Integrierbarkeit von Benutzerschnittstellen ist ein häufig unterschätztes Problem

Das Reich der 1000 Inseln
Kommentare

Die Integrierbarkeit von serverseitigen Unternehmensapplikationen ist Gegenstand zahlreicher Untersuchungen. Das Thema ist mehr als zwei Dekaden alt, und mittlerweile haben sich De-facto-Standards etabliert. Bei der Technologieauswahl für Benutzeroberflächen im Enterprise-Umfeld spielt Integrierbarkeit dagegen oft eine untergeordnete Rolle. Die nahtlose Verknüpfung mehrerer UIs wird zwar durchaus als wichtig erkannt, aber meist ohne Ausflug ins Detail abgehandelt.

So entsteht dann statt einer integrierten UI-Landschaft „das Reich der 1000 Inseln“ – lauter lose verkoppelte Einzellösungen, die keine zusammenhängende Benutzererfahrung zulassen. Innerhalb der einzelnen Inseln ist dann der gegenteilige Effekt zu beobachten: Die Applikation ist ein monolithischer Block, dessen Bestandteile nicht wiederverwendet werden können. Wie aber kann man der Zersplitterung seiner UI-Landschaft vorbeugen? Welche Technologien ermöglichen eine harmonisierte, nahtlose Benutzererfahrung? Sind die im Enterprise-Umfeld so beliebten Webportale schon der Königsweg, sodass wir die Suche einstellen können? Der vorliegende Artikel versucht diese Fragen zu klären.

Was heißt eigentlich Integration?

Für eine angemessene Bewertung des Themas ist zunächst ein kurzer Umweg nötig. Was bedeutet Integration eigentlich genau? Und wie wird sie im allgemeineren Umfeld von unternehmensweiten Applikationen umgesetzt? Dann wird deutlich werden, dass sich die gleichen Entwurfsmuster auch im UI-Bereich finden lassen. Im Enterprise-Umfeld sind Softwaresysteme zunächst einmal als abgegrenzte Silos entstanden, die jeweils für einen bestimmten Ausschnitt der Unternehmensdaten und -prozesse zuständig sind. Geschäftsprozesse reichen aber über diese Silos hinaus, oft sogar über die Grenzen des eigenen Unternehmens – man denke an komplexe Supply-Chain-Prozesse und B2B-Interaktionen. In zunehmendem Maß wird von der IT erwartet, solche Prozesse ungeachtet der existierenden Applikationsstruktur schnell umsetzen zu können. Eine redundante Neuimplementation scheidet aus zeitlichen und ökonomischen Gründen aus. Aber auch, weil Redundanz immer Qualitätsverlust und Risiken mit sich bringt. Wer kann schon sicher sein, dass ein Geschäftsobjekt von zwei parallelen Applikationen wirklich gleich behandelt wird? Bei den Zielen der Applikationsintegration kristallisieren sich somit zwei Hauptaspekte heraus:

  1. Realisierung von komplexen, applikationsübergreifenden und flexiblen Geschäftsprozessen
  2. Vermeidung von redundanter Funktionalität in der Applikationslandschaft

Die naive Umsetzung einer unternehmensweiten Applikationsintegration ist das „Punkt zu Punkt“-Muster, das zu einer so genannten „Stovepipe“-Architektur führt – alle Systeme sind „irgendwie“ mit allen anderen direkt vernetzt.
Das Feld der Enterprise Application Integration beschäftigt sich seit rund 20 Jahren damit, diesen Wartungsalbtraum gar nicht erst entstehen zu lassen. In der Praxis hat sich weitgehend eine serviceorientierte Architektur (SOA) durchgesetzt. Abbildung 1 stellt die Kernelemente einer SOA schematisch dar. Applikationen werden in (Web) Services gekapselt. Der ESB stellt eine universelle Verbindungsinfrastruktur bereit. Dank eines kanonischen Datenmodells werden die über Services hereinkommenden Daten normalisiert und an Konsumenten weitergereicht. Die Orchestrierungsschicht sorgt dafür, dass Services flexibel kombiniert werden können. So lassen sich komplexe Geschäftsprozesse weitgehend durch Konfiguration (statt Codierung in Software) abbilden.

Abb. 1: Applikationsintegration durch eine SOA (stark vereinfacht)

Ziele der UI-Integration

Zu den Konsumenten der Services einer SOA gehören in erster Linie die UIs. Betrachtet man diese genauer, ergibt sich ohne Mühe um UI-Integration das in Abbildung 2 dargestellte Bild.

Abb. 2: Nicht integrierte UIs mit Anbindung an eine SOA

Die UIs greifen jeweils auf verschiedene Services der SOA zu, stehen aber ansonsten wie große Inseln nebeneinander. Von der aufwändigen SOA-Landschaft ist für den Endbenutzer so wenig zu erkennen wie vom Meeresboden unterhalb des Wasserspiegels. Wie äußert sich das aus Sicht des Nutzers? Einige Beispiele:

  1. Die UI-Applikationen sind kaum untereinander verbunden. Ein Sachbearbeiter muss, wenn er die Vertragsdetails zu einem Kunden nachschlagen will, ein zweites UI öffnen und dort die Kunden-ID noch einmal manuell eingeben.
  2. Wenn ein Geschäftsobjekt (Kunde) in verschiedenen UIs auftritt, wird es dort inkonsistent dargestellt. So können etwa neue Aspekte (Bonität des Kunden) in dem einen UI schon verfügbar sein, in dem anderen noch nicht.
  3. Die UIs sind über die Jahre gewachsen. Weil sie von unabhängigen Fachabteilungen in Auftrag gegeben wurden, sind sie in komplett verschiedenen Technologien realisiert. Dementsprechend inkonsistent ist die Benutzererfahrung (User Experience).
  4. Es gibt kein durchgängiges Single Sign-on. Der Nutzer muss sich für Arbeitsabläufe, die sich über mehrere UIs erstrecken, mehrfach neu anmelden – üblicherweise auch mit jeweils verschiedenen Nutzernamen und Passwörtern.

Durch die fehlende UI-Integration werden Geschäftsprozesse also langsam und teuer (brauchen mehr Arbeitszeit) und sind schwer änderbar. Denkt man über eine bessere Integration der UI-Landschaft nach, zeigen sich Parallelen zu den serverseitigen Geschäftsprozessen:

  1. Serverseitig: Bei applikationsübergreifenden Prozessen werden Daten auf dem Weg zwischen Konsumenten oder Speichern transformiert und gelenkt. Das Ziel der Integration ist es, dies störungsfrei und flexibel (leicht änderbar) zu automatisieren.
  2. UI: In komplexen Arbeitsabläufen muss der Anwender seinen Blick abwechselnd auf verschiedene UIs richten, als ob er nur mit einem einzigen großen UI arbeiten würde.

In beiden Fällen ist es so, dass der Geschäftsprozess/Arbeitsablauf auch bei nicht perfekter oder fehlender Integration umgesetzt werden kann. Er erfordert dann aber viel mehr manuelle Arbeit. In leichter Abwandlung des allgemeinen Falls können wir damit die Ziele der UI-Integration wie folgt definieren:

  1. Konsistente Benutzererfahrung, die komplexe, nahtlos über UI-Grenzen verlaufende und flexibel gestaltbare Nutzeraktivitäten ermöglicht
  2. Vermeidung von redundanter Funktionalität in den UIs

Wie im allgemeinen Integrationsfall sind die Ziele 1 und 2 eng miteinander verknüpft. Sicher könnte man das erste Ziel mittels applikationsweiser Individualprogrammierung erreichen. Aber so etwas bezahlt niemand, und es würde somit ohnehin unterbleiben. Außerdem wäre eine wirkliche Konsistenz nicht zu erreichen, weil die einzelnen Applikationen auf unterschiedlichen Plattformen beruhen und von unterschiedlichen Teams erstellt werden.

Aufmacherbild: Majestic summer sunset over the sea. Dramatic sky. von Shutterstock / Urheberrecht: Creative Travel Projects

[ header = Integration durch eine UI-Plattform]

Integration durch eine UI-Plattform

Die Antwort auf diese Situation ist der Einsatz einer UI-Plattform als Integrationsinfrastruktur. Sie nimmt in gewisser Weise vergleichbare Aufgaben wahr wie eine SOA auf der Serverseite. In Abbildung 3 ist dies dargestellt.

Abb. 3: UI-Integration über eine UI-Plattform

