An architect is asked to design a system where the requirements, scale and business model are all still changing. How should they proceed?
Show the full answer Hide the answer
How to proceed
1. Write down what is known, assumed and unknown, separately. Making the assumptions explicit converts an uncomfortable fog into a list, and it is the step that lets everyone else contribute corrections.
2. Identify which unknowns actually change the design. Most do not. Usually one or two determine the structure — the tenancy model, the consistency requirement, the scale by an order of magnitude — and the rest can be deferred. This is sensitivity analysis applied to design.
3. Design so the load-bearing unknowns are cheap to change. Behind an interface, as configuration, with a routing layer. Optionality is the architecture when the future is unknown.
4. Decide the irreversible things early, with the best information available. Data model, tenancy, identity, and the shard key get more expensive with delay, so waiting for certainty is itself an expensive decision.
5. Defer the reversible things and name the trigger. "We move to an asynchronous path when any operation exceeds N seconds at p95" is a responsible deferral; "we will look at it later" is not.
6. Ship something small and real. Nothing resolves ambiguity like production. A narrow slice in front of real users answers questions no amount of analysis will, and it is the fastest route out of the fog.
What not to do
Wait for clarity, which is a decision to let someone else make the architecture — usually whoever writes the first line of code.
Design for every possibility, which produces a system that is complex now for futures that will not all arrive, and frequently does not fit the one that does.
Design for the largest plausible scale, paying complexity every day for a scale that may never come and that may have a different shape than the one designed for.
The framing
Ambiguity is the normal condition, not an exception to be resolved before starting. The skill is not eliminating it but structuring the work so that being wrong is cheap — which is a different and more achievable objective than being right.