Architecture and Agility: A Shared Skillset!

Agility focuses on managing projects, while software architecture shapes the structure of software. So, how are they connected? Surprisingly, neither discipline is really about projects or structures—it’s about working with people. In this talk, we’ll explore how both agile and architectural success rely on similar core skills.

Transcript

1. Architecture and Agility: A Shared Skillset! Eberhard Wolff Head of Architecture https://swaglab.rocks/ https://ewolff.com/
2. Why this Talk? •Agility = Development model •Software architecture = structures of software •How could they require the same skill? •As an architecture consultant, I think they do.
3. Agile Embrace Change Architecture: Stable Architecture Decisions that are hard to change
4. Architecture What about the people? Architects Agile Coaches Agile Embrace Change Architecture: Stable Decisions that are hard to change
5. Hypothesis 1: Architecture = Implementation of Agility
6. Feedback Reprioritization Agile Feedback Sprint Retros Tests Change Architecture Architecture: Stable Decisions that are hard to change Stable – how?
7. Feedback Reprioritization Agile Feedback Sprint Retros Tests Change Stable – how? Architecture Architecture: Stable Decisions that are hard to change e.g. ADRs Just the most recent changed version!
8. Architecture Decision Record (ADRs) Status Context Decision Consequences Michael Nygard We have several clients who are stabilizing their current systems, … but looking toward a larger rearchitecture in the not-too- distant future. By writing these intentions down, we don't inadvertently make those future changes harder.
9. Agility Architecture Learn about the Domain Requirements change Better architecture skills
10. Why is Architecture Often So Bad? •Hypothesis: Not changing the architecture when we need to is our core problem. •Be prepared to change the architecture. •I.e. embrace change
11. https://speakerdeck.com/ewolff/no-future-proof-architecture
12. What do other engineers do?
13. What Do Other Engineers Do? •Hillel Wayne interviewed “crossovers”. i.e. software engineers that used to be engineers in other fields •All engineering is iterative! •If architecture is engineering, … it should be iterative, too.
14. Porsche 959
15. Porsche 959
16. https://software-architektur.tv/2024/03/27/folge209.html
17. Hypothesis 2: Architecture, Agility Are About People
18. Traditional Architect •Most Experienced Person •For every detail? •For every technology? •Unrealistic •Making all important decisions •Puts enormous pressure on the architect. Architects
19. Most Experienced Person •Quite sad •Use the technical expertise of the team •...and grow the team Architects Team
20. Understanding the System •Architects need to understand the system. •Systems too large for one person. •Use expertise of the team! •Each one will understand some part. Architects Team
21. Traditional Architect •Define the architecture •i.e. make all relevant decisions •Enforce the architecture Architects
22. Decisions •Understand the team’s problems •Seek feedback about possible decision •Communicate decisions Architects Team
23. Decisions •Use expertise of the full team •Results: Better decisions Team actually executes decisions •No ivory tower Architects Team
24. Decisions •Moderate, listen, convince •Don’t enforce •Make your expertise usable •General rule for managing self-organization Architects Team
25. Traditional Architect •Decisions have two levels: •The subject matter •How the decision is made. •When you push through a decision, you will limit the autonomy and buy-in of the team. •Is it worth it? •If it happens frequently: What is wrong with the interaction of architect and team? Architects
26. Agile Coach •Make the team perform. •Create a cross functional team •Different focus •Difference: No subject-matter expert •A natural ally?
27. Hypothesis 3: Architecture Enables Agility’s Autonomy
28. Agile: Autonomy •A team should be able to provide business value by itself. •Cross-functional •Autonomous
29. Technology Can Support Autonomy •Microservices allow independent deployment •…independent technology choices •This might translate in more autonomous teams.
30. Micro- / Macro-Architecture •Delegate decisions •Macro architecture: Binding for all modules •Micro architecture: Potentially different for all modules •Micro architecture can be left to the teams
31. Classic Macro-Architecture •Specific technical decisions •Kubernetes, monitoring, programming language etc •Must be enforced
32. Requirements Approach •List typical technical challenges (e.g. scalability) •List possible solutions (e.g. scale out, scale up) •Including experts for the approaches •More support than control
33. Micro- / Macro-Architecture •More micro-level decisions translates into more autonomy. •Requires trust •…and willingness to take responsibility. •I.e. architecture defines autonomy.
34. Mission Orders / Auftragstaktik •Define a goal •Define a deadline •Provide some means to reach the goal •Let the soldier reach the goal autonomously •If things change: Soldier should act accordingly to the intentions of the leader. •I.e. the leader must communicate their intention!
35. Auftragstaktik & Architecture •Auftragstaktik = Micro / Macro Architecture?
36. Mission ordersl https://software-architektur.tv/2022/11/04/folge141.html
37. Hypothesis 4: The Illusion of Control is a Shared Problem
38. A True Story •Plan at start: Migrate the system module-by-module •Prototype to validate migration. •Prototype quite expensive.
39. A True Story: The Start •Project start •Learn more about the domain •Migration by module makes it impossible …to improve support for business.
40. A True Story: Result •There were other issues, too. •Project cancelled …and considered a failure.
41. Intuitive Lesson Learned •Do more research up front! •Be more restrict in approving projects! •Reason: We think we can control such issues. •Illusion of control •But next time, something else will make the architecture obsolete.
42. Better approach: Iterative Architecture •Let’s build an architecture for the first step! •Let’s see how far it takes us! •Feels scary, right?
43. Agility •Agile vs. complete Specification and planning •Turns out: You can’t plan everything. •Should be obvious after your first project! •Why keep we doing planning instead of iterations? •Illusion of Control?
44. Conclusion
45. Conclusion •Hypothesis 1: Architecture = Implementation of Agility •Hypothesis 2: Architecture, Agility Are About People •Hypothesis 3: Architecture Enables Agility’s Autonomy •Hypothesis 4: The Illusion of Control is a Shared Problem
46. https://www.agile-meets-architecture.com/essays/architecture-and-agility-a-shared-skillset
47. WIR SUCHEN MITGESTALTER:INNEN swaglab.rocks/karriere
48. DRINK A VIRTUAL COFFEE WITH ME! https://calendly.com/eberhard-wolff-swaglab/
49. Download here! Send email to ama2025@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