현재 BPM시장에서 SOA에 대한 관심이 뜨겁다. 주지하는 바와 같이 SOA는 느슨하게 결합될 수 있고, 재활용도가 높은 컴포넌트(서비스)에 기반하여 어플리케이션을 개발하고자 하는 아키텍처 모델이다. 기업은 SOA를 통해 솔루션들간의 상호운용성을 확보하고, 개발비용을 감소시키며, 비즈니스적인 요구에 대응하는 민첩성을 확보하고자 한다.

SOA가 애플리케이션들을 서비스로 추상화시켜 제공한다면, BPM은 SOA가 제공한 서비스들을 프로세스에 맞게 정렬하여 그 흐름을 통제하는 것이라고 둘간의 관계를 정의할 수 있다. 이러한 연관성 때문에 많은 전문가들이 향후 BPM시장에서의 화두는 SOA지원이라고들 한다.

여기에는 긍정과 부정이 교차한다. SOA기반으로 구축된 어플리케이션 요소들을 BPM이 그 흐름을 통제하고 자동화해야하는 점에서는 긍정적이지만, 가트너의 정의에서처럼 "BPM은 민첩성과 운용 효율을 증대하기 위해, 비즈니스 프로세스 환경을 통제하는 일상적인 경영 활동"이라는 점과 더불어, BPM이 아키텍처 모델로서의 SOA를 뛰어넘는 다양한 경영활동 프랙티스들을 제공해야 한다는 점에서 부정적인 것이다.

이것은 SOA가 새로운 애플리케이션을 구축하기 위한 기술 아키텍처의 개념인 반면에, BPM은 프로세스 기반의 경영을 지원하는 총괄 프레임워크라는 관점에서 조명되어야 하기 때문이다.

BPM과 SOA를 융합하고자 하는 다양한 시도가 이어지고 있다. SOA가 지향하는 저비용구조의 비즈니스 민첩성을 실현하기 위해선 무엇보다 SOA자원들을 관리하고 그 자원들을 프로세스에 맞추어 업무수행의 경쟁력을 확보할 수 있도록 하는 BPM의 중요성이 더욱 부각되고 있는 실정이다. 다시 말하면, BPM이 개입되지 않고서는 SOA는 막대한 전환비용만 소요될 뿐 단순히 개발비용 및 유지보수주기를 소폭 감소시키기만 하고, 프로세스 혁신을 통한 궁극적인 경쟁력 확보는 요원하게 된다.

SOA의 도입효과를 최대화하고, 성공적인 SOA기반 시스템 구축을 위해 BPM이 지원해야 할 특성들을 조망해보면, 다음 네가지로 압축시켜 볼 수 있다.

첫째, [시스템 커버리지]

SOA기반 시스템구축을 위해 SOA뿐만 아니라 Non-SOA도 수용이 가능하여야 한다. 역설적인 표현이나, 현재로선 파일럿 성격으로 제한된 범위 내에서 SOA를 적용하고자 하여도, BPM이 목적하는 End-to-End 프로세스 구현을 위해선 상당수의 Non-SOA 요소를 수용하지 않고서는 BPM 효과를 달성하기 어렵기 때문이다. 여기서 Non-SOA 요소란 현장 작업자들과 인터랙티브하게 작동하는 대다수의 어플리케이션들이나, 웹서비스로 전환하기 힘든 C/S기반 솔루션들을 일컫는다.

둘째, [플랫폼 중립성]

BPM은 플랫폼에 중립적이면서, 이질적인 플랫폼들을 통합할 수 있어야 한다. 플랫폼 기반의 업체들이 자사의 기존 제품라인을 SOA개념에 맞게 재정렬하여 수직일관 체계를 구축하였다고 하고, 해당 제품들간의 통합성을 자랑한다. 그러나 기업내 다양한 플랫폼이 상존해 있는 현실과, SOA를 활용하는 BPM의 역할이 다양한 IT자원들을 통합하고 조율하는 것임을 상기하면, 고객에게 독이 될 수 있는 처방을 제시한 셈이 된다.

셋째, [IT자원 재활용]

기존의 IT자원을 최대한 재활용 할 수 있어야 한다.  SOA의 주요 역할자로 부상한 ESB는 기존의 EAI 솔루션의 새로운 마케팅 컨셉에 다름 아니다라고들 한다. 따라서 독자적인 ESB 솔루션도 제시할 수 있어야겠지만, 고객사에 기구축되어 있는 EAI 인프라를 SOA의 주요모듈인 ESB 백본으로 활용할 수도 있어야 한다.

마지막으로, [업무중심의 BPM]

SOA에서 파생된 BPEL 표준만으로는 기업현장 작업자들의 Task를 프로세스로 재편하는데 한계가 있다. 프로세스 관리의 핵심인 업무를 조정할 수 있는 BPM 모듈의 관리하에, BPEL은 시스템연계의 측면에서 활용되어야 한다. BPEL의 용도는 메시지연계 및 웹서비스 호출에 집중되어 있어 수년간 워크플로우 기반 BPM에서 축적해온 다양한 업무규칙, 작업환경 설정등을 지원하는 측면에선 한계가 있기 때문이다.

