1. The Life Cycle of Standards
Presented by
the International Electrotechnical Commission

2. Aim
This presentation was developed by the International Electrotechnical Commission (IEC) to create a better awareness and understanding of the importance of standards for students of business schools and management of technology, and technology policy faculties of technical universities.
It consists of three lectures:
An introduction to standards and their importance
A discussion of the life cycle of standards, their development, use and maintenance
A discussion of the economic value of standards (i.e. their relevance for business, innovation and international trade).
This lecture series, the IEC Lecture Series II, has been developed for the occasion of the ‘IEC centennial’. It is the second of a series of lectures. IEC Lecture Series I (IEC, 2005) was developed for electro-technical engineers by prof. Donald Purcell. We strongly recommend you to check it up. The lecture series are complementary – a few slides excepted.
This lecture series aims to provide teaching material for roughly 3 x 45 minutes. It represents a selection, a basis for further elaboration. Some extra material and many of the extra references are included in the notes. The references can be found in a separate document which accompanies this lecture series.
Some colleagues provided very valuable comments on and ideas for earlier versions, and/or they allowed us, my colleague Jaroslav Spirco and me, to use some of their own slides. These are in order of involvement: Jack Sheldon (IEC), Marc van Wegberg (University of Maastricht), Mostafa Hashem Sherif (AT&T), Henk de Vries (RSM Erasmus University), and Knut Blind (Fraunhofer Institute for Systems and Innovation Research). We thank them very much for their time and effort.

3. Contents The life cycle of a standard Standards development
Which organizations develop standards?
Open standards
Difficult issues
And after they have been developed…?
Implementation
Maintenance
Standard Dynamics
Summary

4. The Life Cycle of a standard
Development
Implementation
Maintenance
For reasons of restriction we do not address the issues of Testing (e.g. test suites, plug tests, interop events) and Certification here. See e.g. Moseley et al. (2006) on interoperability and conformance testing. See the IEC lecture series I for slides on conformity assessment (IEC, 2005).

5. The Life Cycle of a standard (cont.)
standard development
Revised
Idea
Implementation
Specification
Implementation Process
Maintenance
Succession
New Specification
The standard’s life-cycle starts with an idea and a work proposal. This idea is then developed into a specification and implemented in products or services. Most likely new needs arise or flaws are detected in the standard. This will lead to a standard maintenance activity (i.e. the development of e.g. a new edition or a technical corrigendum).

6. Standards development: Organizations
Formal standards bodies (e.g. internationally IEC, ISO, ITU-T)
Consortia (e.g. W3C, ECMA, OASIS, IETF, Open Group)
Professional organizations (e.g. IEEE)
Trade organizations
Government agencies
Etc.
Next slides: formal standards bodies and consortia

7. Standards development: Formal standards bodies
International, regional, national formal standards bodies
Standardization process is based on
consensus principle
voluntary application of standards
quality of standards
broad constituency of national delegations, etc.
Several features make up the tissue of the formal democratic standards ideology (Egyedi, 1996). The most pervasive ones are:
The consensus principle is adhered to in the most essential stages of decision making, such as the preparatory and committee stage in the ISO/IEC and the approval process in the ITU-T.
They stand to the voluntary application of standards, which is why the ITU speaks of recommendations instead of standards.
There is concern for the quality of standards, an element relevant in all three standards bodies.
Participation is based on national membership (national standards bodies) and not on direct membership of interest parties and companies. ITU's membership of national administrations is similarly nationally oriented.
ISO/IEC strive for a broad constituency of national delegations.
They adhere to democratic working methods by means of a "well-balanced influence of national members" in management bodies of international standardisation organisations and an "open, democratic process of decision-making". Democratic ideals are also evident in the ITU procedures.
All three bodies strive for an impartial, politically and financially independent organisation and procedures.
All three bodies strive for widely used and thus in principle international standards.
ISO/IEC procedures are designed to promote fair competition and fair trade.
ISO/IEC strive for openness in information.
All three bodies strive for rational, technical discussion.
Note that since 1996 some features have blurred (e.g. direct industry representations is acceptable now in some formal fora)

8. Standards development: Consortia
Standards consortia, or specification groups (Updegrove, 1995)
R&D-oriented and pre-competitive
Research consortia (Updegrove, 1995)
Proof of technology consortia (Weiss & Cargill, 1992)
Implementation and application consortia (Weiss & Cargill, 1992)
Strategic consortia (Updegrove, 1995)
Consortia that organize educational activities (Hawkins, 1999)
“Industry consortia differ. Some focus solely on the development of technical standards or
specifications: standards consortia, or specification groups (Updegrove, 1995). As the
CEN/ISSS website indicates, there are many such consortia (CEN/ISSS, 2000). They
may be R&D-oriented and pre-competitive (research consortia, Updegrove, 1995; proof
of technology consortia, Weiss & Cargill, 1992), or focus on heightening the usability of
existing standards (implementation and application consortia; Weiss & Cargill, 1992).
Other consortia foremost aim to promote the adoption of a certain technology and seek
the support of a business community (strategic consortia, Updegrove, 1995). To achieve
a critical mass, suppliers of primary technologies and providers of complementary
products and services must be directed along defined paths (Hawkins, 1998). To this end,
consortia may rally support by organising educational activities for users of standards
(Hawkins, 1999) or by combining promotional activities with specification development.
In sum, although there are many differences between consortia, their common emphasis
is on co-ordinating a segment of the market.” (Egyedi, 2001b, p.13)

