IBM’s Business Process Manager: more than a new paint job

Neil Ward-Dutton

Tuesday, April 12, 2011 by

Yesterday at IBM’s IMPACT conference in Vegas, the company announced the release of Business Process Manager 7.5. At first glance, Business Process Manager might look like a simple updating and blending of two overlapping toolsets (the former WebSphere Process Server/Integration Developer combo, and the former WebSphere Lombardi Edition platform). Indeed other commentators have pointed to this release as “a new paint job”.

However when you look deeper, the release of Business Process Manager marks a significant departure for IBM, and warrants a thorough reappraisal of IBM’s competitive position.

We’ll be publishing a new in-depth report in the next couple of days: in that report we’ll be laying out how the whole thing fits together. In brief, though, what’s happened is that IBM has pulled the two technology offerings together around a unified repository and governance toolset – Process Center. This is former Lombardi technology; however now it delivers its capabilities across Process Designer (the former Lombardi design environment) and Integration Designer (the former Integration Developer). IBM has also created a single unified deployment runtime foundation that hosts integration flows, ESB microflows, business rules and business processes, together with a unified administration environment. The two design environments remain separate, aimed at different audiences – but integrated through the Process Center repository.

Whereas until recently IBM pitched Lombardi technology and WebSphere Process Server / Integration Developer as offering the same capabilities but for different scenarios, Business Process Manager makes the relationship clear: Process Designer is aimed at business-facing teams collaborating to optimise business processes; Integration Designer is aimed at IT teams working to orchestrate the integration of systems to support the optimisation of those processes. Again – these two environments work together through the use of a shared repository and governance toolset.

For the last few years, although it’s too much to say IBM has been swimming against the tide of BPM technology development, the company has certainly struggled to break away from its historical roots in delivering a BPM technology offering – the offering overall was primarily skewed towards the needs of software developers and architects.

With the release of Business Process Manager, IBM has absorbed the Lombardi DNA. Business Process Manager demonstrates a vital clarity of purpose in IBM for its customers and prospects, and should give those companies improved confidence that IBM has its story straight. What’s more, the promotion of former Lombardi technologies and design approaches to be front-and-centre in shaping the new Business Process Manager offering makes Business Process Manager stand out in terms of ease-of use.

Posted in BPM

9 Responses to IBM’s Business Process Manager: more than a new paint job

  1. Pingback: A Week of BPM | OnStrategies Perspectives

  2. Great read, Neil. Looking forward to the in-depth report!

  3. Pingback: Column 2 : IBM BPM: Merging the Paths

  4. Pingback: IBM BPM – Impact 2011, l’avis des experts | BPM Bulletin

  5. Pingback: IBM Business Process Manager – was in Blogs zu finden ist und Analysten so sagen | vitalize business

  6. Thanks Neil. Hopefully the in-depth report will be up soon! Thanks again.

  7. IM1 says:

    With due respect I am going to agree with the new IBM BPM being a “new paint job”. I have recently done some feature analysis of the IBM BPM stack and its just a shell on two different runtime engines.
    To make matter worse if and when filenet case manager is merged, it will be three different engines under one deployment shell called Process Centre.
    I don’t understand why they claim to have a rules engine when the Rules cannot be deployed or modified independent of the process.

    But I appreciate that IBM have recognised the inability of Websphere Process Server as being the BPM tool and IBM’s legacy BPM strategy but disagree that they have a clear path ahead. The design time environments and the runtime environments both seem to be separate.
    The dynamic case management and runtime change management of process is also lacking. Since its very likely that if and when IBM merge filenet, other runtime engines are not likely to benefit from its features.

    • Hi IM1 (it’s a shame you’re anonymous!)
      Interesting comment.
      I don’t dispute that there are two separate runtime engines under the hood today, but I think we might have to agree to disagree over how important that actually is in the overall scheme of things for a customer in production. When you look at the overall cost and complexity (vs the potential business return) of delivering a successful BPM initiative of significant scale, the matter of whether there’s one unified runtime or two engines plugged into a common runtime foundation is a pretty small component in my experience.
      But my central argument in saying BPManager 7.5 is more than “just a new paint job” is the way that the overall lifecycle is unified through the Process Center repository – this is a smart move in my opinion.
      If you read my detailed report you’ll see that I called out the strange situation currently in play re: rules engines – I think this needs to be made clearer for customers/prospects. At the moment if you want a full rules capability you do have to license that separately.
      It’s difficult to speculate re: FileNet technology merging with the rest of the portfolio at this point, I think. There are a number of ways this could be done, and some of them would provide the value of dynamic/unstructured work/case management facilities to customers without requiring any physical merging of engines. I think it’s just too early to say.

Leave a comment: