Engineer Architecture cheat sheet

Architecture = the set of structures (components, their relationships, and governing principles) needed to reason about the system; it is the design decisions that are hard to reverse, not the whole design.

Separation of concerns: each module owns one reason to change; measure with coupling (afferent Ca / efferent Ce) and instability I = Ce / (Ca + Ce), where I=0 is maximally stable.

Cohesion types ranked high-to-low: functional > sequential > communicational > procedural > temporal > logical > coincidental; prefer functional cohesion.

Dependency inversion: high-level policy depends on abstractions, not details; both depend on interfaces owned by the policy layer (ports and adapters / hexagonal).

Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, Dependency Inversion (SOLID) are design-level heuristics; they do not by themselves satisfy quality attributes.

Layered, pipes-and-filters, broker/event-driven, blackboard, microkernel, and service-oriented are architectural styles; each style trades modifiability, performance, and deployability differently.

Architectural tactics map to quality attributes: heartbeat and redundancy to availability, introduce concurrency and reduce indirection to performance, encapsulate and restrict dependencies to modifiability.

Conway's Law: system structure mirrors communication structure of the organization; inverse Conway maneuver deliberately shapes teams to obtain the target architecture.

Technical debt is a deliberate or inadvertent trade-off; track principal (cost to fix) and interest (recurring cost of not fixing) separately in the backlog.

Requirement types: functional (behavior), non-functional/quality attribute (with stimulus-response measure), constraint (fixed decision, e.g. mandated protocol), and business rule.

A quality-attribute scenario has six parts: source, stimulus, artifact, environment, response, and response measure; a requirement without a measure is not testable.

Stakeholder analysis: build a power/interest grid; classify each stakeholder as key player, keep satisfied, keep informed, or monitor; capture concerns as quality attributes.

Requirement elicitation techniques: interviews, workshops, observation, prototyping, document analysis, and questionnaires; use them to surface tacit requirements.

Traceability matrix links stakeholder needs -> requirements -> architecture elements -> test cases; it supports impact analysis and change control.

Prioritize with MoSCoW (Must/Should/Could/Won't) or weighted scoring; requirements are negotiable in scope, not in definition of done.

Ambiguity detection: flag terms like 'fast', 'user-friendly', 'flexible' and rewrite as measurable, bounded statements with units and conditions.

Requirements baseline is frozen at a milestone; subsequent changes go through change control with impact analysis on architecture and schedule.

Use the INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable) to judge user-story quality.

UML views: structural (class, component, deployment, package) and behavioral (use case, activity, sequence, state machine); choose the view that answers the stakeholder's question.

SysML adds requirement, block, internal block, parametric, and allocation diagrams; allocation traces model elements to requirements and to implementation.

C4 model layers: Context -> Container -> Component -> Code; each layer is a zoom-in and should not mix abstraction levels.

ArchiMate layers: Business, Application, Technology; cross-layer relationships (serving, realization, access) express traceability.

A view is a representation of a viewpoint; viewpoints come from concerns of stakeholders (ISO/IEC 42010). Document the viewpoint, not just the diagram.

Component interface contract: provided interface (what it offers) and required interface (what it consumes); model both to detect missing dependencies.

Sequence diagrams show message order and lifelines; state machines show event-driven lifecycle; use both when behavior and state interact.

Model consistency checks: every requirement has at least one realizing element; every interface has at least one provider and one consumer.

Deployment diagram maps software artifacts to nodes (physical/virtual) and communication paths, exposing runtime and network constraints.

Quality attributes are non-functional but measurable; each must have a scenario with response measure (e.g., p95 latency < 200 ms at 1,000 requests/s).

Availability formula: A = MTBF / (MTBF + MTTR); 99.9% is ~8.77 hours downtime per year, 99.99% is ~52.6 minutes.

Performance tactics: resource pooling, concurrency, caching, load balancing, batching, and reducing indirection; measure with throughput and latency percentiles.

Security attributes: confidentiality, integrity, availability, authentication, authorization, non-repudiation, and auditability; model threats with STRIDE.

