Operating Model

Choose centralized or federated governance and define the responsibilities of central and domain teams so every governance activity has clear ownership.

The operating model establishes what is managed centrally and what belongs to domain teams. GUNs offers Centralized and Federated modes, applying that division of responsibility to standards, project work and dataset operations.

Choose a governance mode

AreaCentralizedFederated
Governance organizationManaged by central teamsShared between central and domain teams
Business objects and standardsEnterprise-wide maintenanceEnterprise and domain definitions coexist; common definitions stay central and domain teams maintain their own
ProjectsOrganized and executed at enterprise scopeAssigned to responsibility domains, with central governance across domains
DatasetsOperated at enterprise scopeOperated by responsible domain teams, with central maintenance across domains
Classification and masking rulesCentrally managedCentrally managed

Centralized mode suits enterprises organizing governance through a central function. Federated mode suits organizations with clear responsibility boundaries and teams able to govern their domains continuously. Both use the same architecture, standards and governance tools.

Describe business capabilities

The business capability tree describes what the enterprise does, such as Supply Chain → Supplier Management or Marketing and Sales → Customer Management. Breaking capabilities down gives teams a common language for information needs and governance priorities.

Capabilities can be linked to responsibility domains and business objects to show which data supports a business activity and who is responsible. Capability classification itself does not change user permissions.

Establish responsibility domains

In Federated mode, a responsibility domain defines a stable area of accountability, such as Supply Chain Data or Customer Data. Domain standards, business objects, projects and datasets are organized around that boundary.

Domains are peer responsibility boundaries. One team can operate several domains, and several teams can operate one domain. Operating relationships can change while preserving governance outputs and change history.

Responsibility domains answer “who is accountable”; subject domains answer “what the information is.” A supply chain responsibility domain can cover supplier, material and purchase-order information across several subjects.

Assign operating teams

Formal departments and cross-functional teams can both carry governance responsibilities, with people participating through positions or organizational roles.

TeamMain responsibilities
Central governance teamMaintain common definitions, security rules and governance structures, and coordinate cross-domain issues
Domain teamMaintain domain objects and standards, collect and annotate metadata, and operate datasets

Users work through their selected identity. People participating in several teams can switch identities to see and handle the appropriate work. Function permissions and team responsibilities together determine available actions.

Review responsibility coverage

Coverage views connect business capabilities to responsibility domains, helping teams identify:

  • Capabilities without a clear data responsibility assignment;
  • Domains whose coverage is too broad and needs review;
  • Business areas supported by several domains that need to collaborate.

Control lists also show which governed objects and activities central and domain teams can maintain, and where they can work.

Change the operating model

As the organization and its governance capabilities evolve, it can initiate a profile switch. Impact checks list required actions, warnings and adjustments that will accompany the switch.

Start a switch → review impact → resolve items requiring attention → confirm

Moving from Federated to Centralized involves bringing domain definitions together and adjusting project ownership. Moving to Federated involves establishing domains, assigning teams and allocating projects. Users review adjustments before confirming or abandon an in-progress switch.

Switch records and object change histories make the evolution of governance responsibilities traceable.