Vanhat C2-järjestelmät eivät kaadu dramaattisesti. Ne rapautuvat hitaasti, reunoilla: datasyöte, joka ei enää saavu odotetussa formaatissa, ohjelmistoversio, joka on jumissa, koska toimittaja lopetti tuen, integraatio uuden liittoutuneen järjestelmän kanssa, johon alusta ei koskaan ole suunniteltu sopimaan. Siihen mennessä, kun operatiivinen vaikutus on kiistaton, ylläpitotaakasta on tullut merkittävä osa IT-budjettia ja järjestelmään on kertynyt vuosien kiertotavat, joita kukaan ei täysin ymmärrä. Organisaatio tietää, että jotain on muututtava; se ei tiedä, pitäisikö korvata, laajentaa vai rakentaa olemassa olevan alustan ympärille.
Tämä opas käsittelee kyseistä kysymystä suoraan. Se kattaa kolme keskeistä modernisointilähestymistapaa — täydellinen korvaaminen, inkrementaalinen päällekkäisyys ja tietokerroksen abstraktio — sekä käytännölliset kriteerit niiden välillä valitsemiseen, yleiset vikamoodit, jotka tuhoavat C2-modernisointiohjelmat, ja miten ylläpidetään operatiivinen jatkuvuus siirron aikana, joka voi kestää vuosia. Lisäksi se määrittelee, miltä moderni C2-perustaso todella näyttää, jotta hankinta- ja IT-johtajat voivat arvioida ehdotuksia konkreettisten teknisten kriteerien perusteella eikä markkinointikielen perusteella.
Miksi vanhoista C2-järjestelmistä tulee vastuita
C2-järjestelmä, joka oli hankintahetkellä tarkoituksenmukainen, ei automaattisesti pysy tarkoituksenmukaisena. Kolme mekanismia muuttaa operatiiviset voimavarat operatiivisiksi vastuiksi, ja ne kertautuvat toistensa kanssa ajan mittaan.
Ylläpitokustannusten kasvu. Kun alusta vanhenee alkuperäisen tukielinkaarensa yli, sen käynnissä pitämisen kustannukset kasvavat epälineaarisesti. Laitteistokomponentit käyvät niukoiksi ja kalliiksi korvata. Ohjelmistoriippuvuudet — käyttöjärjestelmät, ajoympäristöt, kolmannen osapuolen kirjastot — saavuttavat elinkaarensa loppupäänsa eivätkä enää saa tietoturvapäivityksiä, mikä luo tietoturvariskin, johon luokiteltujen verkkojen ylläpitäjät vastaavat yhä rajoittavammilla toimenpiteillä. Pieni joukko insinöörejä, joilla on alustan institutionaalinen tuntemus, eläköityy tai siirtyy muualle, ja heidän seuraajilleen on maksettava preemiota yhä harvinaisemmasta asiantuntemuksesta. Ohjelmat, jotka vaativat aiemmin kolmihenkisen ylläpitotiimin, vaativat nyt kuusi henkilöä tekemään vähemmän.
Integraatiopuutteet. Operatiivinen ympäristö ei seiso paikallaan, kun C2-alusta vanhenee. Uusia anturijärjestelmiä otetaan käyttöön, jotka tuottavat dataa formaateissa, joita vanha alusta ei koskaan ole suunniteltu käyttämään. Koalition kumppanit omaksuvat uusia yhteentoimivuusstandardeja — MIP4:n, päivitetyt CoT-skeemoja, tarkistetut STANAG-määritykset — joita vanha järjestelmä ei pysty puhumaan ilman ulkoista käännöskerrosta, joka on kiinnitetty sen reunalle. Jokainen uusi integrointivaatimus, johon ei voida vastata natiivisti, muuttuu joko puutteeksi yhteisessä operatiivisessa kuvassa tai erikoistuneeksi sovittimeksi, joka lisää monimutkaisuutta ja haurautta jo muutenkin hauraaseen arkkitehtuuriin.
Ei API-pääsyä. Monet vanhat C2-alustat on suunniteltu aikakaudella, jolloin API-ensin-arkkitehtuuri ei ollut vakiintunut käytäntö. Tieto elää alustan omassa tietokannassa ja on saatavissa vain alustan oman käyttöliittymän kautta tai, parhaimmillaan, rajoitetun erä-vientimekanismien sarjan kautta. Tämä suunnittelu tekee mahdottomaksi rakentaa moderneja analyyttisiä päällyskerroksia, tekoälypohjaisia päätöksentukikerroksia tai automatisoituja raportointiputkia järjestelmän päälle ilman sen sisäisten datarakenteiden käänteismuokkausta — riskialtis, kallis ja jatkuva ylläpitotaakka aina kun alusta päivitetään.
Keskeinen oivallus: Ylläpitokustannusten, integraatiopuutteiden ja suljetun tietopääsyn kertyminen ei vain tee vanhasta järjestelmästä kallista — se tekee siitä strategisen riskin. Organisaatiot, joilla on C2-alustoja, joita ne eivät voi laajentaa, eivät pysty omaksumaan uusia kykyjä, kun operatiiviset vaatimukset kehittyvät.
Kolme modernisointilähestymistapaa
C2-modernisointiin ei ole olemassa yhtä universaalia oikeaa lähestymistapaa. Oikea valinta riippuu ohjelmaa ohjaavasta tietystä vikamoodista, operatiivisesta riskinsietokyvystä, budjettikehyksestä ja siitä, kuinka paljon vanhan järjestelmän ydintoiminnosta on syytä säilyttää.
Lähestymistapa 1: Täydellinen korvaaminen
Täydellinen korvaaminen hankkii uuden C2-alustan ja siirtää tiedot, työnkulut ja integraatiot vanhasta järjestelmästä uuteen määriteltynä siirtymispäivänä. Se on riskialttein lähestymistapa ja kallein etukäteen. Se on myös ainoa toimiva lähestymistapa, kun vanhan alustan ydinarkitehtuuri on niin perustavanlaatuisesti ristiriidassa nykyisten vaatimusten kanssa, että mikään määrä päällekkäisyystyötä ei voi kuroa umpeen eroa — esimerkiksi kun alusta toimii lakkautetulla käyttöjärjestelmällä ilman päivityspolkua tai kun sen datamalli on niin rakenteellisesti yhteensopimaton modernien yhteentoimivuusstandardien kanssa, että reaaliaikainen käännöskerros aiheuttaisi sietämätöntä viivettä.
Edut: Puhdas irtautuminen vanhan järjestelmän teknisestä velasta. Uusi järjestelmä voidaan suunnitella API-ensin alusta alkaen. Ei jatkuvaa kahden rinnakkaisen järjestelmän ylläpitoa pitkän siirtymäkauden aikana. Modernin arkkitehtuurin täysimääräinen hyöty realisoituu välittömästi siirtymisen jälkeen.
Haitat: Korkea aikataulu- ja kustannusriski. Yhden kerran siirrot kestävät johdonmukaisesti kauemmin ja maksavat enemmän kuin suunniteltu. Operaattorien uudelleenkoulutus on merkittävä operatiivinen häiriö. Vanhaan järjestelmään sulautunut institutionaalinen tieto — dokumentoimattomat menettelyt, kalibroinnit, mukautetut raportit — on tunnistettava ja luotava uudelleen uuteen järjestelmään ennen siirtymistä, tai se menetetään.
Lähestymistapa 2: Inkrementaalinen päällekkäisyys
Inkrementaalinen päällekkäisyys rakentaa uuden käyttäjille näkyvän kerroksen olemassa olevan C2-alustan päälle, yhdistäen siihen vanhan järjestelmän tarjoamilla tietopääsymekanismeilla — tiedostovienneillä, tietokantakyselyillä, tarvittaessa näyttökaappauksilla — samalla kun vanha järjestelmä jatkaa toimintaansa auktoritatiivisena kirjauslähdettä. Ajan myötä yksittäiset toiminnalliset komponentit korvataan pala palalta, kunnes vanha alusta voidaan poistaa käytöstä. Uudesta päällekkäisyyskerroksesta tulee lopulta ensisijainen järjestelmä ilman yhtä korkeata riskiä sisältävää siirtymistä.
Edut: Alhaisempi operatiivinen riski kuin täydellinen korvaaminen. Aikaiset inkrementit tuottavat nopeasti näkyvää kyvykkyysparannuksia. Operaattorit käyttävät uutta käyttöliittymää samalla kun tuttu vanha järjestelmä pysyy taustalla, mikä vähentää uudelleenkoulutusjärkytyä. Ohjelma voi keskeyttää tai muuttaa laajuutta inkrementtien välillä, jos prioriteetit muuttuvat.
Haitat: Pidempi kokonaisaikataulu. Siirtymäkaudella kahta järjestelmää on ylläpidettävä samanaikaisesti. Päällekkäisyyskerroksen laatu on rajoitettu vanhan järjestelmän tarjoamien tietopääsymekanismien laadulla — alusta, joka tarjoaa vain yölliset erä-viennit, ei voi tukea reaaliaikaista päällekkäisyyskerrosta. On olemassa riski, että "väliaikainen" päällekkäisyys muuttuu pysyväksi ja vanhan järjestelmän käytöstäpoistovaihetta lykätään loputtomiin.
Lähestymistapa 3: Tietokerroksen abstraktio
Tietokerroksen abstraktio lisää normalisointi- ja käännöskerroksen vanhan C2-alustan ja järjestelmien välille, jotka tarvitsevat sen dataa — anturisyötteet, raportointityökalut, analyyttiset päällekkäisyyskerrokset, koalition kumppanijärjestelmät. Abstraktiokerros kääntää vanhan alustan omistusoikeudellisen dataformaatin moderneiksi standardeiksi (CoT, REST JSON, MIP4) reaaliajassa, tarjoten puhtaan API:n, johon alaspäin olevat järjestelmät voivat integroitua tietämättä tai välittämättä siitä, miltä taustalla oleva alusta näyttää.
Tämä lähestymistapa ei korvaa vanhaa alustaa. Se poistaa integraatiopuutteen ongelman tekemällä vanhan alustan näyttämään modernilta ulkomaailmalle, ostaa aikaa perusteellisemmalle korvaukselle samalla kun se välittömästi mahdollistaa uudet kyvykkyydet (tekoälypäällekkäisyydet, automatisoitu raportointi, koalition yhteentoimivuus), jotka olivat estyneet API-pääsyn puutteen vuoksi.
Edut: Nopein aika alkuperäiseen suorituskykyyn. Alhaisin operatiivinen riski. Ei vaadi operaattorien uudelleenkoulutusta. Mahdollistaa modernit analyyttiset työkalut — mukaan lukien kojelaudat kuten Corvus.Head — vanhojen datasäilöjen päällekkäisyyteen ilman alustan korvaamista. Voidaan ottaa käyttöön viikoissa eikä kuukausissa.
Haitat: Ei ratkaise taustalla olevan alustan ylläpitokustannusten kasvua. Vanha järjestelmä jää paikalleen kaikkine tukielinkaarirajoituksineen. Käännöskerroksen monimutkaisuus kasvaa jokaisen uuden integrointivaatimuksen myötä. Reaaliaikaisen käännöksen suorituskykyrasitus on vahvistettava latenssivaatimusten suhteen aikakriittisille datasyötteille.
Keskeinen oivallus: Tietokerroksen abstraktiolähestymistapa on erityisen tehokas siltalähestymistapana — se tuottaa välittömiä yhteentoimivuusetuja samalla kun organisaatio suunnittelee ja rahoittaa perusteellisempaa korvaamisohjelmaa. Organisaatiot, jotka hyppäävät suoraan täydelliseen korvaamiseen ilman siltalähestymistapaa, viettävät usein vuosia ilman kyvykkyysparannuksia, kun korvaamisohjelmaa kehitetään.
Miten arvioidaan C2-järjestelmän modernisointivalmius
Ennen siirtymisstrategian valitsemista organisaation on ymmärrettävä, mitä sillä todella on. Seuraavat vaiheet tarjoavat jäsennellyn arviointikehyksen, joka soveltuu mihin tahansa vanhaan C2-alustaan.
Vaihe 1: Luettele kaikki komponentit ja integraatiot. Laadi täydellinen kartta jokaisesta ohjelmistokomponentista, laitteistoriippuvuudesta ja integrointipisteestä — mukaan lukien dokumentoimattomat integraatiot, jotka löytyvät haastattelemalla operaattoreita ja tarkastelemalla verkkoliikennettä. Vanhoilla järjestelmillä on tyypillisesti kaksi tai kolme kertaa enemmän integraatioita kuin virallinen dokumentaatio kuvaa, koska operaattorit ovat rakentaneet pisteestä pisteeseen -yhteyksiä vuosien varrella ilman muodollista muutoksenhallintaa.
Vaihe 2: Kvantifioi ylläpitokustannusten perustaso. Selvitä järjestelmän käynnissä pitämisen nykyinen vuosikustannus: lisenssimaksut, laitteistotuki, asiantuntijatoimittajien tunnit ja IT-henkilöstöajan vanhan ylläpidon kulutus. Tämä perustaso on vertailupiste, jota vasten modernisointisijoitusta perustellaan. Ohjelmat, jotka ohittavat tämän vaiheen, eivät pysty osoittamaan sijoitetun pääoman tuottoa.
Vaihe 3: Tunnista operatiivisia vaatimuksia estävät integraatiopuutteet. Kartoita jokainen täyttämätön operatiivinen vaatimus tiettyyn tekniseen rajoitukseen. Tämä erottaa ongelmat, jotka vaativat alustan korvaamista, ongelmista, jotka voidaan ratkaista sovittimella tai päällekkäisyyskerroksella — erottelu, joka määrittää, mikä siirtymisstrategia on asianmukainen.
Vaihe 4: Arvioi tietojen siirron monimutkaisuus. Ota näytteitä vanhasta tietokannasta ja arvioi tietojen laatu, skeeman dokumentaation kattavuus ja siirron määrä. Tunnista vapaamuotoiset tekstikentät, jotka sisältävät jäsenneltyä dataa, ja viite-eheysrikkomukset. Tämä arviointi ohjaa tietojen siirtotyön arviointia — johdonmukaisesti aliarvioiduin komponentti C2-modernisointiohjelmissa.
Vaihe 5: Tallenna operaattorin institutionaalinen tieto. Haastattele operaattoreita ja järjestelmänvalvojia, jotka käyttävät järjestelmää päivittäin. Dokumentoi dokumentoimattomat menettelyt, kiertotavat ja kalibrointitiedot, jotka ovat olemassa vain ihmisten päissä. Tämä tieto on tärkein lähde korvaavan järjestelmän operatiivisille vaatimuksille ja tärkein siirtymisen jälkeisten epäonnistumisten lähde, kun sitä ei tallenneta ennen siirtymistä.
Vaihe 6: Valitse siirtymisstrategia. Kun inventaario, kustannusperustaso, puuteanalyysi, tietoarviointi ja tiedon tallennus ovat käsillä, valitse lähestymistapa, joka sopii tiettyyn vikamoodiin ja organisaation riskinsietokykyyn. Dokumentoi valinnan perusteet selkeästi.
Vaihe 7: Määrittele operatiivinen jatkuvuus ja palautuskriteerit. Ennen siirtymistyön aloittamista määrittele rinnakkaiskäyttöjakso, hyväksymiskriteerit siirtymiselle ja palautusmenettely, joka palauttaa vanhan järjestelmän täyden toiminnan määritellyn aikaikkunan sisällä, jos kriittisiä ongelmia ilmenee siirtymisen jälkeen. Siirtymisohjelma ilman testattua palautusmenettelyä on täysin sopimaton operatiivinen riski missiokriittisille järjestelmille.
Yleiset vikamoodit, jotka tuhoavat C2-modernisointiohjelmat
C2-modernisointiohjelmat epäonnistuvat ennustettavissa tavoissa. Näiden vikamoodien ymmärtäminen ennen ohjelman alkua on huomattavasti tehokkaampaa kuin niiden diagnosointi sen jälkeen, kun ohjelma on mennyt pieleen.
Yhden kerran siirtymisen laajuus. Yleisin ohjelman epäonnistumisen syy on kaiken korvaaminen samanaikaisesti. Yhden kerran siirtymät vaativat, että jokainen uuden järjestelmän komponentti on valmis ja integroitu ennen kuin mitään operatiivista hyötyä saadaan. Kun vaatimukset muuttuvat kesken ohjelman — ja ne aina muuttuvat — koko laajuus on suunniteltava uudelleen eikä vain yksittäisiä inkrementtejä voida mukauttaa. Ohjelmat, jotka yrittävät korvata 15 vuotta vanhan C2-alustan yhdellä toimitussyklillä, ylittävät johdonmukaisesti budjettinsa 40–80 % ja aikataulunsa 50–100 %.
Toimittajariippuvuuden toistaminen. Organisaatiot, jotka pakenevat yhden toimittajan omistusoikeudellisesta alustasta, hyväksyvät usein vastaavan omistusoikeudellisen riippuvuuden korvaajassa. Modernisointiohjelma, joka tuottaa uuden järjestelmän suljetulla tietokannalla, ilman julkaistua API:a ja yhden lähteen tukisopimuksella, ei ole vähentänyt organisaation strategista riskiä — se on nollannut kellon samalle ongelmalle. Avointen API-rajapintojen, dokumentoitujen dataformaattien ja ohjelmiston sulkutilisopimusten vaatiminen hankintamäärittelyssä on ainoa luotettava suoja.
Institutionaalisen tiedon menetys. Kun ihmiset, jotka ymmärtävät, miksi vanha järjestelmä on konfiguroitu niin kuin se on, poistuvat ohjelmasta ennen kuin heidän tietonsa on dokumentoitu, korvaava järjestelmä rakennetaan vaatimuskokonaisuuteen, joka ei heijasta todellisia operatiivisia tarpeita. Tämä ilmenee tyypillisesti kuudesta kahteentoista kuukautta siirtymisen jälkeen, kun operaattorit huomaavat, että uudesta järjestelmästä puuttuu kyky, johon he luottivat päivittäin mutta jota he eivät koskaan virallisesti dokumentoineet vaatimuksena, koska se tuntui itsestään selvältä. Lievennys on muodollinen tiedon tallennusharjoitus, joka tehdään nykyisten operaattorien kanssa ennen kuin vanhaa järjestelmää koskettaan.
Tietojen siirron aliarvioiminen. Ohjelmat, jotka käsittelevät tietojen siirtoa myöhäisvaiheen teknisenä tehtävänä, löytävät johdonmukaisesti kyseisessä myöhäisvaiheessa, että lähdedata on huomattavasti monimutkaisempaa kuin ennakoitu. Kolmen miljoonan tietueen siirto hyvin dokumentoidulla skeemalla on suoraviivainen ETL-projekti. Kolmen miljoonan tietueen siirto, jossa 40 % merkityksellisestä datasta on vapaamuotoisissa muistiinpanoissa, skeemalla, jota on muutettu 23 kertaa 15 vuoden aikana ja jonka kehitystä ei ole koskaan virallisesti dokumentoitu, on usean kuukauden insinöörityöponnistus, jota mikään aikataulupaine ei nopeuta.
Keskeinen oivallus: Tehokkain riskienhallinta C2-modernisointiohjelmassa on toimitusmalli, joka tuottaa operatiivista kyvykkyyttä kolmen kuuden kuukauden inkrementeissä. Inkrementti, joka tuottaa mitattavaa kyvykkyyttä, osoittaa ohjelman terveyden, rakentaa organisatorista luottamusta ja tarjoaa varhaisen signaalin, jos lähestymistapaa on tarpeen mukauttaa — ennen kuin ohjelma on kuluttanut koko budjettinsa.
Operatiivisen jatkuvuuden ylläpitäminen siirron aikana
C2-järjestelmä, jota siirretään, on samanaikaisesti reaaliaikainen operatiivinen järjestelmä, jonka on jatkettava toimintaansa. Nämä vaatimukset ovat jännitteessä keskenään, ja kyseisen jännitteen hallinta vaatii harkittua arkkitehtuuria eikä vain toivomusta, ettei siirto ja operatiiviset tarpeet osu yhteen.
Luotettavin malli jatkuvuuden ylläpitämiseksi on rinnakkaiskäyttöjakso: sekä vanha järjestelmä että uusi järjestelmä toimivat samanaikaisesti, operaattorit käyttävät molempia ja vertaavat tuotoksia, ennen kuin vanha järjestelmä nimetään varajärjestelmäksi ja lopulta poistetaan käytöstä. Rinnakkaiskäyttöjaksot ovat kalliita — ne vaativat kahden integrointijoukon, kahden operaattoritaitojen joukon ja kahden tukijärjestelyn ylläpitoa — mutta ne ovat huomattavasti halvempia kuin hätäpalautus epäonnistuneesta siirtymisestä operatiivisessa ympäristössä.
Inkrementaalisen päällekkäisyys-lähestymistavan osalta jatkuvuus on sisäänrakennettu arkkitehtuuriin: vanha järjestelmä ei koskaan mene offline-tilaan, ja jokainen päällekkäisyyskerroksen tuottama uusi kyky on lisäävä eikä korvaa toimintoa, johon operaattorit tällä hetkellä luottavat. Häiriöriski on keskittynyt vanhan alustan lopulliseen käytöstäpoistoon, jolloin päällekkäisyyskerros on jo ollut operatiivisessa käytössä riittävän kauan luottamuksen rakentamiseksi.
Täydellisen korvaamisen ohjelmien osalta siirtymiskriteerit on määriteltävä ja sovittava ennen ohjelman alkua. Tyypilliset kriteerit sisältävät: tietojen yhteismitallisuuden vahvistamisen (uuden järjestelmän yhteinen operatiivinen kuva vastaa vanhan järjestelmän yhteistä operatiivista kuvaa määriteltyjen toleranssien sisällä määritellyllä havaintojaksolla), operaattorin osaamisen kynnysarvot (kaikki operaattorit ovat suorittaneet koulutuksen ja saavuttaneet validoidun osaamisen ydintehtävissä), integraatiosertifioinnin (kaikki ulkoiset integraatiot on testattu alusta loppuun reaaliaikaisella datalla) ja testatun palautusmenettelyn sitoutuneella palautusaikatarveobjektiivilla. Ohjelma, joka saavuttaa siirtymisen ilman vahvistettua palautusta, lyöttää operatiivisen jatkuvuuden ensimmäisen yrityksen onnistumisen varaan — veto, josta laajamittaisten IT-siirtojen historia osoittaa olevan epätodennäköistä.
Miltä moderni C2-perustaso näyttää
Hankinta- ja IT-johtajat, jotka arvioivat modernisointiehdotuksia, tarvitsevat konkreettisia kriteerejä, eivät toiveikasta kieltä. Järjestelmä, jota toimittajamateriaaleissa kuvataan "modernina" tai "seuraavan sukupolven", voi täyttää tai olla täyttämättä teknisen perustason, joka tekee siitä laajennettavan, yhteentoimivan ja ylläpidettävän yli vuosikymmenen operatiivisella elinkaarella. Seuraavat ominaisuudet määrittelevät aidon modernin C2-perustason.
API-ensin-suunnittelu. Jokainen järjestelmän suorittama toiminto on saatavissa dokumentoidun, versioitetun API:n kautta — REST, gRPC tai molemmat. Seurantatiedot, hälytystapahtumat, tehtäväsuunnitelmat, käyttäjäkonfiguraatiot ja raportointituotokset ovat kaikki ohjelmallisesti saatavissa. Järjestelmä, jolla on monipuolinen käyttöliittymä mutta ei ohjelmallista API:a, on modernin näköinen vanha järjestelmä, ei moderni järjestelmä.
Standardeihin perustuva yhteentoimivuus. Järjestelmä vaihtaa dataa ulkoisten järjestelmien kanssa julkaistuilla, laajasti omaksutuilla standardeilla: Cursor-on-Target reaaliaikaiselle seuraus- ja tapahtumadatalle, MIP4 koalition C2-vaihdolle, STANAG 4559 anturin tehtävänannolle ja kuvantamiselle, Link 16 J-sarjan viestit yhteiselle datalinkkiintegraatiolle. Omistusoikeudellinen dataformaatti integrointirajapinnoissa on varoitusmerkki riippumatta siitä, miten se on kuvattu ehdotuksessa. Työkalut kuten Corvus.Head on suunniteltu näiden standardien ympärille — kuluttaen vanhojen datasyötteiden normalisoitujen abstraktiokerrosten kautta samalla kun se esittää operaattoreille modernin tiedustelukojelaudan.
Pilvi-valinnainen käyttöönotto. Arkkitehtuuri toimii paikallisesti taktisella reunapalvelimella, suvereenissa luokitellussa pilvessä tai hybridikonfiguraatiossa ilman koodimuutoksia ympäristöjen välillä. Ympäristökohtainen konfiguraatio — verkkopäätepisteet, tallennuspolut, todennustoimittajat — on ulkoistettu käyttöönottomerkintöihin, ei kiinteästi koodattu sovelluskoodiin. Tämä ominaisuus määrittää, voiko järjestelmä sopeutua tuleviin infrastruktuuripäätöksiin ilman uudelleenkehittämisohjelmaa.
Roolipohjainen pääsynhallinta ja auditointiloki. Pääsy jokaiseen dataluokkaan ja järjestelmän toimintoon on hallittu roolilla, joka voidaan myöntää ja peruuttaa ilman koodimuutoksia. Jokainen käyttäjätoiminto — kysely, muokkaus, vienti, kuittaus — kirjataan käyttäjätunnuksella, aikaleimalla ja toimintayksityiskohdalla muuttumattomassa auditointilokissa. Tämä on luokiteltujen järjestelmien tietoturva- ja vaatimustenmukaisuusvaatimus, mutta se on myös operatiivisesti tärkeä: C2-järjestelmä, joka ei pysty kertomaan, kuka muutti seurannan luokituksen kello 02:30, on järjestelmä, jonka auditointiloki ei voi tukea toiminnan jälkianalyysiä tai tapauksen tutkintaa.
Nämä neljä kriteeriä täyttävä järjestelmä voidaan integroida koalition kumppaneiden kanssa, laajentaa tekoälyn analyyttisillä päällekkäisyyksillä, yhdistää uusiin anturijärjestelmiin niiden käyttöönottamisen yhteydessä ja siirtää uuteen infrastruktuuriin, kun operatiiviset vaatimukset kehittyvät — ilman täydellistä hankintakierrosta joka kerta. Vanhat järjestelmät, jotka eivät täytä mitään näistä kriteereistä, vaativat uuden hankintakierroksen jokaista merkittävää kyvykkyysmuutosta varten. Siinä on perimmäinen ero strategisen voimavaran ja strategisen vastuun välillä.