EA 필요성과 접근 방향

본 자료는 IT Business Journal에 2006년 7월에 게재된 자료로 넥스젠테크놀러지의 류형규 대표이사의 기고문 입니다. EA와 ERP 및 ISP등과의 차별성과 보완성을 기술한 내용으로 전반적인 자원관리 계획의 추세를 알 수 있는 좋은 자료입니다.

- 서문 -

국내에서는 2~3년 전부터 EA(Enterprise Architecture)가 본격적으로 도입, 구축되고 있다. 대표적으로 금융과 공공부문으로 나누어지는데, 금융권에서는 차세대 시스템을 구축하기 위한 목적으로 은행을 중심으로 시작된 EA 프로젝트는 최근 보험, 증권으로 확산되어 가고 있다.

아직은 EA효과에 대해서는 언급하기에 빠른 시기이지만, 확실한 목적이 있었던 금융에서는 대체로 긍정적인 평가를 하고 있다. 금융의 EA 특징을 말하면, EA구축과 더불어 프로젝트 포트폴리오관리(PPM), IT투자성과관리(IT-ROI), IT자원관리(IRM) 시스템 도입과 연계, 통합을 하면서 IT거버넌스 체계로 확장되고 있다는 점이 관심거리이다.

공공부문은 2005년 12월 ‘정보기술아키텍처(ITA)’ 관련 법안이 국회 본회의를 통과 하고, 올해 7월 시행령을 앞두고 정부부처를 중심으로 ITA 도입과 구축이 활발히 추진되고 있다. 2008년까지 의무도입에 따라 2~3년간 본격적인 사업이 진행되리라 예상된다. ‘2005년 IFEAD’ 조사에 의하면 한국이 EA활동 국가 중 8위로 조사 되었다.

이러한 동향으로 볼 때 업종 형태와 규모에 상관없이 EA 도입과 구축은 점차로 확산될 것이며, 여기에 따라 바람직한 EA도입에 대한 인식과 또한 성공적인 구축을 위한 준비와 노력이 필수적으로 같이 이루어 져야만 할 것이다.

정보기술의 현재와 EA 필요성

최 근의 IT환경은 변화와 속도라는 도전에 직면해 있으며, 시간과 공간개념의 퇴색과 더불어 구체적 전략 실행을 통한 최대한의 역량을 발휘하고 최대한 빨리 변화하는 시장 상황에 대응할 수 있는 실시간 기업(Real-Time Enterprise)화를 절실히 요구하고 있다.

따라서 IT에게 비즈니스에 올바른 IT리더쉽과 능력이 요구되는 것 또한 당연한 흐름이다. 현재 기업 비즈니스의 한계(경쟁의 차별성 감소, 가격에 대한 압박, 수익성 하락에 대한 압박)를 극복하는 전략적 도구로 IT의 활용을 필요로 하고 있다. 이제 정보기술은 더 이상 사후에 문제가 아닌 비즈니스의 실질적인 원인이고 추진체인 것이다

앞으로의 경제 구조화에서 기업의 성공과 실패는 IT융합이 기업 전략으로서 우선시 될 것이다. 그러나 기업의 전략목표를 성취하기 위한 IT 원칙과 전략을 세우고 공식화하는 것은 쉬우나, 이런 “전략을 어떻게 실행하고 구현할 것 인가?” 라는 물음에는 다양하고 복잡한 문제를 만나게 된다. 이를 위해서 기업들이 지속적인 서비스 개선과 혁신을 꾀할 수 있도록 믿을 만하고 강력한 인프라(INFRA)인 구조(Architecture)를 개발하고, 활용하는 것이 필수 조건이 된다.

앞에서 말한 바와 같이 현재의 정보기술의 목표와 목적은 분명하다. 따라서 최근 세계 각국의 공공기관이나 기업에서는 동시 다발적으로 구조(Architecture)개념을 도입한 개선 발전된 정보기술 관리 방법의 필요성을 인식하고, 전략의 실행의 도구로 EA(Enterprise Architecture)를 적극적으로 도입하고 구축,활용 하고 있다.

