전사적 구조 프레임워크(EAF)

-EAF(Enterprise Architecture Framework)의 기획방법론과 개발 절차-

김진희/한국솔루션센터 이사·정보관리기술사

정보기술구조의 구성요소 중 하나인 전사적 구조를 구축하기 위한 지원도구로 프레임워크를 사용한다.
이와 관련해 전사적 프레임워크를 개발하기 위한 개발 방법 및 개발 절차를 미국의 연방정부 전사적 구조 프레임워크(FEAF: Federal Enterprise Architecture Framework)의 사례를 통해 짚어본다.

전사적 구조 프레임워크(EAF)

전사적 구조 프레임워크는 정보기술구조 개발 프로세스 수행시 전사적 구조를 개발하기 위한 정보자원으로서 사용되며, 연방 전사적 구조프레임워크(FEAF)와 표준기반구조(SBA: Standard Based Architecture) 등 이미 개발된 프레임워크가 있다.

▲연방 전사적 구조 프레임워크(FEAF Ver 1.1)

1995년 미국 클린턴 행정부는 관리예산국(OMB: Office of Management and Budget)을 통해 정보화 투자효과에 대한 평가를 실시했으나 기대에 미치지 못한 결과가 나왔고, 이는 정보시스템간 연계 및 정보 공유가 원활치 못한 부분이 주요 요인이라 인식하였다.

이러한 문제점을 개선하기 위해 OMB에서는 정보기술의 도입과 효율적 관리를 통한 조직과 행정의 혁신을 시도하면서 정보기술구조(ITA: Informa-tion Technology Architecture)를 개발하여 활용하기로 하였다. 이 작업의 결과로 1996년 OMB에서는 정보기술관리개혁법(ITMRA: information Technology Management Reform Act)을 제정하여 ITA를 이용한 정보기술관리에 강제성을 부여했고, 1997년에는 OMB Memorandum 97-16으로 ITA의 구체적인 내용(ITA는 EA, TRM&SP로 구성)을 명시하였다.

이 작업의 일환으로 연방정부에서는 행정규약 13011을 통해 기관의 정보자원 설계, 현대화, 사용, 공유, 그리고 성능을 향상시키기 위한 원칙적인 부처간 공개토론회로서 연방정부 정보화책임관(CIO) 협의회를 설치하였다.

연방정부 CIO협의회는 1998년4월 연방 전사적 아키텍처 프레임워크를 개발하기 시작했고, 1996년10월 정보기술관리개혁법의 우선순위에 따라 CIO협의회 전략적 계획(Strategic Plan)은 정부안에 있는 정보기술의 이익을 극대화하기 위해 연방정보구조의 개발과 유지에 대한 방향을 제시하였다.

Strategic Plan에 의하여 부처간 업무라인을 가로지르는 우선순위를 갖는 아키텍처 또는 세그먼트들은 연방 전사적 아키텍처를 정착시키기 위해서 개발되었고, 프레임워크는 공통 업무영역에서 선택된 높은 우선순위 영역에 대한 묘사와 조직간 업무경계를 가로지르는 설계에 있어서 아키텍처를 식별하고 개발하고 문서화하기 위한 지속적인 메카니즘을 제공한다.

연방 전사적 아키텍처 프레임워크의 목적은 공통 연방프로세스, 상호운용성, 그리고 연방기관과 다른 정부기관들 사이에 정보공유를 위하여 공통적인 개발을 증진시키는데 있다. 연방 공동 도구는 공통 아키텍처 정보를 모으고 이러한 정보를 저장하기 위한 저장소를 만들기 위해 필요하다. 연방 전사적 아키텍처 프레임워크는 도구나 저장소와 같은 것이다.

▲접근방법

연방CIO협의회는 연방 전사적 아키텍처 프레임워크를 개발하는데 있어서 접근 방법을 다음의 3가지로 구분하였다.

