By definition BPM is process driven. In contrast SOA has multiple drivers. In the initial stages of SOA adoption it is most likely to be driven by utility, core business (entity, resource or data) and capability (functional) services. These types of service form the backbone of enterprise computing capability and are the stable layers that underpin the more agile process services that enable rapid response to business change.

These stable layers have two distinct business justifications.

1. They form a façade hiding the existing and legacy applications, enabling rationalization of the underlying mess and radical reduction in complexity. I generally argue that the rationalization strategy is a primary contributor to increased business agility solely because of the reduction in complexity.
2. Creating consistent services that implement appropriate levels of consistent business data and rules which can then be customized and assembled into LOB specific business process solutions.

A sensible way to look at this is to think of supply and demand. BPM creates demand for process services. SOA provides the supply. The direct convergence happens only at the process service layer whereas the demand relationship to the underlying layer is much more complex, involving questions of requirement for standardization, commoditization, specialization and innovation.

I recently had a conversation with a representative of a company heavily involved in the SAP ecosystem. He asserted that the SOA Roadmap that I had just presented was incorrect because it should have subsumed BPM and SOA concerns. Initially we talked at cross purposes until I realized that in the SAP world it might be assumed that many customers would only be service consumers. And in this case I accept that there could be considerable integration of the SOA and BPM efforts because service consumers may be happy to delegate the lower service architecture layers to a third party application provider.

But even if the enterprise is fully committed to a single application service provider, and such enterprises are extremely rare, it would be highly dangerous in my opinion to blindly outsource entire architectural control for major domains to a third party. At a minimum the enterprise should establish a SOA strategy that forms a policy led basis for acquisition – in other words understanding the implications for business agility of only being concerned with the process services that will encapsulate all other layers, and remove individual enterprise discretion.

The relationship between BPM and SOA is a complex relationship. In contrast to SOA, BPM will often be involved with very specific business perspectives that are orthogonal to the SOA perspective. The mapping between the process and other service layers will often be many to many and the demand supply process must resolve these (conflicts). These conflicts will involve time, data and business rule consistency, change management policy, specialization and standardization and many others. It will therefore be important to ensure there is a consistent meta model for governance spanning BPM and SOA. But a common meta model doesn't mean convergence (def: tendency to become similar in same environment, join - Concise Oxford Dictionary).

So my thinking is that the idea of fully mature convergence as discussed by Gartner is a highly questionable assumption. The intelligent enterprise will look for intelligent collaboration with BPM activity establishing demand and the SOA activity delivering the supply of services within a common governance model.