Choosing between BPM and SOA is akin to the chicken and the egg debate. Without defined business processes, enterprises can't create reusable services for the business, and without a services layer, business processes can't easily be made reusable.
So which should come first?
The short answer is both -- meaning organizations should define business processes and create a service-oriented architecture (SOA) in tandem. "Those doing larger deployments of [BPM tools] are learning that they have to really create a services layer at the same time they create processes," said Janelle Hill, business process management (BPM) analyst at Gartner Inc. in Stamford, Conn.
If developers create services without understanding the business context of those services, they end up creating the wrong services, and if business analysts want to automate processes without any services exposed, processes are harder to build and inflexible, she said.
A case in point is a large insurance company that defined its processes using a BPM tool, writing code for a single BPM system environment. "Everything was great until three years later, when their marketplace changed completely and they weren't able to modify their processes without breaking the system," said Aleks Buterman, founding partner of IT and business management consulting firm SenseAgility LLC and former chief architect at Lincoln Financial Group and Allstate.
The insurance firm had hard-coded its business rules within its business processes and, thus, couldn't change them -- a big problem when new regulations or business practices, such as rules for approving or denying credit, come along, Buterman said. In fact, that could be an issue for lenders facing credit card rule changes that would crack down on deceptive interest rate hikes and harsh penalties for late payments.
To avoid such a hard-coded business rules situation, companies should separate business rules management from their BPM tools. A services layer, or SOA, is an ideal place for storing and more easily modifying rules and creating reusable components and services, Buterman said.
At the same time, rather than building a process to be used across every business unit inside a BPM tool, IT should expose this process as a service with a common interface that all units can use, he said.
"Common processes have to be set aside as services to be reused elsewhere. Without that, you won't achieve optimal BPM ROI," Buterman said.
BPM and SOA convergence among vendors
BPM vendors have been converging BPM and SOA for some time. Integration-centric BPM suite (IC-BPMS) vendors have built deep support for SOA into their core integration servers. Human-centric and document-centric BPM vendors support the creation and consumption of services, although they don't have built-in SOA features such as an enterprise service bus or a SOA repository, said Ken Vollmer, an analyst at Forrester Research Inc. in Cambridge, Mass.
Examples of IC-BPMS vendors are Vitria Technology Inc., Tibco Software Inc., Oracle Corp., IBM, Software AG, SAP AG, Microsoft, Sterling Commerce and Sun Microsystems Inc. These types of vendors often provide a combination of BPM, business event monitoring, business activity monitoring, integration architecture, SOA and composition framework capabilities.
Savvion Inc., Lombardi Software Inc., Tibco, BEA Systems Inc. and Software AG are a few human-centric BPM vendors that have suites that help businesses manage and automate procedures and tasks performed by employees.
SOA vendors -- the major players being IBM, Oracle, Microsoft, SAP, Sun and BEA -- also have a strong presence in the BPM suite (BPMS) tools market. Large vendors, particularly IBM and Oracle, would like SOA and BPMS tool sets to completely converge, Hill said. This is not the best approach, however, since users of each tool set have very different roles and responsibilities, she said.
"[Users of these tools] should collaborate and share models but probably don't want to share tools," she said.
Who's driving the BPM and SOA bus?
Indeed, those leading BPM and SOA efforts are typically from different parts of the organization. Developers or enterprise architects could be the driving forces for a SOA initiative, while on the BPM side it could be a business process architecture group or business unit leader.
The CIO, however, is the one capable of bringing these two efforts together. Buterman said he's starting to see more enterprises form technology management offices led by the CIO, versus separate enterprise architecture and business process architecture management offices.
"The CIO needs to make sure services are being used elsewhere [by the business], and if the CIO approaches it from an overall IT governance perspective and they make compensation or budgets dependent on service reuse, that will force people to build something that can be reused," he said.
Let us know what you think about the story; email: Christina Torode, Senior News Writer.