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.
-1-
Print this article
Email this article
Talk Back!
Write to Editor
