Komplexität kommt in Wellen

IT-Generalisten sind zwar in Managementfunktionen gefragt, aber die wirklichen Konfigurations- und Implementierungsarbeiten können nur von Spezialisten in der notwendigen Qualität durchgeführt werden.

Die spannende Frage, die sich stellt: Verschwindet diese generelle Undurchsichtigkeit wieder und könnte es sich lohnen, dem Drang Neues einzuführen, einfach mal nicht nachzugeben? Technik hat Lebenszyklen und manch stark gefeierte Technologie befindet sich nach wenigen Jahren wieder auf dem Weg aus den Unternehmen. S-Adaptionskurven drehen später unweigerlich um. Und alles was durch die Chasm¹ gekommen ist, geht auch wieder in eine. Ich spare mir an der Stelle die Pferde/Automobil-Beispiele und verweise stattdessen auf Bandsicherungen, ISDN-basierte Telefonanlagen und die Idee, neue Applikationen ohne Legacy Schnittstellen im Jahr 2020 ohne Berücksichtigung eines potenziellen Betriebs in der Cloud zu entwickeln.

Dabei spielt es keine Rolle, ob die Software-Seite mit Unternehmen wie SAP, Salesforce, VMware oder Microsoft inklusive der Vielzahl an Produkten betrachtet wird oder wir versuchen die Hardware Hersteller wie Cisco, HP Enterprise oder Dell etc. mit ihren Roadmaps zu begreifen. Noch komplexer wird es, wenn zusätzlich noch die großen Cloud Provider Amazon, Google, Microsoft/Azure oder IBM analysiert werden sollen — denn wirklich alle Unternehmen haben Partnerprogramme, Eventserien, Zertifizierungswege und quasi-unendliche Feature Pipelines. Sollte jemand den gewagten Versuch unternehmen (wollen) sich auch nur bei den genannten Unternehmen ein State of the Art Wissen anzueignen, hat diese Person einen strammen Reiseplan und eine Vielzahl von Flugmeilen vor sich. Zusätzlich könnte die Person am Ende des Jahres das Gefühl beschleichen, dass die US-Westküste seine zweite Heimat geworden ist. Folgende Events — allesamt mit eigenständigen und meiner Meinung nach gar nicht mal schlecht gewählten Brands — haben die genannten Hersteller im abgelaufenen Jahr (2019) veranstaltet:

IBM Think, Februar in San Francisco (26.000 Teilnehmer)
Dell Technologies World, April in Las Vegas (15.000 Teilnehmer)
Google Cloud Next, April in San Francisco (30.000 Teilnehmer)
SAP SAPPHIRE, Mai in Orlando (30.000 Teilnehmer)
Cisco Live!, Juni in San Diego (30.000 Teilnehmer)
HP Enterprise Discover, Juni in Las Vegas (10.000 Teilnehmer)
VMware VMworld, August in San Francisco (21.000 Teilnehmer)
Salesforce Dreamforce, November San Francisco (170.000 Teilnehmer)
Microsoft Ignite, November in Orlando (30.000 Teilnehmer)
AWS re:Invent, November in Las Vegas (60.000 Teilnehmer)

Natürlich lassen sich alle Informationen dieser Veranstaltungen mit Hilfe von nachgelagerten Webinaren und Beiträgen im Internet zusammentragen. Allerdings werden diese Events gerne genutzt, um die großen Ankündigungen im Rahmen von Keynotes öffentlichkeitswirksam zu präsentieren. Wie groß der erhoffte Marketingeffekt sein soll, lässt sich gut an der von Salesforce organisierten Dreamforce erkennen: Mit Barack Obama als Gast-Speaker² in der letzten Auflage wurde hier längst das nähere IT-Umfeld verlassen. Und die genannten Veranstaltungen sind nur ein Teil des Marketing-Eisbergs. Zusätzlich bieten die Technologieunternehmen noch eine Vielzahl von kleineren regionalen Ablegern der Hauptveranstaltung, Meetups in den jeweiligen Offices sowie Partnerveranstaltungen in unterschiedlichen Größen, die teilweise mehr von den geplanten Features und Funktionalitäten der Produkte preisgeben. Denn nur so können die Partner, welche die Implementierung mit ihren Spezialisten in den meisten Fällen durchführen, die Kunden optimal betreuen und beraten. Die vorderste Front der IT-Technologie fordert neben einer unersättlichen Neugierde somit ihre ganz eigenen Reiseopfer.

Studiert man die Konferenzpläne mit allen angebotenen Vorträgen und Workshop Sessions wird schnell klar, dass eine Person alleine nicht nur zeitlich alle Details aufnehmen kann — vom Verarbeiten gar nicht erst zu reden. Die Komplexität auch nur innerhalb eines Produkts bietet bereits genug Raum für eine Vielzahl von Unterspezialisierungen. Nur mit diesem Spezialwissen können die letzten Konfigurationsmöglichkeiten genutzt und so die entsprechenden Systeme voll ausgereizt werden.

