Tab_2_DRM_Handbook_in_AF_BMA_20160113_MG_signed.pdf

Handbook for Data Reference Modeling in the

Air Force Business Mission Area

(AF BMA)

Version 2.0

Date: 13 January 2016

Editors: SAF/MGB

Signature Page

Submitted By

13 January 2016

DAVID L. MANCHESTER Date

Panel Chair

Approved By

MARILYN M. THOMAS, SES Date

Enterprise Senior Working Group Chair

1230932634C Typewritten Text

1230932634C Typewritten Text

1230932634C Typewritten Text

1230932634C Typewritten Text 2 February 2016

Table of Contents

Signature Page

1 Introduction

1.1 Purpose

1.2 Authority and References

1.3 Background

1.4 Scope

2 AF BMA COI

2.1 Description

2.2 AF BMA COI Roles and Responsibilities

3 AF BMA COI Processes and Deliverables

3.1 Overview

3.2 AF BMA COI Stand-up and Chartering Process

3.2.1 Overview

3.2.2 AF BMA COI Charter Development

3.2.3 AF BMA COI Stand-Up Governance and Approval Process

3.2.4 AF BMA COI Charter Configuration Management

3.3 Data Reference Model Development Process

3.3.1 Overview

3.3.2 DoDAF Models Development

3.3.3 Information Requirements Development

3.3.4 Proposed ADS Identification

3.3.5 Authorization Requirements Documentation Development

3.4 DRM Delivery and Approval Process

3.4.1 Overview

3.4.2 DRM Approval Governance Process

3.4.3 DRM Configuration Management

3.5 COI Stand-Down Request

Appendix A. References

Appendix B. Abbreviations and Acronyms

Appendix C. Terms

Appendix D. AF BMA COI Process Maps

1 Introduction

1.1 Purpose

The Handbook for Data Reference Modeling in the Air Force Business Mission Area (AF BMA)

(hereafter referred to as ‘the Handbook’) is a practical guide for establishing and managing an

AF BMA Community of Interest (COI). The Handbook outlines AF BMA COI procedures and standard work processes, with a focus on the deliverable products, framed within Air Force policy and governance structures, to include Enterprise Architecture and Data Management guidance. This document is intended to be used by IT initiatives during Step 3 of the Service

Development and Delivery Process (SDDP) outlined in AFMAN 33-402 to describe the information needed for a given mission process, including its authoritative data sources, and authorization requirements for specific information needed for a given mission process. This document provides practical guidance to stand-up/stand-down a COI and develops a DRM for a project team supporting an SDDP initiative.

1.2 Authority and References

This document was initiated/authorized by the AF BMA Data Management Coordination Panel

(hereafter referred to as ‘the Panel’) under the authority of the Enterprise Senior Working Group

(E-SWG). References in this document are listed in Appendix A.

1.3 Background

The Handbook is designed to support AF BMA COIs as they develop information requirements in support of capability initiatives, but does so in the context of AF data management governance processes. This context helps both functionals in developing capability initiatives and the AF enterprise as a whole to achieve its goals of discoverability and management of AF data. The

Handbook is designed to lead AF BMA COIs in the transformation from the current state of AF

Information Technology (IT) environment, which is largely a collection of isolated legacy systems connected through a variety of point-to-point interfaces, to a net-centric approach based on the development and use of secure and semantically-enabled services. The USAF has implemented the DoD Net-Centric Data Strategy (NCDS) and institutionalized governance and support for COI activities in the BMA through the E-SWG and the Panel. The roles and responsibilities of both of these governance bodies are described in the SWG Charter and the AF

BMA Data Management Coordination Panel Charter.

The Panel’s Charter (Reference B) calls for the alignment of the COI products (compliance with

DoD and USAF policy and guidance), reducing duplication of effort, maximizing reuse, and contributing to increased data integration across the AF BMA. The processes whereby an AF

BMA COI interacts with the Panel for review and approval of COI deliverable products are described in Section 3.0 of this document.

This document incorporates changes in terminology and authority to focus on the Panel's role in

AF BMA capability initiative requirements in data reference modeling. The Panel’s responsibility synergizes the data management strategy for the AF Defense Business Systems under E-SWG's oversight with data requirements that support the delivery of a Materiel Solution for a capability initiative. The previous USAF COI Coordination Panel Charter and Handbook had an AF enterprise-wide mandate under the auspices of the Transparency Integrated Product

Team. The USAF COI Coordination Panel was transferred to the authority of the Senior

Working Group (currently known as the E-SWG per AFPD 33-4, Terms), which oversees and governs AF BMA activities, in April 2007. The USAF COI Coordination Panel was re-named to the AF BMA Data Management Coordination Panel in November 2015. This Handbook implements three major updates/changes to AF BMA data management strategy and guidance not addressed in the previous version of the document. First, this Handbook aligns with

AFMAN 33-402 SDDP, specifically Step 3 activities that generate the DRM. Secondly, the

Handbook incorporates new guidance driven by the AF Deputy Chief Management Officer (AF

DCMO) Memorandum dated 15 Apr 2015, suspending Ontology requirements included in the

DRM. Lastly, this Handbook provides alignment of DRM deliverables for Authoritative Data

Source (ADS) registry in DoD Data Services Environment (DSE) per DoDI 8320.02 and DoDI

