Frequently Asked Questions (FAQ)

In XDM werden Verbindungen und Umgebungen einmalig definiert und in mehreren Aufgaben wiederverwendet. Kopien sind sowohl innerhalb derselben als auch zwischen unterschiedlichen Verbindungen/Umgebungen möglich. Über den XDM Data Shop lassen sich Aufgaben ausführen, ohne die Detailkonfiguration zu kennen. Verbindungen können als reine Quellverbindungen (Read-only) definiert werden.

XDM kann komplette Datenbanken für DB2 LUW, Microsoft SQL Server und PostgreSQL klonen.

XDM erlaubt die Auswahl über Include-/Exclude-Regeln auf Tabellenebene, inklusive Wildcards. Die tatsächlich zu kopierenden Tabellen werden zur Laufzeit dynamisch basierend auf den Regeln ermittelt.

Ja. Das Nachladen von Produktivdaten in die Golden Copy ist mit XDM möglich. Bestehende Daten können ersetzt und/oder um neue Daten ergänzt werden; horizontale und vertikale Selektion sowie zeitbasierte Deltas werden unterstützt.

Ja. Daten können jederzeit in unterschiedlichen Ausprägungen aus der Golden Copy extrahiert werden.

XDM kann anschließend die Preproduction als Quelle verwenden. In XDM lassen sich Verbindungen als reine Quellverbindungen definieren (nur Lesezugriff).

Bereitstellungen über Nacht bzw. innerhalb von 24 Stunden sind in vielen Fällen möglich, etwa durch Datenbankklonen und Tabellenkopien. Die tatsächliche Laufzeit hängt von Datenvolumen, Infrastruktur und Parallelisierung ab und kann nicht garantiert werden. XDM unterstützt parallele Tabellenkopien; zusätzlich können mehrere Aufgaben parallel ausgeführt werden, um die Performance zu erhöhen.

Häufig ja; die Laufzeit ist jedoch vom Datenvolumen und der Infrastruktur abhängig.

Die Golden Copy wird durch das Tool erstellt und ist anschließend eine eigenständige, von der Quelle unabhängige Umgebung in Form einer externen Datenbank. Sie dient als Testdaten-Basis.

XDM Native Table Copy nutzt Unload-/Load-Methoden; die Daten werden dabei auf den Quell- und Ziel-Servern in Dateien abgelegt.

Ja. Durch den Einsatz von Image Copies/Snapshots bzw. Preproduction-Quellen kann der Kopiervorgang ohne Beeinträchtigung des laufenden Betriebs erfolgen.

XDM ermöglicht jederzeit das Kopieren einer klar definierten Datenmenge von einer Umgebung in eine andere – selektiv, konsistent und DBMS-übergreifend. Umfang und Startpunkt werden über Startbedingungen und Reduktionsregeln festgelegt; die konkreten Datensätze ermittelt XDM zur Laufzeit anhand der definierten Relationen.

Mit Row Level Processing (RLP) wählen Sie eine Starttabelle und eine Startbedingung (z. B. Kunden- oder Vertragsnummer). XDM selektiert alle passenden Zeilen dieser Starttabelle und automatisch alle abhängigen Zeilen aus verknüpften Tabellen – auch über Datenbanken hinweg. Voraussetzung ist, dass die Relationen im Anwendungsmodell einmalig hinterlegt sind. Beispiele: alle Verträge zu ausgewählten Kunden; alle Daten zu einer Versicherungsscheinnummer (VSNR) inklusive zugehöriger Tabellen.

Relationen können zwischen Anwendungsmodellen verschiedener Datenbanken/DBMS definiert werden. RLP traversiert diese Relationen zur Laufzeit; Auswahl und Übertragung sind unabhängig davon, ob Daten in einer oder mehreren Datenbanken liegen.

XDM nutzt die im Modell definierten Relationen bzw. importierte Fremdschlüssel, ermittelt pro Tabelle die zugehörigen Datensätze zur Laufzeit und berücksichtigt die korrekte Einfügereihenfolge. Verletzen Datensätze Ziel-Constraints, können sie übersprungen werden. Ein Stichtag kann über die Startbedingung abgebildet werden.

Zyklen werden erkannt und über einen konfigurierbaren Iterationszähler begrenzt. Die Traversierungstiefe der Abhängigkeiten ist steuerbar; nicht auflösbare Enden werden beim Einfügen ausgelassen.

Über Reduktionsregeln (SQL je Tabelle) können Sie Filter, Limits oder Spaltenreduktionen definieren. Tabellen lassen sich durch fehlende Relation oder explizit in einer Aufgabe ausschließen. So ist auch die Reduktion produktiver Daten möglich.

Ja. Anwendungsmodelle und Umgebungen werden einmalig erstellt und stehen allen berechtigten Nutzern zur Verfügung. Jede Tabelle gehört zu genau einem Anwendungsmodell; eine Umgebung kann mehrere Anwendungsmodelle enthalten.

Schlüssel der Start- und Folgetabellen werden automatisch erkannt (Startbedingung bzw. Relationsdefinition). Passen Schlüssel nicht exakt, kann eine Zuordnung über ein Lookup‑Skript definiert werden. Zusätzliche Schlüssel lassen sich z. B. über den Data Shop aus Dateien ergänzen.

Standardselektionen ergeben sich aus den modellierten Relationen; passende DB‑Queries werden zur Laufzeit generiert. Eigene Kriterien sind frei definierbar (SQL), auch mit komplexen Regeln. Treffen Queries mehrere Zeilen, werden alle gefundenen Datensätze samt abhängiger Daten selektiert.

Metadatenmodelle werden direkt aus angebundenen Datenbanken geladen oder manuell importiert (z. B. Keys). Relationen können unabhängig von vorhandenen DB‑Fremdschlüsseln und auch zwischen Datenbanken modelliert werden. Für Abhängigkeiten außerhalb der DB‑Metadaten (z. B. Datei‑Korrespondenzen) können entsprechende Zuordnungsregeln hinterlegt werden, damit XDM sie als abhängige Objekte berücksichtigt.

Ja. Relationen und Strukturen werden im Anwendungsmodell grafisch visualisiert; Regelwerke können aus vorhandenen Fremdschlüsseln automatisch generiert und in Diagrammen dargestellt werden.

Ja. Die selektive Bereitstellung erfolgt identisch über RLP; alle abhängigen Objekte werden ermittelt. Eine Anonymisierung kann als zusätzlicher Verarbeitungsschritt in den Kopierfluss integriert werden.

XDM bietet Maskierung/Anonymisierung/Pseudonymisierung für alle von XDM unterstützten Systeme (z. B. Db2 z/OS, Db2 LUW, MS SQL). In XDM erfolgen Änderungen über Modifikationsregeln und -methoden (kleine Skripte, primär JavaScript). Mitgelieferte Beispiele und Funktionen (u. a. Hashing) erleichtern die Umsetzung. Die konkreten Ergebnisse und Grenzen hängen von der gewählten Methode und Konfiguration ab.

Ja. Methoden können so konfiguriert werden, dass Daten DSGVO-konform anonymisiert werden. Mitgelieferte, anpassbare Methoden decken personenbezogene Attribute ab. Modifikationen können fest an Quellsysteme gebunden werden, sodass bei jedem lesenden Zugriff über das Tool automatisch maskiert wird. Strenge Datenschutzdefinitionen können berücksichtigt werden; bei Bedarf sind applikationsspezifische Anpassungen in Abstimmung mit Fachbereichen sinnvoll.

Ein PII Finder Task ermittelt Spalten mit potenziell personenbezogenen Daten. Diese Spalten werden anschließend in den Modifikationsdefinitionen hinterlegt und mit geeigneten Methoden verarbeitet.

Ja. XDM kann Daten schon während des Exports modifizieren, sodass keine unmodifizierten Daten extrahiert werden. Die Art der Modifikation wird über JavaScript-basierte Methoden definiert; anpassbare Beispielskripte sind enthalten.

Ja. Verwenden Sie eine deterministische Modifikationsmethode (z. B. Hashverfahren, definierte Pool-/Lookup-Tabellen). So werden identische Eingaben stets konsistent umgesetzt, auch wiederholbar auf unterschiedlichen Datenbanken und Systemen, sofern dieselbe Methode, Konfiguration und Datenbasis (z. B. identische Lookup-Tabellen) verwendet werden.

XDM kann während der Kopie/Modifikation dieselben Regeln auf alle betroffenen Spalten anwenden, sodass Beziehungen erhalten bleiben. Konsistenz wird durch identische Modifikationsmethoden für alle relevanten Felder erreicht. Pool-/Lookup-Zugriffe erfolgen per Hash; wichtig ist, dass die zugrunde liegende Eingabemenge/Schlüssel in allen Tabellen identisch bestimmt wird. So bleiben Abhängigkeiten applikations- und datenbankübergreifend konsistent (z. B. Db2 z/OS, Db2 LUW, MS SQL).

Ja, wenn nicht umkehrbare Verfahren eingesetzt werden (z. B. Zufallskomponenten, Hash-basierte Verfahren ohne Rückrechenmöglichkeit). XDM speichert keine „Schlüssel“ im klassischen Sinn. Der konsistente Zugriff erfolgt über Hashing und Normalisierung. Ein De-Hashing ist nicht möglich; selbst bei unberechtigtem Zugriff auf Lookup-Tabellen lassen sich keine Originalwerte ableiten.

Ja. Für Namen/Adressen können Pooltabellen mit gültigen Werten verwendet werden. Für Nummern mit Prüfsummen (z. B. Kreditkarten, SSN, Bankcodes) wird die Prüfsumme in der Modifikationsmethode korrekt berechnet, sodass resultierende Werte gültig und mit bestehenden Prüfwerkzeugen validierbar sind.

Ja. Eine Modifikationsmethode mit Hash-/Lookup-Tabelle kann Adressen auf Alternativen innerhalb desselben PLZ-Gebiets abbilden. XDM wird mit Lookup-Tabellen ausgeliefert, die dieses Anforderungsprofil unterstützen.

Es gibt keine Standardmethode hierfür. Es ist jedoch umsetzbar, z. B. über eine Pool-/Lookup-Tabelle, die Adressen mit identischer ZÜRS-Klasse miteinander verknüpft.

Ja. Verfremdungsmethoden werden auf klar definierte Bereiche angewendet (Datenbank, Schema, Tabelle, Spalte). Dadurch lassen sich Teilmengen gezielt bearbeiten.

Ja. Modifikationsmethoden können direkt in der Oberfläche erstellt/angepasst werden. Die Einbindung eigener Komponenten ist möglich (JavaScript, Groovy, JAR-Bibliotheken) sowie der Aufruf externer Funktionen/Plugins aus den Methoden.

XDM arbeitet nicht mit gespeicherten Entschlüsselungs-Schlüsseln. Konsistenz wird über Lookup-Tabellen erzielt, die per Hash auf Originalwerte zugreifen und diese normalisiert zuordnen. Die Tabellen sind konfigurierbar; ein Rückschluss auf Originaldaten ist nicht möglich.

