The real cost of ignoring a data warehouse
There is no clever trick in this one, just a handful of decisions worth making deliberately. Nobody bills you for neglecting a data warehouse. The cost shows up somewhere else.
Numbers get quoted in meetings long after anyone remembers how they were calculated. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.
Where the cost lands
- Time spent on work that should not have been necessary
- Enquiries that quietly never arrive
- Reporting queries and application queries want different shapes
- Rework, once the problem is finally visible
Separating them stops reports taking the product down. The cost of getting this wrong is rarely visible on the day it happens. Doing this properly once is usually cheaper than doing it approximately three times.
Where to go from here
Start with the questions, not with the schema. Small and consistent beats large and occasional here. It is the sort of thing that looks like polish right up until it costs you an enquiry.
How to tell if yours is fine
Most data problems are ownership problems that turned into technical ones. Three things worth confirming about a data warehouse before you move on:
- Someone can say what the current setup is without going to look
- Start with the questions, not with the schema — and you know whether that is true here
- There is a way to tell whether the last change to this helped
Most of the value here comes from doing the first two things, not all of them.