데이터 아키텍처 - 전사아키텍처(EA, Enterprise Architecture)
#EA의 개념
1) EA 도입은 IT에 대한 혁신과 관리:통제를 포함하며 시스템의 도입, 구축, 운영, 평가 등을
통합적으로 관리하는 것을 의미한다.
2) EA는 IT와 업무간의 연계뿐만 아니라 현재의 모습과 미래의 모습을 포함한다.
3) EA 도입의 궁극적인 목적은 IT 투자 대비 효과를 최대화하는 것이다.
4) 기업에 따라 도입 목적이 다를 수 있다.
#아키텍처의 3가지 구성요소
1) 모델(Model) 2) 원칙(Rule) 3) 계획(Plan)
#전사의 정의
1) 전사의 범위는 기업의 규모나 구조에 따라 달라질 수 있다.
2) 하나의 기업은 여러 개의 전사로 구성될 수 있다.
3) 전사는 구분 가능한 다수의 사업 영역으로 구성된다.
4) EA 수립에 관련된 모든 활동은 정의된 전사의 성과와 목표에 초점을 두어야 한다.
#전사(Enterprise)에 대한 개념
1) 전사의 범위를 고려하기 위해서는 해당 기업 및 기관 뿐만 아니라 기업 및 기관을 둘러싸고
있는 외부 객체와의 역학관계를 반드시 고려해야 한다.
2) 하나의 기업이 여러 개의 전사로 구성될 수 있다.
3) 전사는 계층구조를 가질 수 있다.
4) 자회사를 보유하고 있는 모기업의 경우, 전체 그룹사를 전사의 범위로 선정하여 통합적인 전사 아키텍처 프레임 워크를 적용할 수 있다.
#데이터아키텍처 전문가가 전사아키텍처와 관련하여 수행해야 할 일
1) EA 프로젝트의 데이터아키텍처 정의 담당자로 참여하는 것은 바람직하다.
2) 구축된 EA 원칙과 정보를 준수 및 활용해야 하고, 담당하고 있는 데이터 모델의
변경 정보가 EA 정보에 반영될 수 있도록 조치할 의무가 있다.
3) EA 프로젝트가 진행되지 않더라도 필요시에 데이터 부분만의
아키텍처 정립 작업을 수행할 수도 있다.
#전사아키텍처 프레임워크에 대한 설명
1) 자크만(Zachman)프레임워크는 다섯 가지 관점(Planner, Owner, Disigner, Builder,
Sub-contractor)과 각 관점에 따른 여섯 가지 묘사 방법(Data, Function, Network, People,
Time, Motivation)을 통하여 EA모델 형식으로 제시한다.
2) 미연방정보 프레임워크(FEAF)는 참조모델(BRM, DRM, SRM, TRM, PRM)기반의
EA프레임워크이다.
3) 미국방성의 아키텍처 프레임워크(DoDAF)는 효과적인 작전수행을 위해 무기 체계간의 상호운용성을 보장하기 위해 도입된 프레임워크이다.
4) 오픈그룹의 EA 프레임워크(TOGAF)는 아키텍처 매트릭스를 별도로 제시하지 않고 있다.
5) 미국재무성 프레임워크(TEAF) 또는 한국전산원 프레임워크에서
계획자, 소유자, 설계자, 개발자 등의 관점으로 구분한 아키텍처 매트릭스를 제시하고 있다.
#아키텍처 매트릭스에 대한 내용
1) 아키텍처 매트릭스를 통해 아키텍처 정보를 분류하는 차원은 기업의 특성에 맞게 임의로 조정 할 수 있다.
2) 아키텍처 매트릭스는 EA 정보를 체계적으로 분류한 틀로써, 기업이 관리하려고 하는 EA정보의 수준과 활용 계층의 분류를 통하여 결정 될 수 있다.
3) 아키텍처 매트릭스에서 뷰(View)는 기업이 관리하고 있는 정보의 유형에 따라 달라진다.
4) 아키텍처 도메인 구성은 기업이 아키텍처 매트릭스를 어떻게 정의하느냐에 따라
달라질 수 있다.
#참조모델
1) 참조모델은 아키텍처 구성요소를 식별하여 표준화한 것으로, 기업이나 기업의 전사아키텍처를 수립 할 때 참조하는 추상화된 모델이다.
2) 국내의 대표적인 참조모델은 범정부차원의 참조모델이 있으며, 그 내용은 업무, 서비스, 기술, 데이터, 성과 참조모델 등으로 구성된다.
3) 참조모델 중에서 기술 참조모델의 활용도가 가장 높다.
4) 참조모델을 정의하는 방법은 산업군별로 특성을 추출하여 추상화시키는 방법과 산업내 대표적인 기업의 참조모델을 표본으로 정의하는 방법이 있다.
#DA 수립 업무에 대한 설명
1) 전사 데이터 영역 모델은 ‘개괄 데이터 모델’이라고도 하며 상위 수준에서 전사 데이터 영역을 분류하여 표현한 것이다.
2) ‘개념 데이터 모델’은 전사 수준의 데이터 모델로써 주제영역이나 핵심 엔티티 정보까지만 도출하여 표현한 데이터 모델이다.
3) ‘논리 데이터 모델’은 업무 요건을 충족시키기 위해 데이터의 상세 구조를 논리적으로 구체화 한 것이다.
4) ‘물리 데이터 모델’은 기술적 환경 및 특성을 고려하여 물리적 데이터 구조를 설계하고
데이터베이스 객체를 정의하는 것이다.
#아키텍처 도메인에 대한 설명
1) 비즈니스 아키텍처(Business Architecture)는 기업의 경영목표 달성을 위해 업무구조를 정의한 아키텍처 영역으로 기업의 업무와 서비스의 실체를 명확히 하는 것이다.
2) 애플리케이션 아키텍처는 기업의 업무를 지원하는 전체 애플리케이션을 식별하고 애플리케이션 구조를 체계화하는 것이다.
3) 데이터 아키텍처(Data Architecture)는 기업의 업무 수행에 필요한 전체 데이터의 구조를
체계적으로 정의하는 것이다.
4) 기술 아키텍처(Technical Architecture)는 비즈니스, 데이터, 애플리케이션 등의 아키텍처에서 정의된 요건을 지원하는 전사의 기술 인프라 체계를 정의하는 것이다.
#기술 참조모델에 대한 설명
1) 기술 참조모델은 다른 참조모델에 비하여 구축하기 쉽고 기대효과가 커서 가장 먼저 적용하는 영역이다.
2) 기술 참조모델은 몇 개의 서비스 영역으로 구성되고 서비스 영역은 다시 하위 수준의 서비스 범주로 구성될 수 있다.
3) 기술 참조모델을 개별 기업에서 적용하는 것은 일반적이다.
4) 기술 참조모델을 적용하면 시스템 간의 상호운용성을 향상시킬 수 있다.
5) 기술 참조모델은 시스템 구축 할 때 사용할 기술들에 대한 표준 프로파일을 분류하는 기준으로 활용된다.
#EA 프로세스에 대한 설명
1) IT 관리체계 프로세스는 EA 프로세스보다 포괄적인 개념이다.
2) EA 프로세스에는 일반화되어 있는 방법론을 적용하기보다 전사의 특성에 맞게 조정하여 적용하는 것이 바람직하다.
3) EA 프로세스는 EA 프레임워크의 구성요소 중 하나이며, 다른 구성요소를 정의하기 위한 절차를 포함한다.
4) EA 프로세스는 EA에 대한 비전 수립, 구축, 관리, 활용 등의 단계를 포함한다.
#데이터 참조모델의 활용 방안이나 효과
1) 개선의 대상이 되는 관련 데이터를 데이터 참조모델을 참조하여 파악할 수 있다.
2) 개별 기관의 DA를 데이터 참조모델을 참조하여 정의할 수 있다.
3) 데이터 참조모델을 사용하는 기관간 정보의 상호운용성과 교환을 촉진한다.
#EA 프로세스
1) EA 프로세스는 EA를 구축하고 관리하는 전체 절차에 관한 것으로 작업의 단계, 공정, 내용 등을 정의하는 것이다.
2) EA 프로세스는 EA 비전 수립, EA 구축, EA 관리, EA 활용 등의 단계로 구분할 수 있다.
3) EA 구축 시에는 단계별로 보고회 및 워크샵 형태의 행사를 통해 이해관계자의 지속적인 참여를 유도해야 한다.
#EA 구축 방향 수립의 작업
1) EA 목적 및 범위 정의
2) EA 비전 수립
3) EA 프레임워크 정의
#전사아키텍처 정보 구성에 대한 설명
1) EA 정보는 변화하지 않는 구성요소를 분석하여 정의하는 것이 이상적이다.
2) EA 산출물과 EA 정보 구성요소는 다르다.
3) EA 정보 구성은 아키텍처 매트릭스를 통하여 정의되고 표현된다.
4) EA 정보는 무조건 상세하게 관리한다고 투자효과가 큰 것이 아니다.
#참조모델의 활용목적과 효과
1) 업무 참조모델을 활용하면 개선의 대상이 되는 업무를 보다 쉽게 파악할 수 있고, 관련 기관간의 업무흐름을 촉진할 수 있다
2) 데이터 참조모델을 활용하면 정보의 상호교환을 촉진하고, 데이터의 중복을 배제하며 재사용을 촉진할 수 있다.
3) 서비스 참조모델을 활용하면 신뢰성이 높은 시스템을 구축할 수 있고, 시스템 개발의 생산성과 품질 향상을 기대할 수 있다
4) 기술 참조모델을 활용하면 시스템간의 상호운용성 향상과 표준화를 통한 벤더 독립성을 제고할 수 있다.
#아키텍처 매트릭스 정의 시 고려할 사항
1) 조직 내 다양한 계층의 사람들이 매트릭스에 포함된 산출물이 범위와 목적에 적합하게 정의되었음을
확신할 수 있어야 한다.
2) 아키텍처 도메인은 관리하고자하는 정보 유형에 따라 얼마든지 다르게 정의할 수 있다.
3) 아키텍처 매트릭스는 IT 조직의 성숙도를 고려해서 정의한다.
4) 전사아키텍처 정보를 공유정보로 구축하기 위해서는 EA산출물에 포함된 정보를 중복이 없고
상호관계가 유기적으로 연결될 수 있는 'EA 정보 구성 요소‘를 추가로 정의해야 한다.
#목표 아키텍처를 정의하는 방식
- 목표 아키텍처 정보 구축 할 때는 먼저 비즈니스 아키텍처를 정의하고, 타 아키텍처를 정의하는 것이 바람직하다.
#전사아키텍처 정보 구축 방식에 대한 설명
1) EA 정보를 구축하는 방법은 상향식과 하향식이 있다.
2) 상향식 방식은 조직의 모든 업무가 포함되는 것을 보장할 수 있는 장점이 있는 반면 상위 업무 기능 분류의 수준이 서로 다르게 나타날 수 있는 단점이 있다.
3) 하향식 방식은 관점이 명확한 장점이 있는 반면 일부 구성요소가 누락될 수 있는 단점이 있다.
#현행 아키텍처 정보 구축에 대한 설명
1) 현행 아키텍처는 현재의 업무나 정보시스템에 대하여 기존의 자료를 분석하여 EA 정보를 구축한다.
2) 현행 아키텍처는 상위 수준의 업무기능과 시스템에 대한 분류체계를 정의 한 후 나머지 하위의 정보
구축은 병렬적으로 수행할 수 있다.
3) 현행 아키텍처는 조직의 EA 도입 목적을 고려해서 정의될 정보수준을 결정하는데 현행 아키텍처 중심의 EA 프로젝트인 경우 현행 아키텍처에 대해서는 아키텍처 매트릭스에 정의된 산출물을 모두 정의하는 것이 바람직하다.
#EA 관리 시스템에 대한 설명
1) EA 관리시스템을 활용하면 아키텍처 정보를 공유할 수 있어서 해당 조직의 각 EA 아키텍처 요소를 이해 관계자들이 정확하게 파악할 수 있다.
2) EA 관리 시스템은 현업과 IT과 공유할 수 있는 모델을 제공함으로써 현업과 IT의 의사 소통시에 오류를 줄일 수 있다.
3) EA 관리 시스템을 활용하면 업무와 IT 서비스간의 차이분석을 할 수 있다. 또한 현행 아키텍처와 목표 아키텍처간의 차이분석을 손쉽게 할 수 있어 시스템 개선에 대한 빠른 의사 결정을 내릴 수 있다.
#EA의 관리체계를 정착시키기 위해서 고려되어야 할 사항
1) 정의된 EA 조직체계, 프로세스 체계 등을 문서화 하여 전 조직이 준수할 수 있도록 제도화 한다.
2) EA 관련 제반 이해 당사자의 EA 인지도 향상 및 업무수행 시에 EA 정보 활용도 증진을 위해서
적절한 교육 프로그램을 제공한다.
3) EA 관리체계를 주기적으로 점검하고 개선점을 도출하여 반영할 수 있는 제도적 장치를 마련한다.
#EA 관리 조직의 정의에 대한 설명
1) EA 관리조직을 별도 조직으로 구성할 수 없는 중소 규모의 경우 반드시 전담조직을 운영할 필요는 없다.
2) EA 정보를 관리하는 전문조직은 조직의 규모가 있을 경우 아키텍처 영역별로 정의하는 것이 바람직하다.
3) EA 구축의 목적이 신 시스템 구축을 위한 계획 수립이라면 PMO(Project Management Office)와
EA 관리 전담 조직을 동시에 정의하는 것이 바람직하다.
4) EA 관리조직은 계획자 수준에서 실무자 수준까지 다양한 시각에서 책임과 역할이 명확히 정의되어야한다.
# EA 관리시스템의 핵심 구성요소
1) EA 정보를 생산하는 모델링 도구
2) EA 정보를 저장 관리하는 EA 레파지토리(Repository)
3) EA 정보를 활용하는 EA 포탈
#EA 정보의 활용 사례로서 IT 업무에 대한 설명
IT 기획관리 : 업무프로세스 혁신, 정보화 계획 수립
IT 구축관리 : 프로젝트 계획, 시스템 개발
IT 운영 및 통제 : 시스템 운영, IT 통제
#EA를 정보를 효과적으로 활용되기 위해서 고려되어야 할 사항
1) EA 정보의 품질이 보장되어야 한다.
2) EA 정보를 관리하고 통제할 수 있는 전담 조직이 구성되고 운영되어야 한다.
3) EA 정보를 전사적으로 공유하고 활용할 수 있는 절차와 시스템이 필요하다.
#EA정보를 효과적으로 활용하기 위한 필요사항
1) EA 정보자체의 품질이 보장되어야 하고 현행 및 목표시스템의 아키텍처 정보를 항상 최신의 상태로 유지한다.
2) EA 정보를 관리하고 적용을 통제할 수 있는 전담 조직이 구성, 운영 되어야한다.
3) EA 정보를 전사적으로 공유하고 활용할 수 있는 절차와 시스템이 필요하다.
#데이터아키텍처 담당자로써 회사에서 수행해야 하는 역할
1) DA 담당자로써 DA를 정의하는데 있어 회사에서 정의한 EA 정보와 항상 연계하여 생각한다.
2) EA에서 정의된 원칙과 정보를 이해하고 준수해야 하며, 데이터아키텍처 영역에서 구체화할 수 있는 것은 더 상세화 시킨다.
3) 데이터 부문에서 발생하는 변경사항이 EA 정보에 적절히 반영될 수 있게 한다.
#EA 정보의 핵심적 활용
1) 정보화 계획 수립 : 정보화 전략 계획 수립 시에 활용할 수 있으며, 중복을 배제한 효과적인 시스템 투자 계획 수립에 활용한다.
2) 시스템 개발 : 기존시스템 개선과 신규시스템 개발을 위한 기준 및 참조 정보를 제공하며, 시스템 간의 연계성 및 재사용 대상을 식별할 수 있다.
3) IT 통제 : 도입되는 시스템의 전사 표준에 대한 준수 여부를 통제함으로써 상호운용성, 유지보수 편리성 등을 확보할 수 있다.
#EA와 관련하여 DA가 이루어야 할 3가지 통합성
1) EA 범위 전체에 대한 각 모델 내의 불일치성을 제거한다.(범위 통합성)
2) 관련된 타 도메인(업무, 데이터, 애플리케이션, 기술 등)과의 불일치성을 제거한다.(수평 통합성)
3) 관련된 관점(계획자, 책임자, 설계자, 개발자 등)간의 불일치성을 제거한다.(수직 통합성)