9. Standards development: Polarized discussion
Polarized discussion among standardizers about the difference between formal standards bodies and consortia
Formal bodies are held to be too slow (due to consensus)
Consortia are held to be less open
In reality: difference is small*
Of much greater concern to standardizers should be that technologies that should be standardized often - are not standardized
Related to this discussion: What does openness actually mean?
With regard to openness, consortia are held to be less open (closed meetings, lack of consensus, lack of due process). With regard to speed, formal bodies are held to be too slow. The discussion has, however, largely been caught up by recent developments. The difference in speed of standard development is small:
Formal bodies have speeded up their consensus procedures and have diversified their products (e.g. workshop agreements are developed directly by interested parties and therefore need no national backing)
Some consortia have grown and become more bureaucratic (less ‘lean’)
Some technologies may need longer than others (e.g. infrastructures)
Certain consortia are de facto open to all contributors, and increasingly interaction exists between formal bodies and consortia. E.g. common meetings, collaboration and some consortium standards are formalized. The difference is can roughly be summarized as “the principle of democracy for the few vs. the oligarchy of consortia”, as one the reviewers has experienced. (Egyedi, 2006).

10. Standards development: What are open standards?
A standard is perceived as open* (Krechmer, 2006):
By standards creators: if the creation of standards is based on open meetings, consensus and due process
By implementers: if it serves the market they wish, does not carry additional cost, does not limit their innovation, does not obsolete their prior investment, does not favour the competitors
By users: the standard is supported over the product’s expected lifetime, and backward compatibility is provided with previous implementations
The word open in ‘Open Standards’ may refer to a variety of features (Krechmer, 2006, p.33):
Open Meeting
Consensus
Due Process
Open IPR
One World
Open Change
Open Documents
Open Interface
Open Use
On-going Support

11. Standards development: Difficult issues
Participation: Are the right people and parties participating? Backed by the right level?
Should contributions with Intellectual Property Rights (patents, copyright) be included?
IPR policies of standards bodies for essential patents (Bekkers & Liotard, 1999)
Example: IEC policy*
(F)RAND: license technology under (Fair,) Reasonable and Non-Discriminatory terms
Bilateral Licensing, Patent Pool, Patent Platform (Blind et al., 2002)
*Different standards developing organisations may have slightly different IPR policy. However, IEC’s IPR policy provides a good example (ISO/IEC, 2004a):
“ 2.14 Reference to patented items
If, in exceptional situations, technical reasons justify such a step, there is no objection in principle to preparing an International Standard in terms which include the use of items covered by patent rights – defined as patents, utility models and other statutory rights based on inventions, including any published applications for any of the foregoing – even if the terms of the standard are such that there are no alternative means of compliance. The rules given below and in the ISO/IEC Directives, Part 2, 2004, Annex F shall be applied.
If technical reasons justify the preparation of a document in terms which include the use of items covered by patent rights, the following procedures shall be complied with.
a) The originator of a proposal for a document shall draw the attention of the committee to any patent rights of which the originator is aware and considers to cover any item of the proposal. Any party involved in the preparation of a document shall draw the attention of the committee to any patent rights of which it becomes aware during any stage in the development of the document.
b) If the proposal is accepted on technical grounds, the originator shall ask any holder of such identified patent rights for a statement that the holder would be willing to negotiate worldwide licences under his rights with applicants throughout the world on reasonable and non-discriminatory terms and conditions. Such negotiations are left to the parties concerned and are performed outside ISO and/or IEC. A record of the right holder's statement shall be placed in the registry of the ISO Central Secretariat or IEC Central Office as appropriate, and shall be referred to in the introduction to the relevant document [see ISO/IEC Directives, Part 2, 2004, F.3 ]. If the right holder does not provide such a statement, the committee concerned shall not proceed with inclusion of an item covered by a patent right in the document without authorization from ISO Council or IEC Council Board as appropriate.
c) A document shall not be published until the statements of the holders of all identified patent rights have been received, unless the council board concerned gives authorization.
Should it be revealed after publication of a document that licences under patent rights, which appear to cover items included in the document, cannot be obtained under reasonable and non-discriminatory terms and conditions, the document shall be referred back to the relevant committee for further consideration.”

12. After standards have been developed…
Implementation (Use; Egyedi & Dahanayake, 2003; Egyedi & Hudson, 2003)
Maintenance (Update; Egyedi & Heijnen, 2005)
Succession (New technology; Egyedi & Loeffen, 2002)
In the following slides emphasis on the first two.

