Hei,

Julkaisemme tässä syksyn aikana tiedon mallintamiseen liittyviä kirjoituksia.

 

Tässä olisi ensimmäinen, hyviä lukuhetkiä!

Data-alustan toteutuksen ohjaaminen arkkitehtuurista

Kerron tässä blogissa hieman kokemuksia data-alustan rakentamiseen liittyvästä tiedon mallinnuksesta isoissa ympäristöissä.

Siitä huolimatta, että nämä kokemukset heijastavat isojen organisaatioiden monimutkaisia datahankkeita, samat periaatteet pätevät myös pienempiin hankkeisiin. Käytän talonrakennusta esimerkkinä: parhaat rakentamisen periaatteet pätevät niin omakotitalon kuin kerrostalonkin rakentamisessa.

Toteutus monitoimittajaympäristössä

Kun rakennetaan pilvipohjaista data-alustaa, dbt–Snowflake- tai Databricks-työnkulku on hyvin yleinen.

Usein palvelua ostetaan konsulteilta, mutta entistä enemmän näemme yritysten omatoimisuuden kasvavan,on ymmärretty, että pitkällä aikavälillä on hyvä pitää osaaminen osittain omissa käsissä.
Luonnollisesti ulkopuolisia konsultteja tarvitaan, ja työtä tehdään yhdessä heidän kanssaan.
Kun mukana on useampia kehittäjiä, tilanne saattaa kuitenkin monimutkaistua. Saatetaan päätyä tilanteeseen, jossa huomaamatta devaajille sysätään liian paljon vastuut data-alustan arkkitehtuurista ja koodista.

Tämä on usein iso haaste, miten se selätetään?

Keskitetty data-alusta vaikuttaa data-arkkitehtuuriin ja governanceen

Kun tehdään oikeasti enterprise-tason alustaa, jonka on tarkoitus toimia organisaation keskitettynä datavarastona, data-alustalle tehdyt ratkaisut vaikuttavat itse asiassa koko yrityksen data-arkkitehtuuriin sekä data governanceen merkittävästi.

Data-alustan kehittäjillä, erityisesti ulkopuolisilla, ei kuitenkaan ole näkymää yrityksen laajempaan data-arkkitehtuuriin tai strategiaan, mutta silti he käytännössä päätyvät siihen vaikuttamaan rakentaessaan data-alustaa.

Olen ollut hankkeissa mukana, joissa iso yritys oli suunnitellut hyvän alustaprojektin ja käyttänyt siinä todella päteviä senior-konsultteja.

Eräs projektissa ollut keskeinen koodari ei kuitenkaan ollut halukas avaamaan tekemiään koodausratkaisuja. Kun niistä kysyttiin, hän hieman loukkaantui ja koki, että hänen ammattitaitoaan epäillään.

Tilanne johti siihen, että asiakas ei ymmärtänyt tehtyjä ratkaisuja ja konsultin lähdettyä iso osa alustasta piti tehdä uudelleen. Hänen koodinsa oli varmasti hyvää, mutta hän ei tehnyt sitä itselleen, vaan asiakkaalle.

Data-alustan rakentaminen vs. talon rakentaminen

Vertauskuvana voisi käyttää talon rakentamista:

Arkkitehti yhdessä teknisten suunnittelijoiden kanssa tekee suunnitelmat, päättää materiaalit ja käytännössä pitkälle koko lopputuloksen, ja rakennusmiehet rakentavat talon mallien pohjalta.

Olisi outoa ajatella, että rakennusmiehet päättäisivät piirustukset, materiaalit ja tekniset ratkaisut työmaalla ilman pohjapiirustuksia. Joku heistä voisi olla huippuluokan kirvesmies, enemmän artesaani kuin teollinen rakentaja.

Data-alustaprojekteissa näin kuitenkin usein tapahtuu, kuten edellisessä esimerkissä kuvasin. Tähän tilanteeseen päädytään erityisesti silloin, kun lähdetään toteuttamaan alustaa ns. bottom-up -periaatteella eli kopioimalla lähdejärjestelmien rakenteita suoraan data-alustaan.

Toinen tilanne on Data Vault -arkkitehtuuri. Se on monesti erittäin hyvä ratkaisu, mutta yksi sen haasteista on vaikea ymmärrettävyys.

Ironista kyllä, tilanteeseen päätyminen ei yleensä johdu koodaajan osaamisen puutteesta – päinvastoin. Isoissa organisaatioissa teollinen tuotanto on kuitenkin tärkeämpää kuin “artesaanikoodi”.

Potentiaaliset haasteet

Edellä kuvattu toimintapa johtaa moniin haasteisiin. Kerroin esimerkin, jossa koodaus piti aloittaa alusta konsulttien lähdettyä.

 

Helposti käy niin, että valittu arkkitehtuuri ja koodi ei tue jatkokehitystä, omat IT-osaajat eivät sitä täysin ymmärrä, SQL-kyselyt monimutkaistuvat ja data-alustan kustannukset kasvavat nopeasti.

Nämä ovat välittömiä seurauksia. Vähän ajan päästä tekninen velka kasvaa liialliseksi, data-arkkitehtuuri ja pipelinet monimutkaistuvat, kehitys hidastuu ja governance-malli muuttuu tarpeettoman raskaaksi. Lopputulos: kustannukset kasvavat, joudutaan tekemään tuplatyötä ja projektien aikataulut venyvät.

Miten sitten toimia?

Kannattaa tehdä kuten talonrakennuksessa: aloittaa ylätasolta ja pitää huolta, että työtä pystytään ohjaamaan sekä dokumentointi on nopeaa – tai jopa pitkälle automatisoitua.

Esimerkiksi Ellie.ai:n tiedon mallinnustyökalulla voit suunnitella data-alustan “asemakaavan” ja kääntää sen teknisiksi piirustuksiksi hyvin helposti (koska GenAI). Malli voidaan jakaa kaikille osapuolille, ja kaikki pääsevät siihen käsiksi.

 

Ellie.ai voi “imeä” skeemat suoraan lähdejärjestelmistä (yli 150 tietokantaa) tai esimerkiksi Snowflakesta ja Databricksistä. Yleensähän toteutus on ELT-, ETL- tai jotakin siltä väliltä.

Ylätason malleista voidaan edetä tarkempiin loogisiin ja fyysisiin datamalleihin. Ellie.ai muuttaa nämä dbt.yaml-tiedostoksi, joka toimii viitemallina toteutukselle.

Näin kriittiset päätökset tehdään suunnitteluvaiheessa, kehittäjillä on selkeät ohjeet, ja projekti etenee nopeasti varmistaen ratkaisun pitkäikäisyyden, aikataulussa pysymisen sekä budjetinhallinnan. Olemme toteuttaneet tätä lähestymistapaa useille suurille eurooppalaisille yrityksille.

Kysy lisätietoja, niin voimme näyttää, miten tämä toimii käytännössä.

 

Mikäli sinulla on vastaava tech stack käytössä, voimme kertoa, miten ns. “top-down” -lähestymistapa toteutetaan – joten ota ihmeessä yhteyttä!