DA 가이드

DA, SQL, DB보안 등 실무자를 위한 위한 DB기술 바이블!

전사아키텍처 프레임워크

작성자
admin
작성일
2021-02-10 11:09
조회
9669

전사아키텍처 프레임워크 개념

기업이 전사아키텍처를 정의하여 관리하기 위해서는 우선 전사아키텍처를 어떻게 표현하고 운영 할 것인가에 대한 전체적인 사고의 틀을 결정해야 한다. 전사아키텍처 프레임워크는 전사아키텍처 활동에서 얻어지는 산출물을 분류하고 조직화하고 이를 유지 관리하기 위한 전체적인 틀을 정의하는 것이다.

전사아키텍처 수립을 위해서는 먼저 이러한 전사아키텍처 프레임워크를 정의해야 하는데, 이미 여러 선진 모델이 나와 있고 정부에서도 가이드를 제시하고 있어, 기관이나 기업은 이를 참조할 수 있다. 하지만, 무조건적인 적용보다는 기업의 특성에 따라 적합한 형태로 정의할 필요가 있다.


전사아키텍처 프레임워크 구성

전사아키텍처 프레임워크는 여러 참조 모델이 있다. 우선 전사아키텍처 프레임워크를 좀더 명확히 이해하기 위해서 국내에서 비교적 일반적으로 적용되고 있는 전사아키텍처 프레임워크의 한 사례를 기준으로 전사아키텍처 프레임워크의 구성을 살펴본다.

그림[1-1-4]에서 보면, 전사아키텍처 프레임워크는 전사아키텍처 정책, 전사아키텍처 정보, 전사아키텍처 관리 등의 3가지 영역으로 구분된다. 전사아키텍처 정책은 기업이 전사아키텍처 수립을 어떻게 할 것인가의 방향을 정의한 것으로 아키텍처 매트릭스, 전사아키텍처 비전, 전사아키텍처 원칙 등으로 구성된다. 전사아키텍처 정보는 기업이 구축하는 전사아키텍처 정보의 구체적인 모습으로 현행 아키텍처, 목표 아키텍처, 이행 계획으로 구성된다. 전사아키텍처 관리는 구축된 전사아키텍처를 어떻게 관리하고 활용할 것인가를 정의한 것으로 전사아키텍처 관리 체계, 전사아키텍처 관리 시스템, 전사아키텍처 평가 모형 등으로 구성된다.

[그림 1-1-4] 전사아키텍처 프레임 워크 구성 예


전사아키텍처 정책

기업이 전사아키텍처를 구축하기 위해서는 먼저 기업의 전사아키텍처 구축 목적과 방향을 정의해 야 한다. 전사아키텍처 정책은 전사아키텍처의 정보를 어떻게 구성할 것이고, 전사아키텍처 수립을 통하여 기업이 달성하고자 하는 궁극적인 모습은 무엇이며, 전사아키텍처를 효과적으로 관리하고 활 용하기 위한 원칙은 어떤 것인지 등을 정의하는 것이다.


아키텍처 매트릭스

아키텍처 매트릭스는 전사아키텍처의 정보를 체계적으로 분류한 틀로서, 기업이 관리하려고 하는 전사아키텍처 정보의 수준과 활용 계층을 결정하는 수단이다.

[표 1-1-2] 아키텍처 매트릭스 예


