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
   iSAQB Software Architecture Gathering
   November 2022
   

   View Slide

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
   

   View Slide

3. THE CHANGING FACE OF
   SOFTWARE DEVELOPMENT
   4
   

   View Slide

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!
   

   View Slide

5. So Software Practice Evolved
   6
   FLUID
   EVOLVING
   ARCHITECTURE
   DevOps (and SRE)
   Microservices and Serverless
   Cloud Infrastructure
   Agile Working
   Reusable Cloud Services
   

   View Slide

6. Traditional software architecture is of less value
   7
   Constant evolution
   Less known early in delivery
   Less value in “up front” architecture
   

   View Slide

7. INTRODUCING CONTINUOUS ARCHITECTURE
   8
   

   View Slide

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!
   

   View Slide

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
   

   View Slide

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
    

    View Slide

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
    

    View Slide

12. THE ACTIVITIES OF CONTINUOUS ARCHITECTURE
    13
    

    View Slide

13. Essential Continuous Architecture Activities
    14
    Provide
    Leadership
    Focus on
    Quality
    Attributes
    Drive
    Architectural
    Decisions
    Manage
    Technical
    Debt
    Implement
    Feedback
    Loops
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

17. Focus on Quality Attributes
    18
    Business
    Concern
    Scenarios
    (illustrate
    implications)
    Measurement
    Tactics
    Quality
    Attributes
    Technical
    Attention
    

    View Slide

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
    

    View Slide

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!
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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?
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

26. Dealing With Technical Debt
    27
    Unified backlog for
    visibility and
    prioritisation
    Unified
    Backlog
    Features
    Arch
    Debt
    

    View Slide

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”
    

    View Slide

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
    

    View Slide

29. TO CONCLUDE
    30
    

    View Slide

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
    

    View Slide

31. To Find Out More
    32
    continuousarchitecture.info
    continuous-architecture.com
    

    View Slide

32. Eoin Woods
    Endava
    eoin.woods@endava.com
    @eoinwoodz and @eoinwoods@mastodonapp.uk
    33
    THANK YOU … QUESTIONS?
    

    View Slide