I was having a Twitter conversation with Brenda Michelson (@bmichelson) and Todd Biske (@toddbiske) about the tight coupling in peoples minds between BPM and SOA, and why I find that when people take a BPM centric approach to SOA, it usually ends up not delivering the goods.  So today’s post is about how to properly layer your SOA to include BPM while still yielding all the flexibility and reuse that is the promise of a well done SOA.

For this discussion I will build on the terminology defined in the post entitled “Anatomy of a Service Oriented Architecture”.  I will also use 2 simplified application examples to illustrate some of the pitfalls.

So here is our base example.  Imagine that you need to build  a very simplified Point of Sale System.  It needs to be able to log people in, update customer records and perform a transaction, including updating inventory.  For the sake of argument, I will propose it should look something like this (not 100% accurate but best I could do in 20 minutes).  Sorry the pictures are a bit hard to read.  I need to change templates to get something wider.

Furthermore, I will contend that people following a BPM centric approach to SOA are usually likely to design it like this:

and that too often with SOA design we see something like this (which is really bad)

So lets look at these starting from the bottom one which, sad to say represents about 75+% of “SOA” implementations I tend to see.

Point of Sale – Badly Done Case:
This last example is what you get when people decide they need to be SOA, but frankly have no idea how to decompose a problem or do component based design.  It is also what you get when people decide SOA means you just slap a web service interface onto a monolithic legacy app so you can call it SOA to please senior management who have heard all the buzz, and decided they just have to have an SOA by next week to save cost, etc.  This approach buys the company absolutely nothing and in fact only slows down the performance of the existing system and certainly provides no flexibility and reuse at all.

Point of Sale BPM Centric Case:
In the BPM case we will have identified our main processes:

1. Customer Lookups, etc
2. Authenticating a User
3. Processing a Transaction

We would then set about to design service interfaces which align to those and they would look something like this:

1. Customer Service:

1.1 Create Customer
1.2 Update Customer
1.3 Lookup Customer
2. Authentication:

2.1 Create User
2.1 Update User
2.3 Delete User
2.4 Login
3. Transaction:

3.1 Record Transaction
3.2 Void Transaction

Each of those service interfaces more often than not end up being tightly coupled to a back end database which exposes stored procedures which are also tightly aligned to those process services. Its basically a client server design behind the service interfaces, and while I drew them as 3 separate databases supporting each service,  more often then not I will see no decoupling under the covers and it will be one big database.
Now, in this case we have a better design (but still not good) which shows some process orientation and some componentization. This design will offer some reuse, albeit limited.  In addition this system will suffer from some data duplication (consider Paul Michaud as User and Paul Michaud as Customer.  This design would store the records twice for Paul Michaud) which is not desirable in a good SOA.

Point of Sale – Layered Case:
I will contend that this design is optimal (or at least as optimal as I could draw in 20 minutes).  It provides for the same level of BPM support,  but does not require any data duplication and allows for the maximum reuse.  I am not going to go into details on how one would come up with this design in this post but I will come back to that in another post soon.

To prove the point, lets now consider the need to create a second application to do simple contact management.  We would ideally like to reuse our SOA and layer the new application on top of what we already built.  I will contend that for this second application only the layered design would offer any reusable components for this second application.  I will propose the following simple design for the Contact Management Application using SOA.

Contact Management:

Notice that we are using the party service not a Customer Service or anything else.  A contact may be a Company, Organization, Church, Personal friend, etc.  If we had only build Customer Services as in design 2 & 3, which is what the BPM approach would have identified we would not have had a foundation on which to build this second application (unless that second application was very similar to the first one).

Anyhow,  the point is that by focusing on the process we usually fail to identify the necessary Foundation Services or the Fundamental Data Objects on which the SOA should be operating.  I will elaborate on this further in a later post.

As always feel free to leave comments here or on Twitter.com (@techmusings).