Sociotechnical Architecture Reviews: Understanding Teams, not just Artefacts

At first glance, software architecture appears to be a purely technical artefact. So it should be possible to review it solely as such—or should it? In reality, an architecture is the outcome of a team’s work and a response to stakeholder requirements. It therefore makes much more sense to review architecture as the product of a sociotechnical system.
This perspective shifts the emphasis from technical artefacts to the people behind them, their goals, and their interactions. Experience has shown that this approach provides a more efficient and effective way to understand architectures than many traditional review methods.
Attendees will see how sociotechnical reviews work in practice and leave with practical techniques to improve the effectiveness of their own reviews.

Transcript

1. Sociotechnical Architecture Reviews: Understanding Teams, not just Artefacts Eberhard Wolff Head of Architecture https://swaglab.rocks/ https://ewolff.com/
2. Why Reviews? • Manage a risk • New ideas from a different viewpoint • Sometimes mistrust
3. How I Did Reviews ~15 Years Ago
4. Metrics • Cyclomatic complexity: Number of execution path • Dependencies between classes, methods, variables … • Size of classes, methods, …
5. Goal • Goal: Not too many Not too big parts Not too many dependencies No dependency circles • Parts: Classes, packages, microservices, …
6. Findings • Usually far too many dependencies, too large parts, dependency circles • “Big Ball of Mud” (unstructured system)
7. Eliminate a Circle: Move a Class Package Class Rest of Package Package Package Package Should be separated Are really one The ultimate problem But changes to one influence the other
8. Package Eliminate a Circle: Move a Class Package Class Rest of Package Package Move Class “Up” Package Class Rest of Package
9. Doubts: Metrics vs Impact • Moving one class solves a circular dependency … improves metrics significantly … how is it relevant?
10. Doubts: Metrics vs Reality • Maybe developers can handle the system as is. • Maybe some parts are not that bad after all.
11. Doubts: Metrics vs. Domain • The structure should reflect the domain. • What is the minimal complexity to model the domain? • So: metrics might be fine but still: system is much too complex.
12. Doubts: Priorities? • Not all parts will ever be perfect. • Which need to be improved?
13. Doubts: Why Bad Metrics? • Isn’t the problem obvious? • How useful is the review then? • Why does the team live with it? • Maybe they even like the complexity?
14. Software = Socio -technical System
15. Valuable Insights? • It is easily to see how messed up a system is. • Most legacy systems are. • How is that a valuable insight?
16. What Good are Ignored Insights? https://chatgpt.com/share/69947b41 -9efc-800f-823b-81e7700dfabc
17. Experts • People working on a system are the experts for it! • Listen to their expertise!
18. If Lost: Ask for Directions! https://chatgpt.com/share/69947b41 -9efc-800f-823b-81e7700dfabc
19. Ask Experts for Directions! https://chatgpt.com/share/69947b41 -9efc-800f-823b-81e7700dfabc
20. But Can You Trust the Experts? • These review are no instrument of control • Not useful e.g. for mergers & acquisitions • Usually all want the software to be successful …so potential improvements are welcome.
21. Focus on Social Issues! • Technologies/architecture don’t make projects fail. • If organization works: Technical problems can usually be solved. • So: Figure out organizational problems from a software architecture • How?
22. Socio -technical Architecture Reviews
23. Socio -technical Architecture Review
24. Proposal • Start: Often virtual coffee • Free video call • Understand goal • Explain approach • Identify experts for interviews
25. Socio -technical Architecture Review Kick Off
26. Kick Off • At least all interviewees • Explain goal of review • Explain review approach • Often already quite interesting insights. • E.g. redefine goals
27. Socio -technical Architecture Review Kick Off Interviews
28. Ask Experts for Direction! • Interview experts Developers, stakeholders, key players
29. Ask the Experts for Directions! https://chatgpt.com/share/69947b41 -9efc-800f-823b-81e7700dfabc
30. Ask Experts for Direction! • Open questions Main strength? Main challenges? … • Take the conversation from there!
31. Who Can Do Such Reviews?
32. Seniors • No strict interview checklist • Spot problem during an interview • Understand the problem • Prioritize …and on to the next problem.
33. Why is This Hard? • “We are now doing microservices.” • “We had our first incident in production.” • “Was hard to analyze.” • Interviews needs to understand what this actually means. • Observability: typical problem with microservices. • Should they solve the problem NOW? • Otherwise full scale prod will be a nightmare. • Does this fit with other interviews? • So: A broad and deep knowledge of architecture is needed.
34. Why is This Hard? • “They pushed that decision on us.” • This is just one sentence. • But it might point to some social issues. • Or excuse for not participating in the decision?
35. Who Can Do Such a Review? • Can take a step back • Tone themselves down • Listen • Thankful if problems are actually mentioned
36. Communication is like an Iceberg https://chatgpt.com/share/69947b41 -9efc-800f-823b-81e7700dfabc
37. External • Internal people are part of the social system. • Internal people can’t provide a fresh point of view.
38. Easier Alternative • Tick off a list • Take a set of predefined metrics • Might provide a benchmark • Probably takes more time • Might “work” in controlling / mistrusting environments. • Not sure how that is helpful?
39. Environment • Separate 1:1 interviews • At least two interviewers to take notes etc • Generates a trusting environment • Makes sure everyone is heard. • Makes sure extroverts won’t dominate the review.
40. Video Call • More flexible concerning time and location • Possible to get to a trustful environment.
41. As the Expert for Directions in a Video Call! https://chatgpt.com/share/69947b41 -9efc-800f-823b-81e7700dfabc
42. Results on Different Levels • Subject matter e.g. architecture • Social: How does the person behave? • Team dynamics: What do they say about others? • Why did this team create this solution?
43. Reviews are Like Watching a Play About Architecture – with Interesting Characters. https://chatgpt.com/share/69947b41 -9efc-800f-823b-81e7700dfabc
44. Example: No Acceptance of a Done Dea • Many interviewees mention the same decision • Subjective: incredibly bad! • But: nobody could name an alternative …doable before the planned deadline. • Only possible solution: keep decision • Real finding: Team is really frustrated.
45. Socio -technical Architecture Review Kick Off Interviews
46. Presentation • Just summing up insights: value? • So: Recommendations to take action • Urgent / non-urgent • Important / less important
47. Socio -technical Architecture Review Kick Off Interviews More Iterations
48. Presentation: Feedback • More details needed? • Other points of view needed? • Iterate! • Enough is enough: End the review if enough information is available.
49. Socio -technical Architecture Review Kick Off Interviews More Iterations
50. Example: No Common Understanding • All interviewees mentioned different problems. • So there is no common understanding yet. • Get all problems on the table, get a common understand, and prioritize them. • External support very helpful. Review Solution
51. Effective and efficient
52. Efficient • Interviewees mention what they consider important • Great guide to the real problems. • They might be mentioned explicitly …or become obvious (e.g. social problems). • Does an unguided search across all potential problems make any sense?
53. Effective • Interviewer and interviewees build a trustful relationship. • Interviewee can provide their input. • Interviewee are more likely to listen to the results of the review …and act. • Review might already attack and solve problems.
54. Example • Leading consultancy did extensive review with a team. • Result: slide deck • Two colleagues did a review, then started consulting. • Result: Actual change in the overall approach
55. Might contain valuable insight. So? https://chatgpt.com/share/69947b41 -9efc-800f-823b-81e7700dfabc
56. Better result: A working team. https://chatgpt.com/share/69947b41 -9efc-800f-823b-81e7700dfabc The headless software architect.
57. Example • Management didn’t really want a review. • We presented our approach … and were hired on the spot. • Reason: Team was not really constructive. • Review turned into consulting and solving problems. • Result: Team started to work successfully again.
58. Conclusion
59. Conclusion • Real problems: social and concern people. • Reviews about code or architecture miss the point. • Focus on people and their subjective impression! • Naturally leads action on identified issues. • Result: Not just insight … but sometimes even better teams
60. https://software-architektur.tv/2026/02/06/folge301.html https://swaglab.rocks/star-review/
61. DRINK A VIRTUAL COFFEE WITH ME! Eberhard Wolff Head of Architecture https://swaglab.rocks/ https://ewolff.com/ https://swaglab.rocks/virtueller -kaffee/eberhard/
62. Slides + more Powered by Amazon Lambda Email address logged for 14 days, wrong addressed emails handled manually Send email to jax2026@ewolff.com