Datastrategian tukipilarit: Arkkitehtuuri ja teknologiavalinnat

Kaiku Kettunen

Datastrategian ja tiedolla johtamisen yhtenä peruspilarina toimii data-arkkitehtuuri. Arkkitehtuuri kattaa kaikki järjestelmät, työkalut ja teknologiavalinnat, jotka mahdollistavat yrityksen datan muuttamisen päätöksentekoa tukevaksi tiedoksi. Monet mieltävät teknisen kehitystyön ja eri teknologioiden rakentamisen yhdeksi keskeisemmäksi osaksi tiedolla johtamista. Vaikka tiedolla johtaminen ja datastrategia käsittävät myös vähemmän teknisiä osa-alueita, tekniset järjestelmät ovat kiistatta yksi tärkeimmistä palasista tässä kokonaisuudessa. Tässä blogikirjoituksessa käymme läpi data-arkkitehtuurin osuuden datastrategiassa nykytilan kartoituksesta tavoitetilan määritykseen.

Nykyisen arkkitehtuurin selkeyttäminen

Arkkitehtuurikartoituksen palaset

Arkkitehtuurikartoitus koostuu useista osista, joiden läpikäynnillä pyritään muodostamaan kokonaiskuva nykytilasta:

Työkalut ja teknologiat kertovat, millä välineillä toteutukset tehdään ja minkä teknologioiden päälle ratkaisut rakennetaan. Esimerkiksi pilvialustan valinta Azuren, AWS:n ja GCP:n välillä tai tietokantamuodon valinta ovat tästä hyviä esimerkkejä.

Ylätason järjestelmäarkkitehtuuri ja liitännät ulkoisiin järjestelmiin kuvaavat käytössä olevat järjestelmät ja läpikäyvät niiden väliset integraatiot ja yhteydet. Tässä vaiheessa usein laaditaan arkkitehtuurikuvaus nykytilasta, mukaan lukien liitännät eri järjestelmien välillä.

Tietovirtakaavio ja -prosessit kuvaavat, miten tieto virtaa järjestelmien välillä, ja auttavat ymmärtämään nykyiset tiedonkäsittelyprosessit.

Elinkaari kertoo, missä vaiheessa nykyiset järjestelmät ovat ja kuinka pitkään niitä voidaan hyödyntää. Tähän liittyy vahvasti eri järjestelmien kehittäjien tarjoama tekninen tuki ja kuinka pitkään sen voidaan odottaa jatkuvan. Usein vähintään versiopäivitykset ovat pakollisia, mutta joskus kokonaiset järjestelmät voivat elinkaarensa loputtua muuttua lähes käyttökelvottomiksi. Toisaalta elinkaariajatteluun liittyvät myös lisensointi ja sopimusuudistukset, sekä infrastruktuurin osalta laitteiston ikä, takuuasiat ja ylläpito.

Tietolähteet kertovat, missä järjestelmien käyttämä tieto sijaitsee ja mihin muotoon se on tallennettu. Ymmärtämällä tietolähteitä voidaan parantaa järjestelmien suorituskykyä ja tehokkuutta, mikä takaa optimaalisen käyttökokemuksen.

Keskeiset lähdejärjestelmät kuvaavat, mistä käytettävä tieto on alun perin peräisin. Ymmärtämällä, kuinka usein tieto päivittyy, mikä sen laatu on ja miten tietoa syntyy, voidaan valita oikeat työkalut ja teknologiat, jotka tukevat sen hyödyntämistä. Esimerkkinä tästä on reaaliaikainen striimidata ja batch-data, jotka vaativat erilaisia ominaisuuksia data-arkkitehtuurilta.

Dokumentaatio ja hiljainen tieto

