[bok-callout]The organisational structure of your company reflects its continuous aim for financial performance, product quality, or operational excellence. Naturally, this structure is in constant flux influenced by changing goals or external factors.

While this structure works to achieve business goals, a different structure might be required to achieve data governance goals. The initial set-up of you data governance organization may reflect your actual company structure. Yet, the data governance organisation usually leads its own lifecycle and eventually put light on how the business should be reorganised.[/bok-callout]

During the start phase, a common approach is to define your enterprise data governance structure the same way your company is organized, that is one community per business function or business unit. Consider the following diagram for Global Value Creative Inc. that follows this approach.

The data governance organization is set up as follows.

1. One Central Data Governance Council (DGC)l that consists of an executive part and an advising part. The DGC is responsible for the onboarding of new requests and the timely resolution of issues. They may also own a set of corporate-level domains such as a company glossary or non-influenceable standards such as country and language codes from ISO.
2. One or more communities that operate on a project-basis over a limited period of time and in which stewardship is a combined set of skills that is appropriate to solve a particular data issue. They govern their own code-lists, glossaries, policies and rules domains, etc. Example: working group on rules and policies.
3. On or more communities that are established over longer periods of time, group specific skill sets and form part of the organizational structure. They govern their own asset domains as they need them. They could be organized according to:
   1. business units/function/capacity: marketing, sales, finance, enterprise architecture;
   2. business process: design, implementation, planning, commercialization.

We discuss a number of features this structural choice bears with it.

Central Data Governance Council

The setup starts from a central Data Governance Council community (already out-of-the-box) that owns a number of domains for temporarily storing new requests made on the dashboard. E.g., the “New Business Terms” domain is a glossary containing all candidate business terms that have been proposed via the dashboard “propose new business term” button.

The data governance council is responsible for reviewing the requests, and assigning the relevant ones to those (business function / business unit) communities  that are considered to be the owner. Irrelevant requests may be archived (by setting status to “Rejected”) or deleted.

Business Unit/Function Autonomy

Once assigned a request by the DGC, every community has its own level of autonomy to govern them. This means that once they accepted the owndership, they are responsible to define, approve and publish a highly quality asset in a reasonable time. For that reason it is important that every community has a managing user. This is usually a user or user group that is assigned the role of  “Admin”. Some would call this role “Chief Steward” or “Community Steward”. In any case, the user with role of “Admin” has all edit permissions in the community (see Managing roles and permissions).

Within one such community, the Admin will establish autonomously a number of domains for the assets he has to report on. This could even include sub-communities to create additional structure. For example, the Finance community in this example has such a broad field of metadata authority that its Admin has decided to subdivided to the domains in coordinating sub-communities. E.g., “Customer Subject Area” is a community that comprises of a number of business asset domains and a glossary. The “External Reference Data” is a community that owns the ISIC Revision Codelists.

Once the “Admin” Resource Role has been assigned for very subcommunity, these respective Admin-role holding users can then assign Resource Roles to their crew of members. Out of the box, we have foreseen three traditional Resource Roles (see Managing roles and responsibilities in the user guide): Steward (who authors  and holds accountability for the approval of an asset), Subject Matter Expert (who is consulted to review and author an asset at certain points in time), and the Stakeholder who by default has no editing permissions. We refer to Role Types for more explanation on these Resource Roles.

Homonyms and Synonyms

This type of organization supports the need to agree on certain assets within the different departments. Consider, for example, the business term with the name “Customer” thrives in both the Sales Commmunity as wel as in the Finance Community. They are homonyms – hence given different meanings.

The definition of Customer in the Finance Community

In the Customer Domain glossary  (within the “Customer Subject Area” sub-community within the “Finance” Community), the Business Term “Customer” is defined in terms of the total number of products bought in total. It is highly matured (with 65% of completion score and a status “Approved”.

Moreover, looking at the relations “represented by” and “system of record”, it has an established traceability down to the Data Asset and Technology Asset levels. this is shown in detail when opening the traceability diagram (for the functionality see the user guide’s section on Traceability). The diagram further reveals Business Rules such as “Customer can only be male of female” and “Customer should be at least 16 years of age” that govern the Business Term, demonstrating even more this maturity of traceability.

The definition of Customer in the Sales community

The business term “Customer in the sales community, however, shows a much lower level of maturity. Despite the 65% of completion, there is hardly traceability. The definition is based on the frequency of buying products, as opposed to the quantity.

Promoting Assets to a Higher Community Level

After an initial cycles of governance,  it may turn out that some assets are shared across communities. In this case they can be promoted to the enterprise level. This can be done by introducing domains that are owned by the top-level community. For example, consider the ISO Country Codes. This may have been initially governed by a “Working Group on Reference Data” community. At a certain point the Data Governance Council may decide to promote mature parts of these lists to the enterprise level, as shown below. The structure shows the preparation stage: a brand new Codelist domain “ISO Country Codelist has ben introduced (on top-level) as a placeholder to promote some of the Codes in the 2013 ISO 3166-1-* Codelists (on the working group level).

The physical move of the assets from the three domains starting with “2013 ISO 3166 *” within  the Community “Working Group on Reference Data” is straightforward. This is explained in the users’ guide. Note your permission to move domains or assets depends on the resource role assigned to your user account. You can move a whole domain to another community by clicking “Edit” in the top menu. You can also select assets in a domain and move them together to another domain using the “rapid edit” function.