Agile Architecture and Innovation

Slide 1

Slide 1 text

Agile Architecture and Innovation Stefan Tilkov  stefan.tilkov@innoq.com  @stilkov Agile Cambridge 2019 "Science Museum, ceiling" by Elecé is licensed under CC BY 2.0

Slide 2

Slide 2 text

Topics we’ll ignore today:

Slide 3

Slide 3 text

Whether you need “Architecture” (you have no choice)

Slide 4

Slide 4 text

Whether your Agile project needs an “Architect” (no, but someone will do that architecting)

Slide 5

Slide 5 text

What to document (structure, dependencies, principles, choices)

Slide 6

Slide 6 text

Whether there should be “Architecture Stories” (no)

Slide 7

Slide 7 text

Whether the whole discussion might actually be quite pointless (possibly)

Slide 8

Slide 8 text

Instead: Architecture

Slide 9

Slide 9 text

@stilkov Conscious trade-offs over emerging architecture Documented rationale over quick ad-hoc decisions Sustained changeability over easy initial development Design for replacement over design for re-use Simplicity over fast delivery Architecture Manifesto Attempt

Slide 10

Slide 10 text

@stilkov (Software) Architecture Definitions A system’s elements, their relationships, and the rules and principles that govern their design and evolution Whatever the architect considers important enough to merit their attention Decisions that you want to be correct because they are costly to change

Slide 11

Slide 11 text

Awesome Shop CMS Archive General Ledger Print Shop HR

Slide 12

Slide 12 text

Awesome Shop CMS Archive General Ledger Print Shop HR Context

Slide 13

Slide 13 text

Awesome Shop CMS Archive General Ledger Print Shop HR Invoicing Accounting Auth Catalog Checkout & Order Search

Slide 14

Slide 14 text

Awesome Shop CMS Archive General Ledger Print Shop HR Invoicing Accounting Auth Catalog Checkout & Order Search Domain Architecture

Slide 15

Slide 15 text

Invoicing Accounting Auth Catalog Checkout & Order Search

Slide 16

Slide 16 text

Macro Architecture

Slide 17

Slide 17 text

Ruby on Rails MySQL Java Spring Boot OSS Product COTS Java Spring Boot NodeJS ElasticSearch

Slide 18

Slide 18 text

Ruby on Rails MySQL Java Spring Boot OSS Product COTS Java Spring Boot NodeJS ElasticSearch Micro Architecture

Slide 19

Slide 19 text

Invoicing Accounting Auth Catalog Checkout & Order Search

Slide 20

Slide 20 text

Invoicing Accounting Auth Catalog Checkout & Order Search

Slide 21

Slide 21 text

Invoicing Accounting Auth Catalog Checkout & Order Search

Slide 22

Slide 22 text

Invoicing Accounting Auth Catalog Checkout & Order Search Team Architecture?

Slide 23

Slide 23 text

@stilkov If your goal is to support autonomous teams, architecture is an essential ingredient

Slide 24

Slide 24 text

@stilkov Size is the #1 enemy of agility. Keep your systems as small as you can.

Slide 25

Slide 25 text

@stilkov Coming up with the “right” system boundaries is an architecture activity that must be done first

Slide 26

Slide 26 text

@stilkov Managing dependencies is the most important ongoing architecture task

Slide 27

Slide 27 text

@stilkov t Simplicity Homogeneity Cohesion Decoupling Modularity (Support for) Heterogeneity Autonomy Ease of development

Slide 28

Slide 28 text

@stilkov number of  developers strength of   decoupling methods modules components μservices systems

Slide 29

Slide 29 text

@stilkov From a layered system … System Logic Data UI Module Module Module

Slide 30

Slide 30 text

@stilkov … to a system of systems System System System Logic Data UI Logic Data UI Logic Data UI

Slide 31

Slide 31 text

Invoicing Accounting Auth Catalog Checkout & Order Search

Slide 32

Slide 32 text

Invoicing Accounting Auth Catalog Checkout & Order Search Team Architecture!

Slide 33

Slide 33 text

@stilkov Benefits 1. Isolation 2. Autonomy 3. Scalability 4. Resilience 5. Speed 6. Experimentation 7. Rapid Feedback 8. Flexibility 9. Replaceability 10. Ecosystem

Slide 34

Slide 34 text

@stilkov Centralization vs. Autonomy: Cases

