This paper was presented at the 1997 CAUSE annual conference and is part of the conference proceedings, "The Information Profession and the Information Professional," published online by CAUSE. The paper content is the intellectual property of the author. Permission to print out copies of this paper is granted provided that the copies are not made or distributed for commercial advantage and the source is acknowledged. To copy or disseminate otherwise, or to republish in any form, print or electronic, requires written permission from the author and CAUSE. For further information, contact CAUSE at 303-449-4430 or send e-mail to [email protected].

A Whole-Product Approach to Standards

by John W. Smith

Introduction The gap between In the last few years, the word "crisis" has been associated with information technology support.1 support needs and support resources is large and getting larger. Support mechanisms that have worked in the past have not scaled well to our current information environment and are likely to be even more inadequate in the future. The word "crisis" implies a "turning point" or "impending abrupt or decisive change."2 Adding a few more people to the help desk or a few more courses to the training catalog will not fix the problem. We must make fundamental changes in our information technology environment.3

Most campuses have, at some point in time, tried standardization as a way of managing support quality and cost. This mechanism did not solve the support dilemma, and created its own set of problems. Standards currently do not appear to be a major factor in most of our institutions.4 Reflections upon the causes of these past failures and an understanding of new factors in the contemporary IT environment justify a reexamination of this mechanism. The problems may not be intrinsic to the concept, but a function of how they are applied. A number of contemporary sources acknowledge the importance of standards, but offer only a narrow perspective on their implementation.5 This document presents specific ideas and actions that address the limitations of standardization and allow the exploitation of its benefits.

The Problem with Standards

Most people would agree that, if there were no standards, the support problem would be worse. Even where standards are "soft," they lead to a commonly held body of knowledge that facilitates the formulation of questions and the derivation of answers. Users are more likely to find answers from the support organization, or from their colleagues. They can acquire hardware and software with a reasonable expectation that it can do what they want, and that it can be fixed when it breaks. Standards make finite the body of knowledge and skills the technology support staff need to master.

The problem with standards as they have been implemented in the past is that they focus almost entirely on technology. A typical manifestation of standards is a list of "supported" hardware and software. Even where special training and documentation is provided for the standards, the focus is on the technology entity--a machine or a program. When an institution standardizes on specific hardware or software, such as a PowerBook 3400 or Word97, the IT organization is given an impossible task, and the users are given an incomplete solution to their needs.

From the user's perspective, the hardware and software are just a few links in the long chain of information entities/functions they need to do the work for which they where hired. Hardware and software standards increase the reliability of those particular links, but do not make the whole chain significantly stronger. Users feel the restrictions of the standards but see little obvious and immediate benefit. They justify exceptions, which become the rule, and the institution and the users loses most of the benefits of standardization.

From the perspective of the support staff, current standards schemes lay two traps that are impossible to escape. There are an infinite number of ways we can apply a PowerBook 3400 or Word97. A numerically small but operationally significant component of our constituency, the innovators and early adopters,6 actively explore the technology and the ways they can apply it. If the standards are of the form (most often seen), "We support the PowerBook 3400" or "We support Word97," the institution has created a level of expectation that can not be met with any amount of resources.

The second trap is a consequence of the customer orientation we have worked so hard to create in our support staff. Those who work directly with users understand that technical standards define only a part of the required information environment. When they try to help in the areas beyond the standards, they are in an area with potentially unlimited demands, and with little guidance as to how far they should go. If they limit their efforts to the standards neither they or the users have the satisfaction of a completed job.

From the institutional perspective information technology support appears to be an unlimited sink for resources--the more they provide, the more the users want. They continue to feed the beast, not because they understand its value, but because they are afraid not to. Fear may be a good short-term motivator, but that is not what you want enabling the development of the institution's critical information systems.

What does this analysis of the problem tell us? For the institution, we need to replace fear with understanding. We must demonstrate that IT support has a first-order impact upon the primary missions of instruction and research,7 and present technology as an asset, not just a cost. We can do this by more directly linking our support objectives with institutional goals. For the users, we need to develop support mechanisms that meet 100% of their needs. We can do this by creating a mechanism that identifies all the links in the chain of support and making sure that each link is strong enough to carry the load. For the IT organization, we can identify the links for which it should assume the primary responsibility and direct its energies to deliver those links with a very high level of reliability and robustness.

Standardization offers a mechanism that addresses all of these issues. Although the past impact of standardization has been marginal, there are several characteristics of the contemporary information environment that suggest revisiting the concept.

The Contemporary Information Environment

There are two factors in the contemporary information environment that are particularly relevant to the concept of standardization. One has to do with the users, and the other with technology.

