Dataintegraatio

Puolustuksen päädatanhallinta: entiteettien yhdistäminen, kultatietue ja järjestelmien välinen yhdenmukaisuus

Tekijä Corvus Intelligence Engineering Team · Tietoa tiimistä →

26. kesäkuuta 2026 12 min lukuaikaa

Pataljoonatason logistiikkaupseeri pyytää valmiusraporttia. C2-järjestelmässä on 47 yksikölle sijoitettua ajoneuvoa. Materiaalivastuun järjestelmässä on kirjattu 51 ajoneuvoa samalla yksikön tunnuksella. Kunnossapitojärjestelmä seuraa 44:ää niistä eri sarjanumeromuodoilla, ja kolme on merkitty käytöstä poistetuiksi tunnuksilla, joita ei näy kummassakaan muussa järjestelmässä. Kukaan ei voi vastata kysymykseen ”kuinka monta käyttökelpoista ajoneuvoa tällä yksiköllä on juuri nyt” ilman soittoa — koska samat fyysiset entiteetit on esitetty eri tietueina, eri tunnisteina ja eri attribuuttiarvoina järjestelmissä, joita ei ole koskaan suunniteltu yhtäpitäviksi.

Tämä on puolustuksen MDM-ongelma yleisimmässä muodossaan. Päädatanhallinta (MDM) on toimiala, joka luo kustakin ydinentiteetistä — henkilöstä, organisaatiosta, kalustosta, sijainnista — yhden auktoritatiivisen esityksen, johon kaikki järjestelmät viittaavat johdonmukaisesti. Se ei ole raportointityökalu eikä tietovarasto. Se on kerros, joka tekee järjestelmien välisistä yhteenliitoksista merkityksellisiä, monialaisesta analytiikasta luotettavaa ja tietoihin perustuvista operatiivisista päätöksistä luotettavia. Tässä artikkelissa käsitellään puolustuksen MDM-järjestelmän arkkitehtuuria hub-mallin valinnasta entiteettien yhdistämisen, kultatietueen rakentamisen, vastuuhenkilötyönkulkujen ja toimintakykyvaatimusten kautta, jotka tekevät MDM:stä käyttökelpoisen uhkaavissa ympäristöissä.

Puolustuksen MDM-ongelma — kalustotietueita kolmessa järjestelmässä kolmella eri tunnisteella, henkilöstötietueet eroavat HR:n ja C2:n välillä, epäyhdentämukaisuuden kustannus

Puolustusorganisaatiot kasaavat totuuslähteen pirstoutumista orgaanisesti. HR-järjestelmä hankittiin henkilöstöhallintoa varten. C2-järjestelmä rakennettiin yksikön rakenteen ja taktisten tehtävänantojen seurantaan. Logistiikkajärjestelmä suunniteltiin hankinnan ja materiaalivastuun hallintaan. Kunkin suunnitteli eri ohjelmistoimisto, kullakin on käyttöönotto eri vuosikymmenellä ja kukin käyttää eri tietomallia. Yhtäkään niistä ei suunniteltu yhteentoimivaksi muiden kanssa entiteetti-identiteetin tasolla.

Tuloksena on joukko tunnistemalleja, jotka ovat yhteensopimattomia suunnittelustaan. Henkilö voidaan tunnistaa HR:ssä henkilötunnuksellaan, C2:ssä sotilasammattikoodin ja sotilasarvon yhdistelmällä ja logistiikassa kalustovastuuhenkilön tunnuksella — kolme tunnisteetta yhdelle ihmiselle ilman järjestelmän ylläpitämää kuvatusta niiden välillä. Kalusto on huonompaa: M1A2-panssarivaunussa voi olla runkoon maalattu bumper-tunnus (jota miehistö ja C2-operaattorit käyttävät), puolustusministeriön toimipaikkakoodi logistiikassa, yksilöivä tunniste (UII) -viivakoodi materiaalivastuussa ja kunnossapitotilauksen numero kunnossapitojärjestelmässä. Mikään näistä tunnisteista ei ole samassa muodossa, eikä niitä käyttäviä järjestelmiä rakennettu kääntämään niitä toistensa välillä.

Tämän epäyhdentämukaisuuden kustannus ei ole pelkkää vaivaa. Kun valmiusanalyytikko yhdistää C2:n yksikön sijoitustiedot logistiikan hankintatietoihin laskeakseen yksikön operatiivisen kyvykkyyden, yhteenliitos ei löydä vastaavia tietueita, jotka viittaavat samaan fyysiseen kalustoon eri tunnisteilla. Tuloksena oleva kyvykkyyspiste on väärä — ja se on väärä suunnassa, jota analyytikko ei voi havaita ilman kunkin järjestelmän itsenäistä tarkistamista, mikä kumoaa analyysimallin tarkoituksen. Yhtenäiseen näkymään siitä, miten nämä integraatiovirheet ilmenevät laajemmassa data-arkkitehtuurissa, tutustu käsittelyymme puolustuksen dataintegraatiomalleista.

Henkilöstötietueiden eriytyminen HR:n ja C2:n välillä on erillinen lisäongelma. HR ylläpitää hallinnollista tietuetta: pysyvä sotilasarvo, tehtäväpaikka, sijoitettu yksikkö, turvallisuusluokitus, koulutushistoria. C2 ylläpitää operatiivista kuvaa: kuka on fyysisesti missäkin yksikössä, mitä roolia hän hoitaa nykyisessä tehtäväorganisaatiossa, mitä järjestelmiä hänellä on valtuudet käyttää. Vakaissa varusmiestilanteissa nämä tietueet ovat kohtuullisen yhtäpitävät. Operaatioiden aikana — kun henkilöstöä liitetään eri yksiköihin, kun tehtäväorganisaatio poikkeaa henkilöstö- ja kalustojärjestystä (TO&E), kun tilapäiset tehtävänannot luovat toissijaisia alaisuuksia — tietueet eriytyvät nopeasti. MDM-järjestelmän, joka hallinnoi henkilöentiteettiä, on sovitettava sekä hallinnollinen että operatiivinen esitys yhtenäiseksi kultatietueeksi, joka on hyödyllinen sekä valmiusraportoinnille että operatiiviselle suunnittelulle.

MDM-hub-arkkitehtuuri — rekisteri-, konsolidointi- ja rinnakkaisuus-hub-mallit, valintakriteerit puolustusympäristöille, hubin sijoitus luokitellulle ja luokittelemattomalle datalle

Kolme hub-mallia hallitsee tuotannon MDM-käyttöönottoja. Kullakin on oma suhteensa palveltaviin lähdejärjestelmiinsä ja erilainen joukko operatiivisia tasapainotuksia, joilla on merkitystä puolustusympäristöissä.

Rekisterimalli tallentaa vain ristiviitetaulukon — kuvauksen kunkin lähdejärjestelmän tunnisteesta MDM:n määräämään globaaliin entiteettitunnukseen — ilman entiteettiattribuuttien replikointia tai tallentamista hubiin itseensä. Kun käyttäjä tarvitsee entiteettitietoja, se kysyy hubista globaalia tunnusta ja kysyy sitten asianmukaisista lähdejärjestelmistä ristiviitteen palauttamilla lähteekohtaisilla tunnisteilla. Rekisterimallilla on pienin datanjälki, eikä se vaadi attribuuttitietojen synkronointia hubiin, mikä tekee siitä houkuttelevan ympäristöissä, joissa luokitellun datan replikointi keskuspaikkaan nostaa valtuutuskysymyksiä. Sen rajoitus on, että se pakottaa jokaisen käyttäjän ratkaisemaan entiteetit useiden lähdejärjestelmien välillä kyselyhetkellä, mikä on operatiivisesti epäkäytännöllistä usein toistuville operatiivisille kyselyille.

