Terminology

2185 terms, tools, patterns and metrics an architect is expected to use precisely. Each one gets a short explanation of what it is, and — where it matters — what it is commonly confused with. Search filters as you type; the column headers sort.

All areas2185 Architecture Fundamentals77 Distributed Systems107 Data Architecture110 Cloud Architecture89 Networking88 API & Integration Architecture82 Reliability & Resilience75 Observability70 Performance & Capacity Engineering72 Security Architecture81 Cost Architecture & FinOps66 Business Architecture67 Architecture Communication67 Enterprise Architecture66 Legacy Modernization66 AI-Era Architecture69 Software Architecture & Engineering71 Architecture Patterns71 Architecture Decision-Making63 The Architect's Meta-Skills61 Delivery & Release Engineering66 Platform Engineering & Developer Experience70 Testing & Quality Architecture66 Data Platform Architecture64 Streaming & Real-Time Data69 Data Governance & Semantics69 Frontend & Experience Architecture66 Edge, Mobile & IoT68 Regulatory & Data Protection Architecture65 Assurance, Audit & Model Risk64

Kind Any concept785 practice729 pattern362 metric125 case-study77 tool62 protocol45

56 terms shown.

Term	Kind	Topic	What it is
Abstraction Level Discipline	practice	C4 Model	Keeping each diagram to a single level of zoom, and providing separate diagrams for each level rather than one diagram attempting all of them.
Architecture Decision Log ADR Log, Decision Register	practice	Architecture Communication	The ordered, immutable collection of a system's decision records, read as a history rather than as a specification.
Architecture Review Practice	practice	Architecture Reviews	Running a design review that improves the design rather than performing gatekeeping, through timing, framing and the questions asked.
Arrow Semantics Edge Semantics, Line Notation Discipline	practice	Architecture Diagrams	The rule that every line on an architecture diagram declares what it is - call or data, synchronous or asynchronous, and what happens when it fails - because each meaning implies a different failure mode.
Attack-Path Framing Path-Based Finding, Attack-Path Finding Format	practice	Communicating Threat Models	Writing each security finding as a reachable path from entry point to impact with the one change that removes it and the cost of that change, replacing severity scores that can be argued with instead of acted on.
Bottom Line Up Front	practice	Written Communication	Placing the conclusion and the requested action in the first lines, on the assumption that most readers will not reach the end.
C4 Model	practice	Architecture Communication	A set of four nested diagram levels — context, container, component, code — that keeps each diagram at one consistent level of abstraction.
C4 Model in Practice	practice	C4 Model	Four nested levels of diagram — context, container, component, code — whose value is controlling altitude rather than the notation itself.
Communicating a Threat Model	practice	Communicating Threat Models	Producing a threat model that engineers act on — structured by data flow, prioritised by risk, and expressed as work rather than as a report.
Communicating with Engineers	practice	Presenting to Engineers	Earning technical credibility and giving guidance that engineers act on — which depends more on how the reasoning is shared than on whether it is correct.
Context Diagrams	practice	Context Diagrams	The system, its users and everything it talks to — the cheapest, most durable and most under-used architecture artefact.
Data Flow Diagrams	practice	Data-Flow Diagrams	Where data goes, who holds it and which boundaries it crosses — the artefact that answers privacy, residency and threat-modelling questions.
Data-Flow Diagram DFD	practice	Architecture Communication	A diagram of how data moves between processes, stores and external entities, with trust boundaries drawn on it.
Decision Narrative	practice	Writing Decision Records	Writing a decision record so that the reasoning survives the author, focusing on the forces and the rejected options rather than the conclusion.
Decision Restatement Implementer Read-Back, Assent by Restatement	practice	Presenting to Engineers	Requiring the people who will implement a decision to write back what they will build and why, so that agreement is demonstrated by the receiver rather than inferred from an approval click.
Decision-Forcing Proposal	practice	Technical Proposals	A written proposal structured so that deferring is visibly a choice with a cost, rather than a free default.
Deployment Diagrams	practice	Deployment Diagrams	Where software actually runs — regions, zones, clusters, networks — and therefore what fails together.
Diagram Notation Consistency	practice	Architecture Diagrams	Using shapes, colours, line styles and arrow directions to mean the same thing across every diagram, and stating what they mean on the diagram itself.
Diagram Provenance Diagram Dating, Generated-From Line	practice	Data-Flow Diagrams	A line on every diagram stating what it was generated from, when, and when it will next be refreshed, so readers can weigh its accuracy instead of assuming it.
Diagrams as Code Architecture as Code, Textual Diagram Model	practice	Architecture Diagrams	Keeping architecture pictures as text in the same repository as the code they describe, so a structural change and its diagram are reviewed in one pull request instead of drifting apart.
Disagree and Commit Principled Dissent, Recorded Objection, Commit With Trigger	practice	Handling Disagreement	Recording a dissent with its reasoning and a monitorable revisit trigger, then executing the chosen approach wholeheartedly - which preserves both the organisation's ability to move and the record needed to learn.
Diátaxis Framework Diátaxis, Four-Mode Documentation	practice	Documentation Practice	A placement rule for technical documentation that separates four reader needs - tutorial, how-to, reference and explanation - so one page serves one need instead of mixing all four and serving none.
Documentation Practice	practice	Documentation Practice	Writing what will be read, keeping it true, and deliberately not writing the rest.
Executive Communication	practice	Presenting to Executives	Presenting technical matters to an audience that owns outcomes and money, in a form that supports a decision within their attention span.
Executive Summary Discipline	practice	Presenting to Executives	Leading with the recommendation and its business consequence, compressed to what an executive audience can act on in a few minutes.
Explaining Trade-offs	practice	Explaining Trade-offs	Presenting a choice so that the audience can exercise the judgement that is genuinely theirs, in the terms they actually think in.
Facilitation	practice	Facilitation	Running a discussion so that a group reaches a decision — a distinct skill from having the best answer.
Facilitation Neutrality	practice	Facilitation	Separating the role of running a discussion from the role of advocating within it, because one person cannot do both credibly.
Failure Domain Annotation Shared-Fate Labelling	practice	Deployment Diagrams	Writing on a deployment diagram what each group of nodes shares - image, configuration source, pipeline, control plane - so the diagram answers what fails together rather than only where things run.
Handling Architectural Disagreement	practice	Handling Disagreement	Resolving a technical dispute in a way that produces a decision people will actually implement, rather than a winner.
Interaction Modelling	practice	Sequence Diagrams	Showing the ordered exchange of messages between participants over time, to reason about protocols, failure points and latency.
Interest-Based Negotiation Principled Negotiation, Positions vs Interests	practice	Negotiation	Negotiating against what each party actually needs rather than what they have asked for, which opens options that the stated positions foreclose.
Narrative Arc	practice	Presentation Skills	Structuring a technical presentation as a problem, tension and resolution rather than as an ordered dump of findings.
Negotiation	practice	Negotiation	Reaching decisions with people whose objectives differ — by working from interests rather than positions, and by making trades explicit.
Options-With-Consequences Never Present a Binary, Costed Alternatives	practice	Explaining Trade-offs	Presenting a technical constraint as a set of costed options rather than as an objection, so the decision moves to the person accountable for the consequence with the information they need.
Outbound Dependency Census Egress-Derived Dependency Inventory, External Dependency Reconciliation	practice	Context Diagrams	Deriving the list of systems a product depends on from four independent machine-readable registers instead of from memory, then deciding which of them belong on a diagram and which belong in a register.
Pre-Read Alignment Blocker Pre-Socialisation, Objection Absorption	practice	Facilitation	Speaking to the two or three people whose objection would block a decision before circulating the proposal, so the session confirms a decision rather than discovering a conflict.
Presentation Skills	practice	Presentation Skills	Presenting architecture so a specific audience can make a decision — which requires knowing which decision and adapting everything to it.
Presenting to Engineers	practice	Architecture Communication	Presenting a design at the level of mechanism, including the alternatives rejected and the parts you are still unsure about.
Presenting to Executives	practice	Architecture Communication	Leading with the decision and the business consequence, at a level of abstraction where technology names do not appear.
Public Incident Narrative Public Postmortem	practice	Written Communication	An externally published account of an outage that transfers the diagnostic search rather than a conclusion - the timeline that was read, the hypotheses that were wrong and the practice gap that allowed it.
Rejected-Option Record ADR Alternatives Section, Why Not X	practice	Writing Decision Records	The part of a decision record that captures what was considered and dismissed and on what grounds - the only content that code, diagrams and current-state documentation cannot carry.
Review Readiness Criteria	practice	Architecture Reviews	A stated bar a design must meet before review, so the session is spent on judgement rather than on discovering that the work is not ready.
Revisit Condition Decision Expiry, Reconsider Trigger	practice	Writing Decision Records	The stated, checkable circumstance under which an architectural decision should be reconsidered - the field that turns a historical record into a live decision.
Sequence Diagram	practice	Architecture Communication	A diagram showing the ordered exchange of messages between participants over time, used to make an interaction's control flow and failure points explicit.
Sequence Diagrams	practice	Sequence Diagrams	Showing the order of interactions over time — the only common diagram that makes latency, ordering and failure behaviour visible.
Stop Authority Halt Right, Andon Authority	practice	Handling Disagreement	A named role's pre-agreed right to halt a running system alone, without consensus on the cause, so that a loss accumulating per minute is stopped before it is understood.
Technical Depth Calibration	practice	Presenting to Engineers	Matching the level of detail and the mode of engagement to an engineering audience, which needs reasoning and the opportunity to disagree.
Technical Proposal Design Doc, RFC	practice	Architecture Communication	A written argument for a course of action, circulated for review before the work starts, structured so that disagreement surfaces early and cheaply.
Technical Proposal Structure	practice	Technical Proposals	An arrangement for a written design proposal that lets reviewers engage with the decision rather than reconstructing the problem.
Trade-off Framing	practice	Explaining Trade-offs	Presenting a decision as a choice between named costs rather than as a search for a best option, so the audience can exercise the judgement that is properly theirs.
Trust Boundary Diagram	practice	Communicating Threat Models	A diagram marking where data crosses between zones of differing trust, which is the structure a threat model is built on and the form security findings are best communicated in.
Update Cadence Commitment Next-Update Promise, Incident Comms Rhythm	practice	Presenting to Executives	Promising when the next update will arrive rather than when the problem will be fixed, so the one commitment made during an incident is one the team can actually keep.
Writing Decision Records ADR	practice	Writing Decision Records	Recording a decision so the next person understands why — including the options rejected and the conditions that would reverse it.
Written Communication	practice	Written Communication	Writing that reaches more people than any meeting, survives longer, and forces the thinking that verbal explanation lets you skip.
Written Design Document RFC, Design Doc	practice	Technical Proposals	A prose document proposing an approach, circulated for comment before implementation, which forces the clarity that diagrams and conversation allow you to avoid.