2.152.3 Naming Data Elements

Manual Transmittal

September 30, 2015

Purpose

(1) This new transmittal IRM 2.152.3 Naming Data Element(s) provides Naming Data Elements Process Description (PD) to be posted on the Information Technology Process Asset Library (IT PAL) and to be published in the Internal Revenue Manual (IRM).

Material Changes

(1) This new transmittal will cover both Business and Technical Naming Data Elements/Data Objects, and will replace the IRM 2.5.7 Data Names Standards.

Effect on Other Documents

None

Audience

The Naming Data Elements Process Description is applicable to all Organizations responsible for Naming Data Elements/Objects

Effective Date

(09-30-2015)

Terence V. Milholland
Chief Technology Officer

Process and Procedure

  1. Naming Data Elements

Introduction

  1. This document describes the formal process for implementing the requirements of the Naming Data Elements. It provides an operational definition of the major components of the process and how to perform each step in the process. This document also describes the logical arrangements of steps that are essential to successfully completing the process and achieving the desirable outcome.

Administration
  1. All proposed changes to this document should be submitted in writing, with supporting rationale, to the Chief, Solution Engineering Process Maturity, owner of this process description, and be pursued via the Integrated Process Management (IPM) process to clearly define interfaces, roles, and responsibilities, and coordinate participation and collaboration between stakeholders.

Overview

  1. A process is defined as “A set of related activities that accomplish a common goal”. The process definition laid out in this document further breaks down these Activities into Tasks, each of which have a complete set of attributes defined such as data and tool specifications and the role(s) responsible for executing the tasks. The document also includes process goal and objectives, metrics, role definitions, policies and other process related attributes.

Process Description
  1. Naming Data Elements Process is the process responsible for ensuring that the Enterprise Data Standards and Guidelines (EDSG), General Enterprise Naming and Definition Standards and Guidelines, Data Model Class and Attribute Standards and Guidelines. Special Tools and Techniques are followed when creating Data Elements (Technical) and Data Objects (Business) ensuring data naming standardization.

Goal
  1. The process goal describes a specific purpose or achievement toward which the efforts of the process are directed. Each process has a specific focus and when combined with the other processes, forms a comprehensive framework for delivering and managing services.

    • To support the business goal for data naming standardization by ensuring that the all Data Naming Standards and Guidelines are followed service wide.

Objectives
  1. Process objectives describe material outcomes that are produced or achieved by the process. The following is a list of objectives for this process:

    • Standardized data names facilitate data sharing, data consistency, and communication between organizational areas across the enterprise.

    • Standardized data names also assist the data administration effort, by making it possible to eliminate data redundancies and inconsistencies.

  2. The Project and Data Engineering develop a data model to establish the data set scope and begin to identify required data objects.
    The Enterprise Logical Data Model (ELDM) is the framework for developing a standard data model.

    Starting From a data model that aligns with the ELDM the data model evolves by applying the EDSG (Enterprise Data Standards and Guidance) and repeatable methodologies to in the assignment of data names. The development of data names follow a methodology that includes class words, and incorporate standard abbreviations and acronyms into each of the column names to achieve a standard physical design and drive standardization and reUse.

Workflow

  1. A workflow consists of Activities and Tasks, Inputs and Outputs, Roles, and Flow Diagrams. It describes the tasks, procedural steps, organizations or people involved, required input and output information, and tools needed for each step of the process.

Main Process Diagram
  1. Naming Data Elements Process Flow Diagram

    Figure 2.152.3-1

    This is an Image: 67565001.gif

    Please click here for the text description of the image.

