A data platform is worth exactly what the decisions it changes are worth, and most of the ones we see change none. Warehouses, lakes, lakehouses, dashboards: the technology usually works fine. The insight just never arrives when someone is choosing. This post covers why, how to build backward from the decision, what makes a number trustworthy, and where the Saudi rules bite.
Four ways a data platform fails, and none of them is the database
In our experience the post-mortem almost never names the technology. It names one of these.
- Built with no decision in mind. The brief was “centralize the data.” Nobody asked which decisions were supposed to get better, so the platform became a tidy warehouse of numbers nobody acts on. The roadmap gives it away: sources, not questions.
- Garbage in, dashboards out. If the data is inconsistent, duplicated, or untrusted, no visualization saves it. People check one figure against the source system, find it wrong, and quietly stop believing all of them. The same root cause shows up in AI work: Gartner predicts at least 30% of generative AI projects will be abandoned after proof of concept by the end of 2025, and poor data quality is the most-cited reason (Gartner, 2024).
- Nobody owns it. Data without a named owner drifts. Someone has to answer for quality and definitions, or “revenue” means five things in five reports.
- The insight never reaches the decision. A correct number in a dashboard nobody opens changes nothing. The last mile, getting the right insight to the right person at the moment they decide, is where most of the value is won or lost, and it is what most budgets leave for “phase two.”
None of the four is about the database. They are about the gap between the data and the choice.
Start from the decision, not the data
This is the whole reframe. Don’t begin with “what data do we have, let’s pile it somewhere.” Begin with the decisions the business makes over and over, then work backward to the data they need, the platform people will trust, and the delivery that puts the insight in front of the person choosing. Build in that order and the technology choices get clearer.
flowchart LR A(["A decision you make again and again"]) --> B(["The data that decision actually needs"]) B --> C(["A platform people trust: owners, definitions, lineage"]) C --> D(["Insight that lands where and when you decide"]) D -->|did the decision get better?| A
“A decision you make again and again” looks like: which branches get restocked this week, which overdue customers get a call, which tender to bid on. Write a page per decision: who decides, how often, what they look at today, what they wish they could see. No page, no ingestion.
What makes a number trustworthy
A number earns trust when four things are true, and each is a document or a role, not a feature you buy.
- One definition, written down. A data dictionary that says what “active customer” and “net revenue” mean, with the rule attached. When finance and sales disagree, the dictionary wins.
- A named business owner per metric. Not the data team. The head of sales owns pipeline; the CFO owns revenue. The owner answers for whether the number is right.
- Lineage you can follow. Any figure on a dashboard can be traced back to the source system. Refuse to publish a metric without it.
- A freshness promise. “Updated nightly by 06:00,” printed on the dashboard. A stale number with no timestamp is worse than none, because people act on it.
flowchart TD
M(["A metric someone wants on a dashboard"]) --> Q1{"Definition written down?"}
Q1 -->|no| R(["Back to the owner. Not published."])
Q1 -->|yes| Q2{"Named business owner?"}
Q2 -->|no| R
Q2 -->|yes| Q3{"Lineage traceable to source?"}
Q3 -->|no| R
Q3 -->|yes| P(["Published, with a freshness promise"])
Gate it this hard and the platform carries fewer metrics. That is the point: twenty numbers people believe beat two hundred they argue about.
A worked example: the weekly restock decision
The numbers here are made up to show the shape. Say you run 40 retail branches from one distribution center. Every Sunday a planner decides what to ship to each branch, working from a three-day-old sales export, a week-old stock count, and memory. It takes most of her day, and call it 15% of inventory sits where it won’t sell while other branches run out.
Build backward. The decision: what to ship, per branch, per week. The data: eight weeks of sales by SKU by branch, current stock per branch, inbound deliveries, the promotions calendar. Four sources, not forty. The trust layer: one definition of “sold” (net of returns), the retail director as owner, a nightly refresh by 06:00. The delivery: not a dashboard, but a Sunday-morning list of suggested quantities per branch that the planner adjusts in an hour.
If that brings misplaced stock from 15% to 10% on, say, SAR 20 million of inventory, that is SAR 1 million of working capital freed, plus fewer stock-outs and a planner with a day back. Four tables, one output. The platform that “centralizes everything” would take a year to reach the same four tables and might never produce the Sunday list.
The Saudi layer: where the data is allowed to live
In the Kingdom, a data platform is also a compliance object, because it concentrates personal data. Three things to settle before the first table is built.
- PDPL applies to the platform, not just the source systems. The Personal Data Protection Law took effect on 14 September 2023, full compliance was required by 14 September 2024, and SDAIA is the regulator (Morgan Lewis, 2024). Copying CRM records into a warehouse is a new processing activity with its own purpose, retention rule, and access controls. Our practical guide to PDPL compliance covers the engineering view.
- Cross-border transfer is a design decision. Transfers out of the Kingdom are governed by Article 29 of the PDPL and SDAIA’s Transfer Regulations, updated in September 2024. A warehouse hosted abroad, or a SaaS analytics tool that copies data abroad, is a transfer whether anyone meant it or not. Decide the region first; see choosing a cloud strategy with data residency first.
- Access is per role, per column. Mask national IDs and phone numbers by default, grant by role, log who queried what. SAMA-supervised firms and healthcare providers on NPHIES have their own rules on top; treat them as design inputs, not a final review.
The warehouse is also the company’s most valuable target. IBM put the average cost of a data breach in the Middle East, a Saudi and UAE sample, at $8.75M in 2024, the second-highest region after the US (IBM via The National, 2024).
Where data platforms go wrong
The traps are the same every time, and all of them are expensive.
- Building for a scale you will never hit. Real-time, petabyte architectures for a company whose decisions are weekly and whose data fits on a laptop. Architect for actual use.
- “Phase one is ingestion.” A year of pipelines with nothing on the other end. By the time a dashboard appears the sponsor has moved on. Every phase should end with a decision that got better.
- Buying the tool before the question. Warehouses, BI suites, and “AI-ready data” platforms are sold hard in Riyadh. The tool is rarely the constraint; ownership and definitions are.
- Calling it the AI foundation before the trust work. A model pointed at untrusted data produces confident, wrong answers faster. If you plan to use your own company data with AI, the trust gate above comes first.
How to start: one decision, one metric, one owner
The pattern that works is boring and reliable. Pick one recurring decision with a frustrated decision-maker and a measurable outcome. Write the one-page brief. Identify the three to five sources it needs and no more. Assign a business owner per metric and write the definitions down before anyone writes SQL. Build the smallest platform that delivers the answer where the decision happens. Run it for a month alongside the old way and measure whether the decision got better in its own units: stock-outs, days sales outstanding, tender win rate. If it did, take the next decision. If not, you learned something for the price of four tables.
That measurement step is where an independent review earns its keep: someone outside the vendor relationship checking that the platform is anchored to decisions, the definitions hold, and the compliance layer is real. That is what our technology assessment and digital transformation engagements do before a large data spend.
Built a data platform that isn’t changing any decisions, or about to build one? SDCG designs data platforms backward from the decisions they’re meant to inform, then builds them to be trusted and actually used. We’re independent, so we’re not steering you toward anyone’s product. Book a free 30-minute review.