Software Architecture: Improving the Human Factor!

Good software architecture organizes complex software systems so that humans with their limited mental capacity can understand and evolve them. Therefore, the human factor is at the core of software architecture. However, architecture cannot solely focus on structuring the software; it must also address the human aspects. This presentation explores specific approaches and experiences aimed at the human factor and thereby improving software development further.

Transcript

1. Software Architecture: Improving the Human Factor Eberhard Wolff Head of Architecture https://swaglab.rocks/ https://ewolff.com/
2. Organization as a Tool •Organization is used nowadays to support architecture and other goals. •Let’s take a look at some examples…
3. Conway’s Law & Inverse Conway Maneuver
4. Conway‘s Law Architecture copies communication structures of the organization
5. Inverse Conway Maneuver •Architecture should drive organization •I.e. set up the organization •Architecture will follow
6. Developers, Designers …
7. Chaos
8. Order
9. Order Order Process Delivery Invoicing
10. Order Order Process Delivery Invoicing Modul Modul Modul
11. Inverse Conway: Simplification •Inverse Conway changes the org chart •Org chart is not communication! •Assumption: Org chart team will collaborate on module & communicate more internally •Reorg might be ignored •Communication depends i.e. on physical distance
12. Inverse Conway: Simplification •Inverse Conway assumes only functionality matters. •What about e.g. location?
13. DevOps
14. DevOps: The Problem Development Operations
15. DevOps: The Problem Development Operations What would a solution look like?
16. DevOps: The Orignal Plan Development Operations
17. DevOps: The Orignal Plan Development Operations ?
18. DevOps: The Reality I Development Operations DevOps
19. Development DevOps: The Reality II Development now does operations. Operations
20. DevOps: The Reality III Development DevOps Engineers DevOps Engineers might also be a silo in the middle.
21. DevOps •Goal: better collaboration •“DevOps” clearly communicates collaboration •Reality: New roles •Reality: Reorgs •Surprise: not necessarily better collaboration
22. Team Topologies
23. Team Topologies Platform Team Stream-aligned Team Enabling Team Complicated- subsystem Team p. 80
24. Team Topologies: The Problem with Org Chart Actual Communication Isolated p. 6
25. https://software-architektur.tv/2024/04/18/folge213.html
26. Team Topologies Heute 13:30-13:45 SWAGLab-Stand https://software-architektur.tv/2024/04/18/folge213.html
27. The Problem
28. How We Structure Software Diagrams often lie Then they are no useful abstraction over code But we can organize code as the diagram shows. Then the diagrams are useful.
29. How We Structure People Familiar approach Give the illusion of control But misses central points
30. Org Chart Patterns •Org chart give the illusion of control and of a solution •Probably what people want •So probably what some consultancies sell
31. Structuring Software Structuring Organizations What is Difference????
32. Example: Project A Platform Team Stream-aligned Team Complicated- subsystem Team Stream-aligned Team Stream-aligned Team
33. Example: Project A Customer Consultancy 1 Consultancy 2 Consultancy 3
34. How I Felt about Project A •Projects often consist of many small kingdoms. •Germany 1870 •> 30 nations •Some really small •Little alignment Ziegelbrenner https://creativecommons.org/licenses/by-sa/3.0
35. Example: Project B Platform Team(s) Stream-aligned Team Stream-aligned Team Stream-aligned Team
36. Example: Project B •Shall we introduce platform team(s)? •Some common functionalities •Might make sense
37. Example: Project B •Toxic environment •Problems are not communicated. •Punishment if problems are communicated •Mistrust
38. Example: Project B •Can’t trust the platform team •Platform team won’t make problems transparent •So: Stream-aligned team might not reach goals •But stream-aligned team will be blamed •So: Rather build platform yourself
39. What Now?
40. Artefacts? •Software diagrams, org diagrams, code are considered important. •But in reality, culture and social relations are important. •Designing just an org chart tells a lot about the project and people.
41. Organizational Issues •The real problems are about culture. •Those problems are hard to solve. •Really?
42. What Can We Learn From Other Industries?
43. Tenerife Aircraft Crash •Deadliest aircraft disaster •Two Jumbo Boeing 747 collided on the ground •Extremely senior crews •Including a KLM “rockstar” •583 dead, 61 survivors https://creativecommons.org/publicdomain/zero/1.0/deed.en
44. Tenerife Aircraft Crash • Crashes have many reasons. • Fog • No ground radar • Airport closed -> diversion of flights • Problems in communication • Taxing on runway • But: KLM pilot took off without clearance …and the rest of the crew did not intervene https://en.wikipedia.org/wiki/Tenerife_airport_disaster https://creativecommons.org/publicdomain/zero/1.0/deed.en
45. United Airlines Flight 173 •Control lights indicated: Landing gear doesn’t work •No landing gear isn’t fatal but unpleasant. •Actually, landing gear was down.
46. United Airlines Flight 173 •Senior crew •Troubleshooted the problem •Holding pattern for about 60 minutes •Ran out of fuel, plane crashed in the woods •10 dead (2 crew) https://en.wikipedia.org/wiki/United_Airlines_Flight_1 73
47. Air Crashes: Lessons Learned •Collaboration matters! •Even if the goal is very clear: i.e. arrive at destination safely. •How much more if the goal is to satisfy stakeholders …who learn about the domain themselves.
48. Air Crashes: Lessons Learned •Metaphors and analogies are always hard. •But let me ask a few questions!
49. Air Crashes: Lessons Learned •Air crashes are about your life. •Software is usually “only” about money. •Air crews fail to collaborate when it’s about their life. •Why do we expect software teams to collaborate successfully?
50. Air Crashes: Lessons Learned •Crews make seemingly trivial mistakes. •Crew members do not intervene. •Even though it is their job. •Even though the lives of the crew are on the line. •Software teams have not so clear roles. •Why should they successfully mention problems and solve them?
51. “Everyone can say whatever they like!” is not enough!
52. Is there any way to systematically improve feedback?
53. https://software-architektur.tv/2023/08/11/folge178.html
54. Crew Resource Management •Use every resource to the fullest! •Resources: humans and technical tools. •This is about making air travel even safer. •This is not about making everyone happy. •Don’t confuse “happy” and “successful”.
55. Crew Resource Management & Architecture •Use the expertise of the full crew! •The only thing the captains decides by themselves is to abort a take-off. •Who should we involve in decisions? •How are e.g. juniors involved?
56. Crew Resource Management & Architecture •Enable communication! •Treat (junior) people so that they speak up. •Smile, be gentle etc •Because you want to fully utilize them! •Do we even care in software projects? •Sometimes aggressive communication is rewarded.
57. Crew Resource Management & Architecture •CRM is part of the pilot training •…and part of exercises in the simulator. •I.e. feedback on the interactions of the crew. •How do we train software teams? •Where is feedback provided on interactions? •Retros? •Scrum master?
58. https://software-architektur.tv/2023/08/04/folge177.html
59. Crew Resource Management & Architecture •Investigation never stops at “That person was stupid!” •Rather “What made that person behave that way?” •Consider Training •Consider situation •What happened before the flight? •How do we deal if an individual seems to fail?
60. https://software-architektur.tv/2022/11/04/folge141.html
61. https://software-architektur.tv/2023/10/27/folge187.html
62. Additional tips
63. Who Cares About All of This? •Culture should be the responsibility of everyone. •Behavior of management is copied – for good or bad.
64. Star Trek Next Generation •Individual guidance and advice to crew members •Provide advice to the ship's captain on command decisions •Periodic crew performance evaluations •Can relieve other officers and crewmembers of duty Counselor Deanna Troi
65. Star Trek Next Generation • Alien •Several hundred years old •Noted for her warmth and folk wisdom •Often defuses difficult situations •Comfort others as they struggle with something Guinan
66. Psychological Safety •No progress without feedback! •Feeling safe is a prerequisite to speak up! + empathy + communication skills
67. https://software-architektur.tv/2023/06/02/folge167.html
68. Questions •Instead of proposing a solution ask questions. •Solution: “We need to separate the system in microservices!” •“How often are teams blocked by other teams?” •“Why are they blocked?” •“Can’t we speed up the continuous delivery pipeline?” •…
69. Questions •A way to check your solution. •A way for others to provide feedback. •A way for others to share your train of thought.
70. More Relaxed •I personally wouldn’t use SPA frameworks. •But: important was the composition of the UI. •That was possible. •So let them use their SPA framework. •Gardener not dictator
71. Architect: Gardener Not absolute ruler.
72. Conclusion
73. Conclusion •We love to work with org charts •The real problems are different: humans •Other industries systematically work on the human side. •So should we.
74. https://software-architektur.tv/2023/01/13/folge147.html Some example scenarios + solution
76. Team Topologies Heute 13:30-13:45 SWAGLab-Stand https://software-architektur.tv/2024/04/18/folge213.html
77. Send email to jax2024@ewolff.com Slides + Service Mesh Primer EN + Microservices Primer DE / EN + Microservices Recipes DE / EN + 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