Historically, we have always thought about systems in terms of things or the nouns that the system incorporates. Thinking about the events that happen, their causal effect and the reactions to the events naturally surfaces the nouns participating in the event. One of the criticisms of older styles of design is that we start architecting a data model too early, before we have understood the interplay of the things within the system. Let’s have a look at what is Event-First thinking.
What is Event-First thinking?
Business Event Analysis Modelling has been used in Data Warehousing for some years as a better methodology for surfacing agile start schemas. Lawrence Corr and Jim Stagnitto describe BEAM in their book Agile Data Warehouse Design. They refer to the 7Ws as a means to understand an event dimensionally.
7Ws as a means to understand an event dimensionally
- Who? – People and organisations
- What? – Things e.g. product or service
- When? – Time
- Where? – Locations
- Why? – Reasons and causality e.g a marketing promotion or weather
- HoW? – Transactions ID and status codes
- HoW Many? – Measure and key performance indicators
-Maybe this article will interest you: When and why should I adopt Event-Driven? –
It’s a great way to surface things, events and the event story. Event storming (Alberto Brandolini) is a more application development specific workshop-based method of deriving the story of events within a system. Event storming is tightly tied to domain-driven design where domain models are created to represent business domains and sub-domains. Without going into detail, we can think of it as breaking the problem down into far more manageable chunks. The event storming method helps us to surface that information and is a core consideration for anyone looking at adopting event-driven.
For the CIO or IT leader, you can start to position event-driven in your organisation if you start to think about the systems you provide as supporting events that happen in any given functional area or process. You can start to look for value in the events that drive the transactional outcomes your current systems support. When we think in terms of ‘if we could do X better’, the events that represent the behaviours that make X manifest can be very valuable in any quest for improvement. This may well highlight opportunities in the organisation to deploy or take an event-driven approach.
One thing we learn from BEAM in dimensional modelling is that the event-driven approach yields a far more flexible data model. Historically, data warehouses become unwieldy because they are often reverse engineered from a set of reports the business needs. They are a response to a very specific set of questions. When we focus on the events that occur within a business or functional area we end up with a data model that is capable of responding to any question the business wants to ask about what it does. When the business is able to get it’s initial questions answered, it is often the questions it is able to ask after that that yield the real insight or value.
The same is true for an event storming approach to system design. In focussing on events that occur, their causality and the reactions to them we end up with something far more flexible than we had with more traditional approaches to application design. The value of those events often gets magnified later in the journey when we have met our initial application needs. We shouldn’t necessarily expect to see that from the onset and we should ensure the value statement at the beginning stack up before we invest. If we sell a promise there’s a fair chance we may end up breaking that promise. Think big but see it as upside as your event-driven journey progresses.
If you want to know how Chakray can help you to adopt Event-first thinking, then contact us!
