Did we sail these waters before?
Addressing the question posed in Part I: Is the BPM/SOA approach at its core different from other methodologies that have already been employed to bridge the business-IT gap?

There are several categories of main-stream system development methodologies from traditional-structured (prevailing in the 70s and sometimes called waterfall methods) through object-oriented and iterative methods (developed in 80s and 90s to replace the former) to modern agile modelling (‘configurable’ methods targeting the project needs) and extreme programming technics. The methodology metamodel aimed to provide an open standard for defining any (business or IT) system development methodology can be found here.

The common characteristic of all system development methodologies is that they are deeply rooted in the IT side of the spectrum and have typically evolved from modelling static and dynamic aspects of programming code and data structures. Therefore, even after being extended to address the needs of business modelling and analysis they do not resonate well with business community and none of them has been widely accepted for the purpose.

On the other side, the business camp has come up with its own modelling techniques and analysis methods which in their opinion are much better and usually simpler representation of the business reality at different levels analysed (from enterprise strategy down to a single job task).

Even though the disconnect between the two sides is obvious, the problem has been floating in dead waters for too long a time with neither side seriously willing to address it. It has been assumed that the transformation from the business to IT side-approach in the course of the project flow somehow occurs somewhere under the surface usually when business analysts hand over their view of the world (typically in the form of more or less elaborate business requirements) to IT developers for design and implementation.

In the case of a small team (e.g. extreme programming techniques that recommend business and programming experts working in pairs), this approach may work just fine, but in modern, global development environment with team members dispersed across different locations and sometimes speaking different languages, expecting this kind of metamorphosis is nothing short of wishing for a miracle to happen at the right time and different places yet in the same manner. Therefore, any mature development methodology has defined a mean to handle the business-IT transformation in its fully defined development life-cycle.