BPM Momentum

I attended the The BPM Momentum: What’s Driving it? webinar today (not “what’s driving IT” as the host ebizQ erroneously labelled it, which has a much different meaning), featuring Jim Sinur of Gartner. Definitely worth catching the replay for Mr. Sinur’s comments on success factors for BPM projects and for his view of the market convergence.

He included Gartner’s Application Integration Hype cycle chart, showing how BPM technologies fit: apparently, BPM itself is sliding into the Trough of Disillusionment, whereas BPM Suites are still climbing towards the Peak of Inflated Expectations. (The hype cycle terminology always reminds me of the morality fable Pilgrim’s Progress with its Slough of Despond, but I digress.) He only put a 10% probability on the catastrophic scenario, which makes me feel a whole lot better.

He also had some good numbers on customers and their BPM projects:

  • 85% of BPM customers are now going after their human-facing processes (presumably, the automated system-to-system ones are already in place).
  • BPM projects are yielding an average IRR of 20% (although Gartner uses a more conservative figure of 15%), but larger projects can produce returns of well over 100%.
  • “Soft” benefits such as competitive advantage and higher customer satisfaction are major contributors to a project’s success.
  • Business and IT are becoming more aligned on BPM projects.

He also commented on the convergence that is happening in the marketplace, something that I’ve been seeing for some time as well: 130 BPM vendors all attempting to jostle their way into what I call the “BPM suite spot”:

This convergence is just a continuation of the evolution of BPM that I discussed in an earlier post, but it’s going to get a lot more painful for some of the players as they get eaten by the competition or body-checked off the playing field.

IBM tops AIM market, but what of BPM?

A press release this week from IBM announces that a preliminary Gartner report on application integration/middleware (AIM) and portal software has crowned IBM as the market leader based on 2004 licence revenue. Their figures put IBM’s share at around 37% of the worldwide market, with chief rivals BEA, Oracle and Microsoft trailing far behind at 7.2%, 4.4% and 4.3%, respectively. The full report is due out at next week’s Application Integration and Web Services Summit.

As you poke around in the data, however, you find out that the number is made up of several products, including application servers (where they compete with BEA), integration software (where they compete with TIBCO, Microsoft BizTalk and webMethods) and portals (where they compete with Microsoft SharePoint). In fact, I suspect that anything that carries the “WebSphere” brand is considered part of their AIM stable, including ongoing licence fees for tons of pre-WebSphere-era MQSeries installations connecting ancient IBM mainframes using proprietary protocols. If you check out IBM’s software product list, there’s a whole lot of WebSphere going on, and it didn’t all start under that brand. In fact, I remember when what is now WebSphere MQ Workflow was rebranded from “FlowMark” to “MQSeries Workflow”, prior to its re-rebranding as WebSphere a year or so ago. Since MQSeries was the hot new brand at the time of the first rebranding, it was seen as an attempt to “standardize by branding”, although FlowMark wasn’t even based on MQSeries until much later.

From a BPM standpoint, the biggest complaint that I have about IBM’s products is the apparently piecemeal strategy. In recent years, we’ve seen a number of products put forward by IBM as BPM and/or workflow: WebSphere MQ Workflow (a somewhat clumsy workflow product that never really developed into a cohesive contender), Content Manager’s Document Routing (a very simple routing capability for document-based workflows), Lotus Workflow (I’m not even going there), Advanced Workflow (now apparently being sunsetted), and the latest entrant, WebSphere Business Integration.

WBI, previously called WebSphere Process Choreographer, is based on the CrossWorlds EAI product acquired by IBM: just type in www.crossworlds.com and see where it takes you. Because of that origin, it’s coming from the EAI space, and my concern is that the product focus will remain on integrating systems and will never fully develop the human-facing functionality, including business-focussed tools for modelling, simulation and analytics. Gartner’s 2004 magic quadrant for pure-play BPM doesn’t mention any of the IBM products, although they did show up in the 2004 magic quadrant for business process analysis due to the Holosofx acquisition.

If this is going to be the next-generation BPM product, IBM needs to stop spending so much time listening to the IT departments (who get far too excited about EAI) and spend more time listening to the business departments in order to develop the human-facing components that they need to move into the pure-play BPM market. At the very least, they need to perform a mercy killing on MQ Workflow as soon as possible to reduce customer confusion and focus their efforts on a single BPM product offering.

Of course, there’s always going to be some platform limitations to WBI: it’s going to require WebSphere Application Server and WebSphere MQ. Given the market penetration of WAS and MQ in large organizations, however, I don’t see that as a problem; the opportunity to grab a huge BPM market share is theirs to blow.

The Case for BPM

Another interesting lunchtime webinar today, “The Case for BPM”, this one featuring Janelle Hill, a VP & Research Lead from META Group (acquired by Gartner as of last week), and Gary Morgen, a VP from Citigroup. It was sponsored by TIBCO, but the first two speakers ran overtime and the poor TIBCO guy had to squeeze his 11 slides into about 30 seconds. Some would say that’s all the time that a vendor should have in an educational webinar, but come on, give them a break, they paid for it.

