The author(s) shown below used Federal funding provided by the U.S. 

Department of Justice to prepare the following resource: 

Document Title: Analysis of the Criminal Justice System’s 

Data Architecture 

Author(s): Diane Lacy 

Document Number: 250964

Date Received: July 2017 

Award Number: 2011-IJ-CX-K051

This resource has not been published by the U.S. Department of 

Justice. This resource is being made publically available through the 

Office of Justice Programs’ National Criminal Justice Reference 

Service. 

Opinions or points of view expressed are those of the author(s) and 

do not necessarily reflect the official position or policies of the U.S. 

Department of Justice. 
Analysis of the Criminal Justice System’s Data Architecture 1 

ANALYSIS OF THE

CRIMINAL JUSTICE SYSTEM’S

DATA ARCHITECTURE

AWARD NUMBER: 2011-IJ-CX-K051

AUTHOR: DIANE LACY

SUBMISSION DATE: JULY 2016

REVISED JULY 2017

This project was supported by Award No. 2011-IJ-CX-K051, awarded by the National 

Institute of Justice, Office of Justice Programs, U.S. Department of Justice. The opinions, 

findings, and conclusions or recommendations expressed in this publication are those of 

the author(s) and do not necessarily reflect those of the U.S. Department of Justice. 

Prepared by SEARCH, The National Consortium for Justice Information and Statistics, 

1900 Point West Way, Suite 275, Sacramento, California 95815.

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 2 

Abstract 

The criminal justice system in the United States is a complex national enterprise 

consisting of a multitude of independent units of government (jurisdictions and agencies) 

that must coordinate their activities in order to achieve a common goal: an efficient and 

effective justice system. To effectively coordinate these activities, system stakeholders 

must effectively share information. However, due to its diversity and decentralization, the 

justice system lacks a common framework for sharing data — in other words, it lacks a 

common data architecture. The primary hypothesis of this project was that while the 

justice community has invested significantly in developing information sharing standards, 

which are critical components of a data architecture, it has not developed a complete 

“enterprise” view of the justice process that properly identifies all of the components 

required to understand the entire enterprise, nor has it properly scaled these exchanges to 

maximize their utility across organizational boundaries. 

The results of this research affirm this hypothesis — there is little demonstration that the 

justice system has developed a comprehensive enterprise model of a criminal justice data 

architecture. However, this research has also moved the discussion forward by 

developing a framework for assessing the state of the justice data architecture. Justice 

stakeholders can use this framework to capture, document, and measure the components 

that exist, and they can add to it to develop a robust criminal justice data architecture. 

The goals of this project were to—

1) document the current as-is state of the criminal justice system’s data architecture 

compared to its ideal future to-be state, and identify gaps between the two, and

2) develop a common framework or structure for defining the information sharing 

requirements and capabilities of the criminal justice process — a data architecture 

metamodel and framework.

To accomplish these goals, researchers defined the structure of the framework following 

principles of Enterprise Architecture, Service Oriented Architecture, and Business 

Process Modeling. Following this framework, researchers used the framework to 

document the as-is and to-be states of the criminal justice data architecture. 

Summary of Gaps: The law enforcement community is well-represented by

GRA/NIEM standards, particularly in CAD/RMS, and incident and criminal history 

reporting and querying. Judicial and corrections communities are somewhat less wellrepresented, but they have a body of state-level IEPDs that could be transformed into 

national standards. Emerging lines of business, such as forensics and statistical data 

analytics, are lightly represented in the data architecture, as is guidance and data elements 

for exchanging unstructured data, such as video, images, and voice. Cross-domain 

exchanges between the justice and nonjustice domains (e.g., health, emergency response) 

are limited to those areas of commonality that are largely represented by the common 

person identifiers contained in the Admissions/Discharge/Transfer (ADT) HL7 exchange 

and the Emergency Incident Description Document (currently under APCO review). 

Researchers are evaluating other research and national initiatives to understand, expand,

and document the current state of the architecture. 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 3 

The results of this research illustrate significant gaps between the as-is and to-be states. 

The as-is state identifies those exchanges that practitioners can model in the framework 

using published national reference models and other authoritative resources. The to-be 

state identifies potential exchanges used by the justice community and their nonjustice 

partners. These potential exchanges numbered 680, whereas research identified fewer 

than 50 published specifications exchanges within the as-is state. The incomplete nature 

of the as-is state illustrates the need for broader participation and active outreach to close 

the gap. 

Conclusions with respect to the Data Architecture Framework and tool include: 

1) Analysis of the to-be state illustrates that practitioners can model most 

information exchanges using one of three basic exchange archetypes: Event, 

Query-Response, and Request-Response; 

2) The framework is robust and practitioners can use it to develop their own 

information architectures for their local justice enterprise; 

3) Practitioners can use the framework as a model for broader adoption and use by 

other domains; 

4) Existing resources and standards establish a foundation to share information that 

needs to be expanded; and 

5) Matriculation to the ideal, to-be state will require further investment to promote 

the adoption, use, and management of the justice data architecture. 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 4 

Table of Contents 

Abstract ............................................................................................................................................................................ 2

Executive Summary ......................................................................................................................................................... 5

Problem ......................................................................................................................................................................... 5

Purpose ......................................................................................................................................................................... 5

Research Design/Methods ............................................................................................................................................ 6

Results .......................................................................................................................................................................... 9

Objective 1 – Analysis of Data Architecture Report ................................................................................................... 9

Objective 2 – NJDA Framework .............................................................................................................................. 10

Conclusions................................................................................................................................................................. 13

I. Introduction ............................................................................................................................................................ 15

Statement of the Problem ............................................................................................................................................ 15

Literature Citations and Review ................................................................................................................................... 17

Statement of Hypothesis or Rationale for the Research ............................................................................................... 22

Aligning Enterprise, Information, and Service Oriented Architectures ...................................................................... 25

II. Methods .................................................................................................................................................................. 27

Rationale for Approach ................................................................................................................................................ 27

Assessment of the Current, As-Is State................................................................................................................... 29

Assessment of the Conceptual, To-Be State ........................................................................................................... 30

The National Justice Data Architecture Tool ................................................................................................................ 31

Documenting the Data Architecture ............................................................................................................................. 32

Distinguishing a Data Architecture from an Information Architecture ............................................................................ 32

III. Results ................................................................................................................................................................... 34

Objective 1 – Analysis of Data Architecture Report ...................................................................................................... 34

Adoption and Use of EA and SOA........................................................................................................................... 34

Information Sharing Standards for Business Architectures ...................................................................................... 36

Summary of Gaps ................................................................................................................................................... 39

Objective 2 – NJDA Framework .................................................................................................................................. 40

Planning View ......................................................................................................................................................... 43

Operational View .................................................................................................................................................... 46

Design View ............................................................................................................................................................ 49

IV. Conclusions ........................................................................................................................................................... 53

Discussion of Findings................................................................................................................................................. 53

Planning View ......................................................................................................................................................... 54

Operational View .................................................................................................................................................... 57

Design View ............................................................................................................................................................ 61

Summary of Views Analysis .................................................................................................................................... 64

Implications for Further Research ................................................................................................................................ 65

Extending the NJDA Framework Taxonomy ............................................................................................................ 65

Expanding the NJDA Content ................................................................................................................................. 66

Summary ..................................................................................................................................................................... 66

V. References ............................................................................................................................................................. 68

VI. Appendices ............................................................................................................................................................ 70

Appendix A. Solving Problems Using the NJDA – Practical Application of the Architecture.......................................... 70

Use Case 1: Court Case Filing ................................................................................................................................ 70

Use Case 2: Open Court Case ................................................................................................................................ 73

Use Case 3: Charge Referral .................................................................................................................................. 76

Use Case 4: Business Scenario – Electronic Court Case Filing (e-Filing) ................................................................ 79

Use Case 5: Planning ............................................................................................................................................. 80

Use Case 6: Operational Assessment and Requirements ....................................................................................... 83

Use Case 7: Service Assessment and Design ........................................................................................................ 86

Appendix B. Links to Federal and State Enterprise Architecture Sites ......................................................................... 87

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 5 

Executive Summary 

Problem 

The criminal justice system in the United States is a complex national enterprise 

consisting of a multitude of independent units of government (jurisdictions and agencies) 

that must coordinate their activities in order to achieve a common goal: an efficient and 

effective justice system. Coordinating activities among these different entities has long 

been a challenge due to the “stove-piped” nature of each key component — each entity 

performs separate core business functions that address its specific mission. Law 

enforcement focuses on crime prevention and public safety, courts focus on delivering 

just outcomes in criminal and civil disputes, while corrections and jails are responsible 

for safely and effectively managing incarcerated or detained individuals. 

The justice community has long recognized the benefits of using technology to improve 

their business processes and perform their core missions. In the 1990s, the justice 

community recognized the need to further improve system performance and capabilities 

by augmenting their core business systems to include electronic information sharing. This 

effort began at the state and local level; federal authorities then acknowledged and 

embraced it by forming the Global Justice Information Sharing Advisory Committee 

(known as “Global”), a Federal Advisory Committee to the U.S. Attorney General.

Global has since fostered the development of a set of national standards — the Global 

Information Sharing Toolkit (GIST) — that promotes information sharing by federal, 

state, local, and tribal justice entities. The entire justice community has benefitted from 

the standards, guidelines, and frameworks the Toolkit provides, which help improve 

interoperability and information sharing capabilities at lower costs. 

However, for all of the progress made in this area, the nation still lacks a comprehensive 

national data architecture for the criminal justice system as a whole. The work of Global 

and justice community members at all levels of government has evolved without an 

explicit, well-defined architecture. Through a sense of goodwill and common purpose —

rather than by design — a great deal of effective information sharing occurs among the 

various stakeholders in the justice system. These capabilities fit remarkably well together; 

as a result, the nation has taken great strides forward in sharing justice information. But 

we still lack a single, comprehensive picture of this complex enterprise, which limits our 

ability to make further progress and make the wisest use of our investments.

Purpose 

The purpose of the Criminal Justice System Data Architecture project is to assess the 

state of the national data architecture framework for criminal justice and public safety 

information sharing in the United States, and to model this assessment based upon 

Enterprise Architecture principles for information architecture. By developing this 

architecture, practitioners and technologists will share an integrated view of the business 

problems to be solved within the greater justice enterprise. SEARCH, The National 

Consortium for Justice Information and Statistics, conducted this research project with 

two primary objectives:

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 6 

... the justice community ... has not 

developed a complete “enterprise” view 

of the justice process that properly 

identifies all of the components required 

to understand the entire enterprise, nor 

has it properly scaled these exchanges 

to maximize their utility across 

organizational boundaries

1) Produce a report that documents: 

 The current as-is national data architecture for information sharing among 

criminal justice agencies at all levels of government, and between criminal 

justice agencies and their partners in related domains such as first responders, 

health, and social services agencies; 

 Any gaps or misalignments in the architecture, as measured against a 

conceptual to-be target architecture. 

2) Define and develop an information sharing framework and associated tools 

to capture and document the current as-is and future to-be state of a 

National Justice Data Architecture (NJDA). This framework includes three 

perspectives or “views,” which address the needs of specific stakeholders based 

upon their role and primary responsibilities and assist in decision-making: 

Planning View Operational View Design View

Senior executives, 

division managers, and 

strategic planners to 

identify goals and policy 

initiatives and to allocate 

resources at the strategic 

level.

Architects and business 

managers responsible for 

designing integrated 

justice systems and 

information flows at the 

business level.

Technology architects 

and developers to make 

decisions about service 

oriented technologies and 

technical designs at the 

implementation level.

Research Design/Methods 

The primary hypothesis for this work is that 

while the justice community has invested 

significantly in developing information 

sharing standards, which are critical 

components of a data architecture, it has not 

developed a complete “enterprise” view of 

the justice process that properly identifies all 

of the components required to understand the 

entire enterprise, nor has it properly scaled 

these exchanges to maximize their utility 

across organizational boundaries.

In conducting research and analysis for the first objective, SEARCH determined that 

synthesizing the disciplines of Enterprise Architecture (EA), Business Process Modeling 

(BPM), and Service Oriented Architectures (SOA) would provide the best approach to 

represent the as-is and to-be states. EA and BPM are naturally synergistic; BPM provides 

the business context, understanding and metrics, while EA provides the disciplines for 

translating vision and strategy into architectural change. Simply put, EA helps 

organizations to do the right things and BPM helps to do things in the right way. The key 

added-value for BPM is its focus on flexible process design, as well as process 

orchestration and information technology (IT) enablement. Service Oriented Architecture

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 7 

provides a technical framework for implementation, and many mature organizations have 

adopted a service oriented approach to business process design as the preferred approach 

to software development. Using a combined EA/BPM/SOA approach helps agencies 

address data, privacy, and security compliance and risks, and document the data 

requirements. The broad end-to-end view of an information sharing environment from 

these perspectives of both exchange partners ensures that regulatory compliance is met. 

Applying EA principles was foundational to developing the data architecture framework. 

SEARCH followed current best practices of EA, a discipline developed by John Zachman 

in 1987.1SEARCH also researched these related frameworks: The Open Group 

Architecture Framework (TOGAF),2the Federal Enterprise Architecture Framework 

(FEAF),3

and the NASCIO Enterprise Framework.4These partition the analysis of an 

enterprise into architectural areas. Exhibit 1 depicts a typical set of architectures: 

Exhibit 1. Enterprise Architecture Layers 

 

1

http://www.zachmaninternational.com/images/stories/ibmsj2603e.pdf

2

http://pubs.opengroup.org/architecture/togaf8-doc/arch/ 

3

http://www.whitehouse.gov/ombv/e-gov/fea/ 

4

http://www.nascio.org/committees/EA/ 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 8 

In conducting research in support of the second objective (develop a tool or framework to 

document the architecture), SEARCH evaluated existing resources available to the justice 

community that promote and/or support information sharing as the basis for the 

architecture. These include the work of the Global initiative, published Global Reference 

Architecture (GRA) Service Specification Packages (SSPs), the National Information 

Exchange Model (NIEM) Program Management Office (PMO), the Information 

Exchange Package Documentation (IEPD) Clearinghouse, and the Justice Information 

Exchange Model (JIEM) Adult Felony Reference Model (AFRM). The project also 

explored two related disciplines to assess their alignment with the Criminal Justice Data 

Architecture: 

 The first responder community, represented by the Emergency Incident Data 

Document (EIDD) initiative. EIDD clearly aligns with the justice domain because 

of commonalities between the two communities. While aligning with NIEM, the 

EIDD initiative has taken a different approach in some respects to the established 

NIEM methodology and model. 

 The health domain, represented by the Health Level 7 (HL7) standard. This 

standard predates the justice information sharing initiatives that led to the current 

GIST. It follows a message-driven approach rather than the all-inclusive data 

model approach followed in NIEM. Alignment of HL7 to NIEM is limited to 

those areas of commonality, which are largely represented by the common person 

identifiers contained in the Admissions/Discharge/Transfer (ADT) HL7 exchange 

and similar elements found mostly in the NIEM core. 

SEARCH is evaluating other research and national initiatives to understand, expand, and

document the current state of the architecture. 

In developing the framework and tool under the second objective, SEARCH adopted the 

concept of “views,” as commonly found in each of the EA methodologies reviewed. 

Views tailor the presentation of the architecture to the needs or interests of particular 

stakeholders in the enterprise. This provides a body of knowledge that decision-makers, 

at different levels, can consult when facing decisions about the stewardship and sharing 

of justice information. SEARCH conceptualized the NJDA views to address three 

different audiences: executive-level, operations-level, and implementer-level. Based on 

this framework, this project produced a view-oriented architecture that presents three 

different views, with each view addressing the needs of a specific stakeholder audience:

Planning View identifies the organizational structures, policies, “line-of-business” (LoB) 

capabilities, and interoperable high-level processes that allow the 

organization to identify and prioritize needed information sharing 

capabilities.

Operational View identifies the core information (or data) assets of the enterprise, and 

generally consists of static and dynamic views that describe information 

semantics, structure, storage, and ownership, as well as its flow 

throughout the organization. 

Design View documents standards for technology infrastructure components and 

implementation approaches that support the Planning and Operational 

Views.

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 9 

Stakeholders can use these views to help analyze an enterprise’s current information 

exchanges and to identify the need for new information exchanges. Using these views, 

partnering agencies will be able to design a sharing architecture as a foundation to 

continually develop, deploy, and expand their information sharing capabilities. 

Results 

Objective 1 – Analysis of Data Architecture Report 

Adoption and Use of Enterprise Architecture and Service Oriented Architecture. 

Researchers determined that a significant body of knowledge exists that describes the 

data architecture as a component of Enterprise Architecture, and that many industries 

have embraced the broader use of EA. Service oriented architecture is now the de facto 

standard for information sharing. However, while the justice community has adopted 

many of the standards of EA and data architecture, a complete, enterprise view of the 

criminal justice data architecture has yet to emerge. This lag in adoption is influenced by 

the nature of the criminal justice system and the mission diversity of its various entities 

and components, the lack of uniform governance represented by the diversity in levels of 

government (local, state, federal) and separation of powers (legislative, executive, 

judiciary), resource contention, and changing public priorities. While limited in number, 

the justice community has successfully adopted a broader EA approach to technology 

planning. Examples include the Regional Information Sharing Systems (RISSNET), the 

San Diego area’s Automated Regional Justice Information System (ARJIS), and 

numerous portal implementations. EA’s limited adoption and implementation means 

there is a limited number of metrics and evidence-based data upon which to make an 

informed assessment of EA’s utility and value. 

Information Sharing Standards for Business Architectures. Using NIEM to design 

and build messages and the GRA to design and build services is the accepted direction 

for justice information sharing. NIEM contains a large body of content that represents 

multiple communities of interest; it is over-inclusive by design. However, because of the 

complexity inherent in the model, it is not easy for the novice to use effectively. One 

approach to consider is to develop common, reusable subcomponents such as 

conceptualized by Business Information Exchange Components (BIECs).

NIEM was designed to be extensible to other domains, as evidenced by the number of 

domains beyond justice and public safety that adopted and participate in NIEM — a total 

of 13 to date. However, many other standards have been developed and the justice data 

architecture needs to interoperate with those that have a nexus with justice. Emergency 

management and health are two such domains. The emergency management domain has 

adopted NIEM but recognizes the need to interoperate with other standards. They are 

pursuing the concept of a “super standard” that accommodates NIEM and other 

standards, such as the NENA Registry Systems Standard5and the NENA/APCO Next 

 

5

 NENA-STA-004.1-2014. NENA is the National Emergency Management Association. 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 10

Generation 9-1-1 Public Safety Answering Point (NG9-1-1 PSAP) Requirements.6The 

health domain uses multiple standards for data exchange, with HL7 being predominant. 

There is limited overlap with NIEM to date, and interoperability may be constrained to 

person-based data elements and demographic information. 

The lack of strong governance over the NIEM Clearinghouse and the justice domain 

impedes the effectiveness of the standard to some extent. NIEM is very inclusive and this 

results both in benefits, such as higher levels of participation, and in weaknesses, such as 

duplicated examples and a lack of clearly identified authoritative examples. While several 

reference specifications exist, they cover only a limited number of exchanges. Stronger 

governance exists for the GIST, where reference specifications are vetted independently 

and represent a more authoritative resource. 

Summary of Gaps. The law enforcement community is well-represented with 

GRA/NIEM standards, particularly in records management and computer-aided dispatch 

systems (RMS/CAD), and incident and criminal history reporting and querying. The 

judicial and corrections communities are less well-represented, but they have a body of 

state-level IEPDs that could be transformed into national standards. Emerging lines of 

business, such as forensics and statistical data analytics, are lightly represented in the data 

architecture, as is guidance and data elements for exchanging unstructured data such as 

video, images, and voice. Cross-domain exchanges between the justice and nonjustice 

domains (e.g., health, emergency response) are limited to those areas of commonality that 

are largely represented by the common person identifiers contained in the ADT HL7 

exchange and the EIDD currently under APCO review. SEARCH is evaluating other 

research and national initiatives to understand, expand, and document the current state of 

the architecture. 

Objective 2 – NJDA Framework 

The National Justice Data Architecture is a tool developed to document the as-is and tobe states of the criminal justice data architecture. This tool is based on principles of 

Enterprise Architecture and employs three views to provide appropriate information to 

three distinct audiences (Exhibit 2).

 

6

 NENA/APCO-REQ-001.1.1. APCO is the Association of Public-Safety Communications Officials–

International. 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 11

Exhibit 2. NJDA Framework Views 

 The Planning View will demonstrate for public safety and criminal justice 

executives, legislators, and policy-maker bodies how the information sharing 

environment will look nationally and assist in strategic planning. 

 The Operational View will demonstrate for operational managers and 

information architects how the pieces fit together so they can make decisions 

about how and where information exchanges should occur. 

 The Design View will assist technology architects and developers to make 

decisions about systems and technologies that adopt and contribute to a standardsbased national architecture. 

The tool is based on the open source Mediawiki platform with support for page 

management, contribution control, presentation, user management, and administrative 

tools. This platform is well known through Wikipedia, so it provides familiar presentation 

and navigation via its links, page content, and site search capabilities. Categories and 

properties are the basic organization method for a Mediawiki site, with form and 

templates providing capabilities for users to enter and edit information. The NJDA 

employs visual modeling as much as possible to produce business and service models 

using standards-based tools, such as the Business Process Modeling Notation (BPMN) 

language and Unified Modeling Language (UML). This aligns with SOA and ModelDriven Architecture (MDA) and the recommendations of NIEM and the GRA.

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 12

As of July 2016, the following NIEM IEPDs or GRA Service Specifications are 

published as national standards and contributed to the NJDA Framework: 

 Law Enforcement Information Technology Standards Committee (LEITSC):7

 7 CAD/CAD Service Call Information IEPDs 

 1 CAD/RMS Service Call Information IEPD 

 2 RMS/RMS Incident Query/Response IEPDs 

 Global Standards Council:8

 2 Federal Data Repository SSPs: Suspicious Activity Report, Terrorist 

Screening Encounter 

 6 Federated Query/Search/Response SSPs 

 4 Court SSPs: Charging, Supervision Conditions, Disposition Reporting, 

Victim Notification 

 7 Law Enforcement SSPs: Arrest Reporting, Warrant Activities, 

Fingerprinting 

 5 Supervision/Corrections SSPs: Inmate Release/Transfer, Sex Offender 

Location 

 Federal Bureau of Investigation: 

 National Data Exchange (N-DEx) Incident/Arrest 

 N-DEx Incarceration, Booking, Parole, Probation 

 IJIS Institute: 12 CAD/Intelligent Transportation Public Safety IEPDs 

 NENA/APCO sponsored a “super-standard” EIDD,

9

to include NIEM, GRA, 

NENA, APCO, and other national standards. 

 Reference specifications and national standards are largely in law enforcement 

activities with limited representations for other justice activities, particularly 

supervision (Detention, Corrections, Community Supervision) and nonjustice 

domains. 

 Model-Driven Architectural practices and graphical artifacts are recommended 

but largely absent in the GRA SSPs and NIEM IEPDs specifications. This 

contributes to difficulties in understanding the underlying schema of published 

IEPDS and facilitating reuse.

 

7

 LEITSC-sponsored IEPDs are available from the International Association of Chiefs of Police (IACP) 

website (2013): http://www.theiacp.org/About-IACP/Governance/-CAD-RMS 

8

 Global-sponsored SSPs are available from their website (2015): https://it.ojp.gov/gist/ 

9

 (APCO International and IJIS Institute, 2013). The IJIS/APCO Emergency Communications Task Force 

(ECTF) report calls for a “universal standard/super standard” that provides additional requirements on the 

creation of future data exchange requirements. 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 13

Conclusions 

The primary hypothesis for this work is that while the justice community has invested 

significantly in developing information sharing standards, which are critical components 

of a data architecture, it has not developed a complete “enterprise” view of the justice 

process that properly identifies all of the components required to understand the entire 

enterprise, nor has it properly scaled these exchanges to maximize their utility across 

organizational boundaries.

The results of this research affirm this hypothesis — there is little evidence that the 

justice system has developed a comprehensive enterprise model of a criminal justice 

data architecture (Exhibit 3). However, this research has also moved the discussion 

forward by developing a framework for assessing the state of the justice data architecture. 

Justice stakeholders can use this framework to capture, document, and measure the 

components that exist, and they can add to it to develop a robust criminal justice data 

architecture. 

SUMMARY OF GAPS

 The corrections, detention, and supervision business 

areas are not well-represented in the published 

standards (IEPD and SSPs) and the data architecture.

 New and emerging lines of business, such as 

forensics and data analytics, are not represented in 

the data architecture.

 Information exchange points between the justice and 

nonjustice communities, such as health and first 

responders, are not documented in the data 

architecture.

 The data architecture lacks guidance on the NIEM for 

capabilities and techniques, to include external 

standards (e.g., HL7, NENA) and unstructured data 

(images, voice, and video) to support the “superstandard” concept proposed by APCO/NENA.

 Non-technical persons could more readily understand 

data architecture specifications if IEPDs and SSPs 

always included graphical representations.

 The NIEM can be difficult to understand and navigate 

for nontechnical persons; visual representations would 

assist both in understanding the model and to ensure 

the integrity and coherency of the model.

 Lack of metrics and measured results makes it difficult

to make evidence-based investment decisions on the 

impact of sharing information.

 Justice strategies and practices are shifting to reforms 

in corrections, behavioral health programs, and 

community services to decrease recidivism and 

reduce costs. These areas are not strongly 

represented in the body of standards and 

specifications.

Exhibit 3. Summary of Gaps Identified Between “As-Is” and “To-Be” State 

The researchers initially posited a variety of questions that should be of interest to 

practitioners and that a comprehensive data architecture could address. The framework 

and tool demonstrate that they can address most of these questions, making the tool an 

effective source of enterprise information to planners, policymakers, and developers. 

Conclusions regarding the Data Architecture Framework and tool include: 

1. While there are hundreds of potential exchanges within the justice enterprise, 

most, if not all, can be modeled using one of three basic exchange archetypes: 

Event, Query-Response, and Request-Response. 

2. The framework is robust and practitioners can use it to develop their own data 

architectures for their local justice enterprise. 

3. Practitioners can use the framework as a model for broader adoption and use by 

other domains. 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 14

4. Existing resources and standards establish a foundation to share information that 

needs to be expanded; and 

5. Matriculation to the ideal, to-be, state will require further investment to promote 

the adoption, use, and management of the justice data architecture (see summary 

of recommendations in exhibit 4).

SUMMARY OF RECOMMENDATIONS

PLANNING VIEW

1. Collect content and document the justice and public safety lines of business (LoBs) and key information 

exchange points to create an accurate model of justice information life-cycle. Essentially this would be a 

revised Criminal Justice Case Flow Life-cycle diagram.

2. Confirm and apply an expandable NJDA meta-model (taxonomy) — e.g., domain, LoB, activity, capabilities, 

information, and services — to support a discoverable categorization of GRA, GIST, and NIEM assets, 

specifications, and resources. 

3. Decompose the updated Criminal Justice Case Flow Life-cycle into complete business process models and 

activities. Explore emerging LoBs, such as forensics and data analytics, and changing LoBs, such as 

corrections and community supervision.

4. Identify points of information exchange between the justice, public safety, and health and human services 

domain models, and unify into the NJDA. 

5. Expand the scope of the NJDA to identify alignment and gaps with other domains and their associated LoBs.

OPERATIONAL VIEW

1. Develop a logical enterprise-level graphical representation of the NIEM model to establish a visual 

representation and ensure the integrity and coherency of the model, with the “Type” elements in the justice 

domain being the likely input.

2. Create guidelines on how to develop Business Information Exchange Components, including samples that 

align with the NJDA Business Reference Models. These would be the initial high-level data models of a 

national Information Reference Architecture.

3. NIEM: Assess and update the model definitions to eliminate tautological definitions and create more accurate 

business definitions.

4. NIEM: Assess the model for new capabilities or techniques to include external standards (e.g., HL7, NENA) 

and nonstructured data (images, voice, and video) to support the “super-standard” concept as proposed by 

APCO/NENA.

5. NIEM IEPDs: Perform a quality assessment and report of the NIEM Clearinghouse IEPDs to confirm currency, 

accuracy, and compliance.

6. NIEM IEPDs: Expand the meta-model to include the NJDA and add to the search capabilities of the 

clearinghouse.

7. GRA SSPs: Evaluate the published GRA service specifications and determine if refactoring is needed.

DESIGN VIEW

1. Perform a gap analysis on an LoB-by-LoB basis to determine the services needed to support the Business and 

Information Reference Models.

2. Create profile specifications that incorporate Security Assertion Markup Language (SAML), GFIPM, and 

eXtensible Access Control Markup Language (XACML) elements in tiered levels of security, identity, and 

information assurance. 

3. Develop a multi-layer framework that includes NIEM and GFIPM elements and possible security aspects such 

as SAML or Trustmark that equals and satisfies FBI Criminal Justice Information Services (CJIS) Security 

requirements for Internet and public message transport. These could be the foundation for a NJDA Security 

Reference Model.

4. Establish an ongoing committee to evaluate open source solutions, SOA deployment practices, model-driven 

tools, cloud services, and emerging technologies, and make recommendations on inclusion or relationships 

with the NJDA Technology Reference Model. The intent is to strengthen enabling assets and resources to 

increase the ease of information sharing deployment.

5. Develop a Security Reference Model, possibly using the National Institute of Standards and Technology’s 

(NIST) A Framework for Improving Critical Infrastructure Cybersecurity (February 2014).

Exhibit 4. Summary of Recommendations by View 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 15

I. Introduction 

Statement of the Problem 

The criminal justice system in the United States is a complex national enterprise 

consisting of a multitude of independent units of government (jurisdictions and agencies) 

that must coordinate their activities in order to achieve a common goal: an efficient and 

effective justice system. Coordinating activities between these different entities has long 

been a challenge due to the “stove-piped” nature of each key component — each entity 

has its own mission and performs separate core business functions to support that 

mission. Law enforcement is focused on crime prevention and public safety, courts are 

focused on delivering just outcomes in criminal and civil disputes, and corrections and 

jails are responsible for safely and effectively managing sentenced or detained 

individuals. The justice system as a whole is like a conveyor belt where each station in 

the process aligns with each of these entities — and each entity is responsible for 

performing specific, specialized activities as individuals enter, move through, or exit the 

justice process. Because of the specialized, entity-centric nature of the justice process, 

few, if any, of the entities involved see or work with the system as a whole — no one 

really sees the “big picture.” Consequently, the criminal justice system is often 

characterized as a “nonsystem.”

10

The justice community long ago recognized the benefits of using technology to improve 

their business processes and perform their core missions. Ironically, as relatively early 

adopters of technology, much of this “adoption” led to the current stove-piped nature of 

the justice process. Each entity built data systems to address their core functions and 

relied on paper to exchange information with the next entity in the process. In the 1990s, 

the justice community recognized the need to improve system performance and 

capabilities by augmenting their core business systems to include electronic information 

sharing. While initially seen as largely a technology challenge, stakeholders in the justice 

process came to recognize the need for effective governance and accountability across 

organizational boundaries as well. Because of the independent nature of agencies and 

jurisdictions involved in the justice process, the justice community recognized the 

importance of fostering agreement about how information sharing should occur. By 

establishing broadly accepted standards and guidelines, justice organizations could make 

their own policy and technology choices, while still enabling information flow and 

business process integration with their partners. 

Efforts to address both technology and policy issues related to justice information sharing 

began in the late 1990s with the formation of the Global Justice Information Sharing 

 

10 Criminal Justice Nonsystem, A. W. Cohn (from Crime and the Criminal Justice Process, by James A. 

Inciardi and Kenneth C. Haas, 1978 – See NCJ-53277), 

www.ncjrs.gov/App/publications/abstract.aspx?ID=53283; To What Extent Should the Criminal Justice 

System be a “System”?, Martin L. Forst, Center for the Study of Law and Society, University of California 

at Berkeley, http://cad.sagepub.com/content/23/4/403.abstract; Criminal Justice in the U.S.: Restructuring a 

‘Non-system,’ National Civic Review, Volume 62, Issue 5, pages 240–247, May 1973, published online 

January 31, 2007, http://onlinelibrary.wiley.com/doi/10.1002/ncr.4100620504/abstract. 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 16

Initiative (“Global”), a Federal Advisory Committee to the U.S. Attorney General. One of 

the early achievements of Global was to support and direct development of the Global 

Justice XML Data Model (GJXDM), which for the first time established a key 

component of a national data architecture for justice information sharing. The success of 

GJXDM led the Department of Homeland Security (DHS) to join with Global and the 

Department of Justice (DOJ) to form the National Information Exchange Model (NIEM) 

initiative in 2006. With NIEM, the data architecture established by GJXDM expanded 

both in scope and adoption with the majority of states in the U.S. adopting NIEM at some 

level, and with NIEM at the core of many nationwide initiatives as well. As GJXDM and 

NIEM became established standards for the structure and semantics of shared 

information, Global turned its attention to developing other important components of the 

data architecture. In 2004, Global published a paper identifying service oriented 

architecture (SOA) as the strategic approach for state, local, and tribal justice information 

sharing nationwide, and tasked its Infrastructure/Standards Working Group (GISWG) 

with developing a service oriented reference architecture that practitioners could use as 

the basis for implementing SOA in their own jurisdictions. Since 2007, GISWG has 

produced several documents establishing this reference architecture, which it published 

as the Global Justice Reference Architecture (GRA). In addition, the Global Security 

Working Group (GSWG) published a set of guidelines for federated identity 

management, called Global Federated Identity and Privilege Management (GFIPM), and 

the Privacy/Information Quality Working Group published a framework for 

implementing machine-enforceable privacy policies based on open industry standards. 

Most recently, Global has aggregated all standards, policies, and guidelines into the 

Global Information Sharing Toolkit (GIST).11

Global has led the effort to establish and promote information sharing within the justice 

and public safety community. The entire community has benefitted from these standards, 

guidelines, and frameworks through greater interoperability and better information 

availability at lower costs. These improvements would not have been possible without the 

development and adoption of standards and the leadership of groups like Global. 

However, for all of the progress made in this area, the nation still lacks comprehensive 

national data architecture for the criminal justice system as a whole. 

