Search for a command to run...
A Guide for Software Architects
Outdoorsman | Networking | SRE | Chaos & Platform Engineering | DevOps @toyotaracing | former @aws @splunk @verizon @gm | Thoughts are my own
Personal: Husband | GirldadX3 | BBQ | Outdoors | Nascar | Baseball | Triathlons
No comments yet. Be the first to comment.
How to scale, modernize, and mature your observability practice
Part 1 of a 2 part series
Introduction In the rapidly evolving world of software development, Continuous Integration (CI) and Continuous Deployment (CD) have become cornerstone practices that ensure software quality and agility. CI/CD pipelines serve as the backbone of modern...
Introduction In software development, documentation is the spinach of coding—vital yet often sidelined. It's the unsung hero, the nutrient-rich foundation that sustains projects and teams. Imagine each software project accompanied by a precise recipe...
On this page
As a software architect, you make choices that shape systems for years. The “one-way vs. two-way door” framework from Jeff Bezos helps classify decisions by reversibility and impact. It keeps teams agile without risking structural failures. Here’s how it works, why architects need it, and how to apply it.
Every decision is a door you step through:
Two-Way Doors: Reversible, low-stakes choices. If it fails, you step back. Think adjusting a microservice or testing a caching strategy. Most decisions (80-90%) are these—make them with 70% of the data, delegate to engineers, and iterate quickly.
One-Way Doors: High-stakes, hard-to-undo choices that lock behind you. Think selecting a core database or committing to a cloud provider. Slow down, collect data, and analyze deeply.
Treating all decisions as one-way doors stifles progress. Rushing one-way doors threatens system integrity. Master this, and you balance speed with reliability.
Architects design scalable, maintainable systems amid evolving requirements and tech debt. Misjudge decisions, and you either bog down in overanalysis or face expensive overhauls. Here’s the impact:
Two-Way Door Mistakes: Overthinking minor choices—like a logging tweak—slows delivery and blocks innovation. Speed keeps systems adaptive.
This is one of my favorite quotes^^
One-Way Door Errors: Hastening major calls—like a flawed architecture pattern—leads to migrations that disrupt operations and inflate costs.
This framework enables rapid prototyping on reversible elements while safeguarding foundational structures, aligning with architecture’s demand for resilience and evolution.
Apply this to common scenarios architects face:
Component Tweaks (Two-Way Door)
Refining an API endpoint or adding a load balancer config? Use canary releases, test in staging, and revert if needed. This enables quick experiments for better performance.
Impact: Maintains momentum, refines designs. Consider how teams at scale iterate on services without halting production.
Configuration Shifts (Two-Way with Risks)
Changing from monolithic to modular configs? Monitor metrics and adjust, but poor rollout risks downtime. Assign to your dev team, track health closely, and roll back fast.
Impact: Evolves setups efficiently but requires vigilance to avoid outages.
Hiring Specialists (One-Way for Key Roles)
Adding a junior devops engineer? Reversible via trials. A lead architect or org restructure? That’s one-way—shifts in expertise are tough to reverse. Scrutinize these hires.
Impact: Strong teams drive architecture; weak ones breed debt.
Tech Stack Commitments (One-Way Door)
Picking a database engine or orchestration tool? Migrating later involves data loss risks and refactoring. Prototype extensively and validate scalability first.
Impact: Right choices enable growth; wrong ones constrain it or escalate expenses.
Integration or Overhauls (One-Way Door)
Adopting a new framework or acquiring legacy systems? These bind you to dependencies and patterns. Conduct thorough reviews and contingency planning.
Impact: Successful integrations expand capabilities (like major cloud adoptions); failures burden maintenance.
Implement it like this:
Classify Decisions: Ask, “Is this one-way or two-way?” It sharpens focus and streamlines processes.
Empower Engineers: Delegate two-way doors with defined metrics to foster ownership and velocity.
Protect One-Way Doors: Deploy checklists—risks, trade-offs, simulations—to mitigate pitfalls.
Review Results: Log outcomes. Did two-way tweaks succeed? Did one-way selections endure? Hone your judgment.
Cultivate Action Bias: Encourage speed on reversible items. Overanalysis here erodes efficiency.
Prevent “decision creep” where reversible choices feel irreversible due to caution. Rely on simulations and metrics for objectivity. Context evolves: a two-way door in prototypes (like a protocol swap) may become one-way in production.
This framework supports calculated risks. Accelerate on minor adjustments to evolve designs, but fortify major commitments for lasting stability. For architects, it’s essential to building robust systems without paralysis.
Facing a tough call? Share in the comments or DM me—let’s determine if it’s one-way or two-way and refine your architecture!
