2021.11.18

기고 | '분류에서 실행까지' 기술 아키텍처 개선 가이드

Bob Lewis | CIO
회사의 기술 아키텍처를 묘사하는 한 단어를 선택하라고 한다면 ‘매우 복잡’이라고 대답할 이가 많을 것이다. 두 단어이기는 하지만 대부분의 기술 아키텍처는 실제로 매우 복잡하다. 정말로, 정말로, 정말로 복잡하다.

물론, 그렇게 복잡하거나 난해한 것이 있다면 개선 계획을 수립하기 전에 분류 작업을 하는 것이 도움이 된다. 이러한 분류는 ‘정말로’라는 말을 사용하는 대신에 실질적인 계획을 수립하여 회사의 기술 아키텍처가 비즈니스에 도움이 되도록 할 것이다.


Jeff Sheldon / Unsplash (CCO)

기술 아키텍처 이해하기
이 시리즈의 이전 글인 ‘기고 | IT부서 ‘업의 본질’일 수도… ‘기술 아키텍처’ 가이드’에서는 기술 아키텍처를 설명하고 3개의 포트폴리오와 하위 포트폴리오로 분류했다.

• 애플리케이션 : 기록, 인터페이스, 통합 시스템 및 위성 앱
• 데이터 : 구조화 및 비구조화
• 기술 : 시설, 인프라, 플랫폼

다음 글 ‘기고 | 기술 아키텍처 평가하기 ‘11가지 핵심 기준’에서는 기술 아키텍처에 포트폴리오 관점과 전체적인 디자인 등 2가지 보완적인 관점이 필요하다고 덧붙였다. 또한 아키텍처를 구성하는 구성요소의 건전성을 평가하기 위한 지침을 공유했다.

아울러 기술 아키텍처의 각 애플리케이션이 맵핑 하는 비즈니스 기능 분류학인 ‘BCM(Business Capability Model)’을 통해 기술 및 비즈니스 아키텍처를 연결하는 방법을 제시했다. 이것들을 통해 보유하고 있는 것을 확인, 범주화, 평가할 수 있다.

기술 아키텍처를 개선하기 위한 효과적인 계획을 수립하기 위해서는 각 포트폴리오와 하위 포트폴리오의 모든 구성요소의 배치(필요한 변화 방식) 및 배치에 대한 우선순위를 결정해야 한다. 구체적인 사항은 취급하고 있는 포트폴리오 및 하위 포트폴리오에 따라 달라진다. 여기에서 아래에서부터 분류해본다.

시설 및 인프라
기술 아키텍처 개선 시 우선순위 수립은 항상 선순위 과제다. 마지막 편에서 설명한 프로세스, 프레임워크, 기준을 사용하여 각 구성요소의 건전성에 점수를 매긴다. 얼마나 많은 애플리케이션이 의존하고 있는지에 따라 중요성에 점수를 매긴다. 각 구성요소의 우선순위 인덱스를 계산하기 위해 건전성에 중요성을 곱한다. 구성요소의 빨간색이 짙어지면 우선순위가 더 높은 히트맵으로 결과를 시각화 한다.

배치는 그 다음이다. 시설과 인프라의 경우 배치 선택은 다음과 같다.

• 퇴역 : 가능성이 낮기는 하지만 사용 중이지 않은 시설 또는 인프라를 확인할 가능성이 있다. 임대 또는 지원 계약을 차단하고 취소한다.

• 업데이트 : 쓸모 없거나 지원되지 않거나 같은 제품의 더욱 최신 버전으로 업데이트해야 하는 시설 또는 인의 구성요소를 찾을 수도 있다. 이것들을 업데이트한다.

• 교체 : 쓸모 없고 지원되지 않는 구성요소가 있을 수 있으며, 더욱 최신 버전이 제공되고 있는 경우 실행 가능하다고 생각하지 않는다. 이것을 버리고 기능적으로 동등하지만 더욱 건전한 대안을 대신 배치한다.

• 통합 : 기술 아키텍처에 중복된 시설 또는 인프라 구성요소가 있는 경우는 드물다. 특히, 합병 또는 인수에 이어 다수의 데이터센터 또는 네트워크는 통합 기회를 제공하는 경우가 많다.

