Quality attributes
The key to understanding modern ideas about architecture are quality attributes.
Let’s start from a simple and hackneyed example. An architect hears the phrase: “We want to develop a system from scratch and we expect 1,000,000 active users in the first year.” The architect writes a note “the quality attribute scalability is important for the system”. If the architect is not stuck in the Stone Age, he will immediately ask: “will these users be active every day?”. If the answer is: “no, we have a seasonal business, in the summer there are 100 active users, 1,000,000 only on New Year’s Eve”, the architect adds elasticity to scalability.
A more realistic example is when a customer says that he wants to catch up and surpass competitors. Hearing this, the architect writes a note “the system must have a competitive advantage” and goes to think about a version of the diagram below (agility in real life has more components).
The last, but no less realistic example is when the system needs to be released in two weeks. Let’s say it’s pointless to argue about timing. It is clear to everyone that either the system comes out in two weeks, or we lose the project. In this case, the architect writes a note “we throw out testability, scalability, maintainability + a dozen more quality attributes from the system” and focuses on the remaining quality attributes. No hard feelings or gray hairs, especially if the customer signed such an architectural decision record.
The existence of quality attributes has been known for a long time, at least 30 years. Previously, there were few of them, but now dozens have been discovered. For example, elasticity (the ability of a system to automatically “inflate” under a load that surges like a tsunami, without losing availability or response time) became possible only after the cloud and devops revolutions.
Architecture is about identifying and testing the quality attributes we need. Design and implementation must meet the desired quality attributes. A common mistake is to draw component diagrams (i.e., design) without identifying and describing the required quality attributes.
Any IT specialist can grow to an architect role. First, you choose one quality attribute (the one you personally like) and study the best resources on it until you understand the essence of it. You can find the best resources like this. Then you choose the second quality attribute and study it too. And so on until you can clearly talk about any system from the point of view of about ten quality attributes. If you’re interested in digging deeper, the topic of quality attributes is nicely covered in Software Architecture in Practice (2021).
Fitness functions
Modern architects are trying to automate the verification of quality attributes. The most widely known example is testability testing. The architect writes a little code that implements the rule “tests should cover 90% of the project code”. If code coverage falls below 90%, the developer simply will not be able to integrate his changes until he writes tests. That is, it is more difficult for the developer to spoil the quality of the implementation or design, which pleases the architect. Such automatic rules for checking quality attributes are called fitness functions. They were first discussed in the book «Building Evolutionary Architectures (2017)» (I don’t recommend it, it’s a breakthrough book, but poorly written).
There are advanced examples of fitness functions. It happens that in an application one of the modules grows to such gigantic size that it becomes impossible to support it. For an architect, maintainability is important, so the architect divides this module into smaller modules and writes a fitness function so that this does not happen again. A fitness function could be something like “no module should contain more than 10% of the application logic”.
In layered architecture, it happens that in order to achieve a short-term goal, the developer punches a hole from the presentation layer to the database. This could create a lot of problems in the future. But the architect can foresee this and write fitness function “classes of the presentation layer should not directly access the classes of the data access layer. Instead, they should only access the business logic layer classes”.
The topic of fitness functions is well covered in Software Architecture: The Hard Parts (2021), but it can be difficult to jump into. A better place to start is Fundamentals of Software Architecture: An Engineering Approach (2021).
Future
There are still no measuring instruments for many quality attributes; they are assessed by gut feeling or checked manually. At the same time, many projects have such huge flows of changes that architects simply do not have time to track the impact of these changes on quality attributes. Fortunately, for some quality attributes we already have cool tools like ArchUnit, Chaos Monkey, Dependabot , as well as linters for any programming languages.
I hope that in the near future, the gold standard of the industry will be automatic verification of absolutely all interesting attributes of the quality of produced software. What a nice time it’s going to be!