Bildlich gesprochen realisiert die Plattform die Verbindung der UI-Inseln zu einer größeren, zusammenhängenden Landfläche. Dort kann sich der Nutzer leicht von einem Teil-UI zum anderen bewegen. Des Weiteren erlaubt die Plattform auch eine Dekomposition größerer, monolithischer UIs in kleinere Teile, die leichter zusammengesetzt und wiederverwendet werden können. Wie sehen nun die Integrationseigenschaften einer UI-Plattform im Einzelnen aus? Als Leitfaden können die Grundsätze der Softwareergonomie nach DIN EN ISO 9241-10 (DIN 2006) herangezogen werden. Demnach gewährleistet ein UI-Dialog:

  • Aufgabenangemessenheit, „wenn er den Benutzer unterstützt, seine Arbeitsaufgabe effektiv und effizient zu erledigen.“
  • Selbstbeschreibungsfähigkeit, „wenn jeder einzelne Dialogschritt (…) unmittelbar verständlich ist oder dem Benutzer auf Anfrage erklärt wird.“
  • Steuerbarkeit, „wenn der Benutzer in der Lage ist, den Dialogablauf zu starten sowie seine Richtung und Geschwindigkeit zu beeinflussen, bis das Ziel erreicht ist.“
  • Erwartungskonformität, „wenn er konsistent ist und den Merkmalen des Benutzers entspricht (…).“
  • Fehlertoleranz, „wenn das beabsichtigte Arbeitsergebnis trotz erkennbar fehlerhafter Eingaben entweder mit keinem oder mit minimalem Korrekturaufwand seitens des Benutzers erreicht werden kann.“
  • Individualisierbarkeit, „wenn das Dialogsystem Anpassungen an die Erfordernisse der Arbeitsaufgabe sowie an die individuellen Fähigkeiten und Vorlieben des Benutzers zuläßt.“
  • Lernförderlichkeit, „wenn er den Benutzer beim Erlernen des Dialogsystems unterstützt und anleitet.“

Tabelle 1 beschreibt die notwendigen Integrationseigenschaften, gegliedert nach den Zielen der Softwareergonomie. Ziel 1 (konsistente Benutzererfahrung über UI-Grenzen hinweg) beschreibt dabei eine Nutzersicht, während Ziel 2 (Redundanzvermeidung) eine IT-Sicht darstellt – welche Aufgaben hat die UI-Plattform, um Einzelimplementierungen in jedem UI zu vermeiden. Auf einige Tabelleneinträge wird unten noch im Detail eingegangen. Diese sind in folgender Weise (2a) gekennzeichnet.

Tabelle 1: Detaillierte UI-Integrationsziele

