Terry Schurter, chief analyst with BPMG.org,offers some interesting food for thought in a recent piece at BPM Today.
Written by Britton Manasco, Contributor

Terry Schurter, chief analyst with BPMG.org,offers some interesting food for thought in a recent piece at BPM Today. He leaves us to wonder what will ultimately become the dominantconcept in our hierarchy ofinvestment priorities. Will it be "service" or"process"? It's anybody's guess at this point. Why?

"Because 'process' can be substituted for 'service,' an SOA also can be described as a 'process oriented architecture.' This is a more accurate term for describing the technical aspects of the architecture than is 'service,'" explains Schurter."The term 'service' is used primarily to emphasize the point that one of the main goals of an SOA is the ability to switch software, Web and business functions in and out of the I.T. infrastructure with ease...However, because the services of an SOA are indeed processes, this blurs the lines between BPM and SOA. Are they at all similar? Are the processes referenced by BPM and SOA the same processes -- or is this simply a matter of semantics?"

Terry thinks not. "It turns out that what BPM terms as 'processes' is, in reality, a superset of the 'services' concept of SOA. Business and functional processes are often services, too, although even these groups have an expanded scope beyond the boundaries of SOA. Enterprise processes that are essential to BPM do not translate into services under the SOA design....Yet, there are substantial differences between SOA and BPM -- differences that can have broad-ranging effects on the organizations that deploy them. SOA addresses the technology need for agility and adaptability, while BPM addresses both the business and the technology needs."

Another difference?"SOA remains a design concept, while there is a broad market offering of BPM software products," he adds."On the one hand, we have design concepts that can be a guide for the software development of an SOA by organizations using a variety of technologies and approaches. On the other, is a product that needs only to be configured."

Schurter goes on to advocate BPM software as "the best choice for the backbone of the organization's SOA. With workflow, simplified integration, business rules and design aids, there is little effort required to configure desired SOA functions into the BPM software...Further, because BPM already is designed to provide the additional services of real-time monitoring, reporting, analysis and optimization, it is much easier to manage deployed services and to evaluate their integration and performance. Couple this advantage with the capability to take action on the business front, which is unique to BPM, and the case for using BPM software for SOA becomes very difficult to contest."

Editorial standards