Washington State Courts Enterprise Data Architecture Version ...

John O’Conner ENTERPRISE DATA ARCHITECT ADMINISTRATIVE OFFICE OF THE COURTS WASHINGTON STATE COURTS

Washington State Courts

Enterprise Data Architecture

Version 1.0

July 18, 2007

ENTERPRISE DATA ARCHITECTURE VERSION 1.0 TABLE OF CONTENTS 07/18/2007

Table of Contents Enterprise Data Architecture Overview.....................................................................................................1

Introduction ...........................................................................................................................................1 What is the Enterprise Data Architecture?............................................................................................2 What are the Components of the Enterprise Data Architecture?..........................................................2 What is the Role of the Enterprise Data Architecture? .........................................................................3 How does the AOC develop the Enterprise Data Architecture? ...........................................................4 How does the AOC use the Enterprise Data Architecture? ..................................................................4 Conclusion ............................................................................................................................................5

Data Management Strategy Overview......................................................................................................6 Introduction ...........................................................................................................................................6 What is the Data Management Strategy? .............................................................................................6 What is the Approach to Data Management? .......................................................................................7 What are the Benefits of using the Data Management Strategy?.........................................................8 What are the Components of the Data Management Strategy? ...........................................................8 How does the AOC use the Data Management Strategy? ...................................................................8 Conclusion ............................................................................................................................................8

Data Governance......................................................................................................................................9 Introduction ...........................................................................................................................................9 EDA Administration...............................................................................................................................9 EDA Policies .......................................................................................................................................12 EDA Business Process Development.................................................................................................15 Data Governance Conclusion .............................................................................................................17

Data Architecture ....................................................................................................................................18 Introduction .........................................................................................................................................18 What are the Components of the Data Architecture? .........................................................................18 Metadata .............................................................................................................................................18 Data Accountability .............................................................................................................................20 Data Standards Development.............................................................................................................22 Conclusion ..........................................................................................................................................22

Data Sharing Architecture.......................................................................................................................23 Introduction .........................................................................................................................................23 What are the Components of the Data Sharing Architecture?............................................................24 Data Sharing Management .................................................................................................................24 Quality Control ....................................................................................................................................24 Data Protection ...................................................................................................................................25 Data Sharing Standards......................................................................................................................25 Conclusion ..........................................................................................................................................26

Conceptual Data Model ..........................................................................................................................27 Introduction .........................................................................................................................................27 What is the Conceptual Data Model? .................................................................................................28 What are the Components of the Conceptual Data Model? ...............................................................28 How is the Conceptual Data Model Developed? ................................................................................29 How does the AOC use the Conceptual Data Model?........................................................................31 Conclusion ..........................................................................................................................................31

Logical Data Model .................................................................................................................................32 Introduction .........................................................................................................................................32 What is the Logical Data Model? ........................................................................................................33 What are the Components of the Logical Data Model? ......................................................................33

PAGE i

ENTERPRISE DATA ARCHITECTURE VERSION 1.0 TABLE OF CONTENTS 07/18/2007

How is the Logical Data Model Developed? .......................................................................................34 How does the AOC use the Logical Data Model?...............................................................................35 Conclusion ..........................................................................................................................................36

Data Standards Table.............................................................................................................................37 Introduction .........................................................................................................................................37 What is a Data Standard?...................................................................................................................38 What are the Benefits of using Data Standards?................................................................................38 What are the EDA Data Standards? ...................................................................................................39 How are the EDA Data Standards Developed? ..................................................................................39 How does the AOC use the EDA Data Standards? ............................................................................41 Conclusion ..........................................................................................................................................42

Enterprise Data Architecture Summary ..................................................................................................43 Introduction .........................................................................................................................................43 EDA Components ...............................................................................................................................43 Implementing the EDA........................................................................................................................44 Using the EDA ....................................................................................................................................45 Conclusion ..........................................................................................................................................45

PAGE ii

ENTERPRISE DATA ARCHITECTURE VERSION 1.0 OVERVIEW 07/18/2007

Enterprise Data Architecture Overview

Introduction The Administrative Office of the Courts (AOC) is responsible for maintaining a statewide data repository of court related data for all courts in the state of Washington. The Enterprise Data Architecture (EDA) describes the framework that supports the collection, manipulation, and dissemination of that data.

In order to fully understand the EDA, it is necessary to first understand its place in the Enterprise Architecture. The Enterprise Architecture contains three interrelated architectures: the Business Architecture, the EDA, and the Technical Architecture. These architectures are individual, yet indivisible pieces that together describe the Enterprise Architecture.

The EDA and the Business Architecture are closely related architectures. The two architectures are connected and aligned with the business requirements that filter through the Business Architecture and are represented within the EDA. The two architectures are different views of the same integrated enterprise architecture, not truly separate architectures.

Purpose The EDA provides a framework for managing the AOC enterprise data. This framework describes a long-term vision of the data and defines a strategy for reaching that vision. In addition, the framework describes a mechanism for validating alignment of data designs with that vision.

The EDA provides a representation of the AOC enterprise data requirements along with the guidelines to assist in the implementation of these requirements. This representation is derived from the same business requirements that drive the business architecture and the technology architecture for the AOC. The result is a unified enterprise architecture based on business requirements.

The EDA provides a basis for sharing data within the AOC and for sharing that data with organizations outside of the AOC. This sharing is facilitated by the clear and complete documentation of the data, taking into consideration the AOC security policies and data dissemination rules.

The EDA provides an administrative component for defining terminology, roles, guiding principles, and processes that manage the EDA. The EDA establishes processes for change tracking, auditing, and version control. The EDA provides a central repository for referencing all EDA related information.

The EDA specifies the documentation tools and techniques that are used to describe the AOC enterprise data. The structure and organization of this documentation is also specified in the EDA. This documentation is the result of the synthesis of the business requirements into data-centric representations of those requirements. These representations provide a conceptual ideal that serves as a common reference point when defining physical data structures for data communication and storage.

Scope The EDA applies to the enterprise data at the AOC. The AOC enterprise data is all the data that is used in the course of business at the AOC. Although the EDA framework accommodates this inclusive definition of enterprise data, the primary focus of the EDA is the statewide court data. The scope of the EDA expands around that core set of data as directed by the EDA governance body.

PAGE 1 OF 45


The EDA does not apply to organizations outside of the AOC, although other organizations may choose to adopt this architecture. The sharing of a common architecture facilitates the sharing of data represented by that architecture.

This document answers the following questions:

• What is the Enterprise Data Architecture? • What are the components of the Enterprise Data Architecture? • What is the role of the Enterprise Data Architecture? • How does the AOC develop the Enterprise Data Architecture? • How does the AOC use the Enterprise Data Architecture?

What is the Enterprise Data Architecture? The EDA is the AOC vision of its enterprise data. This vision is conceptual in nature and represents the ideal data representation from which data designs are created and against which data designs are evaluated. The EDA includes descriptions of the data and mechanisms for managing the data as well as for managing the descriptions themselves.

The EDA includes principles and the policies that follow from those principles. Also included in the EDA are those processes that are fundamental to establishing and managing the EDA. Definitions are provided within the EDA to clarify the terminology used within the EDA and to specify the key roles involved in the management of the EDA. The EDA specifies the standards that are applied throughout the EDA.

The EDA is a collection of documents that describe the AOC enterprise data. These documents are a combination of graphical and textual descriptions of the AOC enterprise data and the EDA itself. The EDA includes a repository for these documents and the processes for managing this repository.

What are the Components of the Enterprise Data Architecture? The EDA is organized around four components:

• Data Management Strategy (DMS) • Conceptual Data Model (CDM) • Logical Data Model (LDM) • Data Standards Table (DST)

Data Management Strategy The DMS provides a structure that facilitates the development of data and that can be effectively shared across information system boundaries. The key sections of the DMS are:

• Data Governance: details the policies that control the management of the enterprise data, and outlines the processes that support those policies. This section of the DMS also includes the administrative tasks of identifying roles, defining terminology, and establishing an EDA change process.

• Data Architecture: explains the management of the metadata that describes the enterprise data.

• Data Sharing Architecture: addresses the issues that result from the sharing of data.

Conceptual Data Model The CDM extends the enterprise business model by using data modeling methods and terminology to organize and describe the data objects. The CDM provides a foundation that subsequent data models use in order to maintain consistency with the enterprise business model.

PAGE 2 OF 45


Logical Data Model The LDM is a detailed data model. In some respects it can be thought of as a structured inventory of the enterprise data elements. Because the LDM is based on the CDM, data designs that are consistent with the LDM are consistent not only with the CDM, but also with the enterprise business model at a fundamental level.

Data Standards Table The DST is a collection of standards applicable to the administration and operation of the enterprise data. These standards support key design aspects and concepts that are defined within the EDA.

What is the Role of the Enterprise Data Architecture? The EDA is a major component of the enterprise architecture. It is the role of the EDA to serve as the focal point for the management of the data flowing through the enterprise. As shown in the following figure, the EDA has a relationship with both the business architecture and the technology architecture. The business architecture describes the business processes along with data input, data output, and shared data requirements. The technology architecture describes the technology enablers that are used in the implementation of individual system components as well as entire information systems. The EDA provides the bridge between the business view of the enterprise data (i.e., informational content) and the technical view of the enterprise data (i.e., data values).

The EDA within the context of the Enterprise Architecture

Link to the Business Architecture The business requirements specify the rules that determine data usage. The EDA receives these requirements primarily through the enterprise business model although some requirements come directly from the business requirements. There is a direct connection between the enterprise

PAGE 3 OF 45


business model and the CDM component of the EDA, but some information from the enterprise business model contributes to the deliverables of both the LDM and DST as well.

Link to the Technical Architecture The DST component of the EDA naturally leads into the technical model. Other components of the EDA may drive portions of the technical model as well. Although the technical model has the most direct impact on the implementation of system components, the EDA also influences these components.

How does the AOC develop the Enterprise Data Architecture? The EDA is developed incrementally. An increment may be the result of a periodic EDA review, be associated with an implementation project, or be a planned increment for building the EDA content. Each increment involves analysis of the relevant portion of the enterprise business model. The results of the analysis are incorporated into the enterprise data model, after which the compliance tracking system is consulted to determine which, if any, compliance reviews are affected by these changes to the enterprise data model. The status of each affected review is adjusted as appropriate.

Although EDA development is defined to follow from the enterprise business model, circumstances may exist that require development of the EDA in the absence of defined prerequisites. This course of action requires the approval of the Information Services Division Director. A list of alternative EDA development scenarios follows:

• In the absence of a business model, the business requirements are analyzed to determine the desired changes to the enterprise data model. These changes are tracked with a status that indicates they have not been validated against the business model.

• In the absence of defined business requirements, existing system components are analyzed to determine the desired changes to the enterprise data model. These changes are tracked with a status that indicates they have not been validated against the business requirements.

• In the absence of existing system components, existing data standards are analyzed to determine the desired changes to the enterprise data model. These changes are tracked with a status that indicates they have not been validated against any existing system component.

• In the absence of existing data standards, the defined processes for gathering business requirements and developing the enterprise business model are employed and the EDA development proceeds from the enterprise business model as defined.

How does the AOC use the Enterprise Data Architecture? The EDA strategy describes the current vision for the AOC enterprise data. This strategy serves as a guide for extending the EDA while preserving its connection to the rest of the enterprise architecture and its relevance to the AOC business rules.

The EDA data model is an authoritative source of information about the AOC enterprise data. This availability of consistent information about the enterprise data provides a common understanding of the data. This common understanding of the data benefits data entry, data exchange, and data reporting. It also facilitates reusability and data sharing.

The EDA is a resource for projects that use AOC enterprise data. The EDA serves as a reference point for answering questions about data design and data usage. In many situations the enterprise data model, along with the data standards, provide a starting point for data design for these projects. In addition, the EDA assists with project planning of scope and expertise for the data related tasks of the project.

PAGE 4 OF 45


