scieee AI-readable full text Open interactive document viewer

Kokonaisarkkitehtuurityön kehittäminen Keski-Suomen hyvinvointialueen ICT-projekteissa

Kaarnamo, Katri Maria,Rutanen, Anni Katariina

Full text

Katri Kaarnamo ja Anni Rutanen KOKONAISARKKITEHTUURITYÖN KEHITTÄMINEN KESKI-SUOMEN HYVINVOINTIALUEEN ICT-PROJEKTEISSA JYVÄSKYLÄN YLIOPISTO INFORMAATIOTEKNOLOGIAN TIEDEKUNTA 2024 TIIVISTELMÄ Kaarnamo, Katri Maria Rutanen, Anni Katariina Kokonaisarkkitehtuurityön kehittäminen Keski-Suomen hyvinvointialueen ICT- projekteissa. Jyväskylä: Jyväskylän yliopisto, 2024, 95 s. Tietojärjestelmätiede, pro gradu -tutkielma Ohjaajat: Halttunen, Veikko & Seppänen, Ville Tässä tutkimuksessa selvitettiin, miten kokonaisarkkitehtuuri tukee organisaatiomuutosta ja ICT-projekteja, sekä miten kokonaisarkkitehtuurityötä voisi kehittää Keski-Suomen hyvinvointialueen ICT-projekteissa. Tutkimuksessa pyrittiin tuottamaan selkeitä kehitysideoita kokonaisarkkitehtuurityön kehittämiseksi tulevaisuuden ICT-projekteja ajatellen. Tutkimuksessa yhdistettiin kirjallisuuskatsauksesta hankittua tietopohjaa sekä dokumenttianalyysin ja organisaation valituille henkilöille toteutettujen puolistrukturoitujen teemahaastattelujen havaintoja. Kirjallisuuskatsaus koostuu hyvinvointialueiden taustalla olevan soteuudistuksen esittelystä, kokonaisarkkitehtuurista ja sen viitekehyksistä sekä kokonaisarkkitehtuurin roolista organisaatiomuutoksissa ja ICT-projekteissa. Teemahaastatteluissa hyödynnettiin teoriapohjasta koostettua haastattelurunkoa. Teemahaastatteluita toteutettiin yhteensä 12 kappaletta, joiden lisäksi dokumenttianalyysissa käytiin läpi esimerkiksi kokonaisarkkitehtuurityön tuotoksia. Tutkimuksen tuloksena kerrotaan, että mitä suurempi organisaatiomuutos on kyseessä, sitä suurempi on myös kokonaisarkkitehtuurin merkitys sen tukemisessa. Lisäksi todetaan, että kokonaisarkkitehtuuri on kriittinen menestystekijä ICT- projektien onnistumisen kannalta. Tuloksista käy ilmi, että kokonaisarkkitehtuuri ja sen keinot ovat näkyneet useilla eri tavoilla ICT-muutoshankkeen aikana ja ICT-projekteissa. Lisäksi todetaan, että organisaation ICT-muutokset hyötyisivät monella tavalla kokonaisarkkitehtuurin ja sen keinojen paremmasta hyödyntämisestä. Tähän liittyen tutkimuksessa esitetään konkreettisia kehitysehdotuksia organisaatiolle. Asiasanat: kokonaisarkkitehtuuri, hyvinvointialue, julkinen sektori, ICT-projekti, organisaatiomuutos ABSTRACT Kaarnamo, Katri Maria Rutanen, Anni Katariina The development of Enterprise Architecture work in the ICT projects of Wellbeing Services County of Central Finland Jyväskylä: University of Jyväskylä, 2024, 95 pp. Information Systems Science, Master’s Thesis Supervisors: Halttunen, Veikko & Seppänen, Ville In this research the aim was to clarify how enterprise architecture can support organizational change and ICT projects as well as to study how enterprise architecture work could be developed in the ICT projects of Wellbeing Services County of Central Finland. The research strives to produce clear and concise development ideas to further develop the enterprise architecture work of future ICT projects. The research utilizes the knowledge gained from literature review and the information gained from document analysis and theme interviews. The literature review was conducted of the service structure reform of social welfare and health care, enterprise architecture and its frameworks and the role of enterprise architecture in organizational change and ICT projects. An interview frame composed of the literature review and theory base was utilized in the theme interviews. There were twelve theme interviews altogether that were supported by the document analysis consisting of for example enterprise architecture work outputs. As a result of the research, it is stated that the larger the organizational change, the larger is also the supporting role of enterprise architecture. It is also stated that enterprise architecture is a critical success factor for ICT projects to succeed. The results also indicate that enterprise architecture and its means have been visible in several ways during the ICT change project and the ICT projects. A pivotal statement also is that the organizations ICT projects would gain considerably of the more efficient and consistent utilization of enterprise architecture and its means. There are concrete development ideas regarding this statement in the end of the research. Keywords: enterprise architecture, wellbeing services county, public sector, ICT project, organizational change KUVIOT Kuvio 1 Hyvinvointialuekartta .................................................................................. 13 Kuvio 2 Alueellisen toimeenpanon tiekartta ........................................................... 14 Kuvio 3 Esimerkki Johtamisen ja osaamisen-valmisteluryhmän tehtäväkokonaisuuksista, tehtävistä ja osatehtävistä ............................................. 15 Kuvio 4 ICT-tiekartta .................................................................................................. 15 Kuvio 5 Arkkitehtuurin strategiatasot...................................................................... 18 Kuvio 6 Mukaillen TOGAF-kehityssykli ................................................................. 21 Kuvio 7 Mukaillen JHS 179 Arkkitehtuurikuvausten viitekehys ......................... 24 Kuvio 8 Kokonaisarkkitehtuurin suunnitteluprosessi ........................................... 25 Kuvio 9 Hyvinvointialueiden viitearkkitehtuurin keskeiset sisällöt ................... 27 Kuvio 10 Mukaillen The Lean Enterprise Architecture Framework LEAF ........ 28 Kuvio 11 Mukaillen LEAD-toimintamalli ylätasolla .............................................. 29 Kuvio 12 Mukaillen Liiketoiminta-arkkitehtuurin välittäjämäinen asema ........ 32 Kuvio 13 Julkisen hallinnon kokonaisarkkitehtuurin hallintamalli ..................... 34 Kuvio 14 TOGAF-viitekehyksen kokonaisarkkitehtuurin hallintamalli ............. 35 Kuvio 15 Mukaillen Kokonaisarkkitehtuurin haasteiden kategorisointi ............ 37 Kuvio 16 Mukaillen Tanskan hallinnon kokonaisarkkitehtuurin prosessimalli 41 Kuvio 17 Tavoitetilan määrittely ............................................................................... 49 Kuvio 18 Kokonaisarkkitehtuurin ja projektisalkun yhteensovittaminen tiekartan avulla ............................................................................................................................. 49 Kuvio 19 Mukaillen Kokonaisarkkitehtuurin vaatimustenmukaisuuden katselmointiprosessi .................................................................................................... 51 Kuvio 20 Mukaillen Keski-Suomen hyvinvointialueen ICT-muutoshankkeen kokonaisarkkitehtuurin hallintamalli ....................................................................... 61 Kuvio 21 Hyvinvointialueiden yhteisen viitearkkitehtuurin arkkitehtuuriperiaatteet .............................................................................................. 62 Kuvio 22 Kokonaisarkkitehtuurin kehitettävät osa-alueet ja toimenpiteet ........ 81 TAULUKOT Taulukko 1 Viitekehysten ja menetelmien vertailu ................................................ 30 Taulukko 2 Mukaillen Kokonaisarkkitehtuuriviitekehyksen valintakriteerit .... 42 Taulukko 3 Kokonaisarkkitehtuurin haasteet ja mahdolliset ratkaisut .............. 43 Taulukko 4 Haastateltavien roolit ............................................................................. 55 Taulukko 5 Dokumenttianalyysissä käytetty aineisto ........................................... 58 Taulukko 6 Esimerkki haastatteludatan analysoinnista ........................................ 59 Taulukko 7 Esimerkki havaintojen lukumäärän hahmotuksesta ......................... 59 Taulukko 8 KA:n osa-alueet ICT-muutoshankkeessa ............................................ 76 Taulukko 9 KA:n tason nostamisen osa-alueet ....................................................... 78 SISÄLLYS 1 JOHDANTO ........................................................................................................... 8 2 SOTE-UUDISTUS ................................................................................................ 12 2.1 Hyvinvointialueet ...................................................................................... 12 2.2 Hyvinvointialueiden alueellinen toimeenpano .................................... 13 3 KOKONAISARKKITEHTUURI ........................................................................ 16 3.1 Määritelmä ja strategiatasot ..................................................................... 16 3.2 Kokonaisarkkitehtuurin hyödyt .............................................................. 18 3.3 Kokonaisarkkitehtuurin viitekehykset ja menetelmät ......................... 19 3.3.1 TOGAF ............................................................................................... 20 3.3.2 Julkisen hallinnon kokonaisarkkitehtuurimenetelmä JHS 179 .. 23 3.3.3 Hyvinvointialueiden viitearkkitehtuuri ....................................... 26 3.3.4 Lean-kokonaisarkkitehtuurimenetelmä LEAD ........................... 27 3.3.5 Viitekehysten ja menetelmien vertailu .......................................... 29 3.4 Liiketoiminta-arkkitehtuuri julkisella sektorilla ................................... 31 3.5 Kokonaisarkkitehtuurin hallintamalli .................................................... 33 3.6 Kokonaisarkkitehtuurityön arviointi ...................................................... 35 3.7 Tyypillisimmät haasteet kokonaisarkkitehtuurin hyödyntämisessä . 36 3.8 Ratkaisuja kokonaisarkkitehtuuriin liittyviin haasteisiin .................... 39 3.9 Toimintaa ohjaava lainsäädäntö .............................................................. 44 4 KOKONAISARKKITEHTUURI ORGANISAATIOMUUTOKSESSA JA ICT-PROJEKTEISSA ..................................................................................................... 45 4.1 Organisaatiomuutos .................................................................................. 45 4.2 Kokonaisarkkitehtuuri osana ICT-projekteja ........................................ 47 4.2.1 Kokonaisarkkitehtuurikatselmoinnit ............................................ 49 4.2.2 Kokonaisarkkitehtuurin hyödyt projekteille ................................ 51 5 TUTKIMUKSEN TAVOITTEET, KOHDEORGANISAATIO JA MENETELMÄT ............................................................................................................ 53 5.1 Tutkimuksen tavoite ................................................................................. 53 5.2 Kohdeorganisaation esittely ..................................................................... 53 5.3 Tutkimuksen osallistujat kohdeorganisaatiosta .................................... 54 5.4 Näkökulmat ................................................................................................ 55 5.5 Tutkimusote ................................................................................................ 55 5.6 Haastattelut ................................................................................................. 56 5.7 Dokumenttianalyysi .................................................................................. 57 5.8 Aineiston analysointi................................................................................. 58 6 LÖYDÖKSET ....................................................................................................... 60 6.1 Dokumenttianalyysin löydökset ............................................................. 60 6.1.1 Kokonaisarkkitehtuurityön resursointi ........................................ 60 6.1.2 Kokonaisarkkitehtuurin hallintamalli ........................................... 61 6.1.3 Arkkitehtuurityön periaatteet ja linjaukset .................................. 61 6.1.4 Kokonaisarkkitehtuurityön tuotokset ........................................... 62 6.2 Teemahaastatteluiden löydökset ............................................................. 63 6.2.1 Haastateltavat ................................................................................... 63 6.2.2 Kokonaisarkkitehtuuri ICT-muutoshankkeessa .......................... 63 6.2.3 Kokonaisarkkitehtuuri ICT-projekteissa ...................................... 66 6.2.4 Miten kokonaisarkkitehtuuria voisi jatkossa hyödyntää ........... 69 7 POHDINTA ......................................................................................................... 74 7.1 Tutkimuksen tavoitteet ja vastaukset tutkimuskysymyksiin ............. 74 7.1.1 Kokonaisarkkitehtuurin rooli organisaatiomuutoksissa ja ICT- projekteissa ........................................................................................ 75 7.1.2 Kokonaisarkkitehtuuri ja sen keinot Keski-Suomen hyvinvointialueen ICT-muutoshankkeessa ja hyvinvointialueen käynnistymisvaiheessa .................................................................... 76 7.1.3 Kokonaisarkkitehtuurin kehitysehdotukset Keski-Suomen hyvinvointialueen ICT-projekteihin .............................................. 78 7.2 Tärkeimmät tulokset ................................................................................. 80 8 LOPUKSI .............................................................................................................. 82 8.1 Akateeminen ja käytännön merkitys ...................................................... 82 8.2 Rajoitteet ja luotettavuuden arviointi ..................................................... 83 8.3 Jatkotutkimus ............................................................................................. 83 9 LÄHTEET ............................................................................................................. 85 LIITTEET Ympärillä muuttuva maailma vaatii organisaatioilta valmiutta sopeutua ja toimia reaktiivisesti, jotta ne pystyvät palvelemaan asiakkaitaan ja saavuttamaan liiketoiminnan tavoitteet. Voidaan jopa sanoa, että muutokseen sopeutuminen on organisaatioiden selviytymisen edellytys. Organisaatiomuutokset ovat pieniä tai suuria rakenteellisia muutoksia, jotka täytyy tehdä, jotta organisaatio pystyy toimimaan tehokkaasti ja saavuttamaan strategiset tavoitteensa. Kokonaisarkkitehtuuri tarjoaa kokonaisvaltaisen lähestymistavan tällaisten suurten muutosten läpivientiin, sillä sen avulla organisaation eri näkökulmia voidaan tarkastella yhtenevällä ja johdonmukaisella tavalla (Hoogervorst 2004, 228–229). Lemmetti ja Pekkola (2012, 164) määrittelevät kokonaisarkkitehtuurin kokonaisvaltaisena tapana kuvata organisaation toimintaa sekä tuottaa suunnitelmia organisaation toiminnan kehittämiseksi kohti tavoiteltua visiota. Kokonaisarkkitehtuuri käsittelee edellä mainittuja seikkoja liiketoiminnan, tiedon, tietojärjestelmien ja teknologian näkökulmista (Lemmetti & Pekkola 2012, 164). Kokonaisarkkitehtuurin avulla pystytään johtamaan organisaatioiden toimintaa kokonaisvaltaisesti ja ennakoivasti niin, että organisaatio pystyy vastaamaan ulkoa tuleviin muutosvoimiin (Gartner, 2013). Kokonaisarkkitehtuuria hyödynnetään tänä päivänä niin yksityisen kuin julkisen sektorin organisaatioissakin. Tämän pro gradu-tutkielman aiheena on kokonaisarkkitehtuurityön kehittäminen Keski-Suomen hyvinvointialueen ICT-projekteissa. Tutkielman toimeksiantajana toimii Keski-Suomen hyvinvointialue (Hyvaks). Yksi Suomen merkittävimmistä hallinnollisista muutoksista tuli voimaan vuonna 2023, kun sote-uu- distuksen myötä sosiaali- ja terveydenhuollon ja pelastustoimen palveluiden järjestäminen siirtyi kunnilta ja kuntayhtymiltä 21 hyvinvointialueen vastuulle (Sosiaali- ja terveysministeriö, 2022a). Keski-Suomen hyvinvointialueen ICT-valmis- telu aloitettiin ICT-muutoshankkeessa syksyllä 2021 ja ICT-muutoshankkeen tehtävänä oli toteuttaa ICT-palvelut hyvinvointialueen tarpeisiin. Hanketyö pohjautui Sosiaali- ja terveysministeriön ja alueiden laatimaan alueellisen toimeenpanon tiekarttaan, jossa määriteltiin ICT-valmistelussa toteuttavat keskeiset tehtävät. Hyvinvointialueen valmisteluvaiheessa oli tärkeää varmistaa, että ICT- palvelut toimivat ongelmitta toiminnan käynnistyessä. ICT-muutoshankkeen 1 JOHDANTO 9 suunnittelun lähtökohtana oli, että hyvinvointialueen toiminta käynnistetään pääasiallisesti jo olemassa olevilla tietojärjestelmillä ja ICT-ratkaisuilla. (Keski- Suomen hyvinvointialue, 2022a; Sosiaali- ja terveysministeriö, ei pvm.) Ennen hyvinvointialueen aloittamista Keski-Suomessa on ollut hajautunut sosiaali- ja terveyspalveluiden järjestämisvastuu, sillä palvelut oli järjestetty Keski-Suomen 22 kunnan ja Keski-Suomen sairaanhoitopiirin toimesta (Terveyden ja hyvinvoinnin laitos, 2022, 5). Näin ollen Keski-Suomen hyvinvointialue on aloittanut toimintansa melko kirjavalla tietojärjestelmäkokonaisuudella, sillä joidenkin pääjärjestelmien osittaiskonsolidoinneista huolimatta Keski-Suomen alueen sosiaali- ja terveydenhuollon sekä pelastustoimen ICT-ratkaisut on järjestetty aiempien järjestäjien toimesta eri tavoin (Keski-Suomen hyvinvointialue 2021, 4, 7). Hyvinvointialueuudistukseen liittyvä ICT-muutos jatkuu Keski-Suomessa vielä pitkään, sillä hajanaisen kokonaisuuden yhtenäistäminen vaatii vielä paljon työtä. Näin ollen hyvinvointialueella on käynnissä ja käynnistymässä lukuisia ICT-projekteja, joilla pyritään yhteensovittamaan hyvinvointialueen tietojärjestelmiä, infrastruktuuria ja toimintaprosesseja. Toimeksiantajan kanssa käydyissä keskusteluissa nousi esiin tarve kehittää ICT-projektien kokonaisarkkitehtuurityötä, jotta kokonaisarkkitehtuurityötä saataisiin jalkautettua tiiviimmin osaksi ICT-projekteja ja kokonaisarkkitehtuurityön tasoa saataisiin nostettua. Kokonaisarkkitehtuurityön tason nostaminen nähdään tärkeänä asiana, jotta hyvinvointialueen toiminnan yhtenäistämistä ja kehittämistä saadaan tuettua ICT-projek- teissa, ja kokonaisarkkitehtuuri tarjoaa tähän tarkoitukseen hyödyllisiä keinoja. Tutkimusaihetta lähestytään ensin kirjallisuuden kautta, ja kirjallisuuskatsauksen avulla pyritään selvittämään, miten kokonaisarkkitehtuuri voi tukea organisaatiomuutosta ja ICT-projektien onnistumista. Tutkimuksen empiriaosuudessa selvitetään, miten kokonaisarkkitehtuuria on hyödynnetty Keski-Suomen hyvinvointialueen ICT-muutoshankkeessa ja hyvinvointialueen käynnistysvaiheessa. Näistä havainnoista pyritään johtamaan kehitysaskelia ja –ideoita, joita Keski-Suomen hyvinvointialueen ICT-projekteissa voisi tehdä kokonaisarkkitehtuuritason nostamiseksi. Tutkimusongelmasta on johdettu seuraavat tutkimuskysymykset: 1. Miten kokonaisarkkitehtuuri tukee organisaatiomuutosta ja ICT-projek- tien onnistumista? 2. Miten kokonaisarkkitehtuuri ja sen keinot näkyivät Keski-Suomen hyvinvointialueen ICT-muutoshankkeessa ja hyvinvointialueen käynnistysvaiheessa? 3. Miten kokonaisarkkitehtuuria ja sen keinoja voisi hyödyntää paremmin Keski-Suomen hyvinvointialueen ICT-projekteissa? Kokonaisarkkitehtuuria on käsitelty aiemmassa kirjallisuudessa jo varsin paljon, ja myös julkishallinnon kontekstissa kokonaisarkkitehtuuria käsitteleviä tutkimuksia on tehty useita. Ylinen ja Pekkola (2018, 1–2) ovat tehneet tutkimuksen, jossa julkisen sektorin IT-osasto käytti kokonaisarkkitehtuuria apuna 16 Tässä luvussa käsitellään tutkimuksen kannalta keskeistä ja läpileikkaavaa aihetta, kokonaisarkkitehtuuria. Aluksi pureudutaan kokonaisarkkitehtuurin teorioihin ja määritelmiin ymmärryksen kasvattamiseksi ja tarkastellaan kokonaisarkkitehtuurin avulla saavutettavia hyötyjä. Tästä siirrytään käsittelemään tutkimuksen kannalta relevantteja kokonaisarkkitehtuurin viitekehyksiä ja menetelmiä, kuten TOGAF:ia ja hyvinvointialueiden viitearkkitehtuuria. Näiden lisäksi tarkastellaan kokonaisarkkitehtuurin hallintamallia ja sitä, miten kokonaisarkkitehtuurityötä olisi syytä arvioida organisaatioissa. Kirjallisuudesta haettiin myös kokemuksia kokonaisarkkitehtuurityön haasteista, sekä ratkaisuja näihin tilanteisiin. Lopuksi luvussa sivutaan lainsäädännön näkökulmaa. 3.1 Määritelmä ja strategiatasot Arkkitehtuuri on terminä alun perin tuttu rakennusten ja rakennetun ympäristön yhteyksistä. Eskolan (2005) mukaan ’arkkitehtuurilla’ tarkoitetaan jonkin tietyn entiteetin loppuolotilaa sekä siihen pääsemiseen vaadittavan aikaansaamisen osaamista, eli tiivistettynä yhtä aikaa sekä lopputuotetta, että sen tekemisen taitoa. Zachman (1997) kuvailee arkkitehtuuria kokoelmana design-artifakteja, tai kuvaavia esityksiä, jotka ovat relevantteja kuvaamaan objekteja niin, että ne voidaan tuottaa vaatimusten mukaisesti sekä ylläpitää niiden koko käyttöiän ajan. Koska organisaation toiminnassa on pitkälti kyse suuresta kokonaisuudesta, joka koostuu osajärjestelmistä, niiden suhteista ja tähän liittyvästä vaadittavasta osaamisesta, on arkkitehtuuri terminä osuva näiden asioiden kuvaamiseen. Termi ’kokonaisarkkitehtuuri’ on johdettu englanninkielisestä termistä ’Enterprise Architecture’, joka suomeksi käännettynä tarkoittaa joko yritysarkkitehtuuria, tai organisaatioarkkitehtuuria. Kokonaisarkkitehtuuri on termi, jota käytetään sekä yrityskontekstissa, että muiden organisaatioiden kontekstissa. Kun puhutaan julkisista organisaatioista, käytetään termiä kokonaisarkkitehtuuri (KA) ja näin tehdään myös tässä tutkielmassa. 3 KOKONAISARKKITEHTUURI 17 Kokonaisarkkitehtuurin määritelmästä on olemassa monenlaisia tulkintoja, riippuen katsantokannasta. Atencio, Bustos ja Mancini (2022, 2) näkevät kokonaisarkkitehtuurin vaihtoehtona organisaation suunnittelulle, mallintamiselle ja analysoimiselle. Lisäksi Mancini ym. (2022, 2) toteavat, että kokonaisarkkitehtuuri on kokoelma periaatteita, metodeja ja malleja organisaation rakenteen suunnittelemiseksi, liiketoimintaprosessien, tietojärjestelmien ja IT-infrastruk- tuurin tarkastelun avulla. Myös Zachman (1997) määrittelee kokonaisarkkitehtuurin kokoelmana kuvauksia (esim. malleja), jotka ovat relevantteja kuvailemaan organisaatiota niin, että sitä voidaan operoida johdon vaatimusten mukaan ja ylläpitää sen koko eliniän ajan. Gartnerin (2013) mukaan kokonaisarkkitehtuuri on tieteenala, jolla johdetaan kokonaisvaltaisesti ja ennakoivasti organisaation reaktioita ulkopuolelta tuleviin muutosvoimiin niin, että tunnistetaan ja analysoidaan toteutettavat muutokset kohti haluttua liiketoimintavisiota ja -tuloksia. Lumor, Hirvonen ja Pulkkinen (2021, 6059) näkevät kokonaisarkkitehtuurin eräänlaisena kehityksen mahdollistavana linkkinä IT-toimintojen ja muiden organisaation toimintojen - kuten liiketoiminnan - välillä, sillä se auttaa rakentamaan organisaatiota erilaisilla komponenteilla ja niiden välisillä suhteilla. Näitä kokonaisarkkitehtuurin kuvauksia yhdistää se, että liiketoiminnan tavoitteet ovat lähtökohtana kokonaisarkkitehtuurin toteuttamiselle. Lisäksi yhdistävänä tekijänä voidaan nähdä se, että kokonaisarkkitehtuurin avulla johdetaan organisaation toimintaa, kohti alussa määriteltyjä tavoitteita. Eroavaisuutena näiden kuvauksien välillä on se, että Zachman (1997) esittelee kokonaisarkkitehtuurin enemmänkin kokoelmana työkaluja, kun taas Gartner (2013) näkee kokonaisarkkitehtuurin ajattelua ohjaavana johtamismallina. Mancini ym. (2022, 2) sekä Lumor ym. (2021, 6059) yhdistelevät onnistuneesti kumpaakin katsantokantaa määritelmässään. Lisäyksenä mainittakoon, että Julkisen hallinnon kokonaisarkkitehtuurin menetelmäkuvaus, JHS 179 (JUHTA 2017, 11), määrittelee kokonaisarkkitehtuurin joko organisaation rakenteena tai organisaation rakenteen kuvauksena, jota käytetään toiminnan kehittämisessä. Yhteenvetona voidaan sanoa, että kokonaisarkkitehtuuri auttaa hallinnoimaan ja kehittämään organisaation toimintaa systemaattisesti, yhteisesti sovittujen periaatteiden, tavoitteiden ja metodien avulla sekä lisäämään ymmärrystä IT-toimintojen ja muiden toimintojen välille. Kokonaisarkkitehtuuria voidaan hahmottaa neljän eri strategiatason avulla, kuten kuviossa 5 havainnollistetaan. Nämä neljä tasoa ovat liiketoiminta-, tieto-, ohjelmisto- ja teknologiastrategia, jotka kaikki tähtäävät tavoitteeksi asetettujen tulosten saavuttamiseen. Liiketoiminnan näkökulma määrittelee ne prosessit ja standardit, joilla liiketoiminnot toimivat päivittäin. Tietonäkökulma määrittelee sen, minkä laatuista dataa halutaan kerätä, kuinka paljon ja miten sitä käsitellään, jotta organisaatio voi toimia halutulla tasolla. Ohjelmistonäkökulma määrittää miten prosessit toimivat keskenään ja millaisia sovelluksia käytetään. Teknologianäkökulma määrittelee, millaisia laitteistoja ja esimerkiksi ohjelmointia toiminnan tueksi tarvitaan. Käytännössä voidaan ajatella, että liiketoiminnan tavoitteet ohjaavat datakokonaisuutta, eli mitä dataa halutaan kerätä ja analysoida. Kerättävä data taas asettaa vaatimuksia ohjelmistoille, joita organisaatio käyttää. 18 Ohjelmistot tarvitsevat tuekseen teknologiainfrastruktuurin, jotta se pystyy toimimaan halutulla tavalla. (Gillis, 2023; The Open Group, 2022.) Kuvio 5 Arkkitehtuurin strategiatasot Kokonaisarkkitehtuuri on strategisen johtamisen väline, jonka avulla voidaan yhtenäistää sitä, kuinka organisaatiota johdetaan ja kuinka toiminnan kehittäminen on johdonmukaista (Gartner, 2013; JUHTA 2017, 22). Kokonaisarkkitehtuurin avulla sidotaan esimerkiksi tietojärjestelmäpuolen kehittäminen organisaation ydintoiminnan kehittämiseen. Lemmetti ja Pekkola (2012, 164) toteavat, että kokonaisarkkitehtuurityön tulisi olla osa normaalia liiketoimintaa eikä se saisi jäädä pelkästään IT-toiminnon vastuulle. On kuitenkin havaittu, että liiketoiminnassa työskentelevillä henkilöillä on harvoin halukkuutta osallistua kokonaisarkkitehtuurin toteuttamiseen, johtuen siitä, ettei aiheen tärkeyttä usein ymmärretä (Lemmetti & Pekkola 2012, 164). 3.2 Kokonaisarkkitehtuurin hyödyt Parhaimmillaan kokonaisarkkitehtuuri tuottaa organisaatiolle suuren määrän monipuolisia hyötyjä. Nämä hyödyt ulottuvat organisaation johtoportaasta aina ruohonjuuritasolle saakka ja näkyvät parhaimmillaan myös asiakkaiden suuntaan. Kokonaisarkkitehtuuri tarjoaa tärkeän työkalun IT:n ja liiketoiminnan prosessien yhteensovittamiselle (Foorthuis ym. (2016). The Open Groupin (2022) mukaan kokonaisarkkitehtuuri mahdollistaa nopean reagoinnin muutoksiin ja tukee ketteriä toimenpiteitä organisaation strategian mukaisesti. Lisäksi se mahdollistaa organisaatiomuutokset, jotka tukevat sekä digitaalista transformaatiota että uusien trendien omaksumista liiketoiminnassa ja teknologiassa. Kokonaisarkkitehtuuri mahdollistaa sellaiset organisaation ja toimintamallien muutokset, jotka parantavat tehokkuutta ja vaikuttavuutta (The Open Group, 2022). Gartnerin (2013) mukaan kokonaisarkkitehtuuri tuottaa arvoa organisaatiolle 19 esittämällä liiketoiminta- ja IT-johtajille valmiita suosituksia toimintatapojen ja - mallien mukauttamiseksi, jotta tavoitellut liiketoimintatulokset voidaan saavuttaa. Myös muutosjohtaminen tehostuu kokonaisarkkitehtuurin ansiosta (Niemi & Pekkola 2019, 587). Kokonaisarkkitehtuurin avulla pystytään parantamaan organisaation sisäistä yhteistyötä ja viestintää, joka johtaa toiminnan tehostumiseen. Sen avulla eri yksiköt voivat toimia innovatiivisesti ennalta määritettyjen raamien sisällä saavuttaakseen tavoitteitaan. Kokonaisarkkitehtuurin avulla voidaan saavuttaa pienemmät liiketoiminnan kustannukset, ketterämpi organisaatio, pienemmät muutosjohtamisen kustannukset sekä joustavuutta työvoiman ja resursoinnin suhteen. Sen avulla pystytään jalkauttamaan liiketoiminnan eri kyvykkyyksiä koko organisaation käyttöön. Lisäksi kokonaisarkkitehtuuri kasvattaa liiketoimintaa ja parantaa liiketoiminnan tuottavuutta sekä organisaatiointegraatioita yritysostojen ja fuusioiden tueksi. Kokonaisarkkitehtuurin avulla voidaan pienentää kehityksen, käyttöönoton, toiminnan, tuen ja huollon kustannuksia, sekä parantaa järjestelmien hallintaa ja yhteen toimivuutta Edellä mainitut seikat vaikuttavat myös asiakastyytyväisyyden kehittymiseen. (Niemi & Pekkola 2019, 587; The Open Group, 2022.) Kokonaisarkkitehtuuri pystyy vähentämään liiketoiminnan ja IT:n monimutkaisuutta (Foorthuis ym. 2016, 2) sekä maksimoimaan olemassa olevan liiketoiminnan ja IT:n panos-tuotto-suhdetta (The Open Group, 2022). Se lisää myös joustavuutta ja nopeutta luoda, ostaa tai ulkoistaa liiketoiminta- ja IT-ratkaisuja. Kokonaisarkkitehtuurin avulla ostopäätökset ovat yksinkertaisempia, sillä hankintoja ohjaava tieto on helposti saatavilla ja muunnettavissa selkeäksi suunnitelmaksi (Foorthuis ym. 2016, 6). Kokonaisarkkitehtuuri lisää kyvykkyyttä hankkia heterogeenisiä, useamman toimittajan avoimia järjestelmiä ja auttaa turvaamaan lisää taloudellisia kyvykkyyksiä (The Open Group, 2022). Yksi tärkeä näkökulma on myös maailmanlaajuinen tietosuojalainsäädäntö, joka asettaa organisaatioille dataan liittyviä vaatimuksia. Näiden vaatimusten toteuttamiseksi on äärimmäisen tärkeää, että tietyt organisaation dokumentaatiot ovat riittävän selkeällä ja ymmärrettävällä tasolla. (The Open Group, 2022.) 3.3 Kokonaisarkkitehtuurin viitekehykset ja menetelmät Kokonaisarkkitehtuurin viitekehyksiä ja menetelmiä on lukuisia, monenlaisiin eri tarkoituksiin. Viitekehysten tarkoituksena on kuvata käytettävät arkkitehtuurin näkökulmat ja eri tasot. Arkkitehtuurin viitekehys voi olla joko valmis jäsennysmalli, kuten TOGAF (The Open Group, 2022) tai vastaavasti organisaation omaan käyttöön suunniteltu ja räätälöity arkkitehtuurirakenteiden jäsennysmalli. Julkisen hallinnon kontekstissa on hyvä huomioida sen erityispiirteisiin luotu kokonaisarkkitehtuurimenetelmä JHS 179 (JUHTA 2017, 2), jonka tavoitteena on julkisen hallinnon organisaatioiden toiminnan ja palveluiden yhteen toimivuuden kehittäminen ja parantaminen (JUHTA 2017, 2). Hyvinvointialueiden valmistelutyötä ja toimintaa tukemaan on luotu hyvinvointialueiden oma 20 viitearkkitehtuuri (Huovila, 2022). Lisäksi tässä luvussa käsitellään suhteellisen tuoretta Lean-arkkitehtuurimenetelmää, joka hyödyntää ketterän kehityksen menetelmiä (Hosiaisluoma, Penttinen, Mustonen & Heikkilä 2018, 88). Luvun lopusta löytyy tiivistettynä edellä mainittujen viitekehysten ja menetelmien vertailu hyötyineen ja haasteineen. 3.3.1 TOGAF The Open Group Architecture Framework (jäljempänä TOGAF) on avoin viitekehys kokonaisarkkitehtuurille. Se on sovellettavissa arkkitehtuurin kehittämiseen kaikissa konteksteissa. TOGAF auttaa organisaatioita määrittelemään tavoitteita ja asettamaan ne linjaan järjestelmäkehityksen arkkitehtuuriobjektien kanssa. TOGAF koostuu toisiinsa yhdistyneistä, mutta myös yksinään toimivista dokumenteista, jotka tarjoavat käytännön opastusta TOGAF:in käyttöön eri konteksteissa. (The Open Group, 2022.) Keskeistä TOGAF:issa on sen kehityssykli (kts. Kuvio 6), joka koostuu kymmenestä eri kokonaisuudesta. Kehityssykli eli ADM-arkkitehtuurimenetelmä (Architecture Development Method) ohjaa organisaation arkkitehtuuriprosessia alusta loppuun saakka. Valmisteluvaiheessa tunnistetaan se arkkitehtuurin taso, jota organisaatiossa haetaan ja luodaan perusta arkkitehtuurityölle. Vaiheessa A (Arkkitehtuurivisio), määritellään arkkitehtuurin periaatteet ja arkkitehtuurikehys. Seuraavissa kolmessa vaiheessa B-D keskitytään eri arkkitehtuurinäkökulmiin eli liiketoiminta-arkkitehtuuriin, tietojärjestelmäarkkitehtuuriin sekä teknologia-arkkitehtuuriin. Vaihe E keskittyy tarkastelemaan tärkeimpiä mahdollisuuksia ja ratkaisuvaihtoehtoja. Vaihe F (Projektien hallinta) sisältää suunnitelman ja tiekartan teon tavoitetilaan pääsemiseksi ja projektien priorisoimiseksi. Vaiheessa G (Toteutuksen hallinta) luodaan suosituksia implementointiin ja käyttöönottoon sekä muodostetaan arkkitehtuurisopimukset näiden toteuttamiseksi. Vaihe H kattaa muutosjohtamisen prosessin perustamisen, jota uuden kokonaisarkkitehtuurin käyttöönotto vaatii. Koko syklin ajan mukana kulkee vaatimusten hallinta, joka määrittelee ja ohjaa jatkuvasti prosessin eri vaiheita. (The Open Group, 2022.) 21 Kuvio 6 Mukaillen TOGAF-kehityssykli (The Open Group, 2022) Nämä kehityssyklin kymmenen vaihetta pilkkovat kokonaisarkkitehtuurin kehittämis- ja ylläpitoprosessin ymmärrettäviksi osakokonaisuuksiksi. Näihin vaiheisiin syvennytään perusteellisemmin seuraavissa kappaleissa. Valmisteluvaiheessa määritellään käytännössä "missä, mitä, miksi, kuka ja kuinka arkkitehtuuria toteutetaan" kyseisessä organisaatiossa. Vaiheessa määritellään mistä organisaatiosta on kyse. Lisäksi tunnistetaan keskeiset tekijät ja elementit kyseisen organisaation kontekstissa. Vaiheessa määritellään arkkitehtuurityön vaatimukset, arkkitehtuuriperiaatteet sekä käytettävä arkkitehtuurikehys. Lisäksi määritellään organisaation johtamiseen liittyviä seikkoja ja arvioidaan organisaation kokonaisarkkitehtuurin kypsyystasoa. (The Open Group, 2022.) Arkkitehtuurivisio-vaiheessa varmistetaan, että organisaatiossa on riittävä sitoutuminen ja tuki arkkitehtuurin kehityssyklin toteutukselle. Lisäksi tarkastellaan organisaation toimintaperiaatteita, tavoitteita ja strategisia ajureita. Vaiheessa määritellään perustason arkkitehtuurin laajuutta ja osatekijöitä, tärkeimpiä sidosryhmiä ja heidän tavoitteitaan sekä keskeisimpiä liiketoimintavaatimuksia ja rajoituksia, jotka on otettava arkkitehtuurityössä huomioon. Lopuksi 22 viestitään syntyneestä arkkitehtuurivisiosta, varmistetaan hyväksyntä työn jatkamiselle ja kartoitetaan muut rinnakkain meneillä olevat kokonaisarkkitehtuurin kehityssyklit ja niiden vaikutukset. (The Open Group, 2022.) Liiketoiminta-arkkitehtuurin vaiheessa kuvataan liiketoiminta-arkkiteh- tuurin perustaso. Lisäksi kehitetään tavoitetilan liiketoiminta-arkkitehtuuri, joka sisältää mm. tuote- tai palvelustrategian sekä toimintaympäristön toiminnallisia, organisatorisia, prosessi-, tieto-, ja maantieteellisiä näkökulmia, jotka pohjautuvat organisaation tavoitteisiin, periaatteisiin ja strategisiin ajureihin. Vaiheessa analysoidaan tämänhetkisen perustason arkkitehtuurin ja tavoitetilan arkkitehtuurin välisiä aukkoja. Business Architecture -vaiheessa valitaan ne relevantit arkkitehtuurin näkökulmat, joiden avulla arkkitehdit pystyvät osoittamaan, että sidosryhmien huolenaiheet on otettu arkkitehtuurityössä huomioon. Lisäksi vaiheessa valitaan ne relevantit työkalut ja tekniikat, joita käytetään valittujen näkökulmien yhteydessä. (The Open Group, 2022.) Järjestelmäarkkitehtuurivaiheessa kehitetään tavoitetilan arkkitehtuureja, jotka kattavat projektin laajuudesta riippuen jommankumman tai molemmat Data- ja Application -alueista. Data Architecture -alueella määritellään yleisimmät datan tyypit ja lähteet, jotka ovat toiminnan kannalta välttämättömiä niin, että ne ovat sidosryhmien näkökulmasta ymmärrettäviä, vakaita, johdonmukaisia ja kattavia. Applications Architecture -alueella määritellään ne tärkeät järjestelmät, joita tarvitaan datan prosessointiin ja toiminnan tukemiseen. Vaiheessa määritellään myös mitä näiden järjestelmien täytyy tehdä datan käsittelyyn liittyen sekä tiedon esittämiseksi järjestelmän käyttäjille organisaatiossa. (The Open Group, 2022.) Teknologia-arkkitehtuurin vaiheessa kehitetään tavoitetilan teknologiaarkkitehtuuri, joka mahdollistaa arkkitehtuurivision, datan, sovellusten ja liiketoiminnan rakennuspalikoiden toteuttamisen teknologian avulla niin, että arkkitehtuurityön tavoitteisiin ja sidosryhmien huolenaiheisiin pystytään vastaamaan. Vaiheessa tunnistetaan arkkitehtuurityön etenemissuunnitelman potentiaaliset osat, perustuen perustason arkkitehtuurin ja tavoitetilan arkkitehtuurin välisiin aukkoihin. (The Open Group, 2022.) Mahdollisuudet ja ratkaisut -vaiheessa arvioidaan erilaisia tavoitetilan arkkitehtuurien kehitystyössä tunnistettuja toteutusvaihtoehtoja. Vaiheessa tunnistetaan muutoksen keskeisiä parametreja ja työpaketteja, joita seurataan ja toteutetaan muutoksen yhteydessä. Lisäksi vaiheessa arvioidaan eri projektien riippuvuuksia toisistaan sekä niiden hyötyjä ja kustannuksia. Lopuksi pyritään luomaan strategia ja yksityiskohtainen täytäntöönpanosuunnitelma siirtymää varten. (The Open Group, 2022.) Projektien hallinta -vaiheessa laitetaan eri toteutusprojektit tärkeysjärjestykseen. Vaiheeseen kuuluu erilaisten migraatioprojektien riippuvuuksien, kustannusten, riskien ja hyötyjen arviointi. Tästä työstä syntyvä priorisoitujen projektien luettelo muodostaa yksityiskohtaisen aikajanalla varustetun täytäntöönpanosuunnitelman ja migraatiosuunnitelman perustan. (The Open Group, 2022.) Toteutuksen hallinta -vaiheessa laaditaan suositukset jokaiselle toteutusprojektille. Vaiheessa rakennetaan arkkitehtuurisopimus, joka ohjaa yleistä 23 toteutus- ja käyttöönottoprosessia. Vaiheen aikana suoritetaan asiaankuuluvat hallinnolliset toiminnot, kun toteutusta ja käyttöönottoa viedään läpi. Lisäksi vaiheessa varmistetaan, että toteutus- ja käyttöönottoprosessin eri projektit noudattavat määriteltyä arkkitehtuuria. (The Open Group, 2022.) Arkkitehtuurin muutosjohtamisen vaihe luo muutoksenhallintaprosessin uuden kokonaisarkkitehtuurin tarpeisiin. Vaiheen tuotokset mahdollistavat jatkuvan seurannan teknologian kehitykselle ja toiminnan muutokselle. Lisäksi vaihe auttaa tunnistamaan, milloin on syytä käynnistää uusi arkkitehtuurin kehityssykli. Tässä vaiheessa saattaa syntyä muutostarpeita valmisteluvaiheessa asetettuihin periaatteisiin ja puitteisiin. (The Open Group, 2022.) Vaatimustenhallinnan vaihe varmistaa, että vaatimustenhallinnan prosessi on johdonmukaista, jatkuvaa ja se toimii kaikissa arkkitehtuurin kehityssyklin vaiheissa. Tämän avulla hallitaan kaikkia niitä arkkitehtuurivaatimuksia, joita tunnistetaan kehityssyklin eri vaiheissa. Vaatimustenhallintavaihe varmistaa lisäksi sen, että kyseiset arkkitehtuurivaatimukset ovat varmasti saatavilla ja näkyvissä, kun vaiheiden toimenpiteitä suoritetaan. (The Open Group, 2022.) 3.3.2 Julkisen hallinnon kokonaisarkkitehtuurimenetelmä JHS 179 Julkisen hallinnon kokonaisarkkitehtuurimenetelmä, JHS 179, kuvaa käytännössä yhtenäisen suunnittelumenetelmän sekä yhtenäiset kuvaustavat ja -mallit julkisen hallinnon kokonaisarkkitehtuurin kehittämiseksi sen eri vaiheissa. Tämä tarkoittaa järjestelmällistä työ- ja menettelytapaa, jolla tunnistetaan, jäsennetään, suunnitellaan ja kuvataan tietyn kokonaisuuden rakenteen osat ja näiden riippuvuudet. JHS 179 perustuu isolta osin aiemmin mainittuun kokonaisarkkitehtuuriviitekehykseen, TOGAF:iin, jota käytetään laajasti sekä julkisella että yksityisellä sektorilla. JHS 179 määrittelee kokonaisarkkitehtuurin joko organisaation rakenteena tai organisaation rakenteen kuvauksena, jota käytetään toiminnan kehittämisessä ja näin ollen kokonaisarkkitehtuuri auttaa hallinnoimaan ja kehittämään organisaation toimintaa systemaattisesti. (JUHTA 2017, 2.) JHS 179 kokonaisarkkitehtuurimenetelmä käsittelee arkkitehtuuria neljästä eri näkökulmasta, joita ovat toiminta-, teknologia-, tietojärjestelmä- ja tietoarkkitehtuurit (ks. kuvio 7). Näistä näkökulmista tärkeimpänä pidetään toimintakerrosta, joka toimii suunnittelun lähtökohtana ja asettaa vaatimukset muille arkkitehtuuritasoille. JHS 179 sisältää myös käsitteelliset tasot, joita ovat periaatteellinen, käsitteellinen, looginen ja fyysinen taso sekä toimeenpanon tason, jossa toteuttamissuunnitelmat kytketään osaksi kokonaisarkkitehtuurin kehittämistä. Periaatetaso ohjaa kokonaisuuden suunnittelua, käsitteellinen taso kuvaa tarpeita ja vaatimuksia, looginen taso sisältää rakenteet ja fyysinen taso esittää ratkaisutavat. (JUHTA 2017, 28–29.) 24 Kokonaisarkkitehtuuria suunnitellaan ja kehitetään iteratiivisesti, organisaation asettamien strategisten tavoitteiden pohjalta. Kokonaisarkkitehtuurin suunnittelu on tärkeä osa organisaation koko toiminnan kehittämistä sekä talouden ja toiminnan suunnitteluprosessia. Kokonaisorganisaation suunnitteluprosessi, kuten kuviossa 8 havainnollistetaan, käsittää kaksi eri kokoista sisältökokonaisuutta, eli peruskuvaukset, jotka jokaisen organisaation olisi tärkeää tuottaa sekä laajennetut kuvaukset, joiden avulla organisaatio voi kuvata oman arkkitehtuurinsa tarkemmalla ja kattavammalla tasolla. Kokonaisarkkitehtuurin olisi syytä olla tärkeä kehittämisen kohde ja osa organisaation toiminnan jatkuvaa kehittämistä. Kokonaisarkkitehtuurin suunnitteluprosessi toimii vuosisyklin mukaisesti. Näin ollen suunnitteluprosessi kattaa seuraavan vuoden aikana toimeenpantavat tehtävät. Kokonaisarkkitehtuurin suunnitteluprosessi koostuu viidestä eri vaiheesta: 1. Kokonaisarkkitehtuurin suunnittelun valmistelu 2. Arkkitehtuurivision määrittely 3. Nykytilan analysointi 4. Tavoitetilan määrittely ja suunnittelu 5. Toimeenpanon suunnittelu. (JUHTA 2017, 30–31.) Kuvio 7 Mukaillen JHS 179 Arkkitehtuurikuvausten viitekehys (JUHTA 2017, 28) 25 Kuvio 8 Kokonaisarkkitehtuurin suunnitteluprosessi (JUHTA 2017, 31) Suunnittelun valmisteluvaiheen keskeinen tavoite on organisoida kokonaisarkkitehtuurityö johdonmukaiseksi sekä kerätä tarpeelliset ohjaustiedot työn tueksi. Ohjaavia tietoja ovat esimerkiksi lainsäädännön vaatimukset, viitearkkitehtuurit, tietoturva- ja tietosuojavaatimukset sekä sidosryhmiltä tulleet tarpeet. Valmisteluvaiheessa on myös hyödyllistä katselmoida organisaation olemassa olevien arkkitehtuurikuvausten taso. Tämän jälkeen varsinainen arkkitehtuurityö organisoidaan, joka pitää sisällään arkkitehtuurityön aikataulutuksen, resursoinnin ja riskianalyysin. Arkkitehtuurityölle on keskeistä nimetä myös omistaja, joka vastaa arkkitehtuurityöstä kokonaisuudessaan. Organisaatiolla tulee olla käytössä myös kokonaisarkkitehtuurityön hallintamalli, joka ohjaa toimeenpanoa ja jossa on määritelty selkeästi vastuut suunnittelun ja toteutuksen osalta. (JUHTA 2017, 32–33.) Arkkitehtuurivision määrittelyvaiheen tarkoituksena on linjata arkkitehtuurityön tavoitteet ja rajaukset sekä hyväksyttää arkkitehtuurivisio johdolla. Vision määrittelyvaihe tarkentaa suunnittelun päätavoitteen, joka voi olla esimerkiksi isomman toiminnallisen muutoksen läpivienti organisaatiossa tai jonkin muun keskeisen tavoitetilan saavuttaminen. Tässä vaiheessa oleellista on myös nimetä ja sitouttaa keskeiset työhön osallistuvat toimijat sekä määritellä keskeiset alueet kokonaisarkkitehtuurista, jotka ovat tavoitteeseen pääsyn kannalta oleellisia kehityskohteita. (JUHTA 2017, 33–36.) 32 Kuvio 12 Mukaillen Liiketoiminta-arkkitehtuurin välittäjämäinen asema (Bouwman ym. 2011, 415) Toiminta-arkkitehtuurin avulla voidaan tuottaa hyödyllistä tietoa ja näkemystä organisaation toiminnasta ja ohjaavista periaatteista. Tämän tiedon avulla muiden arkkitehtuuriosa-alueiden, kuten esimerkiksi järjestelmä- ja tietoarkkitehtuurin rakentaminen ja ylläpito pohjautuu ajantasaiselle ja oikealle tiedolle organisaation toimintaan liittyen. Lisäksi eri sidosryhmiltä tulevat vaatimukset ja toiveet pystytään ottamaan paremmin huomioon ja linjaamaan yhteen kokonaisuuden kanssa. Julkisen hallinnon haasteeksi usein muodostuu se, että organisaatiossa ei ole yhtenäistä linjaa siitä, kuinka yksityiskohtaisella tasolla toiminta-ark- kitehtuurin tulisi olla. Toiminta-arkkitehtuurin tulisi samaan aikaan olla tarpeeksi ylätasolla, jotta arjen käytännön asiat eivät jatkuvasti vaikuta siihen, mutta kuitenkin tarpeeksi yksityiskohtaisella tasolla, jotta organisaation IT-ark- kitehtuuria pystytään kuvaamaan. (Bouwman ym. 2011, 415.) Julkisen hallinnon kokonaisarkkitehtuurimenetelmä JHS 179 kuvailee toiminta-arkkitehtuuria seuraavasti: ”Toiminta-arkkitehtuurin suunnittelun ja kuvauksen tarkoituksena on suunnitella ja kehittää strategialähtöisesti organisaation perustehtävää, sitä tukevia tukitoimintoja, toiminnan vaatimia resursseja 33 sekä toiminnan lopputuloksena olevia tuotoksia tai palvelutarjontaa.” (JUHTA 2017, 55). Toiminta-arkkitehtuurilla on tärkeä tehtävä organisaation strategian jalkauttamisessa IT-arkkitehtuurin tasolle (Bouwman ym. 2011, 415). Toimintaarkkitehtuuri toimii lähtökohtana IT-arkkitehtuurille, joka mahdollistaa tehokkaan, avoimen ja selkeän julkisen organisaation toiminnan (Henkel ym. 2017, 158). 3.5 Kokonaisarkkitehtuurin hallintamalli Bernardin ja Grasson (2009, 23) mukaan yksi keskeisimmistä edellytyksistä menestyksekkään kokonaisarkkitehtuurin toteuttamiselle on kokonaisarkkitehtuurin hallintamallin käyttöönotto. Myös Winter ja Schelp (2008, 548) puoltavat hallintamallin tärkeyttä, sillä sen avulla voidaan varmistaa johdonmukaiset ja ajantasaiset kokonaisarkkitehtuurituotokset. Kokonaisarkkitehtuurin hallintamallin tarkoitus on kuvata, miten arkkitehtuurityön ja kokonaisarkkitehtuurin hallinta organisoidaan, mitä rooleja ja vastuita tehtäviin kuuluu sekä miten kokonaisarkkitehtuurityötä käytännössä toteutetaan ja miten siitä raportoidaan. Hallintamalli auttaa luomaan satunnaisesta tekemisestä jatkuvaa, säännöllistä ja tavoitehakuista toimintaa. (JUHTA 2017, 51; Ahlemann, Stettiner, Messerschmidt & Legner 2012, 83.) Seppäsen (2014, 32) mukaan kokonaisarkkitehtuurin hallintamallilla on kaksi keskeistä tarkoitusta. Ensinnäkin sen tarkoituksena on ohjata organisaation kokonaisarkkitehtuurin kehittämistä niin, että voidaan varmistua, että kokonaisarkkitehtuurityö vastaa organisaation tavoitteita. Toiseksi hallintamallin tarkoituksena on valvoa kokonaisarkkitehtuurin johdonmukaista toteuttamista läpi eri organisaatio-osien. Hallintamallin toteuttamiseen on olemassa useita malleja ja tärkeää onkin muistaa, että yhtä kaikille sopivaa hallintamallia ei ole olemassakaan. Jokainen organisaatio on yksilö, ja hallintamalli täytyy räätälöidä organisaation omiin tarpeisiin sopivaksi. (Ahlemann ym. 2012, 84.) Valtiovarainministeriön (2014, 2) kuvaama julkisen hallinnon kokonaisarkkitehtuurin hallintamalli (kts. Kuvio 13), on kuvaus siitä, miten kokonaisarkkitehtuurin hallinta julkisella sektorilla käytännössä organisoidaan, minkälaisia rooleja siihen liittyy ja minkälaisilla prosesseilla julkisen hallinnon arkkitehtuuria suunnitellaan, kehitetään ja hallitaan käytännön tasolla. (Valtiovarainministeriö 2014, 2.) 34 Kuvio 13 Julkisen hallinnon kokonaisarkkitehtuurin hallintamalli (Valtiovarainministeriö 2014, 2) Liityntä toiminnan johtamiseen ja kehittämiseen -osa-alue kuvaa, miten kokonaisarkkitehtuurityö kytketään osaksi julkisorganisaation toiminnan johtamista, kehittämistä ja strategista suunnittelua. KA-hallinnan roolit-osiossa määritellään yhteisen arkkitehtuurityön roolit ja tehtävät. KA-hallinnan organisoinnissa nimetään kokonaisarkkitehtuurityön keskeiset vastuuhenkilöt ja toimijat. KA-toi- minnan mittarit ja jatkuva kehittäminen -osuudessa määritellään arkkitehtuurityön mittarit ja jatkuvan kehittämisen toimintatavat. KA-työjärjestys ja vuosikello -osio toimii täydentävänä kohtana, jossa tarkennetaan kokonaisarkkitehtuurityön toteuttamistavat ja työ kytketään osaksi vuosikelloa. KA-hallintapro- sessit määrittelevät kokonaisarkkitehtuurin hallintaan liittyvät keskeiset prosessit. (Valtiovarainministeriö 2014, 7–8.) The Open Groupin kokonaisarkkitehtuurin viitekehyksessä TOGAF:issa on myös esitetty kuvaus kokonaisarkkitehtuurin hallintamallista (ks. kuvio 14). TOGAF:in arkkitehtuurin hallintamallissa on kolme keskeistä osaa, joita ovat kehittäminen, toteuttaminen ja käyttöönotto. Kustakin osa-alueesta vastaa tietty taho, esimerkiksi kokonaisarkkitehtuurityön kehityksestä vastaa arkkitehtuurin ohjausryhmä, jonka alaisuudessa toimii johtava arkkitehti, kokonaisarkkitehdit ja eri osa-alueiden nimetyt arkkitehdit. Hallintamallin mukaisesti toteutettavat muutokset tehdään projekteissa ja projektien valmistuttua ratkaisut siirtyvät osaksi organisaation tuotantoympäristöä. TOGAF:in hallintamallin keskeisenä ajatuksena on, että organisaation jatkumoon liittyvät tekijät, kuten prosessit, standardit ja sääntelystä tulevat vaatimukset integroidaan osaksi kehitys-, toteutus- ja käyttöönottovaiheita. (The Open Group, 2022.) TOGAF-hallintamallissa 35 kokonaisarkkitehtuuri on asetettu IT-johtajan alaisuuteen, kuten tietohallintojohtajan tai teknologiajohtajan vastuulle. Kokonaisarkkitehtuurin hallintavastuusta on olemassa myös eriäviä näkemyksiä. Esimerkiksi Banaeianjahromi ja Smolander (2019, 895) esittävät, että kokonaisarkkitehtuuri on sijoitettava organisaatiossa korkeimman johdon vastuulle, jotta kokonaisarkkitehtuurin kehittäminen onnistuisi parhaalla mahdollisella tavalla. Kokonaisarkkitehtuurin menestyksekkään toteuttamisen edellytyksenä on vahva yhteistyö IT:n ja muiden sidosryhmien välillä, joten kokonaisarkkitehtuurin hallinnan sijoittaminen pelkästään IT:n vastuulle voi johtaa siihen, että kokonaisarkkitehtuuri ei jalkaudu riittävästi muualle organisaatioon (Gong & Janssen 2022, 1413). Kokonaisarkkitehtuurin hallintavastuun sijoittamista organisaatioon onkin syytä tarkastella kriittisesti, ja esimerkiksi Ahlemannin ja muiden (2012, 93) mukaan kehittyneemmissä organisaatioissa kokonaisarkkitehtuuri on voitu sijoittaa esimerkiksi talousjohtajan tai toimitusjohtajan alaisuuteen. Kuvio 14 TOGAF-viitekehyksen kokonaisarkkitehtuurin hallintamalli (The Open Group 2022) 3.6 Kokonaisarkkitehtuurityön arviointi Yhdysvaltain hallinnon tilintarkastustuomioistuin (Government Accountability Office, GAO) on määrittänyt viisi tasoa kokonaisarkkitehtuurin kypsyydelle. Ensimmäisellä tasolla luodaan tietoisuutta kokonaisarkkitehtuuriin liittyen. Tällä tasolla organisaatiolla ei ole dokumentoitua kokonaisarkkitehtuuria, suunnitelmia sen kehittämiseksi eikä tarvittavaa sitoutumista kokonaisarkkitehtuuriprosessille. Toisella tasolla rakennetaan perustaa kokonaisarkkitehtuurin hallinnalle. 36 Tällä tasolla organisaatiolla on suunniteltuna pääarkkitehdin rooli, valittu käytettävä kokonaisarkkitehtuurin viitekehys ja prosessi sekä perustettu kokonaisarkkitehtuuriohjausryhmä. Kolmannella tasolla organisaatio kehittää kokonaisarkkitehtuurituotoksia. On havaittavissa selkeää sitoutumista kokonaisarkkitehtuuriprosessille ja on aloitettu nykytila- ja tavoitearkkitehtuuridokumenttien ja muutossuunnitelmien kehittäminen. Neljännellä tasolla kokonaisarkkitehtuurituotokset, kuten nykytila- ja tavoitearkkitehtuurit ovat loppuunvietyjä ja niitä hyödynnetään IT-investointien päätöksenteossa. Viidennellä tasolla kokonaisarkkitehtuuria hyödynnetään muutosjohtamisessa niin, että kokonaisarkkitehtuuri kehittyy koko ajan ja sitä käytetään IT-päätöksenteossa läpi organisaation. Lisäksi on asetettu mittareita kokonaisarkkitehtuurin tehokkuuden seurantaa varten. (Kaisler ym., 2005.) Ojo, Janowski ja Estevez (2012, 4262) esittävät, että julkisten organisaatioiden tulisi ottaa kokonaisarkkitehtuurityötä arvioidessaan huomioon mm. ylimmän johdon sitoutuminen ja tuki, eri liiketoimintojen ja johdon osallistuminen, projektien tehokas johtaminen ja arkkitehtuurin hallinta, tekniset taidot ja osaaminen, koulutukset, kokonaisarkkitehtuuriin liittyvät prosessit, konsulttien saatavuus, muutokseen sitoutuminen, viestintä ja yhteistyö, resurssien saatavuus ja selkeät tavoitteet ja kokonaisarkkitehtuurityön taso. Lisäksi kokonaisarkkitehtuurin arviointiin on suositeltavaa käyttää selkeitä mittareita. Kaisler ym. (2005) ehdottavat muutamia mittareita käytettäväksi, kuten esimerkiksi onko vuosittainen kokonaisarkkitehtuurin päivitys tehty (valmis/ei valmis), kokonaisarkkitehtuurin kanssa linjassa olevien järjestelmien prosenttiosuus, poikkeusten lukumäärä kokonaisarkkitehtuurissa, kokonaisarkkitehtuurin mukaisten konseptien ja liiketoimintatapausten määrä, kokonaisarkkitehtuuriarviointien määrä ja lopputulos, kokonaisarkkitehtuuriin ehdotettujen ja hyväksyttyjen muutosten määrä (Kaisler ym., 2005). 3.7 Tyypillisimmät haasteet kokonaisarkkitehtuurin hyödyntämisessä Kaisler, Armour ja Valivullah (2005) jakavat kokonaisarkkitehtuurin hyödyntämiseen liittyvät haasteet kolmeen kokonaisuuteen: kokonaisarkkitehtuurin mallintaminen, kokonaisarkkitehtuurin hallinta ja kokonaisarkkitehtuurin ylläpito. Mallintamisen avulla pystytään kuvailemaan ja ymmärtämään kokonaisarkkitehtuuria paremmin, kokonaisarkkitehtuurin hallinta on tärkeää sen kehittämiseksi ja jalkauttamiseksi ja kokonaisarkkitehtuurin ylläpito on tärkeää siitä syystä, että organisaation toiminta kehittyy jatkuvasti ja operatiivinen varmuus on kyettävä säilyttämään siitä huolimatta (Kaisler ym., 2005). Nämä kolme kokonaisuutta muodostuvat erilaisista toiminnoista ja käytänteistä, joilla kokonaisarkkitehtuuria toteutetaan. Lucke ja Lechner (2010, 9) sen sijaan jakavat kokonaisarkkitehtuurin haasteet viiteen kokonaisuuteen, jotka ovat: johtaminen ja hallinta, semanttiset (merkityksellisyyteen liittyvät) haasteet, riittämättömät 37 resurssit, monimutkaisuus ja representaatio (eli esitysmuoto), kuten kuviossa 15 havainnollistetaan. Nämä kaksi jaottelutapaa ovat linjassa toistensa kanssa ja niiden sisällöt eivät juurikaan poikkea toisistaan. Kuvio 15 Mukaillen Kokonaisarkkitehtuurin haasteiden kategorisointi (Lucke & Lechner 2010, 9) Johtamisen ja hallinnan haasteet ovat yleisiä kokonaisarkkitehtuurityössä ja niitä on monenlaisia (Rouvari & Pekkola 2024, 78). Lucken ja Lechnerin (2010, 5–6) sekä Kaislerin ja muiden (2005) mukaan kokonaisarkkitehtuuria varten tulee olla johdon tuki, joka mahdollistaa arkkitehtuurimyönteisen ympäristön ja tarvittavat resurssipanostukset. Yksi vaikuttava tekijä Dreyfusin (2007) mukaan on se, että arkkitehtuuriryhmillä ei ole tarvittavaa päätäntävaltaa asioista, jotka vaikuttavat kokonaisarkkitehtuuriin. Esimerkiksi päätäntävastuussa olevat toiminnan edustajat voivat ohittaa arkkitehtuurin käsittelyn tai jättää tekemättä sellaisia investointeja, joita hyvätasoisen kokonaisarkkitehtuurin toteuttamiseen vaadittaisiin (Dreyfus, 2007). Edellä mainittujen seikkojen lisäksi kokonaisarkkitehtuuria ei ymmärretä jatkuvana prosessina, vaikka tämä olisi ensisijaisen tärkeää, sillä kehittyvien organisaatioiden tulisi pitää arkkitehtuuristaan huolta jatkuvana prosessina (Rhodes, Ross & Nightingale, 2009). Semanttisiksi, eli merkityksellisyyteen liittyviksi haasteiksi luetaan esimerkiksi viestintään, sidosryhmien hallintaan, vaatimusten ymmärtämiseen ja jaettuun ymmärrykseen liittyvät ongelmat. Toimivan kokonaisarkkitehtuurin liittyvän yhteistyön saavuttamiseksi organisaation eri ryhmien tulee tavoitella ja toteuttaa erinomaista viestintää, joka on kaikkien ymmärrettävissä (Lucke & Lechner 2010, 7). Yhteistyöhön ja viestintään liittyvät ongelmat ovat hyvin yleisiä kokonaisarkkitehtuurityössä, ja ne voivat aiheuttaa suuria ongelmia (Rouvari & Pekkola 2024, 79). Tästä hyvänä esimerkkinä Espinosa ja Boh (2009, 7) 38 mainitsevat IT-henkilökunnan käyttämän liian teknisen sanaston ja kielen, sekä kyvyttömyyden keskustella kokonaisarkkitehtuurista liiketoiminnan terminologialla. Samaan aikaan liiketoiminnan henkilöstöltä saattaa puuttua kyky ja halukkuus hyödyntää IT-henkilökunnan osaamista kokonaisarkkitehtuuriin liittyen (Espinosa & Boh 2009, 7). Armourin, Kaislerin ja Liun (1999b) mukaan kaikkien sidosryhmien tulisi olla mukana hyväksymässä tavoitearkkitehtuuria, jotta erilaiset tarpeet ja näkökulmat tulevat varmasti otettua huomioon. Lucken ja Lechnerin (2010, 7) mukaan on myös hyvä muistaa, että henkilöt, jotka rakentavat ja käyttävät kokonaisarkkitehtuurin ratkaisuja, eivät ole samoja. Näin ollen tulee varmistaa, että kokonaisarkkitehtuurin vaatimukset ymmärretään oikein, jotta pystytään rakentamaan tarvittavia ja relevantteja ratkaisuja (Melchert ym., 2004). Resurssien vähäisyys ja osaavien arkkitehtien puute (Hauder & Roth, 2013) on merkittävä vaikutustekijä kokonaisarkkitehtuurin onnistumisen kannalta. Lucken ja Leichnerin (2010, 9) mukaan resurssien ja osaamisen puute vaikuttaa myös neljään muuhun haastekokonaisuuteen. Myös Armour ym. (1999b) toteavat, että taitavista arkkitehdeistä on pulaa. Weteringin, Kurnian ja Kotusevin (2020, 3) mukaan organisaatiot, jotka eivät aktiivisesti investoi kokonaisarkkitehtuuriresursseihin, jäävät ilman operatiivisia ja strategisia hyötyjä ja menettävät kokonaisarkkitehtuuriin liittyviä kyvykkyyksiä. Nykypäivän organisaatioissa on suuri määrä erilaisia järjestelmiä ja sovelluksia, joilla on lukuisia keskinäisiä riippuvuuksia ja käyttäjäryhmiä (Rhodes ym., 2009; Espinosa & Boh 2009, 2). Tämä johtaa väistämättä siihen, että on todella haastavaa ylläpitää johdonmukaisuutta kehitystyössä ja kokonaisarkkitehtuurissa (Armour, Kaisler & Liu, 1999a). Armour ym. (1999a) toteavat myös, että on käytännössä mahdotonta kuvata koko organisaation kattavaa kokonaisarkkitehtuuria yhdeltä istumalta, sillä teknologiset ja toiminnalliset olosuhteet muuttuvat niin nopeasti, että kokonaisarkkitehtuuri ehtii vanhentua ennen valmistumistaan. Kokonaisarkkitehtuurin kuvausten määrittelyyn tulisi nähdä vaivaa ja tehdä se huolella, jotta ei tapahtuisi niin kutsuttua ylimallintamista, jossa mennään liian yksityiskohtaiselle tasolle (Rhodes ym., 2009). Mikäli kokonaisarkkitehtuurin kuvausten tasoa ei ole ennalta määritetty, voi arkkitehti ylianalysoida kuvaamisen määrää, eli joutua ns. ”analyysiparalyysiin” (Armour ym., 1999b). On haastavaa valikoida tarkoitukseen sopiva kokonaisarkkitehtuurin viitekehys, sillä erilaisia viitekehyksiä on valtava määrä (Rhodes ym., 2009; Armour ym., 1999a). Tämän lisäksi kokonaisarkkitehtuuriviitekehykset ovat usein liian abstrakteja, eivätkä kykene huomioimaan organisaatiolle tärkeitä asioita tarpeeksi hyvin (Niemi, 2009). Sen sijaan usein huomataan, että kokonaisarkkitehtuuriviitekehykset katsovat organisaatiota liian teknologisesta näkökulmasta (Janssen & Hjort-Madsen, 2007; Seppänen 2014, 108). Kokonaisarkkitehtuurissa törmätään myös usein tiedon hallintaan ja dokumentointiin liittyviin haasteisiin. Kokonaisarkkitehtuuriin liittyvän tiedon dokumentointi ja hyödyntäminen on heikolla tolalla ja arkkitehtuuriin liittyvät perustelut on usein heikosti dokumentoitu johtaen siihen, että tehtyjä päätöksiä on haastavaa seurata ja jäljittää (Armour ym., 1999b). Tämän lisäksi dokumentaatio on sekavaa, sillä mallinnuksia 39 tuotetaan monilla eri työkaluilla (Shah & El Kourdi 2007, 40). Käytettävissä olevat työkalut saattavat olla puutteellisia ominaisuuksiensa suhteen, eikä niillä välttämättä pysty tuottamaan kattavia ja selkeitä mallinnuksia (Seppänen 2014, 110). 3.8 Ratkaisuja kokonaisarkkitehtuuriin liittyviin haasteisiin Kirjallisuudesta pyrittiin löytämään ratkaisuja edellä esiteltyihin tyypillisimpiin haasteisiin mahdollisimman konkreettisella tasolla. Näitä ratkaisuja on jaoteltu samaan tapaan kuin edellä ja löydökset on koottu yhteen taulukossa 3. Jotta kokonaisarkkitehtuurityössä voitaisiin onnistua ja tarvittavat resurssipanostukset kokonaisarkkitehtuuriin tulisi tehtyä, olisi tärkeää, että kokonaisarkkitehtuurityön johtamiseen panostetaan. Rouvarin ja Pekkolan (2024, 87) mukaan korkeatasoinen kokonaisarkkitehtuurin johtaminen on edellytys onnistuneille kokonaisarkkitehtuuriprojekteille. Yksi kehitysaskeleista voisi olla se, että sekä IT:n että liiketoiminnan johtoporras osallistuisi kokonaisarkkitehtuuriin liittyvien tavoitteiden luomiseen ja päätöksentekoon, ja päätösvastuullisista henkilöistä tulisi viestiä selkeästi kaikille, jota asia koskettaa (Espinosa & Boh 2009, 7). Espinosa ja Boh (2009, 7) lisäävät, että näitä tavoitteita luodessa, tulisi olla selkeät mittarit olemassa siihen, mitkä asiat ovat organisaatiolle tärkeitä, jotta pystytään keskittymään relevantteihin asioihin. Lisäksi arkkitehtuuriryhmän tavoitteet pitäisi ohjata liiketoiminnan kehityksestä lähtöisin (Espinosa & Boh 2009, 7). Organisaatiossa tulisi pitää mielessä, että kustannusten pienentäminen IT:n suhteen tapahtuu todennäköisesti IT:n kustannuksella ja tästä syystä päätöksenteossa tulisi hyödyntää monia viitekehyksiä eri näkökulmista, jotta tärkeimmät tavoitteet kirkastuisivat (Espinosa & Boh 2009, 7). Langen ja muiden (2016, 427) mukaan johtotason tulisi jollain tavalla osallistua projektityöskentelyyn toimiakseen roolimalleina kokonaisarkkitehtuurityölle ja sen johtamiselle. Tämä edesauttaa kokonaisarkkitehtuurityön ja sen johtamisen ’ankkurointia’ osaksi organisaation toimintaa (Lange ym. 2016, 427). Lange ym. (2016, 427) kehottavat keskittymään kokonaisarkkitehtuurityön johtamisessa ihmisiin prosessien ja muodollisuuksien sijasta, sillä on tärkeää saada ihmiset omaksumaan aiheen tärkeys ilman pakotettuja sääntöjä ja ohjeistuksia. Tämä johtaa todennäköisesti parempaan kokonaisarkkitehtuurin hyödyntämisen organisaation projekteissa. Yhteistyö sekä IT:n että liiketoimintojen välillä voisi tehostua Espinosan ja Bohin (2009, 7) mukaan esimerkiksi siten, että IT:n rooli olisi toimia liiketoimintayksiköiden kumppanina ohjaamassa oikeanlaiseen kokonaisarkkitehtuurin toteuttamiseen. Lisäksi voisi olla hyödyllistä, että eri yksiköiden henkilökuntaa tuotaisiin yhteen erilaisten porkkanoiden, kuten tunnustuksen antamisen avulla (Espinosa & Boh 2009, 7). Op’t Land, Proper, Cloo ja Steghuis (2009) toteavat, että kokonaisarkkitehtuuria tulee tarkastella ja käsitellä jatkuvana prosessina, jonka pitää olla synkronoituna ympäristön muutoksiin ja organisaation, sen strategian ja operatiivisten prosessien, kehitykseen. Tämä tulisi siis selkeyttää kaikille kokonaisarkkitehtuurin parissa organisaatiossa työskenteleville henkilöille. 40 Kuten Lucke ja Lechner (2010, 7) totesivat, on kokonaisarkkitehtuuriin liittyvän ymmärrettävän viestinnän tärkeys suuri. Jotta tämä voisi toteutua, tulisi tehokkaan viestinnän ja yhteistyön olla yksi organisaation arkkitehtuuriperiaatteista ja sen tulisi sisältää periaatepäätöksen, perustelut ja käytännön merkityksen (Rouvari & Pekkola 2024, 87). Rouvari ja Pekkola (2024, 86) toteavat myös, että viestintään ja yhteistyöhön liittyviä riskejä pystyy hallitsemaan tekemällä viestintäsuunnitelman ja luomalla eri sidosryhmille suunnattuja arkkitehtuuria selventäviä dokumentteja. Ymmärryksen kasvattamiseksi ja yhteisen kielen kehittämiseksi eri toimintojen välillä Espinosan ja Bohin (2009, 7) tutkielmassa ehdotetaan säännöllistä kommunikaatiota IT:n ja liiketoiminnan välillä, eri toimintojen edustajista koottuja työryhmiä sekä koulutusten järjestämistä puolin ja toisin. Lisäksi arkkitehtuuriryhmän ammattitaidon laajentamista ja syventämistä eri toimintoihin liittyen ehdotettiin, jotta arkkitehtuuriryhmä pystyisi paremmin kommunikoimaan sekä IT:n että liiketoiminnan kanssa (Espinosa & Boh 2009, 7). Yhteistyötä ja kommunikaatiota voisi myös helpottaa erityinen kokonaisarkkitehtuuriyhteyshenkilön rooli, joka olisi vastuussa seurannasta ja kokonaisarkkitehtuuriin liittyvien asioiden edistämisestä (Espinosa & Boh 2009, 7). Onnistuneen kokonaisarkkitehtuurin toteuttamiseksi organisaation siis tulee omata riittävästi osaamista ja tietoa kokonaisarkkitehtuurista (Shanks ym. 2018, 143). Kokonaisarkkitehtuuriin liittyviä kyvykkyyksiä ja resursseja tulee asemoida organisaation sisälle, jotta prosessit olisivat paremmin linjassa keskenään, niitä pystytään kehittämään ja jotta sekä IT:n että liiketoimintojen aloitteet ja projektit saavat asiaankuuluvaa neuvontaa (Shanks ym. 2018, 143; Wetering ym. 2020, 16). Lisäksi kokonaisarkkitehtuuriasiantuntijoiden tulee tietää tarpeeksi organisaation eri prosesseista, toiminnoista ja tietojärjestelmistä, jotta he pystyvät rakentamaan käsitteellisiä yhteyksiä IT-mallien, liiketoimintamallien ja etenemissuunnitelmien välille (Shanks ym. 2018, 143). Projektisuunnitelmissa tulisi ottaa kantaa riittävään ja tarpeeksi osaavaan resurssiin, jotta matkan varrella tulevia haasteita voidaan taklata ennakkoon (Rouvari & Pekkola 2024, 86). Aiemmin todettiin, että pula osaavista arkkitehdeistä on suuri haaste kokonaisarkkitehtuurin toteuttamiselle. Seppäsen, Heikkilän ja Liimataisen (2009, 119) haastattelututkimuksessa esitettiin idea, että olisi hyödyllistä perustaa arkkitehtien alusta tai ryhmä, josta voisi löytää sopivalla arkkitehtuuri- ja toimialaosaamisella varustettuja henkilöitä tuottamaan kokonaisarkkitehtuuria. Kokonaisarkkitehtuurityön monimutkaisuutta taklatakseen organisaation tulee lähteä siitä, että kokonaisarkkitehtuurilla on selkeästi määritellyt tavoitteet, jotka on johdettu organisaation strategiasta, ja joita päivitetään säännöllisesti (Schmidt & Buxmann 2017, 183). On lisäksi varmistettava, että kokonaisarkkitehtuuria tehdään jatkuvana prosessina, ei projektimaisesti, ja valmistetaan se muutoksille, jotta ympärillä muuttuvat olosuhteet pystytään ottamaan huomioon (Seppänen 2014, 157; Kaisler ym., 2005). Myös Kaisler ym. (2005) näkee, että arkkitehtuuri tulee suunnitella ja rakentaa muuttumaan, ei kestämään. Tanskan hallinnossa kokonaisarkkitehtuurin monimutkaisuutta on torjuttu luomalla niin kutsuttu käsikirja, joka kuvaa geneeristä arkkitehtuuriprosessia. Käsikirjasta löytyvä malli perustuu Zachmanin viitekehykselle mutta on 41 yksinkertaistettu versio siitä. Tämä malli (kts. Kuvio 16) keskittyy ennemmin kuvaamaan suunnitteluprosessia kuin Zachmanin viitekehyksen eri artefakteja. Mallista löytyy periaatteet kokonaisarkkitehtuurin toteuttamiselle, jotka ovat yksinkertaisuudessaan (1) yhteentoimivuus, (2) turvallisuus, (3) avoimuus, (4) joustavuus ja (5) skaalautuvuus. Näillä periaatteilla varmistetaan se, että kokonaisarkkitehtuurityö on relevanttia ja tarpeeseen tehtyä. (Janssen & Hjort-Madsen, 2007.) Kuvio 16 Mukaillen Tanskan hallinnon kokonaisarkkitehtuurin prosessimalli Kokonaisarkkitehtuurin viitekehyksen valinta on tärkeä onnistumistekijä julkisen organisaation ICT-kehitysprosessissa (Hirvonen, Pulkkinen & Valtonen, 2007). Hirvonen kumppaneineen (2007) listaa valintakriteerejä, joita hyödyntämällä viitekehyksen valinnassa voidaan onnistua. Näitä valintakriteerejä on havainnollistettu teemoitetusti taulukossa 2. 48 tuotokset (engl. Project Exclusive Design, PED). PSA:ssa keskeistä on kuvata kyseisen projektin kannalta keskeiset kokonaisarkkitehtuurin linjaukset sekä haluttu tavoitetila. PSA:n avulla kokonaisarkkitehtuuria lähdetään toteuttamaan projektissa niin, että lopputuotokset (PED) vastaavat alussa sovittuja linjauksia ja tavoitteita. Projektin päättyessä lopputuotoksia voivat olla esimerkiksi toiminta- tai järjestelmäarkkitehtuurikuvaukset. (Foorthuis & Brinkkemper 2008, 38–39.) Röglinger, Bolsinger, Häckel ja Walter (2016, 5) esittelevät artikkelissaan muutostiekartan, jonka avulla kokonaisarkkitehtuurinäkökulma kytketään osaksi organisaation muutosprojektia. Myös Gellweilerin (2020, 107) tutkimus puoltaa tätä ajattelua, sillä hänen mukaansa tiekartoitus edesauttaa ICT-projek- tien ja liiketoiminnan välisten suhteiden kytkemistä toisiinsa. Kokonaisarkkitehtuurin näkökulmasta katsottuna tiekarttamenetelmä tuo näkyväksi arkkitehtuurin nykytilan ja tulevaisuuden tilan, kun taas projektien näkökulmasta tiekartoituksen avulla projektit liitetään osaksi strategiaa ja samalla voidaan määritellä projektien riippuvuudet, tavoitteet, riskit ja kustannukset. Tiekartta toimii perustana toteutettaville muutoksille, minkä avulla muutoksiin voidaan vastata integroidulla lähestymistavalla. (Gellweiler 2020, 107; Röglinger ym. 2016, 5; Langermeier & Bauer 2018, 98.) Onnistuneen tiekarttatyöskentelyn edellytyksenä on strategisista suuntaviivoista sopiminen, joka edellyttää sekä kokonaisarkkitehtuurin parissa työskentelevien tahojen sekä projektinsalkun hallinnasta (engl. Project Portfolio Management, PPM) vastaavien tahojen tiivistä yhteistyötä. Keskeistä on, että molemmat tahot laativat osaltaan etenemissuunnitelmat, jotka sovitetaan yhteen tiekarttatyöskentelyssä. Etenemissuunnittelussa tulee huomioida liiketoiminnan ja teknologian eri näkökulmat, ja yhdistää nämä toisiinsa. Lisäksi suunnittelussa tulee huomioida projektien välinen vuorovaikutus, jotta saadaan varmistettua riittävä tiedon kulku ja resurssit eri projekteihin. (Gellweiler 2020, 107; Röglinger ym. 2016, 8–9.) Tiekartan tavoitetilan määrittelyssä voidaan käyttää apuna korkean tason toiminnallisia vaatimuksia, kuten Röglinger ym. (2016, 9–10) ovat tutkimuksessaan tehneet. Tavoitetilan lähtökohdaksi asetettiin arvontuottaminen, ja vaatimukset jaoteltiin kokonaisarkkitehtuurin tasojen mukaisesti liiketoiminta-, prosessi- ja organisaatiosekä IT-vaatimuksiin (Kuvio 17). Toiminnalliset tavoitteet liittyivät mm. kassavirtaan, riskienhallintaan ja tiedon tarpeisiin, prosesseihin ja organisaatioon liittyvät vaatimukset liittyivät automatisointi-, standardisointi- ja projektienhallintatarpeisiin ja IT-vaatimukset liittyivät mm. käytettävyyteen ja tiedon laadukkuuteen. (Röglinger ym. 2016, 9–10.) 49 Kuvio 17 Tavoitetilan määrittely (mukailtu lähteestä Röglinger ym. 2016, 9–10) Tiekarttamenetelmän strategisen suunnittelun lopputuotoksena syntyy varsinainen tiekartta, joka tähtää organisaation tavoitearkkitehtuurin toteutumiseen (Langermeier & Bauer 2018, 98). Tiekartta toimii organisaation yhteisenä, strategiaan pohjautuvana yleissuunnitelmana, jonka avulla voidaan vastata organisatorisiin ja teknisiin vaatimuksiin ICT-projekteissa, joissa pyritään tuottamaan arvoa (Kuvio 18). (Gellweiler 2020, 107–108.) Kuvio 18 Kokonaisarkkitehtuurin ja projektisalkun yhteensovittaminen tiekartan avulla (mukailtu lähteestä Gellweiler 2020, 108) 4.2.1 Kokonaisarkkitehtuurikatselmoinnit Kokonaisarkkitehtuuria ja projekteja käsittelevässä kirjallisuudessa yhtenä keskeisimmistä teorioista mainitaan arkkitehtuurikatselmoinnit. Foorthuisin ja Brinkkemperin (2008, 36) mukaan arkkitehtuuriarviointien avulla voidaan 50 katselmoida, ovatko projektin tuotokset linjassaan yrityksen kokonaisarkkitehtuurin kanssa. Myös Andersen ym. (2015, 4089) puoltavat arkkitehtuurikatselmointien suorittamista, jotta voidaan varmistua, että työskentely edistää organisaation kokonaisarkkitehtuuritavoitteita. Kokonaisarkkitehtuurin vaatimustenmukaisuuden (engl. EA compliance, suom. EA:n mukaisuus) katselmoinnit eivät ole vielä saaneet osakseen paljon huomiota (Liimatainen, Heikkilä & Seppänen 2008, 272–273). Projektin näkökulmasta kokonaisarkkitehtuuri toimii ikään kuin sopimuksena, jota projektissa tulee noudattaa. EA:n mukaisuus voidaan määritellä niin, että organisaation liiketoiminta- ja IT-järjestelmät noudattavat ennalta sovittuja kokonaisarkkitehtuurin malleja ja periaatteita. Koko organisaation ja sen alaisten toimintojen tulisi noudattaa kokonaisarkkitehtuurin vaatimuksia, mutta varsinaiset arkkitehtuurikatselmoinnit tulee toteuttaa sillä tasolla, jossa kokonaisarkkitehtuuria sovelletaan, eli projekteissa. Projektitasolla tapahtuvat katselmoinnit mahdollistavat vaatimustenvastaisen toiminnan korjaamisen. (Brinkkemper, Foorthuis, Hofman & Bos 2012, 45.) Brinkkemperin ja muiden (2012, 51–52) mukaan kokonaisarkkitehtuurin vaatimustenmukaisuuden katselmointiprosessi vaatii periaatetason linjauksia. Näistä ensimmäinen on, että vaatimustenmukaisuuden arviointi tulee tehdä sellaisen tahon toimesta, joka ei ole mukana varsinaisen projektin toteutuksessa. Toinen tärkeä periaatteellinen linjaus on, että arkkitehtuurikatselmointeja ei suoriteta ainoastaan projektin loppuvaiheessa, koska tällöin arkkitehtuuriin liittyvät päätökset on jo toteutettu ja perumista on tässä vaiheessa vaikeaa enää tehdä. Vaatimustenmukaisuuden arvioinnit tulee toteuttaa projektin elinkaaren aikana siinä vaiheessa, kun projekteissa tehtävät päätökset ovat kypsyneet, mutta niitä ei ole vielä viety toteutukseen. Kolmantena periaatteena on, että kokonaisarkkitehtuurin vaatimustenmukaisuuden tulee ohjata projektien toimintaa heti alusta lähtien, eli vaatimustenmukaisuus tulee sisään rakentaa osaksi projekteja, jotta sääntöjä ja periaatteita noudatetaan alusta lähtien. Kokonaisarkkitehtuurin vaatimustenmukaisuuden katselmointi toteutetaan projektin elinkaaren aikana kolme kertaa: liiketoiminta-analyysin ja suunnitteluvaiheen jälkeen, toiminnallisen vaatimusmäärittelyn ja järjestelmäarkkitehtuurin määrittelyvaiheen jälkeen sekä lopullisen ratkaisutoimituksen jälkeen. Vaatimustenmukaisuuden katselmointiprosessi on esitetty kuviossa 19. Katselmointiprosessi alkaa valmisteluvaiheella, jossa kokonaisarkkitehti valmistelee katselmointiprosessin keräämällä lähtötilanteesta tarvittavat tiedot sekä viimeisimmät versiot kokonaisarkkitehtuurikuvauksista. Seuraavassa vaiheessa projektin artefaktit käydään läpi kokonaisarkkitehdin toimesta, mikä tarkoittaa vaatimustenmukaisuustarkistusten käyttöä niiden kokonaisarkkitehtuurilinjausten arvioimiseksi, joita sovelletaan kyseisessä projektissa. Tämän jälkeen kokonaisarkkitehti katselmoi projektin yhteensopivuuden suhteessa kokonaisarkkitehtuuriin ja arvioi projektin kokonaisarkkitehtuurin vaatimustenmukaisuutta. Tästä syntyy tuotoksena EA:n vaatimustenmukaisuusraportin ensimmäinen versio. Vaatimustenmukaisuusraportista keskustellaan projektiryhmän kanssa, jotta tiedetään, onko raporttia tarpeen selkeyttää ja onko vaatimustenmukaisuuskatselmoinnin tulokset relevantteja. Mikäli tuloksissa ilmenee korjattavaa, palataan 51 artefaktien arviointikohtaan. Katselmointiosuuden ja projektiryhmän kanssa käydyn keskustelun jälkeen kokonaisarkkitehti laatii EA-palauteraportin, johon kirjataan katselmoinnissa havaitut huomiot sekä mahdolliset heikkoudet ja lisätoimenpiteet. Tämän jälkeen EA:n vaatimustenmukaisuusraportti jaetaan tarvittaville sidosryhmille. (Brinkkemper ym. 2012, 52–54.) 4.2.2 Kokonaisarkkitehtuurin hyödyt projekteille Foorthuis ym. (2016, 5–7) esittävät, että kokonaisarkkitehtuurin avulla projektien resursseja ja aikaa voidaan säästää, kun kokonaisarkkitehtuurin käytänteet ohjaavat kehitystyötä. Näin ollen kokonaisarkkitehtuurin avulla voidaan pienentää Kuvio 19 Mukaillen Kokonaisarkkitehtuurin vaatimustenmukaisuuden katselmointiprosessi (Brinkkemper ym. 2012, 53) 52 projektien kustannuksia ja kestoa. Kokonaisarkkitehtuurin käyttö projekteissa edistää projektinhallinnan käytäntöjä, projektin viestintää ja projektinhallinnan kypsyystasoa, mikä osaltaan edesauttaa organisaatioita toteuttamaan projekteja paremmin ja saavuttamaan paremmat lopputulokset (Atteniko ym. 2022, 19; Lange, Mendling & Recker 2016, 424). Kokonaisarkkitehtuurista löytyvien viitekehysten ja holististen näkökulmien avulla projektien johtamista pystytään parantamaan ja samaan aikaan projekti voidaan paremmin yhteensovittaa kontekstiinsa, jotta sen laatua voidaan parantaa. Kokonaisarkkitehtuuri nopeuttaa ja yksinkertaistaa projektien toteuttamista, kun projektien laajuutta voidaan määritellä paremmin ja turhia aktiviteetteja karsitaan. Kokonaisarkkitehtuuri voi pienentää projektin riskejä ja kasvattaa projektien onnistumisen mahdollisuuksia. Kokonaisarkkitehtuurin tavat luoda näkymää eri alustoille, sovelluksiin, prosesseihin ja muihin projekteihin edesauttavat ennakointia riskien suhteen. Kokonaisarkkitehtuurin keinoin ratkotaan myös organisaatiotason haasteita, jonka myötä myös projektien riskit pienenevät ja onnistumisen mahdollisuudet kasvavat, kun projektien lähtökohdat ovat läpinäkyvämmät ja varmemmat. (Foorthuis ym., 2016, 5–7.) Etenkin suurissa ICT-muutoshankkeissa ja -projekteissa kokonaisarkkitehtuurin arvo nousee suureksi. Suurten organisaatioiden ICT-projektit ovat tyypillisesti laajoja ja monimutkaisia, ja niiden kompleksisuutta lisää entisestään sidosryhmien suuri määrä sekä asiakkaiden ja yhteistyökumppaneiden heterogeeniset IT-infrastruktuurit. (Kanin & Drews 2022, 77.) 53 Tässä kappaleessa esitellään tutkimuksen tavoite, esitellään tutkimuksen kohde sekä kerrotaan tutkimuksessa hyödynnetyistä menetelmistä, jotka on valittu tukemaan alkuperäisen tavoitteen toteutumista. Lisäksi kappaleessa esitellään perustelut menetelmien valinnalle. 5.1 Tutkimuksen tavoite Tämän pro gradu-tutkielman perimmäisenä tavoitteena on kokonaisarkkitehtuurin kehittäminen Keski-Suomen hyvinvointialueen ICT-projekteissa. Toimeksiantajan kanssa keskusteltiin tarpeesta ICT-projektien kokonaisarkkitehtuurityön kehittämiselle, jotta kokonaisarkkitehtuuria ja sen keinoja saataisiin jalkautettua paremmin osaksi ICT-projekteja ja kokonaisarkkitehtuurityön tasoa pystyttäisiin nostamaan. Aihetta lähestytään ensin kirjallisuuden ja teorian kautta selvittämällä, kuinka kokonaisarkkitehtuuri voi tukea organisaatiomuutosta ja ICT-projekteja. Kokonaisarkkitehtuurityötä ja sen keinoja organisaatiossa tutkitaan tarkastelemalla ICT-muutoshanketta ja käynnissä olevia ICT-projekteja. Näiden osa-alueiden avulla pyritään vastaamaan tutkimuskysymyksiin ja tutkimuksen tavoitteeseen. 5.2 Kohdeorganisaation esittely Keski-Suomen hyvinvointialue Hyvaks vastaa noin 273 000 keskisuomalaisen sosiaali-, terveys- ja pelastustoimen palveluista (Hyvaks, 2023). Keski-Suomen hyvinvointialue aloitti toimintansa vuonna 2023, jolloin sen järjestämisvastuulle siirtyi yhteensä 22 kunnan (Hankasalmen, Joutsan, Jyväskylän, Jämsän, Kannonkosken, Karstulan, Keuruun, Kinnulan, Kivijärven, Konneveden, Kyyjärven, 5 TUTKIMUKSEN TAVOITTEET, KOHDEORGANISAATIO JA MENETELMÄT 54 Laukaan, Luhangan, Multian, Muuramen, Petäjäveden, Pihtiputaan, Saarijärven, Toivakan, Uuraisten, Viitasaaren ja Äänekosken) sosiaali- ja terveydenhuollon sekä pelastustoimen palveluiden järjestäminen. Hyvinvointialueen vastuulle siirtyi myös aiemmin Keski-Suomen sairaanhoitopiirin järjestämisvastuulla olleet erikoissairaanhoidon palvelut (Terveyden ja hyvinvoinnin laitos, 2022, 11.) Hyvaksin tavoitteena on edistää hyvinvointialueen asiakkaiden hyvinvointia, terveyttä ja turvallisuutta Keski-Suomen alueella vaikuttavasti ja laajalla yhteistyöllä. Lisäksi Hyvaksin tavoitteena on olla ihmislähtöisin hyvinvointialue ja tukea keskisuomalaisten hyvää arkea. Hyvaksin organisaatio jakautuu sosiaali- ja terveyspalveluiden, pelastustoimen palveluiden ja konsernipalveluiden toimialoihin. Keski-Suomen hyvinvointialuetta johtaa tutkimuksen tekoaikaan hyvinvointialuejohtaja Jan Tollet. Sosiaali- ja terveyspalveluiden toimialaan kuuluu koko hyvinvointialueen sosiaali- ja terveyspalvelut perustasolta erityistasolle. Pelastustoimen toimialaan kuuluu hyvinvointialueen pelastustoiminta, riskienhallinta ja ensihoito. Konsernipalveluiden toimialaan kuuluu strateginen johtaminen ja järjestäminen, palvelutuotannon tukipalvelut sekä johtamisen tukipalvelut, johon kuuluu myös tietohallinnon toiminnot. (Hyvaks, 2023.) Keski-Suomen sosiaali- ja terveydenhuollon palvelut on järjestetty ennen hyvinvointialuetta hajautetusti. Palveluista on vastannut alueen 22 kuntaa sekä Keski-Suomen sairaanhoitopiirin kuntayhtymä. Palveluiden hajautunut järjestämisvastuu on heijastunut hyvinvointialueen valmisteluun, sillä hallinnollisesti integroituun järjestämistapaan siirtyminen edellyttää runsaasti valmistelevaa työtä. (Terveyden ja hyvinvoinnin laitos, 2022, 5) 5.3 Tutkimuksen osallistujat kohdeorganisaatiosta Tutkimuksessa haastateltiin Keski-Suomen hyvinvointialueen tietohallinnon edustajia, toiminnan edustajia sekä organisaation ulkopuolisia konsultteja, ketkä ovat olleet tiiviisti mukana Keski-Suomen hyvinvointialueen ICT-muutoshank- keessa ja ICT-projekteissa. Haastateltavat on jaoteltu karkeasti roolin mukaan taulukossa 4, kuitenkaan enempää rooleja avaamatta, jotta anonymiteetti voidaan säilyttää. Haastatteluja suoritettiin yhteensä 12 kappaletta. Haastateltavat olivat rooleiltaan johdon edustajia, päällikkötason edustajia sekä erilaisissa arkkitehtirooleissa toimivia henkilöitä. Haastateltavat valittiin sen perusteella, että heillä on ollut keskeinen rooli ICT-muutoshankkeessa ja ICT-projekteissa. Laadullisessa tutkimuksessa aineistonkeruu suoritetaan usein haastatteluiden, kirjallisten materiaalien ja havainnoinnin avulla. Havaintoja pystytään tuottamaan yhdistelemällä erilaisia aineistonkeruumenetelmiä. Tässä tutkimuksessa käytettiin yksilöhaastatteluita sekä dokumenttianalyysia kohdeorganisaatiossa tuotetuista materiaaleista. Tutkimuskysymyksiin vastaamisen kannalta oli asiaankuuluvaa haastatella organisaation ICT-projektien tekemisen ytimessä olevia henkilöitä, jotta saatiin muodostettua kattava kuva kokonaisarkkitehtuurin hyödyntämisestä haastateltavien omia havaintoja hyödyntämällä. Tueksi näille 55 havainnoille katselmoitiin Keski-Suomen hyvinvointialueen kokonaisarkkitehtuuria koskevia dokumentteja, joihin tutkimuksen tekijöillä oli pääsy. Taulukko 4 Haastateltavien roolit Haastateltava Rooli H1 Tietohallinto H2 Tietohallinto H3 Toiminta H4 Ulkopuolinen konsultti H5 Tietohallinto H6 Tietohallinto H7 Ulkopuolinen konsultti H8 Toiminta H9 Ulkopuolinen konsultti H10 Tietohallinto H11 Ulkopuolinen konsultti H12 Tietohallinto 5.4 Näkökulmat Haastattelurunko rakennettiin sekä kirjallisuudesta että toimeksiantajan tarpeesta nousseiden ennalta määritettyjen näkökulmien ympärille: 1. Kokonaisarkkitehtuuri ICT-muutoshankkeessa 2. Kokonaisarkkitehtuuri ICT-projekteissa 3. Kokonaisarkkitehtuurin kehittäminen yleisesti. Läpileikkaavana aihepiirinä haastattelussa toimi kokonaisarkkitehtuuri, josta keskusteltiin kaikissa haastatteluissa eri vinkkeleistä katsottuna. Näillä näkökulmilla saatiin muodostettua kehys, joka kuvaa loogisesti kokonaisarkkitehtuurin hyödyntämisen tilaa historiassa ja nykyhetkessä, sekä saatiin muodostettua kehitysideoita tulevaisuutta ajatellen. 5.5 Tutkimusote Tässä tutkimuksessa pyritään lisäämään ymmärrystä siitä, miten kokonaisarkkitehtuurilla voidaan tukea paremmin organisaatiossa tapahtuvia muutoksia ja ICT-projektien onnistumista. Lisäksi tutkimuksessa pyritään selvittämään, miten kokonaisarkkitehtuuria ja sen keinoja on hyödynnetty kohdeorganisaation ICT- muutoshankkeessa ja ICT-projekteissa. Tutkimuksen avulla 56 kohdeorganisaatiolle halutaan tuottaa lisäarvoa, jotta kokonaisarkkitehtuuria voitaisiin hyödyntää paremmin tulevaisuuden ICT-projekteissa. Tutkimukseen valittiin kvalitatiivinen eli laadullinen tutkimusote. Laadullisessa tutkimusotteessa tutkitaan erilaisia ilmiöitä mahdollisimman syvällisesti. Laadullisen tutkimusotteen tarkoituksena on ymmärtää reaalimaailman ilmiöitä ja ongelmia, ja tutkimusotteessa keskeistä onkin pyrkiä ymmärtämään yksilöiden tai ryhmien kokemuksia, mielipiteitä, käyttäytymistä sekä merkityksiä, jotka liittyvät niihin. (Moser & Korstjens 2017, 271–272.) Laadullinen tutkimusote valittiin, sillä tässä tutkimuksessa haluttiin selvittää yksilöiden henkilökohtaisia kokemuksia ja mielipiteitä, sekä näiden taustasyitä kokonaisarkkitehtuurin hyödyntämiseen liittyen. Tätä tukemaan tehtiin lisäksi dokumenttianalyysi organisaation saatavilla olevista kokonaisarkkitehtuuriin liittyvistä materiaaleista. 5.6 Haastattelut Laadullisessa tutkimuksessa yksi keskeisimmistä aineistonkeruumenetelmistä on haastattelu. Haastattelutyyppejä on kolme erilaista, ja näitä ovat strukturoitu haastattelu, puolistrukturoitu tai strukturoimaton haastattelu sekä ryhmähaastattelu. Strukturoituun haastatteluun valmistellaan kattava käsikirjoitus etukäteen, ja tätä käsikirjoitusta noudatetaan tiukasti haastattelussa. Puolistrukturoitu tai strukturoimaton haastattelutapa mahdollistaa vapaamuotoisemman toteutustavan, sillä näissä haastattelutavoissa haastattelua ei käsikirjoiteta tiukasti etukäteen. Tutkija saattaa valmistella tiettyjä kysymyksiä etukäteen, mutta haastatteluihin jätetään tilaa improvisoinnille. Ryhmähaastatteluissa haastateltavia on enemmän kuin yksi henkilö, ja toteutustapa voi olla strukturoitu tai strukturoimaton. (Myers & Newman 2007, 2–4.) Tutkimuksen haastattelut toteutettiin avoimina teemahaastatteluina. Haastatteluita ohjasi puolistrukturoitu haastattelurunko (Liite 1), jossa kysymykset oli valmiiksi etukäteen mietitty, mutta vastauksia ei ollut määritetty etukäteen. Haastattelumenetelmäksi valittiin puolistrukturoitu haastattelutapa, koska haastatteluissa haluttiin varmistaa mahdollisimman avoin ja joustava keskustelu sekä mahdollistaa syventymisen keskusteluissa esiin nouseviin aiheisiin. Vastaukset elivät paljon esimerkiksi haastateltavan roolista tai työnantajasta johtuen ja keskustelun annettiin soljua luonnollisesti. Kaikki ennalta määritellyt näkökulmat käsiteltiin jokaisessa haastattelussa. Kuitenkaan kaikki kysymykset eivät olleet jokaiselle haastateltavalle relevantteja, joten niitä saatettiin keskustelun lomassa ohittaa, mikäli näin parhaaksi katsottiin. Myös haastattelurungon ulkopuolisia lisäkysymyksiä saatettiin kysyä tilanteen mukaan. Haastattelukutsuja lähetettiin 12 kappaletta. Yksi alkuperäisistä haastateltavista joutui perumaan sovitun haastatteluajan, joten tähän nopeasti hankittiin toinen, samankaltaisessa roolissa toimiva henkilö haastateltavaksi. Lopulta haastatteluita saatiin toteutettua yhteensä 12 kappaletta. Teknisesti haastattelut toteutettiin Microsoft Teams -työkalulla. Työskentelyssä hyödynnettiin Microsoft Teamsin nauhoitus- ja 57 litterointityökalua ja samalla toinen haastattelija kirjasi muistiinpanoja ylös haastatteluiden lomassa. Haastatteluiden kesto vaihteli 45 minuutista yhteen tuntiin. Haastatteluita toteutettaessa ei ilmennyt teknisiä haasteita. 5.7 Dokumenttianalyysi Dokumenttianalyysi on yksi laadullisen tutkimuksen menetelmä, jonka avulla sekä sähköisiä että painettuja asiakirjoja voidaan tutkia ja analysoida systemaattisesti. Esimerkkejä tällaisista asiakirjoista ovat sanomalehdet, mainokset, kirjeet, pöytäkirjat, kyselytutkimustulokset sekä organisaatioiden sisäiset dokumentit. (Bowen 2009, 27–28.) Tässä tutkimuksessa aineistoa kerättiin myös käymällä läpi Keski-Suomen hyvinvointialueen ICT-muutoshankkeen aikana syntyneitä kokonaisarkkitehtuuria koskevia dokumentteja. Dokumenttianalyysiä käytettiin tässä triangulaation keinona, jotta haastatteluissa tehtyjä havaintoja saatiin tuettua dokumenttianalyysin löydöksillä. Dokumenttianalyysin avulla haluttiin myös kerätä taustatietoja ja lisätä ymmärrystä tutkimuskohteesta, mikä auttoi myös valmistautumaan haastatteluihin. (Bowen 2009, 28–30.) Dokumenttianalyysillä halutiin erityisesti selvittää, mitä kokonaisarkkitehtuurityöstä on sovittu ICT-muutoshank- keen aloitusvaiheessa, mitkä olivat kokonaisarkkitehtuurityön tavoitteet ja linjaukset, miten kokonaisarkkitehtuurityö organisoitiin sekä millaisia kokonaisarkkitehtuurikuvauksia ICT-muutoshankkeen aikana syntyi. Dokumenttianalyysin aineistonkeruu toteutettiin käymällä läpi ICT-muutoshankkeen aikana syntyneitä dokumentteja sekä Keski-Suomen hyvinvointialueen kokonaisarkkitehtuurikuvauksia. Varsinaiseen dokumenttianalyysiin valittiin lopulta Keski- Suomen hyvinvointialueen ICT-muutoksen hankesuunnitelma, muutoshankkeen arkkitehtuuriryhmän tuottamat dokumentit, arkkitehtuurikuvaukset sekä ICT-muutoshankkeen loppuraportti. Analysoidut dokumentit on esitelty tarkemmin taulukossa 5. Dokumenttianalyysissä käytettiin tarkoituksenmukaista otantamenetelmää, sillä tutkimukseen haluttiin valita mahdollisimman informatiiviset ja tarkoituksenmukaiset lähteet peilaten asetettuihin tutkimuskysymyksiin. Käytettävissä olevaa aineistoa oli olemassa suhteellisen runsaasti, minkä vuoksi kaikkea aineistoa ei ollut järkevää tarkastella, joten tästä syystä dokumenttianalyysiin valittiin aineistot tarkoituksenmukaisesti. (Miller & Alvarado 2005, 350–351.) Dokumenttianalyysiin valitut aineistot valittiin sillä perusteella, että ne tuottivat runsaasti tietoa peilaten asetettuihin tutkimuskysymyksiin, olivat sisällöltään kattavia ja dokumenttien laatijoiden tiedettiin olevan henkilöitä, joilla on laaja tietämys tutkittavasta aiheesta. Dokumenttianalyysin aineistojen valintaa myös helpotti se, että käytössä olleet materiaalit oli laadittu nimenomaan Keski-Suomen hyvinvointialueen ICT-muutoshanketta varten, joten niiden tiedettiin jo ennestään olevan relevantteja tutkimuskohteen kannalta. (Bowen 2009, 33; Elo, Kääriäinen, Kanste, Pölkki, Utriainen & Kyngäs 2014, 4.) 64 Haastateltavista suurin osa totesi, että kokonaisarkkitehtuuria ja sen keinoja on hyödynnetty ICT-muutoshankkeessa. Tämän perään moni totesi, että kokonaisarkkitehtuuria olisi pitänyt pystyä hyödyntämään enemmänkin ja taso on ollut vaihtelevaa. Pieni osa haastateltavista ei tunnistanut, että kokonaisarkkitehtuuria olisi hyödynnetty ICT-muutoshankkeessa, mutta tätä perusteltiin osin sillä, että kokonaisarkkitehtuuria ei välttämättä hyödynnetty juuri sillä tasolla, missä he työskentelivät. “Keski-Suomessa on yleisesti ottaen ollut ihan hyvällä tasolla yhteinen tekeminen. Taso on vaihdellut projektien välillä aika paljon.” H5 “Minulle se ei näkynyt millään tavalla.” H8 Haastateltavia pyydettiin avaamaan tarkemmin, millä tavoilla kokonaisarkkitehtuuri on heidän mielestään näkynyt ICT-muutoshankkeessa, esimerkiksi toimintamallien, arkkitehtuurilinjausten, resurssien ja kuvausten osalta. Useampi haastateltavista mainitsi, että ICT-muutoshankkeessa oli oma arkkitehtuuriryhmä, joka kokoontui viikoittain. Haastateltavien mielestä kokonaisarkkitehtuuria oli resursoitu hyvin ICT-muutoshankkeessa. “Arkkitehtuuria resurssointiin tosi paljon.” H1 “Ratkaisuarkkitehteja ym. tarkemman tason tekemistä on ollut paljonkin.” H5 Varsinaisesta arkkitehtuuriryhmän toiminnasta heräsi keskustelua lähinnä niiden haastateltavien kanssa, jotka olivat toimineet arkkitehdin roolissa ICT-muu- toshankkeessa. Haastateltavat, jotka toimivat muissa rooleissa, eivät juurikaan maininneet arkkitehtuuriryhmästä tai sen toiminnasta mitään, vaikka toki tunnistivatkin, että arkkitehtiresursseja on ollut ICT-muutoshankkeessa saatavilla. “Arkkitehtien kanssa meillä oli ihan järkevää yhteistyötä siitä, että mitenkä me mallinnetaan, millä notaatiolla Archimatessa ja miten kuvataan.” H4 Kuten jo dokumenttianalyysissä kävi ilmi, ICT-muutoshankkeen arkkitehtuuriryhmän tehtävänä oli tuottaa ICT-muutoshankkeelle mm. arkkitehtuurin hallintamalli, arkkitehtuurilinjaukset, toimia ICT-projektien tukena arkkitehtuurityössä sekä tuottaa mallinnuskäsikirjan mukaisia kokonaisarkkitehtuurikuvauksia. Tämä kävikin hyvin ilmi niiden haastateltavien kanssa, jotka olivat olleet mukana ICT-muutoshankkeen arkkitehtuuriryhmässä. “ICT-projekteissa hyödynnettiin ICT-muutoshankkeessa määriteltyjä mallinnuskäsikirjaa, kuvaustapoja ja kuvausvälinettä. Vastuut jakautuivat yhdessä määritellyn hallintamallin mukaisesti. ” H11 Haastateltavat, jotka eivät olleet mukana ICT-muutoshankkeen arkkitehtuuriryhmässä, eivät maininneet keskusteluissa arkkitehtuuriryhmän korkeamman tason tuotoksia, kuten hallintamallia tai mallinnuskäsikirjaa puheissaan. Näiden sijaan haastateltavien puheissa nousi enemmän esiin tehdyt arkkitehtuurikuvaukset, 65 ristiinkäyttötaulukot ja tavoitetilan skenaariot. Lisäksi suurin osa haastateltavista tunnisti, että ICT-muutoshankkeen kokonaisarkkitehtuurityön osalta oli tehty tiettyjä periaatetason linjauksia. Näitä linjauksia olivat, että ICT-muutoshank- keessa keskitytään kuvaamaan tietojärjestelmä- ja osin teknologiatasoa ja että muutoshankkeessa tehdään vain pakolliset ja tarpeelliset kuvaukset. Lisäksi haastatteluissa keskusteltiin siitä, mikä kuvausten tavoitetaso oli. Vastausten perusteella ICT-muutoshankkeessa pyrittiin kuvaamaan järjestelmien nykytilaa ja tavoitetilaa, eli millaisella tietojärjestelmäkokonaisuudella Keski-Suomen hyvinvointialue käynnistää toimintansa vuoden 2023 alussa. Haastatteluissa keskusteltiin paljon ICT-muutoshankkeen aikana tehdyistä kokonaisarkkitehtuurikuvauksista. Erityisesti haastateltavia puhututti se, että toiminta- ja tietoarkkitehtuuritasot jätettiin kuvausten ulkopuolelle. Haastateltavista useampi totesi, että ICT-muutoshankkeessa ei toteutettu aitoa kokonaisarkkitehtuuria, koska muutoshankkeessa kuvattiin puhtaasti tietojärjestelmiä ja teknologioita. “Järjestelmätason kuvat saatiin hyvälle mallille ja niitä on täydennetty sen jälkeenkin.” H2 “Vaikka puhuttiin KA:sta, oli se kuitenkin tietojärjestelmän arkkitehtuurin kuvaamista.” H4 Vastauksista kävi ilmi, että todella moni haastateltavista jäi kaipaamaan erityisesti toiminta-arkkitehtuurin kuvauksia. Haastateltavien mukaan ICT-muutos- hankkeen suunnittelu ja toteutus olisi ollut sujuvampaa, mikäli toiminta-arkki- tehtuuria olisi kuvattu. Yksi haastatelluista koki, että toiminta-arkkitehtuurin kuvausten puute aiheutti merkittäviä riskejä ja haasteita ICT-projektien onnistumiselle. Haastateltavat totesivat myös yhteisesti, että toiminta-arkkitehtuurin kuvaaminen ICT-muutoshankkeessa olisi ollut lähes mahdotonta, sillä valmisteluvaiheessa hyvinvointialueen organisaatiota ja strategiaa ei ollut vielä kunnolla muodostettu eikä toimintaprosesseja ollut kuvattu minnekään. “Arkkitehtuurityön rajausten takia toiminnan tason arkkitehtuurin ymmärryksen ja kuvausten puute heijastui kaikkeen tekemiseen.” H11 “Ei ollut olemassa olevaa organisaatiota, jossa on johto ja jolla on strategia. Organisaatio ei ollut valmiudessa miettimään kokonaisarkkitehtuuria, se ei ollut prioriteetti ykkönen.” H4 Kokonaisarkkitehtuurin hyödyt ja haasteet ICT-muutoshankkeessa Haastateltavia pyydettiin kertomaan, millaisia hyötyjä kokonaisarkkitehtuuritekeminen tuotti ICT-muutoshankkeelle. Suurin osa haastateltavista tunnisti kokonaisarkkitehtuurin hyödyttäneen ICT-muutoshanketta, ja kokonaisarkkitehtuurin kerrottiin auttaneen hahmottamaan kokonaiskuvaa, tekemään muutoksen näkyväksi eri osapuolille ja parantaneen projektien välistä kommunikaatiota. ”Hankkeessa tehdyt ylätason arkkitehtuurikuvaukset ja ohjaus auttoivat huomattavassa määrin korikohtaisten projektien toteutusta.” H11 66 Haastateltavilta kysyttiin, millaisia haasteita he kokivat kokonaisarkkitehtuurityöhön liittyneen ICT-muutoshankkeessa. Lähes poikkeuksetta kaikki haastateltavat olivat kokeneet haasteita kokonaisarkkitehtuurin hyödyntämiseen liittyen. Isona haasteena nähtiin esimerkiksi valtavan hankkeen koko ja siihen liittyvä työmäärä. Moni haastateltavista koki, että kokonaisarkkitehtuurin johdonmukaiseen toteuttamiseen ei ollut yksinkertaisesti aikaa. ”Kokonaisarkkitehtuuria ei yksinkertaisesti ehditty tekemään.” H12 Haasteena kokonaisarkkitehtuurin toteuttamiselle nähtiin myös organisaation keskeneräisyys ja luovuttavilta organisaatioilta saatujen lähtötietojen puute. Useampi haastateltavista totesi, että kunnianhimoista kokonaisarkkitehtuurityötä ei voitu toteuttaa, koska hyvinvointialueen organisaatio oli vielä täysin keskeneräinen ja organisaatiosta puuttui päätöksentekijät. Haasteelliseksi koettiin myös saada lähtötietoja luovuttavilta organisaatioilta esimerkiksi järjestelmien osalta, ja tällaisia kuvauksia ei välttämättä ollut edes tehty. Näin ollen suunnittelua jouduttiin tekemään vajavaisilla tiedoilla. Keskusteluissa nousi esiin myös kokonaisarkkitehtuuriin liittyvän omistajuuden puute. Vastauksista nousi toistuvasti esiin, että kokonaisarkkitehtuurin tekemiselle ei ollut nimetty omistajaa, minkä vuoksi kokonaisarkkitehtuurityön ohjaus jäi vajavaiseksi. Omistajuuden puutteen myötä arkkitehtuuriryhmällä ei koettu olleen riittävän korkeaa päätösvaltaa, jotta ryhmä olisi kunnolla pystynyt ohjaamaan ICT-muutoshankkeen kokonaisarkkitehtuurityötä sekä vaatimaan ICT-muutoshankkeen alaisia työryhmiä toimimaan arkkitehtuuriryhmän periaatteiden ja ohjeiden mukaisesti. Tämä näkyi esimerkiksi siten, että arkkitehtuuriryhmälle ei juurikaan noussut projekteilta asioita linjattavaksi. Haasteista huolimatta lähes poikkeuksetta kaikki haastateltavat totesivat, että ICT-muutoshankkeessa onnistuttiin hyvin ja hyvinvointialueen toiminta saatiin käynnistettyä onnistuneesti vuoden 2023 alussa. “Kaikki keskeiset järjestelmät saatiin vuodenvaihteeseen valmiiksi, ilman suurempia ongelmia ja käyttökatkoja.” H2 ”Muutoshankkeen projektit on onnistunut hyvin, kun ajatellaan, että mittari oli, että hyvinvointialueen toiminta käynnistyy ilman suurempia ongelmia.” H6 6.2.3 Kokonaisarkkitehtuuri ICT-projekteissa ICT-muutoshankkeeseen liittyvien kysymysten jälkeen siirryttiin käsittelemään ICT-projektien nykytilaa. Haastateltavia pyydettiin kuvailemaan omin sanoin, millä keinoilla kokonaisarkkitehtuuria hyödynnetään tällä hetkellä käynnissä olevissa ICT-projekteissa. Haastateltavilta kysyttiin tukevia kysymyksiä riippuen henkilön roolista ja annettiin esimerkkejä kokonaisarkkitehtuurin hyödyntämisen keinoista, mikäli sellainen oli tarpeen. Vastaukset kokonaisarkkitehtuurin hyödyntämiseen ICT-projekteissa vaihtelivat paljonkin haastateltavan mukaan. Osa haastateltavista koki, että käynnissä olevissa ICT-projekteissa hyödynnetään kokonaisarkkitehtuuria 67 kiitettävästi ja sille on ollut enemmän aikaa käytettävissä verrattuna ICT-muu- toshankkeen aikaan. Osa haastateltavista taas totesi, ettei kokonaisarkkitehtuuri ole näkynyt juuri millään tavalla ICT-projekteissa, ja kokonaisuuden hallinta puuttuu projekteista oikeastaan täysin. Tietojärjestelmäarkkitehtuurin tasoon ICT-projekteissa oltiin melko tyytyväisiä, kun taas toiminta-arkkitehtuurin taso tuntui puuttuvan miltei kokonaan. “Isommissa projekteissani on sovittu, että siellä on kokonaisarkkitehti paikalla ja KA:ta tehdään ainakin järjestelmien, teknisen puolen ja tietovarantojen osalta.” H10 “ICT-projekteissa tehdään pistemäisiä ratkaisuarkkitehtuurikuvauksia, kokonaiskuvan hallinta puuttuu. ” H11 Haastateltavia pyydettiin omin sanoin kuvailemaan, mistä asioista johtuu, ettei kokonaisarkkitehtuuria toteuteta tarpeeksi organisaatiossa ja ICT-projekteissa. Moni haastateltava viittasi kokonaiskuvan ja johtamisen puutteeseen. Osa haastateltavista totesi, että kokonaisarkkitehtuurilta puuttuu nimellinen vastuutaho organisaatiossa. Haastateltavien mielestä kokonaisarkkitehtuuria tulisi johtaa strategialähtöisesti yhden tai useamman nimetyn henkilön toimesta. Muutama haastateltava oli sitä mieltä, että organisaatiossa tulisi keskustella enemmän kokonaisarkkitehtuurin tavoitteista ja strategiavisiosta, jotta ICT-projekteissakin osattaisiin toteuttaa sitä halutulla tasolla. Haasteeksi nähtiin myös kokonaiskuvan puutteesta johtuva projektien siiloutuminen, jossa syy-seuraussuhteita muihin projekteihin nähden on hankala hahmottaa. Muutama haastateltava lisäsi, ettei tällä hetkellä organisaatiossa ole kokonaisarkkitehtuurin hallintamallia, joka ohjaisi toimintaa oikeaan suuntaan. ”Projektiin liittyvää arkkitehtuuria ei synkata koko hyvinvointialueen arkkitehtuuriin tällä hetkellä. Meidän pitäisi miettiä, mitä ollaan tekemässä, yhteiset tavoitteet ovat sopimatta.” H10 Haastateltavista useampi totesi, että haastetta tuottaa se, ettei toiminnan puolella ymmärretä tarpeeksi hyvin kokonaisarkkitehtuurin hyötyjä. Lisäksi haastatteluissa kävi ilmi, että kokonaisarkkitehtuurin omistajuutta ei ole hallussa juuri kellään. Muutama haastateltava näki mahdollisena, että mikäli saataisiin tuotettua tarpeeksi hyviä kuvauksia kokonaisuudesta, voitaisiin havainnollistaa toiminnan puolelle miksi kokonaisarkkitehtuuriin kannattaa panostaa myös muualla, kuin tietohallinnossa. Myös haastatteluihin osallistuneet toiminnan edustajat näkivät kokonaisarkkitehtuurin hyödyttävän omaa työtänsä mm. siinä, miten integraatioita pystytään hahmottamaan ja rakentamaan paremmin, sekä siinä, miten toimintamalleja saataisiin yhdistettyä eri paikkakuntien välillä. Toisaalta osa tietohallinnon edustajista kertoi, kokonaisarkkitehtuuri on toiminut hyvänä keskusteluvälineenä toiminnan edustajien kanssa, kun esimerkiksi järjestelmiä ja niiden välisiä integraatioita on mallinnettu kuviksi ICT-projekteissa. Kun haastateltavilta kysyttiin, millaisia haasteita kokonaisarkkitehtuurin hyödyntämiseen liittyy, nosti moni ensimmäisenä asiana osaamisen ja ymmärryksen puutteen. Suurin osa haastateltavista totesi, että kokonaisarkkitehtuurin 68 osaaminen ja ymmärrys sen tuottamista hyödyistä on heikolla tasolla organisaatiossa. Useampi totesi, että kokonaisarkkitehtuuri saatetaan ymmärtää tietojärjestelmä- tai teknologia-arkkitehtuurin kuvaamisena. Tieto- ja toiminta-arkkiteh- tuurin ymmärryksen koettiin olevan hataralla tasolla. Osa haastateltavista sanoi, että liian harva käsittää, mikä kokonaisarkkitehtuurin tavoite on, miten sitä voisi hyödyntää, millä tasolla sitä kannattaisi tehdä ja miten sitä tulisi ylläpitää. ”Haasteena on osaamisen, ymmärryksen ja hyvien esimerkkien puute. Sanana [kokonaisarkkitehtuuri] voi tarkoittaa eri asioita eri henkilöille ja jos ei täysin ymmärrä mistä on kyse, eikä ole nähnyt esimerkkejä, on vaikea onnistua. Ne prosessikuvaukset on niin vaikeita välillä lukea, että ei niistä ymmärrä mitään. Notaatioiden pitäisi olla yleismaailmallisia ja ymmärrettäviä.” H6 ”Kuvaukset pitää saada samanlaisiksi, värikoodauksien ja piirrosten suhteen. Pitää heti pystyä tunnistamaan esim. että tuo kuuluu potilaspalvelutuotantoon, tuo tukipalvelutuotantoon jne.” H3 Lähes kaikki haastateltavat viittasivat haasteita kuvaillessaan resurssien puutteeseen organisaatiossa. Koettiin, että sekä aikaresurssin että rahan näkökulmasta tilanne on haastava projekteissa ja sen takia kokonaisarkkitehtuuri ei ole ollut tekemisen ytimessä. Yksi haastateltavista totesi myös, että koska hyvinvointialue organisaationa on niin valtava kokonaisuus, on kokonaisarkkitehtuurin kunnianhimoinen toteuttaminen liian iso ponnistus. Haastateltavien mukaan projekteissa keskitytään kuvaamaan yksittäisiä ratkaisuja projektikohtaisesti, ei kokonaisuutta ajatellen. Yksi haastateltavista nosti haasteeksi myös sen, että organisaatiosta on puuttunut oma, sisäinen kokonaisarkkitehti, jolla olisi ollut vastuu kokonaisuudesta. Useampi haastateltava mainitsi haasteeksi, että tehtyjä arkkitehtuurikuvauksia ei ylläpidetä niiden luomisen jälkeen. Keskustelussa kävi ilmi, että kuvauksien piirtäminen onnistuu yleensä suhteellisen hyvin, mutta niiden päivittäminen ja ylläpito jää usein tekemättä kokonaan. Tämän koettiin johtuvan osaltaan jo aiemmin mainitusta kokonaisarkkitehtuurin omistajuuden puutteesta. Lisäksi mainittiin, että projekteissa tehtäviä kuvauksia ei usein viedä osaksi ICT- muutoshankevaiheessa tehtyä kokonaiskuvaa. Yksi haastateltavista mainitsi, että projektipäälliköt eivät välttämättä ole projektin jälkeen enää mitenkään liitoksissa tehtyihin kuvauksiin, joten niiden ylläpidon ei pitäisi jäädä projektipäällikön vastuulle. Haasteeksi mainittiin myös se, että koska erilaisia dokumentaatioita ja kuvauksia tehdään usein ulkopuolisten toimittajien ja konsulttien toimesta, saattavat ne jäädä näiden toimijoiden haltuun ja järjestelmiin, joihin hyvinvointialueen henkilöstöllä ei ole pääsyä. Samassa yhteydessä todettiin, että toimittajien kanssa tehdyistä sopimuksista saattaa puuttua maininta, että dokumentaatiot ja kuvaukset tulisi siirtää tilaajan haltuun projektin päätteeksi. Osa haastateltavista totesi, että organisaatiolta puuttuu toimintatapa, missä projektin päätteeksi tarkistettaisiin arkkitehtuurikuvausten tilanne. Lisäksi osalle oli epäselvää, missä kuvauksia säilytetään ja kenellä on pääsy niihin. 69 ”Jos halutaan, että meiltä löytyy kuvauksia kaikilta [arkkitehtuurin] tasoilta, pitäisi varmistaa, ettei ne jää sinne projektin tai järjestelmien syövereihin. Pääsy tai toimintaohje ei ole välttämättä tallessa. Dokumentaatiota ei ole hallittu niin hyvin kuin voisi olla.” H6 ”Kun tilaajana teetämme arkkitehtuurityötä, meidän pitäisi osata omistaa se meidän oma kuva. Se tahtoo jäädä projekteissa yhdelle työpöydälle tai jopa sen toimittajan hallintaan.” H1 Haastateltavien kanssa keskusteltiin kokonaisarkkitehtuuriin liittyvistä toimintamalleista, välineistä ja työohjeista. Moni haastateltavista totesi, että kokonaisarkkitehtuuriin liittyen ei ole olemassa yhteisiä selkeitä käytäntöjä ja pelisääntöjä, joita ICT-projekteissa voisi hyödyntää. Tätä selitettiin osaltaan sillä, että organisaatio on vielä nuori eivätkä toimintamallit ole ehtineet vakiintua. Toisaalta arveltiin, että ennen hyvinvointialueen alkamista myöskään vanhalla sairaanhoitopiirillä ja kunnilla ei ole ollut hyvää pohjatasoa kokonaisarkkitehtuurin toteuttamiseen. Kun keskusteltiin välineistä, muutama haastateltava totesi, että hyvinvointialueella on käytössä kuvaustyökalu Sparx. Tuntuma oli, että kaikille ei ole selkeää mistä kyseinen työkalu löytyy, miten sinne pääsee, eikä sitä osata välttämättä käyttää, toimintaprosesseissa työskentelevistä henkilöistä puhumattakaan. Osa haastateltavista koki haasteena sen, että yhteisiä mallipohjia ja ohjeita, jotka voisivat madaltaa kuvaustyökalujen käyttökynnystä, ei ole riittävästi saatavilla. Haastateltavat kokivat, että yhteiset toimintamallit ja ohjeet kuvausten tuottamiseen projekteissa helpottaisivat arkea ja toisivat työskentelyyn säännönmukaisuutta. Lisäksi nähtiin, että parannettavaa olisi säännöllisten arkkitehtuuripalaverien, tarkistuspisteiden ja katselmointien pitämisessä. ”Projektissa tulisi arvioida, minkälaisesta muutoksesta on kysymys ja sen mukaan siellä vaaditaan niitä KA-tuotoksia. Projektipäällikön tehtävälistalla tulisi olla, että nämä tulee tehtyä.” H6 ”Kaikista isoin haaste minulle tällä hetkellä on se, että mitä kuvataan, millä elinkaarella ja mitkä kuvaustavat on fiksuja. KA:n hyödyt ei tule lyhyellä aikajänteellä, vaan se on pitkäjänteistä mallinnus- ja kuvaamistyötä. Se vaatii systemaattista hallintamallia ja toimintaa.” H4 6.2.4 Miten kokonaisarkkitehtuuria voisi jatkossa hyödyntää Haastattelun viimeisessä osuudessa haastateltavia pyydettiin kertomaan konkreettisia kehitysehdotuksia kokonaisarkkitehtuurityön parantamiseksi Keski- Suomen hyvinvointialueen ICT-projekteissa. Haastatteluissa nousi esiin, että Keski-Suomen hyvinvointialueella tulee lisätä kokonaisarkkitehtuuriin liittyvää ymmärrystä ja osaamista. Haastateltavat olivat yhtä mieltä siitä, että osaamista ja ymmärrystä tulee kehittää läpi organisaation, jotta kokonaisarkkitehtuuria voitaisiin toteuttaa onnistuneesti. Monen mielestä kokonaisarkkitehtuuri nähdään organisaatiossa vain IT:n ja tietohallinnon asiana, vaikka kokonaisarkkitehtuuri on koko organisaation yhteinen asia. Tulosten perusteella kokonaisarkkitehtuurin osaamista ja ymmärrystä tulisi lisätä koulutusten avulla. Tämän lisäksi tärkeänä asiana nähtiin, että 70 organisaatiossa tulisi olla enemmän osaamista kokonaisarkkitehtuurikuvausten tekemiseen ja kuvaustyökalun käyttöön. ”KA:n tärkeyden ymmärtäminen ja sen kehittäminen koko organisaatiossa. On tärkeää, että pysytään ajan hermolla ja hankitaan osaamista työnantajan kustantamana.” H2 ”Olisi tarvetta KA-koulutukselle, jotta saavutettaisiin perusymmärrys KA:sta, mistä siinä on oikeasti kyse, mihin siitä voisi olla apua.” H7 ”Pitäisi olla esimerkkejä olemassa sekä joku koutsaamassa, miten käytetään ja luodaan kuvia. Osaaminen karttuu siinä pikkuhiljaa.” H6 Vastausten perusteella kävi hyvin selkeästi ilmi, että Keski-Suomen hyvinvointialueelle toivotaan sisäistä arkkitehtuuriresurssia tai -toimintoa, joka työskentelisi ICT-projektin tukena ja huolehtisi osaltaan kokonaisarkkitehtuurityön toteutumisesta ICT-projekteissa. Haastateltavien mukaan ihannetilanne olisi, jos Keski- Suomen hyvinvointialueelle olisi palkattu kokonaisarkkitehti, jonka vastuulla olisi kokonaisarkkitehtuurin kokonaisuuden hallinta ja sen lisäksi muita arkkitehtirooleissa toimivia henkilöitä, jotka perehtyisivät syvemmin kokonaisarkkitehtuurin eri osa-alueisiin, kuten toiminta-arkkitehtuuriin. Lisäksi yhdeksi vaihtoehdoksi nostettiin, että hyvinvointialueelle voitaisiin perustaa sisäinen arkkitehtuuriryhmä, joka muodostuisi kokonaisarkkitehtuuriin vihkiytyneistä nykyisistä työntekijöistä. Ryhmä voisi toimia konsultoivana tahona esimerkiksi ICT- projekteissa. Toisena näkökulmana nousi esiin, että kokonaisarkkitehtuuri tulisi kytkeä osaksi ihmisten työtehtäviä, jotta jokainen huolehtisi osaltaan, että kokonaisarkkitehtuuri tulisi huomioitua omassa työssä. ”Ehdottomasti pitäisi olla omaa KA-resurssia ja osaamista hyvinvointialueella. Hyvinvointialueella pitäisi olla oma pääarkkitehti.” H4 ”Pitäisi olla yksi tai useampi työkaluun ja KA:han vihkiytynyt henkilö, joka pitäisi tekemistä yllä ja voisi auttaa tarvittaessa.” H6 Monet haastateltavista kokivat, että kokonaisarkkitehtuurin suhteen organisaatiosta puuttuu tahtotila, visio ja tavoite. Yhden haastateltavan mukaan tähän voisi auttaa se, että yhteistä tavoitetta lähdettäisiin muodostamaan niin, että kokoonnuttaisiin keskustelemaan yhdessä niiden tahojen kanssa, joita asia koskettaa. Haastateltava koki, että tällä keinoin asianosaiset pystyisivät kunnolla keskittymään aiheen äärelle sekä sitoutumaan tavoitteeseen paremmin, kun sitä on ollut mukana muodostamassa. Samalla muodostuisi parempi käsitys siitä, miten erilaisia projekteja toteutetaan ja voitaisiin yhteisesti arvioida, ovatko tekemisen tavat järkeviä ja taloudellisia. Toinen haastateltava oli sitä mieltä, että tavoitteiden muodostamisen pitäisi lähteä liikkeelle toimintakerroksesta niin, että siellä määriteltäisiin ja kuvattaisiin palvelut, joita on pakko tuottaa ja mitä kyvykkyyksiä tähän tarvitaan. Kokonaiskuvan muodostaminen kyvykkyyksistä nähtiin myös tarpeellisena, jotta nähtäisiin, millaisia kyvykkyyksiä organisaatiosta uupuu, miten niitä tulisi kehittää ja missä järjestyksessä. Tavoitteiden, tahtotilan ja vision muodostaminen nähtiin hyödyllisenä myös siitä näkökulmasta, että se 71 auttaisi priorisoimaan tekemistä haastavassa resurssitilanteessa. Haastatteluista kävi ilmi, että linjauksia pitäisi tehdä eri toimintojen roolituksessa suhteessa kokonaisarkkitehtuuriin, eli tulisi määrittää, millaisia erilaisia vastuita esimerkiksi tietohallinnolla, toiminnalla ja toimittajilla on. Kokonaisarkkitehtuurin koettiin olevan erittäin tärkeä työkalu organisaation johtamiselle ja samaan aikaan todettiin, että johtotason tulisi siitä syystä huolehtia, että kokonaisarkkitehtuuria toteutetaan. ”Kokonaisarkkitehtuuri voi auttaa hankkeen kokonaiskuvan muodostamisessa, kokonaisuuden hallinnassa, toimintojen yhteensovittamisessa ja ohjauksessa kohti määriteltyä tavoitetilaa. Kokonaisarkkitehtuurin keinoin varmistettava yhteentoimivuus vähentää myös riskejä, tuo pitkällä aikavälillä kustannussäästöjä ja tukee strategista päätöksentekoa.” H11 Jokaisessa haastattelussa keskusteltiin siitä, miten toiminnan edustajien pitäisi kytkeytyä mukaan kokonaisarkkitehtuurityöhön. Jokainen haastateltava näki tämän tärkeäksi ja koki, että tilanteessa on parantamisen varaa. Osa haastateltavista painotti, että toiminnan edustajien tulisi ymmärtää kokonaisarkkitehtuurin arvo heille itselleen, jotta yhdessä tekeminen olisi sujuvampaa. Moni haastateltavista näki, että yksi suurimmista syistä tälle haasteelle oli kokonaisarkkitehtuurin terminologia, jonka koettiin olevan liian teknistä henkilöille, joilla ei ole IT- taustaa omasta takaa. Ratkaisuksi haastateltavat näkivät "maanläheisemmillä" ja toiminnalle tutummilla termeillä puhumisen. Yksi haastateltava lisäsi, että kokonaisarkkitehtuurista puhuminen case-esimerkkien kautta on usein helpottanut tilanteita. Yhdessä haastattelussa todettiin, että motivoidakseen toiminnan edustajia kiinnostumaan kokonaisarkkitehtuurista, heille pitäisi luoda selkeä kuva kokonaisarkkitehtuurin hyödyistä ja samalla kertoa, että tiedonhallintalaki vaatii tiettyjen kuvauksien olemassaolon ja päivittämisen. ”KA:n terminologia aiheuttaa allergiaa. En itse käytä näitä termejä toiminnan kanssa ollenkaan. Puhun heidän palveluista, prosesseista ja lakisääteisistä tehtävistä. Esim. JHS 179 voi aiheuttaa vastareaktion.” H11 Keskusteluissa nousi esiin, että kokonaisarkkitehtuurin osalta kaivattaisiin enemmän yhteisesti sovittuja toimintamalleja ja –tapoja, jolla kokonaisarkkitehtuuria tulisi toteuttaa ICT-projekteissa. Jotta kokonaisarkkitehtuuria voitaisiin toteuttaa systemaattisesti organisaatiossa, ensin tulisi määritellä kokonaisarkkitehtuurin hallintamalli, periaatteet ja menetelmät, joiden mukaan organisaatiossa toimitaan. Moni haastateltavista koki, että mallipohjaisesta kokonaisarkkitehtuurista voisi olla hyötyä. “Vaatimuksia pitäisi nostaa siinä, että käytetään jotain yhteistä menetelmää tai kokonaisarkkitehtuurin periaatteita projekteissa.” H6 Haastatteluissa nousi esiin, että Keski-Suomen hyvinvointialueella tulisi määritellä minimitaso, mitä kokonaisarkkitehtuurin osalta tulisi huomioida ICT-pro- jekteissa. Minimitason osalta oli havaittavissa pieniä näkemyseroja siitä, mitä pitäisi kuvata ja minkä verran on riittävästi. Osan mielestä minimitaso tulisi 72 määritellä projektin kokoluokan mukaan, koska projektien koot ja niissä tehtävät muutokset vaihtelevat toisistaan paljon. Yhteisen näkemyksen mukaan minimitason tulisi toteutua vähintään niin, että kun projektin yhteydessä jokin asia muuttuu, muutos huomioidaan kokonaisarkkitehtuurikuvauksessa. Enemmistö oli kuitenkin sitä mieltä, että minimitason tulisi olla sellainen, että ICT-projek- tissa tehdään nykytilan ja tavoitetilan kuvaukset ja kuvauksissa huomioidaan kaikki kokonaisarkkitehtuurin tasot, eli toiminta, tieto, järjestelmät ja teknologiat. Kuvausten tason määrittelyssä voitaisiin hyödyntää Lean KA-ajattelua, jonka mukaan kuvauksia tehdään vain tarpeen mukaan ja vain niistä asioista, jotka ovat kohtuullisen pysyviä asioita organisaatiossa. “Projekteissa pitää syntyä tuotokset kustakin projektista KA:n näkökulmasta. Minimitaso voisi olla, että jos jotain muutetaan, niin kirjaus siitä tulisi myös tehtyä KA:n näkökulmasta.” H1 Kun yhteiset toimintamallit ja periaatteet on sovittu, nämä tulee jalkauttaa ICT- projekteihin. Heti projektien suunnittelu- ja käynnistysvaiheessa tulisi huomioida kokonaisarkkitehtuuri ja määritellä taso, mitä projektin aikana kuvataan. Myös projektisuunnitelmassa on tärkeää huomioida kokonaisarkkitehtuuri, sen tavoitteet ja vastuut kyseisen projektin osalta. Keskusteluissa nousi esiin, että projektipäälliköiden työtä voisi helpottaa jonkinlainen pikaopas, jossa listattaisiin keskeiset asiat mitä tulee huomioida kokonaisarkkitehtuurin osalta. ICT-projektien käynnistyttyä koko projektin elinkaaren ajan olisi tärkeää huolehtia säännöllisten arkkitehtuurikatselmointien ja tarkistuspisteiden pitämisestä. Näin saataisiin varmistettua, että projektin käynnistysvaiheessa sovituista kokonaisarkkitehtuuriin liittyvistä tavoitteista pidetään kiinni ja työ etenee suunnitellusti. Arkkitehtuurikatselmoinneissa voidaan näin havaita myös mahdolliset poikkeamat ja tehdä tarvittavia korjausliikkeitä. Keskeisenä kehityskohteena nousi esiin myös kokonaisarkkitehtuurin kuvausten elinkaari. Useampi haastateltavista mainitsi, että ICT-projekteissa syntyneiden kuvausten elinkaaresta ei huolehdita riittävän hyvin projektien päättymisen jälkeen, joka aiheuttaa kuvausten vanhentumisen. ICT-projektien päätösvaiheessa tulisi huolehtia esimerkiksi projektien tuotantoon siirron tarkistuslistan avulla kuvausten elinkaaren jatkuvuudesta. Lisäksi keskeinen huomio oli, että kuvauksiin pitäisi olla helpompi pääsy eri osapuolilla ja kuvauksiin pitää määritellä luku- ja muokkausoikeudet niin, ettei kuvaukset mene rikki. ”Sitten kun se projekti päättyy niin ei meillä ole semmoista toimintatapaa, että tsekattaisiin, mikä se arkkitehtuurikuvausten tilanne olisi.” H1 ”Missä näitä säilytetään, että niihin pääsee käsiksi? Ja sitten että ne olisi semmoisessa muodossa, että niitä pääsee katselemaan, mutta vaan tietyt pääsee päivittämään.” H8 Lisäkysymyksenä haastatteluissa kysyttiin, kenellä tulisi olla vastuu kokonaisarkkitehtuurin toteuttamisesta ICT-projekteissa. Kaikki haastateltavat olivat sitä mieltä, että isossa kuvassa vastuun pitäisi olla ehdottomasti hyvinvointialueella, ei ulkopuolisella toimijalla tai konsultilla. Kun tarkennettiin, kellä henkilöllä tai 73 toiminnolla vastuun pitäisi olla, vastaukset vaihtelivat. Muutama haastateltava sanoi, että vastuun kokonaisarkkitehtuurin toteuttamisesta tulisi olla ICT-projek- tin projektipäälliköllä. Tätä täsmennettiin niin, että välttämättä projektipäällikön ei tulisi yksin toteuttaa kokonaisarkkitehtuuria käytännössä, vaan voisi tehdä tätä yhdessä arkkitehtien kanssa tai vastuuttaa työn parhaiten osaavalle henkilölle. Muutama haastateltava totesi, että vastuun kokonaisarkkitehtuurista pitäisi olla toiminnasta vastaavalla henkilöllä. Yksi haastateltavista oli sitä mieltä, että vastuu tulisi jakaa tietohallinnon, toiminnan ja projektitoimiston välillä. Useampi haastateltavista oli sitä mieltä, että projektien ohjausryhmien agendalla pitäisi jollain tavalla näkyä kokonaisarkkitehtuuri. Tätä perusteltiin sillä, että ohjausryhmän pitäisi valvoa sitä, että projekti on linjassa koko organisaation tavoitteisiin nähden. "Hyvaksin toiminnan pitäisi vastata siitä, kun se on heidän työväline. Jos ei sillä toiminnalla ole sille tarvetta, niin ihan turhaa sitä on kuvata." H9 "Ei voi olla vain tietohallinnon duuni, koska tietohallinto kattaa vain pari alimmaista kerrosta KA:sta." H4 Suurimmassa osassa haastatteluista nousi esiin kokonaisarkkitehtuurin omistajuuden puute. Haastateltavat totesivat, että toiminnassa tulisi paremmin omistaa kokonaisarkkitehtuuri, jotta esimerkiksi tietojärjestelmäkokonaisuuksien hahmottuminen paranisi ja ymmärrys kasvaisi siitä, miten nämä asiat liittyvät toimintaan. Yksi haastateltavista oli sitä mieltä, että tilaajana hyvinvointialueen tulisi ottaa omistajuus paremmin omiin käsiin, jotta tuotokset eivät jäisi esimerkiksi toimittajien haltuun tai muuten unohduksiin. ”Toimintaprosessien organisaatioiden pitäisi olla kiinnostunut ja jopa huolissaan siitä, että mikä sen arkkitehtuurin tilanne on. Miten voidaan kehittää, jos ei tiedetä missä ollaan? Paineen täytyy tulla johtotasolta, muuten arkkitehtuurityö jää tekemättä.” H9 80 kokonaisarkkitehtuurin osalta. Minimitason määrittelyn tukena voisi toimia LEAD-kokonaisarkkitehtuurimenetelmä, jonka keskeisenä ajatuksena on toteuttaa vain tarpeellisia asioita kokonaisarkkitehtuuriin liittyen (Hosiaisluoma ym. 2018, 88). Kokonaisarkkitehtuurin käytäntöjen jalkautumista projekteihin edesauttaisi myös arkkitehtuurikatselmointien kytkeminen osaksi ICT-projekteja. Säännölliset arkkitehtuurikatselmoinnit auttaisivat projekteja huolehtimaan siitä, että kokonaisarkkitehtuurin vaatimustenmukaisuus toteutuu. Sekä Foorthuis ja Brinkkemper (2008, 36) että Andersen ja muut (2015, 4089) ovat todenneet arkkitehtuurikatselmointien edesauttavan sitä, että projektien työskentely ja tuotokset ovat linjassaan koko organisaation kokonaisarkkitehtuurin kanssa. Arkkitehtuurikatselmoinnit tulisi sijoittaa projektin elinkaareen siten, että ennen arkkitehtuuripäätösten viemistä toteutukseen pidetään katselmointipalaveri, jossa arvioidaan päätöksen toteutuskelpoisuutta ja onko toteutus organisaation kokonaisarkkitehtuurilinjausten mukainen (Brinkkemper ym. 2012, 51- 52). Tutkimuksen perusteella ICT-projekteista puuttuu tällä hetkellä myös selkeä käytäntö, jossa huolehditaan kokonaisarkkitehtuurikuvausten tuotantoon siirrosta projektin päättymisen jälkeen. Tässä apuna voisi toimia projektien tuotantoon siirron tarkistuslista, jossa sovittaisiin projekteissa syntyneiden arkkitehtuurituotosten tallennuspaikasta ja ylläpitovastuista. Kokonaisarkkitehtuuriin liittyvän omistajuuden kirkastaminen on tulosten perusteella erittäin tärkeää, jotta kokonaisarkkitehtuurille saadaan selkeästi nimetty vastuutaho. Omistajuuden näkökulmasta tärkeää on, että kokonaisarkkitehtuuria ei vieritetä esimerkiksi pelkästään tietohallinnon vastuulle. Kokonaisarkkitehtuurin sijoittaminen IT-johtajan alaisuuteen voi aiheuttaa sen, että kokonaisarkkitehtuuria ei saada levitettyä muualle organisaatioon (Gong & Janssen 2022, 1413). Kokonaisarkkitehtuurin omistajuus tulee sijoittaa organisaatiossa riittävän korkealle, jotta sen jalkauttaminen onnistuu tehokkaasti kaikkialla organisaatiossa (Banaeianjahromi & Smolander 2019, 895). Tämä on syytä ottaa huomioon myös Keski-Suomen hyvinvointialueen kaltaisessa valtavassa organisaatiossa. 7.2 Tärkeimmät tulokset Tässä kappaleessa vedetään lyhyesti yhteen luvussa esiteltyjä johtopäätöksiä ja tärkeimpiä tuloksia. Lisäksi lopussa esitellään lista konkreettisista toimenpiteistä, joilla kokonaisarkkitehtuurityön tasoa voisi Keski-Suomen hyvinvointialueen organisaatiossa nostaa. Tutkimustulosten perusteella kokonaisarkkitehtuuri mahdollistaa vahvan tuen organisaatiossa tapahtuville muutoksille, sillä kokonaisarkkitehtuurin avulla organisaatiossa toteutettavia muutoksia voidaan lähestyä yhdenmukaisella tavalla (Hoogervorst 2004, 228–229). Kokonaisarkkitehtuurin avulla organisaation muutospaineisiin pystytään reagoimaan nopeammin ja se mahdollistaa ketterät toimenpiteet organisaation strategian mukaisesti (The Open Group 2022). ICT-projektit ovat usein luonteeltaan laajoja, monimutkaisia 81 kokonaisuuksia, jotka aiheuttavat isoja muutosvaikutuksia koko organisaatioon (Kanin & Drews 2022, 77). Kokonaisarkkitehtuurin tehokkaan hyödyntämisen on nähty johtavan parempiin lopputuloksiin projekteissa, sillä kokonaisarkkitehtuurin keinojen kautta projektien kypsyystaso, käytännöt ja viestinnän taso paranee (Atteniko ym. 2022, 19; Lange ym. 2016, 424). ICT-projektit johtavat aina myös toiminnallisiin muutoksiin organisaatiossa, ja kokonaisarkkitehtuurin avulla ICT-projekteissa pystytään kattavasti huomioimaan niin liiketoiminnan, organisaation, tiedon kuin teknologiankin eri näkökulmat (Hoogervorst 2004, 228–229). Näin ollen kokonaisarkkitehtuurin merkitystä ICT-projektien onnistumisen kannalta ei voida väheksyä. Tutkimustulosten perusteella voidaan todeta, että kokonaisarkkitehtuuri ja sen keinot ovat näkyneet Keski-Suomen hyvinvointialueen ICT-muutoshank- keessa ja hyvinvointialueen käynnistymisvaiheessa kokonaisarkkitehtiresurssien, kokonaisarkkitehtuurin hallintamallin, periaatteiden, linjausten ja arkkitehtuurikuvausten kautta. Tulosten perusteella kävi ilmi, että etenkin hyvinvointialueen ICT-muutoshankkeeseen perustettu arkkitehtuuriryhmä loi vahvat edellytykset systemaattisen kokonaisarkkitehtuurin toteuttamiselle, sillä hyvinvointialueen valmistelua varten luotiin mm. kokonaisarkkitehtuurin hallintamalli, periaatetason linjaukset ja mallinnuskäsikirja. Kokonaisarkkitehtuuri on näkynyt myös arkkitehtuurikuvausten kautta, sillä hyvinvointialueen tietojärjestelmäkokonaisuuden tila on kuvattu melko kattavasti. Tutkimustulokset osoittavat, että kokonaisarkkitehtuuria ja sen keinoja voitaisiin hyödyntää Keski-Suomen hyvinvointialueen ICT-projekteissa kokonaisarkkitehtuuriymmärryksen ja -osaamisen kasvattamisen avulla, sisäisen resursoinnin avulla, tavoitteiden, periaatteiden ja toimintatapojen sopimisella, käytäntöjen jalkautuksella projekteihin sekä omistajuuden kirkastamisella. Edellä mainittuihin seikkoihin voisi panostaa organisaatiossa keskittymällä kuviosta 22 löytyviin kehitysehdotuksiin. Kuvio 22 Kokonaisarkkitehtuurin kehitettävät osa-alueet ja toimenpiteet 82 Tämän tutkimuksen tavoitteena oli selvittää, miten kokonaisarkkitehtuuria voitaisiin kehittää Keski-Suomen hyvinvointialueen ICT-projekteissa. Tutkimuksessa haluttiin selvittää, miten kokonaisarkkitehtuuri voi tukea organisaatiomuutosta ja ICT-projektien onnistumista sekä miten kokonaisarkkitehtuuria ja sen keinoja on hyödynnetty Keski-Suomen hyvinvointialueen ICT-muutos- hankkeessa ja hyvinvointialueen käynnistymisvaiheen ICT-projekteissa. Tätä kautta pyrittiin tunnistamaan kehitysideoita, miten kokonaisarkkitehtuuria ja sen keinoja voisi hyödyntää jatkossa paremmin hyvinvointialueen ICT-projek- teissa. Tutkimusongelmaan haettiin vastausta kirjallisuuskatsauksen ja empiirisen tutkimuksen avulla, mikä toteutettiin teemahaastatteluiden ja dokumenttianalyysin kautta. Tulokset analysoitiin ja niistä muodostettiin toistuvia teemoja ja tärkeimpiä havaintoja Löydökset-lukuun. Empiirisen tutkimuksen ja kirjallisuuskatsauksen löydöksiä vedettiin yhteen ja näistä muodostettiin vastaukset tutkimuskysymyksiin Pohdinta-luvussa. Tärkeimpiä tuloksia ja suosituksia jatkoa ajatellen esitellään kuviossa 22. Tässä pro gradu -tutkielman viimeisessä luvussa käsitellään tulosten laajempaa akateemista ja käytännön merkitystä, tutkielman rajoitteita sekä jatkotutkimuksen mahdollisuuksia. 8.1 Akateeminen ja käytännön merkitys Tutkimus pyrkii tarjoamaan akateemista lisäarvoa sote-uudistusta, hyvinvointialueita sekä kokonaisarkkitehtuuria koskevalle tutkimusalueelle. Kokonaisarkkitehtuuria on tutkittu aiemmin jo varsin paljon, myös julkishallinnon kontekstissa. Sote-uudistusta ja hyvinvointialueita koskevia tutkimuksia on kuitenkin olemassa vielä varsin vähän, johtuen hyvinvointialueiden lyhyestä historiasta. Hyvinvointialueet käynnistivät toimintansa vuoden 2023 alussa, mutta hyvinvointialueiden sisäinen prosessien, toimintatapojen ja tietojärjestelmien yhtenäistäminen jatkunee vielä pitkään, sillä hyvinvointialueiden varsinainen valmisteluaika jäi verrattain lyhyeksi ja työnsarkaa riittää monilla alueilla vielä 8 LOPUKSI 83 pitkään. Sote-uudistus ja hyvinvointialueiden perustaminen voidaan nähdä historiallisena, koko Suomea läpileikkaavana organisaatiomuutoksena. Tämän kokoluokan muutoksessa kokonaisarkkitehtuuri ja sen keinot voi tuottaa mittavia hyötyjä, ja tämä tutkimus pyrkiikin tuottamaan tähän tarpeeseen lisäarvoa nimenomaan ICT-projektien näkökulmasta. Vaikka tässä tutkimuksessa keskitytäänkin nimenomaan Keski-Suomen hyvinvointialueen ICT-projekteihin, niin tutkimuksen tuloksia voidaan hyödyntää yhtä lailla myös muilla hyvinvointialueilla. 8.2 Rajoitteet ja luotettavuuden arviointi Tutkimukseen liittyy muutamia rajoitteita, jotka on syytä käydä lyhyesti läpi kokonaiskuvan hahmottamiseksi. Ensimmäisenä rajoitteena on se, että kyseessä on kummankin tutkijan ensimmäinen laajempi tutkimusprojekti, ammattikorkeakoulun opinnäytetöitä lukuun ottamatta. Tähän tunnistettuun haasteeseen haettiin tukea sekä yliopiston tarjoamista tukimateriaaleista että pro gradun ohjaajilta. Toisena rajoitteena mainittakoon se, että kumpikin tutkijoista teki asiantuntijatyötä tutkielman kirjoittamisen ohella. Näin ollen voidaan todeta, että osa ajasta ja energiasta meni myös muuhun työskentelyyn, eikä kaikkea mahdollista resurssia ollut koko aikaa käytettävissä. Tutkimuksen luotettavuutta arvioitaessa on myös hyvä tiedostaa edellä mainitut rajoitteet. Tutkimusaineistoa pyrittiin saamaan niin paljon, kuin käytettävissä olleilla resursseilla oli mahdollista. Tutkimuksen luotettavuutta tukee se havainto, että aineisto alkoi haastatteluiden edetessä saturoimaan, eikä uusia löydöksiä juurikaan tehty. Aiempaan kirjallisuuteen ja teoriaan verrattuna ei löytynyt merkittäviä ristiriitoja, ja voidaan todeta, että tutkimuksen löydökset olivat linjassa kirjallisuuskatsauksesta kerätyn aineiston kanssa. 8.3 Jatkotutkimus Tutkimuksen teon aikana nousi esiin muutamia jatkotutkimusaiheita, joita tulevaisuudessa voitaisiin tutkia. Tässä tutkimuksessa tutkittiin Keski-Suomen hyvinvointialueen kokonaisarkkitehtuurin keinoja ICT-projekteissa, mutta mielenkiintoista olisi myös selvittää, miten kokonaisarkkitehtuuria on hyödynnetty muilla hyvinvointialueilla: mitkä ovat kokonaisarkkitehtuurin parhaat käytännöt hyvinvointialueilla? Jatkotutkimuksen kannalta olisi myös arvokasta selvittää, mitkä kokonaisarkkitehtuurin viitekehykset ja -menetelmät tukisivat parhaiten hyvinvointialueiden toimintaa. Haastatteluiden aikana nousi esiin useaan otteeseen näkökulma, että kokonaisarkkitehtuuria tulisi jalkauttaa laajemmin koko organisaatioon. Tästä aiheesta voisi johtaa esimerkiksi seuraavanlaisen tutkimuskysymyksen: ”miten kokonaisarkkitehtuuria pystytään jalkauttamaan koko organisaatioon?”. Lisäksi 84 haastatteluista kävi ilmi, että toiminta-arkkitehtuuri jää monesti sivurooliin kokonaisarkkitehtuuria toteutettaessa. Tätä aihetta voitaisiin tarkastella seuraavan kysymyksen kautta: ”miten toiminta-arkkitehtuurin roolia voidaan nostaa kokonaisarkkitehtuurityöskentelyssä?”. 85 Ahlemann, F. t., Stettiner, E. t., Messerschmidt, M. t., & Legner, C. t. (2012). Strategic Enterprise Architecture Management: Challenges, Best Practices, and Future Developments. Springer Berlin Heidelberg. https://doi.org/10.1007/978-3-642-24223-6 Al-Haddad, S. & Kotnour, T. (2015). Integrating the organizational change literature: a model for successful change. Journal of Organizational Change Management; Bradford, Vol. 28, Iss. 2. https://www.proquest.com/docview/2154276390?parentSessionId=dz0o BA49Kk7JDQKCVxNbvPt%2FpLtpJFWSpV2LIjlF9Yg%3D&accountid=117 74 Andersen, P., Carugati, A., & Sorensen, M. G. (2015). Exploring Enterprise Architecture Evaluation Practices: The Case of a Large University. https://doi.org/10.1109/HICSS.2015.491 Annila, S. (2020). Uusi laki muuttaa julkisen hallinnon tiedonhallintaa – miten käy arkkitehtuurin? Suomidigi-blogi. Päivitetty 6.2.2020. https://www.suomidigi.fi/sv/node/503 Armour, F., Kaisler, S. & Liu, S. (1999a) A big-picture look at enterprise architectures, IT Professional (1:1), s. 35-42. Armour, F., Kaisler, S. & Liu, S. (1999b). Building an enterprise architecture step by step. IT Professional 1(4), s. 31-39. Atencio, E., Bustos, G., & Mancini, M. (2022). Enterprise Architecture Approach for Project Management and Project-Based Organizations: A Review. Sustainability (Basel, Switzerland), 14(16), 9801. https://doi.org/10.3390/su14169801 Banaeianjahromi, N., & Smolander, K. (2019). Lack of Communication and Collaboration in Enterprise Architecture Development. Information systems frontiers, 21(4), 877-908. https://doi.org/10.1007/s10796-017- 9779-6 9 LÄHTEET 86 Berg, M. v.n. & Steenbergen, M. v. (2006). Building an enterprise architecture practice: tools, tips, best practices, ready-to-use insights. Dordrecht : Springer, [2006]. Bernard, S. & Grasso, J. (2009). A Need for Formalization and Auditing in Enterprise Architecture Approaches and Programs. Journal of Enterprise Architecture, 5 (2), 18-30. Bowen, G. A. (2009). Document Analysis as a Qualitative Research Method. Qualitative research journal, 9(2), 27-40. https://doi.org/10.3316/QRJ0902027 Bouwman, H., van Houtum, H., Janssen, M., & Versteeg, G. (2011). Business Architectures in the Public Sector: Experiences from Practice. Communications of the Association for Information Systems, 29, 23. https://doi.org/10.17705/1CAIS.02923 Brinkkemper, S., Foorthuis, R., Hofman, F., & Bos, R. (2012). Compliance Assessments of Projects Adhering to Enterprise Architecture. Journal of database management, 23(2), 44-71. https://doi.org/10.4018/jdm.2012040103 Dang, D. & Pekkola, S. (2017). Enterprise Architecture and Organizational Reform: A Project Debrief. PACIS 2017 Proceedings, 71. https://core.ac.uk/reader/301372840 Dreyfus, D. (2007). Information System Architecture: Toward a Distributed Cognition Perspective, ICIS 2007 Proceedings, Paper 131. Elo, S., Kajula, O., Tohmola, A., & Kääriäinen, M. (2022). Laadullisen sisällönanalyysin vaiheet ja eteneminen. Hoitotiede, 34(4), 215-225. Elo, S., & Kyngäs, H. (2008). The qualitative content analysis process. Journal of advanced nursing, 62(1), 107-115. https://doi.org/10.1111/j.1365- 2648.2007.04569.x Elo, S., Kääriäinen, M., Kanste, O., Pölkki, T., Utriainen, K., & Kyngäs, H. (2014). Qualitative Content Analysis: A Focus on Trustworthiness. SAGE open, 4(1), 215824401452263. https://doi.org/10.1177/2158244014522633 Eskola, T. (2005). Arkkitehtuuri käsitteenä - Arkkitehtonis-filosofinen tutkimus rakennuksesta modernissa. Teknillinen korkeakoulu, arkkitehtiosasto. Väitöskirja. http://urn.fi/urn:nbn:fi:tkk-005634 Espinosa, J.A. & Boh, W.F. (2009). Coordination and Governance in Geographically Distributed Enterprise Architecting: An Empirical Research Design, 42nd Annual Hawaii International Conference on System Sciences. Foorthuis, R. & Brinkkemper, S. (2008). Best Practices for Business and Systems Analysis in Projects Conforming to Enterprise Architecture. Enterprise Modelling and Information Systems Architectures, 3(1), 36–47. https://doi.org/10.18417/emisa.3.1.4 87 Foorthuis, R., Steenbergen, M., Brinkkemper, S. & Bruls, W. A. G. (2016). A theory building study of enterprise architecture practices and benefits. Information Systems Frontiers, 18(3), 541-564. https://www.researchgate.net/publication/276254837_A_theory_buildin g_study_of_enterprise_architecture_practices_and_benefits Gartner. (2013). IT Glossary: Enterprise Architecture (EA). Gartner. Luettu: 25.10.2023. https://www.gartner.com/en/informationtechnology/glossary/enterprise-architecture-ea Gellweiler, C. (2020). Connecting Enterprise Architecture and Project Portfolio Management: A Review and a Model for IT Project Alignment. International journal of information technology project management, 11(1), 1-16. https://doi.org/10.4018/IJITPM.2020010106 Gillis, A. (2023). Enterprise Architecture Framework. TechTarget. Luettu 26.11.2023. https://www.techtarget.com/searchapparchitecture/definition/enterpris e-architecture-framework Gong, Y., & Janssen, M. (2023). Why Organizations Fail in Implementing Enterprise Architecture Initiatives? Information systems frontiers, 25(4), 1401-1419. https://doi.org/10.1007/s10796-022-10298-x Grönlund, Å. & Horan, T. A. (2005). Introducing e-Gov: History, Definitions, and Issues. Communications of the Association for Information Systems, 15, 39. https://doi.org/10.17705/1CAIS.01539 Hakari, K. 2023. (Lähes) kympin suoritus. Kolumni. Sote-uudistus.fi-sivusto. Päivitetty 9.2.2023. https://soteuudistus.fi/-/1271139/-lahes-kympin- suoritus Hauder, M. & Roth, S. (2013). Organizational factors influencing enterprise architecture management challenges. ECIS 2013 Completed Research. 175. https://www.researchgate.net/publication/258119257_Organizational_fa ctors_influencing_enterprise_architecture_management_challenges Henkel, M., Perjons, E., & Sneiders, E. (2017). Business and IT Architecture for the Public Sector: Problems, IT Systems Alternatives and Selection Guidelines. 157-175. https://doi.org/10.1007/978-3-319-58978-7_7 Hirvonen, A., Pulkkinen, M. & Valtonen, K. (2007). Selection criteria for enterprise architecture methods. Jyväskylän yliopisto. https://www.researchgate.net/publication/289491429_Selection_criteria_ for_enterprise_architecture_methods Holbeche, L. (2018). The agile organization : how to build an engaged, innovative and resilient business. London ; New York, NY : CIPD, Kogan Page, 2018. Honkanen, T. (2020). Kokonaisarkkitehtuurin viitekehysten käyttö ketterien toimintamallien yhteydessä. Jyväskylän yliopisto. Pro gradu -tutkielma. 88 https://jyx.jyu.fi/bitstream/123456789/69989/1/URN%3aNBN%3afi%3a jyu-202006174222.pdf Hoogervorst, J. (2004). Enterprise Architecture: Enabling integration, agility and change. International Journal of Cooperative Information Systems : IJCIS 2004, Vol.13 (3), s. 213-233. https://www-worldscientific- com.ezproxy.jyu.fi/doi/epdf/10.1142/S021884300400095X Hosiaisluoma, E., Penttinen, K., Mustonen, J. & Heikkilä, J. (2018). Lean Enterprise Architecture Method for Value Chain Based Development in Public Sector. https://www.researchgate.net/publication/328560027_Lean_Enterprise_ Architecture_Method_for_Value_Chain_Based_Development_in_Public_S ector Hsieh, H. & Shannon, S. E. (2005). Three Approaches to Qualitative Content Analysis. Qualitative Health Research. Vol. 15(9). 1277-88. https://www.researchgate.net/publication/7561647_Three_Approaches_ to_Qualitative_Content_Analysis Hubbart, J. A. (2023). Organizational Change: Considering Truth and Buy-In. Administrative sciences 2023, Vol. 13 (1), s. 1-8. https://www.mdpi.com/2076-3387/13/1/3 Huovila, M. (2022). SOTE kokonaisarkkitehtuurityö ja hyvinvointialueiden viitearkkitehtuuri. 28.4.2022. https://stm.fi/documents/1271139/119380730/Huovila_SOTE+kokonais arkkitehtuurity%C3%B6+ja+hyvinvointialueiden+viitearkkitehtuuri.pdf/ a8ae20f0-543a-5b1e-35b6- 9efbfe70e977/Huovila_SOTE+kokonaisarkkitehtuurity%C3%B6+ja+hyvin vointialueiden+viitearkkitehtuuri.pdf?t=1651646478150 Hyvinvointialueiden perustaminen. (ei pvm.) Sote-uudistus.fi-sivusto. Luettu 2.11.2023. https://soteuudistus.fi/hyvinvointialueiden-perustaminen Hyvinvointialueiden viitearkkitehtuuri. (2022). Viitearkkitehtuurin kuvaus, versio 1.1. Päivitetty 24.9.2022. https://yhteistyotilat.fi/wiki08/display/THLSKAU/Sote+KA+kansalline n+kokonaisarkkitehtuuri?preview=/57733325/152094994/Hyvinvointialu eiden%20viitearkkitehtuuri%20V1.1.pdf Janssen, M. & Hjort-Madsen, K. (2007). Analyzing Enterprise Architecture in National Governments: The Cases of Denmark and the Netherlands. 40th Annual Hawaii International Conference on System Sciences (HICCS '07). Janssen, M., & Klievink, B. (2012). Can enterprise architectures reduce failure in development projects? Transforming government, 6(1), 27-40. https://doi.org/10.1108/17506161211214804 Julkisen hallinnon tietohallinnon neuvottelukunta [JUHTA]. (2017). JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen. Versio 2.0. Julkisen 89 hallinnon tietohallinnon neuvottelukunta JUHTA. Päivitetty 28.9.2020. https://www.suomidigi.fi/ohjeet-ja-tuki/jhs-suositukset/jhs-179- kokonaisarkkitehtuurin-suunnittelu-ja-kehittaminen Kaisler, S., Armour, F. & Valivullah, M. (2005). Enterprise Architecting: Critical Problems, 38th Annual Hawaii International Conference on System Sciences. Kanin, O., & Drews, P. (2022). Enterprise Architecture Management Support for Digital Transformation Projects in Very Large Enterprises: A Case Study at a European Mobility Provider. https://doi.org/10.1007/978-3-031-17604- 3_5 Keski-Suomen hyvinvointialue. (2021). HyvaKS DigiKS ICT- muutossuunnitelma, Keski-Suomen hyvinvointialue. Päivitetty 22.10.2021. https://www.hyvaks.fi/sites/default/files/2021- 10/HyvaKS_DigiKS%20-%20ICT-muutos_hankesuunnitelma.pdf Keski-Suomen hyvinvointialue. (2022a). Kuntien ICT-palveluiden siirtymää hyvinvointialueelle aloitetaan Jyväskylässä ja Äänekoskella. Hyvaks.fisivusto. Päivitetty 14.4.2022. https://www.hyvaks.fi/uutiset/kuntien-ict- palveluiden-siirtymaa-hyvinvointialueelle-aloitetaan-jyvaskylassa-ja Keski-Suomen hyvinvointialue [Hyvaks]. (2023). Organisaatio. Keski-Suomen hyvinvointialue Hyvaksin verkkosivut. Päivitetty 9.6.2023. https://www.hyvaks.fi/hyvinvointialue/organisaatio Laki julkisen hallinnon tiedonhallinnasta 906/2019. https://www.finlex.fi/fi/laki/ajantasa/2019/20190906 Laki julkisen hallinnon tietohallinnon ohjauksesta 634/2011. https://www.finlex.fi/fi/laki/alkup/2011/20110634 Lange, M., Mendling, J., & Recker, J. (2016). An empirical analysis of the factors and measures of Enterprise Architecture Management success. European journal of information systems, 25(5), 411-431. https://doi.org/10.1057/ejis.2014.39 Langermeier, M., & Bauer, B. (2018). A Model-Based Method for the Evaluation of Project Proposal Compliance within EA Planning. https://doi.org/10.1109/EDOCW.2018.00024 Liimatainen, K., Heikkilä, J., & Seppänen, V. (2008). A framework for evaluating compliance of public service development programs with government enterprise architecture. In Proceedings of the 2nd European Conference on Information Management and Evaluation (s. 269-276). Lucke, C., Krell, S. & Lechner, U. (2010). Critical Issues in Enterprise Architecting – A Literature Review. In Proceedings of the 16th Americas Conference on Information Systems (AMCIS), Paper 305. Lumor, T., Hirvonen, A., Pulkkinen, M., tiedekunta, I., Yliopistopalvelut, Technology, F. o. I., & Services, U. (2021). The Role of Enterprise