Analytics & BI Tools · Chapter 1 of 18
The analytics stack, and what each tool is for
Four layers. Most tool arguments are really arguments about which layer owns the metric definition.
Analytics tooling looks crowded because several products span several layers and market themselves as covering all of them. Separate the layers first and the choices become tractable.
What each layer is actually for
- Store — the warehouse or lakehouse. Covered in its own book here.
- Prepare — cleaning, joining, shaping. Historically ETL tools; now mostly SQL transformation in the warehouse, with visual tools where the users are analysts rather than engineers.
- Model — the semantic layer, where a business concept gets one definition. The most under-appreciated layer and the one that decides whether your numbers agree.
- Visualise — where business users live. Highly visible, and the least consequential of the four for whether the numbers are right.
The question that cuts through every tool comparison
“Where is active customer defined, and can a dashboard author override it?”
If the answer is that anyone can redefine it in a report, you will have as many definitions as you have reports, and no tool choice fixes that. If it is defined once in a modelled layer that reports must consume, most governance problems disappear regardless of which visualisation tool sits on top.
How to actually tell these tools apart
Feature comparisons between business-intelligence tools are nearly useless, because every tool has every feature. The distinctions that predict whether a tool will work for you are architectural, and there are four.
| Question | Why it decides everything downstream |
|---|---|
| Where does the modelling live? | In the tool, or in the warehouse? Tool-side modelling is fast to start and produces logic only that tool can see. Warehouse-side modelling is slower and portable, and every consumer agrees |
| Does it import data or query in place? | Import is fast and stale, with a refresh window and a size ceiling. Query-in-place is always current and pushes cost and latency to the warehouse — where it is at least visible |
| Is the metric definition central or per-report? | The single biggest predictor of whether numbers agree across the organisation. Per-report definitions guarantee that two dashboards disagree and nobody can say which is right |
| Who is the intended author? | An analyst, or anyone? Self-service breadth and governed consistency trade against each other, and no tool has solved it — vendors that claim both mean 'anyone can author, in a sandbox' |
The pricing shapes matter more than the rates, because they determine who is allowed to look at data. Per-user pricing discourages broad access, which quietly recreates the reporting bottleneck the tool was bought to remove. Capacity pricing encourages access and surprises you when a heavy workload lands. Consumption pricing tracks value and makes budgeting hard. Pick the shape that matches how you want people to behave, then negotiate the rate.
And the migration reality worth stating before any evaluation: moving between these tools is expensive not because of the visuals but because of the logic embedded in them. Hundreds of report-level calculations, each slightly different, none documented. This is the strongest practical argument for pushing definitions into the warehouse regardless of which tool you pick — it is the only part of the investment that survives the next procurement cycle.
Check yourself