뷰(View)/ 관점(Perspective) 비즈니스 아키텍처 애플리케이션 아키텍처 데이터 아키텍처 기술 아키텍처
계획자 (개괄적) 전체 업무, 조직의 구성 정보 전체 차원의 응용 시스템 구성 정보 전체 차원의 데이터베이스 구성 정보 기술 요소의 구성을 전체 차원에서 정리한 정보
- 전사 사업 모델
- 조직 모델
- 비즈니스 전략
- 전사 애플리케이션 영역 모델
- 애플리케이션 원칙
- 전사 데이터 영역 모델
- 데이터 원칙
- 전사 기술 영역모델
- 기술 참조 모델
책임자/분석자
(개념적)
업무의 세부 구성 정보와 업무/조직 간 관계 정보 상위 수준의 기능 구성 정보와 응용시스템 간 관계 정보 데이터베이스에서 관리되는 주요 데이터 개체와 개체 간 관계 정보 기술 기반 자원의 유형별 구성과 인터페이스 정보
- 업무 기능 모델 - 애플리케이션 모델
- 애플리케이션 표준
- 개념 데이터 모델
- 데이터 표준
- 표준 프로파일
설계자 (논리적) 업무의 연계성, 흐름 정보 응용 시스템의 상세한 기능 정보와 물리적 분산 정보 데이터베이스의 논리적 데이터 구조 기술 기반 자원의 도입과 운영을 위한 유형별 구조 및 관리 체계 정보
- 프로세스 모델 - 컴포넌트 모델 - 논리 데이터 모델 - 기술아키텍처 모델
개발자
(물리적)
업무 수행을 위한 구체적 절차, 양식, 업무 관계 정보 프로그램의 물리적인 구성 체계와 각 프로그램 구현 정보 데이터베이스의 물리적 구조 정보 도입된 기술 기반 자원의 도입, 운영, 관리에 관한 구체적 정보
- 업무 매뉴얼 - 프로그램 목록 - 물리 데이터 모델 - 데이터베이스 객체 - 기술 자원 목록 - 제품 목록

아키텍처 매트릭스는 일반적으로 뷰와 관점의 두 차원으로 전사아키텍처 정보를 구분하고, 뷰와 관점이 교차하는 각 셀에는 전사아키텍처 정보의 실체가 되는 산출물을 정의하는 구조이다. 아키텍처 매트릭스에서 좌우로 바라보는 것을 뷰(View)라고 하고, 위에서 아래로 바라보는 것을 관점(Perspective)이라 한다. 일반적으로 뷰는 비즈니스, 애플리케이션, 데이터, 기술 등으로, 관점은 계획자, 책임자(또는 분석자), 설계자, 개발자 등으로 분류한다. 각 셀은 전후 좌우의 셀과 연관성을 가지며, 셀 간의 추적성이 확보되어야 한다.


전사아키텍처 비전

전사아키텍처 비전은 전사아키텍처 수립을 통하여 기업이 궁극적으로 달성하고자 하는 모습이다. 전사아키텍처 비전에는 전사아키텍처 구축의 목표와, 그 목표를 효과적으로 달성하기 위한 전략과 방향 등을 포함한다.


전사아키텍처 원칙

전사아키텍처 원칙은 전사아키텍처 정보를 효율적으로 구축하고, 기업의 목적에 맞게 전사아키텍처 정보를 효과적으로 활용하기 위해서 조직 구성원이 공유해야 할 규범을 말한다. 전사아키텍처 원칙은 전사아키텍처 대원칙, 아키텍처 원칙, 표준 등을 포함한다.


전사아키텍처 정보

전사아키텍처 구축을 위해서는 아키텍처 매트릭스에서 정의한 각 아키텍처 산출물에 대하여 현재 상태와 목표 상태의 정보를 구축한다. 그리고 목표 아키텍처를 달성하기 위한 이행 계획을 수립한다. 아키텍처 정보를 구축하기 위해서는 우선 아키텍처 정보의 영역을 구분해야 하는데, 이런 아키텍처 영역을 구분한 것을 아키텍처 도메인(Architecture Domain)이라 한다. 정확히 말하면, 아키텍처 도메인이란 아키텍처 매트릭스 상에서 뷰의 관점으로 아키텍처 영역을 구분한 것을 말한다. 현행 아키텍처와 목표 아키텍처는 이런 아키텍처 도메인별로 아키텍처 정보를 구축한다.

[그림 1-1-5] 아키텍처 도메인 예


헌행 아키텍처

아키텍처 도메인별로 정의된 산출물에 대하여 기업의 현재 상태를 아키텍처 정보로 정의한 것을 말한다.


목표 아키텍처

아키텍처 도메인별로 정의된 산출물에 대하여 기업이 궁극적으로 달성하고자 하는 목표 아키텍처의 상태를 아키텍처 정보로 정의한 것을 말한다.


전사아키텍처 이행계획

아키텍처 도메인별로 현재 모습에서 바람직한 목표 모습으로 이행하기 위한 이행 전략과 이행계획을 정의한 것을 말한다.




[Tip] ----------------------------------------------------------------------------------------