Kun nykytilan arkkitehtuuria aletaan kartoittaa, ovat dokumentaatio ja asiantuntijahaastattelut keskeisessä roolissa. Dokumentaation avulla pyritään luomaan selkeä kuvaus järjestelmistä ja työkaluista, niiden toiminnallisuuksista sekä arvioimaan dokumentaation määrän ja laadun perusteella nykyisen arkkitehtuurin ymmärtämisen haastavuutta. Mikäli järjestelmät ja työkalut ovat dokumentoitu puutteellisesti, dokumentaation laatu on heikkoa tai se on kokonaan laiminlyöty, voi nykyisen arkkitehtuurin toiminnallisuuden ymmärtäminen olla erittäin vaikeaa. Näin ollen dokumentaation voidaan ajatella olevan pitää eksplisiittistä tietoa, joka helpottaa järjestelmien toiminnan selkeää ilmaisemista ja käsitteellistämistä.

Haastattelut muodostavat toisen tärkeän osan nykytilan selvittämisessä. Niiden kautta pyritään tuomaan esiin yrityksen hiljaista tietoa. Hiljainen tieto kattaa kaiken sen piilevän tiedon ja osaamisen, jota ei ole dokumentoitu tehden sen löytämisestä vaikeaa. Esimerkiksi tämä käsittää kaiken osaamisen ja ymmärryksen data-arkkitehtuurista, joka sijaitsee pelkästään yrityksen työntekijöiden mielissä. Tämän tiedon ymmärtämisen merkitys korostuu organisaatioissa, joissa dokumentaatio on puutteellista. Vaikka järjestelmät olisivatkin dokumentoitu yksityiskohtaisesti, käyttäjien haastattelut tarjoavat mahdollisuuden varmistaa dokumentaation oikeellisuus ja ajantasaisuus. Hiljainen tieto on luonnollinen osa organisaatiota, koska kaikkea ei voida dokumentoida. Ongelmaksi se muodostuu tilanteissa, joissa järjestelmien kuvaaminen laiminlyödään, ja hiljainen tieto katoaa yrityksestä esimerkiksi henkilöiden siirtyessä muihin tehtäviin.

Sekä eksplisiittistä että hiljaista tietoa hyödyntämällä pyritään muodostamaan mahdollisimman laaja kokonaiskuva data-arkkitehtuurista ja käytettävistä järjestelmistä. Parhaiten tämä onnistuu, mikäli organisaatio on alusta asti varmistanut järjestelmien kehityksen dokumentoinnin. Jälkikäteen tehtävä dokumentaatio on usein massiivinen kokonaisuus, jolla harvoin on edellytykset onnistua.

Kohti arkkitehtuurin tavoitetilaa

Kun nykytila ymmärretään, voidaan siirtyä pohtimaan arkkitehtuurin tulevaisuudenkuvaa. Tässä vahvana tukena toimii datastrategian yleinen tavoitetila, josta olemme aikaisemmin kirjoittaneet oman bloginsa. Kyseisen tekstin löydät täältä.

Data-arkkitehtuuriin tavoitetilan määritykseen vaikuttavat vahvasti arkkitehtuurin palaset, jotka käsittelimme nykytilan määrityksen yhteydessä. On tärkeää, että yritys miettii huolella järjestelmiään, tietolähteitään sekä integraatioita, kun tavoitetilaa lähdetään määrittämään. Liiketoiminnan tukeminen ja tiedolla johtamisen parantaminen on myös syytä pitää kirkkaana mielessä. Nämä asettavat raamit uuden arkkitehtuurin rakentamiselle.

Tärkeimmät tavoitearkkitehtuurin määritykset koskevat teknologia- ja työkaluvalintoja, jotka tukevat sekä datastrategian kokonaistavoitteita että järjestelmien teknisiä vaatimuksia. Kun valinnat on tehty, voidaan tavoitearkkitehtuuri määrittää piirtämällä järjestelmät ja integraatiot sekä laatimalla toteutussuunnitelma tavoitetilan rakentamista varten.

Teknologiavalintoihin vaikuttavat sekä tekniset että organisaation vaatimukset

