Including Reversal Options in Technical Decisions
Reversal options limit the consequences of incorrect assumptions. Data export, isolated coupling, and clear triggers keep decisions reversible.
For management and product managers, "Keeping Technical Decisions Reversible" can be assessed primarily based on two points: "Decisive Trigger" and "Paper Rollback." This comparison makes the technical limits tangible.
Published: 3 min read · Author: Sebastian Geier
How can technical decisions be designed with reversal options from the outset?
Before implementation, it is determined which signal calls the decision into question and until when a rollback is still worthwhile. Data, configuration, and interfaces are managed in such a way that a defined predecessor or backup path can be reactivated. The rollback is tested like an operational readiness test, not just documented.
Paper Rollback
Paper Rollback – A plan exists but was never executed with real data and dependent systems.
Permanent Parallelism – The old path remains in operation without an end criterion, thus doubling testing and maintenance.
One-Way Data Migration – New states cannot be rolled back into the previous model, rendering the option unusable.
Critical Trigger
Critical Trigger – An observable technical or business signal indicates when decommissioning is considered instead of further repairs.
Limited Decommissioning Window – It is clear up to which data or architecture version the option remains safe and economically viable.
Recoverable State – Data, versions, and configurations allow reversion to a tested, working state.
Recoverable State
Time from the decommissioning decision to the restored working state in the final test run.
Proportion of critical data changes that remain transferable without loss within the defined decommissioning window.
Limited Decommissioning Window
Before implementation, define the damage pattern, the trigger for dismantling, and the latest reasonable decision point.
Automate the data and configuration path for dismantling and test it in an isolated environment.
After rollout, monitor signals and remove the parallel structure after an explicit retention decision.
Case review: "Paper rollback"
A new search service is initially activated for a limited page type. Index data remains reproducible, the old search can be reverted via configuration, and both methods provide comparable telemetry. The old implementation is only deactivated after a stable monitoring period.
How "Keeping Technical Decisions Reversible" relates to other topics
An in-depth question answered Multi-Tenancy from the Start or Only When Needed?Should multi-tenancy be built immediately or added only when needed?
Further Perspectives Controlled rollout of schema versions and changes.
If you want to put "Keeping Technical Decisions Reversible" into practice, you can refer to Robust Website Systems This focuses on "Architectural Boundaries and Scaling" and "Critical Trigger."
Conclusion: Keep technical decisions reversible
Reversibility transforms uncertainty into a limited operational option. It remains realistic only if the trigger, data path, and timeframe have been practically tested.
Sources and Further Information
The following official documentation and standards provide the technical classification.
Choosing Technology: An Introduction – GOV.UK Service ManualOfficial guidance on prototyping integrations, carefully cutting components, and evolving via open standards.
14. Operate a reliable service – GOV.UK Service ManualOfficial standard for the operation, availability, recovery, and continuous improvement of reliable services.
OpenAPI SpecificationPrimary specification for machine-readable HTTP API contracts, including operations, data models, and error responses.
Key Thesis
A reversal option identifies the trigger, ensures data portability, and limits dependencies. It is documented during the decision-making process, including costs and responsibilities.
What This Is Not About
Reversibility does not mean implementing every change twice or permanently carrying around old systems. Nor is it a promise to reverse every decision without cost.
What it's about
A reversal option limits the damage from a false assumption through a known trigger, secured data, and an executable alternative. Its scope depends on the uncertainty and potential impact.
Platform strategy & build vs. buy
Plan for resilience based on business risk, not prestige
The question "How can the necessary level of fault tolerance be derived from the business risk?" is a separate review step within the "Reversible Technical Decisions" framework.
Platform strategy & build vs. buy
Monolithic or modular architecture for growing web systems
"When should a growing web system remain monolithic and when should it become modular?" is a separate decision to consider.
Insights Overview
All VELUNO Insights at a Glance
Further analyses on Website Systems, digital visibility, and robust working models.
Limited Reduction Window: Starting Point for Implementation
Before a release that is difficult to reverse, the reduction option should undergo the same reality check as the forward path. A release readiness review can refine triggers, data paths, and shutdown criteria together.