Our Age of Anxiety is, in great part, the result of trying to do today's jobs with yesterday's tools.

Marshal McLuhan

Over the past decade, state agencies and local governments throughout New York State have increasingly used information technology to support their work. During this period, dramatic increases have occurred in the use of computing and networks for government services and internal business operations. Since the mid 1990s, the Internet has exerted two powerful forces for change in government use of technology. First, the Internet offers government a new and flexible platform for information-based services. Second, through the World Wide Web, both agencies and the public were introduced to the possibilities for more responsive and customized services. Together, these effects generated what we have come to call "e-government."

While the early focus of e-government has been primarily on government-to-citizen (G2C) and government to business (G2B) services, government-to-government (G2G) initiatives are now gaining increased attention. The sharpening G2G focus represents a broad realization that improved services to citizens and businesses, more efficient operations, greater transparency, and all the other externally-focused goals of government must rest on internal operating policies and behind-the-scenes administrative functions that are well-designed, intelligent, and interoperable.

To achieve a high quality "back office" that supports very visible public service goals, government needs more than advanced technology. It also needs new strategies, thoroughly redesigned business processes, and creative incentives and mechanisms for interagency and intergovernmental collaboration and coordination. The project reported here explored this set of requirements through a Web-based Prototype involving state, county, and municipal governments.

This report is organized into four chapters plus appendices. This first chapter discusses the background of the project and the issue of G2G integration that it addressed. This chapter also offers a vision of an ideal G2G gateway and its benefits, as well as the barriers that stand in the way of its creation. The second chapter explains the design of the Gateway Prototype. Chapter 3 tells the story of the project itself, who participated, how the Prototype was developed, and how it was tested. Chapter 4 discusses the results of the evaluation and presents conclusions and recommendations for future G2G work. The Appendices include illustrations from the Prototype, lists of participants, and field test and evaluation information.

Today, state and local government use of information technology is manifested in many independent systems that each support only one business function or satisfy one particular program need. As a result, a large and growing number of individual systems for G2G business relationships are employed across state and local levels. This multiplicity of systems is often a significant impediment to efficient work, as well as a financial strain, because many applications require their own hardware, software, security, office space, and business rules.

In order to perform business functions on each system, local government officials must sign in and out as they use each one, requiring numerous log-ins and passwords. Usually, data entered into one system cannot be used in another. Numerous duplicate requests for information are made and fulfilled as individual organizations respond to uncoordinated requests and requirements. Moreover, many local offices keep duplicate paper or electronic copies of information they send to the State because these state-sponsored systems are seldom interoperable or designed with local information needs or business practices in mind. This situation poses a significant burden on the work processes of both state agencies and local governments and entails higher than necessary costs for everyone. If current practices continue, this picture of multiplicity and duplication will worsen as more individual business functions are automated.

Figure 1 illustrates only a fraction of the current array of NYS G2G relationships and interactions by representing a portion of the electronic information systems that connect state and local governments. The figure shows a small number of each kind of government organization and does not reflect any inter-local information systems connecting county and municipal governments. If we extend this picture to include all existing information systems among all state and local entities the picture would be far more complicated, with hundreds of connections involving state agencies, counties, towns, cities, and villages.

Figure 1. Simplified depiction of existing intergovernmental information systems

Efforts to streamline, simplify, and rationalize the picture of existing intergovernmental information systems in New York State are very desirable but they present their own complexities and challenges. Any transition to a more integrated and coordinated way of working adds new demands for planning, management, design, operations, and resource allocation. Figure 2 illustrates some of the elements that need attention. The horizontal axis of the figure represents increasing degrees of integration and notes key features of integration (common interface, single sign-on, integrated data, and integrated processes) necessary to achieve each higher level. As shown in the lower left, individual stand-alone systems represent the absence of integration.

The first true feature of integration is represented by a common Web interface that can be adopted for standard use by multiple stand-alone systems. Single sign-on, which requires identity management and role-based access, represents the next level of integration. It allows users to have secure access to some or all of the systems associated with their work by signing on once. When this feature is in place, users begin to experience the benefits of integration, but designers and system operators must accommodate higher levels of coordination and standardization.

Integrated data represents a significant increase in integration, whether that data is integrated across programs or units of a single organization or across multiple organizations. With this step, a wide variety of data management challenges must be addressed. These include agreement on data standards, quality control, stewardship mechanisms, and access and change rights.

Figure 2. Integration features, applications, and effects

The most advanced level of integration is represented by process integration, where organizations not only share and integrate their data, but revise their work processes to accommodate and capitalize on shared work processes and business practices.

The vertical axis of the figure represents increasing difficulty, complexity, and cost. As integration initiatives move from low-level efforts to co-located independent systems through a single Web interface, to single sign-on mechanisms, to creating integrated data repositories or applications that share data, to the very demanding applications that integrate both data and business processes, the cost, complexity, and difficulty rapidly increase.

The shaded boxes in Figure 2 place selected kinds of development efforts at the intersection of degree of integration and level of difficulty, complexity, and cost. The white boxes illustrate these types with applications from this project. For example, two of the individual applications in this project (Dog Licensing Application and Parcel Transfer Verification Check Application) were adaptations of existing non-Web applications. By revising them for the Web, the developers adopted a common Web interface. By contrast, the Contact Repository Application represented a new application that integrated data from multiple organizations into a single authoritative new source. This application was much more difficult and expensive to build. In the third example, the single sign-on feature of the Gateway Prototype allowed these different applications to be brought together in a single interface accessible with role-based identity mechanisms. This represents a middle-level of integration and resource investment. All of these examples are more fully discussed in Chapter 2.

