Vision Paper: Zukunftsentwicklung von XDM

Die höchste Ausbaustufe in diesem Themenfeld ist die vollständige Anbindung relationaler Datenbanken an das neu entwickelte Framework. Damit erhalten Benutzer die Möglichkeit, Daten aus relationalen Datenbanken zu extrahieren, zu transformieren und in andere Zielsysteme zu laden. Dies bildet die Brücke zwischen dem heutigen Funktionsumfang von XDM und der zukünftigen, breiter aufgestellten Plattformarchitektur. Diese Integration wird vermutlich kein Ersatz der bisherigen RLP Copy Tasks darstellen, aber die Anbindung an relationale Datenbanken ist für aufbauende Funktionen wir Analyse, Generierung, etc. von zentraler Bedeutung.

Eine wiederkehrende Kundenanforderung ist die Möglichkeit, Daten aus unterschiedlichen Quellen zwischenzuspeichern und später erneut zu verwenden. Ein typischer Use Case besteht darin, Daten zu sichern, um sie zu einem späteren Zeitpunkt in einem Task erneut als Quelle für die Beladung eines anderen Systems zu nutzen.

Für dieses Vorhaben sind grundsätzlich zwei Ansätze denkbar:

Der erste Ansatz bietet maximale Flexibilität, erhöht jedoch Komplexität und Implementierungsaufwand. Der zweite Ansatz reduziert die Komplexität, schränkt aber die universelle Nutzbarkeit ein.

Für die Ausgestaltung der IceBox müssen insbesondere folgende Aspekte berücksichtigt werden:

KI kann dazu beitragen, die Datenbereitstellung deutlich zu vereinfachen. Benutzer, die Daten benötigen, formulieren ihre Anforderungen in der Regel aus fachlicher Sicht. Sie kennen jedoch häufig weder die technischen Speicherformen noch die konkreten Datenbanken oder Datenstrukturen, in denen die benötigten Informationen liegen.

XDM soll hier eine fachlich orientierte Interaktion ermöglichen: Anwender beschreiben ihre Anforderungen per Prompt, und XDM übersetzt diese Anforderungen mithilfe von KI in eine Suche nach geeigneten Testfällen. Als Wissens- und Suchgrundlage dient dabei der Test Data Finder beziehungsweise dessen künftige Weiterentwicklung.

Die so ermittelten Testfälle entsprechen den beschriebenen Anforderungen und werden dem Benutzer zur Auswahl angezeigt. Anschließend kann die Suche iterativ weiter verfeinert werden, bis ein zufriedenstellendes Ergebnis erreicht ist. Die ausgewählten Testfälle sollen danach direkt in einem DataShop als Quelle für die Bereitstellung genutzt werden können.

Der wesentliche Vorteil dieses Ansatzes liegt in der Abstraktion technischer Komplexität. Benutzer müssen nicht mehr wissen, wo die Daten physisch liegen, wie sie strukturiert sind, welche Tabellen, Collections oder Dateien relevant sind, oder über welche Prozesse die Bereitstellung erfolgt. Stattdessen können sie ihre fachlichen Anforderungen formulieren und erhalten darauf basierend passende Daten.

Im Hintergrund nutzt XDM die Informationen des Test Data Finders, um geeignete Daten zu identifizieren, und verwendet passende DataShops beziehungsweise Bereitstellungsprozesse, um diese Daten auszuliefern. Dabei bleiben bestehende Sicherheits- und Governance-Mechanismen erhalten:

Benutzer dürfen nur auf Daten zugreifen, für die sie berechtigt sind. Die Bereitstellung erfolgt ausschließlich im Rahmen definierter Zugriffsrechte. Sensible Daten werden durch die Masking-Funktionen von XDM automatisch geschützt. Damit wird sichergestellt, dass Fachanwender Daten effizient nutzen können, ohne sich selbst um technische Details, Berechtigungslogik oder Datenschutzmaßnahmen kümmern zu müssen.

Die synthetische Generierung von Testdaten ist insbesondere für komplexe Systeme mit hohem Aufwand verbunden. Voraussetzung dafür ist ein fundiertes Verständnis der fachlichen Entitäten einer Anwendung, ihrer Attribute, ihrer semantischen Bedeutung sowie der Beziehungen untereinander. Für viele dieser Felder müssen geeignete Generierungslogiken oder Algorithmen entwickelt werden, um konsistente und realitätsnahe Daten zu erzeugen.

