A Federated Data Architecture

In other words, Data Mesh. Yes, another technology buzz word to add to the collection? But this one is different.

The biggest challenge in building a data mesh is not technology. It is communication, culture, and trust. Convincing colleagues meant dismantling the narrative that data mesh is an all-or-nothing technical revolution. It’s about people, not platforms. It’s about delivery and not about not dogma. Above all, it’s about aligning incentives so that those closest to the data care about its quality and usability. You can call it what you want. A federated data architecture is essentially what it is. But that doesn’t sound as cool.

Financial services is an industry steeped in hype cycles: another panacea like big data, fabrics, data lakes, data rivers or blockchain. So why is this one different?

Data as a Product

The most effective communication device is reframing data as a product. Everyone (you would hope) in the business understands a product; it has customers, it has features, it requires investment and it must continuously improve. When applied through that lens to data, suddenly conversations shifted:

A hand holding a glowing, digital cube with the word 'Data' displayed on its surface.
  • Who are the consumers of this dataset?
  • What guarantees of freshness do they expect?
  • How will we measure adoption and satisfaction?
  • How will they consume the data?
  • How often will the data change?
  • How often will the structure change?

Instead of vague arguments about “fixing data quality,” you have product managers talking about service levels, roadmaps, and customer value. Data contracts are then discussed as a way to enforce these service level parameters.

Four Pillars in Practice


Zhamak Dehghani’s four pillars of data mesh became a useful scaffold:

1. Domain-Oriented Ownership: In a global bank, data cuts across risk, finance, trading, operations. Learned quickly that ownership must be federated, but not fragmented. Define who owns what at the conceptual and logical levels before any physical mesh could take shape.

2. Data as a Product: Introduce product owners for key data domains. This required upskilling people who had lived their careers in back-office reporting to think like product managers. It not easy, but it creates accountability.

3. Self-Serve Data Platform: Yes, the tech matters here, but only insofar as it enabled teams to publish, discover, and consume data products without filling out a 40-step request form. Focused on lowering the friction: automated lineage and meta-data inference, templated pipelines, standardised metadata via SaaS tooling (for example, SqlDBM).

4. Federated Computational Governance: The biggest cultural hurdle. Most institutions are accustomed to centralised, command-and-control governance. Mesh governance demanded a shift towards guardrails, not gates. Build policy-as-code and a shared taxonomy, but leave enforcement close to the domains. That was uncomfortable, but essential (p78 of Zamak Dhaganis book talks to this).

What Works?


Start with language, not architecture diagrams. People will reject what they don’t understand (and assume they don’t understand the real reasons why such approaches to data exist). The business operates in a totally seperate domain where terms like surrogate keys or semantic models are likely alien to them.

Anchor every conversation in business outcomes. Data mesh is about faster decisions, quicker risk reporting, sharper client insights.

Expect resistance. For many, “mesh” looked like decentralisation without control. It took months of demos and pilots to prove that guardrails could coexist with autonomy.

Invest in product thinking. Without product managers, the whole construct collapses into another technical dead-end. And hire actual product managers, not project managers, not engineers.

Closing Thoughts


The hardest part isn’t choosing technology stacks (it never is), it is rewiring expectations. A financial institution is, by nature, risk-averse. Selling a decentralised approach to data is countercultural. Yet, by grounding the conversation in the four pillars and relentlessly framing data as a product, you can begin to turn scepticism into cautious optimism.

Data mesh is not a hype cycle. It’s not a silver bullet. It’s a language for aligning how we treat data with how we already treat the things that matter most in business: our products.

Discover more from Data Lingua. Where Data Engineering Meets Agentic Business Strategy

Subscribe now to keep reading and get access to the full archive.

Continue reading