Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Software Architecture: Improving the Human Factor!

Eberhard Wolff
September 29, 2023

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.

Eberhard Wolff

September 29, 2023
Tweet

More Decks by Eberhard Wolff

Other Decks in Technology

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. 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
  4. DevOps •Goal: better collaboration •“DevOps” clearly communicates collaboration •Reality: New

    roles •Reality: Reorgs •Surprise: not necessarily better collaboration
  5. Team Topologies Order Processing Kubernetes / CI Team Delivery Optimization

    Invoicing Delivery XaaS Architecture Collaboration Facilitating XaaS
  6. 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.
  7. Org Chart Patterns •Org chart give the illusion of control

    and of a solution •Probably what people want •So probably what some consultancies sell
  8. 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
  9. 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
  10. 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.
  11. 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
  12. 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
  13. 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.
  14. 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
  15. 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.
  16. 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?
  17. 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?
  18. 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”.
  19. 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?
  20. 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.
  21. 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?
  22. 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?
  23. Who Cares About All of This? •Culture should be the

    responsibility of everyone. •Behavior of management is copied – for good or bad.
  24. 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
  25. 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
  26. Psychological Safety •No progress without feedback! •Feeling safe is a

    prerequisite to speak up! + empathy + communication skills
  27. 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?” •…
  28. Questions •A way to check your solution. •A way for

    others to provide feedback. •A way for others to share your train of thought.
  29. 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
  30. 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.