Konsolidointimalli kopioi ja normalisoi entiteettiattribuutit kaikista osallistuvista lähdejärjestelmistä hubiin, ajaa entiteettien yhdistämisen yhdistääkseen kaksoiskappaleet ja tarjoaa yhtenäisen entiteetinäkymän käyttäjille. Lähdejärjestelmiä ei muuteta — hub on lukuoptimoitu lähdetietojen käyttäjä, eikä se kirjoita takaisin niihin. Tämä malli on käytännöllisin puolustusympäristöille, koska se ei vaadi lähdejärjestelmien muokkausoikeuksia (C2-, HR- ja logistiikkajärjestelmiä ei tyypillisesti voi muokata MDM-ohjelma), ja se keskittää entiteettien yhdistämisen laskennan hubiin jakamatta sitä käyttäjille. Sotilaallinen datajärviarkkitehtuuri käyttää tyypillisesti MDM-konsolidointihubin kultatietueita kuratoituna viitekerroksena eikä yhdistä suoria lähdetaulukoita.

Rinnakkaisuusmalli lisää takaisinkirjoituskyvyn konsolidointimalliin: hub rakentaa kultatietueen ja levittää sitten auktoritatiiviset attribuuttiarvot takaisin lähdejärjestelmiin ja korvaa paikallisesti ylläpidetyt arvot hubin määrittämällä auktoritatiivisella arvolla. Tämä malli tuottaa vahvimman yhdenmukaisuuden järjestelmien välillä mutta edellyttää, että jokainen mukana oleva lähdejärjestelmä hyväksyy hubista tulevat kirjoitukset — vaatimus, jonka usein estävät järjestelmän valtuutusrajoitukset, toimittajan muutostenhallintaprosessit ja operatiivinen riskin karttaminen tuotantojärjestelmissä.

Hubin sijoittaminen luokitellulle ja luokittelemattomalle datalle edellyttää erillisiä hub-instansseja kunkin turvaluokituksen rajalla. Yksi MDM-hub, joka käsittelee sekä luokiteltua että luokittelematonta entiteettidataa, edellyttäisi hubin toimivan korkeammalla turvaluokalla, mikä estäisi luokittelemattomat käyttäjät saamasta mitään entiteettitietoja hubista — mikä kumoaa sen tarkoituksen. Käytännöllinen arkkitehtuuri ottaa käyttöön luokittelemattoman hubin entiteeteille, jotka ovat kokonaan luokittelemattomissa lähdejärjestelmissä (yleiset viitetiedot, luokittelemattomat sijaintitiedot, kaupallisten toimittajien tiedot), ja luokitellun hubin asianmukaisella turvaluokalla entiteeteille, joilla on luokiteltuja attribuutteja. Turvaluokitusrajat ylittävä entiteettien yhdistäminen — sen ratkaiseminen, että luokittelemattomassa järjestelmässä oleva entiteetti vastaa samaa fyysistä entiteettiä luokitellussa järjestelmässä — edellyttää erikoistunutta monialaratkaisun valvontaa, joka kantaa turvaluokituksen rajan yli vain tunnisteiden ristiviitteen eikä koskaan itse luokiteltuja attribuutteja.

Entiteettityypit puolustuksen MDM:ssä — henkilö (sotilashenkilöstö), organisaatio (yksikkö/komento), kalusto (alusta/yksikkö), sijainti (laitos/asema)

Puolustuksen MDM hallinnoi neljää ensijaista entiteettialuetta, joilla kullakin on omat lähdejärjestelmänsä, tunnistemallinsa, attribuuttirakenteensa ja datan laadun haasteensa.

Henkilöentiteetin alue kattaa sotilashenkilöstön, urakoitsijat ja koalitiokumppanit. Keskeisiä lähdejärjestelmiä ovat henkilöstöhallintajärjestelmä (hallinnollinen tietue, pysyvä sijoitus, sotilasarvo), C2-järjestelmä (nykyinen operatiivinen sijoitus, tehtäväorganisaation asema) ja turvallisuusselvitysten hallintajärjestelmä (turvallisuusluokitus, osasto-oikeudet, pääsyn päättymispäivät). Keskeinen tunnishaaste on, että sama henkilö voi esiintyä HR:ssä pysyvällä tehtäväyksiköllään ja olla operatiivisesti liitettynä toiseen yksikköön C2:ssä — molemmat tietueet ovat oikeita omassa järjestelmässään, mutta ne edustavat kahta eri operatiivista tilaa samalle entiteetille. Henkilöalueen kultatietueen rakentamisen on kaapattava sekä hallinnollinen että operatiivinen tila erillisiksi attribuuttiryhmiksi eikä kutistettava niitä yhdeksi yksikön sijoituskentäksi.

Organisaatioentiteetin alue kattaa yksiköt, komentopaikat, alayksiköt ja tehtäväjoukot. Organisaatioilla puolustusympäristöissä on hierarkkinen vanhempi-lapsi-rakenne (prikaati sisältää pataljoonia, pataljoona komppanioita) ja ajallinen ulottuvuus (tehtäväjoukot luodaan, yhdistyvät, järjestäytyvät uudelleen ja hajoavat operatiivisella aikataululla). MDM-järjestelmän on ylläpidettävä nykyistä organisaatiohierarkiaa, sen historiallisia tiloja menneinä aikaleimoina sekä suhteita hallinnollisen TO&E-rakenteen ja nykyisen operatiivisen tehtäväorganisaation välillä. Lähdejärjestelmiä ovat yksikköhierarkia C2-järjestelmässä, TO&E henkilöstöhallintajärjestelmässä ja komentoelementin tietue logistiikkajärjestelmissä.

Kalustoentiteetin alue kattaa alustat, ajoneuvot, asejärjestelmät ja yksikköinventaarion. Käytännössä tämä on eniten tunnisteissa pirstoutunut alue: yksi fyysinen yksikkö kantaa tyypillisesti neljää tai useampaa erillistä tunnistemallia niissä järjestelmissä, jotka sitä hallinnoivat. UII (unique item identifier) on puolustusministerion standardi globaalisti yksilöivä viivakoodi sarjanumeroiduille kalustoyksiköille ja sen pitäisi toimia kalustoalueen pääatunnistimena, mutta UII-standardia edeltävät vanhat järjestelmät käyttävät omia tunnisteitaan, jotka vaativat kuvaustaulun yhdistääkseen UII-tilaan. Vastaavuus järjestelmien välillä edellyttää sumeaa vastaavuutta sarjanumerokentissä, jotka voivat sisältää eri erottimia, etunollia tai valmistajakoodin etuliitteitä riippuen siitä, mikä järjestelmä kirjasi tunnisteen.

Sijaintientiteetin alue kattaa laitokset, varuskunta-alueet, nimetyt kiinnostuksen kohteet ja taktiset asemat. Sijaintien vastaavuus on perustaltaan geopositiota ongelma: sama fyysinen paikka voidaan viitata MGRS-koordinaateilla yhdessä järjestelmässä, desimaaliasteilla toisessa ja luonnollisen kielen paikannimellä kolmannessa. Geopositioblokkaus ryhmittää ehdokassijaintitietueet läheisyyden mukaan geohash-ruudukolla, ja vastaavuus määrittää, viittaavatko kaksi avaruudellisesti läheistä tietuetta samaan laitokseen vai eri läheisiin paikkoihin. Sijaintientiteeteillä on myös ajallinen ulottuvuus — laitoksen turvaluokitus, operatiivinen tila ja hallitseva voima muuttuvat ajan myötä — mikä edellyttää kultatietueen kantavan ajallisia voimassaolovälejä keskeisille sijaintiattribuuteille. Reaaliaikainen tiedustelufuusio -kerros, joka korreloi ISR-havainnot tunnettuihin sijainteihin, riippuu suoraan sijaintientiteetin pääaineiston tarkkuudesta ja täydellisyydestä.

