Effective Practices for Continuous Architecture

Continuous Software Architecture is a philosophy and approach to software architecture that embraces the fact that today, 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. PRACTICES FOR EFFECTIVE CONTINUOUS ARCHITECTURE EOIN WOODS November 2023
2. Eoin Woods • Endava’s Chief Engineer, based in London (since 2015) • 10+ years in products - Bull, Sybase, InterTrust • 10 years in capital markets - UBS and BGI • Software developer, architect, now Chief Engineer • Author, editor, speaker, community guy
3. THE CHANGING FACE OF SOFTWARE DEVELOPMENT 4
4. Software Development in the age of Digital Platforms • Platforms are built to evolve in unpredictable ways • Continual updates to the software (and infrastructure) • Parallel developments occur on a platform • Multiple interfaces and audiences to be accommodated • Platforms must be extensible by design 5 A multi-dimensional software engineering challenge!
5. So Software Practice Evolved 6 FLUID EVOLVING ARCHITECTURE DevOps (and SRE) Microservices and Serverless Cloud Infrastructure Agile Working Reusable Cloud Services
6. Traditional software architecture is of less value 7 Constant evolution Less known early in delivery Less value in “up front” architecture
7. INTRODUCING CONTINUOUS ARCHITECTURE 8
8. Is architecture still needed? 9 • Achieving quality attributes • Balancing stakeholder concerns • Making complex tradeoffs • Achieving cross cutting concerns across many independent parts But architecture is now a continual flow of decisions Cross-Cutting Concerns Tradeoffs Stakeholders Quality Attributes Yes!
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 10 www.continuousarchitecture.info Murat Erder & Pierre Pureur, 2015
10. Moving to Continuous Architecture 11 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. Artifacts of Continuous Architecture 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
12. THE ACTIVITIES OF CONTINUOUS ARCHITECTURE 13
13. Essential Continuous Architecture Activities 14 Provide Leadership Focus on Quality Attributes Drive Architectural Decisions Manage Technical Debt Implement Feedback Loops
14. Provide Leadership • Leading rather than ”managing” • Get the team doing the architecture work • Lead the resolution of technical concerns • What are the key architecture principles? • Which option to choose when none is perfect? • What can be deferred, what needs to be done now? (Tech debt) • What are the options when something ”impossible” is needed? • Constant progress towards technical excellence • What are the right ways of working? • What are the long-term consequences of decisions? • ”the conscience of the team” • Represent the technical view ”upwards” • “difficult conversations” 15 https://www.pexels.com/@fauxels
15. Leadership: a Technical Leadership Group • Form a team to own the architecture & technical concerns • Technical Leadership Group, Tech Leads Group, … • Spreads knowledge across the team • Empowers others to take responsibilities with support • Topic champions for security, performance, resilience, … • Provides technical growth opportunities • Allows multiple perspectives for decision making • Frees up your time • But there does need to be a decision making mechanism (usually you) 16 https://www.pexels.com/@fauxels
16. • Reminder probably unnecessary for quality attributes! • “the architect’s obsession” • Constant process of balancing tradeoffs • Cross-cutting concerns that need system level attention • The question is how to get attention for them? • Most teams and product owners are obsessed by features • ”how many stories in this sprint?” (meaning ”features”) • Quality attributes often not needed ”this sprint” • Stores up potential problems for later • How do we integrate them into Continuous Architecture? Focus on Quality Attributes 17 https://pixabay.com/users/publicdomainpictures-14
17. Focus on Quality Attributes 18 Business Concern Scenarios (illustrate implications) Measurement Tactics Quality Attributes Technical Attention
18. • Get attention using scenarios – make the need clear • Stimulus + Response + Measurement (+ implications if needed) • Consider using a Quality Attribute Tree to organise them • Prioritisation is key and an important architectural activity • Working across stakeholder groups to find an acceptable balance • Security, performance, scalability, resilience are normally important • Evolution (maintainability, flexibility) is normally assumed • Help the team to break down these huge goals into stories • Implementation of architectural tactics, styles & patterns • Make sure the stories get into the backlog – PO conversations • Own some of the difficult ones (e.g. resilience & BCP) • Find people to be ”champions” for the others Quality Attributes Architectural Approach 19 https://pixabay.com/users/publicdomainpictures-14
19. Drive Architectural Decisions • Less detailed models means decisions and principles become more important – new first-class artefacts of architecture • Architectural decisions are how we … • achieve quality properties (via tactics) • make tradeoffs • manage technical debt • achieve sustainable delivery • maximise value 20 https://www.pexels.com/@karolina-grabowska Actually they always were … we used to just hide them in our models!
20. Drive Architectural Decisions • Making, validating, managing and implementing decisions is core to doing architecture continuously • We must ensure that good decisions are made • Practical, logical, balanced, well-argued, well-communicated • Ensure decisions align with our architecture principles • Or cause the principles to evolve • Decisions must be captured, understood, implemented and curated 21 https://www.pexels.com/@karolina-grabowska
21. Drive Architectural Decisions • Use the technical leadership group to: • Make decisions • Validate decisions • Communicate decisions • Implement decisions 22 https://www.pexels.com/@karolina-grabowska Remember: you need to make sure good decisions are made, not make all the decisions! • Capture decisions in an accessible way • ADRs in Git appear to have become something of a standard • https://adr.github.io/ and https://github.com/npryce/adr-tools • Simple wiki pages with a well defined format also work well • Curating decisions over time is important • Control the number & organise the catalogue • Revalidate and remove obsolete decisions • Feedback into the architecture principles
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?
23. Does Technical Debt Matter? 24 Technical debt matters when it stops us doing something … … it is now too expensive to make a change … we are too slow to react to a need … our team is too inefficient to be valuable … it is too risky to update our technology It is these situations that the architect needs to be looking ahead for, to predict and avoid
24. 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
25. 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
26. Dealing With Technical Debt 27 Unified backlog for visibility and prioritisation Unified Backlog Features Arch Debt
27. Implement Feedback Loops 28 Code Repo Production Architecture Cycle Architectural Decisions & Knowledge Delivery Pipeline Artefact Measurements Operational Measurements Measurements can be trends or limits Internally or externally focused Good ones provide architectural “reality checks”
28. • 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 • Don’t fall in love with your feedback loop implementation! Implement Feedback Loops 29 https://unsplash.com/photos/DKSWyxtcPVQ
29. TO CONCLUDE 30
30. In Conclusion 31 https://unsplash.com/photos/NOBZdtTTGrg Cloud Agile + DevOps Digital Platforms Continuous Software Engineering Less value in ”Up Front” architecture Continuous Architecture Technical Leadership Quality Attributes Decisions Technical Debt Feedback Loops
31. To Find Out More 32 continuousarchitecture.info continuous-architecture.com
32. Further Reading (Technical) 33
33. Further Reading (Leadership) 34
34. Eoin Woods Endava eoin.woods@endava.com @eoinwoodz and @eoinwoods@mastodonapp.uk 35 THANK YOU … QUESTIONS?