Офіцер із логістики батальйонного рівня запитує звіт про боєготовність. У системі C2 за підрозділом закріплено 47 транспортних засобів. Система обліку майна фіксує 51 транспортний засіб під тим самим ідентифікатором підрозділу. Система технічного обслуговування відстежує 44 із них за іншими форматами серійних номерів, а три позначено як непридатні до експлуатації під ідентифікаторами, яких немає в жодній із двох інших систем. Ніхто не може відповісти на запитання «скільки справних транспортних засобів має цей підрозділ просто зараз» без телефонного дзвінка — адже ті самі фізичні об'єкти представлені різними записами, різними ідентифікаторами та різними значеннями атрибутів у системах, які ніколи не проєктувалися так, щоб узгоджуватися між собою.

Це проблема MDM в оборонній сфері в її найпоширенішому вигляді. Керування основними даними (MDM) — це дисципліна, що створює єдине авторитетне подання кожної ключової сутності — особи, організації, техніки, локації, — на яке всі системи посилаються узгоджено. Це не інструмент звітності й не сховище даних. Це шар, завдяки якому з'єднання даних між системами стають змістовними, багатодоменна аналітика — достовірною, а оперативні рішення на основі даних — надійними. Ця стаття розглядає архітектуру системи MDM для оборонної сфери: від вибору моделі хаба через розпізнавання сутностей, побудову еталонних записів і робочі процеси стюардства до вимог живучості, які роблять MDM життєздатною в умовах протидії противника.

Проблема MDM в оборонній сфері — записи про техніку в трьох системах із трьома різними ідентифікаторами, розбіжність записів про особовий склад між HR і C2, ціна неузгодженості

Оборонні організації накопичують фрагментацію джерел істини органічно. Систему HR закупили для керування кадровим адмініструванням. Систему C2 створили для відстеження структури підрозділів і тактичних призначень. Систему логістики спроєктували для керування постачанням і обліком майна. Кожну розробляв окремий офіс програми, розгортали її в різні десятиліття, і кожна використовує власну модель даних. Жодну не проєктували з розрахунку на інтероперабельність з іншими на рівні ідентичності сутностей.

Наслідком є набір схем ідентифікаторів, несумісних за задумом. Особу можуть ідентифікувати за особистим номером у HR, за поєднанням коду військово-облікової спеціальності та звання в C2 і за ідентифікатором відповідального за майно в логістиці — три ідентифікатори для однієї людини без відображення між ними, яке підтримувала б якась із систем. З технікою гірше: танк M1A2 може мати бортовий номер, нанесений трафаретом на корпус (його використовують екіпаж і оператори C2), код адреси діяльності Міністерства оборони США в логістиці, штрих-код унікального ідентифікатора одиниці (UII) в обліку майна та номер наряду на технічне обслуговування в системі керування технічним обслуговуванням. Жодні два з цих ідентифікаторів не мають однакового формату, а системи, що ними користуються, не створювалися для перетворення між ними.

Ціна цієї неузгодженості — не лише незручності. Коли аналітик боєготовності з'єднує дані про призначення підрозділів із C2 з даними про постачання з логістики, щоб обчислити показник оперативної спроможності підрозділу, з'єднання не зіставляє записи, що стосуються тієї самої фізичної техніки під різними ідентифікаторами. Отриманий показник спроможності хибний — і хибний у напрямку, який аналітик не може виявити без незалежної перевірки кожної системи, що зводить нанівець мету аналітичної моделі. Щоб побачити цілісну картину того, як ці збої інтеграції проявляються в ширшій архітектурі даних, див. наш розгляд шаблонів інтеграції даних в оборонній сфері.

Розбіжність записів про особовий склад між HR і C2 — це додаткова, окрема проблема. HR веде адміністративний запис: постійне звання, посаду, призначений підрозділ, рівень допуску, історію підготовки. C2 веде оперативну картину: яка особа фізично перебуває в якому підрозділі, яку роль вона виконує в поточній оперативній структурі, до експлуатації яких систем вона допущена. У стабільних умовах постійної дислокації ці записи узгоджуються досить добре. Під час операцій — коли особовий склад приданий різним підрозділам, коли оперативна структура відхиляється від штатно-табельної структури (TO&E), коли тимчасові відрядження створюють додаткові приналежності — обидва записи швидко розходяться. Система MDM, що керує сутністю «особа», має узгодити і адміністративне, і оперативне подання в цілісний еталонний запис, придатний і для звітності про боєготовність, і для оперативного планування.

