Page 24 -

Introduction 3

governing, what activities they need to perform, what is actually governed, and how DG looks when it
occurs.
The first three chapters present an effective executive-level overview of deploying data governance
so a CEO would have enough confidence to hand the book to a subordinate with instructions to develop
a plan of attack. In essence, the first section of the book covers the higher levels of business thinking. If
we were to view the realm of an enterprise’s information architecture as a matrix representing the
conceptual view through the physical, we might say the first few chapters address the top two levels of
3
the matrix, or framework. In other words, we cover DG deployment from a conceptual and logical
view. Figure 1-1 shows this.
The next few chapters address the middle layers from a level of orientation and understanding.
Layer two starts with two chapters suitable for management as well. Chapter 4 talks about the value
proposition of DG and Chapter 5 presents an overview of the process to deploy the DG program.
The start of the second layer (Chapter 4) starts with a topic that merits its own chapter, and that is
the business case for DG. Very often clients will ask for assistance in developing a return on investment
(ROI) for a DG program. In most organizations, the largest obstacle to starting DG is the sellingdor
a business case. This chapter will cover tangible and intangible business drivers for DG. Frankly,
developing an ROI for a program like data governance is usually done to accommodate a lack of
understanding, political posturing, or plain old resistance to anything perceived as “new.” DG is not
a “project” that will grant a traditional return. DG does add value, and stating this as part of a business
case is about the best way there is to frame its value proposition. We will also leverage the chapter on
the business case to learn how to identify the metrics we will use to sustain the DG program.

KEY CONCEPT
As you read, you will occasionally come across a highlighted section (like this). These will be labeled “Key
Concept,” “Helpful Hint,” or “Success Factor.” They are there to reinforce the author’s point, either through
highlighting a point or by presenting an anecdote. For example, the reason that the business case for DG is not
traditional lies in its nature. Justifying DG with an ROI-type calculation is like asking your accounting department
or even your governing board of directors to justify its existence every year with a stated rate of return tied to a cash
flow. You are attempting to justify something in a way that is inconsistent with how it operates. Then again, there is
an appeal to the idea of a board of directors justifying itself with an ROI from time to time!

It is important to understand Chapter 5 and the context of the concepts from Chapter 2. If you want
to dive into the list of tasks to get you from point A to point B (Chapters 6–13) go right ahead, but you
will end up returning to Chapters 2 and 5 to figure out why you are being asked to do certain things at
certain times.
Chapters 6–13 review the details of each phase of the process we use to deploy data governance.
The activities, tasks, work products, and artifacts are reviewed. To the extent space permits, we present
examples and ideas for how to actually execute the activities. Please understand at this point that

3
Figure 1-1 presents a modified view of a common framework us information geeks use to keep track of where it is we are
working. It is called the Zachman framework (after the guy who thought it up) and many thanks to John for allowing us
to use it. It is an effective presentation to explain how an enterprise needs to link conceptual thinking to physical
implementation, which is why we included it.