Vermeintliche Innovationen bei der Softwareentwicklung können sich irgendwann als Sackgasse erweisen. In solchen Fällen sollten Unternehmen rechtzeitig reagieren und behutsam gegensteuern.
Vor rund zehn Jahren waren serviceorientierte Architekturen der letzte Schrei. Durch die Wiederverwendbarkeit von Diensten in unterschiedlichen Anwendungen versprach dieses Architekturparadigma größere Flexibilität und niedrigere Kosten bei der Softwareentwicklung.
Von der damaligen Euphorie ist heute nicht mehr allzu viel übrig. Serviceorientierte Architekturen haben eine Vielzahl an Diensten geschaffen, die schwierig zu administrieren sind, und durch die Nutzung der Dienste in vielen Applikationen sind große Abhängigkeiten entstanden. Wird ein Service geändert, muss diese Änderung an vielen Stellen berücksichtigt werden. Zudem ist es äußert schwierig, die Dienste in verschiedene fachliche Kontexte einzubinden. Heute werden deshalb Microservices-Architekturen verwendet, bei denen Dienste lediglich lose gekoppelt sind und nur wenig miteinander interagieren. Die vermeintliche Innovation hat sich am Ende als Sackgasse erwiesen.
Diese Gefahr besteht natürlich nicht nur bei der Architektur von Software. Auch Programmiersprachen, Datenbanken oder Frameworks unterliegen diesem Risiko. Die Programmiersprache Kotlin beispielsweise hat viele Vorzüge, aber wie sieht ihre Zukunft aus? Wird sie sich auf Dauer durchsetzen können oder nur eine kurze Episode bleiben? Niemand kann heute sagen, ob es künftig genug Entwickler geben wird, um in Kotlin geschriebene Anwendungen auch in Zukunft noch weiterzuentwickeln. Im Bereich der Datenbanken gibt es schon seit geraumer Zeit einen regelrechten Hype um die nicht-relationale Datenbank MongoDB. Sollte aber irgendwann ein Wechsel von MongoDB auf eine andere NoSQL-Datenbank erforderlich werden, kann das eine große Herausforderung bedeuten. Der Umstieg von einer nicht-relationalen auf eine andere nicht-relationale Datenbank ist alles andere als trivial und es gibt hierfür bislang nur wenig Migrationserfahrung.
Auch bei gehypten Frameworks ist Vorsicht geboten. Wird ein ganz neues Framework beispielsweise nur von einem Unternehmen unterstützt, kann es ganz schnell wieder von der Bildfläche verschwinden, wenn der Support eingestellt wird. Diese Gefahr besteht selbst dann, wenn es sich bei dem Unternehmen um einen Global Player handelt.
Das Risiko auf ein falsches Pferd zu setzen, können Unternehmen minimieren, indem sie mit Bedacht vorgehen. Sie sollten keinesfalls Technologien nur um des Hypes Willen einsetzen, sondern auf IT zurückgreifen, die sich bereits bei anderen Firmen bewährt und allgemein durchgesetzt hat. Aber auch solche Technologien sind nie ganz davor gefeit, in einer Sackgasse zu enden. Was können Unternehmen in einem solchen Fall tun? Zunächst müssen sie überhaupt erst einmal feststellen, dass sie auf einem problematischen Weg sind, um darauf rechtzeitig reagieren zu können. Eine technologische Sackgasse verursacht in aller Regel nämlich keinen großen Knall. Sie ist vielmehr ein schleichender Prozess: man tut sich immer schwerer, Entwickler für seine Software zu finden; die Kosten für den Unterhalt der Technologie steigen kontinuierlich an; der Support der Hersteller dafür läuft aus; oder im Fall von Open-Source-Technologien schrumpft die Community dahinter immer mehr zusammen.
Zeichnen sich solche Entwicklungen ab, sollten Unternehmen vorsichtig gegensteuern. Das kann ein Prozess sein, der durchaus mehrere Jahre in Anspruch nimmt. Eine Möglichkeit ist beispielsweise, neue Komponenten einer Software auf einer anderen, zukunftsfähigeren Umgebung zu betreiben – und die alten Komponenten sukzessive auf diese Umgebung zu migrieren. Eine große Herausforderung besteht dabei oft im Mitnehmen der Mitarbeiter, da sie häufig dazu tendieren, an vertrauten Technologien festzuhalten. Deshalb ist oft viel Überzeugungsarbeit erforderlich. Der erfolgreiche Weg aus der Sackgasse ist diesen Aufwand aber definitiv wert.
