Over time I noticed some typical contradictions between non-functional requirements (NFR). Let’s consider three typical cases of NFR conflicts I learned from practice.
Security vs Ease of Use
Security is a huge and ever growing concern these days. No surprise here – we live when IT-systems are unprecedentedly dependable. More and more activities occur in digital space involving more resources than ever. Resources attract criminals who aren’t used to obtain resources legitimately. New kinds of scam appear daily.
In fact it’s not rocket science to make system secure. Imagine a server in an impenetrable safe, fully air gapped. Located in a restricted area, full of armed guards. That server runs a system which is, well, pretty much secure.
What’s the problem here? It’s kind of a quest to use such a system. Probably such systems exist in military & espionage agencies. You can definitely say it’s not easy to use.
On the other hand imagine a web site on a 3-4 letter domain without any authentication. However, you won’t allow such a system to manage your bank account, will you? =)
The point here is the more secure the system is the less it easy to use and vice versa.
Availability / Reliability vs Efficiency
Another pretty relevant aspect in current day and age of dependable IT is availability / reliability. People already used to systems available 24/7 in B2C segment. Enterprise systems in B2B actively achieving quality of B2C to compete with each other.
“Reliable systems have always been built out of unreliable components.”
And it’s always about redundancy – multiple instances of the same component. So one can handle the work when other fails.
What that means to efficiency most of modern organizations are obsessed with? There’s just no way around it – you must run your apps “much less efficiently”.
For instance, the typical AWS service deployment consists of 3 availability zones (AZs) and designed to handle full outage of 1 AZ. Despite that everything fails outage of an AZ is a rare event. That means deployment in 1 AZ typically runs at most at 66% of load it’s designed and tested for. Violate that and in case of an AZ outage the 2 AZs left won’t be able to handle the maximum load.
The bottom line? The worldwide leader in distributed computing pays x1.5 to make own services reliable. Wanna make it “more efficient”? GL & HF with that. NFR conflicts just inevitable here.
Flexibility vs Performance
We all know the story: let’s make it flexible! It should be configurable! Low code or no-code based! Citizen developers to the rescue!
I just won’t repeat mighty Uwe on the topic of continuous amnesia IT industry suffers from. And many-many other topics he covered brilliantly already. No matter how you slice it any automation requires proper handling. So if your citizen developers aren’t ready to maintain their stuff it’s no better than a piece of legacy crap around the corner.
NFR conflict here is similar to availability / reliability vs efficiency. The number 1 recommendation from performance engineering standpoint is simple. Brendan Gregg coined these fundamental principles as “performance mantras” in his great book I already referred to.
“Don’t do it”
Most significant wins in performance are achieved by elimination of unnecessary work. In other words the most performant execution is the most efficient – with the lowest resource consumption possible. I touched that in my own article on scalability.
What’s the problem with flexibility? Flexibility inevitably adds overhead. The stuff you shouldn’t do in a particular case but you do it anyway.
One of the internal systems I worked with rendered a page. It was all low code scripted on the platform itself. Instead of 3+ requests (html, css & js bundles + a few others maybe) it had to do 50+ requests. It was flexible, yes – just add another script & fetch it from the page (and hope it won’t break everything else). Was it performant? Hell no.
Conclusion
I believe trade-offs to be inherent not only to IT architecture but to the life itself. Every “yes” to one thing is a hundred “no” to other things. NFR conflicts are just one manifestation of that fundamental principle.