Skip to content
Software Architecture Guide

Data reusability and standardized access

Explanation

Section titled “Explanation”

Different applications often describe the same data in different formats. Someone must reconcile these differences before the data can be reused. Standardized access moves that work to a shared agreement.

Treat data as a product. Data mesh is an approach where business domains supply data for analysis. It holds that this analytical data must be treated as a product. That supports reuse by other consumers. Data products can also expose standardized interfaces, so consumers reach data in a uniform way.

Agree on shared identity. Some concepts cross domain borders. One example is how to identify a podcast listener. That decision is a global concern, so domains need to agree on it. This addresses inconsistent keys across systems.

Set global standards for a purpose. Global decisions in data mesh have one purpose: interoperability across domains.

Use a canonical data model. The Canonical Data Model pattern asks how to integrate applications that use different data formats while keeping dependencies minimal. The answer is a common data model that does not depend on any one application. Every application produces and consumes messages in that format. Translation to and from it happens at the edges. See the article Canonical Data Model for details.

Balance local and global. Federated computational governance accepts change and multiple interpretive contexts. It balances local domain autonomy against enterprise-wide standards.

Example

Section titled “Example”

An order system and a shipping system both store customers, each with its own customer key. An analyst who wants shipping delays per customer must first match the keys by hand. Instead, the two teams agree on one customer identifier. Each team then publishes its data as a product with a standard interface. The analyst can combine both without manual matching.

Trade-offs

Section titled “Trade-offs”

Global standards create interoperability, but they limit how freely each domain can model its own data. Federated computational governance tries to balance the two. It keeps local autonomy while enforcing enterprise-wide standards, and it accepts that change and different interpretations will occur.

A canonical data model keeps dependencies low. It also requires every application to translate to and from the common format at its edge. That is extra work for each application.

Applications translate to a common model at their edges; consumers reuse the data through a standard interface.

Diagram source 
flowchart LR
  A[Order system] -->|translate at edge| C((Canonical model))
  B[Shipping system] -->|translate at edge| C
  C --> D[Data product with standard interface]
  D --> E[Analyst or other consumer]

Checks

Section titled “Checks”
  • Analytical data that domains provide is treated as a product with a standardized interface.
  • Shared identity concepts, such as how to identify a customer or listener, are agreed across domains.
  • Where applications use different formats, a common data model independent of any one application is defined.
  • Applications produce and consume the canonical format, with translation done at the edges.
  • The document states how local domain autonomy is balanced against enterprise-wide standards.
Section titled “Related”

Sources

Section titled “Sources”