Marko Oja
Data-arkkitehti, joka auttaa asiakasta ymmärtämään tekniikan mahdollisuudet ja muuntaa innovatiiviset ideat teknisiksi ratkaisuiksi. Ketterät kehitysmenetelmät ja kehitystyötä tukevat prosessit ovat lähellä Markon sydäntä.
DataOps rantautui Gartnerin hype-termistöön vuonna 2018. Sen ympärille on noussut muutama startup ja suuremmat yritykset ovat sovitelleet termiä tuotteisiinsa. DataOps on saanut myös manifestin (koska sehän kuuluu nykyään asiaan), ja aiheesta löytyy myös muutama laajempia ideaa avaavia dokumentteja. Käsitteenä se on kuitenkin hyvin uusi, mutta ideat joista se koostuu on hyödynnetty datakehityksessä jo aikansa.
Lyhyesti DataOps on Gartnerin määritelmän vapaan käännöksen mukaan yhteistyöhön painottava datahallintakäytäntö, joka keskittyy parantamaan kommunikaatiota, datavirtojen integrointia ja automaatiota datan tuottajien ja kehittäjien sekä käyttäjien välillä läpi organisaation. Tämä kuvaus kyllä kertoo vastaukseen kysymykseen mitä, mutta ei miten. Erityisesti se jää hyvin kevyeksi teknisellä tasolla.
Käytännössä DataOps ei itsessään tarjoa mitään syvällisesti uutta, vaan se ainoastaan tuo esille datakehityksen haasteet tai ainakin painotukset niissä. Haasteissakaan ei sinällään ole mitään uutta. Ne kaikki ovat olleet olemassa ja tiedossa. DataOps kuitenkin kerää nämä yhteen ja esittää niihin ratkaisuja kokonaisuutena. Tässä blogisarjassa käydään läpi mistä DataOps koostuu ja miten se tulee vaikuttamaan datakehittämiseen.
Jep. Tämä on tullut kaikille, jotka ovat perehtyneet DataOpsin ideologiaan tarkemmin varmasti selväksi. Se ei silti tarkoita sitä, etteikö DevOps olisi kriittistä myös datakehityksen tulevaisuudelle. Oli sitten mitä tahansa mieltä muista DataOpsin osista, niin tuskin kukaan vastustaa nopeampia, automatisoidumpia ja testatumpia toimituksia. Tätä DataOps lainaa DevOpsista – ympäristöjen pystytyksestä aina toteutuksen integroimiseen tuotantoversioon ja sen lopulliseen toimitukseen. DevOps-tyyppisellä kehittämisellä onkin iso merkitys tulevaisuuden datakehittämisessä. Väistämättä yritykset, jotka eivät panosta nopeaan toimitussykliin, tulevat jäämään jälkeen.
Valitettavasti Suomessa dataliiketoiminta on monilla toimijoilla pitkälti resurssimyyntiä. Silloin kun näin on, on harvinaista, että toimittaja itsenäisesti panostaisi automatisoituun kehittämiseen. Tilaajan tulee siis tulevaisuudessa olla entistäkin enemmänkin hereillä. Usein projekteissa saatetaan käyttää paljonkin aikaa turhaan selvittelyyn, monitorointiin sekä automatisoitavissa olevaan työhön. Jos edellä kuvattua tilannetta verrataan DataOpsin mukaisesti kehitettyyn projektiin, jää tuotetun arvon määrä verrattuna käytettyyn tuntimäärään selvästi pienemmäksi.
Saisiko olla yksi DataOps? Valitettavasti ainakaan ihan vielä ei olla niin pitkällä. Ja huomioiden alan tekniikoiden nopean kehittymisen ja jatkuvan murroksen, on epätodennäköistä, että näin olisi vielä pitkään aikaan. DataOps vaatii organisaatiolta muutoksia ajatteluun siitä, miten datakehitystä ylipäätään tehdään ja hallitaan. Liiketoiminnan täytyy olla entistä syvemmin mukana kehityksessä. Suurten järjestelmien sijaan tulisi keskittyä yksittäisten ominaisuuksien nopeaan kehitykseen ja toimittamiseen.
Näiden lisäksi datatiimien tulisi organisoitua moniosaaviksi sen sijaan, että teknologisesti samaa asiaa tekevät ihmiset sullotaan samoihin tiimeihin. Tähän kun vielä lisätään se, että mikään näistä tai muistakaan panostuksista ei ole ilmaista, eikä niitä juuri voi ostaa valmiissa paketissa, voidaan puhua haastavista muutoksista. Hyvä puoli on kuitenkin se, että uutta menetelmää ei tarvitse ottaa kerralla käyttöön – eikä sitä edes suositella.
DataOpsiin syventyminen tapahtuu siis samalla tavalla kuin allekirjoittaneelta järveen meneminen ensimmäistä kertaa kesällä: jokainen tärisevä askel kerrallaan. Mutta hyödyt onneksi alkavat näkyä nopeasti ja kannustavat jatkuvasti jatkamaan syvemmälle. Onkin tärkeää asettaa mittarit nyky- tai lähtötilasta, ja seurata niiden kehittymistä. Näin on helpompaa perustella seuraavat lisäpanostukset databudjetissa.
Organisaation tulee olla henkisesti halukas lähteä panostamaan dataan, ja päämääränä on oltava liiketoiminnan ohjaus tietoon perustuvilla päätöksillä. Eli vanha kunnon tiedolla johtaminen tulee olla korkealla tavoitteissa.
Kuten kaikkien hypetermien, niin valitettavasti ehkä myös DataOpsin osaksi tulee unohtua jossain vaiheessa historiaan. Uskon silti vakaasti, että DataOps tarjoaa viimeinkin yleisesti hyväksytyn (tai ainakin laajemmin hyväksyttävämmän) tavan toteuttaa dataprojekteja. Se tuo keskitetysti esille sen omalaatuiset ongelmakohdat, sekä tarjoaa niihin ratkaisuja.
Luulenkin, että siitä muodostuu tekninen standardi, joka tulee ohjaamaan käyttämiemme työkalujen kehityssuuntaa tulevaisuudessa. Ja huolimatta siitä mitä tapahtuu DataOpsille, sen esittelemät ongelmat ovat samoja joiden ratkaisemiseksi me kaikki data-arkkitehdit olemme ponnistelleet koko uriemme ajan, eivätkä ne tule häviämään minkään hypetermin mukana tai uuden saapuessa.
Blogisarjan seuraavassa osassa avataan DataOpsin muita alueita ja esitellään siitä koituvia hyötyjä.
Data-arkkitehti, joka auttaa asiakasta ymmärtämään tekniikan mahdollisuudet ja muuntaa innovatiiviset ideat teknisiksi ratkaisuiksi. Ketterät kehitysmenetelmät ja kehitystyötä tukevat prosessit ovat lähellä Markon sydäntä.