Your SlideShare is downloading. ×
Washington State Courts
                               Enterprise Data Architecture
                                      ...
ENTERPRISE DATA ARCHITECTURE                                                             VERSION 1.0
                     ...
ENTERPRISE DATA ARCHITECTURE                                                            VERSION 1.0
                      ...
ENTERPRISE DATA ARCHITECTURE                                  VERSION 1.0
                                                ...
ENTERPRISE DATA ARCHITECTURE                               VERSION 1.0
                                               OVER...
ENTERPRISE DATA ARCHITECTURE                                VERSION 1.0
                                                OV...
ENTERPRISE DATA ARCHITECTURE                               VERSION 1.0
                                               OVER...
ENTERPRISE DATA ARCHITECTURE                               VERSION 1.0
                                                OVE...
ENTERPRISE DATA ARCHITECTURE                                    VERSION 1.0
                                         DATA ...
ENTERPRISE DATA ARCHITECTURE                                VERSION 1.0
                                        DATA MANAG...
ENTERPRISE DATA ARCHITECTURE                                  VERSION 1.0
                                        DATA MAN...
ENTERPRISE DATA ARCHITECTURE                                 VERSION 1.0
                                       DATA MANAG...
ENTERPRISE DATA ARCHITECTURE                                VERSION 1.0
                                    DATA MANAGEMEN...
ENTERPRISE DATA ARCHITECTURE                                VERSION 1.0
                                    DATA MANAGEMEN...
ENTERPRISE DATA ARCHITECTURE                                 VERSION 1.0
                                        DATA MANA...
ENTERPRISE DATA ARCHITECTURE                                VERSION 1.0
                                    DATA MANAGEMEN...
ENTERPRISE DATA ARCHITECTURE                                  VERSION 1.0
                                     DATA MANAGE...
ENTERPRISE DATA ARCHITECTURE                                VERSION 1.0
                                      DATA MANAGEM...
ENTERPRISE DATA ARCHITECTURE                                VERSION 1.0
                                    DATA MANAGEMEN...
ENTERPRISE DATA ARCHITECTURE                                VERSION 1.0
                                       DATA MANAGE...
ENTERPRISE DATA ARCHITECTURE                                  VERSION 1.0
                                         DATA MA...
ENTERPRISE DATA ARCHITECTURE                                VERSION 1.0
                                        DATA MANAG...
ENTERPRISE DATA ARCHITECTURE                                VERSION 1.0
                                         DATA MANA...
ENTERPRISE DATA ARCHITECTURE                                   VERSION 1.0
                                     DATA MANAG...
ENTERPRISE DATA ARCHITECTURE                                   VERSION 1.0
                                        DATA MA...
ENTERPRISE DATA ARCHITECTURE                                 VERSION 1.0
                                         DATA MAN...
ENTERPRISE DATA ARCHITECTURE                               VERSION 1.0
                                        DATA MANAGE...
ENTERPRISE DATA ARCHITECTURE                                 VERSION 1.0
                                        DATA MANA...
ENTERPRISE DATA ARCHITECTURE                                VERSION 1.0
                                        DATA MANAG...
ENTERPRISE DATA ARCHITECTURE                                VERSION 1.0
                                         CONCEPTUA...
ENTERPRISE DATA ARCHITECTURE                                VERSION 1.0
                                          CONCEPTU...
Washington State Courts Enterprise Data Architecture Version ...
Washington State Courts Enterprise Data Architecture Version ...
Washington State Courts Enterprise Data Architecture Version ...
Washington State Courts Enterprise Data Architecture Version ...
Washington State Courts Enterprise Data Architecture Version ...
Washington State Courts Enterprise Data Architecture Version ...
Washington State Courts Enterprise Data Architecture Version ...
Washington State Courts Enterprise Data Architecture Version ...
Washington State Courts Enterprise Data Architecture Version ...
Washington State Courts Enterprise Data Architecture Version ...
Washington State Courts Enterprise Data Architecture Version ...
Washington State Courts Enterprise Data Architecture Version ...
Washington State Courts Enterprise Data Architecture Version ...
Washington State Courts Enterprise Data Architecture Version ...
Washington State Courts Enterprise Data Architecture Version ...
Washington State Courts Enterprise Data Architecture Version ...
Washington State Courts Enterprise Data Architecture Version ...
Upcoming SlideShare
Loading in...5
×

Washington State Courts Enterprise Data Architecture Version ...

958

