What is SOA? How to SOA?

컴퓨터 시스템이 사용되면서부터, 각 시대의 기업 전략에 맞는 소프트웨어 아키텍쳐 존재하여 왔다. 초기 시대의 메인프레임에서는 기업의 업무를 전산화 하는데 목적이 맞춰졌고, 소프트웨어는 구조적 프로그래밍 (Structured Programming)으로 개발되었다. 그 후 개인 PC가 도입되면서 클라이언트 서버 시대 아키텍쳐가 도입되었고, 근래의 인터넷과 e비지니스 시대에서는EJB나 COM을 기반으로하는 컴포넌트 기반의 개발이 중심이 되었다. 그리고 지금의 IT 시스템들은 비즈니스의 급격한 변화를 수용할 수 있는 민첩성이 요구 되게 되었고, 이 요구를 충족시키기 위한 아키텍쳐가 서비스 지향 아키텍쳐 SOA 이다.  이번 강좌에서는 SOA가 무엇이고 어떻게 SOA를 진행할지에 대해서 간략히 살펴보도록 한다.

 

1.    SOA의 기본 개념

SOA란, 기존의 애플리케이션들의 기능들을 비즈니스적인 의미를 가지는 기능 단위로 묶어서 표준화된 호출 인터페이스를 통해서 서비스라는 소프트웨어 컴포넌트 단위로 재 조합한후, 이 서비스들을 서로 조합(Orchestration)하여 업무 기능을 구현한 애플리케이션을 만들어내는 소프트웨어 아키텍쳐이다.

 또한 기존의 시스템이 각각의 독립된 업무 시스템으로 개발되어왔던 반면 SOA는 기업의 전체 업무가 하나의 거대한 SOA시스템으로 구성이 된다.

 

이해를 돕기 위해 예를 들어보자, 자바 기술 기반으로 개발된 “고객 정보 시스템”과, 룰 엔진으로 구현된 “룰 엔진”, 메인프레임을 구현된 “계좌이체” 업무 등이 있다고 가정하자.

이 각각의 업무들은 각각의 목적에 따라서 따로 개발된것이고, 서로 연계가 불가능했다.

이 각각의 시스템의 기능들을 업무를 기준으로 주요 기능들로 묶어서 플랫폼에 독립적인 인터페이스 (예를 들어 XML/HTTP, CORBA,SOAP)를 구현하여 외부로 서비스를 제공한다.

<그림 1 SOA의 개념 >

이렇게 제공된 서비스 인터페이스를 이용하여 “신용 대출” 이라는 새로운 업무를 구현할 때 새롭게 시스템을 신규 개발하는것등이 아니라 기존의 이미 제공되어 있는 서비스들을 조합하여, 하나의 업무를 구현할 수 있다. 이것이 SOA의 기본적인 개념이다.

 

SOA 자체는 새로운 개념은 아니다. 소프트웨어 개발에 있어서 계속해서 이야기 되어 왔던 “소프트웨어의 재사용성”과 “레고웨어 [주. 소프트웨어 모듈을 레고블럭처럼 재 사용성이 높은 단위로 구성한후, 애플리케이션을 마치 레고 블록을 조립해서 하나의 조립물을 만들듯이 제작하는 개념]” 의 연장성에 있는 것이다.

 

이런 SOA 개념과 구현된 프로젝트는 이미 1990년대부터 구현되어 왔고 존재되어 왔다. 그럼 지금에 와서야 SOA가 주목 받는 이유는 무었인가? 예전에 서비스 구축을 위한 표준 인터페이스에 대한 방안으로 제시되었던 CORBA등의 기술의 난이도가 높은 점이 문제가 되어 왔으나 현재에는 XML/HTTP나 SOAP 기반의 웹서비스 기술등의 등장으로 서비스의 구현의 기술 난이도 문제가 해결되었고,

e비즈니스 환경에서 기존 업무 환경을 전산화 하는데에만 목적이 맞춰져 있어서 각각의 업무별로 독립된 시스템의 형태로 개발이 되어, 이에 대한 통합이 필요하게 되었으며 [예를 들면 고객 정보를 매출 내용과 연계하여 판매 전략을 수립하는 경우 등] 급격한 비즈니스 환경의 변화에 따라 비즈니스의 요구를 민첩하게 IT시스템에 반영되어야할 필요성이 대두됨에 따라 이에 대한 대안으로 SOA가 대두 되었다.

 

