Un ofițer de logistică de nivel batalion solicită un raport privind starea de pregătire. Sistemul C2 listează 47 de vehicule repartizate unității. Sistemul de evidență a bunurilor înregistrează 51 de vehicule sub același identificator de unitate. Sistemul de mentenanță urmărește 44 dintre aceste vehicule sub formate diferite de numere de serie, iar trei sunt marcate ca indisponibile (deadlined) sub identificatori care nu apar în niciunul dintre celelalte două sisteme. Nimeni nu poate răspunde la întrebarea „câte vehicule operaționale are această unitate chiar acum” fără un apel telefonic — pentru că aceleași entități fizice sunt reprezentate prin înregistrări diferite, identificatori diferiți și valori de atribut diferite în sisteme care nu au fost concepute vreodată să fie de acord între ele.
Aceasta este problema MDM din apărare în forma sa cea mai frecventă. Gestionarea datelor master (MDM) este disciplina care creează o reprezentare autoritară unică a fiecărei entități de bază — persoană, organizație, echipament, locație — la care toate sistemele fac referire în mod consecvent. Nu este un instrument de raportare și nu este un data warehouse. Este stratul care face ca join-urile între sisteme să fie semnificative, analizele multidomeniu să fie de încredere, iar deciziile operaționale bazate pe date să fie fiabile. Acest articol acoperă arhitectura unui sistem MDM pentru apărare, de la alegerea modelului de hub, trecând prin entity resolution, construirea golden record-urilor și fluxurile de lucru de administrare a datelor, până la cerințele de capacitate de supraviețuire care fac MDM viabil în medii contestate.
Problema MDM în apărare — înregistrări de echipamente în trei sisteme cu trei ID-uri diferite, înregistrări de personal care diverg între HR și C2, costul inconsistenței
Organizațiile din apărare acumulează în mod organic fragmentarea surselor de adevăr. Sistemul HR a fost achiziționat pentru administrarea personalului. Sistemul C2 a fost construit pentru a urmări structura unităților și misiunile tactice. Sistemul de logistică a fost proiectat pentru gestionarea aprovizionării și a evidenței bunurilor. Fiecare a fost proiectat de un birou de program diferit, implementat într-un deceniu diferit și utilizează un model de date diferit. Niciunul nu a fost proiectat să interopereze cu celelalte la nivelul identității entităților.
Rezultatul este un set de scheme de identificatori incompatibile prin concepție. O persoană poate fi identificată prin numărul său de personal în HR, prin combinația dintre codul specialității militare și grad în C2 și prin identificatorul de custode al echipamentelor în logistică — trei identificatori pentru o singură ființă umană, fără nicio mapare întreținută de sistem între ei. Situația este și mai gravă în cazul echipamentelor: un tanc M1A2 poate purta un număr de bord marcat cu șablon pe corp (folosit de echipaj și de operatorii C2), un cod de adresă de activitate (activity address code) al Department of Defense în logistică, un cod de bare cu identificator unic de articol (UII) în evidența bunurilor și un număr de ordin de lucru de mentenanță în sistemul de management al mentenanței. Niciunul dintre acești identificatori nu are același format, iar sistemele care îi folosesc nu au fost construite pentru a traduce între ei.
Costul acestei inconsistențe nu este doar o neplăcere. Atunci când un analist al stării de pregătire îmbină datele de repartizare a unităților din C2 cu datele de aprovizionare din logistică pentru a calcula scorul de capabilitate operațională al unei unități, join-ul nu reușește să potrivească înregistrările care se referă la același echipament fizic sub identificatori diferiți. Scorul de capabilitate rezultat este greșit — și este greșit într-o direcție pe care analistul nu o poate detecta fără a verifica independent fiecare sistem, ceea ce anulează scopul modelului analitic. Pentru o imagine integrată a modului în care aceste eșecuri de integrare se manifestă în arhitectura de date mai largă, consultați materialul nostru despre tiparele de integrare a datelor în domeniul apărării.
Divergența înregistrărilor de personal dintre HR și C2 este o problemă suplimentară, distinctă. HR păstrează evidența administrativă: gradul permanent, funcția, unitatea de repartiție, nivelul de autorizare de securitate, istoricul instruirii. C2 păstrează imaginea operațională: ce persoană este prezentă fizic la ce unitate, ce rol îndeplinește în organizarea curentă pe misiune (task organization), ce sisteme este autorizată să opereze. În condiții stabile de garnizoană, aceste înregistrări concordă rezonabil de bine. În timpul operațiilor — când personalul este atașat la unități diferite, când organizarea pe misiune se abate de la statul de organizare și dotare (TO&E), când detașările temporare creează afilieri secundare — cele două înregistrări diverg rapid. Un sistem MDM care gestionează entitatea persoană trebuie să reconcilieze reprezentările administrativă și operațională într-un golden record coerent, util atât pentru raportarea stării de pregătire, cât și pentru planificarea operațională.
Arhitectura hub-ului MDM — modele de hub registry vs consolidation vs coexistence, criterii de selecție pentru mediile de apărare, amplasarea hub-ului pentru date clasificate vs neclasificate
Trei modele de hub domină implementările MDM de producție, fiecare având o relație distinctă cu sistemele-sursă pe care le deservește și un set diferit de compromisuri operaționale relevante în mediile de apărare.
Modelul registry stochează doar tabelul de referințe încrucișate — o mapare a fiecărui identificator din sistemele-sursă la ID-ul global al entității atribuit de MDM — fără a replica sau a stoca vreun atribut al entităților în hub-ul propriu-zis. Când un consumator are nevoie de date despre entități, interoghează hub-ul pentru ID-ul global, apoi interoghează sistemele-sursă corespunzătoare folosind identificatorii specifici fiecărei surse returnați de referința încrucișată. Modelul registry are cea mai mică amprentă de date și nu necesită sincronizarea datelor de atribute în hub, ceea ce îl face atractiv pentru mediile în care replicarea datelor clasificate într-o locație centrală ridică probleme de autorizare. Limitarea sa este că obligă fiecare consumator să rezolve entitățile în mai multe sisteme-sursă la momentul interogării, ceea ce este impracticabil din punct de vedere operațional pentru interogările operaționale de înaltă frecvență.
Modelul consolidation copiază și normalizează atributele entităților din toate sistemele-sursă contribuitoare în hub, rulează entity resolution pentru a lega duplicatele și servește consumatorilor o vedere unificată a entităților. Sistemele-sursă nu sunt modificate — hub-ul este un consumator optimizat pentru citire al datelor-sursă, nu un scriitor înapoi în ele. Acest model este cel mai practic pentru mediile de apărare deoarece nu necesită drepturi de modificare a sistemelor-sursă (sistemele C2, HR și de logistică nu pot fi de regulă modificate de programul MDM) și concentrează calculul entity resolution în hub, în loc să îl distribuie între consumatori. Arhitectura unui data lake militar consumă de regulă golden record-urile hub-ului de consolidare MDM ca strat de referință curated, în loc să îmbine direct tabelele-sursă brute.
Modelul coexistence adaugă capabilitatea de scriere înapoi (write-back) modelului consolidation: hub-ul construiește golden record-ul și apoi propagă valorile autoritare ale atributelor înapoi către sistemele-sursă, suprascriind valorile întreținute local cu valoarea autoritară stabilită de hub. Acest model produce cea mai puternică consistență între sisteme, dar cere ca fiecare sistem-sursă participant să accepte scrieri inițiate de hub — o cerință blocată frecvent de constrângerile de autorizare ale sistemelor, de procesele de control al schimbărilor impuse de furnizori și de aversiunea față de riscul operațional în sistemele active.
Amplasarea hub-ului pentru date clasificate vs neclasificate necesită instanțe de hub separate la fiecare limită de clasificare. Un singur hub MDM care prelucrează atât date clasificate, cât și neclasificate despre entități ar impune ca hub-ul să funcționeze la nivelul de clasificare mai înalt, ceea ce ar împiedica consumatorii neclasificați să acceseze orice date despre entități din hub — anulându-i scopul. Arhitectura practică implementează un hub neclasificat pentru entitățile care există integral în sisteme-sursă neclasificate (date de referință generale, date neclasificate despre locații, înregistrări ale furnizorilor comerciali) și un hub clasificat, la nivelul de clasificare corespunzător, pentru entitățile care poartă atribute clasificate. Entity resolution între niveluri de clasificare — stabilirea faptului că o entitate din sistemul neclasificat corespunde aceleiași entități fizice dintr-un sistem clasificat — necesită un gardian (guard) specializat de tip cross-domain solution, care să transporte peste limita de clasificare doar referința încrucișată a identificatorilor, niciodată atributele clasificate propriu-zise.
Tipuri de entități în MDM pentru apărare — persoană (personal militar), organizație (unitate/comandament), echipament (platformă/articol final), locație (facilitate/poziție)
MDM pentru apărare gestionează patru domenii principale de entități, fiecare cu sisteme-sursă, scheme de identificatori, structuri de atribute și provocări de calitate a datelor distincte.
Domeniul entității persoană acoperă personalul militar, contractorii și partenerii din coaliție. Principalele sisteme-sursă sunt sistemul de management al personalului (evidența administrativă, repartizarea permanentă, gradul), sistemul C2 (repartizarea operațională curentă, poziția în organizarea pe misiune) și sistemul de gestionare a autorizărilor de securitate (nivelul de autorizare, autorizările pe compartimente, datele de expirare a accesului). Provocarea principală legată de identificatori este că aceeași persoană poate apărea sub unitatea sa permanentă de serviciu în HR, fiind în același timp atașată operațional la o altă unitate în C2 — ambele înregistrări sunt corecte în sistemele lor respective, dar reprezintă două stări operaționale diferite ale aceleiași entități. Construirea golden record-ului pentru domeniul persoană trebuie să capteze atât starea administrativă, cât și cea operațională ca grupuri de atribute distincte, în loc să le comprime într-un singur câmp de repartizare a unității.
Domeniul entității organizație acoperă unitățile, comandamentele, subunitățile și grupările operative (task forces). Organizațiile din mediile de apărare au o structură ierarhică părinte-copil (brigada conține batalioane, batalionul conține companii) și o dimensiune temporală (grupările operative sunt create, fuzionează, se reorganizează și se dizolvă la scări de timp operaționale). Sistemul MDM trebuie să mențină ierarhia organizațională curentă, stările sale istorice la momente anterioare și relațiile dintre structura administrativă TO&E și organizarea operațională curentă pe misiune. Sistemele-sursă sunt ierarhia unităților din sistemul C2, TO&E din sistemul de management al personalului și evidența elementului de comandă din sistemele de logistică.
Domeniul entității echipament acoperă platformele, vehiculele, sistemele de armament și inventarul articolelor finale. Este domeniul cel mai fragmentat din punct de vedere al identificatorilor în practică: un singur articol fizic poartă de regulă patru sau mai multe scheme distincte de identificatori în sistemele care îl gestionează. UII (identificator unic de articol) este codul de bare standard al Department of Defense, unic la nivel global, pentru articolele de echipament serializate și ar trebui să servească drept identificator master pentru domeniul echipament, dar sistemele moștenite (legacy), anterioare standardului UII, folosesc identificatori proprietari care necesită un tabel de mapare pentru a fi legați de spațiul UII. Potrivirea între sisteme necesită potrivire aproximativă (fuzzy matching) pe câmpurile de număr de serie, care pot include caractere separatoare diferite, zerouri la început sau prefixe de cod al producătorului, în funcție de sistemul care a înregistrat identificatorul.
Domeniul entității locație acoperă facilitățile, instalațiile, zonele de interes denumite și pozițiile tactice. Potrivirea locațiilor este în esență o problemă geospațială: aceeași locație fizică poate fi referită prin coordonate MGRS într-un sistem, prin coordonate geografice în grade zecimale în altul și printr-o denumire de loc în limbaj natural într-un al treilea. Blocking-ul geospațial grupează înregistrările candidate de locații după proximitate, folosind o grilă geohash, iar potrivirea stabilește dacă două înregistrări apropiate spațial se referă la aceeași facilitate sau la locații distincte din apropiere. Entitățile de tip locație au, de asemenea, o dimensiune temporală — clasificarea facilității, starea operațională și forța care o controlează se schimbă în timp — ceea ce impune ca golden record-ul să poarte intervale de validitate temporală pentru atributele-cheie ale locației. Stratul de fuziune a informațiilor în timp real care corelează detecțiile ISR cu locațiile cunoscute depinde direct de acuratețea și completitudinea entity master-ului de locații.
Entity resolution: potrivirea între sistemele-sursă — strategii de blocking pentru seturi de entități de apărare la scară largă, modele de potrivire ML, potrivire deterministă vs probabilistă
Rezoluția entităților este procesul prin care se stabilește care înregistrări din diferite sisteme sursă se referă la aceeași entitate din lumea reală și prin care acestea sunt legate sub un identificator global comun. La scara unui set mare de date din domeniul apărării — milioane de înregistrări de echipamente în sistemele de logistică, mentenanță și evidență a bunurilor; sute de mii de înregistrări de personal în sistemele de resurse umane (HR), C2 și autorizare de securitate — compararea naivă, pe perechi, a tuturor înregistrărilor cu toate celelalte este irealizabilă din punct de vedere computațional. Pipeline-ul de potrivire trebuie structurat ca un proces în două etape: blocarea, care reduce spațiul perechilor candidat la o dimensiune gestionabilă, urmată de potrivire, care evaluează perechile candidat cu o precizie suficientă pentru a distinge potrivirile reale de cvasipotriviri.
Strategiile de blocare pentru domeniile de entități din apărare folosesc chei de partiționare specifice domeniului pentru a grupa înregistrările care ar putea fi, în mod plauzibil, aceeași entitate. Pentru înregistrările de personal, blocarea fonetică pe câmpul numelui de familie, cu algoritmul Soundex sau Double Metaphone, grupează înregistrările în care sisteme diferite au transcris același nume cu variante ortografice, spații suplimentare sau diferențe în folosirea cratimei — toate frecvente în sistemele de management al personalului anterioare normalizării Unicode. Pentru înregistrările de echipamente, blocarea după prefix pe primele șase caractere ale numărului de serie (după normalizarea spațiilor albe și a majusculelor/minusculelor) grupează înregistrările din sistemele care reprezintă același număr de serie cu convenții diferite de separare. Pentru înregistrările de locații, o grilă geohash la nivelul de precizie 6 (lățimea celulei de aproximativ 1,2 km) grupează înregistrările apropiate spațial, excluzând locațiile evident distincte. Proiectarea blocării trebuie validată pe un set de date etalon de potriviri cunoscute înainte de implementare — etapa de blocare trebuie să păstreze în setul de candidați cel puțin 95% dintre perechile cu potrivire reală, altfel pipeline-ul de rezoluție va produce erori sistematice de omisiune pentru tipurile de înregistrări excluse.
În interiorul fiecărui bloc candidat, modelul de potrivire evaluează fiecare pereche:
- Potrivirea deterministă aplică un set fix de reguli care produce o decizie binară de potrivire/nepotrivire. O regulă deterministă pentru înregistrările de echipamente: două înregistrări se potrivesc dacă și numai dacă codurile lor de bare UII sunt identice (după eliminarea caracterelor nealfanumerice) sau dacă numerele lor de serie sunt identice, iar numerele naționale de stoc coincid până la primele nouă cifre. Regulile deterministe nu necesită date de antrenare, pot fi auditate integral și produc zero rezultate fals pozitive atunci când regula este specificată corect. Ele sunt potrivite pentru atributele destinate să fie unice la nivel global și menținute sub controale de introducere a datelor.
- Potrivirea probabilistică calculează un scor compus de potrivire pornind de la metrici de similaritate ponderate, la nivel de câmp. O comparație între înregistrări de personal poate aplica similaritatea Jaro-Winkler pe prenume, potrivirea fonetică pe numele de familie, potrivirea exactă pe data nașterii și potrivirea aproximativă pe abrevierea gradului (pentru a gestiona variantele de formatare), combinate cu un clasificator de tip regresie logistică sau arbore cu gradient boosting, antrenat pe perechi etichetate de potrivire/nepotrivire provenite din sistemele sursă reale. Modelul antrenat învață importanța relativă a fiecărui câmp în mediul concret de date impure — în unele sisteme sursă data nașterii este foarte fiabilă; în altele are o rată de eroare de 3%, ceea ce o face o trăsătură slab discriminantă.
- Modelele de potrivire bazate pe ML extind potrivirea probabilistică prin reprezentări învățate ale textului atributelor entităților. O rețea neuronală siameză antrenată pe perechi de nume de personal învață o reprezentare vectorială a numelor, astfel încât numele similare fonetic sau ortografic să aibă vectori similari — captând tipare de similaritate pe care metricile de distanță între șiruri, concepute manual, nu le surprind. Modelele ML necesită seturi de date etichetate mai mari pentru antrenare și sunt mai greu de auditat decât regulile deterministe, dar depășesc ca performanță modelele probabilistice clasice pe seturile de entități cu mult zgomot, în care tiparele erorilor de introducere a datelor sunt complexe și neuniforme între sistemele sursă.
Rezultatul pipeline-ului de potrivire pentru fiecare pereche candidat este o decizie de potrivire (potrivire / nepotrivire / revizuire) și un scor de încredere. Perechile aflate peste pragul de potrivire sunt legate automat sub un ID global de entitate comun. Perechile din banda de revizuire — în care scorul de încredere se situează între pragul de nepotrivire și pragul de potrivire — sunt direcționate către un steward uman pentru arbitrare, în loc să fie soluționate automat.
Construirea și întreținerea înregistrării golden record — reguli de supraviețuire pentru atributele sursă aflate în conflict, scorul de încredere al înregistrării golden record, soluționare automată versus asistată de steward
După ce rezoluția entităților a legat înregistrările din mai multe sisteme sursă de același ID global de entitate, sistemul MDM construiește înregistrarea golden record: reprezentarea unificată și autoritativă a entității respective, ale cărei atribute provin din cea mai bună sursă disponibilă pentru fiecare câmp. Înregistrarea golden record nu este o simplă îmbinare a tuturor atributelor sursă — atunci când sursele se contrazic, o regulă de supraviețuire trebuie să stabilească ce valoare poartă înregistrarea golden record.
Regulile de supraviețuire sunt definite pentru fiecare atribut din fiecare domeniu de entități și codifică ierarhia de autoritate pentru atributul respectiv:
Fiecare atribut din înregistrarea golden record poartă, pe lângă valoarea sa, trei câmpuri de metadate: o referință la sursă (care sistem sursă a furnizat această valoare și identificatorul înregistrării sursă concrete), un marcaj temporal al actualizării (momentul în care sistemul sursă a confirmat ultima oară această valoare) și un scor de încredere (o valoare normalizată care reflectă fiabilitatea sursei și calitatea potrivirii prin care această înregistrare a fost legată de entitatea golden). Un scor de încredere de 1,0 indică o potrivire deterministă pe un identificator unic la nivel global, provenit dintr-o sursă foarte fiabilă; scorurile mai mici reflectă rezultate de potrivire probabilistică, surse cu probleme cunoscute de calitate a datelor sau atribute pentru care supraviețuirea a fost contestată între surse cu valori contradictorii.
Scorul de încredere nu este o decorațiune — are semnificație operațională. Un analist al operativității, care elaborează o evaluare a capabilităților, poate filtra interogarea înregistrării golden record pentru a exclude atributele aflate sub un prag de încredere, sau stratul de analiză poate pondera contribuția fiecărei înregistrări de echipament la scorul de operativitate al unității în funcție de încrederea atributului său privind starea de mentenanță. Un analist care primește un indicator de operativitate fără vizibilitate asupra scorurilor de încredere subiacente nu poate distinge între o evaluare cu încredere ridicată și o cifră asamblată din potriviri de calitate slabă și date sursă învechite.
Întreținerea înregistrării golden record este un proces continuu, nu o operațiune unică, în lot. Atunci când un sistem sursă actualizează o înregistrare de entitate, pipeline-ul de ingestie MDM primește actualizarea, reevaluează supraviețuirea pentru toate atributele afectate și actualizează în consecință înregistrarea golden record. Dacă actualizarea determină modificarea înregistrării golden record pentru un atribut pe care sistemele din aval l-au consumat, se publică o notificare de modificare pe magistrala de evenimente MDM, astfel încât sistemele consumatoare să poată reinteroga înregistrarea golden record actualizată. Notificarea de modificare conține ID-ul global al entității, lista atributelor modificate și valorile dinainte și de după — informații suficiente pentru ca un sistem consumator să poată stabili dacă modificarea afectează vreuna dintre datele sale operaționale active, fără a fi nevoie de o preluare completă, din nou, a înregistrării golden record.
Fluxuri de lucru pentru data stewardship — atribuirea stewarzilor pe domenii (steward pentru echipamente, steward pentru persoane), fluxul de soluționare a disputelor, pista de audit pentru modificările înregistrării golden record
Rezoluția automată a entităților și regulile de supraviețuire tratează majoritatea cazurilor de potrivire și de conflict între atribute dintr-un sistem MDM de producție — în mod obișnuit, 85–95 la sută dintre înregistrări pot fi rezolvate fără intervenție umană, atunci când pipeline-ul de potrivire este bine calibrat pe datele concrete ale sistemelor sursă. Cele 5–15 la sută de cazuri rămase — potriviri cu încredere scăzută, valori de atribut contestate în care mai multe surse pretind autoritate egală și separări sau îmbinări de entități care necesită o decizie de apreciere — trebuie direcționate către un steward de date uman pentru arbitrare.
Stewardship-ul este organizat pe domenii de entități, fiecare domeniu fiind atribuit unui steward care deține atât expertiza de domeniu, cât și autoritatea de acces la sistem necesare pentru soluționarea disputelor:
- Stewardul de echipamente — de regulă integrat în funcția de evidență a bunurilor sau de logistică, are autoritatea de a stabili înregistrarea corectă a echipamentului atunci când sistemele nu sunt de acord asupra numerelor de serie, a repartizării la unitate sau a codului de stare. Stewardul de echipamente are acces direct la evidențele fizice și poate verifica realitatea din teren consultând urma documentară originală, pe suport de hârtie, sau coordonându-se cu gestionarii echipamentelor.
- Stewardul de personal — de regulă integrat în funcția de resurse umane sau de management al personalului, are autoritatea de a rezolva variantele contradictorii de scriere a numelor, înregistrările de personal duplicate (frecvente atunci când o persoană se reînrolează și primește un nou identificator generat de sistem) și neconcordanțele de repartizare între înregistrările administrative și cele operaționale.
- Stewardul de organizație — de regulă elementul de stat major J1 sau J3, are autoritatea de a rezolva ambiguitățile din ierarhia unităților în timpul modificărilor organizării pe misiune, de a confirma datele de activare și de inactivare a unităților și de a arbitra atribuirea unității superioare atunci când subunitățile sunt atașate temporar mai multor comandamente.
- Stewardul de locații — de regulă funcția de informații geospațiale sau de administrare a facilităților, are autoritatea de a confirma dacă două înregistrări apropiate spațial reprezintă aceeași facilitate sau facilități distincte, amplasate în același loc, și de a stabili coordonata și denumirea canonice pentru o locație care apare sub denumiri diferite în sisteme diferite.
Fluxul de soluționare a disputelor prezintă fiecare caz transmis stewardului ca pe un pachet structurat. Pachetul cazului conține: înregistrările candidate din fiecare sistem sursă despre care sistemul MDM consideră că s-ar putea referi la aceeași entitate, scorurile de similaritate la nivel de câmp pentru fiecare atribut comparat, recomandarea automată a sistemului MDM (potrivire, nepotrivire sau valoarea câștigătoare recomandată pentru un atribut contestat) și o afișare clară a punctelor în care sursele concordă și a celor în care diferă. Stewardul alege dintre opțiunile de soluționare disponibile — confirmă recomandarea automată, o înlocuiește cu o soluționare alternativă sau marchează cazul ca necesitând informații suplimentare înainte de a putea fi soluționat. Un câmp de justificare în text liber permite stewardului să documenteze raționamentul din spatele deciziilor care nu sunt evidente.
Pista de audit pentru modificările înregistrării golden record consemnează fiecare tranziție de stare din istoricul înregistrării golden record, indiferent dacă modificarea a fost declanșată de o actualizare automată de supraviețuire sau de o decizie manuală a stewardului. Fiecare înregistrare de audit conține:
- ID-ul global al entității și domeniul entității
- Atributul sau atributele modificate și valorile dinainte și de după pentru fiecare dintre ele
- Declanșatorul modificării: regulă automată de supraviețuire (cu ID-ul și versiunea regulii), actualizare primită de la sursă (cu ID-ul sistemului sursă și ID-ul înregistrării sursă) sau decizie a stewardului (cu ID-ul cazului de steward)
- Identitatea autentificată a entității responsabile de modificare — contul de serviciu al sistemului pentru modificările automate, identitatea autentificată a stewardului pentru deciziile manuale
- Marcajul temporal al modificării (valoarea ceasului logic pentru implementările distribuite, ceasul fizic pentru implementările cu un singur hub)
Înregistrările de audit sunt scrise într-un spațiu de stocare exclusiv pentru adăugare (append-only) și nu pot fi modificate după scriere. Această imutabilitate permite sistemului MDM să reconstituie starea completă a oricărei înregistrări golden record la orice moment din trecut, redând pista de audit de la crearea inițială a înregistrării încoace — o capabilitate necesară din punct de vedere operațional atunci când analiștii trebuie să evalueze ce considera sistemul MDM despre o entitate la un anumit moment istoric și o cerință de conformitate pentru sistemele de gestionare a entităților clasificate.
Capacitatea de supraviețuire a MDM în medii deconectate — cache MDM local pentru sistemele dislocate în avans, rezolvarea conflictelor la reconectare, model de consistență eventuală pentru nodurile deconectate
Un hub MDM centralizat, care necesită conectivitate de rețea cu eșalonul din spate pentru fiecare interogare de entitate, este inutilizabil din punct de vedere operațional într-un mediu contestat, în care comunicațiile sunt degradate sau întrerupte. Sistemele C2, sistemele de logistică și instrumentele de planificare operațională dislocate în avans depind toate de rezoluția entităților pentru a funcționa corect — dacă hubul MDM este inaccesibil, ele trebuie să revină la identificatorii sursă bruți, care pot să nu corespundă între sisteme, readucând imaginea operațională la starea de dinaintea MDM, caracterizată prin identitate fragmentată a entităților. Proiectarea capacității de supraviețuire a MDM previne această regresie prin dislocarea în avans a unui cache local și prin definirea unui protocol riguros de sincronizare pentru faza de reconectare.
Cache-ul MDM avansat este o replică de citire prepoziționată a înregistrărilor golden record și a tabelului de referințe încrucișate, pentru subsetul de entități relevant pentru sfera operațională a elementului avansat. „Sfera relevantă” este definită prin două dimensiuni: zona geografică de operații (toate entitățile de tip locație din cadrul AO, toate entitățile de echipamente cu ultima locație cunoscută în cadrul AO) și organizarea pe misiune (toate entitățile de tip persoană, organizație și echipament asociate unităților din organizarea pe misiune a elementului avansat). Cache-ul este populat înainte de dislocarea elementului avansat, folosind un export de tip snapshot de la hubul central. Este implementat pe un hardware care funcționează independent de rețeaua de arie largă — un server robustizat, colocat cu nodul C2 avansat, sau încorporat în mediul de calcul al postului de comandă tactic.
În timpul funcționării în regim deconectat, sistemele tactice interoghează cache-ul local exact așa cum ar interoga hubul central — același API, același format de răspuns. Cererile de rezoluție a entităților sunt servite din tabelul local de referințe încrucișate. Interogările înregistrărilor golden record returnează valorile atributelor din cache, împreună cu un marcaj temporal de prospețime care indică momentul în care fiecare atribut a fost confirmat ultima oară de hubul central. Sistemele tactice au responsabilitatea de a prezenta utilizatorilor acest marcaj temporal de prospețime atunci când datele pot fi învechite, în loc să prezinte datele din cache ca și cum ar fi actuale.
Toate creările, actualizările, îmbinările și separările de entități care au loc în perioada de deconectare sunt scrise într-un jurnal local de modificări — o coadă ordonată și limitată de evenimente de modificare a entităților. Fiecare eveniment poartă un marcaj temporal de tip ceas vectorial, care stabilește o ordonare parțială a evenimentelor între nodurile deconectate, fără a necesita ceasuri fizice sincronizate. Capacitatea jurnalului de modificări limitează durata funcționării în regim deconectat: un jurnal de modificări dimensionat pentru 72 de ore de ritmuri tipice de actualizare a entităților în operații asigură 72 de ore de funcționare independentă, după care sincronizarea devine obligatorie pentru a preveni depășirea capacității jurnalului. Procesul de planificare operațională trebuie să țină seama de această constrângere.
Protocolul de sincronizare la reconectare funcționează în trei faze atunci când elementul avansat restabilește conectivitatea de rețea cu hubul central:
Modelul de consistență eventuală care stă la baza acestei arhitecturi oferă o garanție: după reconectare și finalizarea cu succes a protocolului de sincronizare, toate nodurile din topologia MDM — hubul central și toate cache-urile avansate — dețin aceeași stare a entităților. În timpul unei perioade de deconectare, nodurile pot diverge. Protocolul de sincronizare este conceput astfel încât divergența să fie limitată, detectabilă și rezolvabilă fără pierderi de date — nicio actualizare de entitate efectuată în perioada de deconectare nu este eliminată, ci doar reordonată și, eventual, înlocuită de o regulă de supraviețuire care aplică ierarhia de autoritate definită de organizație.
Implicația operațională este că analiștii și sistemele care folosesc cache-ul avansat în timpul unei perioade de deconectare trebuie să înțeleagă că lucrează cu un snapshot cu actualitate incertă. Cache-ul avansat ar trebui să expună un câmp „marcaj temporal al ultimei sincronizări” la nivelul cache-ului și un marcaj temporal „ultima confirmare” la nivelul fiecărui atribut al înregistrării golden record, oferind sistemelor din aval informațiile de care au nevoie pentru a prezenta avertismentele adecvate privind nivelul de încredere atunci când deciziile operaționale depind de date despre entități care nu au fost confirmate recent de hubul central. O evaluare a operativității unității, construită pe înregistrări golden record ale echipamentelor, cu un snapshot vechi de 12 ore și o perioadă de deconectare de 71 de ore, justifică un nivel de încredere diferit față de una construită pe înregistrări sincronizate cu 30 de minute înainte de generarea evaluării. Faptul că această distincție este făcută vizibilă în date — în loc să fie ascunsă în spatele unei prezentări uniforme a atributelor înregistrării golden record — este ceea ce face ca MDM să fie util, și nu înșelător, în mediile operaționale contestate.