EAP의 탄생 자크만이 1987년 처음 프레임워크 개념을 발표한 이후 EA 분야는 조용히 발전의 기틀을 다지고 있었다. 1990년대에 들어 몇 가지 중요한 진보가 시작됐는데 자크만의 프레임워크 확장, 기술참조모델(TRM)과 미국 국방성(DoD)의 TAFIM 개발, 그리고 스티븐 스피왝 박사(Steven H. Spewak Ph.D.)의 EAP(Enterprise Architecture Planning) 방법론이 그것이다.
스피왝 박사는, “방법론(methodology)은 일관되고 조리 있고 반복적인 방법으로 활동을 수행할 수 있는 문서화된 접근”이라고 정의하며, “일상적으로는 프로세스와 산출물을 정의한 것”이라고 설명한다.
스피왝 박사가 EAP 방법론을 제시하기 전까지는 자크만이 제시한 아키텍처 개념과 프레임워크를 어떻게 구현할 것인가에 대해서는 아무도 가르쳐주는 사람이 없었다. 방법론이 명시되지 않으면 미리 정의된 절차에 따라서 고품질의 결과를 얻는 것이 어렵다는 점에서 EAP 방법론이 정의되기 이전에는 의미 있는 EA 프로젝트가 불가능했다고 할 수 있다.
EA 용어의 변천 EA에 관심을 가지는 사람들이 느끼는 몇 가지 혼란 중 하나는 EA와 ITA의 혼동이다. 이는 EA에 대한 정의가 과거에 확정된 것이 아니라 시대에 따라 변해왔기 때문이다.
자크만이 프레임워크를 개발했을 당시에는 ISA(정보시스템 아키텍처)라는 용어가 통용됐고, 미국 국방성(DoD)이 EA를 주도하던 1990년대에는 ITA가 EA를 포함하는 개념으로 사용됐다. 2000년대 들어서는 미국 연방정부가 EA를 주도하면서 EA가 ITA를 포함하는 것으로 정의돼 현재에 이르고 있다.
우리나라에서는 정부 부처에 따라 EA와 ITA가 혼용되고 있으나 그 의미는 둘 다 미국 연방정부의 EA 정의와 유사하게 사용된다.
EA라는 용어가 여러 차례 변화를 겪었지만 이를 처음 제안한 사람은 스피왝 박사라고 알려져 있다. 그는 EA라는 용어를 제안하고 방법론을 제시해 명실상부하게 EA의 어머니 역할을 했다.
EAP의 개요 EAP는 ‘비즈니스 지원을 위한 정보의 아키텍처들을 정의하는 과정이며 이러한 아키텍처들을 구현하기 위한 계획’으로 정의된다. 이 정의에서 중요한 세 가지 키워드가 있다. ‘아키텍처들(복수형)’, ‘정의’, 그리고 ‘계획’이다.
‘아키텍처들’은 데이터 아키텍처, 애플리케이션 아키텍처, 기술 아키텍처의 3가지 아키텍처를 말한다. 여기서 아키텍처란 청사진(blueprint)이나 모델을 의미하며 비즈니스를 지원하기 위해 존재하는 것이다.
‘정의’는 EAP와 전통적 정보 계획 방법의 중요한 차이점 중 하나다. EAP는 서술하거나 설계하는 것이 아니라 정의하는 것인데, 서술은 사람마다 해석이 다를 수 있으며 설계는 정의보다 세부적인 내용을 다룬다.
‘계획’은 현재 상태뿐 아니라 앞으로의 일들을 정의하는 것이며 아키텍처의 미래(TO-BE)를 말한다고 이해할 수 있다. EAP에서는 현재(AS-IS) 아키텍처뿐 아니라 미래의 아키텍처를 수립해야 하고 이행 계획을 수립해야 한다.
EAP는 이전의 전통적인 정보 계획 방법론과 몇 가지 중요한 차이점을 보인다.
먼저 EAP는 ‘데이터 중심’의 방법론으로, 데이터를 정의한 후 애플리케이션과 인프라스트럭처를 정의하는 순서를 제시한 데 반해 전통적인 시스템 계획 방법은 ‘프로세스 중심’의 방법론이었다. 또한 전통적인 시스템 계획 방법이 ‘기술 중심’이고, ‘단기적 접근’이었다면 EAP는 ‘비즈니스 중심’이고 ‘장·단기적 접근’이다.
전통적인 시스템 계획과 비교했을 때 EAP의 장점은 다음과 같다. -데이터를 자산으로 인식하고 기술은 데이터 관리를 위해 전략적으로 사용한다. -표준 용어를 사용함으로써 의사소통의 불일치와 데이터 중복을 줄여준다. -문서화를 통해 비즈니스의 이해도를 높인다. -모델은 비즈니스뿐 아니라 비즈니스 변화도 설명한다. -의사결정 정책에 영향을 주며 근거 자료로 사용할 수 . -현재(AS-IS) 시스템과 미래(TO-BE) 시스템의 통합을 고려한다. -종합적이고 객관적이며 공평한 접근 방법을 고려한다. -장기적인 시스템 계획을 마련해 비즈니스 계획을 지원한다. -비용 효과적이고 장기간의 솔루션은 투자 가치를 고려한다. -단기간의 성취와 더불어 실행 가능한 시스템 이행 전략을 포함한다. -새로운 시스템과 소프트웨어의 이점과 영향을 평가하기 쉽다. -인수, 합병, 신제품, 비즈니스 라인 등과 같은 활발한 비즈니스 변화에 쉽게 적응할 수 있다. -관리자의 참여는 비즈니스 전망, 신용, 신뢰성을 제공하며 시스템 개발의 편견을 제거한다.
EAP 방법론
EA의 어머니 스티븐 스피왝
EAP는 자크만의 프레임워크에서 상위 2개의 뷰(행, Row)인 볼파크 뷰(Ballpark View)와 오너 뷰(Owner’s View)를 대상으로 한다. 3번째 뷰 이하는 시스템 설계 단계로 간주하며 EAP 완료 이후에 진행할 업무로 본다.
EAP 방법론은 결혼 케이크 모양인데, 계획의 시작 단계, 현황 파악, 목표 내용, 목표에 도달하는 방법의 순서로 위에서 아래로 정의돼 있다.
<그림 1>을 보면 요즘 사용하는 EA 프레임워크의 기본 모형인 비즈니스-데이터-애플리케이션-기술의 4가지 아키텍처와 그 순서가 EAP에서 유래된 것임을 알 수 있다.
여기서 3번째 계층의 DA → AA → TA가 화살표로 연결된 것에 주목하라.
프로젝트의 효율을 중요시한다면 DA, AA, TA를 3개의 팀이 동시에 작성해 프로젝트 기간을 최소화하고 싶은 유혹을 떨칠 수 없을 것이다. 그러나 동시 작업은 위에서 언급한 EAP의 장점을 심각하게 훼손하는 결과를 낳기 쉽다.
즉, 팀들 간의 용어 정의, 이해 수준, 목표 시스템에 대한 시각 차이가 존재하기 때문에 EAP의 일치성, 통합성을 훼손할 수 있다. 더군다나 AA와 TA는 데이터에 대한 의존도가 있기 때문에 DA가 완성되기 전에는 완전한 AA와 TA를 작성할 수 없다. 따라서 3가지 아키텍처는 차례대로 작성돼야만 하며 화살표는 이것을 강조하는 것이다.
최근에 국내에서 수행되는 EA 프로젝트들도 이러한 오류를 범하는 사례가 적지 않은 것 같다. 그러나 EA는 ‘지역 최적화(Local Optimization)’가 아니라 ‘전역 최적화(Global Optimization)’를 추구한다. 따라서 EAP 수행 과정에서도 ‘효율(Efficiency)’보다는 ‘효과(Effectiveness)’를 중시해야 한다.
<그림 1> EAP 방법론 모델 EAP 프로세스 (1) 계획 수립 수많은 EAP 프로젝트들이 실패로 끝나는 이유는 비합리적인 목표, 잘못된 접근 방법 선택, 경험이 없는 참여자 등이다. 계획 수립은 이러한 위험을 제거하고 성공 가능성을 높이려는 것이다. 계획 수립 단계에서의 활동은 다음과 같다.
-EAP의 범위와 목표 결정 -조직의 변화 준비 평가 -비전 수립 -방법론 적용 -컴퓨터 자원 준비 -팀 구성 -EAP 작업 계획 준비 -경영층의 지지 획득
(2) 예비 비즈니스 모델 EAP에서는 비즈니스 모델링을 두 단계로 구분한다. 예비 비즈니스 모델링은 비즈니스의 기능을 정의하고 각 기능의 간단한 설명을 제공하며 각 비즈니스 기능을 구성하는 조직 단위를 밝히는 것이다. 이 활동은 전체 비즈니스 모델링 노력의 25∼30% 정도를 차지한다.
예비 비즈니스 모델 단계의 활동은 다음과 같다.
-조직 구조에 대한 문서화 -비즈니스 기능의 식별과 정의 -예비 비즈니스 모델의 배포
(3) 전사 조사 전사 조사(Enterprise Survey)는 예비 비즈니스 모델을 기반으로 전사의 상세 업무 정보를 주로 인터뷰를 통해 수집한다. 이 과정에서는 업무를 수행하는 데 필요한 정보, 업무의 수행 시기, 업무의 수행 장소나 부서, 업무 수행의 빈도, 업무 개선 가능성 등을 주로 파악한다.
전사 조사 단계의 활동은 다음과 같다.
-인터뷰 스케줄 작성 -인터뷰 준비 -인터뷰 실시 -데이터를소프트웨어에 입력 -완성된 비즈니스 모델의 배포
(4) 현재 시스템과 기술 아키텍처 현재 기업 내에서 사용하고 있은 모든 시스템과 기술 플랫폼을 정의하고 문서화하는 단계다. 이 단계의 가장 중요한 산출물은 정보자원목록(IRC : Information Resource Catalogue)이다.
이 단계의 활동은 다음과 같다.
-범위, 목표, IRC 작업 계획 작성 -데이터 수집 준비 -데이터 수집 -데이터 입력 -IRC를 검증하고 초안을 작성 -구성도 그리기 -IRC 배포 -IRC를 관리하고 유지
(5) 데이터 아키텍처 데이터 아키텍처는 비즈니스 모델에서 정의된 비즈니스 기능들을 지원하는 데이터를 식별하고 정의한다. 이 단계의 활동은 다음과 같다.
-후보 데이터 실체를 나열 -실체, 속성, 관계를 정의 -실체와 비즈니스 기능을 연결 -데이터 아키텍처 배포
(6) 애플리케이션 아키텍처 애플리케이션 아키텍처의 목적은 데이터를 관리하는 데 필요한 주요 애플리케이션 서비스를 정의하고 조직의 사업 기능을 지원하는 데 있다. 이것은 상세 기능이나 요구사항 수준이 아니며 비즈니스에서 필요로 하는 데이터의 가공을 위해 무엇을 할 것인가를 상위 수준에서 정의한다.
이 단계의 활동은 다음과 같다.
-후보 애플리케이션 나열 -애플리케이션 정의 -애플리케이션과 비즈니스 기능 연결 -현재 애플리케이션에 미치는 영향 분석 -애플리케이션 아키텍처 배포
(7) 기술 아키텍처 기술 아키텍처는 데이터와 이를 처리하는 애플리케이션의 환경을 정의하는 것이다. 개념적 모델 수준으로 정의하는 것이며 플랫폼을 설계하지는 않는다. 이 단계의 활동은 다음과 같다.
-기술 플랫폼과 원칙 식별 -플랫폼과 분산 데이터, 분산 애플리케이션 정의 -플랫폼과 애플리케이션, 비즈니스 기능 연결 -이행 결정 수립 -기술 아키텍처 배포
(8) 구현 계획 구현은 EAP의 실행 계획에 해당하는 부분이다. 비즈니스 모델, IRC, 3개의 아키텍처를 이용해 미래 구현 계획을 작성한다. 이 단계의 활동은 다음과 같다.
-애플리케이션의 순서 결정 -필요한 노력과 자원 평가 및 일정 수립 -계획의 비용과 이익 평가 -성공 요소 결정과 권고 사항 작성
(9) 계획의 종결 EAP의 모든 작업을 마무리하는 단계다. 이 단계의 활동은 다음과 같다.
-최종 보고서 준비 -경영진에게 최종 발표
(10) 구현으로 전환
EAP 작업을 마치고 계획 중에 작성한 구현 계획을 실행해 미래를 구현하는 단계다. 이 단계는 몇 달에서 몇 년까지 걸릴 수 있으며 비즈니스 지원을 위한 정보시스템의 장기적인 개선 활동으로 이해할 수 있다.
<그림 2> EAP 단계별 프로세스 EAP의 영향 EAP는 1992년 스피왝 박사가 DHL 시스템의 수석 아키텍트로 있던 시절에 제시한 방법론이다. 이후 미국 정부가 EA를 적극 채택하면서 스피왝 박사가 참여한 미 연방정부 EA팀은 EAP를 기반으로 ‘연방정부 EA의 실용적 지침(A Practical Guide to the Federal Enterprise Architecture)’이라는 방법론을 개발했고 이를 통해 미국 정부의 EA 노력이 확대됐다.
자크만이 EA 프레임워크를 최초로 제시했고 아직까지 표준 프레임워크로 인정받고 있지만 실제 프로젝트에서는 자크만의 프레임워크를 거의 사용하지 않는다. 우리가 쉽게 볼 수 있는 프레임워크는 BA, DA, AA, TA의 네 가지 아키텍처로 이루어진 것이며 스피왝 박사의 방법론에 영향을 받았다.
또한 현재 대부분의 기업에서 사용하는 EA 방법론은 큰 틀에서 EAP와 닮았기 때문에 EAP를 이해한다면 최근에 사용되는 방법론의 80%는 이해할 수 있다.
EA의 대가였던 스피왝 박사는 2004년 53세의 일기로 생을 마감했다. 그와 함께 일했던 사람들은 “미국 정부에서 EA를 하는 사람 치고 스피왝 박사를 모르는 사람은 한 명도 없다”는 말로 그의 업적을 기리고 있다.
Comments