PECB CMSA cheat sheet

Architecture = the set of structures (components, their properties, and relationships) needed to reason about the system; it omits details irrelevant to those concerns.

Quality attributes are non-functional, measurable scenarios: stimulus → source → artifact → environment → response → response measure (the six-part scenario template).

Modifiability tactics split into reducing coupling (encapsulation, use an intermediary, restrict dependencies) and increasing cohesion (split modules, abstract common services).

Availability tactics: fault detection (ping/echo, heartbeat, exception detection), recovery (redundancy, rollback, checkpoint), prevention (removal from service, transactions).

Performance tactics: control resource demand (manage sampling rate, prioritize) and manage resources (concurrency, caching, load balancing).

Architecture vs. design: architecture concerns structures and decisions that are costly to change; design fills in local, cheaper-to-reverse detail.

Separation of concerns and information hiding (Parnas) aim to isolate likely change; abstraction raises the level at which change is expressed.

Conway's Law: system structure mirrors the communication structure of the organization that builds it; inverse Conway maneuvers restructure teams to steer architecture.

Views are chosen per stakeholder concern; a view is a representation of one or more structures, and a viewtype groups views by style (module, component-and-connector, allocation).

Layered style restricts allowed dependencies between layers; strict layering forbids skipping layers, relaxed layering permits it.

Pipe-and-filter: filters transform incrementally, connectors are stateless pipes; suited to stream processing, weak for interactive user dialogs.

Client-server vs. broker vs. publish-subscribe: broker adds indirection for location transparency; pub-sub decouples producers from consumers in time and identity.

Service-Oriented / microservices: services own their data, communicate over network contracts; tradeoffs are independent deployability vs. distributed-system complexity.

UML structural diagrams: class, component, deployment, package; behavioral: sequence, activity, state machine, use case.

ATAM-style utility tree: root is 'Utility', second level is a quality attribute, third level is a refined scenario, leaves carry (importance, difficulty) ratings.

Model-Driven Architecture separates platform-independent model (PIM), platform-specific model (PSM), and platform model via transformations.

Views and Beyond documentation set: a view template (primary presentation, element catalog, context diagram, variability guide, rationale) plus a documentation roadmap and a 'how the documentation is organized' guide.

Every stakeholder concern should map to at least one documented view; a view with no stakeholder concern behind it is documentation bloat.

Architecture decision records (ADRs) capture context, decision, status, and consequences; they record why, which code and diagrams cannot.

The '7±2' rule of thumb: keep a diagram's element count small enough to be comprehended; split large diagrams rather than shrinking fonts.

Architecture Haiku: a lightweight documentation form using a short poem-like summary plus small sketches to convey the essence quickly.

Documentation must state the architectural drivers (key requirements, constraints, quality attribute scenarios) before presenting structures.

Rationale documentation answers: what options were considered, what was chosen, and what tradeoffs were accepted.

Documentation is a communication artifact: tailor notation and detail per audience (management, developers, operators, security reviewers).

Architecture conformance checking compares as-designed structure to as-implemented structure; tools extract dependencies from code and diff them against the intended model.

Fitness functions are automated, objective checks that keep architecture characteristics intact (e.g., dependency rules, layering tests, performance thresholds).

Governance mechanisms: architecture review board, design authority, gate reviews at milestones, exception/waiver process with expiry.

Technical debt is tracked as a backlog with interest: principal (rework cost) and interest (ongoing drag) drive prioritization.

Architecture runway: the amount of architecture built ahead of feature demand that the team can still absorb without rework.

Reference architectures and patterns act as governance by constraint: deviations require documented justification.

Continuous architecture treats decisions as revisable; governance should specify decision rights and escalation, not freeze design.

Traceability links requirements → architecture decisions → components → tests, enabling impact analysis when a driver changes.

ATAM phases: presentation (1), evaluation (2: utility tree, then scenario-based analysis), reporting (3); output is risks, non-risks, sensitivity points, tradeoff points.

Sensitivity point = a decision significantly affecting one quality attribute; tradeoff point = a sensitivity point affecting two or more attributes in opposing directions.

Risk = an architectural decision that may lead to undesirable consequences; non-risk = a good decision worth documenting and preserving.

Other evaluation methods: SAAM (scenario-based, earliest), CBAM (cost-benefit, adds economics), ARID (active design review for partial designs), Lightweight ATAM.

Scenario categories: use-case, growth, and exploratory scenarios; exploratory scenarios probe likely future change and are the hardest to satisfy.

Architecture erosion vs. drift: erosion is gradual structural decay; drift is a divergence from the intended architecture without decay of quality.

Maintenance types: corrective, adaptive, perfective, preventive; architecture-level maintenance focuses on structural refactoring and dependency repair.

Refactoring preserves observable behavior while improving structure; architecture smells include cyclic dependencies, god components, and unstable interfaces.