Howden's Group CDO on why the data product model breaks down at acquisition pace — and what an agent-ready data layer looks like instead
by Aly McGue
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.
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.
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.
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.
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.
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 is reducing what I call insight lag, the gap between when data exists somewhere in the company and when someone can actually use it.
Our business is mainly broking. That means giving brokers the freshest possible insight before they sit down with a client. Our reporting used to be slow and batch-driven. The data was not wrong, but by the time you saw it, it was stale. That does not create a trust problem. It creates a usefulness problem. You are working from a rear-view mirror.
Now, when a broker goes to a client, they can say: "This is what we are seeing across our book right now, this is the benchmarking, this is our house view.” Our data is our IP. There are not many firms that operate across the full insurance value chain the way we do. I would be mad not to make sure we are getting those insights out quickly, and there is no way we could do it with the fragmentation we had before.
Aly: What was the catalyst for rolling out Genie, and what has changed in how people get to answers?
Barry: The question I was asked, possibly even in my interview before I joined, was: why can't we just chat with our data? The logic was straightforward. People are chatting with the entire internet through ChatGPT. So why can't they ask a question of their own company's data and get a fast answer?
There are two sides to it. One is the literal speed. Someone has a question, the answer is some numbers or a quick chart, and Genie does it. The other side is what it frees up. Without it, someone asks for the top ten clients by a metric. An analyst picks that up, clarifies the question, writes a query, builds a dashboard that inevitably gets more elaborate than it needed to be. That cycle is slow. In our US retail business, which was a greenfield operation when I joined, we stood up the target architecture from day one. They are using Genie straight off the bat, and it has probably saved hundreds of hours of dashboard building that people would have forgotten about after the first use.
My colleague has this concept he calls the Howden Intelligence Layer: a thin veneer that triages your question to the right service. Some questions go through a general model for research or email. Others are Genie questions because the answer lives in our governed data. The user should not need to care where it comes from.
Aly: If you could offer one piece of advice to a C-level leader scaling their data and AI efforts, what would it be?
Barry: Go slow to go fast. Not too slow, but design it properly from the start. Get your platform partner to help you design the architecture because I have seen too many architects bring baggage from how they have done it before.
Bring in whoever leads process and agentic work in your organization early. We are going to be serving data to agents that pipe it around the business, and that requires a different design mentality. And start thinking about data services, not just data products.
Barry's argument is not about Howden. It is about the design choices most enterprises are about to confront. The product model that fit a dashboard era is not the model that fits an agentic one. The reconciliation work that gets done downstream becomes a permanent tax unless the taxonomy is codified upstream. The freshness metric most teams optimize for is not the metric that actually matters to the business; insight lag is.
The pace at which Howden is acquiring makes these trade-offs visible faster than they would be elsewhere. But the trade-offs are not unique to Howden. They are arriving for every enterprise that intends to serve data to agents, and the leaders who design for that consumption pattern now will not have to re-architect for it later.
Design for the pace you are heading toward, not the pace you are at today.
To discover how more than 25 industry experts are charting a course toward successful AI deployment, access the "Making AI Deliver" report from Economist Enterprise, produced with support from Databricks.
Subscribe to our blog and get the latest posts delivered to your inbox.