During one of our Archers Knowledge Days (AKD), a discussion started on the following topic: events are essentially no different from “regular APIs” and should therefore be managed in the same way.
This sparked a huge controversy. We quickly realized that we wouldn’t solve this “dispute” right away. So, we organized a follow-up session to get to the bottom of it.
I am in the non-API camp and will explain my perspective. However, it’s not a black-and-white issue—stay tuned for a plot twist at the end!”
To make my argument, we need to go back to the origins of the term API – Application Program(ming) Interface. A quick search shows that the term was first introduced in the 1960s, in the context of a graphics program. This program provided an easy way for other system components to access its functionality. The application (graphics program) provided an interface so other programs could interact with it.
The reason engineers created this interface was to shield users of the graphics program from the complexities of the graphics subsystem it controlled. In other words, it served as an abstraction layer.
Now, let’s consider if and how this applies to events. As mentioned in one of my previous posts, events are primarily used either to propagate data (EDI) or to signal an important “milestone” (I am avoiding the term event) in a business process.
Case 1: Events to propagate Data
Depending on how this is implemented, the source system generates events whenever it wants to communicate that the state of one of its objects has changed.
One could argue that this is functionality – the system provides information about state changes. There might even be some level of abstraction, as the system could transform its internal data model into something more useable.
However, in my opinion, the most critical element is missing: an interface. The purpose of an API is to allow others to request the program/ or component to perform an action. In this case, the program is acting without being prompted. The only “interface” available, is the mechanism that interested parties use to retrieve the information, typically via a queuing mechanism.
If I try to find an analogy with the example that introduced the term API, the graphics program, as part of a larger system, might have registered itself within that system. If another program in the system queried the registry for a list of active programs, it would discover the graphics program. As you can see, this functionality is not part of the “API” of the graphics program – it’s simply a feature that comes “for free” because the program is part of a larger ecosystem.
Some might argue that the event itself contains the API or behavior. For example, data events could carry information about whether an object was created, modified etc. While this is true, it’s not behavior-it’s state. This state allows others to act accordingly. It is the other system that modifies its behavior based on the state it receives.
To me, this is similar to log data containing correlation IDs, which allow reporting tools to group certain logging information. The functionality of ‘logging information’ is part of the program or component, and sending these ‘log data’ is not an ‘API.’ It is simply standard functionality that is an integral part of the program.
Case 2: Events for process automation
The case is even clearer for these kinds of events. The purpose of these events is to automate some sort of process. However, the component creating the event is not even certain if it will ever be used or what functionality it might trigger. Therefore, there is no functionality being exposed and no interface- it is simply a standard feature of that particular component.
In many enterprises, when performing database manipulations, fields like “last update/created timestamp/user” are automatically registered. For example, a customer component might expose functionality to create a customer. Automatically, the user performing this action is logged. This is not an “API”. The API exists for creating the customer. Logging the user is merely part of the functionality -it’s a feature, part of the abstraction.
In my opinion, the creation of these events should also be seen this way. The events generated by the component are not exposing an interface that allows others to trigger some specific functionality for which the component was created.
If I were to provide a non-IT example to illustrated this point: imagine a reception (the component/application). There are tables, and on each table, you’ll find some finger food- chips, olives, cauliflower, etc. (a feature/events). It’s just there for everyone to use as they see fit-usually eating it. However, as any parent knows, children might use olives to shoot at each other. On the other hand, if you want a drink (functionality), you need to signal a waiter (interface) and ask one, which the waiter then provides.
Conclusion:
An API is a way for other components in a system to trigger functionality provided by a specific component. It is a technical mechanism that allows others to say, ‘Can you please do XXXX for me?’ None of these conditions are met with an event:
- An event will never trigger functionality within the component that created it. (Functionality)
- Others do not need to ask a question; the event simply exists. (Interface)
But……
In an ideal world this is where the story would end. However, we all know we don’t live in an ideal world. We live in a complex world with different stakeholders: commercial companies, standardization bodies, influencers etc. In this real-world context, the term “API” holds significant value (it sells well). As a result, the term “API” is being, and will continue to be, used in the context of events. Examples include the Async API specification, Unified API management concepts from Gartner, and API management vendors.
So, even though I believe an event is technically not a “pure” API, the world- and we- will still refer to it as an API.
ALWAYS LOOKING FORWARD TO CONNECTING WITH YOU!
We’ll be happy to get to know you.
