2.152.3 Naming Data Element(s)/Object(s)

Manual Transmittal

November 22, 2019

Purpose

(1) This transmittal revised IRM 2.152.3 Data Engineering, Naming Data Element(s)/Object(s).

Material Changes

(1) Revised the entire document with updated Integrated Process Management (IPM) Process Description and Procedure Templates adding Internal Control Section aligned with agency-wide KISAM, WRMS & XML Change Management Sharepoint collaboration system.

(2) IRM 2.5.7 - Systems Development, Data Name Standards, data April 1, 2005, has been paired with and extended by IRM 2.152.3, as a Job Aide for Data Naming Best Practices for implementation and change request processes.

Effect on Other Documents

IRM 2.152.3 dated September 30, 2015 is superseded.

Audience

The Naming Data Elements Process Description is applicable to all Organizations responsible for requesting Naming Data Element(s)/Object(s) service

Effective Date

(11-22-2019)


Chief Information Officer

Program Scope and Objectives

  1. Overview - The objectives of this Naming Data Element(s)/Object(s) Process which is one of major process of Data Engineering is provide a set of related activities that accomplish a common goal of Naming Data Element(s)/Object(s). 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.

  2. Purpose - This IRM contains procedural steps for Naming Data Element(s)/Object(s) Process within IRS.

  3. Audience - This process description is applicable to all projects following the Enterprise Life Cycle (ELC) and customers who request data management services through the new Change Management KISAM system, or the OnLine 5081 Service.

  4. Policy Owner - The Chief Information Officer is responsible for overseeing all aspects of Naming Data Element(s)/Object(s) Process that operates IRS agency-wide Naming Data Element(s)/Object(s) Process.

  5. Program Owner -The Chief of Process Maturity Group under the Director of Enterprise Services, Solution Engineering Division is responsible for the administration, procedures, and updates related to the program IRM.

  6. Primary Stakeholders -The Chief of Data Engineering Group under Enterprise Services, Solution Engineering Division, and the Chief of Enterprise Data Warehouse under Application Development, Data Delivery Services Division are the Primary Stakeholders of this IRM has input in the procedures.

  7. Program Goals - This IRM provides the fundamental knowledge and procedural guidance for employees who request the Naming Data Element(s)/Object(s) Services from Data Engineering Group. By following the processes and procedures of this IRM, employees will achieve a given purpose of data related projects.
    .

Background

  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 Element(s)/Object(s) 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 follows 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

Authority

  1. All proposed changes to this document must be submitted in writing, with supporting rationale, to the Chief, Enterprise Service, Solution Engineering, Process Maturity Group.