Архітектура хаба MDM — порівняння моделей хаба «реєстр», «консолідація» та «співіснування», критерії вибору для оборонних середовищ, розміщення хаба для секретних і несекретних даних

У промислових розгортаннях MDM переважають три моделі хаба, кожна з яких має власний характер зв'язку з вихідними системами, які вона обслуговує, і власний набір експлуатаційних компромісів, важливих для оборонних середовищ.

Модель реєстру зберігає лише таблицю перехресних посилань — відображення ідентифікатора кожної вихідної системи на глобальний ідентифікатор сутності, призначений MDM, — без реплікації чи зберігання будь-яких атрибутів сутностей у самому хабі. Коли споживачеві потрібні дані сутності, він запитує в хабі глобальний ідентифікатор, а потім звертається до відповідних вихідних систем, використовуючи специфічні для джерела ідентифікатори, повернені перехресним посиланням. Модель реєстру має найменший обсяг збережених даних і не потребує синхронізації даних атрибутів у хаб, що робить її привабливою для середовищ, де реплікація секретних даних до центрального місця викликає питання авторизації. Її обмеження в тому, що вона змушує кожного споживача розв'язувати сутності між кількома вихідними системами під час виконання запиту, що операційно непрактично для оперативних запитів із високою частотою.

Модель консолідації копіює та нормалізує атрибути сутностей з усіх вихідних систем, що надають дані, у хаб, виконує розпізнавання сутностей для зв'язування дублікатів і надає споживачам єдине подання сутності. Вихідні системи не змінюються — хаб є оптимізованим для читання споживачем вихідних даних, а не записувачем назад у них. Ця модель найпрактичніша для оборонних середовищ, оскільки не потребує прав на змінювання вихідних систем (системи C2, HR і логістики зазвичай не можна змінювати з боку програми MDM) і зосереджує обчислення розпізнавання сутностей у хабі, а не розподіляє їх між споживачами. Архітектура військового озера даних зазвичай споживає еталонні записи консолідаційного хаба MDM як перевірений довідковий шар, а не з'єднує безпосередньо необроблені таблиці джерел.

Модель співіснування додає до моделі консолідації можливість зворотного запису: хаб будує еталонний запис, а потім розповсюджує авторитетні значення атрибутів назад у вихідні системи, перезаписуючи локально підтримувані значення авторитетним значенням, визначеним хабом. Ця модель забезпечує найсильнішу узгодженість між системами, але вимагає, щоб кожна вихідна система-учасниця приймала записи, ініційовані хабом, — а ця вимога часто блокується обмеженнями авторизації систем, процесами контролю змін з боку постачальників і операційною несхильністю до ризику в діючих системах.

Розміщення хаба для секретних і несекретних даних вимагає окремих екземплярів хаба на кожній межі рівня секретності. Єдиний хаб MDM, що обробляє і секретні, і несекретні дані сутностей, мав би працювати на вищому рівні секретності, а це не дозволило б несекретним споживачам отримувати з хаба жодні дані сутностей і звело б нанівець його призначення. Практична архітектура розгортає несекретний хаб для сутностей, що повністю існують у несекретних вихідних системах (загальні довідкові дані, несекретні дані про локації, записи про комерційних постачальників), і секретний хаб на відповідному рівні секретності для сутностей, що мають секретні атрибути. Розпізнавання сутностей між рівнями секретності — визначення того, що сутність у несекретній системі відповідає тій самій фізичній сутності в секретній системі, — потребує спеціалізованого охоронного шлюзу міждоменного рішення (cross-domain solution), який переносить через межу рівнів секретності лише перехресне посилання на ідентифікатори і ніколи — самі секретні атрибути.