Der Test Data Finder ermöglicht die Suche nach Testfällen anhand konfigurierbarer Attribute und liefert statistische Kennzahlen pro Attribut (z. B. Minimum, Maximum, Mittelwert, Perzentile). Darauf basierend ist eine weitergehende Klassifizierung möglich.

Ja. XDM nutzt einen vorhandenen Datensatz als Basis, vervielfältigt ihn und passt Werte über definierte Modifikationen an.

Sowohl einzelne Datensätze kurzfristig (ad hoc) als auch große Datenmengen, z. B. für Lasttests.

Zwei Wege: a) Externe synthetische Daten als CSV importieren und als Quelle eines Kopierauftrags nutzen. b) Synthetische Daten direkt in XDM aus vorhandenen Datensätzen generieren.

Ja. Modifikationen können z. B. über Hashing oder feste Seeds deterministisch konfiguriert werden.

Ja. Es stehen u. a. Vor- und Nachnamen sowie Adressen (inklusive existierender Adressen mit Geolokation) und weitere Standarddaten zur Verfügung.

Ja. Dies ist u. a. im DataShop parametrisierbar, um eine dynamische Zuordnung bei der Bestellung zu ermöglichen.

Ja. Lookups können aus allen Bestandstabellen der Anwendungsdatenbank aufgebaut werden.

Ja. Die Abbildung erfolgt über Application Models; die Erzeugungstiefe kann pro Lauf dynamisch gesteuert werden.

Ja. Die Löschfunktion ermittelt zusammenhängende Daten innerhalb einer Umgebung und entfernt sie in referenziell korrekter Reihenfolge.

Ja. Die Mechanik ähnelt der Verfremdung; synthetische Daten lassen sich bestehenden pseudonymisierten Daten hinzufügen, z. B. durch Erzeugen von Leereinträgen in der Applikation und anschließendes Befüllen mit XDM oder durch Kopieren aus der Datenbank mit anschließender Modifikation.

Der Data Shop ist Bestandteil von XDM. Er ermöglicht das Speichern, Bestellen und Bereitstellen von Testdaten per Self‑Service, ohne Details zu XDM oder zu Datenbankschemata kennen zu müssen. Er ist auch für Fachtester geeignet.

Ja. Über den Data Shop können Besteller mit wenigen Parametern ihre gewünschten Testdaten selektieren und bei Bedarf direkt in die Zielumgebung schreiben lassen – ohne spezielles XDM‑ oder Datenbankwissen.

XDM läuft serverseitig und ist über den Browser nutzbar; eine lokale Client‑Installation oder Updates entfallen. Für reine Besteller gibt es ein reduziertes, übersichtliches Layout (dedizierte Data‑Shop‑Ansicht).

Parameter werden zentral beim Bestellen im Data Shop gesetzt oder beim Aufruf über die öffentliche REST API übergeben. So lassen sich Copy‑/Selektionsjobs einheitlich und unkompliziert konfigurieren.

Ja. Im Data Shop können frei definierbare Eingabefelder konfiguriert werden. Die Eingaben füllen benannte Custom‑Parameter in XDM und steuern die zugrunde liegenden Workflows fachnah.

Ja. Bestellungen können als Anträge gestellt und über eine sekundäre Genehmigung (z. B. durch den Betrieb) freigegeben werden. Das XDM‑Rollenmanagement steuert Sichtbarkeit und Ausführung von Aufträgen für definierte Nutzergruppen.

Ja. In XDM definierte Tasks lassen sich beliebig oft ausführen. Mehrere Tasks können in Workflows kombiniert werden; derselbe Task kann in verschiedenen Workflows wiederverwendet werden. Alle Aufträge sind in der XDM‑UI einsehbar.

Ja. Workflows können als REST‑Client agieren, Informationen aus Jira/Xray lesen und Ergebnisse dorthin zurückschreiben.

XDM besitzt einen integrierten Scheduler für zeitgesteuerte Ausführungen. Alternativ kann XDM vollständig über die öffentliche REST-API gesteuert und damit in externe Scheduler (z. B. Automic/UC4) eingebunden werden. Aufträge lassen sich wiederkehrend planen und zentral für alle angebundenen Datenbanksysteme starten.

Ja. Über die REST-API können Aufträge inkl. Parameter gestartet, gestoppt und überwacht werden (Status, Logs). Dadurch ist eine nahtlose Integration in CI/CD und Testautomatisierung (z. B. Robot Framework, UFT) möglich.

Ja. Die REST-API erlaubt u. a. das Starten und Parametrisieren von Tasks, das Abfragen von Status/Ergebnissen sowie die Integration in externe Tools und Prozesse.

Jeder Tasklauf verbindet sich mit den angebundenen Datenbanksystemen und schreibt die Ergebnisse direkt in die Zielumgebung. Optional kann ein Staging-Ansatz genutzt werden. Alternative Zugriffspfade können je nach Sicherheits- und Netzwerkvorgaben konfiguriert werden.

Integrationen erfolgen über die REST-API von XDM. Die konkrete Ausgestaltung wird pro Zielplattform und Use Case geprüft. Die Nutzung verschlüsselter oder pseudonymisierter Testdaten ist prinzipiell über die REST-Schnittstelle möglich, hängt aber von den Fähigkeiten der angebundenen Plattform ab.

Ja. Über Stage Hooks können eigene Prozesse vor, nach oder an definierten Punkten innerhalb einer Kopie ausgeführt werden. Hierüber lassen sich z. B. Skripte oder externe Tools einbinden.

