Effective Practices for Continuous Architecture (at LAD)

Software architecture emerged in the 1990s, and has been evolving ever since, from a directive, up-front activity, where a single architect created the architecture, which was then implemented by others, to today's team based adaptive architectural approaches where architecture is a shared activity owned by the entire team.

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.

In this talk we'll explore the Continuous Architecture approach, and its 5 key practices, that delivers architecture as a "shared commons" in order to support the Agile+DevOps ways-of-working needed for success in our current era.

Transcript

1. Eoin Woods July 2025 Effective Practices for Continuous Software 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. Break, THE AGILITY IMPERATIVE
4. Evolution of Software Practice FLUID EVOLVING ARCHITECTURE DevOps (and SRE) Microservices and Serverless Cloud Infrastructure Agile Working Reusable Cloud Services
5. Agile Aims for Continuous Evolution Continuous evolution Less known early in delivery Less value in “up front” architecture
6. So why bother with architecture? • 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” 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. Break, INTRODUCING CONTINUOUS ARCHITECTURE
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 www.continuousarchitecture.info Murat Erder & Pierre Pureur, 2015
10. Moving to Continuous Architecture 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 Styles & Patterns Principles Decisions Top Down Prescriptive Design Evolving Shared Design
11. Continuous Architecture Artefacts 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
12. Continuous Architecture Practices Provide Leadership Focus on Quality Attributes Drive Architectural Decisions Manage Technical Debt Implement Feedback Loops
13. Break, 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” 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
16. PRACTICE: FOCUS ON QUALITY ATTRIBUTES
17. Quality Attributes Architectural Approach • Cross-cutting concerns that need system level attention • How do you get attention for them? • Most teams and product owners are focused on features • Get attention with scenarios – make the need clear • Tell a story in a structured way • Prioritisation is key and an important architectural activity • Security, performance, scalability, resilience are usually important • Make sure the stories get into the backlog – PO conversations 19 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
18. Focus on Quality Attributes Business Concern Scenarios (show implications) Measurement Tactics Quality Attributes Technical Attention
19. 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 https://www.pexels.com/@karolina-grabowska
21. PRACTICE: MANAGE TECHNICAL DEBT
22. Manage Technical Debt 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?
23. Does Technical Debt Matter? 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
24. Sources of Technical Debt 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
25. Dealing With Technical Debt 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
26. PRACTICE: IMPLEMENT FEEDBACK LOOPS
27. Implement Feedback Loops Code Repo Architecture Cycle Architectural Decisions & Knowledge Delivery Pipeline Artefact Measurements Operational Measurements Consider both trends and limits Production
28. Implement Feedback Loops • Feedback loops are your ”architectural reality check” • Automated, semi-automated and manual all useful • 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 https://unsplash.com/photos/DKSWyxtcPVQ Continuous Architecture in Practice: Software Architecture in the Age of Agility and DevOps (Addison-Wesley Signature Seri...
29. Break, TO CONCLUDE
30. Architecture: From Top-Down & UpFront
31. … towards Democratised and Continuous
32. In Conclusion Agile Continuous Evolution Continuous Software Engineering Less value in ”Up Front” Architecture Continuous Architecture Technical Leadership Quality Attributes Decisions Technical Debt Feedback Loops
33. continuous-architecture.com Just Enough Software Architecture: A Risk-Driven Approach by George H. Fairbanks (2010-08-30) Further Reading on Continuous Architecture continuousarchitecture.info 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...
34. Further Reading on Architecture Practice Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives Software Architecture in Practice, 4th Edition Cover: Designing Software Architectures: A Practical Approach
35. Further Reading on Leadership Start With Why: The Inspiring Million-Copy Bestseller That Will Help You Find Your Purpose (Paperback) Page 1 Page 1
36. Questions? Eoin Woods eoin.woods@artechra.com https://www.eoinwoods.info eoinwoods.bluesky.social @eoinwoodz (Threads, Instagram and X)
37. Thank you / Gracias Powered by: