The intertwining of SOA and BPM, finally explained

BPM is for designing solutions to business problems, SOA is for automating those solutions.

Where, exactly, does service oriented architecture leave off and business process management begin?

In an very informative chat at last month's IBM Impact conference, IBM Integration Architect Brian Petrini describes the differences and commonalities between these two highly intertwined concepts.

How BPM and SOA differ, and how they overlap:

BPM is top-down: "Business process management is looking top down, defining the business process. So it's usually done by business people. Also, there are key performance indicators that are measured. Most of it is platform independent. So you’re looking at the business value that goes through a process, you’re looking at roles and responsibilities."

SOA springs out of IT: "Traditionally SOA has come up from integration and EAI, and is focused on exposing services from back-end one or multiple systems. There isn't a business context, but certainly there are metrics that are called, either throughput or response time, and those work together. ...In SOA, the IT constructs are going to be there. So, for example, a business may say create an account, and if you have three IT systems that all involved to create an account, you’ll have a flow, but that's an IT flow, rather than a business flow."

SOA involves shorter time frames: "The guidance we generally give is, it is a service if there is an expectation of a command -- for example, cancel order, create account, and you expect a response. Also, its in the timeframe of seconds to minutes.  Whereas if it's a business process, the expectation is hours, days, months. So the time is a big differentiator."

What's similar: "What is very similar is that you have a notation of compositional logic. So maybe I do this first, then I do this other thing, then I make a decision. So the decision may be based on business rules. You’ll see a lot of the same constructs in determining the logic."

BPM can function without SOA in some cases: "Certainly for some processes, [companies] never need to go into SOA. For example, a swivel-chair process, something that's entirely manual right now, they still want to use BPM to manage that. However, as the processes scale, as you expect to reduce headcount, improve quality, the overall time span of a process -- for example, order creation or creation of a new insurance policy -- as you want to reduce that, you would expect to automate some of those steps. And when you need to automate that's where SOA comes in."