Imagine that you’re building a house. You have six weeks to build this house, and a fixed amount of money to spend on it. What do you prioritise in the build, and what can you afford to leave out?

This thought experiment isn’t dissimilar to the challenge that developers and stakeholders often face when delivering a software application. Let’s say you’re really concerned about keeping the house warm, but not concerned so much about making it secure. You’ll sink all of your budget into a state of the art heating system that you can control remotely from your phone, but you only have enough time and resources left at the end to make the front door out of cardboard.

Developers call these considerations Quality Attributes. You may have also heard of them referred to as NFRs or non-functional requirements. When we architect a system, we need to be mindful of the impact that meeting the requirements may have on other aspects of our application.

The most important quality attributes that we generally consider are performance, security, reliability, maintainability, availability, and usability (although there are many more). Much akin to our house building scenario, there’s rarely a time where we can satisfy all quality attributes to the same extent. We have to compromise. If we have six weeks to build an application, and our client has requested a fast, secure system that’s highly available, then we’ll have to neglect certain attributes. We may not be able to make the application easy to maintain as a result, or perhaps the application will have a steep learning curve when it comes to usability.

An effective way of managing this is to run Quality Attribute forums between developers and stakeholders. Communication and understanding are the key factors, and it’s important that everyone involved in the project knows which attributes have to be prioritised in order to satisfy the requirements.

This is our challenge when we architect systems. Knowing what area we can strengthen and which ones we can pay less attention to, without having an overall detrimental impact on the system. No one wants to make an application so secure that even Kevin Mitnick couldn’t break into it, but then only works for 60% of the time.

Like all things, it takes practice, and it takes a certain number of failures before you get it right. In the end, with enough experience, it can almost become intuitive, which is the reason why software architecture is often referred to as a dark art.