The future of data strategy: from a function to a discipline

The thesis

Data strategy has historically been treated as an episodic project. A consultancy is engaged, a document is produced, the document sits on a shelf, and the next strategy is commissioned eighteen months later when the document no longer reflects the business. That model is ending. In the organizations we work with, the executives sponsoring data strategy have moved from “produce me a document” to “build me a continuous capability.” The strategy is updated quarterly, tied to capital planning, and revisited every time a major business decision changes the assumptions underneath it. This is closer to how strategic finance functions already operate, and it is the direction the discipline is heading.

The CDO role is consolidating, not expanding

Gartner has been tracking the rise of the CDO role since the early 2010s. The trajectory through about 2020 was clear: more organizations appointing a CDO, with the role increasingly distinct from the CIO. In 2026 we see a different pattern. In mid-market organizations the CDO function is being consolidated with the analytics and data engineering leadership, often reporting to the CIO or directly to the CFO. In large enterprises the standalone CDO role remains, but with a tighter remit: data product ownership, data governance, and enterprise data strategy. The “everything data-shaped” CDO mandate has been thinned. This is not a downgrade. It is the discipline maturing into a defined function rather than an aspirational one. The implication for strategy work is that the document has to be useful to a person who is also responsible for delivery, not a person whose role is to produce strategy in isolation.

Platform consolidation is real, but neutrality still matters

The market has consolidated. Snowflake and Databricks are the platforms organizations are standardizing on for the cloud data foundation. Microsoft Fabric is in active competition for the same workloads inside Microsoft-heavy estates. Power BI, Tableau, and Qlik continue to dominate the analytics layer. dbt is the de facto transformation standard for SQL-based workloads. Fivetran and a small set of competitors handle the SaaS ingest patterns. The argument for vendor neutrality is no longer “you should evaluate twelve options”; it is “you should evaluate the right three or four, against the workloads at the edges of your environment.” We hold partner status with Qlik (Elite Solution Provider, three-time Solution Partner of the Year) and we still write architecture recommendations that begin with the client’s actual environment, not our partner list. That stance will matter more, not less, as the platforms consolidate and the integration edges become the place where the wrong choice creates years of pain.

The strategy document of the future is shorter

The 120-page data strategy document is dying, and good. The strategies the organizations we work with actually use are shorter, more visual, and revised on a quarterly cadence. The structure has converged on something like: the data vision (one page), the target state architecture (one page, with a footnote-level deeper version available), the operating model (one page), the governance approach (one page), and the sequenced roadmap (the longest section, and the one that changes most often). Six pages, plus appendix. The reason this works is that it gets read. The reason the 120-page document failed is that it did not. The CFOs we work with have made this expectation explicit: produce me a strategy I can read in a meeting, defend in front of the board, and reopen next quarter without having to rebuild it.

Strategy is being linked to capital planning explicitly

For most of the last decade, data strategy and capital planning operated on different calendars. The strategy was written in Q1, the capital plan was approved in Q4, and the two were reconciled by an analyst pulling line items into a spreadsheet. That gap is closing. In the engagements we have run over the last eighteen months, the strategy document is increasingly produced inside the capital planning cycle, with the roadmap items priced and sequenced against the same multi-year capital horizon the CFO is working from. This has practical implications. The strategy has to be financially specific. The platform recommendation has to come with a defensible total-cost-of-ownership estimate. The sequencing has to acknowledge what the organization can absorb in a given fiscal year. Strategy that ignores capital planning will continue to lose. Strategy that integrates with it will continue to win.

AI changes the question the strategy answers, not the discipline itself

Generative AI has changed the questions executives ask about data, but it has not changed the underlying discipline of data strategy. The board now asks about AI readiness. The CFO asks whether the data foundation can support AI workloads. The operations team asks whether AI will change their analytics. These are real questions, and the strategy document has to address them. The mistake is to write an “AI strategy” as a separate document. AI workloads are workloads. They sit on the data foundation. The strategy that already covers the foundation, the governance, the platforms, and the operating model can absorb AI as a workload class rather than a parallel program. We write more about the realistic state of AI in analytics in a separate article in this library; the position there is consistent with the position here.

Concrete takeaways for the strategy function

• Treat strategy as a continuous capability. Quarterly review cadence. Standing strategy artifact. Documented owner.
• Pick the platform consolidation that fits. If you are Microsoft-heavy, evaluate Fabric seriously alongside Snowflake and Databricks. If you are not, the choice between Snowflake and Databricks turns on your workload mix and your team’s existing skills.
• Shorten the strategy document. Six pages plus appendix. If it cannot be read in a meeting, it will not be.
• Integrate strategy with capital planning explicitly. Same calendar. Same financial assumptions. Same multi-year horizon.
• Treat AI as a workload class, not a parallel program. Strategy that covers the foundation already covers AI.