Modifiability tactics: encapsulate, increase cohesion, reduce coupling, defer binding, and use intermediary components.

Testability tactics: abstract interfaces, record/playback, sandboxing, and built-in self-test hooks; a system hard to test is hard to change.

Usability and accessibility: measure task completion time, error rate, and WCAG conformance; treat these as testable NFRs.

Scalability is a design property (scale up vs. scale out); elasticity is the ability to scale automatically with demand.

Trade-off analysis: quality attributes often conflict (security vs. usability, performance vs. modifiability); record the chosen trade-off and its rationale.

Integration styles: file transfer, shared database, remote procedure call, messaging (point-to-point and publish/subscribe), and API gateway.

Synchronous (REST, gRPC) couples availability; asynchronous messaging decouples but introduces eventual consistency and ordering concerns.

Interface contract: define schema, versioning policy, error model, idempotency, and timeouts; a contract is a promise, not a suggestion.

REST constraints: client-server, stateless, cacheable, uniform interface, layered system, optional code-on-demand; HTTP methods should be idempotent where defined.

gRPC uses HTTP/2 and Protocol Buffers; it is efficient and strongly typed but less browser-native than REST/JSON.

Message patterns: request-reply, publish-subscribe, competing consumers, dead-letter queue, and saga for distributed transactions.

Interoperability layers: syntactic (format/protocol), semantic (shared meaning), and organizational (process/policy); most failures are semantic.

API versioning strategies: URI versioning, header versioning, and media-type versioning; deprecation requires a documented sunset period.

Backward compatibility: additive changes are safe; removing or renaming fields breaks consumers and requires a new major version.

ATAM (Architecture Tradeoff Analysis Method) phases: present ATAM, present business drivers, present architecture, identify approaches, generate quality-attribute utility tree, analyze approaches, brainstorm scenarios, analyze, present results.

Utility tree: quality attribute -> refinement -> scenario -> (importance, difficulty of realization); prioritize to focus evaluation effort.

Sensitivity point: a decision that significantly affects one quality attribute; tradeoff point: a decision that affects two or more attributes in opposite directions.

Risk: a decision that may lead to undesirable consequences; non-risk: a good decision; risk themes aggregate risks for management.

Lightweight evaluation (e.g., scenario-based, checklist-based, or peer review) is appropriate when full ATAM is too costly; document scope and participants.

Cost-benefit: compare architecture options on lifecycle cost, risk, and quality-attribute impact; use decision records to capture rationale.

Fitness functions: automated tests that continuously verify architectural characteristics (dependency rules, performance budgets, security checks).

Evaluation outputs: prioritized scenarios, sensitivity/tradeoff points, risks, non-risks, and recommendations; feed them into the architecture backlog.

Architecture review should happen early and at each significant change; late review finds defects that are expensive to fix.

Architecture Decision Record (ADR): title, status, context, decision, consequences; immutable once accepted, superseded by a new ADR.

Governance mechanisms: architecture review board, design authority, standards catalog, exception process, and fitness functions in CI.

Documentation should be sufficient, not exhaustive; the arc42 template covers context, constraints, solution strategy, building blocks, runtime, deployment, and decisions.

ISO/IEC/IEEE 42010 defines architecture description: stakeholders, concerns, viewpoints, views, and correspondence rules.

Document the context (external systems and actors) before the internals; the context boundary defines what is in scope.

Standards and patterns should be referenced, not re-explained; link to the authoritative source and record local deviations.

Governance metrics: exception count, review cycle time, adherence rate to standards, and technical-debt trend.

Keep documentation close to code (docs-as-code, versioned in the repository) so it evolves with the system.

Every significant architecture decision should trace to a requirement or quality-attribute scenario that motivated it.

CI/CD pipeline stages: build, unit test, static analysis, package, deploy to staging, integration/e2e test, promote to production; fail fast on the earliest stage.

Blue-green deployment swaps traffic between two identical environments; canary releases route a small percentage of traffic and expand on success.

Infrastructure as Code (IaC) makes environments reproducible and auditable; drift detection compares actual state to declared state.

