Supersnelle POC's met Event Storming
Door een Proof of Concept (POC) te ontwikkelen, kun je voordat je heel veel tijd en geld stopt in het ontwikkelen van een softwareoplossing perfect testen of die oplossing ook echt het probleem van de klant verhelpt. Je kunt met een zeer beperkt budget en binnen korte tijd met dummy-gegevens een geraamte voor het project ontwikkelen en een vereenvoudigde versie van de oplossing die gericht is op de belangrijkste functies. Hoe sneller je een POC ontwikkelt, hoe sneller je weet wat wel en niet werkt. We vertellen je in deze blog hoe je supersnelle POC's kunt maken met Event Storming!
Wat is Event Storming?
Voordat we ingaan op de details, bekijken we eerst welke rol Event Storming speelt binnen een agile context. Event Storming is de afgelopen jaren steeds populairder geworden en deze methodologie heeft als techniek voor het verzamelen van vereisten een plekje veroverd in de levenscyclus van softwareontwikkeling.
Alberto Brandoliniontwikkelde de methode in 2012 als alternatief voor nauwkeurige UML-diagrammen. Event Storming is een workshop-achtige techniek waarbij belanghebbenden van een project (zowel ontwikkelaars als niet-technische gebruikers) samen gecompliceerde bedrijfsdomeinen verkennen binnen Domain Driven Design-architectuur.
Een van de sterke punten van Event Storming is dat de aandacht kan worden gericht op de zakelijke belanghebbenden en dat er veel ruimte is voor interactie. De techniek is bijzonder inzichtelijk en vereist geen enkele technische training.
Er zijn uiteenlopende doelen die je kunt bereiken met Event Storming:
- verbeterpunten bepalen binnen bestaande bedrijfsprocessen;
- verkennen of nieuwe bedrijfsmodellen rendabel zijn;
- gedeeld inzicht krijgen in hoe bedrijfsactiviteiten verlopen;
- schone en onderhoudbare Event Driven-software ontwerpen.
Event Storming kent drie belangrijkste abstractieniveaus:
- Big picture: om te bepalen hoe groot het huidige inzicht in het systeem is worden belangrijke mensen met verschillende achtergronden verzameld en ontstaat er een gedeeld inzicht.
- Process modelling: er wordt op dit niveau een bedrijfsproces van begin tot einde gemodelleerd, alle bedrijfsregels worden toegelicht en iedereen wordt op één lijn gebracht.
- Software design: we beginnen in deze laatste stap met het ontwerpen van de software met behulp van bouwstenen van Domain Driven Design en een reactief programmeerparadigma. Elke sticky note kan een software-pareltje worden tijdens de implementatiefase.
Bij het toepassen van Event Storming, moet je eerst op een tijdlijn de Domain Events in het probleemdomein bepalen. De bron van een Domain Event kan bestaan uit:
- Een gebruikersinteractie;
- Een Event afkomstig van een extern systeem;
- Het resultaat van de tijd die verstrijkt;
- Het gevolg van een ander Domain Event.
We noteren dit Domain Event vervolgens op een oranje sticky note.
Nadat alle Domain Events zijn bepaald, moet worden uitgezocht welk commando deze Domain Events heeft veroorzaakt. Commando's worden op blauwe sticky notes genoteerd en worden direct voor het bijbehorende Domain Event geplaatst. Je moet tot slot bepalen binnen welke samenvoegingen commando's worden uitgevoerd en waar events plaatsvinden. Deze samenvoegingen worden genoteerd op gele sticky notes.
System Modeler gebruiken
Event Storming is in de afgelopen jaren door ACA-IT Solutions omarmd als methode om vereisten te verzamelen, zelfs in die mate dat het nu integraal deel uitmaakt van onze portfolio en de wijze waarop we software ontwikkelen voor onze klanten. Neem voor meer informatie hierover of over Event Storming contact met ons op.
De System Modeler gebruikt Event Storming ter inspiratie om events die bedrijfsprocessen vertegenwoordigen te documenteren (modelleren), eigenschappen op hoog niveau te configureren die aan deze events zijn gekoppeld, en het vervolgens automatisch genereren van Apps en Collaboration Types van het model.
Bij een System Modeler-sessie worden vijf virtuele sticky notes gebruikt voor:
- Event: iets wat binnen het bedrijf gebeurt
- Reaction: reacties op events
- Command: door de gebruiker aangestuurde acties die tot events leiden
- External System: systemen die extern zijn voor het bedrijf
- Issue: mogelijke problemen met documenten of onzekerheden m.b.t. events
De System Modeler maakt daarnaast gebruik van één container:
- Bounded Context: bevat notities met een overeenkomstig vocabulaire
Je kunt hieronder het resultaat bekijken van een EventStorming-sessie in de System Modeler, met betrekking tot het rapportage- en volgsysteem van een stad ten aanzien van kuilen en gaten. Het model omvat het volgende:
- een mobiele app waarmee stadsbewoners melding kunnen doen van kuilen en gaten
- maken van nieuwe databaserecords om gerapporteerde kuilen en gaten te registreren
- realtime melding van stadsdiensten over nieuwe rapporten over kuilen en gaten
- arbeiders de kans geven om de status van een kuil of gat bij te werken
- realtime op de hoogte brengen van de rapporterende stadsbewoner als de status verandert
System Modeler biedt een geweldige manier om de kloof te dichten tussen het verzamelen van de vereisten voor een Event Driven-applicatie en de daadwerkelijke implementatie. We doen dat in dit geval elektronisch op het canvas. En omdat dit een samenwerkingsomgeving is, kunnen meerdere mensen tegelijkertijd aan dit model werken. Gebruikers kunnen dankzij de System Modeler samenwerken met meerdere mensen. Niet alleen in bepaalde ruimtes, maar op alle mogelijke geografische locaties. Dit is een geweldige manier om echt op een soort gedistribueerde wijze vereisten te verzamelen. Juist ook nu veel mensen vanwege de pandemie nog steeds niet op kantoor kunnen werken!
Van vereisten tot supersnelle POC's
We kunnen op basis van deze verzamelsessie voor vereisten, het model gebruiken om een applicatie te maken. Gebruikers kunnen simpelweg switchen van de 'modelmodus' naar de 'genereermodus' en kunnen de diverse elementen groeperen. Klik na het bepalen van de hoofdstukken en samenwerkingstaken op de knop 'Generate'. Met deze simpele handeling wordt al circa 70% van deze specifieke applicatiecode gegenereerd. De System Modeler biedt waarschijnlijk de eenvoudigste manier om snel van het ontwerpen van applicatievereisten over te stappen naar het ontwikkelen van de applicatie zelf.
Conclusie
Moderne applicaties moeten in realtime werken, omdat ze worden aangestuurd door wat er op dat moment in de echte wereld gebeurt. AI en IoT-technologie moet eenvoudig te integreren zijn en de applicaties zelf moeten bij de bron van de events worden gedistribueerd. De software moet overal kunnen worden uitgevoerd (cloud, edge, on-premises). Het is bij deze applicaties ook een vereiste dat er in het proces mensen worden geïntegreerd die indien nodig intuïtief en onderbouwd kunnen handelen. Het is met de System Modeler heel eenvoudig om snel een groot gedeelte van een dergelijke applicatie te genereren. De System Modeler kan immers vereisten verzamelen bij zakelijke gebruikers, domeinexperts en ontwikkelaars en kan die vereisten bijzonder snel vertalen naar een Event Driven-applicatie. Het maken van deze supersnelle POC's is een fluitje van een cent!
Meer weten over wat ACA en Event Driven-technologie kan doen om je digitale transformatie te versnellen? Neem contact met ons op!
