Die Zukunft von Software im deutschen Maschinenbau

„Die Software tut es noch bis zu meiner Rente“. Fühlen Sie sich ein bisschen ertappt, als Geschäftsführer, Leiter (Software-) Entwicklung oder Senior Programmierer? Weil Sie diesen Satz auch schon gesagt oder zumindest gedacht haben? Weil Teile Ihrer Software und damit ein Gutteil des Kern-Know-Hows Ihres Unternehmens ihre Wurzeln in den 1990er Jahren haben?

Aber vor allem: was ist dann – in fünf, vielleicht zehn Jahren? Wie geht es dann mit der Software weiter? Ganz konkret zwei Fragen:

1. Wenn es so weit ist – wenn Sie „in Rente sind“ – wer wird dann die Software weiterentwickeln?
2. Und haben Sie das auch Ihrem Vertrieb gesagt?

Haben Sie das auch Ihrem Vertrieb gesagt?

Beginnen wir doch mit der zweiten Frage und versetzen uns gedanklich in einen Verkäufer hinein, der eine Maschine verkaufen soll, auf der eine Software läuft, deren Kern mehr als 30 Jahre alt ist und der man das höchstwahrscheinlich auch ansieht? Nun, er wird vermutlich vor allem von Qualität und Zuverlässigkeit der Maschine sprechen. Das Wort „Innovation“ lässt er besser außen vor. Das würde ihm ein Kunde nur schwer, im wahrsten Sinne des Wortes, „abkaufen“. Aber wie lange kann man noch mit den Tugenden des deutschen Maschinenbaus der 1980er Jahre noch die Maschinen von morgen verkaufen? In den Fünfjahresplänen der chinesischen Regierung finden sich die Wirtschaftszweige aufgeführt, in den die Nation führend werden will. Maschinenbau ist einer dieser Zweige. Mit Maschinen, auf denen 30 Jahre alte Software läuft könnte das schwierig werden.

Wer hat dann noch dieses Know-How?

Aber nehmen wir einmal an, die Software „schafft“ es tatsächlich noch weitere Jahre am Markt zu bestehen, dann stellt sich Frage 1): wer wird die Software dann weiterentwickeln? Über Fachkräftemangel ist Vieles geschrieben worden. Aber neben dem Rückgang der Zahl der Spezialisten gibt es noch einen ganz anderen Rückgang: den des Know-Hows. Nehmen wir an, Sie finden ausreichend Spezialisten, vielleicht weil Sie ein angesehenes Unternehmen sind. Können diese Spezialisten auch eine Software (weiter-)entwickeln, der dreißig Jahre alte Technologien zu Grunde liegen? Software, die zu einer Zeit entstanden ist, als graphische Bedienoberflächen gerade am Entstehen waren und die Kommandozeile das erste Werkzeug eines Entwicklers war, soll jetzt von Spezialisten weiterentwickelt werden, die mit Touch-Devices groß geworden sind?

Man muss nicht immer alles neu machen?

Nicht „bis zur Rente zu warten“ bedeutet trotzdem nicht, eine Software von Grund auf neu zu entwickeln, damit aktuelle Technologien zum Tragen kommen. Es hat ja schließlich gute Gründe, warum die Wurzeln einer Software so weit zurückreichen. Und die Antwort ist großartig: Know-How. Es stecken über dreißig Jahre kontinuierliche Weiterentwicklung in der Software. Eine komplette Neuentwicklung wäre dementsprechend ein riesiges Projekt von mehreren Mann-(und Frau-)Jahren. Und es würden sich die gleichen Fragen stellen: wer hat das Know-How das zu machen? Und wo sind die Spezialisten dafür? Genau diese Herausforderungen sind ja auch der Grund, warum die Software so „gealtert“ ist.

Die Lösung muss also sein: wie lässt sich eine Software überarbeiten, so dass das in ihr einprogrammierte Know-How erhalten bleibt, sie aber trotzdem moderne Technologien einsetzt (zu allerforderst: moderne Bedienoberflächen)?

Tschüss Monolith

Gewachsene Software hat fast immer ein Merkmal: sie ist sehr monolithisch. Eine klare Abgrenzung einzelner Module gibt es selten. Aber wenn alles mit allem verbunden ist, lässt sich kaum mehr Veränderung implementieren. Der erste Schritt muss also sein: Auftrennung der Software in Module. Dann kann für jedes Modul entschieden werden: Neumachen oder Behalten. Alles, wie wirklich Know-How drinsteckt wird man eher behalten – häufig sind das ausgefeilte Berechnungsalgorithmen, Mathematikbibliotheken, Generatoren z.B. für NC-Programme o.ä. Immer bietet es sich an, ein eigenes Modul „Benutzeroberfläche“ zu schaffen. Das ist der Bereich, den der Kunde/Bediener von der Software sieht und verwendet. Das ist der Teil einer Software, die im wahrsten Sinne des Wortes entscheidet, ob sie „alt aussieht“.