Standards 101: A Tutorial for IT Managers

NJIT CIS 679 Management of IS -- Spring 2000 Term Paper

Morgan C. Benton

May 7, 2001

Abstract

            The importance of IT standards has increased over the past ten to twenty years.  Increasingly IT managers must make decisions regarding the adoption of standards for IT development This paper is a tutorial for managers in the basics of standards, what they are, why they are important, how they are developed, and what considerations are important when making the decision to adopt a standard, or to develop a new one.

 

1. Introduction 

            Should information systems developers incorporate standards into their development projects?  Answering this question requires the IS manager to have a great deal of understanding about standards in general, and specifically about the particular standards that relate to current development projects.  Faced with the multitude of standards that currently exist or are under development gaining such understanding can be a daunting task.  This paper will tutor managers in the basics of what standards are, and where they come from, and it will provide concrete guidance in the identification and evaluation of potential standards for adoption in a development project.

            Why have standards?  Some standards, such as the metric system of measurement, are so stable and entrenched that we hardly notice them.  In other fields, such as human language, the appropriateness and desirability of a universal standard is a very difficult question with deep cultural, political, and social ramifications.  On the one hand the great advancements of the last several hundred years are due in large part to standard methods for doing work, a perfect example being the industrial revolution.  On the other hand, the lack of standards creates opportunity for businesses to earn profit and market share by branding a specific solution to a problem.  Microsoft is the classic example, capturing the market with its Windows operating system, in essence becoming the standard while the industry was still too young to have developed a more egalitarian solution.  Even though they risk losing the profits associated with proprietary solutions, most every major corporation today is involved in the creation of standards and managers must understand why.

            All standards are not created equally.  On one end of the spectrum are the highly formalized, carefully crafted standards created by democratic international bodies such as the ISO.  On the other end lie market driven de facto standards, such as the MS Windows OS, which derive their influence from widespread adoption.  In between are standards developed by consortia, which seek to maximize the benefits and minimize the detriments associated with both formal and de facto standards development processes.  It is crucial to find out who is responsible for the creation of a standard, how they have gone about creating it, and what potential traps or benefits exist because of the creation process.

            With this basic information the IS manager is ready to begin making the difficult decision about whether or not to adopt a given standard.  The manager must look at the criteria for successful standards, such as technical quality, timeliness, effectiveness and widespread adoption (Updegrove 1998).  In addition many other factors must be weighed including the need/desirability for compatibility or interoperability with other systems, the existence or cost of acquiring the necessary skills and expertise needed to implement the standard, the strategic importance of adoption, the stability of the standard, and the consequences of not adopting the standard.  In some cases, making this decision will be relatively painless, as in choosing a target operating system or web browser for a new system.  On the other hand, choosing a programming language may pose more of a challenge.  The size and influence of a company may also have an impact on the decision.

            In summary, after reading this paper an IS manager should have a solid grounding in standards, their creation, and the risks, factors, and challenges involved in evaluating the appropriateness of specific standards for specific development projects.

 

2.  What are standards? 

            As with most academic definitions, general agreement on a single definition of a standard doesn't exist.  Looser definitions refer to a standard as "any [technical] specification that has been agreed [upon] by multiple parties" (Oksala 2000, p5).  Stricter definitions define a standard as:

a “document approved by a recognized body that provides, for common and repeated use, rules, guidelines, or characteristics for products or related processes and production methods with which compliance is not mandatory.” The [WTO Agreement on the Technical Barriers to Trade (TBT)] defines an international body or system as one “whose membership is open to the relevant bodies of at least all members (of the World Trade Organization (WTO)).” Thus, an international standard is one approved by an international body. International standards for our purposes are those accredited by the following entities: International Organization for Standardization (ISO), International Electrotechnical Commission (IEC), International Telecommunications Union (ITU), Codex Alimentarius (Codex) and a handful of others. (Willingmyre 1997, p190)

 

In the most basic sense, human languages, which are standards for communication, existed well before there were methods for writing them down, which means that even written form is not necessarily a requirement.  However, for our purposes, standards for use in IS development are useless if not written down somewhere, and if they are not accessible to those who would use them.  As we shall see later, strict definitions for standards such as the WTO definition described by Willingmyre above are not necessary to build products that will have broad market acceptance, even by government agencies which generally have more stringent procurement restrictions.  For that reason we will take the more relaxed view that standards are written specifications of methods, processes, technical requirements, or other guidelines agreed upon by some segment of the user community.  Users, in this context, would refer to both the developers of products based on the standards and the users of those products.

 

3.  Types of Standards 

            Several authors have divided standards into various classes.  Each divides standards into various types which are not necessarily compatible with one another but each of which is instructive in its own right.  Most of these are very general guidelines, but identifying the type of standard one is concerned with can give the IT manager extra insight into the probable time and cost involved with adopting or developing it.

Batik (1999) claims that more than 90% of all standards fall into four categories: design criteria, dimensional, specifications, and test methods.  Batik is mainly concerned with the amount of time it takes to develop given standards, and the effect of that speed on the resulting products that are built using the standards.  Dimensional standards, which describe the physical dimensions of objects, take the least time to develop.  Design criteria and specifications, which are both concerned with the actual building process, take a moderate amount of time.  Test methods, which define levels of product quality and conformance to the design criteria, dimensions, and specifications, take the most time as they require various groups to actually create products and then go through the process of testing them with various methods.  Standards development can take days--as when in 87 days the US government, petroleum companies, and car manufacturers collaborated to push through a new test method for octane levels during the 1970s oil embargo (Batik 1999).  It can also take several years or more and then fail--as when the ISO/IEC JTC1 committee was developing the Open Systems Interconnection (OSI) standard (Cargill 1997).  Thus being able to gauge the amount of time it will take to develop a standard is an important skill for IT managers.

Lowell (1999) describes standards in terms of their intended uses.  Standards can be used as a basis for government regulation of an industry, or to describe quality and safety levels for use in determining a producer's liability when a user is injured.  Standards can be used to make policy decisions, or to set the boundaries of broad infrastructures.  In these preceding cases, Lowell argues that risk and public interest cause the need for a thorough and balanced standard to exceed the need for a speedily produced standard.  Alternatively, standards can be used to guide the development of new technologies, or to wage combative campaigns for market share.  In these latter cases, the strength of the vested interests of individual players can provide insurmountable obstacles to broadly participative standards development.  Therefore, understanding the probable use of standards and the context in which they are being developed is also crucial to making intelligent decisions about standards adoption.

