PECB CMSA key terms

A short document capturing one significant architectural choice, the context that forced it, the options considered, and the consequences accepted. ADRs are dated, immutable once accepted, and superseded rather than edited.

A requirement that measurably shapes structure, such as a hard latency bound, a regulatory constraint, or a mandated integration. Requirements that can be met by local coding choices are not architecturally significant.

A six-part testable statement of a quality requirement: source, stimulus, artifact, environment, response, and response measure. It converts vague goals like 'must be fast' into a verifiable acceptance target.

Design decisions that directly influence achievement of a quality attribute, such as introducing a cache for performance or a heartbeat for availability. Tactics are finer grained than patterns and are combined to build them.

A reusable, named solution shape for a recurring structural problem, such as layered, pipe-and-filter, or event-driven. A pattern constrains component types and allowed interactions, and each choice trades one quality against another.

A template architecture for a domain or product family, with standard elements, responsibilities, and permitted variations. Teams tailor it rather than start blank, gaining consistency and faster onboarding at the cost of some design freedom.

A conventions-and-notation package that says how to build one kind of view, such as a deployment viewpoint or a concurrency viewpoint. Viewpoints are reusable across projects; a view is the actual artifact produced by applying one.

A representation of a system addressing a specific set of stakeholder concerns, omitting what is irrelevant to them. A complete architecture description normally contains several views whose contents are checked for consistency with each other.

The organized collection of views, models, decisions, and rationale that records the architecture. It is a work product, distinct from the architecture itself, which is the set of fundamental concepts and properties of the system.

A person or group with an interest in the system and legitimate concerns about it, such as operators, auditors, developers, or acquirers. Each concern should map to at least one view in the description.

An interest in the system that matters to one or more stakeholders, such as security, cost of change, or time to market. Architecture work is organized around satisfying and balancing documented concerns.

A situation where improving one quality attribute degrades another, for example adding redundancy for availability raises cost and operational complexity. Trade-offs should be recorded with their rationale, not left implicit in code.

The principle of dividing a system so that each part addresses a distinct, minimally overlapping set of responsibilities. It reduces coupling between unrelated changes and makes each part easier to reason about and test.

The degree to which two modules depend on each other, through shared data, call sequences, or knowledge of internals. Loose coupling lets a change in one module stay local, while tight coupling spreads the impact of change.

How strongly the responsibilities inside a single module belong together. High cohesion means the module has one clear purpose; low cohesion means unrelated functions are bundled, making the module hard to name and reuse.

Structuring a system as discrete units with well-defined interfaces that can be developed, replaced, and tested somewhat independently. It is achieved by managing coupling and cohesion, not merely by creating folders or packages.

Designing modules so each conceals a design decision likely to change, such as a data format or algorithm, behind a stable interface. Callers then depend on the contract rather than on volatile internals.

Bundling data with the operations that legitimately act on it and restricting direct outside access. It protects invariants and lets the internal representation change without breaking callers.

The declared contract through which one element uses another: operations, inputs, outputs, and quality expectations such as timing or error behavior. Well-specified interfaces allow independent evolution of provider and consumer.

A replaceable unit of software with defined provided and required interfaces, treated as a black box in architecture views. Components are the computational elements whose assembly the architecture describes.

An architectural element that mediates interaction between components, such as a remote procedure call, message queue, or shared repository. Connector choice drives latency, coupling, and failure behavior as much as component choice does.

A structure in which each layer provides services to the layer above and uses only the layer below. It supports portability and separation but can add pass-through overhead and tempt developers to bypass layers.

An approach where capabilities are exposed as interoperable, loosely coupled services with explicit contracts, discoverable and composable across systems. Governance of contracts and versions is central to keeping services reusable.

An architectural style decomposing a system into small, independently deployable services, each owning its data and aligned to a business capability. It buys independent scaling and release cadence at the price of distributed-system complexity.

An explicit boundary inside which one domain model and its vocabulary apply consistently. Different contexts may use the same word with different meanings, and translation between them is made explicit rather than assumed.

An approach that centers design on the business domain, using models built with domain experts and separating subdomains by bounded contexts. Strategic DDD shapes service boundaries; tactical DDD supplies entities, value objects, and aggregates.

A simplified, purposeful representation of a system or part of it, built to answer a specific question. Every model omits detail deliberately, so its validity depends on whether the omissions matter for its intended use.

A standardized general-purpose modeling language offering diagram types such as component, class, sequence, and deployment. It defines notation, not method; the architect must still choose which diagrams answer which stakeholder question.

A structured review of an architecture against its quality requirements and risks, done early enough to act on findings. Methods differ in rigor and cost, from lightweight scenario workshops to formal multi-day assessments.

Architecture Tradeoff Analysis Method: a scenario-driven group evaluation that surfaces risks, sensitivity points, and trade-off points by walking stakeholders through quality attribute scenarios against the architecture. It assesses consequences of decisions, not conformance to a checklist.

A design decision to which one quality attribute responds strongly, such as thread pool size affecting throughput. Identifying it tells reviewers where a small change produces a large effect and therefore where to focus testing.

The accumulated cost of expedient design choices that will require later rework, such as skipped abstraction or deferred upgrades. Like financial debt, it charges interest in slower change until deliberately repaid or refinanced.

Improving internal structure without changing observable behavior, performed in small verified steps supported by tests. Architectural refactoring changes element boundaries or interfaces and is far costlier than local code refactoring.

Checking that implemented code and infrastructure match the defined architecture, for example by static dependency analysis or fitness functions. Deviations are either corrected or accepted by updating the architecture description.

The set of decision rights, policies, and review practices that keep architecture consistent with strategy across teams. Effective governance enables teams with guardrails and standards rather than approving every design in advance.

A cross-organizational body that owns architecture standards, resolves escalated conflicts, and reviews exceptions. It works best when it sets principles and thresholds while delegating routine decisions to delivery teams.

A statement of a preferred way of doing architecture that guides decisions without prescribing a specific design, for example 'buy before build'. Principles must be few, justified, and visibly applied in real decisions.

An automated check that objectively tests whether a system exhibits a desired architectural property, such as a dependency rule or a response-time budget. It turns governance from periodic review into continuous feedback in the pipeline.

The mapping of software elements onto execution environments such as hosts, containers, and networks, plus the process of releasing them. Deployment views expose latency, redundancy, and single points of failure hidden in logical views.