DEPARTMENT OF JUSTICE

OFF ICE OF JUSTICE PROGRAMS

BJA NI J OJJDP BJS OVC

U.S. Department of Justice

Office of Justice Programs

Bureau of Justice Assistance

System Integration: Issues

Surrounding Integration of

County-Level Justice

Information Systems

Monograph

Bureau of Justice Assistance
i

Type of Publication

Bureau of Justice Assistance

System Integration: Issues

Surrounding Integration of

County-Level Justice

Information Systems

November 1996 Monograph NCJ 156841
ii

Bureau of Justice Assistance

Bureau of Justice Assistance

633 Indiana Avenue NW., Washington, DC 20531

U.S. Department of Justice Response Center

1–800–421–6770

Bureau of Justice Assistance Clearinghouse

1–800–688–4252

Bureau of Justice Assistance Internet Address

http://www.ojp.usdoj.gov/BJA

This document was prepared by SEARCH, The National Consortium for Justice

Information and Statistics, under cooperative agreement number 92-DD-CX-0005,

awarded by the Bureau of Justice Assistance, Office of Justice Programs, U.S.

Department of Justice. The opinions, findings, and conclusions or recommendations

expressed in this document are those of the authors and do not necessarily represent

the official position or policies of the U.S. Department of Justice.

The Bureau of Justice Assistance is a component of the Office of Justice Programs, which also

includes the Bureau of Justice Statistics, the National Institute of Justice, the Office of Juvenile

Justice and Delinquency Prevention, and the Office for Victims of Crime.
iii

Acknowledgments

The System Integration: Issues Surrounding Integration of County-level Justice Information

Systems report was produced by SEARCH, The National Consortium for Justice Information and

Statistics. Dr. Francis J. Carney Jr. is the Chair and Gary R. Cooper is the Executive Director of

this private, nonprofit consortium of the states.

Production of the report was supervised by Mr. David J. Roberts, Deputy Director. The report

was written by Mr. Robert L. Marx, SEARCH Senior System Specialist. Support was provided

by Kelly J. Harris, Program Coordinator, and Jane L. Bassett, Publishing Assistant. The project

was conducted under the direction of Jay Marshall, Grant Monitor, Bureau of Justice Assistance.
v

Table of Contents

1. Executive Summary ................................................................................................. . 1

2. Introduction .............................................................................................................. . 3

Purpose of this Report......................................................................................................... 3

Target Audience .................................................................................................................. 3

The Workshop Method ....................................................................................................... 5

Project Funding and Support .............................................................................................. 6

3. Scope of Integration................................................................................................. . 7

Thinking About Scope ........................................................................................................ 7

The Importance of a Scope Statement ................................................................................ 7

Scope: County-funded or County Borders .......................................................................... 9

Scope: Criminal Justice or Justice .................................................................................... 10

Scope: Full Agency Information Needs or Case Management Information Needs.......... 11

4. Organizing for Change .......................................................................................... . 13

Gathering: The Initial Phases ............................................................................................ 13

Leadership and Authority.................................................................................................. 13

Defining the System Goal, Objectives and Tasks ............................................................ 16

Defining the Development Timetable............................................................................... 18

Establishing a Review Process.......................................................................................... 19

5. The Big Decisions .................................................................................................. . 21

System Characteristics ...................................................................................................... 21

The Role of Legacy System Environments ...................................................................... 22

Unification or Coordination .............................................................................................. 23

Step-phased or Application-based Development .............................................................. 24

Automation or Reengineering........................................................................................... 25

Inside or Outside Development ........................................................................................ 26

Build, Buy or Transfer ...................................................................................................... 27

How to Manage the New System...................................................................................... 28

6. Sharing Data ........................................................................................................... . 29

Reasons for Data Sharing.................................................................................................. 29

Concepts of Data Ownership ............................................................................................ 29

Sharing Person Descriptors............................................................................................... 30

Sharing Case Descriptors .................................................................................................. 31

7. Appendix ................................................................................................................. . 33

Glossary ............................................................................................................................ 33
System Integration Chapter 1 — Executive Summary Page 1

Chapter 1

Executive Summary

Many counties are considering the integration of information services in support of the

law enforcement, prosecutorial, court and correctional services provided within their

borders. (Integration involves several agencies working together to satisfy their own

single-agency needs and also the data-sharing needs which bring them together.)

SEARCH, with funding from the U.S. Department of Justice, Bureau of Justice

Assistance, convened a workshop of persons who have participated in such integration

projects. This report is the product of that workshop. SEARCH is responsible for the

content of this report, but acknowledges the major contributions of the workshop

participants.

The first phase of system integration is often organized informally, with a focus on

frustration among users of the present information systems. Leadership tends to be

charismatic rather than authoritarian, membership is loosely defined or not defined,

decisionmaking is by building consensus, and topics may be revisited several times. This

phase may last several months or longer.

The second phase focuses on a search for solutions, is accompanied by more formal

organization and decisionmaking methods, and may require outside resources: funding or

temporary assignment of staff from member agencies.

It is essential to establish the scope of the integrated information system.

• It may involve only the criminal justice components or all

components of the justice system.

• It may involve only case management or all data processing

requirements of the participating agencies.

• It may include all justice agencies within the county or only those

operated by the county government.

Several important decisions need to be made early in the development process, including

these:

• The system may be required to use existing computer equipment and

software tools, may establish its own environment, or may require a

combination of both.

• The software may be designed as a single entity, or it may be

conceived as several agency-specific entities with appropriate datasharing software.
Page 2 Chapter 1 — Executive Summary System Integration

• Implementation may proceed on an agency basis, or all agencies may

proceed on a single timetable toward a single shared operational

cutover.

• The system design may lean heavily on the automation of present

tasks, or it may depend on an entirely new concept of how the justice

system should operate.

• The development project may be performed by personnel already

within the government or by private contractors. It might involve

building entirely new software packages, or buying packages from a

private vendor, or transferring packages from another county.

• Ongoing management of the system may be lodged in an existing

information technology agency of the county, or may involve a

continuation of the user-agency committee formed for the

development phases.

Sharing data among the user agencies is an important, perhaps the most important,

benefit of an integrated system. The categories of data most likely to be shared are:

• Information about agency employees;

• Information about private persons with an ongoing relationship to

the county justice system, such as private attorneys;

• Information about persons who are parties to justice cases;

• Information about case events and their outcomes;

• Information about law citations; and

• Information about case outcomes (dispositions).

Note that establishing a plan for integration requires no knowledge of bits or bytes, wire

or fiber, nanoseconds or megahertz; it requires an understanding of the “business” of the

justice system and what information is required to conduct that business.

The first phases of integrating a justice information system at the county level are

difficult and important. They require a level of inter-agency cooperation and compromise

far beyond that normally encountered in a county. There is no single “right way” to form

the consensus, make the decisions or configure the system. The comments in this report,

derived from the experiences of the counties that have gone through, or are going

through, these experiences should be of help to those counties and other governmental

entities, such as the state, that are about to begin the integration journey.
System Integration Chapter 2 — Introduction Page 3

Chapter 2

Introduction

■ Purpose of this Report

This report describes issues surrounding the development of integrated computer systems

to serve more efficiently and effectively the information needs of all participants in the

justice system at the county level.

The report provides a discussion of each major issue, but does not “give the answer” in

the sense of prescribing a specific path through the development process. We do not

believe that there is a single answer, a single “right way” to integrate these information

systems. We believe that the choice of appropriate methods, and even appropriate

outcomes, for an integration effort depends on at least the following factors:

• The level of information technology expertise presently within the

county;

• The history, if any, of successful and unsuccessful inter-agency

cooperation within the county;

• The degree to which information needs of each justice agency in the

county are now being met;

• The stability and receptivity to change of each agency head

potentially affected by integration;

• The history of making and keeping long-term financial commitments

by the county, and the resulting willingness of agencies to “wait their

turn” while cooperating in an extended multi-agency project; and