이제 시설과 인프라의 경우 높은 관심을 가져야 할 것과 이 상황에 대해 해야 할 일에 관해 파악했다.

플랫폼
플랫폼 우선순위와 배치를 결정하는 것은 시설 및 인프라의 그것들을 결정하는 것과 다르다. 왜냐하면 플랫폼들의 상호 의존성이 훨씬 크기 때문이다. 이런 복잡성에 대응하는 좋은 방법은 스택을 정의하는 것이다. 스택은 최소 1개의 애플리케이션이 사용하는 플랫폼들의 조합이며, 여기에는 서버 OS, 개발 환경(라이브러리 포함), DBMS, CMS(Content Management System), 웹 서버, 지원되지 않는 브라우저(애플리케이션의 UI가 브라우저를 통해 노출된 것으로 가정), 다양한 플랫폼이 구동하고 있는 운영체제 등이 포함된다.

스택들이 반복되고 있음에 주의해야 한다. 플랫폼은 다른 플랫폼에 기초할 수 있다. 또한 일부 애플리케이션도 플랫폼이 될 수 있다. 예를 들어, 셰어포인트(SharePoint)는 사용자 정의 애플리케이션을 구축하기 위한 개발 환경이 될 수 있다.

우선순위 : 스택의 건전성은 이 시리즈의 이전 편에 기록된 프로세스, 프레임워크, 샘플 기준을 사용하여 점수를 매긴 구성요소들의 평균 건전성이다.

우선순위는? 이에 대한 완벽한 ‘모범 사례’는 없다. 복잡성을 해결하는 접근방식은, 건전하지 못한 플랫폼을 확인하는 것이다. 기술 아키텍처에 60개의 스택을 정의했다고 가정해보자. 또한 생산 중인 가장 건전하지 못한 플랫폼이 윈도우 서버 2003(Window Server 2003)이며 가상의 건전성 점수가 -1.5라고 가정해보자.

이 가상의 예에서 점수를 +2로 올리면 14개의 스택이 -1에서 0으로 이동하고 다른 6개 스택은 0에서 +1로 이동한다고 가정해보자. 윈도우 2003 서버를 고치면 22개의 스택이 개선되는 것이다. 이 경우 윈도우 2003 서버의 우선순위 인덱스는 개선된 60개의 스택 중 20개인 0.33이다.

모든 플랫폼 구성요소에 대해 해소하고 반복하면 플랫폼 우선순위의 순위를 매기는 유용한 수단을 확보하게 된다.

• 배치 : 플랫폼 배치는 시설 및 인프라에 대해 정의된 것과 유사하다.

• 퇴역 : 가능성이 낮기는 하지만 사용 중이지 않은 플랫폼을 확인할 가능성이 있다. 이것들을 차단하고 기존의 라이선스 계약 및 지원 계약을 취소한다.

• 업데이트 : 지원되지 않거나 쓸모가 없는 플랫폼을 찾을 수도 있다. 같은 제품의 더욱 최신 버전으로 마이그레이션한다.

• 교체 : 쓸모 없고 지원되지 않는 플랫폼을 찾기 쉬우며, 더욱 최신 버전이 제공되고 있는 경우 실행 가능하다고 생각하지 않는다. 이것을 버리고 기능적으로 동등하지만 더욱 건전한 대안을 대신 배치한다.

• 통합 : 사용 중인 플랫폼이 중복되지 않는 기술 아키텍처는 거의 없다. 서버 OS, DBMS, 통합된 개발 환경 등의 사이에서 건전성 등급이 가장 높은 것들을 기업 표준으로 수립하고 나머지를 이런 표준으로 마이그레이션하면 간소화 및 개선을 위한 풍부한 기회를 제공할 수 있다.

데이터
이론상 데이터 저장소는 기술 아키텍처를 개선하기 위한 독립적인 목표로 간주해야 한다. 사실, 이런 것들은 독립적인 평가 및 계획이 아니라 애플리케이션 배치의 일부분으로 취급하고 있다.

즉, 조직의 데이터 웨어하우스(Data Warehouse)와 다른 분석 저장소는 예외이다. 이런 것들을 별도의 데이터 계층 구성요소로 취급해야 한다. 하지만 이것들은 조직의 분석 활동에 의해 관리되기 때문에 다른 문제인 것이다. 이것들을 평가 프로세스에서 배제할 수 있다.