—

Eine spannende Erkenntnis aus der eigenen Arbeit mit vergleichbaren Technologien verschiedener Hersteller ist, dass selbst das Know-How innerhalb einer Produktkategorie nur bedingt adaptiert und bei einem anderen Hersteller angewendet werden kann. Die Public-Cloud-Anbieter stellen stets ähnliche Funktionen — auf einer sehr abstrakten Ebene Compute & Storage — zur Verfügung, die sogar mit Cloud Management Platforms (CMPs) ein Stück weit homogenisiert werden können, sind aber so unterschiedlich bezeichnet, dass es definitiv Senior-Level-Erfahrung braucht, um aus einem AWS-Crack einen guten Microsoft Azure-Consultant werden zu lassen, ohne vorher in dediziertes Training zu investieren.

Des Weiteren sprechen die Experten an den Grenzbereichen zwischen zwei Technologien nicht immer die gleiche Sprache. Ein Beispiel aus dieser Kategorie sind Lösungen für Application Performance Monitoring (APM) und Network Performance Monitoring (NPM). Beide Arten von Lösungen sollen dabei unterstützen, dass Anwendungen reibungslos genutzt werden können. Techniker schauen ebenfalls in beiden Tools auf vergleichbare Metriken wie Latenzen und Datenpakete, präsentieren aber auf die Frage wie ein aus den Messdaten „erkanntes“ Problem gelöst werden kann, sehr unterschiedliche Lösungsansätze. Die Experten des ersten Feldes sind oft für ein Refactoring der Applikation, während die Netzwerkspezialisten den Datendurchsatz mit mehr Bandbreite (also besserem Netzwerkequipment oder Konfigurationsoptimierungen) steigern möchten. Technisch gesehen wird zu Recht argumentiert, dass ein APM Tool vor allem den OSI Layer 7 (also die Anwendung) analysiert und NPM Lösungen einen Fokus auf Layer 2 und 3 – also den Transportweg der Datenpakete – legen. Am Ende würde vermutlich eine Optimierung auf beiden Seiten für die größte Verbesserung sorgen.

Gibt es für die scheinbar kaum zu bewältigende Komplexität einfache Lösungen? Wahrscheinlich nicht. Es gibt ein paar gute Ideen, die aktuell in den großen Unternehmen und Public Sector Organsiationen ausprobiert werden: Die Einführung von weiteren Chef IT-Generalisten in Form Chief Digital Officers (CDOs) und Chief Information Security Officers (CISOs) zur Unterstützung von CIOs/CTOs, Enterprise-Architecture-Lösungen für mehr Transparenz im IT-Stack der Unternehmen oder die radikale Shift zur agilen Paradigmen, um die einzelnen Mitarbeiter mehr in die Pflicht zu nehmen³. Aber oft entsteht das Gefühl Buzz mit mehr Buzz lösen zu wollen. Es erklärt aber auch mit einem Nachdruck die Bedeutung von technischen Analysten wie Gartner, IDC und Forrester Research. Und auch, dass CIOs und ausschreibende Entitäten mit viel Erleichterung zu den Magic Quadrants (Gartner) und Wave Reports (Forrester) der Analysten greifen, um überhaupt herauszufinden, welche Hersteller bei einer Neubeschaffung in Frage kommen könnten. Zur besseren Orientierung haben die Koordinatensysteme der Analysten eine Gemeinsamkeit: Rechts oben is the place to be. Das Zurate ziehen von Analystenmeinungen ist innerhalb der IT-Welt keinesfalls eine Neuigkeit, sondern um eine gelebte Realität der letzten Jahr(zehnt)e und das vorherrschende Szenario, um sich bei Einführung neuer Technologien oder Lifecycle Maßnahmen zu orientieren.

Aber auch bei den Analysten ist Bewegung zu erkennen. CB Insights fordert aktuell⁴ die zuvor genannten und etablierten Anbieter heraus. Der durch CB Inights gespielte Angle, um sich vom Markt zu unterscheiden: Die konsequente Analyse von Daten wie das Auswerten von Earning Transcripts, automatisiertes durchsuchen von Patentdatenbanken, Erwähnungen in den öffentlichen Medien und das Tracken von Startup Funding werden in den Mittelpunkt der Arbeit gestellt. Zusätzlich wird der Fokus auf gerade aufkommende Technologien gelegt, um die nächste Disruption unter keinen Umständen zu verpassen.

Eine persönliche Erfahrung aus dem letzten Monat hat mich in diesem Kontext überrascht. Während eines Vortrages zu den Software-Entwicklungsaktivitäten bei avodaq, den ich für Planer gehalten habe, fragte ich, wem CB Insights bereits bekannt ist. Das Planer-Publikum war eher Mitte 40 und älter, ausschließlich männlich und allesamt national sowie auch international (europaweit) erfolgreich tätig. Die Aufgabe eines Planers ist es, als externer Experte die großen Unternehmen (Enterprise) bei Ausschreibungen, der Definition der technischen Anforderungen, bei der Bewertungen der eingereichten Angebote und den den Bietergesprächen zu unterstützen. Zusätzlich sind die Planer meistens auf eine Technologie wie Netzwerk, Datacenter oder Collaboration spezialisiert. Ich rechnete fest mit 80% an Meldungen und wollte mit der Nachfrage „wer denn bereits einen super teuren⁵ Account nutzt" meinen Punkt machen, da ich von keinen Meldungen ausging. Am Ende kannte einer meiner avodaq Kollegen CB Insights und mein Witz, dass das Produkt von Anand Sanwal und seinem Team das nächste Gartner wird, verpuffte im Raum. So fühlt sich also das ungewollte Platzen seiner eigenen Filterblase an.

—

Die allgemeine Erkenntnis im Umgang mit Informationstechnologie ist wohl, dass es immer das Etablierte und das Neue gibt. Das Neue wartet stets auf den Durchbruch, um das Etablierte erst langsam aber dann mit immer schneller werdender Geschwindigkeit zu verdrängen. Die schwierigste Aufgabe ist zu erkennen welche Technologie von welchem Hersteller sich wann durchsetzen wird. Gartner versucht diese Aufgabe unter anderem mit seinen Hype Cyclen und IT Market Clocks⁶ zu lösen. Jedoch wird die Beantwortung dieser Fragen ungemein schwieriger, wenn es noch konkurrierende Produkte gibt und alle Lösungen vergleichbare Vorteile bieten. Oft gewinnt nicht das beste Feature Set, sondern der Hersteller, der die Marketingklaviatur besser beherrscht und so die Adaption seiner Produkte besser in den Unternehmen vorantreiben konnte.

Mit Blick auf die Themen, die auf den oben genannten Konferenzen aktuell präsentiert werden, gibt es einige Beispiele auch aus meinem Umfeld, in denen sich die Gewinner und neuen Konzepte bereits durchgesetzt haben oder sich eine belastbare Prognose über einen zukünftigen Sieger abgeben lässt. Auf die nachfolgenden Technologien habe ich vor 18 Monaten einen Ausblick gegeben, in denen sich die Anwendungsmöglichkeiten inzwischen konkretisiert haben.

Container & Container Management

Das Konzept serverseitige Applikationen nicht mehr direkt auf virtuellen (oder gar physischen) Servern zu betreiben und so die zur Verfügung stehenden Ressourcen durch clevere Segmentierung effizienter nutzen zu können, ist inzwischen gesetzt. Wie allerdings diese Aufteilung durchgeführt und physische und/oder virtualisierte Server zu Clustern zur besseren Kontrolle zusammengefasst werden sollen, dafür gibt es eine Vielzahl von Antworten, die meistens Pivotal CloudFoundry oder Kubernetes in den unterschiedlichen Geschmacksrichtungen wie zum Beispiel RedHats OpenShift beinhalteten. Seitdem Google sein Container Management Kubernetes der Open Source Community übergeben hat, ist das in der Szene K8s abgekürzte Ochestrationstool für Container wohl der Sieger – und mit ihm die Container aus dem Hause Docker. Auch in den Erwähnungen im Rahmen von Earnings Calls ist der rasante Aufstieg von Kubernetes zu beobachten.⁷ Wie bereits geschrieben arbeitet Dynatrace mit Keptn⁸ an seinem eigenen Kubernetes Management Use Case und versucht mit Hilfe der Integration von anderen Open-Source-Projekten wie Helm⁹ und Istio¹⁰ seinen Traum NoOPs (also nur noch Dev) und Autonomen Clouds (ACM) zu realisieren. Full Disclaimer: Auch mit avodaq testen wir aktuell die erste mit Keptn verwaltete und gesteuerte Lösung auf Kubernetes-Basis.

Da moderne Software nicht mehr nur aus dem Quellcode und einem halbjährlichen Update-Prozess besteht, kommt hier der entscheidende Vorteil von Management- und Orchestrationslösungen zu tragen. Software wird und soll in jedem Augenblick aktualisiert werden können. Diesen Aktualisierungsprozess sowie den tatsächlichen Betrieb mit einem Framework zu vereinheitlichen, soll die Komplexität beherrschbarer werden lassen, da die Applikation als Ganzes betrachtet werden kann: Von der geschriebenen Zeile Code über das Deplyoment bis hin zu automatisierten Eingriffen, wenn es im Monitoring zu Problemen kommt.

