Strategisch denken en Wardley Mapping met Susanne Kaiser

Hieronder vind je een samengevat transcript van het gesprek tussen Gien Verschatse en Susanne Kaiser op Satisfying Software.

Waarom is het moeilijk om softwarearchitectuur af te stemmen op de noden van de business?

Gien: Waarom denk je dat mensen zo worstelen met het creëren van een softwarearchitectuur die echt aansluit bij de noden van de business?

Susanne: Het antwoord heeft veel kanten. Een van onze neigingen is dat we meteen in de oplossingsruimte springen zonder de probleemruimte echt te begrijpen. De probleemruimte gaat over onze oplossingen afstemmen op de noden van de business en de gebruikers — niet alleen waarde kunnen genereren voor klanten, maar die waarde ook kunnen leveren.

Om een snelle flow van verandering mogelijk te maken, hebben we een holistisch perspectief nodig — van bedrijfsstrategie, over softwareontwerp en architectuur, tot teamorganisatie. Elk daarvan beïnvloedt de architectuur waarvoor we kiezen. Zoals een citaat uit Continuous Architecture in Practice het stelt: we moeten "architect for change and leverage the power of small."

Dat betekent ook rekening houden met de wet van Conway — de communicatiestructuur van je organisatie weerspiegelt zich in het ontwerp van je softwaresysteem. Alles beïnvloedt al de rest, dus je kunt niet gewoon meegaan met de stroom. Je moet elk perspectief op elkaar afstemmen om uiteindelijk aan de noden van de business te voldoen.

Wardley Mapping versus andere discovery-tools

Gien: Ik gebruik het Business Model Canvas vrij vaak om een holistisch beeld te krijgen. Jij lijkt Wardley Mapping te verkiezen. Waarom?

Susanne: Het sluit elkaar niet uit — gebruik de tools waarmee je je comfortabel voelt. Maar ik hou persoonlijk van Wardley Mapping omdat het vertrekt vanuit het perspectief van de gebruikersnood. Gebruikers en hun noden zijn het anker van de map.

Het vult de jobs-to-be-done-theorie ook heel goed aan. Clayton Christensen stelde dat mensen producten of diensten kopen om een job gedaan te krijgen. We kunnen vertrekken van een functionele kernjob, de gewenste uitkomsten identificeren als gebruikersnoden, en van daaruit verder werken. Het herijkt ons denken — vroeg in mijn carrière greep ik naar de meest glanzende technologie zonder ze te verankeren in een gebruikersnood.

Wardley Maps helpen ook om een gedeeld begrip van het bedrijfslandschap te creëren: bouwen we op maat componenten die geen deel uitmaken van ons kerndomein? Zouden dat in de plaats kant-en-klare producten of in de cloud gehoste diensten kunnen zijn? Je kunt verschillende maps over elkaar leggen en synergieën ontdekken, je eigen aannames in vraag stellen, en het toekomstige landschap voor je zien waar je naartoe wilt.

Gien: Veel van de developers met wie ik werk, kunnen niet echt verwoorden hoe het bedrijf geld verdient of welke waarde het probeert te leveren. Ze zijn er voor de technologie en het plezier ervan.

Susanne: Maar op een of andere manier moet je geld verdienen. Je moet begrijpen welk probleem je oplost en wie je klanten zijn. En we over-engineeren vaak oplossingen met features die gebruikers nooit zullen gebruiken, gewoon omdat we niet begonnen zijn met gebruikersonderzoek of service design. De probleemruimte blijft meestal dezelfde — gebruikers geven er doorgaans niet om of je de nieuwste AI-technologie gebruikt, zolang je efficiënt en effectief aan hun noden voldoet.

Tips om gebruikersnoden te ontdekken

Gien: Als je een bedrijf binnenstapt waar dit allemaal onbekend is, hoe breng je dan gebruikersnoden aan de oppervlakte?

Susanne: Ik organiseer collaboratieve workshopsessies met mensen uit product, software engineering en design — vergelijkbaar met de mix die je wilt voor EventStorming-sessies. Het is vaak onthullend: teams beginnen met één verondersteld type gebruiker en ontdekken er, door het gesprek, veel meer.

Enkele nuttige heuristieken: volg een user journey als die bestaat, of identificeer noden taak per taak. De sleutel is dat gebruikersnoden technologie-agnostisch zijn en uitgedrukt worden in taal die gebruikers zelf begrijpen — niet "item opslaan in de database". Dat lijkt op het principe achter de domain events van EventStorming, die in de ubiquitous language uitgedrukt worden.

Een praktisch voorbeeld: neem een online school. De functionele kernjob van de leerkracht zou "leren op afstand faciliteren" kunnen zijn. Van daaruit kun je vragen: wat zijn de gewenste uitkomsten? Lesmateriaal voorbereiden, het begrip van studenten beoordelen, vooruitgang opvolgen, communiceren met studenten — dat worden de gebruikersnoden.

Wardley Maps verbinden met Domain-Driven Design

Gien: Ik gebruik vooral EventStorming om bounded contexts te identificeren, en classificeer ze dan als core, supporting of generic. Zie jij een verband tussen die subdomeintypes en de evolutiefases van Wardley — genesis, custom, product, commodity?