Observability pillars: logs, metrics, and traces; add health checks, alerting thresholds, and SLOs/SLIs.

SLO defines a target reliability; error budget = 1 - SLO; burn rate alerts trigger when the budget is consumed too fast.

Deployment vs. release: deployment puts code in production; release exposes it to users (feature flags decouple them).

Rollback strategy must be designed before deployment; database migrations need backward-compatible, expand-contract patterns.

Operational readiness: runbooks, on-call rotation, capacity plan, backup/restore test, and incident response procedure.

Post-incident review (blameless) captures timeline, root cause, and action items; track action items to closure.

Ethical duties: public safety and welfare first, competence limits, confidentiality, conflict-of-interest disclosure, and honest reporting of risk.

When asked to sign off on an architecture you believe unsafe, document the concern in writing and escalate; do not silently comply.

Communication: tailor the message to the audience (executive, engineering, operations); lead with the decision and its consequences.

Architecture presentations should state problem, options, trade-offs, recommendation, and risks; keep one slide per decision.

Negotiation: separate interests from positions; anchor on measurable quality attributes rather than opinions.

Mentoring and knowledge sharing are professional obligations; document decisions so the team can operate without you.

Legal/regulatory awareness: data protection (e.g., GDPR), licensing, accessibility, and sector regulation constrain architecture choices.

Intellectual property: respect licenses (permissive vs. copyleft) and record third-party component provenance (SBOM).

Continuing professional development: track standards evolution and validate assumptions with prototypes before committing.

Architecture = structures + relationships + principles; the decisions that are costly to reverse define the architecture.

Instability metric I = Ce / (Ca + Ce); stable packages should be abstract (Stable Abstractions Principle).

Cohesion ranking: functional > sequential > communicational > procedural > temporal > logical > coincidental.

Dependency inversion: policy depends on abstractions owned by the policy layer, details implement them.

Architectural styles (layered, event-driven, microkernel, pipes-and-filters) carry different quality-attribute trade-offs.

Tactics map to quality attributes: redundancy to availability, concurrency to performance, encapsulation to modifiability.

Conway's Law: organization structure shapes system structure; inverse Conway maneuver shapes teams to obtain target architecture.

Technical debt has principal (fix cost) and interest (recurring cost); track both separately.

Requirement types: functional, quality attribute (with measure), constraint (fixed decision), and business rule.

Quality-attribute scenario parts: source, stimulus, artifact, environment, response, response measure.

Power/interest grid classifies stakeholders as key player, keep satisfied, keep informed, or monitor.

Elicitation techniques: interviews, workshops, observation, prototyping, document analysis, questionnaires.

Traceability links needs -> requirements -> architecture -> tests and enables impact analysis.

MoSCoW prioritization: Must, Should, Could, Won't; scope is negotiable, definition of done is not.

Rewrite ambiguous terms ('fast', 'flexible') as measurable statements with units and conditions.

Requirements baseline is frozen at a milestone; changes go through change control with impact analysis.

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

SysML adds requirement, block, internal block, parametric diagrams, and allocation relationships.

C4 layers: Context -> Container -> Component -> Code; do not mix abstraction levels in one diagram.

ArchiMate layers: Business, Application, Technology; serving/realization/access relationships express traceability.

A view represents a viewpoint derived from stakeholder concerns (ISO/IEC 42010).

Component contract: provided interface (offered) and required interface (consumed); model both.

Consistency check: every requirement has a realizing element; every interface has provider and consumer.

Deployment diagram maps artifacts to nodes and communication paths, exposing runtime constraints.

Quality attributes are measurable; each needs a scenario with response measure (e.g., p95 < 200 ms at 1,000 rps).

Availability A = MTBF / (MTBF + MTTR); 99.9% is ~8.77 h/year downtime, 99.99% is ~52.6 min/year.

Performance tactics: pooling, concurrency, caching, load balancing, batching, reducing indirection.

Security attributes: confidentiality, integrity, availability, authentication, authorization, non-repudiation, auditability; STRIDE for threats.

