Standards That Work

I was thinking about why we have standards and what they achieve today. I have had a fair bit of experience both as a consumer and producer, dating back to working on X.400 in the 1980s through the many ‘standards’ in software through to the current day. In almost all cases these technology standards have, to some extent, failed. None raised themselves up to manage to be the thing the writers intended. At best they just grabbed a foot-hold or a niche. In this post, I will discuss the reasons why.

What we want:

  • Clear
  • Simple
  • Unambiguous
  • Adopted
  • Useful

What we get:

  • Dense
  • Complex
  • Contradictory
  • Partial
  • Unapproachable

The worse kind are the standards proposed by a party with a vested interest. Here there is no standard at all, just lip service to wrap something you already have. Next worst is where a huge body, standards organisation, or academics devise one from basic principles. Theses tend to be interesting but unused. Not everything that follows one of these routes is a disaster. The internet, the web, and some programming languages have managed to get past this. But, in my view the best kind, warts and all, seem to be de facto. Here you get:

  • Something people are using already
  • Business demand is present
  • People need it to work in each and every release or it will fail

So what does that mean for us?

Standards need not be created, but can be formalised from existing use. Business needs wins over theoretical ideals, no matter how well intentioned. A lasting standard needs to have business leadership and demand, across more than one company.  These factors broadly come from the basic business need. So maybe that is all. Success lies in multi-consumer and multi-vendor acceptance and not some higher purpose. Accidental creations, such as the web, or a three pin plug (international versions apply), come from a business driver creating the need for adoption, more than a clean sheet. Standards with no business use cases are doomed, and business use cases derived without the engagement of more than one business are likewise doomed. They sometimes survive where regulation creates the demand, but fundamental is the need to make sure there is value gained by business in adoption. Without this, there is no return on anyone’s investment. Engagement of the people who have the fundamental business need is the key to success. Often this seems to be missing, or the diversity of the business environment is neglected, drawing needs from essentially just one class of consumer.

This is where community and collaboration may help. The long running RFC system adopted by early technologists might be a good model of how this can work. They were building standards for technologists and they engaged with other technologists. That is what we need in oil and gas; engaged business users telling the technologists and vendors what they really need. Do it the other way round and and we will continue to get islands of technology that, while individually quite good, do not add up to a cohesive business system.