The library

129 models

Search across every field, from names and thinkers to examples, then filter by discipline, role, situation, or thinker. Press ⌘K anywhere to jump straight to a model.

No. 001Ways of Thinking
The Map Is Not the Territory
Every diagram, model, and dashboard is a simplification. The running system is the truth.
No. 002Ways of Thinking
First Principles Thinking
Break a problem down to what must be true, then rebuild the solution from there instead of copying others.
No. 003Ways of Thinking
Second-Order Thinking
Ask “and then what?” The consequences of consequences are where architectures succeed or fail.
No. 004Ways of Thinking
Inversion and the Pre-mortem
Instead of asking how to succeed, ask what would guarantee failure — then avoid it.
No. 005Ways of Thinking
Occam's Razor
Among designs or explanations that fit the facts, prefer the one with the fewest assumptions.
No. 006Ways of Thinking
Circle of Competence
Know the boundary of what you genuinely understand, and act differently inside and outside it.
No. 007Ways of Thinking
One-Way vs Two-Way Doors
Match decision rigour to reversibility: decide reversible choices fast and irreversible ones carefully.
No. 008Ways of Thinking
Probabilistic Thinking
Reason in likelihoods and distributions, not certainties and averages.
No. 009Ways of Thinking
The Algorithm: Question, Delete, Simplify, Accelerate, Automate
Make the requirements less dumb, delete what you can, and only then simplify, speed up and automate — in that order.
No. 010Ways of Thinking
Cynefin
First work out what kind of situation you are in, because clear, complicated, complex and chaotic problems each need a different way of deciding.
No. 011Ways of Thinking
Amara's Law
We tend to overestimate the effect of a technology in the short run and underestimate it in the long run, so plan for both the hype and the structural change.
No. 012Ways of Thinking
OODA Loop
Observe, orient, decide and act in a continuous loop; orientation shapes everything else, and whoever cycles faster and better gains the advantage.
No. 013Ways of Thinking
Satisficing
With limited time, information and attention, set a clear bar for good enough and take the first option that meets it, instead of searching for the best.
No. 014Ways of Thinking
Decisions vs Outcomes (Resulting)
Judge a decision by the process and the information available at the time, not by how it turned out, because outcomes mix skill with luck.
No. 015Systems & Structure
Coupling and Cohesion
Keep things that change together close together, and things that change independently apart.
No. 016Systems & Structure
Separation of Concerns
Divide a system so each part addresses one distinct concern and can be reasoned about on its own.
No. 017Systems & Structure
Bounded Context
A model is only valid inside an explicit boundary; the same word can mean different things in different contexts.
No. 018Systems & Structure
Law of Leaky Abstractions
All non-trivial abstractions leak; eventually you have to understand what is beneath them.
No. 019Systems & Structure
Postel's Law
Be conservative in what you send and liberal in what you accept.
No. 020Systems & Structure
Hyrum's Law
With enough users, every observable behaviour of your API will be depended on by somebody.
No. 021Systems & Structure
Theory of Constraints
A system's throughput is set by its bottleneck; improving anything else is an illusion.
No. 022Systems & Structure
Feedback Loops
Outputs that circle back as inputs either stabilise a system (balancing) or amplify it (reinforcing).
No. 023Systems & Structure
Emergence
The behaviour of the whole arises from interactions between parts and cannot be predicted from any part alone.
No. 024Distributed Systems & Data
CAP and PACELC
During a partition you choose consistency or availability; otherwise you trade latency against consistency.
No. 025Distributed Systems & Data
Fallacies of Distributed Computing
The network is not reliable, latency is not zero, and bandwidth is not infinite. Design as if you know it.
No. 026Distributed Systems & Data
Little's Law
Items in a system equal arrival rate multiplied by time in the system: L = λW.
No. 027Distributed Systems & Data
Amdahl's Law
The speedup from parallelising is capped by the part that cannot be parallelised.
No. 028Distributed Systems & Data
Universal Scalability Law
Beyond a point, adding capacity makes systems slower, because coordination costs outgrow capacity.
No. 029Distributed Systems & Data
Data Gravity
Data attracts applications, services, and more data — and the bigger it gets, the harder it is to move.
No. 030Distributed Systems & Data
Idempotency
Design operations so doing them twice has the same effect as doing them once.
No. 031Distributed Systems & Data
Backpressure
When a consumer cannot keep up, it must be able to slow the producer — or the system falls over.
No. 032Distributed Systems & Data
Eventual Consistency
Replicas may disagree for a while but converge when updates stop. Design the business around the window.
No. 033Trade-offs & Economics
Everything Is a Trade-off
There are no best practices, only trade-offs in context. If you can't name the downside, you don't understand the choice.
No. 034Trade-offs & Economics
Technical Debt as Interest
Shortcuts are loans: they buy speed today and charge interest on every future change.
No. 035Trade-offs & Economics
Cost of Delay
Quantify what it costs not to have something yet, then prioritise by value lost per unit of time.
No. 036Trade-offs & Economics
Last Responsible Moment
Delay irreversible commitments until the point where waiting would eliminate an important option.
No. 037Trade-offs & Economics
Innovation Tokens
Every organisation can afford only a few novel technologies. Spend them where they create real advantage.
No. 038Trade-offs & Economics
Total Cost of Ownership
The purchase price is the smallest part of what a technology costs over its lifetime.
No. 039Trade-offs & Economics
Sunk Cost Fallacy
Past investment is gone either way. Decide based on future costs and benefits only.
No. 040Trade-offs & Economics
Pareto Principle
A minority of causes drives the majority of effects. Find the vital few.
No. 041Trade-offs & Economics
Jevons Paradox
Making a resource cheaper or more efficient often increases total consumption of it.
No. 042Risk & Resilience
Margin of Safety
Build in buffer for what you can't predict. The future is usually worse than the plan.
No. 043Risk & Resilience
Blast Radius
Limit how much can break when any one thing fails.
No. 044Risk & Resilience
Single Point of Failure
Any component whose failure stops the whole system is a risk you've chosen, knowingly or not.
No. 045Risk & Resilience
Defense in Depth
Layer independent safeguards so no single failure leads to compromise.
No. 046Risk & Resilience
Swiss Cheese Model
Accidents happen when holes in several imperfect defences line up at the same moment.
No. 047Risk & Resilience
Graceful Degradation
When parts fail, keep the core experience working instead of failing completely.
No. 048Risk & Resilience
Antifragility and Chaos Engineering
Some systems get stronger from stress. Inject failure deliberately to find weaknesses before they find you.
No. 049Risk & Resilience
Normal Accidents
In tightly coupled, interactively complex systems, accidents are inevitable — they are normal.
No. 050Risk & Resilience
Ironies of Automation
Automating the routine work leaves people with the hardest tasks, monitoring they do poorly, and fading skills, just when a failure needs them most.
No. 051Change & Evolution
Gall's Law
A complex system that works evolved from a simple system that worked.
No. 052Change & Evolution
Strangler Fig
Replace a legacy system gradually by growing the new one around it until the old one can be removed.
No. 053Change & Evolution
Fitness Functions
Protect the qualities that matter with automated checks, so the architecture can change safely.
No. 054Change & Evolution
Chesterton's Fence
Don't remove a fence until you know why it was put up.
No. 055Change & Evolution
Lehman's Laws of Software Evolution
A system in use must keep changing, and its complexity grows unless work is done to reduce it.
No. 056Change & Evolution
Inertia (Legacy Gravity)
Established systems keep doing what they're doing unless a force greater than their momentum acts on them.
No. 057Change & Evolution
Red Queen Effect
You have to keep running just to stay in the same place.
No. 058Change & Evolution
Lindy Effect
For technologies and ideas, every year they survive increases their expected remaining life.
No. 059Change & Evolution
Pace Layering
Layers of a system change at different speeds. Let fast layers move without disturbing slow ones.
No. 060Change & Evolution
Automate or Obliterate
Speeding up an old process with new technology mostly preserves its waste; redesign the work around the outcome, using what the technology makes possible.
No. 061People, Org & Influence
Conway's Law
Organisations design systems that mirror their own communication structures.
No. 062People, Org & Influence
Inverse Conway Maneuver
Shape your teams to match the architecture you want, and the system will follow.
No. 063People, Org & Influence
Cognitive Load
A team can only hold so much in its head; architecture should fit within that limit.
No. 064People, Org & Influence
Incentives
Show me the incentive and I will show you the outcome.
No. 065People, Org & Influence
Goodhart's Law
When a measure becomes a target, it ceases to be a good measure.
No. 066People, Org & Influence
Brooks's Law
Adding people to a late software project makes it later.
No. 067People, Org & Influence
Bikeshedding (Law of Triviality)
Groups spend disproportionate time on trivial issues because everyone feels qualified to discuss them.
No. 068People, Org & Influence
Hanlon's Razor
Never attribute to malice what can be explained by missing information, constraints, or honest mistakes.
No. 069People, Org & Influence
Relativity (Stakeholder Frames)
Every observer sees the system from their own frame; none of them sees the whole truth.
No. 070People, Org & Influence
Ubiquitous Language
Use one vocabulary, shared by domain experts and developers, in conversation, documents and code alike.
No. 071People, Org & Influence
The Pyramid Principle
Start with the answer, then give the few reasons that support it, then the evidence for each.
No. 072People, Org & Influence
Ladder of Inference
We climb from a few selected facts to firm beliefs in seconds; walk back down the ladder together to resolve disagreement.
No. 073People, Org & Influence
Disagree and Commit
Argue openly until the decision is made, then everyone backs it fully — including those who argued against it.
No. 074People, Org & Influence
Influence Without Authority
When you can't tell people what to do, trade: offer what they value in return for what you need.
No. 075People, Org & Influence
Power–Interest Grid
Map stakeholders by how much power they have over the outcome and how much they care, and engage each group differently.
No. 076People, Org & Influence
C4 Model (Zoom Levels for Audiences)
Draw architecture as a few maps at different zoom levels — context, containers, components, code — and show each audience the level it needs.
No. 077People, Org & Influence
Curse of Knowledge
Once you know something, it is hard to imagine not knowing it, so experts explain too little, too abstractly.
No. 078People, Org & Influence
Decision Rights (Who Has the D?)
For each important decision, make clear who recommends, who must agree, who gives input, who carries it out, and the one person who decides.
No. 079Strategy & Enterprise
Wardley Mapping
Map components by the value they provide and how evolved they are, from genesis to commodity.
No. 080Strategy & Enterprise
Core vs Context
Invest in what differentiates you; standardise or outsource everything else.
No. 081Strategy & Enterprise
Capability Mapping
Describe what the business does, independent of how, by whom, or with which system.
No. 082Strategy & Enterprise
Platforms and Network Effects
A platform's value grows with each participant — design for adoption, not just function.
No. 083Strategy & Enterprise
Build, Buy, or Partner
Choose the sourcing model by differentiation, market maturity, and your ability to operate it.
No. 084Strategy & Enterprise
Ecosystems
Your architecture lives in a wider habitat of partners, vendors, regulators, and standards — design for the whole of it.
No. 085Strategy & Enterprise
Optionality
Prefer positions that give you the right, but not the obligation, to act in the future.
No. 086Strategy & Enterprise
Operating Model (Standardisation and Integration)
Decide how standardised your business processes must be and how tightly units must share data; the architecture follows from that choice.
No. 087Strategy & Enterprise
TIME Portfolio Triage
Sort each application by business value and technical quality into Tolerate, Invest, Migrate or Eliminate, and fund it accordingly.
No. 088Strategy & Enterprise
Three Horizons
Manage the core, the emerging and the future at the same time, with different goals, measures and funding for each.
No. 089Strategy & Enterprise
Guardrails, Not Gates
Govern by setting clear, ideally automated, boundaries and paved roads, and review only what crosses them, instead of making every change queue for approval.
No. 090Strategy & Enterprise
Data as a Product (Data Mesh)
Domains own and publish their data as products, discoverable, addressable, trustworthy and self-describing, instead of a central team piping everything into a lake.
No. 091Strategy & Enterprise
Exit Strategy (Lock-in as a Design Input)
Decide how you would leave a vendor or platform before you commit, and trade the switching cost consciously against the value the dependency brings.
No. 092Strategy & Enterprise
The Nature of the Firm (Transaction Costs)
Firms exist because using the market has costs; an activity belongs inside when organising it there is cheaper than buying it, so when those costs change, the boundaries should too.
No. 093Product Thinking
Jobs to Be Done
People hire a product to make progress in a particular circumstance; understand the job and its circumstance, not the customer's demographic profile.
No. 094Product Thinking
Kano Model
Not all qualities satisfy in the same way: some are expected, some please in proportion, some delight, and today's delighters become tomorrow's expectations.
No. 095Product Thinking
Build–Measure–Learn
Treat each product idea as a hypothesis: build the smallest thing that tests it, measure what people actually do, and decide whether to pivot or persevere.
No. 096Product Thinking
Opportunity Solution Tree
Map a desired outcome to the customer opportunities that could drive it, the solutions that might address each opportunity, and the assumption tests that check each solution.
No. 097Product Thinking
Outcomes Over Output
Judge and steer work by the change in human behaviour it creates, not by the features, projects or code it produces.
No. 098Product Thinking
The Four Big Risks
Before building, address four risks: value (will they use or buy it), usability (can they work it out), feasibility (can we build it) and business viability (does it work for the business).
No. 099AI Systems
The Bitter Lesson
General methods that scale with computation beat clever, hand-built knowledge — eventually, and by a large margin.
No. 100AI Systems
Software 2.0
Some software is no longer written as code but learned from data; the dataset and the objective become the program.
No. 101AI Systems
Scaling Laws
Model capability improves predictably as compute, data and model size grow, so plan for the models of next year, not today.
No. 102AI Systems
Workflows Before Agents
Use the simplest LLM design that works; add agent autonomy only when a problem truly needs it.
No. 103AI Systems
Context Engineering
A model's context window is a limited budget; curate the smallest set of high-signal tokens it needs for the task.
No. 104AI Systems
Context vs Behaviour
Diagnose an LLM failure first: missing knowledge needs better context; wrong behaviour needs better prompting or tuning.
No. 105AI Systems
The Jagged Frontier
AI is excellent at some tasks and unreliable at others of similar difficulty — and the boundary is invisible until you test it.
No. 106AI Systems
The Lethal Trifecta
An AI agent that combines private data, untrusted content and a way to send data out can be tricked into leaking it.
No. 107AI Systems
The Autonomy Slider
Give AI as much autonomy as you can verify quickly — and let people move the slider up as trust grows.
No. 108AI Systems
The Dynamo Lesson (Productivity Paradox)
A general-purpose technology pays off only when work and organisation are redesigned around it, and that takes years; dropping it into the old layout gives little.
No. 109AI Systems
Evals as Fitness Functions
AI behaviour is probabilistic and shifts with every model, prompt and data change, so check quality with automated evaluations on real cases, run on every change and tracked over time.
No. 110AI Systems
Machine-Usable Interfaces
AI agents can only automate what they can reach, so expose business capabilities as documented, permissioned, stable interfaces rather than screens built for people.
No. 111AI Systems
Moravec's Paradox
What is hard for people is often easy for machines and what is effortless for people is often hard, so intuition about which tasks AI will find easy is unreliable.
No. 112From the Masters
The Architect Elevator
Ride between the penthouse and the engine room: connect business strategy with technical reality.
No. 113From the Masters
Architects See More Dimensions
Many either-or conflicts dissolve once you add a dimension the debaters are not seeing.
No. 114From the Masters
Starbucks Does Not Use Two-Phase Commit
Real businesses scale through asynchronous, compensating processes, not distributed transactions.
No. 115From the Masters
Economies of Speed
Digital organisations win by how quickly they can learn and change, not by how big they are.
No. 116From the Masters
Architecture Is About the Important Stuff
Architecture is the set of decisions that are hard to change, whatever those turn out to be.
No. 117From the Masters
Monolith First
Start with a well-structured monolith; split into services only once the boundaries and the need are proven.
No. 118From the Masters
Microservice Premium
Microservices carry a fixed overhead that only pays off above a certain level of complexity.
No. 119From the Masters
Sacrificial Architecture
Design knowing you may throw the system away, and treat that as a sign of success.
No. 120From the Masters
Design Stamina Hypothesis
Good internal design slows you briefly; past the payoff line it is what keeps you fast.
No. 121From the Masters
Technical Debt Quadrant
Classify debt as deliberate or inadvertent, and prudent or reckless; each needs a different response.
No. 122From the Masters
Anti-Corruption Layer
Protect your domain model by translating at the boundary with systems whose models you don't control.
No. 123From the Masters
Architecture Decision Records
Capture the why behind significant decisions in short, immutable records future teams can read.
No. 124From the Masters
Circuit Breaker
Stop calling a failing dependency for a while, so its failure doesn't become yours.
No. 125From the Masters
Why Is More Important Than How
The second law of software architecture: a design only makes sense once you know why it was chosen.
No. 126From the Masters
Conceptual Integrity
A system should reflect one coherent set of design ideas, even at the cost of some features.
No. 127From the Masters
Everything Fails, All the Time
At scale, failure is the normal state. Design for it rather than hoping to prevent it.
No. 128From the Masters
Make the Change Easy, Then Make the Easy Change
When a change is hard, first reshape the system so the change becomes easy.
No. 129From the Masters
Information Hiding
Decompose systems around the decisions most likely to change, and hide each behind an interface.

