Interview with Event Modeling Founder - Adam Dymitruk

The "Event Modeling Project" advocates a new way of approaching system design by using the concept of time and events as core concepts to describe a system. The language/constructs proposed by the project aims to communicate how systems work across the largest possible cross-section of roles within an organization.

The purpose of the project is to offer a clear and repeatable modeling pattern for applications wanting to develop applications keeping Events as the centerpiece of the architecture.

To learn more about the Event Modeling project as a whole, InfoQ spoke with Adam Dymitruk, the founder of Event Modeling and CEO & founder of Adaptech Group.

InfoQ: Thanks for joining us Adam. So, how did you first get started working on Event Modeling?

Adam Dymitruk: Event Modeling was born out of the need to make software development - especially in the enterprise - to be more like an engineering discipline. The industry gave up on design in lieu of agile when the case was made against onerous RUP and UML as the only "proper" way to design and architect information systems. This caused a lot of damage. The right answer was still to design systems but not do it in a way that was expensive as we had with UML, RUP and related practices. By correctly and efficiently collaborating about state and user experience, all problems in software development that either the onerous or superficial previous attempts created were now gone. We now had an effective blueprint like engineering disciplines had.

The other motivation was the need to tap into the way the human mind works naturally for any imposed process or methodology, and that's to embrace the way we remember things best: as stories. An event model when interpreted from left to right gives you a story much like a movie storyboard - and it looks very similar to one. Below is the plot and above are the key frame for the scenes.

Collaboration was also something that wasn't being done effectively enough in the industry. Event Modeling allows people from multiple roles in an organization to collaborate together about the system. So this required a simple, common set of elements that didn't favour any specific role over another.

InfoQ: How does Event Modeling compare to traditional approaches for system design?

Dymitruk: Event Modeling allows a very important shortcut that traditional systems design disciplines don't allow. Event Modeling removes the need to describe "how" a system is implemented. You won't find diagrams that show classes or methods. There are some similarities. Some have called it the "horizontal sequence diagram for entire systems". The horizontal swimlanes in Event Modeling look like the vertical class instance lines in sequence diagrams. But that's where the similarities end.

Event modeling ensures:

• No branching in logic in the workflow. This ensures we keep a story mindset.
• No technical implementation artifacts like classes or methods.
• Focuses on events as the source of truth - whether the events end up in the implementation is up to the implementation.
• Information and workflow are the anchors onto which other concepts hinge - as opposed to classes and system boundaries or other IT-specific concepts.
• It automatically creates multiple models of the same data for the purposes of reporting - a lot different than the 3rd normal form that we're used to in our entity relationship diagrams.
• It's one blueprint rather than a collection of pages, diagrams or other artefacts. This makes it easy to find anything that is needed at any point.
• UX/UI is a primary concern. The screens are a core part of the system as it also addresses the needs of people who are more visual than analytical.

InfoQ: Can you explain in a nutshell the business and technical benefits of Event Modeling vis-a-vis traditional approaches ?

Dymitruk: The event model contains independent units of work (slices). This allows not requiring stand-ups, sprints and many other processes that are not effective with remote work. These saved hours are reinvested in working on implementing the solution. The transition to remote work is not even felt with the guidance event modeling brings.

Because the patterns are prescribed, event modeling takes the guesswork out of many aspects of writing software. The design allows a fixed and flat cost curve where the complexity of the system doesn't make a project end in a "death march".

Event Modeling is simple. Whether you're looking at BPMN or UML, the traditional practices for design are incredibly heavy. The main benefit is that you can get the same value for a much smaller investment of time to create a blueprint for how your current or potential solution works or will work. The goal is to sweep aside the mountain of books and get on organization going quickly. It takes 15 minutes to explain Event Modeling.

The other main benefit is having a reliable plan to start implementation. Most new projects in software today head into starting development blind. An important test that the event model provides is that it shows if you are "information complete". This means you can connect all the example data in the model identifying where it came from and where it's going to. If you can't do that, you know you have an incomplete design and therefore any guess at an estimate is most likely too small.

