Aiemmissa blogeissani olen käsitellyt kommunikointiin ja sen puuttumiseen sekä vinoutuneisiin lähestymistapoihin liittyviä kohtia oheiselta Gartnerin sudenkuoppalistalta:
1. Vääränlaisen pääarkkitehdin palkkaaminen
2. Riittämätön sidosryhmien ymmärrys ja tuki
3. Unohdetaan (liike)toiminnan ihmiset
4. Tehdään arkkitehtuuria vain teknologia-alustoittain
5. Tehdään täydellinen nykytilan kokonaisarkkitehtuuri ensin
6. Arkkitehtiryhmä tekee kaiken työn
7. Arkkitehtuurin vaikutusta ei seurata eikä mitata
8. Tehdään siiloarkkitehtuuria
9. Ei luoda kokonaisarkkitehtuurin hallintaa ajoissa
10. Ei käytetä tarpeeksi aikaa kommunikointiin
Tässä kirjoituksessa keskityn siihen, miten työskentelyssä voidaan mennä pieleen.
Mistä kokonaisarkkitehtuurissa onkaan kyse? Kokonaisvaltaisesta toiminnankehittämisestä. Yksi pahimmista mokista (Gartnerin listan pronssisija) on siis unohtaa liiketoiminnan ihmiset kokonaan. Haasteena on valitettavasti tuo termi ’kokonaisarkkitehtuuri’. Useimpien liiketoimintaihmisten mielestä kyse on jostakin teknisestä ICT-asiasta, joka ei heitä koske lainkaan. Joten heidän mukaan saamisensa ei välttämättä ole helppoa.
Toisaalta tietohallinnossakin katsotaan samaa termiä ja valitettavan usein mielletään tuon tarkoittavan tietohallintoarkkitehtuuria. Tietohallintojohtaja tai tietohallinnosta peräisin oleva arkkitehti mieluusti keskittyy vain tietoteknisiin asioihin. Jos huomasitte, en käyttänyt edellä kokonaisarkkitehti-termiä. Kokonaisarkkitehdin pitäisi kyllä hahmottaa, mitä kaikkea hänen toimialaansa kuuluu. Toisaalta liiketoiminnan puolella on kyllä tehty vuosikymmeniä toiminnan kehittämistä, mutta sitä ei välttämättä ole liitetty mitenkään suoraan tietohallintoon. On saattanut tulla vain järjestelmähankintapyyntöjä tms. Tämä liiketoiminnan ja tietohallinnon välinen kuilu on valitettavan yleinen.
Kaikkein parasta olisi, jos kokonaisarkkitehtuurin omistajan saisi liiketoiminnan puolelta. Tiedän, että joissakin yrityksissä ja kunnissa tämä on jo onnistunutkin. Esimerkiksi Varkaudessa kokonaisarkkitehtuurin omistaa kaupunginhallitus, eikä yhteenkään projektiin saa rahoitusta, mikäli siitä ei ole tehty kokonaisarkkitehtuurilausuntoa. Tulevaisuudessa tästä liiketoiminnan omistajuudesta tuleekin ehkä voimakkaampi tapa, sillä kauppakorkeakouluissa koulutetaan koko ajan ihmisiä liiketoiminnan palvelukseen siten, että heillä on myös hyvät tietotekniset taidot. Reilu vuosi sitten eräässä KAOS-tilaisuudessa keskusteltiin siitä, että kokonaisarkkitehtuuri on jatkossa johtajilta vaadittava osaamisalue aivan samalla tavoin kuin nyt prosessi- tai laatujohtaminen.
Jos pääkokonaisarkkitehti on kuitenkin tietohallinnon puolelta, niin hänen tulisi vähintään hankkia itselleen oikeaksi kädeksi hyvä toiminta-arkkitehti liiketoiminnasta. Ja hänen on syytä perehtyä liiketoimintaan ja sen johtamiseen. Kokonaisarkkitehtuurinhan tulee olla strategialähtöistä, joten hänen tulee päästä mukaan strategiasuunnitteluun ja liiketoiminnan kehittämiseen muutenkin. Tämä tarkoittaa sitä, että pääarkkitehti ei voi olla teknologianörtti – tosin tiedän parikin poikkeusta, kyse on siis yksilöllisistä ominaisuuksista.
No, miten muuten liiketoimintaihmiset saadaan mukaan? Osallistamalla heitä – ja tämä olikin aasinsilta seuraavan sudenkuopan taklaukseen…
Meillä on siis arkkitehtiryhmä – wau! No, isoissa organisaatioissa usein on, mutta harvemmin silloinkaan aivan täysiaikaisina. Alkuvaiheessa kokonaisarkkitehtuurityötä käynnistettäessä työkuorma on suurin ja silloin voi ollakin tarve täysiaikaisille ihmisille. Mutta kun päästään pidemmälle ylläpitovaiheeseen, työkuorma laskee, ja silloin arkkitehtiryhmän ihmiset viimeistään tekevät muutakin työtä.
Itse asiassa pahin tilanne on, jos arkkitehtiryhmä ei tee mitään muuta kuin kokonaisarkkitehtuuria. Nimittäin jos he eivät ole mukana projekteissa ja kaikessa siinä, missä kokonaisarkkitehtuuria hyödynnetään, niin miten he tietävät, toimivatko heidän suunnittelemansa ohjeistot ja kuvaukset oikeasti? Voi käydä niin, että heistä tulee norsunluutorniin eristäytyneitä asiantuntijoita, jotka onnittelevat toisiaan hienoista malleista. Ja kun joku tulee kysymään heiltä neuvoa, miten tätä kohtaa kokonaisarkkitehtuurista pitäisi soveltaa käytäntöön, he eivät osaakaan vastata. Pahimmillaan kokonaisarkkitehtiryhmä tykkää kyllä kovasti keskustella ja pallotella asioita, mutta jos heiltä vaaditaan päätöksentekoa, joku ehdottaa heti vähintään puolen vuoden projektin perustamista. Eli ei haluta tai uskalleta ottaa kantaa konkreettiseen toteutukseen.
Tässä on myös se vaara, että kokonaisarkkitehtuuri jää kaukaiseksi, teoreettiseksi asiaksi, joka ei koskaan jalkaudu jokaisen työntekijän elämään.
Arkkitehtiryhmä toimii koordinoivana ja työtä tukevana tahona, joka viime kädessä tekee myös päätökset. Varsinaiseen kokonaisarkkitehtuurityöhön valjastetaan kulloiseenkin tarpeeseen sopivia liiketoiminnan tai tietohallinnon ihmisiä. Heiltä tulee sisältö ja oman toimialansa tuntemus. Kokonaisarkkitehtien tehtävä on miettiä, miten se puetaan kokonaisarkkitehtuuriksi. He myös toimivat työpajoissa fasilitaattoreina ja kertovat kunkin työpajan aluksi, mitä ja miksi nyt tehdään.
Eräässä yrityksessä otettiin konkreettisesti työntekijät mukaan kuvaamaan nykytilan prosesseja, ja myöhemmin myös tavoitetilaa. He perustivat prosessikerhon, joka kokoontui säännöllisesti tiettyyn aikaan, jolloin paikalla oli myös kokonaisarkkitehti auttamassa mallinnuskysymyksissä ja sopivan tarkkuustason löytämisessä kuvauksille. Kerhossa työntekijät itse kuvasivat prosessejaan. Näin kokonaisarkkitehtuurityö tuli lähemmäksi jokaista työntekijää ja heidän oli myös helpompi sitoutua tavoitetilan prosesseihin.
Tämän tyyppinen työn jakaminen kentälle auttaa myös silloin, kun ei pystytä perustamaan isoa arkkitehtiryhmää. Saattaa olla, että organisaatiossa on vain yksi puolipäiväinen kokonaisarkkitehti. Eihän hän pysty yksin kaikkea tekemään. Tällöin tarvitaan organisointi- ja delegointitaitoa kuitenkin siten, että kokonaisarkkitehti pitää langat käsissään. Mm. näin on tehty Vantaalla. Resurssiongelmissa kannattaa harkita myös hyvän kokonaisarkkitehtikonsultin käyttöä, mutta siten, että sisältövastuu on edelleen organisaatiolla. Konsultti toimii fasilitaattorina ja ehkä mallintajana sekä esittää hyviä kysymyksiä, joiden avulla saadaan organisaation tavoitteet ja tarpeet esiin. Kokonaisarkkitehtuurin vastuu ja omistajuus on edelleen organisaatiosta nimetyllä kokonaisarkkitehdilla.
Arkkitehtiryhmän jäsenten tulee olla kaikkien tiedossa. Aina parempi jos heidän kasvonsa ovat käyneet tutuiksi – silloin ihmiset uskaltavat helpommin tulla kysymään asioita ja apua soveltamisongelmiinsa. Onhan paljon helpompaa kysyä tutulta kuin joltain vieraalta nimeltä.
IT-projektien alussa tehdään ainakin isompien kohdalla esiselvitys, jonka sisältö on pitkälti toimintaympäristön kuvaamista. Pitää selvittää sidosryhmät, kuvata prosessien ja palveluiden nykytilaa ja tavoitetilaa, kuvata liiketoiminnan käsitteistöä. Ja vaatimusmäärittelyssäkin on kokonaisarkkitehtuurikuvauksilta vaikuttavia kohtia: pitää selvittää naapurijärjestelmät ja liittymät niihin. Periaatteessa hyvä idea, mutta…
Vaarana on, että kuvataankin ratkaisuarkkitehtuuria, joka liittyy vain tähän yhteen hankittavaan tai rakennettavaan järjestelmään. Prosessikuvauksissa mennään suoraan työnkulkutasolle, eikä mietitä sitä, miten tuo liittyy laajempaan kokonaisuuteen. Lisäksi usein käy niin, että kuvaukset jäävät projektin kuvauksiksi, eikä niitä voi uudelleen käyttää ja hyödyntää muualta.
Tähän lähestymistapaan voi johtaa ”tietohallintolain” pykälän 9 kohta, jossa puhutaan julkisen hallinnon viranomaisen velvollisuudesta muuttaa tietojärjestelmät yhteentoimiviksi ”tietojärjestelmiä olennaisesti muuttaessaan tai hankkiessaan uusia tietojärjestelmiä ja palveluja tai muutoin tietojärjestelmiä kehittäessään”. Usein tämä on tulkittu siten, että järjestelmäprojektien yhteydessä ruvetaan tekemään kokonaisarkkitehtuuria. No, yhteentoimivuus on yksi seuraus kokonaisarkkitehtuurista…
Kokonaisarkkitehdin tulee olla yhteydessä projektipäällikköön jo ennen projektin käynnistymistä. Käytännössä tämä menee varmaan useimmiten niin päin, että projektipäällikön on otettava yhteyttä kokonaisarkkitehtiin siinä vaiheessa, kun hän alkaa tehdä projektisuunnitelmaa. Kokonaisarkkitehdin tulee olla mukana esiselvitysvaiheessa vähintään opastajana, mikäli halutaan, että kuvauksista tulee kokonaisarkkitehtuurissa hyödynnettäviä. Toisaalta esiselvitykseen kuuluu toimintaympäristön laajempi kuvaaminen, mutta myös juuri tähän hankittavaan järjestelmään liittyvät asiat, eli siinä on rinnakkain kokonaisarkkitehtuuri- ja ratkaisuarkkitehtuuriasioita. Ja juuri tähän ”rajanvetoon” tarvitaan avuksi kokonaisarkkitehtia.
Vaatimusmäärittelyssä ja myöhemmin sovellus- tai järjestelmäarkkitehtuuria määriteltäessä ja suunniteltaessa on sama juttu. Kokonaisarkkitehtia tarvitaan selittämään arkkitehtuurilinjauksia ja –päätöksiä ja valvomaan, että niitä myös noudatetaan. Muuten käy niin, että kukin projekti tekee miten haluaa, eikä kokonaisarkkitehtuuria luoda tai sovelleta.
Oleellista on, että ratkaisuarkkitehtuurin projektissa syntyneet kokonaisarkkitehtuurikuvaukset arvioidaan ja talletetaan yhteiseen repositoryyn, jossa ne ovat kaikkien käytettävissä.
Summa summarum:Ihmiset ovat yksilöitä ja toimivat helposti yksilöllisesti. Kokonaisarkkitehtuuri taas korostaa yhteentoimivuutta ja kokonaisuuksia, jolloin ihmistenkin pitää toimia yhteen ja yhdessä. Ja kokonaisarkkitehtien ja ”tavallisten” ihmisten tulee pelata yhteen.
Kuulet näistä asioista Coalan kokonaisarkkitehtuurikursseilta www.coala.fi/palvelut, uutuutena mm. Kokonaisarkkitehtuurin kuvaaminen – opi toimivat työtavat.