 | |
|
난이도 : 중급 Dr. Mamdouh Ibrahim, Senior Certified Executive IT Architect and STSM, IBM
Gil Long, Distinguished Engineer, IBM
2007 년 10 월 02 일 본 시리즈 Part 2에서는 서비스 지향 아키텍처(SOA)와 엔터프라이즈 아키텍처(EA)의 아키텍처와 거버넌스 모델을 설명하고 이들의 유사점과 차이점을 비교합니다. EA와 SOA 액티비티를 엔터프라이즈 내에서 조정하지 않을 경우 겪게 될 잠재적인 문제에 대해서도 설명합니다.
머리말
세 파트의 기술자료를 통해서 SOA와 EA 간 유사점과 차이점을 알아내고, 실제로 이들이 겹치게 되면서 발생하는 잠재적 문제들을 해결하는 방법을 설명한다. 이를 위해서 IBM®은 광범위한 비즈니스 변형과 IT 아웃소싱 서비스를 제공하고, 모든 클라이언트의 IT 운영- 메인프레임, 미드레인지, 데스크탑, 헬프 데스크, 음성(voice) 및 데이터 네트워크, 애플리케이션 개발, 관리를 담당한다. SOA와 EA에 필요한 것은 동시에 개발되어야 한다는 점이다.
본 시리즈,
Part 1
—에서는 SOA와 EA의 정의와 범위를 설명하여 이 두 가지를 적절히 비교하고 대조하는 프레임웍을 구축하였다. 또한, SOA와 EA가 단순한 아키텍처 이상이며, 특히, 이 두 가지는 아키텍처, 거버넌스, 로드맵으로 구성된다고 설명했다. 각자의 다양한 영역들의 분파와 이 두 가지를 위한 거버넌스 프레임웍에 대해서도 설명했다.
Part 2
에서는, SOA와 EA 간 유사점과 차이점을 구분하는데 초점을 맞추고 이 두 가지의 아키텍처를 고려하고 상응하는 영역들 간 겹치는 부분을 구분할 것이다. 엔터프라이즈가 EA를 개발했을 때(또는 개발하고 있을 때) 발생하는 잠재적인 문제들을 설명하고, SOA를 구축할 것이다. 그리고 나서, EA와 SOA의 거버넌스 측면에 초점을 맞추고 유틸리티 업계의 Fortune 500 기업들에서 작업하면서 이 아키텍처로 무엇을 수행할 수 있을 것인가에 대한 분석도 할 것이다.
Part 3
에서는 필자가 클라이언트와 함께 일하면서 겪었던 문제들을 통해 배웠던 경험을 토대로 이러한 문제에 대한 가이드를 제시할 것이다.
SOA와 EA의 A가 의미하는 것
SOA와 EA의 아키텍처의 다른 도메인들간 겹치는 부분들을 파악하기 위해 그림 1과 2를 보자. 각각 EA와 SOA의 도메인들을 묘사하고 있다. 이러한 다이어그램을 매핑의 토대로서 사용할 수 있다.
그림 1. EA 아키텍처 도메인
그림 2. SOA 솔루션 스택
다음 표에서는 SOA와 EA의 아키텍처 도메인들 간 매핑을 제공한다. SOA 도메인과 EA 도메인들 간 상당한 중복이 있다는 것이 명확해진다.
Table 1. SOA와 EA 아키텍처 도메인 매핑
| 아키텍처 도메인 | SOA 솔루션 스택 | EA 프레임웍 |
|---|
| 비즈니스 | 비즈니스 프레임웍 | 비즈니스 아키텍처 |
|---|
| 애플리케이션 | 서비스와 컴포넌트 | 애플리케이션 아키텍처 |
|---|
| 통합 및 미들웨어 | 통합 아키텍처 / ESB | 기술 아키텍처 |
|---|
| 데이터 | 데이터 아키텍처 | 정보 아키텍처 |
|---|
| 연산 | QoS, 보안, 모니터링, 인프라스트럭처 | 기술 아키텍처 |
|---|
SOA 도메인들이 EA 도메인의 하위 세트라는 점도 분명해진다. 예를 들어, SOA는 비즈니스 아키텍처의 개발에는 관여하지 않는다. 대신, 비즈니스 프로세스의 결과와 Component Business Modeling (CBM) 같은 비즈니스 아키텍처 생성물들을 인풋으로서 사용하여 비즈니스 서비스를 규명한다. 반대로, EA는 비즈니스 아키텍처의 개발에 관여한다. 비즈니스 프로세스와 CRM이 이에 속한다. 애플리케이션 아키텍처의 관점에서 볼 때, SOA는 서비스의 모델링과 개발에 관여하고 이들을 실현하는 컴포넌트에 관여하지만, EA 아키텍처는 SOA 스팩의 생성물뿐만 아니라, 기타 컴포넌트, 패키지, 전체 엔터프라이즈용 시스템을 다룬다.
기술 아키텍처를 분석할 때, SOA ESB는 EA가 다루어야 하는 많은 통합 메커니즘들 중 하나일 뿐이다. 또한, SOA는 Content Management Architecture에 관여하지 않지만, EA는 관여한다.
또 겹치는 부분은 보안과 서비스 관리이다. 사실, SOA 보안은 EA가 반드시 지정해야 하는 전체 보안의 특별한 경우이고, SOA 서비스 관리와 모니터링은 EA가 다루어야 하는 시스템 관리의 하위 세트이다.
아키텍처 도메인: 유사점과 차이점
다음은 SOA와 EA 아키텍처의 유사점과 차이점을 요약한 것이다.
유사점
SOA와 EA 도메인은 많은 유사점이 있다. 예를 들어,
- 비슷한 아키텍처 도메인들을 다루고 있다.
- IT와 비즈니스를 긴밀히 제휴시킨다.
- 비즈니스 목표에 기반하여 인풋을 사용한다.
- 비슷한 전략 및 플래닝 액티비티를 필요로 한다.
차이점
EA 아키텍처 도메인의 초점은 거시적(macro) 수준이지만, SOA 아키텍처 도메인은 근시적(micro) 수준이다.
- EA는 비즈니스 컴포넌트를 정의하는데 초점을 맞추고, SOA는 비즈니스 서비스에 집중한다.
- EA는 애플리케이션 프레임웍과 엔터프라이즈 애플리케이션들을 다루고, SOA의 범위는 서비스 모델링이다.
- EA는 서버, 데이터베이스 같은 엔터프라이즈 레벨의 인프라스트럭처를 다루고, SOA는 서비스, 특히 Enterprise Service Bus를 지원하는 인프라스트럭처에 초점을 맞춘다.
- EA는 엔터프라이즈 통합 패턴과 이들의 사용 시기를 다룬다. point-to-point 통합, 파일 전송, 기타 전통적인 애플리케이션 통합 방식이 이에 속한다. SOA는 서비스를 사용하는 것에 기반한 통합 방식을 제공한다. SOA의 통합 방식이 가장 유연하고 권장할 만한 방식이지만, EA가 정의 및 지원해야 하는 방식들 중 하나일 경우에만 고려해야 한다.
잠재적 문제들
EA와 SOA의 아키텍처 도메인들간 겹치는 부분 때문에, 다음과 같은 잠재적 문제들이 생긴다.
- 엔터프라이즈가 SOA에만 초점을 맞춘다면, 다른 EA 측면들이 무시된다. 예를 들어, SOA에서 지원되는 것 이와의 통합 방식과 표준에 대한 합법적 필요(예를 들어, point-to-point 인터페이스)가 무시되고 엔터프라이즈 레벨에서 다뤄지지 않는다. 또한, EA 없이는, 기업은 Golden Hammer 반패턴(antipattern)을 적용하게 되고(해머(hammer)가 여러분의 전용 톨이라면, 모든 것이 문제로 비춰질 것이다.), 모든 솔루션에 SOA를 사용하게 될 것이다.
- SOA와 EA를 동시에 개발하려는 노력 속에서 중복 노력과 기존 아키텍처 생성물들을 활용할 기회를 놓치는 등 비효율성을 낳게 될 것이다. SOA와 EA 개발에 참여하는 두 팀들은 중복되고, 가끔은 대비되는 것을 만드느라 불필요한 시간과 리소스를 사용하게 될 것이다.
- EA로 다루어져야 하는 부분과, SOA에서 다루어야 하는 부분에 대해 신중하게 생각하지 않는다면, 기업은 EA의 일부로서 SOA만의 필요(XML과 BPEL 같은 SOA 중심의 표준)를 규명하지 못하게 된다.
거버넌스(Governance)
거버넌스 정의는 관리 될 도메인에 따라 다르다. IT 거버넌스, 아키텍처 거버넌스, SOA 거버넌스가 있다. 하지만, 이러한 다양한 거버넌스에도 관계가 있고, 그 부분을 본 섹션에서 설명하고자 한다.
거버넌스의 정의는 관리 될 도메인에 의존한다. 다음은 다른 도메인들에 대한 거버넌스의 정의이다.
IT 거버넌스
"IT와 프로세스를 통해 위험 요소와 수익의 균형을 맞추고 가치를 부가하여 기업의 목표를 달성하기 위해서 엔터프라이즈의 방향을 정하고 제어하는 관계와 프로세스의 구조" —
The IT Governance Institute
아키텍처 거버넌스
"엔터프라이즈 아키텍처와 기타 아키텍처들이 엔터프라이즈 레벨에서 관리 및 제어하는데 기준이 되는 프랙티스와 방향성. 일반적으로, 고립되어 수행되지 않고, 거버넌스 구조 계층 내에 (특히, 대기업) 존재하며, Corporate Governance, Technology Governance, Information Technology (IT) Governance, Architecture Governance 등이 포함된다." —
The Open Group
SOA 거버넌스
"엔터프라이즈가 서비스 지향으로 가게 되면서 SOA 거버넌스는 IT 거버넌스로 확장된다. SOA는 엔터프라이즈의 전략과 목표를 수행하기 위한 노력으로 비즈니스와 IT를 개입시키는 교차 기능적 이니셔티브이다. 따라서, SOA 거버넌스는 엔터프라이즈와 IT 거버넌스 간 차이를 메운다." —
Kerrie Holley, IBM Fellow
다음의 비교는 거버넌스 프로세스 보다는 거버넌스의 조직 모델에 초점을 맞춘 것이다.
거버넌스 조직 모델
거버넌스 프로세스를 지원하기 위해, 거버넌스 조직이 확립되어 이러한 프로세스를 정의, 실행, 관리해야 한다. 본 섹션에서는 SOA와 EA용 거버넌스 조직을 비교한다.
아키텍처 거버넌스 모델
그림 3은 아키텍처 거버넌스의 전형적인 조직 모델을 묘사하고 있다. (IBM)
그림 3. 전형적인 아키텍처 거버넌스 조직
이러한 아키텍처 거버넌스 조직에서, 아래쪽의 관리 기구들은 개별적인 프로젝트를 다루는 반면, 중간 부분에서는 프로그램 레벨에서 거버넌스를 확립한다. (일반적으로 여러 프로젝트들을 관리한다.) 가장 윗 부분에서는 외부 엔티티와 스테이크홀더로의 링크를 제공한다. 이 글의 정황상 중요한 것은 중간 티어에 있는 Architecture Review Board (ARB)와 Architecture Steering Group (ASG)이다.
ARB는 EA를 소유 및 관리한다. 많은 경우, 어떤 디자인 기구도 없다면, ARB가 프로젝트 팀에 가이드를 제시하면서, 프로젝트 아키텍처를 개발한다. ARB는 개별 프로젝트가 EA에 순응하도록 하고 필요할 경우 예외도 허용한다.
ASG는 아키텍처 정책을 수립하고 ARB에 의해 생긴 문제들을 해결한다. ARB와 ASG 모두 책임을 뚜렷하게 분리하고 다른 두 티어(tier)에 있는 관리 기구들과 면밀하게 인터랙션 한다.
SOA 거버넌스 모델
그림 4는 SOA용 거버넌스 조직 모델이다. 이 거버넌스 모델에 묘사된 주요 팀들은 다음과 같다:
- SOA Executive Steering Committee는 엔터프라이즈에서의 SOA의 방향을 설정한다.
- SOA Review Board는 SOA 표준과 정책들이 모든 SOA 관련 프로젝트에 적용되도록 한다.
- SOA Business Council은 LOB 조직으로의 링크로서 개발 될 서비스들을 규명하고 우선순위를 정의하고, 비즈니스에 있어서 중요하다.
- SOA Center of Excellence (CoE)는 모든 프로젝트에서 SOA 개발을 감시하고 가이드를 제공한다.
그림 4. SOA 거버넌스 조직
EA와 SOA 거버넌스: 유사점과 차이점
검토 기구와 조정 위원회가 SOA와 EA 거버넌스 조직 모델에 존재한다는 것을 알았다. 하지만, SOA 거버넌스 조직 모델은 전통적인 EA 거버넌스 조직 모델을, SOA CoE와 SOA Business Council을 도입하여 확장하는데, 이와 같은 것이 EA에는 없다.
각각의 책임을 기준으로, 다음 리스트는 SOA 및 EA 거버넌스 조직을 연결한 것이다.
- SOA Executive Strategy Committee는 Architecture Steering Group과 같다.
- SOA Review Board는 Architecture Review Board와 같다.
- SOA CoE는 Design Authority와 같다. (이 개념은 영국, 유럽, 중동, 아프리카에서는 유명하지만, 미국에서는 사용되지 않는다.) 하지만, 디자인 기구가 존재함에도, 기업은 SOA를 채택하게 되면서 기대할 수 있는 이익의 실현을 보장할 SOA CoE를 만들지 않고 있다.
- SOA Business Council은 EA 환경에는 없다.
요약하면, SOA와 EA 거버넌스에는 많은 유사점과 차이점이 있다.
유사점
- 특별한 위원회 감독이 필요하다.
- 검토 위원회가 필요하다.
- 엔터프라이즈 레벨에서 문제들을 다룬다.
- 비즈니스 및 IT 스테이크홀더들이 모두 다루어져야 한다.
차이점
- SOA는 비즈니스 단위들과 밀접하게 상호 작동하는 SOA Business Council의 형태로 된 비즈니스 가시성을 필요로 한다.
- SOA는 자금 조달을 포장할 구체적인 평가가 필요하다. 이는 전통적인 EA 거버넌스 모델의 영역이 아니다.
- SOA CoE는 EA 조직에는 없는 개별 엔티티다.
- EA 거버넌스는 일반적인 리더쉽과 스폰서 레벨(전략)에서 거버넌스를 다루지만, SOA 거버넌스는 거버넌스를 수행하는 툴을 사용하는 기술에 초점을 맞춘다. (따라서 거버넌스라기 보다는 관리(management)에 가깝다.)
잠재적 문제
엔터프라이즈가 SOA와 EA 거버넌스를 개발하게 될 경우 직면하게 될 가장 뚜렷한 문제들은 다음과 같다.
-
SOA CoE 리더와 엔터프라이즈 아키텍처의 책임 영역의 중복. 책임의 중복은 혼란과 분열을 일으켜서, 결국 SOA와 EA의 성공을 막는다.
-
같은 비즈니스 리소스에 대한 SOA와 EA 간 경쟁. 대부분의 엔터프라이즈에서, 문제가 되는 것은 부족한 리소스이다. 이러한 리소스들을 SOA와 EA의 중복되고 비슷한 액티비티에 사용한다는 것은 비효율성을 낳게 된다. 이러한 부족한 리소스로는 한 액티비티에도 기여할 수 없다.
-
전체 기업에 영향을 미치는 모순되는 아키텍처 결정. SOA와 EA 프로세싱 노력이 독립적으로 이루어진다면, 한쪽 또는 다른 쪽에서 이루어진 결정들이, 그러한 결정에 의존하는 사람들에게 혼란을 가져올 수 있다.
요약
지금까지, 아키텍처와 거버넌스의 관점에서 SOA와 EA 간 유사점과 차이점에 대해 배웠다. 엔터프라이즈에서 EA와 SOA 액티비티를 조정하지 않는다면 부딪치게 될 잠재적 문제들도 설명했다. Part 3에서는 실질적인 경험을 토대로 한 문제 해결 방법을 설명하겠다.
감사의 말
Academy of Technology Study EA를 이끌고 있는 Ian Charters에게 감사의 말을 전한다. 또한, 이 글에 특별히 조언을 준, Paul Bate, Luba Cherbakov, Claudio Cozzi, Peter De Meo, Ray Harishankar, Kerrie Holley, Don Hutcheson, David Janson, Steven Barnes, Satish Kalyani, Sharon Fortune에게도 감사의 말을 전하고 싶다.
참고자료 교육
제품 및 기술 얻기
토론
필자소개 | 
| | 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 조직, 스태핑, 예산 산정 분야에도 관리 책임을 맡고 있다. 보건, 금융 서비스, 교육, 유통, 보험, 유틸리티, 제조, 정부 분야에서도 다양한 경험을 쌓았다. |
기사에 대한 평가
| |
