DLM 4000.25, Volume 1, May 19, 2014

# C5. CHAPTER 5

**DLMS DATA MANAGEMENT**

C5.1.  PURPOSE.  The chapter describes the critical factors in developing, managing, and enabling information sharing through the use of Defense Logistics Management Standards (DLMS) data management practices. Details about data management concepts, procedures, and tools are covered in subsequent chapters.

C5.2. GUIDING PRINCIPLES

	C5.2.1.  Compliance.  DLMS conform to DoD policies for data management policies as noted in the references identified in Chapter 1 (C1.3) and Chapter 2 (C2.3).  DLMS also use standards from voluntary consensus standards organizations such as Accredited Standards Committee (ASC) X12. DLMS data management helps ensure compliance with DoD and voluntary consensus standards. 

	C5.2.2.  Interoperability.  DLMS data management supports data element coordination to provide interoperability among logistics trading partners.  The use of DLMS procedures and metadata repository (e.g., Logistics Data Resource Management System (LOGDRMS)) simplifies and enables understanding and accessibility of data elements and their syntactical representations.

	C5.2.3.  Data Quality.  Data quality deficiency is often due to inconsistent or inaccurate data usage, or conflicting business rules or business processes.  The Defense Enterprise Data Standards Office coordinates data issues under the governance of the Process Review Committees (PRC). Revisions to the DLMS procedures and component systems are necessary to harmonize data.

	C5.2.4.  Revisions to Data Requirements.  Revisions to the DLMS and data requirements are proposed and incorporated under the PRC forum for the respective logistics functional area. Submit all proposed change requests through the designated DoD Component PRC representatives. More information on the DLMS PRC process can be found  in Volume 1, Chapter 3 of this manual on the DEDSO Website on the Process Changes page.

C5.3.  GOVERNANCE

	C5.3.1.  Approach

		C5.3.1.1.  The process for adding, modifying, and deleting DLMS data elements is part of the Proposed DLMS Change (PDC)/Approved DLMS Change (ADC) process.  The DLMS PDC and ADC templates provide sections to identify changes to DLMS data elements.  Information on data element proposals should be included in relevant PDC/ADC sections as appropriate, but common practice is to include data element changes in the description of change, the impacts, explanations, and any descriptions of DLMS IC changes.  The PDC/ADC procedures are in Volume 1 Chapter 3 of this manual and at the Process Changes page.

		C5.3.1.2.  Changes to data representations in DLMS Implementation Conventions are made when the ADC is published.

		C5.3.1.3.  Approved data element changes are represented in LOGDRMS upon the implementation date identified in the ADC.  If no implementation date is explicitly designated, LOGDRMS will be updated concurrent with the date of the ADC.

	C5.3.2.  Responsibilities

		C5.3.2.1.  Components.  Components contribute to the maintenance of DLMS by developing and commenting on PDCs and ADCs.  

		C5.3.2.2.  Defense Enterprise Data Standards Office.  The Defense Enterprise Data Standards Office is the DoD Executive Agent for Logistics Data Interchange and is responsible for change management concerns and technical issues related to the implementation of DLMS Data Elements and Information Exchanges as defined by Defense Logistics Manual (DLM) 4000.25.  The Defense Enterprise Data Standards Office oversees LOGDRMS for maintaining and presenting DLMS data elements.  Prior to staffing a PDC, and again with the ADC, the relevant PRC Chair coordinates content and quality review of additions and modifications to data elements among Defense Enterprise Data Standards Office staff.

