eliminating legal and policy barriers to …€¦ · eliminating legal and policy barriers to...

ELIMINATING LEGAL AND POLICYBARRIERS TO INTEROPERABLE

GOVERNMENT SYSTEMS

Phase I: Policy Barriers

August 12, 1998

Written by

David LandsbergenGeorge Wolken

Electronic Commerce, Law, and Information Policy Strategies

A Program of the Ohio Supercomputer Center

ELIMINATING LEGAL AND POLICY BARRIERS TO INTEROPERABLEGOVERNMENT SYSTEMS

prepared for the

INTERGOVERNMENTAL ENTERPRISE PANELC/o Office of Information Resources Management

Department of Veterans AffairsWashington, District of Columbia

http://iep.fedworld.gov/

by

David LandsbergenGeorge Wolken

Ohio Supercomputer Center, ECLIPS program1224 Kinnear Road

Columbus Ohio 43212http://www.osc.edu/eclips/

August 12, 1998

This report was prepared for the ECLIPS program of the Ohio Supercomputer Center(OSC) with funding from the Intergovernmental Enterprise Panel (IEP). The views andopinions expressed by the authors are not necessarily those of ECLIPS, OSC and theIEP, The Ohio State University, or any other affiliated organization or institution.

i

TABLE OF CONTENTS

Table of Contents ................................................................................................... i

Preface ................................................................................................................... iii

Acknowledgements ................................................................................................ v

Executive Summary ............................................................................................... vi

I. Introduction ............................................................................................ 1

A. Why is Interoperability Now an Option? ............................................ 1B. Benefits of Interoperability ................................................................ 2C. What are the Barriers? ...................................................................... 3

1. Political ................................................................................... 32. Organizational ........................................................................ 33. Economic ............................................................................... 44. Technical ................................................................................ 4

II. MethodA. Statement of Problem ....................................................................... 5B. General Approach ............................................................................. 6

1. The Integration of Previous Research, Policy Documents, andInterviews ............................................................................... 6

2. Interoperability Policy Architecture ......................................... 6

C. Interview Protocol ............................................................................. 8D. Explanation of Case Studies Chosen ............................................... 9E. Explanation of States Chosen ........................................................... 10

III. Policy Analysis and FindingsA. Interoperability Means the Sharing of Information ............................. 11B. There is a Natural Evolution, or Learning Curve, in the

Development of Interoperable Systems ............................................ 14C. Sharing Information Means Planning for Both Its Collection and

Use .................................................................................................... 16D. There Is No Strong Federal/State Architecture In Place To Support

Interoperability .................................................................................. 17E. In a Technology-Driven Society, Technical Standards are

Another Kind of Public Law ............................................................... 20

ii

IV. Summary and Future Work ............................................................... 21

Appendix A: GILS: The Government Information Locator Service

I. Why GILS? .................................................................................................. A-1II. What is GILS? ............................................................................................. A-1III. Case Study Focus ....................................................................................... A-2IV. GILS Does Benefit Interoperability .............................................................. A-2V. Problems and Solutions to the Implementation of GILS .............................. A-3

Appendix B: Framework of Information System Acquisition Management andUtilization by USEPA

I. Background on EPA: Documentary Foundations ........................................ B-1II. Federal-State Cooperative Programs in Connection with

Environmental Information and Information Systems .................................. B-3III. One Stop Reports Available On-Line Among Five Selected States ............ B-5

Massachusetts ............................................................................................ B-5Washington ................................................................................................. B-6

IV. Overview of State Environmental Administrative Architecture ..................... B-6

Ohio ........................................................................................................... B-6Texas ........................................................................................................... B-7Washington ................................................................................................. B-7Kansas ........................................................................................................ B-8Massachusetts ............................................................................................ B-8

Appendix C: References

I. Selected Laws and Bibliography .................................................................. C-1

A. Books and Reports ........................................................................... C-1B. Newsletters, Articles, Web Sites, and Other Information .................. C-2C. Federal and State Statutes, Regulations, Circulars, and Executive

Orders ............................................................................................... C-6

1. OMB Circulars, Etc. ............................................................... C-72. Executive Orders ................................................................... C-83. State Laws and Regulations .................................................. C-8

II. Interview List ............................................................................................... C-9

Appendix D: About the Authors and ECLIPS .................................................... D-1

iii

PREFACE

This report defines interoperability as essentially a problem in sharinginformation. By understanding the full range of problems and opportunities associatedwith sharing information, our report goes far beyond the simple technical problems ofhardware and software compatibility to strike at the deep bureaucratic, societal andeconomic barriers to building interoperable government systems.

While this report considerably expands the definition of interoperability, there arecertain aspects of the interoperability problem that this report does not address. Everpresent in our interviews with Federal, state and local policymakers and practitionerswas the uncertainty and ambiguity surrounding privacy rights and how to protect them.Our study found that organizations were very concerned about privacy, but that fewdeveloped concrete solutions. To skirt tough issues, often organizations focused oninteroperability projects that had low political and privacy saliency.

As information systems continue to become more interconnected andinteroperable, and the opportunities for “networked solutions” grow, concerns about howprivacy rights are to be protected, both by the public and the private sectors, will need tobe addressed. The ECLIPS companion project “The Protection of Personal Informationin Intergovernmental Data-Sharing Programs: A Four-Part Report on InformationalPrivacy Issues in Intergovernmental Programs” (June 30, 1998)1 begins to address boththese issues and their attendant solutions.

Our report also does not focus on two other areas important to fullyunderstanding interoperability: 1) international law and practice, and 2) procurementpolicy and procedures. These areas lie outside of the expertise of the project team.

Finally, many of the problems identified in our interviews as being“interoperability problems” really stem from fundamental problems endemic to themanagement of information technology in the public sector:

1. inadequate resources to replace technologically obsolescent hardware andsoftware;

2. difficulty in attracting and retaining the best technical support skills;3. the particular mix of environmental constraints in the public sector which

make it uniquely difficult to plan and implement projects, such as:a. the various political, issue, and budgetary cycles that repeatedly

disrupt the long-run planning and implementation of projects;b. the high visibility of the public sector that make the management of

risk problematic;

1 http://iep.fedworld.gov/library/eclipse/cover.htm

iv

c. the unique scale and scope of many public sector informationsystem problems that make it difficult to find and adapt bestpractices from elsewhere; and

d. turf battles between agencies to secure resources and avoid costsand risks.

Our report does not address these problems since they are well understood anddiscussed elsewhere. Nevertheless, part of the promise of interoperability lies in itsunique position as being an answer to many of the generic problems mentioned above.Interoperability may alleviate the resource constraint by doing more with less.

v

ACKNOWLEDGEMENTS

The authors wish to express their appreciation to Jeffrey B. Ritter, Esq., for hiscontributions to this work. His vision in its creation and guidance in its performancehave enlightened both authors.

The authors also wish to thank the staff and administration of the OhioSupercomputer Center and ECLIPS for their support during this project. In particular,we would like to thank Cheryl Stevens for her administrative efforts in schedulingtelephone calls, insuring proper documentation and assisting the authors in ways toonumerous to mention. We also thank J. Pari Sabety for her support and assistance inhelping us in the final stages of completing this report and to Keith Harmon for helpingwith the editing and proofing of the document. Steve Gordon helped keep us on trackand focused on the deadlines. We also had excellent legal research support from ClayBenton. Jeff Wilhelm also pitched in with helping us organize and format our citations.

