Event Driven Integration: The Event API Economy

Among the many activities that have underpinned the evolution of human civilization, two come to the forefront:

• Getting access to resources
• Communicating

Resource access has almost always been a synchronous operation, requiring humans to actively get involved in each activity: whether it was mining, or quarrying etc. Conversely, communication has always been an asynchronous operation, where there was some type of an exchange; there was either a one-to-one conversation or one to many, in a public, forum setting. As the distance between human settlements increased, remote communication became essential. Letters and the mail service transformed communications. Over time technology, would enable the delivery of information in a variety of new ways and in real time.

Both communications and resource access used an “interface” to optimize the interaction. The interface was a way by which one could reduce the amount of work required; it generalized the activity, and decoupled the producer of a given service from its consumer! In the digital realm, the interface became known as the API.

Let’s have a look at a few examples of some of these interfaces/APIs. Below are a few examples of the resource access APIs:

• The wall socket allows you to plug in any electrical device without caring whether the power generated is hydro, nuclear coal, or solar.  On the consumption side, you can plug in any device (computer, hair drier, dishwasher etc.).

• The radio allows you to tune into the right frequency to access the channel that you care for, without caring who produced the content

A few examples of the communication interfaces are:

• The telegraph was the first form of remote text-based communication
• The telephone was the first remote voice-based communication

As a natural form of technological evolution, the mobile phone (the epitome of API evolution) enables both resource access and communication (text and voice). It also points out how intertwined the two approaches are i.e. an incoming notification can lead to the taking of action on a given resource, or conversely, the change in a resource will elicit the generation of a notification to a selected consumer/subscriber. In essence, communication is the “glue”, that makes everything work! Whereas money is the lifeblood of business, communication is its “nervous system”!

RESTful APIs have been the foundation of modern resource-based interfaces. Today almost every aspect of the digital landscape includes REST APIs. They simplify access to digital resources and enable the creation of a wide array of applications and services. REST APIS have essentially become the foundation for a whole new type of digital economy.

On the communication side of the fence, along with the evolution of “social communication” (from letters to video conferencing), event and streaming platforms have also evolved in parallel. However, unlike the way enterprise assets and services were unlocked by RESTful APIs, to create a powerful “public” digital economy, the event-based platforms have remained locked inside the enterprise.

Although in recent years we have seen the rise of the AsyncAPI specification to describe event APIs it has not yet risen to the level of adoption that its REST counterpart has. It is time that changed! There is a tremendous opportunity in opening the enterprise eventing platforms for public consumption. Event Streams that can be used to enact real time decisions, and help detect threats or opportunities are ripe to become the foundation for a new type of digital economy: the event API economy. The event API economy complements the current REST API economy, and it amplifies its impact. Together the Sync and Async worlds create a holistic digital landscape that will drive a new set of capabilities, businesses, and experiences.

In this article, I will explore how the event API economy can impact the digital business landscape and what benefits it will bring.

What is an API Economy?

As indicated in the introduction, APIs have opened up a whole new set of options on how to commercialize digital assets. There are three key aspects that made APIs become so prevalent:

• Discoverability – Ease of on-boarding for API consumers through API Catalogues and public portals
• Ubiquity – APIs can be invoked form literally any technology platform (e.g. mobile apps, web apps, devices etc. )
• Connectivity – APIs can invoke each other thereby creating an incredible set of possibilities; APIs can be used to aggregate information from other API and/or delegate execution to other APIs, and/or extract information from any digital resources.

It is these attributes that have actually constituted the foundation of the API economy. APIs as building blocks for composite digital offerings. This is best illustrated through some examples.

Probably one of most representative examples of the API economy reach is Uber. Uber’s model would only be possible because GoogleMaps APIs were exposed and allowed Uber to leverage them to create their ecosystem. The add-on value to this example is that airlines like United Airlines embedded the Uber APIs into their own online experience, allowing people to book an Uber when they land at a given airport.

Along a similar path, and for the sake of diversity, let’s imagine that you are a Lyft customer (using same GoogleMaps API as Uber). You would use your Amazon Alexa to book a ride with Lyft. You can then use your mobile phone to see the status of the ride, and the driver of the car can verify that it is you who ordered the ride when they pick you up.

Similarly, Slack APIs are embedded and integrated into a wide array of 3^rd party applications and solutions to make enterprise collaboration seamless, and Airbnb has done the same for booking properties. There are an inordinate number of examples out there of how combining various APIs together can result in a whole new set of applications and experiences, that can open new business channels and create new forms of revenue. In short, the arrival of APIs in the public domain, has allowed for the creation of a whole new business model, and drove customer engagement and experience to a whole new level.

APIs have essentially made innovation easy; they have enabled enterprises to become more “composable”. API catalogs (that most enterprises expose to 3^rd parties) drove asset visibility which in turn lead to a higher degree of reuse and eliminated duplication of work. Furthermore, this enabled the ability to rapidly “compose” new applications from existing APIs, and this led to a faster time to market, the capture of new market segments, and new sources of revenue for enterprises. This ability of enterprises to “band together” and share their APIs with each other led to an open ecosystem that opened the world to a whole new set of possibilities.