Susanne: Ja, dat is een van de belangrijkste heuristieken. Bounded contexts in het kerndomein belanden meestal in genesis en custom build, waar het differentiatievoordeel het grootst is. Bounded contexts in generieke subdomeinen — niet-differentiërend en niet-gespecialiseerd — zijn kandidaten voor de fases product/huur of commodity, waar het kostenvoordeel toeneemt naarmate meer concurrenten dezelfde oplossing aanbieden.

Supporting subdomeinen zijn genuanceerder. Ze bieden geen concurrentievoordeel, dus ze zijn niet-differentiërend, maar ze zijn wel gespecialiseerd in het ondersteunen van je kern. De vraag is of bestaande marktoplossingen goed genoeg passen, of dat de use case te specifiek is om op kant-en-klare opties te vertrouwen.

Dat gezegd zijnde, het is geen perfecte mapping. Dat een component in de commodity-fase zit, betekent niet noodzakelijk dat je ze niet op maat zou moeten bouwen — concurrentievoordeel omvat volgens Michael Porter zowel kostenvoordeel als differentiatie. De eigen infrastructuur van een cloudprovider zit misschien in wat consumenten als commodity zien, maar intern wordt ze nog steeds op maat gebouwd en strategisch afgeschermd.

Gien: Ik kijk ook naar het toekomstige potentieel. Kerndomeinen verliezen na verloop van tijd bedrijfswaarde naarmate concurrenten bijbenen. Een supporting subdomein met echt potentieel is het misschien waard om nu in huis te bouwen, in plaats van het kant-en-klaar te kopen.

Susanne: Precies. En waar Wardley Maps goed in zijn, is die beslissingen expliciet maken — niet gewoon "we hebben het altijd zo gedaan", maar het waarom naar boven halen en in vraag stellen. Ik ben teams tegengekomen die hun eigen taakbeheer op maat bouwden, of infrastructuur in een kelder draaiden, en de vraag "is dit hoe jullie je onderscheiden van je concurrenten?" volstaat om een productief gesprek op gang te brengen.

Klimaatpatronen en evoluerende landschappen

Gien: Wat zijn klimaatpatronen in Wardley Mapping?

Susanne: Klimaatpatronen zijn externe krachten die op je landschap inwerken, los van je specifieke context. Ze kunnen versnellen of vertragen hoe je componenten evolueren. Bijvoorbeeld: componenten evolueren langs de evolutiefases door de concurrentie van vraag en aanbod — je weet dat het zal gebeuren, maar niet precies wanneer. En er is inertie tegenover verandering: Nokia bouwde in 2005 een van de eerste smartphones, twee jaar vóór Apple, maar hun succes uit het verleden maakte hen terughoudend om volledig de overstap te maken. Ze onderschatten software en werden voorbijgestoken.

Een ander patroon is "efficiëntie maakt innovatie mogelijk" — wanneer een component een commodity wordt en standaardiseert, kunnen er nieuwe componenten bovenop gebouwd worden. Zo heeft cloud computing een hele generatie startups mogelijk gemaakt.

Die patronen begrijpen is een concurrentievoordeel, omdat de meeste van je concurrenten er niet over nadenken. Het voedt wat Wardley doctrinale principes noemt — universele goede praktijken die je in staat stellen om vroeg en snel op verandering te reageren — en uiteindelijk de leiderschapsbeslissingen over waar je strategisch naartoe wilt.

Gien: Elke markt heeft zijn eigen cadans — in de luchtvaart is dat een decennium, bij LLM's zijn het maanden. Maar de onderliggende patronen duiken in allemaal op.

Susanne: Ja, en hoe meer gereguleerd of geconsolideerd de markt, hoe meer sommige patronen domineren over andere. Maar je bewust zijn van wat er op je landschap inwerkt, maakt het veel makkelijker om te beslissen wanneer je je architectuur opnieuw moet evalueren — niet gewoon "instellen en vergeten".

Frustraties in de huidige softwarecultuur

Gien: Welke dingen frustreren je nog in dit vakgebied?

Susanne: We hebben nog steeds de neiging om naar oplossingen te springen voor we het probleem begrijpen. Op dit moment zijn er heel veel AI-initiatieven die gericht zijn op de technologie zelf, in plaats van de vraag te stellen: helpt dit ons om sneller en duurzamer waarde te leveren aan onze klanten? We zoeken naar shortcuts, en in complexe domeinen zijn die er vaak niet.

Het DORA AI-rapport stelde eigenlijk vast dat AI versterkt wat er al is — goede processen worden beter, slechte processen worden slechter. Dus als er al iets veranderd is, is het dat degelijke architectuurpraktijken hebben belangrijker geworden is, niet minder.

Wat betekent satisfying software voor jou?

Susanne: Software is geen doel — het is een middel om een doel te bereiken. Satisfying software helpt gebruikers om hun job effectief en efficiënt te volbrengen. Het betekent het juiste ding bouwen, en het goed bouwen, niet alleen focussen op de technologie.

Dat geldt ook voor interne klanten — teams die hun werk zelfstandig kunnen leveren, mogelijk gemaakt door self-servicemogelijkheden, misschien via platformteams zoals beschreven in Team Topologies. Een netwerk van autonome waardestromen, die zonder bottlenecks vloeien, in dienst van zowel externe klanten als de mensen die het product bouwen.