As outlined in Part III of the series, the vision of BPM/SOA convergence has a flavour of a ‘holy grail’ of application engineering – it promises to keep the two worlds (business and IT) separate yet united by the shared concept of reusable ‘service’ playing the role of the bridge between them (see Part II ). Crusaders with either emblem claim readiness to share their horses on the way forward if not declaring outright victory (especially if they are in the vendor’s regiment).

The more realistically minded come up with lists of requirements needed for the vision to materialise. Conspiracy protagonists allege ‘the other side’ of having a hidden agenda (probably of hijacking their own hidden agenda). Sceptics point out that they have seen it all before.

Bizarre stories begin to emerge and one of them is especially relevant to our topic: at a recent OASIS symposium a panel that included distinguished architects working on standards for SOA was unable to produce a final word on what SOA is (see article). ‘Lack of clarity in defining SOA makes it difficult for software architects to sell it to the business side of their organizations’, said one of the senior panelists.

What is a root cause of this fundamental problem (of defining SOA) that undercuts successful attempts to bridge the business-IT gap? In my opinion, the answer lies in the very concept that SOA is based on – that of Service.

Closer examination of Fig. 1 in Part II showing Service as a transformation (convergence) enabler imbedded into Business Activity reveals that it’s a gross oversimplification of the reality: in fact, the business and IT definitions of Service are divided by several layers of abstraction – the ‘holy grail’ of BPM/SOA convergence simply does not exist in the form presented on the architecture charts and without it crossing the waters separating both sides is a treacherous trip indeed. The question emerging from this discussion is: how should the methodology ‘bridge’ spanning BPM and SOA be designed?

Experience from first SOA projects strongly suggests that none of the existing methodologies, even when enhanced with some new SOA-like concepts, is on its own sufficient to support BPM/SOA convergence paradigm (see article). The simplest approach to start with would be to find a definition of Service that can be used from both business and IT perspectives and serve as a cornerstone of a common language used by both parties. As mentioned earlier the major problem with this approach is that business defines Service as a high level workflow of activities that provides business value to its customer(s), while IT definition is bound by system operation level which is way to granular from the business perspective. Providing a definition of Service that is vague enough to be interpreted as any of the two hardly resolves the problem – some kind of transformation method is needed to match them.