Users

Ultimately, the information needs of every member of our community are unique. Our faculty are selected to cover the widest possible range of knowledge. Each student pursues learning in a different manner, and each administrator has their own area of responsibility. The first people on campus to use technology, the innovators and early adopters, are very good at adopting the technology to their unique needs. They have the ability and inclination to explore technology and see these efforts as both pleasurable and profitable. They are likely to justify this time as being necessary to meet their unique responsibilities. They are the people most likely to chaff under the restrictions of standards, as they know they can create a better environment for themselves, and do not see the effort in doing so as a cost.

The innovators and early adopters, however, are not representative of the contemporary campus IT user. The early majority, late majority, and laggards8 make up the bulk of our users--the mainstream. They have very different characteristics from the innovators and early adopters. Today's mainstream user is not particularly interested in technology, does not want to invest any time or energy in learning technology, and is very intolerant of lack of reliability and robustness. They want to "do" teaching and research (or learning, if they are students, or administration, if they are administrators). They understand that technology has become an indispensable tool in these pursuits and that they must use it. But any effort spent on technology is effort not directed toward their discipline. Technology is valuable for its solutions, but not for itself. They want an IT environment characterized by information, not technology. They want a production environment, not an exploratorium.

Technology

Two characteristics of contemporary technology, power and reliability, have important implications for standardization. Everyone is familiar with the affordable power enabled by Moore's Law.9 You might also have heard the phrase, "What Moore giveth, Gates taketh away." Most of the cycles in today's desktops are not used for more elegant, sophisticated computation, but for user interfacing. Properly applied, this power can be used to bring the focus to information, rather than technology, and allow people to interact with computers in human terms.

In addition to power, technology advancements have resulted in greatly increased component reliability. Most of our computers are replaced because they are functionally obsolete, not because they are broken. Mean time to failure values are given in years, not hours. Even software, with its poor reputation for reliability and robustness, works without fault on many desktops.

If our current information environment is lacking in reliability, robustness, and usability, it is not because the technology has not given us the basic components needed to do the job. If our current information environment is not meeting the needs of the institution, it is not because the technology is inherently flawed. Our support and management of technology is still largely based upon the needs of the innovator and early adopter. We need to understand the needs of the mainstream user and create an environment that meets those needs, on the user's terms.

The Needs of Mainstream Users

The information technology needs of mainstream users are based upon information, not technology.10 Reports, catalogues, memos, and images are the focus of their attention, not word processors, networks, or disk drives. Although the ultimate expression of information is unique to each user, there are functional generalizations that are common to most. Examples of such functions include:

Each category can be further decomposed. For example, Correspondence can be of the form:

These can be broken into basic information entities and processes. US mail to a colleague requires:

Accurate, up-to-date addresses could be maintained in an on-line directory. Access to such a directory might require:

The desktop computer can be broken into its component parts (CPU, display, printer, etc.) and the processes necessary for its function (acquisition, installation, training, consulting, maintenance, etc.), and each of these parts further decomposed (vendor negotiation, order forms, funding, etc.).

There are two important ideas to be derived from this decomposition. The first is that the analysis starts with the high-level information needs. Meeting these needs is what makes a difference to the mainstream user and the institution. If these needs are not met, the technology infrastructure, no matter how elegant or efficient, is not contributing what it should. Historically, our standardization efforts started with technology. It was up to the user to integrate these standards into information solutions. Innovators and early adopters could do this, but mainstream users will not.11 We must create standards based upon information functions.12

The second important concept is that all of the links in this chain must work. A single fault, no matter how trivial, can cause the entire system to fail. To the mainstream user, poor quality paper jamming the printer can change technology-based correspondence from an effective way of communicating to a frustrating and inefficient process. Users require 100% solutions,13 what Moore calls "whole products"14. We must create standards that provide a 100% solution to important information needs.

Defining Standards

Implementing a scheme of this magnitude and potential impact requires a large and risky effort. With good planning and careful management that effort will not be beyond the capabilities of most institutions. There are two fundamental issues that must be addressed in the implementation of information-based standards.

How do we define standards that deliver a 100% solution when every individual information environment is unique?

The real problem we are dealing with is not a lack of solutions, but an excess. There are an infinite number of ways that a user's information environment can be configured. Some configuration parameters are in response to unique needs, but most are a result of circumstance or personal idiosyncrasies. How do we distinguish between the latter class of parameters and those that are truly necessary to meet the user's needs?

The answer is that we, the IT organization, can not. Any effective standardization scheme must accept the fact that the standards the institution formally supports are but a part of the total effort needed. Our standards environment must reflect our distributed information environment, with distributed authority and distributed responsibility. Each user must be free to create their own environment, but must also accept the responsibility for the unique parts of that environment.

