[지디넷코리아]엔터프라이즈 아키텍처(EA) 평가를 시행하는 목적은 기업의 현 아키텍처가 조직의 필요와 목적에 얼마나 잘 부합하고 있는지 이해하기 위한 것이다. 이 글에서는 EA 평가의 가치에 대해 논의하고 어떤 단계를 거쳐야 할지 살펴보도록 하자.

EA 평가를 가치있게 만드는 것은 무엇일까? 우리 관점에서 보면 EA의 목적은 조직의 목표를 최고로 증진시키기 위해 IT 인프라스트럭처와 조직간의 조화를 꾀하고 IT 부문에 대한 투자 이득을 극대화시키는 것이다. 결국 현재 목표를 이루기 위해 뭘 어떻게 하고 있는지 명확히 이해할 수 있게 된다.

사실 우리는 종종 EA 평가를 수행함으로써 전체 EA에 대해 “대대적인 모험”을 감행하도록 조언하기도 한다. 어찌됐든 EA 평가를 시행하는 목적은 현 아키텍처가 조직의 필요와 목적에 얼마나 잘 부합하고 있는지 이해하기 위한 것이다.

EA는 무엇인가?
우리가 말하는 EA란 기업의 요구와 목표에 부합하기 위해 전 분야의 IT 인프라스트럭처가 어떻게 움직여야 하는지, 또는 현재 어떻게 움직이고 있는지 기술한 것을 말한다. 여기에는 인프라스트럭처를 구성하는 모든 데이터와 각자 정해진 역할, 기술, 인력 등이 포함된다.

그렇다면 아키텍처 평가는 어떻게 이뤄질까? 그 과정은 다음과 같다.

• EA의 현재 상황에 관한 데이터 수집·분석
  
  
• 아키텍처가 기업을 제대로 지원하고 있는지 결론을 도출
  
  
• 결과 보고

어떤 가치가 있는가?
아키텍처 평가는 다른 방법들보다도 가치있는 것으로 입증된 바 있으며 조직의 현 IT 인프라스트럭처에 드는 비용과 얻는 이득을 사실에 기반을 둬 이해할 수 있도록 한다. 설사 아키텍처를 바꿀 이유가 없다고 할지다로 아키텍처 평가는 의사 결정을 뒷받침할 사실을 얻게 되는 것으로 가치가 있다.

아키텍처 평가는 현 아키텍처가 비즈니스상의 문제에 어떤 영향을 끼치고 있는지, 혹은 목표를 어떻게 뒷받침해주고 있는지 명확히 드러내준다.

평가는 시행중인 아키텍처와 그렇지 않은 아키텍처 양쪽 모두에서 이뤄질 수 있다. 현 인프라스트럭처의 문제점을 끄집어내기 때문에 EA 평가 작업을 수행할 경우 아키텍처를 재설계할 때 비즈니스상의 비용을 줄일 수 있는 부분이 어딘지, 또한 비즈니스 기능이나 과정은 어디서 개선할 수 있는지, 그리고 IT 비용 절감, 중복 방지 등 IT 효율성을 어떻게 개선할 수 있는지 파악할 수 있다.

평가에서는 무엇을 유지해야 하고 바꿀 것은 무엇이며 왜 그래야 하는지 비교적 객관적인 시각에 따라 평가를 제공하기 때문에 그 내용들을 비즈니스 케이스 데이터로도 활용할 수 있다. 또한 아키텍처를 채설계할 때 투입돼야 할 자금을 청구할 근거로 활용할 수도 있다.

동기 부여는 필수
평가 수행을 해달라는 요청을 받게 되면 우리는 기본적으로 “경찰 수사 방식”에 따라 동기, 기회, 방법, 그리고 “증거”를 알아내려 한다. 우선 우리는 동기가 무엇인지 알아본다. 즉 조직에서 아키텍처 평가를 원하는 이유가 무엇인지, 평가를 하게 된 계기는 무엇이고 지금은 이유가 무엇인지를 알아본다는 말이다. 우리가 지금껏 보아온 바에 따르면 가장 보편적인 “좋은” 동기는 이런 것들이다.

• 특정 비즈니스 프로세스를 개선하거나 주요 비즈니스 기회, 예를 들어 신규 시장이나 서비스를 뒷받침하고자 하는 바램.
  
  
• 조직의 변화, 예를 들어 일자리를 없애거나 합치는 것이나 관리 구조 재편 등을 말한다.
  
  
• 어떤 주요 프로젝트를 수행하기 위해 현 아키텍처의 일부를 변경, 위임하려 결정.

