Johdanto
Edellisessä julkaisussani kerroin yleisemmin migraatiotestauksesta ja testaukseen liittyvistä peruselementeistä. Julkaisussa kuvatut testausmenetelmät ovat kuitenkin kokemukseni mukaan riittämättömiä silloin, kun tavoitteena on arvioida migroidun datan laatua tarkemmin tai löytää yksittäisiä virheitä. Tähän asti olemme tarkastelleet dataa melko yleisellä tasolla, mutta emme ole vielä pureutuneet siihen, kuinka laadukasta migroitu data todellisuudessa on. Laadulla tarkoitan tässä yhteydessä sitä, että voimme arvioida jokaisen yksittäisen tiedon, kuten korkoprosentin, kertyneen koron tai maturiteetin, oikeellisuutta.
Ennen kuin syvennyn yksittäisten tietojen oikeellisuuden arviointiin, kerron lyhyesti ensimmäisestä kokemuksestani kahden tulosjoukon tietojen vertailusta. Olin työskennellyt tietokantojen parissa noin viisi vuotta, kun tiimimme kokeneempi kehittäjä sai tehtäväkseen vertailla kahden järjestelmän tuottamia tietoja keskenään. Vertailu osoitti nopeasti ne sopimukset, joissa havaittiin eroja. Tulos kuitenkin kertoi vain sen, että ero oli olemassa, ei sitä, missä tiedoissa ero tarkalleen sijaitsi.
Tämä osoittautui merkittäväksi haasteeksi, sillä varsinaisen ongelman selvittäminen alkoi vasta eron löytymisen jälkeen. Ratkaisuksi kehitettiin automatisoitu kenttäkohtainen vertailu, joka tunnisti suoraan ne tiedot, joissa lähde- ja kohdejärjestelmän arvot poikkesivat toisistaan. Sen sijaan, että kehittäjän olisi pitänyt nähdä vaivaa poikkeavien kenttien löytämiseksi, vertailu kertoi suoraan, missä kentissä oli eroja.
Tämä näennäisen pieni laajennus muutti testauksen tehokkuutta merkittävästi. Aikaa ei enää kulunut siihen, että ongelma ensin löydettiin, vaan huomio voitiin kohdistaa suoraan eron selvittämiseen. Samalla vertailusta tuli huomattavasti tehokkaampi prosessi kehityksen tueksi. Seuraavaksi käyn läpi, miten tätä lähestymistapaa voidaan hyödyntää migraatiohankkeiden datan validoinnissa.
Datan validointi
Datan validoinnilla tarkoitan uuden ja vanhan järjestelmän tietojen vertailua keskenään yksityiskohtaisella tasolla. Se on yksi haastavimmista migraation validointitehtävistä, sillä kyseessä on eräänlainen DW-raportointitasoinen (Data Warehouse) muuttamattomuustestaus, jossa täytyy huomioida myös datamuutosten vaikutukset. Ennen varsinaista validointivaihetta on siksi tärkeää käydä tavoitteet läpi liiketoimintamäärittelijöiden, asiantuntijoiden ja liiketoimintaomistajien kanssa. Näin varmistetaan, että datan validoinnin laajuus, periaatteet ja hyväksyttävät poikkeamat on selkeästi määritelty ja ymmärretty.
Asiakkaana on myös tärkeää ottaa vastuuta tästä työvaiheesta. Kyseessä on eräänlainen UAT-testaus (User Acceptance Testing), jota ei tule jättää yksin toimittajan harteille.
Validoinnissa tarkastellaan tavallisesti paitsi lähde- ja kohdejärjestelmän rivimääriä, myös kenttä- ja solutasolla esiintyviä odotettuja ja odottamattomia muutoksia. Lähtökohtana on, että tiedot eivät pääsääntöisesti muutu järjestelmien välillä. Tämä ei kuitenkaan tarkoita, että data kopioitaisiin täysin sellaisenaan, koska uuteen järjestelmään voidaan lisätä sopimuksia, joita vanhassa ei ole voitu ylläpitää tai olemassa olevia sopimuksia voidaan rikastaa uusilla tietokentillä. Lisäksi joitakin sopimuksia voidaan siirtää kokonaan toiseen järjestelmään, mikäli uusi järjestelmä ei tue vanhan kaikkia toiminnallisuuksia. Kaikki mainitut esimerkit ovat sellaisia, joihin migraatioprojekti tarvitsee avukseen liiketoiminta-asiantuntijoita ja omistajia.
Datan validointiin liittyy seuraavat työvaiheet:
- Datasta sopiminen
- Viestintämalleista sopiminen
- Luonnollisten avainten tunnistaminen
- Testattavan kokonaisuuden suunnittelu
- Aineistojen yhtenäistäminen
- Vertailutyökalun rakentaminen/käyttöönotto
- Raportoinnin suunnittelu ja rakentaminen
- Automaation rakentaminen
Datavalidoinnin heikkous on, että siinä joudutaan osittain monistamaan migraatiossa luotua transformaatiologiikkaa. Migraation mahdollisista transformaatioista olen antanut esimerkkejä kappaleessa ”Testattavan kokonaisuuden suunnittelu”. Jotta testausta voidaan ylipäätään tehdä, nämä transformaatiot on toteutettava sekä osana migraatiota että toisessa järjestelmässä, joka muuntaa alkuperäiset arvot halutuksi lopputulokseksi.
Datavalidointi kuitenkin mahdollistaa testauksen huomattavasti tarkemmalla tasolla verrattuna edellisessä julkaisussa mainittuihin testaustapoihin. Parhaimmillaan näin toimien päästään jopa solutasolle. Lisäksi tietokanta mahdollistaa testauksen kattavan kaikki sopimukset tai asiakkaat, jota muissa mainituissa tavoissa on lähes mahdotonta saavuttaa.
Datasta sopiminen
Projekteissa yleensä käydään jossain vaiheessa keskustelu siitä, missä on luvallista käyttää tuotantodataa ja missä tulee käyttää testidataa. Lopullinen testaus on kokemukseni mukaan lopulta aina suoritettu maskaamattomalla tuotantodatalla. Tämän ei kuitenkaan tule olla automaatio, ja tuotantodataa voi käyttää vain perustellusta syystä. Onkin tärkeää sopia jo projektin alussa, mitä dataa eri tilanteissa (käyttötarkoitus, käyttäjät, ympäristö) on luvallista käyttää.
Viestintämallien suunnittelu
Migraation läpivieminen on ehdottomasti tekninen haaste. Projektin kustannuksiin voi kuitenkin vaikuttaa merkittävästi hyvällä viestinnällä. Paremmalla tiedon jaolla olisi lähes aina saatu merkittäviä säästöjä. Valitettavasti kommunikaatiohaasteet huomataan usein liian myöhäisessä vaiheessa. Kokemuksieni mukaan seuraavien kysymysten esittäminen on osoittautunut hyödylliseksi lähes kaikissa migraatioprojekteissani:
- Onko liiketoimintatermit määritelty?
- Onko oikeilla henkilöillä pääsy dataan?
- Onko käyttöoikeuksien hakeminen, myöntäminen ja antaminen selkeästi dokumentoitu?
- Onko projektihenkilöt listattu ja projektiorganisaatio kuvattu?
- Onko ongelmien eskalointiin luotu toimivat ratkaisumallit?
Vältä näitä:
- Tiedon (kuten dokumentaation) ylläpitämistä useassa paikassa
- Esteitä eri työryhmien tai vaiheiden välillä
- Epäselviä vastuita, aikatauluja ja viestintää
Luonnollisten avainten tunnistaminen
Jotta tietoja voidaan vertailla, meidän on tunnistettava ne arvot, joiden avulla datojen yhdistäminen onnistuu. Yleensä silloin pyritään tunnistamaan datasta ns. luonnolliset avaimet.
Luonnollisella avaimella tarkoitetaan entiteetin universaaleja tietoja, jotka eivät muutu järjestelmävaihdon yhteydessä ja joiden avulla tiedon yksilöinti onnistuu. Hyviä esimerkkejä asiakastietoihin liittyvistä luonnollisista avaimista ovat henkilötunnus ja Y-tunnus. Sopimuksilla luonnollisena avaimena toimii esimerkiksi sopimuksen IBAN-tunniste.
On äärimmäisen tärkeää, että tuollainen linkki lähtö- ja tulosjoukon välillä pystytään tunnistamaan. Muuten validointia ei tässä muodossa voida toteuttaa. Käytännössä samalla todetaan, ettei ole mitään tapaa varmistaa, onko tieto siirtynyt oikein. Tämä ei kuulosta kestävältä ratkaisulta. Tämän tyylisiin kommentteihin tulisi suhtautua keskustelun avauksena, jossa todetaan aihe haastavaksi ja vaadittavan varmuustason saavuttamiseksi täytyy tehdä luovia ratkaisuja.
Joskus voi esimerkiksi olla tilanteita, joissa ei löydy yhtä yksittäistä kenttää, jonka perusteella tietojen yhdistäminen onnistuisi. Näissä tilanteissa voidaan käyttää useamman kentän yhdistelmää eli komposiittiavainta. Tärkeintä on, että tiedot pystytään tunnistamaan luotettavasti sekä lähteestä että kohteesta.
Kenttäkohtaista vertausta voidaan tehdä vain niiden kokonaisuuksien osalta, joissa voimme varmuudella todentaa sopimuksen tai kokonaisuuden olevan sama. Tätä voisi kuvata oheisella venn-diagrammilla, joka osoittaa, että vain päällekkäin menevät osuudet voidaan testata.
Testattavan kokonaisuuden suunnittelu
Projektin alussa on hyvä suunnitella, mitä tietokannassa halutaan testata. Migraation aikana datalle tehdään yleensä jotain seuraavista:
- Tiedot viedään muuttumattomina uuteen järjestelmään: Näitä tietoja ovat esimerkiksi tilin saldo migraatiohetkellä, marginaali ja korkoprosentti.
- Tietojen uudelleenluokittelu: Tässä tapauksessa lähdejärjestelmän tieto päivitetään sovitusti. Esimerkiksi lähdejärjestelmän arvo “Ei/Kyllä” voi muuttua uudessa järjestelmässä muotoon “0/1”. Oleellista on, että muutos on yksinkertainen, ja vaikka arvot eivät ole identtiset, niiden merkitys säilyy ennallaan.
- Tietojen jakaminen tai yhdistäminen: Tässä muokkauksessa lähteen ja kohteen sarakemäärät voivat poiketa toisistaan. Kuitenkin tietojen välillä on joku helposti toistettavissa oleva logiikka.
- Jokin muu muokkaus: On mahdollista, että tietoja yhdistetään tavoilla, joiden toimivuutta ei ole helppo todentaa. Järjestelmät voivat tallentaa dataa niin eri muodoissa, että niiden testaaminen vaatii monimutkaisempaa logiikkaa. Tällaisiin muutoksiin ja testaukseen liittyy myös funktionaalista testausta ja integraatiotestausta.
Edelliset esimerkit eivät kata kaikkia mahdollisia tilanteita, mutta pyrkivät havainnollistamaan testauksen monimutkaisuutta. Liiketoiminnan tulee määrittää, mikä on kriittistä dataa, jonka täytyy mennä ehdottomasti oikein: kaikki data ei ole samanarvoista. Migraatioprojektien työntekijöiden tuleekin aktiivisesti auttaa liiketoiminnasta ja datasta vastaavia henkilöitä muodostamaan käsitys yksittäisen kentän tärkeydestä.
Lisäksi testauksella on myös aina kustannusvaikutus. Vaikka itse uskon, että hyvä testaus säästää aina aikaa ja rahaa, voi sen virheellinen suunnittelu tai pahimmillaan hallitsematon toteuttaminen johtaa hankkeen viivästymiseen, lisääntyviin kustannuksiin sekä heikentyneeseen migraation laatuun.
Aineistojen yhtenäistäminen
Koska pankkijärjestelmät tallentavat tiedot hieman eri muodoissa, on vertailun mahdollistamiseksi tärkeää harmonisoida data. Käytännössä tämä kannattaa tehdä niin, että lähdejärjestelmän tieto muokataan vastaamaan kohdejärjestelmään luokittelua. Samalla migraatiosäännöt saadaan testattua. Toinen vaihtoehto on rakentaa vertailu jonkin harmonisoidun tietomallin päälle. Tällöin lähdetiedot ovat jo valmiiksi harmonisoidussa muodossa. Jatkuvuuden varmistamiseksi myös uusi järjestelmä halutaan usein sovittaa samaan tietomalliin.
Tämä vaihe voi viedä paljon aikaa, varsinkin jos migraatiosääntöjä ei ole selkeästi dokumentoitu tai niihin liittyviä muutoksia ei onnistuta kommunikoimaan kaikkien osapuolten kesken. Lisäksi tulee panostaa uuden järjestelmän tietojen dokumentoimiseen ja ymmärtämiseen.
Tähän työvaiheeseen liittyy erityisesti vaade ymmärtää datan liiketoiminnallinen puoli. Jotta tämä vaihe voidaan tehdä tehokkaasti, tulisi tekijöillä olla teknisen osaamisen lisäksi erittäin hyvä ymmärrys liiketoiminnasta. Työvaiheeseen vaikuttaa myös uuden järjestelmän tietomallin dokumentaatio, tietomallin helppokäyttöisyys ja datan muoto.
Datan muodolla tarkoitan, että mikäli tieto ei ole saatavilla yksinkertaisessa relaatiomallissa, voi tiedon muokkaaminen vaatia paljon ylimääräistä työtä, jotta se saadaan käytettävään muotoon.
Vertailutyökalun rakentaminen tai käyttöönotto
Kun aineistot on saatu yhtenäistettyä, tulee vielä rakentaa tai ottaa käyttöön työkalu, jolla tietojen vertaaminen onnistuu tehokkaasti. Markkinoilla on useita vaihtoehtoja, joilla tietokantojen vertaaminen onnistuu. Meillä ALM Partnersilla on kehitetty oma Difference Engine -työkalu, jonka avulla tietokantojen vertailukehikon voi rakentaa helposti ja liittää osaksi testausautomaatiota.
Raportoinnin suunnittelu ja rakentaminen
Kun vertailut on saatu rakennettua, on aika rakentaa raportointi testituloksille. Tässä vaiheessa on hyvä huomioida esimerkiksi seuraavat näkökulmat:
- Mitä dataa raportoinnissa voidaan näyttää (esimerkiksi tunnisteet)?
- Kenellä on pääsyoikeus raportteihin?
- Mitä havainnoista on tärkeää raportoida?
- Minne havaitut poikkeamat raportoidaan?
- Miten havaintojen korjaamista seurataan?
- Kenen vastuulla korjauksen toteuttaminen on?
Virheiden analysointi
Virheiden havaitsemisen lisäksi on myös hyvä käyttää aikaa virheiden juurisyyn analysoimiseen. Mitä enemmän kehittäjille saadaan tietoa ongelmasta, sitä helpompi on tunnistaa, missä kohtaa prosessia virhe on syntynyt. Analysoinnin tukena voi hyödyntää esimerkiksi seuraavia kysymyksiä:
- Vastaako tulos migraatiosääntöä?
- Onko virheellä jokin yhdistävä tekijä vai koskeeko se kaikkia sopimuksia?
Virheiden analysoinnista kannattaa sopia eri osapuolten kesken, koska se saattaa merkittävästi helpottaa projektin etenemistä. Olisi myös hyvä, jos ongelmaa voisi kuvata jotenkin koodillisesti, jolloin sen toistettavuus olisi huomattavasti helpompaa. Yleensä kuitenkin tiedetään, mikä kunkin kentän oikea arvo on tai miksi virhe on ylipäätään raportoitu.
Raportoinnin jatkuvuus
Migraatiohankkeen yhteydessä on hyvä varata riittävästi aikaa myös viranomaisraportoinnin päivittämiselle. Pankeilla on nykyisin mittava raportointivelvollisuus ja osa viranomaisraportoinnista täytyy pyöriä päivittäin. Hankkeen kannalta onkin tärkeää miettiä, miten turvataan raportoinnin jatkuvuus järjestelmäpäivityksen yhteydessä sekä muut integraatiot.
Raportoinnin testaukselle täytyy myös varata riittävästi aikaa. Harvoin migraatiossa päästään siihen tilanteeseen, ettei mikään muutu sen yhteydessä. Näiden muutosten vaikutusten analysointiin on tärkeää varata myös riittävästi aikaa.
Yhteenveto
Migraatiohankkeet ovat pankkitoiminnan vaativimpia projekteja, joissa onnistuminen edellyttää huolellista suunnittelua, laaja-alaista testausta ja syvällistä ymmärrystä sekä vanhasta että uudesta järjestelmästä. Kirjoituksessa käsittelin erityisesti datan validointiin liittyviä vaiheita, kuten luonnollisten avainten tunnistamista, aineistojen harmonisointia ja vertailutyökalujen hyödyntämistä. Korostin myös raportoinnin jatkuvuuden merkitystä.
Onnistunut migraatio ei ole vain tekninen suoritus, vaan se vaatii tiivistä yhteistyötä kaikkien migraatiossa olevien osapuolten kanssa sekä kykyä analysoida ja reagoida havaittuihin poikkeamiin. Hyvin suunniteltu ja toteutettu testaus on avain luotettavaan lopputulokseen – ja lopulta koko projektin onnistumiseen.
Q&A: Datan validointi pähkinänkuoressa
1. Mitä datan validoinnilla tarkoitetaan migraatiohankkeissa?
Datan validoinnilla tarkoitetaan vanhan ja uuden järjestelmän tietojen yksityiskohtaista vertailua. Tavoitteena on varmistaa, että tiedot ovat siirtyneet oikein ja että mahdolliset muutokset ovat odotettuja ja liiketoiminnan hyväksymiä.
2. Miksi perinteinen migraatiotestaus ei yksin riitä?
Perinteinen testaus kertoo usein, toimivatko prosessit ja kokonaisuudet oikein, mutta ei välttämättä paljasta yksittäisten tietojen virheitä. Datan validointi mahdollistaa tarkastelun jopa kenttä- ja solutasolla.
3. Mikä on datan validoinnin tärkein edellytys?
Tietojen luotettava yhdistäminen lähde- ja kohdejärjestelmän välillä. Tätä varten tarvitaan luonnollisia avaimia tai muita tunnisteita, joiden avulla sama sopimus tai asiakas voidaan tunnistaa molemmista järjestelmistä.
4. Mitkä ovat datan validoinnin suurimmat hyödyt?
Validointi auttaa tunnistamaan virheitä tarkasti, mahdollistaa merkittävien siirtyvien tietojen kattavan tarkastuksen ja tukee juurisyiden analysointia. Näin migraation kustannustehokkuus, laatu ja luotettavuus paranevat merkittävästi.