앞에서도 설명하였지만 SOA는 크게 “서비스와 이를 조합하여 애플리케이션을 구성하는 것” 으로 구성된다. 지금부터 각 “서비스”와 “서비스를 구성하는 방법” 에 대해서 알아보도록 하자

 

2.    서비스란?

서비스란 “플랫폼에 종속되지 않는 표준 인터페이스(CORBA나 웹서비스) 를 통해서 기업의 업무를 표현한 Loosely coupled하고 상호 조합 가능한 소프트웨어 이다.”

현대의 SOA에서 서비스의 플랫폼 종속성은 SOAP기반의 웹서비스 또는 XML을 통해서 구현된다. 서비스를 표현하는데 있어서 가장 중요한 특징은 “기업의 업무를 표현한다”는 것이다. 즉 ‘임직원 정보 서비스’,’계좌 이체 서비스’와 같이 기업의 업무는 서비스로 정의할 수 있지만  ‘JNDI Lookup’, ‘SMTP 이메일 클라이언트’와 같은 비업무성 서비스는 존재할 수 없다.

 

(１) 서비스의 구성

서비스는 크게 3가지 요소로 구성된다.

 - 서비스 인터페이스

 - 서비스 규약

 - 서비스의 구현체

< 그림 2서비스의 구조 >

서비스 인터페이스는 서비스내의 하나의 업무 기능을 이야기 한다.

즉 주문서비스라는 서비스가 있을 때, 이 서비스는 “상품 주문” 과 “주문 내용 조회”라는 인터페이스를 가진다. (EJB나 자바 오브젝트의 비즈니스 메서드를 생각하면 되지 않을까?)

그리고 이 서비스를 사용하기 위한 여러가지 규약들 데이터 포맷이나 변수형 서비스를 호출하기 위한 인자나 인터페이스 이름등이 정의되는 곳이 서비스 Contract이다.

이에 대한 실제 구현체가 Implementation다.

현대의 SOA에서는 대부분이 웹서비스를 표준 인터페이스로 사용하기 때문에 서비스 Contract는 WSDL로 정의된다.

 

(２)서비스의 특징

서비스는 몇가지 특성을 가지고 있는데, 그중 몇 가지 중요한 특성을 뽑아보면 다음과 같다.

Ÿ          수직적 분할 (Vertical Slicing)

수직적 분할이란 애플리케이션을 개발할 때 전체 애플리케이션을 여러 개의 서비스로 나누고 각각의 서비스를 독립적으로 개발하는 것을 이야기 한다.

이전의 소프트웨어 개발은 애플리케이션을 각 Data Layer, Business Logic,View Layer와 같이 수평적으로 분리하였다. 그러나 SOA에서는 각각의 서비스가 Data Layer,Business Logic,View에 대한 모듈을 모두 가지고 있고 그래서 각 서비스간의 의존성이 최소화 된다.

<그림 3 Vertical slicing의 개념 >

Ÿ          Has standard interface

서비스가 제공하는 인터페이스는 표준 기술로 구현이 되어야 한다. 서비스를 사용하고자 하는 사람이 “서비스 규약”만을 가지고도 해당 서비스를 호출할 수 있어야 하며, 이는 해당 SOA시스템 내에서 플랫폼이나 기술에 종속되지 않아야 한다.

Ÿ          Loosely Coupled

Vertical Slicing에서도 설명하였듯이 각 서비스 컴포넌트들은 다른 서비스에 대해서 의존성이 최소화 되어 있어서 서비스의 구현내용등을 변경하였을 때 다른 서비스가 이에 의해서 영향을 거의 받지 않는다.

Ÿ          Composable

서비스 컴포넌트들은 서로 연결되어 조합된 형태의 하나의 애플리케이션을 구성해야 하기 때문에, 서비스간에 연결 및 조합이 가능해야 한다.

Ÿ          Coarse grainned