Ja. Zusätzliche Daten lassen sich über spezialisierte XDM-Tasks (z. B. RLP, Compatibility TC) oder durch Import aus einer Icebox einbinden. Weitere notwendige Schritte können über Hooks in den Prozess integriert werden.

Ja. Sobald eine Operation in XDM definiert ist, kann sie beliebig oft ausgeführt und bei Bedarf per (externem oder internem) Scheduler zyklisch geplant werden.

Derzeit nicht. Eine entsprechende Funktion ist angedacht, befindet sich jedoch noch ohne konkreten Zeitplan in der Planung.

Ja. Mit der XDM Icebox lassen sich mehrere Versionen eines Testdatenbestands als Generationen speichern. So können z. B. Baselines vor einem Testzyklus oder Stände nach Testausführungen festgehalten werden.

Sichern Sie vor Start des Testzyklus den gewünschten Datenstand als Icebox-Generation. Diese Baseline kann jederzeit wiederhergestellt und bei Bedarf auch erneut angewendet werden. Ebenso lassen sich nach jedem Testlauf neue Generationen anlegen.

Standardmäßig schreibt ein Task die extrahierten Daten direkt in das Zielsystem. Für eine Zwischenspeicherung nutzt XDM die Icebox; die Daten werden dabei außerhalb der Datenbank in einem von XDM verwalteten internen Zwischenformat abgelegt.

Ohne Icebox erfolgt ein durchgängiger Prozess: Extraktion und Direktimport laufen in einem Task. Mit Icebox sind es zwei Schritte: erst Export in die Icebox, anschließend Import aus der Icebox in das Ziel. Beide Schritte können in einem Workflow kombiniert werden.

Ja, sofern die Daten in einer Icebox-Generation gesichert sind, können sie beliebig oft in Zielsysteme importiert werden.

Ja. Wenn der ursprüngliche Datenstand vor dem Import als Icebox-Generation gesichert wurde, kann dieser Stand jederzeit wiederhergestellt werden, z. B. nach einem fehlgeschlagenen Kopierprozess oder um den Ausgangszustand wiederherzustellen.

Ja. XDM prüft bei jeder Task-Ausführung die Tabellenstrukturen von Quelle und Ziel. Stimmen sie nicht überein, wird der betroffene Task abgebrochen oder die Tabelle übersprungen, um Ladefehler zu vermeiden. Zusätzlich gibt es einen separaten Strukturvergleichs-Task, mit dem Schemas regelmäßig verglichen werden können, um Unterschiede frühzeitig zu erkennen.

XDM überprüft bei Strukturunterschieden automatisch, ob ein Kopieren möglich ist; falls nicht, wird der Task abgebrochen oder die Tabelle übersprungen. Bei Schlüsselkonflikten (z. B. Primärschlüssel-Kollisionen) kann XDM je nach Task-Definition Datensätze ersetzen, verwerfen oder mit neuen Schlüsseln einfügen.

Ja. Über Modifications lassen sich Werte für Spalten berechnen, die ausschließlich im Ziel vorhanden sind. Das Anlegen neuer Spalten selbst ist kein Teil des Ladevorgangs; Unterschiede werden erkannt (siehe Strukturvergleich), die Befüllung erfolgt, sobald die Spalten im Ziel existieren.

Mit einem Row-Level-Delete-Task kann XDM Datensätze anhand frei definierbarer Startbedingungen löschen, z. B. „älter als Datum“. Der Task kann für alle relevanten Systeme/Tabellen einer Umgebung ausgeführt werden.

Durch identische Modifications auf allen betroffenen Spalten und Systemen. XDM wendet die gleiche Regel konsistent an, sodass die Änderungen übergreifend einheitlich sind.

Ja. XDM kann gezielt Testdaten adressieren und löschen – wahlweise einzelne Zeilen oder zusammenhängende Datensätze über mehrere Tabellen hinweg.

Ja. Der RLP Delete Task löscht gezielt Daten mitsamt ihren Beziehungen; die Selektion erfolgt typischerweise im Ziel. Alternativ können Sie die Selektion in der Quelle ausführen, die Schlüssel in einer Datei speichern und diese Datei als Eingabe für den RLP Delete Task im Ziel verwenden.

Standardmäßig stellt XDM Ergebnisse über Custom Task Reports bereit, die in der Task Execution angezeigt und als CSV exportiert werden können. Zusätzlich können Extract-Data-Regeln ausgewählte Objekte (z. B. Kunden/Verträge) bereits bei der Selektion in CSV-Dateien schreiben. Eine vollständige Ablage von Daten in Dateien ist in XDM möglich, muss jedoch projektspezifisch konfiguriert werden. Ob JSON als Ausgabeformat genutzt werden kann, hängt von dieser individuellen Konfiguration ab.

Ja. Es gibt technische Logs und Reports sowie kundenbezogene Reports auf Applikationsebene als Zusammenfassung, z. B. welche Partner mit welchen Partnernummern final erzeugt wurden.

Ja. In XDM über Task-Execution-Reports, die sogenannte Classification Terms (z. B. Kontonummer, Personennummer) verfolgen und nachvollziehbar machen, welche Daten wann in welche Umgebung durch welchen Kopierauftrag geflossen sind.

Ja. In XDM wird die Laufzeit einer Kopie in der Oberfläche angezeigt; Detailinformationen finden sich in den Task-Logs.

