| |
|
Enterprise Architecture란 무엇인가?
Enterprise Architecture는 기업의 비전을 달성하기 위해 필요한 비즈니스, 데이터, 어플리케이션, 기술 IT 환경에 대한 구성요소를 분석하고 이들간의 관계를 구조적으로 정리한 체계(아키텍처)를 의미하며, 이러한 체계(아키텍처)에 근거해서 정의된 아키텍처 원칙 및 표준에 따라 IT 자원을 체계적이고 효율적으로 관리, 활용하기 위한 일련의 활동(프로세스)을 포함한다. 다시 말해, EA를 통해 전사 관점에서 기술 자원의 선정, 개발, 운영을 위한 명확한 가이드를 제공할 수 있도록 As-Is아키텍처를 분석하고, 아키텍처가 지향해야 할 원칙 및 표준을 정의하며, 기업의 사업비전을 반영한 To-Be아키텍처로의 이행을 위한 로드맵을 수립, 관리함으로써 끊임없이 변화하는 비즈니스 전략을 능동적으로 지원하여 기업 경쟁력을 강화하는데 이바지 할 수 있다.
Enterprise Architecture 왜 필요한가?
최근, 다수의 선진기업들이 Enterprise Architecture 관리를 추진하는 공통적인 배경에는 비즈니스 전략에 부합한 중장기 IT 청사진(Blueprint)을 수립하고 복잡해지는 IT기술 또는 자원에 대해 효과적인 관리를 하기 위해서이다. EA의 필요성에 관해, 우선 IT에 영향을 주는 기업의 비즈니스 전략이 시장 환경에 민첩하게 대응하기 위하여 지속적으로 변화하고 있다는 점을 주목해야 한다. 신규 비즈니스 전략에 IT를 지속적으로 연계해야 할 구심점의 필요성에 대한 사업부서 및 IT부서 모두의 이해가 요구되며, 쌍방간 커뮤니케이션을 가능하게 하는 일련의 도구가 필요한 것이다.
하지만 현실은, IT기술이 점점 비즈니스에 중요하게 인식됨에 따라 각 사업부서가 IT에 대한 의사결정을 주도하려고 하는 경향이 점점 두드러지고 있다. 예를 들어, 각 사업부서의 니즈에 따라 도입된 여러 기술자원이 중복 투자되고 있으며, 심지어 기술자원에 대한 현황 파악이 곤란하여 이러한 중복투자 여부도 파악하지 못하는 경우도 존재한다. 특히 IT부서의 입장으로 볼 때 신기술의 만연으로 기술 투자 시 올바른 선택이 점점 어려워지고 있기 때문에 기업환경에 적합하고 유연한 기술분류체계를 수립하고 체계적인 기술 라이프 싸이클 관리가 요구되고 있다. 운영측면에서 비즈니스와 IT 운영비용 감소에 대한 압력이 지속적으로 증가하는 추세이므로, 이를 해결하기 위해서는 기술자원의 표준화 및 혁신을 통한 TCO (Total Cost of Ownership)을 감소해야 할 것이다. 이러한 모든 이슈를 해결하기 위한 구심점이 바로 EA인 것이다.
Enterprise Architecture 사례: 국내 A사Business Context: A사의 경우, 정보기술 관련 부서가 다수 존재하며 부서간 고립된 IT관리체계로 인해 전사 표준 아키텍처가 미흡한 상태에서, IT R&D 업무체계 강화를 통해 도출된 다양한 신기술의 대두에 따른 기술 라이프 싸이클 관리에 대한 니즈가 중요시 되고 있었다. 다시 말해, 가치창출을 위해 새롭게 도입되어야 하는 신기술이 A사의 각 기술부서에 관리하고 있는 기존의 시스템에 어떤 영향을 미치고, 기존의 시스템은 어떻게 변화해야 하며, 신기술 및 기존 시스템이 어떻게 조화롭게 관리되어야 하는가에 답이 요구되었다. EA수립을 위해 고려되었던 사항들을 살펴보면, A사가 EA 프로젝트 수행 이전부터 기간시스템을 새롭게 개발하는 전사 아키텍처 혁신 과제를 수행하고 있다는 점, 과거 어플리케이션, 데이터, 기술 아키텍처 프로젝트를 수행하였으나 시스템 개발/운영 중심의 접근으로 아키텍처 측면의 기획/관리의 관점이 미흡했었다는 점이 고려되었다. 또한 어플리케이션, 데이터, 기술 아키텍처가 별도의 과제로 진행되어 수립되어 각 아키텍처 모델간의 연계가 부족하였고, 무엇보다 아키텍처에 대한 활용 및 관리에 대한 프로세스가 정의되지 않아 아키텍처 모델의 활용이 부진하였다. 이로 인해IT부서와 현업간의 의사소통이 제대로 수행되지 않았으며, IT부서의 전반적인 리더쉽 확보에 상당한 어려움이 존재하고 있었다.
Project Approach:A사의 EA 수립은 총 16주의 일정으로 ① EA Framework 정의 ② As-Is 아키텍처 분석 ③ To-Be 아키텍처 및 관리체계 수립 ④ To-Be 아키텍처로의 이행계획 수립 및 해외 벤치마킹 순으로 진행되었다. 본 프로젝트 수행을 위해 투입된 컨설팅 인력의 Skill Set을 살펴보면, 비즈니스 아키텍처 분석 및 수립을 위한 Industry 전문 인력을 비롯하여 어플리케이션, 데이터, 기술 아키텍처 각 부문별 전문 인력, IT Governance 전문 인력 및 Project Management를 포함한 총 6명으로 진행되었다.
A 사의 EA수립의 첫 단추는EA Framework을 정의함으로써 향후 EA사용자에게 EA에 대한 범위 및 내용에 대한 일관된 관점을 제공하는 의사소통 도구를 제공하는 것이었다. 즉, EA Framework을 통해 EA사용자는 아키텍처 모델(비즈니스, 어플리케이션, 데이터, 기술 아키텍처)은 어떻게 표현되고 있으며, 이에 영향을 주는 동인(경영전략, 기술전략, 비즈니스 요건, 경영방침)에는 어떤 것이 있으며, IT투자, 설계, 개발에 관한 의사결정을 위한 판단기준(원칙) 및 시스템 개발, 운영, 활용 시 지켜야 할 표준은 무엇이며, 또한 어플리케이션 모델을 관리, 활용하기 위해 어떠한 프로세스 (관리체계)를 밟아야 하는 가를 종합적이고 체계적으로 이해 할 수 있다. 그리고 이행계획 수립을 통해 As-Is 아키텍처에서 To-Be 아키텍처로 이행하기 위한 과제는 무엇이며, 과제 추진을 위한 과제간 우선순위, 연관성, 추진일정 등을 파악 할 수 있다.
<Enterprise Architecture Framework 및 구성요소>
EA Framework 수립을 통해 아키텍처 모델을 담을 수 있는 그릇을 만들었다면, 2단계로 그 그릇에 현행 아키텍처의 Content를 담는 작업인 As-Is 아키텍처 분석작업을 비즈니스, 어플리케이션, 데이터, 기술, Governance 각 부문에 걸쳐 수행하였다. 현행 아키텍처 분석작업은 주로 현업 및 IT 담당자와의 인터뷰, 시스템 사용자 매뉴얼, 데이터베이스 Table 구조 및 인터페이스 현황 정보, 시스템 구성도 등을 참조하는 방법을 사용하였다. 문제는 분석용 자료들이 공통된 형식(Template)으로 정의되어 있지 않았다는 점, 예를 들어 같은 어플리케이션 기능 구성도라 해도 Level이 서로 상이하기 때문에 EA Framework에 정의된 Level에 맞추는 작업에서 시간이 많이 소요되었다. 그리고 대부분의 참조 자료들이 Maintenance 과정에서 업데이트가 되지 않고 시스템 오픈 시점의 Out of Date 정보를 반영하는 수준으로 정확한 현행 정보를 획득하기 위해서는 IT담당자와의 인터뷰에 의존할 수 밖에 없는 한계가 있었다.
EA Framework에 따른 As-Is 아키텍처 분석이 끝남과 동시에, 3단계로 To-Be 아키텍처의 수립, 즉 As-Is 아키텍처에 변화를 줄 수 있는 모든 Initiative를 도출하여 To-Be 아키텍처를 정의하였으며 4단계로 To-Be 아키텍처로 이행하기 위한 Transition Plan을 작성하였다. 본 단계에서 발견된 사항은 Business Driven되는 Initiative를 도출하기 위해 현업과 인터뷰를 하는 과정에서 현업과 IT부서간의 Communication에는 현저한 한계가 있다는 점이다. 다시 말해, 대부분의 현업은 자신이 기획한 사업계획을 굳이 IT부서와 공유할 필요성을 느끼지 못하고 있으며, EA가 도입됨으로써 현업에게 어떠한 이익을 가져다 줄 것인가에 대한 회의감을 피력하였다. 즉 IT부서에서는 현업이 어떤 사업계획을 수립하였으며, 이에 기반하여 어떻게 시스템적으로 지원할 것인가에 대한 사전 준비 또는 계획이 사실상 어렵다는 점이다.
Lessons learned:
본 사례연구를 통해 발견된 어려 한계를 극복하기 위해서 요구되는 것은 수립된 아키텍처 모델을 어떻게 활용하고 관리할 것인가에 대한 Governance 체계를 새롭게 정의하여 현업과 IT가 제대로 Communication 할 수 있도록 해야 한다는 점이다. 아무리 EA사용자 (현업, 아키텍처 기획자, 관리자, 설계자, 개발자) 관점에 따라 아키텍처 모델을 추상화 수준에서 구체화 수준으로 상세하게 정의 해 놓아도 실제 각자의 업무에서 어떻게 사용되어야 하는 것에 대한 EA Governance 체계가 정의되어 있지 않다면 아키텍처 모델은 한때의 전시품으로 끝나 버릴 것이며, 결국 EA 사용자로부터 외면당할 것이 뻔하다. 추가적으로 EA Governance 체계 정의 시 주의해야 할 사항은 IT담당자가 EA를 ‘관리를 위한 또 하나의 관리’로 인식하는 것을 철저히 방지해야 한다는 것이다. 국내 A사의 경우, EA Governance에는 IT 사전 투자심의 과정 시 아키텍처 모델을 기반으로 투자 여부에 대한 의사결정을 지원하는 프로세스, 가이드라인, 체크리스트 등이 포함되었으며, 아키텍처 관리의 명확한 주체, 역할 및 책임, 아키텍처 모델 변경 시기 등이 포함되어 기술되었다. EA의 성공 열쇠는 바로 변화관리에 있다고 볼 수도 있다.
사례를 통한 Enterprise Architecture 도입의 기대효과
EA를 도입을 통해 사업부서와의 IT부서간의 효과적인 커뮤니케이션 증대를 위한 기반이 마련되었다. 전사 경영계획에 따라 미래에 필요한 비즈니스 역량을 전략, 프로세스, 조직, IT 종합적 관점으로 정의함으로써 사업부서와 IT부서간에 의사소통 할 수 있는 공통의 도구를 마련하였다. 그리고 견고한 아키텍처 관리체계를 수립하였다. 즉, As-Is 및 To-Be 아키텍처 모델을 동시에 관리할 수 있는 체계적인 관리 프로세스를 정의하고 아키텍처를 관리를 담당하는 아키텍트의 명확한 역할 및 책임이 부여됨으로써 아키텍처 관리 역량을 극대화 시킬 수 있을 것이다. 마지막으로 비즈니스와 IT 아키텍처에 대해 전사 관점의 통합 관리와 다양한 이해관계자 및 사용자의 실제 업무에서의 EA활용을 통하여IT 투자, 개발, 운영의 효율화를 제고함으로써 궁극적으로 기업 경쟁력을 강화할 수 있을 것이다. |
