The hardest part of a data warehouse is getting several departments to agree on what a number means and who is allowed to change it. The pipeline was the more familiar problem.
The problem
As an IT consultant, I worked with municipal departments that had valuable information spread across existing software, historical records, and disconnected reporting processes. The goal was practical: give staff a dependable view of their data without forcing a disruptive replacement of every system.
Each department had its own vocabulary and its own idea of the source of truth. HR cared about one set of definitions; event management cared about another. A generic dashboard would have looked tidy and been useless. The reporting had to reflect how people actually made decisions.
The build
I designed a cloud data-warehousing solution around the existing application landscape. Azure provided the cloud foundation, while Office 365 and Power BI made the reporting layer accessible in tools already familiar to staff. The work included integrating source systems, digitising and migrating historical data, and building the structures needed to keep reporting consistent across departments.
I worked with department heads and IT staff to refine the reports through feedback and user testing. That collaboration mattered because self-service reporting only works when people can understand and trust the data behind it. The project moved through needs assessment, architecture and migration planning, implementation, and end-user training.
The design had to accommodate two kinds of change: scheduled changes to the warehouse and the less predictable changes in departmental questions. I kept the transformation logic explicit so a report owner could trace a number back to its source instead of treating the dashboard as a black box.
Data quality was the part that could quietly sink the project. We added checks around missing values, duplicate records, and changed source formats, and made refresh failures visible to the people who owned the reports. That work was unglamorous. It was also the difference between a dashboard people trusted and one they checked against a spreadsheet before every meeting.
The result
We delivered a cloud data warehouse and department-specific Power BI reporting for municipal staff. The lasting value came from more than the warehouse: it established a repeatable way for the administration to turn operational data into usable information.
What I took from it
Looking back, I would define data ownership, automated quality checks, and refresh monitoring more explicitly from the start. Those concerns are easier to design into a warehouse than to add after departments begin relying on it.
This project gave me an early foundation in cloud data architecture and showed how technical choices must fit the people and processes around them. A warehouse is successful when a department can act on it without asking the consultant what the number means.