Teknologiavalinnoilla tarkoitetaan kaikkia toteutukseen käytettävien ratkaisujen ja työkalujen valintaa. Tähän voi sisältyä esimerkiksi päätökset käytettävästä pilvialustasta (kuten Azure, AWS tai GCP) tai avoimen lähdekoodin relaatiotietokannasta (MySQL, MariaDB tai PostgreSQL). Laajemmassa kontekstissa mukaan tulevat myös esimerkiksi valitut ohjelmointikielet.

Kun yritys aloittaa käytettävien teknologioiden kartoituksen, on hyvä pitää mielessä kolme asiaa:

1. Tarpeet

Järjestelmältä vaadittavat tekniset ja ei-toiminnalliset ominaisuudet on hyvä listata etukäteen ja vertailla eri vaihtoehtoja keskenään. Tämä on helppo tapa eliminoida vaihtoehdot, jotka eivät täytä yrityksen järjestelmille asetettuja minimivaatimuksia – toisin sanoen ne eivät ole käyttökelpoisia. Vaatimuksia voivat olla esimerkiksi tietty suorituskyky, muokattavuus, tarjottava tuki tai muut järjestelmälle kriittiset ominaisuudet. Yrityksen tarpeiden ja tuotteiden ominaisuuksien vertailu luo teknologiavalinnoille ne raamit, jotka määrittävät, mitkä vaihtoehdot ovat harkinnan arvoisia. Siksi ne kannattaa määritellä ja käydä läpi huolella, jotta toteuttamiskelvottomat vaihtoehdot voidaan heti alussa sulkea pois, säästäen siten yritykseltä aikaa. Ei ole epätavallista, että sataprosenttisesta julkipilvitransitiosta joudutaan poikkeustapauksissa hieman tinkimään välivaiheen kautta. Tässä vaiheessa rakennetaan hybridiarkkitehtuuriratkaisu, joka sisältää elementtejä sekä omasta ympäristöstä että julkipilvestä. Toisinaan voi myös ilmetä paineita siirtää joitakin elementtejä pois julkipilvestä takaisin on premise -ratkaisuun.

2. Kyvykkyydet

Yrityksen on myös hyvä miettiä etukäteen, mitä kyvykkyyksiä uuden järjestelmän käyttöönotto ja ylläpito vaativat. Tätä on hyvä peilata yrityksen nykyiseen arkkitehtuuriin ja pohtia, kuinka paljon nykyistä henkilöstöä on koulutettava uudelleen tai kuinka paljon uutta henkilöstöä on palkattava uusien järjestelmien käyttöä varten. Esimerkiksi tilanne, jossa yrityksellä ei ole AWS-kohtaista osaamista, mutta työntekijät hallitsevat Azuren palvelut, tukee ainakin osittain pysymistä Microsoftin tuoteperheessä.

Itseään ei tietenkään kannata lukita yhden toimittajan ratkaisuun, ja useimmat taidot ovat helposti sovellettavissa myös muissa järjestelmissä. Kuitenkin yrityksen oma osaamistaso on hyvä pitää mielessä, sillä se vaikuttaa suoraan siihen, kuinka paljon ulkopuolista apua yritys tarvitsee sekä käyttöönotossa että ylläpidossa.

3. Käyttöönoton ja käytön resurssit

Kolmas osa-alue liittyy järjestelmän käyttöönottoon ja käyttöön tarvittaviin resursseihin. Tähän sisältyvät järjestelmän rakennus- ja migraatiovaiheet sekä järjestelmän käyttöön liittyvät resurssit. Uusien järjestelmien käyttöönotto vaatii paljon yrityksen työntekijöiden aikaa niin määrittelyssä kuin teknisessä toteutuksessa. Tämä ei koske vain IT-henkilöstöä vaan myös liiketoimintalogiikan asiantuntijoita. Lisäksi järjestelmissä on sekä hankinta- että ylläpitokuluja. Henkilöstökulujen lisäksi näihin kuuluvat ohjelmistolisenssit, vaadittavien laitteistojen ostot sekä pilvialustojen laskenta- ja tallennuskapasiteetista aiheutuvat jatkuvat kulut. Vaadittujen kulujen ja resurssien merkitystä usein aliarvioidaan, mutta liike-elämässä ei aina ole mahdollista valita parasta vaihtoehtoa budjettirajoitusten vuoksi.

