N100FN100F
Published on

The requirements nobody states

Nobody asks in writing for the system to recover within an hour or to lose no more than five minutes of data, yet everybody expects it. The quality attributes that decide an architecture, and how to make them explicit.

Service line Cloud Architecture

What is asked for and what is expected

Functional requirements write themselves: the system must record orders, issue invoices, send notifications. The others, the ones that really decide the architecture, are almost never written down: how long it can be down, how much data it can lose, how much it can cost per month, how many users it must withstand on the busiest day.

Nobody asks for them, but everybody takes them for granted. And when the system does not meet them, the problem is not technical: it is that they were never agreed.

The attributes that decide the design

Two designs across six quality attributesA radar comparing a design optimised for cost and one for availability.ARCHITECTURE · REQUIREMENTSNo design wins at everythingAvailabilityRecoveryPerformanceSecurityLow costOperabilityDesign A · optimised for costDesign B · high availabilityGaining availability costs: requirements are negotiated and written down.Illustrative data; they do not correspond to any real caseN100F · n100f.com

  • Availability. What percentage of the time it must work, and during which hours that matters.
  • Recovery. How long it can take to come back after a failure (recovery time objective) and how much data it can lose (recovery point objective).
  • Performance. Acceptable response time and maximum expected load.
  • Security. What data it handles, who can access it and what regulation applies.
  • Cost. How much it can cost to operate, and how that cost should grow with usage.
  • Operability. Who operates it, with what knowledge and with what tools.

Everything has a price

No design maximises everything at once. More availability means more redundancy, and more redundancy means more cost. Recovering in minutes requires replicas that cost money every month. That is why quality attributes are not asked for 'at the maximum': they are negotiated and written down with a number.

'High availability' is not a requirement. 'Available 99.9% of the time during working hours, with recovery in under an hour and a maximum loss of fifteen minutes of data' is one, and it makes it possible to design, estimate and verify.

How to make them explicit

  1. Ask about the consequences, not about the numbers: what happens if this is down for an hour on a Monday? The answer gives you the number.
  2. Write them in a short table, with one value per attribute and who agreed it.
  3. Tie them to cost: each attribute with its estimated impact on the monthly bill.
  4. Review them when the business changes, not when the system fails.

With the requirements written down, every architecture decision has something to be measured against. Without them, any design looks reasonable.

How we apply it: Cloud Architecture.

If your cloud cost keeps growing and nobody knows why, or your architecture depends on whoever built it, let’s talk.

Let’s talk