Ein Logistikoffizier auf Bataillonsebene fordert einen Einsatzbereitschaftsbericht an. Das C2-System führt 47 der Einheit zugeordnete Fahrzeuge auf. Das Materialbuchführungssystem verzeichnet 51 Fahrzeuge unter derselben Einheitskennung. Das Instandhaltungssystem verfolgt 44 dieser Fahrzeuge unter abweichenden Seriennummernformaten, und drei sind unter Kennungen als nicht einsatzfähig (deadlined) markiert, die in keinem der beiden anderen Systeme vorkommen. Niemand kann die Frage „Wie viele einsatzfähige Fahrzeuge hat diese Einheit gerade?“ ohne einen Telefonanruf beantworten – weil dieselben physischen Entitäten in Systemen, die nie darauf ausgelegt waren, miteinander übereinzustimmen, durch unterschiedliche Datensätze, unterschiedliche Kennungen und unterschiedliche Attributwerte repräsentiert werden.
Das ist das MDM-Problem im Verteidigungsbereich in seiner häufigsten Form. Stammdatenmanagement (MDM) ist die Disziplin, die für jede Kernentität – Person, Organisation, Ausrüstung, Standort – eine einzige maßgebliche Repräsentation schafft, auf die alle Systeme konsistent verweisen. Es ist weder ein Reporting-Werkzeug noch ein Data Warehouse. Es ist die Schicht, die systemübergreifende Joins aussagekräftig, domänenübergreifende Analytik vertrauenswürdig und auf Daten gestützte operative Entscheidungen verlässlich macht. Dieser Artikel behandelt die Architektur eines MDM-Systems für die Verteidigung – von der Auswahl des Hub-Modells über Entity Resolution, den Aufbau des Golden Record und Stewardship-Workflows bis zu den Anforderungen an die Überlebensfähigkeit, die MDM in umkämpften Umgebungen praktikabel machen.
Das MDM-Problem im Verteidigungsbereich – Ausrüstungsdatensätze in drei Systemen mit drei verschiedenen IDs, auseinanderlaufende Personaldatensätze zwischen HR und C2, die Kosten der Inkonsistenz
In Verteidigungsorganisationen wächst die Fragmentierung der maßgeblichen Datenquellen (Source of Truth) organisch. Das HR-System wurde zur Personalverwaltung beschafft. Das C2-System wurde gebaut, um Einheitsstrukturen und taktische Zuordnungen zu verfolgen. Das Logistiksystem wurde für die Verwaltung von Versorgung und Materialbuchführung entworfen. Jedes wurde von einem anderen Programmbüro konzipiert, in einem anderen Jahrzehnt eingeführt und nutzt ein anderes Datenmodell. Keines wurde dafür ausgelegt, mit den anderen auf der Ebene der Entitätsidentität zusammenzuarbeiten.
Das Ergebnis ist eine Menge von Kennungsschemata, die von Grund auf inkompatibel sind. Eine Person kann im HR-System über ihre Personalnummer identifiziert werden, im C2-System über die Kombination aus Kennung der militärischen Fachverwendung und Dienstgrad und in der Logistik über ihre Kennung als Ausrüstungsverwalter – drei Kennungen für einen einzigen Menschen, ohne systemseitig gepflegte Zuordnung zwischen ihnen. Bei Ausrüstung ist es schlimmer: Ein Kampfpanzer M1A2 kann eine auf den Rumpf schablonierte Bumper-Nummer tragen (von Besatzung und C2-Bedienern verwendet), in der Logistik einen Department-of-Defense-Activity-Address-Code, im Materialbuchführungssystem einen Barcode mit einem Unique Item Identifier (UII) und im Instandhaltungsmanagementsystem eine Instandhaltungsauftragsnummer. Keine dieser Kennungen hat dasselbe Format, und die Systeme, die sie verwenden, wurden nicht dafür gebaut, zwischen ihnen zu übersetzen.
Die Kosten dieser Inkonsistenz sind nicht bloß Unannehmlichkeiten. Wenn ein Analyst für Einsatzbereitschaft C2-Einheitszuordnungsdaten mit Logistik-Versorgungsdaten verknüpft, um den operativen Fähigkeitswert einer Einheit zu berechnen, findet der Join keine Übereinstimmung zwischen Datensätzen, die sich unter unterschiedlichen Kennungen auf dieselbe physische Ausrüstung beziehen. Der resultierende Fähigkeitswert ist falsch – und zwar in einer Richtung, die der Analyst nicht erkennen kann, ohne jedes System unabhängig zu überprüfen, was den Zweck des Analysemodells aushebelt. Eine integrierte Sicht darauf, wie sich diese Integrationsfehler in der übergreifenden Datenarchitektur äußern, finden Sie in unserer Darstellung der Datenintegrationsmuster im Verteidigungsbereich.
Das Auseinanderlaufen der Personaldatensätze zwischen HR und C2 ist ein zusätzliches, eigenständiges Problem. Das HR-System führt den administrativen Datensatz: ständiger Dienstgrad, Dienstposten, zugeordnete Einheit, Freigabestufe, Ausbildungshistorie. Das C2-System führt das operative Bild: welche Person sich physisch bei welcher Einheit befindet, welche Rolle sie in der aktuellen Einsatzgliederung ausfüllt und welche Systeme sie bedienen darf. Unter stabilen Garnisonsbedingungen stimmen diese Datensätze weitgehend überein. In Einsätzen – wenn Personal anderen Einheiten unterstellt wird, wenn die Einsatzgliederung von der Stärke- und Ausrüstungsnachweisung (TO&E) abweicht, wenn befristete Dienstverwendungen Zweitzuordnungen erzeugen – laufen die beiden Datensätze schnell auseinander. Ein MDM-System, das die Personenentität verwaltet, muss die administrative und die operative Darstellung zu einem kohärenten Golden Record abgleichen, der sowohl für die Berichterstattung zur Einsatzbereitschaft als auch für die operative Planung nutzbar ist.
MDM-Hub-Architektur – Registry-, Konsolidierungs- und Koexistenz-Hub-Modelle im Vergleich, Auswahlkriterien für Verteidigungsumgebungen, Hub-Platzierung für eingestufte und nicht eingestufte Daten
Drei Hub-Modelle dominieren produktive MDM-Einsätze, jedes mit einem eigenen Verhältnis zu den Quellsystemen, die es bedient, und mit eigenen betrieblichen Zielkonflikten, die in Verteidigungsumgebungen eine Rolle spielen.
Das Registry-Modell speichert nur die Querverweistabelle – eine Zuordnung jeder Kennung eines Quellsystems zur vom MDM vergebenen globalen Entitäts-ID –, ohne Entitätsattribute im Hub selbst zu replizieren oder zu speichern. Benötigt ein Konsument Entitätsdaten, fragt er beim Hub die globale ID ab und anschließend die passenden Quellsysteme anhand der quellspezifischen Kennungen, die der Querverweis liefert. Das Registry-Modell hat den geringsten Datenumfang und erfordert keine Synchronisation von Attributdaten in den Hub, was es für Umgebungen attraktiv macht, in denen die Replikation eingestufter Daten an einen zentralen Ort Autorisierungsprobleme aufwirft. Seine Einschränkung besteht darin, dass jeder Konsument Entitäten zur Abfragezeit über mehrere Quellsysteme hinweg auflösen muss, was für hochfrequente operative Abfragen betrieblich unpraktikabel ist.
Das Konsolidierungsmodell kopiert und normalisiert die Entitätsattribute aller beitragenden Quellsysteme in den Hub, führt eine Entity Resolution zur Verknüpfung von Duplikaten durch und stellt den Konsumenten eine einheitliche Entitätssicht bereit. Die Quellsysteme werden nicht verändert – der Hub ist ein leseoptimierter Konsument der Quelldaten, kein Schreiber zurück in sie. Dieses Modell ist für Verteidigungsumgebungen am praktikabelsten, weil es keine Änderungsrechte an den Quellsystemen erfordert (C2-, HR- und Logistiksysteme sind vom MDM-Programm in der Regel nicht änderbar) und die Rechenlast der Entity Resolution im Hub bündelt, statt sie auf die Konsumenten zu verteilen. Die militärische Data-Lake-Architektur nutzt die Golden Records des MDM-Konsolidierungs-Hubs typischerweise als kuratierte Referenzschicht, statt rohe Quelltabellen direkt zu verknüpfen.
Das Koexistenzmodell erweitert das Konsolidierungsmodell um eine Rückschreibfähigkeit: Der Hub baut den Golden Record auf und überträgt die maßgeblichen Attributwerte anschließend zurück in die Quellsysteme, wobei lokal gepflegte Werte durch den vom Hub ermittelten maßgeblichen Wert überschrieben werden. Dieses Modell erzeugt die stärkste Konsistenz über Systeme hinweg, erfordert aber, dass jedes beteiligte Quellsystem vom Hub initiierte Schreibvorgänge akzeptiert – eine Anforderung, die häufig an Autorisierungsbeschränkungen der Systeme, Änderungskontrollprozessen der Hersteller und der betrieblichen Risikoscheu bei produktiven Systemen scheitert.
Die Hub-Platzierung für eingestufte und nicht eingestufte Daten erfordert an jeder Einstufungsgrenze getrennte Hub-Instanzen. Ein einziger MDM-Hub, der sowohl eingestufte als auch nicht eingestufte Entitätsdaten verarbeitet, müsste auf der höheren Geheimhaltungsstufe betrieben werden, wodurch nicht eingestufte Konsumenten keinerlei Entitätsdaten aus dem Hub abrufen könnten – was seinen Zweck zunichtemachen würde. Die praxistaugliche Architektur setzt einen nicht eingestuften Hub für Entitäten ein, die ausschließlich in nicht eingestuften Quellsystemen existieren (allgemeine Referenzdaten, nicht eingestufte Standortdaten, kommerzielle Lieferantendatensätze), und einen eingestuften Hub auf der passenden Geheimhaltungsstufe für Entitäten mit eingestuften Attributen. Eine stufenübergreifende Entity Resolution – die Feststellung, dass eine Entität im nicht eingestuften System derselben physischen Entität in einem eingestuften System entspricht – erfordert einen spezialisierten Cross-Domain-Solution-Guard, der nur den Kennungs-Querverweis über die Einstufungsgrenze trägt, niemals die eingestuften Attribute selbst.
Entitätstypen im MDM für die Verteidigung – Person (militärisches Personal), Organisation (Einheit/Kommando), Ausrüstung (Plattform/Endgegenstand), Standort (Einrichtung/Position)
Das MDM im Verteidigungsbereich verwaltet vier primäre Entitätsdomänen, jede mit eigenen Quellsystemen, Kennungsschemata, Attributstrukturen und Datenqualitätsherausforderungen.
Die Domäne der Personenentität umfasst militärisches Personal, Auftragnehmer und Koalitionspartner. Die wichtigsten Quellsysteme sind das Personalverwaltungssystem (administrativer Datensatz, ständige Zuordnung, Dienstgrad), das C2-System (aktuelle operative Zuordnung, Position in der Einsatzgliederung) und das Freigabeverwaltungssystem (Freigabestufe, Compartment-Berechtigungen, Ablaufdaten des Zugangs). Die zentrale Herausforderung bei den Kennungen besteht darin, dass dieselbe Person im HR-System unter ihrer Stammeinheit erscheinen kann, während sie im C2-System operativ einer anderen Einheit unterstellt ist – beide Datensätze sind in ihren jeweiligen Systemen korrekt, repräsentieren aber zwei verschiedene operative Zustände derselben Entität. Der Aufbau des Golden Record für die Personendomäne muss den administrativen und den operativen Zustand als getrennte Attributgruppen erfassen, statt sie in einem einzigen Feld für die Einheitszuordnung zusammenzufassen.
Die Domäne der Organisationsentität umfasst Einheiten, Kommandos, Teileinheiten und Task Forces. Organisationen in Verteidigungsumgebungen haben eine hierarchische Eltern-Kind-Struktur (eine Brigade umfasst Bataillone, ein Bataillon umfasst Kompanien) und eine zeitliche Dimension (Task Forces werden gebildet, verschmelzen, gliedern sich neu und lösen sich auf, und zwar in operativen Zeiträumen). Das MDM-System muss die aktuelle Organisationshierarchie, ihre historischen Zustände zu vergangenen Zeitpunkten und die Beziehungen zwischen der administrativen TO&E-Struktur und der aktuellen operativen Einsatzgliederung pflegen. Quellsysteme sind die Einheitshierarchie im C2-System, die TO&E im Personalverwaltungssystem und der Datensatz zum Führungselement in Logistiksystemen.
Die Domäne der Ausrüstungsentität umfasst Plattformen, Fahrzeuge, Waffensysteme und Endgegenstände des Inventars. In der Praxis ist dies die am stärksten nach Kennungen fragmentierte Domäne: Ein einzelnes physisches Objekt trägt typischerweise vier oder mehr verschiedene Kennungsschemata über die Systeme hinweg, die es verwalten. Die UII (Unique Item Identifier) ist der global eindeutige Barcode-Standard des Department of Defense für serielle Ausrüstungsgegenstände und sollte als Master-Kennung der Ausrüstungsdomäne dienen, doch Altsysteme vor dem UII-Standard verwenden proprietäre Kennungen, die eine Zuordnungstabelle zur Verknüpfung mit dem UII-Raum erfordern. Das Matching über Systeme hinweg erfordert unscharfes Matching auf Seriennummernfeldern, die je nach System, das die Kennung erfasst hat, unterschiedliche Trennzeichen, führende Nullen oder Herstellercodes enthalten können.
Die Domäne der Standortentität umfasst Einrichtungen, Liegenschaften, benannte Interessengebiete und taktische Positionen. Standort-Matching ist grundlegend ein georäumliches Problem: Derselbe physische Ort kann in einem System über MGRS-Koordinaten referenziert sein, in einem anderen über geografische Dezimalgradkoordinaten und in einem dritten über einen natürlichen Ortsnamen. Georäumliches Blocking gruppiert Kandidaten-Standortdatensätze nach Nähe über ein Geohash-Raster, und das Matching bestimmt, ob sich zwei räumlich nahe Datensätze auf dieselbe Einrichtung oder auf verschiedene nahegelegene Orte beziehen. Standortentitäten haben auch eine zeitliche Dimension – Einrichtungsklassifizierung, Betriebsstatus und kontrollierende Truppe ändern sich mit der Zeit –, weshalb der Golden Record zeitliche Gültigkeitsintervalle für Schlüsselstandortattribute tragen muss. Die Schicht der Echtzeit-Intelligence-Fusion, die ISR-Erkennungen gegen bekannte Standorte korreliert, hängt unmittelbar von der Genauigkeit und Vollständigkeit des Standort-Entity-Master ab.
Entity Resolution: Matching über Quellsysteme hinweg – Blocking-Strategien für große Verteidigungs-Entitätsmengen, ML-Matching-Modelle, deterministisches versus probabilistisches Matching
Entity Resolution ist der Prozess, der bestimmt, welche Datensätze über Quellsysteme hinweg dieselbe reale Entität betreffen, und sie unter einer gemeinsamen globalen Kennung verknüpft. Im Maßstab eines großen Verteidigungsdatensatzes – Millionen von Ausrüstungsdatensätzen aus Logistik-, Instandhaltungs- und Materialbuchführungssystemen; Hunderttausende von Personaldatensätzen aus HR-, C2- und Freigabesystemen – ist der naive paarweise Vergleich aller Datensätze untereinander rechnerisch nicht durchführbar. Die Matching-Pipeline muss als zweistufiger Prozess aufgebaut sein: Blocking, das den Raum der Kandidatenpaare auf eine handhabbare Größe reduziert; gefolgt von Matching, das Kandidatenpaare mit ausreichender Precision bewertet, um echte Treffer von Beinahe-Treffern zu trennen.
Blocking-Strategien für Verteidigungs-Entitätsdomänen nutzen domänenspezifische Partitionierungsschlüssel, um Datensätze zu gruppieren, die plausibel dieselbe Entität betreffen könnten. Für Personaldatensätze gruppiert phonetisches Blocking auf dem Nachnamenfeld mit dem Soundex- oder Double-Metaphone-Algorithmus Datensätze, in denen verschiedene Systeme denselben Namen mit abweichenden Schreibweisen, zusätzlichen Leerzeichen oder Unterschieden in der Bindestrichsetzung transkribiert haben – alles verbreitet in Personalverwaltungssystemen vor der Unicode-Normalisierung. Für Ausrüstungsdatensätze gruppiert Präfix-Blocking auf den ersten sechs Zeichen der Seriennummer (nach Normalisierung von Leerzeichen und Groß-/Kleinschreibung) Datensätzen aus Systemen, die dieselbe Seriennummer mit abweichenden Trennzeichenkonventionen darstellen. Für Standortdatensätze gruppiert ein Geohash-Raster auf Präzisionsstufe 6 (etwa 1,2 km Zellenbreite) räumlich nahe Datensätze und schließt offensichtlich verschiedene Orte aus. Das Blocking-Design muss vor der Bereitstellung gegen einen Gold-Standard-Datensatz bekannter Treffer validiert werden – die Blocking-Stufe muss mindestens 95 % der echten Trefferpaare im Kandidatensatz behalten, sonst erzeugt die Auflösungspipeline systematische Fehlalarme für die ausgeschlossenen Datensatztypen.
In jedem Kandidatenblock bewertet das Matching-Modell jedes Paar:
- Deterministisches Matching wendet einen festen Regelsatz an, der eine binäre Treffer-/Nicht-Treffer-Entscheidung ergibt. Eine deterministische Regel für Ausrüstungsdatensätze: Zwei Datensätze stimmen genau dann überein, wenn ihre UII-Barcodes identisch sind (nach Entfernen nicht alphanumerischer Zeichen), oder wenn ihre Seriennummern identisch sind und ihre National Stock Numbers in den ersten neun Ziffern übereinstimmen. Deterministische Regeln benötigen keine Trainingsdaten, sind vollständig auditierbar und ergeben bei korrekter Spezifikation null falsche Treffer. Sie eignen sich für Attribute, die global eindeutig sein sollen und unter Dateneingabekontrollen gepflegt werden.
- Probabilistisches Matching berechnet einen zusammengesetzten Trefferscore aus gewichteten Ähnlichkeitsmetriken auf Feldebene. Ein Personaldatensatzvergleich könnte Jaro-Winkler-Ähnlichkeit auf den Vornamen anwenden, phonetisches Matching auf den Nachnamen, exaktes Match auf das Geburtsdatum und unscharfes Matching auf die Dienstgradabkürzung (um abweichende Formatierungen zu behandeln), kombiniert mit einer logistischen Regression oder einem Gradient-Boosting-Baumklassifikator, der mit beschrifteten Treffer-/Nicht-Treffer-Paaren aus den tatsächlichen Quellsystemen trainiert wurde. Das trainierte Modell lernt die relative Bedeutung jedes Feldes in der spezifischen Umgebung verschmutzter Daten – in manchen Quellsystemen ist das Geburtsdatum hochzuverlässig; in anderen hat es eine Fehlerrate von 3 %, die es zu einem schwachen Unterscheidungsmerkmal macht.
- ML-Matching-Modelle erweitern das probabilistische Matching um gelernte Darstellungen von Entitätsattributtext. Ein Siamesisches neuronales Netz, trainiert mit Personennamenpaaren, lernt eine Vektordarstellung von Namen, sodass phonetisch oder orthografisch ähnliche Namen ähnliche Vektoren haben – es erfasst Ähnlichkeitsmuster, die handgefertigte Zeichenketten-Distanzmetriken verpassen. ML-Modelle benötigen größere beschriftete Datensätze zum Training und sind schwerer zu auditieren als deterministische Regeln, übertreffen aber klassische probabilistische Modelle bei Entitätsmengen mit hohem Rauschen, bei denen die Dateneingabefehler komplex und über die Quellsysteme hinweg nicht einheitlich sind.
Das Ergebnis der Matching-Pipeline für jedes Kandidatenpaar ist eine Trefferentscheidung (Treffer / Nicht-Treffer / Prüfung) und eine Konfidenzbewertung. Paare oberhalb des Trefferschwellenwerts werden automatisch unter einer gemeinsamen globalen Entitäts-ID verknüpft. Paare im Prüfband – bei denen die Konfidenzbewertung zwischen dem Nicht-Treffer-Schwellenwert und dem Trefferschwellenwert liegt – werden zur Entscheidung an einen menschlichen Steward geleitet, statt automatisch aufgelöst zu werden.
Aufbau und Pflege des Golden Record – Survivorship-Regeln für widersprüchliche Quellattribute, Konfidenzbewertung des Golden Record, automatisierte versus Steward-gestützte Auflösung
Sobald Entity Resolution Datensätze aus mehreren Quellsystemen unter derselben globalen Entitäts-ID verknüpft hat, konstruiert das MDM-System den Golden Record: die maßgebliche, einheitliche Darstellung dieser Entität, deren Attribute aus der jeweils besten verfügbaren Quelle für jedes Feld stammen. Der Golden Record ist keine einfache Zusammenführung aller Quellattribute – wenn sich die Quellen widersprechen, muss eine Survivorship-Regel bestimmen, welchen Wert der Golden Record trägt.
Survivorship-Regeln werden pro Attribut und Entitätsdomäne definiert und kodieren die Autoritätshierarchie für dieses Attribut:
Jedes Attribut im Golden Record trägt zusätzlich zu seinem Wert drei Metadatenfelder: eine Quellenreferenz (welches Quellsystem diesen Wert lieferte und die Kennung des konkreten Quelldatensatzes), einen Aktualisierungszeitstempel (wann das Quellsystem diesen Wert zuletzt bestätigte) und eine Konfidenzbewertung (ein normalisierter Wert, der die Zuverlässigkeit der Quelle und die Qualität des Matchings widerspiegelt, das diesen Datensatz mit der Golden-Record-Entität verknüpfte). Eine Konfidenzbewertung von 1,0 zeigt ein deterministisches Matching auf einer global eindeutigen Kennung aus einer hochzuverlässigen Quelle; niedrigere Werte spiegeln probabilistische Match-Ergebnisse, Quellen mit bekannten Datenqualitätsproblemen oder Attribute wider, bei denen die Survivorship zwischen Quellen mit widersprüchlichen Werten umstritten war.
Die Konfidenzbewertung ist keine Dekoration – sie ist betrieblich bedeutsam. Ein Einsatzbereitschafts-Analyst, der eine Fähigkeitsbewertung erstellt, kann die Golden-Record-Abfrage auf Attribute oberhalb eines Konfidenzschwellenwerts filtern, oder die Analyseebene kann den Beitrag jedes Ausrüstungsdatensatzes zum Einsatzbereitschaftswert der Einheit mit der Konfidenz seines Instandhaltungsstatus-Attributs gewichten. Ein Analyst, der eine Einsatzbereitschaftsmetrik ohne Sicht auf die zugrunde liegenden Konfidenzbewertungen erhält, kann nicht zwischen einer Bewertung mit hoher Konfidenz und einer Zahl unterscheiden, die aus Matching mit niedriger Qualität und veralteten Quelldaten zusammengebaut wurde.
Die Pflege des Golden Record ist ein fortlaufender Prozess, keine einmalige Batch-Operation. Aktualisiert ein Quellsystem einen Entitätsdatensatz, erhält die MDM-Ingest-Pipeline die Aktualisierung, bewertet die Survivorship für alle betroffenen Attribute neu und aktualisiert den Golden Record entsprechend. Führt die Aktualisierung dazu, dass sich der Golden Record bei einem Attribut ändert, das nachgelagerte Systeme bereits übernommen haben, wird eine Änderungsbenachrichtigung auf dem MDM-Ereignisbus veröffentlicht, damit konsumierende Systeme den aktualisierten Golden Record neu abfragen können. Die Änderungsbenachrichtigung trägt die globale Entitäts-ID, die Liste der geänderten Attribute und die Werte vorher/nachher – genug Information für ein konsumierendes System, um zu bestimmen, ob die Änderung seine aktiven operativen Daten betrifft, ohne den Golden Record vollständig neu abrufen zu müssen.
Data-Stewardship-Workflows – Zuweisung der Stewards nach Domäne (Ausrüstungs-Steward, Personal-Steward), Konfliktlösung-Workflow, Audit-Trail für Golden-Record-Änderungen
Automatisierte Entity Resolution und Survivorship-Regeln behandeln in einem produktiven MDM-System die Mehrheit der Matching- und Attributkonfliktfälle – typischerweise 85 bis 95 Prozent der Datensätze können ohne menschliches Eingreifen aufgelöst werden, wenn die Matching-Pipeline auf die Daten der konkreten Quellsysteme gut kalibriert ist. Die übrigen 5 bis 15 Prozent der Fälle – Treffer mit niedriger Konfidenz, umstrittene Attributwerte, bei denen mehrere Quellen gleiche Autorität beanspruchen, und Entitätssplits oder -merges, die eine Ermessensentscheidung erfordern – müssen zur Entscheidung an einen menschlichen Data Steward geleitet werden.
Stewardship ist nach Entitätsdomänen organisiert, wobei jede Domäne einem Steward zugewiesen ist, der sowohl die Fachexpertise als auch die Systemzugriffsbefugnis hält, die zur Konfliktlösung nötig sind:
- Ausrüstungs-Steward – typischerweise in der Materialbuchführung oder Logistik eingebunden, hält die Befugnis, den korrekten Ausrüstungsdatensatz zu bestimmen, wenn sich die Systeme bei Seriennummern, Einheitszuordnung oder Condition Code unterscheiden. Der Ausrüstungs-Steward hat direkten Zugang zu physischen Datensätzen und kann die Bodenwahrheit prüfen, indem er die ursprüngliche Papierakte abfragt oder sich mit Ausrüstungsverwaltern abstimmt.
- Personal-Steward – typischerweise in der HR- oder Personalverwaltung eingebunden, hält die Befugnis, widersprüchliche Namensschreibweisen, doppelte Personaldatensätze (häufig, wenn eine Person erneut eintritt und eine neue systemgenerierte Kennung erhält) und Zuordnungsabweichungen zwischen administrativen und operativen Datensätzen aufzulösen.
- Organisations-Steward – typischerweise das Stabselement J1 oder J3, hält die Befugnis, Mehrdeutigkeiten der Einheitshierarchie bei Änderungen der Einsatzgliederung aufzulösen, Datums der Aktivierung und Deaktivierung von Einheiten zu bestätigen und die Zuordnung zur übergeordneten Einheit zu entscheiden, wenn Teileinheiten vorübergehend mehreren Stäben unterstellt sind.
- Standort-Steward – typischerweise die Funktion für georäumliche Intelligence oder Liegenschaftsmanagement, hält die Befugnis zu bestätigen, ob zwei räumlich nahe Datensätze dieselbe Einrichtung oder verschiedene, am selben Ort liegende Einrichtungen darstellen, und die kanonische Koordinate und den Namen für einen Standort festzulegen, der in verschiedenen Systemen unter verschiedenen Bezeichnungen erscheint.
Der Konfliktlösung-Workflow präsentiert jeden Steward-Fall als strukturiertes Paket. Das Fallpaket enthält: die Kandidatendatensätze aus jedem Quellsystem, von denen das MDM-System annimmt, sie könnten dieselbe Entität betreffen, Feld-für-Feld-Ähnlichkeitswerte für jedes verglichene Attribut, die automatische Empfehlung des MDM-Systems (Treffer, Nicht-Treffer oder der empfohlene Gewinnerwert für ein umstrittenes Attribut) und eine klare Darstellung, wo die Quellen übereinstimmen und wo nicht. Der Steward wählt aus den verfügbaren Auflösungsoptionen – die automatische Empfehlung bestätigen, sie mit einer alternativen Auflösung überschreiben oder den Fall als zusätzliche Informationen erfordern markieren, bevor er aufgelöst werden kann. Ein Freitext-Begründungsfeld erlaubt dem Steward, die Argumentation für nicht offensichtliche Entscheidungen zu dokumentieren.
Der Audit-Trail für Golden-Record-Änderungen protokolliert jeden Zustandsübergang in der Historie des Golden Record, unabhängig davon, ob die Änderung durch eine automatische Survivorship-Aktualisierung oder eine manuelle Steward-Entscheidung ausgelöst wurde. Jeder Audit-Datensatz enthält:
- Die globale Entitäts-ID und die Entitätsdomäne
- Die geänderten Attribute und die Werte vorher/nachher für jedes
- Den Änderungsauslöser: automatische Survivorship-Regel (mit Regel-ID und Version), eingehende Quellenaktualisierung (mit Quellsystem-ID und Quelldatensatz-ID) oder Steward-Entscheidung (mit Steward-Fall-ID)
- Die authentifizierte Identität des Principals, der für die Änderung verantwortlich ist – das System-Servicekonto bei automatisierten Änderungen, die authentifizierte Identität des Stewards bei manuellen Entscheidungen
- Den Änderungszeitstempel (Wert der logischen Uhr bei verteilten Bereitstellungen, Systemuhr bei Bereitstellungen mit einem einzelnen Hub)
Audit-Datensätze werden in nur-lesbaren Speicher geschrieben und können nach dem Schreiben nicht geändert werden. Diese Unveränderlichkeit erlaubt es dem MDM-System, den vollständigen Zustand eines beliebigen Golden Record zu jedem vergangenen Zeitpunkt zu rekonstruieren, indem es den Audit-Trail von der anfänglichen Datensatzanlage ab vorwärts abspielt – eine Fähigkeit, die betrieblich notwendig ist, wenn Analysten bewerten müssen, was das MDM-System zu einem bestimmten historischen Zeitpunkt über eine Entität annahm, und eine Compliance-Anforderung für eingestufte Entitätsverwaltungssysteme.
Überlebensfähigkeit von MDM in abgekoppelten Umgebungen – lokaler MDM-Cache für vorgeschobene Systeme, Konfliktlösung bei Wiederverbindung, Eventual-Consistency-Modell für abgekoppelte Knoten
Ein zentraler MDM-Hub, der für jede Entitätsabfrage Netzwerkverbindung zum rückwärtigen Bereich braucht, ist in einer umkämpften Umgebung, in der Kommunikation beeinträchtigt oder getrennt ist, operationell unbrauchbar. Vorgeschobene C2-Systeme, Logistiksysteme und Einsatzplanungswerkzeuge hängen alle davon ab, dass Entity Resolution korrekt funktioniert – ist der MDM-Hub nicht erreichbar, müssen sie auf rohe Quellenkennungen zurückfallen, die systemübergreifend nicht passen, und das Lagebild in den vor-MDM-Zustand fragmentierter Entitätsidentität zurückführen. Das Überlebensfähigkeits-Design von MDM verhindert diese Regression, indem es einen lokalen Cache vorschoben bereitstellt und ein striktes Synchronisationsprotokoll für die Wiederverbindungsphase definiert.
Der vorgeschobene MDM-Cache ist eine vorab platzierte lesende Replik der Golden Records und der Querverweistabelle für die Teilmengen von Entitäten, die für den Einsatzbereich des vorgeschobenen Elements relevant sind. „Relevanter Bereich“ wird über zwei Dimensionen definiert: geografisches Einsatzgebiet (alle Standortentitäten im AO, alle Ausrüstungsentitäten mit letztem bekanntem Standort im AO) und Einsatzgliederung (alle Personen-, Organisations- und Ausrüstungsentitäten, die mit Einheiten in der Einsatzgliederung des vorgeschobenen Elements verbunden sind). Der Cache wird vor dem Einsatz des vorgeschobenen Elements über einen Snapshot-Export aus dem zentralen Hub befüllt. Er wird auf Hardware betrieben, die unabhängig vom Weitverkehrsnetz arbeitet – einem robustifizierten Server am vorgeschobenen C2-Knoten oder eingebettet in die Rechnerumgebung des taktischen Gefechtsstandes.
Im abgekoppelten Betrieb fragen taktische Systeme den lokalen Cache genau so ab wie den zentralen Hub – dieselbe API, dasselbe Antwortformat. Entity-Resolution-Anfragen werden aus der lokalen Querverweistabelle bedient. Golden-Record-Abfragen lieerten die zwischengespeicherten Attributwerte mit einem Aktualitätszeitstempel, der angibt, wann jedes Attribut zuletzt vom zentralen Hub bestätigt wurde. Taktische Systeme sind dafür verantwortlich, diesen Aktualitätszeitstempel den Benutzern anzuzeigen, wenn die Daten veraltet sein könnten, statt zwischengespeicherte Daten so darzustellen, als seien sie aktuell.
Alle Entitätsanlagen, -aktualisierungen, -zusammenführungen und -aufspaltungen während des abgekoppelten Zeitraums werden in ein lokales Änderungsprotokoll geschrieben – eine geordnete, begrenzte Warteschlange von Entitätsänderungsereignissen. Jedes Ereignis trägt einen Vektoruhr-Zeitstempel, der eine partielle Ordnung der Ereignisse über abgekoppelte Knoten hinweg herstellt, ohne synchronisierte Systemuhren zu brauchen. Die Kapazität des Änderungsprotokolls begrenzt die Dauer des abgekoppelten Betriebs: Ein Änderungsprotokoll, das für 72 Stunden typischer operativer Entitätsaktualisierungsraten ausgelegt ist, liefert 72 Stunden unabhängigen Betrieb, bevor die Synchronisation zwingend wird, um ein Überlaufen des Protokolls zu verhindern. Der Einsatzplanungsprozess muss diesen Rahmen berücksichtigen.
Das Wiederverbindungs-Synchronisationsprotokoll arbeitet in drei Phasen, wenn das vorgeschobene Element die Netzwerkverbindung zum zentralen Hub wiederherstellt:
Das Eventual-Consistency-Modell, das dieser Architektur zugrunde liegt, liefert eine Garantie: Nach Wiederverbindung und erfolgreichem Abschluss des Synchronisationsprotokolls halten alle Knoten der MDM-Topologie – der zentrale Hub und alle vorgeschobenen Caches – einen identischen Entitätszustand. Während eines abgekoppelten Zeitraums können die Knoten auseinanderlaufen. Das Synchronisationsprotokoll ist so entworfen, dass das Auseinanderlaufen begrenzt, erkennbar und ohne Datenverlust auflösbar ist – keine während des abgekoppelten Zeitraums vorgenommenen Entitätsaktualisierungen werden verworfen, nur umgeordnet und möglicherweise von einer Survivorship-Regel überschrieben, die die definierte Autoritätshierarchie der Organisation anwendet.
Die operative Implikation ist, dass Analysten und Systeme, die während eines abgekoppelten Zeitraums den vorgeschobenen Cache nutzen, verstehen müssen, dass sie mit einem Snapshot ungesicherter Aktualität arbeiten. Der vorgeschobene Cache sollte ein Feld „Letzter Sync-Zeitstempel“ auf Cache-Ebene und einen Zeitstempel „Zuletzt bestätigt“ auf Ebene der einzelnen Golden-Record-Attribute exponieren, damit nachgelagerte Systeme die Information haben, passende Konfidenzvorbehalte anzuzeigen, wenn operative Entscheidungen von Entitätsdaten abhängen, die der zentrale Hub nicht in letzter Zeit bestätigt hat. Eine Einsatzbereitschaftsbewertung einer Einheit auf Basis von Ausrüstungs-Golden-Records mit einem 12 Stunden alten Snapshot und 71 Stunden abgekoppeltem Betrieb verdient ein anderes Konfidenzniveau als eine, die auf Datensätzen aufbaut, die 30 Minuten vor Erstellung der Bewertung synchronisiert wurden. Diesen Unterschied in den Daten sichtbar zu machen – statt ihn hinter einer einheitlichen Darstellung der Golden-Record-Attribute zu verstecken – macht MDM in umkämpften Einsatzumgebungen nützlich statt irreführend.