vi

EXECUTIVE SUMMARY

Many state and federal policy makers view interoperability strictly as a technicalinformation technology and procurement issue. However, our work shows thatsuccessful development of pervasive interoperability hinges on an understanding thatsystems, people and information needs must be viewed in a broader context. Thiscontext recognizes that fundamentally, interoperability is the effective sharing ofinformation. A richer definition of interoperability implies that the policy andmanagement architecture to support interoperability must move beyondhardware/software to the most profound barriers to interoperability. These barriers arethe soft “human technologies” implied in fundamental policy and organization design.

Interoperable systems, once implemented, hold the promise of improving theefficiency and effectiveness of government by reducing the “paperwork burden” on thecitizen, streamlining work processes, making more effective use of individual andshared information technologies, and enriching the formulation, implementation, andevaluation of policy.

The goal of this project is to develop a set of findings and recommendationscritical to eliminating barriers to interoperability at the federal, state and local levels.First, previous research relating to interoperability was reviewed. A list of potentialbarriers and solutions was then generated and used to review policy documents. Asthese policy documents were analyzed, an enlarged list of candidate barriers andsolutions were constructed. Then, working findings were tested on leading federal andstate policymakers. In many instances, these conversations generated still moreinsights. After approximately thirty-five interviews, several important central themesemerged from the work:2

(1) INTEROPERABILITY MEANS THE SHARING OF INFORMATION

Interviewees repeatedly identified hardware and software problems of sharingdata as modest when compared to such problems as identifying opportunities forsharing, aligning data definitions, including meta-data, and providing political andeconomic incentives for the sharing of information. Far too often, interoperability is stillthought of as strictly a technical problem or as a managerial or policy problem that canbe solved through more powerful hardware and software. This outdated paradigm alsounderlies the policy architecture in how interoperability is dealt with today in state andfederal agencies.

Before any kind of significant breakthrough can be achieved in improvinginteroperability, a significant paradigm shift must occur. By understanding 2 See interview list page C-9

vii

interoperability as the sharing of information, policy and management tools can bealigned to support the more effective sharing of information.

(2) THERE IS A NATURAL EVOLUTION, OR LEARNING CURVE, IN THE DEVELOPMENT OFINTEROPERABLE SYSTEMS

Working in the future networked, interoperable world will clearly mean new waysof doing things. However, the complex machinery of government takes time toincrementally reinvent itself.

Our study identified various degrees of interoperation among governmental units.For each degree of interoperation, there are a set of barriers and catalysts for action.Each of these possible catalysts and barriers has a different level of relevancedepending on the context of each local information-sharing problem.

(3) SHARING INFORMATION MEANS PLANNING FOR BOTH ITS COLLECTION AND USE

One of the principal contributions of information resource managementapproaches is the application of the “life cycle” model to the management ofinformation. The “life cycle” notion argues that critical decisions made early in thecollection of information will have consequences for how that information, for example,is archived.

Similarly, the effective sharing of information cannot be an afterthought once datais already collected. Once interoperability is understood to be the “sharing ofinformation,” the planning and management of information must include concernsrelated to effective data sharing early in the management of those informationresources.

(4) THERE IS NO STRONG FEDERAL/STATE ARCHITECTURE IN PLACE

A review of underlying federal and state legal and policy documents as well asthe interviews revealed significant progress in the development of federal informationtechnology and information policy. But more work is needed. Strong federal/statearchitecture must also include opportunities for the states to participate much earlier inthe information planning process. While the federal architecture is relatively welldeveloped, the information policy in some states needs to focus more explicitly oninformation sharing. Also, inconsistent federal data collection and reportingrequirements must be harmonized. Finally, ways must be found to counter theperception, and often the reality, that federal data requirements are another form ofunfunded mandates or unnecessary duplication.

viii

(5) IN A TECHNOLOGY-DRIVEN SOCIETY, TECHNICAL STANDARDS ARE ANOTHER KIND OFPUBLIC LAW

In information sharing, technical standards can function like law, because theydetermine, for the indefinite future, the kinds of activities that can be undertaken.However, unlike public law, many of the processes designed to create technicalstandards do not have adequate mechanisms for representation and appeal for otherlevels of government who must use those standards to develop interoperable systems.

The implication for federal government policymakers is that while there havebeen many notable breakthroughs in clarifying and supporting a role for other levels ofgovernment activity in the standards-setting process, state and local governments areoften the passive recipients of standards, without access to a process to influence thatstandard.

1

ELIMINATING LEGAL AND POLICY BARRIERS TOINTEROPERABLE GOVERNMENT SYSTEMS

I. INTRODUCTION

Concerned parents in Marion, Ohio noticed what seemed to be anabnormally high incidence of leukemia among River Valley High Schoolgraduates. In fact, upon further investigation it was learned that leukemiarates increased by 122% between 1966 and 1995 among students havingclose connections with the high school grounds. After much time andeffort, the parents’ detective work eventually revealed that the high schoolwas built upon the site of the former Marion Engineering Depot whichstored military equipment until the 1960's, and nearby to the former SciotoOrdinance Facility, a World War II bomb-making plant. Both facilities hadabandoned cancer-causing chemicals into the surrounding grounds.

Significant clean-up efforts are now underway in Marion along withattempts to locate almost-forgotten waste dumps through old aerialphotos. Such efforts have gotten the attention of national political figures,including Senator DeWine of Ohio.

Relating disease clusters to environmental factors occurred inMarion through personal recollections of residents, friends and family ofcancer victims. It took almost 30 years for the community to realize aproblem existed and to marshal the evidence to tie that problem to anunderlying cause.

Interoperability of information systems would facilitate making thesecorrelations easier, faster and more systematic.

Interoperability of information systems will have many beneficial effects ongovernment efficiency and delivery of governmental services, perhaps even life-savingeffects. By collecting and correlating information from otherwise diverse sources,dramatic new insights can result.

A. Why Is Interoperability Now an Option?

In the span of some fifty years, our computing technology has already gonethrough three significantly different generations of computers.3 We are now living in the

3 Each generation of hardware and software technologies spawns policy and organizational structures tomanage them. While the technologies have been quick to change, the organizational structures tomanage these technologies have often lagged, sometimes by as many as two generations.

2

fourth generation of computing technology – the networking of computers. Theintroduction of the World-Wide-Web technology represents the most visible of the manynew technologies in this fourth-generation of computers.

The third generation of computers – PCs – provided (and are still providing) anincredible increase in the ability to collect and store information on each person’sdesktop computer. We are all familiar with the exponential growth that has taken placeunder Moore’s law.

Yet with this exponential growth in the information processing of personalcomputers, the fourth generation of computers is even more impressive because itleverages the power of each of these powerful desktop computers. The leverage isgained through the networking of computers. Theoretically, networking enables theprocessing power and the information stored on these millions of computers to becomeavailable to each individual’s desktop. In theory, all of this information and computingpower is available to us; in practice, the problem of “interoperability” is how to make thisdream a reality.