• The history, if any, of successful and unsuccessful county efforts at

“outsourcing, ” that is, the purchasing of contractual development of

computer software and hiring of non-permanent project employees.

■ Target Audience

Many counties are considering the integration of information services in support of the

law enforcement, prosecutorial, court and correctional services provided within their

borders.

Several counties have already undertaken the integration tasks. They have learned

valuable lessons “the hard way.” This report attempts to package some of that experience

for use by those now undertaking integration, or considering it.
Page 4 Chapter 2 — Introduction System Integration

Persons who are responsible for authorizing funds for an integration project may be

seeking an assurance that the experience of other counties is being considered, and that

all relative issues will be addressed during the development process. These persons

include:

• Members of the County Board of Supervisors;

• The County Executive Officer and members of that staff; and

• Persons from state and federal agencies that make grants for such

systems.

Persons who are engaged in the development process and will be users of the resulting

system may be seeking general guidance on how to proceed and what issues have major

impact on the success or failure of the development effort. These persons include:

• The Sheriff;

• The Chief of Police of each police department in the county;

• The Jailer;

• The Prosecutor;

• The Court Administrator;

• The Court Clerk;

• The Presiding Judge of the Court of General Jurisdiction

• The Presiding Judge of the Court of Limited Jurisdiction; and

• The Director of Probation.

The county director of information technology may want to consider exploring ways to

make the transition to an integrated system.

Government employees other than the heads of agencies may also benefit from this

report. We believe that many, perhaps most, integration efforts “bubble up” from within

agencies rather than “trickle down” from agency heads. Heads of agencies are sometimes

sheltered from the frustrations that beset middle managers and workers within their

agencies, trying to get the information they need in the absence of formal informationsharing protocols between agencies.

Representatives of other agencies that use information generated within the county

system, but do not contribute data to it, may profit from this report. This includes

agencies involved with statewide court administration, statewide criminal history

systems, state driver licensing, local police agencies, and so on.

Consultants and system vendors may benefit from a look at the development process

from the user point of view. They may also find it useful to use this report as a way of

gauging the readiness of a given county for serious progress toward integration.

Members of the general public may welcome a structure into which they can insert their

requirements for public access to justice information, and alternative ways of paying

fines and other justice costs.
System Integration Chapter 2 — Introduction Page 5

■ The Workshop Method

SEARCH convened a workshop on this subject at its Sacramento, California,

headquarters. We invited six persons who had participated in county-level integration

efforts. Beginning with a proposed outline of this report, they engaged in 11 hours of

intense discussions on every aspect of system integration. Later they commented on the

draft report prepared by SEARCH. The workshop participants were:

• Bob Wessels, Court Manager, County Criminal Courts at Law, Harris

County, Texas. The Justice Information Management System Executive

Board oversees an integrated justice system through which all cases and

persons are processed and all enforcement, courts and corrections agencies

participate.

• Peter Houk, Chief Judge, Ingham County (Michigan) Circuit Court and

Michigan Court of Claims. Ingham County is in the final stages of issuing

a Request For Proposals for a system to integrate the data collection

processes in the sheriff and prosecutor offices and the District, Probate

and Circuit Courts.

• D. Kenneth Peters, Project Manager, Consolidated Justice Information

System, Kent County, Michigan. Mr. Peters is also Manager of the county

Office of Community Corrections. In this role he recognized the need for

justice information integration in 1990 and led the key players in the

justice system through a three-year development effort. The county is now

engaged in an 18-month, $4.5 million project to implement the system.

• Jay Donaldson, Director of Data Processing, Ingham County, Michigan.

The department is participating in the development project for a

countywide integrated justice system. Data processing is involved in

technical issues concerning hardware and software. Because the justice

system is spread over six campuses covering 18 miles, the integration

system will be installed on a wide area network.

• Meg McLaughlin, Associate Partner and member of the Justice and

Public Safety segment of Andersen Consulting. Ms. McLaughlin is the

coordinator of Andersen Consulting’s Integrated Justice Practice.

Andersen is partnered with the Departments of Justice and the Solicitor

General in New Brunswick, Canada, to examine the way in which they

currently deliver their services, and to reinvent the administration of

justice, developing a single “enterprise” with a uniform, integrated

operational framework.

• Mike Henry, County Coordinator, Berrien County, Michigan. The

Berrien County criminal justice information system has been integrated

since 1978. In 1992, the criminal justice agencies and information systems

went through a reengineering process to reconsider all the processes

involved. As a result of that process, the county transitioned to a Fourth

Generation Language, while completing the sheriff’s portion of the

upgraded system. The Courts’ and Prosecuting Attorney’s portion will be

completed and implemented during the third quarter of 1995.
Page 6 Chapter 2 — Introduction System Integration

SEARCH staff Robert L. Marx, Senior Systems Specialist, facilitated the workshop and

drafted this report. David J. Roberts, Deputy Director, Programs, participated in the

workshop and commented on the draft. Kelly J. Harris, Program Coordinator, assisted

Mr. Marx throughout the project.

SEARCH acknowledges with gratitude the contributions of all those who participated in

the workshop. We have tried to reflect the thoughts expressed during the workshop in

this report. But this is not meant to be a consensus document; workshop participants

reviewed and commented on a draft of this report, but did not “vote” on its contents.

SEARCH is fully responsible for the opinions expressed herein.

■ Project Funding and Support

The workshop, and the preparation of this report, were funded by a grant from the U.S.

Department of Justice, Bureau of Justice Assistance.
System Integration Chapter 3 — Scope of Integration Page 7

Chapter 3

Scope of Integration

■ Thinking About Scope

To begin to define the scope of the integration project, start with a blank sheet of paper

and follow this instruction:

Write the names of all those you consider to be in your family, and draw

a circle which contains all the names.

Perhaps the circle now contains the names of parents and children, aunts and uncles,

cousins, nieces and nephews, even close friends.

Now follow this instruction:

At the top of the sheet write this title: “My responsibility is to provide

financial support to my family” and change the circle as appropriate.

Perhaps the circle will get smaller. Your relationship to the persons outside the new

smaller circle is still a familial one, but they are “out-of-scope” with respect to the “goal”

expressed by the title. You will still have relationships, even important relationships, with

these out-of-scope people.

The analogy to county-level information systems is straightforward. The county-level

system has relationships with the state criminal history system, the state driver registry,

the state administrative office of courts, and other systems; however, most would agree

that these systems are “outside the circle.”

County government also has relationships with city-government agencies within the

county, for example, police departments and city courts. There is no nationwide consensus on whether these agencies are inside or outside “the circle.” Each county must make

its own decision, based on its own history, political philosophy, tax base and other

factors.

■ The Importance of a Scope Statement

Persons who participate in an effort to integrate an information system bring with them a

set of assumptions and expectations that arise from their own experiences and concerns.

For example:

• The felony trial court judge may have little interest in information

concerning municipal ordinance violations or traffic cases, while the

lower court judge may have a strong focus in these areas;

• The prosecutor may have strong interest in data originating in local

police departments, while the sheriff may not (or may); and
Page 8 Chapter 3 — Scope of Integration System Integration

• Each agency is interested in case management with respect to use of

its own human resources, while in general no agency is interested in

case management for other agencies except insofar as those cases

affect its own case management concerns.

At some point, preferably fairly early in the process of defining the integrated system, the

participants must agree to a statement of scope for the integrated system. In fact, the very

question of which agencies are participants in the process depends on the scope statement, which can only be agreed to by the participants. The problem is a circular one; that

is, the statement of scope depends partially on who is answering the question, but identi -

fying the persons appropriate to answer the question is partially dependent on the answer.

Nevertheless, the scope statement requires consensus. However, the timing of the

question is worth consideration. If the question is posed too soon in the process, there is a

danger that the discussion will destroy the incipient sense of community among the

participants before habits of joint decision-making are formed. If the question is posed

too late in the process, there is a danger that some participants may feel betrayed when

