[1편] SOA와 Service의 정의
[2편] BPM을 통한 서비스 분류하기(계획)[3편] ESB를 이용하여 Service Enabling 하기(계획)
[4편] SOA 잘 돌리기(계획)
[1편] 에서 SOA와 Service의 정의에 대해 알아봤다.
그럼 이제 그 까탈스러운 서비스를 어떻게 도출해 낼것인가! 그 방법에 대해서 이야기 하자.
1) 서비스 도출 방법
Process Hierachy
기본 사상은 이렇다.
해당 업무에 대한 메가 프로세스
|-- 프로세스 체인
|--------프로세스
|------- 서비스
|----- 기능
이러한 단계로 접근한다.
언뜻봐도.. 프로세스 적인 접근이다.- 다시말하면 BPM적인 접근이란 것임
왜 서비스를 접근 할때 뜬금없이 BPM적인 접근이냐? 라고 반문하는 사람도 많을 것이다.
2) SOA의 접근방법일반적으로 , SOA를 접근하는 방법에는 두가지다.
Top-Down 방식 과 Bottom-Up방식 (
관련토론)이다.- 아래 그림 참조
Top-Down방식(source:IBM)
Bottom-Up (source:IBM)
그림에서 보시면 아시겠지만..
1)Top-Down 방식은 Business Process에서 부터 접근을 하고, 2)Bottom-Up방식은 존재하는 중요 어플리케이션에서부터 출발을 한다.
다시 이야기 하자면 1) 번 방식은 비즈니스 현황 분석을 통해서 하위의 서비스로 접근하는 방식이고,
2)번 방식은 존재하는 중요 어플리케이션을 통해 서비스가 될만한 것이 무엇인지 접근하는 방식이다.
여기서, 1편에서 언급했던 CBD에 대한 기억이 떠오른다.
2001년 한참 CBD기반 프로젝트를 하던중 "Component Size에 대한 이슈"
- 도대체 어디까지 컴포넌트로 봐야하는거야?
- 이거 컴포넌트가 너무 작은거 아냐? 또는 너무 큰거아냐?
- 적당한 사이즈로 가야지...!
만일 Service도 중요 어플리케이션을 서비스의 대상으로 삼고 접근한다면... 위의 예와 같은 문제에 봉착할 것이다.
여기서 다시한번 상기하자!
SOA의 목표를!! "비즈니스에 대한 IT의 민첩성을 증대하는것!"
SOA의 필요성
필자는
BPM은 SOA를 가능하게 하는 Key Solution이라는 생각이다.
BPM과 SOA의 관계
<출처 :IBM>
4) Summary
최근 기업은 다품종 소량생산이라는 변화 속에서 고객 Needs에 맞도록 비즈니스가 변화해야하는 과제를 안고있다. 이와 같은 기업환경은 IT에게도 비즈니스에 따른 변화를 요구하고 있다.
기업은 주기적인 신제품을 출시해야하고, 사용자 트랜드의 변화에 대응할수 있는 상품을 출시해야한다.
기업 업무가 IT 기반으로 이루어 짐으로 IT가 대응해주지 못하면 변화된 비즈니스를 창출 할 수 없는것이 현실이다.
또한 변경된 비즈니스에 대해서 최적화되었는지?
비즈니스가 변경됨에 따라 어떤 이득이 있었는지?
비즈니스가 앞으로 어떻게 변화 될 것인지?
등에 대한 평가 및 예측이 가능해야 할 것이다.
이러한 부분을 Architecture 만으로 극복해 낼 수는 없을 것이다.
BPM을 통해 분석과 예측이 가능한 시스템으로 진화 해야 할 것이다.
따라서, 필자는 위의 1,2 번에서 언급했던것 처럼 SOA의 접근은 프로세스 기반으로 접근해야 한다라고 생각한다.
결국 ," BPM Based SOA"만이 비즈니스에 대한 IT의 적절한 대안이 될것이다.
