ebXML == ISO15000

Today, OASIS announced that four of the ebXML specifications have been approved as ISO standards.

On the one hand, I should be somewhat pleased. After all, I invested over two and a half years of my life in helping to breathe life into these specs, especially the CPP/A and Message Service specs. And yet on the other hand, I think that this move will prove to be a mistake in the long run.

What ebXML got right was that it addressed business requirements in terms that the suits could easily understand and appreciate. What it got wrong was that it did not effectively take the pocket-protector crowd's requirements into consideration. Not enough thought was given to address the issue of how the ebXML specs would fit into existing and emerging tooling, runtime platforms and programming models.

Additionally, ebXML was focused on B2B. Yet, as we have come to understand, the needs of B2B are not unique to B2B. So, the IT vendors pushed back and said that they couldn't afford to solve the same problem differently for different domains (B2B, Grid, EAI, Pervasive, etc.), there are only so many development resources to go around. Rather than a top-down approach, they advocated a bottoms-up approach that tackled each technical aspect separately so that they could get the factoring right such that the various components could be composed into a domain-specific solution.

The proponents of Web services (SOAP, WSDL, UDDI and the miriad WS-splat specs) have (unfortunately) to a certain degree been too focused on technology concerns and not enough on addressing business requirements in terms that business could easily appreciate and understand. While we've made great strides with SOAP, WSDL, WS-Security, etc. we haven't done enough to explain how all of this maps to solving domain-specific business problems. Worse, as we move further up the stack, there are competitive proposed standards for transactions, reliable messaging, and federated identity to name a few.

Of course, business has a different set of priorities than the technology vendors. Business is trying to wring out cost where ever it can and is leveraging IT to do the job. The problem is that what business is looking to do is to extend the reach of its systems to those of its partners and customers. However, if every company has a different set of interfaces, then in order to engage, you'd need to develop a one-of-a-kind to match its interface and integrate with your systems. This simply isn't practical and it certainly doesn't scale.

A company cannot dictate use of a single technology for its partners and customers the way that it can for its internal IT environment. And therein lies the rub. Increasingly, companies are looking to standards to guide them as to the one way that they can integrate with the systems of their partners and customers, etc.

The crux of the problem with standards is that unless, and until such time as, the technology has matured sufficiently, the standard is just as much of an inhibitor as it was intended to be an enabler. Jim Waldo wrote about this in his blog a while back.

This kowtowing to the god of standards is, I believe, doing great damage to our industry, or craft, and our science. It is stifling innovation. It turns technical discussions into political debates. It misunderstands the role that standards have played in the past. Worst of all, it is leading us down absurd technological paths in the quest to follow standards which have never been implemented and aren't the right thing for the problems at hand.

I couldn't agree more.

Yes, the suits have real business problems to address, but the pocket-protector crowd, and to a large degree the standards wonk crowd, is still actively working out the "how". As they learn what works and what doesn't and what the best way to integrate these emerging standards into tools, runtime platforms and programming models, and as the various factions defend their various grounds, the technology morphs or is fragmented until things settle down to a stable point at which the community settles on a de facto standard or set of standards.

Let's face it, deploying IT systems is a long term commitment. Business cannot afford to fund IT to redeploy a system just because the underlying technology has shifted, yet that is the situation we are in today. Much of the technology is still unsettled. It is still too soon to be setting things in concrete. Unfortunately, today's announcement may do just that to the disadvantage of everyone.