Page 152 -

Overview 131

a geographically dispersed company with a diverse and eclectic blend of applications, any kind of
federation on a central basis is going to be an architectural challenge.
• Enterprise architecturedThis factor is difficult, because it cannot be changed very easily, if at all.
This is because the symptoms of an eclectic application portfolio and inconsistent and unplanned
enterprise architecture produce the same challenges that create the need for DG. There is an entire
other book to be written on the role of enterprise architecture and information asset management.
So, briefly, enterprise architecture (the blend of all of the elements of People, Process, and
Technology), or EA, can really influence federation. An organization with no formal approach to
managing the blend of People, Process, and Technology will need to be almost militant in
defining some sort of central data governance. This is because the DG program, for right or
wrong, will be taking up the slack due to poor technology governance. An organization with
a decent or robust approach to EA can leverage the dickens out of its IT and technology
governance and define very clear lines of federation.
• CulturedThe cultural factor can be divided into two subtopics, maturity (we called it IMM, or
information management maturity) and capacity to change.
B IMMdIf an organization is not mature in terms of its understanding of information usage or
the handling of its information assets, then federation should lean to more rigor or
centralization. Of course, the immaturity will have resulted in a lot of informal information
assets scattered about.
B CapacitytochangedDG means change. Many types of organizations are unaccustomed to or in
denial of the need for change. Older cultures or closely held companies typically have a lower
capacity to change, while younger organizations may be more amenable (but not necessarily).
All of these factors must be blended to determine the type of federation required to carry the DG
processes forward.
Federation, then, needs to be combined with the various layers of governance that will evolve from
an analysis of the RACI chart. For example, if we determine that customer data needs to be governed
centrally, but the applications that use customer data are scattered about the globe, the accountable and
responsible parties will need to be identified with some consideration of the distribution of authority.
Therefore, there will need to be a centralized flavor of customer DG as well as a distributed flavor, and
a collaborative set of processes will be required to facilitate DG for the customer subject area.
Of course, the framework to manage the various striations of governance will need to consider the
federation and layers of DG. Remember, the organization is a framework, not an independent orga-
nization chart, so you are weaving DG within the existing organization chart.
The blend of federation and layers of DG oversight produce the representation of the organization and
federation, usually in the form of a hierarchy or network (see Figure 11-8 in the output samples below).
While assigning bodies to positions occurs in detail in the next activity, it is organizational in nature
to start to think of names. At this point, a list of names is okay, but make sure you focus on the talents
and skills required to convert or enhance individual roles.
Names to actually list (and contact) would be the leadership of the ongoing DG framework. They
may be your current executive sponsors or DG team leaders. If not, then there will need to be some
initial socialization of the DG framework and vision for these folks.
Lastly, and probably most overlooked, is the need to draft succinct charters for the various layers of
the DG governing framework. An outline of a typical charter is in the appendices.