|
Français | Contact Us | Help | Search | Canada Site | ||||
| What's New | About Us | Policies | Documents | TBS Site |
| Calendar | Links | FAQs | Presentations | Home | ||||||
|
|
|
 |
24 April 1995 Publicly Available Specifications and the Public Sector. M. Harrop Foreword This paper has been developed for the International Public Sector Group on Information Technology (IPSIT). IPSIT members face many common challenges applying Information Technology (IT) to public administration. All IPSIT members have adopted standards-based IT procurement policies and, to a greater or lesser degree, all have encountered similar problems with respect to the application of those policies in the face of rapid technological change and unexpected market forces. Most public sector IT policies are permissive to some degree with respect to the procurement of products and services based on Publicly Available Specifications (PAS) but there are many questions and implications associated with PAS use. These questions and implications are not confined to public sector use of PASs. This paper attempts to document, from a public sector standpoint, the major issues associated with PAS use. In developing this paper I have drawn on several of the many excellent papers that were submitted to the ICT Standardization Policy Workshop held in Brussels on 28-30 November 1994, and on the collective experience of IPSIT members. Introduction The changing environment There is widespread general awareness of the rapid speed of technological change, particularly that resulting from the massive improvements in the price/performance ratios of microprocessors and the vast increase in available communications bandwidth. This is reflected in the marketplace in the proliferation of relatively low cost, highly functional chip-based devices - personal computers, VCRs, CD Rom players, cellular telephones, automobile control and monitoring units etc- devices which, as every consumer knows, rapidly become obsolete as the next generation of microprocessor is brought to market. Clearly, the rapidly changing technological environment has altered the way we use information technology but it has also resulted in other changes that are less obvious - changes in marketing strategies, market dominance, service provision and even the degree of collaboration between suppliers. In some cases, the rate of technological change has greatly exceeded the ability of organizations to make the necessary adjustments to fully benefit from the developing technology. One of the fundamental questions facing any IT user organization is whether its current policies are appropriate. As noted in ref 1, the environment of the early 1980's, when many of the OSI policies were conceived, was one of IBM market dominance and proprietary specifications. Data processing was, to a considerable extent, based on large, centralized mainframes with hierarchical networking structures. The dominant network protocols were the proprietary protocols that were normally supplied for the mainframe and that meant IBM protocols in most cases. Other manufacturers offered their own proprietary architectures but in each case the purchaser faced the risk of being locked in to a single vendor since the products and architectures of the major suppliers were, for the most part, incompatible. Consistent and broad interworking was impossible, in some cases even between products from a single supplier. By 1995, we had moved to a technology environment based on microprocessors, personal computers, parallel processing architectures and high bandwidth, digital communications, in an operating environment that is moving rapidly towards client-server architectures. IBM is no longer the dominant supplier and there is less concern now over hardware supplier domination than over software supplier domination. User needs have developed along with the technology and common user requirements now include the need to transmit large volumes of data over both local and wide area networks; wide connectivity, particularly for e-mail; portability of applications and data; and effective security for data in storage and during transmission. Above all, there is the need for wide and seamless interworking capability. Ref 2 notes that "there is a fundamental necessity for interworking if the information highway concept is to be realized through the use of existing technology, allowing not just textual transmission, but voice, image and video". Organizational change in the application of IT in both the public and private sectors has been the result of two factors. Firstly, the response to the changing technology itself. Secondly, and, for most organizations, more significantly, the reaction to the recession and the broad movement to reduce the costs of government while maintaining or even improving the level of service delivery. This has meant that, in many cases, functions that were previously handled by people, have been automated. Other trends have also followed largely from the cost reduction initiatives. Many organizations have consolidated their IT (or are in the process of doing so). Several governments are now working towards an "all of government approach" to IT or a "single window" approach. This implies a much greater degree of sharing of information between departments and much more commonality in data structures, formats and interfaces. In some cases cost reduction has meant contracting out an organization's entire IT function and, instead of buying equipment and software, simply contracting for a service. Note though that, as some IPSIT members have observed, there are often conflicts between some of the objectives associated with cost reduction and government renewal. Increased delegation of authority to individual departments and contracting out of, in some cases, the entire IT for a department, make objectives such as "single window", and central coordination of IT effort, much more difficult to attain. On the supply side we have seen a significantly increased degree of cooperation between vendors. Many vendors have made major contributions to the work of the formal standards committees and have cooperated closely in the efforts of the regional OSI/open systems workshops that specify how the formal standards should be implemented. In addition, various consortia, such as X/Open and the ATM forum, have effectively established an alternative mechanism for the development of some industry-specific standards. Within the formal standards process we have seen changes aimed at making standards more usable, speeding the production process and, more recently, establishing a fast track process for formalizing specifications developed by other groups such as the industry consortia and the Internet Society. Clearly, the developments of the past 10 to 15 years have brought about significant change in the way we approach IT. Further, there is every indication that the rapid pace of change will continue for the foreseeable future. It is appropriate, therefore, to periodically re-examine IT policies to determine what, if any, changes need to be made to reflect changes in the operating environment. For the past ten years there has been a widespread assumption that open systems standards were the only way to assure the required connectivity. That assumption is now being widely questioned. Public Sector IT policies and constraints Government IT policies broadly fall into two distinct categories: those that address the procurement and use of IT goods and services; and those that address the issues relating to the development of, and trade in, IT goods and services. While it is difficult to completely separate these two categories, a policy designed to meet the objectives of one of these categories will not necessarily meet the requirements of the other. This paper focuses only on issues concerned with the use of IT to meet specific business objectives, not with issues of trade or regional industrial development. Although in many cases, public sector IT standards policies and government IT standards programs pre-date OSI and Open Systems, it was with the OSI policies that the public sector adopted a more proactive role with respect to IT standardization. The development of OSI standards began in 1978 and OSI itself was originally viewed by many as a way of counterbalancing the dominance of IBM's proprietary Systems Network Architecture (SNA) by "levelling the playing field" and allowing other vendors to produce networking products to common standards. Unlike most private sector companies, public sector agencies have long had a requirement for open bidding. This greatly increases the risk of a mixed vendor environment. The evolving technology and changing demands of the 70's, particularly the growth in the demand for network-based activities, also resulted in an inevitable trend towards mixed vendor environments in both the public and private sectors. With the proprietary architectures of the early 1980's, agencies increasingly found that they were constrained in their procurement options, the choice often being to remain locked into a single vendor indefinitely or to spend excessive sums to transfer the existing production systems to another vendor's equipment. From the public sector IT user and procurer standpoint, it was the requirement for non-discriminatory procurement (with the concomitant risk of a mixed product environment) that was the strongest motivating factor leading to public sector endorsement of OSI and Open Systems as strategic directions, although in Europe at least, the idea that IT policies were "a weapon in an economic war" (i.e. a way of counterbalancing U.S. domination of the IT market) was also a significant factor. Most public sector IT policies endorse the OSI standards and encourage the procurement of products and services that adhere to those standards. In some cases the policies are mandatory, in other cases optional. Treaty obligations (such as those of GATT and its successor WTA, Maastrict and NAFTA) and supranational regulations (such as Decision 87/95/EEC) place additional compliance obligations on some public sector administrations. However, whatever the policy requirements, administrations have often been forced to take a pragmatic approach based on a product being widely available, reasonably priced, and well supported by competent vendor staff. If these requirements are met by products that comply with International standards, then that is the first choice. If not, a non-proprietary, de facto standard-based product is preferred to a proprietary solution. Standards, the user, and the market place When the OSI and IT standards policies were originally conceived little thought was given to the possibility that the standards could be outpaced by technology or the products by marketplace alternatives. It was assumed that standards would be developed and implemented quickly in products; that the products would be fully functional and cost-effective; and that people would buy the products. A retrospective assessment of these assumptions suggests that they were overly optimistic. Even those users who are most supportive of the policies and who want to buy standards- based products have found that, in many cases, cost-effective, functional products are not available when needed. There are several reasons for this situation: - The standards development process itself takes time, usually a minimum of two or three years to develop a standard from scratch. The International Organization for Standardization (ISO) and the International Telecommunications Union (ITU) have made significant changes to speed up the standards process and to "fast track" stable specifications. This means that the processing and balloting time for standards can be reduced and, if one starts with a stable specification or relatively mature and widely-agreed concepts, progress can be swift. On the other hand, if the concepts are not mature or are contentious, it will likely take some time to reach agreement. It is not in anyone's interest to rush to ratify an incomplete or defective specification. - The range of standards covered by the term "open systems" is considerable. Although OSI was initially focused on the standards for interworking (essentially communications standards), expansion to the concept of open systems brings in a much wider range of applications with a much greater number of potential standards, not all of which will develop with the same speed. In some cases the degree of democracy involved in the standards process slows it down to a great extent and results in such compromises that the resulting product is complex, mediocre, difficult to test and riddled with options. - Timely progression of any standard is dependent on an adequate level of expert participation. If the available resources are insufficient, the standard will not progress. - In spite of the increasing cooperation between vendors in the development of standards there is, unfortunately, still a tendency on the part of some vendors to send to standards meetings, experts who are not in tune with their own corporate directions. This results, in a serious disconnect between what is going on in the standards committees and what is happening back at the office. - In some cases vendors have developed standards-based products to meet policy requirements but have been less than enthusiastic in promoting the products, preferring instead to promote company-favoured alternatives. Another complication for the de jure standards is the requirement of some public sector procurement policies for products to be subjected to formal testing. As pointed out by Isabel Valet [6] this has had the effect of greatly complicating the implementation process and significantly increasing the cost of standards-based products. Sometimes the cost of a standards-based product is 3 or 4 times the cost of a proprietary or PAS alternative. This does not mean that either IT standards or IT policies as a whole have failed. Many standards have succeeded, particularly at the lower layers of the OSI model, though as Ray O'Connor points out [1], it is normal for some standards to succeed while others fail. The same must also be true of policies and products. However, given the shortage of available, functional, cost- effective products, the scenario described by Ruth Kerry [2] in which procurers follow trends and buy products and services (from whatever source) to meet their business needs is hardly surprising. To meet current user needs, products that offer large scale, seamless and open connectivity are required. Ten to fifteen years ago standards were seen as the only way to achieve those objectives and the policies reflect that assumption. Standards can still make a major contribution to achieving that goal and in some cases are essential, but as noted by Ray O'Connor [1]: "It no longer true that formal standards are essential for interworking between machines of different suppliers, and indeed it is true only to a limited extent for interworking between networks. Standards are only one of the possible solutions, each of which has characteristic advantages and disadvantages, both technically and economically" Products based on publicly available specifications, sometimes referred to as de facto standards are often considered by purchasers when no standards-based product exists, when standards- based products exist but are deemed unsuitable because of inappropriate functionality of high cost, or even simply because of market pressures. In many cases PASs are believed to provide an alternative to de jure standards while still maintaining the sought-after objectives of openness and pluralism in the marketplace. De facto Standards and PASs While there is a fairly clear definition of what constitutes a de jure standard (i.e. a specification developed by a recognized international or national standards organization or treaty organization), there is no clear definition of what a de facto standard or a PAS is. Two characteristics of de facto standards are that they are widely used and they are specifications that have not been adopted as formal standards. However, there is no implication that a de facto standard is uniquely specified or that the specification is publicly available or in the public domain. Thus we have proprietary products as well as fairly general specifications (such as those used to build clones of the IBM PC or the Microsoft DOS operating system) being referred to as de facto standards. Lack of a published specification results in differences between implementations which are sometimes significant. PASs tend to be defined in terms of general characteristics. A PAS is clearly publicly available, though the specification may not actually be in the public domain i.e. the specification may belong to an individual or organization and this gives rise to serious questions of intellectual property rights. By implication, a PAS is widely used, though this may not always be the case. There are instances of organizations making specifications publicly available but then finding little demand for them. As documented by the CEN/CENELEC/ETSI Joint Presidents Group [8], PASs may result from specifications drafted by an industry or professional group (such as ECMA, the IEEE, the Internet Society of the OSI/OSE implementors workshops); from consortia specifications (such as those developed by the ATM Forum, the Network Management Forum and X/Open); or from specifications that have gained broad market acceptance (e.g. Adobe's Postscript and Microsoft's Windows). Ray O'Connor [1] lists the following as examples of de facto standards:
In some cases, use of a de facto standard or PAS may involve restrictions due to ownership of the intellectual property rights or for other reasons. The security world provides some interesting examples of what can happen to PASs and the possible restrictions on their use. The Data Encryption Standard (DES) adopted by the US National Bureau of Standards (NBS) in 1977 as a Federal Information Processing Standard and in 1981 by ANSI as an American National Standard, was originally developed by IBM and submitted to NBS. Thus, DES, although originating as a private specification, is now a formal US standard and in the public domain. On the other hand. the RSA specification for public key encipherment is widely published but privately owned. In most cases, use of RSA requires that a royalty be paid to the owners of the RSA algorithm. Although both DES and RSA are widely implemented, products based on both DES and RSA are subject to controls that apply in many countries to the export of encipherment devices. A more recent encryption algorithm is PGP (Pretty Good Privacy) which is being used widely for enciphering e-mail, particularly over the Internet. PGP software and documentation is copyright but the source code and documentation are available free and widely available over the Internet. Licensed versions can also be purchased for commercial use in Canada and the US. Encipherment export restrictions also appear to apply to PGP but the software is being freely used all over the world. Presumably, any future endorsement by public sector organizations of either de facto standards or PASs depend on there being criteria to identify what constitutes an acceptable specification. To simply permit the procurement of products and services that claim to meet a de facto standard or a PAS would be almost equivalent to allowing the purchase of anything and would bring us close to the situation that existed before the development of standards-based IT procurement policies. PASs and the formal standards process The standards organizations have taken several steps towards recognizing specifications produced outside the formal standards process. The first major move occurred some years ago when the International Standardized Profile (ISP) was established as a new type of standards document. An ISP is a specification of how existing standards (and their options) are to be implemented to achieve a particular task. ISPs are not developed by ISO: rather they are developed by external groups (such as the regional workshops and industry consortia) and harmonized internationally before being submitted to ISO for fast track approval. The ISO ballot is not a technical ballot but a "process" ballot that confirms that due process has been followed. However, the ISP process does not make provision for non-standard specifications such as de facto standards or PASs to be included or referenced. ISO Joint Technical Committee 1 has recently approved a process that provides a means of recognizing externally produced specifications as formal ISO standards. Details are provided in the document The Transposition of Publicly Available Specifications into International Standards - A Management Guide [4]. The process described in this guide allows for a specification from any source to be submitted to ISO by any National Body or A-liaison organization for a "fast track" ballot. With this process, it is possible for a PAS to receive endorsement as an International Standard in 6 months. Annex B of ref 4 details the criteria for PAS consideration in ISO. While the list of criteria is somewhat lengthy, it raises questions that should be considered by any organization considering using a PAS. Areas covered include characteristics of the PAS originator/submitter; information on the PAS itself such as maintenance arrangements and future plans; information about the intellectual property rights of the PAS - patents, trademarks, copyrights etc; and information about the development process, documentation quality and stability, and alignment with other specifications. This annex could well provide a useful checklist for anyone considering endorsement of a PAS. ISO has thus made provision for PASs to be formalized and, as part of that process, to be subjected to international scrutiny based on pre-defined criteria. What has not yet been determined is the extent to which PAS originators will take advantage of this process to gain formal and international recognition for their specifications. There is, as yet, no resolution of the problem of how standards can make reference to PASs, though ISO is currently examining this issue. The Future of Public Sector IT Policies Any qualitative examination of the effects of mandatory versus discretionary OSI procurement policies would appear to indicate little difference in the overall results achieved. With only a few notable exceptions, such as the experience of the government of North Rhine Westfalia [5], most administrations have had mixed success in trying to implement their IT standards policies. Nowhere can it be claimed that a policy has been totally successful but nor can it be claimed that a policy has been a total failure. In each administration, the respective OSI policy has met with some degree of success and some difficulties. The problem now facing administrations is that, in some areas at least, market forces are over-riding the policies and specifically, the requirement to use standards-based products. This is particularly the case for office technologies and applications packages [2] but also extends to the procurement of non-standard communications protocols. While some have suggested that changing the policies to permit procurement of PAS-based products will provide a solution to those areas where policy is not being followed, a simple change in the degree of permissiveness of the policies is unlikely to contribute to overall interoperability objectives and could be counterproductive, particularly if other related factors are ignored. The objectives of the IT policies remain valid. It is the means of attaining those objectives that we must question. In most cases, the policy requirements have not changed and most administrations would agree that the objectives of their respective IT policies remain valid. The requirement for wide and "open" connectivity among IT systems is not about to change. Non- discriminatory procurement will remain a fundamental requirement for public sector procurement for the indefinite future and, for the next few years at least, there will continue to be a growing demand to interconnect diverse systems. What is in question is whether the policy objectives are being achieved, the extent to which current policies are contributing to the achievement of those objectives, and whether modification of the policies would make attaining the objectives easier. Specifically, should the policies be broadened to permit the procurement of IT solutions that do not comply with formal standards? It is not productive to try to standardize all aspects of IT - focus on the critical components to facilitate interworking. Policy requires the procurement of standards-based IT and yet it is clear that, in some areas much of the hardware and software being bought in the public sector never has never complied with any formal standard. Examples are the IBM-compatible PC, the DOS operating system, MS Windows, Wordperfect and MS Word. In other areas (such as telecommunications connectors and physical layer protocols) it is almost inconceivable that a standards-based product would not be bought. Even though different implementations or different versions of the hardware or software may not be completely compatible, a significant degree of interworking is often possible. It is also possible to transfer documents successfully from one word processor to another, subject to certain constraints, and from, for example, an Apple Macintosh to an IBM PC. This provides an illustration that perhaps we can interwork successfully in some areas without there being formal standards and without being locked in to a single supplier (though it must be recognized that there is often a significant (though unquantified) cost involved due to the time and effort involved in trying to resolve problems of incompatibility and due to reduced efficiency of, for example, working with the cumbersome converted files). IPSIT members agree that in some areas, standards are essential, in others merely desirable. For instance it is not essential that there be a single standard for a word processor: it is essential that interchange formats and interfaces be standardized. Development of standards for products that have an anticipated short lifespan is neither appropriate or practicable. During the CEC Workshop, several references were made to the need to prioritize what should be standardized in IT but any indication of how this might be attempted is lost in the generalities of the workshop recommendations [9]. It may, in fact, prove a difficult, lengthy, and perhaps even futile exercise to try to establish a means whereby prospective IT standards users can prioritize the standards development process. Increasing the amount of bureaucracy in the standards process will certainly not improve the situation. There are two possible ways of influencing the process that require no change in the standards infrastructure: those who establish policies requiring the use of standards could be more specific in saying what they want to be standardized; and the organizations that contribute to the development of standards could be more discriminating when it comes to approving new work item proposals. The user needs to provide a better indication of where standards are essential, where they are desirable and where they are specifically not desirable. One way of assessing future focus for IT standardization might well be to examine the major needs for interworking between the various levels of government. Here we find the primary requirements are:
In some respects, current policies discriminate against standards-based products On the issue of cost, it is hard to criticize a department for choosing the lowest cost, functional solution, particularly in an era of cutbacks and shortage of public funds. A premium of 3 or 4 hundred percent for a standards-based solution is totally unacceptable. Yet, as Isabel Valet points out [6], the cost premium of standards-based products is largely due to the testing requirements imposed by public sector policies. It is noteworthy that no comparable requirement exists with respect to the procurement of products and services that are not standards-based (even though, according to policy, many of these should not be bought in the first place.) If a change were made to the policy to permit the purchase of PAS-based products, it seems highly unlikely that any testing requirements at all would be imposed on the PAS products. There certainly seems to be a case for reviewing the stance with respect to testing requirements to ensure that any such requirements are equally applicable to all procurements. Mixed messages on the part of administrations and suppliers do not contribute to the achievement of policy objectives IT Policy has raised the profile of standards-based solutions but there are a number of reasons why non standard products continue to be bought in apparent defiance of policy. In addition to those already mentioned (i.e. non-availability of a standards-based solution; inadequate functionality; high cost; and simple pressure to buy what everyone else is buying) it is also the case that many users have been unwilling to take the trouble to find out about standards-based products and some vendors have been unwilling to promote them. In most cases, where a user wants to buy a non-standard product even when a functional and cost- effective standards-based equivalent exists, administrations have been lax in enforcing their own procurement policies. If an administration, having put in place a policy that demands standards-based products, then neglects to enforce its own policy, it is hardly surprising that suppliers and users question the administration's commitment to the policy. Likewise, if a vendor invests substantial resources to develop a standards-based product, then fails to promote that product at least as vigorously as the alternatives, the buyer cannot be held entirely to blame if an alternative is selected. Clarity and consistency are important contributors to the success of a policy. A change to IT policies to accommodate PASs has the potential of being beneficial ( i.e. by supporting the long term interoperability objectives, complementing the standards-based solution, and contributing in a positive way) or destructive (i.e. by sending mixed messages and by discriminating even more against the standards-based solutions). Additionally, as Ray O'Connor [1] points out in his recommendations, in formulating any changes to accommodate PASs, policy makers should avoid rewarding anti-competitive practices. Clearly there are grounds to consider broadening the IT policies but particular care will be required in formulating any policy modification. Questions relating to the use or endorsement of PASs by the Public Sector. There are clearly some significant questions to be considered by any organization considering the use or endorsement of any PAS. These include the following considerations. a) General policy questions
b) Specific PAS/technical issues that might influence any conditions to be imposed on the use of a PAS.
A Closing Word. In drawing this paper to a close I have deliberately avoided the term "conclusions" as I realize that the conclusions drawn from the above will, at least to some extent, differ according to the local environment and particular policies in effect. The paper has been prepared for IPSIT rather than by IPSIT. The paper has been reviewed by members and particular points made by members have been incorporated. It is possible that IPSIT may use this paper to develop some collective position on PASs in the future but at this stage it is simply a discussion paper. The paper raises a large number of questions and, for the most part, avoids trying to provide specific answers. (Some answers will, I hope emerge from subsequent discussions.) However, I believe that one conclusion can be safely drawn from the foregoing. That is that any policy that addresses de facto standards or PASs without providing a clear definition of what is meant by these terms and without giving close consideration to the questions raised in the previous section is unlikely to contribute to the objective of improving interoperability. References
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
||||||||
|
 Top of Page |
Important Notices | ||||||
