Akhil Dogra, Enterprise Architect at PostNord, explains the shift from fragmented data silos to a unified, scalable Federated Lakehouse. This strategy moves beyond traditional ETL limitations by utilizing a Hub & Spoke model to provide governed, self-service access across the organization. By focusing on architectural reusability, PostNord has built a “Nordic Analytics Backbone” ready to support the transition toward real-time autonomous decision-making and Agentic AI.
In the lead-up to the Data Innovation Summit, we sat down with Akhil Dogra, Enterprise Architect for Data & Analytics at PostNord, to discuss the evolution of one of the Nordics’ most complex data landscapes.
The transformation of PostNord’s data strategy is a story of close collaboration. Working alongside Abhijeet Singh, Platform Architect for the YODA platform, Akhil has spearheaded a move away from “Data Chaos” toward a scalable, Federated Lakehouse model. While Akhil defines the enterprise-level direction and business alignment, Abhijeet ensures the technical roadmap and engineering standards turn that vision into a reliable, self-service reality.
In this interview, Akhil shares the insights gained from this partnership – from the transition away from siloed ETL solutions to the implementation of a Hub & Spoke operating model. He breaks down how they built the “Nordic Analytics Backbone” and explains why their architecture is now evolving to support the next frontier: Agentic AI and autonomous decision-making.
Your session at the Data Innovation Summit focuses on moving away from “Data Chaos” – what were the primary technical limitations of using independent ETL solutions across the organization?
Akhil Dogra: The primary limitation was the total cost of complexity – both in ownership and in delivery. Each solution operated independently, with its own ETL pipelines, technology stack, and lifecycle. This led to fragmented development, where similar business use cases had to be rebuilt multiple times – significantly slowing down time-to-market. At the same time, teams defined KPIs in their own context, resulting in multiple versions of the truth and making it difficult to establish consistency and trust in data.
Another critical challenge was the heavy dependency on central teams. Data capabilities were not aligned with where business context existed, which meant even small changes required coordination across teams – creating bottlenecks and limiting agility. In addition, business teams often lacked the technical capability to access and explore data independently, making them reliant on specialized teams for even basic insights.
Ultimately, the combination of duplication, fragmented ownership, centralized dependencies, and limited self-service meant that the cost and complexity of the landscape outweighed the value it delivered.
Why was a Federated Lakehouse using a Hub & Spoke model the right architectural choice to replace those fragmented systems?
Akhil Dogra: There has been a lot of discussion in the industry around centralized models, decentralized data mesh approaches, and everything in between. From our experience, there is no one-size-fits-all model – each organization has to design its architecture based on its own structure, scale, and constraints.
At PostNord, we historically operated with multiple centralized IT teams across different countries. While each setup worked locally, they were largely siloed from one another, with varying technology choices and limited alignment. At the same time, moving fully to a decentralized model like data mesh was not practical, given the lack of consistent platform capabilities, cost constraints, and limited availability of skills in modern data technologies.
A fully decentralized approach in that context would have led to fragmentation and loss of control, while a fully centralized model would have continued to create bottlenecks and limit scalability. The Federated Lakehouse with a Hub & Spoke model allowed us to strike the right balance. We established a central Analytics Center of Excellence as the “hub,” responsible for building and operating the core platform, along with standardized templates, golden paths, governance frameworks, and DevOps/MLOps capabilities.
At the same time, domain teams act as “spokes,” building their own data products and use cases on top of this foundation, closer to where the business context exists.
In your experience, why does platform + operating model often matter more than the specific tools when trying to scale a data transformation?
Akhil Dogra: In our experience, scaling data transformation is less about the tools you choose and more about how well your platform and operating model align with the organization. The real challenge is not building a single data solution, but enabling many teams to build solutions quickly, consistently, and with trust – close to where business context exists. That requires clear ownership, well-defined lifecycles, and standardized ways of working.
A key part of this is reusability. Without shared components, common data models, and standardized pipelines, teams end up rebuilding similar logic repeatedly, which slows down delivery and increases inconsistency. While most organizations operate differently in terms of structure and responsibilities, the platform must fit into that operating model – not the other way around.
This is why the platform and operating model must go hand in hand. The platform provides reusable building blocks – data pipelines, templates, governed datasets – while the operating model ensures these are adopted consistently across teams. Without this alignment, even the best tools lead to duplication and fragmentation. But when both are designed together, they enable scalable, reusable, and trusted data products across the organization.
How does your “managed self-service” data approach now allow a business user to access data across the organization without facing technical bottlenecks?
Akhil Dogra: Our managed self-service approach is designed to remove bottlenecks without losing control. The central platform team takes care of the technical complexities – such as infrastructure, security, access management, and standardized pipelines – so domain teams don’t need deep platform expertise to get started.
A key part of this model is how we structure data access. We provide centrally managed, source-aligned datasets that are governed and made accessible across the organization in a controlled way. This allows teams to reuse trusted data without having to rebuild ingestion or interpretation logic. On top of this, we provide templates, golden paths, and reusable components, enabling domain teams to build solutions in a consistent and governed way.
This enables domain teams to develop and own their data products closer to where the business context exists, with full accountability for their use cases, while still operating within a shared and trusted framework. We are also extending this model with AI-driven access. By exposing certified, consumer-aligned data products through conversational interfaces – similar to tools like Databricks Genie – we enable non-technical users to discover and query trusted data using natural language, further reducing dependency on technical teams.
As a result, business users can access and explore data more directly – either through curated datasets or domain-owned solutions – without depending on central teams for every request.
Now that the “Nordic Analytics Backbone” is operational, how do you measure the impact it has had on PostNord’s ability to make informed business decisions?
Akhil Dogra: We measure the impact across a few key dimensions – efficiency, speed, adoption, and data quality. From an efficiency perspective, consolidating multiple siloed platforms into a single analytics backbone has significantly reduced infrastructure and maintenance overhead. In addition, by standardizing the platform and providing shared frameworks, we’ve reduced the need for duplicated platform engineering efforts across domain teams, allowing them to focus more on business logic rather than technical setup.
In terms of speed, we’ve seen a clear improvement in time-to-market. What previously took months to deliver can now be developed in weeks or even days, enabled by standardized pipelines, reusable components, and a common platform.
Adoption is a strong indicator of success. Over the past three years, we have onboarded more than 80 teams and supported over 200 use cases on the platform, while also replatforming legacy data warehouse solutions into a single unified environment. We also measure data quality and consistency by tracking the reuse of governed datasets and the reduction in conflicting KPIs. Having a shared, trusted data foundation has significantly improved confidence in decision-making across the organization.
Ultimately, the biggest impact is that we’ve shifted from reporting data to enabling decisions – where teams can act faster with greater trust in the data they use.
Looking toward the 2026–2027 horizon, how will this architecture evolve to handle emerging trends like Agentic AI or the shift toward autonomous decision-making?
Akhil Dogra: I see our architecture shifting in a few key ways to keep up with Agentic AI and autonomous decision-making. The good news is that YODA already gives us a strong foundation. But a few things will need to evolve.
First, data quality and trust become non-negotiable. When a human looks at a dashboard, they can spot bad data. But once AI agents start making decisions on their own, no one’s double-checking every call. So we’re putting more focus on data contracts, lineage, and observability, so agents work off data we can actually trust.
Second, we have to treat AI agents as real users of the platform, not just people with dashboards. That means exposing data as proper products with clear meaning, so an agent actually knows what a “shipment” or a “delivery” is. Without that, agents just guess – so we strongly vouch for ontologies.
Third, governance needs to grow up. Today we manage who can access what data. Tomorrow, we also need to manage what agents are allowed to decide on their own, and where a human still needs to step in. And finally, the architecture has to get more real-time. Autonomous decisions can’t run on yesterday’s batch data, so we’re moving more workloads toward streaming and event-based patterns.
The way I see it: YODA started as a platform for consolidating data, then became a platform for self-service analytics. The next chapter is making it a platform that serves both humans and intelligent agents, safely and at scale across the Nordics.
If you want to learn more about the technical framework and engineering standards behind the YODA platform, don’t miss Abhijeet Singh’s session at the Data Innovation Summit. He will move beyond the high-level strategy to provide a practical deep dive into the Hub & Spoke blueprint that turned PostNord’s data chaos into a governed, scalable reality. This is a must-attend for those looking to master the operating model required to scale data across domains and provide authorized, self-service access to every corner of their organization.
