<<The combination of Business Process Management (BPM) and
Service-Oriented Architecture (SOA) has been the subject of a great many
magazine column inches and conversations in the past couple of years.
Most commonly, the relationship is seen primarily as one of technical
complements -- where BPM is seen as a way to make it easier to create
composite applications from services, and SOA is seen as a way to make
it easier to integrate automated processes with existing applications,
systems and data sources. However this is only one small part of the
picture, and it forces both BPM and SOA into playing purely technical,
application development related roles.
*/How did we get here?/*
It's important to see how we got to where we are today -- where most
people think of BPM and SOA primarily as complementary technology-driven
concepts. There are three factors that have conspired to push the BPM +
SOA equation into industry consciousness, and all of them have been
driven by IT suppliers:
1. *The adoption of BPEL within mainstream software products.* Through
2004-05, the suppliers selling new middleware products aimed at
customers pursuing SOA initiatives started to offer orchestration
engines that could be used to wire together Web services to create
multi-step logic flows spanning multiple external services. These
engines implemented a standard called BPEL, or Business Process
Execution Language to provide that orchestration. This overloaded use of
"Business Process" terminology caused many commentators to blend and
confuse the topics of SOA and BPM.
2. *Software suppliers with products that appealed to technology buyers,
looking for ways to sell to business leaders.* Many of these same
suppliers were motivated to perpetuate any confusion in the market,
because they were keen to find ways to sell their products not only to
their traditional technology buyer audiences (Architects, Project
Managers, etc) but also to business buyers. Branding their new
technology capabilities as "BPM" was seen as a great way to get a foot
in the door, because BPM had already gained a foothold as a line of
business investment for many large organisations.
3. *BPM technology products making use of Web services.* At the same
time, a group of startup software suppliers was selling a new type of
software platform built specially for BPM initiatives, which came to be
known as the Business Process Management System (BPMS) -- designed to
not only help organisations model processes, but also translate these
models into working systems that could then be easily monitored and
optimised in a "closed-loop" fashion. These suppliers entered the market
just as interest in SOA was spreading rapidly, and as the initial Web
services technical standards work in the SOA area was starting to become
widely recognised. It made sense for these vendors to piggy-back on the
new Web services protocols as a way to make their products "open" for
customers to integrate new automated processes with existing back-end
applications, systems and data sources.
*/BPM and SOA: ships that pass in the night/*
In fact, though, what's interesting is that when we interview managers
from both business and IT departments in an organisation we commonly see
a very different picture which can be summed up as follows:
* *SOA is IT-driven.* From the perspective of SOA, BPM is seen
primarily as a separate modelling and analysis exercise carried
out by business analysts that has little direct impact on the way
that things get done in practice.
* *BPM is business-driven.* From the perspective of BPM, if SOA is
understood at all it is seen as a small part of the technical
implementation landscape for processes that IT staff will "figure
out".
*/Missed opportunities/*
At first glance it might look like there's nothing wrong with having BPM
and SOA initiatives that are disconnected in this way. However there are
negative implications for both BPM and SOA initiatives in situations
like this, particularly for organisations that aspire to implement BPM
and/or SOA more broadly than across just one or two projects. Here are
three examples:
* *Failure to leverage "integration services" effectively in BPM
implementations.* One of the supposed benefits of using Web
services comes from the opportunity for service reuse. But if
integration services in BPM initiatives are being specified and
created purely within the context of individual process
implementations, without any architectural (i.e. cross-project)
oversight, there's no guarantee that the resulting services will
be reusable in any real-world sense. SOA, done right, will improve
consistency and reusability of integration services across BPM
projects.
* *Failure to consider opportunities for process reuse.* It's
straightforward to take a process implementation and expose it to
the "outside world" as a reusable, standards-based software
service -- many BPM tools provide automated functionality to do
this for you. But (as is the case when considering integration
requirements) if you drive the creation of "process services"
solely from the BPM implementation environment without considering
the broader business/IT landscape, who's to say that the resulting
services will deliver optimal value? Any working SOA initiative
should be able to provide valuable input here.
* *Failure to capitalise on information architecture value.* Within
SOA implementations, the definition of "common information models"
is crucial to minimising the amount of translation of information
flows that has to be performed when services are being combined
and re-combined in different environments. If process
implementations are to be reused (as described above), the same
requirement holds within BPM initiatives, too. But apart from
that, it makes sense to enable individual BPM project teams to be
able to reuse or import standard information definitions. Defining
process information within the context of individual projects is
fine when you're only pursuing one or two isolated projects, but
when BPM starts to be "part of the way we do things around here"
you need to be able to guarantee that processes are going to work
with commonly-defined definitions of business information entities
like customers, orders, invoices, deliveries, products and so on.
/*Creating a "service context" for processes*/
There's another, but less obvious, way in which the combination of BPM
and SOA can deliver increased value: SOA, when considered holistically
in the context of business architecture as well as technology
architecture, can provide a consistent framework in which to explore and
define process KPIs.
In a business architecture driven approach to SOA, a portfolio of
services isn't created by solely focusing on how existing software
applications and resources can be more effectively exposed to be reused.
An equally important starting-point is an understanding of the
high-level business service commitments that an organisation makes to
external parties (related to the ordering and delivery of products,
resolution of problems, or filing of financial statements, for example).
Service models acting at different levels of granularity and abstraction
decompose these top-level business service commitments, and inform
requirements for service commitments at different levels within an
organisation and its systems.
Today, these service-level commitments for processes are most often
explored and analysed within individual BPM projects, rather than within
broader initiatives that span multiple processes and projects. If you
drive the specification of KPIs and SLAs for processes solely from
within the scope of individual BPM projects, without considering the
broader landscape of the organisation's business model and service
commitments, who's to say that the KPIs and SLAs are really aimed at
measuring what's important: the business service commitments to external
parties?
A holistic approach to SOA which considers top-down service level
commitments as well as bottom-up system development and integration
requirements can, and should, inform business process modelling
initiatives to ensure a consistent set of business-meaningful service
level commitments.
In summary: when you look at how to combine BPM and SOA initiatives,
don't just focus on the obvious integration-enablement aspects. If you
broaden your view to see how BPM and SOA fit into the broader
perspective of Business Architecture, more profound relationships and
opportunities will become apparent.>>
You can find this at:
http://www.soainstitute.org/articles/article/article/bringing-bpm-and-soa-together-for-maximum-business-value.html
Gervas