① 전통적인 접근방식: 이 방식은 시간과 비용의 상당한 초기 투자를 필요로 한다. 우선 아키텍처의 설명이 어떻게 구성되는지 보여주기 위하여 프레임워크가 반드시 개발돼 있어야 한다. 둘째로 현재의 기준선이 반드시 설명되어 있어야 한다. 마지막으로 목표 아키텍처가 반드시 설명되어 있어야 한다. 이러한 준비활동이 완료되고 나면 이를 실제로 시행하기 위한 시스템의 설계, 개발, 획득을 통한 아키텍처의 변경이 필요하게 된다. 비록 이 방법이 좋게 보일지는 몰라도 이런 노력의 복잡성 때문에 분석의 마비로 귀결될 것이다.

② 세그먼트(segment) 접근방식: 이 방식은 구조화된 전사적 아키텍처 프레임워크에서 아키텍처 세그먼트의 점진적인 개발을 촉진한다. 이 접근방식은 조직의 주요 업무영역(예를 들면 조달 또는 재무시스템 등)에 초점을 맞추고 있으며 특정 영역에 대한 공통된 기능 또는 특정 조직에서의 노력으로 좀 더 빠르게 성공할 수 있다.

③ 현상에 대한 접근방식: 이 방식은 일반적으로 업무를 정보공유에 대한 지속된 실패와 빠르게 변화하는 환경에 대한 대응으로 결론짓는다. 이 접근은 업무재생, 생산성 감소, 기회상실로 귀결된다.

▲프레임워크 구성요소

프레임워크를 설계함에 있어서 연방CIO협의회는 연방 전사적 아키텍처를 개발하고 유지하기 위해 필요한 여덟 가지의 구성요소를 식별한 후 점차적이고 세부적으로 전개하였다. <그림 1>은 최종적으로 완성된 전사적 아키텍처 프레임워크이며 각각의 구성요소에 대한 설명은 다음과 같다.

① 아키텍처 동기(Architecture Drivers): 전사적 아키텍처에 대한 외부 자극 또는 변화 요인으로서 업무동기, 기반동기의 두 가지 형태로 구분한다. 업무동기는 새로운 법률, 새로운 관리 시도, 부각되는 핵심 영역, 시장 지배력 확보를 위한 예산의 강화일 수 있다. 기반동기는 새롭고 강화된 소프트웨어, 하드웨어, 통신 등과 그것들의 조합에 대한 다양한 접근방식의 전개를 포함한다.

② 전략적 방향(Strategic Direc-tion): 목표, 목적, 비전, 원칙으로 구성된 목표 아키텍처로의 전개를 위한 기준이다.

③ 현재 아키텍처(Current Architec-ture): 현재(As-Is) 아키텍처의 정의로서 현재 업무 아키텍처와 현재 기반 아키텍처(데이터, 응용, 기반기술) 두 부분으로 구성된다. 조직의 현재 능력, 상태, 기술을 나타내며 세그먼트의 정의를 추가하는 방식으로 확장될 수 있다.

④ 목표 아키텍처(Target Architec-ture): 미래(To-Be Built) 전사적 아키텍처를 정의하며 목표 업무 아키텍처와 목표 기반 아키텍처(데이터, 응용, 기반기술)의 두 부분으로 구성된다. 변화하는 업무 요구사항을 지원하도록 강화된 기반에서 필요로 하는 미래의 능력과 기술을 나타낸다.

⑤ 변화 프로세스(Transitional Process): 현재에서 목표 아키텍처로의 이동을 지원한다. 조직의 주요한 변화 프로세스로는 자본 정보기술 투자 계획, 이전계획, 구성관리, 공학 변화 제어 등이 포함된다.

⑥ 아키텍처 세그먼트(Architectural Segments): 주요 공통 업무영역(공동 관리시스템 등), 프로그램 영역(교역, 인가 등), 전자상거래에서의 소액 구매 등과 같이 집중된 노력이 필요한 아키텍처의 일부분으로 구성되며 전체 전사적 아키텍처의 일부(세그먼트)를 나타낸다. 세그먼트가 전체 조직에서 하나의 조직으로 간주되는 경우도 있다.

⑦ 아키텍처 모델(Architectural Models): 전사적 범위에서 서술된 모든 세그먼트를 포함하는 업무 및 기반 모델을 정의한다.

⑧ 표준(Standards): 모든 표준(일부는 강제사항), 지침, 성공사례를 참조한다.

<그림1> 전사적 아키텍처 프레임워크 전사적 아키텍처 프레임워크 개발단계

▲프레임워크 개발 1단계

단계1은 전사적 아키텍처 프레임워크의 최상위 단계요한 여덟 가지 요소를 설명한다. 그 중 하나의 요소는 프레임워크의 외부에 있으며 일곱 가지의 요소는 프레임워크의 내부에 존재한다. 프레임워크의 흐름은 왼쪽에서 오른쪽으로 진행되며 전사적 아키텍처의 지속적인 고유의 과정을 표현한다. 여덟 가지의 기본 요소에 대한 내용은 연방구조에 설명되어 있다.

▲프레임워크 개발 2단계

단계2는 좀 더 상세한 단계로서 전사적 아키텍처의 업무 및 기반 부분들을 표현하고 그것들이 어떻게 관련되는지 보여준다. 수평적으로 보면 프레임워크의 위쪽 부분은 전사적에서의 업무 부분을 다루고 있으며 반면에 아래 부분은 업무를 지원하는 기반 아키텍처를 다루고 있다. 업무와 기반의 관계는 요구하고 지원하는 관계로서 업무 운용을 지원하는데 적용되는 새로운 서비스 제공을 위하여 업무는 기반(즉 데이터, 응용, 기반기술의 새로운 개발)을 요구하고 기반은 업무를 지원한다. 예를 들면 기반 동기로서 대중을 위한 인터넷, 전자적 접근 등을 들 수 있으며 이들은 업무의 임무를 지원하는 기반의 필요성을 생성한다.

▲프레임워크 개발 3단계

단계3은 세가지의 기반 아키텍처(데이터, 응용, 기반기술)를 보여주는 프레임워크의 기반 부분들로 확장된다.

▲프레임워크 개발 4단계

단계4는 업무 아키텍처와 기반 아키텍처의 세가지 아키텍처들(즉 데이터, 응용, 기반기술 아키텍처)을 설명하는 모델들을 식별한다. 또한 전사적 아키텍처 계획을 정의한다. 단계4는 세가지의 기반 아키텍처들에 의해 지원되는 업무 아키텍처를 어떻게 전개하고 명백하게 구축하는 가에 관한 내용이다.

전사적 아키텍처를 만드는 사람과 공학자들은 설명을 위한 일반적인 방법으로 모델을 사용한다. 대표적인 학자로는 John Zachman과 Steven Spewak이 있다. 아키텍처와 전사적 아키텍처 계획에 관한 확고한 개념을 가지고 있으며, 많은 연구를 통한 기반 개념들을 제공하고 있다.

단계4의 핵심은 일반적인 사항에서부터 방법들과 접근 방법들의 특정 집합까지의 변화를 표현하는 것이다.

John Zachman은 <그림 2>의 Zachman 프레임워크를 만들었으며 ‘정보시스템 아키텍처를 위한 프레임워크’의 저자이다. 이 Zachman 프레임워크는 그들을 지원하기 위한 조직과 시스템의 변화를 관리하기 위한 통합된 프레임워크로서 광범위하게 받아들여졌다. 조직에 적용될 때 Zachman 프레임워크는 조직시스템의 개발과 관리에 중요한 조직의 묘사적인 표현을 구성하고 식별하는 논리적인 구조이다.

Steven Spewak은 ‘전사적 아키텍처 계획(EAP)’, ‘데이터, 응용, 기술을 위한 청사진 개발’의 저자이다. 연방 전사적 아키텍처에 대한 그의 접근방법은 조직이 모델링, 업무 전략계획, 프로세스 투자, 테이터 저장소, 그리고 다양한 지원시스템 설계, 데이터 관리자 표준, 객체지향과 정보공학 방법론, 프로젝트 관리를 하는데 도움을 준다. 전사적 아키텍처 계획(EAP) 방법론은 단계4에서 연방 전사적 아키텍처 프레임워크의 정의를 이해하는데 장점이 있다.

