Offcanvas

CIO / How To / 리더십|조직관리 / 소프트스킬

기고 | 기술 아키텍처 평가하기 ‘11가지 핵심 기준’

2021.10.29 Bob Lewis  |  CIO
현재 무엇을 보유했는지 파악한다는 것은 좋은 시작점이다. 단 무엇을 보유했는지 아는 것과 무엇을 보유해야 하는지 아는 것은 꽤나 다른 문제다. 

기술 아키텍처(Technical Architecture)는 정보 기술의 진화를 서술하고 평가하고 계획하도록 알려주는 접근법이다. 

지난 글 ‘기고 | IT부서 ‘업의 본질’일 수도… ‘기술 아키텍처’ 가이드’에서 살펴본 것처럼 기술 아키텍처를 설명하기 위한 프레임워크는 포트폴리오와 하위-포트폴리오로 나뉜다. 예를 들어 애플리케이션(기록, 통합, 위성 앱 시스템), 데이터(구조적 및 비구조적), 기술(설비, 인프라, 플랫폼) 등이 대표적인 요소다.

이 프레임워크는 IT가 가진 것을 식별하고 분류하는 것을 가능하게 한다. 그러나 이것만으로는 부족하다. IT가 가진 것이 IT가 가져야 하는 것인지를 알기 어렵다. 이 글에서는 이 난제를 다룬다. 이제 기술 아키텍처를 평가하는 핵심 기준을 살펴본다.
 
Image Credit : Getty Images Bank



기술 아키텍처에 대한 2가지 시각 
기술 아키텍처에 대한 설명은 2가지 보완적 시각, 즉 홀리스틱 디자인(holistic design)과 포트폴리오 시각(portfolio view)으로 나뉜다.

홀리스틱 디자인(Holistic design)은 아키텍처의 각 구성요소가 무엇을 하는지 (구성요소가 제공하는 역량), 그리고 구성요소들이 어떻게 결합해 개별 부분으로부터 기능적 전체를 형성하는지를 설명한다. 

반면 포트폴리오 시각(Portfolio view)은 투자 이론에 뿌리를 둔다. 이는 기술 아키텍처 내의 구성요소를 투자 포트폴리오 내의 주식과 동일하게 취급한다. 투자자는 정기적으로 포트폴리오를 검토하여 어떤 주식을 더 매수할 것인지, 그대로 유지할 것인지, 매도할 것인지 결정한다.

테크니컬 아키텍트는 기술 포트폴리오의 각 구성요소의 건전성을 정기적으로 검토하여 어떤 구성요소가 표준으로서 유지되어야 하는지, 어떤 요소를 배제한 후 필요한 기능을 제공할 더 우수한 대안을 도입할 것인지 결정한다.

그러나 투자자와 달리 테크니컬 아키텍트는 매수, 보유, 매도 외에도 더 많은 선택지를 갖는다. 테크니컬 아키텍트는 이러한 선택지를 ‘배치(Dispositions)’라고 부른다.

만약 홀리스틱 디자인이 없다면 IT가 부실하게 인식된 수많은 개체를 바라볼 것이라는 사실만 유의할 필요가 있다. 포트폴리오 시각이 없다면 적절한 엔지니어링을 거친 종이 집을 보게 될 것이다. 모든 것이 맞춰졌지만, 그 안에서 살고 싶지는 않을 집이다.

비즈니스 아키텍처 및 연결 방식 
기술 아키텍처를 일관적으로 설계하고 계획하는 일은 여러 애플리케이션과 각 애플리케이션이 지원하는 비즈니스 기능에 매핑하지 않고서는 불가능하다. 따라서 비즈니스 아키텍처를 기술하는 사람은 아래의 4가지 핵심 정보를 IT 부서의 테크니컬 아키텍트에게 제공해야 한다.

