The Standardization Paradox

Like me, you've no doubt read countless documents, white papers, books, articles, product briefs, blogs and message boards that tout the promise of BPM. Surely, there's a race for dominance, a contest of wills between competing technologies and standards and a succession of frameworks that represent a “best practice.” The challenge with all this banter is that the inevitable “winner” of this debate will only intensify the very thing BPM promises to eradicate: the need for standardization. Businesspeople like the fact that the guts of the system are hidden under the hood, they like that they can manipulate data elements in a graphical environment, that they can draw their process maps with little stick figures and email icons, and really couldn’t care less what technology is driving the end result. The standard is irrelevant (to them). Or perhaps more accurately, the BPMS they happen to be using superimposes an ad hoc standard on their specific environment.

At their most fundamental level, BPMS technologies enable the knitting together of multiple, disparate systems – across activities, processes, functions, departments and organizations – such that a logical workflow can be managed without excessive manual handoffs into and out of all those separate environments. The wonder inherent in this is that the technology is not only perfectly suited, but consciously designed to be standards-agnostic. A “standard” with which a collection of systems has to comply wrecks the obvious benefit of a BPMS. The value would evaporate, as the formerly disparate systems are readily integrated. Maybe that's where this is all headed. Maybe that's good. (Maybe that's what SOA is all about?)

But there’s another consequence of the adoption of a standard: The need for standardization is rooted deeply in the psyches (and egos) of the technical elite. Their work is astounding – the bodies of knowledge to which they contribute, the codification of ideas to create comprehensive methodologies – is to be applauded. We (business and tech folk alike) are, taken together, one communal brain assembling a massive compendium of knowledge and information, based on the collective experience of thousands of professionals who together represent perhaps tens of millions of hours of learning and work experience. The output is impressive, useful and necessary. But should one idea dominate? If all process maps had to be BPMN compliant and translated into BPEL, would the world really be a better place? Whatever happened to UML? BPML? I know, BPML is so 2004.

The paradoxical point of all this is that it's the competition for being the standard-bearer that accelerates the growth of the discipline, while the attainment of a bona fide standard may mark the inevitable slowing of progress. Standards typically prevail locally - within an industry or geographical area - and/or ephemerally - until some disruptive technology comes along. To achieve their aim, BPMS standards need only prevail organizationally - between and among the stakeholders of a given process within a given organization.