Beyond silos: connect data while preserving domains.

Silos are organisational too

Two teams can share a database and still interpret data in incompatible ways. Isolation appears in concepts, priorities and responsibilities. Fixing the technical connection alone leaves part of the problem unresolved.

Preserve domain knowledge

The people who understand a business process are well placed to explain its data. Organising information by domain gives that knowledge a home. A domain takes responsibility and publishes understandable interfaces for consumers.

Create meeting points

Catalogues, glossaries and contracts can connect producers and consumers. A consumer needs to find data, understand meaning and limitations, and know how to request access. Producers need to understand usage to guide product evolution.

Find the boundary that blocks a real decision

A list of disconnected systems is an inventory, not yet a prioritised programme. Start with a decision that depends on more than one team: planning capacity, analysing service coverage or reconciling a result. Follow the information across that boundary and record delays, disagreements and repeated preparation. This identifies whether the main constraint is a missing connection, an unclear definition, an approval process or a product nobody maintains.

Agree on interfaces without forcing one universal model

Different domains can have legitimate views of the same entity. Finance may organise a customer around billing, while service operations organise the relationship around delivery. Preserve these contexts and agree on identifiers, reference periods and the rules for relating records. A common interface should make those assumptions explicit. Attempting to resolve every modelling difference before sharing anything can turn integration into an indefinite project.

A catalogue should lead to a usable relationship

A searchable entry is useful only if it helps someone decide what the product means and how to use it. Include the owner, examples, limitations, freshness and access path. Make it possible to ask a question and report a defect. Producer feedback matters too: repeated misunderstandings may indicate a weak contract, an unsuitable interface or an important use that the current product does not support.

Choose a team model that can sustain reuse

A Data Squad can concentrate delivery capacity while an organisation establishes its first shared practices. A Data CoE can coordinate standards and help domains take responsibility as participation grows. The choice depends on the distribution of knowledge, decision authority and available capacity. Neither structure removes the need for product ownership and ongoing maintenance. Measure whether the next consumer can reuse the product without rebuilding the same integration.

Start with a useful relationship

Choose two teams with a concrete collaboration need. Agree on a product, ownership and terms of use. Check whether a second team can use the information without rebuilding the integration. Observed reuse is more useful evidence than simply counting connected sources.

Questions to take into your next discussion

• Start with a decision that crosses a team boundary.
• Preserve domain meaning and document shared identifiers.
• Provide an owner, usage examples and a feedback path.
• Measure the effort required to onboard a second consumer.