Von der Eisenzeit in die Cloud – Folgen der Digitalen Transformation für Organisationen und IT

Digitale Transformation verstehe ich zunächst vor dem Hintergrund meiner Ausbildung als Heaviside-Funktion mit Skalierungsfaktor 1. Es ist naheliegend, Situationen durch einen auf Erfahrungen aufbauenden subjektiv eingefärbten Filter zu interpretieren. Bei fehlender Perspektive können daraus allerdings Probleme erwachsen, weil die Problematik wie bei Cargo-Kulten stark simplifiziert wird und dann mit dem simplizitischen Modell komplexe Fragestellungen zu erklären versucht werden. Jede Analogie hat allerdings ihre Grenzen und dieser sollte man sich bewusst sein. Mithin kommt man eben nicht umhin, eine Wellengleichung zu lösen – und dann hat man besser in Quantenmechanik aufgepasst. Auf die digitale Transformation übertragen bedeutet das: Digitalisierungsinitiativen ohne profundes Wissen um IT Technologie und über Funktionsmechanismen digitaler Geschäftsmodelle im Executive Management fehlt Substanz.

Skalierungsfaktoren digitaler Geschäftsmodelle

Digitale Geschäftsmodelle zeichnet zunächst die Skalierungsfähigkeit ohne linear proportionalen Ressourceneinsatz aus. Das heißt: bei gegebener Kundenbasis werden für die doppelte Kundenanzahl weder doppelt soviel Personal noch doppelt so große Maschinen gebraucht – bei entsprechender Prozessauslegung.

Natürlich gibt es Überschneidungen wie bei großen internetbasierten Versandhändlern: hier spielt Logistik eine wichtige Rolle, wobei durch Automatisierung enorme Effizienzen gehoben werden können, die auch relativ betrachtet umso mehr zum Tragen kommen, je größer das abgewickelte Volumen wird. Falls ein Geschäftsmodell allerdings direkt proportional zum Ressourceneinsatz skaliert, stellt sich die Frage: ist es überhaupt digital?

Improvisationstalent & Perfektionismus

Häufig werden in analogen Prozessen übliche Designmuster in digitalen Modellen angewandt. Stellen Sie sich vor: sie stehen im Raffles Hotel in Singapur und wollen keinen Singapur Sling sondern einen Old Fashioned bestellen, der allerdings nicht auf der Karte steht. Sie werden trotzdem den Drink und eine Rechnung bekommen. Der Barkeeper hat also nicht nur ein Produkt geliefert, was es so im Produktkatalog nicht gibt, sondern auch einen Preis approximiert. In anderen Worten: er hat improvisiert – bisher können programmatische Applikationen das nur sehr eingeschränkt. Alles, was nicht explizit im abgebildeten Geschäftsprozess vorgesehen ist, lässt sich allein durch einen Algorithmus also nicht abdecken.

Sowohl die Skalierungsfähigkeit als auch die notwendige Ausdifferenzierung aller Geschäftsprozesse führen dazu, dass der Geschäftserfolg durch die Änderungsgeschwindigkeit maßgeblich mitbestimmt wird, denn jede Funktionalität mehr bedeutet potentiell sofortigen Businessnutzen und höhere Kundenzufriedenheit.

Wenn nur der Hammer zur Hand ist…

Digitale Transformationen werden häufig wie eine Produkteinführung betrachtet, also ohne entsprechende Implikationen auf Organisation und Zusammenarbeitsmodelle. Erfolgreiche Unternehmen, deren Geschäftsmodelle komplett digital ausgerichtet sind, haben neue Formen der Zusammenarbeit entwickelt, die sie bei ihren anhaltenden Bemühungen nach Effizienzsteigerung unterstützen.

Wasserfälle und ihre Stufen

Projekte nach dem Wasserfallvorgehen anzugehen ist aufgrund der tendentiell langen Latenzen zwischen Idee, Konzeption, Umsetzung, Test, Abnahme und Golive suboptimal, wenn man sich in Erinnerung ruft, dass erstens jede Funktionalität mehr konkreten Businessnutzen stiften kann und andererseits digitale Geschäftmodelle letzten Endes nahezu unbegrenzt skalieren können, wenn nur die Kundennachfrage besteht. Man sollte also bestrebt sein, neue Funktionalitäten möglichst schnell auszutesten (fail fast…) und möglichst schnell auf den Markt zu trimmen (… & iterate). Die meisten Bankkunden beispielsweise wollen keine neue Bank, sie wollen nur die neue Funktionalität, weil sie ihr Leben erleichtert. Wenn beispielsweise Fintechs also jahrelang Zeit haben, einen Kundenstamm aufzubauen, weil die Konkurrenz so lahmt, erscheinen Marktverschiebungen vor dem Hintergrund 18-36 monatiger Releasezyklen auf einmal als logische Konsequenz.

Prozessunterstützung oder Geschäftsmodell

Digitale Transformationen kranken oft auch an dem Verständnis von IT als Prozessunterstützung anstatt als Geschäftstreiber. Dieses Verständnis schlägt sich u.A. im Führen von IT Abteilungen als Kostenfaktor und entsprechendem lokalen Optimierungsdruck nieder. Lokale Optimierungen gehen häufig zulasten der Gesamtkomplexität und führen über die Zeit zu einem Sammelsurium an Workarounds oder Hacks, für die sich in modernen IT-orientierten Unternehmen der Begriff technische Schulden etabliert hat. Daten- und servicegetriebene Unternehmen, insbesondere solche mit rein intangiblen Produkten, sind letzten Endes aber nichts Anderes mehr als die Summe ihrer IT. Jede Abteilung für sich genommen kann mit mehr oder weniger großem Impact eine Woche zu Hause bleiben, aber wenn alle Computer aus sind, können alle zu Hause bleiben. Und zwar mit an Sicherheit grenzender Wahrscheinlichkeit endgültig.