Roles and Responsibilities

  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.
     

    Name Description
    Data Engineering Group (DE) The Data Engineering Organization is responsible for establishing and enforcing Data Naming Standards.
    Change Initiator/Analyst (Project Office) The Change Initiator/Analyst(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.

Program Management and Review

  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 an element of governance over the process that provides alignment to business vision, mission and goals.

    Process Management  
    Statement: The Naming Data Element(s)/Object(s) 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 Element(s)/Object(s) process will not be successful.
    Process:  
    Statement: Modifications to the Naming Data Element(s)/Object(s) 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, customization and use. 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:
    [Identify and list the technology and/or tools used in process].
    • [Enter text]

    Rationale: Technology and tools should be used to augment the process capabilities, not become an end themselves.

Program 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.
     

    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 Enterprise Data Standards and Guidelines (EDSG), General Enterprise Naming and Definition Standards and Guidelines, Data Model Class and Attribute Standards and Guidelines..
    Security Policies Infrastructure Executive Steering Committee (IESC) s 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 Change Management Program Management Office (PMO).
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.

  2. Management will regularly set targets for process performance, gather quantifiable data related to different functions of the Naming Data Element(s)/Object(s) 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.

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 Element(s)/Object(s) Process owner.
    [Enter tailoring guideline instructions].

Terms/Definitions/Acronyms

  1. Terms/Definitions/Acronyms

Terms and Definitions
  1. Terms and Definitions
     

    Term Definition
    Data Engineering Enterprise Services, Solution Engineering Division, Data Engineering Branch 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(s)
    (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)

    Data Object(s)
    (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) https://team.ds.irsnet.gov/sites/soleng/de/da-edsg/Shared%20Documents/Enterprise_Data_Standards_Guidance_EDSG.docx?web=1are 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).
    KISAM Knowledge Incident/Problem Service Asset Management Systemhttps://selfservice.web.irs.gov/webtier-9.52/ess.do
    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.
    RACI The RACI model is based on the principle that people act in one of four ways when executing a task. It accounts for the fact that more than one role may be active in performing a specific task while clearly defining specific responsibilities for that role. While many roles may be involved in a task only one is Accountable for the results. The actions are: “R” Responsible for the action (may do the task) “A” Accountable for the action (including approval) :C” Required to be Consulted on the action “I” Required to be Informed of the action. If a task does not have an Accountable role indicated then the Responsible role is assumed to be accountable for the task.
    WRMS The Work Request Management System is an ITIL-based COTS product for registering and managing demand requests for IT products and services.
Acronyms
  1. Acronyms

    [Identify and list the acronyms and definitions identified in this document. See example below].

    Acronyms Description
    EDSG Enterprise Data Standards and Guidelines
    KISAM Knowledge Incident/Problem Service Asset Management System
    MDD Metadata Dictionary
    RACI Responsible, Accountable, Consulted and Informed
    WRMS Work Request Management System

Related Resources

  1. Change Management KISAM & RFC Standard Data Model, and Metadata Dictionary (MDD and XML Registry)

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 Doorit.engineering.customer.support@irs.gov

    • IT Engineering XML Change Managementit.eng.xml.cm@irs.gov

Process Workflow

  1. A process 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 Element(s)/Object(s) 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(s)
    (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
    Data Engineering Group
    Data Element(s)
    (Type: Technical)
    A data asset that is either Unnamed or goes by a non-standard Named. Data Element(s) (Technical) which needs to be developed (if Unnamed) or changed (if non-standard) Project Office
    Data Engineering Group
    MDD - Metadata Dictionary on iMETAis Database(s)/Data Store(s) Data Engineering Group
    XML Registry IXCC Integrated XML Competency Center Database(s)/Data Store(s) Data Engineering Group
    EDSG Enterprise Data Standard Guidelines (IT PAL Process Guidelines) Data Engineering Group

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.
     

    Name Description Recipient
    Standard Data Object(s)
    (Type: Business)
    Standard Data Object(s) Name (Business) Reused or New Business Object Names (Term) Change Initiator/Analyst (Project Office), Data Engineering Group
    Standard Data Element(s)
    (Type: Technical)
    Standard Data Element(s) Name Reused or New Technical Data Element(s) (Implementation, eg. rdbms, column name; xml tag) Change Initiator/Analyst (Project Office), Data Engineering Group

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. Activities are measurable in terms of efficiency and effectiveness. Identify the activities in the process and provide a brief description. The activities must correspond with the high-level process flow diagram above.
     

    ID Name Description
    Step1.0 Identify Data Element(s)/Object(s) to be named Project Office Interfaces with external Develop a Standard Data Model before executing the Naming Data Element(s)Object(s) process, and Metadata Dictionary, then then identifies the Data Element(s)/Object(s) to be named.
    Step2.0 Check MDD and/or XML Registry for re-usable Data Element(s)/Object(s) 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).
    Step3.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).
    Step4.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)/Object(s)(Business) following EDSG Standards. Send new Data Element(s)/Object(s) and definition to MDD and DE as a proposal for approval.
    Step5.0 Approve Naming Data Element(s)/Object(s) New Data Element(s) and renamed Data Elements must be approved by Data Engineering Group to implement. Send proposed Data Element(s)/Objects names to Data Engineering Group for approval. Relational Database requires Data Engineering 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.

