Data as Organisational Memory: What Your Data Architecture Is Actually Telling You

The fossil record

When archaeologists excavate a site, the layers of sediment tell a story — not just about what happened, but about when it happened, what was prioritised, and what was abandoned. An organisation’s data architecture works the same way.

Every database, every integration, every ETL pipeline, every manual spreadsheet export reflects a decision that was made at a specific point in time by specific people under specific constraints. The decision may no longer make sense. The people may have left. The constraints may have changed. But the data architecture persists — and with it, the assumptions that created it.

We’ve started using data architecture as a diagnostic tool, not for its technical health but for what it reveals about organisational structure, decision-making history, and strategic alignment.

What data architecture reveals

Decision boundaries

Where data is stored tells you where decisions were made. A customer record that lives in three systems — CRM, billing, and support — means three teams independently decided they needed customer data, and no one coordinated. The duplication isn’t a technical failure. It’s an organisational one. It reveals a boundary between teams where no shared decision was made.

Power structures

Who controls data access reveals the actual power structure of the organisation — which is frequently different from the formal hierarchy. The team that controls the customer database controls who gets to understand customers. The team that owns the financial reporting pipeline controls the narrative about performance. Data ownership is organisational power, and the data architecture is the map.

Strategic epochs

Like geological strata, data architectures show layers of strategic priority. The legacy mainframe reflects the era of centralised operations. The microservices layer reflects the era of digital transformation. The AI pipeline reflects the current strategic bet. Each layer was built with its own assumptions, its own team, its own definition of “customer” or “product” or “revenue.”

The boundaries between these layers — where they don’t integrate cleanly, where data transformations are required — are precisely the points where strategic transitions were incomplete. The organisation moved on. The data architecture didn’t.

Your data architecture is the most honest documentation of your organisation’s actual history. Unlike strategy documents, it can’t be edited to reflect what people wish had happened.

The diagnostic protocol

We’ve developed a lightweight protocol for reading data architecture diagnostically:

1. Map the data lineage for a single strategic metric. Pick a KPI that the executive team cares about — revenue, customer satisfaction, time-to-market. Trace how the number is generated. Which systems contribute? Which teams own those systems? Where are the manual interventions?

2. Count the transformations. Every time data is transformed — aggregated, filtered, normalised, manually adjusted — is a point where meaning can be lost or distorted. Organisations with high transformation counts on critical metrics are organisations where the executive team is making decisions on heavily processed signal.

3. Date the strata. For each major system or data store, identify when it was built and what strategic priority drove its creation. Map these against the organisation’s strategic timeline. Where do the strata align? Where are there gaps?

4. Identify the orphans. Look for data stores that no current team owns, integrations that no one maintains, pipelines that run but whose outputs nobody consumes. These are the archaeological remnants of abandoned strategic initiatives — and they often consume resources, create maintenance burden, and introduce risk without anyone realising it.

What we find

The diagnostic consistently surfaces patterns that aren’t visible through other lenses:

Strategic amnesia. Critical business logic embedded in systems that nobody understands anymore. The rules are enforced by code, but the rationale is lost. The organisation follows rules it can no longer explain.

Invisible dependencies. Teams that don’t know they depend on each other, connected through data flows that neither team explicitly manages. When one team changes their data output, the other team’s processes break — and both are surprised.

Temporal misalignment. Real-time systems feeding into batch-processed reports feeding into quarterly reviews. By the time the data reaches a decision-maker, it’s describing a reality that may no longer exist.

Data architecture isn’t a technical concern. It’s an organisational diagnostic. The structures that hold your data reveal the structures that hold your organisation — including the ones you didn’t know existed.