Hei,
Ja oikein hyvää alkanutta vuotta!
Data-ala on pahamaineisen tunnettu loputtomasta määrästä buzzwordeja, eli ammatti- termeistä, joita kukaan muu kun alan ihmiset eivät ymmärrä (emmekä mekään näitä aina ymmärrä:)
Nyt uusi sellainen on Data Mesh, jota nyt koko datamaailma hypettää. Ennen kuin tyrmätään se ohi meneväksi muoti-ilmiöksi, niin tarkastellaanpa konseptia tarkemmin.
Moni nimittäin on julistamassa sitä uudeksi vallitsevaksi paradigmaksi data-alalla, eli ajattelutavan isomman mittakaavan muutokseksi.
Täytyy sanoa, että siinä on paljonkin järkeä, koska kyse ei ole lainkaan teknologiasta vaan työn organisoinnista sekä arkkitehtuurista.
Data Mesh ei käänny kovin hyvin suomeksi, mesh tarkoittaa silmukkaa tai verkkosilmukkaa, joten pysyn nyt vielä Data Mesh termistä (muuten termille Big Data ei ikinä löydetty sellaista suomenkielistä vastinetta, joka olisi jäänyt käyttöön).
Data Meshin esitteli ensimmäistä kertaa Zhamak Dehghani niminen konsultti ThoughtWorksilta.
Keskitetty data-alusta
Nykyinen paradigma perustuu keskitettyyn data platformiin, joka pitää arkkitehtuurin näkökulmasta sisällään tietoaltaan (data lake) ja tietovaraston (data warehouse). Teknologioita tähän on monia, niihin en ota tässä kantaa.
Tämä jako on tuttu monille, mutta lyhyesti: data lakeen voidaan tallettaa kuvaa, tekstiä, ääntä ja ns big dataa. Se toimii usein myös ns “lastauslaiturina” tietovarastolle.
Tietovarastoon tallennetaan määrämuotoista dataa, kuten asiakkaat, tilaukset ja tuotteet.
Tämän kokonaisuuden kehittämisestä ja ylläpidosta vastaa usein data engineerien ja muiden teknisten asiantuntijoiden tiimi.
Varsinainen data tuotetaan muualla, eli eri esim IT-järjestelmissä ja applikaatioissa. Näitä ovat esimerkiksi ERP, CRM ja sadat muut sovellukset. Niistä vastaavat omat IT-asiantuntijat.
Datakuluttajia ovat taas johtajat ja business controllerit jotka haluavat saada tietoa vaikkapa myynneistä ja katteista. Myös data-analyytikot sekä tekoälykehittäjät ovat hekin datan kuluttajia.
Keskittämisen paradigma
Nykyinen ratkaisu siis perustuu keskittämiselle, eli kaikki data keskitetään yhteen keskusvarastoon, josta dataa tarjoillaan eri käyttäjäryhmille kulutettavaksi.
Data-alustan lisäksi myös datatiimi on keskitetty ja toimii matriisissa samaan tapaan kuin vaikkapa henkilöstöosasto. Muut organisaation osat ovat ikään kuin heidän asiakkaitaan (sisäinen asiakas), joille palvelua toimitetaan.
Malli perustuu organisaatioteorialle, jossa on ydinliiketoimintaa, kuten tuotanto ja myynti. Ne ovat omia yksiköitä. Sitten on tukifunktiot, jotka palvelevat eri näitä yksiköitä keskitetysti.
Ajatus on tietysti hyvä. Sen sijaan, että jokaisella yksiköllä olisi oma IT- ja HR-osastonsa, on vain yksi osasto joka palvelee kaikkia. Näin saavutetaan skaalautuvuutta, synergiaetuja sekä kustannussäästöjä.
Tässä on kuitenkin yksi mutta. Data ei ole enää monelle pelkkä tukifunktio, vaan keskeinen osa liiketoimintaa.
Mitään liiketoiminta ei nimittäin voi tänä päivänä kehittää ilman dataa. Siksi dataosaamisen pitää tulla lähemmäs bisnestä.
Keskitetyn data-arkkitehtuurin haasteet
Ennen sanottiin, että jokin operatiivinen IT-järjestelmä, vaikkapa ERP, on tuote (product) ja sitten sieltä tuleva data on ikään kuin sivutuote, eli by-product.
Zalando, eli euroopan suurin muodin verkkokauppa on eri mieltä. Heidän mielestään dataa pitäisi kohdella tuotteena, eli data as a product.
Zalando lähti kehittämään Data Mesh-mallia, koska keskitetty systeemi ei toimi data as a product -maailmassa.
Nykymallissa dataa siis tuotetaan IT-järjestelmissä. Tietyt asiantuntijat ovat vastuussa siitä, että ne pyörivät.
Nämä samat ihmiset eivät kuitenkaan ole tekemisissä datanhallinnan kanssa. He eivät usein edes tiedä, että dataa ylipäänsä viedään mihinkään alustalle analyysiä varten.
He siiis tavallaan tuottavat dataa, mutta eivät ota vastuuta tuotoksistaan, datan kannalta ajateltuna. Heiltä puuttuu omistajuus (ownership) tuottamaansa dataan.
Keskitetty datatiimi, jonka tehtävä on viedä data IT-järjestelmistä keskitetylle data-alustalle, ei puolestaan yleensä tunne kyseistä dataa, koska eivät ole mukana tuotantoprosessia.
Myös heidän on vaikea tuntea omistajuutta tästä datasta, koska eiväthän he sitä tuota.
Sitten datan kuluttajat, eli johtajat, business controllerit ja data scientistit ovat tyytymättömiä, koska kestää liian kauan saada dataa analyysiin tai laatu on huonoa.
Keskitetty datatiimi on siis kaikista heikoimmassa asemassa, koska he saavat haukut kuluttajilta, mutta eivät voi vaikuttaa datan tuotantoon eivätkä tiedon laatuun.
Ongelma kiteytyy siis siihen, että IT-järjestelmien ylläpitäjät tuottavat dataa, mutta he eivät kommunikoi datatiimin tai datan kuluttajien kanssa.
Dataputki (data pipeline) tuotannosta kulutukseen ei siten toimi, kuten pitäisi.
Data Meshin periaatteet
Data Meshin mukaan dataputken toteutus tulisi siirtää keskitetyltä datatiimilltä liiketoiminta-alueille (domain).
Kukin liiketoiminta-alue siis ottaa vastuun omasta datasta eli domain-datasta, jolloin sama porukka vastaa koko dataputkesta aina datan tuotannosta hyödyntämiseen asti.
Toisin sanoen keskitetystä arkkitehtuurista siirrytään hajautettuun malliin, mutta ei kuitenkaan täysin:
Itse tekninen data-infrastruktuuri on keskitetty ja sama kaikille, mutta dataputki rakennetaan aina domainkohtaisesti, eli hajautetusti.
Tällä ei siis tosiaan tarkoiteta sitä, että että joka liiketoiminta-alue rakentaisi omat tietovarastot- ja altaat, vaan että fyysinen data-alusta pysyy keskitettynä.
Data Mesh ajattelussa tärkeää on juuri edellä mainittu data tuotteistaminen. Kuten minkä tahansa tuotteen kanssa, myös data tuotteen pitää vastata seuraaviin kysymyksiin:
Mikä on tuotteeni markkina? Mitä ovat (sisäisten) asiakkaiden tarpeet? Miten tuotetta markkinoidaan? Ovatko nykyiset asiakkaat tyytyväisiä?
Tämä osuus sukua eräälle blogilleni, jossa kerron kuinka datatiimin pitäisi toimia kuin sisäinen startup.
Ns Domain-Distributed Architecturen idea on myös se, että tiimit järjestetään liiketoiminta-alueiden ympärille, jolloin heistä tulee tietyn domainin asiantuntijoita.
Data Mesh siis yksinkertaistettuna tarkoittaa sitä, että datan tuottajat, käsittelijät ja kuluttajat pitäisi saada saman pöydän ääreen suunnittelemaan datatuotteita.
Juuri tämän ongelman ratkaisemiseen asiakkaat käyttävät muuten Ellietä, siis parantamaan yhteistyötä ja ymmärrystä datasta kaikkien osapuolten välillä.
Yhteenveto
PIdän Data Mesh-ajattelusta siksi, että se tuo datanhallinnan lähemmäs liiketoimintaa. Itse termistä en ole niin varma, mutta olen ehdottomasti yhteistyön parantamiseen liittyvän kehityksen kannalla.
Se ei siis ole pelkästään data laken tyyppinen arkkitehtuuriratkaisu tai mikään yksittäinen teknologia. Ajatus on siirtyä dataputken rakentamisessa monoliittisista systeemeistä mikropalveluihin.
Datatuotteista on puhuttu jo pitkään, mutta Data Mesh ottaa kantaa siihen, miten tuo työ tulisi organisoida.
Vaikka paradigman idea on hajauttaminen, näyttelee ns Data Governance-osuus siinä erittäin tärkeää roolia, koska datatuotteiden pitää olla yhdenmukaisia.
Data Governancen rooli on olla ikään kuin tuotepäällikkönä, joka vastaa siitä, että joka tehdas tuottaa samaa laatua ja samoilla menetelmillä.
Hajauttamisen ei tule johtaa kuitenkaan siiloihin: keskittämisen ideahan oli alunperin juuri siiloista eroonpääsy.
Ajatus siitä, että datan tuotanto, tekniset asiantuntijat ja liiketoiminta pelaavat paremmin yhteen on siis äärimmäisen kannatettava.
Data Meshin soveltaminen edellyttää toki korkeaa datanlukutaitoa, maturiteettitasoa ja ymmärrystä siitä, että voittavat yritykset panostavat dataan.
Jos johto pitää ERP:n pystytystä ja ylläpitoa monin verroin tärkeämpänä kuin siitä syntyvää dataa, ei Data Mesh arkkitehtuurin lanseeraus onnistu.
Meillä Ari Hovin konsultti Jari Ylinen itse asiassa on soveltanut jo pitkään tätä ajattelua, siis jo ennen kuin sitä alettiin kutsua maailmalla Data Meshiksi. Hänet voi pyytää paikalle kertomaan lisää asiasta, eli miten tuota sovelletaan käytännössä.
Tässä on vielä termin kehittäjän artikkeli sekä video Zalandon case-esimerkkiin.
Ystävällisin terveisin,
Johannes Hovi
Ps. Järjestämme jälleen suositun Python-koulutuksen, jonka vetäjänä on Suomen parhaaksi koodriksi valittu Jari “Jaffa” Jaanto.
Python ohjelmoinnin perusteet Azurea ja Dataa hyödyntäen 15.2 -16.2.2021
Python on yksi maailman top3 käytetyimmästä ohjelmointikielestä. Sen sovelluskohteista data-analyysi, datatiede sekä tekoälyn kehittäminen ovat kasvavimmat. Python on jo ohittanut R-kielen suosiossaan.
Ota Python nyt haltuun osallistumalla tälle kurssille, jolla opit varmasti!
Lisätiedot ja ilmoittautuminen tästä.