Типи сутностей MDM в оборонній сфері — особа (військовослужбовці), організація (підрозділ/командування), техніка (платформа/кінцевий виріб), локація (об'єкт/позиція)

MDM в оборонній сфері керує чотирма основними доменами сутностей, кожен з яких має власні вихідні системи, схеми ідентифікаторів, структури атрибутів і проблеми якості даних.

Домен сутності «особа» охоплює військовослужбовців, підрядників і партнерів по коаліції. Ключові вихідні системи — система керування особовим складом (адміністративний запис, постійне призначення, звання), система C2 (поточне оперативне призначення, позиція в оперативній структурі) та система керування допусками (рівень допуску, дозволи за компартментами, терміни закінчення дії доступу). Основна проблема ідентифікаторів полягає в тому, що та сама особа може фігурувати в HR за підрозділом постійної служби, водночас будучи оперативно приданою до іншого підрозділу в C2 — обидва записи правильні у своїх системах, але відображають два різні оперативні стани тієї самої сутності. Під час побудови еталонного запису для домену «особа» слід фіксувати і адміністративний, і оперативний стани як окремі групи атрибутів, а не зводити їх до єдиного поля призначення до підрозділу.

Домен сутності «організація» охоплює підрозділи, командування, складові підрозділи та оперативні групи. Організації в оборонних середовищах мають ієрархічну структуру «батьківський–дочірній» (бригада складається з батальйонів, батальйон — з рот) і часовий вимір (оперативні групи створюються, зливаються, реорганізуються та розформовуються в операційних часових масштабах). Система MDM має підтримувати поточну організаційну ієрархію, її історичні стани на минулі моменти часу та зв'язки між адміністративною структурою TO&E і поточною оперативною структурою. Вихідні системи — ієрархія підрозділів у системі C2, TO&E в системі керування особовим складом і запис командного елемента в системах логістики.

Домен сутності «техніка» охоплює платформи, транспортні засоби, системи озброєння та облік кінцевих виробів. На практиці це найбільш фрагментований за ідентифікаторами домен: один фізичний предмет зазвичай має чотири або більше різних схем ідентифікаторів у системах, що ним керують. UII (унікальний ідентифікатор одиниці) — це стандартний глобально унікальний штрих-код Міністерства оборони США для одиниць техніки з серійними номерами, який має слугувати головним ідентифікатором для домену техніки, але успадковані системи, що з'явилися раніше за стандарт UII, використовують власні ідентифікатори, для зв'язування яких із простором UII потрібна таблиця відображення. Зіставлення між системами потребує нечіткого зіставлення за полями серійних номерів, які залежно від того, яка система зафіксувала ідентифікатор, можуть містити різні символи-роздільники, провідні нулі або префікси коду виробника.

Домен сутності «локація» охоплює об'єкти, військові бази, іменовані райони інтересу та тактичні позиції. Зіставлення локацій — це насамперед геопросторова задача: те саме фізичне місце може бути задане координатами MGRS в одній системі, географічними координатами в десяткових градусах в іншій і назвою місця природною мовою в третій. Геопросторове блокування групує записи-кандидати про локації за близькістю за допомогою сітки геохешу, а зіставлення визначає, чи стосуються два просторово близькі записи того самого об'єкта, чи різних сусідніх локацій. Сутності локацій також мають часовий вимір — класифікація об'єкта, експлуатаційний статус і сторона, що контролює об'єкт, змінюються з часом, — тому еталонний запис має містити інтервали часової чинності для ключових атрибутів локації. Шар злиття розвідданих у реальному часі, який співвідносить виявлення ISR із відомими локаціями, прямо залежить від точності й повноти основних даних про сутності локацій.

Розпізнавання сутностей: зіставлення між вихідними системами — стратегії блокування для великих оборонних наборів сутностей, ML-моделі зіставлення, детерміноване та імовірнісне зіставлення

Розпізнавання сутностей — це процес, що визначає, які записи в різних вихідних системах стосуються тієї самої сутності реального світу, і зв'язує їх спільним глобальним ідентифікатором. У масштабі великого оборонного набору даних — мільйони записів про техніку в системах логістики, технічного обслуговування та обліку майна; сотні тисяч записів про особовий склад у системах HR, C2 і допусків — наївне попарне порівняння всіх записів з усіма іншими обчислювально нездійсненне. Конвеєр зіставлення має бути побудований як двоетапний процес: блокування, що скорочує простір пар-кандидатів до керованого розміру, а потім зіставлення, що оцінює пари-кандидати з достатньою точністю, щоб відрізнити справжні збіги від майже-збігів.

Стратегії блокування для доменів сутностей в оборонній сфері використовують специфічні для домену ключі розбиття, щоб групувати записи, які цілком імовірно можуть бути тією самою сутністю. Для записів про особовий склад фонетичне блокування за полем прізвища з алгоритмом Soundex або Double Metaphone групує записи, де різні системи транскрибували те саме ім'я з варіантами написання, зайвими пробілами чи відмінностями у використанні дефісів — усе це поширено в системах керування особовим складом, що з'явилися до нормалізації Unicode. Для записів про техніку префіксне блокування за першими шістьма символами серійного номера (після нормалізації пробілів і регістру) групує записи із систем, які подають той самий серійний номер із різними умовностями щодо роздільників. Для записів про локації сітка геохешу з рівнем точності 6 (ширина клітинки приблизно 1.2 км) групує просторово близькі записи, виключаючи явно різні локації. Схему блокування необхідно перевірити на еталонному наборі даних відомих збігів до розгортання — етап блокування має зберігати в наборі кандидатів не менше ніж 95% справжніх пар-збігів, інакше конвеєр розпізнавання даватиме систематичні помилки пропуску для виключених типів записів.

У межах кожного блоку-кандидата модель зіставлення оцінює кожну пару:

  • Детерміноване зіставлення застосовує фіксований набір правил, що дає бінарне рішення «збіг / незбіг». Детерміноване правило для записів про техніку: два записи збігаються тоді й лише тоді, коли їхні штрих-коди UII ідентичні (після видалення нелітерно-цифрових символів) або коли їхні серійні номери ідентичні, а національні номенклатурні номери збігаються за першими дев'ятьма цифрами. Детерміновані правила не потребують навчальних даних, цілком піддаються аудиту та не дають жодних хибнопозитивних результатів, якщо правило задано правильно. Вони підходять для атрибутів, які мають бути глобально унікальними та підтримуються під контролем введення даних.
  • Імовірнісне зіставлення обчислює сукупну оцінку збігу за зваженими метриками подібності на рівні полів. Порівняння записів про особовий склад може застосовувати подібність Jaro-Winkler до імені, фонетичне зіставлення до прізвища, точний збіг за датою народження та нечітке зіставлення скорочення звання (щоб урахувати різні формати запису), у поєднанні з класифікатором на основі логістичної регресії або дерев із градієнтним бустингом, навченим на розмічених парах «збіг / незбіг» із реальних вихідних систем. Навчена модель вивчає відносну важливість кожного поля в конкретному середовищі з «брудними» даними — в одних вихідних системах дата народження дуже надійна; в інших вона має 3% помилок, що робить її слабкою розрізнювальною ознакою.
  • ML-моделі зіставлення розширюють імовірнісне зіставлення навченими поданнями тексту атрибутів сутностей. Сіамська нейронна мережа, навчена на парах імен особового складу, вивчає векторне подання імен таке, що фонетично чи орфографічно схожі імена мають схожі вектори, — вона виявляє закономірності подібності, які пропускають метрики відстані між рядками, створені вручну. ML-моделі потребують більших розмічених наборів даних для навчання та складніше піддаються аудиту, ніж детерміновані правила, але перевершують класичні імовірнісні моделі на високошумних наборах сутностей, де закономірності помилок введення даних складні й неоднорідні між вихідними системами.

Результатом роботи конвеєра зіставлення для кожної пари-кандидата є рішення про збіг (збіг / незбіг / перегляд) і оцінка достовірності. Пари вище порогу збігу автоматично зв'язуються під спільним глобальним ідентифікатором сутності. Пари із зони перегляду — де оцінка достовірності лежить між порогом незбігу та порогом збігу — спрямовуються до стюарда-людини для вирішення, а не розв'язуються автоматично.

Побудова та супровід еталонного запису — правила вибору значень для конфліктних атрибутів із різних джерел, оцінювання достовірності еталонного запису, автоматичне розв'язання та розв'язання за участі стюарда

Коли розпізнавання сутностей пов'язало записи з кількох вихідних систем з одним глобальним ідентифікатором сутності, система MDM будує еталонний запис: авторитетне, єдине подання цієї сутності, атрибути якого беруться з найкращого доступного джерела для кожного поля. Еталонний запис — це не просте злиття всіх атрибутів джерел: коли джерела розходяться, правило вибору значень (survivorship rule) має визначити, яке значення міститиме еталонний запис.

Правила вибору значень визначаються для кожного атрибута в кожному домені сутностей і кодують ієрархію авторитетності для цього атрибута:

# Правила вибору значень визначаються для кожного атрибута в кожному домені сутностей і кодують ієрархію авторитетності для цього атрибута # Сутність «техніка» — правила вибору значень за атрибутами 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 або логістика — залежно від того, яка з систем оновила запис останньою end_item_code: source_priority=[property_acct] # Єдине авторитетне джерело # Сутність «особовий склад» — правила вибору значень за атрибутами 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 або C2 залежно від типу призначення name_legal: source_priority=[hr_system] name_preferred: most_complete # Перемагає джерело з найменшою кількістю порожніх полів імені

Кожен атрибут еталонного запису, окрім власного значення, має три поля метаданих: посилання на джерело (яка вихідна система надала це значення та ідентифікатор конкретного вихідного запису), позначку часу оновлення (коли вихідна система востаннє підтвердила це значення) та оцінку достовірності (нормалізоване значення, що відображає надійність джерела та якість збігу, який пов'язав цей запис з еталонною сутністю). Оцінка достовірності 1.0 означає детермінований збіг за глобально унікальним ідентифікатором із високонадійного джерела; нижчі оцінки відображають результати імовірнісного зіставлення, джерела з відомими проблемами якості даних або атрибути, для яких вибір значень був спірним між джерелами з суперечливими значеннями.

Оцінка достовірності — не прикраса, вона має операційне значення. Аналітик боєготовності, який складає оцінку спроможності, може відфільтрувати запит до еталонного запису, виключивши атрибути нижче порогу достовірності, або аналітичний шар може зважувати внесок кожного запису про техніку в показник боєготовності підрозділу за достовірністю його атрибута статусу технічного обслуговування. Аналітик, який отримує показник боєготовності без доступу до відповідних оцінок достовірності, не може відрізнити високодостовірну оцінку від цифри, складеної з низькоякісних збігів і застарілих даних джерел.

Супровід еталонного запису — це безперервний процес, а не одноразова пакетна операція. Коли вихідна система оновлює запис сутності, конвеєр завантаження MDM отримує оновлення, повторно оцінює вибір значень для всіх зачеплених атрибутів і відповідно оновлює еталонний запис. Якщо оновлення призводить до зміни в еталонному записі атрибута, який уже спожили залежні системи, до шини подій MDM публікується сповіщення про зміну, щоб системи-споживачі могли повторно запитати оновлений еталонний запис. Сповіщення про зміну містить глобальний ідентифікатор сутності, перелік змінених атрибутів і значення до та після — достатньо інформації, щоб система-споживач визначила, чи зачіпає зміна будь-які її активні оперативні дані, без повного повторного отримання еталонного запису.

Робочі процеси стюардства даних — призначення стюардів за доменами (стюард техніки, стюард особового складу), процес розв'язання спорів, журнал аудиту змін еталонних записів

Автоматичне розпізнавання сутностей і правила вибору значень обробляють більшість випадків зіставлення та конфліктів атрибутів у робочій системі MDM — зазвичай від 85 до 95 відсотків записів можна розв'язати без втручання людини, коли конвеєр зіставлення добре відкалібровано під дані конкретних вихідних систем. Решту випадків, від 5 до 15 відсотків — збіги з низькою достовірністю, спірні значення атрибутів, де кілька джерел претендують на однакову авторитетність, та розділення чи злиття сутностей, що потребують оціночного рішення, — необхідно спрямовувати до стюарда даних-людини для вирішення.

Стюардство організовано за доменами сутностей: кожен домен закріплено за стюардом, який має і фахову експертизу в домені, і повноваження доступу до систем, потрібні для розв'язання спорів:

  • Стюард техніки — зазвичай працює в межах функції обліку майна або логістики, має повноваження визначати правильний запис про техніку, коли системи розходяться щодо серійних номерів, призначення до підрозділу чи коду технічного стану. Стюард техніки має безпосередній доступ до фізичних записів і може перевірити фактичний стан справ, звернувшись до первинної паперової документації або узгодивши це з особами, відповідальними за закріплену техніку.
  • Стюард особового складу — зазвичай працює в межах функції HR або керування особовим складом, має повноваження розв'язувати суперечності в написанні імен, дублікати записів про особовий склад (поширені, коли особа повторно вступає на службу й отримує новий згенерований системою ідентифікатор) та розбіжності щодо призначень між адміністративними й оперативними записами.
  • Стюард організацій — зазвичай штабний елемент J1 або J3, має повноваження розв'язувати неоднозначності в ієрархії підрозділів під час змін оперативної структури, підтверджувати дати створення та розформування підрозділів і вирішувати питання призначення вищого підрозділу, коли складові підрозділи тимчасово придані до кількох штабів.
  • Стюард локацій — зазвичай функція геопросторової розвідки або керування об'єктами, має повноваження підтверджувати, чи два просторово близькі записи відображають один і той самий об'єкт, чи різні об'єкти, розташовані поруч, а також установлювати канонічні координати й назву для локації, яка фігурує під різними позначеннями в різних системах.

Робочий процес розв'язання спорів подає кожен кейс стюарда як структурований пакет. Пакет кейсу містить: записи-кандидати з кожної вихідної системи, які, на думку системи MDM, можуть стосуватися однієї сутності, оцінки подібності на рівні полів для кожного порівнюваного атрибута, автоматичну рекомендацію системи MDM (збіг, незбіг або рекомендоване переможне значення спірного атрибута) і наочне відображення того, де джерела збігаються та розходяться. Стюард обирає з наявних варіантів розв'язання — підтвердити автоматичну рекомендацію, перевизначити її альтернативним розв'язанням або позначити кейс як такий, що потребує додаткової інформації, перш ніж його можна розв'язати. Поле довільного тексту для обґрунтування дає змогу стюарду задокументувати міркування щодо неочевидних рішень.

Журнал аудиту змін еталонних записів фіксує кожен перехід стану в історії еталонного запису незалежно від того, чи було зміну ініційовано автоматичним оновленням за правилами вибору значень, чи ручним рішенням стюарда. Кожен запис аудиту містить:

  • Глобальний ідентифікатор сутності та домен сутності
  • Змінений атрибут (або атрибути) та значення до й після для кожного з них
  • Ініціатор зміни: автоматичне правило вибору значень (з ідентифікатором і версією правила), вхідне оновлення з джерела (з ідентифікатором вихідної системи та ідентифікатором вихідного запису) або рішення стюарда (з ідентифікатором кейсу стюарда)
  • Автентифікована ідентичність суб'єкта, відповідального за зміну, — службовий обліковий запис системи для автоматичних змін, автентифікована ідентичність стюарда для ручних рішень
  • Позначка часу зміни (значення логічного годинника для розподілених розгортань, фізичний годинник для розгортань з одним хабом)

Записи аудиту записуються в сховище лише для додавання й не можуть бути змінені після запису. Ця незмінність дає змогу системі MDM відновити повний стан будь-якого еталонного запису на будь-який момент у минулому, відтворюючи журнал аудиту від початкового створення запису вперед, — можливість, операційно необхідна, коли аналітикам потрібно оцінити, що система MDM вважала про сутність у конкретний історичний момент, і вимога відповідності для систем керування секретними сутностями.

Живучість MDM у середовищах без зв'язку — локальний кеш MDM для систем, розгорнутих на передовій, розв'язання конфліктів після відновлення зв'язку, модель кінцевої узгодженості для вузлів без зв'язку

Централізований хаб MDM, який для кожного запиту сутності потребує мережевого зв'язку з тиловим ешелоном, операційно непридатний в умовах протидії противника, де зв'язок погіршений або перерваний. Системи C2, системи логістики та засоби оперативного планування, розгорнуті на передовій, залежать від розпізнавання сутностей для правильної роботи — якщо хаб MDM недосяжний, вони мають повертатися до сирих ідентифікаторів джерел, які можуть не збігатися між системами, і тим самим повертати оперативну картину до стану до MDM з фрагментованою ідентичністю сутностей. Проєктування живучості MDM запобігає такому регресу, розгортаючи локальний кеш на передовій і визначаючи ретельний протокол синхронізації для фази відновлення зв'язку.

Передовий кеш MDM — це заздалегідь розміщена репліка для читання еталонних записів і таблиці перехресних посилань для підмножини сутностей, релевантної для оперативної сфери передового елемента. «Релевантна сфера» визначається двома вимірами: географічним районом операцій (усі сутності-локації в межах AO, усі сутності-техніка з останнім відомим місцезнаходженням у межах AO) та оперативною структурою (усі сутності «особа», «організація» й «техніка», пов'язані з підрозділами в оперативній структурі передового елемента). Кеш наповнюється до розгортання передового елемента з використанням експорту знімка з центрального хаба. Його розгортають на апаратному забезпеченні, що працює незалежно від територіально розподіленої мережі, — на сервері в захищеному виконанні, розміщеному поряд із передовим вузлом C2, або вбудованому в обчислювальне середовище тактичного командного пункту.

Під час роботи без зв'язку тактичні системи надсилають запити до локального кешу точно так, як надсилали б їх до центрального хаба, — той самий API, той самий формат відповіді. Запити на розпізнавання сутностей обслуговуються з локальної таблиці перехресних посилань. Запити до еталонних записів повертають кешовані значення атрибутів із позначкою часу актуальності, що вказує, коли кожен атрибут востаннє підтверджувався центральним хабом. Тактичні системи відповідають за показ цієї позначки часу актуальності користувачам, коли дані можуть бути застарілими, замість того щоб подавати кешовані дані так, ніби вони актуальні.

Усі створення, оновлення, злиття та розділення сутностей, що відбуваються в період відсутності зв'язку, записуються в локальний журнал змін — упорядковану обмежену чергу подій зміни сутностей. Кожна подія несе позначку часу за векторним годинником, що встановлює частковий порядок подій між вузлами без зв'язку без вимоги синхронізованих фізичних годинників. Ємність журналу змін обмежує тривалість роботи без зв'язку: журнал змін, розрахований на 72 години типових оперативних темпів оновлення сутностей, забезпечує 72 години автономної роботи, після чого синхронізація стає обов'язковою, щоб запобігти переповненню журналу. Процес оперативного планування має враховувати це обмеження.

Протокол синхронізації після відновлення зв'язку працює у три фази, коли передовий елемент відновлює мережевий зв'язок із центральним хабом:

Фаза 1 — Передавання журналу змін: передовий вузол передає свій повний журнал змін до центрального хаба. Хаб підтверджує отримання та присвоює кожній події глобальний порядковий номер. Передовий вузол продовжує обслуговувати локальні запити з кешу під час цієї фази. Фаза 2 — Виявлення та розв'язання конфліктів: хаб відтворює журнал змін передового вузла щодо свого поточного стану сутностей. Для кожної події з передового вузла хаб перевіряє, чи оновлювався той самий атрибут на хабі або на іншому передовому вузлі в період відсутності зв'язку. Немає конфлікту: зміну з передового вузла застосовують як є. Конфлікт (той самий атрибут оновили два джерела): застосувати налаштоване правило вибору значень (найнадійніше джерело, найпізніший логічний годинник). Якщо правило вибору значень не визначає однозначного переможця: спрямувати до черги стюарда. Фаза 3 — Повторна синхронізація кешу: хаб передає злитий стан сутностей після розв'язання конфліктів до передового кешу. Передовий кеш замінює свій знімок злитим станом. Хаб передає розв'язаний журнал змін усім іншим передовим кешам, щоб вони також отримали оновлення, що виникли на цьому передовому вузлі. Усі вузли підтверджують отримання, перш ніж хаб позначить цикл синхронізації завершеним.

Модель кінцевої узгодженості, що лежить в основі цієї архітектури, надає гарантію: після відновлення зв'язку та успішного завершення протоколу синхронізації всі вузли топології MDM — центральний хаб і всі передові кеші — мають ідентичний стан сутностей. У період відсутності зв'язку вузли можуть розходитися. Протокол синхронізації спроєктовано так, щоб розбіжність була обмеженою, виявлюваною та розв'язуваною без втрати даних: жодне оновлення сутностей, зроблене в період відсутності зв'язку, не відкидається, а лише переупорядковується й потенційно перевизначається правилом вибору значень, що застосовує визначену організацією ієрархію авторитетності.

Операційний наслідок полягає в тому, що аналітики й системи, які використовують передовий кеш у період відсутності зв'язку, мають розуміти, що працюють зі знімком невизначеної актуальності. Передовий кеш має надавати поле «час останньої синхронізації» на рівні кешу та позначку «останнє підтвердження» на рівні окремого атрибута еталонного запису, даючи залежним системам інформацію, потрібну для подання відповідних застережень щодо достовірності, коли оперативні рішення залежать від даних сутностей, які нещодавно не підтверджував центральний хаб. Оцінка боєготовності підрозділу, побудована на еталонних записах техніки зі знімком 12-годинної давності та 71-годинним періодом відсутності зв'язку, заслуговує на інший рівень довіри, ніж оцінка, побудована на записах, синхронізованих за 30 хвилин до її створення. Зробити цю відмінність видимою в даних — а не ховати її за єдиним поданням атрибутів еталонного запису — і означає зробити MDM корисною, а не оманливою в оперативних середовищах із протидією противника.