Data Governance ja Data Management – tiedon hallintamallien juurilla

Monilla aloilla, meidän data-alamme mukaan lukien, uusia ideoita, malleja ja ratkaisuja syntyy huimaa tahtia. On motivoivaa toimia alalla, joka kehittyy jatkuvasti ja tarjoaa uusia mahdollisuuksia ja haasteita. Uusien mallien seassa navigoidessa on välillä hyvä pysähtyä palauttamaan mieleen myös perusasioita ja syitä käytettyihin ratkaisuihin. Menneisiin malleihin ei pidä jäädä jumiin, mutta on aivan yhtä tärkeätä muistaa mitä ongelmia pyrittiin ratkaisemaan ja mistä nämä haasteet syntyivät. Teknologian kehittyessä, täytyy välillä myös arvioida mitkä ongelmista perustuivat teknologisiin rajoitteisiin, ja ovatko ne edelleen olemassa.

Pöhinää ja paineita skaalaamiseen

Omassa kuplassani oli viime vuoden aikana kovasti pöhinää erilaisista hallintamalleista data kehitykseen. Keskustelua syntyi yritysten ja organisaatioiden hakiessa yhä aktiivisemmin monitiimikehitykseen soveltuvia toimintatapoja. Suomen verrattain pienissä piireissä on pitkään pärjätty hyvin pienehköillä, muutaman henkilön, datatiimeillä. Tietomäärien ja tarpeiden kasvaessa paine on kuitenkin kasvanut datakehityksen skaalaamiseen entistä voimakkaammin. Tavat kehityksen skaalaamiseen ovat saattaneet tapahtua vähemmän järjestelmällisesti ja monesti orgaanisesti. Eli siis tavalla missä suunnitellun ja ohjatun laajentumisen sijaan on päädytty hankkimaan yksittäisiä liiketoimintatarvepohjaisia toteutuksia. Yksittäiseen liiketoimintatarpeeseen tyypillisenä esimerkkinä ovat ML ja AI projektit, joiden päätyminen tuotantokäyttöön suunnitellusti on ollut ongelmallista. Tahot, kuten Gartner ja TechRepublic, ovat arvioineet kehittyneen analytiikan projektien epäonnistumisasteen jopa niinkin korkeaksi kuin 85%. Muitakin arvioita on, mutta ne kaikki jakavat yhden asian, huomiota herättävän matalan todennäköisyyden onnistumiselle.

AI projektien arvioidut epäonnistumisasteet

Ron Schmelzer - Forbes

Arijit Sengupta - Fortune

Selkeät syyt epäonnistumisten takana

Erilaisten dataprojektien epäonnistumiselle on monia syitä, niin teknisiä, osaamispohjaisia kuin hallinnollisiakin. Data ympäristöjä pitkään kehittäneenä olen kuitenkin huomannut, että ilman yhtenäistä toteutus- ja hallintamallia toteutetut projektit päätyvät monesti ongelmiin siinä vaiheessa, kun ne pitäisi siirtää tuotantoon. Teen nyt niinkin rohkean väitteen, kuin että Data Governancen ja Data Managementin puute tai puutteellisuudet ovat yksi merkittävä syy siihen, että etenkin uudet data projektit epäonnistuvat. Ilman suunnitelmallisuutta, kaikki ne epäonnistumispisteet, joita keskitetyllä hallinnalla on pystytty ratkaisemaan, jäävät projektien yksittäisten henkilöiden hallittaviksi ja ratkaistaviksi. Peruutuspeilistä tarkasteltuna (viisasteltuna) tämä luo valtavat ja usein epärealistiset vaatimukset projektitiimien osaamiselle. Esimerkiksi analyyttisiä ja tilastollisia haasteita ratkaisevan huipputiimin tulisi samaan aikaan ymmärtää, oman erityisosaamisalueensa lisäksi, kattavasti myös kaikki tiedonhallintaan ja tuotannollistamiseen liittyvät haasteet ja käytännöt. 

Motivaationa kokonaisuuden hahmottaminen

Kehityksen skaalaaminen, ja siinä joskus jopa systemaattisesti esiintyvät haasteet, saivat minut motivoitumaan kirjoittamaan niinkin perinteisestä aiheesta kuin Data Governance ja Management. Ajatuksieni tueksi piirtelin mallia kokonaisuuden hahmottamiseksi, jonka tässä esittelen. Malli ei ole täydellinen, kattava tai edes kovin konkreettinen. Lisäksi halusin lähestyä asiaa pelkästään data-alustojen kehityksen näkökulmasta. Tiedonhallinnan asioita voi, ja pitäisikin, käydä läpi laajemmassa koko organisaation perspektiivissä, missä mukaan luetaan esimerkiksi myös operatiiviset lähdejärjestelmät, digitaaliset tuotteet ja muut vastaavat komponentit, jotka saattavat jäädä esittämäni rajauksen ulkopuolelle. Uskon että yhtymäkohtia on kuitenkin riittämiin, jotta data-alustan tuottamasta näkökulmasta riittää ajateltavaa myös laajemminkin.

Governance vai Management - johto vai hallinta

Tätä blogia kirjoittaessani ja tutkiessani Data Governance:en sekä Data Management:iin liittyvää materiaalia ja tarjontaa havaitsin pari asiaa. Ensinnäkin termit kääntyvät mielestäni erittäin huonosti suomeksi, mikä vaikeuttaa yhtenäisen termistön muodostumista. Toiseksi termit sekoittuvat monesti, myös englanninkielisessä materiaalissa, eikä tarkkaa rajanvetoa standardin omaisesti näytä olevan olemassa. 

Jotta päästäisiin yhtenäisen termistön puuttumisesta johtuvan haasteen yli, tässä kontekstissa määrittelen termit seuraavasti: Data Governance on ylätaso, jonka alle Data Management kuuluu. Erittäin yksinkertaistettuna Data Governance luo säännöt ja Data Management huolehtii niiden laittamisesti käytäntöön. En pyri luomaan tässä uutta normia termeille, vaan ainoastaan tuomaan kontekstin mallille, jonka esittelen. Pyydänkin sinua lukijana ottamaan tämän ennemminkin ajatusleikkinä, kuin konkreettisena malliesimerkkinä.

Olen aihetta tutkiessani ja blogia kirjoittaessani piirtänyt ja täydentänyt kuviota ajatustyöni tueksi. Ja olemme käyneet kyseisen mallin osalta antoisaa keskustelua. Todettakoon, että kuvio ei varmastikaan tule täysin aukeamaan ilman selittämistä, jo pelkästään termien moniselitteisyyden vuoksi. Parhaimmillaankin kuvaa voi kai kutsua ajatuskartaksi. Tämä yritys jäsentää ajatuksiani koostuu, edellisessä kappaleessa kuvaamallani tavalla, sääntöjen ja tavoitteiden määrittelemisestä (värilliset kohdat), sekä varsinaisesta operatiivisen kehityksen hallintamallista (harmaat kohdat). Koitan seuraavaksi avata kaavion mukaisia pääkohtia.

Data Governance - säännöt ja sopimukset

Itse Data Governance, ennen kuin siirrytään varsinaiseen kehittämisen hallintaan, luo pohjan kehittämiselle. Jaoin tämän pohjan kolmeen osa-alueeseen: ohjaus, ihmiset ja rajoitteet.

• Näistä ensimmäisenä on ohjaus (direction), jonka tehtävä on määritellä mistä syystä data-alustaa ja toimintoja kehitetään. Miten toteutuksien tulisi tukea liiketoimintaa ja sen tavoitteita. Asettaa tavoitteet ja mitata niiden onnistumista.
• Toisena osa-alueena on ihmiset (people). Roolit ja vastuut, niihin liittyvä organisoituminen ja osaaminen. Eli määritellä kuka tekee mitäkin, sekä millaisia toimenpiteitä he voivat tehdä tai mistä asioista he voivat päättää, heille jaettujen vastuiden täyttämiseksi.
• Kolmantena kohtana on rajoitteet (restrictions). Tähän liittyy kehitykselle, toiminnoille ja tiedolle asetettavat, parempien termien puutteessa, säännöt ja sopimukset. Näillä määritellään asioita kuten miten tietoa tulee käsitellä, millaista tietoa kenellekin voidaan tarjota ja millaisia normeja lopputuloksien tulee täyttää. Nämä rajoitteet siis voivat olla periaatteessa mitä tahansa niin turvallisuuteen, eettisyyteen, laadullisuuteen, kuin säännöksiin ja lakeihin kohdistuvia.

Data Governance:n tavoitteena on ohjata, organisoida ja säännöllistää varsinaista datakehitystyötä.

Data Management – kehityksen ohjaus ja hallinta

Data Managementin tehtävä, Data Governancen alakohtana, on ohjata toteutuksen käytännön tekemistä. Olen jakanut sen kahteen pää osa-alueeseen. Teknologiaan ja kehitykseen.

• Teknologia (technology) ottaa kantaa siihen millaisia järjestelmiä, alustoja tai kyvykkyyksiä rakennetaan, otetaan käyttöön ja hallitaan. Millaista arkkitehtuuri ja turvallisuus ratkaisuja näiden tulee noudattaa, niin kokonais-, kuin järjestelmäkohtaisen arkkitehtuurin tasollakin. Haluttaessa, hallinta voi ulottua aina preferoitujen toteutuspatternien, kuten määriteltyjen integraatioväylien tai frameworkien käyttöön.
• Kehityksen (development) hallinta vastaa siitä, että sovitut toimintamallit ja säännöt toteutuvat käytännössä. Tähän liittyy itse kehityksen organisoiminen määritellyllä tavalla, mutta myös suunnitelmien ja toteutuksien vaatimustenmukaisuuden validointi.

Teknologia ja kehityksen hallinta kohtaavat mikrotasolla, kun määritellään, miten tietoa integroidaan, tallennetaan, käsitellään ja tarjoillaan. Erilaisista Data Governancen asettamista vaatimuksista muodostuu nopeasti niitä toteuttavia ratkaisumalleja ja patterneja, joita kaikkien tietyn tyyppistä toteuttamista tulevien tulee noudattaa. Tästä esimerkkinä vaikkapa se, miten raakatieto tulee tallentaa tiettyyn kansiorakenteeseen tietoaltaaseen.

Käytännön tason vaatimuksista ja teknisistä rajoitteista syntyy myös tarve siitä, että Data Governance:n kehityksessä tulisi olla mukana henkilöitä, jotka ymmärtävän Data management:issa ja toteutuksessa käytettyjä malleja. Parhaimmillaan Data Governance tukee kehitystyötä poistamalla haasteita, yksinkertaistamalla ja virtaviivaistamalla vaatimuksia, sekä tarjoamalla selkeän motivoivan päämäärän. Pahimmillaan se taas luo turhan byrokratian kerroksen ja aiheuttaen jatkuvia esteitä kehitykselle.

Toteutukseen keskittyvien prosessien ulkopuolelle

Edellisestä kuvauksesta saattaa jäädä sellainen käsitys, että Data Governance on vain staattinen kokoelma määrittelyitä, käytäntöjä ja dokumentteja. Näin ei kuitenkaan pitäisi missään tapauksessa olla, vaan Data Governance:n tulisi olla myös itsessään aktiivinen ja kehittyvä prosessi. Sen tulisi varsinaisten tehtäviensä lisäksi, myös iteroida sen omia vastuita, käytäntöjä, prosesseja ja päämääriään. Jatkuvasti muovautuvassa ympäristössä, myös hallintamallien tulee kehittyä jatkuvasti.

En usko, että mikään teknologia eliminoi tarpeelliseksi koettuja hallinnallisia tarpeita. Aina välillä käy kuitenkin niin, että tiettyjä vaatimuksia täyttävät ominaisuudet muodostuvat osaksi teknisen alustan perustoiminnallisuuksia. Kun ominaisuus tulee kiinteästi osana teknistä toteutusta.

Esimerkiksi jos otetaan käyttöön API:en hallintatyökalu, niin API:a ei voi julkaista (prosessia noudattaen) enää kenelläkään, määrittelemättä sen käyttöoikeuksia. Tällöin painotus käyttöoikeusien käytön pakottamisesta ei poistu, mutta se tulee osaksi teknistä toteutusmallia. Näin teknisesti ”pakotettu/tarjottu” ominaisuus ei vaadi enää vastaavaa huomiota samalla tavalla kuin aikaisemmin. Tällöin voidaan hallintaa kohdentaa vastaavasti siihen, että käyttöoikeudet esimerkiksi seuraavat paremmin yleistä mallia, kuin että ne ovat ylipäätään mukana.

Teknisten valmiuksien standardoituminen ja standardoiminen siis vähentää tarvetta mikrotason hallintaan. Tässä olisi selkeä aasin silta monimutkaisten säännöstöjen seuraamisen ongelmiin, mutta jätän sen matopurkin aukaisematta. Todettakoon sen sijaan että: Teknisen maturiteetin kasvaessa, myös vaatimusten maturiteetti kasvaa.

Merkitys kehitykselle

