Towards Architecture Organization Topologies for Sustainable Fast Flow of Change

ℹ️ Keynote talk of Agile meets Architecture 2023.

Uncertainty and unpredictability are a reality faced by most organizations building software products - they are not optional! However, many modern orgs still apply old controlling operating models and architecture practices to respond to those environments. In this talk, I share several examples of why this is a big problem. In a nutshell, they are not enabling the proper levels of learning, designing, and decision-making in the organization, particularly in the teams/people close to the problems. Then, I share several examples of the organization and architecture evolution of bol.com over more than 20 years. This organization embraces this sort of change and provides a great example of the importance of doing that. I show those by using elements of the thinking models and practices that I call “Architecture Organization Topologies” (https:esilva.net/architecture-topologies) - a way to visualize and have more explicit discussions on how organizations are designed and approach architecture. On those, we can see how successful organizations embrace continuous change and evolution as a function of their internal and external environment, responding and adapting to it to achieve a constant sustainable fast flow of change (or Agility).

Transcript

1. Towards Architecture Organization Topologies for Sustainable Fast Flow of Change Eduardo da Silva, PhD (esilva.net | modernarch.consulting | @emgsilva | eduardo@esilva.net) Agile meets Architecture 2023, 2023/10/05
2. Doing Agile & trying to achieve higher Agility? 2
3. Trying to improve Architecture* for higher Agility? * ability to learn, Design & Decide on “important things” 3
4. Towards Architecture Organization Topologies for Sustainable Fast Flow of Change Eduardo da Silva, PhD (esilva.net | modernarch.consulting | @emgsilva | eduardo@esilva.net) Agile meets Architecture 2023, 2023/10/05
5. Organizations that are not enabling sustainable Learning, designing and decision-making will struggle to respond to their environment 5 Photo by Cole Patrick on Unsplash 5
7. 7 “Learning is a process that leads to change, which occurs as a result of experience and increases the potential for improved performance and future learning” Ambrose et al., 2010
8. 8 ⚠ It is not just about learning, but how to leverage that learning to drive designs & decisions
16. 16 Photo by Simon Berger on Unsplash 16
17. 17 Image & Credits: https://thecynefin.co/about-us/about-cynefin-framework
18. 18 Image & Credits: https://thecynefin.co/about-us/about-cynefin-framework Most modern orgs have a lot of activities here… “Best practices” and expert knowledge is not enough! We need to “probe > sense > respond”
19. 19 Image & Credits: https://thecynefin.co/about-us/about-cynefin-framework ⚠Many organizations are using practices from these domains to work on their “Complex Domains”... ☹ Most modern orgs have a lot of activities here… “Best practices” and expert knowledge is not enough! We need to “probe > sense > respond”
20. 20 Image & Credits: https://thecynefin.co/about-us/about-cynefin-framework Most modern orgs are here… Unpredictable but “all is inter-connected” “Best practices” and expert knowledge is not enough! We need to “probe > sense > respond” ⚠many organizations are using practices from these domains to work on their “Complex Domains”... ⚠classic “controlling operating models” and “Ivory Tower Architects” do not work well on Complex Domains!
21. 21 Inspired by: Reflections: Sociotechnical Systems Design and Organization Change
22. 22 Inspired by: Reflections: Sociotechnical Systems Design and Organization Change
23. 23 stretching our teams/org & creating complex processes => increasingly messier social and technical systems (⚠Conway’s Law) Inspired by: Reflections: Sociotechnical Systems Design and Organization Change
24. 24 Inspired by: Reflections: Sociotechnical Systems Design and Organization Change
25. 25 Inspired by: Reflections: Sociotechnical Systems Design and Organization Change
26. 26 Photo by Quino Al on Unsplash Outcome: continuously “fight” against the environment (external & internal)...
27. 🏭🤖 These mechanistic org structures & Controlling Operating models limit the dynamics & agility that modern orgs need (& create lot of waste!) 27 Photo by Cole Patrick on Unsplash 27
28. 28 Inspired by: Reflections: Sociotechnical Systems Design and Organization Change
29. 29 💡Creating org cultures, structures and incentives that embrace the nature of the environments we “live in…” Photo by Ronaldo de Oliveira on Unsplash 29
30. 30 🔬Learning: minimal and made in isolation 📝Designing: outside teams (by Architects and controlled Managers) 🤝Decision-making: outside teams (by Architects and Managers (“boss”)) 🔬Learning: maximized across the org (no silos) 📝Designing: in teams & with teams involvement 🤝Decision-making: by teams close to problems
31. 31 🔬Learning: minimal and made in isolation 📝Designing: outside teams (by Architects and controlled Managers) 🤝Decision-making: outside teams (by Architects and Managers (“boss”)) 🔬Learning: maximized across the org (no silos) 📝Designing: in teams & with teams involvement 🤝Decision-making: by teams close to problems How can we start doing that?
32. TL;DR: approaches to architecture in teams & organization will take different forms & change in time (to allow for sustainable flow of change in the org). Embracing that is key to understand and improve them more explicitly. 32 Architecture Topologies & Architecture as Enabling Team, Eduardo da Silva
34. Architecture Organization Topologies, Eduardo da Silva 34
35. Architecture Organization Topologies (AOTs) 🔗 esilva.net/architecture-topologies 35
36. 36 bol.com 1999 - 2019
37. 37 Tech Arch Org (& Way of Work) Prod Tech Org (& Way of Work) bol.com 1999 - 2019 (Org + Tech + Architecture evolution) Arch.
38. 38 Tech Arch Org (& Way of Work) Prod Monoliths Tech Org (& Way of Work) Waterfall Phase 1 (1999 - ~2010): Starting, waterfall & monoliths Arch. Centralized (by Architects)
39. 39 Tech Arch Org (& Way of Work) Prod Monoliths Tech Org (& Way of Work) Waterfall Phase 1 (1999 - ~2010): Starting, waterfall & monoliths Arch. Centralized (by Architects) ⚠ “need for scaling”
40. 40 Architects doing all the design & decision making
41. 41 Tech Arch Org (& Way of Work) Prod Monoliths Tech Org (& Way of Work) Waterfall Agile DevOps Teams (Micro)services ~30 ~10 Phase 2 (~2010 - ~2018): Autonomous Teams Arch. Centralized (by Architects) Teams + Archs “need for scaling”
42. 42 Architecture in team (mostly) by the team; architects doing everything around teams
43. 43 Tech Arch Org (& Way of Work) Prod Monoliths Tech Org (& Way of Work) Waterfall Agile DevOps Teams (Micro)services ~30 ~10 Phase 2 (~2010 - ~2018): Autonomous Teams Arch. Centralized (by Architects) Teams + Archs “need for scaling”
44. 44 Tech Arch Org (& Way of Work) Prod Monoliths Tech Org (& Way of Work) Waterfall Agile DevOps Teams (Micro)services ~30 ~10 Phase 2 (~2010 - ~2018): Autonomous Teams Arch. Centralized (by Architects) Teams + Archs “need for scaling” Teams capable of iterating quickly on their scope
45. 45 Tech Arch Org (& Way of Work) Prod Monoliths Tech Org (& Way of Work) Waterfall Agile DevOps Teams (Micro)services ~30 ~10 Phase 2 (~2010 - ~2018): Autonomous Teams Arch. Centralized (by Architects) Teams + Archs “need for scaling” Teams capable of iterating quickly on their scope Able to deploy quickly and independently
46. 46 Tech Arch Org (& Way of Work) Prod Monoliths Tech Org (& Way of Work) Waterfall Agile DevOps Teams (Micro)services ~30 ~10 Phase 2 (~2010 - ~2018): Autonomous Teams Arch. Centralized (by Architects) Teams + Archs “need for scaling” Teams capable of iterating quickly on their scope Able to deploy quickly and independently Teams able to design and decide things on their scope
47. 47 Tech Arch Org (& Way of Work) Prod Monoliths Tech Org (& Way of Work) Waterfall Agile DevOps Teams (Micro)services ~30 ~10 Phase 2 (~2010 - ~2018): Autonomous Teams Arch. Centralized (by Architects) Teams + Archs “need for scaling” Many teams Prod & Tech Silos
48. 48 Tech Arch Org (& Way of Work) Prod Monoliths Tech Org (& Way of Work) Waterfall Agile DevOps Teams (Micro)services ~30 ~10 Phase 2 (~2010 - ~2018): Autonomous Teams Arch. Centralized (by Architects) Teams + Archs “need for scaling” Many teams Prod & Tech Silos Organic net of Microservices
49. 49 Tech Arch Org (& Way of Work) Prod Monoliths Tech Org (& Way of Work) Waterfall Agile DevOps Teams (Micro)services ~30 ~10 Phase 2 (~2010 - ~2018): Autonomous Teams Arch. Centralized (by Architects) Teams + Archs “need for scaling” Many teams Prod & Tech Silos Organic net of Microservices Architects “keeping things together around teams”
50. 50 Tech Arch Org (& Way of Work) Prod Monoliths Tech Org (& Way of Work) Waterfall Agile DevOps Teams (Micro)services ~30 ~100 ~10 ~600 Phase 2 (~2010 - ~2018): Autonomous Teams Arch. Centralized (by Architects) Teams + Architects (anything around teams) ⚠ ⚠ ⚠ ⚠ “need for sustainable fast flow of change”
51. 51 Architects managing a lot of the “dot-connecting” of multi-team activities and tems being “islands”
52. • Team scope has all disciplines needed (including “product” and “tech”) • Product scope groups teams working on related value streams Re-adjusting Organization Structure 52 Product Taxonomy, Ross Clanton, Amy Walters, Jason Zubrick, Pat Birkeland, Mik Kersten, Alan Nance, and Anders Wallgren
53. • “Product Leadership” team (e.g., Engineering Manager + Product Manager + Tech Lead) works as an Enabling Team 53 Product Taxonomy, Ross Clanton, Amy Walters, Jason Zubrick, Pat Birkeland, Mik Kersten, Alan Nance, and Anders Wallgren Multi-team Leadership Enabling team
54. 54 Teams owning architecture on their scope with clearer alignment to the multi-team scope (with Enabling Architects)
55. 55 Tech Arch Org (& Way of Work) Prod Monoliths Products Tech Org (& Way of Work) Waterfall Agile Product Teams DevOps Teams (Micro)services ~30 ~100 ~10 ~600 ~50 Phase 3 (~2017 - ??): Product organization Arch. Centralized (by Architects) Teams + Architects (anything around teams) Teams (+ Enabling Product Architects) “need for sustainable fast flow of change”
56. Products Waterfall Agile Product Teams DevOps Teams ~30 ~100 bol.com 1999 - 2019 “need for scaling” “sustainable fast flow of change” 56
57. 57 ⚠ Change & Uncertainty will not stop ✅ Embrace it, and thinking models and practices that help you notice it, learn & decide how to navigate it Photo by Ronaldo de Oliveira on Unsplash 57
58. Thank you! Eduardo da Silva, PhD Independent consultant - Sustainable Fast Flow of Change Team Topologies Valued Practitioner (TTVP) # @emgsilva | esilva.net | modernarch.consulting | eduardo@esilva.net 💡stay tuned for “companion article” 58 esilva.net consulting