365 new days, 365 new chances

계획단계에서 AA의 역할은 기업마다 크게 달라짐

- 업무 분석 주도 및 문서화

- PM을 지원하여 프로젝트 범위 정의

- 필요한 시간과 리소스 산정

- 외부 어플리케이션과의 인터페이스 정의 및 설계

1) AA는 프로젝트에서 사용될 기술을 선택한다

   : 기업수준 --> 하드웨어, 운영체제, 소프트웨어, 언어 등

     AA수준 --> ex) XML parser, third party package, utility 등

2) AA는 프로젝트에서 사용할 개발방법론과 프레임워크를 추천한다

3) AA는 어플리케이션의 종합적인 설계와 구조를 제공한다

4) AA는 어플리케이션 설계를 적절하게 문서화해야 한다

   : 설계 문서화는 개발자들과 커뮤니케이션 하는 중요한 단계

   : 문서는 프로젝트 중간에 사람이 교체되더라도 프로젝트가 제대로 유지될 수 있도록 한다

5) AA는 코드 작성 가이드라인을 수립한다

   : 예외처리, 로깅, 테스트, 스레딩, 캐싱, 설정 등

6) AA는 인프라스트럭처 요구사항을 정의한다

[AA와 사람들] AA와 PM

1) AA는 PM에게 구현 작업을 식별해주어야 한다

   : AA는 PM이 현실적으로 프로젝트 계획과 산정을 할 수 있도록 도와주어야 한다

2) AA는 PM을 도와 관리를 위한 프로젝트 비용과 효과를 산정한다  

3) AA는 PM이 개발자 위치에 대한 인사결정을 할 수 있도록 도와준다

4) AA는 PM에게 기술적인 충고와 가이드를 제공해야 할 책임이 있다

[AA와 사람들] AA와 PL

'조대협의 블로그'에 방문해서 이런저런 글을 보다가 아키텍트 키워드가 눈에 들어오길래 쭉 읽어봤다 ㅎㅎ

공감되는 말이 많아 퍼왔다. 

아키텍트

아키텍트는 전체 시스템을 디자인하고 설계하는 역할을 가지는 사람이다.
아키텍처링은 크게 두가지로 나뉘어 지는데 첫번째는 비지니스 아키텍쳐, 다음은 테크니컬 아키텍쳐이다.
비 지니스 아키텍쳐랑, 해당 시스템이 비지니스적으로 어떤 의미를 갖는지에 대한 내용으로 사업 전략,비젼,요구사항 분석과 같은 범주와 관련이 된다. 시스템의 구현 목적은 어떤 비지니스의 목적을 달성하기 위함이다. 사업 전략이야 COO 분들이나, 아니면 비지니스 컨설턴트가 진행을 하기는 하지만, 비지니스 요건을 어떻게 시스템으로 구현하여 효과를 낼지는 IT 아키텍트의 역할이다. 그래서, 비지니스에 대한 아키텍쳐링도 매우 중요하다. 
다음이 테크니컬 아키텍쳐인데, 전체 시스템의 그림을 그리고, 비지니스 요건을 충족하기 위한 기술적인 설계를 하는 역할이다.
 강조하고자 하는 바는 비지니스 요건을 잘 이해해야 한다는 것이다.
예를 들어 분산 트렌젝션 요건이 있다고 하자. "주문과 결재" 두가지 기능을 묶어야 할경우, 여러가지 선택이 있다.
XA기반의 분산 트렌젝션을 사용하는 방법, 보상 트렌젝션 처리, 로깅을 통해서 유실분에 대한 처리, 아니면 유실되는 것 데로 놔두는 것...
고급 기능과 아키텍쳐에는 돈이 든다. 물론 XA기반으로 구현하면 좋겠지만, 해당 시스템이 느린 경우 LOCK 경합 문제가 발생할 수 도 있고, 복잡도가 높아지는 만큼 테스팅에 대한 코스트도 높아진다.
 유료 회원 가입 프로세스 경우 차라리 에러가 나는데로 놔두는 것이 비용 측면에서 훨씬 유리할 수 있다. 공짜로 가입되었다고 Complain할 사람은 그리 없으니까는.
 즉. 완벽한 보안 장치를 하기 위해서, 서랍에 자물쇠를 하느냐 몇천만원짜리 지문 인식 장치를 하느냐가 아닐까?

아키텍트의 능력 중에서 중요한 것은

출처: http://bcho.tistory.com/252 [조대협의 블로그]