Skip to content

Adr Decision Drivers

Decision drivers are the forces, concerns, and requirements that influence architectural decisions. Identifying and documenting these drivers clearly is essential for creating ADRs that explain not just what was decided, but why.

Decision drivers are factors that:

  • Constrain the solution space
  • Prioritize certain qualities over others
  • Represent stakeholder concerns
  • Create tension requiring trade-offs
CategoryDescriptionExamples
FunctionalWhat the system must doFeatures, capabilities, integrations
Quality AttributesHow well system must performPerformance, security, reliability
ConstraintsFixed limitationsBudget, timeline, technology mandates
BusinessOrganizational factorsCost, time-to-market, compliance
TechnicalEngineering considerationsMaintainability, testability, complexity
TeamHuman factorsSkills, capacity, preferences

Ask these questions to uncover drivers:

Functional Drivers

  • What must this system do?
  • What capabilities are essential vs nice-to-have?
  • What integrations are required?

Quality Attribute Drivers

  • What are the performance requirements?
  • How critical is availability?
  • What are the security requirements?
  • How important is scalability?

Constraint Drivers

  • What is the budget?
  • What is the timeline?
  • What technologies are mandated?
  • What regulations apply?

Business Drivers

  • What is the cost sensitivity?
  • How important is time-to-market?
  • What is the risk tolerance?
  • What competitive factors matter?

Technical Drivers

  • How complex can the solution be?
  • What is the expected maintenance burden?
  • How important is extensibility?
  • What testing requirements exist?

Team Drivers

  • What skills does the team have?
  • What capacity is available?
  • What are team preferences?
  • What training would be needed?
AttributeDefinitionMeasures
PerformanceResponse time, throughputLatency (ms), requests/sec
ScalabilityHandle increased loadConcurrent users, data volume
AvailabilitySystem uptimePercentage uptime, MTBF
ReliabilityCorrect operationError rate, MTTR
SecurityProtection from threatsVulnerabilities, compliance
MaintainabilityEase of changesChange effort, code complexity
TestabilityEase of testingTest coverage, test time
UsabilityUser experienceTask completion time, errors
AttributeDefinitionMeasures
PortabilityRun on different platformsPlatform support, migration effort
InteroperabilityWork with other systemsIntegration points, standards
ModifiabilitySupport changesChange impact, coupling
ObservabilityMonitor system stateMetrics, logs, traces
DeployabilityEase of deploymentDeployment frequency, time
RecoverabilityRecovery from failureRTO, RPO
## Decision Drivers
* **{Driver Name}** - {Brief description of the driver and why it matters}
* **{Driver Name}** - {Brief description}
## Decision Drivers
* **High availability required** - System must maintain 99.9% uptime as per SLA
* **Limited budget** - Total solution cost must not exceed $50K/year
* **Team lacks Kubernetes expertise** - Any container orchestration must be learnable quickly
* **Compliance with GDPR** - User data must be stored in EU region
* **Sub-100ms response time** - API latency critical for user experience
## Decision Drivers
* Performance
* Cost
* Easy to use

Problems: Too vague, no specifics, no prioritization

PriorityMeaningTreatment
MustNon-negotiableSolution must satisfy
ShouldImportantSatisfy if possible
CouldNice to haveInclude if easy
Won’tOut of scopeExplicitly excluded

List drivers in order of importance:

  1. {Most critical driver}
  2. {Second most important}
  3. {Third priority} …

Assign weights to drivers:

DriverWeight (1-5)
Availability5
Performance4
Cost3
Maintainability2

Common quality attribute trade-offs:

Trade-offDescription
Performance vs MaintainabilityOptimized code harder to maintain
Security vs UsabilityMore security often means more friction
Scalability vs CostScaling often increases infrastructure cost
Flexibility vs SimplicityConfigurable systems are more complex
Speed vs QualityFaster delivery may reduce quality
### Trade-offs Accepted
We accept:
- **Higher infrastructure cost** for improved availability
- **Increased complexity** for better extensibility
- **Longer initial development** for lower maintenance burden
OptionDriver 1Driver 2Driver 3Score
Option A+++-4
Option B++++5
Option C-+++4

Scoring: ++ (2), + (1), 0 (0), - (-1), — (-2)

For each option, evaluate against each driver:

### Option 1: PostgreSQL
* **High availability**: Good - supports replication, mature tooling
* **Limited budget**: Moderate - open source but requires expertise
* **Team expertise**: Good - team has SQL experience
  1. Missing drivers - Failing to identify all relevant factors
  2. Vague drivers - “Performance” instead of “sub-100ms response time”
  3. No prioritization - Treating all drivers as equal
  4. Ignoring constraints - Forgetting budget, timeline, compliance
  5. Technology bias - Letting preferred tech drive requirements
  6. Single perspective - Not gathering input from all stakeholders

Gather drivers from:

  • Product owners (business requirements)
  • Architects (technical requirements)
  • Operations (operational requirements)
  • Security team (security requirements)
  • Users (usability requirements)
  1. What would make this decision successful?
  2. What would make it fail?
  3. What constraints must we work within?
  4. What quality attributes matter most?
  5. What trade-offs are acceptable?
  6. What risks concern you?

For comprehensive guidance on specific aspects:

  • references/quality-attributes.md - Detailed quality attribute definitions
  • references/trade-off-patterns.md - Common trade-off patterns and resolutions
  • adr-fundamentals - ADR basics and lifecycle
  • adr-quality - Quality review criteria
  • adr-format-madr - MADR format with decision drivers section
  • adr-compliance - Auditing code against ADR decisions