CI/CD Automatisierung und Pipeline Monitoring

Wie gerade angedeutet sind manuelle Deployments von Software Updates weiterhin auf dem Rückzug. Sie nehmen sowohl viel Zeit in Anspruch und sind zusätzlich bei den durch Menschen ausgeführten Schritten fehleranfälliger. So gut wie alle aktuellen Softwarelösungen durchlaufen komplexe Test- und Build-Prozesse bevor diese in QA/Test-, Staging- und Live-Systemen installiert bzw. deployt werden. In den meisten dieser Pipelines werden für die einzelnen Stufen/Stages inzwischen ebenfalls Container eingesetzt und die Artifacts, die Ergebnisse des jeweiligen Prozessabschnitts, zwischen den Stufen solange weitergegeben und modifiziert, bis eine lauffähige Software entsteht. Für die Gesamtorchestrierung der dynamisch zu konfigurierenden Infrastruktur setzen die Entwicklungsteams auf Dienste wie Chef, Puppet oder Ansible. Und auch auch hier sieht es so aus, dass RedHats Ansible sich wohl als Gewinner durchsetzen wird.¹¹

Gleichzeitig sind diese komplexen Pipelines auf Grund ihrer Vielzahl von Abhängigkeiten nicht davor geschützt, von einem auf den anderen Tag nicht mehr wie gewohnt zu funktionieren. Ein Beispiel sind aktualisierte Docker Container Images, die in der neuen Version mit anderen vorinstallierten Paketen eingesetzt werden. Ein Paket, welches gestern noch standardmäßig installiert war, muss nun mit einem zusätzlichen Command geladen werden. Diese bedingt wiederum eine Aktualisierung der entsprechenden Pipeline-Stufe.

Pipelines sind solange eine gute Antwort wie sie zuverlässig funktionieren. Das Überwachen von Pipeline-Prozessen wird somit ein immer wichtiger Teil des Betriebs der Lösungen.

Microservices - „serverless” - Function-as-a-Service

Das Aufbrechen von Legacy-Anwendungen in modulare, locker miteinander verbundene und leichter zu aktualisierende Dienste wird bereits seit einiger Zeit besprochen. In einem potenziellen serverlosen Endszenario soll so vollständig auf einen „Server“ mit seinen notwendigen System-Updates und Wartungsfenstern verzichtet werden können. Allerdings hat die Flexibilität von Containern den Traum von serverlosen Applikationen erst möglich werden lassen. Im Hintergrund eines jeden Microservice-Aufruf wird nämlich ein Container gestartet. Die Administration von Hardware, Virtualisierung, Container Host und das Container Management übernimmt in diesem Fall der Cloud-Anbieter, bei dem der Microservice betrieben wird. Wenn Werner Vogels erst vor kurzem wieder erklärt, warum Microservices die Zukunft gehören und warum Amazon seine Shopping-Plattform von einem Monolithen in viele separate Dienste aufgeteilt hat¹², komme ich mir manchmal vor, als ob (s)eine Platte im Loop liefe. Gleichzeitig hat Werner den Grund, warum der konsequente Wechsel zu einem neuen Architekturprinzip so schwierig ist, selbst genannt: Es ist am Anfang sehr viel einfacher einen Monolithen mit einem Webframework wie Django zu entwickeln. Erst später, wenn eine wirkliche Skalierung notwendig ist, fällt einem bei diesem Design das schwächste Glied immer wieder auf die Füße. Bei einer traditionellen Applikationsarchitektur bestimmt der meist-belastete Dienst die Größe des (virtuellen) Servers. Zusätzlich lässt sich mit einer Microservice-Architektur leichter auf Anfragen und Aufrufe von global verteilten Nutzern antworten. Die entsprechenden Dienste können immer nahe dem Nutzer gestartet und die Anfragen müssen nicht mehr zu einem zentralen Server geleitet werden.

Es ist zu beobachten, dass die Diskussion zu den verschiedenen Begriffen¹³ im Microservice Kosmos noch nicht abgeschlossen ist. „Serverless“ ist in letzter Instanz nie wirklich ohne Server. Er wird nur von jemand anderen gewartet. Wann ist ein Microservice so klein, dass er als „Function-as-a-Service“ bezeichnet werden kann? Ich denke die Grenzen werden hier fließend bleiben und auch in Zukunft von Team zu Team definiert werden.

