현재 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>

      Business Process Oriented  |  2008. 3. 13. 15:37



archidream's Blog is powered by Daum