8320.07.

1.4 Scope

The work described in this document applies to all Air Force BMA IT capability initiative activities pursuing the implementation of a Materiel Solution under the guidance of the Service

Development and Delivery Process (SDDP; Reference M). These activities all fall under the governance and oversight of the E-SWG. AF BMA initiatives following the SDDP will follow this COI process for the creation and approval of their DRM. AF BMA initiatives which are not following the SDDP methodology, but which fall under E-SWG governance may be directed to follow this process by the E-SWG (Note: this authority is not delegated to the Panel).

The AF BMA COI standard processes are embedded within and aligned to a larger SDDP process. The SDDP is a 6-step process that delivers mission process-derived, IT-enabled capabilities, with AF BMA COI work occurring during Step 3 of the SDDP. The first two steps are dedicated to the identification of a need and the execution of a problem solving strategy that considers the full Doctrine, Organization, Training, Materiel, Leadership, Personnel, Facilities -

Policy (DOTMLPF-P) spectrum of solutions. Only when Materiel Solutions are identified (in

Step 3 of the SDDP) does the SDDP path include the AF BMA COI standard processes. The core work of the AF BMA COI is to develop the DRM, which is included in the Bounded User

Requirements (BUR) for the Materiel Solution. The DRM is a framework used to promote the common identification, use and appropriate sharing of data/information across the federal government. It provides standards and guidelines to help agencies structure, categorize, exchange and manage their data to improve the ability of government to perform cross-agency information sharing.

This Handbook describes the processes and business rules an AF BMA COI must use to develop the DRM. The purpose of the DRM is to provide the detailed information requirements, including: the information that serves as input to the Materiel Solution; the information generated by the Materiel Solution; the sources for all that information and the access constraints for users desiring to utilize the information. The information should be sufficient to satisfy relevant compliance requirements as part of downstream governance activities. The benefits of the DRM developed in SDDP Step 3 are thus derived from this modeling of detailed information requirements that will be included in the BUR for the Materiel Solution.

This Handbook also aligns the needs of DoD and USAF data management compliance requirements in the context of the DRM. The Handbook provides guidance to the functional community for requirements to manage and register some or all of a COI’s DRM into an approved repository (such as DSE).

This document refers to and provides links to supplemental guidance in the form of Tactics, Techniques, and Procedures (TTPs) throughout. These TTPs provide further details on how to accomplish the many tasks necessary throughout the lifecycle of an AF BMA COI. The TTPs are approved (IAW delegated authority by the E-SWG) by the Panel. COIs that are stood-up in the context of this Handbook are required to comply with the guidance detailed within them. A full list of TTPs supporting this Handbook is located in Appendix A.

This Handbook is again focused on the development of the DRM in SDDP Step 3 and the compliance/data management aspects that develop when a COI models data in the DRM. This

Handbook does not cover any processes beyond SDDP Step 3.

2 AF BMA COI

2.1 Description

A COI is a collaborative group who exchange information in pursuit of their shared goals, interests, missions, or business processes. The USAF utilizes COIs to detail the requirements for the purposes of identifying the information exchanged during the execution of mission processes and thereby defining the information requirements to a Materiel Solution. Information exchanges are defined in a broader context and can mean an interface between systems, organizations, or activity steps within a process. An AF BMA COI includes stakeholders collaborating on behalf of various components of the AF enterprise for the purposes of exchanging information during the execution of mission processes to define the information requirements to a Materiel Solution. These stakeholders may consist of a cross-section of business process owners, operators, data producers, data consumers, and Subject Matter Experts

(SMEs) from different organizations but tied to a common mission or problem.

Any of the following criteria among many others may lead to the formation of an AF BMA COI:

If following AFMAN 33-402, the initiative is pursuing a Materiel Solution, and has completed Step 3 contextual modeling

A group of stakeholders associated with a business process has conducted a business process engineering event and identified initial information requirements for the process’

Materiel solution followed by E-SWG approval

The Panel Chair or the E-SWG recognizes a mission need that requires cross-functional collaboration to address that need

2.2 AF BMA COI Roles and Responsibilities

AF BMA COIs will develop detailed information requirements (in the form of a DRM) in support of a Materiel Solution that has been targeted for implementation. The AF BMA COI is responsible for delivering the DRM as part of the SDDP Step 3 BUR for acquisition and implementation of the IT capabilities included in the Materiel Solution. AF BMA COIs are not responsible for the implementation of those capabilities, although it is likely that the same SMEs who support AF BMA COI activities may support implementation activities. AF BMA COIs can be reconstituted should a change in scope or implementation affect the DRM. The following are the individuals that comprise an AF BMA COI and the responsibilities they execute:

AF BMA COI Lead(s) will:

Coordinate with their respective Functional Panel Member and Panel staff to identify

COI members, who are stakeholders and representatives of the data and business processes involved in the COI

Coordinate the AF BMA COI charter and deliverables before submission to the Panel with their Functional Panel Member

Review and submit the proposed AF BMA COI charter and deliverables to the Panel through their Functional Panel Member

Provide status updates on the progress of AF BMA COI deliverables as needed to their

Functional Panel Member and the Panel Chair