마지막에 든 동기의 경우 예전에 한 기업 고객이 자사 빌링 시스템을 대규모로 재구축하기 위해 예산을 배정해놓고 의사결정에 도움을 받기 위해 자신들의 계획을 검토해달라고 요청한 적이 있었다. 우리는 우선 현 빌링 시스템의 상태가 어떤지 살펴보는 것으로 평가에 착수했다.

분명 목표로 하는 아키텍처를 만드는 데 바로 뛰어들고 싶을 것이다. 그러나 EA에 대해 진지하게 생각하고 있다면 우선은 평가부터 하는 것이 맞다. 그리고 나서 아키텍처를 재설계하기로 결정하는 것이 “예술적”이 아니라 훨씬 더 “과학적”인 노력을 하는 셈이 될 것이다.

2. EA 평가, 기회가 필요하다
조직의 아키텍처 재설계를 맡게 됐다면 아마도 EA 평가에 대해 조직 구성원의 동의를 얻어야 좀더 수월하게 진행할 수 있을 것이다. 확신이 서지 않는다면 조직 구성원이 지원해야만 하는 일을 먼저 추진하라. 왜냐하면 평가의 목적은 바로 문제를 찾는 것이기 때문이다.

평가에서 좋지 않은 결과가 나와도 문제없도록 경영진의 지지가 필요할 수도 있다. 조직이 아키텍처 개발에 착수하지 않기로 결정한다 하더라도 EA 평가는 상당한 이득을 제공한다. 평가를 통해 얻은 내용 중 전면에 내세울 수 있는 것들은 다음과 같다.

• 평가 결과는 IT 시스템의 변경을 제안할 때 적용될 수 있는 명확한 기준을 제공한다. 예를 들어 CRM, 신규 데이터베이스, 또는 신규 플랫폼 컴포넌트를 고려하고 있다면 변경 제안이 기존 인프라에 얼마나 적합할지 파악하는 데 평가가 도움을 준다.
  
  
• 평가를 통해 주요 프로젝트의 “수정”과 그에 미치는 영향을 강조하거나 파악할 수도 있다. 조직이 아키텍처를 대대적으로 재설계하길 원하지 않아도 데이터베이스 몇 개를 통합하는 등 인프라스트럭처의 “일부”를 수정할 수 있기 때문이다.
  
  
• 평가를 수행한 팀은 IT 솔루션 제안서에서 발생할 수 있는 위험, 그리고 도입 결과를 관리하기 위해 정보에 근거한 결정이나 추천을 수행할 역량을 지닌, 고도로 훈련된 인적 자원으로 성장하게 된다. 완전한 IT 아키텍처 개발 계획의 가부를 결정하려 하든지 CRM/EAI/ERP/포털/웹서비스가 어디에 적절한지 찾고 있든지 상관없이 이런 역량을 보유한 팀은 상당한 가치가 있다. 인프라스트럭처가 비즈니스 목적에 부합하는지, IT 예산이 적재적소에 쓰이고 있는지 확인해줄 수 있기 때문이다.

EA 평가 수행 방법
우리는 엔터프라이즈 아키텍처에서 “대대적인 모험”을 감행해왔고 그 결과 여러 아키텍처에서 얻은 “교훈”을 토대로 “전사적 정보 아키텍처(EIA)용 툴킷”(이후 툴킷)을 개발했다. 이 툴킷은 그림 A에 있는 세 가지 엔터프라이즈 아키텍처 프레임워크 각각에 대해 산출물을 만들어내는 방법론을 모아놓은 것이다.

우리는 고객들에게 아키텍처에 대해 교육하고, 엔터프라이즈 아키텍처를 개발하며, 아키텍처 평가를 수행하는 데에 툴킷 방법론을 적용하고 있다.

그림 A. 툴킷 프레임워크

우리는 아키텍처 평가에 다음과 같은 이유로 툴킷을 사용하고 있다.

• 툴킷은 예를 들어 기술적인 아키텍처 평가에만 국한되지 않고 엔터프라이즈 아키텍처 평가 전체를 지원한다.
  
  
• 툴킷은 아키텍처를 결정하는 일차적 요인을 비즈니스상의 요구로 본다.
  
  
• 툴킷은 목표 아키텍처 개발을 수월하게 진행할 수 있도록 해준다.

우리는 아키텍처 개발이 아닌 평가에도 이 툴킷을 사용하고 있다. 그림 A에서 옅은 파란색으로 셀이 EA 평가에서 중점적으로 사용되는 부분이다.

바꾸고 싶은가? 증거를 확보하라
상위 수준에서는 다음과 같은 단계를 거친다. 이 과정을 통해 “증거”를 수집하고 엔터프라이즈 아키텍처 평가에 사용할 툴킷이 무엇인지 파악한다.

1 단계 : 비즈니스 프레임워크
이 단계에서는 회사가 염두로 두고 있는 것 중 쓸모 있는 것을 발전시키기 위해 회사의 재 상태와 목표 상태를 명확히 기술한다. 일반적으로 데이터 수집은 다음과 같은 순서로 진행된다.

• 문서 수집과 분석 : 공식적이고, 널리 알려졌으며, 쉽게 구할 수 있고, 보편적인 공감대가 형성돼 있는, 조직에 대한 경영진의 견해를 수집. 조직의 임무/목적에 대해 기술한 내용, 조직의 핵심 목표 등을 예로 들 수 있다.
  
  
• 인터뷰 : 현 비즈니스 프로세스의 문제를 파악하고 비즈니스 계획과 방향을 기술하며, 현 IT 인프라스트럭처가 비즈니스 문제에 어떤 영향을 미치는 것으로 인식되는지 명확히 하기 위해 조직 내 경영진과 핵심 임직원의 견해를 비교적 덜 공식적인 형태로 수집한다.
  
  
• 현 상태와 희망 상태를 나열하고 프로세스 흐름을 산출물에 정리한다

2 단계 : 아키텍처 프레임워크
이 단계의 목표는 데이터, 기능, 플랫폼 컴포넌트 사이의 기존 관계를 보여주는 아키텍처 모델을 종합 판단하는 것이다. 또한 기존 데이터, 기능/적용, 그리고 플랫폼 컴포넌트에 대한 내용을 수집하고 만들어놓는 단계다.

특히 내용과 연계된 비용 데이터를 저장해 놓을 것을 강력하게 추천한다. 이에 대한 문서가 없거나 오래된 것이라면 아키텍처 인터뷰를 수행하고 기존 문서들을 재검토하며, 재검토와 갱신을 위해 초안을 준비함으로써 만들어놓아야 한다.

3 단계: 분석
이 단계에서는 비즈니스상의 문제와 견해차, 기회를 파악하기 위해 현 상태와 지향점을 적는 데 분석 테크닉을 적용한다. 또한 현 상태의 아키텍처 어디에서 비즈니스상의 문제와 견해차가 유발되는지 살펴보기 위해 현 아키텍처에 똑같이 분석 테크닉을 적용한다.

4단계 : 실제 구현용 프레임워크 상담
이 단계에서는 수집한 내용과 분석을 통해 절대 간과할 수 없는 “정치적인” 고려에 사용될 산출물을 시험한다. 즉 현재 프로세스, 측정 내용, 그리고 조직의 “적응력”을 놓고 시험하는 것으로 조직이 극도로 변화를 거부하지는 않는지 살펴보는 것이다.

또한 이 단계에서는 “정상성 검사”도 제공한다. 예를 들어 평가한 내용에 따라 조직을 완전히 재구성해야 하거나 비즈니스 프로세스를 완전히 갈아엎어야 할 필요가 있다면, 평가 내용을 잘게 쪼개놓고 보는 게 나을 수도 있다.

현실적인 문제와 함께 많은 사안에 대해 견해차가 발생하면 데이터를 정리해보라. 우선 “판독” 프리젠테이션을 내놓고, 이걸 보면서 토론을 유도한다. “여기 나열한 게 과연 ‘올바른’ 문제들인가?”라는 식으로 말이다.

그리고 종국에는 아키텍처 상태에 대한 보고서를 좀더 꼼꼼히 보강해 내놓는다. 장점이 연이어 거론되면 그 내용 또한 포함시킨다. 이제 아키텍처 재구축 프로젝트를 제안할 기회가 생기는 것이다.

여기 기술한 내용은 상당한 지식과 작업, 그리고 끈기를 요한다. 그러나 이를 통해 얻는 결과는 노력을 들인 만큼 훌륭하다. 나는 IT가 회사를 어떻게 지원하는지, 그리고 변화를 따르면 어디에 가치가 있고 비용 효율적인지 명확히 이해하는 데 있어 이보다 더 효과적이고 확실한 접근 방법은 없다고 본다. @

필자 소개
해리스 컨 엔터프라이즈 컴퓨팅 인스티튜트(www.harriskern.com)는 앞서가는 업계 전문가들이 모여 설립한 서적, 참고 안내서, 도구, 기사 등 출판물 관련 컨소시엄이다. 이 기관에서는 프렌티스 홀/PTR과 공동으로 IT 서비스, IT 조직, IT 시스템 관리, IT 생산 서비스, 고가용성, 투자 대상으로서의 IT 관리, CEO의 지혜에 관한 ‘하우투’ 시리즈를 출간하고 있다.