전략의 실행과 구현을 통해 요구되는 주요 변화요소는 업무 프로세스, 정보 흐름, 어플리케이션, 기술 인프라 등이 여기에 해당 된다. 이것은 기업의 EA 구축 범위와 같은 요소 이다. 그리고 전략의 실행의 도구로서의 EA의 역할은 전략의 영향에 대한 식별 및 명확화 와 총체적이고 전사적인 관점의 설계도 제시이다. 또한 원칙에 기반한 가이드라인과 진화하는 모델링 제공하여, 구현을 위한 미래 상태에 대한 모습과 일관성 있는 통제와 의사소통을 제공하게 된다.

EA에 대한 이해

EA 구축과 활용에 대한 이해를 높이기 위해 EA의 이론적 개념을 잠시 살펴보기로 하자. 그리고 먼저 EA를 정의하기 전에 “구조(Architecture)” 와 전사적(Enterprise)” 의미를 살펴보면 다음과 같다.

구 조(Architecture)라는 용어는 산업 전반에 걸쳐 다양한 의미를 가지고 있다. 구조의 사전적인 의미를 살펴보면 두 개의 희랍어인 archi(시작, 원칙 등)와 tekton(벽돌 쌓는 사람, 석공)에서 유래되었다. 고대 희랍 사람들의 관점에서 볼 때 아키텍트(architect)란 대표적인 건축가 또는 숙련된 기술자를 의미한다.

현대에서 종합적인 정의로서의 아키텍처란 “건축의 예술 또는 과학, 건축의 방법이나 유형, 단일화 또는 논리적인 구조” 라고 할 수 있으며 건축과학, 디지털 시스템공학, 소프트웨어 공학 등 다양한 부분에서 적용하여 사용하고 있다.

전 사적(Enterprise)라는 용어는 공동의 목표를 추구하기 위해 고객과 상품 및 서비스가 존재하며, 이를 지원하기 위한 비즈니스 기능, 자산, 프로세스가 정립되어 수행하는 조직의 집합이다. 또는 기업이 수행하는 사업모델 단위로 비즈니스 변화 동인이 확인 가능한 조직이고, 전략을 정의할 수 있는 조직이라고 정의 한다.

EA(Enterprise Architecture)를 아키텍처와 엔터프라이즈 의미를 통해 정의 한다면, “기업의 비즈니스 전략을 효과적으로 지원하기 위한 업무, 애플리케이션, 데이터, 기술환경 등의 집합과 이에 대한 상호 관계를 총체적으로 표현한 체계” 라고 말할 수 있다. 그러나 EA의 역할과 활용이 다양해지고 진화 발전하고 있기 때문에 단순히 몇 문장으로 표현하기에는 한계가 있으며, 조직의 도입 목적과 중요성에 따라 조금씩 다르게 정의되고 있다.

이렇게 표현된 아키텍처의 적용은 구조화(Architecting: 시스템 구조를 설계하는 것 )를 통해서 구현하게 된다. 구조화를 통해 전체 시스템의 복잡도가 감소되고 관리가 용이하게 된다. 구조화를 통한 추상적인 산출물인 구조는 모델에 의하여 표현되며, 모델에 의해 시스템을 표현할 수 있다. 일반적으로 광의의 목표와 의미를 제외한다면 “EA 도입과 구축을 한다.”라는 말은 구조, 모델, 시스템을 표준화 기반으로 통합적으로 정의, 표현하고, 이행을 통해 기업에 적용하며, 아키텍처의 지속적인 변화관리와 활동 하는 것을 의미 한다.

