Effective Practices for Continuous Architecture (30 mins)

Continuous Software Architecture is a philosophy and approach to software architecture that embraces the fact that doing most of the design before the implementation does not work very well, and perhaps never did. The approach tries to move architecture from a set of up-front blueprints to a continually developed set of architectural knowledge and decisions, stressing collective ownership of the resulting architecture. While a simple idea, actually putting it into practice can be difficult. In this talk we will briefly recap the idea of Continuous Software Architecture and then explore the key practices that are usually needed to achieve it, as well as the common problems and how to address them.

Transcript

1. Effective Practices for Continuous Software Architecture Eoin Woods April 2025 Agile Meets Architecture
2. Eoin Woods • Endava’s Chief Engineer, based in London (2015 - 2025) • 10+ years in products - Bull, Sybase, InterTrust • 10 years in capital markets - UBS and BGI (BlackRock) • Software developer, architect, now Chief Engineer • Author, editor, speaker, community participant
3. THE AGILITY IMPERATIVE 5
4. 6 Agile Delivery Enables Rapid and Effective Change
5. Agile Aims for Continuous Evolution 7 Continuous evolution Less known early in delivery Less value in “up front” architecture
6. So why bother with architecture? 8 • Achieving quality attributes • Balancing stakeholder concerns • Making complex tradeoffs • Resolving cross cutting concerns across many independent parts Cross-Cutting Concerns Tradeoffs Stakeholders Quality Attributes
7. Architecture Needs to be More “Continuous” 9 requirements design build validation completion architectural effort time inception architectural effort time delivery 0 delivery 1 delivery 2 delivery ‘n’ … iterative, incremental, early & frequent delivery, finding feedback, adapting and evolving …
8. INTRODUCING CONTINUOUS ARCHITECTURE 10
9. • Principle 1: Architect products: evolve from projects to products • Principle 2: Focus on quality attributes, not functional requirements • Principle 3: Delay design decisions until absolutely necessary • Principle 4: Architect for change – leverage the “power of small” • Principle 5: Architect for build, test, deploy and operate • Principle 6: Model the organisation of your teams after the design of the system Continuous Architecture Principles 11 www.continuousarchitecture.info Murat Erder & Pierre Pureur, 2015
10. Continuous Architecture Artefacts 12 Styles & Patterns: Common solutions to repeating problems Evolving Shared Design Principles 1. We prefer industry protocols, then standard in-house ones, then ad-hoc point-to-point ones 2. Partner specific detail must not pollute domain model … 3. Do not use cloud specific services Principles 1. We prefer industry protocols, then standard in-house ones, then ad-hoc point-to-point ones 2. Partner specific detail must not pollute domain model … 3. Do not use cloud specific services Principles 1. We prefer industry protocols, then standard in-house ones, then ad-hoc point-to-point ones 2. Partner specific detail must not pollute domain model … 3. Do not use cloud specific services Principles: Guidance to achieve aligned design decisions Decisions: Understanding what we did, when and why
11. Continuous Architecture Practices 13 Provide Leadership Focus on Quality Attributes Drive Architectural Decisions Manage Technical Debt Implement Feedback Loops
12. THE PRACTICES OF CONTINUOUS ARCHITECTURE 14
13. PRACTICE: PROVIDE (TECHNICAL) LEADERSHIP 15
14. Provide Leadership • Leading rather than ”managing” • Form and lead a technical leadership group • Lead the resolution of technical concerns • What are the key architecture principles? • Which “least worst” option to choose? • What can be deferred, what needs to be done now? (Tech debt) • Drive constant progress towards technical excellence • What are the long-term consequences of decisions? • Be ”the conscience of the team” • Represent the technical view ”upwards” 16 Start With Why: The Inspiring Million-Copy Bestseller That Will Help You Find Your Purpose (Paperback) Page 1 Page 1 https://www.pexels.com/@fauxels
15. PRACTICE: FOCUS ON QUALITY ATTRIBUTES 17
16. • Cross-cutting concerns that need system level attention • Most product owners (and so teams) are focused on features • Using scenarios helps to make the need for QAs clear • Tell a story in a structured way • Prioritisation is key and an important architectural activity • Usually a balance across security, performance, scalability, resilience • Make sure the stories get into the backlog – PO conversations Quality Attributes Architectural Approach 18 https://pixabay.com/users/publicdomainpictures-14 Image result for software architecture viewpoints perspectives Continuous Architecture in Practice: Software Architecture in the Age of Agility and DevOps (Addison-Wesley Signature Seri... Software Architecture in Practice, 4th Edition Cover: Designing Software Architectures: A Practical Approach
17. Focus on Quality Attributes 19 Business Concern Scenarios (show implications) Measurement Tactics Quality Attributes Technical Attention
18. PRACTICE: DRIVE ARCHITECTURAL DECISIONS 20
19. Drive Architectural Decisions • Making, validating, managing and implementing good decisions is key to doing architecture continuously • Use the technical leadership group to drive this process • Capture decisions in an accessible way • e.g. ADRs in Git or wiki pages in a well-defined form • Curating decisions over time is important • Control the number & organise the catalogue • Revalidate and remove obsolete decisions • Feedback into the architecture principles 21 https://www.pexels.com/@karolina-grabowska Remember: you need to make sure good decisions are made, not make all the decisions!
20. PRACTICE: MANAGE TECHNICAL DEBT 22
21. Manage Technical Debt 23 Technical debt is a well established yet nebulous concept … … very context specific One person’s “debt” is another person’s “simplest thing possible” Hard coded validation rather than a chain-of-responsibility of validators. Debt? Or simple and effective?
22. Does Technical Debt Matter? 24 Technical debt matters when it stops us doing something … … it is now too expensive to make a change … or we are too slow to react to a need … or our team is too inefficient to be valuable … or it is too risky to update our technology The team needs to be looking ahead to predict and avoid these situations
23. Sources of Technical Debt 25 Environment Changing Context Development Practice Team Structure • Time and cost • Poor requirements • Unrealistic goals • Business context change • Technology change • Evolution through success • Poor testing • Lack of peer review & collaborative work • Inconsistent approach • Inexperience with technology or domain • Lack of communication & understanding • Part time ad-hoc teams Source: Managing Technical Debt, Kruchten, Nord, Ozkaya
24. Dealing With Technical Debt 26 Just-in-Time Cleanup Little and Often 0 5 10 15 20 25 30 1 2 3 4 5 6 7 8 Technical Debt Total by Sprint -1 1 3 5 7 9 11 13 15 1 2 3 4 5 6 7 8 Debt Remediation Effort by Sprint 0 5 10 15 20 25 30 35 1 2 3 4 5 6 7 8 Technical Debt Total by Sprint
25. PRACTICE: IMPLEMENT FEEDBACK LOOPS 27
26. Implement Feedback Loops 28 Code Repo Architecture Cycle Architectural Decisions & Knowledge Delivery Pipeline Artefact Measurements Operational Measurements Consider both trends and limits Production
27. • Feedback loops are your ”architectural reality check” • Automated, semi-automated and manual all have their place • Typically measure quality attributes but can be functional • Internal (e.g. code complexity) and external (e.g. API response time) are both important • Start small and simple, targeting biggest risks or concerns • Over time the implementation can become complex Implement Feedback Loops 29 https://unsplash.com/photos/DKSWyxtcPVQ Continuous Architecture in Practice: Software Architecture in the Age of Agility and DevOps (Addison-Wesley Signature Seri...
28. TO CONCLUDE 30
29. Architecture: From Top-Down & UpFront 31
30. … towards Democratised and Continuous 32
31. In Conclusion 33 Agile Continuous Evolution Continuous Software Engineering Less value in ”Up Front” Architecture Continuous Architecture Technical Leadership Quality Attributes Decisions Technical Debt Feedback Loops
32. Just Enough Software Architecture: A Risk-Driven Approach by George H. Fairbanks (2010-08-30) Further Reading on Continuous Architecture 34 continuousarchitecture.info continuous-architecture.com Continuous Architecture: Sustainable Architecture in an Agile and Cloud-Centric World Continuous Architecture in Practice: Software Architecture in the Age of Agility and DevOps (Addison-Wesley Signature Seri...
33. Further Reading on Architecture Practice 35 Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives Software Architecture in Practice, 4th Edition Cover: Designing Software Architectures: A Practical Approach
34. Further Reading on Leadership 36 Start With Why: The Inspiring Million-Copy Bestseller That Will Help You Find Your Purpose (Paperback) Page 1 Page 1
35. Eoin Woods eoin.woods@artechra.com https://www.agile-meets-architecture.com/speakers/2025-eoin-woods https://www.eoinwoods.info eoinwoods.bluesky.social @eoinwoodz (Threads, Instagram and X) 37 THANK YOU … QUESTIONS?