분류(Taxonomy). 이는 비즈니스 기능의 분류를 의미한다. 3가지 수준, 즉 기능(Capabilities) (L1), 책임(Responsibilities) (L2), 프로세스(Processes) (L3) 정도면 충분하다. 예를 들어 HR 은 (L1) 급여 관리를 (L2) 포함하고, 이는 차례로 급여 명부를 (L3) 포함한다. 마찬가지로 재무 및 회계는 (L1) 수취 계정을 (L2) 포함하고, 이는 수금을 (L3) 포함한다. 굳이 전문용어를 사용하겠다면 분류를 BCM(Business Capability Model: 비즈니스 기능 모델)이라고 불러도 된다.

매핑(Mapping). 두 번째 핵심 정보는 BCM내의 기능이 어떤 애플리케이션에 의존하는가를 파악하는 매핑이다. 비즈니스 아키텍트는 이들을 그냥 기능(L1) 수준에서 매핑하고 싶을지 모른다. 그러나 L2와 L3의 매핑이 없다면 BCM은 효용이 제한적이다.

평가(Assessment). 3번째 핵심 정보는 각 BCM 기능의 전반적 유효성의 평가이다.

중요성(Importance). 4번째 핵심 정보는 꽤 논란의 여지가 있다. 다시 말해 각 비즈니스 기능의 상대적 중요성이다. 여기서는 두 가지 요령이 있다. (1) 중요성을 경쟁 우위에 주는 영향으로 정의하고, (2) 각 기능의 점수를 계산하지만, 순위를 정하지는 않는다.

급여 장부가 판매보다 더 중요한지 덜 중요한지에 관해서는 의견 일치에 도달하기 어려울 것이다. 그러나 5점 척도 상에서라면 쉽게 일치할 수 있다(권장). 이들은 최고 점수인 5점을 받을 만하다. 판매할 수 없다면 시장 점유율을 잃을 것이고, 직원에게 급여를 지급하지 않는다면 판매할 수 없을 것이다.

이들 4가지 정보, 다시 말해 분류, 애플리케이션 매핑, 비즈니스 기능 유효성, 비즈니스 기능 중요성은 비즈니스 및 기술 아키텍처를 서로 연결하는 요소다.

BCM은 흔히 회사의 조직도를 닮았지만, 조직도가 BCM이 아니다. 조직, 특히 대기업은, 기능 외의 기준으로 조직화되는 경우가 흔하다. 예를 들어, 지리, 고객 유형, 제품 범주 등이다. 따라서 몇몇 비즈니스 기능은 조직의 한 곳 이상에서 나타날 수 있다.

기술 아키텍처의 평가 
기술 아키텍처를 평가할 때, 아키텍트는 구성요소 및 통합 건전성, 중복 및 통합 기회, 비즈니스 기능 지원의 질을 이해해야 한다. 중복 및 비즈니스 기능 지원은 다음에 살펴보고 여기서는 구성요소 건전성 평가만을 살펴본다.

기술 아키텍처 안의 각 포트폴리오 및 하위-포트폴리오의 구성요소는 다양한 평가를 받을 수 있다. 예를 들어 긍정적 자산이라는 평가, IT가 본연의 일을 하는 능력에 대한 평가, 지원을 받는 다양한 비즈니스 분야가 본연의 업무를 하는 능력을 방해한다는 평가 등을 받을 수 있다.

아키텍처 구성요소를 평가하는 데 쓰이는 기준은 광범위하다. 프레임워크에 따라 애플리케이션 계층에만 30가지의 유망 평가 기준을 포함하기도 한다. 그러나 30가지는 단일 계층을 대상으로 할 때 너무 많다. 데이터 수집 및 관리 관점에서, 십여 가지 정도가 현실적으로 최대 수치이다.

여기서는 11가지 기준을 제시한다. 아래의 단순화된 기준 집합을 포트폴리오 및 하위 포트폴리오에 따라 조정한다면 기술 아키텍처를 평가하는 강력한 기반을 갖게 될 것이다.

추천 테크라이브러리

회사명:한국IDG 제호: ITWorld 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 편집인 : 박재곤 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.