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 architecture reviews, 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
This chapter is based on the Code of Architecture book club review of the book.
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
Six principles of continuous architecture: product thinking, quality attributes, delayed decisions, and architecture embedded in the delivery flow.
Continuous architecture treats architecture as ongoing work inside the delivery flow rather than a set of decisions locked in at kickoff. The book keeps returning to quality attributes, feedback loops, technical debt, and the cost of change as everyday architecture concerns.
The central question is timing. Some decisions have to be made early, because their cost rises sharply once the system is built around them; others should be deliberately delayed and kept open until the context becomes clearer. That is why the book keeps pulling architecture back into automation, operations, and the realities of modern delivery instead of leaving it as a diagram at kickoff.
Related book
Building Evolutionary Architectures
Fitness functions, managed evolution, and architectural quanta.
Six principles of continuous architecture
Six principles of continuous architecture
The organizational principle is especially important here: system structure and team structure should not drift apart. The authors connect this idea to the Inverse Conway Maneuver and to Team Topologies as a way to align team boundaries with the architecture the system is supposed to grow into.
Session 1: Chapters 1–2
Chapter 1: Why architecture matters more than ever
The opening chapter explains why architecture matters even more in an Agile, cloud, and DevOps world. The architect is no longer a rare specialist who hands down a design once; architecture becomes an ongoing discipline tied to the end-to-end case study from the book.
Chapter 2: Architecture in practice and essential activities
- Making and maintaining architectural decisions
- Quality attributes and technical debt
- Feedback loops: fitness functions and continuous testing
- Models and notations for describing architecture
- Architecture as a continuous decision flow
Guest speaker
Maxim Smirnov is an IT architect and the author of the “Architecture of IT Solutions” channel. He previously served as chief architect at Beeline, the Bank of Russia, and Binbank Digital.
Related book
Learning Domain-Driven Design
DDD, bounded contexts, event sourcing, and integration patterns.
Session 2: Chapters 3–4
In the data and security part, the book ties bounded contexts, event sourcing, eventual consistency, and data ownership to product architecture. On the security side, the focus shifts to threat modeling, shifting security left, and zero trust as architecture concerns rather than last-minute checks.
Chapter 3: Data architecture
- DDD: ubiquitous language and bounded contexts
- Polyglot persistence across SQL and NoSQL
- Consistency models and eventual consistency
- Event sourcing
- Data ownership and the analytical plane
- Schema evolution in SQL and NoSQL systems
Chapter 4: Security as an architectural concern
- The CIA triad: confidentiality, integrity, availability
- Threat identification and prioritization
- Threat modeling
- Shift-left security
- Zero trust architecture
Materials mentioned
Guest speakers
- Vaclav Dovnar is an independent consultant on secure development practices.
- Dmitry Gaevsky works on developer-facing solutions, R&D initiatives, and event-driven systems.
Related book
Site Reliability Engineering
SLOs, error budgets, monitoring, and Google's four golden signals.
Session 3: Chapters 5–6
Chapter 5: Scalability
Architectural approaches to scaling:
- Stateless workloads
- Stateful workloads
- Horizontal and vertical scaling
Chapter 6: Performance
Performance as an architectural characteristic:
- Why performance becomes an architecture concern
- Which signals help track it
- Which optimization techniques fit different load profiles
Materials mentioned
Guest speakers
- Alexey Tarasov develops the architecture of Tinkoff Investments.
- Daniil Kuleshov is the architect of a new authorization system.
Related book
Release It!
Resilience patterns such as circuit breakers, bulkheads, and timeouts.
Session 4: Chapters 7–9
Chapter 7: Resilience
Resilience as an architectural characteristic. Patterns such as circuit breakers, bulkheads, retries, and timeouts.
Chapter 8: Emerging technologies
AI and blockchain as forces that reshape architectural constraints and trade-offs.
Chapter 9: Conclusions
A wrap-up of the book and practical guidance for adopting continuous architecture.
Resilience-related materials
Guest speakers
- Evgeny Peshkov is a technical lead and the founder of the DDDevotion community.
- Sergey Baranov is an architect and the founder of the ArchDays conference.
Source
Telegram: Book Cube
Post by Alexander Polomodov on resilience as an architecture topic.
Resilience as an architectural characteristic
This part of the book draws a clear line between high availability and resilience. It shows how availability and reliability are measured separately, why failover alone is not enough, and how to reduce blast radius by designing for localized recovery.
The practical takeaway is to design for graceful degradation, use backoff strategies in retries, and treat latency as part of the user experience instead of a low-level implementation detail.
Basic terminology
Fault
A condition that may trigger a failure in the system or one of its components.
Failure
A situation where the system deviates from expected behavior. Fault is the cause; failure is the observable consequence.
Availability
A measurable property: the ratio of time the system remains available to total operating time.
Reliability
The probability of failure-free operation over a specified period in a specified environment.
High availability and resilience
Traditional approach: high availability
- Application and database clusters
- Cross-site data replication
- Hot standby for failover
Problems: complexity, high cost, long failover, and complete unavailability during recovery
Modern approach: resilience
- Each subsystem owns its local resilience
- The system adapts to partial failures
- Errors are contained instead of spreading across the whole system
Advantages: flexibility, graceful degradation, and faster recovery of individual components
Key takeaway: traditional high-availability schemes grew out of monolithic on-premise systems. For distributed microservice systems, whether on-premise or in the cloud, resilience is usually the more useful architectural strategy.
MTBF and MTTR
MTBF
Mean Time Between Failures
The average time between failures. High-availability thinking tries to maximize this interval.
MTTR
Mean Time To Recover
The average recovery time. Resilience thinking focuses on shortening recovery and containing the blast radius.
Paradigm shift: in modern systems, localized failures happen often enough that trying to prevent every one of them is not realistic. What matters more is recovering quickly and keeping the damage contained.
Resilience mechanisms
Retries
Retry with progressively increasing backoff
Automatic restart
Self-healing of processes and containers
Circuit breaker
Temporarily open the circuit when a dependency fails
Bulkhead
Separate resources so a local failure does not sink the whole system
Timeouts
Explicit waiting limits and deliberate latency handling
Fallback
A backup response path or degraded operating mode
Additional materials
The authors maintain continuous-architecture.org, which collects additional materials around the approach:
Manifesto
The principles of continuous architecture on one page — something to check against when a debate drifts into abstractions.
OpenFramework
The toolkit for when principles need to turn into how you actually run this inside an organization.
OpenGetting started
First steps for adopting the approach on one manageable slice rather than rolling it out everywhere at once.
OpenRelated chapters
- What Software Architecture Is and Why It Matters in System Design - sets the broader frame where architecture is treated as ongoing work on boundaries, trade-offs, and quality attributes rather than a one-time design 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 - drops to the applied layer: incremental change, deliberate coupling, and the signals that tell you architecture needs to evolve.
- Architecture at Scale: How We Make Architectural Decisions - covers the organizational side of the topic through RFCs, ADRs, decision logs, and lightweight architecture governance.
- Evolution of T-Bank Architecture (2006–2024) - provides a long-horizon production case of architecture moving from a project phase to an ongoing engineering discipline.