서비스의 구성단위나 인테페이스의 단위는 업무 단위를 기본으로 한다. IT 개발 조직이 아니라 현업의 비즈니스 조직이라도 해당 서비스가 무엇이고 무슨 기능을 하는지 이해할 수 있어야 한다.

Ÿ          Dicoverable

서비스에 대한 정보가 검색 가능해야 한다. SOA시스템의 규모가 증가함에 따라 서비스의 중복이 발생할 수 있고, 이를 방지하기 위해서 이미 구현된 서비스가 있는지를 검색할 수 있어야 하며, 검색 내용에는 서비스의 내용과 서비스에 대한 사용방법,권한,보안에 대한 정보들이 포함되어야 한다.

 

(３) 서비스의 종류

서비스를 그 기능에 따라서 5가지 정도로 나눠볼 수 있다.

일반적으로 우리가 지금까지 이야기 했던 서비스는 “비즈니스 서비스” 이다.

이 비즈니스 서비스는 말 그대로 비즈니스 적인 의미를 가지는 서비스로 SOA의 최소 단위가 되며, 비즈니스 로직을 구현한 “Task centric service”와 비즈니스 데이터를 대표하는 “Data centric service”로 분리된다. [주. EJB의 Session Bean과 Entity Bean 정도로 생각하면 된다.]

 

다음은 “Intermediary 서비스” 인데, 업무적인 기능을 가지는 것이 아니라 서비스들을 연결하는 데서 발생하는 차이점을 보안해주는 서비스 이다.

몇가지 예를 들어보자

기존의 백화점의 구매 프로세스가 존재하였다고 가정하자. 백화점의 업무 요건이 바뀌어서 일반고객과 VIP고객에 대한 구매 프로세스를 차별화 하였을 때, 고객의 요건에 따라 구매 프로세스를 서로 다르게 호출해야 한다. 이런 유형을 Routing 서비스라고 한다.

서비스에 들어오는 데이터 타입이 “구매자의 이름,구매액과 물품 목록” 이었는데, 서비스가 수정되면서 데이터 타입이 변화가 되었을 때 기존에 이 서비스를 호출하던 모든 서비스 소비자는 데이터 타입의 변경으로 모두 변경이 되어야 하며 이런 이유로 업무 변화에 유연하게 대처를 하지 못하는데, 이런 경우 구 데이터 타입을 새로운 데이터 타입으로 변화시켜주는 서비스가 있으면 유연하게 변화에 대처할 수 있다. 이런 형태의 서비스를 Transform 서비스라고 한다.

<그림 4 Routing 서비스 >

< 그림 5 Transform 서비스>

그 외에도 기존 서비스에 새로운 기능을 추가하는 Functional Adding서비스, Façade 기능을 구현한 서비스등을 그 예로 들 수 있다.

 “Process centric 서비스” 는 비즈니스 서비스들을 조합하여 하나의 업무 프로세스를 구현해내는 서비스로, 주로 상태가 있는 (Stateful)를 구현하는데 이용이 된다.

 “Application 서비스”는 Technical한 서비스 “트렌젝션 서비스”, “로깅 서비스”가 예가 된다. 지금까지 설명하면서 “서비스는 비즈니스적인 의미를 가진 컴포넌트 이며 트렌젝션 등은 서비스가 될 수 없다..” 라고 이야기를 했지만, 현실세계에서 이런 서비스가 나오지 않을 수 있는 보장이 있을까? 언제나 예외는 존재한다고 SOA에서 지극히 예외적인 서비스이다. 잘 설계된 SOA에서는 “Application 서비스”가 존재하지 않는다.

 “Public enterprise 서비스”는 다른 회사나 다른 SOA시스템으로 제공되는 서비스이다. [은행의 대외계 업무 정도가 이에 해당한다.] 다른 서비스에 비해서 외부로 제공되는 서비스인 만큼 성능, 트렌젝션, 보안에 대한 깊은 고려가 필요하다. 

3.    SOA 아키텍쳐 모델

지금까지 “서비스가 무엇인가?” 에 대해서 알아보았다. 지금부터는 이 서비스들을 어떻게 조합하여 소프트웨어 시스템을 구성하는지, 구성 방법에 대해서 알아보도록 하자.

