Is data mesh right for your team: six questions before you commit

One, the queue test. Is the central data team spending more time triaging intake than building, and has hiring into it stopped reducing lead time. A mesh redistributes work; it does not reduce the total.

Two, the domain count. Are there at least three distinct business capabilities producing analytical data on a regular basis, each with a team that could plausibly own it. One or two domains means a mesh is a naming exercise on top of a shared warehouse.

Three, the capacity test. Can each candidate domain absorb analytics engineering work, through a hire, an embedded engineer, or a rotation. Without capacity, ownership is a transfer of blame.

Four, the platform test. Does a platform team exist, or can one be funded now, to provide storage, orchestration, catalog registration, access control, and observability as self-serve capabilities. Decentralizing before the platform exists produces four different ingestion stacks.

Five, the semantics test. Do domains already disagree about core entities such as customer or order. Disagreement is not a blocker, it is the reason federated governance is one of the principles, but it has to be sequenced first rather than discovered later.

Six, the sponsorship test. Is there an executive willing to defend the arrangement through the two quarters where delivery slows before it speeds up. Mesh adoptions that die usually die in that window.

Four or more yes answers, including the platform test, and a two-domain pilot is a reasonable next step. Fewer than four, or a no on the platform test, and the honest recommendation is to fix the underlying constraint directly.

The platform test is not scored like the others because it is a gate rather than a signal. Decentralizing without shared capabilities does not produce a slower mesh, it produces four ingestion stacks with four upgrade paths, and no later platform investment recovers the year that costs. A no there ends the discussion regardless of how the other five went.

A no is not a verdict on your maturity. Most organisations under roughly a hundred people have one domain that matters and a central team that is a bottleneck only during quarter close. For them, a mesh imports the coordination overhead of a large organisation without the scale that justifies it.

                                                    yes  no
1  Central team triages more than it builds, and
   hiring into it stopped shortening lead time      [ ] [ ]
2  Three or more business capabilities produce
   analytical data regularly                        [ ] [ ]
3  Each candidate domain can absorb analytics
   engineering work (hire, embed, or rotation)      [ ] [ ]
4  A platform team exists or can be funded NOW      [ ] [ ]   <- gate
5  Domains already disagree about customer/order,
   and you are willing to sequence that first       [ ] [ ]
6  An executive will hold the line through two
   slower quarters                                  [ ] [ ]

4+ yes AND question 4 is yes  -> two-domain pilot, six months
question 4 is no              -> build the platform first, revisit
otherwise                     -> fix the constraint you actually have

Keep one warehouse and one transformation project, then take the parts of data mesh that cost nothing: name an owner per subject area in the model configuration, publish a contract for the tables other teams read, layer the model so raw, cleaned, and serving are visibly different, and put quality checks at the boundaries. That gets most of the reliability benefit with none of the reorganisation.

Medallion layering (bronze, silver, gold) is the common shape for this, and it coexists happily with a later mesh adoption: the layers become the internal structure of each domain rather than of the whole warehouse. See medallion architecture.

The second cheap win is making ownership visible. A diagram that shows which team owns which part of the pipeline resolves more arguments than a policy document, and it stays true when it is generated from the repository rather than redrawn.

Duplicate work is real and partly intentional: two domains will build similar cleaning logic, and the platform team's job is to make that cheap rather than to prevent it. Budget for it instead of treating it as a defect.

Discovery gets harder before it gets easier. In a monolith, everything is in one schema and grep works. In a mesh, a catalog and lineage are load-bearing infrastructure from day one, not a phase-two purchase.

Governance is a standing cost, not a project. A forum that meets, decides, and writes policy into code needs hours from every domain, permanently. If that time is not committed, the fourth principle does not exist in your adoption, and the first three will drift apart within a year.

• The four principles of data mesh
• Data mesh implementation guide
• Medallion architecture
• Data warehouse design guide