Tietokanta on nostettava modernisaatiosuunnittelussa erikseen asialistalle. Muuten voidaan päätyä rakentamaan uusi alusta, joka säilyttää vanhan ympäristön rajoitteet ja haasteet lähes sellaisinaan.
Järjestelmät voivat olla käytössä huomattavan pitkään, mutta niiden alla olevia palvelimia, virtualisointiratkaisuja ja muita alustakomponentteja uudistetaan usein noin viiden vuoden välein. Tämä tarjoaa luontevan hetken arvioida suuntaa hieman pidemmälle kuin seuraavaan laitehankintaan.
Modernisoinnissa kannattaa miettiä, mitä seuraavalla alustakaudella halutaan parantaa ja mitä uusia mahdollisuuksia modernisoinnin pitäisi avata.
Nostan esiin viisi näkökulmaa, jotka tietokantojen ja alusta-arkkitehtuurin modernisoinnissa kannattaa huomioida.
1. Missä dataa jalostetaan tekoälyn käyttöön?
Tekoälyratkaisujen onnistuminen riippuu siitä, onko käytettävä data ajantasaista, laadukasta, ymmärrettävää ja turvallisesti hyödynnettävissä. Käytännössä tekoälyhankkeen ensimmäinen vaikea kysymys ei useinkaan koske kielimallia, vaan dataa ja sen arkkitehtuuria.
Onko järkevää siirtää ja kopioida data erilliselle data- tai AI-alustalle? Vai voidaanko vektorisointi, semanttinen haku, hybridihaku ja osa muusta AI-käsittelystä toteuttaa siellä, missä data jo sijaitsee?
Molemmille vaihtoehdoille on paikkansa. Kun AI-kyvykkyydet tuodaan lähelle tietokantaa, voidaan parhaimmillaan vähentää datan tarpeetonta kopiointia ja hyödyntää jo olemassa olevia käyttöoikeuksia, auditointia, salausta sekä tiedon elinkaaren hallintaa. Rajapintojen kautta data voidaan tarjota hallitusti sovelluksille ja tekoälytyönkuluille.
Toisaalta useista lähteistä yhdistettävä data, suuret dokumenttimassat ja laajemmat koneoppimisen tarpeet voivat puoltaa erillistä data- tai AI-alustaa. Oikea ratkaisu ei siksi ole automaattisesti ”kaikki tietokantaan” tai ”kaikki ulos tietokannasta”.
Oleellista on tehdä valinta hallitusti. Samalla on määriteltävä datan merkitys, omistajuus, käyttöoikeudet, alkuperä ja laatu. Hyvä dataontologia tai semanttinen kerros voi parantaa AI-työnkulkujen johdonmukaisuutta, mutta luotettavuus edellyttää lisäksi lähteiden, mallien, promptien ja hakuketjujen hallintaa.
2. Suojataan myös data, ei vain reittiä sen luokse
Tietoturvassa on pitkään keskitytty päätelaitteisiin, verkkoihin ja siihen, miten hyökkääjä estetään pääsemästä ympäristöön. Ne ovat edelleen välttämättömiä suojauksia, mutta eivät yksin riitä.
Kuten asia on osuvasti kiteytetty: ”Forget the rats, protect the cheese.” Hyökkääjän tavoite ei yleensä ole päätelaite tai palvelin itsessään, vaan niiden kautta saavutettava data, liiketoimintaprosessi tai mahdollisuus kiristää organisaatiota.
Tietokantaturvallisuudessa tämä tarkoittaa muun muassa:
- Tuettuja ja säännöllisesti päivitettyjä tietokantaversioita
- Vähimpien oikeuksien periaatetta ja vahvaa tunnistautumista
- Pääkäyttäjäoikeuksien hallintaa
- Salausta ja avainten hallintaa
- Tietokantatapahtumien auditointia
- Poikkeavan käytön tunnistamista
- Toimivia varmistuksia ja suojattua varmistusketjua
Näiden lisäksi tarvitaan kyky nähdä, mitä koko ympäristössä tapahtuu, ja reagoida poikkeamiin nopeasti. Esimerkiksi Advanian Agentic SOC yhdistää havaintoja identiteeteistä, päätelaitteista, verkoista ja pilvipalveluista sekä auttaa viemään tilanteen havainnosta vastatoimiin sekunneissa. Tämä täydentää tietokantaan rakennettuja kontrollimekanismeja, mutta ei korvaa niitä, kuten ei myöskään pelkkä päätelaitteiden suojaus.
Myös sääntely vaikuttaa arkkitehtuurivalintoihin. GDPR:n lisäksi huomioon voivat toimialasta ja organisaation roolista riippuen tulla NIS2, DORA ja CRA. Niiden soveltamisalat ovat erilaisia, mutta yhteinen suunta on selvä: riskienhallinnan, jatkuvuuden, haavoittuvuuksien hallinnan, auditoinnin ja poikkeamiin reagoinnin on oltava suunniteltua ja todennettavaa.
3. Saatavuus ja palautumiskyky on rakennettava yhdessä
Yötä päivää toimivassa tehtaassa, verkkokaupassa tai kriittisessä digitaalisessa palvelussa ylläpitotyölle voi olla hyvin vähän sopivia käyttökatkoja. Samalla tietokantoja on päivitettävä, tietoturva-aukkoja korjattava ja ympäristöä kehitettävä.
Järkevästi suunnitellut HA- ja DR-ratkaisut parantavat järjestelmän saatavuutta ja palautumiskykyä, mutta helpottavat myös normaalia ylläpitoa. Päivityksiä voidaan toteuttaa palvelin, noodi tai ns. “site” kerrallaan ilman käyttökatkoa tai vain muutamien minuuttien katkolla. Tarkka toteutus riippuu käytetystä tietokannasta, lisensoinnista, sovelluksen rakenteesta ja hyväksyttävästä riskitasosta.
Kaikki järjestelmät eivät tarvitse kahden konesalin aktiivista arkkitehtuuria tai pilveen rakennettua varaympäristöä. Tekninen ratkaisu pitää suhteuttaa liiketoiminnan määrittelemiin palautumisaika- ja palautuspistetavoitteisiin sekä siihen, mitä järjestelmän keskeytyminen maksaa.
Jatkuvuus ei silti synny pelkästä arkkitehtuurikuvasta. Sitä pitää ylläpitää ja harjoitella. Käytännöllinen vuosikello voi sisältää esimerkiksi:
- Tietoturva- ja ylläpitopäivitykset 2–4 kertaa vuodessa
- Varmistusten toimivuuden jatkuva valvonta
- Palautus- ja jatkuvuusharjoitus vähintään kerran vuodessa
- Dokumentaation tarkastaminen ja päivittäminen harjoituksen yhteydessä
- Seuraavan vuoden teknisen ja liiketoimintalähtöisen roadmapin suunnittelu
Varmistus, jota ei ole palautettu, on vasta hyvä oletus.
4. Tehdyistä teknologiavalinnoista pitää saada enemmän irti
Modernisointi ei vapauta organisaatiota teknologiatoimittajista tai lisenssimalleista. Jos liiketoimintakriittinen järjestelmä on rakennettu esimerkiksi Oracle Database- tai SQL Server-teknologian varaan, siirtyminen kokonaan toiseen teknologiaan voi olla kallis ja pitkä projekti.
AI-avusteiset työkalut voivat helpottaa koodin analysointia, testausta ja joitakin migraation vaiheita. Ne eivät kuitenkaan poista tietomallien, SQL:n, integraatioiden, suorituskyvyn, operoinnin ja sovellusriippuvuuksien eroja. Teknologiakonversio pitää edelleen perustella saavutettavilla hyödyillä.
Usein realistisempi tavoite onkin maksimoida jo tehtyjen investointien arvo ja vähentää nykyisen teknologian haittoja.
Esimerkiksi Oracle-ympäristössä tämä voi tarkoittaa siirtymistä omassa konesalissa ylläpidetystä tietokannasta ulkoisen toimittajan jaettuun kapasiteettiin (Esimerkkinä Advanian jaettu Oracle kapasiteetti) OCI:n hallittuun tietokantapalveluun tai OCI:n Autonomous AI Databaseen. Esimerkiksi OCI:n Autonomous tietokannassa kapasiteettia voidaan automaattisesti skaalata ylös ja alas työkuorman mukaan ja ylläpitotyötä automatisoida. Autonomous AI Databasen compute autoscaling voi kasvattaa käytettävissä olevat CPU- ja IO-resurssit enintään kolminkertaisiksi määriteltyyn peruskapasiteettiin nähden, ja lisäkapasiteetista laskutetaan käytön mukaan.
Samalla kannattaa arvioida myös ympäröivää alustaa. Voidaanko sovelluspalvelimia siirtää hallitumpaan pilviympäristöön, hyödyntää automatisoitua Linux-alustaa, kontittaa sopivia osia tai viedä niitä Kubernetes-alustalle?
Tavoitteena ei ole luvata täydellistä vapautta toimittajasidonnaisuuksista. Tavoitteena on tehdä sidonnaisuudet näkyviksi, vähentää niiden haittoja sekä kehittää kustannuksia, skaalautuvuutta ja ylläpidettävyyttä hallitusti.
5. Modernisoinnilla vähennetään myös osaamisriskiä
Monen kriittisen järjestelmän jatkuvuus on edelleen muutaman kokeneen asiantuntijan varassa. He tuntevat vuosien aikana syntyneet poikkeukset, integraatiot, käyttökatkorajoitteet ja ne kohdat, joihin ei mielellään kosketa. Tämä ei ole vain tekninen velka. Se on liiketoimintariski.
Modernisoinnin yhteydessä kannattaa siksi tarkastella teknologian lisäksi dokumentaatiota, automaatiota, valvontaa, vastuurooleja ja ylläpitomallia. Kaikkea osaamista ei tarvitse siirtää organisaation ulkopuolelle, mutta kriittisen ympäristön ei pitäisi olla yhden henkilön muistin varassa.
Kun ympäristöstä on ajantasainen dokumentaatio, sovitut ylläpitoprosessit, osaava palvelutiimi ja suunniteltu kehitysroadmap, modernisointi ei jää kertaprojektiksi. Siitä syntyy jatkuvaa elinkaaren hallintaa.
Suunta ratkaisee enemmän kuin yksittäinen teknologiavalinta
Tietokannan ja alustan modernisoinnissa tärkein päätös ei lopulta ole se, ostetaanko seuraavaksi tietty palvelin, tietokantaversio tai pilvipalvelu. Tärkeämpää on päättää, millaista suorituskykyä, jatkuvuutta, tietoturvaa, kustannusrakennetta ja kehityskykyä seuraavalta elinkaarivaiheelta tavoitellaan.
Noin viiden vuoden alustasykli tarjoaa tälle hyvän tarkastelupisteen, mutta roadmapia pitää arvioida vuosittain. Maailma, vaatimukset ja teknologia muuttuvat nopeammin kuin infrastruktuuri ehditään uusia.
Kun alusta-arkkitehtuuri, tietokannat, tietoturva, jatkuvuus ja ylläpitomalli suunnitellaan yhtenä kokonaisuutena, organisaation omat asiantuntijat saavat enemmän aikaa liiketoiminnan ja palveluiden kehittämiseen. Samalla teknologiaa voidaan kehittää ennakoivasti sen sijaan, että seuraava muutos käynnistyy vasta laitteiston, lisensoinnin tai vanhentuneen ohjelmistoversion pakottamana.
