Ennen kuin siirrät tietojasi, tarkista, onko se välttämätöntä

Jos olet data-insinööri tai -arkkitehti, jolle on annettu tehtäväksi tietokannan modernisointi, keskusteluun on yleensä jo valmiiksi määritelty lopputulos. Esimerkiksi se, että vanha järjestelmä on poistettava käytöstä tai tiedot on siirrettävä. Kun pohdit tietojen siirtoa, on tärkeää kysyä itseltäsi, onko tietojen siirto ylipäätään oikea lähestymistapa.

Miksi ”Migration” valitaan oletuksena

Tietokannan siirto on hyvin tunnettu prosessi, johon on olemassa vakiintunut työkalupaketti. SQL Server Migration Assistant, AWS Database Migration Service, Azure Migrate ja lukuisat kolmannen osapuolen alustat saavat siirron tuntumaan jo ratkaistulta ongelmalta. Työkalujen arviointi, aikataulujen arviointi ja siirtosuunnitelman laatiminen ovat kaikki tehtäviä, joiden suorittamiseen tiimit ovat tottuneet.

Vähemmän ymmärretään sitä, miksi siirtymistä ylipäätään ehdotetaan. Ilmoitettuna syynä on yleensä modernisointi: siirtyminen vanhasta paikallisesta järjestelmästä pilvialustalle, hajanaisten tietovarastojen yhdistäminen tai sellaisten analytiikkatoimintojen mahdollistaminen, joita nykyinen järjestelmä ei tue.

Todellinen syy on useimmissa tapauksissa se, että nykyistä järjestelmää on vaikea käyttää tietojen hakemiseen. Seuraavassa on esitetty joitakin vanhojen järjestelmien yleisiä haasteita:

• Hitaat raportit

• BI-työkalujen luotettavan yhteyden muodostamisen epäonnistuminen

• Analyytikot eivät voi hakea tietoja ilman IT- tai tekniikan osaston apua

Vaikka tiedot sinänsä ovat kunnossa, niiden käyttökerros ei ole. Ratkaisuksi ehdotetaan siirtymistä, koska se on näkyvää ja mitattavissa, mutta se ei ratkaise oikeaa ongelmaa.

Mitä maahanmuutto todellisuudessa maksaa

Siirtymävaiheen aikana käytössä on kaksi järjestelmää rinnakkain. Vanhaa järjestelmää ei voida poistaa käytöstä, koska tuotanto riippuu siitä edelleen, kun taas uuteen järjestelmään on syötettävä tiedot, se on validoitava ja pidettävä synkronoituna, kunnes siirtymäaika on määritetty. Tämä rinnakkaiskäyttöjakso vaatii paljon insinöörityötä, aiheuttaa infrastruktuurikustannuksia ja vaatii organisaation huomiota.

Siirtyminen ei välttämättä ratkaise kaikkia tietoon liittyviä ongelmia. Esimerkiksi kyselyt, jotka toimivat tyydyttävästi vanhassa tietokannassa, saattavat käyttäytyä eri tavalla uudessa tietokannassa, ja jos jokin järjestelmä on jätetty käyttöön, koska sen käytöstäpoisto olisi ollut liian riskialtista, joudut nyt ylläpitämään synkronointiprosessia vanhan ja uuden järjestelmän välillä loputtomiin.

Tämä ei tarkoita, että siirto ei olisi koskaan oikea ratkaisu. Joskus tiedot on todellakin siirrettävä alustalle, joka käsittelee niitä paremmin. Siirron tekniset kustannukset ja toiminnalliset riskit ansaitsevat kuitenkin yhtä tarkkaa tarkastelua kuin sen hyödytkin.

Pääsyongelma, jota siirtymä pyrkii ratkaisemaan

Kun siirtymisen todellinen syy on kyselyjen suorituskyky tai BI-työkalujen yhteensopivuus, ratkaisuvaihtoehtoja on enemmän kuin ensi silmäyksellä näyttää.

Vanhaa järjestelmää, jota on vaikea kysellä BI-työkalun avulla, ei välttämättä tarvitse korvata. Sen sijaan se vaatii paremman käyttöliittymän. Standardeihin perustuvat ODBC- ja JDBC-ajurit tarjoavat BI-työkaluille, analytiikka-alustoille ja integraatioprosesseille yhtenäisen SQL-rajapinnan lähteisiin, joihin ne eivät tällä hetkellä pääse käsiksi. Tiedot pysyvät paikoillaan, kun taas raportointi- ja analytiikkakerrokset käsittelevät niitä suoraan.

