Reference Data Architecture: What It Should Contain and How to Use It Without Copying It

A reference data architecture is a reusable pattern for a data platform: its capability layers, principles, quality targets and recorded decisions. It is not a design for your estate. Its value comes from tailoring it into a target architecture you own, then keeping it current. Copied unchanged, it becomes shelfware within a quarter.

Most organisations already have one somewhere: a vendor diagram, a consultancy deck, or an internal wiki page drawn two platform generations ago. The problem is rarely its absence. It is that nobody can say which parts are generic advice, which are decisions the organisation has actually made, and which no longer hold.

#Why Reference Architectures Disappoint

What this means for you: if your teams cite the reference architecture in slide decks but not in design reviews, it has already stopped doing its job.

The usual failure is not a bad diagram. It is a good diagram treated as an answer. A reference architecture shows how a typical organisation could arrange ingestion, storage, transformation, serving and governance. It cannot know your regulatory constraints, your skills, your existing contracts or which of your data domains carries the most value.

Teams then do one of two things. Some copy it literally, building every layer whether or not they need it, and pay for complexity they never use. Others ignore it and build project by project, so each new pipeline invents its own conventions. Both end in the same place: an estate nobody can explain end to end.

A reference architecture is a starting vocabulary, not a design.

The fix is to be explicit about the three levels of architecture and what each one is for, which is where most confusion starts.

#Reference, Target and Solution Architecture

What this means for you: naming the level a document sits at settles half the arguments about whether it is "right".

A reference architecture is generic and reusable. It describes the capabilities a class of platform needs and the patterns that usually work, independent of any one organisation. The TOGAF Standard, whose 10th Edition The Open Group published in April 2022, treats reference models as assets to be reused and adapted rather than adopted wholesale.

A target architecture is yours. It takes the reference, removes what does not apply, makes the choices the reference leaves open (which platform, which integration pattern, which ownership model) and states the end state your estate is moving towards. It is the document a design review should test proposals against.

A solution architecture describes one project: the specific pipelines, tables, services and controls being built now, inside the target's rules. It is detailed, short-lived and owned by the delivery team.

How an industry-specific model fits alongside this structure is a separate question, covered in our guide to when an industry data template pays off.

#What a Usable Reference Architecture Contains

What this means for you: if your current blueprint is only a layered diagram, five of the six components below are missing, and those five are what make it usable.

A diagram of boxes labelled ingestion, storage and consumption is the least useful part of a reference architecture. It is easy to draw and hard to disagree with. The components that make it usable are the ones that constrain choices.

#Capability layers, not products

Layers should describe capabilities, not vendors. A layer called "Snowflake" tells you nothing when the next platform decision comes round; a layer called "governed analytical serving" survives it. Product choices belong in the target architecture, where they can be revisited deliberately, as our Snowflake versus Databricks guide argues for platform selection.

The common refinement pattern of bronze, silver and gold layers is a good example of a pattern a reference can recommend without dictating products. Our glossary entry on the medallion architecture sets out what each layer is for.

#Principles that cost something

A principle that nobody could disagree with is not a principle. "Data is an asset" constrains nothing. "Every dataset consumed by another team has a published contract" constrains a great deal, and that is the point. Each principle should state what it rules out and who can grant an exception.

#Quality targets with numbers

Non-functional requirements are where reference architectures are weakest and where projects most often fail. "Highly available" is not a requirement; a recovery point and recovery time per data domain are. The same applies to freshness, query latency, cost per workload and audit evidence. For regulated estates, these targets connect directly to obligations such as those set out in our article on DORA and operational resilience for data platforms.

#Decision Records: The Part Teams Skip

What this means for you: a reference architecture without recorded decisions cannot explain itself, so every new team re-opens the same arguments.

The two remaining components are decision records and an ownership model. Decision records matter most and are most often missing.

In November 2011 Michael Nygard proposed the architecture decision record: a short document with a title, the context and forces at play, the decision taken, its status, and its consequences, negative ones included. The format has since been widely adopted; the UK Government Digital Service recommends recording architecture decisions this way in its published engineering guidance.

For a reference architecture, decision records do two jobs. They separate the generic advice from the choices your organisation has actually made, and they let a record be superseded cleanly when circumstances change, rather than leaving an outdated diagram in circulation.

The ownership model is simpler but just as necessary: who owns the target architecture, who can approve an exception, and how often it is reviewed. Without it, the document has authority on paper and none in practice.

#How to Adapt a Reference Without Copying It

What this means for you: tailoring is a short, deliberate exercise, not a rewrite, and it should end with a document your design reviews actually use.

#Start from your constraints, not the diagram

List the constraints the reference cannot know: regulatory obligations, data residency, existing platform contracts, skills, budget, and the two or three data domains that carry the most value. Then walk the reference layer by layer and mark each element as adopt, adapt, defer or reject, with a one-line reason recorded as a decision.

#Collapse what you do not need

A mid-sized estate rarely needs every layer a reference describes. Separate real-time serving, a feature store or a dedicated semantic tier may all be deferred until a use case demands them. Deferring is a decision, not an omission, and it should be recorded with the trigger that would bring it back. Where the semantic tier does matter, our explainer on what a semantic layer is and when you need one covers the trade-offs.

#A worked example: tailoring the ingestion layer

Take a typical reference that recommends three ingestion patterns: scheduled batch extracts, log-based change capture and event streaming. A mid-sized retailer with a single ERP, a web shop and no real-time use case yet would not adopt all three on day one. The tailoring exercise for that one layer might look like this.

Each row becomes a short decision record. The result is smaller than the reference, cheaper to run and easier to explain, and it carries its own conditions for growing. When a real-time use case does arrive, the team does not argue from scratch: it reopens one record, checks the trigger has been met and adopts the deferred pattern the reference already described. Repeat the same four-way sort for storage, transformation, serving and governance, and the target architecture emerges as a set of reasoned choices rather than a copy. The trade-offs behind the second row are covered in our guide to change data capture methods and tools.

#Make the rules checkable

Principles and patterns only hold if something checks them. Data contracts, naming standards and access rules can be enforced in the build pipeline rather than in review meetings; our guide to CI/CD for data pipelines shows how, and the data contract is the usual mechanism between teams.

The order in which the target is then built belongs to the roadmap, not the architecture. Sequencing is covered separately in our article on how to sequence a data and AI roadmap.

#Governing the Blueprint So It Stays True

What this means for you: an architecture document that is not reviewed decays at the speed your estate changes, which is faster than most teams assume.

Three habits keep a target architecture current. Every significant design is reviewed against it, and any deviation becomes either an approved exception or a decision record that changes the target. The target is reviewed on a fixed cadence, quarterly for most estates, against what was actually built. And lessons from solution architectures flow back, so that a pattern that failed in delivery is removed rather than repeated.

Lineage is a useful audit of whether the architecture is real. If data lineage shows flows the target does not describe, either the target is out of date or teams are working around it, and both are worth knowing.

#When a Reference Architecture Is the Wrong Starting Point

What this means for you: for some estates, a reference architecture adds ceremony without reducing risk, and a lighter approach serves better.

A small team running one platform for a handful of use cases rarely needs a formal reference architecture. A one-page set of principles, a few decision records and the platform vendor's own guidance will carry them further than a framework exercise.

It is also the wrong place to start when the real problem is ownership. If two departments dispute who owns customer data, a better diagram will not settle it; an operating-model decision will. And when a platform choice is genuinely open, a time-boxed comparison on real workloads produces more evidence than another layered drawing. In those cases, start with the decision that blocks progress, record it, and let the architecture document grow from decisions rather than the other way round.

Write the decisions first; the diagram can follow.

#Where to Start

What this means for you: a usable target architecture can be produced in weeks, provided the scope is the decisions that block delivery rather than a complete enterprise model.

Start by gathering whatever reference material exists and marking each element as generic advice, a decision already made, or a gap. Then record the five to ten decisions that currently block delivery, each in the decision-record format with a named owner. Add numbered quality targets for the two or three domains that matter most, and agree who reviews designs against the result.

Scope matters here. That first pass produces a target architecture for the decisions in front of you, not a complete enterprise model; extending it across every domain is ongoing work that should follow the roadmap. Our architecture blueprint service runs this first pass, our data architecture practice carries it into domain models and contracts, and our enterprise data platform builds implement it.

#Frequently Asked Questions

#What is a reference data architecture?

A reference data architecture is a reusable pattern describing the capabilities a data platform needs, such as ingestion, storage, transformation, serving, governance and operations, along with principles, approved patterns, quality targets and recorded decisions. It is generic by design. Organisations get value from it by tailoring it into a target architecture that reflects their own constraints, choices and ownership.

#What is the difference between reference and target architecture?

A reference architecture is generic and reusable across organisations, describing what a class of platform typically needs. A target architecture is specific to one organisation: it removes what does not apply, makes the product and pattern choices the reference leaves open, and states the end state the estate is moving towards. Design reviews should test proposals against the target architecture.

#What is an architecture decision record?

An architecture decision record is a short document capturing one significant decision: its title, the context and forces involved, the decision taken, its status and its consequences, including negative ones. Michael Nygard proposed the format in 2011. It lets a team explain why a choice was made and supersede it cleanly when circumstances change.

#How often should a target architecture be reviewed?

Quarterly suits most data estates, alongside a review of every significant new design against it. Each deviation should become either an approved exception or a decision record that updates the target. Reviewing what was actually built, for example by comparing data lineage with the documented design, shows whether the architecture is still describing reality.

#Do small teams need a reference architecture?

Usually not in a formal sense. A small team running one platform for a few use cases is better served by a one-page set of principles, a handful of decision records and the platform vendor's guidance. A fuller reference architecture earns its cost when several teams build on shared infrastructure and need common rules to avoid diverging.

Unolabs is a Data and AI first engineering consultancy, headquartered in the United Kingdom with engineering operations in Pune and active engagements across the UK, Australia, and Hong Kong. We help enterprises build the architectural foundation for autonomous AI execution — governed data platforms, semantic intelligence, and agentic systems that enterprises can stand behind.

If you are weighing how to turn a reference architecture into one your teams can build against, book a discovery call and we will work through it with you.