단, 1개 이상의 플랫폼 계층 배치가 분석 저장소에 영향을 미친다. 이런 경우에 기술 아키텍처가 정치적인 이슈로 부상하게 된다.

애플리케이션
여기에서부터 흥미로워진다. 기술 아키텍처의 하위 계층에서 구성요소의 건전성의 점수를 매겼던 것처럼 애플리케이션 건전성의 점수를 매길 수 있다. 평가 기준 점수의 평균을 구하여 전체적인 애플리케이션 점수를 구한다.

우선순위 : 중간 규모 기업도 포트폴리오에 수백 또는 수천 개의 애플리케이션이 있는 경우가 흔하기 때문에 한 번에 하나의 애플리케이션의 우선순위를 수립하는 것은 비현실적이다. 애플리케이션 우선순위 수립도 좋은 아이디어이다. 우선순위를 비즈니스 역량 모델을 사용하여 이미 문서화한 비즈니스 기능 및 애플리케이션 맵핑의 특성으로 간주하는 것이 낫다.

대부분의 기술 아키텍처에서는 각 비즈니스 기능이 1개 또는 2개의 코어 애플리케이션으로 지원되며, ERP 패키지 또는 다른 광범위한 스위트의 모듈인 경우가 많다.

코어 애플리케이션 주변에는 코어 애플리케이션에서 누락된 기능을 제공하는 위성 애플리케이션이 있다. 위성 및 코어 애플리케이션은 서로 데이터를 공유하고 동기화한다.

또한 많은 비즈니스 기능이 단독형이며 해당 비즈니스 기능을 지원하는 다른 애플리케이션과 통합할 필요가 없는 애플리케이션인 유틸리티를 사용한다.

우선순위를 결정하기 위해서는 우선 비즈니스 기능 애플리케이션 건전성 인덱스를 이를 지원하는 애플리케이션의 가중평균 건전성으로써 계산하고 각각의 규모에 따라 코어 애플리케이션에 10, 위성 애플리케이션에 3~7의 가중 인자를 할당하며 유틸리티에 1을 할당한다.

이미 BCM의 일환으로 비즈니스 아키텍처팀이 제공한 기록된 비즈니스 기능의 건전성이 있을 것이다. 최고 우선순위는 최악의 비즈니스 기능 건전성 및 애플리케이션 건전성의 조합을 가진 비즈니스 기능이다.

배치 : 기술 설계자는 기술 아키텍처의 하위 계층보다는 애플리케이션을 취급하기 위해 사용할 수 있는 더 많은 대안이 있다. 특히, 각 애플리케이션에 대해 다음이 가능하다.

• 유지 : 애플리케이션을 계속 사용하여 비즈니스 요구 변화를 유지하고 개선한다.

• 교체 : 애플리케이션을 버리고 기능적으로 동등하지만 전반적으로 더 건전한 대안을 대체한다.

• 플랫폼 재구성 : 애플리케이션을 비용이 낮지만 동등한 일련의 플랫폼으로 ‘이동한다’.

• 리팩터(Refactor) : 애플리케이션을 다시 작성하여 기술 아키텍처 엔지니어링 표준을 준수한다.

• 조정 : 플랫폼은 변화할 것이며(상기 플랫폼 배치 참조), 일부 애플리케이션은 이에 따라 변화해야 할 것이다.

• 통합 : 애플리케이션이 중복되는 경우, 즉 기능적으로 동등하지만 기업의 다른 부문에서 더 뛰어난 애플리케이션이 사용되고 있는 경우 해당 애플리케이션으로 마이그레이션한다. 특히, 미래의 기업 표준으로 간주되는 경우에는 더욱 그렇다.

• 퇴역 : 애플리케이션 사용을 중단하고 라이선스를 취소한다. 상황에 따라 필요한 경우 애플리케이션의 데이터를 먼저 보관한다.

클라우드는? 애플리케이션 배치 할당을 완료할 때까지 클라우드는 이 분석과 관련성이 없거나 중요하지 않다. 이를 수행하고 나면 기술 전략에 클라우드 마이그레이션이 포함되어 있는 경우 클라우드가 애플리케이션 교체, 리팩터, 플랫폼 재구성 등을 위한 적절한 선택일 수도 있다.

