Suomidigi

Kun JHS ei ole riittävän ketterää

Antti Ylä-Jarkko

Meillä Vantaan tietohallinnossa kulunut vuosi on ollut kehittämisen näkökulmasta katsottuna kiinnostavaa aikaa. Kuntasektori kokonaisuudessaan on isojen haasteiden ja muutosten edessä, ja kunnan digitaalisten palvelujen kehityksestä vastaavana joutuu koko ajan miettimään, kuinka nykyaikainen tietohallinto pystyy näihin haasteisiin vastaamaan. Olemmekin joutuneet usein miettimään kokonaiskehittämisen prosessiamme ja sitä, kuinka voisimme jatkuvasti parantaa tapaamme tehdä digitaalista palvelukehitystä.

Mielenkiintoista Vantaan esimerkissä on se, että meillä kokonaiskehityksen uudistaminen lähti liikkeelle nimenomaan arkkitehtuurista ja sen toimintamallin uudelleenorganisoinnista. Ketteryyden yksi ilmentymä on se, miten vaikutuksellista kehitys oikeasti on. Toisaalta taas kuntasektorin suurien järjestelmien ja vaikuttavien osallistujamäärien toimintaympäristössä nimenomaan arkkitehtuurin merkitys on iso. Miten se tukee kehittämisen tarvetta, osallistuen ja vaikuttaen?

Ratkaisutoimistolla liikkeelle

Vantaalla ensimmäinen askel kehittämisen ketteröittämisessä oli arkkitehtuurin jalkauttaminen ideoiden ja tarpeiden alkulähteille. Toiminnan organisoituminen toteutettiin Ratkaisutoimisto-konseptin lanseeraamisen kautta, jossa eri alojen asiantuntijat muodostavat virtuaalisen tiimin, joka ketteriä menetelmiä hyödyntäen prosessoi asiakastoimialojemme kehitystarpeet ja -ideat, ja tuottaa niihin asiakasvastaavien johdolla edelleen asiakaslähtöiset ratkaisuehdotukset. Ja vaikka toimintamallin kehittämisen näkyvimmät muutokset liittyvät ketterien menetelmien ja työkalujen käyttöönottoon, kuten esim. Scrum ja Kanban, silti kokonaiskehityksen taustalla on nimenomaan arkkitehtuurityössä tapahtunut muutos, joka on ollut hyvin suuressa roolissa kehitystä eteenpäin ajavana voimana. Valitsemallamme polulla toimintamallin kehityksen tulee olla jatkuvaa, ja olemmekin varsin joustavalla tavalla hyödyntäneet kehittämismallimme edistämisessä erilaisia viitearkkitehtuureja aina tarpeen mukaan, näistä esimerkkinä vaikkapa SAFe 4.0 ja IT4IT.

Ratkaisutoimisto-konsepti sinällään on ollut vain ensimmäinen askel muutoksen näkyväksi tekemisessä. Todellinen tavoite on toteuttaa koko prosessin ketteröittäminen; kehityksen koko kaari aina ideasta tuotannossa toimivaan palveluun asti. Tällöin yksittäisen prosessin muokkaamisen sijaan tarvitsemme välineitä ymmärtääksemme kehittämisen koko prosessikokonaisuuden, siinä olevat erilaiset vaiheet ja esimerkiksi niihin liittyvät erilaiset kyvykkyydet. Vasta tämän kokonaisuuden hahmottamisen kautta pääsemme käsiksi sellaisiin käsitteisiin kuten esimerkiksi palvelu- tai projektiportfolio hallintaan, tai ymmärrämme mistä kehittämispaketeista prosessimme rakentuu. Olemme nimenneet tämän kokonaiskehittämisen ketteräksi kokonaisarkkitehtuuriksi, ja käytämme siitä yksinkertaista nimeä Lean EA.

Kohti ketterää kokonaiskehittämistä

