Vernetzte Geschäftsmodelle

Geschäftsmodelle haben sich in den vergangenen Jahren verändert: Erfolg hat nicht länger, wer seine Zulieferer über vertikale Integration beherrscht, sondern wem es gelingt, das eigene Geschäft in eine Plattform zu verwandeln und sie horizontal mit anderen Anbietern zu integrieren. An die Stelle der Hierarchie treten vernetzte Geschäftsmodelle.

 

Dieser Wandel geht auf technischer Seite damit einher, dass entkoppelte und physisch voneinander getrennte Systeme miteinander interagieren müssen. Das ist ein wesentlicher Grund, warum Microservices seit einigen Jahren einen derartigen Aufschwung erleben – obwohl sie in gewissem Sinne nichts anderes sind als das, was um die Jahrtausendwende bereits mit dem Begriff „SOA“ propagiert wurde. Nur die Verpackung ist neu.

 

Geschäftsmodelle API-fizieren

Das eigene Geschäftsmodell über Microservices mit anderen Anbietern zu verbinden bedingt aber wiederum, eine API für das eigene Business anbieten zu können. Nicht umsonst ist ein weiteres gängiges Schlagwort die „API-fizierung des Business“. Das stellt viele Unternehmen, die nicht nativ aus der Web- und Cloud-Welt kommen, allerdings bereits vor größere (und nicht nur technische) Herausforderungen.

 

Das Hauptproblem an der Stelle ist jedoch kein technisches, sondern ein konzeptionelles: Die meisten APIs sind heutzutage gemäß REST entworfen, das heißt, sie bilden verschiedene Möglichkeiten zum Zugriff auf Daten ab: Daten können erzeugt, gelesen, verändert und schließlich gelöscht werden. APIs sind daher datenzentrisch aufgebaut. Aus technischer Sicht liegt das Nahe, passt REST doch hervorragend zu dem Datenbankansatz „CRUD“, also „Create, Read, Update, Delete“.

 

CRUD ist ein Designfehler

Unglücklicherweise folgen Geschäftsmodelle jedoch nicht REST und CRUD (siehe auch https://www.thenativeweb.io/blog/2017-10-25-09-46-ddd-and-co-part-1-whats-wrong-with-crud/): Der Kern erfolgreicher Anwendungen sind nämlich nicht die Daten, sondern die Vorgänge, die mit diesen Daten arbeiten. Es geht also um Dinge, die passieren – und die Daten sind lediglich die statischen Akteure, die von diesen Prozessen verwendet werden. Selbstverständlich sind Daten nicht unwichtig, sie spielen nur nicht länger die Hauptrolle.

 

Auf APIs übertragen bedeutet das, dass man sie nicht daten-, sondern prozesszentrisch entwerfen müsste. Nur wer über Vorgänge informiert werden kann, kann auch auf sie reagieren. Dafür sind die vier Verben „Create“, „Read“, „Update“ und „Delete“ aber zu schwach, da sie keinerlei Semantik enthalten, und nicht die Ursachen beschreiben, warum Dinge geschehen. Gerade diese Ursachen sind aber in höchstem Maße relevant, um Geschäftsprozesse verstehen und sinnvoll steuern zu können.

 

Events als DNS für verteilte Systeme

Daher braucht es einen anderen neuen Grundbaustein als Daten, der zukünftig die primäre Rolle einnimmt, und um den sich APIs drehen sollten: Die Rede ist von „Events“. Events beschreiben Vorgänge, die geschehen sind, und sind damit prädestiniert für „If-This-Then-That“-Szenarien und für die Integration von Geschäftsprozessen über API- und Servicegrenzen hinweg.

 

Aus technischer Sicht ist eine Event-zentrische Entwicklung ein gravierender Bruch mit der Vergangenheit und erfordert neue Konzepte und Umdenken. Die neue Welt fühlt sich daher zunächst ungewohnt an, ist aber die erforderliche Grundlage für eine erfolgreiche horizontale Integration und bietet auf dem Weg ausgesprochen viel Potenzial. Welches, erfahren Sie von Golo Roden auf der DWX in den beiden Vorträgen „DDD, Event-Sourcing und CQRS – Theorie und Praxis“ (Montag, 25. Juni 2018, 14:15-15:15 Uhr) und „Event-Sourcing vs CRUD“ (Montag, 25. Juni 2018, 17:00-18:00 Uhr).