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

Software Architecture for a Digital Age

Eoin Woods
October 14, 2021

Software Architecture for a Digital Age

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

October 14, 2021
Tweet

More Decks by Eoin Woods

Other Decks in Programming

Transcript

  1. SOFTWARE ARCHITECTURE FOR A DIGITAL AGE
    EOIN WOODS
    SOFTWARE ARCHITECTURE GATHERING
    OCTOBER 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
    • Author, editor, speaker, community guy

    View Slide

  3. SOFTWARE ARCHITECTURE
    FOR A DIGITAL AGE
    3

    View Slide

  4. The Digital Age: Intelligent Connected Platforms

    View Slide

  5. Digital Platform Characteristics
    5
    Always On
    Cloud-Based
    Unpredictable Direction
    Parallel Evolution
    Extensible by Design
    “Intelligent” Behaviour
    Many Interfaces
    Highly Connected
    Publicly Accessible
    Regular Deployment

    View Slide

  6. Digital Platform Characteristics
    6
    Multi Dimensional
    Software Architecture and Engineering
    Challenge!

    View Slide

  7. Evolving Practice
    7
    FLUID
    EVOLVING
    ARCHITECTURE
    DevOps (and SRE)
    Microservices and Serverless
    Cloud Infrastructure
    Agile Working
    Reusable Cloud Services

    View Slide

  8. THE CHANGING ROLE OF THE ARCHITECT
    8

    View Slide

  9. What is the problem?
    9
    ? ?
    !!
    ?
    !!
    !! ? !!

    View Slide

  10. Traditional software architecture is of less value
    10
    Autonomous teams
    Independent activity
    Constant decision making
    Architect overload
    Progress
    Blocked

    View Slide

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

    View Slide

  12. 12
    “Continuous Architecture” is one of the
    emerging responses to these challenges

    View Slide

  13. CONTINUOUS SOFTWARE ARCHITECTURE
    13

    View Slide

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

  15. 15
    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

  16. • 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
    16
    www.continuousarchitecture.info
    Murat Erder &
    Pierre Pureur, 2015

    View Slide

  17. Architecture
    Largely Up-Front
    Iterative Development
    (with architecture refinement)
    Incremental Delivery
    Test
    Deliver
    Analysis
    Design
    Construct
    iN i1
    i2
    Stakeholder
    Concerns
    Moving to Continuous Software Architecture

    View Slide

  18. 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

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

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

  21. To make artefacts useful they must be …
    Minimal
    Usable
    Significant
    Indexed
    Checked
    Have an audience
    Have a purpose
    and always …

    View Slide

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

    View Slide

  23. Essential Continuous Architecture Activities
    23
    Provide
    Leadership
    Focus on
    Quality
    Attributes
    Drive
    Architectural
    Decisions
    Manage
    Technical
    Debt
    Implement
    Feedback
    Loops
    Leadership not management
    Technical concerns not budget and time
    “Technical conscience” of the team
    System wide concerns
    Often forgotten in ”dash to features”
    Tradeoffs and specialist knowledge
    Ensure good decisions are made
    Ensure principles understood and followed
    Ensure decisions are captured & understood
    Constantly measure
    Understand the implications
    Manage intentionally
    Measure delivery & operation
    Spot trends and warning levels
    Use to assess architectural quality
    Use to focus architectural attention

    View Slide

  24. TO CONCLUDE
    24

    View Slide

  25. Software development is changing:
    so will software architecture
    25
    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

  26. Architect: From Purveyor of Wisdom …
    26

    View Slide

  27. … to Trusted Leader and Advisor
    27

    View Slide

  28. To Find Out More
    28
    continuousarchitecture.info
    continuous-architecture.com

    View Slide

  29. Eoin Woods
    Endava
    [email protected]
    @eoinwoodz
    29
    THANK YOU … QUESTIONS?

    View Slide