Yhtenä keskeisenä välineenä kehityksessämme on ollut valtiovarainministeriön tarjoama arkkitehtuuripankki. Keskitetty kuvauskanta kunnan kokonaisarkkitehtuurin mallintamiseksi on erinomainen lähtökohta. Se hyvällä tavalla sekä antaa mahdollisuuden kokonaisuuden kuvaamiseen, mutta myös varmistaa käytettyjen mallien yhteensopivuuden, yhdenmukaisuuden ja ristiriidattomuuden. Samoin tietenkin helpottaa, kun yksittäinen elementti tai toiminnallisuus tarvitsee mallintaa palveluun vain kerran.

Kuitenkin Lean EA:n yhteydessä yhdessä kehittäminen on törmännyt yhteen käytännön haasteeseen: Arkkitehtuuripankin käyttöliittymä ja rakenne pohjautuvat kuntien paljolti hyödyntämään JHS 179 standardiin, joka suoraan sanoen ei välttämättä ole ollut se kaikkein helpoin työväline kehittämisestä viestimiseen organisaatiossa. Se mikä arkkitehdistä oli loogista ja järjestelmällistä, saattoi muusta organisaatiosta vaikuttaa hivenen… no vaikeasti lähestyttävältä. Kuitenkin, jotta organisaation voisi oikeasti ymmärtää kokonaiskehittämisen prosessin, tulisi sen pystyä se myös käytettävistä välinestä näkemään.

Näistä lähtökohdista haastoinkin kehittäjämme pohtimaan, miten kokonaiskehittämisen prosessi, joka meillä siinä vaiheessa oli jo olemassa, saataisiin ymmärrettävämpään muotoon myös muulle organisaatiolle? Mielellään siten, että sekä asiakasnäkökulma ja prosessin ratkaisukeskeisyys olisivat keskeiset näkökulmat käyttämässämme arkkitehtuuripankin käyttöliittymässä. Näistä lähtökohdista haastoimme samalla koko JHS-maailman, ja loimme täysin omasta kokonaiskehittämisen lähtökohdasta uuden käyttöliittymän käyttämäämme arkkitehtipankkiin. Syntyi seuraava kokonaisuus:

Vantaan kehittämismalli VM:n yhteisessä arkkitehtuuripankissa

Kuva 1: Vantaan kehittämismalli VM:n yhteisessä arkkitehtuuripankissa

Uuden käyttöliittymän keskiössä on kokonaiskehittämisen prosessi aina ideasta tuotantoon asti, aivan kuten olemme oikeastikin organisoituneet tietohallinnossa. Alakerrasta löytyy mallinnettuna koko asiakaskuntamme toimialoittain jaettuna. Toimialojen rakenne on mallinnettu edelleen kerroksellisesti toimintanäkymiin, sovellusnäkymiin ja teknologianäkymiin. Yläkerta taas on varattu koko toiminnan johtamiseen, pitäen sisällään kaiken siinä tarvittavan informaation pitäen sisällään johdon tekemät suunnitelmat ja visiot, arvoja unohtamatta.

Käyttöliittymä itsessään noudattaa Vantaan omaan graafista ilmettä, joten se on mielestämme helpommin sekä lähestyttävissä, että myös omaksuttavissa. Palvelu myös noudattaa Lean EA:n mukaista filosofiaa hyvin siinä, että se rakentuu kehityksen edetessä koko ajan eteenpäin. Se siis ei ole vielä läheskään valmis, sillä yksittäisiä osia siitä mallinnetaan vain, jos olemme tekemässä ko. alueeseen liittyvää kehitystyötä yhdessä sisäisten asiakkaidemme kanssa. Eli kehittämismallimme elää ja kasvaa sitä mukaa kuin kehittämisen projektit etenevät.

Tavoitteet jatkossa?