their (unvoiced) assumptions are challenged after consensus seems to have been formed.

One way to “sneak up” on the scope statement is by an effort to state the goal of the

system. One development methodology says that an appropriate system goal should be

stated in a single declarative sentence of not more than 15 words without commas or the

word “and.” A look at some alternative goal statements suggests the power of this

method to place in sharp focus differences in scope:

• Goal: The system will fulfill all information technology needs of all

justice components of county government; or

• Goal: The system will fulfill all information technology needs of all

justice components of county government except payroll ; or

• Goal: The system will fulfill all information needs of all criminal

justice components of county government; or

• Goal: The system will fulfill all information technology needs of all

justice components of governmental agencies within the county; or

• Goal: The system will fulfill all information technology needs

related to case management for all criminal justice components of

county government.

There are dozens, perhaps hundreds, of alternative goal statements like these, any of

which could eventually bear the title “Smith County Integrated Justice Information

System.” Yet the systems to meet these goals differ dramatically in coverage, cost,

complexity, agency participation, etc. A system designed to meet the last goal statement

above (case management for criminal justice) is perhaps one-tenth as complex or costly

as one designed to meet the first goal statement (all needs of justice agencies).

Note also that declaring an agency to be out-of-scope for the integrated system is not the

same as saying that such an agency is completely and permanently cut off from the

system. An out-of-scope agency, for example, can have inquiry-only access to the system

(that is, a local police department could be allowed to interrogate the court system to

determine if any of its officers is expected in court as a witness). An out-of-scope agency

can also transmit data to the integrated system by conforming to the data standards

published by the system management ( for example, a local police department could send

arrest data to the in-scope prosecutor screening function by dial-up or leased-line file

transfer methods). Thus, the scope decision is not quite as black-and-white as it seems at

first.
System Integration Chapter 3 — Scope of Integration Page 9

■ Scope: County-funded or County Borders

Some counties have drawn the scope circle in such a way as to include only agencies

entirely funded by the county tax base. Other counties have drawn the circle so as to

include both county government agencies and city agencies within the county. There is

no right or wrong decision, but there are factors to be considered, and the operational

utility of the system will differ depending on the decision made.

In Favor of Limiting Scope to County-funded

In many cases the strong a priori assumption is to build a system to serve the needs of

county-level agencies only.

Relationships among agency heads, the county executive and the county board of

supervisors are in place and tested. The “chain of command” is well understood and

precedents usually exist for multi-agency cooperative efforts.

A county information technology authority usually exists, county office buildings are

often already connected to a central site for data transfer, and standardization on

computer equipment, software and development tools have often been adopted and

enforced. Methods to maintain and extend the system once it has been implemented are

already in place.

Funding of system development and operation is simplified. If state or federal grant funds

are being used , a single entity (county board or county executive) can sign the

application, manage the expenditures and control contractual efforts.

In Favor of Broadening Scope to County Borders

There are major data flows between local police departments and the county jailer,

between local police departments and the county courts, between city courts and the

county courts, between city police departments and the county prosecutor. Serving these

data flows within the design and operation of the integrated system improves overall

efficiency and effectiveness.

A middle ground may be available. Some counties do the original development for

county governmental agencies only, funded by county funds but with local justice

agencies represented in a non-voting capacity on the committee. The technical design of

the system either (a) permits easy expansion of the system to allow additional agencies of

the pre-designed types ( for example, local jails that look like the county jail, local courts

that look like the county court, local police departments that look like the county law

enforcement capability), or (b) permits easy local-agency connection to the county

system for two-way information transfer between the system and the independent local

systems.
Page 10 Chapter 3 — Scope of Integration System Integration

■ Scope: Criminal Justice or Justice

Some counties have limited the scope to the criminal aspects of the justice system,

excluding activities such as divorce, torts and other civil functions. Other counties have

included the criminal and non-criminal aspects of all participating agencies.

Some counties have attempted to handle this decision by stating a long-term goal

encompassing the entire justice system, but setting priorities which funnel all resources

into the criminal justice side of the justice system until those needs are met, before

directing any resources to the broader set of requirements.

In Favor of Limiting Scope to Criminal Justice Matters

Most cross-agency data sharing occurs in the criminal justice area, so inter-agency focus

can be tightly focused, while allowing each agency maximum flexibility in defining its

own intra-agency needs and selecting separate paths toward fulfilling those needs.

In Favor of Broadening Scope to Include All Justice

Functions

The same judges, courtrooms, assistant prosecutors, police officers, private lawyers, etc.,

are involved in both criminal and non-criminal procedures, making it very difficult to

disentangle their activities without losing functionality (for example, discovering

schedule conflicts) desirable for the integrated system. In addition, the vast majority of

cases and resources in some agencies, particularly the courts, are devoted to non-criminal

justice matters (such as civil, probate, etc.).

Greater cost benefits can also be realized when more agencies participate in the

integrated system. One of the most common cost savings is the reduction of data entry

time and staff requirements. In addition, fees from civil cases may help to fund some

portions of the integrated system.

Much available software is designed to accommodate entire agencies, so limiting the

scope may not have any benefits in solutions involving purchased software.
System Integration Chapter 3 — Scope of Integration Page 11

■ Scope: Full Agency Information Needs or Case

Management Information Needs

In many cases the original impetus for change, or at least the early visualization of the

new system, involves a shared perception that agencies are entering and reentering the

same data in their independent systems, that is, the same defendant is entered into

systems of the sheriff, the prosecutor, the lower and higher courts; the same schedule

information is entered into many systems, as is the status and disposition data; the same

charge and disposition data are in several systems; and each agency is maintaining a

separate criminal history file.

Such duplicate data entry and storage occur primarily in the case management aspects of

justice information technology. A county can limit the scope of its integrated system to

these case management applications (or to set priorities such that the case management

functions are designed and implemented first).

In Favor of Limiting Scope to Case Management

The multi-agency decision-making structure that is needed to develop, implement and

operate an integrated system is a cumbersome vehicle for setting priorities concerning

functionality that affects only a single agency.

In Favor of Broadening Scope to All Agency Requirements

Many single-agency information requirements are very similar in all agencies, for

example, vehicle maintenance and facilities management. It may require little extra

multi-agency effort to design a “one-size-fits-all” solution to these requirements.

Some requirements that seem to be single-agency in nature are so closely tied to multiagency requirements that they cannot easily be separated. For example, victim rights

responsibilities often rest entirely on the prosecutor, but the type and timing of victim

notifications is highly dependent on events controlled by other agencies (for example,

court schedules, preparation of presentence reports by the probation agency, etc.). Some

jail functions (such as food services, personal effects accounting, cell assignments, guard

scheduling) stretch the concept of system integration even more.
System Integration Chapter 4 — Organizing for Change Page 13

Chapter 4

Organizing for Change

■ Gathering: The Initial Phases

One might think that the impetus for system integration is usually a top-down matter, in

which a county executive, or perhaps the chairman of the county board, requests

consideration of integration and convenes a group to study the matter with an eye toward

making a recommendation for appropriate action. This does not seem to be the normative

route to integration.

Rather, it seems that most integration efforts begin with a single person, usually a user

agency head but quite possibly someone lower in the organization chart, who feels a

strong sense of dissatisfaction with the current level of information services provided.

That person gathers some facts supporting his/her dissatisfaction and shares them with

others, often agency heads of the other user agencies, or at least of one or two other

agencies.

The sharing of “horror stories” may go on for some time, by telephone calls or informal

meetings. As a shared sense of frustration grows, additional members may be invited to

participate. There is little or no formal organization at this point, since decisions are

mostly of the finger-pointing variety rather than the action-plan variety.

In these initial phases, conversations may stay within functional areas. For example, the

sheriff may have conversations with local police departments, or circuit courts may have

conversations with district courts. When many of the agency heads are elected officials,

the sense of frustration may be more intense, but the reluctance to “go public” with the

frustration may also be heightened.

