Page 23 -

2 CHAPTER 1

is also unabashedly a treatise to convince organizations to think differently about how to manage their
information and data universe. To be clear, real data governance requires that organizations act
differently in regard to their use and management of content, meaning data, information, documents,
media, et al. You implement data governance by overseeing the management of these instances of
content, as well as projects and processes that create, use, and dispose of content.
This book does not distinguish between data governance and information governance, although
some authors do. From a practical viewpoint, there is no real difference. We could conjure up some
philosophical argument that there is a difference, but experience has shown these discussions only
serve to confuse and reduce the effectiveness of the program.
Data governance is absolutely a mandatory requirement for success if an organization wants to
2
achieve master data management, build business intelligence, improve data quality, or manage
documents. However, DG is not an eternally lasting add-on process. This may seem contrary to much
of the literature flying about the information industry at the time of this book’s writing. There are many
articles, for example, on how to design the DG “department,” when you are really designing
a framework to govern.
At the end of the day, we are modifying people’s behaviors and business processes to think more
clearly about the care and feeding of data. If we do this correctly, there is no need for large incremental
groups of people implementing something brand new. Organizations love to jump on bandwagons and
then bang on the “next big thing” until it surrenders. Frankly, this book is determined to prevent that.
When it comes to data governance, the devil is in the mindset (as well as in the details).
As stated earlier, the next three chapters form an executive-oriented section. The purpose is to
provide background, value proposition, and business relevance.
Chapter 2 will first establish a common vocabulary. The author’s practice in this area has deter-
mined that the slightest variations in semantics can become huge obstacles. Therefore, we will present
a set of terms and definitions as well as context. We will always provide the context of the term as well
as refer to the definition. That way, if you read another version of a term like “policy,” you at least have
a frame of reference.
We will also stick to business terminology. If there is a technical aspect of a topic, it will be
presented in business terms. If there is a business metaphor to lock in a point, it will be used in place of
a technology metaphor.
Once we establish the terminology, we will cover the basic elements of the DG or IG program. We
will present the core managerial and business concepts required for building and operating a DG
program. Since DG is a business program, you may feel quite at home reviewing the various pieces and
intersections of people, processes, and information technology.
Please thoughtfully read the text that addresses the scope of DG. One of the most critical errors that
can be made while designing a DG program occurs when an organization has the initial conversation
on scope and priorities. This examination also segues into a discussion on the business role of DG. The
value proposition of DG needs to be clearly understood by executives if DG is to be successful. Finally,
this part of the book is important because if data governance is misunderstood, it leads to a tendency to
jam it into another box on the organization chart of the IT department, and this is often a fatal mistake.
The elements, scope, and business role sections are part of an overall segment that provides an
overview of the entire DG program. It continues with a detailed examination of who should do the

2
If you are unfamiliar with the terms master data, data quality, and so on, relaxdwe will define them in the next chapter.