Die Analysten von Gartner probieren sich an der Thematik1 genauso wie Geschäftsführer mittelständischer Unternehmen mit Innovationsprojekten. Stark vereinfacht gilt für die Digitalisierung: Der Wechsel von Papier zu Dateien, von physischen Gegenständen zu elektronischen Signalen.

Papier ist geduldig, sagt man. Dateien und elektronische Signale sowie mit diesen verbundene Backup-Strategien können gerne mit dem Gegenteil beschrieben werden. Die Digitale Transformation beschreibt exakt jenen Wandel, auf den wir in seiner Vollumfänglichkeit nun gefühlt schon einige Zeit warten. Aber die Vorstellung, dass mit der Digitalisierung alle Unterbrechungen und Wartezeiten der analogen Welt der Vergangenheit angehören, kann gerne bezweifelt werden. Ohne eine erneute & weitreichende Automatisierung der Prozesse ist die Digitale Transformation nur ein schöner Gedanke.

Während die fortschrittlichen Länder wie Estland das Papier im Staatsbetrieb weitestgehend abgeschafft haben und auch die Unterschriften Zertifikatsdateien weichen mussten, laufen viele Prozesse zwar digital aber dennoch mit händischen Abgleichen, manuellen Übertragungen und abschließenden Bestätigungen ab. Jeder, der schon mal eine Excel Tabelle in eine andere kopieren musste, weiß was der Euphemismus semiautomatisiert bedeutet. Gleiches gilt für den reibungslosen Betrieb von Diensten, die wir aus der Cloud in Form von SaaS Applikationen beziehen. Im Hintergrund ist davon längst nicht alles so automatisiert wie man annimmt. Oft entscheidet die tägliche Arbeit von IT Professionals mit detailliertem Monitoring und Logging sowie pro-aktiven Wartungsfenstern, ob die Applikationen reibungslos zur Verfügung stehen und sich alles automatisch anfühlt.

Eins haben aber alle modernen Digialisierungslösungen gemeinsam — ohne Schnittstellen wäre der Traum von der vollautomatisierten Welt nur halb so realistisch. Selbst die großen Public Cloud Provider geben als größten Vorteil nicht das Skalieren ins quasi-Grenzenlose sondern ihre Schnittstellen an, mit denen die einzelnen Dienste programmatisch gesteuert werden können. Erst diese Schnittstellen geben dem modernen Techniker die Möglichkeit auf Cloud Infrastruktur basierende Anwendungen so zu gestalten, dass diese für den Endanwender automatisch sind. Die Arbeit mit diesen Schnittstellen auf intelligente Art und Weise ist der erste Schritt einer langen Reise — und bereits eine Mammutaufgabe für sich. APIs ändern sich gerne mal, ohne entsprechenden Release und API Management ist die Automatisierung von gestern heute nicht mehr funktionsfähig und nicht mal den Speicherplatz wert.

Warum ist die Deutung und das gemeinsame Verständnis von Digitalisierung und Automatisierung so schwierig? Beides hat es schon mal gegeben. Das Papier wurde doch schon mal abgeschafft, aber in den allermeisten Fälle nur durch weiterhin statische Dateien ersetzt. Bei der ersten Welle an Automatisierungen haben wir die industrielle Revolution mit ihren Dampfmaschinen oder den Ford’schen Fertigungsstraßen vor unserem geistigen Auge. Beides liegt so weit zurück, dass sich ein gemeinsames Verständnis im historischen Rückspiegel entwickeln konnte. Für die aktuell laufenden Prozesse gilt das noch nicht. Auch wenn die EDV vor mehr als 25 Jahren mit dem flächendeckenden Einzug in die Büros dieser Welt begonnen hat, fehlt es in den Details immer noch an Überzeugungskraft, dass durch die Technologisierung wirklich alles besser wurde.

Mit Blick auf das anvisierte Ziel einer durchgehend automatisierten Welt, sind also viele Prozesse zu definieren, Schnittstellen zu entwicklen und Systeme zu pflegen. Zusätzlich müssen die Daten in den jeweiligen Systemen kompatibel zu den anderen Diensten sein. Denn nur, wenn die Daten und Datensätze systemübergreifend verarbeitbar vorliegen, können diese auch automatisiert weiterverwendet werden.

Was in abstrakten Konzepten (wie diesem Artikel) mit drei knackigen PowerPoint Folien von Slide Engineers einfach gesagt ist, sieht in der technischen Realität ganz anders aus. Die Widrigkeiten von IT-Systemen mit ihren properitären Datenmodellen und Schnittstellen sowie Technologien aus unterschiedlichen Epochen sorgen für ihre ganz eigenen Herausforderungen. Details wie der lästige Unterschied zwischen synchronen und asynchronen Datenübergaben sind hier eher technische Details, die gerne vernachlässigt werden.

