The gap between ‘the business’ and IT has plagued organisations for decades, and nowhere is this more noticeable than in software development. When developing an application, differing priorities, personalities, and most importantly domain knowledge can prevent technical and business teams from coming to a common understanding. Generally, problem definition and solution design are undertaken in isolation, as both teams struggle to find the language to bridge the knowledge gap. Because of this, developers frequently lack a true understanding of the problem, and business teams foster unrealistic or incorrect expectations.
The result of this is often software that doesn’t solve problems. To help bridge this gap, we have been using Event Modeling in some of our recent client engagements. This is a relatively new modeling framework that aims to allow all stakeholders involvement in the process of creating a new product. By enhancing the collaboration aspect and allowing easy visualisation of the problem, Event Modeling can contribute to a more successful product development, as I have witnessed in my engagements with a large Australian freight company.
How does Event Modeling work?
Event Modeling works mainly because its core concept is very simple; the model is centered around events across a timeline. These events reflect core business occurrences that the application will be involved in; see an example below of events for the Client I’m working with currently:
These events form the steel thread around which the rest of the application is built. An important step is determining the very first and very last event: these will set limits on the timeline and set the scope of the application. Here the focus is more on the ‘what’ and ‘why’; unlike the ‘how’, these are questions that stakeholders who lack technical knowledge can contribute to, including SMEs and non-technical people (eg. can a customer cancel a booking? Can a customer pay with credit card?).
Once the events are determined, other details can be added around them to answer that question of ‘how’ – for example, ‘views’ and ‘commands’ form the input and output to the system – but always within the context of the timeline and its events, as shown below.
Keeping the conversation relevant for different stakeholders
One of the main advantages of Event Modeling is that it enables complexity to be captured in a relatively simple way. Though the process of paying a fee may be highly complex, involving multiple technologies or systems, that detail remains associated with an/several event/s in the timeline and thus within context. You now have a story, which acts as a boundary for discussions; if the conversation gets too technical, a business user can simply skip over it and focus on the next event; if a technical person needs to consider detail, they can slot it in between and still see the bigger picture.
By outlining information systems by events over time, Event Modeling exploits the natural way the human brain remembers and visualises information. The modeling notation is simple enough for all parties to understand, unlike previous alternatives such as BPMN, which requires a certain level of technical literacy. This is a major win for communication: almost anyone can contribute and see a high level representation of the process and the problems.
With the Freight Client I mentioned above, Event Modeling allowed the subject matter expert and the Business Analyst to provide a detailed explanation of the process to the master model, where everyone could see it and understand. The product owner could then determine whether the cost and effort were justifiable, and the developers could get a full understanding (within context) and clarify with others where needed. This was a marked improvement on the broken communication chain that COVID-19 had left in its wake, where each stakeholder was working alone at home and passing it along, leaving developers with only a partial and fragmented understanding.
When to use Event Modeling
As with any tool, Event Modeling should be used where it can be most effective and with situation and goals in mind. It is most commonly used for line of business system automation; having a shared understanding becomes more significant here, as this is an area with high complexity and various actors involved. It can also be helpful as a brainstorming exercise, and where complex situations can be analysed by using ‘real life’ examples and events to aid stakeholders’ contributions.
Event Modeling is not, however, a good fit for companies with strict hierarchies and ingrained ways of working. Nor is it a concept that will be easily embraced in a BAU environment. It presents a fundamental change in the way organisations usually work, and though collaboration may be critical in one situation, the efficiency of siloed workers or hierarchies may be more beneficial in another.
With the Client above, I experimented with Event Modeling in small innovation projects and found great success. However, I faced considerable challenges in applying this on a larger scale, until unprecedented changes and new challenges occurred due to the COVID-19 pandemic. With the usual communication channels broken by work from home and other restrictions, the Client looked for new ways to work, and started to use Event Modeling in larger projects. It has been extremely helpful in rebuilding team collaboration and communication across the project, despite a separated and disrupted workforce.
Considerations such as these are critical; far too often in the technology space I see tools used for their excitement factor, rather than in use cases where they are most effective. As the new normal emerges, we may see a return to more ingrained, archaic systems, but the result of this disruptive period may be that there is a place for ideas such as Event Modeling to thrive and bring new value to businesses.
