2.152.2 Data Management Process Description

Manual Transmittal

July 31, 2015

Purpose

(1) This transmits revised IRM Part 2 Chapter 152 Data Engineering, Section 2 Data Management with updated Process Description and Procedure Templates.

Material Changes

(1) Revised the entire document with updated IPM Process Description and Procedure Templates.

Effect on Other Documents

IRM 2.152.2, dated September 22, 2014, is superseded.

Audience

This process description is applicable to all projects following the Enterprise Life Cycle (ELC) and customers who request data management services through the Change/Configuration Management/Enterprise Change Management System (ECMS), the Work Request Management System (WRMS), or the OnLine 5081 Service.

Effective Date

(07-31-2015)

Terence V. Milholland
Chief Technology Officer
Information Technology

Process and Procedure

  1. [Enter Process Name]

Introduction

  1. This document describes the formal process for implementing the requirements of the Data Management process. 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 it 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.

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. The mission of Data Management is to define an enterprise-wide data environment to more easily and efficiently organize, identify, share, reuse, and correlate data that enables the business to consume information and maximize the value to the agency. This Data Management Process Description describes what happens within the process and provides an operational definition of the major components of the process. This description specifies in a complete, precise, and verifiable manner, the requirements, design, and behavior characteristics of Data Management process. The process description (PD) is a documented expression of a set of activities performed to achieve a given purpose. Tailoring of this process in order to meet the individual needs of each project is covered in the Tailoring Guidelines section of this document. For the purpose of this document, roles are provided to describe a set of responsibilities for performing a particular set of related activities. Roles and/or responsibilities should fit your business terminology.

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 achieve a given purpose and states the guidelines that all projects should follow regarding the Data Management process.

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:

    • Provide a standardized and institutionalized Data Management guidelines within IRS.

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. Data Management Process Diagram]

    Figure 2.152.2-1

    This is an Image: 59989001.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
    Change Request/Work Request A Change Request or Work Request for the service of 5 C’s from Data Management Process Change Initiator/Originator
    Disposition Change Request/Work Request High Authority would determine approve or deny the request High Authority/DOCE ESC
    On-Line 5081 Request A request for accessing the Data System Change Initiator/Originator
    Baseline and Milestone Updated for Primary Design The following documents should be started (baseline) or updated at the corresponding Enterprise Life Cycle (ELC) Phase & Milestone:
    • E300 and E53

    • Project Tailoring Plan

    • Project Management Plan

    • Business System Requirement (BSR) (Logical Data Model/Business Metadata)

    Solution Engineering Data Engineering Practice Group
    Baseline and Milestone Updated for Detailed Design Baseline and Milestone Updated for Detailed Design The following documents should be started (baseline) or updated at the corresponding Enterprise Life Cycle (ELC) Phase & Milestone:
    • DSR (Physical Data Model/Technical Metadata)

    • ICD (Data Movement Metadata)

    Solution Engineering Data Engineering Practice 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. The following is a list of outputs for this process:

    Name Description Recipient
    The completed disposition Data Collection Change Request (CR). High Authority determines if the Change Request/Work Request is denied or approve Solution Engineering Data Process Group
    The defined scope for the Data Collection Change Request as related to the Enterprise Logical Data Model, and Standard Meta Model (Business Taxonomy and Technical Metadata) are defined (BSR, DSR,ICD) Solution Engineering Data Practice Group would determine that Change Request/Work Request from Project Office(s) is within the Data Management scope Change Initiator/Originator
    Data Platforms Solution Engineering Data Practice Group provides appropriate Data Platform to Project Office(s), such as: Enterprise Business Intelligence Platform (EBIP); Enterprise Informatica Platform (EIP) Change Initiator/Originator
    Required Reports Solution Engineering Data Practice Group provides all kinds of request reports from Project Office(s) Change Initiator/Originator
    Baseline and Milestone Updated for Primary Design A completed Data Management design with the applied version controlled.
    • E300 and E53

    • Project Tailoring Plan

    • Project Management Plan

    • Business System Requirement (BSR)

      1. Entities & Attributes (Logical Data Model)

      2. Business Metadata (Business Taxonomy)

    Change Initiator/Originator
    Baseline and Milestone Updated for Detailed Design A completed Data Management design with the applied version controlled.
    • Design Specification Report (DSR) (Physical Data Model/Technical Metadata)

      1. Tables & Columns (Physical Data Model)

      2. Technical Metadata (Technical Taxonomy)

    • Interface Control Document (ICD) (Data Movement Metadata)

      1. Schema; Service; Message Interchange Metadata (XML Taxonomy)

    Change Initiator/Originator
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
    Step 1 Data Collection To collect data that exist in databases (structured) and that exist outside databases (unstructured) from across the agency and external sources.
    • Change Initiator/Originator (Project Office/Change Requestor/User) creates and submits Data Collection Change Request (CR) or Work Request (WR).

    • Solution Engineering Data Practice Group (Engineer/Analyst) determines the scope of Change Request or Work Request.

    • Solution Engineering Data Practice Group (Engineer/Analyst) determines the data source, and evaluates the Change Request against the IRS data strategy.

    • Higher Authority/DOCS ESC dispositions Data Collect Change Request (CR) if that required funding.

    • Change Initiator/Originator (Project Office/Change Requestor/User) enters Enterprise Life Cycle (ELC).

    • Change Initiator/Originator (Project Office/Change Requestor/User) submits ELC artifacts.

    • Solution Engineering Data Practice Group (Engineer/Analyst) reviews Data Collection processing outputs.

    • Solution Engineering Data Practice Group (Engineer/Analyst) aligns Project data model with Enterprise Logical Data Model (ELDM), and Standard Meta Model (Business Taxonomy and Technical Metadata); and determines if this Change Request (CR) is only for Data Collection or will go to the next step.

    Step 2 Data Consolidation To manage data as follows: consolidate and condense disjointed data that can/should be homogenized and recognize which data is truly distinct so the relevant data is most easily identifiable and accessible.
    • Change Initiator/Originator (Project Office/Change Requestor/User) creates and submits Data Consolidation Change Request (CR) or Work Request (WR).

    • Solution Engineering Data Practice Group (Engineering/Analyst) determines the scope of Change Request (CR) or Work Request (WR).

    • Solution Engineering Data Practice Group (Engineering/Analyst) determines the data source, and evaluates the Change Request against the IRS data strategy.

    • High Authority/DOCS ESC dispositions Data Consolidation Change Request (CR) if funding is required.

    • Solution Engineering Data Practice Group (Engineer/Analyst) considers Change Request (CR) and determines the impact on the Data Warehouse environment.

    Step 3 Data Certification To certify that the designated sources, processes, and projects understand data quality, and govern the data assets.
    • Change Initiator/Originator (Project Office/Change Requestor/User) creates and submits the Data Certification Change Request or Work Request (WR).

    • Solution Engineering Data Practice Group (Engineer/Analyst) determines the scope of Change Request (CR) or Work Request (WR).

    • Solution Engineering Data Practice Group (Engineer/Analyst) determines the data source, and evaluates the Change Request against the IRS data strategy.

    • Higher Authority/DOCS ESC dispositions Data Certification Change Request (CR) if funding is required.

    • . Solution Engineering Data Practice Group (Engineer/Analyst) certifies data contents with an appropriate data Competency Center.

    • Solution Engineering Data Practice Group (Engineer/Analyst) assigns the responsibility of source data validation to Project Office/User.

    • Change Initiator/Originator (Project Office/Change Requestor/User) conducts data profiling, implements data quality check, and develops balance & control and validation.

    Step 4 Data Connection To connect the data to each other as well as users to the data. Building out the metadata repository helps expose data element to the larger IRS audience.
    • Change Initiator/Originator (Project Office/Change Requestor/User) creates and submits Data Connection Change Request (CR) or Work Request (WR).

    • Solution Engineering Data Practice Group (Engineering/Analyst) determines the scope of the Change Request or Work Request.

    • Solution Engineering Data Practice Group (Engineering/Analyst) determines data sources, and evaluates the Change Request against the IRS data strategy.

    • Higher Authority/DOCS ESC dispositions Data Connection Changer Request (CR) if funding is required.

    • Solution Engineering Data Practice Group (Engineer/Analyst) identifies interfaces.

    • Solution Engineering Data Practice Group (Engineer/Analyst) routes approved Change Request (CR) to appropriate data platform (e.g. Enterprise Informatica Platform (EIP) Integrated Services, BusinessObjects Enterprise (BOE)).

    Step 5 Data Consumption To consume data by presenting the data in the proper/desired state for the recipient to efficiently make the right decisions. This effectively turns data into information that then can be strategically used.
    • Change Initiator/Originator (Project Office/Change Requestor/User) submits an OnLine 5081 request for accessing to the data system.

    • Project Office/User submits a Live Data Waiver request as required for users of SBU data.

    • OnLine 5081 Approval Group approves or denies the OnLine 5081 request.

    • Solution Engineering Data Practice Group (Engineer/Analyst) provides data environment for Project/User to consume data.

    • Project Office/User consumes data through queries and generating reports by using various data retrieval resources for data analysis

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
    Change Initiator/Originator (Project Office, Change Requestor, or User)
    • Submits Change Request (CR) /Work Request (WR) to High Authority

    • Enters ELC

    • Conducts data profiling; implements data quality check; develops balance control and validation

    • Submits an OnLine 5081 request for access the data system

    • Submits a Live Data Waiver request as required for user of SBU data

    • Consumes data through queries and generate required reports

    High Authority/ DOCS ESC Provides governance for data technology platforms and funds data initiatives
    Solution Engineering Data Practice Group (Engineer/Analyst)
    • Determines Data Collection scope and impact as related to ELDM

    • Determines data organization (OLTP/OLAP)

    • Advances ELC and achieves milestone approval

    • Reviews Data Management Process outputs

    • Aligns Project Data Model with ELDM

    • Determines impact on Data Warehouse environment

    • Certifies data contents

    • Identifies interfaces

    • Routes approved CRs to data platforms (e.g. EIP and BOE)

    OnLine 5081 Approval Group Approves or Denies OnLine 5081 Request