서비스의 구성 방법의 기업의 SOA 성숙도와 발전 정도에 따라 단계적으로 적용되어야 한다.

단계적인 발전 모델을 설명하기에 앞서서 “application frontend”에 대해서 설명하면, 서비스들이 사용되어 최종 사용자에게 보이는 곳이 application front end이다. 일반적인 웹사이트나 기업 포탈, X 인터넷 클라이언트, 4GL 클라이언트등이 될 수 있다. 

(１)Fundamental SOA [통합]

가장 기본적인 형태의 SOA로, 비즈니스 서비스와 애플리케이션 서비스만 존재하며 이 서비스들의 조합들은 application front end에서 이루어 진다.

Fundamental SOA의 가장 큰 목적은 기존의 시스템을 각각 서비스화하는 것과 독립되었던 시스템들을 통합하여 하나의 시스템으로 운영한다는데 목적이 있다. 

(２)Networked SOA [ 유연성과 통제 추가 ]

서비스화하여 통합된 SOA시스템은 시간이 갈 수 록 그 크기가 커지게 되고 서비스간의 호출은 관계는 날이 갈 수 록 복잡해진다. 그리고 서비스의 내용이 변경 또는 보강 되어 가면서 의존성에 의해서 서비스간에 수정이 필요한 경우가 발생한다. 이는 서비스의 변화를 어렵게 만들고 결과적으로 기업 업무에 대한 ‘경직성’ 을 유발하는데, 이를 해결하기 위해서 모든 서비스들을 중앙에 하나의 버스를 통해서 관리하여 서비스간 연결의 복잡도를 해소하고 Intermediary 서비스를 추가 함으로써, 서비스의 내용이 변경되었을 때 그 차이를 보강해줄 수 있어야 한다.

 

<그림 6 Networked SOA 개념 >

이렇게 중앙에 버스 역할을 하는 것이 Enterprise Service Bus (ESB)이고, 여기에는 서비스에 대한 모니터링과, Intermediary 서비스 기능의 제공, 위치에 대한 투명성 제공을 통해서 기본적인 “통제”와 “유연성” 제공을 특징을 한다. 

(３) Process Oriented SOA [ 민첩성의 추가 ]

기업의 업무프로세스가 자주 변화가 되고, IT 시스템이 이에 민첩하게 반응해야 하거나, SOA로 구현해야 하는 기업 업무들에 복잡한 업무 플로우가 존재할 경우 이 업무 프로세스들을 BPM기반으로 구현하는 SOA를 고려해볼 수 있다.

 각 서비스를 조합하는 것을 BPM으로 구현함으로써, 업무의 조합이 별도의 코딩 없이 BPM툴로 이루어 지게 되고, 업무프로세스가 바뀌었을 때 BPM툴에서 업무프로세스를 조정하는 것만으로도 빠르게 비즈니스 조직의 요구에 대응하여 IT 시스템이 비즈니스 업무에 대한 민첩한 대응력을 확보할 수 있다.

 또한 업무 조직과 기술 조직간의 의사 소통에 있어서도, 기존에는 업무조직은 EJB나 JAVA와 같은 기술적인 내용을 이해하지 못하였고, 기술 조직의 경우 업무에 대한 이해도가 낮았기 때문에 의사소통에 있어서 많은 문제를 유발하였는데, BPM을 도입할 경우, 이 BPM에서 사용되는 모든 서비스는 이미 “업무적인 의미를 가지는 컴포넌트”이기 때문에 IT조직과 업무 조직간에 의사 소통을 하는데 문제가 없으며, 특히 업무 프로세스의 경우 직접 업무 조직이 큰 흐름을 정의하고 IT조직이 구현화에 있어서 보강만 함으로써 빠르고 정확한 의사 소통을 이룰 수 있다.

 BPM과 함께 생각할 수 있는 것이 BPA(Business Process Analysis) 와 BAM(Business Activity Monitoring) 이다. BPA는 실제 업무플로우를 BPM으로 구현하기 전에 업무팀에서 해당 업무 플로우에 대한 설계를 하고 이에 대한 시뮬레이션을 할 수 있는 Business Process 분석 설계 도구이다.