Allerdings haben alle diese technologischen Visionen eins gemeinsam: Alles, was später automatisiert ablaufen soll, muss vorher konzeptioniert und implementiert werden. Ein großer Teil der Arbeit verlagert sich von der späteren Umsetzung und dem Doing in die vorhergehende Architektur und den Betrieb der Systeme. Spätere Änderungen von Details im fertigen System müssen bei dem generalstabsmäßig gewählten Ansatz vorher berücksichtigt werden — oder führen zu einem aufwendigen Anpassungs- und Änderungsprojekt.

Welche Technologien treiben die Digitalisierung und nächste Welle an Automatisierungen im Detail? Insert your Tech Buzz Word here. Aber ohne die folgenden Technologiegruppen, wären die späteren Anwendungen der Zukunft, egal ob Blockchain, AI mit ML-Netzwerken und Deep Learning, (I)IoT, Fog Computing oder RPA (Robotic Process Automation) nicht denkbar:

Sie sind die Zutaten für die Digitale Transformation und die nächste Generation an Automatisierungen.

APIs und API-first Entwicklung

Während früher über eine Schnittstelle (application programming interface) zur Kommunikation mit externen Systemen gerne nachträglich nachgedacht wurde, setzen moderne Entwicklungen auf einen sogenannten API-first Ansatz. Jeder interne Funktionsaufruf verwendet bereits Klassen & Funktionen, die über eine Schnittstelle zur Verfügung gestellt werden. Das grafische Interface wird somit zur ersten pseudo-externen Entwicklung. Während diese modulare Architektur zu mehr Flexibilität und einer besseren Wartbarkeit des Codes führt, ist ein größerer Aufwand bei der Architektur und Planung notwendig. Gleichzeitig wird der verwendete Technologie Stack meistens um Komponenten wie Message Broker und interne Taskmanager erweitert - denn das Programm muss schließlich wissen, ob die API Befehle angekommen und richtig verarbeitet sind.