위에서 언급한 SOA를 지원하는 BPM의 특성을 면밀히 살펴보면, 플랫폼 기반의 BPM 솔루션이 가지는 한계를 발견하게 된다. 웹서비스 등 SOA 요소들에 편향된 채, Non-SOA에 대한 해결책을 제시하지 못하고 있는 점과 [시스템 Coverage], 자사의 제품라인에 속한 플랫폼만을 강조함으로써 전사범위의 통합 이미지를 제시못하고 있는 점과 [플랫폼 중립성], EAI솔루션 등 기존의 IT자원에 대한 재활용 전략을 제시하지 않은 채, 고객에게 막대한 전환비용을 제시하는 점과 [IT자원 재활용], 업무 프로세스를 관리하기엔 아직은 데이터 연계에 편향된 BPEL기반으론 어려운 측면[업무중심의 BPM]이 바로 그 한계이다. 그러나 이러한 기술적인 면에 집중하면서 우리가 간과하게 되는, 보다 근본적인 한계가 플랫폼기반의 BPM솔루션에 존재한다.

SOA와 더불어 격변하는 시장환경에서 경쟁사 대비 우위의 경쟁력을 확보할 수 있는 도구이자, 생존의 전략으로까지 제시되는 BPM의 가치는 무엇에 기인하고 있는가? 서두에서 밝힌 바와 같이 "BPM은 민첩성과 운용 효율을 증대하기 위해, 비즈니스 프로세스 환경을 통제하는 일상적인 경영 활동"으로 정의할 수 있다. 총론의 관점에서의 BPM의 가치는 전사 프로세스의 가시화, 자동화, 성과중심의 업무체계 정립, 부분이 아닌 전사관점의 최적화 등을 들 수 있고, 각론에서는 현장에서의 다양한 업무규칙, 일관된 작업환경, 동적인 작업배분, 전략실행단위로서의 KPI설정, 모델링에서부터 실행/모니터링/피드백에 이르는 통합운영환경의 구축 등을 들 수 있다.

단순히 기술적 접근만으로는 해결할 수 없는 다양한 담론들을 포함하고 있다. BPM솔루션은 경영활동과 관련된 다양한 Best Practice를 지원하고 있어야하며, 이러한 Best Practice들이 고객의 프로세스에 내재화되면서 그 고객사만의 고유한 프로세스로 지속적인 혁신이 가능한 기반을 구축할 수 있어야 한다.

단순히 트랜잭션과 데이터 연계, 기존의 컴포넌트를 웹서비스로 전환/배포하는 기능들에 집중된 플랫폼 기반의 BPM 솔루션만으로 BPM의 가치를 실현하기는 어렵다. 플랫폼 기반의 BPM솔루션은 지극히 트랜잭션 및 데이터연계에 편향적이고, 지극히 범용적이며 포괄적인 솔루션을 제시하고는 구체적인 시스템 완성의 책임을 고객에게 전가하고 있다. 우리가 플랫폼기반의 BPM업체들을 우려의 시각으로 바라보는 이유가 바로 여기에 있다.

<출처 : http://www.bloter.net/_news/8df427eb1c2ef70c>

2007 년 8 월 21 일

서비스 지향 아키텍처(SOA)는 많은 비즈니스 변형 노력의 중심에 있습니다. 많은 기업들은 점증적으로 SOA로의 변형을 시도하고 있고, 귀중한 레거시 IT 시스템들을 서비스 공급자로서 참여시키고 있습니다. 솔루션 아키텍트는 변형을 도모하는 수단으로서 SOA 인프라스트럭처를 제공해야 할 뿐만 아니라, 기업 중심의 비즈니스 연산들을 강력하고 순응적인 것으로 유지해야 하는 도전에 직면해 있습니다. 여러분의 기업은 SOA의 일부가 될 수 있는 엔터프라이즈 정보 관리 전략을 개발하고 모든 비즈니스 연산에서 전체적인 데이터 및 콘텐트 일관성을 관리해야 합니다. 이와 같은 변화 과정에 대해 알아보고 디자인 전략을 공부해 봅시다.

머리말

여러분의 비즈니스가 거의 비슷하다면, 비즈니스 전략과 핵심 경쟁력 분석은 비즈니스 리엔지니어링과 IT 현대화에 초점을 맞춰야 한다. 일반적인 산물이(엔터프라이즈의 핵심 측면에서 볼 때) 서비스 지향 비즈니스로의 변형 및 SOA에 대한 의존성이다. 비즈니스 연산은 현재 IT 시스템이 재 엔지니어링 되고 서비스 공급자로서 통합되어야 하는 서비스 세트를 중심으로 설계된다. 변형 역시 새로운 서비스 공급자를 도입한다. 목표는 내부 워크플레이스 포털 애플리케이션 또는 인터넷 커머스 애플리케이션 같은 새로운 복합 애플리케이션들을 구현하여 특수한 비즈니스 필요를 채우는 것이다.

이렇게 도전이 되는 변형의 일부로서, 엔터프라이즈는 많은 중요한 비즈니스와 IT 프로그램에 개입되어 있다. 주요한 변형에는 다음이 포함된다.

• 비즈니스 서비스 모델 중심의 엔터프라이즈 아키텍처 정렬.
• 비즈니스 서비스 모델의 관련 부분들을 실현할 수 있는 서비스 기반 IT 인프라스트럭처의 도입.
• 레거시 IT 시스템이 변형, 확장, 래퍼 적용을 통해 서비스 기반 IT 인프라스트럭처로 통합될 수 있도록 함.
• IT 애플리케이션들을 지원하는 효율적이고 유연한 구현을 가능케 하는 강력한 디자인 및 개발 환경 및 딜리버리 프로세스.

