Eine reiche Landschaft an Herausforderungen
Interne Rich Clients haben häufig eine lange Historie und sind früh in einem Projekt aus der Notwendigkeit heraus entstanden, Backoffice-Prozesse einfacher abwickeln zu können. Dabei liegt der Fokus darauf, möglichst schnell und einfach eine funktionierende Lösung zur Verfügung zu stellen, anstatt lange über Technologie-Stacks und Architektur nachzudenken. Deswegen liegt nahe, eine Umsetzung auf der Basis des «üblichen» Stacks zu machen, anstatt ein Framework zu wählen, das für Rapid Development besonders geeignet wäre. Ebenso oft wachsen solche Tools dann über die Zeit, weil sie schon «da» sind und man darum die Kosten einer neuen Applikation vermeiden kann, wenn man einfach noch weitere Funktionen anbaut.
Aus dieser Ungeplantheit ergibt sich auch die Vielfalt der Plattformen, die sich bei solchen Tools finden. Eclipse RCP ist ein beliebtes Standbein, insbesondere, wenn doch etwas Strategie vorhanden war und diverse Tools als Erweiterungen unter einem gemeinsamen Dach zusammengefasst werden sollen. Aber auch Access-Lösungen, Delphi UIs, Swing-Applikationen und natürlich Excel-Sheets finden sich.
Diese Technologien haben sich in den vergangenen Jahren zu einer Sackgasse innerhalb von Firmen entwickelt:
Know-how-Mangel: Die Entwickler:innen die die Technologie und Fachlichkeit kennen, stehen oft kurz vor der Pensionierung, neue Entwickler:innen, die das Tool pflegen können, sind in den internen Teams nicht mehr einfach verfügbar. Der technische Fokus liegt typischerweise mittlerweile auf einer oder mehreren Webapplikationen für das Endkund:innengeschäft, so dass Entwickler:innen, die die Rich Client-Technologien beherrschen, nicht mehr breit vertreten sind im Unternehmen. Gerne ergibt sich daraus auch die Sichtweise, dass es «niemanden mehr gibt, der X lernt» (auch wenn sie vielleicht nur im eigenen Mitarbeiter:innenstamm wenig vertreten sind).
Fehlender Anreiz zum Lernen: Oft wird die eingesetzte Technologie nicht als «modern» wahrgenommen, was zumindest psychologisch eine Herausforderung darstellt. Dadurch wollen auch im Unternehmen vorhandene Entwickler:innen etwas «so altes» nicht mehr lernen. Veränderte Umgebungsbedingungen: Die internen IT-Landschaften sind vielfältiger geworden. Anwendungen müssen nicht mehr nur auf einem Windows-Desktop laufen, sondern auch andere Desktop-Betriebssysteme und häufig Mobilgeräte unterstützen.
Veränderte Umgebungsbedingungen: Die internen IT-Landschaften sind vielfältiger geworden und interne Tools müssen nicht mehr nur auf einem spezifischen Windows-Desktop mit bekannter Version und Software-Minimalausstattung laufen. Oft gibt es den starken Wunsch, mobile Geräte zu unterstützen und dabei die vorhandene Geschäftslogik und Validierungen zu erhalten. Auch Unterstützung für andere Desktop-Betriebssysteme wird immer häufiger eine Anforderung, die auf den bestehenden technischen Lösungen schwer umzusetzen sind.
Komplexe Rollouts: Die zentrale Verteilung von Rich Clients auf Dutzende oder Hunderte Clients ist zwar generell ein gelöstes Problem. Die Prozesse, die diese Rollouts umgeben, sind aber oft das Gegenteil von agil und nicht dazu geeignet, häufig Updates und Features auszurollen.
Abhängigkeit von Citrix und Co: Anstelle eines Rollouts auf alle Clients hat sich in den letzten Jahren – auch mit der steigenden Zahl von Menschen die im Homeoffice arbeiten – eine Virtualisierung von Desktops etabliert. Damit kauft sich ein Unternehmen aber auch teure Verträge für die entsprechende Virtualisierungslösung ein.
Mangelnde Wartung in der Vergangenheit: Oft ist die Version des Toolstacks, auf dem das interne Tool umgesetzt wurde, hoffnungslos veraltet, sodass nun Inkompatibilitäten mit modernen Betriebssystemen ins Haus stehen. Ein Update der Version wäre eine teure Angelegenheit, weil ein grosser Releasesprung vollzogen werden muss. Dazu kommt das Problem, dass einem dann die Entwickler und die Langzeitpflege fehlen (siehe oben), so dass sich die Frage stellt, ob sich ein Update je auszahlen wird.
Die reichen Verlockungen des Webs
Webapplikationen sind derzeit die Standard-Antwort auf die meisten Problemstellungen, da sie flexible Lösungen für viele Probleme bieten. Daher ist es naheliegend, auch für interne Tools auf das Web zu setzen, da dies viele der obigen Punkte adressiert:
Das Know-how ist verfügbar: Entwickler:innen, die in Webtechnologien geschult sind, sind entweder bereits in der Firma tätig oder lassen sich (einfacher) auf dem Arbeitsmarkt finden.
Flexibilität: Webapplikationen funktionieren grundsätzlich auf allen Geräten, die einen Browser haben. Moderne Umgebung: Das Web ist eine moderne und stabile Plattform.
Einfache Rollouts: Im Normalfall gibt es ein zentrales Deployment, ggf. auch mit der Integration von A/B-Tests, Canaries oder anderen Testmethoden.
Gerade für Tools, die auch sinnvoll auf mobilen Geräten laufen sollen, sind in den vergangenen Jahren standardisierte APIs hinzugekommen, die die wichtigsten Anwendungsfälle (Zugriff auf Kamera und Position) einfach und stabil unterstützen. Damit lassen sich einfach und effizient Lösungen für viele Probleme auch auf Mobilgeräten bauen.
In Form von Progressive Web Applications (PWA) lassen sich Webapplikationen sogar installieren und stehen damit auf Mobilgeräten einfach als normale Applikation zur Verfügung. Die Installation und Aktualisierung der Apps ist im Vergleich zu den Appstores mit Ihren Reviewprozessen deutlich einfacher.
Auch für Desktopapplikationen bieten sich Vorteile. Automatisches Speichern von beliebigem Fortschritt, Support für Deeplinks so dass man Verweise auf eine spezifische Stelle eines Datensatzes schicken kann, einfache Integration mit weiteren Applikationen über Links, Integration verschiedener Datenquellen über clientseitige Transklusion … Dies sind mögliche Verbesserungen, die eine Webapplikation einfach unterstützt und die Nutzbarkeit für Benutzer erhöht.
Hürdenreichtum des Webs
Aber nicht alle Dinge, die gerade in einem internen Tool unterstützt werden sollten, sind einfach in einer Webapplikation umzusetzen. Klassische Tastaturnavigation, Support für Shortcuts, komplexe Eingabefelder oder auch automatische Navigation in strukturierten Eingabemasken sind machbar, aber nie so reaktiv und sauber funktionierend wie nativ. In der Regel werden Webanwendungen als Single-Page-Applikationen mit einem mehr oder weniger schwergewichtigen Javascript-Framework realisiert, was die Reaktionszeiten einzelner Seiten beträchtlich erhöhen kann und so für Benutzer:innen Frust bereiten kann. Dazu kommt, dass mit der Umsetzung in Form einer SPA erst viel komplexe Logik ausgeführt werden muss, bevor überhaupt etwas zu sehen ist, was gern und oft fehlschlagen kann.
Auch andere wenig mondäne Themen wie das Drucken oder die Einbindung weiterer Hardware (Kartenleser, Scanner, mechanische Geräte aller Art …) sind deutlich schwieriger, insbesondere dann, wenn man nicht nur Daten empfangen möchte, sondern auch noch mit Ihnen in beide Richtungen kommunizieren möchte.
Und auch das Layout ist kein Selbstläufer. Interne Tools haben oft eine grosse Informationsdichte und können nicht einfach in ein gut gestaltetes und responsives, sich auf unterschiedliche Geräte anpassendes Weblayout umgesetzt werden.
Ein existierender Rich-Client enthält natürlich nicht-triviale Mengen an Logik und Validierungen, die bei einem Umstieg auf eine Webapplikation durch eine entsprechende – oft nicht vorhandene – Serverseitige Komponente abgedeckt werden müssen. Dabei lassen sich die Implementierungen natürlich nicht 1:1 übernehmen und je nachdem ist viel Wissen um das «Warum» spezifischer Details nicht mehr vorhanden. All das macht es wahrscheinlich, dass die Implementierung Bugs (oder überflüssige Logik) enthält und der Umstieg so in einen mehr oder weniger langen Rewrite ausartet.
Und nicht zuletzt stellt sich im Web die Frage nach der Frontend-Integration, gerade, wenn man auf ein SPA Framework setzt. Wie kommen verschiedene Aspekte des Tools – vielleicht von unterschiedlichen Teams gepflegt – zusammen? Idealerweise ohne sich einen grossen, zentral koordinierten Releaseprozess einzuhandeln? Ist es wirklich sinnvoll, auf «Micro-Frontends» zu setzen und die Nutzer:innen N verschiedene Versionen eines SPA-Frameworks in den Browser laden zu lassen? Und wie viel Maintenance-Bürde halse ich mir mit einem Technologiestack auf, der typischerweise hunderte von Dependencies hat?
Fazit
Wie so oft in der IT gibt es nicht die eine Lösung, die auf alle Probleme passt. Stattdessen hilft es, im Auge zu behalten, welches Problem man eigentlich versucht zu lösen.
Tools, die klare, überschaubare Problembereiche abdecken, oder auch Tools, deren Hauptanwendungsfeld mobile Geräte sind, können wahrscheinlich am ehesten von einer Migration ins Web profitieren, da man eine Plattform erhält, die man nicht selbst verwalten muss.
Einfache Dateneingabe-, -verwaltungs- und -auswertungstools, die z. B. die Validierung von Nutzereingaben oder Freigabeprozesse abbilden, können zumindest ohne grosse Nachteile für die Nutzer:innen in den Browser migriert werden.
Komplexe Tools für Fachexperte:innen, die auch viel Logik in Ihren Masken beinhalten und/oder mit vielfältiger anderer Hardware integriert werden müssen, sind hingegen technisch portierbar. Eine solche Migration ins Web birgt aber klar das Risiko, dass die Effizienz und Zufriedenheit der Nutzer:innen sinkt, weil sie für Ihre Bedürfnisse eine Lösung bekommen, die in Bezug auf Nutzer:innenfreundlichkeit und Schnelligkeit schlechter funktioniert als ein Rich Client.
Am Ende muss man den Stellenwert von internen Tools richtig einordnen – wenn nur dieses spezifische Tool mein Backoffice befähigt, meine wichtigen Prozesse effizient zu betreiben, sollte es kein Nachgedanke sein, sondern verdient die notwendige Aufmerksamkeit. Dazu gehört, dass man in Wissen und Fähigkeiten der eigenen Mitarbeiter investiert. Gleichzeitig lässt uns das Web die Möglichkeit für immer mehr Bereiche auf schon etabliertes Wissen und Tooling zurückzugreifen, um auch internen Benutzer:innen hervorragende Lösungen anzubieten. Und falls einem die Wahl zwischen Webapplikation oder nativer Applikation zu schwerfällt, gibt es inzwischen natürlich auch noch verschiedene Cross-Plattform Ansätze, mit denen sich die beiden Welten etwas näher zusammenbringen lassen.
Ich danke Anja Kammer, David Caspar, Timo Loist und Johannes Seitz für Ihre hilfreichen Anmerkungen zu einer früheren Version dieses Artikels.
Das Headerbild stammt von Glenn Carstens-Peters auf Unsplash.