 | |
|
난이도 : 중급 Dr. Mamdouh Ibrahim, Senior Certified Executive IT Architect and STSM, IBM
Gil Long, Distinguished Engineer, IBM
2007 년 9 월 04 일 서비스 지향 아키텍처(SOA)와 엔터프라이즈 아키텍처(EA) 시리즈 Part 1에서는, 서비스 지향 아키텍처(SOA)와 엔터프라이즈 아키텍처(EA)가 어떻게 서로 조화를 이루는지를 설명합니다. 우선, SOA와 EA의 의미와 범위를 설명하고, 이 둘을 비교합니다.
머리말
SOA와 EA, 그리고 이들의 거버넌스를 면밀히 조사해 보면 개념, 액티비티, 프로세스, 결과가 많은 부분 중복된다는 것을 발견할 수 있다. 예를 들어, 두 개 모두 비즈니스 목표에 기반한 인풋을 필요로 하고 목표와 연결된 결과를 만들어 낸다. 더욱이, 이 두 가지 모두 엔터프라이즈 레벨에서의 문제(전략 및 기획, 레퍼런스 아키텍처 등) 들을 다루고 있으며, 거버넌스 모델은 비슷하다. SOA를 채택하면서, 이와 동시에 EA와 거버넌스를 개발하고 있는 기업이 EA와 SOA 간 유사성과 중복성 등을 고려하지 않는다면 큰 문제를 일으킬 수 있다.
본 시리즈의 내용은 유틸리티 산업 분야의 Fortune 500 기업에 참여하면서 얻은 실질적인 경험을 토대로 하고 있다. IBM®은 광범위한 비즈니스 변형과 IT 아웃소싱 서비스를 제공하고, 클라이언트의 모든 IT 기능(메인프레임, Midrange, 데스크탑, 헬프 데스크, 음성 및 데이터 네트워크, 애플리케이션 개발, 관리) 들을 관리했다. 세 편의 시리즈에서는 중복성 같은 잠재적인 문제들을 구체적으로 살펴보고, 이 같은 문제들을 해결하는 가이드라인을 제시하고자 한다.
-
Part 1에서는 SOA와 EA의 정의와 범위를 설명하여 이 두 가지를 올바르게 비교할 수 있는 토대를 마련한다.
-
Part 2
에서는, SOA와 EA를 비교한다. 엔터프라이즈가 EA를 개발한 다음 SOA를 구현할 때 발생하는 문제들을 집중 조명한다.
-
Part 3
에서는 16억 달러의 SOA와 EA 프로젝트를 수행하면서 얻은 경험을 토대로 이러한 문제들을 해결하는 가이드라인을 제시한다.
많은 기업들이 SOA를 채택하게 되면서, EA와 거버넌스의 정황 속에 SOA 아키텍처와 거버넌스를 조화시키는 방법을 이해하는 것이 점점 더 중요해지고 있다. 특히, 다음과 같은 문제들은 반드시 다루어져야 한다.
- EA 범위 대 SOA 범위 (이들의 비슷한 측면들을 활용하는 방법)
- SOA Center of Excellence (CoE)와 EA 거버넌스 위원회 간 관계 (중복을 피하는 방법)
- SOA 아키텍처의 반응성과 오너쉽 (Enterprise Service Bus (ESB)가 엔터프라이즈 아키텍처의 어떤 부분과 맞고, SOA에는 어떻게 적용되어야 하는가?)
엔터프라이즈 아키텍처
EA 정의
IBM Academy of Technology Study는 EA를 다음과 같이 정의하고 있다.
"EA 원리는 공통의 비즈니스 또는 IT 목표를 효과적으로 조정하는데 필요한 아키텍처 모델, 거버넌스, 트랜지션 이니셔티브를 정의 및 관리한다."
이 정의는 EA가 단순한 아키텍처 이상이라는 것을 강조하고 있다. 또한, EA에 대한 필요성을 포착하여 엔터프라이즈의 비즈니스 전략을 다음과 같은 정의를 통해 변경 프로그램으로 연결시키고 있다.
- (비즈니스 아키텍처를 통해) 비즈니스의 구조를 포착하고, (공통적이며 명확한 IS 및 IT 아키텍처를 통해) 다중 프로젝트와 프로그램들이 정보 기술을 활용하는 방법에 대한 스팩을 제공하는 아키텍처 모델.
- 비즈니스의 모든 부분들을 기획하고, 조정하며, 제어하면서, 이들 모두가 같은 방향을 향하도록 하는 아키텍처 거버넌스와 트랜지션 플래닝 같은 메커니즘.
EA 프레임웍에는 어떤 부족한 점도 없다. Zachman은 최초로 이 개념을 공식화 했고 그의 이름을 딴 EA용 프레임웍을 발표했다. 그 이후, 많은 EA 프레임웍들이 발표되었고 많은 기업들에 의해 사용되고 있다. 이 같은 프레임웍은 그림 1처럼 묘사될 수 있다.
그림 1. 다양한 EA 모델들
그림 1에 나오는 다양한 약어들을 풀면 다음과 같다.
- FEAF — Federal Enterprise Architecture Framework
- TEAF — Treasury Enterprise Architecture Framework
- DoDAF — Department of Defense Architecture Framework
- NASCIO — National Association of State Chief Information Officers
그림 2는 IBM Academy of Technology Study on EA의 일환으로 개발된 프레임웍을 묘사하고 있다. 정의에 언급된 모든 개념들을 다루고 있고 EA가 엔터프라이즈 전략(비즈니스와 IT)과 비즈니스 운영 환경과 IT 인프라스트럭처 간 링크로서 배치되는 방법을 보여주고 있다. 다음 섹션에서는 EA의 다양한 측면들에 대해 보다 자세히 살펴보기로 한다.
그림 2. IBM EA 프레임웍
EA는 아키텍처 이상이다.
이 아키텍처는 EA의 일부에 불과하다. 특히, EA에는 아키텍처, 거버넌스, 로드맵이 포함된다. 그림 3은 이러한 EA의 구현 블록과 비즈니스의 목표를 달성하기 위해 프로젝트와 교류하는 방법을 묘사하고 있다.
그림 3. EA에는 아키텍처, 거버넌스, 로드맵이 포함된다.
EA 프레임웍
EA의 개발과 구현을 위해 IBM에 의해 구축된 프레임웍은 여러 아키텍처 도메인과 거버넌스로 구성된다. (그림 4)
그림 4. 플래닝 과정에서 EA 도메인과 거버넌스 배치하기
EA의 일부로서 모델링 되어야 하는 아키텍처 도메인은 다음과 같다.
- 비즈니스 아키텍처
- 애플리케이션 아키텍처
- 정보 아키텍처
- 기술 아키텍처
아키텍처 거버넌스 프레임웍에는 올바른 승인, 예외, 통신, 아키텍처의 수명을 보장하기 위해 확립되어야 하는 구조와 프로세스가 포함된다.
SOA
SOA 정의
모든 사람들의 동의를 얻은 SOA의 정의는 아직 존재하지 않는다. 대신, 여러 정의들이 다양한 그룹, 벤더, 비즈니스 분석가들에 의해서 발표되었다. 이러한 정의들은 SOA가 비즈니스에 미치는 영향을 분석한 고급 분석에서부터 SOA 기반의 솔루션의 기술적 측면에만 초점을 맞춘 정의에 이르기까지 다양하다. 다음은 소프트웨어 개발 분야에서 사용되는 SOA 정의이다.
W3C 정의:
"호출될 수 있는 컴포넌트 세트이며, 이것의 인터페이스 디스크립션은 퍼블리시 및 발견될 수 있다."
CBDI의 정의:
"애플리케이션 기능이 서비스 소비자와 관련한 세분성으로 발표된 서비스 세트로서 제공 및 소비될 수 있도록 하는 정책, 프랙티스, 프레임웍으로, 단일의 표준 기반의 인터페이스 형태를 사용하여 구현으로부터 추상화 된다."
Gartner 정의:
"서비스 지향 아키텍처는 클라이언트/서버 소프트웨어 디자인 방식으로서, 애플리케이션은 소프트웨어 서비스와 소프트웨어 서비스 소비자(클라이언트 또는 서비스 요청자)로 구성된다. SOA는 소프트웨어 컴포넌트들 간 약결합을 강조하고 개별적으로 독립된 인터페이스를 사용한다는 점에서 일반적인 클라이언트/서버와는 다르다."
IBM 정의:
IBM은 SOA와 비즈니스 목표와 엔터프라이즈 목표간 관계를 중요하게 여기므로, IBM SOA Center of Excellence는 이에 걸맞는 SOA의 정의를 개발했다.
"서비스 지향 아키텍처는 리소스를 온 디맨드 방식으로 연결하기 위한 엔터프라이즈 용 IT 아키텍처이다. 이러한 리소스들은 비즈니스 필요를 채우기 위해 밸류 넷, 엔터프라이즈, LOB(line of business)에 참여할 수 있는 서비스들로서 구현된다. SOA 애플리케이션의 기본적인 요서는 하위 시스템, 시스템, 컴포넌트와 반대되는 서비스이다."
SOA를 인식한다는 것은 많은 것들이 여러분의 관점에 기반한다는 것을 의미하고, 비즈니스, 아키텍처, 구현 관점을 다루기 위해 세 개의 정의가 도입된다. 다음과 같은 정의가 도입되었다.
비즈니스 관점의 정의:
비즈니스가 고객과 파트너 또는 조직의 다른 부분에 노출하고자 하는 비즈니스.
아키텍처 관점의 정의:
서비스 공급자, 요청자, 서비스 디스크립션을 필요로 하는 아키텍처 스타일.
모듈성, 캡슐화, 약결합, 영역의 분리, 재사용, 합성 가능성, 단일 구현 같은 특성들을 다루는 아키텍처 원리, 패턴, 기준.
구현 관점의 정의:
웹 서비스 같은 표준, 툴, 기술로 완성된 프로그래밍 모델.
SOA는 아키텍처 그 이상이다.
EA와 마찬가지로, SOA는 아키텍처 그 이상이다. 아키텍처 측면에 더하여, SOA는 엔터프라이즈가 이를 완전히 채택할 수 있도록 하는 거버넌스와 트랜지션 로드맵을 필요로 한다. 사실, EA에 포함된 것을 설명하는데 사용된 똑 같은 그림이 SOA를 설명하는 데에도 사용될 수 있다. (그림 5)
그림 5. SOA는 아키텍처 그 이상이다.
SOA 솔루션 스택
SOA는 프로세스, 서비스, 컴포넌트로 구성된다. SOA의 중심에는 서비스와 컴포넌트를 정의하는 서비스 모델이 있다. 그림 6은 SOA 솔루션 스택을 보여주고, SOA를 구성하는 다양한 엘리먼트들 간 관계를 보여주고 있다.
그림 6. SOA 솔루션 스택
이러한 아키텍처는 복합 서비스들이 비즈니스 프로세스로 정렬되는 방식을 보여주며, 엔터프라이즈 급(대단위) 컴포넌트들은 서비스를 구현하고 있다. 비즈니스 프로세스는 노출된 서비스들을 복합 애플리케이션들로 구성함으로써 지원된다. 이 아키텍처는 여러 수직적 레이어에 의해 지원을 받는다.
- Enterprise Service Bus (ESB)로 일컬어 지는 인프라스트럭처 레이어.
- 비스의 품질을 보장하고 비 기능적 요구 사항들을 실현하는 모니터링 및 관리 레이어.
- 데이터 아키텍처 레이어.
- 거버넌스 레이어.
요약
이 글에서는 SOA와 EA의 정의와 범위를 설명하고 이 둘을 비교해 보았다. Part 2와 3에서는 SOA와 EA간 유사성과 차이점을 규명할 것이며, 프로젝트를 통한 실전 경험에서 얻은 방식으로 이러한 문제들을 해결하는 방법을 설명하겠다.
감사의 말
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 조직, 스태핑, 예산 산정 분야에도 관리 책임을 맡고 있다. 보건, 금융 서비스, 교육, 유통, 보험, 유틸리티, 제조, 정부 분야에서도 다양한 경험을 쌓았다. |
기사에 대한 평가
| |
