Page 151 -

130 CHAPTER 11 Governing framework design

Approach Considerations

Given the potential for the DG team getting its first real dose of resistance (usually in the form of the
organization expressing concern that this is the correct thing to do), this should not be a set of linear
tasks that are executed without external contributions. Every output from this activity requires
continuous vetting with potential stakeholders. Every step requires sensitivity to culture and politics.
This does not mean the DG team dumbs down what governance is supposed to accomplish. It means to
be resolute and navigate through the first set of real barriers.
The functional design from the Functional Design phase is used as input to develop a RACI chart.
This means scrutinizing all activities described as necessary to perform DG and IM. The DG team will
need to take the initial cut at the DG framework and make them the columns in the RACI chart work
product. Therewill be multiple passes at this work product and much debate. Most likely, therewill be an
issueortwo arisingfrom thisprocessthatwill require steeringcommittee or executive-level intervention.
OneofthekeydesignaspectsthatwillusetheresultsoftheRACIistheidentificationofthestyleornature
of federation. Remember, the concept of federation (in the context of data governance) means how we blend
andstratifythevariousgovernanceentitiesorfunctionsacrosstheorganization.Itisarefinementofwherethe
DG elements touch the organization, how standards will be applied across various layers and segments of an
organization, and what layers of governance are required (i.e., local, regional, global, enterprise, or others).
For example, if accountability for a subject area is hard to nail down, then most likely it is used in
a context that will require some sort of multilayered oversight. The main factors for how federation is
established are:
• Enterprise sizedIf there are differences in brands, operating divisions, or business operating
models that will require differing styles and intensities of DG, then some type of federation
needs to be defined.
• GeographydIs your enterprise spread across different countries? If so, then you are almost
guaranteed varying types of governance based on differences in customs and regulations.
• Organization styledAn organization that is accustomed to rigid central control will tend to adapt
easily to DG, if its leadership is engaged in the DG process. Decentralized organizations will require
very specific definitions of what is centrally controlled and what is distributed.
• Regulatory environmentdObviously, an organization that is highly regulated will embrace the
central control of assets more readily than one that is not.
• IT portfolio conditiondThis factor can work both ways. An older application portfolio can create
a desire to build anew and accept new conditions of governance. This is most common when
a company implements SAP, which brings a set of constraints that are mostly based around
success factors. Modifying functionality in SAP is not a good ideadyou accept it “vanilla.”
Sustaining the advantages of SAP integration after you “go live” also requires ongoing data
governance. The configurability of SAP can allow users to run amok. It is not uncommon to find
2
SAP master files as badly managed as the legacy files they replaced. Conversely, a beloved
embedded (or tolerated) legacy application can be a barrier. It can be considered either
ungovernable or immune from any perception of disruption. Lastly, if you combine
2
The author got into trouble years ago after writing an article describing SAP software as “instant legacydjust add money.”
SAP took great offense to this, but they missed the meaning. If you treat the SAP application data the same as you treated
your old systems data, you get the same result: junk data. At an average cost of $35 million per project (author’s data), that
makes for very disappointed CEOs.