In my post about <a href="https://hvalls.dev/posts/developers-and-architects">Developers and Architects</a>, I did mention the concept of architecture characteristics. Let’s talk about them.
According Mark Richards and Neal Ford, architecture characteristics are “all the things the sofware must do that isn’t directly related to the domain functionality”. Also, they are independent of the problem domain and describe concerns critical to the success of the architecture. Sometimes, they are also referred as “non-functional requirements” or “quality attributes”.
Here are some examples:
<ul>
<li>Availability</li>
<li>Performance</li>
<li>Scalability</li>
<li>Maintainability</li>
<li>Security</li>
<li>Privacy</li>
<li>Usability</li>
<li>Accessibility</li>
</ul>
...and so on.
An architect must define which ones must be supported by the system, extracting critical information from the domain concerns (by talking to domain stakeholders) and the requirements (e.g. if it’s required to develop a payment gateway, maybe security it’s an important characteristic to be supported).
It’s an anti-pattern trying to define an architecture supporting them all. It leads to greater complexity.; remember the First Law of Software Architecture:
<div class="remark-highlight"><pre class="language-quote"><code class="language-quote">“Everything in software architecture is a trade-off.”</code></pre></div>
If you want to practice your skills in extracting architecture characteristics from a given problem, <a href="https://nealford.com/katas/list.html">Neal Ford’s katas list</a> is an excellent resource to start.

In my post about Developers and Architects, I did mention the concept of architecture characteristics. Let’s talk about them.

Héctor Valls

Sr. Software Engineer

Architecture Characteristics