This is the first of a short series of articles on the topic of standards. This article is a general overview of how the standards development world really operates today, with inside information on some of the big issues that end users (architects and developers) should know when they want to take a dependency on standards in development work.
Other articles in the series will explore in more depth some of the key specific issues influencing the world of standards including on-going efforts to get convergence between all the standards, demystifying the topic of intellectual property in standards, and appreciating open standards.
For today, when looking at the quality of standards, there are a few different perspectives to keep in mind. There are those that implement the standard, and need to somehow make it real. There is another perspective from the Standards Development Organization (SDO) who operate a development process to make (publish & maintain) standards. Standards organizations always want to raise the public’s expectation that their standards are relevant and that they are serving a community. But on the front line is the architect, often faced with an avalanche of different standards to choose from; and should / can architects expect more from standards?!
Standards are a key element in Microsoft's software business strategy. Standards provide a focal point for cooperation between Microsoft and a diverse group of participants, customers, industry partners, competitors, and researchers so it should not be a surprise to find that Microsoft actively participates in and contributes to hundreds of standards development organizations worldwide; including ANSI, ISO, ITU, W3C, SWIFT, and many others.
The International Standards Organization (ISO) says “Standards are documented agreements containing technical specifications or other precise data to be used consistently as rules, guidelines or definitions or other characteristics to ensure that material, products, processes, and services are fit for their purpose”
Independent of definition, it’s good to look closer at the organization publishing a standard and get an idea of how they go about putting the new standard together; to get a better idea on how relevant or representative or stable the standard might be to use.
Peeling back the surface on how a SDO works, standards developed within committee’s are usually the end result of some lengthy consensus gathering process to agree on ‘something’; most often with compromises and usually with limitations or exclusions on what may not be in the standard. Typically new standards don’t make promises about features and functions what might be in next versions, which may still be under intense committee design reviews. The standard itself usually tells you what it only does here and now. In practice the best way to find out what is not in the standard or what might be coming in any next versions is by actually reviewing the standards committee minutes and notes; which may or may not be open to the public.
How each SDO proposes new work, how they go about doing a formal validation on something new to prove that it can work, how they formally define who is allowed to vote or approve the new standard and a much longer list of other organizational characteristics are what makes one SDO different from another. Nothing could be more varied than the theory and actual practice of the different organizational and their governance structures, when you look at how one SDO works compared to another SDO.
There is no standard way of running standards organizations. Taking some lessons from best practices in software development processes, a helpful structure on how to look at SDO work groups in a common way (which some SDO’s follow) could be described as a ‘Standards Open Development Process’ with the following steps:
- propose a new specification, and call for open participation to the development project team.
- compile and verify a requirements list, for the new specification.
- write the first working draft of the new specification, in the project team.
- refine and approve the first working draft within the project team.
- go through a public review of the draft specification, with people outside of the project team.
- do some form of real world implementation verification of the draft specification, to check that it can work as advertised.
- do any final revisions, address any review comments (correct the spelling) and release the final technical specification as the new ‘standard’
- Do maintenance on the standard, and if needed go back to the first step to put together the next version of the standard.
In terms of different types of standards themselves, there are basically just a few different classes. De facto standards are usually established by broad market share and popularity. When a particular owner of a technology has a large enough market share, the technology is said to be a de facto standard. De jure standards are those that have been defined or designed by committee and sanctioned by some legal organization with jurisdiction. In terms of getting things done, de facto standards have proven themselves by market adoption, while de jure standards often still have to prove themselves as the standard gets first offered to the market.
There is a third type of ‘standard’ which technically is a ‘specification’, but masking itself as a ‘standard’ and that is typically created by industry groups or consortia. These industry groups are typically communities with a specific industry interest focus, like finance or retail, and as a community what they actually produce are ‘technical specifications’. Many times, consortia will submit their final technical specifications to other de jure standards bodies for ‘standards accreditation’, but in many of the cases the development of the technical specification still remains within the consortia.
In making a standard though, SDO’s usually have organizational staff who try to foster communities of partners, vendors and customers to come together. SDO members typically volunteer their own efforts to work at publishing something they hope one day everyone will agree can be commonly used as a standard. The operative word here is ‘volunteer’ as many standards are often entirely volunteer driven content creation work programs. The more driven and the more depth of volunteer experts participating, the faster and more quality of standard that usually gets produced; or the corollary to that is be cautious of any effort that has taken over a year just to gather a list of requirements.
There are many popular misconceptions about all standards, including: once standard - it will never change, standards are easy to implement, and standards are complete for implementation.
There is also a common perception that standards are slow to develop, often falling victim of a ‘design by committee’ mentality, which probably is a deserved reputation for some standards work; but no one ever promised standards development was going to be a fast process.
Many progressive SDO’s have recognized their members needs for faster developments and at the same time are trying to avoid being caught up under their own weight of lengthy formal operating procedures. Some SDO’s have adopted more streamlined, ‘fast track’ development (or approval) programs. ‘Fast tracking’ largely relies on the standards specification work having been done outside of the normal standards committee process, with the usual assumption that only a matured specification gets ‘contributed’ to the SDO for ‘fast track approval’. Although a subtle, often misconceived perception, but important distinction is many fast tracked specification never get the ‘highest standards ranking’ inside the (de jure) SDO; i.e. they are not ‘full quality standards’. Again, how the ‘contributions’ get made from outside into the SDO and how the ‘fast track approval process’ functions are just some of the reasons why so many SDO’s have such different governance rules.
In our rapidly evolving, increasingly complex and competitive world, the question people often face is ‘do you wait for something to be a standard, or just start early’; or is waiting for a standard really a safe business bet to make? The answer is very much an individual responsibility but the real value of a standard depends on the number of other users also using the same standard; the more end customers, the greater the network adoption effect and typically a better track record.
There is an avalanche of duplicative standards efforts these days between different SDO’s, and in some cases even within the same SDO. Someone once wrote: “The nice thing about standards is that you have so many to choose from. Furthermore, if you do not like any of them, you can just wait for next year's model." What typically happens these days, in an effort to grow, is a SDO wants to expand its membership and the best way to do that is to looking beyond its original scope of work. With so many efforts already underway, as SDO’s expand they typically end up creating duplicating standards efforts to other SDO’s.
With so much duplication of standards efforts, it becomes almost impossible to make simple architectural decisions about which standard to use; without also considering a whole host of other design factors. The convergence of standards is an especially hot discussion topic today, for a lot of user communities. The convergence rallying cry usually starts by trying to get the various SDO’s to start or better talk to each other, with the intention to align their respective work programs either by agreeing to joint development programs or by establishing formal liaisons between their working groups.
There isn’t any definitive, publicly and easily accessible up to date directory on all the work all the standards organizations are doing but outside of the standards efforts a lot of people these days are discovering new ways to reach out and publish information; such as blogs. Wouldn’t it be nice if SDO’s had a ‘standard’ digital signature Web Service for themselves, of what it was they all were doing, so that finding out who is doing what might be more easily discoverable?
But what are people, the end customers, hoping to get from a standard? Taking a standard, just because it’s a standard, or doing standards for standards sake could be someone’s policy but ‘blind faith’ might not always be the most efficient use of effort. In the final analysis, the ‘quality’ of a standard to meet the customer needs is a determining factor in the standard’s longevity and market success.
A more interesting question about today’s SDO’s might be, ‘are standards organizations today well equipped for the future and proving they are staying in sync with today’s real world business needs?’
The perceived benefits sometimes promoted by a SDO of its new work, can be always questioned. All new standards are not all new guarantees, and in today’s highly competitive world it is a fact that it takes an increasingly significant amount of highly skilled development effort and significant funding to come up with new standards that are very practical, fully validated and fully readily for everyone.
Still no one is promising standards development is a quick process and for the limited number of subject matter experts, often finding the time to attend the many voluntary standards meetings can be half the battle in making a SDO work.
In the final analysis, it is the quality standards that ring at the cash register and end up justifying their ROI. Choosing the right quality standard is an individual choice. The choices are (too?) many and being aware of where and how standards (and technical specifications) came from does help architects make better decisions.
