Digitale Ökosysteme

Warum digitale Ökosysteme?

Im Artikel Digitalisierung habe ich die Digitalen Ökosysteme als Stufe 4 des Prozesses kurz vorgestellt. In diesem Artikel möchte ich näher darauf eingehen, wie ein digitales Ökosystem gebaut werden kann. Doch zuerst und ohne Umschweife:

Digitale Ökosysteme sind komplex.

Daher sind vor allem 2 Dinge wichtig, bevor man die Entscheidung trifft, ein solches Ökosystem aufzubauen:

• Man sollte einen guten Grund dafür haben, bei dem der Nutzen eines digitalen Ökosystems den Aufwand übersteigt
• Man sollte Maßnahmen treffen um die Komplexität beherrschbar zu machen

In folgenden Szenarien bringen digitale Ökosysteme einen größeren Nutzen als die vorherigen Stufen der Digitalisierung:

• Digitale Ökosysteme können sehr gut skalieren. Sie sind daher für Einsatzgebiete mit stark wechselnder Last oder Hochlast gut geeignet.
• Kern von Digitalen Ökosysteme ist die Integration: Daher sind sie sehr gut geeignet, wenn viele unterschiedliche Rollen und Akteure (Kunden, Mitarbeiter, Partnerunternehmen, etc.) mit einem System arbeiten oder wechselwirken sollen.
• Digitale Ökosysteme sind sehr flexibel: In agilen Umfeldern in denen häufig neue Geschäftsfunktionen oder Produkte entstehen oder wegfallen, spielen Digitale Ökosysteme ihre Vorteile aus.

Der Preis für ein digitales Ökosystem ist seine höhere Komplexität und aufwändigere Verwaltung im Vergleich zu Systemen auf einer niedrigeren Stufe der Digitalisierung. Das bedeutet im Umkehrschluss: Für eine Anwendungslandschaft mit geringer oder weitgehend statischer Last, die sich nicht mit externen Systemen integrieren muss, und deren Funktionsumfang ausgereift ist, gibt es keinen Grund, sie in ein digitales Ökosystem zu transformieren. In einem solchen Szenario würden lediglich die Kosten nach oben schnellen, die aus der höheren Komplexität und dem größeren Verwaltungsaufwand resultieren.

Die drei genannten Faktoren Skalierung, Integration und Flexibilität lassen sich für eine erste Auswahl auf die beiden Faktoren Skalierung und Integration reduzieren. Denn wenn ein System gut skaliert und sich einfach integriert, dann ist es meistens auch flexibel. Folglich kann man die existierenden Anwendungen in einem Unternehmen auf einem 2-dimensionalen Graphen darstellen und danach ihre Eignung für ein digitales Ökosystem bewerten:

Der Entscheidungsquadrant unterscheidet folgende Arten von Anwendungen:

• Sichere Kandidaten: Diese Gruppe von Anwendungen hat hohe Anforderungen an Skalierungsfähigkeit und Integrationsfähigkeit. Daher ist es sicher sinnvoll, an dieser Stelle ein digitales Ökosystem zu bauen.
• Gute Kandidaten: Diese Gruppe von Anwendungen hat hohe Anforderungen an die Integrationsfähigkeit, aber nicht an die Skalierungsfähigkeit. Ich würde sie dennoch in einem digitalen Ökosystem realisieren, weil der Kern eines solchen Systems die Integration ist.
• Mögliche Kandidaten: Diese Gruppe von Anwendungen hat hohe Anforderungen an die Skalierungsfähigkeit, aber niedrige an die Integrationsfähigkeit. An dieser Stelle würde ich die Anforderungen an die Skalierungsfähigkeit genauer überprüfen:
  • Sind sie wirklich sehr hoch: Digitales Ökosystem bauen.
  • Entpuppen sie sich als nicht ganz so hoch oder doch eher statisch: Bestehende Architektur beibehalten.
  • Ist eine hohe Flexibilität gefordert: Ebenfalls digitales Ökosystem bauen.
  • Und letztendlich: Falls das Unternehmen bereits Erfahrung mit digitalen Ökosystemen hat und welche betreibt, kann man auch diese Anwendungen transformieren.