Procedure

  1. Procedure

Step1.0: Identify Data Element(s)/Object(s) to be named
  1. 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.

    ID Task Name and Description Role RACI Duties
    Task1.1 Identify Data Element(s)/Object(s) to be named


    This task is to identify the Data Element(s)/Object(s) with external predefined process of Develop a Standard Data Model, and Metadata Dictionary
    Change Initiator/Analyst (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.
    Task1.2 Discover new or incorrectly named Data Element(s)/Object(s)


    This task discovers if the Data Element(s)/Object(s) either new or incorrectly
    Change Initiator/Analyst (Project Office) R The Project Office is responsible for discovering new or incorrectly named Data Element(s)/Object(s).

     

Cross-Functional Flow Diagram
  1. Identify Data Element(s)/Object(s) to be named Cross-Functional Flow Diagram

    Figure 2.152.3-2

    This is an Image: 67565002.gif
     

    Please click here for the text description of the image.

Step2.0: Check MDD and/or XML Registry for reusable Data Element(s)/Object(s)
  1. 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).

    ID Task Name and Description Role RACI Duties
    Task2.1 Check MDD and/or XML Registry for reusable Data Element(s)/Object(s)


    This task is to search Metadata Dictionary (MDD) and/or XML Registry (IXCC) to discover standard data elements name(s) and definition(s) that match the project’s data requirement
    Change Initiator/Analyst (Project Office) R 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)
    Task2.2 Search MDD or XML Registry using keywords


    This task is to search definition in MDD or XML Registry
    Change Initiator/Analyst (Project Office) R The Project Office is responsible for using keywords to search definition in MDD or XML Registry
    Task2.3 Ensure that the definition for Data Elements/Object(s) matched the definition in MDD or XML registry


    This task is to ensure the definition matches the project requirement(s)
    Change Initiator/Analyst (Project Office) R The Project Office is responsible for ensuring the definition matches the project requirement(s)
    Task2.4 If Data Element(s)/Object(s) exists/exist and definition matched, go to Step 3.0 -reuse Data Element(s)/Object(s); below; otherwise, if definition not matched, or new Data Element(s) go to Step 4.0 - create new Data Element(s) (either Business or Technical) below


    This task is to ensure if definition matched or not matched
    Change Initiator/Analyst (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)
Cross-Functional Flow Diagram
  1. Check MDD and/or XML Registry for reusable Data Element(s)/Object(s) Cross-Functional Flow Diagram

    Figure 2.152.3-3

    This is an Image: 67565003.gif
     

    Please click here for the text description of the image.

Step3.0: Reuse Data Element(s)/Object(s)
  1. 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). .

    ID Task Name and Description Role RACI Duties
    Task3.1 Reuse Data Element(s)/Object(s)


    This task is to reuse current existing Data Element(s)/Object(s) if definition matched,
    Change Initiator/Analyst (Project Office) R If the Data Element(s)/Object(s) exists/exist and the Technical/Business definition matches what is required, Project Office re-use the existing Data Element(s)/Object(s)
    Task3.2 Reuse the existing Data Element(s)/Object(s)


    This task is to re-use current existing Data Element(s)/Object(s)
    Change Initiator/Analyst (Project Office) R Project Office re-use existing matched Data Element(s)/Object(s)
      End Naming Data Element(s)/Object(s) Process Change Initiator/Analyst (Project Office) R End Process
Cross-Functional Flow Diagram
  1. Reuse Data Element(s)/Object(s) Cross-Functional Flow Diagram

    Figure 2.152.3-4

    This is an Image: 67565004.gif
     

    Please click here for the text description of the image.

