Effective Practices for Continuous Software Architecture Eoin Woods April 2025 Agile Meets Architecture 

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 

THE AGILITY IMPERATIVE 5 

6 Agile Delivery Enables Rapid and Effective Change 

Agile Aims for Continuous Evolution 7 Continuous evolution Less known early in delivery Less value in “up front” architecture 

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 

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 … 

INTRODUCING CONTINUOUS ARCHITECTURE 10 

• 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 

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 

Continuous Architecture Practices 13 Provide Leadership Focus on Quality Attributes Drive Architectural Decisions Manage Technical Debt Implement Feedback Loops 

THE PRACTICES OF CONTINUOUS ARCHITECTURE 14 

PRACTICE: PROVIDE (TECHNICAL) LEADERSHIP 15 

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 

PRACTICE: FOCUS ON QUALITY ATTRIBUTES 17 

• 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 

Focus on Quality Attributes 19 Business Concern Scenarios (show implications) Measurement Tactics Quality Attributes Technical Attention 

PRACTICE: DRIVE ARCHITECTURAL DECISIONS 20 

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! 

PRACTICE: MANAGE TECHNICAL DEBT 22 

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? 

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 

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 

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 

PRACTICE: IMPLEMENT FEEDBACK LOOPS 27 

Implement Feedback Loops 28 Code Repo Architecture Cycle Architectural Decisions & Knowledge Delivery Pipeline Artefact Measurements Operational Measurements Consider both trends and limits Production 

• 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... 

TO CONCLUDE 30 

Architecture: From Top-Down & UpFront 31 

… towards Democratised and Continuous 32 

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 

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... 

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 

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 

Eoin Woods [email protected] 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?