Democratising Software Architecture

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. In this talk we’ll explore the architectural practices that deliver architecture as a “shared commons” which supports the Agile+DevOps ways-of-working needed for success in the digital age.

Transcript

1. DEMOCRATISING SOFTWARE ARCHITECTURE
   EOIN WOODS
   SEPTEMBER 2021
   

   View Slide

2. Eoin Woods
   • Endava’s CTO, based in London (6 years)
   • 10+ years in products - Bull, Sybase, InterTrust
   • 10 years in capital markets - UBS and BGI
   • Software engineer, architect, now CTO
   • Software engineer in theory & practice (BSc, MSc, PhD)
   • Author, editor, speaker, community guy
   

   View Slide

3. SOFTWARE ARCHITECTURE
   FOR THE DIGITAL AGE
   3
   

   View Slide

4. The Digital Age: Intelligent Connected Platforms
   

   View Slide

5. Historical Context for Software Architecture
   • Central small group
   • Organisation of large pieces
   • Relatively static connections
   • Largely completed before implementation
   • Structures, qualities, stakeholders,
   technology choices
   5
   

   View Slide

6. What has changed?
   6
   FLUID
   EVOLVING
   ARCHITECTURE
   DevOps
   Microservices
   Cloud
   Agile
   

   View Slide

7. What is the problem?
   7
   ? ?
   !!
   ?
   !!
   !! ? !!
   

   View Slide

8. Traditional software architecture is of less value
   • Constant evolution => less ”certainty” early in lifecycle
   • Less decided early in lifecycle =>
   less value in thorough ”up front” architecture
   8
   • Autonomous teams => independent activity
   • Independent activity => constant parallel decision making
   • Constant decisions => architect overload => blocks progress
   

   View Slide

9. CONTINUOUS SOFTWARE ARCHITECTURE
   9
   

   View Slide

10. Is architecture still needed?
    10
    • 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

11. 11
    Architecture is a skill not (just) a role
    Stream of decisions, not “one off” architecture
    Principles, styles & patterns over structures
    Delegate & share wherever possible
    ”Little and often” (and adapt)
    Aim for a “shared commons”
    Architecture
    Work in the
    New World
    

    View Slide

12. • 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
    12
    www.continuousarchitecture.info
    

    View Slide

13. Architecture
    Largely Up-Front
    Iterative Development Incremental Delivery
    Test
    Deliver
    Analysis
    Design
    Construct
    iN i1
    i2
    Stakeholder
    Concerns
    Moving to Continuous Software Architecture
    

    View Slide

14. Moving to Continuous Software Architecture
    Test
    Deliver
    Architecture
    Analysis
    Design
    Construct
    iN i1
    i2
    Incremental Delivery
    Architectural
    Knowledge
    Architectural
    Decisions
    Stakeholder
    Concerns
    (See Eltjo Poort’s work on
    “Risk and Cost Driven Architecture”)
    Agile Development with
    Continuous Architecture
    

    View Slide

15. Moving to Continuous Architecture
    15
    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

16. Artifacts of Continuous Architecture
    16
    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

17. When creating artifacts make them …
    Minimal
    Usable
    Significant
    Indexed
    Checked
    Have an audience
    Have a purpose
    and always …
    

    View Slide

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

    View Slide

19. 19
    Architecture work in every sprint
    Decisions, principles, styles, patterns
    Deliver decisions as they are needed
    Form an inclusive architecture group
    Practical tests to validate architecture work
    Keep the architecture ”close to the code”
    Useful
    Practices
    

    View Slide

20. TO CONCLUDE
    20
    

    View Slide

21. Software development is changing:
    so will software architecture
    21
    Agile + DevOps
    change how we WORK
    Cloud + Containers
    change how we BUILD
    Less “Upfront” Architecture
    Quality Attributes, Tradeoffs, Stakeholders
    Flow Of Decisions & Guidance
    Changes to Architect’s Work
    Changes to Architect Training
    

    View Slide

22. Architect: From Purveyor of Wisdom …
    22
    

    View Slide

23. … to Trusted Leader and Advisor
    23
    

    View Slide

24. To Delve Further
    24
    continuousarchitecture.info
    continuous-architecture.com
    

    View Slide

25. Eoin Woods
    Endava
    eoin.woods@endava.com
    @eoinwoodz
    25
    THANK YOU … QUESTIONS?
    

    View Slide