B. Benefits of Interoperability

There are three fundamental benefits to government in developing interoperablesystems as fourth-generation networked technologies become dominant.

• Effectiveness – While many federal agencies were created to respond to theparticular crises of the day – Antitrust, Drugs, Labor, Education, new policyapproaches are based on the understanding that most social and regulatoryproblems go beyond the jurisdiction of one agency and require integrated policyapproaches. More effective government will require leveraging information andknowledge across these agencies to provide an integrated response to our morecomplex social problems.

• Efficiency – Once information is collected electronically, it becomes very easy toduplicate and manipulate. Thus, interoperable systems have the potential toreduce the paperwork burden on the public. Interoperable systems will allowfourth-generation computer networking technologies to facilitate access toinformation by all stakeholders.

• Responsiveness – Better access to information will allow government to actfaster and more effectively to identify problems and respond to them.

3

C. What are the Barriers?

Given these potential benefits, there are significant barriers to achievinginteroperability on a pervasive scale at the federal, state and local government levels.4

1. Political

• Privacy – The Orwellian threat of a big brother government is always associatedwith a sophisticated government information system. Before an interoperablegovernment can be achieved, privacy rights and their protection must be clarified.In addition to putting appropriate systems in place, a genuine feeling of trust andcontrol by citizens must be present before it becomes politically possible to haveinteroperable systems. An ECLIPS companion report to the IEP entitled “TheProtection of Personal Information in Intergovernmental Data-Sharing Programs”focuses on these issues.

• Ambiguity about statutory authority – Legally, agencies cannot act outside of thepower delegated to them under their authorizing statute. Derivatively, agenciescannot collect information outside of the subject delegated to them. An openquestion for most agencies is whether and under what circumstances informationcollected by one agency can be shared by another agency. Those agencies thatare hesitant to share information would prefer to have explicit statutory authorityto share information. More proactive agencies view narrow statutory guidance asan encumbrance to their discretion. Ambiguities about federal agencies’statutory authority to collect and share information extend to federal-stateinteroperabilities and information-sharing.

• Openness to public scrutiny – The development of interoperable systems willallow for heightened scrutiny. For many agencies, easy access to informationraises the spectre of more public requests for information and increased micro-management of the agency’s decisions.

2. Organizational

• Trust - Before agencies can share information, they must develop mutual trust.For example, a welfare services agency may collect application information as acondition precedent to a client receiving benefits. The intake officer collectingclient information places a high priority on getting benefits to that client. Thus,they may have very different quality control standards than an agency that usesthat same information in order to pursue a paternity establishment case so thatthe father is held responsible for child support. The agency pursuing a paternityestablishment must be able to place an extremely high degree of reliance on thedata it collects because it will be used in an adversary process before a judge.

4 These categories are adapted from Andersen and Dawes (1991).

4

For this reason, each agency collects redundant information because there islittle trust that the information that they are sharing will be accurate. The “giving”agency must trust the “receiving” agency not to use information in a way thatcompromises the statutory basis on which the “giving” agency collected theinformation. Given different agency priorities, how is trust established betweenagencies so that the efficiencies can be realized and service can be improved toclients?

• Lack of experience – Our field research indicates that interoperable systems arevery much the exception. An experience base that reflects the benefits and costsof interoperability has not yet developed. When faced with the unknown,agencies avoid information-sharing projects because they prefer to attend toproblems where there are relatively well-known ways of solving problems and arelatively clear understanding of the tradeoffs involved.

• Lack of awareness of opportunities to share – Good information resourcemanagement requires an inventory of an agency’s information resources. Oftenagencies have difficulty inventorying their own information. They face eventougher obstacles in learning about the existence and nature of informationcollected by other agencies.

3. Economic

• Lack of resources – Given the ever-increasing accountability of agency actioncombined with the narrowing of an agency’s resource base, most agencies arehard-pressed to enter into interoperability arrangements where the benefits areill-defined or a “public good” and the costs are not known with any certainty. Whyshould an agency expend its own scarce resources to make information availablefor the benefit of another agency?

• “Low bid” procurement methods – “Life cycle” or “Best Value” procurementmethods are still the exception in purchasing information technology in the publicsector. Often, interoperability costs more in the short run, posing difficulties foragencies oriented to “low bid” approaches.

4. Technical

• Hardware or Software Incompatibility – The most often cited problem tointeroperability is technical incompatibility between and among hardware andsoftware. Most basically understood, it is getting a Microsoft Windows programto read a Macintosh data set. On some level, most of these problems can besolved, but at some cost. Our interviews, however, indicate that these machine-dependent problems are becoming less and less of a problem as more openstandards are being set in the marketplace.

5

• Data-Sharing Standards – A more difficult ‘technical problem’ is the problem ofdata definitions and data quality standards. For example, a state correctionalinstitute may identify its charges through a ten digit system while a mentalagency identifies its charges through the use of social security number.Inconsistent data definitions prevent the correctional institute from identifyingthose prisoners who may need special kinds of rehabilitation. For the mentalagency, information is inaccessible on which mentally ill individuals may pose athreat to society. The natural answer is to harmonize these standards. But sincelayers and layers of procedures are built upon each of these data definitions,changing them will require changes to existing procedures. More difficult, is thatoften data definitions are mandated by law and in some cases, are inconsistentfrom jurisdiction to jurisdiction.

In this section, the initial benefits and potential barriers to interoperability asgleaned from previous research and surveys have been identified. In the followingpages, the policy architecture in place at the federal, state and local levels are identifiedto ascertain what institutions’ procedures are in place to address some of theseconcerns.

II. Method

A. Statement of Problem

The Intergovernmental Enterprise Panel (“IEP”) has authorized a study byECLIPS to examine the Federal laws, regulations and policies and the similar policyenvironments of five selected states in order:

1) To identify legal and policy barriers which exist to the collaborativedevelopment among Federal, state and local governments ofinteroperable government systems;

2) To develop guiding principles and strategies for eliminating barriers tointeroperability;

3) To recommend methods for improving the adoption of open, publicstandards in government information systems; and

4) To recommend specific actions to IEP offering the opportunity forleveraged demonstration of the applicability and benefits of interoperabilityas applied to governmental information systems.

Phase I of this report identifies policy barriers to interoperability. Based upon thosebarriers, Phase II identifies recommendations to reduce or eliminate those barriers.

6

B. General Approach

1. The Integration of Previous Research, Policy Documents, andInterviews

The research process began by reviewing previous research concerninginteroperability, information policy and intergovernmental operations. This working listof barriers also furnished set of criteria to use in selecting and reviewing policydocuments relevant to interoperability.

As these policy documents were analyzed, the list of candidate barriers andsolutions were developed. In developing the findings and recommendations, both directand indirect barriers to interoperability were sought ought, by analyzing the relevantlaws on “interoperability”; i.e., the statutes, administrative rules, OMB Circulars, andExecutive Orders. Having a descriptive model of federal policy allowed the researchteam to identify possible institutional, policy and managerial barriers to interoperability.

