What Is Software Architecture

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 software architecture is.

A common rhetoric is that software architecture is the important stuff … whatever that is. I find this to be greatly 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’s structure  is the type of architecture style -- microservice, layered, etc -- the system is implemented in. 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, deployability, so on and so forth. 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 of the system and direct its development. I think this is what Clean Architecture is -- an architectural decision -- because it constraints how the system should be built.

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

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