Vanhojen sovellusten modernisointi ei tarkoita koko ohjelmiston kirjoittamista uudelleen kerralla. Monelle yritykselle parempi ensimmäinen kysymys on, minkä toiminnon pitää muuttua, mikä voi toistaiseksi jatkaa ja miten tilaus pysyy oikeana siirtymän aikana. DAXS jäsentäisi siksi nykyisen Windows- tai Linux-sovelluksen tiedot, rajapinnat ja valmistajan hyväksynnät ennen päätöstä uudesta käyttöliittymästä, API:sta tai alustasta.
Nykyisen VM:n siirto voi erottaa käyttöjärjestelmän laitteistosta, mutta ei vielä modernisoi itse sovellusta. VMware/Proxmox-siirron hyväksyntä on erillinen vaihe. Tässä käsitellään toimintojen ja integraatioiden pidemmän aikavälin muuttamista liiketoiminnan jatkuessa.
Kuvaa nykytila ja määritä sitten raja
Kartoitus tarvitsee muutakin kuin palvelinnimien luettelon. Jokaisen palvelun sovelluskorttiin kuuluvat omistaja, käyttäjäryhmät, Windows- tai Linux-versio, tietokanta ja ajurit, eräajot, tiedostojaot, tulostimet, identiteettilähde, saapuvat ja lähtevät rajapinnat sekä ylläpito- ja lisenssisopimus. Erityisen tärkeitä ovat vähän näkyvät polut: öinen CSV-vienti kirjanpitoon, palvelutili vanhenevine salasanoineen tai työasemasiakas, jonka versio on sidottu palvelimeen.
Suljetussa ohjelmistossa valmistaja määrittää tuetut vieraskäyttöjärjestelmät, tietokantaversiot, ajurit ja virtualisointiympäristöt. Suora kirjoitus valmistajan tietokantaan voi näyttää helpolta integraatiolta mutta rikkoa liiketoimintasääntöjä, takuuehtoja ja myöhempiä päivityksiä. DAXS tutkisi ensin dokumentoidun API:n, hyväksytyn viennin tai valmistajan SDK:n. Ilman mitään tuettua integraatiokohtaa vaiheittainen korvaaminen voi olla teknisesti tai sopimuksellisesti sopimatonta; silloin tarvitaan toinen ratkaisu toimittajan kanssa.
Esimerkki: uusi tilausnäkymä, vanha tilausydin
Oletetaan, että sisäisessä tilaushallinnassa on Windows-sovelluspalvelu, SQL-tietokanta ja öinen vienti. Asiakkaat kysyvät usein tilausten tilaa, mutta vanha ydin käsittelee tilaukset ja laskut luotettavasti. Ensimmäinen uusi toiminto voisi olla vain lukuun tarkoitettu tilanäkymä, joka saa tiedot käyttämällä hyväksyttyä rajapintaa. Tilausydin ja sen tietokanta pysyvät aluksi määräävänä lähteenä.
Integraatiokerros muuntaa vanhat tunnisteet ja tilat dokumentoiduksi uudeksi malliksi. Periaate tunnetaan sovittimena tai Anti-Corruption Layer -kerroksena. Se ei ole taika-API hallitsemattoman tietokannan edessä: tilauskohtaiset oikeudet, tunnistautuminen, syötteiden tarkistus, kutsurajat, lokitus ja vasteajat on arvioitava uudelleen. OWASP nostaa objektikohtaisen valtuutuksen ja tunnistautumisen keskeisiksi API-riskeiksi. Pelkkä tilan lukeminenkään ei saa paljastaa muiden tilauksia.
Vasta lukutoiminnon vakiinnuttua voi seurata rajattu kirjoitusprosessi, esimerkiksi yhden tilaustyypin syöttäminen. Tietovastuu on nyt ratkaiseva: niin kauan kuin vanha ydin on määräävä, uusi käyttöliittymä ei saa huomaamatta luoda toista itsenäistä totuutta. Jokaiselle tietueelle määritetään kirjoittava järjestelmä, pyyntöjen yksiselitteinen tunnistus sekä epäonnistumisten, myöhästyneiden viestien ja korjausten täsmäytys. Molempien samanaikainen kirjoittaminen ei ole siirtymäsuunnitelma ilman liiketoiminnan ristiriitamallia.
Neljä vaihetta ja mitattava pysäytyspiste
| Vaihe | Muutos | Näyttö ennen seuraavaa vaihetta |
|---|---|---|
| 1. Turvaa nykytila | Kirjaa riippuvuudet, sopimukset, tietovirrat ja palautettavat varmuuskopiot | Palauta sovellus ja tietokanta testiverkossa; täsmäytä esimerkkitilaus liiketoiminnan kanssa |
| 2. Erota lukeminen | Käytä hyväksyttyä vientiä/API:a uuteen tilanäkymään | Mittaa tilan oikeellisuus, katseluoikeudet, päivitysviive ja kuorma vanhaan järjestelmään nähden |
| 3. Siirrä yksi kirjoitustapaus | Vie vain yksi tilaustyyppi uuden rajapinnan kautta; määritä tietovastuu | Kirjaa jokainen tilaus tasan kerran, täsmäytä tositteet ja korjaukset, harjoittele paluu |
| 4. Poista vanha osa | Sammuta vasta toimintojen ja tietojen siirtymisen todentamisen jälkeen | Ei selvittämättömiä piilokutsujia, vienti-/säilytysvelvoitteita tai valmistajariippuvuuksia |
Toimintojen vaiheittainen korvaaminen muistuttaa Strangler Fig -mallia. Se ei sovi kaikkialle: jos pyyntöjä ei voi ohjata, toimittaja sulkee kaikki rajapinnat tai pieni järjestelmä on helppo korvata kokonaan, sovitin voi aiheuttaa enemmän työtä kuin hyötyä. Siirtymäkerros tarvitsee itsekin valvontaa, kapasiteettia ja ylläpitäjän; siitä ei saa tulla uutta yksittäistä vikaantumispistettä.
Määritä paluu ennen ensimmäistä tuotantokirjoitusta
Vain lukevalle tilanäkymälle paluu on usein helppo: poista uusi näkymä käytöstä, jatka tilausytimellä ja tutki syy. Ensimmäisen uuteen tietokantaan tehdyn kirjoituksen jälkeen välityspalvelimen palauttaminen vanhalle reitille ei riitä. Uudet tilaukset, peruutukset ja tositteet on vietävä vanhaan tilaan tai täsmäytettävä liiketoiminnallisesti. Jokaiseen vaihtoon kuuluvat siksi viimeinen täsmäytetty tietotila, selkeä kirjoituskatko, vienti-/tuontimenettelyt, vastuuhenkilöt ja harjoitus. Microsoft varoittaa nimenomaisesti paluun vaikeutuvan, kun vanhoja tieto-objekteja on poistettu.
Myöskään vanhaa ympäristöä ei saa unohtaa rinnakkaiskäytön aikana. Jos käyttöjärjestelmä tai sovellus ei saa enää tietoturvapäivityksiä, asianomaisia palveluita, verkkoreittejä ja pääsyä on rajattava, valvottava ja niille asetettava poistumispäivä. Uusi API edessä ei poista vanhan ytimen haavoittuvuutta. Eristämisen riittävyys riippuu konkreettisesta riskistä ja valmistajan saatavilla olevista toimista.
Arvioi työ ja rajat rehellisesti
Kolmen tai viiden vuoden vertailu sisältää vähintään nykytila-analyysin, valmistaja- ja lisenssiselvitykset, sovitinkehityksen, tietojen muunnokset, tietoturva-arvion, testitiedot, liiketoiminnan hyväksynnän, rinnakkaiskäytön, valvonnan ja myöhemmän purkamisen. Lisäksi voidaan tarvita uusia järjestelmä- tai tietokantalisenssejä ja molempia ympäristöjä tilapäisesti hoitavien ihmisten koulutusta. Rinnakkaiskäyttö on tietoinen kustannus, ei ilmainen välivaihe. Vaiheittainen ratkaisu kannattaa vasta, kun vältetyt riskit ja uudet toiminnot perustelevat todellisen työn; yleistä säästöprosenttia ei voida johtaa.
DAXS valitsisi liiketoiminnan kanssa pienen näkyvän ensimmäisen rajauksen, kuten esimerkin tilakyselyn, ja hyväksyisi sen tietojen oikeellisuuden, vasteajan, tuettavuuden ja palautuksen perusteella. Sitten päätettäisiin, mikä seuraava toiminto todella tarvitsee oman palvelunsa. Nykyisen VM:n teknisen perustan osalta Proxmox yrityksessä kuvaa infrastruktuurin raamit; API-yhteyksien ennakoitava ylläpito täydentää myöhempää rajapintojen hallintaa. Sovelluskortin laatimiseksi DAXSiin voi ottaa yhteyttä kohdasta Yhteystiedot.
Lähteet: Microsoft Azure Architecture Center: Strangler Fig -malli · Microsoft: Anti-Corruption Layer -malli · OWASP: API Security Top 10.
