For the past several years, SAP has been one of the usual suspects in pushing various standards efforts impacting Business process management (BPM). Yet to date, SAP has lacked an explicit offering, if you don’t count earlier efforts like xApps.
Of course there are loads of third parties that are profiting by exposing and integrating processes painstakingly exposed using SAP’s Business APIs and its more recent Enterprise Service-Oriented Architecture (ESOA, formerly ESA). But if you know SAP, it likes to boast an extensive third party ecosystem, but it also likes to boast its own all-inclusive wall garden of basic core building blocks.
This week at its 2007 TechEd developer conference, SAP finally let the other shoe drop. At this point, its BPM, plans are vague, but we’ve got a pretty good idea of SAP’s architectural approach.
Some of the pieces of SAP’s BPM architecture are hardly surprising. Yes, SAP BPM will layer atop NetWeaver, SAP’s middle tier platform. It will utilize a new SOA repository that, like its rivals, will support UDDI and store relevant non-web service artifacts. And it will generate BPMN, an emerging process modeling language from OMG.
What’s intriguing is how SAP will deploy, or execute business processes that are modeled in its tool. SAP wants to avoid the “roundtripping” where you’re constantly synchronizing the model with the software code and vice versa. Instead it wants to dial direct. SAP’s BPM modeler will generate BPMN, which in turn will generate Java byte code. Not Java, but the binary bytecode that runs against a compiler, or in Java’s case, a virtual machine (JVM).
In other words, SAP wants to cut developers out of the loop as much as possible. Business analysts would design the model, generate the BPMN, push a button, and poof! It’s executable. If it sounds too good to be true, it is.
For years, the notion of fully automating generation of software from models has been the stuff of pipedreams. CASE was justified based on the notion that all you had to do was generate an enterprise data model, and then you could automatically spit out consistent C or C++ code. More recently, UML modeling tools that automatically generate Java or C# have become practically ubiquitous. But in most cases, you’ll still require software developers to tweak or refactor the resulting code. And none of this dealt with byte code.
Well, we’ve come across one company that has already pulled the trick off. E2E, a company out of Switzerland, was called on by UBS to unify disparate banking systems after the company was formed by merger nearly a decade ago. Using UML to structure the logic for linking disparate banking networks, E2E concluded that they could save development time by turning the model directly into an executable. Today, their solution, which they have productized as E2E Bridge, handles millions of transactions per hour. IDS Scheer, whose ARIS language is used by many SAP customers to model their business processes, has now teamed up with E2E to present a do-it-yourself BPM solution.
So SAP’s dial-direct approach might not be as off-the-wall as it sounds. There’s obviously a risk in jumping from model to executable in that you may lose the subtleties of business logic. But that’s something that SAP has gobs of, as it owns the application layer across its client base. So we’re not surprised that SAP would take an approach that intertwines BPM further into the wall garden. And we’ve spoken with several BPM pure plays with similar ideas.
That makes us wonder if and when SAP will come out with the next piece of the puzzle: an Enterprise Service Bus (ESB). It’s staying quite mum on the topic, but offering its own bus would remain entirely consistent with its strategy to own the environment above the database. Count it sheer coincidence, but the guy who directs marketing for SAP’s NetWeaver platform happened to have come from Tibco.