---
title: "How do you create reliable data flows?"
description: "Reliable data flows need one system of record per data set, clear ownership and binding key figures. Causes, approach and target picture explained."
canonical: "https://simo-online.com/en/knowledge/data-architecture"
---

# How do you create reliable data flows?

Reliable data flows need one system of record per data set, clear ownership and binding key figures. Causes, approach and target picture explained.

Dargestellte Fassung: https://simo-online.com/en/knowledge/data-architecture

## How do you create reliable data flows?

Reliable data flows emerge when, for every important data set, it is clear which system maintains it as the system of record, how it reaches the other systems and who is accountable for its quality. Add a binding definition for each key figure and reconciliation rules that surface discrepancies automatically. Data is then captured cleanly once and is available wherever it is needed.

- One system of record per data set, one accountable owner per domain.
- One binding definition and calculation for each key figure.
- Reconciliations expose discrepancies before they reach a report.
- The guiding vision is Zero Friction Data Flow.

### Why three reports show three numbers.

When the monthly report shows three figures for the same revenue, the cause is rarely a calculation error. Usually the figures come from different systems, with different cut-off dates and different definitions, and each one is calculated correctly on its own terms. Customer data lives in the CRM, the ERP and spreadsheets alongside them, each maintained slightly differently. That is a data architecture problem, not a people problem.

Typical break points

- The same master data in several systems, with no system of record
- Key figures defined differently in each department
- Data copied and re-entered by hand
- Interfaces nobody has documented
- No traceable lineage from report to source

### From the report back to the source system.

The most reliable path to clean data flows starts at the end: with the key figures that decisions are based on. From there, each figure is traced back to its source system, noting where it is copied, converted or supplemented by hand. The result is a data map that can be read without technical background and that forms the basis for the target architecture.

Four steps, each with a result

#### Capture sources

Record systems, data sets and interfaces, including the spreadsheets next to the systems.

#### Trace flows

Follow selected key figures from the report back to the source system.

#### Measure quality

Make completeness, timeliness and contradictions visible with metrics.

#### Design the target

Define systems of record, data flows and accountabilities, and agree on them.

### One system of record, one reliable flow.

The target architecture defines which system is the system of record for which data, how data should flow and who is accountable for its quality. Existing systems stay where they do their job. Only what is demonstrably redundant is switched off, and only after a period of parallel operation with reconciliations. The guiding vision is Zero Friction Data Flow: data is captured once and used reliably everywhere.

- A clear data architecture is also the precondition for any sensible use of AI. A model is only as reliable as the data it works on. Fragmented system landscapes produce fragmented results.

### What is a system of record?

The system in which a data set is maintained bindingly, for example the customer master in the CRM or the item master in the ERP. All other systems take the data from there and do not change it themselves. For each data domain there is exactly one system of record at any point in time.

### How can you tell a good data architecture?

Meetings revolve around decisions rather than around which number is right. Every key figure has a defined source and calculation, errors are fixed where they arise, and the lineage of every number can be traced.

### Does data architecture matter for BCBS 239 or DORA reviews?

Yes. BCBS 239 requires banks to aggregate their risk data traceably, and DORA requires financial entities to identify their ICT assets and their dependencies. Documented data lineage from report to source is key evidence for both.

Basel Committee on Banking Supervision: BCBS 239, Principles for effective risk data aggregation and risk reporting, 2013

Regulation (EU) 2022/2554 (DORA), Article 8

DAMA International: DAMA-DMBOK, Data Management Body of Knowledge, 2nd edition, 2017

ISO 8000, Data quality (series of standards)