Mesh, Myths and Master Data: Why Domain Ownership Alone Won't Untangle UK ERP Estates
Photo: UK manufacturer ERP systems data architecture meeting, via upload.wikimedia.org
Data mesh has become the default answer to a real problem. UK mid-market manufacturers and retailers have accumulated ERP, CRM, warehouse and planning systems over years, often through acquisition, customisation and local compromise. The result is sprawl: duplicated master data, brittle interfaces and reporting that depends on a few people who know where the joins are. Data mesh promises to make domain teams responsible for their own data products. That promise is attractive. It is also easy to misapply.
Where mesh earns its keep
Data mesh is not a product or a migration. It is an operating model built on domain ownership, data as a product, a self-serve platform and federated governance. It works best where domains have clear boundaries, capable owners and a platform team that can supply common controls. In a UK retailer with separate merchandising, supply chain and finance domains, for example, a well-run data product for stock availability can reduce central bottlenecks. In a manufacturer, a product data product for item, bill of materials and supplier lead times can be valuable if the domain understands its consumers.
Where it fails in legacy-heavy estates
The failure mode is predictable. An organisation reads about domain ownership, appoints a data steward in each function and calls the result mesh. No shared standards follow. Each domain builds its own pipeline, defines its own customer key and publishes a data product with unclear quality. The centre retreats, and the silos become more articulate.
Legacy ERP makes this worse. ERP estates are often deeply customised, with batch interfaces, local extensions and years of embedded process logic. The domain boundary may be clear on an organisation chart but not in the data. Finance, procurement and supply chain share supplier records, cost centres and item masters. Giving each function ownership without a master data authority simply distributes the argument.
Data contracts are useful, but they are not a substitute for integration ownership. A contract that says the finance domain will publish cost centre data is meaningless if no one owns the ERP extract, the transformation job and the service level around it. In estates with limited platform teams, contracts can become documents that describe intent rather than enforce behaviour.
A pragmatic alternative: federated delivery with central standards
UK organisations with small platform teams should not attempt a full mesh maturity model. A more realistic model is federated delivery with central standards. Domain teams contribute to data products, but the centre sets the minimum controls: reference architecture, master data authority, interface ownership, quality thresholds and a catalogue.
Start with an interface register. Every integration between ERP, CRM, warehouse and SaaS should have a named business owner, a technical owner, a schema, a refresh frequency, an error path and a monitoring arrangement. This is unglamorous, but it is the foundation on which any domain ownership can rest.
Next, define master data authority. Customer, supplier, product, employee and location data need a single accountable owner and agreed survivorship rules. In a manufacturer, item and bill of materials data may sit with engineering or operations; that decision must be explicit. In a retailer, product and location hierarchies need the same treatment. Without this, domain data products will disagree on the entities that matter most.
Use data contracts selectively. Apply them at high-value boundaries where a consumer depends on a producer: stock availability to e-commerce, supplier lead times to planning, customer records to service. Do not impose contract overhead on every internal table. A contract should include quality expectations, change notification and an escalation route.
Finally, create a thin platform team with a clear remit: catalogue, lineage, quality checks, access control and reusable ingestion patterns. It should not become a central delivery team for every domain. Its job is to make good behaviour easier than local workarounds.
Governance without theatre
Federated governance should be a decision-rights model, not a meeting schedule. Define who can approve a new data product, who can change a master data rule, who owns an interface and who arbitrates when domains disagree. A monthly architecture forum is useful only if it can make those decisions.
Data protection belongs in the same model. UK GDPR accountability, retention and subject rights need to be designed into data products and interfaces, not added after a catalogue entry. The ICO expects organisations to demonstrate how data is governed across systems, including legacy extracts and spreadsheets that sit outside the core estate.
The pragmatic conclusion is not that data mesh is wrong. It is that mesh is a destination for organisations with mature domain ownership and shared standards. For many UK mid-market firms, the next step is less fashionable: fix integration ownership, settle master data authority, publish a small number of trustworthy data products and build governance that can say no. That work will not produce a memorable conference slide, but it will make later decentralisation credible.