The Map Is Not the Territory

First Principles Thinking

Second-Order Thinking

Inversion and the Pre-mortem

Occam's Razor

Circle of Competence

One-Way vs Two-Way Doors

Probabilistic Thinking

The Algorithm: Question, Delete, Simplify, Accelerate, Automate

Cynefin

Amara's Law

OODA Loop

Satisficing

Decisions vs Outcomes (Resulting)

Coupling and Cohesion

Separation of Concerns

Bounded Context

Law of Leaky Abstractions

Postel's Law

Hyrum's Law

Theory of Constraints

Feedback Loops

Emergence

CAP and PACELC

Fallacies of Distributed Computing

Little's Law

Amdahl's Law

Universal Scalability Law

Data Gravity

Idempotency

Backpressure

Eventual Consistency

Everything Is a Trade-off

Technical Debt as Interest

Cost of Delay

Last Responsible Moment

Innovation Tokens

Total Cost of Ownership

Sunk Cost Fallacy

Pareto Principle

Jevons Paradox

Margin of Safety

Blast Radius

Single Point of Failure

Defense in Depth

Swiss Cheese Model

Graceful Degradation

Antifragility and Chaos Engineering

Normal Accidents

Ironies of Automation

Gall's Law

Strangler Fig

Fitness Functions

Chesterton's Fence

Lehman's Laws of Software Evolution

Inertia (Legacy Gravity)

Red Queen Effect

Lindy Effect

Pace Layering

Automate or Obliterate

Conway's Law

Inverse Conway Maneuver

Cognitive Load

Incentives

Goodhart's Law

Brooks's Law

Bikeshedding (Law of Triviality)

Hanlon's Razor

Relativity (Stakeholder Frames)

Ubiquitous Language

The Pyramid Principle

Ladder of Inference

Disagree and Commit

Influence Without Authority

Power–Interest Grid

C4 Model (Zoom Levels for Audiences)

Curse of Knowledge

Decision Rights (Who Has the D?)

Wardley Mapping

Core vs Context