Wat is Event Storming?

Voordat we in detail treden, bespreken we eerst de rol van Event Storming in een agile context.Event Storming is de afgelopen jaren een zeer populaire methodologie geworden en heeft zijn plaats gevonden in de levenscyclus van softwareontwikkeling als techniek voor het verzamelen van vereisten.

Event Storming werd in 2012 ontwikkeld doorAlberto Brandolini als een alternatief voor nauwkeurige UML-diagrammen. Hetis een workshopachtige techniek die projectstakeholders samenbrengt (zowel ontwikkelaars als niet-technische gebruikers) om complexe bedrijfsdomeinen te verkennen in domeingedreven ontwerparchitectuur.

Een van de sterke punten van Event Storming is dat het zich kan richten op de zakelijke belanghebbenden en het hoge interactieniveau. De techniek is eenvoudig en vereist geen enkele technische training.

Met Event Storming kun je verschillende doelen nastreven:

• verbeterpunten van een bestaande bedrijfsstroom identificeren;
• onderzoeken of een nieuw bedrijfsmodel levensvatbaar is;
• inzicht krijgen in een gedeeld begrip van hoe een bedrijf werkt;
• schone en onderhoudbare Event-Driven software ontwerpen.

Er zijn drie primaire abstractieniveaus voor Event Storming:

1. Big picture: wordt gebruikt voor het verkennen van het huidige begrip van het systeem door belangrijke mensen met verschillende achtergronden samen te brengen en een gedeeld begrip te creëren.
2. Procesmodellering: op dit niveau modelleren we één bedrijfsproces van begin tot eind, verduidelijken we alle bedrijfsregels en zorgen we ervoor dat iedereen op één lijn zit.
3. Softwareontwerp: in deze laatste stap beginnen we met het ontwerpen van de software op basis van bouwstenen uit Domain-Driven Design en een reactief programmeerparadigma. Elke sticky note kan tijdens de implementatiefase een softwareartefact worden.

Bij het toepassen van Event Storming moet je eerst de Domain Events in het probleemdomein identificeren op een tijdlijn. De bron van een Domain Event kan het volgende zijn:

• Een gebruikersinteractie
• Een gebeurtenis die plaatsvindt
• Het gevolg van het verstrijken van de tijd
• Het gevolg van een andere Domain Event.

Vervolgens schrijven we deze domeingebeurtenis op een oranje sticky note.

Als alle domeingebeurtenissen gedefinieerd zijn, is de tweede stap het vinden van de opdracht die deze domeingebeurtenissen heeft veroorzaakt. Opdrachten worden op blauwe briefjes geschreven en direct voor de bijbehorende domeingebeurtenis geplaatst. Tenslotte moet je de aggregaten identificeren waarbinnen commando's worden uitgevoerd en waar gebeurtenissen plaatsvinden. Deze aggregaten worden op gele plakbriefjes geschreven.

De Systeemmodeler gebruiken

In de afgelopen jaren hebben we Event Storming omarmd als een techniek voor het verzamelen van vereisten binnen ACA-IT Solutions - zozeer zelfs, dat het nu een geïntegreerd onderdeel is van ons portfolio en de manier waarop we software ontwikkelen voor onze klanten. Als u daar meer over wilt weten of als u meer wilt weten over Event Storming, kunt uhier contact met ons opnemen.

De System Modeler gebruikt EventStorming als inspiratie voor het documenteren (modelleren) van de gebeurtenissen die bedrijfsprocessen vertegenwoordigen, het configureren van high-level eigenschappen die aan deze gebeurtenissen zijn gekoppeld en vervolgens het automatisch genereren van Apps en Collaboration Types vanuit het model.

Een System Modeler sessie omvat het gebruik van vijf virtuele sticky notes om te representeren:

• Gebeurtenis: iets dat gebeurt in het bedrijf
• Reactie: reacties op gebeurtenissen
• Opdracht: gebruikergestuurde acties die gebeurtenissen produceren
• Extern systeem: systemen die extern zijn aan het bedrijf
• Issue: documenteren van potentiële problemen of onbekenden over gebeurtenissen

De System Modeler maakt ook gebruik van één container:

• Bounded Context: bevat notities die een gemeenschappelijk vocabulaire delen

Hieronder ziet u het resultaat van een EventStorming-sessie in de System Modeler, die het melding- en volgsysteem voor gaten in het wegdek van een stad voorstelt. Het model vertegenwoordigt:

• een mobiele app waarmee stadsbewoners een pothole kunnen melden
• Aanmaken van nieuwe databaserecords om gemelde gaten te documenteren
• realtime melding van nieuwe meldingen van gaten aan stadsdiensten
• medewerkers kunnen de status van een gat bijwerken
• realtime melding aan de meldende bewoner wanneer de status is gewijzigd
  

System Modeler is een geweldige manier om de kloof te overbruggen tussen het verzamelen van requirements voor een event-driven applicatie en de daadwerkelijke implementatie. In dit geval doen we dat elektronisch op het canvas. Bovendien is dit een samenwerkingsomgeving, waardoor meerdere mensen tegelijkertijd aan dit model kunnen werken. Met de System Modeler kunnen gebruikers samenwerken met meerdere personen, niet alleen in een bepaalde ruimte, maar op een willekeurig aantal geografische locaties. Dit is een geweldige manier om echt een soort gedistribueerde requirements gathering sessie te doen. Zeker nu de pandemie veel mensen ervan weerhoudt om naar kantoor te gaan!

Van vereisten naar supersnelle POC's

Op basis van deze sessie voor het verzamelen van vereisten kunnen we nu dit vereistenmodel gebruiken en een toepassing maken. Het enige wat gebruikers hoeven te doen is overschakelen van de 'modelmodus' naar de 'genereermodus' en de verschillende elementen groeperen. Nadat de onderwerpen en samenwerkingstaken zijn gedefinieerd, hoeft u alleen maar op de knop Genereren te klikken.Deze eenvoudige handeling alleen al genereert ongeveer 70% van de code van deze specifieke applicatie! Dit maakt System Modeler waarschijnlijk de eenvoudigste manier om zeer snel van het ontwerpen van applicatie-eisen over te gaan op de ontwikkeling van de applicatie zelf.

Conclusie

Moderne applicaties moeten in real-time werken, omdat ze worden aangestuurd door wat er op dat moment in de echte wereld gebeurt. Ze moeten gemakkelijk kunstmatige intelligentie en IoT-technologie integreren en de applicaties zelf moeten worden gedistribueerd bij de bron van de gebeurtenissen. De softwarelogica moet overal kunnen draaien (cloud, edge, on-premises). Voor deze toepassingen is het ook nodig om mensen in het proces te integreren wanneer een hoger niveau van intuïtie en redenering nodig is. Met System Modeler is het eenvoudig om snel een zeer groot deel van zo'n applicatie te genereren. De System Modeler heeft immers de mogelijkheid om requirements te verzamelen van zakelijke gebruikers, domeinexperts en ontwikkelaars en deze requirements zeer snel om te zetten in een draaiende event-driven applicatie. Het maken van deze supersnelle POC's is een koud kunstje!

Als u meer wilt weten over hoe ACA Group en event-driven technologie uw digitale transformatie kunnen versnellen, neem dan contact met ons op!