Everyone involved in Information and Communications Technology (ICT) has been exposed to and most likely impacted by standards in one way or another.

Recent debates over removing the earphone jack from the Apple iPhone 7 was an example. The issue is really about changing a longstanding, reliable standard. What we don’t know, of course, is Apple’s vision for its future products. According to Wikipedia, the traditional TRS (tip-ring-sleeve) connector dates back to 1878 although the basic standard has evolved over time.

Everything from physical wiring to programming languages to encryption algorithms have been subject to standardization; sometimes the result is competing standards (multiple IEEE802 LAN standards come to mind). It is often difficult to keep track of the standards “inventory” and where they apply.

The range of standards organizations

Some people claim there are as many standards organizations as there are standards (although this is not true). However, they are numerous and each has their own sponsors, supporters, processes and mandate. Each organization produces standards or pseudo-standards that are designed for a specific purpose. For example, we have:

  • Formal international standards produced by bodies such as the ISO, IEC and ITU;
  • National standards that are developed or adopted at a country level, such as by the CSA in Canada and ANSI in the USA (and similar organizations in most other countries);
  • Industry/community standards organizations such as the US government’s National Institute of Standards and Technology (NIST) and the IEEE which is an international association of engineers;
  • Consortia standards produced by organizations such as the Open Group, W3C, OASIS and the Cloud Security Alliance (there are too many others to list);
  • Open-source software may not be a traditional standard but the results are often viewed as an equivalent – software developed collaboratively and is available at no charge (see a definition here) can be widely adopted; open source organizations include the Open Source Initiative, the Apache Software Foundation, and the Linux Foundation;
  • De facto standards include a variety of products, services or best practices that are so widely used as to be considered as standard; Microsoft Word and Adobe PDF would be examples;
  • Company internal standards can be adopted by a company, either by referencing industry standards or by developing custom standards or profiles.

Needless to say, standards from different sources are not always mutually exclusive. For example, ISO standards are very often adopted as national standards, and de facto standards can eventually become formal standards (e.g. the ITIL documents). ITU recommendations are typically adopted as standards by telecommunications companies.

Some standards are referenced in laws and regulations and may have formal compliance requirements, although this is less often the case with ICT. ICT standardization is mis-used in an attempt to gain competitive advantage or to discourage adoption of a technology.

Some people would argue the only true standards are those with precise conformance clauses, which leaves out vocabulary and reference architecture standards. Other professionals believe that useful standards do not always have to be normative.

Issues with ICT standardization

It may seem odd, but there is no universal standard for standards, who should develop them and how they should be developed. Each organization has its own methods, tools and voting processes. Additionally, they each have their own ways of reaching out to users and peer groups and for promoting their products.

The ISO, for example, has multiple rounds of National Body voting while the Internet Engineering Task Force (IETF) believes in “rough consensus and running code” instead of paper-based ratification.

There has been much criticism of the standards “industry” and its ability to stay relevant in the current era of digital transformation. One indicator of potential problems is that international standards development methods are at least forty years old. A panel at a recent NIST cloud computing forum and workshop discussed standards development issues and concluded that improvements are needed.

Some of the typical criticisms of standards are:

  1. Too many standards – the perception is that there are a large number of overlapping standards, leading to difficulties, knowing what is important, how things fit together and where the gaps lie;
  2. Too many organizations – for many people it is too expensive and time consuming to participate in development efforts and even harder to keep track of progress; leaving everything to the vendors to figure out is also not a satisfactory solution;
  3. Too little coordination – some believe standards bodies do not work closely enough together and do not cross-fertilize their work sufficiently;
  4. Progress is too slow – it can take five or more years for a new work item to be a published standard, which is a very long time in Internet years;
  5. Standardization is not transparent – barriers, such as membership cost or eligibility criteria may exist. Transparency for both work-in-progress and after completion can be low (although this is starting to change);
  6. Standards are not agile – standards updates lag as technology changes, and typically do not provide the flexibility needed for modern agile systems. Problems with intellectual property and with disclosing trade secrets are examples of difficult areas that inhibit change.

Transforming the approach to standardization

A lot of people, especially in end user organizations, have not participated in standards development, do not know much about the standards process and do not even know who has developed the standards. New ways to encourage involvement, to identify and prioritize user requirements and to develop use cases are all needed in order to attract more participants.

There is also a need for additional community outreach from the various standards committees, and even for university education and industrial training in “standards engineering.” This will only happen if the base standards documents are made freely available to anyone. Again, this is starting but needs to be expanded.

At the end of the day, ICT users and providers all have to challenge the status quo, make standards a higher priority and work closely to improve the process without losing its open, thoughtful and collaborative approach.

This is what I think but you may have a different perspective; always happy to hear from my readers!

Related Download
Ensuring Secure and Compliant Cloud App Use with Symantec Sponsor: Symantec
Ensuring Secure and Compliant Cloud App Use with Symantec
Cloud Access Security Brokers (CASBs) serve as a critical control point to ensure the secure and compliant use of cloud apps and services. Cloud service providers typically maintain a shared responsibility policy for security - they guarantee the integrity of their service infrastructure, but the customer is responsible for securing actual app usage.
Register Now