The relationship between BPM and SOA is not a simple one.

Several key variables determine which path is appropriate for your situation–and like many SOA situations, there’s no cookie cutter answer.

I’m tempted to try to clarify my position on this topic because of Joe McKendrick’s piece:
The awkward dance between BPM and SOA

Like the mating dance of the Sand Hill Crane, this dance looks a bit gawky but serves a very real purpose. To the untrained eye, the movements seem awkward. However, this dance has a very ancient logic. Unlike the crane’s mating dance though, the topic isnt about reproduction. It’s about money. In the words of Cyndi Lauper, Money Changes Everything.

How does money influence this relationship? Through the funding vehicle for SOA projects. Increasingly, BPM is used as the funding vehicle for SOA projects. This makes sense because SOA by itself is pretty much by itself pretty invisible to the business. It’s like doing a bathroom remodel to justify new plumbing. Now having new plumbing may in the future allow you to do a kitchen remodel. But the plumbing by itself doesnt really provide the business with much justification for the cost up front.

BPM is just one of many different “Consumption Patterns” for SOA’s business services. You can connect business services to Web 2.0, AJAX and other kinds of front ends. You can consume them using portlets. You can wire up SOA business services in a B2B fashion or maybe build using a variety of composite application or mashup tools.

But it’s a pretty strong argument for SOA and can help get your SOA funded.

I fully agree with Steve, the “bazaar” of business process does tend to mess with the “cathedral” of SOA, and that the “percolating process” antipattern *is* alive and well.

However, this is a pretty small price to pay for getting your SOA project funded. Not every single service you make for a BPM process will be reusable, that’s for certain. But you can segment these into various registry repository taxonomies and you can use the funding to put in infrastructure that will scale to enterprise level.

You see, the cool thing is that BPM is typically project funded. This means that within a given enterprise, you have a considerable lot of BPM projects, whether it be supply chain logistics, order to cash, some cool RFID project, call center, there are hundreds of processes that can be optimized. Optimizing a process leads to clear ROI and you can justify spending millions of dollars for the resulting improvement to the business.

So if you can link your SOA infrastructure to one of these projects, you can get components like Registry Repository and runtime policy mediation systems that have Enterprise wide implications. This can create significant value over time and across projects.

This logic doesnt apply to the so-called “ESB”, I’ve only seen the “ESB” be valid within a project, not so much across projects or across silos of ownership or operations.

In conclusion, the BPM stuff may mess you up a little on your project–but they might also foot the bill! So dont be afraid to get your hands a little dirty, after all, hands can be washed and you don’t want to sit this one out. Careers are being made on SOA right now and if BPM is attractive to your business, you should let them know that a bathroom remodel might be a perfect time to do some plumbing work and get your SOA funded alongside.

Happy SOA-ing
Miko