Superfast POCs with Event Storming
Developing a Proof of Concept (POC) is a great way to test if a software solution really is the answer to a customer’s problem before you spend tons of time and money developing the solution. With a very limited budget and in a short span of time, you can create a dry-run of the project and a simplified version of the solution focusing on key features with dummy data. The faster you can set up your POC, the faster you learn what works and what doesn’t. In this blog post, we’ll tell you how to create superfast POCs with Event Storming!
What is Event Storming?
Before getting into details, let’s discuss EventStorming’s role in an agile context. Event Storming has become a very popular methodology during the past years and has found its place in the software development lifecycle as a requirements gathering technique.
Created by Alberto Brandolini in 2012 as an alternative to precise UML diagramming, Event Storming is a workshop-style technique that brings project stakeholders together (both developers and non-technical users) to explore complex business domains in domain-driven design architecture.
One of the strengths of Event Storming is being able to focus on the business stakeholders and the high level of interaction. The technique is straightforward and requires no technical training at all.
Using Event Storming, there are different goals you can pursue:
- identify improvement areas of an existing business flow;
- explore if a new business model is viable;
- gain insight into a shared understanding of how a business operates;
- design clean and maintainable Event-Driven software.
There are three primary levels of abstraction for Event Storming:
- Big picture: used for exploring the current understanding of the system by gathering key people with different backgrounds and creating a shared understanding.
- Process modelling: in this level, we model a single business process from start to finish, clarifying all the business rules and making sure everyone is aligned.
- Software design: in this last step, we start designing the software based on building blocks from Domain-Driven Design and a reactive programming paradigm. Each sticky note potentially turns into a software artefact during the implementation phase.
When applying Event Storming, you first need to identify the Domain Events in the problem domain on a timeline. The source of a Domain Event could be the following:
- A user interaction
- An event coming
- The result of time passing by
- The consequence of another Domain Event.
We then write this domain event down on an orange sticky note.
When all domain events are defined, the second step is to find the command that caused these domain events. Commands are written on blue notes and placed directly before the corresponding domain event. Finally, you’ll need to identify the aggregates within which commands are executed and where events happen are identified. These aggregates are written down on yellow sticky notes.
Using the System Modeler
In the past years, we have embraced Event Storming as a requirements gathering technique within ACA-IT Solutions – so much so, that it’s now an integrated part of our portfolio and how we develop software for our customers. If you’d like more details about that or want to know more about Event Storming, you can contact us here.
The System Modeler uses EventStorming as an inspiration for documenting (modelling) the events that represent business processes, configuring high-level properties associated with those events, then allowing automatic generation of Apps and Collaboration Types from the model.
A System Modeler session involves the use of five virtual sticky notes to represent:
- Event: something that happens in the business
- Reaction: responses to events
- Command: user-driven actions that produce events
- External System: systems that are external to the business
- Issue: document potential problems or unknowns about events
The System Modeler also makes use of one container:
- Bounded Context: contain notes that share a common vocabulary
Below, you can see the result of an EventStorming session in the System Modeler, representing a city’s pothole reporting and tracking system. The model represents:
- a mobile app that allows city residents to report a pothole
- creation of new database records to document reported potholes
- real-time notification of city services of new pothole reports
- enable workers to update the status of a pothole
- real-time notification to the reporting resident when the status has changed
System Modeler is a great way to bridge the gap between the requirements gathering of an event-driven application and the actual implementation. In this case, we’re doing that electronically on the canvas. Moreover, this is a collaborative environment, allowing several people to work on this model at the same time. Using the System Modeler, users can collaborate with multiple individuals not only in a given room, but across any number of geographic locations. This is an awesome way to genuinely do a sort of distributed requirements gathering session. Even more so with the pandemic still preventing lots of people from going into the office!
From requirements to superfast POCs
Based on this requirements gathering session, we can now take this requirements model and create an application. All users need to do is switch from ‘model mode’ to ‘generate mode’ and group the various elements. After having defined topics and collaboration tasks, you just click on the Generate button. This simple action alone generates about 70% of this particular application’s code! This makes System Modeler probably the easiest way to very quickly move from application requirements design into application development itself.
Conclusion
Modern applications need to operate in real-time as they will be driven by what’s happening at that time in the real world. They’ll need to easily incorporate artificial intelligence and IoT technology, and the applications themselves will need to be distributed at the source of the events. The software logic will need to be able to run everywhere (cloud, edge, on-premises). These applications will also require integrating human-beings in the process for when a higher level of intuition and reasoning is needed. With System Modeler, it’s easy to quickly generate a very large portion of such an application. After all, the System Modeler has the ability to gather requirements from business users, domain experts, and developers and very quickly turn those requirements into a running event-driven application. Creating these superfast POCs is a breeze!
If you want to learn more about how ACA Group and event-driven technology can help accelerate your digital transformation, please contact us!