It may take six to nine months of such informal sessions before the mood shifts from

blame-fixing to problem-solving. At this point the group may feel the need for more

formality. They may choose a name for their group. They may invite broader

participation so that all appropriate agencies in the county are represented. They may

reach outside for a grant of authority to do something to alleviate their frustration. There

may be discussion about who may represent an agency during meetings, whether one

agency may obtain a proxy vote on behalf of another, whether items not on the agenda

may be voted upon.

■ Leadership and Authority

Leadership in the Original Phase

For most counties, leadership during the first phase of inter-agency cooperation is

charismatic rather than authoritative. Since the incipient multi-agency committee at this

stage often has no “standing,” the committee proceeds by consensus, often effectively

requiring unanimity as the discussion proceeds.
Page 14 Chapter 4 — Organizing for Change System Integration

Often the person who convenes the first meeting acts as the leader. There are no votes,

just discussion until a consensus is reached as determined by a spontaneous change of

topic. Focus is often on a “gripe list” which acts as the main source of energy for the

committee. Formal words like “vote” and “minutes” are avoided, although “meeting

notes” and other substitute terminology is employed. Committee membership is informal

and may fluctuate, and some time may be spent discussing who should be invited to

attend and who should not be.

Leadership in the Middle Phase

At some point the committee needs authority, perhaps to hire a facilitator or consultant,

or to address the county board. At this point the committee often starts to take on some of

the trappings of ordinary governmental inter-agency cooperative efforts.

Sometimes the “outsider” approach to legitimize the committee is the director of

information technology. In some ways this is the most straightforward method. The

director usually has the right to convene users to consider alternatives to present methods

of delivering and receiving services. The director can organize such a committee,

defining its scope, appointing a chairperson or allowing election of one, and setting a

meeting schedule. The director usually has direct access to the county executive and to

the county board, and easily could delegate this authority to the committee.

But in many cases this is not the path chosen. Individual user-agency heads themselves

have the needed direct access, and may not choose to subjugate the committee to the

information technology agency. In some cases the computer services agency, or its head,

has already been demonized by the committee in the initial fault-finding phase of its

existence. In these cases, the request for standing and authority is usually made to the

county executive or the county board.

This first request for standing and authority sometimes, but not always, is accompanied

by a request for funds. Not funds to develop and implement a system, of course, but

modest funds to support the workings of the committee in the next phases.

Committee membership and participation may change during this phase.

• Heads of local justice agencies within the county may be invited,

perhaps as non-voting members.

• The county executive or a member of the county board may become

members, again perhaps without voting privileges.

• The public defender and/or a representative of the local private bar

may be invited as members, non-voting members or non-member

participants.

• Local representatives of state-level justice agencies may be invited to

attend.

• Vendors with specific knowledge about key technologies may be

invited to attend or to address the committee.

• The distribution list for meeting minutes and committee reports may

expand.
System Integration Chapter 4 — Organizing for Change Page 15

More formality may emerge at this point.

• Membership classes may emerge: a voting class for real system

participants; and a non-voting class for interested outsiders ,

including persons associated with funding sources, representatives of

interfacing systems at the state and federal level, and local agencies

within the county.

• The committee may elect a chair, or the person providing the

requested authority may appoint one.

• Some attempt is often made to write a “mission statement” for the

committee.

• A decision-making method will emerge; discussion will focus on

whether agency heads must attend or whether they may send

representatives, whether or not the director of information

technology is a voting member, whether decisions can be vetoed by

any member.

• A structure may emerge, possibly with a head-of-agency committee

and a lower-level committee which does the more technical tasks and

brings subjects to the committee for resolution.

The committee may engage paid help. This may be a facilitator , needed to get or keep the

committee on track and possibly to bridge over certain inter-personal difficulties among

its members. Or it may be a development consultant to guide the committee through a

structured methodology (for example, Reengineering, Design with a Human Face, or

Structured Design Methodology) which might not be known to the members. Or it might

be a technology consultant to counsel the members on what software packages are

available, what new hardware and software developments could be appropriate for use in

the county, or initial cost estimating of alternative solutions. 1

A full-time or nearly full-time person to act as internal visionary and evangelist for the

project often emerges at this point. The work of moving the project forward, drafting the

meeting agendas and the meeting minutes, keeping heads of agencies interested and

motivated, getting past the unavoidable conflicts and disagreements, usually requires

more time than a head-of-agency can provide. Often this full-time person comes from the

staff of the committee chairperson; other times it comes from the information technology

agency. It is a key position which materially affects the probability of success for the

project.

Leadership in the Operational Phase

When the system becomes operational, the technical leadership usually reverts to the

agency which provides information technology services.

 

1

 We use the term “facilitator” to describe a person with specialized skills in interpersonal

relations, which is useful to construct an atmosphere of collegiality in which decisions can be

made and implemented. We use the term “consultant” to describe a person with specialized skills

in some technical area important to the success of the integration effort. A single person can be

both a facilitator and a consultant.
Page 16 Chapter 4 — Organizing for Change System Integration

Interagency participation in the management of the system is still required, however. If

any agency identifies a new data requirement, the other agencies need to be involved in

the format and content of that data; the new data may originate within another agency

and thus be “owned” by that agency (the concept of data ownership is discussed in

Chapter 6). Or the new data may be of use to other agencies, and thus subject to

negotiation on its form and content.

System performance needs to be measured and corrective steps supported. For example,

system “crashes” may be hindering operations, or system response time may be affecting

employee productivity, or priority-setting in the competition for maintenance

programmer time or allocation of workstations to agencies may pit one agency against

another for scarce resources.

The organization required for such oversight of the operational system is likely to be

different than for earlier phases of the system: fewer head-of-agency meetings and more

technical subcommittee meetings reporting to the heads; more reliance on county staff

and less on consultants; more communication in writing and less by face-to-face

meetings.

The management needs and structure are changed, but not removed. Operational multiagency systems need a continuing multi-agency forum lest they result ultimately in the

same frustrations that led to the development of a new system in the first place.

■ Defining the System Goal, Objectives and Tasks

The newly formalized committee may require a meeting or two to settle into its new

authority and responsibilities. Each member may want to make an extended “opening

statement.” Very soon, however, the committee will take up the question of functionality

— just what is it that the new system will do.

There are many alternative ways of developing the list of things to be done by the

integrated system. A county may choose from among these alternatives based on the

experience of the participants or the standards adopted by the county or its contractor.

But the adoption of some method is imperative. We discuss two methods.

Defining system tasks is hard work. Some committees have tried to avoid it with blanket

statements; for example, that the new system will “preserve all existing functionality

while minimizing duplicate data entry.” We do not believe that such an approach can be

successful; it is the detailed statement of functional requirements which permits full

informed consensus within the committee, allows accurate cost estimates for system

development, and permits meaningful project management and system evaluation

throughout its life.

One Method of Defining System Tasks

This method involves:

• The statement of a single goal . The goal should be stated in a single

declarative sentence of 15 words or less without commas or the word

“and.”

• The statement of a set of objectives, each in the format specified

above for the goal, such that accomplishment of each and every

objective will also result in achievement of the goal.
System Integration Chapter 4 — Organizing for Change Page 17

• For each objective, the statement of a set of sub-objectives, each in

the format described above for the goal and so chosen that the

accomplishment of each and every sub-objective will also result in

the achievement of the objective.

• Further subdivision of sub-objectives, perhaps several times. The

final, most detailed level of sub-sub-objectives is called the layer of

“atomic tasks.” It is the atomic tasks that define the functionality of

the integrated system at a level suitable for programming.

The process is meant to ensure that there is real agreement among the participants

concerning the tasks (atomic tasks in the jargon of this model because they are not easily

further subdivided) under the control of the committee. In system design, as in contracts,

“the devil is in the details.” The rigid outline-style hierarchy of functions permits a

rigorous review. Is everything we now do handled in this new model? Is my agency

getting all the data it needs from other agencies? Are we able and willing to collect and