A set of working findings and recommendations were developed very early in theprocess, so that these working conclusions could be tested against the experiences andexpertise of the widest array of managers and policymakers. In this way, the researchteam could make the most use of the interviews by simultaneously testing the workingconclusions and looking to expand that set of conclusions.

2. Interoperability Policy Architecture

After developing a working understanding of the federal information policyarchitecture, a tool was developed to determine whether the existing policy architectureperformed all of the generic functions necessary to any policy process. See Table 1.

Two dimensions were identified early in the research as important tounderstanding the adequacy of the existing interoperability policy: “a policy functiondimension” and a “communities” dimension. The matrix was constructed by looking atthe intersection of these two dimensions; i.e., the role of each community in the policyprocess. Using this tool enabled the research team to systematically determinewhether; 1) all of the important communities were integrated into the basic functions ofthe policy process; and 2) each community had all of the tools it needed to completethose functions.

The functional dimension consists of the three most generic components in thepolicy cycle: the development of policy; its execution or implementation; and the finalevaluation of both the policy and its implementation. Typically, the results of anevaluation are then fed back into the refinement and development of policy.

Our interviews confirmed what past research has told us – that the communitiesdimension is salient in dealing with interoperability because of the highly complicated

7

and interdependent nature of interoperability problems. Each of these communities hasvery different norms, concepts and jargon and ways of understanding theinteroperability problem. Successfully achieving interoperability will require that thesecommunities, each with its own distinct competencies, work together towards itsimplementation. These communities include: 1) policymakers; 2) public managers; 3)the technical community; and 4) the wider “policy community” which includes all of thestakeholder groups with which the agency works in the creation of policy.

Table 1

Interoperability Policy Architecture:Planning, Implementing and Evaluating

Function /Community Policy Makers Management Technical Policy Community

Plan

How do we set broadguidelines that allowfor interoperability butdo not micromanage?

How do we takebroad policyguidelines andtranslate /supplement thoseguidelines toestablish policy forour local situation?

Given the broadand local policyguidelines whattechnical laws(standards) arenecessary toimplementtechnology?

How do we insurethat our local needswill be met, orminimally, will notbe hinderedthrough appropriatepolicy?

Implement

How can wemonitorimplementationwithoutmicromanaging?

Taking policy, howdo we coordinatehuman resources,political, technical,and fiscalresources withinand acrossorganizations?

How do wematch technicalopportunities withthe organization’sproblem ofachieving goalsgiven itsconstraints?

How do we insurethat policy isimplemented in ourpolicy community?

Evaluate

Where do we obtaingood information tounderstandnecessary policychanges?

How do we knowhow well we aredoing and what canbe done differently?

How do we knowhow well we aredoing and whatcan be donedifferently?

How can weparticipate in theevaluation and thedevelopment ofrecommendationsfor the next roundof policy /implementation?

The matrix was then applied against the existing policy documents tosystematically evaluate the information policy architecture to determine strengths,

8

weaknesses and “holes”. These tentative conclusion on the policy functions were thenincluded in the larger list of working conclusions.

These working, tentative conclusions were then tested against what practitionersin government—both federal and state—would say about interoperability. Did ourrecommendations make sense? Did our findings about the federal/state interoperabilitycorroborate what managers and policy makers saw? How does one achieveinteroperability when it is important? After each interview, the working model describingthe problems of interoperability and what kinds of recommendations could be made wasreviewed. Armed with this new understanding, the new set of findings andrecommendations were then tested in the next interview. In this way, a robust list offindings and recommendations was developed and accumulated.

C. Interview Protocol

To begin the interview process, the research team generated a generic list ofgovernment information technology professionals who might be in a position tocomment on federal/federal and federal/state interoperability. Federal officials werefairly easy to locate by searching federal web pages and through a series of phonecalls. To help in identifying state officials, the National Association of State InformationResource Executives (NASIRE) furnished a list of names for the generic list of officialsidentified. Based upon this list, the research team then identified, through a series ofphone calls, people in each organization whom could best comment on interoperability.This list was expanded by asking at the end of an interview, who might be ablecomment intelligently on the kinds of questions that were just discussed. The list of allinterviews conducted is shown at page 9, appendix C.

Before each interview, a statement on the general thrust of our research wasfaxed or e-mailed. It included a short description of the IEP and ECLIPS. This wasaccompanied by a working set of findings and recommendations. In order to secure theinterview and assure that the interview would not take too long, it was made clear thatthe interview would not cover every point; and that the goal was to obtain their mostsalient reactions – what was most horribly wrong and what was most interesting as aninsight. In order to secure an interview, it was explained that these were workingconclusions and that the purpose of the interview was to receive comment on theconclusions most salient and relevant to their work. Despite the proffer to discuss onlythe most salient points, interviews usually touched upon most of the general findings.The interviews lasted an average of one hour with some as short as 45 minutes andone interview lasting 2.5 hours.

A research judgement was made to conduct the interviews pursuant to anunderstanding that specific comments and/or recommendations would not be attributedto specific officials, states or agencies. The decision was to err on the side of obtaininga richer conversation about the difficulties and opportunities in achieving interoperability

9

against the ability to later document specific weaknesses and strengths in particularfederal and state agencies.

D. Explanation of Case Studies Chosen

One strategic choice made in focusing the present IEP study was to eschew abroad but necessarily shallow survey of barriers to interoperability in favor of a more in-depth probe by means of selected case studies.

The ECLIPS team decided on three case studies to study the most criticalaspects of interoperability 1) legal constraints; 2) cross-agency, regulatory enforcementwhere significant penalties could incur; and 3) the need to disseminate specializedknowledge across different domains using “meta-data” or “data about the data”. Ourcompanion report, “The Protection of Personal Information in Intergovernmental Data-Sharing Programs” focused upon a known legal constraint, the presence and absenceof privacy protections.

The field of environmental protection was selected as the case study for the caseof cross-agency, regulatory enforcement. The United States Environmental ProtectionAgency (“USEPA”) has been aggressively pursuing electronic reporting, data sharing,paperwork reduction, stakeholder involvement, intra-agency integration of informationand information systems and information system interoperability through a variety ofinternal programs and cooperative programs with states, regulated industries, and thepublic. Therefore, ample information exists from which to seek examples of effectiveand ineffective elimination of barriers to interoperability.

In addition, the environmental case study touches upon a system of concurrentand overlapping federal, state and local (including tribal) regulatory statutes andregulations, with data collection and enforcement responsibilities frequently delegatedfrom one level of government to another. In addition, environmental protection at thestate level will often involve numerous state agencies. Typically, there will be anagency having lead responsibilities for environmental protection but sharing (or yielding)jurisdiction among other state agencies for specific matters. State departments ofhealth, agriculture, natural resources, mining and minerals as well as coastal andwaterway protection agencies are typically agencies with responsibilities for protectingthe environment in selected areas (e.g. states tend to regulate pesticide use through thedepartment of agriculture, not environmental protection). Cities and municipalities willtypically have primary responsibility for land use and zoning, certainly impacting theprotection of the environment by its actions. Tribal sovereignty also will affectenvironmental protection thorough tribal control of information relating to waterways,fish and wildlife, waste disposal and landfills located on tribal lands. Thus,environmental protection offers a rich mosaic of interactions at coordinate and differentlevels of government from which cases relevant to a study of information systeminteroperability can be drawn.

