Software Architecture

Why Architecture Matters

The architecture of an application or a software solution is often viewed as the overall structure of the application, the major modules of the system and the dependencies between them, and the major technical decisions that drive the development of the project.

So why invest time in architecture at all?

Ultimately, a software project exists to meet the needs of the business, whether that’s a large enterprise, a startup or somewhere in between, by delivering a system that supports its goals and adds value.

Architecting a solution also involves planning for and addressing non-functional requirements to ensure the solution is reliable, secure, performant and cost-effective.

Designing for Change

Understandably, project stakeholders are often focused on the current business requirements and short-term goals. However, applications and systems often have a lifespan much longer than originally anticipated, and far longer than any single sprint.

Requirements will also change over the lifetime of the project (and beyond), often in ways the original team couldn’t have anticipated. The team changes too, and the developers who maintain or extend the application will often join long after it was first built.

The solution architecture or system design must support future change. Robert C. Martin makes the case well in Clean Architecture. He asks a simple question: which matters more, that a system works, or that it can be changed? Ask business managers and they will usually say that working matters more, and developers tend to go along with that. It’s a natural position for anyone to take, but Martin argues it’s the wrong one:

The Greater Value

“If you give me a program that works perfectly but is impossible to change, then it won’t work when the requirements change, and I won’t be able to make it work. … If you give me a program that does not work but is easy to change, then I can make it work, and keep it working as requirements change.”

— Robert C. Martin, Clean Architecture (2017)

That argument resonated with me. I believe he’s right, although it can be taken too far: a system that is endlessly adaptable but never delivers anything isn’t valuable either. The point is that the ability to change is what keeps working software working, so it deserves protecting even when nobody is asking for it.

Ultimately, the architect’s job is to support the development team, now and in the future, so that the application meets the needs of the business and can adapt as requirements change.

Communicating the Architecture

An architecture only helps if people understand it. With stakeholders, that means explaining the direction, the roadmap and the trade-offs in terms of outcomes and risk (see Ways of Working). With the development team, it means making the architecture visible in the code itself and in lightweight diagrams such as C4, rather than in heavy documentation that goes stale.

Where to Start

If you only read one page, make it Architecture Principles: the six principles I come back to on every project, and the trade-offs behind each. From there:

• Managing Complexity: why managing complexity is what keeps a system easy to change.
• Key Concepts: the vocabulary I reason with, and where I land on the trade-offs between them.
• Architecture Frameworks: the tools I use to make, validate and communicate decisions.

The styles pages (system and application) explain how I choose between the common styles. The patterns pages (system and application) cover the patterns I reach for, with notes on what to watch out for with each.