A third way to subdivide standards is by their source.  A great deal, if not most of the literature on standards for the last five years involves the question of the importance of the source of the standard--more specifically how representative and democratic was the process used to create that standard (Cargill 1999, Lowell 199, Lynch 1998, Oksala 2000, Willingmyre 1997).  The last twenty years has seen a sharp rise in the influence of consortium-developed standards, and decline of traditional standards development organizations (SDOs) such as the ISO and ANSI.  This has caused quite a bit of debate about the relative merits of the different types of standards development organizations.  We will go into this topic in more depth, and attempt to provide an up to date opinion later in this paper.

 

4.  Why have standards? 

            It doesn't take a great deal of reflection to reach the conclusion that by and large human societies benefit from the existence of standards.  Some authors believe that the development of standards is the primary reason that human society has been able to develop (Krechmer 2000a).  The International System (SI) or metric system of weights and measures perfectly exemplifies the benefits of standards to society.  It is difficult to imagine the loss in productivity and the increase in redundancy that would result if every nation, state, province and locality devised its own system for measuring objects.  Actually this was the state of the world not too long ago.

Historically, human language was probably one of the first sets of standards, followed by writing systems, measurement systems, and more recently by specifications of processes for production and even the management of those processes.  It is easy to see the cumulative nature of standards--it is impossible to conceive of a TCP/IP standard without a multitude of other standards that make such communication even possible in the first place.  Krechmer believes that we have reached the stage where we must now begin specifying not only standard processes, but also standard methods of adaptation between related processes or redundant processes.  He describes these adaptive standards as "etiquettes" (Krechmer 2000).

            Long and firmly established standards, such as SI, clearly benefit us and don't make for an interesting discussion for IT managers.  What we are primarily concerned with is those fields where a standard is non-existent, immature, less than satisfactory, or where competing standards exist.  We are interested in questions like, does the existing set of practices or evolving standard meet our needs?  Do we have the clout and/or resources to successfully create or contribute to a new standard?  Would these efforts serve our business ends?  Is there a moral imperative to work toward standards?  What are the ethical issues related to the process of creating a standard?  Perhaps the answers to these questions are ultimately personal and need to be found through discussion and exploration at a personal or company level.  However, these pursuits will be aided by a thorough understanding of the process, which is what will be discussed in the rest of this paper.

            In summary, the question of "why have standards?" is not difficult, and can be answered with minimal reflection.  We know that in the long run standards are beneficial.  In fact, it is arguable that standards are inevitable products of our evolution as a species, that we as a species have a deep-seated compulsion to create them.  Compulsion or not however, as Lynch and many other authors frequently remind us, "Standards are not free" (Lynch 1998, p1).  A great deal of financial and human capital must be spent in their creation.  Few companies or groups can afford to do this merely for altruistic reasons; companies need clear, compelling rationale why their contribution to or adoption of a given standard is a wise use of their precious resources.  IT managers need to be able to develop this rationale as part of the business case in a development project.  The following discussion should help managers prepare that case.

 

5.  How Standards are Developed 

            In general there are three ways in which standards come into existence.  The first is through nationally or internationally recognized standards development organizations (SDOs).  SDOs are the most rigidly structured and in many cases the most democratic and well-respected source of standards.  On the other end of the spectrum are de facto standards.  De facto standards are created unilaterally by a single company, and even occasionally by a single individual.  Their success as standards relies on their widespread adoption and market dominance.  In between SDOs and de facto standards are those standards created by consortia of companies concerned about the form of a developing technology.  Consortia seek to overcome some of the weaknesses of SDOs, and have a greater chance of success at becoming widely adopted than if they were created by individual companies as in the case of de facto standards.

            Each of these sources of standards goes about its work in a very different way, and with very different motivations.  Exactly how a standard was developed has a great impact on how it may be used, and consequently on the decision to adopt it.  The following section will describe each process in detail, with examples, and discuss some of the implications that process has on the decision to adopt.

 

5.1  Standards Development Organizations 

            The defining characteristics of SDOs which follow a very formal standards development process are:

·        broadly inclusive participation structures composed of representatives from all members of a given class; e.g. an international SDO must include a representative from each nation

·        open discussion and debate of all issues

·        due process meaning opportunities to lodge formal complaints and appeals to the establishment of given standards

·        democratic voting procedures

·        emphasis on consensus as opposed to majority or plurality rule

Perhaps the most well known SDOs with respect to IT standards in the US are the International Organization for Standardization (ISO) and the American National Standards Institute (ANSI).  In actuality these bodies are generally not the authors (or at least not the main authors) of the standards which they sponsor.  Specifications are created by various groups from individual companies, to governmental consortia from several countries, and these documents are then submitted to the SDO for approval.  The SDO then follows a highly specific process whereby the proposed standard is first drafted, circulated to all members for review, discussed, amended as needed, and so on, until it is finally approved and adopted as an official standard.  In other words, the main function of most SDOs is to manage the process of standards approval to ensure that it is fair and legitimate.

            Standards, by their very nature, are highly technical documents that require developers who have expert knowledge and significant experience in the fields being addressed.  Standards must be of the highest technical quality possible, else they will not be widely adopted.  Hence participants in the development process must generally come from among the top practitioners in their field.  Naturally, these people are usually employed in the industry already, which makes it necessary for their employers to officially allow them to have the time and resources to participate in the standard creation.  It is significant to recognize that regardless of the type of organization issuing a standard, often the group of people who wrote the standard will not change.

 

5.1.1  Benefits of SDOs 

            SDOs have been widely and loudly criticized in recent years, but before we examine that criticism we will discuss the benefits of standards derived from SDOs.  First, standards issued by SDOs have a high degree of legitimacy derived from the process which created them.  Batik (1999) cites that in over 100 years, with more than 40,000 voluntary SDO standards in existence fewer than nine have faced opposition in the courts.  In comparison, standards from other sources frequently face such lawsuits by organizations opposing the standard issuer.  In this sense, adoption of an SDO-backed standard is the least likely way to incur legal opposition from any competitors.  It also means that products based on the standard will be acceptable to most any governmental organization under which the SDO is recognized.  Although they are becoming more relaxed recently, traditionally procurement by government agencies (a major customer to some businesses) was tightly controlled by regulations regarding the quality of products being bought.  Now such agencies have more freedom, but it is safe to say that SDO-backed standards will always be the safest bet when creating products to be used by a government.

            Second, SDO standards offer stability.  Because they are so widely evaluated and because they require consensus, not mere majority vote, to be approved SDO standards generally arrive in a more mature format that is less likely to contain major flaws.  Other standards are subject to change, sometimes without notice, which could possibly cause major problems for a development project.  Indeed, a substantial change in the standard upon which a project is based is tantamount to a major requirements redefinition, one of the main reasons for runaway projects.

            Third, SDO standards offer support.  SDO standards must be updated every five years.  Each time this happens the previous standard is thoroughly reviewed and a recommendation to extend its approval, amend it, or retire it is made.  This review process is subject to the same rigid processes that the initial approval faces and hence carries with it all of the other benefits (and liabilities) that the initial approval brings.

            Lowell (1999) identifies some key cases in which SDO standards are all but necessary.  The first is in the case of governmental regulation of industry.  In this case any standard which is not free of partial influence by individual industry members will not be satisfactory.  The second case is in relation to safety and quality standards.  Particularly in cases where a company is being sued for negligence over the safety of its products, ably demonstrating that products are in conformance with SDO standards is a cornerstone defense, which while not guaranteed, has shown good results for companies in the past.  Lowell also describes situations where there is extremely high risk for first movers as prime candidates for SDO standards.  As an example he posits the future of automated transportation systems such as smart highways.  The potential risks in terms of human life, and in setting up a national infrastructure are likely to be too great for any single company to bear.  Lowell's last case for SDOs involves general situations where the quality of a solution is more important than producing a quick solution.

            In summary, in terms of their political, social, and philosophical foundations SDOs are on solid ground.  SDOs are probably an example of one of our global society's largest triumphs in terms of representative and democratic decision making.  They are a consistent source of high quality, legitimate standards that stand up to the most rigorous tests of quality.  In some cases they are a necessity.  As we shall see, however, there are a number of problems with SDOs, some more substantial than others, that have given rise to the growth of standards-setting consortia.  In the next section we will examine this criticism.

 

5.1.2  Criticism of SDOs 

            SDOs are under attack.  The US National Committee for Information Technology Standardization (NCITS) went from about 40 active members in 1989 to 19 not-so-active members in 1998.  The International Organization for Standardization/International Electrotechnical Committee Joint Technical Committee 1 (ISO/IEC JTC1), once the world's premier issuer of global IT standards has lost participants on the order of a drop from well over 5000 in 1993, to around 2100 in 1999 (Cargill, SIIT99).  A number of criticisms have been made(Batik 1999, Lowell 1999, Willingmyre 1997), among them:

·        SDOs are too slow with respect to market timeframes

·        redundancy, and parallel structures, especially within the country representatives to international SDOs are inefficient

·        SDOs are too focused on consensus and hence are often reduced to choosing the least common denominator, often not an ideal solution to many users

·        voting structures out of sync with the economic investment of participating members

·        participation of non-stakeholder members drags out the process 

·        SDOs cost too much

·        SDOs processes are out of date

·        technical committee members, while technically apt, lack experience and writing skills to produce draft standards quickly

·        SDOs don't effectively prioritize which drafts to consider first

As we shall see, some of these claims are valid problems that SDOs must address, while other problems are more a result of public/industry perception.  In the final analysis we will see that some think that the question of SDO viability is already for the most part moot.

            It is difficult to discuss the problems with SDOs without first discussing their main competitors: standards-setting consortia.  Therefore we will postpone the fuller discussion of SDO problems until the end of the section on consortia.

 

5.2  Standards-Setting Consortia 

            The main rivals to SDOs are standards setting consortia.  Consortia are organizations, usually made up of representatives from two or more companies within the same industry.  Usually for strategic reasons these organizations work together to build standards that they hope will dominate the market, in turn helping the sales of the products built by the member companies.  In antithesis to SDOs, consortia do not have representative membership, do not always enforce rigid democratic processes, do not have due process, and do not always require consensus among members.  Consortia are not always successful and it is important to understand some of the factors that impact consortium success.

            As background, Oksala (1999) attributes the rise of consortia to three governmental actions.  First was the passing of the US National Cooperative Research Act of 1984 (NCRA).  This act eased some of the anti-trust restrictions which up until that point prevented groups of companies from collusion.  The new organizations that emerged had new membership and new focus; whereas previously composed almost completely of engineers, marketing and other business types began to participate, and the new groups shifted the focus from process to the results of the standards development process.  Despite other differences, three common facets of the new consortia were: shift from broad inclusive consensus to general consensus among present participants, lack of a need for balanced participation among members, and lack of dependence upon the sale of standards documents for revenue.  Second, in Europe, the European Union began adopting as official standards the technical specifications of organizations such as CEN, CENELEC and ETSI in their effort to harmonize the varying standards in all the EU member nations.  This meant that most standards were put together by not-necessarily-representative groups of industry representatives.  The third governmental action was the adoption by the World Trade Organization of the Technical Barriers to Trade Agreement (TBT).  In the wake of disappearing tariffs as a result of the GATT (General Agreement on Tariffs and Trade) focus shifted to non-tariff barriers to trade, chief among which were local standards requirements that gave unfair advantage to local businesses.  The TBT asserted that existing international standards should have priority over local standards, thereby removing standards-based barriers.  However TBT failed to explicitly define an "international standard" which has resulted in a rush by many industries to create favorable standards that can be seen as international.  Together the above three events encouraged the creation of non-SDO consortia.

            Both Lowell (1999) and Cargill (1999) recognize that while the number of standards-creation organizations has risen dramatically the amount of funding has stayed relatively stable.  Consequently we see the weakening of SDOs as described above.  It's also important to restate here what was said earlier, that since to be successful standards must exhibit high technical quality, they require participation from the best minds in a given industry.  In the case of either SDO standards or consortium standards what this means is the same people are writing the standards.  The major difference is the process by which the standards get written.

            From an industry perspective the benefits of consortium standards are:

·        stronger control over the resulting specifications, meaning that possibly more favorable implementations result

·        non-stakeholders are not allowed to vote or participate

·        focus is on the results--i.e. producing a standard within a timeframe reasonable by market standards--rather than on process

·        possible ownership of part or all of the intellectual property rights (IPR) of a given standard

·        strategic advantage over competitors who are not members of the consortium or who are members of a rival consortium

·        the chance to be first to market with products based on the new standard

In practice we see that consortium members in fact do receive some or all of these benefits.

            Consortia take many forms.  Some are made up of representatives from dozens of interested companies and have complex and explicit structures for arriving at standards.  Others are made up of only a couple of companies, usually big players, who are joining forces to oppose a common rival.  Updegrove (1995) identifies at least two types of consortium.  The first, which he refers to as a "strategic consortium" is made up of a limited number of players trying to advance a proprietary solution to a problem.  The second, the "standards setting consortium," enjoys much wider industry participation and represents a genuine interest in finding a common solution.  The odds of success, he says, are highly negatively correlated with the degree to which member participants have already invested in mutually incompatible proprietary solutions.  Success is most common in the case of an "anticipatory consortium" which in anticipation of a technology trend gets together to come up with a common solution before any single group has made a significant investment in a proprietary solution.  Interestingly, in order to ward off the ill effects of "proprietary forces" Updegrove recommends that all the major stakeholders in the process need to be given sufficient input and output--pretty much exactly what the SDO process provides, and what business strategists chafe against.

            A couple of the more notable consortia bear description.  First of all would be the Internet Engineering Task Force (IETF) which is responsible for TCP/IP, HTTP, and other protocols which form the foundation of the internet as we know it today.  The IETF is not actually a consortium per se.  It started out in 1986 as fifteen U.S. governmental workers related to ARPANET getting together to discuss solutions to internet infrastructure problems.  From there it rapidly expanded.  IETF has no members, no dues.  Literally anyone can participate by joining their e-mail mailing lists and attending their meetings which happen three times a year.  An informal hierarchical structure has evolved to describe eight areas of interest, but under these areas working groups form spontaneously and disband as soon as the problem of interest has been solved.  The backbone of this organization seems to be a steadfast dedication by members to a culture of voluntary cooperation, and a ready willingness to teach their "rules" to newcomers and to censure members who violate them.  They have a saying, "no kings, no votes, rough consensus, running code, and dual competing implementations" (Cargill 1997, pt1).  Everything performed by the IETF is on a voluntary basis.  No one is employed, and no one profits from the sale of standards or any other direct actions of IETF.  Even their meetings are run by the volunteer secretariat, and often they receive major donations of space and equipment from the meeting hosts.  Even the standards they produce weren't called so at first.  Referred to as RFC's (Request For Comments) these are just specifications, sent via e-mail or other electronic medium.  Once the RFC's reach a level where there is rough consensus and running code they are finalized and the working groups that created them disband.  Recently they have added the prefix STD to RFCs that are "standard."  This is a truly fascinating organization, which is a natural offspring of the internet (Malkin RFC1718).

            Second is the World Wide Web Consortium (W3C) which has taken responsibility for developing the standards for HTML, XML, and overseeing the implementation of other standards which are built upon these foundations.  The W3C is made up of over 500 member organizations from industry, standards setting organizations, governments, universities and other organizations.  Interestingly the W3C only refers to its technical specifications as "recommendations."  There is an explicit avoidance of the term "standard" in reference to the documents, which they produce for free online.  For all practical purposes W3C Recommendations are standards, but without formal SDO status they don't bear that name.  Actually an examination of the W3C's structure and process guidelines indicates that they place a high degree of emphasis on consensus as the magnitude of the decisions they make is quite large.  One might go so far as to say that the W3C is the sheep in wolf's clothing--they are a consortium that acts at heart like an SDO.  Yet the W3C continues to turn out very high quality recommendations that meet all the requirements of a "good" standard, including timeliness, openness, consensus, high technical quality, and wide acceptance(Jacobs 2000).

 

5.3  SDOs vs. Consortia 

            As mentioned before, a great deal, if not a majority of the academic discussion surrounding standards for the last five years has dealt with questions of SDOs versus consortia.  We will try to hit all of the main themes and get at the core issues involved.  We will point out which arguments are substantive, which are matters of public perception, and finally what we think is a reasonable stance for IT managers to take on the issue.

 

5.3.1        Cost-related Issues 

            As stated earlier, standards are expensive with respect both to financial and human capital.  The leading experts in a field must be donated by their employers to the process, and in addition, those employers must put up the cash to transport those people to meetings, organize conferences, etc.  As standards in general have become more important the costs, and more importantly the return on investment, of the standards process has come under more intense scrutiny.  Issues related to cost are: who pays for the standards development process, how much, what those payments buy them, and what is the cost to users for the resulting standards.

            SDOs receive funding from two main sources: their member organizations, and the sale of standards documents.  In one report, in 1997 ANSI received on the order of about 65% of its operating budget from the sale of standards, while 20% came from membership dues (Bank 1998).  These sources pose a significant problem for a couple of reasons.  The first is that many consortia such as the IETF and W3C publish their standards online for free to any who would use them.  A significant number of people think that in order for standards to do the most good, that they should be free and that there should be no costs imposed by the holders of the intellectual property rights (IPR) to either obtain or use such standards documents.  Clearly SDOs like ANSI cannot afford to do away with 65% of their revenue and still remain viable sources of standards.  Consequently, SDOs suffer criticism for not providing their standards online in convenient digital formats (Lynch 1998).  Buyers of ISO standards may now order them online, but they still have to wait for the printed and bound copy to arrive via conventional mail.  The second problem is of course that the membership of SDOs has been dropping steadily over the last decade or so, particularly as corporate members are finding consortia to provide better returns on investment (Cargill, 1999).  In short, SDOs face the loss of their two main sources of funding which seriously affects their ability to live up to their charters.

            Consortia are significantly different.  One of the main differences between SDOs and consortia is that consortia are not dependent upon the sale of standards documents for funding (Oksala, 2000).  Rather consortia depend entirely on their members for funding.  Another crucial difference between consortia and SDOs is what member companies get in return for their membership dues.  Since SDOs are controlled by very rigid constitutions, member companies cannot hope to buy influence through increased contributions.  The best they can hope for is that a representative from their company will sit as the head of a technical committee and perhaps wield some parliamentary power.  However, anticipating such, SDOs are structured to share this influence as well.  On the other hand consortia sell power and influence to the companies willing to make the largest contributions.  Updegrove (1995) emphasizes that carefully crafted structures for membership dues and rights are essential to hold back the "proprietary forces" that would undermine the work of consortia.  Arguably one of the greatest strengths of consortia in terms of their competitive power against SDOs is their freedom to offer different levels of membership to different stakeholders in the process that carry different levels of member rights, responsibilities and contributions.

            What costs should IT managers expect to face?  In the case where it is only necessary to obtain the standards documentation of a previously completed standard, the costs can range from free--for standards such as the XML 1.0 recommendation from W3C--to several hundred dollars per copy of the standard--for standards obtained from SDOs such as the ISO.  If the standards are not free, it is important to understand that intellectual property laws prohibit photocopying extra copies of a document on the company copier.  One author points out that sometimes several standards exist covering the same or related areas.  It is important that one doesn't purchase the wrong standard as this can be a waste of money (Lynch 1998).  He also points out that since standards are no longer taught in engineering schools, that if it costs several hundred dollars to obtain a standard, it is less likely that anyone will be familiar with it.  On the other hand it is not uncommon for recent graduates to be familiar with free specifications like for XML.  Managers need to consider the cost of supplementary educational materials and training for staff members who will use the acquired standards.

            If managers intend to participate in standards creation by joining SDOs or consortia then the cost of membership needs to be considered.  Lacking other sources of funding besides membership dues, consortia tend to be more expensive and usually range on the order of $25,000 to $50,000 per year or more depending on the scope and importance of the standard being developed and the number of participants.  Consortia offer different levels of membership to different types of organizations at different prices; naturally paying more money gets one more power and influence in the consortium.  Joining such organizations also generally requires a commitment in terms of personnel and the resources for those personnel to travel to meetings, conferences, etc.  Participation offers many benefits including an inside track on the latest technological trends, the chance to influence the technology to the benefit of one's company (for example, by using a platform with which one's company has a great deal of experience), the chance to network with other professionals in the field, and the right to use one's participation in the standards-making process for marketing purposes. 

It should be plain that the cost of participation in standards development is quite high, especially compared to buying a completed standard or downloading it for free, but it is important also to realize that all of the major players in an industry are involved and realize significant market advantages for their involvement.  Even if a standards document is not free, it is important to think of it and the training of one's staff as an investment that will pay great dividends if the resulting products are successful.

 

5.3.2        Timeliness 

            A second major issue that is frequently discussed is the timeliness, with respect to market cycles, with which standards are developed.  Again the dominant perception here is that SDOs are slow and that consortia are fast.  In reality this may not be true, but in the end the perception may end up being more important than the truth anyway.

            When the need exists SDOs can produce standards in short timeframes which meet market demands.  Batik (1999) raises the example of when in 87 days octane testing standards were revised to avert the ills of the 1970s Arab oil embargo, and he adds that many more examples exist to support the responsiveness of SDOs.  Unfortunately, Batik's argument rests on what is possible, given today's technology, rather than what actually goes on.  He argues that by using groupware today's more than 572 SDOs should be able to meet the need for standards.  While some of the SDOs certainly are up to date technologically, the majority it appears are not.

            Cargill (1999) gives a somewhat more realistic picture, and to a certain extent sidesteps the question of timeliness with his comment that:

The point is not that the consortia, as individual entities survive, but that the sponsors of these groups consider them a more viable investment for standardization than the formal standardization entities and continue to pour money and people into them. (Cargill 1999, p2)

 

Cargill refers to the dramatic drop in participation and resources among national and international SDOs.  In an earlier article (1997) he compares the standardization of C++, which took the ISO eight years, to JavaScript (ECMAScript) which was completed by ECMA in six months and HTML which was completed by the W3C in just a year.  Despite the fact that C++ is a much larger and complex language than either ECMAScript or HTML, it is easy to see how these finer details could be brushed aside by the marketing types who wish to promote their consortia at the expense of SDOs.

            It is important for IT managers to understand that this argument has little importance after the standards have been developed.  IT managers needing a standard will not need to consider the time to development if it is already done.  Timeliness only becomes an issue when one is considering the creation of a new standard.  In that case, managers need to make the decision about whether speed is more important than quality.  As discussed before in high risk projects it is crucial to build upon standards of the highest quality since in the event of failure this helps to reduce liability damages.

 

5.3.3        Legitimacy 

            Staunch supporters of the SDO process frequently claim that the lack of control over non-SDO standards creation will damage the credibility and legitimacy of the standard to the point where it will not be viable in the market.  Unfortunately this does not seem to be the case.  There are several reasons for this.

            The first reason is that apparently education about standards was dropped from engineering curricula some time in the 1960s, hence today's product developers don't have the background from which to evaluate prospective standards (Batik 1999).  Today's developers and managers don't know the difference between standards development processes, what organizations are responsible for what standards, where to go to find standards, or how to incorporate them or develop them effectively.  Lynch (1998) comments that the high price of SDO standards is a barrier to their being learned by today's college students and recommends a way to restructure the pricing system so that they are accessible.

            The second reason is that rules for governmental procurement have eased .  In the past it was necessary for a standard or a product to have the stamp of approval of a nationally or internationally recognized SDO in order to be acceptable for governmental use.  Gradually this has changed as the SDOs haven't been able to keep up with the need.  In order for governments to keep up with the rapidly changing pace of technology they have had to lower their standards.  This in effect has raised the level of legitimacy for consortium standards.

            The third reason is pure and simple market economics.  As standards become successful, regardless of their source, they tend to have a legitimizing effect on those sources.  As the W3C and IETF continue to turn out high quality standards it becomes more and more recognized that perhaps the rigid SDO process is not always a requirement.  Also as consortia are increasingly the venue of choice for standards supporters--i.e. corporations--their value in the eyes of the world tends to improve.

            For all practical purposes IT managers nowadays are free to adopt standards regardless of their origin.  The legitimacy of standards is first tested in the market and frequently later in the courts.  At the same time it is very important to understand that all standards are not created equally and now more than ever managers must be careful to research the origins of any given standard, and evaluate the likelihood of market success before deciding to adopt.  Just because a few people claim that Esperanto will become the global language doesn't mean that a smart manager will choose to make it the official company language.

 

5.3.4        Structure, Process, and Participation 

            While structure, process and participation actually represent three different issues, it is difficult to address them separately.  Herein lie the most significant differences between SDOs and consortia and it is here that the fundamental philosophical questions lie.  Perhaps the problem is that the market seldom has time for philosophy.  This is an area where it will be interesting to watch the evolution of the field.

            Open structures, open processes, and open participation are at the heart of the SDO process.  Krechmer (1999) identifies ten principles of open standards that are worth reproducing here:

1.      Openness of participation to all stakeholders

2.      Consensus

3.      Due process

4.      Open Intellectual Property Rights (IPR)

5.      Open World--same standard for the same function world-wide

6.      Open Access to the standards produced

7.      Open Meetings

8.      On-going support

9.      Open Interfaces--allow extensions public or proprietary to the standard

10.  Open Use--low or no charges for use of the resulting standard

Applying these principles to ANSI he found that the first four and possibly the fifth are already explicitly a part of the ANSI development process.  Principles six through nine are currently under development.  Krechmer was critical of many consortia which market their standards as "open" when they don't really conform to these principles.

            Naturally such open processes carry with them some undesirable consequences.  Particularly at the international level it takes quite a deal of effort to coordinate communication.  Not all member groups have access to the technology or equipment to participate in a fully electronic fashion.  Sometimes non-stakeholder members will have a voice that will drag the process out.  It is at these inefficiencies of open processes that consortia have aimed their criticism.

            Consortia have the strength of being able to tailor their participation structures and processes to the specific requirements of the task at hand.  There are times when the scope of the standard being developed is such that it really isn't necessary to include representatives from the whole world.  SDOs don't have the luxury of excluding some of their membership from the process and hence can't keep up with these tailored structures.  Willingmyre (1997) examines what makes consortia structures successful.  Interestingly he found that strong leaders who are adept at following the principles of fair constitutions produce the most successful consortia.  Ironically these principles of fairness are what SDO structures are designed to protect.  These observations support the conclusions that Cargill (1999) has made about the source of standards being more a question of perception than substance.

            However, for the most part consortia do not conform to the principles of open standards.  Shapiro and Varian (1999) instruct managers in the use of the standardization process to wage standards wars against their competitors.  Beginning with their metaphor, the entire tone of their article downplays openness and even cites it as a sign of weakness.  Particularly revealing is their advice to winners of a standards war:

Probably you made some concessions to achieve victory, such as promises of openness or deals with various allies.  Of course, you have to live with those, but still there is a great deal of room for strategy.  (Shapiro 1999, p21)

 

Such is the reality of business, and it is important to remember that despite claims of openness many or most members of consortia are only there because it is in the best interests of their businesses to be there.  In a purely rational world, Keen (1981) reminds us, compromise is pathological.  Hence it is very important to examine the motives, the processes, the participation structures that produce consortium standards.

            IT managers need to understand the participation structures and processes of SDOs and consortia when considering their standards for adoption.  Also if a company is planning on participating in the standards process they need to go into it with their eyes open.  Updegrove  makes an interesting comment:

Most successful consortia are, in fact, the creation of individuals, not companies. Typically, a single individual or group of individuals have a vision that they persuade their employers or vendors to endorse, and then that individual(s) works to propose a structure, charter, and by-laws for adoption by founding members. (Updegrove 1995, p146)

 

The individual IT manager can make a big difference and can have a significant impact on the way that standards come into being and are consequently adopted by the IT community.

 

5.3.5  Consortia or SDOs? The Final Word 

            In terms of costs and financial status, consortia appear to be in much better shape than SDOs these days.  Consortia have more flexibility in terms of modes of revenue generation and enjoy the reputation of giving a higher return of investment.  However, these cost issues largely fall away if an organization is not involved in the standard's development; in that case, only the cost of the standard document is a factor, and with respect to the eventual return, even this is not terribly significant.  In terms of timeliness as well, consortia seem to have an edge, but again this is not a factor if the standard has already been completed.  In terms of legitimacy, SDOs should be the unquestionable favorites; however, a combination of ignorance, relaxing governmental rules, and economics have brought consortia standards to almost equal footing.  In terms of participation structure and development process, SDOs are still superior when it comes to issues of liability, and genuine global interest.  Here again, however, we see that for many standards the freedom from the rigid rules of participation allow consortia to produce good standards efficiently.  The final analysis is that if standards are already completed whether developed by consortium or SDO is of relatively little importance.  For standards under development, however, various issues of cost, timeliness, and participation must be considered with the likely advantage going to consortia.

 

5.4  De Facto Standards 

            Finally we will briefly discuss the third source for standards, de facto standards.  Moving as far away from SDO standards as is possible, de facto standards are not the product of any sort of negotiation, joint effort, or agreement whatsoever.  De facto standards get their name from the fact that market dominance has made the technology or process so common, so widely used, understood, and accepted, that really there is no rival or substitute that can replace it.  The prime example would be Microsoft Windows operating system, which by some accounts is installed on around 80% of all personal computers worldwide.  This dominance in effect gives Microsoft huge influence in most every aspect of computing since most all software developed these days must in some way be adapted to the operating system in which it lives.

            Of course, achieving market dominance with one's products on the scale that Microsoft has would be a dream come true for many businesses, but realistically there is no way to reliably predict and plan for such a success.  IT managers should know that if they choose to go it alone and develop a proprietary standard that there are overwhelming odds against it succeeding.  Not that it is not possible--RealNetworks and Adobe both have been very successful respectively with their media player and portable document format systems.  It takes a special kind of luck, technical excellence, and business savvy to pull this off.  Indeed there are descriptions of the sorts of business strategy one must employ.  Shapiro and Varian (1999) describe seven key assets that can be wielded in standards war:

1.      Control over an installed base of users

2.      Intellectual Property Rights (IPR)

3.      Ability to innovate

4.      First-mover advantage

5.      Manufacturing capabilities

6.      Strength in complementary technologies

7.      Brand name and reputation

While a company may not be strong in all of these areas, it is best to use one's strengths to advantage and to attack one's competitor in the weak spots.  Of course, absent from this discussion is any serious consideration of cooperation or consensus except as a last resort.  Success in achieving a dominant position for one's technology brings with it ruthless attacks from one's competitors.  Unless an organization has tremendous legal, financial or other resources with which to fend off these competitors, one is best advised to stick to one of the less heroic methods for standards establishment.

 

6.  Making the Decision 

            Now that we have a background in the standards process, the following section will provide some realistic guidelines for deciding whether or not to include standards into one's development projects.  First we will discuss why this decision even falls to the IT manager in the first place.  In their textbook on IT management Applegate et al. (1999) discuss all the major facets of running the IT operation in many different kinds of company, including an in depth section on the question of outsourcing.  Throughout this discussion, and even in the case where a company outsources 100% of its IT function, the authors stress that control over the overall architecture of one's systems should never be delegated.  Outsourcers change, or multiple systems must be integrated including internal, and external systems.  The only person with the vested interests of the company at heart, and the vantage point and clout to integrate such systems is the IT manager.  System architecture always involves the incorporation of many standards, some new and untested, and for that reason IT managers must be ready to do the research and make the decision.

            What are the elements of that decision?  There are a number of classes of considerations to be made.  The importance of each will vary greatly depending on the particular development project in the particular organization.  Those considerations are:

·        The quality of the proposed standard (technical quality, timeliness, effectiveness, widespread adoption)

·        The type/usage of the standard

·        Compatibility/Interoperability issues relating to one's current and future IT architecture

·        Strategic importance

·        Personnel/Expertise issues

·        Stability of the standard

·        Consequences of non-adoption

·        Capacity to participate in standards development, or to wage a standards war

