Slide 1

Slide 1 text

PRACTICES FOR EFFECTIVE CONTINUOUS ARCHITECTURE EOIN WOODS November 2023

Slide 2

Slide 2 text

Eoin Woods • Endava’s Chief Engineer, based in London (since 2015) • 10+ years in products - Bull, Sybase, InterTrust • 10 years in capital markets - UBS and BGI • Software developer, architect, now Chief Engineer • Author, editor, speaker, community guy

Slide 3

Slide 3 text

THE CHANGING FACE OF SOFTWARE DEVELOPMENT 4

Slide 4

Slide 4 text

Software Development in the age of Digital Platforms • Platforms are built to evolve in unpredictable ways • Continual updates to the software (and infrastructure) • Parallel developments occur on a platform • Multiple interfaces and audiences to be accommodated • Platforms must be extensible by design 5 A multi-dimensional software engineering challenge!

Slide 5

Slide 5 text

So Software Practice Evolved 6 FLUID EVOLVING ARCHITECTURE DevOps (and SRE) Microservices and Serverless Cloud Infrastructure Agile Working Reusable Cloud Services

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

INTRODUCING CONTINUOUS ARCHITECTURE 8

Slide 8

Slide 8 text

Is architecture still needed? 9 • 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!

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

THE ACTIVITIES OF CONTINUOUS ARCHITECTURE 13

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

Provide Leadership • Leading rather than ”managing” • Get the team doing the architecture work • Lead the resolution of technical concerns • What are the key architecture principles? • Which option to choose when none is perfect? • What can be deferred, what needs to be done now? (Tech debt) • What are the options when something ”impossible” is needed? • Constant progress towards technical excellence • What are the right ways of working? • What are the long-term consequences of decisions? • ”the conscience of the team” • Represent the technical view ”upwards” • “difficult conversations” 15 https://www.pexels.com/@fauxels

Slide 15

Slide 15 text

Leadership: a Technical Leadership Group • Form a team to own the architecture & technical concerns • Technical Leadership Group, Tech Leads Group, … • Spreads knowledge across the team • Empowers others to take responsibilities with support • Topic champions for security, performance, resilience, … • Provides technical growth opportunities • Allows multiple perspectives for decision making • Frees up your time • But there does need to be a decision making mechanism (usually you) 16 https://www.pexels.com/@fauxels

Slide 16

Slide 16 text

• Reminder probably unnecessary for quality attributes! • “the architect’s obsession” • Constant process of balancing tradeoffs • Cross-cutting concerns that need system level attention • The question is how to get attention for them? • Most teams and product owners are obsessed by features • ”how many stories in this sprint?” (meaning ”features”) • Quality attributes often not needed ”this sprint” • Stores up potential problems for later • How do we integrate them into Continuous Architecture? Focus on Quality Attributes 17 https://pixabay.com/users/publicdomainpictures-14

Slide 17

Slide 17 text

Focus on Quality Attributes 18 Business Concern Scenarios (illustrate implications) Measurement Tactics Quality Attributes Technical Attention

Slide 18

Slide 18 text

• Get attention using scenarios – make the need clear • Stimulus + Response + Measurement (+ implications if needed) • Consider using a Quality Attribute Tree to organise them • Prioritisation is key and an important architectural activity • Working across stakeholder groups to find an acceptable balance • Security, performance, scalability, resilience are normally important • Evolution (maintainability, flexibility) is normally assumed • Help the team to break down these huge goals into stories • Implementation of architectural tactics, styles & patterns • Make sure the stories get into the backlog – PO conversations • Own some of the difficult ones (e.g. resilience & BCP) • Find people to be ”champions” for the others Quality Attributes Architectural Approach 19 https://pixabay.com/users/publicdomainpictures-14

Slide 19

Slide 19 text

Drive Architectural Decisions • Less detailed models means decisions and principles become more important – new first-class artefacts of architecture • Architectural decisions are how we … • achieve quality properties (via tactics) • make tradeoffs • manage technical debt • achieve sustainable delivery • maximise value 20 https://www.pexels.com/@karolina-grabowska Actually they always were … we used to just hide them in our models!