현재 국내에서는 EA(Enterprise Architecture) 와 ITA(Information Technology Architecture) 용어를 특별히 구분하지 않고 같은 뜻으로 사용하고 있다. 하지만 특징적인 것은 대부분 민간기업에서는 ‘EA’로, 공공기관은 ‘ITA’ 로 사용하고 있다. 미국을 비롯한 대부분 국가에서는 일반적으로 2002년 미국 OMB(Office of Management and Budget) 주도로 시작된 비즈니스-기반 프레임웍 (business-based framework)인 FEA(Federal Enterprise Architecture)가 시작되면서부터 ITA보다는 EA로 불려지고 있는데, 이것은 EA가 비즈니스부터 동인됨을 강조하면서, 용어 또한 EA로 통일하려는 의도라고 볼 수 있다.

EA에 대한 오해

2004년 이후 국내에도 EA가 본격적으로 도입이 되면서, 다양한 오해와 잘못된 해석으로, 시작부터 어려움을 겪고 있다. 일부이지만 EA가 활성화 되기 전인데도 도입과 효과에 대한 부정적인 결론을 내놓는 경우를 자주 보게 된다.

어 떤 분야든 완전히 새로운 것은 없다. 필요에 의해 성숙되고 진화, 발전된다. 하지만 진화 발전된다고 해서 과거에 하던 방식과 모양이 같은 것은 절대로 아니다. 보통 기술자들은 새로운 기술용어를 접하게 되면 관심을 갖게 되고, 인터넷이나 이론적으로 정리된 자료와 단기간의 교육 수강 등으로 흔히 “그전하고 비슷하네.” 등으로 치부해 버리기 쉽다.

또한 개인의 지식 깊이에 따라 이해도가 흡수되어, 변질된 모습으로 나타나는 경우를 자주 보게 된다. 국내 대형 시스템통합(SI) 사장으로 재직 하셨던 분의 말씀이 생각이 난다. “나는 한 분야(기술)에 대하여 한 권의 책을 읽은 사람이 최고 무섭더라.” 라고 했는데, 여기에는 많은 의미를 내포하고 있다고 생각한다. 새로운 일을 성공적으로 할 때는 우선 정확히 알고, 합리적인 계획을 세우며, 올바르게 실행하는 것이 중요한 요소가 된다.

EA와 ISP는 다르다.

EA(Enterprise Architecture)와 ISP(Information Strategy Planning)는 다르다. 우선 수행 범위와 방식이 다르기 때문이다. 정보전략계획인 ISP는 의미 그대로 계획 수준에서 정보자원들의 아키텍처를 정의하고 향후 IT전략과제 도출 및 도출 과제의 이행계획을 수립하는 것이다. 하지만 EA 구축은 계획자 및 소유자 수준의 EAP(Enterprise Architecture Planning)에서부터 설계자 및 개발자 수준까지의 구조화(Architecting)를 통해서 모델과 설계를 수행하게 된다. 따라서 EA와 ISP는 비교 대상이 아니라고 이해하는 것이 좋다.

정보시스템 계획인 ISP와 비교 대상인 EAP의 차이점을 분석해 보면 쉽게 EA와의 다른 점을 발견할 수 있다. ‘Spewak의 EAP’ 책을 인용하여 설명하기로 한다. 일반적으로 EAP는 비즈니스에 종합적인 정의로 시작한다. 즉, ‘우리가 무엇을 하며, 비즈니스에 어떤 정보와 기술이 사용되느냐? 라는 질문에 의해서, 바람직한 비즈니스 모델을 정의하고, 정의된 비즈니스 모델은 비즈니스 특성과 아키텍처가 정의될 수 있는 안정적인 기반을 제공한다.

그리고 아키텍처는(데이터, 애플리케이션, 기술) 각각의 요구사항이 아닌 비즈니스 중심으로 요구를 지원할 수 있고, 그들 아키텍처는 강한 연결고리를 갖도록 통제 된다. 따라서 EAP는 비즈니스의 지원을 위한 정보와 기술에 초점을 맞추어 단기운영과 장기전략이 모두 고려되어 계획된다.

