Utvecklingen av hårdvara i det pågående kriget är ett omdiskuterat ämne, framför allt vad gäller hur lång (eller kort) teknikens livslängd förväntas vara. Vad som däremot inte lyfts i samma utsträckning är mjukvaran, att det är den som i själva verket avgör hur länge, och med vilken framgång, hårdvara kan användas. En snabbt implementerad programuppdatering kan över en natt förändra hur ett system fungerar, och därmed påverka dess taktiska egenskaper. Mjukvaran är precis lika påverkande för ett tekniskt system som ammunition är för ett vapensystem. Vapensystemets funktion är detsamma under lång tid, men genom att modifiera ammunitionen kan egenskaper som räckvidd och genomslag förändras. Vi behöver behandla mjukvara på samma sätt för att säkerställa att vi kan hänga med i utvecklingen och minska risken för att stå med föråldrade system i framtiden. Detta kräver en organisatorisk, kunskapsmässig och kulturell omställning.
Den traditionella upphandlingsmodellen av militära system har kretsat kring att Försvarsmakten köpt en komplett plattform med en specificerad funktionalitet. Därefter har en förmåga byggts kring den plattformen. Eventuella behov av förändringar av plattformen har därefter gått via tillverkaren, med långa ledtider för förändringar som följd. Försvarsföretagen har blivit mycket duktiga på att utveckla hårdvara, mjukvaran däremot har inte ägnats samma uppmärksamhet och Försvarsmakten har historiskt blivit låst till olika mjukvarulösningar där man köpt en ”svart låda”, oftast utan att ha möjlighet att påverka innehållet. Vilket inte är svårt att förstå då det är just hårdvaran som syns och som kan marknadsföras mot beslutsfattare. Att politiker fattar beslut om att köpa stridsflygplan och fregatter är en sak, det är något annat att falla in i perspektivet om en plattformscentrerad krigföring. Det leder lätt till jakten på ett ”wunderwaffe” och diskussioner om stridsvagnens död.
Mjukvarudefinierad krigföring är ett förhållningssätt där ett systems stridsvärde främst avgörs av dess mjukvara. Ett stridsvärde som förändras när koden uppdateras, inte när hårdvaran byts ut. En bedömning av förmågor är traditionellt plattformscentrerad där hårdvara är det som granskas medan mjukvaran är en underordnad detalj. Mjukvarudefinierad krigföring vänder på förhållandet: hårdvara är en bärare men det är koden som avgör vad systemet har för värde i striden. Medan den plattformscentrerade krigföringen mäter eldkraft och räckvidd, mäter mjukvarudefinierad krigföring uppdateringstakt. Den förskjutningen får följdeffekter för hela kedjan: anskaffning, utveckling, uppföljning, ledning och kompetens.
Programmeraren en vital del av verkanskedjan
För att kunna följa upp kod på samma sätt som ammunition måste den som skriver koden finnas nära striden. Det har alltid funnits ett långt avstånd mellan utvecklare av ett system och soldaten som ska nyttja systemet i striden. Ukraina och Ryssland har på olika sätt arbetat med att korta ner det avståndet. Antingen genom att det via sociala medier går att kommunicera direkt med utvecklarna eller att företagen aktivt åker till frontförbanden för att inhämta feedback. Oaktad metod är det fortfarande den traditionella leveranskedjan där företaget levererar förändringar till de militära styrkorna. Det adaptiva slagfältet kräver däremot en annan modell: det finns ett behov av tekniker och mjukvaruutvecklare organiskt på förbanden som kan genomföra modifikationer omgående. Det vill säga att feedback-loopen från det att en operatör upplever ett problem till att operatören får en lösning levererad blir betydligt kortare i tid och rum. Såväl drönare som stridsflyg behöver kunna konfigureras på dagen för att bibehålla momentum och övertag.
En starkt bidragande orsak till att exempelvis FPV-drönare fortsatt är framgångsrika kan förklaras med att lösningen bygger på ”open source” och öppen arkitektur. Mjukvaran är spridd, källkoden är tillgänglig för modifiering och brukaren är inte låst till en specifik leverantör av komponenter. I stället kan förbanden nyttja den hårdvara de kommer över och fortfarande få samma verkan. Brist på en komponent innebär inte att produktionslinan avstannar utan att den komponenten ersätts av någon annan. Öppna gränssnitt av det slaget är inte ovanliga i techindustrin, men i försvarsindustrin framstår det mer som en enhörning.
Versionsuppföljning som en del av förbandsrapporten
Om koden avgör stridsvärdet måste vi också veta vilken kod som körs var. Dagens krigföring består av algoritmer, AI-modeller, nätverk och databaser. Allt fler soldater är exponerade för olika former av grafiska gränssnitt och databehandling sker både molnbaserat och ”längst ut på linan” genom ”edge computing”. Därtill ser vi hur det på brigadnivå kan förekomma mjukvaruutveckling för att lösa lokala problem, det tydligaste exemplet är att modifiera mjukvara till drönare. Tiden mellan köp och leverans av materiel, även genom Brave1, innebär en risk att vissa mjukvaruinställningar är utdaterade och att den första åtgärden vid leverans är att modifiera kod. Detta medför att det blir viktigt att ha uppföljning på vilken mjukvaruversion som vilket förband använder, och vilken version som fungerar bäst mot vilket hot. Den här typen av uppföljning har indikerats i ryska telegramkanaler där man noterat att det inte nödvändigtvis är bättre att använda den senaste versionen av en applikation, utan att det på vissa frontavsnitt kan vara lämpligare att reversera till en äldre utgåva. Således kan det vara lika relevant att följa upp mjukvaruversioner som att följa upp tillgång på ammunition och reservdelar för respektive förband.
Mjukvarudefinierad krigföring ställer nya krav på styrning
Mjukvarudefinierad krigföring flyttar inte bara utvecklingen närmare förbandet, den flyttar också ansvaret dit. Den här typen av friheter kommer givetvis med kostnader och utmaningar. Inte sällan är snabb utveckling och säker utveckling varandra motsatser. Som tidigare nämnts befinner sig alla världens försvarsmakter i samma sits där det ställs krav på att vara anpassningsbar samtidigt som att organisationen ska vara effektiv. Precis som att perfektion hamnar i konflikt med tillgänglig tid, hamnar tillgänglig tid i konflikt med hur driftsäker en modifikation blir. Frågor som onekligen uppstår i samband med den här artikelns uppmaning om att minska beroendet av ”svarta lådor” ska inte ignoreras. Vi behöver definiera vem som är ansvarig för att granska kod, vem som är ansvarig för att signera att den uppfyller såväl behov som de krav som ställs på mjukvaran och vem som har mandatet att ställa krav. Ska det vara en modell som liknar den ryska där man försöker centralisera så mycket som möjligt till en specifik organisationsenhet?[1] Ska det vara likt den ukrainska modellen, decentraliserad, där brigaderna och bataljonerna har egna verkstäder med personal som jobbar enbart utifrån lokala förutsättningar? Eller ska det vara en mittenväg i uppdragstaktisk anda där högre chef definierar vilka modifikationer som är acceptabla? Exempelvis för att upprätthålla cybersäkerhet och flygsäkerhet.[2] Det kan bli svåra gränsdragningar för en chef att göra och möjligen en utopi sett till hur mycket data som chefen måste ta ställning till.
Oaktat val av riktning är kompetens nyckeln för att genomförandet överhuvudtaget ska ha chans att lyckas. Dagens befälskår behöver ha en teknisk förståelse för att kunna fatta välavvägda beslut. Samtidigt är det orimligt att kräva att en chef eller enskild stabsmedlem ska ha kunskap om hur firmware modifieras, hur man skriver kod för autonoma sensorer eller förstå fullt ut hur informationsnätverk byggs. Här kommer Försvarsmakten vara beroende av att det långt ner i organisationen finns personal med kompetens inom datavetenskap. De ukrainska framgångarna med olika former av ledningsstödsystem, en integrerad verkanskedja och en databas som kan användas för att träna AI-modeller bygger i stort på att man kompetensinventerat och placerat individer med civil kompetens inom mjukvaruutveckling med att göra samma sak i kriget som de gjorde i fred. Arketypen om krigarpoeten[3] passar in i sammanhanget så till vida att vi behöver soldater som också har en hög teknisk förmåga som sträcker sig bortom att enbart vara en operatör av system. Individen behöver i högre utsträckning förstå systemets bakomliggande arkitektur, dess sårbarheter och styrkor, och hur man går till väga för att modifiera.
Avslutningsvis
Den som uppdaterar snabbast, inte producerar mest, sätter tempot. Ammunition avgör vilken verkan ett vapensystem kan uppnå; på samma sätt avgör mjukvaran vilken effekt ett tekniskt system uppnår i strid. Skillnaden är att mjukvaran kan bytas över en natt. Det är kärnan i mjukvarudefinierad krigföring och det ställer försvarsmakter inför ett val: att fortsätta köpa ”svarta lådor” med långa ledtider från tillverkaren, eller att bygga en organisation där även mjukvara följs upp likt ammunition, utvecklas nära operatören och vilar på en öppen arkitektur som inte binder oss till en leverantör. Ukraina har visat att det senare är möjligt, men att det i sin tur kräver kompetens långt ner och långt ut i organisationen, samt att det finns behov av vissa gränsdragningar för att inte skapa taktiska sårbarheter. Den som i kriget behärskar den här förmågan kan hålla sina system relevanta i takt med att läget och hotet förändras. Den som inte gör det riskerar i stället att stå med tekniskt dugliga plattformar som är taktiskt obsoleta, inte för att hårdvaran är utdaterad utan för att koden är det.