10

The final case study, the Government Information Locator Service (GILS)5,focused on the meta-data problem because previous research had focused on thecritical importance of meta-data (or alternatively “meta-information”) to successfulinteroperability. Since interoperability is “effective sharing of information,” then theimplementation of interoperable systems critical information requires meta-data such as:What is the availability of the information? What is the cost of the information? Whatformat is the data in? How was the data collected? Each of these questions coulddirectly or indirectly be answered by information provided by the GILS service.

In addition to providing meta-data important to interoperability, GILS, is itself anexercise in interoperability because agencies have to conform to a minimum set ofstandards in order to share meta-data information. Based upon an initial reading of theimplementation of GILS across the federal and state governments, GILS has beenimplemented with varying degrees of success. This “natural experiment” provided theraw data from which we could determine if GILS and the provision of meta-data wasimportant to interoperability. At the same time, it is a case-study itself on the criticalsuccess factors to develop interoperable systems across the federal government, whereGILS was mandated by law and between different levels of government, where itsadoption is a policy option.

E. Explanation of States Chosen

The study requested by IEP included a study of five selected states in which thefederal, state and local information system interoperabilities would be investigated inmore depth. It is recognized that any limitation on the number of states wouldnecessarily exclude interesting and important initiatives undertaken by the non-selectedstates. However, within the constraints of the present study, it is believed that fivestates could give an acceptable cross-section of environmental regulation, developmentof their GILS architecture information interoperabilities and approaches to recognizingand overcoming barriers to interoperability.

The five states chosen in consultation with IEP are: Kansas, Massachusetts,Ohio, Texas and Washington. It was considered that these five states offered areasonably good cross-section of environmental situations and success with GILSimplementation of GILS. These states also vary by location, size and populations. Sizewas important because different states might have different organizational resources tosupport an information policy infrastructure. In the case of the environmental regulation,transborder (international border) states are represented in Ohio, Texas, andWashington. Interstate waterways heavily utilized for commerce and recreation arepresent in Ohio and Washington. Significant tribal interactions are present inWashington. It is hoped that the results of this study indicate the potential benefits to beobtained from a more comprehensive study of intergovernmental information system

5 For more information on GILS, see http://www.usgs.gov/gils/locator.html .

11

interoperabilities within the context of environmental regulation and the implementationof GILS.

III. Policy Analysis and Findings

A. Interoperability means the sharing of information

Finding 1: Interoperability among federal, state and local level information systems ismore than “plumbing” - making sure that the information pipes fit together throughcompatible hardware and software. Fundamentally, interoperability is “the sharing ofinformation.” “Sharing information” is the use of information generated from anorganization to improve policy or management.6 Eventual users could include otheragencies or the public. Agency information policymakers and managers must make thisfirst, conceptual leap before there can be any real progress in improving interoperability.

One of the early central findings in our work is that interoperability must beperceived as the sharing of information. This new focus towards information and awayfrom technical hardware and software concerns is driven by two simultaneous trends.One is the increasing use of open or almost universal technical standards and theexistence of technologies that increase the likelihood that systems can interoperate on atechnical level. The second simultaneous trend is that as difficult problems of accessinginformation are being solved through tools like the web, actually making the informationuseful now becomes the problem. All of our interviewees agreed with the centralimportance of making this conceptual leap. The more difficult problem is making surethat everyone in the organization understands this and that the policy tools are alignedto this new goal.

Finding 2: Interoperability projects frequently fail because important meta-datainformation is either not known or is not shared. Meta data is “data about the data.”Meta-data are the important data that must be known before information is shared.Examples of meta-data include such characteristics as the quality of the data(timeliness, precision, clarity, accuracy); whether it is quantifiable; whether it isverifiable; how accessible it is; whether it is comprehensive; who the information wascollected from; the authority under which the data was collected; limitations on the useof that data; the author of the data; and the physical and logical storage characteristicsof the data.

This meta-data can be made available in two ways: 1) formally, through aninformation system like GILS or Internet-accessible environmental data files; or 2)

6 Use of information can include: 1) being directly used in the decision process; 2) validating or refutingan already completed decision process; 3) instigating an organization to act even if the information isnever used in the decision process; and 4) creating new information by combining data from severalsources.

12

informally through people who know about the information. The choice of formal andinformal approaches depends on the complexity and richness of the meta-data. Inmany cases, formal approaches (such as GILS) are a satisfactory solution to the initialproblem of “pointing to” and identifying potential opportunities for sharing information.But as the complexity and richness of the meta-data increases, agencies will tend torely more on informal approaches to support inter-agency use of information becauseformal approaches cannot fully capture the rich set of contextual concerns that affecttheir ability to actually use relevant information.

The idea of using GILS to support interoperability is not new; one could arguethat it was envisioned in GILS as part of the greater benefit that could be achieved inthe wider dissemination of information. However, one of our interviewees deliberatelyfocused on GILS as a way to stimulate and support interoperability. The effort was notsuccessful; however, the failure was not because the idea was not good one, butbecause GILS lost out in the power struggle between the state library and theinformation technology people over what GILS should require and what it could provide.The interviewee suggested that perhaps a better introduction and a better politicalclimate could have made GILS a success. Other implementors of successful GILSprojects, while not focused on the goal of interoperability, commented on the increasedsharing of information that they observed as a result of GILS.

While our interviewees agreed that a GILS-like service is important tointeroperability, they also agreed that GILS, is itself, an exercise in interoperabilitybecause all agencies must agree to standards about collecting information about theinformation. GILS solves the standards problem elegantly by requiring that data becollected but leaving it to each agency to decide what set of descriptors to use for eachkind of data.

While GILS or a GILS-like service seems to hold promise as a first, but importantstepping stone towards interoperability, there is a difference of opinion as to what GILSrequires, the costs and benefits in implementing GILS, and how well GILS has beenimplemented (Moen and McClure, 1997). Our interviews confirmed this difference ofopinion. Fully sorting out the competing arguments and conclusions was out of thescope of this research, but clearly the difference of opinion and the existence of bothsuccesses and failures in GILS suggests: 1) that the success of GILS in certain stateslike Washington, shows that there are better ways to implement GILS systems thatwork; 2) over time, technologies and managerial approaches will be developed that willmake it easier to implement GILS; and 3) the GILS efforts could benefit from the sharingof best practices.

Our interviewees all agreed that there are no significant policy barriers toimplementing GILS or GILS-like services; in fact, law mandates GILS. What is lackingis the institutional mechanism to support agencies in their implementation of GILS.

13

Finding 3: Frequently the cost and time constraints are too prohibitive to effectuate thesharing of information even if the meta-data is available.

Interoperability will not always be the answer to inadequate IT budgets or a moreeffective government. But our interviewees stressed the long-term commitment that itwill require to achieve interoperability and to achieve a GILS-like service. This long-term commitment needs to be made despite the disruptive effects of various short-termpolitical, technology, and budgetary cycles. The long-term approach views theachievement of interoperability as a convergence process of agency plans andstrategies that requires that certain directions and infrastructure be laid out now, so thatconvergence can take place over time.