Um diesen Aufwand zu reduzieren, soll XDM einen pragmatischen und risikoorientierten Ansatz unterstützen: Abhängig von der fachlichen Relevanz einzelner Felder kann entschieden werden, ob diese mit realitätsnah generierten Werten oder mit einfachen Zufallsdaten befüllt werden. Dadurch lässt sich der Erstellungsaufwand gezielt auf die für Tests tatsächlich kritischen Datenbereiche konzentrieren.

Mithilfe von KI soll XDM künftig mit deutlich geringerem Modellierungs- und Implementierungsaufwand in der Lage sein, realistische Testdaten zu generieren. Grundlage dafür ist das Datenmodell der Anwendung in Verbindung mit einer Wissens- und Metadatenbasis in Form des Data Brain. Dieses stellt die notwendigen Informationen über Datenstrukturen, Wertebereiche, Verteilungen, Beziehungen und fachliche Muster bereit, die für eine qualitativ hochwertige Datengenerierung erforderlich sind.

Auf dieser Basis soll XDM Testdaten erzeugen können, die sowohl strukturell konsistent als auch fachlich plausibel sind. Die generierten Daten sollen anschließend in einem Format bereitgestellt werden, das direkt in die von XDM unterstützten Zielsysteme und Datenformate geladen werden kann.

Beispiele hierfür sind:

Damit wird die Datengenerierung zu einem integrierten Bestandteil der XDM-Plattform: von der Analyse des Datenmodells über die KI-gestützte Erzeugung bis hin zur direkten Bereitstellung in den gewünschten Zielsystemen.

Ein wesentlicher Hemmschuh bei der produktiven Einführung von XDM in größeren Umfeldern ist der Aufwand für die Modellierung von Tabellen und Beziehungen innerhalb der Plattform. Abhängig von Komplexität und Größe der Kundenanwendung kann dieser Aufwand mehrere Personentage bis hin zu mehreren Wochen betragen.

Um diesen Einrichtungsaufwand zu reduzieren, soll KI genutzt werden, um Muster in Tabellenstrukturen und Dateninhalten zu erkennen und daraus Vorschläge für Beziehungen zwischen Tabellen abzuleiten. Diese Vorschläge sollen im Anschluss automatisch in XDM angelegt oder durch Benutzer verfeinert werden können.

Ein möglicher Ansatz besteht in einem Workflow auf Basis von MCP und LLM. Dabei erhält das Sprachmodell Informationen über:

Auf dieser Grundlage soll das Modell Hinweise auf potenzielle Beziehungen erkennen, beispielsweise über:

Die vorgeschlagenen Beziehungen können anschließend in einem dialogorientierten Prozess weiter verfeinert und präzisiert werden, bis ein belastbares Ergebnis erreicht ist. Das Resultat soll automatisiert in Form eines Application Models in XDM übernommen werden, inklusive der erforderlichen DataRelationRules.

Ein vergleichbarer Ansatz ist auch für die Erkennung sensibler Daten denkbar, um Maskierungs- und Anonymisierungsregeln gezielt vorzuschlagen.

Der DataShop ist bereits heute ein zentraler Bestandteil von XDM und für viele Anwender das wichtigste Zugangstor zur Suche und Bereitstellung von Testdaten. Auch künftig bleibt der DataShop ein wesentlicher Baustein der Plattform. Seine Rolle soll jedoch weiterentwickelt werden: weg von einer stark technisch geprägten Bestelloberfläche hin zu einer flexiblen, konfigurierbaren und breiter einsetzbaren Interaktionskomponente.

Ziel ist es, bestehende Restriktionen im aktuellen Ansatz aufzulösen, die Wartbarkeit zu verbessern und gleichzeitig neue Nutzungsszenarien zu ermöglichen. Der DataShop soll dadurch nicht nur einfacher konfigurierbar werden, sondern auch stärker von technischen Implementierungsdetails entkoppelt werden.

Ein zentrales Handlungsfeld ist die heutige Parameter-Modellierung. Aktuell wird die Darstellung eines Formularfeldes auf einer Bestellmaske dadurch bestimmt, dass ein Form-Parameter mit einem Parameter eines zugrunde liegenden Templates, also eines Tasks oder Workflows, verbunden ist. Diese enge Kopplung führt in der Praxis häufig dazu, dass zusätzliche Custom Parameter an XDM-Objekten angelegt werden müssen, obwohl diese nur temporär für die Benutzerinteraktion benötigt werden und fachlich nicht zur eigentlichen Verarbeitung gehören.