Step4.0 Create new Data Element/Objects (Technical or Business)
  1. 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 exist or exist 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).

    ID Task Name and Description Role RACI Duties
    Task4.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) for approval when the data cannot be identified by examples from EDSG




    This task is to establish data name standards
    Data Engineering Group R Data Engineering Group establishes Agency-Wide Data Name Standards.
    Task4.2 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.




    This task is to write a description of the entry
    Data Engineering Group R Data Engineering Group writes a description of the entity.
    Task4.3 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.



    This task is to eliminate the nonessential words from the description.
    Data Engineering Group R Data Engineering Group is to eliminate the nonessential words from the description.
    Task4.4 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.




    This task is to arrange the words in a meaningful way
    Data Engineering Group R Data Engineering Group is to arranging words in a meaningful order.
    Task4.5 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.




    This task is to establish standard for the abbreviations and acronyms
    Data Engineering Group R Data Engineering Group maintains Standards Abbreviations and Acronyms in IT PAL.
    Task4.6 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


    This task is to establish how to insert the appropriate special character between the remaining words and required acronyms.
    Data Engineering Group R Data Engineering Group establishes the rule on how to insert the appropriate special character between the remaining words and required acronyms.
    Task4.7 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
    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




    This task is to substitute approved abbreviations or accepted acronyms, and store all the new naming data element(s)/object(s) into ‘All Data Naming Standards and Guidelines’ Database.
    Data Engineering Group R Data Engineering Group establishes the rule on how to substitute approved abbreviations or accepted acronyms.
    Task4.8 Use EDSG convention


    This task is to use EDSG convention to create new data element(s)/object(s)
    Change Initiator/Analyst (Project Office) R Change Initiator/Analyst (Project Office) uses EDSG convention to create new data element(s)/object(s)
    Task4.9 Use General Enterprise Naming and Definition Standards and Guidelines


    This task is to follow General Enterprise Naming and Definition Standards and Guidelines to create data element(s)/object(s)
    Change Initiator/Analyst (Project Office) R Change Initiator/Analyst (Project Office) follows General Standards and Guidelines to create data element(s)/object(s).
    Task4.10 Use Data Model Class and Attribute Standards and Guidelines


    This task is to use Data Model Class and Attribute Standards and Guidelines to create new data element(s)/object(s)
    Change Initiator/Analyst (Project Office) R Change Initiator/Analyst (Project Office) follows Data Model Class and Attribute Standards and Guidelines to create data element(s).
      If creates Business Data Element(s), go to Task4.12, else If creates Technical Data Element(s) go to Task4.13 Change Initiator/Analyst (Project Office) R Change Initiator/Analyst (Project Office) determines if it is a new Business Object(s) or it is a new Technical Element(s)
    Task4.11 Authorized/Allowed Acronyms in Business Data Asset names


    The purpose of this task is to create Naming Business Object(s), then go to step Task4.16‘Approve Naming Data Element(s)/Object(s)
    Change Initiator/Analyst (Project Office) R Change Initiator/Analyst (Project Office) creates Business Object(s)
    Task4.12 Use Data Modeling Standards (relational database) Guidelines


    The purpose of this task is to use Data Modeling Standards to create Naming Technical Element(s)
    Change Initiator/Analyst (Project Office) R Change Initiator/Analyst (Project Office) creates Technical Element(s)
    Task4.13 Use Special Tools and Techniques (including Extensible Markup Language (XML))


    The purpose of this task is to use Special Tools and Techniques to create Naming Technical Element(s)
    Change Initiator/Analyst (Project Office) R Change Initiator/Analyst (Project Office) creates Technical Element(s)
    Task4.14 Authorized abbreviations and acronyms for Physical Data Model Class, XML, and Attribute Names


    The purpose of this task is to follow authorized abbreviations and acronyms for physical Data Model Class, XML, and Attribute Names. then go to next step Approve Naming Data Element(s)/Object(s)
    Change Initiator/Analyst (Project Office) R Change Initiator/Analyst (Project Office) follows authorized abbreviations and acronyms for Physical Data Model Class, XML, and Attribute Names
    Task4.15 Business Subject Master Expert (SME/Program Lead/Project Office/Developer/Data Steward Create a CR for Data Assset Name Change.ye (CR)https://kisamservice.web.irs.gov/webtier-9.52/index.do
    • Category:Norman

    • Subcategory:Software - Development

    • Initiating Service:XML Data Element

    • RFC Type: XML Data Element

    • Assignment Group: DATA ENGINEERING UNSTRUCTURED DATA PRACTICE SERVICES

    • Reason for Change: Business Requirement

    • Affected Service: XML Library – IRS COMMON

    • Save created Change Request


    (2): WRMS Change RequestDATA CR that requires ES:Solution Engineering Service & Support.http://wrms.web.irs.gov/itg/dashboard/app/portal/PageView.jsp
    • Requested Service: Enterprise Services *IT Engineering Customer Support or Solutions Engineering*IT Engineering XML ChangeManagement

    • Requested Service Sub-category: Solutions Engineering Data Engineering


    (3): XML Sharepoint Collaboration site - supporting documentshttps://team.ds.irsnet.gov/sites/soleng/de/udp/XML/ixcccm/SitePages/Home.aspx
    • All Projects: XML Component Change TemplateXMLCR_ProjectName_mmddyyyy.xlsx Template for XML component /element creation or changes.

    • All Projects: XML Message Structure change TemplateXMLCR_Message_ProjectName_SeqNum_mmddyyyy.xlsx Template for XML message schema creation or update existing message.

    • MeF & IRIS: XML RLO Change or Updated TemplateTYyyyy XML RLO form FormNumber as of mmddyyyy.xlsx For new RLO creation or update existing.





    The purpose of this task is Change Initiator/Analyst (Project Office) creates CR or WR for new Naming Data Element(s)/Object(s)
    Change Initiator/Analyst (Project Office) R Change Initiator/Analyst (Project Office) Creates CR or WR through KISAM, WRM, and Data XML SharePoint Site
    Task4.16 Submit CR or WR to Data Engineering EDSG or Data Engineering IXCC (Integrated XML Competency Center)


    The purpose of this task is Change Initiator/Analyst (Project Office) submits CR or WR for new Naming Data Element(s)/Object(s)
    Change Initiator/Analyst (Project Office) R Change Initiator/Analyst (Project Office) submits CR or WRj

    .

Cross-Functional Flow Diagram
  1. Create new Data Element/Objects (Technical or Business) Cross-Functional Flow Diagram

    Figure 2.152.3-5

    This is an Image: 67565005.gif
     

    Please click here for the text description of the image.

Step5.0 Approves Naming Data Element(s)/Object(s)
  1. New Data Element(s) and renamed Data Elements must be approved by Data Engineering Group prior to implementation. Send proposed Data Element(s)/Objects names to Data Engineering Group for approval. Relational Database requires Data Engineering Group Change Request. XML requires an IXCC (XML) Change Request. Data Engineering Group will disposition Data Model /data element CRs and IXCC CB will disposition XML CRs. .

    ID Task Name and Description Role RACI Duties
    Task5.1 Data Engineering Group EDSG or Data Engineering Group IXCC XML Change Board dispositions CR

    The purpose of this task is to disposition Change Request
    Data Engineering Group R Data Engineering Group dispositions hange Request
    Task5.2 Approve new Naming Data Element(s) or Object(s) and formally document approved CR

    The purpose of this task is to approve new Naming Data Element(s) or Object(s)
    Data Engineering Group R Data Engineering Group approves new Naming Data Element(s) or Object(s)
    Task5.3 Approved Data Asset/Definitions are instantiated & published to MDD as a ‘Standard Data

    The purpose of this task is that Data Engineering Group published new Data Element(s)/Object(s) to MDD
    Data Engineering Group R Data Engineering Group approves and publish new Data Element(s)/Object(s) to MDD as a ‘Standard Data’.
Cross-Functional Flow Diagram
  1. Approves Naming Data Element(s)/Object(s) Cross-Functional Flow Diagram

    Figure 2.152.3-6

    This is an Image: 67565006.gif
     

    Please click here for the text description of the image.