The risk continuum for standardization success

October 31, 2009

Following on from the three stereotypes of standards approaches: so you have a standard. Now, how likely is it to succeed, or at least to be implemented (since standards more or less necessarily fail if they're never implemented)?

Well, that depends on the specific standard. But we can ask what the continuum of risks is for each stereotype of approaches to standardization.

At one end of the continuum is pure documentation, where the behavior the standard calls for already exists and so the standard is 'implemented' the moment it's written up. Vendors don't need to implement anything, they just need to not change anything that you've documented.

In the middle is coordination; vendors have to implement something, but they've already agreed to do so. And from there to the far end are the various ways you can approach invention, ranging from talking a lot to vendors about what they're happy with (but not requiring explicit agreement to implement before you go ahead with the standard) to basically having no contact with would-be implementors at all.

In addition to the 'will anyone build it' risk, there is also the 'will it actually work once implemented' risk. Documentation has no risk here; you know it works, because it already exists and you presumably wouldn't be standardizing it if it worked badly (yes, I'm an optimist). Coordination has some risk but the vendors should be convinced that it will work before they agree to it, and invention has various levels of risk depending on how you go about inventing the standard.

Well, sort of. The coordination versus invention division breaks down here because in both approaches you need to decide what to specify, and whether the standard is useful has more to do with how you go about making those decisions than what is going on around those decisions. I do think that coordination has somewhat lower risks because the vendors have more riding on the standard working (if it doesn't, they have probably wasted the effort of implementing it), but vendors can make howling mistakes too.

That the pure documentation approach has such low risks of both implementation and usefulness goes a long way to explaining why it has such a high appeal.

Written on 31 October 2009.
« Understanding hash length extension attacks
My thoughts on why invented standards succeed or fail »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Oct 31 01:47:14 2009
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.