A Short History of BPM, Part 8

Continued from Part 7.

Part 8 (the last): The Current State of BPM. Every analyst, vendor and customer defines BPM differently, because the current definition of BPM is very broad, and there are many vendors jostling for position within it. EAI/ESB-type vendors call their products BPM, but the products may contain only rudimentary human-facing functionality. Workflow-type vendors, also labelling themselves as BPM, lack the necessary infrastructure for integration, and often handle automated steps poorly. Some pure integration products call themselves workflow, just to confuse things further. There’s a lot of complementary products, such as process analytics and simulation, and business rules engines: BPM vendors will either tell you that a particular capability must be part of the base BPM product (if their product has it), or should never be part of the base BPM product (if their product doesn’t have it). And now there’s the whole SOA wild card thrown into the mix.

BPM is definitely a case where the whole is greater than the sum of the parts. It’s not just workflow plus EAI plus B2Bi plus business rules, plus plus plus: it’s the near-seamless integration of all of these tools into a single suite that provides an organization with the ability to do things that they could never do before. That doesn’t mean that all the tools have to be from the same vendor, but it’s essential to deliver all of the BPM functionality in a single environment of closed-loop process improvement.

Smith and Fingar’s book Business Process Management, The Third Wave describes this “third wave” as providing the ability to create a single definition of a business process from which different views of that process can be rendered and new information systems can be built. This allows different people with different skills — business manager, business analyst, regular old user, programmer — to view and manipulate the same process in a representation suitable for them and derived from the same source. They make a great analogy with HTML, where a business user may use a high-level tool like FrontPage to view and edit HTML, whereas a developer may edit the HTML code directly, but they’re still working from the same source. Round-tripping between a business analyst’s modelling tool and a developer runtime environment is one way to do this, although it violates the “same source” in the purest sense, but we definitely have to get rid of the strictly one-way paths from business analysis to implementation that exist now in many organizations.

Furthermore, Smith and Fingar point out that in the world of BPM, the ability to change is far more prized than the ability to create in the first place, and that BPM has the potential to actually remove application development from the cycle — the “zero code” Holy Grail that gets a lot of press these days. They make an analogy with VisiCalc, which took customized data analysis out of the hands of the IT department and put it in the hands of the business users, thereby taking software development off the critical path for achieving results.

Getting back to the point of this post, what is the current state of BPM?

First of all, we have several companies from the pure-play BPM/BPM suites market: they provide excellent human-facing BPM and at least adequate integration capabilities, with some providing outstanding integration. At the Gartner BPM summit earlier this year, they listed three “major players” in this category who had revenues upwards of $100M — FileNet, Pegasystems and Global 360 — and five “up and comers” with revenues above $30M — Appian, Lombardi, Savvion, Metastorm and Ultimus — while ignoring anything smaller than that. All eight of these vendors hit into the right zones in the Gartner and Forrester charts, which means that they either have the necessary functionality or are partnered with someone to provide it.

Second, we have a couple of integration-focussed BPM vendors who have purchased pure-play BPM vendors to create the complete range of functionality. The two highest-profile examples are the TIBCO acquisition of Staffware in 2004, and the BEA acquisition of Fuego earlier this year. In both cases, there seems to be a reasonable fit, but my concern is that the human-facing BPM side is going to become weaker since the main focus of these companies is on integration.

Third, we have the large software companies that have developed (or acquired) a BPM product: IBM, Microsoft and Fujitsu all spring to mind. In many cases, such as IBM and Microsoft, their BPM products are primiarly integration-focussed without a lot of human-facing support, and likely started as a “would you like fries with that” sort of offering for customers who were already committed to their architecture. IBM’s MQ Series messaging is probably still the most commonly used piece of integration middleware in financial services, although I think that they call it (and everything else) “WebSphere” these days, and IBM rightly has it as a cornerstone of their BPM strategy. Fujitsu is the odd one out here, with what appears to be a fully-functional BPMS; unfortunately, they’ve been marketing it in stealth mode and most people are completely unaware of it: as I said in one of my posts about the Gartner BPM summit, “who knew that Fujitsu did BPM?”

We’ll continue to see most of the business functionality envelope being pushed by the vendors in the first category as they seek better ways to integrate business rules, analytics, performance management and other capabilities into BPM; in fact, the most innovation seems to be coming from the smaller vendors in this category because of the lack of baggage that I discussed in part 7.

Because of the current focus on process improvement in all organizations, I don’t think that there’s any great risk of any of the vendors that I’ve listed here going out of the BPM business any time soon. However, the integration vendors will acquire some of the smaller BPM suite vendors to round out their portfolios, and the large software companies will acquire some of everything, in a continuing Darwinian cycle.

Before you vendors start adding self-promoting comments to this post, keep in mind that this is not intended to be a comprehensive list or review of BPMS vendors, and I know that you’re all very special in your own way. 🙂

4 thoughts on “A Short History of BPM, Part 8”

  1. Sandy,
    I don’t really have a problem with your list, but I don’t agree with your characterization of IBM and BEA. IBM has been doing human workflow almost as long as FileNet, and a lot of that functionality has found its way into WebSphere v6. Also, the BPM marketing guys there must be jumping out the window to hear that the cornerstone of their BPM strategy is MQ. WebSphere Business Modeler and Monitor are the cornerstone of BPM for IBM, what sets it apart from SOA.
    We all noted how weird it looked when BEA bought Fuego, but unless you know something I don’t, the bigger worry now is that BEA is ignoring its strengths in SOA and focusing too much on human-centric processes… not the other way around. I look for BEA to integrate ESB with the Fuego stuff, but not to redirect BPM to mean business integration.

  2. The day that anyone at IBM pays enough attention to me to even consider looking out a window (metaphorically speaking), much less jumping out of one, I can’t even imagine what I’d do. 🙂

    I’m aware of IBM’s human-facing workflow efforts, and they have always been substandard compared to their competitors at the time, in my opinion.

    As for the integration side, I said that Websphere MQ was “a” cornerstone of their strategy, not the only thing in it, and I’m speaking more from the point of view of how this stuff is actually being used in organizations that I work with as opposed to how IBM marketing would like it to be used.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.