У 2022–2025 роках Україна провела те, що можна назвати найінтенсивнішим і найстисненішим розгортанням оборонних технологій в сучасній військовій історії. Зіткнувшись зі звичайним противником рівного рівня, що мав значні можливості в радіоелектронній боротьбі та протиповітряній обороні, українські військові інститути адаптувалися швидше, ніж будь-яка порівнянна організація після Другої світової війни. Результатом є сукупність операційних уроків щодо цифрової трансформації в обороні, які не може відтворити жодна кількість консультантів з трансформації та вправи з дорожніми картами.
Для розуміння цих уроків необхідно вийти за межі конкретних платформ, що виникли, — додатків для дронів, засобів управління вогнем артилерії, систем ситуаційної обізнаності — і вивчити структурні умови та рішення, що уможливили швидку адаптацію. Ці умови і рішення є передаваними. Конкретні інструменти — ні.
Швидкість проти процесу: стиснення часових рамок закупівель
Традиційні процеси оборонних закупівель в країнах — членах НАТО відбуваються в часових рамках, що вимірюються роками. Фази визначення вимог, огляду ринку, формального тендеру, оцінки, присудження контракту та доставки разом зазвичай займають три-сім років для значних програм програмного забезпечення. Україна не могла оперувати в цих часових рамках. Країна перебувала в прямому конфлікті з противником, який адаптував власну тактику протягом тижнів. Тому українські оборонні інститути мали знайти способи тестування, прийняття та інтеграції програмних інструментів у часових рамках, що вимірюються тижнями та місяцями.
Механізми, що забезпечили цю швидкість, є повчальними. По-перше, повноваження на затвердження та оплату програмних інструментів були різко знижені — командири батальйонів і бригад могли випробовувати та оплачувати програмні інструменти без проходження через центральний процес закупівель. По-друге, толерантність до недосконалих інструментів була значно вищою, ніж у мирний час закупівель. По-третє, зворотній зв'язок між операційними користувачами та розробниками програмного забезпечення був різко коротшим — в деяких випадках розробники були вбудовані в підрозділи, отримуючи зворотній зв'язок і випускаючи оновлення в добових циклах.
Ключові платформи, що виникли під операційним тиском
Система ситуаційної обізнаності Delta ілюструє модель розробки під операційним тиском. Delta не проектувалася комітетом з вимог. Вона виникла з практичних потреб українських командирів, яким потрібно було ділитися спільною оперативною картиною між підрозділами без централізованої мережевої інфраструктури. Архітектура системи відображає обмеження, в умовах яких вона будувалася: вона працює через цивільні мобільні мережі, коректно деградує при поганому зв'язку і працює на комерційних планшетах, якими вже вміють користуватися оператори.
Роль Starlink у військових комунікаціях України добре задокументована, але менш обговорюваний урок полягає в тому, наскільки швидко українські військові користувачі адаптували комерційний супутниковий інтернет до військових комунікаційних робочих процесів. Здатність була прийнята, адаптована та оперативно інтегрована швидше, ніж будь-яка формальна програма придбання військових комунікацій могла б рухатися. Урок полягає не в тому, щоб "використовувати Starlink" — він у тому, що архітектура військових комунікаційних систем має бути здатна швидко включати нові технології носіїв без необхідності повного переінженерінгу програм, що на них працюють.
Уроки архітектури програмного забезпечення: офлайн-першість, API-першість, модульність
Дизайн офлайн-першим не є опціональним. Кожен програмний інструмент, який був успішно розгорнутий в Україні, мав функціонувати з деградованим або відсутнім підключенням. Програми, що вимагали надійного мережевого з'єднання для функціонування, просто не витримали зіткнення з російською РЕБ. Патерн архітектури офлайн-першим — де локальна робота є стандартом, а мережеве підключення використовується опортуністично — виявився передумовою для операційного розгортання, а не необов'язковою функцією.
Архітектура API-першою забезпечує інтеграцію без координації. Найуспішніші українські оборонні технологічні інструменти були розроблені навколо відкритих API, що дозволяли іншим системам обмінюватися даними без двосторонніх угод про інтеграцію. Це означало, що коли з'являвся новий інструмент, що міг надавати корисні дані до існуючої системи, інтеграція могла відбутися без прямої координації команд за кожною системою.
Модульність зменшує вартість ітерації. Програми, побудовані як модульні компоненти, показали значно кращі темпи адаптації, ніж монолітні системи. Коли противник змінив тактику, що зламала конкретний компонент системи, модульна архітектура дозволила оновити і повторно розгорнути цей компонент, не торкаючись решти системи.
Ключовий висновок: Досвід України показує, що цифрова трансформація в обороні — це передусім не технологічна проблема, а проблема повноважень і зворотних зв'язків. Організації, що адаптувалися найшвидше, були тими, де повноваження на прийняття рішень були розподілені найближче до операційних користувачів, а зворотній зв'язок від цих користувачів доходив до розробників протягом годин, а не місяців.
Що можуть прийняти організації НАТО
Повна українська модель — розподілені повноваження на закупівлі, толерантність до недосконалих інструментів, вбудовані розробники — не є безпосередньо передаваною до мирних інститутів НАТО. Але кілька структурних уроків можна адаптувати.
Бюджети для експериментів з спрощеними шляхами схвалення. Кілька членів НАТО запровадили бюджетні рядки для інновацій, де підрозділи можуть випробовувати програмні інструменти за спрощеним шляхом схвалення без проходження через повний процес закупівель. Урок з України полягає в тому, що ці бюджети мають бути більшими, а шляхи схвалення — ще простішими.
Операційні зворотні зв'язки в контрактах на програмне забезпечення. Стандартні контракти НАТО на програмне забезпечення включають приймальне тестування та терміни виправлення дефектів, але зазвичай не включають структурованих механізмів збору і реагування на операційний зворотний зв'язок від користувачів. Введення контрактної вимоги для щоквартальних операційних оглядів зворотного зв'язку — із зобов'язаннями постачальника реагувати на пріоритетні операційні проблеми у визначені строки — привнесло б більше з української моделі розробки до стандартних закупівель.
Стандарти архітектури, що забезпечують модульність. Розширення керівництва FMN для вимоги модульних внутрішніх архітектур — з опублікованими внутрішніми API та розділенням функціональних компонентів — зробило б альянсні системи більш адаптованими без необхідності центральної координації кожної зміни.
Основний урок цифрової трансформації України полягає не в якій-небудь конкретній технології. Він полягає в умовах, за яких можлива швидка цифрова адаптація: розподілені повноваження, короткі зворотні зв'язки, толерантність до недосконалості на ранніх етапах та архітектурні вибори, що роблять ітерацію дешевою.