The value of Event Sourcing

I honestly feel obliged to write this article because I feel that most developers think about Event Sourcing as only another PoEAA (Pattern of Enterprise Application Architecture). Maybe reserved to software models which have a certain level of complexity or at least they need to look like they do so that the time and cost is justified. Event Sourcing is a lot more than just an architectural choice. Its utmost value is in the data it preserves.

What is Event Sourcing?

As aforementioned, essentially, most of us think of Event Sourcing as just a pattern of enterprise application development. I don't agree with this description, at least not by itself because Event Sourcing can, and is, applied to several types of applications, enterprise and otherwise. The call logs on our mobile phones are persisted as events as much as most customer transactions are within a CRM (Customer Relations Management) application.

Why is Event Sourcing so important?

Since things happen, store the fact that they did. Don't throw this information away because even today there's an application where this information is useful and tomorrow, well, there will be a lot more.

When to apply Event Sourcing?

Does this mean that we should apply Event Sourcing to every application? The brief answer is Yes, we should. The longer answer is; apply Event Sourcing whenever you afford to or, even better, think about it in reverse. When should we not apply Event Sourcing? The answer is even simpler; don't apply Event Sourcing when you afford to lose the data your application should store but is throwing away. What you don't store today will not be available tomorrow and I'm sure that you will need all of it tomorrow.

I believe that the two primary reasons why Event Sourcing is not applied as much as it should be are due to; one, lack of knowledge of how to apply it in an integrated system and two, the additional work involved in applying this pattern. None of these reasons justifies the loss of information and both of them can be easily mitigated. Knowledge is available and most of the additional work involved can be reduced and almost eliminated by code file generators and infrastructure frameworks. Even if you create both the generators and the framework yourself on your own, these will be reused over and over again. In most part, it's a one-time investment.

Planning and applying Event Sourcing is relatively simple. In my opinion, the modelling of an event sourced domain is far simpler than that of say; a Domain Driven Design (by itself), not to mention a Data Driven Design 🤣. The reason is that if we think about any given problem in forms of events, we are then very close to the real-life application of the said problem. It is easier to think about software through the lens of the real life domain than an algorithm or some other form of process logic.

Machine Learning and Event Sourcing

We've already established that event sourced data is by far more valuable than any other data which might be out of context. It's also a fact that Machine Learning attempts to, and most of the time successfully manages, construct algorithms that make predictions from data. The data captured within a well-planned event sourced model replicates the real-life process a human or any entity follows. Feeding this accurate data into a Machine Learning algorithm(s) will result in extremely useful predictions.

We don't even need to imagine a scenario were to apply this, as many already exist, but take this a few steps further and connect every input device to an event store; the result can be used by numerous machine thought applications such as health and psychological diagnostics. Connect your favourite IDE to an event store and you might even end up with automatically developed software applications.

Machine Learning is in fact quite basic, yet incredibly accurate and powerful. The only missing link is the data we throw away every day by using damning software models and persistence architectures. This waste of information is the cause of delay for several groundbreaking innovations, cures and overall life improvement.

As I'm writing this post, YouTube is auto-playing music and for some reason, it's playing some relaxing Jazz & Bossa Nova, a genre I would never choose but one which fits perfectly with the work at hand. Thank you YouTube, I appreciate the selection. The machine thought music selection is great, but, I'm sure we can find more useful applications for Machine Learning. Let's do out part and start with not destroying vital information because tomorrow, next week or next year someone (or something, hint hint Elon Musk) will make great use of this data.

Artificial Intelligence is not so artificial

I really never liked the term Artificial Intelligence because what's artificial about say for example Autonomous Cars? The car is physical, it drives by itself, as in, it physically and not artificially produces kinetic energy from a different energy source and a software application guides it to a destination along a certain route.

Just a few years ago, we would refer to Speech Recognition as Artificial Intelligence, which made sense at the time because the assistance and support provided by those extremely stupid and annoying IVR (Interactive Voice Response) systems were artificial. Now, a lot of us use Speech Recognition without even thinking about it. I utter "Okay Google" to my phone's microphone more than I say "Hi" to real people on any given day. I don't think of this technology as Artificial Intelligence and most probably you don't either. I think the consensus is that when a Machine Learning project is still in its ambitious phase we refer to it as Artificial Intelligence until it becomes a part of our daily lives when then it's just, well, intelligence.

Machine thought applications from captured events' data is not artificial at all. I mean the CIA (Central Intelligence Agency) uses Machine Learning algorithms every day. Should we start calling it the CAIA (Central Artificial Intelligence Agency)? 😊

Final thoughts

The main points I wanted to put across in this article are:

1. Event Sourcing is extremely important not just for ease of modelling a domain but even more for the data it captures.
2. Event Sourcing is a means to an end and the end is Machine Learning.
3. A machine thought application from a stream of captured events is definitely not artificial intelligence. It is based on real-life occurrences, not artificial ones.