Visualizing Sociotechnical Architectures

Transcript

1. Visualizing Sociotechnical Architectures MICHAEL PLÖD FELLOW
2. Michael Plöd Fellow at INNOQ Mastodon (or Twitter): @bitboss@mastodon.social LinkedIn: https://www.linkedin.com/in/michael-ploed/ Current consulting topics: • Domain-Driven Design • Team Topologies • Transformation from IT Delivery to digital product orgs Regular speaker at (inter-)national conferences and author of a book + various articles
3. “Sociotechnical Architecture is about taking an holistic co- design approach to technical and organizational systems, given the inherent impact they have on each other.” Eduardo Da Silva https:/ /esilva.net
4. Sociotechnical Architectures are a lot about Systems Thinking as well To manage a system effectively, you might focus on the interactions of the parts rather than their behavior taken separately
5. Teams Modules Business Domain Should be a model of Should be aligned with Software Architecture Is structured in Deployment Unit(s) Are packaged into
6. There are many great visualization approaches for software architectures
7. 4+1 Model by Kruchten
8. 8 I will mainly focus on arc42 4+1 Model by Kruchten
9. Arc42 Building Block View C4 Model Level 2: Container Diagram (in parts) Source: https://c4model.com/ Source: https://arc42.org/overview
10. Teams Modules Business Domain Should be a model of Should be aligned with Software Architecture Is structured in Deployment Unit(s) Are packaged into Arc42 - Building Block View
11. Arc42 Deployment View Source: https://arc42.org/overview
12. Teams Modules Business Domain Should be a model of Should be aligned with Software Architecture Is structured in Deployment Unit(s) Are packaged into Arc42 - Deployment View
13. There are some approaches that can be used for organizational aspects
15. 15 Fundamental Team Topologies Complicated Subsystem Enabling Platform Stream-aligned Image taken from the Team Topologies book
16. Complicated Subsystem Team • Responsible for building and maintaining a part of the system that is highly dependent on specialist expertise • Team manages the complexity of the subsystem using speci f ic skills and expertise that are usually dif f icult to f ind or recruit. Enabling Team • Work alongside the stream-aligned teams and support them in the area of knowledge building and empowerment. • Have a strong collaborative nature and strive to understand the problems and shortcomings of the other teams • Inhouse consulting team Platform Team • Should give stream-aligned teams the possibility to do their work with a high degree of autonomy, • Platform provides self-service APIs, tools and services as an internal product Stream-aligned Team • Tailored to a business area or organizational capability (Bounded Context) • Is intended to create customer value quickly, safely and autonomously without having to delegate parts of the work to other teams.
17. A team can have attributes of several fundamental topologies but should be attracted to one of them Enabling Platform Complicated Subsystem Stream- aligned
18. Team Interaction Modes Collaboration X-as-a-Service Facilitating Image taken from the Team Topologies book
19. Team Interaction Modes Image taken from the Team Topologies book
20. Platforms Image taken from the Team Topologies book
21. Team Topologies is not just 4 Team Types + 3 Interaction Modes
23. It’s about the f low of work
24. Teams Modules Business Domain Should be a model of Should be aligned with Software Architecture Is structured in Deployment Unit(s) Are packaged into Team Topologies + Flow + Interactions
25. https://un f ix.com A pattern and model collection for versatile organizational design
26. 🤔 😝 😩 😬 😇 🥳 😅 😆 😉 😋 😎 🙄 😣 😮 🤐 😆 😉 😊 😋 🙄 😏 😣 😥 😮 M I A D 9 5 Governance Crew Partnership Crew Experience Crew Facilitation Crew Capability Crew Platform Crew Value Stream Crew Forum Base Turf 😌 😛 Chiefs Captain Captain Captain Captain Captain Chair Chair Captain Captain
27. Crews aka Team, Squad, Cell, Pod Small group of 3-7 people Exists for (at least) the duration of a de f ined mission The Crew is mostly self- organizing There is no manager on the Crew
28. • Evolutionary • Simple • Hints for identifying team boundaries • Team Interaction Modes • „Opinionated“ / Promotes best practices • Talks about Platforms, and not just Platform teams • Evolutionary • Very f lexible / adjustable • More holistic for complete org design • No Team Interaction Modes! • Not so opinionated, promotes some good advices • It’s easy to get lost with all the options
29. Teams Modules Business Domain Should be a model of Should be aligned with Software Architecture Is structured in Deployment Unit(s) Are packaged into unFIX NO Flow NO Interactions
30. There is one approach which bridges the gaps of the other approaches a bit
31. Strategic Domain Driven Design also has a technique which can be used to visualize sociotechnical relationships: CONTEXT MAPS
32. Context Maps in Domain Driven Design address relationships between Bounded Contexts and teams. They start „bounded context f irst“.
33. 33 Dependencies between teams Team Dependencies Mutually Dependent • Two software artifacts or systems in two bounded contexts need to be delivered together to be successful and work. • There is often a close, reciprocal link between data and functions between the two systems. Free • Changes in one bounded context do not in f luence success or failure in other bounded contexts. • There is, therefore, no organizational or technical link of any kind between the teams. Upstream / Downstream • An upstream context will in f luence the downstream counterpart while the opposite might not be true. • This might apply to code but also on less technical factors such as schedule or responsiveness to external requests.
34. These patterns address a diverse variety of perspectives 34 The context map uses patterns to describe the contact between bounded contexts and teams Shared Kernel Customer / Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language Partnership Big Ball Of Mud
35. Check out DDD Crew on GitHub https://github.com/ddd-crew/context-mapping •Cheat Sheet for all of the patterns and Team Relationships •Context Mapping Starter Kit for Miro (as a downloadable Board Backup) •Creative Commons
36. I’ll just mention a few of the patterns here to give you a taste
37. Schufa OHS 37 Open-host Service WebService The Open-host Service is a public API •One API for several consumers •No point-to-point API •Has a common, general purpose model and functionality •The team providing the Open-host Service is an upstream team Bank A Bank B U D D
38. Anticorruption Layer The Anticorruption Layer translates one model to another one •Transforms an external model from another team / bounded context / system to another internal one •Reduces the amount of coupling to a single layer •The team implementing an Anticorruption Layer is always downstream Credit Sales Funnel Scoring OHS ACL U D Credit Application Person Scoring Credit Scoring Security Scoring
39. 39 Conformist The Conformist slavishly adheres to the upstream model •There is no model-to-model transformation •Motivation: Simplicity, contracts, force or delight (for the upstream model) •The team implementing a Conformist is always downstream Credit Sales Funnel Scoring OHS CF U D Credit Application
40. 40 Shared Kernel Shared Kernel is a subset of a domain model that two teams share •„Physically“ shared artifact between two teams •Examples: shared JARs or database •High degree of coupling requires a high amount of coordination between the involved teams •Shared Kernel is no Anti-Pattern but use with caution Credit Sales Funnel Scoring Credit Application SK
41. Scoring Credit Sales Funnel Partnership Partnership is about cooperative relationships between teams •Establishes a process for coordinated planning of development and joint management of integration •Not technical at all, Partnership is plain organizational •Recommended for teams which depend on a Shared Kernel We want to adjust something Ok, let’s coordinate our efforts
42. Customer-Supplier A Customer-Supplier development gives the downstream team some in f luence •Downstream requirements factor into upstream planning. Therefore, the downstream team gains some in f luence over the priorities and tasks of the upstream team •Customer-Supplier is organizational •Mind „vetoing customer“ and customer against an OHS as anti-patterns Credit Sales Funnel Scoring CUS SUP U D We need more f ields in the application Ok
43. System ABC Upstream Downstream System Y Open Host Service Anticorruption Layer You can visualize different perspectives Customer Supplier • Call Relationship • Team Relationship - Level 1 • API Level • Model Propagation • Team Relationship - Level 2
44. 44 The patterns address various aspects Team Relationships Model Propagation API / „technical“ Open-host Service (✅) ✅ Anticorruption Layer ✅ Conformist ✅ Shared Kernel ✅ (✅) Partnership ✅ Customer-Supplier ✅ Separate Ways ✅ (✅) Published Language ✅ (✅) Big Ball Of Mud ✅
45. Context Mapping Quiz
46. Chain of Conformists
47. High Utilization Open Host Service
48. OHS + Customer / Supplier CUS SUP
49. In demand supplier
50. Teams Modules Business Domain Should be a model of Should be aligned with Software Architecture Is structured in Deployment Unit(s) Are packaged into Context Maps + Governance + Dependencies + Coupling
51. “Sociotechnical Architecture is about taking an holistic co- design approach to technical and organizational systems, given the inherent impact they have on each other.” Eduardo Da Silva https:/ /esilva.net
52. All of these approaches don’t have an holistic approach. We need to combine and improvise.
53. Introducing STA-Maps
54. https:/ /github.com/sta-maps/ STA-Maps is currently work in progress
55. Key Principles Flexibility - there are no f ixed views Open for extension - You are missing something? No problem: just add your building block, team dependency or -relationship. Trade-Offs instead of templates - STA-Maps don't tell you what is right or wrong. Instead they help you to visualize trade-offs in order to better discuss them. Collaborative - STA-Maps are there for modeling and reasoning about sociotechnical systems in a collaborative fashion.
56. Building Blocks
58. Alignments
62. Relationships
66. Teams Modules Business Domain Should be a model of Should be aligned with Software Architecture Is structured in Deployment Unit(s) Are packaged into STA-Maps + Interactions + Flow + Dependencies + Coupling
67. Krischerstr. 100 40789 Monheim +49 2173 3366-0 Ohlauer Str. 43 10999 Berlin Ludwigstr. 180E 63067 Offenbach Kreuzstr. 16 80331 München Hermannstrasse 13 20095 Hamburg Erftstr. 15-17 50672 Köln Königstorgraben 11 90402 Nürnberg innoQ Deutschland GmbH www.innoq.com Thank you! Michael Plöd E-Mail: michael.ploed@innoq.com LinkedIn: https://www.linkedin.com/in/michael-ploed/ German version of Team Topologies incl. the Remote Team Interactions Workbook Translated by me Released through O’Reilly Germany