Kevyesti mutta tehokkaasti liikkeelle kokonaisarkkitehtuurityössä

”Kokonaisarkkitehtuuri, se vasta on mukavaa helppoa ja mukavaa työtä.” Kuinka usein olet kuullut tällaisen lausahduksen? En minäkään monesti, mutta siihen on syynsä.

Kokonaisarkkitehtuuri on vaikeiden, monimutkaisten asioiden usein abstraktia mallintamista, jolla pahimmillaan on hyvin vähän tekemistä oikean elämän kanssa. Vaikka kokonaisarkkitehtuuri onkin luonteeltaan vaativaa asiantuntijatyötä, on siinäkin tapoja päästä vähän vähemmällä. Tänään kirjoitan niistä.

Kokonaisarkkitehtuuria voidaan kuvata monella tavalla ja monesta syystä. Syyt voivat tulla organisaatioon kohdistuvista ulkoisista vaatimuksista (kuten tiedonhallintalaki julkisella sektorilla) tai sisäisestä halusta parantaa ja tehostaa organisaation kehittämistoimintaa.

Kokonaisarkkitehtuurin kuvaamista voi lähestyä kahdella tavalla:

1. Ottamalla käyttöön organisaatioon valmiin mallin (esim. TOGAF).
2. Soveltavan arkkitehtuurin kautta, jossa organisaatio itse määrittelee säännöt omalle arkkitehtuurilleen.

Valmis vai soveltava kokonaisarkkitehtuuri?

Molemmissa tavoissa toteuttaa kokonaisarkkitehtuuria on omat mahdollisuutensa ja haasteensa.

Valmis kokonaisarkkitehtuuri:

Valmiin viitekehyksen tai mallin käyttö tarjoaa luonnollisesti organisaatiolle valmiin mallin ja toimintatapoja arkkitehtuurin ylläpitämiseen ja kehittämiseen. Viitekehykset ovat alan asiantuntijoiden rakentamia ja niihin on todennäköisesti käytetty enemmän aikaa ja vaivaa, kuin organisaatio realistisesti voi käyttää ”kotitekoiseen” versioon. Valmiilla malleilla on myös vertaistukea ja muita käyttäjiä, joten apua ja tukea on helpompi löytää.

Kuitenkin myös geneerisen mallin sovittaminen omaan organisaatioon vaatii ajatustyötä, eli täysin ilman suunnittelua ei tässäkään tapauksessa päästä. Haasteeksi saattaa myös nousta se, etteivät valmiit rakenteet välttämättä jousta organisaation tarpeisiin. Valmiit mallit vaativat usein myös koulutusta oikeaoppiseen käyttöön.

👉  Lue lisää TOGAF-viitekehyksen hyödyntämisestä tästä.

Soveltava kokonaisarkkitehtuuri:

Soveltavalla arkkitehtuurilla on mahdollista rakentaa kevyempi ja ketterämpi tapa kokonaisarkkitehtuurin hallinnoimiseen. Tämä johtuu siitä, ettei ns. ”pakollisia” asioita ole, vaan organisaatio saa itse päättää mikä on sen oman toiminnan kannalta oleellista. Vähemmän arvokkaat dokumentoinnit ja kuvaukset voi siis helpommin jättää tekemättä, tai ainakin minimoida. Toki hyviä osia valmiista viitekehyksistä voi myös lainata osaksi omaa soveltavaa arkkitehtuuria.

Myös kolikon kääntöpuoli on mahdollinen, eli soveltavalla arkkitehtuurilla voi luoda myös huomattavan raskaita ja monimutkaisia toimintamalleja. Soveltava arkkitehtuuri vaatii siis kuitenkin myös suunnittelua ja opiskelua, jotta organisaation omaa toimintatapaa voi lähteä rakentamaan. Haasteeksi saattaa myös nousta ”puhtaan paperin pelko”, sillä valmista sapluunaa ei ole tarjolla.

”Vital Few”

”Vital few” on tilastollisesta laadunhallinnasta tuttu käsite, joka voidaan kätevästi selittää myös Pareto-periaatteen avulla: 20 % jostakin aiheuttaa 80 % jostakin. Esimerkiksi 20 % asiakkaista tuottaa 80 % liikevaihdosta. Tässä tapauksessa nimenomaan tämä 20 % on vital few, eli se muuttuja tai muuttujat joilla on suurin vaikutus lopputulokseen.

Samaa periaatetta voimme soveltaa myös kokonaisarkkitehtuuriin: 20 % dokumentaatiosta luo 80 % arvosta. On oleellista siis tunnistaa mitä 20 % tässä on, ja keskittää työtä niiden kuvaamiseen ja kehittämiseen. Näin voidaan varmistaa arvon tuotanto.

”Vital few”-asioiden tunnistaminen ja kuvaamisen aloittaminen voi olla oiva keino päästää liikkeelle kokonaisarkkitehtuurityössä. Olemme tämän jo Arterilla tehneet kehittäessämme Kokonaisarkkitehtuurin pikastartti -palveluamme. Tällöin päädyimme siihen, että eniten arvoa (todennäköisesti) tuottaa se, että kuvataan

• prosessit,
• palvelut ja
• tietojärjestelmät.

