Vältä kokonaisarkkitehtuurin sudenkuopat, osa 4: Ohjaus ja vaikuttavuus

Blogi


Sudenkuoppien blogisarjan viimeisessä osassa keskityn ohjaukseen ja vaikuttavuuteen liittyviin kohtiin 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

9. Ei luoda kokonaisarkkitehtuurin hallintaa ajoissa

 
Kokonaisarkkitehtuurin hallinta – sehän kuulostaa byrokratialta ja joltain kankeilta rakenteilta ja käytännöiltä. Kyllähän me osaamme tämän homman, ei siihen mitään ylimääräistä tarvita. Ja eikös kokonaisarkkitehtuurin pitänyt tuoda ketteryyttä liiketoimintaan?! Hallinta kuulostaa juuri vastakkaiselta.
 
Tuon edellä kuvatun ajattelija unohti, että hallintaan liittyy organisoinnin lisäksi myös esimerkiksi syntyvien kuvausten versiointi ja hallinta sekä työtehtävät, jotka toistuvat vuosittain (ns. vuosikello). Eikä sovi unohtaa saumapintoja muihin organisaation tai yrityksen menetelmiin: laatu, hankkeet, johtaminen, jne. Mutta tarvitaanko näitä jo alussa? Kyllä, osaa tarvitaan. Hallintaan liittyy myös työskentelytapojen ja kuvaustapojen valitseminen ja jalkauttaminen. Muutenhan jokainen tekee niin kuin lystää, eivätkä kuvaukset taaskaan ole yhteensopivia.
 
Otan analogian entisestä elämästäni koulutusmaailmasta. Kun aloittelin siellä, meitä oli systeemityöalueella vain pari kouluttajaa. Ei ollut mitenkään hankala tietää, mikä materiaali oli viimeisin ja mitä käytetään. Vaan sitten tuli lisää kysyntää, minkä myötä kuvioihin tuli joukko freelancereita. Ja jokainen halusi tehdä omia virityksiään materiaaleihin. Ja unohti tietysti toimittaa aineiston koulutuskoordinaattorille ja informoida muita. Tämä johti pahimmillaan siihen, että kurssin alkaessa kurssilaisilla oli edessään ihan eri versiota oleva materiaali kuin kouluttajalla. Ei kiva!! Oli pakko luoda käytännöt versioinnille ja muutoksista informoinnille jne. Ja tietysti jalkauttaa tämä käytäntöön. Haa, noudatimme itse oppeja, joita koulutimme! Eipä tullut enää vastaavia ongelmia, vaikka samaa kurssia piti useampi eri kouluttaja, ja vaikka räätälöimme materiaaleja asiakaskohtaisesti.
 

Taklaus:

 
Lähde kevyesti liikkeelle. Mieti mitä oikeasti tarvitaan heti alussa. Ja katso vähän lähitulevaisuuteen. Luo siis puitteet, joita voi tarkentaa myöhemmin.

Heti alussa tarvitaan jonkinasteinen organisointi – kuka tekee työtä, kuka hyväksyy tuotokset. Pääarkkitehti ja päävastuullinen eli kokonaisarkkitehtuurin omistaja tarvitaan heti. KA:n omistajan pitää olla omasta organisaatiosta ja ihan nimetty henkilö tai tietyssä roolissa toimiva henkilö. Erittäin suositeltavaa on, että omistaja on liiketoiminnan puolelta. Tiedän – tämä on joskus haastavaa. Kokonaisarkkitehtuuri on kuitenkin johtamisen työväline, ja silloin on fiksuinta, että sen omistajuuskin on siellä, missä sitä eniten tarvitaan. Pääarkkitehti yleensä on omasta organisaatiosta, ja varsin usein tietohallinnon puolelta. Voi olla kuitenkin tilanteita, joissa käytetään konsulttia apuna. Silloin arkkitehtikonsultti raportoi KA:n omistajalle.
 