Gleichzeitig sorgt die Transition hin zu modularen Applikationsarchitekturen für ihre ganze eigenen Herausforderungen. Damit die reinen Funktionen tatsächlich aufgerufen werden können, müssen Zugriffe und Berechtigungen entsprechend vergeben, bei den Cloud Providern gepflegt und sicherheitstechnisch überprüft werden. In frühen Konzeptionsphasen und ersten Prototypen wird schnell ein Haken zu viel gesetzt, um die sich gegenseitig aufrufenden Funktionen interagieren zu lassen. Sobald Lösungen jedoch produktiv genutzt und dann auch extern erreicht werden müssen, sollten alle Zugriffe entsprechend beschränkt und natürlich die Architektur der gesamten Lösung sinnvoll dokumentiert sein. Während es bei monolithischen Systemen mit entsprechendem Aufwand durchaus möglich ist, sich mit Hilfe einer Analyse des Live-Systems die Funktionsweise der Anwendung zu erklären, wird das bei reinen Microservice-Architekturen schnell zu einer nicht mehr lösbaren Aufgabe – vor allem wenn mehrere Cloud-Anbieter und eine Vielzahl nur per API aufgerufener Dienste beteiligt sind.

Nichtsdestotrotz überwiegen aus meiner Sicht die Vorteile den Mehraufwand. Während in einer klassischen Architektur das Ende von Kapazitäten immer sicher ist, bietet der Microservice Ansatz die notwendige Luft nach oben. Gleichzeitig lässt sich durch die Tatsache, dass Microservices nur gestartet werden, wenn diese wirklich benötigt werden, die physischen Ressourcen sehr viel effizienter nutzen. Dies führt langfristig zu einem geringeren TCO (Total Cost of Ownership).

—

Die drei genannten Themen sind offensichtlich eng mit einander verbunden, verdeutlichen aber die Komplexität der Situation. Experten in einem Gebiet sind mitunter nur Novizen in den anderen Technologien. Gleichzeitig setzen Unternehmen die beschriebenen Lösungen immer intensiver ein und benötigen somit fundiertes Wissen bei der täglichen Arbeit.

Die Fähigkeit solche Veränderungen im Markt frühzeitig zu antizipieren, wird meiner Ansicht nach immer wichtiger. Consultants und Partner werden in Zukunft mehr dafür bezahlt, dass sie zum einen erkennen wo „Vorne“ ist bzw. in einer nahen Zukunft sein wird, aber auch auf drohende „Enden“ rechtzeitigen hinzuweisen. Unternehmen und die eingesetzte Technologie in diesen sind wie Organismen und bedürfen der fortlaufenden Erneuerung, um nicht als lebloses Teil irgendwann abgestoßen oder gar als Ganzes überflüssig zu werden.

Auf der anderen Seite des Spektrums gibt es das „new cool Kid on the Block“-Phänomen. Die Features der neuen Lösung adressieren bekannte Pain Points und der Messias scheint nah zu sein. Aber hat die neue Lösung auch die notwendige Luft eine lang andauernde Adaptionsreise durchzuhalten? Single Maintainer, keine Visibilität im Markt, keine Community, keine Partnerökosysteme? Das alles sind schlechte Anzeichen für langfristigen Erfolg, erklärt aber das quasi-gleiche Playbook der IT-Größen, welches zu Beginn skizziert wurde. Auf die Essenz herunter gebrochen: Marketing, Marketing, und ein weiteres Mal — Marketing. Nicht umsonst wird das Akronym sogenannter Sales Engineers (SE), auf Deutsch etwas langweilig, aber gleichbedeutend mit dem Vertriebsingenieur beschrieben, nicht ganz ernst gemeint mit Slide Engineer übersetzt. Die Ursache liegt auf der Hand. Auf Grund der massiven Komplexität von technischen Lösungen kann sich ein Produkt nur durchsetzen, wenn es verständlich erklärt werden kann. Und hierzu benötigt es eben technisch ausgerichtetes Marketing, Vorträge und eine Vielzahl von Slides.

—

Neben der Vielzahl von Super-Spezialisierungen gibt es aber auch universelle IT-Fähigkeiten, die einem etwas überraschend so gut wie immer weiter helfen: IP-Netzwerke, Routing und Switching, ein Verständnis für OSI-Layer, Linux-Kenntnisse inkl. Dateiberechtigungen, Bash Scripting, API Design und die (Basis-)Kenntnisse in einer modernen, funktionalen Programmiersprache wie Python, Ruby oder Go. Obwohl diese Kombination sich wie eine Basisausbildung in der IT liest, sind Kandidaten, die diese Fähigkeiten in einer gewissen Qualität neben einer Spezialisierung mitbringen, kaum zu finden. Hersteller und Partner geben ihren Engineers und Consultants schnell die Detailarbeit innerhalb von Produkten und die IT Basics rücken in den Hintergrund.

