DMMM

Data Management
Maturity (DMM) Model

SM
AUGUST 2014 | VERSION 1.0
Cover A
B
Performance.
Predictability.
Profitability.
Data Management Maturity (DMM) SM Model
Cover C
Welcome to the Data Management Maturity (DMM)SM Model
CMMI® Institute is delighted to introduce the Data Management Maturity (DMM)SM model. The DMMSM
model provides organizations with a standard set of best practices to precisely evaluate their capabili-
ties and build a unique roadmap to accelerate progress in delivering value to the business.
The DMMSM model was developed using the principles and structure of CMMI Institute’s Capability
Maturity Model Integration (CMMI)®—a proven approach to performance improvement and the gold
standard for software and systems development for more than 20 years. The DMM model helps organi-
zations become more proficient in managing critical data assets to improve operations, enable analytics
and gain competitive advantage.
In addition to providing a pathway to elevated organizational performance like the CMMI®, the DMM
model serves as a catalyst and a platform for the growth of a global community of professionals and
practitioners who are committed to advancing the state of the practice. These are people who work
every day to help communities in the workplace make things the way they ought to be. They create
innovative solutions to fix what is broken and envision new approaches to fill what is missing. They
serve as powerful accelerators for aligning the interests of lines of business with IT to ensure that their
critical data assets are strengthened, well-managed, and better utilized to achieve business goals. In the
current era of global business where information and access reign supreme, the companies that are able
to leverage their corporate data assets to the fullest are the companies where people flourish.
Over the last two decades CMMI has been adopted in over 94 countries, applied in thousands of organi-
zations, and has directly impacted the professional development of over 150,000 people. It has served
as the benchmark in organizations ranging from NASA working on manned space missions, to entre-
preneurial start-up companies in Shanghai. It is our hope that the DMM will serve the data management
needs of organizations across a similar spectrum of applications.
We are deeply grateful to the DMMSM Sponsors (Booz Allen Hamilton, Microsoft, Lockheed Martin, and
Kingland Systems) whose personal commitment and expertise has allowed us to offer the DMM
oes Here
model as a platform to the world.
We are also thankful for the early innovators (Microsoft, Fannie Mae, the Federal Reserve System
Statistics Function, Ontario Teachers’ Pension Plan and Freddie Mac) who reported significant benefits
from the use of the DMM model— including the ability to galvanize organizational change by identifying
and implementing collaborative actionable initiatives.
We appreciate the over 100 data management professionals representing 45 different organizations
who contributed to the development of the DMM and the 70 organizations who evaluated their capabil-
a/an
ities using the model during the development process.
pletion
CMMIHere
Together—individuals from a broad base of business, government and data management associations,
Institute and our DMM sponsors—have collaborated to make the Data Management Maturity
(DMM) model a catalyst for advancing data management strategy. We know from this experience, that
when DMM-based process improvements are implemented, organizations can realize significant benefits
such as controlling costs through the use of reliable and accurate data, mitigating risk, and increasing
XXXX transparency and data access for more strategic and informed business decisions.
We appreciate your support, dedication, and wisdom. If you are new to the DMM, we welcome you to
the conversation and look forward to working together.
Best regards,
Kirk Botula
CEO, CMMI Institute
iv
Licensed to Davi Meireles, 2015-05-29 #5864290

About CMMI® Institute
As the organization behind the Capability Maturity Model Integration (CMMI)®, a capability
improvement framework that guides organizations in high-performance operations, CMMI®
Institute is working to build upon the 20 years of CMMI’s success, advance the state of
the practice, accelerate the development and adoption of best practices, and provide new
and evolved solutions to meet the emerging needs of businesses around the world. CMMI
Institute supports the worldwide adoption of its technologies in small and large organiza-
tions alike in a variety of industries, including aerospace, finance, health services, software,
defense, transportation and telecommunications. In addition, CMMI Institute licenses its
products and services through a network of delivery partners; conducts training and certifi-
cation; sponsors conferences, workshops, and events; and promotes the benefits of process
improvement models and appraisal methods. CMMI Institute is part of Carnegie Innovations,
a technology commercialization enterprise and part of Carnegie Mellon University.
Visit us at www.cmmiinstitute.com
Acknowledgements
CMMI Institute wishes to thank its sponsors, who provided insight and vision to help us
bring the Data Management Maturity (DMM)SM model to the data management industry and
profession.
BOOZ ALLEN HAMILTON

Booz Allen Hamilton is a leading provider of manage-
ment consulting, technology, and engineering services
to the U.S. government in defense, intelligence, and civil
markets, and to major corporations, institutions, and
not-for-profit organizations.
“This is a critical period for effective data management

because of the growth of data and the risk and opportuni-
ties this presents. Booz Allen has long recognized the need
for a model that can assist organizations in their data man-
agement. The DMM model effectively addresses this need.
As a user of CMMI with client organizations, Booz Allen has
found that having DMM based on the CMMI facilitates the
implementation and effectiveness of data management
practices.” - Leslie DiFonzo, Senior Vice President,
Booz Allen Hamilton
KINGLAND SYSTEMS
Kingland Systems provides enterprise-class software,
reference data, technology services, and analytics
solutions to global clients in the accounting, financial,
and insurance markets to manage and improve
reference data, monitor and ensure compliance with
global regulations, and analyze data to improve
business processes in over 140 countries.

“The DMM model provides the best available tool for orga-
nizations to objectively evaluate where they stand against
practices that their peers have identified as necessary to do
well at data management. It transcends any one industry,
and has proven to be a valuable asset to anyone that has
to manage data or improve data management practices
within their organization.” - Jeff Gorball, Managing Direc-
tor, Kingland Systems Corporation
LOCKHEED MARTIN
Lockheed Martin is a global security and aerospace
company that employs about 118,000 people worldwide
and is principally engaged in the research, design, de-
velopment, manufacture, integration, and sustainment of
advanced technology systems, products, and services.
“As organizations have become more dependent on data

quality, integrity, and governance, a model to guide best
practices in the data management discipline has become
critical. The DMM model provides organizations with a
focused approach to managing the large amount of data
today’s organizations generate. The model’s architecture
allows the implementer to identify and fill the gaps existing
in data management, and delivers a “right-sized approach”
that can be used across an organization’s business data as
well as data within individual projects specific to individual
customers.” - Mary Lynn Penn, Director of Enterprise
Integration, Lockheed Martin Information Systems &
Global Solutions
MICROSOFT
Founded in 1975, Microsoft (NASDAQ “MSFT”) is the
worldwide leader in software, services, and solutions
that help people and businesses to realize their full
potential.
“DMM has accelerated the Microsoft Real-Time Enterprise

Journey, and is an effective and unambiguous language
to align Microsoft IT and businesses goals in real-time. The
recommendations provided by the CMMI Institute and
the DMM model were actionable and scalable for a large
organization like Microsoft Corporation, and enabled quick
assessments that led to immediate execution.”
- Luisa Recalcati, Senior Director, Library & Network,
Microsoft Corporation
vi

Data Management Maturity (DMM)SM Model Team
This document represents thousands of hours of work by representatives from a variety of

organizations. The initial content was created through extensive collaboration with many data
management experts, led by the Software Engineering Institute and corporate sponsors. The
DMMSM represents industry consensus on the key practices for effective data management.
Through our development effort, we have refined the model content through extensive
feedback from peer reviewers and pioneering organizations who have engaged in evaluating
their capabilities through DMM Assessments. The DMM incorporates the approach and proven
strengths of the Capability Maturity Model Integration (CMMI), a successful industry process
improvement reference model which for 20 years has helped over 10,000 organizations to
lower risk, increase predictability and performance, and gain increased profitability.
On behalf of the CMMI Institute and our corporate sponsors, we acknowledge the contribu-
tions of the following individuals, who have offered their time and knowledge for the creation
of the Data Management Maturity Model.
DATA MANAGEMENT MATURITY MODEL - LEADERSHIP TEAM

Melanie Mecca, DMM Program Manager, CMMI® Institute
Rawdon Young, CMMI® Architect, CMMI® Institute
James Halcomb, Data Management Expert, Elucidate.
MODEL DEVELOPMENT TEAM

Jose Abiles, Quality and Process Engineer, Booz Allen Hamilton
Jonathan Adams, Analytics Design & Architecture, Booz Allen Hamilton
Matthew Chopper, Enterprise Data Architect, Booz Allen Hamilton
Art Freas, Enterprise Architect, Lead Enterprise Data Architecture, Microsoft Corporation
Barbara Geshwind, Lockheed Martin
Jeff Gorball, Managing Director, Kingland Systems
Gary Lunsford, Enterprise Data Management Consultant, Booz Allen Hamilton Engineering
Services, LLC
M. Lynn Penn, Director Strategic Process Engineering, Lockheed Martin
Luisa Recalcati, Enterprise Architect, Microsoft Corporation
Nadine Schramm, Enterprise Data Architect, VF Corporation
Judith Thompkins, Enterprise Data Architect, Booz Allen Hamilton.
CONTRIBUTORS
Funmi Balogun, Fannie Mae; Roy Ben-Hur, Deloitte and Touche; John Carroll, element-22;
Predrag Dizdarevic, element-22; Doug Finn, Deloitte and Touche; John Gemski, Golden-
Source; John Housen, Chartis Insurance; Olga Maydanchik, Citi; Doug Nixon, Ernst and
Young; Richard White, Federal Reserve Bank of New York; Gian Wemyss, Software Engineer-
ing Institute, Carnegie Mellon University; and David Williams, Citi.
vii

REVIEWERS
Peter Aiken Dilip Gore Philip Michaelson

Mary Anne Herndon Mitch Hamilton Mark Mosley
Carlos Barbieri Susie Harvey Gloria Ng
Rita Barlow Ham Hayes Don O’Neill
Aylin Berkowitz Umamaheshwar Pat O’Toole
Hegde
Angela Boyd Bernice Purcell
Frank Hollenbach
Antonio Braga Nathan Sethuraman
Bill Inmon
Lewis Broome Anis Siddiqy
Sajit Jacob
Edd Burns Gurdarshan Singh
Ho-Wun Jung
Kim Chan Ravneet Singh
Marappa Kaliappan
Peter Chen Phil Snipes
Paul Kimmerly
Michael Coleman James Stacia
Thomas Klein
Jeanine Shelley Stall
Courtney-Clark Krishnamurthy
Kothandaraman Raja Valiveti
Anthony D’Angelo
Ross Leher Pieter van Zyl
Pratibha Dubey
Martha Lemione Tony Wilkes
Saswata Dutta
Steven MacLauchlan Chelsea Wilson
Mario Faria
Debbie McCoy Teresa Wylie
Becky Fitzgerald
Wil McCray Mingqing Xu
Mark Fox
Winifred Menezes Vincent Yip
Colin Galbraith
viii

Copyright 2014 CMMI Institute
NO WARRANTY
THIS CMMI INSTITUTE MATERIAL IS FURNISHED ON AN “AS-IS” BASIS. CMMI INSTITUTE

MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY
MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR
MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. THE
CMMI INSTITUTE DOES NOT MAKE ANY WARRANT OF ANY KIND WITH RESPECT FREEDOM
FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT.
TO THE MAXIMUM EXTENT ALLOWED BY LAW, EXCEPT AS EXPRESSLY SET FORTH IN ANY
SCHEDULE, ATTACHMENT, OR EXHIBIT, THE CMMI INSTITUTE SPECIFICALLY DISCLAIMS ALL
WARRANTIES, WHETHER EXPRESS, IMPLIED, OR STATUTORY, REGARDING OR RELATING
TO THE DATA MANAGEMENT MATURITY MODEL (DMM), OR ANY MATERIALS OR SERVICES
FURNISHED OR PROVIDED TO COMPANY UNDER THIS AGREEMENT, INCLUDING ALL IMPLIED
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE NONIN-
FRINGEMENT, USAGE OF TRADE, AND COURSE OF DEALING OR PERFORMANCE WITH RE-
SPECT TO THE DATA MANAGEMENT MATURITY MODEL (DMM) AND ANY OTHER MATERIALS
AND SERVICES WITH RESPECT TO THE USE OF ANY OF THE FOREGOING.
Use of any trademarks in this report is not intended in any way to infringe on the rights of the trade-
mark holder.
Your copy of the Data Managment Maturity (DMM)SM model is licensed solely to you, and no ownership
rights transfer to you when you download a copy of the DMM model. When you purchase a license to a
digital download of the DMM model, the PDF will be stamped with your name, denoting you as the sole
licensee of the document. You may not remove or obscure your name, any copyright notices or other
identifying information from the PDF.
You agree not to reproduce, duplicate, copy, sell, resell, assign, transfer or exploit any portion of the
DMM model, use of the DMM model, or access to the DMM model or the website through which the
service is provided, without express written permission by CMMI® Institute. The DMM model is provided
“as is, where is,” without warranties of any kind, and CMMI Institute hereby disclaims all express and
implied warranties, including but not limited to, any implied warranties of merchantability, fitness for a
particular purpose, accuracy, title or non-infringement. You are solely responsible for your use of the
DMM model, and agree to defend, indemnify and hold CMMI Institute harmless from any claims, liability,
damages, costs or expenses incurred by CMMI Institute arising from your use of the DMM model.
ix

Table of Contents
Figures & Tables xvii
Introduction  2
Background 2
About the DMM 2
Audience 2
DMM Framework 3
Organization of the DMM 3
Capability Evaluation 8
Capability and Maturity Measurement 8
Capability Measurement 8
Maturity Measurement 9
Data Management Strategy  11
Data Management Strategy 12
Purpose 12
Introductory Notes 12
Goals 13
Core Questions 13
Related Process Areas 14
Functional Practice Statements 14

Communications 20
Purpose 20
Goals 20
Core Questions 21
Data Management Function 24
Purpose 24
Goals 25
Core Questions 25
Business Case 31
Purpose 31
Goals 32
Core Questions 32
Program Funding 37
Purpose 37
Goals 37
Core Questions 38
xi

Data Governance  43
Governance Management 44
Purpose 44
Goals 45
Core Questions 45
Business Glossary 50
Purpose 50
Goals 51
Core Questions 52
Metadata Management 58
Purpose 58
Goals 59
Core Questions 59
Data Quality   69
Data Quality Strategy 70
Purpose 70
Goals 71
xii

Core Questions 71
Data Profiling 77
Purpose 77
Goals 77
Core Questions 78
Data Quality Assessment 84
Purpose 84
Goals 84
Core Questions 85
Data Cleansing 90
Purpose 90
Goals 90
Core Questions 90
Data Operations   97
Data Requirements Definition 98
Purpose 98
xiii

Goals 99
Core Questions 99
Data Lifecycle Management 105
Purpose 105
Goals 106
Core Questions 106
Provider Management 111
Purpose 111
Goals 111
Core Questions 112
Platform and Architecture  117
Architectural Approach 118
Purpose 118
Goals 119
Core Questions 119
Architectural Standards 126
Purpose 126
xiv

Goals 126
Core Questions 127
Data Management Platform 132
Purpose 132
Goals 132
Core Questions 132
Data Integration 137
Purpose 137
Goals 137
Core Questions 138
Historical Data, Retention and Archiving 144
Purpose 144
Goals 145
Core Questions 145
Supporting Processes  151
Measurement and Analysis 152
xv

Purpose 152
Goals 153
Core Questions 153
Process Management 168
Purpose 168
Goals 168
Core Questions 169
Process Quality Assurance 187
Purpose 187
Goals 188
Core Questions 188
Risk Management 193
Purpose 193
Goals 193
Core Questions 194
Configuration Management 206
Purpose 206
xvi

Goals 206
Core Questions 206
Infrastructure Support Practices  211
Purpose 211
IS 1 Perform the Functional Practices 212
IS 2 Implement a Managed Process 213
IS 3 Institutionalize Organizational Standards 217
Appendix  221
Figures & Tables
Figure 1. DMM Categories 4
Table 1 – Categories and Process Areas 5
Figure 2. DMM Construct 6
Table 2 – Capability/Maturity Level Definitions 7
Figure 3. Sample Organization – DMM Summary Scores 8
xvii

Introduction
BACKGROUND
The Data Management Maturity (DMM)SM Model is intended as a comprehensive reference
model for state-of-the-practice process improvement. The DMM defines the fundamental
business processes of data management and specific capabilities that constitute a gradated
path to maturity. It allows organizations to evaluate themselves against documented best
practices, determine gaps, and improve management of data assets across functional, line of
business, and geographic boundaries.
The DMM was collaboratively developed by data management experts, IT professionals, and
representatives of lines of business. The process areas and incremental capability measure-
ment criteria, known as “practice statements,” are based on practical, proven activities that
are required to achieve and sustain effective management of an organization’s data assets.
It is a framework that fosters alignment on the following factors: strategy, implementation
of governance mechanisms, defining dependencies, managing operational components,
integrating with IT capabilities, ensuring data quality, developing shared data across the
organization, and incorporating trusted data into the organization’s data stores.
The model’s overall goals are to help organizations to improve proficiency in management of
their critical data assets, and to provide a benchmark suitable for continuous improvement,
compliance, and audit.
ABoUT THe DATA MANAGMENT MATURITY (DMM)SM MODEL

The DMM is a process improvement and capability maturity model for the management of
an organization’s data assets and corresponding activities. It contains best practices for
establishing, building, sustaining, and optimizing effective data management across the data
lifecycle, from creation through delivery, maintenance, and archiving. The model’s organized
set of processes is applicable to all industries and any data management objective. It facil-
itates an organization’s appreciation for the management of data as critical infrastructure,
through increasing capabilities and disciplined practices.
While the DMM defines the requirements and activities for effective data management, it is
not prescriptive about how an organization should achieve these capabilities. The DMM is
structured such that it can be used by organizations to not only assess their current state of
capabilities, but also to build a customized roadmap for data management implementation.
The product suite supporting the DMM features a standard method for conducting objective
evaluations of the organization’s data management program, an organization Partner
program, and successive training courses leading to certification as an Enterprise Data Man-
agement Expert (EDME).
AUDIENCE
All organizations interested in evaluating and improving their data management program
from end to end can benefit from this model. The DMM is an unparalleled discovery tool
2 Introduction

for surfacing detailed data management activities that have contributed to the success of
adopting organizations.
The model provides a comprehensive framework for evaluating data management practices,
increasing the scope and engagement of data governance, and implementing best practices
for adoption and application by all organizations. A standard assessment methodology allows
organizations to measure themselves against best practices. Industry regulators and business
experts can employ the DMM for evaluation of capability and maturity of data management
practices within organizations.
Assessing data management maturity is a strategic initiative. However, an assessment against

the DMM also clearly reveals numerous tactical initiatives that can be accomplished leverag-
ing the existing strengths of the organization. The model is also useful, in whole or in part, as
a front-end activity for data infrastructure transformations, large analytics implementations,
master data management solutions, and similar purposes. The model guides implementers in
establishing and rolling out all of the activities needed to achieve and institutionalize effec-
tive data management practices.
DMM FRAMEWORK
The model is comprised of 20 data management process areas as well as 5 supporting
process areas based on CMMI process areas. The model is organized into five categories, as
illustrated in Figure 1. Each category contains a number of process areas, as shown in Table
1. These process areas serve as the principal means to communicate the themes, goals, prac-
tices, and example work products of the model. Accomplishment of process area practices
allows an organization to build capabilities and, in conjunction with the infrastructure support
practices, accomplish maturity in data management.
The model is structured such that an organization can implement any combination of process
areas or categories and still obtain a precise evaluation of their capabilities if only process
areas are evaluated, or overall maturity if process areas and infrastructure support practices
are evaluated. Therefore, an organization can evaluate achievement of capability or maturity
in a single process area, a set of process areas, a category, a set of categories, or any com-
bination, up to the whole model. This allows flexible use of the model to meet the specific
needs of all organizations. More information on the evaluations, and how they can be scoped
and tailored, can be found in the DMM assessment and appraisal training and services.
ORGANIZATION OF THE DMM

Process areas are consolidated under the five categories. Figure 1 shows how these catego-
ries (strategy, governance, data quality, operations, and platform and architecture) work to-
gether to create an effective data management program. The DMM also includes supporting
process areas, which contain the best practices for providing support for the implementation
of process areas.
Introduction 3

FIGURE 1
Although each process area can be considered separately, the collection of practices
work together to ensure that the organization has addressed data management across all
disciplines. There are dependencies and interrelationships that must be synthesized for an
effective program. The primary supporting relationships are presented as “Related Process
Areas.” Other relationships exist but are not explicitly stated; they are mentioned in support-
ing informative text. Table 1 shows which process areas are contained within each category in
the DMM. The selection of process areas within categories was based upon the affinity of the
process areas and the manner in which they support each other.
4 Introduction

TABLE 1 – CATEGORIES AND PROCESS AREAS
Data Management Strategy
Communications
DATA MANAGEMENT STRATEGY Data Management Function
Business Case
Program Funding
Governance Management
DATA GOVERNANCE Business Glossary
Metadata Management
Data Quality Strategy
Data Profiling
DATA QUALITY
Data Quality Assessment
Data Cleansing
Data Requirements Definition
DATA OPERATIONS Data Lifecycle Management
Provider Management
Architectural Approach
Architectural Standards
PLATFORM & ARCHITECTURE Data Management Platform
Data Integration
Historical Data, Archiving and Retention
Measurement and Analysis
Process Management
SUPPORTING PROCESSES Process Quality Assurance
Risk Management
Configuration Management
Each process area is composed of the same parts, as illustrated in Figure 2.
Brief description of why an organization will want to implement pro-

PURPOSE cesses that are compliant with the practices of the process area
Begins with a definition of what an organization will accomplish when
INTRODUCTORY it implements processes that are compliant with the process area,
NOTES provides context about its importance, and includes general implemen-
tation observations
Statements of what the key capabilities of the organization will be
GOALS when the processes compliant with the area are successfully imple-
mented
CORE Provides a high-level self-assessment summary; an organization can use
QUESTIONS the questions to quickly evaluate if it is achieving the desired results
RELATED Process areas that provide inputs, consume outputs, or are material
PROCESS AREAS support
FUNCTIONAL Description of the capabilities that need to be in place to successfully
PRACTICES achieve the intended results
Examples of the types of work products that would be produced by
EXAMPLE WORK
successful implementations that are compliant with the practices of the
PRODUCTS associated level
Introduction 5

FIGURE 2
Core Category
Process Area
Purpose
Introductory Notes
Goal(s) of the Process Area
Core Questions for the Process Area
Related Process Areas
Functional Practices (Levels 1-5)
Example Work Products
Infrastructure Support Practices
Explanatory Model Components Required for Model Compliance
The Infrastructure Support Practices, which are adapted from core CMMI process improve-
ment practices, apply to all DMM process areas and are expected to be performed to help im-
prove the capability or maturity of process areas, beginning with Level 1, and are consistently
applied at Level 3 and above. They ensure that support practices such as policies, planning,
resources, etc. are in place for supporting execution of data management processes.
6 Introduction

CAPABILITY AND MATURITY LEVELS
The DMM presents five levels of functional capability and maturity. Each process area level is
characterized by increasing achievements for process improvement of best practices. Table 2
provides a summary description and perspective for each level.
TABLE 2 – CAPABILITY AND MATURITY LEVEL DEFINITIONS
LEVEL DESCRIPTION PERSPECTIVE
1: Performed Processes are performed ad hoc, primarily at the proj- Data is managed as
ect level. Processes are typically not applied across a requirement for the
business areas. Process discipline is primarily reactive; implementation of
for example, data quality processes emphasize repair projects.
over prevention. Foundational improvements may
exist, but improvements are not yet extended within
the organization or maintained.
2: Managed Processes are planned and executed in accordance There is awareness

with policy; employ skilled people with adequate of the importance of
resources to produce controlled outputs; involve managing data as a
relevant stakeholders; are monitored and controlled critical infrastructure
and evaluated for adherence to the defined process. asset.
3: Defined Set of standard processes is employed and consis- Data is treated at

tently followed. Processes to meet specific needs are the organizational
tailored from the set of standard processes according level as critical for
to the organization’s guidelines. successful mission
performance.
4: Measured Process metrics have been defined and are used for Data is treated as a
data management. These include management of source of competitive
variance, prediction, and analysis using statistical and advantage.
other quantitative techniques. Process performance is
managed across the life of the process.
5: Optimized Process performance is optimized through applying Data is seen as

Level 4 analysis for target identification of improve- critical for survival
ment opportunities. Best practices are shared with in a dynamic and
peers and industry. competitive market.
Introduction 7

CAPABILITY EVALUATION
An organization may evaluate its capabilities according to DMM practice statements and
example work products. Each practice statement within a process area is scored individually
and weighted equally. Figure 3 presents a summary diagram that serves as a visual overview
of the process area scores. In the figure, the colored conical sections represent DMM catego-
ries, the white dashed line represents a capability of Level 3, and the dark line represents the
capability scores for each of the process areas.
FIGURE 3
CAPABILITY AND MATURITY MEASUREMENT

Within each process area, functional capabilities are measured based on the performance of
functional practices. Infrastructural support practices support the execution of the processes
developed for a process area by providing items such as planning, monitoring and con-
trolling, oversight, quality assurance, etc. Maturity is measured according to the achievement
within each process area of both the functional and infrastructure support practices associat-
ed with each capability level and all levels below.
CAPABILITY MEASUREMENT
For a process area to be scored at Capability Level 3, it must be performing all of the func-
tional practices for Levels 1, 2, and 3. Although process areas are independent, organizations
8 Introduction

may select any number of process areas as their focus for building and improving capabili-
ties.
For each process area, however, each capability level builds on the capabilities of all of the
previous levels. For example, to achieve Level 4, the organization must also meet the require-
ments of Levels 1, 2, and 3 in that process area.
MATURITY MEASUREMENT
Maturity assessment, as distinguished from capability measurement, requires that all process
areas being measured are being performed at the function capability level and also at the
same level in the infrastructure support practices. For a process area to be scored at a matu-
rity Level 3, the organization must be performing all of the functional practices for Levels 1, 2,
and 3 and all of the infrastructural support practices at Levels 1, 2, and 3. The maturity level
can be measured for single process areas, individual categories, or any combination of these,
up to and including the whole model.
For example, to achieve a Level 3 maturity rating in the category of Data Quality, the
organization must achieve at least functional capability Level 3, as well as the Infrastructure
Support Level 3 for all process areas within the Data Quality category.
Introduction 9

1 Data 12
Data Management
Strategy
Management 20 Communications
Data Management
Strategy 24
Function
31 Business Case
37 Program Funding
10 Data Management Strategy

Best practices for establishing, communicating, justifying,
and funding a collaborative vision for data management.
The Data Management Strategy category encompasses process areas designed to focus on
development, strengthening, and enhancement of the overall enterprise data management
program. It provides an outline and specific best practices for achievement of the following: a
broad and unified internal perspective about the importance of the organization’s data assets
and what is required to manage and improve them; gaining agreements through explicit and
approved priorities; aligning the program with the organization’s business strategy.
Data Management Strategy advocates that, irrespective of the current level of data man-
agement maturity, significant stakeholder involvement is needed to develop the long-term
commitments required to achieve organization-wide cohesion and demonstrate value to
the business, according to shared and approved objectives and priorities. Achieving this
alignment with business goals and objectives is imperative to realize the greatest value to
the organization. Communications addresses the importance of bidirectional stakeholder
communication according to a planned approach that facilitates continued collaboration,
and determining the types and frequency of program information provided through multiple
channels. Because the data management program is both permanent and evolutionary, com-
munications should be carefully thought out and need to be well-managed and sustained.
The Data Management Function emphasizes the need to effectively scope, plan, and resource
data management activities as a sustained function; develop strong leadership; and inculcate
a shared stakeholder approach to data management roles and responsibilities. Business Case
helps an organization to frame, justify, and gain approval for data management initiatives
based on the scope and sequence plan created for the Data Management Strategy. Program
Funding addresses the development and ongoing justification of funding, and the funding
model employed for the data management program and its component projects, to provide
appropriate funding for phased, sustained data management improvements.
Maturity of the practices in this category will strengthen the form and structure of the data
management program, build ongoing advocacy and support from stakeholders, and help
the organization to achieve its strategic objectives with the confidence that results from a
comprehensive and thoughtful implementation.

PURPOSE
Defines the vision, goals, and objectives for the data management program, and
ensures that all relevant stakeholders are aligned on priorities and the program’s
implementation and management.
INTRODUCTORY NOTES
An effective data management strategy defines why the organization is implementing
a data management program, explains what the overall program aims to achieve,
and identifies how the various components of the initiative fit together. It needs to
accurately reflect the data suppliers’ and consumers’ business objectives to give
confidence to stakeholders that the data management program will be valuable.
A functional data management strategy should be developed collaboratively and
approved by all stakeholders. A current state assessment, including capability gap
analyses and identifying key dependencies, can foster alignment and provide a
foundation for buy-in to the strategy and the corresponding plan for implementation.
It is recommended that the organization immediately undertake the development (or

revision) of its data management strategy following a data management assessment,
leveraging participant momentum and an accentuated shared perspective. The
ensuing collaborative project, developing the data management strategy, is a powerful
mechanism for clarifying executive actions and decisions and fast-tracking the data
management program: all key players have had a voice; agreement on objectives,
priorities, and measures has been achieved; organization-level approval of capabilities
to be improved is accomplished; and all relevant stakeholders understand the impacts
of the implementation sequence plan.
Engaging in the development (or refinement) of the data management strategy

provides an unparalleled collaboration opportunity, which can be leveraged as fuel for
the cultural and organization change that is required for continued success.
The data management strategy defines the overall framework of the program. A data
management strategy usually consists of, at a minimum:
• A vision statement, which includes core operating principles; goals and objec-
tives; priorities, based on a synthesis of factors important to the organization,
such as dependencies, perceived business value, alignment to strategic initia-
tives, and level of effort
• Program scope—including both key business areas (e.g., Customer Accounts);

data management priorities (e.g., Data Quality); and key data sets (e.g.,
Customer Master Data)
• Business benefits
• The selected data management framework and how it will be used
• Major gaps identified in the current state based on a data management

assessment

• High-level roles and responsibilities; list of key stakeholders
• Governance needs and scope
• Description of the approach used to develop the data management program
• Extent and scope of compliance approach
• Success measures and metrics; benchmarking instrument to measure progress
• High-level sequence plan (roadmap)
The data management strategy needs to reinforce the use of standards and outline
the overall governance framework that the organization will employ to make decisions
about implementation. It should also take into account major implementation consid-
erations, such as architectural initiatives and technology transformation initiatives
underway or planned, and it needs to define a sequence plan to guide implementation.
The strategy needs to identify the resource requirements for the data management
program, and the criteria that will be employed to evaluate program effectiveness.
Measures are defined and monitored throughout implementation to assess progress
against program objectives.
The organization’s data management strategy must be able to evolve as the needs
of the organization change. Collaboration is essential to building and maintaining an
effective data management program. One example of evidence of improved collabo-
ration is a broader and more evident responsibility for data quality, led by executives
and reflected throughout the data lifecycle. The most effective data management
strategies are those that are visibly and actively endorsed by executive management
and supported by mandatory organizational policy: in effect, institutionalized.
GOALS
1. Establish, maintain and follow a data management strategy that is aligned
with organizational strategy, approved by all relevant stakeholders, communi-
cated across the organization, and reflected in architecture, technology, and
business planning.
2. Maintain the data management strategy (goals, objectives, priorities, and

scope) for all business areas, through data governance.
3. Stakeholders set data management program priorities and objectives based

on the business value of data and a shared vision for data management.
4. Develop, monitor, and measure an effective sequence plan for guiding the data
management program implementation.
CORE QUESTIONS
1. Do executive stakeholders visibly and actively support the data management
strategy?
2. Is the sequence plan aligned with business priorities and milestones?

3. Is there sufficient understanding and agreement among executives and
operational, IT and business stakeholders, to support a long-term sustainable
data management program?
4. How are projects aligned with the sequence plan that guides implemention of
the data management program?
5. Are staff capabilities and resources in place to architect, design, and lead the
data management program? Is there a commitment to provide training to
enable maturity of the data management program?
6. Is there a commitment to provide training to enable maturity of the data

management program?
RELATED PROCESS AREAS

Architectural Standards gives guidance to ensure that business strategy and architec-
tural standards are aligned and consistent with business needs.
Business Case provides information to help ensure that proposals to fund programs,
initiatives, or specific projects are in line with the data management strategy.
Communications helps in developing policies, standards, processes, progress

announcements, and other data management communications, and ensuring that they
are published, enacted, and understood within the organization.
Data Lifecycle Management provides guidance to ensure common understanding of

how data flows through business processes across the data lifecycle from creation or
acquisition to retirement.
FUNCTIONAL PRACTICE STATEMENTS
Level 1: Performed
1.1 Data management objectives, priorities, and scope reflect stakeholder

business objectives within projects.
For a specific project, the business sponsor, business representatives, and

project team define the priorities and objectives for the data set within
scope. This may include identifying data scope and requirements, mapping to
business process steps which create, read, update, and delete data, applying
standards for management of supplier and consumer data, instituting data
quality checks, etc.
Data Lifecycle Management addresses alignment between business needs

and processes and data management priorities.

• Documented business objectives
• Data management objectives, priorities, and scope for a project
• Report on data management outcomes versus objectives for a project

Level 2: Managed
2.1 Data management objectives, priorities, and scope are defined and
approved.
The subject areas within scope, that are relevant to a business unit or cross-
cutting initiative (for example, reference data used by multiple business
areas) are defined and approved by all stakeholders, including IT and lines of
business. When multiple business units are impacted, data governance should
be engaged. In addition, the scope should address requirements such as
externally procured data vital to business processes, regulatory requirements,
etc.
2.2 Data management objectives and priorities are aligned with business objec-
tives.
The subject areas within scope are mapped to business unit objectives,
functions, and processes. Data management priorities and objectives are
reviewed and modified with input from business unit stakeholders.
2.3 A process for prioritizing projects across a business unit from a data
perspective, as well as traceability to business objectives, is established and
followed.
Projects are prioritized based on factors important to the business unit,

such as business value, time-criticality, level of effort, and process and data
dependencies.
2.4 A tactical plan for addressing data management objectives and priorities
across the business unit is established and maintained.
The business unit (or cross-cutting project) has developed a plan that
typically includes key milestones (e.g., component projects), major activities,
dependencies, resources, and identification of stakeholders.
2.5 Metrics are used to assess the achievement of objectives for data
management.

• Data management objectives and corresponding metrics
• Data management scope definition
• Subject area mapping to functions that create, update, and delete data
• Approved list of data management priorities
• Data management priorities mapped to business objectives
• Project prioritization list
• Capability enablement sequence plan

Level 3: Defined
3.1 A data management strategy representing an organization-wide scope is

established, approved, promulgated, and maintained.
The data management strategy describes the approach for implementing a

new (or enhanced) multi-year data management program organization-wide.
The data management strategy typically addresses, at a minimum:

• A vision statement, which includes core operating principles; goals and
objectives; priorities, based on a synthesis of factors important to the
organization, such as level of effort, business value, dependencies, and
stakeholder support for strategic initiatives
• Program scope—including both key business areas (e.g., Customer

Accounts); data management priorities (e.g., Data Quality); and key data
sets (e.g., Customer Master Data)
• Business benefits
• The selected data management framework and how it will be used
• High-level roles and responsibilities
• Governance needs
• Data management program development approach
• Compliance approach and measures
• High-level sequence plan (roadmap)
The data management strategy integrates the organization’s key objectives

and business priorities for its data assets, and the processes that establish,
build, and improve them. It is developed to increase understanding and
awareness of data as a critical corporate asset, and to gain approval and
commitment from all relevant stakeholders and decision makers. Active and
sustained buy-in is the key to adoption and success over time.
3.2 Data management objectives for the organization are evaluated and
prioritized against business drivers and goals, and aligned with the business
strategy.
A recommended approach is to begin the development of the data

management strategy with reference to the organization’s strategic business
plan with its goals and objectives to determine the primary drivers for
improvements to data management and architecture.
3.3 Business and technology collaboratively develop the organization’s data

management strategy.
The scope of the data management program aligns with the enterprise
architecture, the target data architecture, and the existing and future
infrastructure. Typically, the data management function and governance
bodies play a significant role in orchestrating collaborative development and
ensuring a comprehensive strategy.

Architectural Standards provides guidance to ensure that business strategy
and architectural standards are aligned and consistent with business needs.
3.4 The sequence plan for implementation of the data management strategy is
monitored and updated, based upon progress reviews.
A successful sequence plan includes high-payback quick wins to generate

and sustain momentum, as well as longer-term and important strategic
initiatives. It is important to identify major dependencies—impacting projects
underway, organization formation, etc.
Reviews of the sequence plan for implementation of the data management

program should take into consideration:
• Progress against milestones
• Risk identification
• Resource usage
• Alignment with data management priorities
• Achievement of data management objectives
Business Case describes activities associated with data management prior-

ities and its alignment with business needs.
3.5 The organization’s data management strategy is documented, maintained,

reviewed, and communicated according to the organization’s defined
standard process.
The data management function and data governance bodies are responsible
for ensuring effective communication of the data management strategy.
As business needs and strategy changes occur, the governance body
representing all business stakeholders is typically responsible for regularly
reviewing the priorities, objectives, and roadmap, as well as updating them
and following a defined process for approval.
Communications provides additional guidance developing and ensuring

effective communications for data management.
3.6 The organization’s data management strategy is consistent with data

management policies.
As needed, policies are reviewed with respect to the strategy to evaluate the
need for new policies or enhancements to existing policies. Policies provide
the foundation for organization-wide compliance.
The strategy may also identify the need for new policies, which should be
included in the sequence plan.
3.7 Metrics are used to assess and monitor achievement of data management
objectives.
Program metrics may include measurements of the sequence plan milestone

progress and evaluation of costs and benefits. Program-level metrics should
be accessible by all stakeholders (e.g., through a dashboard). Measures

should be developed employing standard best practice techniques, such as
Goal Question Indicator Metric.
Measurement and Analysis provides a systematic approach for establishing

and analyzing metrics.

• Data management strategy
• List of data management objectives and priorities
• Data management policies
• Stakeholder participation and approval documents
• Data management program scope documentation (e.g., subject areas,

business areas, key data elements, key disciplines, etc.)
• Data management strategy sequence plan
• Data management program metrics
• Program cost-benefit analysis results
• Data management program reviews
• Data management strategy dashboard
Level 4: Measured
4.1 Statistical and other quantitative techniques are used to evaluate the
effectiveness of strategic data management objectives in achieving business
objectives, and modifications are made based on metrics.
Changes made to the process for developing strategy and objectives typically
include the following:
• Improving the process employed for developing data management
objectives, priorities, and scope needed to achieve business objectives
• Adjusting the statistical evaluation or data collection method
4.2 The organization researches innovative business processes and emerging

regulatory requirements to ensure that the data management program is
compatible with future business needs.

• Metrics-based data management program reports
• Plan and documentation for monitoring emerging industry or regulatory

requirements
• Data management policies
Level 5: Optimized
5.1 The organization researches and adopts selected industry best practices for
strategy and objectives development.

5.2 Contributions are made to industry best practices for data management
strategy development and implementation.

• External publications and presentations about best practices at industry
conferences
• Comparative analysis reports of best practices

Communications
PURPOSE
Ensure that policies, standards, processes, progress announcements, and other data
management communications are published, enacted, understood, and adjusted based
on feedback.
INTRODUCTORY NOTES
Data management communications include the policies, strategies, roles and respon-
sibilities, plans, and mechanisms for informing all relevant stakeholders about data
management in an effective and timely manner. The importance of data management
communications cannot be overvalued, both for establishing an effective program and
to support and improve data management capabilities, which are heavily dependent
on collaboration across the organization.
Promulgation is the act of formally proclaiming or declaring a new statutory or admin-

istrative policy after its enactment. In many organizations, promulgation is necessary
before a policy can take effect. Promulgation of data management standards, policies,
and processes should be addressed through established policy management mecha-
nisms nisms and incorporated into the communications strategy of the organization.
For some stakeholders and organizations, communications channels can be

more effective if they include in-person events (e.g., regular meetings, structured
workshops, town hall events, etc.). The mechanisms, frequency, and timing of commu-
nications should be defined as part of the data management communications strategy.
In addition, communications that require action or a response are more likely to be
effective when they come from senior management.
To ensure that the organization can achieve its objectives, promulgation of policies,
standards, and processes must be established in advance of the target adoption date
and commencement of compliance checks. A feedback process should be established
to support stakeholders’ questions, recommendations, etc. Measurement of the effec-
tiveness of the promulgation process can be assessed through the use of adoption
metrics.
Published policies, standards, and other guidelines should be readily available to

members of the organization. Often this is accomplished through a centralized
electronic library. The library must be maintained to ensure that assets are kept up to
date, and a method should exist whereby updates can be effectively communicated
to impacted stakeholders. The appropriate communication may be as simple as
publishing a notice, or more comprehensive, such as a training session.
GOALS
1. The data management communications strategy ensures that the right messages
20 Communications

about the program are understood by the right people, at the right time.
2. Industry or regulatory guidance that impacts data management is

promulgated internally in a timely manner.
3. Stakeholders participate in the development of data management communica-

tions.
CORE QUESTIONS
1. How are policies, standards, and processes for data management
promulgated?
2. How does the organization keep stakeholders informed about data

management plans and projects?
3. How is bidirectional communication accomplished among business, IT, data

management, and executive management about data management priorities,
approaches, and deliverables?

Data Management Strategy provides guidance to ensure that all communications are
aligned with the strategies and priorities that this Process Area will be required to
define.
Level 1: Performed
1.1 Communications are managed locally.
The communications level and frequency may vary significantly between

different parts of the organization and within different projects.
• Announcements, emails, meeting notes, or web portal
Level 2: Managed
2.1 The communications plan for data management is defined, documented,

approved by stakeholders, and scheduled.
It is critical to plan and control communications to support the data

management program. A communications strategy typically includes a
matrix for guiding operational communications. The matrix may consist of
designations by topic (e.g., data quality), type (e.g., profiling process, data
quality policy), audience (e.g., data stewards), frequency (e.g., quarterly,
event-driven), date created, modified, or sunsetted.
Refer to Data Management Strategy for details of the strategy that need to be
communicated.
Communications 21

2.2 Data management standards, policies, and processes are communicated and
adjusted based upon feedback.

• Communications policy
• Announcements, emails, meeting notes, or portal
• Communications strategy
• Communications examples
Level 3: Defined
3.1 The communications policy establishes criteria for the dissemination or

promulgation of different types of data management communications.
Varying levels of importance dictate that some messages are communicated

differently than others. It is important that guidelines are used to influence
communication planning and dictate the types of communication based on
criteria that are aligned with the scope and importance of the message.
3.2 The communications strategy is guided by an organization-wide policy and

reflects the data management strategy.
3.3 Standards, policies, and processes are promulgated across the organization
and adjusted based upon feedback.
3.4 Metrics are developed and used to measure effectiveness of the data
management communications.
3.5 Communications are reviewed by stakeholder peers according to a process

that is required by defined standards, and processes.
3.6 Metrics are employed to improve data management communications effec-

tiveness.
Communications metrics depend upon the stated goals, objectives, and

channels defined in the communications strategy. They should measure the
effectiveness and efficiency of data management communications. Examples
of communications metrics include percentage of stakeholders identified;
adoption rate of data management policies and procedures communicated to
stakeholders; percentage of stakeholders involved in the development of the
data management communications strategy.

• Communications policy
• Announcements, emails, meeting notes, or portal
• Communications effectiveness metrics
• Communication plan
• Peer feedback about communications
22 Communications

Level 4: Measured
4.1 Data management communications with external stakeholders are planned

and conducted according to the communications strategy.
External audiences typically include regulatory bodies, industry and trade

organizations, and standards bodies.
4.2 Statistical and other quantitative techniques are employed to improve data
management communications.

• Changes to data management communication plans linked to communi-
cations effectiveness metrics
• Regulatory correspondence (i.e., responses to inquiries, reports, and

memoranda)
Level 5: Optimized
5.1 External data management communications are made with the purpose of
influencing public policies and industry best practices that impact data.

• External communications
• Impacted public policies and industry best practices
Communications 23

Data Management Function
PURPOSE
Provides guidance for data management leadership and staff to ensure that data is
managed as a corporate asset. Executive oversight is critical to establish and maintain
data management principles, facilitate adoption, and ensure alignment across the
organization.
INTRODUCTORY NOTES
The data management function defines key components of data management
activities and provides guidance for interaction within the overall organization. The
resourcing and deployment strategy for data management resources is developed
based on objectives, within the parameters of the organization’s culture and existing
organizational structures with which the function will integrate.
In most organizations, the data management function has been operational for
a number of years, typically having originated within IT and closely linked to
development of data stores. As organizations have moved toward appreciating the
criticality and value of their data assets, the function and activities have expanded
and additional roles have been defined. The groups or individuals performing the data
management function have a sustaining role, and increasingly, a leadership role for
implementing data management capabilities and conducting compliance actitivities.
Data management success depends on business ownership of its goals and objec-
tives. Implementation or enhancement of the data management function should
be developed and communicated with stakeholders in alignment with the data
management strategy. This will not automatically resolve all challenges, but will assist
the organization in effective integration of the function and the groups or individuals
involved.
Achieving alignment evolves over time, and progress is not always linear. A failure to
take this into account will result in inaccurate scheduling estimates. Sustainability of
the data management function requires a culture of open communication, combined
with a willingness to institutionalize practices that create business value and curtail or
eliminate practices that don’t. Strong leadership and skilled and experienced staff are
equally important for continued success of the data management function.
The lines of accountability and responsibility for data management activities are
typically communicated in an organization chart, an interaction diagram, and a
responsible, accountable, consulted, informed (RACI) matrix. Some organizations
find it useful to outline the mission and objectives of the data management function
in the form of a charter. As the organization makes progress in its data management
program, the data management function will need to change to address new develop-
ments.
24 Data Management Function

GOALS
1. Establish and follow role definitions, responsibilities, authorities, and account-
ability to provide consistency in decisions and interactions related to data
management.
2. Institutionalize the process for executive oversight of data management, to

ensure the adoption of consistent policies, processes, and standards.
3. The data management function is aligned with data governance on data

management priorities and decisions.
4. Develop, evaluate, and reward data management staff based on organiza-

tion-wide criteria.
CORE QUESTIONS
1. Is the data management function defined such that it is clear to all relevant
stakeholders?
2. Is the data management function aligned to the data management strategy, as

demonstrated by measures and metrics?
3. What role do executives play in the design and oversight of the data
management function?

Data Management Strategy provides guidance to the organizational model in the form
of strategic objectives, priorities, and stakeholders. These form the basis of the objec-
tives that the data management function is to oversee and communicate.
Program Funding supports the organizational model by providing guidance on

practices to ensure that the structure defined by the organizational model is
adequately funded to perform its role in data management oversight.
Governance Management describes organization-wide bodies of responsibility and

authority for corporate data assets, to which the data management organization
provides sustaining leadership and support.
Data Lifecycle Management helps to identify where in the organization data

management is performed or is needed. Knowledge of this information is critical to
ensuring that the Data Management Function fully encompasses all needs.
Level 1: Performed
1.1 Data management resourcing and oversight are event-driven.
Data management staff may be in a central organization or allocated to

projects. Their roles are not typically distinct (e.g., position descriptions may
refer to data analysts, data architects, etc.), and their activities may differ
from project to project.

• Project communications, meeting minutes
• Assignment of data-related roles to projects
Level 2: Managed
2.1 An approved interaction and engagement model ensures that stakeholders

engage with the data management organization.
Refer to Data Management Strategy, which provides input to organizational

model in the form of strategic objectives, priorities, and identified stake-
holders.
2.2 Principles are defined and followed to guide the consistency of practices
related to data management.
Rarely can all activities and expectations be explicitly defined for every
eventuality. To help ensure consistency of practice when explicit guidance
is not available, guidelines and principles are used to help shape decisions.
Documented principles help to ensure alignment between stakeholder activ-
ities and those of data management staff across the business unit.
2.3 Roles and responsibilities are specified to support the governance of

data management and the interaction between governance and the data
management function.
Data governance roles are established in a form that clearly communicates to

those with responsibilities, and their stakeholders, what those responsibilities
are and who has them. Typical examples include a RACI matrix, position
descriptions, and organizational charts indicating who has what types of
responsibilities relative to data management activities.
Refer to Governance Management, which describes organization-wide bodies

of responsibility and authority for corporate data assets, to which the data
management organization provides sustaining leadership and support.
2.4 Agreements are in place that provide explicit expectation for the use of
shared staff resources with responsibilities for data management.
Two common problems often surface when the management of human

resources is shared: the resource is conflicted by the differences in goals
and objectives between the two managers, leading to the resource being
placed in the untenable position of making decisions that should be made
by management. Having agreement on a clear set of expectations helps to
mitigate these issues.
Refer to Data Lifecycle Management, which helps to identify the components

of the organization that have a need for, or manage, data. Knowledge of this
information is important to ensure that the data management function fully
encompasses business needs.
2.5 A mechanism exists and is followed to identify and apply needed changes to
enhance or redesign the data management function.

Reviews of the data management function should be performed periodically
to assess its relevance and allocation against the changing needs of the
business. Other triggers for change typically result from events such as
objective measures, results of internal process audits, or suggestions for
process improvement.
Rarely does a business unit or organization remain static; business objectives,

technology, and staffing resources change. These tend to impact the needs
of the data management function and its governance. It is important to make
adjustments to ensure that the existing data management function continues
to be aligned with the needs and resources of the business.
In lower maturity organizations, changes related to the data management

function are generally event-driven and often made after something has
exposed a weakness in the model. By contrast, higher maturity organizations
establish objective measures and regularly schedule reviews of the data
management function to ensure that the model is meeting the current and
future needs of the organization, and initiate changes as necessary.
Refer to Governance Management, which describes organization-wide bodies

of responsibility and authority for corporate data assets, to which the data
management organization provides sustaining leadership and support.

• Policies
• Process documents
• Program guides
• Defined roles and responsibilities
• Metrics related to the data management function
• Function review notes or report
• Lessons learned documents
Level 3: Defined
3.1 A data management function is established with responsibility for managing

activities that support data management objectives.
Data management resources, roles, and responsibilities are approved at the

executive management level of the organization. Furthermore, policy-making
authority establishes principles of operation, standards, and objectives of
data management operations across the organization. Data management
must be equipped with sufficient authority and resources to guide the
program. It must also be formed carefully to ensure that it has the appro-
priate stakeholder perspectives to ensure successful implementation and
institutionalization of its published guidance, and to ensure that its principles
encompass all of the stakeholder needs.
Executive management should be involved in data management oversight

and help to facilitate adoption and institutionalization. Executive sponsorship

establishes shared expectations, promotes confidence in the program, and
approves methods for measuring progress. Active engagement of executive
sponsors is important to ensure continued alignment with goals and objec-
tives, and continued alignment with business, as well as to monitor milestone
achievement. Executive sponsors are also important in managing expecta-
tions and prioritizing data management resources. Typically, the function of
data management reports to a senior executive, often the Chief Data Officer.
Clear roles and responsibilities, along with accountability mechanisms, are

defined, documented, and standardized. Performance goals for members of
the data management team should include data management program goals.
This helps to ensure that alignment between data management needs and the
organization’s strategy and priorities is maintained.
3.2 The interaction model for the data management function ensures the
involvement of data governance for projects that use shared data.
The organization should understand which projects and data management

activities are in direct support of its organizational goals and strategy. Shared
data sets are critical to the accomplishment of the organization’s goals; and
projects which may create, manage, or have an impact on this data should be
monitored through the data management function. The monitoring of these
projects and activities should be accomplished via regular communications
between the execution teams, senior management, and the positions and
roles established as part of the data management function. Criteria are
generally established through which the monitoring occurs, including a
standard set of core metrics that allows consistent evaluation among projects
and activities across the organization.
Refer to Data Lifecycle Management for identifying the components of the

organization that have need for, or manage, data across projects and other
initiatives and operations.
3.3 A data management organization and specified structure are defined and
periodically reviewed to ensure that they meet the needs of the organi-
zation.
The data management organization is formed to conduct the following:

• Promote guiding principles of data management
• Clarify and communicate responsibilities
–– Foster a common understanding of objectives

–– Address and synthesize the expectations of various business
functions
–– Facilitate approved criteria for measuring progress
This organizational model should be regularly reviewed to ensure that it

evolves as the needs of the organization change and governance activities
are institutionalized.
To ensure that the data management function meets the needs of the
organization, data management staffing should be managed from a strategic

viewpoint. Regular review of organizational objectives and evaluation of
existing skills and capabilities should be conducted to ensure that staffing will
consistently meet the needs of the organization, with hiring or staff training
plans initiated as needed.
The Data Management Strategy process area provides guidance to the

organizational model in the form of strategic business objectives, priorities,
and stakeholders. These form the basis of the objectives that the data
management function executes and oversees.
3.4 Data management processes are established and maintained by the data
management function with governance approval.
3.5 Data management is an explicitly recognized business function and is

leveraged across the organization.
Strong data management practices often require subject matter experts for
execution. These experts should be trained and, where appropriate, certified
in their specific discipline. Career paths and professional growth plans should
be established to ensure that these staff members have the means to increase
and hone their skills for the benefit of the organization. These resources are
valuable assets of the organization, and their skills and competency should
be formally recognized so that they can be leveraged across the organization.
Doing so will help to guide others with less training, will help to support
consistency of practices across the organization, and will facilitate institution-
alization of sound data management practices.
Some organizations further articulate this orientation, developing centers of

excellence for data management disciplines (for example, for data quality,
data integration, or data modeling). While centralization is usually accom-
panied by challenges, this approach can provide efficiency gains, consistency
in process execution, and increased product or service quality.

• Data management function documentation
• Data management structure
• Training records
• Compliance or audit reports
• Project reports
• Governance oversight plan
• Communication plans and schedules
• Definition of roles, responsibilities
• Performance measures
Level 4: Measured
4.1 The data management function has defined tasks that are measured and
assessed using statistical and other quantitative techniques.

4.2 Modifications of the data management function and its practices are
based on an analysis of indicators using statistical and other quantitative
techniques.

• Data management structure
• Performance measures
• Record of changes to data management structure
Level 5: Optimized
5.1 The operational plan for the continuous improvement of data management
activities must be prioritized.
5.2 Analysis using statistical and other quantitative techniques as well as the
use of process performance models leverages data to improve operational
efficiency.
At a mature level of data management capability, it is recognized that not

only are data assets of the organization, but they are directly supportive of
the organization’s ability to achieve its strategic objectives. The operational
efficiencies of all activities critical for achievement of organizational goals are
quantitatively measured, and these measures are the preeminent source for
decisions on what changes should be made. Continuous improvements based
on predictive analytics are expected as part of the portfolio of activities used
by the organization to initiate or support change.

• Resource plans
• Priorities aligned with strategy
• Strategic decisions and supporting metrics

Business Case
PURPOSE
Provides a rationale for determining which data management initiatives should be
funded, and ensures the sustainability of data management by making decisions
based on financial considerations and benefits to the organization.
INTRODUCTORY NOTES
The business case is a proposal to fund programs, initiatives, or specific projects. It
describes scope, activities, and expected outcomes and a rationale comprised of a
total cost versus benefits of investment analysis.
The process of developing the business case fosters stakeholder support and
minimizes the tendency for the data management program to devolve into discon-
nected activities.
Business cases may be developed for the entire data management program, for
program elements requiring sustained funding, or for specific data management
projects. They have both strategic and tactical components.
For instance, at the program level, a strategic aspect of the business case recognizes
the need to reduce cross-functional data redundancy. As such, the business case
would address organization-wide challenges, including topics such as why the
organization is focusing on minimizing redundancy, business functions that are
impacted by redundancy, major existing issues that the program will address, etc. The
tactical component of this business case would define how strategic objectives will be
satisfied, including the following:
• Defining related projects within the sequence plan
• Identifying key program deliverables
• Translating progress into metrics
• Determining required staff resources
• Justifying the costs, benefits, and risks
The business case comprises the cost-benefit rationale of data management

activities and deliverables (e.g., risk mitigation, return on investment, strategic
alignment, improved quality, and availability of data assets). At the program level,
it should be strategic in scope, addressing the data assets and the flow of data
supporting business processes performed for acquisition, maintenance, delivery, and
consumption. A business case typically examines risks (financial, operational, and
reputational) incurred by suboptimal management of data assets; operation costs
(e.g., data integration, intangible costs such as operational disruption, and regulatory
drivers); the tangible and intangible benefits expected from the investment in data
management; and alignment with the organization’s strategic plan.
Business Case 31

The data management strategy contains a long-term sequence plan to be accom-
plished over a multi-year period. Most organizations employ a standard business
case template that can be leveraged for the data management business case(s) in
alignment with the sequence plan. The total cost required for implementation and
support of the data management strategy throughout all phases is a critical input into
the program level business case, and its validation and approval ensures that data
management is adequately funded to meet its near- and long-term objectives. The
approved business case is the justification required by Program Funding.
Total cost of ownership (TCO), also referred to as total lifecycle cost, is a method of
discovering and analyzing “cradle to grave” costs of a program, product, or project.
For data management, a TCO analysis would address the objectives, resources,
enhanced capabilities, operational disruption, and other factors via a rational funding
approach accounting for multiple factors with cost implications over time. Although
total lifecycle analysis methods are frequently used for major expenditures and
programs, they are not frequently applied to data management initiatives, as some
costs incurred are often allocated to individual projects, creating a complexity
challenge for assessing an aggregate cost. An example is the accumulation of costs
due to re-architecting the same data sets or interfaces, from project to project.
Two dimensions are addressed in defining the total lifecycle cost: tangible costs,
such as data sourcing, tools, staff resources, IT, and manual reconciliation processes;
and intangible costs, such as data value to the business processes or for achieving
competitive advantage. Intangibles are challenging to quantify; the lack of hard
metrics makes tracing costs through the broad data management scope difficult.
However, TCO provides senior management with a baseline to evaluate achievement of
the program’s objectives over time, and to assess the adequacy of current funding. In
addition, when developing a TCO, it is preferable to utilize existing industry standards
if available, to assist management in benchmarking against peer organizations.
GOALS
1. Obtain executive sponsorship for the data management program.
2. Stakeholders approve and adopt the business case across lines of business.
3. Business cases justify and help to ensure sustainable financing for data
management initiatives.
4. Business cases for data management are comparable to approved business

cases for other organization-wide investments.
CORE QUESTIONS
1. How does the organization determine the level of investment required for the
data management program?
2. How does the organization decide whether to develop one umbrella business
case or multiple, linked business cases?
3. What are the success criteria for the business case?
4. Who needs to be involved? Who needs to approve?
32 Business Case

5. Does the business case reflect the objectives and priorities of the data
management strategy?
6. Does the business case reflect the data management sequence plan?
7. Has the Data Management Strategy sequence plan, supporting the business
case(s), been reviewed and approved by data management sponsors?
8. Does the business case methodology satisfy Program Funding criteria?

Data Lifecycle Management will help to understand the touch-points requiring data
management activities.
Program Funding contains information about ensuring the availability of adequate

and sustainable capital to support the data management program, as well as cost
allocation models required to be tracked, reported, and used for cost comparison and
business case development.
Governance Management and Data Management Function contain information about

organizational responsibilities related to data management.
Data Management Strategy contains information about the scope, priorities, and
objectives of the data management program.
Level 1: Performed
1.1 A business case is developed for project initiatives.
1.2 The benefits and costs of data management are documented and used in
local funding decisions.
Refer to Program Funding, which contains information about ensuring

the availability of adequate and sustainable capital to support the data
management program.

• Project documentation (minutes, discussion documents)
• Project-level business case
Level 2: Managed
2.1 The business case methodology is defined and followed.
Most organizations have produced well-structured business cases for some

key projects within a business unit or for a crosscutting project. These
examples can be leveraged to other areas of the organization as a step in
developing an organization-wide standard approach and method.
Business Case 33

2.2 Standard business cases support approval decisions for funding data
management.
Program Funding contains information about ensuring that adequate

and sustainable financing is committed to support the data management
program.
examples can be leveraged to other areas of the organization as a step in

developing an organization-wide standard approach and method.
2.3 The data management business case for new initiatives aligns with business
objectives and data management objectives.
Business cases should reference and align with business objectives as well
as key data management initiatives to which the project contributes. An
example is an organization focusing on development of a glossary of business
terms. There may be a requirement in the business case for the project to
contribute new or modified terms to the glossary.
Refer to Data Management Strategy for information about the scope, prior-
ities, and objectives of the data management program.

• Business case standard methodology
• Data management business cases initiatives
• Documentation or notes of business case approvals and rejections
Level 3: Defined
3.1 The data management business case is developed according to the organi-
zation’s standard methodology.
3.2 The business case reflects analysis of the data management program’s total
cost of ownership, and allocates cost elements to organizations, programs,
and projects in accordance with the organization’s financial accounting
methods.
Refer to Funding Model, which contains information about ensuring adequate

and sustainable financing for the data management program.
3.3 Data management business cases require executive sponsorship.

Refer to Governance Management and Data Management Function, which
contain information about organizational responsibilities related to data
management, executive involvement, and sponsorship needs.
3.4 Cost factors comprising data management TCO are managed and tracked
across the data management lifecycle.
Data management costs are developed using a standard financial data

collection method, and are consistently gathered across the organization.
34 Business Case

Refer to Data Lifecycle Management, which contains information about data
usage by business processes across the data lifecycle.
The Funding Model provides information about funding and cost allocation
models required to be tracked and reported, and used for cost comparison
and business case development.
3.5 Cost and benefit metrics guide data management priorities.

Metrics are a powerful tool to apply for both minor and major adjustments to
programs and projects. For example, an organization may have staff devoted
to data cleansing for financial reporting. Comprehensive metrics and cost
tracking would show clearly the effort and spend for repeated cleansing
efforts, versus the cost of modifying the source systems to improve data
quality at the source.

• Data management business case(s) are defined and consumed by all
stakeholders
• Approval documentation for data management business cases
• Documentation of data management TCO and methodology
• Cost-benefit analysis results for data management
• Data management business case performance metrics
• Traceability matrix for data management TCO, including relationships and

dependencies
• Standard process to collect information about data management costs
• Cost allocation methodology for data management TCO calculations
Level 4: Measured
4.1 Data management TCO is employed to measure, evaluate, and fund changes
to data management initiatives and infrastructure.
Refer to Program Funding for information about ensuring the availability of

adequate and sustainable capital to support the data management program,
as well as cost allocation models required to be tracked and reported, and
used for cost comparison and business case development.
4.2 Statistical and other quantitative techniques are used to analyze data
management cost metrics to assess data management TCO and collection
methods.
4.3 Data management program performance scorecards include TCO metrics.

4.4 The organization’s data management TCO model is validated, checked for
accuracy, and enhanced through regular reviews and analysis.

• TCO management reports
Business Case 35

• Program change recommendations based on cost metrics
• Infrastructure budgets
• Data management TCO metrics
• Data management TCO methodology documentation
• Data management TCO change recommendations for structure, methods,

and calculations
• Program performance scorecard
• Audit results
Level 5: Optimized
5.1 Statistical results and stakeholder feedback guide continuous improvement

of TCO for data management.
5.2 The organization shares TCO best practices to contribute to industry

maturity through publications or conference sessions.
5.3 Optimization techniques and predictive models are employed to anticipate

results of proposed changes prior to implementation.

• Proposed changes and updates to data management TCO model
• Published industry articles, white papers, conference sessions
• Predictive analysis tools and models
36 Business Case

Program Funding
PURPOSE
Ensure the availability of adequate and sustainable financing to support the data
management program.
INTRODUCTORY NOTES
Program funding processes enable sustainable financial support, based on overall
benefits and costs. In addition, they define the allocation method for distributing
costs among business sponsors and projects, and facilitate stakeholder alignment on
data management funding. Program funding defines the framework used to evaluate
and prioritize business cases (e.g., total cost of ownership, total lifecycle cost, return
on investment) for determining and approving the required financing to sustain data
management.
Program funding must be developed to address requirements from lines of business,

IT, data management function, etc., and communicated to and approved by data
governance to assure oversight and accountability. A well-structured funding
approach can help to foster collaboration and facilitate agreements among stake-
holders.
The organization should consider the advantages of designating a core set of

functions for sustained funding, even if an organization-wide data management
program is not in place. Data management is often funded as a series of projects,
which can be detrimental as there can be discontinuity. For example, an organization
may undertake a data quality pilot project to improve a data set and aid in method
development, tool selection, and defining processes for reuse. If the ongoing activities
resulting from this project are not funded as a part of the ongoing data management
program, the organization will miss the opportunity to extend data quality best
practices to other data stores and lines of business. Just as an organization will always
need human resources and finance, it will always need to manage its data assets,
regardless of changes in strategy or leadership.
The specific model that is implemented to facilitate program funding will depend on
the preferred approach of the organization. Program funding addresses the following:
investment criteria and priorities, budget management, benefits delivered versus
expected, ongoing management, and allocation method. An organization should
expect its program funding method to evolve as the maturity of its data management
program evolves.
GOALS
1. Priorities and criteria for both discretionary and nondiscretionary investment
are established and followed.
2. Sustainable program funding methods for making cost and benefit allocations,
managing expenditures, and establishing priorities are defined and followed.
3. Program funding reflects business objectives and organizational priorities.
Program Funding 37

CORE QUESTIONS
1. Is there an approved set of investment criteria and priorities for data
management?
2. How does data governance provide oversight for data management funding?
3. Was the program funding approach developed, evaluated, and approved by

relevant stakeholders?
4. Does the funding model reflect the organization’s business models, priorities,
and financial decision processes?
5. Are there defined and approved cost-benefit allocation methods, defined

expense management practices, and business cases across the organization?
6. Does the funding model consider all expenses of data management (e.g.,
projects, unique applications, urgent requirements)?

Business Case contains more information on making prudent financial decisions that
will ensure the sustainability of data management.
Data Management Strategy provides information on creating the organization’s vision

and strategy to guide its plans and decisions for managing corporate data assets.
Governance Management and Data Management Function give more information on

the ownership, stewardship, and operational structure developed to understand the
necessary stakeholders to be involved, and the structure necessary that requires
funding.
Level 1: Performed
1.1 Data management projects are funded on the basis of cost-benefit analyses.

• Data management project budgets
• Data management funding approvals
• Funding requests that include cost-benefit analysis
Level 2: Managed
2.1 Data management initiatives are financed based upon funding criteria
addressed by the business case.
Program funding is reviewed based on business cases, their degree of

support for the data management strategy, and other factors. Benefits are
tracked following the completion of the project and used to improve benefit
estimation.
38 Program Funding

Refer to Business Case for more information on making prudent financial
decisions that will ensure the sustainability of data management.
2.2 Stakeholders participate in and support data management program funding.

Refer to Governance Management and Data Management Function for
more information on the ownership, stewardship, and operational structure
developed to understand the necessary stakeholders to be involved, and the
structure necessary that requires funding.
2.3 Data management costs are mapped to business areas, operational

functions, and IT.
Data management costs come from a variety of sources, from data acqui-
sition costs, purchasing licenses to tools, IT system implementation and
maintenance, and staff to manage all the activities.
Refer to Business Case to develop return on investment (ROI) expectations,

as it is necessary to understand the costs of current activities, as well
as where those costs are being incurred, so that value formulas can be
developed. It is only through this mechanism that qualified and quantified
assessments can be made as to the value of the data management activities
and informed decisions made on proposed changes.
2.4 Governance of the funding process is defined and implemented.

• Data management business cases
• Data management program funding method
• Data management budget
• Management reports on mapping of data management costs to the

overall program, business unit, and projects
• Governance documentation related to funding
Level 3: Defined
3.1 Data management program funding aligns with investment decision-making

standards that are consistently employed across the organization.
A standard method for mapping costs and calculating benefits for data
management is established and followed across the organization.
3.2 Program funding priorities align with the objectives and priorities of data
management.
Refer to Data Management Strategy for information related to establishment

of data management priorities and strategic objectives.
3.3 Defined measures determine the effectiveness of program funding with

respect to its objectives and expected benefits.
Program Funding 39

• Data management funding criteria
• Budget planning process
• Metrics to measure investment and funding objectives
• Documented data management funding model
• Reports measuring data management benefits
• Prioritization criteria and mapping to data management strategy
Level 4: Measured
4.1 Metrics are defined and statistically analyzed to evaluate the effectiveness
and accuracy of program funding in meeting organizational objectives.

• Metrics and analysis of program funding effectiveness
Level 5: Optimized
5.1 Lessons learned from organization-wide program funding for data

management are shared with industry peers.
5.2 Optimization techniques and predictive models are employed for analysis
of the anticipated results of proposed modifications to program funding
methods prior to implementation.

• Public presentations or white papers about data management funding
• Approved changes to program funding based on predictive analysis
• Presentations, white papers, articles, etc.
40 Program Funding

Program Funding 41

2 Data 44
Governance
Management
Governance 50 Business Glossary
Metadata
58
Management
42 Data Governance

Data Governance
Best practices for ensuring broad participation in the
practice and senior oversight of the effectiveness of data
management.
The Data Governance category encompasses process areas designed to help an organization
achieve strong participation across the organization for critical decisions affecting the data
assets. It provides best practices for implementing a data governance program and structure
capable of functioning consistently across the broad scope of shared responsibilities;
expanding and managing the organization-wide collection of approved business terms em-
ployed in the target data architecture, taxonomies, and ontologies; and the development and
implementation of metadata to fully describe the organization’s data assets.
In addition to building data management functions, governance may include the manage-
ment of external or regulatory requirements, and external shareholders with an interest
in data management activities and outcomes. More generally, governance also includes
monitoring data management results to ensure that the organization receives the desired
outcomes and business value from data management activities.
Governance Management addresses the processes that facilitate collaborative decision

making and effectively implement the building, sustaining, and compliance functions of
governance bodies. Business Glossary practices help an organization to achieve a common
understanding and representation of an expanding compendium of approved business terms,
prioritize and sequence its development, and manage term creation and changes over time.
Metadata Management provides a top-down approach to architecting, planning, populating,
and managing the metadata repository to fully describe the organization’s data assets.
Maturity of the practices within this category will create a corporate culture of shared
responsibility for the data assets. Maturity enables improved data quality, supports data
integration, facilitates the design and implementation of the target data architecture, and
helps the organization to develop a thorough and detailed knowledge of the as-is data layer
and the lineage of data through business processes, data stores, and systems.
Data Governance 43

Governance Management
PURPOSE
Develop the ownership, stewardship, and operational structure needed to ensure that
corporate data is managed as a critical asset and implemented in an effective and
sustainable manner.
INTRODUCTORY NOTES
Effective data governance management provides oversight, ensures stakeholder
collaboration, and facilitates decisions for critical data subject areas. Data governance
management addresses three basic data governance functions supporting the organi-
zation’s data assets: building, sustaining, and compliance. Building is the creation
of new capabilities through the new or enhanced governance structures; sustaining
consists of the processes for collaboration, evaluation, and decision making; and
compliance is instituted and managed to control data assets.
The data governance structure is designed to correlate with the organizational

hierarchy and its culture. Key functions for data governance include the following:
• Approve the enterprise data strategy, policies, and standards
• Define business terms by subject area
• Assign accountabilities and responsibilities
• Develop decision rights and change mechanisms
• Address regulatory and other external requirements, data security, and access
• Enforce compliance
Data governance is customized to best address these functions for the organization.
For example, an executive governance body may be charged with oversight for
the interconnections that must be established among business, technology, and
operations regarding the data assets within scope. A committee of data stewards may
be created to oversee subject areas, define priorities, and minimize conflicts. Data
working groups may be formed to develop the metrics and milestones for the data
management program. Tactical work groups may be formed from, or at the direction
of, governance bodies to perform a variety of tasks, such as to assure the quality of
critical data attributes, to perform business analysis, to interface with information
architects, and to triage and resolve business challenges with data.
The data governance function may begin by focusing on a small set of business
domains, but it typically expands over time to include additional subject areas and
responsibilities. Master data governance is often an initial focus for developing an
overall enterprise data governance capability, as it requires collaboration from multiple
business areas. To implement governance successfully, the organization needs to
develop a deployment plan to ensure that governance, program funding, and data
management oversight will be rolled out smoothly in the business environment. Key
factors for a successful implementation of data governance include the following:
44 Governance Management

• An approved governance charter(s)
• Executive oversight, governance policies, and objectives
• Clearly defined roles and responsibilities
• Well-designed supporting processes, such as issue resolution, change

management, etc.
GOALS
1. A process is established and followed for aligning data governance with
business priorities, including ongoing evaluation and refinement to address
changes in the business such as the need to encompass new functions and
domains.
2. Data governance ensures that all relevant stakeholders are included, and that
roles, responsibilities, and authorities are clearly defined and established.
3. Compliance and control mechanisms with appropriate policies, processes, and

standards are established and followed.
CORE QUESTIONS
1. Does data governance provide mechanisms to facilitate collaboration and
decision making across lines of business and IT functions?
2. Does the data governance structure clearly delineate defined responsibilities

and accountability for data domains?
3. How does the organization define roles and responsibilities and ensure that all
relevant stakeholders are involved?
4. Does data governance provide a mechanism for definition of priorities and

resolution of competing priorities?
5. Does data governance effectively provide a process for defining, escalating,

and resolving issues?
6. How does the executive sponsor(s) of data governance actively support the
effort?
7. How are executive sponsor(s) informed of data governance efforts?
8. Has the organization instituted an effective compliance program across the

data lifecycle?
9. Does the organization have a process in place to review the governance

structure and activities?
10. Is there appropriate training in place for staff involved in data governance?
11. What is the compliance process to carry out the decisions of the data
governance body?

Data Lifecycle Management provides information about all business processes in the
organization that require data management activities. This information is used to help
identify the data governance management needs.
Data Management Strategy provides guidance on development of data management

priorities and strategy, which are used to help define the scope of data governance.
Data Management Function provides details on roles and responsibilities related to

data management, as well as the business areas that they support.
Communications provides guidance on effective communications to support the

implementation and management of data governance.
Level 1: Performed
1.1 Data governance functions are performed.
Governance often begins as project-based, aligned with development and

operation of application data stores; for example, validation of logical and
physical data models.
1.2 Ownership, stewardship, and accountability for data sets are primarily
project-based assignments.

• Governance process documentation
• Evidence of implemented governance processes
• Description of data governance roles and responsibilities
Level 2: Managed
2.1 A defined and documented data governance structure is in place.

Data Lifecycle Management provides information about the business
processes in the organization that deal with data management activities. This
information is used to help identify the data governance management needs.
Data Management Strategy provides guidance on development of data

management priorities and strategy, which is used to help define the scope of
data governance.
2.2 Governance roles, responsibilities, and accountabilities are established for

data subject area by priority, as stated in the business or data strategy.
2.3 Data subject area representatives participate in data governance and

associated processes.
Data Management Function provides details on roles and responsibilities

related to data management.

2.4 Data governance follows defined policies, processes, and standards.
2.5 A review process is established and followed to evaluate and improve data
governance.

• Data governance charter
• Data governance policy
• Documented data governance processes and standards, including the

decision process, issue resolution, and operations
• Roles, responsibilities, and accountability matrix
• Governance body meeting minutes
Level 3: Defined
3.1 An organization-wide data governance structure and rollout plan is estab-

lished with executive sponsorship.
Standard conflict and issue resolution processes for data governance are
developed and adopted across the organization.
The data governance charter(s) and operational rules establish the method
for resolving conflicts and the criteria for escalation.
Refer to Communications, which provides guidance on effective communica-

tions to support governance implementation and management.
3.2 Executive level organization-wide data governance is operational for the

organization’s high-priority subject areas.
Data governance is responsible for managing governance execution and

providing liaison among business owners, data stewards, and IT.
3.3 Data governance includes representatives from all business units, which are
suppliers or consumers of high-priority data subject areas.
Governance roles, responsibilities, and accountability are established for

subject areas at the organization level.
3.4 Standard data governance policies and processes are followed.

Data governance decisions, policies, and processes are communicated across
the organization.
Data compliance processes and corresponding data governance roles are

established and enforced organization-wide. The organization should have
specified data governance activity categories and decision authorities by
governance body level. For example, major changes to data standards should
be reviewed and approved by the executive data governance council, as they
have a long-term effect on the target data architecture.
3.5 Data governance determines and approves appropriate metrics to evaluate

effectiveness of governance activities.

Approved data governance metrics measure the progress and expansion of
governance activities and accomplishments, and alignment with the organiza-
tion’s business objectives. Corrective action is taken when metrics are out of
alignment or indicate insufficient progress against business objectives.
3.6 An evaluation process is established for refining data governance to align

with changing business priorities and to expand as needed to encompass
new functions and domains.
Data governance adjusts its activities affected by modification or addition

of new business processes and data, new regulatory rules, or new internal
compliance requirements. It is important to ensure consistent accountability
within the organization as it grows, changes, and evolves.
3.7 Classroom, mentoring, e-learning, or on-the-job training in data governance

processes is required for new governance members and other stakeholders.
Data governance bodies determine what type of training is needed for each
role for new members.
3.8 Data governance activities and results are analyzed against objectives
periodically and reported to executive management.

• An executive-level data governance charter
• A organization-wide data governance rollout plan
• Metrics to evaluate data governance effectiveness
• Evidence of the adoption of data governance policies and processes
• Data governance training materials
• Governance meeting minutes
• Reports of decisions and action items
Level 4: Measured
4.1 Statistical and other quantitative techniques are applied to determine if

governance efforts are changing organizational behaviors appropriately.
4.2 Adjustments to data governance activities and structure are made based on
analysis results.

• Metrics-based analytical performance reports
• Executive reports of governance effectiveness
Level 5: Optimized
5.1 External governance structures and industry case studies are evaluated for
best practices and lessons learned, providing ideas for improvements.

5.2 The data governance structure is communicated to the peer industry as a
model of best practice.
5.3 Data governance processes are continually refined and improved.

• Internal presentations or white papers referencing the data governance
model as an industry best practice
• Reports evidencing continual governance improvements

Business Glossary
PURPOSE
Supports a common understanding of terms and definitions about structured and
unstructured data supporting business processes for all stakeholders.
INTRODUCTORY NOTES
The business glossary is an approved, governed compendium of business term names
and definitions. The process defines how the organization creates, approves, updates,
and promulgates consistent business terms and definitions, fostering shared data
usage across the organization. Consistent terms and definitions, with corresponding
metadata, are essential to managing corporate data in the context of meaning.
The business glossary provides a stable foundation for understanding and integrating
data across the organization. The goal of the business data glossary is to ensure that
each term refers to a specific, atomic fact without ambiguity or duplication. This
enables a broad range of important data management functions and accomplish-
ments, which include the following:
• Data quality
• Target data architecture and shared data repositories
• Enterprise data warehouse
• Content management
• Consolidation of data stores
• Custom-to-COTS migrations
• Business process automation
• Risk analysis
The business glossary is the core of the organization’s data infrastructure. Although it
is simple in concept, it can be a significant challenge to define, reconcile, harmonize,
qualify, approve, and maintain shared business terminology. Consistent business
meaning is important, although not always obvious to the lines of business within an
organization, because distinctions between business terms employed by a business
unit, versus an organization-wide perspective, are not typically well defined or
documented. In addition, terms used by multiple business units often have connotative
meanings that must be explored, rationalized, and decided upon through agreements.
An approved standard business glossary underlies effective transition to the target

data architecture. Without it, re-architecting, consolidation, and effective sharing of
corporate data assets will be slower, more complex, and more costly. Development
of new data stores, consolidations, and redesigns are often driven by events, which
frequently results in ad hoc naming and definitions of business terms that are then
instantiated as logical attributes and physical data elements. Each time this scenario
occurs, another obstacle to creating and building a corporate body of approved
standard terms is created, and it inevitably results in future rework.
50 Business Glossary

Within the corporate data layer, consistent approved business terms are also a
cornerstone for improving the organization’s data interfaces, which are usually
plagued with different names and representations for the same atomic fact, resulting
in a high steady-state cost burden. Similarly, consistent business terms and definitions
are critical to enable data integration, aggregation, accurate analytics, trend and
predictive analysis, semantic modeling, taxonomies, and ontologies.
The broad scope of this activity—to achieve a comprehensive compendium of business

terms that is understood and applied across all applications, systems, and processes—
requires a policy mandate from executive management, emphasizing the importance
of establishing and controlling data consistency. Projects may try to circumvent
adoption of approved terms, to accomplish short-term objectives. Strong governance
(supported by compliance enforcement) is essential to intercept implementation
efforts early to ensure that the organizational policy is followed.
It is critical to develop a defined process by which business terms and their corre-
sponding definitions are created, updated, maintained, and promulgated. Management
of the organization’s business glossary requires adopting the view that synthesis of
meaning is essential for long-term data management success. Because reconciliation
of data names, definitions, allowed values, and other associated metadata cuts across
existing systems, it is advisable to align the sequence with the priorities established in
the data management strategy.
How best to sequence and prioritize portions of the glossary depends upon the nature
of the initiative. Data warehousing projects (e.g., designing and building an opera-
tional data store) tend to sequence and prioritize sets of data defined by subject area
(e.g., transactions, products, customers, etc.). The data needed to perform business
processes, for applications and business intelligence purposes, frequently extends
horizontally across subject areas. Ideally, once the organization has mandated the
goal of building out a full and comprehensive business glossary, progress is achieved
through multiple avenues: top-down, fed by multiple glossaries maintained by the
lines of business; by leveraging major initiatives; and bottom-up, by harvesting data
models or database scripts.
Establishing standards for business terms, including naming conventions, abbrevi-

ations, standard definition representations, and standard metadata, provides the
foundation for representing consistent meaning across the organization. These
standards should be applied through data governance, and corresponding approval
and change processes should be developed, followed, and maintained. A proper
communication or feedback loop should be instantiated to ensure that changes and
recommendations within the business process are properly communicated to ensure
accuracy within the glossary.
GOALS
1. The language that represents the data is unambiguously aligned with the
language of the business.
2. The organization has created a comprehensive, approved business glossary.

3. The organization follows the standards for naming, definitions, and metadata
associated with business terms.
4. Organization-wide access to the business glossary allows all stakeholders to

achieve a common understanding of standard business terms.
5. Data governance facilitates the review, approval, and consistent usage of

business terms.
6. A compliance and enforcement process ensures consistent application of

business terms as new data requirements and projects arise.
7. The organization has a communication plan and process in place for

continuous feedback on the usefulness of the glossary to data users and other
stakeholders.
CORE QUESTIONS
1. Is there a policy mandating use of and reference to the business glossary?
2. How are organization-wide business terms, definitions, and corresponding

metadata created, approved, verified, and managed?
3. Is the business glossary promulgated and made accessible to all stakeholders?
4. Are business terms referenced as the first step in the design of application
data stores and repositories?
5. Does the organization perform cross-referencing and mapping of busi-

ness-specific terms (synonyms, business unit glossaries, logical attributes,
physical data elements, etc.) to standardized business terms?
6. How is the organization’s business glossary enhanced and maintained to

reflect changes and additions?
7. What role does data governance perform in creating, approving, managing,

and updating business terms?
8. Is a compliance process implemented to ensure that business units and

projects are correctly applying business terms?
9. Does the organization employ a defined process for stakeholders to provide

feedback about business terms?

Data Lifecycle Management helps to identify all the current activities associated with
data management to aid in development and management of the business glossary.
Metadata Management will help to identify which data is used for what purposes, as
well as identify what systems and models are using the data.

Level 1: Performed
1.1 Business terms are defined for a particular purpose.
Business term definitions may be needed for a development project or an

external publication.
Business terms may be defined within development project documentation.

Partial glossaries may exist but within a line of business; glossaries developed
for a business area may contain terms that may conflict with or overlap with
terms and definitions used by another business area.
Refer to Data Lifecycle Management, which will assist in identifying all the
data management activities to help develop awareness of terms and business
needs across the organization.
1.2 Logical data models are created with reference to defined and approved
business terms.
When standard approved business terms exist, they should be referenced to

derive attribute names. This practice prevents the creation of nonstandard
terms by each project effort, and is implemented in physical data stores,
project by project, and supports the objective of clarifying and improving
business usage versus adding complexity. Business terms are the basis for
facts (attributes) about an entity, although naming conventions and database
design practices may result in altered naming (for example, the standard
industry practice of ending each attribute name with a class word). For
example, a business term describing a pension plan may be “Date of Plan
Origination”; the corresponding logical name may be “Plan Origination Date.”
Refer to Metadata Management, which will help to identify which data is used
for what purposes, as well as identify what systems and models are using the
data.

• Defined business terms in project documentation
• Business glossary maintained by a business unit
• Business term and logical attribute mapping.
Level 2: Managed
2.1 A process is established, documented, and followed to define, manage, use,

and maintain the business glossary.
Creating the business terms process involves input from stakeholders, data
governance, and business unit experts with the data management function
taking the lead, sponsored by a senior executive. This will facilitate sustained
participation among the multiple business units, establish shared goals and
objectives, and foster agreement on the desired outcome and corresponding
timeline.

Collective input and collaborative decisions are also needed to develop
standards for terms, definitions, and metadata. For example, new initiatives
should apply standard business terms as part of the data requirements
definition process to ensure consistency of language so comparability of
the content can be achieved, and data sharing is facilitated across the
organization. Likewise, business glossary updates should come from the
organization at large, managed through data governance.
Capturing and maintaining metadata about business terms is foundational

for tracking and managing progress of the business glossary. Examples of
metadata for business terms include the following:
• Term name
• Definition
• Alternative forms (synonyms, logical, physical, etc.)
• Business term details (e.g., status, security classification, creation date,

etc.)
• Governance (e.g., level, owner, etc.)
• Usage (e.g., system of record, valid values, etc.)
2.2 Standard business terms are readily available and promulgated to relevant
stakeholders.
As business terms are created and approved, they should be published and
promoted. Examples include email announcements of releases, and notifi-
cation via the corporate portal, at a reasonable frequency. This is important
for change management success. The organization may elect to roll out the
process in phases, for example, by business unit for major upcoming devel-
opment efforts, etc.
Refer to Data Lifecycle Management, which helps to identify all the current
activities associated with data management to aid in development and
management of the business glossary.
Refer to Communications, which defines a process for promulgating the

standard business terms.
2.3 Each business term added to the business glossary has a unique name and
unique definition.
When terms are developed from a “base term” (e.g., “Trade Price” or “Product
Name”), one or more qualifying words may be added, such as “Last Trade
Price” or “Short Product Name,” with a corresponding unique definition. The
qualifying words and the modification to the base term definition should be
approved by data governance. Where there is a prevailing industry standard
to which the organization must adhere, business terms and definitions should
be validated against authoritative sources.

2.4 New development, data integration, and data consolidation efforts apply
standard business terms as part of the data requirements definition process.
The business terms process should include compliance process steps. In

essence, this is embedding the criticality of business glossary reference into
the development lifecycle. Tailoring guidance should also be created for the
process (for example, the organization may choose to exempt local data
stores or data stores with a limited user base).
Governance Management and the Data Management Function support this

practice by establishing and managing the oversight necessary to ensure that
projects are monitored for compliance with the standard business glossary.

• Business glossary
• Business glossary policy
• Business term glossary management process
• Business glossary available online
• Business glossary compliance process
• Data requirements documentation utilizing business terms
Level 3: Defined
3.1 The organization uses the approved business glossary in the development of
shared repositories, data transfer standards (e.g., XML), ontologies, semantic
models, and similar initiatives involving corporate data.
3.2 Organization-wide data governance for compliance with the business

glossary process is implemented and followed.
While the organization may initiate the standardization effort for one
business unit, subject area, or major project, the full value of adhering to this
process will be realized over time as it is consistently applied in appropriate
phases. Application of resources to compliance monitoring within the devel-
opment lifecycle is required.
3.3 The organization has implemented a mechanism to facilitate transformation

by mapping between business terms, attributes, and physical data element
names or synonyms.
This capability may be implemented in phases, employing an enabling

technology such as a metadata repository or a custom database. For
maximum utility, the enabling technology should make it easy for stake-
holders to view and search business glossary content.
Data Lifecycle Management helps to identify all the current activities

associated with data management to aid in development and management of
the business glossary.

3.4 Impact assessments are conducted, and governance approval is obtained,
prior to implementing changes to business terms.
3.5 Metrics are captured and used to evaluate the organization’s progress
toward a comprehensive business glossary.
Metrics are not only a gauge of progress for meeting objectives and
timelines, but help to maintain enthusiasm among the many participants in
the sustained glossary development effort.
3.6 Compliance monitoring processes are used to verify correct use of business
terms, highlight exceptions, and ensure they are addressed.
Compliance reports are input to remediation plans for noncompliant and

exception terms. Remediation plans may coincide with a scheduled release.
For business terms considered critical to the organization (for example, for
a shared repository, an important standard report, a regulatory requirement,
etc.), a release may be planned specifically to address this issue. Exception
reports are made available to all stakeholders, including corresponding
impact analysis and planned remediation activities.

• Business terms glossary
• Mapping mechanism tracing business terms to attributes to physical data

elements
• Business terms compliance process
• Policy mandating use of standard business terms
• Implemented mechanism to store and map business terms
• Compliance monitoring indicating results against the business terms

process and business terms standards
• Impact assessment results
• Business terms metrics showing progress against targets
• Business terms noncompliance and exceptions report
• Business glossary update log
Level 4: Measured
4.1 Statistical and other quantitative techniques are used to manage the process
and develop reporting and projections on business glossary integration for
senior management.
4.2 The business glossary is integrated into the organization’s metadata repos-
itory with appropriate access permissions.
4.3 The business glossary uses standard industry business terms and definitions
as appropriate.

• Metadata repository providing a unified business terms glossary
integrated with logical and physical data representations and references
to industry standards
• Metrics and analysis reports
• Published exception reports, impact analyses, and remediation plans
Level 5: Optimized
5.1 The business glossary is enhanced to contain associated business rules and
ontology structures, and is consistent throughout the organization.
5.2 Optimization techniques are employed to improve the process of developing

taxonomies, ontologies, or semantic representations leveraging the business
glossary.
5.3 The organization publishes white papers and case studies addressing
effective management of business terms.

• Business rules and ontologies associated to business terms in automated
mechanism
• White papers and case studies

Metadata Management
PURPOSE
Establish the processes and infrastructure for specifying and extending clear and
organized information about the structured and unstructured data assets under
management, fostering and supporting data sharing, ensuring compliant use of data,
improving responsiveness to business changes, and reducing data-related risks.
INTRODUCTORY NOTES
Metadata is a category of information that identifies, describes, explains, and provides
content, context, structure, and classifications pertaining to an organization’s data
assets and enables effective retrieval, usage, and management of these assets.
The metadata developed by an organization is the mechanism allowing data

asset knowledge to be established and enhanced over time. Effective metadata
management and the creation of the organization’s metadata catalog facilitates,
supports, and contributes to achievement of critical data management activities and
objectives, which include the following:
• Data architecture
• Data requirements
• Data lineage
• Data lifecycle management
• Historical data
• Records retention
• Data archiving
• Data integration
• Data provenance
• Data standards.
Metadata contains three categories:
Business Metadata: Descriptive information used to understand, search, locate, and

control content that can include elements such as terms, definitions, values, authors,
keywords, and publishers. Business metadata may also include business domains,
related subject areas, business rules, and data quality rules, all of which should be
developed for the business glossary. Business metadata is the foundation for mapping
to related metadata artifacts such as taxonomies, ontologies, business glossaries, and
standards.
Technical Metadata: Describes data assets instantiated in the physical data layer as
well as their transformations through automated processes. It describes the content
and location of data stores and interfaces, including information about tables, field
structures, data types, columns, links to related files, indexes, etc. Technical metadata
58 Metadata Management

consists of the following subcategories: 1) run-time or dynamic metadata (examples
include configuration information, messaging, and XML) and 2) design-time or static
metadata (examples include physical data models, DDL, data dictionary, and ETL
scripts).
Operational Metadata: Provides administrative information to manage a data asset

and includes information such as when it was created; the file type; purpose of the
data; information needed for archival, integration, and update of schedules; and
access rights and entitlement restrictions. The administrative metadata related
to governance and stewardship is included under Operational Metadata. This is
descriptive information used to understand the roles of the individuals involved in
governing the data. It identifies governance bodies and their scope, process, partic-
ipants, structure, and responsibilities; and is used to manage change to all types of
metadata. In addition, operational metadata is used for process improvements to
enhance productivity and improve data quality.
Process metadata, a subcategory of operational metadata, addresses process steps

for production and maintenance, as well as for data quality measurement and analysis.
Business rules; names of relevant systems, jobs, and programs; as well as gover-
nance and regulatory roles and other control requirements are examples of process
metadata.
GOALS
1. Senior managers appreciate the value of metadata because it is expressed in a
language they can understand.
2. Data governance oversight directs the development and implementation of

the metadata strategy, categorizations, and standards, as well as ensures
adoption and consistent use across the organization.
3. The contents of the metadata repository span all relevant categories and
classifications of data assets under management, and accurately reflect the
implemented data layer of the organization.
4. Internal and selected external standards of importance to the organization are

incorporated into metadata and aligned with organizational processes and
standards.
CORE QUESTIONS
1. Is the metadata strategy defined and aligned with internal and selected
external standards?
2. How is the scope of metadata to be addressed for inclusion within the

metadata repository defined?
3. Are all relevant stakeholders involved in defining metadata categories and

properties?
4. What is the method for developing and evaluating standards and processes
for metadata management?

5. What is the method for maintaining or updating the metadata repository?
6. Are metadata management processes defined and followed?
7. Are roles and responsibilities clearly defined for the capture, updating, and
use of metadata?

Governance Management provides information about data governance structures and
roles.
Data Management Function provides information related to the roles of data

management staff in developing and supporting metadata management.
Data Management Lifecycle gives more information related to interdependencies.
Data Requirements Definition contains information about developing data require-

ments with corresponding metadata.
Architectural Approach provides information about activities associated with data

platform architecture.
Business Glossary contains information about developing a shared and approved

organization vocabulary and corresponding metadata.
Data Integration gives information about generating and managing data mapping and
transformation metadata.
Level 1: Performed
1.1 Metadata documentation is developed, stored, and accessible.
An organization typically maintains information about data assets in multiple

locations for different purposes. Metadata may be captured and stored
in data models, project documentation, operational documentation, or in
business term lists. Collectively, these sources constitute a virtual metadata
repository. Organizations should identify sources of existing metadata;
evaluate their completeness, categorization, and properties; and plan to
consolidate and enhance into a cohesive meta-model reflecting their needs.
As an example of existing metadata assets which may be leveraged, sources

based on data models typically include the following items:
• Entity type name
• Attribute name
• Table name
• Column name
• Data type

• Length
• Allowed values
• Default values
• Mandatory/Optional indicator
• Data definitions for entity types, attributes, tables, and columns

• Metadata repository or virtual metadata repository (multiple sources)
Level 2: Managed
2.1 A metadata management process is established and followed.

An organization will benefit from defining a standard process for performing
major steps in the metadata lifecycle (i.e., create, update, and delete). The
process usually involves the following:
• Identification of relevant stakeholders and their roles
• Definition of data concepts, approved by the business
• Determination of required metadata components and categories
• Selection or building of a common repository for storage, maintenance,

and retrieval
• Configuration management and maintenance rules and criteria
Business stakeholder involvement ensures that metadata clearly describes

information required for end users and supports the performance of critical
processes in the data lifecycle, such as:
• Data sourcing
• Data movement
• Targeting and classification
• Usage (e.g., for reporting and within the system development life cycle—
SDLC)
• Governance and control
2.2 Metadata documentation captures data interdependencies.

It is important for the organization to determine the core set of metadata
categories across the business, technical, and operational landscape to
enable traceability from the sources of data to the target repositories.
The Data Management Lifecycle will help to identify where data is used and
changed. This information helps to provide a source of information related to
interdependencies.
Organizations often lack sufficient metadata to construct a data lineage,

which typically includes the following:

• Data sources
• Designation of authoritative or preferred sources
• Applied transformations or aggregations
• Data destinations
• Integration mappings at the data element level showing how sources

were combined when integrated
• When new data were received
• When data were changed, etc
For example, for a report provided to a regulatory organization, an organi-

zation may need to trace the origin of the data from all sources through
any transformations, calculations, or aggregations applied from multiple
processes, end to end. This provides a complete audit trail for exactly
what the data were, how they were changed, and how they were used in
the report. When data lineage is pieced together for a specific need, it is a
time-consuming process that may be repeated in multiple contexts across the
organization. The development of robust end-to-end metadata simplifies this
process and facilitates its automation.
2.3 Metadata is developed and used to perform impact analysis on potential

data changes.
Assessing the impact of data changes requires knowledge of the extent

of its use within the organization (i.e., by stakeholders, in application data
stores, the data warehouse environment, etc.). In addition to metadata
that describes the data content, it is necessary to document the systems
and stakeholders associated with each data set in the repository (through
production, maintenance, and consumption). This may have an initial scope
by data set, but the eventual objective is to achieve mapping at the attribute
and column level. For example, when the business adds a new value to a
highly shared type code (e.g., organization type), multiple data stores may
need to modify their structures.
2.4 Metadata categories, properties, and standards are established and

followed.
For each major classification of metadata (e.g., business, technical), the

organization should propose and approve a set of categories (e.g., business
terms, databases), and a set of corresponding properties (e.g., data steward,
update date) for each category. Conventions for each metadata element
representation should be specified. These decisions should be codified in a
metadata standard(s) which is published, implemented, and followed.
Refer to Business Glossary, which provides more information about

documenting and maintaining information about data categories and other
metadata terms, etc.

• Metadata management policy

• Business metadata
• Metadata repository(ies)
• Metadata Meta Model
• Metadata governance and publication approval documentation (including

business and technical stakeholders)
• Metadata standards
• Audit results
• Metadata change log
Level 3: Defined
3.1 A metadata management strategy for the organization is established,

promulgated, and maintained by data governance with input from relevant
stakeholders.
Development of a comprehensive, complete, and well-organized metadata

repository evolves over time. Similar to the recommended approach for the
organization’s data quality program, the organization is advised to develop
a strategy—to collaborate on a top-down vision, goals, objectives, and to
develop a roadmap for requirements, design, and development (or platform
deployment)—which includes a phased implementation plan that accommo-
dates dependencies and reconciles sequencing conflicts.
The metadata management strategy should address the following topics:

• The organization’s shared vision for metadata management
• Stakeholder roles and responsibilities
• Metadata attributes (extent, categories, properties, usage, etc.)
• Conceptual metamodel for the metadata assets
• Data governance roles and responsibilities for metadata creation and

changes
• Compliance program for metadata management
• Sequence plan for guiding implementation
As systems become more integrated and coupled, and often include external
systems where dependencies are based on contract, it’s important that
the metadata strategy addresses all of these data sources and related
exchange standards. Adoption of externally accepted industry standards, as
appropriate, helps to mitigate internal differences and to increase the organi-
zation’s interoperability with customers and clients, peers, and regulatory
bodies.
Data Requirements Definition provides more information about developing

data requirements with corresponding metadata.

3.2 The organization’s metadata repository is populated with additional
categories and classifications of metadata according to a phased implemen-
tation plan, and is linked to architecture layers.
The metadata repository may be built internally or purchased from third-

party vendors depending on the scope of requirements; in practice, it is
usually preferable to buy rather than build, due to the cost of feature devel-
opment versus feature purchase. Typical enhancements to the repository are
subject to business priorities, the sequence plan, and available resources.
The initial meta-model is enhanced and extended with model modifications
to reflect increasing completeness. The following elements often comprise
metadata expansion or extensions:
• Data quality rules including rules related to source authenticity and
provenance rules
• Business rules
• Extensible classifications (added by the organization)
• Distinction between organizational and line of business classifications
• Authoritative data sources (trusted sources)
• Data steward assignment to business terms
• Data custodian assignments to physical data objects
• Process metadata including transformation logic (e.g., ETL)
• Linkage of the following architecture layers for data at rest:
–– Business glossary
–– Enterprise logical data model
–– Logical data model
–– Physical data model
–– Database schem
–– BI layer
• Physical data lineage (sources-transformations-targets)
• Metadata history and versioning (enables audit and change control)
3.3 The data management function centralizes metadata management efforts

and is overseen by data governance.
Metadata efforts include categorizations, properties, and standards; and

organization-wide implementation.
Metadata differs from data as the range of issues is broader, more technical,
and relates to other topics that are not usually part of the normal data
lifecycle processes. Metadata is more highly impacted by projects, and its
scope and depth make it challenging from a data governance perspective.
Notwithstanding the important difference between establishing versus
maintaining metadata, aligning project-based metadata into an overall data

governance activity is an important achievement, especially critical for master
data management, data warehousing, and metadata repository implemen-
tation initiatives.
Due to the range and extent of metadata throughout the business and
technology environment, roles and responsibilities will involve many staff
in multiple areas. It is usually best to assign the data management function
to lead and drive the collaborative effort, and to fully inform and obtain
approval from stakeholders, as a number of their staff members will need to
devote time to the effort. Data governance, with representatives from across
the organization, can address final approvals and ensure agreements.
Refer to Governance Management and Data Management Function, which

provide more information about data governance structures and roles, and
data management staff responsibilities.
3.4 Data governance approves metadata additions and changes.

Once a category of metadata has been released to the repository, additions
or changes to scope, categories, properties, and standards
should be managed by data governance and communicated across the

organization.
3.5 Measures and metrics are used to evaluate the accuracy and adoption of
metadata.
Key metrics and achievement targets should be identified in the metadata

strategy. These can be further refined as the metadata assets are extended
and expended.
Metrics define what needs to be tracked (and inherently convey why it is

important); examples include the following:
• The value of metadata management (link to cost containment, operating
efficiency, process effectiveness)
• The performance of key processes and procedures; for example, the

frequency of use per attribute, how many data stores per attribute, how
many applications per attribute
• The criticality of data attributes to applications (which are core, for

what process, used in which application, included in which calculation
processes)
• The costs associated with the movement of data across the lifecycle (and
how much is at risk), especially if the lineage is fragmented
• Tracking progress toward a single authoritative source
• The quality of metadata breadth, depth, scope, availability, timeliness,

accuracy, duplication, conformity, linkages, and clarity
3.6 Metadata, and any changes to metadata, are validated against the existing
architecture.

For example, information about physical models, interface specifications, ETL
scripts, data provisioning services, etc. should be validated to ensure that it
correctly describes the existing environment.
Refer to Architectural Approach for more information about activities

associated with data platform architecture.

• Metadata management strategy
• Metadata roles and responsibilities
• Repository reports of metadata extensions
• Metadata management organization standards
• Metadata meta-model diagrams
• Gap analysis results comparing implemented platforms against metadata
• Metadata metrics reports (adoption, percent complete, etc.)
• Metadata sequence plan milestone and progress reports
Level 4: Measured
4.1 The organization has developed an integrated meta-model deployed across

all platforms.
4.2 Metadata types and data definitions support consistent import, subscription,
and consumption practices.
Refer to Data Integration for information about generating and managing data
mapping and transformation metadata.
4.3 The metadata repository extensions include exchange data representation

standards used by the organization.
Examples of exchange data representation standards are XML and XBRL.
4.4 New metadata management activities are guided by metadata metrics and
historical information about metadata.
4.5 Quantitative objectives guide metadata management and support process

performance.
4.6 Statistical analysis reports for process, reporting, and performance are
included in the metadata repository and employed to support fact-based
decision making for new metadata management initiatives.

• Documented quantitative objectives for metadata
• Documentation of measurement approaches to include the statistical and

other quantitative techniques applied, and the performance thresholds
• Comprehensive metadata repository reports including history

• Metadata process efficiency reports
• Unified or integrated meta-model
• Metadata standards captured in meta-model
• Documentation of uniform practices for import, consumption, and

subscriptions of data
• Documentation of standards followed for exchange data representation
• Reports of statistical results
Level 5: Optimized
5.1 Root cause analysis is conducted to reduce the variations between the
repository information and the data it describes.
5.2 Performance prediction models guide changes in metadata management

processes.
5.3 Quantitative metadata improvement objectives are derived from the

metadata strategy.
5.4 Planned data changes are evaluated for impact on the metadata repository;
and metadata capture, change, and refinement processes are continuously
improved.

• Evidence of consistent and reporting based on standard definitions
• Results of analysis of repository information against the data it describes
• Documentation on prediction models
• Define quantitative objectives
• Impact analysis reports

3 Data Quality 70
Data Quality
Strategy
77 Data Profiling
Data Quality
84
Assessment
90 Data Cleansing
68 Data Quality

Data Quality
Best practices for defining and implementing a
collaborative approach for detecting, assessing, and
cleansing data defects to ensure fitness for intended uses
in business operations, decision making, and planning.
The Data Quality category encompasses process areas designed to provide the means for
an organization to fully understand the nature and quality of the data under management,
as well as mechanisms to evaluate, prevent, and remediate defects, to assure that the quality
of data meets business purposes and the organization’s strategic objectives. In short, these
process areas collectively describe a comprehensive data quality program, driven by a data
quality strategy.
The Data Quality Strategy is foundational to all data quality management activities. It
describes activities designed to help the organization develop a defined, approved integrated
plan to ensure that the quality of data meets business needs. Data Profiling and Data Quality
Assessment contain activities that help the organization assess the data under management
against a set of quality objectives, which are defined in the Data Quality Strategy. Achieving
efficiencies and successful, repeatable processes for Data Cleansing activities reduces effort
and lowers costs, enabling the organization to assure “fit for purpose” data assets across its
data sets and physical data stores.
Maturity of the practices described in this category will help to translate business goals and
priorities into actionable plans designed to execute as an organization-wide program to
actively manage data across all dimensions of quality. This enables the organization to realize
maximum value from its data assets and to capitalize on opportunities that require accurate,
trusted data.
Data Quality 69

Data Quality Strategy
PURPOSE
Defines an integrated, organization-wide strategy to achieve and maintain the level of
data quality required to support the business goals and objectives.
INTRODUCTORY NOTES
Data quality strategy defines the goals, objectives, and plans for inproving data
integrity. It is the blueprint used to inculcate a perspective of shared responsibility
for the quality of data. The data quality strategy should address the following items:
meaning; data store design (e.g., referential integrity, normalization, cardinality,
hierarchy management, optionality constraints); and business process. All four
components need to be addressed, and in addition, the data quality strategy needs to
be aligned with the target data architecture. Another goal of a complete data quality
strategy should be to address and reduce ROT (redundant, obsolete, and trivial)
information in the data.
The data quality strategy is created based on an analysis of existing major quality
issues and business objectives for trusted data. Data quality objectives cannot be met
solely by technologies and techniques alone. High quality is the result of continued
scrutiny shared and communicated across the organization by all stakeholders.
An implementable data quality strategy may require a cultural shift, obtained by
strong support of executive management and sustained promoting, educating, and
mandating attention to the data assets.
To successively achieve a data quality culture, the organization must develop a

comprehensive measurable strategy appliable across all business units, business
processes, and applications. The adoption of a data quality strategy enables stake-
holders to understand the correspondence between organizational objectives, such as
enhanced analytics, more accurate risk management, and improved operations.
When defining the data quality strategy, organizations should include guidance for the
criteria against which data quality will be measured. It is recommended that criteria
be defined for each of the dimensions of quality. A number of different dimensions of
quality can be measured. A sample set is presented below:
• Accuracy – criteria related to affinity with original intent, veracity as compared

to an authoritative source, and measurement precision
• Completeness –criteria related to the availability of required data attributes
• Coverage – criteria related to the availability of required data records
• Conformity – criteria related to alignment of content with required standards
• Consistency – criteria related to compliance with required patterns and

uniformity rules
• Duplication – criteria related to redundancy of records or attributes
70 Data Quality Strategy

• I ntegrity – criteria related to the accuracy of data relationships (parent and child
linkage)
• T
imeliness – criteria related to the currency of content and availability to be
used when needed
GOALS
1. A data quality strategy, collaboratively developed with lines of business, is
aligned with business goals.
2. Data quality priorities and goals are translated into actionable criteria, and are
aligned with organizational objectives.
3. An organization-wide data quality program is defined, and correspond-

ing roles and responsibilities are established to meet program needs (e.g.,
executive sponsorship, communication mechanisms, delegated authority,
career development, and employee training).
4. Data quality processes are integrated and aligned with the data quality
strategy.
CORE QUESTIONS
1. Is data quality emphasized in all initiatives involving the data stores?
2. How does the organization measure data quality program progress?
3. What organizational unit is responsible for maintaining the data quality

strategy?
4. What organizational units are tasked with data quality initiatives? How are
decisions made about standards, methods, and techniques?
5. Are roles, responsibilities, and accountability clearly defined to foster

improved quality of data assets?
6. Is the data quality strategy widely distributed, communicated, and

promulgated?
7. Does the data quality strategy clearly describe objectives, policies, and
processes?
8. Is data quality integrated with the systems development lifecycle?
9. How is data quality improvement integrated with business process

improvement efforts?

Data Requirements Definition provides assistance in determining data quality objec-
tives and development of detailed criteria.
Data Management Strategy addresses information to aid in development of the data

quality strategy, which should align with the organization’s data management strategy.

Data Quality Assessment, Data Profiling, and Data Cleansing contain specific practices
that contribute to improving the quality of data assets.
Level 1: Performed
1.1 Data quality objectives, rules, and criteria are documented.
Project level criteria include established standards, control processing, and

metrics such as error rates and quality thresholds.
1.2 Business stakeholders participate in setting data quality criteria and objec-
tives.
1.3 Data quality plans are followed; rules are implemented; criteria are
monitored.

• Data quality plans, criteria, and rules
• Meeting notes or reviews from stakeholders
• Status updates against plans
• Data quality metrics
• Data quality processing documentation
• Data quality rules implemented in database and software, documented

as requirements
Level 2: Managed
2.1 A data quality strategy is defined, approved, and managed.

The fundamental objective of the data quality strategy is to encapsulate the
organization’s plans to assure that data is fit for purpose and meet business
needs. The strategy should be designed to facilitate moving from the current
state to the target state; it should explicity align with business objectives and
drivers and the organization’s data management strategy.
At a minimum, a data quality strategy should include the components below:

• Quality goals and objectives
• Business benefits and impact (by line of business within scope)
• Implementation priorities
• Quality criteria
• Policies and governance
• Compliance process
• A sequence plan to guide implementation

It should also include guidelines related to data profiling, expectations, and
rules that help guide data cleansing projects.
Data Requirements Definition will assist in determining data quality objec-

tives.
Refer to Data Management Strategy for information to aid in development

of the data quality strategy—these two process areas have a symbiotic
relationship.
2.2 Business stakeholders particpate in creating the data quality strategy.

2.3 The organization has established policies, processes, and guidelines to
implement the data quality strategy.
The data quality strategy is supported by policies, plans, and processes,

which define standards and guidelines for how activities are conducted that
are necessary to achieve the organization’s quality goals. Processes and
policies should contain guidance for profiling, cleansing, assessment, and
monitoring activities that are applied across projects. These activities can be
applied to areas such as data store consolidations, data warehousing, source
to target transformation, data conversion, etc.
2.4 Data quality requirements are articulated employing data quality dimensions
selected by the organizations.
A variety of ways and adjectives are used to describe dimensions of quality.

Industry vendors and experts in data quality measurement will describe
from seven to nine distinct dimensions. What is most important is that
the organization determine what dimensions are most important to them,
describe the dimensions, use them to guide development of requirements,
establish criteria to guide activities, and use them to assess levels of quality
in a standardized fashion.
Refer to Data Requirements Definition for assistance in determining data

quality objectives and development of detailed requirements.
2.5 The data quality strategy is created with reference to business objectives
and plans, and is approved by executive management.
It is important to ensure that the strategy can be accomplished based on

the operational models defined by the organization for data management
functions. Efforts to achieve increased quality can be significant, so the
correct level of quality for the purpose must be identified, and the effort
to achieve it must be balanced and in alignment with business plans. The
business plans are key drivers to development of the data quality strategy.
2.6 Plans to meet the goals and objectives of the data quality strategy are
monitored to evaluate progress.

• Data quality strategy
• Data quality sequence plan with key milestones identified

• Policies, processes, and guidelines
Level 3: Defined
3.1 The data quality strategy is followed across the organization and is accom-
panied by corresponding policies, processes, and guidelines.
The strategy should include consideration of the following:

• Alignment with business strategy
• Targets and thresholds associated with business objectives
• Overall data management strategy and objectives
• Prioritizations of subject areas
• Alignment with organizational data and architectural standards
• Requirement to employ data quality dimensions
• Process for approving data quality rules
• Guidelines and criteria for data profiling, assessment, and cleansing

activities
• Sequence plan to guide implementation
• Identification of critical projects with dependencies mapped
3.2 Roles and responsibilities for governance, implementation, and management

of data quality practices are defined.
3.3 A defined process for defining benefits and costs for data quality initiatives
is employed to guide data quality strategy implementation.
The data quality strategy should provide justification for the value and
importance of implementation outcomes. A clear value proposition should
be established for executing the strategy. Determination of the benefits
and costs of data quality may include an ROI analysis, cost implications of
defects, and business opportunites tied to improvements.
3.4 The policies, processes, and governance contained in the data quality
strategy are anchored across the data lifecyle, and corresponding processes
are mandated in the system development lifecycle methodology.
Institutionalization of the data quality strategy includes ensuring that as new

data management systems and data warehouses are developed, principles
and requirements are embedded as a part of the development lifecycle. It is
equally important that the plans for and execution of development activity
are monitored and adjusted as appropriate to reflect execution of the data
quality strategy.
3.5 Data quality projects, such as data profiling, data assessments, data
cleansing, and risk assessments are aligned with the business needs
identified in the data quality strategy and the cost-benefit analysis.

3.6 A sequence plan for data quality improvement efforts across the organi-
zation is developed, monitored, and maintained.
The sequence plan is monitored by data management with input from gover-
nance bodies.

• Data quality strategy approvals
• Data management standards providing quality criteria and guidelines
• Approved policies and processes
• Approved data quality metrics
• Embedded SDLC data quality processes
• Data quality business rules organized around subject areas
• Standard data quality processes
Level 4: Measured
4.1 Data quality metrics are employed to analyze proposed changes to the data
quality strategy.
Producing a strategy to meet the data quality needs of the organization is not
a once-and-done activity. Once developed, the execution of the strategy must
be closely monitored, as well as the changing needs of the business. Both
must be regularly evaluated to ensure the strategy achieves, and continues to
achieve, the business needs for quality. As shortfalls are identified or gaps are
discovered, the strategy must evolve, which may involve changes of focus or
adjustments to ongoing projects.
4.2 Prioritizing data quality issues for remediation or prevention is evaluated

quantitatively. Priorities are regularly reviewed and adjusted to address
changing business objectives.
Efforts and costs to address quality issues can be substantial. It is important

to ensure that prioritization and decisions relating to these activities are
accomplished in an informed manner so that the costs are aligned with the
value and achievement of business objectives. Quantitatively evaluating the
quality issues and using that information to help support these decisions is
therefore critical.
4.3 Stakeholder reports of data quality issues are systematically collected. Their
expectations for improving data quality are included in the data quality
strategy, and are measured and monitored.
Documented business needs and data quality criteria and stakeholder expec-
tations do not always match. Unless stakeholders have been involved in the
development of the data quality strategy, it is easy for them to believe that
their quality expectations are not being met. To guard against this and ensure
that the levels of quality are meeting business needs, the success factors

and criteria by which the data quality strategy will be measured must be
developed with stakeholder input.
4.4 The performance of policies, processes, and guidelines, which are defined
to support the data quality strategy, are adjusted based on performance
metrics analysis results.

• Approved changes to the data quality strategy
• Approved changes to policies, processes, and metrics
• Standard metrics based on analytical reports of data quality progress
• Approved modifications to the data quality strategy, sequence plan, or

supporting policies, processes, and plans
Level 5: Optimized
5.1 Data quality program milestones and metrics are regularly reviewed by
executives, and continuous improvements are implemented.
5.2 The organization shares best practices and successful approaches to

improving data quality with industry peers.
Implementation of standards—direct quality standards as well as architecture

standards—is important to meet quality objectives. Standards can include the
following:
• Data architecture standards
• Data exchange standards (e.g., XML)
• Performance metrics for quality rules
• Data quality shared services
• Ontologies and taxonomies

• Presentations, white papers, and articles communicating best practices
for data quality strategy

Data Profiling
PURPOSE
Develops an understanding of the content, quality, and rules of a specified set of data
under management.
INTRODUCTORY NOTES
Data profiling supports an effective data quality program and is an important first step
for many information technology initiatives. Data profiling should be conducted both
periodically for critical data stores, and event-driven as an important activity in evalu-
ating data quality for a specific purpose. For example, organizations may profile data
prior to finalizing the design of a data warehouse, populating a metadata repository,
performing data conversion or migration, planning for data store consolidation, or
whenever a data store is modified.
Data profiling is a discovery task, revealing what is stored in databases and how
physical values may differ from expected allowed values listed in metadata repos-
itories or data store documentation. Profiling typically examines values, ranges,
frequency distributions, divergent metadata, nonstandard record formats, etc. It also
may include testing the accuracy of business rules and analysis of known issues.
As a result of data profiling, organizations may pursue remediation activities such as

data fixes, updating metadata descriptions, enhancing ETL scripts, changes to data
structures, addition or refinement of quality rules, or application business rules, etc.
What is learned through data profiling often serves as a key input to the development
of rules, statistics, metrics, content standards, or business process redesign for
improving the quality of the organization’s data assets.
Data profiling differs from Data Quality Assessment in that profiling activities result in
a series of conclusions about the data set, whereas the assessment process evaluates
how well the data meets specific quality requirements. Data profiling is typically the
first step in conducting data quality assessments.
It is recommended that an organization survey the projects and data stores for
which data profiling is currently performed, establish standard criteria for when data
profiling should be performed, and implement a standard process for its execution.
Prioritization of candidate data stores and data sets (internal or external) for profiling
is based on business needs and objectives expressed in the data quality strategy.
GOALS
1. A standard set of methods, tools, and processes for data profiling is
established and followed.
2. Produce recommendations for improving the data quality improvements to

data assets.
3. Physical data representation is factual, understandable, and enhances business

understanding of the set of data under management.
Data Profiling 77

CORE QUESTIONS
1. Does the organization have a standard method for profiling data?
2. Has the organization trained or acquired staff resources with expertise in data
profiling tools and techniques?
3. Does the organization apply statistical models to analyze data profiling

reports?
4. Do policies and processes specify the criteria for a data store to undergo
profiling?
5. Is data profiling scheduled based on defined events, considerations, or

triggers?

Business Glossary covers the standardization and approval of business terms that
should be referenced in data profiling efforts.
Metadata Management addresses classifications and detailed information about attri-

butes and data elements referenced in data profiling efforts.
Architectural Standards contains best practices that support the design and data
representation standards referenced in data profiling efforts.
Level 1: Performed
1.1 Basic profiling is performed for a data store(s).
Basic profiling includes such things as analyzing the types or number of

distinct values in a column, number or percent of zero, blank or null values,
string length, date ranges, patterns, as opposed to the more advanced
analysis such as cardinality, frequency distributions, or key integrity

• Data profiling reports
• List of data profiling checks
Level 2: Managed
2.1 A data profiling methodology is established and followed.

The methodology adopted or created by the organization describes the
approach to data profiling. The methodology will typically address planning
and scoping the effort, profiling techniques, report templates, and presen-
tation formats for summary results. In addition, profiling processes should
be reusable and leveraged across multiple data stores and shared data
repositories.
2.2 Data profiling plans are established for projects.
78 Data Profiling

Components typically included in the plan:
• Selection of the data store(s) to examine
• Identification of the data set(s) to profile
• List of stakeholders and definition of their involvement
• Objectives of the profiling activity
• Data quality criteria based on the objectives, which includes referential

integrity (parent and child) of the data, consistency of the data with
respect to its documented metadata, consistency with established rules
and patterns, and standard data quality dimensions
• Rules to be applied during the profiling activity
• Method(s) and tool(s) for data profiling
• Template(s) for documenting results
• Schedule of activities, including resources
2.3 Plans for profiling a data store are shared with relevant stakeholders and
data governance.
Data profiling activities should not be planned or executed in a vaccum.

Stakeholders and data governance authorities may have specific needs that
should be taken into consideration. In addition, recognizing that the expense
and effort to conduct profiling activities is not trivial, it is important for
the profiling activities to be aligned with business needs. Sharing plans for
profiling can help to ensure agreements and continued alignment.
2.4 Data profiling activities are conducted according to the plan, and efforts are
adjusted when significant deviations from plan are detected.
Because a profiling effort often produces some unexpected results, the

organization needs to be flexible enough to determine, during the profiling
initiative, if initial results justify additional time and effort to expand the
scope.
2.5 Data profiling results and recommendations are reported to the stake-
holders.
Results should be used as input to data quality assessment and data

cleansing efforts, as well as to inform the data quality strategy. For example,
an organization may determine that its product data has an unacceptable
percentage of errors. The stakeholders need to weigh in on the impact of
these errors and have a role in determining the remediation alternatives and
approach.

• D
ata profiling methodology documentation
• A
pproved data profiling plan and schedule
• D
ata profiling findings reports and metrics
• P
roposed business rule additions based on data profiling
Data Profiling 79

• Defined skill set and training plan for staff with data quality responsibil-
ities
Level 3: Defined
3.1 Data profiling methodologies, processes, practices, tools, and results

templates have been defined and standardized.
Standard profiling tools should be identified and consistently used across

the organization to gain efficiencies. An organizational standard method for
analyzing and presenting business and technical impacts of data profiling on
remediation activities should also be defined and followed. Report templates
and metrics are standardized, centrally stored, and published to ensure
consistent application across the organization.
3.2 All techniques identified to meet the profiling objectives are performed.
While data profiling can be considered primarily a discovery activity, it is
typically initiated to meet specified objectives. The profiling techniques
and tools employed must support achieving those objectives. Tailoring of
techniques and templates may be required. Often a profiling effort has several
phases; for example, out of the box profiling checks (e.g., value ranges, ID
uniqueness, etc.); standardization analysis (e.g., addresses, syntax); tests
for selected business rules; and known issues (which may require complex
queries).
The data profiling team should be fully conversant in all techniques and
corresponding tool capabilities selected for the profiling activities.
3.3 Traceability between data requirements, documented metadata, the physical

data, and data quality rules is captured and maintained.
Data profiling activities should be executed by data profiling experts aware

of data requirements, data quality rules, data content, and data structures.
This is achieved through establishing traceability between data requirements,
physical data, and metadata.
3.4 Data governance is engaged to identify core shared data sets and the corre-
sponding data stores that should be regularly profiled and monitored.
The organization should have defined rules for when various data sets are
profiled (e.g., when data is acquired; or prior to being consolidated, migrated,
exported, analyzed, reported for compliance purposes, or structurally trans-
formed).
3.5 Profiling processes are reusable and deployed across multiple data stores
and shared data repositories.
Sharing and mentoring among peers to build data profiling best practices
should occur across the organization, because data quality activities are
often highly valuable but resource-intensive. Therefore, it is desirable to
leverage efficiencies and avoid rework. Some organizations find that the most
effective approach is to operate with a single data profiling team with skilled
staff for all data profiling efforts.
80 Data Profiling

3.6 The SDLC includes data profiling tasks with tailoring criteria, guidance, and
governance.
Most data store development efforts (for example, creation of a new data
warehouse) should include data profiling activities as a planned part of the
project. Institutionalization of data profiling practices requires that the SDLC
include reference and guidelines for these activities, and that tailoring criteria
are defined and followed.

• Data profiling standards, including criteria for processes, standards, best
practice criteria, tailoring, and reporting formats
• Data profiling methodologies tailored from the organizational standard
• Report showing traceability of data requirements with the data content

and characteristics revealed through profiling results
• Documented tailoring of data-related decisions and rationale
• Documentation that practitioners have required profiling skills
• Data profiling metrics
• Recommendations reports from data profiling efforts
• Business and technical impact analysis results template
• Standard data profiling report requirements
• Approved standard data profiling tool(s)
• Data profile baselines
Level 4: Measured
4.1 Performance of data profiling processes is measured and used to manage

activities across the organization.
• Plans and schedules for data profiling should be managed according
to the feedback provided by data quality measurements. Measurement
should indicate how well the output of this activity addresses and aligns
with the business need and priorities. Decisions on what, when, and how
to profile data should be driven by indications of quality and criticality,
which may vary by business application. Highly shared data and data sets
deemed vital to key business processes should be regularly profiled, as
data quality is critical and needs to be frequently monitored.
• Data quality measures should also indicate how well the staff performed
the data profiling activities. The evaluation of plans and execution (actual
vs. estimates) should consider such things as use of techniques, impact
of results and decisions, compliance with methods and standards, quality
of output, and level of effort.
• Data profiling process performance baselines can be created and used to

inform the planning and execution of data profiling activities and results.
4.2 Data profiling efforts include evaluation of the conformity of data content
with its approved metadata and standards.
Data Profiling 81

Approved standard business terms, meanings, values, and ranges are used
as a benchmark for profiling the data content in a data store. Additional
documentation is typically found in corporate data dictionaries, data models,
system requirements documentation, etc. It is a best practice to update this
documentation as needed.
4.3 During a data profiling activity, actual issues are compared to the statisti-
cally predicted issues based on historical profiling results.
Results should be systematically compared to corresponding historical

profiles to evalute impact of profiling activities on corrective actions and
quality improvements.
4.4 Results are centrally stored, systematically monitored, and analyzed with
respect to statistics and metrics to provide insight to data quality improve-
ments over time.
A consistent impact analysis method can be applied to evaluate business,

technical, and cost impacts of remediation. Summary profiling results are
provided to data governance bodies and senior management. Results are
used to inform data governance and data architecture decisions, especially
for highly shared data.

• Documented profiling methodology, best practices, and standards
• Project reports showing application of profiling results to data quality

governance
• Dashboards, scorecards, or other decision support tools for data quality,

showing the results of data profiling efforts
• Data quality portal displaying data quality models and results to be used
for performance baselines
Level 5: Optimized
5.1 The organization addresses root causes of defects and other issues based on
an understanding of the meaning, technical characteristics, and behavior of
the data over time.
5.2 Data profiling processes and other activities are analyzed to identify
defects and make improvements based on the quantified expected benefits,
estimated costs, and business objectives.
Data profiling results performed on the same data over time can be statisti-
cally analyzed periodically to measure the performance of profiling activities.
5.3 Real-time or near-real-time automated profiling reports are created for all
critical data feeds and repositories.
Automating the performance and scheduling of profiling improves the data

quality program’s efficiency and responsiveness to planned and unplanned
events.
82 Data Profiling

• L
og of stakeholders’ usage of profiling results
• C
ontrol charts demonstrating that the processes used across data stores
have stabilized (data stores have been sufficiently profiled)
• D
ata profiling process objectives for improvement included in standard
data management strategies, programs, and reports
• R
eal-time data profiling reports generated on schedule
• C
onclusions drawn from data profiling process analyses and recommen-
dations for improvement
Data Profiling 83

Data Quality Assessment
PURPOSE
Provides a systematic approach to measure and evaluate data quality according to
processes, techniques, and against data quality rules.
INTRODUCTORY NOTES
Data quality assessments support the development and attainment of predefined
quality expectations and measure data quality for the most important business data
attributes, organized by subject area. Initiation of assessments is driven by business
priorities, often focused on highly shared data required by multiple business areas,
data required for accurate financial statements, and data sets supporting critical
business processes.
Quality assessments should be performed against those data elements that are
deemed critical to the organization; for example, data that contribute directly to the
success of the organizational objectives, are used as part of regulatory or internal
compliance reporting, are designated as critical employee data, or are necessary for
operational decision making. It is important to ensure that policies provide guidance
for what are determined to be critical data sets and data elements.
Targets (the level of quality desired); thresholds (the level of quality tolerated); and
metrics are established for attributes in the selected data sets. These measures and
metrics are typically captured and published in a scorecard or dashboard format.
Assessment results facilitate root cause analysis and are key inputs into the organiza-
tion’s data quality improvement plans.
To support these efforts and determine benefits, it is helpful to categorize the data
quality impacts as part of the assessment process. Categorizing impacts such as cost,
risk, compliance, productivity, etc. will also assist with prioritizing data cleansing
plans.
The organization may move toward a subject area-based approach to data quality
assessment as the governance function and target data architecture matures. For
example, in the subject area approach, the data stewards for customer information
would accept responsibility for developing and monitoring data quality rules for
shared customer data on behalf of the organization, and would be the “owners” of
that portion of the organization’s data quality dashboard. Key data stores that create
or update customer information would be regularly monitored to determine if the
acceptable quality thresholds and targets are being met; if not, the customer data
stewards would initiate root cause analysis and sponsor the resulting improvements
for remediation and defect prevention.
GOALS
1. Establish and sustain a business-driven function to evaluate and improve the
84 Data Quality Assessment

quality of data assets.
2. Standardize data quality assessment objectives, targets, and thresholds

according to industry accepted techniques and processes.
3. Adopt standard data quality dimensions across domains for development of

thresholds, targets, and metrics.
4. Establish an empirical method for statistical evaluation of data quality.
5. Establish standard data quality assessment reporting, utilizing scorecards,

dashboards, and other analytical reports.
6. Utilize the results and conclusions of data quality assessments to develop and
enhance data quality improvement plans.
CORE QUESTIONS
1. Are standard data quality assessment techniques and methods documented
and followed?
2. How are data quality assessments conducted, and are they scheduled or
event-driven?
3. Are standard data quality rules developed for core data attributes?
4. Are data quality rules engines or assessment tools employed?
5. Are the business, technical, and cost impacts of data quality issues analyzed
and used as input to data quality improvement priorities?

Data Quality Strategy contains additional information related to data quality dimen-
sions, including accuracy, timeliness, uniqueness, etc.
Data Profiling contains additional information related to practices associated with

determination of data quality used for data quality assessment.
Metadata Management contains additional information related to metadata

management information and expectations.
Level 1: Performed
1.1 Data quality assessments are performed and results are documented.

• Data quality rules
• Data quality assessment results

Level 2: Managed
2.1 Data quality assessment objectives, targets, and thresholds are established,
used, and maintained according to standard techniques and processes.
2.2 Data governance determines the key set of attributes by subject area for
data quality assessments.
Defining the set of key attributes by subject area is essential to managing the
quality of shared data assets for the organization. Data governance approves
the key attributes and ensures that the value expected will exceed the costs
associated with managing and assessing those attributes; it also establishes
stewardship of terms and definitions, including how data quality is defined
and measured to ensure consistency across the organization. This function
also includes the selection of data quality dimensions against which the data
will be assessed.
Refer to Data Quality Strategy for additional information related to data

quality dimensions.
2.3 Data quality assessments are conducted periodically according to an

approved frequency per the data quality assessment policy.
Within data quality assessments, the data quality is evaluated from a business
unit perspective for consistency with defined data quality dimensions and
criteria.
Refer to Data Profiling for additional information related to practices

associated with determination of data quality.
Refer to Data Qualty Strategy for additional information related to data

quality dimensions and prioritization.
2.4 Data quality assessment results include recommendations for remediation

with supporting rationale.
• B
usiness stakeholders prioritize data quality improvements and evaluate,
test, and approve data quality metrics.
• S
upporting rationale typically includes root cause analysis and impact
assessments, which help to determine corrective action options and
support prioritization decisions for data quality improvements.
2.5 Impact analysis includes estimates of the costs of fixes, the level of effort,
characterization of the business impact, and tangible and intangible
benefits.
The purpose of impact analysis is to support decisions about remediating

data quality defects. Because cost control is important, impact analysis is
essential.
It is useful to assign a severity characterization to business impacts,

estimating the effect of the defect on a business process (for example, high,
medium, low) with a brief rationale. Technical impacts, which address the

difficulty, time, or effort of remediating the defect, can also be estimated and
characterized as high, medium, and low.
2.6 High-level information in data quality assessment reports is traceable to

component individual records to support analysis.
Drill-down capability to actual values is recommended to facilitate under-

standing of data and isolate the source(s) of defects.

• Documentation of objectives, targets, and thresholds
• Documented data quality dimensions and attributes
• Documented metrics for data quality assessment
• Documented analysis of business and technical impacts
• Level of effort estimates for data quality improvements
• Evidence that business stakeholders review data quality assessments
• Recommendations for remediation
Level 3: Defined
3.1 Periodic data quality assessments are conducted in accordance with data
quality policies on an approved schedule, or according to specified event
triggers.
Data quality assessment policies should define how methodologies,

processes, and data quality rules are to be standardized, communicated, and
consistently applied across the organization. The criteria that drive assess-
ments should also be specified.
3.2 The methods for assessing business impacts, including costs and risks, are
defined, approved, and consistently applied across the organization.
When assessing impacts, data quality professionals should ensure that

techniques are applied to determine root causes of any data quality issues.
This may require analysis outside of the data set scope.
3.3 Improvement plans resulting from data quality assessments are integrated at
the organization level.
Improvement initiatives resulting from assessment activities, other than data

cleansing, should address the root cause of the quality problem. This is likely
to impact multiple stakeholders and consuming data stores. It is important
to ensure that improvement initiatives are evaluated and planned at an
organizational level. In addition, dependencies of a subject area data set upon
another data set should be identified and orchestrated to minimize rework.
Senior management prioritization of these activities should be driven based
on the impact assessments provided with the quality assessment reports.
3.4 Data quality is assessed using established thresholds and targets for each
selected quality dimension.

When performing assessments, it is important to provide a clear method of
communicating importance of the findings, and to show relative impacts to
the organization. Results should be organized by the standard approved data
quality dimensions. Scores against defined thresholds and targets will provide
clear indicators of where quality is satisfactory or deficient.
Refer to Data Quality Strategy for information on best practices for devel-
oping data quality dimensions.
3.5 Data quality measurement reporting standards are integrated into the
systems development lifecycle and compliance processes.

• Documented scores, targets, and thresholds for each standard data
quality dimension
• Published and accessible organization-level data quality rules for

approved attributes.
• An organization-level data quality assessment policy
• Standard organization-level data quality assessment processes
Level 4: Measured
4.1 Data quality measurement reports are systematically generated based on

criticality of attributes and data volatility.
Measurement reports are developed according to standard mechanisms such

as dashboards, scorecards, etc.
4.2 Data quality operational metadata is standardized, captured, and analyzed

using statistical and other quantitative techniques to guide improvements.
Refer to Metadata Management for additional information related to

metadata management and its relationship to data quality.

• A
udit and control reports
• D
ata quality assessment progress reports for improvements
• D
ata quality confidence surveys (e.g., determining the level of user trust
for a given data set).
Level 5: Optimized
5.1 The organization can quantitatively assess the benefits of proposed data
changes and refine management priorities in line with data quality gover-
nance practices.
5.2 Data quality assessment and reporting processes are continuously reviewed
and improved.

• Assessment analysis results
• Process review documentation
• Process improvement proposals and approvals

Data Cleansing
PURPOSE
Defines the mechanisms, rules, processes, and methods used to validate and correct
data according to predefined business rules.
INTRODUCTORY NOTES
Data cleansing focuses on data correction to meet end user criteria as determined by
data quality business rules addressing all applicable quality dimensions. Business rules
provide a standard baseline for identifying data defects or anomalies which can affect
business operations.
Data cleansing should be conducted at the data source or close to the original
creation point, and should follow data profiling and data quality assessment analysis
when possible. The organization should develop a data cleansing strategy to guide
sharing and reuse of cleansing rules and to minimize duplicate or conflicting cleansing
processes throughout the data lifecycle. Data corrections must be published for
upstream systems and all downstream repositories. A consistent process for escalating
issues should be documented. Data changes should be verified with internal and
external data providors.
When developing the data quality strategy, it is recommended that, similar to data
profiling and data quality assessments, organizations analyze events and establish
criteria for when data cleansing activities are triggered and performed. Typically, data
cleansing is more frequently conducted on key shared data stores or identified critical
data elements, but it is advisable, subject to criticality and budget, to extend the
reach of this discipline to operational systems providing data to other destinations as
a standard practice. As with data profiling, data cleansing criteria are recommended
to be subject to tailoring. Factors for tailoring may include data store size; data
store criticality; specific business or compliance requirements; and events, such as in
advance of a redesign or consolidation, etc.
GOALS
1. A data cleansing strategy has been created and is consistently followed.
2. Standard data cleansing processes are established and sustained.
3. Data cleansing standards are consistently verfied by all stakeholders.
CORE QUESTIONS
1. Does the organization have a reusable set of data cleansing processes
(automated and manual) to resolve data quality issues?
2. Is there a defined process for verifying corrections and assessing effective-

ness?
3. How does the organization cleanse duplicate records?
4. Are corrections implemented at the source of capture?
90 Data Cleansing

5. Are data cleansing processes followed through to analysis of root causes?
6. Have lines of business established quality thresholds and tolerance limits?
7. Has the organization deployed a consistent toolset(s) to support data

cleansing?
8. Does ROI incorporate data cleansing costs?
9. Does the organization apply considerations of operational and reputational

risk to determine what data cleansing activities to fund?
10. How does the organization define, institutionalize, and monitor the data
cleansing process?

Data Requirements Definition contains more information related to development and
management of requirements.
Data Quality Assessment and Data Profiling provide information that can be leveraged
to prioritize and guide data cleansing.
Metadata Management provides guidance to ensure that necessary information is

managed to support capture and logging of changes to data.
Provider Management contains information about sharing information developed from

internal data cleansing activities with providers to aid in development of better source
data.
Level 1: Performed
1.1 Data cleansing requirements are defined and performed.
Refer to Data Requirements Definition for more information related to devel-

opment and management of requirements.

• Data cleansing requirements
• Data cleansing guidelines
Level 2: Managed
2.1 Data cleansing activities adhere to data cleansing requirements, which are
linked to process improvements to achieve business objectives.
Data cleansing requirements are often derived from data profiling, data
quality assessments, change requests, identification of report discrepancies,
and regulatory audits. Requirements typically identify the following topics:
• What problem to solve (i.e., business objective not being met as a result
of the data issue)
Data Cleansing 91

• What data set to clean (data or metadata)
• How the target state of the data will solve the problem
Describing the target state of the data involves an understanding of the

business rules, data definitions, current and future usage, quality criteria,
business objectives, cost and benefit analysis, data, software and system
architecture, etc.
2.2 Data cleansing activities conform with data quality requirements (e.g.,
quality dimensions such as conformity, accuracy, uniqueness) and quality
criteria.
Data cleansing processes and rules should be documented and linked to

business objectives and requirements. The resulting cleansed data should be
evaluated for consistency with the data definitions. The data dictionary, in
turn, is updated as a result of deficiencies discovered during data cleansing
efforts.
• Data cleansing rules are used to support the achievement of data
cleansing objectives and processes. The development of rules typically
involves:
• Validating data cleansing rules against business definitions
• Linking data cleansing rules to business rules
• Conformance with quality criteria
• Use of business SMEs to create rules
• Documentation and approval of data cleansing rules and their validation
• A process for adding new rules
• Measures to assure consistent application of cleansing rules across

repositories
2.3 The scope of data cleansing is defined.

The scope includes the identification of the data set, data elements and
rules that will define the cleansing activity, as well as the criteria for prior-
itizing data cleansing activities. The scope needs to be balanced with any
time-bounds or resource constraints that may exist. The impact analyses
produced by the data quality assessment process are input to estimating and
setting the boundaries of data cleansing efforts.
Data Quality Assessment and Data Profiling provide complementary infor-

mation that can be leveraged for this practice.
2.4 The process for performing data cleansing is defined by a plan.

Typical planning steps include the following:
• E
valuate the downstream impacts of the change
• D
etermine where the changes needs to be made
• R
econcile any changes with respect to the data’s original intent, versus
the implied meaning resulting from the cleansing requirement. This
92 Data Cleansing

avoids unintentionally changing the meaning of the data, which results in
inefficiencies and confusion
Data cleansing plans typically include:

• The tools and methods that will be used for correcting the data (i.e.,
multiple repository comparison, verification against valid source, logic
checks, etc.)
• Defined process for resolving differences of opinion on data validity
• Logging of corrections, audit trails, version control (configuration

management)
• Feedback on needed adjustments to the data store maintenance plans
• Definition of how referential integrity will be maintained after data

changes are implemented
2.5 A data cleansing policy is established and maintained.

During development, it is important to ensure that appropriate stakeholders
(governance through execution) are involved. If prescribed methods and tools
will be used to support data cleansing activities, the policy should identify
them.
The policy should include a mechanism for communication to affected

stakeholders, as well as a means to manage their feedback. In addition, the
policy should include any specific criteria or thresholds expected to drive
data cleansing activities. The policy should clearly articulate expectations
for root cause analysis, business, and technical impact. It should also specify
the criteria for prioritizing and scheduling data cleansing projects, as well as
guidelines for resource allocation.
2.6 Methods for correcting the data have been established and are defined
within a plan.
Methods may include multiple repository comparison, verification against

valid source, logic checks, referential integrity, or range tolerance.
Methods typically involve functions to ensure the following:

• Content is standardized, validated, and maintained with the use of
external sources as needed
• There is a process for resolving differences of opinion on the validity of

the data
• Log corrections, audit trails, and version control (configuration

management) have been defined
• Feedback to data store maintenance plans has been delivered
• Referential integrity is maintained after data changes are implemented.
2.7 Data cleansing issues are communicated and resolved, when possible, in the
internal or external source.
Data Cleansing 93

The best defense against spending the time and effort to cleanse the same
data set for multiple instances on multiple occasions is prevention at the
point of origin.

• Data cleansing policy
• Data cleansing processing and rules
• Data cleansing metrics
• Data cleansing plans
• Data correction methodologies
• Data cleansing issues
Level 3: Defined
3.1 Data change history is maintained through cleansing activities.

Data change history should be supported by traceability of cleansing rules
from their requirements to where the changes are being made and down
through their interconnected processes.
See the Metadata Management for guidance on ensuring that necessary infor-
mation is managed to support this activity.
3.2 Policies, processes, and procedures exist to ensure that data cleansing activ-
ities are applied at the point of origination in accordance with published
rules.
3.3 Data cleansing rules are applied consistently across the organization.
Quality rules and business rules for data elements that are shared among
multiple business lines should not diverge unless a considered excepetion has
been approved.
3.4 A governance group establishes, maintains, and ensures adherence to data

cleansing rules.
3.5 Standard data cleansing results report templates, at the detail and summary
level, are employed.
The organization can monitor these reports to develop a picture of dupli-

cative efforts (cleansing the same data sets in multiple data stores). In
circumstances where the same shared data is used (e.g., customer data),
rather than spend the time and allow separate efforts to fix several data
repositories, resources may be better spent to modify systems and processes
to consume from a single standard data set that can meet the quality require-
ments of all users.

• Data change history log
• Traceability matrix
94 Data Cleansing

• Data cleansing feedback
• RACI matrix for data cleansing governance, activities, and rule devel-
opment
• Data cleansing results report templates
Level 4: Measured
4.1 Service level agreements include data quality criteria to hold data providers
accountable for cleansed data.
The results of data validations should be provided to internal and external

suppliers to enable the improvement of their cleansing processes.
Refer to Provider Management for more information related to these expecta-

tions.

• Service level agreements
• Feedback documentation
Level 5: Optimized
5.1 The organization is involved in the establishment and maintenance of

external or industry standards for improving the quality of data content.
This is especially applicable when the organization is involved in industry

initiatives to standardize data produced or consumed by multiple organiza-
tions.
5.2 Data cleansing requirements for data providers are managed in accordance
with standardized processes.

• M
eeting minutes showing involvement in standards
• S
LAs include cleansing processes and expectations for data providers
Data Cleansing 95

4 Data 98
Data
Requirements
Definition
0perations Data Lifecycle
105
Management
Provider
111
Managment
96 Data Operations

Data Operations
Best practices for specifying data requirements and
managing implemented data across the entire supply
chain.
The Data Operations category encompasses process areas designed to help an organization
ensure that data requirements are fully specified; data is traceable through all of the busi-
ness processes that produce or consume it; data changes and their processes are managed;
and data sources are selected based on requirements, well controlled, and verified as
author-itative.
Data Requirements Definition contains practices which ensure that specifications for data
used by a business process satisfy business objectives, are validated by stakeholders, priori-
tized, and well documented through a repeatable process. Data Lifecycle Management assists
an organization to ensure that its data flows are well mapped to business processes through
all lifecycle phases. Provider Management describes best practices for data source selection
and controlled, bidirectional interactions with internal and external providers.
Maturity of the practices within this category will increase the organization’s knowledge
about its data assets, allow business users to identify the best sources to meet their needs,
enable upstream suppliers and downstream consumers to map dependencies to anticipate
the impact of changes, support data integration initiatives, and build more accurate and
efficient data stores.
Data Operations 97

Data Requirements Definition
PURPOSE
Ensure the data produced and consumed will satisfy business objectives, is under-
stood by all relevant stakeholders, and is consistent with the processes that create and
consume the data.
INTRODUCTORY NOTES
Data requirements definition establishes the process used to identify, precisely define,
prioritize, document, and validate the data needed to achieve business objectives.
Data requirements should be stated in business language and reuse any approved,
available, standard business terms. This is critical to reducing complexity over time,
and essential for effectively sharing data across the organization.
The data requirements definition process is an important contributor to the

enrichment, validation, and creation of business glossary terms and definitions
that link to business processes that manage and process the data. These business
processes should express the intended applications of the data. Business analysts
typically identify, examine, and document business processes with their data usage,
to better understand how the data will be used and tested prior to being ready for
release into production. It is also important to analyze and document data quality
rules as part of the data requirements process.
The method chosen for defining and documenting data requirements should be
in alignment with application development lifecycle processes. Participation of
stakeholders in data requirements definition gives them visibility into the evolution
of the requirements, ensuring that the requirements are understood and relevant.
Early collaboration establishes the foundation necessary for effective communication
and governance. In addition, many of the stakeholders will be assigned stewardship
roles. The adoption of data governance roles and responsibilities in an organization
frequently originates with the requirements definition process.
Requirements definition should follow an orderly discovery and decomposition

process that encompasses articulation of business concepts and needs, and alignment
with existing approved business terms and definitions. Business rules should be
developed and articulated in parallel with the logical design of the application(s)
supporting the destination data store.
This process is bidirectional and iterative. When complete, documented functional

data requirements should be fully represented in the logical design of each data
store and should reflect standardization across projects. The data scope is not final
until business users validate the requirements in detail, to ensure that each business
requirement and its corresponding business rules have been approved, and if the
project development method allows, tested.
Profiling the data where possible (e.g., incoming reference data, transaction data to
be ingested, etc.) will ensure that it meets the business expectations, objectives, and
requirements. This will positively impact the design process for the data store by
98 Data Requirements Definition

surfacing data issues prior to permanent storage, and also results in earlier refine-
ments in business rules and selection criteria, lowering development costs. These
practices will improve the percentage of requirements satisfied by the first release,
and require reduced levels of rework for future releases.
GOALS
1. Data requirements definitions consistently satisfy business objectives.
2. All relevant stakeholders have a common understanding of data requirements.
3. Approved standards are followed for data names, definitions, and representa-
tions in requirements definitions as appropriate.
CORE QUESTIONS
1. How are business and technical data requirements solicited, captured,
evaluated, adjudicated, and verified with stakeholders?
2. How are the data requirements mapped to the business objectives?
3. How are approved data requirements validated against standard data

definitions as well as logical and physical representations?

Data Lifecycle Management provides information about business process correspon-
dence to the data within scope.
Data Profiling focuses on understanding the content, quality, and rules of data sets.
Data Management Strategy contains information about business objectives.
Governance Management and Data Management Function contain information about

the roles and expectations of stakeholders.
The products produced and managed by the organization described in Architectural

Standards will also be a source of data requirements, as well as a vehicle by which to
satisfy some of them.
Level 1: Performed
1.1 Stakeholders review and approve data requirements.
Data requirements should be consistent with the language of the business

and employ standard approved business terms when available.
1.2 The business glossary is updated with approved data requirements.

Approved data requirements often have impacts to the business glossary,
both when they are initially defined and also as they change. It is important
to update the business glossary after the requirements are approved, project-
by-project. The project lead provides the proposed additions or modifications

to business terms to data governance, usually facilitated by the data
management function.
1.3 Data requirements are evaluated and adjudicated against deliverables and
either confirmed or modified.
A systematic approach is employed to collect, document, evaluate, prioritize,

and verify data requirements as well as to align them with business objec-
tives, analytical needs, and other consuming or producing applications.
• Catalog of business terms and their definitions
• Data requirements documentation
• Review board meeting notes
• Documented stakeholder requirements review decisions
Level 2: Managed
2.1 The data requirements definition process is documented and followed.

It is important for the data requirements process to be performed consis-
tently within a business unit or equivalent organizational scope. Documen-
tation of the process should be managed as a reusable asset.
The process should include identification and prioritization of data

requirements critical to the business, including, as appropriate, critical data
elements.
Data operations processes and workflows are mapped to the data require-
ments. In addition, the data requirements definition process should use and
produce specific data requirements artifacts such as a standardized data
requirements document template, which includes data quality rules.
2.2 The data requirements necessary to achieve data management goals are
defined and demonstrably aligned with business objectives.
Alignment of data requirements to business objectives can be managed by

using methods such as inference, mapping, traceability, relational databases,
etc. The organization should determine and implement a method that best
fits its culture and environment.
Refer to Data Management Strategy for more information about business

objectives.
2.3 The traceability of data requirements to business requirements and objec-

tives is maintained.
Organizations often apply a requirements management tool to ensure that

requirements changes are fully traceable. Some data requirements may be
captured through this capability. Others may be captured and maintained
through data models, specialized templates, or the metadata repository.

2.4 Data requirements are aligned with the corresponding data model(s) and
other related artifacts.
A best practice is to develop the logical data model in parallel with

supporting analyses that decompose business requirements at progressively
finer granularity and eventually into atomic testable statements. The logical
design is iteratively refined, corresponding with requirements refinement.
Other artifacts may include work products such as custom-to-COTS mapping,
etc.
2.5 Stakeholder roles and responsibilities for involvement with data require-
ments definition are specified, planned, monitored, and controlled.
A requirements definition stakeholder may be the owner of the data, a

steward of the data, an end user of the data (internal or external), a provider
of the data, etc.
Refer to Governance Management and Data Management Function for infor-

mation about the roles and expectations of stakeholders.
The results of performing Data Lifecycle Management practices will support

this process by providing information about data used in business processes.

ata requirements specification document
• D
• R
equirements mapping to business objectives
• R
equirements mapping to data model(s)
• S
takeholder requirements approvals
• R
eview board notes and decisions.
Level 3: Defined
3.1 Data requirements are defined, validated, and integrated using the organiza-
tion’s standard requirements definition framework.
Data requirements definition best supports the achievement of business

objectives when the scope of the data:
• Supports the new or improved business process
• Is specified in a clear and well organized fashion
• Is understood and validated by business sponsors and end users.
Individual activities and implementations should take direction for their data
requirements definition activity from the organization’s standard require-
ments definition process and templates. These should define all components
of the requirements definition and be reusable from project to project. Refer
to CMMI’s Requirements Development process area for additional information.
3.2 Data requirements are assessed based on business priorities.

The criticality of data within scope should be evaluated against high-pri-
ority business objectives according to the primary purpose (for example,
regulatory reporting). Customer feedback should be included in the analysis
to determine if there are implied or unstated business objectives that may
be important to accommodate. In addition, critical data elements should be
identified, tracked, and managed.
3.3 The business processes that produce data are documented and linked to the
data requirements.
Understanding the business processes involved in the production of the data

that will be used to satisfy the requirements is essential to understanding its
meaning, its correct use, and its owners. In addition, visibility into the process
promotes trust in the quality of the data. Business processes are modeled
with reference to the activities, products, or services resulting from process
performance, in the language of the business.
In cases where there are known quality issues with the data resulting from the
associated business processes, a redesign of the process may be conducted.
This facilitates remediation of inadequate data stores, and specifies the scope
and magnitude of data quality improvements.
Data Lifecycle Management supports this practice by providing information
about the usage of data in business processes.
3.4 Data requirements comply with and include compliance requirements for
both physical and logical data, including security rules as well as technical
requirements.
Data requirement standards and templates developed at Levels 1 and 2

should now reflect organization-level compliance requirements.
Security requirements may include the following:

• P
hysical security (e.g., communication of classification on screens and
printed reports and a lack of access to secure machines)
• Logical security (e.g., row or column level security)
• Network segmentation
• Entitlement and permissioning
• Granting authorizations
• Encryption (e.g., server data encryption, data extract encryption, etc.)
Technical requirements may address these items:

• Availability
• Performance
• Designated platform
• Communications capability
• Interface operational specifications (e.g., download frequency, etc.)
• Architectural compatibility, etc.

Most organizations require interface specification or control documents,
which specify selection criteria as well as technical requirements for
interface operations. This information can be included in the technical design
document or in a separate document, at the organization’s option. Many
organizations find that they do not have sufficient information about their
interfaces, leading to challenges with integration testing, emergency efforts
late in the design phase, etc. The bottom-up task of fully specifying interfaces
will result in valuable information and greatly increased understanding of
the existing data architecture for all stakeholders. Creating documentation
for existing interfaces is a labor-intensive task, but it is important input for
streamlining the data layer over time. It is recommended that the organi-
zation adopt an event-driven approach to ease the cost and effort burden; for
example, requiring that project teams create or update interface specifica-
tions during a major release.
See the products produced and managed by the organization through
execution of the Architectural Standards process area.
3.5 Requirements are evaluated to ensure that they are implementable in the
target environment.
The complexity of the implementation environment should be documented

and reviewed to provide guidance for a high-level architecture that will best
mitigate the existence of multiple, and sometimes competing, requirements
(e.g., business versus security versus technical).

• Standard data requirements template
• R
equirements mapping to use case documentation (e.g., flow charts with
swim lanes)
• R
equirements mapping to business processes
• D
ocumented data security and entitlements rules
• S
takeholder or review board consensus documentation (minutes,
approvals, etc.)
Level 4: Measured
4.1 Industry best practices pertaining to data requirements have been evaluated
against selected criteria to determine if they should be adopted into the
development lifecycle.
Selection criteria may include the cost of adoption and implementation,

analysis of performance before with anticipated performance after, and the
amount of training required to adopt or implement. These criteria can also be
weighted based on cost, risk of implementation, and maintenance. Specific
criteria associated with the data also may need to be considered.
4.2 Defined and managed metrics ensure that data requirements as defined
satisfy business objectives; corrective actions are taken when performance
is not meeting business needs.

• Standard toolset to maintain mapping and traceability between business
requirements and data requirements
• Selection criteria for adoption of industry best practices for the data
requirements definition framework
Level 5: Optimized
5.1 The organization has implemented continuous process improvement to

ensure efficient and consistent prioritization, selection, and verification of
data requirements.
5.2 The organization shares best practices with industry and peers regarding
data requirements.
Information sharing can be through presentations, papers, active partici-

pation in standards bodies, etc.

• Recommendations to improve data requirement processes
• Decisions to change data requirement processes
• Public presentations, articles, and white papers

Data Lifecycle Management
PURPOSE
Ensures that the organization understands, maps, inventories, and controls its data
flows through business processes throughout the data lifecycle from creation or
acquisition to retirement. Data lifecycle management enables better risk management
and supports data quality improvements, particularly in situations involving large
data volumes or high velocity of data movement, and complex and interdependent
processes that share data.
INTRODUCTORY NOTES
The data lifecycle runs from the creation of data assets through their useful life in the
business and eventual archiving or destruction. The organization will benefit from
defining data usage and dependencies across business processes for data that are
either critical for an important business function or are needed by multiple business
processes.
Data lifecycle phases include the following:
• Business Direction (data requirements, creation, and acquisition)
• Development (architecture and design)
• Implementation (physical architecture)
• Deployment (insertion into the operational environment)
• Operations (data transformations, usage, performance, and maintenance)
• Retirement (decommissioning and archiving)
The specific boundaries of the data to be managed are defined, prioritized, aligned
with business objectives, and scoped through the data management strategy.
It is advised to undertake efforts phased over time, as priorities dictate and natural
events provide opportunities, to identify dependencies at the attribute level, enabling
the organization to gradually develop a comprehensive understanding of data inter-
relationships. Scoping of specific data sets should also apply the following consider-
ations:
• I mpact – Data lifecycle management should initially focus on attributes that

either highly impact the organization for an important business purpose, or are
shared by multiple lines of business and instantiated in many data stores across
the organization.
• O
bjectives and condition of target data sets – If the business objective is, for
example, to minimize operational risk, and confidence in the quality of the target
data set is low, the data lifecycle boundary may become broader. For example,
the organization may engage with data providers who are creating data that is
ingested by data stores, and may need to research data consumption patterns.
Effective data lifecycle management commonly depends on the definition and

documentation of key business processes integral to organization-wide functions

and business systems. Each business process determined to be within scope should
be analyzed to identify its data attribute requirements, including how attributes are
integrated into IT systems and modified. After data sets have been initially mapped,
they should be validated and approved by business process owners. The analysis may
also incorporate practices addressed in other process areas, such as Business Glossary,
Data Requirements Definition, Metadata Management, and Architectural Standards.
For shared data used by multiple business areas, data flows and data requirements
should be mapped to business processes. Business analysts utilize business process
models and corresponding attribute lists to evaluate requirements and create maps
to organization and project data model(s) in collaboration with data architects and
data stewards. Eventually, the organization should ensure that all important business
processes are accurately mapped with respect to the data sets they create and
modify, process data requirements, and physical data flows. This process continues as
data needs and sources change.
Because this effort is detailed, extensive, and is undertaken in phases, business stake-
holders and staff supporting the physical instantiation of business data (i.e., systems
development lifecycle, project management) must perform validation and approvals.
The data management function, working with business experts, business process
architects, and other stakeholders, is typically responsible for facilitating the definition
and verification of business process to data set requirements, ensuring that data
is represented according to standards, and specifying data attributes within the
enterprise or business area logical data model. The data management function
also typically develops data lifecycle management processes, and coordinates with
business representatives and data governance to ensure that the defined data sets for
business processes are integrated into application data stores. Project data architects
are typically responsible for the design and implementation of physical data models,
and the management and validation of specific business requirements for application
data stores.
GOALS
1. The data lifecycle pertaining to selected business processes is defined and
maintained to reflect changes.
2. Business processes are mapped to data flows based on a framework for

identifying and prioritizing shared data flows; this mapping extends through
the data lifecycle at the attribute level.
3. Mapping of data impacts, dependencies, and interdependencies are defined

and maintained.
CORE QUESTIONS
1. What activities, milestones, and products are defined for mapping business
processes to the data created and maintained in support of these processes?
2. Has the organization established clear roles and responsibilities for creating
and maintaining a mapping of business processes to data?
106 Data Lifecycle Management

3. Are standard process modeling methods and tools employed to model and
define business processes?
4. Does governance have a role in the management and orchestration of business

process data needs, mapping, and prioritization?

Data Requirements Definition provides information about defining data requirements
at all levels.
Metadata Management contains information about metadata categories and

properties.
Governance Management and Data Management Function contain more information

related to stakeholder role expectations and governance oversight of these activities.
Level 1: Performed
1.1 The data lifecycle for a business process(es) is defined and applied.
The definition includes traceability from the creation or acquisition of source

data through transformations to the destination target(s).
1.2 Data dependencies—both upstream and downstream from the initial creation
or ingest—have been identified and mapped.
Mapping also includes identification of both consumers and producers of the

data.
1.3 Stakeholders agree on the scope of data elements and authoritative data
sources.
The organization should have defined scope and authoritative sources for at
least one fundamental shared entity or data set important to the business
(e.g., customer entity, transaction history, etc.).

• B
usiness process to data element mapping, specifying creates, reads,
updates, and deletes (e.g., CRUD matrix)
• Consumer and producer matrix
• Data flow diagrams specified at the attribute level
• List of authoritative data sources and approved attributes for a data set
Level 2: Managed
2.1 The requirements of data consumers and producers are mapped and
aligned.

A mechanism or process is established whereby the organization understands
the relationship and requirements of data between sources and consumers of
data.
Refer to the Data Requirements Definition for information about defining data
requirements at all levels.
2.2 Business process to data mappings are defined, maintained, and periodically
reviewed for compliance.
Examples of useful tools include a metadata repository, data modeling

tool(s), and business process modeling tools, with their associated artifacts
and models.
Refer to Metadata Management for more information to aid this practice.
2.3 A defined process for collaborative agreements with respect to shared data
and its usage within business processes is followed.
2.4 Selection criteria are defined and applied to designate authoritative data
sources.
2.5 The systems development lifecycle process requires reference to and

adoption of approved shared data representations and obtaining data from
authoritative sources.

• Documentation of the data change management process
• Governance process for shared data assets and data sets
• Business process catalogs and maps to shared attributes
• Data source selection criteria
• Mapping between data producers and consumers
• Attribute level flow diagrams
• SDLC defined processes including mandatory reference to authoritative

data sources as part of process to data mappings
• Business process modeling tool and artifacts
• Data modeling tool and artifacts
• Metadata repository
• Data attribute source mappings
Level 3: Defined
3.1 Data lifecycle management processes are defined and approved by stake-
holders, and managed by data governance bodies and processes.
3.2 Change management processes addressing the entire data lifecycle are
established and maintained.

For example, custodians (physical) and data stewards (logical) employ a
standard evaluation and impact analysis process for data element changes—
additions, deletions, and modifications. Corresponding changes are made to
source-to-target mappings.
3.3 Project responsibilities for system development lifecycle activities include

mapping data attributes to business processes, shared data sets, sources,
and target data sets that are important to the organization.
3.4 Data flows and full data to process lifecycle maps for shared data are imple-
mented for each major business process at the organizational level.
3.5 Changes to shared data sets or target data sets for a specific business
purpose are managed by data governance structures with relevant stake-
holder engagement.
3.6 Designations of authoritative data sources are reviewed and approved by

data governance.
The data management staff is typically responsible for capturing authori-

tative data source information in the organization’s metadata repository or
equivalent location.
See Governance Management and Data Management Function for more infor-
mation related to stakeholder role expectations and governance oversight of
these activities.
3.7 Measures and metrics are defined, and associated information is collected
to assess progress in process to data mapping efforts and the adoption of
authoritative data sources.

• Process to data mapping templates
• Data mapping project plan (with milestones)
• Data management organizational roles and responsibilities
• Change management process for defined data sets
• Lifecycle data mapping of core business processes
• Identified data attribute sources
• Authoritative data sources for data attributes
• I mpact analysis of proposed changes to managed attributes and their

supported processes
• R
ecommendations for additional attributes, modifications, and changes
to source-to-target mappings
• Interface, data source, and destination change records
• Data maps
• Context diagrams
• Map for shared data set attributes across data schemas

• Governance process to identify data dependencies
• Metrics measuring progress and authoritative data sources adoption
Level 4: Measured
4.1 A standard process is used across the organization for data lifecycle impact
analysis, and to identify, estimate, and schedule changes to interfaces and
data sets.
4.2 Metrics are used to expand approved shared data reuse and eliminate
process redundancy.

• Metrics documentation and results
• Approved process mapping change requests
• Remediation process
• Remediation plans
Level 5: Optimized
5.1 Metrics and stakeholder feedback are analyzed periodically for the purpose
of introducing improvements into the management of data dependencies.
5.2 Data lifecycle metrics are periodically refined and reviewed by senior
management.
5.3 The organization shares experiences with industry and peers regarding data
management lifecycle processes.

• Data dependencies reports
• Recommendations to improve data lifecycle management processes
• Data lifecycle forecasting reports
• Reports to senior management based on statistical analysis
• P
ublic presentations, white papers, or similar documents communicating
data lifecycle management process experience
• R
eports to senior management highlighting new requirements for
inclusion in process to data maps

Provider Management
PURPOSE
Optimize internal and external sourcing of data to satisfy business requirements and
to manage data provisioning agreements consistently.
INTRODUCTORY NOTES
This process area describes practices performed to define data sourcing requirements,
acquire data, manage agreements, and interact with providers. In addition to mapping
data requirements with appropriate sources, this process includes establishing service
level agreements with external and internal data providers. It is important to manage
providers to assure quality data delivery. The data sourcing focus of this process
ensures that data requirements can be satisfied with the appropriate data sources,
whether internal or external. This process ensures that delivered data will meet
business needs.
Data source mapping depends on precise terms, comparable data definitions, aligned
calculation methodologies, data profiling analysis, and well-defined data requirements.
The goal is to create parameters by which alternative sources can be identified,
compared, and selected; and to determine where attributes can be combined, split, or
parsed via business rules to satisfy business requirements.
This analysis should be performed at the attribute level, and take into consideration
key performance indicators, alternative data sources, and service level requirements.
Data quality criteria definition is integral to the data sourcing process and is employed
to compare data sourcing alternatives, and to support service level agreements with
selected internal and external data providers.
Assessing the quality of sourced data should be based upon established criteria, such
as data error handling, use of authoritative sources, testing, managing responses to
requests, escalating issues, and ensuring the integrity of the data by utilizing proper
controls. Delivered data should be regularly monitored to ensure that established
criteria continue to be satisfied.
Management of data providers ensures continued fulfillment of established criteria

through service level agreements. To achieve this, it is important to know how
providers produce, combine or aggregate, and deliver their data. This knowledge is
used to work with the provider to increase confidence in the data and to assess in
evaluation of quality issues.
GOALS
1. Data requirements for sourcing, procurement, and provider management,
including data quality criteria, are assessed according to a documented
process.
2. Selecting, contracting, monitoring, and managing data providers is performed

according to a standard data source selection and control process.

3. Potential sources and providers, including their services, data scope,
processes, and technologies are identified, documented, and understood.
4. Standard service level agreements address all business requirements and are
employed to manage data providers.
CORE QUESTIONS
1. How are data sourcing requirements captured, validated, and prioritized?
2. Are requirements for data sourcing specific, unambiguous, driven by business

requirements, and feasibly procurable?
3. Is there a mechanism that ensures business approval of sourcing require-

ments?
4. How are data attributes mapped to data sources and downstream applica-
tions?
5. How is the data source selection process managed?
6. How are service and content quality from data providers monitored?
7. Do providers comply with applicable standards?
8. Is there a repeatable process for managing issues that includes responsible

points of contact?

Data Requirements Definition provides more information related to determining and
managing requirements.
Data Quality Strategy supports this Process Area with data quality objectives that
should be used to guide agreements with providers.
Governance Management and Data Management Function contain more information

related to stakeholder role expectations and governance oversight.
Data Profiling and Data Quality Assessment support this practice by providing
methods by which data is evaluated, as well as the results of evaluation.
Level 1: Performed
1.1 Data requirements are translated into data sourcing specifications.
1.2 Analysis and testing are conducted to verify that procured data meet stated
requirements.

• Data sourcing requirements
112 Provider Management

• C
ontract coverage checklist for external providers (includes formats,
usage, costs, timing, delivery methods, etc.)
• Data provider’s quality checks (list)
• Data feed evaluation reports
• Agreements with internal and external data providers
• Approved vendor invoices
• Communication with data providers
Level 2: Managed
2.1 A process to analyze data requirements for data sourcing specifications, and
mapping requirements to provided data elements, is defined and followed.
Data documentation (e.g., data dictionary, metadata repository, etc.)

with mapping between requirements and source attributes, is updated as
necessary.
Data Requirements Definition provides more information related to deter-

mining and managing requirements.
2.2 A data procurement process for obtaining data from external providers is
defined and followed.
A defined procurement process typically includes some or all of the following:

checking to see if the data required has already been procured by another
area of the organization, evaluation criteria, decision criteria, identifying
authorized sources, approval authorities, cost evaluation, etc.
2.3 Data quality criteria are defined and embedded into service level agree-
ments with both external and internal providers.
Data analysts and key stakeholders regularly review key performance metrics
for data source quality, using standard data quality dimensions criteria (e.g.,
accuracy, completeness, consistency, timeliness).
Refer to Data Quality Strategy and Data Quality Requirements for input to this
practice.
2.4 Planned discussions are held with data providers to address deviations to
established data quality thresholds and targets defined in the service level
agreement.
Data analysts liaise with subject matter experts to agree on acquisition

requirements and data quality validation processes, as well as to provide
feedback over time.

• Procurement policies
• Data sourcing requirements

• D
ata definitions that show alignment between sources, requirements, and
attributes
• Mapping of data requirements to sources
• Provider service level agreements
• Procurement process
• Data source evaluations
• Meetings minutes with data providers
Level 3: Defined
3.1 Data governance monitors the standard organization-wide process used to

develop data sourcing requirements.
Refer to Governance Management and Data Management Function for infor-

mation related to stakeholder role expectations and governance oversight.
3.2 Metrics for the data sourcing management process are established,
maintained, and used.
Metrics could be related to cost, schedule, level of effort, and specific targets
for technical performance. Key performance metrics (i.e., message formats,
delivery times, timeliness of updates, valid values, accuracy of attributes,
issue management, etc.) are defined, implemented, and employed to measure
and evaluate providers.
3.3 Data sourcing evaluation and selection processes are defined and employed
across the organization.
Organizations often use the audit reports of their external data providers
to show compliance with control standards and processes as part of the
selection process.
Refer to Data Profiling and Data Quality Assessment for information that
supports this practice by providing methods by which data is evaluated, as
well as the results of that evaluation.
3.4 Provider service level agreements are developed based on standard

wtemplates and processes, are implemented across the organization,
tracked, and enforced.
Service level agreements typically include agreed upon remediation options

pertaining to data quality, delivery, and timeliness. Key performance metrics
are incorporated into standard service level agreements. Dashboards, score-
cards, and performance reports for data sources also reflect these metrics.
3.5 Service level agreements are periodically reviewed to assure satisfaction of

business objectives and requirements.
3.6 Periodic meetings are held with data providers to review planned changes to
data content, processes, formats, quality, etc.
114 Provider Management

• Standard data sourcing process
• Service level agreement template
• SLAs with providers
• Defined quality criteria for data sourcing
• Defined metrics for measuring data sourcing
• Updates to data sourcing process based on stakeholder feedback and

best practices
• Standards, procedures, policies, and work-flow diagrams
• Data provider meeting minutes
• Industry audit reports concerning external data providers (e.g., SOC 2,

SAS70—relevant audit standards by industry)
Level 4: Measured
4.1 Key performance metrics related to service level agreements are analyzed
using statistical and other quantitative techniques, are reviewed, and are
used to identify and address issues.
4.2 Partnering relationships are developed with selected external providers

based upon provider evaluation results and anticipated data needs.
Future data requirements are anticipated, evaluated, and traced to potential

data sources.

• Performance reports, dashboards, scorecards, and heat maps
• Scoring criteria for data providers
• Analytical reports of provider performance
• Recommendations for changes to provider service level agreements
Level 5: Optimized
5.1 Statistical and other quantitative analyses of the provider processes are
applied to improve them and ensure that business objectives are adequately
supported.
5.2 Sourcing lessons learned and evolved best practices are shared with
industry peers.

• Analytical results
• Data sourcing performance-related recommendations
• Alignment mechanism for data sources to business objectives
• Presentations, articles, and white papers

5 Platform and 118
Architectural
Approach
Architectural
126
Architecture Standards
Data Managment
132
Platform
137 Data Integration
Historical Data,
144 Archiving and
Retention
116 Platform and Architecture

Platform and Architecture
Best practices for establishing methods and standards
that ensure the implemented data management platform
successfully integrates, archives, and retains corporate
data assets to support business objectives.
Platform and Architecture encompasses process areas designed to help an organization

design an optimal data layer to meet present and future business objectives; establish and
implement well-crafted, enforceable standards; select a platform and supporting technolo-
gies that meet scope and performance requirements; integrate disparate sources of data; and
manage historical and aged data effectively.
Architectural Approach assists the organization in developing an approved approach to

scope and design a consumable data and technology architecture that emphasizes reduction
of duplicate data and maximizing data sharing. Architectural Standards practices address
the development and approval of standards for data representation, data access, and data
distribution. Data Management Platform emphasizes stakeholder involvement and governance
in decisions that affect platform selection and implementation. Data Integration helps the
organization to create and maintain alignment with business needs through design of shared
data stores, and to establish and enforce standards. Historical Data, Archiving and Retention
addresses versioning, record retention, and archiving, ensuring that data satisfies availability
needs, business needs, and regulatory requirements, as applicable.
Maturity of the practices within this category will help the organization to plan, architect, and
implement a data layer that minimizes redundancies, ensures availability, meets performance
requirements, and integrates well with the technology stack. Mature practices also ensure
that the organization’s architecture will be supported by a robust set of applicable standards
and will be deployed on an extensible platform. Defined practices for integration of data will
increase data availability and improve data quality, and improved processes for historical and
aged data will increase application performance and meet regulatory requirements.
Platform and Architecture 117

Architectural Approach
PURPOSE
Design and implement an optimal data layer that enables the acquisition, production,
storage, and delivery of data to meet business and technical objectives.
INTRODUCTORY NOTES
The architectural approach is essential for design of a well-structured, consumable
target data and technology architecture that satisfies key business goals, as defined
by Data Management Strategy.
Emphasis should be on data sharing for critical business data needs. This may require
streamlining the data layer (redesign and consolidation of data stores), reducing data
redundancy, improving data integration through common interface specifications and
data services, or defining and enhancing a data technology stack that satisfies current
and anticipated business needs. The target data layer should support the data quality
objectives defined in the data quality strategy and incorporate data profiling and
validation results. This will ensure that high-quality, trusted data can be used to meet
critical business objectives, with minimal data reconciliation required.
The architectural approach also incorporates the following technical objectives:
• Scalability to ensure that resources made available by the architecture in the

form of components, services, and code libraries achieve acceptable perfor-
mance and throughput with increasing data loads
• Resiliency principles guiding establishment of system robustness, fault

tolerance, and data recovery from abnormal usages or disruptions in accordance
with business requirements
• Security requirements governing the protection, confidentiality, and availability

of corporate data and personal information
The approach should ensure that the architecture reflects identified legal and
regulatory requirements appropriately.
The combination of business goals and technical requirements comprising the target
architecture creates a logical representation of the future state, referred to as the
“To-Be” blueprint. The target architecture requires a transition plan from the current
state, or “As-Is,” to the To-Be. The blueprint is decomposed into an IT implementation
roadmap, which reflects compliance with the approved approach.
It is important to define metrics and key performance indicators (KPIs) measuring the
effectiveness of the architecture blueprint and subsequent designs of the components.
Metrics may include the number of adopters for a new data component or service, the
rate of adoption, satisfaction of specific business needs by new or redesigned compo-
nents, the number of data quality issues resolved prior to design, etc.
The architectural approach must be flexible for the evolving needs of the organization,
and processes for technology obsolescence and ensuing data migrations must be
118 Architectural Approach

formulated. It is important for data governance and relevant stakeholders to adopt
the transition plan and target components of the architecture, and to validate that
business operations will be minimally impacted. Major impacts to key operational
systems need to be analyzed, and appropriate mitigation strategies to ensure uninter-
rupted delivery of operational data must be documented.
The architectural approach must be reviewed and approved before proceeding toward
design and implementation to validate that it meets business needs and is consistent
with architectural standards. Because the architectural approach is a long-term
guidance activity, it should be maintained and modified in response to changing
business needs and organizational circumstances.
GOALS
1. The approved architectural approach is consistent with business needs and
architectural standards.
2. The transition plan from the “As-Is” to the “To-Be” state is consistently
monitored to ensure that projects are aligned with long-term objectives.
3. The architectural approach is approved and adopted by all relevant stakehold-

ers.
4. Platform and technical capability decisions are aligned with the architectural
approach and approved by stakeholders.
5. Metrics and measures are used by business and IT stakeholders, approved

by the senior governance body, and monitored by the appropriate data
governance group.
CORE QUESTIONS
1. How does the organization approach architecting information assets?
2. Is the architectural approach consistently followed, and are project-level

decisions aligned with the approach?
3. What is the rationalization method employed for synchronizing, consolidating,

or eliminating duplicate data?
4. How does the organization ensure the sustained progress of the transition
plan to the target-state in response to deadlines, tight schedules, and other
pressures?
5. Does the organization have an approved data technology stack, and corre-
sponding governance applied to modifications, additions, and sunsetting?
6. Has the organization documented and approved the technical capabilities and
requirements to satisfy operational business continuity?

Data Management Strategy contains information about aligning business objectives
with the data management program and architectural initiatives.

Governance Management contains information about collaborative agreements and
organization-wide controls for data assets.
Architectural Standards contains information about standards applicable to the archi-

tectural approach.
Data Integration contains information about integration best practices.
Data Profiling contains information related to profiling activities that should be

performed prior to approval of any architectural redesigns or consolidations.
Level 1: Performed
1.1 An architectural approach that aligns business requirements with IT archi-

tecture is established and followed.
1.2 Business and IT stakeholders are identified and involved in architectural

decisions.
1.3 Technical capabilities and requirements are defined to guide implemen-

tation.

• Architecture design for implementation
• Business and technical approvals for architecture
• Stakeholder list for architecture approvals
Level 2: Managed
2.1 The target data architecture aligns with and complements the data
management strategy.
The organization’s data management strategy is developed collaboratively

among lines of business, data management, and IT. Because it is created
top-down, the strategy describes a broadly approved vision, goals, objectives,
and priorities for the organization’s data assets. The target data architecture
employs this shared vision as an important input. The high-level requirements
addressed in the data management strategy are leveraged to architect and
develop blueprints for the future state.
2.2 A governance process is established and followed to ensure that the target
data architecture is jointly rationalized and approved by business and IT
stakeholders.
Data rationalization is a systematic approach applied for the architectural

purposes of discovering, defining, mapping, specifying differences, and
comparing elements of the data layer. This activity ensures that the planned
data architecture fully addresses the data assets and current issues. Areas
of consideration at the logical level typically include multiple data models

(which may differ), conflicting business term definitions, similarity and diver-
gence of values, undocumented business logic, multiple ETL mappings with
overlapping data content, etc.
Areas for mapping and evaluation at the physical level include redundant
data in multiple data stores, exceptions to common data usage, degree of
business dependency on specific data stores, and planned application consol-
idation efforts. Engaging in a data rationalization effort at the architectural
level enables the organization to fully describe the current architecture at the
level needed to support development of future state blueprints.
2.3 An architectural transition plan is based upon a mapping between the

current data layer components and the future-state environment.
The transition plan includes current data store status, retirement and redesign
target dates, the staffing plan, the training plan for new technologies, and
target implementation dates for future components.
Refer to Architectural Standards for information about managing data

standards applicable to the architectural approach.
2.4 A process is established and followed to ensure that data interface speci-
fications are documented for shared data, with traceability from creation
through consumption (end to end) by all sources within scope.
Refer to Data Integration for information about integration best practices

dealing with interfaces.
2.5 A compliance process is established and followed to ensure that projects

refer to and utilize the approved target architecture.

• D
ocumented approval for architectural designs
• A
pproval process for architectural design through governance
• D
ocumentation of approved architecture utilization
• S
hared data interface traceability map
• R
ecords indicating implementation consistent with approved designs
Level 3: Defined
3.1 The architectural approach for the target data architecture is followed
across the organization.
It is challenging for the organization to enforce consistency of application,

as short-term, event-driven priorities may result in exceptions that have
long-term consequences that could add complexity, cost, and rework to the
evolution toward the target architecture. Strong senior management direction
is critical to preempting decisions that may not be conducive to achieving
architectural goals.

Refer to Architectural Standards for information about standards applicable to
the architectural approach.
3.2 A data store rationalization process is performed.

The rationalization process assesses the existing data assets and determines
the degree of redundancy, the degree to which they currently satisfy business
requirements, and the platforms and technologies utilized. It is based on
rigorous criteria and performed systematically to ensure that information
needs implying the development of new data components are not already
addressed by other data stores within the organization. Existing data stores
can be repurposed, or may be satisfactory as a transition step to achieve
longer-term architectural goals by adding an abstraction layer (for example,
XML) or enhanced data quality processes.
The organization may develop a decision tree for graduated characteristics

that need to be met before a consolidation or build decision can be made.
Minimizing impact on core operational business processes is an important
objective, as is cost minimization. The results of the rationalization process
provide significant input into the architecture transition plan.
3.3 The target architecture is collaboratively developed and jointly approved by

business units, IT, and data governance.
It is important for organizations to design the data layer to address business

needs and best practices. Organizations should avoid delegating it solely
to IT, as that approach may foster resistance from the lines of business and
reinforce the status quo. For example, business sponsors who have not been
involved may be insufficiently informed to make precise plans to transition
their data stores to the target state. Additionally, other business implications
of which IT is unaware may exist. Finally, involving all relevant stakeholders is
the key to adoption and sustaining support over time.
It is recommended to follow a collaborative method in development of the

architecture. If the architecture effort runs longer than anticipated to ensure
collective involvement, it may be a worthwhile tradeoff to realize the benefits
of higher likelihood of approval and sustained collaborative agreement
during implementation. As the transition plan is executed over time, it is likely
that one or more data stores owned by each primary business sponsor will
eventually be impacted. Strong buy-in can facilitate decisions and reduce
obstacles, project by project, as data stores undergo redesign, consolidation,
or replacement.
3.4 The organization creates and maintains metrics to evaluate progress on

state transition and traceability mapping.
Metrics for the architecture transition can enable accurate reporting on

milestone achievements for major projects, show progress of the architecture
in terms of adoption, and highlight capability improvements realized from the
new and modified components. For example, business feedback on improve-
ments can be expressed as a data confidence index that correlates with
meeting the business objectives for the target architecture. Traceability maps

can be developed and monitored to evaluate the extent to which business
requirements are met by the evolving implementation, and to validate that
existing data sources have been successfully transitioned as planned.
3.5 Both internal and selected external data standards are evaluated and
applied to the development of architectural blueprints and component
designs.
Although the transition to the target data layer is a long-term activity,

adhering to standards from the beginning prevents rework and its associated
costs. In many organizations, data standards and integration data models
(e.g., enterprise data models, shared repository data models, etc.) already
exist and are subject to a compliance process prior to the development of
the target data architecture. If such artifacts do not exist, are not complete,
or are not followed, undertaking the architecting of the target data layer
is an occasion to create them and institute a compliance process. Evolving
technology capabilities and industry-wide external exchange efforts create
the need for new standards.
3.6 The architecture, technical requirements, and supporting infrastructure

capabilities are aligned.
The architecture and designs should align with the organization’s intended
target infrastructure. The organization may have an Enterprise Architecture
in place, and decisions about platforms, technical capabilities, and corre-
sponding products may have been approved. If lacking, development of
the architectural approach for the data layer is an opportunity to further
organization-wide progress. The organization needs to determine how it will
manage data movement, data integration, data quality, and security, to meet
the goals of extensibility, performance, reliability, resilience, etc.
3.7 The architecture includes the target integration layer, also known as
common interface design.
Some organizations experience high complexity and cost burdens from

the proliferation of interfaces over many decades. While it is challenging
to derive a precise figure for the aggregate cost of maintaining existing
interfaces, reflection on typical scenarios—such as the number of integration
tests conducted per major application release and the number of new point-
to-point interfaces created annually—outlines the suboptimal situation. Many
organizations pay relatively little attention to this steady-state burden, as
costs are usually allocated within the schedule and budget of the projects.
Within the context of the architectural approach, it is very beneficial to

define objectives and identify interfaces for consolidation, abstraction, elimi-
nation, or replacement over time. Considerations include data movement,
uniform import mechanisms, standardization of data representations,
publish [producer] and subscribe [consumer] methods, consolidated views,
candidate common data services, etc.
Large organizations, or organizations that have been in business for many

years, may suffer from a lack of overall knowledge about the data they are

ingesting, its sources, and its quality. For example, an organization may
find that some data feeds are purchased more than once for separate lines
of business, and that sets of the same internal data are procured through
multiple mechanisms. Creating a data asset library, accessible to all stake-
holders, is a useful mechanism to facilitate discovery of what external and
internal sources are already available, what they contain, and how access may
be accomplished.
3.8 Data profiling is performed prior to finalizing the design of a data store
component that will contain existing data.
When an organization commits to a major redesign or consolidation, it

is advisable to undertake data quality profiling as a preliminary activity.
Because roughly half of data quality issues are structural, comprehensive
profiling frequently reveals design flaws that can be remediated in the new
data store. The organization should have criteria defined to guide decisions
on when profiling is required before these architectural changes.
Refer to Data Profiling for more information related to profiling activities.

• Rationalization reports and matrix depicting decision criteria
• Standards documentation on data-related architectural approach
• Project implementation checklists aligned with transition plan
• Metrics for transition progress
• Evaluation of external and internal standards
• List of architecture adoption stakeholders and business units
• Technical requirements capabilities and specifications
• Architecture blueprint compared to the As-Is architecture
• Data quality profiling reports applied to design
Level 4: Measured
4.1 Statistical analysis of performance and data quality improvements are used
as input to the architectural design process.
Metrics for the performance of new architecture components against defined

business objectives, coupled with cost-benefit analyses, are input to architec-
tural design decisions. Limitations of the existing architecture are identified,
tracked, and used as input for future architectural plans. Similarly, refinement
of the architectural approach over time includes forward planning to ensure
an effective future migration to next-generation capabilities.
Metrics for the new architecture component are also used to assess if
business objectives and data quality targets are being met. This may include
business impact KPI criteria that typically include the following:
• Time

• Money saved due to less data repair
• Increased revenues
• Improved customer satisfaction
• Freed time
• Improved data
• Enhanced analysis

• Cost-benefit analyses
• Quantitative performance criteria for designed components
• Quantifiable architecture evaluation targets
• Quantifiable data quality improvements correlated with new or changed

components
• Statistical models employed to guide architecture decisions
• Documented limitations of current target architectural approach
Level 5: Optimized
5.1 Prediction models are evaluated against architectural changes and adjusted
as needed.
5.2 The organization shares architecture and platform lessons learned through
publications and conferences.

• Proposals for modifications to architectural approach
• Prediction model comparison report against business objectives
• Stakeholder feedback traced to proposed modifications
• Presentations or publications about the organization’s architectural

approach
• Analysis of data sets showing correlation between actual performance

and predicted performance
• Identified enhanced business capabilities due to enhanced data analysis

Architectural Standards
PURPOSE
Provide an approved set of expectations for governing architectural elements
supporting approved data representations, data access, and data distribution, funda-
mental to data asset control and the efficient use and exchange of information.
INTRODUCTORY NOTES
Architectural standards define the approach and practices for developing, approving,
and instituting compliance for data representation, data access, and data distribution
standards, which may include standards for the following:
• Data representation - business terms, logical, physical, XML, modeling

standards, model management, etc.
• Data access - common data services, applicable information exchange

standards, standard methods for point-to-point data transit and bulk data
movement, data integration standards (e.g., ETL standards, ELT standards)
• Data distribution - internal and external data provisioning: distribution control

and management, requesting and approving access, access restrictions,
distribution models (e.g., push and pull, publish and subscribe), ownership and
authority, regulatory authority and audit, etc.
The organization’s standards influence platform choices, technology and tool

selection, and common integration rules.
The development of standards is essential. It is important for lines of business to take

an active role in evaluating and approving standards, as well as in prioritizing among
target state objectives. The core capability is to successfully implement a collaborative
approach among lines of business and IT, laying out a systematic, governed process to
develop, promulgate, institutionalize, and enforce standards that both meet business
needs and satisfy the organization’s architectural approach.
Once codified across the organization, the collective set of standards supports the
evolution toward the target data architecture, enabling evolutionary streamlining
of the data assets; improved selection and deployment of the technology stack;
simplified development lifecycle; and reduced costs by minimizing unintegrated
efforts of project staff, reuse of artifacts, disciplines, mechanisms, etc. Effective
and active governance, instituted as an active and sustained function, is required to
achieve these objectives.
GOALS
1. Develop a comprehensive set of data standards aligned with the architectural
approach and the data management strategy.
2. Institute a sustainable standards development and maintenance process

involving business and IT stakeholders.
126 Architectural Standards

3. Establish effective governance and auditing processes for standards
adherence and exceptions.
4. Define and enforce a data distribution standard for requests and approvals.
5. Define and enforce approved data access methods across platforms.
CORE QUESTIONS
1. What are the categories of standards required for the organization’s target
data architecture, and how are they scoped and defined?
2. How does the organization determine business need and technology strategy
for developing approved, standard data access and provisioning?
3. How are data models approved, maintained, and governed?
4. Has the organization defined architecturally aligned, standard data access

methods and criteria for determining which methods to apply?
5. How does the organization promulgate, audit, and enforce standards?

Data Management Strategy and Data Quality Strategy are important considerations for
the standards definition process to ensure the implemented architecture will support
business objectives.
Governance Management and Data Management Function contain information related

to stakeholder role expectations and governance oversight of these activities.
Data Requirements Definition provides information about requirements, which will

impact organizational standards, especially for such things as security requirements
that must be met consistently across the various platforms.
Business Glossary contains information about standards for business terms.
Metadata Management contains information about leveraging standards for metadata.
Data Integration contains information about standards and best practices for data
ingestion, acquisition, and transformation.
Data Management Strategy contains information about the alignment of the organiza-
tion’s data asset approach with standards.
Level 1: Performed
1.1 Data architecture standards are defined and followed.
Typically, organizations develop architectural standards, but they may not

apply them consistently. For example, standards may be strictly followed in

the data warehouse environment but not for operational data stores, or they
are not adopted and utilized by some lines of business.

• Data standards used by projects
• Validation of As-Is data stores against referenced standards
Level 2: Managed
2.1 Architectural standards addressing data representations, security, data

access, and data provisioning are defined and followed.
The body of architectural data standards usually evolves based on broader

architectural initiatives, such as an organization-wide transformation of the
applications or technology architecture, a major application integration or
consolidation initiative, or a major custom-to-COTS migration. Developing a
usable, effective set of standards takes time and effort. Subject to resource
and budget factors, it is recommended to extend the standards base to
address all aspects affecting the organization’s data layer.
Refer to Data Requirements Definition for information that will impact organi-
zational standards, especially for such items as security requirements that
must be met consistently across the various platforms.
2.2 Architectural standards are reviewed with business stakeholders and

approved by data governance.
Creation of data architecture standards typically originates in IT, with input

from the data management function. Business stakeholders should be
involved in reviewing and approving standards development and enhance-
ments through data governance. Approved standards are usually maintained
by the data management function with input from IT and data governance.
See Governance Management and Data Management Function for information

related to stakeholder role expectations and governance oversight of these
activities.
2.3 A process governing requests, approvals, and management of deviations

from architectural standards is defined and followed.
Because the evolving body of standards eventually affects the entire data
layer and data access mechanisms employed, event-driven requests for new
standards, additions, and changes to existing standards must be carefully
coordinated, agreed to, and approved to ensure that progress toward
long-term architectural objectives is not compromised.
2.4 The architectural approach, blueprints, and component designs align with
selected standards.
As standards are approved and adopted, publicizing and promulgating them

across the organization can be a challenge. If the target data architecture
is under development, it will take attention and effort to ensure that new or
improved standards are utilized in designs, tool selections, etc.

Standards and policies should set an effective date and require exception
requests for any deviations after that date. For example, if the effective date
closely precedes a major implementation, a new standard may not be feasible
for that project as there wasn’t sufficient lead time for incorporation. It is
recommended to release guidance with new standards to ensure that they
can be smoothly integrated into planned or existing initiatives.
2.5 Architectural standards are reviewed periodically against changing business,

architectural, and technology needs.
Rapidly advancing technologies and consequent enhancements to architectural

approaches dictate systematic review of implemented standards for applicability
and modification, and issuance of new standards to reflect architectural modifi-
cations as well as innovations, such as universal indexing platforms, etc.

• A
policy that requires adherence to standards
• Standards artifacts
• S
tandards approval process
• S
tandards change request process
• P
roject references to standards
• G
uidance for incorporating standards into design
Level 3: Defined
3.1 Architectural standards are followed across the organization.

Standards are applied to new development, redesigns, consolidations, and
enhancements to existing data stores as manifested throughout the entire
lifecycle—from modeling through any normal production changes or releases.
The commitment to create and enforce standards is a discipline that pays
dividends over time; adherence to standards is essential. A clear, explicit
exception process facilitates compliance, as project teams sometimes resist
applying architectural standards, citing schedule or budget grounds. An
architecture review board, with oversight from data governance, should
adjudicate exceptions.
3.2 External requirements applicable to the organization are included in data

architecture standards development.
External requirements can be for regulatory reporting, information exchange,

or compliance purposes. Depending on the business need of the organization
to adopt or adapt standards driven by external requirements (e.g., regulatory
bodies, industry exchange standards), approaches to standards adoption and
integration may utilize any of the following:
• Inclusion within the body of internally produced standards when not
contradictory
• Creation of externally facing transformations to meet requirements that

are defined and approved by review boards and associated governance

• Creation of distinct data stores, on which no internal business functions
are dependent, for external reporting
3.3 Stakeholder roles and responsibilities for architectural standards include

compliance accountability, ownership, and training.
A fully formed standards development process includes activity steps,

milestones, gates, clear roles and responsibilities, and governance structures
used to develop, maintain, measure, audit, and revise standards as needed.
3.4 Data governance ensures that architectural standards are aligned with
business needs and aligned with the organization’s senior architecture
governance body.
The process of proposing and developing standards is typically led by

the data management function or IT, depending on the application of the
standard. For example, IT or Enterprise Architecture usually develops data
access standards, and the data management function often serves as the lead
for developing standards pertaining to business data and the intersection
of business considerations into the IT environment, such as data modeling
standards. Once developed, additions and modifications are reviewed and
approved by data governance.
3.5 Metrics for monitoring and controlling adoption of, and compliance to,
architectural standards are defined and implemented.
Because consistent and correct use of standards provides strong support

for good design practices and shareability, and the best proactive defense
against ever-increasing complexity, a strong compliance program is essential.
Metrics assist each project team in evaluating their contribution to the quality
and structure of data assets; collectively, compliance metrics inform the
organization about the reach and effectiveness of standards.
3.6 An audit process is developed, documented, and performed for evaluating

compliance to architectural standards.
A configuration controlled auditable list of enabling technologies used to

support standards development and management may include data modeling
tools, data discovery tools that assess compliance or deviation as part of
audit activity, and scripts for requisite external transforms.
Within the systems development lifecycle, audits of data models, data access
methods, and data distribution designs should be based on uniformly applied
standards.

• Compliance or regulatory reporting standards and requirements
• Standards development and modification process
• Standards tailoring guidance
• Standard exceptions process
• Audit results reports

• Architecture review board (or equivalent governance body) meeting notes
• Proposals for data standards that are based on compliance and

regulatory data requirements
• Data standard policies and procedures
Level 4: Measured
4.1 Audit result metrics and internal deviation patterns indicate where changes
to data architecture standards and enhanced guidance for standards appli-
cation are needed.
4.2 The organization conducts risk-based impact analysis for proposed changes to
organizational data architecture standards and guidance prior to acceptance.
The organization group(s) leading standards development should apply

metrics and risk factors to create impact analysis assessments for proposed
changes to standards.

• Standards review documentation (action items, minutes, etc.)
• Impact analysis for proposed changes to standards
• Architectural standards compliance metrics
Level 5: Optimized
5.1 Feedback is provided to external stakeholders on new or proposed changes

to data standards.
For example, a regulator may provide new requirements for review; the
organization would assess these requirements and provide input on feasi-
bility, burden, and may suggest possible modifications.
5.2 The organization contributes to data architecture standards initiatives within

its industry.
5.3 The organization researches innovative data technologies and methods for
potential adoption, and develops appropriate new standards for those which
are deployed.
5.4 The organization shares best standards practices and lessons learned
through publications, conferences, and white papers.

• Evidence of engagement with external standards bodies
• Research of emerging technologies
• Proposed standards for future technologies likely to be adopted
• Presentations and other published work related to data standards

Data Management Platform
PURPOSE
Ensures that an effective platform is implemented and managed to meet business
needs.
INTRODUCTORY NOTES
A data management platform (singular or plural) serves as a system of record, a
trusted source or authoritative source of data. The platform typically includes assets
used for data distribution, transformation, and integration into consuming applica-
tions.
Organizations view the data management platform as the overall technological

ecosystem, managed under common authority (a person, a group, a standard, an SLA,
a policy), although there is typically more than one physical platform. An organization
usually hosts a collection of applications and enabling technologies to manage
data across business lines and to meet data management objectives. All practices
described in this process area in the platform and architecture category apply to each
platform and its components.
Data management platforms significantly impact data management performance.

Therefore, the data management platform selection process should align with the data
management and data quality strategies to ensure that required features and capabil-
ities will be supported.
To support “build versus buy” decisions, an inventory and gap analysis should be
conducted for existing systems and capabilities, at a sufficient level of detail to
consider extending the use of existing platforms. Organizations should be prepared
for implementation in phases over an extended period. Organizational standards and
blueprints must be followed to develop or acquire and implement the target platform.
GOALS
1. The platforms satisfy the approved requirements and architecture.
2. Processes exist and are followed for effective platform management to meet
business needs.
3. The platform is supported by adequately trained and skilled personnel.
4. The platform provides trusted data.
CORE QUESTIONS
1. How are authoritative data sources defined, selected, and integrated into
particular portions of the platform?
2. How does the organization address overlapping platforms and data

duplication?
3. Does the organization have a process for making “build versus buy” decisions?
132 Data Management Platform

4. How does the organization address platform scalability, security, and resiliency
in accordance with anticipated growth of data, users, and overall complexity?
5. What forms of data, data exchange, and interfaces are supported by the
platform?

Refer to the results of executing the practices in Data Management Strategy.
Governance Management and Data Management Function provide information related

to stakeholder role expectations and governance oversight of these activities.
Business Glossary and Metadata Management provide guidance for identification,

classification, and management of this type of information.
Data Lifecycle Management provides information on where data is used.
Data Quality Strategy provides information related to quality dimensions.
Level 1: Performed
1.1 Data management platforms and components are documented.
For example, automated systems and technologies that are used within
projects to manage critical data are identified and documented.
Example Work Product

• Inventory of data management platforms and components
Level 2: Managed
2.1 The platform implementation supports the target objectives set out in the
data management strategy.
During platform development, and prior to release, verify and validate the
platform against the objectives specified in the data management strategy.
Refer to the Data Management Strategy.
2.2 A policy and process exists to ensure that build or buy decisions consider
the target data architecture and support the data management strategy.
2.3 Platforms are consistent with the technology stack and architectural
designs.
2.4 Platforms support the security and access requirements of the organization.
Platforms should be deployed implementing multilevel access that is driven
by lines of business, and managed under a separation-of-duties principle to
enforce access restriction.

2.5 The executive data governance body advises and consents about major
platform decisions.
Typically, governance uses a framework to document and assess competing

platform solutions and options. This framework should include criteria to
guide decisions.
See Governance Management and Data Management Function for information

related to stakeholder role expectations and governance oversight of these
activities.

• Data management platform documentation
• Approved deployment, and conversion and migration plans
• D
ocumented stakeholder involvement (including governance) in the
design and approval of data management platform deployment plan
• Documented platform decisions with rationale
Level 3: Defined
3.1 Critical data elements for which the platform is an authoritative source,
trusted source, or system of record are documented.
Refer to Business Glossary and Metadata Management for more guidance on

identification and management of this type of information.
Data Lifecycle Management provides information on where data is used.
Data Quality Strategy provides information related to quality dimensions.
3.2 Data set duplication across systems is documented, planned, and justified.
Data redundancy is confusing to users, negatively impacts business
operations, is expensive, and contributes considerably to the complexity of
the data management environment. Nonetheless, there are rational justifi-
cations for duplicating data to meet specific functionality and performance
requirements; for example, preprocessing large data sets for a data mining
application versus for a data warehouse.
In cases where data duplication is intentional, it should be documented and in

each case the costs associated with keeping duplicate sources synchronized
(including the impacts where data cannot be kept synchronized) are justified
against the expected benefits to the organization.
3.3 Platform implementation plans address the scalability, resiliency, and

security needed to accommodate changes in anticipated complexity as well
as the volume of data and number of users.
3.4 Platform design and capabilities ensure that work flow and service level
requirements can be met.
3.5 Platform performance data is captured, stored, and used to verify that the
platform meets business performance needs and capacity requirements.

3.6 The platform contributes its metadata to the organization’s metadata repos-
itory.
Refer to Business Glossary and Metadata Management for more guidance on

identification and management of this type of information.

• Documentation mapping critical data elements to platforms
• Documentation identifying and justifying data duplication
• Platform implementation plan
• Platform architecture designs
• Platform performance data
• Service level requirements
• Platform metadata
Level 4: Measured
4.1 Qualitative and quantitative performance metrics for the data management
platform are analyzed, using statistical and other quantitative techniques, to
support platform change decisions.

• Metrics to measure both qualitative and quantitative performance of data
management platform
• Measurement and analysis plans
• Statistical analysis according to the measurement plan
• Approved decisions based on analysis of metrics
Level 5: Optimized
5.1 Platform improvement objectives are quantitatively expressed and approved

by governance.
5.2 The organization continuously improves the platform based on statistical

performance data and causal analysis.
The data management platform is optimized using performance prediction

models.
5.3 The effects of platform changes are compared with prediction models and
analyzed to improve the prediction models.
5.4 The organization is sharing its experiences related to design, development,

deployment, and operation of the data management platform within its
industry.

• Causal analysis (defect classifications, pert diagrams, etc.)

• Performance prediction models
• Approvals for improvements
• Predicted versus actual performance analyses
• Approved optimization plans
• Public presentations and other formal and informal documents related to

data management platform

Data Integration
PURPOSE
Reduce the need for the business to obtain data from multiple sources, and to
improve data availability for business processes that require data consolidation and
aggregation, such as analytics. Data integration enables source data optimization, the
realization of cost savings through centralization, and improved data quality.
INTRODUCTORY NOTES
Data integration addresses data transport and processing (connecting, combining,
de-duplication, etc.) from multiple sources into a destination environment. Data
integration challenges include diverse data representations in multiple sources, ratio-
nalizing business meaning, and the complexity of transformation logic.
Typically, data integration is concerned with data transfer and consolidation among
applications, and data integration from transactional systems or external sources into
a shared repository. The scope of data integration is both broad and detailed. Relevant
stakeholders need to understand the components and dependencies for project
delivery, and the iterative phases of planned integration efforts. Business stake-
holders need to take a long-term perspective, which implies flexibility in addressing
integration obstacles.
Successful integration efforts depend on continual collaboration. Business users need

to establish and validate the business rules used for transformation or consolidation,
and IT needs to understand the intended business use and implement the business
rules within the context of the organization’s integration and data standards. The data
management function, representing consistency of standards application, updates to
the business glossary, and other organization-wide considerations are also involved.
Due to changing business needs, the existing integrated environment should be
periodically reviewed for representational consistency and its alignment with business
requirements.
GOALS
1. Establish and follow a consistent process to ensure ongoing business and
technology alignment for data integration.
2. Data integration is performed utilizing standard processes and tool sets that
enable compliance with data architecture standards and data quality require-
ments.
3. Proactively research and evaluate integration technologies for application and

adoption.
4. Establish and manage data conversion, transformation, and enrichment

disciplines so that the data is fully processed and meet quality standards
before they enter the integration environment.

CORE QUESTIONS
1. How are data consolidation needs assessed?
2. How is future redundancy minimized?
3. How does the organization consolidate data effectively where redundancy

exists?
4. Do data integration standards exist, and are they reviewed, monitored,

approved, and enforced?
5. Describe the compliance processes employed to enforce integration

standards.
6. How are data quality thresholds and targets applied to sources of data at
ingestion and integration?
7. Are the processes to identify missing data automated, and does tracking
against defects or gaps support remediation?
8. How is adequate staffing ensured for monitoring, managing, and sustaining

data quality for ingestion and integration?

Data Quality Strategy provides guidance on expectations and standards for quality
checks and understanding data quality dimensions.
Metadata Management provides more information on establishing the processes and

infrastructure for specifying and extending clear and organized information about
the data assets under management, to increase data sharing, ensure compliant use of
data, increase responsiveness to business changes, and reduce data-related risks.
Architectural Standards provides more information on providing an approved set of

expectations for governing architectural elements regarding approved data represen-
tations, data access, data integration, and data distribution, which are fundamental to
data asset control and the efficient use and exchange of information.
Data Lifecycle Management provides information on the uses and needs of data across
the organization.
Data Profiling provides more information on developing an understanding of the

content and the quality of a specified set of data under management.
Level 1: Performed
1.1 Data integration occurs between systems.
An example is a production database administrator (DBA) manually initiating

multiple integration scripts in a predetermined order, or making manual
changes to correct defective data.

• Data integration scripts
Level 2: Managed
2.1 Data integration plans are documented.

Project documentation for data integration should include the following
topics:
• Identification of data scope
• Identification of vendors and source systems (and SLA)
• Identification of data growth and data retentions
• Identification of applicable data standards
• Integration sequence of sources
• Decision guidance related to data trust (e.g., precedence)
• Analysis using quality dimensions
• Change-data capture rules
• Profiling guidance
• Conformance and transformation rules
• Import exception handling
• Roles and responsibilities of stakeholders and data management staff
• Validation against business requirements
• Expectations for impact analysis
• Expectations for integration testing
• Expectations for backout triggers
• Risk mitigation planning for data backup and recovery
• Data archive process
• Data privacy protection
• Data access matrix for different groups of users
2.2 The set of data integration disciplines and tools used by the organization
provides bulk transport and load, change data capture, versioning and
configuration, metadata capture and management, and in-line data quality
checks and controls.
Data transfer from sources to destinations typically requires complex rules,

data transformations, and data standardization. To accomplish these tasks
consistently and with the least amount of risk, specialized tools designed to
support physical capture and movement of data should be applied, but they
can also be used to provide basic analysis of the data and transformations.

These tools facilitate maintenance of the metadata associated with ETL
processes and provide a means to make changes in a controlled fashion.
Refer to Metadata Management for more information on establishing

the processes and infrastructure for specifying and extending clear and
organized information about the data assets under management, to increase
data sharing, ensure compliant use of data, increase responsiveness to
business changes, and reduce data-related risks.
Refer to Architectural Standards for more information on providing an

approved set of expectations for governing architectural elements regarding
approved data representations, data access, and data distribution, funda-
mental to data asset control and the efficient use and exchange of infor-
mation.
2.3 A change control process is established and followed to ensure that changes
to the integration environment, including upstream sources and downstream
targets, are controlled and coordinated.
Changes to operational systems often have a direct impact on the data which
are stored or managed by those systems and subsequently used by other
downstream systems. Examples of downstream systems include both repos-
itories (e.g., data warehouse) and other operational systems that rely on the
data from the source system.
2.4 Remediation processes are established and followed to address selected

abnormal circumstances.
It is important for the the business to have confidence that the system it
depends on is managed proactively—the business maintains data availability
and integrity by having plans for dealing with potential interruptions and
unforseen events, including load interruptions or data validation failures.
2.5 Integration verification is performed to ensure that architecture and

interface specifications are documented and will be met prior to being
released into production.
Refer to Architectural Standards for more information related to interface and

integration expectations.

• Data integration standards
• Verification and validitation plans
• Integration test environments
• Application programing interfaces (APIs)
• Data integration policy
Level 3: Defined
3.1 The organization follows a standard set of practices and rules for performing
data integration activities.

3.2 Quality checks are defined as part of the organizational integration standard
and performed as part of data integration processes.
For example, the ETL process should perform a basic level of quality control
checks, especially for subsequent change-data capture loads, to ensure that
the data being integrated meets the quality attributes defined by the
organi-zation. These checks should define criteria by which the data is
rejected, flagged, or queued as exceptions for subsequent action.
Failure to perform this check at integration may cause problems with the
data that can be unknown for long periods of time and require greater
cleanup efforts later. The organization may want to verify that the following
tasks are performed:
• Data is profiled
• Data is complete and accurate by attribute
• Logic is instituted to handle missing data
• Provisions for alternative sources exist if data is not available from the
preferred source
• Data quality and error handling reports are produced and monitored
Data Quality Strategy process area provides guidance on expectations and

standards for quality checks and understanding data quality dimensions.
3.3 A standard process is established and followed to create and verify data
precedence rules with business users based on use cases, requirements, and
selected triggers.
Often, multiple sources contribute to data integration into a single logical

destination, such as operational systems contributing to a data warehouse. In
these instances, it can be expected that more than one source may contribute
data that is the same or similar to data from other sources. In this example,
during the final ETL process that feeds the single repository, it is necessary
to establish and apply precedence and conformance rules to guide the final
integration.
The results of performing Data Lifecycle Management practices provide input

to this process area by helping to understand the use and need of the organi-
zation’s data.
3.4 The development and deployment of integration interfaces are specified in

accordance with architectural standards supporting re-use.
Some examples include consolidated interfaces and common data services.

Data integration rules and performance requirements are clearly defined.
Interfaces between systems should be well documented to support future
changes, as well as provide a means for accommodating integration to or
from additional systems. Development of these interfaces should follow
common programming practices for defining and documenting application
programming interfaces (APIs). Organizational standards should exist to
guide these activities.

Interfaces should also be included in the complete technical data package,
and managed following the organization’s configuration management
processes and standards.
3.5 Interface and integration performance metrics are collected and analyzed to
identify nonconformance with standards and criteria.
For example, tracking of defects is performed to monitor defect severity,

causes, statistical occurrence, and plan resolutions.
3.6 The organization documents and manages changes to data sources and
destination through the data governance process.

• Verification and validation results
• Performance requirements
• Performance metrics and analysis results
• Measures and metrics for continuous improvement in data quality
• Data delivery policy and SLAs
• Integration method standards
• Integration best practices guidance
• Standard interface specifications
• Integration environment change management process
Level 4: Measured
4.1 Statistical analysis of integration metrics guides decisions on changes to

interfaces and integrations.
Variation criteria (i.e., tolerance limits) are specified and used in the analysis
of interface performance. For example, analysis of data profiling results may
indicate that the volume of integration-related defects is within an acceptable
tolerance.
4.2 Selected highly shared data is fully integrated, centrally managed, and
delivered as needed to integration data stores.
An organization’s business processes that rely on highly shared data (e.g.,

reference data, master data, etc.) are greatly affected by discrepancies—
differences in timeliness, representation, and values—in vital information
about key entity types, such as customer, account, product, organization, etc.
A specific goal of data integration is to streamline, standardize, centralize,
and provide trusted shared data most needed by multiple lines of business
and multiple business purposes.
The results of Data Lifecycle Management provide input to this practice by

helping to understand the use and need of data across the organization.

• Statistical analysis results
• Data profiling analyses
• Consolidated highly shared data with continuous improvement
Level 5: Optimized
5.1 Performance models for data integration are periodically reviewed, and are
used as input for enhancements.
5.2 The organization publishes and shares integration best practices within its
industry.

• Quantitative models
• Performance triggers and thresholds
• Root cause analysis results
• Presentations, white papers, or published articles

Historical Data, Retention and Archiving
PURPOSE
Ensure that data maintenance will satisfy organizational and regulatory requirements
for historical data availability, and that legal and regulatory requirements for data
archiving and retention of data are met.
INTRODUCTORY NOTES
Historical data retention and management serves multiple business purposes. It
defines how data history will be managed (e.g., changes to data, versioning) as well as
for managing data in the later stages of the lifecycle, including:
• Data and records retention and archiving
• Reduction of primary data store size to improve production performance
• Restoration of a data state from a point in time
• Assurance that internal and external retention requirements are met
The primary goals for historical data is to ensure that it is maintained by the organi-
zation and is managed in a consistent manner to meet business needs. To accomplish
this, the organization also needs to define criteria for data retention, as well as a
standard process and set of guidelines for data archiving. Often, these guidelines
are driven by regulatory requirements that dictate mandatory retention periods,
encryption, or edit-ability of the archived data.
The organization should have a clear understanding of its internal and external
requirements for data retention. This is typically a combination of regulatory and
business requirements. It is advisable to ensure that each line of business is aware of
and has clearly defined its current retention requirements for its existing data stores
and planned initiatives. This is the precursor to developing an archiving policy and
strategy.
Historical data may be maintained under two broad models: online and accessible,
or archived. The organization is advised to define a core set of rules for representing
and implementing data history, subject to tailoring (e.g., data modeling rules, history
updates, etc.) to gain efficiencies from standardizing an approach and conventions
over time. For effective management of historical data, the organization should
collect, discover, and review major requirements for history within business processes
(e.g., forecasting, reporting, and operational processes) as well as regulatory
compliance. These considerations will outline these high-level requirements. Each
application data store or data warehouse component will have specific historical data
needs.
A defined process for archiving should require the specification of business rules
that are applied to determine when data is archived, and how it must be stored and
accessible or available for restoration. For example, a federal agency may have a
regulatory requirement to retain citizen records for seven years after the status of
the individual has reached a completion state (inactive, deceased, etc.). To determine
144 Historical Data, Retention and Archiving

which records meet this criterion, it is useful to periodically monitor data stores for
archive-ready records. In addition, specific business rules may dictate additional
constraints; for example, “A citizen record may not be archived if an appeal has been
filed within the last five years.” Lastly, performance gains are likely to be supported by
archiving aged data; performance monitoring against established thresholds can be
applied to indicate the need to archive.
When data is archived, it is recommended to establish an authoritative source of the

aged data to be maintained, including a record of the system or user who made any
change and the date and rationale for the change. Determination of whether the data
can be in a writable form (versus read only) must be made, as well as consideration
of accessibility by data priority and use (e.g., near-line versus remote, etc.) and other
security rules.
This process area defines how
• B
usiness requirements for understanding, defining, and managing criteria
for historical data archiving, retention, deletion, and retrieval are supported;
integrated; published; communicated through policies, processes, and
standards; and monitored for conformance.
etention rules, archiving scripts, deletion, and retrieval capabilities are

• R
deployed. Automating these features supports meeting business criteria, coordi-
nating development and execution of data retention and archiving, and applying
defined performance thresholds. These capabilities also include physical data
controls, storage retrieval methods, data archival, and retrieval.
GOALS
1. Historical data is managed consistently, leveraging common standards.
2. Business needs for capturing and storing historical data are met.
3. An approved process for determining when and how data should be archived
is followed, containing defined activity steps.
4. Data retention periods are consistent with both legal and regulatory require-
ments.
5. Data archives reflect organizational and regulatory requirements.
CORE QUESTIONS
1. What are the architectural standards and conventions applied to the structure
and management of historical data, and how are the corresponding business
rules defined and governed?
2. How is data retention for the required length of time assured?
3. How is the integrity of archived data maintained?
4. Is there a consistent approach for the retrieval and integration of archived

historical data with current data?
5. How is an audit trail for data changes monitored and managed?

6. What considerations are applied to determine when archived data can be
deleted?

Data Requirements Definition provides information about capturing and representing
data requirements.
Architectural Approach contains information about defining high-level business

requirements for data assets and capabilities.
Governance Management and Data Management Function provide more information

related to stakeholder role expectations and governance oversight of these activities.
Level 1: Performed
1.1 Historical data is available and used to support business decisions.
1.2 All data stores are backed up and data is archived as prescribed in policies.
Based on policies and continuity of operations requirements, some sets
of data backups may be stored in a separate location to mitigate risks
associated with the primary data location. This is typically on a different
server and may also be included in a continuity of operations environment.
It is also important for data change logs to be retained according to

documented guidance. Data change logs should typically capture things such
as the ID of the user or process that made the change, as well as the date
and time of the change. Data retention guidance should be published and
followed.

• Backup registers for data stores and data archives
• Archiving procedures
• Change log files
• Data retention business rules
• Data archiving or destruction procedures
Level 2: Managed
2.1 Policies mandate management of data history, including retention,

destruction, and audit trail requirements.
2.2 A defined method ensures that the historical data necessary to support
business needs is accessible.
These decisions are commonly based on both technology policy and business
requirements.

Refer to Data Requirements Definition for more information related to deter-
mining and managing data requirements.
2.3 Restoration testing is performed on selected archived data.

Not all archived and backed up data is expected to be restored, but it is
important to establish a standard set of practices (supported by policy) that
perform periodic restoration tests to ensure that the procedures for resto-
ration are accurate and the technology is available to perform the restoration.
These tests should be performed across the various types of technology used
by the organization.
2.4 Access, transmittal, and modifications to historical and archived data are
controlled by policy and processes.

• Data retention policies
• Restoration testing records
• Encrypted archives
• Data encryption requirements
• Archived data access tests
Level 3: Defined
3.1 The organization has a prescribed data warehouse repository that provides
access to historical data for meeting analytics needs supporting business
processes.
Execution of the practices in the architectural approach should define the

method by which this practice should be satisfied.
3.2 Data context at any specific point in time can be recreated.

When developing guidance for backups and restoration capabilities, the
organization should also ensure that recovery time objectives are clearly
stated to provide guidance on how quickly access to restored data must be
available.
3.3 Policy is defined and approved by data governance and implemented at the
organizational level requiring logging of data changes, and retention of the
logs.
Data logging, retention, and archive policies should be aligned with

regulatory requirements.
3.4 An audit program ensures compliance with organizational data logging,

archive, and retention policies.
The program should include validation of the types of data or logs that are
retained for various specified periods, restoration testing of backups and
archives, and retention and maintenance of technology to support access to
archived data.

See the Governance Management and Data Management Function process
areas for more information related to stakeholder role expectations and
governance oversight of these activities.
3.5 A feedback mechanism exists with stakeholders and regulators to affirm

existing retention and archiving policies.

• Restoration procedure documentation
• Application with access to historical data
• Data logging policy including log retention
• Data archive requirements
• Archive backup and restoration requirements
• Restoration testing records for archived data
• Audit and test records
Level 4: Measured
4.1 Statistical and other quantitative techniques are used to analyze historical
data for input to business process and data quality improvements.
4.2 Models are employed to predict compliance with legal and regulatory
requirements.
4.3 Metrics results and stakeholder feedback are used to improve data retention
and archiving policies.

• Improvement process
• P
rocess improvement reports and records
• C
hange management records
• R
egulator or stakeholder feedback
• S
tatistical and other quantitative analysis reports
Level 5: Optimized
5.1 The organization shares policies and best practices regarding historical data
and archiving within its industry.

• Public presentations, white papers, articles, and other documents
communicating processes and experience


6 Supporting 152
Measurement and
Analysis
Processes 168
Process
Management
Process Quality
187
Assurance
193 Risk Management
Configuration
206
Management
150 Supporting Processes

Supporting Processes
Definition of the business processes and capabilities
required for assessment and implementation of data
management effectiveness in all process areas.
This section contains a set of foundational processes that supports adoption, execution, and
improvement of data management processes.
Measurement and Analysis addresses measures and select analytical techniques for iden-
tifying strengths and weaknesses in data management processes. Process Management
addresses a usable set of organizational process assets, and plans, implements, and deploys
organizational process improvements informed by the business goals and objectives and the
current gaps in the organization’s processes. Process Quality Assurance provides staff and
management with objective insight into process execution and the associated work products.
Risk Management identifies and analyzes potential problems to take appropriate action to
ensure objectives can be achieved. Configuration Management addresses the integrity of the
operational environment using configuration identification, control, status accounting, and
audits.
Supporting Processes 151

Measurement and Analysis
PURPOSE
Develop and sustain a measurement capability and analytical techniques to support
managing and improving data management activities.
INTRODUCTORY NOTES
Defines capabilities for measurement, including the creation of measurement objec-
tives and the mechanisms to perform the following tasks:
• Obtain
• Store
• Analyze
• Abstract
• Aggregate
• Report
• Interpret results and impacts to identify candidate remediation actions
Measurement and analysis reveals issues to be managed, provides a means for

objective feedback to stakeholders, and helps in maintaining the alignment of data
management to business objectives. Measurement and analysis includes the topics
below:
• Business objectives
• Design, development, execution, and modification of business processes
• Implementation of a cost-benefit review mechanism
• Prioritization of data management improvement initiatives based on organiza-

tionally defined criteria
Measurement and analysis provides visibility into the performance of the data
management program. This process area involves the following activities:
• Specifying objectives of measurement and analysis so that they are aligned with
identified information needs and objectives
• Specifying measures, analysis techniques, and mechanisms for data collection,

storage of measurement data, reporting, and feedback
• Implementing the analysis techniques and mechanisms for data collection, data
reporting, and feedback
• Providing objective results that can be used in making informed decisions and
taking appropriate remediation action
The integration of measurement and analysis activities into data management

processes supports the following:
• Objective planning and estimating
152 Measurement and Analysis

• Tracking actual progress and performance against established plans and objectives
• Identifying and resolving process related issues
• Providing a basis for incorporating measurement into additional processes in

the future
• When designing the data management measurement and analysis function, it is

important to address key topics:
• The need for new measurements
• Integration of remedial actions into the data management process
• Governance review of proposed measures to validate their relevance to business

objectives
• Measures emphasizing the most critical business processes
GOALS
1. A set of metrics that measures the satisfaction of the data management
program’s objectives is established and used.
2. The process of measuring data management capabilities and improvements

based on defined metrics is established and used.
3. Stakeholders are kept well informed about the status of the data management
program and its component processes based on measurements and analysis.
4. Organization-wide access to data management measurements and analysis

results is provided.
CORE QUESTIONS
1. What measures and analyses exist to determine if data management goals and
objectives are being met?
2. How does the organization define, measure, analyze, and report on data
management?
3. How are measurements and analyses integrated into data management

processes?

This process area pertains to all data management process areas.
Level 1: Performed
1.1 Data management measurement and analysis is performed.

• Data management reports
• Metrics data
• Analysis results

Level 2: Managed
2.1 Establish and maintain measurement objectives derived from identified

information needs and objectives.
Measurement objectives document the purposes for which measurement and

analysis are done and specify the kinds of actions that can be taken based on
results of data analysis. Measurement objectives can also identify the change
in behavior desired as a result of implementing a measurement and analysis
activity.
Measurement objectives may be constrained by existing processes, available

resources, or other measurement considerations. Judgments may need to be
made about whether the value of the result is commensurate with resources
devoted to doing the work.
Modifications to identified information needs and objectives can in turn be

indicated as a consequence of the process and results of measurement and
analysis.
Sources of information needs and objectives can include the following:

• Work plans
• Work performance monitoring
• Process improvement plans
• Data management scorecards
• Interviews with managers and others who have information needs
• Established management objectives
• Strategic plans
• Business plans
• Recurring or persistent problems
• External industry benchmarks
Example measurement objectives include:

• Provide insight into schedule fluctuations and progress
• Provide insight into actual effort compared to plan
• Identify unplanned growth of data assets
• Determine the cost of correcting defects
• Provide insight into actual costs compared to plan
The steps involved in establishing and maintaining measurement objectives

typically involve:
1. Document information needs and objectives.
2. Prioritize information needs and objectives.

It is neither possible nor desirable to subject all initially identified infor-
mation needs to measurement and analysis. Priorities also need to be set
within the limits of available resources.
3. Document, review, and update measurement objectives.
Carefully consider the purposes and intended uses of measurement and

analysis.
The measurement objectives should be documented, reviewed

by management and other relevant stakeholders, and updated as
necessary.
It is important that users of measurement and analysis results be

involved in setting measurement objectives. It may also be appropriate
to involve those who provide the measurement data.
4. Provide feedback for refining and clarifying information needs and objec-
tives as necessary.
Identified information needs and objectives can be refined and clarified

as a result of setting measurement objectives. Initial descriptions of infor-
mation needs may be ambiguous. Conflicts can arise between existing
needs and objectives. Precise targets on an already existing measure may
be unrealistic.
5. Maintain traceability of measurement objectives to identified information

needs and objectives.
A good answer to the question, “Why are we measuring this?” should

always be known.
Measurement objectives can also change to reflect evolving information

needs and objectives.
2.2 Specify measures to address measurement objectives.

Measurement objectives are refined into precise, quantifiable measures.
Measures can be either base or derived. Data for base measures are obtained
by direct measurement. Data for derived measures typically come from
the combination of two or more base measures. Derived measures are
typically expressed as ratios, composite indices, or other aggregate summary
measures. They often are more quantitatively reliable and meaningfully inter-
pretable than the base measures used to generate them.
Traceability between the objectives and the measures is clear, available, and
bidirectional between the objective and the measure.
Examples of commonly used base measures include the following:

• Estimates and actual measures of effort and cost (e.g., number of person
hours)
• Quality measures
• Customer satisfaction survey scores

Examples of commonly used derived measures include quality measures and
customer satisfaction trends.
Direct relationships exist among information needs, measurement objectives,

measurement categories, base measures, and derived measures.
Specification of measures typically involves the following:

1. Identify candidate measures based on documented measurement objec-
tives.
Measurement objectives are refined into measures. Identified candidate

measures are then categorized and specified by name and unit of
measure.
2. Maintain traceability of measures to measurement objectives.
Interdependencies among candidate measures are identified to enable

later data validation and candidate analyses in support of measurement
objectives.
3. Identify existing measures that already address measurement objectives.
Specifications for measures may already exist, perhaps established for

other purposes earlier or elsewhere in the organization.
4. Specify operational definitions for measures.
Operational definitions are stated in precise and unambiguous terms.

They address two important criteria:
• Communication: What has been measured; how was it measured;

what are the units of measure; and what has been included or
excluded?
• Repeatability: Can the measurement be repeated, given the same

definition, to get the same results?
5. Prioritize, review, and update measures.
Proposed specifications of measures are reviewed for their appro-

priateness with potential end users and other relevant stakeholders.
Priorities are set or changed, and specifications of measures are updated
as necessary.
2.3 Specify how measurement data is obtained and stored.

Specification of collection methods helps to ensure that the right data is
collected properly. This specification can also help to further clarify infor-
mation needs and measurement objectives.
Proper attention to storage and retrieval procedures helps to ensure that

data is available and accessible for future use. Traceability of the supporting
data for the measurements is established, maintained, and used.
Obtaining and storing the data typically involves the tasks listed here:
1. Identify existing sources of data that are generated from current work
products, processes, or transactions.

Existing sources of data may have been identified when specifying the
measures. Appropriate collection mechanisms may exist whether or not
pertinent data have already been collected.
2. Identify measures for which data is needed but are not currently
available.
3. Specify how to collect and store the data for each required measure.
Specifications are made of what, how, where, and when data will be
collected and stored to ensure its validity and to support later use for
analysis and documentation purposes.
Questions to be considered typically include the following:
• Has the frequency of collection and the points in the process where
measurements will be made been determined?
• Has the timeline required to move measurement results from points

of collection to repositories, other databases, or end users been
established?
• Who is responsible for obtaining data?
• Who is responsible for data storage, retrieval, and security?
• Have necessary supporting tools been developed or acquired?
4. Create data collection mechanisms and process guidance.
Data collection and storage mechanisms should be well integrated with

other normal work processes. Data collection mechanisms can include
manual or automated forms and templates. Clear, concise guidance on
correct procedures is available to those who are responsible for doing
the work. Training is provided as needed to clarify processes required to
collect complete and accurate data and to minimize the burden on those
who provide and record data.
5. Support automatic collection of data as appropriate and feasible.
Examples of such automated support include the following:
• Time stamped activity logs
• Static or dynamic analyses of artifacts
6. Prioritize, review, and update data collection and storage procedures.
Proposed procedures are reviewed for their appropriateness and

feasibility with those who are responsible for providing, collecting, and
storing data. They also may have useful insights about how to improve
existing processes or may be able to suggest other useful measures or
analyses.
7. Update measures and measurement objectives as necessary.

2.4 Specify how measurement data is analyzed and communicated.
Specifying analysis procedures in advance ensures that appropriate analyses
will be conducted and reported to address documented measurement
objectives and thereby the information needs and objectives on which they
are based. This approach also provides checks that ensure the necessary data
will, in fact, be collected. Analysis procedures should account for the quality
(e.g., age, reliability) of all data that enter into an analysis. The quality of data
should be considered to help select the appropriate analysis procedure and
evaluate the results of the analysis.
Specifying how data is analyzed and communicated involves:

1. Prioritize the analyses to be conducted and the reports to be prepared.
Early on, pay attention to the analyses to be conducted and to the

manner in which results will be reported. These analyses and reports
should meet the following criteria:
• The analyses explicitly address the documented measurement objec-

tives.
• Presentation of results is clearly understandable by the audiences to

whom the results are addressed.
Priorities may have to be set for available resources.
2. Select appropriate data analysis methods and tools.
Issues to be considered typically include:
• Choice of visual display and other presentation techniques (e.g., pie

charts, bar charts, histograms, radar charts, line graphs, scatter plots,
tables)
• Choice of appropriate descriptive statistics (e.g., arithmetic mean,

median, mode)
• Decisions about statistical sampling criteria when it is impossible or

unnecessary to examine every data element
• Decisions about how to handle analysis in the presence of missing

data elements
• Selection of appropriate analysis tools
Descriptive statistics are typically used in data analysis to:

• Examine distributions of specified measures (e.g., central tendency,
extent of variation, data points exhibiting unusual variation)
• Examine interrelationships among specified measures (e.g., compar-

isons of defects found in a peer review vs. size of product examined)
• Display changes over time
3. Specify administrative procedures for analyzing data and communicating

results.

Issues to be considered typically include the following:
• Identifying the persons and groups responsible for analyzing the

data and presenting the results
• Determining the timeline to analyze the data and present the results
(schedule, frequency, phases in the data lifecycle, etc.)
• Determining the venues for communicating the results (e.g., progress

reports, transmittal memos, written reports, staff meetings)
4. Review and update the proposed content and format of specified

analyses and reports.
All of the proposed content and format are subject to review and
revision, including analytic methods and tools, administrative procedures,
and priorities. Relevant stakeholders consulted should include end users,
sponsors, data analysts, and data providers.
Update measures and measurement objectives as necessary.
Just as measurement needs drive data analysis, clarification of analysis

criteria can affect measurement. Specifications for some measures may
be refined further based on specifications established for data analysis
procedures. Other measures may prove unnecessary, or a need for
additional measures may be recognized.
Specifying how measures will be analyzed and reported can also suggest
the need for refining measurement objectives themselves.
5. Specify criteria for evaluating the utility of analysis results and for evalu-
ating the conduct of measurement and analysis activities.
Criteria for evaluating the utility of the analysis might address the extent
to which the following apply:
• The results are provided in a timely manner, understandable, and

used for decision making
• The work does not cost more to perform than is justified by the
benefits it provides
Criteria for evaluating the conduct of the measurement and analysis may
include the extent to which the following apply:
• The amount of missing data or the number of flagged inconsis-
tencies is within specified thresholds
• There is no selection bias in sampling (e.g., only satisfied end users

are surveyed to evaluate end-user satisfaction, only unsuccessful
projects are evaluated to determine overall productivity)
• Measurement data is repeatable (i.e., statistically reliable)
• Statistical assumptions have been satisfied (e.g., about the distri-

bution of data, about appropriate measurement scales)

2.5 Obtain specified measurement data and ensure that it meets quality criteria.
The data necessary for analysis are obtained and checked for completeness
and integrity.
Obtaining and checking measurement data for quality involves the following
steps:
1. Obtain data for base measures.
Data is collected as necessary for previously used and newly specified

base measures. Existing data is gathered from project records or
elsewhere in the organization.
2. Generate data for derived measures.
Values are newly calculated for all derived measures.
3. Perform data integrity checks as close to the source of data as possible.
All measurements are subject to error in specifying or recording data. It

is always better to identify these errors and sources of missing data early
in the measurement and analysis cycle.
Checks can include scans for missing data, out-of-bounds data values,
and unusual patterns and correlation across measures. It is particularly
important to:
• Test and correct for inconsistency of classifications made by human

judgment (i.e., to determine how frequently people make differing
classification decisions based on the same information)
• Empirically examine the relationships among measures that are used

to calculate additional derived measures. Doing so can ensure that
important distinctions are not overlooked and that derived measures
convey their intended meanings (otherwise known as “criterion
validity”)
2.6 Analyze and interpret measurement data.

Measurement data is analyzed as planned; additional analyses are
conducted as necessary; results are reviewed with relevant stakeholders;
and necessary revisions for future analyses are noted.
Analyzing and interpreting data involves:

1. Conduct initial analyses, interpret results, and draw preliminary conclu-
sions.
Data analyses results are rarely self-evident. Criteria for interpreting

results and drawing conclusions should be stated explicitly.
2. Conduct additional measurement and analysis as necessary and prepare

results for presentation.
Results of planned analyses can suggest (or require) additional, unantic-

ipated analyses. In addition, these analyses can identify needs to refine
existing measures, to calculate additional derived measures, or even
to collect data for additional base measures to properly complete the

planned analysis. Similarly, preparing initial results for presentation can
identify the need for additional, unanticipated analyses.
3. Review initial results with relevant stakeholders.
It may be appropriate to review initial interpretations of results and

the way in which these results are presented before disseminating and
communicating them widely.
Reviewing the initial results before their release can prevent needless
misunderstandings and lead to improvements in the data analysis and
presentation.
Relevant stakeholders with whom reviews may be conducted include

intended end users, sponsors, data analysts, and data providers.
4. Refine criteria for future analyses.
Lessons that can improve future efforts are often learned from
conducting data analyses and preparing results. Similarly, ways to
improve measurement specifications and data collection procedures can
become apparent as can ideas for refining identified information needs
and objectives.
2.7 Manage and store measurement data, measurement specifications, and

analysis results.
Storing measurement-related information enables its timely and cost-ef-

fective use as historical data and results. The information also is needed to
provide sufficient context for interpretation of data, measurement criteria,
and analysis results.
Information stored typically includes these items:

• Measurement plans
• Specifications of measures
• Sets of data that were collected
• Analysis reports and presentations
• Retention period for data stored
• Measurement audit reports
Stored information contains or refers to other information needed to under-

stand, interpret, and assess the measures for reasonableness and applicability
(e.g., measurement specifications used on different projects when comparing
across projects).
Typically, data sets for derived measures can be recalculated and do not need
to be stored. However, it may be appropriate to store summaries based on
derived measures (e.g., charts, tables of results, report text).
Interim analysis results do not need to be stored separately if they can be

efficiently reconstructed.

Storing of measurement data, specifications, and analysis results typically
involves the following steps:
1. Review data to ensure completeness, integrity, accuracy, and currency.
2. Store data according to data storage procedures.
3. Make stored contents available for use only to appropriate groups and
staff members.
4. Prevent stored information from being used inappropriately.
Examples of ways to prevent the inappropriate use of data and related

information include controlling access to data and educating people on
the appropriate use of data.
Examples of the inappropriate use of data include:
• Disclosure of information provided in confidence
• Faulty interpretations based on incomplete, out-of-context, or

otherwise misleading information
• Measures used to improperly evaluate the performance of people or

to rank projects
• Impugning the integrity of individuals
2.8 Communicate results of measurement and analysis activities to all relevant

stakeholders.
The results of the measurement and analysis process are communicated

to relevant stakeholders in a timely and usable fashion to support decision
making and assist in taking corrective action.
Relevant stakeholders include intended end users, sponsors, data analysts,

and data providers.
Communication of measurement and analysis results to relevant stakeholders

typically involves the following steps:
1. Keep relevant stakeholders informed of measurement results in a timely
manner.
To the extent possible and as part of the normal way they do business,
users of measurement results are kept personally involved in setting
objectives and deciding on plans of action for measurement and analysis.
Users are regularly kept informed of progress and interim results.
2. Assist relevant stakeholders in understanding results.
Results are communicated in a clear and concise manner appropriate to

relevant stakeholders. Results are understandable, easily interpretable,
and clearly tied to identified information needs and objectives.
The data analyses are often not self-evident to practitioners who are
not measurement experts. The communication of results should be clear
about the following details:

• How and why base and derived measures were specified
• How data were obtained
• How to interpret results based on the data analysis methods used
• How results address information needs
Examples of actions taken to help others to understand results include:

• Discussing the results with relevant stakeholders
• Providing background and explanation in a document
• Briefing users on results
• Providing training on the appropriate use and understanding of

measurement results

• Defined data management metrics and procedures
• Data management analysis reports
• Defined responsibilities for data management metrics governance
• Base and derived measurement data sets
• Results of data integrity tests
• Measurement objectives
• Specifications of base and derived measures
• Data collection and storage procedures
• Data collection tools
• Analysis specifications and procedures
• Data analysis tools
• Analysis results and draft reports
• Stored data inventory
• Delivered reports and related analysis results
• Contextual information or guidance to help interpret analysis results
Level 3: Defined
3.1 Measurement and analysis standards are established and followed.

Objectives and requirements are evaluated to define the appropriate
measurement standard for the organization. The organization may have
multiple standards for measurements if the projects in the organization are
diverse and require different approaches.
Measurement analysis methods are defined by the organization. These

analysis methods align with the desired use of the measurements as well as

their alignment to the business objectives. Measurement analysts are trained
in analysis methods to ensure consistency in interpretation.
3.2 Measurement and analysis tailoring guidance is established and used.

The organization establishes guidance to tailor both measurements and
analysis methods as appropriate for their individual activity. Guidance
ensures that any alternative practices associated with analysis will still give
the organization results that are consistent with business objectives while
accomodating the unique needs of the activity.
3.3 An organizational measurement repository is established and maintained in

accordance with usage feedback.
The organization establishes a repository for all measurement data across

the individual activities. The organization analyzes this database to define
systemic problems, potential improvements, and data quality risks. The ability
of the repository to meet the needs of the organization is well understood,
and is adjusted as necessary to meet the changing needs of the organization.
3.4 A data quality program for the measurement repository is established, used,
and maintained.
The organization should establish a program to better analyze and improve

data quality by minimizing measurement system error. As necessary,
controls are introduced to ensure that the data inputs are accurate and valid.
Measurements are used to determine the effectiveness of process iprovement
initiatives. The program will enforce that metrics and measurement criteria
are traceable to business objectives, so that the organization understands the
rationale for the measures.

• Data management measurement and metrics standards
• Defined metrics objectives
• Repository(ies) for data management measurements
• Mandate to use standard data management metrics
• Periodic data management metrics analysis reports
• Mapping of metrics to business objectives
• Data management metrics change management process
• Guidance on tailoring measurements and analysis methods
Level 4: Measured
4.1 Process performance is monitored using statistical and other quantitative

techniques.
Statistical and other quantitative techniques are used to analyze variation

in selected processes to determine necessary actions to achieve business
objectives.

4.2 Understand the root causes for selected issues to address deficiencies in
achieving objectives.
Root cause analysis of selected issues is best performed shortly after the
problem is first identified, while the event is still recent enough to be carefully
investigated.
The formality of, and effort required for, a root cause analysis can vary greatly
and can be determined by such factors as the stakeholders who are involved;
the risk or opportunity that is present; the complexity of the situation; the
frequency with which the situation could recur; the availability of data,
baselines, and models that can be used in the analysis; and how much time
has passed since the events triggering the deficiency.
In the case of a selected process exhibiting too much variation, a root cause
analysis is rarely performed as it could take weeks or months to identify root
causes.
Likewise, the actions to take can range significantly in terms of effort and
time needed to determine, plan, and implement them.
It is often difficult to know how much time is needed unless an initial analysis
of the deficiencies and variations is undertaken.
The assessment of impact can include an evaluation of the statistical

significance of the impacts resulting from the actions taken to improve data
management.
4.3 Measures to address measurement objectives are managed.

Measurement objectives are refined into precise, quantifiable measures, with
attention to the following:
• Maintaining traceability of measures to data managment objectives.
Interdependencies among candidate measures are identified to
enable later data validation and candidate analyses in support of data
management objectives.
• Identifying existing measures that already address data management

objectives.
• Recognizing specifications for measures that already exist, perhaps

established for other purposes earlier or elsewhere in the organization.
4.4 The performance of the data management attributes is analyzed and the
data management baseline measures are maintained.
The selected measures should be analyzed to characterize the data

management attributes.
Data management baselines are derived by analyzing collected measures

to establish a distribution or range of results that characterize the expected
performance for selected processes or subprocesses when used in the
organization.

Records of quantitative management data are shared with the organization,
including results from the periodic review of the data management attributes
selected for management against established interim objectives of the
project.

• Approved statistical methods for analysis of data management
• Defined root cause analysis method
• Data management analysis reports evidencing statistical methods
• Dependency diagram showing metrics relationships
• Review evidence for data management measurement and analysis initia-

tives
• Trigger and threshold changes
• Natural bounds for each selected process
• The actions needed to address deficiencies in the data management
Level 5: Optimized
5.1 The organization’s business performance is managed using statistical and

other quantitative techniques to understand data management shortfalls,
and to identify areas for process improvement.
Effective management of the data management program requires the following:

• Maintaining the organization’s business objectives, particularly as they
pertain to data management
• Understanding the organization’s ability to meet the data management

objectives
• Continually improving processes related to achieving the data

management objectives
The organization uses data management baselines to determine if the current

and projected organizational data management objectives are being met.
Shortfalls are identified and analyzed to determine potential areas for process
improvement.
5.2 Root causes of selected outcomes are systematically determined.

A root cause is an initiating element in a causal chain, which leads to an
outcome of interest.
When determining which outcomes to analyze further, consider their source,

impact, frequency of occurrence, similarity, cost of analysis, time and
resources needed, safety considerations, etc.
Examples of methods for selecting outcomes include:

• Pareto analysis
• Histograms

• Box and whisker plots for attributes
• Failure mode and effects analysis (FMEA)
• Process capability analysis
5.3 Selected improvements are validated by stakeholders.

Selected improvements are validated in accordance with their improvement
proposals.
5.4 The effects of deployed improvements on data management are evaluated

using statistical and other quantitative techniques.
Measure the results of each improvement as implemented, using the

measures defined in the deployment plans.
5.5 Measurement and analysis related experiences derived from planning and
performing data management activities are collected and shared, and are
included in the organizational process assets.
The information and artifacts are stored in the organization’s measurement

repository and the organization’s process asset library.
The process and product measures are primarily those that are defined in the
common set of measures for the organization’s set of standard processes.
Lessons learned from measurement and analysis should be documented for

inclusion in the organization’s process asset library.
Examples of measurement and analysis related experiences include the following:

• Captured lessons learned from analysis of process performance data
compared to data management objectives
• Documented measures of the costs and benefits resulting from imple-

menting and deploying improvements
• Report comparing similar data management processes to identify the

potential for improving data management
• Records of quantitative data management
• Suggested improvements to models
• Status of how current the data is
• Results of data integrity tests
• Data analysis reports

• Causal analysis reports with remediation recommendations
• Measurement and analysis reports
• Structured analysis processes
• Analysis of data management measurement changes traced to benefits
• Public presentations, articles, and white papers

Process Management
PURPOSE
Establish and maintain a usable set of organizational process assets and plan,
implement, and deploy organizational process improvements informed by the business
goals and objectives and the current gaps in the organization’s processes.
INTRODUCTORY NOTES
The organization’s process asset library supports organizational learning and process
improvement by allowing the sharing of best practices and lessons learned across
the organization. Defined processes are a tailored subset of the organization’s set of
standard processes. Tailoring consists of choosing among alternative processes and
modifying processes according to guidelines and criteria to most effectively accom-
plish the goals and objectives.
Organizational process assets enable consistent process execution across the organi-
zation and provide a basis for cumulative, long-term benefits to the organization.
The organization’s processes include all processes used by the organization and its
work groups. Candidate improvements to the organization’s processes are obtained
from various sources, including the measurement of processes; lessons learned in
implementing processes; results of process appraisals, product and service evaluation
activities, customer satisfaction evaluations and benchmarking against other organi-
zations’ processes; and recommendations from other improvement initiatives in the
organization.
Process improvement occurs in the context of the organization’s needs and is used to
address the organization’s objectives. The organization encourages participation in
process improvement activities by those who perform the process. The responsibility
for facilitating and managing the organization’s process improvement activities,
including coordinating the participation of others, is typically assigned to a process
group. The organization provides the long-term commitment and resources required
to sponsor this group and to ensure the effective and timely deployment of improve-
ments.
Ensuring that process improvement efforts across the organization are adequately
managed and implemented requires careful planning. Results of the organization’s
process improvement planning are documented in a process improvement plan.
GOALS
1. The organization operates according to its set of standard processes.
2. The organization follows defined methods for maintaining their processes to

accommodate changes in business requirements, standards, and technology.
3. Process measures, process assets, and examples are maintained in a

repository.
168 Process Management

CORE QUESTIONS
1. How are processes, methods, procedures, policies, and standards maintained?
2. How is process performance measured?
3. How does the organization measure process compliance?
4. How does the organization ensure that improvements are identified, pursued,
and implemented?
5. How does the organization validate that proposed improvements enhance

performance before they are deployed?

This process area pertains to all data management process areas.
Level 1: Performed
1.1 A group is established to coordinate improvement of processes, standards,

and procedures.
Data governance typically leads the data management process improvement

program.
1.2 Process needs are identified through appraisals or submitted change

proposals.
1.3 Process problems or improvement opportunities are addressed.

1.4 Data, process, and work products are stored, maintained, and accessible.
• List of process problems or improvement opportunities
• Self-assessment results
• Process asset library
• Documentation establishing process improvement focused group
Level 2: Managed
2.1 Establish and maintain the description of process needs and objectives for
the organization.
Understand the business context in which the organization’s processes

operate. The organization’s business objectives, needs, and constraints
determine the needs and objectives for the organization’s processes.
The following steps are typically taken to identify process improvement

needs and objectives:
1. Identify policies, standards, and business objectives that are applicable
to the organization’s processes.

2. Examine relevant process standards and models for best practices.
3. Determine the organization’s process performance objectives.
4. Process performance objectives can be expressed in quantitative or

qualitative terms.
5. Define essential characteristics of the organization’s processes.
6. Document the organization’s process needs and objectives.
7. Revise the organization’s process needs and objectives as needed.
2.2 Appraise processes as needed to maintain an understanding of their

strengths and weaknesses.
The typical steps for an appraisal include:

1. Obtain sponsorship of the process appraisal from senior management.
Senior management sponsorship includes the commitment to have the

organization’s managers and staff participate in the process appraisal
and to provide resources and funding to analyze and communicate
findings of the appraisal.
2. Define the scope of the process appraisal.
Process appraisals can be performed on the entire organization or can be

performed on a smaller part of an organization such as a business unit.
The scope of the process appraisal addresses the following:
• Definition of the organization (e.g., sites, business units, projects) to

be covered by the appraisal
• Processes to be appraised
3. Determine the method and criteria to be used for the process appraisal.
4. Plan, schedule, and prepare for the process appraisal.
5. Conduct the process appraisal.
6. Document and deliver the appraisal’s findings.
2.3 Perform impact assessment on suggested improvements.

Analyzing improvement may include the following:
1. Analyze the costs and benefits of suggested improvements.
Criteria for evaluating costs and benefits include the following:
• Contribution toward meeting the organization’s quality and process

performance objectives
• Effect on mitigating identified risks
• Ability to respond quickly to changes in requirements, market situa-

tions, and the business environment
• Effect on related processes and associated assets

• Cost of defining and collecting data that support the measurement
and analysis of the process and technology improvement
Identify potential barriers and risks to deploying each suggested

improvement. Examples of barriers to deploying improvements are listed:
• Lack of strong business justification
• Lack of short-term benefits and visible successes
• Too many changes at the same time
• Lack of involvement and support from relevant stakeholders
Examples of risk factors that affect the deployment of improvements

include:
• Compatibility of the improvement with existing processes, values,
and skills of potential end users
• Complexity of the improvement
• Difficulty of implementing the improvement
2. Estimate the cost, effort, and schedule required for implementing,

verifying, and deploying each suggested improvement.
3. Select suggested improvements for validation and possible implemen-

tation and deployment based on the evaluations.
4. Document the evaluation results of each selected improvement

suggestion in an improvement proposal.
The proposal should include a problem statement, a plan (including cost

and schedule, risk handling, and method for evaluating effectiveness in
the target environment) for implementing the improvement, and quanti-
tative success criteria for evaluating actual results of the deployment.
5. Determine the detailed changes needed to implement the improvement

and document them in the improvement proposal.
6. Determine the validation method that will be used before broad-scale

deployment of the change and document it in the improvement proposal
Determining the validation method includes defining the quantitative

success criteria that will be used to evaluate results of the validation.
7. Determine whether or not to pilot the change based upon the costs,
benefits, and risks. Other validation methods, including modeling and
simulation, can be used as appropriate.
8. Document results, including the rationale of the selection process.
2.4 Select and implement improvements for deployment based on an evaluation

of costs, benefits, and other factors.
Practices for selecting and implementing improvements follow:

1. Prioritize improvements for deployment.
The priority of an improvement is based on an evaluation of its estimated

cost-to-benefit ratio with regard to the quality and process performance
objectives as compared to the performance baselines. Return on
investment can be used as a basis of comparison.
2. Select improvements to be deployed.
Selection of improvements to be deployed is based on their priorities,

available resources, and results of improvement proposal evaluation and
validation activities.
3. Determine how to deploy each improvement.
The following examples show where the improvements may be deployed:
• Project specific or common work environments
• Product families
• Organization’s projects
• Organizational groups
4. Document results of the selection process.
Results of the selection process usually include these items:
• The selection criteria for suggested improvements
• The characteristics of the target projects
• The disposition of each improvement proposal
• The rationale for the disposition of each improvement proposal
5. Review any changes needed to implement the improvements.
Listed are examples of changes needed to deploy an improvement:
• Process descriptions, standards, and procedures
• Work environments
• Education and training
• Skills
• Existing commitments
• Existing activities
• Continuing support to end users
• Organizational culture and characteristics
6. Update the organizational process assets.
Updating the organizational process assets typically includes reviewing,

gaining approval, and communicating them.
2.5 Establish, maintain, and follow process action plans to address improve-
ments to the processes.

Establishing and maintaining process action plans typically involves the
following roles:
• Management steering committees that set strategies and oversee
process improvement activities
• Process groups that facilitate and manage process improvement activ-

ities
• Process action teams that define and implement process actions
• Process owners that manage deployment
• Practitioners that perform the process
Stakeholder involvement helps obtain buy-in on process improvements and

increases the likelihood of effective deployment.
Process action plans are detailed implementation plans. These plans differ
from the organization’s process improvement plan by targeting defined
improvements to address weaknesses usually uncovered by appraisals.
Steps involved in establishing and maintaining action plans include the

following:
1. Identify strategies, approaches, and actions to address identified process
improvements.
New, unproven, and major changes are piloted before they are incorpo-
rated into the organization’s set of standard processes.
2. Establish process action teams to implement actions.
The teams and people performing the process improvement actions are
called “process action teams.” Process action teams typically include
process owners and those who perform the process.
3. Document process action plans.
Process action plans typically cover the following:
• Process improvement objectives
• Process improvement infrastructure
• Process improvements to be addressed
• Procedures for planning and tracking process actions
• Strategies for piloting and implementing process actions
• Responsibility and authority for implementing process actions
• Resources, schedules, and assignments for implementing process

actions
• Methods for determining the effectiveness of process actions
• Risks associated with process action plans
4. Review and negotiate process action plans with relevant stakeholders.

5. Revise process action plans as necessary.

• Documented process needs and objectives
• Process appraisal plan
• Appraisal findings
• Process improvement recommendations
• Improvements selected for deployment
• Updated process documentation and training
Level 3: Defined
3.1 Establish and maintain the organization’s set of standard processes (OSSP).
Standard processes can be defined at multiple levels in an organization
and can be related hierarchically. For example, an enterprise can have a set
of standard processes that is tailored by individual organizations (e.g., a
division, a site) in the enterprise to establish their set of standard processes.
The set of standard processes can also be tailored for each of the organiza-
tion’s business areas, product lines, or standard services. Thus the organiza-
tion’s set of standard processes (OSSP) can refer to the standard processes
established at the organization level and standard processes that may be
established at lower levels, although some organizations may have only one
level of standard processes. (See the definitions of “standard process” and
“organization’s set of standard processes” in the glossary.)
Multiple standard processes may be needed to address the needs of different

business areas. The organization’s set of standard processes contains process
elements that may be interconnected according to one or more process
architectures that describe relationships among process elements.
The organization’s set of standard processes typically includes technical,

management, administrative, support, and organizational processes.
The organization’s set of standard processes should collectively cover all

processes needed by the organization and business areas.
Below are the typical steps when establishing and maintaining an OSSP:
1. Decompose each standard process into constituent process elements to
the detail needed to understand and describe the process.
Each process element covers a closely related set of activities. The
descriptions of process elements may be templates to be filled in,
fragments to be completed, or abstractions to be refined; or complete
descriptions to be tailored or used unmodified. These elements are
described in such detail that the process, when fully defined, can be
consistently performed by appropriately trained and skilled people
Examples of process elements are listed:

• Template for creating service agreements
• Template for conducting management reviews
• Templates or task flows embedded in workflow tools
• Description of work product design methodology
2. Specify the critical attributes of each process element.
Examples of critical attributes include the following:

• Process roles
• Applicable standards
• Applicable procedures, methods, tools, and resources
• Process performance objectives
• Entry criteria
• Inputs
• Verification points (e.g., peer reviews)
• Outputs
• Interfaces
• Exit criteria
• Product and process measures
3. Specify relationships among process elements.
Examples of relationships include the following:
• Order of the process elements
• Interfaces among process elements
• Interfaces with external processes
• Interdependencies among process elements
The rules for describing relationships among process elements are

referred to as the “process architecture.” The process architecture covers
essential requirements and guidelines. Detailed specifications of these
relationships are covered in descriptions of defined processes that are
tailored from the organization’s set of standard processes.
4. Ensure that the organization’s set of standard processes adheres to
applicable policies, standards, and models.
Adherence to applicable process standards and models is typically

demonstrated by developing a mapping from the organization’s set
of standard processes to relevant process standards and models. This
mapping is a useful input to future appraisals.
5. Ensure that the organization’s set of standard processes satisfies process

needs and objectives of the organization.

6. Ensure appropriate integration among processes that are included in the
organization’s set of standard processes.
7. Document the organization’s set of standard processes.
8. Conduct peer reviews on the organization’s set of standard processes.
9. Revise the organization’s set of standard processes as necessary.
Examples of when the organization’s set of standard processes may need

to be revised include:
• When improvements to the process are identified
• When causal analysis and resolution data indicate a need for a

process change
• When process improvement proposals are selected for deployment

across the organization
• When the organization’s process needs and objectives are updated
3.2 Establish and maintain tailoring criteria and guidelines for the set of
standard processes.
Tailoring criteria and guidelines describe these items:

• H
ow the organization’s set of standard processes and organizational
process assets are used to create defined processes
• R
equirements that must be satisfied by defined processes (e.g., the
subset of organizational process assets that are essential for any defined
process)
• O
ptions that can be exercised and criteria for selecting among options
• P
rocedures that must be followed in performing and documenting
process tailoring
• Examples of reasons for tailoring include the following:
• A
dapting the process to a new service or type of customer
• E
laborating the process description so that the resulting defined
process can be performed
Flexibility in tailoring and defining processes is balanced with ensuring

appropriate consistency of processes across the organization.
Flexibility is needed to address contextual variables suchas the domain; the

selected tool; cost, schedule, and quality tradeoffs; the technical difficulty
of the work; and the experience of the people implementing the process.
Consistency across the organization is needed so that organizational
standards, objectives, and strategies are appropriately addressed, and
process data and lessons learned can be shared.
Tailoring is a critical activity that allows controlled changes to processes due

to the specific needs of a work group or a part of the organization. Processes
and process elements directly related to critical business objectives should
usually be defined as mandatory, but less critical processes and process

elements or those indirectly affecting business objectives may allow for more
tailoring.
Tailoring criteria and guidelines can allow for using a standard process “as is,”
with no tailoring.
Listed here are the typical steps to establishing tailoring criteria and guide-
lines:
1. Specify selection criteria and procedures for tailoring the organization’s
set of standard processes.
Below are examples of criteria and procedures:
• Criteria for selecting process elements from the organization’s set of

standard processes
• Procedures for tailoring selected lifecycle models and process

elements to accommodate process characteristics and needs
• Procedures for adapting the organization’s common measures to

address information needs
Examples of reasons for tailoring include the following:

• Modifying process elements
• Replacing process elements
• Reordering process elements
2. Specify the standards used for documenting defined processes.
3. Specify the procedures used for submitting and obtaining approval of

waivers from the organization’s set of standard processes.
4. Document tailoring guidelines for the organization’s set of standard

processes.
5. Conduct peer reviews on the tailoring guidelines.
6. Revise tailoring guidelines as necessary.
3.3 Establish and maintain the organization’s process asset library.

Examples of items to be stored in the organization’s process asset library are
listed:
• Organizational policies
• Process descriptions
• Procedures (e.g., estimating procedure)
• Quality assurance plans
• Training materials
• Process aids (e.g., checklists)
• Lessons learned reports

These steps typically are followed to establish and maintain an organization’s
process asset library:
1. Design and implement the organization’s process asset library, including
the library structure and support environment.
2. Specify criteria for including items in the library.
Items are selected based primarily on their relationship to the organiza-

tion’s set of standard processes.
3. Specify procedures for storing, updating, and retrieving items.
4. Enter selected items into the library and catalog them for easy reference
and retrieval.
5. Make items available for use by work groups.
6. Periodically review the use of each item.
7. Revise the organization’s process asset library as necessary.
The library may need to be revised when:

• New items are added
• Items are retired
• Current versions of items are changed
3.4 Establish and maintain the organization’s measurement repository.

The repository contains both product and process measures that are related
to the organization’s set of standard processes. It also contains or refers to
information needed to understand and interpret measures and to assess them
for reasonableness and applicability. For example, the definitions of measures
are used to compare similar measures from different processes.
The following are typical steps for establishing and maintaining the organiza-
tion’s measurement repository:
1. Determine the organization’s needs for storing, retrieving, and analyzing
measurements.
2. Define a common set of process and product measures for the organiza-
tion’s set of standard processes.
Measures in the common set are selected for their ability to provide
visibility into processes critical to achieving business objectives across
the organization. The common set of measures can vary for different
standard processes.
Defined measures include those related to agreement management,

some of which may need to be collected from suppliers.
Operational definitions for measures specify procedures for collecting

valid data and the point in the process where data will be collected.
Examples of classes of commonly used measures include the following:

• Estimates of work product size (e.g., pages)
• Estimates of effort and cost (e.g., person hours)
• Actual measures of size, effort, and cost
3. Design and implement the measurement repository.
Functions of the measurement repository are listed here:

• Supporting effective comparison and interpretation of measurement
data
• Providing sufficient context to allow quick identification of and

access to data in the repository for similar projects
• Aiding in the understanding of process performance
• Supporting potential statistical management of processes or subpro-

cesses, as needed
4. Specify procedures for storing, updating, and retrieving measures.
Refer to Measurement and Analysis for more information about speci-

fying data collection and storage procedures.
5. Enter specified measures into the repository.
Refer to Measurement and Analysis for more information about speci-

fying measures.
6. Make the contents of the measurement repository available for use by
the organization and projects as appropriate.
7. Revise the measurement repository, the common set of measures and

procedures as the organization’s needs change.
The common set of measures may need to be revised in the following

situations:
• New processes are added
• Processes are revised and new measures are needed
• Finer granularity of data is required
• Greater visibility into the process is required
• Measures are retired

• Results of analysis of candidate process improvements
• Approved process action plan
• Status and results of implementing process action plans
• Set of standard processes
• Tailoring guidelines for the organization’s set of standard processes

• The organization’s process asset library
• The catalog of items in the organization’s process asset library
Level 4: Measured
4.1 Establish and maintain the organization’s quantitative objectives for quality
and process performance, which are traceable to business objectives.
The organization’s quality and process performance objectives can be estab-

lished for different levels in the organizational structure (e.g., business area,
product line, function, project) as well as at different levels in the process
hierarchy. When establishing quality and process performance objectives,
consider the following:
• Traceability to the organization’s business objectives
• Past performance of the selected processes or subprocesses in context

(e.g., on projects)
• Multiple attributes of process performance (e.g., quality, productivity)
• Inherent variability or natural bounds of the selected processes or

subprocesses
The organization’s quality and process performance objectives provide focus

and direction to the process performance analysis and quantitative project
management activities. Typical tasks for accomplishing this include:
1. Review the organization’s business objectives related to quality and
process performance.
2. Define the organization’s quantitative objectives for quality and process

performance.
Quality and process performance objectives can be established for

process or subprocess measurements (e.g., effort, cycle time, defect
removal effectiveness) as well as for product measurements (e.g.,
reliability, defect density) and service measurements (e.g., capacity,
response times) as appropriate.
3. Define the priorities of the organization’s objectives for quality and

process performance.
4. Review, negotiate, and obtain commitment to the organization’s quality

and process performance objectives and their priorities from relevant
stakeholders.
5. Revise the organization’s quantitative objectives for quality and process

performance as necessary.
Examples of when the organization’s quantitative objectives for quality

and process performance may need to be revised include the following:
• When the organization’s business objectives change
• When the organization’s set of standard processes change

• When actual quality and process performance differ significantly
from objectives
4.2 Analyze the performance of the selected processes, and establish and
maintain the process performance baselines.
The selected measures are analyzed to characterize the performance of

the selected processes or subprocesses achieved on projects. This charac-
terization is used to establish and maintain process performance baselines
(see the definition of “process performance baseline” in the glossary). These
baselines are used to determine the expected results of the process or
subprocess when used on a project under a given set of circumstances.
Process performance baselines are compared to the organization’s quality

and process performance objectives to determine if the objectives are being
achieved.
The process performance baselines are a measurement of performance for

the organization’s set of standard processes at various levels of detail. The
processes that the process performance baselines can address include the
following:
• S
equence of connected processes
• P
rocesses that cover the entire life of the project
• P
rocesses for performing individual activities or developing individual
work products
Several process performance baselines can be used to characterize perfor-

mance for subgroups of the organization.
Tailoring the organization’s set of standard processes can significantly affect

the comparability of data for inclusion in process performance baselines.
Effects of tailoring should be considered in establishing baselines. Depending
on the tailoring allowed, separate performance baselines may exist for each
type of tailoring.
The following steps may be involved in creating and maintaining process

performance baselines:
1. Collect the selected measurements for the selected processes and
subprocesses.
The process or subprocess in use when the measurement was taken is

recorded to enable its use later.
2. Analyze the collected measures to establish a distribution or range

of results that characterizes the expected performance of selected
processes or subprocesses when used on a project.
This analysis should include the stability of the related process or

subprocess, and the impacts of associated factors and context.
Analyze the presence of segmentation or stratification of the candidate

baseline (or addition to the baseline) to determine its disposition.

Related factors include inputs to the process and other attributes that
can affect the results obtained. The context includes the business context
(e.g., domain) and significant tailoring of the organization’s set of
standard processes.
The measurements from stable subprocesses in projects should be used

when possible; other data may be unreliable.
3. Establish and maintain the process performance baselines from collected

measurements and analyses.
Process performance baselines are derived by analyzing collected

measures to establish a distribution or range of results that characterize
the expected performance for selected processes or subprocesses when
used on a project in the organization.
4. Review and reach agreement with relevant stakeholders about the

process performance baselines.
5. Make the process performance information available across the organi-

zation in the measurement repository.
6. The process performance baselines are used by projects to estimate the

natural bounds for process performance.
7. Compare the process performance baselines to associated quality and

process performance objectives to determine if those objectives are
being achieved.
These comparisons should use statistical techniques beyond a simple

comparison of the mean to gauge the extent of quality and process
performance objective achievement. If the objectives are not being
achieved, corrective actions should be considered.
8. Revise the process performance baselines as necessary.
The following examples indicate when the organization’s process perfor-

mance baselines may need to be revised:
• When processes change
• When the organization’s results change
• When the organization’s needs change
• When suppliers’ processes change
• When suppliers change
4.3 Establish and maintain process performance models for selected processes
in the organization’s set of standard processes.
High-maturity organizations generally establish and maintain a set of process

performance models at various levels of detail that cover a range of common
activities across the organization and address the quality and process
performance objectives. (See the definition of “process performance model”
in Appendix A.)

Process performance models are used to estimate or predict the value of
a process performance measure from the values of other process, product,
and service measurements. These process performance models typically
use process and product measurements collected during the work effort to
estimate progress toward achieving quality and process performance objec-
tives that cannot be measured until later in the work effort’s life.
Process performance models are used as follows:

• In organizations:
• Estimating, analyzing, and predicting the process performance

associated with processes in and changes to the organization’s set of
standard processes
• Assessing the (potential) return on investment for process

improvement activities
• For work efforts:
• Estimating, analyzing, and predicting the process performance of

their defined processes
• Selecting processes or subprocesses for use
• Estimating progress toward achieving the project’s quality and

process performance objectives
These measures and models are defined to provide insight into, and the
ability to predict, critical process and product characteristics that are relevant
to the organization’s quality and process performance objectives.
Examples of process performance models include the following:

• Regression models
• Complexity models
• Discrete event simulation models
• Monte Carlo simulation models
Steps that may be involved in establishing and maintaining process perfor-

mance baselines include:
1. Establish process performance models based on the organization’s set of
standard processes and process performance baselines.
2. Calibrate process performance models based on past results and current

needs.
3. Review process performance models and reach agreement with relevant

stakeholders.
4. Support the use of process performance models.
5. Revise process performance models as necessary.
Examples of when process performance models may need to be revised

include:

• When processes change
• When the organization’s results change
• When the organization’s quality and process performance objectives

change

• Definition of the common set of product and process measures for
the organization’s set of standard processes
• Design of the organization’s measurement repository
• Organization’s measurement repository (i.e., the repository structure,

support environment)
• Organization’s measurement data
• Analysis of process performance data
• Baseline data on the organization’s process performance
• Process performance models
Level 5: Optimized
5.1 Maintain business objectives based on an understanding of business strat-

egies and actual performance results.
Organizational performance data, characterized by process performance

baselines, evaluate whether business objectives are realistic and aligned with
business strategies. After business objectives have been revised and prior-
itized by senior management, quality and process performance objectives
may need to be created or maintained and recommunicated.
The following steps can be used to maintain business objectives:

1. Evaluate business objectives periodically to ensure they are aligned with
business strategies.
Senior management is responsible for understanding the marketplace,

establishing business strategies, and establishing business objectives.
Because business strategies and organizational performance evolve,

business objectives should be reviewed periodically to determine
whether they should be updated. For example, a business objective
might be retired when process performance data show that the business
objective is being met consistently over time or when the associated
business strategy has changed.
2. Compare business objectives with actual process performance results to
ensure they are realistic.
Business objectives can set the bar too high to motivate real
improvement. Using process performance baselines helps balance desires
and reality.

If process performance baselines are unavailable, sampling techniques
can be used to develop a quantitative basis for comparison in a short
period of time.
3. Prioritize business objectives based on documented criteria, such as key
business strategies.
4. Maintain quality and process performance objectives to address changes

in business objectives.
Business objectives and quality and process performance objectives

typically evolve over time. As existing objectives are achieved, they will
be monitored to ensure they continue to be met, while new business
objectives and associated quality and process performance objectives
are identified and managed.
5. Revise process performance measures to align with quality and process
performance objectives.
5.2 Analyze process performance data to determine the organization’s ability to

meet identified business objectives.
The data that result from applying the process performance measures are
analyzed to create process performance baselines that help in understanding
the current capability of the organization. Comparing process performance
baselines to quality and process performance objectives helps the organi-
zation to determine its ability to meet business objectives. These data
typically are collected from project level process performance data to enable
organizational analysis.
The following steps can be used to analyze process performance data:

1. Periodically compare quality and process performance objectives to
current process performance baselines to evaluate the ability of the
organization to meet its business objectives.
2. Identify shortfalls where the actual process performance is not satisfying

the business objectives.
3. Identify and analyze risks associated with not meeting business objec-
tives.
4. Report results of the process performance and risk analyses to organiza-

tional leadership.
5.3 Identify potential areas for improvement that could contribute to meeting
business objectives.
Potential areas for improvement are identified through analysis to determine

areas that could address process performance shortfalls. Causal analysis
processes can be used to diagnose and resolve root causes.
The output from this activity is used to evaluate and prioritize potential
improvements.
Steps to identifying potential areas for improvement include the following:

1. Identify potential improvement areas based on the analysis of process
performance shortfalls.
Examples of areas to consider for improvement include product

technology, process technology, staffing and staff development, team
structures, supplier selection and management, and other organizational
infrastructures.
2. Document the rationale for the potential improvement areas, including
references to applicable business objectives and process performance
data.
3. Document anticipated costs and benefits associated with addressing

potential improvement areas.
4. Communicate the set of potential improvement areas for further evalu-

ation, prioritization, and use.

• Revised business objectives
• Revised quality and process performance objectives
• Senior management approval of revised business objectives and quality

and process performance objectives
• Communication of all revised objectives
• Updated process performance measures
• Analysis of current capability vs. business objectives
• Process performance shortfalls
• Risks associated with meeting business objectives
• Potential areas for improvement

Process Quality Assurance
PURPOSE
Provide staff and management with objective insight into process execution and the
associated work products.
INTRODUCTORY NOTES
The Process Quality Assurance process area involves the following activities:
• Objectively evaluating performed processes and work products against appli-

cable process descriptions, standards, and procedures
• Identifying and documenting noncompliance issues
• Providing feedback to staff and managers on the results of quality assurance

activities
• Ensuring that noncompliance issues are addressed
The Process Quality Assurance process area supports high-quality delivery by staff
and managers at all levels through providing appropriate visibility into and feedback
on processes and associated work products.
Objectivity in process quality assurance evaluations is critical to the success of the

effort. Objectivity is achieved both by the use of established criteria and independent
evaluators. A combination of methods is often used. Less formal methods can be used
to provide broad day-to-day coverage. More formal methods can be used periodically
to assure objectivity.
The following methods can be used to perform objective evaluations:
• Formal audits by organizationally separate quality assurance organizations
• Peer reviews, which can be performed at various levels of formality
• In-depth review of work at the place it is performed (i.e., desk audits)
• Distributed review and comment of work products
• Process checks built into the processes such as a fail-safe for processes when
they are done incorrectly
Traditionally, a quality assurance group that is independent of the work team provides
objectivity. However, another approach may be appropriate in some organizations to
implement the process quality assurance role without that kind of independence.
For example, in an organization with an open, quality-oriented culture, the process

quality assurance role can be performed, partially or completely, by peers, and the
quality assurance function can be embedded in the process. For small organizations,
this embedded approach might be the most feasible approach.
If quality assurance is embedded in the process, several issues should be addressed

to ensure objectivity. Everyone performing quality assurance activities should be

trained in quality assurance. Those who perform quality assurance activities for a work
product should be separate from those who are directly involved in developing or
maintaining the work product. An independent reporting channel to the appropriate
level of organizational management should be available so that noncompliance issues
can be escalated as necessary.
For example, when implementing peer reviews as an objective evaluation method, the
following issues should be addressed:
• Members are trained and roles are assigned for people attending the peer
reviews
• A member of the peer review who did not produce this work product is
assigned to perform the quality assurance role
• Checklists based on process descriptions, standards, and procedures are

available to support the quality assurance activity
• Noncompliance issues are recorded as part of the peer review report and are
tracked and escalated when necessary
Quality assurance should begin in the early phases of an effort to establish plans,
processes, standards, and procedures that will add value and satisfy the requirements
and organizational policies. Those who perform quality assurance activities participate
in establishing plans, processes, standards, and procedures to ensure that they fit
needs and that they will be usable for performing quality assurance evaluations. In
addition, processes and associated work products to be evaluated are designated; this
can be based on sampling or on objective criteria that are consistent with organiza-
tional policies, requirements, and needs.
When noncompliance issues are identified, they are first addressed and resolved, if
possible, in the work team. If they cannot be resolved in the work team, issues are
escalated to an appropriate level of management for resolution.
This process area applies to evaluations of activities and work products at all levels
within the data management organization.
GOALS
1. Management has visibility into the quality of the process and products.
2. Noncompliance issues are addressed at the appropriate level.
3. Process and product quality have become an embedded discipline at all levels
in the organization.
CORE QUESTIONS
1. Are process noncompliance issues raised to an appropriate level?
2. Are quality issues analyzed for positive trending?
3. Do all relevant stakeholders have visibility into the quality of the process and
products?
188 Process Quality Assurance

This process area is applicable to all process areas.
Level 1: Performed
1.1 Process and product issues are identified and addressed.
• List of quality issues
Level 2: Managed
2.1 Objectively evaluate selected performed processes against applicable

process descriptions, standards, and procedures.
Objectivity in quality assurance evaluations is critical to the success of quality

assurance. A description of the quality assurance reporting chain and how it
ensures objectivity should be defined.
The following activities typically are involved in process evaluations:

1. Promote an environment (created as part of management) that
encourages staff participation in identifying and reporting quality issues.
2. Establish and maintain clearly stated criteria based on business needs for
evaluations.
Business needs may include these issues:

• What will be evaluated
• When or how often a process will be evaluated
• How the evaluation will be conducted
• Who must be involved in the evaluation
3. Use the stated criteria to evaluate selected performed processes for

adherence to process descriptions, standards, and procedures.
4. Identify each noncompliance found during the evaluation.
5. Identify lessons learned that could improve processes.
2.2 Objectively evaluate selected work products against applicable process

descriptions, standards, and procedures.
The listed activities typically are involved in product evaluations:

1. Select work products to be evaluated based on documented sampling
criteria if sampling is used.
Work products can include services produced by a process whether the

recipient of the service is internal or external to the effort or organi-
zation.

2. Establish and maintain clearly stated criteria based on business needs for
evaluating selected work products.
Business needs may include the following:

• What will be evaluated for a work product
• When or how often a work product will be evaluated
• How the evaluation will be conducted
• Who must be involved in the evaluation
3. Use the stated criteria during evaluations of selected work products.
4. Evaluate selected work products at selected times.
Examples of when work products can be evaluated against process

descriptions, standards, or procedures include the following:
• Before delivery
• During delivery
• Incrementally, as appropriate
5. Identify each case of noncompliance found during evaluations.
6. Identify lessons learned that could improve processes.
2.3 Communicate quality issues and ensure the resolution of noncompliance

issues with the staff and managers.
Noncompliance issues are problems identified in evaluations that reflect a

lack of adherence to applicable standards, process descriptions, or proce-
dures. The status of noncompliance issues provides an indication of quality
trends. Quality issues include noncompliance issues and trend analysis results.
When noncompliance issues cannot be resolved, use established escalation

mechanisms to ensure that the appropriate level of management can resolve
the issue. Track noncompliance issues to resolution.
The activities involved in resolving noncompliance items typically include

these tasks:
1. Resolve each noncompliance with the appropriate members of the staff if
possible.
2. Document noncompliance issues when they cannot be resolved in the

project.
The following ways may be used to resolve noncompliance in the effort:
• F
ixing the noncompliance
• C
hanging the process descriptions, standards, or procedures that
were violated
• O
btaining a waiver to cover the noncompliance

3. Escalate noncompliance issues that cannot be resolved to the appro-
priate level of management designated to receive and act on noncom-
pliance issues.
4. Analyze noncompliance issues to see if quality trends can be identified

and addressed.
5. Ensure that relevant stakeholders are aware of evaluation results and

quality trends in a timely manner.
6. Periodically review open noncompliance issues and trends with the

manager designated to receive and act on noncompliance issues.
7. Track noncompliance issues to resolution.
2.4 Establish and maintain records of quality assurance activities.

The following activities typically are involved in maintaining quality records:
1. Record process and product quality assurance activities in sufficient
detail so that status and results are known.
2. Revise the status and history of quality assurance activities as necessary.

• Evaluation reports
• Noncompliance reports
• Quality trends
• S
tatus reports of corrective actions
• R
eports of quality trends
Level 3: Defined
3.1 Establish, maintain, and follow organizational standard policies, processes,

and procedures for process and product quality assurance.
3.2 Establish, maintain, and follow organizational standard policies, processes,

and procedures for reporting quality results and escalating noncompliance
issues when they cannot be resolved at lower levels.
3.3 Establish, maintain, and apply a measurement system to quality issues.

• Policies, processes, and procedures for quality evaluations and noncom-
pliance escalation
• Quality reports
Level 4: Measured
4.1 The organization uses statistical and other quantitative techniques to

predict where quality issues will arise.

• Results of predictive analyses
Level 5: Optimized
5.1 The organization uses statistical and other quantitative techniques to

manage tradeoffs between cost and quality to meet business objectives.

• Results of actual quality versus quantitative business objectives for
quality

Risk Management
PURPOSE
Identify and analyze potential problems in order to take appropriate action to ensure
objectives can be achieved.
INTRODUCTORY NOTES
Risk management is a continuous, forward-looking process that is an important part
of management. Risk management addresses issues that could endanger achievement
of critical objectives. A continuous risk management approach effectively anticipates
and mitigates risks that can have a critical impact.
Effective risk management includes early and aggressive risk identification through
collaboration and the involvement of relevant stakeholders. Strong leadership among
relevant stakeholders is needed to establish an environment for open disclosure and
discussion of risk.
Risk management should consider internal and external, and technical and nontech-
nical sources of risks. Early detection of risk is important because it is typically easier,
less costly, and less disruptive to make changes and correct work efforts the earlier
they are identified.
Industry standards can help when determining how to prevent or mitigate specific
risks commonly found in a particular industry. Certain risks can be proactively
managed or mitigated by applying appropriate industry best practices and lessons
learned.
Risk management can be divided into the following parts:
• Defining a risk management strategy
• Identifying and analyzing risks
• Handling identified risks, including the implementation of risk mitigation plans

as needed
Organizations may initially focus on risk identification for awareness and react to risks
as they occur. The Risk Management process area describes an evolution of these
practices to systematically plan, anticipate, and mitigate risks to proactively minimize
their impact.
GOALS
1. The organization is operating with an understanding of its current level of risk.
2. The organization is pursuing risk mitigation plans to limit the potential

damage from identified risks.
3. Risks are continually identified, analyzed, and monitored.
Risk Management 193

CORE QUESTIONS
1. Does the organization know the amount of risk it is operating under?
2. Has the organization identified and implemented risk mitigation and

contingency plans?
3. Does the organization periodically monitor risks and take appropriate update
actions?

Level 1: Performed
1.1 Risks are identified, documented, and monitored.
• Risk list
Level 2: Managed
2.1 Analyze identified risks.

Risks are identified or discovered and analyzed to support planning and
management. This practice should be extended to all plans to ensure that
stakeholders are aware of identified risks.
Risk identification and analysis typically includes the following:

• Identifying risks
• Analyzing risks to determine the impact, probability of occurrence, and

time frame in which problems are likely to occur
• Prioritizing risks
The following tasks typically are involved in risk identification and analysis:
1. Identify risks.
The identification of risks involves the identification of potential issues,

hazards, threats, vulnerabilities, and so on that could negatively affect
work efforts and plans. Risks should be identified and described under-
standably before they can be analyzed and managed properly. When
identifying risks, it is a good idea to use a standard method for defining
risks. Risk identification and analysis tools can be used to help identify
possible problems.
Examples of risk identification and analysis tools are listed below:

• Risk taxonomies
• Risk assessments
194 Risk Management

• Checklists
• Structured interviews
• Brainstorming
• Process performance models
• Cost models
• Network analysis
• Quality factor analysis
2. Document risks.
3. Review and obtain agreement with relevant stakeholders on the

completeness and correctness of documented risks.
4. Revise risks as appropriate.
Examples of when identified risks may need to be revised include the

following:
• New risks are identified
• Risks become problems
• Risks are retired
• Circumstances change significantly
2.2 Monitor identified risks.

The activities listed below typically are involved in risk monitoring:
1. Periodically review the documentation of risks in the context of the
project’s current status and circumstances.
2. Revise the documentation of risks as additional information becomes

available.
As time progresses, new risks may arise. It is important to identify and

analyze these new risks. In addition, risks may become obsolete and thus
should be retired so no more effort is spent monitoring them.
3. Communicate the risk status to relevant stakeholders.
Examples of risk status include:

• A change in the probability that the risk occurs
• A change in risk priority

• Identified risks
• Risk impacts and probability of occurrence
• Risk priorities
• Current status of risks
Risk Management 195

Level 3: Defined
3.1 Determine risk sources and categories.

Identifying risk sources provides a basis for systematically examining
changing situations over time to uncover circumstances that affect the ability
to meet objectives. Risk sources are both internal and external, technical
and nontechnical. As the work progresses, additional sources of risk can
be identified. Establishing categories for risks provides a mechanism for
collecting and organizing risks, as well as ensuring appropriate scrutiny
and management attention to risks that can have serious consequences on
meeting objectives.
Typical activities involved in determining risk sources and categories are

addressed below:
1. Determine risk sources.
Risk sources are fundamental drivers that cause risks. Risks have many
sources, both internal and external. Risk sources identify where risks can
originate.
Typical internal and external risk sources include the following:

• Uncertain requirements
• Unprecedented efforts (i.e., estimates unavailable)
• Competing quality attribute requirements
• Unavailable technology
• Unrealistic schedule estimates or allocation
• Inadequate staffing and skills
• Cost or funding issues
• Uncertain or inadequate supplier capability
• Disruptions to the continuity of operations
• Regulatory constraints (e.g., security, safety, environment)
2. Many of these sources of risk are accepted without adequately planning

for them. Early identification of both external and internal sources of
risk can lead to early identification of risks. Risk mitigation plans can
then be implemented to preclude occurrence of risks or reduce conse-
quences of their occurrence. Determine risk categories.
Risk categories are useful for collecting, organizing, and communicating

risks. Identifying risk categories aids the future consolidation of activities
in risk mitigation plans.
Consider the following factors when determining risk categories:

• Types of processes used
• Types of products used
196 Risk Management

• Management risks (e.g., contract risks, budget risks, schedule risks,
resource risks)
• Technical performance risks (e.g., quality attribute related risks,

supportability risks)
A risk taxonomy can be used to provide a framework for determining risk

sources and categories.
3.2 Define parameters used to analyze and categorize risks and to control the
risk management effort.
Parameters for evaluating, categorizing, and prioritizing risks include the

following:
• Risk likelihood (i.e., probability of risk occurrence)
• Risk consequence (i.e., impact and severity of risk occurrence)
• Thresholds to trigger management activities
Risk parameters are used to provide common and consistent criteria for
comparing risks to be managed. Without these parameters, it is difficult to
gauge the severity of an unwanted change caused by a risk and to prioritize
the actions required for risk mitigation planning.
Because circumstances change over time, parameters used to analyze and

categorize risks should be documented so they are available for reference.
This facilitates the re-categorization and analyzes when changes occur.
The activities associated with defining risk parameters typically include the
following:
1. Define consistent criteria for evaluating and quantifying risk likelihood
and severity levels.
Consistently used criteria (e.g., bounds on likelihood, severity levels)

allow impacts of different risks to be commonly understood, to receive
the appropriate level of scrutiny, and to obtain the management
attention warranted. In managing dissimilar risks (e.g., staff retention
versus data security), it is important to ensure consistency in the end
result. (For example, a high-impact risk of data security is as important
as a high-impact risk to staff retention.) One way of providing a common
basis for comparing dissimilar risks is assigning dollar values to risks
(e.g., through a process of risk monetization).
2. Define thresholds for each risk category.
For each risk category, thresholds can be established to determine

acceptability or unacceptability of risks, prioritization of risks, or triggers
for management action.
3. Define bounds on the extent to which thresholds are applied against or
within a category.
There are few limits to which risks can be assessed in either a quanti-
tative or qualitative fashion. Definition of bounds (or boundary condi-
Risk Management 197

tions) can be used to help define the extent of the risk management
effort and avoid excessive resource expenditures. Bounds can include
the exclusion of a risk source from a category. These bounds can also
exclude conditions that occur below a given frequency (unless of course
they have an extremely high potential impact).
3.3 Establish and maintain the strategy to be used for risk management.
A comprehensive risk management strategy addresses a range of items:
• T
he scope of the risk management effort
• M
ethods and tools to be used for risk identification, risk analysis, risk
mitigation, risk monitoring, and communication
• S
ources of risks
• H
ow risks are to be organized, categorized, compared, and consolidated
• P
arameters used for taking action on identified risks, including likelihood,
consequence, and thresholds
• R
isk mitigation techniques that can be used
• T
he definition of risk measures used to monitor the status of risks
• T
ime intervals for risk monitoring or reassessment
The risk management strategy should be guided by a common vision

of success that describes desired future outcomes for the task. The risk
management strategy is often documented in a risk management plan. This
strategy is reviewed with relevant stakeholders to promote commitment and
understanding.
Identification and assessment of critical risks allows the formulation of

risk-handling approaches and the adjustment of the allocation of resources
based on critical risks.
3.4 Identify, analyze, and document risks by following the organization’s

standard process.
Risk documents must include a concise statement of the risk and additional
information including at least the context, conditions, and consequences of
risk occurrence.
Risk identification should be an organized, thorough approach to seek

out probable or realistic risks in achieving objectives. To be effective, risk
identification should not attempt to address every possible event. Using
categories and parameters developed in the risk management strategy and
identified sources of risk can provide the discipline and streamlining appro-
priate for risk identification. Identified risks form a baseline for initiating risk
management activities. Risks should be reviewed periodically to reexamine
possible sources of risk and changing conditions to uncover sources and risks
previously overlooked or nonexistent when the risk management strategy was
last updated.
198 Risk Management

Risk identification focuses on the identification of risks, not the placement
of blame. The results of risk identification activities should never be used by
management to evaluate the performance of individuals.
Many methods are used for identifying risks. Typical identification methods
• Conduct a risk assessment using a risk taxonomy
• Interview subject matter experts
• Review risk management efforts from similar efforts
• Examine lessons learned documents or databases
• Examine agreement requirements
The following activities typically are involved in identifying risks:

1. Identify the risks associated with cost, schedule, and performance.
Risks associated with cost, schedule, performance, and other business

objectives should be examined to understand their effect on objectives.
Candidate risks may be outside the scope of objectives but vital to
customer interests.
In addition to the cost risks identified above, other cost risks can
include the ones associated with funding levels, funding estimates, and
distributed budgets.
Schedule risks can include risks associated with planned activities, key
events, and milestones.
Performance risks can include risks associated with the following:

• Requirements
• Analysis
• Application of new technology
• Physical size
• Performance maintenance attributes
2. Review environmental elements.
Risks to a project that are frequently missed include risks supposedly

outside the scope of the effort (i.e., does not control whether they occur
but can mitigate their impact). These risks can include weather or natural
disasters, political changes, and telecommunications failures.
3. Review all elements of the work breakdown structure as part of identi-
fying risks to help ensure that all aspects of the work effort have been
considered.
4. Review all elements of the plan as part of identifying risks to help ensure
that all aspects of the project have been considered.
5. Document the context, conditions, and potential consequences of each

risk.
Risk Management 199

6. Risk statements are typically documented in a standard format that
contains the risk context, conditions, and consequences of occurrence.
The risk context provides additional information about the risk such
as the relative time frame of the risk, the circumstances or conditions
surrounding the risk that has brought about the concern, and any doubt
or uncertainty.
7. Identify the relevant stakeholders associated with each risk.
3.5 Evaluate and categorize each identified risk using defined risk categories
and parameters, and determine its relative priority.
Risk evaluation allows identified risks to be assigned a relative importance,

and helps to determine when appropriate management attention is required.
Often, it is useful to aggregate risks based on their interrelationships and
develop options at an aggregate level. When an aggregate risk is formed by
a roll up of lower-level risks, care should be taken to ensure that important
lower-level risks are not ignored.
Collectively, the activities of risk evaluation, categorization, and prioritization

are sometimes called a “risk assessment” or “risk analysis.”
The following activities are involved in evaluating and categorizing risks:

1. Evaluate identified risks using defined risk parameters.
Each risk is evaluated and assigned values according to defined risk

parameters, which can include likelihood, consequence (i.e., severity,
impact), and thresholds. The assigned risk parameter values can be
integrated to produce additional measures, such as risk exposure (i.e.,
the combination of likelihood and consequence), which can be used to
prioritize risks for handling.
Often, a scale with three to five values is used to evaluate both likelihood
and consequence.
Likelihood, for example, can be categorized as remote, unlikely, likely,

highly likely, or nearly certain.
Example categories for consequence include the following:

• Low
• Medium
• High
• Negligible
• Marginal
• Significant
• Critical
• Catastrophic
200 Risk Management

Probability values frequently are used to quantify likelihood. Conse-
quences are generally related to cost, schedule, environmental impact, or
human measures (e.g., labor hours lost, severity of injury).
Risk evaluation is often a difficult and time consuming task. Specific

expertise or group techniques may be needed to assess risks and gain
confidence in the prioritization. In addition, priorities can require reevalu-
ation as time progresses. Consequences of the risks can be monetized to
provide a basis for comparing the impact of identified risks.
2. Categorize and group risks according to defined risk categories.
Risks are categorized into defined risk categories, providing a means to

review them according to their source, taxonomy, or project component.
Related or equivalent risks can be grouped for efficient handling. The
cause-and-effect relationships between related risks are documented.
3. Prioritize risks for mitigation.
A relative priority is determined for each risk based on assigned risk

parameters. Clear criteria should be used to determine risk priority.
Risk prioritization helps to determine the most effective areas to which
resources for risk mitigation can be applied with the greatest positive
impact on the project.
3.6 Develop a risk mitigation plan in accordance with the risk management
strategy.
Developing alternative courses of action, workarounds, and fallback positions

along with a recommended course of action is a critical component of
risk mitigation planning. The risk mitigation plan for a given risk includes
techniques and methods used to avoid, reduce, and control the probability
of risk occurrence; the extent of damage incurred should the risk occur
(sometimes called a “contingency plan”); or both. Risks are monitored, and
when they exceed established thresholds, risk mitigation plans are deployed
to return the affected effort to an acceptable risk level. If the risk cannot
be mitigated, a contingency plan can be invoked. Both risk mitigation and
contingency plans are often only generated for high or unacceptable conse-
quence risks. Other risks may be accepted and simply monitored.
Options for handling risks typically include the following alternatives:

• Risk avoidance - changing or lowering requirements while still meeting
end user needs
• Risk control - taking active steps to minimize risks
• Risk transfer - reallocating requirements to lower risks
• Risk monitoring - watching and periodically reevaluating the risk for

changes in assigned risk parameters
• Risk acceptance - acknowledging risk but not taking action
Often, especially for high-impact risks, more than one approach to handling a
risk should be generated.
Risk Management 201

For example, in the case of an event that disrupts the continuity of opera-
tions, approaches to risk management can include establishing the following
items:
• Resource reserves to respond to disruptive events
• Lists of available backup equipment
• Backups to key staff
• Plans for testing emergency response systems
• Posted procedures for emergencies
• Disseminated lists of key contacts and information resources for

emergencies
In many cases, risks are accepted or watched. Risk acceptance usually occurs
when the risk is judged too low for formal mitigation or when there appears
to be no viable way to reduce the risk. If a risk is accepted, the rationale for
this decision should be documented. Risks are watched when an objectively
defined, verifiable, and documented threshold (e.g., for cost, schedule,
performance, risk exposure) will trigger risk mitigation planning or invoke a
contingency plan.
The following activities typically are involved in developing a risk mitigation

plan:
1. Determine the levels and thresholds that define when a risk becomes
unacceptable and triggers the execution of a risk mitigation plan or
contingency plan.
Risk level (derived using a risk model) is a measure combining the uncer-
tainty of reaching an objective with the consequences of failing to reach
the objective.
Risk levels and thresholds that bound planned or acceptable cost,

schedule, or performance should be clearly understood and defined to
provide a means with which risk can be understood. Proper categori-
zation of risk is essential for ensuring an appropriate priority based on
severity and the associated management response. Multiple thresholds
can be employed to initiate varying levels of management response.
Typically, thresholds for the execution of risk mitigation plans are set to
engage before the execution of contingency plans.
2. Identify the person or group responsible for addressing each risk.
3. Determine the costs and benefits of implementing the risk mitigation

plan for each risk.
Risk mitigation activities should be examined for benefits they provide

versus resources they will expend. Just like any other design activity,
alternative plans may need to be developed and costs and benefits of
each alternative assessed. The most appropriate plan is selected for
implementation.
4. Develop an overall risk mitigation plan to orchestrate the implementation

of individual risk mitigation and contingency plans.
202 Risk Management

The complete set of risk mitigation plans may not be affordable. A
tradeoff analysis should be performed to prioritize risk mitigation plans
for implementation.
5. Develop contingency plans for selected critical risks in the event their
impacts are realized.
Risk mitigation plans are developed and implemented as needed to

reduce risks before they become problems. Despite best efforts, some
risks can be unavoidable and will become problems that affect the
project. Contingency plans can be developed for critical risks to describe
actions a project can take to deal with the occurrence of this impact. The
intent is to define a proactive plan for handling the risk. Either the risk is
reduced (mitigation) or addressed (contingency). In either event, the risk
is managed.
Some risk management literature may consider contingency plans a

synonym or subset of risk mitigation plans. These plans can also be
addressed together as risk handling or risk action plans.
3.7 Monitor the status of each risk periodically and implement the risk
mitigation plan as appropriate.
To effectively control and manage risks during the work effort, follow a
proactive program to regularly monitor risks and the status and results of
risk-handling actions. The risk management strategy defines the intervals at
which risk status should be revisited. This activity can result in the discovery
of new risks or new risk-handling options that can require replanning and
reassessment. In either event, acceptability thresholds associated with the
risk should be compared to the risk status to determine the need for imple-
menting a risk mitigation plan.
The activities involved in monitoring risks and implementing mitigation plans

typically involve:
1. Monitor risk status.
After a risk mitigation plan is initiated, the risk is still monitored.

Thresholds are assessed to check for the potential execution of a contin-
gency plan.
A mechanism for monitoring should be employed.

2. Provide a method for tracking open risk-handling action items to closure.
3. Invoke selected risk-handling options when monitored risks exceed

defined thresholds.
Often, risk handling is only performed for high and medium risks. The
risk-handling strategy for a given risk can include techniques and
methods to avoid, reduce, and control the likelihood of the risk or the
extent of damage incurred should the risk occur, or both. In this context,
risk handling includes both risk mitigation plans and contingency plans.
Risk Management 203

Risk-handling techniques are developed to avoid, reduce, and control
adverse impact to meeting objectives and to bring about acceptable
outcomes in light of probable impacts. Risk-handling actions require
proper resource loading and scheduling in plans and baseline schedules.
This replanning should closely consider the effects on adjacent or
dependent work initiatives or activities.
4. Establish a schedule or period of performance for each risk-handling
activity that includes a start date and anticipated completion date.
5. Provide a continued commitment of resources for each plan to allow the

successful execution of risk-handling activities.
6. Collect performance measures on risk-handling activities.

• Risk source lists (external and internal)
• Risk categories list
• Risk evaluation, categorization, and prioritization criteria
• Risk management requirements (e.g., control and approval levels,

reassessment intervals)
• Risk management strategy
• List of identified risks, including the context, conditions, consequences of

risk occurrence, and priority
• List of risks and their assigned priority
• Documented handling options for each identified risk
• Risk mitigation or contingency plans
• List of those who are responsible for tracking and addressing each risk
• Updated lists of risk status
Level 4: Measured
4.1 Using statistical and other quantitative techniques, analyze and determine
the quantitative risk to meeting the goals.
This can often involve the comparison of estimates, including their prediction
interval, to the quantitative objectives to calculate the amount of risk. Often,
the results of this calculation are monetized to determine the amount of
risk, which can then be analyzed versus the expected rate of return from the
activity to estimate returned value.

• Quantitative risk analysis results
204 Risk Management

Level 5: Optimized
5.1 Establish and maintain, using statistical and other quantitative techniques,
the quantitative risk posture for selected quantitative objectives.
The activities of this practice will give an organization, when combined

together for all of the efforts, an understanding of the total risk to meeting its
objectives.

• R
isk posture criteria
• R
isk posture documentation for applicable activities
Risk Management 205

Configuration Management
PURPOSE
Establish and maintain the integrity of the operational environment using configu-
ration identification, control, status accounting, and audits.
INTRODUCTORY NOTES
Configuration management is a partnership between business, data, and IT resources
to control the integrity of products, data stores, and interfaces, and changes to them.
Configuration management is a vital discipline; planning and coordination is essential.
Configuration management involves the following actions:
• Identifying the configuration of the operational environment and data interfaces

at given points in time
• Controlling and managing data interfaces and the operational environment
• Managing changes to data interfaces and the operational environment
• Maintaining the integrity of data interfaces and the operational environment
• Providing accurate status of data interfaces and the operational environment to

end users and customers
The operational environment and data interfaces placed under configuration

management include the products that are delivered to the customer; designated
internal work products; and acquired products, tools, and other items used in creating
and describing the data interfaces and operational environment.
Configuration management is focused on the rigorous control of the managerial and

technical aspects of the operational environment, including the delivered product or
service.
A configuration management system includes the storage media, procedures, and

tools for accessing the system. A configuration management system can consist of
multiple subsystems with different implementations that are appropriate for each
configuration management environment.
A change management system includes the storage media, procedures, and tools for
recording and accessing change requests.
GOALS
1. Maintain the integrity of data as changes occur.
2. Define and implement a configuration and release management system.
CORE QUESTIONS
1. How is configuration management implemented and measured?
2. How are data changes planned and controlled across the data lifecycle?
206 Configuration Management

Level 1: Performed
1.1 Configuration management is documented and implemented within projects.
1.2 Impact of data changes is assessed within systems and applications and
prioritized with input from business and data stakeholders as well as IT.

• Change records
• Release notes
• Impact analysis
Level 2: Managed
2.1 Changes in the operational environment are planned, managed, and tested
to determine impact on data stores and systems.
2.2 Vendor data changes are subject to the organization’s configuration

management processes.
2.3 Data interface changes are managed and controlled.

Change requests address new or changed requirements and failures and
defects in work products.
Change requests are analyzed to determine the impact that the change
will have on the work product, related work products, the budget, and the
schedule.

• C
onfiguration management processes documentation
• C
onfiguration management and release management records
• T
est results of changes
• S
ervice level agreements include change management processes
• C
hange request database
Level 3: Defined
3.1 A configuration management policy is defined, approved by governance,

and implemented for selected platforms across the organization.
The organization sets the parameters for selecting platforms that will be
subject to the policy.

3.2 Changes to data interfaces and operational environment are planned and
approved by stakeholders at the organizational level.
Managing changes typically involves the following activities:

1. Changes are evaluated through activities that ensure that they are
consistent with technical and project requirements.
2. Changes are evaluated for their impact beyond immediate project or

contract requirements. Changes to an item used in multiple products
can resolve an immediate issue while causing a problem in other appli-
cations.
3. Changes are evaluated for their impacts on release plans.
4. Emergency requests are identified and referred to an emergency

authority if appropriate.
5. Conduct the change request review with appropriate participants.

Record the disposition of each change request and the rationale for the
decision, including success criteria, a brief action plan if appropriate, and
needs met or unmet by the change. Perform the actions required in the
disposition and report results to relevant stakeholders.
6. Change requests brought into the system should be handled in an

efficient and timely manner. Once a change request has been processed,
it is critical to close the request with the appropriate approved action as
soon as it is practical. Actions left open result in larger than necessary
status lists, which in turn result in added costs and confusion.
3.3 An audit program ensures compliance with configuration management

policy across the organization.
Configuration audits confirm that the resulting operational environment and

documentation conform to a specified standard or requirement. Config-
uration-related records can exist in multiple databases or configuration
management systems. In such instances, configuration audits should extend
to these other databases as appropriate to ensure accuracy, consistency, and
completeness of configuration management information.
Configuration management audit programs typically conduct the following:

1. Assess the integrity of the operational environment.
2. Confirm that configuration management records correctly identify items

in the configuration management system.
3. Review the structure and integrity of items in the configuration

management system.
4. Confirm the completeness, correctness, and consistency of items in the

configuration management system.
5. Confirm compliance with applicable configuration management

standards and procedures.
6. Track action items from the audit to closure.
208 Configuration Management

3.4 Governance has established accountability and oversight for configuration
management processes for data management.

• C
onfiguration management policy
• C
onfiguration management processes
• S
takeholder approvals for changes
• Audit records
• C
onfiguration management and release management records
Level 4: Measured
4.1 Metrics are used to measure compliance and effectiveness of configuration

management policies and procedures.

• Stakeholder feedback
• Repository
• Recommendations
• Minutes from governance council related to configuration management

processes
Level 5: Optimized
5.1 Predictive models are evaluated and improved after completion of the
change.
5.2 Metrics and stakeholder feedback are analyzed to improve configuration

management of new releases from providers.
5.3 The organization shares experiences regarding configuration management

best practices with the industry.

• Predictive models for performance improvement of configuration
management processes
• Metrics and stakeholder feedback
• Recommendations
• Configuration audit results
• Change request aging reports
• Public presentations and other documents communicating configuration

management processes and experience

7 Infrastructure 212
Perform the
Functional
Practices
Support Implement a
213
Managed Process
Practices Institutionalize
217 Organizational
Standards
210 Infrastructure Support Practices

Infrastructure Support
Practices
Goals and practices for infrastructure support—model
components that constitute a support framework to aid
process execution in an organization adopting the DMM.
The infrastructure support practices (ISPs) are required for every process area.
For Level 1, they ensure that adopting organizational components (i.e., project, business unit,
etc.) perform the Level 1 practices.
For Level 2, the ISPs will help to ensure that adopting organizational components will do
the following: operate under an organizational policy, plan the process, provide resources,
assign responsibility, train people in the process, manage configurations, identify and involve
relevant stakeholders, monitor and control the process, objectively evaluate adherence, and
review status with higher level management.
For Level 3, they ensure the following: a set of standard processes is in place; organizational
assets support the use of the standard process; elements can be tailored from the standard
process to fit unique circumstances; process-related experiences are collected to support
future use and improvements.
PURPOSE
The infrastructure support practices are essential for effective and repeatable performance of
the implemented processes.
INTRODUCTORY NOTES
An effective and repeatable data managment process enables the organization to gain max-
imum value from the deployed improvements, and is more likely to be retained during times
of stress. When requirements and objectives for the process change, the implementation of
the process may also need to change to ensure that it remains effective.
Infrastructure Support Practices 211

IS 1 Perform the Functional Practices
The purpose of this infrastructure support practice is to produce the work products
and deliver the services that are associated with the processes implementing the
functional practices of the process areas up through the targeted capability level.
ISP 1.1 Perform the Functional Practices
212 IS1 Perform the Functional Practices

IS 2 Implement a Managed Process
The infrastructure support practices describe activities that address key support
practices that must be in place to support effective implementation of the functional
practices. The level of support corresponds with the Level 1-5 designation for specific
practice areas. For example, if the organization achieves an Infrastructure Support
Level 2 for a process area, it implies that the organization manages the execution
of processes through functional capability level 2. A policy that indicates that the
process will be performed has been established. A plan is in place for performing it.
Resources are provided, responsibilities assigned, training on how to perform it is in
place, selected work products from performing the process are controlled, and so on.
In sum, the process is planned and monitored just like any project or support activity.
Establish an Organizational Policy

ISP 2.1
This infrastructure support practice defines organizational expectations
for the process and makes these expectations visible to those members
of the organization who are affected. In general, senior management
is responsible for establishing and communicating guiding principles,
direction, and expectations for the organization. Not all direction from
senior management will bear the label “policy.” The existence of appropriate
organizational direction is the expectation of this infrastructural support
practice, regardless of the form in which it is communicated or how it is
imparted.
ISP 2.2 Plan the Process

This infrastructure support practice determines what is needed to perform
the process and to achieve the established objectives, to prepare a plan
for performing the process, to prepare a process description, and to get
agreement on the plan from relevant stakeholders.
The practical implications of applying an infrastructure support practice

vary for each process area.
Establishing a plan includes documenting the plan and a process

description. Maintaining the plan includes updating it to reflect corrective
actions or changes in requirements or objectives.
ISP 2.3 Provide Resources

This infrastructure support practice ensures that resources necessary to
perform the process are available when they are needed. Resources include
adequate funding, appropriate physical facilities, skilled staff resources, and
appropriate tools.
IS2 Implement a Managed Process 213

Inadequate resources may be addressed by increasing resources, or by
limiting scope, removing requirements, or adding constraints.
ISP 2.4 Assign Responsibility

This infrastructure support practice ensures establishment of accountability
for the process throughout the effort and for achievement of the specified
results. The people assigned must have the appropriate authority to
perform the assigned responsibilities.
Responsibility for the data profiling process can be assigned using existing
job descriptions or in living documents, such as the project plan.
Subpractices
1. Assign overall responsibility and authority for conducting the
process.
2. Assign responsibility and authority for performing specific activities.
3. Confirm that the people assigned understand their responsibility and

authority.
Train People
ISP 2.5
This infrastructure support practice ensures that staff resources have the
necessary skills and expertise to perform or support the process, and that
appropriate training is provided to those who will be performing the work.
Overview training is provided to inform individuals who interact with, or
manage, those who perform the work.
Examples of methods for providing training include self-study; self-directed

training; self-paced, programmed instruction; formalized on-the-job
training; mentoring; and formal and classroom training.
Training supports the successful execution of data profiling by establishing

a common understanding and by imparting the skills and knowledge
needed to conduct the process.
ISP 2.6 Manage Configurations

Place selected work products under appropriate levels of configuration
control.
This infrastructure support practice establishes and maintains the integrity

of the work products of the process (and their descriptions) throughout
their useful life. Selected work products are identified in the project plan,
along with a specification of the appropriate level of control.
Different levels of control are appropriate for different work products and
for different points in time. For some processes that are intended to be
repeated, it may be important to place work products under formal config-
uration management. This may include defining and establishing baselines
at predetermined points; baselines are formally reviewed and approved, and
214 IS2 Implement a Managed Process

serve as the foundation for further development of the designated work
products.
Identify and Involve Relevant Stakeholders

ISP 2.7
Identify and involve the relevant stakeholders of the process as reflected in
the project plan.
This infrastructure support practice establishes and maintains the expected

involvement of relevant stakeholders during the execution of the process.
Typically, the stakeholders are identified in the project plan, and their
involvement may include activities such as the following:
• Planning, goals and objectives
• Commitments and resources
• Communications and coordination
• Appraisals and evaluations
• Resolution of problems and issues
• Subject matter expertise
• Review and decisions
ISP 2.8 Monitor and Control the Process

Monitor and control the process against the project plan and take appro-
priate corrective action.
This infrastructure support practice ensures that direct day-to-day

monitoring and controlling of the process is operational. Appropriate
visibility into the process is maintained so that appropriate corrective
action can be taken when necessary. Monitoring and controlling the process
can involve evaluating and measuring relevant attributes of the process, the
work products, and the services produced by the process.
Subpractices
1. Evaluate actual progress and performance against the plan. The evalu-
ations are of the process, its work products, and its results.
2. Review accomplishments and results of the process against the plan.
3. Review activities, status, and results of the process with the immediate
level of management responsible and identify issues.
4. Reviews are intended to provide the immediate level of management

with appropriate visibility into the process based on the day-to-day
monitoring and controlling of the process, and are supplemented by
periodic and event-driven reviews with higher level management.
5. Identify and evaluate the effects of significant deviations from the

plan.
6. Identify problems in the plan and in the execution of the process.
IS2 Implement a Managed Process 215

7. Take corrective action when requirements and objectives are not being
satisfied, when issues are identified, or when progress differs signifi-
cantly from the plan for performing the process.
8. Track corrective action to closure.
ISP 2.9 Objectively Evaluate Adherence

Objectively evaluate adherence of the process and selected work products
against the process description, standards, and procedures, and address
noncompliance.
This infrastructure support practice ensures that the process and selected
work products are implemented as planned, and compliant with the process
description, standards, and methods.
In many organizations, individuals not directly responsible for managing or

performing the activities of the process instance conduct the evaluation for
compliance. The timing of this function is usually specified as a review event
in the project plan.
Review Status with Senior Management

ISP 2.10
Review the activities, status, and results of the process with higher level
management and resolve issues.
This infrastructure support practice provides higher level management

with the appropriate visibility into the process. Senior management is
the immediate level of management responsible for the process, and may
include executive management. Process reviews are targeted to managers
who provide policy and overall guidance for the process, versus for those
who perform the direct day-to-day monitoring and controlling of the
process.
These reviews provide management with the information needed for

informed decisions. Therefore, they are typically periodic, event-driven,
and specified in the project plan.
216 IS2 Implement a Managed Process

IS 3 Institutionalize Organizational Standards
The support infrastructure processes support the effective implementation of a

defined process.
Establish Standards
ISP 3.1
Establish and maintain standards for performing the process.
This infrastructure support practice establishes and maintains organi-

zational standards for a process that address how the organization will
achieve capability Level 3. Standards include a standardized, communicated
process as well as criteria and guidelines for tailoring the process to meet
the needs of specific instances in specific contexts. With standards and
guidelines, variability in how the process is conducted across the organi-
zation is reduced, and process assets, data, and learning can be effectively
shared, while allowing local criteria-based tailoring to meet organization or
customer-specific needs.
Standards for a process can be defined at multiple levels in an organization

and they can be related hierarchically. For example, an enterprise can have
a standard that is tailored by individual organizations (e.g., a division, a site,
a cross-cutting program) to establish organization-specific standards for
the process, but generally, organization-specific standards will build on—not
remove—elements of the enterprise standard to ensure applicability of the
top-level standard across the enterprise. Standards can also be tailored
for each of the organization’s business areas, product lines, or standard
services. Multiple standards for the process may be required to address the
needs of different business domains, lifecycle models, methodologies, and
tools.
Subpractices
1. Decompose the process (processes) addressing the process area
into constituent activities to an appropriate level, to understand,
communicate, and describe the process. Elements are described such
that the process, when fully defined, can be consistently performed by
appropriately trained and skilled staff resources.
Examples of process elements include the following:

• Tailorable peer review methodology
• Template for conducting management reviews
• Templates or task flows embedded in workflow tools
IS3 Institutionalize Organizational Standards 217

2. Specify the critical attributes of each process activity. Examples of
critical attributes include the following:
• Applicable standards, methods, tools, and resources
• Process performance objectives
• Entry and exit criteria
• Inputs, outputs, controls, and mechanisms
• Verification points (e.g., peer reviews)
• Product and process measures
3. Specify relationships among process elements.
Examples of relationships include the following:

• Order of the process activities
• Interfaces among process activities
• Interfaces with external processes
• Interdependencies among process activities
4. Establish tailoring criteria and guidelines for the process that specify
the method for creating the defined processes, requirements that must
be satisfied, options that can be exercised, and procedures that must
be followed.
5. Tailoring is an important activity that allows practical and controlled

changes to processes according to the specific needs of a project
or an organizational unit. Processes and activities directly related to
critical business objectives should usually be defined as mandatory,
but those that are less critical or only indirectly affect business objec-
tives may allow for more tailoring. Tailoring criteria and guidelines
include use of the standard process “as is,” with no tailoring.
6. Ensure that the standards and tailoring guidelines for the process
adhere to applicable policies, standards, and models.
7. Ensure that the standards and tailoring guidelines satisfy the process
needs and objectives of the organization.
8. Ensure that appropriate integration is taking place with other

processes, toolsets, and tailoring guidelines.
9. Revise the organization’s standards and tailoring guidelines as

necessary.
10. Examples of when standards for the process may need to be revised
• When improvements to the process are identified
• When causal analysis and resolution data indicate that a process

change is needed
• When the organization’s process needs and objectives are

updated
218 IS3 Institutionalize Organizational Standards

• Organization’s standards for performing the process
• Organization’s criteria and guidelines for tailoring the standard

process
ISP 3.2 Provide Assets that Support the Use of the Standard Process
Establish and maintain organizational process assets that support the future
planning and performance of the process.
This infrastructure support practice provides relevant assets; in particular:

1) process-related experiences—especially measures, measurement results,
and lessons learned—so that planning and performance of the process will
benefit from prior experiences and what has been learned (e.g., strengths,
limitations, challenges) and 2) standard toolsets enabling the process to be
conducted more efficiently, reducing the need for time-consuming manual
processes.
Examples of organizational process assets include lifecycle models for the

process, selected artifacts, an organizational measurement repository, an
organizational process asset library, standards pertaining to the process,
and standard toolsets.
Subpractices
1. Establish and maintain criteria for specifying the measures and
measurement results to be included in the organization’s measurement
repository.
It is advisable to develop a repository containing both product and

process measures that are related to the process. It should contain or
refer to information needed to understand and interpret measures and
to assess them for reasonableness and applicability.
2. Establish and maintain criteria for specifying items to be included in

the organization’s process asset library.
3. Establish and maintain standard organizational toolset(s) that support

planning and conducting the process.

• Criteria for measures and measurement results to be included in the
organization’s measurement repository
• Criteria for work products and lessons learned to be included in the
organization’s process asset library
• Organizational standard toolset(s).
ISP 3.3 Plan and Monitor the Process Using a Defined Process
Establish and maintain the defined process.
This infrastructural support practice establishes and maintains a description

of the process that conforms to the organization’s standards for the process
IS3 Institutionalize Organizational Standards 219

and is tailored from the organization’s set of standard processes to address
the needs of a specific instantiation.
The defined process should 1) identify roles, responsibilities, and interfaces;

2) be sufficiently precise to enable those executing the process to measure,
manage, and improve their work performance; and 3) support decision
making pertaining to the process.
The descriptions of the defined processes provide the basis for planning,
performing, and managing the activities, work products, and services
associated with the process.
Subpractices
1. Select from the organization’s set of standard processes those
processes that address the process area through capability level 3,
and best meet the needs of the project, work group, or organizational
function.
2. Establish the defined process by tailoring the selected processes

according to the organization’s tailoring guidelines.
3. Ensure that the organization’s process objectives and standards are

appropriately addressed in the defined process.
4. Document the defined process and the records of the tailoring.
5. Revise the description of the defined process as necessary.
ISP 3.4 Collect Process-Related Experiences to Support Future Use

Collect process-related experiences derived from planning and performing
the process to support the future use and improvement of the organiza-
tion’s processes and process assets.
This infrastructure support practice establishes the collection of process-re-

lated experiences, such as information and artifacts created from planning
and conducting the process. Examples include work products, measures,
measurement results, lessons learned, and process improvement sugges-
tions. Information and artifacts are collected and included in the organiza-
tional process assets and made available to those who are (or who will be)
planning and performing the same or similar processes. The information and
artifacts are stored in the measurement repository and the organization’s
process asset library.
220 IS3 Institutionalize Organizational Standards

Appendix
Glossary of Terms and Acronyms
AGILE
A software development approach based on incremental and iterative development of
functionality, characterized by collaboration, user interface design with the customer, and
time-boxing of activity steps. These techniques have also been applied in nondevelopmental
circumstances.
ASSESSMENT
A determination of the strengths and weaknesses of an organization through the evaluation
of their processes and results against a standard model framework. Synonym - appraisal.
ATTRIBUTES
A fact, property, or characteristic of an entity. In a physical form, referred to as a “column,”
a “data element,” or a “field.” Examples: Customer Name, Product Classification Code, Trade
Price.
AUTHORITATIVE SOURCE
An official source of information, which includes, but is not restricted to, a trusted source or a
“system of record.” Authoritative source may refer to the source that creates the data or the
“best source” for a specific data set, depending on context.
BUSINESS UNIT
An organizational unit, typically under the management of a single leader, that is responsible
for the management of products and services. It typically measures performance in terms of
profit and loss, and utilizes shared services such as finance, accounting, operations, IT, and
human resources.
BUSINESS RULES
a) Define or constrain some aspect of the business to implement a strategy or ensure oper-
ational consistency. For example: “A loan cannot be approved unless 30-day seasoned down
payment funds are verified.”
b) A testable rule expressed in business English, specifying logic for automated execution,
typically captured in a requirements document. Example: “If the Customer Status Code is
“Active” and the “Cumulative Customer Sales Amount” is over $10,000.00, set Customer
Level Code to ‘Valued.’”
CORE ATTRIBUTES
Attributes that highly impact one or more business process of the organization. The DMM
uses the term to refer either to shared data, such as master and reference data, or to a pur-
pose-focused data set, such as attributes with regulatory import that may be from multiple
Appendix 221

data sources. Synonym - core data
CORPORATE DATA LAYER

The collection of implemented data stores and interfaces that store and deliver data for
applications and business users. Includes operational system data stores, batch interfaces,
point-to-point interfaces, data services, and data stores in the enterprise data warehouse
environment.
COTS
Commercial off-the-shelf software. COTS systems typically have their own vendor-specific
data model and representations; when an organization is developing a Business Glossary and
the corresponding logical and physical metadata to describe existing data assets, COTS data
stores need to be addressed, typically through mapping. For example, “Flex field 12” contains
“Customer Comment.”
CRITICAL ATTRIBUTES
Attributes that highly impact the performance of important business processes, or are
needed for a specific business purpose; for example, attributes contained in audited financial
statements.
CRUD
Create, Read, Update, Delete. Identifies the actions that business processes or subprocesses
execute on data. Typically represented in a modeling tool or spreadsheet matrix. Data actions
can be summarized or generalized for subject areas or high-level entity types in a conceptual
data model, and are captured at the attribute level in the integration of a business process
and logical data model.
DATA ATTRIBUTES
Attributes are properties of an entity type. The DMM states that they should be based on
approved business terms from the Business Glossary. Attribute names follow the conventions
set out in the organization’s data standards, and business terms are modified as needed to
conform to standards. Example: A business term “Date of Plan Termination” may have the
attribute name of “Plan Termination Date.”
DATA CLEANSING
The mechanisms, processes, methods, and processes employed to validate or correct data
with respect to predefined business rules, allowed values, ranges, etc.
DATA CLEANSING TOOL

A software product used to remediate errors and anomalies in one or more data stores.
DATA CLEANSING RULES

The specific business rules applied in defined process steps against a data set to discover
defects.
DATA GOVERNANCE
Implements structures and establishes policies aimed to help achieve strong participation
222 Appendix

across the organization for critical decisions affecting the data assets. Data governance
structures are groups that are comprised of data management stakeholders, whose function
is to ensure the data management program is held accountable to organization-wide needs
and is oriented toward the fulfillment of business and data management objectives. Gover-
nance groups can be established for specific purposes, such as approving enterprise require-
ments for a master data hub, and may also be standing bodies with sustained responsibilities,
such as establishing policies and monitoring compliance. A group need not have the title of
“data governance” to be considered functionally valid for assessment purposes.
DATA INTEGRATION
Transporting and processing (selecting, connecting, combining, de-duplicating, transforming
representations, etc.) data from multiple sources into a destination environment.
DATA LIFECYCLE
The linked chain of critical processes to create, read, update, and delete (CRUD) data through
the extent of its useful life in the business and eventual archiving or destruction. Typical data
lifecycle phases include the following:
• Business Direction (data requirements, creation and acquisition)
• Development (architecture and design)
• Implementation (physical architecture)
• Deployment (insertion into the operational environment)
• Operations (data transformations, usage, performance, and maintenance)
• Retirement (decommissioning and archiving)
DATA LINEAGE
Traceability of data attributes according to their process dependencies from origination
through to consumption and reporting.
DATA MANAGEMENT COMPLIANCE PROGRAM

The collection of organization processes established and enforced to validate conformance
with existing policies and standards.
DATA MANAGEMENT COMPONENTS

The disciplines and subdisciplines of data management that collectively interact in the pro-
curement, management, improvement, and delivery of data. Examples: data governance, data
quality, data standards.
DATA MANAGEMENT OBJECTIVES

Planned outcomes that are used to measure progress against the achievement of data man-
agement goals.
DATA MANAGEMENT STANDARDS

The collective set of standards that supports all of the organization’s data management
disciplines, developed and used to prescribe consistent approaches to data management.
Examples: business term standards, data profiling standards, data integration standards.
Appendix 223

DATA MANAGEMENT STRATEGY
A vision, objectives, and plan for the organization’s data management program. The vision
illustrates how the organization will fund, govern, and manage data. Specific organiza-
tion-wide objectives are achievement targets. The strategic plan integrates the components
into a sequence based on priorities and logical dependencies.
DATA MANAGEMENT PROFESSIONALS

People who perform data management processes and practices, which correspond to prac-
tice statements in the DMM. Synonym – data management practitioners.
DATA QUALITY DIMENSIONS

The language of data quality facilitates a shared understanding that is essential for ensuring
business requirements are met by established quality criteria, measuring defects, and
communicating within and across organizations priorities, measurement scores, thresholds,
and targets. Dimensions typically include the following: accuracy, completeness, validity,
timeliness, integrity, consistency, conformity, and uniqueness.
DATA QUALITY FRAMEWORK

The selected principles, paradigm, or model within which the data quality strategy and
implementation will be executed. Typically involves four phases of activity for the selected
data sets or data stores: identify, remediate, prevent, monitor systematically for continuous
improvement.
DATA QUALITY STRATEGY

An organization’s vision and plan for improving and sustaining data quality. It typically
includes goals, objectives, benefits, business cases, policies, compliance, governance, and
implementation priorities.
DATA REQUIREMENTS
Definition of the data needed to achieve business objectives. Data requirements should be
stated in business language and should reuse any approved, available standard business
terms from an authoritative business glossary.
DATA STEWARD
A line of business individual who accepts responsibility for a data set of business terms,
attributes, and data elements. The data steward is responsible for ensuring that the meaning,
usage, and representations of the data set are according to business purpose and conform
to the organization’s standards. A data stewards group is typically one of the organization’s
data governance bodies, with membership from multiple lines of business.
DEFINED
Designed according to a precise template and instantiated as one or more documents.
ENTITY
A person, place, thing, concept, or event of interest to the organization, about which informa-
tion is kept. Examples: Product, Customer, Annual Conference. In data modeling terminology,
the term Entity Type (e.g., “Customer”) refers to the data object; and the Entity is an instance
224 Appendix

of that object (e.g.. Joe Smith, Mary Black).
ETL
Extract, transform, load. The process by which data is obtained from one or more sources,
transformed into the destination data representations, and loaded into a data store. Business
rules (logic) are applied for data selection and data transformations. Typically accomplished
employing an ETL software product.
EXECUTIVE MANAGEMENT
Executives are individuals who lead major decision-making functions that directly and indi-
rectly impact the organization. For the purposes of the DMM, executive management has the
power to sponsor large-scale, long-term strategic initiatives that are intended to benefit the
entire organization. Examples of executives include Board Chairman, Chief Executive Officer,
Chief Financial Officer, and Chief Operating Officer. As titles vary, the DMM primarily refers
to individuals with major authority over data management programs and activities or over
business processes and corresponding data stores.
IMPLEMENTATION PLAN
A detailed work breakdown structure, addressing interdependencies, resources, beginning
and end dates, assigned resources, etc., which guides the implementation of a data manage-
ment initiative.
INSTITUTIONALIZED
Formalized and embedded within the culture and infrastructure of the organization as a
common resource or method.
KPI
Key performance indicator. Measures and metrics that are used to identify the level of
achievement of objectives or results identified by the organization as very important.
MASTER DATA MANAGEMENT

Management and centralization of high shared data about the core entity types of an organi-
zation, which provides essential identification and reference for business transactions across
multiple business areas.
MEASURE
A measure is a count that is collected, and presents a quantified result that is used for report-
ing and monitoring. Measures may be tracked and intended to create a baseline. Examples of
measures include number of defects, transaction counts, number of lines of code, number of
duplicates.
METRIC
Metrics specify the quantification of business meaning. Specifically, a metric defines the
calculation method (+, -, *, /, %, etc.) and unit of measure(s), as well the meaning and context
of the specified measurements.
Appendix 225

ORGANIZATIONAL PROCESS PERFORMANCE
The measurement of effectiveness within the activity steps of a specified business process.
May address durations, lag time, dependencies, etc.
OWNER
The responsible party for a business data asset, typically the line of business individual who
is in charge of a business process or application data store. In the DMM, owners are also
referred to at the subject area level, as the organization moves toward centralization of
shared data assets.
PERIODIC, PERIODICALLY
Held or executed at planned intervals.
POLICY
A guiding principle typically established by senior management that is adopted by an organi-
zation to influence and determine decisions.
PROCEDURE
A procedure is an action or set of actions that is performed in a prescribed manner, de-
scribing HOW a process activity step is accomplished. When decomposing processes, the
procedure(s) are defined at the lowest level of detail for standardizing operational execution.
PROCESS
A structured set of activity steps performed to accomplish a result. A process describes
WHAT is done. When documented, typically addresses triggering event; inputs; controls;
mechanisms; outputs; and roles.
PROCESS MODEL FORMATS

Approaches to modeling business processes and process usage of data, such as data flow
diagrams, flow charts with swim lanes, IDEF 1 and 3, BPMM, UML, etc.
PROCESS PERFORMANCE MODEL

A description of relationships among measurable attributes of one or more processes or work
products. The model is developed from historical process performance data and is used to
predict future performance. Process performance models include statistical, probabilistic, and
simulation-based models that predict interim or final results. They model variations of the
factors, and provide insight into the expected range and variation of predicted results.
PROMULGATION
The act of formally proclaiming or declaring a new statutory or administrative policy after its
enactment. In the DMM, this term is used to emphasize the importance of communication and
verifiable instantiation.
REGULAR MEETINGS
Discussions that recur according to a set schedule or are triggered by pre-specified events.
226 Appendix

RESILIENCY
A resilient architecture presents a framework or principles for implementation that can be
used as a guide to establishing a high level of system robustness and fault tolerance and
recovery from abnormal usages or disruptions. Resiliency, scalability, maintainability, and
extensibility are aspects of architectural, application, and data store design, and are applied
to architectural decisions, technology selection, and technical requirements.
RESPONSIBILITY MATRIX
An inventory of assets (documents, systems, etc.) aligned with the people who are responsi-
ble for them. The abbreviation RACI is typically used, referring to Responsible, Accountable,
Consulted, and Informed roles. RACI is also often applied to process, project, and governance
responsibilities.
ROADMAP
Illustrates a high-level view of the major elements of the data management strategy and the
order of execution, typically at the project or initiative level.
ROOT CAUSE ANALYSIS

The determination of the source of defects within an interdependent linkage of processes.
SCALABILITY
Architecture appropriately (based on requirements) manages the resources consumed by the
application component or services to maintain acceptable latency and throughput with the
increasing load.
SEMANTIC REPOSITORY
Stored content pertaining to the meaning of the concepts represented by the data. In the
DMM, the semantic repository concept is addressed in the process areas Business Glossary
and Metadata Management.
SENIOR MANAGEMENT
A level of management that has the power to allocate resources for the long-term benefit of
the organization (i.e., hire, fire, and manage a budget). Senior managers are those individuals
whose support is needed to establish or enforce corporate policy. In this model, executive
management has broader authority than senior management.
SEQUENCE PLAN
A translation of the roadmap into a mid-level time-line, which includes a high-level work
breakdown structure, key interdependencies, and important milestone dates.
SERVICE LEVEL AGREEMENT (SLA)

Specifies delivered services; service measures; levels of acceptable and unacceptable service;
and expected responsibilities, liabilities, and actions of both the provider and customer in
anticipated situations.
STAKEHOLDER
An individual or organization that is affected by a decision about architecture, technology,
Appendix 227

an application, a data store, or a data set. Each data management initiative typically has a
corresponding stakeholder group.
STANDARD PROCESS
An operational definition of the overarching process that guides the establishment of a
common process in an organization. A standard process describes the fundamental process
elements that are expected to be incorporated into any defined process. It also describes
relationships (e.g., ordering, interfaces) among these process elements.
SYSTEM DEVELOPMENT LIFE CYCLE (SDLC)

A series of phases and activity steps that provides a framework for the requirements, design,
development, and maintenance of application software and databases. Methods, required
steps, and supporting processes and documentation can vary with the organization. Two of
the most common SDLC frameworks utilized are Waterfall and Agile.
SYSTEM OF RECORD
An information system that acts as the authoritative repository accountable for active man-
agement (create, update and delete) of a specific set of data at one or more specified stages
in their lifecycle.
TEMPLATES
Predefined forms of documents that guide the topics addressed when a specific instantiation
is created.
TRUSTED SOURCE
Any source that delivers data that users can trust with confidence to meet their objectives,
ideally without need for reconciliation or remediation. An example is a system of record or an
authoritative data source.
VALIDATION
Assurance that a product, service, process, or system meets the needs of the customer and
stakeholders.
228 Appendix

Table of Acronyms
AICPA AMERICAN INSTITUTE OF CERTIFIED PUBLIC ACCOUNTANTS

API APPLICATION PROGRAM INTERFACE
BCP BUSINESS CONTINUITY PLAN(S)
BI BUSINESS INTELLIGENCE
BOD BOARD OF DIRECTORS
BPI BUSINESS PROCESS IMPROVEMENT
BPM BUSINESS PROCESS MANAGEMENT
CCB CHANGE/CONFIGURATION CONTROL BOARD
CDO CHIEF DATA OFFICER
CEO CHIEF EXECUTIVE OFFICER
C-LEVEL TOP (CHIEF)-LEVEL (EXECUTIVE)
CMMI CAPABILITY MATURITY MODEL INTEGRATION
CMU CARNEGIE MELLON UNIVERSITY (IN PITTSBURGH, PA)
COE CENTER OF EXCELLENCE
COOP CONTINUITY OF OPERATIONS
COP COMMUNITY OF PRACTICE
COTS COMMERCIAL OFF-THE-SHELF
CPI COST PERFORMANCE INDEX
CRUD CREATE, READ/REVIEW, UPDATE, DELETE
DB DATABASE
DBA DATABASE ADMINISTRATOR
DDL DATA DEFINITION LANGUAGE
DLM DATA LIFECYCLE MANAGEMENT
DMM DATA MANAGEMENT MATURITY (MODEL)
DQ DATA QUALITY
DW DATA WAREHOUSE
EA ENTERPRISE ARCHITECTURE
EDM ENTERPRISE DATA MANAGEMENT
ELT EXTRACT, LOAD, TRANSFER (OF DATA)
EOL END OF LIFE/LEASE
ERD ENTITY RELATIONSHIP DIAGRAM
ETL EXTRACT, TRANSFORM, LOAD OR EXTRACTION, TRANSFORMATION,
LOADING (OF DATA)
EVM EARNED VALUE MANAGEMENT
FCA FUNCTIONAL CONFIGURATION AUDIT
FMEA FAILURE MODE AND EFFECTS ANALYSIS
Appendix 229

FOSS FREE AND OPEN SOURCE SOFTWARE
ISP INFRASTRUCTURE SUPPORT PRACTICE
IT INFORMATION TECHNOLOGY
KPI KEY PERFORMANCE INDICATOR
KPM KEY PERFORMANCE METRIC
LOB LINE OF BUSINESS
MDM MASTER DATA MANAGEMENT
MISMO MORTGAGE INDUSTRY STANDARDS MAINTENANCE ORGANIZATION
MTBF MEAN TIME BETWEEN FAILURES
ODS OPERATIONAL DATA STORE
OJT ON-THE-JOB TRAINING
ORM OPERATIONAL RISK MANAGEMENT
PCA PHYSICAL CONFIGURATION AUDIT
PMO PROGRAM MANAGEMENT OFFICE/OPERATIONS
QC QUALITY CONTROL
RACI RESPONSIBLE, ACCOUNTABLE, CONSULTED, INFORMED (MATRIX)
RFC REQUEST FOR COMMENT(S)
ROE RETURN ON EQUITY/EFFORT
ROI RETURN ON INVESTMENT
SDLC SOFTWARE/SYSTEM DEVELOPMENT LIFECYCLE
SEI SOFTWARE ENGINEERING INSTITUTE
SLA SERVICE LEVEL AGREEMENT
SME SUBJECT MATTER EXPERT
SOC SERVICE ORGANIZATION CONTROL (THREE TYPES OF REPORTS)
SPI SCHEDULE PERFORMANCE INDEX
TCO TOTAL COST OF OWNERSHIP
UAT USER ACCEPTANCE TEST
WBS WORK BREAKDOWN STRUCTURE
XBRL EXTENSIBLE BUSINESS REPORTING LANGUAGE
XML EXTENSIBLE MARKUP LANGUAGE
230 Appendix

ABOUT THE DATA MANAGEMENT
MATURITY (DMM)SM MODEL
The DMM model helps organizations become
more proficient in managing critical data
assets to improve operations, enable analyt-
ics and gain competitive advantage. A key
goal of the DMMSM model is to represent and
support data professionals across all organi-
zations that need to realize high value from
their data assets.
By working with businesses, government

and data management associations, CMMI®
Institute and our DMM sponsors have gar-
nered critical insight and strong support from
over 100 data management professionals
representing 45 different organizations that
contributed to the development of the DMM.
Appendix 231
ABOUT CMMI® INSTITUTE
The Data Management MaturitySM model was developed using the principles and structure of
CMMI Institute’s Capability Maturity Model Integration (CMMI)®—a proven approach to perfor-
mance improvement and the gold standard for software and systems development around
the world.
The CMMI® Institute is part of Carnegie Innovations, a technology commercialization enter-

prise and part of Carnegie Mellon University. CMMI® is the result of more than 20 years of
ongoing work at Carnegie Mellon University by members of industry, government, and the
Software Engineering Institute, a federally funded research and development center.
©2014 CMMI Institute. All rights reserved. Capability Maturity Model Integration, CMMI & Carnegie Mellon
are registered marks of Carnegie Mellon University. The CMMI logo and Data Management
Maturity (DMM) are service marks of CMMI Institute.
232 Appendix

DMMM

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

DMMM

Încărcat de

Drepturi de autor:

Formate disponibile

Data Management

Maturity (DMM) Model

AUGUST 2014 | VERSION 1.0

Licensed to Davi Meireles, 2015-05-29 #5864290

BOOZ ALLEN HAMILTON

“This is a critical period for effective data management

Licensed to Davi Meireles, 2015-05-29 #5864290

“As organizations have become more dependent on data

“DMM has accelerated the Microsoft Real-Time Enterprise

Licensed to Davi Meireles, 2015-05-29 #5864290

This document represents thousands of hours of work by representatives from a variety of

DATA MANAGEMENT MATURITY MODEL - LEADERSHIP TEAM

MODEL DEVELOPMENT TEAM

Licensed to Davi Meireles, 2015-05-29 #5864290

Peter Aiken Dilip Gore Philip Michaelson

Licensed to Davi Meireles, 2015-05-29 #5864290

THIS CMMI INSTITUTE MATERIAL IS FURNISHED ON AN “AS-IS” BASIS. CMMI INSTITUTE

Licensed to Davi Meireles, 2015-05-29 #5864290

About the DMM 2

Organization of the DMM 3

Capability and Maturity Measurement 8

Data Management Strategy 11

Data Management Strategy 12

Related Process Areas 14

Functional Practice Statements 14

Licensed to Davi Meireles, 2015-05-29 #5864290

Related Process Areas 21

Functional Practice Statements 21

Data Management Function 24

Related Process Areas 25

Functional Practice Statements 25

Related Process Areas 33

Functional Practice Statements 33

Related Process Areas 38

Functional Practice Statements 38

Licensed to Davi Meireles, 2015-05-29 #5864290

Related Process Areas 46

Functional Practice Statements 46

Related Process Areas 52

Functional Practice Statements 53

Related Process Areas 60

Functional Practice Statements 60

Data Quality Strategy 70

Licensed to Davi Meireles, 2015-05-29 #5864290

Related Process Areas 71

Functional Practice Statements 72

Related Process Areas 78

Functional Practice Statements 78

Data Quality Assessment 84

Related Process Areas 85

Functional Practice Statements 85

Related Process Areas 91

Functional Practice Statements 91

Data Requirements Definition 98

Licensed to Davi Meireles, 2015-05-29 #5864290

Related Process Areas 99

Functional Practice Statements 99

Data Lifecycle Management 105

Introductory Notes 105

Core Questions 106

Related Process Areas 107

Functional Practice Statements 107

Provider Management 111

Data Management Strategy  11

Platform and Architecture  117

Supporting Processes  151

Infrastructure Support Practices  211