Finding 4: The project team found that many agencies use “sharing agreements” orcontracts to specify how data is to be shared. Sharing agreements are an ad hocprocedure for setting terms and conditions for making data available acrossadministrative boundaries. In many cases, however, these sharing agreements areindividually researched and written when, in fact, many of the same issues andconcerns are present across these agreements. This uncoordinated activity results inunnecessary duplication of time and resources as each data sharing agreement isindividually planned and implemented. Moreover, the complexity of researching andwriting such agreements is often a significant disincentive for smaller agencies.

At the same time, states now focus on particular, need-driven data-sharingarrangements. This ad hoc approach, while an important step in learning how to sharedata, can lead to a patchwork data-sharing policy. Ad hoc approaches invite thecreation of inconsistent policies and practices across agencies and levels ofgovernment.

The environmental protection case study7 revealed many instances of intra-agency cooperation agreements and sharing of data as responsible agencies transitionfrom media-based data collection and storage systems (e.g., air, water, etc.) to a facility,one-stop form of information management. Intra-agency pooling of information andinformation technology typically has a common supervisor (maybe as far up as thedirector of the agency), but this does not totally remove the use of written agreementsfor sharing data. Additionally, responsibilities for environmental protection are typicallyspread over several state agencies (typically agriculture, health, natural resources, fishand wildlife, occupational safety, and the like). Further complicating matters, statesoften have local or regional authorities with responsibility for a particular coastal area, orriver region that also must interface with environmental information systems and needs.Coordinated environmental protection agencies in adjacent states also have commonenvironmental needs (e.g., Ohio River matters are relevant to six bordering states).

7 Please see Appendix B

14

Finding 5: Developing strong interoperable systems at the federal, state and local levelrequires construction of, and access to, a reservoir of specialized knowledge andexperience of practitioners in information resource management. Policy makers andmanagers do not always have ready access to this knowledge.

The broad definition of interoperability as information-sharing implies thatpotentially a complex set of considerations must be attended to, in order forinteroperability to be successfully implemented.

Setting up these systems or entering into these data-sharing exercises may notoccur frequently and therefore the experience of how to implement interoperability isquite specialized and may be difficult to access. Our interviews revealed that in manyinstances data-sharing agreements were the result of many years of agency effort. Adiverse set of issues were mentioned as stumbling blocks that had to be “negotiated”including: whether there was statutory authority to share information, understandinghow the information was created and its resultant quality and utility; and the allocation ofresources to make the data-sharing possible. In many cases, the scope and scale ofthe work was underestimated.

Finding 6: One barrier to interoperability, or the use of shared information, is the beliefthat providing undigested data too freely to the public will permit its distortion andmisuse, perhaps by persons advancing a political agenda rather then advancinggovernance.

Drawing upon past research, one of the early working assumptions aboutbarriers to interoperability was a concern that agencies “lose control” of their owninformation. Our interviews with developers of “information utilities”, GILS, and StateCIOs confirmed that the fear of losing control is prevalent. However, for those statesthat successfully implemented GILS and information sharing projects, this fear provedunfounded. While there may be occasions of misuse and distortion, our reading of thelaw and policy tools available to organizations, suggests that agencies have the abilityto define the context within which information is used and, in that way, reduce theopportunities for misuse and distortion.

B. There is a Natural Evolution, or Learning Curve, in the Developmentof Interoperable Systems

Finding 7: There are factors that tend to support the identification, planning, andimplementation of data-sharing arrangements. This is the knowledge about how toshare information. If there is a natural learning curve, agencies can use this knowledgeto learn from the mistakes of others by climbing the learning curve faster and moreintelligently. Our reading of past research identified several factors in managing thislearning curve that were later confirmed by our interviews:

15

• Sharing is more likely when agencies have a history of working together so thattrust and a common understanding of how things are done in each agency canbe established.

• Sharing is more likely when there is free, centralized money than when agenciesare asked to fund sharing out of their own budgets.

• Federal/state sharing will only be accomplished when it is perceived in thoseagencies’ own self-interest.

• Multi-level or multi-agency information sharing arrangements benefit by makingall the interested organizations, equal parties to the agreement.

• Interoperability projects are more easily implemented when the focus is onsharing transaction information (as opposed to operational or strategicinformation) since these are the processes where tangible benefits in reducedcosts and improved service can most easily be documented.

• Interoperability projects are more easily implemented when the projects result inshort, or even same year benefits as opposed to long run benefits.

• Interoperability projects are more likely when the sharing occurs within an agencyand budget savings can more easily be shared than when the sharing occursbetween agencies.

• Crisis is often an important catalyst for intergovernmental collaboration point inraising awareness and providing the political capital necessary to sustainprogress towards a solution.

Policy makers and managers need to use these critical success factors whendeciding upon the selection of targets of opportunity including demonstration projects orjoint-agency projects.

An important focus from the beginning of the research was to identify the factorsthat retard or accelerate interoperability. Prior research on interoperability andintergovernmental operations suggested a large number of the factors. Our interviewsin general, and in particular, the GILS and Environmental Protection case studiesconfirmed the above factors as important to interoperability.

Not all of the interviews mentioned all of the items listed here as important. Ourconclusion is that interoperability projects will vary in the kinds of problems experienced.This list of important factors, however, can serve as a checklist, that ought to beconsidered in the selection of interoperability projects and how they are implemented.

It should be noted that we did receive one inconsistent set of prescriptions. Onthe one hand, some of our interviewees suggested that the only way that aninteroperability project would work was if there was a specific legislative mandaterequiring it. It was argued that agencies have far too many projects and pressures toattend to, and would choose to work on these projects rather than on something forwhich the costs and benefits are unknown, as is the case of interoperability. Theconclusion was that unless the attention of the agency was focused through a mandate,it would not happen. Once the attention was focused on the correct priorities or

16

activities, the agency would find a way to get things done. On the other hand, our casestudies and interviews also revealed that merely requiring public agencies to engage ininteroperability projects, to consider such projects in their strategic planning, or toimplement GILS in their agencies, does not mean that they will have the capacity or theability to actually implement it. Perhaps the best way to understand the problem is whatone interviewee suggested - that the priority should be on making the tools andresources necessary to support GILS and interoperability in general. Invoking the ruleof law by pointing at a statute should be used very sparingly.

C. Sharing Information Means Planning for Both Its Collection and Use

Finding 8: Our review of federal policy documents revealed that there is a policyarchitecture in place to support information sharing. Interoperability is supportedthrough an explicit policy that requires agencies to work with state and localgovernments; to attempt to share information before collecting new information; providefor information dissemination mechanisms; develop systems in a manner that facilitatesinteroperability; share available information systems with other agencies to the extentpracticable and legally permissible to meet information technology needs through intra-agency and inter-agency sharing, when it is cost-effective, before acquiring newinformation technology resources; and for agencies to use the GILS standard to helpthe public locate and access information.8 While the strong policy statements are inplace, federal agencies also need support mechanisms to understand and deal with therange of economic, political, technical and organizational issues involved withinformation sharing.