All of the work of Global, NIEM, and community members at all levels of government 

has evolved without an explicit, well-defined architecture. Through a sense of goodwill 

and common purpose — rather than by design — a great deal of effective information 

sharing occurs between the various stakeholders in the justice system. The various 

components that have been put in place fit remarkably well together; as a result, the 

nation has taken great strides forward in sharing information. But we still lack a single, 

comprehensive picture of this complex enterprise, which limits our ability to make 

further progress and make the wisest use of our investments. 

 

11 https://www.it.ojp.gov/gist 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 17

Fortunately, enterprise architectures (and the standards, guidelines, and technologies they 

contain) are quite flexible, so it is never too late to step back and consider formalizing the 

relationships and linkages between components through the creation of an architecture. 

Literature Citations and Review 

Literature citations for the analysis are organized by their contribution to: 

A. Authoritative references for the Enterprise Architecture (EA), SOA, and Business 

Process Modeling (BPM) disciplines and development of the National Justice 

Data Architecture (NJDA) framework; 

B. Analysis of the current state of justice information sharing; 

C. Content for the NJDA Framework. 

A. Authoritative references for EA, SOA, and BPM include electronically published 

materials from the: 

 NASCIO Enterprise Architecture Toolkit 3.0 

 Federal Enterprise Architecture Framework 2.0 (FEAF) 

 IBM Center of Excellence (COE) 

 Carnegie-Mellon, Software Engineering Institute (SEI) 

 IBM SOA Foundation Group 

 Open Group Organization 

The NASCIO EA Toolkit 3.0, Information Architecture volume contributed to the 

assessment and discussion of how “data architectures” matured into “information 

architectures.” Information architectures are still evolving with the dramatic proliferation 

of nonstructured data and questions of how to manage the transient nature of mobile data. 

The FEAF 2.0 DOJ Reference Models contributed to the high-level definition of the 

taxonomy of the NJDA Framework. It also contributed to the content of the justice “lines 

of business” category and the advocacy of a “common approach” with the facets of 

primary outcomes, levels of scope, basic elements, sub-architecture domains, reference 

models, current and future views, transition plans, and roadmaps. 

The IBM COE and the Carnegie-Mellon SEI contributed significantly to the value of the 

combined approach of EA, BPM, and SOA with several white papers, IBM “Redbooks,”

research studies, and case studies. Significantly, these studies have shown that the 

combined value of these disciplines far outweighs the value of practicing any one of them 

individually. Successful SOA is realized by effective BPM; effective BPM is realized by 

strategic enterprise architecture. 

The IBM SOA Foundation Group and the Open Group Organization materials confirmed 

the value of using SOA not just in the sense of designing software (service) development,

but also in describing the business. Their materials also contributed to the value of using 

visual modeling tools such as UML and BPMN to create robust, integrated, and complete 

models of process, information, and services. 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 18

B. Analysis of the current state of justice information sharing includes published 

material from: 

 The IJIS Institute and APCO International 

 The RAND Corporation 

 The Urban Institute 

 SEARCH

 The National Strategy for Information Sharing and Safeguarding 

 Reports from Governing the States and Localities, Government Technology, and 

other periodicals focused on the public sector 

 State-level Enterprise Architecture websites (see Appendix B)

 NIEM Core Evaluation report

The IJIS Institute and APCO International contributed information on state and industry 

information sharing initiatives and programs, such as the Prescription Monitoring Drug 

Program, the Emergency Incident Description Document IEPD, and the Justice 

Reinvestment Initiative. The EIDD IEPD (still in review at this writing) is an example of 

a “super-standard” information sharing specification that combines industry standards. 

The RAND report, Improving Information-Sharing Across Law Enforcement: Why Can’t 

We Know?, contributed an assessment specific to the computer-aided dispatch/record 

management system (CAD/RMS) industry and associated IEPDs identifying progress and 

remaining barriers. The report focuses on the systems that are relatively mature, governed 

and standardized, but the issues and challenges it addresses are equally germane to other 

criminal justice entities. 

Several Urban Institute publications provided context on criminal justice issues, 

particularly evidence-based research. The NJDA Framework is capable of capturing 

metrics and performance results from evidence-based research in a “data-driven” 

visualization manner to aid in valuating information exchanges. 

SEARCH published a comparative analysis of NIEM to Health Level 7 (HL7) with the 

intent of identifying opportunities to bridge the two standards.12 The findings of this 

research suggest that there are important but limited opportunities for the two standards 

to interoperate, which focus on the person-based demographic and other descriptive data 

contained in the HL7 Admission/Discharge/Transfer (ADT) exchange. 

The National Strategy for Information Sharing and Safeguarding contributed to the 

understanding of the federal vision and strategies for information sharing. It provided 

some NJDA content on where future funding sources might arise and policy implications 

that might “trickle-down” to state and local jurisdictions. 

Reports from Government Technology and other periodicals provided context and 

specific examples of information sharing experiences, which confirm that jurisdictions 

 

12 http://www.search.org/files/pdf/TechBrief_HL7-NIEM_Comparative_Analysis.pdf 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 19

encounter the same problems and issues in cross-agency information sharing. They also 

confirm that the difficulty of information sharing rests not in technology, but rather in 

policy, integration with disparate systems, budget constraints, and conflicting priorities. 

SEARCH used David Hay’s NIEM Core Evaluation report to understand the 

implementation challenges that development staff and subject matter experts encounter 

when using NIEM IEPDs and associated schemas. 

C. Content for the NJDA Framework: 

The NJDA Framework is a tool to help plan, design, develop, and deploy an information 

sharing environment between a set of collaborating exchange partners. The framework 

strives to address concerns and interests of decision-makers, business managers, and 

technologists through Planning, Operational, and Design views (Exhibit 5). Each view 

provides guidance through recommendations, standards, frameworks, and other 

disciplines such as the EA frameworks, GRA, and SOA design. These are extensively 

noted in Section II: Methods. 

Each view also provides navigable artifacts, such as business process models, service 

interaction models, and service inputs and outputs. These artifacts are intended to be 

adapted to the particular goals and priorities of users. 

Exhibit 5. Diagram of NJDA Framework 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 20

The NJDA Framework, based upon the Mediawiki platform, is intended to be used as a 

tactical decision-making tool rather than a prescriptive representation of the data 

architecture. SEARCH limited the scope of this initial effort to the business aspects and 

functional information sharing exchanges within Business and Data Reference Models 

(BRM and DRM). SEARCH recommends also providing guidance and artifacts for a 

Security Reference Model (SRM) on identity and privilege management, secure 

collaboration, transport protocols, and safeguarding of shared information. Users can do 

this by adding a security reference model to the framework (see our recommendations, 

embodied in Section IV. Conclusions).

The framework collects and organizes the available information sharing functional and 

technical artifacts into BRMs and DRMs guided by the planning, operational, and design 

views, each of which has its own taxonomy. In this manner, SEARCH was able to 

identify gaps in the architecture. 

SEARCH derived significant content for the NJDA Framework from: 

 The National Information Exchange Model (NIEM) Information Exchange 

Package Document (IEPD) Clearinghouse 

 Global Reference Architecture (GRA) Service Specification Packages (SSPs) 

 Global Information Sharing Toolkit (GIST) 

 The SEARCH Adult Felony Reference Model (AFRM) 

NIEM This model provides an extensive vocabulary and a common language to 

enable information sharing between diverse organizations. It is organized into 

domains, of which the justice domain is the arguably the richest and most 

complete. NIEM also provides a standard process and tools to assemble 

selected subsets of the model into an IEPD that enables partners to define 

their specific XML exchange messages. As IEPDs are developed, they are 

published into the NIEM IEPD Clearinghouse for others to review, reuse, and 

adapt for their information sharing needs.

GRA The Global Justice Information Sharing Initiative (Global), funded by the 

Departments of Justice and Homeland Security, supports information sharing 

through the development of the GRA framework. The framework provides 

guidance and technical specifications on how to secure and transport NIEM 

messages. These specifications are packaged into SSPs that conform to both 

the GRA and NIEM standards.

GIST Global also developed a toolkit, known as GIST, to help exchange partners 

design their exchange to meet their security, privacy and reliability 

requirements. GIST is a broad collection of policy guides, governance 

framework specifications, and assessments to assist in the composition of 

designing an information sharing environment. The searchable materials are 

presented in videos, podcasts, presentations and traditional publications, 

organized by topics and tagged with keywords. The GIST was used 

extensively to document essential enabling assets and resources to support an 

information sharing environment.

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 21

AFRM The ARFM is designed to facilitate planning and deployment of integrated 

justice information sharing initiatives.13 The conceptual model identifies 

interagency business processes, key agency decision points, and the 

information flow between agencies when these decisions or events occur. The 

model provides state and local practitioners with a tool to develop an 

enterprisewide view of their information sharing requirements. The ARFM 

was used extensively to document the business capabilities in the justice 

domain. The AFRM defines and documents the information exchange 

requirements for 654 information exchanges between justice partners along 

five dimensions — agencies, events, processes, conditions, and information.14

These dimensions contributed to the design of the NJDA Framework, and the 

provided the majority of the content for the NJDA Operational View.

SEARCH developed this diagram (Exhibit 6) as a high-level operating model of an 

integrated justice domain environment.15 The NIEM and the AFRM contributed to the 

capabilities and information components, while the GIST contributed to the enabling 

assets and resources components.

The NIEM IEPD Clearinghouse and the GRA Service Specifications provided content to 

the NJDA Framework. Key content for the NJDA includes business process models, 

service interaction models, and information models and metadata information. 

Researchers focused on assessing national reference models, such as the N-DEx 

Incident/Arrest IEPD or the GRA Charge Filing SSP. 

 

13 SEARCH produced the AFRM in 2004 using the Justice Information Exchange Model (JIEM) tool. 

14 Note: The JIEM tool models point-to-point exchanges, whereas the NJDA models service oriented 

exchanges with web services that support multiple message actions. 

15 (Robertson, Ross, & Weill, 2006), pages 28–34.

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 22

Exhibit 6. Justice Domain Coordination Model 

Statement of Hypothesis or Rationale for the Research 

SEARCH’s primary hypothesis for this work is that while the justice community has 

invested significantly in developing information sharing standards, which are critical 

components of a data architecture, it has not developed a complete “enterprise” view of 

the justice process that properly identifies all of the components required to understand 

the entire enterprise, nor has it properly scaled these exchanges to maximize their utility 

across organizational boundaries.

The complete lifecycle of the criminal justice business process depends upon activities 

and processes that cross many agencies and jurisdictional boundaries. A case may begin 

in law enforcement, then is evaluated by a prosecutor, who in turn will prosecute the case 

in court, which may result in sentencing to either a state department of corrections, jail, or 

probation department — each of which could be a separate independent unit of 

government. Each of these entities has its own mission, which may contend or even 

conflict with another within the same system. It is no wonder that the justice system 

epitomizes the concept of stove-pipe systems and would significantly benefit from taking 

an enterprise approach to information architecture.

This decentralization of the justice process necessitates a high level of collaboration and 

coordination between agencies to be successful. While NIEM and the GRA provide 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 23

specific data message and service design standards, cross-jurisdictional collaboration 

initiatives need a higher-level view to develop a comprehensive set of capabilities. The 

literature review confirmed that the disciplines of Enterprise Architecture, Business 

Process Modeling, and Service Oriented Architectures are the best approach for the 

analysis. 

EA and BPM are also naturally synergistic; BPM provides the business context, 

understanding and metrics, and EA provides the disciplines for translating vision and

strategy into architectural change. Simply put, EA helps organizations to do the right 

things and BPM helps to do things in the right way. The key added-value for BPM is its

focus on flexible process design, as well as process orchestration and IT enablement. 

Mature organizations have adopted a service oriented approach to business process 

design, which then naturally combines with an SOA approach for software development. 

Using a combined EA, BPM, and SOA approach helps agencies to address data, privacy, 

and security compliance and risks — as well as to document the data requirements. The 

broad end-to-end view of an information sharing environment from these perspectives of 

both exchange partners ensures that regulatory compliance is met. For example, 

compliance requirements in the sharing of prescription drug history records from the 

perspective of a law enforcement agency may be quite different than the perspective of a 

treatment program provider. As the demand for information continues to grow across the 

sharing environment, common information services will be exposed to larger user 

communities. Consequently, it often falls upon managers and architects to identify new 

requirements and potential security exposures. But without a well-documented 

architecture that is based on a firm foundation, it can become nearly impossible to track 

data throughout the infrastructure and effectively establish the necessary means of 

authentication, authorization, and transport protection.

SEARCH followed current best practices of EA, a discipline developed by John Zachman 

in 1987.16 SEARCH also researched related frameworks, including: The Open Group 

Architecture Framework (TOGAF),17 the Federal Enterprise Architecture Framework 

(FEAF),18 and the NASCIO Enterprise Framework.19 These frameworks partition the 

analysis of an enterprise into layered architectural areas, which are also referred to as 

“domains” or “models” within the overall architecture. These are further decomposed 

into sub-domains (sub-models) to the detail and extent needed by the enterprise. This

high-level model (Exhibit 7) depicts the typical starting point of an EA framework: 

 

16 http://www.zachmaninternational.com/images/stories/ibmsj2603e.pdf

17 http://pubs.opengroup.org/architecture/togaf8-doc/arch/ 

18 http://www.whitehouse.gov/ombv/e-gov/fea/ 

19 http://www.nascio.org/committees/EA/ 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 24

Exhibit 7. Enterprise Architecture Layers 

An EA framework combines structure, processes, and templates to document the desired 

architecture in a systematic and disciplined manner. It can be described as a technique for 

developing the necessary repository for the Enterprise Architecture. Stakeholders must 

construct the framework before they can document the detail regarding the organization’s 

business, information, and technology functions. 

Specific elements of the EA that contributed to the development of the NJDA Framework 

are Business and Information Architectures, which informed development of the NJDA’s 

Planning and Operational Views, and the Application and Technology Architectures, 

which informed development of the Design View. 

Business Architecture documents items such as exchange partners, capabilities, events,

and information with their existing and future significance. The business capabilities 

statements in the business model are more completely documented in refined and 

exchange partner-specific BPMs, preferably in standardized languages such as Business 

Process Notation Language. The NJDA helps develop these visual models by providing 

decomposed BPMs, information models, and agency data flows. Business process models 

are decomposed into service interaction models, which provide input into the web service 

design and orchestration. The business models depict the information to be shared or 

exchange, which is the input to Information Architecture. 

Information Architecture is the compilation of the business requirements of the 

enterprise: the information, process entities, and integration that drive the business and 

rules for selecting, building, and maintaining that information. Information Architecture 

addresses the informational needs of the enterprise. Reference models are the core of an 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 25

information exchange environment: they contain source data models, information 

exchange models, target data models, information orchestration, data quality, and 

applicable data technology standards. In this scenario, charge filing and prosecution case 

information is to be shared. The NJDA uses both description information and class 

diagrams from published specifications from NIEM IEPDs or GRA Service 

Specifications. 

Application Architecture defines the major kinds of application systems necessary to 

manage the data and support the business. Applications are mapped back to capabilities 

in the Business Architecture and data assets in the Information Architecture. Application 

architecture identifies the applicable standards for security and privacy, which the 

Technology Architecture then details. The NJDA uses a general level to describe the 

applications that support law enforcement records management systems (RMS),

prosecution, court and prosecution case management systems (CMS), jail management 

systems (JMS), and offender management systems (OMS). 

Technology Architecture is a disciplined approach to describing the current and future 

structure and inter-relationships of the enterprise’s technologies in order to maximize 

value in those technologies. The Technology Architecture framework provides a sound 

set of structured processes and templates to support implementation and communication 

of the architecture. The mapping of the technology products and standards to the 

Business Drivers is vital to align the overall enterprise direction. Vendors, employees, 

and business users can benefit from an understanding what technology standards exist 

and where these standards can be found. 

Aligning Enterprise, Information, and Service Oriented Architectures 

Both the GRA and NIEM proscribe using SOA for compliant exchanges. A service 

oriented style is applied to an enterprise by being adopted as the overarching style for any 

architecture within that enterprise — business architectures, information systems 

architectures, and infrastructure architectures. While SOA is typically associated with 

web services, the concept is now applied to business-oriented services that enable 

flexibility and improved delivery speed. Exhibit 8 illustrates a basic interaction view of 

EA and the SOA and BPM disciplines.

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 26

Exhibit 8. Interaction View of EA, SOA, and BPM 

in Enterprise Architecture

This analysis synthesizes these three disciplines into one perspective or framework in 

order to effectively address the decentralized nature of the criminal justice system. A 

private sector EA plan is centrally managed, aligned, and traceable to the top strategic 

goals. The plan can reflect and integrate all aspects of the business — customer service, 

human resource, financial, marketing, logistics, and chain supply business processes —

into one centrally managed effort that allows all stakeholders in the business to “pull the 

cart together.” While private sector environments might be complex, information 

integration initiatives have been successful and have standardized much of the 

information sharing solutions with an extensive set of internal partners. Information 

sharing with external partners is mutually beneficial based on decreased costs and 

incentives for return on investment. However, the full-cycle completion of law 

enforcement and judicial case business processes depend upon activities and processes 

that cross many agencies and jurisdictional boundaries. A case will start locally; may 

flow horizontally or vertically through local, county, or state jurisdictions; and may cross 

into nonjustice communities, such as private or public health and human services.

While each agency or organization may have its own EA, including IT capabilities and 

systems, their strategic drivers, goals, and aligned capabilities are unlikely to be 

compatible due to their often-nonaligned missions. This leads to contention about 

priorities and competition for funding, resources, and assets. It is necessary for partner 

agencies to collaborate and develop a shared information sharing architecture that 

mutually aligns their capabilities, meets their business requirements, protects their data 

assets, and complies with internal policies. 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 27

II. Methods 

Rationale for Approach

SEARCH researchers based this analysis of the criminal justice system data architecture 

on the disciplines of Enterprise Architecture, Business Process Modeling, and Service 

Oriented Architecture. The analysis integrated these disciplines into a common 

framework to define and describe the justice data architecture. Following the principles 

of EA (as previously discussed), the justice data architecture focused on defining the 

current (as-is) state of information using the published standards, best practices, and 

guidelines developed and governed by the domain stewards—Global for the GIST and 

the DHS Program Management Office o for NIEM. Researchers assessed the current 

state of information sharing by evaluating the set of published GRA Service 

Specifications and NIEM Information Exchange Package Documents in conjunction with 

other authoritative resources. To define the future (to-be) state, researchers used a broad 

scan of the literature, input from subject matter experts, and a review of the Adult Felony 

Reference Model of the JIEM tool. Then, following EA principles, researchers conducted 

a gap analysis between the current (as-is) state and the future (to-be) state. Developing

the as-is and to-be states involved creating detailed business process models, identifying 

document sharing points, and determining whether information standards existed for 

those documents. 

EA frameworks include the notion of views, and the use of views was seen as integral to 

the presentation of data included in the NJDA. Views are intended to enable different 

constituencies to use the architecture to address their individual needs or areas of 

concern. For example, an application designer or chief information officer (CIO) will ask 

different questions of an architecture than a policymaker (police chief or judge). Some 

users will look for guidance on how to build things — such as what constraints should be 

in place to ensure that a particular application or resource fits with everything else. Other 

users will look to the architecture to understand how investments and information flows 

support key business objectives, such as reducing offender recidivism or reporting 

suspicious activity. Following this strategy, researchers identified a variety of questions 

that could reflect the different requirements and needs of three constituencies —

Planners, Operational Managers, and Designers — and that potentially could be 

addressed through a better understanding of the criminal justice data architecture.

The project team posited that the following questions may be of value to these three user 

types, and each of these questions is evaluated in Section IV. Conclusions.

Planning View Questions:

 What policy objectives can information sharing help achieve?

 What current business challenges is the justice community facing, and how can 

we address those problems with information sharing?

 What risks are inherent in information sharing, and how do we mitigate those 

risks? For example, developing and enforcing proper privacy policies mitigate the 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 28

risks associated with the maintenance and exchange of personally identifiable 

information (PII).

 What governance models are in place to establish ownership and control over 

information and information exchanges?

 What principles determine who should provision and control information and 

exchanges?

 What strategic plans exist currently, and what is the progress toward those plans?

How do jurisdictions and agencies align with those plans?

 What are the measures of success?

Operational View Questions:

 Who is, or should be, exchanging information?

 What is the content (structure and meaning) of exchanged information?

 What systems (or “capabilities,” in GRA) typically capture or record information 

about the occurrence of those events?

 What is the business process or policy response to each event? 

 What “nonfunctional” requirements (“service interaction requirements,” in GRA 

terminology) apply to each exchange? That is, what are the access control, 

confidentiality, availability, reliability, logging, accountability, and similar 

requirements that apply?

 How do existing information exchanges (e.g., service specifications, IEPDs) map 

into the reference exchanges (events, process responses)? Are any existing 

exchanges misaligned?

 What partner organizations’ capabilities/systems/processes typically participate in 

the policy response?

 What events trigger information exchange in the justice system (and related 

domains)?

 What are the priorities for building exchanges?

Designer View Questions:

 What is the typical state of implementation of supporting technology at the state 

and local levels of government? 

 What networks and other national technology infrastructure elements are in place 

to support information sharing? 

 What technical principles can inform choices of technology provisioning strategy 

(e.g., cloud or shared services)? 

 Where are there gaps in what the Operational and Planning Views require? 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 29

Assessment of the Current, As-Is State

SEARCH based its current (as-is) state assessment on the Case Flow Sequence Diagram 

originally developed by the President’s Commission on Law Enforcement and 

Administration of Justice in 1967 (Exhibit 9).20 Although the DOJ updated the diagram in 

1997, it has remained substantially unchanged for 50 years.

Exhibit 9. Case Flow Sequence Diagram 

The diagram provides a high-level overview of the criminal justice process, breaking the 

process into five major components: Entry (arrest), Prosecution and Pretrial Services, 

Adjudication, Sentencing and Sanctions, and Corrections. More specific activities or 

actions are broken down within each component. Where there is some crossover or 

“bleeding” across the components, colors are used to clarify how each task or activity 

aligns with the model.

A second key authoritative resource was the Justice Information Exchange Model (JIEM) 

developed by SEARCH, The National Consortium for Justice Information and Statistics, 

in 2003. JIEM was an early effort to map and model the key exchanges between justice 

partners, and decomposed information sharing into five key dimensions: Processes, 

Agencies, Events, Conditions, and Information. The model provided further detail about 

 

20 Adapted from The Challenge of Crime in a Free Society, President’s Commission on Law Enforcement 

and Administration of Justice, 1967. This revision, a result of the Symposium on the 30th Anniversary of 

the President’s Commission, was prepared by the U.S. DOJ Bureau of Justice Statistics in 1997. 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 30

the justice process, focusing on data exchange requirements. A key product in the 

development of JIEM was the production of the Adult Felony Reference Model (AFRM), 

which identified and documented 654 information exchanges among justice partners.

Researchers used information from both of these authoritative resources to more 

precisely define the justice process using Business Process Modeling Notation (BPMN).

Researchers identified and defined high-level “lines of business” and developed detailed 

business process models to graphically illustrate how data moves between justice 

partners. The business process models identified triggering activities, subsequent 

activities, and associated documents. Document descriptions identified sending agencies, 

receiving agencies, and national reference service specifications associated with 

document exchanges. 

While the AFRM captures a vast array of exchange requirements, it does not document 

the data that must be exchanged. The NJDA Framework allows data to be documented at 

a more detailed level and relies on various authoritative national resources to identify the 

content of each exchange.21 As an example, the AFRM identifies that an incident report is 

the exchanged document. The NJDA captures more detail about the content of the 

incident report. Researchers used the Service Specification Packages available on the 

Global website to capture this added detail. The SSPs also included design details such as 

transport and security requirements. Together, researchers used these resources to 

identify and document the components of the framework/architecture. 

Assessment of the Conceptual, To-Be State 

The future (to-be) state of information sharing relies on these same authoritative 

resources but also adopts and applies the principles of the GIST, use of SOA-based 

design, use of web services, standards for security and transport, and NIEM for XML 

data format. Following the GIST, development teams can use standards and design 

elements to develop solutions that follow a broader, more consistent and holistic 

approach. This produces information sharing in agreement on a set of business-aligned 

SOA services that collectively and mutually supports the business processes and goals of 

the exchange partners. By collaborating on a joint EA Information Sharing Reference 

Model, partners can realize a flexible technology environment, improve the quality of 

service delivery, and prevent security breaches and business interruptions.

The objectives of successful SOA are embedded in the EA concepts of “sharing” and 

“reuse.” SOA supports the overall enterprise architecture by enabling agility so the 

enterprise can respond to new business needs, respond quickly to trends, and handle 

disruptions such as legal and regulatory changes. SOA influences the business 

architecture with well-defined, reusable business processes; influences the application 

architecture to use components and service interfaces; influences the information 

architecture to use standards; and influences the technical architecture with standards for 

 

21 The N-DEx Incident/Arrest IEPD and the N-DEx Incarceration/Booking/Probation/Parole IEPD. 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 31

infrastructure to support the following: services, service consumers, and messaging 

infrastructure. 

Both the GRA and NIEM leverage SOA concepts for technical implementations. To 

assist in reference model planning, the GRA addresses the full range of information 

sharing use cases by providing a flexible blueprint to implement interoperable data 

sharing services across organizations — whether they are technologically advanced or 

those with limited technology resources. 

The to-be assessment included the SOA discipline because SOA provides flexibility 

through autonomous web services and cost-effective message movement by using

Internet transport. SOA provides solutions to the challenges of information sharing in 

criminal justice as it decouples technology from the exchange. (Such challenges occur 

due to the lack of a common mission; the existence of multiple independent exchange 

partners; and diversity of systems, data assets, and security requirements.)

Using SOA design and construction principles ensures that the sets of web services are 

well-defined, appropriately interact, and — when in context with EA — are fully 

traceable to real-world functions, capabilities, activities, and business objectives. As 

stakeholders identify and model new business objectives throughout the enterprise, they 

can quickly assemble available information assets and services to meet the new objective. 

If there are gaps, stakeholders can quickly identify new solutions. An example of this 

speed of service delivery is illustrated by the continually expanding mobile applications

for cell phones and tablets. 

The National Justice Data Architecture Tool

During the course of the project, the project team determined that a tool to capture and 

organize the project artifacts would be useful for justice agencies and their partners to 

create a joint enterprise information sharing plan. The tool is intended to assist partner 

agencies to develop a joint Information Reference Model (IRM) that meets their 

information exchange needs, leverages their data assets resources and security policies, 

and uses existing GRA and NIEM exchange standards. 

When developing complex information exchanges, it is often difficult to bridge the gaps 

between business and service requirements. Designing and implementing a businessaligned set of services that works for all exchange partners presents a fundamental 

problem: Business requirements are difficult to translate into deployable specifications. 

The NJDA addresses these challenges by providing a systematic, modular approach to 

identify and associate business processes and information with service interactions 

through model-driven architecture practices and recommended standards. Using the 

NJDA, partners can design a comprehensive information sharing plan that they can 

develop and implement in increments as partners have available assets and resources.

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 32

Documenting the Data Architecture

The NJDA tool is based on the open source Mediawiki platform with support for page 

management, contribution control, presentation, user management, and administrative 

tools. This platform is well known through Wikipedia, so it provides familiar presentation 

and navigation via its links, page content, and site search capabilities. Categories and 

properties are the basic organization method for a Mediawiki site, with form and 

templates providing capabilities for users to enter and edit information. The NJDA 

employs visual modeling as much as possible to produce business and service models 

using standards-based tools such as the BPMN language and Unified Modeling Language 

(UML). This aligns with SOA and Model-Driven Architecture (MDA) and the 

recommendations of NIEM and the GRA.

The Mediawiki platform is augmented with additional semantic extensions to increase the 

capabilities for category drill-downs, additional property support, custom queries, and 

inline views. The category tree extension allows a dynamic, direct navigation through the 

category structure. The semantic drilldown extension provides a page for drilling down 

through the site, using categories and filters on semantic properties. Semantic capabilities 

are added to templates and forms to ensure that entered information conforms to a 

defined data structure that supports the metadata model and enables semantic queries.

Distinguishing a Data Architecture from an Information Architecture 

While this report refers to the Criminal Justice System Data Architecture, in practice, the 

analysis performed and the framework and tool developed for documenting the state of 

the criminal justice data architecture align with the more mature definition of an 

information architecture.

An “architecture” is primarily a decision-making framework, whether building a house, 

organizing an enterprise, or designing a system. Like any architecture, the goal for the 

NJDA is to serve as a decision-making framework. It should be a body of guidance that 

decision-makers, at all levels, can consult when facing decisions about the stewardship 

and sharing of justice information. An architecture documents the intended environment 

with the components, specifications, and relationships to other components.

While frequently used interchangeably, in the context of EA, the terms “information 

architecture” and “data architecture” are distinctly different.22

Data architecture addresses the available data assets that systems produce and store. It 

establishes the enterprise data assets and defines how those assets are created, stored, 

protected, and managed.23 It is typically documented through data models such as entityrelationship diagrams, UML class diagrams, data dictionaries, or in spreadsheets. 

 

22 Early EA models have Data Architecture as one of four reference models: Business, Data, 

Applications, and Technical. 

23 (Lewis, Comella-Dorda, Place, Plakosh, & Seacord, 2001). 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 33

Information architecture addresses the informational needs of the business. It is 

frequently defined as the organization of data into usable formats that are accurately 

transformed into the desired format that end users can understand. Information 

architecture describes how these assets flow through business processes, levels of quality 

standards, data aggregation rules, required security during transport, and how information 

is treated by non-owning systems, generally policy-directed. It is focused on information 

integration and interoperability, typically documented in data flow diagrams, message 

formats, and transport protocols. 

Information architecture differs from data architecture in that it encompasses both 

structured (data marts, databases, database tables, and data exchanges) and unstructured

information (web content, jpeg or video files, and documents). Information architecture 

also defines business functional processes and delineates the relationship of the data 

element concepts to the processes. Information architecture documents the relationships 

between business domains and business processes, as well as the information, business 

rules, and organizational roles/responsibilities that are part of each process. In other 

words, data architecture is focused on “data-at-rest” and information architecture is 

focused on “data-in-motion.” (NASCIO, 2008) 

Data and information architectures can be documented in combined or separate EA 

Reference Models. The Federal Enterprise Architecture Framework describes them in the 

Data Reference Model (DRM). In the NASCIO EA Framework, they are governed in the 

Information Architecture Reference Model. Exhibit 10 from the NASCIO EA Toolkit24

represents where data/information architecture fits into an EA Program: 

Regardless of name, this 

architecture is a key bridge, driven 

by the Business Model and a driver 

to the Technology Reference Model. 

Using the detail documented in the 

information architecture provides 

the basis to share information 

throughout the enterprise, as well as 

across organizational boundaries. 

The NJDA uses both concepts and 

contains models that represent both 

data-at-rest and data-in-motion. 

 

24 http://www.nascio.org/EA 

Exhibit 10. Where Data Architecture Fits 

in Enterprise Architecture

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 34

III. Results 

Objective 1 – Analysis of Data Architecture Report 

Over the past two decades, corporations and private businesses successfully implemented 

and realized the benefits of maturing business management practices and technology 

advancements. These practices are ingrained in planning activities and successfully used 

to align business objectives with technology adoption and investment. (IBM, 2008) The 

disciplines that are germane to enterprise data architecture include: 

 Enterprise Architecture (EA) creates a framework that places integrated 

strategic goals, business operations, and technologies into a set of unified models 

to support an enterprise vision. 

 Business Process Management (BPM) practices identify, optimize, consolidate,

and integrate core business operations and processes to achieve improvements in 

productivity, cycle times, and quality. 

 Service Oriented Architecture (SOA) and supporting standards and 

technologies improve business agility, lower development costs, reduce risks, and 

decrease ongoing maintenance. 

Adoption and Use of EA and SOA 

The current state of information sharing in the justice community reflects an 

understanding of GRA and NIEM principles — that SOA and web services are best 

suited for the underlying application architecture for information sharing. SOA is a 

broadly adopted and proven discipline that aligns business strategy and IT solutions with 

results that increase productivity, reduce costs, and speed system deliveries. (Jenson, 

Charters, Amsdens, Darlington, Owen, & Eric, 2008) Since the early 2000s, SOA 

implementations have successfully transformed businesses with integrated systems, 

reduced redundancies through consolidation, and increased information access using a 

host of new technologies and delivery capabilities.25 Due to its features of loose coupling 

and platform independence, SOA is becoming the preferred and more suitable 

architectural style for ubiquitous or pervasive computing and information 

interoperability. (Zanuz, Barcelos, Filippetto, & Pinto, 2008) 

Concurrent with the rising use of SOA, and driven by the economic downturn, 

organizations introduced EA programs to support multiyear consolidation projects and 

increase shared services. (Patton, 2010) They merged data centers, selected single-source 

email and Internet providers, and centralized procurement and provisioning. Subsequent 

projects merged or replaced functional systems (e.g., finance, HR); e-government 

initiatives were mandated; and Internet self-service capabilities replaced administrative 

services. All of these gave rise to the importance of understanding the data assets and 

how the information was used and presented to the business entities. 

 

25 (Patton, 2010), http://www.governing.com/blogs/view/The-Push-to-Consolidate.html 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 35

However, law enforcement and other justice agencies have been slower to adopt EA and 

SOA and/or to join state-level EA programs because they face challenges unique to the 

justice domain. These, in turn, adversely impact cross-agency information sharing 

progress. (Newcombe, Merging IT Systems Causes Problems for States and Localities, 

2010) 

Mission Diversity: The criminal justice system consists of multiple agencies or actors 

with different and often conflicting missions. Law enforcement is responsible for 

ensuring public safety, while prosecutors, defense, and courts are responsible for ensuring 

a fair judicial process. Corrections and supervisions agencies are responsible for 

managing offender consequences and the reintegration of offenders into the community. 

Conversely, many other public sector systems, such as education or health agencies,

generally have similar missions. 

Alignment of Cross-Agency Enterprise Architectures: Even if partnering justice 

agencies have an EA program with developed enterprise plans and deployment standards 

that include IT capabilities and systems, it is likely that their funding, priorities, and 

resources will not align. This makes it difficult for a given project to be smoothly 