• Keine Kandidaten: Diese Gruppe von Anwendungen hat niedrige Anforderungen sowohl an Skalierungsfähigkeit als auch an Integrationsfähigkeit. Aus dieser Gruppe ein digitales Ökosystem zu machen, wäre Verschwendung von Zeit und Geld. Es sei denn, der Rest der Unternehmensanwendungen ist bereits vollständig auf der Stufe des digitalen Ökosystems angekommen, das Wissen und die Kompetenz ist im Unternehmen vorhanden und die entsprechenden Strukturen (wie Betriebs- und Integrationsteams) sind etabliert. Nur dann sollte man auch diese Anwendungen auf die Stufe der digitalen Ökosysteme bringen.

Komplexität beherrschen

Soll die IT-Landschaft im Unternehmen ganz oder teilweise auf ein digitales Ökosystem umgestellt werden, dann wird sie naturgemäß komplexer als zuvor. Eine Anwendung besteht dann aus einer Gruppe von Micro, Mini oder Macro Services, die orchestriert werden müssen. Gleichzeitig wird die Anzahl der Anwendungen zunehmen, denn die Anwendungen werden sich in Richtung kleinerer Apps entwickeln und weniger multifunktionale Suiten sein. Das wird dann ungefähr so aussehen:

Die Anwendungen auf der linken Seite sind an ihre Monolithen gebunden. Die Kommunikation über das Netzwerk erfolgt nur zwischen den 3 gezeigten Monolithen. Damit bilden die Monolithen einen natürlichen Rahmen um die Anwendungen, der die Komplexität der Anwendungslandschaft im Zaum hält. Leider begrenzt dieser Rahmen auch die Skalierbarkeit, die Integrationsfähigkeit und die Flexibilität. Innerhalb eines digitalen Ökosystems (rechts im Bild) fällt dieser natürliche Rahmen weg und die Anwendungen kommunizieren direkt miteinander. Das erhöht schlagartig die Skalierbarkeit, Integrationsfähigkeit und Flexibilität der Gesamtlandschaft. Leider auch die Komplexität. Aus diesem Grund müssen innerhalb eines Digitalen Ökosystems Maßnahmen getroffen werden, um die Komplexität wieder zu reduzieren. Denn die Anzahl der Anwendungen wird in Zukunft weiter wachsen und die Komplexität dadurch weiter zunehmen.

Indem man ein großes digitales Ökosystem in verschiedene Zonen unterteilt, kann die Komplexität reduziert werden. Wie im obigen Bild gezeigt, gibt es dabei nicht die eine, richtige Unterteilung, sondern verschiedene Möglichkeiten. Um pragmatisch vorzugehen, macht man die Schnitte in der IT Landschaft indem man gemeinsame Merkmale von Anwendungen sucht und diese Anwendungen dann jeweils einer dedizierten Zone zuordnet. Gemeinsame Merkmale können zum Beispiel sein:

• Lastanforderungen: Hochlast-Zone, Mittellast-Zone, Niedriglast-Zone, volatile Lastzone
• Anwender: Jeweils eine Zone für Anwendungen, die von Mitarbeitern, Kunden oder Geschäftspartnern genutzt werden
• Geschäftsprozesse: Ausrichtung der Zonen an den Kern-, Unterstützungs- oder Managementprozessen
• Sicherheitsbereiche: Eigene Zonen für Anwendungen, die geheime, vertrauliche, sensible oder öffentliche Daten verarbeiten
• Art der Datenverarbeitung: Zonen für Anwendungen, die transaktionale, analytische oder translytische Daten verarbeiten
• etc.

