Kokonaisarkkitehtuurin muutos

Useista eri lähteistä voimme todeta, että kokonaisarkkitehtuurin tulee muuttua osallistuvammaksi. Kokonaisarkkitehtuuri ei ole ollut varsinainen menestystarina suomen julkishallinnossa, kuten Katja Penttinen väitöskirjassaan osoittaa (“The long and winding road of enterprise architecture implementation in the Finnish public sector”, 19.12.2018, Jyväskylän yliopisto, linkki). Yksityisellä sektorilla kokemukset ovat olleet niin ikään vaihtelevia. Kokonaisarkkitehtuurin ongelmien juurisyy liittyy sen erillisyyteen: kokonaisarkkitehtuuri on usein liian irti johtamisesta ja käytännön kehittämisestä, se on liian laaja, liian vaikeaselkoinen ja monimutkainen, liian irti arjesta – liian epäkäytännöllinen.

Kokonaisarkkitehtuurin muutos mahdollistuu siten, että kokonaisarkkitehtuuritoiminto kytketään osaksi muuta kehittämistoimintaa. Arkkitehtitiimistä muodostetaan ketterä toimija, jonka kaikki tekeminen tehdään näkyväksi, ja arkkitehdit osallistetaan käytännön kehittämistoimintaan yhdessä muiden roolien kanssa. Arkkitehtuurista tehdään käytännönläheistä kuvausvälineen hyödyntämisen avulla: kaikki kehittämisasiat kuvataan jollain tarkkuustasolla keskitettyyn kuvauskantaan, josta ne tehdään näkyväksi jatkuvan julkaisun periaatteen mukaan. Arkkitehtuurin vastuulla on siten tarjota kokonaiskuva organisaation toiminnasta ja rakenteesta, eli kokonaisuuden tilannekuva. Tämä näkymä alkaa toimia “organisaation digitaalisen kaksosen” (Digital Twin of an Organization, DTO) alustavana versiona. Aivan ensiksi on kuitenkin syytä määritellä koko kehittämisen toimintamalli eli kehittämismalli uudelleen, ja kuvata se välineeseen kaiken jatkokehittämisen pohjaksi. Ajanmukaista on määritellä kehittämismalli arvoketjuksi, jossa korostuu asiakasarvon tuottaminen.

Kokonaisarkkitehtuurin uudistaminen ja case Vantaa

Eräs kokonaisarkkitehtuurin modernisointitoteutus on tehty Vantaan tietohallinnossa, joka alkoi tuottamaan hyötyjä varsin nopeasti. Siellä kokonaisarkkitehtuuri integroitiin osaksi kehittämismallia, jossa kaiken toiminnan perustana on asiakasarvon tuottaminen.

Kehittämismalli.

Kaikki tietohallinnon toiminnot kytkettiin osaksi Plan-Build-Run -pohjaista “Ideasta-tuotantoon” -arvoketjua, mikä tehosti huomattavasti aikaisemmin niin siiloutunutta organisaation kehittämisen toimintamallia eli kehittämismallia. Ketjun läpinäkyvyyttä parannettiin moderneilla käytännöillä ja työkaluilla, joita poimittiin soveltaen eri viitekehyksistä ja menetelmistä. Lean-filosofian ja ketteryyden piirteitä sisäänrakennettiin malliin, ja sivutuotteina saavutettiin mm. parempaa asiakastyytyväisyyttä, laatua ja näkyvyyttä kokonaisuuteen. Keskeiseksi toimijaksi perustettiin moniammatillinen virtuaalitiimi (Ratkaisutoimisto), jossa eri asiantuntijat yhdessä alkoivat ratkaisemaan ideoista kehittämiskelpoisia konsepteja.