The EDA provides data element traceability back to specific business requirements. This link to business requirements allows the enterprise data model to provide validation criteria to ensure that the enterprise business model includes functionality to support the complete lifecycle of each data element.

The EDA provides for the assignment of metrics that allow both internal and external data designs to be measured for compliance with the EDA. These metrics are also available for evaluating data sharing implementations and automation opportunities.

The standards-based nature of the EDA facilitates communication not only among the data professionals at the AOC, but also between AOC data professionals and professionals from both the business and technology areas. This communication, along with the link to the business requirements, allows the EDA to provide valuable assistance with the re-engineering of business processes, not only for AOC processes but for court business processes as well.

Conclusion The EDA is a fundamental component of the enterprise architecture. It provides the conceptual representation of the data requirements. This representation is developed incrementally in order to maximize EDA benefit while minimizing the impact of EDA development on implementation projects. The EDA helps to ensure that implementation decisions regarding the AOC enterprise data, align with court business needs and achieve business goals.

The EDA serves as a common understanding of the AOC enterprise data. This understanding promotes successful communication of data requirements and facilitates accurate sharing of data content.

The EDA describes administrative components for change control and centralized management of distributed system components and data content. This allows the EDA to evolve to accommodate changing business requirements and technology advances.

PAGE 5 OF 45

ENTERPRISE DATA ARCHITECTURE VERSION 1.0 DATA MANAGEMENT STRATEGY 07/18/2007 OVERVIEW

Data Management Strategy Overview

Introduction This section defines the Data Management Strategy (DMS) for the Enterprise Data Architecture (EDA). The Administrative Office of the Courts (AOC) exchanges and shares information with courts, state agencies, and other justice partners as well as various enterprises which are interested in court information. This is important as the AOC develops integrated systems that communicate effectively between diverse information systems.

AOC data and information activities include data sharing, integration, and reuse at the enterprise level, while maintaining data quality and integrity. The DMS coordinates this effort.

Purpose The purpose of the DMS is to document the administrative components needed to establish and maintain the EDA.

Scope The DMS addresses data at the conceptual level. Each implementation project is responsible for applying this strategy to its individual needs. A strategy associated with the physical data design, databases, and data stores will not be part of the EDA. Individual implementation projects are responsible for developing this strategy.

This section answers the following questions:

• What is the Data Management Strategy? • What is the approach to data management? • What are the benefits of using the Data Management Strategy? • What are the components of the Data Management Strategy? • How does the AOC use the Data Management Strategy?

What is the Data Management Strategy? The DMS provides a structure that facilitates the development of data that can be effectively shared across system component boundaries. The implementation of the DMS provides the principles, policies, and processes to meet the need for timely, accurate data. It will also provide an impetus for individual implementation projects to better understand the data and how it fits in the enterprise data models. The DMS addresses fundamental aspects of data that enable data sharing opportunities which position the AOC to operate in a data sharing environment.

There are practical considerations in the DMS:

• Data is important only to the extent that it provides business value. It is vital that all data in the EDA is associated with a business requirement.

• The world is constantly changing, and the data that describes it must also change. The EDA needs to minimize the effects of the lag between the need and use of new data and the adoption of standards.

There are several guiding principles for EDA development:

• EDA development accommodates data that is changing, which results in the following: – There are standard ways to describe data.

PAGE 6 OF 45


– Tools are required to process ambiguous data. – Translators are required to adapt non-standard data.

• EDA development is business driven: – Priority and extent of standardization is driven by business need. – Incremental business value is measured and evaluated to drive investment planning and

standards negotiations. • Security and privacy are integrated with data design and deployment.

The DMS supports the development of integrated systems that effectively communicate to achieve common goals through interoperability and common standards.

The DMS supports the EDA in many ways:

• Promotes an enterprise view that supports technologies that are aligned with court business processes and technologies.

• Takes a business value approach to standardizing data in cases where it provides the most value, while allowing flexibility to meet unique business needs.

• Provides data that is timely, accurate, usable, and easily accessible in order to support analysis and decision-making for court management and program administration.

• Promotes an environment that supports flexibility, adaptability, and rapid response to changes in programs and technology.

• Provides performance measurement for accountability and planning. • Supports the review process by providing a mechanism to evaluate requests and make

recommendations. • Creates an environment that facilitates data sharing. • Coordinates with justice partners to effect alignment between AOC enterprise data and

information in the justice community. • Develops mechanisms for measuring the effectiveness of data sharing to determine the

business value of further standardization. • Promotes common standards by promoting alignment with national standards organizations.

What is the Approach to Data Management? The DMS provides mechanisms to monitor and manage the environments in which the system components operate with respect to both the data standards and technologies. Data standards include the broad range of national initiatives, standards bodies, and other organizations engaged in defining or influencing standards. Technologies include open standards, protocols, middleware, and other mature or emerging technologies that facilitate data sharing.

The DMS promotes the prioritization of activities based on business needs and measures the resulting business value. Business value continually evolves as standards and data sharing solutions become more refined. Refining standards does not necessarily mean increasing the number of standards. Rather, standards are applied where they will provide business value.

The DMS accommodates technologies and specifies design requirements for data sharing and the associated processes and procedures. The resulting data architecture leads to the development of a successful data management environment.

Key elements addressed by the DMS are as follows:

• Metadata management specifications. • Standards that address key data management and data sharing concerns.

PAGE 7 OF 45


What are the Benefits of using the Data Management Strategy? The DMS provides the AOC with a strategy for combining tools, procedures, and processes to handle AOC enterprise data needs. The DMS provides the following benefits:

• Aligns information related activities and provides a roadmap to use in planning. Provides guidance for making decisions associated with information, data sharing, and integration.

• Reduces total cost of achieving quality goals by aligning and focusing information related activities.

• Provides an information structure that enables data systems to share data in formats that have a common definition resulting in consistent application across the enterprise.

• Reduces risk to system development by reducing custom solutions and promoting integration and data sharing.

• Increases overall quality of court management by improving information quality. • Allows individual justice partners to benefit from the information assets of other justice partners.

What are the Components of the Data Management Strategy? The DMS involves architecture, modeling, standards, metadata, management, interoperability, security and privacy, access methods, quality, and performance measurement. The three key components of the DMS are as follows:

• Data Governance defines the governance processes for making enterprise data decisions regarding AOC data systems. It provides the capability to determine and assign data ownership, to determine data standard adoption processes, to ensure data integrity, to define processes for accommodating new business requirements, and to establish a mechanism for arbitrating differences.

• Data Architecture establishes standard data management procedures for the EDA metadata. Specific guidelines are included regarding EDA documentation, data sharing development and use, applicable to both structured and unstructured data, and the management of metadata of all types. These guidelines ensure that data entities and attributes, data models, and relationships are sufficiently defined to convey the overall meaning and use of the data. Finally, the data architecture assigns accountability for the data.

• Data Sharing Architecture describes considerations for data sharing. The DMS describes standard data definitions and data sharing schemas. A centralized dictionary and directory maintain this information for general use. Each implementation project is responsible for knowing and understanding its environment (e.g., data, applications, and infrastructure) in order to map its data to data sharing requirements. In addition, the data sharing architecture addresses data semantics, shared data ownership, security and privacy implications of shared data, and the quality of shared data.

How does the AOC use the Data Management Strategy? • Implementation projects use the DMS for planning their data architecture. • Implementation projects are responsible for applying the DMS to their project work products. • Implementation projects use the DMS to identify business processes in their scope that do not

comply with the DMS. • For IT procurements, the DMS provides evaluation criteria for the RFP process.

Conclusion The DMS provides an enterprise approach for determining standards and documenting data requirements. Standards and documentation are the tools that enable successful data sharing.

PAGE 8 OF 45

ENTERPRISE DATA ARCHITECTURE VERSION 1.0 DATA MANAGEMENT STRATEGY 07/18/2007 DATA GOVERNANCE

Data Governance

Introduction Data Governance is the portion of the Data Management Strategy (DMS) that defines the governance structure for the EDA and describes the decision making processes of that governance structure. The governance structure establishes decision making roles, assigns authority to those roles, and provides a set of rules under which those roles make decisions.

Purpose Data Governance defines a strategy for consistent evaluation and improvement of the EDA, the data designs for the system components, and the AOC enterprise data. That strategy includes a mechanism to perform those evaluations and to recommend improvements.

Scope EDA Data Governance is responsible for decisions concerning the EDA which includes the contents of the Data Architecture Repository (DAR).

Data Governance is divided into the following components:

EDA Administration – This component describes the governance processes and defines the terms and the roles involved in those processes.

EDA Policies – These policies are the fundamental criteria for system component designs. Decisions regarding the EDA are consistent with these policies.

EDA Business Process Development – This component describes how new business requirements interact with the EDA.

EDA Administration Data Governance Administration is divided into the following components:

• EDA Terminology/Scope – Definitions of key terms and the scope in which they apply. • EDA Roles/Authority – The roles involved with defining the EDA, and the source of their

authority within the context of the EDA. • EDA Deliverables/Ownership – The work products for the EDA along with the owner of those

work products. • EDA Review/Approval – The components of the review and approval process and the criteria

for making approval recommendations. • EDA Compliance Review/Reporting – The components of the process for measuring the

degree of alignment between system components and the EDA and for the communication of the results.

EDA Terminology/Scope Business Process: A conceptual description of a unit of work within the enterprise. The EDA is particularly concerned with those processes that are part of the judicial business of one or more courts in the State of Washington. This does not include work incidental to the operation of a court, such as payroll and personnel.

Data Consumer: The recipient in a data interchange.

PAGE 9 OF 45


Data Owner: The person or organizational unit that is responsible for the source information that is entered into an information system.

Data Interchange: The movement of data from one information system to another.

Data Provider: The sender in a data interchange.

Data Interchange Participant: An information system that is involved in a data interchange. The sender and recipient are data interchange participants with each other.

Data Steward: The person or organizational unit that is responsible for accurately capturing and representing the source information that enters a particular information system.

Enterprise Architecture: A compendium of structural specifications that together provide a conceptual description of the system components of an organization.

Enterprise Data Architecture: One of three major components of the Enterprise Architecture focusing on the data aspect of the Enterprise Architecture.

Information Source: The person or organization that supplies information to an information system.

Information System: The implementation of the requirements for a set of integrated business processes. This term is applied to AOC applications, individual court applications and justice partner applications in Washington State, applications in other states, and applications developed by a vendor either for a specific organization or for general availability.

Key Data Area: A category of data knowledge. The five Key Data Areas for supporting the AOC EDA are:

– Application – Knowledge of data usage in AOC system components. – Dissemination – Knowledge of data being accessed by persons or organizations outside of

the AOC. – Documentation – Knowledge of the data dictionary, data diagrams, and standards and

procedures for modifying the data definitions for the AOC databases. – Integration – Knowledge of requirements for data that is shared between AOC applications

and organizations outside of the AOC. – Replication – Knowledge of data replication and transformation within the AOC.

System Component: The operational embodiment of business requirements. A system component is as simple as creating a service for a single business process, or as complex as creating an application for the complete set of business processes for an organization.

EDA Roles/Authority AOC – Administrative Office of the Courts: The representative organization for the courts in the State of Washington. The AOC has the authority, as well as the responsibility, to create and maintain a statewide repository for Washington State court data. This authority and responsibility has been mandated by the Washington State Legislature.

DARB – Data Architecture Review Board: A group of individuals responsible for reviewing and approving data architecture change requests. The members of the AOC Data Architectural Review Board are the Enterprise Architect, the Enterprise Data Architect, and the Enterprise Data Experts. The AOC Data Architecture Review Board is granted authority by the Enterprise Data Architect to approve EDA change requests.

Enterprise Architect: The role which is responsible for the architectural specifications of the

PAGE 10 OF 45


Enterprise Architecture. The AOC Enterprise Architect receives authority from the Information Services Division Director of the AOC.

Enterprise Data Architect: The role which is responsible for the architectural specifications and quality assurance of the data that is within the scope of the Enterprise Data Architecture, as well as for the designation of the Data Experts. The AOC Enterprise Data Architect receives authority from the Information Services Division Director of the AOC.

