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/

    View full-size slide

  2. Organisation ->
    Architecture & Development

    View full-size slide

  3. Organization as a Tool
    •Organization is used nowadays to support architecture
    and other goals.
    •Let’s take a look at some examples…

    View full-size slide

  4. Conway’s Law &
    Inverse Conway Maneuver

    View full-size slide

  5. Conway‘s Law
    Architecture
    copies
    communication structures
    of the organization

    View full-size slide

  6. Inverse Conway Maneuver
    •Architecture should drive organization
    •I.e. set up the organization
    •Architecture will follow

    View full-size slide

  7. 🙂 😬 🙁
    Developers, Designers …
    😬
    😬
    🙁
    🙁
    🙂
    🙂
    😬
    🙂
    🙁

    View full-size slide

  8. 🙂 😬 🙁
    Chaos
    😬
    😬
    🙁
    🙁
    🙂
    🙂
    😬
    🙂
    🙁

    View full-size slide

  9. 😐 😐 😐
    Order
    😐
    😐
    😐
    😐
    😐
    😐
    😐
    😐
    😐

    View full-size slide

  10. 😐
    😐😐
    Order
    😐
    😐
    😐
    😐😐
    😐
    😐
    😐
    😐

    View full-size slide

  11. 😐
    😐😐
    Order
    😐
    😐
    😐
    😐😐
    😐
    😐
    😐
    😐
    Modul
    Modul
    Modul

    View full-size slide

  12. 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

    View full-size slide

  13. DevOps: The Problem
    Development Operations

    View full-size slide

  14. DevOps: The Problem
    Development Operations
    What would a
    solution look like?

    View full-size slide

  15. DevOps: The Orignal Plan
    Development Operations

    View full-size slide

  16. DevOps: The Orignal Plan
    Development Operations
    💚

    View full-size slide

  17. DevOps: The Reality I
    Development Operations
    DevOps

    View full-size slide

  18. Development
    DevOps: The Reality II
    Development now does
    operations.
    Operations

    View full-size slide

  19. DevOps: The Reality III
    Development DevOps Engineers
    DevOps
    Engineers
    might also be a
    silo in the
    middle.

    View full-size slide

  20. DevOps
    •Goal: better collaboration
    •“DevOps” clearly communicates collaboration
    •Reality: New roles
    •Reality: Reorgs
    •Surprise: not necessarily better collaboration

    View full-size slide

  21. Team Topologies

    View full-size slide

  22. Team Topologies
    Platform Team
    Stream-aligned Team
    Enabling
    Team
    Complicated-
    subsystem Team
    p. 80

    View full-size slide

  23. Team Topologies: The Problem with Org Chart
    Actual Communication
    Isolated
    p. 6

    View full-size slide

  24. 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.

    View full-size slide

  25. How We Structure People
    Familiar approach
    Give the illusion of control
    But misses central points

    View full-size slide

  26. Org Chart Patterns
    •Meaningful change e.g. in culture is hard
    •Hard to outsource
    •Org chart give the illusion of control and of a solution
    •Probably what people what
    •So probably what some consultancies sell

    View full-size slide

  27. Structuring Software
    Structuring Organizations
    What is Difference????

    View full-size slide

  28. Example: Project A
    Platform Team
    Stream-aligned Team
    Complicated-
    subsystem Team
    Stream-aligned Team
    Stream-aligned Team

    View full-size slide

  29. Example: Project A
    Customer
    Consultancy 1
    Consultancy 2
    Consultancy 3
    💚

    View full-size slide

  30. 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

    View full-size slide

  31. Example: Project B
    Platform Team(s)
    Stream-aligned Team
    Stream-aligned Team
    Stream-aligned Team

    View full-size slide

  32. Example: Project B
    •Shall we introduce platform team(s)?
    •Some common functionalities
    •Might make sense

    View full-size slide

  33. Example: Project B
    •Toxic environment
    •Problems are not communicated.
    •Punishment if problems are communicated
    •Mistrust

    View full-size slide

  34. 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

    View full-size slide

  35. 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.

    View full-size slide

  36. Organizational Issues
    •The real problems are about culture.
    •Those problems are hard to solve.

    View full-size slide

  37. But we can solve technical
    problems!

    View full-size slide

  38. Technical Issues
    •Recall the last project that had significant technical
    issues.
    •Could you name a way that you believe would solve
    these issues?
    •Were the issues solved?
    •Consultants might just point out solutions the
    organization already thought about.

    View full-size slide

  39. Is the challenge to identify
    potential solutions for issues?

    View full-size slide

  40. What Can We Learn From
    Other Industries?

    View full-size slide

  41. https://software-architektur.tv/2023/08/11/folge178.html

    View full-size slide

  42. Aircraft Setup
    •Captain: Most senior pilot
    •First Officer: Second pilot
    •Like pair programming:
    Person on the keyboard + navigator
    •One flies the plane
    •One “controls” / supports / radio
    •Flight engineer
    Steve Jurvetson https://creativecommons.org/licenses/by/2.0/deed.en

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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.

    View full-size slide

  46. United Airlines Flight 173
    •Senior crew
    •Decided to troubleshoot 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

    View full-size slide

  47. Air Crashes: Lessons Learned
    •Quite some crashes where captain mistreated (junior)
    first officer until they won’t speak up.
    •This is sometimes rooted in culture.
    https://en.wikipedia.org/wiki/Korean_Air_Flight_801

    View full-size slide

  48. Air Crashes: Lessons Learned
    •Investing in safer technology only takes you so far.
    •Collaboration matters!

    View full-size slide

  49. Air Crashes: Lessons Learned
    •What is the point?
    Air travel is and has been incredibly safe!
    …but we don’t hear about near-crashes.
    •Metaphors and analogies are always hard.
    •But let me ask a few questions!

    View full-size slide

  50. Air Crashes: Lessons Learned
    •Flights have a clear goal.
    •Procedures, regulations, checklists etc help.
    •But only so much.
    •Software projects have more ambiguous goals.
    •Does collaboration matter even more in software
    projects?

    View full-size slide

  51. Air Crashes: Lessons Learned
    •Air crashes are about your life.
    •Software is usually “only” about money.
    •If air crews fail to collaborate successfully when stakes
    are high, why do we expect software teams to be
    successful?

    View full-size slide

  52. 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.
    •How do we expect software teams with less clear
    roles to successfully mention problems and solve
    them?

    View full-size slide

  53. “Everyone can say whatever
    they like!” is not helpful!

    View full-size slide

  54. Crew Ressource
    Management

    View full-size slide

  55. Crew Resource Management
    •Resources include humans and technical tools.
    •This is about making air travel even safer.
    •They must use every resource to the fullest.
    •This is not about making everyone happy.
    •Software project sometimes seem to confuse happy
    and successful.

    View full-size slide

  56. Crew Resource Management & Architecture
    •Flight is done by a crew.
    •Captain = responsible, most senior person
    •Juniors have less flight hours (only metric).
    •Software is also done in teams.
    •Architect = responsible, most senior person
    •Juniors might have some specialized knowledge.

    View full-size slide

  57. 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?

    View full-size slide

  58. 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.

    View full-size slide

  59. 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 teams in this regard?
    •Where is feedback provided on interactions?
    •Retros?
    •Scrum master?

    View full-size slide

  60. Crew Resource Management & Architecture
    •There are biases and pressure.
    •E.g. plan continuation bias
    •E.g. time pressure
    •Are we aware of them?
    •Are we explicit about them?
    •Do we practice dealing with them?

    View full-size slide

  61. Crew Resource Management & Architecture
    •Investigation never stops at “That person was stupid!”
    •Rather “What made that person behave that way?”
    •Consider Training
    •Consider specific situation
    •What happened before the flight?
    •How do we deal if an individual person seems to fail?

    View full-size slide

  62. Additional tips

    View full-size slide

  63. Who Cares About All of This?
    •Culture should be the responsibility of everyone.
    •Behavior of management is copied – for good or bad.

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  66. Psychological Safety
    •No progress without feedback!
    •Feeling safe is a prerequisite to speak up!
    + empathy
    + communication skills

    View full-size slide

  67. https://software-architektur.tv/2023/06/02/folge167.html

    View full-size slide

  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?”
    •…

    View full-size slide

  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.

    View full-size slide

  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 dicatator

    View full-size slide

  71. Architect:
    Gardener 🧑‍🌾
    not absolute ruler. 🫅

    View full-size slide

  72. 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.

    View full-size slide

  73. https://software-architektur.tv/2023/01/13/folge147.html
    Some example scenarios + solution

    View full-size slide

  74. https://www.socreatory.com/de/trainers/eberhard-wolff

    View full-size slide

  75. 60-Minuten-Consulting
    •Online
    •Inkl. Bericht
    •99€
    https://swaglab.rocks/60-min-consulting/

    View full-size slide

  76. Send email to [email protected]
    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

    View full-size slide