The BPM value proposition pays off best in an SOA environment

Untitled Document

Let's be clear. There is really no such thing as SOA BPM. One is a design model; the other is a value proposition. One has been around a lot longer than the other. But they do go together nicely.



Service oriented architecture (SOA) is one way to build information technology (IT) infrastructure. It is the design model that will most likely dominate the IT market through about 2020 because it adds the concept of utility-like computing to the re-use and interoperability promised in earlier IT architectures such as client/server (C/S). But SOA is still just one way of putting your IT assets-physical and logical-together.

Business process management (BPM), on the other hand, is a value proposition. That value can be achieved using many different types of software (e.g., straight-through processing-STP, workflow, collaborative, enterprise content management-ECM) running 'on top of' varying architectures of which SOA is only one. For example, everything from Microsoft Project to BMC Remedy's Action Request System to IBM Rational tools can help users manage business processes.

Your options are not just the products with BPM somewhere in their name and SOA on the first page of the data sheet. Still, BPM and SOA are a good fit.

The Concept

One of the best ways to look at business processes and workflows is as services. Although it is possible to have a heavier modular view of a service-as opposed to a lightweight componentized view-the SOA concept really does not make much sense without hundreds or thousands of highly granular components, rather than a few or a couple of dozen modules.

These services are the pieces-artefacts in computer-science speak-that provide the benefits users expect of SOA. Because even the largest traditional software suppliers are unlikely to build thousands of such services, due to a limited market demand for each service individually, the BPM value proposition, where workflows are 'developed by' line management and end users-and shared around companies and supply chains-make a great source.

These fine-grained services need to be decoupled literally or figuratively from individual applications (and pieces of infrastructure software) and stored in repositories. SOA and BPM intersect so well because straight-through business processes and human-centric workflows-and their hybrids-can be built, rebuilt and executed as lightweight services. There are two types:

  • Those unique to a single enterprise and kept behind enterprise firewalls
  • "Community repositories" organized by supply chain or other inter-enterprise (likely industry-centric) characteristic.

Community repositories do not really exist yet to any great extent and are expected to emerge in the 2009-2012 timeframe. However, think of ACORD in the insurance industry or GS1 US in consumer packaged goods manufacture and distribution as likely sources.

As shown in the illustration, in pre-SOA program development artefacts are sequenced together in every application (or piece of infrastructure software such as an application server). There are thousands of duplicative triangles, rectangles, ovals, etc. (representing subroutines that are used over and over again in various applications or pieces of middleware) that basically do the same thing. When IT has to change a triangle, rectangle, etc., it has to be changed everywhere it exists.

In the SOA world, the triangles, rectangles, ovals etc. are kept in the repository and called upon as needed-ideally in real time-to execute whatever the application or middleware is intended to execute. Not only does the repository mechanism make updating easier but it also allows the IT group to provide end users a higher level of service-both in terms of faster updating and faster execution-leading to the service level agreement (SLA) promise that is the heart of SOA.

Flexibility vs. Performance

Aligning BPM service type to SOA integration philosophy (heavy vs. lightweight) is key in choosing SOA to underlay BPM. Some IT management and staff-especially among the software supplier community-are philosophically tied to performance to the exclusion of flexibility but most IT developers and end users prefer flexibility. SOA and its repository approach and SLA concept is ideal for BPM where such flexibility is the key requirement. There are some BPM applications where a less flexible, preconfigured flow is required for higher performance, more security or similar reasons, but in most cases the flexibility and lighter weight of more componentized services are going to be the leading requirement. This is especially true when the process extends outside the firewall to partners, suppliers or customers.

IBM and Red Hat offer SOA-based BPM but they are only two examples among many. In fact in my opinion, IBM mixes the terms SOA and BPM so regularly that its more interesting BPM announcements because buried inside IBM's SOA marketing message. On October 1, IBM announced a number of new BPM-related professional services and product enhancements, particularly of "business space" and BPM Healthcheck. Via plug-ins to IBM BPM Modeler, users can input renderings of process flows from Microsoft PowerPoint or Visio or IDS Scheer's tools. Then with Healthcheck, users can monitor their use and effectivity. Then, according to IBM, "…Healthcheck will suggest a BPM Strategic Roadmap that identifies the best entry points and practices for a successful deployment."

Red Hat's Enterprise JBoss jBPM is an emerging open-source-developed method of creating a scalable, standards-compliant and cost-effective SOA environment. According to the forthcoming Manning Publications book Open Source SOA, Red Hat introduced jBPM as the BPM product used for an IT department's own BPM (what is often called IT Lifecycle Management-ITLM). Parts of the book on jBPM covers two mains topics: enterprise functionality and integration with Open SOA Collaborative Service Component Architecture (SCA) and Service Data Objects (SDO) as implement in the Apache Software Foundation's Tuscany project. The enterprise features of jBPM are relevant when building very complex business processes that have enterprise-ready exception handling and logging. The ability to decompose complex business processes into subprocesses, as shown in the illustration, is the key. It enables you to construct higher-level composite services that can be reused by multiple processes.

Summary

At one level, SOA is all about eliminating infrastructure as a BPM consideration and reducing instances of code needed to implement various processes. From the BPM perspective, decomposing applications into services that instantiate subprocesses and workflows that provide organization a competitive advantage is the key characteristic of SOA.

In building an enterprise repository and/or using a community repository, users will need to have some BPM-related services and some other (primarily) infrastructure services or the SOA concept does not hold up.

About the Author

Dennis Byron brings three decades of analyst experience to his role as ebizQ's Community Manager for Improving Business Processes. This community covers Business Process Management (BPM), Process Modeling, Process Analysis, and Business Alert Monitoring (BAM), among other topics.

As Community Manager, Byron will blog and podcast to keep the ebizQ community fully informed on the latest news and breakthroughs relevant to enterprise BPM. Byron will be responsible for bringing you breaking news on BPM daily, writing feature articles and sourcing content from other analysts, industry associations and vendors for publication on ebizQ. Finally, each week, Byron will compile the most important news and views in an e-mail newsletter for ebizQ's ever-growing BPM community.

Byron is ideally suited to the job, as he has researched and analyzed all areas of IT and information-systems use for the past 30 years. Byron looks at BPM market dynamics backed up by facts, while taking into account the perspective of the IT and business person. He is a frequent speaker and moderator on business processes, which will also be one of his roles as Community Manager.

Byron was the ERP and Middleware Analyst with the Datapro division of McGraw-Hill and IDC from 1991 to 2006. In these roles, he was the primary analyst for Business Process Management. He has conducted over 500 specific information-systems case studies. He has contributed to Application Development Trends, IT Business Edge, Research 2.0 and other publications.

Byron is also the principal of IT Investment Research, which is aimed at institutional and individual investors in IT, or anyone who enjoys peering under the covers of "the financials," where large companies and emerging IPOs like to bury their most interesting facts. His main area of interest is investment opportunities in enterprise software.

More by Dennis Byron

About ebizQ

ebizQ is the insiderís guide to next-generation business process management. We offer a growing collection of independent editorial articles on BPM trends, issues, challenges and solutions, all targeted to business and IT BPM professionals.

We cover BPM standards, governance, technology and continuous process improvement, as well as process discovery, modeling, simulation and optimization, among many other areas. We follow case management, decision management, business rules management, operational intelligence, complex event processing and other related topics. We closely track important trends such as the rise of social BPM, mobile BPM and BPM in the cloud. We also explore BPMís use in functional areas, such as supply chain and customer management, and in key verticals, such as financial services, health care, insurance and government.

ebizQ's other BPM-oriented content includes podcasts, webcasts, webinars, white papers, a variety of expert blogs, a lively online forum and much more.