Enterprise Data Expert: An individual who has been identified by the Enterprise Data Architect as possessing expert knowledge in one of the Key Data Areas. The AOC Enterprise Data Architect grants the AOC Enterprise Data Experts the authority to approve EDA change requests and to participate in other data architecture decisions in an advisory role.

EDA Deliverables/Ownership DAR – Data Architecture Repository: The collection of documentation items that together describe the EDA. The Enterprise Data Architect is the owner of this repository and its contents.

EDA – Enterprise Data Architecture: The conceptual data architecture that serves as a model for the AOC system components. Because the EDA is a part of the Enterprise Architecture, the Enterprise Architect owns the EDA. But authority over, and responsibility for, the EDA is granted to the Enterprise Data Architect by the Enterprise Architect.

EDA Review/Approval EDA Change Request: This change request is a formal request that flows through the EDA review/approval process. Misspellings and grammatical errors are not part of this process. Those types of errors are corrected, tracked, and reported directly by the Enterprise Data Architect.

There are three types of change requests:

– EDA Document Change Request – This request is for changes to the EDA document structure or content. These changes are textual in nature and correct or clarify an architectural concept or description of an architectural component.

– Metadata Change Request – This request is for changes to the descriptions of the EDA metadata or of the data for a system component. Metadata is represented in multiple ways and includes text, diagrams, tables, and formatted data.

– Standards Change Request – This request is for changes to the standards within the EDA. A request for a standards change has an effect external to the EDA when the standard in question is owned by an organization which is external to the AOC.

Submission: EDA change requests are sent to the Enterprise Data Architect.

Tracking: The Enterprise Data Architect tracks each request in the EDA change request tracking system. Approved requests are prioritized, scheduled, and tracked to completion.

Review: The DARB reviews the EDA change requests and determines whether or not the request is approved. The request review is based on EDA success factors as measured on the following scales:

– Accuracy – The EDA is an accurate representation of the data requirements. – Accessibility – The EDA is available to everyone in the intended audience. – Clarity – The information in the EDA is readily understandable to the intended audience.

PAGE 11 OF 45


– Completeness – The intended audience of the EDA is able to find within the EDA any architectural information that they need for the implementation of a data architecture to support any business process in the Enterprise Architecture.

– Appropriate Standards – System components achieve their goals without the need to deviate from the EDA.

Approval: When a request is approved, the requestor is notified and the Enterprise Data Architect plans and schedules the requested change. A response that does not result in approval of the request includes a description of the issues preventing approval and lists any corrective actions to take to resolve these issues.

Standard Promotion: When a request for a standards change is approved for a standard that is external to the AOC, the change is also submitted for inclusion in the external standard as appropriate.

Completion: When the changes in an approved request are completed, the Enterprise Data Architect notifies the requestor, notifies the DARB, and closes the request.

EDA Compliance Review/Reporting Definition: Each policy and process step in the DMS has a quantifiable metric associated with it. The documentation for the metric definitions and instructions is available in the DAR. A metric consists of the following components:

– Description – This explains the purpose of the metric, the policy or process step it measures, and its quantification criteria.

– Rating – This describes the scale that is used to derive a qualitative value from a quantitative measurement result.

– Instructions – These are the procedures for gathering and recording the information associated with the metric.

– Audit Schedule – This indicates the frequency of measurement of the metric. This does not preclude additional measurements between scheduled dates.

– Corrective Action – This describes the process that addresses poor measurement results for this metric.

Recording: A metric measurement record specifies the metric being measured, the measurement result, a timestamp indicating when the measurement was taken, the implementation to which the metric applies, and the person or process who recorded the measurement.

Monitoring: Metric measurements are recorded periodically as indicated in the measurement schedule for each metric.

Evaluation: Metric measurements are reviewed and evaluated. Problem areas are identified and an overall status is determined.

Reporting: The results of the review and evaluation are consolidated into a report which recommends further action as appropriate.

EDA Policies Policies provide consistency and dependability, and enable reusability. They help maintain a high level of data sharing and data quality, and they help reduce costs.

The Data Governance Policies are expressed as action items for implementing guiding principles. These principles are divided into the following areas of concern:

PAGE 12 OF 45


• Data Standards – Principles that support data standards and their role in the EDA. • Data Quality – Principles for ensuring data accuracy, data integrity, data accessibility, data

security/privacy, data timeliness, and data access efficiency (i.e., performance). • Metrics – Principles for evaluating deliverables and for monitoring processes, and to identify

improvements and direct the implementation of those improvements. • Adaptability – Principles that anticipate and accommodate changes in the data structures and

in the metadata that describes those structures. • Integration – Principles that establish a basis for the interactions between the system

components. • Exceptions – Principles that address practical considerations for system components that

operate within imperfect, inconsistent, or incomplete business specifications.

Data Standards Principle: Standards are followed for every situation in which they apply.

• Compliance reviews are performed periodically to assess the alignment of each system component with the EDA.

• A record is kept of all out-of-compliance findings.

Principle: Each standard meets an identified business need.

• Each standard is periodically reviewed to validate its purpose and to assess how well it meets that purpose.

Principle: Global standards are preferred over local standards. This applies not only when defining new standards but also implies that an attempt will be made to gain global acceptance of local standards.

Standards are categorized as follows (from most global to least global):

– International – National – Industry – State – AOC – System Component

• The most global standard that meets the business needs of the EDA is adopted. • Local standards that meet global requirements are submitted to the appropriate organization

for acceptance as the global standard.

Principle: There is a defined process for reviewing, recommending, and approving modifications to the standards.

• The EDA Review/Approval process applies to data standards.

Data Quality Principle: There is one and only one source for each data element.

• All information sources for a particular data element use the same process to enter data into the AOC information system.

PAGE 13 OF 45


Principle: Data integrity and accuracy are assured before data is accepted in the AOC information system.

• All validation criteria for a particular data element are checked before a value for that data element is accepted by an AOC system component.

• Any data element whose value loses validity over time is associated with a validation timestamp.

Principle: Data is exchanged in consistent units of information.

• Data elements that are coupled within the AOC information system are delivered to other information systems only as a complete ordered set of those data elements.

• Coupled data elements are accepted by an AOC system component only as a complete ordered set of those data elements.

Principle: Data that has been replicated indicates the point in time for which it is valid.

• Each data element that is replicated within an AOC system component is associated with a replication timestamp.

Principle: Data transformations neither create nor destroy information.

• Data transformations do not default the value for any data element being transformed. • Data transformations do not initialize any data element being transformed. • Data transformations do not alter the value of any data element being transformed unless it

is to substitute an equivalent value. • Data transformations perform the same transformation for all occurrences of a particular

data element. Principle: Data arrival at an AOC system component is not arbitrarily delayed.

• There is a service level agreement in place that determines the acceptable delay between data arrival at an AOC system component and incorporation of that data into that system component.

Metrics Principle: Metrics exist to measure the efficiency and effectiveness of the EDA.

• Each metric represents a measurement of one or more quantifiable criteria. • Each metric is assigned to a role that is responsible for collection of that metric.

Principle: Metrics provide a means for taking corrective action.

• Each metric identifies the role that is responsible for implementing changes that improve the portion of the EDA that the metric measures.

Adaptability Principle: The EDA is not dependent upon a particular implementation technology.

• Technology specifications are expressed in terms of requirements in order to allow consideration of future technologies.

Principle: The EDA accommodates changes in business requirements and changes in technology opportunities.

• Data requirements are reviewed periodically to confirm current applicability. • The EDA is reviewed periodically for applicability to new and emerging technologies.

PAGE 14 OF 45


Implementation Integration Principle: System components enable the flow of data into and out of the information system via well-defined access interfaces based on common standards for access by either individuals or other information systems.

• System components support the communication standards specified in the Data Standards Table.

Principle: System components expose to the proper utility tool set the metadata necessary to determine data sharing potential.

• Metadata that describes data elements, and the entities into which they are grouped, is accessible via a universally accepted communication format.

Principle: System component metadata must provide a clear description of the data elements, and the data objects into which they are grouped.

• Each data object description explains the purpose of the data object and its relationship to other data objects.

• Each data element description explains the purpose of the data element and its relationship to other data elements.

Principle: System component metadata presents a complete and unified view of all data in the implementation.

• All data elements in the implementation are documented. • All portions of the data description are present for each data element and data object. • Each data element is associated with one, and only one, data object.

Principle: Data security and privacy is not implementation dependent.

• Data security and privacy are consistent across all system components.

Implementation Exceptions Principle: System components accommodate imperfect data, including ambiguous and nonstandard data.

• System components have documented procedures for managing invalid or inaccurate data.

Principle: The business need determines scope and conformity of a system component.

• A business case exists for each intentional out-of-compliance item.

EDA Business Process Development

Introduction The EDA is a conceptual architecture that serves as a model for the data architecture of system components. This makes the EDA an integral part of the development of business processes. Business process development is the primary method by which additions and modifications to the enterprise data model are identified.

PAGE 15 OF 45


What is EDA Business Process Development? EDA business process development describes the connection between the business requirements and the data design for a system component. The information needs of business processes provide the foundation for the data requirements. These data requirements become part of the enterprise data model which is the basis for the data design of the system components.

EDA business process development is concerned with the data that is part of the business processes and the relationship between that data and the enterprise data model. Requirements for new data elements result in the incorporation of these data elements into the enterprise data model. New business processes that interact only with existing data do not create new data elements in the enterprise data model, but they do prompt modifications to the data descriptions in the metadata as appropriate.

EDA business process development is part of the implementation of system components. The implementation project team is responsible for identifying the business requirements of the system component and for determining, and documenting, the relationship of these requirements to the enterprise data model.

Data elements are added to the enterprise data model only as needed. The analysis of new data requirements and the mapping of these requirements to the enterprise data model provide a mechanism for determining when new data elements are needed and when existing data elements are appropriate for the implementation of new business requirements.

What are the Components of EDA Business Process Development? Although business process development begins with new business processes, its lifecycle includes periodic review of existing business processes. The purpose of these reviews is to identify improvement opportunities for system component and data designs.

Business Process Development has the following components:

– Process Model Analysis – Data Map Generation – Compliance Reviews

PROCESS MODEL ANALYSIS The business process model is developed as defined in the business architecture portion of the Enterprise Architecture. Also defined in the business architecture is the analysis process by which data requirements are derived from the business requirements.

DATA MAP GENERATION The data that is derived from the business requirements is mapped to the existing data definitions in the EDA. New data in the business requirements is either new to the EDA, the same as existing data in the EDA, or a change to existing data in the EDA. The need for new data or replacement data results in requests to update the enterprise data model to meet this need.

COMPLIANCE REVIEWS Periodic compliance reviews are scheduled for system components. The purpose of these reviews is to measure alignment between the system component and the EDA. These reviews identify unresolved issues that were present during the analysis of the business process, and they identify unresolved issues caused by changes to either the system component or the EDA as changes are made to accommodate evolving business needs. The issues that a compliance review raises become action items to be applied either to the system component or to the EDA.

PAGE 16 OF 45


Business Process Development Conclusion The business architecture portion of the Enterprise Architecture specifies the processes involved in extracting data requirements from the business requirements. The result of these processes is a set of requirements that together with the enterprise data model provide the basis for a data design for a system component. Existing data designs are aligned with the enterprise data model by evaluating their compliance with the EDA and identifying any necessary changes to either the data design or the EDA to accomplish this alignment.

Data Governance Conclusion Data Governance determines how the EDA evolves and how it is implemented. It also describes a mechanism for evaluating the EDA in order to direct the EDA evolution toward the mission and goals of the EDA. Data Governance provides a structure that implementation projects use to ensure alignment with the EDA.

PAGE 17 OF 45

ENTERPRISE DATA ARCHITECTURE VERSION 1.0 DATA MANAGEMENT STRATEGY 07/18/2007 DATA ARCHITECTURE