Der Fantasie sind hier keine Grenzen gesetzt und auch Mischformen sind möglich. Aber als Architekt muss man eine plausible Erklärung vorweisen können, was die gemeinsamen Merkmale einer Zone sind und warum man danach geschnitten hat.

Aufbau eines digitalen Ökosystems

Um den Aufbau einer Zone zu erklären, zeige ich zuerst wie eine Anwendung auf dieser Stufe der Digitalisierung aufgebaut ist.

Anwendungen

Wie die Abbildung zeigt, besteht die Beispiel-Anwendung (von oben nach unten) aus einem Web Interface und einer App, die von einem Backend for Frontend (BFF) mit Hilfe einer GraphQL API mit Daten versorgt werden. Das BFF bekommt seine Daten aus verschiedenen REST APIs, die wiederum von mehreren Services (SOA oder Microservice) zur Verfügung gestellt werden. Die Services untereinander können mit Hilfe eines Topics in einer Streaming Middleware sprechen und einer der Services hat eine Datenhaltung in Form einer Datenbank. Alle Komponenten in diesem Bild sind separat deploybar - bis auf die Schnittstellen (REST APIs, GraphQL API, Streaming Topic), die von den Services, bzw. dem BFF zur Verfügung gestellt werden. Für eine einzelne Anwendung ist diese Architektur noch recht übersichtlich. Fügen wir eine weitere hinzu und nehmen wir an, dass sich Nutzer an den Anwendungen anmelden können sollen. Das Bild sieht dann so aus:

Wie im obigen Bild zu sehen, ist die zweite Anwendung aufgebaut wie die erste. Da sie aber wie die erste auch, Integrationen braucht, wurden diese ebenfalls eingezeichnet. Konkret bedeutet das: “Nach innen” können sich die Services der Anwendungen jetzt mit einer Streaming Middleware austauschen. “Nach außen” werden die Daten der Services über einen API Gateway abgesichert. Der API Gateway ist mit der Authentifizierungs- und Autorisierungsanwendung verbunden und kann auf diese Weise sicherstellen, dass Ressourcen den jeweils berechtigten Nutzern angezeigt werden.

Schichten

Aus dem gezeigten Bild - ein Mini-Ökosystem mit 2 Anwendungen - kann man jetzt abstrakt ableiten welche Schichten eine Zone in einem Digitalen Ökosystem minimal benötigt:

Die Zone, die im oben gezeigten Bild vier Anwendungen umfasst, besteht konzeptionell aus 6 Schichten. Dabei setzen sich die grünen Schichten aus Komponenten der Anwendungen zusammen, während die blauen Schichten durch eigene Anwendungen realisiert werden. Diese Anwendungen bilden das Grundgerüst der Zone des digitalen Ökosystems. Die Schichten der digitalen Zone sind:

• Sicherheitsschicht (Security Layer): Hier findet sich alles was der Sicherheit dient, wie die Authentifizierung & Autorisierungsanwendung aus dem obigen Beispiel.
• Äußere Vermittlungsschicht (Outer Mediation Layer): In dieser Schicht sind alle Anwendungen zu finden, die den Zweck haben, die Verbindung zur Außenwelt herzustellen: Außerhalb der Zone, aber auch zu den Frontends der Endnutzer, die zwar konzeptionell Teil der Zone sind, aber technisch “draussen im Internet” laufen. Im obigen Beispiel war das das API Gateway.
• Innere Vermittlungsschicht (Inner Mediation Layer): Hier findet man alle Systeme, die die Kommunikation innerhalb einer Zone ermöglichen. Als Beispiel dient oben die Streaming Middleware. Eine Anwendung muss die innere Vermittlungsschicht nicht notwendigerweise nutzen. Die innere Vermittlungsschicht dient vor allem dazu, eine schnelle und abgesicherte Kommunikation rein innerhalb einer Zone zwischen Backend-Komponenten zu ermöglichen. Sollten die Anwendungen in dieser Zone das nicht benötigen, kann auf diese Schicht verzichtet werden. Die Zone kann ebenfalls auf die innere Vermittlungsschicht verzichten, wenn sie zur Kommunikation zwischen den Anwendungen die äußere Vermittlungsschicht nutzt.