I have explored the following statement with a number of people and have yet to find anyone in disagreement:

"We can create a standard information environment that meets 80% of the needs of 80% of the population."

A memo is unaware of whether it was created on a Macintosh, a Compaq, or a Sun. Any of these platforms have the power to meet our basic information needs, and the reliability to do so with minimal support. Take the following example configuration:

This configuration would easily meet the 80-80 rule. More importantly, it would serve as a base for the unique 20%. The platform easily accommodates statistical, desktop publishing, CAD, and other software to meet special needs. The basic platform and the special software are highly configurable, allowing each user to create their own unique "look and feel" while retaining a common technology base.

Today much of the effort our users expend on technology goes into supporting the 80%--making the printer work, getting the document to the colleague in a readable form, twiddling the projector to make the image viewable. If the 80% baseline could be delivered to the users with a high degree of reliability and robustness they could spend more of their time on the 20% that makes a difference in their discipline. With a good information/technology architecture even the 20% who need a completely unique environment can be integrated into the campus information environment.

Standards must be thought of as a hierarchy/matrix, rather than a monolith defined by the IT organization.15

A workable standards scheme must be designed with this layering ability. It must also be able to evolve along with user needs and technology developments. The layered, distributed architecture provides a mechanism for growth. For example, the environment created by the innovators in the Spanish Department might be easily extended to handle other Romance languages. A small effort by the IT support organization could assimilate this capability into the baseline standards. For the most part, individuals and departments should bear the cost of the exploratory efforts needed to create their unique environment. In the case where that effort could result in a product with broad or future benefit to the institution, the central support group might become a partner in the development. This allows the institution to take advantage of the energy and effort of highly motivated individuals, and to explore many more areas than could be achieved by the central technology group alone.

Implementing the Standards

The failure of previous standards efforts can not be attributed completely to their lack of the whole product approach. Even when the expectations are limited to technical aspects, a good set of technical standards does not demonstrate its potential impact upon service requirements and customer satisfaction. The rewards of standardization do not come simply because a good set of standards have been defined. Intense management is required to realize the benefits. This is the second major issue critical to the success of information-based standards.

How do we implement a standards scheme that requires both high-level integration and individual independence, that impacts the culture of both the IT organization and the users, and without adding significant new resources?

Critical Constituencies

There are three campus constituencies that are critical to the success of standardization. A successful standards effort requires the full support of the administration and IT organization, and the willingness of the faculty to let it happen.

The Administration: Many of the benefits of standardization are second- and third-order effects, and are only significant in the aggregate. Standardization that saves 5000 information workers 15 minutes a day adds the equivalent of 150 people to the staff. The time early adopters spend playing with technology does not necessarily enhance the goodness and reputation of their department. Users optimize their local environment, not institution's. The administration must understand the hidden economy16 of information technology and be willing to invest in standards.17 Although the effects are lower-order, standards will have a significant impact upon the higher-level goals of the institution.

The IT Organization: Although distribution is the essence of the new standards model it will not come about without a lot concentrated exhortation and effort. The central IT organization is the logical place to focus this leadership. It means, however, that the organization's internal and external perspectives must change. Creating a hierarchy/matrix of standards that does not lose things in the cracks requires close coordination and real teamwork. Although we seldom admit it, "That's not our responsibility" is an operant reality in most of our organizations (and users). Even though it is for their benefit, it is unrealistic to expect our anarchical user community to take the responsibility for identifying every crack. The IT organization must assume the responsibility for identifying the critical links in the information chain, but share the authority over the standards with the users.

The internal changes required of the IT organization will be even more traumatic than the external. Creating a standard environment that is reliable and robust is a difficult and tedious job. Our organizations have become very good at fixing problems when they occur. It requires a much higher level of expertise and management to find and fix the problem before the failure. Our technology experts will have to become true experts, not just folks one page ahead of the users. Testing and verification and other boring operations will have to become integral to the way people think and work. Technical gadabouting must become subservient to attention to detail.

The Faculty: Although a few of the faculty can be expected to understand and appreciate standards, we can expect most to be indifferent or antagonistic. The innovators and early adopters--those who are almost "one of us," are least likely to accept restrictions on their environment. They can probably be cajoled into supporting standards in the abstract, but when their favorite techy no longer has the time to talk to them (because they are committed to the standards effort), that one-time ally may turn into an adversary.

