By now, you’ve likely grown jaded to the cliché that the nice thing about standards is that there are so many of them to choose from. Today, a more appropriate statement would say something like, the more standards, the less standardization.
Such an argument could be made for the proliferation of WS- standards that has helped web services technology mature into precisely the same kind of bifurcation that has afflicted Java. There are the building blocks that everybody supports, and then there is WS-everything else. No wonder there is a WS-I in place to define interoperability tests for the building blocks that are supposedly not in question.
So in spite of the noise, and the fact that of course, there will be separate but equal camps for things like federated identity, a consensus has emerged that web services are the protocols where vendors will theoretically pay more than lip service to interoperability. If you had any doubts, just look at what the BPM community is up to.
Traditionally BPM vendors competed on their ability to abstract higher level business processes from the programmatic logic that comprised software applications. Much of the value-add was in the modeling language and environment, which was typically proprietary. Excluding XPDL, which originated from the document workflow world, there was nothing in the way of standards until the BPMN modeling notation materialized several years ago (more about that in a moment).
When it came to execution, processes modeled through BPM were typically exposed through generation of C++, and later, Java or .NET code, and integrated through use of adapters. With emergence of web services, BPM vendors began using the basic WS- standards, both for exposing their own processes and for replacing proprietary integration adapters. In some ways, this reminds us of classic 4GLs, where the programming language and visual design environment was proprietary, but execution leveraged various de facto standards (typically dialects of SQL, or more generic ODBC/JDBC).
As we noted several weeks back, there’s a growing tendency for BPM vendors to ace out the code generation piece entirely. The obvious benefit is that you streamline the process by eliminating a step. In this case, you dispense with the need to continually sync code with the process model, which is one way to avoid bugs, discrepancies, or in extreme cases, potential compliance issues. You may also change the roles that software developers play, but even if you dispense with code generation, there’s still software involved, and with it, software developers.
But in so doing, BPM vendors firm their hold on process execution in a manner similar to those of enterprise application vendors, whose source code is practically impregnable.
This week we saw more evidence of the growing reach of BPM vendors as Pegasystems began disclosing its plans to deepen its penetration upstream in the BPM lifecycle. In this case, it was over plans to add its own requirements definition, project management, and testing capabilities. In essence, creating the BPM version of the application lifecycle management offerings (ALM) that you would otherwise see from the likes of IBM/Rational, Borland, Serena, Mercury, Compuware and others.
The Pega folks claim their customers – who tend to skew towards the higher-end, complex BPM implementation – have been asking for more tooling that could talk business process natively. They claim that existing requirements tools tend to be more developer than business analyst or process architect-focused, and they also maintain that conventional functional testing tools don’t adequately cover BPM because, unlike conventional applications, the screens generated by process management systems are far more dynamic and not easily exercised using typical GUI test approaches.
Understand that we’re not making value judgments about proprietary vs open here. Unless you’re an open source vendor whose lifeblood is selling support subscriptions, you need to offer some unique value-add that is likely to include some dose of unique technology. For BPM, the secret sauce is expanding from process modeling and definition to execution, and in some cases, the tooling that supports development.
Consequently, while BPM sells integration, it is horizontal integration of assets that in most cases are locked away in vertical application or database silos. Significantly, BPM vendors are not selling integration with other BPM systems. Sure, virtually all plan or already support BPMN. But keep in mind that BPMN was developed, not as a process model integration language, but as a notation for mapping to execution languages. Of course, if you expose that BPM process (or for that matter, any application or database functionality) as a service and properly implement a SOA architecture that loosely couples those services, voila, there’s your integration.
Consequently, when it comes to process integration, all roads lead to Rome, which in this case, happens to be web services.