한편 EAP는 무엇이 데이터, 응용, 기술 아키텍처에 적절한지를 정의하고 전 조직을 지원하는 것을 중점으로 한다.

<그림 3>은 이와 관련된 전환계획을 정의하기 위한 7가지의 구성요소를 보여준다. 7가지의 구성요소는 웨딩케익의 모양이며 각 주요임무에 대한 다른 초점을 나타낸다.

<그림2> Zachman 프레임 워크

<그림3> EAP 모델

결 론

투자 결정을 인도하기 위한 전사적 아키텍처는 일관성 없는 시스템 설계 및 개발에 대한 결정과 최적화가 덜된 성능결과 및 관련 비용을 막을 수 있는 체계적인 방법이다.

전사적 아키텍처가 미치는 영향은 조직간에 완전하고 일관된 정보를 공유하고 변화에 효과적으로 대응하게 하는 능력이다. 반면 전사적 아키텍처가 없으면 다음의 예와 같이 계속되는 다양한 현상과 징후로 인하여 이러한 노력이 힘들게 될 것이다.

① 정보 공유에 대한 무능력: 표준과 지침이 없다면 연방조직은 기술 매체(예를 들면 워드프로세싱 문서, E-메일, 데이터베이스, 번갈아 불필요한 사항을 요구하고 비용을 추가하는 기타 응용들)를 통하여 업무정보를 공유하는데 계속해서 어려움을 겪을 것이다. 지식 기반구조는 지식관리를 허용할 수 있을 정도로 적합한 위상에 있지 못한 것이 현실이다. 또한 사용자가 기대하는 전사적에 대한 좀 더 단순한 인터페이스도 어려울 것이다.

② 불완전한 정보: 조직이 전사적 아키텍처를 갖고 있지 않기 때문에 의사결정에 대하여(예를 들면 데이터의 적합한 적재량에 대한) 불완전한 정보가 계속해서 표준이 된다.

·전사적 업무정보는 기존의 독립적인 연통 시스템 때문에 불완전, 비조직화, 불필요성을 많이 갖게 돼 데이터 검색 또는 지식관리가 어렵다.

·정보기술 자본 계획 투자 정보는 현재의 전사적 아키텍처 환경, 진행중인 잘 조정된 정보기술 시장 연구, 목표 아키텍처에 대한 정보 등이 부족하기 때문에 불완전할 수밖에 없다. 현실적으로 개별기관들은 전자상거래, 인증, 스마트카드, 암호화, 기타 분야에서 다중의 해결책을 추구하고 있다.

·업무 및 설계에 관한 의사결정을 지원하는 전사적 아키텍처가 없다면 조직은 불완전한 정보로 인하여 본질적으로 다르고, 부적합하고, 비싼 결정을 하게 되는 증가하는 위험에 계속해서 직면한다. 이로 인하여 조직은 완전히 만족하지 못하게 되고 부족한 품질과 불완전한 데이터에 익숙해진다.

③ 변화에 대한 느린 반응: 아키텍처가 없다면 조직은 변화에 대한 자극에 계속해서 느리게 반응할 것이다. 그러나 공통의 구조는 전사적으로 다음과 같은 이익을 얻게 하였다.

·현재 아키텍처 정보를 평가함으로서 전사적 아키텍처의 영향 영역을 빠르게 식별.

·구현을 위한 데이터 표준을 빨리 정의하기 위해 전사적 아키텍처의 의사결정 부분을 활용함으로써 문제에 대한 빠른 봉쇄.

·지식에 근거한 현존하는 전사적 아키텍처의 의사결정 기반 구조를 통하여 행동으로의 빠른 이동.