Data Architecture Introduction Data Architecture determines the structure that supports the management of the metadata that describes the enterprise data. This metadata provides a complete, clear, and concise description of the enterprise data. Accessibility to this metadata provides an important component of the successful integration of new products and automated services with respect to the enterprise data.

When information enters an information system it is split into quantitative content and semantic content. The quantitative content is stored as a data value in the information system. As individual instances of a piece of information enter the information system, a corresponding data value is recorded in the information system for each instance. The semantic content, representing the meaning or the interpretation of the data, is captured as metadata. This meaning or interpretation is recorded once for each atomic piece of information (i.e., a data element). The Data Architecture component of the Data Management Strategy defines the structure that supports the processes for managing the metadata.

Purpose The data architecture describes the information that is captured as metadata. The data architecture also describes the repository for organizing and managing the metadata. This repository is referred to as the Data Architecture Repository (DAR). The processes for managing the metadata and for managing the DAR are described in the data architecture.

Scope Development efforts and data sharing efforts rely extensively on the enterprise metadata. Implementation projects use the metadata to determine data integration requirements for new products. Implementation projects use the metadata to plan data retrieval details. Also, the metadata allows individual users and external information systems to develop data retrieval processes on their own for data within their security profile.

What are the Components of the Data Architecture? • Metadata – Description of the location, management, and accessibility of the Metadata. • Data Accountability – Assignment of responsibility for data content. • Data Standards Development – Application of data standards to the requirements of a system

component to produce a data design that promotes data sharing.

Metadata Metadata is the key to good data architecture. Implementation projects require a thorough understanding of the existing data in order to successfully integrate with system components. Meaningful data cannot be extracted from an information system without a clear description of that data. Improving data quality requires quality metadata. Metadata is a valuable enterprise asset.

Metadata management begins with providing a repository for the metadata. The DAR is used for this purpose. This repository is secure in order to protect the reliability of its contents. There is a process for changing, adding to, and deleting from the DAR. This process maintains the quality of the DAR contents. The contents of the DAR are easily accessible to maximize the usefulness of the metadata.

The DAR is the central store of information about the EDA. The DAR includes different forms of recorded information stored in different physical locations, but managed as a single repository. The DAR contains only EDA information, and all information relevant to the EDA is contained in the DAR.

PAGE 18 OF 45


The components of the DAR are: • EDA Document – The EDA document describes the Enterprise Data Architecture. This

document resides in a file folder that is part of the DAR. Only DAR items are in this file folder. • Data Models – Data models provide a conceptual depiction of the data that is within the scope

of the EDA. There are various data models that describe the enterprise data architecture. All EDA data models are included in the DAR. Different types of data models have different storage requirements. A file folder that contains EDA files is part of the DAR and contains only DAR items. A database or some other storage system that contains EDA documentation, isolates the EDA documentation from other items in that storage system and the EDA documentation is managed as part of the DAR.

• Data Dictionary – The textual descriptive information about data elements and entities is kept in a data dictionary. The data dictionary information for the EDA is isolated from any other data dictionary information. The data dictionary information is part of the DAR and is managed as part of the DAR.

• Data Standards – Within the context of the EDA, data standards are specifications that provide data consistency and facilitate the exchange of data between system components and between information systems. These standards are documented in the DAR.

• Metrics – Metrics exist to measure the degree of compliance between a system component and the EDA, and to measure the effectiveness of the EDA. Metric specifications are recorded in the DAR.

• Change Requests – Any changes to the EDA document or to any of the other items in the DAR require a formal change request. These requests along with their outcomes provide documentation regarding decisions that have been made concerning the structure and content of the EDA. The change request along with the final decisions and supporting documentation for the change are recorded in the DAR. In addition, tracking information for these requests resides in the DAR.

• Compliance Reports – The results of a compliance review are consolidated into a compliance report. All compliance reviews along with their resulting reports are documented in the DAR. The schedule of periodic reviews is also included in the DAR.

• DAR Inventory – All of the items that are recorded in the DAR are listed in the DAR inventory. The inventory provides information needed to locate each item along with a description of the tool or tools necessary to access the item. The DAR inventory is recorded in the DAR.

The content of the DAR is strictly controlled. All EDA information resides in the DAR where individual items are stored in secured locations that contain only EDA information. A set of processes manages the EDA information through the various stages of its lifecycle. The DAR content is accessible within the AOC enterprise.

DAR management involves: • Storage – The DAR implementation consists of multiple files in multiple file folders. Security is

established for these folders to accommodate the security requirements of the DAR management procedures. Also included in the DAR implementation are isolated portions of tool-specific repositories. These tools provide a security mechanism that can support the security requirements of the DAR management procedures for individual items within the repositories of these tools.

• Documentation Lifecycle – New EDA information items are added to the DAR. New file folders or new tool repositories that are required by new EDA information are added to the DAR security scheme and enforced by the file system or the tool. Changes to EDA information items displace old items. A history of past information items is maintained in the DAR. Obsolete EDA information items are logically removed from the DAR.

PAGE 19 OF 45


• Management Procedures – EDA change requests are the vehicle for proposing modifications to the enterprise data model. The modification is expressed in the same form as the item for which the change is proposed. For example, modification of a textual description would show the text “before” and “after” the modification. In the case of a diagram, the request would show the diagram “before” and “after” the proposed modification.

• Accessibility – The content of the most current version of the DAR is available to individuals with the proper security. Historical versions of information in the DAR are available for retrieval. DAR content that is in the process of being modified is not part of the current version of the DAR and is only available as specified in the DAR change management process.

Data Accountability The AOC maintains a statewide repository of court data for the state of Washington. The Washington State Courts, along with various justice partner organizations, are responsible for populating this data repository. Once populated, the data in the repository becomes the responsibility of the AOC. This responsibility is the foundation for a partnership between the Washington State Courts, the justice partner organizations, and the AOC to ensure the quality and integrity of the data within the statewide court data repository.

Data accountability represents assigned responsibility for the management of data at various stages of the data lifecycle and for various uses of the data. It is a cooperative arrangement between the implementers and stakeholders of an information system. Data accountability is essential for assigning identification and resolution of data issues. Many areas of responsibility involve more than one role, and responsibility assignments occasionally depend upon the phase of the data lifecycle.

Data accountability begins at the point at which source information is entered into the information system. It is the purpose of the information system to provide an accurate representation of that information.

Responsibility for data does not end when the data is removed from the information system. Data that has been shared or disseminated continues to exist after it has been removed from the information system. Accountability for that data continues until either the recipient accepts responsibility for the data or the data has been declared obsolete, invalid, or otherwise unusable.

Data accountability is assigned based on the role that has control over the factors that influence the data. Data accountability assignments are specific to the phase of the data lifecycle and to various areas of responsibility.

Data accountability is assigned for the following areas of responsibility:

• Data Quality – The accuracy and usability of the data values. • Data Access – The mechanisms that make the data available outside the information system. • Data Security – The availability of data based on authorizations and privacy specifications. • Data Implementation – The architectural and managerial strategies for data design.

Data Quality Data quality is assessed across several dimensions:

– Accuracy – The data contains valid and correct values. – Timeliness – The data contains current values. – Completeness – Values are present to fully represent a complete unit of information.

Data quality starts at initial data entry into the data system. Organizations that perform data entry are responsible for the quality of the data they enter into the information system. Quality data entry

PAGE 20 OF 45


requires quality data sources. These data sources include documents, conversations, visual inspection, and electronic communication. Ensuring a quality data source requires negotiation with the provider of the source data. Quality data entry is facilitated by quality data entry mechanisms. These mechanisms include presentation design and communication protocols. Ensuring a quality data entry mechanism requires collaboration between the data entry organization and the provider of the data entry mechanism.

The quality of the data as it flows through the information system is the responsibility of the implementers of the information system. Data quality assessments, and recommendations for solutions to data quality problems, require the involvement of business experts and subject matter experts.

The quality of data that is copied from one location to another location within the information system is the responsibility of the owner of the destination location. Transformation of the data does not reduce this responsibility.

The roles that control data sharing and dissemination of data to data consumers outside the information system are responsible for the quality of the data that leaves the information system. The same roles ensure the completeness of the removal of data when data is removed from the information system.

Data Access Data accessibility is implemented by a combination of hardware and software solutions. The roles that implement system component hardware and software are responsible for accessibility to the physical data.

The “ease-of-use” component of data access is addressed by the design, and the quality of documentation, of the physical data stores. This aspect of data accessibility is the responsibility of the designers of the physical data stores.

Data is often accessible via prepared reports and queries. The roles involved with data dissemination are responsible for this aspect of data accessibility.

Data Security Data security begins with restricting access to the information system. The enterprise security team is responsible for security at this level.

Implementation of security at the database level is the responsibility of the database administration team. The implementation of schema and table level security is also the responsibility of the database administration team.

Business requirements will indicate the need for column or row level security. The implementation of column or row level security within the database is the responsibility of the database administration team. Security requirements that are implemented in applications or services are the responsibility of the implementers of those applications or services.

Security restrictions for individual instances of data objects or portions of data objects are the responsibility of the implementers of those security restrictions.

Data Implementation The designers of the physical data stores are responsible for the data stores that they design. They are responsible for ensuring that the data is recoverable from a system failure. They are also responsible for producing data designs that conform to the data rules and requirements of the EDA.

PAGE 21 OF 45


This responsibility includes the ability to verify the conformity of the data designs to those rules and requirements.

Data Standards Development A common data design simplifies the implementation project effort. This leads to consistent system component implementation throughout the information system which increases the efficiency and effectiveness of these implementations. The EDA provides implementation guidelines to assist with data design in system components.

By leveraging the data standards during the implementation of system components, implementation projects produce a data design that promotes effective data sharing.

Data sharing involves combining several areas of standardization.

– Data Semantics – The data requirements of external information systems are matched to the EDA data elements based on the meaning of the data as described in standards associated with the EDA metadata. Resolutions are found for issues resulting from the matching of multiple EDA data elements to a single data requirement and from the matching of multiple data requirements to a single EDA data element.

– Data Format – The data characteristics specified in the EDA Data Standards Table are preserved. Decreasing these characteristics (e.g., decrease length, decrease precision, etc.) potentially creates a loss of information. Extending these characteristics (increase length, increase precision, etc.) does not create a loss of information but it potentially creates false implications concerning the data.

– Communication Protocols – The use of standard protocols simplifies data sharing between data interchange participants. Common communication protocols among data interchange participants provide the greatest opportunity for accurately sharing data.

– Data Access Mechanisms – Data access mechanisms are selected based on their availability to existing, as well as potential, data interchange participants. The mechanisms most likely to meet this criterion are those based on common data access standards.

– Data Security – Data is shared only when continuity of data security requirements is assured. It is the responsibility of the data consumer to implement the security requirements that have been identified for any shared data that it receives. The data provider is responsible for acquiring assurance that a data consumer has assumed responsibility for meeting the security requirements for any shared data that the data provider sends.

Conclusion The data architecture portion of the Data Management Strategy describes a framework for documenting the data requirements. The data documentation includes assigning responsibility for the data and specifying guidelines to address the sharing of that data. A single source of data documentation provides a shared understanding of the data across system components. This shared understanding is the cornerstone to data quality and data sharing.

PAGE 22 OF 45

ENTERPRISE DATA ARCHITECTURE VERSION 1.0 DATA MANAGEMENT STRATEGY 07/18/2007 DATA SHARING ARCHITECTURE

Data Sharing Architecture

Introduction Many information systems are interested in sharing data with the AOC. The value of shared data depends upon the quality of the data as it migrates between information systems. Standardization and common understanding are the primary tools for preserving the quality of data that is shared among multiple information systems.

Data sharing refers not only to situations involving multiple information systems; it also includes individual information systems where the same data is supplied by more than one source, or where the data is distributed to multiple data consumers. Standardization and common understanding facilitate data sharing in these instances as well.

Data issues arise when multiple sources supply the same data. These issues require consistent resolution. Shared data is reliable when methods of collecting and manipulating the data produce predictable results.

