STfA
Persona learning path

Start here:
Software Architect

Focus on architecture decisions, technical system dynamics, and resilient delivery structures.

Level 1: Foundations

0/5 read

After this level you can name feedback loops, delays, and bottlenecks in your architecture and frame them as system behavior.

Systems Thinking in the Architecture Context

Systems thinking analyzes the interdependencies, feedback loops, and delays among individual parts instead of trying to repair them in isolation.

Why here: The foundation: without seeing structures instead of parts, none of the later articles land.

Feedback Loops

Feedback loops, whether reinforcing or balancing, are the basic building blocks that drive or stabilize system behavior over time.

Why here: Feedback loops are the base mechanism behind almost every architecture pattern in this path.

Delays

Delays exist in every system. They distort our perception of cause and effect and push us toward drastic overreactions.

Why here: Delays explain why architecture decisions only show their effect months later.

Constraints and Bottlenecks

Bottlenecks limit the overall performance of the system and determine where improvements actually matter.

Why here: Bottlenecks determine the throughput of your system — technically and organizationally.

Sociotechnical Architecture

Software architecture can never be viewed independently from the people and teams who create and operate it.

Why here: Connects the technical with the human side — the core thesis of this platform.

Level 2: Practitioner

0/7 read

After this level you recognize recurring patterns behind technical symptoms and can back them up with diagrams.

Goodhart's Law

When a metric becomes a target, it loses explanatory value because the system starts optimizing for the proxy instead of the underlying outcome.

Why here: Shows how metrics deform your system — required before you define architecture KPIs.

Microservice Explosion

The number of services grows faster than the team's ability to manage them. That creates operational overhead and the typical symptoms of a distributed monolith.

Why here: The reference symptom of this path: all the foundations applied to one real case.

Limits to Growth

Growth in real systems eventually meets limiting resources. The important work is to recognize that limit early and either expand capacity or adjust ambition.

Why here: Explains why successful systems stall when a limiting factor is ignored.

Fixes That Fail

A quick remedy eases the acute symptom immediately, but it triggers hidden side effects that return in the medium or long term.

Why here: The most common archetype in technical work: quick fixes that make the problem worse.

Causal Loop Diagrams

Visual maps that clarify complex architecture problems by making circular cause-and-effect structures explicit.

Why here: Your most important diagnostic tool for making feedback loops visible and discussable.

Dependency Mapping

A visualization of technical and organizational entanglements that exposes bottlenecks and dangerous coupling.

Why here: Reveals the couplings that actually hold your architecture together.

Behaviour over Time Charts

A visualization tool that reveals how system variables such as metrics, debt, or productivity change over time.

Why here: Trains you to look at trajectories instead of snapshots — the basis for trend statements.

Level 3: Strategic depth

0/5 read

After this level you choose interventions by leverage and anchor them in daily work with the right tooling.

Coupling Reduction

The deliberate cutting of hard, blocking dependencies between parts of the system to buy local autonomy at the cost of some consistency.

Why here: The structural answer to most dependency problems found in the diagnostic phase.

Feedback Loop Redesign

The radical shortening and rerouting of technical and human signals so that failures hurt immediately instead of exploding only after release.

Why here: Acts directly on the loops you identified with the diagrams.

Leverage Points

The strategic focal concept of systems theory: the places within a complex IT landscape where a tiny intervention can trigger outsized architectural change.

Why here: The ordering model for all interventions: where effort pays off and where it fizzles.

Architecture Observability Tooling

Traces, metrics, and logs as architecture diagnostics: they make gradual structural decay visible before it turns into incidents.

Why here: Makes the effect of your interventions measurable — no measurement, no learning loop.

System Dynamics Simulation

The step from sketch to quantitative model: testing hidden delays in the architecture numerically before they cause damage in production.

Why here: Lets you rehearse structural changes before they get expensive in production.