Kokonaisarkkitehtuurin rooli ja merkitys muuttui eniten. Alettiin puhumaan lyhyesti vain “arkkitehtuurista”, kun kaikkia kehittämiskohteita visualisoitiin sopivasti ja tarkasteltiin jatkuvasti täydentyvää kokonaisuuden tilannekuvaa vasten. Tilannekuvaa alettiin systemaattisesti ylläpitämään asianmukaisessa kuvausvälineessä, johon luotu jäsennysmalli tuki Ideasta-tuotantoon -arvoketjua. Kaikki, suunnittelu, muotoilu, kehittäminen ja palvelutuotannon palvelut saatiin samaan kuvausvälineeseen, jonka selainpohjaisen portaalikäyttöliittymän kautta kaikki pääsivät jatkuvasti näkemään “mitä tapahtuu todella”, miten ideoista jalostuu kehittämiskohteita tuotantoon. Arkkitehtuuria alettiin kuvaamaan vain tarvelähtöisesti (just in time) ja vain riittävästi (just enough), sitä ei tehty enää varastoon (just in case). Tarpeeton etukäteissuunnittelu (Big Design Up Front, BDUF) minimoitiin, päätöksentekoa yksityiskohdista annettiin ja lykättiin kehitystiimeille, jossa varsinainen toteutustekninen osaaminen on. Arkkitehdit alkoivat toimimaan ketteränä, itseohjautuvana tiiminä (kuten muutkin tiimit). Ja kun arkkitehdit osallistuivat moniammatilliseen tiimiin Ideasta-tuotantoon -arvovirran alkuvaiheessa, tarvittavat kuvaukset tehtiin jo varhaisessa vaiheessa.

Arkkitehtien kuvausvälineessä ylläpitämä arkkitehtuurin tilannekuva tarjosi kokonaiskuvan organisaation toiminnasta ja rakenteesta, sekä riippuvuussuhteista eri elementtien välillä. Tämä auttoi arvioimaan mm. muutosvaikutuksia, mahdollistamaan tietoturvan, riskien ja arkkitehtuurinmukaisuuden huomioimisen heti alusta alkaen – ei vasta joskus myöhemmin erikseen. Näin kehittämiskohteisiin saatiin sisäänrakennettua laadun valvonta, eikä erillisiä jälkeenpäin suoritettavia katselmointeja enää tarvittu.

Arvoketju.

Kokonaisuuden arkkitehtuuri, tilannekuva, alkoi kasvamaan pala palalta (tetris pelin tyylisesti blokkeina). Kokonaisarkkitehtuuria tehtiin pieninä osakokonaisuuksina (slice), joissa kussakin huomioidaan toiminta, tiedot, järjestelmät ja teknologiat kerralla. Tällainen osakokonaisuus voi olla esimerkiksi yksi järjestelmäkokonaisuus, jonkin yksikön muodostama kokonaisuus kuten digisuunnitelma tms. Kokonaisuuden arkkitehtuuria ei tehty lähtökohtaisesti “kerroksittain” näkökulmapohjaisesti (toiminta, tieto, järjestelmä, teknologia), ellei se nimenomaan ollut asiakastarve, kuten liiketoimintayksiköiden palvelu- tai prosessikarttojen läpikäynti. Kun kaikki tekeminen alkoi virtaamaan Ideasta-tuotantoon -prosessin läpi virtuaalitiimin kautta, saatiin kokonaisnäkyvyys kaikkeen tekemiseen. Kaikki työ ja tuotokset alkoivat olla näkyvissä, jatkuvasti ja ajantasaisesti. Tämä näkyvyys auttoi johtoa hallitsemaan kokonaiskehittämistä, ja asiantuntijoita toimimaan paremmin yhteistyössä. Kuvausvälineen hyödyntäminen oli aivan keskeistä, siitä tuli kaikkien yhteinen väline kommunikaation tueksi.

