Growing and thriving in a multi-model world

No initiative ever starts aiming to become a big Ball of Mud. But over time, principles and forces will act on the teams and the code, often constraining the options for evolutions.
In this talk, we’ll examine the challenges for envisioning and growing impactful multi-model enterprise software applications, from inception to multi-market maturity.

Transcript

1. Growing and Thriving in a Multi-Model World Alberto Brandolini @Ziobrando
2. My Plan • Good Old Times • Starting with the right foot • Transitioning to Multi-Model • Bonus Round
3. Good Old Times
4. Multiple Models? • Read about it in 2005 • Thought: “Not my problem!” • …”My project is simpler than that” • What a Fool!
5. Models sprawl … let me add just one more table…
6. Somebody gotta stop this!!!
7. But first, a few more features…
8. Fake Gantt Someone talking about serverless Someone saying: “It will take longer than this”
9. The illusion of parallelism Team A Project Project Project Project Project Project Project Project Team B Team C Impact Impact Impact Impact Impact Impact Impact Impact Team D Project Project Project
10. The reality of dependencies Team A Project Project Project Project Project Necessary refactoring Project Project Team B Team C Impact Impact Impact Impact Impact Impact Impact Impa Team D Project Project Project Depend ency Depend ency Depend ency Depend ency Depend ency Depend ency Depend ency Depend ency Depend ency Depend ency
11. Planning meetings
12. Black Market Planning
13. How does it look like?
14. From above… Information Technology Increased spending Progressively diminishing returns
15. More “precisely” • But consider also: • Extra overhead for management layer(s) • Extra costs for supporting roles • Inertia and lagging metrics development team size almost linear costs Progressively decreasing returns
16. Many variations are possible
17. But the pattern repeats
18. Repainting with Microservices
19. Splitting around data won’t help you
20. Single Model • Serves Multiple Purposes • without excelling in any • More stakeholders == more trade-offs • More stakeholders == More risks
21. The Bali Urban Legend Easy to get in, hard to get out
22. Summary: Good Old Times Sprawling is natural or… do we lack antibodies? Nobody intentionally starts a Big Ball of Mud But a Single Model turns into coupling, increased risk and paralysis Latency and luck delay the warning signals …while the cost of recovery progressively increases
23. Starting with the right foot Is it even possible?
24. Small experiment Photo by Nicolas Thomas on Unsplash
25. I am the business
26. Proxies to the rescue? • Unfortunately, most of these proxies are only visible in large organisations Bounded Context Limit of applicability of a model Team Subdomain Organization Technology Legacy • A single model tailored around a specific purpose
27. Boundaries are still visible! And Swimlanes too! You can be picky on Purpose, though
28. Can quickly lead us to • Purpose-oriented models • Separated by Events Bounded Context Bounded Context Bounded Context Public Event Local Event Public Event Bounded Context Local Event Local Event Public Event Public Event Local Event Just event-driven Storytelling about something happening outside the system Something happening inside a software system Something happening in a third-party system Something happening in the heal world
29. Not every model will be implemented… (…Now)
30. … but they’re models! And the business-oriented me wants to know about them!
31. Is it enough to avoid this?
32. Treat it like an addiction • Define guiding principle • Intercept the moment we are triggering the old habit • Do something different instead
33. We don’t change working design WE don’t open boxes without a very good reason
34. Alberto, I am revisiting your carbonara recipe with new ingredients
35. What’s the right bucket? Photo by Green Grasshopper on Unsplash
36. “Context Roadmapping” • Make sure every new feature has a place on the context map • Make sure the consequences of the decision are clear • (ADRs anyone?) • Ask yourself the tough questions: • Can it work without our legacy? • Can it work with Other Models (Products, competitors)? • Can it be valuable standalone? • How would I implement it without the legacy? Our Model New Feature New Feature (Conformist) Our new Model Our Model Our Model New Feature ACL New Feature
37. We have a problem… • Our brain still defaults to Canonical Model • This happens especially if we are talking to ourselves • …is the difference between verbal and visual thinkers relevant?
38. I Think it is
39. We need a map! Photo by The Cleveland Museum of Art on Unsplash
40. Context Map for one Business Line Strategy Pricing negotiation Training Experience Design Content Design Planning Publishing Sales Marketing Billing Reservation Date Picking Logistics Delivery Follow Up Claims Forecast Treasury Catalog
41. And for more… Books Public Trainings Private Trainings Consulting Sponsorships Public Speaking Software Delivery Meetups Events Planning Sales Delivery Billing Product Design Financial Analysis Strategy Marketing Inventory Date Picking Tracking Value Tickets and discounts Print on Demand Personal Availability Engagement Strategy Deals Pricing Budget Contracts & Engagement Partnerships Forecast Global Analysis Billing Billing Scouting Date Picking Content design Review Logistics Scouting Courseware and certificates Newsletter & social Newsletter & social Content Design Format Design
42. Framing Discussions 1. Visualise the current problem -> We don’t discuss invisible things 2. Highlight critical issues -> We don’t discuss invisible things 3. Visualise alternative solutions -> One is never enough. 4. Visualise Pros & Cons (Obvious, but not resolutive) 5. Highlight Scenarios …and their probability 6. Pick your preferred solution 7. Capture the discussion with an ADR
43. https://www.dropbox.com/s/czn6ee9fejs61t9/ Screenshot%202024-10-13%20at%2007.57.47.png?dl=0 https://www.dropbox.com/s/czn6ee9fejs61t9/ Screenshot%202024-10-13%20at%2007.57.47.png?dl=0
44. Structuring thoughts?
45. But Think freely! • Discussion alone isn’t design • Balance solo and team • Balance Computer and Lo-Fi • Balance Indoor and Outdoor
46. Most design happens in the boundaries
47. Explicit Purpose • Reaching clarity is HARD • …and clarity is EPHEMERAL • Let’s capture the CONVERSATION as a memento! • The bare minimum to get back in the “clarity mood”. Filtering out terms is key!
48. Strong Logical Boundaries
49. Deferred Physical Ones
50. Result?
51. Promise fulfilled • Complexity remained under control 🎉 • No High-Risk Hotspot in the system 🎯 • Many purposes and functionalities served without increasing fragility 👍 • (We still have issues with third-party integrations) 😒
52. Splitting around Events enables model simplicity It wouldn’t work if we just split around glorified tables: you still would have ONE model, just chopped into smaller pieces
53. Models’ simplicity enables Business Options
54. The Obvious Math Model Model Model New Model Model New Model Model Model + = Well designed System Well designed component Well designed System
55. Multi-Model in the small Counterintuitive: still our brain will be tempted Logical Boundaries, but ready to go physical Discipline is essential Stable team, Maps are the winning ingredient Hack the habit with new routines
56. Multi-Model in Startups Happens Rarely… “We don’t need multi models, we are a startup” But works really well! Quick Time To Market Ability to Pivot without being destructive.
57. Too Late, man Nice story, but our problem is a little different
58. WE are getting late with more Features! But we understand we need to change
59. But an opportunity isn’t enough
60. Plenty of Blockers • There is no time for refactoring • Where do we start? • Who’s going to be responsible? • Can we estimate? • Who decides where to start? • We never really did anything like this… • …fear? • Imposter Syndrome?
61. We’re stuck in deciding! Turns out the technical part isn’t the hardest one
62. DETECTING WHERE TO START
63. A little expectation reminder… Information Technology Increased spending Progressively diminishing returns
64. Where do we start?
65. Consensus is blocker Number one
66. Coupling increases the cost of consensus Remember Bali!!!
67. We can see frictions between model and reality And the ones more sensitive for the business
68. Splitting has risks!
69. Make it worthy!
70. Model splitting There are tools and practices to make it happen But the safety scaffolding takes time (The time someone forgot on the current implementation. Sorry for being picky.) Architecture views will tell us where it’s ugly Business will tell us where is worthy
71. Not the whole story What if actions and logic start to diverge?
72. What about Fear?
73. Fear Map • If FEAR is the hidden driver, let’s make it explicit! • Map the critical components in a quadrant. • Decide your strategy together Disposable Business critical Scary Safe Can we talk about it?
74. Overcoming the deadlocks
75. Everybody’s secret dream
76. They’re your decisions, sorry.
77. We need guidance! Build your own guidelines -> Wiki Style / Pull Driven Experiment transparently -> A Document Decisions -> ADRs to the rescue Make Uncertainties explicit -> You won’t have all the information you need.
78. Spikes and experiments
79. You can have both!
80. Model Model ??? The adapter stalemate Two models need an adapter in-between Teams would not start develoment unless ownership is defined. Apparently a design problem, but really a political one.
81. Pairing at the boundaries • If Both teams are active, pick experts from both sides to work on the frontier implementation • Decide on the responsibility attribution only after is completed •The journey will give you the information to decide, or can make the decision pointless.
82. See the pattern?
83. Don’t get blocked by uncertainty
84. Reduce Uncertainty by explicit exploration
85. Alone in the dark?
86. Better team up! Photo by Austin Distel on Unsplash
87. And show some vulnerability Nobody has all the answers
88. “Resistance” can be many things Habits Habits and pressure Imposter syndrome Cognitive dissonance …
89. Patterns?
90. They need to coexist! Ubiquitous Ubiquitous Ubiquitous Ubiquitous Surface (Canonical) Ubiquitous Ubiquitous BI (canonical)
91. The Draft-Executable-Tracking Archetype Draft Model Executable Tracking Easy to change, possibly partially specified Solid, running on read- only data Collecting or visualizing Validation Different Models, very similar languages, different paradigms
92. The Joys of Multi-Country
93. The Joys of Multi-country Read the forces shaping the model(s) Language? Regulations? Customs? Market Maturity? Debunk Powerpoint assumptions like “economy of scale” or “Reuse”
94. Don’t force solutions in
95. Events enable a new type of simplicity
96. It’s more emotions than skills
97. Confidence must be built
98. Decisions need to happen
99. Maps and new Habits
100. Good old times were wrong, sorry
101. Thank You! Alberto Brandolini @Ziobrando
102. Contacts: • Blog: • https://blog.avanscoperta.it << Cool new stuff! • https://medium.com/@ziobrando • http://ziobrando.blogspot.com • Twitter: @ziobrando • Mastodon: @ziobrando@hachyderm.io • Consulting & Training: info@avanscoperta.it • http://eventstorming.com • http://www.avanscoperta.it