Reviewing Software Architectures

Author: Steve Malmskog

Goal
Develop a methodology for reviewing a software architecture. The focus is on cloud-based software, but it can be applied to other
software products as well.

Background
The method of analysis is based on the 4+1 architecture view model: https://en.wikipedia.org/wiki/4%2B1_architectural_view_model
(paper is available here: https://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf )

There are four primary views that are used to analyze and understand a software product. The purpose of these views is to
systematically work through all the aspects of a complex software system and come away with a solid understanding. As you
perform your analysis, there are three questions that are important to ask each step of the way. These cut across each of the
architectural views:

1. What. This answers the question of "what was built?" It seeks to determine the end result of the effort expended to
development the software. At the end of everything, what is it you have? This can be used to determine gaps and future
team focus. For example, do you have a product that checks all the product boxes but is poorly written and future feature
velocity will be miniscule? Or are there significant feature gaps but what has been written is rock solid? Or something in
between?
2. How. This answers the question "how does it all work?" It seeks to understand how the pieces fit together to solve a
problem. But beyond this, it can answer the question "how well does it work?" For example, How well or how poorly has it
been written and what technical debt was accumulated? And even further, this question can also encompass a business
dimension: How does it solve problems my customer has? How well does it establish a business moat against my
competition?
3. Why. This answers questions oriented on context and decision making that led to the "how" of the product. It seeks to
primarily answer the question "why was it built the way it was?" Answering the "why" questions can give significant insight
into the team that built the software: its technological proclivities (not only what technology does the team prefer, but
does the team know how to make the right choices between technologies when solving a given problem), its
understanding of technical debt management and tradeoffs, and perhaps most significantly, the team's strengths and
weaknesses (who are the strongest members of the team, who are weaker, where does the team need additional bench
strength),

Four Views
When using the four views for complex software systems, the four views can be applied iteratively: first at a high level, then at
deeper levels as you dig in further. This is especially true when it comes to cloud-based software. There can be hundreds of
microservices, a myriad of databases, and numerous data exchange pipelines that form a software product. Trying to digest the
details of such behemoths is too difficult to do all in one take--even when using the four views. Rather, it's easier to start at a
high level ("the front-end UI talks to the back-end payment system") and then go deeper ("the front end UI is composed of four
microservices that do A, B, C, and D"). You can continue this iteration as far as needed ("microservice A is composed of
components X, Y, and Z") and stop when you're too far in the weeds or the details aren't immediately useful.

The four views are described in detail in the paper so there's no need to go over those in detail here, but they are listed below for
reference:

● Logical View. Boxes-and-arrows type diagrams. This is the typical architecture diagram that most people draw and think
of when they think of an architecture diagram. It covers the major components and how they relate to one another. This
is also a good way of knowing how teams are divided up and who works on which parts (this can be where Conway's Law
often comes in to play: https://en.wikipedia.org/wiki/Conway%27s_law).
● Process View. This covers how the software operates especially as it relates to concurrency (horizontal scalability),
software fault-tolerance (resilience, single points of failure, partial failure scenarios, crash/recovery), and the overall
execution of the software (How does it start up, How does it shut down? Does it shut down gracefully?). This also
covers communications between the software components. This is where analysis of communications would occur
(gRPC, REST, IPC, shared-memory, TCP/TLS, etc.) and would include things like: how are APIs defined? Where are the
definitions stored? How are they versioned? How are clients defined?
● Development View. This would cover the Software Development Life Cycle (SDLC). It includes how software is written
and added to the code base including code reviews, code linting, code security checks, etc. It also includes automated
builds (CI pipelines) and deployment (CD pipelines). This is also a good place to analyze configuration: how is the
system configured? How does configuration get created, stored, distributed, updated, and read? The sizing of
configuration should also be analyzed and the formats. Same goes for secrets management: API keys, encryption keys
(asymmetric and symmetric), and TLS certificates (client and server). How are they created, stored, distributed,
updated/rotated, read, and expired/deleted? Software packaging and versioning should also be included: are docker
images used? RPMs? git clone?
● Physical View. The physical view further expands on the ideas of fault-tolerance and resilience but as applied to the
physical layer. This also includes how compute is partitioned and managed: is Kubernetes used? Are VMs? Serverless?

(end)