Müsste man das aktuelle Treiben der Digital- und IT-Teams vieler mittelständischer und großer Unternehmen in einem kurzen Statement beschreiben, würde es wohl etwa lauten: “Daten- und API-Plattformen allüberall!”
Das ist auch gut und richtig so. Denn mit diesen Plattformen können die Unternehmen gleich mehrere wichtige Aufgaben erledigen:
- Aufbau einer zentralen Cloud-Architektur (Public/Hybrid/Native): Die Einführung und produktive Nutzung von Cloud-Services für alle Geschäftsbereiche anhand einheitlicher Standards (Governance, Authentifizierung, Monitoring)
- Verknüpfen von Kernsystemen & neuer Welt: Auch wenn die IT der zwei Welten ein Mythos bzw. oft eine Sackgasse ist, so werden Kernsysteme wie beispielsweise SAP und die neuen Cloud-Native-Anwendungen immer ein etwas anderes Betriebsmodell haben und Daten in den Kernsystemen verbleiben (müssen).
- Test- & Entwicklungsumgebung schaffen: Viele Unternehmen sind bis heute unsicher, welche digitalen Services einen echten Mehrwert bringen. In einer kostentechnisch risikoarmen Umgebung lassen sich so MVPs und Prototypen entwickeln und ausprobieren.
- Neue Innovationen schaffen: IoT, künstliche Intelligenz, Real-Time-Data-Streaming und Co. versprechen ein immenses Innovationspotenzial, können aber meist nur mit den neuesten Technologien in der Cloud wirtschaftlich umgesetzt werden.
- Differenzierung & Wettbewerbsvorteile: Die zunehmende Kommerzialisierung von Technologie erschwert es zunehmend, eigene Innovationen auf den Markt zu bringen. Umso wichtiger ist es, die etablierten Standards einzusetzen, um hier weder Zeit noch Geld zu verschwenden.
Somit treiben zahlreiche Unternehmen gerade ihre parallelen Bemühungen, eine firmenweite Cloud-Architektur auf einem der Hyperscaler aufzusetzen, Cloud-Native-Entwicklungsteams aufzubauen und die Datenplattformen als Schaltzentrale zu installieren.
Power to the Teams – Warum sich die Entscheidungsgewalt für Cloud Computing noch wandeln muss
Naturgemäß fällt einigen Unternehmen der Schritt in die neue Technologie-Welt und das digitale Business noch immer nicht leicht. Wenngleich zahlreiche Erfolgsbeispiele existieren, über die wir bereits seit Jahren berichten können, so gibt es auch viele Herausforderungen, Mehrkosten und Misserfolge in diesem Bereich. Was theoretisch einfach und trivial klingt, ist i der Praxis oft umso schwerer und aufwändiger.
Denn trotz aller Standards und Best Practices muss jedes Unternehmen sich noch einmal selbst besinnen, welche Architektur-Konfiguration und welche Use Cases in diesem Bereich wirklich einen Mehrwert bieten.
Die Entscheidungsgewalt liegt häufig beim Management und hat eine sehr grundlegende Natur: Das Management oder einzelne Organe geben eine grundlegende Richtung vor, um möglichst strukturiert und mit vermeintlich geringem Risiko agieren zu können.
Das Buy-in des Management ist für eine erfolgreiche Cloud-Transformation und die Integration in die business-kritischen Prozesse unerlässlich. Je mehr Beteiligung und Unterstützung von der Führungsebene kommt, desto vielversprechender werden die technischen Ansätze sein.
Mit der eher zentralistischen Entscheidungsgewalt geht auch eine restriktivere Cloud-Plattform-Architektur einher. Die Teams, die auf ihr agieren, haben meist eine klare Liste an Richtlinien, an die sie sich halten müssen. Diese kommt entweder direkt vom Management oder wird in deren Auftrag von der eigenen IT als Enabler der Anwendungsteams erstellt.
Diese Richtlinien schränken bewusst ein, was insbesondere in den Frühphasen der Cloud-Nutzung und des Plattform-Aufbaus sinnvoll sein kann, um eine gute Leitlinie für die Umsetzungsteams zu definieren. Allerdings sollte diese Liste der Richtlinien künftig anpassbar sein oder auch relativiert werden können, um mehr Freiheitsgrade zu heben.
Die Unternehmen sollten allerdings in jedem Falle beachten, dass sie nicht aktuelle, statische und eher aus der traditionellen IT stammenden Konzepte eins zu eins in die neue digitale Infrastrukturplattform und Cloud-Welt übertragen. Dieser Weg birgt zahlreiche Schwierigkeiten und konterkariert das Cloud-Konzept und einen Großteil der damit verbundenen Chancen und Ziele. Für die neue Cloud-Welt sollten Sicherheit, Datenschutz und Regulatorik eingehalten werden, aber definitiv neue Richtlinien erstellt werden, um dies zu vermeiden.
Langfristig gesehen werden somit die Anwendungsteams und deren individuelle Bedarfe die ursprünglichen Richtlinien in Frage stellen. Die Unternehmen sollten Antworten darauf haben, wie sie an den Grenzen der eigens definierten Richtlinien entscheiden und welche Voraussetzungen erfüllt sein müssen, um die Entscheidungsgewalt stärker in die Teams zu verlagern.
Moderne Organisations- und Architektur-Konzepte für Daten- und API-Plattformen in der Cloud
Die Organisationsmodelle und die Daten- und Softwarearchitekturen hängen dabei oft enger zusammen, als viele denken. Conway’s Law, eine Gesetzmäßigkeit beobachtet von Melvin Conway, sagt aus, dass die Softwarearchitekturen stark die Organisationsstruktur des jeweiligen Unternehmens widerspiegeln.
So wandeln sich auch die Plattform- und Betriebskonzepte rund um die Daten- und API-Plattformen der Unternehmen.
Im ersten Schritt haben die Unternehmen seinerzeit die Entwicklungs- und Betriebsverantwortungen immer mehr verbunden. Zwar wurden Entwicklung und Betrieb teilweise noch immer von unterschiedlichen Teams erbracht, was in der Praxis sinnvoll sein kann, jedoch waren die jeweiligen Abstimmungen und gemeinsamen Architekturüberlegungen sehr stark synchronisiert.
Dennoch – und das ist heute einer der am meisten verbreiteten Modelle – werden die Plattform-Entwicklung und die Anwendungsentwicklung der individuellen Services noch voneinander getrennt. Während die Plattform-Teams vor allem auf eine universelle und langfristige Lösung schauen, die möglichst viele Eventualitäten bedenkt und dennoch ein Höchstmaß an Standards vereinen soll, suchen die Anwendungsteams für ihren jeweiligen Bereich die bestmögliche Lösung. Es ist dabei nicht immer einfach, diese beiden Zielrichtungen in Einklang zu bringen.
Zu große Plattform-Lösungen, die zahlreiche kostspielige Cloud Managed Services im Einsatz haben, aber gar nicht in vollem Umfang genutzt werden, sind die Folge. Das bedeutet letztlich nichts anderes als hohe Kosten für weniger Ertrag.
Auf dieser Basis werden die Weichen nun für die nächste Evolutionsstufe der Plattformentwicklung gestellt. Im neuen Ansatz diktieren die DevOps und Umsetzungsteams der jeweiligen Use Cases einen Großteil der Plattformarchitektur. Dies muss nicht zwingend bedeuten, dass die Plattform-Teams an Bedeutung verlieren, sie sind nur vielmehr in ihren Anforderungen von den konkreten Use Cases des Unternehmens getrieben. In enger Verzahnung mit den Entwicklungsteams entwickeln sie so ihre Architektur, die umso variabler und weniger statisch sein muss. Dennoch gilt es auch hier für die Unternehmen, überall dort auf Standards und fertige Services zu setzen, wo diese bereits etabliert und Best Practice sind. Die Individualisierung und eigene Software-Entwicklung, die schlussendlich den Wettbewerbsvorteil verschafft, ist ein wichtiger, aber immer komplexerer und verhältnismäßig kleinerer Teil.
Das Zusammenwachsen der Use Case- und Plattformteams bringt das Produkt-Mindset der jeweiligen Welten noch stärker in ein Einklang. Unternehmen, denen es gelingt, gesteuert von den wesentlichen Use Cases ihrer Daten- und API-Plattform ihre Konfiguration zu definieren und in die Tat umzusetzen, werden also noch schneller, effizienter und nachhaltiger erfolgreich sein als jene, die ihre Plattform und die Anwendungen technisch und organisatorisch zu stark voneinander abstrahieren.
In der Praxis ist dies für viele Unternehmen Stand heute nicht möglich, da die interne Erfahrung auf diesen Plattformen noch nicht gegeben ist und somit Strukturen und Ressourcen fehlen. Auch diktiert die bestehende IT-Landschaft nach wie vor sehr stark das Systemdesign der Plattformen.
Dennoch sollten sie darauf vorbereitet sein, dass die individuellen Anwendungen und Services entlang der Wertschöpfungskette immer mehr der heilige Gral und Wachstumsgarant der Unternehmens sind und deswegen auch technologisch eine besondere Bedeutung einnehmen.
Früher oder später werden somit die Entwickler- und Umsetzungsteams einen Großteil der operativen Entscheidungen übernehmen können.