Random articles


This page contains my notes, thoughts and remarks of the book Fundamentals of Software Architecture: An Engineering Approach. A Comprehensive Guide to Patterns, Characteristics, and Best Practices. I’ve taken these notes as part of Scalable Capitals weekly reading group where we read technical books and discuss chapters on a weekly basis.

(1) Introduction

There’s no clear path to become a software architect.

Definition of Software Architecture

Software architecture consists of

Eight core expectations

Architecture and Engineering

Laws of Software Architecture

(2) Architectural Thinking

Four main aspects of thinking like an architect:

  1. Understand the difference between architecture and design
  2. Have a wide breadth of technical knowledge and a certain level of technical depth
  3. Understand, analyze and reconcile trade-offs
  4. Understand the importance of business drivers

Architecture Versus Design

Responsiblities of architect and development team

ArchitectDevelopment Team
Analyze business requirementsCreate class diagrams for component
Select architectural patternsCreate user interface
Creating componentsDevelop and test

This is challenging, if architecture is independent of design (“unidirectional design flow”). Instead, architect and development team must be on the same virtual team to facilitate bidirectional communication.

Technical Breadth


Knowlegde pyramid

In beginning of career, focus on (A). Be aware, that one must maintain knowledge of (A), otherwise it becomes obsolete.

Value of an architect: broad understanding of technology and when to use a particular set of technologies to solve a particular problem. Hence, as an architect,

Transitioning into an architect role means to accept a shift in perspective. Difficultiers arise:

Frozen Caveman Anti-Pattern. An architect, who always reverts back to their irrational concern in every acrchitectural discussion based on a single bad experience in the past => Risk assessment should be realistic.

Analyzing Trade-Offs

Thinking like an architect is

While anaylzing trade-offs, it’s important to look at both the benefits but also negatives of a solution.

(Omitting extensive example of topics vs. queues for a bidding system)

Understanding Business Drivers

An architect has to understand the business drivers and need to translate them into “-ilities” such as scalability and availablity.

Two important aspects

Balancing architecture and coding

Ideally, every architect should still code (to maintain technical depth, understand developer concerns, …).

Danger: Becoming the bottleneck, hence don’t take ownership of code of a critical path in a project. Instead, delegate critical functionality to full time development teams and work on some non-critical business functionality.

In addition or as an alternative, to remain hands-on at work, architect can

(3) Modularity

Modularity is an organizing principle; good Modularity is an implicit architecture characteristic.

Definition: Modularity describes a logical grouping of related code.

Measuring Modularity


(a measure of how related the parts are to one another)

Larry Constantine: “Attempting to divide a cohesive module would only result in increased coupling and decreased readability.”

Definition: LCOM: The sum of sets of methods not shared via sharing fields.

Disadvantage: only able to find structural lack of cohesion; not possible to determine if parts fit together logically.


Definition: afferent coupling: number of incoming connections; efferent coupling: number of outgoing connections.

Definition: Abstractness is the ratio of abstract artifacts to concrete ones.

Definition: Instability is the ratio of efferent (outgoing) coupling to the sum of efferent and afferent coupling (outgoing and incoming).

Instability measures the volatility of a codebase; a high value means that the system breaks more easily; high values occur when you have more outgoing than incoming connections.

Combining abstractness and instability leads to Distance from the main sequence (D=|A+I-1|). Ideally, classes are near the ideal main sequence line, i.e. have a healty mix of abstract and concrete classes as well as outgoing and incoming connections.

Zone of uselessness are classes with high instability and abstractness – too abstract to be useful; classes with few abstractions and few outgoing connections are in the zone of pain: too much implementation, therefore brittle and hard to maintain.

Limitations of metrics

Metrics can’t distinguish between essential and accidental complexity; nevertheless it’s helpful to have metrics to establish baselines, create awareness, etc.


Two components are connascent if a change in one would require the other to be modified in order to maintain the overall correctness of the system.

Static connascene is preferred, since source code analysis (tooling) allows to improve way easier.

Strength of connascene: how easy can a developer refactor a particual type of coupling? Locality of connascene: how proximal are the modules to each other in the code base. When refactoring, one has to evaluate strength and locality together.

Degree of connascene: size of its impact.

Connascene and coupling are related, see Figure 3-6 on p. 79.

Guideline 1

… to use connascene to improve code base:

Guideline 2

(4) Architecture Characteristics Defined

Architecture Characteristic (abbreviated AC from now on) meets three criteria:


Operational AC

Overlaps with Operations and DevOps

Structural AC

Concern about code structure (modularity, controlled coupling, readable code, …)

Cross-Cutting AC

ISO definitions

Note that there is no commonly agreed definition of ACs.

ISO defined some

Fun fact: (from Wikipedia): The letters ISO do not represent an acronym or initialism. The organization provides this explanation of the name: Because ‘International Organization for Standardization’ would have different acronyms in different languages (IOS in English, OIN in French), our founders decided to give it the short form ISO. ISO is derived from the Greek word isos (ίσος, meaning “equal”). Whatever the country, whatever the language, the short form of our name is always ISO.


Applications can (and should) only support a few ACs:

Quote: “Never shoot for the best architecture, but rather the least worst architecture.”

Again: Architecture should be as iterative as possible.