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

Democratising Software Architecture

6facddda8e4536c0b0bfbdaf45e50675?s=47 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.

6facddda8e4536c0b0bfbdaf45e50675?s=128

Eoin Woods

September 09, 2021
Tweet

Transcript

  1. DEMOCRATISING SOFTWARE ARCHITECTURE EOIN WOODS SEPTEMBER 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 • Software engineer in theory & practice (BSc, MSc, PhD) • Author, editor, speaker, community guy
  3. SOFTWARE ARCHITECTURE FOR THE DIGITAL AGE 3

  4. The Digital Age: Intelligent Connected Platforms

  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
  6. What has changed? 6 FLUID EVOLVING ARCHITECTURE DevOps Microservices Cloud

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

    !! ? !!
  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
  9. CONTINUOUS SOFTWARE ARCHITECTURE 9

  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!
  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
  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
  13. Architecture Largely Up-Front Iterative Development Incremental Delivery Test Deliver Analysis

    Design Construct iN i1 i2 Stakeholder Concerns Moving to Continuous Software Architecture
  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
  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
  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
  17. When creating artifacts make them … Minimal Usable Significant Indexed

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

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

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

  23. … to Trusted Leader and Advisor 23

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

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