Trade-off analysis
A trade-off analysis makes visible which goals an option strengthens and which costs it entails. It combines criteria with a comprehensible recommendation.
- CriteriaWhere variants are measured.
- CostsEach option has an opposite side.
- DriversThe context decides.
Context
Why this is important
Without named criteria, the choice of structure falls according to preferences or trends. A comparison shows what a variant wins and what it costs. How the decision is recorded shows the architectural decision and ADR.
This building block structures the comparison. Architectural decision records the chosen option and reasons; ADR documents the resulting decision.
At a glance · Options against criteria
Shop structure according to concrete criteria
The shop checks a modular monolith structure and independently provided services. The team compares change autonomy with operational and network effort.
This is how you read the picture
- Criteria Lines such as “Provision”, “Operational responsibility” and “Data Consistency”.
- Costs Column “variant: separate services”: “Network contracts with latency and error cases”.
- Drivers Line “Appropriate Driver”: small teams against proven need for independent deployment.
| Criterion | Modular monolith baseline | Variant: Separate services |
|---|---|---|
| Delivery | A shop artifact | Services provided individually |
| Timeliness communications | Module contract in the process | Network contracts with latency and error cases |
| Operational responsibility | Activities in common application | Per Service Metrics, Alerts and Readiness |
| Data consistency | Local transactions within the application | Distributed flows and alignment rules |
| Appropriate driver | Small teams and joint release capability | Demonstrated need for independent provision |
Benefits & limitations
Helps if:
- Alternatives distribute quality, effort and risk differently between development, operation and use.
- Consequential decisions need an explicit comparison of uncertainty, constraints and reversal costs.
Boundaries
- Weighted scores can obscure mandatory constraints; check mandatory criteria before every assessment.
- Uncertain assumptions can change the ranking; vary sensitive values or measure them before committing.
- The comparison informs the decision; record that decision in an ADR and verify it with Fitness Functions.
In practice
- Adopt the comparison criteria. Use the quality goals already made concrete and the mandatory constraints. Check that all alternatives are assessed under the same conditions. Quality attributes explores how to develop measurable scenarios.
- Assess alternatives and constraints. Identify viable options, exclusion criteria and consequences for operations and future changes. Distinguish measurements from estimates. This clarifies which choices remain available.
- Present the comparison and uncertainty. Place goal attainment, reversal costs and sensitive assumptions side by side. Identify what additional evidence could change the assessment. Pass this basis to the Architecture decision, where the accountable choice is made.
Read the detailed explanation
A trade-off analysis reveals how design options affect several goals at once. It uses measurable goals from Quality attributes, checks mandatory constraints and compares viable alternatives by benefit, effort and risk. Exclusion criteria narrow the options; negotiable goals are weighted by importance.
Assumptions and measurements are reported separately. Sensitivity analysis asks which changes in load, cost or tolerance would alter the assessment. Small experiments can reduce these uncertainties. The result is a reasoned comparison with visible trade-offs and open questions, forming the basis for the subsequent Architecture decision.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
What data consistency does the variant with separate services have?
View the solution with justification
Distributed flows and balancing rules. The modular monolith uses local transactions within the application.
ApplyingTransferred to a new situation
The payment function needs demonstrably independent provision, the rest does not. What conclusions do you draw?
View the solution with justification
The driver “independent provision” applies only for payment. Check a targeted service variant for this capability and leave the remaining modules in the modular monolith.
EvaluateWeighing an alternative
The team wants to build all modules immediately as services in order to be flexible later on. How do you rate that?
View the solution with justification
The possible autonomy gain is not proven, but the costs for operation, network and consistency are incurred immediately. Without a proven need, the baseline is the better starting point.
Explore further
These building blocks continue the thoughts of this page.
References
- SEI – ATAM: Method for Architecture Evaluation (opens in new tab)Describes the scenario-based assessment of quality objectives, risks and conflicts of objectives.
- arc42 – Quality Requirements (opens in new tab)Helps to describe quality goals as testable scenarios for architectural decisions.
- Microsoft – Performance Efficiency Tradeoffs (opens in new tab)Compares the impact of performance decisions on cost, safety and reliability.