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

67 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.
Abuse Case Misuse Case	concept	Communicating Threat Models	A use case written from the attacker's side - a hostile actor plus the interaction that achieves their goal - which engineers can refute or fix, unlike a likelihood-impact score which they can only dispute.
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 Lineage View	concept	Data-Flow Diagrams	A view showing how data moves and is transformed through a system, independent of the components that do the moving.
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.
Deployment Topology View	concept	Deployment Diagrams	A diagram showing where software actually runs — regions, zones, networks and hosts — which is where availability and cost properties become visible.
Diagram Altitude	concept	Architecture Diagrams	The level of abstraction a diagram commits to, and the rule that mixing levels in one picture makes it useless to every audience.
Diagram Maintenance Economics Which Diagrams to Keep, Stale Diagram Cost	concept	C4 Model	The rule that a diagram earns its maintenance cost only when it explains something hard to derive from source - which is why structure diagrams below the container level should be generated or absent.
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 Decay	concept	Documentation Practice	The tendency of written documentation to become inaccurate faster than it is updated, making stale documentation actively more harmful than none.
Documentation Practice	practice	Documentation Practice	Writing what will be read, keeping it true, and deliberately not writing the rest.
Evidence Transferability Context Matching, Scale Applicability, Case Study Fit	concept	Explaining Trade-offs	The degree to which a finding from another organisation's system applies to yours, determined by similarity of workload shape, scale and constraints - and the discipline of extracting the question rather than …
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.
Intermediate-State Diagram Transition-State View, Migration Step View	pattern	Architecture Diagrams	A short series of diagrams showing the system at each step between today and the target, each marking which store is authoritative and where rollback stops being possible.
Last Safe Start Date Programme Latest Start, Deadline Backstop Date	metric	Negotiation	The externally imposed deadline minus the programme's duration and contingency - the date an architect computes and owns, which competes for funding in a way the distant vendor deadline does not.
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.
SLA Measurement Point Measurement Boundary, Observation Point	concept	Negotiation	The place in the request path where an availability or latency commitment is observed, which decides what the number means and is where nearly every SLA dispute actually originates.
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.
System Context Boundary	concept	Context Diagrams	The line separating what a project owns and can change from what it must integrate with and accept as given.
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.