GEIA Standard
Data Management
GEIA- 859
This Standard Was Developed under EIA Project PN 4888
Contents
Foreword
Introduction
Scope
Overview
Terminology
References
1.0Principle: Define the Enterprise Relevant Scope of Data Management
2.0Principle: Plan for, Acquire, and Provide Data Responsive to Customer Requirements
Introduction
2.1Enabler: Establish General Requirements for Data
2.2Enabler: Develop Data Strategy and Data Concept of Operations
2.3Enabler: Determine Specific Data Requirements
2.3.1Determine the Needs for Data
2.3.2Identify the Users of the Data and Establish the Frequency of Data Delivery
2.3.3Relate Data Requirements to the Functional Areas Responsible for Data Generation and Distribution
2.4Enabler: Perform Risk Analysis
2.5Enabler: Authenticate Data Requirements
2.6Enabler: Contract for Data
3.0Principle: Develop DM Processes to Fit the Context and Business Environment in Which They Will Be Performed
Introduction
3.1Enabler: Determine the Complete Set of Requirements that the DM Solution Must Address
3.2Enabler: Determine the Shape of the DM Solution
3.3Enabler: Compare the Proposed, Best Solution to Existing and Planned Enterprise Capability (Infrastructure and Processes)
3.4Enabler: Make Needed Adjustments in Processes, Practices, Policy, Organizational Alignment, and Infrastructure
4.0Principle: Identify Data Products and Views So Their Requirements and Attributes Can Be Controlled
Introduction
4.1Enabler: Develop Consistent Methods for Describing Data
4.1.1Ensure Data Interoperability Among Team Members
4.1.2Apply Processes to Characterize Data and Data Products to Ensure Adequacy and Consistency
4.2Enabler: Establish Relevant Attributes to Refer to and Define Data
4.3Enabler: Assign Identifying Information to Distinguish Similar or Related Data Products from Each Other
5.0Principle: Control Data, Data Products, Data Views, and Metadata Using Approved Change Control Processes
Introduction
5.1Enabler: Control the Integrity of Data, Data Elements, Data Structures, and Data Views
5.1.1Establish a Change Control Process that Imposes the Appropriate Level of Review and Approval
5.1.2Provide a Systematic Review of Proposed Changes within the Change Process
5.1.3Determine the Impact of Change to Include Associated Products, Data, Data Elements, Data Structures, and Data Views
5.1.4Gain Approval or Disapproval of Changes to Data, Data Elements, Data Structures, and Data Views (Data Products) by a Designated Approval Authority
5.2Enabler: Establish and Maintain a Status Accounting Process, Reporting Tool, and Mechanism
5.3Enabler: Establish and Maintain an Internal Validation Mechanism
6.0Principle: Establish and Maintain a Management Process for Intellectual Property, Proprietary Information, and Competition-Sensitive Data
Introduction
6.1Enabler: Establish and Maintain a Process for Data Access and Distribution
6.1.1Define Access Requirements
6.1.2Ensure Entitlement to Access and Use of Data Is Validated and Documented by the Proper Authority
6.2Enabler: Establish and Maintain an Identification Process for IP, Proprietary Information, and Competition-Sensitive Data
6.2.1Distinguish Contractually Deliverable Data
6.2.2Establish and Maintain Identification Methods
6.2.3Establish and Maintain Tracking Mechanisms for Identification of Data
6.2.4Ensure Compliance with Marking Conventions and Requirements
6.3Enabler: Establish and Maintain an Effective Data Control Process
6.3.1Establish and Maintain Control Methods
6.3.2Establish Mechanisms for Tracking and Determining Status of Data
7.0Principle: Retain Data Commensurate with Value
Introduction
7.1Plan to Ensure Data Are Available When Later Needed
7.2Maintain Data Assets and an Index of Enterprise Data Assets
7.3Assess the Current and Potential Future Value of Enterprise Data Holdings
7.4Dispose of Data
8.0Principle: Continuously Improve Data Management
Introduction
8.1Enabler: Recognize the Need to Continuously Improve the Quality of Data
8.2Enabler: Establish and Maintain a Metric Process and Reporting Strategy
8.3Enabler: Monitor the Quality of Data to Improve Data and Processes
8.4Enabler: Improve Data Management Through a Systematic and Self-Diagnostic Process
8.5Enabler: Establish the Necessary Tools and Infrastructure to Support the Process and Assess the Results
9.0Principle: Effectively Integrate Data Management and Knowledge Management
Introduction
9.1Enabler: Establish the Relationship Between Data Management and Knowledge Management
9.2Enabler: Cooperate with Knowledge Management Where DM and KM Intersect as KM Methods Develop
9.2.1Understand the State of KM in the Enterprise
9.2.2Coordinate DM and KM Efforts
10.0Application Notes
List of Figures
Figure 1. Data Management Principles
Figure 21. Contemporary Data Management Model
Figure 22. Principle 2 Enablers——
Figure 23. Data Environmental Assessment
Figure 24. Review Project Life Cycle to Identify Data Requirements and Determine the Needs for Data
Figure 25. Identify Users of the Data Products and Establish When Data Will Be Needed
Figure 26. Relate Data Requirements to the Functional Areas Responsible for Generating the Data
Figure 27. Example Risk Portrayal
Figure 31. DM Requirements
Figure 32. Process for Understanding Requirements
Figure 33. Process for Determining the Shape of the DM Solution
Figure 34. Process for Comparing Proposed Solution to Existing and Planned Enterprise Capability
Figure 35. Process for Making Needed Adjustments in Processes, Practices, Policies, Enterprise, and Infrastructure
Figure 41. Data Product Identification Enables the Control of Requirements and Attributes
Figure 42. Process for Consistently Describing Data
Figure 43. Develop a Process for Selecting Attributes
Figure 44. Assign Identifying Information to Distinguish Among Similar Data Products
Figure 51. Establishing Control
Figure 52. Example Change Control Process
Figure 53. Maintenance of Metadata for Project Use in a Status Accounting Database
Figure 54. Validation of Status Accounting Data and Stored Data to Ensure Integrity
Figure 61. Principle 6 Flow Diagram
Figure 62. Process for Managing Data Access to Intellectual Property, Proprietary Information, and Competition-Sensitive Data
Figure 63. Process for Identifying, Controlling, Tracking, and Protecting Intellectual Property, Proprietary Information, and Competition-Sensitive Data
Figure 71. Planning Decision Tree for Data of Sustained Value
Figure 81. Improving Data Management
Figure 82. Process and Reporting Strategy
Figure 83. Monitoring Data Quality
Figure 84. Improvement Strategy
Figure 85. Self-Diagnostic Process
Figure 86. Development of Objective Evidence of Improvement
Figure 87. Process to Establish Tools and Infrastructure to Support the Process and Assess Results
Figure 91. Understanding the Interdependence of DM and KM
List of Tables
Table 1. Types of Data
Table 1-1. Common Functions of Traditional Data Management
Table 12. Overview of Data Management Tasks, Subtasks, and Needed Skills
Table 31. Creation and Acquisition of Data
Table 32. Responsibility for Updating and Disposing of Data
Table 33. Interdependent Requirements
Table 41. Metadata Examples
Table 51. Example Elements of Database Functionality
Table 71. Representative Refresh and Migration Intervals
Table 81. Examples of Data Management Metrics
Table 91. Relationship Between Data and Knowledge
Foreword
The identification, definition, preparation, control, archiving, and disposition of data all require a sizable investment in labor, supporting systems, and time. The purpose behind enacting consistent, high-quality data management (DM) is to make certain that the enterprise reaps a return on this investment. DM applies effective processes and tools to acquire and provide stewardship for data. A well-designed DM process ensures that customers receive the data they need when they need it, in the form they need, and of requisite quality.
When DM principles are applied using effective practices, the return on the investment in data is maximized and product life-cycle costs are reduced. This standard is intended to be used when establishing, performing, or evaluating DM processes in any industry, business enterprise, or governmental enterprise.
This standard describes DM principles and methods using a neutral DM terminology. Sections 1 through 9899 8 are normative. Annexes are informative.
The methods of DM have undergone significant changes as paper documents transitioned to digital data and continue to evolve. As a result, many policies, manuals, and instructions for DM, which mostly addressed DM for defense products, became obsolete; they described procedures that were adapted to efficient paper-based management of paper deliverables. This standard is intended to articulate contemporarycontemporarycapture current DM principles and methods that are broadly applicable to management of electronic and non-electronic data in both the commercial and government sectors.
The standard is intended to introduce the basic principles of Data Management, provide an introduction to the enablers for each principle, and to introduce what may constitute some new concepts and tasks associated with the management of data. GEIA-HB-859 is the associated manual which contains how-to information for implementation of this standard in a variety of environments.
Development of this standard began in August 2000 when the Electronic Industries Alliance’s (EIA) G-33 Committee on Data and Configuration Management initiated task PN 4888 to develop a consensus standard for data management. This is the firstsecond release of the standard. Contributors to this standard are identified in Annex A.
1
1
Introduction
Scope
Data is information (e.g., concepts, thoughts, opinions) that has been recorded in a form that is convenient to move or process.[peg1][peg2] Data can bemay representbe[peg3] tables of values of various types (numbers, characters, and so on). Data can also take more complex forms such as engineering drawings and other documents, software, pictures, maps, sound, and animation.
For the purposes of this standard, commercial and governmentmany enterprises concern themselves with three broad types of data.[peg4][peg5] Table 1 lists them, indicates how each is used, and provides examples.
Table 1. Types of Data[peg6][peg7]Type / Usage / Examples
Product / Collaboration / Cost, schedule, and performance data
Scientific data such as written notes and observation of phenomena
Engineering drawings and models, parts catalogs, software applications and their components, operational and maintenance instructions, and training materials
Business / Collaboration / Plans and schedules, financial information, software applications, inventory status, medical, facility, vacancy and human resource information
Operational / Transactional records exchange / Orders, issues, receipts, bills of lading, usage data and invoices
Data management, from the perspective of this standard, consists of the disciplined processes and systems that plan for, acquire, and provide stewardship for product and product-related business data, consistent with requirements, throughout the product and data life cycles. Thus, this standard primarily addresses product data and the business data intrinsic required for to collaboration during product acquisition and sustainment. It is recognized, however, that the principles articulated described in this standard also have broader application to business data and operational data generally. It is also recognized that the data addressed by this standard is subject to data administration, metadata management, records management, and other processes applied at the enterprise level, and that these principles must be applied in that enterprise context.
Data has many purposes, including stating requirements, providing proof of achievement, establishing a basis for long-term product support, and many others. Deliverable data (customer-accessible information) represents only a small fraction of the project data. In general, a vast amount of design, development, fabrication, and manufacturing data remains the intellectual property of the developer/producer. Further, the value of data is not limited to its use in support of a particular specific product: data may have a life cycle longer than that of the product it describes. For instance, data from previous projects forms part of the foundation for new product and process design. Data also supports the enterprise in process redesign and quality. Thus data is essential to competitive position. An enterprise’s dataif not properly safeguardedcan also be misused by a competitor to the competitor’s advantage. For these reasons, data is an integral part of an enterprise’s intellectual assets and overall enterprise knowledge.
Overview
This standard hascomprises has nine fundamental data management principles (Figure 1). Principles are high-level descriptive statements about describing high-quality DM; they establish what high-quality DM looks like. Each principle has a set of enablers, which provide the mechanisms of DM.
Figure 1. Data Management Principles[jms8]
[B9]
Two different viewpoints, corresponding to product and data life cycles, are important to DM. Product data (and related business data) is normally acquired or created as part of the development of a new product or similar initiative. This is the project perspective. Principle 2, which addresses the planning for and acquisition of data, and Principle 4, which deals with the identification of products, views, and related data elements, are written primarily from the perspective of the individual project. The remaining principles apply at both the project and enterprise levels. Principle 9 relates DM to knowledge management (KM).
The degree to which the DM principles in this standard apply to a product varies over the product’s life cycle. Similarly, they vary in applicability over the data life cycle. Some principles may not apply during every phase of either life cycle.
This standard addresses the functions of DM but not how to organize for DM. Each enterprise, for valid reasons, locates the functions of DM within enterprise elements that make sense within its own enterprise environment.
This standard is not intended for use as a compliance document or an evaluation mechanism for DM projects. It is intended for use as a source and reference document for either purpose. Appropriate application of the functions and principles in this standard enables the user to plan and implement a DM program for a product, project, or enterprise.
Terminology
During creation of this standard, significant effort went into using neutral terms wherever possible. Please see the Glossary, (Annex B) for the definition of those terms. Neutral terms used in this standard are provided in the glossary (Annex B). There is no intent to express preference for any particular terminology set. When planning and documenting a DM program, other aliases may be substituted for the neutral terminology. Three particular sets of terms deserve special mention. The first of these is the pair of terms “program” and “project.” In practice, the term “program” is often used to represent an undertaking that is larger in scope than a “project,” but such is not universally the case. This standard consistently uses the term “project.”
Second, this standard introduces some new neutral terminology used here in the context of DM for the first time. Where the terms are introduced for the first time, they are explained in context. The most important of these are probably the terms “data view,” “data view description,” and , “bill of data” (also called a bill of information)information”, and a set of terms associated with ownership and authorities..information).
Data normally has and will be a byproduct[peg10][peg11] is the product[peg12] or the result of engineering, management, financial, medical, retail, public works and other work efforts. This is true regardless of the enterprise. Historically, before the widespread availability of electronic databases, a deliverable data product generally resulted from locating, assembling, and presenting existing information in the format that a customer had specified. Because the technical work had to be done anyway, and its results recorded anyway, the cost of data of a data product was in locating, assembling, and presenting it. Given the effort and cost involved, it made sense to describe the result as a product. Over time, there was an increasing recognition that the imposition of customer-specified formats often increases cost without creating equivalent value, prompting a move to utilize supplier formats whenever possible. More recently, manual effort is being replaced by electronic extraction from an existing database, and the cost of retrieving, packaging, and even “personalizing” the data is much smaller. Further, what gets captured is a snapshot of data as seen from a particular perspective, at a particular point in time. Products become views of the data in the repository. A “data view,” a generalization of the concept of a data product, includesthe visual presentation of data by technologies such as digital images, geographical information systems, graphical user interfaces, multidimensional tables and graphs, virtual reality, three-dimensional presentations, and animation.[*]
The “data view description” provides the agreed-to content, preparation assumptions, intended use information, and (where applicable) format for a data view. The data product format can be specified in a data item description (DID), in an extensible markup language (XML) style sheet, or by other means.
The list of data views to be provided in accordance with a contract is a data bill of datainformation,data, an example of which is acontract data requirements list (CDRL). and all the relationships to associated data.. A data bill of datainformation is a multi-viewtwo-way concept: a buyer may need specific data from a supplier in order to operate a product or a supplier may need data from the buyer in order to perform under a contract. Further, in an integrated trading partner environment, both trading partners may obtain different views of the same data, as provided for in a data bill of informationdata, from a single data repository.
Insert Data BOI structure diagram here.
Ownership and authorities are found within the standard. An “owner” is the entity with legal rights to the information. This is no different that the owner of a physical asset – a product, building tool or computer.
Finally, references to terms such as the “enterprise,” “organization,” “performing activity,” “developing activity,” or “producing activity” refer to the enterprise that is responsible for performing DM. It could beFor the purposes of this standard, enterprise may be an organization, a commercial entity or a government agency. It may also be an entity resulting from a select collaboration between companies, a facility within a company, a program, a large project, or a social group. Within these principles, review the relevant scope of the “extended” enterprise in relation to the application of data management within the environment. It could be a commercial entity or a government agency. References to the customer should be interpreted as the activity that specifies requirements. A customer may be external to the developing and producing enterprise; may be an internal customer such as marketing, management, or the using department; or may even be a supplier in a conventional sense.
References
ANSI/EIA Standard 649, Configuration Management.
EIA Standard 836, Configuration Management Data Interchange and Interoperability.