Software Architecture:
Improving the Human Factor
Eberhard Wolff
Head of Architecture
https://swaglab.rocks/
https://ewolff.com/
Slide 2
Slide 2 text
Organization as a Tool
•Organization is used nowadays to support architecture
and other goals.
•Let’s take a look at some examples…
Slide 3
Slide 3 text
Conway’s Law &
Inverse Conway Maneuver
Slide 4
Slide 4 text
Conway‘s Law
Architecture
copies
communication structures
of the organization
Slide 5
Slide 5 text
Inverse Conway Maneuver
•Architecture should drive organization
•I.e. set up the organization
•Architecture will follow
Slide 6
Slide 6 text
Developers, Designers …
Slide 7
Slide 7 text
Chaos
Slide 8
Slide 8 text
Order
Slide 9
Slide 9 text
Order
Order Process
Delivery
Invoicing
Slide 10
Slide 10 text
Order
Order Process
Delivery
Invoicing
Modul
Modul
Modul
Slide 11
Slide 11 text
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
Slide 12
Slide 12 text
Inverse Conway: Simplification
•Inverse Conway assumes only functionality matters.
•What about e.g. location?
Slide 13
Slide 13 text
DevOps
Slide 14
Slide 14 text
DevOps: The Problem
Development Operations
Slide 15
Slide 15 text
DevOps: The Problem
Development Operations
What would a
solution look like?
Slide 16
Slide 16 text
DevOps: The Orignal Plan
Development Operations
Slide 17
Slide 17 text
DevOps: The Orignal Plan
Development Operations
?
Slide 18
Slide 18 text
DevOps: The Reality I
Development Operations
DevOps
Slide 19
Slide 19 text
Development
DevOps: The Reality II
Development now does
operations.
Operations
Slide 20
Slide 20 text
DevOps: The Reality III
Development DevOps Engineers
DevOps
Engineers
might also be a
silo in the
middle.
Slide 21
Slide 21 text
DevOps
•Goal: better collaboration
•“DevOps” clearly communicates collaboration
•Reality: New roles
•Reality: Reorgs
•Surprise: not necessarily better collaboration
Slide 22
Slide 22 text
Team Topologies
Slide 23
Slide 23 text
Team Topologies
Stream-aligned team
Platform team
Enabling team
Complicated
Subsystem
team
XaaS
Collaboration
Facilitating
XaaS
Slide 24
Slide 24 text
Team Topologies
Order Processing
Kubernetes / CI Team
Delivery
Optimization
Invoicing
Delivery
XaaS
Architecture
Collaboration
Facilitating
XaaS
Slide 25
Slide 25 text
Team Topologies: The Problem with Org Chart
Actual Communication
Isolated
p. 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.
Slide 30
Slide 30 text
How We Structure People
Familiar approach
Give the illusion of control
But misses central points
Slide 31
Slide 31 text
Org Chart Patterns
•Org chart give the illusion of control and of a solution
•Probably what people want
•So probably what some consultancies sell
Slide 32
Slide 32 text
Structuring Software
Structuring Organizations
What is Difference????
Slide 33
Slide 33 text
Example: Project A
Stream-aligned team
Complicated
Subsystem
team
Stream-aligned team
Stream-aligned team
Platform team
Slide 34
Slide 34 text
Example: Project A
Customer
Consultancy 1
Consultancy 2
Consultancy 3
Slide 35
Slide 35 text
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
Slide 36
Slide 36 text
Example: Project B
Stream-aligned team
Stream-aligned team
Stream-aligned team
Platform team
Slide 37
Slide 37 text
Example: Project B
•Shall we introduce platform team(s)?
•Some common functionalities
•Might make sense
Slide 38
Slide 38 text
Example: Project B
•Toxic environment
•Problems are not communicated.
•Punishment if problems are communicated
•Mistrust
Slide 39
Slide 39 text
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
Slide 40
Slide 40 text
What Now?
Slide 41
Slide 41 text
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.
Slide 42
Slide 42 text
Organizational Issues
•The real problems are about culture.
•Those problems are hard to solve.
•Really?
Slide 43
Slide 43 text
What Can We Learn From
Other Industries?
Slide 44
Slide 44 text
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
Slide 45
Slide 45 text
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
Slide 46
Slide 46 text
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.
Slide 47
Slide 47 text
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
Slide 48
Slide 48 text
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.
Slide 49
Slide 49 text
Air Crashes: Lessons Learned
•Metaphors and analogies are always hard.
•But let me ask a few questions!
Slide 50
Slide 50 text
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?
Slide 51
Slide 51 text
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?
Slide 52
Slide 52 text
“Everyone can say whatever
they like!” is not enough!
Slide 53
Slide 53 text
Is there any way to
systematically improve
feedback?
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”.
Slide 56
Slide 56 text
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?
Slide 57
Slide 57 text
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.
Slide 58
Slide 58 text
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?
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?
Who Cares About All of This?
•Culture should be the responsibility of everyone.
•Behavior of management is copied – for good or bad.
Slide 65
Slide 65 text
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
Slide 66
Slide 66 text
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
Slide 67
Slide 67 text
Psychological Safety
•No progress without feedback!
•Feeling safe is a prerequisite to speak up!
+ empathy
+ communication skills
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?”
•…
Slide 70
Slide 70 text
Questions
•A way to check your solution.
•A way for others to provide feedback.
•A way for others to share your train of thought.
Slide 71
Slide 71 text
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
Slide 72
Slide 72 text
Architect:
Gardener
Not absolute ruler.
Slide 73
Slide 73 text
Conclusion
Slide 74
Slide 74 text
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.
Slide 75
Slide 75 text
https://software-architektur.tv/2023/01/13/folge147.html
Some example scenarios + solution