Ja. Für jeden Tasklauf erstellt XDM eine Task Execution mit Reports und Logs, in der unter anderem die Startzeit protokolliert wird. Der konkrete Datenumfang (extrahierte bzw. importierte Daten) kann über eigene Reports dokumentiert werden.

XDM unterstützt zentrale Verzeichnis- und SSO-Dienste wie LDAP/Active Directory sowie OAuth2/OpenID Connect (z. B. Keycloak). Die Authentifizierung und Autorisierung erfolgt serverseitig über den angebundenen Identitätsdienst; clientseitige Zugriffskontrollen werden nicht eingesetzt.

Ja. SSO über OAuth2/OpenID Connect (z. B. Keycloak) wird unterstützt. MFA wird über den angebundenen Identitätsanbieter realisiert, sofern dieser MFA bereitstellt.

In typischen Setups werden keine Passwörter in XDM gespeichert, da die Anmeldung über LDAP/AD bzw. OpenID Connect erfolgt. Zugangsdaten zu technischen Verbindungen (z. B. Datenbanken) werden verschlüsselt in der XDM-Datenbank abgelegt und können jederzeit rotiert/ersetzt werden.

Ja. Mit dem integrierten Rollen- und Rechtemanagement lassen sich Lese-, Änder- und Ausführungsrechte fein granular vergeben. So kann z. B. das Testautomations-Team Save/Load/Unload sowie Skriptänderungen getrennt und eigenständig durchführen. Nutzer sehen nur die Objekte, für die sie berechtigt sind.

Ja. Über das Rechtemanagement können Verbindungen zu Datenbanken sowie die dazugehörigen Kopier-/Exportaufträge gezielt einzelnen Rollen bzw. Benutzergruppen zugewiesen werden.

Ja. Über die Reservierungsfunktion können Daten für Testzeiträume temporär oder global dauerhaft gegen Überschreiben durch XDM gesperrt werden.

Ja. Jedes Objekt besitzt eine Historie, die geänderte Attribute mit Zeitstempel sowie die ausführenden Benutzer ausweist. Logins werden protokolliert; fehlgeschlagene Anmeldungen können bei Nutzung eines externen OpenID-/SSO-Providers dort nachvollzogen werden.

Ja. JWTs werden mit SHA‑256 signiert, haben ein Ablaufdatum und enthalten keine sensiblen Daten (nur den Benutzernamen).

Ja. Endanwender sehen keine technischen Detailfehler. Detaillierte Fehlermeldungen und Logs sind nur für berechtigte Rollen einsehbar. Debug-Ausgaben sind standardmäßig deaktiviert und können bei Bedarf über den Log-Level gezielt aktiviert werden.

Die Weboberfläche cached Seitenanforderungen. Bei Zugriff auf Produktionsdaten können Requests im Cache landen. Empfohlen ist die Konfiguration geeigneter Anti-Caching-Header bzw. die Deaktivierung von Browser/Proxy-Caching für sensible Bereiche.

Ja. XDM-Komponenten werden in getrennten Docker-Containern betrieben. Die produktive Infrastruktur wird vom Kunden betrieben; der Anbieter betreibt keine Kundensysteme (kein Managed Service).

Zwischen Diensten werden nur erforderliche Anmeldedaten ausgetauscht und diese transportverschlüsselt. Vertrauliche Anwendungsdaten werden nach den CoC-Regeln anonymisiert verarbeitet/zwischengespeichert. Zugangsdaten werden verschlüsselt abgelegt und können über die Weboberfläche oder per Bulk-Änderung rotiert werden.

Grundsätzlich sollen Produktionsdaten nicht in Nicht-Produktionsumgebungen verwendet werden. Es existiert jedoch ein mit dem Datenschutz abgestimmtes Ausnahmeverfahren, nach dem in Incident-Fällen Klardaten aus Produktion für maximal zwei Wochen in eine Testumgebung zur Fehleranalyse geladen werden dürfen.

Die XDM Weboberfläche ist für mobile Endgeräte optimiert und ermöglicht die Bedienung und Nutzung von XDM über mobile Endgeräte.

Es werden regelmäßige CVE-Prüfungen durchgeführt. Ein automatisierter Prozess aktualisiert Drittbibliotheken auf geprüfte aktuelle Versionen. Zusätzlich kommt statische Codeanalyse (z. B. SonarQube) bei jeder Codeänderung zum Einsatz, um unsichere APIs/Funktionen zu vermeiden.

Externe Komponenten und Bibliotheken werden inventarisiert, auf bekannte Schwachstellen geprüft und auf unterstützte, aktuelle Versionen gebracht. CVE-Prüfungen laufen regelmäßig; Updates erfolgen automatisiert. Formale VA/PT durch Dritte erfolgen nach Kundenanforderung; vor Go‑Live bzw. bei Major Changes sind kundenseitige Tests üblich.

Der Prozess ist vertraglich im General Framework Agreement geregelt.

Die Einhaltung relevanter Standards (z. B. ISO 27001/NIST für Informationssicherheit, ISO 22301 für Business Continuity oder gleichwertig) ist vertraglich zugesichert. Interne Datenverarbeitung entspricht nationalen Vorgaben; eingesetzte Drittdienste (z. B. Jira) hosten in der EU und erfüllen deutsche/europäische Standards.

Nein. Wir erhalten und verarbeiten keine personenbezogenen Daten von Kunden im Rahmen des Produkts/Services.

Das General Framework Agreement regelt den Export der Daten in gängigen Formaten (z. B. CSV), die sichere Rückgabe sowie die anschließende revisionssichere Löschung/Vernichtung nach Best Practices (inkl. Nachweis und geeigneter Verfahren bei Medienentsorgung).

