BPM on SOA Explained at Last!

Here it is:
BPM suites (like BEA's AquaLogic BPM Suite) can enable easy access to applications and databases using various techniques, service-oriented or not. The implementation ... is derived from and dependent on the underlying system interfaces and thus, any change to underlying databases and applications will require changes to the business process.
This is fine if the organization and IT environment are reasonable small and the same group of people control all systems including the BPM suite. It also works well if the underlying systems do not change at all. But if the BPM suite is deployed by one group and it consumes services from systems in another group, then it can quickly become hard to coordinate and manage change within each group. This is the classical problem that SOA was meant to address and thus, it applies to the deployment of a BPM suite as it does to everything else.
If BPM is deployed as part of SOA, it means that when a business process connects to underlying systems, it connects to proxy services provided by an enterprise service bus that hides the complexity of the underlying applications and databases.
At last! A concrete statement on the subject that makes sense! It's even the way I thought it was supposed to work. He goes on to list the benefits of this approach:
  • Easier for IT to expose coarse-grained services this way, and easier for business people to understand and orchestrate them.
  • Process "more robust" because decoupled from changes in the backend systems.
  • Allows service governance/maintenance outside of the BPMS. He implies (but doesn't outright say) that IT owns the services, and business owns the processes.
  • Better discovery through enterprise registry.
He's very careful to say BPM doesn't need this until it reaches a certain level of "maturity" (i.e. widescale adoption) within the enterprise. Jesper, thanks for a great post on a subject nobody else seems to understand! Dude, you're on my blogroll.

But taking it another step... What would a BPMS design tool that worked this way look like? Seems to me that the orchestration should reference those implementation-independent service interfaces using some canonical data model, leaving all those messy service endpoint mappings to the ESB and service architects, instead of introspecting the endpoints directly the way all BPMS's (including Fuego 5.5, I mean Aqualogic BPM) do today. Jesper, does that make sense to you?