Data governance operating model: centralized, federated or hybrid

A data governance operating model is the way a company organizes who decides, who executes and who oversees the rules for its master data. It is not software. It is not a job title. It is the structure that defines whether governance becomes routine or becomes a nice policy kept in a folder nobody opens.

I implemented SAP at large companies for almost two decades and watched the same mistake repeat: the company buys the right tool, writes the right policy, sets up the right committee, and still the master data is dirty six months later. What is missing is deciding who rules the data when purchasing disagrees with the tax department about how to classify a material.

There are three operating models for data governance: centralized, federated and hybrid. Each one solves a problem and creates another. I will explain all three the way they show up in a company's real life, not the way they show up on a consulting slide.

What a data governance operating model is

It is the design that answers three questions. Who owns the master data rule. Who approves a change to that rule. And who resolves the conflict when two areas want to record the same data in different ways.

Without that answer, the governance policy becomes a dead letter. I have seen a company with a thirty-page document on quality dimensions, roles and responsibilities, and not one line saying who decides when the automatic record creation pulls a supplier's wrong registration status from the Receita Federal (Brazil's federal tax authority). The operating model solves that on a Tuesday morning, not at the quarterly committee meeting.

Centralized model: one area rules everything

In the centralized model there is a single master data team, usually inside IT or corporate governance, that creates, approves and maintains the rule for the whole company. Purchasing does not create suppliers. Sales does not create customers. Everything goes through the hub.

The advantage is consistency: a single material classification criterion, a single supplier name standard, a single quality standard. It works well in a midsize company, with few units and a single ERP, because the hub keeps up with the volume without becoming a bottleneck.

The problem shows up at scale. In a company with several units, each with its own way of buying and selling, the hub becomes a queue. The plant in the countryside waits three days to create an urgent material because the central team is overloaded with requests from four other units. The business feels governance as a brake, not as protection, and the shortcut appears: the area records things on the side, in a parallel spreadsheet, and the hub loses the control it had.

Federated model: each area looks after its own data

In the federated model, central governance defines the standard, the taxonomy and the quality rule, but whoever creates and maintains the data day to day is the business area itself. Purchasing has its supplier data steward, sales has the customer one, engineering has the technical material one.

The advantage is speed and domain knowledge. Someone who understands a stainless steel hex bolt classifies a technical item better than a generic master data analyst at the hub, and the volume is distributed across teams, reducing the queue.

The risk is fragmentation. Without central governance strong enough to impose the standard, each area creates its own taxonomy and the company goes back to having the same material recorded three times, each time with a different criterion. I saw this on an S/4HANA migration project, where each plant had developed its own way of describing materials over the years, and at migration time the data load became so slow and full of inconsistencies that it nearly compromised the go-live. The federated model only works with a strong central policy owner and indicators that show when an area is drifting from the standard.

Hybrid model: what most large companies end up using

The hybrid combines the two. There is a central governance that defines taxonomy, quality rule, policy and indicators, and there are data stewards distributed across the areas, who carry out record creation within that rule and answer for the quality of the data in their domain.

The hub does not create records, but it audits, defines the approval flow and steps in when the quality indicator drops. It is the model that the master data workflow materializes in practice: the request is born in the area, goes through the centrally defined rules, and only becomes approved master data after being validated.

The hybrid demands more maturity. It needs a clear responsibility matrix, of the RACI type, saying where the area's autonomy ends and where central governance's final word begins. Without that line drawn, the hybrid becomes the worst of both worlds: slow like the centralized model on exceptions and fragmented like the federated one day to day.

Who takes part in this model

The Chief Data Officer defines the policy and arbitrates the operating model. The data owner, normally a business manager, answers for decisions about the data domain, such as supplier or material. The data steward executes, creates records, corrects and maintains quality day to day. The data committee resolves the conflicts the operating model did not resolve on its own, such as the disagreement between purchasing and tax about the classification of an item.

IT comes in as the platform provider, but in none of the three models should it own the business rule for master data. I have seen a company outsource the material classification decision to the systems team simply because they were the ones touching the ERP. The result was master data that was technically correct and operationally useless.

Which tools support each model

MDM platforms such as SAP MDG, Informatica MDM, Stibo Systems, Reltio, Semarchy and Profisee automate the approval workflow and record who did what, regardless of the model chosen. They are what make the hybrid operable at scale, because the system applies the control that the manual process cannot sustain on its own. Catalog tools such as Collibra, Alation and Microsoft Purview give the hub visibility into what each area does with the data, even in the federated model, and solutions like Ataccama and Informatica Data Quality do the profiling that feeds the indicator the committee will demand later.

No tool solves a poorly designed operating model. I know a company that bought the most expensive platform on the market and kept the same lack of defined roles it had in the spreadsheet. Software automates the decision, it does not replace the decision.

How to learn to design this model

The path goes through understanding first the fundamentals of data governance and the difference between master data and transactional data, before getting into organizational architecture. The DAMA-DMBOK organizes that knowledge, and the CDMP certification is the market recognition for those who already master the subject. A course that brings real cases from purchasing, SAP, supplier and material master data is worth more than pure framework theory, as I cover in the book Master Data Management: Fundamentos e Aplicações (book in Portuguese), published by Editora Brasport.

Career opportunities in this area

Designing and operating a data governance model is one of the most sought-after fronts within MDM, because it requires both technical data knowledge and an understanding of business process. Data steward, data owner, governance analyst and, at the top, Chief Data Officer are positions that grow as the company matures from an overloaded hub to a well-designed hybrid. A professional who speaks the language of IT and the language of the business at the same time, without blocking the business with unnecessary bureaucracy, is rare and well paid.

Main questions about the data governance operating model

Which data governance operating model is the best? There is no best one in the abstract. A small company, with a single ERP and few units, tends to work well with the centralized model. A large company, a multinational with several business units, usually needs the hybrid.

Can you move from centralized to hybrid without restructuring everything? You can, and it is the most common path. You start by defining the RACI matrix for the most critical domains, such as supplier and material, and then expand the federated data steward model domain by domain.

Does the federated model work without an MDM platform? For a while, but without a tool that applies the rule automatically, fragmentation arrives quickly, because the federated model without automation depends on the individual discipline of each area, and individual discipline does not scale.

How do you measure whether the operating model is working? Through governance indicators: average approval time for record creation, duplication rate, percentage of complete data and the number of exceptions the committee had to resolve outside the normal flow. If the indicators do not exist, the model does not really exist either, it only exists on paper.

MDM Academy: where to learn to structure data governance in practice

MDM Academy is 4MDG's school of master data governance, created to train the professional the Brazilian market still produces too little of: someone who understands master data, business process and technology at the same time, with courses that deal with that bridge between the operating model on paper and the model working inside a real SAP, Oracle or TOTVS.

Those who want to advance in a governance career, become a data steward, data owner or one day lead the company's data area will find in MDM Academy the structured path that much of the market lacks. I also recommend Data Club, our community of master data and governance professionals, where these discussions happen in practice.

Conclusion

The data governance operating model is not the prettiest chapter of the data policy, but it is what decides whether the policy leaves the paper. A committee without an operating model becomes a meeting. A policy without an operating model becomes a file. A platform without an operating model becomes an expense.

Before buying the next tool or writing the next policy, it is worth asking the simplest question of all: at your company, when two areas disagree about how to record the same data, who decides?