[DAP 전문가 가이드] 1.2.2 전사아키텍처 정보 구성 정의
전사아키텍처 정보 구성 개요
- 기업을 잘 이해하기 위해 필요한 업무와 정보기술에 대한 정보로서 활용할 만한 가치가 있고 관리가 용이한 정보라고 정의할 수 있음. 또한 전사아키텍처 정보는 업무와 정보기술의 구성 요소와 구성 요소 간의 관계를 포함함
- 전사아키텍처 정보의 각 구성 요소가 현실적으로 관리가 가능한지는 기업의 상황을 판단하여 관리 가능한 정보를 식별한 후 그 정보를 전사아키텍처 정보로 구축하여야 함
아키텍처 매트릭스 정의
아키텍처 매트릭스 개념
- 전사아키텍처 프레임워크의 핵심 구성 요소로, 전사를 설명하는 모델과 원칙 정보를 통일된 시각으로 볼 수 있는 논리적 틀. 협의의 프레임워크로 아키텍처 도메인의 산출물을 식별하고 정의하기 위한 논리적 체계를 정의하는 것
아키텍처 매트릭스 구성
- 의사결정 유형(관점)과 아키텍처 정보 유형(뷰)의 두 축을 기준으로 2차원의 매트릭스 형태를 띠고 있음. 아키텍처 정보의 활용 방안을 토대로 의사결정 유형과 아키텍처 정보 유형으로 구분하여 각 항목에 필요한 산출물을 도출해 아키텍처 매트릭스를 정의함
- 의사결정 유형 : 조직의 의사결정 유형을 계층적으로 구분한 것으로, 조직이 수행하는 업무의 의사결정 특성에 따라 단계를 정의함. 업무와 IT 조직의 이해 관계자를 식별하고, 이를 바탕으로 정보화 의사결정 계층의 구조를 분석하여 의사결정 유형을 정의함
- 아키텍처 정보 유형 : 특성이 비슷한 아키텍처 정보를 그룹화한 것으로, 기업이 관리하는 모든 아키텍처 정보를 수집하여 분류함. 업무 영역과 정보기술 영역으로 구분되는데, 업무 영역은 조직, 사업, 업무 기능, 업무 프로세스를 포함하고, 정보기술 영역은 데이터, 애플리케이션, 기술 인프라 등을 포함함
* 아키텍처 매트릭스 정의 시 선진 사례의 무조건적인 도입보다는 선진 사례에서 프레임워크를 참조하되 기업의 현황을 고려하여 기업의 전사아키텍처 목표 달성에 필요한 구조로 아키텍처 매트릭스를 정의하는 것이 바람직함
산출물 정의
- 의사결정 유형과 아키텍처 정보 유형으로 구성된 매트릭스의 각 필요한 산출물을 정의
- 산출물의 정의는 어떤 방법론을 사용하는가와 기업의 업무 특성이나 문화에 의하여 좌우됨
관점/뷰 | 업무 | 데이터 | 응용 | 기술 |
계획자 | - 조직 구성도/정의서 - 업무 구성도/정의서 |
- 데이터 구성도/정의서 | - 응용 시스템 구성도/정의서 | - 표준 프로파일 - 기반 구조 구성도/정의서 |
책임자 | - 업무 관계도/기술서 - 업무 기능 분할도/기술서 |
- 개념 데이터 관계도/기술서 - 데이터 교환 기술서 |
- 응용 시스템 관계도/기술서 - 응용 기능 분할도/기술서 |
- 기반 구조 관계도/기술서 |
설계자 | - 업무 절차 설계서 | - 논리 데이터 설계서 - 데이터 교환 설계서 |
- 응용 기능 설계서 - 응용 분산 시스템 설계서 |
- 기반 구조 설계서 - 시스템 성능 설계서 |
개발자 | - 업무 매뉴얼 | - 물리 데이터 모델 | - 응용 프로그램 목록 | - 제품 목록 |
전사아키텍처 정보 구성 요소 정의
- 전사아키텍처 정보 구성 요소 식별
- 전사아키텍처 정보를 공유 정보로 구축하기 위해서는 전사아키텍처 산출물에 포함된 정보를 중복 없이 상호 유기적으로 연결되도록 구성 요소를 정의해야 함. 전사아키텍처 정보가 데이터베이스 형태로 구축되어 지속적으로 갱신되기 위해서는 산출물을 구성 요소 단위로 분류하고 구성 요소 간의 관계를 명확히 할 필요가 있음
- 전사아키텍처 정보 구성 요소 연관 관계
- 구성 요소 간 연관 관계를 통해 특정 업무를 지원하는 시스템이 무엇인지, 특정 시스템이 어떤 시스템과 연계되어 있는지를 알 수 있음. 또한 특적 시스템이 사용하는 데이터는 무엇인지, 특정 시스템이 어느 서버에 운용되고 있는지도 파악할 수 있음
- 전사아키텍처 구성 요소를 관리하면 구성 요소 간의 관계를 분석할 수 있기 때문에 특정 업무의 변화가 있을 때 영향을 받는 시스템, 데이터, 서버 등을 파악할 수 있음
- 연관 관계가 많을수록 전사아키텍처 정보의 활용 가치는 높아짐. 유지 관리 비용을 감안하여 현실적인 수준에서 연관 관계 정보를 관리하는 것이 바람직함
아키텍처 매트릭스 정의 시 고려 사항
- 아키텍처 매트릭스에 정의되는 산출물은 업무와 IT, 관리자와 실무자 사이의 중요한 커뮤니케이션 툴이다.
- 조직적, 정치적, 지리적 특성, 조직의 편견 등 다양한 조직 문화와 의사결정 구조가 반영되어야 한다.
- 아키텍처 매트릭스는 실제 시스템과 아키텍처 개발 표준에 대한 준수성을 높이고 조직별로 통일된 접근이 가능하도록 정의되어야 한다.
- 각 아키텍처 도메인은 상호 간에 연계성을 가져야 한다.
참조 모델 정의
- 기업의 기준 모델로 정의할 참조 모델의 체계와 구조를 정의하고 컨텐츠를 구축함
- 업무와 정보기술에 대한 체계적인 분류와 표준화를 통하여 정보화의 통합성, 중복 개발 방지, 공유 정보의 발견, 상호운용성 향상 등의 목적으로 설계되어 있기 때문에, 개별 기업은 상위기관이나 산업별 참조 모델을 참고하여 아키텍처 정보 구성 요소를 정의하는 것이 바람직함
전사아키텍처 원칙 수립
- 전사아키텍처 비전 달성을 위해 구성원들이 공통적으로 지켜야 하는 규범을 정의하는 것
- 전사아키텍처 원칙은 전사아키텍처 목표 달성을 위한 의사결정의 객관적 기준을 제시함으로써 의사결정을 효과적으로 지원해 주고, 업무 협조와 조정을 위한 의사소통 과정의 투명성을 제공함
<전사아키텍처 기본 원칙 예>
원칙 | 의미 |
업무 지향 | - 기업의 정보화는 업무 개선과 상품 및 서비스 품질 개선에 기여할 수 있는 방향으로 추진되어야 함 |
성과 지향 | - 기업의 정보화는 객관적인 성과 지표에 의해 관리되고 평가되어야 함 |
고객 지향 | - 기업의 정보화는 고객의 만족도를 개선하는 방향으로 추진되어야 함 |
상호운용 | - 기업의 정보화는 전사아키텍처에 정의된 원칙과 아키텍처를 준수하여 시스템 간의 연계성과 운영의 지속성을 확보할 수 있는 방향으로 추진되어야 함 |
- 아키텍처 원칙은 전사아키텍처 기본 원칙을 기반으로 비즈니스 아키텍처, 데이터 아키텍처, 애플리케이션 아키텍처, 기술 아키텍처 등의 아키텍처 도메인별로 원칙을 정의함. 각 아키텍처 정보를 정의하고 관리하는 기준이 되는 원칙으로, 각 아키텍처 정보 구축 시 준수되어야 함
<아키텍처 원칙 예>
아키텍처 | 원칙 | 의미 |
비즈니스 | 범위의 완전성 | - 기업이 수행하는 모든 업무 기능을 누락하지 않고 중복 없이 파악하여 정의해야 함 |
데이터 | 데이터 표준 준수 | - 정의된 표준에 따라 생성, 수정, 활용되도록 해야 함 |
아키텍처 모델 관리 | - 전사 차원의 아키텍처 데이터 모델을 관리하여 전사적 데이터 통합성을 유지해야 함 | |
애플리케이션 | 지원 기능 유일성 | - 응용 시스템의 기능은 유일해야 함 |
기술 | 기술의 표준화 | - 모든 기술 아키텍처 설계 및 도입 시에는 정의된 TRM/SP를 반드시 준수해야 함 |
운영의 안정성 | - 시스템의 장애에 대한 대응 체계 구축으로 시스템의 안정성, 연속성을 보장해야 함 |
<데이터아키텍처 원칙 수립 예>
- 전사아키텍처 원칙을 수립할 때 다음과 같은 사항을 고려해야 함
- 원칙의 의도가 명확하게 제시되어 원칙 적용 시 혼돈의 발생을 최소화할 수 있어야 한다.
- 아키텍처 및 계획 수립과 관련된 의사결정을 효율적으로 할 수 있도록 가이드할 수 있어야 한다.
- 중대한 정보 기술 관련 의사결정 시 규범으로써 활용될 수 있어야 한다.
- 전사아키텍처 조직의 모든 정보 관리 및 기술과 관련된 의사결정은 전사아키텍처 원칙을 기반으로 수행하여야 한다.
- 원칙 간에 서로 상반되는 지향점을 갖지 않도록 원칙 수립 시 사용되는 용어는 주의하여 선택하여야 한다.