이러한 변형의 산물들은 구현상의 문제를 만들어 낸다. 엔터프라이즈는 변형의 의도를 전달하고 변화를 적용하여 유연성을 실현할 수 있는지를 확인해야 한다. 이러한 변형 노력은 다음의 원리를 따른다.

• 엔터프라이즈는 강력하고 순응적인 비즈니스 연산을 제공해야 한다.
• 전체 비즈니스 서비스 모델과 IT 시스템 구현이 변형 원리에 순응할 수 있도록 하는 거버넌스 프로세스와 디자인 권한이 필요하다.
• 엔터프라이즈는 비즈니스와 IT 서비스 관리의 통합적인 뷰를 통해 측정과 응답성 변화가 이루어 질 수 있도록 해야 한다.

일부 엔터프라이즈는 전체 조직에 걸쳐 SOA로 비즈니스 변형을 할 수 있다. 이러한 방식은 기본적인 변형 인도물에 대한 더 큰 도전을 시사하고 있지만, 결과적으로, 부차적인 변형 인도물을 성장시키고 개발하기에는 더 쉽다. 이러한 유형의 시나리오는 엔터프라이즈에 비즈니스 및 IT 변화를 이룩하고자 하는 최고위 간부들이 전략적인 문제를 지원하기로 결정할 때 발생한다.

그러나, 대부분의 엔터프라이즈 변형은 점증적이고 거대하며 전략적이다. 레거시 IT 시스템들은 리엔지니어링 되어, 다른 IT 시스템들을 결합하여 고객 주문 프로세싱을 단순화 하는 등, 새로운 비즈니스 연산 지원에 참여할 수 있어야 한다. 이러한 IT 시스템들은 현재 갖고 있는 모든 또는 대부분의 기능을 계속해서 수행한다. SOA 변형의 범위 밖에서의 비즈니스 연산들도 여전히 지속된다.

변형 시나리오에서, SOA IT 인프라스트럭처에 대해 신중한 구현 디자인을 모색해야 한다. 이러한 IT 시스템 내에서의 데이터 프로세싱은 이 범위 밖에서의 데이터 프로세싱에 영향을 주고, 이 프로세싱에 의해 영향을 받는다. 전체적인 데이터 프로세싱 환경은 전체 비즈니스 연산에 대하 강력함과 순응성을 유지해야 한다.

그림 1의 예제는 세 개의 레거시 시스템들이 서비스 프로바이더가 되도록 엔지니어링 되는 모습을 보여준다

그림 1. 새로운 SOA 환경에서의 레거시 IT
 

그림 1에서, 비즈니스 변형 프로그램이 SOA 인프라스트럭처를 구현했고, 비즈니스 서비스들은 여기에서 퍼블리시 되고 새로운 애플리케이션에 의해 소비될 수 있다. 이러한 인프라스트럭처에는 일반적으로, 소프트웨어 간 다중 프로토콜 연결, 비동기식 및 동기식 메시지 플로우 관리, 메시지 트랜슬레이션, 규칙 실행, 프로세스 구성법을 실행하는 미들웨어가 포함된다. 이러한 서비스들을 사용하는 복합 애플리케이션들이 구현되었고, 레거시 시스템들은 새로운 서비스들을 호출함으로써 강화되었다.

SOA에서의 프로세스와 정보 아키텍처

SOA 인프라스트럭처를 구현하기 위해, 비즈니스 서비스 모델(business service model)이 생성, 관리, 향상된다. IBM® Service Oriented Modeling and Architecture (참고자료) 같은 기술들은 이러한 모델을 개발하는데 사용된다. 전형적인 엔터프라이즈에서, top-down 분석, bottom-up 분석, 목표 서비스 모델링이 포함된다. 변형의 목표는 새로운 비즈니스 연산과 지원하는 IT 애플리케이션들의 구현을 실행하는데 사용되는 프로세스 및 정보 아키텍처로 귀결된다.

• 프로세스 아키텍처는 엔터프라이즈 연산을 받치고 있는 비즈니스 프로세스를 형성하기 위해 결합될 수 있는 액션의 기능적 계층이다. 인간 대 시스템, 시스템 대 시스템의 플로우 컨트롤을 책임진다. 예를 들어, 고객이 제품 주문을 하고 그 제품의 전달을 기다리는 상태가 되는 동안 필요한 액션들이 포함된다.
• 정보 아키텍처는 엔터프라이즈 연산에 상태와 의미를 제공하기 위해 액세스, 조작, 저장되는 관련 데이터 및 콘텐트 세트이다. 데이터 및 콘텐트의 정보 관리를 수행한다. 단순한 액세스 이벤트나 프로세스 플로우 정황이든 상관이 없다. 제품 개발 라이프 사이클 동안 소비 및 생성되는 데이터와 콘텐트가 하나의 예이다.

