Über die zufällige Komplexität von Supply-Chain-Systemen

Joannes Vermorel

Moderne Computertechnik ist äußerst leistungsfähig. Ein bescheidenes Smartphone liefert Milliarden von FLOPS (Fließkommazahlenoperationen pro Sekunde) und speichert Hunderte von Gigabyte an Daten. Ein einzelnes Smartphone könnte theoretisch eine vorhersagende Bestandsallokation für ein sehr großes Einzelhandelsnetzwerk durchführen. Die historischen Daten würden eine geeignete Darstellung erfordern¹, und auf der Seite der Datenverarbeitung müssten schlankere Techniken wie differenzierbares Programmieren verwendet werden. Daher sollten leistungsstarke Supply-Chain-Systeme eine Selbstverständlichkeit sein. Sicherlich können sich Unternehmen etwas Besseres als ein Smartphone leisten, um ihre Lieferketten zu betreiben und zu optimieren. Dennoch zeigt eine oberflächliche Beobachtung der Supply-Chain-Systeme unserer Kunden bei Lokad genau das Gegenteil: Diese Systeme sind fast immer langsam und häufig sogar quälend langsam.

Die heutigen Marktführer für Supply-Chain-Software (ERP, WMS, MRP usw.) haben Schwierigkeiten, auch nur eine Anfrage pro Sekunde auf ihrer API-Backend aufrechtzuerhalten. Bei Lokad werden wir täglich schmerzlich an solche schrecklichen Leistungen erinnert, da wir an vorderster Front des Datenabrufs stehen. Bei etwa einem Dutzend Kunden dauerte der anfängliche Datenabruf fast einen Monat². Die Trägheit der verschiedenen APIs macht 99,9% des Problems aus. Systeme, die 1 MB/Sekunde für ihre Datenextraktion aufrechterhalten können, sind selten. Systeme, die uns nicht dazu zwingen, die gleichen Daten immer wieder unnötig neu zu extrahieren, um die aktuellsten Teile zu erreichen, sind noch seltener. Diese Systeme haben in der Regel über 100-mal mehr Rechenressourcen zur Verfügung als vor 2 Jahrzehnten, und dennoch sind sie nicht grundlegend schneller³ und machen die Dinge auch nicht radikal besser. Einige der fortschrittlichsten Anbieter, die In-Memory Computing nutzen, benötigen mehrere Terabyte RAM, um mit Einzelhandelsnetzwerken umzugehen, was eine erschreckend große⁴ Menge an RAM ist, wenn man bedenkt, was mit diesen Ressourcen gemacht wird.

Diese “zufällige Komplexität” vieler (meistens?) Supply-Chain-Systeme lässt sich auf zwei Hauptursachen zurückführen: Erstens falsche Erwartungen hinsichtlich des Fortschritts der Computertechnik selbst und zweitens mangelnde Sorgfalt bei der internen Gestaltung der Lösung.

In Bezug auf den Fortschritt der Computertechnik gab es bis vor einem Jahrzehnt kein einziges (großes) Unternehmen, in dem das erste Moore’sche Gesetz nicht dutzendfach vorgestellt wurde (normalerweise falsch). Es gab das Gefühl, dass Computer ständig absurd schneller wurden. Leider hörte dies seit den frühen 2000er Jahren größtenteils auf, trivialerweise wahr zu sein. Diese falsche Vorstellung von unbegrenztem Fortschritt führte viele Softwareunternehmen, weit über die Welt der Supply Chain hinaus, zu massiven Fehlern. Viele der Probleme, die mit Windows Vista (veröffentlicht 2006) verbunden sind, lassen sich auf die ursprünglichen Erwartungen - damals im Jahr 2001, als Windows XP veröffentlicht wurde - der Microsoft-Ingenieure zurückführen, dass CPUs bis 2006 mit 6 GHz getaktet sein würden. Wir nähern uns dem Ende des Jahres 2020, und High-End-Gaming-CPUs kratzen kaum an 5 GHz. Die Computertechnik hat nie aufgehört, Fortschritte zu machen, aber sie hat auf eine triviale Weise aufgehört, zumindest was die Softwareunternehmen betrifft.

