Serviceorientierte Architekturen waren vor rund zehn Jahren 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. Zudem sind durch die Nutzung der Dienste in vielen Applikationen große Abhängigkeiten entstanden. Wird ein Service geändert, muss das an vielen Stellen nachgeführt werden. Zudem ist es äußert schwierig, die Dienste in verschiedene fachliche Kontexte einzubinden. Heute verwenden IT-Architekten daher vorzugsweise Microservices-Architekturen. Diese Dienste sind lediglich lose gekoppelt und interagieren nur wenig miteinander. Die vermeintliche Innovation der serviveorientierten Architektur hat sich also als Sackgasse erwiesen.
Auch Programmiersprachen haben einen Lebenszyklus
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 ihre Zukunft ist unklar. Niemand weiß, ob sie sich auf Dauer durchsetzen kann oder sie nur eine kurze Episode bleibt. Ebenfalls offen ist die Frage, ob es künftig genug Entwickler geben wird, um in Kotlin geschriebene Anwendungen auch in Zukunft weiterzuentwickeln. Bei Datenbanken gibt es schon seit geraumer Zeit einen regelrechten Hype um die nicht-relationale Datenbank MongoDB. Sollte irgendwann ein Wechsel von MongoDB auf eine andere NoSQL-Datenbank erforderlich sein, kann das eine große Herausforderung bedeuten. Der Umstieg von einer nicht-relationalen auf eine andere nicht-relationale Datenbank ist alles andere als trivial. Außerdem haben die IT-Dienstleister hierfür bislang nur wenig Migrationserfahrung.
Auch bei den gehypten Frameworks ist Vorsicht angesagt. 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.
Bei der Software-Auswahl hilft der Erfolgsbeweis
Das Risiko auf ein falsches Pferd zu setzen, können Unternehmen nur minimieren, indem sie bei der Software-Auswahl mit Bedacht vorgehen. Sie sollten keinesfalls Technologien nur um des Hypes Willen einsetzen, sondern auf IT zurückgreifen, die sich bereits bei anderen Unternehmen bewährt und allgemein durchgesetzt hat. Aber auch solche Technologien sind nie ganz davor gefeit, in einer Sackgasse zu enden. In einem solchen Fall müssen Unternehmen zunächst einmal feststellen, dass sie auf einem problematischen Weg sind, um darauf rechtzeitig reagieren zu können. Eine technologische Sackgasse verursacht nämlich typischerweise 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 besteht beispielsweise darin, neue Komponenten einer Software auf einer anderen, zukunftsfähigen 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. jf