Modifiability tactics: encapsulate, increase cohesion, reduce coupling, defer binding, add intermediaries.

Testability tactics: abstract interfaces, record/playback, sandboxing, built-in self-test hooks.

Scalability = design property (scale up/out); elasticity = automatic scaling with demand.

Trade-offs: security vs. usability, performance vs. modifiability; record chosen trade-off and rationale.

Integration styles: file transfer, shared database, RPC, messaging (point-to-point, publish/subscribe), API gateway.

Synchronous (REST, gRPC) couples availability; asynchronous messaging decouples but adds eventual consistency and ordering concerns.

Interface contract: schema, versioning policy, error model, idempotency, timeouts.

REST constraints: client-server, stateless, cacheable, uniform interface, layered system, optional code-on-demand.

gRPC uses HTTP/2 and Protocol Buffers; efficient and strongly typed, less browser-native than REST/JSON.

Message patterns: request-reply, pub-sub, competing consumers, dead-letter queue, saga for distributed transactions.

Interoperability layers: syntactic (format/protocol), semantic (shared meaning), organizational (process/policy); most failures are semantic.

API versioning: URI, header, or media-type versioning; deprecation requires a documented sunset period.

ATAM steps: present ATAM, business drivers, architecture, approaches, utility tree, analyze approaches, brainstorm scenarios, analyze, present results.

Utility tree: quality attribute -> refinement -> scenario -> (importance, difficulty); prioritize to focus effort.

Sensitivity point affects one quality attribute strongly; tradeoff point affects two or more in opposite directions.

Risk = decision with potentially undesirable consequences; non-risk = good decision; risk themes aggregate risks.

Lightweight evaluation (scenario-based, checklist, peer review) fits when full ATAM is too costly; document scope and participants.

Cost-benefit compares options on lifecycle cost, risk, and quality-attribute impact; record rationale in ADRs.

Fitness functions are automated tests verifying architectural characteristics (dependency rules, budgets, security).

Evaluation outputs: prioritized scenarios, sensitivity/tradeoff points, risks, non-risks, recommendations; feed the backlog.

ADR fields: title, status, context, decision, consequences; accepted ADRs are immutable and superseded, not edited.

Governance mechanisms: architecture review board, design authority, standards catalog, exception process, fitness functions in CI.

arc42 sections: context, constraints, solution strategy, building blocks, runtime, deployment, decisions, quality.

ISO/IEC/IEEE 42010 defines stakeholders, concerns, viewpoints, views, and correspondence rules.

Document the context (external systems and actors) before internals; the boundary defines scope.

Reference standards and patterns by link; record local deviations explicitly.

Governance metrics: exception count, review cycle time, standards adherence rate, technical-debt trend.

Docs-as-code: keep documentation versioned with the system so it evolves with it.

CI/CD stages: build, unit test, static analysis, package, deploy to staging, integration/e2e test, promote to production; fail fast early.

Blue-green swaps traffic between identical environments; canary routes a small percentage and expands on success.

IaC makes environments reproducible and auditable; drift detection compares actual to declared state.

Observability pillars: logs, metrics, traces; add health checks, alerting, SLOs/SLIs.

Error budget = 1 - SLO; burn-rate alerts fire when the budget is consumed too fast.

Deployment puts code in production; release exposes it to users; feature flags decouple the two.

Rollback must be designed before deployment; database changes use expand-contract for backward compatibility.

Operational readiness: runbooks, on-call rotation, capacity plan, backup/restore test, incident response procedure.

Ethical duties: public safety and welfare first, competence limits, confidentiality, conflict-of-interest disclosure, honest risk reporting.

If asked to sign off on unsafe architecture, document the concern in writing and escalate; do not silently comply.

Tailor communication to audience (executive, engineering, operations); lead with the decision and its consequences.

Architecture presentation structure: problem, options, trade-offs, recommendation, risks.

Negotiation: separate interests from positions; anchor on measurable quality attributes, not opinions.

Document decisions so the team can operate without you; mentoring and knowledge sharing are professional obligations.

