SearchOracle.com discusses a recent Forrester report that claims SAP NetWeaver is winning the middleware battle against Oracle Fusion. The logic isn’t fully revealed in the story, but the key seems to be more about the strength of those companies’ enterprise applications and solution partners than the technical merits of the middleware itself. Forrester’s Ray Wang, co-author of the report, explains SAP’s advantage this way:
“A head start, a partner ecosystem and a customer base are pretty much key ingredients for success.”
In addition to the core apps themselves, BPM is one of three fronts where SAP and Oracle will be duking it out over middleware, the others being business intelligence and master data management. But the report also says, as reported by SearchOracle, that
Oracle’s strong middleware platform and better support of open standards make it the right choice for customers who rely heavily on custom development in conjunction with packaged applications…
Hey, isn’t that what BPM is all about? Go figure.
What struck me most was the implication that BPM at both companies is ultimately just an embellishment of their application story, just like workflow was in the 1990s. In that context, Edwin K’s re-framing of BPM concepts as Oracle application extenders makes a lot more sense.
April 7th, 2006
I got a nice note yesterday from Paul Fisher, an IT exec at the FDA, on my BPM 2.0 manifesto. He was struck, in particular, by the line that said:
“[BPM's] top-down design contrasts starkly with current SOA initiatives, which are bottom-up and IT-driven, and where the services exposed for composition are determined by IT’s notion of enterprise architecture, not by process-centric analysis.”
He goes on to say,
That’s exactly what is going on here, and I’m trying to argue with people who are trying to build services simply to be able to say look ma, SOA!
You can see the rest of his comment to the BPM 2.0 post here, but I’m trying to restart the discussion around BPM as a top-down approach to SOA. Top-down as in goal-directed, the goal being optimization of business performance by improving a particular business process. It’s the process owners on the business side that should decide which services get rolled out first, and BPM provides a methodology for doing that. It’s the process, the service orchestration, that determines which services get built.
In contrast, it seems that a lot of SOA efforts today put too much emphasis on the A. I can already see enterprise architects’ heads exploding: Business-directed implementation is not architecture, it’s spaghetti, yadda yadda. Instead, we need to first build a comprehensive services layer, integrate it with our stack, etc.
But it doesn’t make sense to fully build out the infrastructure when the standards keep changing and the middleware doubles in richness every 6 months. BPMS offers an alternative practical approach that is more grounded in quickly deployable solutions with built-in performance metrics, including ROI. That iterative approach is more likely to lead to an accepted enterprise service architecture than trying to fill out all the colored squares in the EA diagram up front and declaring, OK we’re SOA now!
Phil Gilbert makes a similar point:
SOA is a great step and is the foundation that insures [easier integration]… But business process management is NOT SOA! It’s not part of the “SOA stack.” Business process management is about the business…
In order to succeed, BPM has to convince IT that it provides a better path to SOA and implementation success, and has to convince the business side that there’s more to BPM than just modeling.
April 7th, 2006