Slide 35

Slide 35 text

@stilkov Context: • … Observation(s): • … Lesson(s) learned: • …

Slide 36

Slide 36 text

@stilkov Context: • E-Commerce/Online shop (Retail) • 100-120 developers, ~10 teams Observation(s): • Lack of front-end expertise led to central UI/design team, bottleneck for development, deployment, operations, evolution Lesson(s) learned: • Local optimization needs can trigger centralization • Full stack teams require full stack capabilities

Slide 37

Slide 37 text

@stilkov A general lack of specific skills, combined with a select few who have it, will sabotage any attempt at decentralizing anything requiring it

Slide 38

Slide 38 text

@stilkov Context: • E-Commerce/Online shop (Retail) • 100-120 developers, ~10 teams Observation(s): • Extremely inefficient UI integration runtime due to lack of standardization • Vast differences in API style, formats, documentation Lesson(s) learned: • Complete lack of guidance creates unproductive diversity

Slide 39

Slide 39 text

@stilkov You cannot decide to not have an architecture; if you don’t actively create it, be prepared to deal with the one that emerges

Slide 40

Slide 40 text

@stilkov There’s a fine line between diversity (that adds value) and chaos (that doesn’t)

Slide 41

Slide 41 text

@stilkov Context: • Insurance customer portal • 10-15 developers, 1 team Observation(s): • Potential for independent decisions in separated systems (almost) never exploited • Engineering effort spent on coordination Lesson(s) learned: • Premature modularization can lead to increased effort without matching benefits

Slide 42

Slide 42 text

@stilkov Context: • E-Commerce/Online shop (Retail) • 100-120 developers, ~10 teams Observation(s): • Common standard micro architecture at start of project • Gradual increase in degrees of freedom • Increase in actual diversity of tools, languages, architecture Lesson(s) learned: • Increased maturity allows for less dogma/fewer rules

Slide 43

Slide 43 text

Pattern: Regulated Market

Slide 44

Slide 44 text

@stilkov Dreyfus model of skill acquisition Novice Advanced Beginner Competence Proficient Expert Recollection Non- Situational Situational Situational Situational Situational Recognition Decomposed Decomposed Holistic Holistic Holistic Decision Analytical Analytical Analytical Intuitive Intuitive Awareness Monitoring Monitoring Monitoring Monitoring Absorbed Quality Stage

Slide 45

Slide 45 text

@stilkov Growing architectural maturity means less guidance and rules are needed

Slide 46

Slide 46 text

@stilkov The more experienced you are at (active and passive) architectural governance, the less you can do of it

Slide 47

Slide 47 text

Takeaways

Slide 48

Slide 48 text

@stilkov 1. There is no conflict between Agile and Architecture

Slide 49

Slide 49 text

@stilkov 2. Size matters

Slide 50

Slide 50 text

@stilkov 3. Architecture must match Organization

Slide 51

Slide 51 text

Stefan Tilkov @stilkov  stefan.tilkov@innoq.com  Phone: +49 170 471 2625 innoQ Deutschland GmbH Krischerstr. 100 40789 Monheim am Rhein Germany Phone: +49 2173 3366-0 innoQ Schweiz GmbH Gewerbestr. 11 CH-6330 Cham Switzerland Phone: +41 41 743 0116 www.innoq.com Ohlauer Straße 43 10999 Berlin Germany Phone: +49 2173 3366-0 Ludwigstr. 180E 63067 Offenbach Germany Phone: +49 2173 3366-0 Kreuzstraße 16  80331 München Germany Phone: +49 2173 3366-0 @stilkov That’s all I have.  Thanks for listening!

Slide 52

Slide 52 text

@stilkov www.innoq.com OFFICES Monheim Berlin Offenbach Munich Hamburg Zurich FACTS ~150 employees Privately owned Vendor-independent SERVICES Strategy & technology consulting Digital business models Software architecture & development Digital platforms & infrastructures Knowledge transfer, coaching & trainings CLIENTS Finance Telecommunications Logistics E-commerce Fortune 500 SMBs Startups

Slide 53

Slide 53 text

@stilkov Problems Some People Have Building features takes too long Technical debt is well-known, yet not addressed Deployment is way too complicated and slow Replacement would be way too expensive Scalability has reached its limit Architectural quality has degraded “-ility” problems abound