비즈니스, 업무, 사업 :
‘비즈니스’란 용어는 원어로‘Business’이다. 우리나라 말로 번역하면‘사업’또는‘업무’로 표현할 수 있다. 사업이란 용어는 전사 차원의 경영과 관련된 어감이 강하고, 업무란 실무적 차원의 업무 활동에 관련된 어감이 강하다. 비즈니스는 사업과 업무를 포함하는 포괄적인 의미를 가진다고 할 수 있다. 하지만 이 책에서는 비즈니스와 업무를 특별히 구분하지는 않는다. 주로 비즈니스라는 용어를 사용하겠지만, 정부의 참조 모델 관련 내용에서는 업무라는 용어를 그대로 사용한다.

애플리케이션, 응용 :
‘애플리케이션’이란 용어는 원어로‘Application’이다. 우리나라 말로 번역하면 응용이라고 표현할 수 있다. 애플리케이션과 응용을 같은 의미라고 할 수 있다. 이책에서는 업계에서 많이 사용하고 있는 애플리케이션을 사용하겠지만 정부의 참조 모델 관련 내용에서는 응용이라는 용어를 그대로 사용한다.

---------------------------------------------------------------------------------------------


일반적으로 아키텍처 도메인은 비즈니스 아키텍처, 애플리케이션 아키텍처, 데이터아키텍처, 기술 아키텍처 등으로 구분한다. 비즈니스아키텍처는 조직의 목적 및 임무를 지원하기 위해 수행하는 업 무를 분석하고, 이를 업무 활동 단위로 분할하여 표현한 아키텍처이다. 둘째, 데이터아키텍처는 효과 적인 업무 처리 및 의사결정을 위해 어떤 정보가 사용되고, 전달되어야 하는지를 표현한 아키텍처로 서, 전사 데이터 구성을 분류하고 데이터 모델을 정의하는 것이다. 셋째, 애플리케이션아키텍처는 조 직의 임무를 수행하는 데 필요한 애플리케이션의 기능 및 이들 간의 관계 등을 정의한 것으로, 기업 의 애플리케이션 단위를 분류하고 애플리케이션 간의 인터페이스를 정의한 아키텍처이다. 마지막으 로 기술아키텍처는 비즈니스아키텍처, 데이터아키텍처, 애플리케이션아키텍처를 지원하는 데 필요 한 정보 기술 인프라 요소 및 구조, 그리고 이들 간의 관계를 표현한 아키텍처로서, 전사의 기술 영역 을 분류하고 표준 프로파일과 기술 아키텍처 모델을 정의한 것이다.


전사아키텍처 관리

정의된 전사아키텍처 정보를 지속적으로 유지 관리하고 효과적으로 활용하기 위해서는 전사아키텍처 관리 체계의 정립과 전사아키텍처 관리 시스템의 구축이 필요하다. 또한 전사아키텍처 관리 수준을 제고하기 위해서는 지속적으로 평가하고 개선할 필요가 있다.


전사아키텍처 관리 체계

전사아키텍처 관리 체계는 흔히‘전사아키텍처 거버넌스’라고 말하기도 한다. 이것은 구축된 전사 아키텍처를 유지하고 개선하기 위한 제도적 기반을 수립하는 것이며, 정의된 전사아키텍처 원칙을 준수하도록 확인하고 통제하기 위한 조직과 프로세스를 정의하는 것을 포함한다. 전사아키텍처 관 리 체계는 전사아키텍처 활동을 관리하며, 전사아키텍처의 정보 변경을 통제하고, IT 프로젝트가 전사아키텍처의 기본적인 원칙과 정책을 준수하도록 하기 위한 목적이 있다.


전사아키텍처 관리 시스템

전사아키텍처 관리 시스템은 전사아키텍처의 정보 관리의 효율성을 제고하고 전사아키텍처 정보의 공유를 활성화하기 위해 구축하는 정보시스템이다. 전사아키텍처 관리 시스템은 도입하는 기업의 요건에 따라 다양한 형태로 구성될 수 있는데, 일반적으로 전사아키텍처 정보를 정의하는 모델링 도구와 전사아키텍처 정보를 저장하는 전사아키텍처 리포지터리, 전사아키텍처 정보를 사용자에게 배포하는 전사아키텍처 포털 등으로 구성된다.


전사아키텍처 평가

전사아키텍처의 관리와 활용 수준의 제고를 위해서는 전사아키텍처에 대해 주기적으로 평가하고, 개선점을 도출하여 반영해야 한다. 이를 위해서는 전사아키텍처의 수준을 객관적이고 정확하게 평가할 수 있는 전사아키텍처 성숙 모형이 필요하다.


