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

Democratising Software Architecture

Eoin Woods
September 09, 2021

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.

Eoin Woods

September 09, 2021
Tweet

More Decks by Eoin Woods

Other Decks in Programming

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
    [email protected]
    @eoinwoodz
    25
    THANK YOU … QUESTIONS?

    View Slide