CAUSE Professional Paper #16, The Crisis in Information Technology Support: Has Our Current Model Reached Its Limit?1 explored the roots of the technology support problem and presented a framework for solution. The critical elements in the solution included a rational economic system, distributed support, standards, and a reliable infrastructure. A major point in the paper is that the information environment must be designed.
It is inconceivable that a school would construct a new building without applying a design methodology and assigning someone the overall responsibility for its conception and implementation. There is a well-developed process for designing physical environments and a profession to guide it—architecture. The architect integrates user needs, abstract concepts such as space, form, and flow, and the technical elements of construction, into a functioning building, on time, and within budget.
Architecture is both structure and process.2 The structure usage is well established in technology, as in "Intel architecture," "the architecture of the Internet," etc. Architecture as process is poorly developed in information technology, and when it is applied it is in a relatively narrow context such as the development of an administrative information system. The user needs, abstractions, and technical elements of the information environment are different from those of the physical environment. The process of architecture developed for building construction, however, contains many elements that can be applied to the information environment.
Four basic traits characterize today’s information technology environment:
Complexity: In today’s information environment complex applications are based upon complex technology underpinnings. Basic user applications such as word processing, e-mail, and web browsing are extraordinarily flexible and powerful, but incomprehensibly large and complex. A reference book for Word 973 contains over 1200 pages. The Windows98 Resource Kit4 is over 1700 pages, plus the contents of a CD-ROM. This complexity makes it difficult for users to do simple things simply, makes it easy for them to fall off the edge, and creates insatiable demands for training and consulting.
The technical infrastructure is becoming more and more transparent to the user, but at the expense of increased demands upon technical support personnel. Today’s PC-based desktop is more complex, in both hardware and software, than the VAX that required dedicated staff. Each component of the infrastructure--the file server, router, dial-in bank, scanner, etc.—requires a high level of expertise to acquire, configure, troubleshoot, and maintain.
Connectivity: Contemporary applications depend upon the interconnection of these complex components. For example, to find a book in the library, the user, from a desktop machine they control and manage, employs a departmental server and local-area network, to attach to the campus wide area net, which takes them to the computing center’s mainframe, which runs the library’s card catalogue. If any single component or connection fails, the user cannot function. The increase in complexity of a system of interconnected components is much greater than the sum of the parts.5 When the chain does break, it can be very difficult to determine where the problem is and invoke the appropriate repair mechanism. A system of control and coordination is required when components belong to different administrative units, further complicating the environment.
Ubiquity: The pervasive use of technology has three implications. Resource numbers are very large. Inefficiencies that were tolerable when only a few people used the technology create significant resource drains when multiplied by everyone on campus. Less obvious, but of greater import, is that the information environment must handle a much greater degree of diversity. It must crunch numbers and process words, and also capture, manipulate, and present sound, and both still and moving images. Ubiquity means that users, as well as information, are diverse. People with little technical background and less inclination to learn expect the full benefits of technology. The information environment must satisfy their needs, while not over-constraining the technically advanced.
Rapid Change: It is universally accepted that rapid change is a dominant characteristic of information technology. User expectations change less rapidly than technology, but at a rate that our institutions still find difficult to accommodate. Investments in technology can turn out poorly if they are made too soon, or too late, in the technology cycle. Even good investments can fail to have positive impact upon the ultimate outputs of the institution—instruction and research—if the faculty and students do not develop along with the technology. Rapid change makes it difficult to predict the future, and provides little time in which to make adjustments when things go wrong.
Information technology support organizations are well aware of these characteristics. Unfortunately, the most common response is to use them as explanations why the information environment can not be planned, designed, or managed. And it is certainly true that most attempts to apply systems analysis, strategic planning, and other design/management methodologies to the whole academic information environment have not been very successful. One of the conclusions in the Crisis paper, however, is that planning and design are imperatives. This does not mean that the failures of the past can be ignored. An understanding of why they failed is important in developing a successful approach.
In general, systems analysis techniques are too rigid and require too much detail to work well in the context of the whole institution. Strategic planning efforts often fail because it is so difficult to couple them into the day-to-day operations. What we need is a design methodology that encompasses the detailed view of systems analysis and the overall perspective of strategic planning, and that extends the process through the implementation phases. Centuries of effort in creating physical environments has produced a design and implementation methodology that addresses many of these issues.
Building architects use a six-step process in designing and implementing a physical structure. These include:
Although the process is basically sequential, it can accommodate parallel and reentrant paths. Program development and schematic design in particular feed off each other as they develop the user’s needs and start converging upon a solution.
Program development: Program development is similar to the process of systems analysis in information technology. It defines the question and establishes it as the basis of the design.
In the first part of their work, called programming, architects determine the concerns of the client for whom they are to design a building and what it is that the client needs.6
Program development translates very abstract concepts, such as "need," "attractive," "interesting" into more realizable specifications, such as "square feet," "paint color," and "multi-level floor plan." It develops the basic parameters needed to specify a building—how much space, room orientation, esthetic theme, etc. It may state requirements in general terms, e.g., "Early American," or specific, e.g., "50± 5%, humidity, 68± 3° temperature," as is most appropriate.
The major role of the architect in program development is to make sure all the right questions are asked, and answered in a way that allows the design to proceed. Many of the questions, such as "how many offices?" can be fill-in-the-blank, while others, such as "An attractive entrance," may require substantial interaction between the client and architect.
Schematic design: Schematic design is a process of pulling together all the considerations of the building, from esthetics through space assignment to budget.
"The real purpose of the schematic design phase, of course, is to identify in graphic form the scope of the project, the relationships of various elements, the general form or forms of the building, and its visual character. When this has been done competently and adequately and has been accepted by the owner, it becomes the map, the set of guidelines, the instructions for the development of the project in later phases. It becomes a yardstick with which to measure the work of the later phases. The program may have assigned square footages to both individual rooms and entire buildings, but not until the schematic design phase will it be known whether the assumptions made and factors applied in programming can be transformed into a real building, nor can its character and quality be established."7
The primary tool of the architect in this phase is the sketchpad and pencil. The basic layout of the building is explored and the architect’s and the user’s ideas tested. The full spectrum of issues, from the site plan to the detailing of the door jams, are easily presented and modified as the process converges upon an esthetic and functional design. It is easy to jump between the worldview and the details in order to see how they fit together. Hundreds of concepts and wild and extravagant ideas can be explored with the expense of a few sheets of paper.
Because many architectural clients have a limited understanding of the technical, esthetic, and financial aspects of a building, it can be difficult for them to express their real needs and match them with a design that can be built, at a price they can afford. If the first design on the sketchpad turns out to be too expensive or too complex, the architect and client can revisit the program in order to see what could be compromised in order to achieve their main goals
If the information needed is something that the client can provide, the architect must find ways to ask questions in a way that the client can answer. Of course, the most usual way is by a direct question, but if this fails (as it often does), the architects can undertake a schematic design of the building based upon assumed answers to those questions. The way the client responds to the schematic design proposal usually answers the architect’s question."8
Together, program development and schematic design can be the most important phases of a building project.
"…the time spent in this early conceptualization period could very well be the most important in the entire project. Those hours and the work accomplished in them set the course for all work that follows. If adequate time is not devoted at this point, the project may be doomed to some degree of failure, if not in serious deficiency in the usefulness of the completed building at least (or at best) in a mediocre building."9
Design development: Once the basic design has been set, the architect begins the largely technical process of turning the design into the plans, specifications, and instructions by which the building will be constructed. In design development it is not expected that the architect be knowledgeable in every aspect of the building. The architect will typically hire consulting engineers for the detailed design of the technical systems--electrical, mechanical, fire protection, etc. If the schematic design calls for unique structures or materials, or if there are special problems such as unstable soil, specialized expertise may be brought into the project. It remains the full responsibility of the architect, however, to coordinate these different activities and maintain the integrity of the design.
It is quite likely in any complex building that detailed design will uncover problems with the schematic design. The utility piping may not fit in the duct space allocated and the required enlargement makes a room smaller than specified by the user. Most such problems can be handled by tweaking the design, but the remedy may require the user to adjust their requirements. The architect, with their understanding of both the user’s needs and the constraints of building technology, is responsible for orchestrating the best compromise.
Construction Documents: The design effort generates two documents that fully describe the building. Blueprints show the relationship of the building to its surroundings and the internal organization of all its parts. The prints range in scale from the site plan, which shows the building in relationship to the local geography, through plan and elevation drawings that show each floor and external surface, to full-scale drawings of details such as window trim, door locks, and foundation anchors. The blueprints do not have to include each and every detail, as each of the building trades have standards and conventions that can be reasonably assumed.
The blueprints show the relationships of the building components and their sizes. Other important information is contained in the specifications. Specifications can be compositional, such as the quality of steel required for the beams or the particular brand of paint to be used, or process, such as the precise steps to follow in pouring the foundation or the method to be used to flush the pipes after they are installed. The specifications must be of sufficient detail to allow the contractors to select the appropriate components for their bid—neither so cheap that they are of insufficient quality, or so expensive that they cause the building to cost too much.
If the building is a conventional design, using conventional building techniques, and the owner can find a knowledgeable and trustworthy contractor, a well-build and highly functional building can be constructed with a simple set of blueprints and specifications. As the building deviates from convention or the construction process becomes more involved, the plans and specifications must become more detailed, more comprehensive, and more unambiguous. Uncertainty and misunderstanding are very expensive to correct after the concrete has set.
Bidding and Negotiation: Few building projects have unlimited budgets. The architect begins constraining the design even in the programming stage, where they help the user develop realistic expectations. Throughout the design process they use professional judgement to balance design and resources. Not until the bids are returned, however, does anyone truly know what the building will cost. It is often the case that the bid price will be greater than the project budget. In this situation the owner can provide more resources, the contractor can offer a lower price, or the architect can modify the design.
The architect plays a pivotal role in negotiating some combination of these responses. They must understand the client’s needs well enough to be able to concede small requirements while maintaining important ones. They must know enough about construction practices to judge how much the contractor can bend. They must understand construction materials well enough to know when cheaper goods can be substituted without degrading the building. These negotiations are complex and messy and significantly increase the risk that some important element of the building will be compromised. It is far better to spend resources doing a good design in the first place, than in reconciling a poor one.
Construction management: The architect plays two important roles beyond the design of the building. They make sure that the building is laid out according to the blueprints and that the materials and processes meet the specifications. Where these are not clear to the contractor, they provide explanation. They resolve differences in interpretation between the client and contractor, and between subcontractors. Although he does not do the work, the architect maintains the responsibility for the overall quality of the building and keeps it on time and in budget.
In any real building project it is inevitable that some aspect of the design will have to be changed. Perhaps the client didn’t realize how small that office was until they saw the walls around it. Or a vendor goes out of business and can not deliver a critical component. Design changes made during construction can be very expensive, and almost always have some ripple-through impact. Someone must make difficult decisions if the project is not to go out of control, and the architect, with responsibilities to both the user and the contractor, is in the best position to make these decisions.
An important part of a building project is its termination.
When the contractor has completed his work, they, the architect,
and the owner inspect the building and generate a "punch-list"
of items that are incomplete or in error. If a problem is the
consequence of an incomplete specification or a user change, the
contractor may decline to correct it without additional payment.
The final act of the architect is to reconcile these problems
and get the building accepted by the client, hopefully to the
full satisfaction of both the user and the contractor.
This process of design comes in as many flavors as there are architects and buildings. It can be applied methodologically, by the seat-of-the-pants, or in some combination. Many of the high-level concerns faced in designing and implementing a physical environment are similar to those in the information environment. The process used by building architects to meet those concerns can be combined with technology analysis and planning techniques to create a very powerful tool for creating and implementing the information environment.
There are enough differences between the physical and information environments that we cannot directly apply the design process of the former to the latter. We can, however, extract from the process specific concepts that are highly relevant to information technology.
Hierarchical design perspective: The building architect delves to the smallest level of detail needed to execute a design while maintaining a holistic perspective on the building structure and the client’s needs. They explore and communicate abstract forms and relationships using graphics techniques, from sketchpads to physical models to virtual reality. How many of us could draw a "site plan" for our institution’s information environment? Such a plan would show the basic information sinks and sources; library, classroom, office, faculty, student, registrar, etc., and describe how they relate to each other. This large-scale view is vitally important in maintaining balance in the environment. It makes it easier to see that an expensive, state-of-the-art network will not realize its potential if it is used to connect obsolete faculty desktops with inadequate library resources.
A hierarchical design environment allows the institution to create "rooms" that are of themselves effective and efficient, and also integrate with and contribute to the overall information environment. For example, the images to be presented in a "high-tech" classroom can exist on the instructor’s desktop, a central server, or on a machine in the classroom. The designer must give particular consideration to the capabilities of the network if the images are stored remotely. Local storage of images makes projection easier and more efficient, but creates problems in manageability and reliability. A hierarchical design environment makes it easier for the designer to remain aware of the capabilities and limitations of the levels above and below the one they are focused on.
Integration of design and implementation: Although we think of architects as primarily designers, their role continues throughout the construction of the building. The inevitable problems in implementation force changes in the design. Because the architect is involved in both design and the implementation, they can manage the changes so that budget and schedule are not compromised, and the integrity of the design is not lost. When the conventional practices of different implementers, such as plumbers and the electricians, conflict, the architect is there to solve the problem in the best interests of the building. The need for construction management increases for more complex buildings, and where more subcontractors are required for its construction.
When the environment is not designed to begin with, as is the case with most of our information environments, the lack of integration between design and implementation is not readily apparent. In the interconnected environment, however, some design is implicit. Even if it is not formalized there is need to coordinate implementation activities. How many cases can we find where a new router was installed, and no one could access the web server? Or the operating systems in the cluster were upgraded, and the lab assignments no longer worked? In a constantly changing environment the perpetual iteration between design and implementation must be managed.
An architect always works against a budget: Every building project starts with at least a ballpark estimate of budget in dollars and time. Even when given broad latitude and charged with being creative and innovative, the architect must be realistic—one inch columns will not support a roof, and a gold-plated exterior will not have to be painted, but… The architect responds to this basic constraint by matching the design to the available resources, and also by shaping the user’s expectations throughout the process.
The information environment in a university is highly distributed and no one is directly responsible for it. It is impossible to know its costs to any degree of accuracy. This makes it more, not less, important to consider costs in its design and implementation. It is well understood that that the greatest cost in installing a network is in digging up the campus. Good design responds by laying in extra cable or with empty conduit. It may seem frugal to "pass-down" old computers as new ones are acquired. That may not be the case, however, when the costs of maintaining, training, and consulting for the older systems is considered, not to mention the opportunity costs for those with them. A high-level perspective that considers cost and benefit, even in a qualitative way, will make for a better information environment.
The architect depends upon standard components: One of the most powerful tools the architect has in creating buildings that are functional and affordable is the hierarchy of standards in the building industry. If the building is designed with standard window openings, less expensive windows can be specified as a way of preventing a cost overrun, without a major redesign effort. If a standard window breaks 20 years after construction, a replacement can be easily found. Architects can still be creative and innovative even with standard components. There are an infinite number of ways standard components can be arranged to satisfy user needs. Even in a highly customized building, the vast majority of it components are likely to be industry standard.
Today’s computer hardware and software is extraordinarily powerful and flexible. Most administrative functions can be satisfied with customized off-the-shelf systems—few institutions are building their administrative systems from scratch. Standard PCs, networks, and office suites will satisfy 80% of the needs of 80% of the academic users, even though ultimately each has unique information needs.10 A key to making this work is determining who and what are the 80%, and in creating a design that accommodates the nonstandard needs, and does not disenfranchise the totally unique users. An architect can use their understanding of user needs and technology to determine what constitutes the 80% and guide its implementation.
Documentation and process: From inception to acceptance, various forms of documentation are used to develop the design and to facilitate communication between user and designer, and designer and builder. Program development for a complex building can generate notebooks full of user requirements. Sketches and models help give abstractions concrete form. Blueprints and a specifications book provide the critical communication between designer and builder. Change-orders control modifications, and a punch-list makes sure the contractor’s work is complete. Most completions require the contractor to provide an "as-built" set of blueprints to document the changes from the original intent.
Documentation is difficult to generate even for simple software programs, much less the infinitely more complex information environment. Lack of information, however, can deny service as effectively as poor design or bad components. Personal and institutional memory must be replaced by more formal methods of collecting, retaining, and promulgating information.
Responsibility for design: The architect does not use the building, nor do they build it. But they are responsible for seeing that it is usable, that it can be built, and that it is built on time and within budget. They do not define the user’s needs, but are responsible for making them specific and visible. They do not create paint or doors or air conditioners, but must apply them so that they work, and work together. They do not have the knowledge and skills of the mechanical engineer, the bricklayer, or the interior decorator, but must create a design that can be implemented within those bounds. They must know enough about finance, building codes, union regulations, contract law, and other related areas to make sure that they do not impede the development of the building.
A few universities have architecture groups, but they generally are limited to standards definition and development. The culture of higher education is unlikely to tolerate an Information Architect with the responsibility and authority enjoyed by the building architect. There are a number of ways, however, that an institution might structure the architectural function. Most people will gravitate to a good design if it is presented to them. A high-level staff person (or group) could create the design as long as they have complete access to information in the line units. Non-coercive incentives, such as subsidies for those who follow the design, will speed acceptance. A "recommended" design that is followed by 75% is better than an "official" design that is ignored by 90%. Finding the proper level of responsibility and authority for the architecture function is probably the most critical success factor for higher education.
There are no silver bullets for the problems in information technology, and architecture is no exception. When combined with other technology design techniques, however, it provides a very powerful tool for creating functional and supportable information environments. It provides the context and high level perspective needed for detailed systems analysis methodologies to apply to enterprise-level problems. It helps couple strategic technology planning to intermediate planning, and ultimately to the implementation of real products and services.
Designing for change: A building architect does not start with bricks, beams and 2x4s, or with offices, kitchens and courtyards. They start with intermediate concepts such as form, flow and function. Information architecture should start, not with data entities such as computers, networks and file systems, or with knowledge abstractions such as history, psychology, and culture. It should start with intermediate information entities such as written correspondence, classroom presentation and talking heads. Information entities change much more slowly than data entities—a letter composed on a 400MHz Pentium is little different from one created on a 286. In a well-designed building a window can be replaced by one with lower heat loss without having to rebuild the wall. In a well-designed information environment a computer can be replaced with a new model without imposing upon the user an unfamiliar look and feel or forcing them to reenter all their data. Basic concepts used by the building architect such hierarchy, modularity, and standards, are not unknown in information technology.11 Without an architect to champion their use, however, they are easily sidetracked in favor of local optimizations.
An important characteristic of change in information technology that is difficult to see without a high-level perspective is that the whole world does not change at once. However compelled we might be to get on Internet II, it will be of little practical use to the campus until we upgrade other technology entities such as local area networks, servers, and desktops. Even if we quickly upgrade the technology, it takes considerable time for the new functionality to be assimilated into the work of more than a few of the faculty. Keep in mind that the World Wide Web, a technology whose introduction appears explosive, was conceived 10 years ago, and was available commercially by 1992. An architectural perspective helps balance the time-course of implementation so that we do not end up with components that are obsolete before they are used, or users unable to do their work because a critical component is not yet available.
Ideally, everyone in the institutions maintains a constant awareness of how there area is changing. In reality, the pressure to make things work forces most people to see only the here and the now. Change must be an integral part of information technology design, and the architect can be responsible for maintaining that perspective.
Designing for diversity: There are very few buildings in the world that are absolutely identical, yet most are composed of the same basic components. Building architects can create a custom environment with standard components, or at least with minimal expensive customizations. For any style of building; a residence, school, office, etc., the basic infrastructure; the foundation, floors, roof, plumbing, etc., is created from standard components using standard building practices. The skill of the architect is in knowing when customization is necessary to meet the user’s needs, and how it impacts their budget.
No institution can afford to customize every office and classroom, nor can it afford to customize every desktop and server. Technology has advanced to the point where it is entirely feasible to create a highly standard information infrastructure that, when combined with minimal customization, will meet the needs of the users. The key element in implementing this infrastructure is knowing where to draw the line between baseline and unique. The users would bias the line toward uniqueness, the administration toward infrastructure. These divergent interests are likely to preclude any design if there is not someone with the responsibility to create the best environment for the institution—an architect.
Many of the same architectural tools used to address change also address diversity. A hierarchical structure allows the user to build their unique environment on top of the infrastructure, rather than having to build a completely unique structure. A modular design allows them to change only the components that do not suit their needs. A good architecture enables the benefits of both standard infrastructure and customization.
Designing for connectivity: In the interconnected environment, the only thing that matters to the users is their end-to-end connectivity. They want the bibliographic record from the library to appear on their screen, and the do not want to spend mental energy on network protocols, router addresses, or file formats. Yet if any of the components between their desktop and the library database fail the user will not be served. A noisy connection in the wiring closet is enough to deprive them of the service. Our institutions provide support for each link in the chain, but typically have no one (other than the user) responsible for delivering the high-level information function (bibliographic access). When the function fails the user can regain the functionality by calling the help desk, which contacts the library, or the network group, or the department’s computer guru. This process eventually solves the problem, but is inefficient for both user and technologist.
The architect does not have to know the technical details of every component, but they must be able to identify weak components and bring them to the attention of the experts. They must be able to identify when the interaction of two components degrades the system, even though the component’s individual performances are within standards. Isolating complex systems into "black-boxes" and their connections requires skills very different from those required to understand the technical details of subsystems and individual components. It is the natural tendency of the managers of the local components--the desktops, LANs, WANs, databases, etc., to optimize the performance of that which they control. This usually requires different settings from those that optimize the whole system. A campus without an architectural perspective can have good technology delivering poor service to the users. The architect assures communication between the separate components.
Designing for complexity: The support dilemma of the complex, interconnected, ubiquitous environment is that you need both breadth and depth. In the current model of the information environment, the faculty provide most of the technological breadth while the IT organization provides depth. A few people are very well served by this model, but it inefficiencies are huge, and it does not scale well to the whole enterprise. The architectural approach provides a mechanism to probe detail to whatever level needed without loosing sight of the larger context. Its hierarchical documentation shows each player how they fit into the big picture, and provides them a mechanism to share their part of the design. Its mechanisms for adjusting the design during implementation provide a response to new ideas and problems while maintaining the integrity of the design, budget, and schedule. It offers a design methodology, but avoids excessive rigidity by building in interactive, human judgement with the right balance of responsibility and authority.
Each of these approaches shares responses that are well known in the IT profession—hierarchy, modularity, standards, etc. They are often used in local applications, as for the campus network or administrative systems, but seldom applied to the whole enterprise. We can no longer afford the chaotic and inefficient process of evolution for the development of our pervasive information environment. The architectural approach to design addresses the specific complications of information technology and provides the combination of rigor and flexibility needed for the academic culture.
Creating functional technology classrooms: Having proposed that classical building architecture can be used as a model for creating information systems, this first example demonstrates how building architecture has worked to our detriment. Not because it is flawed, but because it manifests our selection of the wrong problem to solve—we lost sight of the big picture. From the perspective of information architecture, a "high-tech classroom" is only secondarily a classroom, or high-tech. It is primarily a learning environment. Its design, however, is dominated by building architecture and technology--An elegant podium houses a state-of-the-art computer and controls that operate the lights, windows, and projection system.
The computer is different from that on most faculty desks, so they have trouble doing even simple things. The computer-based controls for the lights and windows offer unlimited flexibility, but take considerable more effort to learn than does flipping a switch or pulling a cord. The projection system is the best money can buy, but still lacks enough brightness and resolution to allow the students in the back third of the room to see a typical Windows screen. The podium hides all the unsightly cables, but it takes a technician half an hour to get to the monitor connection, to see if that is why the projector isn’t projecting. With all the complexity, it takes the instructor a quarter of their class period to determine that something really is broken and it is not just that they weren’t operating it correctly. And its not just that the $20,000 projection system provides lower quality images than the $300 slide projector. The instructor must learn all about scanning and compression and file formats just to get the image into electronic form, and then finds that there’s no place to store the 2MB files that each generates. And when they try to use the web for their 11:00 class, the network is so slow that it takes 4 minutes to load one page.
If we visualize the classroom as a component in the information environment, it is apparent that the core of the classroom is the information content used by the instructor. If the faculty cannot easily create or convert information for the classroom, its most expensive features will be little used.12 It also becomes apparent that the function of a classroom is significantly different from other technology facilities. If the classroom breaks, the progression of the entire course is jeopardized. If the classroom locks the instructor into limited interactions with the students and materials its net value may be perceived as negative, even though it may do most things very well.
These problems are due more to the way we apply technology, rather than its inherent limitations. There are always barriers, but when they are exposed they must be eliminated, not ignored. The fact that a limitation is not in an area that is the responsibility of the IT organization does not make it any the less fatal to a system in which IT may be heavily invested. "We built it and they did not come" may be an adequate excuse for the IT organization, but not for the institution. A high-tech classroom that is created as part of an information architecture will be much more likely to repay its investment costs.
Extending the useful life of systems: An architectural perspective helps us see that the problems of rapid change are not as bad as they first appear, and that they are not unmanageable. If we look at the whole information environment, it is apparent that information changes more slowly than technology, and our institutions even slower. 99.99% of information is still contained in books; letters and memos are pretty much the same even though electrons replace ink; and the "explosion" of the World Wide Web has really taken 10 years.13
Rather than basing our information environment on "What technology should everyone have?" we should be asking, "What information functionality should everyone have?" The latter question leads us to the 80-80 solution which in turn suggests a technical solution of an office suite, an e-mail package, a web browser, and whatever hardware and operating system it takes to run those applications at a reasonable level of performance. At this time (late 1998) the web browser is the technically limiting application for most users. Anyone with a system beyond a 386 or memory-limited 486 can participate in the web. They may desire more capacity (speed, disk space, screen size, etc.), but are not disenfranchised from this important part of the information environment by five-year old technology. An architectural perspective helps balance the design so that the user has neither too much, nor too little, technology to meet their needs.
Any institution that does not look to the future is likely to be blind-sided by it. The first step in managing the future is to make good guesses about its progression. The technical specialists in our institutions have a reasonably good understanding of their area of specialty (networking, desktops, operating systems, word processing, etc.), but typically no one has the responsibility to integrate these views into a holistic vision of the future. If someone is looking at the institution’s networks, servers, applications software, and user needs, there are less likely to be bandwidth and disk capacity crunches when everyone starts putting images on their web page. Any single technical group, or even the IT organization itself, will find it difficult to not bias their view with their expertise. An independent architect is more likely to provide accurate, unbiased estimates of the campus future.
Making standards work: Standards, of both components and processes, are vitally important to the economical development of functional buildings. The architect’s job would be considerably more difficult if they had to completely design each and every part of the environment. Conversely, an architectural perspective will greatly facilitate the development of standards. Because the information environment of each faculty member has to be uniquely suited to the discipline and style of their work, it is easy to justify an infinite level of customization. No institution, however, can afford the unlimited effort this requires. It takes an institutional perspective to see the institutional benefits of standardization, and an accurate understanding of faculty needs to see the individual benefits.
Standards as they have typically been implemented in the past have promoted the interests of the administration and IT organization, with most of the constraints placed on the individual. The building architect serves both the client and the contractor by focusing on the building--designing it so that it best meets the needs of the client, and can be constructed with the skills and resources available to the contractor. The information architect, by focusing on information, can design a standard infrastructure that offers efficiency for the institution and provides the individual a reliable foundation upon which they can add their own customizations.
A WWW search for information architectural efforts in higher education produces very sparse results.14 Many of the pages are several years old, and have not been updated since the initial effort. There are several reasons why these efforts might have failed.
These failures of the past should not be allowed to dictate the development of the future. As developed in the Crisis paper, the old model of support is broken and we must come up with a new approach. Every institution needs to develop a process other than evolution for shaping its information environment. Ideas borrowed from building architects can be used in a design and implementation process that directly addresses many of the failings of the old methods. When combined with existing technology planning/design techniques they result in a very powerful tool for fully exploiting the potential in today’s information technology.
2 Architecture n.
1. the profession of designing buildings, open areas, communities,
and other artificial constructions and environments. …
2. the character or style of buildings. …
3. the action or process of building; construction.
4. the result or product of architectural work, as a building.
5. buildings collectively.
6. the structure of anything. …
Random House Unabridged Dictionary,
Second Edition Random House, Inc., 1993
5 "If each part of the task
must be separately coordinated with each other
part, the effort increases as n(n-1)/2. Three workers requires
three times
as much pairwise intercommunication as two; four require six times
as
much as two."
Brooks, Page 18
10 Smith, Making Standards Work
11 "The ways of designing
a system for such changes are well known
and widely discussed in the literature-perhaps more widely discussed
than practiced. They include careful modularization, extensive
subroutining,
precise and complete definition of intermodule interfaces, and
complete
documentation of these. Less obviously one wants standard calling
sequences
and table-driven techniques used wherever possible."
Brooks, page 117
12 An example of converting
images is explored in detail in an
appendix in Smith, Making Standards Work
14 See URL list at end of bibliography
Berghel, Hal
Who Won the Mosaic War?
Communications of the ACM, Vol 14, No 10, October 1998
Brooks, Frederick P.
The Mythical Man-Month
Addison-Wesley, 1982 (reprint with corrections version, original
1975)
McClure, P. A., T. D. Sitko and J. W. Smith
The Crisis in Information Technology Support: Has Our Current
Model Reached Its Limit?
CAUSE Professional Paper #16, 1997
http://www.educause.edu/ir/library/html/pub3016/16index.html
Microsoft
Microsoft Windows97 Resource Kit
Microsoft Press, 1998
Orr, Frank
Professional Practice in Architecture
Van Nostrand Reinhold, 1982
Person, Ron and Karen Rose
Special Edition Using Microsoft Word 97
Que Corporation, 1997
Smith, John W.
Making Standards Work: A "Whole-Product" Approach
ACM SIGUCCS User Services Conference XXV, October, 1997
http://www.people.virginia.edu/~jws3g/Publications/MakingStandardsWork.htm
Smith, John W.
A "Whole-Product" Approach to Standards
CAUSE97, December, 1997
http://www.educause.edu/ir/library/html/cnc9763/cnc9763.html
Snyder, James C. and Anthony J. Catanese, Editors
Introduction to Architecture
McGraw-Hill, New York, 1979
(Links verified 981110)
Arizona State University; Arizona State University Rational
Information Technology Environment. Full text can be retrieved
from:
http://www.asu.edu/it/fyi/start/asurite/
Armann, et al, Developing a Distributed Computing Architecture
at
Arizona State University, CAUSE/EFFECT, V 17, N 2, Summer
1994.
Full text can be retrieved from:
http://www.educause.edu/pub/ce/cem94/cem942.html
Network Applications Consortium; Business Services Architecture:
The Integration of Software Components and Common Services Infrastructure
Http://www.wisc.edu/arch/task_force/corba_com/nac_final.html
Stanford University; Architecture, Planning, and Standards
http://www-leland.stanford.edu/group/APS/index.html
State of Connecticut; Strategic Plan for Information Technologies;
SECTION 3: Information Technology Architecture
http://www.aces.k12.ct.us/www/opm/ctsp94.html
University of Arizona; Information Architecture Project
http://w3.arizona.edu/~sis2000/info_architecture/info_arch.html
University of California, Berkeley; Information Technology
Architecture Task Force
http://socrates.berkeley.edu:4259/
University of California, Davis; UC Davis Distributed Computing
Architecture
http://dcas.ucdavis.edu/DCEWG2.html
University of Michigan; An Information Technology (IT) Architecture
for ITD
http://www-personal.umich.edu/~gpirkola/IT_arch_doc/Phase1Doc.html
University of Pennsylvania; Information Technology Architecture
and Standards
http://www.upenn.edu/computing/arch/
University of Wisconsin, Madison; Information Technology Architecture
http://www.wisc.edu/arch/index.html