Stop building data products. Start building data services.

Stop building data products. Start building data services. | Databricks Blog Skip to main content

Summary

The one-product-per-use-case model breaks down under acquisition-driven growth and agentic consumption. A services layer is more adaptable to what comes next.

Moving data mastering and quality checks closer to ingestion is what makes integration cycles measured in weeks, rather than months, possible.

One of the most important metrics is insight lag: the gap between when data exists in the company and when someone can actually use it.

The traditional enterprise data playbook assumes a certain pace. You design a strategy, you build the platform, you onboard sources methodically, and you stand up products for each major use case. The plan is the artifact, and the artifact is built to last. That playbook is being stress-tested in a way it was not designed for. Companies growing through acquisition, building agent-based workflows, and absorbing new data sources at speed are discovering that strategies built for a slower era become constraints on the business itself. The architecture, taxonomy and operating model that worked at one pace start to actively work against the next one. Barry Panayi is Group Chief Data Officer at Howden , a global insurance broker, underwriter and reinsurer operating in over 50 countries with 25,000 employees. Five years ago, the company had 10,000 people. Last year, it acquired more than one business per week. Howden runs its enterprise data platform on Databricks , consolidating over 100 sources of record into a unified architecture that supports everything from regulatory reporting to conversational analytics through Databricks Genie . In this blog, Barry discusses how traditional design choices will not work for where AI consumption is heading. The product model gets clunky. The reconciliation cycle gets expensive. The dashboard backlog becomes the bottleneck. Below, Barry makes the case for what to build instead. The product model gets clunky. Services scale. Aly McGue: You mentioned that the one-product-per-use-case model starts to break down at a certain point. What do you mean by that, and what replaces it? Barry Panayi: I have begun to see that this model gets clunky. If you think about your data layer as a set of open, governed services, it becomes much more adaptable to whatever AI demands come next. We are going to be serving data to agents that pipe it around the business, and that requires a different design mentality. You cannot pre-define every use case when the consumers are no longer just dashboards and analysts. Agents will compose data in ways you did not anticipate. A services layer assumes that. A product catalog does not. This is also why I tell people to bring in whoever leads process and agentic work in your organization early. Not after the platform is built. Shift left, or pay for reconciliation forever Aly: Howden acquired more than one business per week last year. What does that pace do to a data organization, and what had to change architecturally? Barry: When I arrived, we had roughly 80 data sources ingested, and it was taking about six months to integrate data post-acquisition. At the pace we are acquiring, that meant people were creating silos or pulling data from elsewhere because they needed results now. We had limited adoption across our divisions because we simply did not have the coverage. It was not just a technical modernization. It was about removing the cost of fragmentation, slow integration and duplicate effort. Architecturally, we shifted in a different direction. The previous setup handled data mastering and quality checks further downstream, closer to the reporting layer. We needed that to happen as near to ingestion as possible so data becomes usable faster. That shift changes the whole timeline. One of Howden's biggest strengths is collaboration between different parts of the business. And what fuels that is the data. You need to know what your colleague has that could help you and how you could help them. There were so many business opportunities we could unlock just by getting data visible, not even fully ingested and mastered, just visible. The importance of unified business context for modern analytics Aly: When you have that many sources, the same metric can exist in multiple correct versions. How did you stop spending your team's time on manual reconciliation? Barry: We could have up to four versions of the same data point, and all of them were correct in their own context. There was no common data model or taxonomy, so my team spent a lot of effort working out which version was the right one for a given answer. The executives always got what they needed. We ensured the numbers reconciled. But the manual reconciliation took time and resources that could have gone toward higher-value work. We have since built a standard data model, the Accord data model, alongside the platform. That codifies the logic so the reconciliation is built in rather than dependent on people catching it each time. That is the broader point. If your taxonomy is not codified, your team becomes the reconciliation engine. That is a tax you pay every reporting cycle, and it scales with the business in exactly the wrong direction. From proofs of concept to reusable capability Aly: Many companies have a portfolio of AI pilots that never scale. What changed at Howden? Barry: Like many organizations, our early stages were all about exploration, which meant we were building unique use cases from scratch. It was a necessary phase to see what was possible, but to truly scale, we had to move away from rebuilding for every division. Now, because of how we are using the Databricks platform, we have standardized pipelines, shared code and reusable data assets. We can do cross-domain analytics, mixing client data, risk data and market data together, building it once instead of rebuilding per division. We have an AI use case pipeline across the group now. We are still working on productionizing models so they can be consumed as consistent services, and that is a gap I am honest about. But the transition from isolated experiments to scalable capability is real. We would not be able to do any of it without that unified view. The metric is insight lag, not data freshness Aly: In an industry that does not move at retail's transactional speed, where does faster data actually change the outcome? Barry: What matters enormously...