Visualizing sociotechnical architectures with Context Maps

When designing a system, we usually make sure to document the technical integration towards other systems. We thereby make call- or consume-relationships explicit. This approach ignores an important aspect, which often is hidden implicitly: the other teams who are owning these systems and their domain models. However, we must consider the impact of teams, organizational aspects and political dynamics.
Context Maps, are a part of strategic Domain-driven Design and aim at delivering a holistic overview over such sociotechnical architectures. They make the implicitly hidden organizational dynamics explicitly visible. This talk introduces you to the motivation and the benefit for Context Maps. It also digs deep into the patterns which explain various relationship-types between systems, teams and the associated domain models. The talk concludes with a consistent visual representation of Context Maps in practice.

Transcript

1. Visualizing Sociotechnical Architectures with Context Maps Michael Plöd
2. 2 Speaker Michael Plöd Fellow at INNOQ Twitter: @bitboss
3. 3 My assuptions / prerequisites You know about (Sub)domains, Bounded Contexts, Domain Models and Integration. You don’t need to be an expert. I will talk about Context Maps: their motivation, the patterns, their use cases, a few heuristics and how to apply them. In addition to that I will also look at other options. I will NOT talk about REST, WebServices, Apache Kafka, Microservices or other technical integration stuff.
4. Get my DDD book cheaper Book Voucher: 7.99 instead of (min) 9.99 http://leanpub.com/ddd-by-example/c/speakerdeck
5. 5 McKinsey: „At larger companies, structural issues are the top hurdle to meeting digital goals“ Quelle: https://www.mckinsey.com/business-functions/digital-mckinsey/our-insights/the-digital-tipping-point-mckinsey-global-survey-results „Focus on organization-wide impact. Companies expect much of their near- term growth to be driven by digital, but impact remains elusive. What’s more, effective organizational structures, accountability, and meaningful metrics and incentives are largely lacking. As executives become more involved in digital efforts, they must work to ensure that their structures and business processes are set up to take full advantage of the opportunities that digital efforts offer.“
6. 6 Domain-driven Design contains sociotechnical aspects which can enable teams to be autonomous and to deliver value at speed by decentralizing governance aspects
7. 7 Centralized models lead to many dependencies
8. 8 The language for loan application form may differ Loan Application Form Loan Applications Loan Application Form Scoring Applicant Scoring Cluster Financial Situation Scoring Cluster Applied Credit Scoring Cluster Credit Decision Credit Decision Template Contracting Contract Proposal Contract
9. The bounded context is a linguistic boundary around the meaning of a (domain) model 9
10. 10 In an ideal world we want to align Subdomains and Bounded Contexts Loan Applications Scoring Credit Decision Contracting Credit Sales Funnel Document Check Internal Scoring Security Assessment External Scoring Credit Decision Contract Proposal Contract Creation Credit Application Applicant Document Rule Clusters Securities External Rating Decision Template Decision Hierarchy Decision Contract Proposal Contract
11. „Team assignments are the first draft of the architecture” Michael Nygard Author of „Release It“ 11
12. 12 Let’s say we have a total of 50 people to build teams? How do we distribute them? Loan Applications Scoring Credit Decision Contracting Credit Sales Funnel Document Check Internal Scoring Security Assessment External Scoring Credit Decision Contract Proposal Contract Creation Credit Application Applicant Document Rule Clusters Securities External Rating Decision Template Decision Hierarchy Decision Contract Proposal Contract or
13. Heuristics for team distribution 13 Things to keep in mind 5-9 people per team Mind cognitive load of a team „You design it, you build it, you run it“ Mind communication bandwith Take subdomains into account
14. 14 Categories for Subdomains Subdomain Core (Sub)domain • Most important subdomain • The heart of an organization’s business • Differentiation against competitors and complexity Supporting Subdomain • Vital for the operating of core (sub)domains • Lack of strategic relevance with regards to competition • Can be complex or simple Generic Subdomain • Needed functionality, which is not critical at all • „We need some solution of problem x“ • No way to differentiate
15. 15 The categorization of subdomains should have an impact on staffing, make or buy decisions and even IT-procurement Core (Sub)domain • In-House development • Excellent teams with excellent working conditions • Staffing strategy should be „insourcing“ • No Near- / Off-Shore development • No „Custom Off The Shelf“ (COTS / Standard) Software Supporting Subdomain • In-House development with external support is possible • Some Near-Shore development is an option • „Custom Off The Shelf“ (COTS / Standard Software) products that fits your processes with minor customizations • Avoid complete outsourcing and / or major customizations of COTS products Generic Subdomain • Look of COTS or SaaS Products that get „the task done“ • Staffing strategy can be „outsourcing“ • Look for cost saving opportunities • Don’t put your best employees into generic subdomains • Vendor Management is a key skill in this area Focus Cost
16. Wardley Maps can also provide valuable insights Image Credit: https://medium.com/@rbouma/lean-agile-scotland-2016-c3756adcb18d
17. Make sure that your core (sub)domains and / or your most valuable contexts in genesis and custom built phases are perfectly staffed 17
18. 18 Fundamental Team Topologies Complicated Subsystem Enabling Platform Stream-aligned
19. 19 Subdomains + Team Topologies Core (Sub)domain Supporting Subdomain Generic Subdomain
20. 20 Coupling of bounded contexts Although bounded contexts aim for a high degree of decoupling there needs to be some kind of connection between: •The teams •The software •The business capabilities
21. Team B Team A ?
22. 22 “An architect should be thinking: Which team interaction modes are appropriate for these two teams? What kind of communication do we need between these two parts of the system, between these two teams?“
23. Team Interaction Modes Collaboration X-as-a-Service Facilitating Image taken from the Team Topologies book
24. Team Interaction Modes Image taken from the Team Topologies book
25. Context Maps aim to deliver a holistic overview with regards to coupling of bounded contexts 25
26. 26 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 influence 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 influence 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.
27. 27 Systems calling each other or consuming events Some Bank Schufa WS Calls a WebService Scoring Credit Application Sales Funnel Domain Event Consumes
28. Some Bank Schufa WS Scoring Credit Application Sales Funnel Domain Event 28 The propagation of models Schufa Result Credit Application
29. 29 Teams communicating with each other Some Bank Schufa WS Scoring Credit Application Sales Funnel Domain Event
30. 30 Teams communicating with each other Some Bank Schufa WS We will adjust the interface and the underlying model with the next release. Ok no problem, just send us the documentation.
31. 31 Teams communicating with each other Scoring Credit Application Sales Funnel Domain Event We will deprecate the domain event and replace it with a new one. We have neither the budget, nor the capacity to implement that change.
32. Schufa REST 32 Actions of one team have an impact on others Some Bank WS We will replace the WebService with RESTful Resources next week. Some Bank
33. These patterns address a diverse variety of perspectives 33 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
34. Schufa OHS 34 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
35. 35 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
36. 36 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
37. 37 Conformist couples the core of your domain model to the external model Anticorruption Layer reduces the coupling to the adapters
38. 38 Heuristics for choosing a Conformist The degree of coupling and also connascence of a Conformist is higher compared to an Anticorruption Layer but there are a few situations in which a Conformist may still be the better choice. •One Bounded Context provides computations, that are highly regulated by legal authorities (collateral value of a real estate for example) •One team / Bounded Context is considered to be a specialist in aggregations or computations and we don’t want others to alter their results.
39. 39 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
40. 40 Heuristics for Shared Kernels A Shared Kernel introduces a high degree of coupling between the teams and their software and is, therefore, often considered not to be a good option. However, there are situations in which a Shared Kernel may be a good idea: •One team is responsible for two or more bounded contexts which have an overlap in terms of language •Strictly avoid a Shared Kernel when two teams are in a competitive situation or where a lot of backdoor politics are being played •When two teams have a Shared Kernel, they should form a Partnership…
41. Scoring Credit Sales Funnel 41 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. 42 Customer-Supplier A Customer-Supplier development gives the downstream team some influence •Downstream requirements factor into upstream planning. Therefore, the downstream team gains some influence 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 fields in the application Ok
43. 43 Separate Ways A bounded context has no connections to others •Sometimes integration is too expensive or takes very long •The teams choose separate ways in order to focus on specialized solutions •Interesting pattern for minimum viable products or organizational solutions in uncertain market conditions Credit Sales Funnel Contract Offering and Creation Manual process for entering credit application data in contract SW
44. 44 Published Language A well documented language shared between bounded contexts •Every bounded context can translate in and out from that language •Sometimes defined by a consortium of the most important stakeholders / teams •Often combined with Open-host Service •Examples: iCalendar, vCard, ZugFerd Credit Sales Funnel Credit Application Scoring Real Estate Rating Contract Proposal PL
45. Core Banking System 45 Big Ball Of Mud A (part of a) system which is a mess by having mixed models and inconsistent boundaries •Don’t let the (lousy) model of the Big Ball Of Mud propagate into your context •Anticorruption Layer is the pattern of choice on the downstream •Demarcation of bad model or system quality BBoM Contract Creation ACL
46. 46 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 ✅
47. 47 Some of the patterns reflect team relationships Team Relationships Mutually Dependent • Partnership • Shared Kernel Free • Separate Ways • Published Language Upstream / Downstream • Customer-Supplier • Anticorruption Layer • Conformist • Open-host Service
48. 48 Mind team communication Team independence Tight Coupling / Integration Shared Kernel Customer / Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language Team Communication
49. 49 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
50. Ask those questions 50 Subdomain categories and the context map Should a generic or supporting subdomain be a customer for a supplier in a core domain? Should a core domain conform to the model of a generic or supporting subdomain? How do we deal with a Big Ball Of Mud in a core domain? Conform to it in the other categories? Do we want Partnerships or mutually dependent teams between core and the other subdomains?
51. 51 Also look at bounded context model traits Influence of an Octopus Enforcer? Bubble Context for Bubble Context? Mind the Enterprise Integration Patterns!
52. Some examples in which Context Maps make implicit issues explicit 52
53. 53 System ABC Open Host Service Upstream Downstream System X Anticorruption Layer System Y Anticorruption Layer System Z Anticorruption Layer POLITICAL FOUL PLAY „Vetoing“ Customer „Helpless“ Supplier
54. 54 The model propagation from hell U D D U U D Credit Application Scoring Credit Agency Customer Customer Contact O H S C F S K CF ACL OHS O H S Rating Model Customer Model
55. 55 Context Map Scenarios Taken from my Domain-driven Design book •These scenarios showcase various options / alternatives •Domain: retail mortgage loans •https://www.leanpub.com/ddd- by-example
56. 56 How teams gain influence
57. 57 Degrading influence of a team
58. 58 Using a Published Language
59. 59 Dealing with a Big Ball Of Mud
60. 60 Where should context maps help? Governance A Context Map helps to identify governance issues between applications and teams. Transformation A Context Map is an excellent starting point for future transformations: it gives an in-depth insight into integration aspects and subdomain / context relations Bad Models By introducing a Context Map we get a clear view on where and how bad models propagate through application landscapes Politics By not just looking at technical integration aspects the Context Map also helps us in seeing how teams communicate and „play politics“.
61. 61 Context Map The context map is a powerful tool for •making implicitly hidden organizational processes visible •identify the flow of bad domain models •establishing a decentralized governance model •PS: managers LOVE context maps ;-)
62. Get my DDD book cheaper Book Voucher: 7.99 instead of (min) 9.99 http://leanpub.com/ddd-by-example/c/speakerdeck
63. Krischerstr. 100 40789 Monheim am Rhein Germany +49 2173 3366-0 Ohlauer Str. 43 10999 Berlin Germany +49 2173 3366-0 Ludwigstr. 180E 63067 Offenbach Germany +49 2173 3366-0 Kreuzstr. 16 80331 München Germany +49 2173 3366-0 Hermannstrasse 13 20095 Hamburg Germany +49 2173 3366-0 Gewerbestr. 11 CH-6330 Cham Switzerland +41 41 743 0116 innoQ Deutschland GmbH innoQ Schweiz GmbH www.innoq.com 63 Thank you! Michael Plöd Follow me on Twitter: @bitboss