Prepare and present appropriate presentations for proposed AF BMA COI charter and deliverables when submitted to the Panel (this will be coordinated with their Functional

Panel Member and the Panel staff prior to submission of Charters or deliverables)

Coordinate and communicate with COI members for appropriate inputs throughout the lifecycle of the AF BMA COI on the completion of all AF BMA COI deliverables, including all potential changes to the COI charter and the DRM after their approval

Manage the AF BMA COI activities leading to the submission of the AF BMA COI deliverables

AF BMA COI Members will:

Provide subject matter expertise of supported business processes and associated information assets

Represent the positions of their organization and functional domain business process stakeholders to the AF BMA COI

Inform their respective organizations about the perspectives, concerns, and interests of the AF BMA COI stakeholders

Participate in appropriate working groups to provide appropriate SME support

Participate in developing and evaluating AF BMA COI deliverables

System Engineering/Design Team Members (IAW section 1.6.7, AFMAN 33-402) will:

Document and model information exchange requirements determined by the COI to be incorporated into the DRM

Build the DoD Architecture Framework (DoDAF) models required in the Handbook, Information Requirements Identification, Proposed ADS Identification, and

Authorization Requirements Documentation that comprise the DRM

Participate in appropriate COI working groups to provide appropriate technical support

3 AF BMA COI Processes and Deliverables

3.1 Overview

This section details the overall process for standing-up and standing-down a BMA COI, the processes and activities for producing AF BMA COI deliverables during the COI’s lifecycle, and any DoD or USAF compliance concerns (including registration) that pertain to COI deliverables.

Registration of AF BMA COI deliverables is managed (under the oversight of the Panel) by the

Functional Panel Member. Registration will involve different repositories for different purposes

(e.g., discovery, configuration management, compliance). Process maps for the AF BMA COI lifecycle can be found in Appendix D.

3.2 AF BMA COI Stand-up and Chartering Process

3.2.1 Overview

A capability initiative will initiate stand-up request of their COI upon initiative sponsor approval of the SDDP Step 3 Contextual Model (CM). The capability initiative project team will form a candidate COI who will communicate the need to stand –up a COI to the Panel staff. The Panel staff (upon consultation with the Panel Chair) will designate a Functional Panel Member to represent the COI at the Panel. This designation will be based on the Functional Domain that would act as the initiative’s IT Investment Portfolio Manager. The candidate COI then develops a COI charter, and submits it for the COI Stand-Up Governance and Approval process. Once the

COI charter is approved, it will fall under the Panel for control of configuration management.

3.2.2 AF BMA COI Charter Development

The AF BMA COI Stand-up Process begins with the development of an AF BMA COI charter.

The Charter identifies the purpose, scope, and membership of the AF BMA COI, and outlines the timeline and dependencies for the AF BMA COI. The scope of an AF BMA COI’s work is determined by the list of information assets and business processes which are identified in the initiative’s SDDP Step 3 and contained in the CM. In certain circumstances, the Panel may grant the COI permission to form without a SDDP Step 3 CM (e.g., when an initiative is following a business process engineering methodology other than the SDDP and has identified the processes and information assets that will scope their work).

The majority of information in the COI charter’s content should be available in previously developed documents created by the project (e.g., listing the Information Assets from the CM, Performance Reference Model (PRM), Business Reference Model (BRM), and the initiative schedule). COI membership will often be the only new information that needs to be developed.

This is especially true in cases where the COI needs to draw from multiple functional organizations to support their work. In cases where the COI needs assistance in identifying members from other functional organizations, the COI Lead should reach out to their Functional

Panel Member or the Panel staff, which can facilitate conversations with relevant Panel Members to identify COI membership. The COI Lead should also identify any potential outside ADSs for

Information Assets identified in the CM, and ensure any potential ADS Data Producers (e.g., PMOs) are included as COI members.

If there is a significant change in scope for the AF BMA COI after AF BMA COI Charter approval, then the AF BMA COI will need to re-charter. The Panel will review the change in scope and make the determination on re-chartering. Minor changes for the AF BMA COI can be made as administrative amendments to the COI Charter as approved by the Panel.

AF BMA COI Charter must include the following content:

Authority: The AF BMA COI is established and chartered under the authority of the E-

SWG and the governance of the Panel. The AF BMA COI will submit its deliverables to the Panel through its Functional Panel Member thereon.

Need/Purpose: The need for an AF BMA COI is inherited from the SDDP documents (in particular the PRM), and the purpose describes what the AF BMA COI intends to deliver

Scope: The scope is the set of mission and business processes which the AF BMA COI is supporting, to include the list of information assets that will be a part of the Materiel

Solution

Deliverables: The Deliverables Section will list the deliverables that the COI will generate.

Membership/Participation: The membership/participation consists of three groups of stakeholders. This will include:

o COI Lead(s), who is typically at the Action Officer-level and the initiative’s project lead or member from the overall initiative, and will be available to respond and coordinate with the appropriate Functional Panel Member and Panel staff as necessary o COI Members, who are the relevant stakeholders with the knowledge and the authority to represent the business processes supported by the AF BMA COI, the data used by those processes, and any relevant systems that are part of the current or future states of the relevant organizations and processes, or additional members designated by the Panel o System Engineering/Design Team Members (IAW section 1.6.7, AFMAN 33-402), that support an initiative and are responsible for the modeling/coordination/delivery of the AF BMA COI deliverables

