Puolustuslogistiikkaorganisaatiot toimivat kahdella hyvin erilaisella aikataululla. Strategisella ja operatiivisella tasolla kansalliset toiminnanohjausjärjestelmät (ERP) hallitsevat tarvikkeiden, kaluston ja henkilöstön kokonaissovirtausta koko joukon läpi — seuraten varastoa varastoissa, luoden hankintapyyntöjä ja raportoimassa varastotasoja komentajille ja suunnittelijoille. Taktisella tasolla kenttäsovellukset seuraavat, mitä yksittäisillä yksiköillä todella on, mitä ne ovat kuluttaneet, mitä ne tarvitsevat ja milloin täydennys on pyydetty. Näiden kahden kerroksen välinen kuilu on pysyvä operatiivinen ongelma: kansalliset järjestelmät sisältävät dataa, jota kenttäkomentajat tarvitsevat, ja kenttäsovellukset tuottavat dataa, jota kansalliset järjestelmät tarvitsevat, mutta nämä kaksi eivät usein vaihda tietoja oikea-aikaisesti tai luotettavasti.

Kenttälogistiikkasovellusten integrointi kansallisiin puolustuksen ERP-järjestelmiin on teknisesti ja byrokraattisesti monimutkainen tehtävä. Järjestelmät on rakennettu eri organisaatioissa, eri aikoina, käyttäen erilaisia tietomalleja ja rajapintaprotokollia. Jotkut käyttävät moderneja REST-rajapintoja; toiset käyttävät sanomajononoja 2000-luvun alun legacy XML-skeemoilla; muutamat tukeutuvat edelleen erätiedostosiirtoihin. Integraatiohaaste ei ole pelkästään tekninen — se sisältää tietoturvaluokittelujen navigoimisen, organisatoristen omistajuuskysymysten ja hyväksymisprosessien läpikäymisen, jotka voivat kestää kuukausia.

Puolustuksen ERP-ympäristö

GCSS-Army (Global Combat Support System – Army). GCSS-Army on Yhdysvaltain armeijan yritysten logistiikka- ja taloushallintajärjestelmä, rakennettu SAP:lle ja otettu käyttöön vaiheistettuna 2010-luvun alusta alkaen. Se hallitsee omaisuusvastuu-, kalustohuollon seuranta-, tarvikehankinta- ja taloustransaktioita maailmanlaajuisille armeijan yksiköille. GCSS-Army korvasi useita vanhoja järjestelmiä (ULLS-G, SAMS-E, LIW) ja pitää nyt auktoritatiivista tietuetta armeijan kaluston omaisuuskirjoista ja tarvikehankintapyynnöistä. Kenttäsovellusten, jotka tarvitsevat yksikön kalustoauktorisaatioita tai omaisuustietoja tai jotka haluavat lähettää hankintapyyntöjä armeijan toimitusketjuun, on liityttävä GCSS-Army:hin.

LOGFAS (Logistics Functional Area Services). LOGFAS on ensisijainen logistiikan suunnittelu- ja operatiivinen tukijärjestelmä, jota käytetään monissa Euroopan asevoimissa ja monikansallisten operaatioiden koordinoinnissa. Se tarjoaa toimintoja liikkeiden ja kuljetusten suunnitteluun, toimitusketjun hallintaan ja lääkintälogistiikkaan. Toisin kuin GCSS-Army, LOGFAS ei ole yksittäinen järjestelmä vaan yhteenliitettyjen sovellusten kokoelma, joka jakaa yhteisen tietomallin.

ЛОГІС (Ukraina). Ukrainan asevoimien logistiikan tietojärjestelmä, ЛОГІС, kehitettiin ja otettiin käyttöön vaiheistettuna vuodesta 2022 alkaen sodan aikaisissa olosuhteissa. Se hallitsee tarvikepyyntöjä, omaisuusvastuuta ja logistiikan suunnittelua ukrainalaisissa yksiköissä. Järjestelmä on käynyt läpi nopeita kehityskierroksia sodan aikaisten vaatimusten käsittelemiseksi, ja sen integraatiorajapinnat heijastavat tätä kehitystä — sekoitus REST-rajapintoja uudemmille moduuleille ja tiedostovientejä vanhemmille komponenteille.

Integraatiohaasteet: API:t, perintöprotokollat ja luokitellut päätepisteet

Jokainen näistä järjestelmistä asettaa erillisiä integraatiohaasteita, joita yhdistettävän kenttäsovelluksen on käsiteltävä.

GCSS-Army:n SAP-pohjainen arkkitehtuuri tarkoittaa, että integraatiorajapinta on määritelty SAP:n verkkopalvelu- ja RFC-käytäntöjen mukaan, ei modernien API-suunnitteluperiaatteiden mukaan. Tietomalli heijastaa SAP:n yleiskäyttöistä ERP-rakennetta, joka on mukautettu armeijan käyttöön — omaisuuskirjan rivinimiket, hankintaobjektit ja huoltomääräykset on esitetty SAP-terminologialla ja -rakenteilla, jotka eivät kuvaudu suoraan kenttäsovelluksen tietomalliin.

