 | |
|
난이도 : 중급 Dr. Mamdouh Ibrahim, Senior Certified Executive IT Architect and STSM, IBM
Gil Long, Distinguished Engineer, IBM
2007 년 10 월 09 일 서비스 지향 아키텍처(SOA)를 채택하고 엔터프라이즈 아키텍처(EA)를 동시에 개발하기로 결정했다면, 이 글이 도움이 될 것입니다. 본 시리즈의 이전 두 기술자료들에서는 SOA와 EA를 비교 및 대조해보았고, 엔터프라이즈 내에서 EA와 SOA 액티비티를 조화시키지 못했을 때 생기는 문제에 대해서도 다루었습니다. 필자는 SOA와 EA를 개발하는 16억 달러의 클라이언트 계약 참여하여 이러한 문제들을 직접적으로 경험했습니다. 본 시리즈의 마지막 글에서는, 필자가 경험을 통해 얻은 교훈들로 이러한 문제들을 다룰 수 있는 가이드를 제시합니다.
개요
SOA와 EA, 그리고 이들의 거버넌스의 개념, 액티비티, 프로세스, 결과는 많은 부분 중복된다. 예를 들어, SOA와 EA는 비즈니스 객체에 기반한 인풋을 요하고 그러한 객체들에 연결된 결과를 만들어 낸다. 이 두 가지 모두 엔터프라이즈 레벨에서 발생하는 문제들을 다루고자 한다. (전략과 기획, 레퍼런스 아키텍처). 또한, 이들의 거버넌스 모델도 비슷하다. 엔터프라이즈가 SOA를 채택하면서 EA(그리고 거버넌스)를 개발할 경우, EA와 SOA 간 유사점과 중복이 인지 및 규명되지 않는다면 문제가 생긴다.
본 시리즈,
Part 1
에서는 SOA와 EA의 정의와 범위를 설명하여 이 두 가지를 적절히 비교하고 대조하는 프레임웍을 구축하였다. 또한, SOA와 EA가 단순한 아키텍처 이상이며, 특히, 이 두 가지는 아키텍처, 거버넌스, 로드맵으로 구성된다고 설명했다. 각자의 다양한 영역들의 분파와 이 두 가지를 위한 거버넌스 프레임웍에 대해서도 설명했다.
Part 2
에서는, SOA와 EA 간 유사점과 차이점을 구분하는데 초점을 맞추고 이 두 가지의 아키텍처를 고려하고 상응하는 영역들 간 겹치는 부분을 구분할 것이다. 엔터프라이즈가 EA를 개발했을 때(또는 개발하고 있을 때) 발생하는 잠재적인 문제들을 설명하고, SOA를 구축할 것이다. 그리고 나서, EA와 SOA의 거버넌스 측면에 초점을 맞추고 유틸리티 업계의 Fortune 500 기업들에서 작업하면서 이 아키텍처로 무엇을 수행할 수 있을 것인가에 대한 분석도 할 것이다.
Part 3에서는 EA와 SOA를 동시에 개발했던 경험을 토대로 한 케이스 스터디를 제공한다. 잠재적 문제들을 다루는 방법과 경험을 통해 배웠던 교훈들을 요약해 놓았다.
계약
Fortune 500 기업에 속하는 클라이언트는 IBM®과 비즈니스 및 IT 아웃소싱 서비스 10년 계약을 체결했다. 이러한 계약의 일환으로, IBM은 광범위한 비즈니스 변형과 IT 아웃소싱 서비스를 제공하고, 모든 클라이언트의 IT 운영- 메인프레임, 미드레인지, 데스크탑, 헬프 데스크, 음성(voice) 및 데이터 네트워크, 애플리케이션 개발, 관리를 담당한다.
핵심적인 IT 변형 액티비티에는 다음 사항들이 포함된다.
- SOA를 위한 프레임웍과 Center of excellence (CoE) 확립
- 애플리케이션 개발과 관리를 위한 Level 3 Software Engineering Institute (SEI) 프로세스 성숙도
- 애플리케이션 포트폴리오 관리
- 여러 가지 새로운 변형 프로젝트와 데이터 센터와 서버 통합 프로젝트 개발
관련 사항과 문제점
우선, 구체적인 SOA-EA 문제점을 살펴보고 이러한 문제들이 발생할 수 있는 환경에 대해 알아보자.
엔터프라이즈 아키텍처(Enterprise Architecture)
- EA에 대한 필요는 판매 사이클 단계에서 뒤늦게 인지되었다. 따라서, 엔터프라이즈 아키텍트 같은 예산이나 인력이 EA 개발에 할당되지 않았다.
- 우리는 이미 개발 중인 프로젝트에서 원리, 결정, 모델을 추출하고, 통합된 금융 및 회계 시스템과 고객 서비스 데스크탑 시스템을 추가시킴으로써, EA를 점증적으로 개발하기로 결정했다.
- 계약이 시작된 직후, 가상의 EA 거버넌스 구조를 만들었고, SOA와 이것의 거버넌스를 규정 및 문서화 하는 것도 계속 진행했다.
SOA
- 계약을 성사시키는 이유와 IBM과 다른 경쟁사를 구별 짓는 요소로서 SOA를 제안하여 이것이 개발에서 어떤 두각을 나타내도록 하였다.
- 계약에는 SOA 액티비티를 위한 자금과 계획이 포함되었는데, 이는 좋은 출발점을 이루었다.
- 단 하나의 변형 프로젝트만이 SOA로 확실히 연결되는 반면, 다른 변형 프로젝트들은 SOA를 뚜렷하게 포함시키지 않고 체계화 및 자금이 지원되었다. 이로서, 계약 후에 그러한 프로젝트에 SOA가 도입되었다.
거버넌스 구성 모델
본 계약은 특별히 아키텍처 거버넌스 모델의 개발과 구현을 요구하지만, SOA 거버넌스 모델의 개발은 SOA 시작 액티비티의 일환으로 간주되었다. 다음 섹션에서는 제안된 아키텍처 거버넌스와 SOA 거버넌스 모델을 설명한다.
아키텍처 거버넌스 구성 모델
아키텍처 거버넌스를 확립하기 위해, 우리는 2-tier 조직 구조들로 구성된 모델을 제안했는데(그림 1), 이것은 IBM Enterprise Architecture Consulting Method에 설명된 거버넌스 모델을 적용한 것이다. 이 모델에서, 두 개의 거버넌스 기구들을 각각 Architecture Management Council (AMC)과 Delivery Architecture Review Board (DARB)라고 한다.
그림 1. EA 거버넌스 조직 모델
AMC 헌장:
- 클라이언트를 위한 전체적인 아키텍처 전략을 결정하고, 클라이언트의 비즈니스 전략, 기술 연구(가용 기술들을 망라한 연구 지원), 업계 지식을 고려한다.
- 점점 증가하는 문제들을 다루고 처리한다.
- EA를 지원 및 운영한다.
DARB 헌장은 두 개의 범주로 구분된다.
-
EA 점증적 개발과 관리
- 기존 아키텍처 정책들을 수집하고 검사하여 클라이언트의 EA로서 채택할 것을 결정한다.
- 엔터프라이즈에 맞는 개별적인 프로젝트 아키텍처 결정들을 경감 및 통합하여 EA의 필수 요소가 되도록 한다.
-
아키텍처 거버넌스
- 프로젝트 아키텍처의 개발을 인도한다.
- 클라이언트의 EA와 프로젝트 아키텍처의 순응성을 감시한다.
- 프로젝트 아키텍처를 하드웨어와 소프트웨어 획득을 향한 사전 조건 및 상세한 디자인 및 개발의 초기화로서 승인한다.
- 예외를 허용한다.
SOA 거버넌스 조직 모델
EA 거버넌스 모델이 개발 및 확립되면서, SOA 팀은 다음과 같은 SOA 거버너스 조직 모델을 제안한다. (그림 2)
그림 2. SOA 거버넌스 조직 모델
이 모델에서, SOA는 세 가지 기구를 통해 관리된다. 주 조정 위원회(executive steering committee-다이어그램 상단), SOA 비즈니스 위원회(오른쪽), SOA 검토 위원회(왼쪽)가 있다. SOA CoE와 중앙화된 SOA 제공 팀은 핵심적인 SOA 팀을 나타낸다. 그림 2는 이러한 운영 위원회들의 멤버들을 나타낸다.
문제 해결하기
이 섹션에서는 SOA와 EA를 동시에 개발하는 데서 기인한 잠재적 문제들을 해결하는 방법을 설명한다. 문제는 두 가지 범주(아키텍처와 거버넌스)로 나뉘고 본 시리즈의 Part
2에서 설명한 문제들과도 연결된다.
아키텍처 관련 문제들
| 잠재적 문제 | 해결책 |
|---|
| 모두 SOA에 초점을 맞추기 때문에 다른 EA 측면들은 무시된다. |
- SOA CoE와 DARB를 분리한다.
- DARB는 EA에 초점을 맞추고, CoE는 SOA에 초점을 맞춘다.
- SOA 리더와 엔터프라이즈 아키텍트는 상호 보완적으로 DARB와 SOA CoE에 참여한다.
|
|---|
| 중복된 노력에서 기인한 비효율성과 기존 아키텍처 생성물들을 활용할 기회의 박탈 |
- DARB를 활용하여 SOA 디자인과 인프라스트럭처를 검사했다.
- 엔터프라이즈 서비스 버스(ESB)를 엔터프라이즈 통합 인프라스트럭처로서 사용했다.
- SOA 인프라스트럭처에 (확장된) 기존 시스템 관리와 모니터링 톨을 활용했다.
|
|---|
| EA의 일부로서 SOA만의 필요를 파악하지 못함. |
- DARB는 SOA 관련 프로젝트를 다른 비 SOA 프로젝트로서 검토했다.
- SOA를 EA 기능 아키텍처 도메인의 토대로서 구축했다.
|
|---|
거버넌스 관련 문제들
| 잠재적 문제 | 해결책 |
|---|
| SOA CoE 리더와 엔터프라이즈 아키텍트의 책임 중복 |
- EA는 SOA CoE의 멤버였고, SOA 리더는 DARB의 핵심 멤버였다. 따라서 합동의 결정이 이루어졌다.
|
|---|
| 같은 비즈니스 리소스를 위한 SOA와 EA간 경쟁 |
- SOA와 EA에 같은 거버넌스 위원회를 공유함으로써 비즈니스 리소스들이 같은 포럼에서 SOA와 EA의 필요를 채울 수 있게 되었다.
|
|---|
| 전체적인 엔터프라이즈에 영향을 미치는 상반된 아키텍처 결정 |
- 특정 SOA 관련 문제들을 제외하고, 다른 모든 아키텍처 결정들은 DARB에 의해 승인되었다.
|
|---|
그림 3은 우리가 EA 거버넌스 조직 모델을 활용하여 SOA 거버넌스 구조를 구현했던 방법을 보여주고 있다. (그림 3 크게 보기)
그림 3. 아키텍처와 SOA 거버넌스 조직 모델 매핑
교훈
고객 계약 수행 과정에서 드러났던 문제들을 통해서 우리들은 SOA를 채택하고 동시에 EA를 개발하는 것에 대한 값진 교훈을 얻었다. 다음 리스트는 우리가 배웠던 교훈들을 정리한 것이고, 여러분에게도 도움이 될 것이라 믿는다.
교훈 1: SOA는 EA 도메인의 하위 세트만을 다룬다.
- SOA 범위는 주로 서비스와 서비스의 구현에 맞춰진다.
- 대부분의 SOA 액티비티와 결정들은 EA 기능적 아키텍처 영역에 해당된다.
- SOA는 엔터프라이즈를 위해 구축된 정보 아키텍처, 시스템 관리, 운영 아키텍처 같은 다른 EA 영역들을 활용할 수 있다.
교훈 2: SOA 거버넌스는 EA와 IT 관리 구조를 활용한다.
- 서비스 모델은 SOA CoE에 의해 개발 및 관리되어야 한다.
- 아키텍처 검토 위원회와 조정 위원회는 SOA 거버넌스 필요를 다루어야 한다.
- 필요할 경우, SOA는 비즈니스 위원회 같은 특별한 위원회를 요구한다.
교훈 3: SOA 펀딩(funding) 모델은 EA의 범위를 벗어난다.
- 전통적인 EA 모델은 펀딩을 신경 쓰지 않는다.
- SOA 펀딩은 프로젝트 레벨이 아닌 엔터프라이즈 레벨에 있어야 한다.
- SOA 펀딩은 IT 펀딩 모델과 거버넌스를 활용해야 한다.
- 서비스 모델은 SOA CoE에 의해 개발 및 관리되어야 한다. 하지만, 중복시키는 것이 아닌 EA 기능 영역에서 참조되어야 한다.
교훈 4: SOA 인프라스트럭처(ESB)는 엔터프라이즈 에셋이 되어야 한다.
- ESB는 서비스를 사용하고 있는 시스템뿐만 아니라, 모든 엔터프라이즈의 필요를 다루어야 한다.
- ESB의 관리는 엔터프라이즈 시스템 관리 아키텍처의 일환으로 간주되어야 한다.
- ESB와 SOA 관련 보안은 엔터프라이즈 보안 정책에 순응해야 한다.
요약
EA가 확립된 엔터프라이즈에서 SOA를 구현하는 것 또는 이 두 가지를 동시에 개발하는 것은 어려운 일이다. 영향력, 거버넌스 기구, 프로세스, 아키텍처 등 범위의 중복에서 기인한 아키텍처 및 거버넌스 관련 문제들이 생긴다. 이러한 문제를 해결하려면, 계획이 잘 짜인 아키텍처 거버넌스와 SOA 거버넌스 모델을 갖고 있어야 하고, 이들이 서로 조화를 이루도록 하는 방법을 이해하고 있어야 한다. 또한 여러분보다 앞서서 이러한 문제들을 경험한 사람들이 전해주는 교훈에도 귀를 기울이면 시간과 돈을 줄일 수 있다.
감사의 말
이 글을 위해 값진 조언을 아끼지 않은 분들께 감사의 말을 전하고 싶다: Paul Bate, Ian Charters, Peter De Meo, Luba Cherbakov, Claudio Cozzi, Ray Harishankar, Kerrie Holley, Don Hutcheson, David Janson, Steven Barnes, Satish Kalyani, Sharon Fortune.
참고자료 교육
제품 및 기술 얻기
토론
- 포럼에 참여하기.
-
developerWorks 블로그
-
Service Oriented Architecture -- Off the Record with Sandy Carter
-
Best Practices in
Service-Oriented Architecture with Ali Arsanjani
-
WebSphere SOA and J2EE in Practice with Bobby
Woolf
-
Building SOA applications with patterns with Dr. Eoin Lane
-
Client Insights, Concerns and Perspectives on SOA with Kerrie Holley
-
Collaboration apps, SOA, open source, Apache Tuscany, and world
travel with Luciano Resende
-
Isn't it SOAnderful?: SOA, architecture, and developer issues
with Pat Flanders
-
Service-Oriented Architecture and Business-Level
Tooling with Simon Johnston
-
SOA Innovations with Dr. Liang-Jie Zhang
-
SOA, ESB and
Beyond with Sanjay Bose
-
SOA, Innovations, Technologies, Trends...and a little
fun with Mark Colan
-
Web Services Interoperability with Tom Glover
필자소개 | 
| | Mamdouh Ibrahim 박사는 Enterprise Architecture and Technology Center of Excellence의 Senior Certified Executive IT Architect 겸 Senior Technical Staff Member (STSM)이다. SOA Web Services Center of Excellence extended 팀의 멤버이기도 하다. 엔터프라이즈 아키텍처, SOA, 분산 컴퓨팅, 무선 기술 분야에서 30년 이상의 경력을 쌓았다. IBM IT Architect Certification Board의 멤버이며 IBM Architectural Thinking course의 작가 겸 강사이다. 컴퓨터 공학 박사 학위, 컴퓨터 공학, solid state science, 수학 석사 학위, 전기 엔지니어링과 수학 학사 학위가 있다. 센트럴 미시간 대학교의 부학장이다. OOPSLA 2002의 의장을 역임했으며, 2008년 까지 OOPSLA Steering Committee의 의장을 맡고 있다. ACM, IEEE Computer Society, AAAI의 멤버이다. |
| 
| | Gil Long은 IBM의 Distinguished Engineer이다. Worldwide Enterprise Architecture Education 리더 및 SOA Governance integration 리더로서, 엔터프라이즈 아키텍처 디자인, 트랜지션 플래닝, SOA 인프라스트럭처 플래닝을 전문으로 하고 있다. IT 전략 플래닝, 아키텍처 디자인, 비즈니스 시스템 디자인 및 구현, 시스템 및 네트워크 디자인 및 전개, 데이터 센터 운영 등 IT의 모든 분야에서 전문적인 관리를 수행하고 있다. 큰 IT 조직, 스태핑, 예산 산정 분야에도 관리 책임을 맡고 있다. 보건, 금융 서비스, 교육, 유통, 보험, 유틸리티, 제조, 정부 분야에서도 다양한 경험을 쌓았다. |
기사에 대한 평가
| |