그러나 전통적인 ISP는 ‘어떤 정보 시스템이 필요하며’, ‘현재 동향에서 무엇이 중요한가?’ 에 초점이 맞추어 지며, 대체로 단기운영 비즈니스 영역의 자동화만을 고려하고 있다. 기업에 따라서 보통 3년을 주기로 ISP를 수행하게 되는데, 그전에 수립한 계획은 대부분 활용 가치를 상실하게 된다. 최근에는 중장기 계획을 위한 ISP가 수립 되고 있는데, 이런 현상과 요구는 EA도입의 필요성을 더욱 명확하게 하고 있다.

EA 도입 및 활동 분석

IFEAD 의 2005년 3차 보고서에 의하면, 2004년에 이어 2005년에도 미국(1위), 영국(2위), 호주(5위) 등의 국가가 지속적으로 가장 활발한 EA활동을 진행하고 있으며 인도(6위), 한국(8위), 일본(11위) 등의 국가가 그 뒤를 이어 활발한 EA활동을 하고 있는 것으로 나타난다.
조직에서 왜 EA가 중요한가? 에 대해서 10개 항목을, 어떤 문제로 EA를 계획하고 있는가? 에 대해서 9개 항목을 설문 조사한 결과는 다음과 같다.

· 조직에서 왜 EA가 중요한가? 에 대한 질의에서는 2003년에서 2005년에 걸쳐 ‘변화를 위한 로드맵 실현(Delivers road map for change)’ 부문과 ‘의사결정지원(Supports decision making)’부문의 중요성이 높은 비중을 차지해 왔다. ‘IT포트폴리오 관리(Manages IT portfolio)’ 부문은 과거 년도에 비해 2005년에 크게 중요성이 부각된 반면, ‘복잡성 관리(Managing complexity)’부문은 다소 중요성이 떨어졌다.

·어떤 문제로 EA를 계획하고 있는가? 에 대한 질의에서는 2003년과 2004년을 비교해볼 때 ‘EA가 로드맵 변화(Transformation road map)’ 이슈에서 큰 상승세를, ‘비즈니스 IT간 연계(Business-IT Alignment)’ 이슈에서는 감소를 보였는데, 2005년도 결과에서는 ‘Business와 IT간 연계’ 이슈가 큰 폭으로 상승하였고, ‘로드맵 변화’ 이슈에 대한 부분은 2004년과 유사한 수준을 나타냈다. 그리고 ‘인프라구조 재구축(Infrastructure renewal)’ 이슈는 뚜렷한 감소를 보이고 있다.

결론적으로 EA도입과 활용에서 중요시 되는 항목은 로드맵 실현(Delivers road map for change), 의사결정지원(Supports decision making), IT포트폴리오 관리(Manages IT portfolio), 로드맵 변화(Transformation road map), 비즈니스 IT간 연계(Business-IT Alignment) 이다. 이에 반해 인프라구조 재구축(Infrastructure renewal) 이슈는 뚜렷한 감소를 보이고 있는데 이는 EA의 목표 지향점을 강하게 시사하고 있다.

분석을 통해서 지속적으로 중요시 되는 항목들을 보면, IT거버넌스 영역에서 핵심적으로 관리되는 필수 항목이기도 하는데, 이것은 EA가 IT거버넌스 체계의 한 부분으로 인식되고 활동한다는 말하고 있다. 또한 EA와 IT거버넌스 활동은 유기적으로 통합되어 기업 전략목표를 성취하기 위한 IT전략을 세우고 현행화 하는데 핵심적인 역할을 하게 된다고 말할 수 있다.

EA 성숙도와 IT 거버넌스

EA가 IT거버넌스의 체계에서 핵심 부분으로 인식되고 활동하게 된다는 점이 강조된다면, IT거버넌스(IT Governance)가 무엇이고, EA와의 관계성에 대해서 먼저 알아 볼 필요가 있다. IT거버넌스 협회인 ITGI에서는 IT거버넌스를 “ 이사회와 경영진의 책임아래 수행되는 기업 지배구조의 일부로 IT가 조직의 전략과 목표를 유지하고 확장할 수 있게 하는 리더십, 조직구조, 프로세스” 라고 정의하고 있다.