우선순위와 배치부터 계획까지
워터폴(Waterfall) 접근방식에 치중한 많은 기술 설계자들이 기술 아키텍처 개선을 계획할 때 배치 시한에 대한 간트(Gantt) 차트 같은 관점에서 로드맵이 가장 중요하다고 생각하곤 한다. 

하지만 로드맵은 워터폴 사고방식의 유물이다. 최고 우선순위 플랫폼 또는 비즈니스 기능을 넘어 기술 아키텍처 변화를 계획할 때는 거의 의미가 없다. 우리가 애자일(Agile) 애자일 개발에서 학습했듯이 너무 앞선 계획은 이내 쓸모 없어지게 될 가능성이 높다.

애자일 스타일 백로그(Backlog)를 통해 기술 아키텍처 계획을 관리하는 것이 전통적인 로드맵보다 훨씬 우월하다.

이 접근방식에는 플랫폼 지향적 아키텍처와 비즈니스 기능 지향적 아키텍처 등 2가지 변화가 있다. 우선, 플랫폼 스택은 백로그에서 애자일 ‘서사’의 위치를 차지하고 있다. 두 번째는 비즈니스 기능을 중심으로 백로그 서사를 구축한다.

플랫폼 지향적 아키텍처 변화 : 이 접근방식을 통해 일반적으로 상기 설명처럼 우선순위 설정 또는 조직에 더 적합한 일부 대안에 기초하여 하나의 플랫폼 구성요소가 선택된다. 어쨌든, 계획자는 플랫폼 수준의 파급효과(기타 영향을 받는 스택)와 애플리케이션 수준의 파급효과(영향을 받는 스택을 사용하는 애플리케이션)를 기대할 것이다.

최고 우선순위 플랫폼 배치를 구현하는 가운데 기술 설계자는 나머지 백로그에서 최신 플랫폼 서사 우선순위를 검토하고 적절한 경우 변화하는 상황에 따라 변경하고 다음으로 우선순위가 가장 높은 서사의 계획 프로세스를 시작할 것이다.

비즈니스 기능 지향적인 아키텍처 변화 : 비즈니스 기능 지향적인 아키텍처 변화의 경우 상관관계가 야기를 입증하지는 않지만 비즈니스 및 애플리케이션 건전성이 낮게 평가된 기능에서부터 비즈니스 프로세스 병목을 유발하고 있는 애플리케이션 결핍을 찾는 것이 합리적이다.

기술 아키텍처의 관점에서 비즈니스 기능 지향적 변화가 최고 우선순위 비즈니스 기능의 코어 애플리케이션의 배치부터 시작하여 위성 애플리케이션 배치로 흘러간다. 이와 동시에 기업의 비즈니스 설계자는 애플리케이션 변화를 통해 가능해진 프로세스 개선을 설계하고 구현하기 위해 협업할 것이다.

플랫폼 지향적인 변화와 마찬가지로 최고 우선순위 비즈니스 기능의 애플리케이션 배치를 구현하고 있는 기술 설계자는 백로그 우선순위를 검토하고 적절한 경우 조정하며 다음 최고 우선순위 서사에 대한 계획을 시작할 것이다.

결론
기술 아키텍처는 복잡하다. 왜냐하면 비즈니스가 복잡하기 때문에 그럴 수밖에 없다.

어쨌든, BCM은 이런 기능을 한다. 첫 번째 3개의 BCM 계층에서 수백 개의 비즈니스 프로세스와 활동이 목록화 되어 있는 경우가 흔하다. 마찬가지로 BCM에 맵핑 된 애플리케이션(애플리케이션 인벤토리)이 1,000개 이상인 경우도 흔하다.

보유한 모든 것을 문서화하고 필요한 개선을 계획하는 프로세스는 시간이 소요되고 비용이 높다. 하지만 상관없다. 왜냐하면 보유한 모든 것을 문서화하지 않고 필요한 개선을 계획하지 않으면 시간이 더 많이 소요되고 비용이 더 높기 때문이다.

지금 지불하는가 또는 나중에 지불하는가의 선택인 경우 나중에 지불하는 것이 훨씬 더 나쁘다는 것은 확실하다.

* Bob Lewis는 IT와 현업 관계, 전략 실행 계획에 중점을 IT 컨설턴트다. ciokr@idg.co.kr
 