Sopikaa karkealla tasolla työskentely- ja muutostenhallintaprosesseista. Työskentelyprosessista sopiminen helpottaa työtä, kun kaikki tietävät, missä järjestyksessä töitä tehdään ja miten tuotokset hyväksytään. Työskentelyprosessi taatusti muokkautuu parin ensimmäisen kierroksen aikana – se ei ole siis kiveen hakattu. Yllätys, yllätys, muutoksia tulee – sekä KA-työn aikana että sen tuotosten soveltamisessa ratkaisuarkkitehtuuriin. Niinpä kannattaa varautua näihin jo ennakolta ja luoda peruskäytännöt.
 
Käykää läpi, miten kokonaisarkkitehtuuri liittyy muihinorganisaationne johtamisen ja kehittämisen malleihin. Tätä ei tarvitse käydä kaikkea kerralla. Aloittakaa johtamisen ja liiketoimintastrategian malleista ja tutkikaa, missä ovat rajapinnat kokonaisarkkitehtuuriin. Nimittäin yhteentörmäyksiä ei saisi tulla ja toisaalta on resurssien hukkaamista tehdä samoja asioita kahteen kertaan. Käykää läpi myös hankesalkun ja projektien hallinta: KA-työtä tehdään yleensä projekteina ja projekteissa ja kokonaisarkkitehtuurin tuotoksia hyödynnetään projekteissa. Paitsi että ei hyödynnetä, jos nämä rajapinnat ontuvat. Kannattaa tässäkin lähteä kevyesti liikkeelle tyyliin ’kokonaisarkkitehti toimii projektipäällikön oikeana kätenä projektisuunnitteluvaiheessa’ ja ’apua saa KA-ryhmältä arkkitehtuurilinjausten tulkintaan ja sopivien mallinnustapojen löytämiseen’.
 
Miten kokonaisarkkitehtuurityö ajoitetaan vuoden mittaan? Tutkikaan organisaationne johtamisen vuosikelloa – sinne on merkitty mm. strategian suunnittelu (lähtökohtia KA:lle), budjetin valmistelu (tänne pitäisi saada jotain KA-työn toteutuksia), itse budjetointi (saadaanko rahaa KA:lle?) ja sen toimenpiteiden eteenpäin vienti (KA-projektien käynnistäminen). Sovittakaa vuotuinen KA-työn rytmi tähän jo olemassa olevaan vuosikelloon. Jos rakennatte ihan oman vuosikellon KA:lle, saatte ihan itse aikaiseksi uuden sudenkuopan… tai ainakin joukon hankaluuksia.
 
Kokonaisarkkitehtuurin hallintaan kuuluvat myös vaikutusten seuraaminen ja mittaaminen, minkä unohtaminen onkin seuraava sudenkuoppa.

7. Arkkitehtuurin vaikutusta ei seurata eikä mitata

 
Kun kokonaisarkkitehtuurityötä aloitellaan, niin siihen asetetaan suuria toiveita ja odotuksia. Kokonaisarkkitehtuurin avullahan tiedämme tarkasti, mihin kaikkialle muutokset vaikuttavat, vältämme päällekkäisen työn ja saamme huimia säästöjä – eikös niin… Vaan mistä tiedämme toteutuivatko odotukset? Liian usein unohdetaan seurata tai mitata, millaisia vaikutuksia kokonaisarkkitehtuurilla oikeasti on. Sitten täytyy mennä mutu-tuntumalla, eikä se ole koskaan hyvä juttu.
 
Ja vaikka sitten keksittäisiin laittaa joku mittari pystyyn, niin mihin sitä verrataan? Kovin usein lähtötilannetta ei ole ”mitattu” tai tavoitetilanteelle ei ole asetettu minkäänlaisia kriteerejä. Silloin mittaamisesta ei ole mitään hyötyä.
 

Taklaus:

 
On vaikea saada järkeviä mittaustuloksia, jos lähtötilannetta ei tiedetä. Tähän auttaa kaksi asiaa. 

