Et militært IT-system er ikke bare et IT-system. Men det er heller ikke nødvendigvis så eksotisk, som vi nogle gange gør det til.
Meget af teknologien vil være fuldstændig genkendelig for enhver, der arbejder med enterprise IT: servere, netværk, compute, storage, identiteter, applikationer og kommunikation. På andre områder minder militær IT måske mere om operationel teknologi (OT), som især er kendt fra energibranchen, kritisk infrastruktur og produktionsvirksomheder.
Militær teknologi skal nemlig understøtte en fysisk og operativ kapacitet, som kan have en levetid på årtier. Den skal ikke bare fungere i et datacenter. Den skal fungere som en del af en kampvogn, et fly, et hovedkvarter eller en deployeret enhed. Og det ændrer nogle af præmisserne, også i forhold til klassisk IT/OT-forståelse.
Det skal kunne virke, selv når dele af det ikke virker
Et system kan eksempelvis skulle fungere et sted, hvor der ikke var nogen infrastruktur en halv time tidligere. Det kan skulle levere en brugbar kernefunktion, selvom forbindelsen tilbage til resten af organisationen er væk. Det kan skulle tåle, at dele af systemet fejler.
Og i modsætning til de fleste almindelige enterprise-miljøer skal man samtidig forholde sig til, at der kan stå en intelligent modstander på den anden side, som aktivt forsøger at opdage, forstyrre eller ødelægge ens evne til at kommunikere og arbejde.
Med andre ord skal det kunne virke, selv når dele af det ikke virker. Det har konsekvenser for arkitekturen.
For mig starter det altid med operationen
Hvad er det egentlig, vi forsøger at opnå?
Det lyder banalt. Det burde også være udgangspunktet for enhver god enterprise-arkitektur. Men i forsvarsprojekter bliver det særligt vigtigt, fordi konsekvensen af at optimere efter det forkerte kan være stor.
Brugeren kan komme til at beskrive den løsning, de allerede kender, i stedet for den effekt, man har behov for. Teknikeren kan omvendt bygge en teknisk fremragende løsning uden helt at forstå den operative virkelighed, den skal fungere i, eller bindingerne til andre legacy-løsninger, som den skal integreres med.
Begge dele kan føre til en arkitektur, der løser det forkerte problem eller slet ikke skaber den effekt, der var ønsket.
Derfor interesserer jeg mig langt mere for effekt end for features. Hvad skal soldaten, staben eller enheden kunne gøre? Under hvilke forhold? Hvor hurtigt? Og hvad skal stadig fungere, når noget andet ikke gør?
Først derefter bør vi diskutere teknologien.
Mere er ikke nødvendigvis bedre
Hver ekstra funktion og hver ekstra teknisk afhængighed kan have en pris i form af uddannelse, reservedele, fejlsøgning, logistik, specialister eller behov for ekstern support.
Kompleksitet kan sagtens være nødvendig. Men den bør kunne retfærdiggøres af den operative effekt, den skaber.
Sikkerhed skal være en del af den samlede kapacitet
Det samme gælder sikkerhed. Det sikreste system på papiret er ikke nødvendigvis det bedste militære system.
Hvis sikkerhedskontroller gør løsningen så vanskelig at anvende eller så afhængig af andre systemer, at brugeren ikke kan løse sin opgave, har vi ikke nødvendigvis skabt en bedre kapacitet.
Det betyder naturligvis ikke, at sikkerhed er sekundært. Tværtimod. Det betyder, at sikkerhed, akkreditering, interoperabilitet, logistik, robusthed og operativ anvendelighed skal designes som dele af den samme kapacitet. Ikke som separate problemer, der løses bagefter.
Det er måske ikke så fremmed en tanke, særligt ikke for sikkerhedsfolk. Men logistik, forsyning og mobilitet er nok i færre tilfælde en del af billedet. Og måske er det netop dér, forskellen ligger.
Militær IT handler ikke kun om at bygge et godt IT-system. Det handler om at bygge en militær kapacitet, hvor IT er en integreret del af løsningen.