13. Standards implementation
Sometimes standards are*
not used
used
used, but in a way that breaches the integrity of the standard …
For discussion with students: Does anyone know examples of standards which have not been used? Do you also know why it was not used?
*Examples:
not used, e.g. IEC on ‘IEC system of plugs and socket-outlets for household and similar purposes’
used, e.g. IEC Series on ‘Household and similar electrical appliances - Safety’
used, but in a way that breaches the integrity of the standard …: e.g. IEC on ‘Audio recording - Compact disc digital audio system’. Some manufacturers introduced a change to the standard to prevent people from copying audio CDs, and did it in a way which the integrity of the standard. Certain CDs did not play in ‘normal’, standard-compliant CD players of car radios and certain personal computers.

14. Standards implementation: Malevolent breach of integrity
Breaches in the integrity of the standard can be
Malevolent when standards are corrupted as part of a market strategy (i.e. embrace-and-extend strategy)
This leads to
incompatibility with other genuinely standard-conform products
doubts of end-users about the quality of the standard
To give an example of a malevolent breach of integrity, “(…) in October 1997, Sun Microsystems filed a complaint against Microsoft for copyright infringement. Microsoft was implementing a Windows dependent Java programming environment (e.g. Windows dependent APIs and Java Software Development Kit). Among other things, the Java programs created with Microsoft's Software Development Kit would in some cases only run on Microsoft’s Java Virtual Machine. Furthermore, although Internet Explorer version 4.0 (IE4) did not pass Sun's Java compatibility tests, Microsoft nevertheless used the Java Compatibility Logo on IE4 consumer packaging and promotional materials. Therefore, Sun accused Microsoft of deliberately attempting to fragment the Java platform(…).” (Egyedi, 2001c, p.122)

15. Standards implementation: Benevolent deviation from standard
Breaches in the integrity of the standard are called benevolent when implementers deviate from the standard
knowingly for legitimate reasons: e.g. because a standard is too complex and expensive for the implementer’s use (partial implementation of the standard)
unknowingly: e.g. because of an ambiguity in the standard, it was unwittingly implemented the wrong way
Whether knowing or unknowing, benevolent deviations from the standard usually also lead to incompatibility.
To give an example of a potential benevolent breach of integrity, from 1998 onwards the market for real-time Java was expanding rapidly (in cars, telephone switches, etc.). This part of the Java market posed different requirements on Java. A workshop was organized to draw up the core-requirements for real-time Java. However, addressing these requirements would lead to a fragmented Java market. Sun first tried to block and later take control of developments in real time Java. Thereby, implicitly the legitimacy of the real-time requests for adaptation was recognized. (Egyedi, 2001c, p.123)

16. Standards implementation: Causes of ‘benevolent incompatibility’
Causes of benevolent deviations are e.g.
Errors, ambiguities, inconsistencies in the standard
Missing details in a standard
Too many options (may cause e.g. interference between standard implementations)
Benevolent causes can be addressed more easily than malevolent ones by standards development bodies.

17. Standards implementation: Feedback
Experience with standardss implementation can lead to suggestions for improving the standard
Standards maintenance, in the following slides
Maintenance procedures
Degree of maintenance work
For a detailed discussion of implementation problems and solutions see Egyedi (2006).

18. Maintenance: Procedures
Standards undergo a Periodic Review
A standard can be (ISO/IEC, 2004a)
Confirmed
Revised
Amendment
New Edition
Change of document type*
Withdrawn
*Under the auspices of the formal standards bodies committees may develop – apart from International Standards - different types of documents: Technical Reports, Guidelines, Workshop Agreements. ‘Change of document type’ refers to the situation that e.g. an International Standard can become a Technical Report, and vice versa.

19. Maintenance: Degree of maintenance work in IEC (IEC, 2004)

20. Standard Dynamics
“By definition, a standard is reasonably unchanging; therefore, the only time that an architecture should be standardized is when it is no longer subject to change – and when an architecture is no longer subject to change, it is dead.” (Cargill, 1989, p.70)
Standard dynamics*: Changes to a standard once it has been specified
Previous slide: more standard maintenance than development work
Some degree of change is unavoidable …
A topic for discussion among students is the dilemma between Stable standards and responsive standards, and Technical continuity and improved functionality.
For more on standard dynamics see Egyedi, 2006.

21. Standard Dynamics: What affects technology affects its standards
Source: Egyedi, Since standards are endogenous to technology development, factors that cause technology change also affect standards. The document referred to further specifies the four clusters of causes of standard dynamics depicted in the figure.

22. Summary
Coming back to the ISO/IEC definition of a standard, one of the definitions which the lecture started out with: the aim is to achieve an “optimum degree of order in a given context”, a context which for some technologies changes rapidly. In such situations standards need to be responsive.

23. Contact Information
For inquiries concerning this lecture, contact:
Jack Sheldon, IEC Standardization Strategy Manager, or
Tineke M. Egyedi, Senior Researcher Standardisation, Delft University of Technology, .