Entiteettien yhdistäminen: vastaavuus lähdejärjestelmien välillä — blokkausstrategiat suurille puolustusentiteettijoukoille, ML-vastaavuusmallit, deterministinen vs todennäköisyyspohjainen vastaavuus

Entiteettien yhdistäminen on prosessi, joka määrittää, mitkä tietueet lähdejärjestelmien välillä viittaavat samaan todelliseen entiteettiin, ja yhdistää ne jaetun globaalin tunnuksen alle. Suuren puolustusaineiston mittakaavassa — miljoonia kalustotietueita logistiikan, kunnossapidon ja materiaalivastuun järjestelmissä; satoja tuhansia henkilöstötietueita HR-, C2- ja turvallisuusselvitysjärjestelmissä — naiivi parittainen vertailu kaikkia tietueita kaikkia muita vastaan on laskennallisesti mahdotonta. Vastaavuusputki on rakennettava kaksivaiheiseksi prosessiksi: blokkaus, joka supistaa ehdokasparien tilan käsiteltävään kokoon; ja sen jälkeen vastaavuus, joka arvioi ehdokasparit riittävällä tarkkuudella erottaakseen aidot vastaavuudet lähes-osuneista.

Blokkausstrategiat puolustuksen entiteettialueille käyttävät aluekohtaisia jakoavaimia ryhmitelläkseen tietueet, jotka voisivat periaatteessa olla sama entiteetti. Henkilöstötietueille foneettinen blokkaus sukunimikentässä Soundex- tai Double Metaphone -algoritmilla ryhmittää tietueet, joissa eri järjestelmät ovat kirjoittaneet saman nimen eri kirjoitusasuilla, ylimääräisillä välilyönneillä tai yhdysmerkkierotuksilla — kaikki yleisiä henkilöstöhallintajärjestelmissä, jotka edeltävät Unicode-normalisointia. Kalustotietueille etuliiteblokkaus sarjanumeron kuudessa ensimmäisessä merkissä (välilyönnit ja kirjainkoko normalisoituaan) ryhmittää tietueet järjestelmistä, jotka esittävät saman sarjanumeron eri erottimilla. Sijaintitietueille geohash-ruudukko tarkkuustasolla 6 (noin 1,2 km:n solun leveys) ryhmittää avaruudellisesti läheiset tietueet ja sulkee pois selvästi erilliset paikat. Blokkaussuunnitelma on validoitava tunnetuista vastaavuuksista koostuvaan kulta-aineistoon ennen käyttöönottoa — blokkausvaiheen on säilytettävä vähintään 95 prosenttia aidosta vastaavuusparista ehdokasjoukossa, tai ratkaisuputki tuottaa järjestelmällisiä ohitusvirheitä pois suljetuille tietueetyypeille.

Kunkin ehdokasblokin sisällä vastaavuusmalli arvioi kunkin parin:

Deterministinen vastaavuus soveltaa kiinteää sääntöjoukkoa, joka tuottaa binäärisen vastaavuus/epävastaavuus-päätöksen. Deterministinen sääntö kalustotietueille: kaksi tietuetta vastaa toisiaan jos ja vain jos niiden UII-viivakoodit ovat identtiset (ei-alfanumeeriset merkit poistettuaan) tai jos niiden sarjanumerot ovat identtiset ja niiden kansalliset varastotunnisteet ovat yhtäpitävät ensimmäiseen yhdeksään numeroon. Deterministiset säännöt eivät vaadi koulutusaineistoa, ovat täysin auditointikelpoisia ja tuottavat nolla väärää vastaavuutta, kun sääntö on määritetty oikein. Ne sopivat attribuuteille, jotka on tarkoitettu globaalisti yksilöiviksi ja joita ylläpidetään tietosyöttövalvonnan alaisuudessa.
Todennäköisyyspohjainen vastaavuus laskee yhdistelmävastaavuusarvon painotetuista kenttätason samankaltaisuusmittareista. Henkilöstötietueen vertailu voi soveltaa Jaro-Winkler-samankaltaisuutta etunimelle, foneettista vastaavuutta sukunimelle, tarkkaa vastaavuutta syntymäaikaa ja sumeaa vastaavuutta sotilasarvon lyhenteelle (vaihtelevan muotoilun hallintaan), ja yhdistää ne logistisen regressio- tai gradienttivahvistetun puuluokittelijan kanssa, joka on koulutettu nimetyistä vastaavuus/epävastaavuuspareista todellisista lähdejärjestelmistä. Koulutettu malli oppii kunkin kentän suhteellisen merkityksen tässä likaisen datan ympäristössä — joissakin lähdejärjestelmissä syntymäaika on erittäin luotettava; toisissa sillä on 3 prosentin virhemäärä, joka tekee siitä heikon erottavan tekijän.
ML-vastaavuusmallit laajentavat todennäköisyyspohjaista vastaavuutta opituilla esityksillä entiteettiattribuuttitekstistä. Henkilöstön nimipareille koulutettu Siamese-verkko oppii vektriesityksen nimistä siten, että foneettisesti tai ortografisesti samankaltaisilla nimillä on samankaltaiset vektorit — se kaappaa samankaltaisuusmalleja, jotka käsin tehdyt merkkijonoetäisyysmittarit ohittavat. ML-mallit vaativat suurempia nimettyjä koulutusaineistoja ja ovat vaikeampia auditoida kuin deterministiset säännöt, mutta ne ylittävät klassiset todennäköisyysmallit korkean kohinan entiteettijoukoissa, joissa tietosyöttövirheet ovat monimutkaisia ja epätasaisia lähdejärjestelmien välillä.

Vastaavuusputken tuotos kullekin ehdokasparille on vastaavuuspäätös (vastaavuus / epävastaavuus / tarkastus) ja luottamusarvo. Vastaavuuskynnysarvon ylittävät parit yhdistetään automaattisesti jaetun globaalin entiteettitunnuksen alle. Tarkastusvyöhykkeellä olevat parit — joissa luottamusarvo jää epävastaavuuskynnysarvon ja vastaavuuskynnysarvon väliin — ohjataan ihmiselle vastuuhenkilölle ratkaistavaksi eikä ratkaista automaattisesti.

Kultatietueen rakentaminen ja ylläpito — arvonvalintasäännöt ristiriitaisille lähdeattribuuteille, kultatietueen luottamusarvot, automaattinen vs vastuuhenkilön avustama ratkaisu

Kun entiteettien yhdistäminen on yhdistänyt tietueet useista lähdejärjestelmistä samaan globaaliin entiteettitunnukseen, MDM-järjestelmä rakentaa kultatietueen: auktoritatiivisen, yhtenäisen esityksen kyseisestä entiteetistä, jonka attribuutit tulevat parhaasta mahdollisesta lähteestä kullekin kentälle. Kultatietue ei ole yksinkertainen kaikkien lähdeattribuuttien yhdistelmä — kun lähteet ovat eri mieltä, arvonvalintasäännön on määrättävä, minkä arvon kultatietue kantaa.

