아키텍쳐를 설계 하는 사람은 아키텍트(Architect)라고 합니다. 이 아키텍트는 아키텍쳐 설계 프로세스에서 정의한 각 아키텍쳐에 대해서 아키텍쳐를 설계하는 역할들이 정의됩니다.
계층 구조를 제외하면 아키텍쳐는 5가지로 분리되는데, 참조 Business Architecture, Application Architecture, Solution Architecture, Data Architecture로 분리되며, 아키텍트 역시 이 5개 분야에 걸쳐서 총 5개의 역할로 정의됩니다.
Application Architect (AA)
프레임워크, 공통설계자
특정 어플리케이션의 구축에 대한 표준 가이드 및 아키텍쳐 구조를 담당합니다.
팀 규모에 따라 대규모 팀인 경우 각 개발팀마다 AA를 배치하고,
소규모팀인 경우에는 프로젝트 전체팀에 대해서 애플리케이션 아키텍쳐 설계를 담당하게 됩니다.
간혹 SA와 AA를 혼동할 수 있지만, SA는 각각의 독립적인 Application간의 종속성이 발생하는 것에 대한 설계를 하는 것기고 AA는 독립적인 Application의 세부 설계를 담당하게 됩니다.
결론 : 업무단과 내부로직 설계(인터페이스 및 업무처리에 필요한 모듈 설계 및 제작)
Data Architect (DA)
데이터 구조 설계
프로젝트 전체팀테 대해서 데이타 아키텍쳐 설계를 담당합니다. [번역글] 데이터 아키텍트(Data Architect)의 삶 을 참고하자면, 데이터 아키텍트는 회사의 잠재적인 데이터 소스(내부 및 외부)를 평가한 후 통합하고 중앙 집중화하며, 보호 및 관리하는 계획을 설계하여, 적시에 적절한 장소에서 중요한 정보에 접근할 수 있도록 합니다.
- IT 팀 및 경영진과 협업하여 업계 요구사항을 해결하는 데이터 전략을 수립
- 아키텍처를 구현하는 데 필요한 데이터 목록을 구축
- 데이터를 획득하기 위한 새로운 기회를 연구
- 현행 데이터 관리 기술을 식별하고 평가
- 데이터가 조직에서 어떻게 흐르는지에 대한 가변적인 양단간 비전을 창조
- 데이터베이스 구조에 대한 데이터 모델을 개발
- 데이터베이스 아키텍처 및 응용 프로그램(예: 대규모 관계형 데이터베이스)을 설계하고 문서화하며 구성하고 배포
- 기술적 기능(예: 확장성, 보안, 성능, 데이터 복구, 안정성 등)을 통합
- 데이터 정확성 및 접근 가능성 보장을 위한 조치를 구현
- 데이터 관리 시스템의 성능을 지속적으로 모니터링, 조정 및 보고
- 기존의 웨어하우스 구조에 새로운 시스템을 혼합시킴
- 데이터베이스 개발 표준을 작성하고 시행
- 모든 데이터 아키텍처 산출물 및 절차에 대한 공동 저장소를 관리
결론: 전체 데이터에 대한 구조적 설계를 담당.
Global Architect (GA)
아키텍쳐 설계
일반적인 프로젝트 팀 구조에서는 잘 존재하지 않는 역할입니다.
EA의 경우 사내에서 진행중인 모든 프로젝트에 대해서 관여하며, 비지니스 전략 측면에서 접근을 하다보니 경영진과의 커뮤니케이션이나 의사 결정 과정에 참여가 많아지기 때문에 실제 아키텍쳐 설계 과정에 디테일하게 참여하기가 어렵고, 때로는 기술의 이해수준이 아주 디테일 하지 않은 경우가 많습니다.
그럴때, GA라는 역할을 둬서 SA,TA,DA,AA에 대한 통제 권한 부여하고 기술 중심의 System Architecture의 설계 하도록 합니다.
프로젝트 팀의 PM/PL의 관계를 EA/GA 관계로 보면 됩니다.
EA는 비지니스를 포함한 외부 대응이나 큰 그림에 신경 쓰고, GA는 기술 위주의 아키텍쳐 설계에 집중합니다.
결론 : SA,TA,DA,AA에 대한 통제
Technical Architect (TA)
Infra Architect
업무시스템을 운영할 환경을 구성하는 하드웨어, 소프트웨어, 네트워크를 정의합니다.
EA 또는 SA가 3-Tier 모델을 정의하면,
각각의 Tier 사이에 물리적인 네트워크의 구조를 TA가 담당하게 되는 거 같습니다.
프로젝트중 발생할만한 기술적 이슈(Business, Database Data 제외)에 대한 Support하는게 주된 업무로 보입니다.
결론 : 프로젝트 전체팀에 대한 하드웨어 및 네트워크 아키텍쳐를 설계
Solution Architect (SA)
특정 솔루션 아키텍쳐 설계
SA는 특정 솔루션에 대한 Architecture를 설계계합니다. SA가 하는 업무가 EA와 겹치는 부분이 있을 수도 있지만, EA가 전체 구조에 대한 설계라면 SA는 특정 분야에 대한 세부설계를 담당한다고 할 수 있으며, 그렇기 때문에 EA보다는 특정 영역에 대해서 전문적인 지식이 필요합니다.
결론 : SA의 경우 프로젝트 내에 개발팀이 있을때, 해당 솔루션을 사용하는 모든 팀에 대한 아키텍쳐 설계를 담당
그리고 그 외에는,
Enterprise Architect (EA)
Business Architecture를 포함한 전체 아키텍쳐 설계에 대한 책임을 집니다. 비지니스 이해를 바탕으로 전체 아키텍쳐에 대한 큰 설계를 담당하며, 비지니스에 대한 이해를 바탕으로 장기적인 IT 전략 수립을 담당합니다.
EA의 특징중의 하나는, EA의 경우 단일 프로젝트 뿐만 아니라, 해당 회사의 앞으로의 비지니스 전략에 맞춰서 향후 모든 프로젝트에 대한 아키텍쳐에 대한 책임을 지며,
SA,AA,TA,DA에 대한 통제 권한을 가지고 아키텍트 팀을 운용합니다.
가끔 CIO(최고 정보 책임자)와 혼동하는 경우가 있는데, CIO는 회사 내부의 IT 전략을 수립하고, IT 포트폴리오를 정의하고 수행한다는 관점에서 EA와 유사한 면이 있으나, 기술적인 면에서는 CIO와 EA의 부분이 겹칠 수 있으나 경영적인 측면에서는 다르다고 합니다.
CIO는 결정적으로 예산 집행권과 인사권을 가지고 있으며 설계 보다는 경영과 관리에 목적을 두는 반면, EA는 아키텍쳐 설계를 그 목적으로 합니다.
결론 : 전체 아키텍처 설계에 대한 책임을 집니다.
Business Architect (BA)
일반적으로 역할을 구분하지는 않지만, EA의 경우 기술적인 측면과 비즈니스적인 측면에 대한 이해도가 모두 높아야 합니다.
하지만 현실적으로 두 가지에 대한 이해도가 높은 사람이 극히 드물기 때문에 EA는 좀더 기술적 측면에 집중하고 BA로 하여금 비즈니스적 측면을 고려할 수 있도록 역할을 분담하고 있습니다.
비즈니스 측면에 대한 설계를 담당
quality assurance (QA)
품질보증
주로 프로그램이나 문서의 검수를 합니다. 대부분 로직이나 내용보다는 룰(규정)을 지켰는지 봅니다.