Clients ask me this question perhaps more than any other. They’ve usually just come off a bad experience, either analytics stuck in IT’s backlog for months or analytics scattered across the business without anyone accountable for what it all means. My answer is always the same. Split it. IT owns the data engineering. The business owns the analytics. And you need one small team sitting between them to keep the whole thing from drifting apart.
That’s not a compromise position I land on to avoid picking a side. I’ve witnessed companies that went all in on one extreme or the other, and they end up in the same place. They have expensive dashboards sitting untouched and analysts who stopped trusting the numbers years ago. Give me twenty minutes with a client and I can usually tell which extreme they started from, just by looking at what’s broken.
Full centralization and full decentralization both fail the same way
When IT owns everything, security and governance are usually solid. You need people who actually understand networking and access control managing any connection to raw data coming out of your ERPs, TMS and CRM systems, not analysts who picked up security practices on the side.
But speed dies. Business analysts wait on intake forms and requirements documents that assume you can specify a dashboard’s full scope before you’ve ever seen the data move. Analytics doesn’t work that way. It’s one of those areas where you need multiple iterations to land on the right end state. You learn what you need by building something rough, using it for two weeks and rebuilding half of it. A team that has to file a ticket for every iteration will never keep pace with a business that changes its questions weekly. People who sit close to the business need the freedom to iterate as the tools mature, and that freedom disappears the moment every change has to clear an IT queue.
Flip it and hand analytics entirely to the business, and you get the opposite failure. I worked with a company this year that let every department build its own reports with no shared standards or governing body. Marketing had one set of definitions for a “customer.” Sales had another. Finance had a third, and every meeting turned into an argument about whose number was right. Total spend wasn’t being tracked either. As you can imagine, by the time they called me, their cloud analytics costs on Microsoft Fabric had already climbed past $20,000 a month, and the team couldn’t point to where it was going. They fixed it by building a small internal group, essentially a center of excellence, that owned the standards everyone else built on top of. CIO contributor Ranko Cosic’s April 2026 piece, “How analytics and AI are reshaping the boundaries of IT leadership,” draws a similar line, arguing that IT leadership builds the capability to analyze while analytics leadership builds the capability to decide. I’d add a third piece. Someone has to own the handoff between those two, or you get exactly the sprawl I saw at that client.
There are numbers behind this. In a survey of more than 2,400 CIOs, Gartner found that companies where IT and business leaders co-own delivery, what Gartner calls the “franchise” model, hit or beat their targets on 63% of digital initiatives. Companies where IT keeps sole ownership hit that mark on just 43% of initiatives. Only 12% of CIOs run a true franchise model today. That’s the whole argument in one number.
Adoption breaks when builders and users are different people
A few years ago, I got called into a large manufacturing company that had spent three years and an entire IT department building a dashboard platform meant for the whole organization. When I looked at usage, six people were opening those dashboards regularly. Six, out of thousands of employees. The tools worked fine technically. What broke was trust, and it’s a classic mistake. Trust and adoption begin when end users are part of the design process, or better yet, when they’re the ones building the tools.
That number stung, but it isn’t unusual. A BARC and Eckerson Group survey of 214 data and analytics leaders found average active adoption of BI tools sitting around 25%, a figure that had barely moved in seven years of tracking. Those companies bought good tools, but the adoption model wasn’t built to match. They skipped giving the people who’d use those reports a role in building them. Adoption climbs when the people using a report have a hand in shaping it, or better yet, built it themselves. That manufacturing client shifted from a fully centralized build to a decentralized one, with IT still owning the underlying data and business teams, together with us as consultants, owning what got built on top of it. They now have roughly 80% of employees using the tools weekly, on the same data, at the same company, with nothing changed but who owned the build.
I bring this up with every client who tells me they want “one IT team” running analytics end to end. A single team can own the pipeline. It can’t own every department’s judgment about what a useful report looks like, and trying to force that usually produces the same six-user outcome I saw at that manufacturer.
Standardization is the toll you pay for scale
There’s a fifth benefit to this structure that I didn’t lead with, but it’s the one that surprises clients most. It’s that alignment gets easier, not harder. Any organization of real size has a hundred project requests, a thousand small enhancements and a never-ending list of technical debt sitting somewhere. When all of that runs through one intake, owned by the seam team instead of scattered across five departments, prioritization stops being a fight and starts being a conversation. Time and time again, I’ve watched people set aside what’s good for their own team once they can actually see the whole list, the whole picture of what needs doing across the business. That only happens with one line of work to look at, not five competing ones.
This doesn’t come free. Splitting ownership this way comes with costs, and I tell clients about all three before they commit to the model.
First, the ramp-up is slow. If your organization has been running fully centralized or fully decentralized, the first few months of a split model will feel like you’re moving backward. You’re building shared data models from a standing start. You’re writing templates nobody has tested yet. None of it pays off immediately, and it takes longer than anyone wants to admit before the shared foundation starts paying for itself.
Second, coordination gets harder. Running one IT team that reports up a single chain is simpler than coordinating a business analytics team and an IT team that each report somewhere else and only share a dotted line into governance. You’ll spend real time in rooms aligning people who don’t share a manager.
Third, standardization itself is a hard sell early on. People resist naming conventions and data model rules when they can’t yet see why those rules matter. I’ve sat through those meetings. It usually takes a few months before teams start seeing the payoff in shared resources and consistent numbers across departments, and until then you’re asking people to trust a process they can’t yet see the benefit of.
I still think the tradeoff is worth it. The alternative is a business that’s either too slow to answer its own questions or too scattered to trust the answers it gets. Every client I’ve seen commit to the split — security in IT, agility and ownership in the business, a small governing layer holding the seam together — has come out the other side with something that actually gets used. The ones that skip the governing layer end up back in my inbox a year later, describing the exact same $20,000-a-month problem with different numbers attached.
So, when a client asks me where analytics should sit, I don’t tell them to pick a side. Instead, I tell them to build the seam. Put someone in charge who speaks both languages, IT and the business, and give that person say over the standards. If you skip that part, you end up back where you started. Get it right, and it’s the difference between six people opening a dashboard and eighty percent of the company doing it every week.