Und am Horizont — so wie immer — zeichnen sich bereits die nächsten Wellen an Technologien ab, die wohl in einem überschaubaren Zeitraum vor dem Durchbruch in den Massenmarkt stehen. Während die Giganten der IT (FAANG/FAMAG) bereits frühzeitig R&D Budget „verprassen“ als ob es kein Morgen gäbe, zögern die nächstkleineren Unternehmen noch mit Investitionen in diesem Bereich. Die ganz Großen der Technologie haben neben der Möglichkeit, beeindruckende Events zu veranstalten und Las Vegas in regelmäßigen Abständen zu einer IT-Pilgerstätte werden zu lassen, natürlich einen weiteren und entscheidenden Vorteil: Sie verfügen eben über die Budgets um extrem früh in R&D zu investieren. Der Schritt hilft nicht nur dabei ihren Vorsprung im Markt zu behaupten, sondern auch mit ihren Aufwänden Technologien überhaupt erst durch die Chasm und so zur Massenadaption zu treiben. Die nächst-kleineren, aber immer noch größeren Enterprise-Unternehmen scheuen früh in neue Technologien zu gehen und mitunter horrende Gehälter für Tech-Mitarbeiter zu zahlen, wenn unklar ist, ob sich die Technologie überhaupt durchsetzen wird. Ein anschauliches Beispiel ist, dass während des Blockchain-Hypes vor zwei Jahren Unternehmen bis zu 300.000 € Jahresgehalt für „Senior“-Entwickler in diesem Bereich zahlen mussten. Dabei hat die Distributed Ledger Technology zu diesem Zeitpunkt erst die Konzeptphase verlassen und Unternehmen für die IT (noch) kein Selbstzweck ist, überlegen sich sehr genau, ob ein so früher Einstieg in noch nicht wirklich erprobte Technologie schon sinnvoll ist. Gleichzeitig kann beobachtet werden, dass Unternehmen diese Frage nicht immer nur strategisch und analytisch treffen, sondern ein Stück weit von Opportunitäten getrieben werden. Ein cleveres Hiring, welches bereits Erfahrungen in diesem Bereich mitbringt oder ein tatsächlich noch besseres Produkt, welches durch einen Hersteller angeboten wird, bringen Unternehmen dazu neue Pfade einzuschlagen.

Gleichzeitig führen die Investitionen der Großen zu einem aus der Wirtschaft lediglich vermuteten Trickle Down¹⁴ Effekt in der IT, der in diesem Umfeld tatsächlich beobachtet werden kann. Alles, was in den R&D Labs von Google, Microsoft und Co. gezähmt wurde und anschließend in Best oder Good Practices¹⁵ dokumentiert wird, kann von den nächst-kleineren Unternehmen weiterverarbeitet werden. Zusätzlich engagieren sich die Großen stärker in Open-Source-Projekten¹⁶, die wiederum von allen anderen genutzt werden können. Und so wartet am Ende der erfolgreichen Adaptionsreise einer neuen Technologie, ein nicht zu vernachlässigender Wissensvorsprung auf Seiten der Großen: Auch wenn alle Unternehmen auf einmal Zugriff auf die gleiche Technologie und exzellente Leitfäden haben, besitzen nur die Innovators und die wirklichen Early Adopters bereits das notwendige Expertenwissen durch die bereits gesammelte Erfahrung. Durch dieses Know-How haben sie in Go-To-Market-Szenarien den entscheidenden Vorteil, dass sie bereits wissen, welches Geschäftsfeld von technischer Seite besser funktionieren wird und sichern so ihren kommerziellen Erfolg für die Zukunft.

—

Konferenzen, neue Technologien und Wellen — wie hängt das alles zusammen? Ein gutes Beispiel sind die nachfolgenden Themen, die sich wie ein Who is who im Buzzword Bingo lesen. Wie sich aber erahnen lässt, betrachte ich die Technologien aus einer bestimmten Perspektive: Auf Grund meiner Arbeit in einem spezifischen Kundensegment (großer Mittelstand bis mittlere Enterprise Unternehmen) interessieren mich Technologien besonders dann, wenn erahnbar ist, dass diese für meine Kunden relevant werden und zumindest in Ausblickssituationen berücksichtigt werden sollten.

Aktuell sehe ich folgende Technologien in absteigender zeitlicher Nähe für eine nachhaltige Adaption.

IPv6 als notwendige Grundlage für zukünftige Konnektivität

Damit zwei oder mehr Komponenten über ein Netzwerk wie dem Internet miteinander kommunizieren können, benötigen beide (unter anderem) eine Adresse. Das aktuell vorherrschende Protokoll für diese IP-Konnektivität lautet IPv4. Bereits 1995 wurde in der ersten technischen Beschreibung zu IPv6 erkannt, dass die in dem Protokoll IPv4 zur Verfügung stehenden Adressen bzw. Adressbereiche wohl zu klein sein könnten¹⁷. Warum es kein IPv5 gibt, kann hier nachgelesen werden.¹⁸