coordinated and successful. Project delays occur because needed resources (staff or 

funding) are not available at the needed time. 

Organizational Disparity and Legislative Constraints: The justice system is directly 

affected by the diversity of legal and organizational authorities within which it must 

operate. Cities, counties, special districts, nonjustice agencies, states, the separate 

branches of government, and the federal government often produce conflicting 

requirements that make information sharing difficult because of the lack of a single, 

centralized authority.26 For example, oversight of state Prescription Drug Monitoring 

programs may be provided by health departments, pharmacy boards, or law enforcement 

agencies — each of which has different policies and legislative constraints on sharing of 

patient drug prescription and dispensed history. Similarly, sharing juvenile criminal 

history or mental health records is highly constrained by privacy legislation and respect 

for citizen concerns. 

Justice Reforms: Another factor is change. Priorities within the justice domain are 

shifting to reforms in policing, corrections, behavioral health programs, and community 

services to reduce crime, decrease recidivism, and reduce costs. These are introducing 

new or changing business processes — and practitioners are still studying and exploring 

effective programs, treatments, and metrics. (Kim, Becker-Cohen, & Serakos, 2015) A 

key premise of EA is that evidence-based metrics are used as input to investment 

decisions, but measurement metrics and program performance results are being 

reevaluated as reforms and changing policies are evaluated. 

 

26 Of note, the Texas State Code, Title 1, Part 8, Chapter 177 Rule 2 mandates the justice information 

exchanges between courts and law enforcement conform to NIEM IEPDs developed under the “Texas Path 

to NIEM” project. 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 36

There are also many new SOA-based information sharing capabilities provided through 

regional federated networks, such as RISSNET and ARJIS, and through open portals, 

such as the Police Foundation’s Public Safety Open Data Portal, the Kentucky State 

Police Open Data Portal, and others.

EA and SOA As-Is Findings:

 Statewide Enterprise Architecture practices are gaining ground and producing 

successes in modeling business strategies, predominantly to support consolidation and 

to streamline procurement and provisioning, which is typically the first maturity level 

of EA.

 Due to its features of loose coupling and platform independence, SOA is becoming 

the preferred and more suitable architectural style for information interoperability.

(Zanuz, Barcelos, Filippetto, & Pinto, 2008) (Ziemann, 2010)

 Lack of metrics and measured results makes it difficult to make evidence-based 

investment decisions on the impact of sharing information.

 Portals with single sign-on and federated capabilities are frequently the earlier 

solutions to information sharing, preceding more complex information integration and 

interoperability projects.

Information Sharing Standards for Business Architectures 

Using NIEM to design and build messages and the GRA to design and build services is 

the accepted direction for justice information sharing. Vendor products are increasingly 

including NIEM-compliant information, and government funding includes NIEM and 

GRA language in their Requests for Proposals. (Hollywood & Winkelman, 2015) 

NIEM Model: NIEM has a great deal of content that represents multiple communities of 

interest. Most organizations using NIEM to share information will only use a small 

fraction of the model to meet their specific information sharing requirements. Because 

NIEM is so large and overly inclusive, it is often difficult for IEPD developers to find the 

appropriate NIEM content because there is so much to sift through. (NIEM Technical 

Advisory Committee, 2011) Since NIEM was developed without the semantics of data 

structure27 and no graphical components, it requires subject matter expertise, data design 

skills, and specific NIEM model navigation skills to find appropriate NIEM elements and 

 

27 Since XML is a linguistic model, semantics would describe the logical relationships of types, 

properties, aspects of reference, and implication and logical forms. 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 37

then manually define and map the business semantics.28 The NIEM model would benefit 

from the addition of graphic models to assist IEPD developers.29

NIEM BIEC/EIEM Concept: A Business Information Exchange Component (BIEC) is 

a collection of closely related business data organized at an object level and defined as 

extension data components in an IEPD. Often they are business data components 

developed and used by multiple organizations within the same community of interest 

(COI). Once an organization defines a number of BIECs, it can use the collection of 

BIECs as a library of business components or as the basis of an Enterprise Information 

Exchange Model (EIEM). Instead of developing each IEPD by mapping business data to 

NIEM and extension components, sub-setting NIEM, and defining extensions, 

organizations can perform much of the IEPD development by mapping high-level 

business content to existing BIECs in their own EIEM. 

The Maritime Information Exchange Model (MIEM) is an example of the BIEC/EIEM 

concept. BIECs were modeled for the high-level maritime objects such as Vessels, Cargo, 

Passengers, Crew, Ports of Call, etc., and collated into the MIEM. The MIEM is now 

being used as the basis for information sharing between the U.S. Coast Guard, 

Department of the Navy, the National Center for Vessel Movement, and other maritime 

entities to develop IEPDs specific to their business needs. 

The use of BIECs has the potential to simplify IEPD development and increase 

consistency of the business object definitions at all steps in the process, including 

exchange content modeling, mapping to NIEM, creating NIEM extension components, 

and generating XML schemas.

Integration of industry standards: All data standards need to recognize and address 

how to exchange data with other standards. NIEM is no exception and has limited 

capabilities to integrate with other models and industry standards, such as HL7, NG9-1-1, 

and NIST. As an example, the APCO/NENA Emergency Incident Data Document 

(EIDD) IEPD Workgroup has been developing a national super-standard for public safety 

answering point (PSAP) incident reporting for more than three years, and the work is still 

in progress. An ongoing difficulty is including external standards into the IEPD, which 

has complicated completion of this effort. The IEPD is currently in APCO review. 

The health community is another domain with potential interactions and a need to 

exchange data with the justice community. There are several health data exchange 

standards. The one with broadest adoption is Health Level 7.30 HL7 predates the 

 

28 A particular design aspect is that the model requires the use of references between data elements in 

combination to communicate one piece of business information. For example, there are data structures for 

an offense and for locations, and the offense location is determined by creating a reference link between 

those structures, tying a specific location to an offense. This is not intuitive to many developers, and makes 

eyeballing the XML by nondevelopers difficult and even harder for subject matter experts. (Hay, 2014) 

29 The Bureau of Justice Statistics sponsored a NIEM UML project. The tool specification was based on 

NIEM 2.1, which has since been superseded by NIEM 3.1. 

30 www.hl7.org 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 38

development of justice data exchange standards and varies significantly both in the 

content and transport methods used in justice. There are multiple versions of HL7 in use, 

and although the most recent version (Version 3, implemented in 2005) uses XML, it has 

not been broadly adopted. By far, the largest number of implementations — more than 

three quarters of all exchanges31 — use some variant of Version 2.3 or older and rely on 

an older Electronic Data Interchange transport standard and character delimited data 

structures. Despite this variability, there is semantic equivalence between some of the 

data and messages of HL7 and NIEM. Commonality can be found between the person 

descriptive data contained in the HL7 Admissions/Discharge/Transfer (ADT) message 

and person-related elements found in NIEM Core. 

IEPD Governance: Reflecting both a strength and weakness, any entity that seeks to 

specify a document or collection of data elements in a manner compliant with the toplevel NIEM specifications can prepare and submit IEPDs. There is no authoritative 

oversight to the content, design quality, appropriate contextual modeling, and 

implementation documentation within the NIEM IEPD review process. 

NIEM Clearinghouse Organization: Finding relevant IEPDs in the clearinghouse 

could be improved. There is a limited amount of metadata that users can employ to find 

and determine the suitability of a given specification. Given that graphical documentation 

(e.g., class diagrams, business flows) is recommended but not required, it is timeconsuming to drill-down into schemas and XML. Thus, it is easier and more effective to 

create another IEPD — which has rendered significant duplication and overlap of IEPDs 

in the clearinghouse. It is also difficult to determine the level of development and 

implementation of IEPDs. 

GRA Information Sharing Toolkit: The GRA and the GIST significantly enhance 

information sharing with the continuing publication of reference Service Specification 

Packages. The GRA/GIST provides extensive technical guidance for service 

identification and design and a standardized framework that can reduce development 

costs. The toolkit offers a good governance process, policy guidance, and links to 

resources. 

NIEM and GRA As-Is Findings:

 Reference specifications and national standards are largely in law enforcement 

activities with limited representations for other justice activities, particularly 

supervision (Detention, Corrections, and Community Supervision) and nonjustice

domains.

 Model-Driven Architectural practices and graphical artifacts are recommended but 

largely absent in the GRA SSPs and NIEM IEPDs specifications. This contributes to 

difficulties in understanding the underlying schema of published IEPDs and 

facilitating reuse.

 

31 Technical Brief, A Comparative Analysis of HL7 and NIEM: Enabling Justice-Health Data Exchange, 

Mo West, SEARCH (2015), page 5. 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 39

 There is a limited amount of data that can be exchanged with other domains, such as 

health, yet interoperability is practical and achievable.

 The concept of a super-standard32 as proposed by APCO/NENA is viewed as 

providing high value to the industry. As interactions between health and human 

services and the justice domains increase, stakeholders will need to develop 

techniques to integrate multiple standards.

 The use of BIECs has the potential to simplify IEPD development and increase

consistency of the business object definitions at all steps in the process, including 

exchange content modeling, mapping to NIEM, creating NIEM extension 

components, and generating XML schemas.

 The XML-based NIEM is difficult to understand and foster discussion with 

nontechnical persons who communicate the information requirements. The addition 

of graphical or visual models would assist in understanding the NIEM information 

structure and relationships for both nontechnical and technical persons.

Summary of Gaps 

 The corrections, detention, and supervision business areas are not wellrepresented in the published standards (IEPD and SSPs) and the data architecture. 

 New and emerging lines of business, such as forensics and data analytics, are not 

represented in the data architecture. 

 Information exchange points between the justice and nonjustice communities,

such as health and first responders, are not documented in the data architecture. 

 The data architecture lacks guidance on the NIEM for capabilities and techniques,

to include external standards (e.g., HL7, NENA) and unstructured data (images, 

voice, and video) to support the “super-standard” concept proposed by 

APCO/NENA. 

 Nontechnical persons could more readily understand data architecture 

specifications if IEPDs and SSPs always included graphical representations.

 The NIEM can be difficult to understand and navigate for nontechnical persons; 

visual representations would assist both in understanding the model and to ensure 

the integrity and coherency of the model. 

 Lack of metrics and measured results makes it difficult to make evidence-based 

investment decisions on the impact of sharing information. 

 Justice strategies and practices are shifting to reforms in corrections, behavioral 

health programs, and community services to decrease recidivism and reduce costs. 

 

32 The APCO ECTF report calls for a “universal standard/super standard” that provides additional 

requirements for creating future data exchange requirements. The super standard was specified to 

incorporate NIEM, GRA, specifications from the forthcoming NENA EIDD standard (NENA and APCO, 

2013), and information assurance measures. (Wisely, Wormeli, and Gabbin, 2013) 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 40

These areas are not strongly represented in the body of standards and 

specifications. 

Objective 2 – NJDA Framework 

The NJDA Framework is a tool to assist in planning, designing, developing and 

deploying an information sharing environment between a set of collaborating exchange 

partners. The framework strives to address concerns and interests of decision-makers, 

business managers, and technologists through Planning, Operational, and Design views. 

Each view provides guidance through recommendations, standards, frameworks, and 

other disciplines, such as EA frameworks, GRA, and SOA design. These are extensively 

noted in Section II: Methods. 

Each view also provides navigable artifacts, such as business process models, service 

interaction models, and service inputs and outputs. These artifacts are intended to be 

adapted to the particular goals and priorities of users. 

The high-level diagram (Exhibit 11) summarizes main references used to create the 

guidance and artifacts provided by the NJDA tool. The diagram also identifies gaps 

within the tool, which are further described in Section IV: Conclusions. 

Exhibit 11. NJDA Framework Overview 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 41

The NJDA Planning View guides a process through which partnering agencies can 

develop a strategic interagency interaction model and create a roadmap of prioritized 

information exchanges to mutually meet their agencies’ goals. Business and IT managers 

can use this roadmap to assess the needed service capabilities and document detailed 

requirements of the exchanges through process models, and reference and information 

models. Then, architects and technologists can use these requirements to design the 

services using NIEM IEPDs and GRA SSPs where possible. If IEPDs are not available,

the NJDA tool provides guidance on how to develop information exchange packages and 

service specifications. The diagram in Exhibit 12 summarizes this process flow: 

Exhibit 12. Process Flow for Using the NJDA Tool

The NJDA starts with the main page, which presents the three top-level views that 

address the needs of specific stakeholder audiences. Each view has associated metadata 

to provide semantic context and queries, and each assists in analyzing current information 

exchanges and the need to engineer new information exchanges: 

Planning demonstrates for public safety and criminal justice executives, 

policymakers, and national bodies how a to-be information sharing 

environment might look and assists in assessing their as-is environment 

and planning their to-be environment. This view provides navigation to 

page content to help assess the criminal justice information sharing 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 42

environment in terms of policies, initiatives, and technology standards or 

trends. It provides information that addresses criminal justice challenges, 

reviews evidence-based research, and evaluates what information sharing 

capabilities need to be strengthened or developed. Responsible 

information sharing requires policy mechanisms and legal authorities that 

encourage sharing, with appropriate safeguards, as well as a proven way to 

resolve legal and policy issues that may impede such sharing.

Operational demonstrates for operational managers how the pieces fit together so they 

can make decisions about how and where information exchanges should 

occur. This view presents business processes and models that are 

decomposed and bi-directionally linked with activities. The activities 

provide links to triggering activities, subsequent activities, and associated 

documents. CIOs and managers will want to develop and review the 

business process models and clarify where to best invest resources, 

identify architecture platforms, and evaluate and recommend standards. 

Design assists technology architects in making decisions about systems and 

technologies that adopt and contribute to a standards-based national 

architecture. Architects will want to review services and service 

interaction models, as well as published GRA SSPs, to determine their 

applicability to meet operational and strategic goals. Documents and 

Services are bi-directionally linked, with both linking back to activities.

Exhibit 13 depicts the category structure of each view:33

Exhibit 13. Category Structure of Planning, Operational, and Design Views 

 

33 Note: By default, the category tree extension shown here orders categories alphabetically, although the 

hierarchical structure typically followed when using the tool is Planning, Operational, and Design. 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 43

Planning View 

The NJDA Planning View presents topics, questions, and information to guide partner 

planning discussions to consider how policies, processes, systems, and information are 

currently organized and what a to-be environment might look like for their agency 

interactions. The view starts by presenting a well-established, conceptual information 

sharing diagram of the justice process first developed in 1967 (see Exhibit 9). This 

diagram depicts the overall domain and assists in identifying and selecting which 

processes are most critical to improve business efficiencies, increase public safety, or 

address emerging challenges. The diagram identifies only the steps in the process and the 

high-level business relationships between the major entities that are engaged in the 

criminal justice process. 

The goal of the Planning View is to help inform an EA approach to designing business 

processes that decreases information silos, increases the use of standardized technologies, 

and optimizes core capabilities. This produces a foundation for execution that guides the 

operational decisions with implementation actions that produce results. 

The Planning View includes content on topics that are intended to be for continual user 

contributions, such as: 

Policy Implications of Information Sharing. This topic identifies the emerging policy 

considerations in order to identify information sharing assets that are of value to interagency sharing, what external access is appropriate, and what security protection 

measures need to be in place. This topic is initially guided by the policy products 

developed by the Global Justice Information Sharing Initiative and the DOJ IT policies,

along with various federal- and state-level IT strategic plans. The policy implications of 

legislation such as the Adam Walsh Act and emerging legislation on physical and 

behavioral health records are examples of group areas of discussion. 

Governance Models. This topic identifies various governance models that detail the 

candidate measures to be taken to achieve the policy objectives. These measures include 

data asset risk assessments, performance indicator values for exchanged information, and 

the roles and responsibilities of each exchange partner. This component is initially guided 

by frameworks such as Control Objectives for Information and Related Technology 5 

(COBIT 5) and governance models in place for federated networks, such as RISSNET 

and JNET. 

Principles of Identity Management and Information Access Security. This topic 

identifies existing and emerging standards and architectures to ensure that users are 

appropriately identified and provisioned for access to data assets; that user credentials are 

secured; and that appropriate audits and oversight are in place. This component is largely 

guided by the Global Federated Identity and Privilege Management (GFIPM) standard. 

The Planning View is intended to help identify what information exchanges would be of 

most value to the enterprise and what set of capabilities are needed for those exchanges. 

The output of planning is intended to answer the questions about what needs to be done, 

along with a business model of the intended operating environment and a prioritized set 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 44

of enterprise goals for sharing information to exchange partners. For example, it may be a 

goal to automate all information sharing between a prosecution system and a court 

system using standards to increase accuracy and productivity. This would require that 

both systems provide and use capabilities that exchange information on cases, charges, 

sentencing, and disposition. Or it may be that all warrant information is desired to be 

shared between law enforcement, courts, and state repositories to eliminate manual 

processes. This would entail fewer reusable services that exchange information between 

many agencies. This is the beginning of developing a portfolio of sharing capabilities. 

High-level business relationship models, as illustrated in Exhibit 14, provide the next 

level of detail for the planning process. This diagram depicts the interagency interactions 

to aid in the discussion on what business areas could most benefit from, and are prepared 

for, electronic information sharing. These are not detailed business process models; 

however, they illustrate the progression of events between law enforcement and other 

justice agencies. These diagrams are the bridge from the Planning View to the 

Operational View; as an example, the diagram depicts the interaction between agencies 

from a Call for Service to an Open Court Case. 

The NJDA Operational and Design Views then provide more detailed models and 

underlying components that produce information, such as Call for Service data, that is 

shared with partners and determine how that sharing is enabled through security, identity, 

transport, and federated assets. The role of these diagrams is discussed more thoroughly 

in the following Operational View subsection. 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 45

Exhibit 14. Call for Service to Open Court Case 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 46

Operational View 

The NJDA Operational View depicts related or coordinated business processes, 

activities, and key partners and documents these using Business Process Modeling 

Notation, a broadly used technique to model business processes and interactions. 

Collectively using the models, CIOs and architects can adapt the models to create their 

own portfolio of business capabilities, based upon the strategic planning goals. The 

models define roles, responsibilities, and ownership, and are loosely coupled with each 

other. Ideally, they are easy-to-manage models with a level of decomposition that allow 

operational managers to reuse them in larger process compositions or orchestrations. 

These business models and documents can be a starting point for exchange partners to 

identify and customize the exchanges needed for their own processes that are relevant to 

information sharing priorities established during planning. 

The Operational View is built around the following components: 

Business Reference Models (BRMs). This component documents justice lines of 

business into formal Business Process Models diagrams assembled into a Justice BRM. 

This component is guided by various criminal justice publications and academic studies.

Business Activities. This component documents the details of individual business 

activities within a justice line of business. This component is largely guided by the JIEM.

Exchange Documents. This component documents the information that is exchanged 

between agencies within a business activity. The component is largely guided by 

published NIEM IEPDs in the NIEM Clearinghouse or IEPDs within a GRA Service 

Specification Package. 

The Operational View is modeled on three sets of well-established information sharing 

resources: the JIEM Adult Felony Reference Model; documentation artifacts within 

NIEM IEPDs in the Office of Justice Programs’ IEPD Clearinghouse; and GRA SSPs, as 

published by the Global Advisory Committee. As of July 2016, the following NIEM 

IEPDs or GRA Service Specifications are published as national standards and contributed 

to the NJDA Framework (Exhibit 15): 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 47

Sponsor IEPD or Service Specification

Law Enforcement Information 

Technology Standards 

Committee (LEITSC) 34

 7 CAD/CAD Service Call Information IEPDs

 1 CAD/RMS Service Call Information IEPDs

 2 RMS/RMS Incident Query/Response IEPDs

Global Standards Council35

 2 Federal Data Repository SSPs (Suspicious Activity Report, Terrorist 

Screening Encounter)

 6 Federated Query/Search/Response SSPs

 4 Court SSPs (Charging, Supervision Conditions, Disposition 

Reporting, Victim Notification)

 7 Law Enforcement SSPs (Arrest Reporting, Warrant Activities, 

Fingerprinting)

 5 Supervision/Corrections SSPs (Inmate Release/Transfer, Sex 

Offender Location)

FBI  N-DEx Incident/Arrest

 N-DEx Incarceration, Booking, Parole, Probation

IJIS Institute  12 CAD/Intelligent Transportation Public Safety IEPDs

NENA/APCO  A “super-standard” 36 Emergency Incident Data Document (EIDD), to 

include NIEM, GRA, NENA, APCO, and other national standards

Exhibit 15. NIEM IEPDs and GRA Service Specifications 

Contributing to the NJDA Framework 

SEARCH used the AFRM as reference material to decompose the processes into “Lines 

of Business” (LoBs) business process models within justice and public safety agencies. 

These models identify activities, documents, capabilities, and services for storing, 

managing, and sharing information with key partners. SEARCH used the IEPD and GRA 

artifacts to identify content and structure of exchanged information (e.g., booking reports, 

charge filings, and warrants). 

Business process models, activities, and documents are the core category of the 

Operational View. The metamodel of this view includes triggering and subsequent 

activities, sending and receiving agencies, associated documents with a given activity, 

and associated data elements with a given document. The Operational View assists in a 

business capabilities analysis approach with a view of the justice enterprise LoBs, and 

business activities shown through business process models. During the subsequent 

decomposition, the analysis of selected business functions is refined and specified in 

greater detail until the entire analysis is reduced to those low-level core business 

capabilities. The high-level Business Relationship Models (Planning View) are 

decomposed into related activities. These are grouped and organized within LoB business 

process models, such as Investigation and Prosecution, depicted in Exhibits 16 and 17. 

 

34 LEITSC-sponsored IEPDs are available from the International Association of Chiefs of Police (IACP) 

website (2013): http://www.theiacp.org/About-IACP/Governance/-CAD-RMS

35 Global-sponsored SSPs are available from Global’s website (2015): https://it.ojp.gov/gist/

36 (APCO International and IJIS Institute, 2013). The IJIS/APCO Emergency Communications Task 

Force (ECTF) report calls for a “universal standard/super standard” that provides additional requirements 

on creation of future data exchange requirements. 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 48

Exhibit 16. LoB Business Process Model – Investigation Activities 

Exhibit 17. LoB Business Process Model – Prosecution Activities 

The result of the business capabilities analysis is a set of information sharing capabilities 

that will be used during the next step of the services identification methodology. For the 

purpose of simplicity at this step of the process, it is assumed that each business 

capability is provided by a single service or service candidate. 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 49

Design View 

The NJDA Design View is intended to help technical managers, architects, and their 

development teams identify more technical components of the architecture — what web 

service capabilities are needed, the concepts and best practices of SOA, and available 

references and resources. This view contains the services and service interaction process 

models, content on designing exchanges, information on published SSPs, and technology 

standards. The Design View will describe the implementation initiatives at state and local 

agencies, what national networks and infrastructure elements are in place to support 

information sharing, and what technical principles can assist in provisioning strategy 

decisions. 

The Design View is built around the following components: 

Services. This component describes specific web services that are used to request and 

receive information during the course of a business activity. This component is guided by 

published GRA Service Specifications and conceptual models. 

Service Interactions Models. This component documents conceptual service 

orchestrations to accomplish a collection of business activities. This component is largely 

conceptual; there is no extensive library of published service specifications and the 

interaction between agencies can widely vary from one jurisdiction to another. 

Technologists must become more outward-facing and knowledgeable about the business 

side of the broader justice enterprise. While they do not need to become experts in the 

business, they need an understanding of the language that allows them to talk with 

business analysts about the business. Architects, in particular, provide the 

communications channel and the link between the justice business requirements 

(Operational View) and the resulting technology solution (Design View). They need to 

ensure that business requirements and solutions are traceable and interdependent. They 

can achieve this interdependence by working very closely with business analysts to 

ensure that the solutions proposed fully align with the justice business requirements. In 

common SOA vernacular, it is called “exposing the business architecture.” 

The NJDA Design View provides this perspective by decomposing the Business Process 

Models (Operational View) into services. (“Services” in the context of this view of the 

tool are a technical means to exchange data between systems.) This aids architects and 

designers in arriving at the right service granularity for their capabilities and identified 

business services, and building an enterprise service catalog. By using a standard process 

to identify an organization’s capabilities, even nonexperts in a given business domain 

(e.g., the justice enterprise) can facilitate a useful discussion about business requirements 

and can surface important information on function, metrics, performance, maturity, 

interconnectedness, governance, and compliance. Because business process practitioners 

are answering questions from a technical architect, the architect helps to expose a view 

that the practitioners may not yet have. The introduction of a service model between the 

business model and the technology model is a key factor that can help achieve this goal, 

which leads into Model-Driven Architecture as another premise of the NJDA. 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 50

Services are the core organizational category of the Design View and are based upon the 

standards for NIEM IEPDs and GRA Service Specifications. The metamodel includes 

scope, real-world effect, associated documents, exchange archetype, and service actions, 

as depicted in Exhibit 18. If a national reference IEPD or GRA Service Specification is 

published, these are noted. 

Exhibit 18. Service Metamodel Example 

Service Interaction Process models depict possible service orchestrations. In the example 

in Exhibit 19, an arrest event is reported and routed, in turn, to jail, prosecution, and 

community service systems. While similar to business process models in appearance, 

service interaction models focus on the inter-relation between service providers and 

service consumers. Using the vernacular of the GRA, these are called “adapters” and 

“connectors.” The diagram can also identify service actions and message content. 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 51

Exhibit 19. Service Interaction Process Model Example 

Semantic queries can produce customized listings, such as those shown on a list of Real 

World Effects of Services in Exhibit 20. 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 52

Exhibit 20. Semantic Query Example 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 53

IV. Conclusions 

Discussion of Findings 

The primary hypothesis for this work is that while the justice community has invested 

significantly in developing information sharing standards, which are critical components 

of a data architecture, it has not developed a complete “enterprise” view of the justice 

process that properly identifies all of the components required to understand the entire 

enterprise, nor has it properly scaled these exchanges to maximize their utility across 

organizational boundaries.

The results of this research affirm this hypothesis — there is little evidence that the 

justice system has developed a comprehensive enterprise model of a criminal justice data 

architecture. However, this research has also moved the discussion forward by 

developing a framework for assessing the state of the justice data architecture. Justice 

stakeholders can use this framework to capture, document, and measure the components 

that exist, and they can add to it to develop a robust criminal justice data architecture. 

Using the NJDA as a sustainable and extendable framework, stakeholders can readily add 

and categorize additional content and structure within the views of the framework. The 

framework is extendable into other domains, such as health or emergency management. It 

could also be packaged into a product that can be customized by agency exchange 

partners to document their joint sharing environment. 

The premise of this research was that an enterprise framework has value in that multiple 

audiences can use it to better understand and take advantage of the data architecture of 

the justice domain, thereby resulting in a more efficient and effective justice system. The 

framework is arranged around three “views” of the architecture to be used by key 

audiences to address their areas of concern: 

 The Planning View will demonstrate for public safety and criminal justice 

executives, legislators, and policy-maker bodies how the information sharing 

environment will look nationally and assist in strategic planning. 

 The Operational View will demonstrate for operational managers and 

information architects how the pieces fit together so they can make decisions 

about how and where information exchanges should occur. 

 The Design View will assist technology architects and developers to make 

decisions about systems and technologies that adopt and contribute to a standardsbased national architecture. 

Researchers developed practical questions to be answered by the framework views. These 

sets of questions are presented (Exhibits 21, 22, 26) with a description on where and how 

it is addressed in the framework in the second column. If a question is partially or not 

addressed, additional capabilities to close the gap are noted in the third column. 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 54

Planning View 

The Planning View questions (Exhibit 21) address policy, information sharing strategies, 

and how information sharing can address challenges within the justice community. They 

are of concern to investment decision-makers, strategic planners, and policy analysts.

Exhibit 21. Planning View Questions 

The NJDA can answer most of these Planning View questions by page content and 

external links to federal, state, and local references. The very nature of planning activities 

is that decision-makers and strategic planners need to assess their own environment, 

Planning View Questions NJDA Implementation NJDA Additional Recommended 

Capabilities/Comments

What policy objectives can 

information sharing help achieve?

Privacy and security policies are 

described at the document and 

service category levels.

Add Identity Management category 

and taxonomy metadata.

What current business challenges is 

the justice community facing, and 

how can we address those problems 

with information sharing?

Business challenges are 

described through page content.

Evidence-based research is needed 

to understand what information 

sharing effectively addresses what 

problems, and what metadata to add 

to the NJDA taxonomy.

What risks are inherent in information 

sharing, and how do we mitigate 

those risks? For example, developing 

and enforcing proper privacy policies 

mitigate the risks associated with the 

maintenance and exchange of 

personally identifiable information 

(PII).

Risk Management is not 

addressed.

Users can readily add a Risk 

Management topic, but it needs 

subject matter expertise. 

What governance models are in place 

to establish ownership and control 

over information and information 

exchanges?

The NIEM and GRA governance 

models are described. Guidance 

on agency governance is 

provided.

The GIST provides governance 

templates and examples.

What principles determine who 

should provision and control 

information and exchanges?

This topic is not addressed in 

the NJDA.

Needs further discussion with subject 

matter experts.

What strategic plans exist currently, 

and what is the progress toward 

those plans? How do jurisdictions and 

agencies align with those plans?

Many state-level EA strategic 

plans are described in the NJDA,

focused on those that include 

comprehensive justice

information sharing projects. 

Research these projects in further 

detail within an evidence-based 

perspective. Determine what 

business challenges these projects 

intend to address, what metrics are 

designed, and the resulting 

performance. A good example is the 

Colorado Offender Management 

System, which started in 2016

(Colorado Office of Information 

Technology).

What are the measures of success? Related to previous questions. Topic needs evidence-based input. 

Pretrial services that use risk-based 

evaluations of offenders might be an 

area to evaluate.

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 55

challenges, constraints, and capabilities in order to plan their future environment. The 

NJDA can serve as a model and identifies a broad spectrum of material relevant to 

planners, which they can use to identify the plan scope. Ultimately, each set of 

constituents will need to define their own planning view unique to their specific 

environment and requirements. 

Performance measures, key indicators, and risk factors are typical measures found in 

broader EA planning activities, which are backed by evidence and are typically included 

in a planning metamodel. However, SEARCH discovered only a limited amount of 

authoritative evidence-based research pertaining to the justice domain to confirm the 

metamodel and associated values as originally envisioned. This is reflected in Exhibit 21, 

where certain questions could not be addressed, such as “What are the measures of 

success?” and “What risks are inherent in information sharing?” Further collaboration 

with subject matter experts is needed to confirm and possibly redefine the metamodel and 

metadata in order to answer questions applicable to this view. Adding this is necessary in 

order to guide selection and prioritize decisions for information sharing exchange 

capabilities. 

The Planning View also contains information about business challenges and other areas 

of concern (e.g., drug-related crime, firearms registration and control, mental health 

problems of offenders, and juvenile justice) and includes external links to reference 

materials and government sites. 

In addition to planning the information sharing capabilities portfolio, the Planning View 

enables users to determine what security standards and data asset policies are needed 

(e.g., how data are protected, nonfunctional requirements). Once users establish the 

portfolio priorities and policies, use of the NDJA transitions from the Planning View to 

the Operational View. 

Planning View Findings: 

 Many national organizations have worked and continue to work to evolve the 

national justice data architecture, including Global, the NIEM Project 

Management Office, the FBI Criminal Justice Information Services Advisory 

Policy Board (CJIS APB) and its working groups, and the Program Manager for 

the Information Sharing Environment’s (PM-ISE) Standards Coordinating 

Council (under which industry standards development organizations operate). 

 State and local jurisdictions have undertaken similar efforts to define a standard 

architecture for their jurisdictions — examples include the Colorado Offender 

Management System, and the California Health and Human Services Systems 

Integration and Interoperability Project. 

 Within the justice business processes, standards and specifications exist and are 

broadly adopted for investigative activities, such as incident and arrest reporting, 

wanted/missing persons, stolen property, and CAD/RMS communications. These 

are reflected in the NJDA. 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 56

 The Planning View can help identify agencies and exchanges to support justice 

lines of business (such as investigative or prosecution), but there are gaps in 

associating business problems with evidence-based research to assist in setting 

priorities. 

 Justice strategies are shifting to reforms in corrections, behavioral health 

programs, victim services, and community services to decrease recidivism and 

reduce costs. These areas are not strongly represented in the body of standards 

and specifications. 

 Performance measures, key indicators, and risk factors are typical measures found 

in broader EA planning activities, which are backed by evidence and are typically 

included in a planning metamodel. However, SEARCH discovered only a limited 

amount of authoritative evidence-based research pertaining to the justice 

information sharing to assist in prioritization and investment decisions. 

 The concept of a fused “super-standard,”

37 as proposed by the Association of 

Public-Safety Communications Officials–International and the National 

Emergency Number Association (APCO/NENA), is viewed as providing high 

value to this domain. A successful example of this is the Maritime Information 

Exchange Model (MIEM) led by the U.S. Coast Guard in collaboration with 

federal and international partners. 

 As the health and human services communities develop stronger relationships and 

interactions with the justice community, the governing entities will need to 

consider how to integrate the health business processes and domain standards into 

the data architecture. 

Planning View Recommendations: 

1. Collect content and document the justice and public safety lines of business 

(LoBs) and key information exchange points to create an accurate model of 

justice information life-cycle. Essentially this would be a revised Criminal Justice 

Case Flow Life-cycle diagram. 

2. Confirm and apply an expandable NJDA meta-model (taxonomy) — e.g., domain, 

LoB, activity, capabilities, information, and services — to support a discoverable 

categorization of GRA, GIST, and NIEM assets, specifications, and resources. 

3. Decompose the updated Criminal Justice Case Flow Life-cycle into complete 

business process models and activities. Explore emerging LoBs, such as forensics 

and data analytics, and changing LoBs, such as corrections and community 

supervision. 

 

37 The APCO ECTF report calls for a “universal standard/super-standard” that provides additional 

requirements on creating future data exchange requirements. The super-standard was specified to 

incorporate NIEM and GRA specifications from the forthcoming NENA EIDD standard. (NENA and 

APCO, 2013), (Wisely, Wormeli, and Gabbin, 2013) 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 57

4. Identify points of information exchange between the justice, public safety, and 

health and human services domain models, and unify into the NJDA. 

