|« 2010, the year that changed everything, again||[SOA,BPM,REST] Lifecycle: we are almost there »|
I am generally dubious of "No YYY" movements, but today, I'd like to make such a statement: No more so called "industry standards", No more "specifications".
A long time working group companion, who is one of the best standard editor/writer on the planet, asked me today if I wanted to write 10 pages of an upcoming SOA book, more specifically, the part on "Service Description" (all these great standards like WSDL, UDDI, ... or lack thereof with REST that we know and love). I explained to him that I could no longer promote specifications in any way shape or form and here is why.
For somebody who has spent several years of his career in standards committees, most often on my own time, and sometimes on my own dime, I can say that I believe in the general goal of standards, they have the potential to bring a lot of value to our industry at large. Yet, they rarely do because the process by which standards are created is completely broken (and I would recommend any company to stop funding their participation to standard working groups starting immediately):
a) Working groups are full of humans: pretty much every aspect of human behavior and psyche is at play in a working group. People want to advance their career, capture glory and fame, leave their footprint, hunt their fellow contributors for fun… Sometimes they are plain clueless, most of the time, these people are wicked smart, yet what they produce is almost always garbage. The arbitrary sum of good ideas is generally a bad idea.
b) Standards rarely exist in vacuum: most standards rely on other standards and eventually, before you know it, and especially when all these standards are worked upon in parallel, nothing fits together. The arbitrary sum of standards is generally a bad standard stack.
c) Standards can’t be consumed by mere mortals: after working for nearly 5 years in organizations that are consuming standards (rather than writing them), I can safely attest that less than 1% of the people I meet understand more than a couple of specifications to the level that they use it without major mistake, for the purpose the standard was intended. The sad reality is that most specifications are written in a way that only the people who wrote them can understand their semantics. Most consumers of a spec would glance over it, remember what he or she used to do in a similar context and start claiming that this spec is nothing new and they are an expert since they have been doing similar things for the last 5,10,20 years. Even a spec as simple, elegant and useful as HTTP, even 4 little verbs (GET, PUT, POST, DELETE) are the field of endless debates and frustration about their meaning and utilization in any IT deparment. The attention span of a 21st century human is no more than a 140 characters.
d) Standards are by definition too late: by the time a problem is identified, a working group is formed, a spec is produced and some reference implementations are available, (and all the major players are actually in the position to ship something), not to mentioned it is understood by the vast majority of people, well the industry has moved on and is facing new problems. If by any strike of luck the resulting specification is not out of touch with reality, implementations quickly offer proprietary extensions to make it useful in the latest context. There is simply no process by which a specification can be produced in a timely manner for the industry. (and I am not even talking about the case when a player breaks off from the working group to develop a competing specification)
e) Standards are not “product managed”: the voice of the customer is nowhere to be found, this is the playground of the big boys (there are so few now anyways). Nobody in the working groups cares about the customer. A charter is not a series of requirements. Requirements should be driving the process. That’s too scary for lots of the working group members, they wouldn’t be able to push their little idea, they have tried to get in a standard for 20 years.
f) Standards hamper innovation: they are by definition the common denominator of an industry, i.e. the only things, including the weakest or clueless player, can agree on. And, when "a standard is in place", nobody will dare investing to innovate in that space. Standards in effect create innovation dead zones.
Guys, and gals, standards are a big waste of time for everyone. Specifications are too late, confusing, hard to implement and use, rarely fulfill a need and cannot be articulated easily with other specifications. This is hopeless -let’s face it. If the Spring victory over JEE doesn't teach our industry something what will? Let’s have a big digital auto-da-fe and send all the specs, drafts, notes, mailing lists... to the recycler.
The reality is that implementations win, yes, always have, always will. They may have been based on some kind of specifications written by some kind of working group. But the only reason they become a “standard” is because somebody wrote something that worked and that ended up being useful to a lot of other people. So why not start there? Implementations don’t leave much room for interpretation and if they do, and it doesn’t kill you, that’s ok, bring your own semantics to the party. So let’s stop every working group, let the architects architect, let the developers develop, let the product managers manage requirements and give (a true) voice to the customer. When you think something should be a standard, and it's not too late, open source it - free of any IP- and let the industry decide whether this is a standard or not. If it is recognized and accepted, let competitors build implementations that ensure portability and interoperability with your implementation. Then, only then, let’s write the books and the tutorials and the articles. Heck, even a spec. I am not sure they will needed though, because most likely they will already be using it.
To be a standard or to be designed as a standard that is the question.
I completely disagree. Standards are necessary to achieve interoperability. The process by which certain groups define interoperability may be broken, but abandoning standards is not the right answer.
Do you mean the kind of interoperability that WS-*/WS-I gave us? I am not sure that we really disagree, I am just saying, stop trying engineer standards. That doesn’t work. Rather start with an implementation and have the courage to make it a standard, instead of keeping the techology proprietary.
I would also argue that interoperability at the standard level is an illusion, because vendors control the interop knob at the implementation level and will only implement the parts of the specs that are strategic to them.