A technology that has gained increased attention in recent years, business process management (BPM), is starting to look a lot like another technology gaining momentum, service-oriented architecture (SOA). And this similarity is leading some CIOs to apply the techniques in concert, using SOA approaches as the delivery platform and BPM approaches as the “business smarts” platform.
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 can’t 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 SOA—messaging 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.
That’s 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 Synovus’s 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 it’s 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. That’s 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 that’s 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 they’ll 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, I’ll get to connecting A-to-C-to-B as a configuration change,” he said.