We will briefly describe each of these considerations and leave it up to managers to apply them as appropriate to their own organizations.

            Willingmyre (1997) proposes four qualities that describe "good" standards.  High technical quality of the standard is the first element to be examined.  Hidden in this requirement is that the IT manager, or someone on the staff, must be competent to evaluate whether or not the specification is of high technical quality or not.  Naturally a standard which is not of high technical quality will result in end products which have flaws or other undesirable qualities.  Timeliness is the second quality of a "good" standard.  Earlier we spent a good deal of discussion on this issue.  Generally the strength of the need for a standard dictates the speed with which it will be developed.  Recently consortia such as W3C are spending considerable energy on predicting and even directing the future need for standards and planning to develop them in time to meet the demand.  The hidden trap here is not to go with standards that exist before their time.  Companies may build products to fit a standard whose need is never realized and be left with a warehouse full of gadgets no one wants to use.  Effectiveness is the third quality of a good standard.  Effectiveness is different from technical quality in that a specification may be of high technical quality and still not effectively address the core problem--i.e. it is not an effective solution.  Many standards exist which address similar issues or problems.  IT managers must carefully choose the standard that is most appropriate to the given design problem.  Lastly, widespread adoption is perhaps the most crucial success factor for a standard.  Certainly this is easy to evaluate for established standards, but IT managers must beware of emerging standards that have not yet reached maturity.  Using these four criteria IT managers can make a good preliminary evaluation of a potential standard.  Provided the standard meets these criteria, the next question is its appropriateness to the development project at hand.

            How the standard will be used is very important.  If the standard will be used to build a product that will put user safety at risk, it is crucial that it meet impartial, rigorously developed standards--i.e. those created by SDOs.  For example, it would be unacceptable to base the design of a child car seat on a standard set by an industry consortium of car manufacturers.  The reason is that if the child seat manufacturer ever gets sued for negligence, citing compliance with the consortium standard won't hold much weight since car manufacturers can be shown to have more interest in selling cars than protecting the safety of the children that ride in them.  On the other hand, if the child seat safety standard was approved by ANSI, which has rigorous checks and balances in place, compliance will likely be a successful defense (Lowell 1998).  It is perhaps ironic that in either the consortium case or the ANSI case, the standard will most likely be developed by the exact same group of experts, but we see that here is where the differences between SDOs and consortia come to be important.  For the majority of cases such considerations probably won't be a factor, in which case the source of the standard is probably not too important (Cargill 1999).  In terms of managing the risk involved in product development it is necessary for the manager to try to anticipate all the uses to which the product, and hence the standard, will be put and to manage the risks involved with such uses.  Not to do so can be seen as negligence and may bring serious consequences upon the producer.

            The third set of considerations deals with interoperability and compatibility.  There are numerous areas which need to be considered such as backward compatibility with legacy systems, compatibility with the products the user currently owns, and forward compatibility with products this company and others will produce.  Especially in the area of information systems interoperability with very different systems is increasingly an issue.  Primarily the issue of compatibility can be seen in terms of switching costs: how much will it cost the company to switch to a new standard, will users of the product also be willing to switch, is there a general switching trend going on in the industry, and will the new standard lower switching costs in a way that can help or hurt the company?  The open source movement and standards such as languages built on XML are bringing increasing focus on universal compatibility between radically different devices.  The cost of adopting a standard might be prohibitively high for one compatibility reason or another, but in these times the costs need to be weighed carefully against the cost of not adopting the standard.  There are more than compatibility issues at stake here so these costs will be discussed last.

            The fourth set of considerations are strategic and include issues previously discussed such as switching costs for users of the products.  Applegate et al. (1999) provide a useful set of considerations based on Michael Porter's ICA framework.  They advocate asking five questions:

1.      Can IT build barriers to entry into a given market?

2.      Can IT build (or reduce) switching costs from your product to a competitor's?

3.      Can IT change the basis of competition?

4.      Can IT change the balance of power in supplier/consumer relations?

5.      Can IT generate new products?

By their very nature and purpose standards reduce barriers to entry into a given market, reduce the switching costs between competing products, change the balance of power, and generate new product ideas.  For example standards in the frequencies at which remote control devices operate allow competing vendors to provide remote controls that will work with their competitor's products (e.g. TVs/VCRs), reducing the cost of switching to the consumer.  Perhaps question three is the most crucial of all.  Standards change the basis of competition.  No longer is the base technology in question, the real challenge now becomes to focus on what features differentiate the product from its competitors.  The existence of a standard reduces design and production time, but that in turn should free the design team to work on improvements, that also in turn may become standard some day.  The real business profit lies in this marginal period lasting from when new and distinguishing features appear until they become standards themselves.  Of course such strategic considerations will apply more or less to different products, but they are important all the same.

            Do you have the people with the experience and expertise necessary to utilize the standard?  If not, do you have the resources to develop them?  This is a basic question that applies to all the skills necessary to develop a product.  In the case of standards it is important to realize that the costs for developing the skills vary greatly depending on the standard.  Free, widely understood standards like HTML are easier to acquire and develop than more esoteric standards which must be purchased from an SDO.

            Standards documents generally give some indication as to the degree of stability of the standard.  Sometimes a standard will carry a qualifier like "proposal" or "under consideration" which indicates that it is a work in progress and may not be reliable for product development.  Managers must ask the question of how likely a given standard is to change, and how difficult it will be to incorporate those changes into the final product.  Most international standards are ideally required to be reviewed every five years and a proposal to change, retire, or modify the standard made.  Facing a lack of resources some SDOs have not been able to keep up with this requirement, but in general it is safe to say that standards are evolving and changing documents and that the manager needs to have a grasp of when this is likely to happen and how it will effect development.

            The next to last question to consider is extremely important and is the question of what will be the consequences of not adopting a given standard.  In some fields standards are evolving so rapidly that a company can safely skip a generation of change.  Of course this is best done deliberately and the company should be able to stockpile some resources to make the change when it eventually becomes necessary.  Some standards are not very consequential and can safely be ignored.  For example, the three major car manufacturers in the U.S. got together and formed a consortium to set standards for products and features that are not the basis of competition for their industry, such as gas caps, light bulbs, jacks, etc. (Lowell 1999).  This form of standardization streamlines the industry without really changing the playing field.  On the other hand, failure to adopt some standards can be disastrous, as non-compliance can be the cause for lawsuits or failure to receive regulatory approval.  Therefore IT managers need to work to make sure they are cognizant of the applicable standards in all cases, and to understand what will be the consequences of not adopting those standards.

            The last issue we will discuss covers situations where either no standard exists, or current standards are out of date or unsatisfactory for one reason or another.  In these situations the IT manager has several options: develop a proprietary solution to the problem without regard for how others are approaching the problem, join/create an industry consortium to tackle the problem, submit a request to an SDO to handle the problem.  All of the ideas discussed up to this point should give the IT manager the background necessary to make the most appropriate decision.  Each of these choices has its own set of costs, risks, rewards, and benefits.  The manager needs to consider the resources available to the company, weigh them against the costs involved with each process.  The manager needs to gauge the likelihood that developing a standard will lead to the need for waging a costly standards war with a competitor or group of competitors.  Following these guidelines should allow the IT manager to make the most appropriate choice when it comes to evaluating standards for adoption in development projects.

 

 7.  Conclusion

            A growing number of scholars and practitioners are focusing their attention explicitly on standards, their development, and their consequences for our society.  Some authors are working on general theories for standards development (Schoechle 1999) while others are working on mathematical models to describe standards development (Krechmer 2001).  The growing interest by scholars in a field such as this generally marks an increase in the importance of the phenomenon to the rest of society.  It is not true to say that the field wasn't important up until now, but there certainly exists an opportunity now to develop the field while industry support and interest are relatively high.  After surveying the literature several issues strike me as particularly important.

            A major issue that needs to be examined carefully is the importance of the process by which standards are developed.  Some degree of bias and unfairness will perhaps always accompany standards development, but with the demotion of SDOs from the position of sole standards distributors we have opened ourselves up to the dangers of standards developed by industry that were created with less than the users' best interests in mind.  We need to decide if market and legal forces are strong enough to keep consortia working for the public good.  Some staunchly believe that standards should be the sole domain of SDOs, but more and more revolutionary organizations, such as the IETF are challenging that notion by producing what appear to be extremely beneficial standards.

            The second issue that needs examination is who should bear the costs of standards development.  Defendants of the SDO process are relatively speechless when it comes to coming up with new and creative way to fund SDOs.  Companies justifiably spend their standards development dollars where they perceive they can receive the greatest returns.  On the other hand there is an explicit recognition that standards fuel and are fueled by the evolution of society.  In this light, since everyone in the world has a stake in the development process, somehow everyone's interests need to be protected by the process.  Consequently there is some justification for some means of publicly funding the standards development process.  This adds whole new layers of complexity to the issue.  Among others one of the main issues is who owns the standards.

            Intellectual Property Rights (IPR), or who "owns" a standard represents a significant problem for the field.  SDOs depend on the sale of standards documents for revenue, while consortia like IETF and W3C give away their standards for free.  It is difficult to conceive that someone could "own" the metric system or the English language, both of which are standards for measurement and communication respectively.  Some hold that information is a commodity and therefore standards should somehow obey laws of supply and demand (Bank 1998), but this is a difficult position to defend when electronics allow a virtually limitless supply of digital copies to be distributed at little or no cost.  This issue is not limited to standards, but applies generally to all forms of information.  Perhaps the ownership of standards will prove a workable subset of this larger issue.

            Despite how these issues play out in the long run, IT managers should be able to use the ideas developed in this paper to make critical decisions now about the infrastructure on which their businesses will be built.

 

References

Applegate, Lynda M., F. Warren McFarlan, and James L. McKenney.  Corporate Information Systems Management: Text and Cases, 5th ed., Irwin/McGraw-Hill 1999.

 Bank, Andrew.  The Myth of Free Standards: Giving Away the Farm.  Standards Engineering Society World Standards Day Paper Competition 1998, first place.  (http://www.ses-standards.org/library/bank.pdf)

 Batik, Albert L.  What Price Speed?  Standards Engineering Society World Standards Day Paper Competition 1999, second place.  (http://www.ses-standards.org/library/batik.pdf)

 Bird, Graham B.  The Business Benefit of Standards.  ACM StandardView 6(2), June 1998, p76-80. (http://www.acm.org/pubs/articles/journals/standardview/1998-6-2/p76-bird/p76-bird.pdf) 

Cargill, Carl.  ACM StandardView 5(4), December 1997.  Series of articles documenting Sun Microsystems Inc.'s application for ISO/IEC JTC1 PAS (Publicly Available Specifications) provider status.  Rather than cite each of the 13 articles, which have names like "Section 1," separately, readers are referred to the entire issue.

Cargill, Carl.  Consortia and the Evolution of Information Technology Standardization.  Proceedings of 1st IEEE Conference on Standardisation and Innovation in Information Technology 1999.  (http://www-i4.informatik.rwth-aachen.de/~jakobs/siit99/proceedings/Cargill_consortia.doc)

 Jacobs, Ian.  About the World Wide Web Consortium.  March 2000 http://www.w3.org/Consortium/

 Keen, Peter G. W.  Information Systems and Organizational Change.  CACM 24(1), January 1981, p24-33 (http://www.acm.org/pubs/articles/journals/cacm/1981-24-1/p24-keen/p24-keen.pdf)

 Krechmer, Ken.  Technical Standards: Foundations of the Future.  ACM StandardView 4(1), March 1996, p4-8. (http://www.acm.org/pubs/articles/journals/standardview/1996-4-1/p4-krechmer/p4-krechmer.pdf)

 Krechmer, Ken.  The Principles of Open Standards. Standards Engineering Society World Standards Day Paper Competition 1998, second place. (http://www.ses-standards.org/library/krechmer.pdf)

 aKrechmer, Ken.  The Fundamental Nature of Standards: Technical Perspective.  IEEE Communications Magazine 38(6), June 2000, p70.  (http://www.csrstds.com/fundtec.html)

 bKrechmer, Ken, and Elaine Baskin.  The Fundamental Nature of Standards: Economic Perspective. International J. A. Schumpeter Society Economics Conference, June 28 - July 1, 2000, Manchester, England (http://www.csrstds.com/fundeco.html)

 Krechmer, Ken.  personal correspondence.  May 3, 2001.

Lowell, Stephen C.  The Yin and Yang of Standards Development. Standards Engineering Society World Standards Day Paper Competition 1999, first place. (http://www.ses-standards.org/library/confucius.pdf)

 Lynch, Clifford.  The Case for New Economic Models to Support Standardization Efforts. Standards Engineering Society World Standards Day Paper Competition 1998, third place. (http://www.ses-standards.org/library/lynch.pdf)

 Malkin, Gary.  The Tao of IETF.  RFC1718 http://www.ietf.org/tao.html

 Oksala, Stephen.  The Changing Standards World: Government Did It, Even Though They Didn't Mean To. Standards Engineering Society World Standards Day Paper Competition 2000, second place. (http://www.ses-standards.org/library/oksala.pdf)

 Parker, Dana J.  In a Rut or In the Groove.  EMedia 13(11), November 2000, p88. (http://wilsontxt.hwwilson.com/pdffull/06693/3Z9RB/0F8.pdf)

 Schoechle, Timothy.  Toward a Theory of Standards.  IEEE SIIT99.  (http://www-i4.informatik.rwth-aachen.de/~jakobs/siit99/proceedings/Schoechle.doc)

 Shapiro, Carl, and Hal. R. Varian.  The Art of Standards Wars.  California Management Review 41(2), Winter 1999, p8-32.  (available online from Proquest)

 Updegrove, Andrew.  Standard Setting and Consortium Structures.  ACM StandardView 3(4), December 1995, p143-147 (http://www.acm.org/pubs/articles/journals/standardview/1995-3-4/p143-updegrove/p143-updegrove.pdf)

 Willingmyre, George T.  International Standards at the Crossroads.  ACM StandardView 5(4), December 1997, p190-194 (http://www.acm.org/pubs/articles/journals/standardview/1997-5-4/p190-willingmyre/p190-willingmyre.pdf)