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.

The dreaded “consultant” title

Not unlike the prejudice regarding conference pricing that I discussed in this post, I just got dissed by DCI for using the title “consultant”.

I had a call from DCI this morning, but I was a bit distracted with real work and thought that this was a sales call, so I wasn’t paying a lot of attention. I just wanted to get through to the part where he would say “would you like any more information”, I would say no and get off the phone. Instead, he said something like “Our business networks are vendor- and consultant-neutral, so judging by your title we don’t think that’s it’s appropriate for you to join. Do you require any other information about us?” I was completely in the dark about what he was talking about, so I said no and hung up.

A few minutes later, I started wondering what this was about, searched through my browser history for DCI, and realized that I had applied to join their Business Process Management business network, about which they claim:

The Business Process Management Network provides a forum for you to learn and share best practices, challenges and solutions. Learn how to effectively identify, analyze and design processes to improve the overall flow of information within your organization.

Members of the Business Process Management Network are involved in the strategy, implementation, execution and management of all functions across the enterprise. They are the individuals who work together to identify, define, streamline and improve processes through business and IT solutions — to meet the needs of the organization, on time and within budget. Members include:

  • Business Analysts
  • Systems Analysts
  • Business Managers
  • Business Process Owners
  • Change Agents
  • Directors / VPs responsible for Enterprise Management
  • Financial and Compliance Professionals
  • Process Analysts and Designers
  • Project and Program Managers
  • Quality Assurance Professionals
  • Strategic Planners

Okay, count me in. I have lots of best practices experiences to share. I’m involved in strategy and implementation. I identify, define, streamline and improve processes. I take on the role of business analyst, system analyst, change agent, process analyst and designer, and strategic planner.

However, since I used the word “consultant” in my title as a sort of shorthand for what I do, they turned me down. Is this some sort of weird discrimination? Are there so many unqualified people using the term “consultant” that I have to abandon it for all time in order to not appear incompetent by (word) association? Or does DCI feel that having a “consultant” in their midst might detract from their own educational programs?

Luckily, since I run the show, I can take on whatever title that I want, so it’s time to go for something that won’t get me banned from the nice places. Or even from DCI.

e-forms

I blushed a few weeks ago while reading a friend’s blog entry about me. I appreciate his comment about how I “got” the whole electronic forms thing (in the context of integrating it with BPM), because I see e-forms as an essential part of many BPM applications. When I worked for FileNet a few years back as the Director of eBusiness Evangelism (yes, that was my real title, and yes, I asked for it), I gave presentations talking about how e-forms and BPM work together, and how they can — in some cases — make customization something that can be done by technical and business resources at the customer, rather than by an SI. This was considered heresy in some circles.

I understand that there are a lot of things that e-forms can’t do, but a bigger problem is that a lot of large systems integrators just don’t want to use e-forms, because it makes their job too easy. If it’s too easy, they can’t use their premium-priced Java developers. If it’s too easy, they can’t justify being late and over budget. If it’s too easy, the customer might get the radical idea that they could do some of the work themselves, including ongoing maintenance. In the large SI business model, e-forms are bad for business.

I saw this first-hand while working as a subcontractor to a large SI on a FileNet BPM project. I was responsible for the functional design, and for working with the development team to create the technical design. Because several of the user-facing steps needed to interface with a line-of-business database as well as the BPM system, the out-of-the-box user interface wasn’t going to cut it. However, FileNet has a very capable e-forms functionality, the result of the acquisition that my friend Chris mentioned in his blog posting, so naturally I suggested this to the technical lead on the project. You could have frozen Lake Ontario with the looks that I got in return. I was told, in no uncertain terms, that they were writing this from scratch in Java, and I should just shut up and keep out of it. Considering that I’ve probably written more code in my lifetime than the entire development team put together, I could have been insulted, but I was being paid much too well for that. I finished my piece of work and got out of Dodge. Now I hear that they’re a year late and still not in production, and I’m finding it very difficult to whip up any sympathy.

The funny thing is how long it has taken the first-tier BPM vendors to understand the value of e-forms as a part of their product, and either build or buy the capability. They’re so busy building bullet-proof plumbing that they forget about the fact that at some point, a process may have to interface with a person, and that a customer doesn’t want to spend a year having custom screens written in order to do so.

SEx machine

I just watched the replay of a presentation done by Peter Fingar, one of the most prominent names today in BPM and co-author of Business Process Management: The Third Wave. As usual, he had some interesting words about “How Work Works in Business”, because he understands that BPM is about business, not about IT: a fact of which many organizations have lost sight.

There was one false note in the presentation, however: he had a slide that described the work processor as the “strategy-execution machine”, and abbreviated that as “The SEx Machine™”. I kid you not, it even included the ™. With a slightly embarrassed pause, Peter pronounced the abbreviation as “the s-e-x machine”, as if he were the parent of a 4-year-old discussing a taboo subject at the dinner table. I was left wondering what marketing hack created that abbreviation, because I’m pretty sure that Peter wouldn’t coin a phrase to be used in a public presentation that he obviously can’t even pronounce in public. The really funny thing was that he spent a great deal of time in the presentation emphasizing how we had to get rid of 3-letter acronyms in IT, then he goes and turns “sex” into a TLA.

The inconsistency between the presentation slide and his obvious discomfort with the content really gave me pause, because it makes me wonder how many other presentations that I see where the presenter is equally ill-at-ease with the content, but just hides it better.

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.

BPTrends’ 2005 BPM Suites Report

BPTrends published a report on BPM Suites this week that reviews 13 different BPM products:

  • Appian Enterprise from Appian
  • AgilePoint from Ascentn
  • XicoBPM from B2Binternet
  • Chordiant Enterprise Platform from Chordiant Software
  • TRAXION Enterprise Business Process Management Suite from CommerceQuest
  • eg work manager from eg Solutions
  • FileNet Business Process Manager from FileNet
  • WebSphere Business Integration from IBM
  • WorkPoint from Insession Technologies
  • Business Conversion Suite from M1 Global Solutions
  • Pegasystems SmartBPM Suite from PegaSystems
  • TIBCO Staffware Process Suite from TIBCO Software
  • Ultimus BPM Suite from Ultimus

The major players are definitely covered here, but there’s a few of these that leave me wondering about the criteria for inclusion in this report. That cleared up a bit when I read the section Participating Vendors in the Foreward to the report:

BPTrends contacted all the BPM vendors we could identify and solicited their participation in this report at a cost to them of under $5,000. All products from participating vendors were evaluated in the same manner: Derek Miers and Paul Harmon prepared a detailed questionnaire which we asked each vendor to complete. They then reviewed the questionnaires, studied the product documentation and all other relevant materials provided by the vendors, and requested a product demonstration. Finally, they interviewed each vendor to eliminate any confusion and to make certain we had not overlooked anything. We did not conduct any actual product testing.

In other words, it appears that the vendors paid a fee to be included in the report, and the vendors provided the content for the report rather than it being based on independent observations. Although the authors have provided some nice summary pages that list each product’s characteristics on a separate page, there are no negative comments about any product, and there are few comparisons between products: this is more like a collation of each vendor’s product information rather than a product review as you might find from Gartner. Still, there is much useful information about the products in the report, and some excellent introductory material including the authors’ view of the BPM space and a summary of BPM drivers.

My assessment of BPTrends’ report: the first 38 pages (prior to the actual product information) contain some great background information. The product sections, although well organized and well written, don’t provide anything that you couldn’t get from the vendors’ websites.