Software Architecture

What is your favourite definition of the term?

Ruth Malan writes (while I link):

"What is software architecture?" is a perennial question. So much so, ... it can be exasperating? Yet how we think of it, informs what we do.

Grady Booch characterized architecture as "the significant design decisions that shape a system, where significant is measured by cost of change."

Michael Nygard characterized architecturally significant decisions as "those that affect the structure, non-functional characteristics, dependencies, interfaces, or construction techniques."

Another one that I like—and I don't know where have I got it from—is that software architecture is there to deal with all the how questions. This complements the product team, that is there to answer all the what questions. Being under pressure to deliver software on time, they might not have the attention or budget to invest into the quality of what ends up being delivered.

It matches another interpretation of the term, which is that software architecture is to take care of all the -ilities, as outlined in the ISO/IEC 25010:2011 standard. Examples include reliability, interoperability, or maintainability. N.B. security is among them, too, even if it doesn't rhyme.

Whichever definition we agree on, I'm currently convinced that software architecture is primarily about clear communication. A balanced mix of written documents, drawings of boxes and arrows, and in-person interactions. When writing, being thrifty with words and using them with no ambiguity helps, too.

Some teams I've worked with enjoyed using Nygard's architecture decision record, or ADR, template. I think that its main advantage is its terseness, which does wonders for the likelihood of being read in future.

I like to divide the architectural work into two rough categories: micro- and macro-architecture. The distinction is the scope of the work. Micro-architectural decisions affect the work of a single team and software they work on. Say, what programming language we use. Macro-architectural decisions have an effect on multiple teams. Say, how do we communicate error conditions between systems. You can think of micro focussing on boxes, while macro dealing with arrows. Note that it's much easier to make meaningful changes to boxes rather than to arrows.

The distinction between the micro and macro scopes is related to the discussion of bounded contexts and languages from the domain-driven design school of thought. That's a topic for a whole new page, though.