|
정의 |
° EA(Enterprise Architecture)
- 조직 및 업무활동과 정보기술 간의 관계를 현재모습과 향후 추구할 모습을 별도로 정의한 청사진(Blueprint)
- 규칙(Rule) + 모델(Model) + 계획(Plan)으로 구성
° ITA(Information Technology Architecture)
- EA + TRM +SP |
|
구성요소 |
EA Framework |
° EA를 개발하기 위한 의사소통 모델
° 기업의 비즈니스, 정보, 어플리케이션 및 기술에 대해 명확한 구성요소로 식별, 정의하고 이들간의 관계를 정립한 구조적인 틀
 
※ 아키텍쳐 도메인
|
비즈니스 아키텍쳐 |
° 기업의 경영목표 달성을 위해 업무구조를 정의한 영역으로 기업의 업무와 서비스의 실체를 명확히 하는것 |
|
데이터 아키텍쳐 |
° 기업의 업무 수행에 필요한 전체 데이터 구조를 체계적으로 정의한 것 |
|
어플리케이션 아키텍쳐 |
° 기업의 업무를 지원하는 전체 어플리케이션을 식별하고 어플리케이션 구조를 체계화하는 것 |
|
기술 아키텍쳐 |
° 비즈니스, 데이터, 어플리케이션 아키텍쳐에서 정의된 요건을 지원하는 전사의 기술 인프라 체계 | |
|
기술참조모델(TRM) |
° 기업이 업무활동에 필요한 기능들을 수행하기 위해 요구되는 정보기술을 상위 수준에서 논리적으로 분류한 틀인데, 전사기술영역 모델과 같은 범주로 볼 수 있다. 다만 기술 참조 모델은 일반적인 표준을 최대한 수렴해 정의한는 것이 특징 |
|
표준프로파일(SP) |
° 기술참조모델에 명시된 서비스를 지원하는 정보기술 표준들의 집합
° 해당 아키텍쳐에 적용될 표준에 대해 서술해 둔 내용물 |
|
절차 |
|
EA 비전 수립 |
° EA 방향 수립 - 환경분석, 구축 방향 정의, EA 프레임워크 정의 |
|
EA 구축 |
° EA 정보 구성 정의 - 아키텍쳐 매트릭스 정의, 참조모델 정의, EA원칙 수립
° EA 정보 구축 - EA 자료수집, AS-IS 구축, TO-BE 구축 |
|
EA 관리 정의 |
° EA 관리체계 구축 - EA 관리 조직, 프로세스, 인력 구성
° EA 관리시스템 구축 - EA 모델링 도구, EA 정보관리 시스템(EA Repository, EA Portal, EA Analysis Tool) |
|
EA 활용 정의 |
° EA 이행계획 - 차이분석, 프로젝트 정의, 이행 전략 수립, 이행 계획 수립, 변화관리 계획수립
° EA 정보활용 - IT 기획, IT 구축관리, IT 운영 및 통제 |
※ EA 관련 DA가 이루어야 할 3가지 통합성
° 범위통합 - 전사아키텍쳐 범위 전체에 대한 각 모델 내의 불일치성 제거
° 수평통합 - 관련된 타 도메인(업무, 데이터, 어플리케이션, 기술)과의 불일치성 제거
° 수직통합 - 계획자, 책임자, 설계자, 개발자 사이의 불일치성 제거 |
|
참조모델
활용방안
및
기대효과 |
|
|
활용방안 |
기대효과 |
|
업무참조
모델 |
° 개선 대상 관련 업무를 파악
° 비즈니스 아키텍쳐 정의 |
° 기관간 업무 흐름 촉진
° 업무 프로세스 촉진을 통한 생산성 제고
° 비즈니스 성과 측정 용이 |
|
데이터참조
모델 |
° 개선 대상 관련 데이터 파악
° 데이터 아키텍쳐 정의 |
° 정보의 상호운용성 및 교환 촉진
° 통합된 데이터 활용으로 중복배제 및 재사용
° 데이터 표준화 |
|
서비스참조
모델 |
° 개선 대상 관련 어플리케이션 서비스 파악
° 어플리케이션 아키텍쳐 정의 |
° 시스템간 상호운용성 향상
° 신뢰성 있고 변화에 신속한 대응 가능
° 시스템 개발 생산성 및 품질 향상 기대 |
|
기술참조
모델 |
° 개선 대상 관련 기술 인프라 파악
° 기술 아키텍쳐 정의 |
° 시스템간 상호운용성, 이식성, 확장성 향상
° 벤더 독립성
° 재활용과 리소스 공유 |
※ 참조모델 구축방법
° 공통특성 추출 - 이해가 쉽고 산출물이 많지 않지만 요소간 경계, 하위수준의 정의가 불명확
° 대표적이고 복잡한 기업 선정 - 산출물간의 관계가 정확하고 하위수준까지 참조할 수 있지만 기업의 보안상 대부분 공개가 되지 않음 |
|
EAF
사례 |
|
ZEAF |
° 기업활동을 5W1H관점에서 모델링
° 5개 관점 - Data, Function, People, Network, Time, Motivation
° 6개 묘사방법 - Planner, Owner, Designer, Builder, Sub-Contractor
° 지나치게 모델링에 집중, 실제 아키텍쳐 활동 계획 및 기반 정의 부족 |
|
FEAF |
° 미 연방정부 프레임워크
° 참조모델 기반 EAF(BRM, DRM, SRM, TRM, PRM)
° 모델링 관점과 구체적 이행계획까지 포함
° 조직 및 관련 규정등 제반요소의 진화 부족 |
|
TEAF |
° 미 재무성 프레임워크
° How-Where-When을 표현하는 기능, What-How-much How Freq.을 표현하는 정보, Who-Why를 표현 하는 조직, Enable을 표현하는 인프라 관점 중시
° 산출물 중심의 프레임워크로서 활용에 대한 접근 부족 |
|
DoDAF |
° 미 국방성 프레임워크
° 효과적인 작전 수행을 위해 무기 체계간 상호 운용성 보장을 위해 도입된 EA
° 산출물에 대한 템플릿을 상세히 정의, 통일되고 검증된 방식으로 모델링 가능, 운영모델에 대한 상세 한 정의 및 표현양식 제공
° 과도한 산출물과 정확도 요구, 과잉투자 가능성 |
|
TOGAF |
° 민간 표준연합인 오픈그룹 EAF
° 구체적 아키텍쳐 개발 프로세스 제안
° 각종 참조모델의 활용 관계를 잘 정의
° 메타모델에 근거한 연속체 개념으로 아키텍쳐를 파악하여 조직의 특수성 반영이 어려움 | |
|
EAP
vs
ISP |
※ ISP vs EAP
|
ISP |
EAP |
|
° 원칙에 대한 정의 주로 없음
° 벤더 의존적
° 문서 지향적 산출물
° 조직, 기술변화시 사용되지 못함
° 외부 컨설턴트 의존적
° 도출과정 모호성
° 산출물 유지보수가 거의 이루어지지 않음 |
° 정보관리 전체에 적용될 원칙 정의
° 사용자 소유의 표준적, 오픈 아키텍쳐
° 프로젝트 지향적 산출물
° 지속적인 아키텍쳐 수정
° 내부주도, 외부지원
° 도출과정의 체계성
° EA실행과 유지보수를 위한 Control Mechanism 구현이 중요 | |