Save 37% off PRO during our Black Friday Sale! »

Software Architecture for a Digital Age

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.

6facddda8e4536c0b0bfbdaf45e50675?s=128

Eoin Woods

October 14, 2021
Tweet

Transcript

  1. SOFTWARE ARCHITECTURE FOR A DIGITAL AGE EOIN WOODS SOFTWARE ARCHITECTURE

    GATHERING OCTOBER 2021
  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
  3. SOFTWARE ARCHITECTURE FOR A DIGITAL AGE 3

  4. The Digital Age: Intelligent Connected Platforms

  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
  6. Digital Platform Characteristics 6 Multi Dimensional Software Architecture and Engineering

    Challenge!
  7. Evolving Practice 7 FLUID EVOLVING ARCHITECTURE DevOps (and SRE) Microservices

    and Serverless Cloud Infrastructure Agile Working Reusable Cloud Services
  8. THE CHANGING ROLE OF THE ARCHITECT 8

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

    !! ? !!
  10. Traditional software architecture is of less value 10 Autonomous teams

    Independent activity Constant decision making Architect overload Progress Blocked
  11. Traditional software architecture is of less value 11 Constant evolution

    Less known early in delivery Less value in “up front” architecture
  12. 12 “Continuous Architecture” is one of the emerging responses to

    these challenges
  13. CONTINUOUS SOFTWARE ARCHITECTURE 13

  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!
  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
  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
  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
  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
  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
  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
  21. To make artefacts useful they must be … Minimal Usable

    Significant Indexed Checked Have an audience Have a purpose and always …
  22. Essential Continuous Architecture Activities 22 Provide Leadership Focus on Quality

    Attributes Drive Architectural Decisions Manage Technical Debt Implement Feedback Loops
  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
  24. TO CONCLUDE 24

  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
  26. Architect: From Purveyor of Wisdom … 26

  27. … to Trusted Leader and Advisor 27

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

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