프로세스와 정보 아키텍처 뷰포인트는 프로세스-데이터(CRUD) 매트릭스 같은 것을 통해서 개발 및 제시된다. 이들은 서비스 아키텍처를 구성하는 많은 서비스들을 정의한다. 서비스는 메시지 데이터가 전달된 곳에서 호출되는 연산 세트이다. 서비스 구현은 영속 스토리지나 액세스를 사용하여 데이터나 콘텐트를 조작하는 프로세싱을 수행하고 결과를 리턴한다. 서비스는 동기식 및 비동기식으로 사용될 수 있고, 호출은 통합 인프라스트럭처에 의해 일반적으로 중재된다. 완전히 분리된 시스템에서, 일부 서비스들은 변경 사항들이 상태를 처리하도록 한다. (예를 들어, 요청된 정보가 제공될 때, 고객 X에 대한 새로운 주소의 유효성 검사가 수행된다.) 다른 서비스들은 정보 상태가 바뀌도록 하면서, 데이터와 콘텐트가 향후 서비스 이벤트가 의존할 수 있는 원하는 상태가 되도록 조작한다. (예를 들어, 새로운 선적 주소가 고객 X에 적용된다.)

레거시 데이터 프로세싱 문제

레거시 IT 시스템들은 의심할 여지 없이 엔터프라이즈의 서비스 공급자 구현의 일부이고 SOA 인프라스트럭처로 통합된다. 레거시에는 전통적인 메인프레임 프로세싱 뿐만 아니라, 엔터프라이즈 리소스 플래닝(ERP) 애플리케이션, 내/외부 웹 애플리케이션, 워크플로우 애플리케이션, 스캐닝 및 프린팅 시스템 등이 포함된다. 이러한 레거시 시스템들이 사용되고 서비스-공급자 구현으로 결합되기 위해서는 많은 일들이 발생할 수 있다.

• 프로세싱 함수는 노출되고 액세스 되어 서비스 공급자 구현에 결합된다. 이는 CICS® 트랜잭션의 SOAP 래퍼처럼, 새로운 프로토콜과 호출 메커니즘을 통해 트랜잭션을 노출하는 것을 의미한다.
• 함수들은 트랜잭션을 노출할 때 프로세싱 무결성을 관리하도록 리엔지니어링 되어야 한다. 트랜잭션은 기존에 존재했던 것 또는 한 개 이상의 기존 트랜잭션을 호출하기 위해 생성되어야 한다. 서비스 세분성 전략은 그러한 서비스의 호출 디자인에 영향을 미친다.
• 특정 프로세싱 함수는 데이터 프로세싱이 서비스 공급자 구현을 통해 호출되는 새로운 함수에 의해 수행되기 때문에 스위치를 꺼야 한다.
• 기존 액세스 권한과 보안 및 감사 요구 사항들은 새로운 액세스 메커니즘을 위해 실행되어야 한다.
• 기존 시스템의 서비스 품질(Quality of Service (QoS)) 기준은 확장 또는 보충되어야 한다. 예를 들어, 오프라인 일괄 프로세싱 윈도우는 대리 프로세싱 솔루션에 의해 다루어져야 한다.
• SOA는 기존 시스템에 새롭고 예측할 수 없는 부하를 가져오는데, 이는 기존 프로세스에 부정적인 영향을 미친다.

레거시 IT 시스템들이 SOA에 참여하고자 하는 노력으로 노출될 때, 변형의 범위 밖에서 비즈니스 연산을 지원하는 특정 함수들이 데이터 프로세싱을 지속한다. 여기에는 일반적으로 데이터 동시성과 동기화 문제를 이해하고 다룰 수 있어야 한다.

사용자는 계속해서 원래의 애플리케이션 수단을 사용하여 레거시 IT 시스템을 호출한다. 주로 사용자 인터페이스(메인프레임 터미널 또는 애플리케이션의 UI)를 통해서 호출한다. SOA는 SOA 생태계 주위로 흐르는 메시지를 기술하기 위해 사용되는 데이터 스키마에 의존한다. 이러한 데이터 스키마들은 서비스 연산의 협업 세트 내에서 통합되는 물리적인 데이터 메시지로서 실현된다. 여기에는 런타임 데이터 트랜슬레이션, 의미 매핑, 또는 메시지 데이터의 추가 등이 포함된다. 데이터는 기반 레거시 IT 시스템에 의해 사용 및 처리된다.

SOA에서 실행될 수 있는 프로세스 세트는 특정 상태로 되어 있어야 하는 데이터와 콘텐트에 의존한다. SOA 함수와 레거시 IT 시스템들을 통한 병렬 프로세싱은 상태 모델에 불안정하게 만들 뿐이다.

그림 1의 예제에서, 변형은 고객의 보험 정책을 설정하고 관리하는 단순한 프로세싱 기능을 갖고 있는 새로운 인터넷 애플리케이션을 실행했다. 이 새로운 애플리케이션들은 고객과의 연락을 실행하고 보험 정책이 갱신될 때 갱신 처리를 제공한다. 하지만, SOA 범위 밖에 있는 기존 비즈니스 연산들은 문제를 일으킬 수 있다. 고객들은 거주지를 옮겼던 경로에 따라 회사에 공지할 수 있는 수단이 있다. 새로운 인터넷 애플리케이션을 통해 정책이 처음 구매되었더라도, 고객은 SOA 애플리케이션을 사용하여 회사에 주소 변경을 알리지 않고, 대신 편지를 보낼 수 있다. 백 오피스(back- office) 프로세스는 고객의 새로운 주소가 고객 관리(CRM) 시스템에만 적용되도록 한다. 기존의 CRM 시스템의 일괄 프로세싱이 Insurance Contract Administration 시스템을 고객 데이터로 업데이트 한다. 새로운 SOA 기반 시스템은 거의 실시간 트랜잭션으로 설계되므로, 데이터 동기화 타이밍 문제가 발생한다. 새로운 애플리케이션은 오래된 주소의 갱신에 대해 고객과 연락을 시도할 수 있고, 응답 및 콘텍스트 인식 SOA 애플리케이션이 새로운 주소에 있는 사람에게 연락하여 오래된 정책을 취소하고 새로운 정책을 설정한다

