An institution of 8,500 people, responsible for emergency response across a capital city, decided it wanted to be data-driven. The gap between that sentence and a working data warehouse is where I spent two years.

The number that defines the problem

The brigade's data did not sit in a handful of systems. It sat in an application landscape of roughly 250 information systems — accumulated over decades, bought or built by different departments for different reasons, each with its own owner, its own access rules and its own idea of what a date field means.

That single number reframes the work. Dimensional modelling is the part you can learn from a book. What you cannot learn from a book is how to integrate a landscape nobody owns centrally: finding who actually controls a system, establishing whether its data means what its column names claim, and doing that again for the next one, and the next.

Domain by domain, not big-bang

The warehouse was built one operational domain at a time rather than as a single programme: emergency interventions, human resources, working-time management, medical and physiological records, stock and equipment management — seven and more by the end, each with its own ETL flows feeding the model.

Sequencing it this way is not a compromise, it is the strategy. Each domain that lands produces reports people use, which produces the credibility to negotiate access to the next one. A two-year big-bang programme in an institution like this produces nothing anyone can see until it is too late to correct.

flowchart LR
    SRC[~250 source systems<br/>interventions · HR · working time<br/>medical · stock and equipment] --> ETL[SSIS ETL flows<br/>one domain at a time]
    ETL --> DWH[(Enterprise<br/>data warehouse)]
    DWH --> BI[Power BI teams<br/>reporting]
    ETL -.-> MON[Load-job indicators]
    MON -.-> OPS[Anomalies to clear,<br/>not silent gaps]

The part I added that nobody asked for

A data warehouse fails quietly. A loading job that stops does not throw an error at anyone; it simply stops refreshing, and the reports built on it keep rendering — with yesterday's numbers, then last week's. The failure surfaces days later, as a person in a meeting saying a figure looks wrong. By then the damage is not the stale number, it is the trust.

So I built a set of internal indicators over the loading jobs themselves: what ran, what did not, what fell behind. Not a dashboard for executives — an operational surface for the people running the platform, where a failed load appears as an anomaly to be cleared rather than as a gap nobody sees.

Nobody specified this. It came from the observation that in an institution that dispatches vehicles on data, a reporting layer people stop trusting is worse than no reporting layer at all.

Making it survive me

The second unrequested piece was written: an internal wiki for the BI practice — conventions, usage, the reasoning behind the model — so that someone arriving into a very specific domain could become productive without an oral tradition.

That matters more in a public institution than in a company. People rotate through posts on their own cycles; the person who inherits your work may arrive two years after you left, with no handover. Documentation is the only channel that reaches them.

I ended up as the internal technical referent on the Microsoft BI stack, consulted on structuring technical choices, and mentoring apprentices on delegated projects. That is a consequence of the wiki as much as of the code: being the person who wrote down how it works makes you the person people ask.

A data team of former firefighters

The part of this job I would take again without hesitation: helping build and lead a data team that included former firefighters retraining into technical roles.

I am one of them. I served seven years as an operational firefighter before teaching myself to code, and I know exactly what that transition costs — the imposter feeling on the first SQL query, the sense that everyone else started earlier. What that background buys, once the technical gap closes, is people who know what an intervention actually is. They do not need the domain explained. They spot an implausible figure in a dataset because they have lived the operation it describes.

Upskilling them was slower than hiring engineers who already knew the stack. It also produced a team that understood the business better than any external hire would have.

What I would defend in an interview

That the monitoring indicators mattered as much as the warehouse. The model, the ETL, the dimensional design — that is the visible work, and it is genuinely necessary. But the thing that decides whether an institution becomes data-driven is not whether the warehouse exists; it is whether people still believe its numbers eighteen months later. Everything I built that nobody asked for was aimed at that.

The second thing: shipping domain by domain against pressure to promise the whole landscape. Two hundred and fifty systems is a number that invites a five-year roadmap. Seven domains that people actually use beats a roadmap that covers everything and lands nothing.

A written reference from the brigade's BI lead, describing this work, is available on request.

Stack: SQL Server · SSIS · T-SQL · Power BI · Master Data Services · PowerShell