How do we make non-functional requirements exciting?

They’ve got that look again.

If you’re a technology architect, particularly one who designs infrastructure, then you’re used to people getting that look. Their eyes glaze over, their smile becomes fixed. They may have an air of panic. Why is this person talking to me? What’s a server? What is latency, and why are they so worried about it? What’s the quickest way out of this meeting? There’s only one sure way to dispel this look: to start talking about time and money.?

Welcome to the conversation about non-functional requirements. This is the time when the technology architect tries to agree with their business sponsor (or, more usually, the business sponsor’s representative) what compromises they will make together. Because there are always compromises: if you ask someone how much downtime they can tolerate, what the response time should be, and how many users the system needs to support, the default (and not unreasonable) answers are likely to be: none, instant, and everybody. Until you explain how much it would cost and how long it would take to achieve those things.

I believe that the conversation about non-functional requirements is a major source of technical debt, because it usually proceeds from a position of mutual misunderstanding. The business sponsor rarely understands the choices and compromises they are being asked to make. The technology architect rarely understands the business constraints and parameters under which the sponsor is operating. When disagreements and misunderstandings like this arise, they are normally resolved by following the money - meaning that projects are optimised for things that the sponsor understands and values.

This is a difficult problem to solve, and I do not claim to have solved it: I’ve worked on plenty of projects where I have known that the solution was under-specced and rushed to production - without knowing how to express this in a way which helped people decide and act differently.

However, I do think that there are a couple of things that we can do, and they are to attempt shifts in language and attitude.

Language

As I wrote a few weeks ago, the language of non-functional requirements is not helpful. Given a choice between meeting a functional requirement and a non-functional requirement, it is entirely reasonable to choose the thing without ‘non-functional’ in its name. I suggested that meta-requirements might be a better term: requirements that sit above all others and make them possible.

On reflection, though, I think that the whole language of requirements, functional or non-functional, is not helpful: it implies an old-fashioned transactional relationship between sponsor and technology team, expressed in a precise specification. We’ve been trying to stop working this way for decades now.

Perhaps we should use the language of features. Everybody loves a feature: it sounds like something positive that adds to the capability and appeal of my system. We could combine these ideas and talk about meta-features: those features which make all other features possible. And I think that it is up to us to use language which shows how desirable those meta-features are: language of speed, agility and reliability, not just the language of deployments, pipelines and failovers.

Attitude

If I look back on my career, particularly my early work as a solution architect (which was so long ago that we didn’t even call that work solution architecture), then there are conversations about non-functional requirements which I wish I had approached with a different attitude.

In those conversations, the attitude I took could best be described as apologetic and deferential. Apologetic, because I had been coached not to baffle ‘the business’ with technical talk, but it seemed impossible to have the conversation without saying something about technology. Deferential, because I had also been coached to regard ‘the business’ as the authoritative source of requirements. Inevitably, these conversations ended in uneasy compromise and regrettable technical debt.

I hope that now I would approach such conversations with a higher degree of professional confidence: sufficient confidence to believe that, while we have a duty to explain, sponsors of digital projects also have a duty to understand: if you are going to digitise your business and make your users dependent on your technology, then you owe it to everybody to make informed choices. Technology architects are there to help people make those choices - and not let them off when their eyes glaze over.

Fortunately, as is often the case in technology, there is good news, and the good news is that technology has evolved to help us address this problem. Many of the choices made to meet non-functional requirements in the past had long term physical consequences: we bought software and servers, we procured network connections and space in data centres, we installed tape drives and found places to store our backups. This meant that, if we got our choices wrong, they were hard to change: excess capacity might go unused indefinitely, while overloaded infrastructure stayed overloaded until we tuned the system or went through another procurement cycle.

The shift to software-defined infrastructure in the form of cloud platforms makes it easier to change our minds: we can start with limited capacity and scale horizontally. We can re-architect our virtual networks dynamically. We can add storage as we need it. (Of course, this all depends on us having the money.)

However, cloud platforms don’t provide all meta-features on their own: there are still choices we have to make, about architectures, and pipelines, and deployment patterns, and all the things that make our solutions fast, agile, stable and secure. This means that there are still moments when people will get the look - and we will have to find the language and the attitude to help them help us make the right choices.

(Views in this article are my own.)