Procedure
  1. Data Management Process Procedures to identify the Tasks and Roles for each Activity

Tasks and Roles
  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
    Step 1 Data Collection
    Collect structured and unstructured data from across the agency and external to the agency. By leveraging the additional data captured with e-filing and modernized residual paper processing, more data can be shared for matching and targeting the best case. Data can be collected in forms of documents, records, models, emails, processes, RDBMS, business rules, or transaction systems.
    Change Initiator/Originator
    Solution Engineering/Data Engineering Group (Engineer/Analyst)


    High Authority/DOCS ESC
    R


    C

    A
    Follow the ELC to submit change request for Data Collection Service
    Review Change Request and preform Data Collection Service works

    Disposition Change Request
    Step 1.1 Create and submit Data Collection Change Request/Work Request
    In order to get the Data Collection Service from Data Engineering Group, Change Initiator/Originator must submit either change request or work request to Solution Engineering Data Engineering Group
    Change Initiator/Originator R Create, and submit Change Request or Work Request to Solution Engineering/Data Engineering Group for Data Collection Service
    Step 1.2 Determine the scope of change or work request
    This task is to determine the scope and impact of Change Request or Work Request with respect to IRS Data Collection as related to the Enterprise Logical Data Model (ELDM)
    Solution Engineering/Data Engineering Group (Engineer/Analyst) R Ensure change or work request follows the Data Engineering Guidelines.
    Step 1.3 Determine the data source, and evaluate the Change Request against the IRS data strategy
    • Determine the authoritative data source

    • Determine data organization (OLTP/OLAP)

    • Determine feasibility of Data Collection Change Request (CR)

    • Evaluate Data Collection Change Request (CR) against IRS Data Strategy

    Solution Engineering/Data Engineering Group (Engineer/Analyst) R The Solution Engineering Data Engineering Group is accountable for evaluating the change or work request against the IRS data strategy.
    Step 1.4 Disposition change or work request requiring funding.
    High Authority disposition change or work request and ensure project has funding to support change or work request.
    High Authority/DOCS ESC
    Solution Engineering/Data Engineering Group (Engineer/Analyst)
    A
    R
    High Authority/DOCS ESC reviews the change request, and determine to reject or approve the request
    Forward change or work request to High Authority for decision.
    Step 1.5 Enter Enterprise Life Cycle (ELC)
    • follow ELC Guidance

    • advance through ELC and achieve Milestone Approval

    Change Initiator/Originator R Change Initiator/Originator should be started (baseline) or updated at the corresponding Enterprise Life Cycle (ELC) Phase & Milestone
    Step 1.6 Submit ELC Artifacts
    A completed Data Management design with the applied version controlled.
    Primary Design:
    E300 and E53
    Project Tailoring Plan
    Project Management Plan
    Business System Requirement (BSR)
    • Entities & Attributes (Logical Data Model) Business Metadata (Business Taxonomy)


    Detail Design:
    Design Specification Report (DSR) (Physical Data Model/Technical Metadata)
    • Tables & Columns (Physical Data Model)

    • Technical Metadata (Technical Taxonomy) Interface Control Document (ICD) (Data Movement Metadata)

    • Schema; Service; Message Interchange Metadata (XML Taxonomy)

    Step 1.7 Review Data Collection Processing Outputs
    Primary Design
    E300 and E53
    Project Tailoring Plan
    Project Management Plan
    Business System Requirement (BSR)
    • Entities & Attributes (Logical Data Model)


    Business Metadata (Business Taxonomy)
    Detail Design:
    Design Specification Report (DSR) (Physical Data Model/Technical Metadata)
    • Tables & Columns (Physical Data Model)

    • Technical Metadata (Technical Taxonomy)


    Interface Control Document (ICD) (Data Movement Metadata)
    • Schema; Service; Message Interchange Metadata (XML Taxonomy)

    Solution Engineering/Data Engineering Group (Engineer/Analyst) R Review the ELC artifacts which are submitted by Change Intiator/Originator
    Step 1.8 Align Project’s data model with Enterprise Logical Data Model (ELDM), Standard Meta Model (Business Taxonomy and Technical metadata)
    • collaborate with Change Initiator/Originator (Project Office/Change Requestor/User)

    • Solution Engineering together with Project Office work to harmonize outputs until aligned with Enterprise Logical Data Model (ELDM)

    • Solution Engineering together with Project Office work to harmonize outputs until aligned with Standard Meta Model (Business Taxonomy and Technical metadata)

    • determine if this Change Request or Work Request is only request for data collection or needs to go to the next Data Management Process step(s).

    Solution Engineering/Data Engineering Group (Engineer/Analyst)
    Change Initiator/Originator
    R
    R
    Collaborate and work together with Change Initiator/Originator to harmonize the ELC requested artifacts
    Work with Solution Engineering/Data Engineering Group to harmonize ELC artifacts until align with Enterprise Logical Data Model, and Meta Model.
    Step 2.0 Data Consolidation
    To manage data as follows: consolidate and condense disjoint data that can/should be homogenized and recognize which data is truly distinct to the relevant data is most easily identifiable and accessible.
    Change Initiator/Originator
    Solution Engineering/Data Engineering Group (Engineer/Analyst)


    High Authority/DOCS ESC
    R


    C

    A
    Follow the ELC to submit change request for Data Consolidation Service
    Review Change Request and preform Data Consolidation Service works

    Disposition Change Request
    Step 2.1 Create and submit Data Consolidation Change Request (CR) or Work Request (WR).
    In order to get the Data Consolidation Service from Data Engineering Group, Change Initiator/Originator must submit either change request or work request to Solution Engineering Data Engineering Group
    Change Initiator/Originator R Create, and submit Change Request or Work Request to Solution Engineering/Data Engineering Group for Data Consolidation Service
    Step 2.2 Determine the scope of Change Request or Work Request
    • determine before processing this step if the work needed includes the Data Collection activity (Step 1)

    • determine the scope and impact of Change Request or Work Request with the respect to IRS Data Consolidation as related to the Enterprise Logical Data Model (ELDM)

    Solution Engineering/Data Engineering Group (Engineer/Analyst) R Determine if before doing this step, it needs to do Data Collection Service; and ensure the Change Request related to ELDM
    Step 2.3 Determine the data source, and evaluate the Change Request against the IRS data strategy
    • determine the authoritative data source

    • determine the data organization (OLTP/OLAP) determine the feasibility of the Data Consolidation Change Request (CR)

    • evaluate the Data Consolidation Change Request (CR) against the IRS Data Strategy

    Solution Engineering/Data Engineering Group (Engineer/Analyst) R Solution Engineering/Data Engineering Group (Engineer/Analyst) is responsible for determining data source, and following the IRS data strategy
    Step 2.4 Disposition change or work request requiring funding.
    High Authority disposition change or work request and ensure project has funding to support change or work request.
    High Authority/DOCS ESC
    Solution Engineering/Data Engineering Group (Engineer/Analyst)
    A
    R
    High Authority/DOCS ESC reviews the change request, and determine to reject or approve the request
    Forward change or work request to High Authority for decision.
    Step 2.5 Consider the Data Consolidation Change Request, and determine the impact on the data warehouse environment
    • consider the Change Request

    • determine the impact on the data warehouse environment

    • determine if this Change Request or Work Request is only for this step or if there is a need to go to the next Data Management step(s).

    Solution Engineering Data Practice Group (Engineer/Analyst) R Solution Engineering Data Practice Group (Engineer/Analyst) would consider the Change Request, and determine the impact on the data warehouse environment
    Step 3 Data Certification
    Certify the designated sources, processes, projects and understand the data quality. The higher the quality of the data the Agency has, the more accurate scores can be produced. More accurate scores lead to more effective issue detection and case selection. Certification enables the governance of complete, consistent, comprehensible, correct, and authoritative sources by establishing operational metrics
    Change Initiator/Originator Solution
    Engineering/Data Engineering Group (Engineer/Analyst)
    High Authority/DOCS ESC
    R
    R
    A
    Follow the ELC to submit change request for Data Certification Service
    Review Change Request and preform Data Certification Service works
    Disposition Change Request
    Step 3.1 Create and submit Data Certification Change Request (CR) or Work Request (WR).
    In order to get the Data Certification Service from Data Engineering Group, Change Initiator/Originator must submit either change request or work request to Solution Engineering Data Engineering Group
    Change Initiator/Originator R Create, and submit Change Request or Work Request to Solution Engineering/Data Engineering Group for Data Certification Service
    Step 3.2 Determine the scope of Change Request or Work Request
    • determine, before processing this step, if other Data Management activities such as: Data Collection or/and Data Consolidation are needed.

    • determine the scope and impact of Change Request or Work Request with the respect to IRS Data Consolidation as related to the Enterprise Logical Data Model (ELDM)

    Solution Engineering/Data Engineering Group (Engineer/Analyst) R Determine if before doing this step, it needs to do Data Collection Service; and ensure the Change Request related to ELDM
    Step 3.3 Determine the data source, and evaluate the Change Request against the IRS data strategy
    • determine the authoritative data source

    • determine the data organization (OLTP/OLAP) determine the feasibility of the Data Consolidation Change Request (CR)

    • evaluate the Data Consolidation Change Request (CR) against the IRS Data Strategy

    Solution Engineering/Data Engineering Group (Engineer/Analyst) R Solution Engineering/Data Engineering Group (Engineer/Analyst) is responsible for determining data source, and following the IRS data strategy
    Step 3.4 Disposition change or work request requiring funding.
    High Authority disposition change or work request and ensure project has funding to support change or work request.
    High Authority/DOCS ESC
    Solution Engineering/Data Engineering Group (Engineer/Analyst)
    A
    R
    High Authority/DOCS ESC reviews the change request, and determine to reject or approve the request
    Forward change or work request to High Authority for decision.
    Step 3.5 Certify the data content with appropriate data Competency Center
    Based on data content, Solution Engineering Data Practice Group(Engineer/Analyst) would send to different Competency Center to validate.
    Solution Engineering Data Practice Group (Engineer/Analyst) R Solution Engineering Practice Group (Engineer/Analyst) would certify data content to with competency center
    Step 3.6 Assign the responsibility of source data validation to the Project Office
    • send data validation back to Project Office

    • determine if this Change Request or Work Request is only for this step or go to the next Data Management step(s)


    Solution Engineering Data Practice Group (Engineer/Analyst)
    Change Initiator/Originator
    R
    I
    After certifying data content, Solution Engineering Data Practice Group (Engineer/Analyst) would assign the responsibility to project office
    Change Initiator/Originator accepts the feedback from Solution Engineering Data Practice Group (Engineer/Analyst) that the data have been validated,
    Step 3.7 Execute the following data validation:
    • Conduct data profiling

    • Implement data quality check

    • Develop balance &; control and validation

    Change Initiator/Originator R After data validation, Change Initiator/Originator would do validation and quality check,
    Step 4 Data Connection
    Connect the data to each other as well as users to the data. Building out the metadata repository helps expose data elements to a larger audience. Increasing data accessibility across the agency helps to gain the ability to measure ROI and compliance impact across the end to end process.
    Change Initiator/Originator
    Solution Engineering/Data Engineering Group (Engineer/Analyst)
    High Authority/DOCS ESC
    R
    R
    A
    Follow the ELC to submit change request for Data Certification Service
    Review Change Request and preform Data Certification Service works
    Disposition Change Request
    Step 4.1 Create and submit Data Certification Change Request (CR) or Work Request (WR).
    In order to get the Data Certification Service from Data Engineering Group, Change Initiator/Originator must submit either change request or work request to Solution Engineering Data Engineering Group
    Change Initiator/Originator R Create, and submit Change Request or Work Request to Solution Engineering/Data Engineering Group for Data Certification Service
    Step 4.2 Determine the scope of Change Request or Work Request
    • determine before processing this step, if the CR/WR needs to include previous Data Management step(s), such as: Data Collection, Data Consolidation, or/and Data Certification step(s).)

    • determine the scope and impact of Change Request or Work Request with the respect to IRS Data Consolidation as related to the Enterprise Logical Data Model (ELDM)

    Solution Engineering/Data Engineering Group (Engineer/Analyst) R Determine if before doing this step, it needs to do Data Collection Service; and ensure the Change Request related to ELDM
    Step 4.3 Determine the data source, and evaluate the Change Request against the IRS data strategy
    • determine the authoritative data source

    • determine the data organization (OLTP/OLAP) determine the feasibility of the Data Consolidation Change Request (CR)

    • evaluate the Data Consolidation Change Request (CR) against the IRS Data Strategy

    Solution Engineering/Data Engineering Group (Engineer/Analyst) R Solution Engineering/Data Engineering Group (Engineer/Analyst) is responsible for determining data source, and following the IRS data strategy
    Step 4.4 Disposition change or work request requiring funding.
    High Authority disposition change or work request and ensure project has funding to support change or work request.
    High Authority/DOCS ESC
    Solution Engineering/Data Engineering Group (Engineer/Analyst)
    A
    R
    High Authority/DOCS ESC reviews the change request, and determine to reject or approve the request
    Forward change or work request to High Authority for decision.
    Step 4.5 Identify interfaces Solution Engineering Practice Group (Engineer/Analyst) R Solution Engineering Practice Group (Engineer/Analyst) Identifies Interfaces
    Step 4.6 Route approved CRs to appropriate data platforms (e.g. Enterprise Informatica Platform (EIP) Integrated Services, BusinessObjects Enterprise (BOE)).
    • provide Computer Operator Handbooks (COH) for data platforms

    • evaluate schema certification metrics using Standard Data Names (Business, Physical & XML

    • determine if this CR or WR is for this step or go should it proceed to the next step

    Solution Engineering Practice Group (Engineer/Analyst) R Solution Engineering Practice Group (Engineer/Analyst) routes approved Change Request to appropriate data platforms
    Step 5 Data Consumption
    Consume: Present the data in the proper/desired state for the recipient to efficiently make the right decision. Data is effectively turned into information, used to innovate new methods/discoveries, streamline and automate retrieval processes through renovations, and intent individuals through motivation. Tools of data consumption focus on visual representations of dashboards, scorecards, queries, reporting tools, OLAP, or data mining.
    Change Initiator/Originator
    OnLine 5081 System Administrator or Manager
    Solution Engineering Data Practice Group (Engineer/Analyst)
    R
    R
    R
    Submit OnLine 5081 request
    Disposition OnLine 5081 request
    Provide data consumption environment
    Step 5.1 Submit an OnLine 5081 request for access to the data system Change Initiator/Originator R Change Initiator/Originator OnLine 5081 request
    Step 5.2 Submit a Live Data Waiver request as required for users of SBU data Change Initiator/Originator R Submit for Live Data Waiver
    Step 5.3 Approve or deny the OnLine 5081 request OnLine 5081 System Administrator or Manager R OnLine 5081 System Administrator or Manager dispositions OnLine 5081 request
    Step 5.4 Provide data environment for Project/User to consume data
    • determine before processing this step if there is a need to execute previous Data Management process step(s), such as: Data Collection, Data Consolidation, Data Certification or/and Data Connection

    • provide Data Environment for Project/User to consume data

    Solution Engineering Data Practice Group (Engineer/Analyst) R Provide data consumption environment
    Step 5.5 Consume data through queries and generating reports by using various data retrieval resources for data analytic Change Initiator/Originator R Consume data through queries
Cross-Functional Flow Diagram
  1. [Enter Diagram Name]

    Figure 2.152.2-2

    This is an Image: 59989002.gif

    Please click here for the text description of the image.

    Figure 2.152.2-3

    This is an Image: 59989003.gif

    Please click here for the text description of the image.

    Figure 2.152.2-4

    This is an Image: 59989004.gif

    Please click here for the text description of the image.

    Figure 2.152.2-5

    This is an Image: 59989005.gif

    Please click here for the text description of the image.

    Figure 2.152.2-6

    This is an Image: 59989006.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
    Data Implement Guide (DIG) Data implementation begins with vision and strategy activities and ends with system deployment. The Data Implementation Guide (DIG) provides guidance on how to document the flow of an information system's data throughout its life cycle: from acquiring, conversion, migration, storage to the time when it becomes obsolete and is deleted.
    Data Engineering Policy (Directive) Completion of Data Engineering Process The project will include in its engineering plan either by inclusion or reference, planning materials specifying how the following will be accomplished:
    • Execution Data Engineering Process

    • Obtaining needed resources to perform Data Engineering Process

    • Control of work products required by the Data Management Process

    • Engagement of stakeholders affected by the Data Management Process

    • Monitoring and Controlling of the Data Management Process

    • Collection of Data Management Process measures

    • Review of Data Management Process status with high level of management

    • Establishment of the Data Management Process within the project's defined processes

    • Submission of lesson learned and process improvement suggestions from the execution of Data Management Process.

    Data Implementation Compliance Directive The Data Implementation Compliance Directive enforces the Implementing of the Data Implementation Guide (DIG).
    Scope All projects following the Enterprise Life Cycle (ELC) are required to perform Data Engineering Process and associated activities in accordance with this policy.
Metrics
  1. Management will regularly set targets for process performance, gather quantifiable data related to different functions of the [ Enter Process Name] 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 an element of governance over the process that provides alignment to business vision, mission and goals.

    Process Management
    Statement: The Data Management 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 [Process Name] will not be successful.
    Process:
    Statement: Modifications to the Data Management 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
    • Any data technology tools, for instances: Enterprise Business Intelligence Platform (BusinessObjects), Enterprise Informatica Platform

    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 [Process Name] 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:

    • Any data technology tools that come into process

Exhibits

  1. Acronyms and Glossary

Exhibit A: Acronyms
  1. Acronyms

    Acronyms Description
    AD Application Development
    CMMI Capacity Maturity Model Integration
    EA Enterprise Architecture
    EDF Enterprise Demand Forecast
    EDM Enterprise Demand Management
    EOps Enterprise Operations
    ESS Enterprise Storage Service
    IPM Integrated Process Management or Integrated Production Model when uses for database environment
    IRM Internal Revenue Manual
    IT Information Technology
    ITIL Information Technology Infrastructure Library
    ITSM Information Technology Service Management
    JBoss JavaBeans Open Sources Software Application Server
    PAL Process Asset Library
    PD Process Description
    PMI Project Management Institute
    RACI Responsible, Accountable, Consulted, Informed
    SBU Sensitive But Unclassified
    SE Solution Engineering
    SEPM SE’s Engineering Process Maturity
    URL Uniform Resource Locator
    VPO Virtualization Project Office
Exhibit B: Glossary
  1. Glossary

    Term Definition
    Best Practice A best practice is a technique or methodology that, through experience and research, has proven to reliably lead to a desired result. A commitment to using the best practices in any field is a commitment to using all the knowledge and technology at one's disposal to ensure success. In software development, a best practice is a well-defined method that contributes to a successful step in product development. Throughout the software industry, several best practices are widely followed. Some of the more commonly used are: an iterative development process, requirement management, quality control, and change control.
    Capacity Maturity Model Integration (CMMI) Capability Maturity Model Integration (CMMI) is a process improvement training and certification program and service administered and marketed by Carnegie Mellon University and required by many Department of Defense (DOD) and Government programs for government contracts, especially software development. Carnegie Mellon University claims CMMI can be used to guide process improvement across a project, division, or an entire organization. Under the CMMI methodology, processes are rated according to their maturity levels, which are defined as: Initial, Repeatable, Defined, Quantitatively Managed, Optimizing. Currently supported is CMMI Version 1.3. CMMI is registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.
    Enterprise Storage Service (ESS) ESS represents an industry-leading "Storage as a Service" approach. It encompasses a historic transformation from project-based stove-pipes to a private cloud utility-based model where storage is available as-needed and is paid for only as-used. In June 2012, the IRS awarded the ESS contract to Unisys to transfer ownership of existing data storage arrays, enable tiered high-performance storage and faster storage acquisition and allocation, and capture significant cost savings based on actual data stored rather than total capacity. In March 2013, Phase 2 of the deployment was completed, culminating in ESS storage cloud “Ready For Use,” and the hard work of migrating existing data into this new cloud infrastructure began.
    Information Technology Infrastructure Library (ITIL) The Information Technology Infrastructure Library (ITIL) is a set of practices for IT service management (ITSM) that focuses on aligning IT services with the needs of business. In its current form (known as ITIL 2011 edition), ITIL is published in a series of five core publications, each of which covers an ITSM lifecycle stage. ITIL describes processes, procedures, tasks and checklists that are not organization-specific, used by an organization for establishing integration with the organization's strategy, delivering value and maintaining a minimum level of competency. It allows the organization to establish a baseline from which it can plan, implement, and measure. It is used to demonstrate compliance and to measure improvement.
    IT service management (ITSM) IT Service Management (ITSM) is a process-based practice intended to align the delivery of information technology (IT) services with needs of the enterprise, emphasizing benefits to customers. ITSM involves a paradigm shift from managing IT as stacks of individual components to focusing on the delivery of end-to-end services using best practice process models. ITIL (Information Technology Infrastructure Library) is a globally recognized collection of best practices for information technology (IT) service management.
    JavaBeans Open Sources Software Application Server (JBoss) JBoss is a division of Red Hat that provides support for the JBoss open source application server program and related services marketed under the JBoss Enterprise Middleware Suite (JEMS) brand. The JBoss applications server is a J2EE platform for developing and deploying enterprise Java applications, Web applications and services, and portals. J2EE allows the use of standardized modular components and enables the Java platform to handle many aspects of programming automatically.
    Linux Linux is a Unix-like computer operating system assembled under the model of free and open source software development and distribution. The defining component of Linux is the Linux kernel an operating system kernel first released 5 October 1991 by Linus Torvalds. Typically Linux is packaged in a format known as a Linux distribution for desktop and server use.
    RACI
    • Responsible – The person that is assigned to do the work.

    • Accountable – The person that makes the final decision and has ultimate ownership.

    • Consulted – The person that must be consulted before a decision or action is taken.

    • Informed – The person that must be informed that a decision or action has been taken.

    URL A uniform resource locator, abbreviated as URL (also known as web address, particularly when used with HTTP), is a specific character string that constitutes a reference to a resource.
    VPO Enterprise Operations established the Virtualization Project Office to be responsible for:
    • Leading the virtualization design effort;

    • Deploying the infrastructure in the Computing Centers and Campuses; and

    • Collapsing existing virtual environments into the enterprise virtual infrastructure.