The issue with most definitions of software architecture is that they leave you with more questions than answers. To make it worse, everyone seems to have a different idea of what is software architecture.

A common rhetoric is that software architecture is the important stuff … whatever that is. I find this to be unsatisfying, so I decided to learn from veteran software architects Neal and Mark through their book Fundamentals of Software Architecture.

Neal and Mark give a more meaningful description based on what is analyzed when an architect analyzes a system. They say a system’s architecture is defined by: it’s structure, architectural characteristics, architectural decisions and design principles. I expound on these in the following paragraphs.

System structure  is the architecture style the system is implemented in, an non-exhaustive list is: microservices, layered, etc. Therefore, when you ask someone about the architecture of a system and they say, “oh this is a microservice architecture”, know that they are only describing its structure. 

Architectural characteristics define the success criteria of the system. Think availability, scalability, fault tolerance, performance, security, testability and deployability. These are independent of the system’s functionality but are required for the system to function properly.

Architectural decisions define the rules of how a system should be constructed. They form constraints on the system and direct its development. I think this is what Clean Architecture is — an architectural decision — because it constrains how the system should be built.

Design Principles guide the development team on what technologies to adopt. For example, a design principle will specify that the  frontend should use a  reactive framework and leave it up to the team to decide whether they’ll use a specific implementation of a reactive framework like React, Elm or Vue.

Software architecture is not just the important stuff. It is all these things.

View Comments

Next Post