04.17.09
How many developers does it take to screw in a business process?
Let’s remind you that we included the word “in” in the title.
We’re not experts on BPM standards, but we’ve never been great fans of BPEL either. It’s one of those things that’s necessary in that, if you want to make a business process executable, you’ll probably need something like BPEL. Imagine slicing and dicing a process down into its constituent workflows, then explode those workflows into a series of atomic steps that at the end of the day look more like computer log files. That’s BPEL for you.
Business stakeholders have long disdained BPEL, with a few of them having deep pockets springing for BPM tools that use their own richer proprietary syntax to generate Java. It’s remained a niche, as classic BPM systems satisfied primarily those organizations with sufficiently complex, but high enough value-added processes that were beyond the scope of packaged software.
So the riddle is whether you can make rich business process models portable. The XPDL folks claim you can, and they have done a thorough mapping to BPMN 1.1 to prove it. XPDL backers claim it gives you the best of both worlds: a rich, workflow-oriented language, and portability. Detractors, like IDS Scheer’s Sebastian Stein, say it’s fine as long as you don’t mind wading through a 216-page spec to do it. As for vendor support, if you’re talking to IBM, Oracle, or SAP, pulling teeth would be easier.
The big enterprise/middle tier players would rather shift the subject to BPMN, which does provide the kinds of visual flow charts and terms that domain experts and process designers understand, and also makes provision for translating those process flows to executables. Sounds fine, except, maintains Bruce Silver, until now the coupling to executables has been too tight. The existing 1.x version requires that those service interfaces and data mappings be specified, which ironically makes them too web services-friendly but not really service-oriented. Yes, BPMN requires you to specify the services that processes steps are supposed to fire, but on the other hand, it violates a key precept of SOA which is that there should be no dependencies. None. Zilch. Not even to an otherwise loosely-coupled service. (Silver hopes that BPMN 2.0 will more effectively support portability.)
But at the end of the day, you have a process that you need to automate, it’s not covered by Oracle or SAP, and you don’t have a quarter million dollars for a big BPM tool. Active Endpoints, which began life as an OEM supplier of BPEL technology, has taken the approach of saying, leave it to developers. Not the rocket scientist Java EE or C# folks, but the departmental developers used to VB.
OK, maybe the $30 – 50k is a bit rich for a departmental app, but in fact, it’s probably more the sweet spot these days for corporate IT which needs to stretch its dollars. But the guiding logic looks quite similar to what drove all those departmental VB apps that often snuck through the back door under the radar of corporate IT: business units needed solutions and couldn’t afford to wait at the back of the line for corporate IT to burn through its project backlogs.
ActiveVOS, which is Active Endpoint’s product (a mouthful for a small company, yes?) takes a RAD approach to making BPEL just a little less BPEL. Instead of seeing endless lines of BPEL XML, it aggregates the BPEL into process steps that look a bit like the workflow diagrams that business process analysts consume. It also provides capabilities like process rewind, which are a lot like transaction rollback – if a live process starts to go bad, you can get a bit of a do-over and roll it back (data and all) to the last decent step. And yes, it will translate BPMN, because as you might recall, BPMN was designed to translate to an executable (we won’t dredge up all the baggage again).
Given that the product is still young – sales only picked up last year with release of version 6 – it piqued our attention that in the first crappy quarter of this year, the company’s business still went up 20%.
Obviously, there is no single silver bullet approach to BPM that will work for all comers. Maybe in part that’s been a speed bump impeding development of the BPM market, or at least one that is obviously identifiable. On the other hand, maybe that’s not the point, as the prize really is to keep application development as closely aligned with the business as possible in an era of reduced budgets, whatever it takes. ActiveVOS’s emergence reflects the fact that departmental VB-style development remains very much alive, and in many cases, the shortest path between two points. And if it leverages BPEL so be it – that’s the execution language that WS-* web services understand.
It’s one of a number of emerging model-driven approaches that hope to make what was traditionally tactical application development more coherent and less random (the same point behind Microsoft Oslo, for instance). The rationale is that models are easier to manage and replicate, as they abstract physical implementation from content or core logic. We’re currently studying various approaches to what we’d call Business Whiteboarding which provide simpler onramps for business people, not developers, the ability to more formally declare what a process is, or what their core business requirements are, so there’s less game of telephone and finger pointing, and more accountability for the software that results at the end of a project request.