Thinking about software standards
I was thinking about why we have standards and what they achieve today. I have had 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:
What we get:
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.
EnergySys Limited are looking for an experienced and dynamic Development Team Lead to ensure our continued market leadership. With overall responsibility for the development of the EnergySys Cloud Platform, you will manage the team to deliver incremental improvements, ground-breaking innovations and the product roadmap.
EnergySys Limited, a growing oil and gas software vendor, is looking for an experienced User Interface developer to join their product development team. The role is focussed on the development of the Web User Interfaces for the company’s portfolio of cloud services.
Clear and concise management is key to data success. In order to maximise the value of each opportunity, you’ve got to begin with the data.
IT systems can be restricting rather than rewarding, which leads to companies having to sacrifice essentials. We reckon there's a better way.