How is an Event API Different from a REST API?

Now that I have talked about the REST API and how it lies at the foundation of the API economy, let’s have a look at its counterpart, the event API.

At the risk of oversimplifying, REST APIs (in their purest form) are related to the resource access dimension, while event APIs are more related to the communication dimension. Essentially event APIs encapsulate the definition of a stream of events. event APIs have the construct of “channels” (which can map to topics or queues) which are conduits for the movement of Events.  When implemented, the event API can both ingest multiple streams of events or publish them, in conformance with their specification.

There are many specifications that can be used to define/describe both REST and event APIs, however typically REST APIs are described by the OAS specification while event APIs are described by the Async API specification.

event APIs group events into an interface, and thus encapsulate domain knowledge about those events. event APIs transform event streams into products, much like REST APIS do with resource access.

Unlike REST APIs however, which are fundamentally based on the HTTP protocol, event APIs need to offer a generic interface that can support a variety of protocols (MQTT, JMS, AMQP etc.). In addition, many new use cases (i.e. connected vehicles) can only be fulfilled by means of event APIs, which drastically reduce costs of data transfer and improve customer experience.

In summary, event APIs are the building blocks of even driven applications, and even though they are different in their makeup from their REST counterparts, the process by which you get access to them, and how you would use them should be the same. Thus, an API economy based on event APIs should follow the same general rules as the one based on REST APIs.

In the next section I will explore how an event API economy could function.

What is an Event API Economy?

The aim of an event API economy is the same as that of the REST API Economy: speed up innovation and create an ecosystem that is conducive to the creation of new business models, and revenue channels. The journey of participation in an event API economy of any enterprise, follows closely the journey of participation in the traditional REST API economy:

1. Develop internal event APIs, that expose publicly relevant event
2. Secure/govern the event APIs through both internal and external policies
3. Publish event APIs to a public facing portal where 3^rd party developers, integrators or partners can be easily onboarded, and begin using the event APIs
4. Track usage, and monetize the use of the respective event APIs

The only difference between the two economies is in the way the event APIs are used and, in the tooling, used to construct and compose these APIs.

As indicated, event APIs encapsulate event streams, so their consumers must be able to handle and process a continuous set of events. One of the other important aspects of an API economy is the ability to “compose” new APIs from existing APIs. In the event API context composing APIs refers to ways of processing event streams i.e. ingesting multiple streams (i.e. aggregating) and generating multiple streams (distributing). Much like REST APIs “shape” that state of a resource, event APIs shape event traffic.

Let’s explore an example to see how this could work.

Example: Airport Traffic Management Systems

Airports are like small cities, and one of their key areas of focus is to deliver an optimal traveler experience. Optimizing the customer experience can be a complex process based on many variables, but ultimately the intent is that as soon as a traveller is in the airport (whether they are there to depart, or they have arrived or are in transit) their journey while on premises should be adapted to their personal profile/preferences and the type of stay.

To make this work, the airport needs to process a lot of data in real time. Let’s take the example of an arriving traveller that is in transit.

To begin with, airport systems ingest a lot of raw data from multiple data sources. Those sources can be flight location information from the FAA feed, weather information, airline information that relates to the arriving flight and the respective passenger manifest etc. This constitutes the first tier of event ingestion and processing.

The multiple event streams that the airport’s ingestion systems receive, can then perform a series of event processing activities where they aggregate and correlate events into an outbound event stream that contains traveller information: the traveller event stream. In order to generate the traveler event stream, one needs to integrate to a wide variety of REST APIs that expose traveller information i.e. airport travel history, baggage handling system, airline systems, security systems etc.

The idea is that at the end of the process a passenger arrival event is generated that includes the most relevant information about that traveller: what gate/terminal they are arriving at, how long before their next flight (and delay times if any), what stores and restaurants they have visited in the past, the lounge they prefer to stay at etc.. Thus, a continuous event stream (made available via a Tier 2 event API) for all arriving travellers is generated that can now be the source for may upstream systems.

Thus far it has been mostly about data crunching and correlation. The value add of the “Airport Event API Economy” starts here. There are multiple entitles/services that subscribe to the Traveler Event Stream and each subscriber offers a different set of capabilities and benefits:

• Security Event Hub: This service will ingest the traveler event stream and correlate each traveller data with its security registry, and various government traveller lists, to identify the security risk an incoming passenger might pose. Based on the results, the security team may take appropriate measures (i.e. send out a security detail to the gate to accompany the traveller)
• Retail Stores: All retailers on the airport concourse will receive the traveller event stream and each one can identify if they have a record of the traveller having purchased something in the past or if they are a new traveller. In either case corresponding messaging is sent to the traveller’s airport app with discount offers, or specials that the respective store may have.
• Restaurants/Cafés: All restaurants on the airport concourse can subscribe to the traveller event stream, and each one can identify if any of the travellers are past patrons or potential new ones. Depending on the situation they may emit meal offers to the traveller’s mobile airport app.
• Lounges: The various airlines or private lounges in the airport may also consume the traveller event stream and based on the identity of the traveller may extend special offers or coupons to the respective traveller.
• Hoteling: The various hotels on the airport concourse or the airport vicinity may also subscribe to the traveller event stream and based on availability and potential connecting flight cancelation or rescheduling offer discounted rooms to the traveller.
• Concourse Event Hub: This service is in fact an aggregator service. It will subscribe to the traveller event stream , but it may also subscribe to other event streams emitted by the various other concourse tenants (retailers, restaurateurs, etc.). The purpose of this service is to create an “itinerary” for the traveller in transit. It will aggregate and consolidate the data from the various event streams, and it will generate a potential itinerary for the traveller. For instance, if they have 3 hours between flights, it can chart a path from the arrival gate to the destination gate with the sequence of visits that the traveller can do in the allotted time i.e. where to eat/drink, where to shop, lounge etc.

This third tier of event processing is where the traveler experience is being crafted. The fourth and final tier is the direct traveler experience which is delivered via the airport app on their mobile phone. The traveler can further configure the app to select the type of notifications they want to receive (i.e. from the individual concourse tenants or from the concourse event hub), to thus customize their overall experience

This diagram shows a high-level view of what the potential airport-based event API economy could look like:

Monetization Model

The airport is a closed system, with a limited set of providers and consumers. That being said, any event API provider can monetize their APIs. For instance, the airport provides tier 1 and tier 2 event APIs, with the tier 2 traveler event API being fully monetizable by the airport. Tier 3 event APIs can be built and monetized by any other third party. Thus retailers, restaurateurs etc. can pay a subscription fee for the traveler API, and in turn can charge a subscription fee to the concourse event hub provider for their specific feeds. Lastly the traveler may be paying a fee for the use of the airport mobile app (to the vendor of the app), that could incorporate the fees from the Tier 2 and 3 event APIs.

Furthermore, the airport could in fact prepackage certain event APIs and integrations and offer them at cost to their various tenants as a value-add service.

In addition, all the REST APIs that are required to affect change in the various data sources that are part of the broader system, can also be monetized alongside the event APIs. For instance, one can potentially create combined monetization tiers based on the number of events “traversing” over a given set of event APIs, and the number of requests on a given set of REST APIs.

The bottom line is that there is a lot of flexibility in how the event APIs are created and managed thereby creating a rich set of monetization policies.

The Value of the Event API Economy

There is an old adage: a database is like a telephone that does not ring! i.e. the data is there but you don’t know when and how it arrived. Unless you actively and intentionally query the database, you will not be able to get to the data inside.  What if the database could tell you when a new record has arrived? Or what if you knew that a fraud on your credit card was being perpetrated, or that your favorite brand of jeans was on sale at a nearby store as you’re walking downtown?  There are endless examples of how events and event APIs implicitly, and positively impact life, however you can boil it down to two key themes:

• Save money by averting a fraud, or taking advantage of a discount
• Make money by knowing when to invest or taking advantage of a new trend.

Event APIs allow the “environment” to let you know what needs to be done, or let you know when things that you are interested in are happening:

• They improve customer experience through real-time notifications
• They give you real-time visibility into impactful activities, so you can make better decisions
• They can de-risk certain transactions by giving you advance notice
• They can reach you anywhere you are on your preferred channel
• They are the feedback loop mechanism for change (whether good or bad)

Event APIs are basically the glue between knowing and doing!

The value they bring is awareness, and the value they create is opportunity!

And this brings us to the final point: although an event APIs economy in and of itself is very valuable, its value increases manyfold when it integrates into the REST API economy. When REST APIs and event APIs are used together, you can create pretty much any type of architecture and solve almost any problem. With two simple integration patterns you can create any complex architectural structure. Ultimately much like communication is used to drive activities on resources, event APIs can be used to trigger the execution of REST APIs, or conversely REST APIs, can generate Events that event APIs can consume.

Ultimately, an API economy will include both REST and event APIs.

Conclusion

In this article, I explained how communication and resource access interfaces differ. Then I explored how the rise of REST APIs changed the digital space by unlocking enterprise data and making it available, and by creating an ecosystem where enterprises could collaborate and share information, thereby creating a (REST) API economy. Then I explored how event APIs are gaining in popularity and how they can be the engine of growth for a different aspect of the API economy, the event API economy.

With an eye to the future, I concluded that the future of the API Economy will contain both REST and event APIs. The interplay between the two can become the foundation for a new era of an “experience” based economy, that will pave the road for a broader integration between edge systems, enterprises systems and humans, and will lead to a more efficient and secure digital economy landscape.