Timeline/Schedule: A baseline schedule for completing all of the activities and deliverables within the standard COI Process

Dependencies: Any dependencies which could affect the project schedule and delivery of the DRM

For further guidance and direction in completing the AF BMA COI Charter, refer to the AF

BMA COI Charter Development TTP at this link.

3.2.3 AF BMA COI Stand-Up Governance and Approval Process

AF BMA COI stand-up and charter approval is a two-step process:

For step 1, the AF BMA COI will submit a draft charter to the Functional Panel Member. Upon satisfactory review by the Functional Panel Member, the Functional Panel Member will submit the charter to the Panel staff for review. Upon satisfactory review by the Panel staff, the Panel

Chair will direct submission of the charter to the Panel agenda for approval by the Panel.

The Functional Panel Member and Panel staffs review consists of a validation of an identified set of business processes and information assets which scope the AF BMA COI’s work. If the initiative is following the SDDP process, then this content is provided by the completed SDDP

Step 3 CM that has been approved by the initiative sponsor. When an initiative is following a methodology other than the SDDP, information assets have been identified and approved by the initiative sponsor.

For step 2, the Panel Chair will direct either a meeting presentation or an electronic vote with the

Panel, giving sufficient time to the Panel to review the proposed charter and provide comments.

Upon satisfactory adjudication of all comments and concurrence of the Panel Members the charter will be submitted to the Panel Chair by the Panel staff for approval signature.

For further guidance and details (including entrance criteria) in completing the AF BMA COI

Stand-up process, refer to the AF BMA COI Stand-Up TTP at this link.

3.2.4 AF BMA COI Charter Configuration Management

Upon signature by the Panel Chair, the AF BMA COI charter will be under the configuration management control of the Panel. When further changes are necessary to the COI charter, the

COI Lead will notify and recommend the necessary changes to the Functional Panel Member.

The Panel Chair and the Functional Panel Member will then determine based on the significance of the change, if any change of the charter needs to be reviewed by the Panel or any other significant action (such as re-chartering or elevation to the E-SWG) is required.

The Panel will retain final configuration control on the COI charter after it has been signed until the COI is stood-down. Any changes to the charter will be first recommended by the COI Lead https://cs1.eis.af.mil/sites/afdbt/COI/COI%20Artifact%20Management/Forms/AllItems.aspx?RootFolder=%2Fsites%2Fafdbt%2FCOI%2FCOI%20Artifact%20Management%2FHandbook%2FTTPs%2FAF%20BMA%20COI%20Charter%20Development&FolderCTID=0x012000E664CBCABF3339458FF2CB2D10FB39DA&View=%7bFCCA03A5-EB4A-4865-93CD-0E12F9F64FEE%7d&InitialTabId=Ribbon%2EDocument&VisibilityContext=WSSTabPersistence https://cs1.eis.af.mil/sites/afdbt/COI/COI%20Artifact%20Management/Forms/AllItems.aspx?RootFolder=%2Fsites%2Fafdbt%2FCOI%2FCOI%20Artifact%20Management%2FHandbook%2FTTPs%2FAF%20BMA%20COI%20Stand%2DUp&FolderCTID=0x012000E664CBCABF3339458FF2CB2D10FB39DA&View=%7bFCCA03A5-EB4A-4865-93CD-0E12F9F64FEE%7d&InitialTabId=Ribbon%2EDocument&VisibilityContext=WSSTabPersistence to the Functional Panel Member, who will then communicate the change request to the Panel

Chair. The Functional Panel Member and Panel Chair will decide if the change necessitates one of the following decisions: 1) Change request is minor and therefore subject to the approval of the Panel Chair and Functional Panel Member; or 2) Change request is significant and must be presented to the Panel for further action. Significant change is defined as a change that either considered to be out of the scope identified in the COI charter or has cross-functional implications.

Any registration of COI products (including an AF BMA COI charter) will be done IAW the

TTP for AF BMA DRM Registration Guidance at this link.

3.3 Data Reference Model Development Process

3.3.1 Overview

The COI and System Engineering/Design Team Members will model and develop the DRM deliverables. The DRM deliverables will consist of: 1) the DoDAF models required for the

DRM; 2) the Identification of Information Requirements; 3) Identification of ADSs; and 4)

Documentation of Authorization Requirements. The Identification of Information Requirements, Identification of ADSs, and Documentation of Authorization Requirements are modeled in the

DRM Vocab Spreadsheet. The DRM Vocab Spreadsheet template can be found at this link.

While developing the DRM, a COI should utilize all available resources for maximum discoverability and re-use. A list of reference sites to research and optimize alignment of business processes and authoritative data can be found on the Reference Sites List provided in the AF BMA COI Stand-Up TTP (referenced in 3.2.3).

3.3.2 DoDAF Models Development

DoDAF has been designed to meet the specific business and operational needs of the DoD. It defines a way of representing an enterprise architecture that enables stakeholders to focus on specific areas of interests in the enterprise, while retaining sight of the big picture. To assist decision-makers, DoDAF provides the means of abstracting essential information from the underlying complexity and presenting it in a way that maintains coherence and consistency. One of the principal objectives is to present this information in a way that is understandable to the many stakeholder communities involved in developing, delivering, and sustaining capabilities in support of the stakeholder's mission. It does so by dividing the problem space into manageable pieces, according to the stakeholder's viewpoint, further defined as DoDAF-described Models.

