Page 73 -

52 CHAPTER 5 Process overview for deploying data governance

Also, make sure that the functional model is complete. Reexamine where the list of IM functions
and DG functions could intersect. You may discover the need for some coordination that was not
obvious earlier.
The most critical concept to consider at this point is the degree of federation. Simply put, some
areas or subjects will require more intense governance than others will. We introduced federation in
Chapter 3, but to review, the term “federation” is used to describe the level of penetration of DG into
various areas within the organization. A typical example for federation of DG appears in the MDM
solution area. Assuming that [a?] customer is the subject, we might find in one organization that only
a small portion of the content describing a customer needs to be governed. In another organization,
you may find that all of the information used around a customer needs to be closely governed. Refer
again to Figure 3-2 as a generic example of how we would indicate the type of governance across
multiple subjects in a large company. If you do not consider the extent of federation, it will be
impossible to design an effective framework. Many organizations strive (naively) for a totally
centralized oversight for data (no federation). Others believe they can develop a framework that is
totally virtual (totally federated and very hard to sustain). Ideally, there is a middle ground that
reflects reality.

Activities

1. Design DG organization frameworkdThis series of tasks determines where and what levels will
execute, manage, and be accountable for managing information assets. Sometimes forward-
looking organizations appoint a DG committee (that eventually supplies stewards and owners)
to work with the DG team to design the organization framework. Either way, this activity means
an old-fashioned RACI exercise, a definition of the degree of federation, and an identification of
the leadership layers for DG. Finally, organization charters will need drafting so that soon-to-
be-appointed stewards and owners will have reference material for rolling out DG.
2. Complete roles and responsibility identificationdOnce the RACI is done, the DG team (or
committee) will be able to start placing names with roles. Depending on the organization, this
may be much harder than just names in boxes on a chart. There are several potential obstacles
to the timely completion of this activity:
• Perceived political threats from some getting “power” over data.
• Human capital (or HR) concerns on changing job descriptions.
• Fear that adding additional responsibilities will damage current productivity.

One thing to reinforce at this point is you are not creating a new job description or position. Our good
friend and practitioner, David Plotkin, put it this way: “Data stewardship is not a job. It is the
i
formalization of data responsibilities that are likely in place in an informal way.” The DG team should
coordinate with HR to identify potential revisions in performance goals for the new roles. Finally, the
DG team will suggest the makeup of the DG oversight bodies or committees. These oversight bodies
take on different names. Figure 5-4 shows an example of the various names and layers. Note the
example uses the V structure, not a pyramid. This representation clearly shows not only layers, but also
where communication needs to occur.

i
David Plotkin, extract from “Presentation to Enterprise Data World, 2010.”