The question of who should own data architecture, is it the CTO or does the CDO own it, has sparked heated debates in boardrooms and on LinkedIn alike. It’s a critical issue because data architecture is not just an IT construct, it’s the backbone of your organisation’s ability to derive value from its data. But many organisations are stuck in a vicious cycle where control of data architecture resides with the CTO, leading to a bottleneck for innovation.

A friend of mine, who previously held this role, shared their frustration: “We moved data architecture from the CTO to the CDO so we could control technology for data. Before that, every tech decision had to go through the CTO, which was really constraining.”

This raises a pivotal question and that is: Should the CDO own data architecture?

Before you answer that question, here are my thoughts on the pros and cons of the CDO owning data architecture.

1. Closer Alignment with Data and AI Strategy The CDO is tasked with delivering value from data, and having control of the architecture allows for tighter integration between the technology and business goals. A CDO led data architecture prioritises business goals, insights, and value over traditional IT efficiency metrics.
2. Cutting Through Bottlenecks When the CTO acts as the gatekeeper for every decision, progress slows to a crawl or constrained as my friend mentioned. Shifting ownership to the CDO removes this bottleneck, allowing decisions to be made quickly and with the business’s data needs front and centre. In an environment where speed and adaptability often determine success, this shift can be the difference between staying ahead or falling behind.
3. Focus on Business Value CDOs approach architecture from a value perspective, ensuring it’s built to serve use cases rather than just ticking off technical checkboxes. This shift can bridge the gap between business needs and technical execution.

1. Risk of Silos: Moving data architecture to the CDO risks fragmenting the technology landscape. Without strong collaboration with the CTO, there could be a disconnect between enterprise architecture and data systems.
2. Overlap and Turf Wars: CTOs traditionally manage the broader technology stack. Separating data architecture can lead to turf wars, blurred lines of responsibility, and inefficiencies.
3. Governance Challenges: CDOs may lack the technical depth of a CTO when it comes to integrating data architecture into the broader IT ecosystem. This could lead to poor technical decisions or scalability issues.

It’s time to face the truth, the decision over who owns data architecture reflects how seriously your organisation takes its data and AI strategy. If data is genuinely at the heart of your business, then the CDO must take ownership. Why? Because data architecture is not just about technology, it’s about enabling the business to generate value, and the CDO is closer to those outcomes than the CTO will ever be.

Keeping data architecture under the CTO may seem logical in organisations where data is still an afterthought. But let’s be honest, if your business is still treating data as a secondary concern, you’re falling behind. The real issue here isn’t maturity or goals; it’s ambition. If you want to build an organisation supported by data and AI for the future, then the CDO needs the tools, authority, and autonomy to deliver it. That starts with owning data architecture.

Anything less is just tinkering around the edges.

Let’s stop dancing around the issue. Ownership of data architecture isn’t a question of titles or organisational charts; it’s a question of priorities. If your data architecture isn’t delivering business value, driving innovation, and scaling with your ambitions, then frankly, it doesn’t matter who owns it, you’ve already failed.

This debate too often becomes a smokescreen for inertia or, worse, finger-pointing. The real challenge isn’t who has the keys; it’s whether they know how to steer. Without clear alignment between the CDO and CTO and without a shared vision for what data should achieve, ownership is just a distraction.

So, let’s cut to the chase. Where does data architecture sit in your organisation? And more importantly, is it enabling your business to thrive, or just adding to the confusion?