While there is a well-developed federal information policy architecture in place,our cursory review of state policy documents suggests that there are wide variations inthe degree to which interoperability is addressed. Some states explicitly mention theimportance of interoperability and information-sharing, other states only discussinteroperability as it relates to particular domain areas, while being silent on policy ingeneral. In still other states, there was difficulty in finding any explicit policy guidanceon interoperability. However, there are few specific provisions that require cooperation,an examination of opportunities to share information, or the planning of what theyexpect to collect. Specific provisions like these would avoid the data definition problemsand many other meta-data problems that typically confound attempts to interoperate.

Finding 9: There is a scarcity of quantitative measures of interoperability such that anobjective assessment of progress toward interoperability goals can be made. Whetheror not such measures exist in the scholarly literature on the field, our interviews withstate and federal managers and the case studies analysis found scant evidence thatsuch are seriously attended to in the daily life of information system managers. 8 The Paperwork Reduction Act of 1995 (44 U.S.C. 3511); M-98-05 OMB Circular No. A-130, OMBBulletin 95-1, OMB Bulletin No. 98-03

17

D. There is No strong Federal/State Architecture in Place to SupportInteroperability

Finding 10: The existing federal information management model is designed tomaximize the efficiency and effectiveness of individual line agencies. There is a veryrational cycle of requiring agencies to (1) specifying organizational goals by specifyinghow information technology will achieve that goal, (2) identifying what costs will beincurred by the process, and (3) evaluating whether the information technology hasachieved the goals intended.9 But this heavy “focus” on what individual agencies arerequired to accomplish naturally takes away attention and energy from cross-agency,cross-level of government cooperation.

At the Federal level, agency legislation mandates a strong, agency-widestrategic-planning effort, which lays the foundation for smart strategic informationplanning. But the strong emphasis on planning that makes the connection betweenresources and outcomes clear, defines measures for success and installs a variety ofaccountability and reporting measures, actually has the perverse effect of excludingstates from the planning effort. Unfortunately, if states are not involved early with thefederal strategic planning for information needs, and this is tightly bound withinformation planning and procurement, there is little chance for the states to have a realvoice in the process.

State officials also expressed the hope that federal requirements for providingdata should be rationalized. Far too often, states view these requirements as anotherform of unfunded mandate because there are significant programmatic and fiscalresponsibilities that come along with these information requests. In some cases, thestates are not sure that this information is even being used. State and localgovernments will need to see a benefit in collecting and providing this information to theFederal government. Finally, states are concerned about the sometime inconsistentdata requirements—agencies explicitly requiring different kinds of information fromstates.

Finding 11: Interoperability is hindered by statutory requirements that data be collectedand reported to Congress according to specific statutory definitions. Definitions of manycommon terms (“solid waste,” “hazardous waste,” and the like) often differ from federalto state government and from program to program within one agency, leading toseparate (but highly redundant and overlapping) data collection and storage methodsthat have no path to interoperability. The table below demonstrates these differencesdramatically.

9 Government Performances & Results Act (1993); Information Technology Management Reform Act of1996; The Paperwork Reduction Act of 1995

18

Table 2

Differing Statutory DefinitionsOf "Hazardous Substance"

Law Definition42 USCS7274d

"For the purpose of this section, the term "hazardous substance" includesradioactive waster and mixed radioactive and hazardous waste."

42 USCS9601