Die Schichten der Anwendungskomponenten orientieren sich an der 3-Schicht-Architektur:

• Darstellungsschicht (Presentation Layer) umfasst alles was benötigt wird, um ein Nutzerinterface zur Verfügung zu stellen. Im obigen Beispiel waren das das Web Interface, die App sowie das Backend for Frontend mit seiner GraphQL API.
• Logikschicht (Logic Layer) enthält die Logik einer Anwendung, meistens realisiert in Services oder Microservices. Im obigen Beispiel waren das einfach die Services.
• Persistenzschicht (Persistence Layer): Enthält alles was Daten für eine Anwendung speichert: Datenbanken, Dateisysteme, Objektspeicher, etc. - im obigen Beispiel einfach die Datenbanken.

Die hier gezeigte, einfache Darstellung einer Anwendung in der 3-Schicht-Architektur schließt nicht aus, dass die Anwendung noch mehr Schichten verwendet (z.B: View-Controller Layer, Session Layer, Data Access Layer, etc.). Wichtig ist als Minimalanforderung nur die Entkopplung von Darstellung, Logik und Persistenz.

Im Gesamtbild betrachtet, besteht eine Anwendung auf dieser Stufe der Digitalisierung aus ihren direkt zugeordneten Komponenten in den Persistenz-, Logik- und Darstellungsschichten, wie auch aus den zonenspezifischen Anwendungen der inneren und äußeren Vermittlungsschicht sowie der Sicherheitsschicht.

Zonen

Kombiniert man mehrere dieser Zonen, erhält man ein Digitales Ökosystem:

Fokussiert man die Anwendungen der Zonen eines digitalen Ökosystemsystems statt der Schichten, ergibt sich folgende Darstellung:

Obige Grafik zeigt 4 Zonen eines digitalen Ökosystems in einem Unternehmens. Die einzelnen Zonen können gleich aufgebaut sein (Zone 1 & 2), müssen es aber nicht (Zone 3 & 4). Jede Zone besitzt eine gewisse Autarkie. Zone 4 verzichtet beispielsweise komplett auf die Inner Mediation und wickelt alle Kommunikation über die Outer Mediation ab. In Zone 3 nutzen nicht alle Anwendungen die Inner Mediation. Diese Freiheit innerhalb einer Zone ist gewünscht um selbständiges Anpassen an die jeweiligen Anforderungen zu erlauben.

Die Anwendungen mit blauem Hintergrund sind auf dem Bild diejenigen Anwendungen, die die jeweilige Zone des Ökosystems aufspannen. Anders ausgedrückt: In einer Stadt wären diese Anwendungen die Verkehrswege (Straßen, Schienen, etc.) während die grau hinterlegten (Fach-)Anwendungen die Gebäude sind. In dieser Analogie muss ein Gebäude eine Ausfahrt zu einer Straße hin haben, damit es am Straßenverkehr teilnehmen kann - in der IT wären das die definierten APIs, die eine (Fach-)Anwendung anbieten und verwenden muss.

Wie oben schon beschrieben, sind die gemeinsamen Merkmale der Anwendungen ausschlaggebend um in einer Zone zu sein. Die Aufteilung nach Nutzergruppen könnte in diesem Beispiel so aussehen:

• Zone 1 enthält Anwendungen für Mitarbeiter in der Zentrale eines Unternehmens
• Zone 2 enthält Anwendungen für Mitarbeiter in den Niederlassungen des Unternehmens
• Zone 3 enthält Anwendungen für Kunden innerhalb von Europa
• Zone 4 enthält Anwendungen für Kunden in Asien