서비스 공급자

SOA 아키텍트의 역할은 서비스 실행 인프라스트럭처의 디자인과 구현과 관련되어 있다. SOA 모델링 기술은 프로세스와 정보 아키텍처가 소비할 서비스를 결정하고, 서비스 공급자와 연락하고, 프로세싱 실행과 데이터 프로세싱의 일부로서 서비스 연산을 호출하는 애플리케이션을 구현할 수 있게 도와준다. 서비스 소비자는 동의된 계약에 따라 데이터를 처리하고 관리하는 한 서비스 공급자가 서비스를 구현하는 방식은 신경 쓰지 않는다.

특정 시나리오에서, 모델이 작동한다. 특히, 여러분이 서비스 공급자 구현을 기업 외부에서 아웃소싱 했을 경우에 그렇다. 이 글에서는 오늘날 많은 기업들이 SOA를 채택하면서 겪게 되는 특수하지만 공통적인 시나리오에 초점을 맞춘다.

현실은, SOA 변형에서 전체적인 솔루션 아키텍트는 많은 책임을 갖고 있고, 특히 점증적인 변형을 해야 하는 기업의 경우 특히 그렇다. 이러한 책임은 기업 거버넌스 프로세스의 영역 안에서 수행된다. ("SOA 거버넌스" [developerWorks, 2005년 8월]).

우선, 솔루션 아키텍트는 SOA 인프라스트럭처의 디자인과 구현에 관련되어 있다. 여기에는 서비스 공급자 구현의 일부를 형성하는 소프트웨어 시스템으로서 작동할 레거시 IT 시스템을 구분하는 것이 포함된다. 두 번째, 솔루션 아키텍트는 서비스 소비 애플리케이션을 조합할 수 있는 개발 프로세스와 환경을 제공한다. 여기에는 디자인 패턴과 표준, 툴링 환경이 포함된다. 셋째, 솔루션 아키텍트는 비즈니스와 IT 아키텍처를 구성할 수 있어야 한다. 비즈니스 아키텍트는 기능과 콘트랙트와 관련하여 비즈니스 전략을 짜야 한다. IT 아키텍처는 전체적인 비즈니스 연산을 지원하는데 필요한 IT 시스템을 제공할 것이다. 대형 엔터프라이즈 내에서, 이는 전략적 애플리케이션의 대형 포트폴리오가 된다

디자인 전략

전체적인 엔터프라이즈 순응성을 실행하는 강력한 정보 관리 아키텍처를 구현하기 위해서는 이 문제를 다룰 많은 디자인 전략과 원리를 생각해야 한다.

비즈니스 프로세스 분석에 있어서 범위 변경 계획

변형 프로그램 동안, 일반적으로 시스템 분석과 디자인이 바람직하지 못한 데이터 프로세싱 시나리오를 발견하게 된다. 이전에 범위에서 벗어났던 비즈니스 연산들은 다시 범위로 가져와서 새로운 시스템을 수용할 수 있도록 수정될 수 있다. 새로운 SOA 기반 시스템들은 고객 상세를 업데이트 하는 추가 프로세싱 단계 같은 변화된 비즈니스 연산을 위해 내부 애플리케이션을 제공해야 한다.

레거시 엔터티 변화를 퍼블리시 및 등록하기

동의된 엔터티와 애트리뷰트 데이터가 서비스 공급자로서 참여하는 레거시 IT 시스템에서 변화될 때, 추가 프로세싱은 SOA에 알리도록 개발되어야 한다. 이상적으로 이것은 실시간으로 되어야 하지만, 스케줄링이 된 일괄 액티비티가 된다. 데이터 기록이 바뀔 때 탐지하는 레거시 IT 시스템으로 계측 코드를 적용하는 데는 비용이 많이 들고, 오래되고 구조가 형편없는 애플리케이션 코드에서는 거의 불가능 하다.

엔터프라이즈가 수행해야 하는 한 가지는 레거시 시스템이 소유한 데이터와 관련 당사자에게 변화를 공지하는 시스템 기능을 평가하는 것이다. SOA에 중요한 데이터가 자주 변하고 이것이 레코드 레벨 이벤트 트리거를 생성하는 시스템의 무능력과 결합한다면 레거시 시스템의 리엔지니어링 또는 대체를 다시 고려해야 한다. 비즈니스 서비스의 QoS는 계획된 엔지니어링 노력으로 정렬되어야 한다 핵심 서비스 데이터의 일괄 프로세싱에서 실시간 메시지 중심 프로세싱으로 옮기는 것 같은, 엔지니어링 향상을 통해, QoS가 시간이 흐르면서 향상되고 있다는 것을 나타내야 한다.

정보 서비스 쿼리 facade

정보 관리 서비스는 데이터 또는 콘텐트에 적용될 수 있는 단순한 액션들을 나타내야 한다. 쿼리 facade는 정보가 액세스 되고 조작되는 방법을 숨기고, 물리적 IT 시스템들이 얼마나 많이 있는지도 숨긴다. 기본적으로, 쿼리 facade는 데이터 통합을 이룩하기 위해 두 개의 패턴을 구현할 수 있다. 엔터프라이즈 내에 다양한 시나리오와 레거시 시스템들 때문에 서비스를 구현하는데 이 두 가지가 사용될 것이다.

• 데이터를 쿼리로 가져오기. 천천히 변하는 정보를 데이터 스토어(웨어하우스)로 가져오고, 그곳에서 데이터에 대해 작동한다. Extract, Transform, Load (ETL) 기술들이 여기에서 사용될 수 있다.
• 쿼리를 데이터로 가져오기. 빠르게 변화하는 트랜잭션 데이터의 경우, 액션은 이를 조작할 수 있는 물리적 소스로 가야 한다. 커넥터와 어댑터 기술을 사용하여 액세스 할 수 있다. (읽기 및 업데이트)

SOA 내에서, 실제 쿼리 facade는 federation과 population (참고자료 섹션의 데이터 통합 애플리케이션 패턴 참조) 같은 다양한 패턴들을 사용하여 구현되고, Service Data Objects와 Data Access Services (참고자료) 같은 기술을 사용하여 구현된다. 다양한 서비스 구현을 위한 전체적인 디자인 패턴("서비스 지향 아키텍쳐와 통합을 위한 패턴 언어, Part 1" [한국 developerWorks, 2005년 7월])은 이러한 결정에 영향을 미친다. 하지만, 이러한 문제 공간에서, 구현 디자인은 확장되어 서비스를 더욱 지능적인 것으로 만든다. 엔터티 데이터 변경 사항을 퍼블리시 하는 레거시 시스템을 위한 솔루션이 정비된 상황에서(QoS), 정보 시스템은 변경 사항을 등록하고 변경 사항들을 각각의 물리적 시스템에 적용해야 한다.

이것은 엔터티 결정을 완성하는 아키텍처의 장소이다. 어떤 레거시 IT 시스템이 마스터로 간주되어야 할까? 여기에서 마스터 데이터 관리 기술은 구현을 도울 수 있고, 옵션과 결정들은 레거시 시스템의 통합 기능과 균형을 맞추어서 아키텍처 정의의 중요한 부분이 되어야 한다.

비즈니스 규칙 배치

SOA로의 변형에는 통합 미들웨어와 새로운 복합 애플리케이션들을 포함하고 있는 새로운 IT 인프라스트럭처가 도입된다. 비즈니스 규칙들은 하나의 애플리케이션 안에서만 더 이상 제한되지 않는다. 상태는 비즈니스 규칙의 실행을 통해 효과적으로 관리된다. 정보 관리 디자인을 개발하는 것의 일환으로 비즈니스 규칙 로직의 유형과 위치가 이해되어야 한다.

SOA 내에서 비즈니스 규칙의 유형에는 다음이 포함된다.

• 참조 무결성 규칙
• 애플리케이션 작동 규칙
• 크로스 애플리케이션 통합 규칙
• 트랜잭션 프로세싱 비즈니스 로직 규칙
• 저장 프로시저 같은 데이터 엔터티 프로세싱 규칙

전략은 비즈니스 규칙을 다시 만드는 것이 아닌 재사용이 되어야 한다. SOA의 도입으로 기존의 비즈니스 규칙과 새로운 비즈니스 규칙을 실행하는 것을 신중하게 생각해야 한다. 규칙 로직 그 자체는 특정 프로세싱 시나리오를 위해 무결성을 관리하기 위해 호출될 수 있는 서비스로서 노출되어야 한다.

잠재적인 디자인 전략 영향

이와 같은 디자인 결정에 다다르면 여러분이 고려해야 하는 솔루션에 미치는 영향은 다음과 같다.

• 더블-키 프로세싱. SOA의 도입으로 인해 하나의 비즈니스 영역에서 얻어진 효율성은 추가 데이터 엔트리 태스크(그리고 데이터 엔트리 에러의 위험)에 비례하여 균형이 맞춰져야 한다. 하지만, 이것은 데이터-동기화 타이밍 시나리오를 대처하기 위한 유일한 옵션이다. 이러한 시나리오는 보통 가볍게 취해진다. 엔터프라이즈는 밤마다 수행되는 일괄 업데이트의 시간 지연을 피하기 위해 이벤트 중심 더블 키(keying)를 수행하는 인원수를 확립해야 한다. 데이터 동기화를 보조할 시스템에서 자동화된 인터페이스를 개발하는 비용도 계산해야 한다. 자동화된 인터페이스를 구현하는데 필요한 시간이 전체적인 딜리버리 타임 스케일을 구성하는지 여부도 평가해야 한다.
• 불필요한 피드백 루프. CRM 시스템에서의 고객 기록 업데이트는 SOA로의 수동 또는 자동 호출로 이어져서 영역 KR의 고객 데이터 변경에 대해 다른 애플리케이션에 알려야 한다. 고객을 업데이트 하려면, SOA는 정보 서비스를 호출하고, 이는 그 자체로 원래의 CRM 시스템을 호출하고 고객 데이터를 업데이트 한다. 정보 서비스 아키텍처는 사용 모델에 기반하여 업데이트 고객의 다른 스타일을 구현해야 한다.
• 범위 이동. SOA 범위가 정의될 때, 레거시 IT 시스템에 대한 지식의 부족과 프로세스 및 정보 관리 기능도 변하게 된다. 서비스 모델의 파생은 레거시 분석을 이끌어 내고, 보다 미묘한 SOA 인프라스트럭처 구현이 필요하다는 것을 드러낸다. 전체적인 비즈니스 서비스와 엔지니어링 프로그램의 전체 범위를 정의하기 전에 단계를 플래닝 해야 한다.

