Recently I had a chance to do some training in France. I participated in a week of coursework with classmates from all over the world. Some were from France, Spain, Holland, Sweden, and England; others were from even further - the United States and even India. To say the least, it was an eye-opening experience and dramatic evidence that standards and interoperability are important in all aspects of our work as technologists.

Early on in our journey to a service-oriented enterprise we began to realize that for services to work, truly work, they had to be standards based, and, more important, those standards had to trump implementation, so that the services would interoperate as well.

In our training class, English was the language standard for speaking as well as writing. This made sense, as English seemed to be the one language that the class all had in common. The question was posed, for example, since the training was in France, why not have a French version of the class. This seemed a reasonable question to me as well. The answer was that while we were in France, there were many participants who did not speak French. Also, given the international nature of the audience, the question could be posed for many other languages as well. For the purposes of cost containment and the ability to be flexible regarding the content (by only having to update content in one language, not a dozen), a single standard was needed.

This lesson has very similar applications in our work. Not everyone spoke English with equal facility - some were very fluent, while some could understand what was said but had less confidence in their own speaking abilities. Similarly the issues faced by various implementation differences from vendors resulted directly in the creation of the WSI board and its interoperability profile. In our analogy, the basic profile is sort of like a test of spoken and written English that allows users to gauge their ability to communicate successfully with other users. Which is all the basic profile does. It doesn't mean that every word is understood by both parties, merely that they can understand each other. Occasionally we still had to resort to pictures, pointing, or the odd written word to be adequately understood.

I've seen this happen recently due to simple differences in WSDL between the Apache Axis toolkit and one of the commercial ESB products. While the WSDL worked on one side, Apache, it refused to function as is on the bus. Sadly, the developers responsible for this electronic tower of Babel sat right next to one another, so there was no reason at all why they couldn't have communicated with each other and shared the WSDL early enough in the process so that when the integration work was scheduled to happen, it would have gone smoothly.

The coursework did show another amazing aspect of standards and interoperability - how successful people could be when they were able to communicate effectively. During the training exercises, I'd say the average participant spoke at least three languages (I do, but only if you count Latin). Yet we were able to do the work effectively and have very intense discussions around the subject matter, because we all shared one common standard.

In the same fashion, when you consider what the standards that we have now allow us to accomplish, it's pretty remarkable. Ten years ago we had major IT initiatives designed to allow systems to speak with one another (we called it EAI). Sadly, each of those initiatives was in its own language, so at large we still had chaos and no one lingua franca, and no Rosetta stone. Now, thanks to our standards around services, we have achieved interoperability and communication without the need for proprietary solutions and can accomplish the majority of EAI functionality via our existing platforms (with perhaps a few additions such as BPM). Fortunately for all of us, we are no longer speaking in tongues.