By now, youve likely grown jaded to the cliché that the nice thing
about standards is that there are so many of them to choose from. Today, a more
appropriate statement would say something like, the more standards, the less standardization.
Such an argument could be made for the proliferation of WS-standards that has
helped web services technology mature into precisely the same kind of bifurcation
that has afflicted Java. There are the building blocks that everybody supports,
and then there is WS-everything else. No wonder there is a WS-I in place to
define interoperability tests for the building blocks that are supposedly not
in question.
So in spite of the noise, and the fact that of course, there will be separate
but equal camps for things like federated identity, a consensus has emerged
that web services are the protocols where vendors will theoretically pay more
than lip service to interoperability. If you had any doubts, just look at what
the BPM community is up to.
Traditionally BPM vendors competed on their ability to abstract higher level
business processes from the programmatic logic that comprised software applications.
Much of the value-add was in the modeling language and environment, which was
typically proprietary. Excluding XPDL, which originated from the document workflow
world, there was nothing in the way of standards until the BPMN modeling notation
materialized several years ago (more about that in a moment).
When it came to execution, processes modeled through BPM were typically exposed
through generation of C++, and later, Java or .NET code, and integrated through
use of adapters. With emergence of web services, BPM vendors began using the
basic WS- standards, both for exposing their own processes and for replacing
proprietary integration adapters. In some ways, this reminds us of classic 4GLs,
where the programming language and visual design environment was proprietary,
but execution leveraged various de facto standards (typically dialects of SQL,
or more generic ODBC/JDBC).
As we noted several weeks back, theres a growing tendency for BPM vendors
to ace out the code generation piece entirely. The obvious benefit is that you
streamline the process by eliminating a step. In this case, you dispense with
the need to continually sync code with the process model, which is one way to
avoid bugs, discrepancies, or in extreme cases, potential compliance issues.
You may also change the roles that software developers play, but even if you
dispense with code generation, theres still software involved, and with
it, software developers.
A plethora of companies are still employing completely ad hoc, document-centric processes, many of which are central to day-to-day operations. To...Learn More