Mitä tällä kaikella on sitten saatu aikaan? Ainakin sen, että kehitysprosessimme alkupää alkaa olla varsin lean. Uudet ideat ovat organisaatiolle hyvin näkyvissä, ja yksittäisistä asiakastarpeista syntyneet ratkaisuehdotukset, kuten esimerkiksi suun terveydenhuollon palvelujen digitalisointisuunnitelma, ovat jo etenemässä isoiksi kehittämishankkeiksi Vantaan kaupungissa. Tuleen ei kuitenkaan saa jäädä makaamaan. Meidän on pidettävä huoli siitä, että ketterä kehitys jatkuu hankkeiden koon kasvaessa, yhdessä kehittäen.

kokonaisarkkitehtuuriarkkitehtuuritietohallintoleanscrumkanban

3 kommentia

  1. Rauni Kudia:

    On ollut ilo olla mukana kehittämässä kehittämistiimin toimintaa ja tuoda arkkitehtuuri osaksi kaikkea kehittämistä. QPR välileenä on ollut arvokas lisä tässä työssä-

    Vastaa
  2. Petteri Jekunen:

    Onnittelut! Erittäin havainnollinen malli ja visualisointi. Erityisesti päätason kuva nostaa esiin kaikki tärkeimmät näkökulmat kokonaiskehittämiseen. Varsinaisen kehitystoiminnan – miten siirrytään jatkuvasti muuttuvasta nykytilasta kohti jatkuvasti muuttuvaa tavoitetilaa – tuominen näkyväksi päätasolle on todella hyvä ratkaisu. Vastaavasti KA:n/JHS:n sinänsä käyttökelpoiset näkökulmat ovat edelleen käytettävissä alemmilla kuvaustasoilla.

    Siellä KA-alikuvauksen päätasolla onkin sitten muutama silmään pistävä asia: kerrosnäkymä terminä ja kuvassa aika näkyvänä isona laatikkona – termi ei ole kovin kuvaava eikä auki klikkaminenkaan paljon auta; ehkä lisää selittäviä tekstejä?

    Tietonäkymä puuttuu. Mielestäni keskeisempi kuin teknologia, jonka voisi piilottaa sovellusnäkymän sisään.

    Vastaa
    • Eero Hosiaisluoma:

      Kiitokset kysymyksistä! Olen osallistunut tämän Lean EA -mallin kehittämiseen pääarkkitehtina, ja vastauksiani alla.

      Päätasolta avautuvat ”Operatiivisen toiminnan tilannekuvat” on rakenteeltaan muutettu kerroksellisiksi, ArchiMate-viitekehystä mukaillen (Biz, App, Tech). Tietonäkymä sisältyy toiminta- ja sovellusnäkymiin vertikaalisesti, siihen kuuluvat seuraavat näkymät (kehyksen oikeassa reunassa): ”Käsitteet”, ”Tiedot” ja ”Tietovarannot”. Näistä avautuvilla näkymillä voidaan kuvata käsitemallit, tietoryhmät ja tietomallit, sekä tietovarannot. Näitä hyödynnetään mm. toimintamalli- ja sovellusintegraatio kaavioissa.

      Kerrosnäkymät ovat kaavioita, jotka yhdistelevät em. kerrosten elementtejä – kulloisenkin tarpeen mukaan soveltaen. Kerrosnäkymä antaa siten mahdollisimman kattavan kuvan määrätystä kohteesta. Kun kuvauksia tehdään tarvelähtöisesti, kerrosnäkymissä voi olla koostettuna esimerkiksi jonkin määrätyn kehittämiskohteen toiminnallisia ja rakenteellisia elementtejä – tapauskohtaisesti juuri oleellisia asioita korostaen. Esimerkiksi voidaan kuvata tietyn toiminnan palveluiden kokonaisuuden asiakkaat ja muut toimijat sekä prosessit ja niitä tukevat sovelluspalvelut ja sovellukset, tai jonkin sovelluksen tai sovellusalueen kokonaisuuteen kuuluvat teknologiset ratkaisut.

      Vastaa

Kommentoi

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *