Reports and data models built for the people reading them, not just the people who asked for them.

The client's global BI team needed dashboards stakeholders could actually act on, but requests were mostly arriving secondhand rather than gathered directly. Two specific workflows were eating disproportionate time: a monthly report that took about two weeks to put together, and a scheduling metric that only surfaced once someone had already noticed something was wrong.

I embedded with the client's global BI team, working directly with the Director of Global BI, and made a point of sitting in the stakeholder meetings myself instead of working off a handed-down spec. Data flows through a medallion architecture in Snowflake, with dbt handling transformation and Git version control gating every promotion between layers, so nothing reaches a dashboard without another BI team signing off first. On top of that foundation, I built two AI agents: one to fully automate the two-week report, and one to flag the scheduling metric (tracked internally as NBOT) in real time instead of waiting on a manual Power BI pull. I also shipped a Streamlit tool so end users could generate and adjust their own reports without routing every variation back through the BI team.

The monthly report cycle dropped from about two weeks to a few minutes, a reduction of over 99%. The scheduling issue that used to surface after the fact now gets flagged as it happens, and self-service reporting cut down the volume of one-off requests reaching the BI team directly.

Data lived across more than 10 disconnected source systems with no single governed structure. Answering even a basic cross-system question meant reconciling data by hand each time, and historical changes weren't being captured, only the latest state, so nothing could be traced back over time.

I designed a Bronze-Silver-Gold medallion warehouse to consolidate every source into one governed structure, and built the ETL pipelines in Azure Data Factory and Databricks, backed by SQL stored procedures. I implemented slowly changing dimensions so every historical change to the data gets captured instead of overwritten, layered in a simulated real-time streaming pipeline to support organism tracking for the research team, and put automated validation checks across the pipeline to catch issues before they reached a report.

Over 99.9% pipeline uptime, and a data model where historical changes are preserved and queryable instead of lost the moment new data lands.

Local authorities were making decisions off after-the-fact reports. Batch data from government sources arrived too slowly to be useful for anything happening in the moment, but a purely real-time system on its own wouldn't preserve the historical batch data needed for trend analysis.

I built a Lambda architecture combining both layers: a batch layer ingesting government source data, and a real-time layer processing live public API feeds through Azure Event Hubs and Databricks Structured Streaming into Delta Lake. That gave the system both the completeness of batch and the immediacy of streaming in one place. Power BI sat on top for the trend view authorities actually used day to day.

Over 2 million streaming events processed daily, under a minute of latency from event to insight, and a 60% improvement in local operational planning once authorities had predictive alerts instead of after-the-fact reports.

Retention strategy was being built off a blended, average view of the customer base, which meant effort wasn't targeted at the segments actually worth saving or most at risk of leaving.

I segmented over 20,000 customers by behavior and value using SQL, then built executive scorecards in Power BI tracking retention KPIs, satisfaction trends, and service-channel performance, so senior stakeholders could see exactly where to focus instead of working off one blended number.

A 15% lift in retention once the scorecards pointed the team at specific, targetable segments.

I inherited a reporting query that joined 13 tables directly out of the staging layer in a single pass. It was technically correct but slow, and dense enough that nobody besides the person who wrote it wanted to touch it, which meant every new reporting need risked re-deriving the same logic from scratch instead of reusing it.

I rebuilt the monolithic join as a set of reusable fact and dimension views in Snowflake, so the logic that used to live in one dense query now lives in named, purpose-built pieces that map to how the business actually thinks about the data, facts and dimensions, rather than a wall of raw joins.

Faster queries, and dimension views that now get reused across other fact tables instead of every new report re-deriving the same joins from scratch.

Analyzing historical and intraday stock data for price trends, volume spikes, and sector performance was a manual process. A broader effort to automate African stock market data processing was also blocked by source exchanges still publishing in legacy .xls formats that don't fit cleanly into a pure cloud pipeline.

I ran the trend analysis directly in SQL to surface price movement, volume, and sector patterns. For the broader automation effort, I scoped the problem through detailed business analysis and proposed a hybrid cloud/desktop architecture specifically to handle the legacy .xls requirement, instead of forcing a cloud-only design the source data couldn't actually support.

A scoped, hybrid architecture proposal that accounts for a legacy format constraint a cloud-only approach would have missed.