Tämä koskee erityisesti organisaatioita, joilla on jo olemassa olevia tietoja esimerkiksi Apache Iceberg -muodossa tai jotka harkitsevat Trinoa kyselykerrokseksi. Trino on hajautettu SQL-kyselymoottori, joka tukee tietojen kyselyä useista lähteistä samanaikaisesti, mukaan lukien Iceberg-taulukot, ilman että tietoja tarvitsee siirtää tai kopioida.

Milloin maahanmuutto on oikea ratkaisu ja milloin se ei ole

Siirtyminen on järkevää, kun alusta itsessään on rajoittava tekijä. Jos vanha järjestelmä ei kykene käsittelemään liiketoiminnan tarvitsemia tietomääriä, jos siitä puuttuvat lainsäädännön edellyttämät tietoturva- ja vaatimustenmukaisuusominaisuudet tai jos sen elinkaari on päättymässä ilman toimittajan tukisuunnitelmaa, kyseessä ovat todelliset alustaan liittyvät ongelmat, jotka oikeuttavat alustan vaihdon.

Siirtäminen on väärä ratkaisu, kun rajoittava tekijä on pääsy tietoihin. Hitaat raportit, epäluotettavat BI-yhteydet ja analyytikoiden riippuvuus kehittäjistä tietojen poiminnassa ovat merkkejä yhteysongelmasta. Niiden ratkaiseminen siirtämällä tietoja lisää kuukausien työmäärää ja jatkuvaa toiminnallista monimutkaisuutta ongelmaan, jonka ratkaisu voisi onnistua muutamassa päivässä.

Diagnoosikysymys on siis seuraava: jos analytiikkakokonaisuutesi jokainen työkalu voisi tehdä kyselyjä suoraan nykyiseen järjestelmääsi, tarvitsisitko silti siirtää tietoja uuteen järjestelmään? Monille organisaatioille rehellinen vastaus on ”ei”.

Yhteyksien käsitteleminen infrastruktuurina

Useimmissa siirtymiskeskusteluissa on havaittavissa, että tietojen saatavuutta pidetään pikemminkin tietokannan ominaisuutena kuin erillisenä infrastruktuurikysymyksenä. Jos tietokannasta on vaikea tehdä kyselyjä, oletetaan, että tietokantaa on muutettava. Vaihtoehtoa, eli luotettavan käyttökerroksen rakentamista olemassa olevan järjestelmän päälle, harkitaan harvoin yhtä vakavasti.

Insightsoftwaren Simba on yhteyskerros, johon maailman johtavat data-alustat – kuten Google, Microsoft ja Databricks – luottavat omien datan käyttötuotteidensa toteuttamisessa. Sama standardipohjainen ODBC- ja JDBC-yhteys, joka kattaa vanhat tietokannat, pilvialustat, SaaS-järjestelmät, NoSQL-tallennustilat sekä kyselymoottorit, kuten Trino ja Presto, on yritysten tiimien käytettävissä Simba-ajurikatalogin kautta. Jokainen ajuri tarjoaa lähdekoodinsa SQL-rajapinnan kautta, joka toimii Tableau-, Power BI-, Logi Symphony- ja muiden merkittävien BI-alustojen kanssa.

Trinon Simba-ajuri yhdistää minkä tahansa ODBC- tai JDBC-yhteensopivan BI-työkalun suoraan kyseiseen kyselykerrokseen, jolloin analyytikot pääsevät käyttämään SQL:ää sellaisiin tietoihin, joihin ei aiemmin päässyt käsiksi ilman siirtoprojektia.

Konkreettisena esimerkkinä: organisaatio, jonka operatiiviset tiedot ovat hajallaan paikallisissa tietokannoissa ja pilvitallennustiloissa, voisi käyttää Apache Icebergia yhteisenä taulukkomuotona ja Trinoa kyselymoottorina, ja liittää sitten Power BI:n, Tableaun tai Logi Symphonyn Simba Trino -ajurin kautta. Tietoja ei siirretä lainkaan. Analysointikokemus on täysin samanlainen kuin modernista pilvitietovarastosta tehtävissä kyselyissä. Lisätietoja siitä, miten tämä toimii käytännössä, löytyy insightsoftwaren artikkelista, jossa käsitellään yksityiskohtaisesti Apache Icebergin ja Simba-ajurin integrointia.

Organisaatioiden, joiden on tehtävä päätös järjestelmän siirtämisestä, tulisi punnita yhteyskerroksen etuja suhteessa täydellisen siirtymisen vaikutuksiin. Vanhat järjestelmät ansaitsevat modernisoinnin, ja parempi yhteyskerros johtaa samaan lopputulokseen kuin järjestelmän siirtäminen ilman ylimääräisiä kustannuksia ja riskejä.

Haluatko tietää lisää? Lue raporttimme, jossa käsitellään tietoyhteyksien päätöksenteon viitekehystä.