Arvonvalintasäännöt määritellään attribuuttikohtaisesti kunkin entiteettialueen osalta ja koodaavat kyseisen attribuutin auktoriteettihierarkian:

# Kalustoentiteetti — arvonvalintasäännöt attribuuttiin serial_number: source_priority=[property_acct, maintenance, logistics] national_stock_num: source_priority=[property_acct, logistics] unit_assignment: source_priority=[c2_system, logistics] maintenance_status: source_priority=[maintenance, logistics] condition_code: source_priority=[maintenance, property_acct] location_mgrs: most_recent_update # C2 tai logistiikka, kumpi viimeksi päivitti end_item_code: source_priority=[property_acct] # Yksi auktoritatiivinen lähde # Henkilöentiteetti — arvonvalintasäännöt attribuuttiin permanent_rank: source_priority=[hr_system] operational_unit: source_priority=[c2_system, hr_system] clearance_level: source_priority=[clearance_mgmt] duty_position: most_recent_update # HR tai C2 sijoitustyypin mukaan name_legal: source_priority=[hr_system] name_preferred: most_complete # Lähde, jolla on vähiten null-nimikenttiä, voittaa
            

Kussakin kultatietueen attribuutissa on arvonsa lisäksi kolme metatietokenttää: lähdeviite (mikä lähdejärjestelmä toimitti tämän arvon ja kyseisen lähdetietueen tunnus), päivitysaikaleima (milloin lähdejärjestelmä viimeksi vahvisti tämän arvon) ja luottamusarvo (normalisoitu arvo, joka kuvaa lähteen luotettavuutta ja sen vastaavuuden laatua, joka yhdisti tämän tietueen kultaentiteettiin). Luottamusarvo 1,0 tarkoittaa determinististä vastaavuutta globaalisti yksilöivästä tunnuksesta erittäin luotettavasta lähteestä; alemmat arvot heijastavat todennäköisyyspohjaisia vastaavuustuloksia, tunnetusti huonolaatuisia lähteitä tai attribuutteja, joissa arvonvalinta oli riitaisaa ristiriitaisten arvojen lähteiden välillä.

Luottamusarvo ei ole koriste — sillä on operatiivista merkitystä. Valmiusarviota rakentava analyytikko voi suodattaa kultatietueen kyselyä pois attribuutit, jotka jäävät luottamuskynnysarvon alapuolelle, tai analytiikkakerros voi painottaa kunkin kalustotietueen panosta yksikön valmiuspisteeseen sen kunnossapidon tila -attribuutin luottamuksella. Analyytikko, joka saa valmiusmittarin ilman näkyvyyttä taustalla oleviin luottamusarvoihin, ei voi erottaa korkean luottamuksen arviota luvusta, joka on koottu huonolaatuisista vastaavuuksista ja vanhentuneista lähdetiedoista.

Kultatietueen ylläpito on jatkuva prosessi, ei kertaluonteinen erätoiminto. Kun lähdejärjestelmä päivittää entiteettitietueen, MDM-sisääntostoputki vastaanottaa päivityksen, arvioi uudelleen arvonvalinnan kaikille vaikuttuneille attribuuteille ja päivittää kultatietueen vastaavasti. Jos päivitys aiheuttaa muutoksen kultatietueen attribuuttiin, jonka alaspäin suuntautuvat järjestelmät ovat jo käyttäneet, muutosilmoitus julkaistaan MDM-tapahtumaväylään, jotta käyttävät järjestelmät voivat kysyä päivitettyä kultatietuetta uudelleen. Muutosilmoituksessa on entiteetin globaali tunnus, muuttuneiden attribuuttien luettelo ja ennen/jälkeen-arvot — riittävästi tietoa käyttävälle järjestelmälle sen päättämiseen, vaikuttaako muutos sen aktiivisiin operatiivisiin tietoihin ilman koko kultatietueen uudelleenhakua.

Datanhallintavastuun työnkulut — vastuuhenkilön määrääminen alueittain (kalustovastuuhenkilö, henkilöstövastuuhenkilö), riidanratkaisuprosessi, kultatietueen muutosten auditointijälki

Automaattinen entiteettien yhdistäminen ja arvonvalintasäännöt hoitavat suurimman osan vastaavuus- ja attribuuttiristiriidatapauksista tuotannon MDM-järjestelmässä — tyypillisesti 85–95 prosenttia tietueista voidaan ratkaista ilman ihmisen puuttumista, kun vastaavuusputki on kalibroitu hyvin kyseisten lähdejärjestelmien datan mukaan. Loput 5–15 prosenttia tapauksista — matalan luottamuksen vastaavuudet, riitaiset attribuuttiarvot, joissa useat lähteet vaativat saman auktoriteetin, ja entiteettien jakamiset tai yhdistämiset, jotka vaativat harkintaa — on ohjattava ihmiselle data stewardille ratkaistavaksi.

Vastuu on järjestetty entiteettialueittain, ja kullekin alueelle on nimetty vastuuhenkilö, jolla on sekä toimialan osaaminen että riitojen ratkaisemiseen tarvittava järjestelmäpääsyvaltuus:

Kalustovastuuhenkilö — tyypillisesti materiaalivastuun tai logistiikan toiminnassa, on valtuutettu määrittämään oikea kalustotietue, kun järjestelmät ovat eri mieltä sarjanumerosta, yksikön sijoituksesta tai kunnon koodista. Kalustovastuuhenkilöllä on suora pääsy fyysisiin tietueisiin, ja hän voi todentaa todellisen tilan kysymällä alkuperäisestä paperijäljestä tai koordinoimalla kalustovastuuhenkilöiden kanssa.
Henkilöstövastuuhenkilö — tyypillisesti HR- tai henkilöstöhallinnon toiminnassa, on valtuutettu ratkaisemaan ristiriitaiset nimen kirjoitusasut, kaksoishenkilöstötietueet (yleisiä, kun henkilö astuu uudelleen palvelukseen ja saa uuden järjestelmän generoiman tunnuksen) ja sijoituserot hallinnollisten ja operatiivisten tietueiden välillä.
Organisaatiovastuuhenkilö — tyypillisesti J1- tai J3-esikuntaelementti, on valtuutettu ratkaisemaan yksikköhierarkian epäselvyydet tehtäväorganisaation muutosten aikana, vahvistamaan yksiköiden aktivoinnin ja lakkauttamisen päivämäärät ja ratkaisemaan emoyksikön sijoituksen, kun alayksiköt on tilapäisesti liitetty useisiin esikuntiin.
Sijaintivastuuhenkilö — tyypillisesti geospatiaalisen tiedustelun tai kiinteistöhallinnon toiminto, on valtuutettu vahvistamaan, edustavatko kaksi avaruudellisesti läheistä tietuetta samaa laitosta vai erillisiä samassa paikassa olevia laitoksia, ja määrittämään kanonisen koordinaatin ja nimen sijainnille, joka esiintyy eri nimillä eri järjestelmissä.