share all the data that other agencies want from us? Will we be able to meet all our

responsibilities to outside agencies for data, records, statistical reports?

Another Method of Defining System Tasks

This method focuses on specific cases, “walking through” each case and recording those

places where information becomes available and where information is needed. The

process proceeds along these lines:

• Pick a “typical” case. Let us say that we choose a specific breakingand-entering offense.

• How does the case enter the system? Let us say there is an on-sight

arrest during the offense, followed by booking into jail. What

information is available at this point which will be needed later in the

process? What information is needed at this point? What information

must be reported to outside agencies at this point?

• What happens next? Let us say the prosecutor screening function

occurs next. What new information becomes available at this point?

What information which was available at a previous point is needed

at this point? What information must be reported to outside agencies

at this point?

• And so on for each succeeding function. There are, of course,

branches in the process flow, for example , pleas before trial,

dismissals during trial. These branches need to be traversed and

recorded in the single case or in succeeding cases.

The result of this method is a description that shows the gradual growth of knowledge

about a case as it progresses, the intra- and inter-agency use of this knowledge, and the

most efficient sources of each piece of knowledge.

An Eclectic Method of Defining System Tasks

The first method offers the advantage of proceeding from the universal to the specific.

The outline structure of the resulting definition is well suited to the later tasks of

technical design and program development. It carries with it the disadvantage of

requiring a facility for rather abstract thought which may prove difficult for some

committee members.
Page 18 Chapter 4 — Organizing for Change System Integration

The second method offers the advantage of proceeding from the specific to the universal.

The case-oriented structure makes it easy for practitioners to visualize the data

environment and apply their experience. It lends itself nicely to questions like “Why do

we do things this way and can/should we change our methods?” It carries with it a certain

lack of structure which makes it difficult to know how “typical” the typical cases chosen

are, how many cases and of what kind should be analyzed, and when the process should

be declared finished.

An eclectic method could borrow from both these methods. For example, the first method

could be followed from beginning to end; then typical or randomly selected cases could

be used to test the completeness of the atomic task list that has been generated. This

could proceed a few times until the committee is satisfied that the task list adequately

describes the functional requirements of the new integrated system.

■ Defining the Development Timetable

The first 90 percent of the system development requires the first 90 percent of the allotted

time; the last 10 percent of the effort requires the other 90 percent of the time.

No one ever lost his job for completing an assigned task ahead of schedule.

The earliest phase, sharing of frustration and forming the resolve to do something,

seldom takes less than six months and often takes a year. After a year, the parties should

decide to do something or stop talking about it.

The middle phase, in which the committee organization becomes established and the

basic decisions are made concerning system scope and development mode, often takes a

year or a year and a half. Interim milestones can be set during this phase. The final

milestone of this phase usually defines the point at which development decisions shift

from the policy-oriented ones to more technically-oriented ones. Hiring a system

developer or system integrator, or publishing a procurement for system development are

typical endpoints.

The third development phase involves development of the system, installation, testing

and acceptance. Two years is not an unusual duration for this phase. Depending on

whether the development proceeds agency-by-agency, or function-by-function, or phaseby-phase, different milestones occur, but many interim milestones can be set and

reviewed during this phase. System acceptance is the most typical end-point to this

phase.

A very worthwhile but often ignored interim product of the development phase is the

prototype. A prototype of the entire system, or of selected parts of it, can be built using

low-cost computer equipment and advanced software tools. The prototype should include

all data entry screens and a small database. Users of the future system should “walk

through” several cases to see how the system will support them; changes in the

specification of the real system should be recommended following this use of the

prototype.

The final phase involves ongoing operation and oversight of the system. In some cases

this phase overlaps the third phase as various portions of the system are brought into

operational use. There is no escape save death or retirement from this phase.
System Integration Chapter 4 — Organizing for Change Page 19

■ Establishing a Review Process

Guarding Against Going in Circles

The committee should establish a decision process which provides a “ratchet effect” to its

processes. For major decisions, a formal motion, in plain and precise language, assures

that all participants understand what is about to be agreed to. Meeting minutes containing

these motions and the decision reached on each one assure that decisions, once made,

remain intact.

Guarding Against Marking Time

Even in the earliest stages the committee should try to state task objectives for itself and

set deadlines for task completion. Even wildly optimistic schedules are better than no

schedules at all. It may be neither possible nor desirable to plan out the entire

development effort while in its earlier phases; the committee has too little experience

with the subject matter and with the dynamic of the committee decision-making method.

So, in the early phases, it may be most appropriate to look only one or two tasks ahead;

for example, from the list of “big decisions” discussed later in this report, the committee

may decide to explore one, say the role of legacy systems, and make a decision on it

within two months of the first meeting.

Later in the process, the committee will be able to look several tasks ahead, eventually

working with a schedule for the entire developmental process with interim deadlines and

a final date of operational use of the integrated system.

Guarding Against Stubbornness

Schedules and deadlines provide a valuable occasion for reappraisal. There is no shame

associated with discovering that the project has gotten off course, or that the original

course was incorrect. At several points along the developmental path it is necessary to

ask these questions:

• Is the system goal we have stated still the goal we want to pursue?

• Do the objectives, sub-objectives and atomic tasks we have listed

still state accurately and completely the functional requirements of

the system we are building?

• Do the policy decisions we have made to this point optimize the

probability that we will achieve our goal?

• Do we (still) have the support we need from the funders and users of

the system, and what must we do to get or retain that support?

• What is the next task we should do to move toward our goal, what do

we need to do it, and when can we realistically expect to complete

the task?
System Integration Chapter 5 — The Big Decisions Page 21

Chapter 5

The Big Decisions

■ System Characteristics

The statement of goal and objectives anchors the project in the sense of defining what the

system will do. The system characteristics define how the system will do those things.

The system characteristics may apply only to new portions of the system (when parts of a

legacy system are retained). The list here is only an example from which the committee

should develop an appropriate list for its own use and for inclusion in any task statements

for development issued by the committee:

• The system will provide on-line documentation, including “help”

screens;

• All data entry will be edited before acceptance by the system;

• The system will provide on-line data entry without intervening paper

forms wherever feasible;

• To the extent feasible, each data element of the entire system will be

entered only once;

• The system will provide a single integrated calendar, with several

views of the schedule data corresponding to the needs of the

system’s users;

• The system design will accommodate future changes in the structure,

coding and content of the database;

• The system will provide a capability to retrieve and summarize data

in a variety of ways, including ad hoc reporting features;

• The system will provide for its own audit, including the production

of adequate audit trail data;

• and so forth.
Page 22 Chapter 5 — The Big Decisions System Integration

■ The Role of Legacy System Environments

Legacy: Anything passed on from an ancestor, predecessor or earlier era. Things change

rapidly in the computer industry. Large water-cooled power-hungry mainframe

computers are being replaced in many applications by small fan-cooled efficient mid-size

computers or networks of desktop computers. Proprietary operating systems and program

languages that work on just one manufacturer’s hardware are giving way to more

generalized software environments that can be moved easily from the equipment of one

manufacturer to that of another. Arcane and hard-to-maintain application languages like

COBOL are gradually being replaced by equally arcane but easier-to-maintain languages.

Indexed file structures are being eschewed by many software developers in favor of the

new relational database model or the even newer object-oriented database model.

We are not prepared to say that a legacy hardware and software environment is always

inappropriate for a new major application like the integrated justice information system.

However, we do believe that the burden of proof is on those who support the legacy

system to describe how that provides higher total lifetime value to the system users.

Advantages of Legacy System Environments

Perhaps the present computer is paid for and essentially “free.” Even though the

operating costs of the present system could be higher than the operating costs of new

equipment, the total annual costs of the present system might be lower than the total costs

of a new system.

Perhaps there are many other applications (payroll, water billing, general accounting)

which must remain on the old equipment for an extended period, so that the floor space

or electrical savings cannot be “captured” by placing the integrated justice system on a

