There is no single “right” way to organize Data Governance and Stewardship. Some organizations have distinct Data Governance programs. Others embed Data Governance activities into Data Quality or Master Data Management programs. Still others adopt formal Data Governance as a service offered by evolving Enterprise Data Management (EDM) or Enterprise Information Management (EIM) programs. In these cases, best practice says that it important to carry out key governance activities, regardless of how you’ve labeled them.
Likewise, while program structures generally vary from organization to organization, they all tend to follow a generic pattern.
Most organizations have one or more virtual teams operating at strategic and/or operational/tactical levels.
A Data Governance Council (or Committee) makes high-level decisions. This is a cross-functional group, with representatives from business and technical data stakeholder functional groups. In some organizations, this group may be labeled a Data Stewardship Council. Members may be called Data Governors, Lead Data Stewards, Executive Stewards, or Council Members.
Unless the organization is very small, it will probably also have one or more tactical teams involved in daily, data-related decisions about how best to turn policy into practice. These may be labeled Data Stewardship Committees, Working Groups, Data Teams, or some variation.
These tactical teams tend to provide guidance to individuals with stewardship responsibilities who may be scattered across the organization, performing specific data-related tasks. Those individuals may or may not be labeled Data Stewards. Technical contributors may be called Technical Data Stewards, Data Custodians, or Subject Matter Experts (SMEs).
A Data Governance Office (DGO), or a Data Governance support team, supports all these groups. This group is charged with facilitating and coordinating data governance and stewardship activities. Typically this group manages communications from councils to data stakeholders. Not all programs have formal DGOs, but all successful programs have designated roles to support councils and to facilitate efforts.
A data stakeholder is any individual or group that could affect or be affected by the data under discussion. Who are they? Some stakeholders are obvious: business groups, IT teams, data architects, and DBAs. Other stakeholders may not be so obvious: representatives from compliance, security, privacy, content/document management, taxonomy design, Web/intranet design, and others.
Organizational Charts
Creating charts to describe Data Governance organizations can be tricky. The wrong graphic can imply “power relationships” that are not useful in cross-functional groups that come together to forge compromises. I know of one organization that had to create over a dozen organization graphics before they had one that no major stakeholder objected to. (They ended up depicting “round tables” in lieu of anything that looked like an org chart.)
Another compliance-driven organization I know was moving power into a DGO, although they would still have a cross-functional team. In their drawing these two groups were shown next to each other, with neither team “higher” on the diagram.
Another group put the DGO in the center of the diagram, showing that it was supporting every other Data Governance function, while still another one had it hanging off a line between an Executive Sponsor and a Stewardship Committee.
As you design your program, think carefully about how many groups you need and who should be in them. Too small, and you’ll have stakeholders who feel they are not represented. Too large, and your group may be unwieldy and unable to come to decisions quickly. Consider whether the concept of Working Groups (subset of a larger council) is right for you.
Be prepared to answer the following questions:
- Which stakeholders should be part of a Data Governance Council?
- What type of commitment is required of them?
- What will they be expected to do in their meetings? Between meetings? What support will they get, and from whom?
Your answers, of course, will depend on the focus of your program. A program that focuses on privacy/compliance/security may have a different council makeup from one that exists to support data warehouses and Business Intelligence (BI). Likewise, a program concentrating on architecture or integration may involve different participants than one whose goals involve data quality.
Don’t accept a “cookie-cutter” program definition. Think hard about what you’re trying to accomplish, and staff your efforts appropriately. And remember, if you’re successful, you can always add more participants later. But if you call a meeting and force people to come to it, then confess that you don’t have much for them to do, you may have wasted your chance to introduce Data Governance to your organization.
