The decisions that destroy software budgets in Saudi companies are almost never bugs: they are the architecture choices made quietly in the first weeks of a project, still load-bearing years later, when reversing them means rebuilding under a live system. This post covers what a software architecture review examines, which decisions we open first, what the wrong ones cost, how PDPL and the NCA’s ECC controls make some of them compliance questions in the Kingdom, and how to run a review in two weeks before you sign a build contract.
What does a software architecture review examine?
An architecture review is not a code audit and not a security scan. It is a structured look at the decisions that are expensive to reverse, done before the money is committed. Most decisions are cheap: which logging library, which frontend framework, pick one and move on. The review exists for the other kind, and its entire method is telling the two apart.
flowchart TD
A(["Inventory every decision in the design"]) --> B{"Cheap to reverse?"}
B -->|"Yes"| C(["Accept it and move on"])
B -->|"No"| D(["Deep-dive: data model, integration contracts, platform, boundaries"])
D --> E{"Survives real integration and Saudi compliance rules?"}
E -->|"Yes"| F(["Write the one-page decision record"])
E -->|"No"| G(["Change it now, while it is still a drawing"])
The output is a short stack of one-page decision records: what was chosen, what was rejected, and what would make us revisit it. In our experience it is the cheapest artifact a project can produce, because it moves arguments that would otherwise happen in year two, as change orders, into week four, as text.
Which decisions does the review open first?
- The data model. How you structure customers, orders, patients, or payments sets the cost of every future feature. A model that does not match how the business runs forces every screen, report, and integration to translate between what the business means and what the database says, for years. It is usually the highest-stakes decision in the design and the one that receives the least deliberation.
- The integration contracts. In the Kingdom these are rarely negotiable. The ERP exports on its own schedule, government platforms define their own message shapes, and in healthcare the national health information exchange NPHIES, built on HL7 FHIR, fixes the shape of patient and encounter data. Treat integration as a phase-two detail and you meet this reality all at once.
- The platform you cannot leave. Which cloud region, which database engine, which proprietary layer on top. Some exits are exits in name only, and where personal data lives is a compliance question we come to below.
- The service boundaries. How the system is divided into parts decides whether three teams can work without colliding and whether one part can be replaced without replacing all of them. Split too early, before anyone understands the domain, and you buy distributed-systems pain you never needed.
What does the wrong decision cost?
The pattern is consistent: nothing, then friction, then a cliff. A convenient choice feels free in week two; the bill arrives years later, paid in delivery speed, by whoever inherits the project.
flowchart LR A(["Week 2: the choice costs nothing"]) --> B(["Month 6: the first workarounds appear"]) B --> C(["Year 1: every feature pays a translation tax"]) C --> D(["Year 2: delivery slows to a crawl"]) D --> E(["Year 3: rebuild the foundation, under a live system"])
The aggregate evidence is blunt. McKinsey and Oxford studied more than 5,400 IT projects and found that large IT projects run on average 45% over budget, 7% over time, and deliver 56% less value than predicted, and that 17% go so badly they threaten the company’s existence (McKinsey, 2012). Not all of that is architecture. But in our experience, when a project in the Kingdom runs a year late, the cause is usually a decision from month one that everyone is now working around.
A worked example: the NPHIES integration deferred to phase two
Here is that cliff with numbers attached; the numbers are made up to show the shape. A clinic group in Riyadh commissions a patient platform. At kickoff the team designs its own patient, appointment, and billing tables, and marks the NPHIES connection as phase two, an integration to handle later. Phase one goes well.
Phase two arrives. NPHIES speaks HL7 FHIR, so every clinical entity now needs mapping between the platform’s private shapes and the national resource shapes, and the mapping is not a corner of the system: appointments, encounters, coverage, and reporting all sit on it. Say the team is five engineers and was shipping twelve meaningful features a quarter. Through the integration period two of the five do nothing but mapping and rework, throughput falls to five features a quarter, and the remap runs eight months. The platform meets its business case roughly a year late, at payroll cost alone in the millions of riyals, none of it budgeted under the word architecture.
The decision that caused it took one afternoon: designing the data model without the national contract in view. Building to the FHIR resource shapes from day one costs little and removes the second tax entirely. We have watched the same shape with an ERP’s nightly exports.
Where architecture reviews go wrong
A review before commitment is the cheapest insurance a project can buy, and it still fails in the same four ways.
- The deck gets reviewed instead of the design. A vendor’s architecture slides are a sales document. If the review does not open the actual data model, integration contracts, and deployment plan, it is auditing marketing.
- The builder marks their own homework. The team that proposed the design is the least able to see its failure modes. Independent eyes before acceptance are worth more than any post-mortem after go-live.
- Elegance gets scored instead of reversibility. The right question is not “is this modern?” but “what does undoing it cost?” Some of the plainest designs we have reviewed were sound, because every unglamorous part was cheap to replace.
- The review happens after signature. Once the contract is signed, every design change is a change order. The review belongs between winning proposal and committed budget; for government work procured through Etimad, that gap is the last moment the design can change cheaply.
How do PDPL and NCA ECC change the picture in Saudi Arabia?
Two Saudi regimes convert some architecture decisions into compliance decisions, which raises the price of getting them wrong from expensive to regulated.
Personal data location is the clearest case. The PDPL took effect 14 Sept 2023 and full compliance was required by 14 Sept 2024, SDAIA is the regulator, and cross-border transfer is governed by Article 29 and SDAIA’s Transfer Regulations (Morgan Lewis, 2024). Whether a dataset may leave the Kingdom is decided by where the design puts it, which makes the week-two hosting choice a legal question. Retrofitting a transfer mechanism onto a system that assumed borderless storage is its own project.
For regulated entities the NCA’s ECC controls push the same way: in our experience segmentation, logging, and access control are architecture-level structures, cheapest when drawn in and most expensive when bolted on afterwards. Health operators get a third constraint, because NPHIES fixes part of the integration contract up front. The engineering side of the PDPL is covered in our practical PDPL guide for technology leaders; the point here is that the review checklist and the compliance checklist overlap, and a review that ignores either is incomplete.
How to start: a review that fits in two weeks
The routine that works is boring and repeatable.
- Pick one system at a decision point. The design about to be signed, or the live system every roadmap item now waits behind.
- List the decisions that are hard to reverse. Data model, integration contracts, platform, boundaries: usually five to ten items. For each, write down honestly what reversing it would cost today.
- Put that list in front of independent engineers. Engineers who have watched these decisions play out over years and are not selling the next platform. Two weeks covers an ordinary system, and this is exactly where our technology assessment and due diligence work starts.
- Write a one-page decision record per item. What was chosen, what was rejected, why, and the trigger that would reopen the question.
- Fix the cheap ones immediately. A data-model correction in week four is an afternoon. In year two it is the worked example above.
If the system is already live and slowing everything down, the same review tells you which part to replace first; modernizing a legacy core without breaking the business is its own discipline. If nothing is signed yet, the cheapest moment is before the RFP goes out, and writing a technical RFP for a Saudi procurement decides what vendors may propose in the first place.
About to sign a build contract, or already living with a system that fights every change? SDCG reviews system architecture as engineers who have built and remediated at scale in the Kingdom, independently of any vendor, so the finding is about the design, not the next sale. Book a free 30-minute review.