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.
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.
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.
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:
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:
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.
There are no products in your shopping cart.
0 Items |
|