Lähes kaikki toimintamme perustuu tietoihin, joita meillä on käsiteltävästä asiasta. Samoin järjestelmämme toiminta perustuu sen ja muiden järjestelmien tietoihin. Mutta ovatko tietomme oikeita? Onko matkalla tapahtunut väärinymmärryksiä? Eivätkö tiedot kohtaa oikein toisiaan? Onko tiedonsiirrossa ongelmia?
Tietomme toivottavasti ovat oikeita, mutta harvoin täydellisiä tai riittäviä. Tietojen vajavuus usein johtuu kommunikointiongelmista joko ihmisten, organisaatioiden tai järjestelmien välillä. Helposti käytämme samasta asiasta useita eri nimityksiä, synonyymejä. Tai luulemme puhuvamme samasta asiasta, kun tarkoitammekin eri asioita – tällöin on kyse homonyymeistä. Esimerkiksi joku puhuu tilistä – mutta onko kyseessä pankkitili, kirjanpidon tili vai kenties käyttäjätili? Kalliiksi väärinymmärrykset tulevat, jos jonkin asian selvittämiseksi joudutaan kysymään lisätietoja moneen kertaan, tai jos toimitetaan jotain ihan muuta kuin on tilattu. Kyse on siis sekä oikeellisesta tiedosta että yhteentoimivuudesta. Tiedon laatuun vaikuttavat toki muutkin asiat. Tietoarkkitehtuurin luominen ja hyödyntäminen auttaa näihin molempiin haasteisiin.
Vaan mitä on tietoarkkitehtuuri? Hyvä kysymys. Sanonta kuuluu: pistä 3 tietoarkkitehtia saman pöydän ääreen, niin hetken päästä on kunnon väittely tai jopa riita virinnyt. Jo sana ’tieto’ tarkoittaa eri ihmisille eri asiaa. Lisäksi tietoarkkitehtuuria on tehty eri aikoina ja eri yrityksissä tai organisaatioissa eri painotuksin. On syntynyt jopa oppiriitoja ja ”traumoja” huonoista kokemuksista. Ottamatta kantaa siihen mikä on ”oikea” tapa tehdä tietoarkkitehtuuria, asioita voidaan katsoa eri näkökanteilta. Onhan totta, että käyttötarkoitus ja asiayhteys vasta määrittää, millaiseksi kukin tietoarkkitehtuuri muodostuu. Arkistolaitoksen tietoarkkitehtuuri on varmasti erinäköistä kuin kunnan kiinteistötoimen tai vähittäiskaupan.
Joka tapauksessa ilman tietoarkkitehtuuria käy helposti niin, että jokaisessa projektissa aloitetaan alusta. Lähdetään keräämään sanastoa ja määrittelemään termejä. Kerätään tietoluetteloita ja laaditaan käsitemalleja. Sinänsä ok, mutta tässä tulee haaskattua aikaa ja tehtyä samoja asioita moneen kertaan. Ihan niin kuin projekteissa ei muutenkin olisi kiire. Pahinta on, että vaikka projektit sivuaisivat toisiaan, syntyvät käsitemallit näyttävät aivan erilaisilta.
Tietoarkkitehtuuria tehdäänkin useammalla tasolla. Tärkeintä olisi luoda ensin yritykselle tai organisaatiolle yhteinen ylätason käsitteistö ja ns. liiketoiminnan käsitemalli. Haetaan siis yhteistä pohjaa, että ymmärrämme toisiamme. Siinä ei oteta kantaa, mitkä järjestelmät käyttävät tai tuottavat tietoja, vaan mietitään asia puhtaasti liiketoiminnan kannalta. En kuitenkaan kannata niin ylätason mallia, jossa kaikki käsitteet ovat abstrakteja. Tällainen malli jää yleensä teoreettiseksi rakennelmaksi, jota kukaan ei osaa soveltaa – ei välttämättä edes tietoarkkitehdit. Jos organisaatiossa on useita, hyvinkin toisistaan poikkeavia toimialoja, voidaan laatia ns. kohdealueiden käsitemalleja. Kuitenkin näissäkin tapauksissa olisi hyvä tunnistaa käsitteet, joita tarvitaan kaikkialla, ja käyttää niistä samoja nimityksiä jokaisessa kohdealueen käsitemallissa.
Ainoastaan tällä tavoin voimme vähitellen päästä yhteisymmärrykseen ja helpottaa myös tietojärjestelmäprojekteja ja integraatioiden onnistumista. Tämä ei siis tapahdu yhdessä yössä tai viikossa tai edes kuukaudessa, vaan vähitellen sitä mukaa kun järjestelmiä uusitaan. Koska emme elä ideaalimaailmassa, tähän välivaiheeseen julkinen sektori on kehittämässä Yhteentoimivuusmenetelmää, johon kuuluvan soveltamisprofiilin avulla mm. järjestelmät saadaan paremmin keskustelemaan keskenään. Todellisuudessa näitä soveltamisprofiileja on ollut jo pitkään olemassa, mutta niitä ei ole kutsuttu tuolla nimellä. Esim. pankkien maksuliikenteen rajapinta on tarkkaan kuvattu eli mitä tietoja, missä järjestyksessä ja muodossa pitää toimittaa. Tästä on kyse myös soveltamisprofiilissa, joskaan siinä ei oteta kantaa toteutustekniikkaan.
Lisää tietoarkkitehtuurista, sen kehittämisestä ja hyödyntämisestä kuulet Coalan kurssilla Tietoarkkitehtuuri muun kehittämisen tukena.
Tarja Raussi
Kirjoittaja on kokonaisarkkitehti ja konsultti Coalasta. Yli 25 vuoden aikana Tarja on tehnyt monenlaista, mutta jo varsin aikaisin hän huomasi, että kokonaisuuksien hallinta ja kuvaaminen ovat hänen ominta aluettaan. Niinpä pitkän määrittely- ja mallintamiskokemuksen jälkeen oli luontevaa siirtyä kokonaisarkkitehtuurin ja laadunhallinnan pariin. Tarjasta on hienoa, kun saa kanssatekijät tai valmennettavat oivaltamaan asioita.