Tehkää kokonaisarkkitehtuurin kypsyystasomittaus itsearviointina. Tämä antaa tietoa siitä, mitä jo tiedetään ja hallitaan ja toisaalta siitä, mitä osa-alueita pitäisi kehittää. Kaikkein tehokkain tämä on siinä vaiheessa, kun on jo vähän tehty KA-työtä. 
Kokonaisarkkitehtuurin suunnittelun valmisteluvaiheessa pitää kerätä, mitä kaikkea dokumentaatiota on olemassa ja mistä ne löytyvät. Tämä itsessään jo antaa kuvaa siitä, missä tilassa organisaation kokonaisuuksien hallinta on. Toisaalta kuvausten läpikäynti nykytilan analysointivaiheessa antaa kuvaa siitä, mitä on oikeasti osattu kuvata fiksusti, ja toisaalta missä on selviä puutteita. 

Näistä kahdesta saa paremman lähtötila-arvion kuin hihasta pudistamalla.

 
KA-työn alkuvaiheessa mittaaminen voi perustua aikatauluihin. Asetetaan tavoitteet, milloin pitäisi olla tietyt tehtävät tehtyinä tai organisoituina, ja sitten mitataan, miten ne oikeasti valmistuivat. itse KA-työn tavoitetilalle kannattaa laittaa välitavoitteita ja pienempiä kokonaisuuksia. Syy: kun niitä saadaan jotakin valmiiksi, aletaan myös nähdä KA-työn tuloksia ja vaikutuksia nopeammin. Ja nämähän kiinnostavat pomoja.
 
Mittarien keksiminen on aina vaikeaa. Älkää siis yrittäkö väkisin keksiä isoa liutaa mittareita, joista ei ehkä olekaan hyötyä. Koettakaa löytää pari mittaria, jotka oikeasti toimivat. Tässä pari esimerkiksi:

  1. Toiminnan sujuvoituminen: Jos tavoitetilaan suunnitellun prosessin käyttöönotto aiheuttaa toiminnan sujumista paremmin, se lyhentää läpimenoaikoja. MUTTA älkää mitatko heti, vaan vasta 3 kk kuluttua käyttöönotosta, sillä opetteluvaiheessa prosessi on hitaampi kuin vanha tapa.
  2. Kuinka paljon IT-projektien esiselvitys- ja/tai vaatimusmäärittelyvaihe nopeutuvat: Esiselvitysvaiheessa pitää selvittää ja kuvata paljon sellaisia asioita, jotka löytyvät kokonaisarkkitehtuurista. Jos nuo ovat siis jo olemassa, riittää niiden poimiminen mukaan sopivalla rajauksella. Eli ei tupla-työtä. Vaatimusmäärittelyssä selvitetään toiminnallisten vaatimusten lisäksi ei-toiminnallisia vaatimuksia – ja nämä viimeksi mainitut löytyvät usein teknologia-arkkitehtuurilinjauksista. Nyt ne pitää vain sovittaa käsiteltävään tapaukseen. Ei tarvitse siis keksiä pyörää alusta lähtien uudelleen.

Vaatimusmäärittelyssä pitää kuvata myös naapurijärjestelmät ja ainakin karkealla tasolla järjestelmien väliset liittymät. No, nämäkin löytyvät kokonaisarkkitehtuurikuvauksista – ei muuta kuin poimimaan sieltä!

Näillä kahdella pääsee jo kummasti eteenpäin. Ja jos haluaa vielä lisäksi kirjata ylös, kuinka paljon uudelleenkäytettäviä kuvauksia tuli käytettyä, niin saadaan aitoa seurantaa myös kokonaisarkkitehtuurin hyödyntämiselle. Ai niin, nuo ensiksi mainitut tarkoittavat myös säästöjä, sillä aika on rahaa! Jos prosessin läpimenoaika lyhenee tai IT-projektin alkuvaiheet nopeutuvat, niin kyllä noista kustannussäästöjä tulee.

 
Kun kokemusta karttuu ja huomataan, mitä asioita kannattaa seurata, niin sitten voidaan ottaa uusia mittareita käyttöön vähitellen.
Tässä blogisarjassa olen ruotinut omiin kokemuksiini ja havaintoihini perustuen Gartnerin löytämää kymmenikköä kokonaisarkkitehtuurin sudenkuopista. Ah, jos me kaikki osaisimme väistää ja välttää nämä sudenkuopat! Lisää kokemuksen rintaäänellä kerrottuja esimerkkejä kuulet siis kursseillamme

www.coala.fi/palvelut

Yhteydenotto