I really liked Ms Hill’s focus on tying process improvements (and hence the use of BPM) back to business performance objectives or a process improvement methodology such as Six Sigma: although that might seem obvious, there’s a lot of people who get wrapped up in the cool technology and lose sight of what we’re actually trying to do here, which is to improve someone’s business.

I disagree with her broad description of a BPM suite as “unifying workflow, EAI, document/content management, portal and web services technologies”, because I don’t consider content management or portals to be a part of BPM, but rather complementary technologies. Given that we’re migrating to an SOA world, however, the boundaries are starting to blur.

Mr. Morgen talked mostly about Citigroup’s TIBCO/Staffware implementation, but he also had some great words about reducing time/cost of application development by using best-of-breed vendor solutions rather than building it themselves: a refreshing viewpoint to hear from the financial services world, where huge organizations have spent billions of dollars in the past writing their own word processors and database engines. I’ve written previously about the value of using COTS components such as e-forms, so I’m completely aligned with Mr. Morgen’s views on this subject.

I also like the cool Blackberry integration that they’ve done to their workflow, although I don’t want to appear too wrapped up in the technology.

TIBCO will be making this webinar available for download or replay on their website soon; even if you’re not interested in TIBCO/Staffware specifically, I recommend listening to Janelle Hill’s portion for a reality check on establishing your business drivers for BPM.

Also, it will be interesting in the months ahead to see how Gartner and META reconcile their sometimes very different opinions on BPM.

Human, Interrupted

I just read about yet another analyst BPM workshop that claims to be “the definitive education on BPM”. Oh, puh-leeze. There is no such thing as a 2-day definitive education on a topic as broad as BPM, and besides, the analysts can’t even agree on the definition of BPM. I wrote a short course on BPM for a client recently (no, it wasn’t the definitive education on BPM), and as part of that, I created a brief history of BPM to show how this space evolved. One thing that becomes painfully clear in looking at the evolution and current state of BPM is that although everyone agrees that BPM is about managing processes, there is no clear definition of the divisions within the space, or which technologies belong where (if anywhere) within it.

It’s almost biblical: in the beginning, there was human-to-human workflow. Some time after that, there was system-to-system EAI. They were distinct, and that was good because everyone understood which was which. In time, workflow begat EAI-like capabilities in order to facilitate human-to-system interfaces, and EAI begat human-facing workflow-like capabilities in order to handle exceptions within processes. Then, workflow begat BAM and simulation, and EAI begat B2Bi. Finally, workflow and EAI together adopted process modelling and business rules (they didn’t beget these technologies, they already existed in other fields).

Then, the abomination: the analysts created a Tower of Babel by lumping all of this together and calling it BPM.

Yes, it was confusing before the term BPM was applied to it all, since workflow and EAI overlapped significantly, but it’s now monumentally more confusing to customers because any vendor in the entire BPM space can claim that they “do BPM” and can therefore compete with any other vendor. I saw a particularly painful example of this at a large company that had chosen an integration broker suite for their BPM standard. The internal IT groups were fully indoctrinated that this was the only BPM tool that they could use, and they actually seemed to believe that BPM meant the considerably narrower field of EAI. One of the senior people, on hearing me describe the requirements of a human-facing BPM project, referred to it as “human-interrupted”. Not surprisingly, there are considerably more system-to-system BPM projects than any other type in that organization; who would willing pick up that square peg and try to ram it into a round hole?

In an attempt to help with the confusion, the same analysts who lumped all of this together as BPM created divisions within the BPM space based on functionality. Unfortunately, they all created different divisions based on widely varying criteria. For example, Gartner, whose definition I tend to align with, created a taxonomy in a research note back in 2003 based on process type, dividing the space into pure-play (application-independent), integration-focussed, administrative, collaborative, and embedded. [For my work with back office systems, the key segments of the BPM space are pure-play and integration-focussed; pure-play is, more or less, what evolved from workflow, and integration-focussed is what evolved from EAI.] Delphi, on the other hand, makes divisions based on the degree of human interaction: person-to-person, person-to-system, and system-to-system. This is a very useful way to categorize applications of BPM, but I don’t agree with it as a way to categorize the products themselves, since all of them claim to do all of it.

There are many other BPM taxonomies: at least one per analyst, and usually one per vendor. Most of them are not created for the altruistic purpose of trying to clarify the space.

Creating a taxonomy is hard work, because it requires projecting a complex, multidimensional space onto a much simpler space of lower dimensionality in order to make it comprehensible and useful. BPM is definitely a case where the whole is greater than the sum of the parts, making the process even more difficult. BPM is not just workflow plus EAI plus BAM plus business rules, et cetera: it’s the near-seamless integration of all of these tools that is the real competitive differentiator, because that’s what enables an organization to do things that they could never do before.