The number worth staring at
The results were presented as a landmark year, with records across revenue, gross profit, operating income and cash flow — and the records were real. So were the rates behind them: full-year revenue up five percent, four in constant currency. Free cash flow up forty percent on revenue up five is cost discipline and working capital, not demand. The operative word in the release was “records”, not “growth”.
Inside the numbers, one line did the work. All-flash arrays — the on-premises storage that sits under enterprise warehouses, databases and file estates — reached a record quarter, up eighteen percent. The public-cloud segment, positioned for years as the structural growth engine, finished the year up three percent, slower than the company as a whole.
That gap is a measurement. A vendor with every incentive to grow its cloud business, and the product to do it, found its customers spending on the boxes in their own data centres instead. Enterprise data, in the aggregate, is where it has always been.
What the spending says about your AI programme
Most AI integration plans we see carry an unstated assumption: that the data will be in the cloud by the time the AI needs it. The migration is on the roadmap; the AI platform is cloud-native; the two will meet. In practice the migration slips, the AI programme waits, and a year later the pilot is still running on an extract because the “real” data is on an array in a data centre the AI service cannot reach.
The alternative is to design for where the data actually is. That means governed connectors that reach on-premises systems of record — the warehouse on the array, the ERP in the data centre, the document store nobody migrated — with the same permissions, classification and logging as the cloud paths. It means placing retrieval indexes and context tiers near the data they are derived from, because latency across a wide-area link is a real cost in an inference loop. It sometimes means bringing the model to the data — private inference next to the estate — rather than the reverse.
None of that is an argument against cloud migration. It is an argument for separating two decisions that are usually conflated: whether the data should move, which has its own business case and its own timeline, and how AI reaches the data, which can be solved now, wherever it is.
Reading the release
Two further habits from the results are worth carrying to any vendor’s numbers. First, currency: a meaningful share of the quarter’s per-share growth came from exchange rates, which the company disclosed plainly and which a headline does not. Second, the difference between what customers committed to and what was recognised: billings running ahead of revenue is a mildly encouraging signal about the next few quarters, not about this one. Both are the kind of footnote that turns a “record year” into an honest rate, and the discipline is the same one we apply to a benchmark.
What to do with it
- Map the data before choosing the AI platform. Where the systems of record and the largest datasets physically are, and what can reach them, is the first constraint on the architecture — before the model, before the vendor.
- Build the on-premises governed path. The connector that lets an AI service read the warehouse on the array, through its own permissions, with logging, is the integration work. It is unglamorous and it is the whole job.
- Place the derived tiers deliberately. Indexes, caches and context stores go near their sources, on capacity you already own where possible, sized from measurement.
- Decide migration on its own merits. If the data should move, move it for its own reasons, with the AI programme designed to work before, during and after.
The vendor’s chief executive described the platform as delivering access to data “wherever it resides”. Discount the marketing and the phrase is exactly right. Wherever it resides is, for most organisations, still the data centre — and an AI programme that respects that fact ships years before one that waits for it to change.
