System Architecture Mindset

How to think, decompose, learn, and stay relevant.

Introduction

There are no complex systems.
There are only systems made of simple subsystems.

A system architect is not defined by how many things they know, but by how they think:
how they decompose, abstract, recognize patterns, and study what they don’t know yet.
Every architecture — an LVDS link, a JEDEC interface, USB, Ethernet, a SoC — is built from the same set of simple building blocks.
Complexity is not a wall; it is a mosaic.
This page collects the principles, strategies, and mental models I use to break down complex systems into understandable, designable, and scalable components.

Principle 1 — There are no complex systems

Complexity is just layering of simple concepts.

When a system looks overwhelming, the problem is not the system — it’s the level of abstraction.
The first step is not to understand everything, but to decide where to cut:

• what the blocks are
• what the interfaces are
• what belongs inside each boundary
• what signals cross those boundaries

Complexity is tamed by decomposition.

Principle 2 — The building blocks are always the same

Protocols change. The fundamental blocks do not.

Under every architecture you will always find:

• serializers / deserializers
• encoders (8b/10b, scrambling, framing)
• arbiters, FIFOs, CDC
• correlators, PLLs, CDR
• state machines, handshakes, timeouts

JESD204B, CSI, USB, Ethernet, CAN, a custom LVDS link —
they are all different compositions of the same basic functions.

If you know the blocks, you already understand half of the system.

Principle 3 — Simplicity is work, not luck

A simple system is the result of many difficult decisions.

Simplicity is not an accident; it is a design goal.
It requires:

• removing what is unnecessary
• choosing one consistent way to do something
• accepting constraints to simplify the rest
• avoiding elegant but fragile solutions
• keeping interfaces clean and predictable

A simple architecture is one you can explain.

Principle 4 — Architecture is a way of thinking

Designing means deciding what to ignore, what to abstract, and what to control.

A system architect:

• defines boundaries
• establishes interfaces
• decides where control loops close
• chooses what must be configurable
• separates essential behavior from implementation details

Architecture is a filter:
it lets only the essential pass through.

Principle 5 — Learn, learn, learn. Always.

Even after years of experience, you will encounter a new function or a new interface.
When that happens, you cannot avoid it — you must study it.

A system architect’s discipline is not only to design, but to stay relevant.
Every new interface is an opportunity to:

• recognize the blocks you already know
• identify what is truly new
• update your mental toolbox

Stopping your learning means becoming obsolete silently.
The rule is simple: learn, learn, learn — always.

Principle 6 — If it feels complicated, stop and redesign it

If you are designing a system or a block and it feels complicated, stop.
Sleep on it, and redesign it from scratch.
There is always a simpler way — and you will find it.

A design that feels complicated is telling you something important:

• the boundaries are wrong
• the responsibilities are mixed
• the abstraction level is inconsistent
• the architecture is fighting against itself

When this happens, the best strategy is not to push harder, but to reset.

Start again.
Redraw the block diagram.
Re‑evaluate the assumptions.
Challenge every constraint.

Simple functions work better, have fewer bugs, consume less power, and are more portable.
Simplicity is robustness, efficiency, and longevity.

From High‑Level Specification to Architecture

Every new project begins with a high‑level specification.
The process I follow is always the same.

Read the specification without chasing details

Focus on:

• purpose
• constraints
• critical metrics (throughput, latency, jitter, error rate, power…)
• external interfaces

Identify system boundaries

Where information enters and leaves.

Decompose into functional blocks

Look for blocks you immediately recognize:

• encoder
• arbiter
• FIFO
• PLL
• correlator
• CDC
• framing logic

And isolate what is new.

Map the specification onto known building blocks

This is the key step:
reduce the unknown to the known.

Identify the critical points to “eviscerate”

Every system has 2–3 points where everything is decided:

• timing
• jitter
• metastability
• protocol corner cases
• synchronization
• latency bottlenecks

These must be studied deeply.

Study the new parts in detail

Read the standard, draw your own block diagram, compare with known patterns.

Choose implementation options based on context

There is no universally best solution.
There is only the best solution for that context.

A Practical Example (coming soon)

I will take a real architecture — for example, a bidirectional LVDS link with:

• parallel‑to‑serial conversion
• tagging
• 8b/10b encoding
• correlator‑based CDR
• PLL
• parallel reconstruction

And I will show, step by step:

• how I decompose it
• which blocks I recognize
• which parts require study
• where the critical points are
• which design choices I make and why

This example will illustrate the complete method in practice.

A Living Page

This page will grow over time.
Whenever I encounter a principle worth capturing, a sentence that summarizes a way of thinking, or an example that clarifies a concept, I will add it here.
The goal is simple:
anyone who wants to become a system architect should find here not only the blocks and the architectures, but also the mindset behind them.