The mainstream user is interested in results, and until standards deliver real value to them, will be inclined to ignore the whole effort. The may become antagonistic if they perceive that the standards effort is diverting resources from "important" things, like books for the library, Teaching Assistants, or faculty salaries. The best strategy with the faculty is to fully involve and exploit those who understand, and try and keep everyone else from being too disruptive until the scheme is delivering obvious value.

 

Top-Down Versus Bottom-Up

Any scheme of this magnitude presents a fundamental conflict between the need for high-level planning and coordination and the immediacy of solving real problems. A proper design takes time and effort. Implementation without design and planning wastes resources in duplicated efforts and backtracking. The problems, however, will not wait for the "best" solution. If standards do not exist to guide solutions, the users will accept any idiosyncratic approach that works. Any implementation plan must acknowledge and explicitly address this conflict.18

Top-Down (Enabling) Activities

High-level design and planning are critical to the success of standards for four reasons:

Interconnection: A basic expectation in today's information environment is the interconnection of heterogeneous components (technological, informational, and organizational). The combinatorial problem of implementing these connections one-to-one quickly scales beyond the capabilities of even the richest institution. The task can be made manageable by connecting the disparate components to a common architecture. The existence of such an architecture is a major factor in the success of the Internet.

Coordination: The 100% solution will result from the efforts of many groups and individuals. An "Information Czar" with total institutional authority is unlikely to exist in higher education, hence planning is the process most likely to provide the necessary coordination. Planning can help ensure that all the required links exist and are reliable and robust, and reduce wasteful duplication of effort. Planning can keep institutional priorities in sight while solving local problems, and enable resources devoted to unique environments to also contribute to the general good of the institution.

Response to Change: An oft-heard excuse for lack of a significant standards effort is that technology changes too rapidly. Technology does change very rapidly, but information entities/processes change at a much slower rate. A standards architecture that focuses on information makes it possible to replace the underlying old technologies with new, with minimal disruption to the user. The standards process must anticipate and explore new technologies so that they can be integrated into the "official" standard environment before the innovators and early adopters have created multiple de facto standards.19

Economy of Scale: Although the use of information technology results in an infinite uniqueness, there are many common elements in both the informational and technical environments (ultimately, the whole world can be distilled into ones and zeros). A top-down perspective helps the institution identify these areas and create support mechanisms that take best advantage of economies of scale.

Feasibility

The first step in creating an information-based standards environment is to identify the information entities and processes of greatest significance to the institution (refer back to the example in the "The Needs of Mainstream Users" section). This may seem an impossible task, but there are two factors that make it doable.

The 80% Rule-Of-Thumb

The 80% rule-of-thumb tells us that 80% of the work of the institution will be accomplished by 20% of its resources. The institution may generate thousands of letters in a day, each with unique address and/or content. The basic form of the letter, however, has a limited number of permutations. It would not be difficult to create a set of standard letter formats that would meet 80% of the needs of the institution. The size, shape, color, and texture characteristics of an image are infinitely variable, but the use of the image in the classroom is limited to drawing on the board, passing out Xerox copies, holding up the poster, or showing via a 35mm slide or LCD projector. We could create standard image formats and standard presentation environments that would meet 80% of the needs of our users. Indeed, much of this work has been done for us. Word97 has a whole folder of letter templates and, if you use the defaults, scanning an image into PowerPoint is click and drag. In higher education, the solution of 100% of the problems requires infinite resources. 80% is achievable.

Common Components

The second enabling factor is that when we start the decomposition process, we find common elements that are used throughout the information environment. A contemporary "address" typically contains name, title, physical location, telephone number, FAX number, E-mail address, and perhaps even the URL of your home page. The information process of finding the address is similar whether the communication is via US mail, E-mail, telephone, or a physical visit. A standard file transfer mechanism cares little whether the file is E-mail, a word processed document, a sound-bite, or a high-resolution image. Contemporary word processing packages include very capable spreadsheet, drawing, image editing, and desktop and web publishing capabilities. A few configurations of a standard desktop, as exampled in the "Defining the Standards" section, would run all of the applications required by 80% of the users. We can achieve a significant improvement in efficiency and effectiveness by focusing on a few common elements.

Top-down efforts focus on two areas; architecture and a baseline information infrastructure.

Architecture

Information architecture, like physical architecture, provides design and oversight. Blueprints show the overall design and the connections between components. They aid in the identification of missing or weak links, and help draw the lines between areas of central and peripheral responsibility. Specifications show the critical dimensions and parameters that are needed when interconnecting components. With a well developed design and a full set of specifications, individuals can independently create local solutions that will be compatible with the institutional environment. When guided by an architecture that anticipates the future, both local and baseline solutions can be implemented without the fear that they will be dead-ended by changes in technology.20