In den 1980er und 1990er Jahren war es selbstverständlich, dass die Geschwindigkeit einer Software, sobald sie funktionsfähig war, im nächsten Jahr ordentlich und im übernächsten Jahr ausgezeichnet sein würde, auch wenn sie zum Zeitpunkt der Veröffentlichung etwas langsam war. Aggressive Softwareunternehmen wie Microsoft spielten diese Karte sehr gut aus: Ihre Ingenieure erhielten (und erhalten immer noch) die beste verfügbare Computertechnik, und sie trieben die Leistung der Software systematisch an die Grenze des Akzeptablen, in dem Wissen, dass die Hardware das Leistungsproblem im Wesentlichen innerhalb eines Jahres oder zwei lösen würde. Nach dem Debakel mit Vista erkannten die Entwicklungsteams bei Microsoft das Ausmaß des Problems und änderten ihre Vorgehensweise - Windows 7 war eine wesentliche Verbesserung. Dennoch dauerte es ein Jahrzehnt, bis Windows auf dem Leistungssektor wirklich wieder auf die Beine kam. Heutzutage ist der Ausblick nahezu das genaue Gegenteil: Die besten Microsoft-Teams setzen nicht mehr auf zukünftige Hardware, sondern konzentrieren sich fast ausschließlich darauf, sofort überlegene Leistung durch überlegene Software zu liefern⁵.

Die Welt der Unternehmenssoftware hat jedoch viel länger gebraucht, um das Problem zu bemerken, und hat in den 2010er Jahren weiterhin Software entwickelt, als ob die zukünftige Computertechnik kurz davor wäre, alle ihre Probleme zu lösen, wie es in der Vergangenheit oft der Fall war. Leider für die meisten Anbieter von Unternehmenssoftware hat sich die Computertechnik vor einem Jahrzehnt in einer trivialen Weise weiterentwickelt⁶, in der der Anbieter nur darauf warten kann, dass die Leistung eintritt. Software neigt dazu, im Laufe der Zeit Ballast anzusammeln (mehr Funktionen, mehr Optionen, mehr Bildschirme usw.). Die natürliche Tendenz komplexer Software ist daher, sich im Laufe der Zeit zu verlangsamen, nicht zu verbessern - es sei denn, es gibt einen intensiven, engagierten Einsatz auf diesem Gebiet.

Leider ist die Leistung aus Verkaufssicht größtenteils kein Problem. Demos werden mit Spielzeugkonten durchgeführt, die nur einen verschwindend geringen Teil der Datenlast enthalten, mit der das System in der Produktion konfrontiert würde. Außerdem erhalten Bildschirme, die für das Top-Management von Interesse sind, im Vergleich zu denen, die für Mitarbeiter gedacht sind, eine unverhältnismäßig hohe Aufmerksamkeit. Dabei sind es gerade die Bildschirme, die täglich tausendfach verwendet werden und daher die meiste Aufmerksamkeit verdienen. Ich vermute, dass APIs häufig eine schlechte Leistung bieten, weil nur wenige Käufer untersuchen, ob die APIs tatsächlich eine Leistung liefern, die ihrem beabsichtigten Zweck entspricht. Softwareanbieter wissen das und richten ihre Entwicklungsinvestitionen entsprechend aus.

Das bringt mich zum zweiten Aspekt des Leistungsproblems: dem Mangel an Sorgfalt für das interne Design der Lösung. Derzeit erfordert es strategische Software-Designentscheidungen, um die meisten laufenden Hardwareverbesserungen zu nutzen. Eine Designentscheidung ist jedoch ein zweischneidiges Schwert: Sie ermöglicht, aber sie begrenzt auch. Es erfordert eine starke Führung, sich sowohl auf der Geschäftsseite als auch auf der technischen Seite zu einer Designentscheidung zu verpflichten. Unentschlossenheit ist einfacher, aber auf der negativen Seite, wie es die große Mehrheit der Unternehmenssoftware zeigt, leidet die Leistung (und die Benutzererfahrung im Allgemeinen) erheblich.

