"Business process management could be implemented without SOA, because both capabilities have been available for some time. But implementations of BPM without the SOA foundation take longer. There's more ongoing maintenance and support costs are higher, and therefore ROI is delayed. An analogy of doing BPM without an SOA foundation would be like a juggler with one hand tied behind his back. He can still do some juggling, but not as effectively and not as fast as it could be."
In his keynote address for the SOA in Action online conference, Forrester's Ken Vollmer connected the dots between BPM and SOA. Only lately have the two approaches been converging, and Vollmer said the time is ripe to begin pursuing combined BPM-SOA approaches to increase the flexibility of business processes. (Replay is available here.)
"SOA provides a more standards-based approach of doing BPM," Vollmer said in his address. First, the notations that come out of the initial modeling process can be exported into standards such as business process execution language (BPEL), "which then, in the form of XML, can be executed inside the execution engine," he explained. Then, foundational standards such as SOAP, WSDL and UDDI "support the interaction between the business applications and the modeling tools. If these standards did not exist, the model-driven development in the BPM tools would not be possible."
Vollmer observes that while BPM suites were originally developed to support integration and process improvements, "once these tools were installed inside of organizations, it quickly became clear that they were very good for supporting service oriented architecture, and composite application development."
Another emerging link between SOA and BPM is SOA repositories, "which will reside in the back of BPM tools," Vollmer predicted. Such repositories "will be able to store a number of interfaces or artifacts related to applications, interface specifications and code, processing policies and security issues, process flows, and semantic data links -- all stored inside a repository or more likely in a set of federated repositories."
These repositories can be employed to "provide the business analyst with a view of the modeling stage of the things they need to see, the service developer with a separate role of the things they need to see, and a service architect view. In effect, the SOA repository will provide different views for different roles in the development cycle, all coordinated through the service repository. This will help keep all of the different roles in sync as to what's going on, because a change made in one view will be reflected in other views as appropriate."
Leave a comment