Penny for Your Thoughts (IBM BPM 7.5)
blogged about it before Impact, and we’ve obliquely referenced it since Impact. And we’ve enjoyed reading all the other reviews out there. So we won’t rehash the feature by feature, blow-by-blow nature of product reviews (we’ll save that for another post!). Let’s just take a big step back and look at the big picture, and I’ll tell you how we, at BP3, really feel about it.Much has now been written about IBM BPM 7.5. We’ve
I’m a Lombardi Customer… Now What?First, for Lombardi customers. There’s no doubt that this is A Good Thing. The Lombardi Way has prevailed within IBM in a sense – the experience of IBM BPM is going to feel a lot like Lombardi – and yet a lot of time and effort is going into things Lombardi could never afford to invest in (configuration management, integration). ILOG baked into the product line means no more guessing how best to handle rules issues in your processes. There’s a clear migration path up to 7.5, and clear software entitlements. But most of all, IBM BPM makes Websphere manageable for the customers who really wanted BPM rather than Websphere (in other words, the app server is behind the curtain, not in front of it). Most of all, Lombardi Customers can breathe a sigh of relief that IBM is not throwing out the golden goose that lays the eggs. From a Lombardi point of view, it is going to look like lots of extra goodies in the bag, with very few downsides from a feature-function point of view.
But I’m a WPS Customer… Now What?WPS Customers should also be in good shape. While the migration to 7.5 does not automatically convey the Process Designer, they’re existing WPS efforts should migrate up just fine (the WPS engine is intact). If you add Process Designer to the mix, you’ll find you now have a great BPM tooling for addressing use cases that might have been more challenging in the WPS environment. The new tooling should be more accessible to your team, and make it easier to address a broader set of use cases. Most WPS customers won’t breathe a sigh of relief because (a) they always assumed WPS would dominate the ultimate BPM solution, or (b) because they are happy to have access to the Lombardi-style version of BPM.
I was about to Buy IBM WPS or Lombardi… Now What?Just buy IBM BPM. Your choices got simpler. If you need to design integration flows with clear atomicity and transactional semantics, go for the advanced version of IBM BPM. Otherwise, you’ll probably want to start out on the Standard version if you’re a larger company, and express if you’re running a pilot or smaller organization. You no longer have to worry about betting on the wrong horse. This is something we can give IBM credit for – their product strategy didn’t involve abandoning either of their main BPM product lines or leaving behind either set of customers.
I Work for IBM… Is This a Good Thing?You bet it is. Now you can sell and deliver on one value proposition with conceptually minor permutations. No more product conflict. The WPS heritage assets are now defined toward a different use case (automated workflows and integrations) than the heritage Lombardi assets (Human-centric BPM, if you will). Build your processes in process designer, and build integration flows and lights-out processing in the Integration Designer. And integrate the two in the Process Designer.
I’m an Analyst Covering BPM… Now What?Well, I guess your job got a little easier. IBM really has one BPM offering you need to analyze, rather than 2-3. And it seems to capture the best attributes of Lombardi, WPS, and ILOG. As Phil Gilbert said to us at bpmCamp shortly after the acquisition: “IBM clearly has the assets and technology to put together the best BPM offering in the market.” The only question was: would they? Would they actually put those assets front and center and create the offering? Well they have. Adjust those magic quadrants, waves, and rankings.
I’m a Lombardi Consultant or Consulting Firm… Now What?This is nothing but good news as far as BP3 is concerned. We couldn’t be happier with the direction IBM took with BPM 7.5. Including dropping all the awkward naming of previous versions. We believe we are the best Lombardi BPM services provider, and we aim to continue that record by aiming to be the best IBM BPM services provider. We think IBM put the right horse (Process Designer) in front of the cart (Integration Designer), and we’re really looking forward to leveraging all the new features of 7.5 (to review: ILOG rules, Integration Designer, Profile Manager, Business Monitor, etc.). We’re incredibly relieved that they didn’t EOL Lombardi. And I think there will be a lot of WPS customers who will want to understand, better, what this whole Lombardi point-of-view is all about. We think they’ll want to talk to someone like BP3.
It’s All About the ExperienceImportantly, this release keeps the focus on the things that matter in BPM deployments – time to market, ease of use for the 80% case, ability to go as deep as need be in the 20% case, and a focus on the “business” view of BPM, not just the IT view. But most importantly, this release signals that the engine(s) don’t matter… What matters is the EXPERIENCE. IBM (and specifically Phil Gilbert) is planting the flag and saying the experience around BPM matters more than which specific technologies are behind it, it even matters more than the Websphere branding in front of the old names. In the future, if IBM resolves the offering down to a single engine, it would likely be transparent to us because that engine would be running off of the repository we have today, and running behind the user experience we have today (or, an improved version of the same). Do I really care if the code running my Process Designer-authored process is Lombardi heritage or WPS heritage? I don’t really care, so long as it still behaves the same way. In other words, so long as it implements the “interface” and gives me that “WYSIWYG” feel, I’m happy. Much has been made by Clay Richardson and others about “multiple BPM engines.” But trust me when I say that these engines consist of a relatively small percentage of the total lines of code involved in these products. It is like the algorithmic core of a bigger software entity. No one is suggesting that the ILOG engine has to be consolidated with the BPM engines to save cost. It doesn’t make any sense to do that, does it? So why consolidate the BPEL and BPMN engines? (Again, it may just not make sense to merge these two entities in a meaningful way). IBM feels that it has already merged them in the two ways that matter most:
- the BPM “engines” install, run, and operate as one software process or entity, inside a single JVM.
- the BPM “engines” are unified behind common UI treatment, and common data models, reporting infrastructure, and rules interactions. In a sense, they “behave the same”. Users of IBM BPM won’t think of these things as separate engines. They might think of the modeling as separate user cases, but they won’t need to care, nor will they care, about what kind of “engine” is processing the model. The diagram and details attached to it will define all the behavioral semantics.
Where Do We Go from Here?Nothing has validated our investment in Lombardi more than the release of IBM BPM 7.5. I think John Reynold’s post on the subject captures how I feel as well. This is important. As pivotal as finding out last year at Impact that IBM was truly getting behind its new Lombardi BPM software. This year it is pivotal in that we’re finding out that the last year has been one of real investment in the platform and real results. This isn’t just window dressing, it is substance. I understand why people unfamiliar with the workings of Lombardi and WPS might feel differently, but with respect, they’re wrong. If you know how it works under the hood, this is significant.
…and Thanks!Given that this is the culmination of hard work from so many people that I hold in high regard, it seems appropriate to say thanks. I was recruited to Lombardi by Toby Cappello, Scott Bonneau, and Phil Gilbert – not to mention Rainer Ribback and Brian Witherly. And Lombardi allowed me to meet Lance Gibbs, and Flournoy Henry, among others. We built the services team I wanted to build at Lombardi – geographically dispersed (localized), highly skilled, and very experienced consultants. It was completely counter to the prevailing trends at the time: off-shore (remote), commoditized/cheap (lower skill level), and inexperienced consultants. The results:
- a much more successful, and mature, customer base
- a better feedback loop into the product development team
- a great talent pool for pulling into other senior or leadership roles in the company
- lower financial risk to the company, at the price of somewhat lower margins on services.