The data issues that arise when there are multiple data consumers generally involve misinterpretation or misrepresentation of the data. Either way, trust in the data is weakened. A shared understanding of the data, whether reporting the data or processing the data, is a key component of successful data sharing.

Sharing data among multiple information systems is particularly complex. In addition to the issues involving suppliers and consumers at each information system, those suppliers and consumers also affect each of the other information systems. In general, changes to data in one information system require coordination with the other information systems in order to incorporate those changes accurately and within a specified period of time.

Shared responsibility for data quality requires that the data replication and data transformation policies are followed by each information system. Since it is not possible to know in advance all potential data interchange participants at the time that data sharing decisions need to be made, the data sharing strategy relies on the use of common standards which have been adopted at the most global level.

Each information system has its own unique challenges and constraints. Data requirements are not necessarily the same for each information system. A single solution may not be practical in all situations. Applying the most global standards in a particular situation increases the likelihood of compatibility with other information systems.

Purpose The Data Sharing Architecture involves a structure of standards to facilitate the sharing of data between information systems. These standards are used to determine which data is shared, how it is shared, and when and with whom that data is shared. In addition, these standards address issues associated with maintaining data quality. Information systems use these standards to make decisions that maximize their data sharing potential.

Scope It is expected that not all data in an information system will be shared. The data sharing architecture is directed only at that data that is selected for sharing.

The data sharing architecture anticipates changes in technology. In order to accommodate these changes, information systems are expected to support technologies that meet a set of common technology requirements.

PAGE 23 OF 45


What are the Components of the Data Sharing Architecture? The Data Sharing Architecture is divided into the following components:

• Data Sharing Management – Defines data sharing and describes the method by which conflicts involving data sharing are resolved.

• Quality Control – Establishes guidelines to maximize the quality of shared data. • Data Protection – Applies security and privacy restrictions to shared data. • Data Sharing Standards – Provides the specifications for technologies that facilitate data

sharing.

Data Sharing Management Data is shared when multiple organizations use the same instance of a data element in their business processes. An organization may be supplying data, consuming data, or hosting an external data system that services its own set of data consumers.

Data ownership implies business knowledge of data where the knowledge is sufficient to determine correctness of that data. In a data sharing environment where two separate data sources supply the same data instance to an information system, ownership is determined by business requirements. This ownership is documented as part of the descriptive information about the data elements in the enterprise data model. Usage of that data instance is allowed according to established rules of ownership. These rules are data element specific; they specify who has control over the data at each phase of the data lifecycle, and they describe the circumstances under which data ownership is transferred.

Each data interchange participant is responsible for providing a description of its data design, the mapping of its data elements to the enterprise data model, and any required conversion processes.

There are several ways that data sharing ends. The owner of the data may stop sharing the data. In this situation, other copies of the data become stale and are no longer considered accurate. Another way that data sharing ends is when the data is targeted for destruction. Data destruction includes destruction of that data at external information systems that are consumers of that data.

Quality Control When multiple system components use the same data in different ways, the enterprise data model is consulted and the system component and the enterprise data model are aligned to follow the most common use of the data. Alignment with the most common data usage minimizes the impact on existing system components.

Delays in data synchronization between system components reduce the quality of shared data which in turn reduces the usefulness and effectiveness of the shared data. Synchronization standards are applied at the data object level for each data object.

Data completeness is not guaranteed between system components. Data sharing restrictions can vary from data owner to data owner. Data sharing documentation includes the circumstances under which data may be incomplete.

Accurate data communication relies on consistent data representation. There is a standard communication format for each data element. Each system component is responsible for either complying with the standard format or for providing format conversions between the local format and the standard format. The communication format is specified for each data element and includes the following:

PAGE 24 OF 45


• Encoding Scheme – Indicates any decoding requirements (e.g., data, time, numeric data, etc.). • Data Representation – Describes the rendering of data element contents (e.g., capitalization

and punctuation). • Data Length – The maximum allowable length for the data element representation.

System components express their data requirements as data elements organized into one or more schemas. The more closely the schemas align with each other, the more efficient the data sharing process. The EDA provides a conceptual model that system components use to achieve schema alignment with each other.

A thorough understanding of the data elements in the information system is necessary for successful data communication. This understanding is derived from the metadata for the information system. Data designs, along with accompanying data dictionary entries for individual system components, are stored in a repository designed specifically for making this information available to other information systems.

Data Protection Data availability requirements are determined by the data owner. The data owner determines who can access the data, and under which circumstances that access is allowed. Security policies are established to align data access to the specifications of the data owner. Accommodations are made for public data that needs to be available to the public. Also special considerations are made for data that has been declared private or otherwise inaccessible by statute or by court order.

Data security is an issue between multiple information sources that supply the same data. Data sharing expands security policies that allow an information source to secure its data, so that those policies also accommodate situations where other information sources supply the same data.

Security and privacy need to follow the data. The data provider needs agreements with its consumers to honor data security and privacy.

Data Sharing Standards There are technologies that can assist with data sharing. Consistent application of well established standards is the key to a successful implementation of data sharing technology. It is adherence to these standards that make otherwise unrelated technologies compatible with each other.

Data sharing standards provide a minimum set of requirements to apply to data sharing technologies. These requirements specify the criteria that facilitate communication and exchange of data between information systems. These criteria are result based (i.e., the “what”) rather than process based (i.e., the “how”). Specifying standards in this way allows for the inclusion of innovative or “niche” technologies, as well as the application of new technologies.

Meeting a common set of requirements enables integration among the various information systems. This is important in developing a data design that facilitates the sharing of data. Published standard requirements provide a basis for current data designs and for assessing compatibility with technologies of future data interchange participants as these technologies become available.

Purchased data sharing solutions are also subject to the data sharing standards. The standard requirements are part of the evaluation criteria for the purchase decision. The technologies that are bundled within a purchased system component are not evaluated separately but rather the system component is evaluated as a whole.

PAGE 25 OF 45


Conclusion Data sharing requires cooperation and coordination among the data interchange participants. There are data standards available that each information system uses to maximize its data sharing potential with other existing information systems and with potential future system components.

Data ownership is clearly defined so that data quality and data security issues can be resolved as efficiently as possible. The data owner is responsible for supplying accurate data and for specifying the data authorization rules for that data.

Compatibility among technologies is enabled by defining standards that do not restrict information systems to use only known technologies. These standards specify the minimum requirements needed in the data sharing architecture so that any technology that meets these standards is a viable alternative.

PAGE 26 OF 45

ENTERPRISE DATA ARCHITECTURE VERSION 1.0 CONCEPTUAL DATA MODEL 07/18/2007

Conceptual Data Model Introduction The Enterprise Data Architecture (EDA) includes an enterprise data model. The enterprise data model represents the data that is needed to support the enterprise business requirements. The scope of the enterprise data model and the context within which the enterprise data model objects are described, are determined by the business requirements as represented in the enterprise business model. The information needed to complete subsequent data models is also extracted from the enterprise business model.

The enterprise data model is developed at two levels:

• The Conceptual Data Model (CDM) is a high-level data model for the enterprise business model. It is developed in terms of data objects and the interrelationships of those data objects. Individual data elements are not specified.

• The Logical Data Model (LDM) represents a refinement of the CDM, incorporating data element detail into the data model without regard for the physical aspects of implementation.

The primary distinction between these two models is that the CDM represents the data objects (expressed in business language using data modeling tools and methods) while the LDM describes individual data elements and their interdependencies (which are derived using strict mathematical principles).

The process of constructing the CDM exposes fundamental relationships and dependencies between the data objects, which leads to a greater understanding of the role of the data in the enterprise business model. The CDM documents these relationships and dependencies so that they can be used to further refine the enterprise data model. The CDM is a fundamental component of the enterprise data model, which is the key reference point for data design.

Purpose The CDM defines the context and scope for the data objects in the enterprise data model. The CDM serves the dual purpose of being a high-level data model for the enterprise business model and of providing guidance for the development of subsequent data models.

The CDM carries the business context of the data into the enterprise data model. The analysis of the data objects with regard to the business context reveals commonalities that allow for the grouping of data objects within the CDM. This ties the enterprise data model to the enterprise business model at the most fundamental level, assuring that subsequent data models, based on the CDM, align with the business requirements.

The CDM achieves the following goals:

• To define, describe, and organize the data objects derived from the enterprise business model.

• To provide a tool for verifying completeness of the enterprise business model with respect to data manipulation functionality.

• To provide a foundation upon which to complete the enterprise data model.

Scope Analysis of the data requirements in the enterprise business model determines the scope of the CDM. Because of the connection between the CDM and the data objects from the enterprise

PAGE 27 OF 45


business model, this scope is consistent with the scope of the enterprise business model and maintains this consistency as subsequent models are developed from the CDM. The CDM provides the scope for the enterprise data model.

The following criteria are used to determine the scope of the CDM:

• All data objects in the enterprise business model are represented. • All direct relationships that exist between data objects are included. • No information regarding physical design or definition is included. • No information from outside of the enterprise business model is included. • No individual data elements from the enterprise business model are included.

The CDM section of this document answers the following questions:

• What is the Conceptual Data Model? • What are the components of the Conceptual Data Model? • How is the Conceptual Data Model developed? • How does the AOC use the Conceptual Data Model?

What is the Conceptual Data Model? The CDM is a collection of diagrams, charts, and textual descriptions of the data objects that represent the data in the enterprise business model.

The CDM describes the following data model objects:

• Conceptual Entity: A conceptual entity in the data model is the representation of a data object from within the enterprise business model.

All data contained in a data object is represented by an entity. Each entity is associated with only one data object, but a data object may be represented by multiple entities. When multiple entities are associated with a single data object, those entities represent non-overlapping partitions of the data contained in that data object.

• Conceptual Relationship: A conceptual relationship is a bi-directional connection between two conceptual entities.

Relationships between entities indicate when the actions that affect one entity may affect other entities. Each relationship connects exactly two entities. Any entity is allowed multiple relationships.

• Subject Area: A subject area is a logical grouping of conceptual entities that represent data objects that share a common business purpose.

Subject areas provide business context for the entities they contain. All entities in the CDM are assigned to a subject area, and each entity is assigned to only one subject area.

What are the Components of the Conceptual Data Model? The CDM employs multiple techniques for describing the data from the enterprise business model. Each technique exposes a particular set of characteristics about the data.

The CDM has the following components:

• Conceptual Entity Relationship Diagram: A conceptual Entity Relationship Diagram (ERD) provides a graphical representation of the conceptual relationships between conceptual entities. The entities are organized into subject areas. Subject areas are represented in the CDM as ERD

PAGE 28 OF 45


submodels of the main ERD model, which contains all the entities. The name of the subject area is used as the name of the submodel. There is one, and only one, submodel for each subject area.

Entities are represented in the ERD as a “box” with the entity name inside it. The position of the entities on the diagram does not imply hierarchy or relationship.

Relationships are represented in the ERD as a line touching two entities, with one entity at each end of the line. The nature of the relationship is stated as text on the diagram next to the relationship line. The text is placed above the line for the relationship from the entity on the left to the entity on the right, and placed under the line for the relationship from right to left. When the two entities are aligned vertically, the text is placed to the right of the line for the relationship from the entity on top to the entity on the bottom, and to the left of the line for the relationship from bottom to top.

• Data Dictionary: The data dictionary provides structured textual descriptions for each data model object in the CDM. These descriptions provide data model object details.

The textual descriptions follow a specified format for each data component. Templates of these formats are available in the Data Architecture Repository.

Each data model object description includes as a minimum, a name and a definition. Names are unique within the model. There are naming standards for each type of data model object. Definitions must be clear, precise, and unambiguous. They must identify the item being defined and distinguish it from any other actual or foreseeable item. Examples or exclusions may be used as needed to improve clarity.

• Data Object Mapping: The data object mapping associates conceptual entities with their source data objects in the enterprise business model.

There is a place to record this mapping in the description template for conceptual entities. Multiple entities are allowed to map to a single data object.

