‘표준준수와 당면과제의 갈등’ 기업 아키텍트를 위한 가이드

기업 아키텍트는 애플리케이션 솔루션 패키지 선택에 있어 조직에 막대한 혜택을 안겨줄 수 있다. 이들 솔루션의 ABV(Architectural Business Value)를 평가하는 작업을 통해서다. 포레스터 리서치의 랜드 헤프너가 그 방법을 소개한다.

기업 아키텍트(enterprise architect)가 일을 제대로 한다면 조직이 애플리케이션 솔루션 패키지를 선택하는데 엄청난 혜택을 누릴 수 있다. 최신 기술에 내재되어 있는 아키텍처는 의도하지 않은 결과들을 초래할 수 있는데, 기업 아키텍트가 이를 분석해낼 수 있기 때문이다. 특히 구내에(on-premise) 배치되든 SaaS를 통해서든 주요 앱 솔루션 선택에서는 그 가치가 더욱 빛을 발한다.

앱 패키지 선택 과정에서 아키텍트들은 오랫동안 주로 조직 내 기술 표준의 관리인 역할을 도맡아 왔다. 아키텍트들은 그토록 표준들에 치중하는 경향을 보이는 이유는 뭘까? 다른 모든 것들이 동일하다면 IT 표준들을 고수하는 것이 장기적인 가치를 달성하는데 도움이 되기 때문이다. 하지만 문제는 여기에서 시작된다.

다른 모든 것들이 동일한 경우는 거의 없다. 즉 단순히 표준 준수만을 고수할 수 없음을 의미한다. 앱 패키지를 결정하는데 적절한 방식으로 기여하기 위해서는 각 후보 솔루션마다 아키텍처의 사업 가치(이하 ABV: Architectural Business Value)를 분석하고 평가해야 한다. 포레스터(Forrester)가 ABV에 대해 다음과 같이 정의한다.

후보 솔루션의 총 경제적 효과(TEI: total economic impact)의 추정 값이다.

1) IT 표준들과 솔루션의 차이로 인해 요구되는 조직적 및 기술적인 조정 과정에 따르는 지속적인 비용들.
2) 그 솔루션의 아키텍쳐가 다른 솔루션들과 비교했을 때 가지는 강점들에 의해 생기는 지속적인 이익들.

아키텍트에게 있어서 솔루션을 선정하는 팀에게 ABV의 개념을 가르치는 것이 첫 번째 과제다. 조직, 폭을 좁혀감, 평가, 결정이라는 네 단계에 걸쳐 초기 ABV 모델을 세우고 ABV에 영향을 미치는 핵심 요소들을 식별해낸 뒤 핵심 요소들을 시험해 효과를 확인하면 ABV를 팀에 의해 마련된 포괄적인 경제 분석에 통합시킬 수 있을 것이다.

조직 단계에서는 ABV를 선택 과정의 일환으로 구축하라
팀이 체계적으로 조직되어 가면서, 아키텍트들은 팀이 ABV를 선택 과정의 일부로 인식하고 통합시키는 것을 주된 목표로 삼게 된다. 이를 달성하기 위한 조언은 다음과 같다.

신뢰성을 확립하라. 아키텍트들의 목표는 사업 분석이며 기술 분석은 오로지 사업 비용, 이익, 위험성, 그리고 다른 추후의 옵션들을 파악하기 위한 것임을 확실히 하라.

ABV에 대한 지원을 구축하라. ABV를 분석의 프레임워크로써 소개하라. ABV를 후속 효과, 숨겨진 비용, 현재의 기술 결정에 따른 미래의 기회 등을 정량화하는 수단으로 설명하라.

프로젝트 헌장에 ABV를 포함시켜라. 다른 것들 사이에서 프로젝트 헌장은 선택의 결정이 어떻게 이루어지는지를 정의한다. ABV가 결정 모델의 일환으로 인정되고 합의될 것과 함께 ABV의 평가 작업과 예산으로 선별 프로젝트가 구성될 것을 목표로 삼아야 한다.

선택을 좁혀가는 단계에서는 자체적인 ABV 모델을 구축하라
선택을 좁혀가는 단계에서는 우선 순위를 정하고 각 최종 후보의 ABV에 기여하는 가장 중요한 요소들을 파악하는 것을 목표로 삼아야 한다. 아키텍처 가치에 대한 평가는 단순히 최신 아키텍처들이 좋다고 가정할 것이 아니라, 주로 각 장점들과 사업 전략 및 목표와의 연계성에 의해 판단되어야 한다. 스스로의 ABV 모델을 구축하기 위해서는 다음과 같은 작업이 필요하다.

먼저 각 예비 후보 제품들에 대해 빠르게 검토하라. 실효성 있는 후보들을 선별해가면서, 선별 팀은 패키지의 애플리케이션 플랫폼이나 SOA와 같은 최신 아키텍쳐에 대한 지원 등 각 후보에 대해 가장 효과적인 ABV 항목들을 재빨리 파악하고 항목을 작성하게 된다.  

팀에 ABV의 대략적인 비교를 제공하라. 다양한 선택 사항들에 대한 장단점을 토론하고 영역을 좁혀가는 것에 대해 고려하게 되면, 후보들의 상대적인 ABV에 대한 개략적이고 상당히 규모가 큰 비교를 제공해야 한다.