Published on

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
958
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
46
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Transcript of "Washington State Courts Enterprise Data Architecture Version ..."

  1. 1. Washington State Courts Enterprise Data Architecture Version 1.0 July 18, 2007 John O’Conner ENTERPRISE DATA ARCHITECT ADMINISTRATIVE OFFICE OF THE COURTS WASHINGTON STATE COURTS
  2. 2. 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
  3. 3. 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
  4. 4. 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
  5. 5. ENTERPRISE DATA ARCHITECTURE VERSION 1.0 OVERVIEW 07/18/2007 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
  6. 6. ENTERPRISE DATA ARCHITECTURE VERSION 1.0 OVERVIEW 07/18/2007 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
  7. 7. ENTERPRISE DATA ARCHITECTURE VERSION 1.0 OVERVIEW 07/18/2007 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
  8. 8. ENTERPRISE DATA ARCHITECTURE VERSION 1.0 OVERVIEW 07/18/2007 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
  9. 9. 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
  10. 10. ENTERPRISE DATA ARCHITECTURE VERSION 1.0 DATA MANAGEMENT STRATEGY 07/18/2007 OVERVIEW – 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
  11. 11. ENTERPRISE DATA ARCHITECTURE VERSION 1.0 DATA MANAGEMENT STRATEGY 07/18/2007 OVERVIEW 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
  12. 12. 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
  13. 13. ENTERPRISE DATA ARCHITECTURE VERSION 1.0 DATA MANAGEMENT STRATEGY 07/18/2007 DATA GOVERNANCE 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
  14. 14. ENTERPRISE DATA ARCHITECTURE VERSION 1.0 DATA MANAGEMENT STRATEGY 07/18/2007 DATA GOVERNANCE 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
  15. 15. ENTERPRISE DATA ARCHITECTURE VERSION 1.0 DATA MANAGEMENT STRATEGY 07/18/2007 DATA GOVERNANCE – 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
  16. 16. ENTERPRISE DATA ARCHITECTURE VERSION 1.0 DATA MANAGEMENT STRATEGY 07/18/2007 DATA GOVERNANCE • 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
  17. 17. ENTERPRISE DATA ARCHITECTURE VERSION 1.0 DATA MANAGEMENT STRATEGY 07/18/2007 DATA GOVERNANCE 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
  18. 18. ENTERPRISE DATA ARCHITECTURE VERSION 1.0 DATA MANAGEMENT STRATEGY 07/18/2007 DATA GOVERNANCE 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
  19. 19. ENTERPRISE DATA ARCHITECTURE VERSION 1.0 DATA MANAGEMENT STRATEGY 07/18/2007 DATA GOVERNANCE 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
  20. 20. ENTERPRISE DATA ARCHITECTURE VERSION 1.0 DATA MANAGEMENT STRATEGY 07/18/2007 DATA GOVERNANCE 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
  21. 21. 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
  22. 22. ENTERPRISE DATA ARCHITECTURE VERSION 1.0 DATA MANAGEMENT STRATEGY 07/18/2007 DATA ARCHITECTURE 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
  23. 23. ENTERPRISE DATA ARCHITECTURE VERSION 1.0 DATA MANAGEMENT STRATEGY 07/18/2007 DATA ARCHITECTURE • 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
  24. 24. ENTERPRISE DATA ARCHITECTURE VERSION 1.0 DATA MANAGEMENT STRATEGY 07/18/2007 DATA ARCHITECTURE 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
  25. 25. ENTERPRISE DATA ARCHITECTURE VERSION 1.0 DATA MANAGEMENT STRATEGY 07/18/2007 DATA ARCHITECTURE 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
  26. 26. 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
  27. 27. ENTERPRISE DATA ARCHITECTURE VERSION 1.0 DATA MANAGEMENT STRATEGY 07/18/2007 DATA SHARING ARCHITECTURE 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
  28. 28. ENTERPRISE DATA ARCHITECTURE VERSION 1.0 DATA MANAGEMENT STRATEGY 07/18/2007 DATA SHARING ARCHITECTURE • 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
  29. 29. ENTERPRISE DATA ARCHITECTURE VERSION 1.0 DATA MANAGEMENT STRATEGY 07/18/2007 DATA SHARING ARCHITECTURE 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
  30. 30. 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
  31. 31. ENTERPRISE DATA ARCHITECTURE VERSION 1.0 CONCEPTUAL DATA MODEL 07/18/2007 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

×