아키텍처 도메인 구성

아키텍처 도메인의 구성은 기업이 아키텍처 매트릭스를 어떻게 정의하느냐에 따라 다르다. 이 절에서는 아키텍처 도메인에 대해서 이해를 좀더 깊이 하기 위하여 국내 기업에서 비교적 일반적으로 활용되고 있는 아키텍처 도메인별 구성내역을 살펴본다. [표 1-1-1] 아키텍처 매트릭스를 기준으로 설명한다.

[그림 1-1-6] 아키텍처 도미엔별 산출물 예

급변하는 비즈니스 환경에 대한 적응성을 높이기 위해서는 정보기술이 철저하게 비즈니스 전략과 연계되어야 한다. 데이터아키텍처는 비즈니스아키텍처에서 정의한 업무를 지원하기 위해 필요한 데 이터를 정의해야 하고, 애플리케이션아키텍처는 비즈니스 업무를 수행하기 위해서 필요한 애플리케 이션을 정의해야 한다. 기술아키텍처 역시 이러한 비즈니스를 지원하는 데이터 및 애플리케이션아키 텍처를 잘 지원하기 위한 기술적 특성을 감안하여 정의되어야 한다.


전사 사업 모델 (계획자 관점)

비즈니스 아키텍처는 먼저 아키텍처 정보를 구축하는 대상인 전사(Enterprise)의 범위를 정의하는 것에서부터 시작한다. 전사를 둘러싼 내외부의 이해관계자를 분석하고, 외부 객체와의 가치사슬을 분석하여 전사를 정의한다. 전사의 정확한 가치사슬을 분석하기 위해서는 외부 객체의 가치사슬과의 연관 관계를 파악하여 어떤 기능들이 외부객체에 의해서 수행되고, 외부객체의 어떤 기능을 전사 내부가 수행하고 있는지 분석해야 한다.

[그림 1-1-7] 전사 가치사슬 예


조직 모델 (계획자 관점)

조직 모델은 기업의 사업 모델을 지원하기 위한 기업의 조직 구조를 정의하는 것이다. 비즈니스를 수행하는 지리적 위치와 내부 객체를 도출하여 기업의 조직 구조와 업무 분장을 정의한다.


업무 기능 모델 (책임자 관점)

업무 기능 모델은 기업의 업무 기능을 계층적으로 분할하고 기능 내용을 정의하는 것이다. 업무 기 능을 분할할 때는 조직 기준이 아닌 업무 기능의 유사성과 연관성을 기준으로 정의한다. 상위 업무 기능은 하위 업무 기능의 합으로 완전히 표현될 수 있어야 한다. 업무 기능 모델링은 데이터와 애 플리케이션의 상호 비교를 통한 연관 분석이 이루어진다.


프로세스 모델 (설계자 관점)

프로세스 모델은 업무 기능을 상세화하여 계층적으로 프로세스을 분할하고 프로세스의 활동내용을 정의하는 것이다. 프로세스란 업무 수행을 위해 정보를 입력 받아 의미있는 활동을 통해 산출물을 생성하는 일련의 과정이다. 프로세스 모델 역시 데이터와 애플리케이션과 상호 비교를 통한 연관분석이 반복적으로 이루어진다.


업무 메뉴얼 (개발자 관점)

업무 기능이나 프로세스별 업무 내역을 상세히 기술한 자료로, 전사아키텍처에서는 목록 수준의 정보를 관리한다.


애플리케이션아키텍처

애플리케이션 아키텍처는 기업의 업무를 지원하는 전체 애플리케이션을 식별하고 연관성을 정의 하며, 업무와 IT 특성을 고려하여 그룹화하고 범주함으로써 전체 애플리케이션 구조를 체계화하는 것이다. 애플리케이션 서비스는 애플리케이션이 지원하는 업무와 데이터의 특성을 고려하여 정의되 며, 서비스 간의 상호 연관관계를 분석 정의한다. 이는 향후 애플리케이션에 대한 배치, 통합, 포트 폴리오 관리를 위한 시각을 제공한다.


전사 애플리케이션 영역 모델(계획자 관점)

기업의 업무를 지원하는 애플리케이션을 식별하고 애플리케이션별 특성 분석을 통해 이를 전사 수 준에서 구조화하는 것이다. 애플리케이션의 기능과 특성에 따라 독립되어 구현되고 운영될 수 있 는 애플리케이션을 정의하고, 애플리케이션과 관련된 업무, 데이터와 IT 특성을 감안하여 애플리 케이션을 그룹화하여 애플리케이션 영역을 정의한다.


애플리케이션 모델(책임자 관점)

애플리케이션 모델은 각 애플리케이션이 지원하는 기능과 데이터 정보를 정의하고, 애플리케이션 이 제공하는 서비스를 도출하며, 이들 간의 연관 관계를 정의한 것이다. 애플리케이션이나 서비스 가 어느 업무 프로세스에서 활용되고, 어떠한 정보를 생산하고 관리하는지 연관성 분석을 한다. 애 플리케이션 모델의 정의는 개발 방법론에 의존적이다.


컴포넌트 모델, 클래스 모델(설계자 관점)

실제 애플리케이션 개발에 필요한 설계 정보를 관리하는 것으로, 컴포넌트 정의나 클래스 정의, 데 이터 흐름도(DFD, Data Flow Diagram) 등이 해당되며 기업의 개발 방법론에 영향을 많이 받는 다. 기업이 가지고 있는 업무 영역별로 애플리케이션의 개발 환경은 상이할 수 있다. 예를 들면 정 보계는 컴포넌트 기반 개발(CBD, Component Based Development) 방법론을, 운영계는 메인 프레임 중심의 구조적 방법론을 사용할 수 있다.


프로그램 목록(개발자 관점)

애플리케이션의 최종 단위인 프로그램에 대한 정보를 관리한다.


데이터아키텍처

데이터아키텍처는 기업의 업무 수행에 필요한 데이터의 구조를 체계적으로 정의하는 것이다. 데이터아키텍처는 전사의 데이터 영역을 분류하는데, 업무 데이터와 메타 데이터를 구분하거나 업무 데이터는 운영계 데이터, 정보계 데이터 등으로 구분한다. 이를 기준으로 전사 수준의 주제 영역 모델, 개념데이터 모델을 정의하고, 영역별로 논리 데이터 모델, 물리 데이터 모델을 정의한다.

참고로, 데이터아키텍처 전문가가 다루는 데이터아키텍처의 범위는 데이터 구조뿐만 아니라 데이터 표준, 데이터 관리 체계 등을 포함하는 광의의 데이터아키텍처를 의미한다.(아키텍처 의미 아키텍처 정의를 참조, 데이터아키텍처 전문가의 영역에 대해서는 전사아키텍처 관리 및 활용> 전사아키텍처 활용의 5.전사아키텍처와 데이터아키텍처 전문가 영역 참조)


전사 데이터 영역 모델 (계획자 관점)

전사 데이터 영역 모델은 개괄 데이터 모델이라고도 하며 상위 수준의 전사 데이터 영역을 분류하여 표현한 것이며, 상위 주제 영역 수준의 데이터 구성도가 이에 해당된다. 주제 영역은 업무 기능과 대응되는 개념으로 유사 데이터를 그룹화 한 것이다.


개념 데이터 모델 (책임자 관점)

개념 데이터 모델은 전사 수준의 데이터 모델로 단위 주제 영역 또는 핵심 엔터티 정도를 표현한 데이터 모델이다. 개념 데이터 모델은 전사 수준에서 사용하는 데이터를 전체적으로 표현할 수 있 는 기본 틀로서, 전사 데이터아키텍처를 관리하는 데 있어 매우 유용한 모델이다. 개념 데이터 모 델에서는 핵심 엔터티는 일반적으로 단위 주제 영역별로 한두 개가 정도가 도출된다.


논리 데이터 모델(설계자 관점)

논리 데이터 모델은 개념 데이터 모델에서 정의된 주제 영역과 핵심 엔터티를 기본 정보로 하여 업 무 요건을 충족시키기 위한 데이터의 상세한 구조를 논리적으로 구체화한 것이다. 논리 데이터 모 델링은 수집된 업무 관련 데이터 정보 및 사전에 작성된 산출물을 기반으로 필요한 모든 엔터티를 도출하고, 식별자, 속성, 관계와 서브타입 등을 정의한다. 논리 데이터 모델은 엔터티, 속성에 대 한 명칭, 정의, 형식, 규칙, 코드 등을 전사적인 차원의 표준으로 정의하여 관리해야 한다.