Slide 20

Slide 20 text

Drive Architectural Decisions • Making, validating, managing and implementing decisions is core to doing architecture continuously • We must ensure that good decisions are made • Practical, logical, balanced, well-argued, well-communicated • Ensure decisions align with our architecture principles • Or cause the principles to evolve • Decisions must be captured, understood, implemented and curated 21 https://www.pexels.com/@karolina-grabowska

Slide 21

Slide 21 text

Drive Architectural Decisions • Use the technical leadership group to: • Make decisions • Validate decisions • Communicate decisions • Implement decisions 22 https://www.pexels.com/@karolina-grabowska Remember: you need to make sure good decisions are made, not make all the decisions! • Capture decisions in an accessible way • ADRs in Git appear to have become something of a standard • https://adr.github.io/ and https://github.com/npryce/adr-tools • Simple wiki pages with a well defined format also work well • Curating decisions over time is important • Control the number & organise the catalogue • Revalidate and remove obsolete decisions • Feedback into the architecture principles

Slide 22

Slide 22 text

Manage Technical Debt 23 Technical debt is a well established yet nebulous concept … … very context specific One person’s “debt” is another person’s “simplest thing possible” Hard coded validation rather than a chain-of-responsibility of validators. Debt? Or simple and effective?

Slide 23

Slide 23 text

Does Technical Debt Matter? 24 Technical debt matters when it stops us doing something … … it is now too expensive to make a change … we are too slow to react to a need … our team is too inefficient to be valuable … it is too risky to update our technology It is these situations that the architect needs to be looking ahead for, to predict and avoid

Slide 24

Slide 24 text

Sources of Technical Debt 25 Environment Changing Context Development Practice Team Structure • Time and cost • Poor requirements • Unrealistic goals • Business context change • Technology change • Evolution through success • Poor testing • Lack of peer review & collaborative work • Inconsistent approach • Inexperience with technology or domain • Lack of communication & understanding • Part time ad-hoc teams Source: Managing Technical Debt, Kruchten, Nord, Ozkaya

Slide 25

Slide 25 text

Dealing With Technical Debt 26 Just-in-Time Cleanup Little and Often 0 5 10 15 20 25 30 1 2 3 4 5 6 7 8 Technical Debt Total by Sprint -1 1 3 5 7 9 11 13 15 1 2 3 4 5 6 7 8 Debt Remediation Effort by Sprint 0 5 10 15 20 25 30 35 1 2 3 4 5 6 7 8 Technical Debt Total by Sprint

Slide 26

Slide 26 text

Dealing With Technical Debt 27 Unified backlog for visibility and prioritisation Unified Backlog Features Arch Debt

Slide 27

Slide 27 text

Implement Feedback Loops 28 Code Repo Production Architecture Cycle Architectural Decisions & Knowledge Delivery Pipeline Artefact Measurements Operational Measurements Measurements can be trends or limits Internally or externally focused Good ones provide architectural “reality checks”

Slide 28

Slide 28 text

• Feedback loops are your ”architectural reality check” • Automated, semi-automated and manual all have their place • Typically measure quality attributes but can be functional • Internal (e.g. code complexity) and external (e.g. API response time) are both important • Start small and simple, targeting biggest risks or concerns • Over time the implementation can become complex • Don’t fall in love with your feedback loop implementation! Implement Feedback Loops 29 https://unsplash.com/photos/DKSWyxtcPVQ

Slide 29

Slide 29 text

TO CONCLUDE 30

Slide 30

Slide 30 text

In Conclusion 31 https://unsplash.com/photos/NOBZdtTTGrg Cloud Agile + DevOps Digital Platforms Continuous Software Engineering Less value in ”Up Front” architecture Continuous Architecture Technical Leadership Quality Attributes Decisions Technical Debt Feedback Loops

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

Further Reading (Technical) 33

Slide 33

Slide 33 text

Further Reading (Leadership) 34

Slide 34

Slide 34 text

Eoin Woods Endava [email protected] @eoinwoodz and @[email protected] 35 THANK YOU … QUESTIONS?