결론

이 글에서는 SOA로의 성공적인 비즈니스 변형 프로그램을 제공하는 것에 초점을 맞추었다. SOA로의 비즈니스 변형의 문제는 매우 많다. 대부분의 기업들은 새로운 복합 애플리케이션들이 구현될 수 있는 SOA 인프라스트럭처를 도입함으로써 점증적인 변형을 시도하고 있다. 이들은 레거시 IT 시스템들을 사용하여 서비스 공급자를 구현한다.

강력하고 순응적인 연산을 기업이 유지하려면, 변형 프로그램은 엔터프라이즈 정보 관리 솔루션을 개발해야 한다. 이 솔루션은 SOA에서의 레거시 IT 시스템들에서 데이터의 일관성과 동기화 문제를 다루어서 정보 서비스들이 안전하게 노출될 수 있도록 해야 한다.

SOA 변형을 제공하는 책임이 있는 솔루션 아키텍트는 전체적인 엔터프라이즈 아키텍처 및 예산의 정황 속에서 SOA의 필요와 레거시 IT 시스템의 기능에 균형을 맞춰야 한다. 데이터 통합을 위한 기술과 주 데이터 관리는 정보 관리 솔루션을 위한 구현 전략에 포함된다

감사의 말

이 글을 검토해 준 Rick Robinson, Patrick Dantressangle, Bob Lojek, Claudio Cozzi에 감사의 말을 전하고 싶다.

참고자료

교육

• Ali Arsanjani의 기술자료, "서비스 지향 모델링과 아키텍쳐 (한글)" (한국 developerWorks, 2004년 11월) : SOA 서비스의 정의, 특성화, 구현 방법.
• Tilak Mitra의 기술자료 "SOA 거버넌스" (developerWorks, 2005년 8월)
• 데이터 통합 애플리케이션 패턴: IBM Patterns for e-business 사이트.
• "Service Data Objects 소개" (developerWorks, 2004년 9월): Bertrand Portier와 Frank Budinsky의 Service Data Objects를 활용한 차세대 데이터 프로그래밍 소개.
• Service Data Objects 스팩.
• Ali Arsanjani의 기술자료 "서비스 지향 아키텍쳐와 통합을 위한 패턴 언어, Part 1: 서비스 생태계 구현하기 (한글)" (한국 developerWorks, 2005년 7월) : 이 시리즈에서 이들의 사용법과 관련된 패턴과 경험들을 나눌 것이다. 또한 SOA와 SOI의 마이그레이션, 모델링, 디자인, 구현과 관련된 문제에 대한 솔루션도 모색해 볼 것이다.
• developerWorks 기술 이벤트와 웹캐스트.
• IBM SOA 웹사이트
• 한국 developerWorks의 SOA와 웹서비스 존
• Safari bookstore.

제품 및 기술 얻기

• IBM 시험판 소프트웨어를 다운로드하여 차기 개발 프로젝트에 활용해보라(다운로드 또는 DVD)

토론

• 포럼에 참여하기.
• developerWorks 블로그와 커뮤니티 참여하기.

필자소개

BPM is SOA’s killer application, and SOA is BPM’s enabling infrastructure. We’ve used this tagline before, but simple truths are worth repeating, for their deceiving simplicity might overshadow their relevance.

On one hand, and to a large extent, the Service Oriented Architecture (SOA) is a solution in search of a problem, and the Return on Investment (ROI) customers can expect from any SOA initiative has been a hot topic of discussions as of late. In such a context, Business Process Management (BPM) might very well be the one indisputable reason why any IT shop should consider deploying SOA today.

On the other hand, the benefits BPM can offer to the business, in terms of agility, affordability, and accountability, cannot be gained without the proper underlying infrastructure. So far, BPM has remained a point solution, deployed through proprietary products. The emergence of SOA, and the establishment of industry standards that take advantage of it — BPEL being first among them — should lay the ground for BPM’s mainstream adoption.

BPM is SOA’s Killer Application
The problem with the Service Oriented Architecture is that it is exactly what its name implies, an architecture. It’s a set of guiding principles. It’s a philosophy. It can help an architect design a blueprint for something concrete, but nothing more. It is not the blueprint, even less the building. Architecting is not building, and if companies do just that, they’ll end up with very little in the end, after having spent a lot of time, money, and efforts getting there. SOA should not be seen as the end, but the means to the end. The challenge then becomes about finding what the end is that will justify the means.

Advocates of SOA have heralded the need for agility as the main business driver for deploying their architecture of predilection. Unfortunately, business types have found it difficult to understand how SOA could provide true business agility. The most litterate among them might have realized the benefits it could bring to their IT departments in terms of costs reductions, but the other quickly dismissed it as yet another IT fad.

From a business standpoint, a service is too small a unit to really appeal to the business side of the house. Its granularity is too fine. And it’s only when elevated to the level of processes that business folks usually start paying attention. Reusing a currency conversion service across multiple applications, and saving three man-month of development along the way, is one thing. Being able to shave three weeks in the overall order-to-cash process is another. Guess which of the two will get the CFO’s attention?

