A Federal Model for Data Governance (part 3)
- Huntington Beach, CA, July 2025This is the third article in a four-part series on my federal model for data governance. Find the beginning of the series here.
Before I explain my approach to governing data, I’ll try to help you overcome the temptation to think of it as a technical solution. IT people struggle with this. My analogy to the U.S. Interstate Highway System can help.
You can’t just build a system of highways and expect everyone to cooperate as they use them. A dictatorship might force everyone to comply, but it won’t help people buy into the solution. On the other hand, anarchy gives everyone freedom to make their own decisions, but it doesn’t help everyone move in the same direction.
That’s why my federal model is better. It balances the benefits of centrally managed data with the freedom analysts and decision-makers need to explore that data. Although working together requires a lot more planning and effort, it results in great solutions that everyone can share.
Who Owns What?
Clear definitions of people’s roles and responsibilities help them work together. Your centralized data team should own four key services:
Enforcing the system of record. Your central data team should guarantee that you have consistent information about customers, products, vendors, employees (and more) across all business systems and reports. Exception reports play a key role in this approach. The central team also provides data dictionaries as a quick reference to help business teams identify the sources of the data they see in reports.
- Financial reporting. Your central data team should link all business activities to financial statements. All activity results in some financial posting, and that creates a standard measurement that all business teams can use. However, while linking financial data like this speeds up profitability decisions, it also makes the data more sensitive. That’s why centralizing this feature makes sense.
- Scaled security. An effective data security solution applies the same rules to all data. Only a centralized team can do that. More importantly, without clean, well-organized data in the first place, even the best security solution will grant too much or too little access.
- Process modeling. Most business processes, such as demand planning, involve multiple teams, like manufacturing, customer service, and product design. Your central data team should create 360-degree views of key business processes.
Functional business teams (like manufacturing or customer service) should manage most other data work, but it’s helpful to clearly communicate that they own these two key areas:
- Master data. Business teams maintain master data as part of their standard processes, like onboarding new customers. They also link data to decisions by associating customers with their parent customer or sales region, for example. Your central data team should never override business owners' decisions about master data.
- Real-time reporting. People involved in operating a business process (like filling orders) need to see the data in the system right now, including transactions made in the last few seconds. Delivering data like this requires completely different technical and data management solutions than those used for business analytics. Operational teams are much better prepared to manage this than a centralized data team.
Even though my data governance model won’t magically result in people working together, it does help create a culture of sharing. That won’t happen automatically, and that’s the point of this governance framework: to help you foster an environment where the people and departments share the solution.