Ein weiterer wesentlicher Schwachpunkt ist die derzeitige Formularlogik. Die Regeln dafür, wann Felder sichtbar sind, wann sie Pflichtfelder werden und welche Eingaben zulässig sind, sind bislang typischerweise in zentralen Skripten umgesetzt. Dies erschwert die Pflege und Weiterentwicklung erheblich: Änderungen setzen technisches Spezialwissen voraus, gewachsene Skripte werden schwer wartbar, und Anpassungen an der Formularlogik erhöhen das Risiko unbeabsichtigter Seiteneffekte.

Für die Zukunft wird daher ein Zielbild verfolgt, in dem die Formularlogik weitgehend über die Benutzeroberfläche konfiguriert werden kann. Anwender oder Konfiguratoren sollen in die Lage versetzt werden, typische Anforderungen ohne tiefgehende Skriptkenntnisse umzusetzen. Dazu gehören insbesondere:

Damit soll der überwiegende Teil typischer Anwendungsfälle durch Konfiguration statt durch individuelle Skriptentwicklung abgedeckt werden.

Darüber hinaus sollen Formularparameter künftig stärker von der dahinterliegenden Verarbeitung entkoppelt werden. Eingabefelder auf einer Bestellmaske sollen unabhängig davon modelliert werden können, wie ein Task, Workflow oder ein anderer technischer Prozess diese Informationen später verarbeitet. Dadurch wird die Gestaltung intuitiver Benutzeroberflächen erleichtert und die Wiederverwendbarkeit von Formularen verbessert.

Langfristig soll sich der DataShop zudem stärker vom bisherigen Template-Ansatz lösen. Heute basiert die Nutzung im Wesentlichen darauf, dass im Hintergrund ein Task oder Workflow ausgeführt wird. Künftig soll der DataShop als allgemeinerer Interaktionsbaustein gedacht werden, der auch in anderen Kontexten eingesetzt werden kann, in denen strukturierte Benutzereingaben, fachliche Auswahlprozesse und nachgelagerte Aktionen miteinander verbunden werden müssen.

In dieser Weiterentwicklung liegt ein wesentlicher Schritt zur Modernisierung der Plattform: Der DataShop bleibt das strukturierte und geführte Frontend für wiederkehrende Anwendungsfälle, wird dabei aber flexibler, konfigurierbarer und anschlussfähiger für neue Szenarien innerhalb einer umfassenderen XDM-Plattform.

Neben der Weiterentwicklung des DataShops soll auch die generelle Interaktion mit XDM grundlegend vereinfacht werden. Ziel ist es, XDM nicht nur über klassische Benutzeroberflächen und konfigurierbare Formulare nutzbar zu machen, sondern zusätzlich über einen zentralen, in die Plattform integrierten Prompt-Zugang.

Dieser Ansatz geht deutlich über die reine Suche und Bestellung von Daten hinaus. Stattdessen soll der Prompt als universelle Interaktionsschicht für XDM dienen, über die Benutzer unterschiedliche Operationen fachlich und technisch unterstützt ausführen können.

Dazu zählen unter anderem:

Langfristig soll der Prompt damit zu einem zentralen Einstiegspunkt in die Plattform werden. Benutzer können ihre Absicht in natürlicher Sprache formulieren und erhalten darauf aufbauend Unterstützung bei Analyse, Navigation, Konfiguration und Ausführung.

Ein besonderer Mehrwert entsteht dabei durch die Integration mit angebundenen Fremdsystemen. Insbesondere die Anbindung technischer Systeme wie Datenbanken spielt hier eine entscheidende Rolle. Dadurch kann der Prompt nicht nur auf in XDM vorhandenes Wissen zugreifen, sondern auch Informationen aus externen Systemen einbeziehen, um beispielsweise Tabellenstrukturen zu analysieren und daraus Modellierungsvorschläge oder konkrete Tabellenmodellierungen in XDM abzuleiten.

Dieser Ansatz ergänzt die Weiterentwicklung der Formular-Logik um eine zweite, noch stärker abstrahierende Interaktionsform: Während konfigurierbare Formulare strukturierte und geführte Prozesse für wiederkehrende Anwendungsfälle ermöglichen, eröffnet der zentrale Prompt einen flexiblen Zugang für Analyse, Exploration, Konfiguration und operative Nutzung der Plattform. Damit entwickelt sich XDM schrittweise von einer spezialisierten Testdatenlösung hin zu einer dialogfähigen technischen Plattform für Daten.