This site uses cookies to enhance your browsing experience and deliver personalized content. By continuing to use this site, you consent to our use of cookies.
COOKIE POLICY
Enterprise data and technology leaders face a familiar dilemma: how much control should central data teams maintain versus empowering business units with federated access? It’s a debate that’s been heating up as organizations struggle to balance governance with agility, often swinging between extremes that create new problems. As someone who’s guided numerous enterprises through this exact challenge, I see clients wrestling with this issue on a regular basis. There is not one single answer that will work for all enterprises, so we’ve come up with an approach to find the right model for your organization.
Getting your data strategy wrong doesn’t just slow projects—it can stall entire business units. When centralized teams become bottlenecks, business leaders create workarounds that undermine data quality and governance. When federation runs wild, organizations lose consistency and face compliance risks that can be costly to fix later. Federation also creates extra costs in the shape of redundant data sets and overlapping data products that drain resources without adding value.
The tension between centralized data control and federated business autonomy isn’t new, but it’s reached a tipping point. It’s always been a little bit of a pendulum that swings back and forth. The notion of having a Chief Data Officer role led a lot of centralized tendencies because the executive wants to have the ability to control the outcome.
Centralization offers compelling advantages: consistency across the organization, strong governance for compliance requirements like GDPR and CCPA, and standardized definitions that prevent confusion. Centralization also helps manage costs as you get scale for buying and you don’t buy multiple versions of the same solution. Centralization can also help incubate and grow new capabilities for the organization. But it comes with a cost—speed.
On the flip side, federated models give business units the agility they crave. When you think about business outcomes and being able to use data at the speed of business and having the move from batch pipelines to real-time analytics, being able to make recommendation engines on websites, you want to have that closer to the business context. However, federation comes with cons including higher costs, potentially redundant data investments, and data user confusion across different systems and standards.
The real challenge isn’t technical—it’s organizational. When centralized teams lack business context, they build solutions that miss the mark. I’ve seen a client whose sales team needed a couple data points for some frontline decision-making. The centralized data team was trying to be thoughtful and anticipate other needs, but what ended up happening is it took a long time, and it developed a really large set of metrics—a dashboard with 30 metrics. It took longer than anybody wanted, and a lot of the metrics that they envisioned the sales team using never got used.
The result? The business team created Excel workarounds and never touched the dashboard.
Even technically skilled centralized data teams can create friction. The problem isn’t competence—it’s context. The emphasis is probably more on solving broad enterprise needs versus a specific business. Because they don’t necessarily sit as close to each business unit, they don’t have the conversations around the decisions that are being made every day.
This distance from daily business operations leads to several common pitfalls:
Solutions That Are Too BroadCentralized teams try to anticipate every possible need, creating complex dashboards or data products that overwhelm users. The result is often feature-rich but business-poor solutions.
Without regular exposure to how each business unit operates, central teams miss the nuances that make data actionable. They often don’t get the context of what matters most to each business unit, leading to technically sound but practically useless deliverables.
When central teams can’t deliver at business speed, departments find alternatives. You’ll have business units who have either analysts that become more technically savvy and learn how to source data and bring it into their own systems. They may buy their own systems. They may use a third party without going through the centralized team.
These workarounds signal a clear message: the central team isn’t meeting business needs, regardless of technical quality.
The solution isn’t choosing between centralization and federation—it’s identifying which services work better in each model. I think what organizations should start with is to think about the various data services and understanding how they get consumed, and why they get consumed. Being 100% centralized or 100% federated in a large organization is almost never the answer.
We use service blueprinting to identify the right approach to data services and use that to create an overall operational data plan. Service blueprinting is a long-established best practice that takes a service or user journey, front stage and back stage actions along with the systems and applications supporting them. It becomes a great reference for conversation across tech and business teams.
This service blueprint approach helps organizations map out:
In a balanced model, central data teams focus on services that create enterprise-wide leverage without requiring deep business context. This guidance will depend on the organization’s culture and industry, but this is a good general reference to start from.
The things that the centralized team should do are those things that are a little bit further removed from things that require business context. This means stepping back from:
Successful data governance isn’t about control—it’s about enabling informed decisions. The first step has been defining the ownership model. I’ve always firmly believed that the value of the data comes in its use more so than its creation.
This ownership model requires clear definition of roles:
The key is creating processes that help business owners understand the impact of data quality issues and make informed trade-offs. You’re never going to have enough money to fix every single data issue, and you’re going to need to triage those that are important and those you can live with.
Traditional self-service approaches often fail because they try to anticipate every question with massive dashboards. You end up making these really large, often complex dashboards that are so broad that users have a hard time with them and they may or may not actually trust and use the data.
The future lies in more conversational approaches: Instead of really large data sets with large dashboards and tons of reports, they’re going to move into more of a generative BI sort of space where we’re putting together processes and tools that allow business users to have a conversation with data without having to navigate a tool or write SQL.
For non-technical business leaders making demands of their data organization, here’s clear advice:
For organizations caught between too much centralization and too much chaos, the path forward starts with high-priority use cases. I would think about trying to find some of those high-priority use cases for data that are either too slow because you’ve centralized them, or too hard to interpret because you’ve federated them.
The goal isn’t perfect centralization or complete federation—it’s finding the right balance for each service within your data ecosystem. This requires ongoing evaluation and adjustment as business needs evolve.
The centralization versus federation debate isn’t really about choosing sides—it’s about creating flexible data strategies that can adapt to different business needs. Organizations that succeed focus on:
If you do it well, data always creates value. I’ve never seen a place where you can’t create value.
At UDig, we’ve helped numerous organizations navigate these complex data strategy decisions through our comprehensive data strategy framework and strategic planning approaches. If your organization is struggling to find the right balance between centralized control and federated agility, we’d love to help you create a service blueprint that drives real business impact.
Ready to turn your data strategy ideas into measurable impact? Let’s start the conversation.
Reid, Executive Vice President, Consulting Practices at UDig, is a long-time data professional with experience at multiple Fortune 500 companies. Most recently, he was the Chief Data and Analytics Officer at Markel. Prior to that he held multiple roles at Capital One including VP of Data Engineering.