Der Hinweis, dass der neue Standard jetzt aber wirklich adaptiert werden muss, wiederholt sich schon seit einiger Zeit. Inzwischen ist jedoch das Limit der öffentlich im Internet vergebbaren IPv4-Adressen erreicht¹⁹ und mit Blick auf die Tatsache, dass in naher Zukunft noch eine nicht definierte Anzahl von IOT Geräten direkt mit dem Internet verbunden werden sollen, belegen die Notwendigkeit des Umstiegs. Während IPv6 im Service Provider Umfeld bereits erkannter und gelebter Standard ist²⁰, kämpfen andere noch mit der Integration. So ist das eigentlich moderne Kubernetes noch nicht so richtig sattelfest in IPv6²¹ Themen und auch Ciscos Zukauf Meraki kämpft den langen Weg der IPv6-Adaption²² innerhalb seiner Produktserie.

Auch wenn es niemand in den letzten Jahren einsehen wollte, mit IPv6 muss sich jeder auseinandersetzen, da das Ende der bekannten Fahnenstange tatsächlich erreicht wurde und ein Nachfolger schon lange in den Startlöchern steht. Spannend wird es vor allem dann, wenn in Zukunft alte Systeme, die aktuell noch sehr gut mit IPv4-Konnektivtät betrieben werden können, modernisiert werden müssen. Ich gehe davon aus, dass einige Systeme dann nicht nur leichte Anpassungen, sondern eher ein größeres Refactoring vor sich haben.

AI/ML und Deep Learning all the Things

Wenn Marc Andressen die technologisch-philosophische Frage stellt, ob es sich bei AI um ein Feature oder eine Plattform handelt²³ und Personen wie Tim Burton auf Wait But Why bereits vor fünf Jahren exzellente Primer²⁴ geschrieben haben, können wir inzwischen mit einem realistischen Gefühl einschätzen was mit künstlicher Intelligenz in Spezialfeldern erreicht und vorhergesagt werden kann. Abstrakt geht es aktuell um das Erkennen von Mustern in Daten, die in vorher definierten Wenn-Dann-Dann-Das-Schleifen zu mühselig zu automatisieren wären. Der große Wurf – egal ob vollständig selbst fahrende Autos oder tatsächlich eine allgemein-generelle künstliche Intelligenz – ist noch ein gutes Stück weit weg. In den Spezialfeldern hingegen, deren Parametrisierung ausreichend mit Best/Good Practices erforscht ist, werden Unternehmen massiv aufrüsten und versuchen Kosten einzusparen, in dem sie die Produktivität von Personen gegen TCO und ROI von AI-Technologien benchmarken. Wenn diese Betrachtungen zu zahlenbelegbaren Vorteilen der technischen Intelligenz führen, werden diese Prozesse durch AI-unterstützte Technologien und RPA-Anbieter (Robotic Process Automation) in Zukunft übernommen werden. Dieses konnten wir bereits im Bereich der Dokumentendigitalisierung beobachten: Bessere Bilderkennungs- und OCR-Lösungen digitalisieren den Inhalt von Rechnungen bereits seit einiger Zeit vollautomatisch und erkennen Rechnungsnummern, Daten sowie Summen und schreiben diese automatisiert in neue Datenbanken.

Zusätzlich steigt die Adaption von künstlicher Intelligenz bereits in „kleineren“ Unternehmen und Personen mit den Fähigkeiten eines AI Specialist sind gefragt²⁵. Ob es sich hierbei nur um eine Alternativbezeichnung zum Data Scientist handelt, wird die nahe Zukunft zeigen. Folgendes Beispiel beweist sehr eindrucksvoll, was mit den verfügbaren AI-Tools und einem gewissen Ingenieursgeist inzwischen möglich ist: Die Arbeit eines Instagram Influencers kann mit dem AWS AI-Portfolio zu 100% automatisiert werden.²⁶ Somit sollten alle Unternehmen ernsthaft überlegen, ob im Rahmen von Digitalisierungsprojekten nicht auch andere eigentlich repetitive Aufgaben zumindest mit Hilfe von AI-Lösungen unterstützt werden könnten, um die Kapazitäten der menschlichen Arbeitnehmer für die Lösung von wirklich neuen Aufgaben einzusetzen.

Blockchain & Distributed Ledger Technology (DLT)

