The business case for event sourcing

At AxonIQ, we work with a lot of organizations that have built applications using Axon Framework and the majority of them use event sourcing (the framework leaves that choice open). Although event sourcing has clear technical benefits, our observation is these are not driving it. It’s the business benefits. Let’s have a closer look.

What is “event sourcing”, exactly?

A twelve year old but still accurate definition is given by Martin Fowler. Quoting from that page:

"Event Sourcing ensures that all changes to application state are stored as a sequence of events. Not just can we query these events, we can also use the event log to reconstruct past states, and as a foundation to automatically adjust the state to cope with retroactive changes."

Contrasting this with the notion of “event-driven architecture” (EDA), it should be clear that Event Sourcing is a lot more specific: it not only promotes the use of events, but it demands that events are the only way to change and store the application state. Event Sourcing is Event-driven Architecture taken all the way to the storage level. EDA can be implemented without doing Event Sourcing. But a system using Event Sourcing would by definition exemplify a form of Event-driven Architecture.

Given that ES is a storage strategy, it is often seen as an alternative to traditional Create, Read, Update, Delete (CRUD).

Let’s also consider something which is not part of the definition: domain-driven design (DDD). Although there are some good reasons why they are frequently used together (more on that below), they’re conceptually and technically unrelated. DDD can be practiced with or without ES, and ES can be implemented with or without doing DDD.

The essential resulting difference between ES and non-ES approaches is that with ES, the events give you full information about the history of the system in addition to the current state, whereas non-ES approaches primarily store the current state (and secondarily may produce log information to represent some aspects of history).

Business value of historical data

The first business reason for implementing ES is actually really simple: historical data is valuable. So reversely, not doing ES, and therefore forgetting historical data, may destroy value.

Zooming in on this, we see that the value of historical data manifests itself in broadly two forms:

History of individual data records. Being able to reconstruct exactly what happened in a particular case has lots of value:

• It helps to implement the accountability required by many compliance frameworks (like GDPR Article 5.2). (And in some case, verification of compliance may be automated, looking at events.)
• When ending up in any type of lawsuit (compliance-related or not), it is very useful to have access to a full, reliable audit log of what happened to substantiate your case.
• When dealing with a security incident or fraud case, being able to see what happened makes all the difference in getting it resolved as painlessly as possible.
• Outside of the legal/security space: It will make incident management for a system much more effective and efficient: when a customer reports a problem, the helpdesk will be able to know exactly what happened and further support tiers will be able to reproduce the situation. Which in turn will reduce costs and create happier customers.

History of the collective data records. There’s a lot to learn from looking at past data. This knowledge can be used to optimize your business going forward. This is the core idea behind analytics, machine learning, data mining, process mining and the like. But the following is true for all these technologies: they can’t operate on data that isn’t there. Using ES ensures that you keep all historical data which will then always give you the option to start using some new data analysis solution and use it to look back at past data as well.

Let's illustrate this with an example. Suppose you're operating an e-commerce system with a CRUD based order module. At some point, you may ask yourself the question: how often does it happen that customers put items in their shopping cart, but remove them again before checking out? In the CRUD system, you ordinarily wouldn't have the information required to answer the question, unless it was explicitly known beforehand that this information would be relevant and logging of the removal event has been included. By contrast, in an ES system, you can always answer such questions about the past, even if didn't know you were going to have that question, because all history is available.  

Software matching your business processes

In addition to this value-of-historical-data argument, there’s another solid business reason for doing ES: Events are a very natural representation of business processes, and therefore ES systems are likely to be more valuable. Many of us (especially techies) have been educated in and worked with databases and CRUD operations to the point where they feel natural and ES feels somewhat weird and convoluted. But actually, looking at it without an IT background, if you would ask anyone to describe their business processes, you would hear a language of events: “if this (event) happens, then this (event) should happen, and a result (event) happens”, for instance.

An example of this (admittedly somewhat abstract) argument is the representation of intent. A classical example is this: in a CRM system, a customer address may need to be changed either because it was wrongly registered, or because the customer actually changed address. In a non-ES system, both would probably be represented as the same update on the address. If the business later wants to do something with the difference (trigger a certain response, perform analysis), this would require changes to the program and past data wouldn’t be available. In an ES system, it would be very natural to make that distinction from the beginning and therefore record it. That ES system would provide more value to the business.

Conclusion

Event sourcing is enjoying increasing popularity. That’s caused by some clear business drivers: historical data is valuable, both considered per-record and considered as-a-whole, and it helps to create systems that have a better business fit. The trends fueling it (compliance pressure, big data) are still growing. As a result, Event Sourcing will become even more popular. It’s not just a technical thing. If you are looking for a business case while using Axon, feel free to reach out to one of our developers or trainers or share your contact details with us in one of our forms or by using the chat function on our website.