How is Business Process Management related to Service Oriented Architecture?

I'm at a large training conference this week, doing a presentation on my ideas around Middle-out SOA and abstractions in the center.  I got a rare opportunity: a smart consultant pulled me aside and asked me this question:

How is Business Process Management related to Service Oriented Architecture?

The great part about being asked that question is that I had to work to answer it, which tells me that I hadn't spend nearly enough time thinking about the relationship between the two.  The consultant who asked wasn't trying to show me up, nor was he asking for a basic course in SOA.  He had his own ideas, and he wanted a sounding board.

So we stood at a white board and wrote, and drew, and compared models and described ideas.  What we discovered, first and foremost, was this: we both had the same answer.  We had picked up our words from different places, so they were different words, but once we wrote the models up on the whiteboard, the biggest difference was that I drew the SOA stack horizontally while he drew it vertically. 

Turns out, when you dig down, these two activities are twin brothers.  Their parents are the same, and they have many similarities, but the serve different needs in the enterprise.

• Business Process Management is the organization of business capabilities (people, process, technology, and data) so that common mechanisms can be discovered, simplified, and improved.  The result: a simpler, more efficient and more rational portfolio of processes.  This reduces cost and increases business agility.
   
• Service Oriented Architecture is the organization of technical capabilities (activities, events, documents, and data) so that common services can be discovered, simplified, and improved.  The result: a simpler, more efficient and more rational portfolio of services.  This reduces cost and increases business agility.

The similarities are striking because these twin brothers have the same father, data, and the same mother, the business event.  To understand how they relate is to understand their parents.

First, the father: the common data model  

As I have blogged before, we need very little at the "center" in order to make Enterprise Architecture work.  Probably the most important thing we need is a common data model, so that we all know what data we are working with.  Doesn't have to be a big data model.  On the contrary, the common data model should be as slender as possible. 

The common data model should contain ONLY enough information to define the things that must be present to define a business document, to identify the unique key for that document, and to define the relationships with other business documents.  It can be developed over time, with some parts vague (just relationships between data areas) while other parts are tangible (thus allowing it to be developed iteratively, as needed by projects).

To extend this 'family' analogy a bit further: The brother of the data model, and the uncle of our twins, is the business document.

A business document is the collection of data items that are needed to characterize an object used by the business to support the business capabilities.  These are the things the business acts upon: products, services, programs, invoices, orders, shipments, payments, and many more.  Every ERP system vendor understands the concept of the document.  It is at the heart of what they manage.

And then the mother: the business event ontology 

And just as the father of the twins is data, the mother is the business event.

A business event is an event that defines the boundaries between business processes.  At the instant that a business event occurs, a business document changes state. 

If you truly want to create a rational heirarchy of business processes, and you want to look for both commonalities and variations, you have to know where a process starts and where it ends.  Otherwise, you could find yourself comparing a single apple to a grove of apple trees. 

To compare two processes, they must both start with the same starting event and traverse to the same ending event.  We do this in our language when we say "Let's look at the Order to Cash process" meaning "Let's look at the process that begins with the creation of the order (event) and ends with recognition of revenue (event)."  You need the ontology of events.  This is often left out of literature on Business Process Management, because you can diagram a process that spans "from anywhere to anywhere."  That's great, if you want to create a diagram.  But if you want to capture knowledge, and you want to rationalize or simplify processes from around the company, you need these events as your boundaries. 

Marriage of the two

Before you manage the processes, and before you design your services, you need these parents.  They have to have time to grow up and become mature, or their children will have no direction, so get consensus that the data entities are correct and their relationships are correct.  Get consensus that the heirarchy of events is correct and the names of the business documents are consistent.  There is no point in doing BPM if you don't know what your data is, and you don't know what the events are.  The same holds for SOA. 

This is not a top-down design, but it is a top-down constraint.  If you build your SOA before you understand the data, you are creating multiple versions of the truth.  If you attempt BPM before you identify your events, you will burn huge efforts to compare apples to apple trees, producing no value.

Now, let's all sit together and share a meal

Like all brothers, SOA and BPM don't always get along.  They will have different viewpoints of both data and business events.  These two activities are usually performed by different people, in different parts of the organization.  Frequently, the are not connected in any specific way.  Their managers may be different, and their measurable metrics may be different.  Sometimes, they don't even see how closely related they are.  Yet, there is a link, like the link between twin brothers.  An obstacle for one is an obstacle for both, and victory for one directly benefits the other.

Who works to get these two brothers to agree?  The Enterprise Architect does. 

Through both SOA and BPM, we get exceptional value for the enterprise.  Understanding how they are related helps to build the common shared understanding that these two activities need to truly succeed.