Connected business models

tl;dr: More and more, business models require horizontal integration rather than vertical hierarchies. While having a data-centric approach worked in the past, it won't work in the future. Therefore, events are needed as a new basic building block.

On the technical side, this change is accompanied by the need for decoupled and physically separate systems that interact with each other. This is one of the main reasons why microservices have been experiencing such an uplift in recent years – although in a certain sense they are nothing more than what was originally propagated around the turn of the millennium with the term service-oriented architecture (SOA). Actually, only the packaging is new.

API-fying business models

Connecting your own business model with those of others using microservices requires the ability to offer an API for your own business. However, this causes large difficulties for many companies, especially when they have not been on the web and in the cloud forever. The challenges are not merely technical, but also, and above all, of conceptual and functional nature.

Most APIs today are designed according to REST, i.e. they represent different ways to access data. Data can be created, read, updated and finally deleted. APIs are therefore data-centric. From a technical point of view, this approach is pretty obvious, as it perfectly fits in with the CRUD database approach (create, read, update, delete).

CRUD is a design flaw

Unfortunately, business models do not follow REST and CRUD (for details see What's wrong with CRUD). The core of successful applications is not about data. Instead, it's about the processes that work with this data. So it's about things that happen – and data is just a static piece of information used by these processes. Of course, data is not irrelevant, it just no longer plays the leading role.

Regarding APIs, this means that they would have to be designed in a process-centric rather than a data-centric way. Only those who can be informed about processes can react to them. But the four verbs create, read, update and delete are too weak for that, because they do not contain any semantics and do not describe the reasons why things happen. However, it is precisely these semantics and reasons that are highly relevant for understanding and sensibly controlling business processes.

Events as DNA for distributed systems

Therefore, a new basic building block other than data is needed, which will take the primary role in the future, and around which APIs should revolve: We are talking about events. Events describe facts that have happened and are therefore predestined for if-this-then-that scenarios and for the integration of business processes across API and service boundaries.

From a technical point of view, using an event-centric approach for designing and developing APIs is a serious break with the past and requires new concepts and rethinking. The new world therefore feels unfamiliar at first, but it is the necessary basis for successful horizontal integration and offers a great deal of potential along the way.

Twitter Facebook LinkedIn

Golo Roden

Founder, CTO, and managing partner

Since we want to deliver elegant yet simple solutions of high quality for complex problems, we care about details with love: things are done when they are done, and we give them the time they need to mature.