Benutzeroberflächen modernisieren

Whitepaper
Benutzeroberflächen modernisieren
Der Spagat zwischen Kosten und Nutzen
Benutzeroberflächen modernisieren
Der Spagat zwischen Kosten und Nutzen
Autoren:
Stefan Kühnlein
und Stephan Rauh
für OPITZ CONSULTING
Haben Sie Fragen
zu diesem Thema?
Dann sprechen Sie uns gerne an!
Stefan Kühnlein
Solution Architect
[email protected]
Stephan Rauh
Senior Consultant
[email protected]
Inhalt
Vorwort
Vorwort
Grafische Oberflächen – gestern und heute
Die Sicht der Anwender
Technologische Argumente
Architekturoptionen
Firmenkultur berücksichtigen
UI-Frameworks
Migrationsstrategien
Agilität im Modernisierungsprojekt
Zusammenfassung
Bildnachweise
UI-Modernisierung mit OPITZ CONSULTING
Über die Autoren
Über OPITZ CONSULTING
Nach dem Spiel ist vor dem Spiel! Benutzeroberflächen müssen fortlaufend
erneuert werden. Kaum ein System bleibt über Jahrzehnte unverändert.
Es gibt viele Gründe für eine Modernisierung: Manchmal ändern sich die
fachlichen Anforderungen, manchmal wird das Bedürfnis nach einem
Relaunch wach. Nur: Was ist die beste Strategie? Welche Optionen gibt es?
Und was ist bei der Modernisierung zu beachten?
Unter den verschiedenen Architekturschichten eines zu modernisierenden
Altsystems bedarf die Präsentationsschicht einer besonderen Aufmerksamkeit. Insbesondere ihre Modernisierung hat unmittelbare Auswirkung auf
die zukünftige Zielarchitektur.
Für die Strategie stellen sich somit Fragen wie „Worin liegen die wesentlichen Herausforderungen bei der Modernisierung von Benutzeroberflächen?“ oder „Welche technischen Möglichkeiten und Varianten bieten sich
an?“. Wir stellen Ihnen in diesem Whitepaper verschiedene Optionen und
für die Modernisierung und die Verbesserung von Benutzeroberflächen vor,
mit denen Sie Ihren Mitarbeitern die tägliche Arbeit erleichtern.
Wir wünschen Ihnen gute Informationen und viel Spaß beim Lesen!
Texte und Abbildungen wurden mit größter Sorgfalt erarbeitet. OPITZ CONSULTING kann jedoch für eventuell verbleibende fehlerhafte Angaben und
deren Folgen weder eine juristische Verantwortung noch irgendeine Haftung übernehmen. Das Recht an dargestellten Verfahren, Showcases, Implementierungsbeispielen und Sourcecodes liegt ausschließlich bei OPITZ CONSULTING.
© OPITZ CONSULTING Deutschland GmbH 2015
Whitepaper: Benutzeroberflächen modernisieren
Seite 2
Grafische Benutzeroberflächen –
gestern und heute
Mit der rasanten Verbreitung von iPod, iPad, Tablet und Co. ist eine neue
Generation von Benutzeroberflächen entstanden. Noch Anfang dieses
Jahrtausends wurden grafische Benutzeroberflächen (GUI) nach dem Motto „Viel hilft viel“ entworfen. Auf geringstem Raum versuchten Entwickler
damals, so viele Informationen wie möglich darzustellen. Ziel war es, alle
Aufgaben auf wenigen Masken auszuführen. Alle Informationen sollten
auf einen Blick zu erfassen sein. Häufig war das Design der Eingabemaske
eher technisch getrieben und orientierte sich wenig an den Anforderungen
des Endanwenders. Die Konsequenz waren äußerst kompakte Masken mit
zahlreichen Eingabefeldern, Buttons und Plausibilitäten. Der Nutzer konnte
Buttons oder Eingabefelder vielfach dynamisch ein- und ausblenden. Diese
Masken waren teilweise echte Meisterwerke, die auch heute noch von
erfahrenen Mitarbeitern sehr effizient bedient werden können.
Wie schon angedeutet, haben solche Masken aber auch ihren Preis: Die
Usability. Sie sind selten intuitiv bedienbar. Durch die Vielzahl von Eingabefeldern und Buttons sowie deren Abhängigkeiten untereinander benötigen Mitarbeiter vor der ersten Benutzung eine Schulung. Dazu sind ein
Benutzerhandbuch und eine Hilfe erforderlich, in denen die Anwender alle
wesentlichen Informationen nachlesen können. Auch aus technischer Sicht
haben diese Applikationen Nachteile: Aufgrund ihrer komplexen Benutzeroberflächen steigt der Aufwand für Wartung und Erweiterungen. Durch
die wechselseitigen Abhängigkeiten der GUI-Elemente sind Änderungen
schwierig und riskant.
Die Verbreitung von Web-Apps führte in den letzten Jahren zu einem Umdenken bei der Gestaltung von grafischen Benutzeroberflächen. Heute
wird verstärkt auf die intuitive Bedienbarkeit geachtet.
Die Sicht der Anwender
Der Übergang von einem Paradigma zum anderen erfolgt natürlich selten
reibungslos. Die grafischen Oberflächen von Anwendungen, die schon
mehrere Jahren im Einsatz sind, entsprechen meist noch nicht der neuen
Sichtweise. Ihre Defizite fallen für heutige Anwendern entsprechend ins
Gewicht:
Wenig intuitive Bedienung
Ein häufiges Problem bei komplexen „Expertenmasken“ ist, dass sie nicht
intuitiv bedienbar sind, was heutzutage nicht mehr Stand der Technik ist.
Heute würde man die nötige Zeit zu investieren, um die Dialogführung zu
vereinfachen. Wie so oft im Leben, gibt es aber auch bei Benutzeroberflächen keine Regeln ohne Ausnahme. So kommt es durchaus vor, dass eine
„Expertenmaske“ die optimale Lösung ist, weil sich mit ihr alles auf einen
Blick erfassen und mit wenigen Mausklicks erledigen lässt. Den meisten
Anwendungen schaden allerdings komplexe und überladene Oberflächen.
© OPITZ CONSULTING Deutschland GmbH 2015
Fragt man heute Endanwender nach ihren Anforderungen an die Benutzeroberfläche, so erhält man folgende Antworten:
Anwender möchten ...
■ … die Oberfläche und die dargestellten Informationen sofort verstehen
und diese direkt mit dem entsprechenden Geschäftsvorfall in Verbindung bringen.
■ … ihre Aufgaben erledigen. Sie möchten nicht darüber nachdenken
müssen, wie sie das machen können. Das soll sich einfach intuitiv für
sie erschließen.
■ … die anstehenden Aufgaben möglichst schnell erledigen können.
■ … keine speziellen Kenntnisse über den weiteren Prozessablauf erwerben müssen, nur um die Anwendung bedienen zu können.
Veraltetes GUI-Design
Neben der fehlenden intuitiven Bedienung wirkt das GUI-Design bestehender Altanwendungen im Allgemeinen etwas „verstaubt“. Getrieben von
Web 2.0 und Apps haben Benutzer heute neue Anforderungen an das GUIDesign. Zum Beispiel hat sich die Darstellung von Eingabefeldern und
Buttons weiterentwickelt, so dass sie sich wesentlich besser in die Gesamtoptik der Benutzeroberfläche einfügen. Des Weiteren erlauben moderne
Gestaltungselemente optisch ansprechendere Oberflächen. Und nicht
zuletzt passt sich die Benutzeroberfläche durch Responsive Design automatisch an die Größe des jeweiligen Endgeräts an. Auf kleineren Bildschirmen werden so weniger wichtige Informationen ausgeblendet und der
geringe Platz für die Kernfunktionen der Anwendung reserviert.
Der aktuelle Trend im Webdesign setzt übrigens auch Maßstäbe für das
Anwendungsdesign: Dialoge mit Schatten und 3D-Effekten sind einer
wesentlich nüchterneren, flachen Optik mit kräftigen Farben gewichen.
Fehlende Akzeptanz
Die Relikte aus der Vergangenheit haben heute kaum noch eine Chance,
von den Nutzern akzeptiert zu werden. Aus der digitalen Welt sind Anwender Programme mit einer intuitiven Benutzerführung gewöhnt. Denken Sie
nur an Netflix oder Amazon!
Die Benutzeroberflächen wenden sich mittlerweile an ein Publikum, das
sich nicht notwendigerweise mit EDV auskennt. So lassen sich Touchscreens von Bordcomputern und Navigationssystemen in modernen PKWs
auch ohne Handbuch bedienen.
Inzwischen entscheiden Anwender sehr schnell, ob ihnen eine neue Anwendung gefällt oder nicht. Visuelle Darstellung und Bedienbarkeit sind
dabei entscheidende Faktoren. Die Benutzer von mobilen Devices möchten
ihre Anwendung durch Wischen, Drehen oder gar Schütteln bedienen
können. Auch wenn dies nicht für alle Anwendungen realisierbar ist, so
erwartet der Anwender inzwischen doch wenigstens einfache Funktionen
wie Drag & Drop.
Whitepaper: Benutzeroberflächen modernisieren
Seite 3
Veränderung der Geschäftsprozesse
Ein weiterer Treiber für die UI-Modernisierung ist die ständige Veränderung der zugrundeliegenden Geschäftsprozesse. Geschäftsprozesse werden
im Laufe des Lebenszyklus einer Anwendung immer wieder angepasst. Sei
es durch gesetzliche Neuerungen, durch Veränderungen in Geschäftsstruktur und -Strategie oder durch die Optimierung der bestehenden Geschäftsabläufe.
Steigende Qualitätsanforderungen
In den letzten Jahren sind die Qualitätsanforderungen – auch bekannt als
„nicht funktionale Anforderungen“ – kontinuierlich gestiegen. Dies betrifft
vor allem die Performance. Bewährte Anwendungen sind den Anforderungen immer größerer Datenmengen oft nicht mehr gewachsen. Manchmal
hilft hier eine neue Hardware. In vielen Fällen reicht das allerdings nicht,
sondern die Architektur der grafischen Oberflächen muss erneuert werden.
In vielen Fällen werden die Benutzeroberflächen bei der Planung von Anpassungen übersehen, oder aus Kostengründen werden nur die allernotwendigsten Veränderungen vorgenommen. Auf diese Weise werden die
Masken regelmäßig erweitert und damit immer komplexer.
Hinzu kommt, dass die Ansprüche der Anwender z. B. an die Performance
einer Suchfunktion gewachsen sind. Wir alle sind von Google verwöhnt
und wissen: Egal, wie kompliziert eine Suchanfrage ist, Google beantwortet sie in Bruchteilen einer Sekunde. Die Suchmaschine setzt damit einen
Maßstab, an dem sich auch andere Anwendungen orientieren müssen.
In unseren Modernisierungsprojekten treffen wir auf Anwendungen, bei
denen viele Eingabefelder und Funktionen schon lange nicht mehr verwendet werden und teilweise auch schon gar nicht mehr funktionieren.
Manchmal ist auch das Wissen über die älteren Funktionalitäten im Laufe
der Zeit verlorengegangen. Durch ständige Anpassungen verwässern die
Benutzeroberflächen außerdem so stark, dass der Nutzer nicht mehr erkennt, welche Informationen für eine spezifische Aufgabe relevant sind.
Wegfall der verwendeten Frameworks
In vielen Fällen ist eine Modernisierung der grafischen Benutzeroberfläche
notwendig, weil die Weiterentwicklung und Wartung der verwendeten
Frameworks eingestellt wurde. Für eine begrenzte Zeit ist das noch kein
Problem: Die Anwendung läuft ja weiterhin. Auf lange Sicht ist das allerdings riskant. Wer sagt Ihnen, dass die Anwendung nach dem nächsten
Betriebssystem-Update noch läuft?
Technologische Argumente
Ein Beispiel ist Swing, die Oberflächentechnologie für DesktopAnwendungen, die über viele Jahre Bestandteil von Java war: Vor einiger
Neben den Defiziten, die Altanwendungen vor allem für den Anwender mit Zeit wurde Swing durch JavaFX abgelöst. Für ältere Versionen von Java
sich bringen, und den damit verbundenen Konsequenzen gibt es auch aus und damit auch für Swing hat Oracle schon vor einiger Zeit die Entwicktechnologischer Sichtweise triftige Gründe, die für eine Modernisierung lung eingestellt, und auch in den aktuellen Java-Versionen wird Swing
von grafischen Benutzeroberflächen sprechen.
nicht mehr weiterentwickelt. Wenn Sie Swing einsetzen, kommen Sie also
langfristig nicht um einen Wechsel der Technologie herum.
Fehlende Wartbarkeit und steigende Kosten
Wie die Back-End-Systeme einer Anwendung unterliegt auch die Benut- Bei Web-Anwendungen sind die Herausforderungen noch gravierender: Zu
zeroberfläche ständiger Veränderung. Die Haupttreiber hierfür sind die Anwendungen im Internet geben die Hersteller mit der Einstellung eines
kontinuierliche Veränderung der Geschäftsprozesse und die damit verbun- Frameworks auch keine Security Patches mehr heraus. In diesem Szenario
denen Erweiterungen an den Erfassungsmasken.
steht also im schlimmsten Fall – z. B. bei einem gelungenem Hackerangriff
- sogar die Existenz des Betriebs auf dem Spiel.
Bei jeder Veränderung der Geschäftsprozesse werden Masken angepasst,
oder es kommen neue Masken hinzu. Nach mehreren Iterationen ent- Bei Apache Struts liegt die Situation ein wenig anders. Einstmals ein sehr
spricht die Anwendung dann nicht mehr der ursprünglichen Architektur. verbreitetes Framework für Internetanwendungen (vielleicht sogar der
Dafür gibt es meist gute Gründe, problematisch wird es jedoch, wenn die Marktführer), wird Struts heute so selten benutzt, dass es allmählich
Weiterentwicklung nicht in einer neuen, konsistenten Architektur mündet. schwierig wird, Personal zu finden, das sich damit auskennt. Und das, obwohl das Framework als solches noch aktiv weiterentwickelt wird.
Im Laufe der Zeit steigt die Komplexität schnell an. Im Idealfall entwickeln
Development- und Testteams neue Testfälle und stellen damit sicher, dass Andere Frameworks – beispielsweise JSF und AngularJS – haben sich nach
das Risiko von Erweiterungen beherrschbar bleibt. In Extremfällen wird die einem Versionswechsel so stark verändert, dass die Portierung einer AnAnwendung so komplex, dass auch triviale Änderungen kaum noch mög- wendung auf die neue Version fast auf eine Neuentwicklung hinausläuft.
lich sind. Spätestens dann ist die Balance zwischen Kosten und Nutzen aus
dem Ruder geraten.
© OPITZ CONSULTING Deutschland GmbH 2015
Whitepaper: Benutzeroberflächen modernisieren
Seite 4
Personalfluktuation und -Rekrutierung
Weit verbreitet ist die Aufteilung in drei Schichten:
Ein nicht zu unterschätzender Aspekt betrifft das Thema Personal. In vielen ■ „Presentation Layer“ (PL) für die reine Darstellung
Fällen spricht aus technischer Sicht nichts dagegen, eine bestehende An- ■ „Application Layer“ (AL) für die Business-Logik
(liegt zwischen PL und DAL)
wendung weiter laufen zu lassen. Es gibt viele Anwendungen, die ursprünglich auf dem Großrechner entwickelt und immer noch verwendet ■ „Data Access Layer“ (DAL) für die Datenbankanbindung
werden.
Diese Schichten können prinzipiell sowohl auf dem Client als auch auf dem
Nur geht die Generation der Entwickler, die sich mit diesen Anwendungen Server implementiert werden. Daraus ergeben sich zahlreiche Kombinatiauskennt, allmählich in Rente. Jüngere Entwickler lassen sich in der Regel onsmöglichkeiten, aus denen Sie sich die für Ihr Anwendungsszenario
nicht davon überzeugen, die Wartung für Programme, die in COBOL, Fort- optimal geeignete Variante aussuchen können (vgl. Abbildung 1).
ran, Natural oder PL/1 geschrieben wurden, zu übernehmen.
Da in diesen Anwendungen das Know-how von Jahrzehnten steckt, bietet
sich eine schrittweise Migration in neuere Programmiersprachen an. Häufig startet man mit der Modernisierung der grafischen Oberfläche und
kümmert sich später – in einem unabhängigen Projekt – um die Modernisierung der Server-seitigen Programmteile.
„Bring your own device“
Heutzutage hat praktisch jeder Mitarbeiter einen PC, ein Smartphone und
ein Tablet. Veränderungen in Arbeitsorganisation und Lebensgewohnheiten
führen dazu, dass immer mehr Mitarbeiter auch von ihren privaten Geräten oder von einem Kundenrechner aus auf Firmendaten zugreifen möch- Abbildung 1: Mögliche Client/Server-Kombinationen
ten. Damit geht der IT die Kontrolle über die Laufzeitumgebung ihrer Anwendung verloren. Sie muss sich auf eine Vielzahl verschiedener Zielplatt- Jede dieser Varianten hat ihre Vor- und Nachteile. Bereits die Auswahl
einer Variante ist richtungsweisend für die Gesamtarchitektur, die im Rahformen einstellen.
men einer Oberflächen-Modernisierung mit umgesetzt werden sollte. Im
Barrierefreiheit und Ergonomie
Folgenden nehmen wir einige dieser Architekturoptionen genauer unter
Bei der Auswahl einer neuen Oberflächentechnologie sollten Sie auch die die Lupe.
Punkte Barrierefreiheit und Ergonomie berücksichtigen. Ältere Anwendungen nehmen in der Regel wenig Rücksicht auf die Belange von Mitarbei- Desktop- oder Web-Anwendung?
tern mit körperlichen Einschränkungen. Eine Modernisierung der Benutzer- Soll die Anwendung hauptsächlich auf dem Client laufen oder besser auf
oberfläche bietet Ihnen die Chance, das zu korrigieren. Das gleiche gilt für dem Server? Das ist eine jener Fragen, die ungefähr alle zehn bis fünfzehn
die Ergonomie der Anwendung: Seit einigen Jahren sind Software- Jahre neu diskutiert werden. Ursprünglich gab es nur einfache Terminals,
Entwickler gesetzlich verpflichtet, ihre Anwendungen ergonomisch zu die von einem einzigen Server bedient wurden. Mit dem Aufkommen der
gestalten. Die Norm EN ISO 9241 (siehe https://de.wikipedia.org/wiki/ PCs wurden Desktop-Anwendungen populär. Später gab es Client-ServerEN_ISO_9241#EN_ISO_9241-110_Grunds.C3.A4) bietet einen guten Ori- Anwendungen und den Versuch, „Thin Clients“ zu etablieren. Momentan
entierungsrahmen. Anwendungen sollen laut dieser Norm
gibt es wieder eine starke Bewegung hin zu leistungsfähigen Anwendun■ der Aufgabe angemessen sein,
gen auf dem Client. Dieser Trend wird zum einen durch die große Verbrei■ selbsterklärend sein,
tung mobiler Geräte gefördert, die einen Teil der Zeit offline sind. Zum
■ den Erwartungen des Benutzer entsprechen
anderen ist die Browser-Technologie durch HTML5 und ausgefeilte Ja■ und fehlertolerant sein.
vaScript-Compiler mit nativen Desktop-Anwendungen in vielerlei Hinsicht
konkurrenzfähig geworden. Die Grenzen zwischen Desktop-Anwendungen
und Web-Anwendungen beginnen zu verschwimmen.
Architekturoptionen
Die Softwarearchitektur von modernen Geschäftsanwendungen ist in
verschiedene Schichten aufgeteilt. Die Schichten entsprechen zum einen
fachlichen Kriterien („vertikale Aufteilung“) und zum anderen technischen
Kriterien („horizontale Schichten“).
© OPITZ CONSULTING Deutschland GmbH 2015
Ungeachtet dessen haben native Desktop-Anwendungen immer noch viele
Vorteile: Die Anwender haben den vollen Zugriff auf die SystemRessourcen. Desktop-Anwendungen können problemlos drucken, Dateien
lesen oder schreiben. Denken Sie nur an den häufig geforderten Import
von Excel-Dateien!
Whitepaper: Benutzeroberflächen modernisieren
Seite 5
Bei der Entscheidung können Sie sich an einigen Fragen orientieren:
■ Wo soll die Anwendung laufen? Wird sie auch außerhalb des Büros
benötigt?
■ Wie viele verschiedene Zielplattformen wollen Sie unterstützen?
■ Soll die Anwendung auf Smartphones oder Tablets laufen?
■ Wie gut funktioniert Ihre Softwareverteilung? Wenn die automatischen
Software-Updates nicht auf allen PCs funktionieren, wird eine teure
manuelle Nacharbeit erforderlich.
■ Ist Ihr Netzwerk für den Anwendungstyp ausreichend groß dimensioniert? Dabei spielen Leitungskapazität UND Latenzzeit eine Rolle.
Logik auf Client oder Server?
Der Siegeszug von JavaScript hat eine neue Auswahlmöglichkeit bei der
Client-Architektur zu Gunsten von Browser-basierten Anwendungen eröffnet. Sie haben jetzt die Möglichkeit, Teile Ihrer Anwendungslogik auf dem
Client zu implementieren und im Browser direkt ausführen zu lassen.
Viele der Einschränkungen, die wir oben erwähnt haben, gelten für moderne HTML5-Anwendungen nicht mehr. Sie können auf die GPS-Koordinaten
Ihres Smartphones zugreifen, das Mikrofon und die Webcam abfragen und
dank einer lokalen Datenbank sogar Offline-Phasen überstehen. HTML5Anwendungen sind heutzutage sehr schnell – seit einigen Jahren sogar
schnell genug für 3D-Spiele, wie Daniel Kurka 2013 in einer eindrucksvollen Session auf der Java-Konferenz „Jax“ demonstrierte (https://jax.de/
wjax2013/special-days/gwt-day.html).
Die meisten Business-Anwendungen brauchen deutlich weniger Rechenleistung. Bei ihnen stellt sich die Frage, warum man diese Leistung, die
ohnehin vorrätig ist, brachliegen lässt und die komplette Logik auf dem
Server implementiert. Was das betrifft, sind sich die Autoren nicht einig.
Die Ansicht, dass Business-Logik auf dem Server implementiert werden
muss, weil dort die besseren Werkzeuge vorliegen und weil sie dort besser
vor unbefugtem Zugriff geschützt ist, ist weit verbreitet. Es gibt aber in
den meisten Fällen keinen zwingenden Grund, der es verbietet, Logik auf
dem Client zu implementieren.
Abbildung 2: Vor- und Nachteile der verschiedenen Anwendungstypen
Unstrittig ist, dass es sich lohnt, einzelne Teilaspekte der Programmlogik
auf dem Client zu implementieren und damit teure Server-seitige Ressourcen zu sparen. Wenn Sie einfache Berechnungen und Plausibilitäten auf
dem Client implementieren, sparen Sie nicht nur Netzwerk-Traffic, sondern
Sie können oft auch die Ergonomie der Anwendung verbessern. Die durch
das Netzwerk verursachten Latenzzeiten fallen weg, und die Anwendung
fühlt sich flüssiger an. Ihre Anwender werden es Ihnen danken. Besonders
dann, wenn sie ein Mobilfunknetz verwenden.
Abbildung 2 zeigt die wichtigsten Vor- und Nachteile der verschiedenen
Anwendungstypen auf einen Blick. „Rich Clients“ sind DesktopAnwendungen, die z. B. mit JavaFX, Swing oder auch .NET geschrieben
werden. „Thin Clients“ sind klassische HTML-Anwendungen, die dem
Request-Response-Schema folgen und kein AJAX verwenden. Anwendungen, die stark auf AJAX setzen, sowie reine JavaScript-Anwendungen, wie
man sie z. B. mit AngularJS schreibt, werden meistens als Der Gegenpool zu einer Client-seitigen Implementierung der BusinessLogik ist das traditionelle Request-Response-Schema, bei dem für jede
„Rich Internet Application“ (RIA) bezeichnet.
Benutzerinteraktion der komplette Bildschirm neu gezeichnet wird. Das ist
Bei der Entwicklung von Apps, die auf mobilen Endgeräten ausgeführt die einfachste Implementierungsoption bei Web-Anwendungen. Sie gewerden sollen, müssen weitere Aspekte berücksichtigt werden. Sie haben nügt heutigen Ansprüchen aber nicht mehr.
die Wahl, Ihre Anwendung als native Anwendung zu schreiben, oder eine
Web-Anwendung zu erstellen. Native Anwendungen können die System- Ein häufiger Kompromiss ist AJAX: Die Logik liegt vollständig auf dem
ressourcen wie z. B. GPS nutzen und fügen sich besser in das Bedienkon- Server, aber die Benutzeroberfläche ist so optimiert, dass sie nicht bei jeder
zept des jeweiligen Betriebssystems ein. Mit dieser Entscheidung legen Sie Benutzeraktion komplett neu aufgebaut werden muss. Wenn Sie ein
schnelles Netzwerk mit einer geringen Latenz haben, kann sich eine AJAXsich allerdings auch auf das Betriebssystem fest.
Anwendung fast genauso flüssig anfühlen wie eine echte DesktopAlternativ können Sie die Apps auch für mehrere Betriebssysteme entwi- Applikation.
ckeln. Das bedeutet jedoch einen höheren Entwicklungs- und Testaufwand.
Wenn Ihre Anwendung sowohl unter Android, iOS und Windows laufen Wenn Sie AJAX verwenden, sollten Sie die Komplexität Ihres Programmsoll und keine Systemressourcen benötigt, sollten Sie sich für eine codes im Auge behalten. Ein AJAX-Client bietet mehr technische MöglichBrowser-basierte Lösung entscheiden. In diesem Fall sind Sie jedoch auf keiten, erfordert aber auch mehr Know-how als eine einfache RequestResponse-Anwendung. Beide sind potentielle Treiber für Komplexität.
einen zentralen Server angewiesen.
© OPITZ CONSULTING Deutschland GmbH 2015
Whitepaper: Benutzeroberflächen modernisieren
Seite 6
Hier ein paar Fragen, die bei der Auswahl eine Rolle spielen:
■ Enthält Ihr Programm-Code Geschäftsgeheimnisse, die Sie schützen
wollen?
■ Muss die Anwendung auch offline laufen können? In diesem Fall kommen Sie um eine JavaScript-Implementation kaum herum.
■ Wie komplex sind die Benutzerinteraktionen in Ihrer Anwendung? Mit
JavaScript können Sie viel leichter auf Benutzeraktionen reagieren als
mit AJAX. Mit einer klassischen Request-Response-Anwendung gibt es
nur einen Aktionstyp, auf den Sie reagieren müssen: Klicks auf Menüs
und Buttons. Das ist nicht immer ein Nachteil. Das reduzierte EventHandling verringert schließlich die Komplexität der Programmlogik.
■ Wie groß sind die Netzwerklatenzen?
Traditionelle Anwendung oder Single Page Application?
Die ersten Web-Anwendungen waren Multi-Page-Anwendungen. Diese
bestehen aus einer Vielzahl einzelner Dialoge, die jeweils in einer eigenen
HTML-Datei abgelegt sind. Um von einem Dialog zum nächsten zu gelangen, wechselt die Anwendung zu einer anderen Seite – surft also quasi zu
einer anderen URL.
Abbildung 4: Single Page Application
Trotzdem besteht bei SPAs die Gefahr, dass die Komplexität höher ist als
beim traditionellen Ansatz. Laut einer Umfrage auf Reddit bleibt die Komplexität allerdings auch bei großen Anwendungen mit mehreren hundert
Masken beherrschbar, vorausgesetzt, Sie achten beim Architektur- und
Programmentwurf auf die Modularisierung.
Bei der Implementierung von SPAs gibt es einige Dinge zu beachten. Hier
nur eine kurze, unvollständige Checkliste:
■ Bookmarking: Ist es Ihnen wichtig, dass sich die URL beim Seitenwechsel verändert? Wollen Sie die URL speichern oder so verschicken können, dass der Empfänger nicht nur die gleiche Seite, sondern auch die
gleichen Daten sieht?
■ Suchergebnisse: Suchmaschinen können in aller Regel mit Single-PageAnwendung nichts anfangen. Wenn Sie möchten, dass Ihre Anwendung
in den Ergebnislisten der Suchmaschinen erscheint, müssen Sie etwas
dafür tun.
■ Komplexität/Modularisierung: Multi-Page-Anwendungen geben durch
die Aufteilung in verschiedene HTML-Seiten automatisch eine gewisse
Abbildung 3: Multi Page Application
Modularisierung vor. Bei Singe-Page-Anwendungen müssen Sie als
Architekt aktiv auf die Modularisierung achten.
Die häufigen Seitenwechsel bei Multi-Page-Anwendungen führen oft zu ■ History: Die „Zurück“-Schaltfläche des Browsers ist sowohl bei MultiPage-Anwendungen als auch bei Single-Page-Anwendungen eine Hereiner kleinen Pause, die den Arbeitsfluss hemmt. Eine Lösung dafür wäre,
immer auf derselben Seite zu bleiben und nur Teile der Seite ein- und ausausforderung.
zublenden. Facebook und GMail machen vor, wie das geht: Bei ihnen handelt es sich um große „Single Page Applications“ (SPA). SPAs zeichnen sich Alle diese Punkte sind lösbar, vorausgesetzt, Sie berücksichtigen sie bereits
dadurch aus, dass sie nach dem initialem Laden keine neuen HTML-Seiten beim Entwurf Ihrer Architektur.
laden, sondern immer nur Bestandteile der Seite austauschen. Lästige
Ladezeiten entfallen, die Anwendung fühlt sich deutlich „flüssiger“ an. Microservices oder SOA?
Frameworks wie AngularJS, die einige Sekunden für die Initialisierung der Es gibt verschiedene Ansätze, ein Programm in unabhängige Module aufzuteilen. Die meisten Softwareentwickler haben die horizontale Schichersten Seite brauchen, sind auf SPAs angewiesen.
tentrennung verinnerlicht. Die bekanntesten Architekturmuster sind hier
Das bedeutet aber nicht zwangsläufig, dass die Anwendung eine einzige, MVC, MVVM und – bei Desktop-Anwendungen – MVP. Ab einer gewissen
riesige HTML-Datei sein muss. Bei AngularJS werden beispielsweise HTML- Anwendungsgröße ist zusätzlich eine vertikale Aufteilung sinnvoll. Bei
Fragmente dynamisch nachgeladen. Dadurch können Sie Ihre Anwen- diesem Ansatz werden fachlich zusammengehörende Programmteile in
dungslogik auf viele, kleinere HTML-Seiten verteilen, was der Wartbarkeit einem Modul zusammengefasst.
zugutekommt.
© OPITZ CONSULTING Deutschland GmbH 2015
Whitepaper: Benutzeroberflächen modernisieren
Seite 7
Ein etablierter Ansatz sind serviceorientierte Architekturen (SOA), bei de- Und nicht zuletzt sollten Sie Ihre Firmenstrategie in die Entscheidung für
nen man sich auf die Modularisierung der Server-seitigen Programmteile eine Oberflächenmodernisierung einbeziehen. In welche Richtung soll sich
konzentriert. Wenn Ihre SOA-Services gut geschnitten sind, reduzieren Sie Ihr Unternehmen entwickeln:
die Komplexität Ihrer Oberflächenkomponenten erheblich. Es lohnt sich, ■ Sollen Mitarbeiter ihre Arbeit nur an dedizierten Arbeitsplätzen verrichten?
darauf zu achten! Aus eigener leidvoller Erfahrung können wir Ihnen versichern, dass Designfehler auf der Ebene der SOA-Services sehr teuer wer- ■ Können Mitarbeiter auch von zu Hause aus arbeiten?
den. Die Kosten, die Sie bei der Erstellung der Services sparen, bezahlen Sie ■ Sollen Mitarbeiter für die tägliche Arbeit ihre eigenen mobilen
Endgeräte einsetzen?
bei der Erstellung der Benutzeroberfläche.
Als Konsequenz dieser Erfahrung wurden in letzter Zeit Microservices populär. Ein Microservice umfasst sowohl die Benutzeroberfläche als auch
den Server-Anteil eines fachlich definierten Moduls (siehe http://
martinfowler.com oder unser Whitepaper zum Thema Microservices).
Auf den folgenden Seiten geben wir Ihnen einen Überblick über einige
wichtige UI-Frameworks.
Typischerweise umfasst dieses Modul eine oder einige wenige Masken und
bietet klar definierte Schnittstellen nach außen. Die Anwendung besteht
aus einer Sammlung von Microservices. Jeder Microservice wird getrennt
entwickelt, gewartet und installiert. Bei einem Update brauchen Sie nicht
mehr das ganze Programm zu aktualisieren, sondern nur den Programmteil, der verändert wurde. Wenn Microservices miteinander kommunizieren
müssen, machen sie das über Web-Schnittstellen wie Web-Services, RESTServices oder HTTP-Requests und rufen so die Maske eines anderen Microservices auf.
UI-Frameworks
Allerdings erinnern Microservices stark an die Idee der Portlets, die
von der Java-Community nach anfänglichem Interesse als Architektur für
Web-Anwendungen verworfen wurden. Zu Microservice-Architekturen
erheben sich jetzt ähnlich kritische Stimmen: Sie seien zu kompliziert, zu
netzwerklastig, zu langsam (siehe http://www.stavros.io/posts/ Abbildung 5: UI-Frameworks
microservices-cargo-cult/).
Wir halten Microservices für eine faszinierende Idee, empfehlen jedoch, im
Vorfeld alle Aspekte zu berücksichtigen, damit Sie wirklich wissen, auf was
Sie sich einlassen. Die Architektur ist für eine bestimmte Klasse von Anwendungen optimiert. Prüfen Sie also, ob Ihre Anwendung dazugehört!
Firmenkultur berücksichtigen
JavaFX
JavaFX hat eine wechselvolle Geschichte hinter sich. Die erste Version von
war eine statische, typisierte und deklarative Sprache, die JavaFX Script
genannt wurde. Diese erste Version brachte eine Reihe von neuen Konzepten, die in der Java-Community nicht gut ankamen. Dadurch kam JavaFX
in Verruf. Das wirkt bis heute nach – zu Unrecht, wie wir glauben. Mit
JavaFX 2 und den späteren Versionen wurden viele Kritikpunkte aufgenommen und beseitigt.
Bei der Modernisierung von Benutzeroberflächen sollten Sie auch Ihre
Firmenkultur berücksichtigen. Welche Vorkenntnisse und Vorlieben haben
Ihre Entwickler? Besteht Ihre Entwicklungsmannschaft eher aus Frontendund Web-Entwicklern, oder aus Mitarbeitern, die sich auf dem Server zuhause fühlen? Welche Programmiersprachen sind ihnen geläufig, und bei
welchem Abstraktionsgrad fühlen sich Ihre Entwickler wohl?
Mit der Neuentwicklung wurde JavaFX 2 zur Programmierschnittstelle
(API) umgeschrieben. Seitdem kann auf alle Java API zugegriffen werden.
Mit JavaFX 8 ist das Programm vollständig in das Java SE Runtime Environment und das Java Development Kit (JDK) integriert. Da das JDK für
alle wichtigen Plattformen (Windows, Mac OS X und Linux) existiert, kann
JavaFX als Technologie für diese Plattformen verwendet werden.
Spätestens seit JavaFX 8 ist JavaFX eine ernstzunehmende Alternative zu
Ebenso gilt es, die Firmenkultur auf der Anwenderseite zu berücksichtigen. anderen Desktop-GUI-Frameworks.
Wie sehen die spezifischen Anforderungen Ihrer Anwender aus? Bevorzugen Ihre Anwender eher kompakte „Expertenanwendungen“, oder nehmen
sie lieber ein paar Klicks mehr in Kauf, um eine intuitiv bedienbare Anwendung zu bekommen?
© OPITZ CONSULTING Deutschland GmbH 2015
Whitepaper: Benutzeroberflächen modernisieren
Seite 8
JavaFX bringt einige Neuerungen mit sich, die die Entwicklung von Desktop-Anwendungen wesentlich vereinfachen:
■ FXML: Mit FXML bietet JavaFX die Möglichkeit, grafische Komponenten
schnell deklarativ und unabhängig von der Programmlogik zu definieren. Bei FXML handelt es sich um eine XML-basierte Definition zur Implementierung von deklarativen JavaFX-Oberflächen.
■ Scene Buider: Es gibt eine Reihe von Open-Source-Produkten, mit denen die grafischen Komponenten mittels Drag & Drop zusammengestellt werden können. Der bekannteste JavaFX-Editor ist der Scene
Builder von Gluon.
■ CSS: Mit der Möglichkeit zur Einbindung von Cascading Style Sheets
bietet die JavaFX-Bibliothek ein weiteres sehr nützliches Feature. Das
Aussehen der JavaFX-Anwendung kann damit flexibel und dynamisch
verändert werden. Das Design kann entweder direkt im Code oder vollkommen unabhängig von der Logik in einer eigenen CSS-Datei gekapselt werden.
■ Properties und Bindings: Moderne Benutzeranforderungen gehen dahin, Daten unmittelbar bei der Eingabe zu validieren und Änderungen
sofort zu registrieren. In JavaFX wurden dafür das Konzept der Properties und Bindings entwickelt und mit einigen nützlichen Features
ausgestattet.
Mit der Auswahl von JavaFX als strategischer Technologie müssen bestehende Swing-Anwendungen nicht sofort nach JavaFX migriert werden. Für
die Migration stehen folgende Möglichkeiten zur Verfügung:
■ Integration von JavaFX in Swing: Mit dieser Option können Sie neue
Komponenten in JavaFX entwickeln und in Ihre bestehende DesktopAnwendung integrieren. Dieser Weg erlaubt eine schrittweise Modernisierung von Benutzeroberflächen von innen heraus.
■ Integration von Swing in JavaFX: Mit dieser Option können Sie bestehende Swing-Komponenten in JavaFX verwenden. Diese Migrationsstrategie versetzt Sie in die Lage, bestehende und komplexe JavaSwingKomponenten in einer neuen überarbeiteten Benutzeroberfläche zu
verwenden.
■
■
■
Das Model ist für die Kommunikation mit der Datenbank zuständig.
Die View-Komponente besteht aus XML-Dateien, die die Benutzeroberfläche deklarativ beschreiben. Diese XHTML-Dateien ähneln klassischen
HTML-Dateien und enthalten keine Programmlogik.
Der Controller ist zwischen Model und View angesiedelt und implementiert die Programmlogik.
Bei genauerem Hinsehen fällt bei JSF auf, dass es dem MVVM-Paradigma
ähnelt. Insbesondere bietet es ein „Two-Way-Binding“ zwischen der View
und dem Controller. Mit anderen Worten: Benutzereingaben werden vom
JSF-Framework automatisch in die JSF-Beans übertragen, und umgekehrt
werden Änderungen der JSF-Bean beim nächsten Neuzeichnen der Maske
automatisch aus der JSF-Bean ausgelesen und angezeigt. Wir haben das
klassische MVC-Diagramm in unserer Architekturskizze daher entsprechend erweitert:
Abbildung 6: Erweiterung des klassischen MVC-Paradigmas
JSF 2.0 und 2.1 sind komponentenbasierte Frameworks. Es gibt eine Reihe
umfangreicher Komponentenbibliotheken, die es Ihnen erlauben, schnell
komplexe Anwendungen zu schreiben.
Die meisten Komponentenbibliotheken sind nicht miteinander kompatibel,
JSF
so dass die Auswahl des richtigen Verzeichnisses wichtig ist – zumal es
JavaServerFaces ist Bestandteil des JavaEE-Standards und damit eines von auch einige Bibliotheken gibt, deren Zukunft unsicher ist:
zwei GUI-Web-Frameworks, die Oracle offiziell unterstützt. JSF hat eine ■ PrimeFaces ist der Platzhirsch unter den JSF-Frameworks. Es bietet
mehr als 100 Komponenten und deckt auch Themen wie Barrierefreiähnliche Geschichte wie JavaFX: Die erste Version hatte gravierende Mänheit und Tastaturbedienung ab, die bei Web-Anwendungen eher selten
gel, die den Ruf und die Akzeptanz von JSF zunächst ruinierten.
unterstützt werden. PrimeFaces unterstützt das Responsive Design und
hat auch eine spezielle Version für Mobile Devices.
JSF 2.0 war dann in wesentlichen Teilen ein Neuanfang mit einer deutlich
verbesserten Architektur. Seitdem ist JSF ein ernstzunehmendes und weit ■ ICEFaces und RichFaces waren früher sehr populäre JSF-Frameworks.
Genaue Zahlen über die Marktanteile sind schwer zu finden, aber laut
verbreitetes GUI-Framework, mit allen Vorteilen, die das mit sich bringt: Es
Google Trends und einer OIO-Umfrage aus dem Jahr 2011 spielen diese
ist leicht, Informationen darüber im Internet zu bekommen, und die Rekrubeiden Frameworks nur noch eine untergeordnete Rolle. (Vgl. http://
tierung neuer Mitarbeiter ist auch kein Problem.
www.oio.de/public/java/java-web-frameworks-vergleich/OIO-KompassWebframeworks-Studie.pdf)
Meistens wird JSF als MVC-Framework bezeichnet. In diesem Modell teilen
Sie Ihre Anwendung in drei Teile auf:
© OPITZ CONSULTING Deutschland GmbH 2015
Whitepaper: Benutzeroberflächen modernisieren
Seite 9
■
■
BootsFaces ist ein relativ junges JSF-Framework, das einen Schwerpunkt auf Responsive Design legt. Der Marktanteil ist noch sehr gering,
es kommt daher in erster Linie für innovative Projekte in Frage, die
keinen kommerziellen Support brauchen.
OmniFaces ist kein Komponentenframework, jedenfalls nicht in erster
Linie, sondern eine Sammlung von Funktionalitäten, die im
JSF-Standard fehlen und es lässt sich problemlos mit anderen JSFFrameworks kombinieren.
AngularJS 2.0 bringt neue Konzepte und Verbesserungen, ist aber zu den
Vorgängerversionen inkompatibel. Falls Sie bei einer Modernisierung auf
AngularJS setzen, sollten Sie also möglichst mit AngularJS 2.0 beginnen.
Wenn Ihre Entwicklungsmannschaft aus Java-Entwicklern besteht, hat das
noch einen Vorteil: AngularJS 2.0 kann (und soll) mit der Programmiersprache TypeScript programmiert werden und senkt damit die Einstiegshürde für Entwickler, die an eine objektorientierte Sprache gewöhnt sind.
Alle Komponentenframeworks haben ein Problem: Sie sind nur so lange
gut, wie sie Ihre Anforderungen abdecken. Wenn Ihre Anforderungen über
die Möglichkeiten der Komponente hinausgehen, kommen Sie schnell an
den Punkt, an dem Sie gegen die Grenzen der Komponente
„anprogrammieren“. Deshalb gibt es seit JSF 2.2 Unterstützung für HTML5.
Sie können im Prinzip also auch ganz ohne Komponentenframework auskommen oder alternativ Client-seitige Komponenten verwenden.
Bei JSF gibt es eine wichtige Einschränkung: Es ist nur teilweise mit Spring
kompatibel. Beispielsweise funktioniert der ViewScope nicht mit SpringBeans. Oracle unterstützt Spring offiziell nicht. Stattdessen verbindet es
JSF immer stärker mit dem JavaEE-Standard CDI. Es ist daher denkbar, dass
künftige Versionen von JSF mit Spring inkompatibel werden. Solange Sie
Spring ausschließlich im Back-End einsetzen, ist das kein Problem. Mit CDI
können Sie Dependency Injection allerdings auch im Front-End einsetzen.
Abbildung 7: Arbeit mit benutzerdefinierten Komponenten
Android und iOS
Mit den nativen Entwicklungsumgebungen für Android und iOS können
Sie Ihre Anwendung für das Betriebssystem Ihrer Anwender optimieren.
Den verbesserten Komfort, und damit die verbesserte Produktivität Ihrer
Anwender, erkaufen Sie sich allerdings für einen hohen Preis: Die Anwendung läuft ausschließlich unter Android bzw. iOS. Bei iOS kommt noch
AngularJS
dazu, dass Sie es nur in ObjectiveC programmieren können. Sie müssen
AngularJS ist ein JavaScript-Framework, das vor allem für Enterprise- also in Ihrem Team das notwendige Know-how aufbauen – was in den
Entwickler attraktiv ist. Es bietet alle Features, auf die Architekten in grö- meisten Fällen bedeutet, dass Ihr Team eine weitere Programmiersprache
ßeren Firmen Wert legen:
lernen muss. Daher verwenden die meisten Anwendungen für mobile Ge■ Dependency Injection
räte heutzutage HTML5. CSS-Frameworks wie Bootstrap helfen Ihnen, die
■ Data Binding
Anwendung gleichzeitig für den Desktop und für den kleinen Bildschirm
■ MVVM-Pattern (eine Variante des bekannteren MVC-Patterns)
des Tablets oder Smartphones zu optimieren (Responsive Design).
■ Modularisierung und einen starken Fokus auf Testbarkeit
Andere GUI-Frameworks
AngularJS entkoppelt die Anwendung von der technischen Basis. Für grö- Es gibt noch weitere interessante GUI-Frameworks, die wir an dieser Stelle
ßere Projekte ist das ein Vorteil, weil Sie sich auf die Entwicklung der fach- nur kurz erwähnen:
lichen Anforderungen konzentrieren können. Interessanterweise fühlen ■ Ozark oder Spring MVC: Ozark ist das neue GUI-Web-Framework, das
von Oracle zurzeit entwickelt und vielleicht mit Java 9 veröffentlicht
sich viele erfahrene JavaScript-Entwickler von der für Sie ungewohnten
wird. Ozark und Spring MVC sind „Action-orientierte“ Frameworks (im
Abstraktion abgeschreckt. Bei der Evaluierung und Einführung von
Unterschied zu komponentenorientierten Frameworks wie JSF). Dieser
Des Frameworks sollten Sie insofern darauf achten, dass es in Ihre UnterFrameworktyp gibt Ihnen größere Kontrolle über Ihre Anwendung,
nehmensstrategie passt.
allerdings möglicherweise auf Kosten der Entwicklerproduktivität.
AngularJS wurde ursprünglich für das „Model-View-Model“-Paradigma ■ Grails: Grails ist ein GUI-Framework für Web-Anwendungen, die mit
entwickelt. Das Architekturbild ähnelt der Architektur von JSF. Der HauptGroovy geschrieben werden. Grails ist besonders für „Rapid Prototyunterschied ist, dass AngularJS mit benutzerdefinierte Komponenten arping“ interessant: Sie können mit wenigen Zeilen Code eine einfache
beitet. Meistens werden auch noch die CSS-Bibliotheken Bootstrap oder
Anwendung schreiben. Gleichzeitig ist Grails so flexibel, dass Sie auch
Material Design verwendet, um das Web-Design zu vereinfachen.
größere Anwendungen programmieren können.
■ Captain Casa: Captain Casa ist ein interessanter Ableger von JSF. Es
verwendet JSF als Framework und für die Definition der Dialoge. Anders
als JSF generiert es aber kein HMTL, sondern einen Swing- oder JavaFXClient.
© OPITZ CONSULTING Deutschland GmbH 2015
Whitepaper: Benutzeroberflächen modernisieren
Seite 10
■
GWT und Vaadin: GWT ist ein HTML-Framework, bei dem die BusinessLogik in Java formuliert wird. Beim Kompilieren wird ein großer Teil der
Logik in JavaScript übersetzt. Die Anwendung läuft also komplett oder
zu großen Teilen im Browser. Vaadin baut auf GWT auf, verlagert aber
einen wesentlich größeren Teil der Anwendungslogik auf den Server.
Im JavaScript-Bereich entwickelt sich der GUI-Framework-Markt so
schnell, dass es kaum möglich ist, eine klare Empfehlung für oder gegen
ein JavaScript-Framework abzugeben.
Mit einer Multi-Channel-Strategie können Sie die Anwendung für verschiedene Zielgruppen optimieren. So können Funktionen der Anwendung
mit kritischen und sensiblen Daten in einer Desktop-Anwendung verarbeitet werden; andere Funktionen werden hingegen als Web-Client oder native App für ein mobiles Endgerät bereitgestellt. Die Schichtentrennung
zwischen den drei Clients und dem Application Layer bietet Ihnen Wiederverwendungsmöglichkeiten.
Migrationsstrategien
Scott Hanselmann führte 2012 eine Liste von 22 bekannten JavaScriptFrameworks
auf
(siehe
http://www.hanselman.com/blog/
TheBigGlossaryOfOpenSourceJavaScriptAndWebFrameworksWithCoolNames.aspx). Neben AngularJS seien an dieser Stelle meteor.js, Ember.js,
Underscore.js, Backbone.js, Knockout.js und KendoUI erwähnt. Einen ausführlichen Vergleich verschiedener Java- und JavaScript-Frameworks finden Sie auch unter http://www.beyondjava.net/blog/hottest-guiframework-java-world-jsf-javafx/.
In den vorherigen Abschnitten haben wir gezeigt, welche Optionen Ihnen
bei den verschiedenen Architekturen und Technologien zur Verfügung
stehen. Je nachdem, wie Sie sich entscheiden, können Sie eine bestehende
Anwendung schrittweise modernisieren, oder die Anwendung vollständig
neu entwickeln. Unabhängig von der gewählten Technologie benötigen Sie
eine Strategie, wie Sie die Migration ihrer bestehenden Benutzeroberfläche
durchführen. Die Migrationsstrategien „Evolution“ und „Revolution“ weisen
erhebliche Unterschiede auf, die Sie von Anfang an berücksichtigen müsMulti-Channel-Strategie
sen. Eine dritte Strategiemöglichkeit wäre, „nichts zu tun“ und Ihre aktuelBisher haben wir die verschiedenen Technologien und Zielplattformen len Oberflächen so zu lassen, wie sie sind. Anders als der Name suggeriert,
isoliert betrachtet. Sie können sie aber auch kombinieren. Beispielsweise sollten Sie auch diese Strategie gut planen, um für die Zukunft gerüstet zu
können Sie für Ihre Mitarbeiter im Büro einen Desktop-Client bereitstellen, sein.
für Ihre Außendienstler einen Web-Client und für Ihre Kunden eine speziell
Revolution
angepasste Smartphone-App.
Bei der Migrationsstrategie „Revolution“ wird eine bestehende Anwendung
vollständig durch eine Neuentwicklung abgelöst. Diese Strategie bietet
eine Reihe von neuen Spielräumen und Chancen:
■ Erleichterung der Bedienbarkeit
Wie gesagt, wurde früher in vielen Anwendungen versucht, alles auf
einen Blick zu zeigen. Diese Anwendungen sind somit sehr komplex und
entsprechen den heutigen Anforderungen nicht mehr. Ein Neubeginn
auf der „grünen Wiese“ bietet also die Möglichkeit, die Applikationen zu
entschlacken, zu vereinfachen und auf einer komplett neuen Architektur aufzusetzen.
■ Eliminierung von „technischen Schulden“
Während des Lifecycles einer Anwendung verändern sich die Anforderungen, und die bestehende Architektur muss gegebenenfalls erweitert
werden. Bei der Integration von neuen Architekturkomponenten in eine
bestehende Anwendung entstehen „technische Schulden“, die man bei
einem „revolutionären“ Vorgehen hinter sich lässt.
■ Eliminierung von Erosion und Verwässerung
Abbildung 8: Multi-Channel-Strategie
Weitere Effekte, die sich in bestehenden Altanwendungen beobachten
lassen und die wir mit einer Neuentwicklung ausschließen können, sind
die Erosion und die Verwässerung der Software-Architektur, weil die
Ziel dieser Architektur ist es, die zentrale Anwendungslogik in den ApplicaKluft zwischen der geplanten und der implementierten Architektur
tion Layer auf dem Server zu implementieren und sie allen Benutzeroberimmer größer wird. Die Konsequenz kann z. B. eine Verschlechterung
flächen in Form von Services zugänglich zu machen. Erfolgt die Implemender Performance sein, oder dass Änderungen schwieriger eingepflegt
tierung des Application Layer als REST-Service, so können die zentralen
werden können. Auch die Fehlerquote steigt bei gewachsenen ApplikaServices unabhängig von der verwendeten Client-Technologie konsumiert
tionslandschaften, da die IT Änderungen oft nicht mehr zentral durchwerden.
führen kann. Mit einer Neuentwicklung entgehen Sie diesem Problem.
© OPITZ CONSULTING Deutschland GmbH 2015
Whitepaper: Benutzeroberflächen modernisieren
Seite 11
Eine konsequente Neuentwicklung bietet Ihnen die Freiheit, über die Architektur Ihrer Anwendung noch einmal ganz neu nachzudenken. Insbesondere die folgenden Fragen sollten Sie beantworten, bevor Sie eine
Entscheidung treffen:
■ Wie gut hat sich die Architektur der bestehenden Anwendung bewährt?
■ Welche Clients sollen den Mitarbeiter für die Erfüllung der täglichen
Arbeit angeboten werden?
Da die Modernisierung der Benutzeroberfläche nicht ausschließlich am
Client umgesetzt werden kann, sondern in vielen Fällen in die ServerArchitektur eingegriffen werden muss, sollten Sie sich ebenfalls Gedanken
über die folgenden Fragen machen:
■ Ist es Zeit, auf eine Internet-Technologie oder auf Microservices umzusteigen?
■ Wollen Sie die Hardware weiter selbst betreiben, oder macht es Sinn,
die Laufzeitumgebung in die Cloud zu verlagern?
Wenn Sie den Weg der „Revolution“ beschreiten, reicht es normalerweise
nicht, nur die Benutzeroberfläche neu zu erstellen. Sie müssen auch die
zugrundeliegende Server-Architektur erneuern – insbesondere wenn Sie
auf eine neue Client-Technologie umsteigen. Selbst wenn Sie bestehende
Komponenten weiterverwenden können: schauen Sie sich die Komponenten genau an. Denn beim Vorgehen „Revolution“ haben Sie ja wie gesagt
die Chance, die Software-Erosion rückgängig zu machen und „technische
Schulden“ zu tilgen.
Eine Herausforderung für jede Migrationsstrategie ist der Parallelbetrieb
der bestehenden und der neuen Oberfläche. Oft genug reicht es nicht, in
der bestehenden Anwendung die neuen Funktionalitäten zu deaktivieren.
Falls die neuen Anforderungen auch Änderungen am Datenmodell mit sich
bringen, müssen Sie auch die Daten der bestehenden Anwendung in die
neue Datenbank migrieren. In der Regel bedeutet dies, dass Sie die alte
Anwendung nicht mehr reaktivieren können, falls die neue Anwendung
nicht auf Anhieb läuft.
Evolution
Mit dem Ansatz der Evolution werden die grundlegenden Konzepte beibehalten. Der Fokus liegt hier ausschließlich auf die Modernisierung der
grafischen Benutzeroberfläche. Zugrundeliegende Architektur und Infrastruktur bleiben unverändert und werden nur soweit angepasst, wie es für
die neue Technologie notwendig ist.
Im Rahmen der Evolution werden schrittweise bestehende Masken oder
bestehende Komponenten durch eine neue Implementierung abgelöst. Die
Entwicklung einer Migrationsstrategie für eine Evolution ist weitaus einfacher als bei einer „Revolution“. Bei dieser Strategie können Sie die geänderten oder neuen Eingabemasken wesentlich leichter in die neue Architektur integrieren. Allerdings braucht die schrittweisen Migration ein tiefes
Verständnis der Geschäftslogik.
Nichts tun
Auch das ist eine valide Option. Sie können sich entscheiden, auf die MoUm eine bestehende Software abzulösen, bedarf es natürlich einer Reihe dernisierung einer bestehenden Anwendung zu verzichten. Hinter dieser
von Vorarbeiten.
Option sollte jedoch eine klare Strategie stehen, die besagt, wie die beste■ Analyse der Eingabemasken: Eine der wichtigsten Aufgaben im Vorfeld hende Anwendung gewartet werden kann. Bestehende Technologie und
ist die Analyse der Eingabemasken und ihrer Funktionsweisen.
Architektur würden dann auf einem fest definierten Stand eingefroren.
■ Dokumentation: In vielen Fällen fehlt eine umfangreiche Dokumentation, so dass diese im Rahmen eines Reverse Engineerings extrahiert
Vor dem Austausch bestehender Komponenten ist eine genaue Analyse
werden muss.
über ihre Auswirkungen auf andere Bestandteile erforderlich. Da sich je■ Bewertung der analysierten Eingabemasken hinsichtlich ihres Nutzens doch die Geschäftsanforderungen ständig ändern, müssen diese Anfordeund ihrer konzeptioneller Wiederverwendbarkeit: Nach diesem Schritt
rungen sehr wohl in der bestehenden Anwendung integriert werden. Belässt sich sehr schnell erkennen, an welchen Stellen das System erwei- achten Sie, dass Sie das notwendige Know-how für die Pflege und Weitertert oder umgebaut werden muss.
entwicklung der Anwendung bereitstellen müssen. Damit binden Sie even■ Eingabemasken kategorisieren: Zusätzlich sollten Sie die Eingabemas- tuell Mitarbeiter, die Ihnen in anderen Projekten fehlen.
ken nach Kriterien wie diesen kategorisieren:
■ Anzahl der Benutzer,
Betrachten wir die verschiedenen Architektur- und Handlungsoptionen für
■ Wichtigkeit der Eingabemaske im Kontext der Anwendung
die Modernisierung von Benutzeroberflächen, so stellen wir fest, dass uns
■ oder Komplexität.
eine Reihe von Varianten zur Verfügung steht.
Im Rahmen der Analyse der aktuellen Benutzeroberfläche sollten Sie unbedingt die anstehenden Erweiterungen für das bestehende System mit betrachten. Je nach Priorität kann es erforderlich sein, dass Erweiterungen
noch in den bestehenden Eingabemasken vorgenommen werden und bei
der Neuentwicklung erneut zu berücksichtigen sind.
© OPITZ CONSULTING Deutschland GmbH 2015
Whitepaper: Benutzeroberflächen modernisieren
Seite 12
Die nachfolgende Tabelle gibt Ihnen einen Anhaltspunkt für die Wege, die
Sie verfolgen können:
Single Page Multi Page
Mobile
Java Swing Evolution
Revolution
Revolution
Revolution
Single Page Revolution
Kein
Handlungsbedarf
Evolution
Evolution
bzw. kein
Handlungsbedarf
Multi Page
Evolution
Kein
Handlungsbedarf
Evolution
bzw. kein
Handlungsbedarf
ALT
NEU
JavaFX
Revolution
Agilität im Modernisierungsprojekt
Scrum
Agile Methoden erfreuen sich in der Softwareentwicklung einer großen
Beliebtheit. Unabhängig davon, ob Sie sich für eine „Evolution“ oder eine
„Revolution“ entscheiden, unterstützen agile Methoden Sie bei der Modernisierung von Benutzeroberflächen. Durch den Einsatz von Scrum reicht
ein Minimum an Planung aus, um schnell, überlegt und koordiniert in die
Umsetzung zu kommen. Damit dies jedoch funktioniert, muss das Product
Owner Team eine entsprechende Vorarbeit leisten. Die Aufgabe dieses
Team besteht darin, das Migrationsprojekt entsprechend vorzubereiten und
die spätere Umsetzung zu begleiten.
In einer ersten Phase müssen vor allem Fragen geklärt werden wie:
„Welche Eingabemasken müssen am dringendsten überarbeitet werden“
und „Welche Kernfunktionen werden weiterhin benötigt“. Die Klärung
dieser Fragen entspricht der Anforderungsanalyse eines klassischen Projekts. Auch in einem agilen Projekt sollte hierfür entsprechend Zeit eingeplant werden. Jedoch wird im ersten Schritt nur der rote Faden aufgenommen und alle Randaspekte auf einen späteren Zeitpunkt verschoben. Aufgabe des Produkt Owner Teams ist es, die anstehenden Aufgaben zu priorisieren und in kleine Arbeitspakete zu zerlegen, die das Scrum Team anschließend innerhalb eines Sprints bearbeitet.
© OPITZ CONSULTING Deutschland GmbH 2015
Zusammenfassung
Benutzeroberflächen sind ein spannendes Thema. Es ist fast wie beim Fußball: Jeder ist hier Experte. Und jeder ist betroffen. Wir alle arbeiten mit
Programmen und leiden an weniger gelungenen Benutzeroberflächen.
Oder wir freuen uns, wenn eine Benutzeroberfläche gut gestaltet ist.
Wenn bei Ihnen eine Renovierung der Benutzeroberfläche ansteht, starten
Sie also am besten mit einer Umfrage bei Ihren Mitarbeitern und Anwendern. Was gefällt ihnen besonders gut? Wo liegen die Knackpunkte?
Die Modernisierung der Oberfläche bietet Ihnen die Chance, vieles besser
zu machen.
Mit diesem Feedback im Hinterkopf können Sie eine passende Architektur
auswählen. Wir hoffen, Ihnen einen kleinen Überblick über den unüberschaubaren „Dschungel“ von Technologie- und Architekturoptionen gegeben zu haben.
Wenn Sie noch Fragen oder Anmerkungen haben: Wir freuen uns über Ihr
Feedback! Und selbstverständlich hilft OPITZ CONSULTING Ihnen auch
gerne bei der Umsetzung Ihres GUI-Modernisierungsprojekts.
Bildnachweise
■
■
■
Der PC in den Abbildungen 4, 6 und 7 wurde von Max Lee unter einer
Creative Commons 2.0 license ((CC BY-SA 2.0) veröffentlicht (https://
www.flickr.com/photos/keetsa/524715635).
Das AngularJS-Logo in Abbildung 7 wurde unter einer Creative Commons Attribution-ShareAlike 3.0 Unported License veröffentlicht (siehe
https://docs.angularjs.org/misc/faq).
Die Graphiken zu MVC und MVVM wurde von Stephan Rauh auf seinem
Blog http://www.beyondjava.net unter einer Creative Commons Attribution-NonCommercial-NoDerive 3.0 Germany License veröffentlicht.
Whitepaper: Benutzeroberflächen modernisieren
Seite 13
Über OPITZ CONSULTING
■
Training und Coaching:
Das Oracle University Schulungszentrum von
OPITZ CONSULTING bietet ein umfangreiches
Schulungsprogramm in den Bereichen Oracle,
SOA, Java und Business Intelligence. Die
Trainings werden flexibel auf Kunden oder Projekte zugeschnitten und auf Wunsch auch inhouse durchgeführt. Die
Trainer kommen direkt aus der Praxis und verfügen neben fundiertem
theoretischem Wissen über langjährige Projekterfahrung.
■
Trends:
Gemeinsam mit dem Kunden konzipieren und
implementieren die IT-Experten innovative und
differenzierende Lösungen. Hierzu beschäftigen
sie sich permanent mit neuen Trends und evaluieren diese Hype-Themen hinsichtlich der möglichen Nutzung in den Kundenprojekten.
OPITZ CONSULTING trägt als führender Projektspezialist für ganzheitliche
IT-Lösungen zur Wertsteigerung von Unternehmen bei und bringt IT und
Business in Einklang. Mit OPITZ CONSULTING als zuverlässigem Partner
können sich die Kunden auf ihr Kerngeschäft konzentrieren und ihre
Wettbewerbsvorteile nachhaltig absichern und ausbauen.
OPITZ CONSULTING wurde 1990 gegründet und beschäftigt heute an elf
Standorten mehr als 400 Mitarbeiter. Zum Kundenkreis zählen
¾ der DAX30-Unternehmen sowie branchenübergreifend mehr als
600 bedeutende Mittelstandsunternehmen.
Portfolio
Das Portfolio von OPITZ CONSULTING umfasst die folgenden Leistungsschwerpunkte:
■
IT-Beratung:
Die IT-Experten unterstützen ihre Kunden dabei,
die organisatorischen Grundlagen für eine verbesserte Wertschöpfung durch die Informationstechnologie zu schaffen. Transparente und
effektive Strukturen im IT-Management sind hier
grundlegend. Mit positiven Konsequenzen für das gesamte Unternehmen: bessere Kontrolle über aktuelle IT-Kosten,
effektiverer Ressourceneinsatz, stabilere Planungsbasis für die Zukunft
und zufriedene Anwender.
■
Business-Lösungen:
In enger Zusammenarbeit mit seinen Kunden
entwickelt unser Projekthaus innovative, differenzierende und individuelle Business-Lösungen.
Hierbei unterstützen die Spezialisten den gesamten Plan-Build-Run-Zyklus. Auf Wunsch über-nehmen sie die Verantwortung für Wartung und Weiterentwicklung der Lösungen über den
gesamten Lebenszyklus, mittels Application
Lifecycle Management, kurz: OC|ALM®.
■
Managed Services:
Unsere Teams für Managed Services Application
(OC|MSA®) und Managed Services Infrastructure
(OC|MSI®) kümmern sich rund um die Uhr, remote oder vor Ort um die Applikationen und Systeme ihrer Kunden. Dabei übernehmen sie die Wartung, die Weiterentwicklung und die Modernisierung von Applikationen, sowie die Administration, die Wartung und den Betrieb von ITInfrastrukturen. Proaktiv weisen Sie die Kunden auf mögliche Risiken
und Engpässe hin.
© OPITZ CONSULTING Deutschland GmbH 2015
Weitere Infos zu unseren Leistungsfeldern finden
Sie auf unserer Homepage:
www.opitz-consulting.com/portfolio
Whitepaper: Benutzeroberflächen modernisieren
Seite 14
UI-Modernisierung
mit OPITZ CONSULTING
OPITZ CONSULTING unterstützt Sie bei der Software-Modernisierung mit
■ Planung und Entwicklung der passgenauen Strategie
■ Implementierung der notwendigen Benutzeroberflächen sowie Anpassungen der Ablauf- und Aufbauorganistation
■ Entwicklung und Einführung einer flexiblen und leistungsstarken
Lösung für die Modernisierung von Altsystemen
Unser Angebot auf einen Blick
Planung
Workshops und Assesments zur Entwicklung einer Roadmap
für die UI-Modernisierung
■
■
■
■
Vision, Ziele und Business Case
Strategie und notwendige Initiativen
Technologieauswahl
Umsetzungsstrategie und Roadmap
Implementierung
Implementierung von individuellen Lösungen
Unterstützung bei der Implementierung
■
■
Betrieb
Übernahme der Wartung und Weiterentwicklung
Reviews und Retrospektiven
■
■
Application Lifecycle Management
Mit OC|ALM® bieten wir Ihnen die Betreuung über den ganzen Lebenszyklus Ihrer Applikationen aus einer Hand.
Über die Autoren
Stefan Kühnlein
Stefan Kühnlein arbeitet als Solution Architekt bei der OPITZ CONSULTING
Deutschland GmbH am Standort München. Der Schwerpunkt seiner täglichen Arbeit liegt im Entwurf von SOA-basierten Architekturen sowie in der
Auswahl moderner Softwarearchitekturen und entsprechender technischer
Frameworks. Insbesondere berät er Kunden bei der Modernisierung von
Desktop-Anwendungen.
Stephan Rauh
Stephan Rauh arbeitet als Senior Consultant bei der OPITZ CONSULTING
Deutschland GmbH am Standort Bad Homburg und ist durch seinen Blog
www.BeyondJava.net bekannt geworden. Seit mehreren Jahren befasst er
sich mit JSF und AngularJS und engagiert sich in der Open-Source-Szene
als Autor von AngularFaces und Committer für BootsFaces.
© OPITZ CONSULTING Deutschland GmbH 2015
Whitepaper: Benutzeroberflächen modernisieren
Seite 15
Folgen Sie uns:
youtube.com/opitzconsulting
@OC_WIRE
slideshare.net/opitzconsulting
xing.com/net/opitzconsulting
Weitere Infos auf
www.opitz-consulting.com