Auch wenn andere provokativ sagen, dass Blockchain ein Buzzword ist, welches nach einem lösbaren Problem sucht²⁷, gibt es Anwendungsfälle, bei denen der Einsatz von eben dieser Technologie ohne Zweifel sinnvoll ist. Als Blythe Masters, ehemalige JP Morgan Veteranin, bereits im Jahr 2015 für ihren neuen Arbeitgeber Digital Asset Management auf der Veranstaltung Money20/20 Europe über den Prozess des Clearings im Wertpapierhandel sprach²⁸, war der Vorteil einer verteilten Datenbanktechnologie klar. Den gleichen Datensatz auf Grund von nachvollziehbaren Vertrauensproblemen zehn oder mehr mal in verschiedenen Systemen individuell zu speichern und als quasi-neu zu betrachten, ist hochgradig ineffizient. In diesen Anwendungsfällen kann der Einsatz von Distributed Ledger Technology (DLT) eine technische Antwort auf eine Fragen sein, die aktuell mit komplexen Prozessen gelöst wird. In diesem, sehr grob skizzierten Szenario würden alle Beteiligten die gleiche Datenbank betreiben – nur eben verteilt. Die Hürden, die in diesem Fall genommen werden müssen, sind regulatorischer Natur und setzen eine Zusammenarbeit über Unternehmens- und Staatengrenzen hinweg voraus. Auf der anderen Seite sind das wohl die Gründe, warum eine flächendeckende Adaption von entsprechenden Datenbanksystemen noch nicht stattgefunden hat.

Die in der Öffentlichkeit oft diskutierten Rechenleistungs- und Energieineffizienzen von öffentlichen Blockchains wie Bitcoin²⁹ spielen in diesen Szenarien eher eine untergeordnete Rolle.

Verteilt betriebene Datenbanken bringen also offensichtliche Vorteile. Sobald die letzten Puzzlestücke wie industrieweite Best/Good Practices, von den IT-Größen unterstützte Open-Source-Projekte gefunden werden, sind Legacy-Datenbanken, die in Anwendungsfällen quasi-gleiche Daten speichern sollen wohl auf dem Weg aus den Unternehmen. Die R&D-Anstrengungen der letzten Jahre haben bereits dafür gesorgt, dass die Public-Cloud-Anbieter inzwischen alle Angebote für Blockchain-as-a-Service im Portfolio haben. In der Zukunft sind in angrenzenden Szenarien zumindest protypische Tests mit dieser Technologie kaum zu vermeiden.

Quantum Computing

Über Quantum Computing wird ebenfalls inzwischen viel geschrieben und verständlich erklärt.³⁰ IBM versucht mit seinem quasi-Mainframe³¹ ein Comeback der ganzen eigenen Art. Doch bevor Quantum Computing so weit gezähmt ist, dass aus Narrow Use Case Quanatum Supremacy³² ein fundamentaler Wechsel der IT Plattform wird, wartet unbestritten noch einiges an R&D-Arbeit.

Allerdings werden Unternehmen, die in Feldern aktiv sind, bei denen mit Quantum Computing ein entscheidender Vorteil erwartet wird (bspw. Verschlüsselungen/Cybersecurity und der der Ver-arbeitung von wirklich großen Datensätzen nahe Echtzeit), sich genauer überlegen müssen, ob eine Investition durch die neue Technologie gefährdet sein könnte.

Amazon nutzte seine diesjährige re:Invent Konferenz ebenfalls für die Ankündigung von Quantum-Spielwiesen.³³ Die ganz großen Gehälter für diejenigen, die die Rechner der neuen Zeit tatsächlich konstruieren mussten, sind nun nicht für die Unternehmen der nächsten, kleineren Größenordnung notwendig. Nichtsdestotrotz muss auch für diese Tests mit den AWS-Tools wieder R&D Budget allokiert werden, welches nicht zu Direkterwirtschaftung von Profit genutzt werden kann.

Auf der anderen Seite wird eine Risikoanalyse bei Lösungen mit Massendatenverarbeitung wohl Pflicht sein, um bei notwendigen Investitionen in diesem Bereich abschätzen zu können, dass eine heute als State of the Art betrachtete Lösung nicht überraschend rechts und links mit einer vielfach effizienteren Rechenleistung überholt wird.

—

Alle die zuvor genannten Technologien haben das realistische Potential den Umgang mit vorhandenen und unausweichlich soon-to-be Legacy-Systemen gewaltig auf den Kopf zu stellen. Teure Migrationspfade sind die unausweichliche Konsequenz und bedeuten (mal wieder) gutes Geld für alle Partner, Berater und natürlich Hersteller. Die Hersteller haben dann für ihre Events weiteren Bedarf an Vorträgen, um die nächste Transformationswelle anzupreisen und mit einer Fear of Missing out (FOMO) die Absätze in die neuen Produktkategorien zu steuern. Das IT-Karussell und die Notwendigkeit auf der Höhe der Zeit bleiben zu wollen (oder müssen), beginnt die nächste Fahrt. In einem Meeting hörte ich kürzlich folgenden, leicht ironisch gemeinten Satz: IT beschäftigt sich zu 80% mit sich selbst und in den 20% verdient der Sektor sein Geld. Pareto at it’s finest — und auch meine Beiträge, die mir bei der Strukturierung der Komplexität helfen, fallen wohl eher in die erste Kategorie.

This content is only available in German