아키텍쳐를 설계 하는 사람은 아키텍트(Architect)라고 한다. 이 아키텍트는 아키텍쳐 설계 프로세스에서 정의한 각 아키텍쳐에 대해서 아키텍쳐를 설계하는 역할들이 정의된다. 계층 구조를 제외하면 아키텍쳐는 5가지로 분리된다.(http://bcho.tistory.com/667 참조) Business Architecture, Application Architecture, Solution Architecture, Data Architecture로 분리되며, 아키텍트 역시 이 5개 분야에 걸쳐서 총 5개의 역할로 정의된다.
Enterprise Architect (EA) Business Architecture를 포함한 전체 아키텍쳐 설계에 대한 책임을 진다. 비지니스 이해를 바탕으로 전체 아키텍쳐에 대한 큰 설계를 담당하며, 비지니스에 대한 이해를 바탕으로 장기적인 IT 전략 수립을 담당한다. EA의 특징중의 하나는, EA의 경우 단일 프로젝트 뿐만 아니라, 해당 회사의 앞으로의 비지니스 전략에 맞춰서 향후 모든 프로젝트에 대한 아키텍쳐에 대한 책임을 진다. 또한 SA,AA,TA,DA에 대한 통제 권한을 가지고 아키텍트 팀을 운용한다. 가끔 CIO와 혼동하는 경우가 있는데, CIO는 회사 내부의 IT 전략을 수립하고, IT 포트폴리오를 정의하고 수행한다는 관점에서 EA와 유사한 면이 있으나, 기술적인 면에서는 CIO와 EA의 부분이 겹칠 수 있으나 경영적인 측면에서는 다르다. CIO는 결정적으로 예산 집행권과 인사권을 가지고 있으며 설계 보다는 경영과 관리에 목적을 두는 반면, EA는 아키텍쳐 설계를 그 목적으로 한다.
Solution Architect (SA) 특정 솔루션에 대한 아키텍쳐를 설계한다. SA의 경우 프로젝트 내에 개발팀이 있을때, 해당 솔루션을 사용하는 모든 팀에 대한 아키텍쳐 설계를 담당한다.
Technical Architect (TA) 프로젝트 전체팀에 대한 하드웨어 및 네트워크 아키텍쳐를 설계한다.
Application Architect (AA) 애플리케이션에 대한 표준 가이드 및 아키텍쳐 구조를 담당한다. 팀 규모에 따라 대규모 팀인 경우 각 개발팀마다 AA를 배치하고, 소규모팀인 경우에는 프로젝트 전체팀에 대해서 애플리케이션 아키텍쳐 설계를 담당한다.
Data Architect (DA) 프로젝트 전체팀테 대해서 데이타 아키텍쳐 설계를 담당한다.
Global Architect (GA) [Optional] 일반적인 프로젝트 팀 구조에서는 잘 존재하지 않는 역할이다. EA의 경우 사내에서 진행중인 모든 프로젝트에 대해서 관여해야 하고, 비지니스 전략 측면에서 접근을 하다보니 경영진과의 커뮤니케이션이나 의사 결정 과정에 참여가 많아지기 때문에 실제 아키텍쳐 설계 과정에 디테일하게 참여하기가 어렵고, 때로는 기술의 이해수준이 아주 디테일 하지 않은 경우가 있기 때문에, GA라는 역할을 둬서 SA,TA,DA,AA에 대한 통제 권한 부여하고 기술 중심의 System Architecture의 설계 하도록 한다. 프로젝트 팀의 PM/PL의 관계를 EA/GA 관계로 보면 된다. EA는 비지니스를 포함한 외부 대응이나 큰 그림에 신경 쓰고, GA는 기술 위주의 아키텍쳐 설계에 집중한다.
소프트웨어 아키텍처 이론과 실제 > 1부 아키텍처 개요
혁신도시 건설계획, 공공기관 지방이전 계획
