EA, 우리 조직에 필요한가?
요사이 IT 분야의 키워드는 경영이나 비즈니스와 밀접한 경향을 보이고 있다. BPO, BI, BPM, BRE 등이 그러한 예이며 EA(Enterprise Architecture)는 IT에서 발원한 용어 중 가장 비즈니스 진영에 가까운 용어 가운데 하나다.

최근 주요 컨설팅 및 솔루션 회사들의 발표를 보면 기업의 가장 중요한 화두는 '신속함(Agility)'과 '경비 절감(Cost Reduction)'으로 요약된다. 기업은 '신속함'에 의해 가치를 창출하고 '경비 절감'에 의해 위험 요소를 제어할 수 있다.

'신속함'은 고객이 원하는 정도 혹은 그 이상의 수준을 요구하는데, 요즘의 고객은 거의 광속(light-speed)으로 취향이 바뀌고 있다. '경비 절감'은 'Made in China'로 대표되는 생산비 절감을 비롯해 ITO(IT Outsourcing)/BPO(Business Process Outsourcing) 등 비핵심 분야 아웃소싱에 의한 운영비 절감으로 이해할 수 있다.

EA는 바로 신속함과 경비 절감이라는 두 가지 화두를 동시에 해결하고자 하는 시도다.

여러 가지 EA 정의가 있지만, EA가 우리 조직에 필요한가 아닌가 하는 판단에는 아주 단순한 기준을 적용해볼 수 있다. 즉 '비즈니스의 핵심 성공 요인(CSF : Critical Success Factor)에 IT가 포함되는가?'이다.

요즘에는 상식적으로 IT가 기업의 필수 요소라고 생각하지만, 경우에 따라서는 다소 불합리한 IT 지원에도 비즈니스가 별 영향을 받지 않는 기업도 있을 것이다. 이러한 조직은 EA가 필요하지 않거나 당장 도입할 필요는 없다고 판단할 수 있다.

엔터프라이즈 아키텍처가 필요한 시대
경제와 사회가 발전하면서 비즈니스도 복잡하고 다양한 형태로 발전했다. 이에 따라 비즈니스를 지원하는 정보시스템의 기능과 구조도 점점 복잡해졌다. 이러한 변화는 산업화 이후 점증돼 온 것으로 21세기에 갑자기 나타난 문제가 결코 아니다.

1980년경 비즈니스에서 컴퓨터의 활용이 증가하고 다양한 응용 시스템이 한 대의 메인프레임에서 가동되자 응용 시스템 사이의 논리적 연관성이 중요해지고 우선 순위 설정에 의한 컴퓨팅 자원 배분이 중요해졌다. 이에 ISP(Information Strategy Planning : 정보 전략 계획)가 태동했다.

이 시기에는 메인프레임을 한 대만 가동하는 것이 일반적이었기 때문에 인프라스트럭처나 기술 아키텍처에 대한 고려가 필요치 않았다.

1990년대에 유닉스 기반의 개방형 시스템이 기업 전산실에서 사용되면서 애플리케이션과 인프라스트럭처 사이의 관계가 중요해졌다. 또한 여러 대의 유닉스 서버 간의 네트워크에 대한 표준이 발달했다.

응용 아키텍처뿐 아니라 기술 아키텍처도 필요하게 된 시기가 이 때다. 하지만 비즈니스의 변화는 여전히 느렸으며 정보시스템 아키텍처에서 비즈니스는 그리 중요한 사항이 아니었다. 따라서 이 때 정립된 ITA(IT 아키텍처)는 데이터 아키텍처(DA), 애플리케이션 아키텍처(AA), 인프라스트럭처 아키텍처(TA)로 구성된다.

2000년대 이후 세계화의 급진전에 따라 기업의 경영 환경이 복잡해지면서 가상 기업의 형태가 등장했다. 더는 기업의 비즈니스 모델이 안전하지 않으며, 1년 이상 유지하기도 어렵다는 인식이 팽배해졌다.

비즈니스 모델을 지원하는 정보시스템 또한 전 세계에 걸쳐 분산되면서 가상화되고 있다. 이제 기업은 IT 아키텍처로 충분하지 않다. 비즈니스 아키텍처를 중심으로 IT 아키텍처를 결합한 엔터프라이즈 아키텍처가 필요해진 것이다.

자크만이 제시한 '프레임워크'
이미 1987년 IBM 시스템 저널에는 <정보시스템 아키텍처 프레임워크(A framework for information systems architecture)>라는 논문이 실려 이 같은 변화를 예고했다. 이 논문은 EA를 개척한 첫 논문으로 인정받고 있으며, 저자인 존 자크만(John Zachman)은 'EA의 아버지'라고 일컬어진다.