No design, no matter how well conceived, is implemented without change. The architect plays a critical oversight role in making sure that changes are truly necessary, that they do not compromise the design, and that they do not overrun the budget. Many information technology projects fail because, when faced with difficulties, the implementers change the problem to fit the solution. Oversight is one of the main reasons why it is desirable to assign the responsibility for architecture and implementation to separate individuals or groups.

A Standard Infrastructure

A good architectural design will make it fairly easy to identify the collection of components that are the core of the institutional information environment--the 80%. Because this portion of the environment is used regularly, by everyone, improvements generate a good return on their investment. The development of a highly usable and reliable infrastructure21 is probably the single greatest action an institution can take to improve the efficiency and effectiveness of its information environment. Although the baseline standards must be defined in conjunction with the users, the central IT organization should take responsibility for their implementation. It is the only group with the resources necessary to do the job right, and that can best exploit economies of scale factors.

Architecture provides the big picture needed to see all the links needed for the 100% solution, and the detailed view that lets us develop individual components. It helps break a very large problem into solvable pieces. By making the biggest piece, the baseline infrastructure, highly usable and reliable, the institution allows the users to devote their efforts to meeting their unique needs. These two factors are key to the creation of a comprehensive, distributed standards environment.

Bottom-Up (Actualizing) Activities

Architecture and infrastructure enable the work of the institution, but do not actually solve any problems. It is also unlikely that an institution can wait for a comprehensive architecture and technical design before implementing standards. Even if we had the time, it would be difficult to develop a good design without the benefit of hard data and experience. An institution needs to solve its critical problems while it develops architecture and infrastructure. This process can be managed such that each activity compliments and enhances the other.

Most of our campuses have cases where technology has been used to solve important instructional, research, or administrative problems. An example might be the faculty member who uses the technology classroom to show students current events information from the web, and historical data via images taken from 35mm slides and video newstapes. That instructor has developed a process that allows her to find and retrieve the current events web page at the time she wants, and project it such that the whole class can see it. She has taken all the steps necessary to convert her 35mm slides to electronic format (including finding the right file format and compression ratio), store them in a place that can be accessed from the classroom, and project them.22 She has figured out a similar process for capturing the information from the videotape.

An oversimplified-for-sake-of-illustration bottom-up standards process might have a group of people look over that instructor's shoulder as she goes through all the steps needed to create and deliver the classroom lecture (the 100% solution), document the steps and parameters, and promulgate this as a standard for classroom presentation. The next instructor wanting to do similar things in the classroom has a standard path already mapped out for them, hence should achieve their 100% solution with much less effort. The content of their images might be art, rather than historical events, but that makes no different to the underlying process and technology.

An extension of this model would have the institution pick one or more specific information tasks and put together a team to create a set of standard components, systems, and processes that would result in 100% fulfillment of the task. Example tasks might be:

Higher-level standards would be used where they exist and are appropriate, otherwise local standards would be developed for the specific task. There are a number of criteria that can be used to select appropriate projects. Two should be considered essential:

This helps avoid the stigma of failure and begins building support for the concept of standardization. Other criteria can help select the projects with the best cost-benefit ratio:

Working Both Ends Toward the Middle

The first and last statements in the preceding paragraph are the key to successfully designing and implementing at the same time. Local solutions have access to higher-level design wisdom and common tools and components. Individuals do not have to reinvent every component and process needed for their solution. Existing architectures and standards are constantly tested against real problems. If the high-level standards are found to be inappropriate, they are changed. If similar local standards are being generated in different projects, they are migrated to the architectural level. If there are higher level standards that are not being used they are eliminated.

This approach allows us to solve the here and now problems while minimizing the accretion of idiosyncratic solutions that become more and more costly to support as they age and diverge from the common environment. It accepts the fact that we will not get it right the first time. It provides, in the spirit of TQM, for constant refinement, rather than abandonment and regeneration. For example, the first iteration of a standard process might require the user to access several different commands and manually enter half a dozen parameters. The second iteration could convert these actions to a click on an icon or menu item. The effort would be justified in terms of ease of use, reduced training and documentation requirements, and reduced opportunity for failure.

This approach obviously places very high demands for communication, coordination, and cooperation. Implementers need to accept the presence of the architects looking over their shoulder. Architects must be open and accepting of the criticism of the implementers and not become emotionally attached to "their" standards. Users must be willing to discuss their "real" needs and accept that they must pay the cost of their unique needs. Service providers must focus on the mainstream user's view of usability and reliability.

User Buy-in

Standards, no matter how well conceived, will have little impact upon the institution if the users do not accept them. How do we get user buy-in?. We can do this by quaranteeing them a specific level of service if they follow the standards, and by making the standard solution the path of least resistance.

Existing standards "contracts" imply,

"If you follow the standards you are most likely to get support and are least likely to have unknown problems."

We must provide users a "contract" that says,

"If you follow the standards, we will provide a guarantee that you will succeed in the information task."

For example, if you use a standard font with a standard letter template with the standard word processor on a standard system connected to a standard printer with the standard paper, only one print job out of 1000 will not be at the printer when and how you expect it. Users would not be prevented from trying different fonts, buying "the latest, greatest" printer, or using fancy, colored paper. But if this didn't result in readable hardcopy, they would be responsible for making it work. If their primary interest is in getting the letter of recommendation out, they can do so with the standard environment with the least amount of effort.

Delivering on the guarantee and creating a path of least resistance requires a high-level of institutional commitment. Few institutions in the past have been truly committed to standards, so it is not surprising that the potential has not been realized. The best way to explain the level of commitment needed to fully exploit standardization is to present some examples.

To be accepted by the users, standards must obviously make their life easier, and minimally occupy their mind-space. Because of the hugely diverse information needs of higher education, standards with limited scope will have little impact upon the total cost of support. An institutional commitment to whole product standards is a large investment, but will result in a large gain.

Conclusion

Tweaks and patches are unlikely to pull an organization out of a crisis. The deeper the roots of the crisis penetrate the institution, the more holistic and decisive must be the solutions. Most people would agree that information technology pervades the academy. Standardization, based on whole product concepts, is one of the more powerful tools that we can apply to the current problems in information technology. Like all powerful tools, it requires careful management and application if it is to do more good than damage.

I have tried in this paper to present both theory and rationale, and concrete example and action. An institution applying these ideas will have to adapt them according to is own goals, culture, and resources. To be successful, it must understand the "why" of an action, not just the "how." To be successful it must transform the institution, not just the technology organization. To be successful it must understand a little bit about where it has been, and a lot about where it is going. If the price of success seems excessive, it should think about the cost of failure.

Bibliography

Barry, William F., Moving to Client/Server Application Development: Caveat Emptor for Management, Cause/Effect, Vol 17, No 4, Winter 1994, http://www.cause.org/ir/library/text/cem9444.txt

Burns, Laurie L. and Cheryl Munn-Fremon, Partnerships with the Deans: Delivery of the ‘Whole Product’ Cause/Effect Vol 18, No 2, Summer 1995, http://www.cause.org/ir/library/text/cem9523.txt

Gorry, G. Anthony, Envisioning the System-After-Next, Educom Review, Vol 32, No 2, March/April 1997, http://www.educom.edu/web/pubs/review/reviewArticles/32230.html

Heterick, Robert C. Jr. and John Gehl, Information Technology and the Year 2020, Educom Review, Vol 30, No 1, January/February 1995, http://www.educom.edu/web/pubs/review/reviewArticles/30122.html

Klingenstein, Ken, Network Management: Tools and Best Practices, in Campus Communications Strategies, a CERN Virtual Seminar (CD-ROM), See http://seminars.cren.net/ for information about seminars

McClure, Polley A., John W. Smith, and Toby D. Sitko, The Crisis in Information Technology Support: Has Our Current Model Reached its Limit?, , CAUSE Professional Paper #16, 1997, http://www.cause.org/ir/library/html/pub3016/16index.html

Moore, Geoffrey A., Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers, Harper Business, 1991 (page numbers from paperback edition, 1995)

Nelson, Keith R. and Richard W. Davenport, A Planning Process Addresses an Organizational and Support Crisis in Information Technology, CAUSE/EFFECT, Vol 19, No 2, Summer 1996, http://www.cause.org/ir/library/html/cem9626.html

Noblitt, James S., Making Ends Meet: A Faculty Perspective on Computing & Scholarship;

Top-Down Meets Bottom-Up, Educom Review, Vol 32, No 3, May/June 1997, http://www.educom.edu/web/pubs/review/reviewArticles/32338.html

Office of Computer and Information Systems, The Pennsylvania State University, Observations on Benchmarking Information Technology Support, Cause/Effect Vol 18, No 1, Spring 1995, http://www.cause.org/ir/library/html/cem9626.html

Readers Respond Column, Question: Is your institution experiencing a crisis in support for information technology…, CAUSE/EFFECT, Vol 19, No 3, Fall 1996, http://www.cause.org/ir/library/html/cem963c.html

Ringle, Martin D. and David L. Smallen, Can Small Colleges Be Information Technology Leaders? CAUSE/EFFECT, Vol 19, No 2, Summer 1996, http://www.cause.org/ir/library/html/cem9625.html

