Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Effective Practices for Continuous Architecture

Eoin Woods
November 26, 2022

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.

Eoin Woods

November 26, 2022
Tweet

More Decks by Eoin Woods

Other Decks in Programming

Transcript

  1. PRACTICES FOR EFFECTIVE CONTINUOUS ARCHITECTURE EOIN WOODS iSAQB Software Architecture

    Gathering November 2022
  2. Eoin Woods • Endava’s CTO, based in London (since 2015)

    • 10+ years in products - Bull, Sybase, InterTrust • 10 years in capital markets - UBS and BGI • Software developer, architect, now CTO • Author, editor, speaker, community guy
  3. THE CHANGING FACE OF SOFTWARE DEVELOPMENT 4

  4. Software Development in the age of Digital Platforms • Platforms

    are ”always on” • Platforms are built to evolve in unpredictable ways • Some intelligent behaviour is becoming expected • Continual updates to the software (and infrastructure) • Parallel developments occur on a platform • Platforms are highly connected • 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. Eoin Woods Endava [email protected] @eoinwoodz and @[email protected] 33 THANK YOU

    … QUESTIONS?