One of the mistakes that new architects make is underrating the effect of the quality attributes on the architecture decisions. They don’t capture the quality attributes at all or much later in the project and when they do it, they only dedicate a short time and put less effort to accomplish this important task. Probably, the reason is that the quality attributes are vaguely understood and poorly specified.
To help better understand their importance, I will answer the following questions: why do we need quality attributes, and how to find and document them?
Why do we need quality attributes?
Quality attributes, also known as non-functional requirements, architecture characteristics, and also called “-ilities”, will help you make important decisions such as which architecture style to use: Monolith vs. Distributed? Microservices vs. Webservices? Choreographies vs. Orchestration? Synchronous vs. Asynchronous communications? …etc.
You will need both the business requirements and the quality attributes to help you decide which architecture style to use but the quality attributes have a profound impact on the architecture. For example, if you are working in a domain where regulations and policies change frequently, you may need to separate the module containing the code that implements regulations from the other modules that are more stable (E.g., using microservices architecture). Another example is if you are working on an application where thousands of users will access simultaneously at specific times, you need to consider scalability as part of your quality attributes and reflect it in your architecture decision by using for example microservices and asynchronous communications.
Note that the quality attributes are interdependent, and therefore that by implementing one attribute, your architecture may impact another attribute. A good example is a security and performance. By encrypting all the data at rest and in transition the performance may be impacted as this requires more time to encrypt and decrypt the data every time there is a request.
How to find the quality attributes?
Some of the quality attributes are explicit and can be found by reading the requirements such as the number of users that access a system, the expected response time, and the availability of the system. But, much of what affects the architecture will not be listed in the requirements and the documentation and need to be found by working collaboratively with the different stakeholders. This is a challenge that every architect has to face.
Document the quality attributes you discover incrementally and share your findings with the stakeholders to validate your understanding. As not all quality attributes are not equal, it is crucial to find the most important ones by prioritizing them. Otherwise, you may end up with a large list of architecture characteristics that may lead to generic solutions that target all of them but in fact, don’t support any adequately. The goal is to identify the most important in the list and focus mainly on them to make your important architecture decisions.
The International Organization for Standards (ISO) publishes a list of the quality characteristics that you can find here. You can also find another list from Wikipedia here.
To help you start documenting your quality attributes, you can find a template here.