CraigJin님의 주절주절

3.1 아키텍쳐 뷰(architecture view)

SOA 기반의 레퍼런스 아키텍처(SOA-based Reference Architecture)는 다음과 같이 크게 3개의 아키텍처로 구성된다.

● 애플리케이션 아키텍쳐(application architecture)
하나 이상의 여러 서비스 공급자(service provider)가 제공하는 서비스를 사용하여 비즈니스가 직면해 있는 문제에 대하여 솔루션을 구성한다.
● 서비스 아키텍처(service architecture)
비즈니스의 핵심 기능을 표현하는 비즈니스 서비스 집합의 논리적인 관점을 제공하며, 서비스 구현과 소비자 애플리케이션 사이를 연결하는 역할을 한다.
● 컴포넌트 아키텍처(component architecture)
구현된 애플리케이션, 비즈니스 객체 및 구현 등을 지원하는 다양한 환경을 표현한다.

3.2 서비스 아키텍처(service architecture)
SOA기반 레퍼런스 아키텍처의 중심에는 서비스 아키텍처(service architecture)가 있다. 서비스 아키텍처는 공유비즈니스 서비스의 공급자 관점에서 비즈니스의 핵심 기능을 표현하는 비즈니스 서비스 집합의 논리적인 관점을 제공하며, 비즈니스프로세스 레이어 (business process layer)와 비즈니스 서비스 레이어(business servicelayer), 그리고 이들 서비스 레이어에 기반구조(infras-tructure)를 제공하는 인프라 서비스(infraservice) 등 3개의 레이어로 구분된다.

비즈니스 프로세스 레이어 (business process layer)는 비즈니스 프로세스 로직에 다라 비즈니스 서비스를통합하는 서비스를 제공한다. 따라서 비즈니스 프로세스 레이어에는 프로세스 서비스(process-centric service)가놓이게 된다.

비즈니스 서비스의 통합구성에는 두 가지 접근 방법이 있다. 하나는 오케스트레이션(orchestration)이고, 다른하나는 코리오그라피(choreography)이다. 이들 두 개념은 비즈니스 서비스의 통합이라는 면에서 어느 정도 중첩된다.그러나 오케스트레이션은 비즈니스 프로세스 관점에서 비즈니스 서비스를 통합하지만, 코리오그라피는 비즈니스 협업(businesscollaboration)이란 관점에서 비즈니스 서비스를 통합한다는 점에서 다르다.

오케스트레이션은 주로 기존의 비즈니스 서비스를 재사용하는 복합 서비스(composite service) 또는 프로세스서비스(process service)를 정의하기 위해서 사용한다. 이에 대하여 코리오그라피는 여러 참여자가 보다 큰 비즈니스트랜잭션(business transaction)의 일부로서 거래 파트너끼리 메시지를 교환함으로써 피어-투-피어(peerto-peer) 방식으로 협업하는 방식을 정의하기 위해 사용된다.

오케스트레이션과 코리오그라피 사이의 커다란 차이점은 오케스트레이션이 비즈니스 프로세스를 주도하는 하나의 참여자 관점에서여러 비즈니스를 통합하는 계층적인 요청자/공급자(hierarchical requester/provider) 모델을 사용하는반면에, 코리오그라피는 비즈니스 프로세스 안에서 다수의 참여자가 피어-투-피어(peer-to-peer) 방식으로 협업하는 모델을사용한다는 것이다. 따라서 기업 내부 프로세스 통합을 위해서는 오케스트레이션을 사용하고, 기업사이의 프로세스 통합에는코리오그라피를 사용하는 것이 바람직하다.

비즈니스 서비스 레이어(business service layer)는 비즈니스의 핵심 기능을 표현하는 비즈니스 서비스를제공한다. 따라서 비즈니스 서비스 레이어에는 기본 서비스(basic service)와 공개 서비스(publicenterprise service), 그리고 중개 서비스(intermeriary service)가 놓인다. 비즈니스 서비스레이어의 서비스들은 스스로 비즈니스 로직을 구현함으로써 서비스를 제공하기도 하지만, 주로 컴포넌트 아키텍처(componentarchitecture)에 컴포넌트로 구현되어 있는 서비스 구현과 소비자 애플리케이션 사이를 연결하는 역할을 한다. 또한, 중개서비스를 통해서 메인 프레임이나 ERP(enterprise resource planning) 등 기존의 IT 리소스에 접근하여게이트웨이나 어댑터, 또는 퍼