• CRUD Chart: The CRUD chart shows the type of access (Create, Read, Update, and Delete) that each business data function has with each conceptual entity. Each entity needs at least one function that creates it and at least one that reads it. Update and Delete actions are considered to include a Read action.

The CRUD chart is represented as a matrix with business functions listed along one axis and conceptual entities along the other. The letters “C,” “R,” “U,” and “D” are placed at the intersections to indicate the interaction that a function can have with an entity. The intersection can contain any combination of the letters or none at all when there is no interaction between the function and the entity.

How is the Conceptual Data Model Developed? The enterprise business model is the source for the information that is used to develop the CDM. Business analysts and subject matter experts provide this information and, together with the data experts and data designers, generate the CDM.

The CDM is developed incrementally either as new requirements are modeled in the enterprise business model or as existing portions of the enterprise business model are reviewed. CDM development tasks are prioritized according to project needs. This maximizes CDM usefulness while minimizing any delays that projects may experience while waiting for the completion of the CDM.

PAGE 29 OF 45


CDM development involves the following process steps:

• Data Analysis: A data analyst defines the conceptual entities necessary to represent the data objects identified in the enterprise business model. These entities are mapped to their corresponding data objects, relationships are identified between entities, and entities are assigned to subject areas.

When a proposed data object already exists in the CDM, any differences need to be analyzed to determine the final form of the proposed data object. Once all the proposed data objects are finalized, the textual descriptions for these data objects are completed.

• Model Generation: The data model objects identified during data analysis are incorporated into the CDM. This means that conceptual ERDs are created for new subject areas and populated with the appropriate entities and relationships. The textual information that completes the description of these data model objects in the conceptual ERD is added to the data dictionary. The mapping of new conceptual entities to data objects is completed and added to the CDM.

Proposed data model objects replace existing data model objects in the CDM where data model object changes have been identified. The CRUD chart in the CDM is updated to reflect any changes in entities and business functions.

• Metadata Change Request: A metadata change request for the proposed CDM modifications is prepared and submitted as described in the “Data Management Strategy” section of the EDA.

• Change Implementation: A request is generated for implementation of any approved changes. This request is sent to the custodian of the physical repository for the CDM components, who is responsible for implementing changes to the physical repository. Once implementation is complete, notification of the completed changes is sent to the Enterprise Data Architect.

The following criteria determine when the CDM is complete:

• All data objects are fully represented. • All conceptual entities belong to a subject area. • Each conceptual entity is associated with a specific data object. • Each data model object is documented in the data dictionary using the designated template. • Every conceptual entity is included in the CRUD chart. • Every business function that accesses data is included in the CRUD chart. • Every interaction between conceptual entities and business functions is indicated on the CRUD

chart.

The following criteria determine when the CDM is correct:

• The CDM is complete. • Each conceptual entity belongs to only one subject area. • The primary purpose of each conceptual entity in a subject area aligns with the common

business purpose of that subject area. • Each conceptual entity maps to only one data object. • All information in the data dictionary is consistent with the enterprise business model. • Each conceptual entity appears only once in the CRUD chart. • Each business function appears only once in the CRUD chart. • All CRUD interactions are consistent with the enterprise business model.

PAGE 30 OF 45


How does the AOC use the Conceptual Data Model? The CDM is a valuable tool for gaining a high-level understanding of the data requirements of the enterprise business model. The CDM development process uncovers information about the business data that leads to discoveries and conclusions that are represented in the various components of the CDM.

The CDM verifies the completeness of the enterprise business model with respect to the management of business data. The CDM reveals the absence of business functionality that is needed in order to manage the business data. The CRUD chart accomplishes this by identifying business functions for each stage of the full data lifecycle of each conceptual entity. Each entity needs a business function that creates the data represented by that entity, and needs a business function that reads that data. When the data represented by an entity can change over time, there needs to be a business function to perform the update. Also, when the data represented by an entity can be removed from the system, there needs to be a business function to perform the delete.

The CDM assists with the planning of implementation projects involving enterprise data. The high-level enterprise view of the business data that the CDM provides facilitates determining the scope and the business context of the data involved in a project. The scope of the data that a project manipulates is an important factor in preparing a sizing for the project, while the business context of the data influences staffing decisions by identifying requirements for particular business area expertise. The CDM provides these benefits regardless of whether a project is generating new data or simply manipulating existing data.

The CDM is a tool for communicating high-level data requirements to persons and organizations outside the enterprise. This facilitates data alignment on implementation projects that involve data sharing with these persons and organizations. When implementation projects involve adding new data to the enterprise data model, the link between the CDM and the enterprise business model simplifies the business analysis that is needed in order to define the business processes for managing the new data.

Conclusion The CDM transitions the system analysis from the business arena into the data arena. Data objects are analyzed and categorized based on their data characteristics. Mapping the business functionality to the entities they manipulate helps complete the enterprise business model by allowing the identification of any missing business functions for manipulating data.

Implementation projects that are preparing to develop their data design have the CDM available for review to help determine scope and context of the data development portion of the project. Projects that share a common data design are better positioned for data sharing and for providing higher quality data.

Development of the LDM begins with the CDM. The CDM provides scope and business context within which to develop the LDM.

PAGE 31 OF 45

ENTERPRISE DATA ARCHITECTURE VERSION 1.0 LOGICAL DATA MODEL 07/18/2007

Logical Data Model

Introduction The Logical Data Model (LDM) is part of the enterprise data model. The enterprise data model represents the data in the enterprise business model at the data object level and also at the data element level, where the data objects are represented in the Conceptual Data Model (CDM) and the data elements are represented in the LDM.

The LDM is a theoretical data model, not a data design. This theoretical data model is derived from the CDM and the business requirements according to defined mathematical principles. The resulting data model clearly depicts data relationships and dependencies. This information is essential to data design, but does not address physical considerations such as performance and usability.

Purpose The LDM completes the enterprise data model and serves as a reference for the data design of system components. The LDM accomplishes this by incorporating data elements from the business requirements into the enterprise data model. The organization of these data elements in the LDM provides a complete representation of the relationships and interdependencies between data model objects. This representation facilitates verification of the completeness of the enterprise business model with respect to data related functionality.

The LDM also provides a detailed description of the enterprise business data. This description provides a communication vehicle for internal system components and external information systems, as well as outside organizations to use when developing strategies for sharing data with the Administrative Office of the Courts (AOC).

The LDM contributes to data quality efforts. The information in the LDM includes valid data values, valid data types, related data, data dependencies, and traceability to business requirements and processes. This information is vital to the task of identifying data quality issues and formulating responses to these issues.

Scope The data model objects in the LDM are derived from the data model objects in the CDM either as a direct representation of the CDM data model objects or as data model objects that support the representation of CDM data model objects. This aligns the LDM scope with the scope of the CDM, which is already aligned with the scope of the enterprise business model. The individual data elements represented in the LDM are derived from the enterprise business model and the business requirements.

Physical data modeling is outside the scope of the LDM. The data model objects in the LDM are not expected to be implemented in a database, application object, structured text file, or any other data representation without first going through a process that addresses physical design considerations. This process is not part of the LDM.

The LDM section of the Enterprise Data Architecture (EDA) answers the following questions:

• What is the Logical Data Model? • What are the components of the Logical Data Model? • How is the Logical Data Model developed? • How does the AOC use the Logical Data Model?

PAGE 32 OF 45


What is the Logical Data Model? The LDM is a representation of the information requirements for the enterprise. It contains the elemental detail of the data objects and depicts the data interdependencies and relationships of those data elements. The LDM uses diagrams and textual description to model the data requirements.

The LDM describes the following data model objects:

• Attribute: An attribute is an indivisible unit of information that is either derived from the business requirements or is needed to support business requirements within the data model.

The attribute description provides information about the values associated with that attribute. This information includes the structure and format of the values along with any value restrictions. Also included is any information about how the attribute is used in the business, including interrelationships with other attributes.

Attributes are the basis for elemental (e.g., table column) designations in data designs.

• Domain: A domain represents a collection of characteristics that are shared by multiple attributes.

A domain represents a data type that can be associated with an attribute. Associating an attribute with a domain simplifies data analysis and data design because it clarifies data value compatibilities between attributes.

Domains are the basis for data type (e.g., table column type) specifications in data designs.

• Entity: An entity is a collection of attributes that share a common identity.

Entities provide a single point of reference for attributes that are created and deleted together as a single unit. Using entities to represent a collection of attributes also provides the opportunity to explain characteristics that apply to the attributes when they are considered together. Entities allow for the documentation of associations and interactions between entities where those associations and interactions may not be easily described referring only to individual attributes.

Entities are the basis for data object (e.g., table) specifications in data designs.

• Relationship: A relationship represents an association between two entities.

Relationships depict the business rules and requirements which describe the interactions between entities. The interaction between two entities joined by a relationship is described twice, once from the perspective of each entity in the relationship.

Relationships are the basis for reference (e.g., foreign key) specifications in data designs.

What are the Components of the Logical Data Model? The LDM is made up of components that present the details of the data requirements using diagrams and textual descriptions. The information about dependencies and relationships between data model objects is represented using diagrams. Information describing the business usage characteristics of each data model object is recorded as text in the data dictionary.

The components of the LDM are as follows:

• Entity Relationship Diagram: An Entity Relationship Diagram (ERD) is the tool by which a formal, graphical depiction of the data model is produced. The descriptions of entities and relationships for the CDM ERDs also apply to the LDM ERDs. The LDM ERDs also include attribute names which are included in the entity “box” along with a designation to identify primary key attributes.

PAGE 33 OF 45


• Data Dictionary: The data dictionary provides structured textual descriptions for each data model object in the data model. The description of the CDM data dictionary also applies to the LDM data dictionary.

How is the Logical Data Model Developed? Development of the LDM is a transformation process that begins with the CDM. The information in the CDM is supplemented with attributes which represent data elements derived from the enterprise business model. This combination of CDM and attributes becomes the LDM through an iterative process known as “normalization.”

The normalization process identifies dependencies between attributes and organizes the attributes and entities in alignment with those dependencies. Generally speaking, attributes that share dependencies are grouped together with the attributes upon which they depend. The resulting organization of attributes and entities provides a clear representation of the attribute dependencies and relationships.

There are multiple degrees of normalization which are referred to as “normal forms.” The normalization process develops these “normal forms” of the data model according to a prescribed sequence. Normalization, for purposes of the LDM, ends with Boyce/Codd Normal Form (BCNF). The steps leading to BCNF are as follows:

• Populate candidate CDM entities with attributes. This may be referred to as Zero Normal Form (0NF). A particular attribute is assigned to only one entity. Entities may be combined or attribute names may be qualified if necessary. 0NF is maintained through each subsequent normalization step.

• Assign a Unique IDentifier (UID) to each entity. The UID is an attribute or combination of attributes that uniquely identifies individual occurrences of that entity. UIDs are maintained through each subsequent normalization step.

• Separate from each entity those attributes or groups of attributes that repeat within that entity. Each repeating attribute or group of repeating attributes becomes a new entity. Once all the repeating groups of attributes are isolated into their own entities, the model is said to be in First Normal Form (FNF). FNF is maintained through each subsequent normalization step.

• Separate from each entity those attributes or groups of attributes whose values depend on only a portion of the UID. These attributes or groups of attributes become new entities. Once all the partial dependencies on the UID have been resolved, the model is said to be in Second Normal Form (SNF). SNF is maintained through each subsequent normalization step.

• Separate from each entity those attributes or groups of attributes whose values depend on attributes in the entity but not in the UID. These attributes or groups of attributes become new entities. Once all the non-UID dependencies have been resolved, the model is said to be in Third Normal Form (TNF). TNF is maintained through each subsequent normalization step.

• Separate from each UID those attributes or groups of attributes whose values depend on other attributes within the UID. When the separated attributes exist in another entity (i.e., the UID inherited these attributes from a relationship), the relationship with that other entity changes accordingly. When no other entity is involved, the attributes become non-UID attributes. Once all the inter-UID dependencies have been resolved, the model is said to be in Boyce/Codd Normal Form (BCNF).

