The Evolution of Architecture through Team Topologies

Slide 1

Slide 1 text

The Evolution of Architecture through Team Topologies Eberhard Wolff Head of Architecture https://swaglab.rocks/ https://ewolff.com/

Slide 2

Slide 2 text

Team Topologies is a natural evolution of software architecture.

Slide 3

Slide 3 text

What is Software Architecture?

Slide 4

Slide 4 text

Communication: Good or Bad? •Communication: foundation of successful projects •But: communication can also hinder progress and takes up time. •Projects should communicate as much as necessary. •Written documentation: lots of effort •EMails instead of meetings? •JIRA tickets instead of direct communication – really?

Slide 5

Slide 5 text

Architecture Reduces Flow of Information •Reducing communication itself might backfire. •How can we reduce the need for communication?

Slide 6

Slide 6 text

The structure of a system should minimize the need for communication!

Slide 7

Slide 7 text

http://cseweb.ucsd.edu/~wgg/CSE218/Parnas-IFIP71-information-distribution.PDF

Slide 8

Slide 8 text

Information Distribution Aspects •Modules can be changed freely •…if they still meet expectations from other modules. •Other modules will use all information about a module.

Slide 9

Slide 9 text

Information Distribution Aspects •Information hiding: Hide as much information as possible •Less information leaks to other modules •Result: Modules easier to change •Still valid, fundamental concept

Slide 10

Slide 10 text

Information Hiding •“We decided that all programmers should see all the material.” •“Each programmer having a copy of the project workbook, which came to number over 10,000 pages.” •(Including interior of modules.) •"I dismissed Parnas's concept as a ‘recipe for disaster’.” •“Parnas was right, and I was wrong.”

Slide 11

Slide 11 text

Information Hiding •Not all documentation is good documentation?

Slide 12

Slide 12 text

Public Methods Instance Variables Class Data model can be changed: Bank Account store balance or calculate on-the-fly

Slide 13

Slide 13 text

Interface Database Coarse-grained Module / Microservice Data model can be changed: Bank Account store balance or calculate on-the-fly

Slide 14

Slide 14 text

Interface Data model Module

Slide 15

Slide 15 text

https://software-architektur.tv/2020/11/20/folge026.html

Slide 16

Slide 16 text

Domain Architecture •A good domain architecture facilitates changes to the business logic. •Business logic and features are the primary value of the software to customers. •Naïve Optimum: 1 Team = 1 Domain = 1 Part of the Code

Slide 17

Slide 17 text

Domain e.g. order process Team A part of the code

Slide 18

Slide 18 text

https://software-architektur.tv/2020/07/02/folge004.html

Slide 19

Slide 19 text

Conway‘s Law Architecture copies communication structures of the organization

Slide 20

Slide 20 text

Domain e.g. order process Team A part of the code Inverse Conway Setup the team Assign a domain to the team Congrats! They will build a module in the code.

Slide 21

Slide 21 text

What is Team Topologies?

Slide 22

Slide 22 text

Why Team Topologies? •Somehow teams need to collaborate •Not too complex •Intuitive (?) •Covers more “fracture planes” then just domains e.g. location •Covers more team types than development teams

Slide 23

Slide 23 text

Team Topologies Stream-aligned team Platform team Enabling team Complicated Subsystem team XaaS Collaboration Facilitating XaaS

Slide 24

Slide 24 text

Team Topologies Order Processing Kubernetes / CI Team Delivery Optimization Invoicing Delivery XaaS Architecture Collaboration Facilitating XaaS

Slide 25

Slide 25 text

https://software-architektur.tv/2024/04/18/folge213.html

Slide 26

Slide 26 text

A Word of Warning… •Team Topologies defines “magnets”. •I.e. the teams should evolve towards these roles. •How many organization actually implement Team Topologies fully and by the book? •Team Topologies acknowledges that informal communication exists besides organigrams.

Slide 27

Slide 27 text

https://software-architektur.tv/2024/04/18/folge213.html

Slide 28

Slide 28 text

What is the Relation between Software Architecture and Team Topologies?

Slide 29

Slide 29 text

Communication •Team Topologies and Software Architecture both aim at reducing the need for communication with interfaces. •Team Topologies XaaS = software interface or user interface

Slide 30