전사적 아키텍처 프레임워크는 통신, 저장소 구조, 협동을 위한 조직화 메커니즘, 정보기술 투자계획과 의사결정을 더 효과적으로 하기 위한 지원에 대한 명확한 용어를 제공함으로써 각 세그먼트가 아키텍처 서술을 개발하고 유지하는데 도움을 줄 것으로 기대된다.

이들 프레임워크는 조직의 목적을 위하여 전사적을 정의한 전사적 아키텍처를 나타낸다. 세그먼트는 개별 조직이나 기관으로 언급되기도 하지만 세그먼트는 전사적에서 홀로 있을 수 없고 하나 이상 혹은 그 이상의 기타 다른 세그먼트와 상호 운용될 것이다.

전사적 범위 내에서의 조직은 조직 내부의 세부 조직이나 기관으로 더 협소하게 정의되고 프레임워크 모델에 기반한 동일한 접근법을 사용할 수 있다. 각 조직은 정보기술아키텍처를 구성할 필요가 있다.

전사적 범위 내에서의 조직은 전사적 프레임워크를 개별 조직의 유일한 필요성에 맞추거나 또는 맞추도록 수정할 수 있기 때문에 프레임워크의 사용을 선택할 수 있다. 프레임워크는 어떤 경우라도 바람직하기만 하다면 전사적 차원에서 수행하는 아키텍처 개발 노력의 활성화를 도울 수 있다.

자산관리 도구로서 프레임워크는 전사적 전략 정보 자산을 개발하고 관리하는데 사용할 수 있다. 전사적 전략 정보 자산은 조직의 현재와 목표 아키텍처에 대한 아키텍처 서술 즉 청사진이다. 이러한 자산이 아키텍처 세그먼트를 통하여 점차적으로 개발되면서 전사적 자산 기초에 더해진다.

프레임워용될 때 프레임워크는 독립적인 아키텍처 프로세스와 많은 전사적 세그먼트들의 활동을 지원할 수 있다.

프레임워크는 아키텍처 세그먼트의 점진적인 개발과 이러한 세그먼트를 개발하기 위한 공동작업을 지원하며, 공동작업은 전사적 세그먼트 내에서뿐만 아니라 전사적 세그먼트간에도 발생할 수 있다. 전사적 세그먼트는 자원 공유를 통한 동등한 공동작업으로 이득을 얻을 수 있다. 전사적 세그먼트는 공동작업을 통하여 지식과 서비스를 공유하고 규모의 경제를 이용할 수 있다.

결론적으로 전사적 아키텍처는 허황된 생각이고 시간과 노력을 낭비하는 것이라고 많은 사람들이 말한다. 그러나 축적되고 자발적인 노력이 설명하듯 조직의 정보화담당관(CIO)은 전사적 아키텍처를 생성하기 위한 사실적이고 재사용 가능한 접근법인 전사적 아키텍처 프레임워크를 정의해야 한다. 아키텍처 개발 조직은 전사에 걸쳐 식별된 문제점을 가지고 진행(예를 들면 비조직화된 해결책을 확립하는 것)을 계속한다면 현재까지 나타난 문제점(예를 들면 비 상호운용적이고 비싸고 지금까지의 데이터, 응용, 기술의 도발적인 얽힘)을 계속해서 소유하게 될 것을 확인한다. Larry P. English은 다음과 같이 언급하였다.

‘정보 품질 착수(사업)에 대한 비용의 정당성은 비품질 정보에 대한 비용을 분석하고 양을 측정함으로써 만들어진다. 조직은 현재 상태의 비용을 알아야 한다. 프로세스 실패, 업무의 재작업, 감소된 생산성, 불필요성 등으로 인한 비용은 업무수행을 위한 표준 비용으로 받아들여지고 있다.

이러한 관리에서 정보 수집과 개정, 프로세스 실패, 잃어버리거나 놓쳐버린 기회에 대한 비용으로 순익이 손상된다는 것을 인식할 때 변화가 이루어 질 것이다.’

제공 : DB포탈사이트 DBguide.net