PAGE 34 OF 45


LDM development involves the following process steps:

• Model Initiation: The LDM begins as a duplicate of the CDM. The LDM ERDs contain the CDM entities, and the data dictionary includes the CDM entity descriptions.

The LDM evolves as the LDM development process proceeds. Subsequent LDM development steps refine the LDM “in place” (i.e., the LDM is manipulated until the LDM development process is complete).

• Data Element Identification: Analysis of the business requirements reveals the data elements for the data objects which are represented by the entities in the LDM. These data elements are the attributes in the LDM that are used in the normalization process.

• Data Normalization: The normalization process identifies dependencies between attributes and reconstructs the entities according to the rules of normalization. The normalization process triggers corresponding changes to the data dictionary descriptions.

• Metadata Change Request: Proposed LDM modifications are processed as Metadata Change Requests as described in the “Data Management Strategy” section of the EDA.

• Change Implementation: Approved changes are implemented by the custodian of the physical repository for the LDM components, who is responsible for implementing changes to the physical repository. The Enterprise Data Architect is notified of all completed changes to the physical repository.

The following criteria determine when the LDM is complete:

• All data elements in the enterprise business model are represented as attributes. • Each attribute is associated with a specific data element from the enterprise business model. • A UID is defined for each entity. • Each entity participates in a relationship. • Each data model object is documented in the data dictionary using the designated template.

The following criteria determine when the LDM is correct:

• The LDM is complete. • Each attribute is associated with only one data element from the enterprise business model. • The LDM is fully normalized to BCNF. • All information in the data dictionary is consistent with the enterprise business model.

How does the AOC use the Logical Data Model? The LDM is used in the following ways:

• Validation of the Completeness of the Enterprise Business Model The LDM is a tool for validating the completeness of the enterprise business model. Data dependencies that are documented in the LDM require supporting functionality in the enterprise business model. Methodical analysis of the data dependencies in the LDM identifies necessary business functionality whose existence in the enterprise business model is then confirmed.

• Development of Data Designs The LDM provides information used in the creation of data designs for system components. Data design applies not only to database and other data store designs, but also to user interface designs, data structures within data communications, and combinations of data elements being updated within data manipulation processes.

PAGE 35 OF 45


Data dependencies identified in the LDM indicate scope boundaries for data that is needed in the system component. These data dependencies also determine complete groupings of attributes. Data groupings are complete when data manipulation within the group does not require the manipulation of data outside the group. Data dependencies also influence decisions involving denormalization, redundancy, and derived data in data designs.

System components benefit from thorough documentation of the entities, relationships, and attributes in the LDM data dictionary. The LDM documentation provides traceability of attributes and entities to business requirements. This traceability assures that a data design based on the data definitions in the data dictionary accurately represents the business requirements.

• Validation of Data Designs and Performance of Compliance Reviews The LDM is used during evaluation of data designs of system components and during compliance reviews. Physical attributes are traced to corresponding attributes in the LDM to validate that the physical attributes exist in the LDM, that their use is consistent with the LDM definitions, and that data manipulations are consistent with the data dependencies identified in the LDM.

• Data Sharing The use of a common data model facilitates the sharing of data, whether that is sharing between AOC system components, between the AOC and AOC justice partners, or between the AOC and other persons or organizations that have an interest in AOC data. The LDM serves as the common data model for the data that the AOC manages. Therefore, there is an expectation that the efficiency of communication, migration, integration, and transformation functionality between information systems will be enhanced for implementation projects that align their data designs with the LDM.

The LDM represents data requirements and specifications which are made available for distribution as part of the information technology procurement process. The LDM is distributed in whole or in part as appropriate along with other components of the EDA.

Conclusion Completion of the LDM completes the enterprise data model, which represents the data that is in the enterprise business model. The LDM documents the data relationships and dependencies that are derived from the enterprise business model and business requirements. The information in the LDM allows data design processes to start with a complete picture of the data requirements.

The LDM is developed from the same requirements as the CDM and the enterprise business model. This provides traceability from the LDM back to the same business requirements as the enterprise business model. This traceability enables validation processes between the enterprise business model and the LDM.

The LDM positions the AOC to establish criteria for determining data sharing compatibility between AOC enterprise data and external information systems. In addition, the LDM simplifies integration processes by providing a common model and common understanding of the AOC enterprise data.

PAGE 36 OF 45

ENTERPRISE DATA ARCHITECTURE VERSION 1.0 DATA STANDARDS TABLE 07/18/2007

Data Standards Table

Introduction The Enterprise Data Architecture (EDA) Data Standards Table (DST) is a documentation structure for itemizing standards that are directly or indirectly involved in the specification of the EDA. This structure allows the association of EDA elements to specific standards. These standards have an influence on any data design that aligns with the EDA.

The use of standards within an organization improves communication and productivity for that organization. The same is true for standards that are adopted across organizations, in that the inter-organizational communication is improved and the interactions between the organizations are more productive. The DST mapping of standards to EDA elements is available to organizations outside of the Administrative Office of the Courts (AOC) in order to communicate requirements for compatibility with AOC enterprise data.

Purpose The DST provides a list of standards and the organizations with which those standards are associated in order to facilitate the assignment of standards within the EDA. In order to accomplish this, the DST:

• Associates standards to the organizations responsible for them, • Inventories the various versions of standards that are referenced in the EDA, • Provides a reference key for associating a standard to an EDA element, • Provides a list of standards from which to select the appropriate standard for a new EDA

element, and • Identifies the owning organization to contact when proposing changes to a standard.

Scope The DST lists standards, their version, and the organizations that are responsible for those standards. These standards define the scope, format, content, security, and meaning of the enterprise data.

The EDA data standards include both AOC-developed standards and standards developed by organizations outside of the AOC. In addition to standards that apply specifically to data, the DST includes standards that support system implementation. Examples of supportive standards include communication protocol standards, modeling standards, and change management standards.

The following points describe the scope of the DST:

• All standards referenced in the EDA are listed in the DST. • Standards that are not referenced in the EDA but that apply to technologies, methodologies,

or practices that support the EDA, are allowed in the DST, but are not required. • Data standards associated with the physical data model, databases, and data stores will not

be part of the EDA. Implementation projects are responsible for mapping or developing data standards for these physical components.

The DST section of the EDA answers the following questions:

• What is a data standard? • What are the benefits of using data standards?

PAGE 37 OF 45


• What are the EDA data standards? • How are the EDA data standards developed? • How does the AOC use the EDA data standards?

What is a Data Standard? A standard is a specification that is used as a rule or a guideline in a defined situation, and so a data standard is a standard that applies specifically to data. There are independent organizations that develop standards that other organizations can choose to adopt. These independently developed standards become the foundation for consistency between organizations that choose to adopt them.

There are two general categories of data standards:

• Structure data standards specify how data should be formatted or structured. Structure data standards enable two systems to exchange data, though not necessarily to understand that data. This allows the systems to exchange data, but agreements are needed to enable the systems to understand and use this data.

• Vocabulary data standards deal with the content of the data elements (i.e., the semantics of the data). Vocabulary data standards enable information systems to share a common understanding of the meaning of the data.

What are the Benefits of using Data Standards? Data standards represent specifications that have already been designed, developed, and tested. An organization that chooses to adopt a particular standard is in agreement with all other organizations that have adopted that standard, without the need for negotiation or compromise.

Some of the qualities that standards add to an organization include:

• Reusability – Standards are developed with the intent of being applicable to multiple situations. • Consistency – The application of standards across the enterprise provides uniformity. • Automation – The consistency that standards provide makes certain automation opportunities

feasible. • Understanding – Standards increase understanding by providing consistent definitions and

descriptions of the data. • Communication – Standards facilitate data communication by establishing a common

understanding of the format and the meaning of the data.

Some of the areas that benefit from the application of data standards include:

• Data Quality Data standards improve data quality by increasing the understanding of the enterprise data. This reduces data entry errors caused by unintentional misuse of a data field due to a misunderstanding of the data. Data standards also allow more consistent and more efficient data collection by reducing, or eliminating completely, the need to reformat or transcribe data each time it needs to be shared.

Accurate and consistent data definitions resolve ambiguities that cause redundant copies of data to be generated. Reductions in data redundancy result in a corresponding reduction in data collection, data entry, data manipulation, and related paperwork. Good data definitions also reduce the complexity of data reporting while improving the quality of the resulting reports. Data standards improve the understanding of the data, which results in an increase in the usefulness of the data as it is used internally and externally for decision support. Data standards also increase the potential for using automated processes to interact with the enterprise data.

PAGE 38 OF 45


• Data Sharing Data standards increase the potential for data sharing and data integration by providing consistent definitions of communication formats and data content. The more widely accepted the data standards are, the greater the potential for effective data sharing. The availability of these definitions makes it possible for data to be shared not only between information systems, but also with other business processes and even with the general public. Accurate definitions enable processes to interact with the enterprise data with little or no manual intervention, resulting in a seamless exchange of information. Adherence to the data standards ensures data compatibility within information systems, as well as between information systems.

• System Implementation Data standards enhance the efficiency with which information systems, as well as system components, can be implemented. Data standards provide initial definitions and descriptions of data. Reusing existing standards where possible reduces the cost of standards development and standards maintenance. Process specification and process integration timelines are shortened when data specifications can be determined at the beginning of the implementation project using existing standards. Data standards also enhance the effectiveness of information systems by improving understanding of the data, enabling increased accuracy of the data, and reducing the need for redundant data entry to accommodate multiple data definitions. When data standards are followed, the need for data translation processes is reduced or even eliminated.

What are the EDA Data Standards? The EDA data standards are the set of standards that have been adopted for use with the AOC enterprise data. The EDA data standards are organized around standards organizations. Standards organizations are responsible for providing standards. A Standards Development Organization (SDO) defines standards either for general publication or for submission to a Designated Standards Maintenance Organization (DSMO) that publishes and coordinates standards. It is common for an organization to both develop and maintain a standard.

The DST identifies and describes the organizations that provide standards that are relevant to the AOC EDA. The descriptions of the standards organizations include the standards associated with each organization, any relationships between standards, and any organizational hierarchies involved in the support of any of the standards. The AOC is included as both a SDO and a DSMO because of the involvement of the AOC in the development of AOC-specific standards. The Data Architecture Repository (DAR) contains a template for describing a Standards Organization and its EDA related standards.

There are two types of EDA data standards:

• Process-Based Standards prescribe a specific response to a specific situation. These standards are generally expressed in the form of rules.

• Criteria-Based Standards provide minimum qualifications, where any implementation that meets or exceeds the qualifications is compliant with the standard. Compatibility standards are stated either as a threshold for a quantitative measure, or as expected results from a specified action.

How are the EDA Data Standards Developed? Business needs determine the standards that are selected for inclusion in the DST. This means that a standard is adopted only if it aligns with defined business needs. EDA data standards development is primarily the adoption of existing standards. New standards are developed at the AOC only when existing standards are incompatible with business needs.

PAGE 39 OF 45


The process for development of an EDA data standard begins with the business need for a standard. When the business need is not satisfied by an existing EDA data standard in the DST, then candidate standards sources are identified and their applicable standard is considered for adoption to fill the business need in question.

When no existing standards are found that satisfy the business need, the AOC develops new standards or defines variants of existing standards. When the AOC accepts a variation of a standard that is external to the AOC, the AOC will attempt to have the variation adopted by the DSMO for the external standard, in accordance with the process established by the DSMO for revising its standards.

Once a standard is selected for application to a business need, an EDA change request is made to modify the DST (to add the standard) and to modify the enterprise data model (to assign the standard to the appropriate EDA element).

Versioning is maintained for each standard. All references to standards include the version identifier for that standard. When a standard is modified or replaced, the old version is inactivated and the new version is designated as the active version of that standard. EDA elements that reference the old standard are flagged as using an inactive standard. Migration of these EDA elements to the new standard is prioritized and scheduled. When there are no references to an inactive version of a standard, that standard can be removed from the DST.

There are two AOC-specific standards that are fundamental to the EDA. These standards are developed and maintained by the AOC. The AOC-specific standards are:

• JIS Data Elements The JIS Data Elements are those data elements that have been approved by the Judicial Information System Committee (JISC), according to JISC Rule 5, as Standard Data Elements for inclusion in the Standard Court Data Element Dictionary for the Judicial Information System (JIS). This standard represents the list of data elements whose contents are available to persons and organizations outside of the AOC. Requests for new data elements for this standard are prepared at the AOC and submitted to the JISC for inclusion into the standard. The JISC reviews and approves all proposed changes to the JIS Data Elements standard, subject to established security requirements and data dissemination policies. The AOC maintains the JIS Data Elements Standard that specifies and describes the JISC approved Standard Data Elements. The DAR contains a template for describing a JIS Data Element.

• JIS Reference Tables A JIS reference table represents the valid set of values to be accepted for a particular JIS data element. In addition to providing a fixed set of values, a reference table also provides a description of each value. These descriptions provide a common understanding for the use of the data elements that are associated with the reference tables. A reference table is either developed at the AOC or is adopted from an existing standard of an external organization. The JIS Reference Tables Standard is a list of reference tables, each of which is developed independently from the others. The contents of the JIS reference tables are subject to the same approval process as the JIS Data Elements Standard. The AOC maintains the JIS Reference Tables Standard that specifies and describes the reference tables that are associated with JIS Data Elements. The DAR contains a template for describing a JIS Reference Table.

The mapping of reference tables to data elements is maintained in the DAR. The mapping of data standards to reference tables and to data elements is also maintained in the DAR.

PAGE 40 OF 45


How does the AOC use the EDA Data Standards? The AOC uses the EDA data standards to support data quality efforts, to facilitate data sharing, and to streamline system implementation efforts. Data quality is higher when standards are applied throughout the data lifecycle. These standards are used to provide consistent data structure and content as data enters and leaves the information system, as well as when it is being manipulated within the information system or being shared with one or more external information systems.

Data standards also provide a baseline against which data quality can be measured. This measure enables the development of mechanisms for assessing data quality and evaluating the effectiveness of changes designed to improve data quality.

The AOC uses the EDA data standards to promote data sharing and integration between information systems, services, and system components. The data standards set expectations regarding the availability and implementation characteristics of the data being shared. The data standards also include published descriptions of the meaning of the data. These descriptions convey a common understanding of the data.

System implementation efforts benefit from data standards. Data standards are a reusable resource that reduces implementation complexity.

There are a number of ways that implementation complexity is reduced:

• Standards represent previously defined specifications. The use of these standards reduces the amount of specification development that an implementation project needs to do.

• When an existing standard partially satisfies a particular set of business requirements, the portions of that standard that satisfy the requirements, can be reused.

• The use of documented standards reduces the amount of documentation that an implementation project needs to produce.

• When each system involved in data interchange uses the same data standards, little or no data conversion or translation is necessary as part of that communication.

• Data standards provide a set of requirements that can be used in preparation to procure system components.

Some examples of uses of data standards include:

• Person-to-Computer Communication During data entry, data standards set expectations regarding form design and field content. Establishing accurate expectations reduces data entry errors by eliminating incorrect assumptions about requested data.

• Computer-to-Computer Communication Information system integrations, data migrations, and data conversions are examples of computer-to-computer communication. When data is exchanged between information systems, the use of standard data formats and standard data communication protocols reduce unintentional changes to data that result from conversions from one data format to another. A standard set of data values reduces misinterpretation of data content and reduces the need for data translation modules.

• Computer-to-Person Communication When data is extracted from an information system for reporting purposes, consistent definitions for data elements improve the usability of the reported information by providing a common understanding of the meaning of the data.

• Person-to-Person Communication Common terminology and standardized data values and formats reduce ambiguity when people

PAGE 41 OF 45


need to communicate with other people regarding data. Theses communications take place in all phases of implementation and continue after implementation in the form of problem reporting and resolution.

Conclusion The EDA DST is the foundation for data quality, data sharing, and system implementation. Data standards allow organizations to share data more easily by providing a common understanding of data communication formats and data semantics. Automated processes between organizations rely on standards for their communication specifications and for their interpretation of communication content. Organizing these standards into a standards table facilitates the tracking of changes to standards and the mapping of particular standards to EDA elements.

PAGE 42 OF 45

ENTERPRISE DATA ARCHITECTURE VERSION 1.0 SUMMARY 07/18/2007

Enterprise Data Architecture Summary Introduction The Enterprise Data Architecture (EDA) is a framework for describing and managing the Administrative Office of the Courts (AOC) enterprise data. This framework also defines the establishment and ongoing support of the EDA itself.

The EDA is defined within the context of the enterprise architecture. The role of the EDA within the enterprise architecture is to address architectural issues related specifically to data.

The EDA is business-centric and standards-based. The EDA is aligned with the enterprise business model which is derived from the business requirements. This allows the EDA to serve as a common reference point when implementing AOC system components. Standardization promotes reuse of architectural components and provides consistency that facilitates data sharing and integration.

EDA Components The EDA uses various tools to describe the AOC enterprise data. The EDA toolset includes text documents, spreadsheets, ERD diagrams, data dictionaries, hypertext, XML, database systems, query tools, version control systems, and tracking systems for problem reporting and compliance reviews. The work products of these tools reside in the Data Architecture Repository (DAR).

The EDA is divided into four components; the Data Management Strategy (DMS), the Conceptual Data Model (CDM), the Logical Data Model (LDM), and the Data Standards Table (DST).

Data Management Strategy The DMS describes the components of the strategy for establishing and managing the EDA. The DMS provides the governance structure for the EDA, describes the repository for the EDA documentation, and defines the terms, roles, and deliverables of the DMS.

The DMS establishes a review board to determine appropriateness of additions and modifications to the EDA along with an outline of the process for submitting and approving requests for these EDA changes. In addition, the DMS requires compliance reviews based on quantifiable metrics. These reviews are applied to existing system components, to proposed designs, and to potential purchased solutions. The DMS includes architectural principles and policies that guide the determination of review metrics for both the change requests and compliance review processes.

Conceptual Data Model The CDM is an organization of the metadata that is associated with the data objects that are described in the enterprise business model. This connects the content of the CDM to the business requirements. Because the CDM is based on the data objects in the enterprise business model, the scope of the CDM is aligned with the enterprise business model.

The information in the CDM is captured in Entity Relationship Diagrams (ERDs) in order to show the relationships between conceptual entities and to group the conceptual entities into subject areas. The CDM subject areas provide context for the conceptual entities in the CDM. Textual descriptions of the data model objects are maintained in the data dictionary. The description of each CDM conceptual entity includes a reference to its corresponding data object in the enterprise business model.

The CDM includes a CRUD chart. The CRUD chart is a matrix that maps the CDM conceptual entities with functionality from the enterprise business model. The purpose of this chart is to

PAGE 43 OF 45


validate that the functionality needed to support the entire lifecycle of the CDM conceptual entity is present in the enterprise business model.

Logical Data Model The LDM is an extension of the CDM. A mathematical process known as normalization extends the CDM to include the data elements from the enterprise business model. This normalized information in the LDM is captured in ERDs in order to clearly represent the relationships and interdependencies between the data elements.

Textual descriptions of the data model objects are maintained in the data dictionary. These descriptions include data requirements details such as security, privacy, and ownership.

The LDM includes a list of domains where each domain represents a set of data element characteristics. The domain assignment for each data element is part of the description of that data element in the data dictionary. The use of domains facilitates the identification of compatibility between data element values.

The LDM maps the entities in the ERDs to the corresponding conceptual entities in the CDM and maps each attribute to its source in the enterprise business model. This provides requirements traceability from the LDM details all the way back to the business requirements.

Data Standards Table The DST is a list of each version of each standard that is referenced in the EDA. Each standard includes a brief description of the standard along with a reference to the organization that is responsible for maintaining that standard. In addition, the DST identifies the AOC maintained standards that require Judicial Information System Committee (JISC) approval.

Implementing the EDA The EDA content is added in planned increments. The planning and scheduling of these increments is based on business priorities. This minimizes the impact on project schedules without compromising the integrity of the EDA.

Changes to the EDA are triggered by a number of actions. These actions include changes in business requirements, review of the EDA, and compliance reviews of existing system components and of proposed components. Changes to existing content in the EDA are validated against the enterprise business model before the EDA is changed. Any changes to the EDA follow the change process described in the Data Management Strategy portion of the EDA.

New content for the EDA comes from the enterprise business model. Data objects from the enterprise business model are incorporated into the CDM as conceptual entities. Each conceptual entity is assigned to a subject area and relationships between conceptual entities are identified. The information in the data dictionary is updated to reflect any changes to the CDM. References to the data objects in the enterprise business model are established and the CRUD chart is updated to reflect the changes to the CDM.

LDM content is derived from the information in the CDM along with data elements taken from the enterprise business model. Any time the CDM is modified or there are changes to the data elements in the enterprise business model, the LDM is changed accordingly. Changes to the LDM are normalized to Boyce/Codd Normal Form and the data dictionary is updated to reflect the LDM changes.

The DST is updated whenever a new standard or new version of a standard is referenced in the EDA. When the AOC adapts an external standard in order to meet a business requirement, the adaptation is considered for proposal to the external organization that manages that standard.

PAGE 44 OF 45


Using the EDA The EDA assists with the planning of implementation projects. The EDA provides scope and context for the data-related tasks associated with implementation projects. This helps estimate project size and helps determine appropriate resource allocations for these projects.

The EDA descriptions of relationships and interdependencies of data elements serve as a reference for data designs for system components. The EDA facilitates reuse of data within the enterprise by presenting an enterprise view of the data, and promotes reuse of AOC data management principles in data designs for external information systems. The enterprise view of the AOC data exposes redundancy in proposed data designs. This allows the redundancy to be documented and controlled, or eliminated completely, as determined by the business requirements.

The EDA defines the data management requirements for system components. These requirements are part of the procurement process for purchased system components and they determine feasibility of automation opportunities.

The EDA supports data sharing by providing definitions enterprise data within a common architecture derived from documented business requirements and using established standards. The use of a common architecture provides consistent solutions to the difficulties involving multiple producers of the same data and multiple consumers with disparate uses for the same data. A common architecture also assists with resolving synchronization issues and communication issues between diverse information systems by providing a precise definition for each AOC data element.

The EDA identifies data sharing issues concerning data ownership, data access, and public data. The resolution of these issues follows the data management principles in the EDA. The EDA allows for the development of new data management principles as needed.

The EDA provides a mechanism for measuring alignment and compliance with the EDA. This mechanism includes the specification of the measurement criteria and the requirement for a system that tracks the results of alignment and compliance reviews.

Conclusion The EDA is a strategic framework for managing the enterprise data of the AOC. The enterprise data is derived from the enterprise business requirements and is described in detail in the enterprise data model. The EDA includes a set of standards that provide consistent definitions for the data within the EDA as well as with other organizations who have adopted the same standards.

The EDA provides a common definition of the AOC enterprise data to the many organizations with which the AOC shares data. This common definition is necessary to maximize the quality of the data being shared. When data is exchanged between the AOC and an external information system, consistent data definitions are needed for the successful exchange of data. The same need for consistency exists when integrating a new system component with the AOC information system or when migrating AOC data to a new information system.

The EDA provides measurable criteria for use as requirements when procuring new system components. These same criteria are part of the mechanism for measuring the alignment of information systems with the EDA. This mechanism is also employed for periodic review of existing AOC system components. The results are recorded and tracked in order to facilitate planning and scheduling of efforts to bring noncompliant system components into alignment with the EDA.

The EDA is a documentation and assessment tool that is designed to adapt and grow to fit not only the current data needs of the AOC, but also its future needs as they evolve.

PAGE 45 OF 45

Date post:	27-Jan-2015
Category:	Technology
Upload:	aamir97
View:	105 times
Download:	2 times