BPA를 통해서 현 업무팀에서 해당 업무프로세스를 정의하고, 작동 내용을 시뮬레이션 함으로써 보다 완성된 업무 프로세스를 얻을 수 있으며, 이렇게 설계된 업무는 IT 개발팀에 의해서 BPM으로 변환이 된다.

BPM으로 변환된 업무는 SOA 시스템에 반영되어 실제 운영이 되게 되고,

BAM이라는 비즈니스 프로세스 모니터링 도구를 이용하여 반영된 BPM에 대한 평가가 이루어진다. 이 평가를 기반으로 업무팀에서는 다시 BPA를 이용하여 해당 업무의 최적화를 수행하고 다시 이는 BPM으로 구현이되고.. 이러한 반복을 통해서 업무의 개선과 SOA시스템이 최적화를 이룰 수 있다.

<그림 7. BPA,BPM,BAM을 통한 업무 프로세스의 구현과 업무의 최적화 >

4.    SOA 아키텍쳐 모델의 구현

앞에서 설명한 3단계 아키텍쳐를 실제로 구축하는데 있어서 고려할 사항이 있다. 

(１) 서비스화

먼저 Fundamental SOA에서 가장 중요한 것은 기존의 시스템을 “서비스화” 시키는 것이다. 현재의 서비스 인터페이스는 대부분 SOAP 기반의 웹서비스를 사용하는데, 솔루션 중에는 이미 Legacy System에 대해서 웹서비스를 제공하는 “서비스 아답터”가 제공된다. (IWay社의 SAP, Siebel 아답터, BEA의 Tuxedo 웹서비스 아답터 SALT etc)

대부분의 서비스 아답터를 통해서 서비스화된 “기존 메서드”들은 비즈니스 적인 의미를 가지지 않는 Application 서비스가 될 가능성이 많다. 서비스화를 하기전에 기존 시스템에 기능등을 업무 단위의 Coarse grainned된 컴포넌트로 묶은후에 서비스화 하는 것이 좋다.

 

(２) 스펙과 범위

고려 사항중 하나가 트렌젝션이나 Reliable 메세징과 같은 웹서비스 스펙에 해당하는 문제이다. 현재 웹서비스의 확장 규약인 WS* (Webservice Extenstion)의 경우에는 트렌젝션이나 Reliable Messaging과 같은 기능들을 제공하고 있지만 문제는 서비스화를 시켜주는 솔루션에는 이에 대한 지원이 의무사항이 아니라는 것이다. 즉 트렌젝션 기능들을 웹서비스에서 지원하는 기능을 사용하려고 했다가 막상 해당 시스템의 웹서비스에서 트렌젝션 기능들을 지원하지 않아서 문제가 될 수 있다. 서비스를 정의할 때 어떻게 이런 기능들을 구현할지에 대한 고려가 앞서야 한다.

 이런 서비스 구현에 있어서 유용하게 사용할 수 있는 것이 EAI이다. EAI는 시스템간의 통합을 목적으로 하는 솔루션으로, SOA는 다르게 Tightly Coupled 되고 비즈니스적인 통합이 아니라 IT 시스템간의 통합을 지원함으로써,  SOA 통합에서 다루기 힘든 트렌젝션이나 보안에 대한 내용을 해결해준다.

[이 EAI 솔루션에도 IT 시스템간의 연계 흐름을 정의 하기 위해서 BPM이 사용되는데, 시스템간의 흐름과 업무 흐름을 분리하기 위해서 이를 각각 IC-BPM가 HC-BPM으로 구분하여 부른다.]

 

(３) 보안

보안에 대해서는 따로 길게 설명하지 않겠다. 암호화 선택할때는 전체 메시지를 암호화할지 메시지 내용중 일부만 암호화 할지가 결정해야 하며, 중앙에서 각 서비스에 대한 사용 권한과 계정에 대한 관리를 할 수 있는 솔루션을 구성할 필요가 있다.

 

(４) 모니터링