COIs will develop DoDAF models as part DRM development to model data requirements and give a depiction of information processes and the business relationships involved in the initiative.

The Data and Information Viewpoints in particular will be used as models. The DoDAF-described Models within the Data and Information Viewpoint provide a means of portraying the operational and business information requirements and rules that are managed within and used as constraints on the organization’s business activities.

The COI will, at a minimum, develop a DoDAF Data and Information Viewpoint Conceptual

Data Model (known hereafter as the DIV-1). The DIV-1 is a visual diagram that documents the https://cs1.eis.af.mil/sites/afdbt/COI/COI%20Artifact%20Management/Forms/AllItems.aspx?RootFolder=%2Fsites%2Fafdbt%2FCOI%2FCOI%20Artifact%20Management%2FHandbook%2FTTPs%2FAF%20BMA%20DRM%20Registration%20Guidance&FolderCTID=0x012000E664CBCABF3339458FF2CB2D10FB39DA&View=%7bFCCA03A5-EB4A-4865-93CD-0E12F9F64FEE%7d&InitialTabId=Ribbon%2EDocument&VisibilityContext=WSSTabPersistence https://cs1.eis.af.mil/sites/afdbt/COI/COI%20Artifact%20Management/Forms/AllItems.aspx?RootFolder=%2Fsites%2Fafdbt%2FCOI%2FCOI%20Artifact%20Management%2FHandbook%2FTemplates%2FDRM%20Vocab%20Spreadsheet&FolderCTID=0x012000E664CBCABF3339458FF2CB2D10FB39DA&View=%7bFCCA03A5-EB4A-4865-93CD-0E12F9F64FEE%7d high level business information assets and basic relationships identified in the AF BMA COI

Charter. The DIV-1 is used to document the business information requirements and structural business process rules of the architecture. It describes the information that is associated with the information of the architecture. Included are information items, their attributes or characteristics, and their inter-relationships. The intended usage of the DIV-1 includes information requirements and information hierarchy.

For further information on requirements (including additional requirements for other DoDAF models based on Panel/E-SWG priorities) and for further details and guidance in completing the

DoDAF Models Development, refer to the DoDAF Models Development TTP at this link.

3.3.3 Information Requirements Development

Information Requirements document the data associated with Information Assets listed in the AF

BMA COI Charter. Information Requirements are developed for 3 general reasons. First, Information Requirements are required to describe a Materiel solution that does not currently exist. Second, they could be a needed requirement relative to an existing system. Third, they are required for previously defined Information Assets that do not necessarily fit for the first reason.

The Information Requirements are designed to use and meet the intent of industry standards found in ISO/IEC 11179 (Information Technology–Metadata Registries) which identifies the components that need to be available for determining the meaning of data elements. An

Information Requirement does not contain data itself, rather it provides an understanding of the meaning, representation, and identification of units of data.

Information Requirements describe the Information Assets and their component parts

(Information Elements and Information Domains), which are necessary to support the data needs of the Materiel Solution. Information Elements and Domains contain the necessary information to clearly describe, inventory, analyze, and classify data. They provide an understanding of the meaning, representation, and identification of units of data. Additionally they support the creation of or alignment to the DoD Business Enterprise Architecture DoDAF models.

3.3.3.1 Information Assets and Information Elements

Information Assets are typically identified in the COI charter and were derived during the Step 3

SDDP Contextual Model. During the development of the DRM, a COI might require

Information Assets identified outside of the Contextual Model. These additions are within the purview of the COI to model and there is no requirement to update the COI charter to include these additional Information Assets (providing the Information Assets are within the scope of the

COI charter).

Information Assets are typically decomposed into Data Elements. An Information Asset is a definable piece of information, stored in any manner, which is recognized as valuable to an organization. A Data Element is a unit of data for which the definition, identification, representation and permissible values are specified by means of a set of attributes. A Data

Element is an atomic unit of data and can include “smart code” data elements that can be decomposed into distinct Data Elements, which is typically defined as the smallest unit of data https://cs1.eis.af.mil/sites/afdbt/COI/COI%20Artifact%20Management/Forms/AllItems.aspx?RootFolder=%2Fsites%2Fafdbt%2FCOI%2FCOI%20Artifact%20Management%2FHandbook%2FTTPs%2FDoDAF%20Models%20Development&FolderCTID=0x012000E664CBCABF3339458FF2CB2D10FB39DA&View=%7bFCCA03A5-EB4A-4865-93CD-0E12F9F64FEE%7d&InitialTabId=Ribbon%2ELibrary&VisibilityContext=WSSTabPersistence within a model (i.e., a single code, date, or number). An example of an Information Asset and its decomposed Data Elements can be seen in Example 1:

Information Asset

Maintenance Plan

Data Element

Part Number

Nomenclature

Organizational Planner

Resource Control Center Example 1: Information Asset Decomposition

The above example shows Maintenance Plan identified as an Information Asset. The

Maintenance Plan Information Asset has been further decomposed into four Data Elements: Part