new computer.

Perhaps a loyal and competent staff is unwilling or unable to make the significant

transition effort.

Perhaps the integrated system will build strongly on an existing system implemented on

the legacy system, or the new system, bought or transferred from another county, runs

only on the legacy system.

Advantages of Newer System Environments

Equipment purchase cost, floor space and electrical requirements are all more favorable

using the new hardware platforms. Savings in these areas can sometimes justify the entire

development cost for new software.

Because new software tools provide more flexibility in changing functionality and

database configuration, total lifetime software costs will probably be lower, even after

consideration of a significant “learning curve” for the software maintenance staff.

The use of graphical user interfaces, often associated with newer system environments,

can lead to lower training costs and more efficient data entry for the system (but

graphical interfaces are becoming available for more traditional system environments as

well).
System Integration Chapter 5 — The Big Decisions Page 23

■ Unification or Coordination

Two models of an integrated information system can be identified in the work of counties

so far.

In the first of these models, a single design concept is developed to meet all the

functional requirements. Usually a single design team, a single development team and a

single programming team are responsible for the entire project. Often, but not always, the

design incorporates a single database, housed on a single computer, and a single

programming language and programming software tools. The “intelligence” of the

system may be distributed among smaller computers at the user sites, or may be

centralized. We will call this the Unified Integrated System model.

In the second model, the design concept follows more closely along agency lines, with a

separate subsystem for each agency and another subsystem to handle the inter-subsystem

data flows. Some of the subsystems may be purchased, others transferred from other

counties, others retained in service (for the time being) by the county, and others

developed “from scratch” by the county. The agency-level applications may run on

different equipment platforms, with different operating systems and computer languages,

with different data structures. The disparate subsystems may agree only on the form and

content of sharable information which is passed between them; this data sharing may use

the standard inquiry methods of each subsystem or may involve no-human-involved data

transfer from one database to another. With this model, detailed testing is critical to

ensure that the disparate systems can share data as expected and required. We will call

this the Coordinated Integrated System model.

Note that either model can lead to drastic reductions in duplicate data entry. Either can

reduce the amount of duplicate data storage. But a decision in this area can constrain

decisions in other areas; for example, a county probably cannot decide to develop an allagency system of the unified integrated type and conduct the procurement by buying an

off-the-shelf software product; there are, we believe, no such products.

Advantages of Unified Integrated Systems

Precisely because a unified system is the product of a single design concept, it is likely to

have the same look and feel in all its components, which may lead to lower training costs

throughout its lifetime.

Because there is a single database design, it is less likely that the linkages between

components will get out of synchronization. For example, if the prosecutor changes the

length of the Last-Name field from 20 characters to 18, that change is more likely to be

propagated through the entire system before mischief is done to other portions of the

database.

Because there is a single language, single set of development tools and single design

philosophy throughout, there is more chance for cross-training the maintenance staff,

resulting in lower programming costs throughout the system life.

Advantages of Coordinated Integrated Systems

The development cycle as perceived by the users may be shorter because individual

agencies already satisfied with their intra-agency solutions can keep those systems; the

coordinating software can be developed “behind the scenes.” Purchased or transferred

systems, which typically do not serve the needs of the entire justice system, can be used

and tied to other systems (either ones also purchased or transferred, or ones developed

specifically for the county). This may shorten the development cycle, minimize downside risk for the project, and make development costs more predictable.
Page 24 Chapter 5 — The Big Decisions System Integration

■ Step-phased or Application-based Development

A step-phased development proceeds on a countywide level. The functional requirements

for all agencies are determined first. Then the technical requirements for all agencies are

done. Then the conceptual designs for all agencies are done. Eventually the

programming, testing, acceptance and use of the entire system is done, with operational

use of the system being approximately contemporaneous for all users.

An application-based development proceeds on an agency level. First, the entire

development process is performed for one agency and that agency begins operational use.

A second agency is chosen and the entire development process is undertaken for that

agency, resulting in its operational use and integration with the first agency. The process

continues in this way until all agencies have been developed and integrated, and all

agencies are using their portions of the new system.

No real-world project exactly fits either of these descriptions, which represent the endpoints of a continuum. Even in extreme step-phased developments, cutover to operational

use is usually done on an agency-by-agency basis to avoid chaos. Even in extreme

application-based developments, some effort is devoted to “peeking ahead” at the

requirements of other agencies as the design of the first agency proceeds.

Advantages of Step-phased Development

A step-phased development avoids the sensitive question of which agency is first in line.

All agencies remain equally focused on assuring that funding flows over the several years

needed for completion of the project. All agencies are assured that they are receiving the

same level of system — early agencies do not receive “Cadillac” systems while later

agencies are stuck with “Yugo” systems to make up for earlier overspending.

A step-phased development minimizes the chance of a major misstep (for example,

forgetting a major information need of a “later agency” while developing the data-capture

portions of an “earlier agency” system) which may require a rewrite of a just-completed

system at additional cost.

Advantages of Application-phased Development

An application-phased development provides early tangible results, which provides

encouragement to the participants and also to funding parties.

An application-phased development allows the committee to learn from the early

developments and apply these lessons to the later agencies. Lessons might include the

accuracy of cost estimates, the suitability of certain contractors or employees to carry

major responsibilities, importance of the user interface and other design features to

overall system efficiency, and the accuracy of project schedules.
System Integration Chapter 5 — The Big Decisions Page 25

■ Automation or Reengineering

Automation involves the computerization of present methods and procedures. The

analysis steps focus on the paper forms and data entry screens now in use. Focus is on

process rather than on decision points.

Reengineering proceeds from the question: “If we didn’t have any historical ‘baggage,’

how would we organize our resources to accomplish our goal, what information would

we require and how would we obtain and deliver that information?”

These are in fact the endpoints of a continuum. Pure automation would not consider

integration as an option (since the present systems are not integrated). Pure reengineering

would not allow even a peek at present forms and reports, which represent the

accumulated wisdom and frustration of the people who actually do the job today.

Advantages of Automation

The requirements phase of an automation project is very straightforward: assemble

copies of all present paper forms and data-entry screens, query screens and printed

reports. These become the data requirements of the new system. It remains only to decide

which agency contributes each element and to negotiate differences in data formats and

definitions.

Initial training and user adaptation is minimized because the new system will resemble

the old system in most respects.

The down-side risk of “missing the point” in some important respect is minimized.

Advantages of Reengineering

The possibility of making a large-scale leap in employee productivity is increased.

The shift of focus from process to decision points allows consideration of alternative

ways of making those decisions. For example, automation of the arraignment process

presupposes that the process involves assembling the various people in one place at one

time; reengineering forces consideration of the purpose of arraignment, and thus allows

consideration of alternative methods of achieving that purpose, such as video

arraignment.

Combining the automation and reengineering approaches represents a broad, middle path

toward improved systems. Present operations are referred to throughout the development

process as a way to ground the work in reality, and, at the same time, extensive thought

about the purpose of present procedures and possible alternative methods of achieving

those purposes is encouraged .
Page 26 Chapter 5 — The Big Decisions System Integration

■ Inside or Outside Development

Inside development is performed by county employees under the direction of the

information technology department of the county.

Outside development is conducted by contractor employees. The contract may be under

the control of the information technology department or the county executive.

A middle ground is available. Sometimes a joint team of employees and contractors is

established. The members work together, sometimes in the same facility, and share in the

development, design, coding and testing.

The committee may play an advisory role in either case. The committee may advise the

director of information technology, the county executive or the county board. Because

the committee consists of agency heads, the advice will command attention and response.

Advantages of Inside Development

The same staff that designs the system will eventually maintain it, so the motivation for a

robust and flexible design is strong.

The development staff is always on-site, making formal and informal communication

between the developers and the users efficient and effective. This option may not always

be practical, however, as many agencies lack the resources to dedicate existing staff to a

specific project.

Advantages of Outside Development

The development staff may have more up-to-date skills in modern development

