InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Using BPM And SOA To Maximum Business Value

Posted by Dilip Krishnan on Jun 25, 2009

Sections
Process & Practices,
Enterprise Architecture
Topics
Business Process Management ,
SOA ,
Business Process Modeling
Tags
Business Architecture ,
BPEL ,
BPMN

Industry analyst Neil Ward-Dutton writes that the combination of Business Process Management (BPM) and Service-Oriented Architecture (SOA) is seen as technically complementary. There are different views on how the two concepts play together, however, the author maintains that there is enough synergy between them to increase business value.

Neil explores the reasons as to why the idea of BPM and SOA together has the industries predisposed to thinking of them as complementary technologies.

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 […] multi-step logic flows spanning multiple external services engines [and] implemented a standard called Business Process Execution Language (BPEL),  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. Branding their new technology capabilities as “BPM” was seen as a great way to [sell to business users in addition to traditional technology buyers].

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)[…] Interest in SOA was spreading rapidly [and] 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.

He believes that the two are really the result of different perspectives SOA, the bottom-up approach, which is primarily IT driven, and BPM, the top-down approach, which is business driven. He attributes the failure to capitalize on the synergies between the two approaches to the diverging interests of the drivers of the initaitives.

  • Failure to leverage "integration services" effectively in BPM implementations.
  • Failure to consider opportunities for process reuse.
  • 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.

Neil advocates Creating a “service context” for both the business architecture as well as technology architecture while designing the business processes and their supporting services. Service designs that are purely business driven may not be optimal in terms of re-use, efficient use of resources and information. Same goes for completely IT driven services, which may not be especially well designed to participate in an orchestrated business process.

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 […]. 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.

As he had concluded earlier, “the truth is that *outcomes* come first, and services and processes are two sides of the same coin in achieving the right results.", he urges the drivers of these initiatives, to broaden their perspective and design their system holistically that satisfies both IT as well as business need.

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.

  • This article is part of a featured topic series on SOA

No comments

Watch Thread Reply

Educational Content

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.

Beauty Is in the Eye of the Beholder

Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.

Architecting Visa for Massive Scale and Continuous Innovation

John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.

Max Protect: Scalability and Caching at ESPN.com

Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.

The Seven Deadly Sins of Enterprise Agile Adoption

Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.

Questions for an Enterprise Architect

Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?

Wrap Your SQL Head Around Riak MapReduce

Sean Cribbs explains what Map-Reduce and Riak are, why and how to use Map-Reduce with Riak, and how to convert SQL queries into their Map-Reduce equivalents.