Riidanratkaisuprosessi esittää kunkin vastuuhenkilötapauksen rakennettuna pakettina. Tapauspaketti sisältää: ehdokastietueet kustakin lähdejärjestelmästä, jotka MDM-järjestelmä uskoo viittaavan samaan entiteettiin, kenttätason samankaltaisuusarvot kullekin vertailulle attribuutille, MDM-järjestelmän automaattisen suosituksen (vastaavuus, epävastaavuus tai suositeltu voittaja-arvo riitaiselle attribuutille) ja selkeän esityksen siitä, missä lähteet ovat samaa ja eri mieltä. Vastuuhenkilö valitsee saatavilla olevista ratkaisuvaihtoehdoista — vahvistaa automaattisen suosituksen, ohittaa sen vaihtoehtoisella ratkaisulla tai merkitsee tapauksen vaativaksi lisätietoja ennen ratkaisua. Vapaatekstinen perustelukenttä mahdollistaa vastuuhenkilölle epäselvien päätösten perustelun dokumentoimisen.

Kultatietueen muutosten auditointijälki kirjaa jokaisen tilamuutoksen kultatietueen historiassa riippumatta siitä, aiheuttiko muutoksen automaattinen arvonvalintapäivitys vai manuaalinen vastuuhenkilön päätös. Kussakin auditointitietueessa on:

Entiteetin globaali tunnus ja entiteettialue
Muuttuneet attribuutit ja kunkin ennen/jälkeen-arvot
Muutoksen laukaisin: automaattinen arvonvalintasääntö (sääntötunnuksella ja versiolla), saapuva lähdepäivitys (lähdejärjestelmän tunnuksella ja lähdetietueen tunnuksella) tai vastuuhenkilön päätös (vastuuhenkilön tapaustunnuksella)
Muutoksesta vastuussa olevan päähenkilön todennettu identiteetti — järjestelmän palvelutili automaattisille muutoksille, vastuuhenkilön todennettu identiteetti manuaalisille päätöksille
Muutoksen aikaleima (looginen kelloarvo jaetuissa käyttöönotoissa, seinäkello yksittäisessä hubissa)

Auditointitietueet kirjoitetaan vain lisäys -tallennukseen eikä niitä voi muuttaa kirjoituksen jälkeen. Tämä muuttumattomuus mahdollistaa sen, että MDM-järjestelmä rekonstroi minkä tahansa kultatietueen täydellisen tilan millä tahansa menneellä hetkellä toistamalla auditointijäleen alkaen alkuperäisestä tietueen luonnista eteenpäin — kyky, joka on operatiivisesti välttämätön, kun analyytikot tarvitsevat arviota siitä, mitä MDM-järjestelmä uskoi entiteetistä tiettynä historiallisena hetkenä, ja vaatimus luokiteltujen entiteettien hallintajärjestelmien vaatimustenmukaisuudelle.

MDM:n toimintakyky yhteydettömissä ympäristöissä — paikallinen MDM-välimuisti eteenpäin sijoitetuille järjestelmille, ristiriitojenratkaisu yhteyden palautuessa, lopullisen yhdenmukaisuuden malli yhteydettömille solmuille

Keskitetty MDM-hub, joka vaatii verkkoyhteyden takalinjaan jokaiseen entiteettikyselyyn, on operatiivisesti käyttökelvoton uhkaavassa ympäristössä, jossa viestintä on heikentynyt tai katkennut. Eteenpäin sijoitetut C2-järjestelmät, logistiikkajärjestelmät ja operatiiviset suunnittelutyökalut kaikki riippuvat entiteettien yhdistämisestä toimiakseen oikein — jos MDM-hub ei ole tavoitettavissa, niiden on palattava raakoihin lähdetunnisteisiin, jotka eivät välttämättä vastaa toisiaan järjestelmien välillä, ja operatiivinen kuva palaa MDM:ää edeltävään pirstoutuneen entiteetti-identiteetin tilaan. MDM:n toimintakyvyn suunnittelu estää tämän paluun sijoittamalla paikallisen välimuistin eteenpäin ja määrittelemällä tarkan synkronointiprotokollan yhteyden palauttamisvaiheelle.

Eteenpäin sijoitettu MDM-välimuisti on ennalta sijoitettu luku-kopio kultatietueista ja ristiviitetaulukosta siitä entiteettijoukosta, joka liittyy eteenpäin sijoitetun elementin toiminta-alueeseen. ”Relevantti alue” määritellään kahdella ulottuvuudella: maantieteellinen toiminta-alue (kaikki sijaintientiteetit AO:lla, kaikki kalustoentiteetit, joiden viimeisin tunnettu sijainti on AO:lla) ja tehtäväorganisaatio (kaikki henkilö-, organisaatio- ja kalustoentiteetit, jotka liittyvät eteenpäin sijoitetun elementin tehtäväorganisaation yksiköihin). Välimuisti täytetään ennen eteenpäin sijoitetun elementin lähtöä keskushubin tilannekuvapurulla. Se otetaan käyttöön laitteistolla, joka toimii itsenäisesti laajaverkosta — kestäväksi rakennettu palvelin rinnakkain eteenpäin sijoitetun C2-solmun kanssa tai upotettuna taktisen komentopaikan tietotekniikkaympäristöön.

Yhteydettömän toiminnan aikana taktiset järjestelmät kysyvät paikallisesta välimuistista täsmälleen samalla tavalla kuin keskushubista — sama API, sama vastausmuoto. Entiteettien yhdistämisen pyynnöt palvelletaan paikallisesta ristiviitetaulukosta. Kultatietuekyselyt palauttavat välimuistissa olevat attribuuttiarvot tuoreusajaleimalla, joka kertoo, milloin keskushubi viimeksi vahvisti kunkin attribuutin. Taktiset järjestelmät vastaavat tämän tuoreusajaleiman esittämisestä käyttäjille, kun tiedot voivat olla vanhentuneet, eivätkä siitä, että välimuistissa oleva data esitetään kuin se olisi ajantasaista.

Kaikki entiteettien luonnit, päivitykset, yhdistämiset ja jakamiset yhteydettömän jakson aikana kirjataan paikalliseen muutoslokiin — järjestettyyn, rajoitettuun jonoon entiteetin muutostapahtumia. Kussakin tapahtumassa on vektorikelloaikaleima, joka muodostaa osittaisen järjestyksen tapahtumille yhteydettömien solmujen välillä ilman synkronoituja seinäkelloja. Muutoslokin kapasiteetti rajoittaa yhteydettömän toiminnan keston: tyypilliseen operatiiviseen entiteettipäivitystaajuuteen mitoitettu 72 tunnin muutosloki tarjoaa 72 tuntia itsenäistä toimintaa ennen kuin synkronointi pakottaa estämään lokin ylivuodon. Operatiivisen suunnittelun prosessin on otettava tämä rajoite huomioon.

Yhteyden palauttamisen synkronointiprotokolla toimii kolmessa vaiheessa, kun eteenpäin sijoitettu elementti palauttaa verkkoyhteyden keskushubiin:

Vaihe 1 — Muutoslokin siirto: Eteenpäin sijoitettu solmu siirtää koko muutoslokinsa keskushubiin. Hubi vahvistaa vastaanoton ja antaa kullekin tapahtumalle globaalin järjestysnumeron. Eteenpäin sijoitettu solmu jatkaa paikallisten kyselyjen palvelemista välimuistista tässä vaiheessa. Vaihe 2 — Ristiriitojen havaitseminen ja ratkaiseminen: Hubi toistaa eteenpäin sijoitetun muutoslokin nykyistä entiteettitilaansa vastaan. Kullekin eteenpäin sijoitetulle tapahtumalle hubi tarkistaa, päivitettiinkö sama attribuutti hubissa tai toisessa eteenpäin sijoitetussa solmussa yhteydettömän jakson aikana. Ei ristiriitaa: eteenpäin sijoitettu muutos sovelletaan sellaisenaan. Ristiriita (sama attribuutti päivitetty kahdesta lähteestä): Sovelletaan määritettyä arvonvalintasääntöä (luotetuin lähde, viimeisin looginen kello). Jos arvonvalintasääntö ei tuota selvää voittajaa: ohjataan vastuuhenkilön jonoon. Vaihe 3 — Välimuistin uudelleensynkronointi: Hubi siirtää yhdistetyn ristiriitojen jälkeisen entiteettitilan eteenpäin sijoitettuun välimuistiin. Eteenpäin sijoitettu välimuisti korvaa tilannekuvansa yhdistetyllä tilalla. Hubi siirtää ratkaistun muutoslokin kaikkiin muihin eteenpäin sijoitettuihin välimuisteihin, jotta nekin saavat tästä solmusta lähteneet päivitykset. Kaikki solmut vahvistavat vastaanoton ennen kuin hubi merkitsee synkronointisyklin valmiiksi.
            