EA의 아버지 존 자크만

자크만이 EA의 아버지라면, 듀이 워커(Dewey Walker)는 자크만이 'EA(ITA)의 할아버지'라고 부르는 사람이다.

1960년대 후반에 자크만과 함께 IBM에서 일했다. 당시는 메인프레임이 곧 컴퓨터를 의미하는 시절이었는데, 워커는 IBM의 정보시스템 제어와 계획 책임자로 일하면서 '업무 시스템 계획(Business Systems Planning)' 방법론을 개발했다.

1965년에 IBM에 입사한 자크만은 정보시스템 계획 업무를 담당했다. 워커와 함께 개발한 '업무 시스템 계획' 기법은 1970년대에 IBM이 정보 계획 방법론으로 광범위하게 활용하기도 했다. 또 다른 기법인 '집중 계획(Intensive Planning)'은 IBM의 중역팀 계획 방법의 기반이 됐다.

이러한 과정을 거쳐 자크만은 1987년에 <정보시스템 아키텍처 프레임워크>라는 논문을 발표할 수 있었던 것이다.

자크만은 서문에서 '정보시스템의 점증하는 규모와 복잡도를 다루기 위해서는 시스템의 모든 구성 요소 사이의 인터페이스와 통합을 정의하고 제어하기 위한 논리적 구조(내지는 아키텍처)가 필요하다'고 지적했다. 30년 전에 제기된 아키텍처의 필요성은 현재까지도 여전히 유효하다.

이 논문은 또 '비즈니스 변화의 관리, 비즈니스 자원과 자원 일치성 관리에 유연성을 제공한다'고 언급해 비즈니스에서 정보시스템의 역할을 명확히 정의하고 있다.

자크만의 논문 이전에도 정보시스템 아키텍처에 대해 다양한 시도가 없었던 것은 아니다. 하지만 자크만이 EA의 아버지라고 불리게 된 것은 이러한 시도를 구조화한 프레임워크를 도입했기 때문이다. 이 프레임워크는 정보시스템 아키텍처에 새로운 패러다임을 제시했다.

자크만이 프레임워크에서 제시한 것은 하나의 시스템에 대해 세 가지 종류의 정보를 제공하는 것과 각 정보를 다섯 가지 구체화 수준으로 구분하는 것이다. 이 과정에서 사용한 집짓기의 비유는 아직까지도 EA의 개념을 설명하는 데 적절히 인용되고 있다.

1992년부터 현재까지 사용하고 있는 프레임워크는 1987년에 자크만이 제시한 'What(Data), How(Process), Where(Network)'의 정보에 'Who(People), When(Time), Why(Purpose)'의 정보를 추가한 것이다.

자크만이 제안한 ISA(정보시스템 아키텍처) 개념과 이를 표현하기 위한 프레임워크는 이후 미국 정부에서 받아들여 정보 자산 관리의 표준이 됐다. 그가 제안한 개념들은 미국 연방정부 CIO 위원회에 의해 1999년 제정된 미국 연방정부 아키텍처 계획 가이드라인에 반영됐으며, 프레임워크는 미국 연방정부 EA 프레임워크인 FEAF의 기반이 됐다.

<그림> 초기와 현재의 자크만 프레임워크

EA를 구체화해줄 방법론 'EAP'
26년간의 IBM 생활을 정리한 자크만은 자크만 인터내셔널(Zachman International)을 설립해 교육과 컨설팅을 수행하고 있다.

또 ZIFA(Zachman Institute for Framework Advancement)의 회장으로서 EA 전문가들의 네트워크를 구성해 ZEAF(Zachman EA Framework)을 이용한 EA 구현과 사용 지식을 교류하는 데 앞장서고 있다.

2003년에는 ZEAF에 대한 상세한 해설과 자신의 논문 21편을 모아 'The Zachman Framework: A Primer for Enterprise Engineering and Manufacturing'이라는 책을 발간했다.

자크만은 ISP 경험을 살려 정보시스템 자산을 체계적으로 분류할 수 있는 프레임워크를 개발하고 IT 아키텍처 개념을 정립하기는 했지만, 프레임워크를 이용하는 EA 구축 방법론을 제시하지는 못했다. 또 1987년의 패러다임 전환 이후 EA에 대한 뚜렷한 발전 방향을 제시하거나 이 분야에 대한 지식을 정리한 교과서를 출판하지 못했다(2003년의 책은 자신의 논문을 정리한 것이다).

자크만이 뿌린 EA의 사상이 실체화되고 발전한 것은 다음 회에서 언급할 스티븐 스피왝(Steven Spewak)이 EAP(Enterprise Architecture Planning) 방법론을 제시함으로써 가능해졌다. @