팀이 범위를 좁혀나갈수록, 분석을 심화시켜라. 시간이 있다면, 그리고 최종 후보를 결정해야 한다면, 분석을 확장시켜 나머지 팀원들에게 가장 지지를 받는 후보들에 대해 초기 재정 견적을 세워야 한다.

ABV모델을 통해 최종 목록을 얻음으로써 마무리하라. 팀이 최종 후보를 2~5개 정도로 좁히고 선별 기준을 발전시켜 나가면 후보들 사이에 동일한 요소들은 무시하고 서로 다른 ABV 요소들의 차이점들을 분류하라. 그리고는 가장 큰 효과가 예상되는 것들부터 시작하여 평가 단계에서 이루어질 구체적인 ABV 분석을 위한 모델을 구축하라.

평가 단계에서는 ABV 분석을 완성하라
ABV 분석을 이행하기 위해서는 문서 기반의 작업과 실험 기반의 작업들이 함께 이루어져야 한다. 시험 항목들을 놓고 제공업체가 표준들을 준수했다고 강력하게 주장하고 있는지 여부를 확인하는 것이 좋다. 모든 주요 ABV 요소들을 분석할만한 충분한 시간이 없다면 우선순위를 정하여 가장 큰 효과를 낼만한 요소들부터 분석을 진행하면 된다. ABV 분석을 완성하기 위해서는 다음과 같은 작업이 필요하다:

각 후보에 대해 실험 테스트를 구성하고 실시하라. 본사 팀의 랩이든 제공업체의 랩이든 혹은 (SaaS 제품의 경우) 인터넷을 이용하든, ABV 모델의 요소들을 확인하고 가치를 부여하기 위한 특정 검사들을 실시하라. 각 후보의 ABV 요소들이 다를 수 있기 때문에 모든 후보에 대해 반드시 같은 테스트를 진행할 필요는 없지만, 테스트 내의 모든 차이들에 대해 나름의 원인을 밝혀 설명할 수 있어야 한다.

나머지 ABV 요소들에 대해서는 문서 기반의 분석을 수행하라. 실험을 통해 검사할 수 없거나 시험해볼 시간이 없는 ABV 요소들에 대해서는 문서를 기반으로 분석하면 된다. 새로운 IT 운영 절차로는 무엇이 필요할 것인가? 표준을 충족시키지 못하는 기술들로 인해 조직은 새로운 직원을 고용해야 하는가, 혹은 다른 앱들에 대한 지원 수준을 낮춰야 하는가? 기업의 IT 표준에서 벗어난 기술들을 개발자들에게 이해시키기 위해서는 어느 정도의 비용이 소요될 것인가?

ABV 분석을 팀의 TEI 분석에 통합시켜라. 실험 결과들과 문서 기반의 분석들을 가지고 ABV 분석의 위험성과 유연성 측면을 결정하라.

결정 단계에서는 전반적인 사업 가치가 가장 높은 제품을 지원하라
ABV 분석을 나머지 팀 분석에 통합시키고 나면, 기업인으로서 본인의 신뢰도를 선보일 시간이다. 기업가의 마음가짐으로 조직에 사업 가치를 전반적으로 가장 많이 제공해줄 제품을 지지해야 한다.

아키텍트들은 앱 솔루션 패키지뿐만 아니라 정치적인 문제에 따른 조직의 다른 많은 아키텍처 결정에 참여하게 될 수 있다. IT를 신뢰하지 않는 기업 경영인들은 종종 모든 솔루션에 대한 가장 빠른 경로를 원한다. 또 프로젝트 마감 시한이 있는 애플리케이션 딜리버리 팀들은 보통 아키텍처의 제약들에 대해서는 인내심이 없다.

IT 표준의 집행자로서, 아키텍트들은 종종 사업 가치보다 일관성에 더 높은 우선 순위를 부여한다. 사업 기술 아키텍처에 관련된 많은 종류의 결정들에 있어서 ABV는 아키텍트들로 하여금 아키텍처의 표준들로부터 벗어나서 사업의 순익에 관한 논의로 재구성할 수 있게 한다. 아키텍트들은 마땅히 지향해야 할 기업인으로서의 신뢰도를 구축함으로써 표준과 비즈니스 가치 사이의 갈등을 조율할 수 있다.

 * 랜디는 포레스터 리서치의 부사장이자 수석 애널리스트이다. 그는 지속적인 사업과 기술 변화에 직면하여 안정되고 복구가 빠른 기업 애플리케이션들을 구축하기 위한 설계적 접근과 아키텍처 분야에 있어서 선도적인 전문가이다. 이러한 맥락에서 서비스 지향 아키텍처(이하 SOA: Service-Oriented Architecture)는 랜디의 주요 관심 영역이다. 기업 애플리케이션들이 SOA 이상을 요구하는 까닭에, 랜디는 SOA를 둘러싼 광범위한 아키텍처 컨텍스트(architectural contet)를 제공하는 포레스터의 디지털 비즈니스 아키텍처(Digital Business Architecture)를 개발했다. 랜디는 지난 7년동안 포레스터의 애플리케이션 아키텍처 경향, 개념, 패턴과 최고 성공사례 등에 대한 연구를 추진해왔다. ciokr@idg.co.kr