VOSibilities

Joe McKendrick has revisited the debate about the relationship of BPM and SOA by commenting on JP Morgenthal’s assertion that SOA and BPM initiatives should be kept separate.

With all due respect to JP, we think he’s got it wrong. BPM and SOA do need to be reconciled.

JP seems to have fallen into a trap that confuses the need to achieve two complimentary goals with the need to combine the initiatives that strive for those goals.

So sure, the initiative to introduce a business process culture into an organization should be separate from an initiative that drives toward a service-oriented architecture, but both initiatives have to be able to succeed. Those that merely view BPM as the killer application that justifies purchasing stacks of “SOA” middleware are missing the key “BPM” value proposition. Conversely, pure-play BPMers risk building impenetrable fortresses of locked in process that can’t be shared/reused.

In JP’s world, the benefits of BPM will not materialize for either the business which is trying to rationalize work or by the architecture groups trying to rationalize infrastructure supporting that work. In order for them both to succeed, any application that is developed with a BPMS must introduce its new functionality as a collection of services.

Implementing “BPM” does not suddenly provide an excuse to intertwine business logic with presentation logic. Reusable services must be created in order for the long-term success of the enterprise and its BPM initiatives. BPM must be inclusive – not a fiefdom.

Workflow, human interaction, reports, event processing — all need to be incorporated in a service-based architecture if we’re ever to get to better business (i.e. BPM) and IT (i.e. infrastructure) alignment. In other words, BPM itself needs to be service-oriented.

Without a major course correction in current BPM-SOA approaches (with BPM as a consumer of services only) the respective visions of BPM and SOA stakeholders will not materialize. A service-oriented BPM has a much better chance of yielding an outcome where BPM and SOA can actually share and deliver on a common vision. Claiming, as JP does, that SOA and BPM “are not – repeat not – related” gives the incorrect impression that people who are creating business processes don’t need to care about SOA and that people creating services don’t need to care about BPM.

Neither is true.