The Architect’s Path (Part 1 - Model)

Updated: November 08, 2020 Updated: Architecture

As I described in a recent post, when getting ready to publish The Software Architect Elevator, my editor and I entertained naming it The Architect’s Path. We decided to stick with the elevator metaphor because it really struck a chord with readers. Nevertheless, requests for an architect learning path come up fairly regularly, usually in the form of readers asking for advice on which books to read to become an architect or a better one.

Although it’s tempting to just point to my book, that wouldn’t nearly do this topic justice. 300 pages cannot possibly capture what there is to know about architecture - The Software Architect Elevator is just a small piece in a large jigsaw puzzle. 1000 pages likely won’t suffice either - Grady Booch tried and he’d be a good candidate to tackle this kind of problem.

To make matters ever more challenging, architecture isn’t a linear topic space either. One would therefore first need to build some sort of landscape of topics and then plot a sequential learning path over it. Sounds like a nice architecture challenge!

A Model of Architecture as a Discipline?

So, what does a model of architecture as a discipline look like? That’s not an easy question to answer. My starting point would be to look at how software architecture books or lectures are organized. I’ll give a simplified and non-scientific overview based on a sample set defined by my bookshelf and personal relationships. This set also isn’t orthogonal—like good software, good architects rarely live in isolation, so these guys all know each other and build on each other’s thinking.

Let’s look at a few well-read architecture books (and lectures) from George Fairbanks, Cesare Pautasso, Eoin Woods, and Olaf Zimmermann to see how they are organized:

• Cesare has been collating his lecture notes into an ebook aptly titled Software Architecture (it stands at 530 pages!). He first introduces a set of quality attributes (positioned as the key purpose of architecture) and then pairing up a primary quality with the a major architectural abstraction: Modularity and Components; Reusability and Interfaces; Composability and Connectors; Compatibility and Coupling; Deployability and Containers. The abstractions seem to proceed from high-level system design (modularity, interfaces), and then to run-time considerations (deployability, scalability, availability).
• George’s book Just Enough Software Architecture starts with models, going from high level to low (Conceptual Model, Domain Model, Design Model, Code Model) before pivoting to more meta-topics like Model Elements and Model Relationships, and finally diving into Architectural Styles.
• Eoin and his co-author Nick appear to go in layers in Software Systems Architecture , first introducing the notion of concepts, process, viewpoints, and perspectives, before then dedicating one part of the remainder of the book to each. Perspectives are sequenced into Security, Scalability, Resilience, Evolution, seemingly focusing on operational concerns and recognizing time (evolution) as a separate dimension.
• Olaf’s lecture with concrete implementations that illustrate higher-level concepts. He divides into five major parts: Context and scope; Big decisions and solution strategy; Logical design (incl. DDD); Integration; Systems management and deployment. He highlights that these are really viewpoints in disguise.

These works appear to be structured along an overarching theme of “high-level to low-level” (or vice versa) and an element of chronology (requirements come before design and operations). While I would use a similar structure for a book or a lecture, I also can’t help but feel that an architect’s path is even more multi-faceted than a system’s path, which most of these books try to model.

What About Data?

There’s an aspect of architecture that’s routinely overlooked or intentionally omitted: data architecture. Cloud Strategy likely could have benefited from a part on data, but I was afraid to start writing it because I feared that it might grow into its own book. Luckily, Eoin and Nick include a chapter on Information Viewpoint in their book.

So, once again, we are putting data aside for a moment and hope that I’d get around to writing “Data Strategy” some day.

Folding a Complex Space into One Dimension

Just like with systems architecture viewpoints help us make a complex web of things, which the set of architecture topics surely is, approachable. One way to do so is to order items along a single dimension. Intuitively, I’d lean towards selecting scope as the primary dimension: start with small things and gradually move on to larger things.

A (likely imperfect) first cut could look as follows:

1. Single component
2. Multiple, connected components
3. A whole system
4. The bigger picture of organizations and technology

I quickly realize the limitation of this viewpoint because it doesn’t give me a good space for topics that deal with change over time, or what I like to call the first derivative. This “extra dimension” would include topics like CI/CD, versioning, and managing change. Let’s park this challenge until later - architects live in an imperfect world :-)

One Dimension Might Not Be Enough

After thinking the model over a little bit more, I found that it’s missing another important angle: architecture is all about abstraction, so we’d also want to factor in how concrete or conceptual we want to get, i.e. the level of abstraction we want to apply.

We might initially think that larger things are more abstract but that’s not necessarily the case. A major pet peeve of mine is reminding people that looking at things from a higher level doesn’t at all mean there’s less depth. So, I see the granularity of design (smaller vs. larger things) and level of abstraction as two independent dimensions:

Funnily we ended up with yet another 2x2 Matrix, the staple of all management presentations. So, we better test our two-dimensional universe to make sure we have real content here. We should be able to fill all four quadrants with meaningful architectural considerations:

Going counterclockwise, we can find representative examples for each quadrant:

1. Wide, Conceptual: Architectural styles, integration styles
2. Wide, Concrete: Cloud configuration scripts, integration flows
3. Narrow, Concrete: Language syntax, idioms, libraries
4. Narrow, Conceptual: Design patterns, “code smells”

Some folks might claim that #3 isn’t really architecture - that’s OK for me. I am not here to split hairs but to help define an end-to-end learning path. #2 can take numerous forms like Terraform, CloudFormation, or Pulumi scripts, which can wire up a whole system infrastructure with concrete, detailed parameters. Integration flows define the system composition at a higher level, but very concretely. In serverless systems, the two actually have an interesting intersection—we’ll park that for another post.

While these are just simple examples, they do highlight that you can model a system as a whole very concretely, i.e. what system component is deployed to which VM of what size (hello, YAML!). Likewise, you can discuss small details in a conceptual way with design patterns. Too many people assume that wide scope goes hand-in-hand with conceptual and small scope only with concrete, but that’s not true.

Reading Material

After this a fairly elaborate preamble on applying architectural thinking to a learning path for architects, we need to fill in our matrix with concrete book and topic recommendations.

Let me pause here first, though, and defer the book list until Part 2.

Make More Impact as an Architect

The Software Architect Elevator helps architects and IT professionals to take their role to the next level. By sharing the real-life journey of a chief architect, it shows how to influence organizations at the intersection of business and technology. Buy it on Amazon US, Amazon UK, Amazon Europe