techniques and programming tools.

The arms-length contractual relationship raises the probability that the final result of the

process will resemble the initial concepts mutually agreed to early in the development

process, or that changes of concept and functionality are documented in the form of

Engineering Change Notices and contract modifications.

Through contractual terms (including progress payments, penalty clauses and

performance bonuses) the county can keep the contractor tightly focused on this project.
System Integration Chapter 5 — The Big Decisions Page 27

■ Build, Buy or Transfer

To build a system means to conduct all phases of development without consideration of

subsystems available from alternative sources; note, however, that the building may be

done as an inside development effort or an outside one, as those terms are discussed

above.

To buy a system means to purchase “packaged” software from a commercial source,

along with the modification effort required to tailor the software to the specific needs of

the county. The purchase price may include all hardware, software, training and

installation (turnkey procurement) or significantly less.

To transfer a system is to obtain the software from a governmental agency already using

it, and modify it as necessary using in-house or contractor programmers.

Advantages of Building the System

The system can be designed to accommodate exactly the current requirements and

preferences of the using agencies.

As requirements and procedures change, the development staff is available for program

maintenance.

Advantages of Buying the System

The county is able to examine the software, already running in another county, to assist

in the evaluation and in stating the required modifications.

Documentation tends to be better.

Although modification of the software often is restricted by the license agreement, there

is sometimes a user group which determines priorities for software enhancements.

Overall software maintenance costs may be lower than experienced in in-house packages.

Advantages of Transferring the System

The county is able to examine the software, already running in another county, to assist

in the evaluation and in stating the required modifications.

Depending on the need for modifications, it may be the least expensive alternative.

The county assumes complete and unrestricted ownership, including the right to modify

the software as it deems appropriate (but these systems are often inadequately

documented).
Page 28 Chapter 5 — The Big Decisions System Integration

■ How to Manage the New System

Management of the operational integrated system is a part of the system design.

Software Error Correction

Software performance which is different from the system documentation is called a bug

and is corrected by a process called debugging. (Software performance in accordance

with the documentation but different from user expectations is called a feature and is

changed by a process called maintenance.)

Who is responsible for debugging the software? It may be the county information

technology organization, or the contractor that wrote the software, or a third party

contracted for that purpose. Sometimes debugging is performed without charge by a

contractor for an initial period following installation (the warranty period), and then by

another party later. This decision is needed early enough to be incorporated into the

contract if there is one; it affects the need for access to the system’s source code, training

of resident staff personnel, and other factors.

Software Maintenance

Almost immediately after the first operational use, some external requirement will

change, or a user agency will decide it needs a new capability, or an operator will make

the point that a certain task could be done more efficiently or effectively. Any of these

cases may lead to software maintenance, the technical task of revising an existing feature

of the software or adding a new feature.

Who will decide on the desirability of each new or revised feature? Perhaps the user

agency head will be empowered to decide for features which do not affect shareable data,

and the committee will decide in cases that do affect other agencies.

Who will decide the priorities of new or revised features when several user agencies are

competing for the scarce resource represented by the staff (or budget) assigned to system

software maintenance?

The concept of maintenance also extends to equipment devoted to the system. Color

displays and printers, document imaging and videoconferencing all represent potentially

major expenditures. In a pre-integration setting, each agency would probably place itself

in competition with all other agencies to obtain the necessary funding; in the integration

environment, on the other hand, it is probably more likely that an agency which

wants/needs a substantial increase in capability will have to work through the multiagency committee structure to form a common position with which to approach the

county board and other funding entities.

General System Management

Maintenance programmers often spend much of their working time in the user agencies.

Should the user agencies have a say in their job reviews and possibly in their salary reviews?

Should the costs of operating the system be handled as a charge-back from the

information technology organization, or as a line item in the user agency budget, or as an

item in the information technology budget? If the user agencies are shown as the budget

“spenders,” what rights do they have to set the amounts and control the expenditures,

including the possibility of spending it outside the information technology organization?

We do not bring a set of “right answers” to the discussion of system management. We are

confident, however, that the “right answers” of the previous non-integrated systems may

not be appropriate in the new integrated environment. And we are confident that the

committee has a responsibility to consider the issue; the final decision may well rest with

the county board.
System Integration Chapter 6 — Sharing Data Page 29

Chapter 6

Sharing Data

■ Reasons for Data Sharing

Among persons considering integration or in the early stages of integration, the reason

most stated for data sharing is to avoid the unnecessary labor costs of duplicate data

entry. The duplication is real and the labor cost savings can be substantial, although the

labor is usually used elsewhere in the user agencies.

Among persons with longer experience with integrated systems, other reasons for data

sharing are often mentioned. The data is more accurate when entered only once. Often it

is available on a more timely basis because data collected at the earlier processing stages

becomes available to the later processing stages before those processes even begin. The

data may be more complete because the responsibility for collecting and entering each

data element is firmly fixed with a specific agency.

■ Concepts of Data Ownership

The purpose of declaring ownership is not to complicate the sharing of data among

agencies; such sharing is the main advantage of an integrated system. On the contrary, it

is to assure that the data which is to be shared is from the most credible source available

and thus most likely to be complete and accurate.

In single-agency systems, the question of data ownership does not arise — the agency

that owns the system also owns all the data in the system; it can create, review, update or

delete any data about any subject in its files. In a multi-agency system it is appropriate,

even necessary, to set rules about what agency can create, review, update and delete.

(Note that this is not the same as the security issue, which is concerned with what

persons can create, review, update and delete data.)

The most general rule of ownership is this: the agency that controls the event which gives

rise to the data, creates the data. Thus, in general, the jailer creates booking data, the

prosecutor creates case-screening data, either the prosecutor or court creates charge-filing

data (probably more often the court), the prosecutor creates some final disposition data

(for decline-to-prosecute dispositions) and the court creates the rest. The group must

agree on which agency is responsible for each data entry task and should be made part of

the system design.

The second rule is this: In general, the agency that creates the data owns the data. There

are some exceptions to this rule (for example, the data element called “current charge”

may first be filled with information from booking, then from filing, and finally from

disposition, which may involve several different agencies).

The third rule is this: the agency that owns the data decides whether or not the data can

be shared by other agencies, and by which ones. These data-sharing decisions are

incorporated into the system and control the technical access to the shared databases.

The fourth rule is this: the agency that owns the data controls the updating and deletion of

the data. Normally this power is not delegated to other agencies.
Page 30 Chapter 6 — Sharing Data System Integration

■ Sharing Person Descriptors

Agency Employees

This category of persons includes data entry operators, law enforcement officers,

assistant prosecutors, public defenders, judges, probation agents and others who (a) are

employees of user agencies and (b) are repeatedly involved as the source or destination of

data for the integrated system.

Information about these persons is usually kept in tables within the integrated system;

reference to these persons within the system is often by some unique identifier associated

with the person, such as a police badge number. Data from these tables is used to edit

other data entry, to generate system reports, and to notify participants in various process

events.

The employing agency is usually responsible for maintaining the system table of its

employees, and exercises data ownership rights involving the ability to create, update and

delete entries in that table.

Quasi-employees

This category includes private attorneys, providers of defendant assessment services,

providers of corrections alternatives and others who (a) are not employees of user

agencies but (b) who are repeatedly involved in process events covered by the integrated

system.

Information for these persons is also kept in system tables, but usually the tables are

maintained by one of the official user agencies; the prosecutor, courts and correctional

agencies often are assigned responsibilities for table maintenance.

Parties to Cases

This category includes civil plaintiffs and defendants, criminal defendants, civilian

witnesses, and victims. Some of these people are repeatedly involved (for example,

recidivist defendants) while others are engaged in a single case.

Information for the one-time persons in this category is owned by the agency that first

entered the data. Information for repeat persons in this category is owned by the agency

that first entered the data in the earlier case(s). The methods used to link a person from an

