What data platform do you actually need?

Data architecture advice is mostly written by and for very large organisations. Applied at a tenth of that scale it produces a platform that is expensive, needs specialists to operate, and answers questions nobody is asking.

Start from the disagreement

The useful starting point is not a tooling decision. It is the list of numbers people currently argue about. Trace each one back to source and find the fork — a different filter, a different date boundary, a different definition of an active customer.

Half the value of a data platform is available before you buy one, by writing the definitions down and agreeing them.

Size it for the team you have

A warehouse, a scheduled transformation layer and a BI tool handle an enormous range of organisations. Streaming, a lakehouse, a semantic layer and real-time ingestion solve genuine problems that most mid-sized companies do not yet have.

The question worth asking of any component is who operates it on the Friday the person who built it is on leave.

Define metrics once

The single highest-return practice is computing each metric in exactly one place and pointing everything at it. It is unglamorous, it is mostly writing things down, and it eliminates the category of meeting where the subject becomes the dashboard.

Treat the models like code

Version control, review, tests and a staging environment apply to transformation logic exactly as they do to application code. Data pipelines that are edited in a web console drift, and the drift is only discovered when somebody notices a number looks wrong.

Decide what the platform is for

Before any of it, write down the decisions the data is supposed to inform. If a dashboard would not change what anybody does, it does not need building, and a surprising number of them do not survive that question.