Case Vantaan kehittämismallin ja siihen integroidun arkkitehtuuritoiminnon tekee erityiseksi käytännönläheisyys. Vaikka Vantaan malli tukee ketteriä ja muita menetelmiä sekä viitekehyksiä (kuten SAFe, IT4IT, DevOps), Vantaan mallin erityispiirre on eri toimintojen, kuten arkkitehtuuritoiminnon, osallistuminen ja yhteistyö, sekä kuvausvälineen aktiivinen hyödyntäminen. Vantaan parhaita oppeja ovatkin juuri yhdessä tekeminen ja asioiden näkyväksi tekeminen. Kokonaisuus ja sen arkkitehtuuri konkretisoituu kuvausten kautta. Visualisointi tekee näkyväksi organisaation toiminnan ja rakenteen, ja auttaa eri rooleissa toimivia jakamaan yhteisen käsityksen. Kuvaamiseen tarvitaan pelisäännöt ja kurinalaisuutta, mutta kaikki voidaan tehdä yksinkertaisesti ja helposti, kun on sovittu yhdenmukainen kuvaustapa ja vallitsee yhdessä tekemisen meininki.

Merkittävin muutos Vantaalla koskee kehittämisen toimintamallia eli ”kehittämismallia”. Ideasta-tuotantoon -prosessi on se varsinainen pihvi. Siihen liittyy kaikki keskeiset toimijat ja roolit organisaatiossa, välittömästi tai välillisesti. Vantaan kehittämismalli on johdon omistuksessa, kehittämismallin kehittämisestä ja käytännön toiminnasta vastaa erityinen fasilitaattori-rooli (Lean Manager, “Scrum Masterien Scrum Master”).

Ideasta-tuotantoon.

Asiakaskeskeisyys näkyy Ratkaisutoimiston toiminnassa, sillä tärkeimmät roolit ovat ns. asiakasvastaavilla. He tuovat viestiä asiakasyhteistyöstä ja liiketoiminnan tarpeista. Ratkaisutoimisto ei ole siis millään muotoa “arkkitehtuuritoimisto”. Ideasta-tuotantoon -prosessi on asiakas- ja kehittämislähtöinen, ei arkkitehtuurilähtöinen. Kokonaisarkkitehtuuri on tukifunktio, joka sai merkittävän roolin kokonaisuudessa, kun se aikaisemmin oli lähes hyödytön ja lopettamisuhan alla. Kokonaisarkkitehtuurin tilanne (rooli ja merkitys) muuttui, koska kokonaisarkkitehtuuritoiminto muuttui: se alkoi osallistumaan käytännön työhön ja tuottamaan konkreettisia tuotoksia (business outcome), joilla on välitön liiketoiminnallinen hyöty. Kokonaisarkkitehtuuritoiminnon pääasiallisena vastuuna on kokonaisarkkitehtuurin hallinta (Enterprise Architecture Management, EAM), ja käytännön kehittämistoimintaan osallistuminen. Vantaan muutoksessa yhdistyy kaksi erillistä asiaa: 1) arvovirtapohjaisen Ideasta-tuotantoon kehittämismallin ja 2) kokonaisarkkitehtuuritoiminnon uudistukset.

Case Vantaa pähkinänkuoressa

1. Ongelma lähtötilanteessa

  • asiakkaan tarpeiden huomioiminen puutteellista
  • kehittämistoiminta siiloutunutta, ei kokonaisuuden hallintaa, päällekkäisiä ratkaisuja, osaoptimointia, ennakoimattomia ja yllättäviä tilanteita kuten teknisen tuen päättyminen, “tulipalojen sammuttelua” jne.
  • johto (kaupungin) ja toimialat (liiketoimintayksiköt) tyytymättömiä tietohallinnon toimintaan, tietohallinnon johto tyytymätön organisaatioon ja kehittämismalliin sekä KA-työhön: ei selkeää kokonaiskuvaa palveluista, prosesseista, tiedoista, järjestelmistä, teknologioista
  • KA-toiminnon rooli, merkitys ja hyöty kyseenalainen, norsunluutornissa puuhastelua, seminaareihin ja verkostoihin osallistumista, vähän tai ollenkaan konkreettisia tuotoksia, pitkä lista ylätason periaatelinjauksia ilman käytännön hyötyjä, arkkitehtuurikatselmointeja jälkikäteen, erillistä toiminta-arkkitehtuurityötä ilman kosketuspintaa varsinaisiin ratkaisuihin järjestelmä- tai teknologiatasoilla, “powerpoint-arkkitehtuuria ja Exceleitä”.