2021.11.18

기고 | '분류에서 실행까지' 기술 아키텍처 개선 가이드

Bob Lewis | CIO
회사의 기술 아키텍처를 묘사하는 한 단어를 선택하라고 한다면 ‘매우 복잡’이라고 대답할 이가 많을 것이다. 두 단어이기는 하지만 대부분의 기술 아키텍처는 실제로 매우 복잡하다. 정말로, 정말로, 정말로 복잡하다.

물론, 그렇게 복잡하거나 난해한 것이 있다면 개선 계획을 수립하기 전에 분류 작업을 하는 것이 도움이 된다. 이러한 분류는 ‘정말로’라는 말을 사용하는 대신에 실질적인 계획을 수립하여 회사의 기술 아키텍처가 비즈니스에 도움이 되도록 할 것이다.


Jeff Sheldon / Unsplash (CCO)

기술 아키텍처 이해하기
이 시리즈의 이전 글인 ‘기고 | IT부서 ‘업의 본질’일 수도… ‘기술 아키텍처’ 가이드’에서는 기술 아키텍처를 설명하고 3개의 포트폴리오와 하위 포트폴리오로 분류했다.

• 애플리케이션 : 기록, 인터페이스, 통합 시스템 및 위성 앱
• 데이터 : 구조화 및 비구조화
• 기술 : 시설, 인프라, 플랫폼

다음 글 ‘기고 | 기술 아키텍처 평가하기 ‘11가지 핵심 기준’에서는 기술 아키텍처에 포트폴리오 관점과 전체적인 디자인 등 2가지 보완적인 관점이 필요하다고 덧붙였다. 또한 아키텍처를 구성하는 구성요소의 건전성을 평가하기 위한 지침을 공유했다.

아울러 기술 아키텍처의 각 애플리케이션이 맵핑 하는 비즈니스 기능 분류학인 ‘BCM(Business Capability Model)’을 통해 기술 및 비즈니스 아키텍처를 연결하는 방법을 제시했다. 이것들을 통해 보유하고 있는 것을 확인, 범주화, 평가할 수 있다.

기술 아키텍처를 개선하기 위한 효과적인 계획을 수립하기 위해서는 각 포트폴리오와 하위 포트폴리오의 모든 구성요소의 배치(필요한 변화 방식) 및 배치에 대한 우선순위를 결정해야 한다. 구체적인 사항은 취급하고 있는 포트폴리오 및 하위 포트폴리오에 따라 달라진다. 여기에서 아래에서부터 분류해본다.

시설 및 인프라
기술 아키텍처 개선 시 우선순위 수립은 항상 선순위 과제다. 마지막 편에서 설명한 프로세스, 프레임워크, 기준을 사용하여 각 구성요소의 건전성에 점수를 매긴다. 얼마나 많은 애플리케이션이 의존하고 있는지에 따라 중요성에 점수를 매긴다. 각 구성요소의 우선순위 인덱스를 계산하기 위해 건전성에 중요성을 곱한다. 구성요소의 빨간색이 짙어지면 우선순위가 더 높은 히트맵으로 결과를 시각화 한다.

배치는 그 다음이다. 시설과 인프라의 경우 배치 선택은 다음과 같다.

• 퇴역 : 가능성이 낮기는 하지만 사용 중이지 않은 시설 또는 인프라를 확인할 가능성이 있다. 임대 또는 지원 계약을 차단하고 취소한다.

• 업데이트 : 쓸모 없거나 지원되지 않거나 같은 제품의 더욱 최신 버전으로 업데이트해야 하는 시설 또는 인의 구성요소를 찾을 수도 있다. 이것들을 업데이트한다.

• 교체 : 쓸모 없고 지원되지 않는 구성요소가 있을 수 있으며, 더욱 최신 버전이 제공되고 있는 경우 실행 가능하다고 생각하지 않는다. 이것을 버리고 기능적으로 동등하지만 더욱 건전한 대안을 대신 배치한다.

• 통합 : 기술 아키텍처에 중복된 시설 또는 인프라 구성요소가 있는 경우는 드물다. 특히, 합병 또는 인수에 이어 다수의 데이터센터 또는 네트워크는 통합 기회를 제공하는 경우가 많다.