물리 데이터 모델(개발자 관점)

물리 데이터 모델은 기술적 환경과 특성을 고려하여 물리적 데이터 구조를 설계하고, 데이터베이 스 객체를 정의한 것이다. 개발자는 논리 데이터 모델을 물리적인 데이터 구조로 전환하고 데이터 무결성을 보완하여 정의하고, 데이터 분산 설계에 따른 데이터 무결성 등 추가적인 무결성 규칙을 정의한다. 데이터베이스의 성능을 고려하여 이미 설계된 데이터 구조에 추가적으로 데이터의 접근 성능 향상을 위한 인덱스 설계, 데이터 구조에 대한 비정규화 과정을 수행한다.


기술아키텍처

기술아키텍처는 비즈니스, 데이터, 애플리케이션 아키텍처에서 정의된 요건을 지원하는 전사의 기 술 인프라 체계를 정의하는 것이다 기술 인프라는 하드웨어, 시스템 소프트웨어, 통신 네트워크, 시 스템 개발도구, 시스템 관리도구, 최종 사용자 소프트웨어 등을 포함한다. 기술 참조 모델과 표준 프 로파일 구축을 통해 애플리케이션의 이식성과 확장성을 강화하고, 벤더로부터의 독립성을 확보하며, 시스템 간의 상호운용성을 강화하는 등의 효과를 기대할 수 있다. 기술아키텍처의 경우 다른 아키텍 처와 달리 개별 기업에서도 기술 참조 모델을 정의하는 것이 일반적이다. [표 1-1-2] 아키텍처 매트 릭스에서 기술 참조 모델을 계획자 수준의 산출물로 포함한 것도 그런 의미라고 판단하면 된다.


전사 기술 영역 모델, 기술 참조 모델(계획자 관점)

전사 기술 영역 모델은 기업이 업무활동에 필요한 정보기술의 영역을 상위 수준에서 분류한 것이다. 기술 참조 모델(TRM, Technical Reference Model)은 기업이 업무 활동에 필요한 기능들을 수행하기 위해 요구되는 정보기술을 상위 수준에서 논리적으로 분류한 틀인데, 전사 기술 영역 모델과 같은 범주로 볼 수 있다. 다만 기술 참조 모델은 일반적인 표준을 최대한 수렴해 정의하는 것이 특징이라고 할 수 있다.

[그림 1-1-8] 기술 참조 모델 예


표준 프로파일(책임자 관점)

표준 프로파일(SP, Standard Profile)은 기술 참조 모델에 명시된 서비스를 지원하기 위한 정보기술 표준들의 집합이다. 기업의 모든 기술 아키텍처 요소들에 영향을 미치는 표준들을 포함한다. 이 표준들은 시스템의 이식성, 확장성, 상호운용성, 호환성을 제고하게 된다. 일반적으로 표준 프로파일은 기술표준을 프로파일의 대상으로 하며, 최근에는 제품을 프로파일링 대상에 포함시키는것이 추세이다.


기술 아키텍처 모델

기술 아키텍처 모델은 전사 기술 영역 모델이나 기술 참조 모델에서 정의된 서비스 카테고리별로 아키텍처의 패턴을 정의하거나, 기업의 소프트웨어, 하드웨어, 네트워크 등의 구성 요소에 대한 배치도를 정의하는 것이다.


기술자원 목록, 제품 목록

표준 프로파일이나 기술 아키텍처별로 관련된 기술자원 목록이나 제품 목록을 기술 아키텍처 정보로 관리한다.


전사아키텍처 프레임워크 사례

전사아키텍처 프레임워크로 참조할 수 있는 모델은 다양하다. 자크만 프레임워크(ZEAF)를 비롯하여, 미연방정부 프레임워크(FEAF), 미재무성 프레임워크(TEAF), 미국방성 프레임워크(DoDAF), 오픈그룹 프레임워크(TOGAF), 한국정보 프레임워크 등이 대표적인 사례이다.

예를 들면 자크만 프레임워크(ZEAF)는 다섯 가지 관점(Planner, Owner, Designer, Builder, Sub-contractor)과 각 관점에 따르는 여섯 가지 묘사 방법(Data, Function, Network, People, Time, Motivation)을 정의하고 있다. 전사아키텍처 프레임워크의 대표적인 예로서 많은 다른 전사아키텍처 프레임워크에서 참조되고 있다.

