DIE EVOLUTION DER TECHNOLOGIE

Digitale Transformation

,

Artificial Intelligence

,

AI

DIE EVOLUTION DER TECHNOLOGIE

Martin Horvath | Apr 14, 2020

Bereits in den 1960er Jahren beschäftigen sich Wissenschaftler mit Techniken die zum dem führten, was wir heute als "Das Internet" kennen. Richtig Wind in die Segel kam im Januar 1997, mit der erstmaligen Veröffentlichung des HTTP/1.1 Standards. Es folgen HTML, Javascript und wer modern sein wollte, setzte vor der 2000er Marke auf dynamische Inhalte mit Flash.

Mit Ajax wird das Ende von Flash wenige Jahre später eingeläutet und die Zeit der Javascript Frameworks beginnt. Ja, wir blicken zurück auf eine rasante Entwicklung und dies ist im Kontext des Internets deutlich zu erkennen - wenngleich dies für alle anderen Bereiche der Informationstechnologie ebenso gültig ist.

Quelle: http://www.evolutionoftheweb.com/?hl=de

Heute befinden wir uns in einem technologischen Raum mit enormer Komplexität und Dynamik. Mit der Innovation Schritt halten zu können wird zunehmend herausfordernder und umso wichtiger ist es, im Rahmen der Digitalisierung "auf das richtige Pferd zu setzen". Denn eins ist klar, das Rennen ist bereits voll im Gange und es ist höchste Zeit, in neue Technologien einzutauchen um dem Wettbewerb am Markt standhalten zu können. Nun wollen wir uns einige ausgewählte Innovationen näher ansehen und beurteilen.

Künstliche Intelligenz

Beginnen wir mit dem Hype-Thema der künstlichen Intelligenz - kurz KI. Für viele ist es die technologische Innovation schlechthin von der man unglaubliche Ergebnisse erwarten kann. Doch in Wirklichkeit stecken dahinter Statistik und Mathematik, die in eine Werkzeugbox (z.B. Tensorflow) verpackt wurden.

KI wird die demnach Umsatzzahlen eines Unternehmens nicht verdoppeln und KI wird Unternehmensausgaben nicht senken. Aber KI kann Vorhersagen treffen, um eine Optimierung im Unternehmen zu unterstützen. In jedem Fall muss daher analysiert werden, welche Kennzahlen zum Unternehmenserfolg maßgeblich beitragen. Sehen wir uns das an einem vereinfachten Beispiel an.

Bauer Markus verdient seinen Lebensunterhalt mit dem Anbau und dem Verkauf von Kartoffeln. Wenn Markus mehr verdienen möchte, muss er also nur mehr anbauen. Ein linearer Zusammenhang, für den es keine KI benötigt.

In der Realität muss Markus aber die schwankende Nachfrage, den Marktpreis für Kartoffeln, benötigtes Personal, Wetter usw. berücksichtigen. Da kann es also vorkommen, dass 50% mehr Anbau gerade mal zu 25% mehr Verdienst führt. Da die Einflussfaktoren bekannt sind, eignet sich hier KI hervorragend, um die optimale Anbaumenge für Markus im Voraus zu berechnen und das Maximum aus den vorhandenen Ressourcen herauszuholen.

Der Einsatz von künstlicher Intelligenz - unabhängig von der darunterliegenden Implementierung - sollte also überlegt und zielgerichtet sein. Design-Thinking Workshops eignen sich hervorragend, um ohne große Kosten und Risiko zu evaluieren, ob und wie ein KI Modul eingesetzt werden kann.

Microservices

