Kokonaisarkkitehtuuri - miten naula ja ruuvi saadaa juttelemaan keskenään?

Vuoden alussa pohdiskelin kokonaisarkkitehtuurin olemusta ja merkitystä. En tiedä olenko sen jälkeen ymmärtänyt asiasta enemmän vai päinvastoin unohtanut jo oppimaani, mutta asia on kuitenkin askarruttanut.

Viime viikon lopulla olin seminaarissa jossa puhuttiin kokonaisarkkitehtuurista korkeakoulujen näkökulmasta. Tämä antoi paljon ajateltavaa. Omalle esitykselleni oli annettu otsikko "Kokemuksia korkeakoulujen yhteisten IT-palveluiden tuottamisen johtamisesta", josta kyllä syntyi varsin mukavasti keskustelua, muun muassa Jyväskylän yliopiston FEAR-projektin tuloksiin liittyen.

Mainio hahmotelma siitä, mitkä asiat IT-kehityshankkeissa menevät pieleen löytyy Mikko Malisen ja Antti Pyykön esitelmästä 17.6.2010. (Löytyy PDF-tiedoston sivulta 36.)

Tässä listaa tyypillisistä epäonnistumisen syistä:

• tavoitteiden epärealistisuus suhteessa resursseihin
  
• heikko tai kokonaan puuttuva koordinointi
  
• puutteita valvonnassa ja siinä havaittuihin ongelmiin puuttumisessa.
  

(Esitelmästä löytyy näitä vielä kuusi lisää.) Kyse on siis projektityön perusasioista, toki IT-mausteilla höystettynä. Karua kuultavaa, kun ottaa vielä huomioon että vain noin kolmannes IT-hankkeista onnistuu.

Yksi näkökulma asiaan on "naulan ja ruuvin probleema", siis se että vaikka keskustellaan niin keskustellaan ohi toisten osapuolten mutta kuvitellaan että oikeasti kommunikoidaan. Tai ainakin se jää huomaamatta, että merkittävä osa viestinnästä joko ymmärrettiin väärin tai jätettiin huomiotta.

Asiaa voisi karikatyrisoida kahden toimijan välisen keskusteluna. Toinen keskustelija - sanotaan nyt vaikka naula - tuntee tietojärjestelmät kuin omat taskunsa, tietää miten niitä sovelletaan eri kohteisiin ja miten niitä räätälöidään. Toinen taas - kutsukaamme häntä ruuviksi - tuntee liiketoiminnan ja palvelutarjooman kuin omat taskunsa, kaikkia hienoja vivahteita ja erityistapauksia myöten.

Kun sitten naula ja ruuvi rupeavat keskustelmaan tietojärjestelmähankkeesta, olkoon se vaikkapa ERP-hanke, aletaan välittömästi puhua ohi toisen. Naula näkee järjestelmän sisuskalut ja innostuu sen suoraviivaisista mahdollisuuksista. Ruuvi taas näkee hankkeessa mahdollisuuksia saada vihdoinkin tolkkua vanhojen tietojärjestelmien omituisuuksiin ja uskoo kykenevänsä vihdoinkin huomioimaan asiakastyön hankalimmatkin erityistapaukset uuden tekniikan myötä.

Jos näiden toimijoiden keskinäistä kommunikaatiota ei kukaan muu analysoi - en jaksa uskoa että naula tai ruuvi osaisi asettua oman roolinsa ulkopuolelle - tuloksena on jatkuvien väärinymmärrysten sarja. IT-järjestelmän vaatimusmäärittelyä luetaan kahdella eri tavalla, johtuen lukijoiden erilaisista taustoista ja konteksteista, samaten projektin eteneminen nähdään eri tavalla.

Lopulta jossain vaiheessa ilmenee, että asiat kerta kaikkiaan eivät toimi - joko naula huomaa, että tosiasiassa haluttua toiminnallisuutta ei voida toteuttaa tietojärjestelmän tarjoamilla välineillä - tai ruuvi huomaa, että paljon sellaista mikä olisi pitänyt pystyä toiminnasta viestimään on jäänyt kertomatta ja pitäisi nyt pystyä huomioimaan järjestelmää toteutettaessa.

Lopputulema ei välttämättä ole kaunis. Toimijoiden hiljainen tieto (nimenomaan se tärkeä tieto jonka merkitys jää tunnistamatta) on loputon syy epäonnistumisille ja kompastumisille. Milloin on saatu aikaan tietojärjestelmä joka todella toteuttaa ne asiat joita järjestelmän käyttäjä siltä haluaa?

No, ehkä silloin - siinä harvinaisessa tapauksessa - että järjestelmälle asetetut odotukset on todella ajatuksella käyty läpi, ja samalla myös pohdittu toimintaprosesseja ja ulkoisen maailman kehitysnäkymiä, jolloin voidaan paitsi ottaa käyttöön uusi tietojärjestelmä myös petrata itse toiminnan kehittämisessä. Mutta tämä taitaa olla utopiaa.