Legal/regulatory awareness: data protection (e.g., GDPR), licensing, accessibility, sector regulation constrain choices.

Respect licenses (permissive vs. copyleft) and record third-party provenance in an SBOM.

Architecture is the set of structures and decisions that are hard to reverse; it excludes easily changed design detail.

Coupling metrics: afferent Ca (incoming), efferent Ce (outgoing); instability I = Ce/(Ca+Ce); I=0 is maximally stable.

Cohesion order: functional, sequential, communicational, procedural, temporal, logical, coincidental; prefer functional.

SOLID principles are design heuristics; they do not by themselves satisfy quality attributes.

Architectural styles: layered, pipes-and-filters, broker/event-driven, blackboard, microkernel, service-oriented.

Tactics: heartbeat/redundancy -> availability; concurrency/reduce indirection -> performance; encapsulate -> modifiability.

Conway's Law: system structure mirrors organizational communication; inverse Conway maneuver shapes teams to the target architecture.

Technical debt: track principal (cost to fix) and interest (recurring cost) separately in the backlog.

Requirement types: functional, quality attribute (with measure), constraint (fixed decision), business rule.

Quality-attribute scenario: source, stimulus, artifact, environment, response, response measure; no measure means not testable.

Stakeholder power/interest grid: key player, keep satisfied, keep informed, monitor; capture concerns as quality attributes.

Elicitation: interviews, workshops, observation, prototyping, document analysis, questionnaires surface tacit requirements.

Traceability matrix links needs -> requirements -> architecture -> tests; supports impact analysis and change control.

Prioritize with MoSCoW or weighted scoring; scope is negotiable, definition of done is not.

Flag ambiguous terms ('fast', 'user-friendly') and rewrite as measurable statements with units and conditions.

Requirements baseline frozen at a milestone; changes go through change control with architecture impact analysis.

INVEST criteria for user stories: Independent, Negotiable, Valuable, Estimable, Small, Testable.

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

SysML adds requirement, block, internal block, parametric diagrams and allocation relationships.

C4 layers: Context -> Container -> Component -> Code; each layer is a zoom-in; do not mix abstraction levels.

ArchiMate layers: Business, Application, Technology; serving, realization, access relationships express traceability.

A view represents a viewpoint derived from stakeholder concerns (ISO/IEC 42010).

Component contract: provided interface (offered) and required interface (consumed); model both to detect gaps.

Sequence diagrams show message order and lifelines; state machines show event-driven lifecycle; use both when behavior and state interact.

Consistency checks: every requirement has a realizing element; every interface has a provider and a consumer.

Deployment diagram maps artifacts to nodes (physical/virtual) and communication paths, exposing runtime and network constraints.

Quality attributes are non-functional but measurable; each needs a scenario with a response measure.

Availability A = MTBF/(MTBF+MTTR); 99.9% is ~8.77 hours/year downtime, 99.99% is ~52.6 minutes/year.

Performance tactics: resource pooling, concurrency, caching, load balancing, batching, reducing indirection; measure throughput and latency percentiles.

Security attributes: confidentiality, integrity, availability, authentication, authorization, non-repudiation, auditability; STRIDE for threat modeling.

Modifiability tactics: encapsulate, increase cohesion, reduce coupling, defer binding, use intermediary components.

Testability tactics: abstract interfaces, record/playback, sandboxing, built-in self-test hooks.

Usability/accessibility: measure task completion time, error rate, WCAG conformance; treat as testable NFRs.

Scalability is a design property (scale up vs. scale out); elasticity is automatic scaling with demand.

Conflicting attributes (security vs. usability, performance vs. modifiability) require a recorded trade-off and rationale.

Integration styles: file transfer, shared database, remote procedure call, messaging (point-to-point, publish/subscribe), API gateway.

Synchronous (REST, gRPC) couples availability; asynchronous messaging decouples but introduces eventual consistency and ordering concerns.

Interface contract: schema, versioning policy, error model, idempotency, timeouts; a contract is a promise.

REST constraints: client-server, stateless, cacheable, uniform interface, layered system, optional code-on-demand; HTTP methods idempotent where defined.

