The
SOA Marketplace
Software leaders provide their perspective
on developments in the services-oriented architecture space and how it will
impact the industry.
The
Future of BPM and SOATony Baer
Sep. 04, 2007
There
appears to be consensus there is synergy between BPM and SOA: promoting process
agility is entirely consistent with SOA’s loose
coupling. And, it seems to be a no-brainer to expose processes as web
services to take advantage of all the standards-based integration. Not
surprisingly, you’d be hard pressed today to find a BPM tool that doesn’t expose
processes as web services.
Yet beneath the surface a deep cultural war continues to rage. It’s the latest
manifestation of the cultural divide between business and IT. In
this instance, it’s the business view of
business processes vs. the IT view. In this instance, it’s a matter of
reconciling who makes the architectural decisions for integrating business
processes.
Business stakeholders, comprising process owners or architects, managers, or
staff level down in the trenches, claim to be more
intimately acquainted with the subtleties of business processes than those in
IT, who develop software to automate it. Conversely, the IT side contends that
business stakeholders have little idea on how processes are supposed to execute
in the data center.
Not surprisingly, the debate spills over when it comes to the merits of BPEL.
Business stakeholders claim that, as an execution language, BPEL is ill suited
for handling the nuances of a business process. It doesn’t directly support
core process artifacts like parallel swim lanes, or adequately represent highly
recursive decision loops. By contrast, the IT folks contend that, as a
standard, BPEL is an ideal environment for defining what actually executes at
run time.
In essence, the argument boils down to what kind of language to use for
defining business processes: Java (or C#), which can be generated by BPM tools,
or XML, which is the lingua franca for BPEL. Against this backdrop, it
shouldn’t be surprising that recent proposals by IBM, BEA, SAP, Oracle, Adobe,
and Active endpoints to extend BPEL to human workflows have exacerbated, rather
than patched the great divide, given that BPM pure plays such as Lombardi, Savvion, Metastorm, and Pegasystems were not part of the loop.
What’s interesting is that when it comes to deploying SOA, similar cultural
divides rear their ugly heads when it comes to SOA teams and enterprise
architects. The folks implementing SOA projects are perceived as estranged from
the enterprise architects who are supposed to (depending on the organization)
enforce or promote technology standards and best practices across the
enterprise. And they are seen as equally estranged from the domain experts and
process owners in the business that manage business processes. Regardless of
whether you are an EA or business analyst, chances are, you view SOA developers
as just the latest generation of cowboy programmer.
In the case of EA, it’s that programmers make de facto architectural choices in
delivering projects that could wreak havoc down the road when it comes to
reusability, maintainability, or the accountability with enterprise compliance
policies. According to eBizQ analyst Beth
Gold-Bernstein, most web services being exposed today are
rudimentary data services that in many cases are conventional remote procedure
calls (RPCs) with web service interfaces that are SOA
in name only.
Adding insult to injury, SOA developers are accused of unleashing web services
with scant awareness of the subtleties of the business process(es) that they are exposing.
Of course, it’s easy to dump on developers because they are the poor folks down
on the front lines who actually must deliver tangible results for sponsors who
are rightly concerned about their own projects. And lacking the right funding
mechanism, project sponsors are not exactly willing to bear the costs alone of
generalizing their solutions for the rest of the enterprise. Although it might
be reasonable to expect developers to observe enterprise architectural
standards, you can’t knock them for failing to develop reusable assets if
nobody’s going to pay the necessary surtax.
It’s ironic – although not terribly surprising – that these new approaches to
enterprise integration are not exactly integrating stakeholder factions across
the enterprise. Integration is just too strategic to trust the other guy to
drive it. Are there any signs that on this go round, the impasse might finally
resolve?
Keynoting the recent Open Group’s Enterprise
Architecture Practitioner’s Conference, colleague David
Linthicum made a bold prediction: that in five years, SOA
would get absorbed into the discipline of Enterprise Architecture within five
years. Participating in a panel lead by analyst Dana Gardner,
we came to a surprising consensus: yes, SOA should become a function of
Enterprise Architecture, but no, predicting such grand unification within 5
years was a bit optimistic.
But a couple days later, at OMG’s BPM Think Tank, Brenda Michelson,
who coordinates the SOA Consortium (a
place where CIOs share SOA best practices), told us a
real-life tale whose moral was that maybe there’s hope. The resident SOA geek
at a particular company, who initially spoke only web services speak, spent
roughly a year immersing himself in the business.
Today that SOA architect speaks the vocabulary of the business, and has become
someone whose advice is valued by the very people who formerly shunned him.
Tony Baer, principal of onStrategies,
is a well-published IT analyst with over 15 years background studying
implementation issues in enterprise systems, application development, data
management, and business intelligence. Baer's commentaries and rants on the
state of the IT market are available here.