EA/ITA

○ EA/ITA

정의	° 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 구현이 중요