Once customers start putting a Service Oriented Architecture in place, the desire to tie their newly-available services together into coarser-grain services, or higher-level processes, is felt rather rapidly. This should not come as a surprise: services can be seen as neatly-packaged units of functionality, and the main reason for such a packaging is to enable their composition.

Now let’s make a little experiment: I suggest you draw a set of boxes on a white board, and give them names of ’services’ that make sense for the particular business you’re in. Then ask a colleague to ‘combine’ them into something useful. I bet you that what you’ll see being drawn on the white board is a set of arrows connecting the boxes, and resembling the flowcharts you used to draw when practicing the principles of the good old Business Process Reengineering methodology. Here you have it: a process!

But BPM would not be SOA’s killer application if it would work only after you get SOA, for, as we indicated before, you might never get it. Instead, BPM is SOA’s killer application because it will give you the reason for doing SOA at the first place. Without BPM, the main ROI for SOA is reduced IT costs. With BPM, you can directly link the ROI for your SOA project to the ROI you could get from any improved business process. All you have to do is ask the business which processes they’d like to fix first, put Return on Investment tags on them, and you’ll get the justification for your SOA initiative, with the budget to deploy it.

Better yet, deploying SOA in the context of BPM-powered process work will give you the right SOA. Here is why. SOA is more philosophy than religion. The book of SOA is more Tao Te King than Bible. For example, no consensus has emerged as to what the level of granularity of services should be. Some will say it should be at the level of fulfilling a purchase order, orders will advocate that it should be lowered to the level of recording the purchase order, yet others will recommend that it should be down to the level of creating the header for the purchase order, while using another service to record each line item. Who’s right? Nobody knows…

In reality, there is no absolute answer to this question, and the right answer will depend upon the business scenario — not to say business process — the question was asked in relation to. As a result, deploying SOA in the context of a BPM process will help you package services with the appropriate level of granularity, at least within the context of the business processes they’ll be involved in. Nothing will prevent you to compose coarser grain services out of smaller existing ones, or expose technical details of another into finer grain ones, but you will do it for a very good reasons, always justified by business requirements. Again, SOA is a means to an end, and the way this means is shaped usually depends upon the actual end that is sought after.

For all these reasons, BPM is SOA’s killer application.

SOA is BPM’s Enabling Infrastructure
One of the main ideas behind BPM is to abstract technical systems and requirements in such a way that new business processes could be designed, deployed, executed, monitored, and optimized, without having to write any software code, while most of the work would be done by non-technical folks — or at the very least less-technical ones.

This in turn would bring agility, affordability, and accountability to the business. Agility as in the ability to change the process as fast as the business itself is changing. Affordability as in the ability to deploy, in a cost effective way, a new process that could not have been deployed with any other technology before. And accountability as in the ability to prove, in a non-ambiguous way, that what your IT systems are doing in relation to your business processes is exactly what they were intended to do at the first place — in today’s SoX-constrained world, people are discovering this to be a lot harder than they initially thought.

To some, this idyllic scenario might sound too good to be true, and until recently, it really was. Without a way to provide the functional richness of existing systems packaged into reusable units, without having to expose their technical complexity, what could have been presented as a silver bullet actually turned into magic pixie dust, which is another word for vaporware. It just did not work, or at least not as advertised, and behind the neat little boxes and arrows, armies of developers would have to write arcane code, using languages such as C++, Java, or JavaScript.

Granted, there were some technologies that could have been used to make it work. CORBA was one of them. Problem is, as early incarnations of what we call SOA today, they were not ready for prime time, and more often than not turned out to bring more complexity, exactly where there should have been less. Again, it just did not work.

Then came XML, and the idea of using standard Internet protocols to connect all the pieces together. People called it Web Services, then started thinking about an architecture for managing it all, and SOA was born. It took some more years for the concept to mature, but it eventually reached a critical mass of adoption, making it the de-facto standard for any enterprise architecture today.

Of course, industry standards played a key role in this adoption process. By its very nature, SOA is all about enabling different actors (people, processes, and systems) to communicate with each others, and sharing a common language is usually a good way to foster communication. This lead to the development of specifications such as SOAP and WSDL, which today are the fabric of any new application being developed.

Right around the same time, industry standards for BPM started to coalesce as well. BPML got rid of proprietary languages — very few remember WSFL and XLANG today, and was eventually replaced by WS-BPEL — also known as BPEL, which took full advantage of the emerging stack of standards for Web Services — as well as IBM’s deep-pocketed marketing resources. But because boxes and arrows seem to be more pleasing to the eyes of most business analysts than angle brackets, BPMN was developed, and eventually established as the standard graphical notation for the modeling of executable business processes.

Ultimately, a stack emerged. WSDL for packaging services, BPMN for designing processes, and BPEL for executing processes built out of packaged services. All of a sudden, true BPM — what some call BPM 2.0 — became possible. It worked in a Zero Code manner, supported One Click Deploy for the most complex processes, and enabled a groundbreaking middle-out approach that empowered business analysts and less technical folks — called process analysts today — to work together on the same process, using the same tool.

Then BPM started to work, enabled by SOA

<출처 : http://itredux.com/blog/2006/08/13/bpm-is-soas-killer-application/>