Shapiro, Jeremy J. and Shelley K. Hughes, Information Literacy as a Liberal Art: Enlightenment proposals for a new curriculum, Educom Review, Vol 31, No 2, March/April 1996, http://www.educom.edu/web/pubs/review/reviewArticles/31231.html

Smith, John W., Making Standards Work: A "Whole-Product" Approach to Standards, ACM SIGUCCS User Services Conference XXV, Monterey California, November 9, 1997, http://poe.acc.virginia.edu/~jws3g/Publications/MakingStandardsWork.htm

Solomon, Martin B., The Need to Rethink Decentralized Computing in Higher Education, Cause/Effect, Vol 17, No 4, Winter 1994, http://www.cause.org/ir/library/text/cem9440.txt

Steinbrenner, Karin, Knowledge-based Reengineering, Cause/Effect Vol 15, No 2, Summer 1992, http://www.cause.org/ir/library/text/cem9228.txt

Twigg, Carol A., The Changing Definition of Learning, Educom Review, Vol 29, No 4, July/August 1994, http://www.educom.edu/web/pubs/review/reviewArticles/29422.html

Willis, Bill, In Search of a Common Delivery Target, November 1996 , http://www2.ncsu.edu/willis/target.html

Yohe, J. Michael, Information Technology Support Services: Crisis or Opportunity?, CAUSE/EFFECT, Vol 19, No 3, Fall 1996, http://www.cause.org/ir/library/html/cem9633.html

Endnotes:

1. A Planning Process Addresses an Organizational and Support Crisis in Information Technology, Nelson,  Question: Is your institution experiencing a crisis in support for information technology…, Readers Respond Column, Information Technology Support Services: Crisis or Opportunity?, Yohe, The Crisis in Information Technology Support: Has Our Current Model Reached its Limit?, McClure4

2.Microsoft Bookshelf '95

3. Information technology environment rather than computing center. The former implies a much broader scope than the latter. Virtually all of our organizations have changed their names, but have not broadened their thinking to match the differences in the concepts. This gap is a major factor in our inability to respond to today's problems. (This is not to say that IT organizations have not changed. They have, but not at the rate at which information technology is permeating our institutions.)

Heterick offers this relevant comment about environment, "In fact, the word user will be archaic, because systems won't be tools anymore; they will simply be the environment. And one doesn't use an environment; one lives in it."

4. A random sampling of the web pages of 24 institutions from the http://www.clas.ufl.edu/CLAS/american-universities.html web page turned up only 8 that contained any mention of standards, and many of these were in the form of the list of equipment and software sold by the bookstore. Only one institution had anything approaching a "hard" standard. (The likely error is under representation, but is probably not enough to invalidate the conclusion.)

5. "…standardization may be the most important aspect of computing cost control that an organization can employ. It can affect every component of costs. Standards can reduce initial acquisition costs of hardware and software, reduce the costs of training and upgrades, reduce system development costs, and reduce the among of time required to diagnose and repair both hardware and software problems." Solomon, page 48

"Lastly, one important choice to make among our toolset is budget or authority. Free choice is antithetical to efficient support. We either need to confine the use of technology to standards or to increase our budgets to deal with diversity." Klingenstein

"The key to leaving the chasm behind, however, is to stop custom developments and institutionalize the whole product, to build to a set of standards that the marketplace as a whole can support." Moore, page 204

"Successful implementations of client/server applications must be built upon standards of a well-defined systems architecture if they are to be reliable, scalable (sic), expandable, and enduring. A comprehensive strategy defining standard requirements for software, operating systems, data administration, application programming, interfaces (APIs), remote procedure calls (RPCs), network protocols supported, and hardware configuration is a prerequisite for widespread success with client/server-based systems. … The very real potentials of interoperability, decentralized independent software development or acquisition, and independence from proprietary systems will fail if the institution does not first succeed at further establishing and adhering to standards." Barry, page 14

"Principle 2: Best-in-class institutions encourage early implementation of information technology infrastructure and standards." OCIS, page 25

"Principle 4: Best-in-class institutions use the elements of standards, security, and architectural planning to create a supportive environment for change." OCIS, page 26

"Controlling the diversity of hardware and software will minimize support costs, particularly the staff resources necessary to answer questions, provide training, and assist with upgrades. Adhering to established standards and mainstream products across the entire institution make it more likely that the infrastructure can be efficiently managed. These are particular opportunities for small colleges that are often unavailable to large universities." Ringle

"Once complete, the hardware hierarchy is reduced to fewer layers and communication, with operating and software systems adhering to standards. The resulting architecture not only simplifies the maintenance of all hardware and software systems, it also generates substantial savings in maintenance cost and reduced support staff requirements. Because of standards and simplification, the information infrastructure becomes more robust and reliable." Steinbrenner, page 50

6. "Innovators pursue new technology products aggressively. … This is because technology is a central interest in their life… they…often make a technology purchase simply for the pleasure of exploring the new device's properties." Moore, page 12

"Early adopters…buy into new product concepts very early in their life cycle, but unlike innovators, they are not technologist. Rather they are people who find it easy to imagine, understand, and appreciate the benefits of a new technology…" Moore, page 13

7. As opposed to the second- and third-order effects, i.e., we support the network which allows the web page to appear in the classroom which allows the instructor to show the latest stock-market trends which helps the students understand finance.

8. "… the early majority want to buy a productivity improvement for existing operations. They are looking to minimize the discontinuity with the old ways. The (sic) want evolution, not revolution. They want technology to enhance, not overthrow, the established ways of doing business. And above all, they do not want to debug somebody else's product. By the time they adopt it, they want it to work properly and to integrate appropriately with their existing technology base." Moore, page 21

"Conservatives like to buy preassembled packages, with everything bundled, at a heavily discounted price. The last thing they want to hear is that the software they just bought doesn't support the printer they have installed." Moore, page 47

"These customers want the whole product to be readily available from the outset. They like a product such as WordPerfect because there are not only books in every bookstore about how to use it but also seminars for training, the industry's best hot-line support (out of Orem, Utah, no less) and a whole cadre of temporary secretaries already trained on the product." Moore, page 113

9. "In 1965, Gordon Moore was preparing a speech and made a memorable observation. When he started to graph data about the growth in memory chip performance, he realized there was a striking trend. Each new chip contained roughly twice as much capacity as its predecessor, and each chip was released within 18-24 months of the previous chip. If this trend continued, he reasoned, computing power would rise exponentially over relatively brief periods of time." from http://www.intel.com/intel/museum/25anniv/html/hof/moore.htm

10. Shapiro offers a good discussion on information in Information Literacy as a Liberal Art.

11. "The single most important difference between early markets and mainstream markets is that the former are willing to take responsibility for piecing together the whole product (in return for getting a jump on their competition), whereas the latter are not." Moore, page 114

12. " It is my suggestion that we initiate an on-going, high priority effort to define a "delivery target" to which we will attempt to deliver all of our applications. This target should be independent of hardware, operating system, and vendor, and should utilize emerging web and application framework technology." Willis

13. "Classically, high tech has delivered 80 to 90 percent of a whole product to any number of possible target customers, but 100 percent to few, if any. Anything less than 100 percent, unfortunately, means that the customer either supply the remainder themselves or feel cheated." Moore, page 115

14. On page 115 Moore presents a drawing that shows the Whole Product as the Generic Product plus the following:

  • Additional software
  • Additional hardware
  • System Integration
  • Installation and Debugging
  • Cables
  • Training and Support
  • Standards and Procedures

"In ITD, whole product means that for each product or service we create or offer, we must think about the ancillary needs for additional software, additional hardware, network connections, remote access, training, documentation, consulting support, publicity, standards and procedures, installation, and system integration services (accounting, billing, authentication). To get our products successfully adopted by the majority of customers, we must ensure that if any of these ancillary items is necessary to use the product, it is available to the customer." Burns, page 10

15. On many campuses standards are defined by a committee with user representation, not just the technology organization. Because committee members are chosen from the ranks of the innovators and early adopters, however, the standards are usually more appropriate to the IT establishment than the mainstream user.

16. See the discussion of "A Strategic Economic Model" in McClure, http://www.cause.org/ir/library/html/pub3016/2b.html

17. Many of the time and dollar costs of standardization can be met by reallocating these resources from ad hoc local solutions. The greatest costs to the administration are political rather than financial. Some users will have difficulty accepting the responsibility for their unique needs, or even their infatuations. It will take a good deal of political courage for the administration to deny influential users access to central resources for their personal needs.

18. See Noblitt for a slightly different perspective on Top-Down versus Bottom-Up.

19. Gorry offers interesting ideas in this area in Envisioning the System-After-Next

20. The National Learning Infrastructure is a high-level architectural concept/process directed toward learning. See the three-part series by Twigg, starting with The Changing Definition of Learning.

21. See the section, "A Reliable Baseline Information Infrastructure" in McClure, http://www.cause.org/ir/library/html/pub3016/2d.html

22. See the expanded example in Smith, Making Standards Work: A "Whole-Product" Approach to Standards

[Comments] [Search] [Home]