Vuosina 2022–2025 Ukraina toteutti kiistatta intensiivisimmän ja tiivistetyimmän puolustustekniikan käyttöönoton modernin sotahistorian aikana. Kohdatessaan tavanomaisen vertaisvastustajan, jolla on merkittäviä elektronisen sodankäynnin ja ilmapuolustuksen kykyjä, Ukrainan sotilasinstituutiot mukautuivat nopeammin kuin mikään vastaava organisaatio oli joutunut mukautumaan toisen maailmansodan jälkeen. Tuloksena on joukko operatiivisia oppeja puolustuksen digitaalisesta muutoksesta, joita mikään määrä muutoskonsultteja ja tiekarttaharjoituksia ei voi toisintaa.

Näiden oppien ymmärtäminen edellyttää katsomista syntyneiden yksittäisten alustojen ohi — drone-sovellusten, tykistön tulenjohtotyökalujen, tilannekuvajärjestelmien — ja niiden rakenteellisten edellytysten ja päätösten tarkastelua, jotka tekivät nopean mukautumisen mahdolliseksi. Nuo edellytykset ja päätökset ovat siirrettävissä. Yksittäiset työkalut eivät ole.

Nopeus vastaan prosessi: hankinta-aikataulun tiivistäminen

NATO-jäsenmaiden perinteiset puolustushankintaprosessit toimivat vuosissa mitattavilla aikatauluilla. Vaatimusten määrittely, markkinakartoitus, virallinen tarjouskilpailu, arviointi, sopimuksen myöntäminen ja toimitusvaiheet kestävät yhdessä tyypillisesti kolmesta seitsemään vuotta merkittävissä ohjelmisto-ohjelmissa. Ukrainalla ei ollut mahdollisuutta toimia näillä aikatauluilla. Maa oli suorassa konfliktissa vastustajan kanssa, joka mukautti omaa taktiikkaansa viikoissa. Ukrainan puolustusinstituutioiden oli siksi löydettävä keinoja testata, ottaa käyttöön ja integroida ohjelmistotyökaluja viikoissa ja kuukausissa mitattavilla aikatauluilla.

Tämän nopeuden mahdollistaneet mekanismit ovat opettavaisia. Ensinnäkin valtuudet hyväksyä ja maksaa ohjelmistotyökaluista työnnettiin huomattavasti alaspäin — pataljoonan- ja prikaatinkomentajat saattoivat kokeilla ja maksaa ohjelmistotyökaluista käymättä läpi keskitettyä hankintaprosessia. Tämä loi hajautetun kokeiluympäristön, jossa monia työkaluja arvioitiin samanaikaisesti todellisten käyttäjien toimesta operatiivisissa olosuhteissa, eikä keskitetyn arviointielimen toimesta valvotuissa olosuhteissa. Toiseksi epätäydellisten työkalujen sietokyky oli merkittävästi korkeampi kuin rauhanajan hankinnoissa. Työkalu, joka toimi 80 % käyttötapauksista ja oli saatavilla nyt, oli parempi kuin työkalu, joka toimisi 100 % käyttötapauksista ja olisi saatavilla kolmen vuoden kuluttua. Kolmanneksi palautesilmukka operatiivisten käyttäjien ja ohjelmistokehittäjien välillä oli huomattavasti lyhyempi — joissakin tapauksissa ohjelmistokehittäjät olivat sijoitettuina yksiköihin, saaden palautetta ja julkaisten päivityksiä päivittäisissä sykleissä.

Operatiivisesta paineesta syntyneet keskeiset alustat

Delta-tilannekuvajärjestelmä havainnollistaa operatiivisen paineen kehitysmallia. Deltaa ei suunnitellut vaatimuskomitea. Se syntyi ukrainalaisten komentajien käytännön tarpeista, joiden täytyi jakaa yhteinen operatiivinen tilannekuva yksiköiden välillä ilman keskitetysti hallittua verkkoinfrastruktuuria. Järjestelmän arkkitehtuuri heijastaa niitä rajoituksia, joiden alla se rakennettiin: se toimii siviilien mobiiliverkoissa, heikkenee hallitusti yhteyksien ollessa huonot ja toimii kaupallisilla tableteilla, joiden käytön käyttäjät jo osaavat. Nämä eivät ole sattumanvaraisia ominaisuuksia — ne ovat suora seuraus siitä, että järjestelmä suunniteltiin ja kehitettiin operatiivisissa olosuhteissa eikä testiympäristössä.