Tavoitearkkitehtuurin määritys

Kun teknologia- ja työkaluvalinnat on tehty, voidaan siirtyä tavoitearkkitehtuurin piirtämiseen. Arkkitehtuuripiirros rakentuu samalla tavalla kuin nykytilan kuvaus, mutta palasten sisältö voi erota uusista teknologioista ja työkaluista riippuen. Piirrokseen sisältyvät ylätason järjestelmäarkkitehtuuri, integraatiot, tietovirtakaaviot sekä -prosessit.

Tavoitearkkitehtuurin rakentaminen antaa yritykselle mahdollisuuden tarkastella nykyisiä dataprosessejaan tarkemmin. Käsittelemme dataprosesseja seuraavassa blogikirjoituksessa yksityiskohtaisemmin, mutta tässä vaiheessa on hyvä nostaa esille mahdollisuus parantaa prosesseja arkkitehtuurin uusimisen yhteydessä. Kun uutta arkkitehtuuria rakennetaan, kannattaa sekä IT:n että liiketoiminnan asiantuntijoiden kanssa käydä läpi, miten data muuttuu lähdejärjestelmien raakadatasta hyödynnettäväksi tiedoksi. Tämä parantaa datan laatua, kun varmistutaan sen oikeellisuudesta ja ajantasaisuudesta prosessin jokaisessa vaiheessa. Piirtämällä uuden arkkitehtuurin ajatuksella ja sparrailemalla sitä eri sidosryhmien kanssa varmistutaan siitä, että se ottaa huomioon nykytilan ongelmakohdat ja palvelee datastrategian tavoitteita.

Kaikkien liitäntöjen ja integraatioiden kuvaaminen ainakin ylätasolla on myös tärkeää. Kartoitusta tehtäessä on suositeltavaa pitää mielessä ne ongelmakohdat, jotka nykyisessä dokumentaatiossa on havaittu. Data-arkkitehtuuria tullaan uudistamaan myös tulevaisuudessa tasaisin väliajoin, jolloin vajavaisesti tehty arkkitehtuurikuvaus vaikeuttaa tulevia uudistushankkeita.

Toteutussuunnitelma

Kun tavoitearkkitehtuuri on määritetty, voi yritys alkaa miettiä kuinka se voidaan rakentaa. Olemme tunnistaneet kuusi tärkeää osa-aluetta, jotka jokaisen yrityksen tulee ottaa huomioon matkalla kohti modernimpaa data-arkkitehtuuria:

Kyvykkyydet kuvaavat, mitä taitoja ja osaamista yrityksellä tulee olla, jotta data-arkkitehtuurin tavoitetila voidaan realistisesti saavuttaa. Ensimmäinen vaihe on arvioida nykyisten työntekijöiden osaamisprofiilia ja selvittää, mitä uudet järjestelmät ja työkalut vaativat. Kun erot nykyisen ja tarvittavan osaamisen välillä ovat selvät, voidaan pohtia, miten tämä ero saadaan kurottua umpeen. Vaihtoehtoina ovat henkilöstön uudelleenkoulutus, uusien ihmisten palkkaaminen tai ulkoisen konsulttiavun käyttö. Valinta näiden välillä riippuu pitkälti siitä, kuinka vaikeita vaadittavat taidot ovat hankkia ja kuinka pitkään niitä tarvitaan. Esimerkiksi, tarvitaanko jotain teknologiaosaamista vain käyttöönotossa vai myös jatkuvasti ylläpidossa. Mikäli datastrategiaan on kirjattu transitio on premise -pohjaisesta ratkaisuarkkitehtuurista julkipilveen, korvaavien kyvykkyyksien hallitsemiseen kannattaa kiinnittää erityistä huomioita: Tie on premise -spesialistista pilvinikkariksi voi olla hyvinkin pitkä ja kivinen tie.

