High and Low Roads to GIS Development Bijan Azad Cadastre Operations Modernization and Automation Project Ministry of Finance/World Bank 3rd Floor, Riad El-Solh Square Beirut, Lebanon | Abstract Of The Paper & The Profile of The Speaker | Speaker Index | Paper Title Index | INTRODUCTION In their current form, the information systems (IS) and their geographic counterparts (GIS) of most large organizations will never meet the demands of the present day efficiency and flexibility. As David Osborne and Ted Gaebler (1992) described so clearly in Re-Inventing Government, many large public sector organizations are just "too slow and too maladaptive for today's high-speed business world." The responsive organization must be much more dynamic and adaptive than in the past and, for this purpose, will need the most flexible ISs/GISs it can find. But where are such systems? IS/GIS has been anything but flexible in the past. In organizations I have studied, IS/GIS efforts generally automate the status quo, freezing the organization into patterns of behavior and operations that resolutely resist change. As The Business Week (1996) put it, "Today, executives have discovered an even more disconcerting problem: markets and electoral environments change, but computer systems do not" (p. 36). Traditional systems do not bend; they will not change, and they cannot adapt. The challenge for organization is to break the rules of the past and structure IS/GIS to meet a variety of changing information requirements, some of which cannot even be known before the systems are built. The change must come through a revamped IS/GIS architecture &endash; that is, the set of policies and rules that govern an organization's actual and planned arrangements of computers, data, human resources, communication facilities, software, and management responsibilities. Information architecture has replaced organizational design, planning systems, and financial controls as the key to responsive organization. Architecture specifies how and why the pieces fit together as they do, where they go, when they are needed, and why and how changes will be implemented. IS/GIS architecture presents many difficult choices: What data and applications must be agency-wide, and what should be managed locally? What standards should be adopted or what vendors chosen? What rules should govern the decisions? What policies should guide the process? ROADS TO FLEXIBILITY AND EFFICIENCY The two criteria of greatest importance in choosing IS/GIS architecture are overall and simultaneous efficiency and flexibility. The former concern is of long standing and one that will always be with us. The latter challenge is emerging as the critical architectural issue for large organizations in the coming years. A single, monolithic application system will not allow future organizations to be responsive to customers for long. The key will be to build IS/GIS architectures that provide the foundation for rapid response to changing external (be they market or electoral) conditions through a host of relatively targeted government services (Osborne and Gaebler, 1992). Which architecture will best achieve the twin goals of efficiency and flexibility? Two solutions have emerged that, at their extremes, are quite different. I call them in this article the "low road" and the "high road." Each has its group of supporters, and many examples can be found of large organizations adopting one or the other approach. Each has its persuasive rationale, concrete advantages, and distinct weaknesses. Each also has a fatal flaw. Although these two strategies are discussed in their extremes, many organizations clearly pursue elements of both. I have found, however, that the combination usually results from a reactive stance to operating problems rather than a carefully thought out analysis of what road should be taken. Therefore, this article will hopefully provide here some insights I have learned about the choice. Several of the following sections outline basic elements of "pure" high roads and low roads. The purpose is to clarify the elements conceptually appropriate elements of each, rather than back into elements of both with no plan in mind. Most of the examples in this paper are based on my past consulting experience which has been in the state and metropolitan transportation arena. THE LOW ROAD In this scenario, IS/GIS technology and its management are dispersed widely throughout the organization. Data, computers, networks, applications, programming, and all the supporting resources are pushed as far down in the organization as possible. The structure is not just a one-step decentralization beyond the corporate IS/GIS organization. IS/GIS becomes the responsibility of every operating manager from divisions down. To make its all-out decentralization work, the low road approach ties critical units together with inter-linked communications, a philosophy of full access to information, and data-exchange conventions. Inter-linked communications The concept of "internal EDI" is used to ensure data exchange and integration. Just as external Electronic Data Interchange is on its way to becoming a means of linking organizations within a governmental unit or across several departments for high-speed exchange of data. Intra-organization or internal EDI uses the concepts of telecommunications, networks, standardized data definitions, and common format standards to promote the same within the organization. When they have agreed to a common set of standards and definitions for information exchange and have built a corporate network that links and bridges the dispersed workstations and databases, the divisions and functional areas can exchange all types of information. Massachusetts Turnpike Authority (MTA) serves as a useful example. MTA key goals are customer satisfaction and survival &endash; former means providing better highway services and the latter means resisting the Republican onslaught for privatization in the state. Decentralization of organization and IS/GIS have been prime strategies of MTA in achieving the above twin goals. A result of MTA's IS/GIS strategic plan showed a need to integrate maintenance and planning with design and construction. By giving the appropriate staff information at their desks, they would be able to reduce the cycle time for a project by 16 to 22 weeks. Therefore, MTA decided to relegate much of IS/GIS management responsibilities to various functional areas and tie them together through internal EDI in the long-run. In the short-run local area networks (LAN) and Wide Area Networks (WAN) for file and data sharing has been implemented. MTA hopes to take advantage of an architecture that provides local solutions in a manner consistent with agency-wide strategic objectives. Full access to information The policy of full access to information is one that seeks to open, rather than restrict, access to data throughout the organization. The philosophy recognizes the need for data sharing by permitting teams, task forces, and other units to gather information quickly. It is a concept based on trust; it acknowledges that ad hoc groups and special teams are the norm, not the exception. It does not mean that any individual in the organization may rummage through the corporate data collections on a whim, but it does mean that the "owners" of various data collections are expected to provide data access and interpretation to an array of teams and task forces. At the Massachusetts Transportation Building &endash; which houses Massachusetts Bureau of Transportation Planning and Development (BTPD), Massachusetts Turnpike Authority (MTA), Massachusetts Port Authority (MPA), Massachusetts Highway Department (MHD), and Massachusetts Executive Office of Transportation and Construction (EOTC), and Central Transportation Planning Staff (CTPS) &endash; more than 4,500 employees are tied into the state's transportation information repository. The network is one of the first of its kind in the state. Similarly, Massachusetts Executive Office of Environmental Affairs (EOEA) is setting out to build a system that will provide distributed, dispersed IS/GIS capabilities to departments and functions agency-wide and will give everyone in the state environmental arena a workstation from which they can access any resource outside or inside the organization. Both umbrella organizations, previously characterized by distinct silos of information, are moving toward a policy of "full information access" through a low-road approach to putting information at the fingertips of employees. The philosophy of full access presents an interesting challenge to the various organizational units compiling information. They must ensure the protection of valuable and sensitive data while at the same time assuring full access to routine data seekers. Many organizations today following dispersed, low-road approaches continue to debate which managers get access to what information: Should the CAO (Chief Administrative Officer) be able to tap into the local information sources of lower-level operating managers? Should lower-level operating managers have access to agency-wide information, including information that was previously under the control of managers from other functional areas? Data exchange conventions In the low-road scenario, the role of any central IS/GIS organization is to ensure the integrity of the internal data definitions and networking standards and to provide full access. Indeed, aside from a process for establishing a minimal set of data definitions and a means for data exchange, there may be no centrally controlled IS/GIS organization at all. Organizations often use a centralized telecommunications function, but even this is not necessary. Some large state agencies have adopted a low-road approach to telecommunications management by decentralizing responsibility for networks to their operating units. The only necessary central role is standard setting. The role of standards in the low-road scenario is an important but limited one. Standards ensure the integrity of the internal data-exchange process. Beyond that, guidelines or other limitations play no vital role in the IS/GIS activities of the operating units. In the classic low-road approach, a business unit pursues its IS/GIS destiny linked to the corporate parent only by imposed or agreed standards for data exchange and inter-operability of networks. Of course, one might find substantial cooperation in IS/GIS affairs among workgroup in software development, spatial database development, training, and other activities, but the cooperation is not imposed on the units by any central group. The low-road philosophy views most corporate technology standards as impediments to progress. Imposed standards for programming languages, database management, development methodologies, even computer hardware, are considered unnecessary and constraining. Such standards only mean "old, outdated, and ill-suited to our purposes" to low-road enthusiasts. They demand to use the latest in technology, the best of the new development tools, and the most appropriate software for their particular application. In making a decision on what standards to impose, EOTC and EOEA have recognized and dealt with the complex issues surrounding when and how to impose standards: under a low-road approach to help ensure that existing and future corporate goals and objectives were not hindered while, at the same time, individual, workgroups aggressively pursued IS/GIS strategies that were consistent with each of their own vested interests. Both EOTC and EOEA for example, decided that standards for information and data exchange were vital but that technological and application-oriented standards could not be set in a true "low road" approach. Illustration of the low road I recently observed a classic low-road approach taken by Delaware Department of Transportation (DelDOT). Over 50 highway projects must be brought from the drawing board to operational status for customers who are demanding increased service levels of the roads less intrusion in their driving habits. In the late 1980s, IS/GIS was centrally managed and located and concentrated on back-office applications. IS/GIS was providing only monthly information relevant for historical purposes. The then management team, had promptly acquired all new technology &emdash; LAN-based PCs &emdash; and located it throughout the organization. Systems were quickly developed to solve pressing operational problems throughout the organization. New application software was acquired but viewed as disposable as changing needs emerged &emdash; a pavement management system based on a totally proprietary linear referencing system was one example costing more than $100,000. The emphasis was placed on solving today's demands based on low-cost to the workgroup. The result: a major corporate turnaround. Ideas proposed to the organization for consistent data architectures and communications standards were summarily dismissed as interfering with the new focus on finding fast solutions using dispersed technology and management. New systems were constantly being developed and old systems thrown out. Management believed that new investments on technology aimed at important, short-term solutions is well worth the price and accepts long-term problems that might arise from a lack of integration and consistency. The organization was poised to continue being a leader in finding innovative solutions in an arena that will face tighter funding and more severe cutbacks in the future. The low road solution appeared to be the correct one for this organization in need of rapid and drastic change to its total operations. Low-road pros and cons Overall, I have found that the low-road approach is considered: A Natural Solution. The dispersed-network &emdash; Client/Server &emdash; structure for IS/GIS is a natural fit with many dispersed organizational structures. It capitalizes fully on the benefits of decentralized responsibility and control. Fast. Dispersed and networked Client/Server IS/GIS is the key to speedy implementation of new systems and rapid deployment of technology. Centralized solutions take longer and often do not meet all the local needs. Innovative. The low road leads to innovative uses of current technology and the adoption of newly emerging technology. New software, computers, and design and development methods can be adopted as soon as they hit the market. Low-road managers need not wait for committees, councils, standards bodies, advisory groups, impact studies from other divisions, or similar bureaucratic processes. Effective. Locally developed systems best meet local needs. In the low-road approach, technical solutions for local needs can be adopted without regard for the needs of other divisions or business groups. If UNIX or NT, on a Pentium or a RISC workstation, with a particular software package best meets that unit's needs, then it can be chosen. End of issue! Efficient. The argument is frequently made that the low road will eventually become the overall low-cost scenario for IS/GIS. A networked Client/Server IS/GIS structure capitalizes on the "new economics" of computing through PCs, workstations, LANs, and low-cost software. Strategic. When faced with external challenges or opportunities, managers tend to use whatever resources are at their disposal. If IS/GIS is part of their tool kit, it will get used along with the people, money, time, and other resources of the organizational unit. If IS/GIS is not a resource the manager can command, then it simply will not be used to the degree and with the same intensity as it would otherwise. Substantial evidence indicates that most strategic systems and so-called responsive applications are not the creations of ClOs (Chief Information Officers) or IS/GIS managers but are the brainchild of operating managers. Pushing technology control and responsibility far down in the organization is much more apt to stimulate creative business-related applications than is vesting its future in a supposedly all-seeing, all-knowing CIO. On the other hand, dispersed, localized IS/GIS united only by a common internal EDI creates some problems. The biggest lie in the areas of: Efficiency. Despite its proponents' arguments, organizations that have adopted the low road strongly suspect that dispersed technology management is more costly than centralization, but the dispersed costs are less visible than centralized costs &endash; e.g., DelDOT's pavement management system ended up costing $500,000 after adding the requirements to make it truly multi-user and multi-site &endash; a twist on the "new economics". The low road cannot help being a costly solution to IS/GIS structure in the long run. It leads to accumulation of more technology with lower utilization rates, more duplication, more people, more package purchases, more of everything than a centralized approach. Integration. The efforts necessary to link separate workgroups' IS/GIS activities with each other are complex, no matter how effective the organization's internal networks and data-exchange mechanisms. The United States has many large organizations, and governmental units that that have struggled with severe computing and communications problems as they have tried to adopt client/server, and other restructurings of IS/GIS operations. State of Florida is perhaps the most prominent example of an effort in which dispersed IS/GIS and ineffective internal standards became serious impediments to data sharing in the mid 1980s. The creation of the governor's Information Resource Commission to oversee all expenditures of IS/GIS was a response to this trend. Today, many organizations are faced with similar problems as they attempt to participate in government-wide data sharing projects. They may suddenly discover that they cannot combine their own land ownership, tax, and mapping data across the organization because of the myriad local, independent data structures fostered by the low-road scenario. Integrity. Another casualty of dispersed IS/GIS is data integrity. Even under the best circumstances, standardizing and maintaining data or information standards are difficult. Words just do not mean the same thing from one unit to another, and the differences tend to increase over time in large organizations. It is a bad situation when units of the same organization cannot exchange data without a lot of manual intervention because of missing data standards. It is an even worse situation when units exchange and use data they think have commonly accepted meanings but do not. Data Exchange. Only with a Herculean effort can a large organization actually achieve and maintain an effective internal data exchange system. Change itself is an enemy here. Many large organizations decentralized a good portion of their IS/GIS in the late 1980s or found it becoming dispersed because of rapid metropolitan growth and organizational restructurings, well before they had a standard set of data definitions. Internal EDI was usually an afterthought. Rarely does a large multi-department or multi-division government organization enjoy a set of core data definitions &endash; one and only one linear referencing system for the road system throughout the agency, for example, or one road-segment ID, one coding scheme for addresses, even one common property ID system for all Right-of-Way acquisitions. Uneven Efforts. Another drawback to the low road scenario is that it leads to uneven levels of accomplishment throughout the organization and, in time, uneven levels of effort within a single unit. Some business segments will inevitably fall way behind in the deployment of IS/GIS. Short-Run Focus. The planning horizons of operating managers are frequently much shorter than what executive officers, board members, and informed bureau chiefs would like. IS/GIS projects can have the longest lead times of any projects in an operating unit. It is sad but true that, in many state Departments of Transportation today, a new road segment can be built and or an existing one re-surfaced faster than the IS/GIS group can build the systems to support the project. IS/GIS projects, often do not get the attention they should from local operating managers, who are under pressure to achieve immediate results. The low road fatal flaw The biggest drawback to the low road, and its real risk, is simply that it may not work! Five or 10 years from now, organizations that enthusiastically adopt this direction may discover to their horror that the structure cannot cope with change, that unforeseen circumstances are overwhelming its ability to adapt. The organization may try to absorb growth, restructure its units and awake to a mess of incompatible technologies, systems, procedures, and data that simply will not support the new business requirements. The organization will find itself flailing away with incompatible systems and an inability to install the information management to support strategic and organizational changes. Many of the large, low-road government organizations operating in the U.S. state and local government now face just such a predicament. DelDOT, for example, had low-road systems in each division and diverse technology implemented in a half a dozen different languages and reflecting the enormous variety of operating units' independence. Now comes 2000! DelDOT would like to adjust operations to a state-wide "metric" scale to qualify for full federal highway funding but it finds dispersed IS/GIS blocking the way. DelDOT is now engaged in a major effort to build "common" application systems for all of its highway-based operations &endash; a decidedly "high-road" turn. THE "HIGH ROAD" Along the high road, many of the properties featured in the low-road solution are reversed: the role of the senior IS/GIS executive is expanded. The core IS/GIS activities of the organization are centralized. Investments in IS/GIS infrastructure are built around the central precepts of corporatewide networks, central data collections, common business practices, common application systems, and standardized hardware, operating systems, and databases. Core applications are designed to be organizationally independent &endash; that is, immune to the restructurings that so often plague the IS/GIS activities of low-road organizations, where applications are "owned" by user divisions and departments. The most eloquent supporter of this approach is James Martin (1989) who by many is regarded as the father of Information Engineering or the high road. Pennsylvania Department of Transportation (PennDOT) has a classic high-road approach. Although having over 32 major organizational units, PennDOT manages its information systems through one technical and one organizational architecture. The technical architecture is built around central hardware, databases, and applications. The organizational architecture is built around an IS organization that is itself one of those 32 units within the organization. PennDOT uses this high-road approach to obtain low-cost solutions from the information technology industry (primarily IBM) and also to expand its basic transportation services in the face of a variety of new federal requirements, including ISTEA (Intermodal Surface Transportation Efficiency Act) and Clean Air Act Amendments. Many of the organizations I have observed taking the high road face these two key challenges ( efficiency and responsiveness to strategic challenges. Florida Department of Transportation (FDOT) invested in its own state-wide information architecture for the functional areas and district offices and has built a state-wide Business Information Systems Plan (BISP) for handling all transactions that is unmatched in scope. The FDOT target has been to use its own hardware, software, communications links, people, and systems to handle end-to-end transactions in a seamless fashion for 9,000 users state-wide. The FDOT built this high road information engineering solution in response to perceptions of waste and duplication that were prevalent concerning the IS/GIS expenditures before. The expenditures of $5,000,000 on the efforts have been estimated so far. The results are promising. However, the degree with which the system is "seamless" is open to interpretation. Kansas Department of Transportation (KDOT), decided to follow the high road when it introduced one of the largest single integrated GIS/CAD (Computer-Aided Design) system anywhere. KDOT is attempting to build a "Integrated Design Environment (IDE)" with which it can "put down pavement" faster and also respond to rapidly changing federal demand for new information and do so at low cost. KDOT is moving to reduce the "design-to-construction time" for new projects from 130 to 114 weeks! Although the KDOT system is not fully completed yet, the preliminary results look promising, and, when completed and successful, it will be an example of a high-road solution that is sure to be adopted by other state transportation agencies around the country. Pros and cons of the high road The key arguments for taking the high road are: Fast Change. Organizations that depend on IS/GIS cannot restructure themselves without a concurrent restructuring of their computing systems, communications, and decision processes. A great benefit of the high road is that it permits speedy system restructuring. Senior management can transform the organization by making a decision at the top. When senior managers address the classic change questions&emdash;where are my customers? how do I want to operate, what is the ideal structure for our organization &endash; the high road permits strategy, organizational design, and IS/GIS planning to be done concurrently. Integration. Carefully planned and managed data collections are the hallmark of today's high road. Easy-to-access data structures are made possible through the very large storage systems and advanced data-management software of the latest in large-scale computers. Large data stores can be managed effectively, and centralized, time-critical operations can be supported efficiently. Recent developments in software suggest continued improvement in storage capacities and speed can be expected. Efficiency. The high road is the most efficient structure for the long run &endash; one set of data, one set of core application systems, minimal redundancy, and fewer people needed for maintenance. Flexibility. Another key aspect of the high-road approach is flexibility, which is provided by relational data systems and organizationally independent application systems for common core business activities. The problem with the old data system technique was that it could not cope with unanticipated demands and did not accommodate new data elements. Relational systems overcome these problems. The same is true for common application systems: they are designed to support change because they are organizationally independent. Strategic Use. Successful use of IS/GIS to be organizational responsive is almost universally a story set on the high road. PennDOT, FDOT, KDOT &endash; all are centrally designed and managed (that is, high-road) communications-oriented efforts. The high road is the only approach that permits senior management to focus its time and attention efficiently on the IS/GIS structure of the organization. Unfortunately, the high road also has weaknesses: Expense. Perhaps, the greatest problem is "development risk." The history of computing in many large organizations is filled with expensive and painful failures, especially with attempts to build common systems and central data stores. Although FDOT and KDOT are two examples of agencies moving toward success with the high road, other agencies have faltered. For example, one state DOTs (New York State) decided to abort its high-road attempts. It had launched a project in an attempt to achieve a common agency-wide linear referencing system for mapping conceptually similar to GIS base map. The goal was to enhance the ability of the organization to manage information to achieve rapid response for design to maintenance cycle at low cost. NYSDOT attempted to build a monolithic GIS/CAD system that would provide long-term flexible advantages from a low-cost solution. The technical and managerial difficulties the organization faced were gigantic. Even when the high road is a success, it is expensive. FDOT and KDOT have invested heavily in their solutions. PennDOT may actually invest in more information technology than any other transportation agency in the country from mid 1980s to 1992 close to $90,000,000. KDOT crafted a close partnership with Intergraph in order to have access to resources KDOT lacked as it tried to resolve difficulties encountered on the high road. For organizations without access to such resources, arguments can be mounted that "the high road did not work when total system solutions were the watchword of the 1960s, and they will not work now." Customizing. The applications must usually be custom-built. Package solutions are not really feasible when one sets out to build a suite of organizationally independent applications. Not many packages are available, and not many new ones are under development. Few package options exist for large organizations and mainframe-sized/large server processors. For transportation management only one or two systems exist, and they all have limitations and constraints. Too often one hears, "I looked at packages, but none met our needs. I had to write our own." And many of "their own" did not work. Management Dependence. The successful high-road solution depends heavily on senior management's ability to plan both the enterprise of tomorrow and the data and systems to support it. Many state agencies admit that they have been slow to recognize the importance of integrated transportation information systems now demanded in ISTEA or Clean Air based on common file structures, cross functional cooperation, and integrated data reporting. If asked why they were so slow, they give reasons that all seem to come back to a management that did not see the need. They could not visualize the potential. Even when they had the vision, however, they often lacked the courage: many grand efforts at common systems in large state agencies foundered and were scaled back. Politics. The high road is fraught with political pitfalls because operating managers distrust central solutions, especially IS/GIS ones. Common application systems and shared data collections also frequently run counter to the culture, where large organizations place decision-making responsibility with the operating managers, who are on the firing line. Planning Techniques. Common system architectures built around central data collections place great stress on organization-wide planning methodologies, but advances in planning technologies have not kept pace with the size, complexity, or expectations of information systems. Unfortunately, as organizations grow the demands placed on the planning process grow geometrically. Planning approaches such as IBM's Business Systems Planning or Andersen Consulting's Method One, Texas Instruments IEF are simply too complex to apply to a large entity such as FDOT or PennDOT. The high-road fatal flaw Even if these problems can be overcome, the chief drawback to the high road is the same as for the low road: the likelihood that it will not work, that it will not adapt to the needs of a changing organization. The danger with the high-road strategy is that it will freeze the organization into a fixed structure, culture, decision-making process, and pattern of relationships both inside and outside the organization. There is no guarantee that common systems and centrally managed data structures built with the latest technological solutions or any of the other aspects of the high road will lead to what management demands &endash; flexibility and efficiency. Indeed, the evidence so far has been just the reverse: the larger the organization, the more comprehensive the systems, the wider the scope of the data, the richer the relationships with vendors and customers, the faster the rate of organizational change, then the greater the chances that the high-road solution will never be finished. Even if it is finished, moreover, it may never meet the changing expectations of the organization. SOME GUIDELINES FOR MANAGERS If the low road eventually leads to a maze of expensive, incompatible efforts that are impervious to system-wide change, and the high road either never gets built or will not adapt when it does, what scenario will work? How do I get the benefits of both roads while minimizing the drawbacks? How do I get the efficiency and control provided by the high-road solution simultaneously with the low road's ability to respond to rapidly changing information processing needs of operating managers throughout the organization? So far, the architectural or structural choices have been presented at the extremes: the low-road, distributed client/server, where no central systems are used, where integration and connectivity are provided only by internal EDI, where no CIO or sometimes no central administration exist. The high road was virtually silent as to local computing, local data collections, and local initiatives. Clearly, however, some system tasks are global to the organization and require high-road solutions, but many tasks are not global and are best dispersed through low-road solutions. Organizations must do both. Deciding what to manage from a high road and what to disperse to the low road is really the key question. Organizations face certain constraints on what can be approached via a low road. By their nature, some data are common and cannot be decentralized with current technology; nor should they be. Some part of the IS/GIS task of almost every large organization should be accomplished with high-road solutions. This high-road structure must encompass two parts of the organization's IS/GIS architectural requirements: the central office segment and the IS/GIS activities that pervade the rest of the organization. The current IS/GIS strategy at FDOT is a good example of a large, diverse organization that has taken elements of both the high and low roads after much management attention to the formulation of internal IS/GIS architecture. The organization is an innovator and is organized with considerable decentralized responsibility throughout its 8 district offices. Following a low-road philosophy, IS/GIS is decentralized and IS/GIS management is considered a critical part of every manager's responsibility. Yet the organization has concluded that high-road needs exist for agency-wide data and common systems in five key areas: Work Order Management Procurement Right-of-Way Management Pavement Management Safety Management Through internal data standards, these five high-road systems are tied to the corresponding applications for information access. KDOT is another example of a large organization that is combining an element of high-road philosophy in an otherwise low-road IS/GIS architecture. Prior to 1989, the organization had few central systems; most IS/GIS activities were organized along standard lines &endash; planning, design, construction, maintenance &endash; which were mostly autonomous. Maintenance and design systems were local, duplicative, costly, and implemented on a variety of different computers. Horizontal and vertical information flows were slow, complex, and costly, requiring many conversions and translations. In the late 1980s, KDOT made a decision to adopt a high-road solution for planning and design systems. The new structure entails: A common operating charter for the entire organization from facility design to maintenance; Common design and construction applications and databases for the survey, right-of-way acquisition, preliminary design and environmental monitoring; and A common management reporting structure of work orders. A key decision for any management is how many levels in the organization should have a distinct IS/GIS perspective? Some large organizations have chosen to focus their IS/GIS activities at a functional level. Some State DOTs organize their IS in one core and their GIS in another; others divide the IS/GIS activities along functional areas to do with planning, design, construction and maintenance. For many organizations, I believe that for all IS/GIS activities that are not such, high-road dimensions solutions should be dispersed to become low-road, local solutions. A crucial element to any successful low-road effort, however, is linking the organization horizontally and vertically with communications and data-exchange facilities &endash; that is, the internal EDI, the internal information network of the organization, is critical to the merging elements of the high and low roads. Unfortunately, the needs for internal EDI often become apparent only after a considerable investment in local technology or after changes bring new requirements that cannot be met. What is necessary is to establish a minimal set of standardized information that will stand up to unforeseen changes of the next 10 years. Beyond the components of the organization's IS/GIS structure that are naturally high road, managers should be convinced that an IS/GIS application meets three tests before concluding that it is to be a part of a high-road solution: synergy, feasibility, and fit. Synergy The default rule for writers, "when in doubt, leave it out," has a corollary in IS/GIS architecture: "when in doubt, let the operating units do their own." Managers must be convinced that pursuing the high road can add value; otherwise they had best stay with local, low-road solutions that can respond to local needs in rapid and flexible fashion. For large agencies, even the wisdom of a single (source) scale base map that can meet all needs across the functional areas is now becoming questionable in the wake of new leading edge technologies for "multi-scale map navigation tools". Feasibility High-road common systems, by their nature, are high-risk. Top level executives should be humble in their expectations for the success of common systems, especially those that cut across different functional areas. A state agency with 13,000 employees probably has no other choice than to standardize, and the differences from district office to district office are probably small enough that the risk in common the systems is minimal. The organization that sets out to build common applications for planning, design, construction and maintenance for multiple division lines across many functional areas is entertaining an entirely different degree of risk. Fit Besides the tests of synergy and feasibility, core IS/GIS activities must also pass the fit test. Fit has many dimensions. High-road solutions work best in stable environments, while low-road structures are best in volatile environments. High-road solutions are easier to construct and maintain when the intra-unit relationships are limited and straightforward. When intra-organization relationships are complex and fast changing, low-road IS/GIS systems will be more likely to cope than high-road centralizing. High-road solutions best fit organizations whose divisions are alike along most dimensions. When the services, processes, geographic areas, cultures, and decision processes are diverse, common systems just do not work well. FINAL COMMENTS All organizations are different, and there can be no solution that will be ideal for everyone, but there are general rules that everyone can follow. For many organizations, the architecture solution would recognize that requirements for efficiency and economy of scale can only be met by high-road solutions, but that flexibility and speed are best achieved along the low road. Combining both is the challenge faced by many organizations as we approach the turn of the century because customer service and responsiveness requirements increasingly call for not just efficiency and economy or speed and flexibility, but both simultaneously. Mastering the elements of the high and low roads by fitting each to the unique requirements of your organization and then tying it all together through careful development of architecture planning and special attention to internal EDI is required to manage these dual, and contradictory, mandated governmental challenges posed in the current era. REFERENCES: Business Week, 1996, "Information Processing", April 22, p. 22. Martin, James, 1989, Strategic Information Planning Methodologies, New York: Prentice-Hall. Osborne, David, and Gaebler, Ted, 1992, Re-Inventing Government, Reading, MA: Addison-Wesley. | Abstract Of The Paper & The Profile of The Speaker | Speaker Index | Paper Title Index | CGIS HOME PAGE CONTENTS