Architecture drivers
Architecture drivers are requirements and conditions with a particularly great influence on the design. Their prioritization guides decisions to the most effective questions.
- DriversRequirement with great influence on the design.
- ConstraintMandatory specification which delimits the solution space.
- PriorityOrder by influence.
Context
Why this is important
Not every requirement shapes the architecture equally strongly. Without ranking, the design is based on chance or volume instead of the most effective influences. Measurable quality goals deal with a separate building block.
This building block explains the selection of formative influences. For measurable quality expectations, see Quality Attributes.
At a glance · Three drivers, one architecture
Prioritized drivers of the shop
The shop must accept orders, clarify payments reliably and work with a prescribed payment provider. The team prioritizes these influences over detailed decisions.
This is how you read the picture
- Drivers The lines “Accept order” and “Clarify unclear payment status” with priority high.
- Constraint The line “Determined provider”: Art Constraint, priority binding.
- Priority The priority column: high for formative drivers, medium for catalogue images, binding for the constraint.
| Aspects | Species | Influence on the design | Priority |
|---|---|---|---|
| Accepting an order | Function | Coordinate ordering and storage module | High |
| Clarify unclear payment status | Quality | Stable payment identification code and status query | High |
| Dedicated provider | Constraint | Adaptor in the payment module | Binding |
| Exchange of catalogue images | Changes | remains in the catalogue module | Medium |
Benefits & limitations
Helps if:
- A project must decide which needs are given particular priority in the selection of structures.
- Several objectives compete and require a jointly agreed priority.
Boundaries
- Drivers identify what matters, rather than how good it must be; a measurable Quality Attribute makes the expectation testable.
- A constraint such as a mandated provider is binding rather than subject to prioritisation; check it against Constraints.
- A list in which every item has high priority provides no guidance; some requirements, such as catalogue images, are not architectural drivers.
In practice
- Identify influential needs. Collect requirements, risks and constraints, then determine which affect architectural decisions. Produce a focused list rather than an unstructured catalogue of wishes.
- Determine the structural impact. Trace which boundaries, responsibilities, contracts or runtime relationships follow from each need. Use measurable scenarios from Quality Attributes as inputs instead of redefining them here.
- Agree priorities and provenance. Identify an owner, the binding status and a review point for each driver. Assess Constraints separately so that non-negotiable conditions remain distinct from prioritised goals.
Read the detailed explanation
A driver matters when satisfying it calls for particular structures, interfaces or operating practices. Business capabilities can shape the architecture through their criticality or usage patterns; binding constraints also limit the available options. Functional Requirements describes required capabilities, while Quality Attributes sets out measurable expectations for their behaviour.
Prioritise drivers by their impact on boundaries, responsibilities, contracts and runtime structure. Record the connection between each requirement or constraint and the affected design choice so that later changes remain traceable. Measurable quality scenarios are inputs here; they are developed in Quality Attributes.
An architecturally significant requirement (ASR) is a requirement that substantially shapes the design.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
What is the priority of the “Exchange catalogue images” driver?
View the solution with justification
appropriations. The change remains in the catalogue module and does not shape the overall structure.
ApplyingTransferred to a new situation
The team is considering building the payment status query later. Which driver speaks against it?
View the solution with justification
“Clarify unclear payment status” is a high-priority quality driver. It requires a stable payment identifier and a status query that influence the design from the beginning.
EvaluateWeighing an alternative
The team wants to set all drivers to “high”. Does that make sense?
View the solution with justification
It works justly, but takes away the list’s steering effect: If everything is high, then a basis for the decision is missing in case of conflicts of goals. The specified provider does not belong in the ranking anyway, because as a constraint it is binding.
Explore further
These building blocks continue the thoughts of this page.
References
- arc42 · Introduction and objectives (opens in new tab)Business goals, stakeholders and prioritized quality goals as a starting point.
- arc42 · Boundary conditions (opens in new tab)Explicitly specify technical and organizational requirements.
- arc42 · Quality requirements (opens in new tab)Translate abstract quality goals into verifiable scenarios.