이제 시설과 인프라의 경우 높은 관심을 가져야 할 것과 이 상황에 대해 해야 할 일에 관해 파악했다.

플랫폼
플랫폼 우선순위와 배치를 결정하는 것은 시설 및 인프라의 그것들을 결정하는 것과 다르다. 왜냐하면 플랫폼들의 상호 의존성이 훨씬 크기 때문이다. 이런 복잡성에 대응하는 좋은 방법은 스택을 정의하는 것이다. 스택은 최소 1개의 애플리케이션이 사용하는 플랫폼들의 조합이며, 여기에는 서버 OS, 개발 환경(라이브러리 포함), DBMS, CMS(Content Management System), 웹 서버, 지원되지 않는 브라우저(애플리케이션의 UI가 브라우저를 통해 노출된 것으로 가정), 다양한 플랫폼이 구동하고 있는 운영체제 등이 포함된다.

스택들이 반복되고 있음에 주의해야 한다. 플랫폼은 다른 플랫폼에 기초할 수 있다. 또한 일부 애플리케이션도 플랫폼이 될 수 있다. 예를 들어, 셰어포인트(SharePoint)는 사용자 정의 애플리케이션을 구축하기 위한 개발 환경이 될 수 있다.

우선순위 : 스택의 건전성은 이 시리즈의 이전 편에 기록된 프로세스, 프레임워크, 샘플 기준을 사용하여 점수를 매긴 구성요소들의 평균 건전성이다.

우선순위는? 이에 대한 완벽한 ‘모범 사례’는 없다. 복잡성을 해결하는 접근방식은, 건전하지 못한 플랫폼을 확인하는 것이다. 기술 아키텍처에 60개의 스택을 정의했다고 가정해보자. 또한 생산 중인 가장 건전하지 못한 플랫폼이 윈도우 서버 2003(Window Server 2003)이며 가상의 건전성 점수가 -1.5라고 가정해보자.

이 가상의 예에서 점수를 +2로 올리면 14개의 스택이 -1에서 0으로 이동하고 다른 6개 스택은 0에서 +1로 이동한다고 가정해보자. 윈도우 2003 서버를 고치면 22개의 스택이 개선되는 것이다. 이 경우 윈도우 2003 서버의 우선순위 인덱스는 개선된 60개의 스택 중 20개인 0.33이다.

모든 플랫폼 구성요소에 대해 해소하고 반복하면 플랫폼 우선순위의 순위를 매기는 유용한 수단을 확보하게 된다.

• 배치 : 플랫폼 배치는 시설 및 인프라에 대해 정의된 것과 유사하다.

• 퇴역 : 가능성이 낮기는 하지만 사용 중이지 않은 플랫폼을 확인할 가능성이 있다. 이것들을 차단하고 기존의 라이선스 계약 및 지원 계약을 취소한다.

• 업데이트 : 지원되지 않거나 쓸모가 없는 플랫폼을 찾을 수도 있다. 같은 제품의 더욱 최신 버전으로 마이그레이션한다.

• 교체 : 쓸모 없고 지원되지 않는 플랫폼을 찾기 쉬우며, 더욱 최신 버전이 제공되고 있는 경우 실행 가능하다고 생각하지 않는다. 이것을 버리고 기능적으로 동등하지만 더욱 건전한 대안을 대신 배치한다.

• 통합 : 사용 중인 플랫폼이 중복되지 않는 기술 아키텍처는 거의 없다. 서버 OS, DBMS, 통합된 개발 환경 등의 사이에서 건전성 등급이 가장 높은 것들을 기업 표준으로 수립하고 나머지를 이런 표준으로 마이그레이션하면 간소화 및 개선을 위한 풍부한 기회를 제공할 수 있다.

데이터
이론상 데이터 저장소는 기술 아키텍처를 개선하기 위한 독립적인 목표로 간주해야 한다. 사실, 이런 것들은 독립적인 평가 및 계획이 아니라 애플리케이션 배치의 일부분으로 취급하고 있다.

즉, 조직의 데이터 웨어하우스(Data Warehouse)와 다른 분석 저장소는 예외이다. 이런 것들을 별도의 데이터 계층 구성요소로 취급해야 한다. 하지만 이것들은 조직의 분석 활동에 의해 관리되기 때문에 다른 문제인 것이다. 이것들을 평가 프로세스에서 배제할 수 있다.

