Data mesh made a promise that resonated with every enterprise drowning in a central data backlog: stop routing everything through one overloaded team, and give ownership of data to the people who actually understand it. Marketing owns marketing data. Finance owns revenue data. Each domain runs its own data as a product, and the business finally scales past the bottleneck.
It's a compelling model. But there's a dependency in it that rarely gets discussed until an implementation is well underway — and when it surfaces, it quietly undoes the whole thing.
That dependency is observability. More precisely: who is allowed to own data quality. Because if the answer is still "a small group of engineers who write SQL," you haven't decentralized ownership at all. You've just moved the bottleneck one layer down and hidden it.
A quick refresher on what data mesh actually asks for
The term was coined by Zhamak Dehghani at ThoughtWorks in 2019, and the framework rests on four principles:
Domain-oriented ownership — the teams that generate and understand the data own it, instead of a central data team.
Data as a product — each domain treats its data like a product, with consumers as customers. A data product is expected to be discoverable, addressable, self-describing, interoperable, secure, and — critically — trustworthy.
Self-serve data platform — domain teams can build and operate their products without deep platform expertise, which keeps their cognitive load manageable.
Federated computational governance — local domain autonomy operating inside a set of global standards, so all those independent products still interoperate.
The diagnosis underneath all four is the same: centralized data teams become bottlenecks because they don't carry domain context, so they build the wrong things and everyone waits. Data mesh is the attempt to push ownership to where the knowledge already lives.
Now look closely at principle two. A data product has to be trustworthy. That isn't a soft aspiration — it's a baseline attribute. And trustworthiness is not a property you declare. It's a property you continuously verify. Which means observability isn't a side tool bolted onto a data mesh. It's load-bearing. It's how "data as a product" stays true after day one.
The recentralization trap
Here's where most implementations quietly break.
The first generation of data observability was built for a central data-engineering team. Monitors are authored in SQL. Alerts are expressed in technical terms — a table went stale, a column's distribution drifted, a row count fell — with no inherent connection to which business process is affected or who owns it. That design was a reasonable fit for a world where one central team watched the whole estate.
Drop that same tooling into a data mesh and the contradiction is immediate. You've told the Marketing domain it owns its data products. But the only people who can define what "good" looks like for those products, set up the checks, and interpret the alerts are the engineers who speak SQL — most of whom sit outside the domain. So quality ownership snaps back to a central technical group. The domain "owns" the data in name, while a different team owns whether anyone can trust it.
That's not a data mesh. That's a centralized quality function wearing a decentralized org chart. The principle that was supposed to keep quality high — responsibility lives where the knowledge does — is the first casualty.
The fix isn't more dashboards or more monitors. It's an observability layer that domain experts can actually operate, that speaks in business terms rather than only technical ones. Two capabilities decide whether that's possible: accessibility and business context. They're usually treated as UX niceties. In a mesh, they're structural.
What domain-owned observability looks like in practice
This is the gap Sifflet was built to close, and it maps onto the four principles more directly than it might first appear.
Domain owners define quality without writing SQL. Sifflet's monitor library is template-driven and no-code: freshness, volume, schema change, nulls, duplicates, distribution change, referential integrity, and format checks like "is this a valid email" or "does this match the expected pattern." A data product owner who knows the business meaning of a field — but not the SQL to validate it — can set up and own the right checks themselves. The SQL and condition-based monitors are still there for engineers who want them, so the platform serves both personas instead of forcing everything through one. That's the self-serve principle in its most concrete form: ownership without a SQL prerequisite.
Data products are first-class objects, not an afterthought. In Sifflet, a Data Product is a logical grouping of the datasets, dashboards, and pipelines that serve one business use case, discoverable through the data catalog. Each one belongs to a domain and carries an owner, an SLA (for example, "updated by 08:00 daily"), tags, and default alert routing, with an aggregated health status across all its assets. Crucially, Domain Editors — not just central admins — can create and manage them. That's domain autonomy expressed in the product model itself, and it's exactly the "data as a product" principle made operational.
Alerts carry business meaning and an owner. Because Sifflet ingests business context — ownership, a shared business glossary, domain structures, and downstream lineage — an alert isn't just "table X is stale." It's tied to the data product it belongs to, the owner accountable for it, and the dashboards and processes downstream. Notifications route to the owning domain's channel (Slack, Teams, Jira, ServiceNow) by default, rather than landing in a central queue. The domain that owns the product is the domain that hears about the problem.
Coverage scales without a central team hand-building everything. Sentinel, Sifflet's auto-monitoring, recommends the monitors that should exist so domains don't start from a blank page — directly lowering the cognitive load that the self-serve principle is meant to protect. When something does break, Sage (root-cause analysis) and end-to-end, field-level lineage trace the blast radius across domain boundaries — which is the interoperability that federated governance depends on.
Global standards, local autonomy. Domains and subdomains, a shared business glossary, ownership, access control, SSO, and audit logs give the central governance group the global guardrails the fourth principle calls for — interoperability, security, documentation — while leaving each domain free to run its own products inside them. That balance between local decision-making and global rules is the hardest part of federated governance to get right, and it's a configuration problem in Sifflet rather than an organizational standoff.
Map it to Dehghani's baseline data-product attributes and the fit is hard to miss: discoverable (catalog), addressable (URI-based declarative assets), self-describing (glossary, ownership, metadata), interoperable (cross-domain lineage), secure (access control, audit), and trustworthy (monitors, SLAs, health status). The trustworthy attribute — the one most tools leave to the central team — is the one a domain owner can now hold directly.
The honest boundary
It's worth being precise about what this does and doesn't do, because overclaiming here is how trust in a vendor erodes. Observability doesn't repair bad source data. If a domain's upstream system is feeding in incomplete records, no monitoring layer invents the missing truth. What it does is make the state of the data continuously visible, owned, and verifiable — the "trust but verify" posture that a healthy data mesh runs on. It puts the controls in the hands of the people closest to the data, and it tells them, in their own terms, when a product they own can no longer be trusted. It doesn't replace domain expertise. It arms it.
The point
Data mesh is a sociotechnical shift, not just an architecture diagram. The org model and the tooling have to agree with each other. An observability layer that only central engineers can operate doesn't just fail to help a mesh — it actively pulls ownership back to the center, one alert at a time, while everyone insists the domains are in charge.
An observability layer that domain experts can actually use, that speaks business before it speaks SQL, is what lets the mesh hold its shape. Ease of use and business context aren't the soft features in this story. They're the difference between domain ownership on a slide and domain ownership in production.
If your data mesh depends on domains owning trustworthy data products, it depends on giving those domains observability they can run themselves. That's the part most tools quietly take back. It's the part we built Sifflet to give away.
-p-500.png)