Tietoturva ja yksityisyys ovat nykymaailmassa yhä tärkeämpiä asioita, joita kannattaa miettiä jo arkkitehtuurin suunnitteluvaiheessa. Yrityksen datan turvaaminen ja tietomurtojen estäminen ovat ensisijaisen tärkeitä, koska niistä koituvat ongelmat voivat olla massiivisia. Yksityisyyden suoja ja esimerkiksi GDPR-säädökset tuovat omat haasteensa datan käsittelyyn ja tallennukseen. Roolitus ja valmiiksi mietityt prosessit ovat näissä kysymyksissä avainasemassa.

Teknologioissa ja palveluissa on kyse pitkälti teknologiavalinnoista. On tärkeää, että tarpeet osataan kuvata tarpeeksi tarkasti, jotta kilpailutettaville yrityksille voidaan antaa mahdollisimman selkeät vaatimukset. Tämän jälkeen tuotteita arvioidaan keskenään, ja valitaan toteutettava vaihtoehto yrityksen asettamien kriteereiden perusteella.

Ei-toiminnalliset vaatimukset kuvaavat kaikki ne vaatimukset, jotka eivät suoraan liity ohjelmiston toimintoihin, vaan varmistavat järjestelmän vastaavan käyttäjän tarpeita. Näitä ovat esimerkiksi skaalautuvuus, ylläpidettävyys, suorituskyky, turvallisuus, luotettavuus ja monet muut osa-alueet. Tähän kokonaisuuteen kuuluvia aspekteja on sivuttu jo aikaisemmin, esimerkiksi turvallisuuden osalta, ja arkkitehtuurikartoituksessa onkin tärkeää, että yritys miettii ja kirjoittaa vaatimukset ylös selvästi. Näin varmistutaan siitä, että järjestelmä sopii kaikilta osiltaan tarkoitukseen, johon se on hankittu.

Toimittaja- ja lisenssistrategiassa etualalla ovat hinnoittelu ja synergiat. Tässä vaiheessa usein itse tuote tai palvelu on valittu, ja kartoituksen kohteena ovat käytännön asiat: Kuka palvelun tuottaa ja millä sopimusehdoilla lisenssit saadaan hankittua? Toimittajien vertailussa mietitään, ostetaanko kaikki palvelut samasta paikasta, vaikka osakokonaisuuksien toteutus kärsisi, vai valitaanko jokaisen osan toteutukseen erikseen paras vaihtoehto. Lisenssien suhteen on usein kyse puhtaasti hinnoitteluneuvotteluista ja sopimusteknisten yksityiskohtien stilisoinnista.

Migraatiopolun suunnittelu nousee esiin seuraavaksi, kun tavoitearkkitehtuuri on määritetty. Polku jakaa muutoksen nykytilasta tavoitetilaan selkeisiin kokonaisuuksiin ja asettaa ne aikajanalle samalla tavalla kuin tiekartta datastrategian kohdalla. Näin varmistutaan, että asioita tehdään oikeassa järjestyksessä ja matka tavoitteeseen on etukäteen suunniteltu.

DB Pro Services tarjoaa kattavia ratkaisuja ja asiantuntijapalveluita tiedolla johtamisen haasteisiin. Tarjontamme kattaa muun muassa datastrategian, modernien data-alustojen, sekä edistyneen analytiikan kokonaisuudet, kuin myös vaativat datamigraatiot. Ota yhteyttä, niin autamme sinua ja organisaatiotasi hyödyntämään tietoa tehokkaasti ja menestymään kilpailussa!

Tämä blogi on osa datastrategia-blogisarjaamme, josta julkaistaan uusia kirjoituksia tulevina kuukausina. Edellisen blogikirjoituksen löydät täältä: Tavoitetilan määritys: Kuinka määrittää datastrategian suunta?

Kaiku Kettunen

Project Manager

kaiku.kettunen@dbproservices.fi

DB Pro Services Oy