Turvallisuusluokittelu lisää toisen monimutkaisuusulottuvuuden. GCSS-Army toimii useilla luokittelutasoilla, ja osat, joihin kenttäsovellusten on päästävä käsiksi — yksikön omaisuuskirjat, hankintapyynnöt, huoltostatus — voivat kantaa luokittelumerkintöjä, jotka rajoittavat datan tallennusta, käsittelyä ja siirtoa. Integraatiokeskikerroksen on oltava akkreditoitu käsittelemään asianomaiset luokittelutasot.

LOGFAS asettaa erilaisen haasteen: järjestelmää käyttävät useita kansakuntia, joilla on erilaiset datastandardit ja organisatoriset käytännöt samoille logistiikkakonsepteille. Yhdessä kansakunnassa LOGFAS:n "hankintapyyntö" voi vaatia eri pakolliset kentät ja erilaiset koodausjärjestelmät kuin toisessa.

Keskeinen oppi kenttäkäyttöönotoista: Yleisin integraation vikamuoto ei ole alkuyhteys — se on datan laadun hajoaminen ajan myötä. Kenttäsovellus, joka päivittää tietomallins (lisäämällä uusia omaisuusluokkia, muuttamalla statuskoodeja) ilman vastaavia integraatiosovittimen päivityksiä, saastuttaa hiljaisesti kansallisen ERP:n datan. Integraatioarkkitehtuurin on sisällettävä automaattinen datavalidointi rajapisteessä ja selkeä omistajuus sovittimen päivitysprosessista.

Keskikerrosmallit: sovitin, julkisivu ja anti-corruption-kerros

Hallitsevat keskikerrosmallit puolustuksen ERP-integraatiolle ratkaisevat kukin ongelman eri osa-alueen.

Sovitinmalli tarjoaa käännöskerroksen kenttäsovelluksen API:n ja ERP:n rajapinnan välille. Sovitin tuntee molempien osapuolten tietomallit ja kääntää pyynnöt ja vastaukset niiden välillä. Sovittimet sopivat, kun kenttäsovelluksella ja ERP:llä on vakaat, hyvin määritellyt rajapinnat ja niiden välinen kartoitus on hallittavissa monimutkaisuudessa.

Julkisivumalli esittää yksinkertaistetun rajapinnan kenttäsovellukselle, piilottaen taustalla olevan ERP:n monimutkaisuuden. Logistiikkajulkisivu voi tarjota yksinkertaisia operaatioita — "pyydä tarvikenimikettä X määrässä Y yksikölle Z" — samalla kun se sisäisesti hoitaa monimutkaisen SAP-kutsujen, työnkulun hyväksyntöjen ja datatransformaatioiden sarjan. Julkisivu sopii, kun ERP-rajapinta on monimutkainen eikä kenttäsovellustiimin tarvitse ymmärtää ERP:n sisäisiä toimintoja.

Anti-Corruption Layer (ACL) on arkkitehtuurimalli Domain-Driven Designista, joka on erityisen merkityksellinen vanhojen puolustuksen ERP-järjestelmien integroinnissa. ACL suojaa kenttäsovelluksen verkkotunnus-mallia ERP:n datarakenteiden ja terminologian saastuttamiselta. ACL tarjoaa käännösrajan, joka pitää kenttäsovelluksen mallin puhtaana ja ERP-kohtaiset konseptit integraatiokerroksessa.

Reaaliaikainen vs. erä-synkronointi: milloin kumpi

Synkronointistrategialla kenttäsovelluksen ja kansallisen ERP:n välillä on merkittäviä operatiivisia vaikutuksia. Kaiken ei tarvitse virrata reaaliajassa, ja kaiken reaaliaikaiseksi tekeminen luo luotettavuus- ja monimutkaisuusongelmia.

Reaaliaikainen synkronointi sopii datalle, jonka vanhentuminen yli muutaman minuutin aiheuttaa operatiivisia ongelmia. Hankintapyynnön status — "onko hätäpolttoaineeni pyynnöt hyväksytty ja lähetetty?" — on ehdokas reaaliaikaiseen synkronointiin. Reaaliaikainen synkronointi vaatii, että molemmat järjestelmät ovat samanaikaisesti saatavilla, ja vaatii integraatiokeskikerrosta käsittelemään yhteysvirheet sulavasti.

Erä-synkronointi sopii datalle, joka muuttuu hitaasti ja jossa säännölliset päivitykset riittävät. Omaisuuskirjadata — auktoritatiivinen tietue siitä, mitä kalustoaa yksikön pitäisi olla — muuttuu hitaasti ja voidaan synkronoida päivittäin tai vuorokohtaisesti. Erä-synkronointi on kestävämpi verkon katkosten aikana.

Käytännön arkkitehtuuri useimmille kenttä-ERP-integraatioille yhdistää molemmat: reaaliaikaiset tapahtumaohjatut päivitykset operatiivisesti kriittiselle statusdatalle, tuettuna säännöllisellä erätäsmäytyksellä, joka havaitsee ja korjaa ristiriitoja, jotka kertyivät reaaliaikayhteyden degradoituessa. Tämä hybridilähestymistapa tarjoaa operatiivisen ajankohtaisuuden kriittiselle datalle samalla kun se varmistaa lopullisen johdonmukaisuuden kaikille datatyypeille.