The Evolution of Architecture through Team Topologies

Architecture "just" defines the structure of the software. However, Conway's Law already shows the connection between architecture and organization. Through the Inverse Conway Maneuver, it has become clear that the clever arrangement of the organization of a software development project can significantly influence the architecture. This talk illustrates that team topology also has significant consequences for architectural work: Team Topologies not only functions as a tool for architecture but must also be included in architectural planning.

Transcript

1. The Evolution of Architecture through Team Topologies Eberhard Wolff Head of Architecture https://swaglab.rocks/ https://ewolff.com/
2. Team Topologies is a natural evolution of software architecture.
3. What is Software Architecture?
4. 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?
5. Architecture Reduces Flow of Information •Reducing communication itself might backfire. •How can we reduce the need for communication?
6. The structure of a system should minimize the need for communication!
7. http://cseweb.ucsd.edu/~wgg/CSE218/Parnas-IFIP71-information-distribution.PDF
8. 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.
9. 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
10. 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.”
11. Information Hiding •Not all documentation is good documentation?
12. Public Methods Instance Variables Class Data model can be changed: Bank Account store balance or calculate on-the-fly
13. Interface Database Coarse-grained Module / Microservice Data model can be changed: Bank Account store balance or calculate on-the-fly
14. Interface Data model Module
15. https://software-architektur.tv/2020/11/20/folge026.html
16. 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
17. Domain e.g. order process Team A part of the code
18. https://software-architektur.tv/2020/07/02/folge004.html
19. Conway‘s Law Architecture copies communication structures of the organization
20. 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.
21. What is Team Topologies?
22. 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
23. Team Topologies Stream-aligned team Platform team Enabling team Complicated Subsystem team XaaS Collaboration Facilitating XaaS
24. Team Topologies Order Processing Kubernetes / CI Team Delivery Optimization Invoicing Delivery XaaS Architecture Collaboration Facilitating XaaS
25. https://software-architektur.tv/2024/04/18/folge213.html
26. 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.
27. https://software-architektur.tv/2024/04/18/folge213.html
28. What is the Relation between Software Architecture and Team Topologies?
29. Communication •Team Topologies and Software Architecture both aim at reducing the need for communication with interfaces. •Team Topologies XaaS = software interface or user interface
30. Interface Data model Software Architecture XaaS Team Team Topologies Module
31. Splitting a System •Team Topologies and Software Architecture both split a system into module / teams.
32. Software Architecture Team Topologies Module Stream-aligned team Platform team Enabling team Complicated Subsystem team
33. 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)
34. 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.
35. 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
36. Wanna hate work and burn out? Don’t do continuous delivery!
37. https://software-architektur.tv/2020/08/14/folge012.html
38. Fracture Planes •Teams are split by fracture planes. •Domain •Regulatory Compliance (PCI DSS) •Change Cadence •Team Location •Risk (acquisition vs retention) •Performance Technology
39. 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
40. Fracture Plane Location Order Processing Backend (Kaiserslautern) UI Team (India) Delivery Backend (Hamburg)
41. 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
42. 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
43. So what shall we do differently?
44. Software Architecture and Teams •Traditional software architecture tries to solve communication problems. •How can you achieve that goal with just technical means?
45. 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
46. BUT I CAN’T SET UP TEAMS!
47. 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!
48. 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!
49. 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)
50. Org Chart and Informal Communication •Team Topologies acknowledges informal structures besides the org chart. •We should improve informal structures! •We should use informal structures!
51. W IR S UCH EN M ITG ES TALTER :IN N EN sw a gla b.ro cks/ ka rriere
53. Trink einen virtuellen Kaffee mit mir! https://calendly.com/ eberhard-wolff-swaglab/
54. Send email to bedcon2024@ewolff.com 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