| Term | Definition |
|---|---|
| ASR | Architecturally Significant Requirement — a requirement with a measurable impact on architecture, whether functional or non-functional. Ultimately measured by high cost of change |
| Quality attribute | A measurable or testable property of a system indicating how well it satisfies stakeholder needs |
| NFR | Non-functional requirement — criteria used to evaluate the whole system rather than a specific behaviour |
| Constraint | A requirement that removes design freedom; almost always architecturally significant |
| Tactic | A design decision to achieve a quality attribute response, with no trade-offs considered internally. "Atoms" |
| Pattern | A design solution for a concrete context and problem, with trade-offs built in. "Molecules" |
| Style | The highest level of granularity — layers, high-level modules, their interaction and relations |
| Structure | A set of elements and their organisation |
| View | A representation of a structure, documented per a template in a chosen notation, for some stakeholders |
| Viewpoint | The conventions for constructing, interpreting, using and analysing one type of view — where you look from |
| Perspective | A collection of activities, tactics and guidelines ensuring the system exhibits a set of related quality properties. Applied to views; never produces new views |
| AD | Architecture Description — consists of one or more views, plus possibly principles, standards and glossaries |
| SAD | Software Architecture Document |
| Business driver | A resource, process or condition vital for continued business success and growth. Named with a noun |
| Business goal / objective | A goal is a general statement of desired achievement; an objective is a specific step to reach it. Both SMART |
| Business capability | What a business does now and must do to meet future challenges — the what, not the how |
| Value stream | An end-to-end collection of value-adding activities creating a result for a customer or stakeholder, using capabilities as steps |
| RACI | Responsible, Accountable, Consulted, Informed. Exactly one Accountable per activity; accountability precedes responsibility |
| Transition requirement | A capability needed only to move from current to future state, not needed once the change completes |
| Utility tree | QA → attribute refinement → prioritised ASR scenarios, each rated for business importance and difficulty to achieve (H/M/L) |
| QAW | Quality Attribute Workshop — SEI's eight-step scenario elicitation. Mini and nano variants exist |
| Six-part scenario | Source, Stimulus, Artifact, Environment, Response, Response measure |
| ADD | Attribute-Driven Design — iterative design method organised into rounds (steps 1–7) and iterations (steps 2–7) |
| ATAM | Architecture Tradeoff Analysis Method — SEI's architecture evaluation method |
| Coupling / Cohesion | Coupling is interdependence between modules; cohesion is relatedness within a module. Low coupling, high cohesion |
| SOA vs microservices | Scope: SOA is enterprise, microservices are application |
| Mediator vs broker | Event-driven topologies: mediator orchestrates multi-step events centrally; broker chains events with no central orchestration |
| Fault → Error → Failure | The fault is the defect; the error is the incorrect state liable to lead to failure; the failure is observable non-compliance with the specification, detected by users |
| Redundancy types | Spatial (copies in different places), temporal (over time, e.g. recovery blocks), informational (multiple versions of data) |
| Hot / warm / cold standby | Determines switchover speed; checkpoints help a warm standby catch up faster |
| Blue-green / canary | Zero-downtime deployment techniques. Canary is the answer when automated test coverage is low |
| CAP | Consistency, Availability, Partition tolerance — under partition you choose availability or consistency |
| BASE | Basically available, Soft state, Eventual consistency |
| Scale cube | X = cloning, Y = functional decomposition, Z = data sharding |
| Cone of uncertainty | The best-case estimate accuracy at each project point. Narrows only through project control — otherwise it becomes a cloud |
| Parkinson's Law / Student Syndrome | Why overestimation's penalty is linear and bounded, while underestimation's is nonlinear and unbounded |
| Accuracy vs precision | Independent. The precision you present should match the accuracy you actually have |
| WBS | Work Breakdown Structure — deliverable-oriented (scope) or task-oriented (work) |
| Law of Large Numbers | Why decomposed bottom-up estimates beat one big estimate: errors partly cancel |
| Wideband Delphi | Anonymous iterative group estimation; any "no" vote returns the group to discussion |
| TCO | Total Cost of Ownership — initial plus all continuing costs through final decommissioning |
| NIST five properties | On-demand self-service, broad network access, resource pooling, rapid elasticity, measured service |
| hpaPaaS | High-productivity aPaaS — declarative, model-driven, low-code/no-code, opaque infrastructure |
| Pets vs cattle | Whether losing one server takes everything down, or the herd carries on unaffected |
| Immutable infrastructure | Never modify instances in place; replace to update; plan for failure; don't let instances get stale |
| DIKW | Data → Information → Knowledge → Insight. Data is always right; information can be wrong |
| Analytics maturity | Descriptive → Diagnostic → Predictive → Prescriptive → Cognitive |
| Splittable compression | Compressed files must remain splittable or parallel frameworks lose their main advantage |
| Avro vs Parquet | Row-oriented, self-describing, schema-evolving (raw data) vs columnar with predicate pushdown (processed data) |
| Split-brain / fencing | Two active masters corrupting data; fencing ensures only one remains active |
| Consumer group | Kafka's abstraction generalising queueing (same group = load balanced) and pub-sub (different groups = broadcast) |
| AMQP vs JMS | AMQP specifies the wire format but no standard API; JMS specifies the API but not the message format |
| Visibility timeout | SQS: too small cascades and chokes threads; too large delays failover |
| Governance characteristics | Discipline, Transparency, Independence, Accountability, Responsibility, Fairness |
Unit 13 of 14
RFPLumen DiagnosticsOpen anytime - every module Task uses this brief0% complete