C5.4.  METADATA MANAGEMENT.  Metadata are the defining characteristics about data elements of a database or transaction. However, DLMS managed metadata expands beyond the simple characteristics of data elements or a transaction.  It also includes, associated code values, business rules, transaction formats, and the repository that hold the information.  These data categories reflect distinctions between generic and context-specific definitions as well as different representations when applied within syntactical standards, or how they’re used in a particular business transaction.  Understanding the relationship among the data categories and the governing process will improve data quality through the use of consistent data assets. Table C5.T1 identifies the DLMS Metadata Categories, the details of these categories are described in the subsequent chapters.

	C5.4.1.  The following information is recorded in LOGDRMS.  LOGDRMS is a publically accessible webpage.

		C5.4.1.1  Metadata for each data element, including a definition, minimum and maximum characters, data type, and authoritative source(s)

		C5.4.1.2  Code values and special business rules 

		C5.4.1.3  DLMS data elements and their relationships to X12 syntax representations

		C5.4.1.4  Mapping of DLMS data elements and code values in the DLMS transactions

	C5.4.2.  Developing DLMS Data Requirements.  Data elements, business rules, and code values.

		C5.4.2.1.  Data requirements identified during PDC development (Volume 1, Chapter 3), are compared against the DLMS elements recorded in LOGDRMS to check if the element is already supported, needs to be modified, or needs to be added.  While preferable for DLMS data elements to use terms commonly used by subject matter experts, reuse of an existing DLMS element with the same semantic meaning may take precedence in the interest of interoperability.  Conversely, DLMS data elements may be adjusted from common industry usage to distinguish concepts that are almost the same but should not be confused as synonyms.  These same concepts are used to develop code values and business rules.

		C5.4.2.2.  The creation of a core data element occurs when an Approved DLMS ADC adds a new DLMS data element that does not represent a context-specific version of an existing core element.  The core element name and definition are derived from the approved DLMS element and are to be made as generic as possible.  It is possible that the Core element may duplicate the DLMS element if the DLMS element is generic.

		C5.4.2.3.  When ADCs include mappings of DLMS elements to X12 structures in the DLMS ICs, LOGDRMS is updated to reflect the use of X12 data elements.

C5.5.  COMMUNITIES OF INTERESTS (COI).  The orchestration of logistics data management requires continuous dialog and coordination with the other DoD Components, Federal agencies, and Commercial communities to ensure shared data is visible, understandable, and interoperable.  The Defense Enterprise Data Standards Office staff participates in various COIs focused on enterprise data standards and interoperability issues.

	C5.5.1  DoD Metadata Registry (MDR).  Directive DoD 8320.02, “Data Sharing in a Net-Centric Department of Defense”, April 23, 2007, requires that Data assets must be made understandable and discoverable by publishing associated semantic and structural metadata in a federated MDR.  Defense Enterprise Data Standards Office is the manager of the Logistics namespace in the MDR.  When DLMS ICs are updated by ADCs, an XML schema is generated from the DLMS IC as an alternative syntactical approach.  These XML schemas are posted to the MDR on a regular basis. 

	C5.5.2.  Country Code Working Group (CCWG).  Defense Enterprise Data Standards Office is a voting member of the CCWG.  It was established to create and maintain the configuration management process for the maintenance of the Geopolitical Entities, Names, and Codes (GENC) Standard for use by the U.S. Federal Government and the Department of Defense.  GENC is the U.S. Government profile of ISO 3166, modified only where necessary to comply with U.S. law and U.S. Government recognition policy.  The complete set of entries in the GENC Standard may be browsed and searched from the GENC Discovery page. Federal and DoD Component systems, including MAPAD and DoDAAD must be in compliance with the GENC Standard.

	C5.5.3.  Business Enterprise Architecture (BEA).  In 2005, the National Defense Authorization Act mandated the establishment and use of a BEA: An organizational system designed to provide overarching governance across all business systems, functions, and activities for 15 End-to-End (E2E) business processes within the DoD. The entire BEA content is available on the BEA Website.  BEA compliance is one of the requirements in the DoD Investment Review Board (IRB) process, which certifies funding for Defense Business Systems that have an expected total cost of greater than $1 million. The IRB process is available on the IRB Website.  The Defense Enterprise Data Standards Office has significant interest in the BEA E2E business processes such as: “Order to Cash”, “Procure to Pay”, ”Plan to Stock”, and “Acquire to Retire”.  Given that all DoD trading partners must comply with BEA, it is imperative that the relevant BEA content is valid and interoperable with DLMS.  With over 60 published DLMS transactions (e.g., Requisition, Advance Shipment Notice), including business processes, information exchanges, business rules and data requirements; the DLMS continue to contribute to the BEA development process by incorporating the logistics business processes, business rules, and data requirements into the relevant E2E processes, Standard Financial Information Structure, and Procurement Data Standards. DLMS policies and procedures are also included in the BEA Laws, Regulations, and Policies and they are linked as constraints to the various business processes in the architecture models.  In addition to the BEA and DLMS compliance, the Components have additional processes, business rules and data for managing customers within their respective business systems.

C5-2	CHAPTER 5