2. Using NFRs to guide architectural decisions

Why it matters

Our architecture is represented by the solutions we implement. The solutions we choose impact system qualities.

Sometimes, architecture is described as: “The parts of your system that is too difficult to change”. A more useful definition is:

1. The part of the system that determines your system qualities.
2. Names and models, so we can talk about them.

What are system qualities?

If you quantify your system qualities, you get what is commonly known as “Non Functional Requirements” (NFRs). Take the system quality “Performance” as an example, a quantifiable measure of performance is “Response time”.

A list of key system qualities are listed below. A simple way to recall them is to think of performance and everything ending with ‘-ility’.

We can summarize the impact of System Qualities on Architecture using three axioms:

1. Given our system qualities, we can’t choose any type of solution (some are viable, others are not).

Take the system quality performance as an example, if we say that we need to have a response time of under 2 seconds over 1 Million IoT devices, we have ruled out deployment on Raspberry PI, but not on Amazon Cloud.

Let’s look at two different solutions for time measurement as an example, both a sun dial and an atomic clock represent solutions to this problem. However, what system qualities we have will decide which is viable.

2. Architecture is a key driver of system life cycle costs.
   If we set the bar of our system qualities too high, then our system life cycle cost will also be too high. In other words, choosing system qualities which are too high at a very early stage can be economically disastrous.

3. System qualities vary with time. They are never constant.

“We did a Minimum Viable Product (MVP) – then this ended up in production.”

What makes up an appropriate set of system qualities during Proof of Concept will differ from what we need when we do our Big Launch. Failure to do architecture shifts between MVP and Big Launch produces technical debt and the undesirable side effect above.

From our image above:

• These releases don’t require the same architecture
• The architecture can (and should!) evolve
• If it doesn’t, you’ll end up with technical debt

This means the Architecture needs to be Agile, which we often express using the system quality “Modifiability”.

How it works

Practice: As architecture, ask, “What are the non-functional requirements?”

If we don’t ask this, we risk implementing solutions that do not fulfil them, or, alternatively, have product lifecycle costs that are too high.

A classic example of this in software is building a system that solves the basic needs of a user but runs into performance issues when we deploy this to many.

Practice: Measure your system qualities

The best documentation is not specifications on shelves but specifications that run. This means as code or test cases.

When can you measure your system qualities? Answer: During continuous system testing:

During

• Function testing – we test that we build a function that does what we expect it to do.
• Acceptance testing – we test that it solves the users problem.
• System testing – we measure and validate the system qualities. A good example of this is when Netflix validates “Availability” using the “Chaos Monkey”.

What it comes to measuring system qualities, automate as much as possible. This produces two benefits: the first is faster feedback loops; and the second is Modifiability. What runs needs to be maintained, and what is maintained with ease is modifiable.