earlier case to the person in the current case will vary from one system to another (for

example, fingerprint-supported identification number, similarity of name and

biographical data, self-admission by the subject) and should be stated and enforced by the

system design.

Non-personal Resources

Organizations like halfway houses, group homes, twelve-step programs and elder-care

facilities have a role analogous to private attorneys; they are involved continually in the

justice processes. User agencies that employ the services of such agencies can be

assigned the responsibility of maintaining a current list of them within the system.
System Integration Chapter 6 — Sharing Data Page 31

■ Sharing Case Descriptors

Case Number

The problems associated with case numbers are numerous and serious. Traditionally,

each agency — police, prosecutor, lower court, upper court, corrections — had its own

case number sequence. Some counties have tried to preserve this tradition, building with

their integrated system a cross-index of case numbers that relate the various numbers;

others have attempted to assign a single and pervasive case number at the time of case

initiation.

Problems occur when police use the same case number for all persons arrested for a

single incident-case-number; when prosecutors combine two police cases involving the

same person into a single prosecutor case number; when lower courts combine two

prosecutor cases into a single court case, then acquit or dismiss on some charges and

forward other charges to higher court. The chances for mischief are endless.

The problem of linking one active case to another through a common subject, and of

linking an active case to historical case records through a common subject, raises

additional issues of fingerprint-based positive identification.

Event List and Event Descriptors

There are several types of cases which might be within the scope of the integrated

system: traffic cases, infractions, misdemeanors, felonies, torts, divorces, wills, and so

forth. Each case type has associated with it a case flow diagram which shows the possible

events for that case type, the possible outcomes to each event, and the event connectivity

(that is, for each position in the case flow diagram, what events can immediately follow

the event being considered).

Typically, an event is described by noting its case number, time and place, the persons

present, the event-type, the outcome, and the (scheduled or non-scheduled) next event

anticipated.

Charge Descriptors

The justice system is organized around codified rules: the state penal code, administrative

code, traffic code, local ordinances , and so forth. The individual provisions of these

codes are almost always identified by a unique numerical descriptor (for example, the

state penal code citation). Borrowing the terminology of the criminal portion of the justice system, we refer to all these code references as charge descriptors. Outside agencies

sometimes require reports that aggregate many citations into a single category; for

example, the state criminal history repository may want to lump all burglaries

(residential, commercial, day and night) into a single category.

Disposition Descriptors

Disposition refers to the final outcome of a case (where “final” is often interpreted to

mean short of any appeal which might be undertaken). Outside agencies often have an

interest in dispositions, and impose coding structures on the reporting of them. For

example, state criminal history repositories, state administrative office of courts and state

department s of motor vehicles may all require reporting of the same case disposition, but

impose different coding requirements. The disposition coding scheme of the integrated

system must be robust enough to allow translation from its structure to several others

depending on the intended recipient.

Considered on a nationwide basis, there is no end to the variations on the theme of

disposition. Some counties have judgment without sentence, some have sentence without

judgment, some have suspended imposition of judgment or probation as a condition of

acquittal. System design continually pits the logic of computer programmers against the

ingenuity of legislators and judges.
System Integration Appendix — Glossary Page 33

Chapter 7

Appendix

■ Glossary

This glossary is meant to indicate the way in which the terms are used in this report. For

more general definitions of the technical terms , we suggest the use of a good technical

dictionary.

Automation The computerization of present methods and procedures. The

analysis steps focus on the paper forms and data entry screens now

in use. Focus is on processes presently used to achieve objectives

currently defined. Compare to reengineering.

Consultant A person with specialized skills in some technical area important to

the success of the integration effort. Compare with facilitator. A

person can be both a facilitator and a consultant.

Coordinated Integrated

System

A system comprised of relatively separate subsystems, each

designed primarily to meet the objectives of a single agency and

joined together to meet shared objectives. Compare to unified

integrated system.

Criminal Justice System That subset of the justice system which is in direct support of

objectives related to the state penal code, or other state and county

codes which carry a criminal sanction. Sometimes includes all or

some of the traffic code. Compare to justice system.

Facilitator A person with specialized skills in interpersonal relations, useful to

construct an atmosphere of comity in which decisions can be made

and implemented. Compare with consultant. A person can be both a

facilitator and a consultant.

Flat Files A file structure which emphasizes non-redundance of data storage

and computational efficiency at the expense of reduced flexibility in

response to future needs for changes in the database structure or

content. Compare to relational database and object-oriented.

Indexed Files See flat files.

Integrated System A computer system (see definition below) which meets the needs of

more than one agency, as in integrated justice information system or

integrated criminal justice information system. See unified

integrated system and coordinated integrated system.
Page 34 Appendix — Glossary System Integration

Justice System The combined objectives and functions of police departments, the

sheriff, the prosecutor, all courts, pretrial services and correctional

agencies within a county. Sometimes used to include the public

defender. Rarely used to include criminal-trial attorneys. Compare

to criminal justice system.

Legacy System Computer equipment, software languages and development tools

which involve proprietary (not “open”) hardware architecture and

operating system software, flat files (not relational or object-oriented

database structures), and non-graphic user interfaces. Often but not

always used pejoratively.

Object -oriented A method of organizing data and program elements which

emphasizes data integrity and the ability to maintain programs over

an extended life. Compare with indexed files and relational

database.

Reengineering Design or redesign of a system using a process which emphasizes

the objectives to be attained and methods now available to attain

them, while de-emphasizing past methods, organizational

boundaries and history of the present system. Sometimes called

blank-sheet-of-paper design. Compare with automation.

Relational Database A method of organizing data which emphasizes ease of adding new

data elements to the structure later in the life of the database, at the

expense of increased computational complexity within the software.

Compare with indexed files and object-oriented.

System A set of interlocking functions and processes, directed toward the

achievement of a single goal and operating in a specific context of

laws, policies, procedures, computers and software, personnel and

management.

Unified Integrated System A system designed to achieve the individual objectives of

participating agencies and also the shared objectives of those

agencies, with a single design concept, using one computer language

and set of development tools, and often incorporating a shared

database.
Bureau of Justice

Assistance

Information

General Information

Callers may contact the U.S. Department

of Justice Response Center for general information or specific needs, such as assistance in

submitting grants applications and information

on training. To contact the Response Center,

call 1-800–421–6770 or write to 1100 Vermont

Avenue NW., Washington, DC 20005.

Indepth Information

For more indepth information about BJA, its

programs, and its funding opportunities,

requesters can call the BJA Clearinghouse.

The BJA Clearinghouse, a component of the

National Criminal Justice Reference Service

(NCJRS), shares BJA program information

with State and local agencies and community

groups across the country. Information

specialists are available to provide reference

and referral services, publication distribution,

participation and support for conferences, and

other networking and outreach activities. The

Clearinghouse can be reached by:

❒ Mail

P.O. Box 6000

Rockville, MD 20849–6000

❒ Visit

1600 Research Boulevard

Rockville, MD 20850

❒ Telephone

1–800–688–4252

Monday through Friday

8:30 a.m. to 7:00 p.m.

eastern standard time

❒ Fax

301–251–5212

❒ Fax on Demand

1–800–688–4252

❒ BJA Home Page

http://www.ojp.usdoj.gov/BJA

❒ NCJRS World Wide Web

http://www.ncjrs.org

❒ Bulletin Board

301–738–8895

(Modem setting 8–N–1)

❒ E-mail

askncjrs@ncjrs.org

❒ JUSTINFO Newsletter

E-mail to listproc@ncjrs.org

Leave the subject line blank

In the body of the message,

type:

subscribe justinfo [your name]
BULK RATE

POSTAGE & FEES PAID

DOJ/BJA

Permit No. G–91

U.S. Department of Justice

Office of Justice Programs

Bureau of Justice Assistance

Washington, DC 20531

Official Business

Penalty for Private Use $300

BJA World Wide Web Address

For a copy of this document online,

as well as more information on BJA,

check the BJA home page at

http://www.ojp.usdoj.gov/BJA