Number, Nomenclature, Organizational Planner, and Resource Control Center. This particular example only required four Data Elements, but an Information Asset can be decomposed into as many Data Elements as necessary to properly model the information requirements of that DRM.

Contrarily, during development it might be discovered that an Information Asset may not need to be decomposed into any Data Elements. The Information Asset would just stand on its own.

Lessons learned in previous capability initiatives showed that the simplistic model shown above is inadequate to model the complex relationships in data between Information Assets in a single

DRM. This Handbook adds a level of detail to address this gap. In Information Requirements development, this Handbook uses the term Information Elements. Information Elements is a term used in ISO/IEC 20943-1 (Reference R) that can denote any unit of information (including potentially Data Elements and Information Assets). For purposes of this Handbook, Information

Elements will be the unit into which all Information Assets in the DRM will be decomposed.

This decomposition into Information Elements versus Data Elements can be seen in Example 2 below.

Information Asset

Maintenance Plan

Information Element

Part Number

Nomenclature

Organizational Planner

Resource Control Center

Example 2: Information Asset Decomposition Using Information Elements

The above example shows Maintenance Plan identified as an Information Asset. The

Maintenance Plan Information Asset has been further decomposed into four Information

Elements: Part Number, Nomenclature, Organizational Planner, and Resource Control Center.

This particular example only required four Information Elements, but an Information Asset can be decomposed into as many Information Elements as necessary to properly model the information requirements of that DRM. Contrarily, during development it might be discovered that an Information Asset may not need to be decomposed into any Information Elements. The

Information Asset would just stand on its own.

Using Information Elements versus only Data Elements allows additional flexibility in modeling an Information Asset. An Information Element can be the lowest-level, “atomic unit” like a Data

Element, or can be a “previously developed Information Asset”. A “previously developed

Information Asset” is an Information Asset in the DRM that has already been decomposed into

Information Elements (or has been determined no decomposition is necessary for that

Information Asset). An example of developing and labeling Information Elements by element type can be seen in the example below.

Information Asset

Maintenance Plan

Information Element

Element Name Element Type

Part Number Data Element

Nomenclature Data Element

Organizational Planner Data Element

Resource Control Center Data Element

Example 3: Labeling Information Elements by Element Type

The above example shows Maintenance Plan identified as an Information Asset. The

Maintenance Plan Information Asset has been further decomposed into four Information

Elements: Part Number, Nomenclature, Organizational Planner, and Resource Control Center.

This particular example shows a further break-down into Element Name and by Element Type.

During development, the COI will identify Element Names for Information Elements based on the business process behind the information exchange. Element Type will be determined on whether the Information Element is a Data Element or a “previously developed Information

Asset”. In Example 3, the four Information Elements are the lowest level of data, at the “atomic level”. The Element Types in this example are therefore all Data Elements.

Using Information Elements allows for a more flexibility model in detailing relationships between multiple Information Assets. An Information Asset can be decomposed into

Information Elements that are all Data Elements, all “previously developed Information Assets”, or a combination of Data Elements and Information Assets. Whenever an Information Asset cannot be decomposed into Information Elements or is decomposed into Information Elements that are modeled as Data Elements, then the Information Asset is labeled as a “Regular Asset”.

Whenever an Information Asset is decomposed into Information Elements of the type one or more “previously developed Information Assets” (including any combination of Data Elements), then the Information Asset is labeled as a “Multi-Asset”. An example of how an Information

Asset is labeled by type is seen in the example below.

Information Asset

Maintenance Plan

Asset Type

Regular Asset

Information Element

Element Name Element Type

Part Number Data Element

Nomenclature Data Element

Organizational Planner Data Element

Resource Control Center Data Element Example 4: Labeling Information Assets by Asset Type- ”Regular Asset”

The above example shows Maintenance Plan identified as an Information Asset. The

Maintenance Plan Information Asset has been further decomposed into four Information

Elements: Part Number, Nomenclature, Organizational Planner, and Resource Control Center.

These four Information Elements are all Data Elements; therefore, the Asset Type for the

Information Asset would be a “Regular Asset”. If the Maintenance Plan Information Asset could not be decomposed into further Information Elements of any type, then it would also be a

“Regular Asset”.

Information Assets can be made up of any combination of Information Element Types that are

Data Elements or “previously developed Information Assets”. When an Information Asset is decomposed into one or more Information Elements that are “previously developed Information

Assets”, then the Information Asset is labeled as a “Multi-Asset” type of Information Asset. An example of how an Information Asset is labeled by “Multi-Asset” type is seen in the example below.

Information Asset

Material Supportability Outlook

Asset Type

Multi-Asset

Information Element

Element Name Element Type

Maintenance Plan Information Asset

Material Requirements Data Element

Part Type Data Element

Unit per Assembly Data Element Example 5: Labeling Information Assets by Asset Type- “Multi-Asset”

The above example shows Material Supportability Outlook identified as an Information Asset.

The Material Supportability Outlook Information Asset has been further decomposed into four

Information Elements: Maintenance Plan, Material Requirements, Part Type, and Resource

Control Center. The first Information Element, Maintenance Plan, is a “previously developed

Information Asset” from Example 4. It is an Information Asset that was previously decomposed into four Information Elements: Part Number, Nomenclature, Organizational Planner, and

Resource Control Center. An Information Element that is a “previously developed Information