Gleichzeitig hat dieser Ansatz zu einer Vielzahl von Schnittstellen geführt, die öffentlich dokumentiert sind (https://www.programmableweb.com zählt fast 20k APIs) und wiederum eigene Dienste in Form von API Brokern mit ihren Low- und No-Code Ansätzen hervorgebracht hat. Egal ob selbst gehostet in Form von Node-RED über Zapier und Built.io – ein wenig Verständnis wie Programme kommunizieren müssten, reicht aus, um zwei Dienste miteinander zu verschalten. Dass man auf diesen Plattformen in den seltensten Fälle wirkliche steuern kann, wann exakt die Daten übertragen werden und Debugging nur spartanisch zur Verfügung steht, kann nicht über den Fakt hinwegtäuschen, dass Public APIs2 mit all ihren Anwendungszenarien gekommen sind, um zu bleiben.

Infrastructure as Code

Was früher händisch, Zeile-für-Zeile konfiguriert wurde, muss heute immer wieder abspielbereit als Konfigurationsdatei zur Verfügung stehen. Systeme sind nur skalierbar, wenn die technische Beschreibung in von Maschinen-lesbaren Formaten vorliegt. Die unterschiedlichen Konzepte im Bereich der Contionous Configuration Automation setzen wahlweise auf Agents oder direkte Logins bzw. Push/Pull Methoden und versetzen den modernen DevOps Engineer und Technik-Verliebten in Verzückung. Aber ohne das abstrakte Konzept hinter Chef, Puppet, Ansible und Co. wären automatische Deployments, die für komplexe Systeme benötigt werden, ebenfalls nur ein schöner Traum.

Container Technologie

Obwohl der flächendeckende Einsatz von virtuelle Maschinen für einen großen Schub im Bereich der Flexibilität beim Betrieb von IT-Systemen führte, war relativ schnell klar, dass es immer noch einen gewaltigen Overhead in Form des Betriebssystems gibt. Jeder virutelle Server, auch wenn am Ende nur eine kleine Website mit einem Webserver betrieben werden soll, braucht immer ein Linux/Windows/Operating System unten drunter. Die Idee auf einem Host/Server mehrere kleine Anwendungen zu betreiben, sorgte für den Siegeszug der Container Technologie. Auch wenn Docker gerne Synonym für Container verwendet wird, gibt es noch andere Anbieter wie Rocket oder LXD, die nach dem gleichen Prinzip arbeiten: Ein Host, viele kleine Container für einzelne Anwendungen.

Gleichzeitig führen Dienste, die in Containern betrieben werden, zu Herausforderungen im Bereich des Deployments mit ihren automatischen Konfigurationen, der Netzwerk-Konnektivität (schließlich sollen Container untereinander kommunzieren können) oder im Bereich der Skalierung. Google hat die Container Technologie bereits vor einigen Jahren gemeistert3: Jede einzelne Google-Suche, egal von welchem Endgerät auf der Welt, ist ein eigener Container. Auf diese Art und Weise, kann Google extrem leicht gigantische A/B-Tests durchführen und beispielsweise ein leicht geändertes Design einfach für einen Teil seiner Nutzer zur Verfügung stellen. Anschließend wird ausgewertet welches Design zu mehr Werbeeinnahmen führt und dann auf alle Nutzer angewendet. Automatisch, versteht sich.

Auf der anderen Seite zeigt Googles Schritt seine Container Orchestrationsplattform Kubernetes als Open Source zur Verfügung zu stellen, dass die mit Containern einhergehende Komplexität zu Entwicklungskosten führt, die Google auch nicht alleine schultern möchte und sich hier dem beliebten Community Ansatz zuwendet.

Microservices / Serverless Functions

Dabei sind Container aus Enticklersicht eigentlich nur ein Zwischenschritt – in einer perfekten Welt übernimmt ein sogenannter serverloser Microservice die Aufgabe den Code auszuführen. Der Fakt, dass im Hintergrund wieder ein mit Konfigurationsdatei gesteuerter Container gestartet werden muss, verschwindet aus Sicht des Anwenders. Sichtbar bleibt die Funktion, die nur noch bei Bedarf ausgeführt wird. Kein Wunder also, dass Analysten den Anbietern für diese Art von Funktionen ebenfalls ein großes Wachstum vorhersagen4. Ob sich ein Unterschied zwischen Microservices mit Blick auf zugesicherte SLAs zu Serverless Functions durchsetzen wird5, bleibt zu abzuwarten

Mit Hilfe von Microservices können noch leichter hochskalierbare loosley coupled Systeme realisiert werden. Jeder Aufruf bzw. jede Anfrage wird in einem parallel gestarteten Dienst (also Container) verarbeitet. Gleichzeitig muss auch hier wieder der Betrieb der Microservices zu Grunde liegenden Systemen von jemanden, übernommen werden. Gut, dass hier die etablierten Cloud-Anbieter ebenfalls helfen können.

Nicht nur für den Betrieb der zuvor genannten benötigten Komponenten sondern für alle automatisierenden Systeme gelten, wie bereits angedeutet, ganz eigene Regeln: Sicherheitsupdates, geänderte Funktionen der genutzten Schnittstellen führen zu notwendigen Anpassungen, Hardware Ausfall/Hersteller Austausch, Redundanz-Konzepte für den reibungslosen Betrieb, Service, Wartungsfenster, verwendete Dienste und Komponenten „gehen“ EoS/EoL etc. pp. Die einfache/sich wiederholende Arbeit wird sicherlich weniger, aber ob alles besser wird? Für Befürworter von Systemen, die im Bestfall so gut wie autonom die Arbeit erledigen, sicherlich. Aber eins ist sicher: Unsere Arbeitswelt wird agiler.

Während vorher eine Schar von Mitarbeitern mit repetitiven Aufgaben beschäftigt wurden, ziehen heute Entwicklungsteams von Herausforderung zu Herausforderung und automatisieren im Namen der Digitalen Transformation exakt diese Aufgaben. Dass diese Systeme trotz sich abzeichnender Best Practices der Industrie nur noch von wenigen Spezialisten gewartet & weiterentwickelt werden können, verlagert die Abhängigkeitsverhältnisse innerhalb der Workforce eines Unternehmens zwar von vielen auf wenige Mitarbeiter, sorgt aber für eine ganze eigene Art des Lock-ins.

Eins ändert sich aber definitiv für alle: Die Vielzahl von immer raffinierteren Automatisierungen, die für die Digitale Transformation notwendig sind, lassen unsere Welt ein weiteres Mal schneller werden. Um auf diese Änderungen besser vorbereitet zu sein, gilt nicht umsonst agile everything als neues Unternehmensparadigma.

  1. https://www.gartner.com/podcasts/make-digital-business-transformation-a-practical-reality/
  2. https://www.programmableweb.com/news/gartner-clarifies-where-api-economy-heading/analysis/2017/03/07
  3. Google Präsentation aus Mai 2014: https://speakerdeck.com/jbeda/containers-at-scale
  4. https://www.cbinsights.com/research/serverless-cloud-computing-expert-intelligence/
  5. https://www.stratoscale.com/blog/compute/keeping-small-serverless-functions-vs-microservices/