Widmen wir uns nun einem weiteren Trend-Thema aus dem aktuellen Beratungsgeschäft: den Microservices. Wenngleich es immer noch eine Daseinsberechtigung für monolithische Server gibt, so sind die Mehrheit der Unternehmen mit einer Microservice-Architektur deutlich besser beraten. Diese sind besser zu testen, zu skalieren, abzusichern und zu warten. Für die tatsächliche Implementierung einer solchen Architektur gibt es eine Vielzahl von Mischformen (z.B. zentrale Datenbank pro Service oder separate Datenbank für jeden Service). Die Aufgabe eines jeden Services ist die Abarbeitung einer Anfrage und die Rückgabe eines Ergebnisses. Ein de facto Industriestandard ist das REST-Paradigma mit JSON als Datenaustauschformat. Für eine Vielzahl von Diensten ist das eine optimale Kombination, die aber auch ihre Probleme und Risiken mit sich bringt: Performance und Funktionalität. Sehen wir uns auch das an einem Beispiel an.

Unternehmen X produziert Platinen in Massenfertigung und möchte eine automatisierte, bildbasierte Qualitätssicherung in der Produktion umsetzen. Die Vorarbeiten zu diesem Vorhaben führten zu einem KI Modul, das anhand eines Fotos und einer Vielzahl von Produktionsparametern der Platine deren Qualität beurteilt. Nun soll ein Microservice implementiert werden, um die Produktion anzubinden. Der Einsatz von REST und JSON ist naheliegend, doch Performance-Engpässe, hohe Netzwerklast und fehlende bidirektionale Kommunikation könnten mittel- und langfristig zu einem Problem werden.

Eine noch nicht allzu bekannte Technologie Namens "gRPC" bietet sich als Lösung an. Kurz gesagt erlaubt gRPC eine bi-direktionale Kommunikation über das HTTP/2 Protokoll und arbeitet deutlich effizienter, da ausgetauschte Daten binär übertragen werden. Als "Bonus" kann hinzugefügt werden, dass das Abfangen der Daten ohne Kenntnis über das Schema zu unverhältnismäßig hohen Aufwänden für die "Interpretation" führt. Kurzum, die Technologie ist sicherer. gRPC ist derzeit (noch) eine Nischentechnologie, die richtig angewandt aber einen entscheidenden Vorteil gegenüber REST/JSON, SOAP/XML mit sich bringt.

Datenspeicher

Um das Gesamtbild dieses Blogs abzurunden fehlt noch der Datenspeicher. Eine KI säße ohne umfängliche Daten auf dem Trockenen und nur die wenigsten Dienste einer Microservice Architektur sind ohne Datenspeicher denkbar. Die "üblichen Verdächtigen" in diesem Umfeld sind MySQL, Oracle, MS SQL Server, PostgreSQL oder andere Vertreter der relationalen Datenbanksysteme (RDBMS). Seit einigen Jahren werden in vielen Bereichen auch sogenannte No-SQL Datenbanken eingesetzt - vorwiegend aber in "digitalen Unternehmen" und nicht, um traditionelle Unternehmen zu digitalisieren. Bleiben wir aber  bei den RDBMS, da diese die Platzhirschen im Beratungsgeschäft sind: Diese eigenen sich hervorragend wenn tabellarische Daten vorliegen, die man sich am besten als Excel-Listen vorstellt. Kundenregister, Zahlungsein- und ausgänge, Materiallisten und Preisinformationen sind Beispiele hierzu. Ebenso können Verknüpfungen zwischen Listen sehr gut abgebildet werden, etwa die Zahlungseingänge eines spezifischen Kunden aus der Kundenliste.

Was aber, wenn weit komplexere Anforderungen erfüllt werden müssen? Hier kommen oft die SQL-Ninjas zum Einsatz, die hochkomplexe Datenkonstrukte und Abfragen kreieren - die dann schlussendlich entweder nicht wartbar sind oder eine unzumutbare Performance liefern. Auch hierfür nehmen wir ein Beispiel zur Hand.

Das Dispositionstool Z eines Spediteurs soll dem Disponenten die Möglichkeit geben, Waren schnellstmöglich von A nach E zu transportieren. In vielen Fällen gibt es keine (sinnvolle) Direkt-Verbindung zwischen A und E und oft setzt sich das "Netzwerk" eines Spediteurs aus vielen Sub-Netzen von Partnern zusammen.

Quelle: https://www.101computing.net/dijkstras-shortest-path-algorithm/dijkstra-algorithm-graph/

Die Verbindung von A nach E wird also in der Realität eher A - B - E oder A - C - E oder A - C - D - E sein. Alle Buchstaben stellen dabei in der Realität Umschlagplätze, Zwischenlager o.ä. dar. An all diesen Plätzen sind verschiedene Gegebenheiten zu beachten: An manchen wird nur 2 Tage die Woche gearbeitet, andere wiederum sind nur Nachts besetzt und wieder andere sind beschränkt auf Fahrzeuge unter 3.5T.

Die Modellierung einer Gesamtlösung mittels RDBMS... eine Katastrophe. Strukturelle Informationen wie der Index an Partnern oder Standorten sind dort gut aufgehoben, ebenso die Restriktionen. Aber für die Ermittlung der besten (=günstigsten, schnellsten, sichersten etc.) Verbindung von A nach E wäre eine sogenannte Graphen-Datenbank deutlich besser geeignet.

Anders als die "herkömmlichen" Datenbanksysteme sind diese konzipiert um sogenannte Graphen abzubilden und auf diesem zu operieren. Die Abfragesprache Cypher kann dabei genutzt werden, um entsprechende Fragen zu stellen, etwa: "Wie kommt meine Ware am schnellsten von A nach B". Die Graphendatenbank navigiert dann vom Ausgangspunkt ausgehend durch den Graphen und errechnet die beste Verbindung und unterstützt eine Vielzahl von Optionen dabei. Zum Beispiel maximal über 3 Zwischenpunkte zu traversieren oder Zwischenpunkte vom Typ "X" zu vermeiden. Und wenn es beides sein soll, also ein RDBMS und eine GraphenDB, dann ist ein Blick in Richtung SAP HANA nicht verkehrt. Diese unterstützt "normale" SQL Abfragen und Tabellen, erlaubt aber auch die Modellierung eines Graphen sowie die Nutzung der Graphenabfragesprache.

Die Kernaussage dieses Blogs sollte sein, dass es eine Vielzahl von neuen Technologien gibt, die enormes Potential mit sich bringen, jedoch im Prozess der "normalen" Digitalisierung nicht beachtet werden. Sei es, weil dies den Entscheidungsträgern noch nicht bewusst ist, bestehende Software vermeintlich nicht damit kompatibel ist oder schlicht und einfach die Einstiegshürde zu hoch ist.

Hier kann Techedge, für die ich seit 2018 tätig bin, unterstützen: In dafür ausgelegten Design Thinking Workshops gehen wir mit ausgewählten Mitarbeitern des Kunden in einen Prozess, der die Lösung eines Geschäftsproblems/-prozesses zum Ziel hat und dabei keine noch so utopischen Ansätze ausschließt. Nach Bewertung der Ansätze im Hinblick auf Umsetzbarkeit, Budget, Nutzen etc. baut ein "SWAT-Team" bei Techedge ohne extensive Ressourcennutzung einen funktionsfähigen Prototypen, der nach der Kundenevaluation dann entweder zu einer nachhaltigen Lösung führt - oder aber dem Kunden die Gewissheit gibt, dass Lösung X nicht anwendbar ist.

...umso wichtiger ist es, im Rahmen der Digitalisierung "auf das richtige Pferd zu setzen".

Es führen zwei Wege zum Gewinn. Die Identifikation des schnellsten Pferdes oder die Identifikation aller langsamen Pferde. So verhält sich das auch mit der Technologie-Auswahl.

 

Möchten Sie mehr erfahren?

Senden Sie uns eine Nachricht: Wir freuen uns auf ein Gespräch!

KONTAKTIEREN SIE UNS

Abonnieren!