Architecture does not fail only because of bad choices. It also fails because of the false idea that everything important can be decided once at project kickoff. This chapter argues for the opposite: architecture lives inside the delivery flow and needs constant recalibration.
What makes it practical is the way it connects quality attributes, delayed commitment, small increments, governance, and feedback loops to actual delivery cadence. That helps teams avoid both extremes: postponing important decisions forever and freezing them too early.
In interviews and review conversations, the book is useful because it gives you process language rather than diagram language alone: which decisions must happen early, which should wait, and how architecture hypotheses get validated inside delivery.
Practical value of this chapter
Continuous mindset
Moves architecture from a one-time phase to a continuous process in the delivery loop.
Quality attributes first
Keeps non-functional requirements central instead of treating them as late add-ons.
Decision timing
Teaches delaying expensive commitments until information improves while controlling risk.
Interview maturity
Demonstrates architecture as an ongoing discipline, not a static diagram snapshot.
Source
CoA Book Club
The chapter material is based on the book analysis in the Code of Architecture book club
Continuous Architecture in Practice: Software Architecture in the Age of Agility and DevOps
Authors: Murat Erder, Pierre Pureur, Eoin Woods
Publisher: Addison-Wesley Professional
Length: 352 pages
6 principles of continuous architecture: from projects to products, quality attributes, delay decisions and architecture for DevOps.
Related book
Building Evolutionary Architectures
Fitness Functions, evolution of architecture and architectural quantum
6 principles of Continuous Architecture
6 principles of Continuous Architecture
First stream: Chapters 1–2
Chapter 1: Why Software Architecture is More Important Than Ever
Architecture in the Agile world, architecture in the cloud, the role of the architect as a “non-value adder”. Definition of Continuous Architecture and set of principles. Description of the end-to-end case study.
Chapter 2: Architecture in Practice—Essential Activities
- Making and governing architectural decisions
- Quality attributes and technical debt
- Feedback Loops: Fitness Functions, Continuous Testing
- Models and notations for describing architecture
- Architecture as a decision flow
Stream guest
Maxim Smirnov — IT architect, author of the “Architecture of IT Solutions” channel. In the past, the chief architect of Beeline, the Bank of Russia and Binbank Digital.
Related book
Learning Domain-Driven Design
DDD, Bounded Contexts, Event Sourcing and Integration Patterns
Second stream: Chapters 3–4
Chapter 3: Data Architecture
- DDD: Ubiquitous Language and Bounded Contexts
- Polyglot Persistence: SQL/NoSQL
- Consistency Models and Eventual Consistency
- Event Sourcing
- Data Ownership and Analytics
- Schema Evolution in SQL and NoSQL
Chapter 4: Security as an Architectural Concern
- CIA triad: Confidentiality, Integrity, Availability
- Threat identification and prioritization
- Threat Modeling
- Shift-Left Security
- Zero Trust Architecture
Materials mentioned
Stream guests
- Vaclav Dovnar — independent consultant on secure development processes
- Dmitry Gaevsky — engineer of dev-to-dev solutions, RnD and event-driven systems
Related book
Site Reliability Engineering
SLO, error budgets, monitoring and four golden signals from Google
Third stream: Chapters 5–6
Chapter 5: Scalability
Architectural approaches to scaling:
- Stateless load
- Stateful load
- Horizontal and vertical scaling
Chapter 6: Performance
Performance as an architectural characteristic:
- Why performance is important
- Performance Monitoring
- Optimization techniques
Materials mentioned
Stream guests
- Alexey Tarasov — develops the architecture of Tinkoff Investments
- Daniil Kuleshov — architect of the new authorization system
Related book
Release It!
Resilience Patterns: Circuit Breaker, Bulkhead, Timeouts
Fourth stream: Chapters 7–9
Chapter 7: Resilience
Sustainability as an architectural characteristic. Patterns: Circuit Breaker, Bulkhead, Retry, Timeout.
Chapter 8: Emerging Technologies
AI and Blockchain - their impact on software architecture.
Chapter 9: Conclusion
Summing up the book and recommendations for implementing Continuous Architecture.
Resilience materials mentioned
Stream guests
- Evgeny Peshkov — technical lead, founder of the DDDevotion community
- Sergey Baranov — architect, founder of the ArchDays conference
Source
Telegram: book_cube
Post by Alexander Polomodov about Resilience
Resilience as an architectural characteristic
Basic terminology
Fault
A random condition that, if it occurs, can lead to the failure of a system or component.
Failure
A situation where the system deviates from the required behavior. Fault is the cause, Failure is the consequence.
Availability
Measurable characteristic: the ratio of availability time to the total system operating time.
Reliability
Probability of failure-free operation over a specified period of time in a specified environment.
High-Availability vs Resilience
Old Approach: High-Availability
- Application and Database Clusters
- Cross-site data replication
- Hot standby for emergency transfer
Problems: complexity, high cost, long failover, complete inaccessibility during recovery
New approach: Resilience
- Each part of the system is responsible for its stability
- Adaptive behavior during failures
- Limiting error propagation (blast radius)
Advantages: flexibility, graceful degradation, quick recovery of individual components
Key insight: High-Availability was designed for monolithic on-premise systems. For distributed microservice systems (on-premise or in the cloud), Resilience is a more suitable approach.
MTBF vs MTTR
MTBF
Mean Time Between Failures
Mean time between failures. The focus of the High-Availability approach is to maximize the time between failures.
MTTR
Mean Time To Recover
Average recovery time. Focus of the Resilience approach: minimize cooldown and blast radius.
Paradigm Shift: In modern systems, part failures occur quite often. Instead of trying to prevent all failures (MTBF), it is more important to learn to recover quickly (MTTR) and limit the impact of failures.
Mechanisms for providing Resilience
Repeated requests
Retry with exponential backoff
Automatic restart
Self-healing processes
Circuit Breaker
Open circuit during faults
Bulkhead
Isolation of system compartments
Timeout
Correct work with latency
Fallback
Spare answer options
Additional Resources
The authors created the website continuous-architecture.org with a set of documents:
Related chapters
- What is software architecture and why is it in System Design? - sets the overall frame where Continuous Architecture is treated as an ongoing decision process, not a separate project phase.
- Building Evolutionary Architectures (short summary) - adds the baseline on fitness functions and managed evolution that continuous architecture principles rely on.
- Evolutionary architecture in practice - shows the applied layer: incremental changes, coupling management, and evolution triggers in real teams.
- Architecture at scale: how we make architecture decisions - covers the organizational side of the continuous approach via RFC/ADR, decision logs, and lightweight governance.
- T-Bank architecture evolution (2006-2025) - provides a long-horizon production case of moving from project-centric to continuous architecture practices.