Tämä on osa blogisarjaa, jossa fokuksessa on arkkitehtuurityön anatomia, kokemukset ja havainnot vuosien varrelta. Havaintoja ja kokemuksia on kerätty arkkitehtuurin parissa töitä tekeviltä – yleensä ihmisiltä - erilaisissa kekkereissä, työkokouksissa, kahvipöytäkeskusteluissa ja joskus (ennen koronaa!) myös huurteisen äärellä. Blogisarjan nimeksi valikoitui luontevasti fraasi ’Miten meni noin niin kuin omasta mielestä’. Tervetuloa mukaan arkkitehdin ruumiin- ja mielenavaukseen!
Pitkästä aikaa päätin taas tarttua kynään (=näppikseen) ja ryhtyä pistämään ylös kokemuksia vuosien varrelta. Lupailin edellisessä blogissa, että kerron jossain vaiheessa myös ratkaisuarkkitehdin tehtävistä. Jostain syystä aihe on nyt mielenpäällä, joten siitä siis tarinaa tällä kertaa.
Ratkaisuarkkitehti ja projektin vastuuarkkitehti (se merelle lähtevä Mikki Hiiri)
Ratkaisuarkkitehti on arkkitehti, joka nimetään tiettyyn hankkeeseen tai projektiin ns. vastuuarkkitehdiksi. Hänen tehtävänään on varmistaa, että hanke/projekti tuottaa tarkoituksenmukaiset kuvaukset ja ne käsitellään asianmukaisella tavalla. Esimerkiksi että tehdään organisaation sovittujen menettelyjen mukaiset kuvausten katselmoinnit ja käsittelyt, annetaan tarvittaessa arkkitehtuurilausunto ja niin edelleen.
Isommassa hankkeessa tai projektissa vastuuarkkitehdin lisäksi mukana saattaa olla muitakin ratkaisuarkkitehtejä. Tällöin kuvausvastuut voidaan jakaa vaikkapa arkkitehtuurinäkökulmittain; esimerkiksi vastuuarkkitehti tuottaa toiminnan ja tietojen kuvaukset, tietojärjestelmäarkkitehti tuottaa järjestelmä- ja teknologiakuvaukset. Vastuuarkkitehti valitaan yleensä sen mukaan, minkä osa-alueen kuvauksilla on suurin painoarvo projektissa, eli vastuuarkkitehti ei ole aina jonkin tietyn arkkitehtuurinäkökulman arkkitehti. Esimerkiksi prosessikehitys projektissa suurin painoarvo on toiminnan kuvauksilla, alustamigraatioprojektissa taas fokus on järjestelmä- ja teknologiakerroksessa.
Lähdetäänpä siis iloisesti laulellen merelle!
Merihätään joutumisesta ja karikoista
Vastuuarkkitehdin tehtävät - ja haasteet - vaihtelevat todella PALJON riippuen toimintaympäristöstä sekä kyseessä olevan hankkeen tai projektin laajuudesta. Näin ollen vastuuarkkitehti joutuu navigoimaan erilaisten karikoiden ohi tai yli tavalla tai toisella. Seuraavassa on kuvattu yleisimmät vastaantulevat vaaranpaikat.
Karikko 1 - arkkitehtuurityön legitimiteetti
Jos toimintaympäristö on arkkitehtuurin näkökulmasta kovin matalalla maturiteettitasolla, niin vastuuarkkitehdin ensimmäinen ja tärkein tehtävä on valitettavasti arkkitehtuurityön legitimiteetin varmistaminen ja arvon ”todistelu”. Tämä tarkoittaa käytännössä siis sitä, että osoitat jollakin tavalla arkkitehtuurityön hyödyt. Varsinkin jos päättävissä rooleissa olevilla henkilöillä ei ole aiempaa kokemusta arkkitehtuurista, saatat päätyä jopa sellaiseen absurdiin tilanteeseen, että joudut käyttämään hyötyjen osoittamiseen enemmän työaikaa kuin varsinaiseen arkkitehtuurityöhön. Ilman mitään takeita siitä, että varsinaiseen arkkitehtuurityön tekemiseen päästään missään vaiheessa. Fiilis on sama kuin – no, kaarnalaivassa myrskyisellä merellä.
Jos (toivottavasti kun) onnistut saamaan arkkitehtuurityölle legitimiteetin, niin seuraava tehtävä on muodostaa jonkinlainen malli siitä, miten arkkitehtuurityö asemoituu hankkeen/projektin muuhun tekemiseen ja johtamiseen.
Mallin tekemiseen ottaisin kaksi lähtökohtaa: varovaisuus ja yksinkertaisuus. Varovaisuus siinä mielessä, että arkkitehtuurin roolia tukitoimintona ei voi riittävästi korostaa: arkkitehti on asiantuntija, ei johtaja. Anna siis johtajien huolehtia päätöksenteosta, mutta varmista että arkkitehtuurityön kautta johtajat saavat hyödyllistä tietoa oikea-aikaisesti päätöksenteon pohjaksi. Toisaalta hallintamalli kannattaa pitää niin yksinkertaisena kuin mahdollista, jotta a) arkkitehdit itse tietävät mitä heiltä odotetaan ja b) päätöksentekijät tietävät mitä voivat odottaa arkkitehtuurityöltä.
Jos / kun toimintaympäristössä on vakiintunut kehittämisen toimintamalli ja arkkitehtuurityön asema on vakaa, niin onnittele itseäsi ja tartu seuraavaan tehtävään.
Karikko 2 – hyödyllisten kuvausten tunnistaminen
Kun vihdoin pääset aloittamaan kuvausten tekemisen, on edessä kaikkein vaikein tehtävä eli tarpeellisten kuvausten tunnistaminen. Ratkaisuarkkitehtuurin kuvausten tekemiseen ei ikävä kyllä ole olemassa valmista ”keittokirjaa”, vaan tarvittavat kuvaukset riippuvat projektin tai hankkeen laajuudesta ja sisällöstä. (Yksinkertaisuuden vuoksi puhun jatkossa projektista.) Tämä tietysti edellyttää, että sinun on perehdyttävä joskus aika laajastikin siihen mitä projektissa ollaan tekemässä, mitä tavoitteita projektille on asetettu ja millaiseen kontekstiin tuotettava ratkaisu sijoittuu. Ikään kuin perehtymisen sivutuotteena sinulle kerääntyy ymmärrys, jota voit hyödyntää niin sanotun asemointikuvan tuottamisessa. Asemointikuva on oikeastaan ainoa kuvaus, joka kannattaa sisällyttää jokaiseen ratkaisuarkkitehtuurin kuvaukseen. Lyhyesti sanottuna siihen kuvataan mihin projekti vaikuttaa suhteessa nykytilaan: mihin toimijoihin, palveluihin, prosesseihin, tietoihin tai tietojärjestelmiin kohdistuu vaikutuksia. Joskus tietysti voi olla vaikutuksia myös teknologioihin, silloin luonnollisesti kuvataan myös se. Pääsääntöisesti projektin asemointikuva mahtuu yhteen kaavioon, joitakin poikkeuksia tosin on (esimerkiksi todella iso kehityskokonaisuus).
Asemointikuvan tuottamiseen jälkeen homma muuttuukin hankalammaksi. Mitä kannattaa kuvata tavoitetilasta? Helppo vastaus tietysti olisi, että kuvataan kaikki. Se ei kuitenkaan ole tarkoituksenmukaista, sillä kaikkien tuotettavien kuvausten pitäisi tuottaa jotakin selkeää lisäarvoa. Esimerkiksi aika harvoin tuottaa mitään lisäarvoa kuvata nykyisen tietojärjestelmän sisäistä rakennetta tai toiminnallisuuksia hyvin tarkalla tasolla, jos tietojärjestelmään rakennetaan projektin myötä uusi rajapinta. (Ja sitä paitsi olemassa olevien tietojärjestelmien yksityiskohtaiset kuvaukset pitäisi löytyä muualla ylläpidetystä järjestelmädokumentaatiosta.)
Miten sitten tunnistaa tarvittavat, lisäarvoa tuottavat kuvaukset? Joskus se voi olla hyvinkin suoraviivaista, esimerkiksi prosessikehitys -projektissa kannattaa kuvata miten tavoitetilan prosessit suhteutuvat toisiinsa, mitä palveluita prosesseilla tuotetaan ja vaikkapa mikä on prosessien automatisoinnin aste tavoitetilassa. Joskus tunnistaminen voi olla erittäin haastavaa. Esimerkiksi jos tuotettava ratkaisu on erittäin monimutkainen ja kompleksinen, voi olla vaikeaa tunnistaa mistä kuvaustyö kannattaisi aloittaa. Tunnistamisessa auttaa yleensä kokemus; kun tiedät minkä tyyppisistä kuvauksista on aiemmin ollut hyötyä, pystyt paremmin arvioimaan mitä kuvauksia luultavasti kannattaisi tällä kertaa tehdä. Varaudu kuitenkin tekemään tarvittaessa korjausliikkeitä, sillä jos kuvaus alkaa tuntua hyödyttömältä, kannattaa sen tekeminen keskeyttää mieluummin aiemmin kuin myöhemmin.
Tarvittavien kuvausten tunnistamiseen voi olla järkevää hankkia sparrailutukea, joko oman organisaation muilta arkkitehdeiltä tai konsultilta. Konsulteilla voi olla paitsi enemmän kokemusta, myös tuoreempi ja ikään kuin ulkopuolisen näkökulma projektin sisältöön ja laajuuteen.
Karikot 3–n – muita vastaantulevia haasteita
Ratkaisuarkkitehti kohtaa tyypillisesti muitakin kuin mallintamiseen liittyviä haasteita. Monien haasteiden juuret juontuvat arkkitehdin roolista; arkkitehti menee projektiin mukaan ”yhdeksi käsipariksi” ja osaksi projektiryhmää. Tämä tarkoittaa sitä, että projektipäälliköllä on tietynlaista käskyvaltaa suhteessa arkkitehtiin. Onkin aika tyypillistä, että projektipäällikkö ryhtyy antamaan arkkitehdille myös muita kuin arkkitehtuurityöhön liittyviä tehtäviä – erityisesti jos arkkitehti on osoittautunut aikaansaavaksi ja ahkeraksi. Olisikin hyvä sopia selkeästi, mitä projekti odottaa arkkitehdiltä ja mitä arkkitehti projektilta. Toki niin sovittaessa arkkitehti voi tehdä muutakin kuin arkkitehtuurityötä.
Joskus projektipäällikkö voi ottaa myös hyvin vahvasti kantaa siihen, mitä ja minkälaisia kuvauksia hän haluaa tuotettavaksi. Esimerkiksi projektipäällikkö voi haluta hyvin yksityiskohtaiset kuvaukset lomakkeiden tietosisällöistä, vaikka tosiasiallisesti tietosisällöt kannattaisi kuvata mallinnusvälineen sijasta vaikkapa Excelillä. Arkkitehdillä voi olla suuri houkutus suostua näihin vaatimuksiin (arkkitehdithan oikeasti tykkäävät tehdä kuvauksia), vaikka kuvausten tuottaminen ei olisi tarkoituksenmukaista.
Edellisten lisäksi ratkaisuarkkitehti kohtaa ”niitä tyypillisiä juttuja” eli yrittää jotenkin estää erilaisten purkkaviritysten syntymistä, sooloiluja ja osaoptimointia.
Mutta huoli pois – kyllä se Suomenjoutsen jossakin muodossa, jossain vaiheessa saapuu auttamaan ja taas laulu soi!
Kas noin Suomenjoutsen käy auttamaan
Ja nyt laulu soi taas näin:
"Hiuli hei, huolta nyt ei
Merimies näin käy merta päin
Hiuli hei, merimies ei
Pelkoa siis tunne ei!"
(Mikki Hiiri merihädässä, lähde: LyricFind)
Taustatietoa ratkaisuarkkitehtuurista
Ehkä on paikallaan myös lyhyt taustoitus tässä kirjoituksessa käytetyistä termeistä, jos ratkaisuarkkitehtuuri ei ole sinulle ennestään tuttu termi.
Noudattamassani ajattelumallissa arkkitehtuuri jaetaan kahteen tasoon: kokonaisarkkitehtuuriin ja ratkaisuarkkitehtuuriin. Kokonaisarkkitehtuuri on ylemmän tasoista ja nimensä mukaisesti kokonaisvaltaisempaa; tyypillisesti esimerkiksi kokonaisarkkitehtuurin nykytilan kuvaukset kattavat koko organisaation ja kaikki arkkitehtuurinäkökulmat. Sanomattakin lienee selvää, että tällöin kokonaisarkkitehtuurin kuvaukset eivät voi olla hyvin yksityiskohtaisella tasolla – ainakaan jos ne halutaan saada joskus valmiiksikin.
Ratkaisuarkkitehtuuri puolestaan kuvaa tietyn ratkaisun ja sen implementoinnin. Tällöin yleensä tarvitaan yksityiskohtaisempia kuvauksia, toki kuvattavasta ratkaisusta ja sen laajuudesta riippuen. Esimerkiksi joskus voi olla tarpeen kuvata tavoitetilan prosessit melko tarkalla tasolla, jotta kehitystiimi pystyy suunnittelemaan prosesseja parhaiten tukevan tietojärjestelmän. Tai joskus joudutaan kuvaamaan tietosisältöä ihan attribuuttitasolle saakka, esimerkiksi jos ollaan rakentamassa integraatiota keskitettyyn viranomaisrekisteriin, jonka tietosisältö on hyvin vahvasti standardoitua ja säädeltyä.
Lue lisää: kokonaisarkkitehtuuri.fi