We illustrated the talk with old masters. Rembrandt, Hokusai, Millet, Saenredam. Not as decoration, but because every painting in the deck hides earlier versions under its surface. So does every transformed organization. What follows is the SWICA story we told in Munich on 24 June: how a Swiss health insurer with 1.6 million insured persons set out to replace classic data analytics with a data mesh, and what it actually took.
The old world: two warehouses and a queue
SWICA's analytical landscape looked like that of most insurers. A primary data warehouse, CENTRIS DWH, built on the core system SYRIUS, solid but hard to extend with new sources and new data. Next to it, an extended warehouse, the SWICA eDWH, developed in-house over the years to compensate for everything the primary one could not cover. Both maintained by a central team. And everybody was unhappy with the performance of that central team. Not because the team was weak. Because the construction guarantees a queue.
Two things made SWICA unusual. First, a few business units already had direct data access and real data competence, pockets of decentralization that worked. Second, decentralization is part of the company's DNA, seen as a strength rather than a governance problem. So when the aging tech stack forced a migration decision anyway, the conclusion almost wrote itself. In the words we used on stage: we partially already have a data mesh setup in our organization, so let's do data mesh. But there were no data mesh platforms on the market yet. So let's build the platform ourselves.
That second sentence deserves a pause. Data mesh, as Zhamak Dehghani framed it in 2019, is first an organizational idea: domains own their data as products, served on a self-service platform under federated governance. We committed to building the platform — Dragonfly, a governed, self-service cloud platform — and assumed the organizational part would follow the technology. It did not. It never does.
Four ways to be wrong about change
What we presented in Munich as the second act was a series of four experiments, each with its own change philosophy, each wrong in an instructive way.
The first we called the Multi-Domain Lab. Its change notion: we'll show you the new world and you are going to love it. Dragonfly had just been released in a semi-stable state, every data product needed careful nursing, and the project team was figuring out the working mode while demonstrating it. We decomposed a few well-understood pipelines into domain segments and translated the SQL to PySpark, one to one. The platform proved it could handle the workload. The people proved something else: even our most experienced analytics engineers were intimidated by the switch away from familiar SQL. And a perception gap opened that we had not anticipated — providing a report on the old platform felt like a fundamentally different responsibility than serving a downstream data product on the mesh, even when the work was nearly identical. Ownership and governance questions surfaced immediately. We initiated a data community with working groups to define platform standards, and we revised the company's business object model to become the backbone of data ownership. Both were right. Neither self-organized. A community, we learned, is built, not born.
The second experiment served the underserved: business areas the central warehouses had never reached well. The learning here was almost the opposite of the first. Early enthusiasm is a real force and you should ride the wave while it lasts — but enablement of decentralized teams is a discipline in its own right, not something you do on the side. And a set of unconnected islands, however happy each island is, does not make a mesh.
The third, Heavy Lifting, tested speed. An ambitious timeline can indeed force a quick lift-and-shift. But the discussions you skipped do not disappear; they wait for you. And the artifact you shifted has an owner problem: business teams will not take ownership of centrally provided data artifacts. Hand-me-down data never gets owned.
The fourth experiment we titled, on the slide, Collapse under pressure. The change notion was the mirror image of the first: we really need to see if the business can do it alone. Four business units were tasked by c-level management to prove that decentralized analytics works, with IT and enablement involvement deliberately minimized. No business analysis skill in the team. No authority to change processes or operational systems. A narrow scope guardrail: improve B2B reporting. The slide after that one carried the most honest header of the talk: Spoiler, we failed. Technical discussions dominated from day one — how do we do SCD2, what about surrogate keys — while the actual business question stayed unasked. The team built three data marts, then discovered that a fourth, unbuilt one was the one actually needed. And when the prototype finally worked, it hit bedrock: the granularity and quality of data recorded in our B2B processes made the desired contract-level drilldown impossible. No platform fixes that. The project is on hold, reconsidering what would tangibly help B2B decision makers. Autonomy without enablement is not empowerment. It is abandonment with better branding.
Moving mountains: what the failures bought
Here is what those four experiments purchased, at full price: the design of the real migration, which we call Moving Mountains. The mission is to migrate the central DWH to the mesh platform within three years. The mandate is deliberately maximalist — no lift-and-shift of existing models and code, live the data mesh principles, question every existing model and report, and hand the organization the final puzzle piece of its transformation.
The operating model is a hybrid, and every element of it answers a specific earlier failure. A strong central core team — data engineering leads, an architecture stream, a change management coordinator, a project office — because self-organization does not happen on its own. Strong business unit leads who own and manage their data products long-term, because hand-me-down artifacts never get owned. External data engineers delivering the bulk of the work, funded centrally but chosen by the business leads, because ownership starts with choosing. The business analyst role was made explicit after the B2B collapse: roughly 20% of design effort estimations are now allocated to business analysis, and one full-time BA built a framework that is now being multiplied. And a data architect role was created inside the core team, with the mandate to set central standards and work with the business units to implement them. Modelling, it turns out, is not dead. It just needed a mesh-native way to be done.
Six months in, the early evidence points the right way. About 40% of all reports were already cut in the pre-study, and proper business analysis is removing roughly another 5% — half the migration is refusing to migrate things. We are pushing reports back where they belong: core-system logic that had been replicated in SQL returns to built-in features, operational backlogs that lived as reports move to workflow tools, even where that extends scope beyond the analytical platform. A strongly-managed cross-domain data layer now provides a governed, interoperable model for analysis and reporting. And the costly decentralized project setup is starting to pay off where it matters most: ownership has increased in nearly every business unit we work with.
Six lessons to climb the mountain
We closed the Munich talk with six lines, and they survive translation into prose. First, community is built, not born — connect the involved teams deliberately, because a data community will not self-organize. Second, enablement is the job, not a side quest. Third, no book teaches data mesh; you have to get your hands dirty, and invest in your own skillset before you preach to others. Fourth, hand-me-down data never gets owned — ownership begins at creation, not at handover. Fifth, no leadership belief, no breakthrough; when we hit serious obstacles, management conviction was the only thing that carried the project across. Sixth, modelling isn't dead — go mesh-native instead of abandoning the discipline.
Notice what is absent from that list. Not one lesson is about the platform. Dragonfly, the thing we had to build ourselves because the market offered nothing, turned out to be the most tractable part of the whole transformation. This is the same pattern I keep finding in five years of AI strategy: the technology is rarely the constraint. The organization is. A data mesh migration is a change management program wearing a technology costume.
Chasing stars
The third act of the talk was short, because the future always is. SWICA's north star is a data-driven company, navigated by four guide stars: data literacy, evidence-based decisions, data as a strategic asset, and an AI-ready foundation of curated, context-rich data. That last one matters beyond SWICA. Every organization currently racing into AI will discover that the race runs through exactly the terrain described above — ownership, modelling, enablement, governance. The ones who did this unglamorous work will feed their models curated, understood, owned data. The others will feed them the eDWH.
The deck's title slide showed Rembrandt's Flora. The slide after it showed the same canvas under X-ray, where an earlier, different composition sits beneath the visible one. Restorers call these buried revisions pentimenti — the painter's changes of mind, preserved under the finished surface. Our data mesh will carry its pentimenti too: a lab that intimidated its engineers, islands that never connected, a lift that shifted nothing, a collapse under pressure. They are not failures of the painting. They are how the painting got made.
That is the art of change. The platform was the easy part. It always is."