Inputs
  1. Process inputs are used as triggers to initiate the process and to produce the desired outputs. Users, stakeholders or other processes provide inputs. The following is a list of inputs for this process:

    Name Description Supplier
    Data Object
    (type: Business)
    A data asset that is either Unnamed or goes by a non-standard Named. Data Object(s) (Business) which needs to be developed (if Unnamed) or changed (if non-standard) Project Office/DE
    Data Element(s)
    (type: Technicall)
    A data asset that is either Unnamed or goes by a non-standard Named. Data Elememt(s) (Technical) which needs to be developed (if Unnamed) or changed (if non-standard) Project Office/DE
    MDD - Metadata Dictionary on iMETAis Database(s)/Data Store(s) DE/MA
    XML Registry
    Ixcc – Integrated XML Competency Center
    Database(s)/Data Store(s) DE
    EDSG Enterprise Data Standard Guidelines (IT PAL Process Guidelines) DE/MA
Outputs
  1. Each process produces tangible outputs. These outputs can take the form of products or data and can be delivered to a user or stakeholder, or, they can be used as inputs to other processes. Outputs are measurable in terms of quantity and quality. The following is a list of outputs for this process:

    Name Description Recipient
    Standard Data Object Name (Business) Standard Data Object(s) Name (Business) Reused or New Business Object Names (Term) Project/Office/DE/MA
    Standard Data Element(s) Name (Technical) Standard Data Element(s) Name Reused or New Technical Data Element(s) (Implementation, eg. rdbms, column name; xml tag) Project/Office/DE/MA
Activities
  1. An activity is a major unit of work to be completed in achieving the objectives of the process. A process consists of a sequence of related activities that transforms inputs into outputs and performed by the roles defined in the process. Identify the activities in the process and provide a brief description. The activities must correspond with the high-level process flow diagram above. The following is a list of activities for this process:

    ID Name Description
    External Process Develop a Standard Data Model Interface with external Develop a Standard Data Model before executing the Naming Data Element(s)Object(s) process
    1.0 Identify Data Element(s)/Object(s) to be named The Project identifies the Data Element(s)/Object(s) to be named
    2.0 Check MDD and/or XML Registry for re-usable Data Element(s)/Object(s) The Project Office is responsible for searching MDD and/or XML Registry (IXCC) to discover standard
    data elements name(s) and definition(s) that match the project’s data requirement
    The Project reviews the Metadata Dictionary and XML Registry (IXCC) to see if the Data Element already exists and can be re-used (Business and Technical representations)
    3.0 Reuse Data Element(s)/Object(s) If the Data Element(s)/Object(s) exists/exist and the Business definition matches what is required, re-use the existing Data Element(s)/Object(s)
    4.0 Create new Data Element/Objects (Business or Technical) If the Data Element(s)/Object(s) doesn’t/don’t exists/exist or exists/exist with a different definition or exists with a different definition, , create a new Data Element(s)[Technical] /Objects[Business] following EDSG Standards. Send new Data Element(s)/Object(s) and definition to MDD and DE as a proposal for approval.
    Submit required Naming and Design Rules Change Requests to appropriate Change Boards: 1) MA DataXchange & 2) IXCC (XML) Change Board (CB).
    5.0 Approve Naming Data Element(s)/Object(s) New Data Element(s) and renamed Data Elements must be approved by DE and MA prior to implementation.
    Send proposed Data Element(s)/Objects names to DE/MA for approval. Relational Database requires DE/MDD Change Request. XML requires an IXCC (XML) Change Request. Data Engineering will disposition Data Model /data element CRs and IXCC CB will disposition XML CRs.
Roles
  1. Each process defines at least one role. Each role is assigned to perform specific tasks within the process. The responsibilities of a role are confined to the specific process. They do not imply any functional standing within the hierarchy of an organization. For example, the process manager role does not imply the role is associated with or fulfilled by someone with functional management responsibilities within the organization. Within a specific process, there can be more than one individual associated with a specific role. Additionally, a single individual can assume more than one role within the process although typically not at the same time. The following roles have been identified for this process:

    Name Description
    DE The Data Engineering Organization is responsible for establishing enforcing Data Naming Standards
    MA The Metadata Administration Section is responsible for publishing the MDD and providing service and support Enterprise and Project Office(s) in the delivery of standard metadata. .
    Project Office The Project Office is responsible for proposing new Data Elements following EDSG Naming and Design Rules (NDR) and checking the Metadata Dictionary to see if the Data Element already exists and can be re-used or if a new Data Element needs to be created.
