^^; 조금 장난스러운 설명이다..

BPM의 주요 요소 중 하나인 Process Modeling Tool의 결과물로서 BPEL 표준을 제공하는 경우가 있다.

이 BPEL은 어디에 쓰일 것인가?
- 느슨한 형태로 연계된 여러 개의 웹 서비스들을 조합하여 롱-러닝 워크플로우(long running workflow)를 생성하고 이를 하나의 비즈니스 애플리케이션으로 통합하는 것을 주된 목적

위와 같은 목적으로 BPEL은 ESB의 표현 수단으로 활용된다.

IBM 제품의 경우 BPM Suite의 Lifecycle을 보면

WBM(Webspher Business Modeler) --> WID(Websphere Integration Developer) --> WPS(Websphere Process Server) --> BAM(Business Activity Monitoring)

위와 같은 라이프 사이클을 가지고 있어서, WBM에서 모델링한 결과물을 WID라는 Integration Tool에서 Import해서 해당 서비스들과 연결 작업을 한 후에... WPS에 Deploy하게 된다. 그리고 BAM에서 WBM에서 작성한 KPI를 통해서 모니터링을 하게 되는 것이다.

연관성 (일관성)이 있는 구조이다. 하지만..전적으로 프로세스 모델링을 위한 BPEL을 사용해야 한다.

또한 표현의 기준은 WBM에서 작성한 BPEL이다. ESB 즉, WID에서 작성한 내용이 더 복잡해 질 수도 있고, 추가되는 내용도 다양할 것이다.(Websphere의 경우 WPS는 표준 프로토콜에 대해서만 ESB 기능을 탑재했다. 만일 Adapter를 사용한다면.. Message Tranformation, Validation등이 추가되어야 할것이다.)

Integration 관점은 논 외로 하고 ....

위의 그림에서 보는 것처럼 모델링에 대한 결과물을 다시 BAM의 Input으로 들어간다.
BAM의 목적은 비즈니스 프로세스 모델링을 근거로 KPI 등 모니터링을 위함이다.

작년에부터 오라클, 핸디소프트 등에서 Stand Alone BAM 제품이 출시되기 시작했다.

왜 별도의 제품으로 자사의 BPMS 없이도 별도의 구성이 가능하다.

현재 대부분의 BPM은 프로세스 모델링 시점에서 KPI를 설정해서 모니터링한다. 모델링 시점에서 모니터링 요소에 대한 부분을 구성하기는 쉽지 않다. 때문에 별도의 BAM 모델링을 통해서 모니터링 요소를
끌어내는 것이다.

라이프 사이클을 보면 일반적인 BPM의 라이프 사이클과 유사하다.

ORACLE, 핸디소프트 같은 BPM Suite을 제공하는 경우 단독으로도 판매가능한 BAM 제품을 출시 하였다. 이것은 그만큼 BAM의 중요성을 부각시킨것이다.

Business Process Improvement의 키워드가 바로 BAM인 것이다.

따라서, 맨위의 그림과 같이 BAM의 Input으로 모델링 결과물(BPEL)이 제공될 수 있어야  그 상황에 맞게 Action을 추가 할 수 있다.
다시 말하면 BPEL(모델링 결과물)은 설계서 같은 것이다. 이 설계서를 기반으로 연동해야할 Activity 등을 확연히 구분해 낼 수 있고, 또한 설계서를 근거로 어떤 방식의 모니터링을 구성할 수 있을지 판단할 수 있을 것이다.

또한 BAM에서의 EAI역할은 기존의 프로세스 데이타만으로 KPI를 삼아야 했던 약점을 잘 보완 할 수 있을 것이다.

BPM 성장의 열쇠는 BPM을 사용하는 사용자에게 어떠한 Value를 돌려 줄 것 인가이다.

점진적으로 개선되는 프로세스로는 자극적(?)인 효과를 볼 수 없다.

눈에 확연히 들어오고, 명확히 인지 할 수 있는 내용을 설득력있게 호소해야 할 것이다.

관련 자료 :http://itislord.tistory.com/entry/Business-Activity-MonitoringBAM