Asiakastarina · Länsi-Uudenmaan hyvinvointialue · 2024 →
Pistemäisestä tietotuotannosta yhtenäiseen tietoalustaan
Länsi-Uudenmaan hyvinvointialue siirtyi tietotuotannossaan ohjelmistokehityksen menetelmiin. Yhteistyö alkoi vuonna 2024 ja jatkuu.
Länsi-Uusimaa oli teknisesti edellä jo ennen kuin yhteistyö alkoi. Juuri siksi sen ongelma oli vaikeampi kuin useimmilla: alue oli päässyt niin pitkälle, että seuraava pullonkaula ei enää ollut alusta vaan tapa tehdä työtä sen päällä.
Perustiedot
- Asiakas
- Länsi-Uudenmaan hyvinvointialue (LUVN)
- Toimiala
- Julkinen sosiaali- ja terveydenhuolto, hyvinvointialue
- Kesto
- 2024 → jatkuu
- Inviniten rooli
- Tietotuotannon arkkitehtuuri ja menetelmä, toteutus yhdessä LUVN:n datainsinööritiimin kanssa
- Ympäristö
- Azure Data Lake, Databricks Lakehouse
- Menetelmät
- PySpark ja Python, yksikkötestatut muunnosfunktiot, CI/CD, datakontraktit
Lähtötilanne
Vuonna 2024, pian toimintansa alkamisen jälkeen, LUVN teki ratkaisun, jonka harva verrokki teki yhtä aikaisin: se ohitti perinteisen tietovaraston kokonaan ja siirtyi suoraan Azure Data Lake - ja Databricks Lakehouse -arkkitehtuuriin. Alkuvuodesta 2025 ensimmäiset raportit olivat tuotannossa.
Alue oli kuitenkin itse tunnistanut rajan, johon se oli tulossa. Lakehousea ei voi rakentaa yksittäisten raportointisovellusten ehdoilla. Jokainen uusi raportti oli oma määrittelynsä, tekijänsä näköinen tekninen toteutus ja oma totuutensa, ja jokainen niistä oli riippuvainen siitä ihmisestä, joka sen oli tehnyt. Tarvittiin jalostettu tietopohja, joka palvelee useaa käyttötarkoitusta luotettavasti. Datainsinööritiimin menetelmiin tarvittiin erityisesti automaattinen testaus ja laadunvarmistus.
Miksi tämä on vaikeampi ongelma, kuin miltä näyttää
Tietovaraston korvaaminen lakehousella on hankinta. Sen jälkeen tuleva ongelma ei ole. Kun jokainen tietotuote määrittelee oman totuutensa, virhe ei näy virheenä vaan kahtena eri lukuna samasta asiasta. Se löytyy siinä kokouksessa, jossa luvun piti olla päätöksen peruste. Korjaus on käsityötä, käsityö ei skaalaudu, ja mitä enemmän tietotuotteita syntyy, sitä vähemmän niihin uskalletaan koskea.
Tähän ei ole työkaluratkaisua. Se on menetelmäkysymys, ja menetelmä muuttuu vain, jos sen kanssa työskentelevät ihmiset muuttavat tapaansa tehdä työtä. Siksi tämä ei ollut toimitusprojekti.
Mitä tehtiin
Neljä muutosta, joista jokainen on tarkistettavissa koodista.
SQL:stä PySparkiin ja Pythoniin
Merkittävin yksittäinen muutos. Se tekee datainsinöörityöstä ohjelmistokehitystä eikä kyselyiden kirjoittamista, ja sen myötä kaikki ohjelmistokehityksen välineet tulevat käyttöön sellaisenaan.
SQL-skriptiä ei voi yksikkötestata mielekkäästi. Funktion voi.
Pitkistä putkista pieniin muunnosfunktioihin
Käsin validoidut, pitkät dataputket pilkottiin muunnosfunktioiksi, jotka kehittäjä voi testata paikallisesti, ennen kuin mitään ajetaan.
Virhe löytyy kehittäjän koneelta minuuteissa, ei tuotannosta kuukausien päästä.
Automaattinen testaus ja julkaisu datan elinkaareen
Testaus ja käyttöönotto automatisoitiin (DevOps ja CI/CD). Laadunhallinta siirtyi ihmisen muistin varasta putkeen, joka ajetaan joka kerta.
Laatu, joka riippuu siitä, muistaako joku tarkistaa, ei ole laatua vaan tuuria.
Datakontraktit
Kontraktit ovat tekninen keino tallentaa kuvaus tietomallin sisällöstä: ne kuvaavat teknisesti ja loogisesti sen ydindatan, joka vastaa todellisen maailman ilmiöitä. Ne välittävät olennaiset metatiedot, kertovat, missä elinkaaren vaiheessa data on, ja määrittelevät laatusäännöt ja omistajuuden. Ne kulkevat koodin mukana kehityksestä tuotantoon. Tämä on se kohta, jossa laadun validointi muuttuu automaattiseksi kaikissa arkkitehtuurikerroksissa. Se on myös sama rakenne, joka myöhemmin tekee tekoälystä luotettavan: kielimalli saa yksiselitteisen selityksen siitä, mitä kukin tietorakenne toiminnan termein tarkoittaa. Datakontraktien toteutukseen valittiin laajasti käytetty avoin julkinen standardi (ODCS).
Mikä muuttui
Toimintamalli, jonka voi toistaa
Syntyi kuvattu toimintamalli, joka ei ole yhden tiimin tai yhden ihmisen varassa. Koodikäytännöt, tietoallas- ja data-arkkitehtuuri ja roolit.
Hallittu julkaisusykli
Julkaisut ovat hallittavampia ja niitä voidaan tehdä tiheämmin. Kaikki julkaisut testataan automaattisilla laatu- ja integraatiotesteillä ja niiden vaikutukset tietotuotteisiin ymmärretään.
Arkkitehtuurin kehitys jatkuu
Toimiva arkkitehtuuri mahdollistaa tietoaltaan monipuolisemman hyödyntämisen raportoinnin lisäksi tekoälykehittämiseen, ketterään ja luotettavaan analytiikkaan ja ulkoisten sovellusten tietolähteiksi, samalla on siirrytty kohti tiedon demokratisointia.
Asiakkaan näkemys
Siirtyminen Data as Software -malliin on muuttanut perusteellisesti tapamme lähestyä tietotuotantoa – haluamme ymmärtää datan ja tuottaa tietoa. Kahden vuoden tiivis yhteistyö on antanut meille mahdollisuuden käsitellä dataa ydintuotteena, ja se on parantanut sekä dataputkiemme että tietotuotteidemme nopeutta ja luotettavuutta. Hyvinvointialueelle tämä tarkoittaa tarkempaa, tietoon perustuvaa ymmärrystä, joka lopulta tukee parempaa päätöksentekoa ja parempaa hoitoa asukkaillemme.
Miksi tämä ei ollut toimitusprojekti
Menetelmä ei syntynyt siitä, että Invinite toi valmiin mallin. Se syntyi siitä, että LUVN:llä oli selkeä suunta alustalleen ja poikkeuksellinen kyky arvioida erittäin monimutkaisia data- ja koodiarkkitehtuuriehdotuksia. Me suunnittelimme teknisen arkkitehtuurin ratkaisemaan juuri LUVN:n ongelmat, ja he arvioivat sen kriittisesti. Näin pitkälle viety menetelmä ei olisi kehittynyt ilman sitä vastavuoroisuutta.
Työtapa rakentui matkan varrella eikä etukäteen. Dokumentaatio, työnkulut ja se, mitä opittiin, ovat molempien tiimien yhteisiä. Niitä ei luovuteta lopussa, koska ne on kirjoitettu yhdessä koko ajan.
Mitä tämä mahdollistaa seuraavaksi
Kurinalainen tietopohja on tekoälyn edellytys, ei sen vaihtoehto. Datakontraktit ovat tässä ratkaisevia. Tietojohdon on olennaista tunnistaa, ettei loppuun voi hypätä suoraan. LUVN:n tapauksessa etenemisjärjestys on kaksivaiheinen.
Tekoälyavusteinen kehitys
Agentti ymmärtää yhteisen käsitteistön, toimialojen toiminnan piirteet, tietopohjan ja kehitysprosessin vaiheet. Näin se pystyy merkittävästi tehostamaan datainsinöörien, BI-kehittäjien, analyytikoiden ja toimialojen johdon työtä kehittämisessä.
Työkalut tiedon hyödyntäjille
Kun rakenne, tietosisältö ja tekoälykyvykkyydet on osoitettu luotettaviksi kehittämisessä, tekoälyn käyttö voidaan laajentaa kaikille tiedon hyödyntäjille. Edellytyksenä on, että taustalla oleva data pysyy hyvin määriteltynä, laadukkaana ja käyttöoikeuksiltaan hallittuna.
Miksi onnistuimme
Uuden menetelmän kehittäminen ja samanaikainen käyttöönotto onnistui osin siksi, että asiakas on poikkeuksellisen kyvykäs. LUVN oli määritellyt hyvin tahtotilansa ja pystyi arvioimaan arkkitehtuuriehdotuksia kriittisesti. Organisaatiossa, jossa ei ole omaa teknistä kykyä ottaa kantaa, sama menetelmä olisi johtanut joko hitaampaan etenemiseen tai siihen, että toimittaja olisi päättänyt asioita yksin. Nyt kun menetelmä on kypsä ja ratkaisevat linjat on tehty, mallia voidaan ottaa käyttöön laajemmin myös muissa organisaatioissa.