Discussing Architectural Characteristics

Outlining project development work inevitably involves discussions on architecture. I've seen this understated from a technical perspective because it involves two aspects. The first one is translating domain requirements into architectural characteristics. The second one is inferring additional architectural requirements that are not explicitly stated as part of the domain problem.

In practical terms, if the product needs to support a high volume of users it has to be scalable. This is usually mentioned explicitly and clearly. Something that might not surface from domain stakeholders is, for example, availability. This is implicit, meaning that we want to build an appropriately available system. The list goes on and you could list all the ilities (e.g. testability, durability) but never be able to satisfy them all. This is normal and, as an architect, not something you want to aim for.

The goal is to keep the design as simple as possible. Incorporating the smallest set of ilities reduces the complexity of the system, other than preventing a lot of headaches. But what can you do as an Architect? As challenging as it is, your responsibility is to outline clearly the implications of any of the architectural characteristics that creep into the requirements. Why is it there and how does it affect other characteristics? You might want a high-performance system but also the highest level of security. Sometimes these don't go hand in hand and you might have to sacrifice some of one to benefit the other.

A starting point is agreeing on prioritizing the architectural characteristics with all stakeholders. This can help look at the bottom ones and understand if they can be eliminated. Generally don't obsess over the perfect set of characteristics but treat it as an optimization problem, what is the better set of trade-offs we can make for this project to be viable?

Thoughts

Mark Richards and Neal Ford (authors of "Fundamentals of Software Architecture") present a very simple "translation table" that maps common project requirements to architectural characteristics (e.g. "Time To Market" => Agility + Testability + Deployability). I like the idea of having a quick and simple reference and I agree that finding the simplest set should be the goal. As someone who works at a tech company though, some of their thoughts don't translate directly. Security is a domain requirement and rarely is it implicit. Sometimes you might even have some company-wide requirements that qualify as implicit from the book (e.g. availability) but are actually top priority. So the challenge changes form, how do you design a product that can always satisfy the most important requirements? It's honestly an intriguing challenge that spurs a lot of creativity. Just remember that, at the end of the day, you're battling with trade-offs rather than chasing a perfect solution.