5. Expand the scope of the NJDA to identify alignment and gaps with other domains 

and their associated LoBs. 

Operational View 

The Operational View questions (Exhibit 22) address the operational design and business 

process flow of information exchanges between agencies. These questions are of concern 

to functional division managers, IT operational managers, and design architects. 

Exhibit 22. Operational View Questions 

Operational View Questions NJDA Implementation Status NJDA Additional Recommended 

Capabilities/Comments

Who is, or should be, exchanging 

information?

This is captured in the “Sending” 

and “Receiving Agency” metadata.

The supervision area needs more 

subject matter expertise to define 

activities and documents.

What is the content (structure and 

meaning) of exchanged 

information?

This is captured in the metadata of 

the document category.

Affirm and adapt document 

metadata and semantic queries 

with subject matter experts.

What systems (or “capabilities,” in 

GRA terminology) typically capture 

or record information about the 

occurrence of those events?

This is captured in the activity and 

service.

Affirm and adapt activity and 

service metadata and semantic 

queries with subject matter experts.

What is the business process or 

policy response to each event? 

This is captured in the business 

models.

Affirm and adapt business models,

particularly in supervision and 

corrections.

What “nonfunctional” requirements 

(“service interaction requirements,” 

in GRA terminology) apply to each 

exchange? That is, what are the 

access control, confidentiality, 

availability, reliability, logging, 

accountability, and similar 

requirements that apply?

No Metadata is designed but not 

implemented. Agency policies and 

standards determine these 

nonfunctional requirements. The 

NJDA can recommend, but there 

are no standards for nonfunctional 

requirements.

How do existing information 

exchanges (e.g., service 

specifications, IEPDs) map into the 

reference exchanges (events, 

process responses)? Are any 

existing exchanges misaligned?

This is captured in the metadata of 

the service category, described in 

content, and depicted in diagrams.

Affirm and adapt for misalignments.

What partner organizations’ 

capabilities/systems/ processes 

typically participate in the policy 

response?

This is captured in the business 

process models.

Affirm and adapt activity and 

agency categories’ metadata and 

semantic queries.

What events trigger information 

exchange in the justice system (and 

related domains)?

This is captured in the activity 

category.

Affirm and adapt activity category 

metadata and semantic queries.

What are the priorities for building 

exchanges?

Not applicable The situation of the enterprise 

should determine priorities.

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 58

The activities of the justice domain are well-documented through legislation, public 

records, and academic and scholarly publications. These resources served as input to the 

Operational View, resulting in a more robust metamodel, so users can answer the 

majority of these questions either directly through the NJDA Framework or through 

semantic queries. Stakeholders can answer the first question — “Who is, or should be, 

exchanging information?” — by using the tool to view activities and documents. For 

example, a court may want to provide capabilities that allow systems to electronically 

send court-related documents. The tool presents this information by answering the 

question, “What documents are sent to courts by what agencies?” This produces the 

following results (Exhibit 23):

Exhibit 23. Results for Question, 

“What documents are sent to courts by what agencies?”

While the question addresses what documents are received by the courts, the tool also 

reveals additional information that may not otherwise be apparent based on the 

perspective of any one stakeholder. The query results identify that the court is also a 

sending entity for some of these documents. This correctly occurs when the exchanged 

information is part of a “request-response” archetype pattern, in that the information is 

expecting a policy response to the request. Looking at the “Affidavit for Arrest Warrant,” 

this would be a request to the courts to review and approve or deny the Arrest Warrant 

and return the affidavit with their decision. 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 59

Further analysis of this inquiry allows the user to limit this scope to only law enforcement 

documents. The question “What documents are sent by law enforcement to courts and 

what triggers the exchange?” produces the following results (Exhibit 24): 

What documents are sent by law enforcement to courts?

Triggering Activities

Affidavit for Arrest Warrant Incident

Arrest Warrant Request

Arrest Warrant Review

Summons Service

Sex Offender Registration

Affidavit for Summons Incident

Summons Request

Prosecution Charging Decision

Probation Violation Charging

Decision

Appearance Bond Release

Arrest Report Arrest without Warrant

Charge Referral

Arrest on Warrant

Bench Warrant Review Hearing

Arrest on Warrant

Court Appearance

Charge Complaint Arrest on Warrant

Arrest without Warrant

Case Filing

Citation Cite and Release

Open Court Case

Case Filing

Traffic Stop

Return of Service Summons Service

Subpoena Service

Arrest on Warrant

Exhibit 24. Results for Question, 

“What documents are sent by law enforcement to courts?”

The question “What events trigger information exchange in the justice system (and 

related domains)?” is answered within the Subsequent Activities and Triggering 

Activities properties in the activity category. For example, “Arrest without Warrant” is 

triggered by an incident and itself can be the trigger to multiple activities, as illustrated in 

the output (Exhibit 25).

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 60

Exhibit 25. Example Output 

Operational View Findings 

 Due to its features of loose coupling and platform independence, SOA is 

becoming the preferred and more suitable architectural style for information 

interoperability. (Zanuz, Barcelos, Filippetto, & Pinto, 2008) (Ziemann, 2010) 

(Ziemann, 2010) 

 The three archetypal patterns of Events, Requests, and Query produce a consistent 

structure to describe a jurisdiction’s set of justice information exchanges or 

national reference exchanges. 

 The exchanges in the architecture fit very well into the NJDA’s graphical 

depictions, archetypal patterns, and metamodel. Exchanges are expressed within a 

taxonomy that includes agencies, lines of business, activities, documents, and 

services. While these are all within the justice domain, stakeholders can readily 

expand the framework to additional domains. 

 Each level of the taxonomy has associated metadata to produce a consistent, 

understandable description of the business, document, and service components. 

 As much as possible, components in the architecture are described and united by 

graphical models using tools based on standards such as Business Process 

Modeling Notation language and Unified Modeling Language. 

 Operational metrics, performance measures, and key indicators are needed in the 

architecture metamodel to assist jurisdictions in determining the relative value of 

exchanges and how information sharing addresses business challenges. 

 Gaps exist in the corrections, supervision, and community services areas that need 

more subject matter expertise and research to resolve and close. 

Operational View Recommendations 

1. Develop a logical enterprise-level graphical representation of the NIEM model to 

establish a visual representation and ensure the integrity and coherency of the 

model, with the “Type” elements in the justice domain being the likely input. 

2. Create guidelines on how to develop Business Information Exchange 

Components, including samples that align with the NJDA Business Reference 

Models. These would be the initial high-level data models of a national 

Information Reference Architecture. 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 61

3. NIEM: Assess and update the model definitions to eliminate tautological 

definitions and create more accurate business definitions. 

4. NIEM: Assess the model for new capabilities or techniques to include external 

standards (e.g., HL7, NENA) and nonstructured data (images, voice, and video) to 

support the “super-standard” concept as proposed by APCO/NENA.

5. NIEM IEPDs: Perform a quality assessment and report of the NIEM 

Clearinghouse IEPDs to confirm currency, accuracy, and compliance. 

6. NIEM IEPDs: Expand the meta-model to include the NJDA and add to the search 

capabilities of the clearinghouse. 

7. GRA SSPs: Evaluate the published GRA service specifications and determine if 

refactoring is needed. 

Design View

The Design View questions (Exhibit 26) address the technological infrastructure 

needed to support information sharing and are of interest to Technical Managers. 

Exhibit 26 provides a set of questions intended to be addressed by the Design View. 

Exhibit 26. Design View Questions 

Stakeholders can answer the Design View questions with content to be provided through 

user contributions and ongoing collection of information as technologies emerge and 

mature and as principles change and evolve. With respect to gaps in the Operational and 

Planning views (Question 4), researchers identified high-level gaps in the corrections, 

community supervision, and health services areas. 

These questions are not completely answered by the Design View, as the view was 

addressing the interests of web service designers and software developers rather than the 

supporting technologies. Examples of questions that the Design View can answer are: 

 “What set of services are needed to support the Issuance and Serving of a 

Warrant?”

Design View Questions NJDA Implementation Status NJDA Additional Recommended 

Capabilities/Comments

What is the typical state of 

implementation of supporting 

technology at the state and local 

levels of government?

The framework does not include 

a comprehensive state and local 

level perspective. 

Add a state and local perspective to 

the tool.

What networks and other national 

technology infrastructure elements 

are in place to support information 

sharing?

These are described in the tool. These would be an ongoing task as 

networks and technologies mature. 

What technical principles can 

inform choices of technology 

provisioning strategy (e.g., cloud or 

shared services)?

The framework does not address 

provisioning strategies and 

principles.

Add provisioning strategies to the 

framework. Would need to adapt it. 

Where are the gaps in what the 

Operational and Planning Views 

require?

These would be identified through 

subject matter expert review.

Affirm and adapt the framework.

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 62

 “What are the methodologies and guidelines to identify and decompose services?”

 “What service specifications exist for services to support Court Case Filing?”

Design View Findings 

 The GRA provides valuable guidance that aligns with the archetypes and provides 

sufficient detail to develop consistent, interoperable service designs. 

 The data architecture tool is robust and communicates “traceability” from 

business problems and evidence to data. This approach was used to develop the 

research tool used by the project. 

 Identifying archetypes for data exchanges leads to a simplified data architecture 

that can focus on key justice information objects like arrests, incidents, and 

dispositions. Stakeholders can use three basic information flow archetypes to 

describe nearly all information flows in the justice system. These archetypes 

recast prior concepts like “push,” “pull,” “publish,” “subscribe,” etc. to a more 

service oriented model. These archetypes are:

Events: In the event-driven service interaction flow archetype, the 

information exchange begins with the occurrence of a realworld business event that is either citizen-initiated (e.g., an 

arrest) or procedural (e.g., sentencing). The composite 

(intermediary) response under this archetype represents the 

enterprise response or “handling” of this event, which 

generally involves orchestrating individual component 

(responding entity) responses. Note that the component 

response can also trigger a subsequent event that would follow 

the same flow. 

Requests: In the request-driven service interaction flow archetype, the 

information exchange begins with a practitioner’s request for 

procedural action (e.g., requesting a warrant) or for some 

change in the state of the world (e.g., updating status of 

compliance with an offender’s terms of sentence). The 

composite (intermediary) response under this archetype, much 

like the composite response in the event-driven archetype, 

represents the enterprise response or handling of the request. 

Note that the component response can also trigger a subsequent 

event. Resources like the GRA and NIEM provide useful 

guidance that aligns with the archetypes, but there are 

insufficient guidelines and specifications to develop 

orchestrated service design. 

Queries: In the query-driven service interaction flow archetype, the 

information exchange begins with a practitioner’s or citizen’s 

desire to know information about the state or history of the 

justice system (including events that occurred and any 

responses to those events). The composite response under this 

archetype represents the enterprise effort to gather the 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 63

requested information from one or more component data 

sources and assemble the component responses into a single, 

enterprise response to the requester. 

 Portals with single sign-on and federated capabilities — such as RISSNET,38

Pennsylvania’s JNET,39 and Vermont’s Justice Information Sharing System 

(VJISS) Portal40 — are increasingly being used to simplify user authentication 

and management. 

 The PSAP/CAD/RMS industry is rapidly adopting unstructured, nontext 

technologies into their solutions, thereby rendering a data-rich source of incident 

information (voice, images, and video). 

 REST/JSON41 is increasingly being adopted as a technology to represent and 

exchange information; it is not yet fully supported in the justice data architecture. 

However, Global is working to include these in the standards. 

Design View Recommendations 

1. Perform a gap analysis on an LoB-by-LoB basis to determine the services needed 

to support the Business and Information Reference Models. 

2. Create profile specifications that incorporate Security Assertion Markup 

Language (SAML), GFIPM, and eXtensible Access Control Markup Language 

(XACML) elements in tiered levels of security, identity, and information 

assurance. 

3. Develop a multi-layer framework that includes NIEM and GFIPM elements and 

possible security aspects such as SAML or Trustmark that equals and satisfies 

FBI Criminal Justice Information Services (CJIS) Security requirements for 

Internet and public message transport. These could be the foundation for a NJDA 

Security Reference Model. 

4. Establish an ongoing committee to evaluate open source solutions, SOA 

deployment practices, model-driven tools, cloud services, and emerging 

technologies, and make recommendations on inclusion or relationships with the 

NJDA Technology Reference Model. The intent is to strengthen enabling assets 

and resources to increase the ease of information sharing deployment. 

5. Develop a Security Reference Model, possibly using the National Institute of 

Standards and Technology’s (NIST) A Framework for Improving Critical 

Infrastructure Cybersecurity (February 2014). 

 

38 https://www.riss.net/ 

39 http://www.portal.state.pa.us/portal/server.pt/community/jnet_internet

40 http://www.ojbc.org/files/VermontOJBCspotlight.pdf 

41 Representational State Transfer/JavaScript Object Notation. 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 64

Summary of Views Analysis 

A key premise of the data architecture is that it useful and valuable to practitioners 

concerned with developing an enterprise view of the justice system. Researchers divided 

practitioners into three groups and developed separate views of the architecture to address 

the needs and requirements of these groups. To assess the benefits of the architecture to 

these groups, researchers posed and evaluated questions germane to each group at the 

outset of the project: seven questions under the Planning View, nine questions under the 

Operational View, and four questions under the Design View. Exhibit 27 summarizes the 

ability of the framework to address these questions. 

View Number of 

Questions

Number of Questions the 

Framework Addresses

Percentage Addressed

Planning 7 5 71.5%

Operational 9 7 77.7%

Design 4 2 50.0%

Total 20 14 70.0%

Exhibit 27. Summary of Research Questions 

The framework was able to collect information that pertains to and provides a means to 

evaluate 14 of the 20 reference questions posed — or 70%. This represents a reasonable 

degree of utility of the framework to meet real-world needs. This research identified other 

questions that stakeholders can address using the tool’s query capabilities. For example: 

 “What are the agencies that receive or send Arrest Reports?”

 “What documents are involved in moving subjects between jails and courts?”

 “What service capabilities should a Court provide to be fully web-enabled for 

electronic receipt of any court document?”

The framework consists of: 

 449 Content Pages 

 78 Semantic Properties for Query 

 24 Agencies 

 73 Activities 

 152 Documents 

The Adult Felony Reference Model provided baseline data on exchanges that were 

incorporated into the NJDA. The NJDA documents a total of 680 exchanges, yet less than 

10% are represented by existing national standards, although several states have 

published suites of IEPDs that could be adapted into national standards 42

 

42 The California DOJ published 44 IEPDs in 2008–09 under their Data Exchange Project. The Texas 

Department of Public Safety published 28 IEPDs in 2007–08 under their “Path to NIEM” project.

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 65

Implications for Further Research 

The implications discussion is organized by NJDA Views within the tool, and expanded 

upon in the following recommendations. The associated recommendations represent 

proposed activities for the upcoming year in collaboration with the National Institute of 

Justice (NIJ). SEARCH previously reported the following preliminary findings, which 

continue to be valid based on continued research: 

The following represents proposed activities to be undertaken with appropriate 

collaboration partners to extend the NJDA Framework and expand the content. 

Extending the NJDA Framework Taxonomy 

The framework consists of a taxonomy structure with each level having a set of metadata,

except for the first level: 

 Domain/Line of Business/Activity/Document/Service 

In this manner, a service, e.g., Arrest Reporting Service, is categorized thusly: 

 Criminal Justice/Investigation/Arrest without Warrant/Arrest Report/Arrest 

Reporting Service

This taxonomy serves the Operational and Design Views but lacks support for the 

Planning View. The framework could be extended with an additional taxonomy, such as 

the “Line of Business” level connecting the two taxonomies (conceptual): 

 Domain/Line of Business/Challenges/Programs/Evidence-Based Research 

In this manner, research could be categorized with metadata about metrics and 

performance results. 

Adding a state and local perspective would likely require a change to the framework by 

adding a level between “Domain” and “Line of Business” to (conceptual): 

 Domain/Jurisdiction/Line of Business/Activity/Document/Service 

Users could extend the framework to support Security, Identity, and Policy, either 

through a separate taxonomy and/or metadata. For example, they could extend the 

document category metadata with security considerations, or the service category 

metadata with policy considerations. 

Based on metadata, query development is preliminary and basic. If the metadata is 

considered adequate, users can quickly develop extensive queries, but requirements for 

“What questions are to be answered?” is needed. If the metadata does not support those 

questions, users can extend the metadata by adding metadata elements or adding values to 

existing elements. 

Developing Business Information Exchange Components into the framework would 

introduce another level of semantic capabilities to the information model. 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 66

Expanding the NJDA Content 

Corrections: The corrections and supervision activities need additional subject matter 

expertise to affirm and adapt the business process models, activities, documents, and 

services. This represents a discovery gap in the research materials for authoritative 

information. California and Colorado are implementing comprehensive offender 

management systems that might provide input to creating reference SSPs and IEPDs that 

align with emerging reforms in corrections. Emerging corrections reforms are making 

distinctions between jail and prisons (Hall, 2006) (Schlanger, 2003) that could argue for a 

separate line of business between detention and incarceration. 

Health/Mental Health: The recommendations that came out of Aligning Justice to 

Health Priority Exchanges Task Team Final Report, 2014 could begin the expansion by 

adding a health and human services domain: 

 Health and Health Services/Line of Business/Activity/Document/Service 

