2. Datenintegration mit dem CQRS-Muster
In den zurückliegenden Jahren wurden zahlreiche ETL-Tools (Extract, Transform, Load) für eine bessere Integration von Daten in eine bestehende Software entworfen. Diese folgen einer ähnlichen Logik, wie sie bei der Integration von Services in einen ESB zur Anwendung kommt. Dabei sind jedoch oft monolithische Datendrehscheiben entstanden, die nicht zur gewünschten Entkopplung der Datenmodelle beitrugen. Das Problem: Trotz Middleware und Datenvirtualisierung führt eine Änderung in einem Tabellenschema zu zahlreichen Nebeneffekten in anderen Datentöpfen.
Ein Ansatz, um auch die Daten zu entkoppeln, sind kostengünstige Open-Source-Lösungen wie Hadoop oder Kafka. Darauf basiert auch das CQRS-Muster (Command, Query, Responsibility, Separation). In diesem Muster bleiben die existierenden Datentöpfe zwar erhalten, parallel wird jedoch ein separates Datenmodell aufgebaut, welches für Read-Only-Zugriffe und Analytics optimiert ist. Dieses zusätzliche Datenmodell kann Redundanzen enthalten, um eine einfachere oder schnellere Analyse zu ermöglichen. Da die ursprünglichen Daten nicht verändert werden, können Nutzer diese auf zahlreiche Art und Weise analysieren. Dies ermöglicht eine echte Entkopplung von missionskritischen Systemen die im Command-Pfad von CQRS erhalten bleiben.
3. Mehr Personalisierung durch Entkopplung und Modularisierung von Workflows
Makroflows, die in externen Applikationen ausgedrückt sind, gehören in einer modernen Software-Architektur der Vergangenheit an. An ihre Stelle rücken Microflows, die von den Endnutzern für die Erfüllung einer bestimmten Aufgabe pluggable und ad-hoc zusammengebaut werden können. Das ist die Grundlage für personalisierte Anwendungen, die den Nutzern in ihrer täglichen Arbeit einen großen Gestaltungsspielraum lassen. Diese wollen schließlich möglichst viel Kontrolle über Daten und Abläufe behalten statt in vorgegebene Systeme gezwängt zu werden.
Die Nutzung von Daten aus bestehenden Applikationen ist heute oft unnötig kompliziert und wenig nutzerfreundlich. Die Folge: Nutzer kopieren sich die Daten lieber mühselig aus der Applikation in andere Software-Tools wie zum Beispiel Excel, verarbeiten sie dort weiter, nur um sie am Ende wieder zurück in die Anwendung zu laden. Wesentlich komfortabler wäre hingegen ein eigenes User Interface (UI) für jeden Nutzer - eine Spielwiese, deren Aufbau sie verstehen und die sie ganz nach ihren Wünschen gestalten und kontrollieren können. Die heutigen Komponenten bieten diese Freiheitsgrade jedoch nicht, da sie auf standardisierten Softwarekomponenten aufbauen.
Deshalb muss eine Architektur der Zukunft so gestaltet sein, dass die einzelnen Module als Grundbausteine funktionieren, die der Nutzer ganz individuell kombinieren kann. So lassen sich personalisierte Abläufe und Benutzererfahrungen einfach umsetzen. Das hat aber auch Folgen für die Unternehmen: Statt wie bisher als monolithische Dienstleister aufzutreten, werden sie zu Anbietern von modularen Diensten, deren Funktionen gegen Bezahlung in konkrete Abläufe eingebaut werden.
Kurz gesagt: Die Module, aus denen sich ein Benutzer seine Abläufe zusammenstellt, werden nicht mehr nur von der eigenen Organisation bereitgestellt, sondern ergeben sich aus einem globalen Ökosystem ohne zentrale Kontrolle. Das stellt jedoch neue Herausforderungen an die Firmen-IT. Sie muss sicherstellen, dass die von den Mitarbeitern und den Endkunden benutzten Module sowohl fachlich wie auch sicherheitstechnisch im Einklang mit den Zielen der Gesamtorganisation stehen.