DevOpsista DataOpsiin

DataOps ottaa kantaa, DevOpsilta lainattujen asioiden lisäksi, myös projektinhallintamalliin, sekä esittää uuden tavan nähdä tietojärjestelmät tuotantolinjaston kaltaisena perinteisen ohjelmistotuoteajattelun sijaan. Vaikka DevOpsin opit ovat itsessään tärkeitä, ei se ole silti saanut samaa pitoa datapuolella, kuin ohjelmistokehityksessä. Syynä tähän nähdäkseni on se, että dataprojektit eivät noudata täsmälleen samoja lainalaisuuksia kuin perinteinen ohjelmistokehitys. Näin ollen DevOpsin opit eivät suoraan sellaisinaan täysin sovellu niihin.

Toimintavarmaan ja tehokkaaseen toimitusprosessiin ei ole mahdollisuutta, jos epäonnistutaan huomioimaan ja reagoimaan datakehittämisen erityispiirteet. Blogisarjan tässä osassa avataan tarkemmin näitä erityispiirteitä, sekä DataOpsin ehdottamia ratkaisumalleja niihin.

Ketterän kehittämisen käyttö vaatii panostusta kaikilta osapuolilta

Myönnän sen suoraan: DataOps kerää yhteen asioita, joista suurin osa on lähellä omaa sydäntäni, ovat olleet lähes koko urani ajan. Yhtenä näistä ovat ketterät kehitysmenetelmät.

DataOps:in yhteydessä tuodaan usein esiin sprintit. Näin ollen voi sanoa, että Scrum-menetelmää voidaan DataOps:in mukaan soveltaa datakehittämiseen – myös oman kokemukseni mukaan näin todellakin on; olen vetänyt ja ollut mukana ketterän kehityksen dataprojekteissa yli 8 vuotta. Alusta asti oli helppo ymmärtää kehitysmetodologian hyödyt projekteissa: laatu parani, virheet vähenivät, toimitusnopeus kasvoi. Nämä siis jo ilman, että käytössä oli erillisiä automaatiotyökaluja tai pilviympäristön tarjoamia moderneja mahdollisuuksia. Kun ketterästi hallittuun projektiin lisäsi generointityövälineet niin päästiin jo järjestelmiin, joiden virheet laskettiin vuodessa yhden käden sormilla, ja joihin toimituksia tapahtui usein vähintään kerran viikossa.

Dataprojektit soveltuvat erittäin heikosti vesiputousmalliseen kehittämiseen. Ne kestävät usein vuosia, ja alussa on olemassa ainoastaan jonkinlainen karkea visio siitä, mitä halutaan saada aikaiseksi. Lisäksi työkalut ja mahdollisuudet ovat usein tilaajalle vieraita, eikä lopullista määrittelyä ole olemassa. Ketterä kehittäminen sopii tällaisiin lähtökohtiin huomattavasti paremmin.

https://docs.microsoft.com/en-us/azure/devops/learn/agile/what-is-agile

Ketterä (ja silloin myös tarkasti ohjattu) kehittäminen vaatii kuitenkin kohtuullisen suurta henkistä muutosta perinteisempiin menetelmiin tottuneille. Kehittäjien täytyy hylätä projektipäällikön antama suoja ja omistautua kehittämälleen järjestelmälle, ottaa vastuuta. Toisaalta myös tilaajan täytyy luopua kiinteiden budjettien tuomasta turvallisuuden tunteesta, jos sellaista koskaan nyt on ollutkaan, ja lähteä mukaan aktiivisesti ohjaamaan ja tukemaan kehitystä. Tulla osaksi tiimiä. Perinteisissä toimittaja/tilaaja ympäristössä tämä vaatii aina molemminpuolista kunnioitusta ja luottamusta. Kykyä hyväksyä virheet, oppia niistä sekä jatkaa eteenpäin entistä parempina kumppaneina.

Disclaimer: vaikka toteutusta tehtäisiin tarkastikin esimerkiksi Scrumin sääntöjä noudatellen, ei silti voida puhua ketterästä kehityksestä, jos sen pohjalta löytyvää Leanin ideologiaa ei ole sisäistetty ja seurata aktiivisesti. Tähän olen suurimman osan epäonnistuneista ”ketteristä” yrityksistä todennut kaatuvan.

Ketterän kehitysympäristön luominen ja luottamuksen muodostaminen voi hyvin olla DataOpsin vaikeimmin omaksuttavissa oleva kokonaisuus. Vaikka et olisi omaksumassa mitään muuta DataOpsista, niin mielestäni tämä on osa, johon panostamisesta hyödyt eniten. Oikein tehtynä se johdattaa sinut ennen pitkää omaksumaan kaikki muutkin DataOpsin osa-alueet.

Datajärjestelmän ajatteleminen tuotantolinjana

Viimeinen tai loput, riippuen keneltä kysyy, osat DataOpsista liittyvät siihen, miten tietojärjestelmät pitäisi nähdä. Olemme ehkä tottuneet näkemään tietoaltaat, -varastot ja -järvet sekä muut vastaavat samaan termistöön kuuluvat järjestelmät perinteisien IT-järjestelmien kaltaisina toteutuksina. Sellaisia jotka koostuvat erilaisista toiminnoista ja rajapinnoista.

DataOps pyrkii muuttamaan tätä käsitystä siten, että datakehityksen lopputulos nähtäisiin enemmän tehtaana, jossa on toisistaan riippuvia ja riippumattomia tuotantolinjoja. Verrattuna vallitsevaan IT-järjestelmäkeskeiseen ajatteluun, on siinä selvä ero, miten tuotantolinjaston tyyppisiä järjestelmiä tulisi kehittää, päivittää, ylläpitää ja monitoroida. Tämän ajatuksen avaaminen kokonaisuudessaan vaatisi kokonaisen blogisarjan, joten kovin syvälle siinä ei muutamalla sanalla pääse.

Testaus ja monitorointi ovat tärkeitä ja konkreettisia asioita, joista voidaan aloittaa. Raaka-aine (lähdeaineisto) voi olla laadultaan hyvinkin vaihtelevaa, ja vaihtelevuus voi alkaa hyvinkin yllättäen, monesti vasta kuukausien tai vuosien päästä siitä, kun se on otettu ensimmäisen kerran käyttöön. Tällöin tulee testauksen kohdistua ennemminkin tulosten ja välitulosten laadun tarkkailuun kuin tarkasti määriteltyjen testitapausten ajamiseen.

Käytännössä tämä tarkoittaa muutosten ja tilastollisten laskentojen tulosten vertailua ajan funktiona. Myös ajoaikojen monitorointi, suorituksien lisäksi, on tärkeää. Nopeasti latenssia kasvattaviin tai ajan suhteen eksponentiaalisesti hidastuviin prosesseihin tulisi tehdä korjaukset välittömästi ennen kuin ne muodostuvat ongelmiksi tuotantokäytölle.

Hyödyt DataOpsista

DataOps koostuu siis pääpiirteittäin kolmesta kokonaisuudesta: DevOpsin mukaisesta tavasta nopeuttaa toimitussyklejä, ketterien menetelmien käytöstä sekä prosessituotannon mukaisesta kehitys ja hallintamallista. Näiden yhdistelmällä saatavat hyödyt ovat:

• Tiedon laadun parantaminen lisäämällä automaattinen testaus osaksi kehitysprosessia. Tämä estää tehokkaammin virheellisen datan huomaamisen jo kehitysvaiheessa ja päätymisen tuotantoon.
• Virheiden vähentäminen käyttämällä automatisoitua laadun monitorointia osana sekä kehitys-, testi- että tuotantoprosessia, mikä mahdollistaa myös turvallisen automatisoidun toimitusprosessin.
• Toimitusnopeuden parantaminen, automatisoimalla toimitus, mahdollistaa huomattavasti nopeammat toimitussyklit.
• Kehitystyön vähentäminen luomalla uudelleen käytettäviä ominaisuuksia ja komponentteja. Kehitykseen vapautuva aika mahdollistaa liiketoiminnallisen hyödyn tuottavien ominaisuuksien rohkeamman kehittämisen.
• Kehitystiimin vapauttaminen innovointiin, sen sijaan, että sen täytyisi käyttää aikaansa järjestelmän virheiden havainnointiin, selvittelyyn ja paikkaamiseen.

Tulemme myös julkaisemaan useita aiheeseen liittyviä kirjoituksia tulevaisuudessa, jotka sukeltavat syvemmälle DataOpsin mukaisesta kehityksestä saataviin hyötyihin sekä siihen, miten Azure-platformin päällä voidaan toteuttaa DataOpsia tukevia toimintoja.