Bashing SAP, Oracle and Other 'Stackers'

Lombardi's Jim Rudden posts an admittedly "cranky" piece about software giants like SAP crashing the business process management (BPM) party. His beef with those companies, which he calls "Stackers," is that they pursue the promise of BPM half-heartedly. Actually, they have done everything in their power to bury BPM deep in what they view as their real market… which in the case of SAP and Oracle, he says, is enterprise apps, and in the case of IBM is… well he's not sure ( I would say IBM Global Business Services billable hours). However, if those guys - none of whom can touch Lombardi for speed of development (agility!), business empowerment, and overall elegance in execution - were not succeeding at some level, Jim would surely not be so cranky. But I think he paints the Stackers in BPM with too broad and too black a brush. So let me offer a more nuanced view.As the nominal trigger of the bashing, SAP's Project Galaxy takes the lion's share of abuse, I think unfairly. For one thing, like Lombardi, Galaxy has a BPMN engine (and doesn't try to shoehorn BPMN into BPEL-allowed topologies). Like Lombardi, it starts with a BPMN process model, and IT binds model activities to implementation properties by point-click configuration in Eclipse. It supports collaborative modeling and design, not a standalone modeling tool that must be whacked back in BPEL mode before exporting to the executable design environment. The SAP guys would admit - maybe not publicly - that the Galaxy modeling surface is not as business-friendly as Lombardi's today, but it's just version 1.0, and they are trying to move that way.

Oracle takes a completely different technical approach, taking ARIS's BPMN tool and adding Oracle extensions for human tasks, business rules, and notifications, all to generate BPEL that runs on the Fusion stack. Those BPEL gymnastics are similar to IBM's approach in WebSphere. But if IBM, SAP, and Oracle (with BEA) succeed in their BPMN 2.0 proposal, we'll see BPMN-direct executable design from all of the Stackers in a year or two. Well, maybe not Microsoft…

So it's more than, as Jim says, getting their BPM pitch down. It's getting their tools down as well. I call it "learning from Lombardi." Ironically, I think the Stackers' engineering guys "get" BPM, and that it's not the same as SOA, more than the sales and marketing guys, who are much slower to move off their IT-centric value propositions.

Jim's contention that BPM in Stacker companies is secretly a stalking horse for some other business has more merit. There is no doubt, for example, that the applications group - and the installed base it represents - at both SAP and Oracle dwarfs the middleware group building BPM. That is not to say the groups share the same agenda, but in a sense they need each other to succeed. Middleware needs specific hooks to the apps to tap into the installed base, and the apps group needs the middleware to keep IBM out as they turn the application monolith into composable services.

The real reason for Jim to be cranky about the Stackers is that they do have a stack - an SOA stack - that BPM rides on top of. The pureplay BPM vendors - our former term for the non-Stackers - don't, and as BPM moves to the enterprise, customers increasingly want one. The non-Stackers say, we have a UDDI browser, just layer our BPM on top of any SOA stack. But that is apparently a hard sell.Lombardi's Jim Rudden posts an admittedly "cranky" piece about software giants like SAP crashing the business process management (BPM) party. His beef with those companies, which he calls "Stackers," is that they pursue the promise of BPM half-heartedly... I think he paints the Stackers with too broad and too black a brush. So let me offer a more nuanced view.