관련 통계자료 다운로드 주요 3개국의 EA비교 도시정비가 잘 된 곳은 쾌적한 생활을 누릴 수 있게 해준다. 미래의 인구 증가와 환경 변화를 고려해서 설계한 도로, 상하수도, 주택보급, 교통시설, 교육, 문화 및 각종 편의시설들이 잘 정비돼 있기 때문이다. 잘 정비된 도시가 CIO에게 시사하는 바는 바로 ‘미래의 변화를 예측하고 이를 수용해서 설계한 도시계획’이 선행됐다는 점이다.
지난 몇 년간 기업의 IT 발달은 과거 10년보다 빠르게 진행됐다. 기업은 증가하는 데이터 트랜잭션의 부하를 감당하기 어려워 필요할 때마다 시스템을 증설하는 처방법을 사용해 왔다. 그 결과가 현재 IT 난개발로 이어졌다. 마치 미래지향적인 계획 없이 필요할 때마다 도로를 확장하고 주택을 보급해 난개발이 불가피했던 도시처럼 돼버린 것이다.
난개발은 도시를 폐허로 만들 수 있다. IT 난개발 역시 기업의 시스템을 ‘쓰레기’로 전락시키게 될 것이다. 엔터프라이즈 아키텍처(EA)는 IT 난개발을 멈추고 체계적인 관리와 효율을 증진시키기 위한 수단으로 떠오르기 시작했다.
#나무보다는 숲을 보는 IT
업무 및 정보시스템의 복잡성은 업무와 정보기술의 통합성 미흡, 중복투자, 환경변화에 대한 IT의 대응 어려움, 전체가 아닌 단위시스템의 최적화를 가져왔다. 많은 기업들이 비즈니스 전략을 보다 원활하게 지원하기 위한 IT 청사진(Blueprint)의 수립과 복잡도가 지속적으로 증가하는 IT 기술 자원에 대한 관리를 목적으로 EA를 도입하고 있다.
EA는 업무요구사항을 충족시키고, IT 자원 간 상호 운영성 및 통합성 보장을 위하여 요구되는 업무 및 정보기술의 구성요소를 분석하고 이들간의 관계를 구조적으로 정리한 체계다. EA라는 업무 및 정보기술의 표준체계는 궁극적으로 시장의 변화에 대응하고 수익창출을 위한 기업의 비즈니스 수행을 위해 IT를 도입하고 활용하는데 근간이 되는 표준(Standard)으로써 활용된다. 또한 비즈니스 목표와 이에 적합한 전사적 아키텍처의 논리적인 구조를 구성해 정보기술의 상호 연계성을 극대화하고 체계적인 정보기술 기반 구축을 용이하게 이해할 수 있는 ‘커뮤니케이션 툴(Communication tool)’ 역할을 제공한다.
EA는 다수의 전문가에 의하여 다양한 형태로 정의돼 왔다. 조직의 비전을 달성하기 위해 필요한 현재와 미래의 비즈니스, 데이터, 애플리케이션, 기술 IT 환경에 대한 구성요소를 분석하고 이들간의 관계를 구조적으로 정리한 체계와, 이러한 체계에 근거해서 원칙 및 표준에 따라 IT 자원을 체계적이고 효율적으로 관리, 활용하기 위한 프로세스로 알려져 왔다.
EA를 수립한다는 것은 기술의 선정, 적용, 운영, 보호 및 지속적인 개선을 위하여 필요한 조직의 비전, 원칙, 표준, 로드맵을 수립한다는 것을 의미한다. EA를 잘 정의함으로써 IT 와 비즈니스 역량을 조화롭게 통합할 수 있으며 보다 수준 높은 운영 환경의 제공이 가능하게 된다.
EA의 중요성은 다음과 같다. △EA는 비즈니스와 IT 전략 간의 연결고리 역할을 담당한다 △EA는 보다 전략적인 IT 투자를 가능하게 한다 △EA는 IT 투자 프로세스 및 운영 점검을 보다 용이하게 한다 △EA는 비즈니스 전략 수행의 결과를 보다 정략적으로 측정할 수 있게 한다 △EA는 신규 프로세스의 적용이나 내외부 환경 요인에 대한 다 유연한 대처가 가능하도록 한다.
#IT고정비용을 낮춰라
미국발 금융위기가 전세계로 확산되며 내년의 투자 예산을 전반적으로 줄이려는 움직임이 일고 있다. 어려운 시기에 허리띠를 졸라매는 것은 지극히 당연한 현상이나 기업들은 증가하는 IT고정비용을 어떻게 줄일 것이냐를 두고 고민하고 있다. 이미 IT예산 중 상당부분이 인프라, 운영, 정보시스템 유지보수를 위한 비용이 전체 정보화 투자의 가장 큰 부분을 차지할 것이다.
EA는 IT고정비용을 줄여 예산 절감에 기여하고 IT예산 중 줄어든 고정 비용 중 일부를 신규 IT프로젝트에 투자하는 선순환 구조가 가능해진다. EA를 구축함으로써 기업은 업무에 대한 IT의 대응력이 높아지고, IT관리 향상과 IT투자비용의 효율화를 이룰 수 있게 된다. EA는 정보화의 기획에서 실행까지 전분야의 혁신도구로 활용할 수 있게 한다. EA의 정량적 활용을 통하여 IT투자 의사결정 과정에 대한 투명화, 객관화, 상향 평준화를 실현할 수 있다.
EA 추진을 통해 정보화 투자 포트폴리오 조정과, 전략적 가치창출 기회를 확대한다. 정보화 투자 예산의 규모는 향후 몇 년간 동년과 같은 수준으로 머물 것으로 예상된다. 정보화는 비즈니스 전략적 추진 목표에 대한 기여를 반드시 입증해야 하며 EA 과제는 비즈니스가 우선시하는 전략적 분야에 우선 집중 할 것이다. EA가 기여하는 가치의 측정은 EA 추진의 모멘텀을 유지하는데 매우 중요한 요소다.
#1990년대 미국·일본 정부 도입
EA의 역사는 1989년 IBM의 자크만 프레임워크(Zachman Framework)를 발표한 것에서 출발한다. 미국은 1993년 사실표준화기구인 The Open Group TOGAF를 개발하기 시작했다. 1996년 미국의 모든 공공기관에 의무 도입하는 법(ITMRA)이 제정됐으며 사실상 미국 정부의 EA 도입이 본격화됐다. 같은 해 영국의 국방부도 아키텍처 도입했다.
1997년 미국 예산관리국(OMB:Office of Management budget)이 ITA를 도입했고, 1998년에는 노르웨이가 공공서비스 분야에 아키텍처를 도입했다. 1999년 미국 연방정부의 아키텍처 정보화(FEA:Federal Enterprise Architecture) 프레임워크 버전1.1이 발표됐으며 이 해에 호주 주정부도 아키텍처를 도입했다. 2000년 들어서는 미국이 아키텍처 정렬 및 평가 지침을 발표해 EA를 좀더 강화했고 이 때 캐나다 재무부도 아키텍처를 수립했다. 2002년 미국은 전자정부법(e-GOV. Act)을 발표했으며 싱가폴은 정부 아키텍처 컨설팅을 받았다.
미국의 경우 1996년 정보기술관리혁신법(클린거-코헨법(Clinger-Cohen Act)) 제정으로 IT투자효율 관리 등에 EA를 의무화했다. 이후 FEAF 운용을 강화하기 위해 체제를 정비했으며 2002년 FEAF를 책정, 관리 기관으로 OMB에 FEAPMO를 발족시켰다. 또한 2003년에는 EA참조모델을 발표하기도 했다.
일본은 경제산업성 IT 어소시에이트 협의회에서 일본 정부 EA 도입을 착수했으며 경제산업성을 대상으로 한 EA시범사업을 2002년 11월부터 2003년 3월까지 진행했다. 이후 CIO연락회의를 통해 정부 EA 도입이 본격화됐다. 2003년 3월 CIO연락회의는 2004년부터 각 부처에 EA를 도입할 것과 이를 담당할 CIO보좌관을 설치할 것을 결정했다. 같은 해 12월 정부 전체적으로 부처간 담당 조정, 각 부처의 CIO보좌관 후보자 연수, EA도입을 위한 표준모델 및 지침 개발 등을 통해 범정부적 EA도입 추진을 완료했다. 경제산업성에서 EA책정 가이드라인 개발-전체 최적의 관점에서 업무 및 시스템을 개선하기 위한 구조로서, 조직 전체의 업무 프로세스 및 정부시스템의 구조, 이용기술 등을 정리하고 체계화했다. 2004년 1월부터 전 정부부처에 EA개발을 추진했다. 2005년까지 일본 정부에 EA도입 완료를 목표로 했다.
한국도 2006년 ITA법을 제정해 공공기관의 EA도입을 의무화했다.
#EA, 일회성 프로젝트로 접근하면 실패
EA 도입을 기업이 일회성 프로젝트로 보고 접근하면 성공확률은 0%다. EA는 기업의 IT청사진이다. 청사진이란 건물을 짓는 과정에서 수정될 수는 있어도 그 건물의 수명이 다 돼서 허물기 전까지 필요한 것이다. 만약 EA 도입을 위한 컨설팅을 받은 것만으로 할 일을 다 한 것처럼 생각한다면, 큰 착각이다. 방향만 세워놓고, 그 다음 행동이 뒤따르지 않으면 당초 기대했던 효과는 전혀 얻을 수 없기 때문이다.
EA와 SOA(Service Oriented Architecture)는 모두 재사용과 유연성, 그로 인한 비용절감 등 지향하는 바가 같다. 이 둘은 조직의 IT자원을 효율적으로 활용하고 이들간의 상호운영을 증진시키고 재사용할 수 있도록 지원한다는 공통점이 있기 때문이다. EA는 전사 확대 지원 표준 및 비즈니스부터 애플리케이션, 기술 아키텍처까지 소프트웨어의 서비스화를 위한 기반 아키텍처를 지원하고 SOA는 IT기능을 비즈니스 지향 서비스로 적용하는 방법을 의미한다. EA를 서비스 수준까지 세분화하면 SOA가 되며 SOA를 전사 차원으로 확대하면 EA가 된다. EA와 SOA는 닮은 듯 하면서도 상호 보안적인 관계로 볼 수 있다.
이희수 액센츄어 SI&T 그룹 이사 hee-soo.lee@accenture.com
