Hei,
Mikäli yritys tai organisaatio haluaa panostaa tietojohtamiseen ja datakeskeiseen kulttuuriin, on informaatioarkkitehtuurin oltava kunnossa.
Siitä voisi myös käyttää nimeä data-arkkitehtuuri, mutta informaatioarkkitehtuuri ehkä kuvaa paremmin sen tavoitetta: miten datasta syntyy tietoa, joka johtaa toimintaan.
Informaatioarkkitehtuuri on usein vaikea aihe, koska sitä tehdää liian järjestelmälähtöisesti.
Dataprojektit ovat irrallaan liiketoiminnasta
Kaikki tiedot ovat IT-järjestelmissä ja usein datanhallinta saattaa olla pahimmillaan niiden tietorakenteiden loputonta kuvaamista.
Ongelmaksi muodostuu usein se, että tämä tekeminen loittonee liiketoiminnasta. Kuitenkin datan hyödyntämisen pitäisi olla siihen sidottu.
Ja jos dataprojektit ovat irrallaan liiketoiminnasta, dataa ei kunnolla ymmärretä ja sen hyödyntäminen on lähes mahdotonta.
Juttelin kerraa hyvin osaavan AWS-asiantuntijan kanssa. Hänellä oli erittäin laaja osaaminen dataputkien rakentamisesta ja uusimmista teknologioista.
Kun yritin kysyä ymmärtääkö hän mitä dataa hän käsitteleen, niin kysymys yllätti hänet: se ei kuulu hänen työtehtäviinsä.
Sitten kuulen saman firman johtoa lähellä lähellä olevilta analyytikolta, että data-arkkitehtuuri tekeminen ei oikeastaan tuota lisäarvoa liiketoiminnalle: he tietävät että jotain siellä tehdään mutta ei mitä.
Tähän on olemassa modernimpi tapa, eli liiketoimintalähtöinen informaatioarkkitehtuuri.
Liiketoimintalähtöinen informaatioarkkitehtuuri
Ohjelmistokehitys on vuosikymmenessä kehittynyt täysin uudelle tasolle. Se on ketterää ja tehdään sprinteissä.
“Vesiputousmalli” on mennyttä aikaa, koska se ei pysy liiketoiminnan muutosten tahdissa.
Myös esimerkiksi tietovarastojen- ja alustojen kehittäminen tehdään nykyisin samoin, eli pala kerrallaan.
Olisiko aika kehittää data-arkkitehtuuria myös vastaamaan nykyajan nopeatempoista maailmaa?
Liiketoimintalähtoinen kehitys liittyy datarankenteiden ymmärtämiseen liiketoiminnan kannalta.
Toki järjestelmien sisältämää dataa tulee käsitellä ja tietää miten se siellä makaa – niiden ymmärtäminen edellyttää kartan laatimista IT-viidakossa navigointiin.
Käsitellään seuraavaksi liiketoimintalähtöisen arkkitehtuurin luomista. Se perustuu käsitemallinnuksen (conceptual data modeling, business driven data modeling) viemiseen ikään kuin uudelle tasolle.
Enterprise-mallit
Yritykset ja organisaatiot yleensä tuottavat palveluja ja tuotteita. Niitä sitten toimitetaan asiakkaille tavalla tai toisella.
Ympärillä on tukifunktioita, kuten HR, talous, logistiikka tai hankinta.
Enterprise-malli on koko konsernin ylätason kuvaus. Hyvä vertauskuva on Google Maps. Siinä voi zoomata sisään ja ulos, jolloin kartan tarkkuustaso vaihtelee.
Kun zoomaat ylös, näet vain kaupunginosat ja isompien teiden nimet. Jonkin alueen kokonaisuus on kuitenkin helpompi ymmärtää, kun sieltä on poistettu yksityiskohdat, kuten pikkuteiden nimet.
Enterprise-malli nivoo yrityksen toiminnot yhteen ja siinä käytetyt käsitteet ovat sellaisia kun tuote, asiakas, kustannuspaikka ja työntekijä.
Näistä muodostuva data kiinnostaa yli yksikkörajojen.
Domain-mallit
Yritykset määrittyvät usein sen prosessien mukaan. Sillä on esim tuotanto-, myynti ja HR-prosesseja.
Nämä prosessit tuottavat valtavan määrän dataa. Ja juuri tämän datan haluamme ymmärtää ja kuvata.
Doman-malli jälleen tarkentaa karttaa, eli määrityksiä on enemmän ja ne ovat yksityiskohtaisempia. Esimerkiksi HR-mallissa on kuvattu keskeinen käsitteistö liittyen rekrytointiin, palkanmaksuun, henkilöstön kehitykseen ja resursointiin.
Ne ovat tietyn alueen vetäjälle, kuten HR-johtajalla erittäin kiinnostavia asioita, mutta eivät koske kokonaisuudessaan muita yksiköitä.
Nillä on tietysti yhtymäpinnat muihin alueisiin ja usein mielenkiintoisimmat datan hyödyntämisen kohdat voivat löytyä juuri näistä liitospisteistä.
Käyttötapausmallit
Jälleen menemme syvemmälle, kun mallinnamme käyttötapauksia.
Ne ovat hyvin spesifejä liiketoimintaongelmia. Kuten vaikkapa tietyn tuotteen kate tietyssä lokaatiossa tai rekrytointiprosessin keskipituus.
Nämä ovat sellaisia tapauksia, jotka kiinnostavat erityisesti yksittäisiä tiimejä ja esimiehiä. Esimerkiksi rekrytointi on HR-johtajan yksi alue muiden joukossa ja siitä vastaa omat erityisasiantuntijat.
Käyttötapausmallista voidaan suoraan johtaa esimerkiksi tietovaraston ensimmäinen toteutus ja BI-dashboardit.
Se voi olla myös data-analyytikon toimeksianto, esimerkiksi että kuinka moni tuotetta x ostava asiakas ostaa myös tuotetta y.
Kaikki tekoälyyn liittyvät harjoitukset ovat myös tällaisia, eli miten jokin spesifi liiketoimintaongelma ratkaistaan datan ja algoritmien avulla.
Informaatioarkkitehtuurin toteuttaminen
Moni on ehkä huomannut, että liiketoiminnan edustajia on vaikea saada mukaan arkkitehtuurityöhön.
Tämä johtuu siitä, ettei sen koeta hyödyttävän liiketoimintaa, ainakaan kovin nopeasti.
Tietyn käyttötapauksen mallinnus puolestaan hyödyttää liiketoimintaa, koska he voivat sen avulla kehittää toimintaa.
Ellie-mallinnustyökalu mahdollistaa sen, että kaikkia näitä mallinnuksen tasoja voidaan tehdä siten, että kaikki mallit ovat tallessa ja ajan tasalla.
Mallinnus kannattaa tehdä käyttötapausmallit kerrallaan, palastellen. Tämä on juuri sitä ketterää kehitystä.
Ellie kokoaa nämä käyttötapausmallit yhteen ja niistä voidaan luoda domain-mallit, edelleen pala kerrallaan.
Kun tosiaan teemme useita käyttötapausmalleja eri liiketoimintaedustajien kanssa, informaatioarkkitehtuuri alkaa syntymään ikään kuin automaattisesti – Ellien toiminnallisuudet pitävät tästä huolen.
Lopulta myös enterprise-malli rakentuu iteratiivisesti tätä menettelyä toistamalla. Osaavat informaatioarkkitehdit sitten varmistavat Ellietä hyödyntäen, että kaikki on linjassa ja domain-mallit ovat eheät.
Nopeus on kriittistä
Joku voi argumentoida, että ei tuo ole oikea tapa, koska se ei kuvaa täydellisesti tietojärjestelmien tietorakenteita. Toinen voi sanoa, että tässä yksinkertaistetaan vaikeaa asiaa.
Juuri siitä on kyse, yksinkertaistamisesta. Koko järjestelmäkohtainen arkkitehtuurityö on niin tuskastuttavan hidasta, ettei se palvele liiketoimintaa juurikaan.
Minusta on parempi tehdä hieman “epätäydellisempää” mallia sekä tinkiä sen ”akateemisuudesta”, jos se on kuitenkin nopeaa, käytännön läheistä ja relevanttia liiketoiminnalle.
Minusta moni asia itse asia on juuri tällaista työelämässä: ei kannata pyrkiä liialliseen täydellisyyteen ja perfektionismiin, koska se ei tuota tietyn pisteen jälkeen enää lisäarvoa.
Tilanne on se, että monia asioita pitää saada aikaiseksi nopeasti täydellisen kustannuksella.
Onko nimittäin hyötyä sellaista arkkitehtuurityöstä, joka näkee päivän valon vasta viiden vuoden päästä, mutta siinä on varmasti kuvattu akateemisella pieteetillä (ja kaikki maailman viitekehykset huomioiden) jokainen datanmurunen ja tietovirta sataprosenttisesti?
Eipä taida olla.
Ellie on kehitetty sitä varten, että saadaan vauhdilla mallit aikaiseksi ja voidana kääriä datatemisessä hihat heti, eikä vasta ensi vuonna.
Mikäli kiinnostaa kuulla lisää, niin vielä ehdit ilmoittautua Ellien ilmaiseen webinaariin torstaina 22.10.2020 klo 17:00 – 17:45. Informaatioarkkitehtien kanssa paljon työskentelevä Alec Sharp toimii keynote puhujana, eli hieno juttu tulossa!
Ystävällisin terveisin,
Johannes Hovi
Ps. 2020 viimeinen Data Vault-sertiifointikoulutus alkaa kohta olla täynnä, mutta vielä nopeat ehtivät varata paikkansa.
Data Vault 2.0 Bootcamp + Certification
Kolme päivää tiukkaa asiaa ja mahdollisuus suorittaa arvostettu, menetelmän kehittäjän Dan Linstedtin auktorisoima sertifointikoe. Varmista, että tietovarasto-osaaminen on kunnossa ja hanki sertit koko tiimille – Syksyn koulutukset ovat pian täynnä, kannattaa varata paikat nyt nopeasti!
Lisätiedot ja ilmoittautuminen tästä