Monesti data-alustoja kehitettäessä on vaikeaa saada kiinni siitä, miten yksittäiset toteutukset palvelevat liiketoiminnan päämääriä. Tällöin on myös haastavaa arvioida, kuinka hyvin toteutus tukee tätä piilossa olevaa tarvetta. Data Governance:n tarkoituksena on tarjota kehitykselle selkeämpi suunta ja tavoitteet. Vastaavasti välillä, varsinkin laajemmalla tekijäjoukolla toteutettavissa kokonaisuuksissa, on ongelmana kehitysmallien ja -tapojen hajanaisuus. Data Management pystyy tarjoamaan yhtenäiset käytännöt ja rakenteet, joilla myös kehitystä voidaan yhtenäistää. Suunnan ja sääntöjen yhdistelmästä on mahdollista syntyä prosessi, jolla varmistetaan, että toteutetaan liiketoimintaa parhaiten palvelevia kyvykkyyksiä sellaisella teknisellä tavalla, että ne saadaan vietyä tuotantoon ja ovat ylläpidettävissä ja jatkokehitettävissä. Vieläpä sellaisella tasolla, että ne varmistavat alustakehityksen vaatiman pitkäikäisyyden.

Jos ei ole yhteisiä sopimuksia, jotka takaavat yhteisen linjan, ei sellaista linjaa voi taianomaisesti olettaa syntyvän. Mutta myöskään sopimuksilla, joita kukaan ei noudata, ei ole yksinään mitään arvoa. Data Governance:n vastuulla on määritellä nämä sopimukset datakehityksen linjan varmistamiseksi. Lisäksi se tarvitsee Data Managementia varmistamaan sopimuksien käytäntöön panemisessa ja noudattamisessa. Vastaavasti Data Management, ilman näitä liiketoiminnan vaateista syntyneitä rajoja, jää väkisinkin tyngäksi, tekniseksi prosessiksi, joka ehkä tarjoaa yhtenäisiä käytäntöjä, muttei palvele suoraan liiketoiminnallisia päämääriä.

Molemmat puolet, hallinta ja käytäntö, tarvitaan, jotta kummastakaan saataisiin täyttä hyötyä. Luulen, että tämä onkin yksi syy siihen, miksi Data Governance ja Data Management termit sekoittuvat niin voimakkaasti toisiinsa. Termien symbioottinen suhde huomioiden väitän, että Data Governace:a ja Data Management:ia tulisi aina kehittää lähekkäin ja rinnakkain. Molempien osien kehityksessä tulisi hyväksyä ja omaksua tarve mallien jatkuvasta kehityksestä ja muovautumisesta. Samalla mallien laajentuessa pitäisi myös pyrkiä yksinkertaistamaan ja suoraviivaistamaan niiden asettamia sääntöjä ja rajoituksia. Malleista ei saisi koskaan muodostua sellaisia, että niiden omaksumiseen ja noudattamiseen kuluu enemmän vaivaa, kuin niistä saadaan hyötyä.

Tarpeellinen ajatusleikki

Hallinta ja kehitysmallit vaihtelevat organisaatiosta toiseen, välillä jopa organisaatioiden sisällä. Olen nähnyt monia malleja, jotka eroavat suurestikin esittelemästäni versiosta ja silti toimivat niille ominaisessa ympäristössä. Ainoa yhtenäinen asia, jonka pystyn löytämään erilaisten tapojen väliltä, on hallintamallien tärkeys. On kyseessä sitten keskitetty tai hajautettu malli, on malli liiketoiminta- tai liikejohtovetoinen, itseohjautuva vai hierarkkisesti hallittu, kaikki ymmärtävät yhteisten sopimusten ja sääntöjen tärkeyden. Tästä syystä, on valittu hallintamalli organisaatiolle mikä hyvänsä, kannattaa mielestäni aina välillä palata juurille ja arvioida mallia tiedonhallinnan alkuperäisistä lähtökohdista. On hyödyllinen harjoitus miettiä, huomioiko ja täyttääkö malli kaikki tarpeelliset tehtävät sellaisina, joihin voi olla tyytyväinen, vai tulisiko joitakin osa-alueita selkiyttää, tehostaa tai kehittää.

Toivon, että nämä ajatukset kannustavat ainakin jollain tavalla pohtimaan hallintamallien soveltuvuutta ja tehokkuutta. Suosittelen myös lämpimästi tekemään pohtimista muiden ihmisten kanssa, sparrailemaan ajatuksia, kartoittamaan nykymallin haasteita tai puutteita. Ja mikäli lähipiiristä ei löydy valmiiksi sopivia tahoja, tai kaipaa lisäksi ulkopuolista perspektiiviä, niin autamme tässäkin asiassa mielellämme.