Procedure
  1. Identify the Tasks and Roles for each Activity

Naming Data Elements Process Procedure
  1. The tasks and roles for each activity are the following for this process are the following:

    ID Task Name and Description Role RACI Duties
    External Process Develop a Standard Data Model Interface with external Develop a Standard Data Model before executing the Naming Data Element(s)Object(s) process.
    The Project and Data Engineering develop a data model to establish the data set scope and begin to identify required data objects.
    Step 1.0 Identify Data Element(s)/Object(s) to be named Project Office R The Project Office is responsible for identifying the new Data Element(s)/Object(s) to be created or existing Data Element(s) that need to be renamed.
    Step 1.1 Discover new or incorrectly named Data Element(s)/Object(s) Project Office R The Project Office is responsible for discovering new or incorrectly named Data Element(s)/Object(s).
    Step 2.0 Check MDD and/or XML Registry for reusable Data Element(s)/Object(s) Project Office R The Project Office is responsible for searching MDD and/or XML Registry (IXCC) to discover standard
    data elements name(s) and definition(s) that match the project’s data requirement
    The Project reviews the Metadata Dictionary and XML Registry (IXCC) to see if the Data Element already exists and can be re-used (Business and Technical representations)
    Step 2.1 Search MDD or XML Registry using keywords Project Office R The Project Office is responsible for using keywords to search definition in MDD or XML Registry
    Step 2.2 Ensure that the definition for Data Elements/Object(s) matched the definition in MDD or XML registry Project Office R The Project Office is responsible for ensuring the definition matches the project requirement(s)
    If Data Element(s)/Object(s) exists/exist and definition matched, go to Step 3.0 -reuse Data Element(s)/Object(s); below;
    if definition matched, or new Data Element(s) go to Step 4.0 - create new Data Element(s) (either Business or Technical) below
    Project Office R The Project Office determines if data element(s)/object(s) can be reused or need to create new data element(s)/object(s)
    Step 3.0 Reuse Data Element(s)/Object(s) Project Office R If the Data Element(s)/Object(s) exists/exist and the Technical/Business definition matches what is required, re-use the existing Data Element(s)/Object(s)
    Step 3.1 Reuse the existing Data Element(s)/Object(s) Project Office R Reuse the existing and definitions of matched Data Element(s)/Object(s)
    End Naming Data Element(s)/Object(s) Process Project Office R End Process
    Step 4.0 Creates New Data Element(s)/Objects (either Business or Technical) Data Engineering Group
    Project Office
    R
    R
    Creates New Data Element(s)/Objects following EDSG standards, send new Data Element(s)/Objects to MDD. (submit required Naming and Design Rule Change Requests).
    If the Data Element(s)/Object(s) doesn’t/don’t exists/exist or exists/exist with a different definition or exists with a different definition, , create a new Data Element(s)[Technical] /Objects[Business] following EDSG Standards. Send new Data Element(s)/Object(s) and definition to MDD and DE as a proposal for approval.
    Submit required Naming and Design Rules Change Requests to appropriate Change Boards: 1) MA DataXchange & 2) IXCC (XML) Change Board (CB).
    Step 4.1 Establish Data Name Standards
    • Only alphabetic (A-Z), numeric (0-9), and special characters (e.g., hyphen, colon, underscore) which are appropriate to the language being used are allowed in a name. No blanks are permitted.

    • The first character of the data name must be alphabetic (A-Z).

    • Data names may not start with verbs

    • The maximum length of a name (including special characters) is 30 characters.

    • Each name must be unique

    • Each name must be clear and accurate to reflect a condensed version of the data description.

    • Abbreviate only when it is necessary to reduce a name to 30 characters or less. Effective with this transmittal, names in COBOL applications will not contain abbreviations for words of four characters or less.

    • Each name must contain a class word. A class word specifies the nature of the data and must be the right-most word in the name (e.g., TAXPAYER-BIRTH-DATE). The EDSG (Enterprise Data Standards and Guidelines) provides a list of Standard class words. Other class words must be submitted to the Data Engineering (DE) and Metadata Administration Section (ME) for approval when the data cannot be identified by examples from Enterprise Standards and Guidelines (EDSG).

    Data Engineering Group R Establish Agency-Wide Data Name Standards
    Step 4.1.1 Write a description of the entity
    • Write a sentence or a paragraph containing a full but concise description of the entity (user, system, run, module, report, form, file, record, group, data element, schema, subschema, area, set) explaining what it is. This description should be retained as a part of the data dictionary entry.

    • A close relationship must exist between a data name and its description; one should reflect the other. A general or broad description requires a general name.

    • Do not use the source or destination of the entity. Avoid: This entry comes from previous Run to next Run (for instance from Run 123 to Run 456.

    • Do not specify the processing done on the entity, Avoid: This amount is the result of price times quantity.

    • Attach system/function names or form numbers to data items only when the description limits its use to a particular function. For example: EXAMINATION-CASE-START-DATE and COLLECTION-CASE-START-DATE could be uses with system names attached because their descriptions would be basically different.

    Data Engineering Group R Describing an Entity
    Step 4.1.2 Eliminate the nonessential words from the description
    • Eliminate those words in the description which are not essential to the meaning. Note that these words are deleted only for the purpose of deriving a name; the full description remains intact in the data dictionary entry.

    • Unnecessary words usually include articles, conjunctions, prepositions, and some modifiers. However, in some cases these types of words may be necessary to the meaning.

    Data Engineering Group R Arranging Words in a Meaningful Order
    Step 4.1.3 Arrange the remaining words in a meaningful order, with the class word to the right
    • Arrange the remaining words by placing the class word as the last word on the right of the name, and reorganizing the other words into a meaningful order. Some change in the form of a word may be necessary; that is a verb may be changed to a noun or adjective (for example: collect to collection or collected)

    • In some instance, a good description (as suggested above) will not result in an adequate name. If, after reworking the description, the resultant name is still unacceptable, then persons involved in name development must use their knowledge of the subject data in selecting key words for the name.

    Data Engineering Group R Arranging Words in a Meaningful Order
    Step 4.1.4 Always substitute required acronyms
    • Always use common IRS acronyms (required acronyms) for groups words in the name (e.g., IMF for Individual Master File, DLN for Document Locator Number). A list of these acronyms is included as IT PAL Standard Abbreviations and Acronyms List. (Note: Those items which are marked by two pound signs are required

    • Separate the remaining words and required acronyms with the appropriate special character.

    Data Engineering Group R Standards Abbreviations and Acronyms are maintained in IT PAL
    Step 4.1.5 Insert the appropriate special character between the remaining words and required acronyms. Potentially it has an Hyphen (-) or and underscore (_). For example: Spouse SSN - Potentially in your application you would have Spouse-SSN, whereas on a database you may have Spouse_SSN ,or Birth Dt - Potentially in your application you would have Birth-Dt, whereas on a database you may have Birth_Dt Data Engineering Group R Insert Special Character
    Step 4.1.6 Substitute approved abbreviations or accepted acronyms if the name is over 30 characters
    • Count the remaining alphanumeric characters and special characters,. Substitute accepted acronyms or abbreviations found on IT PAL Abbreviations and Acronyms until the name has 30 or fewer characters (including approved special characters).

    • When only the singular form of a word is givens as the abbreviation’s meaning, the plural of the word may be assumed acceptable and vice versa, if that form will make the name more meaningful. Similarly, tenses different from those listed in the meaning may be assumed acceptable without an addition to the approved abbreviation list. For example:

      1. On list: COLM Column INCR Increase

      2. May assume: COLMS Columns INCRD Increased

    • The list of standard abbreviations and acronyms are maintained in IT PAL Standard Abbreviations and Acronyms List

    • .

    Note:

    If there is no appropriate abbreviations on the approved list, use the following steps to develop an abbreviation.

    1. Eliminate vowels right to left to make the most meaningful abbreviations. Never delete the first letter of the word.

    2. Drop nonessential consonants. Use phonetic sounds to help select only those letters needed to understand the abbreviated word(s). For example: Block BLK Opening OPNG

    3. Use a shorter form of the word when the word is lengthy and the shorter form can be understood. For example: Function FUNC Geographical GEOG

    4. Do not abbreviate a word so as to cause confusion in meaning. For example: Use AUTH for Authority Not AUTHOR for Authority

    Data Engineering Group R Substituting Approved Abbreviations or Accepted Acronyms
    Step 4.2. Use EDSG convention Project Office R Use EDSG convention to create new data element(s
    Step 4.2.1 Use General Enterprise Naming and Definition Standards and Guidelines Project Office R Follows General Standards and Guidelines to create data element(s).
    Step 4.2.2 Use Data Model Class and Attribute Standards and Guidelines Project Office R Follows Data Model Class and Attribute Standards and Guidelines to create data element(s),
    If creates Business Data Element(s), go to Step 4.2.4;
    If creates Technical Data Element(s) go to 4.2.5 below
    Project Office R Determines if it is a Business or Technical data element(s).
    Step 4.2.3 Authorized/Allowed Acronyms in Business Data Asset names. Then, go to Step 4.2.8 below Project Office R Follows Business Data Asset names.
    Step 4.2.4 Use Data Modeling Standards (relational database) Guidelines Project Office R Follows relational Data Model Standards to create data element(s).
    Step 4.2.5 Use Special Tools and Techniques (including Extensible Markup Language (XML)) Project Office R Follows Special Tools and Techniques to create data element(s).
    Step 4.2.6 Authorized Abbreviations and Acronyms for Physical Data Model Class, XML, and Attribute Names Project Office R For Physical Data Model
    Step 4.2.7 Business Subject Master Expert (SME/Program Lead/Project Office/Developer/Data Steward creates a Data Asset Name/Definition Change Request (CR) Project Office R Creates CR
    Step 4.2.8 Submit CR to DE EDSG or DE IXCC (Integrated XML Competency Center) Project Office R Submits CR
    Step 5.0 Approves Naming Data Element(s)/Object(s) Data Engineering Group
    Metadata Administration Section
    A New Data Element(s) and renamed Data Elements must be approved by DE and MA prior to implementation.
    Send proposed Data Element(s)/Objects names to DE/MA for approval. Relational Database requires DE/MDD Change Request. XML requires an IXCC (XML) Change Request. Data Engineering will disposition Data Model /data element CRs and IXCC CB will disposition XML CRs.
    Step 5.1 DE EDSG or DE IXCC XML Change Board dispositions CR Data Engineering Group A Dispositions CR
    Step 5.2 Approve New Naming Data Element(s) and formally document approved CR Data Engineering Group A Approves and documents CR
    Step 5.3 Approved Data Asset/Definitions are instantiated & published to MDD as a ‘Standard Data Element(s) ‘ Data Engineering Group
    Metadata Administration Section
    Project Office
    R
    I
    C
    Instantiated & Published to MDD as a ‘Standard Data Element(s)’
    Data Engineering Group informs Metadata Administration Section that Approved Data Asset/Definitions are published to MDD
    Consume New Data Element(s)
Cross-Functional Flow Diagram
  1. Process Procedures Diagrams

    Figure 2.152.3-2

    This is an Image: 67565002.gif

    Please click here for the text description of the image.

    Figure 2.152.3-3

    This is an Image: 67565003.gif

    Please click here for the text description of the image.

    Figure 2.152.3-4

    This is an Image: 67565004.gif

    Please click here for the text description of the image.

    Figure 2.152.3-5

    This is an Image: 67565005.gif

    Please click here for the text description of the image.

    Figure 2.152.3-6

    This is an Image: 67565006.gif

    Please click here for the text description of the image.

Process Control

  1. Activities involved in ensuring a process is predictable, stable, and consistently operating at the target level of performance.

Controls
  1. Process controls represent the policies and guiding principles on how the process will operate. Controls provide direction over the operation of processes and define constraints or boundaries within which the process must operate. The process controls are the following:

    Name Description
    Policies Policies and criteria for standard names concentrate on standard abbreviations; the inclusion of class words to provide context and type and the degree of potential re-use of a component are the driving characteristics of a Data Elements attributes that are considered in the CMS process.
    Security Policies DOCS ESC is made up of representatives across IRS ACIO/BODs to provide democratic processes and transparency to business operating divisions across the Agency.
    Scope The scope of the Naming Process for Data Element includes standard naming conventions and their application across key implementations for interoperability.
    Change Management Policies Change Management Policies and procedures are managed by Data Engineering EDSG Change Board.
    Management Reports The ESDG standard Data Elements names; standard abbreviations; standard acronyms will be published annually on EA Framework and IRM. MDD may publish project-specific metadata on a more rapid release scheduled, but at least annually.
Metrics
  1. Metrics are used for the quantitative and periodic assessment of a process. They should be associated with targets that are set based on specific business objectives. Metrics provide information related to the goals and objectives of a process and are used to take corrective action when desired results are not being achieved and can be used to drive continual improvement of process effectiveness and efficiency.

    Management will regularly set targets for process performance, gather quantifiable data related to different functions of the Naming Data Elements process, and review that data in order to make informed decisions and take appropriate corrective action, if necessary. All Measurements will have a defined data dictionary, map to the organizational strategic goals, and be documented in a Process Measurement Plan. The Process Measurement Plan template is available in the IT PAL.

Policies
  1. Policies outline a set of plans or courses of action that are intended to influence and determine decisions or actions of a process. Policies provide a system of governance over the process that provides alignment to business vision, mission and goals.

    Process Management
    Statement: The Naming Data Elements process will have a single Process Owner and a separate Process Manager, responsible for implementation and ensuring adherence to the process. The process will be reviewed regularly to ensure that it continues to support the business requirements of the enterprise. The process will be designed and developed based on ROI to the business. Process metrics will be focused on providing relevant information as opposed to merely presenting raw data.
    People:
    Statement: Roles and responsibilities for the process must be clearly defined and appropriately staffed with people having the required skills and training. The mission, goals, scope and importance of the process must be clearly and regularly communicated by upper management to the staff and business customers of IT. All IT staff (direct and indirect users of the process) shall be trained at the appropriate level to enable them to support the process
    Rationale: It is imperative that people working in, supporting or interacting with the process in any manner understand what they are supposed to do. Without that understanding Naming Data Elements will not be successful.
    Process:
    Statement: Modifications to the Naming Data Elements process must be approved by the Process Owner. The design of the process must include appropriate interfaces with other processes to facilitate data sharing, escalation and workflow. The process must be capable of providing data to support real-time requirements as well as historical/trending data for overall process improvement initiatives. The process must be fully documented, published and accessible to the various stakeholders of the process. The process will be reviewed on a periodic basis in order to ensure it continues to support organizational goals and objectives (continuous improvement). The process must include Inputs, Outputs, Controls, Metrics, Activities, Tasks, Roles and Responsibilities, Tool and Data requirements along with documented process flows. The process will be kept straight forward, rational, and easy to understand.
    Rationale: The process must meet operational and business requirements.
    Technology and Tools:
    Statement: All tools selected must conform to the enterprise architectural standards and direction. Existing in-house tools and technology will be used wherever possible, new tools will only be entertained if they satisfy a business need that cannot be met by current in-house tools. The selection of supporting tools must be process driven and based on the requirements of the business. Selected tools must provide ease of deployment, customizing and use. The selected tools must support heterogeneous platforms. Automated workflow, notification and escalation will be deployed wherever possible to minimize delays, ensure consistency, reduce manual intervention and ensure appropriate parties are made aware of issues requiring their attention. The tools used by this process are the following
    • IBM InfoSphere Business Glossary (Metadata Dictionary (MDD)

    • Enterprise Data Standards and Guidelines (EDSG)

    • General Enterprise Naming and Definition Standards and Guidelines

    • Data Model Class and Attribute Standards and Guidelines

    • Data Modeling Standards (relational database) Guidelines

    • Special Tools and Techniques ( including Extensible Markup Language (XM)))

    • Authorized Abbreviations and Acronyms for Physical Data Model Class, XML, and Attribute Names

    Rationale: Technology and tools should be used to augment the process capabilities, not become an end themselves.
Tailoring Guidelines
  1. The tailoring guidelines identify the allowable variations of the IT organization’s standard process as needed for adjustments (adding, deleting, modifying) relative to specific operational or functional needs of another organization. Process tailoring is about roles and procedures, not the standard process or major activities defined in this process. All tailoring request, with supporting rationale, must be submitted in writing to and approved by the Naming Data Elements owner.

Training

  1. Process training involves training all stakeholders about key processes that are crucial for an organization to deliver business objectives. Training provides clarity to employees on a set of procedures that needs to be carried out as part of the process and the best possible way to do them. List below the training resources available for this process:

    • Training available upon request – Please contact Solution Engineering Front Door or Application Development Metadata Administration Section

Exhibits

  1. Acronyms and Glossary

Exhibit A: Acronyms
  1. Acronyms

    Acronyms Description
    DE Data Engineering
    EDSG Enterprise Data Standards and Guidelines
    IXCC XML Registry (Integrated XML Competency Center (IXCC))
    MA Metadata Administration Section
    MDD Metadata Dictionary
Exhibit B: Glossary
  1. Glossary

    Term Definition
    DE Data Engineering is responsible for Data Governance of Naming and Design Rules and implementation, Strategic Planning and Alignment, Quality Management, Architecture Management and Transparency Management.
    Data Element (Technical) Throughout this process specification, the term ‘data element’ is an atomic unit of data that has precise meaning or precise semantics and is implementable. ‘Data element’ refers to a data asset that has been identified and developed for data processing and is part of a technical implementation (eg. relational database column or XML tag).
    A data element has:
    • An identification such as a data element name

    • A clear data element definition

    • One or more representation terms

    • Optional enumerated values Code (metadata)

    Date Objects (Business) Throughout this process specification, the term ‘data object’ refers to the business representation of a data element. In other words, it is the alias to the data element. The data object has a precise meaning or precise semantics. The data object is not an implementable asset, but serves the business community of interest to identify the data asset.
    A data object has:
    • An identification label or name (‘term’)

    • A business definition

    • Optional enumerated values Code (metadata)

    EDSG Enterprise Data Standards and Guidelines (EDSG) are specific rules for achieving a standard IRS design pattern. EDSG is the framework for development and modification of the names, definitions and other metadata for classes, attributes, and data models. In addition to prescribing format, data standards also establish a required level for the correctness, consistency, and completeness of these Data Element(s)/Objects.
    Guidelines are recommendations and instructions for the successful implementation of enterprise data standards.
    Data standards and guidelines are followed any time a Data Element(s)/Object(s) is/are created or modified. Multiple data standards and guidelines apply at the same time for a particular Data Element(s)/Object(s).
    MA The Metadata Administration Section maintains and executes the processes for developing and maintaining the Metadata Dictionary (MDD)
    MDD
    iMETAis – integrated Metadata on IBM InfoSphere is a web based application that hosts the IRS Metadata Dictionary (MDD). The MDD defines the data object and the data element for the IRS standard data model and its member components.
    The primary goal of the MDD is to provide a single location to find standardized terms and their various attributes. The Metadata Dictionary is intended to easily and efficiently organize, identify, share, reuse and correlate data that enables the business to consume information and maximize the value to the agency.