Case Study · MIRQAB «مرقاب»
How a request for an “outcome dashboard” becomes a working solution: dispersed programme data, consolidated into one trusted model, kept current automatically, traceable back to source, and explained in plain language.
An end-to-end design for an outcome-focused monitoring solution — the data pipeline and governance architecture that takes scattered programme data and turns it into a dashboard decision-makers can actually trust and use.
Most organisations don’t lack data — they lack usable data. It sits across disconnected systems, in different formats and refresh cycles, and by the time it reaches a report, nobody is sure where the numbers came from or whether to trust them. Activity gets counted; outcomes don’t.
A current, trusted, explainable outcome dashboard — and, more importantly, a repeatable method for turning any business question into a governed, automated pipeline that keeps producing value long after the first build.
01 — The problem
A programme organisation operating across several locations wanted to move beyond activity and output reporting — counts of what had been delivered — towards outcome-focused monitoring: a clear, near-current view of whether the work was actually making a difference. Senior decision-makers needed a single dashboard that brought dispersed programme information together, expressed it against outcome indicators, and surfaced what the numbers meant in plain language — so reviews and course-corrections could be made on evidence rather than impression.
The real obstacle was not visual design. The relevant data did not live in one place: it sat across separate operational systems, in different formats and structures, refreshed on different cycles, and maintained by different teams. Producing the dashboard meant building a reliable path from those scattered sources to a trustworthy view — and building it so it could be repeated for each location and rolled up to an organisation-wide picture.
02 — Approach
The guiding principle is to design backwards from the decisions the product must support. Before any extraction or modelling, I establish with stakeholders which questions the dashboard has to answer, which outcome indicators matter, and at what cadence decisions are taken. Every technical choice downstream — what to ingest, how to model it, which measures to compute — then traces directly to one of those needs. This keeps the solution lean and ensures what gets built is what gets used, rather than what was easiest to assemble.
03 — Translation
The first concrete step is to translate stated business needs into technical implications. Each requirement drives a specific component of the design.
04 — Solution architecture
A pipeline that moves information from raw, dispersed sources to a governed, decision-ready dashboard. Each stage maps to a specific requirement above.
05 — Walkthrough
Inventory the available sources and what each holds — effectively a small data catalogue. Establish which fields exist, who owns them, how they are defined, and where the outcome-relevant data lives, before a single record is moved.
Bring data in API-first where a source exposes a stable interface, and through scheduled, structured extracts where it does not. The method is chosen per source, so the pipeline adapts to what each system supports rather than assuming one mode.
Incoming data lands in a staging area and passes a quality gate: schema and type checks, completeness and range validation, de-duplication. Records that fail are quarantined and reported rather than silently dropped, so quality is observable from the outset.
Validated data is cleaned, standardised and joined across sources, and the outcome measures the business asked for are derived to agreed definitions. This is where raw operational data becomes analysis-ready.
The data is organised into a star schema — outcome fact tables surrounded by descriptive dimensions (location, time, programme area, population group) — making it efficient to query and intuitive to slice.
Business logic is expressed once, centrally, as reusable measures. Defining outcome calculations in a single semantic layer means every visual draws on the same agreed definition — the technical guarantee behind a single source of truth.
The dashboard presents outcome KPIs with drill-down from the organisation-wide view to individual locations — designed around the decisions identified at the start, not around the data that happened to be available.
A proportionate AI layer generates plain-language narratives of what the data shows and flags anomalies for attention. Applied augmentation for faster reading of the numbers — not bespoke model development — turning a chart into an insight a busy decision-maker can act on.
The whole sequence is automated and scheduled, so the dashboard stays current without manual rebuilds, and parameterised so the same pipeline runs for each location and consolidates upward — the choice that lets a single-site prototype scale to an organisation-wide product.
06 — The spine
Running through every stage is a governance spine. Validation rules at ingestion and staging make quality measurable; defining measures once in the semantic layer enforces a single source of truth; and because each transformation is explicit and documented, the lineage of any figure can be traced back through every step to its origin. If a decision-maker asks where a number came from, the pipeline can answer — which is what makes the output trustworthy enough to act on.
07 — Platform realisation
How the governance spine is realised on a modern data platform. This section is a target / reference architecture — a design for how the solution would be implemented on Microsoft Fabric, where governance is built into the platform rather than bolted on.
On Fabric, every workload reads and writes a single copy of data in OneLake, the tenant’s unified lake, in open Delta-Parquet format. The pipeline lands as a medallion flow — raw bronze, cleansed silver, curated gold — and Power BI reads the gold model directly in Direct Lake mode, with no extra copy. Because all data passes through OneLake, governance can apply uniformly across the estate.
The architecture uses two governance surfaces for two different jobs — and knowing which to use when is the point. The OneLake catalog handles technical governance natively inside Fabric (no Purview required): domains, endorsement of trusted assets, sensitivity labels, access control and in-Fabric lineage. Microsoft Purview is added when governance must scale across the whole enterprise: a business-facing Unified Catalog, automated end-to-end lineage from source to report, classification and DLP, data-quality scanning, audit, and governance of the AI/Copilot layer.
08 — Scale
Because the pipeline is parameterised and templated rather than hand-built for one location, the same solution extends to additional sites with minimal rework and rolls individual views up into a consolidated, organisation-wide picture. Building for scale and consolidation from the first prototype — rather than retrofitting it later — is what allows a proof-of-concept to become a sustainable, repeatable product.
09 — Stack
A dashboard decision-makers can trust and use: outcome indicators consolidated from dispersed sources, kept current automatically, traceable back to source, explained in plain language, and built to scale. The deeper deliverable is the method — a repeatable way to turn a business question into a governed, automated pipeline that keeps producing value long after the first build.