The Software Architect Elevator

Chapter 8. Is This Architecture?

Look for Decisions!

Would you pay an architect for this?

Part of my job as chief architect is to review and approve system architectures. When I ask teams to show me “their architecture,” I frequently don’t consider what I receive to be an architecture document. Their counter-question of “what do you expect?” isn’t so easy for me to answer: despite many formal definitions, it isn’t immediately clear what architecture is or whether a document really depicts an architecture. Too often we have to fall back to the “I know it when I see it” test famously applied by a US Supreme Court judge to obscene material.¹ We’d hope that identifying architecture is a more noble task than identifying obscene material, so let’s try a little harder. I am not a big believer in all-encompassing definitions but prefer to use lists of defining characteristics or tests that can be applied. One of my favorite tests for architecture documentation is whether it contains any nontrivial decisions and the rationale behind them.

Defining Software Architecture

So many attempts at defining software architecture have been made that the Software Engineering Institute (SEI) maintains a reference page of these definitions.

Among the most widely used is this definition from Garlan and Perry, from 1995:

The structure of the components of a system, their interrelationships, and principles ...