Do you need a data warehouse—or an answer by Friday?

The decision before the database

An operations director wants to know which client reviews are overdue. The proposed answer is a data warehouse.

Perhaps it is the right answer. But there are several unanswered questions between the request and the architecture: what counts as overdue, where the relevant dates live and whether the status in the source system is reliable.

Our position is that an advice firm should define the decision first, then choose the smallest data arrangement capable of supporting it. Central storage can help. It cannot settle a disputed definition by itself.

If the question concerns the current state of one well-managed application, an existing report or controlled export may be enough. If it requires joining several sources or reproducing historical positions, a separate reporting store may become more useful.

History is an especially revealing test. A current client record may show today's adviser and service status. A management question about an earlier period needs to know what those fields were then, or what reliable evidence can reconstruct them.

Write that requirement explicitly. Otherwise a warehouse project may faithfully copy current records while still failing to answer the historical question that justified it.

The ICO's accuracy guidance recognises that a historical personal-data record can remain accurate even after circumstances change, provided its status is clear. This distinction matters when designing a reporting store: preserve what a dated record represents instead of treating every later change as a reason to erase the earlier position.

Resolve definitions before aggregation

An overdue-review measure needs an agreed population, expected service, relevant date and treatment of exceptions. If teams interpret those differently, aggregation makes the disagreement look like one clean number.

The FCA's Consumer Duty board-report findings stress the need for data that supports conclusions about outcomes. They do not require advice firms to buy a warehouse. The architecture should be justified by the evidence the firm actually needs.

Keep the measure definition beside the report. Include the source fields, exclusions, refresh timing and known limitations. A reader should understand what a movement in the number might mean before treating it as a change in performance.

Prove the answer, then assign the owners

Choose one management question and produce a repeatable answer using a representative slice of data. Record the manual work needed to reconcile identities, interpret statuses and correct source issues.

That exercise helps separate three jobs: fixing records, agreeing business definitions and moving data. Only the third is primarily a storage-and-integration problem. Buying infrastructure for all three can create an expensive waiting room for unresolved decisions.

Test the answer with the people whose work it describes. Ask them to trace a few reported cases back to evidence. Investigate discrepancies rather than averaging them away.

If a reporting store is justified, assign owners for source quality, transformations and metric definitions. Decide how corrections reach both historical reports and live operational records where appropriate.

Keep access proportionate to purpose. A consolidated store may bring information together that was previously separated, so review who can see what rather than copying every source permission assumption into a broader dataset.

Plan how users learn that a refresh failed. Yesterday's report presented as today's can be more misleading than an unavailable report with a clear explanation.

A warehouse should make important questions easier to answer repeatedly and consistently. If the firm cannot yet specify one such question, spend the next week defining it and tracing the evidence. That work remains useful whichever technology comes next.