Snippets of Text

Snippets of Text

200: Focusing on Business Value When Measuring Progress

Event-Driven Architecture for system design simplification and measuring team output through business value delivery

Snippets Press's avatar
Snippets Press
Jul 31, 2023
∙ Paid
Share

Thank you for reading Snippets of Text. Snippets from media about tech, programming, parenting, and more. This is a preview of a post available exclusively to paying subscribers. You can get unlimited access to all articles by purchasing a subscription.

a person riding a bike on a snowy street

Off Topic: Why You Should Adopt Event-Driven Architecture

When an event is emitted, it determines which processors or functions will use it. This allows for decoupling, meaning that apps using the event can change without requiring changes in the emitter. For example, when entering a room and generating an "entered room" event, the light turns on in response to the event rather than a command. In contrast, a command-based approach would involve flipping a light switch to turn on the light. Adopting an event-first mindset is crucial when constructing something, going beyond primary use cases, and comprehending processes and architecture on a deeper level. 

The event-first process supports repeated evaluation and processing, providing a "time machine." It also offers horizontal scaling and a shared language with the business. In this paradigm shift, we discard traditional messaging and send events without API coupling to a remote service. This enables processing events as reactions without the emitter calling on a specific function. It simplifies the architecture and allows for greater flexibility. At some point, we need to go back to basics, back to the first principles of system design, and start again.

Share Snippets of Text

The common element of all these new world problems is that they revolve around the notion of real-time events. It has taken the last 25 years to reach the point where the event is a core system design principle. Throughout that period, much of the world was stuck thinking that remote object calling was the right way of doing things. REST and web services started by exposing the API as a concern, done by a synchronous protocol.

The value of events is that a sequence of related events represents behavior. For example, an item is added and removed from a shopping cart, an error recurs every 24 hours, or users always click through a site in a particular order. Start with the *event* rather than the coupled concept of command. This thinking underpins event-driven streaming systems. A stream of events captures temporal behavior. There are many considerations when evaluating event-driven architecture. Events start as atomic and drive reactionary callbacks (functions). This raises many questions. Is ordering important? Do I want to ensure transactionality? How do I trust the execution? Security? Lineage? Where did the event come from?

The critical realization for adopting event-first thinking is that an event represents a fact. Something happened, and it is immutable, thus changing our domain model. The other consideration is that circumstances do not exist in isolation. Due to their very nature, an event tends to be part of a flow of information, a stream. We define a stream as an unbounded sequence of related events associated with an "eventKey," a key that ties many events together. Applications must run with 99.999% uptime and be superelastic, global, and cloud-native. This is where event-driven architecture (EDA) comes in.

Implementing Domain-Driven Design by [Vernon Vaughn]

Current Work: Focusing on Business Value When Measuring Progress

In the Software Engineering industry, progress is measured in various ways. Yet, the most common method is through story points, which assess the effort put into a task rather than the time taken. Focusing on time can lead to the team prioritizing low-value tasks to complete them within the sprint. This approach must be more accurate as the primary focus should be delivering business value. The only proof of progress is working software, not any burnout chart.

Thanks for looking at the free preview of Snippets of Text. Please consider subscribing to the paid version if you find my work helpful. This way, I can spend more time developing new ideas to share with you.

Keep reading with a 7-day free trial

Subscribe to Snippets of Text to keep reading this post and get 7 days of free access to the full post archives.

Already a paid subscriber? Sign in
© 2025 Rafael George
Privacy ∙ Terms ∙ Collection notice
Start writingGet the app
Substack is the home for great culture