InfoQ: What are the main building blocks of Event Modeling ?

Dymitruk: At the core, events (yellow or orange boxes) and screens (mock-ups or black and white wire-frames) are the main building blocks. In fact, that's all that's needed to do Rapid Event Modeling when you need something reliable, fast. More completely, commands (blue boxes) and views (green boxes) are part of the complete event model and are used to denote the input and output points in the workflow. These are arranged on a timeline, with example data and into swim lanes to show different actors, sub systems and other concepts in your workflow. All information reference is forward only so it has a similarity to git log history - the "directed acyclic graph".

These building blocks are arranged into four patterns as needed:

• "Input" or change of the system as instructed by a user, for example.
• "Output" or information provision by the system and requested by a web page for a user, for example.
• "Automation" for automatically initiating interactions with external systems like payment gateways, for example.
• "Translation" for receiving data from external systems like an incoming order from a partner company that you integrate with automatically.

All of these decompose into interactions between UI->Command->Event->View-> and back to UI. This cadence is important as it gives predictability and hence gives the best shot we have in software at reliable estimates. We get high numbers of implementations of these and from that we get a very reliable velocity.

InfoQ: How does one go about the process of incorporating Event Modeling ?

Dymitruk: If your organization has a new service they want to implement, have a team read up on Event Modeling and spend a day making an event model - it's a very small investment compared to other practices. The team members can quickly teach others and lead these modeling sessions across the company. Because you don't need to read a thick book on it, it will be one of the easiest disciplines to incorporate in your organization.

Usually an Event Modeling session can be broken down into seven steps for a new system:

1. Brainstorm all the possible events (things that can happen in your business).
2. Arrange those events on a timeline and determine if it makes sense; imagine you already have the system and you are looking at the facts captured during a year of operation. Remove events that don't make sense and add any that may have been missed.
3. Add screens, mock-ups or wire-frames above the row of events to show what the users of the systems see along the way. If you have a lot of back-end processing, use dashboards and reports as stand-ins to show what is going on to an admin or operator. Make sure to leave enough space in between for the next two steps.
4. Join the screens with the events by adding commands in each place that a user is responsible for changing the system. If it's something that's done automatically, use an icon like a robot or gears and have that issue the command.
5. Join the screens with the events by adding views to each place some information is presented to the user. These views will usually be connected to multiple events.
6. Arrange the screens into swim lanes to show which user sees which screens.
7. Arrange the events into swim lanes to show the sub-systems that the solution will have.

A sample of the Event Modeling process for a Hotel Reservation system is depicted below.

InfoQ: Can this process be adopted for existing legacy systems or traditional state-based systems?

Dymitruk: Yes! This is the latest effort to bring the process to the rest of the world that isn't doing event sourcing yet. You can elaborate how the rows in your tables change. It's the insight that Fred Brooks (author of the Mythical Man Month) had a long time ago. The tables tell you all you need to know. So you include that in the event model. You still keep events, but they are not stored in the system as you describe them. But they capture the truth of what happened in a user-centric way. The event model can then be used as a reference for finding the coupling points in the system with key context as to when these couplings play part.

Event Modeling can be used to show how you can start to treat the legacy system like a black box and evolve it by building a side-car solution. This is done by not opening up the code for the legacy solution but by looking at the database and adding compensating actions. There are other details to this but it makes dealing with a legacy system you inherited a lot easier to administer. No more walking on eggshells because you don't know what a line of code you introduced in the legacy code base will result in.

InfoQ: What resources are available to help learn Event Modeling?

Dymitruk: They are listed on the Event Modeling website: EventModeling.org. There are two main articles written by me looking at event-sourced projects and traditional projects. There is the slack group that's on the resources page. There are lots of members of that community ready to help you. There is also the Event Driven Meetup that meets twice a week.