EA와 ITA는 어떻게 다른가

[출처] http://www.ciobiz.co.kr/news/articleView.html?idxno=4850

 

EA와 ITA는 어떻게 다른가

EA와 ITA를 동일시하면 EA의 진정한 가치 제공은 요원

2011년 02월 13일 (일) 19:18:00   브루스 로버트슨 가트너 부사장 bruce.robertson@gartner.com

<script type="text/javascript">< /script> <script language="javascript"> </script> 많은 기업에서 엔터프라이즈 아키텍처(EA)를 IT 아키텍처(ITA)와 동일시하고 있어 성공적인 EA 구축이 어려운 것으로 나타났다. 가트너는 EA 프로그램을 IT 중심적으로 구성하면 기업이 비즈니스 성과를 개선할 수 있는 기회는 물론이고 EA의 진정한 가치를 얻을 수 없다고 지적하고 있다. EA 구축에 IT 지원이 필요하고 세분화된 기술이 비즈니스 개선에 큰 기여를 하지만 EA가 IT 프로젝트는 아니다. 그러나 대단히 많은 기업에서 EA를 IT 프로젝트로 간주하고 있으며, 최고정보책임자(CIO)나 IT 조직에서도 역시 EA는 IT에 관한 것이라고 생각하고 있다. EA 중에서 기업기술 아키텍처(ETA)가 ITA에 해당될 뿐이다. 가트너는 2010년 200여건의 EA 구축 사례를 조사했는데 이 중 30%의 기업에서 EA 실무자들이 ITA라는 용어를 사용하며, IT 관계자들은 더 빈번하게 사용하는 것으로 확인됐다. EA 담당부서가 CIO에게 보고하는 조직체계로 인해 용어에 대한 오해가 발생하고 있으며, 이 때문에 ITA와의 관계가 밀접하게 여겨지는 것도 사실이다. 하지만 EA의 역할은 단순히 IT를 개선하는 것이 아니다. 기업 전체를 개선하는 것이 EA다. EA추진팀은 관계자들의 이해도를 높이고 전사적인 공감대를 형성하기 위해 프로젝트 초기 단계에서 EA 효과를 명백히 전달하고 확신을 주는 데 집중해야 한다. 또 EA에서 ITA만을 다루는 것으로는 충분하지 않다는 점을 전사적으로 공감할 때까지 이 같은 메시지를 전달해야 한다. EA를 언급할 때 ITA라는 용어를 사용하게 되면 EA의 전체 범위와 가치가 왜곡된다. 또 EA 프로그램에 존재하는 리스크가 간과될 수 있다. ITA는 EA와 동일시되어서는 안 된다. 일반적으로 ITA는 EA에서 ETA만을 뜻하며, 개별 솔루션 혹은 프로젝트 아키텍처 작업을 항상 포함하게 된다. EA에서는 이러한 작업이 매번 발생하지는 않는다. EA 프로그램을 ITA에서 시작할 수는 있으나 전체 EA로 발전해 나가는 과정에서 지나쳐야 하는 한 단계일 뿐이다. EA를 명확히 이해하기 위해서는 ITA의 개념부터 이해해야 한다. ITA는 △ETA △ETA와 기업솔루션 아키텍처(ESA)-애플리케이션 포트폴리오 관리(APM)만 포함 △IT 사업부만을 위한 EA 세 가지 의미를 지닌다. 어떤 것이든 EA는 아니며, 이렇게 쓰이면 EA 범위를 제한하게 된다. ◇ETA로서 ITA는 EA의 일부일 뿐=우선 ITA가 ETA만을 뜻할 때의 장점은 기본에 충실하다는 것이다. ETA 구축작업은 잘못된 것이 아니다. 가트너 역시 ETA와 관련한 많은 연구를 해왔다. EA 프로그램의 한 부분으로서 IT 중심적인 이슈와 1차적인 기술 이슈를 다룰 필요가 있다. 이는 기업에 타당한 관점이다. EA팀들이 ETA 작업으로 시작하는 것이 일반적이긴 하지만 ETA가 EA의 전부는 아니다. 보다 이상적인 EA는 기업비즈니스 아키텍처(EBA), 기업정보 아키텍처(EIA)를 포함하며 솔루션 포트폴리오 관리, 솔루션 패턴, 개별 솔루션 아키텍처 업무 지원을 포함한다. 또 ETA가 ESA와 함께 시너지를 발휘하는 것도 포함된다. EA는 비즈니스 전략과 트렌드에 긴밀히 대응하는 비즈니스 콘텍스트 속성을 갖고 있기 때문에 비즈니스와 기업 아키텍처 변화를 위해 프로세스나 인력 등 필요한 요건을 끌어낸다. 그리고 이러한 변화 요건은 IT전략과 연결된다. 이 모든 일은 EA 플래닝을 통해 이뤄진다. EA는 IT전략에 의해 결정되는 것이 아니다. EA는 비즈니스 전략에 의해 결정되고 구축되어야 한다. EA가 비즈니스 전략에 따라 구현될 때 EA가 IT전략을 이끌어갈 수 있다. 만약 EA를 주도하는 것이 IT전략이라면 이는 EA가 아니라 ITA를 구축하기 위한 것이다. 나아가 EA팀은 비즈니스 콘텍스트와 변경 요건 분석, 업무 프로세스 혹은 인력 변동의 분석에서도 완전히 배제될 것이다. 비즈니스 분석 과정에서 배제되면 모든 전략적 IT 결정은 비즈니스 중심이 아니라 IT에 관해서만 이뤄지게 된다. 비즈니스 전략과의 연계, 조율과 통합이 부족해지고 타당성도 얻지 못하게 된다. 따라서 실무자들의 지원을 확보하기 어렵다. ITA 관점의 접근은 정보 자체를 분석하진 않고 해당 정보를 관리 및 저장하기 위해 어떤 기술이 필요한지에만 중점을 둔다. EA는 IT 변화에만 초점을 맞추는 것이 아니다. EA는 비즈니스 변화를 다룬다. 비즈니스 콘텍스트를 파악하는 EA 전략화 과정의 일환으로 서로 다른 EA 영역들 간 변경 요구를 끌어낼 때 IT전략과 투자 간의 비즈니스 연계성이 더욱 투명하게 드러난다. 기술의 변화는 다시 정보, 인력 또는 프로세스 변화, 나아가 비즈니스 전략 전체에 대해 연결되어야 한다.     다양한 의미의 ITA와 EA 비교 ◇ETA와 일부 ESA로서의 ITA=기술에만 집중하는 ITA의 대안으로 일부 기업에서는 APM을 추가하기도 한다. 개선점은 애플리케이션 관점이 추가되었다는 것이다. 기술 변화가 적어도 애플리케이션 수요와는 연동되기 때문이다. 이는 EA 구축의 좋은 출발점이 될 수 있다. 하지만 역시 온전한 EA 접근방식만큼 효율적이진 않다. 온전한 EA 관점과 APM이 결합되면 애플리케이션 솔루션 포트폴리오에 대한 EBA 및 EIA 변화 요건이 훨씬 긴밀하게 연계된다. 또 애플리케이션뿐 아니라 전체 솔루션 포트폴리오를 다룬다. ETA와 일부 ESA 관점의 ITA는 애플리케이션 변화에 대해서 로드맵을 정의하고 기술 변화를 매핑할 수 있다. 그러나 비즈니스에서의 변화 필요성은 감지하기 어렵다. 상향식 접근방식이기 때문에 프로세스, 인력, 정보에 관한 이슈에서 비즈니스 변화를 정의하지 못했기 때문이다. 프로세스, 인력, 정보의 변화는 IT보다 비즈니스에 훨씬 더 큰 영향을 주며 긴밀한 사안이 된다. 이 점을 비즈니스 부서에서 이해한다면 필요한 기술 및 애플리케이션 변화에 대한 지원을 얻기가 쉽다. 그렇지 않으면 IT는 여전히 비용센터로 남게 된다. 게다가 이러한 ITA 접근방식은 프로젝트나 솔루션 아키텍처 작업을 포함하는 경향이 있다. 이 작업은 한 번에 하나씩 추진되는데, EA팀은 프로젝트와 EA 업무 사이에서 우왕좌왕하다가 점점 EA 업무를 소홀히 하게 되는 것이 일반적이다. 프로젝트에서 개별 솔루션 아키텍처 구현은 필수 작업이지만 이는 EA 업무라고 할 수는 없다. EA는 한 번에 한 프로젝트, 하나의 애플리케이션, 한 사업부에 중점을 두는 것이 아니다. EA는 한 번에 한 시스템의 아키텍처를 구성하는 것에 그치지 않고 기업 전체의 아키텍처를 구성하는 것에 주안점을 둔다. 물론 성숙한 EA 접근방식도 솔루션 아키텍처와 통합해야 한다. 이러한 솔루션 아키텍처는 EA의 일부라고 할 수 있으며, EA를 활용해 솔루션 아키텍처를 개선하는 것도 EA의 목표임은 분명하다. 그러나 EA는 단일 시스템 솔루션 아키텍처에 중점을 두는 것은 아니다. ◇IT사업부만을 위한 EA=EA를 기업의 단일부서에만 적용하는 접근방식도 있다. IT부서만으로 대상을 제한하는 것인데 이 경우 ITIL, 소프트웨어개발수명주기(SDLC), 일부 EBA 업무를 운영하게 된다. 적용 대상을 제한했지만 전체적인 EA 접근방식을 사용하면 적어도 EA팀과 EA 고객(이 경우에는 IT조직)은 기술 및 솔루션 포트폴리오에서 벗어나 보다 포괄적인 사고를 시작할 수 있다. 또 비즈니스와 정보 아키텍처를 중히 여기며 IT사업부 밖에서 활용할 수 있는 능력을 기를 수 있다. 다른 사업부서에도 EA의 가치를 보여줄 수 있다. 따라서 이 접근법은 IT조직은 EA를 이해하고 지지하지만 비즈니스 부문으로부터는 강력한 지원을 얻지 못한 조직에서 EA 초기단계에 취할 수 있는 방식이다. 하지만 EA 업무가 항상 IT 변화 또는 기업 내 IT 역할에 대해서만 이뤄진다면 EA가 영향을 줄 수 있는 일부 비즈니스 변화를 놓치게 될 것이다. IT 변화와 비즈니스 변화를 직접적이고 필수적으로 연계하지 못하는 단점은 여전하다. 예를 들어 IT비용을 낮추는 데 주력하되 이 문제를 인력, 프로세스, 정보 변화와 함께 다룬다면 총소유비용(TCO) 관점에서 대응할 수 있게 된다. 하지만 더 큰 문제, 즉 비즈니스 아키텍처 구현 문제는 남아 있다. 기업의 운영비용 중 95%가 비즈니스 부문에서, 단 5%가 IT 부문에서 지출된다는 점을 감안하면 더욱 안타까운 일이다. 다른 두 가지 방식의 ITA보다는 발전된 방식이긴 하지만 IT사업부만을 위한 EA 역시 비즈니스 동인과 미래를 다루진 못한다. 비즈니스의 비용 절감 요인을 찾아내지 못할 것이며, 왜 비즈니스 비용 절감을 위해 IT 지출을 늘려야 하는지도 설명하지 못할 것이다. 또 비용 절감 혹은 기존의 목표나 비즈니스 전략 이상의 것은 다루지 못한다. EA는 그 이상을 반드시 찾아야 하며 EA 및 IT 업무가 비즈니스 지출 및 전략과 연계되어 있을 뿐 아니라 직접적으로 시너지를 창출해 성공을 지원할 수 있도록 해야 한다. ITA는 여러 뜻을 갖고 있지만 그 어떤 정의도 EA는 아니며, 각 정의는 EA 가치 창출을 제한하는 한계점을 갖고 있다. 이러한 IT 접근방식은 EA 구현 초기에는 쓸모가 있지만 가치 있는 EA 접근방식으로 가기 위한 교두보로서만 사용되어야 한다.   브루스 로버트슨 가트너 부사장 겸 수훈애널리스트 bruce.robertson@gartner.com