Building Adaptive Systems For a Fast Flow of Change
Please log in to watch this conference skillscast.
In a world of rapid changes and increasing uncertainties, organizations have to continuously adapt and evolve to remain competitive and excel in the market.
In such a dynamic business landscape organizations need to design for adaptability. Organizations need to aim for building systems and team organizations aligned to the business needs and business strategy and evolving them for adaptability to new changes and unknown environments.
In this talk, I am going to highlight how the combination of Wardley Maps, Domain-Driven Design, and Team Topologies can provide a holistic, powerful toolset to design, build and evolve adaptive systems and team structures for a fast flow of change.
Q&A
Question: This is a very interesting mash-up of techniques @Susanne Kaiser. Have you implemented this structure at an organisation or is it still in the theory stage?
Answer: At my clients, I am using those different perspectives at different levels - currently mostly Wardley Maps and DDD and next is Team Topologies.
Question: Could you share here the resources you mentioned at the end of your talk?
Answer: Of course, I will share my slides later as well, but here are the resources I mentioned:
DDD:
- Eric Evans: "Domain-Driven Design: Tackling Complexity in the Heart of Software"
- Vaughn Vernon: "Implementing Domain Driven Design" and "Domain-Driven Design Distilled"
- Vladik Khononov: "What is Domain-Driven Design?"
Wardley Maps:
- Simon Wardley (Online Book): https://medium.com/wardleymaps
- https://learnwardleymapping.com/
- https://github.com/wardley-maps-community/awesome-wardley-maps
Team Topologies:
-Matthew Skelton, Manuel Pais: "Team Topologies"
Question: I was wondering if you had an opinion about separating teams across verticals of a domain - for example API versus UI for a single domain/bounded context?
Answer: I am a big fan of micro-frontends that increases the autonomy of the team owning that bounded context including UI. However, my current projects are (due to "historic" decisions), the most are organized with one UI using several backend APIs though. Hope to practice Micro-Frontend in future projects though. Then I could give a hands-on experience ;) I guess MicroCPH (https://twitter.com/MicroCPH) is planning a Micro-Frontend related conference (online) for next year.
Question: Should a stream-aligned team be responsible for a single domain model or multiple? How important is it to invest in core subdomains in the custom-built stage, particularly one that has already been quite successful, versus ones in the genesis stage?
Answer: A stream-aligned can own multiple domain models/bounded contexts depending on their complexity and its resulting cognitive load per team. If the team's cognitive load would be highly exceeded, then I would recommend to split it.
In general, I would suggest investing in both of your core subdomains (both in genesis, and custom-built): Investing in experimenting/exploring the genesis and watching out how the custom-built core-subdomains might evolve over time, e.g. are their opportunities that custom-built components can go later on in product + rental.
YOU MAY ALSO LIKE:
Building Adaptive Systems For a Fast Flow of Change
Susanne Kaiser
Tech Consultant Independent