Die Plattform muss alle UIs miteinander verbinden, aber dennoch eine komplett dezentrale Entwicklung (3a) erlauben. Jede Fachabteilung hat andere Bedürfnisse (unterschiedliche Geschäftsprozess-Lebenszyklen, Budgets, Lieferanten etc.). Eine zu zentralistische Ausrichtung wird in der Praxis scheitern. Bei der Einbindung sollten UIs, die auf älteren Technologieplattformen beruhen, möglichst nicht außen vor bleiben (3b).
Der Nutzer sollte das UI bedienen können, ohne erst ein Handbuch auswendig lernen zu müssen. Ein Beispiel aus dem Alltag ist eine Schere (Norman 2002) – hier passen die Finger nur auf genau eine Weise hinein. Ein gutes UI geht vollständig auf die Verständniswelt des Benutzers ein. Das reicht von einem intuitiven und konsistenten (L&F) (2a) über die einheitliche Darstellung von Geschäftsobjekten und Status-Indikatoren (4a) bis hin zur stets gleichen Art, wie komplexe Operationen (4b) ausgeführt werden. Dazu zählen Transaktionsbehandlung, aber auch langlaufende Aktivitäten im Minutenbereich (komplexe Such-, Speicher- oder Rechenvorgänge). Dies ist gerade bei webbasierten UIs immer ein schwieriges Thema (wie wird der Nutzer über den Fortgang informiert, was geschieht bei einem Fehlschlag). Auch das Paradigma für eine Suchfunktion auf komplexen Geschäftsobjekten zählt dazu (z. B. Ein-Feld-Suche im Google-Stil vs. Auflistung aller suchbaren Attribute). Eine einheitliche Implementierung setzt Wiederverwendung von UI-Komponenten voraus, die hinreichend mächtig sein müssen.
Unterstützt die UI-Plattform Workflows (1a), so kann der Nutzer durch das UI gezielt durch eine Standardaktivität (etwa das Ändern eines Kundenvertrags) geführt werden. Ein dazu orthogonales Konzept (beide können sich durchaus auch sinnvoll ergänzen) ist es, dem Nutzer eine umfassende freie Wahl von Aktion und Navigation zu geben. Das wird durch immer gleiche Aktionen auf Geschäftsobjekten (3c) implementiert. Die Plattform stellt ein Kontextmenu zur Verfügung, wenn ein Geschäftsobjekt (Kunde) in einem UI erscheint. Der Anwender kann damit frei durch das Objektmodell navigieren – von Kunde zu Vertrag, von dort aus zur Vorgangshistorie, vom Vorgang zu angehängten Dokumenten.
Eine plattforminterne Realisierung garantiert die ständige Verfügbarkeit und Konsistenz. In der Plattform ist dafür ein kanonisches Datenmodell nötig – eine weitere Parallele zur SOA. Außerdem wird ein Registrierungsmechanismus von Geschäftsobjekten und zugehörigen (Teil-)UIs benötigt.
Mit diesem Mechanismus eng verwandt sind gemeinsame Funktionen (3d). Beispiele sind „Neuanlegen“, „Löschen“, „Drucken“, „Einfügen“ oder „Kopieren“. Aus Nutzersicht sollten diese für alle Geschäftsobjekte einheitlich verfügbar sein. Sie erfordern aber eine jeweils unterschiedliche Implementierung. Die UI-Plattform benötigt einen Registrierungsmechanismus für solche Aktionen.
Benutzt der Anwender Integrationseigenschaften wie die oben beschriebenen, benötigt er dynamisches Öffnen, Schließen und Anordnen von Teil-UIs (3e). Ein Beispiel: Der Sachbearbeiter einer Versicherung hat die Sicht auf einen Kunden geöffnet, der eine Vertragsänderung wünscht. Aus der Kundenansicht öffnet der Sachbearbeiter ein zweites Fenster mit dem Versicherungsvertrag und beginnt mit den Änderungen. Um Alternativen betrachten zu können, öffnet der Mitarbeiter die Vertragssicht ein zweites Mal und spielt dort weitere Möglichkeiten durch. Schließlich entscheidet er sich für eine der Änderungen, speichert sie und verwirft die andere. Am Ende schließt er beide Vertragsfenster wieder. Dieser an sich einfache Fall ist beispielsweise in einem typischen Webportal mit seinen nebeneinander angeordneten Portlets nicht ohne Weiteres zu realisieren.
Durch konfigurierbare Sichten (6a) schließlich kann der Administrator oder der Nutzer selbst Teil-UIs zusammenfassen, die er immer zusammen öffnen möchte – beispielsweise die Sicht „Kunde“ mit „Verträge des Kunden“ und „Vorgangshistorie zum Kunden“.

Eine kurze technische Betrachtung

Eine vollständige Auswertung der verfügbaren Technologien in Bezug auf den im vorigen Abschnitt präsentierten Kriterienkatalog würde den Rahmen dieses Artikels sprengen. Stattdessen werden die gängigsten Ansätze nur sehr grob klassifiziert und verglichen. Webbasierte UIs werden häufig in einem Portal integriert. Laut einer Forrester-Studie (Brown und Walters 2009) setzen mittlerweile mehr als 75 Prozent aller größeren Unternehmen ein Portal im Enterprise-Umfeld ein. Allerdings ist der Begriff „Portal“ alles andere als klar umrissen. Nach (Chandran 2003) stellt ein Portal „Inhalte und Applikationen, zusammen mit einer einheitlichen, auf Zusammenarbeit ausgelegten Arbeitsumgebung“ [1] zur Verfügung. Am weitesten verbreitet sind die auf einem Java-Standard beruhenden Portale – gemeint sind JSR-168/286-kompatible Portallösungen, die von zahlreichen Herstellern angeboten werden, auch von den großen Anbietern im Java-Enterprise-Umfeld (IBM, Oracle, SAP) – aber auch das häufig eingesetzte Microsoft Sharepoint kann man durchaus unter diesen Oberbegriff fassen.
Ebenfalls sehr häufig findet sich die Festlegung auf ein UI-Framework für (webbasierte) UIs als verbindlicher Standard. Im Enterprise-Bereich ist das häufig JavaServer Faces (JSF) mit einer definierten UI-Komponentenbibliothek. Eine Integration der Einzel-UIs erfolgt oft durch Zusatzlösungen wie etwa JBoss Seam oder Spring Web Flow, mit deren Hilfe sich die Abfolge (Pageflow) zwischen den einzelnen UIs definieren lässt. Hauptalternativen zu JSF sind das mittlerweile etwas aus der Mode gekommene Struts oder ein Framework wie etwa Wicket.
Eine Minimallösung zur Integration stellt ein Webtechnologiemix unter gemeinsamer Startseite dar. Ohne Festlegung auf eine UI-Plattform werden die Einzel-UIs lediglich auf einer gemeinsamen Startseite verlinkt oder in einem Frame eingebettet.
Die Eclipse Rich Client Platform (RCP) erscheint zunächst als überraschende Variante in dieser Liste. Eclipse ist eine höchst mächtige UI-Plattform, die mittels der Rich Ajax Platform (RAP) auch als Webanwendung läuft. Im Enterprise-Umfeld ist Eclipse RCP allerdings eher in Nischen anzutreffen. Das dürfte einerseits schlicht an der mangelnden Bekanntheit dieser Alternative liegen, zum anderen aber auch an der (im Vergleich zu gängigen Webtechnologien) schlechten Verfügbarkeit von Entwicklungsressourcen.
In Tabelle 2 ist dargestellt, wie viel native Unterstützung diese Technologiegruppen für die Integrationseigenschaften bieten. Die Übersicht beruht nicht auf einem systematischen Technologievergleich und kann nur daher nur der groben Orientierung dienen.