[표 1-1-3] 전사아키텍처 프레임워크 예


ZEAF FEAF TEAF DoDAF TOGAF 공공부분EAF
구성도 구성도 ZEAF 구성도 FEAF 구성도 TEAF 구성도 DoDAF 구성도 TOGAF 구성도 공공부분EAF
특징 - 1980년대 말 기업활동을 공학적 관점에서 파악하는 아키텍처 개념 최초 소개
- 기업 활동을 5W1H의 관점에서 모델링 관점 제공
- 2003년에 최신 버전 발표, 미연방정부 프레임워크 가이드 라인제공
- 참조 모델 기반의 EAF
- 미 재무성 EAF - FEAF, DoDAF와 함께 대표적 EAF .효과적 작전 수행을 위해 무기 체계 간 상호운용성 보장을 위해 도입된 EAF
- 상호운용성 분석과 향상을 위해 LIBI 분석
- 민간 표준 연합인 오픈그룹 EAF - 정부, 공공기관에 전사아키텍처 도입시 참조할 수 있도록 표준, 가이드 목적으로 추진
장점 - 5W1H에 따라 기업활동을 상세하게 모델링할 수 있는 관점 제공
- Planner, Owner, Designer, Builder, Sub-contractor 관점에서 기업 활동 관심영역을 구체화
- 모델링 관점뿐만 아니라 구체적 이행 계획을 프레임워크에 포함
- BRM, DRM, SCRM, TRM, PRM등 다양한 참조 모델 활용
- How-Where-When을 표현하는 기능, What-How much-How Freq 를 표현하는 정보, Who-Why를 표현하는 조직, Enable를 표현하는 인프라 관점 중시 - 산출물에 대한 템플릿을 상세하게 정의하여 통일되고 검증된 방식으로 모델링 가능
- 운영 모델에 대한 상세한 정의 및 표현 양식 제공
- 구체적 아키텍처 개발 프로세스 제안 - 각종 참조 모델의 활용관계를잘정의함 - 전사아키텍처 관련된 거의 모든 항목을 프레임워크에 포함하여 기본 프레임워크로 활용하기 용이
단점 - 정보화 측면에서 활용도 떨어지는 부문까지 정의
- 모델링 표현에 지나치게 집중, 실제 아키텍처 활동 계획 및 기반 정의 부족
- 아키텍처 모델의 이해 및 진화에 대해 잘 정의되어 있으나, 조직 및 관련 규정등 제반 요소의 진화적 관점부족 - 전사아키텍처 산출물 중심의 프레임워크로서 활용에 대한 접근이 부족
- 기업의 계속적인 활동에 대한 관점이 부족
- 일반 기업 현장에서는 과도한 산출물과 정확도를 요구하고 있어 과잉 투자 가능성 있음 - 메타 모델에 근거한 연속체 개념을 도입하여 아키텍처를 파악함으로써 조직의 특수성이프레임워크에 반영되기 어려움 - 표준 프레임워크만 제시하여 구체적인 내용들은 참조한 기관에서 작성하도록 권고

미재무성 프레임워크(FEAF)는 8개 구성요소로 이루어져 있고 4단계에 걸쳐 점차적으로 진행하여 마지막 단계에 자크만 프레임워크의 모델 내용을 모두 관리한다. 프레임워크에는 각 세그먼트별 접근법을 채택하여 현행과 목표의 갭분석을 통한 이행 계획과 프로세스를 포함하고 있다.

오픈그룹 프레임워크는 아키텍처를 정의하기 위하여 오픈그룹에서 개발한 아키텍처 개발에 대한 지침인 아키텍처 개발 방법(ADM, Architecture Development Method), 정보기술을 체계적으로 분류한 기술 참조 모델, 표준 요약 정보를 모아놓은 데이터베이스인 표준정보기반(SIB, Standard Information Base)으로 구성되어 있다. 빌딩블록 정의에 의한 접근 방식으로 구성 단위의 문제해결 방식을 제안하고 있다.

각각의 전사아키텍처 프레임워크들은 다른 점도 있지만, 공통점 또한 많다. 프레임워크를 정의할때 이러한 선진 모델을 참조하되 기업의 특성에 맞는 것을 만들어야 하며, 경직된 사고보다는 유연성을 가지는 것이 중요하다.