Asset” will be labeled as the Information Asset Element Type. During development, it was identified that the Information Assets Material Supportability Outlook and Maintenance Plan had a relationship between them and that Material Supportability Outlook required in its modeling all of the Information Elements identified in Maintenance Plan. The other Information Elements decomposed for Information Asset Material Supportability Outlook (Material Requirements, Part

Type, and Unit per Assembly) are the lowest level “atomic unit” of data and are therefore Data

Elements.

Example 5 shows an Information Asset that has been decomposed into four Information

Elements: One “previously developed Information Asset” and 3 Data Elements. Because

Material Supportability Outlook Information Asset was decomposed into one or more

Information Elements that are “previously developed Information Assets” and therefore labeled as Information Asset Element Type, Material Supportability Outlook is labeled as a “Multi-

Asset”. This label shows that there are more than one Information Assets related to each other in the modeled Information Asset.

Using the methodology discussed in this section helps model the potentially complex relationships between Information Assets and Information Elements. Note that not all

Information Assets are Information Elements. An Information Asset can be an Information

Element, but not necessarily. Only those “previously developed Information Assets” that are required in the decomposition of another Information Asset (like in Example 5) are also

Information Elements. All development of Information Assets and Information Elements in the

DRM should fall in the category of either Example 4 or Example 5 (one or more Information

Asset as Information Element).

3.3.3.2 Information Domains

In developing Information Requirements in the DRM, further values, known as Information

Domains, that model an Information Element are sometimes required. Information Domains define the value limits which an Information Element can contain. Information Domains are developed to provide a standard means of modeling these additional values which can be re-used across Information Elements. An Information Element may be limited to a range of values. That range of values could be a specific, an enumerated list of values either defined relative to the element itself or it could be drawn from some other reference. Alternatively, the Information

Element’s values may be flexible, but have a preferred interpretation. For example, an

Information Element could contain a number, but that number should be expressed in the context of a dimension (i.e., distance, temperature) or specific unit of measure (i.e., feet versus meters, Centigrade versus Fahrenheit).

The usage of Information Domains to provide further detail for Information Elements is conditional. If the Information Element is an Information Asset or there is no need to specify a limitation on an Information Element’s range of values (e.g., a Data Element could store text of any length or content), then the Information Domain should not be developed for that

Information Element. The Information Domain is required to be developed in order to provide a better understanding of the values involved in modeling a Data Element type of Information

Element.

When an Information Element meets the conditions for developing an Information Domain, the

Information Domain must be named appropriately along with a brief description. The examples used to provide guidance for Information Domains can be seen below.

Information Element A Information Element B

Element Name Element Name

Gender of Employee - Code Incident Report

Element Type Element Type

Data Element Data Element

Domain Name Domain Name

Human Gender Codes N/A

Domain Description Domain Description

Codes for Human Genders N/A

Example 6: Conditions of when to Model Information Domains

In the above example, Information Element A identified the requirement for an Information

Domain, whereas Information Element B does not. Information Element A defines the value meaning of the Information Element for Gender of Employee – Code. Gender of Employee –

Code has the Element Type of Data Element. Additionally, it has identified requirements of a limited range of values, and meets the conditions of requiring an Information Domain. The

Information Domain for Gender of Employee – Code was named Human Gender Codes and given a brief description, Codes for Human Genders. Information Element B does not meet the conditions for requiring an Information Domain. It meets the first condition of being a Data

Element, but it requires a free-format text field with no character limits and therefore has no limited range of values.

Once the need for an Information Domain has been identified, the Information Domain can be modeled based on its requirements. These requirements for Information Domains are known as

Domain Values. Domain Values model the various ways an Information Domain models the limited range of values to an Information Element. There are three Domain Values to model for an Information Domain: 1) Dimensionality; 2) Allowable Values; and 3) Domain Value Rule.

The requirement to model any of the three Domain Values is conditional and is dependent on the requirements for modeling the limited range of values in the Information Domain.

Dimensionality is the Domain Value for units of measure. Dimensionality expresses units of measurement without the unit (temperature instead of degrees Fahrenheit or Celsius), and can be applied to both physical dimensions (e.g., length, mass, velocity) and to non-physical dimensions

(e.g., currency, quality indicators). Dimensionality shows the equivalence class relationship between units of measure. If for example one Information Element was Length in Feet, but another was Length in Miles, they would have the same unit of measurement (unit of length).

The modeling of Dimensionality is conditional. Dimensionality will be modeled whenever the need for an Information Domain has been identified and the Information Element is expressed in a unit of measurement. An example of the Dimensionality Domain Value can be seen below.

Information Element A Information Element B

Element Name Element Name

Total Amount of Funds - Dollars Total Amount of Funds - Euros

Element Type Element Type

Data Element Data Element

Domain Name Domain Name

Amounts in Whole US Dollars Amounts in Whole Euros

Domain Description Domain Description

Monetary Amount in Whole US Dollars Monetary Amount in Whole Euros

Dimensionality Dimensionality

Monetary Units Monetary Units Example 7: Dimensionality Domain Value

In the above example, Information Element A has identified the requirement for an Information

Domain. The Domain Description, Monetary Amount in Whole US Dollars, is expressed in a unit of measurement (US dollars); therefore, a Dimensionality can be identified. The