Starlinkin rooli Ukrainan sotilasviestinnässä on hyvin dokumentoitu, mutta vähemmän käsitelty oppi on se, kuinka nopeasti ukrainalaiset sotilaskäyttäjät mukauttivat kaupallisen satelliitti-internetin sotilasviestinnän työnkulkuihin. Kyky otettiin käyttöön, mukautettiin ja integroitiin operatiivisesti nopeammin kuin mikään virallinen sotilasviestinnän hankintaohjelma olisi voinut edetä. Oppi ei ole "käytä Starlinkiä" — se on, että sotilasviestintäjärjestelmien arkkitehtuurin on kyettävä sisällyttämään uusia kantotekniikoita nopeasti ilman, että niiden päällä toimivat sovellukset on suunniteltava kokonaan uudelleen.

Drone-sovellukset edustavat näkyvintä innovaatiota, mutta kiinnostavampi tekninen oppi on syntyneiden lähestymistapojen monimuotoisuudessa. Sen sijaan, että olisi kehitetty yksi standardoitu droonien ohjaus- ja tiedustelualusta, Ukraina kehitti kilpailullisen ekosysteemin sovelluksista, jotka oli optimoitu eri käyttötapauksiin — tiedustelulennokit, ensimmäisen persoonan näkymän (FPV) hyökkäyslennokit, logistiikkalennokit ja vastalennokkijärjestelmät kehittivät kukin oman ohjelmistopinonsa. Tämä monimuotoisuus oli joiltakin osin tehotonta, mutta tuotti nopeamman kokonaisoppimiskäyrän kuin keskitetty, standardoitu lähestymistapa olisi saavuttanut.

Ohjelmistoarkkitehtuurin opit: offline-first, API-first, modulaarisuus

Offline-first-suunnittelu ei ole valinnaista. Jokaisen Ukrainassa onnistuneesti käyttöönotetun ohjelmistotyökalun oli toimittava heikennetyn tai puuttuvan yhteyden kanssa. Sovellukset, jotka vaativat toimiakseen luotettavan verkkoyhteyden, eivät yksinkertaisesti selvinneet kosketuksesta venäläiseen elektroniseen sodankäyntiin. Offline-first-arkkitehtuurimalli — jossa paikallinen toiminta on oletus ja verkkoyhteyttä käytetään tilaisuuden tullen sen ollessa saatavilla sen sijaan, että siihen luotettaisiin — osoittautui operatiivisen käyttöönoton edellytykseksi, ei valinnaiseksi ominaisuudeksi.

API-first-arkkitehtuuri mahdollistaa integroinnin ilman koordinointia. Onnistuneimmat ukrainalaiset puolustusteknologiatyökalut oli suunniteltu avoimien API-rajapintojen ympärille, jotka antoivat muiden järjestelmien vaihtaa niiden kanssa tietoa ilman kahdenvälisiä integraatiosopimuksia. Tämä tarkoitti, että kun syntyi uusi työkalu, joka pystyi tuottamaan hyödyllistä tietoa olemassa olevalle järjestelmälle, integrointi saattoi tapahtua ilman, että kunkin järjestelmän takana olevien tiimien oli koordinoitava suoraan. Nopeasti muuttuvassa operatiivisessa ympäristössä kyky integroida uusia kykyjä ilman virallista koordinointiprosessia on valtavan arvokasta.

Modulaarisuus vähentää iteroinnin kustannuksia. Modulaarisina komponentteina rakennetut sovellukset — joissa yksittäisiä toimintoja voidaan päivittää tai korvata rakentamatta koko järjestelmää uudelleen — osoittivat merkittävästi parempia mukautumisasteita kuin monoliittiset järjestelmät. Kun vastustaja muutti taktiikkaa, joka rikkoi järjestelmän tietyn komponentin, modulaarinen arkkitehtuuri salli kyseisen komponentin päivittämisen ja uudelleen käyttöönoton koskematta muuhun järjestelmään. Monoliittiset järjestelmät vaativat täysiä uudelleenkäyttöönottosyklejä, jotka saattoivat kestää päiviä tai viikkoja.

Keskeinen oivallus: Ukrainan kokemus osoittaa, että puolustuksen digitaalinen muutos ei ole ensisijaisesti teknologiaongelma — se on valtuus- ja palautesilmukkaongelma. Nopeimmin mukautuneet organisaatiot olivat niitä, joissa päätösvalta oli hajautettu lähimmäs operatiivisia käyttäjiä ja joissa näiden käyttäjien palaute saavutti kehittäjät tunneissa eikä kuukausissa.

Mitä NATO-organisaatiot voivat omaksua

Täysi ukrainalainen malli — hajautettu hankintavalta, epätäydellisten työkalujen sietäminen, sijoitetut kehittäjät — ei ole suoraan siirrettävissä NATOn rauhanajan instituutioihin, jotka toimivat vastuuvelvollisuus- ja auditointivaatimusten alaisina, jotka tekevät epävirallisesta hankinnasta mahdotonta. Useita rakenteellisia oppeja voidaan kuitenkin mukauttaa.

Kokeilubudjetit yksinkertaistetuilla hyväksymispoluilla. Useat NATO-jäsenet ovat ottaneet käyttöön innovaatiobudjettirivejä — tyypillisesti 1–5 miljoonan euron vuosivälillä — joissa yksiköt voivat kokeilla ohjelmistotyökaluja yksinkertaistetulla hyväksymispolulla käymättä läpi täyttä hankintaprosessia. Yhdysvaltain AFWERX- ja Ison-Britannian Defence and Security Accelerator -ohjelmat noudattavat tätä mallia. Ukrainan oppi on, että näiden budjettien tulisi olla suurempia ja hyväksymispolkujen vielä yksinkertaisempia.

Operatiiviset palautesilmukat ohjelmistosopimuksissa. NATOn vakio-ohjelmistohankintasopimukset sisältävät hyväksymistestauksen ja vikojen korjausjaksot, mutta eivät tyypillisesti sisällä jäsenneltyjä mekanismeja operatiivisen käyttäjäpalautteen keräämiseksi ja siihen reagoimiseksi sopimuskauden aikana. Sopimusvaatimuksen käyttöönotto neljännesvuosittaisille operatiivisille palautekatselmuksille — toimittajan sitoumuksilla reagoida korkean prioriteetin operatiivisiin ongelmiin määriteltyjen aikarajojen sisällä — toisi enemmän ukrainalaista kehitysmallia vakiohankintaan.

Arkkitehtuuristandardit, jotka pakottavat modulaarisuuteen. NATOn Federated Mission Networking -kehys tarjoaa yhteentoimivuusstandardeja tiedonvaihtoon liittolaisjärjestelmien välillä. Se ei kuitenkaan tällä hetkellä määrää siihen kytkeytyvien järjestelmien sisäistä arkkitehtuuria. FMN-ohjeistuksen laajentaminen vaatimaan modulaarisia sisäisiä arkkitehtuureja — julkaistuilla sisäisillä API-rajapinnoilla ja toiminnallisten komponenttien erottelulla — tekisi liittouman järjestelmistä mukautuvampia ilman, että jokaista muutosta tarvitsisi koordinoida keskitetysti.

Kaksoisverkkoarkkitehtuuri. Ukrainan sotilasverkot kehittyivät nopeasti käyttämään sekä erityistä sotilasviestintää että kaupallisia mobiili-/satelliittiverkkoja, ja sovellukset oli suunniteltu käyttämään sitä, mikä kulloinkin oli saatavilla. NATOn verkkoarkkitehtuuri kohtelee edelleen kaupallisia verkkoja varajärjestelmänä rinnakkaisen resurssin sijaan. Sotilasohjelmistojen suunnittelu käyttämään kaupallista yhteyttä tilaisuuden tullen — asianmukaisilla turvavalvontatoimilla — lisäisi merkittävästi operatiivista sietokykyä.

Ukrainan digitaalisen muutoksen ydinoppi ei koske mitään tiettyä teknologiaa. Se koskee olosuhteita, joissa nopea digitaalinen mukautuminen on mahdollista: hajautettua valtaa, lyhyitä palautesilmukoita, epätäydellisyyden sietämistä alkuvaiheissa ja arkkitehtuurivalintoja, jotka tekevät iteroinnista edullista. Nämä olosuhteet voidaan luoda politiikkavalinnoilla, ei pelkästään teknologiainvestoinneilla.