Ehkä nämä pätevät teidänkin organisaatiossanne?

Tunnista arvoa tuottava kokonaisarkkitehtuurin dokumentaatio

Dokumentaatio tuottaa arvoa silloin, kun sen lukijat saavat siitä hakemansa tiedon mahdollisimman vähällä vaivalla.

Dokumentaation arvoa voidaan mitata esim. sen

• käyttöasteella (lukeeko ohjetta kukaan koskaan),
• laadulla (estääkö ohje tekemästä kriittisiä virheitä) tai jopa
• kattavuudella (sisältääkö ohje kaiken oleellisen).

Etukäteen voi olla hankala tietää, onko jokin dokumentti tai kuvaus kirjoittamisen arvoinen. Esitän seuraavaksi viiden kohdan listan, jolla asiaa voi testata. Mikäli vastaat ”kyllä” ainakin yhden kysymyksen kohdalla, kannattaa harkita dokumentin tekemistä.

1. Vaatiiko jokin standardi, laki tai asetus, että täytyy dokumentoida?
2. Osaatko kuvitella tilanteen, jossa joku haluaa lukea syntyvän dokumentin?
3. Aiheuttaako dokumentoinnin puute työyhteisössä epävarmuutta tai sähläystä?
4. Onko dokumentointi tärkeää työyhteisön yhteisen ymmärryksen luomisen kannalta?
5. Onko dokumentointiin kuluva aika kohtuullinen siitä saataviin hyötyihin nähden?

Jos taas et saa yhtään kyllä-vastausta, ei dokumenttia todennäköisesti kannata kuvata.

Pohdi tarkkaan myös tiedon granulaarisuus eli hienojakoisuus – miten tarkkaan tarvitsee kuvata?

Dokumentoinnin ohjeistuksessa kannattaa myös pohtia kriittisesti sitä, mille tasolle tietoa halutaan kuvata ja kuinka hienojakoista tietoa dokumentaatio oikeasti tarvitsee.

Esimerkkinä toimikoon taulukkomuotoinen tietojärjestelmäsalkku. Jos salkussa on 50 tietojärjestelmää, josta kustakin on listattu 10 tietoa, tarkoittaa se yhteensä 500 ylläpidettävää tietokenttää. Yhden uuden tiedon lisääminen taulukkoon tarkoittaa heti 50 uutta tietokenttää lisää.

Kerran asiakas pohti, tulisiko heidän lisätä ohjelmiston käytössä oleva versionumero tietojärjestelmäsalkkuun. Esitin kysymyksen, kuka versioita seuraa ja käy päivittämässä tietoa salkkuun? Hetken hiljaisuuden jälkeen vastaus tuli: ”Ei kukaan”. Päätettiin, ettei versionumeroa ehkä kannata lisätä salkussa olevaksi tiedoksi.

Samaa problematiikkaa kannattaa harkita prosessien kuvauksessa: kuinka tarkalle tasolle prosesseja oikeasti kannattaa tunnistaa ja kuvata? Jossain vaiheessa mennään joka tapauksessa yksittäisten työohjeiden tasolle, joiden sisältöä tyypillisesti ei kannata toistaa prosessikuvauksissa.

Miten liikkeelle kokonaisarkkitehtuurissa?

Pääsette alkuun esimerkiksi seuraavilla askelilla.

1. Päättäkää, mitä kaikkea kuvaatte. Jos mahdollista, tehkää myös päätös siitä mitä kaikkea ette (ainakaan vielä) kuvaa.
2. Kuvatkaa yksi asia kerrallaan (esim. prosessit).
3. Miettikää, keiden kannattaa osallistua kuvaustyöhön. Yleensä he, jotka tietoa tulevat käyttämään, ovat hyviä valintoja.
4. Pitäkää säännöllisiä katselmointeja kuvatulle materiaalille, tavoitteena jakaa kuvaustyössä tulleet opit ja oivallukset.

Avuksi voi ottaa myös Arterin ARC-ohjelmiston. ARC on kokonaisarkkitehtuurin mallintamisen ja hallinnan työkalu. Se mahdollistaa organisaation rakenteiden ja niiden välisten yhteyksien kuvaamisen visuaalisesti. Ohjelmistoon on mahdollista saada myös valmiina sisältönä Arter Framework, kuvauspohja, joka mahdollistaa nopean liikkeellelähdön soveltavan arkkitehtuurin kanssa.

>> Tilaa ARC-demo ja kokeile työkalua ilmaiseksi.

Kaiken kaikkiaan soveltavan arkkitehtuurin ydin piilee kokeilemisessa ja siinä, että asioita uskalletaan jättää kuvaamatta. Kaikki kuvaustyö tulisi tehdä vain oikeaan tarpeeseen ja varastoon kuvaamista taas tulisi välttää.

Suosittelen sinulle:

👉 Mistä liikkeelle kokonaisarkkitehtuuri kuvauksissa | blogi
👉 Kokonaisarkkitehtuurin hallinta ARC-ohjelmistolla | blogi
👉 Sisäministeriön pelastusosasto – Strategialähtöinen toiminnan kehittäminen kokonaisuuden kuvaamisella | asiakastarina

Tämän blogitekstin on kirjoittanut Markus Meurman.