2. Muutos

  • asiakasarvon luominen otettiin lähtökohdaksi kaikessa kehittämisessä ja tekemisessä: aina voidaan esittää kysymys, maksaisiko asiakas tästä?
  • perustettiin ”virtuaalinen moniammatillinen tiimi”, Ratkaisutoimisto, käsittelemään keskitetysti kaikki ideat (sprintit, backlogit, työnohjaus Kanbanit). Ammattitaitoiset asiakasvastaavat alkoivat ansiokkaasti tuomaan toimialojen ideoita ja tarpeita ns. asiakasvuoropuhelun kautta Ratkaisutoimistoon, jossa näistä tarpeista alettiin yhdessä tekemään ratkaisuehdotuksia eli ratkaisukonsepteja
  • kehittämismalli ”muotoiltiin uudelleen” “Ideasta-tuotantoon” -arvoketjuksi, ja siihen kytkettiin organisaation toiminnot
  • kehittämismallin käytännön toiminnan organisointiin valjastettiin erityinen rooli, ”Lean Manager”, jonka vastuulla on kehittämismallin käytännön toiminta, kehittäminen ja viestintä, sekä Ratkaisutoimiston fasilitointi, ja ”suhdetoiminta” organisaation toimijoihin kuten johtoon, kehittämisestä vastaaviin tahoihin ja eri ohjausryhmiin. Lean Managerina on toiminut alusta alkaen Goforen Juha Mustonen, joka on paitsi vastannut kehittämismallin johtamisesta, kehittämisestä ja käytännön toiminnasta kokonaisuudessan, myös tuonut organisaation operatiiviseen toimintaan johtajuutta ja tulosorientoitunutta tekemisen mallia henkilökohtaisten ominaisuuksiensa myötä
  • kokonaisarkkitehtuuritoiminto organisoitiin uudelleen ketteräksi tiimiksi, joka kytkettiin kehittämismalliin. Tässä vaiheessa tiimin vetäjänä ja pääarkkitehtina toimi allekirjoittanut
  • kuvausväline otettiin keskeiseen rooliin, kaikkea kehittämistä alettiin visualisoimaan, ammattimaisesti ja systemaattisesti yhteisesti sovittujen käytäntöjen mukaan (väline: Arkkitehtuuripankin tarjoama QPR EA mallinnuspalvelu, linkki)
  • kuvausvälineen käyttöönotossa, kuvauskannan (repositorion) hallinnassa, viitekehyksen viimeistelyssä ja käytännön mallintamisessa oli käytettävissä huippuluokan osaamista. Mm. QPR:n Ari Haaksiala toi mukanaan kokemusta, näkemystä ja monipuolista ammattimaisuutta – niin formaaliin mallinnukseen kuin arkkitehtuurin viestintään eri sidosryhmille. Arkkitehdeistä muodostui innostava ja inspiroiva tiimi, jonka tekemisen meininki kulminoitui luottamukseen ja toisten arvostamiseen
  • kehittämismalli mallinnettiin kuvausvälineeseen, jonka avulla muutoksesta voitiin viestiä helpommin, kun se tehtiin ”näkyväksi”. Kehittämismallin määrittely oli muutoksen toimenpanon edellytys. Tässä mielessä arkkitehtuuritoiminto ja kuvausväline olivat kehittämismallin muutoksen mahdollistajia, niistä muodostui kehittämismallin käytännön toiminnan ydin
  • kuvausvälineeseen muotoiltiin uusi, yksinkertainen ja selkeä viitekehys, koska JHS179-viitekehys koettiin vaikeaksi. Uusi modernisoitu viitekehys tuki suoraan kehittämisprosessia Ideasta-tuotantoon. Viitekehyksessä huomioitiin myös tärkeä ”johtamisen taso”, ei ainoastaan vain nämä: suunnittele/muotoile (Plan), kehitä/rakenna/hanki (Build) ja operoi (Run). Kuvausvälineen keskitetystä kuvauskannasta julkaistiin jatkuvasti kaikki tuotokset portaaliin, josta kaikki keskeiset sidosryhmät pääsivät näkemään kokonaisuuden on-line tilannekuvan jatkuvasti
  • kaiken perustaksi kristallisoitui asiakasarvon tuottaminen, jossa eräs monista ajatusmallien muutoksista kiteytyy tähän: ”stop talking architecture, start talking customer & business value!”

3. Lopputulos

  • johto ja toimialat olivat tyytyväisempiä, CIO tyytyväinen parantuneeseen asiakastyytyväisyyteen, asiakastarpeiden huomioimiseen ja arkkitehtuurin vaikuttavuuden paranemiseen, työntekijät olivat tyytyväisempiä roolien kirkastamiseen ja konkreettisia hyötyjä tuottavaan, palkitsevaan tekemiseen
  • kehittämismalli Ideasta-tuotantoon alkoi tuottamaan mitattavissa olevia hyötyjä läpivirtauksen hallinnan kautta
  • organisaation toimijoiden ja roolien vuorovaikutus parani lisääntyneen yhteistyön myötä
  • arkkitehtuuritoiminnosta tuli osallistuva ja hyödyllinen tukitoiminto, uudelleen organisoinnin jälkeen. Arkkitehtuuri ja tietoturva tulivat huomioiduksi heti kehittämiskohteiden alkuvaiheessa, kokonaisarkkitehtuurin tilannekuva tarjosi näkymän olemassa oleviin palveluihin ja järjestelmiin
  • muutoksen toteuttamisen kannalta ratkaisevaa oli johdon, erityisesti CIO:n, sitoutuminen, korkea vaatimustaso ja into Lean-filosofiaa ja ketteryyttä kohtaan. Rima oli asetettu korkealle (jos se joskus olikin ollut lattialla)
  • ainoa uusi asia koko kehittämismallin muutoksessa oli uusi fasilitaattori-rooli, Lean Manager, kaikki muut toimijat olivat jo olemassa – ne tuli vain organisoida toimivaksi kokonaisuudeksi, jossa informaatio liikkuu ja kehittäminen etenee hallittuna ja läpinäkyvänä virtana Ideasta-tuotantoon.
Ideasta-tuotantoon ja toimijat.

Havaintoja