Tähän arkkitehtuuriin perustuva lopullisen yhdenmukaisuuden malli antaa takuun: yhteyden palauttamisen ja synkronointiprotokollan onnistuneen päättymisen jälkeen kaikki MDM-topologian solmut — keskushubi ja kaikki eteenpäin sijoitetut välimuistit — pitävät identtistä entiteettitilaa. Yhteydettömän jakson aikana solmut voivat eriytyä. Synkronointiprotokolla on suunniteltu siten, että eriytyminen on rajoitettua, havaittavissa ja ratkaistavissa ilman tietojen menetystä — yhtään entiteetin päivitystä yhteydettömän jakson aikana ei hylätä, vain järjestellään uudelleen ja mahdollisesti ohitetaan arvonvalintasäännöllä, joka soveltaa organisaation määrittämää auktoriteettihierarkiaa.

Operatiivinen seuraus on, että eteenpäin sijoitetun välimuistin käyttäjien ja järjestelmien yhteydettömän jakson aikana on ymmärrettävä työskentelevänsä epävarman ajantasaisuuden tilannekuvasta. Eteenpäin sijoitetun välimuistin pitäisi esittää ”viimeisin synkronointiaikaleima” -kenttä välimuistitasolla ja ”viimeksi vahvistettu” -aikaleima yksittäisen kultatietueen attribuutin tasolla, ja antaa alaspäin suuntautuville järjestelmille tiedot, joita ne tarvitsevat esittääkseen asianmukaiset luottamusvaroitukset, kun operatiiviset päätökset riippuvat entiteettitiedoista, joita keskushubi ei ole vähän aikaa sitten vahvistanut. Yksikön valmiusarvio, joka on rakennettu kaluston kultatietueista 12 tuntia vanhalla tilannekuvalla ja 71 tunnin yhteydettömällä jaksolla, vaatii erilaisen luottamustason kuin arvio, joka on rakennettu tietueista, jotka synkronoitiin 30 minuuttia ennen arvion luomista. Tämän eron tekeminen näkyväksi datassa — sen sijaan että se piilotettaisiin kultatietueen attribuuttien tasapäisen esityksen taakse — tekee MDM:stä hyödyllisen eikä harhaanjohtavan uhkaavissa operatiivisissa ympäristöissä.

Usein kysytyt kysymykset

Mitä päädatanhallinta (MDM) tarkoittaa puolustuksen yhteydessä?

Päädatanhallinta puolustuksen yhteydessä on toimiala, jossa luodaan ja ylläpidetään kustakin ydinentiteetistä — henkilöstä, organisaatiosta, kalustosta ja sijainnista — yhtä auktoritatiivista versiota, jota kaikki operatiiviset järjestelmät käyttävät vertailukohteena. Ilman MDM:ää sotilas näkyy HR-järjestelmässä yhdellä henkilötunnuksella, C2-järjestelmässä toisella yksikön määräämällä tunnisteella ja logistiikkajärjestelmässä kolmannella, kaluston sijoitukseen sidotulla tunnisteella. Kun analyytikko yhdistää nämä järjestelmät, hän ei voi ratkaista, viittaavatko kolme tietuetta samaan henkilöön vai kolmeen eri henkilöön. MDM ratkaisee tämän käyttämällä entiteettien yhdistämisprosessia, joka vertailee tietueita järjestelmien välillä, yhdistää kaksoiskappaleet yhden globaalin tunnuksen alle ja rakentaa kultatietueen, joka edustaa kunkin entiteetin parhaiten tunnettua tilaa. Kaikki alaspäin suuntautuva analytiikka ja operatiiviset järjestelmät käyttävät kultatietuetta jaetun API:n kautta eivätkä kyselyitä lähdejärjestelmiin erikseen. Tuloksena ovat yhdenmukaiset entiteettiviittaukset C2-, logistiikka-, HR- ja ISR-järjestelmissä, mikä on edellytys luotettavalle monialaiselle tilannekuvalle.

Mitkä ovat MDM:n kolme hub-mallia ja mikä niistä on paras puolustukselle?

MDM:n kolme vakio-hub-mallia ovat rekisterimalli, konsolidointimalli ja rinnakkaisuusmalli. Rekisterimallissa MDM-hub tallentaa vain ristiviitetaulukon — kuvauksen lähdejärjestelmien tunnisteista globaaliin entiteettitunnukseen — ilman itse pääattribuuttitietojen tallentamista. Kukin järjestelmä säilyttää oman kopionsa entiteetin attribuuteista, ja käyttäjät kysyvät lähdejärjestelmistä suoraan ja ratkaisevat identiteetin ristiviitteen avulla. Konsolidointimallissa hub kopioi ja tallentaa entiteetin attribuutit kaikista lähdejärjestelmistä, rikastaa ja poistaa niistä kaksoiskappaleet ja tarjoaa konsolidoidun tuloksen; lähdejärjestelmiä ei muuteta. Rinnakkaisuusmallissa hub sekä tallentaa konsolidoidun pääaineiston että kirjoittaa kultatietueen attribuutit takaisin lähdejärjestelmiin ja luo siten jaetun auktoritatiivisen tilan kaikille mukana oleville sovelluksille. Puolustusympäristöissä käytännöllisin on konsolidointimalli: se ei vaadi auktoritatiivisten lähdejärjestelmien (HR, logistiikka, C2-järjestelmät ovat harvoin muokattavissa) muuttamista, ei vaadi, että kaikki järjestelmät hyväksyvät hubista tulevat kirjoitukset (takaisinkirjoituksen valtuutus on monimutkaista luokitelluissa ympäristöissä), ja tarjoaa silti keskeisen paikan, josta analytiikka- ja tiedustelujärjestelmät voivat kysellä yhdenmukaisia entiteettitietoja. Rekisterimalli sopii tilanteisiin, joissa tallennuksen replikointi ei ole mahdollista turvaluokituksen erottelun vaatimusten vuoksi.

Mitä entiteettityyppejä puolustuksen MDM-järjestelmä hallinnoi?

Puolustuksen MDM-järjestelmä hallinnoi neljää ensisijaista entiteettialuetta. Henkilöalue kattaa sotilashenkilöstön — sotilaat, upseerit, urakoitsijat ja koalitiokumppanit — attribuutteinaan HR-, henkilöstöhallinta-, turvallisuusselvitys- ja C2-järjestelmien tiedot. Organisaatioalue kattaa yksiköt, komentopaikat, alayksiköt ja tehtäväjoukot mukaan lukien hierarkkiset suhteet ja nykyinen tehtäväorganisaatiorakenne, joka muuttuu usein operatiivisen suunnittelun aikana. Kalustoalue kattaa alustat, ajoneuvot, asejärjestelmät ja yksikköinventaarion, attribuutteinaan logistiikan, kunnossapidon ja materiaalivastuun järjestelmien tiedot; kullekin kalustoyksikölle on sarjanumero ja yksilöivä tunniste (UII), joka on yhdistettävä järjestelmiin, jotka voivat kirjata eri tunnistemuotoja. Sijaintialue kattaa laitokset, varuskunta-alueet, nimetyt kiinnostuksen kohteet ja taktiset asemat, ja se edellyttää yhteensovittamista järjestelmien välillä, jotka viittaavat samaan fyysiseen paikkaan MGRS-koordinaateilla, maantieteellisillä koordinaateilla tai luonnollisen kielen paikannimillä. Kukin alue vaatii aluekohtaisia vastaavuuden tunnistamisen algoritmeja ja vastuuhenkilöityksiä, koska attribuutit, tunnistemallit ja datan laatumallit poikkeavat huomattavasti alueiden välillä.

Miten entiteettien yhdistäminen toimii suuren puolustusaineiston mittakaavassa?

Entiteettien yhdistäminen puolustuksen mittakaavassa — miljoonia kalustotietueita, satoja tuhansia henkilöstötietueita useissa lähdejärjestelmissä — edellyttää blokkausvaihetta ennen kuin mitään parittaista vertailua voidaan tehdä. Blokkaus jakaa koko tietuejoukon pienempiin ehdokasryhmiin, joiden sisällä kaikki tietueet voisivat periaatteessa viitata samaan entiteettiin. Ilman blokkausta jokaisen tietueen vertailu jokaista toista tietuetta vastaan on neliöllisen kallista ja laskennallisesti mahdotonta suurille aineistoille. Puolustusentiteettijoukkojen blokkausstrategioita ovat foneettinen blokkaus sukunimikentissä (Soundex, Metaphone) henkilöstötietueille, etuliiteblokkaus sarjanumerokentissä kalustotietueille ja geohash-blokkaus sijaintitietueille. Blokkauksen jälkeen vastaavuusmalli arvioi kunkin ehdokasparin blokin sisällä. Deterministinen vastaavuus soveltaa kiinteää sääntöjoukkoa — jos kaksi tietuetta jakaa tarkan sarjanumeron ja saman kansallisen varastotunnuksen (NSN), ne vastaavat toisiaan. Todennäköisyyspohjainen vastaavuus laskee vastaavuusvarmuusarvon kenttätason samankaltaisuusarvojen painotetusta yhdistelmästä ja vertaa sitä kynnysarvoon. Koneoppimiseen perustuva vastaavuus kouluttaa luokittelijan nimetyistä vastaavuus/epävastaavuuspareista kyseisestä aineistosta ja oppii kunkin kentän suhteellisen painon sekä ympäristön lähdejärjestelmille ominaiset tietosyöttövirheet.

Mitä kultatietue on ja miten se rakennetaan ristiriitaisista lähdetiedoista?

Kultatietue on MDM-järjestelmän auktoritatiivinen, yhtenäinen esitys yhdestä entiteetistä. Se kootaan kaikkien sellaisten lähdejärjestelmien attribuuteista, joissa on tietueita kyseisestä entiteetistä. Kun kaksi tai useampi lähdejärjestelmä antaa eri arvon samalle attribuutille — esimerkiksi kaluston sijoitettu yksikkö eroaa logistiikka- ja C2-järjestelmän välillä — arvonvalintasääntö määrää, kumman lähteen arvo voittaa. Yleisiä arvonvalintasääntöjä ovat: viimeisin voittaa (lähde, joka viimeksi päivitti attribuutin, on etusijalla), luotetuin lähde voittaa (kiinteä lähdeprioriteettijärjestys määrää, minkä järjestelmän arvot ovat auktoritatiivisia kullekin attribuutityypille) ja täydellisin voittaa (arvo lähteestä, jolla on pienin null-määrä kyseiselle attribuutille). Käytännössä tuotannon MDM-järjestelmä yhdistää sääntöjä: yksikön sijoitus on auktoritatiivinen C2-järjestelmästä, kunnossapidon tila logistiikkajärjestelmästä ja tunnisteattribuutit (sarjanumero, nimeke) materiaalivastuun järjestelmästä. Kunkin kultatietueen attribuutin mukana tulee luottamusarvo ja alkuperäviite, joka kertoo, mikä lähde toimitti arvon ja milloin se viimeksi vahvistettiin. Matalan luottamuksen vastaavuksista tai tunnetusti huonolaatuisista lähteistä johdetut attribuutit saavat alhaisemman luottamusarvon, mikä näkyy alaspäin suuntautuville käyttäjille, jotka arvioivat entiteettitietojen luotettavuutta.

Mitä datanhallintavastuu tarkoittaa ja miten se toimii puolustuksen MDM-käyttöönotossa?

Datanhallintavastuu on ihmisten hallintakerros, joka ratkaisee vastaavuus- ja attribuuttiristiriidat, joita automaattinen MDM-järjestelmä ei pysty ratkaisemaan riittävällä varmuudella. Data steward on henkilö, jolla on toimialan osaamista ja järjestelmäpääsyvaltuuksia ja joka tarkastelee epäselviä vastaavuuksia, ratkaisee ristiriitaiset attribuuttiarvot ja hyväksyy tai hylkää ehdotetut kultatietuerakenteet. Puolustuksen MDM-käyttöönotossa vastuu on jaettu entiteettialueittain: kalustovastuuhenkilöllä on valta kalustoalueeseen ja hän tyypillisesti kuuluu materiaalivastuun tai logistiikan toimintoon; henkilöstövastuuhenkilöllä on valta henkilöalueeseen ja hän tyypillisesti kuuluu henkilöstöhallinnon tai HR-toimintoon. Riidanratkaisuprosessi reitittää matalan luottamuksen vastaavuuspäätökset ja arvokkaat attribuuttiristiriidat asianomaisen vastuuhenkilön jonoon rakennettuna tapauspaketinä: ehdokastietueet kustakin lähteestä, kenttätason samankaltaisuusarvot kullekin vertailulle attribuutille, automaattinen suositus ja vaihtoehtoiset ratkaisut, joista vastuuhenkilö voi valita. Vastuuhenkilön päätös kirjataan MDM:n auditointijälkeen yhdessä hänen identiteettinsä, tehdyn päätöksen ja perustelunsa kanssa. Tämä auditointijälki on sekä operatiivinen kirjaus että hallinnon asiakirja, joka osoittaa, että kultatietueen on tarkastanut valtuutettu toimialan asiantuntija.

Miten MDM olisi arkkitehtoitu selviytymään yhteydettömässä eteenpäin sijoitetussa ympäristössä?