사드 등의 역할을 수행함으로써 레거시 시스템을 재사용할 수 있게 한다.

인프라 서비스(infra service)는 이들 레이어의 서비스들의 배포를 위한 공통적인 기반을 제공하며, 여기에는 위치독립성(location independence), 실패 복구(fail over), 서비스 및 프로세스 관리, 그리고 기타QoS(quality of service) 특성들을 제공하기 위한 서비스들이 포함된다.

공통 서비스(common service)에는 로깅(logging), 감사(auditing), 보안(security),에러처리(error handling)와 같이 모든 서비스에 필요한 핵심 기능이 제공된다. 서비스 버스(service bus)는일반적인 미들웨어 솔루션에서의 전통적인 메시지 브로커(message broker) 또는 소프트웨어 버스(softwarebus)와 같은 방식으로 라우팅(routing)과 변형(transformation) 서비스를 제공하며,ESB(enterprise service bus)

개념을 활용할 수 있다. 서비스 관리(service management)에는 비즈니스 서비스와 비즈니스 프로세스를 관리하고모니터링하는 기능이 제공되며, 여기에는 비즈니스 서비스 레파지토리(repository) BPM(business processmanagement), BAM(business activity monitoring) 등이 포함된다. 이들 인프라 서비스는 많은기업에 있어서 새로운 개념이 되겠지만, 서비스 지향 엔터프라이즈(service-oriented enterprise)를 성공적으로구축하기 위한 핵심이 된다.

3.3 애플리케이션 아키텍처(application architecture)

애플리케이션 아키텍처(application architecture)는 서비스 아키텍처의 소비자 관점에서 정의되는 개별애플리케이션의 솔루션을 표현한다. 일반적으로 애플리케이션 아키텍처에서는 서비스 아키텍처에서 제공하는 공유 비즈니스 서비스를사용하여 비즈니스가 직면해 있는 문제에 대하여 솔루션을 구성하게 된다. 그러나 공유 비즈니스 서비스가 제공하지 않는 솔루션에대해서는 애플리케이션 아키텍처 자체에서 개별적으로 구현할 수 있으며, 자체 구현을 위한 데이터의 정보를 별도의 데이터베이스를통해 관리할 수 있다.

3.4 컴포넌트 아키텍처(component architecture)
컴포넌트 아키텍처(component architecture)는 서비스 아키텍처의 구현 관점에서 공유 비즈니스 서비스의 구현 기능을제공한다. 컴포넌트 아키텍처 도입의 가장 큰 이점은 기존의 IT 리소스를 재사용할 수 있게 한다는 사실이다. 이전까지 주류를이루던 CBD(component-based development) 환경에서 구현되었던 비즈니스 서비스의 구현 세부사항을애플리케이션 아키텍처에게 감춤으로써, 애플리케이션 아키텍처에 독립적으로 컴포넌트 아키텍처를 자유롭게 변경 및 구성할 수 있게된다.

[출처: 06/04/29 MSDN 세미나 - 전병선]

2.2 비즈니스 서비스와 웹 서비스
SOA에서 비즈니스 서비스(business service)는 비즈니스 프로세스(business process)와 비즈니스로직(business logic), 그리고 비즈니스 실체(business entity) 등을 캡슐화하는 가장 기본적인 빌딩블록(building block)이다.

비즈니스 서비스의 가장 큰 특징은 자치적(autonomous)이라는 것이다. 여기에서 자치적이란 각각의 비즈니스 서비스가 다른 비즈니스 서비스에 의존하지 않고도 독립적으로 해당 로직을 제어할 수있으며, 또한 해당 로직을 제어하는데 필요한 정보를 스스로 포함하고 있다는 것을 말한다. 그렇다고 해서 비즈니서 서비스가 완전히독립적으로 실행되는 것만은 아니다. 비즈니스 서비스는 서비스 합성(service composition)에 멤버로서 참여하는 구성요소가 될 수도 있기 때문이다.

비즈니스 서비스 특징 중 하나는 메시지 기반적(message-based)이라는 것이다. 비즈니스 서비스는 메시지를 통해 서로 커뮤니케이션을 한다. 메시지(message)란 하나의 서비스가 다른 서비스로전성하는 정보의 단위로서, 스키마(schema)를 사용하여 고도로 구조화되어 전송되어야 하며, 메시지를 이해하는데 필요한 모든정보를 포함하거나 참조함으로써 개념적으로 스스로 충족될 수 있어야만 한다.

이러한 두가지 비즈니스 서비스의 특징은 비즈니스 서비스가 느슨한 결합도(loosely-coupled)를 가지며, 커다란 입자성(coarse-grained)을갖는다는 것을 의미한다. 객체지향기술(object-oriented technology)의 중심 개념인 객체(object)와CBD(component-based development) 기술의 중심 개념인 컴포넌트(component)와 비교할 때, 다음그림과 같이 비즈니서 서비스가 컴포넌트보다 더 큰 입자성과 느슨한 결합도를 갖게 된다.

비즈니스 서비스의 또 다른 중요한 특징은 개방 표준(open standard)를 기반으로 한다는것이다. 여기에서 개방 표준이란 웹 서비스 표준을 말한다. 결국 웹 서비스(web service)는 비즈니스 서비스의 구현이된다. 우리는 웹 서비스를 개방형 프로토콜(HTTP,SMTP등)을 사용하여 커뮤니케이션하며, SOAP 프로토콜을 사용하여 구성된XML 메시지를 처리하며, XML 스키마를 사용하여 메시지를 기술하고, WSDL을 사용하여 서비스 인터페이스를 기술하며,UDDI를 사용하여 등록하고 검색할 수 있는 소프트웨어 컴포넌트라고 정의할 수 있다.

이제 우리는 이러한 비즈니스 서비스의 특징으로부터 다음과 같이 정의할 수 있다.
'비즈니스 서비스란 개방 표준을 따라 메시지 기반으로 서로 커뮤니케이션하는 자치적인 소프트웨어 컴포넌트이다'

이러한 비즈니스 서비스의 정의로부터 우리는 다음과 같은 기술적인 특징을 파생시킬 수 있다.
* 비동기 커뮤니케이션 지원 - 비동기적으로 커뮤니케이션을 할 수 있어야 한다.
* 커뮤니케이션 채널 독립성 - 이기종 커뮤니케이션 채널을 통해서도 커뮤니케이션을 할 수 있어야 한다.
* 플랫폼 독립성 - 서로 다른 플랫폼 상에서도 호스트될 수 있어야 한다.
* 언어 독립성 - 서로 다른 언어를 사용하여 구현될 수 있어야 한다.

2.3 비즈니스 서비스의 종류
우리는 비즈니스 서비스를 다음과 같이 4가지로 구분할 수 있다.

● 기본서비스(basic service)
● 중개서비스(intermediary service)
● 프로세스 서비스(process-centric service)
● 공개 서비스(public enterprise service)
이들 서비스 유형 사이의 특징을 요약하면 다음과 같다.

기본 서비스(basic service)는 용어 그대로 SOA의 기반이되는 서비스로서, 수직적인 도메인(vertical domain)의 기본 요소를 표현한다. 다시 기본 서비스는 데이터서비스(data centric service)와 로직 서비스(logic centric service)로 구분된다. 데이터서비스는 식별된 비즈니스 엔터티(business endtity(의 데이터 저장과 조회, 로킹 메커니즘, 트랜잭션 관리 등을담당한다. 로직 서비스는 비즈니스 로직(business logic)과 비교적 간단한 비즈니스 룰(business rule)을캡슐화한다.

중개 서비스(intermediary service)는 레거시시스템(legacy system)과 연결하는 게이트웨이(gateway) 기능이나 기존 다른 서비스의시그너쳐(signature)나 메시지 형식(message format)을 클라이언트가 요구하는 형식으로 맵핑시켜주는어댑터(adapter), 하나 이상의 기존 서비스에 대하여 통합되는 형식으로 다른 뷰를 제공하는 퍼사드(facade) 등의기능을 제공하는 서비스이다.

프로세스 서비스(process service)는 비즈니스 프로세스(business process)를 캡슐화하며, 비즈니스 프로세스 로직을 제어하고 비즈니스 프로세스의 상태(state)를 관리한다. 비교적 복잡한 비즈니스 룰도 프로세스 서비스가 담당한다.

앞에서 언급한 서비스의 유형은 대부분 특정 기업의 내부에서만 사용된다. 그러나 공개 서비스(public enterprise service)는 다른 기업이나 조직과 공유하는 서비스로서, 주로 B2B(business to business)에 사용된다.

[출처: 06/04/29 MSDN 세미나 - 전병선]

2.1 서비스 지향 아케텍쳐의 정의, 그리고 이점
이와 같이 서비스 지향 개념을 기반으로 소프트웨어 시스템을 구축하고자 하는 노력을 총칭하여 서비스 지향 아키텍쳐(service-oriented architecture, SOA)라고 한다. SOA에 대한 정의한 관점에 따라 다양하게 존재한다.

여러 SOA에 대한 정의 중에서 필자가 가장 마음에 드는 것은, Service-Oriented Architecture Compass(2006, Norbert Bieberstein 외, IBM press)의 것이다.
"서비스 지향 아키텍쳐는 비즈니스 프로세스와 그것을 지원하는 IT 기반 구조를 안전하고 표준화된 컴포넌트-서비스로 통합하기 위한 프레임워크이며, 이들 서비스는 변화하는 비즈니스 우선순위를 해결하기 위해 재사용하고 결합된다."

SOA에 대한 가장 많은 정의는 아키텍쳐와 구현 기술 관점에서 바라보는 것이다.

아키텍쳐 관점에서는 개방형 표준(open standard)을따라 자치적인 서비스(autonomous service)가 메시지 기반(message-based)으로 서로 커뮤니케이션하도록소프트웨어 시스템을 설계하는 방식을 정의하는 아키텍쳐적인 원리와 패턴을 포함하는 일종의 아키텍쳐 스타일(archirecturalstyle)로 SOA를 정의한다. 이 관점에서 SOA는 다음과 같이 서비스 공급자(service provider)와소비자(service consumer), 그리고 서비스 브로커(service broker) 등 3개의 주요 요소로 구성된다.

구현 기술 관점에서 SOA는 웹서비스(web services)와 같은표준(standard)이나 도구(tool), 기술(technology)로 완성되는 프로그래밍 모델(programmingmodel)이다. 즉, 웹서비스가 SOA의 구현이 된다.

그 이전에도 SOA의 구현은 있었다. CORBA(common object request brokerarchitecture)나 DCOM(distributed component object model), JavaRMI(remote method invocation) 등이 바로 그것이다. 그러나 이들 기술은 모두 SOA의 이상을 구현하기에는부족한 점이 많았다. 서로 다른 그룹의 사람들이 서로 다른 장소에서, 서로 다른 시간에, 서로 다른 플랫폼 상에서 애플리케이션을생성하는 경우에 이들 애플리케이션의 통합이 어렵기 때문이다. 하지만 이제 우리는 웹 서비스의 등장으로 SOA의 이상을 실현할 수 있게 되었다.

여기에서 주목할 만한 하나의 사실은 전 세계의 소프트웨어 기술을 주도하는 대부분의 벤더들이 처음으로 하나의 표준 즉, 웹 서비스에 동의했다고 하는 사실이다. 이것은 향후 기업에서 어떤 기술을 사용하여 소프트웨어 시스템을 구현하든 지금까지 변화에 대한 대응의 걸림돌로 작용하였던 상호운영성을 손쉽게 확보할 수 있다는 것을 의미한다.

그러나 보다 중요한 것은 SOA가 비즈니스 관점에서 어떤 의미를 가져다 주는 가이다.

비즈니스 관점에서 SOA는 비즈니스가 자신의클라이언트나 파트너, 또는 다른 조직에게 노출하기를 원하는 비즈니스 서비스(business service)의 집합으로 이해할 수있다. 다시 말하면 기업 내 여러 시스템에 분산되어 있는 비즈니스 서비스를 해체하여, 여러 시스템에서 공유할 수 있는 공유비즈니스 서비스(shared business service)로 통합하는 것이다.

다음 그림은 생명보험사의 영업 채널 시스템의 아키텍쳐 예를 보여준다.

대부분의 생명보험사는 여러 영업 채널을 가동한다. 그리고 이들 각 영업 채널마다 각기 독립적인시스템을 구현하고 있으며, 이들 각 영업 채널 시스템은 고객관리, 상품고나리, 청약관리, 얻더라이팅 등의 유사한 기능을 포함하고있다. 다만 각 영업 채널의 정책에 따라서 관리되는 비즈니스 로직과 데이터의 형식이 조금씩 다를 뿐이다. 이와 같은 아키텍쳐에도장점이 있다. 각 태널 시스템마다 특화되고 최적화된 기능을 제공할 수 있다는 것이다.

그러나 생명보험사 전체의 관점에서 본다면 여러가지 문제점을 노출한다. 가령 어떤 한 영업채널이 아니라 생명보험사 전체에 걸쳐 정책이 변경된다면, 각 채널 시스템을 모두 변경해야만 한다. 이것은 정책 변경에 민첩하게대응하지 못한다는 것을 의미한다. 또한 보험사 전체의 관점에서 본다면, 하나의 채널 시스템에 구현된 기능을 다른 채널 시스템에서재사용하지 못함으로써 중복하여 투자를 하게 되는 셈이다. 영업 정책이 변경되어 또 다른 영업 채널이 추가된다면 어떨까? 또하나의 영업 채널 시스템을 구축하는데 다시 많은 시간과 돈이 투자되어야만 할 것이다. 그리고 그 사이에 고객은 다른 생명보험사로옮길 수도 있고, 또 다시 영업 정책이 변경될 수도 있다.

그렇다면 어떻게 하면 변화에 민첩하게 대응할 수 있고, 이미 구현된 기능을 재사용함으로써 중복된 투자를 제거할 수 있을까? 이 질문에 대한 해답을 SOA가 제공한다. 다음 그림은 SOA를 적용한 생명보험사의 아키텍쳐를 보여준다.

앞에서 SOA란 기업 내 여러 시스템에 분산되어 있는 비즈니스 서비스를 해체하여, 여러 시스템에서 공유할 수 있는 공유 비즈니스 서비스(shared busienss service)로 통합하는 것이라고 하였다. 생명보험사의 예에서는 위의 그림과 같이 각 채널 시스템에 분산되어 있는 고객관리, 상품관리, 청약관리,언더라이팅서비스 등의 공유 비즈니스 서비스로 통합시킨다. 이제 생명보험사 전체에 걸쳐 정책이 변경될 때 통합된 공유 비즈니스서비스를 변경하기만 하면 모든 영업 채널 시스템에 신속하여 변경된 정책을 반영할 수 있게 된다. 또한 새로운 영업 채널이추가되는 경우에도 이미 구현되어 있는 공유 비즈니스 서비스를 재사용함으로써 중복된 투자없이 신속하게 새로운 영업 채널 시스템을구축할 수 있게 된다.

이와 같이 SOA를 적용함으로써 비즈니스에 단일화되고 작업 중심적인 뷰(unified, task-orientedview)를 제공할 수 있게 되고, 불투명한 블랙박스(black-box)시스템을 '비즈니스 투명성(businesstransparecy)'을 제공하는 하부 구조로 손쉽게 대체할 수 있게된다. 따라서 기업은 변화에 대하여 민첩하고 유연하고 효과적으로 대응할 수 있게 된다.

[출처: 06/04/29 MSDN 세미나 - 전병선]

1.1 변화는 변하지 않는 유일한 요소

오늘날 기업이 직면하고 있는 현실은 글로벌 경쟁과 급속한 기술 발달로 인해 경영 환경이 급변하고 있으며, 시장에서의 고객의 영향이 점차 강화되고 있을 뿐만 아니라 이들의 요구사항도 다양해지고 급속히 변화하고 있다. 변화는 변하지 않은 유일한 요소가 되고 있다.
가장 보수적이라고 할 수 있는 금융권에서도 키워드가 변화하고 있다. 변화에 대응하기 위해 지금까지 추구해왔던안정성(stability) 대신에 민첩성(agility)과 유연성(flexiblity), 그리고 효율성(effeciency)이그 자리를 차지하고 있다. 다시 말하면, 이러한 변화는 환경 속에서 기업들이 얼마나 빨리 변화를 감지하고 고객의 요구사항에얼마나 신속하고 유연하게 대응하는가가 바로 기업의 경쟁력 강화의 핵심이 된다는 것이다.

한편으로는 지난 20여년 간 기업들은 경쟁력 강화를 위해 IT분야에 대해 지속적으로 투자를 해왔다. 초기에는 부서 단위로업무 자동화를 목적으로 하는 다양한 시스템이 구축되었으나, 점차 전체 기업 차원에서 각 시스템을 통합하는 단계로 나아가고 있다.그러나 아무리 최적의 시스템이 구축되었다고 하더라도, 시스템에서 생성한 정보가 관련된 업무처리나 의사 결정에 신속하게 참여하지못한다면 그 효과는 반감되고 말 것이라는 현실적인 문제이다.

1.2 경영 관점의 변화 대응 전략
이러한 현실 인식을 바탕으로 정보 기술의 전략적 가치라는 측면에서 등장한 개념이 Real-Time Enterprise(RTE, 실시간 기업)라고 하는 개념이다. 가트너 그룹은 RTE를 '실시간 정보를 기초로 핵심 비즈니스 프로세스를 관리, 실행함에 있어서 여러 가지지체 현상을 지속적으로 제거함으로써 경쟁력을 극대화하는 경영 방법'이라고 정의한다. 다시 말하면, RTE란 기업 내/외부를포함하는 전체적인 관점에서 지속적인 프로세스의 개선 및 정보의 실시간 전달을 통해 업무 지연요소를 최소화하고 의사결정의 속도를높여 경쟁력을 극대화한 기업을 의미한다.

따라서 RTE 구현의 핵심은 비즈니스 프로세스를 어떻게 효과적으로 관리하는 가에 있으며, 이것을 BPM(Business Process Management)라고 한다. Real-Time Enterprise는 'BPM을 통해서 RTE를 실현할 수 있다'고 말한다. 간단히 말해서 BPM은 'IT 애플리케이션에서 비즈니스 프로세스를 분리'하여 관리함으로써 변화에 대해 민첩하고 유연하게 대응하고자 하는 관리 방식이다.

1.3 변화 대응 전략으로서의 현재의 IT의 문제점
이번에는 현재의 IT관점에서 살펴보기로 하자. 비즈니스 분야에서의 변화에 대한 요구는 끊임없이 진행되고 있지만, IT 분야는 이러한 비즈니스 분야에서의 변화를 수용하기 위해 필수적인 민첩성(agility)과 유연성(flexiblity), 그리고 효율성(effeciency)이 절대적으로 부족하다. 다시 말하면 비즈니스와 IT 사이의 단절이다. 이것은 IT가 비즈니스의 요구사항을 충분히 수용할 수 없다는 것을 의미한다. 일부의 사람들은 IT의 무용론까지 언급하고 있다. 왜 그럴까?

초기에 IT시스템은 비즈니스 프로세스와 데이터가 하나로 통합된 단일 애플리케이션(monolithicapplication)으로 구현되어 있었다. 사람들은 이러한 애플리케이셔니 자신이 원하는 모든 것을 다해줄 것으로 기대했지만이내 그럴 수 없다는 것을 알았다. IT 시스템이 사람처럼 상황에 따라서 즉시 변화를 감지하고 추론하고 대응할 수 없다는 것을깨달았기 때문이다. 사람들은 데이터 만이 안정적이며 신뢰할 수 있는 것이고 구조화할 수 있는 것이라고 생각했다. 따라서 단일애플리케이션으로 부터 데이터를 분리해내야만 한다고 믿었으며, 이러한 믿음은 DBMS(database managementsystem)의 출현을 가져왔다. DBMS는 데이터를 애플리케이션과 분리시키고, 데이터 공유 모델과 데이터 관리 도구를제공하였다.

그러나 이러한 데이터 중심(data-centric)의 접근 방법은 변화를 방해하는 또 하나의 부작용을 만들어냈다. 시장경쟁이 심화됨에 따라 기업 안에서 각 부서에서는 의사 결정 시에 필요한 풍부한 정보를 필요로 했으며, 그 결과로 각 부서는독자적인 애플리케이션을 개발해야만 했다. 이렇게 산발적으로 개발된 독자적인 정보 시스템은 데이터 사일로(data silo)가되었다. 기업 내의 각 부서느 유사하지만 서로 다른 형태의 데이터 구조를 필요로 하기 때문이다. 고객 정보의 경우에 영업 부서가원하는 고객 데이터 구조와 마케팅 부서가 원하는 고객 데이터 구조가 다르다면, 이들 부서는 고객 정보 관리의 유사성을 배제한 채서로 다른 독자적인 애플리케이션을 개발하여 자신들이 원하는 방식으로 고객 정보를 관리하기를 원했다. 다중 채널 영업 조직을 갖는기업의 경우 이러한 현상은 더욱 더 심화되었다. 따라서 기업의 어떤 한 고객이 다른 채널 영업 조직에서는 고객으로 인식되지못하는 문제점이 대두되었다.

또한 비즈니스 분야의 변화가 계속되면서 앞에서 살펴본 바와 같이 이러한 변화에 대응하기 위해서느 비즈니스 프로세스를 손쉽게 변경할 수 있어야 한다. 그러나 아직 비즈니스 프로세스는 애플리케이션의 코드 안에 갖혀 있으며, 또한 밀접한 결합성(tigtly-coyupled)이라는 코드의 특성으로 인해 변경이 쉽지 않는 문제점이 발생하였다.

1.4 IT관점의 변화 대응 전략 - 프로세스 중심 및 서비스 지향 세계로
따라서 IT 측면에서 기업의 변화에 대응 전략으로서 최고의 '효율성'과 탁월한 '민첩성'을 달성하기 위해서는 기술, 소프트웨어,네트워크로 인한 제약 요소들로부터 비즈니스 프로세스가 자유로워야 할 필요가 있다. 이것은 애플리케이션으로부터 데이터를 분리한것과 마찬가지로, 애플리케이션 안에 묶여있는 비즈니스 프로세스를 분리해야 한다는 것을 의미한다.
그리고 애플리케이션으로부터 데이터 분리의 결과로 DBMS가 탄생한 것과 마찬가지로, 애플리케이션으로부터 분리된 비즈니스 프로세스를관리하기 위해 BPMS(business process management system)이 탄생하게 되었다.

Business Process Management: the third wave에서는 '모든 목표들의 의존 대상은 데이터가 아닌 프로세스이며, 그것은 프로세스가 비즈니스와 정보 시스템 설계의 중심에 있어야 가능하다'고 하였으며, 결국 변화의 대응 전략으로서 프로세스 중심적인(process-centric) 방식으로의 사고의 전환을 우리에게 요구하고 있는 것이다.

앞에서 언급한 고객 관리의 예를 다시 생각해보자. 사실 고객 관리는 모든 기업에 있어서 핵심 비즈니스프로세스이므로, 기업 내의 대부분의 부서에서는 고객 관리를 필요로 한다. 따라서 각 부서에서 개발한 애플리케이션에는 필수적으로고객 관리의 기능이 내장되어 있다. 이 경우 기업은 고객에게 단일한 서비스를 제공할 수 없을 뿐만 아니라, 기업의 고객 정책이변경될 때 각 부서의 애플리케이션에 변경된 기업의 고객 정책을 일관성있게 적용하는 일이 결코 쉽지 않다.

서비스 지향 개념(service-oriented concept)은이와 같이 기업 내 여러 시스템에 분산되어 있는 비즈니스 서비스(business service)를 해체하여, 여러 시스템에서공유할 수 있는 공유 비즈니스 서비스(shared business service)로 통합하는 것을 의미한다. 이로써 기업은 변화에 대하여 민첩하고 유연하고 효과적으로 대응할 수 있을 뿐만 아니라, 앞에서 언급한 데이터 사일로의 문제점까지 해결할 수 있게 된다.

[출처: 06/04/29 MSDN 세미나 - 전병선]

- MSDN세미나에서 나눠준 파일에서 발췌하였습니다. 챕터7까지 계속 올릴 예정입니다.

[ 펌 : http://blog.naver.com/image07/60023971436 ]