Warum Software (fast) nie fertig ist

Bei den meisten Projekten, die ich in den vergangen Jahren begleiten durfte, ist mir eine Denkweise meiner Kunden immer wieder aufgefallen: Der Softwareentwicklungsprozess wird häufig als Projekt betrachtet, das per Definition irgendwann abgeschlossen ist. Die übergreifende Einführung von "Agilen Methoden" (oder Mischformen davon) hat die Lage zwar etwas verbessert, aber auch Agile Projekte enden nach "ein paar Sprints", wenn das Budget aufgbraucht und die unbedingt benötigten Features umgesetzt wurden. Dabei sollte die funktionale "Fertigstellung" der Software nur der erste Meilenstein für die kontinuierliche Weiterentwicklung und Wartung der Lösung sein.

Softwaresysteme unterliegen einem Alterungsprozess

Software ist ein lebendiges Produkt: Häufig unterstützt sie uns dabei, Prozesse zu automatisieren und Abläufe zu beschleunigen. Doch die Welt bleibt nicht stehen, sondern entwickelt sich kontinuierlich weiter - und damit ändern sich auch die Anforderungen an Software. Sei es durch Prozessanpassungen, neue Datenschutzrichtlinien oder einen geänderten Rechtsrahmen: Ein Softwaresystem muss sich den Veränderungen der Zeit anpassen. Geschieht das nicht oder nur sehr langsam, kann es zu erheblichen Komplikationen kommen.

Agile Vorgehensweisen erfreuen sich großer Beliebtheit, weil sie Veränderungen im Projektverlauf nicht ablehnen, sondern als natürlichen Bestandteil des Entwicklungsprozesses betrachten. Wenn wir allerdings bereits erkannt haben, dass sich Anforderungen sogar schon des zeitlich stark begrenzten Entwicklungsprojekts ändern, und wir Methoden einführen müssen, damit umzugehen, dann sollten größere Änderungen nach dem Projektende keine Überraschung sein.

Veraltete oder unflexible Software sorgt für Frust und Stress bei den Anwenderinnen und Anwendern.

Wird die Software von den Prozessen, für die sie entwickelt wurde, überholt, entwickeln sich diese Prozesse häufig an der Software vorbei. Führungskräfte stehen dann vor einem Dilemma: Entweder Sie erzwingen die weitere Nutzung der Software und erzeugen damit Frust bei den Anwenderinnen und Anwendern oder sie passen die Software an die neuen Anforderungen an - was wiederum einiges an Zeit und Geld kostet. In diesem Moment ist das Kind bereits in den Brunnen gefallen. Von einem ehemals nützlichem Werkzeug wird die Software so zu einer Innovations- und Wachstumsbremse. Mit etwas Glück verfügt das Unternehmen noch über ein mit der Software vertrautes Entwicklungsteam, das kurzfristig reagieren kann. Fehlt jedoch das nötige Know-how, kann das weitaus gravierendere Folgen haben als nur stockende Prozesse.

Mehr Software bedeutet mehr bekannte Schwachstellen

Software ist ein komplexes Produkt, das sich aus vielen Teilkomponenten und anderen Abhängigkeiten zusammensetzt. Im Laufe der Zeit werden in diesen Komponenten Schwachstellen entdeckt. Das ist prinzipiell zu begrüßen, weil das Auffinden solcher Lücken die Sicherheit von Software erhöht - allerdings nur, wenn die entdeckten Schwachstellen anschließend behoben werden.

Wichtig zu verstehen ist, dass selten gewarteter Code nicht zwingend unsicher oder bereits kompromittiert sein muss. Aber je länger ein Produkt im Einsatz ist, desto mehr Zeit haben Sicherheitsforscher und potenzielle Angreifer, um mögliche Angriffspunkte zu identifizieren. Sobald eine Schwachstelle öffentlich gemeldet wird (oft, damit Unternehmen sich dieser bewusst und zum handeln gezwungen werden), erfahren jedoch auch Kriminelle davon. Die Zahl der gemeldeten Sicherheitslücken steigt seit Jahren kontinuierlich an. Daraus ergibt sich ein permanenter Handlungsbedarf - den allerdings nicht jedes Unternehmen erkennt oder ernst nimmt.

Die steigende Zahl gemeldeter Schwachstellen ist jedoch kein Grund zur Besorgnis. Im Gegenteil: Es ist besser, über Sicherheitslücken in der eigenen Software Bescheid zu wissen und darauf reagieren zu können, als irgendwann böse überrascht zu werden. Unternehmen sollten allerdings unbedingt Strategien und Prozesse entwickeln, um der wachsenden Zahl an Sicherheitsmeldungen effektiv zu begegnen.

Aussitzen ist keine gute Taktik

Eine Strategie die ich in den vergangenen Jahren immer wieder beobachten durfte ist das "Aussitzen" der Situation. Entweder fehlte den Unternehmen das Bewusstsein für die Brisanz des Themas, oder sie ignorierten es bewusst. Tatsächlich kann es auf den ersten Blick günstiger erscheinen, nicht viel in die Wartung eines Softwaresystems zu investieren - denn Wartung kann teilweise hohe Kosten verursachen. Reagiert wird dann oft erst, wenn eine kritische Sicherheitslücke in die Schlagzeilen gerät, sodass sogar die nicht-Fachpresse darüber berichtet. Spätestens wenn die Sicherheitslücke am nächsten Werktag im ganzen Unternehmen diskutiert wird, kommen unangenehme Rückfragen auf die verantwortlichen zu.

Genau dann rächt sich die "Aussitz"-Strategie: Binnen kürzester Zeit müssen sämtliche Versäumnisse der Vergangenheit aufgeholt werden. Häufig ist es nicht damit getan, einfach nur die betroffene Komponente zu ersetzen. Vielmehr steht dem Entwicklungsteam eine Mammutaufgabe bevor, etwa das genutzte Framework gleich um zwei Major-Versionen zu aktualisieren - was eine umfassende Überarbeitung des Codes nötig macht.

Aus einer vernachlässigten Sicherheitslücke wird im Handumdrehen ein Major Incident.

Muss sich das Team dannn erst einmal wieder in die betroffene Komponente einarbeiten, geht weitere, wertvolle Zeit verloren. Doch Wissenslücken bei länger nicht gewarteten Softwarekomponenten, die einen wichtigen Anteil an den Wertschöpfungsprozessen eines Unternehmens haben oder direkte Schnittstellen für seine Kunden bereitstellen, sollten grundsätzlich aufgearbeitet werden. Das betrifft übrigens nicht nur kleine Firmen, sondern selbst große Tech-Konzerne, wie ein Vorfall bei Reddit eindrucksvoll zeigt.

Fazit

Die Welt entwickelt sich weiter, und Software kann dabei nicht stillstehen. Eine regelmäßige Wartung ist deshalb unerlässlich - sie ist eine Investition in die langfristige Stabilität, Sicherheit und Handlungsfähigkeit eines Unternehmens und zahlt sich besonders in Krisensituationen aus. Durch kontinuierliche Anpassungen bleibt die Nutzererfahrung hoch, was wiederum die Akzeptanz der Lösung im Unternehmen steigert. Wichtig ist, dass das dafür notwendige Budget bereits in der Planungsphase einkalkuliert und der Wissensaustausch im Entwicklungsteam früh gefördert wird.