Digitale Transformation und Governanceansätze

Die veränderten technologischen und organisatorischen Voraussetzungen ermöglichen aufgrund stringenterer Controllingmöglichkeiten völlig neue Governancemodelle mit stärker eigenverantwortlichem und kollaborativem Ansatz. Durch Aufwandsschätzungen, das Abgleichen von ad hoc Schätzungen und post hoc Messungen und dem Tracking der KPIs über die Zeit wird üblicherweise eine stetige Verbesserung sowohl der Schätzungen als auch der Menge der umgesetzten Story Points (atomare Schätzgröße für Implementierungsarbeiten) sichtbar. Die Entwicklungszeit korreliert für gewöhnlich mit stetiger Abnahme der Bug Tickets, d.h. der aufgetretenen und zu beseitigenden Fehler. Durch die deutlich verbesserte Eigenkontrolle in Verbindung mit kollaborativen Zusammenarbeitsmodellen ist nicht notwendigerweise eine externe Steuerung in bisherigem Maße notwendig. Die Zusammenarbeit sollte aber auch übergreifend deutlich kollaborativer aufgestellt werden, indem Product Owner auf den Fachseiten von Anfang an eng mit der Entwicklung zusammenarbeiten, anstatt ein Fachkonzept fragwürdiger Qualität über den Zaun zu werfen.

In der Eisenzeit der IT waren alle Systeme notwendigerweise mit physischer Hardware verbunden, was intensive und häufig repetitive manuelle Provisionierungs- und Wartungsarbeiten impliziert. In cloudnativen Architekturen sind die Systeme und Applikationen (teilweise auch Netzwerk etc.) von der physischen Infrastruktur abstrahiert, wobei Provisionierung und Wartung über hochgradig automatisierbare Backendschnittstellen an Software delegiert werden können. Änderungen können kurzfristig und revisionssicher vorgenommen werden, es ist möglich automatische Fallbackszenarien (bspw. zu einem gesichert funktionierenden Versions- und Konfigurationsstand) zu definieren und Change Management Prozesse können beschleunigt und auf das Wesentliche reduziert werden. Die vollautomatisierte Deploymentpipeline vom Entwicklungsrechner bis in die Produktion wird mit Continuous Integration bezeichnet und erlaubt Firmen wie Amazon und Netflix bis zu 120 Releases am Tag. Das Szenario von serverunabhängigen Applikationen wurde von Bill Baker von Microsoft durch den Aphorismus “Servers should be cattle, not pets” geprägt.

Agile Methoden

Die technischen und organisatorischen Möglichkeiten zusammen mit den Anforderungen an Änderungsgeschwindigkeit und Funktionalität haben in den letzten Jahren agilen Vorgehensweisen wie SCRUM starken Auftrieb verschafft und aus eigener Erfahrung können wir sagen, dass es sich von kleineren Umsetzungsprojekten bis hin zu Gesamttransformationen komplexer Bankenarchitekturen und Umsetzungen regulatorischer Anforderungen nicht nur hervorragend eignet, sondern insbesondere dem Wasserfallvorgehen in vielen Fällen deutlich überlegen ist.

BizDevOps

Die agilen Methoden mit kurzen Regelungsschleifen zwischen IT und Fachseiten führen zu besserem beidseitigem Verständnis, was zu höherqualitativen Implementierungen in kürzerer Zeit führt. Mitunter ist es sogar sinnvoll, den integrativen Prozess noch viel weiter vorne zu starten und den kompletten Produktzyklus mit den verschiedenen fachseitigen Abteilungen gemeinsam zu designen, also von Produktentwicklung bis zu Front- und Backoffice sowie ggf. Abwicklung bis hin zu Entwicklung und Betrieb.

In den allermeisten Fällen sind besser optimierte Prozesse in erster Näherung ausreichend. Das gilt insbesondere dann, wenn Arbeitsschritte parallelisiert werden können – die Erfahrung zeigt, dass selbst im Bankenumfeld Rechnungen auf dem gesamten Portfolio selten sind. Wenn Sie Ihre Applikationen zustandslos und parallelisierbar entworfen haben, sie also scale out anstatt scale up betreiben können, eine sinnvoll geschnittene Microservicearchitektur pflegen und vor dem Start der Implementierung einen guten Applikationsarchitekten mit dem Entwurf einer Modulplanung beauftragt haben, dann sollten Sie aufhorchen, wenn jemand in Ihrem Umfeld nach Big Data und In Memory Datenbanken schreit. Mit diesen Technologien wird häufig versucht, Implementierungsprobleme zu lösen, und nicht tatsächliche Performanceengpässe zu beseitigen. Oft ist eine Reorganisation der Batchprozesse und Prozesssteuerung deutlich sinnvoller zur Performancesteigerung. Mit Infrastructure as Code und elastischen Infrastrukturen kann der Ressourcenverbrauch sogar dynamisch den Anforderungen angepasst werden, Maschinen und Applikationen müssen also nur dann laufen bzw. hochskaliert werden, wenn die Kapazität tatsächlich gebraucht wird. Die Architektur muss also nicht mehr generell auf Peaklast ausgelegt sein.

Wenn Sie Ihre neue Infrastruktur planen, denken Sie an Antoine de Saint-Exupèry: Perfektion ist nicht dann erreicht, wenn es nichts mehr hinzuzufügen gibt, sondern wenn man nichts mehr weglassen kann.

Der Beitrag ist als Vortrag am 3. November 2016 auf dem IT Application Performance Day auf dem COREcampus gehalten worden.