Page 44 -

The Scope of Data Governance 23

same as implemented. We always implement it gradually, but the vision is enterprise-wide.
Company B is a large company as well, but has several very distinct business units. They do not
share common information, so in this case data governance can be implemented or applied by
business unit.
The detailed aspect of the business model is also an area to consider when scoping DG. DG will
often require a change in business processes. A typical example is when master data management
(MDM) is implemented. It is often the case that the operators entering data into many applications
have also maintained the data area in question. Going from many-item master files to one is a typical
example of where day-to-day business processes need to change. The scope of DG needs to make clear
mention of this possibility.
In addition to the DG scope being dependent on the business model, it can also be dependent on
type of content.

Content

Earlier we established that this book does not make a distinction between data governance and
information governance. They are philosophical and semantic distinctions that cause considerable
confusion, and are not relevant to this discussion. We also do not govern different types of content
differently. At the end of the day, the activity to govern business intelligence data, operational data,
e-mails, contracts, documents, or even media, is driven by the same reasons and entails the same
activities.
While we do not distinguish how differing content is governed, we do need to be clear within
a specific organization what types of content are subject to DG. Certainly, master data, BI data, and
other forms of structured data are most likely governed. However, a highly regulated company may
also need to govern e-mails and contracts.
A company where safety is a major issue may need to place its governance focus on guidelines and
procedures. A government body may need to zero in on governing access to public documents while
protecting individual privacy.
The types of content subject to DG will heavily impact where the DG program resides, who holds
accountability, and how the organization deploys the DG program. It will also influence the types of
tools and policies that the DG organization has to define.
Content types are also important because, while DG programs contain the same elements
regardless of the content being governed, very often the types of content will influence the detailed
governance processes. Differing content types will have unique life cycles. For example, content that is
a structured type of data, like a transaction, may come and go within a fiscal year, and governance will
tend to focus on the usage of that data within the time period. An unstructured type of data, like
contracts and e-mails, may need to be kept for decades and may be subject to legal discovery or strict
classifications of privacy or privilege. Obviously, there will need to be consideration of the details of
governing these different types.
The development and maintenance of applications and systems should be accounted for in the type
of governance as well. Many of our clients have a defined development process, or systems devel-
opment life cycle (SDLC) for defining and deploying automated systems. Few of them have built any
type of consideration for designing around DG policies and standards. Very often, we end up writing
enhancements to corporate IT department SDLC methodologies when structured information is being