MDM:n toimintakyky yhteydettömissä ympäristöissä edellyttää porrastettua arkkitehtuuria, jossa kevyt MDM-välimuisti sijoitetaan eteenpäin rinnalle niille taktisille järjestelmille, joita se palvelee, ja auktoritatiivinen MDM-hub pysyy takalinjassa. Eteenpäin sijoitettu välimuisti sisältää ennalta sijoitetun tilannekuvan entiteettipääaineistosta — kultatietueet ja ristiviitetaulukon niistä entiteeteistä, jotka liittyvät eteenpäin sijoitetun elementin toiminta-alueeseen ja tehtäväorganisaatioon. Yhteydettömän ympäristön taktiset järjestelmät kysyvät paikallisesta välimuistista entiteettien yhdistämistä eivätkä vaadi verkkoyhteyttä keskushubiin. Kun eteenpäin sijoitettu elementti toimii yhteydettömästi, kaikki muutokset entiteettitietueisiin kirjataan paikalliseen muutoslokiin — rajoitettuun jonoon luonti-, päivitys-, yhdistä- ja jakamistapahtumia — eivätkä katoa. Yhteyden palautuessa muutosloki lähetetään keskushubiin, joka soveltaa determinististä ristiriitojenratkaisuprotokollaa yhdistääkseen eteenpäin sijoitetut päivitykset muihin muutoksiin, jotka ovat tapahtuneet hubissa tai muissa eteenpäin sijoitetuissa solmuissa yhteydettömän jakson aikana. Ristiriitojenratkaisu soveltaa oletuksena aikaleimapohjaista järjestystä ja vastuuhenkilön avustamaa ratkaisua, kun sama entiteettiattribuutti päivitettiin molemmin puolin yhteydettömän ikkunan aikana.

Mikä ero on deterministisellä ja todennäköisyyspohjaisella entiteettivastaavuudella?

Deterministinen vastaavuus soveltaa kiinteää sääntöjoukkoa, jossa vastaavuuspäätös on binäärinen — joko kaksi tietuetta täyttää kaikki vastaavuuskriteerit tai ei. Deterministinen sääntö kalustotietueille voi kuulua: kaksi tietuetta vastaa toisiaan jos ja vain jos niiden sarjanumerot ovat identtiset välilyönnit poistettuaan ja kirjainkoko normalisoituna, ja niiden kansalliset varastotunnisteet (NSN) ovat yhtäpitävät ensimmäiseen yhdeksään numeroon. Deterministiset säännöt ovat helppoja auditoida, eivät tuota vääriä vastaavuuksia, kun sääntö on määritetty oikein, eivätkä vaadi koulutusaineistoa. Ne ovat oikea valinta attribuuteille, jotka on tarkoitettu globaalisti yksilöiviksi tunnisteiksi ja joita ylläpitävät auktoritatiiviset lähteet. Todennäköisyyspohjainen vastaavuus laskee painotetun yhdistelmäarvon useista kenttävertailuista, joista kunkin tulos on osittainen samankaltaisuusarvo eikä binäärinen kyllä/ei. Henkilöstötietueen vertailu voi painottaa sukunimen foneettista samankaltaisuutta arvolla 0,35, etunimen samankaltaisuutta arvolla 0,25, syntymäaajan tarkkaa vastaavuutta arvolla 0,30 ja yksikön sijoitusta arvolla 0,10, ja tuottaa näin yhdistelmäarvon, jota verrataan säädettyyn vastaavuuskynnysarvoon. Kynnysarvon ylittävät tietueet ovat ehdokasvastaavuuksia; tarkastusvyöhykkeellä juuri kynnysarvon alapuolella olevat tietueet ohjataan vastuuhenkilölle. Todennäköisyyspohjainen vastaavuus hallitsee puolustusjärjestelmien likaisen datan todellisuuden — tietueet, joissa on kirjoitusvirheitä, nimen kirjoitusasuvaihteluja, puuttuvia kenttiä tai epäjohdonmukaista koodausta — joissa deterministiset säännöt tuottaisivat kohtuuttoman korkeita ohitusmääriä.

Miten kultatietueen muutokset auditoidaan puolustuksen MDM-järjestelmässä?

Jokainen kultatietueen muutos puolustuksen MDM-järjestelmässä on tallennettava muuttumattomaan auditointijälkeen, joka kirjaa vaikuttuneiden attribuuttien täydellisen ennen- ja jälkeen-tilan, muutoksen lähteen (automaattinen arvonvalintasääntö, manuaalinen vastuuhenkilön päätös tai saapuva lähdejärjestelmäpäivitys), muutoksen valtuuttaneen päähenkilön identiteetin (järjestelmän palvelutili automaattisille muutoksille, todennettu ihmisen identiteetti vastuuhenkilön päätöksille), muutoksen aikaleiman ja viitteen siihen lähtetapahtumaan, joka laukaisi sen (sisääntostoerän tunnus automaattisille päivityksille, vastuuhenkilön tapaustunnus manuaalisille päätöksille). Auditointijälki tallennetaan vain lisäysmuodossa — olemassa olevia auditointitietueita ei voi koskaan muuttaa tai poistaa, vain uusia tietueita voi liittää. Tämä muuttumattomuus varmistetaan tallennuskerroksessa objektilukituksella tai tietokantatason kirjoita-kerran-käytänteillä eikä luoteta pelkkään sovelluskerroksen täytäntöönpanoon. Auditointijälki mahdollistaa kaksi kriittistä operatiivista käyttötapaa: minkä tahansa entiteetin kultatietueen tilan rekonstroinnin millä tahansa menneellä hetkellä (vastaus kysymykseen, mitä MDM-järjestelmä uskoi tämän yksikön kalustosta klo 06:00 tiettynä päivänä) ja nykyisen kultatietueen tietyn attribuuttiarvon alkuperän jäljittämisen takaisin siihen lähdejärjestelmäpäivitykseen ja sisääntostotapahtumaan, joka toi sen.

Miten lopullinen yhdenmukaisuus toimii puolustuksen MDM-järjestelmässä, jossa on useita yhteydettömiä solmuja?

Lopullinen yhdenmukaisuus puolustuksen MDM-käyttöönotossa tarkoittaa, että vaikka kaikki MDM-topologian solmut — keskushubi ja kaikki eteenpäin sijoitetut välimuistit — taataan konvergoituvan samaan entiteettitilaan yhteyden palauttamisen ja synkronoinnin jälkeen, ne voivat pitää eriäviä tiloja yhteydettömän jakson aikana. Yhdenmukaisuusmalli on tarkoituksella höllennetty vahvasta yhdenmukaisuudesta (jossa kaikki solmut ovat samaa mieltä nykytilasta kaikkina aikoina), koska vahva yhdenmukaisuus edellyttää jatkuvaa verkkoyhteyttä, mikä on ristiriidassa yhteydettömän toiminnan vaatimuksen kanssa. Lopullisen yhdenmukaisuuden mallissa kukin solmu käsittelee päivityksiä paikallisesti ja kirjaa ne muutoslokiinsa. Muutoslokit käyttävät vektorikelloja tai hybridilogiikkakelloja seinäkelloaikaleimojen sijaan, jotta voidaan muodostaa osittainen järjestys tapahtumille solmujen välillä ilman synkronoituja kelloja — vaatimus, joka on realistinen eteenpäin sijoitetuissa ympäristöissä, joissa NTP-synkronointi voi olla käyttämätön. Yhteyden palautuessa hub kerää muutoslokit kaikilta solmuilta, yhdistää ne soveltamalla osittaista järjestystä ja tuottaa konvergoituneen kultatietuetilan, joka sisältää kaikki päivitykset kaikilta solmuilta. Kun kaksi solmua teki ristiriitaisia päivityksiä samaan attribuuttiin yhteydettömän ikkunan aikana — tila, joka havaitaan tutkimalla vektorikellon osittaista järjestystä — ristiriita ratkaistaan määritetyllä arvonvalintasäännöllä (luotetuin lähde, viimeisin loogisen kellon mukaan) tai eskaloidaan vastuuhenkilölle, jos arvonvalintasääntö ei tuota selvää voittajaa. Konvergoitumisen jälkeen hub levittää yhdistetyn tilan takaisin kaikkiin solmuihin, jotta ne synkronoituvat uudelleen yhdenmukaiseen näkymään.