Ja. Anforderungen an die physische Sicherheit (z. B. Zutrittskontrollen, Umweltschutz) sind im General Framework Agreement geregelt.

Ja. XDM unterstützt externe SSO-/IdP-Systeme (OpenID Connect/OAuth2). Für die Prüfung der Kompatibilität benötigen wir die konkreten Details Ihres IdP (z. B. Protokoll/Flows, Claims, Endpunkte).

XDM unterstützt nativ Db2 for z/OS, Db2 LUW, Db2 for i, Oracle Database, Microsoft SQL Server, PostgreSQL und IMS. Weitere Systeme können über eine generische JDBC-Schnittstelle eingebunden werden, sofern das Quellsystem JDBC unterstützt. Daten aus unterschiedlichen Systemen lassen sich in Beziehung setzen und gemeinsam kopieren.

Ja, über unseren Partner EPI-USE (https://www.epiuselabs.com). EPI-USE bietet im SAP-Bereich Funktionen wie Testdatenbereitstellung, Selektion und Maskierung, die unserem Ansatz im Non-SAP-Umfeld entsprechen.

Immer wieder werden wir gefragt, warum unsere XDM-Lösung keinen nativen Support für SAP bietet, obwohl SAP Datenbanken per JDBC Zugriff ermöglichen.

Ja. XDM arbeitet auf allen unterstützten Datenbanksystemen nach demselben Prinzip. Für Zielsysteme gelten die gleichen Voraussetzungen wie für Quellsysteme.

XDM wird containerisiert bereitgestellt (Docker oder Podman) und läuft auf einem Linux-Server. Alternativ kann die Bereitstellung per Helm-Chart auf Orchestrierungsplattformen wie Kubernetes oder OpenShift erfolgen.

XDM wird ausschließlich als On-Premises-Lösung angeboten; sämtliche Daten verbleiben jederzeit auf den Servern der Kundschaft. Eine Installation in einer privaten Cloud-Umgebung ist möglich. Ein SaaS-Betrieb wird nicht angeboten. Der Betrieb hinter einer Diode-Firewall ist nicht abschließend bewertet und sollte im Rahmen eines PoC geprüft werden.

Ja. XDM kann per Helm-Chart in Kubernetes/OpenShift integriert werden; entsprechende Informationen stellen wir bei Bedarf bereit.

Erforderlich ist ein Linux-System, auf dem Docker installiert werden kann. Detaillierte Hardwarevoraussetzungen finden Sie im Handbuch: https://products.ubs-hainer.com/docs/XDM3/0283489234786435/current/manual/Setup/Planning/Requirements.html

XDM verwendet eine PostgreSQL-Datenbank ab Version 11 als Administrationsdatenbank. Diese kann als interner Docker-Container mitgeliefert oder als externe PostgreSQL-Instanz angebunden werden. Darin werden u. a. Tasks, Metamodelle, Konfigurationsdaten und Logs gespeichert.

Die Provisionierung erfolgt je nach System über native Utilities (z. B. Unload/Load), FTP sowie DML/DDL. Zielsysteme unterscheiden sich in der Verwendung durch XDM nicht von Quellsystemen; die gleichen Voraussetzungen gelten. Bei BCV4 wird als Ziel stets ein komplettes Db2-Subsystem bzw. eine Data-Sharing-Group durch eine 1:1-Kopie des Quellsystems ersetzt.

Eine Grundkonfiguration ist enthalten, für den produktiven Einsatz sind jedoch projektspezifische Parametrisierung und Customizing erforderlich.

Arbeitsaufträge (Jobs) werden komfortabel über die Browser-Oberfläche verwaltet. Alle Objekte (z. B. Credentials, Verbindungen) werden als wiederverwendbare Objekte angelegt. Alternativ steht eine API sowie ein Command-Line-Interface zur Verfügung. Während der Ausführung erzeugt jeder Job Logs und Reports mit technischen Details (z. B. verwendete Tabellen, Verfremdungsmethoden); diese können exportiert, importiert oder direkt im Tool ausgewertet werden, etwa für Audits.

Für Monitoring kann XDM in gängige Lösungen wie Checkmk oder Nagios eingebunden werden. Für Logging ist eine Anbindung an Loki möglich; Reporting-Tabellen können z. B. in Grafana visualisiert werden.

Alle für den Betrieb von XDM erzeugten administrativen und Konfigurationsdaten liegen in der PostgreSQL-Datenbank und können mit den Bordmitteln von Docker/PostgreSQL gesichert werden. Bei BCV4 werden die relevanten Informationen über die reguläre Sicherung der ISPF-Tabellen (ISPTLIB) und optional der Work-Datasets gesichert; Work-Datasets können bei Bedarf jederzeit neu erzeugt werden.

Die Einhaltung von SLAs hängt von der Bereitstellung ausreichender Ressourcen und der jeweiligen Infrastruktur ab. Werden dem Tool die benötigten Ressourcen zugewiesen, können die vereinbarten SLAs je Umgebung erreicht werden.

Ja. Releases ab 2025 entsprechen den Anforderungen der BITV 2.0 (Barrierefreie-Informationstechnik-Verordnung).

Entwicklung, Vertrieb und Support kommen aus einer Hand in Deutschland. Wir verfügen über langjährige Erfahrung, bieten zeitnahen, kundenorientierten Support sowie regelmäßige Customer Reviews zu Neuerungen und Best Practices. Auf Wunsch stellen wir Personentage-Kontingente für Schulung, Implementierung oder projektnahe Mitarbeit bereit.

Es steht eine Mietlizenzen zur Verfügung. Die Nutzung ist unternehmensweit möglich und nicht an kopierte Datenmengen gebunden. Bei XDM richtet sich der Preis nach den benötigten XDM-Komponenten, den einzusetzenden DBMS, den Benutzern, der produktiven Datenmenge.

Nein. Die Produkte sind unternehmensweit nutzbar und upgradefrei; für die beschriebenen Produktumfänge fallen keine zusätzlichen, nutzungsabhängigen Lizenzgebühren an.

Ja. Auf Wunsch unterstützen wir mit Personentagen für Implementierung, Beratung oder Schulung. Abrechnung nach tatsächlichem Verbrauch. Preise zzgl. gesetzlicher MwSt.

Ja. Das Produkt kann bis zu 30 Tage kostenlos installiert und getestet werden. Für einen strukturierten POC/Piloten mit definierten Use Cases empfehlen wir eine begleitende, kostenpflichtige Beratung und die entsprechende POC-/Pilot-Lizenz (siehe Kostenangaben).

Der Aufwand hängt stark von den Use Cases ab (reines Klonen/Kopieren ist deutlich schneller als Modifizierung wie Anonymisierung/Pseudonymisierung oder Generierung synthetischer Daten). Erfahrungswerte für XDM: ca. 20 Personentage Unterstützungsleistung. Kosten: 1.200 EUR pro Personentag (Abrechnung nach Verbrauch) plus pauschal 30.000 EUR für die POC-/Pilot-Lizenz, die bei späterer Lizenzierung angerechnet wird. Gesamtkosten = benötigte Personentage x 1.200 EUR + 30.000 EUR (zzgl. gesetzlicher MwSt.). Hinweis: Ein vorangegangener POC reduziert in der Regel den Aufwand im Pilot, da auf Ergebnissen aufgebaut wird.

Nein. Installation und Support sind in den allgemeinen Kosten für POC und Pilot enthalten; separate Gebühren fallen dafür nicht an. Auch mehrere Installationen (z. B. POC und Pilot) innerhalb der Testphase sind damit abgedeckt.

Der Aufwand hängt von Aufgabenstellung, Anzahl und Komplexität der Anwendungen ab. Klonen/Kopieren ist schneller als selektives Kopieren mit Modifikation. Erfahrungswerte für XDM: ca. 20 Tage pro Anwendung – sowohl für eine Testversion in der Entwicklungsumgebung als auch für die Umsetzung in Produktion. POC Zeit 4-6 Wochen, Pilot 8-12 Wochen. Umsetzung der wichtigsten Anwendungsfälle in Produktion typischerweise 6-12 Monate.

Offizielle Supportzeiten: Montag bis Freitag, 8–17 Uhr. Supportanfragen werden stets von einer zugewiesenen Ansprechperson betreut.

Die Performance wird im Rahmen des POC auf den Kundensystemen ermittelt. Aufgrund der vielfältigen Einflussfaktoren und Konfigurationsmöglichkeiten lassen sich keine allgemeingültigen Aussagen vorab treffen. Exemplarische Laufzeiten:

Unser Unternehmen setzt umfangreiche organisatorische und technische Maßnahmen zur Gewährleistung der Datensicherheit gemäß relevanten regulatorischen und gesetzlichen Anforderungen um. Zum aktuellen Zeitpunkt verfügen wir jedoch über keine Zertifizierungen nach gängigen Standards wie ISO 27001, ISO 22301, ISO 9001, ISO 14001, SOC2 oder BSI Grundschutz.

XDM wird als Webanwendung auf Basis von Docker-Containern ausgeliefert und kann on‑premises oder in privaten Cloud-Umgebungen (z.B. Kubernetes / OpenShift) betrieben werden. Updates werden zentral eingespielt und die Konfigurationsdatenbank wird dabei automatisch migriert. Durch Containerisierung ist eine klare Trennung zwischen Produkt-Updates und kundenspezifischer Infrastrukturkonfiguration gegeben.

Ja. Über ein flexibles, objektbasiertes Berechtigungskonzept mit Rollen, Gruppen, ACLs und vererbbaren Rechten können mehrere Organisationseinheiten, Anwendungen und Teams eine gemeinsame XDM‑Instanz nutzen, ohne sich gegenseitig einzuschränken. Die Anbindung an Unternehmensverzeichnisse (LDAP, OpenID/OAuth2‑IDP) ermöglicht die Integration in bestehende IAM‑Strukturen.

XDM stellt ein vorkonfiguriertes Grafana‑Dashboard zur Verfügung, das Systemmetriken (CPU, Speicher, Plattenplatz) sowie interne Kennzahlen zur Nutzung der Testdatenbereitstellung und Taskdurchführung visualisiert. Über ein Systemdashboard können Ressourcenengpässe analysiert und Optimierungspotenziale identifiziert werden. Darüber hinaus bietet XDM umfangreiche Protokollierung zu Logins, Konfigurationsänderungen, Ausführungen und Workflows.

Die XDM‑Services laufen in Docker‑Containern und können in Kubernetes‑Umgebungen horizontal skaliert werden, um den benötigten Durchsatz für Testdatenbereitstellungen zu erreichen. Ressourcen für Task‑Ausführung und Datenverarbeitung lassen sich je nach Lastsituation dynamisch anpassen.

UBS Hainer GmbH betreibt ein Informationssicherheitsmanagement, das sich an etablierten Standards (z.B. ISO 27001, NIST) orientiert, ohne derzeit formal zertifiziert zu sein. Es existieren interne Richtlinien, Prozesse und Kontrollen u.a. zu Zugriffskontrolle, Betriebssicherheit, Patch‑Management, Schwachstellenmanagement, Schulungen sowie physischen und organisatorischen Schutzmaßnahmen. Zugriffsrechte werden nach dem Need‑to‑know‑Prinzip mit formalen Prozessen für Provisionierung, Änderung und Entzug vergeben.

Für Kunden aus dem Finanzsektor werden vertraglich definierte Sicherheitsanforderungen (u.a. zu Governance, Risiko‑ und Compliance‑Management, Incident‑Management, Penetrationstests, Patch‑Management und Schulung) abgedeckt. Der Anbieter verpflichtet sich, regulatorische Anforderungen des Kunden (einschließlich Prüf‑ und Auditrechten, Meldepflichten zu Sicherheitsvorfällen und Anforderungen an Subdienstleister) im Rahmen der jeweiligen Verträge umzusetzen. Auf Nachfrage werden sicherheitsrelevante Informationen, Fragebögen und Nachweise bereitgestellt; Audits und Security Assessments durch den Kunden oder beauftragte Dritte werden unterstützt.

XDM ist eine Standardsoftware, die in der Regel in der Infrastruktur des Kunden betrieben wird; produktive oder personenbezogene Daten verbleiben beim Kunden. Der Anbieter erhält ohne gesonderten Vertrag keinen Zugriff auf Produktivdaten des Kunden und betreibt selbst keine Kundensysteme im Produktivbetrieb.

Soweit Subdienstleister eingesetzt werden (z.B. für Entwicklungs‑ oder Collaboration‑Werkzeuge), werden diese sorgfältig ausgewählt und an vertraglich fixierte Sicherheits‑ und Datenschutzanforderungen gebunden. Personenbezogene Daten von Kunden werden vom Anbieter grundsätzlich nicht verarbeitet; für etwaige abweichende Szenarien werden individuelle vertragliche Regelungen (inkl. Datenverarbeitungsverträgen) abgeschlossen.

Es werden regelmäßig Schwachstellenprüfungen (CVE‑Checks) auf eingesetzte Komponenten und Bibliotheken durchgeführt; ein automatisierter Prozess aktualisiert Dritthersteller‑Bibliotheken auf aktuelle Versionen. Web‑, Anwendungs‑ und Build‑Umgebungen werden mit sicherheitsrelevanten Patches aktuell gehalten. Bei Bedarf werden Ergebnisse von Schwachstellenanalysen oder Penetrationstests gegenüber Kunden offengelegt.

Aktuell liegen keine formalen Zertifizierungen nach ISO 27001, ISO 22301, ISO 9001, ISO 14001 oder BSI‑Grundschutz vor. Die internen Prozesse und Richtlinien zur Informationssicherheit orientieren sich jedoch an diesen etablierten Standards und werden kontinuierlich weiterentwickelt.

Ja. Der gezielte Erwerb von Zertifizierungen wie ISO 27001 wird geprüft, um das bestehende Sicherheitsniveau extern bestätigen zu lassen und Transparenz gegenüber Kunden zu erhöhen. Bis dahin werden Sicherheitsanforderungen kundenseitig durch vertragliche Regelungen, Fragebögen, Prüfungen und externe Nachweise (z.B. Datenschutz‑Testate) adressiert.

Entwicklung, Wartung und Support von XDM erfolgen durch die UBS Hainer GmbH in Deutschland. Es werden etablierte Entwicklungsprozesse mit Versionsverwaltung (Git), Code‑Review, Build‑Pipelines und automatisierten Tests eingesetzt. Die Entwicklung folgt dem Prinzip „Configuration as Code“: Konfigurationen werden versioniert, änderbar und nachvollziehbar in Git verwaltet.

Es existiert eine sichere Programmier‑ und Entwicklungsrichtlinie; Code‑Änderungen werden verpflichtend durch mindestens einen weiteren Entwickler reviewed. Für jede Änderung kommen statische Code‑Analysen (z.B. SonarQube) zum Einsatz, um unsichere oder veraltete Funktionen und Bibliotheken aufzudecken. Unsichere oder veraltete Technologien werden vermieden; Build‑/Deployment‑Pipelines laufen auf gehärteten, aktuell gehaltenen Plattformen.

Quellcode und Konfigurationen werden zentral in Git verwaltet; jede Änderung ist über Historie und Commits nachvollziehbar. Zugriffe auf die Repositories sind rollenbasiert beschränkt, Quellcode‑Systeme werden regelmäßig gesichert und gegen unbefugten Zugriff geschützt.

XDM protokolliert Logins, Konfigurationsänderungen und wesentliche Aktionen; für Konfigurationsobjekte steht eine Historie mit den letzten Änderungen und den jeweiligen Benutzern zur Verfügung. Darüber hinaus kann die Event‑API genutzt werden, um zusätzliche, kundenspezifische Audit‑ und Benachrichtigungsprozesse (z.B. E‑Mail, Messaging‑Systeme) zu implementieren.

XDM lässt sich an zentrale Unternehmensverzeichnisse und Identity‑Provider (LDAP, OpenID/OAuth2) anbinden, sodass bestehende Policies für Authentifizierung, Passwörter und Rollen genutzt werden können. Das Prinzip der minimalen Rechte („Least Privilege“) wird durch das Rollen‑ und Berechtigungsmodell unterstützt; sensible technische Details können gegenüber Fachanwendern ausgeblendet werden.