„Plugins für Webseiten“ ODER „Der letzte vernünftige Moment“

OpenData Portale, eGovernment Services, Business Software APIs. Sie alle stellen Daten und Services zur Verfügung, auf deren Basis wertvolle Informationen und Tools generiert werden können. Wertvoll für bestimmte Nutzergruppen in bestimmten Kontexten. Doch wann kennen wir unsere Nutzergruppen wirklich? Wo erreichen wir diese Nutzergruppen? Welche Informationen sind heute und morgen relevant? Oft können und wollen wir diese Fragen nicht ein für alle Mal beantworten.
Mit dem Konzept des „Launchers“ haben wir einen Lösungsansatz entwickelt, der in Bezug auf die Integration von Informationen und Tools jederzeit Handlungsoptionen eröffnet.

Vor etwa 10 Jahren übernahm ich die Entwicklungsleitung für ein aus dem Budget- und Zeitplan gelaufenes Portalprojekt. Ziel war es zu diesem Zeitpunkt, den Livegang zu ermöglichen. Fachlich gesehen hatte das Projekt zwei Schwerpunkte: Zum Einen die redaktionelle Pflege von Content, zum Anderen die Integration von Informationen aus Umsystemen. Es sollte eine Art Single-Point-of-Information/Navigation geschaffen werden. 

Der Kunde entschied sich zu Projektbeginn für ein Portal, weil mit einem CMS die Anforderungen an die Integration von Daten aus Umsystemen absehbar nicht effizient realisiert werden konnten.  Schlussendlich konnte die realisierte Lösung jedoch in beiden Bereichen (Content Management und Datenintegration) nicht überzeugen. Die Integration von Funktionen und Inhalten aus Drittsystemen war unverhältnismäßig komplex. Die redaktionelle Unterstützung für das Management von Content war unzureichend.

Die Alternativentwicklung setzte 3 Jahre später auf ein etabliertes kommerzielles CMS. Aspekte des Content Managements konnten nun zeitgemäß adressiert werden (Versionierung von Content, Multi-Channel-Publishing etc.). Doch die Herausforderung einer effizienten Integration von Informationen aus Umsystemen ist auch jetzt nicht gelöst. Im Ergebnis werden Daten redaktionell dupliziert; faktisch veralten wichtige Informationen – unbemerkt von den Redakteuren. Beide Lösungen waren nicht zufriedenstellend.

Frontend-Integration per Remote Control

Aus Business- und Architektursicht wollen wir handlungsfähig bleiben – den letzten vernünftigen Moment für eine Entscheidung möglichst weit hinauszögern. Besser noch, wir möchten eigentlich auch im Live-Betrieb flexibel sein. Optimalerweise wollen wir die Integration von Funktionen und Inhalten aus Umsystemen dynamisch vornehmen und jederzeit anpassen können. 

Weil die eingangs berichtete Erfahrung kein Einzelfall ist, haben wir uns an einem Lösungsansatz versucht: Frontend-Integration per Remote Control

Das Konzept:

  1. Platziere genau ein Script (wir nennen es den „Launcher“) auf der WebSite.
  2. Lasse dieses Script eine Konfiguration („launcher-config“) laden, welches die Integrationen auf der aktuellen Webseite beschreibt.
  3. Pflege die Konfiguration: Definiere die Tools & Snippets

Der Rest passiert zur Laufzeit im Frontend: Die Integration der Informationen und Tools.

Das Konzept des Launchers.

Mit Hilfe von Snippets (z.B. Webkomponenten) kann quasi jede vom Client erreichbare API angesprochen werden. Verfügbare Daten können als Kontextinformationen visualisiert werden. Funktionen kann der Anwender als webbasierteTools direkt auf der Seite nutzen. 

Die Konfiguration des Launchers kann adhoc angepasst werden – ohne programmatische Veränderung der Webseite.

So wird zum Beispiel folgendes problemlos möglich:

  • Eine neue Quelle mit kontextrelevanten Informationen integrieren (z.B. Ansprechpartner oder Dokumente zum Thema der Seite)
  • Die neue Version des integrierten SelfService für die Raumbuchung in die Toolbar integrieren
  • Die übergreifende Suche als Tool in alle Seiten integrieren
  • ….

Fazit

Der Kerninhalt einer Website verliert nichts von seiner Bedeutung. Für deren Gestaltung und Verwaltung bieten verschiedenste Arten von Content Management Systemen, Frameworks für Custom Webapplikationen etc. großartige Möglichkeiten. Im Backend helfen uns Konzepte wie Container, Microservices und WebApis, die o.g. Qualitätskriterien zu adressieren. 

Dort, wo wir auch im Frontend mehr Flexibilität brauchen, setzen wir mit dem „Launcher“ und seinem Pluginkonzept für Webseiten an. Mit dessen Hilfe können wir Webseiten jederzeit um weitere Elemente (beliebiger Komplexität) anreichern. Lassen Sie den Gedanken auf sich wirken. Uns erlaubt er schon jetzt neue Denk- und Lösungsansätze.