BROT UND BUTTER-SOFTWARE
Legacy verdient die Kohle. Das ist eine These, die ich vertrete und die in der Realität auch bewiesen werden kann.
Nicht umsonst suchen Banken teilweise noch händeringend nach COBOL-Entwicklern, um Systeme, die ursprünglich in den 70ern ins Leben gerufen wurden, weiter am Leben zu erhalten weil eine Ablösung teuer und riskant ist. Auch im Produktionsumfeld laufen Steuerungen mit teils jahrzehnte lang nicht aktualisierter Software. Weil sie funktioniert.
Schnittstellen sind oft keine modenen Graph-APIs sondern Dokumentenablagen auf Sambaservern, die Dateien in XML-Syntax oder gar proprietäten Formaten austauschen.
Code, der in der seit langem produktiv läuft, besteht hier oder da aus Klassen mit mehr als 5000 Zeilen. Eigens aufgesetzte Websockets laufen, um Signale von A nach B zu transportieren.
Weil es funktioniert
All das, was ich gerade aufgezählt habe ist oft die ungeschönte Wahrheit. Es tritt einen Softwareentwickler aus seiner heilen, verSCRUMten Microservice-Welt direkt in die harte Realität. Keine Raketenrechnik, oft nur simpelste Brot und Butter Technologie. Weil sie teils von Menschen entwickelt wurden, die Ergebnisorientiert gearbeitet haben und nicht mit einer rosaroten IT-Manager-Brille. Als Teile der Systeme entwickelt wurde gab es keine IT-Manager im heutigen Sinne. Da gab es eine Produktion und den Willen, Daten zu sammeln, um ein Produkt besser zu machen oder die Produktion effizienter zu machen. Um Maschinen rechtzeitig zu warten und damit einen ungeplanten Ausfall zu verhindern. Um den Jungs und Mädels an den Maschinen das Arbeiten angenehmer oder zielgerichteter zu gestalten. Jemand, der sich mit "Rechentechnik"(der Vorgänger von IT im deutschen Sprachgebrauch) so einigermaßen auskannte, hat etwas zurechtgefummelt, was funktioniert hat. Dann wurde das Ergebnis anerkannt und er hat weitergemacht, diese Dinge umzusetzen. Dokumentation war erst mal optional. Spätestens, als er am ersten oder zweiten Projekt etwas anpassen und warten musste, ist vermutlich eine Form der Dokumentation entstanden. Es funktionierte noch vieles auf Zuruf. Kein Change-Tracking, keine Tickets, keine Cybersecurity, die ständig im Produktionsnetz rumfummelt und Dinge noch komplizierter macht, als sie ohnehin schon sind. Mit Standards, die für ein Produktionssystem gar nicht notwendig wären, wenn man die Daten nicht aus dem OT Netz in die "Cloud" ballern wollen würde.
Und doch gab es das alles.
Statt Change-Tracking und Ticketsystemen gab es ein Betriebsbuch. Entwickler haben ihre Änderungen an der Software analog zu einem Changelog dorthinein geschrieben und so wussten die Anwender und später sie selbst über die getätigten Änderungen bescheid. Die Cybersecurity war die Firewall zwischen Produktionsnetz und IT-Netz. Und es gab das rote Kabel. Das Kabel, das das Produktionsnetz mit dem IT-Netz verbunden hat und bei Bedarf getrennt werden konnte damit die Produktion autark weiterläuft. Die Cloud lief im Produktionsnetz und war eine Datenbank. Embedded Security war die Vorsicht des Programmierers, der die Systeme durchdacht geplant und entwickelt hat. Die Edge-Cloud war das Register in der SPS, das für die Datenpufferung verantwortlich war. Die Microsoervice-Architektur war die monolithische Anwendung, die jeder im Unternehmen genutzt hat. Die nach Bedarf der Anwender weiterentwickelt wurden. Ganz ohne Stundenbuchung auf fiktive Projekte, die nur dem Controller etwas nützen.
Aus sicherheitstechnischer Sicht gibt es für solche Implementierungen, wie sie heute nicht selten noch anzutreffen sind, natürlich Lösungen, die einen Mittelweg zwischen Komfort und Sicherheit abbilden.
Aber warum?
Das klingt alles leicht befangen, wenn ich mit anekdotischer Evidenz von unnötigem Entwicklungsaufwand für heutige Projekte spreche. Ich meine damit nicht, dass es eine gute Idee ist, eine neue Anwendung ohne TLS zu implementieren oder neue Schnittstellen nach 70er Jahre-Standard zu entwerfen.
Ich meine, dass es alles, was es heute gibt, irgendwann schon mal gab. Dass die "archaische", oft verteufelte, alte Technologie immer noch präsent und Teil dessen ist, was heute existiert, wird oft vergessen. Und wenn man sie noch findet, dann nur, weil sie funktioniert. Manchmal habe ich das Gefühl, dass man heute Microservices implementiert, um Microservices zu machen. Es muss unbedingt eine Container-Umgebung sein, obwohl ich gar keinen Bedarf an horizontaler Skalierung, konfigurationsbasierter Bereitstellung oder einem System mit geteilten Ressourcen habe. "Aber KI machen doch alle!" Ja, dann holen wir uns doch ein Abo für die Amazing Äscher Cloud und blasen die Daten einfach in einen tollen Data Lake, damit da irgend ne Machinelearninganwendung Zeug reininterpretiert.
Die Frage ist nicht, ob mir das einen Mehrwert bringt. Das tut es vermutlich. Die Frage ist, ob ich das mit statischer Analyse nicht so oder ähnlich auch hinbekommen hätte. Ganz ohne meine sensiblen Messdaten zu teilen oder zwielichtige Rechenzeit-Kostenmodelle zu nutzen, bei dem einem keiner sagen kann, was man denn am Ende des Monats dafür bezahlt. Kleiner Spoiler: üblicherweise mehr als angenommen.
Dann gibt es 20 produktionsrelevante Technologien im Unternehmen und es müssen für jede Technologie mehrere Leute vorhanden sein, die diese Systeme warten, updaten und verwalten können.
Vielleicht... aber nur vielleicht... ist es manchmal doch sinnvoll, einen neuen Anwendungsfall nur so kompliziert zu machen wie nötig und die Kernpunkte der Entwicklung nicht auf die verwendete Technologie sondern auf das Ergebnis zu lenken. Wartbarkeit. Nicht nur im Code-Entwurfsmuster-Sinne. Auch in der Zahl der verwendeten Endpunkte, zu wartenden Server, zu kontrollierenden Systeme. Im Kompromiss mit der Ausfallsicherheit.