Standards Best Practices Blog

Going through my bookshelves the other day to make space for new purchases, I noticed a few books that have something to do with standards setting. The accumulation of these books wasn’t necessarily on purpose, but I find these sorts of stories interesting.

Longitude: The True Story of a Lone Genius Who Solved the Greatest Scientific Problem of his Time, by Dava Sobel is a best-selling book that focuses on John Harrison and the mid 18th century invention and further development of timepieces that could be reliably used at sea. The setup for the problem is a discussion of the longitude problem. While the angle of the sun and stars can be easily used to determine latitude, finding one’s longitude relative to a given location or reference point requires knowing the time difference from that location.

There’s a further, very interesting and somewhat fanciful, description of the longitude problem in Umberto Eco’s Island of the Day Before. A shipwrecked 17th century mariner comes across an abandoned ship whose previous passenger may have discovered the solution to the longitude problem. Most intriguing is the description of the wounded dog and the powder of sympathy used to synchronize timepieces.

The primary focus of The Measure of All Things: The Seven Year Odyssey and Hidden Error that Transformed the World, by Ken Alder, is the history of Delambre’s and Mechain’s expedition of 1792-1799 to measure the meridian and hence calculate the length of the meter. The first section of the book has a very interesting discussion of the state of weights and measures in 18th century Europe. Of particular note is the fact of each village having its own set of measures, with often a reference weight or length publicly accessible in the village square in order to promote fair commerce.

While the longitude problem may be a technical, rather than a standards, problem, as with most standards the technical solution must be discovered first and then codified. Once the means of determining a longitude was discovered, it could be applied only after a reference point, the prime meridian, was standardized. This, of course, included the requisite and inevitable political battles over where the prime meridian would be located. In the end commercial interests won out: the Prime Meridian ended up going through the Royal Observatory at Greenwich, or rather through the center of the eyepiece of the Observatory’s main observation instrument, rather than through Paris, because the majority of commercial shipping of the time used Greenwich-based maps.

Once the longitude lines were laid out on the world map, the next step was to apply these lines back onto time – from which they were derived in the first place. Time Lord : Sir Sandford Fleming and the Creation of Standard Time by Clark Blaise is the story of the Canadian engineer and railroad surveyor who proposed and promoted the plan which eventually turned into Universal Time and the global system of time zones. As before, the technical problem had been solved but the issue was politics. (Repeat after me: “there are no technical problems in standards setting, only political.”) The French, out voted 22 to one over the use of the Greenwich meridian as the baseline, waited 27 years to adopt the resolution.

Just about any book written on the history of technology will follow similar themes: the problem at hand, the development of the solution, but then perhaps most importantly – and frustratingly – the fight to promote acceptance of and standardization on the solution. That last step, perhaps the least meaningful at first glance, is sometimes the most important to the success of the invention.

A recent article in InfoWorld discusses the involvement of the U.S. Department of Homeland Security in the development of emergency preparedness standards for private industry.

“Sections of the Improving America’s Security Act, which passed the U.S. Senate March 13, and the Implementing the 9/11 Commission Recommendations Act, which passed the House of Representatives Jan. 9, would authorize the DHS to create voluntary cybersecurity and other preparedness standards. The Senate version would also authorize the DHS to create certification and accreditation programs associated with the standards.”

So far, so good. Government has long been involved in the development of standards.

“One audience member at an event hosted by the Center for Strategic and International Studies suggested the standards would be less than voluntary.”

But this might be a problem. The adoption and implementation of standards, as we generally discuss them, are voluntary. Even the “big I” de jure standards organizations (ISO, IEC, and ITU) refer to their work as “voluntary consensus standards,” i.e. work developed under a consensus process and which are voluntarily adopted.

It doesn’t sound like the DHS standards are being developed under a consensus process, where interested and affected parties have input, but perhaps they are. If these standards become requirements, however, and their adoption is mandatory, I would suggest that they be called laws or regulations instead.

Perhaps this is just another example of the confusion over what a “standard” is.

Any discussion of standards activities will inevitably use a particular terminology to refer to and classify the various types of organizations that develop, approve, and promote standards. The terms de facto, de jure, formal, informal, SSO, SDO, government, sectoral, consortium, recognized, accredited, regional, national, etc. are all used to describe what could generically be called standards organizations.

I’d like to discuss the terms “Standards Setting Organization” (SSO) and “Standards Developing Organization” (SDO) that are commonly used to describe organizations that develop and approve standards.

“SDO” is generally meant to refer to an organization that is accredited or recognized by some sanctioning body, usually a formal body such as a government-recognized or treaty organization such as ISO, ITU, or IEC, or the national bodies such as ANSI, AFNOR, or DIN, and the European regional bodies such as CEN or ETSI. This would include, in the U.S. the Accredited Standards Developer (ASD) organizations which are accredited by ANSI; this accreditation is obtained by applying for the accreditation, demonstrating compliance with the ANSI Essential Requirements, and submitting to occasional audits.

“SSO,” on the other hand, generally refers to a consortium, forum, professional organization, or any private, closed group that develops specifications that it calls standards. The most consistent use of the term “SSO” has been to designate a standards organization that is not formal, recognized, or accredited as defined above. It is generally used as the opposite of “SDO,” and sometimes replaced simply with the term “consortium.” Consortia have generally not restricted themselves to national interests, but develop domain- or industry-specific standards without regard to national boundaries.

I try to avoid using the SDO/SSO terminology because, despite general use, there is no accepted definition of the terms, and more especially because the terminology is confusing and contradictory. In particular, both the accredited ASDs and non-accredited consortia organization will develop standards, so there is no useful distinction in saying that one sets and the other develops. And while an ASD will develop standards, a recognized national body such as ANSI does not develop standards as much as it approves or sets standards; it would thus more appropriately be called a “standards setting organization” rather than a “standards developing organization” though it is usually included in the latter category.

When the SDO/SSO terms are defined, it is usually along the lines of accredited vs. non-accredited organizations. As those definitions are perfectly understandable and considerably more accurate, those are the terms I use when writing about standards activities, together with consortia, recognized, national body, etc.