gRPC uses HTTP/2 and Protocol Buffers; efficient and strongly typed, less browser-native than REST/JSON.

Message patterns: request-reply, publish-subscribe, competing consumers, dead-letter queue, saga for distributed transactions.

Interoperability layers: syntactic (format/protocol), semantic (shared meaning), organizational (process/policy); most failures are semantic.

API versioning: URI, header, media-type versioning; deprecation requires a documented sunset period.

Backward compatibility: additive changes are safe; removing or renaming fields requires a new major version.

ATAM phases: present ATAM, business drivers, architecture, approaches, utility tree, analyze approaches, brainstorm scenarios, analyze, present results.

Utility tree: quality attribute -> refinement -> scenario -> (importance, difficulty of realization); prioritize to focus evaluation effort.

Sensitivity point significantly affects one quality attribute; tradeoff point affects two or more attributes in opposite directions.

Risk: decision with potentially undesirable consequences; non-risk: good decision; risk themes aggregate risks for management.

Lightweight evaluation (scenario-based, checklist-based, peer review) fits when full ATAM is too costly; document scope and participants.

Cost-benefit: compare options on lifecycle cost, risk, and quality-attribute impact; capture rationale in decision records.

Fitness functions: automated tests verifying architectural characteristics (dependency rules, performance budgets, security checks).

Evaluation outputs: prioritized scenarios, sensitivity/tradeoff points, risks, non-risks, recommendations; feed them into the architecture backlog.

Review early and at each significant change; late review finds defects that are expensive to fix.

ADR: title, status, context, decision, consequences; immutable once accepted, superseded by a new ADR.

Governance mechanisms: architecture review board, design authority, standards catalog, exception process, fitness functions in CI.

arc42 template: context, constraints, solution strategy, building blocks, runtime, deployment, decisions, quality.

ISO/IEC/IEEE 42010 defines architecture description: stakeholders, concerns, viewpoints, views, correspondence rules.

Document the context (external systems and actors) before internals; the context boundary defines scope.

Reference standards and patterns by link; record local deviations explicitly.

Governance metrics: exception count, review cycle time, standards adherence rate, technical-debt trend.

Docs-as-code: version documentation in the repository so it evolves with the system.

Every significant architecture decision traces to a requirement or quality-attribute scenario that motivated it.

CI/CD stages: build, unit test, static analysis, package, deploy to staging, integration/e2e test, promote to production; fail fast on the earliest stage.

Blue-green deployment swaps traffic between two identical environments; canary releases route a small percentage and expand on success.

IaC makes environments reproducible and auditable; drift detection compares actual state to declared state.

Observability pillars: logs, metrics, traces; add health checks, alerting thresholds, and SLOs/SLIs.

SLO defines a target reliability; error budget = 1 - SLO; burn-rate alerts trigger when the budget is consumed too fast.

Deployment puts code in production; release exposes it to users; feature flags decouple the two.

Rollback must be designed before deployment; database migrations use backward-compatible expand-contract patterns.

Operational readiness: runbooks, on-call rotation, capacity plan, backup/restore test, incident response procedure.

Blameless post-incident review captures timeline, root cause, and action items; track action items to closure.

Ethical duties: public safety and welfare first, competence limits, confidentiality, conflict-of-interest disclosure, honest reporting of risk.

If asked to sign off on an architecture you believe unsafe, document the concern in writing and escalate; do not silently comply.

Tailor communication to the audience (executive, engineering, operations); lead with the decision and its consequences.

Architecture presentation: problem, options, trade-offs, recommendation, risks; one slide per decision.

Negotiation: separate interests from positions; anchor on measurable quality attributes rather than opinions.

Mentoring and knowledge sharing are professional obligations; document decisions so the team can operate without you.

Legal/regulatory awareness: data protection (e.g., GDPR), licensing, accessibility, sector regulation constrain architecture choices.

Intellectual property: respect licenses (permissive vs. copyleft) and record third-party component provenance (SBOM).

Continuing professional development: track standards evolution and validate assumptions with prototypes before committing.