Quick Navigation
- Start here — How do architects think?
- Systems thinking
- Abstraction
- The dual lens
- Deciding under uncertainty
- Trade-off thinking
- How architects communicate
- Putting it all together
- Cheat sheet
Before we start — the one thing to hold onto
Architects don't think like developers, managers, or executives. I've sat in rooms with brilliant engineers who could optimise a component down to the millisecond but couldn't see how that component affected the rest of the system. And I've sat with architects who couldn't write the code but could tell you exactly what would break if you changed it.
Architects think in systems — holding business and technical concerns simultaneously, making decisions under uncertainty, and choosing trade-offs rather than seeking perfection.
The skill isn't knowing every technology. The skill is knowing how to think about technology decisions in context.
Keep it in mind.
1. How do architects think? — The judgment craft
Here's a question I ask in workshops: what's the difference between how a developer thinks and how an architect thinks?
The answer isn't about seniority. It's about focus.
A developer optimises a component. An architect optimises the system. A developer asks "how do I build this?" An architect asks "should this be built, and if so, where does it fit?"
The cognitive toolkit of architecture includes systems thinking, abstraction, balancing business and technical concerns, deciding under uncertainty, and trade-off thinking. It's a judgment craft, not a technical checklist.
flowchart TD
INPUT["Problem / Opportunity"] --> ST["Systems Thinking\nWhat is the whole?"]
ST --> AB["Abstraction\nWhat level are we working at?"]
AB --> DL["Dual Lens\nBusiness + technical view"]
DL --> UN["Uncertainty Assessment\nWhat do we know? What don't we?"]
UN --> TO["Trade-off Analysis\nWhat do we optimise for?"]
TO --> DEC["Decision\nWith rationale"]
DEC --> COMM["Communication\nRight message, right audience"]
COMM --> EXEC["Execution\nTeams act on the decision"]
Once you understand that architecture is a judgment craft, the rest of this module makes sense — including why there's rarely a single right answer.
Try it yourself — The perspective shift
Think of a recent technical decision your team made. Now answer it from three perspectives:
| Perspective | Question | Your answer |
|---|---|---|
| Developer | "How do I build this well?" | |
| Architect | "Where does this fit in the whole system?" | |
| Business | "What outcome does this serve?" |
If all three answers are the same, you're either very lucky or you haven't looked hard enough.
2. Systems thinking — Relationships, boundaries, and emergent behaviour
Most people see parts. Architects see wholes. Most people see features. Architects see systems.
Systems thinking means understanding that components don't exist in isolation — they interact, depend on each other, and create behaviours that no single component exhibits alone.
The core ideas:
Relationships matter more than components — how things connect determines how the system behaves. Feedback loops — actions create consequences that circle back and change the system. Emergent behaviour — the system does things that no component does alone. Boundaries — drawing lines is one of the most consequential decisions an architect makes.
flowchart TD
subgraph SYSTEM["System Thinking"]
direction LR
A["Component A"] -->|"affects"| B["Component B"]
B -->|"affects"| C["Component C"]
C -->|"feeds back"| A
end
SYSTEM --> EMERGE["Emergent Behaviour\nNot present in any\nsingle component"]
Here's a concrete example. Adding a cache reduces database load — that's the component. But the cache invalidation bug that appears three weeks later? That's the feedback loop. And the data inconsistency that cascades through three other services? That's emergent behaviour. Nobody designed that failure. It emerged from the relationships.
There are four levels of systems thinking. Events — what happened. "The deployment failed." Patterns — what happens repeatedly. "Deployments fail every Friday." Structure — what causes the patterns. "Friday deploys fail because the staging environment is shared and overloaded." Mental models — what beliefs create the structure. "We share staging because we believe separate environments are too expensive."
Architects operate at levels three and four — they see structure and the beliefs that create it.
Architects see relationships and feedback loops, not just components.
Try it yourself — The feedback loop hunt
Think of a recurring problem in your system. Now trace it through the four levels:
| Level | Your answer |
|---|---|
| Event — What happened? | e.g. The deployment failed |
| Pattern — What happens repeatedly? | |
| Structure — What causes the pattern? | |
| Mental model — What belief created the structure? |
Most people get stuck at level one. The fix lives at level three or four.
3. Abstraction — Choosing the right level of detail
Here's something that trips up a lot of architects: showing an executive a class diagram is as unhelpful as showing a developer a strategy slide.
Abstraction is the skill of choosing what to show and what to hide — for the audience and the decision at hand.
Think of it as a ladder:
Vision → "We will be a platform business"
Strategy → "We will build a shared API gateway"
Architecture → "The gateway handles auth, routing, rate limiting"
Design → "The auth module uses OAuth2 with JWT"
Implementation→ "This function validates the JWT signature"
Architects move up and down this ladder — choosing the right level for the right audience and the right decision.
flowchart TD
L5["🎯 Vision\nWhy we exist"]
L4["🧭 Strategy\nWhere we are going"]
L3["🏗️ Architecture\nHow we are structured"]
L2["📐 Design\nHow this component works"]
L1["💻 Implementation\nHow this code works"]
L5 --> L4 --> L3 --> L2 --> L1
Here's the part that catches people out: the same architecture decision gets communicated three different ways. To an executive: "We are consolidating to reduce cost and risk." To engineering: "We are merging three services into one using the strangler fig pattern over six months." To a developer: "The new service exposes these three APIs and replaces these endpoints."
Same decision. Three abstraction levels. All correct.
Abstraction = choosing what to show and what to hide.
Try it yourself — The abstraction ladder
Take a real architecture decision from your team. Now write it at three levels:
| Level | Your version |
|---|---|
| Executive — outcomes, risk, investment | |
| Engineering — boundaries, patterns, timeline | |
| Developer — APIs, endpoints, migration |
If you wrote the same thing for all three, you haven't abstracted — you've just copied.
4. The dual lens — Business and technical, simultaneously
Most roles see one side. Developers see technology. Business stakeholders see outcomes. Architects must see both — simultaneously.
Here's the truth: the best architecture decision isn't the best technology. It's the best technology given the business context — budget, timeline, team capability, strategic direction, and risk tolerance.
The dual lens looks like this:
flowchart LR
B["Business Lens\nWhat do we need?\nWhat can we afford?\nWhat is the risk?"] -->|"filtered through"| A["🏗️ Architecture Decision"]
T["Technology Lens\nWhat is possible?\nWhat is proven?\nWhat is maintainable?"] -->|"filtered through"| A
A --> BALANCED["Balanced Decision\nNot optimal technically\nNot optimal commercially\nBut optimal for this context"]
Every architect navigates five tensions:
Speed vs quality — ship fast, learn fast versus ship right, avoid rework. Build vs buy — own the differentiation versus buy the commodity. Innovation vs stability — try new things versus run what we have. Centralisation vs autonomy — consistency and control versus speed and ownership. Short-term vs long-term — this quarter's goals versus next year's flexibility.
A technically superior solution that the business can't afford isn't a good architecture decision. A business requirement that can't be met with available technology is a constraint to negotiate, not a design to force.
Architects hold business and technical concerns simultaneously.
Try it yourself — The tension map
Which of the five tensions is most active in your team right now?
| Tension | Which pole are you leaning toward? | Is it the right call for your context? |
|---|---|---|
| Speed vs quality | ||
| Build vs buy | ||
| Innovation vs stability | ||
| Centralisation vs autonomy | ||
| Short-term vs long-term |
If you can't answer the second column, you're not making a deliberate trade-off — you're drifting.
5. Deciding under uncertainty — Principles when facts are missing
Architects rarely have complete information. Waiting for perfect information means deciding too late. Acting on too little information means deciding badly.
Here's the reality:
- You will never have all the facts
- Requirements will change after you decide
- Technology will evolve after you choose
- The team's capabilities will shift
- The business context won't stand still
The skill is making good-enough decisions with available information — and knowing when to revisit.
flowchart TD
UNCERTAINTY["Uncertainty"] --> PRINCIPLES["Use Principles\nWhen facts are missing,\nprinciples guide decisions"]
UNCERTAINTY --> REVERSIBLE["Prefer Reversible\nChoose options that\ncan be changed later"]
UNCERTAINTY --> EXPERIMENT["Experiment\nTest assumptions\nbefore committing"]
UNCERTAINTY --> DEFER["Defer Irreversible\nDelay big decisions\nuntil necessary"]
PRINCIPLES --> GOOD["Good-enough decision\nMade on time"]
REVERSIBLE --> GOOD
EXPERIMENT --> GOOD
DEFER --> GOOD
The most useful distinction an architect can make: reversible versus irreversible decisions. Reversible decisions should be made fast — low cost of being wrong, learn and adapt. Irreversible decisions should be made carefully — high cost of being wrong, gather more data.
Choosing which library to try? Reversible. Decide fast. Choosing a database technology? Irreversible. Decide carefully.
Architects use heuristics when facts are missing. Prefer reversible decisions — choose options that can be changed later. Last responsible moment — delay irreversible decisions until you must decide. Design for change — assume requirements will change. YAGNI — don't build for hypothetical futures. Conway's Law — design team structure to match desired architecture. Chesterton's Fence — don't change what you don't understand.
Architecture is decision-making under uncertainty — using principles when facts are missing.
Try it yourself — The reversibility test
List three pending decisions from your team. For each one:
| Decision | Reversible or irreversible? | Should you decide fast or carefully? |
|---|---|---|
If you're treating irreversible decisions like reversible ones, you're gambling. If you're treating reversible ones like irreversible, you're paralysed.
6. Trade-off thinking — No perfection, only choices
There is no perfect architecture. Every choice costs something. Architects who seek the "best" solution paralyse themselves.
Trade-off thinking means explicitly choosing what to sacrifice. Not avoiding sacrifice — choosing it deliberately.
The truth about trade-offs:
- Every pattern solves something and sacrifices something
- Every technology choice has a cost — money, complexity, lock-in, learning curve
- Every design decision optimises for one thing at the expense of another
- The question is never "Is this good?" — it is "Is this the right trade-off for this context?"
flowchart LR
SPEED["Speed to Market"] <-->|"trade-off"| QUALITY["Quality & Robustness"]
COST["Low Cost"] <-->|"trade-off"| CONTROL["Full Control"]
FLEX["Flexibility"] <-->|"trade-off"| SIMPLICITY["Simplicity"]
INNOVATION["Innovation"] <-->|"trade-off"| STABILITY["Stability"]
Here's the framework I use for every trade-off. What do we optimise for? What do we sacrifice? What risk does this create? Can we reverse this later? The reason for the trade-off gets documented — in an ADR, in a decision log, somewhere that future teams can find it.
"No trade-off" means "I haven't thought about what this costs" — which is worse than a deliberate trade-off.
Architecture is the discipline of informed trade-offs — not the pursuit of perfection.
Try it yourself — The trade-off frame
Think of a recent technology decision. Now fill in the frame:
| Question | Your answer |
|---|---|
| What did we optimise for? | |
| What did we sacrifice? | |
| What risk does this create? | |
| Can we reverse it later? | |
| Would we make the same decision today? |
If you can't answer the second question, you didn't make a trade-off — you made a choice without seeing the cost.
7. How architects communicate — Creating shared understanding
A great architecture that no one understands is useless. Architects must communicate decisions to audiences who think differently.
Architects translate between worlds — technical to business, business to technical, team to team, past decisions to future context.
The communication skills that matter:
Translate — convert technical concepts into business language and vice versa. Simplify — choose the right abstraction level for the audience. Persuade — influence decisions without authority. Document — create artefacts that outlast conversations. Listen — understand stakeholder concerns before proposing solutions.
flowchart TD
ARCH["🏗️ Architect"] --> T1["Translate\nBusiness ↔ Technical"]
ARCH --> T2["Simplify\nRight abstraction level"]
ARCH --> T3["Persuade\nInfluence without authority"]
ARCH --> T4["Document\nADRs, views, principles"]
ARCH --> T5["Listen\nUnderstand before proposing"]
T1 --> SHARED["Shared Understanding"]
T2 --> SHARED
T3 --> SHARED
T4 --> SHARED
T5 --> SHARED
The influence model is simple but most architects skip step one. Listen — understand concerns and context. Understand — map stakeholders and their incentives. Frame — present options, not prescriptions. Align — find common ground and shared goals. Decide — document the choice and rationale. Communicate — share the decision with all affected.
Architecture that isn't communicated doesn't influence decisions — it sits in a drawer.
Architects communicate to create shared understanding — not to prove they are right.
Try it yourself — The audience test
Take an architecture decision you need to communicate. Write it for three audiences:
| Audience | What they need to hear | What they don't need |
|---|---|---|
| Executive | Outcomes, risk, investment | API contracts, integration patterns |
| Engineering lead | Boundaries, patterns, timeline | Vision slides, business cases |
| Developer | APIs, migration path, constraints | Enterprise architecture diagrams |
If you wrote the same thing for all three, go back to the abstraction exercise.
Putting it all together
Here's the complete picture in one diagram. This is the mental model worth internalising.
flowchart TD
THINK["🧠 How Architects Think"]
THINK --> S["Systems Thinking\nSee wholes, not parts"]
THINK --> A["Abstraction\nRight level for right audience"]
THINK --> B["Business + Technical\nHold both simultaneously"]
THINK --> U["Uncertainty\nDecide with incomplete info"]
THINK --> T["Trade-offs\nNo perfection, only choices"]
THINK --> C["Communication\nCreate shared understanding"]
S --> SKILL["🏗️ Architecture Skill"]
A --> SKILL
B --> SKILL
U --> SKILL
T --> SKILL
C --> SKILL
The foundation:
Systems thinking — see relationships and feedback loops, not just components. Abstraction — move up and down the ladder; choose the right level for the right audience. Dual lens — hold business and technical concerns simultaneously. Uncertainty — decide with incomplete information using principles. Trade-offs — there's no perfect architecture; every decision optimises for something and sacrifices something else. Communication — create shared understanding, don't prove you're right. Architecture is a judgment craft. The thinking matters more than the tools.
Cheat Sheet — All the key terms
| Thinking Skill | What It Means | Key Question |
|---|---|---|
| Systems thinking | See wholes, relationships, feedback loops | "How does this affect the whole?" |
| Abstraction | Choose the right level of detail | "What does this audience need to see?" |
| Dual lens | Hold business and technical simultaneously | "Does this serve both goals and feasibility?" |
| Uncertainty | Decide with incomplete information | "What do I need to know before deciding?" |
| Trade-offs | Accept imperfection deliberately | "What am I optimising for, and what am I sacrificing?" |
| Communication | Create shared understanding | "Does my audience understand the decision and why?" |
How to know if this landed
You'll know this has landed when someone stops asking "what's the right technology?" and starts asking "what's the right trade-off for our context?" They can identify feedback loops in their own systems. They adjust their communication abstraction level by audience without being told. They make decisions without waiting for complete information — and document the rationale alongside the choice. They frame decisions as trade-offs, not absolutes. And they listen to stakeholder concerns before proposing solutions.
What changes when the mental model clicks
I've run this session with architects who produced technically excellent designs that teams ignored. The gap at the start is usually not about technical depth — it's about thinking in the wrong frame. They're optimising for technical elegance when the context demands business fit. They're waiting for perfect data when the context demands a good-enough decision now.
What changes after this session:
Architects stop seeking the "best" solution and start seeking the best trade-off for the context. The reversibility test — "is this decision reversible, and if not, am I deciding carefully enough?" — is always the moment things click. People stop waiting for perfect data and start using principles when facts are missing. Their results get better. They stop being seen as ivory-tower thinkers and start being seen as enablers.
The abstraction exercise tends to immediately change how architects communicate. They start writing three versions of the same decision — executive, engineering, developer. Their acceptance rate goes up. They stop blaming the audience when the real problem was that they presented at the wrong level.
Book a Workshop
Ready to develop architectural thinking in your teams?
or
1-day workshop includes systems thinking exercises with real systems, abstraction ladder practice with different audiences, trade-off analysis workshop with real decisions, decision heuristics reference card, and communication format templates for each audience type.