Tabelle 2: Native Unterstützung für die Integrationseigenschaften aus Tabelle 1

Fazit

Auch in dieser groben Auflösung fällt auf, dass es keinen wirklichen Königsweg bei der UI-Integration gibt. Die Eclipse-Plattform stellt fast alle Integrationseigenschaften zur Verfügung, ist aber ein recht geschlossenes System mit wenig Breitenakzeptanz im Unternehmensumfeld. Das vielfach als Integrationsplattform genutzte Webportal ist nur eine suboptimale Lösung, da ausgefeilte Integrationseigenschaften fehlen. Dennoch kann es, sinnvoll eingesetzt, die passende Lösung darstellen. Insgesamt sollte die Integrationslösung mit sorgfältigem Blick auf die existierende und noch geplante UI-Landschaft ausgewählt werden. Für einen kleinen Nutzerkreis mit hochkomplexen, den ganzen Tag lang ausgeführten Aufgaben (etwa Börsenmakler oder Monitoring-Experten eines Mobilfunknetzwerks) ist möglicherweise die hochintegrierte Eclipse-Lösung die beste. Für eine sehr große Anwendergruppe mit einfachen Tätigkeiten hingegen kann der Integrationsaufwand vielleicht viel geringer ausfallen. Dies kann bis hin zu einer komplett abgekoppelten, dafür aber maßgeschneiderten Lösung gehen, wenn sie tatsächlich nur für genau eine Aktivität genutzt wird. Auch das Kosten-Nutzen-Verhältnis spielt natürlich eine wichtige Rolle. Für ein selten genutztes UI ist ein geringerer Integrationsaufwand oft ökonomisch sinnvoll. Um im Bild der „UI-Inseln“ zu bleiben: Es muss nicht immer eine große, feste Landmasse zwischen ehemaligen Inseln sein – manchmal reichen auch ein paar einfache Brücken. Wird aber die volle Bandbreite der hier beschriebenen UI-Integrationseigenschaften umgesetzt, so sollte dies nur in Verbindung mit einer sauber modularisierten serverseitigen Architektur (etwa einer gut umgesetzten SOA) geschehen. Ansonsten verkommt die schöne neue UI-Welt nur zu einem weiteren Wartungsalbtraum. Wie immer aber auch die UI-Plattformfrage entschieden wird, am Ende muss auch das UI-Design fachgerecht umgesetzt sein. Auch auf Basis der besten Plattform lassen sich völlig inkonsistente UIs implementieren. Welches Werkzeug man auch verwendet – man muss es beherrschen.

Links & Literatur

[1] Im englischen Original: [A portal delivers] integrated content and applications, plus a unified, collaborative workplace, Übersetzung durch den Autor. Ähnlich lautende Definitionen finden sich auch in anderen Quellen, etwa bei (Gootzit, Phifer und Valdes 2008) und (Tatnall 2005)

[2] Brown, Matthew; Walters, Tim: Deciding Whether Or Not To Use A Portal Platform, Forrester, 2009

[3] Chandran, Anup: Architecting portal solutions, Research Triangle Park, NC: IBM, 2003

[4] DIN EN ISO 9241-10. Grundsätze der Dialoggestaltung, 2006

[5] Gootzit, David; Phifer, Gene; Valdes, Ray: Magic Quadrant for Horizontal Portal Products, Gartner, 2008

[6] Norman, Don: The Design of Everyday Things, New York: Perseus Books, 2002

[7] Tatnall, Arthur: Web portals: the new gateways to Internet information and services, Hershey, PA: Idea Group, 2005

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -