Cheatsheet

129 models, one page

Ways of Thinking

The Map Is Not the Territory: Every diagram, model, and dashboard is a simplification. The running system is the truth.; When was this diagram last checked against production?
First Principles Thinking: Break a problem down to what must be true, then rebuild the solution from there instead of copying others.; Which of these are real constraints, and which are just habits?
Second-Order Thinking: Ask “and then what?” The consequences of consequences are where architectures succeed or fail.; If this works, what happens next, and after that?
Inversion and the Pre-mortem: Instead of asking how to succeed, ask what would guarantee failure — then avoid it.; Imagine this has failed a year from now. What is the most likely reason?
Occam's Razor: Among designs or explanations that fit the facts, prefer the one with the fewest assumptions.; What is the simplest design that meets the real requirements?
Circle of Competence: Know the boundary of what you genuinely understand, and act differently inside and outside it.; Which parts of this decision sit inside my real expertise, and which are informed guesses?
One-Way vs Two-Way Doors: Match decision rigour to reversibility: decide reversible choices fast and irreversible ones carefully.; What would it cost to reverse this in twelve months, once data and users depend on it?
Probabilistic Thinking: Reason in likelihoods and distributions, not certainties and averages.; What does the tail look like, not just the average?
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.; Who, by name, asked for this requirement, and is it still right?
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.; Can an expert tell us the answer, or will we only know by trying something?
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.; Which of this year's AI promises are we funding as if they were already proven?
OODA Loop: Observe, orient, decide and act in a continuous loop; orientation shapes everything else, and whoever cycles faster and better gains the advantage.; What are we actually observing, and what is our orientation filtering out?
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.; What would good enough look like here, written down before we compare options?
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.; Given what we knew at the time, was this a reasonable decision, regardless of how it turned out?

Systems & Structure

Coupling and Cohesion: Keep things that change together close together, and things that change independently apart.; When this changes, what else has to change and be released with it?
Separation of Concerns: Divide a system so each part addresses one distinct concern and can be reasoned about on its own.; What is this component's single reason to exist, in one sentence?
Bounded Context: A model is only valid inside an explicit boundary; the same word can mean different things in different contexts.; When we say this term, does every team in the room mean the same thing by it?
Law of Leaky Abstractions: All non-trivial abstractions leak; eventually you have to understand what is beneath them.; Where will this abstraction leak under load, failure or unusual input?
Postel's Law: Be conservative in what you send and liberal in what you accept.; Will our consumers break if a producer adds a field they don't recognise?
Hyrum's Law: With enough users, every observable behaviour of your API will be depended on by somebody.; What observable behaviour are we promising without meaning to — ordering, timing, error text?
Theory of Constraints: A system's throughput is set by its bottleneck; improving anything else is an illusion.; Where does work queue up and wait, in the system or in the delivery process?
Feedback Loops: Outputs that circle back as inputs either stabilise a system (balancing) or amplify it (reinforcing).; Which loops here are reinforcing, and which are balancing?
Emergence: The behaviour of the whole arises from interactions between parts and cannot be predicted from any part alone.; What behaviour only appears when these parts interact under real load?

Distributed Systems & Data

CAP and PACELC: During a partition you choose consistency or availability; otherwise you trade latency against consistency.; During a partition, should this operation fail or serve possibly stale 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.; What exactly happens when this call times out — for the caller, the callee and the user?
Little's Law: Items in a system equal arrival rate multiplied by time in the system: L = λW.; What are the arrival rate and the average time in the system here?
Amdahl's Law: The speedup from parallelising is capped by the part that cannot be parallelised.; What fraction of this work is inherently serial, and have we measured it?
Universal Scalability Law: Beyond a point, adding capacity makes systems slower, because coordination costs outgrow capacity.; How does measured throughput change as we add nodes, and have we measured beyond today's size?
Data Gravity: Data attracts applications, services, and more data — and the bigger it gets, the harder it is to move.; Where does this data live today, and where will most of its growth happen?
Idempotency: Design operations so doing them twice has the same effect as doing them once.; What happens if this request or message is processed twice?
Backpressure: When a consumer cannot keep up, it must be able to slow the producer — or the system falls over.; What happens when the consumer is slower than the producer for an hour?
Eventual Consistency: Replicas may disagree for a while but converge when updates stop. Design the business around the window.; How long can this data be inconsistent, and who would notice?

Trade-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.; What are we giving up by choosing this option?
Technical Debt as Interest: Shortcuts are loans: they buy speed today and charge interest on every future change.; Is this debt deliberate or accidental?
Cost of Delay: Quantify what it costs not to have something yet, then prioritise by value lost per unit of time.; What does it cost the business, per week, not to have this yet?
Last Responsible Moment: Delay irreversible commitments until the point where waiting would eliminate an important option.; When must this decision really be made, and what happens if we miss that date?
Innovation Tokens: Every organisation can afford only a few novel technologies. Spend them where they create real advantage.; Is this new technology part of what differentiates us, or could a boring option do the job?
Total Cost of Ownership: The purchase price is the smallest part of what a technology costs over its lifetime.; What does this cost over five years, including people's time?
Sunk Cost Fallacy: Past investment is gone either way. Decide based on future costs and benefits only.; If we were starting today, with what we now know, would we choose this path?
Pareto Principle: A minority of causes drives the majority of effects. Find the vital few.; Which few items drive most of the cost, load or risk here?
Jevons Paradox: Making a resource cheaper or more efficient often increases total consumption of it.; If this gets cheaper or easier, how much more will people use it?

Risk & Resilience

Margin of Safety: Build in buffer for what you can't predict. The future is usually worse than the plan.; How much headroom do we have today, and what is eating into it?
Blast Radius: Limit how much can break when any one thing fails.; If this fails at 3am, which customers are affected, and how many?
Single Point of Failure: Any component whose failure stops the whole system is a risk you've chosen, knowingly or not.; What is the one thing that, if it vanished tonight, would stop us?
Defense in Depth: Layer independent safeguards so no single failure leads to compromise.; If this control fails, what stops the attacker at the next step?
Swiss Cheese Model: Accidents happen when holes in several imperfect defences line up at the same moment.; Which defences should have caught this, and why didn't each of them?
Graceful Degradation: When parts fail, keep the core experience working instead of failing completely.; What is the one function that must keep working when everything else is failing?
Antifragility and Chaos Engineering: Some systems get stronger from stress. Inject failure deliberately to find weaknesses before they find you.; When did we last test this failure mode on purpose, and what did we change as a result?
Normal Accidents: In tightly coupled, interactively complex systems, accidents are inevitable — they are normal.; If one part of this fails, how quickly does the failure reach the next part?
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.; When the AI gets it wrong, who notices, how, and what do they need to know to take over?

Change & Evolution

Gall's Law: A complex system that works evolved from a simple system that worked.; What is the simplest version that works end to end, and when can it be live?
Strangler Fig: Replace a legacy system gradually by growing the new one around it until the old one can be removed.; Where can we intercept traffic to the legacy system?
Fitness Functions: Protect the qualities that matter with automated checks, so the architecture can change safely.; Which architectural qualities do we most want to protect as the system changes?
Chesterton's Fence: Don't remove a fence until you know why it was put up.; Why was this built this way, and what problem was it solving at the time?
Lehman's Laws of Software Evolution: A system in use must keep changing, and its complexity grows unless work is done to reduce it.; What share of our capacity goes to simplification, not just features?
Inertia (Legacy Gravity): Established systems keep doing what they're doing unless a force greater than their momentum acts on them.; What gives this system its momentum — integrations, data, skills, contracts or habits?
Red Queen Effect: You have to keep running just to stay in the same place.; How far behind current, supported versions are we, and how fast is the gap growing?
Lindy Effect: For technologies and ideas, every year they survive increases their expected remaining life.; How long has this technology existed, and how widely is it used?
Pace Layering: Layers of a system change at different speeds. Let fast layers move without disturbing slow ones.; What is the natural rate of change for each layer of this system?
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.; If we designed this process today, starting from the outcome the customer wants, would these steps exist at all?

People, Org & Influence

Conway's Law: Organisations design systems that mirror their own communication structures.; Does our team structure match the boundaries we want in the system?
Inverse Conway Maneuver: Shape your teams to match the architecture you want, and the system will follow.; What team structure would naturally produce our target architecture?
Cognitive Load: A team can only hold so much in its head; architecture should fit within that limit.; How much does this team need to understand to make a safe change on its own?
Incentives: Show me the incentive and I will show you the outcome.; What are these teams actually rewarded and measured for?
Goodhart's Law: When a measure becomes a target, it ceases to be a good measure.; What behaviour will this target encourage, including behaviour we don't want?
Brooks's Law: Adding people to a late software project makes it later.; Can this remaining work really be split, or does it depend on a few people and a shared design?
Bikeshedding (Law of Triviality): Groups spend disproportionate time on trivial issues because everyone feels qualified to discuss them.; Is the time we are spending on this proportionate to its impact?
Hanlon's Razor: Never attribute to malice what can be explained by missing information, constraints, or honest mistakes.; What did they know, or not know, when they made this decision?
Relativity (Stakeholder Frames): Every observer sees the system from their own frame; none of them sees the whole truth.; What does this stakeholder care about most, in their own words?
Ubiquitous Language: Use one vocabulary, shared by domain experts and developers, in conversation, documents and code alike.; Would a domain expert recognise the names in this design and code?
The Pyramid Principle: Start with the answer, then give the few reasons that support it, then the evidence for each.; Can I state my recommendation in one sentence?
Ladder of Inference: We climb from a few selected facts to firm beliefs in seconds; walk back down the ladder together to resolve disagreement.; What data am I actually looking at, and what did I leave out?
Disagree and Commit: Argue openly until the decision is made, then everyone backs it fully — including those who argued against it.; Has everyone had a real chance to argue their position?
Influence Without Authority: When you can't tell people what to do, trade: offer what they value in return for what you need.; What does this person need to succeed in their own role?
Power–Interest Grid: Map stakeholders by how much power they have over the outcome and how much they care, and engage each group differently.; Who could stop this, and do they know about it yet?
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.; Who is this diagram for, and which zoom level do they need?
Curse of Knowledge: Once you know something, it is hard to imagine not knowing it, so experts explain too little, too abstractly.; What would this mean to someone who wasn't in the design sessions?
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.; Who, by name, makes the final call on this decision?

Strategy & Enterprise

Wardley Mapping: Map components by the value they provide and how evolved they are, from genesis to commodity.; Where does each component sit on the evolution axis, and do we agree?
Core vs Context: Invest in what differentiates you; standardise or outsource everything else.; Does this capability differentiate us in customers' eyes?
Capability Mapping: Describe what the business does, independent of how, by whom, or with which system.; Which business capability does this system, project or vendor support?
Platforms and Network Effects: A platform's value grows with each participant — design for adoption, not just function.; Why would a team choose this platform if it were not mandated?
Build, Buy, or Partner: Choose the sourcing model by differentiation, market maturity, and your ability to operate it.; Does this capability differentiate us in our customers' eyes, or is it a utility?
Ecosystems: Your architecture lives in a wider habitat of partners, vendors, regulators, and standards — design for the whole of it.; Who outside our walls depends on, or contributes to, this system?
Optionality: Prefer positions that give you the right, but not the obligation, to act in the future.; Which future options are worth paying to keep open?
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.; Which processes must run the same way in every unit, and which may differ?
TIME Portfolio Triage: Sort each application by business value and technical quality into Tolerate, Invest, Migrate or Eliminate, and fund it accordingly.; Who scored business value, and who scored technical quality, and did they score independently?
Three Horizons: Manage the core, the emerging and the future at the same time, with different goals, measures and funding for each.; What share of this year's technology spend goes to each horizon, and is that a choice or an accident?
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.; Which of the decisions this board reviews could a written, testable rule settle instead?
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.; Who owns this dataset, and would they notice if it broke tomorrow?
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.; If we had to leave this provider in a year, what would we move, where to, and how long would it take?
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.; For this activity, what does it cost us to coordinate it inside compared with finding, contracting and monitoring a supplier?

Product 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.; What progress is the user trying to make, and in what circumstance, when they reach for this system?
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.; Which of these qualities would users only notice if they were missing?
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.; What is the riskiest assumption here, and what is the smallest thing we could build to test it?
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.; Which outcome is this solution meant to move, and through which customer opportunity?
Outcomes Over Output: Judge and steer work by the change in human behaviour it creates, not by the features, projects or code it produces.; Who will do what differently, and by how much, if this succeeds?
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).; Which of the four risks is highest for this idea, and what have we done to reduce it before building?

AI Systems

The Bitter Lesson: General methods that scale with computation beat clever, hand-built knowledge — eventually, and by a large margin.; Which parts of our design encode knowledge that a better model will soon learn on its own?
Software 2.0: Some software is no longer written as code but learned from data; the dataset and the objective become the program.; Which part of this system is behaviour we write, and which is behaviour we train or prompt?
Scaling Laws: Model capability improves predictably as compute, data and model size grow, so plan for the models of next year, not today.; Which of our design decisions assume today's model quality, cost or speed?
Workflows Before Agents: Use the simplest LLM design that works; add agent autonomy only when a problem truly needs it.; Could a single, well-crafted model call solve this before we build anything bigger?
Context Engineering: A model's context window is a limited budget; curate the smallest set of high-signal tokens it needs for the task.; What does the model actually need to see for this step, and what is noise?
Context vs Behaviour: Diagnose an LLM failure first: missing knowledge needs better context; wrong behaviour needs better prompting or tuning.; Is the model wrong because it lacks information, or because it behaves inconsistently?
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.; Which of our tasks have we actually tested inside the frontier, and which are we assuming?
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.; Does this agent read private data, see untrusted content, and have a way to communicate out — all at once?
The Autonomy Slider: Give AI as much autonomy as you can verify quickly — and let people move the slider up as trust grows.; How fast can a person check what the AI did at each level of autonomy?
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.; Are we replacing the steam engine with one big motor, adding AI to the old structure, or redesigning the work around it?
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.; What set of real cases tells us this AI feature is good enough, and who wrote down what good means?
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.; Which of our core capabilities can only be reached by a person clicking through a screen?
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.; Have we tested this task on real cases, or are we guessing that it is easy or hard for AI because it is easy or hard for us?

From the Masters

The Architect Elevator: Ride between the penthouse and the engine room: connect business strategy with technical reality.; When did I last spend real time in the engine room, with code, pipelines or incidents?
Architects See More Dimensions: Many either-or conflicts dissolve once you add a dimension the debaters are not seeing.; What dimension are both sides of this argument leaving out?
Starbucks Does Not Use Two-Phase Commit: Real businesses scale through asynchronous, compensating processes, not distributed transactions.; How does the business handle this failure in the real world today?
Economies of Speed: Digital organisations win by how quickly they can learn and change, not by how big they are.; In this area, are we optimising for scale or for speed, and did we choose that on purpose?
Architecture Is About the Important Stuff: Architecture is the set of decisions that are hard to change, whatever those turn out to be.; What in this system will be hardest to change in two years' time?
Monolith First: Start with a well-structured monolith; split into services only once the boundaries and the need are proven.; Do we understand the domain boundaries well enough yet to fix them behind a network?
Microservice Premium: Microservices carry a fixed overhead that only pays off above a certain level of complexity.; Is this system genuinely too complex to manage as a well-modularised monolith?
Sacrificial Architecture: Design knowing you may throw the system away, and treat that as a sign of success.; How long do we honestly expect this system to live, and have we written that down?
Design Stamina Hypothesis: Good internal design slows you briefly; past the payoff line it is what keeps you fast.; Will this system still be changing after the next few weeks?
Technical Debt Quadrant: Classify debt as deliberate or inadvertent, and prudent or reckless; each needs a different response.; Did we take this debt on knowingly, or did we only discover it later?
Anti-Corruption Layer: Protect your domain model by translating at the boundary with systems whose models you don't control.; Whose model are we adopting if we integrate with this system directly?
Architecture Decision Records: Capture the why behind significant decisions in short, immutable records future teams can read.; Will someone joining in two years understand why we did this from what we write today?
Circuit Breaker: Stop calling a failing dependency for a while, so its failure doesn't become yours.; What happens to callers when this dependency hangs rather than fails?
Why Is More Important Than How: The second law of software architecture: a design only makes sense once you know why it was chosen.; Why was this chosen, and is that reason still true?
Conceptual Integrity: A system should reflect one coherent set of design ideas, even at the cost of some features.; Could a new engineer predict how an unfamiliar part of this system works from the parts they know?
Everything Fails, All the Time: At scale, failure is the normal state. Design for it rather than hoping to prevent it.; What happens to users when, not if, this dependency fails?
Make the Change Easy, Then Make the Easy Change: When a change is hard, first reshape the system so the change becomes easy.; What change to the structure would make this feature easy to add?
Information Hiding: Decompose systems around the decisions most likely to change, and hide each behind an interface.; Which decisions in this design are most likely to change in the next year?