Ein Fallstrick moderner Software (nicht nur im Unternehmensbereich) ist der Überfluss an Schichten. Daten werden durch Dutzende von inneren Schichten in der Software kopiert, geleitet, gepoolt, synchronisiert, … Dadurch werden die meisten Rechenressourcen für die “interne Verrohrung” verschwendet, die an sich keinen Mehrwert bietet. In Bezug auf das Design ist die Lösung sowohl einfach zu konzipieren als auch schwierig umzusetzen: Man muss sparsam mit Komponenten von Drittanbietern umgehen, insbesondere solchen, die eine Art Schicht beinhalten⁷. Aus Sicht des Softwareanbieters ist das Hinzufügen einer weiteren Schicht der schnellste Weg, um dem Produkt mehr “coole Funktionen” hinzuzufügen, ganz gleich, wie aufgebläht es dadurch wird.

Bei Lokad haben wir uns für einen umfassend integrierten Stack entschieden, indem wir unsere gesamte Plattform um einen Compiler-Kern herum entworfen haben. Nachteilig ist, dass wir die Möglichkeit verlieren, beliebige Open-Source-Projekte einfach in unser Design einzubinden. Integrationen sind zwar möglich, erfordern jedoch in der Regel tiefgreifende Änderungen am Compiler selbst. Auf der positiven Seite erreichen wir eine “bare metal”-Leistung, die im Bereich der Unternehmenssoftware normalerweise als undenkbar gilt. Insgesamt hat sich dieser Ansatz in den letzten zehn Jahren als besonders effektiv erwiesen⁸.

Gemeinsam genutzte Mandantenfähigkeit ist eine weitere Designentscheidung, die die Leistung radikal beeinflusst, zumindest aus der Perspektive des “Preis-Leistungs-Verhältnisses”. Die meisten Unternehmenssoftware - einschließlich Supply Chain-Software - hat stark intermittierende Anforderungen an Rechenressourcen. Zum Beispiel haben wir am äußersten Ende des Spektrums das Forecasting numerical recipe, das nur einmal pro Tag (oder so) ausgeführt wird, aber die gesamten historischen Daten bei jeder Ausführung verarbeiten muss. Die Zuweisung eines statischen Satzes von Rechenressourcen⁹ an einen Kunden ist äußerst ineffizient.

Auch bei Lokad haben wir uns für eine vollständig gemeinsam genutzte Infrastruktur entschieden. Dieser Ansatz reduziert unsere Cloud-Betriebskosten und liefert gleichzeitig eine Leistung, die wirtschaftlich sonst nicht realisierbar wäre (die Cloud-Kosten würden die Vorteile der Supply Chain überwiegen). Um eine reibungslose Gesamtsteuerung aller Arbeitslasten zu gewährleisten, haben wir eine hohe “Vorhersagbarkeit” für unseren eigenen Verbrauch von Rechenressourcen entwickelt. Lokads DSL (domänenspezifische Programmiersprache) namens Envision wurde entwickelt, um dieses Vorhaben zu unterstützen. Deshalb gibt es in Envision ganze Klassen von Programmierkonstrukten - wie beliebige Schleifen - nicht: Diese Konstrukte sind nicht mit den Anforderungen an die “hohe Vorhersagbarkeit” vereinbar, die mit der Verarbeitung von Supply Chain-Daten einhergehen.

Zusammenfassend lässt sich sagen, dass man nicht erwarten sollte, dass ein übergewichtiges Supply Chain-System bald fit wird, wenn es nicht bereits fit ist. Während die Hardware immer noch Fortschritte macht, ist sie bereits mehr als ausreichend schnell. Wenn das System träge ist, liegt es höchstwahrscheinlich daran, dass es seine zugrunde liegende Hardware behindert - nicht daran, dass die Hardware unzureichend ist. Das Problem zu beheben ist möglich, aber es ist größtenteils eine Frage des Designs. Leider ist das Kern-Software-Design eine der Dinge, die in der Unternehmenssoftware nach der Designphase des Produkts tendenziell kaum zu beheben sind. Es ist jedoch möglich, sich zu erholen, wie Microsoft gezeigt hat, aber nicht jedes Unternehmen (sowohl Anbieter als auch Kunde) kann sich das Jahrzehnt leisten, das dafür benötigt wird.