Samuli Pekkola
Feb 19, 2014

Lapioita ja malleja

Tietohallintolaki on nyt ollut voimassa reilut kaksi vuotta. Julkishallinnon organisaatioilla on ollut reilusti aikaa opetella ja tulkita, mitä laissa mainittu kokonaisarkkitehtuuri tarkoittaa. Tietohallintolaki lähestyy asiaa mallien näkökulmasta: ”tietohallinnon kokonaisarkkitehtuurilla [tarkoitetaan] kuvausta julkisen hallinnon organisaatioiden, palvelujen, toimintaprosessien, käsiteltävien tietojen sekä käytettyjen tietojärjestelmien ja teknologian muodostaman tietohallinnon kokonaisuuden rakenteesta ja sen osien välisistä suhteista” (§3 Määritelmät). Mallit ovat kuitenkin vain työkaluja, eräänlaisia lapioita. Aivan kuten lapiolla kaivetaan ojaa, erilaisilla malleilla avataan väylää tietojärjestelmien, toimintaprosessien, tietojen ja teknologioiden välisten suhteiden syvällisempään ymmärtämiseen. Toisaalta, mikäli ojankaivaja ei tiedä minne päin ja miksi ojaa pitää ylipäänsä kaivaa, ei ojaa synny kovinkaan kovalla päivävauhdilla tai tarmokkuudella. Sama pätee kokonaisarkkitehtuurimalleihin.

Tästä suunnan puutteesta löytyy useita esimerkkejä: malleja laaditaan lain näin määrätessä, tarkkuustaso ja kuvaustavat valitaan mielivaltaisesti ja tehtävää laitetaan suorittamaan viimeiseksi taloon tullut harjoittelija. Kukaan ei huomaa kysyä, miksi malleja oikeastaan pitäisi laatia, mitä hyötyä niistä on, kuka malleja käyttää tai miten niitä ylläpidetään – tai tarvitseeko niitä ylläpitää lainkaan. Malleja ei laadita päämäärätietoisesti eikä tavoitehakuisesti. Tyydytään täyttämään lain kirjain.

Miksi-kysymysten puute antaa aavistuksen siitä, miten kokonaisarkkitehtuurilähestymistapaa tulkitaan. Tietohallintolaki määrittää kokonaisarkkitehtuurin olevan malleja. Toisaalta kokonaisarkkitehtuuri nähdään myös strategisen tason tulevaisuuden ratkaisuna. Kokonaisarkkitehtuuria ei sen sijaan nähdä nykypäivän operatiivisena työkaluna – mitä se sitten ikinä kenellekin tarkoittaa.

Tämä ristiriita mallien ja strategisen tason to-be-tilan välillä tarjoaa yhden selityksen, miksi kokonaisarkkitehtuurin kehittäminen on edennyt vähemmän tarmokkaasti. Malleista ei nähdä olevan käytännön hyötyä juuri nyt, vaan hyöty tulee joskus tulevaisuudessa. Se, kenelle, miten ja milloin hyödyt konkretisoituvat, on epäselvää vaikka mallien avulla väitetään ratkaistavan suurin piirtein kaikki organisaatiossa olevat ongelmat – ainakin myyntipuheiden perusteella.

Kokonaisarkkitehtuuri ei kuitenkaan ole Graalin malja. Arkkitehtuurimallit tai edes kokonaisarkkitehtuurilähestymistapa eivät yksinään ratkaise organisaation ongelmia. Sen sijaan ne tarjoavat mahdollisuuden kehittää organisaation toimintaa tekemällä erilaiset tietoon, liiketoimintaan, tietojärjestelmiin ja teknologioihin liittyvät yksityiskohdat ja suhteet näkyviksi ja siten paremmin hallittaviksi. Se, miten näitä malleja aiotaan hyödyntään, määrittelee kokonaisarkkitehtuurityön kohteen, tarkkuustason, työssä tarvittavat dokumentit, kuvaukset ja kuvaustavat, erilaiset sidosryhmät, mallien myöhäisemmän hallinnan ja ylläpidon ja niihin liittyvät käytänteet ja menetelmät, sekä hyödynnettävät tekniikat ja teknologiat. Kaikki lähtee siis tavoitteista.

Onko näitä tavoitteita mietitty? Onko organisaatiossa kysytty,miksi valtionvarainministeriö ohjeistaa tekemään kokonaisarkkitehtuurityötä? Onko organisaatiossa sisäisesti mietitty miksi erilaisia malleja laaditaan tai pitää laatia? Kun tätä perimmäistä mietintää ei ole tehty, ei kokonaisarkkitehtuurilla nähdä olevan arvoa päivittäisessä operatiivisessa toiminnassa. Esimerkiksi Hilman hankintailmoituksia tarkastelemalla huomaa nopeasti arkkitehtuurimallien minimaalisen roolin tietojärjestelmiä uudistettaessa. Sitä ei ole. Kuitenkin juuri tässä olisi helpoin tapa hyödyntää jo auki lapioitua arkkitehtuuriojaa tarjoamalla tehdyt mallit järjestelmätoimittajalle, vaatimalla sitä rakentamaan kuvauksiin sopivan ratkaisun ja lopuksi dokumentoimaan sen aikaisempien mallien kanssa yhteensopivalla tavalla. Kun tätä ei tehdä, hankinnan tuloksena saatava ratkaisu on todennäköisesti epäyhteensopiva useimmilla kokonaisarkkitehtuurin eri tasoilla.

Tietohallintolaissa tehtäväksi edelletyillä kokonaisarkkitehtuurimalleilla on siis arvoa. Aivan kuten lapiolla tämä arvo on kuitenkin vain välinearvo halutun tavoitteen saavuttamiseksi. Vaikka välineitä voidaan vertailla ja arvioida, ei valittu työkalu, oli se sitten Fiskarsin lapio, togaf, Kartturi tai joku muu, vielä takaa lopputuloksen onnistumista. Tärkeämpää on ymmärtää miksi laipiota käytetään ja malleja rakennetaan.

Oleellista onkin kysyä: Miksi?

 

(Kirjoittaja on ICT Standard Forum bloggaaja, kirjoitus on julkaistu aikaisemmin CIO.fi-sivulla).

Ota yhteyttä Bisnesteknologiamalli PDF

Haluatko tietää lisää Bisnesteknologiamallista ja sen soveltamisesta käytännössä? Ota yhteyttä.