또한 최근 IT거버넌스에 대한 관심이 높아지는 이유는 IT가 기업 및 조직의 비즈니스 전략의 핵심 요소로 인식되고, IT의존도가 심화되면서, IT투자에 대한 비용의 급속히 증가하는 현상을 발생하고 있다. 따라서 기업들은 전략 도구인 IT의 바람직한 사용과 관리, 그리고 IT투자성과관리 등에 필요성에 대한 인식이 높아지고 있다.

IT 거버넌스는 EA와 같이 IT가 비즈니스의 목표 달성을 지향 한다는 점과 IT전략을 구체적으로 실현하는 역할로써 동일한 목적을 갖고 있다. 따라서 EA를 도입하고, 구축하기 전에 IT 거버넌스에 대한 전제는 아키텍처 도입과 구축의 중요한 요소이며, 구체적인 목적과 효과를 만들어 나가는 목표가 되는 것이다.

 미 회계 감사원인 GAO(General Accounting Office)의 EA 성숙도 모델에서 제시하는 단계별 내용 설명을 통해서 다시 한번 EA의 성숙도와 IT거버넌스 관계성을 강조하고자 한다

1. 인지 단계: EA를 인식하기 시작하는 단계로 EA를 사용하거나 향상시킬 계획이 없으며, EA에 대한 효과를 인식하지 못하는 상태이다.

2. 기반구축 단계: EA관리 기반을 구축하는 단계로 EA 아키텍처 개발을 위한 계획 수립과 책임과 역할을 정의 하고 , EA Framework 및 관리체계 수립이다.

3. EA 개발 단계: 아키텍처 구축 개발 단계로, 실질적인 EA 산출물 개발에 초점을 두고, 전사를 포함하는 범위에 대해서 제도적인 정책 및 지침을 정의한다.

4. 완성과 활용 단계: EA 아키텍처 완성단계로 기관이 사용할 수 있도록 결정된 EA 산출물들이 정보기술 투자자원 구성을 통제하고 선택하는 것을 지원한다. IT자원관리를 통하여 투자의사의 결정자료를 수집하고 IT 투자를 EA에 따라서 하도록 하는 정책을 수립한다.

5. 관리와 개선 단계: 변화관리 수단으로 EA를 사용하고 EA유지보수를 위해 문서화되고 승인된 정책에 따라 아키텍처를 진화 시키고, 조직의 의사결정에 EA를 연관시키며, EA의 효과 성을 측정하기 위하여 매트릭스를 적용한다.

EA 성숙도 모델을 단계별로 살펴보면 1단계에서 3단계까지는 EA 도입과 아키텍처 개발에 초점이 맞춰지지만, 완성과 활용 단계인 4단계부터는 EA 완성을 통해 IT거버넌스 체계와 활동을 구체적으로 지원하는데 초점이 맞추어 지고 있다.

EA추진 필수 구성요소

EA 성숙도 2단계에 해당하는 기반구축으로는 EA방법론 과 EA프레임워크 수립이며, 성숙도 3단계로는 EA 구축, 참조모델, EA Repository 이다. 성숙도 4단계의 EA완성과 활용에는 EA거버넌스 수립과 이행계획을 통해서 강력하고 지속적인 아키텍처 관리가 필요하다.

이유는 EA 도입 성공 여부가 이때부터 구체적으로 나타나기 때문이다. 산출물인 아키텍처가 예산, 투자, 프로젝트 사업관리에 적용 활용되는 4단계에서는 시스템 구축과 통합이 유기적으로 이루어 져야 할 것이다.

이 러한 시스템 도입과 구축은 기반구축 초기부터 계획되어야 한다. 도입된 시스템과 산출물인 아키텍처는 지속적인 개선과 고도화 작업을 걸쳐야 비로서 활용단계에서 제대로 된 효과를 낼 수 있기 때문이다. 구성요소의 자세한 설명은 2장에서 하기로 하겠다.

EA성공을 위한 핵심 요소

이번 장 마지막으로 EA를 성공하기 위해서 꼭 필요한 요소와 장애 요인에는 어떤 것들이 있는지 살펴보기로 한다.

첫째, 최고 경영자와 중역들의 올바른 인식과 적극적인 의지가 가장 중요한 성공요소라고 말할 수 있겠다.
누 구나 쉽게 말하는 요소이지만, 가장 어려운 요소이기도 하다. 과연 경영층에게 ‘어떻게 EA를 인식 시키고, 자신들의 역할을 인정하고 지속적인 활동과 지원을 약속 받을 수 있을까?’ 라는 것이다. 성공 사례나 세미나 등의 방법도 좋지만, 많은 어려움이 예상된다. 이 경우는 외부 컨설턴트의 도움을 받는 것도 좋은 방법이다.

둘째, EA를 도입하는 목적이 명확 해야 한다.
앞 서 IFEAD 동향 조사 항목에서도 설명 했지만 EA 도입 목적을 예로 들면 ERP구축, Business변화, M&A, 어플리케이션 재구축, 로드맵 변화, 비즈니스 & IT간 연계, 인프라구조 재구축, 기간계 시스템 변화 등의 이슈들이 있는데, 도입 목적과 활용 방안이 명확할 때 성공할 가능성이 크다.

셋째, 장기적 계획과 전담인력 확보이다.
EA 의 성과는 단기적으로는 나타나지 않기 때문에 장기적 안목과 계획으로 인정 받을 필요가 있다. EA의 동인은 ‘비즈니스’ 라고 반복 설명 했다. 전사 업무를 범위로 하되 핵심업무를 중심으로 점진 반복적인 방법으로 구체화와 통합을 병행해 나가야 할 필요가 있다.

단순히 EA 기반과 아키텍처 구축을 했다고 단기적인 효과를 바라는 것은 현실적으로 어려운 일이다. 이와 함께 EA 구축에 필요한 합당한 전담 조직과 인력을 확보 하는 것이다. 구축을 위한 전담인력과 구축 후 EA 변화관리를 지속적으로 유지 관리할 조직과 인력이 필요하다.

넷째, 정보 시스템(IS) 조직의 우호적인 협조 문화와 EA에 대한 올바른 교육이 선행되어야 한다.
국 내 경우 1980년 초반까지 대부분 IS는 기업을 위한 중앙집중 데이터처리 부서였다. 따라서 전통적인 IS는 조직과 역할이 단순했다. 하지만 급격히 변화하는 기업 혁신과 생산성 속도에서 IT의 역할이 강화되면서 IT의 투자, IS조직의 확대 등의 변화가 생겼다.

하지만 이러한 IT의 성공이 불러온 높은 기대 수준과 요구와는 별개로 IS는 위상은 상대적으로 낮아지는 현상이 발생하고 있다. 원인은 여러 가지 측면이 있지만 중요한 원인으로 IS조직의 역할이다. 현재와 미래의 IS에서 유지해야 할 5가지 핵심 역할로 IT 리더쉽, 아키텍처 개발, 비즈니스개선, 기술 진보, 벤더관리 라고 이야기 한다. 그러나 EA를 추진하다 보면 많은 걸림돌이 IS에서 나온다는 불만에 소리가 있다.

정보시스템(IS)에서 IT 및 EA 리더쉽을 갖고 우호적 협조 문화가 형성되어야 하는 것이 당연하지만, 현실적으로 IS 문화 그리고 권한과 역할에 대한 불안감 등으로 인해 어려움을 토로 하고 있는 실정이다. 따라서 EA에 대한 IS 조직의 우호적 문화와 IT리더쉽 등의 역할 변화 그리고 IS 인력들의 심도 깊은 사전 교육과 EA 역할에 대한 인식은 EA 성공의 중요한 요소임을 다시금 강조하고 싶다.