여러 시스템을 하나의 SOA 시스템에 구축한 만큼 각각의 서비스에 대한 모니터링과 성능 측정은 매우 중요한 요소로 작용한다. SOA 시스템을 구축할 때 미리 로깅과 모니터링 성능 측정에 대한 기능을 미리 구현할 필요가 있다.

 

(５) 서비스 검색

SOA 시스템에서 이미 개발된 서비스를 재사용하기 위해서 서비스를 검색할 수 있어야 하며, 서비스에 대한 메타 정보 (보안,과금체계 등에 대한 규약등)들도 검색할 수 있어야 한다. 웹서비스에서는 이를 UDDI로 구현한다.

 

(６) Application frontend

Application frontend는 최종 사용자에게 업무 기능을 제공하는 부분으로, 일반적인 웹 인터페이스를 이용할 수 도 있으며, Rich client의 개념을 웹에 도입한 AJAX 기반이나 Flex와  같은 X-Internet 솔루션을 사용할 수 도 있다.

단 SOA 시스템은 여러 시스템을 통합한것으로 여러 메뉴와 UI가 통합 되기 때문에 권한과 메뉴등에 대한 관리 기능이 필요하게 되며, 이는 Enterprise Portal (EP)솔루션등을 이용해서 쉽게 구현할 수 있다. 지금까지 설명한 SOA 아키텍쳐 구성을 하나의 그림으로 표현해보면 다음과 같다.

 

<그림 8 SOA 레퍼런스 아키텍쳐 >

지금까지 SOA가 무엇인지, 그를 구성하는 서비스의 개념과 서비스를 조합하여 SOA시스템을 구축하는 방법에 대해서 알아보았다.

그렇다면 실제로 SOA 프로젝트를 수행하는데 있어서 어떻게 SOA 시스템을 구축하며 프로젝트를 진행해야 할까? 아래부터는 SOA의 수행 방법론에 대해서 알아보도록 하자.

 

5.    SOA 수행 방법론

SOA 시스템은 기존의 시스템과는 다르게 기업에 업무별로 개개별 시스템이 존재하는 것이 아니라, 이러한 개개별 시스템을 통합하여 하나의 거대한 IT 운영 플랫폼을 구축하는데 있다. 이에 따라 SOA 시스템을 수행 하는 방법도 역시 차이가 나는데, 기업의 전략, 비용의 집행방법, 팀의 통제, 프로젝트 관리 방법을 기준으로 하나씩 알아보도록 하자

 

(１) 기업의 전략

IT 시스템은 기본적으로 기업 업무에 대한 반영이다. 그래서 SOA시스템을 통해서 제공하고자 하는 기능은 기업의 전략에서부터 파생된다.예를 들어 기업 경영 전략이

2004년 매출 증대

2005년 고객 만족 실현

2006년 브랜드 이미지 관리

와 같다면, 이를 지원하기 위해서 IT시스템의 구현 전략을 다음과 같은 것들이 될 수 있다.

2004년 매출 내용 전산화

2005년 CRM 도입을 통한 고객 정보 수집과 매출 내용을 기반으로 고객 패턴 추출

2006년 수집된 고객 정보를 토대로 마케팅 집중

즉 SOA의 수행은 기업의 경영 전략에 따라서 수행되며, 성공적인 SOA를 위해서는 해당 단계에서 기업의 핵심 업무를 SOA화 하는 것이 필요하다.

또한 기업의 IT전략은 예전처럼 각각의 단위 시스템을 개발하는 것이 아니라 기업의 전략을 IT화하여 구현한 SOA시스템을 기업의 발전에 따라서 계속 반영 및 변화 시켜나가기 때문에 기존 IT전략에 비해서 좀더 장기적인 전략을 필요로 한다.

(２) 비용의 집행

SOA 시스템은 비용 집행에 대한 고려가 필요하다. 기존 IT시스템은 단위 시스템에 대한 개발 프로젝트에 소요되는 비용만 예상하여 집행하면 되었지만, SOA 계속해서 발전해 나가는 시스템이고 한 시스템에 기능이 추가 되기 때문에 비용 집행 방식이 다르다.

 SOA 시스템의 경우 초기에 SOA에 필요한 인프라의 구축 (ESB,BPM,모니터링,보안 인증,UDDI 등)에 비용이 많이 소요되기 때문에 초기 투자 비용이 기존의 IT 시스템 보다는 높아진다.

