What Infrastructure Can and Cannot Do for Your Data

In September, CDW hosted its annual Summit in Dallas. During the Smartest 2 Days in Tech, there was a panel session featuring Kaitlin Hart of Nutanix and Matthew Bednar of Everpure, with CDW's Eryn Brodsky from the Data Center portfolio and strategy team, where they discussed the infrastructure behind your data. The conversation centered on the evolution of “the data problem,” and on how challenges around data are not new, but AI has removed the option of postponing a resolution. One unique perspective was that CDW's infrastructure partners have already begun expanding their portfolios to address both data management and data preparation, which customers are beginning to adopt.

Data is not a new problem, but it has evolved. Twenty years ago, the work was educating organizations on the importance of storing their data and on the formats that would make it accessible to more than just a couple of engineers. Today’s data challenges are treated as a platform decision made somewhere else in the business, while the data center architecture underneath is treated as a retention source rather than what it actually is: the backbone of the business.

Our intent here is to close that gap: to show how infrastructure has changed so that it is uniquely positioned to support your data strategies, and how the partners you are already investing in are modernizing their portfolios to take on data management strategies and data preparation phases, so that your data is available, accessible and accurate. It matters just as much to be clear about where infrastructure stops, because it can help solve the problem you have identified, but it cannot identify the problem for you.

The new catalyst for this approach is your hardware refresh. A refresh is not only a performance and efficiency exercise; it is the natural point to understand, organize, and optimize your data, and it is far easier and more cost-effective to do that before your data migration than after it. Because, as Eryn aptly stated, data is the most valuable resource you have, second only to time.

Organizations have had issues with their data in every era. Enhancements within platforms during that time to access, clean, transform and move data opened genuine new areas of growth for those who used them well. Many others accumulated and waited. Waiting stopped being viable around 2023, when the obligation shifted from keeping data safe to proactively using it. AI, as Kaitlin Hart put it during the session, is a data product; it is not a layer installed above an organization's data; it is manufactured out of it. Every unresolved question about that data becomes a question about the AI.

Many organizations hoped the reverse was true, and that AI would finally clear up the problems they had been deferring. It does the opposite; it amplifies them, surfaces them to far more people, and spreads the inaccuracies further than the organization can see. Enterprise AI failure rates are widely reported, and the reporting usually stops at the number. A 2025 Fivetran press release found that 42% of enterprises say more than half of their AI projects have been delayed, underperformed or failed because of data readiness issues. The more useful observation is the cause. These programs rarely fail because the model was wrong, or the infrastructure was too slow. They fail because the data underneath was not ready, and because nobody treated getting it ready as the project.

Stated abstractly, this sounds like a governance exercise, but the way this presents in the field, it is less comfortable. Matthew Bednar described it plainly during the session: customers do not understand their data; they own it, it sits inside their four walls, and they have no idea what it is, where it exists, what it is good for, or how their own company uses it. A 2026 Barc unstructured data study points to a major visibility gap: Only 29% of respondents say they fully know where their AI-relevant unstructured data lives, while 70% say less than half of that data can be found and used for analytics or AI.

That is not a failure of competence; it is the predictable result of how estates are built. Data accumulates across arrays from several vendors, across multiple hypervisors, across on-premises rooms, colocation space and more than one cloud, over more years than most of the current team has been in post. No single system was ever asked to describe the whole of it, so none does. The effect compounds: when people cannot reach the data that already exists, they create new data that duplicates it, and the organization ends up holding several versions of the same truth with no agreed answer about which one governs. Hart framed this as more than a consolidation exercise: Centralizing infrastructure gives customers a practical way to power new capabilities while improving visibility across the estate.

Ask any infrastructure manufacturer today how they are addressing data management, and you will get a different answer. This is the most useful signal in the market. Every manufacturer is seeing the same shift: The value is no longer only in the infrastructure itself, but in the data that infrastructure helps customers find, prepare and use.

Some have bought their way in, acquiring software companies and keeping that intellectual property deliberately hardware-agnostic, so it works across an estate rather than locking to one platform. Others have gone multi-cloud and multi-hypervisor, treating placement and portability as the problem worth solving because customers cannot say today where their workloads will run tomorrow. Others again have built tightly aligned partnerships that bring deep data services capabilities alongside the platform instead of inside it. HashiCorp’s 2025 Cloud Complexity Report says 52% of respondents identify managing multi-cloud and hybrid cloud environments as a top challenge.

