Based on research across technology organizations, three distinct approaches have emerged for managing architecture decision-making, each with documented successes and failures:
Stripe's approach, as documented in their engineering strategy work, employs an advisory architecture review process where:
- Architecture decisions are made by the implementing team
- A group of senior engineers (Staff+) provides feedback and guidance
- No formal approval is required, but teams are expected to incorporate feedback
- Escalations go to engineering leadership only for disagreements on critical decisions
Netflix's "Freedom and Responsibility" model extends this further:
- Engineers make decisions within their sphere of responsibility
- Context is shared broadly through documentation and RFCs
- "Keeper test" ensures high-performing individuals drive decisions
- Strong emphasis on documentation to enable distributed decision-making
Documented outcomes: Both organizations report high engineering velocity and innovation, but require significant investment in hiring and retaining senior engineers capable of good judgment.
Amazon's "Two-Pizza Team" architecture combines autonomy with coordination:
- Each service team owns their architecture decisions
- Architecture review required only for cross-team dependencies
- "Well-Architected Framework" provides consistent evaluation criteria
- Bar raiser program ensures decision quality through peer review
Google's approach uses Technical Lead Networks:
- Technical Leads (TLs) in each area coordinate architecture decisions
- Area-specific expertise concentrated in dedicated roles
- Regular "Architecture Review Committee" for company-wide decisions
- Strong emphasis on written design documents and peer review
Documented outcomes: Scales well with organization size, maintains consistency across teams, but can create bottlenecks and requires significant investment in technical leadership development.
Microsoft's historical model (pre-cloud transformation):
- Central architecture board approves all significant decisions
- Detailed architecture standards and governance processes
- Technology choices limited to approved stack
- Strong emphasis on consistency and risk management
Traditional enterprise approach seen at companies like IBM, Oracle:
- Enterprise architects define technology standards
- Project approval gates require architecture compliance
- Centralized technology evaluation and vendor management
- Risk mitigation prioritized over speed
Documented outcomes: High consistency and reduced risk, but significantly slower innovation and adaptation. Many organizations have moved away from this model during digital transformation.
Michael Nygard's pattern, widely adopted across industry:
- Lightweight documentation of architecture decisions
- Captures context, options considered, and rationale
- Immutable record enabling future teams to understand reasoning
- Successfully implemented at ThoughtWorks, Spotify, and numerous startups
The "Architectural Decision Authority" pattern:
- Clearly defined decision rights at different organizational levels
- Escalation paths for cross-cutting concerns
- Balance between autonomy and coordination
- Specific implementation guidance for different organization sizes
Simon Wardley's approach to technology evolution:
- Map components by visibility to user and evolutionary stage
- Make architectural decisions based on component maturity
- Avoid "one size fits all" approaches
- Focus governance intensity on strategic components
Symptoms observed at multiple organizations:
- Senior engineers become disconnected from implementation reality
- Architecture decisions made without sufficient context
- Over-engineering of solutions for theoretical future needs
- Teams work around architecture decisions rather than following them
Documented at companies like Twitter (pre-acquisition):
- Teams reject external solutions in favor of custom implementations
- Lack of coordination leads to duplicated effort
- Technology sprawl creates maintenance burden
- Cultural bias toward complexity over simplicity
Observed in large enterprises:
- Lengthy approval processes that don't actually improve decision quality
- Rubber-stamp reviews that create delay without value
- Architecture boards that lack implementation context
- Documentation requirements that become bureaucratic overhead
- Successful approaches balance autonomy with alignment - Pure autonomy leads to chaos, pure control leads to stagnation
- Decision authority must match implementation responsibility - Those accountable for outcomes need authority to make decisions
- Written documentation is essential - All successful models invest heavily in capturing decisions and rationale
- Context matters more than consistency - Teams need framework for good decisions, not universal solutions
- Cultural fit determines success - Technical approaches must align with organizational values and hiring practices
Infrastructure as Code adoption has shifted architecture decisions toward the implementing team, as tools like Terraform and Kubernetes make previously centralized decisions (networking, security, deployment) more accessible to product teams.
Microservices proliferation has increased the volume and complexity of architecture decisions, making centralized approaches less viable for many organizations.
DevOps practices have blurred the line between development and operations decisions, requiring architecture governance to adapt to faster deployment cycles and shared ownership models.
This exploration reveals that successful architecture decision-making frameworks depend heavily on organizational context, size, and culture, but consistently require clear authority allocation, strong documentation practices, and mechanisms for knowledge sharing across teams.