Yleisenä havaintona ja Vantaan kokemuksiin perustuen voidaan todeta seuraavaa: kokonaisarkkitehtuurin rooli ja merkitys muuttuu selkeästi paremmaksi, kun se uudelleen organisoidaan osallistuvaksi ja käytännön kehittämistoimintaa suoraan tukevaksi toiminnoksi. Alla eräitä keskeisiä ”muutoksenjälkeistä” asiantilaa kuvaavia seikkoja:

  • arkkitehtuuri on tukitoiminto, joka osallistuu kehittämiskohteiden läpivientiin yhdessä muiden osaajaroolien kanssa moniammatillisen yhteistyön kautta. Tällöin syntyy jatkuvasti arkkitehtuurituotoksia asiakastarpeiden mukaan (vrt. SAFe:n ”Emergent Design”). Lisäksi arkkitehdit tekevät tarvelähtöisesti myös pitkäjänteistä suunnittelua (vrt. SAFe:n ”Intentional Architecture”). Molemmat tehtävät etenevät prosessissa tarvelähtöisesti, mitään “kammiotyöskentelyä” ei esiinny, osallistumisia selkeästi lisäarvoa tuottamattomiin seminaareihin ja tapahtumiin vähennetään tai lopetetaan kokonaan
  • asianmukainen kuvausväline on tärkeä mallintamiseen ja jatkuvaan julkaisuun, visualisoinnin avulla kehittämiskohteet tehdään paitsi näkyviksi, myös altistetaan arvioinnille: ymmärretäänkö asia samalla tavoin. Mallintamista tehdään ammattimaisesti, systemaattisesti ja tarkoituksenmukaisesti, noudatetaan hyviä mallinnustapoja ja yhdessä sovittuja käytäntöjä sekä kaaviotyyppejä, ja käytetään standardinotaatioita (ArchiMate, BPMN, UML)
  • arkkitehtuuria tehdään vain tarpeeseen (just in time), ei varastoon (just in case)
  • arkkitehtuuria kuvataan vain ”riittävästi” (just enough)
  • tarpeettomien raja-aitojen kaatamiseksi ja saman ”ammattikunnan” sisäisten näkökulmaerojen hälventämiseksi ei kannata puhua nimenomaisesti ”kokonaisarkkitehtuurista” (eikä varsinkaan kapea-alaisesti sen sisältöalueista: toiminta, tieto, järjestelmä, teknologia), vaan yleisemmin ”arkkitehtuurista”. Tai mieluimmin, vain ”kehittämisestä” – mikä laajentaa ajattelutapaa yli osaamisaluerajojen, siilojen, toimijoiden, tiimien, roolien, käytäntöjen – yhdessä tekemisen nimissä
  • palvelumuotoilua ja arkkitehtuuria on aloitetettu sovittamaan yhteen (aluksi ontuvin askelin), mikä asia on laajemminkin vielä ratkaisematta käytännössä
  • jatkossa eräs eniten huomionarvoinen alue onkin muotoiluajattelun ja arkkitehtuurin parhaiden puolien soveltaminen yhdessä siten, että lopputulos enemmän kuin kummallakaan lähestymistavalla olisi erikseen saavutettavissa. Tämä edellyttää yhdentymistä konkreettisten menetelmien ja välineiden tasolla – mutta ennen muuta ajattelutapojen ja kulttuuristen toimintatapojen tasolla.

Muutos käyntiin

Kokonaisarkkitehtuuri on hyödyllinen toiminto, asiat ovat oikeasti tärkeitä ja merkityksellisiä. Toteutustapa ei ole ollut oikea, sillä huikeista menestystarinoista kuulee harvemmin kuin epäonnistuneista, jotka on hiljaa ajettu alas. On kyllä tehty oikeita asioita, mutta asioita ei ole tehty oikein. Siksi kokonaisarkkitehtuurin muutos on matka, joka on syytä tehdä – syistä jotka mm. Penttisen väitöskirja nostaa esiin. Parhaiten se onnistuu aloittamalla pienin askelin.

Muutoksen käynnistämiseksi kannattaa ottaa oppia siitä, miten muissa organisaatioissa on menetelty. Näin voidaan vältellä sudenkuoppia, ja kopioida onnistuneita juttuja sekä valmiita malleja (kaikkea ei tarvitse keksiä itse). Olemme kirjoittaneet artikkelin Vantaan tarinasta kokoonpanolla Eero Hosiaisluoma, Katja Penttinen, Juha Mustonen ja Jukka Heikkilä. Artikkelin tarina voi toimia rohkaisevana esimerkkinä kokeilemaan muutosta. Artikkeli (”Lean Enterprise Architecture Method for Value Chain Based Development in Public Sector”, 2018, linkki) avaa kehittämismallin ja kokonaisarkkitehtuuritoiminnon muutosta, sen taustoja ja lopputuloksia.

Vantaan kaltaisia muutoksia on mahdollista saada aikaan kaikissa organisaatioissa, jos johdolla on rohkeutta ja osaamista tarttua ”muutoksen mahdollisuuteen” ja käynnistää se.

Eero Hosiaisluoma

P.S.

Miten kokonaisarkkitehtuuritoiminto muutetaan käytännössä, miten kuvausvälinettä hyödynnetään? Mm. näitä käsittelee seuraava kirjoitus…

Uusi suunta.
Jaa kirjoitus:
Social media & sharing icons powered by UltimatelySocial