Miten onnistua arkkitehtuuritoiminnon pystyttämisessä? Nämä vinkit toimivat molemmissa tilanteissa, voit olla joko pystyttämässä kokonaisarkkitehtuuritoimintoa ensimmäistä kertaa tai käynnistämässä sitä uudelleen.
Ensimmäistä kertaa toimintoa pystytettäessä haaste on se, että kukaan ei kunnolla hahmota, mitä se kokonaisarkkitehtuuri oikein on. Useamman pystytysyrityksen jälkeen haasteena ovat aikaisempien kertojen epäonnistumiset. Joskus jopa sanaa ”kokonaisarkkitehtuuri” ei saa enää käyttää, vaan puhutaan vaikkapa ”rakenteisesta suunnittelusta”. Tämä on toki hämmentävää, sillä uusia ihmisiä palkatessa ja konsultointia hankkiessa olisi helpompaa käyttää vakiintunutta terminologiaa.
Ennen pystytystä on ymmärrettävä arkkitehtuuritoiminnon tehtävät ja sen vaatima työmäärä. Arkkitehtuuritoiminnon tehtävien määrittely ei ole niin helppoa kuin voisi kuvitella. ”Tekee kokonaisarkkitehtuuria” ei nimittäin riitä, vaan on päästävä konkreettisemmalle tasolle. Organisaatiossasi voi hyvinkin olla jo prosessien kehittäjiä ja ylläpidetty laatukäsikirja. Kuka siis ylläpitää ja minkä tason prosesseja? ICT-puolellakin tehdään kaikenlaista, mikä sivuaa kokonaisarkkitehtuuria. Ainakin järjestelmäsalkkua kannattaa ylläpitää, oli organisaatiossa kokonaisarkkitehtuuria tai ei. On nimittäin syytä tietää, mitä tietojärjestelmiä meillä edes on.
Haastavin asia on määritellä työnjako kokonaisarkkitehtuurin ja kehittämisprojektien välillä. Kokonaisarkkitehtuurin merkittävä hyöty on tukea kehittämisprojekteja, mutta mitä se tarkoittaa? Kokonaisarkkitehtuuritoiminnolla on harvoin sellaista määrää resursseja, että se ehtisi tehdä kaikkien projektien kaikki arkkitehtuurikuvat. Toisaalta, jos kehittämisprojektit eivät saa hyötyjä kokonaisarkkitehtuurista, alkaa olla kyseenalaista, onko hyötyjä saatavissa millään muullakaan alueella.
On siis määriteltävä työnjako ja tuotokset. Työnjaon on kuvattava, mitä kokonaisarkkitehtuuritoiminto tekee, kenelle tuotokset menevät (ja mihin käyttöön) sekä tarvitseeko kokonaisarkkitehtuuritoiminto jotain muilta toiminnoilta (vaikkapa mainitun ylläpidetyn järjestelmäsalkun). Tuotoksia kuvatessa on otettava kantaa kattavuuteen ja tarkkuustasoon. Se nimittäin vaikuttaa työmäärään, mikä edelleen vaikuttaa tarvittavien resurssien määrään. Tämä saat helpoiten selville pilotoimalla, eli tekemällä jonkun osa-alueen kuvaukset ja arvioimalla tarvittavan työmäärän yksinkertaisella kertolaskulla.
Seuraavaksi pitäisi saada arkkitehdit kasaan. Keräilläänkö arkkitehdit omasta organisaatiosta, rekrytoidaanko uusia vai käytetäänkö konsultteja? Jonkinlainen kompromissi kaikista kolmesta on paras. Oman organisaation tuntemus auttaa arkkitehtuurityössä ja arkkitehtuuriosaaminen on koulutettavissa, uudet ihmiset tuovat raikasta näkökulmaa ja konsultit kokemusta. Toiminto kannattaa aloittaa suhteellisen pienenä, sillä työmaan koko eli resurssien tarve valkenee ajan kanssa. Lisäksi alkuvaiheessa aikaa menee työtapojen pähkäilyyn ja muihin käynnistämiseen liittyviin asioihin. Kun kokonaisarkkitehtuuritoiminto pyörii, on työmaa hieman erilainen kuin ihan alussa.
Oleellinen kysymys on myös se, mihin kokonaisarkkitehtuuritoiminto organisaatiossa sijoitetaan. Tässäkin on puolensa ja puolensa. Jos toiminto on pelkkä virtuaalitiimi, on riski, että kunkin arkkitehdin varsinainen ”kotiosasto” työllistää niin paljon, että arkkitehtuuria ei ehdi edes ajatella saati tehdä. Jos arkkitehtuuritoiminto on erillinen, on riski ns. norsunluutorniin eli siihen, että kiinnityspinta muuhun organisaatioon on liian ohut. Joskus toiminto sijaitsee tietohallinnossa, siellähän moni arkkitehti työskentelee muutenkin, mutta muu organisaatio voi silloin kokea kokonaisarkkitehtuurin ”joksikin IT-jutuksi”. Strategiayksikkö ei olisi hullumpi sijoituspaikka, jos se vain muuten onnistuu.
Jos organisaatiossa haluttaisiin päästä vähän helpommalla, tutustu Coalan Kokonaisarkkitehtuurin käynnistyspakettiin. Meillä on kokemusta kymmenien organisaatioiden kokonaisarkkitehtuurin käynnistyksestä. Hyödynnämme työssämme koeteltua valmismateriaalia, jonka avulla pääsemme nopeasti liikkeelle.