Sum of the Parts: Combining SOA and BPM
Both BPM and SOA require you to map out business processes and figure out how they should interact with each other, with other applications, and with data sources. You cant do SOA without business processes, said Judith Hurwitz, president of the Hurwitz Associates consultancy. Yet many organizations have created an artificial separation by thinking of services as just IT functions and business processes as just business workflow functions.
But BPM should emerge as the central orchestration mechanism for SOA because BPM is inherently process-oriented, while the orchestration mechanism typically used in SOAmessaging via an enterprise service bus (ESB)is not.
BPM is going to be the most important part of SOA in that it lets you combine the services as your needs change. It lets you make end-to-end processes, said Bill Swanton, a research vice president at AMR Research.
Thats the case at Synovus Financial, a financial services conglomerate serving the Southeast U.S. CTO John Woolbright began exploring the SOA concept three years ago, attracted by the ability to be reduce the number of software assets to develop and manage, as well as to be more flexible in providing new services by being able to combine core services rather than re-create them for different variations. But the infrastructure focus of vendors SOA approaches missed something key to Woolbright: the business processes executed by the services.
We start with the business processes and then try to translate the IT tools and techniques to support them, he said.
So Woolbright brought in a BPM tool from Active Endpoints to define and model the business processes, then to act as the orchestration tool to manage the SOA services that execute the processes. Essentially, the BPM tool is the orchestration layer in Synovuss services architecture. We use SOA techniques to get common data and presentation models so we can build applications that execute the business processes.
He also decided not to invest in an enterprise service bus (ESB), a technology platform advocated by most SOA vendors. We already had technology in place for most of the ESB layers, such as security and data translation, and we brought in BPM to be the business orchestration layer, so why replace all that? he asks.
Woolbright was also concerned that the ESB approach to orchestration focuses just on messaging management among services rather than on the business processes themselves. And its those business processes that ultimately any application effort is about, he said.
Furthermore, a BPM tool as the orchestration layer provides greater control and insight over how service execution affects the business processes, Woolbright notes. Thats because the context is about the business processes themselves and the tasks they execute, such as opening a customer account or running a credit check.
Synovus discovered the benefits of SOA and BPM at the same time, so it was able to develop its architecture with both in mind. But thats unusual. Many enterprises have distinct BPM and SOA initiatives in place, and so will need to expect to grow both their SOA and BPM efforts, not just remake their organization in one fell blow. Just as SOA is a long-term goal reached through many steps, so is BPM at the broadest level of deployment, notes Prashanth Ajjampur, vice president of architecture at The Hartford insurance company.
Enterprises will first deploy BPM for self-contained processes, just as many will deploy SOA first within specific projects. And in both cases theyll interact with legacy applications such as ERP and CRM to coordinate processes among them and with other applications. Thus BPM-delivered processes and SOA services will initially link components in predetermined ways, what Ajjampur calls A-to-B-to-C. But if the enterprise has defined an architecture that addresses both its processes and services, it will be able to change the links as needed to support new or changed needs. At some point, Ill get to connecting A-to-C-to-B as a configuration change, he said.Motorola is another enterprise anticipating this SOA-BPM convergence. Weve tied our BPM tool to our system family architecture, which defines the blueprint for our company, said Charles Soto, senior director for enterprise platforms at Motorola. After all, theyre extensions of the same concept: business modularity.
As Synovus, The Hartford, and Motorola have all found, the key is to ensure that the enterprise architecture addresses both business processes and software services, rather than focus on one or the other separately. That broad view is especially needed at enterprises experienced with enterprise application integration (EAI) approaches, which focus exclusively on the interactions of software irrespective of the business processes they serve.
As an architecture approach that centers around the delivery of processes across disparate technical systems, SOA naturally aligns to the IT-integration approach and, if narrowly conceived, will stay in that realm. But the broad SOA approach also naturally aligns to business process coordination, bridging this gap.
With true SOA, you dont have the BPM/EAI dichotomy any more, said Ron Schmelzer, a senior analyst at the ZapThink consultancy.