Architectural drivers

Concept · Chapter 5

What they are

Architectural drivers are the architecturally significant considerations that guide the design. They describe what you’re building and why; the design exists to satisfy them. They are the inputs to the design process:

1. Design objectives
2. Primary functional requirements
3. Quality attribute scenarios
4. Constraints
5. Architectural concerns

Design objectives

• Capture the purpose of this specific design — why is the software being designed?
• A common objective is designing an architecture for a solution ahead of development. But not the only one:
  • Project proposals / pre-sales — focus on capabilities, delivery timeframe, work breakdown, feasibility; produced fast and far less detailed than a development design.
  • Prototypes — for a proposal, to trial a technology/framework, to build a proof of concept (POC), or to test how a quality attribute might be met. Different scope and focus than a development design.

Primary functional requirements

• The functionality critical to the organization’s business goals — much of it flows from the core domain (what makes the software worth writing and differentiates the org from competitors; see Domain-driven design).
• Caveat: not all functionality is shaped by the architecture. Some is highly architecture-dependent; other functionality could be delivered equally well by different architectures. Even architecture-neutral features can still be drivers for other reasons — e.g. later maintainability/modifiability, which the architecture affects.

Quality attribute scenarios

• Quality attributes are measurable properties (the “-ilities”) and are among the main drivers, because design decisions determine which are met.
• Expressed as a quality attribute scenario: a short description of how the system should respond to a stimulus, making the attribute measurable and testable. “Fast” isn’t testable; “when the user selects Login, the Login page appears within two seconds” is.

Prioritizing quality attribute scenarios

• Prioritize before design starts so you can focus on high-priority attributes first and reason about trade-offs.
• Rank each scenario on two axes — business importance (from stakeholders) and technical risk (from the architect) — using High / Medium / Low.
• Plot scenarios on an importance × risk grid; those toward the bottom-right (H, H) matter most and should be addressed in early iterations, working down through H,M and M,H, etc.

Constraints

• Decisions imposed on the project that the architecture must honor and usually can’t change. Fixed from the start.
• Technical (mandated technology, target environment, language) or non-technical (a regulation, a deadline).
• Internal (from within the org, some control) or external (from outside, little/no control).

Architectural concerns

• Design issues important to the architect (rather than to stakeholders as functional requirements/quality attributes are). They aren’t captured as functional requirements.
• A concern may instead be recorded as a quality attribute, or it may spawn new quality attribute scenarios. Example: a concern about instrumentation/logging that, if not already covered by maintainability, becomes a new quality attribute.
• Good architects recognize likely concerns from the type of software being built, and new concerns can arise from previous design iterations.

Related concepts

• Software architecture design
• Using a systematic approach to software architecture design
• Attribute-driven design (ADD)
• Requirements engineering

Citations

• Software Architect’s Handbook (Packt, 2018), Ch.5 “Architectural drivers”, pp. 292-300.