IBM's Lombardi Integration Roadmap

Scott Francis takes me to task a bit for not completely buying IBM's public mass ingestion of the Lombardi Kool-Aid in Las Vegas a couple weeks back. I have to admit, however, that I did come away from the event with a different notion of how Lombardi will ultimately be incorporated into the WebSphere BPM family.

At Impact, IBM ran an analyst mini-conference featuring small roundtables and one-on-ones where analysts like me could ask WebSphere executives about the Lombardi roadmap and they could refuse to answer. But of course that's a blessing in disguise, because if they told me it would be under NDA. And if, as occasionally happens, they actually asked my opinion what they should do, it would not only be under NDA but I would have to say only nice things when they ultimately sort of did it. All of which kind of defeats the purpose of blogging.So... unencumbered by anything like facts or even barroom musings by those actually in the know, here is my "fantasy" roadmap for Lombardi integration.

First of all, it is a long tradition at IBM, a religion almost, that there is never a single right way to do anything. In BPM, the right way, and for most vendors the only way, is you start with modeling by business process analysts and architects, which leads to executable design (ideally layered on the model rather than starting over), followed by deployment, performance monitoring and optimization. But at IBM, that's just one BPM "adoption pattern." You can also start by monitoring first, or automating first (I call that Ready Fire Aim!), or... I don't know, I think they have three or four more. So the very idea that IBM would merge Lombardi and Process Server ideas into a single WebSphere BPMS based on a recommended model-first adoption pattern is pure fantasy on my part. But of course that's what they should do.

Scott also snickers at my statement that WebSphere Business Compass is a better BPMN tool than Lombardi Blueprint, says I'm the only one not employed by IBM to say that. But I may be one of the only people not employed by IBM to have used both. And it's obvious why I say it: Blueprint dumbs down the BPMN too much. Its goal was to make BPMN so simple even a caveman can do it. I think that's wrong-headed. If you want to get business and IT on the same page, you need to create a middle ground and ask business to step up to it. Compass does that, leveraging the complete BPMN 2.0 Descriptive conformance class (equivalent to my Level 1) palette. Versioning and some aspects of the drawing mechanics are better in Blueprint. Linking to strategies, metrics, and data is better in Compass. But Compass and Blueprint are pretty close, with considerable functional overlap. Obviously they need to merge into a single product. That's a no-brainer.

The hard part is bringing together Teamworks and Process Server. The soul of Teamworks is what Lombardi calls the shared model, i.e. shared by modelers and the execution engine. What you see is what you execute. The other key is playback, instantly from the modeling/design environment. How does that task UI work? Play it back. How does that service work? That business rule? Play it back, tweak, play it back again. None of this compile, deploy, log on, execute... Zzzzzz. Are you asleep yet? Shared model and instant playback are the keys to business empowerment. I think they are what got Craig Heyman and Beth Smith so starry-eyed. Because they are both so... un-IBM.

The soul of Process Server is SOA. SCA composites. Mediation flows. ESB and message brokers. Business people have no clue what all that stuff is, but IT knows you need it to do heavy-duty BPM. It's why IBM is the big dog in the BPMS world. Not because it is business-friendly. Because it can tote the heavy loads.

IBM's mistake was always thinking BPM and SOA were kind of the same thing. Remember those hexagons in the IBM marketecture? (Before they went to the layer cake?) The labels were slightly different in a SOA presentation versus a BPM presentation, but there was always just one hexagon. There wasn't a BPM hexagon operating in communication with (but independent of) a SOA hexagon. Like there is in real life.

In its most basic form, my IBM BPM fantasy separates the BPM and SOA layers, with Lombardi -- or let's call it the "Lombardi experience" -- as the BPM layer and Process Server the SOA layer. In Teamworks there is the Process Model -- the BPMN diagram -- and the Service Model, which models the implementation of each activity in the Process Model, whether a human task or automated service. The shared model concept requires a native BPMN process engine, and Process Server seems on its way to providing that next year. Let's take that as a given. Business-empowered executable process modeling then pits the Teamworks Process Model editor vs WebSphere Business Modeler. I prefer Lombardi, but clearly those tools need to merge.

So we are down to the task implementations, i.e. Teamworks Service Model vs WebSphere Business Modeler and WebSphere Integration Developer. Human tasks just work better with Lombardi, so despite IBM's heroic efforts to make its BPEL-based human tasks more flexible, I think just go with Teamworks coaches and screenflows. The automated tasks will be a few services created by business a la Teamworks Service Model, but mostly ones built by IT in WID. Under the covers, all the editors will create SCA components that allow configuration of assemblies for bulletproof deployment and reuse.

The hard part of all this is instant playback. How do you achieve the immediacy of Lombardi's model it, play it, tweak it, play it again experience without compromising what Process Server does well? I have no doubt that if IBM wanted to do this, it could.

Will they go this route? I doubt it. But it would be a killer product.Unencumbered by anything like facts or even barroom musings by those actually in the know, here is my "fantasy" roadmap for IBM integration of Lombardi BPM.