“Data Mesh on moderni tietoarkkitehtuurimalli, joka tarjoaa vaihtoehdon perinteisille keskitetyille data lake- ja data warehouse -ratkaisuille. Palvelut omistavat datansa. Data engineerit ja analyytikot työskentelevät osana palvelutiimejä…”
Suurin piirtein näin Data Mesh -arkkitehtuuria joskus koronan alkuaikoina minulle esiteltiin. Silloin en vakuuttunut; olihan kaikki siihenastiset organisaationi eriyttäneet datatekemisen enemmän tai vähemmän irralleen palvelukehityksestä. Ei oltu Spotifyn kaltainen kehitysorganisaatio, vaikka ehkä näin olisikin yritysjohdossa visioitu. Minulla oli vahvat datalasit silmillä, mutta toisaalta niin oli myös henkilöllä, joka ko. arkkitehtuuria minulle yritti myydä.
Ei resonoinut. Pari vuotta myöhemmin myhäilin kun Gartner:n kartalla Data Mesh päätyi obsolete before plateau -tilaan tarkoittaen, että ajatus ei välttämättä lähdekään lentoon, mutta osia sieltä voidaan ottaa käyttöön.
Näin on myös tapahtunut: Data Mesh -ajattelusta data tuotteet saivat uutta nostetta. Tälläkin hetkellä monet haastattelemamme yritykset tekevät datastrategiaa, jonka pohjana on tuotteistaa dataa. Datatuote on enemmän kuin pelkkä datamassa – se on huolellisesti suunniteltu, hallittu ja ylläpidetty kuten mikä tahansa digitaalinen palvelu.
Mutta palataan vielä Data Meshiin hetkeksi.
Mikä on Data Mesh?
Vuonna 2019 Zhamak Dehghani julkaisi ensimmäiset artikkelinsa Data Mesh -arkkitehtuurista. Tekstit on julkaistu martinfowler.com:ssa, joka on yksi ohjelmistokehityksen ja -arkkitehtuurin merkittävimmistä tietolähteistä. Sivustolla on syväluotaavia artikkeleita mm. ohjelmistokehityksen ketteristä kehityskäytännöistä, hajautetusta arkkitehtuurista ja mikropalveluista. Tutustuessani viime vuosina syvemmin ohjelmistokehityksen käytäntöihin olen ymmärtänyt, että Data Mesh -periaatteet sitovat sisäänsä paljon samoja ajatuksia, joita softapuolella on jo vuosia käytetty: vahva omistajuus, hajautettu arkkitehtuuri ja DevOps-tyyppinen ketterä kehitys.
Nopea summaus: Data Mesh perustuu neljään pääperiaatteeseen:
- Domain-omisteinen data – Vastuu datasta siirtyy keskitetyiltä data-tiimeiltä liiketoimintayksiköille. Time-to-market on optimi-tapauksessa lyhyempi.
- Data tuotteena – Dataa käsitellään tuotteina, joilla on omat laatuvaatimukset, rajapinnat, käyttäjät, kehitys-backlogit, jne.
- Self-service data-alusta infra – Infrastruktuuri mahdollistaa datatuotteiden luomisen yhtenäisellä tavalla (tarjoaa moduuleja, joilla kehitys oletusarvoisesti nopeampaa)
- Federoitu hallintomalli – Yhteiset standardit ja käytännöt takaavat yhteentoimivuuden (pääsynhallinta, rajapintavaatimukset, SLA-luokat, laadunhallinta..), mutta toisaalta mahdollistavat tiimin autonomian raamien sisällä
Ohjelmistokehityksen puolella tämä vastaisi “palvelut ja kyvykkyydet”-lähtöistä ajattelua: Liiketoimintayksiköillä on vahva omistajuus palveluihinsa, jolloin palveluita kohdellaan suurinpiirtein tuotteina. On olemassa talotasoiset cloudops-kyvykkyydet helpottamassa palveluiden kehitystä ja oikeastaan aina löytyy myös yhteiset käytännöt, jotka asettavat kehitystiimeille raamit, joissa toimia.
Mikseivät sitten suurinpiirtein näillä lähtökohdilla digitaalista kehitystä tekevät yritykset siirry samalla datakehityksessä kohti Data Mesh:ä?
Eikö olisi helpompaa jos säännöt olisivat samat niin digikehityksessä, kuin myös datakehityksessä?
Conwayn laki ja sen vaikutus
”Organisaatiot suunnittelevat järjestelmiä, jotka peilaavat niiden omaa viestintärakennetta” -Melvin Conway 1967 (vapaasti suomennettuna)
Usein Conwayn laki esitetään ohjelmistokehityksen kontekstissa. Raaka yksinkertaistus: iso tiimi, niin lopputuloksesta syntyy yksi suuri monoliitti, mutta jos on pienemmät tiimit ja hyvä kommunikaatio, niin saadaan lopputuloksena modulaarinen ja palvelupohjainen arkkitehtuuri.
Toisaalta Conwayn laki kuvaa hyvin myös laajempia organisaatiorakenteita. It-organisaatiossa perinteisesti järjestäydytään it-järjestelmien ympärille, jolloin myös kehitys on järjestelmälähtöistä. Tällöin kokonaiskuva saattaa hämärtyä ja on hankalaa saada maaliin kehitystä, joka läpileikkaa useita järjestelmiä.
Datapuolellakin perinteisen keskitetyn tietovaraston ympärille rakentuva malli on viestintärakenteen kannalta tarkasteltuna lähempänä it-organisaatiota kuin ketterää palvelukehitystä. Liiketoiminta on tottunut saamaan raportit ja muut tietotuotteet pyytämällä datapuolelta. Tai vaikka liiketoiminnassa olisikin analyytikkoja, niin sitten analyytikot pyytävät datapuolelta datan saataville. Saattaa olla vaikea edes kuvitella maailmaa, jossa itsepalvelumaisesti liiketoiminnan puolella tehtäisiin myös datakehitystä ja teknologia vain tarjoaisi työkalut siihen?
Mikäli kuitenkin tähän suuntaan halutaan liikkua, niin pitää ottaa huomioon, että liiketoimintalähtöinen datakehitys vaatii tottakai muutosta liiketoimintayksiköissä:
- Mitä datalla halutaan saavuttaa liiketoimintayksikön sisällä? Kuka miettii tavoitteet ja roadmapit?
- Miten varmistetaan riittävä tekninen osaaminen, jotta taataan jatkuvuus?
- Miten sovitaan ja pidetään kiinni yhteisistä toimintamalleista yli yksiköiden?
- Ja vielä yleisesti: mitä liiketoimintalähtöisyydellä kehityksessä ylipäätään haetaan eli mitä ongelmia nykyisessä toimintatavassa nähdään?
Tartun erityisesti näistä toimintamalleihin. Siirtyessä puhtaammin liiketoimintalähtöiseen päätöksentekoon saatetaan aiheuttaa suuriakin heijastevaikutuksia teknologian puolelle. Teknologiaosasto voi ajautua mahdollisesti vielä aiempaa kauemmaksi liiketoiminnasta, jolloin erityisesti teknisiin kyvykkyyksiin liittyvät yritystason toimintamallit pitää pystyä varmistamaan. Lisäksi teknologia-puolella dataan liittyvät roolit saattavat muuttua esimerkiksi näin:
- Entisestä datapäälliköstä tulisi datakyvykkyyden päällikkö, jolloin rooli olisi varmistaa tekninen kyvykkyys pitkässä juoksussa, eikä niinkään olla mukana päätöksissä itse dataan liittyen.
- Entisestä datan arkkitehdista tulisi jatkossa ennemminkin mahdollistava- kuin päättävä rooli: miettien pidemmän aikavälin visiota tekniseltä kannalta, sekä ohjaten tiimejä vision suuntaan raamien kautta.
Useissa organisaatioissa ohjelmistokehitys on jo aikaa sitten mennyt yllä olevaan suuntaan. Esimerkiksi tekniset arkkitehdit nähdään mahdollistajina kehitystiimien onnistumiselle. He tuovat ymmärrystä tiimien ulkopuolisesta maailmasta ja pitävät samalla huolta, että pitkässä juoksussa yhtiön tekninen kehitys on synkassa yli tiimirajojen.
Mutta palataan vielä Data Meshiin. Tarkoitukseni ei ollut sanoa, että “Ottakaa tästä viisi vuotta vanha hype-framework, niin datakehityksenne hyppää seuraavalle tasolle!”, vaan herättää ajatuksia. Data Mesh on vain yksi viitekehys monista, mutta sen avulla pystyin sitomaan lankoja digikehityksen ja datakehityksen välille, luomaan ymmärrystä toimintatavoista.
AI-kehityksessä samaa haastetta on nähtävissä: Minkälaisia organisaatiorakenteita onnistuminen AI-käyttötapauksissa vaatii? Miten kytkeä teknologia-yksikkö mukaan organisaation liiketoimintayksiköiden AI-hypeen ja innovaatiotoimintaan, jotta kokeilut saadaan tuotantoon ja vastuut sovittua järkevästi ylläpidon osalta? Miten sisäinen data saadaan helposti osaksi kokeiluita?
Resonoiko ajatukset? Onko teidän yrityksellä ohjelmisto- ja datakehitys synkassa? Puhumattakaan AI:n tuomista muutoksista? Autan mielelläni sparraamaan haasteissanne!
