Skip to main content

BPA, BPM, BPMS, Business Modeling???


Is BPM (Business Process Modeling and Execution) the SOA killer application?

I had a very interesting interaction with a global VP of BPM of BPM for a major vendor.  The encounter went like this…

VP on behalf of vendor demonstrates BPM tools to potential client.  Everyone oohs and ahhs at the impressive presentation, graphics, and overall possibilities of BPM.  The vendor product looks impressive, it works, and actually has reasonable (runtime) performance.

Then I ask the VP “how many processes can this client create in a year?”.  After all, creating a BPM workflow / process is relatively quick and easy.  In theory a couple of days to create it, another week to test it and deploy it.  Maybe a mid-sized organization should be able to generate 26 processes per year per person assigned to BPM.

The VP responded, “7”.  “Seven”, I remarked, “why so few?”  He explained first of all the BPM processes won’t have all their steps exposed (at all or at the right level of granularity).  This turns almost every BPM creation into an integration project (and explains why many BPM tools come with a large number of adapters and other integration components – because they have to struggle to get to the process steps or data needed for them). 

Then he added  that few businesses actually have their processes mapped out.  So the managers must get together with a business process modeler, model the process, run it through a few senior managers who revise it, send it back down where they adjust it, and finally get the process approved.  Then when they deploy it they find out that how the managers think things are working is not exactly how they ARE working…and it goes through a revision to reality.  Naturally the whole thing can take a few months.

So what has happened?  I see BPM as having divided into two separate directions, with most tools focused on one side or the other.  The first are very pure business driven Business Process Modeling and Execution tools.  These tools and projects are driven by the business with limited IT involvement, and while they directly solve business problems they are limited in their ability to do so due to IT not offering the access to the IT systems/services performing the business steps.

The second are Business Process Automation tools and features, some of which have become part of a number of Enterprise Service Bus products (others which are tightly integrated with ESB’s and architecturally a close layer above).  In many cases the ESB logic of specific integrations has been morphing into partial (and sometimes complete) business process automation routines.  And the ESB’s themselves often offer a fully visual drag-and-drop drag-and-connect modeling-like environment for creating them.

As I note to the confusion of my colleagues, a BPM process may be exposed as a service and be composed of services.  It’s activating event may be a service request, and it’s terminating action may be to activate a service.

There may be no differentiating factor between the approaches from the tool standpoint (and both IBM and Software AG have been busy buying both the higher business approach tools and the lower BPM automation tools – with roadmaps for merging them together), but there is a common differentiator from the IT standpoint…

When processes are particularly long running (days or longer) and/or include stops for human input (or interaction or approval), these are typically the business oriented BPM processes.  When the processes are short running (seconds to hours) and/or don’t normally require human interaction (except in case of an exception), these are typically business process automation routines.

Business Process Automation offers significant possibilities to IT architecture and inter-system and component interaction designs and should directly be incorporated into the Enterprise Architecture and Enterprise Integration Layer (or tightly coupled to it right above).

Business Process Modeling and Execution (execution of the model) has shown less success as an enterprise APPROACH and should be targeted at specific business problems where it will directly bring it’s ROI.

Popular posts from this blog

Integration Spaghetti™

  I’ve been using the term Integration Spaghetti™ for the past 9 years or so to describe what happens as systems connectivity increases and increases to the point of … unmanageability, indeterminate impact, or just generally a big mess.  A standard line of mine is “moving from spaghetti code to spaghetti connections is not an improvement”. (A standard “point to point connection mess” slide, by enterprise architect Jerry Foster from 2001.) In the past few days I’ve been meeting with a series of IT managers at a large customer and have come up with a revised definition for Integration Spaghetti™ : Integration Spaghetti™ is when the connectivity to/from an application is so complex that everyone is afraid of touching it.  An application with such spaghetti becomes nearly impossible to replace.  Estimates of change impact to the application are frequently wrong by orders of magnitude.  Interruption in the integration functioning are always a major disaster – both in terms of th

Solving Integration Chaos - Past Approaches

A U.S. Fortune 50's systems interconnect map for 1 division, "core systems only". Integration patterns began changing 15 years ago. Several early attempts were made to solve the increasing problem of the widening need for integration… Enterprise Java Beans (J2EE / EJB's) attempted to make independent callable codelets. Coupling was too tight, the technology too platform specific. Remote Method Invocation (Java / RMI) attempted to make anything independently callable, but again was too platform specific and a very tightly coupled protocol. Similarly on the Microsoft side, DCOM & COM+ attempted to make anything independently and remotely callable. However, as with RMI the approach was extremely platform and vendor specific, and very tightly coupled. MQ created a reliable independent messaging paradigm, but the cost and complexity of operation made it prohibitive for most projects and all but the largest of Enterprise IT shops which could devote a focused technology

From Spaghetti Code to Spaghetti Connections

Twenty five years ago my boss handed me the primary billing program and described a series of new features needed. The program was about 4 years old and had been worked on by 5 different programmers. It had an original design model, but between all the modifications, bug fixes, patches and quick new features thrown in, the original design pattern was impossible to discern. Any pattern was impossible to discern. It had become, to quote what’s titled the most common architecture pattern of today, ‘a big ball of mud’. After studying the program for several days, I informed my boss the program was untouchable. The effort to make anything more than a minor adjustment carried such a risk, as the impact could only be guessed at, that it was easier and less risky to rewrite it from scratch. If they had considered the future impact, they never would have let a key program degenerate that way. They would have invested the extra effort to maintain it’s design, document it property, and consider