Kun raportti ei enää riitä tietopohjaksi
Länsi-Uudenmaan hyvinvointialue siirtyi tietotuotannossaan ohjelmistokehityksen menetelmiin. Kaksi vuotta, ei yhtään lukkoa.
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 sote — noin 480 000 asukkaan hyvinvointialue
- Kesto
- 2023 → jatkuu
- Inviniten rooli
- Tietotuotannon arkkitehtuuri ja menetelmä, toteutus yhdessä LUVN:n datainsinööritiimin kanssa
- Ympäristö
- Azure Data Lake, Databricks Lakehouse
- Menetelmät
- PySpark/Python, yksikkötestatut muunnosfunktiot, CI/CD, datakontraktit
- Julkaisulupa
- Asiakkaan antama. Sitaatti asiakkaan omaa tekstiä.
Lähtötilanne
Vuonna 2023, heti hyvinvointialueen perustamisesta, LUVN teki ratkaisun jota harva verrokki teki yhtä aikaisin: se ohitti perinteisen tietovarastoinnin 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ä, oma kyselynsä ja oma totuutensa, ja jokainen niistä oli riippuvainen siitä ihmisestä joka sen oli tehnyt. Tarvittiin jalostettu tietopohja, joka palvelee useaa käyttötarkoitusta luotettavasti — ja datainsinööritiimin menetelmiin 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 — ja 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ä.
DevOps ja CI/CD datan elinkaareen
Testaus ja käyttöönotto automatisoitiin. 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 toimialuekerroksen mallinnuksen päätepiste: 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, määrittelevät laatusäännöt ja omistajuuden — ja kulkevat koodin mukana kehityksestä tuotantoon.
Tämä on se kohta jossa laadun validointi muuttuu automaattiseksi kaikissa arkkitehtuurikerroksissa. Ja se on sama rakenne, joka myöhemmin tekee tekoälystä luotettavan: kielimalli saa yksiselitteisen selityksen siitä mitä kukin tietorakenne liiketoiminnan termein tarkoittaa.
Mikä muuttui
Viikoittainen julkaisutahti
Julkaisun jälkeen uusia toiminnallisuuksia tuotiin tuotantoon viikoittain — ei julkaisuikkunoittain.
Monistettava toimintamalli
Syntyi kuvattu toimintamalli, joka ei ole yhden tiimin tai yhden ihmisen varassa. Sitä on sittemmin sovellettu muualla.
Kaksi vuotta ilman lukkoa
Yhteistyö on jatkunut kaksi vuotta ilman yhtään sopimuksellista tai teknistä sidosta. Jokainen jatkopäätös on ollut asiakkaan oma.
Tämän sivun luvuista sanomme myös sen, miten ne on mitattu. Jos emme voi sanoa sitä, luku ei kuulu tähän.
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; 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ä: ne eivät ole asia joka luovutetaan lopussa, koska ne on kirjoitettu yhdessä koko ajan.
“Asiakas on valinnut jatkaa joka kuukausi kahden vuoden ajan. Se on ainoa jatkuvuuden mittari johon luotamme.”
Mitä tämä mahdollistaa seuraavaksi
Kurinalainen tietopohja on tekoälyn edellytys, ei sen vaihtoehto. Tietojohdon on olennaista tunnistaa, ettei loppuun voi hypätä suoraan. LUVN:n tapauksessa etenemisjärjestys on kolmivaiheinen.
Tekoälyavusteinen kehitys
Agentti ymmärtää toimialuemäärittelyt ja projektinhallinnan tehtävät ja avustaa datainsinööriä sen koodin kirjoittamisessa, joka tuottaa datan.
Tuki datan määrittelyyn
Kun data määritellään koodissa ja sen täsmällinen merkitys selitetään datakontrakteissa, kielimallilla on poikkeuksellisen hyvä pohja ymmärtää sekä data että sen tuottava koodi — ja varmistaa, että uudet määrittelyt noudattavat sovittua arkkitehtuuria.
Liiketoiminnan työkalut
Vasta kun kaksi edellistä on osoittautunut dataspesialisteille luotettavaksi, tekoäly laajennetaan liiketoiminnan käyttäjille. Edellytyksenä on, että taustalla oleva data pysyy hyvin määriteltynä, laadukkaana ja käyttöoikeuksiltaan hallittuna.
Datakontraktit ovat tässä ratkaisevia. Ne antavat kielimallille yksiselitteisen selityksen siitä, mitä kukin tietorakenne liiketoiminnan termein tarkoittaa. Se on ero uskottavalta kuulostavan vastauksen ja todennetun vastauksen välillä.
Mitä tämä tapaus ei todista
Tämä onnistui osin siksi, että asiakas oli poikkeuksellisen kyvykäs. LUVN pystyi arvioimaan arkkitehtuuriehdotuksia kriittisesti ja teki sen. Organisaatiossa, jossa ei ole omaa teknistä kykyä ottaa kantaa, sama menetelmä johtaisi joko hitaampaan etenemiseen tai siihen, että toimittaja päättää yksin — eikä jälkimmäinen ole Data as Software vaan sen ulkokuori. Ensimmäinen asia jonka kartoituksessa selvitämme on siksi se, kuka asiakkaan päässä pystyy sanomaan ei.
OTA YHTEYTTÄ
Onko teillä hanke, joka pitäisi viedä käyttöön asti? Keskustellaan.
Jos emme voi auttaa, sanomme sen.