The cheapest hour in any software project is the one spent on architecture. The most expensive is the one spent migrating away from a database chosen carelessly in week two, three years and forty thousand records later.
What "architecture" actually means here
Not diagrams for their own sake. A useful architecture engagement answers concrete, uncomfortable questions before anyone commits budget: how much load will this actually carry, what happens when the primary database fails, where does personal information physically live, how much data can we afford to lose, how long can we afford to be down, and what does all of this cost per month at year one and year three.
Capacity planning beats guessing
Sizing from a real load profile — concurrent users, transaction volume, peak-to-average ratio, data growth, retention obligations — produces a specification with named instance types and a projected monthly bill. Guessing produces either an over-provisioned server burning money every month, or an under-provisioned one that falls over during your busiest week. Both are avoidable with a spreadsheet and honest inputs.
Recovery objectives are a business decision, not a technical one
Two numbers drive most of the infrastructure cost: how much data you can afford to lose, and how long you can afford to be down. A business that can tolerate losing an hour of data and being down for four hours needs radically cheaper infrastructure than one that can tolerate neither. That is a decision for the business to make explicitly, with the cost of each option in front of it — not something a developer should quietly assume.
Cloud, on-premise, or both
There is no universal answer. Steady, predictable workloads with strict data residency requirements are often genuinely cheaper on-premise or in a local data centre. Spiky, growing or geographically distributed workloads usually favour cloud. Many South African businesses land on hybrid: sensitive data local, elastic compute in the cloud. The right way to decide is to model both against your actual numbers.
What you should receive
- Network topology and segmentation diagrams
- Server and storage specifications with sizing rationale
- A data flow map showing where personal information lives and moves
- A security model covering access control, encryption and audit logging
- Stated recovery point and recovery time objectives
- A costed bill of materials with projected monthly running cost
- A phased implementation roadmap
It should be vendor-neutral enough that you can tender it competitively, and specific enough that whoever wins can build from it without guessing. If the architecture document only makes sense to the person who wrote it, it has failed at its main job.
Written by the DigiCore engineering team. If your situation does not match anything above, ask us directly — a five-minute call usually beats a general article.
Ask a question