Das Internet sowie die Ökosysteme von Geschäftspartnern sind, wie die anderen Zonen, über die Outer Mediation mit dem Unternehmen verbunden. Aus der Perspektive einer Anwendung in Zone 1 spricht selbige niemals mit einer Anwendung in einer anderen Zone. Sie spricht immer nur mit einer anderen Zone, aber nicht mit einer anderen Anwendung. Die Outer Mediation wirkt wie eine Fassade vor einer Zone. Das reduziert die Komplexität des Ökosystems, erhöht die Flexibilität und verbessert die Wartbarkeit. Zone 2 kann durch dieses Architekturmuster eine Anwendung durch eine neue ersetzen ohne dass Anwendungen in anderen Zonen Migrationsaufwände haben - solange die definierten Schnittstellen der Zonen beibehalten werden!

Herausforderungen

Dieser Artikel lieferte bisher eine idealtypische Beschreibung dessen was ein digitales Ökosystem ist und wie man dort hin kommt. Leider weicht die Realität oft vom Lehrbuch ab. Daher möchte ich an dieser Stelle einige typische Herausforderungen zeigen, die beim Aufbau eines digitalen Ökosystems zu meistern sind.

Integration und Mediation organisieren

Die Integration und Mediation sind der Kern eines digitalen Ökosystems. Sie haben sehr viel Gewicht und tragen Entscheidendes zum Funktionieren bei. Dieses Gewicht muss sich auch in organisatorischen Strukturen wiederfinden. Diese Strukturen müssen dem Unternehmen und seiner Größe angemessen sein. Je nach Größe des Unternehmens und den Zonen des digitalen Ökosystems könnte zum Beispiel ein Integrationsteam für das komplette Ökosystem zuständig sein, oder auch nur für eine Zone. Dazwischen gibt es beliebige Abstufungen - wichtig ist jedoch, dass jemand (eine Person, ein Team, eine Abteilung, …) explizit die Verantwortung für Integration und Mediation im Ökosystem bzw. innerhalb einer Zone hat. Ist das langfristig nicht der Fall, wird das digitale Ökosystem in einzelne Inseln oder Königreiche zerfallen, die nicht mehr effizient miteinander sprechen können.

Unternehmensstrukturen akzeptieren

„Organisationen, die Systeme entwerfen, […] sind gezwungen, Entwürfe zu erstellen, die die Kommunikationsstrukturen dieser Organisationen abbilden.“

– Melvin E. Conway

Das Gesetz von Conway bewahrheitet sich so oft wie seine Realität ignoriert wird. Dem Aufbau eines digitalen Ökosystems müssen die Strukturen innerhalb eines Unternehmens folgen. Dafür gibt es 2 Möglichkeiten: Entweder der Schnitt der Zonen wird analog zu den (hierarchischen) Strukturen im Unternehmen vollzogen oder die hierarchischen Strukturen werden dem Schnitt des digitalen Ökosystems angepasst. Was der richtige Weg ist, variiert in jedem Unternehmen. Wichtig ist aber auch hier: Die beiden Schnitte müssen übereinstimmen! Ansonsten passiert das gleiche wie bei der vorherigen Herausforderung: Das digitale Ökosystem ist nicht erfolgreich und wird zerfallen.

Integrationsarchitektur finden

Der wesentliche Unterschied zwischen einem Digitalen Ökosystem und anderen Organisationsformen verteilter Systeme ist die Integrationsarchitektur und die daraus resultierenden Integrationsmuster. Um hier die richtige Entscheidung zu treffen, muss sich ein Architekt das Kommunikationsverhalten von Anwendungen in seiner Zone genau ansehen und geeignete Protokolle und Technologien wählen. Es kann auch eine Lösung sein, von der Integrationsarchitektur her zu denken. Das wird Anpassungsaufwände an den Anwendungen nach sich ziehen - was bedacht werden muss.