단, 1개 이상의 플랫폼 계층 배치가 분석 저장소에 영향을 미친다. 이런 경우에 기술 아키텍처가 정치적인 이슈로 부상하게 된다.

애플리케이션
여기에서부터 흥미로워진다. 기술 아키텍처의 하위 계층에서 구성요소의 건전성의 점수를 매겼던 것처럼 애플리케이션 건전성의 점수를 매길 수 있다. 평가 기준 점수의 평균을 구하여 전체적인 애플리케이션 점수를 구한다.

우선순위 : 중간 규모 기업도 포트폴리오에 수백 또는 수천 개의 애플리케이션이 있는 경우가 흔하기 때문에 한 번에 하나의 애플리케이션의 우선순위를 수립하는 것은 비현실적이다. 애플리케이션 우선순위 수립도 좋은 아이디어이다. 우선순위를 비즈니스 역량 모델을 사용하여 이미 문서화한 비즈니스 기능 및 애플리케이션 맵핑의 특성으로 간주하는 것이 낫다.

대부분의 기술 아키텍처에서는 각 비즈니스 기능이 1개 또는 2개의 코어 애플리케이션으로 지원되며, ERP 패키지 또는 다른 광범위한 스위트의 모듈인 경우가 많다.

코어 애플리케이션 주변에는 코어 애플리케이션에서 누락된 기능을 제공하는 위성 애플리케이션이 있다. 위성 및 코어 애플리케이션은 서로 데이터를 공유하고 동기화한다.

또한 많은 비즈니스 기능이 단독형이며 해당 비즈니스 기능을 지원하는 다른 애플리케이션과 통합할 필요가 없는 애플리케이션인 유틸리티를 사용한다.

우선순위를 결정하기 위해서는 우선 비즈니스 기능 애플리케이션 건전성 인덱스를 이를 지원하는 애플리케이션의 가중평균 건전성으로써 계산하고 각각의 규모에 따라 코어 애플리케이션에 10, 위성 애플리케이션에 3~7의 가중 인자를 할당하며 유틸리티에 1을 할당한다.

이미 BCM의 일환으로 비즈니스 아키텍처팀이 제공한 기록된 비즈니스 기능의 건전성이 있을 것이다. 최고 우선순위는 최악의 비즈니스 기능 건전성 및 애플리케이션 건전성의 조합을 가진 비즈니스 기능이다.

배치 : 기술 설계자는 기술 아키텍처의 하위 계층보다는 애플리케이션을 취급하기 위해 사용할 수 있는 더 많은 대안이 있다. 특히, 각 애플리케이션에 대해 다음이 가능하다.

• 유지 : 애플리케이션을 계속 사용하여 비즈니스 요구 변화를 유지하고 개선한다.

• 교체 : 애플리케이션을 버리고 기능적으로 동등하지만 전반적으로 더 건전한 대안을 대체한다.

• 플랫폼 재구성 : 애플리케이션을 비용이 낮지만 동등한 일련의 플랫폼으로 ‘이동한다’.

• 리팩터(Refactor) : 애플리케이션을 다시 작성하여 기술 아키텍처 엔지니어링 표준을 준수한다.

• 조정 : 플랫폼은 변화할 것이며(상기 플랫폼 배치 참조), 일부 애플리케이션은 이에 따라 변화해야 할 것이다.

• 통합 : 애플리케이션이 중복되는 경우, 즉 기능적으로 동등하지만 기업의 다른 부문에서 더 뛰어난 애플리케이션이 사용되고 있는 경우 해당 애플리케이션으로 마이그레이션한다. 특히, 미래의 기업 표준으로 간주되는 경우에는 더욱 그렇다.

• 퇴역 : 애플리케이션 사용을 중단하고 라이선스를 취소한다. 상황에 따라 필요한 경우 애플리케이션의 데이터를 먼저 보관한다.

클라우드는? 애플리케이션 배치 할당을 완료할 때까지 클라우드는 이 분석과 관련성이 없거나 중요하지 않다. 이를 수행하고 나면 기술 전략에 클라우드 마이그레이션이 포함되어 있는 경우 클라우드가 애플리케이션 교체, 리팩터, 플랫폼 재구성 등을 위한 적절한 선택일 수도 있다.

