난이도 : 중급 Kunal Mittal, Portal/J2EE 아키텍트, Consultant
2005 년 11 월 18 일 각 아키텍쳐 레벨을 효율적으로 구분하는 방법을 알고싶은가?
Part 2에서는 SOA 성숙도 모델을 통해 아키텍쳐의 성숙도 레벨을 평가하고 할당하는 방법을 설명할 것이다.
Part 1에서는
SOA 모델을 구축하는데 필요한 새로운 프로세스와 방법을 설명했다. 머리말
SOA 성숙도 모델(SOA maturity model)이란
전체적인 IT 아키텍쳐 이니셔티브에서 더 나은 레벨의 성숙도와 예견가능성을 이룩하는데 도움이 되는 아키텍쳐 가이드라인과
프로세스를 정의하는 과정에서 만들었던 용어이다. 이 글에서 내가 설명하는 모델은 다섯 가지 레벨로 구성된다.
이 모델이 진정한 서비스 지향 아키텍쳐를 달성하는데 도움이 될 것으로 믿는다. SOA 성숙도 모델을 반복적으로 적용하면
IT 기업들이 빠르게 변화하는 비즈니스의 요구 사항들을 효과적으로 대응할 수 있을 것이다. 각 성숙도 레벨에 따라
아키텍쳐 중심의 목표를 달성하는 방법을 설명하겠다.
성숙도 모델의 중요성
낮은 성숙도 레벨에서 개별 프로젝트 팀들은 비표준 기술을 사용하여 자신들의 아키텍쳐를 정의한다.
이러한 기술들은 예견하기도 힘들고 재사용 할 수 있는 솔루션도 아니기 때문에 관리하기가 힘들고 변화에 적응하지 못한다.
기업이 Level 3과 Level 4 정도의 성숙도에 이르게 되면 강력한 엔터프라이즈 아키텍쳐(EA) 그룹이 생겨난다.
이것은 아키텍쳐 원리들을 관리하는 운영기구와 같은 것이다. 재사용 가능한 아키텍쳐의 엘리먼트들이 나타나고
각 업종(LOB)의 필요에 유연하게 대처한다. 이러한 솔루션은 효과적이며 일정한 수준의 상호 운용성을 제공하여
결국 서비스를 지향하게 된다. Level 5는 기업이 SOA 이니셔티브를 성공적으로 구현했다는 것을 의미한다.
이러한 유형의 기업은 스스로의 가치를 보유하고 있고 LOB들간(더 나아가서 사용자, 파트너, 공급자, 경쟁자들까지) 서비스들을
구현하고 공유할 수 있는 경지로 진화되었다.
이 모델은 기업의 IT 아키텍쳐의 모든 측면에 적용된다. 개발 부분에 강력한 영향을 줄 뿐만 아니라
IT 기업 내의 아키텍쳐(개발, 논리적, 물리적, 프로세스 아키텍쳐)에도 똑같이 중요하게 적용된다.
SOA 성숙도 모델
능력 성숙도 모델(CMM)이 기업의 소프트웨어 개발 프로세스의 성숙도(software development process)를 측정하는데 사용된다면
SOA 성숙도 모델은 기업의 SOA 개발 프로세스의 성숙도를 평가한다. 나는 SOA 성숙도 모델을 다섯 가지 단계로 정의했다.
("프로세스와 방법론, Part 1: 기초")
그림 1은 기본적인 SOA 성숙도 모델이다.
그림 1. The SOA 성숙도 모델
Level 1: 초기(Initial)
Level 1 상태에 있는 기업은 아키텍쳐에 대한 공식적인 프로세스가 없다. 아키텍쳐와 프로젝트도 분리되어 있지 않다.
일반적으로 이러한 기업들은 EA 팀도 없다. 대게, 부서별로 나누어진 각 프로젝트 팀은 사일로(silo)에서 작업한다.
개별 프로젝트를 수행하는 것에 초점을 맞추고 있다.
이 레벨의 특징은 예측이 불가능한 프로젝트 스케줄, 예산 초과, 재사용도 불가능하고 관리도 힘든 형편없는 코드 품질 등으로
점철된다. 프로젝트는 같은 태스크를 반복한다. 이렇게 다소 미성숙한 레벨에서는 IT는 다른 방법 대신에 비즈니스 기민성을
강조하는 경향이 있다.
Level 2: 반복(Repeatable)
이 레벨에서는 몇몇 아키텍쳐 요소들이 나타난다. 프로젝트 팀들은 재사용 가능한 아키텍쳐를 정의한다.
비공식 통신 경로가 프로젝트 팀을 통해 구축된다. EA 팀은 이를 체계화 하고 프로젝트 팀들간 통신을 조장한다.
하지만 이 단계에서는 그와 같은 팀은 존재하지 않으며 통신도 혼란 그 자체이다.
이 레벨의 특징은 아키텍쳐 컴포넌트의 재사용성이다. 프로세스와 혼란스러운 통신 라인은 아키텍쳐 솔루션에서
일정한 수준의 반복성을 띠게 되고 소프트웨어의 제품화 비용과 관리비용을 줄일 수 있다.
하지만 이것은 재무적 관점에서는 그렇게 중요한 영향을 주지는 못한다.
Level 2 가장 큰 장점은 구조화된 프로세스의 효용을 누릴 수 있다는 점이다.
예를 들어, 프로젝트 팀은 소프트웨어 개발에 상승 효과를 누릴 수 있는 접근 방식을 취함으로서
큰 혜택을 누릴 수 있다는 것을 알고있다. 이들이 예산 초과를 막을 수 있고 예견 가능한 소프트웨어 개발 스케줄을 만들고
소프트웨어의 전체 품질을 향상시킬 수 있다는 것을 인식하고 있다. 프로젝트 팀들간 통신 라인을 구축하는 사람들은 후원을 받고 있다.
Level 3: 정의(Defined)
Level 3 수준에 있는 기업들은 EA 이니셔티브에 얼마간의 투자를 해왔다.
EA 팀은 안정되어 있고 표준화된 아키텍쳐 요소들로 작업을 하면서 참조 아키텍쳐를 만들고 그 아키텍쳐에 대해 프로젝트 팀을
교육하고 관리 정책과 실행 정책을 정의한다. 일반적으로 EA 팀들은 기술적 컴포넌트와 프레임웍을 만들고
프로젝트 팀 전반에 걸쳐 이 프레임웍의 사용을 표준화 한다.
안타깝게도 EA 팀 이니셔티브는 가치 대비 비용이 커질 수 있다. 가장 큰 비용은 아키텍쳐 관리 비용이다.
오늘날 척박한 경제 환경에서 일반적으로 EA는 관리되지 않는다. 핵심 아키텍쳐 팀이 프로젝트를 수행하는 쪽으로 이동했기 때문이다.
이 때문에 EA의 가치와 적용성이 떨어진다. 이 레벨의 또 다른 문제는 팀들간 줄다리기이다.
프로젝트 팀들은 EA 팀의 "감시하는듯한 태도"를 존경하거나 좋아하지 않는다. 이와 마찬가지로 EA 팀 멤버들도
LOB의 비즈니스에 대한 지식이 부족하고 LOB를 공급하는 프로젝트 팀들과 통신하지 않는다.
그렇다면 이 성숙도 레벨에서는 어떤 이점이 있을까?
무엇보다도 이 레벨은 SOA의 필요성을 인식하는 첫 번째 단계이다. EA 노력이 헛수고처럼 보인다.
왜냐하면 LOB의 필요를 충족시킬 수 있을 정도로 민첩하지 않기 때문이다. 분야에 대한 지식의 부족도 EA 팀에게는 큰 문제이다.
이러한 단점을 인식하는 EA 팀들은 오히려 성공적이라고 볼 수 있다. 그들은 스스로를 전문가라고 생각해서는 안된다.
이러한 인식은 이들을 성공으로 이끌고 기업이 다음 단계의 성숙도 레벨로 올라가도록 하는 견인차 역할을 하는 것이다.
Level 4: 관리(Managed)
이 레벨에서는 EA 팀이 SOA로 가는 경로를 정의하기 시작한다. 오늘날 모든 큰 기업에는 SOA를 다루는 아키텍트 그룹이 있다.
적어도 이 아키텍트들은 SOA의 가치를 인식하고 있고 SOA 전략을 고안해내고자 한다.
Level 4에서는 프로젝트 팀과 EA 팀은 협업하여 기업의 SOA는 물론 프로세스, 기술, 컴포넌트들을 정의해야 한다.
관리와 "보상" 정책이 정의되어야 한다. 지원 레벨 역시 언제 누구와 연락할지 왜 연락하는지에 대한 분명한 이해를 통해
구축되어야 한다. 서비스를 정의하는 분석가를 위한 프레임웍도 마련되어야 한다.
- LOB나 프로젝트 팀이 자신들이 제공할 수 있는 잠재적 서비스나 다른 프로젝트 팀에서 가져올 수 있는 잠재적 서비스를 어떻게 구분하는가?
- 서비스를 구현하고 관리하는 책임은 누구에게 있는가?
- 비용은 누가 부담하는가?
위 세 가지 질문들은 SOA 플래닝 시 다루어야 하는 문제들이다.
이 성숙도 레벨에는 많은 위험성과 함께 많은 혜택들이 공존한다. 특히 Level 4는 단기적인 비용 이득이 없다.
Level 4를 실행하기 위해서는 어느 기업에나 비용이 들기 마련이다. 올바르게 수행되었다면 기업은 Level 5로 나아갈 수 있다.
엉망으로 수행되었다면 기업은 Level 2로 떨어진다. EA 팀은 해체되거나 지원을 거의 받지 못하기 때문이다.
Level 5: 최적화(Optimizing)
Level 5는 해탈의 경지이다. 아키텍쳐 프로세스와 정책들이 제도화된다. SOA의 가치를 확고히 인식한다.
제대로 된 프레임웍에서 각 팀은 서비스를 노출하고 소비한다. 이 레벨에서 기업은 SOA의 진정한 가치를 경험할 수 있다.
이들은 서비스를 그들의 비즈니스 파트너, 공급자, 사용자와 교환하는 방법을 규명한다.
이 레벨에서, 재사용(기술 컴포넌트의 재사용이 아님)은 최대한의 비즈니스 민첩성을 이룩하기 위한 아키텍쳐의 핵심 요소이다.
이 레벨에서 기업들은 비즈니스 필요에 빠르게 대응할 수 있는 보다 민첩성을 갖추면서 비용과 시간 효용을 누릴 수 있다.
이 레벨의 핵심 목표는 아키텍쳐 이니셔티브의 목표를 정의하는 것이다. 높은 표준과 목표가 확고하게 정해져서
실현해 나가야 한다. 이러한 비전 없이는 Level 4에서 투자했던 비용을 회수할 길이 없다.
각 레벨의 특징과 영향
지금까지 다섯 가지 SOA 성숙도 레벨을 보았다. 표 1에는 각 레벨의 특징과 영향을 정리해 놓았다.
표 1. SOA 성숙도 모델 레벨별 개요|
레벨
|
특징
|
영향
| | Level 1: 초기 |
- 공식적인 소프트웨어 개발 프로세스가 없다.
- 아키텍쳐에 대한 문서화도 미비하다.
- 프로젝트 팀들간 통신이 되지 않는다.
|
- 프로젝트들 간 일관성 있는 아키텍쳐가 없다.
- 결과 시스템을 이해 및 수정하기가 어렵다.
- 재사용 가능한 객체들이 미비하다.
- 팀은 매 프로젝트마다 새롭게 시작한다.("바퀴를 다시 만든다.")
| | Level 2: 반복 |
- 아키텍쳐에 대한 문서화가 어느 정도는 되어 있다.
- 프로젝트 팀 내에서 아키텍쳐가 적용된다.
- 프로젝트 팀들간 아키텍쳐의 통신이 이루어진다.
|
- Level 1 보다 약간 향상되었다.
- 성공한 실례들이 반복된다.
- EA의 가치가 인정 받는다.
| | Level 3: 정의 |
- EA팀은 참조 아키텍쳐와 소프트웨어 개발 실례들을 정의한다.
- 프로젝트 팀은 이 아키텍쳐를 사용할 것을 권장 받는다.
- EA는 각 LOB의 모든 필요들을 충족시키지는 못한다.
|
- 동의에 이르기가 힘들다. EA팀과 프로젝트 팀간 협업이 잘 이루어지지 않는다.
- 아키텍쳐 관리가 중요한 문제이다.
- 아키텍쳐 수명은 6개월에서 12개월 정도이다.
| | Level 4: 관리 |
- SOA가 아키텍쳐 이니셔티브의 목표로서 간주된다.
- LOB와 EA팀이 SOA를 정의한다.
- 지원 및 관리 모델이 정해진다.
- LOB는 서비스를 노출 및 소비할 수 있다.
|
- 투자에 대한 이익이 돌아온다.
- 일관성 없는 아키텍쳐 레이어로 인해 프로젝트가 지연될 위험성이 줄어든다.
- 기업 내의 SOA가 힘을 얻기 시작한다.
| | Level 5: 최적화 |
- SOA가 시작점이 된다.
- 기업은 고객, 공급자, 파트너가 진정한 서비스 지향의 효과를 경험할 수 있도록 한다.
- 지속적인 아키텍쳐 최적화가 이루어진다.
|
- 비즈니스가 빨라진다.
- 고객, 파트너, 공급자의 서비스들이 상호운용 된다.
- 제품화가 빨라진다.
- TCO(총 소유 비용)이 낮아진다.
|
요약
지금까지 SOA와 SOA 성숙도 모델의 기본 개념을 설명했다. 이 글 역시 능력 성숙도 모델(CMM)의 개념들과 관련이 깊다. (Part 1 참조)
SOA 프로젝트를 시작하는 것이 최상의 출발점은 아니다. 기업은 SOA 이니셔티브의 어떤 단계에 있는지를 파악해야 한다.
기업에 SOA를 성공적으로 구현하려면 IT에 대한 비전과 기업의 전체적인 아키텍쳐를 이해해야 한다.
SOA 성숙도 모델은 별다른 것이 아니다. 기업의 IT 아키텍쳐에 성숙도 레벨을 평가하는 수단인 것이다.
평가가 완료되면 자신의 기업이 SOA로 갈 수 있는 최선의 방법이 무엇인지를 결정하는데 도움이 된다.
이 모델을 적용하면, EA 그룹들은 개별 LOB에 제공해야 하는 서비스들이 무엇인지를 결정할 수 있다.
게다가 컨설팅 기업과 아웃소싱 회사는 이 모델을 사용하여 자신들의 서비스 오퍼링에 추가해야 하는 서비스 리스트들도
구축할 수 있다.
Part 3에서는 RUP와 XP를 섞은 새로운 소프트웨어 개발 방식을 소개하겠다.
바로 Service-Oriented Unified Process (SOUP)이다. SOUP은 소프트웨어 개발 과정을 두 단계로 나눈다.
RUP를 사용하여 SOA를 구현한 다음 이를 관리할 때에는 XP로 전환한다.
참고자료 교육
제품 및 기술 얻기
토론
필자소개  | 
| Kunal Mittal, Portal/J2EE 아키텍트, 컨설턴트 |
기사에 대한 평가
| 