< 그림 9 SOA의 비용 집행 방법 >

그러나 위의 그림에서와 같이 계속해서 업무를 추가해나감에 따라 새로운 업무가 완전히 새롭게 구성이 되는 것이 아니라 앞단계에서 개발하였던 서비스들을 다시 재 사용되기 때문에 개발 비용은 지속적으로 감소하게 되고, 기능이 부족한 서비스들은 계속해서 대체 되면서 안정적으로 유지 되기 때문에 시간이 갈 수 록 소요 비용은 감소하게 된다.

 

(３) 제어와 통제

SOA 시스템이 거대화해짐에 따라 SOA 시스템에 대한 중앙 관리 및 통제 제어가 필요하게 된다. 어느 서비스부터 개발해야 할것인지, 이번 기간내에 진행해야할 SOA범위, 각 개발에 대한 표준화, 자금 조달 계획등을 수행해야 하며 이를 통제하는 조직이 필요하다. 이러한 통제를 Goverance라고 하는데,

이 통제를 실시하는 Governace 조직에서 하는 일은 다음과 같다.

-         SOA 시스템에 대한 정책 수립 및 표준화 - Standard

-         SOA 관련 기술 전파 및 가이드 - Evangelist

-         SOA 구축 계획 수립 및 실행 (로드맵)- Strategy

-         자금 조달 및 집행 계획

-         업무 분석 및 설계

-         문화 변화  IT조직과 비즈니스 협업 조직의 협업문화 개발

-         모범사례 수집과 배포

여기에는 여러가지 통제 모델을 도입할 수 있는데, 운영 환경상에 서비스의 개발 배포 모니터링을 위한 통제 모델이다.

 

<그림 10 SOA 제어 통제 모델 예시 >

중앙 통제 조직은 실 개발 조직인 IT 조직과 비즈니스 조직간의 중계 역할을 하게 되며, 비즈니스 조직으로부터 전략과 요구 사항을 받아 실제 구현 조직에 전달을 하며

각 개발 조직에서 개발된 내용들에 대한 검증 및 배포 작업과 SOA 플랫폼에 대한 운영 및 모니터링 통제를 실시 한다.

 이외에도 CVS등을 이용한 소스의 통제, apache maven과 같은 도구를 이용한 빌드의 관리, 일일 빌드 정책, 개발 방법론등도 이 “제어와 통제”에 해당한다. 

(４) 프로젝트 관리

SOA의 프로젝트 진행에 있어서 특이한 점은 “반복적인 개발(Iterative Development)”과 “점진적인 개발(Incremental Development)”이다. 한번에 SOA 전체 시스템을 개발하는 것이 아니라 중요 업무를 먼저 개발한후에 반복적으로 업무에 대한 개선 작업을 병행하고, 점차적을 필요한 기능을 추가해나가는 모델이다.

 또한 SOA의 프로젝트 개발 관리는 앞에서 설명 했던 Thin Thread Model의 개발 방식을 준수 하면 좀 더 좋은 효과를 볼 수 있다. 

6.    결론

지금까지 SOA가 무엇인지, SOA를 구성하는 서비스의 형태와 특징은 어떠한지 그리고 SOA 프로젝트를 수행하는 몇가지 권고 방안에 대해서 살펴보았다.

 SOA는 ESB나 BPM같은 솔루션을 제외하고라도 이미 서비스의 개념과 서비스 인터페이스의 개념을 도입하여 개발되는 사례가 많다. 특히 AJAX와 X 인터넷의 등장으로 SOA 기반의 시스템 도입은 가속화 되어갈 전망이다.

 여기서 중요한점은 SOA의 개념이 무엇인지를 명확하게 이해하고, 현재 기업에서 필요한 SOA의 단계를 파악하여 적절한 수준의 SOA를 도입하고, 이 SOA 시스템을 장기적으로 발전 시켜나갈 수 있는 장기적인 전략과 이를 수행할 수 있는 제어와 통제 모델 (Governance)를 구축하는 것이 중요하다.