Software Architectural Pearls: 002 (en-us)

Non-functional Requirements - Application Performance - Part 1

Returning to the analogy we made in the previous articles, where I compare the construction and evolution of an application with the generation and evolution of the human being, the computational system that aims at high performance, being able to meet thousands of requests per minute, is very similar to with a high-performance athlete. Since childhood, the high-performance athlete is prepared to acquire a nutritional, psychological, and muscular balance that, combined with solid resilience, discipline, and focus, make this individual achieve marks that are absolutely unattainable to other individuals who were not cut out to this end.

The same occurs with high-performance systems, where all these fundamental characteristics for the athlete are present, similarly, in our computer systems covering, for example, the following topics:

• Language or development frameworks used.
• Infrastructure, capacity, and geographic distribution
• Data storage technologies
• Security layers needed

These four topics are examples within several others that we can cite and evaluate. But as software architects, we have to meet a whole set of requirements. And many times, we will have to sacrifice one side to serve the other, which we commonly refer to as a trade-off. For example, I can mention that if there is a vital security requirement where all data must travel internally and externally encrypted, the network performance will be affected by the overhead created by this requirement. Which is perfectly normal and acceptable. In this particular case, security takes precedence over performance. From here, we can draw some crucial points, and I advise you to faithfully follow these teachings, regardless of the non-functional requirement analyzed:

1. Every non-functional requirements survey has its primary objective to eliminate any subjectivities. They all need to be documented, tested, and approved in detail.
2. No non-functional requirements should be individually analyzed or validated. They must be validated together and through simulations of the natural use of the application in its different growth scenarios and in equal conditions of infrastructure with that of production.
3. The Software or Solutions Architect's central role is to validate the feasibility of such requirements in these different scenarios. If this is not feasible, it needs to be pointed out as soon as possible, as this may even make the development of the product unfeasible or blocked.?The Software Architect must maintain, in case of trade-offs or decisions that will affect the NFRs, an architectural decision record containing:

• the context of the problem;
• the alternative solutions presented;
• the decision that was taken.

1. The record of architectural decisions needs to be formalized and evidenced so that in the future, such decisions do not become the target of criticism or significant problems.

Link to the article