Semantically connecting a Health and Human Services domain to the Criminal Justice 

domain would likely come through the “Triggering” and “Subsequent” activities property 

of “Activity” and the “Sending” and “Receiving” agency property of a “Document.” This 

may also encompass expanding into health interoperability standards, such as the 

Electronic Health Record (EHR), Emergency Responder Electronic Health Record (EREHR), and the Medication Management Interoperability Specification (MISP). 

Incident/Emergency Management: The National Incident Management System 

extensively documents organizations, processes, and information to plan, prepare, 

respond, recover, and mitigate all-hazard incidents and disasters. The associated five 

plans would easily translate to the framework and taxonomy, as they are similarly 

structured with organizations, activities, processes, and information. The metadata of the 

taxonomy would likely need to reflect the emergency management/first responder 

community rather than law enforcement. 

Governance: For the data architecture tool to become sustainable for extension and 

expansion, stakeholders would need to develop a governance plan for technical support, 

framework design, user administration, and content contribution and review. They would 

also need to develop policies regarding privacy, security, and copyrights. A working 

group might be considered with credentialed members from justice, health, and incident 

management domains. 

Summary 

This analysis of the Criminal Justice System’s Data Architecture had two objectives: 

1. A report that documents: 

o The current as-is national data architecture for information sharing among 

criminal justice agencies at all levels of government, and between criminal 

justice agencies and their partners in related domains such as first responders, 

health, and social services agencies; 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 67

o Any gaps or misalignments in the architecture as measured against a 

conceptual target; and 

o Recommendations for strategy, standards, information, and technology 

changes necessary to close the identified gaps. 

2. An information sharing framework and associated tools to capture and document 

the current and to-be state of a National Justice Data Architecture. This 

framework includes three perspectives, or “views,” that address the needs of 

specific stakeholders based upon their role and primary responsibilities and assist 

in decision-making: 

o Planning View: Senior executives, division managers, and strategic planners 

to identify goals and policy initiatives and to allocate resources at the strategic 

level; 

o Operational View: Architects and business managers responsible for 

designing integrated justice systems and information flows at the business 

level; 

o Design View: Technology architects and developers to make decisions about 

service oriented technologies and technical designs at the implementation 

level. 

In conducting research and analysis for the first objective, SEARCH determined that 

synthesizing aspects or elements of Enterprise Architecture (EA), Business Process 

Modeling (BPM), and Service Oriented Architecture (SOA) provided the best approach 

to represent the data architecture framework. This objective was achieved for information 

sharing within the justice domain, but there was a gap in sharing with nonjustice 

domains. 

In order to complete the gap analysis, SEARCH developed a framework and tool that 

combined elements of EA, BPM, and SOA. SEARCH developed the tool using open 

source products, and it can be used to capture and document the data architectures of 

other domains. For the second objective, applying principles of EA was foundational to 

developing the data architecture framework. The objective was achieved using the 

available research materials and published specifications, and the framework is readily 

able to represent the justice data architecture. 

The analysis and framework confirms that through a model-driven approach, a National 

Data Architecture can provide a systematic methodology to identify and create crossagency information sharing plans that can be incrementally implemented through 

expanding services capabilities. Employing the principles of EA, BPM, and SOA 

provides justice stakeholders the agility to respond to new business needs, introduce new 

technologies, and more readily comply with legal and regulatory changes. The result is a 

well-defined, reusable set of components and services based on standards that work for 

all exchange partners with respect to business, information, and security requirements.

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 68

V. References 

APCO International and IJIS Institute. (2013). Recommendations of the Emergency 

Communications Task Force. APCO Internationsl. 

Arsanjani, A., Ph.D, Ellis, M., Allam, A. (2014, August). SOA Designing through 

Reference Architectures. IBM developerWorks. 

Colorado Office of Information Technology. (n.d.). OIT FY16 Playbook Strategic 

Planning Roadmap. Retrieved from Colorado Office of Information Technology: 

https://drive.google.com/file/d/0B29p7msKOLwAcWYwUkhUUmY3SzA/view 

Hall, D. (2006, February). American Correctional Association Report Jail vs. Prisons. 

Corrections Today, p. 8.

Hay, D. C. (2014). NIEM Core Evaluation. Houston, TX: Essential Strategies. 

Hollywood, J., & Winkelman, Z. (2015). Improving Information Sharing Across Law 

Enforcement: Why Can't We Know? RAND Corporation, NIJ. 

IBM. (2008). Pursuing Operational Exellence in IT. IBM. 

IBM. (2011). Combining Business Process Management and Enterprise Architecture for 

Better Business Outcomes. Poughkeepsie, NY: IBM. 

Jacobson, M. (2013). Kentucky eWarrants Case Study. Sacramento: SEARCH. 

Jenson, C., Charters, I., Amsdens, J., Darlington, J., Owen, M., & Eric, H. (2008). 

Leveraging SO, BPM and EA for Strategic Business and IT Alignment. IBM SOA 

Foundation Group. 

Kim, K., Becker-Cohen, M., & Serakos, M. (2015). The Processing and Treatment of 

mentally Ill Persons in the Criminal Justice System. Washington, DC: The Urban 

Institute. 

Lews, G., Cormella-Dorda, S., Place, P., Plakosh, D., & Seacord, R. (2001). An Enteprise 

Information System Archittecture Guide. Pittsburgh: Carnegie Mellon University, 

Software Engineering Institute. 

NASCIO. (2008). http://www.nascio.org/portals/0/EAToolKit/NASCIO-EAToolKitIntroGovernance.pdf. Retrieved 2016, from NASCIO Organization EA Toolkit. 

Newcombe, T. (2010, September). Merging IT Systems Causes Problems for States and 

Localities. Governing the States and Localities. 

Newcombe, T. (2014, November). Is e-Gov Really Delivering. Government Technology. 

NIEM Technical Advisory Committee. (2011). NIEM Busines Information Exchange 

Components. Washington, DC: Department of Homeland Security. 

O'Brien, W. (2002). Enterprise Information. Pittsburgh, PA: Software Engineering 

Institute, Carnegie-Mellon. 

Office of Management and Budget. (2014). Annual Report to Congress, Benefits of EGovernment Initiatives. Washington, DC: United States Congress. 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 69

OpenGroup Organization. (n.d.). TOGAF Version 9 Chapter 3.62. Retrieved from 

OpenGroup Organization: http://pubs.opengroup.org/architecture/togaf9-

doc/arch/chap03.html#tag_03_62 

Patton, Z. (2010, February). The Push to Consolidate. Governing the States and 

Localaties.

President's Commision on Law Enforcement. (1967). Challenge of Crime in a Free 

Society. Washington, DC: U.S. Government Printing Office. 

Rigby, D. K. (2015). Management Tools 2015 An Executives Guide. Boston, MA: Bain & 

Company. 

Roberts, D. J. (2001, Revised 2004). Integration in the Context of Justice Information 

Systems. SEARCH. 

Robertson, D., Ross, J., & Weill, P. (2006). Enterprise Architecture as Strategy: Creating 

a Foundation for Businss. Harvard Business Press. 

Schlanger, M. (2003). Differences Between Jails and Prisons. (p. 8). Harvard Law 

School. 

Senna, J. J., & Siegel, L. J. (2002). Introduction to Criminal Justice, 9th Edition.

Stamford, CT: Wadsworth Thomson Learning. 

White House. (2012). National Strategy for Information Sharing and Safeguarding.

Washington, DC: United States Government. 

Zanuz, L., Barcelos, G., Filippetto, A., & Pinto, S. (2008). U-SOA: Towards a 

Ubiquitous SOA Platform. XIV Brazilian Symposium on Multimedia and the Web

(p. 108). ACM Digital Library. 

Ziemann, J. (2010). Architecture of Interoperable Information Systems. Berlin: 

University of Saarlandes. 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 70

VI. Appendices 

Appendix A. Solving Problems Using the NJDA – Practical Application of 

the Architecture 

The following discussion presents use cases to demonstrate how the NJDA assists in 

defining an information exchange and enabling services, and then orchestrating a set of 

services into a series of exchanges that support a full, interagency business process. 

These are not intended to be normative but illustrative and a starting point for exchange 

partners to examine and adapt to their particular information assets. Also, note that this is 

an abbreviated set of artifacts that would be associated with each use case. 

Use Case 1: Court Case Filing 

District courts would like to electronically receive prosecution case and charge 

information in order to reduce data entry, decrease data errors, and reduce the overall 

time for a judge to review a case filing. 

Starting with the NJDA document category, a user can find applicable documents and 

supporting information artifacts for the use case, such as the Bill of Information and a 

Charge Complaint, information models, and related service specification. 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 71

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 72

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 73

Use Case 2: Open Court Case 

Prosecutors’ offices would like to electronically receive the court clerk’s review of the 

case filing documents and an indication of whether the case will proceed to a judge’s case 

review. This will reduce data entry and increase timeliness of case processing. 

Using the NJDA document category, a user can find applicable documents and 

supporting artifacts for the use case, such as the Court Case or Court Case Deficiency 

Notification, information model, and the Court Case Decision Service. 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 74

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 75

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 76

Use Case 3: Charge Referral 

The County law enforcement agencies and prosecutor’s office would like to 

electronically share charge referral documents to reduce data entry for both agencies, 

eliminate time-consuming hand-delivery of documents by law enforcement, and speed 

the overall time to court case filing. The partners agree that only misdemeanor charges 

are within the scope of this use case. 

Using the NJDA activity category, the partners use the NJDA Charge Referral activity 

(within the investigation process) to find applicable documents and supporting artifacts 

for the use case. Working together, the exchange partners agree on the following business 

rules for the Charge Referral information package: 

 For a Cite and Release misdemeanor, only the citation is needed 

 For an Arrest without Warrant misdemeanor, incident and arrest reports are 

needed. 

The partners review the NJDA charge referral and incident service interaction models. 

They decide to adapt the service interaction model that accomplishes the full requestresponse process of submitting a charge referral and receiving the prosecutor’s decision.

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 77

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 78

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 79

Use Case 4: Business Scenario – Electronic Court Case Filing (e-Filing) 

A decentralized county court system currently receives more than 30,000 court case 

charge filings a week. Court caseloads have been increasing annually by 3–10% in their 

nine court divisions (e.g., civil, criminal, family law). Court and prosecution data entry 

costs are increasing, data accuracy is decreasing, case filing time is lengthening, and there 

is frequent data loss. Additionally, the court is out of full legislative compliance with 

providing public access to court cases and case information within 30 days of filing. 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 80

Use Case 5: Planning 

The senior stakeholders who have an interest in the outcomes hold initial discussions to 

establish the project. The stakeholders agree to initiate an Electronic Court Case Filing 

information sharing project between the superior court case management system (CMS), 

the district court’s CMS, and the prosecuting office’s CMS. The NJDA presents the 

following questions for senior leadership to consider, answer, and document: 

 What policy objectives do we seek to achieve with information sharing?

 What current business challenges does the justice community face, and how can 

we address those problems with information sharing?

 What risks are inherent in information sharing, and how do we mitigate those 

risks? 

 What governance models are in place to establish ownership and control over 

information and information exchanges?

 Are there principles to determine who should provision and control information 

and exchanges?

 What strategic plans exist currently, and what is the progress toward those plans? 

How do jurisdictions and agencies align with those plans?

 Who is — or should be — exchanging information?

 What are the measures of success?

 What mechanisms are available to fund justice information exchange

development and maintenance?

The NJDA Planning view helps document the outcome of planning activities by 

providing planners reference material to develop the Performance Measures (PRM) and 

to contribute to areas of the Business Reference Model (BRM) and the Security 

Reference Model (SRM).

PRM: Performance measures are statements of objectives that have accompanying 

measurements and timelines, and are associated with a line of business. Within an 

information sharing initiative, all exchange partners should jointly develop these. Agency 

strategic plans are good sources to identify goals and objectives that exchange partners 

share; they can use these as input for performance measures. For this business scenario, a 

partial list could take the form of: 

 “By 2Q16, district courts will be able to complete civil, traffic, family, and 

probate case filing reviews and notifications within 5 business days of prosecution 

case referral submission. 

 By 3Q16, district courts will be able to complete criminal and appellate case filing 

reviews and notifications within 10 business days of prosecution case referral 

submission. 

 By 4Q16, all appropriate cases, case information, and case updates will be 

available for public access within 48 hours of being updated in the court systems. 

 By 1Q17, electronic information and data audits will be in place to eliminate data 

loss and ensure data consistency.”

These are the incentives that subsequently determine what business capabilities that 

stakeholders need to develop or improve to meet the performance objectives. The NJDA 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 81

is developing evidence-based research content to help identify proven performance 

measurements. 

BRM: The NJDA provides line of business (LoB) functional models from various views 

and levels. For example, the “Prosecution Line of Business” is a single agency view,

while the Court Case Interaction Process is a cross-agency view of the performed 

functions. 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 82

For this business scenario, a partial list of business capabilities may specify that: 

 “A district court CMS can accept a complaint for a civil case from a prosecution 

CMS. 

 A district court CMS can accept a bill of information for a criminal case from a 

prosecution CMS.

 A superior court CMS can accept a civil case from a district court CMS.

 A superior court CMS can accept a criminal case from a district court CMS.

 A district court can accept a ‘case accepted’ notification from a superior court.

 A prosecution CMS can receive a notice of the outcome from a court case filing.”

SRM: Within an information sharing initiative, the security reference model is concerned 

with protecting data assets from perspectives of access, usage, confidentiality, and 

accountability at every layer of the exchange. 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 83

Use Case 6: Operational Assessment and Requirements 

Operational business managers, IT development managers, and architects complete the 

Business Reference Models and the Information Reference Model. The NJDA presents 

the following questions, which these managers and architectures should consider, answer, 

and document: 

 What systems typically capture or record information about the business 

functions? 

 What are the detailed business processes of the business functions? 

 What is the content (structure and meaning) of the exchanged information? 

 What is the quality level of the available data assets? 

 What “nonfunctional” requirements apply to each exchange? 

 Do any existing specifications map into the requirements, or are there any 

applicable reference specifications? 

 Is there a rational sequence of deploying the exchanges that provide incremental 

benefit? 

BRM: The business capability statements in the BRM are more completely documented 

in refined and exchange partner-specific business process models, preferably in 

standardized languages such as Business Process Notation Language. The NJDA helps 

develop these models by providing decomposed business process models, information 

models, and agency data flows. The following charge filing process diagram is an 

example of the decomposition of the case charge filing interaction, which provides input 

into the web service design and orchestration. Stakeholders should prepare as many 

models as needed to document all the business exchange capabilities. It is not necessarily 

needed to document the agency’s internal business activities, but reviewing those 

processes could expose opportunities for different or more effective information 

exchange points. The business models depict the information to be shared or exchanged,

which is the input to the Information Reference Model. 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 84

IRM: The information reference models are the core of an information exchange 

environment. They contain source data models, information exchange models, target data 

models, information orchestration, data quality, and applicable data technology standards. 

The starting point for the IRM is: What documents or messages are to be shared or 

exchanged? In this scenario, charge filing and prosecution case information is to be 

shared. The NJDA uses both description information and class diagrams from published 

specifications from NIEM or the GRA, depicted in the following illustration for a Bill of 

Information. Stakeholders can assemble and refine these to assist in developing the IRM. 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 85

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 86

Use Case 7: Service Assessment and Design 

IT development managers, SOA architects, and SOA teams complete the Application 

Reference Models and the Information Reference Model. The NJDA presents the 

following questions, which these managers and architects should consider, answer, and 

document: 

 What is the typical state of implementation of supporting technology within the 

information sharing partners?

 What networks and other technology infrastructure elements are in place to 

support information sharing?

 Where are there gaps in what the operational and planning views require?

The NJDA provides summary reference information on published service specifications; 

in this scenario, these are the Case Filing Service and the Court Case Decision Service.

These two services achieve and are traceable back to the business requirements of:

 A district court CMS can accept a complaint for a civil case from a prosecution 

CMS. 

 A district court CMS can accept a bill of information for a criminal case from a 

prosecution CMS.

 A prosecution CMS can receive a notice of the outcome from a court case filing. 

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

necessarily reflect the official position or policies of the U.S. Department of Justice 
Analysis of the Criminal Justice System’s Data Architecture 87

Appendix B. Links to Federal and State Enterprise Architecture Sites 

 Federal Government: https://www.whitehouse.gov/omb/e-gov/FEA 

Arizona: https://aset.az.gov/strategy/enterprise-architecture 

http://www.azcourts.gov/

 California: http://www.cio.ca.gov/ea/

 Colorado: http://www.oit.state.co.us/cto/ea

 Kentucky: http://technology.ky.gov/Governance/Pages/KITS.aspx 

 Michigan: http://www.michigan.gov/dtmb/0,5552,7-150-56355_56580---

,00.html 

 North Dakota: http://www.nd.gov/itd/services/enterprise-architecture

Oregon: http://www.oregon.gov/DAS/CIO/ITIP/pages/ 

pol_arch_overview.aspx

Virginia: http://www.vita.virginia.gov/oversight/default.aspx?id=349

This resource was prepared by the author(s) using Federal funds provided by the U.S. 

Department of Justice. Opinions or points of view expressed are those of the author(s) and do not 

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