Requires Free Membership to View
|  | ||||||||||||||||
| |||||||||||||||||
Where you start from is important, says Steve Jones, a CTO at consultancy CapGemini in the U.K. Out-of-the-gate understanding of the roles of services and process steps is part of that. Jones suggests starting with a SOA-oriented approach. But the tenor of that approach is key. If it is utterly technology-centric, the BPM-SOA project is likely to stumble. Jones encourages a SOA approach that is grounded in business understanding.
''SOA for us is a business thing,'' said Jones. ''It is a way of modeling the business, thinking about the business and understanding the business.''
On one level, there are similarities to BPM and SOA approaches.
''If you think about an organization at its highest level, whether you are looking at high-level BPM models or at a services methodology, you actually end up with the same bundles.''
A business-oriented approach to SOA can help BPM, suggested Jones.
''Using SOA as we do—as an architecture and business modeling approach—helps bridge the gap between traditional business process modeling and technology delivery,'' he said.
 |
||||
|
|
|||
|
||||
Said Jones, ''Where SOA becomes really required is where BPM has a number of steps. We would say that it is the service that is always the 'grown' in the relationship. It contains the processes - the capabilities that need to be delivered.''
It is BPM's job to build process steps; it is the service model's job to access them, he indicated.
In short, in Jones' view: ''SOA makes really, really good BPM. But BPM bakes really bad SOA.''
Join the conversationComment
Share
Comments
Results
Contribute to the conversation