Wird die Integrationsarchitektur bei der Planung eines digitalen Ökosystems nicht ausreichend berücksichtigt, wird ein babylonisches Sprachwirrwarr entstehen und die Kommunikation zwischen Anwendungen und Zonen wird von Missverständnissen und fehlgeschlagenen Projekten begleitet werden.

Alte Systeme integrieren

Ältere Systeme, die noch nicht auf einer 3-Schicht-Architektur basieren, wie Monolithen oder Client-Server-Systeme, lassen sich nicht ohne weiteres in ein digitales Ökosystem integrieren, weil sie die erforderlichen Schnittstellen nicht bieten.

Hier liegt die Herausforderung darin, eine Möglichkeit zu finden, den “Monolithen anzuschneiden”. Idealerweise macht man das irgendwo in der Logikschicht - sofern der Monolith eine hat. Wenn es irgendwie vermeidbar ist, sollte man nicht direkt auf die Datenbasis in der Persistenzschicht eines Monolithen zugreifen, weil durch die monolithische Kopplung Logik und Persistenz oftmals stark gebunden sind. “Den Monolithen aufschneiden” schreibt sich hier zwar einfach - in der Wirklichkeit ist das jedoch eine sehr komplexe Aufgabe, die von den zuständigen Architekten einiges an Fingerspitzengefühl erfordert.

Macht man es nicht, verliert man die Möglichkeit frühe Erfolge im digitalen Ökosystem zu erreichen. Denn oftmals sind die Daten, die noch in monolithischen Systemen liegen, wesentlich für das Unternehmen. Und ohne diese Daten ist ein junges digitales Ökosystem nur begrenzt nützlich.

Iterativ vorgehen

Ein digitales Ökosystem zu bauen - das womöglich ein komplettes Unternehmen umfasst - ist ein großes Vorhaben. Dieses Vorhaben wird auch nicht sofort, sondern erst mittelfristig, einen Nutzen zeigen. Das Projektmanagement muss sich also auf mögliche Durststrecken einstellen. Besonders bei der Einführung der Mediation Layer werden zuerst Stimmen laut werden, die von Mehraufwänden für ihre bestehenden Systeme und laufenden Projekte sprechen werden. Hier braucht es ein entsprechend erfahrenes Projektmanagement mit einem dicken Fell. Es muss Kommunikation und Überzeugungsarbeit geleistet werden. Vertrauen muss aufgebaut, Entscheider müssen abgeholt werden. Das ist häufig eine Arbeit außerhalb der eigentlichen Projektaktivitäten und weit im Vorfeld des Projektstarts.

Nicht iterativ vorzugehen, ist keine Alternative. Außer einem Startup baut niemand ein digitales Ökosystem auf einer grüne Wiese.

Fazit

Die notwendigen Technologien für Digitale Ökosysteme existieren seit ca. 20 Jahren. Die zu Grunde liegenden Architekturmuster sogar noch länger. Dennoch sind zumindest in Deutschland bisher noch nicht viele digitale Ökosysteme entstanden. Vielleicht auch deswegen, weil die bestehenden Herausforderungen unterschätzt werden: Ein digitales Ökosystem ist kein IT Projekt. Viele Firmen unterscheiden nach wie vor zwischen IT und Fachbereich. Im Zeitalter der Digitalisierung ist ein Fachbereich gleichzeitig ein IT-Bereich und umgekehrt. Es erfordert Mut eine Transformation hin zu einem echten digitalen Ökosystem anzustoßen und Kraft, sie zu Ende zu bringen. Doch nicht erst am Ende der Transformation wird ein Unternehmen davon profitieren. Bereits mittelfristig werden Ergebnisse in Form von neuen, flexiblen Anwendungen und einer deutlichen Skalierung der Geschäftsprozesse sichtbar sein. Es lohnt sich!