How to implement Event-Driven Architecture

You’ve heard about Event-Driven Architecture (EDA) on your journey to event sourcing, read the blog posts, and watched the videos. You’re positive it would help your business achieve more. So, how do you go about implementing it? This page gives you some useful advice on how to implement EDA and affect real change in your business, maximizing your investment in your technical architecture. 

Information you will need

First things first, gather your resources. How about this post on the 10 problems Event Sourcing can solve? Or this one on convincing your CTO? Have your evidence ready to go for any skeptics you encounter. 

No matter what your current situation is, implementing EDA will start with looking at the boundaries of your system. The boundaries are the clues as to where your messages will go and move through your system. There are several tools to start this process, including Event Modeling or Event Storming. You can use these tools to map out the flow of business decisions and data and allow you to model a system that matches the business (Domain Driven Design). Mapping out the business processes in this manner takes time and input from the wider business, but the payoff is worth the effort in the beginning.

Misconceptions to combat before you start

Users are used to screens where they enter 20 different points of data, then click save. Think about any web form you’ve ever filled out. You complete the fields, then hit ‘Save’. the button becomes fainter or the wheel spins, then you have some kind of confirmation it’s been saved. Dopamine triggered and received. Current User Interfaces prioritize responsiveness and usability over functionality (for example, it’s much easier to find information on how buttons should look on Apple apps rather than how they work). 

Unfortunately, event-driven systems may not translate well to functioning as a UI. As modern UI designs hide the complexity of the system behind pure white (or grey, if you’re in dark mode) screens, users do not see how systems work and how their data is saved. 

When thinking about EDA, you have to think about the tasks performed in the systems. Clicking ‘Save’ isn’t an action in this context. The actions leading up to clicking ‘Save’, such as entering the data, are the actions. Consider the difference between ‘Save’ and ‘Check Out. For systems, ‘Save’ writes data to a database but ‘Check Out’ starts a whole new process; receiving payment, checking stock, packaging, etc. These are a reaction to the ‘Check Out’ event. 

This is the kind of thinking you have to consider when implementing EDA. Every business process needs to be thought through as a digital event, leading to the next one or (where necessary) looping around to a previous one. 

Build your UI based around the tasks and events, rather than the screens that need to be filled out. Make sure the complexity of the system (that the information is saved to a database and then pushed out to a queue) is hidden from the user, so they can focus just on their task. 

When you get to the right stage of the project, try giving some trusted users a demo version of the app you’re building to play with, so they can understand how it works. 

Operations are your friend

Projects can sometimes be completed by Developers, then just handed over to Operations with no formal support. Take some of the Ops team within you on your journey to help understand EDA. This will help them understand how the system works and will help the support products built on the architecture in the future. This has been introduced early in this guide because it’s better to get the Ops team on board early.

These three steps are part of building awareness, intent, and a culture of EDA in your company. Internal company support is vital and can mean the difference between success and delayed success with EDA (you will definitely succeed!). Operations may even be able to help you with the next step of this process…

Find the right starting point

If you have made it this far, there’s a good chance that you have a project in mind to start with. You need a quick win to keep the momentum you’ve built up. Is there a project that would help remove a pain point from some users? Or something that would make a big impact with little work? Stakeholders from business or Operations may be able to help you identify the right project to start with.

Taxonomy

One thing you need is a universal language describing the workflow and events. Getting this part right is one of the most important aspects of the project. A good taxonomy will essentially design the event flow. Create this from discussions with business stakeholders, using the previously mentioned Event Modeling or Event Storming. Make sure every event is in the past tense, as the events are recorded after they have happened (InvoiceSent, PaymentReceived, etc). Modeling your data on the processes of your business has value across all departments. Take your time and get this right!

Create the flow

After Event Modelling or Event Storming with your business stakeholders, you should have a perfect map of the business processes morphed into technical processes. If it's not perfect, go back and do it again. 

From this map, you can pick out an event ‘flow’ that will give you a quick win: something you can implement easily, quickly, or for a big impact. It would also be helpful to make this the reference point for the future, allowing you to reuse events or even parts of the event flow for the future.

Go forth and multiply

Once you have the first flows created, you can begin to create an event mesh following the Event Modelling/Storming map. By uniting the event flows and creating the event mesh, you will start to build up your pilot project. Building up the project should allow you to demonstrate your quick win.

The virtuous circle

From these basic flows and your quick win, you have created the template to create further event-driven areas of your system and expand it as needed. Keep making more event flows, and more event systems, that feed into each other and create a virtuous circle of growth across your architecture. Make sure it aligns closely with the Event Modelling/Storming maps, and that the business stakeholders, including Ops, are included and happy. 

These basic steps for implementing EDA should help you move toward an event-based system and create future-proof, scalable systems that maximize the investment in this project. 

If you’d like to know more, watch the webinar by Chris Condron on Data Modeling in an event-centric world for an in-depth explanation.