Taken together, Figures 1 and 2 illustrate why New York State and local government officials sought to carefully explore and prototype the idea of a single point of contact for G2G work. The current situation is inefficient, complex, and expensive, but alternative approaches present some daunting challenges for which there is little practical experience. Thus, the idea of a prototype project was adopted as a useful way to understand the feasibility of moving from the current state to a more integrated future.

Working with a broadly representative project Advisory Committee, the project planners used their experiences and mutual desire for a better situation to envision an ideal fully functioning state-local gateway for government business in New York State. They conceptualized the gateway as a single secure place on the Internet which would channel all G2G work. They called the idea a "gateway" rather than a "portal" to avoid confusion with the common use of portals to offer services to the public.

The participants elaborated on their ideal by specifying a number of desirable characteristics.

Joint governance. The ideal gateway would be governed jointly by state and local organizations through a formal governing structure. This structure would include fair representation of state, county, and municipal stakeholders. It would also include open communication, and joint problem-solving and decision-making mechanisms.

Gateway design driven by genuine business needs. Each application would address information and management needs associated with a particular business function that is relevant to both state and local organizations. Each application would provide business value right from the start, even with less than full participation of all state and local agencies.

Affordability to all interested participants. The costs associated with adopting and using the gateway would not be prohibitive to any state agency, county, or municipality.

Financial solvency. The gateway would be designed to offset initial investments and ongoing costs through future cost reductions to all participants.

Protection from threats and misuse. The gateway would be protected from external threats and internal misuse by jointly established security features and policies. Access would be limited to authorized personnel assigned roles associated with specific functional requirements. Standard security measures would be in place to protect the infrastructure, transactions, and data.

High quality, accurate, and authentic data. Data sources and associated metadata used in the gateway would be assessed for "fitness for use" and authenticity. Data quality and usability would rely on designated data owners and clear processes for additions, corrections, and updates. Data cleansing and analysis tools and data management services would be available to users.

Modular, flexible, and versatile in design and content. Envisioned in its entirety, the gateway would be built in a gradual fashion, according to current needs and available resources, delivering both near- and long-term benefits. Its modular nature would not require immediate full participation of all state and local agencies for successful initial performance. The gateway would also follow an evolutionary development strategy where ongoing evaluation leads to continual improvement. Information and applications would use a standard set of conventions and continually be evaluated for usability and improvement under a variety of local conditions. New business-driven information resources and applications would be added regularly.

Accommodation of users with varying levels of skill. The gateway would be designed to accommodate users with low technical skills. It would be intuitive, transparent, and simple to use with a common vocabulary, and a single sign-on. Issues of accessibility would be addressed appropriately. The gateway would be accompanied by solid user support mechanisms and training programs.

Responsiveness to the needs of users. Applications would be designed from the user point of view. Online help would be readily available, as well as immediate real-time confirmation of processed transactions.

High reliability and availability to all state and local users. Appropriate connectivity would be available to all participants including adequate basic infrastructure from desktop equipment and software to network speed and bandwidth.

Capability to incorporate other existing efforts. To take advantage of existing investments, useful characteristics of existing projects and applications that address shared processes and business needs would be incorporated into the gateway.

The project planners also sought specific categories of benefits from an ideal gateway.

Efficiency. The ideal gateway would save time and money by reducing the manual workload and duplication of tasks, as well as achieving economies of scale. It would allow creative and efficient use of existing funds, systems, and infrastructure already in place at all levels of government. It would also promote quicker and more reliable and complete communication among all levels of government.

Improved coordination and consistency.Shared processes, common data definitions, and more logical programmatic connections would yield better coordination between the state and local levels, and more consistent program designs and internal operations thus leading to better quality services.

Data quality and access. Re-use of well-defined, consistent, complete, and accurate data would allow the same information to satisfy multiple demands and support greater data integration and utility for multiple users. Improved intergovernmental data management would reduce costs and promote wider responsibility for information stewardship across government.

The foregoing characteristics and potential benefits of an ideal gateway would not emerge without significant effort to overcome key barriers. The project planners described these barriers.

Cost. Concerns were expressed about the initial and ongoing costs of a gateway, as well as concerns about the distribution of costs across levels and units of government with different budget cycles, spending priorities, and revenue capacities.

Complexity. Multiple and conflicting state business rules and practices often prevent needed coordination among agencies and programs at both state and local levels. This problem is often tied to the fact that many programs are federally defined and funded so that rules and practices are not always within the state's authority to change. Furthermore, the diversity of local governments adds to the complexity. Local capabilities and practices are far from uniform from place to place because they are locally devised to accommodate community-level demographics, economies, infrastructures, and needs. Finally, any effort to create a common gateway must recognize the many legacy systems supporting established programs that cannot be replaced or significantly changed in the near future.

Politics. Political support for a state-local gateway will compete with many other governmental priorities and there will be difficulty maintaining political support across the election cycles of so many jurisdictions. Concerns about control and management of the overall effort stem from questions about who will have authority to do what. In addition, some agencies and local governments may resist opening their data to new uses or users.