Slide 30 text

Interface Data model Software Architecture XaaS Team Team Topologies Module

Slide 31

Slide 31 text

Splitting a System •Team Topologies and Software Architecture both split a system into module / teams.

Slide 32

Slide 32 text

Software Architecture Team Topologies Module Stream-aligned team Platform team Enabling team Complicated Subsystem team

Slide 33

Slide 33 text

Splitting a System •Architecture: Focus usually on domains. •Team Topologies teams imply modules with different functionality. •Complicated subsystem •Platform •Enabling (might just provide support, no module)

Slide 34

Slide 34 text

Streams? •Team Topologies focuses on stream-aligned teams. •A complete stream from requirements to production. •This is the whole point of stream-aligned teams. •I.e. you should not compromise in this regard.

Slide 35

Slide 35 text

Why Focus on these Streams? •Feedback from users •Benefit: Product / market fit •Feedback from tests, production, staging •Benefit: Better productivity •Benefit: Less Burnout •The preferred way of working

Slide 36

Slide 36 text

Wanna hate work and burn out? Don’t do continuous delivery!

Slide 37

Slide 37 text

https://software-architektur.tv/2020/08/14/folge012.html

Slide 38

Slide 38 text

Fracture Planes •Teams are split by fracture planes. •Domain •Regulatory Compliance (PCI DSS) •Change Cadence •Team Location •Risk (acquisition vs retention) •Performance Technology

Slide 39

Slide 39 text

Domain e.g. order process Team A part of the code Software Architecture Team Topologies Fracture plane e.g. Location Team Shared responsibility for code / domain acceptable

Slide 40

Slide 40 text

Fracture Plane Location Order Processing Backend (Kaiserslautern) UI Team (India) Delivery Backend (Hamburg)

Slide 41

Slide 41 text

Fracture Planes •Always splitting teams by domain is impossible. •So is always splitting modules by domain (Conway) •So a team with a UI module might make sense. •Architecture splits also by layers / hexagonal architecture •But usually not on the team-level

Slide 42

Slide 42 text

Cognitive Load •Responsibility for a complete stream is complex. •Too much “cognitive load” •Other teams reduce the cognitive load. •I.e. support not control •I.e. no architecture police but an enabling team

Slide 43

Slide 43 text

So what shall we do differently?

Slide 44

Slide 44 text

Software Architecture and Teams •Traditional software architecture tries to solve communication problems. •How can you achieve that goal with just technical means?

Slide 45

Slide 45 text

Software Development = Sociotechnical •Teams = social •Modules = technical •Must consider both •Interface = communication (social) + module interaction (technical) •Information hiding: Just one way to reduce cognitive load

Slide 46

Slide 46 text

BUT I CAN’T SET UP TEAMS!

Slide 47

Slide 47 text

It is your duty to provide feedback! But you can decide about technologies? Architecture? Sure! But I can’t set up teams! No discussion with other developers? Architects? … It’s all collaborative decisions!

Slide 48

Slide 48 text

Team Setup •Team Setup is a joint effort: developers, management, architects… •So “1 domain = 1 team” is probably impossible. •Too many other factors to keep in mind. •But you do have influence!

Slide 49

Slide 49 text

Fundamental Value •What is not negotiable? •Support the stream of changes – many benefits! •Support the teams that actually do the changes! •Lower their cognitive load! •Not: Every team must have a direct business impact! •Not: Split teams by domain! (Inverse Conway Maneuver)

Slide 50

Slide 50 text

Org Chart and Informal Communication •Team Topologies acknowledges informal structures besides the org chart. •We should improve informal structures! •We should use informal structures!

Slide 51

Slide 51 text

W IR S UCH EN M ITG ES TALTER :IN N EN sw a gla b.ro cks/ ka rriere

Slide 52

Slide 52 text

No content

Slide 53

Slide 53 text

Trink einen virtuellen Kaffee mit mir! https://calendly.com/ eberhard-wolff-swaglab/

Slide 54

Slide 54 text

Send email to [email protected] Slides + Sample Microservices Book DE / EN + Sample Practical Microservices DE/EN + Sample of Continuous Delivery Book DE Powered by Amazon Lambda & Microservices EMail address logged for 14 days, wrong addressed emails handled manually