It will not define the problem. The architecture can help solve a problem an organization has identified; it cannot say what that problem is. The most expensive failures start here, and the mechanism is enthusiasm rather than incompetence: experimentation has become so cheap that teams get absorbed in finding out what AI can do without building toward something they already know is valuable. If we do not understand the problem, as Matthew Bednar put it, AI is not going to magically intuit it for us.

Nor will today's architecture carry you forward. Manufacturers have developed programs intended to help customers protect the hardware investment, but they do not exempt the architecture from re-examination. New applications and use cases change what the estate is asked to do, and the honest response is not to assume that the solutions you were building toward will continue to be the solutions as you move forward. And no single portfolio closes the gap. Every vendor is offering a route in; the routes do not join up on their own, and organizations that stay insular, solving this inside one vendor relationship or one team, tend to find the vulnerabilities later. Hart’s guidance was to simplify the starting point: Do not begin with AI in the abstract. Start with a specific, practical business problem the organization can define, measure and improve.

This is where a refresh stops being a hardware purchase and starts being a business case. Infrastructure teams have historically justified a refresh on capacity, performance and support terms, and those arguments are getting harder to win on their own. The stronger case is that the new platform carries capabilities other parts of the business are already asking for, which means the people who need those capabilities should be in the conversation before the design is finished, not after.

It works in two directions at once. From leadership down, the sponsors of the AI and analytics initiatives set the outcomes the estate must support, and their funding is what turns a refresh into a modernization. From the administrator out, the people who run storage, virtualization and backup must reach sideways into the teams they rarely sit with: data security, data governance, application owners and whoever is closest to the data science work. These responsibilities usually get added to someone’s existing role and staffed by committee, which is exactly why describing the estate belongs to everyone in principle and to nobody on a Tuesday afternoon.

Tying the work to a funded infrastructure event is what gets it done, because the refresh supplies the budget, the executive attention, and a legitimate reason to open the estate for inspection at the same time.

Start by knowing what you have and where it is, and accepting that you do not yet have all the answers. If you don't know your data, how can you ensure you're not misusing it? That admission is the hard part, and it is almost universally true because the estate has outlived the people who built it. Then pick one small, specific project and action it, narrow enough to prove value quickly rather than broad enough to impress.

Use that project as a framework rather than a trophy. Learn from it, repeat what proves repeatable across the next effort, and when something fails, fail fast and pivot quickly. A modest use case that earns funding and organizational trust is what buys room for the ambitious work later; heavy spend with nothing to show buys the opposite. Hart described that the first win does not need to be the biggest use case; it needs to be credible enough to create momentum for the next one.

Two terms are worth separating because they are often used interchangeably. Data management is “the what”: the components, teams and strategies an organization already has in play, including data security and data governance. Data preparation is “the how”: the phases underneath it such as tagging, indexing, and cleansing. Neither the phases nor the terminology is novel. CDW has mapped those phases to meet your organization wherever you are today and show you the right next step, rather than handing you a plan that only works from the beginning.

Because this work cuts across teams that rarely report to the same person, a meaningful part of it lands in hybrid infrastructure, which is where CDW has built its position. The first step we want a customer to take is the one above, and we are developing a data curation service built on hardware-agnostic tools so that it matches the shape of the problem: several platforms, several vendors, several locations.

The infrastructure conversation and the data conversation have been held separately for years, on different budgets. They are the same conversation now, and the next refresh is where that becomes a decision rather than a renewal. Infrastructure can describe an estate nobody has fully described, explain how the organization uses what it holds, and keep options open as models change. It cannot define the problem, guarantee today's architecture is the last one, or close the gap single-handedly. Start with the move that makes every move after it easier: find your data. You cannot buy back time, but you can stop spending it hunting for what you already own. Your next refresh is the opening. Make it the moment you stop buying capacity and start building capability.

With thanks to AI Lead, Kaitlin Hart of Nutanix and Principal Technologist, Matthew Bednar of Everpure, for the conversation that started this.