The term "hazardous substance" means (A) any substance designatedpursuant to section 311(b)(2)(A) of the Federal Water Pollution control Act[33 USCS Section 1321(b)(2)(A), (B) any element, compound, mixture,solution, or substance designated pursuant to section 102 of this Act [42USCS Section 9601], (C) any hazardous waste having the characteristicsidentified under or listed pursuant to section 3001 of the Solid WasteDisposal Act [42 USCS Section 6921] (but not including any waste theregulation of which under the Solid Waste Disposal Act [42 USCS Sections6901 et seq..] has been suspended by Act of Congress), (D) any toxicpollutant listed under section 307(a) of the Federal Water Pollution ControlAct [33 USCS Section 1317(a)], (E) any hazardous air pollutant listed undersection 112 of the Clean Air Act [42 USCS Section 7412], and (F) anyimminently hazardous chemical substance or mixture with respect to whichthe Administrator has taken action pursuant to section 7 of the ToxicSubstance Control Act [15 USCS Section 2606]. The term does not includepetroleum, including crude oil or any fraction thereof which is not otherwisespecifically listed or designated as a hazardous substance undersubparagraphs (A) through (F) of this paragraph, and the term does notinclude natural gas, natural gas liquids, liquefied natural gas, or syntheticgas usable for fuel (or mixtures of natural gas and such synthetic gas).

OhioRevisedCode3734.01

"Hazardous waste" means any waste or combination of wastes in solid,liquid, semisolid, or contained gaseous form that in the determination of thedirector, because of its quantity, concentration or physical or chemicalcharacteristics, may do either of the following" (1) Cause or significantlycontribute to an increase in mortality or an increase in serious irreversibleor incapacitating reversible illness; (2) Pose a substantial present orpotential hazard to human health or safety or to the environment whenimproperly stored, treated, transported, disposed of, or otherwise managed."Hazardous waste" includes any substance identified by regulation ashazardous waste under the "Resource Conservation and Recovery Act of1976," 90 Stat. 2806, 42 U.S.C.A. 6921, as amended, and does not includeany substance that is subject to the "Atomic Energy Act of 1954," 68 Stat.919, 42 U.S.C.A. 2011, as amended.

Finding 12: There is an inherent tension between the need for national informationsystem interoperability with a particular programmatic focus (e.g., environmentalinformation) and the no less compelling forces for interoperability across programswithin a state (e.g., environmental and disease data in Marion, Ohio). Our review of

19

environmental information system interoperabilities has indicated that state agenciesare typically under top-down pressure to coordinate their information systems primarilywithin the agency, secondarily across related agencies within the state, and thirdly, inaccordance with national interoperability policies. Insofar as interoperabilities can beachieved simultaneously at more than one of these levels, agencies will attempt to meetall three demands. However, when priorities must be assigned to interoperabilities, theabove priority sequence tends to be observed.

The Ohio Environmental Protection Agency has been among the leaders inmaking environmental information available to the regulated community, citizens andother stakeholders through information technology. SIIMAN, SWIMS and otherprograms represent information technologies applied to media*specific needs at theforefront of Ohio EPA concerns. Following behind is cross*media information sharingas the Ohio EPA devotes increasing efforts to coordination of environmental informationand interoperability across various regulated media. Scant attention was evident inconnection with information to interoperability with other agencies, not through lack ofinterest or concern, but as a priority allocation with limited human and financialresources.

Finding 13: The federal information management architecture is not scalable—that is,smaller levels of government cannot effectively duplicate the federal architecture. Thefederal government will impose undue expectations on the states if it plans under theassumption that state and local governments can participate in information planningusing the federal information policy architecture.

The review of federal policy documents revealed a well-developed informationpolicy infrastructure. An immediate question arose as to whether all states, large andsmall, could duplicate this infrastructure. Our selection of states for the case studiesspecifically included small states to answer help answer this question. Our interviewsdid not reveal a problem with the small states selected, but our interviews with largerstates indicated that they are often consulted for help and assistance by neighboringsmaller states. These states also volunteered that states in the same region often needto work together on policy problems as well supporting the information needs thatsupport that policy making process.

Given this disparity in resources, assumptions about the ability of all states to befully included in the formulation of information policy may need to be revisited.Mechanisms need to be developed to support the ability of small states and those withfewer resources to develop and support information policy as it relates to interoperabilitywith larger states and the federal government.

20

E. In a Technology-Driven Society, Technical Standards are AnotherKind of Public Law

Finding 14: While the federal government has made significant progress in redefininghow government participates in the standards process, the policy must now besupported by infrastructure and process. Most critical is insuring the continued adoptionof open standards and insuring that the technological standards that are adoptedsupport the government’s goal of sharing information.

In information sharing, technical standards can function like law, because theydetermine, for the indefinite future, the kinds of activities that can be undertaken.However, unlike public law, many of the processes designed to create technicalstandards do not have adequate mechanisms for representation and appeal for otherlevels of government who must use those standards to develop interoperable systems.Currently, there is very sporadic representation by public agencies in the standards-setting process. Where there is representation on the federal level, support is providedby the National Institute for Standards and Technology (NIST) but NIST also faceslimited resources in begin able to do more. NIST has also been successful inleveraging its expertise by assisting other standards-setting efforts, for example, theU.S. Federal Geographic Data Committee.

Most state agencies communicate their preferences for a technical standarddirectly to their vendors but they feel that other avenues to insure good standardsshould be cultivated. Alternatively, public servants also communicate their needs for atechnical standard through their professional communities, but they agree that thisresults in a splintered representation of government and public interests. States do notnecessarily want the federal government to become involved in the standard-settingprocess on their behalf. They also desire that standards should be established onlywhen pilot projects have proven the workability of those standards. Standards shouldfollow proven best practices.

States described the federal efforts planning as being “very abstract and big-picture” but not necessarily informing the real-life implementation problems. One of themore salient decisions before the GILS community is over which of the various meta-data standards should be adopted. Our case study revealed that agencies are facingimportant decisions about whether GILS, Dublin Core, or XML standards are the bestway to proceed. Lacking the ability to adequately track the standards discussions andnot knowing the cost and procedural implications of adopting or refining a standard,many agencies adopt a wait-and-see attitude. The result is non-innovation.

IV. Summary and Future Work

Taken together, the findings indicate that, aside from the work that needs to bedone in clarifying privacy rights, there are no real major policy barriers to interoperability

21

at the federal level. What are lacking mechanisms to support interoperability. Incontrast, in some states, the policy architecture to support interoperability needs to bemore fully developed. Clearly, there also need to be adequate support mechanisms tohelp state agencies in working through the complicated set of questions in pursuinginteroperability also applies.

Table 2 brings together the accumulated findings as they fit into theinteroperability policy architecture matrix first introduced in Table 1. The mostsignificant planning barrier, was in the obsolescent notion across all communities ofinterest - policy makers, managers, the technical community and the policy community(stakeholders), that interoperability is really a problem in getting the right technology orin using technology to solve problems. Unless there is a shift in perception, the moreimportant organizational and policy questions implicit within the technical ones will notbe addressed. The focus on interoperability as information-sharing will allow theidentification of the correct goals and measures towards achieving those goals.

As seen by the relatively larger number of barriers listed in the manager column,what is lacking are mechanisms to support managers in the implementation ofinteroperability. Finally, the interviews also revealed that all communities of interestneeded better information on the evaluation question, i.e., what works for bothinteroperability in general, and in particular with the implementation of GILS. PhaseTwo attempts to identify the mechanisms and tools to deal with the barriers discussed inPhase One.

22

Table 3

Interoperability Policy Architecture:Planning, Implementing and Evaluating Policy

Planning Barriers

Policy Makers Management Technical Policy CommunityGoal: Set broad guidelinesthat allow forinteroperability but do notmicromanage

• Many still seeinteroperability astechnical

• No formal institutionchampion to supportinteroperability

• Inconsistent statutorydata definitions

Goal: Take broad policyguidelines and translate/supplement thoseguidelines to establishpolicy for each localsituation

• Managers still planinteroperability as atechnical problem

• Short runconsiderations displacelong-term planning oninteroperability systems

Goal: Understandtechnical laws andstandards necessary toimplement technology • Technical community

unfamiliar with thepolicy choicesimportant to informationsharing

• Projects fail technicallybecause importantmeta-data not available

• Linkages amonginformation plan,functions meet thatplan and standards tobe not clearly defined.

• Government agenciesstill passive recipientsof standards

Goal: Ensure that localneeds will be met, orminimally, will not behindered throughappropriate policy • State and local

governments enter thediscussion late overinteroperabilityrequirements imposedby the Feds

23


Implementation Barriers

Policy Makers Management Technical Policy Community

Goal: MonitorImplementation withoutmicromanaging

• Policy mandatescollection of meta-databut does not createinstitution to support /championimplementation of GILS

• Policy makers do nothave knowledge baseof the critical successfactors to supportinteroperability

Goal: Coordinate humanresources, political,technical, and fiscalresources within andacross organizations • Managers too often

implementinteroperability projectsas a technical problemto be left to techniciansto solve or fortechnology to solve

• Projects do not oftenhave technology /organization translatorsactively participating

• Informal organizationoften overlooked asimportant infrastructureto support sharingmeta-data

• Inability to sharepersonnel is barrier tosharing meta-dataabout information inrespectiveorganizations

• Use of innovativesolutions tointeroperability in“sharing contracts” notwidely disseminatedwasting opportunities toshare and leading toinconsistent practices

Goal: Match technicalopportunities within theorganization’s budget andprogram constraints

• Governmentorganizations are oftenforced to “choose”standards or forced todelay implementationbecause of uncertaintyas to which standardsare appropriate

Goal: Ensure that policyis implementedconsistently across theentire policy community

• No central coordinationof federal and stateinformation sharing

• Federal governmentinformation sharingwith states may requireinformationmanagementinfrastructure that is notscaleable to all states

• Perception thatproviding undigesteddata freely will lead tomisuse inhibits agencydissemination ofinformation

24


Barriers to Evaluation

Policy Makers Management Technical Policy Community

Goal: Obtain informationto understand necessarypolicy changes on acontinuous basis

• There is littlecommonly-understoodsystematic knowledgeon the relative successof interoperabilityprojects and theexplanations for theirsuccess

Goal: Developappropriate milestonesand measures of success


• There is a scarcity ofquantitative measuresif interoperability suchthat an objectivemeasure of progresstowards interoperabilitycan be made

Goal: Monitorperformance of systemsand measure successagainst acceptedmeasures ofinteroperability • There is little

commonly-understoodsystematic knowledgeon the relative successof interoperabilityprojects and theexplanations for theirsuccess

• There is a scarcity ofquantitative measuresif interoperability suchthat an objectivemeasure of progresstowards interoperabilitycan be made

Goal: Participate in theevaluation and thedevelopment ofrecommendations for thenext round of policydevelopment andimplementation
