Startseite > Distribution > Der Ausweg aus der »Dependency Hell«

Software-Obsoleszenz

Der Ausweg aus der »Dependency Hell«

5. November 2023, 11:00 Uhr | Heinz Arnold

Martin Steinleitner, Partner bei Syliom: »In den USA geschieht in Richtung Software-Obsoleszenzmanagement schon sehr viel, bei uns scheint die Awareness allerdings noch wenig ausgeprägt zu sein.«

Wer an Obsoleszenzmanagement denkt, der denkt zumeist an die Verfügbarkeit von Hardwarekomponenten. Doch Software muss genauso behandelt werden – in Zeiten von Industrie 4.0 ist das wichtiger denn je.

▶ Diesen Artikel anhören

Die Bill of Materials (BOM) kennt jeder – und dass sich mit einem fundierten Obsolescence-Management nicht nur Änderungen und Abkündigungen managen, sondern auch die Risiken quer durch die Supply-Chain reduzieren lassen, hat sich über die vergangenen Jahre ebenfalls herumgesprochen. Dabei bezieht sich der Begriff Obsoleszenzmanagement meist auf die Hardware, also auf greifbare Bauelemente wie Chips, Elektromechanik, Leiterplatten, kurz: auf alle Hardware-Komponenten, die zum Aufbau des jeweiligen Systems erforderlich sind. Doch damit ein System – etwa eine Produktionsmaschine – funktioniert, sind nicht nur die verschiedenen Hardware-Module und die Komponenten erforderlich, aus denen die Maschine besteht. Erst die Software haucht den Maschinen »Leben« ein, erst wenn alle Softwarekomponenten zusammenspielen, kann die Maschine arbeiten. In Zeiten von Industrie 4.0 kommt komplexer Software eine eminent wichtige Bedeutung zu, die zudem sehr schnell wächst.

Doch was Entwicklungs- und Einkaufsabteilungen vieler Unternehmen nicht auf dem Schirm haben: Auch Software – oder ein Teil davon – wird obsolet. Ähnlich wie für Hardwarekomponenten ist also auch für Softwarekomponenten Obslescence-Management erforderlich. »Deshalb sprechen wir analog zur BOM im Hardwarebereich von der Software-BOM, kurz SBOM«, sagt Martin Steinleitner, Partner bei Syliom. In der SBOM werden alle Teile gelistet, aus denen sich die Software final zusammensetzt. Das gesamte Softwaresystem, beispielsweise für die Steuerung einer Produktionsmaschine, besteht normalerweise aus Modulen, die ihrerseits wiederum aus Software-Komponenten besteht. Die SBOM ist ein formaler Datensatz mit den Details zu den Komponenten. Ganz wichtig ist, dass hierzu auch die jeweiligen Lieferbeziehungen gehören. Wesentlich ist das »Nested Inventory« der SBOM, ein abhängiges Inhaltsverzeichnis, das alle Informationen enthält, die erforderlich sind, um die gesamte Software bauen und betreiben zu können. Die Informationen, wie die Module zusammengebaut werden, stecken im SW-Konfigurationsmanagement.

Was aber ein Unterschied zur Hardware-BOM ist: Es gibt drei Sorten von Softwaremodulen, je nach ihrer Herkunft.

Die vom Unternehmen selbst entwickelten Software-Anteile oder Module.
Die von Fremdfirmen zugekauften Module.
Die von Drittfirmen oder der eigenen Software-Entwicklung eingesezten Open-Source-Module.

»Wichtig ist hier, dass die Unternehmen nur über die im eigenen Haus entwickelte Software die volle Kontrolle haben«, erklärt Steinleitner. Doch bei eingekaufter Software sieht das schon anders aus. Hier trägt die Firma, die die Software entwickelt und verkauft, die direkte Verantwortung. Das Unternehmen, das die Software einkauft, schließt mit dem Verkäufer einen Anwendungs- und Wartungsvertrag, über den geregelt ist, was die Software machen soll oder darf. Steinleitner: »Damit ist der Zugriff auf Änderungen und Wartungen nur noch indirekt. Das muss auch das Unternehmen wissen, das die Maschine einschließlich der Software vom Hersteller eingekauft hat.« Wenn beispielswese ein Fehler in der Produktionsmaschine auftritt und das Unternehmen, das die Maschine betreibt, eine Korrektur wünscht, dann, so Steinleitner, »kommt es auf den Service-Vertrag an, den der Maschinenhersteller mit dem Softwarehersteller geschlossen hat. Darüber ist beispielsweise festgelegt, wie schnell er reagiert kann – in Tagen oder Wochen.«

Kompliziert wird es, wenn neue Features in die Software eingebaut werden sollen, etwa um die Performance oder Funktionen der Maschine zu verbessern. Dann muss der Hersteller der eingekauften Software erst überzeugt davon sein, dass die Neuentwicklung in sein Geschäftsmodell passt und sich für ihn kommerziell lohnt.

Noch komplizierter wird es mit Open-Source-Komponenten. Grundsätzlich gilt: Open-Source-Software hat viele Vorteile, deshalb beteiligen sich die meisten Unternehmen an Open-Software-Projekten bis hinauf zu den größten wie Microsoft, die aus guten Gründen viel Geld in die Projekte stecken. Denn das Rad muss ja nicht von jedem wieder neu erfunden werden, und auch die Kosten für die Wartung fallen weg. »Vor allem hat Open Source viel Sicherheit gebracht und läuft hervorragend, wie etwa Linux zeigt«, sagt Martin Steinleitner. »Meine Argumentation richtet sich keinesfalls gegen Open-Source-Software; es ist nur sehr wichtig, sich vollkommen klar über die jeweiligen Abhängigkeiten und deren Konsequenzen zu sein. Es kommt darauf an, richtig damit umzugehen.«

Allerdings gibt es bei Open-Source-Software noch nicht einmal die Möglichkeit des indirekten Zugriffs. Wer beispielsweise etwas korrigieren, ändern oder ergänzen will, der muss entweder einen tiefen Einblick in die jeweiligen Teile der Software haben, die korrigiert werden sollen, oder er muss wissen, bei wem dies beantragt werden kann. In den meisten Fällen wird die betroffene Community zustimmen wollen, wenn etwas geändert werden soll. Das werden dann in der Praxis vor allem wieder die Autoren sein, die die Software geschrieben haben Deren Zahl ist überschaubar. Auch hier stellt sich wieder die Frage: Bei wem kann die Änderung beantragt werden? Von wem die Software kommt, ist nicht immer sofort eindeutig: Wer sie von Github hat (mehr als 100 Millionen Entwickler!), weiß nicht, wer genau dahintersteckt.

Dazu ein konkretes Beispiel: Eine Security-Lücke wurde in der Software einer Maschine entdeckt. Alle Unternehmen, die die Maschine mit der entsprechenden Software des Maschinenbauers gekauft haben, benötigen also einen Austausch. Dazu müssen zwei Fragen beantwortet werden: Ist die Software mit der Sicherheitslücke Bestandteil unserer Maschinen? Wenn ja, wo befindet sie sich? »Nur wer die SBOM sorgfältig erstellt hat, kann diese Fragen beantworten«, sagt Steinleitner. »Ist sie nicht vorhanden, herrscht erst einmal ein großes Durcheinander.«

Ähnlich verhält es sich, wenn sich die Software ändert. Bekannt ist das beispielsweise von den Windows-Sprüngen, etwa von XP auf Windows 7. Dann müssen Treiber neu geschrieben werden, es tauchen Sicherheitsprobleme auf, die beachtet werden müssen, Datenformate können sich ändern und müssen angepasst werden, Anpassungen im Source-Code müssen vorgenommen werden und bestehende Test müssen durch neue Tests erweitert werden. »Das ist genauso wie bei Hardwarekomponenten in einer Produktionsmaschine, die nicht mehr die Spezifikationen erfüllen. Dann müssen bestimmte Module in der Maschine entsprechend geändert werden, das ist in der Software genauso«, sagt Steinleitner.

Handelt es sich um eine im eigenen Haus entwickelte Komponente, dann geht die Aufforderung zur Korrektur an die Inhouse-Abteilung. Handelt es sich um ein eingekauftes Modul, dann geht der Auftrag zur Änderung an den Hersteller, und es hängt vom Service-Vertrag ab, wie und wie schnell es weitergeht.