전사 아키텍처(Enterprise Architecture)
- 기업 전체의 정보화 시스템을 쉽게 파악할 수 있는 설계도
- 기업의 목표와 요구를 효율적으로 지원하기 위해서 IT 인프라의 각 부분들이 어떻게 구성되고 작동되어야 하는가를 체계적으로 기술한 것
- 복잡한 기업의 정보화 모습을 비즈니스, 데이터, SW, HW 등의 측면으로 분석하고 표현하여
이해하기 쉽도록 정보 체계를 구축 및 활용하는 것
전사가 하나의 기업 또는 기관일수도 있고 아닐수도 있습니다.
A. 기업 하나에 여러 개의 전사로 구성되거나 조직의 아이템, 사업 등을 여러개로 분할할 수 있기 때문입니다.
EA 수립하기 전 해야할 것
- '전사'의 범위를 명확하게 정의해야하고 이해관계자들이 공감해야함
- EA는 하나의 시스템 또는 여러 개의 시스템으로 구성된 하나의 단위 시스템이기 때문에 프로젝트 초기에 '전사 아키텍처' 또는 대상 프로젝트의 '아키텍처'가 무엇인지 상호간에 명확히 정의하고 시작해야함
Architecture
- 골격, 뼈대
구성요소
- 계획(Plan)
- 이행 계획
- 구축 계획 - 규칙(Rule)
- 전략
- 원칙/지침
- 표준 - 모델(Model)
- 참조모델
- 비즈니스 아키텍처
- 데이터 아키텍처
- 애플리케이션 아키텍처
- 기술 아키텍처
모델관점
- 전사 또는 기관의 목표를 달성하기 위한 비즈니스 모델을 바탕으로 한 비즈니스 아키텍처와
시스템을 구성하는 시스템 아키텍처로 구분됨
시스템 아키텍처
1) 데이터
2) 애플리케이션
3) 기술(하드웨어)
모델 수립시 중요한 것은 향후 유지보수를 고려해서 구성해야 하는 것입니다.
규칙관점
- 의사결정 단계에서 상호운용이나 일관성의 유지를 위하여 준수하여야 하는 원칙을 수립하고
적용함으로써 아키텍처의 연속적인 모습을 관리하는 것
계획관점
- 현재와 목표 아키텍처를 정의한 후 수립한 목표 아키텍처를 달성할 수 있는 이행 전략과 계획을 의미
전사 아키텍처 Framework
개념: 전사 아키텍처 활동에서 얻어지는 산출물을 분류하고 조직화하며 이를 유지 및 관리하기 위해 사용하는
전체적인 틀을 의미합니다.
구성: 전사 아키텍처 정책, 정보, 관리로 구성되지만 기업의 EA(전사 아키텍처) 도입 목적에 따라 달라질 수 있습니다.
* 전사 아키텍처 정책 *
: 전사 아키텍처의 정보를 어떻게 구성하고, 어떻게 수립하는지 정하며 기업이 달성하고자 하는 궁극적인 모습은
무엇이며, 효과적으로 관리 및 활용하기 위한 원칙은 어떤 것인지 정의하는 것입니다.
1) 아키텍처 매트릭스
- 전사 아키텍처의 정보를 체계적으로 분류한 틀로서, 기업이 관리하려고 하는 전사 아키텍처 정보의 수준과
활용 계층을 결정하는 수단
: 뷰와 관점 두 차원으로 전사 아키텍처 정보를 구분하고 뷰와 관점이 교차하는 각 셀에는 전사 아키텍처 정보의 실체가 되는 산출물을 정의하는 구조입니다.
좌우는 뷰와 관련되어 있으며 주로 비즈니스, 애플리케이션, 데이터, 기술 등으로 조합되어 있고
상하는 관점과 관련되어 있고 주로 계획자, 책임자(or 분석가), 설계자, 개발자 등으로 조합되어 있습니다.
각 셀은 전후, 좌우의 셀과 연관성을 가지며, 셀 간의 추적성이 확보되어야 합니다.
2) EA 비전
- 전사아키텍처 수립을 통하여 기업이 궁극적으로 달성하고자 하는 모습
- 전사 아키텍처 구축을 목표로하며, 해당 목표를 효과적으로 달성하기 위해서 필욯안 전략 및 방안을 강구
3) EA 원칙
- 전사 아키텍처 정보를 효율적으로 구축하고, 기업의 목적에 맞게 전사 아키텍처 정보를 효과적으로 활용하기 위해서
조직 구성원이 공유해야할 규범
- 전사 아키텍처 대원칙, 전사 아키텍처 원칙, 표준 등으로 구성되어 있다.
* 전사 아키텍처 정보 *
: 아키텍처 정보 구축을 위해서는 아키텍처 매트릭스에서 정의한 각 아키텍처 산출물에 대하여 현행 아키텍처와 목표 아키텍처 정보를 구축해야함
또한 그에 대하여 이행 계획도 수립해야하는데, 이러한 아키텍처 정보를 구축하기 위해서 정보의 영역, 즉 아키텍처 매트릭스에 뷰(View; 좌우) 관점에서 나눠서 정보 영역을 구분합니다.
비즈니스 아키텍처, 데이터 아키텍처, 애플리케이션 아키텍처, 기술 아키텍처 총 네 가지로 나누어 정보 영역을 구분하고
각 아키텍처에 맞게 현행 아키텍처와 목표 아키텍처를 구성해야 합니다.
비즈니스 아키텍처
: 기업의 경영 전략 및 사업모델을 기반으로 비즈니스 수행을 위한 조직 및 프로세스 정의
데이터 아키텍처
: 비즈니스 수행을 위해 필요한 데이터를 어떻게 정의하고 유지할 것인가 정의
기술 아키텍처
: 비즈니스와 결합된 애플리케이션/데이터를 실행하기 위해 갖추어야 할 기술, 인프라를 어떻게 구성하고 관리할 지 정의
애플리케이션 아키텍처
: 비즈니스 수행을 위해 필요한 애플리케이션들을 어떻게 정의하고 제공할 것인가 정의
현행 아키텍처
: 아키텍처 도메인 별로 정의된 산출물에 대하여 기업의 현재 상태를 아키텍처 정보로 정의한 것
목표 아키텍처
: 아키텍처 도메인 별로 정의된 산출물에 대하여 기업이 궁극적으로 달성하고자 하는 목표 아키테처의 상태를 아키텍처 정보로 정의한 것
이행 계획
: 아키텍처 도메인 별로 현재 모습에서 바람직한 목표 모습으로 이행하기 위해 필요한 이행 전략과 계획을 정의한 것
* 전사 아키텍처 관리 *
1) 전사 아키텍터 관리 체계
: 전사 아키텍처 거버넌스라고 불리기도 하며, 전사 아키텍처를 유지 및 개선하기 위해서 제도적으로 기반을 수립하는 것을 말합니다.
정의된 전사 아키텍처 원칙을 준수하고 통제하기 위한 조직과 프로세스를 정의한 것을 의미합니다.
전사 아키텍처 활동을 관리하고 정보 변경을 통제하며, IT 프로젝트가 전사 아키텍처의 기본 원칙과 정책을 잘 지키도록 하는 것이 목적입니다.
2) 전사 아키텍처 관리 시스템
: 전사 아키텍처의 정보 관리의 효율성을 제고하고 전사 아키텍처 정보의 공유를 활성화하기 위해서 구축된 정보시스템
구성요소
- 전사 아키텍처 정보를 정의하는 모델링 도구
- 전사 아키텍처 정보를 저장하는 전사 아키텍처 레포짓토리
- 전사 아키텍처 정보를 사용자에게 배포하는 전사 아키텍처 포털
3) 전사 아키텍처 평가(성숙도 모형)
: 전사 아키텍처의 관리와 활용 수준의 제고를 위해서는 전사 이키텍처에 대해 주기적으로 평가하고, 개선점을 도출하여 반영해야 합니다.
전사 아키텍처는 객관적이고 정확하게 평가할 수 있는 전사 아키텍처 성숙 모형이 필요합니다.
아키텍처 도메인
: 기업이 아키텍처 매트릭스를 어떻게 정의하는에 따라 다르다. 즉 각각의 아키텍처를 사용자 관점으로 매트릭스를
구성하여 필요한 것을 정의한다.
종류: BA(Business Architecture), AA(Application Architecture), DA(Data Architecture), TA(Technical Architecture)
1) 비즈니스 아키텍처
: 기업의 경영 목표를 달성하기 위한 업무 구조를 정의한 아키텍처로 타 아키텍처(DA, AA, TA)의 방향을 정의하고
검증하는 역할을 한다.
- 계획자 관점
| 전사사업 모델 | 조직모델 |
| 전사의 범위를 정함 | 기업의 조직구조 정의 |
| 외부객체와의 가시치슬 분석 | 업무분장 정의 |
- 책임자 관점
| 업무기능 모델 |
| 업무 기능을 계층적으로 분할 |
| 조직기준이 아닌 업무 기능의 유사성과 연관성을 기준으로 분할 |
| 데이터와 어플리케이션의 상호 비교를 통한 연관분석 수행 |
- 설계자 관점
| 프로세스 모델 |
| 업무기능을 상세화하여 계층적으로 프로세스를 분할 |
- 개발자 관점
| 업무 메뉴얼 |
| EA에서는 목록수준의 정보를 관리 |
2) AA (Application Architecture)
: 기업의 업무를 지원하는 전체 어플리케이션을 식별하고 연관성을 정의하고, 전체 어플리케이션 구조를 체계화 하는 것
- 계획자 관점
| 전사 어플리케이션 영역 모델 |
| 전사 수준 구조화 |
| 어플리케이션을 그룹화 |
- 책임자 관점
| 어플리케이션 모델 |
| 어플리케이션 서비스 간의 연관관계 정의 |
| 모델의 정의는 개발방법론에 의존적 |
- 설계자 관점
| 컴포넌트 모델, 클래스 모델 |
| 개발에 필요한 설계 정보를 관리 |
| 기업의 개발 방법론에 영향을 받음 |
- 개발자 관점
| 프로그램 목록 |
| 프로그램에 대한 정보 관리 |
3) DA(Data Architecture)
: 기업의 업무 수행에 필요한 데이터의 구조를 체계적으로 정의한 것입니다.
- 데이터 영역분류
| 업무 데이터 | 메타 데이터 |
| 운영계 데이터 |
| 정보계 데이터 |
- 계획자 관점
| 전사 데이터 영역모델 |
| 개괄 데이터 모델 |
| 상위주제 영역 수준의 데이터 구성도 |
- 책임자 관점
| 개념 데이터 모델 |
| 전사 수준의 데이터 모델 |
| 단위주제영역 또는 핵심엔터티표현(단위주제영역별로 한 두 개) |
- 설계자 관점
| 논리 데이터 모델 |
| 모든 에터티 도출 |
| 전사적인 차원의 표준을 정의 |
- 개발자 관점
| 물리 데이터 모델 |
| 비정규화 |
| 인덱스 설계 |
4) TA(Technical Architecture)
: 타 아키텍처에서 정의된 요건을 지원하는 전사의 기술 인프라 쳬계를 정의하는 것으로, TA는 개별 기업에도
기술 참조 모델을 정의하는 것이 일반적입니다.
- TRM과 SP구축을 통해 어플리케이션의 이식성과 확장성을 강화하고 벤더 독립성을 확보, 시스템 상호 운용성을 강화한다.
- 개별 기업에서도 기술참조모델을 정의하고 아키텍처 매트릭스에서 TRM을 계획자수준의 산출물로 포함한다.
- 계획자 관점
| 전사기술영역모델 | 기술참조모델 |
| 정보기술의 영역을 상위수준에서 분류 | 정보기술을 상위수준에서 논리적으로 분류한 틀 |
| 일반적인 표준을 최대한 수렴(=> 전사기술영역모델과 다른 이유) |
- 책임자 관점
| 개념 데이터 모델 |
| TRM에 명시된 서비스를 지원하기 위한 정보기술표준 집합 |
| 일반적으로 기술표준을 프로파일의 대상으로 함 |
| 제품을 프로파일링 대상에 포함시키는 주세 |
- 설계자 관점
| 기술 아키텍처 모델 |
| 전사 기술 영역 모델이나 TRM에서 정의된 서비스 카테고리별로 아키텍처 패턴을 정의 |
| S/W, H/W, N/W 등의 구성요소에 대한 배치도 정의 |
- 개발자 관점
| 기술자원목록, 제품목록 |
| 인덱스 설계 |
* TRM(Technical Road Map)
- 미래 시장에서 요구되는 제품 또는 서비스를 규명함
- 위 서비스 또는 제품에 필요한 핵심 기술과 필요 기술을 도출함
- 최적의 기술 대안을 선택할 수 있게 하는 시장 지향 기술 기획을 과정함