우선순위와 배치부터 계획까지
워터폴(Waterfall) 접근방식에 치중한 많은 기술 설계자들이 기술 아키텍처 개선을 계획할 때 배치 시한에 대한 간트(Gantt) 차트 같은 관점에서 로드맵이 가장 중요하다고 생각하곤 한다. 

하지만 로드맵은 워터폴 사고방식의 유물이다. 최고 우선순위 플랫폼 또는 비즈니스 기능을 넘어 기술 아키텍처 변화를 계획할 때는 거의 의미가 없다. 우리가 애자일(Agile) 애자일 개발에서 학습했듯이 너무 앞선 계획은 이내 쓸모 없어지게 될 가능성이 높다.

애자일 스타일 백로그(Backlog)를 통해 기술 아키텍처 계획을 관리하는 것이 전통적인 로드맵보다 훨씬 우월하다.

이 접근방식에는 플랫폼 지향적 아키텍처와 비즈니스 기능 지향적 아키텍처 등 2가지 변화가 있다. 우선, 플랫폼 스택은 백로그에서 애자일 ‘서사’의 위치를 차지하고 있다. 두 번째는 비즈니스 기능을 중심으로 백로그 서사를 구축한다.

플랫폼 지향적 아키텍처 변화 : 이 접근방식을 통해 일반적으로 상기 설명처럼 우선순위 설정 또는 조직에 더 적합한 일부 대안에 기초하여 하나의 플랫폼 구성요소가 선택된다. 어쨌든, 계획자는 플랫폼 수준의 파급효과(기타 영향을 받는 스택)와 애플리케이션 수준의 파급효과(영향을 받는 스택을 사용하는 애플리케이션)를 기대할 것이다.

최고 우선순위 플랫폼 배치를 구현하는 가운데 기술 설계자는 나머지 백로그에서 최신 플랫폼 서사 우선순위를 검토하고 적절한 경우 변화하는 상황에 따라 변경하고 다음으로 우선순위가 가장 높은 서사의 계획 프로세스를 시작할 것이다.

비즈니스 기능 지향적인 아키텍처 변화 : 비즈니스 기능 지향적인 아키텍처 변화의 경우 상관관계가 야기를 입증하지는 않지만 비즈니스 및 애플리케이션 건전성이 낮게 평가된 기능에서부터 비즈니스 프로세스 병목을 유발하고 있는 애플리케이션 결핍을 찾는 것이 합리적이다.

기술 아키텍처의 관점에서 비즈니스 기능 지향적 변화가 최고 우선순위 비즈니스 기능의 코어 애플리케이션의 배치부터 시작하여 위성 애플리케이션 배치로 흘러간다. 이와 동시에 기업의 비즈니스 설계자는 애플리케이션 변화를 통해 가능해진 프로세스 개선을 설계하고 구현하기 위해 협업할 것이다.

플랫폼 지향적인 변화와 마찬가지로 최고 우선순위 비즈니스 기능의 애플리케이션 배치를 구현하고 있는 기술 설계자는 백로그 우선순위를 검토하고 적절한 경우 조정하며 다음 최고 우선순위 서사에 대한 계획을 시작할 것이다.

결론
기술 아키텍처는 복잡하다. 왜냐하면 비즈니스가 복잡하기 때문에 그럴 수밖에 없다.

어쨌든, BCM은 이런 기능을 한다. 첫 번째 3개의 BCM 계층에서 수백 개의 비즈니스 프로세스와 활동이 목록화 되어 있는 경우가 흔하다. 마찬가지로 BCM에 맵핑 된 애플리케이션(애플리케이션 인벤토리)이 1,000개 이상인 경우도 흔하다.

보유한 모든 것을 문서화하고 필요한 개선을 계획하는 프로세스는 시간이 소요되고 비용이 높다. 하지만 상관없다. 왜냐하면 보유한 모든 것을 문서화하지 않고 필요한 개선을 계획하지 않으면 시간이 더 많이 소요되고 비용이 더 높기 때문이다.

지금 지불하는가 또는 나중에 지불하는가의 선택인 경우 나중에 지불하는 것이 훨씬 더 나쁘다는 것은 확실하다.

* Bob Lewis는 IT와 현업 관계, 전략 실행 계획에 중점을 IT 컨설턴트다. ciokr@idg.co.kr
 

X