Dimensionality identified is Monetary Units. An understanding of Dimensionality is important in modeling data. Dimensionality allows knowing whether data supplied in one set of units can be transformed into another. Information Element B is in Euros, but has the same

Dimensionality as Information Element A. This allows the ability to show an equivalency or conversion between the Information Elements sharing the same Dimensionality.

An Allowable Value is the Domain Value for the list of values and value descriptions required by the Information Element. The modeling of Allowable Values is conditional. Allowable

Values will be modeled whenever the need for an Information Domain has been identified and the Information Element is a limited set of characters with a description to each character. An example of the Allowable Values Domain Value can be seen below.

Information Element A Information Element B

Element Name Element Name

Gender of Employee - Code Gender of Employee - Code

Element Type Element Type

Data Element Data Element

Domain Name Domain Name

Human Gender Codes Human Gender Codes

Domain Description Domain Description

Codes for Human Genders Codes for Human Genders

Allowable Values Allowable Values

<1, Male> <2, Female> <0, Unknown>

<M, Male> <F, Female> <U, Unknown>

Example 8: Allowable Values Domain Value

In the above example, Information Elements A and B have identified the requirement for

Information Domains. Information Elements A and B have both identified the need to model a limited set of codes with accompanying descriptions for those codes and therefore require

Allowable Values. They both contain a limited set of codes with accompanying code descriptions (Male, Female, and Unknown). Information Elements A and B are virtually identical with the exception of one using numbers as the limited set of codes and the other using letters as the limited set of codes. Both are shown to demonstrate that either methodology can be used. Example 8 shows 3 Allowable Values for Information Elements A and B, but there is no requirement to the limit of the number of Allowable Values that can be modeled.

A Domain Value Rule is a rule that describes the limits of the value. The rule specifies which values belong to the Information Domain and which do not. Rules are created when there is a limit on the number of values, but the exact values that will be used are unknown. For example, the Information Element might require the input of a whole number between 1 and 1000. This example would require a Domain Value Rule. An example of the Allowable Values Domain

Value can be seen below.

Information Element A

Element Name

Industry Description for Person’s Job - Text

Element Type

Data Element

Domain Name

Textual English Industry Descriptions

Domain Description

Textual Descriptions of an Industry.

Domain Value Rule

English text up to 60 characters

Example 9: Domain Value Rule

In the above example, Information Element A has identified the requirement for an Information

Domain. Information Element A has identified the need allow free-format input of characters with a limit, and therefore requires a Domain Value Rule. The difference between Allowable

Values and Domain Value Rules is that Allowable Values is a limited identified set of codes with accompanying descriptions (see Example 8), whereas Domain Value Rules are descriptions of the characters that can be selected and the limitations to selecting them.

Information Domains are categorized into three Domain Types. The Domain Types are: 1)

Enumerated; 2) Non-enumerated; or 3) Both Enumerated and Non-enumerated. An Enumerated type of Information Domain is a domain where all the permissible values are listed explicitly.

Examples of enumerated type of Information Domains include code sets, standard classifications, and categorizations. A Non-enumerated type of Information Domain is where the values are expressed using a rule. Examples of types of non-enumerated value domains include intervals of numbers, character strings, and bit maps. The Both Enumerated and Non-enumerated type of Information Domain is a limited, rare instance that occurs when values fall within a certain range, have a minimum (or maximum) value, and discrete values below the minimum (or above the maximum) are used for special cases. An example of Enumerated and

Non-enumerated type of Information Domains can be seen below.

Element Name Element Name

Gender of Employee - Code Industry Description for Person’s Job - Text

Element Type Element Type

Data Element Data Element

Domain Name Domain Name

Human Gender Codes Textual English Industry Descriptions

Domain Type Domain Type

Enumerated Non-enumerated

Domain Description Domain Description

Codes for Human Genders Textual Descriptions of an Industry

Dimensionality Dimensionality

N/A N/A

Allowable Values Allowable Values

<1, Male> <2, Female> <0, Unknown>

N/A

Domain Value Rule Domain Value Rule

N/A English text up to 60 characters

Example 10: Enumerated and Non-enumerated Information Domain Types

In the above example, Information Elements A and B have both identified the requirement for an

Information Domain. The Information Domain for Information Element A is the enumerated type. The Information Domain requires a listed set of identified values with descriptions. The

Information Domain for Information Element B is the non-enumerated type. The Information

Domain does not require a listed set of identified values, but does require rules for free-format input of characters with a limit. Enumerated type of Information Domains will always have

Allowable Values, but never have a Domain Value Rule, with Dimensionality being conditional based on the usage of a unit of measurement. Non-enumerated type of Information Domains will always have a Domain Value Rule, but never have Allowable Values, with Dimensionality being conditional based on the usage of a unit of measurement.

The Information Domain type Both Enumerated and Non-enumerated is used in rare, specific circumstances. An example of the circumstance for Both Enumerated and Non-enumerated type can be seen below.

Information Element A

Element Name

Volume of Fuel Usage - Gallons

Element Type

Data Element

Domain Name

Volume in gallons (US, liquid) x 1000

Domain Type

Both Enumerated and Non-enumerated

Domain Description

Liquid volume in thousands of US gallons

Dimensionality

Volume Units

Allowable Values

…