Turun yliopiston laatujärjestelmän mukaisesti tämän julkaisun alkuperäisyys on tarkastettu Turnitin OriginalityCheck -järjestelmällä. Digikehittäminen ja mikropalvelut Turun kaupungilla TURUN YLIOPISTO Tulevaisuuden teknologioiden laitos Pro gradu -tutkielma Kesäkuu 2018 Tuomas Piippo Ohjaajat: Sami Hyrynsalmi Sampsa Rauti TURUN YLIOPISTO Tulevaisuuden teknologioiden laitos TUOMAS PIIPPO: Digikehittäminen ja mikropalvelut Turun kaupungilla Pro gradu -tutkielma, 109 sivua, 4 liitesivua Tietojenkäsittelytiede Kesäkuu 2018 Vakiintuneiden organisaatioiden IT-toimintoihin kohdistuu kahdenlaisia keskenään ristiriitaisia vaatimuksia. IT-toiminnoilta vaaditaan toisaalta ketteryyttä ja kokeellisuutta, kun organisaatiot pyrkivät sekä hyödyntämään uusien teknologioiden tuottamia mahdollisuuksia että vastaamaan perinteisiä liiketoimintamalleja haastavien toimijoiden kilpailuun. Toisaalta ne joutuvat ylläpitämään ja kehittämään hallitusti, ennakoitavasti ja kustannustehokkaasti organisaation nykyistä toimintaa tukevia IT- järjestelmiä. Tässä pro gradu -tutkielmassa tarkastellaan bimodaalisen, eli samanaikaisesti kahdella tavalla toimivan IT-toiminnon tarkoituksenmukaisuutta ja mahdollista toteutustapaa Turun kaupungilla. Tutkimuksen tarkoituksena on syventää ymmärrystä siitä, miten kokeellinen ja ketterä digitaalinen informaatioteknologia sekä vakauteen ja toimintavarmuuteen pyrkivä perinteinen IT muodostavat organisaation toimintaa ja tavoitteita tukevan yhtenäisen kokonaisuuden. Tutkimus toteutetaan tapaustutkimuksena, joka hyödyntää sekä julkista aineistoa että etnografista aineistonkeruuta. Tuloksena kuvataan Turun kaupungille toimintamalli kahden rinnakkaisen IT-toiminnon toimintatavan käyttöönottamiseksi, tunnistetaan mallin vaikutukset organisaation järjestelmäarkkitehtuuriin sekä tarkastellaan mikropalveluja toteutustapana digitaalisen IT:n järjestelmäkehitykselle. Asiasanat: bimodaalinen IT, mikropalveluarkkitehtuuri, kokonaisarkkitehtuuri, ohjelmistoarkkitehtuuri, Turun kaupunki UNIVERSITY OF TURKU Department of Future Technologies TUOMAS PIIPPO: Digital development and microservices at the City of Turku Master’s Thesis, 109 pages, 4 pages of appendices Computer Science June 2018 The IT functions of established organisations constantly face two kinds of conflicting requirements. On one hand, the IT functions need to be agile and experimental, to support the organisations in their efforts to leverage the potential of new technologies as well as to respond to new kinds of competition that challenges existing business models. On the other hand, they need to maintain and develop the organisations’ existing IT systems in a coordinated, foreseeable and cost-efficient manner. This master’s thesis examines the appropriateness and feasibility of a bimodal IT function – i.e. an IT function operating concurrently in two separate modes – at the City of Turku. The aim of the study is to deepen the understanding on how experimental and agile digital IT, and stabile and reliable traditional IT can form a coherent IT function that supports the organization’s targets and operations. The study is conducted as a case study that utilizes both public sources as well as ethnographic material collection. As the result, the study produced a bimodal operating model for the City of Turku, identified its effects on the organization’s information systems architecture and examined microservice architecture as an approach for digital IT development. Keywords: bimodal IT, microservice architecture, enterprise architecture, software architecture, City of Turku SISÄLLYS 1 Johdanto ................................................................................................................ 1 2 Digitaalinen ja perinteinen IT ................................................................................ 7 2.1 Tarve kahdelle rinnakkaiselle toimintatavalle .................................................. 7 2.2 Bimodaalinen IT ............................................................................................. 9 2.3 Liiketoiminnan ja informaatioteknologian yhteensovittaminen...................... 13 2.4 Liiketoiminta ja bimodaalinen IT-toiminto .................................................... 21 2.4.1 Bimodaalisuuteen siirtyminen ................................................................ 21 2.4.2 Bimodaalisen IT-toiminnon ja liiketoiminnan yhdenmukaisuus ............. 22 2.4.3 Bimodaalisuuden järjestämistavat .......................................................... 24 2.4.4 Bimodaalisuuden elinkaari ..................................................................... 27 2.5 Yhteenveto luvusta ....................................................................................... 28 3 Kokonais- ja ohjelmistoarkkitehtuurit .................................................................. 30 3.1 Arkkitehtuuri yleisesti ................................................................................... 30 3.2 Kokonaisarkkitehtuuri................................................................................... 31 3.2.1 Kokonaisarkkitehtuurin hyödyt .............................................................. 32 3.2.2 Kokonaisarkkitehtuurin viitekehykset .................................................... 34 3.2.3 Kokonaisarkkitehtuurin näkökulmat ...................................................... 41 3.3 Ohjelmistoarkkitehtuuri ................................................................................ 44 3.4 Yhteenveto luvusta ....................................................................................... 47 4 Mikropalveluarkkitehtuuri ................................................................................... 48 4.1 Mikropalveluarkkitehtuuri osana arkkitehtuurityylien jatkumoa .................... 48 4.2 Monoliittiset sovellukset mikropalvelujen vastakohtana ................................ 49 4.3 Palvelukeskeinen arkkitehtuuri mikropalvelujen edeltäjänä ........................... 54 4.3.1 Palvelukeskeisen arkkitehtuurin käsitteitä .............................................. 55 4.3.2 Palvelukeskeisen arkkitehtuurin suunnitteluperiaatteita .......................... 56 4.3.3 Palvelukeskeisen arkkitehtuurin toteutustapoja ...................................... 58 4.3.4 Palvelukeskeisen arkkitehtuurin haasteita .............................................. 59 4.4 Mikropalveluarkkitehtuuri ............................................................................ 60 4.4.1 Mikropalveluarkkitehtuurin suunnitteluperiaatteita ................................ 60 4.4.2 Mikropalveluarkkitehtuurin toteutustapoja ............................................. 63 4.4.3 Mikropalvelujen kehittäminen ............................................................... 65 4.4.4 Mikropalveluarkkitehtuurin haasteita ..................................................... 66 4.5 Monoliittisen, palvelukeskeisen ja mikropalveluarkkitehtuurin vertailu......... 69 4.6 Yhteenveto luvusta ....................................................................................... 71 5 Bimodaalinen IT ja mikropalveluarkkitehtuuri Turun kaupungilla ....................... 74 5.1 Taustaa ......................................................................................................... 74 5.2 Nykytila ........................................................................................................ 76 5.2.1 Strateginen yhdenmukaisuus .................................................................. 76 5.2.2 Bimodaalinen toimintatapa .................................................................... 79 5.3 Tavoitetila .................................................................................................... 86 5.3.1 Bimodaalinen toimintatapa toiminnan eri osa-alueilla ............................ 86 5.3.2 Tavoitetila strategisen yhdenmukaisuuden näkökulmasta ....................... 91 5.3.3 Tavoitetila tietohallintostrategian näkökulmasta ..................................... 92 5.3.4 Eri arkkitehtuurityylit tavoitetilassa ....................................................... 94 5.4 Yhteenveto luvusta ....................................................................................... 99 6 Yhteenveto ........................................................................................................ 100 6.1 Aineistot ..................................................................................................... 100 6.2 Johtopäätökset ............................................................................................ 101 6.3 Rajoitteet ja jatkotutkimuskohteet ............................................................... 102 LÄHTEET ................................................................................................................ 105 LIITE A .................................................................................................................... 110 KUVIOT Kuva 1. Strategisen yhdenmukaisuuden malli (mukaillen Hendersson ja Venkatraman 1993, s. 476) ............................................................................................................... 15 Kuva 2. Strategisen yhdenmukaistamisen ensimmäinen näkökulma: Strategian toteuttaminen .............................................................................................................. 17 Kuva 3. Strategisen yhdenmukaistamisen toinen näkökulma: Teknologiatransformaatio ................................................................................................................................... 18 Kuva 4. Strategisen yhdenmukaistamisen kolmas näkökulma: Kilpailullinen potentiaali. ................................................................................................................................... 19 Kuva 5. Strategisen yhdenmukaistamisen neljäs näkökulma: Palvelutaso. ................... 20 Kuva 6. Liiketoiminnan ja bimodaalisen IT-toiminnon yhteensovittaminen. ............... 23 Kuva 7. Digitaalisen IT-toiminnon ja sitä vastavan liiketoiminnan yhteensovittaminen. ................................................................................................................................... 23 Kuva 8. Projektikohtainen toimintatavan valinta ......................................................... 24 Kuva 9. IT-toiminto jakautuneena kahteen toimintatapaan .......................................... 25 Kuva 10. IT kahtena erillisenä toimintona. .................................................................. 26 Kuva 11. Bimodaalisen IT-toiminnon vaiheet (Haffke ym., 2017a, muokattu)............. 27 Kuva 12. JHS 179:n suunnittelurakenteiden kokonaisuudet (JUHTA 2017b, s. 27, muokattu). .................................................................................................................. 37 Kuva 13. Kokonaisarkkitehtuurin sisältöviitekehys (JUHTA 2017b, muokattu). ......... 39 Kuva 14. Kokonaisarkkitehtuurin arkkitehtuurikuvausten viitekehys (JUHTA 2017b) 40 Kuva 15. Monoliittinen sovellus, palvelukeskeinen arkkitehtuuri ja mikropalveluarkkitehtuuri jatkumona.. ........................................................................ 48 Kuva 16. Monoliittinen ja mikropalveluihin perustuva verkkosovellus. ....................... 50 Kuva 17. Moduulien välinen vuorovaikutus monoliittisessa ja mikropalveluista koostuvassa sovelluksessa. .......................................................................................... 52 Kuva 18. Esimerkki mikropalvelun rakenteesta ........................................................... 61 Kuva 19. Järjestelmän monimutkaisuuden vaikutus sen toteutustyön tuottavuuteen (Fowler 2015a). .......................................................................................................... 67 Kuva 20. Palvelujen hienojakoisuuden vaikutus järjestelmän ominaisuuksiin (Zahed ym. 2013). .................................................................................................................. 68 Kuva 21. Turun kaupungin organisaatiorakenne (lähde: https://www.turku.fi/organisaatio) ............................................................................... 74 Kuva 22. Turun kaupungin kehittämismalli (Turun kaupunki 2014) ............................ 75 Kuva 23. Lähestymistavat strategisen yhteensopivuuden ja toiminnallisen integraation saavuttamiseksi. (Hendersson ja Venkatraman, 1993) ................................................. 77 Kuva 24. Turun kaupunki- ja tietohallintostrategia strategisen yhdenmukaisuuden mallin kautta tarkasteltuina. ........................................................................................ 78 Kuva 25. Sekä toimintaa että informaatioteknologiaa koskevan standardisoinnin vaikutuksia.................................................................................................................. 82 Kuva 26. Keskitetyn standardoinnin ja hajautetun yksilöllisen IT:n painotukset toiminnan eri osa-alueilla (mukailtu, Silvius 2007) ..................................................... 83 Kuva 27. Hahmotelma Silviuksen esittämästä mallista kunnan toimintaympäristössä .. 85 Kuva 28. Esimerkki service blueprint -tyyppisestä prosessikaaviosta .......................... 87 Kuva 29. Kaupungin toiminnan ja IT:n yhteensovittaminen ja eri osa-alueiden toteutustapoja. (Horlachin ym. esittämää mallia mukaillen)......................................... 89 Kuva 30. Digitaalisuuden, yhteisten palvelujen ja standardoinnin vaikutusten hahmottelua ................................................................................................................ 90 Kuva 31. Näkemys eri osa-alueiden tarkoituksenmukaisimmista toteutustavoista. ....... 98 TAULUKOT Taulukko 1. Perinteisen ja digitaalisen IT:n piirteitä (mukaillen Horlach ym, 2016) .... 10 Taulukko 2. Taltiointijärjestelmien ja osallistavien järjestelmien ominaisuuksia (mukaillen Moore 2011) ............................................................................................. 12 Taulukko 3. Osa-alueilla tehtävät valinnat ................................................................... 16 Taulukko 4. Monoliittisen, palvelukeskeisen ja mikropalveluihin perustuvan arkkitehtuurin piirteitä Strîmbei ym. (2015). ............................................................... 70 Taulukko 5. Tavoitetilan ja tietohallintostrategian riskien ja haasteiden vastaavuus ..... 94 Taulukko 6. Eri osa-alueiden toteutustapojen arviontia. ............................................... 96 11 Johdanto Tässä pro gradu -tutkielmassa tarkastellaan ketteryyteen ja nopeuteen pyrkivän digitaa- lisen IT:n tarkoituksenmukaisuutta ja mahdollista mikropalveluihin perustuvaa toteutus- tapaa Turun kaupungin digitaalisten palvelujen kehittämisessä.1 Useat yksityiset ja julkiset organisaatiot ovat viime vuosina käynnistäneet erilaisia digi- talisaatiohankkeita, joissa toteutetaan tyypillisesti organisaation asiakkaille näkyviä pal- veluja uutta teknologiaa ja ketteriä toimintatapoja hyödyntäen. Tällaiset hankkeet voivat koskea kokonaan uusien digitaalisuuden mahdollistamien palvelujen kehittämistä tai esimerkiksi yhtenäisemmän asiakaskokemuksen tarjoamista käytetystä asiointikana- vasta riippumatta. Digitaalisuuden tuottamien mahdollisuuksien hyödyntäminen ja sen haasteisiin vastaa- minen aiheuttaa uudenlaisia vaatimuksia vakiintuneiden organisaatioiden IT-toimin- nolle. Organisaatiot pyrkivät sekä hyödyntämään uusien digitaalisten teknologioiden tuottamia mahdollisuuksia että vastaamaan uusien, usein jo lähtökohtaisesti digitaali- suuteen perustuvien ja perinteisiä liiketoimintamalleja haastavien toimijoiden kilpai- luun. Vakiintuneet organisaatiot joutuvat toimimaan tässä nopeasti muuttuvassa ympä- ristössä huomioiden samalla nykyistä toimintaansa tukevat perinteiset IT-järjestel- mänsä. (Haffke, Kalgovas & Benlian, 2017a.) Ristiriita ketteryyden ja nopeuden sekä toisaalta vakauden ja turvallisuuden vaatimuk- sille on useissa organisaatioissa ratkaistu bimodaalisella, eli kahta eri toimintatapaa noudattavalla IT:llä. Tällöin organisaatiot kehittävät kahta rinnakkaista IT-kokonai- suutta: perinteistä, tyypillisesti erityisesti organisaation sisäisiä toimintoja tukevaa IT:tä sekä uutta digitaalista, usein asiakkaille näkyviä palveluja toteuttavaa IT:tä. (Haffke ym, 2017a; Horlach ym, 2016.) Taustana mikropalveluihin perustuvan toteutustavan selvittämiselle ovat olleet muun muassa haasteet sähköistä asiointia ja yleisemmin digitaalisten palvelujen toteuttamista 1 Digitaalisuudella ei tässä yhteydessä viitata epäjatkuvaan ja diskreetteihin arvoihin perustuvaan esitysta- paan, vaan tietynlaiseen organisaation IT-toiminnon toimintatapaan. Kahdella rinnakkaisella tavalla toi- mivan IT-toiminnon mallia kuvannut tutkimusyhtiö Gartner kutsuu toisaalta ennakoitavuutta ja toisaalta kokeellisuutta tavoittelevia toimintatapoja yksinkertaisesti ”tilassa 1” ja ”tilassa 2” toimimiseksi (Gartner, 2017). Tässä työssä käytetään näistä toimintatavoista Horlachin, Drewsin ja Schirmerin (2016) käyttämiä käsitteitä perinteinen IT ja digitaalinen IT. Samoin tutkielmassa käytetty digikehittämisen käsite viittaa tämän kokeellisuutta, ketteryyttä ja nopeutta tavoittelevan toimintatavan hyödyntämiseen. 2ja prosessien digitalisointia tukevan alustaratkaisun löytämisessä. Toimin tätä kirjoitta- essani kehittämispäällikkönä Turun kaupungin konsernihallintoon kuuluvalla Strategia ja kehittäminen -vastuualueella. Vastuualue on selvittänyt aiemmin mikropalvelujen käyttömahdollisuuksia sähköisen asioinnin toteuttamiseen sekä yhteistyössä Espoon kaupungin kanssa että puitesopimustoimittaja Integration House Oy:n kanssa toteutet- tuna toimeksiantona. Sekä tämä esiselvitys- ja suunnittelutyö että aiempi osallistumiseni julkishallinnon asiointiportaalin toteutustyöhön ovat vahvistaneet näkemystä siitä, että yhdestä laajasta ohjelmistosta koostuvien, useita eri palveluja sisältävien asiointialusto- jen toteutus on varsin haasteellista. Mikropalveluja voidaan pitää vastakohtana tälle niin kutsutulle monoliittiselle toteutustavalle. Aihetta tarkastellaan arvioimalla digitaalisuuden ja perinteisen IT:n ristiriitaisia vaati- muksia ja niihin vastaamista Turun kaupungin toimintaympäristössä. Oletuksena on, että uusien teknologioiden hyödyntämisen, ketteryyden ja nopeuden vaatimukset myös Turun kaupungille ja sen IT-toiminnoille ovat lisääntyneet, mutta tarve perinteiselle en- nakoitavalle ja kustannustehokkaalle IT-toiminnolle ei ole poistunut. IT-toimintoon kohdistuu siis usein keskenään ristiriitaisia ja päinvastaisia vaatimuksia. Kaupunki yllä- pitää useita toiminnalleen ja esimerkiksi potilasturvallisuudelle keskeisiä järjestelmiä, joiden sisältämien tietojen tulee ehdottomasti olla oikeellisia ja käytettävissä. Toisaalta sähköistä asiointia ja digitaalisia palveluja kehitettäessä kaupungin palvelujen asiointi- kokemus vertautuu helposti Netflixin ja Amazonin kaltaisiin kuluttajille suunnattuihin palveluihin. Tämä tekee kaupungista kiinnostavan tapaustutkimuksen kohteen digitaali- sen ja perinteisen IT-toiminnon yhdistämistä koskevaan työhön. Asiakkaille näkyvät digitaaliset palvelut liittyvät miltei aina kaupungin sisäisiin, perin- teisen IT:n piiriin kuuluviin järjestelmiin. Vaikka asiakkaan käyttämiä palveluja kehitet- täisiin ketterästi, asiakaslähtöisesti ja uusimpia teknologian mahdollisuuksia hyödyn- täen, asettavat vakauden ja virheettömyyden tyyppisiä vaatimuksia painottavat perinne- järjestelmät ja toimintatavat yhtenäisen järjestelmäkokonaisuuden muodostamiselle haasteita. Tästä johtuen arvioitaessa mikropalveluja digitaalisen IT-toiminnon järjestel- mien toteutustapana tarkastellaan myös niiden liittämistä muihin perinteisen IT-toimin- non järjestelmiin. Työn tavoitteena on siis syventää ymmärrystä siitä, miten kokeellinen ja ketterä digitaa- linen informaatioteknologia sekä vakauteen ja toimintavarmuuteen pyrkivä perinteinen IT muodostavat organisaation toimintaa tukevan tarkoituksenmukaisen ja yhtenäisen 3kokonaisuuden. Työ jatkaa samalla myös Turun kaupungin esiselvitystyötä mikropalve- lujen hyödyntämisestä kaupungin digitaalisten palvelujen toteutustapana. Työssä tarkasteltava tutkimusongelma on, - miten mikropalveluarkkitehtuurilla toteutettu digitaalinen informaatioteknologia toteutetaan perinteisen IT:n tukeman toiminnan rinnalle? Tutkimusongelma voidaan jakaa seuraaviin kysymyksiin: - Onko bimodaalinen IT-toiminto tarkoituksenmukainen toimintatapa Turun kau- pungille? - Miten bimodaalinen toimintatapa tulisi Turun kaupungin toimintaympäristössä toteuttaa? - Miten mikropalveluarkkitehtuuri soveltuu digitaalisen informaatioteknologian toteutustavaksi? Tutkimus tehdään tapaustutkimuksena, joka hyödyntää sekä julkista aineistoa että etno- grafista aineistonkeruuta. Eriksson ja Koistinen (2014, s. 4) määrittelevät tapaustutki- muksen tarkastelevan ”yhtä tai useampaa tapausta, joiden määrittely, analysointi ja rat- kaisu on tapaustutkimuksen keskeisin tavoite”. He jakavat tapaustutkimukset luonteel- taan intensiivisiin ja ekstensiivisiin tapaustutkimuksiin. Näistä intensiivinen tapaustutki- mus pyrkii tutkimuksen kohteen tiheään kuvaamiseen, tulkintaan ja ymmärtämiseen, tehden tapauksesta siten teoreettisesti mielenkiintoisen. Ekstensiivinen tapaustutkimus taas vertailee useita tapauksia ja pyrkii siten selittämään ilmiöitä tai kehittämään uutta teoriaa. Tämä tutkimus voidaan Erikssonin ja Koistisen esittämää jakoa käyttäen luoki- tella intensiiviseksi tapaustutkimukseksi, joka pyrkii osallistuvan havainnoinnin kautta soveltamaan edellä kuvattuja bimodaalisen IT-toiminnon ja mikropalveluarkkitehtuurin malleja Turun kaupungin toimintaan. Näiden mallien kuvaukset perustuvat julkisiin ai- neistoihin. Turun kaupungin toimintaympäristön kuvaus perustuu puolestaan etnografi- seen aineistonkeruuseen, jonka voidaan katsoa tuottavan kaupunkiorganisaation muo- dostamasta monimutkaisesta teknisestä ja sosiaalisesta ympäristöstä intensiivisen ta- paustutkimuksen vaatiman tiheän kuvauksen. Etnografisessa aineistonkeruussa tutkija kerää kohteestaan laajasti tietoa esimerkiksi tut- kimuksen kohteena olevien ihmisten päivittäiseen elämään osallistumalla. Tutkimuk- sessa käytettävää tietoa ei siis kerätä etukäteen suunnitellun rakenteen, kuten kyselyn, 4ohjaamana, vaan vuorovaikutteisesti havainnoimalla ja tulkitsemalla tutkimuskohdetta osana kohteensa sosiaalista maailmaa. (Hammersley & Atkinson 1983.) Tämä pro gradu -työ koostuu kahdesta osasta. Luvut 2–4 muodostavat työn teoreettisen osan, jossa käsitellään aiemman tutkimuksen ja kirjallisuuden perusteella tutkimuskysy- myksille keskeisiä aihepiirejä. Teorialukujen aihepiirit käsittelevät sekä työn aiheena olevia bimodaalisen informaatioteknologian mallia ja mikropalveluarkkitehtuuria että nämä kaksi aihepiiriä yhdistäviä kokonais- ja ohjelmistoarkkitehtuuria. Luvuissa 5–6 tarkastellaan tutkimuskysymyksiä tapaustutkimuksen kohteeksi valitun Turun kaupun- gin toimintaympäristössä ja esitetään niiden tarkastelussa tehtyjä huomioita. Työ alkaa johdantoluvulla, jonka jälkeisessä toisessa luvussa aloitetaan työn teoreettisen viitekehyksen tarkastelu. Luvussa esitetään yleisesti vakiintuneiden organisaatioiden haasteita digitaalisuuden hyödyntämisessä ja esimerkiksi siitä aiheutuvaan uudenlaiseen kilpailuun vastaamisessa. Tarkastelua syvennetään tutkimalla organisaation toiminnan ja sitä tukevan informaatioteknologian yhteensopivuutta kuvaavaa Henderssonin ja Venkatramanin (1993) strategisen yhdenmukaisuuden mallia. Malli esittää, millaisista osa-alueista organisaation toiminnan ja IT-toiminnon voidaan katsoa koostuvan ja miten varmistetaan, että ne muodostavat yhdessä tarkoituksenmukaisen kokonaisuuden. Digi- taalisuuden ja perinteisten toimintatapojen välisen ristiriidan sekä organisaation toimin- nan ja sitä tukevan informaatioteknologian välisen suhteen tarkastelun jälkeen esitetään työn keskeisenä aiheena oleva bimodaalisen IT-toiminnon malli. Mallin tarkoituksena on vastata organisaatioon sen toimintaympäristöstä kohdistuviin kahdenlaisiin vaati- muksiin kahdella eri toimintatavalla ja eri tapoihin jakautuneella IT-toiminnolla. Bimo- daalisen IT:n mallia tarkastellaan erityisesti Horlachin ym. (2016) ja Haffken ym. (2017a) esityksiin pohjautuen. Luvun tavoitteena on siis luoda käsitys digitaalisuuden tuomista haasteista vakiintuneelle organisaatiolle, sekä siitä, millä tavalla bimodaalinen IT pyrkii niihin vastaamaan. Kolmas luku tarkastelee kokonaisarkkitehtuuria. Kokonaisarkkitehtuuri yhdistää organi- saation tavoitteet ja strategian sen liiketoimintaprosesseihin ja edelleen toimintaproses- seja tukeviin tietojärjestelmiin ja niiden tekniseen toteutukseen. Kokonaisarkkitehtuuri toimii siten yhdistävänä viitekehyksenä tarkasteltaessa sekä organisaation strategisen ta- son valintoihin sisältyvää bimodaalista toimintatapaa että toisaalta mikropalveluarkki- tehtuuria tietojärjestelmien teknisenä toteutustapana. Kokonaisarkkitehtuuria tarkastel- laan erityisesti valtion- ja kunnallishallinnolle suunnatun JHS 179 -viitekehyksen 5(JUHTA, 2017b) kautta. Koska tarkoituksena on esimerkiksi viitekehyksen arvioinnin sijasta kuvata viitekehyksen avulla yhteys organisaation toiminnan ja tietojärjestelmien välillä, on pääasiallisena lähteenä käytetty tieteellisten artikkelien sijasta viitekehyksen dokumentaatiota. Luvun lopussa tarkastellaan ohjelmistojen sisäistä toteutustapaa ku- vaavaa ohjelmistoarkkitehtuuria. Ohjelmistoarkkitehtuuriin liittyvien käsitteiden ja nä- kökulmien tarkastelu auttaa hahmottamaan arkkitehtuurin suunnitteluun liittyviä valin- toja ja reunaehtoja, ja pohjustaa siten kolmen eri ohjelmistoarkkitehtuurityylin tarkaste- lemista seuraavassa luvussa. Neljäs luku tarkastelee työn keskeisenä aiheena olevaa mikropalveluarkkitehtuuria, mutta päätyy siihen kahta muuta arkkitehtuurityyliä tarkastelemalla. Mikropalveluarkki- tehtuurin voidaan katsoa kehittyneen palvelukeskeisestä arkkitehtuurista, joka taas vas- taa niin kutsutussa monoliittisessa arkkitehtuurissa tunnistettuihin haasteisiin. Yhdestä laajasta ohjelmistosta koostuva monoliittinen arkkitehtuuri määritellään yleensä lähinnä useista pienistä ja itsenäisistä ohjelmiston osista koostuvien arkkitehtuurien vastakoh- tana, ja sitä ei siten välttämättä voida pitää omana arkkitehtuurityylinään. Myös tässä tarkastelussa monoliittinen arkkitehtuuri esitetään mikropalveluarkkitehtuurin ominai- suuksien kautta – haasteina, joihin mikropalveluihin perustuva arkkitehtuurityyli vastaa. Palvelukeskeinen ja mikropalveluarkkitehtuurityyli esitetään sen sijaan selkeämmin omina arkkitehtuurityyleinään, joita kuvaavat niiden suunnitteluperiaatteet sekä niiden toteutuksessa tyypillisesti käytetyt menetelmät. Kaikki arkkitehtuurityylit on kuvattu tarkkuustasolla, joka mahdollistaa niiden hyödynnettävyyden arvioinnin tapaustutki- muksen kohteena olevan Turun kaupungin toiminnan eri osa-alueilla. Eri arkkitehtuuri- tyylejä esitetään paitsi tieteellisten artikkelien sisältöihin viitaten, myös perustuen Lewi- sin ja Fowlerin (2014) esittämiin ohjelmistoprojekteista syntyneisiin käytännön koke- muksiin. Viidennessä luvussa siirrytään tarkastelemaan tutkimuskysymyksiä Turun kaupungin toimintaympäristössä. Luvun aluksi kuvataan Turun kaupungin toiminnan nykytilaa strategisen yhdenmukaisuuden ja bimodaalisen IT:n mallien kautta. Tässä yhteydessä vastataan työn ensimmäiseen tutkimuskysymykseen tarkastelemalla, kohdistuuko kau- pungin toimintaan ja siten sen IT-toimintoon kahdenlaisia vaatimuksia, joihin voisi olla tarkoituksenmukaista vastata IT-toiminnon bimodaalisella toteutustavalla. Nykytilan 6kuvauksesta siirrytään tarkastelemaan, miltä bimodaalisen toimintatavan käytön tavoite- tila voisi Turun kaupungilla näyttää ja miten sitä tuettaisiin mikropalveluarkkitehtuuriin perustuvalla informaatioteknologialla. Tutkielman viimeisessä luvussa tarkastellaan yhteenvetona tutkimuksen toteutustapaa ja johtopäätöksiä. Luvussa arvioidaan edellä kuvattujen tulosten perusteella, miten tutki- mus kasvattaa ymmärrystä digitaalisen ja perinteisen IT:n tarkoituksenmukaisista toteu- tustavoista ja mikropalveluarkkitehtuurin soveltuvuudesta digitaalisen informaatiotek- nologian yhteydessä käytettäväksi. Lisäksi esitetään tutkimuksessa käytettyihin aineis- toihin ja menetelmiin liittyviä huomioita ja niistä aiheutuneita rajoitteita. Luvun lopuksi esitetään mahdollisia tutkimuksen aihepiiriin liittyviä jatkotutkimusaiheita. Liitteessä A esitetään Turun kaupungin toiminnan kehittämisen näkökulmasta laadittu lyhyt yhteenveto tutkimuksen tuloksista. 72 Digitaalinen ja perinteinen IT Tässä luvussa tarkastellaan samanaikaisesti digitaalisella ja perinteisellä tavalla toimi- van bimodaalisen IT-toiminnon tarvetta, piirteitä ja toteutustapoja. Luvun aluksi tarkas- tellaan yleisellä tasolla tarvetta kahdelle rinnakkaiselle toimintatavalle organisaatiossa niin IT-toiminnon järjestämisessä kuin organisaation muussakin toiminnassa. Erilaisten toimintatapojen tarpeen tunnistamisen jälkeen eritellään digitaalisen ja perin- teisen IT-toiminnon toteutustavan välisiä eroja ja tarkastellaan lyhyesti toteutusvaihto- ehtoja bimodaalisen IT-toiminnon järjestämiselle sekä toimintatavan vaikutuksia orga- nisaation toiminta- ja tietojärjestelmäarkkitehtuurin näkökulmista. Lopuksi tarkastellaan bimodaalisuuden elinkaarta, eli kahtia jakautuneeseen toimintatapaan siirtymistä ja toi- saalta siitä yhtenäiseen toimintatapaan palaamista. 2.1 Tarve kahdelle rinnakkaiselle toimintatavalle Mikä saa organisaation kehittämään tietoisesti saman toiminnon toteuttamiseksi useita rinnakkaisia toimintatapoja? Koskeeko bimodaalisuus vain IT-toimintoa, vai pyritäänkö siihen muussakin organisaatioiden toiminnassa? Digitaalisuus tarkoittaa julkisessa keskustelussa sekä talouden ja tekniikankin kielessä usein muuta, kuin sen alkuperäistä, täsmällisiin lukuarvoihin liittyvää merkitystä. Yri- tykset kertovat usein vastaavansa digitaalisuuden haasteisiin tai hyödyntävänsä digitaa- lisuuden mahdollisuuksia. Tällöin voidaan katsoa digitaalisuuden tarkoittavan yritysten toimintaympäristössä tapahtuvia, digitaaliseen teknologiaan perustuvia muutoksia, joi- hin yritysten tulee reagoida. Tätä digitaalisten teknologioiden muokkaamaa ja mahdol- listamaa yritysten toimintaympäristöä voidaan kutsua digitaaliseksi taloudeksi (engl. di- gital economy). Mesenbourg (2001) esittää digitaalisen talouden muodostuvan kolmesta pääasiallisesta osasta: · laitteiden, ohjelmistojen, tietoliikenneverkkojen, tukipalvelujen ja inhimillisen pääoman muodostamasta digitaalisen talouden mahdollistavasta infrastruktuu- rista (engl. e-business infrastructure), · tietoverkon yli suoritetuista liiketoimintaprosesseista (engl. e-business), sekä · tietoverkon yli myydyistä tuotteista ja palveluista (engl. e-commerce). 8Yritysten ja organisaatioiden digitaalisuuteen vastaamista tai sen hyödyntämistä voi- daan ajatella tähän perinteisestä taloudesta digitaaliseen talouteen siirtymiseen sisälty- viksi toimenpiteiksi. Tämä perinteisestä taloudesta digitaaliseen talouteen siirtyminen, eli uusien toimintatapojen omaksuminen ja toisaalta uudenlaiseen kilpailuun vastaami- nen, on vaatinut useiden vakiintuneiden organisaatioiden IT-toiminnolta bimodaalisen toimintatavan omaksumista (Haffke ym, 2017a). Tässä toimintatavassa digitaalinen osa IT-toiminnosta tuottaa asiakkaille uutta teknologiaa hyödyntäviä palveluja ketterästi, nopeasti ja asiakaslähtöisesti. Perinteinen IT-toiminto taas keskittyy organisaation sisäi- seen toimintaan ja pyrkii takaamaan sille vakaan, turvallisen ja suorituskykyisen IT-jär- jestelmien kokonaisuuden. Rinnakkainen perinteisillä ja perinteistä irrotetuilla tavoilla toimiminen vakiintuneissa organisaatioissa ei koske pelkästään IT-toiminnon järjestämistapaa. Useilla vakiintu- neilla yrityksillä osa toiminnasta on organisoitu sisäisiksi start-up -yrityksiksi, jotka pystyvät toimiman ilman yritykselle sen historian aikana muodostuneiden toimintatapo- jen painolastia. Märijärvi ym. (2016, s. 23) esittävät vakiintuneiden yritysten käynnistä- mät start-up:it erityisesti yhtenä yritysten keinoista uusiutua. Vakiintuneet yritykset ke- hittyvät tyypillisesti kyvykkäiksi pitämään yllä nykyisenlaista toimintaansa ja toimi- maan johdonmukaisesti ja ennustettavasti. Tämä kasvattaa yritysten operatiivista tehok- kuutta, mutta rajoittaa niiden kykyä uusiutumiseen. Märijärven ym. (2016, s. 41–42) ku- vauksen mukaiset yrityksen sisäiset start-up:it saavat toisaalta vapauksia yrityksen toi- mintatavoista, mikä mahdollistaa uusien liiketoimintamallien nopean kehittämisen ja kokeilun, mutta hyötyvät silti yrityksen osaamisesta, voimavaroista ja tukipalveluista. Myös digitaalinen IT-toiminto voitaneen sen organisointitavasta riippuen ajatella enem- män tai vähemmän eräänlaisena organisaation sisäisenä start-up -yrityksenä, joka hyö- tyy organisaation osaamisesta ja voimavaroista, mutta joka pystyy toimimaan perin- teistä IT-toimintoa ketterämmin. Vaikka digitaalista IT-toimintoa ei olisikaan järjestetty omaksi organisaatioyksikökseen, voidaan organisaation kuitenkin todeta irrottaneen osan toiminnastaan toimimaan erillään vakiintuneista toimintatavoista. 92.2 Bimodaalinen IT Edellä kuvattiin, miten asteittainen perinteisestä taloudesta digitaaliseen talouteen siirty- minen on edellyttänyt organisaatioilta usein samanaikaista toimimista kahdella eri ta- valla – digitaalisella ja perinteisellä. Organisaatioiden IT-toiminnoille tämä on tarkoitta- nut kahdenlaisia vaatimuksia ja samoin usein kahdella eri tavalla toimimista. Tarkastel- laan seuraavaksi, mitä digitaalinen ja perinteinen IT:n toimintatapa tarkoittavat käytän- nössä. Digitaalisesta ja perinteisestä toimintatavasta koostuvan bimodaalisen IT:n käsite tuli suuren yleisön tietoisuuteen tutkimusyhtiö Gartnerin raportissa vuonna 2013 (Aron & McDonald, 2013), ja sitä koskevaa keskustelua on käyty akateemisen tutkimuksen si- jasta pääosin yritysmaailmassa. Keskustelun käsitteistö ei ole vakiintunutta, ja toiminta- tapaa on kutsuttu myös muun muassa kahden nopeuden IT:ksi (engl. dual speed IT tai two speed IT). (Horlach ym., 2016.) Gartner (2017) määrittelee bimodaalisen IT:n tarkoittavan IT-toiminnon järjestämistä kahdella erillisellä tavalla, joista ensimmäinen keskittyy ennakoitavuuteen ja toinen ko- keellisuuteen. Näistä tavoista ensimmäinen soveltuu käytettäväksi hyvin tunnetuilla ja ennakoitavilla alueilla, ja toinen kokeellisemmilla ja uuden luomista vaativilla alueilla. Horlach ym. (2016) kuvaavat ensimmäistä toimintatapaa perinteiseksi ja toista digitaa- liseksi IT:ksi. He esittävät näille IT-toiminnon toteutustavoille taulukon 1 mukaiset piir- teet. 10 Taulukko 1. Perinteisen ja digitaalisen IT:n piirteitä (mukaillen Horlach ym, 2016) Perinteinen IT Digitaalinen IT Vakaus Tavoite Ketteryys ja nopeus IT-keskeinen Kulttuuri Liiketoimintakeskeinen Kaukana asiakkaasta Etäisyys asiakkaasta Lähellä asiakasta Suorituskyvyn ja turvalli- suuden parantaminen Käynnistäjä Lyhyen aikavälinen trendit markkinoilla Palvelujen suorituskyky Arvo Liiketoimintatilaisuudet2 Turvallisuus ja luotetta- vuus Palvelujen fokus Innovaatio Vesiputousmalli Lähestymistapa Iteratiivinen ja ketterä kehitys Taltiointijärjestelmiä Sovellukset Osallistavia järjestelmiä Hidas Palvelujen toimittamisen nopeus Nopea Horlachin ym. (2016) mukaan perinteinen IT-toiminto pyrkii tuottamaan IT-palveluja tehokkaasti ja luotettavasti. Sitä kuvaavat muun muassa vakauden, korkean suoritusky- vyn ja turvallisuuden tavoittelu. Perinteisen IT:n järjestelmät ovat usein taltiointijärjestelmiä (engl. systems of record), jotka on luotu ja tarkoitettu tietojen keräämiseen, tallennukseen ja käsittelyyn. Näitä jär- jestelmiä kehitetään vesiputousmallin mukaisesti pitkäkestoisilla, hallituilla ja selkeästi vaiheistetuilla projekteilla. (Horlach ym. 2016.) Digitaalinen IT toimii perinteistä IT:tä itsenäisemmin laajemman organisaation sisällä. Se vastaa organisaation toimintaan liittyviin lyhytaikaisiin markkinoiden trendeihin, 2 Alkuperäinen Horlachin ym. (2016) viittaama, ja Gartnerin käyttämä käsite on ”business moment”. Se viittaa asiakkaan tilanteeseen, johon on mahdollista vastata useilla toisiinsa kytköksissä olevilla palve- luilla. Esimerkkinä Gartner käyttää tilannetta, jossa älykäs asunto tunnistaa lievän vesivahingon, ehdottaa talon käyttäjälle maalausta ja tilaa automaattisesti maalaustarvikkeet. Kts. https://www.gartner.com/smar- terwithgartner/the-rise-of-the-business-moment/, viitattu 16.11.2017 11 tuottaen niihin vastaavia digitaalisia palveluita. Digitaalista IT:tä kuvaavat ketteryys, lii- ketoimintakeskeisyys, nopeus ja innovaatioiden tavoitteleminen. Digitaalisen IT:n jär- jestelmät ovat tyypillisesti osallistavia järjestelmiä (engl. systems of engagement), jotka mahdollistavat tiedon käsittelyn sijasta käyttäjiensä välistä vuorovaikutusta ja yhteis- työtä. (Horlach ym. 2016.) Moore (2011) esittää Kirscherin ja Kenneyn (2014) viittaamassa artikkelissaan taltioin- tijärjestelmien ja osallistavien järjestelmien välisiä eroja. Mooren esittämät, taulukon 2 mukaiset ominaisuudet kuvaavat yritysten käyttämiä perinteisiä ja digitaalisia järjestel- miä erityisesti yritysten sisällönhallinnan (engl. enterprise content management) näkö- kulmasta, mutta esitettyjen ominaisuuksien voidaan katsoa kuvaavan perinteisiä yritys- järjestelmiä ja käyttökokemukseltaan kuluttajatasoisempia digitaalisen IT:n järjestelmiä yleisemminkin. 12 Taulukko 2. Taltiointijärjestelmien ja osallistavien järjestelmien ominaisuuksia (mukaillen Moore 2011) Taltiointijärjestelmät (perinteinen IT) Osallistavat järjestelmät (digitaalinen IT) Transaktiot Fokus Vuorovaikutus Johtamisjärjestely3 Hallinta Yhteistyö Faktat, päivämäärät, vel- voitteet Keskeiset elementit Näkemykset, ideat, nyanssit Yksi lähde totuudelle Arvo Avoin foorumi Tarkkuus ja täydellisyys Suorituskyky Ajankohtaisuus ja saatavuus Toimitettua Sisältö Yhteinen Dokumentit (teksti, gra- fiikka) Ensisijainen taltion tyyppi ”Keskustelut” (tekstipoh- jaiset, kuvat, ääni, video) Helppoa Haettavuus Vaikeaa Käyttäjät koulutetaan käyttämään järjestelmää ja heille tarjotaan siihen tukea Käytettävyys Käyttäjä ”tuntee” järjestelmän kuluttaja- kokemuksen pohjalta Säännelty Pääsy Tapauskohtainen ja avoin Pysyvä Tallennus Väliaikainen Turvallisuus (omaisuuden turvaaminen) Menettelytavan painopiste4 Yksityisyys (käyttäjien turvaaminen) Mooren (2011) järjestelmiä koskevasta kuvauksesta voidaan katsoa korostuvan perintei- sen IT:n pyrkimys oikeellisuuteen mm. tietojen sisällössä, niihin kohdistuvassa pääsyn- 3 Engl. Command & control 4 Engl. Policy focus 13 hallinnassa, käyttäjien osaamisessa. Digitaalisen IT:n voidaan ajatella toimivan epä- muodollisemmin ja vähemmän suunnitellusti. Järjestelmät suunnitellaan käytettäviksi kuluttajille suunnattujen sovelluksien kaltaisesti ja ilman erillistä koulutusta. Järjestel- miin tallennettava tieto on vähemmän täsmällistä ja etukäteen suunniteltua, eikä siihen pääsyä tai sen elinkaarta välttämättä suunnitella yhtä täsmällisesti. Vaikka edellä kuvatuille toimintatavoille on kirjallisuuden perusteella haastavaa antaa yksikäsitteisiä määritelmiä, antanevat Mooren (2011) ja Horlachin ym. (2016) kuvauk- set ja niiden perusteella esitetty pohdinta riittävän ymmärryksen perinteisen ja digitaali- sen IT:n eroavaisuuksista sekä niihin kohdistuvissa tavoitteissa että niiden toteutusta- voissa. 2.3 Liiketoiminnan ja informaatioteknologian yhteensovittaminen Edellä kuvattiin perinteisesti ja digitaalisesta toimintatavasta koostuvaa bimodaalista IT-toimintoa. Bimodaalisen IT-toiminnon tarpeen todettiin edellä liittyvän organisaation toimintaympäristöön ja siihen, että toiminnon tulee kyetä vastaamaan kahdenlaisiin vaa- timuksiin. Toisin sanoen voidaan todeta, että IT-toiminnon tulee olla yhdenmukainen organisaation toimintaympäristön vaatimusten kanssa. Tarkastellaan seuraavaksi mitä tällaisella yhdenmukaisuudella (engl. alignment) tarkoitetaan. Nadler ja Tushman esittävät, että kaksi komponenttia ovat yhdenmukaisia (engl. aligned), kun niiden tarpeet, vaatimukset, tavoitteet, päämäärät ja/tai rakenteet ovat kes- kenään johdonmukaisia.5,6 (Baker & Jones 2008, s. 5.) Yhdenmukaisuutta kuvaavissa malleissa nämä tarkasteltavat komponentit vaihtuvat sen mukaan, mistä näkökulmasta organisaatiota tarkastellaan. Baker ja Jones (2008) kuvaa- vat aiemman kirjallisuuden perusteella viisi eri malleissa esiintyvää yhdenmukaisuuden näkökulmaa: · liiketoiminnan yhdenmukaisuus (engl. business alignment) organisaation strate- gian ja sen organisaatiorakenteiden ja resurssien välillä, 5 ”the degree to which the needs, demands, goals, objectives, and/or structure of one component are consistent with the needs, demands, goals, objectives, and/or structure of another component” (Baker & Jones 2008, s. 5) 6 Baker ja Jones (2008) toteavat samassa yhteydessä yhden määritelmän soveltamisen olevan haasteellista, koska yhdenmukaisuudesta puhutaan eri asiayhteydessä tarkastelun kohteesta riippuen. 14 · IT:n yhdenmukaisuus IT-strategian ja IT-resurssien välillä, · kontekstuaalinen yhdenmukaisuus (engl. contextual alignment) organisaation kilpailullisen toimintaympäristön ja sen sisäisten resurssien välillä, · rakenteellinen yhdenmukaisuus (engl. structural alignment) organisaation re- surssien ja IT-resurssien välillä, ja · strateginen yhdenmukaisuus organisaation strategian ja liiketoiminnan välillä. Tässä tutkielmassa organisaation tietojärjestelmien ja sen muiden piirteiden välistä yh- denmukaisuutta tarkastellaan Hendersonin ja Venkatramanin (1993) esittämän strategi- sen yhdenmukaisuuden mallin (engl. strategic alignment model) kautta. Organisaation liiketoiminnan ja IT-toiminnon välistä suhdetta kuvaava malli on Bakerin ja Jonesin (2008) esittämää useista lähteistä koostettua mallia suppeampi, mutta tutkielmassa käy- tettäväksi arvioiduista malleista parhaiten tunnettu ja yleisimmin käytetty. Mallin käyttö tutkielmassa on tarkoituksenmukaista erityisesti sitä koskevan ja sitä hyödyntävän tutki- muksen suuren määrän takia. Hendersonin ja Venkatramanin (1993) esittämä malli jaottelee organisaation toiminnan kuvan 1 mukaisesti toisaalta ulkoiseen ja sisäiseen sekä toisaalta liiketoiminnan ja infor- maatioteknologian toimialueisiin. Kokonaisuuden yhdenmukaisuus koostuu strategi- sesta yhteensopivuudesta (engl. strategic fit), eli yhdenmukaisuudesta ulkoisen ja sisäi- sen toimialueen välillä, sekä toiminnallisesta integraatiosta (engl. functional integra- tion), eli liiketoiminnan ja informaatioteknologian välisestä yhdenmukaisuudesta. Toi- sin sanoen malli siis korostaa tarvetta samanaikaiselle liiketoiminnan ja IT-toiminnon väliselle yhteensopivuudelle sekä organisaation sisäisen toiminnan strategianmukaisuu- delle. Mallissa esitetty ulkoinen toimialue tarkoittaa organisaation toimintaympäristöä. Toi- mintaympäristö käsittää organisaation kilpailijat ja yhteistyökumppanit, sekä muun mu- assa yrityksen kilpailijoistaan erottavat strategiset tekijät. Sisäinen toimialue taas tar- koittaa organisaation rakenteen, prosessien, osaamisen ja kyvykkyyksien kaltaisia sisäi- siä seikkoja. (Henderson ja Venkatraman, 1993.) Malliin sisältyvä jaottelu liiketoiminnan ja informaatioteknologian välillä taas erottelee toisistaan organisaation toiminnan ja informaatioteknologian, eli muuta toimintaa tuke- van IT-toiminnon. Kun organisaation toiminta jaetaan osa-alueisiin näiden toimialuei- 15 den perusteella ensin sisäiseen ja ulkoiseen ja toisaalta liiketoimintaan ja informaatio- teknologiaan, muodostuu jaottelun seurauksena neljä strategista kokonaisuutta: i) liike- toimintastrategia, ii) IT-strategia, iii) organisaation infrastruktuuri ja prosessit, sekä iv) tietojärjestelmäinfrastruktuuri ja -prosessit. (Henderson ja Venkatraman, 1993) Kuva 1. Strategisen yhdenmukaisuuden malli (mukaillen Hendersson ja Venkatraman 1993, s. 476) Organisaation strateginen yhdenmukaisuus muodostuu näiden edellä kuvattujen toimi- alueiden (ja siten niiden muodostamien neljän strategisen kokonaisuuden) välisistä suh- teista. Esitettyä mallia ja osien välisiä suhteita on havainnollistettu kuvassa 1. Ulkoisella alueella tapahtuvaa liiketoiminta- ja IT-strategioiden yhdenmukaistamista kutsutaan strategiseksi integraatioksi. Sisäisten toimialueiden, eli organisaation ja tie- tojärjestelmien infrastruktuurin ja prosessien yhdenmukaistamista kutsutaan operatio- naaliseksi integraatioksi. (Henderson ja Venkatraman, 1993.) Organisaation strategiset valinnat eri osa-alueilla voidaan jakaa taulukon 3 mukaisten aihepiirien valintoihin. 16 Taulukko 3. Osa-alueilla tehtävät valinnat Liiketoimintastra- tegia · Liiketoiminnan alue: organisaation ulkoista toimintaym- päristöä koskevat valinnat, kuten sen markkinoiden va- linta ja sijoittuminen kilpailijoihin nähden. · Erottavat kompetenssit: organisaation valinnat sen kil- pailijoista erottumiseen, mm. hinnoittelu, laatu ja valitut jakelukanavat. · Liiketoiminnan hallinta: organisaation valitsemat kump- panit, suhteet sidosryhmiin ym. IT-strategia · Teknologian alue: liiketoiminnan strategian tukemiseen käytettäväksi valitut teknologiat · Järjestelmiin liittyvät kompetenssit: liiketoiminnan stra- tegian tukemiseen tietojärjestelmiltä vaadittuihin laatu- vaatimuksiin sekä informaatioteknologian osaamiseen liittyvät valinnat · IT-hallinta: toimittajat ja kehittämiskumppanit, joita vaaditaan haluttujen järjestelmiin liittyvien kompentens- sien saavuttamiseen Organisaation inf- rastruktuuri ja prosessit · Hallinnollinen infrastruktuuri: organisaation rakennetta, hallintamalleja, rooleja ja vastuita koskevat valinnat · Prosessit: liiketoimintastrategioiden suorittamiseen vaa- dittavien prosessien suunnittelussa tehtävät valinnat · Osaaminen: liiketoiminnan strategian suorittamiseen vaadittavaan osaamiseen liittyvät valinnat Tietojärjestelmä- infrastruktuuri ja prosessit · Arkkitehtuurit: käytettäviä sovelluksia, laitteistoja ja oh- jelmistoja määrittävät, sekä tietoarkkitehtuuria koskevat valinnat · Prosessit: tietojärjestelmien käyttö- ja ylläpitoprosessei- hin ja työskentelytapoihin liittyvät valinnat · Osaaminen: organisaation IT-infrastruktuurin käyttöön ja ylläpitoon tarvittavan osaamien hankintaan, kasvatta- miseen ja ylläpitoon liittyvät valinnat 17 Tarkastellaan seuraavaksi, miten näillä edellä kuvatuilla neljällä alueella tehtävillä va- linnoilla varmistetaan kaikkien osa-alueiden strateginen yhdenmukaisuus. Henderson ja Venkatraman (1993, s. 477) esittävät, että alueiden kahdenvälisen yhdenmukaisuuden tarkastelu ei ole tarkoituksenmukaista. Heidän mukaansa esimerkiksi keskityttäessä ul- koiseen toimialueeseen ja varmistettaessa ainoastaan liiketoimintastrategian ja IT-strate- gian yhdenmukaisuus, on merkittävä mahdollisuus sille, että sisäisen toimialue – eli or- ganisaatio- ja tietojärjestelmäinfrastruktuuri – muodostuvat keskenään ristiriitaisiksi. Yhdenmukaisuuden varmistaminen vaatii Hendersonin ja Venkatramanin (1993, s. 477) mukaan toimialueiden sisäisen, kahdenvälisen yhdenmukaistamisen sijasta toimialuera- jat ylittävää, kolme osa-aluetta käsittävää tarkastelua. He esittävät tarkastelulle neljä eri näkökulmaa: liiketoimintastrategiaa ajurina käyttävät strategian toteuttaminen ja tekno- logiatransformaation näkökulmat sekä IT-strategiasta lähtevät kilpailullisen potentiaalin ja palvelutason näkökulmat. Ensimmäisessä esitetyistä strategisen yhdenmukaistamisen näkökulmista, strategian to- teuttamisen näkökulmassa, strategisen yhdenmukaisuuden tarkastelu aloitetaan kuvan 2 mukaisesti ajurina käytettävästä organisaation liiketoiminnalle määritellystä strategi- asta. Tästä liiketoimintaa koskevasta strategiasta johdetaan sekä organisaation infra- struktuuriin liittyvät päätökset että niistä seuraavat tietojärjestelmäinfrastruktuurin ja prosessien toteutustavat. Kuva 2. Strategisen yhdenmukaistamisen ensimmäinen näkökulma: Strategian toteuttaminen 18 Henderson ja Venkatraman (1993) toteavat strategian toteuttamisen näkökulman olevan mallissa esitetyistä näkökulmista kenties yleisimmin käytetty ja laajimmin ymmärretty, koska se vastaa perinteisen hierarkkisen organisaation ylhäältä alas suuntautuvaa oh- jausrakennetta. Teknologiatransformaation näkökulma käyttää strategian toteuttamisen näkökulman tavoin liiketoimintastrategiaa (kuva 3) muun suunnittelun ajurina, mutta siinä tietojär- jestelmäinfrastruktuurin ja prosessien suunnitteluun päädytään liiketoimintastrategiasta johdetun IT-strategian kautta. Näkökulma jättää siis organisaation sisäisen rakenteen ja toteutustavan huomiotta IT:n toteutustavan rajoitteena ja keskittyy sen sijasta tarkastele- maan ensin millainen IT-strategia tukee parhaiten liiketoimintastrategiaa. Kuva 3. Strategisen yhdenmukaistamisen toinen näkökulma: Teknologiatransformaatio Sekä strategian toteuttamisen että teknologiatransformaation näkökulma lähtevät edellä kuvatusti liiketoimintastrategian määrittelystä ja päätyvät tietojärjestelmäinfrastruktuu- rin ja IT:n prosessien suunnitteluun, joskin eri reittejä. Samoin organisaation liiketoi- minta- ja IT-johdon roolit eroavat näissä näkökulmissa toisistaan. Strategian toteuttami- sen näkökulmassa organisaation ylin johto toimii strategian muotoilijana, ja IT strate- gian kustannuspaikkamaisesti toimivana toteuttajana. Teknologiatransformaation näkö- kulmassa liiketoiminnan johto tuottaa liiketoimintastrategiaa tukevan teknologiavision, jota IT-toiminto strategiallaan toteuttaa. IT-johto toimii tällöin ”teknologia-arkkiteh- tina”, suunnitellen ja toteuttaen visiota vastaavan tietojärjestelmäinfrastruktuurin. IT- toiminnon arviointi perustuu tällöin sisäisen näkökulman sijasta enemmän ulkoiseen 19 vertailuun ja organisaation sijoittumisen arviointiin muihin IT-toimijoihin nähden. (Henderson ja Venkatraman, 1993) Kahdesta ensimmäisestä näkökulmasta eroten kolmas ja neljäs Hendersonin ja Venkat- ramanin (1993) esittämä strategisen yhdenmukaisuuden näkökulma lähtevät liiketoimin- tastrategian sijasta IT-strategian määrittelystä. IT-strategialähtöiset näkökulmat pyrkivät tuottamaan teknologian mahdollistamana uusia liiketoimintastrategioita. Kilpailullisen potentiaalin näkökulmassa (kuva 4) pyritään hyödyntämään markkinoi- den uusia teknologisia kyvykkyyksiä. Kuva 4. Strategisen yhdenmukaistamisen kolmas näkökulma: Kilpailullinen potentiaali. Tässä näkökulmassa organisaation sijoittuminen IT-markkinalla vaikuttaa sen liiketoi- mintastrategiaan. Sijoittuminen IT-markkinalla ja uudet teknologiset kyvykkyydet voi- vat esimerkiksi vaikuttaa valittuun liiketoiminnan alueeseen niiden mahdollistamien uu- sien tuotteiden ja palvelujen muodossa, vaikuttaa organisaation muista markkinoiden toimijoista erottaviin osaamisiin ja luoda uusia kumppanuuksia. Palvelutason näkökulma keskittyy ”maailmanluokan” IT-toiminnon kehittämiseen. Lähtökohtana strategisen yhteensopivuuden saavuttamiselle on tällöin IT-strategian luonti ja sen kanssa yhdenmukaisen IT-toiminnon järjestämistavan suunnittelu, mikä mahdollistaa IT-toiminnolle kapasiteetin liiketoiminnan tarpeisiin vastaamiseen. 20 Kuva 5. Strategisen yhdenmukaistamisen neljäs näkökulma: Palvelutaso. Liiketoimintastrategia toimii palvelutasonäkökulmassa huomioitavana tekijänä ainoas- taan epäsuorasti sen tuottamien liiketoiminnan operatiivisen tason tarpeiden kautta. Ku- ten liiketoimintastrategiaa ajurin käyttävissä näkökulmissa, liiketoiminnan ja IT-toimin- non johdot toimivat myös molemmissa IT-strategialähtöisissä näkökulmissa erilaisissa rooleissa. Kilpailullisen potentiaalin näkökulmassa liiketoiminnan johto tuottaa liiketoiminta- vision, joka kuvaa ulkoisten teknologisten muutosten aiheuttamia vaikutuksia liiketoi- mintastrategiaan. IT-johto toimii tällöin katalyyttina, joka kuvaa ulkoisessa toimintaym- päristössä tapahtuvista teknologisista muutoksista aiheutuvia uhkia ja mahdollisuuksia. Tässä näkökulmassa IT-toimintoa arvioidaan markkinaosuuden ja uusien tuotteiden esittelyn kaltaisilla liiketoiminnan mittareilla. Palvelutason näkökulmassa liiketoiminnan johto toimii priorisoijana, joka määrittelee, miten rajalliset resurssit tulisi kohdentaa sekä ulkoisesti IT-markkinaan nähden että or- ganisaation sisäisesti. IT-toiminnolla on tällöin toiminnallisen johdon rooli, jossa se pyrkii vastaamaan sisäisenä IT-liiketoimintana liiketoimintajohdon asettamiin vaati- muksiin. Yhteenvetona strategisen yhteensovittamisen mallista sen voidaan todeta korostavan ul- koisen toimintaympäristön merkitystä myös organisaation IT-toiminnon järjestämiselle. IT-toiminnon piirteitä ei tarkastella ainoastaan organisaation liiketoimintaan ja sitä oh- jaavaan strategiaan nähden, vaan myös ulkoisesti muuhun IT-markkinaan nähden. 21 Malli esittää perinteiselle liiketoimintastrategiasta liiketoiminnan ja IT-toiminnon to- teuttamistavan johtavalle strategian toteuttamisen näkökulmalle kolme vaihtoehtoista tarkastelutapaa. Lisäksi malli kuvaa vaihtoehtoisia rooleja liiketoiminta- ja IT-johdolle esitettyjen näkökulmien yhteydessä noudatettavaksi. 2.4 Liiketoiminta ja bimodaalinen IT-toiminto Edellä tarkasteltiin liiketoiminnan ja IT:n yhdenmukaisuuden tavoitetta, ja erilaisia lä- hestymistapoja sen saavuttamiseksi. Tarkastellaan seuraavaksi, miten organisaatiot pää- tyvät järjestämään IT-toimintonsa kahdella eri toimintatavalla toteutetuksi ja miten kah- desta toimintatavasta koostuva IT-toiminto tukee edellä kuvattua strategista yhdenmu- kaisuutta. 2.4.1 Bimodaalisuuteen siirtyminen Haffke ym. (2017a) esittävät, että digitaaliseen ja perinteiseen toimintatapaan jakautu- minen liittyy liiketoiminnan vaatimukseen tehokkaammasta tuesta digitaalisille toimin- tatavoille. Lisääntyvät organisaation ulkoiset ja sisäiset digitaalisuuteen liittyvät vaati- mukset vaativat IT-toiminnolta enemmän ketteryyttä sekä samanaikaista kokeelli- suutta ja tehokkuutta7 kuin perinteiset IT:n hallintamenetelmät mahdollistavat. IT-toimintoa koskevat kokeellisuuden ja innovatiivisuuden, eli teknologian uusien hyö- dyntämistapojen löytämisen, vaatimukset ovat ristiriidassa IT:n perinteisten tavoitteiden ja toimintatapojen, kuten kustannusten alentamisen ja pieninä muutoksina tapahtuvan kehittämisen kanssa. IT:n ketteryyden vaatimuksella Haffke ym. (2017a) tarkoittavat IT-toiminnon kyvyk- kyyttä tunnistaa innovaatioiden mahdollisuuksia ja vastata niihin nopeasti. Tällainen IT- toiminto pystyy sopeutumaan nopeasti organisaation ulkoisen toimintaympäristön muu- toksiin ja hyödyntämään tunnistamiaan mahdollisuuksia. Edellä kuvatun liiketoiminnan ja IT:n strategisen yhdenmukaisuuden mallin näkökulmasta tarkasteltuna he toteavat IT- toiminnon ketteryyden tarkoittavan kyvykkyyttä korjata liiketoiminnan ja IT:n väliset 7 Horlach ym. (2016) kutsuvat kokeellisuuden ja innovatiivisuuden vaatimusta IT:n monikätisyydeksi (engl. ambidexterity), viitaten tällä toisaalta teknologian mahdollisuuksien kokeelliseen tutkimiseen (engl. explorative) ja toisaalta olemassa olevan teknologian hyödyntämiseen (engl. exploitative). 22 epäjohdonmukaisuudet nopeasti. Tiwana ja Konsynski (2010) esittävät, että IT:n kette- ryyden vaatimukset eivät kohdistu pelkästään IT:n kykyyn tukea organisaatiota kette- rästi, vaan myös sen kykyyn toteuttaa omaa toimintaansa koskevia muutoksia. Kolmanneksi syyksi ketteryyden ja kokeellisuuden vaatimusten ohella bimodaalisuu- teen siirtymiselle Haffke ym. (2017a) esittivät tarpeen rakenteelliseen yhdenmukaisuu- teen IT-toiminnon ja liiketoiminnan välillä. He toteavat, että digitaalisuuden muokatessa liiketoimintaa, ilmenee usein tarpeita muokata liiketoiminnan rakenne vastaamaan orga- nisaation uutta palvelutarjoamaa. Tämä voi vaatia vastaavia rakenteellisia muutoksia myös IT-toiminnolta, mikäli esimerkiksi tietyt digitaalisuuteen painottuneet liiketoimin- tayksiköt tarvitsevat IT-toiminnolta muita yksiköitä enemmän tukea. Bimodaalisen IT-toiminnon esitetään siis tukevan liiketoiminnan ja IT-toiminnon yh- denmukaisuutta vastaamalla kolmeen keskeiseen liiketoiminnasta aiheutuvaan tarpee- seen. Tarkastellaan seuraavaksi, miten bimodaalinen IT-toiminto vaikuttaa Hendersonin ja Venkatramanin (1993) strategisen yhdenmukaistamisen mallissa esitettyyn liiketoi- minnan ja IT-toiminnon yhdenmukaistamiseen, eli näiden alueiden yhteensopivien stra- tegioiden ja toimintatapojen valintaan. 2.4.2 Bimodaalisen IT-toiminnon ja liiketoiminnan yhdenmukaisuus Horlachin ym. (2016) mukaan kahdella tavalla toimiva IT-toiminto aiheuttaa kahdenlai- sia uusia huomioitavia seikkoja Hendersonin ja Venkatramanin (1993) esittämän strate- gisen yhdenmukaistamisen mallin soveltamiseen – vaatimuksen digitaalisen ja perintei- sen IT-toiminnon yhteensovittamisesta (kuva 6) sekä kahden keskenään erilaisen toi- mintatavan huomioimisesta organisaation liiketoiminnan strategiassa ja operatiivisessa toiminnassa (kuva 7). Vaatimus digitaalisen ja perinteisen IT:n saattamisesta keskenään yhteensopiviksi johtuu siitä, että asiakkaille tarkoitetut digitaalisen IT:n järjestelmät käyttävät tyypilli- sesti perinteisen IT:n piirissä olevien taustajärjestelmien tietoja. Tällöin digitaalisen IT:n ketterien ja kokeilevien toimintatavat vaativat perinteisen IT:n järjestelmiltä ja ark- kitehtuurilta muutoksia, jotteivat ne omalla toiminnallaan hidasta tai estä digitaalisen IT:n toimintatapoja. 23 Kuva 6. Liiketoiminnan ja bimodaalisen IT-toiminnon yhteensovittaminen. Toinen Horlachin ym. (2016) esittämä tarve on liiketoiminnan sovittaminen digitaali- sen ja perinteisen IT:n erilaisiin toimintatapoihin. Irrotettaessa aiemmasta IT-toimin- nosta digitaalisella tavalla toimivia osia, voidaan ne liittää osaksi aiemmin puhtaasti lii- ketoimintaan kuuluneita organisaatioyksiköitä. Niiden tavoitteet ja toiminta tulee tällöin kuvan 7 mukaisesti saattaa yhteensopivaksi niitä vastaavan liiketoiminnan strategian ja operatiivisen toiminnan kanssa. Kuva 7. Digitaalisen IT-toiminnon ja sitä vastavan liiketoiminnan yhteensovittaminen. Hendersonin ja Venkatramanin (1993) mallin kautta tarkasteltuna Horlachin ym. (2016) esittämien huomioiden voitaneen katsoa vaikuttavan sekä strategiseen yhdenmukaista- miseen että toiminnalliseen integraatioon – perinteisen ja digitaalisen IT:n yhteensovit- taminen on huomioitava informaatioteknologian toimialueen sisäisessä strategisessa yh- denmukaistamisessa, ja liiketoiminnan sovittaminen bimodaaliseen IT-toimintoon taas 24 vaikuttaa liiketoiminnan ja informaatioteknologian toimialueiden välisessä toiminnalli- sessa integraatiossa. Hendersonin ja Venkatramanin (1993) esittämistä neljästä strategisen yhdenmukaista- misen näkökulmasta perinteisen IT-toiminnon voidaan katsoa vastaavan erityisesti liike- toiminnan strategiasta lähtevien näkökulmien (strategian toteuttaminen ja teknolo- giatransformaatio) tarpeisiin – tavoitteena on tuolloin liiketoiminnan strategiaa vastaa- van tietojärjestelmäkokonaisuuden ja prosessien muodostaminen. Digitaalinen IT-toi- minto taas tukee tässä tarkastelussa IT-strategiaa ajurina käyttäviä näkökulmia (kilpai- lullinen potentiaali ja palvelutaso), joissa pyritään tunnistamaan ja hyödyntämään tieto- järjestelmien ulkoisella toimialueella teknologian tuottamia mahdollisuuksia, ja hyödyn- tämään niitä liiketoiminnassa. 2.4.3 Bimodaalisuuden järjestämistavat Tarkastellaan seuraavaksi millä tavoin kaksi rinnakkaista toimintatapaa näkyvät IT-toi- minnon organisaatiorakenteessa. Haffke ym. (2017a) tunnistavat kolme tyypillistä jär- jestämistapaa digitaaliselle ja perinteiselle IT-toiminnolle – projektikohtaiset toimintata- vat, IT-toiminnon jakautumisen kahteen erilaiseen toimintatapaan sekä jakautumisen kahteen erilliseen toimintoon. Ensimmäisessä Haffken ym. (2017a) kuvaamista bimodaalisen IT-toiminnon toiminta- tavoista, projektikohtaisessa toimintatavassa, osa organisaation projekteista voidaan ku- van 8 mukaisesti toteuttaa organisaation ja sen IT-toiminnon tavallisesti noudattamista prosesseista poikkeavasti. Kuva 8. Projektikohtainen toimintatavan valinta 25 Projektikohtainen bimodaalinen toiminta tarkoittaa Haffken ym. (2017a) kuvaamissa esimerkkitapauksissa käytännössä kevyemmillä prosesseilla toimivaa, kokeilevampaa ja virheitä hyväksyvämpää toimintatapaa. Haasteena digitaalisten toimintatapojen käyt- töönotolle todetaan projektikohtaisen toimintatavan esimerkkitapausten yhteydessä muun muassa henkilöstön osaaminen ja uudenlaisen työskentelytavan omaksuminen sekä vahvasti säännellyillä aloilla sääntelyn ja siihen liittyvien tarkasti määriteltyjen prosessien huomioiminen. Huomionarvoisena seikkana projektikohtaisesta toimintatavan valinnasta voidaan to- deta, että esitetty malli ei näytä tarkastelevan projektien tuottamien tietojärjestelmien elinkaaren myöhempiä vaiheita. Esimerkkitapausten kuvauksissa käytetyistä pilottipro- jektin ja prototyypin käsitteistä voitaneen päätellä, että näissä tapauksissa digitaalisilla toimintatavoilla tuotetut palvelut ja sovellukset ovat kokeiluluontoisia, ja oletettavasti niiden käytön jatkuessa perinteisempien IT-toiminnon palvelutuotannon menetelmien piiriin siirrettäviä. Toisessa Haffken ym. (2017a) esittämässä tyypillisessä bimodaalisen IT:n järjestämista- vassa IT-toiminto on kuvan (9) mukaisesti jaettu rakenteellisesti kahteen erilaiseen toi- mintatapaan. Kuva 9. IT-toiminto jakautuneena kahteen toimintatapaan Haffke ym. (2017a) esittävät kahteen erilaiseen toimintatapaan jaetun IT-toiminnon to- teuttamisesta eri toimialojen yritysten tekemiä valintoja kuvaavia esimerkkejä. Yhteistä 26 näille kuvatuille esimerkeille on tarve ylläpitää ja kehittää nykyisiä järjestelmiä ja toi- saalta innovoida ja hyödyntää uusista teknologioista aiheutuvia mahdollisuuksia. Viimeinen ja pisimmälle viety Haffken ym. (2017a) tunnistama bimodaalisuuden toteu- tustapa on digitaalisen IT-toiminnon järjestäminen kuvan 10 mukaisesti perinteisestä IT-toiminnosta kokonaan erillisenä organisaatioyksikkönä. Haffken ym. (2017a) esittä- mässä esimerkkitapauksessa uuden digitaalisen IT-toiminnon perustamista käytettiin myös tarkoituksellisesti organisaation sisäisenä viestinnällisenä keinona innovatiivisem- man ajattelutavan ja kulttuurin kasvattamiseksi. Tarkastellussa esimerkissä olemassa olevan perinteisen IT-toiminnon ei katsottu soveltuvan digitaalisuuden edistäjäksi sen toiminnan pääpainon ollessa kustannustietoisessa nykyjärjestelmien ylläpidossa ja koska sen ei katsottu riittävällä tasolla tuntevan yrityksen ydinliiketoimintaa. Kuva 10. IT kahtena erillisenä toimintona. Haffke ym. esittävät myös yritysostot erääksi tavaksi päätyä kahden erillisen IT-toimin- non malliin. Heidän kuvaamassaan esimerkkitapauksessa yritysoston jälkeen päädyttiin ostetun yrityksen innovatiivinen IT-toiminto säilyttämään erillään ostajan perinteisem- min toimivasta IT-toiminnosta. (Haffke ym., 2017a) 27 2.4.4 Bimodaalisuuden elinkaari Aiemmin tarkasteltiin bimodaaliseen toimintaan siirtymistä sekä kahden erilaisen toi- mintavana järjestämisen vaihtoehtoja. Tarkastellaan seuraavaksi, millainen elinkaari bi- modaalisella IT-toiminnolla on, eli vaihtuuko sen järjestämistapa bimodaalisuuden ai- kana ja palataanko siitä yhtenäiseen toimintatapaan. Haffken ym. (2017a) kuvaamissa tapauksissa osa yrityksistä oli siirtynyt projektikohtai- sesta toimintatavasta (1. esitetty toteutustapa) rakenteellisesti jakautuneeseen IT-toimin- toon (2. esitetty toteutustapa), ja toisaalta osa myös rakenteellisesta jakautumisesta kah- tena erillisenä toimintona toimimiseen (3. esitetty toimintatapa). Yksikään aineiston yri- tyksistä ei ollut kuitenkaan siirtynyt järjestyksessä kaikkien esitettyjen kolmen toiminta- tavan läpi. Haffke ym. (2017a) esittävät yhtenä keskeisistä tekemistään havainnoista, että digitaali- seen ja perinteiseen IT-toimintoon jakautuminen on tilapäinen ja lyhyt vaihe IT-toimin- non kehityksessä ja pitkäkestoisemmassa digitaalisuuden vaatimuksiin vastaavassa muutoksessa (kuva 11). Kuva 11. Bimodaalisen IT-toiminnon vaiheet (Haffke ym., 2017a, muokattu). Haffke ym. (2017a) toteavat tarkastelemillaan organisaatioilla olleen miltei poikkeuk- setta IT-toiminnon johdon tavoitteena siirtyä koko toiminnon osalta yhtenäiseen, kette- rään ja digitaalisuutta paremmin tukevaan toimintatapaan, ja bimodaalinen toimintatapa 28 toimi tässä muutoksessa tilapäisenä siirtymävaiheena. Kolme heidän tarkastelemistaan yhdeksästätoista organisaatiosta oli sekä siirtynyt bimodaaliseen toimintatapaan että jat- kanut muutosta siirtymällä yhtenäiseen ketterämpään ja kokeellisempaan IT-toimintoon. Toisessa artikkelissaan Haffke ym. (2017b) esittävät tarkemmin jälleen yhdistyneen IT- toiminnon sisäistä toteutustapaa. He kuvaavat IT-toiminnon toimivan tällöin projekteis- saan ja ulkoisten sidosryhmiensä näkökulmasta ketterästi, ja ainoastaan perinnejärjestel- mien ylläpito noudattaa perinteisiä toimintatapoja. 2.5 Yhteenveto luvusta Tässä luvussa esitettiin bimodaalisen, eli digitaalisesta ja perinteisestä toimintatavasta koostuvan IT-toiminnon keskeisiä seikkoja. Luvun alussa esitettiin yleisellä tasolla digi- taalista taloutta, ja tarkasteltiin sen vakiintuneille organisaatioille aiheuttamia haasteita. Organisaatioiden vakiintuneiden toimintatapojen todettiin olevan usein operatiivisesti tehokkaita, mutta rajoittavan niiden kykyä uusiutumiseen. Kahdella eri tavalla toimiva IT-toiminto todettiin voitavan nähdä sisäisten start-up -yritysten kaltaisena keinona toi- saalta varmistaa organisaation nykyisen toiminnan häiriintymättömyys ja toisaalta pyr- kiä hyötymään digitaalisuuden mahdollisuuksista. Luvun toisessa kohdassa tarkasteltiin perinteisen ja digitaalisen IT-toiminnon piirteitä pääosin Horlachin ym. (2016) esittämän luonnehdinnan perusteella. Vaikka akateemisen tutkimuksen ulkopuolella syntyneille toimintatavoille oli haastavaa löytää täsmällisiä määritelmiä, muodostavat esitetyt ominaisuudet käsityksen perinteisen ja digitaalisen IT:n eroavaisuuksista. Yhteenvetona voidaan perinteisen IT-toiminnon painottavan toi- minnan jatkuvuuden ja kustannustehokkuuden kaltaisia seikkoja, kun taas digitaalinen IT-toiminto pyrkii ketterästi ja kokeilevasti hyödyntämään teknologian tuomia mahdol- lisuuksia. Luvun kolmannessa kohdassa tarkasteltiin Hendersonin ja Venkatramanin (1993) esittä- mää strategisen yhdenmukaisuuden mallia. Mallin tarkastelu auttaa lukijaa hahmotta- maan, millaisia huomioitavia seikkoja liittyy organisaation toiminnan ja sitä tukevan IT- toiminnon suunnitelmien ja käytännön tason toiminnan yhdenmukaisuuden varmistami- seen. Hendersonin ja Venkatramanin esittämä malli tarkastelee organisaatiota toisaalta sisäisestä ja ulkoisesta, ja toisaalta liiketoiminnan ja tietojärjestelmien kautta. Nämä 29 kaksi tarkastelutapaa muodostavat neljä kokonaisuutta liiketoimintastrategia (liiketoi- minta, ulkoinen), IT-strategia (tietojärjestelmät, ulkoinen), organisaation infrastruktuuri ja prosessit (liiketoiminta, sisäinen), sekä tietojärjestelmäinfrastruktuuri ja -prosessit (tietojärjestelmät, sisäinen). Hendersonin ja Venkatraman (1993) esittävät myös neljä eri etenemistapaa näiden kokonaisuuksien yhdenmukaistamiseksi. Strategisen yhdenmukaisuuden käsitteen ja mallin tarkastelun jälkeen esitettiin luvun viimeisessä kohdassa liiketoiminnan ja bimodaalisen IT-toiminnon yhteensovittamiseen liittyviä seikkoja. Aluksi tarkasteltiin, millaiset seikat saavat organisaatiot päättämään kahteen erilaiseen toimintatapaan siirtymisestä. Haffken ym. (2017a) mukaan organisaa- tiot vaativat IT-toiminnolta ketteryyttä, eli kykyä hyödyntää nopeasti teknologian tuot- tamia mahdollisuuksia, sekä kaksikätisyyttä, eli samanaikaista pyrkimystä sekä innova- tiivisuuteen ja kokeellisuutta että operatiiviseen tehokkuuteen. Bimodaalisuuteen siirtymisen kuvaamisen jälkeen tarkasteltiin toimintatavan vaikutusta liiketoiminnan ja IT-toiminnon yhdenmukaisuuden varmistamiseen sekä tunnistettuja tapoja organisoida näillä eri tavoilla tehtävä työ. Viimeisenä tarkasteltiin bimodaalisesti toimivien IT-toimintojen kehittymistä ajan kuluessa. Bimodaalisuuden todettiin olevan tyypillisesti väliaikainen vaihe laajemmassa IT-toiminnon kehittymisessä liiketoimin- nan tarpeisiin ketterämmin vastaavaksi ja digitaalisuutta hyödyntäväksi toiminnoksi. 30 3 Kokonais- ja ohjelmistoarkkitehtuurit Edellisessä luvussa kuvattiin vakiintuneiden organisaation haasteita digitaalisuuteen liit- tyviin haasteisiin vastaamisessa, sekä esitettiin bimodaalisen IT-toiminnon malli liike- toiminnan tehokkaammaksi tukemiseksi informaatioteknologian avulla. Tässä luvussa tarkastellaan kokonais- ja ohjelmistoarkkitehtuuria sekä niihin liittyviä käsitteitä. Luvun tarkoituksena on erityisesti luoda ymmärrys siitä, miten organisaatiota kuvaava kokonaisarkkitehtuuri yhdistää sen strategian ja tavoitteet käytännön toimintaprosessei- hin ja niitä tukevaan teknologiaan. Toisaalta erityisesti ohjelmistojen sisäisiä toteutusta- poja käsittelevän ohjelmistoarkkitehtuurin peruskäsitteiden tarkastelu auttaa hahmotta- maan seuraavassa luvussa käsiteltävän mikropalveluarkkitehtuurin piirteitä. Luvun alussa tarkastellaan hyvin lyhyesti yleistä arkkitehtuurin käsitettä. Tämän jälkeen siirrytään tarkastelemaan laajinta näkökulmaa arkkitehtuurityölle – organisaation toi- minnan tasolta lähtevää ja organisaation käyttämien tietojärjestelmien tarkastelutasolle päätyvää kokonaisarkkitehtuuria. Tämän yhteydessä esitetään läheisesti kokonaisarkki- tehtuurin hyödyntämiseen liittyviä kokonaisarkkitehtuurin viitekehyksiä ja valitaan niistä tämän työn pohjana käytettävä viitekehys. Kokonaisarkkitehtuuriin liittyvien kä- sitteiden ja näkökulmien esittelyn sekä tarkastelun viitekehyksen valinnan jälkeen siir- rytään tarkastelemaan ohjelmistoarkkitehtuuria ja siihen liittyviä käsitteitä. 3.1 Arkkitehtuuri yleisesti Arkkitehtuurille on esitetty kirjallisuudessa useita määritelmiä. IEEE-standardointijär- jestön määritelmää, joka esittää arkkitehtuurin tarkoittavan ”järjestelmän tai organisaa- tion perustavanlaatuista rakennetta, joka ilmenee sen osissa, sen osien keskinäisissä ja ympäristöönsä liittyvissä suhteissa sekä sen suunnittelua ja kehittymistä ohjaavissa peri- aatteissa.”8 (IEEE 2000, s. 3). Standardin käsitteistössä järjestelmä ymmärretään hyvin laajasti – se voi tarkoittaa esimerkiksi organisaatiota tai ohjelmistoa, ja voi olla ihmisen tekemä tai luonnon muovaama. 8 ”the fundamental organization of an enterprise (or system) embodied in its components, their relation- ships to each other, and to the environement, and the principals guiding its design and evolution” 31 Ohjelmisto- ja kokonaisarkkitehtuureilla tarkoitetaan tämän määritelmän kautta tarkas- teltuina pohjimmiltaan samankaltaista kuvausta järjestelmän arkkitehtuurista – koko- naisarkkitehtuurissa tarkasteltava järjestelmä on usein organisaatio tai sen osa, kun taas ohjelmistoarkkitehtuurissa järjestelmänä tarkastellaan ohjelmistoa. Vaikka pohjimmiltaan kokonais- ja ohjelmistoarkkitehtuurit kuvaavat samankaltaisesti järjestelmien osia ja niiden välisiä suhteita, eroavat ne tarkastelunsa kohteen lisäksi toi- sistaan myös muun muassa kuvaamisessa käytettävien menetelmien ja viitekehysten osalta. Tarkastellaan seuraavaksi kokonaisarkkitehtuuria. 3.2 Kokonaisarkkitehtuuri Kokonaisarkkitehtuuri (engl. enterprise architecture) on organisaation toiminnan tar- kastelussa käytetty menetelmä ja näkökulma. Edempänä tarkasteltavan ohjelmistoarkki- tehtuurin tapaan sekin kuvaa tarkastelunsa kohteen osia ja rakenteita – valitusta tarkas- telun näkökulmasta riippuen esimerkiksi organisaation liiketoimintaprosesseja, palve- luita ja tietojärjestelmiä. Kokonaisarkkitehtuuri sitoo nämä organisaation perusrakenteet yhteen siten, että niistä muodostuu yhtenäinen ja saumattomasti toimiva kokonaisuus (JUHTA 2017b, s. 23). Kokonaisarkkitehtuurille on esitetty useita toisistaan osin eroavia määritelmiä. Julkisen hallinnon tietohallinnon neuvottelukunta (JUHTA 2017b, s. 3) esittää kokonaisarkkiteh- tuurin olevan organisaation ”toiminnan, prosessien ja palvelujen, tietojen, tietojärjestel- mien ja niiden tuottamien palvelujen muodostaman kokonaisuuden rakenne.” Valtioneuvoston kanslian (2008) mukaan ”kokonaisarkkitehtuuri on kokonaisvaltainen toiminnan kehittämiseen tarkoitettu lähestymistapa. Se on strategisen johtamisen väline, jonka avulla yhtenäistetään toiminnan kehittämistä ja informaatio- ja viestintäteknolo- gian hyödyntämistä julkishallinnossa. Sen avulla kehitetään organisaation toimintaa, tie- toja, tietojärjestelmiä ja teknologiaa yhtenä kokonaisuutena.” Kokonaisarkkitehtuurilla voidaan siis näiden määritelmien mukaan tarkoittaa ainakin sekä tietynlaista kuvausta9 kohdealueestaan että lähestymistapaa ja työmenetelmää, joka tuottaa tällaisen kuvauksen. Sekä lähestymistavalle että siinä tuotettavalle kuvaukselle 9 Organisaation erilaisia rakenteita koskevan kuvauksen lisäksi kokonaisarkkitehtuurilla voidaan viitata myös itse näihin rakenteisiin, on niitä kuvattu tai ei. 32 voitaneen katsoa olevan yhteistä niiden tarkastelun laaja näkökulma, joka yltää toimin- taprosesseista ja niitä tukevien tietojärjestelmien tekniseen toteutukseen asti. Kuvauksen kohdealueena voi olla useista organisaatioista muodostuva kokonaisuus, tai yksittäinen organisaatio tai sen osa. Tarkastellaan seuraavaksi, miten organisaatiot hyötyvät kokonaisarkkitehtuurista. 3.2.1 Kokonaisarkkitehtuurin hyödyt Kokonaisarkkitehtuuria voidaan edellisessä luvussa tarkastellun Hendersonin ja Venkat- ramanin (1993) esittämän strategisen yhdenmukaisuuden mallin kautta tarkasteltuna pi- tää keinona sekä strategisen yhdenmukaisuuden että toiminnallisen integraation edistä- miseen. Mallin sanastolla esitettynä kokonaisarkkitehtuuri auttaa ymmärtämään, kuvaa- maan ja hallinnoimaan organisaation liiketoiminnan infrastruktuuria ja prosesseja, to- teuttamaan ne liiketoiminnan strategian mukaisiksi sekä integroimaan informaatiotekno- logian ja liiketoiminnan yhteensopivaksi kokonaisuudeksi. Ross, Weill & Robertson (2006) esittävät kokonaisarkkitehtuurin menetelmänä, jolla luodaan organisaation toimintamallia (engl. operating model) toteuttava ydinprosessien ja niitä tukevien keskeisten järjestelmien muodostama toiminnan perusta (engl. founda- tion for execution). Toimintamalli määrittää tavoitellun prosessien integroinnin ja stan- dardoinnin tason, jonka vaatimuksia kokonaisarkkitehtuuri toteuttaa. IT-hallintamalli (engl. IT engagement model) kuvaa menetelmät, joilla varmistetaan yksittäisten IT-pro- jektien ja yrityksen tavoitteiden keskinäinen vastaavuus. Ross ym. (2006) esittävät, että edellä mainituista kolmesta kokonaisuudesta muodostu- vaa toiminnan perustaa tarvitaan seuraavan kaltaisten organisaatioiden ulkoisessa toi- mintaympäristössä tapahtuneiden muutosten takia: · Organisaatioiden tietojärjestelmäkokonaisuuden kasvava monimutkaisuus estää järjestelmien kehittämistä. Vakiintuneiden organisaatioiden olemassa olevat jär- jestelmät muodostavat usein toisiinsa tiiviisti liittyvän kokonaisuuden, johon tehtävät muutokset ovat kalliita ja riskialttiita. · Liiketoiminnan ketteryys on riippuvainen toiminnan perustasta. Ross ym. (2006) esittävät, että organisaation pysyvien ydinprosessien standardointi ja digitali- sointi vapauttavat voimavaroja mm. uusien tuotteiden ja uuden liiketoiminnan kehittämiseen. 33 · Organisaatioihin kohdistuva sääntely ja raportointivaatimukset aiheuttavat uusia vaatimuksia. Toiminnan perusta ja kokonaisarkkitehtuuri toimivat kilpailuetuna, kun organisaation tulee kyetä tuottamaan toiminnastaan uutta sääntelyn vaati- maa tietoa. · Toiminnan perustan toteuttaminen on halvempaa ja vähemmän riskialtista kuin sen toteuttamatta jättäminen. Ross ym. (2006) esittävät, että toiminnan perusta voidaan toteuttaa projekti kerrallaan, hyödyntäen organisaatiossa muutenkin to- teutettavia projekteja. Tarkastellaan seuraavaksi, millaisia hyötyjä kokonaisarkkitehtuurityö tuottaa organisaa- tiolle. Kokonaisarkkitehtuurin hyötyjä on kuvannut muiden muassa Niemi (2006). Hän luokittelee kokonaisarkkitehtuurilla saavutettavat hyödyt mitattaviin ja ei-mitattaviin sekä vahvasti ja heikosti kokonaisarkkitehtuuriin liitettäviin. Vahvasti kokonaisarkkitehtuuriin liitettäviä mitattavia hyötyjä ovat Niemen (2006) mu- kaan kasvaneet mittakaavaedut (engl. economies of scale), parantunut yhteensopivuus ja integrointi, lisääntynyt uudelleenkäytettävyys, lisääntynyt standardointi, alentuneet kus- tannukset ja lyhentyneet prosessin läpimenoajat (engl. cycle time). Vahvasti kokonais- arkkitehtuuriin liitettäviä, ei-mitattavia hyötyjä ovat: kehittyvä kokonaisarkkitehtuurin hallinta (engl. evolutionary EA governance), parantunut päätöksenteko ja kokonaisku- van muodostuminen organisaatiosta. Niemen (2006) yhtenä kokonaisarkkitehtuurin ei-mitattavista hyödyistä esittämää koko- naiskuvan muodostamista organisaatiosta voitaneen ajatella keskeiseksi kokonaisarkki- tehtuurin tuottamaksi hyödyksi, joka välillisesti mahdollistaa muita hyötyjä. Ymmärrys organisaation muodostavista osista – muun muassa toiminnasta, prosesseista, tietojärjes- telmistä – mahdollistaa sekä nykytilan ymmärtämisen, että organisaation tavoitteita vas- taavan tavoitetilan muodostamisen sekä sen saavuttamiseksi tarvittavan muutoksen hal- litun suorittamisen. Kokonaisarkkitehtuurityön tuotokset toimivat myös kommunikaa- tiovälineenä: ne auttavat organisaation eri toimijoita ymmärtämään paremmin toistensa toimintaa ja kehittämään yhteistyötä (JUHTA, 2017b). 34 3.2.2 Kokonaisarkkitehtuurin viitekehykset Edellä kuvattiin kokonaisarkkitehtuuritarkastelun laajuutta ja siitä saatavia hyötyjä. Tar- kastellaan seuraavaksi, miten kokonaisarkkitehtuuria käytännössä tehdään. Kokonaisarkkitehtuuria tarkastellaan tyypillisesti jonkin etukäteen valitun viitekehyksen kautta. Tarkastelulle ennalta valittu viitekehys ohjaa organisaatiota kuvaavan arkkiteh- tuurin muodostamista ja sen käyttöä, määrittäen esimerkiksi tarkastelussa käytettävät näkymät ja käsitteet, ja auttaen siten hallitsemaan organisaation toiminnan tarkasteluun väistämättä liittyvää monimutkaisuutta. Viitekehysten sisältämien kuvausten yksityis- kohtaisuus vaihtelee; osa niistä tyytyy esittämään kuvattavat asiat, ja jotkut voivat sisäl- tää esittämilleen näkymille mm. valmiita kuvauspohjia. Itse arkkitehtuurikuvauksissa käytettävien näkymien, käsitteiden ja dokumenttipohjien kaltaisten arkkitehtuurikuvauksen osien lisäksi viitekehykset pyrkivät ohjaamaan tyypil- lisesti myös arkkitehtuurin kuvaamistyötä. Ne voivat kuvata vaihtelevalla tarkkuusta- solla mm. arkkitehtuurityössä noudatettavia prosesseja, näiden prosessien syötteiden ja tuotosten kuvauksia sekä prosesseissa noudatettavia periaatteita ja käytäntöjä. Arkkitehtuurin viitekehykset voivat olla yleisiä ja toimialariippumattomia, tai erityisesti tietyllä toimialalla sovellettaviksi tarkoitettuja. Lisäksi yritykset voivat luoda omia viite- kehyksiä käyttöönsä tai yhdistellä ja muokata yleisiä malleja käyttöönsä sopiviksi hybri- diviitekehyksiksi. Cameronin ja McMillanin (2013) aineistossa yli puolet (54%) yrityk- sistä käytti kokonaisarkkitehtuurin viitekehyksenään tällaista yhdisteltyä viitekehystä. Tarkastellaan seuraavaksi kokonaisarkkitehtuurin kuvaamiseen ja kehittämiseen tarkoi- tettuja kokonaisarkkitehtuuriviitekehyksiä. Koska työn tarkoituksena on tarkastella esi- tettyjä bimodaalisen IT-toiminnon, kokonaisarkkitehtuurin ja mikropalveluarkkitehtuu- rin aihepiirejä julkishallinnon ja tarkemmin Turun kaupungin toimintaan sovellettuina, tarkastellaan kokonaisarkkitehtuuriviitekehyksistä kattavimmin julkishallinnolle kehi- tettyä JHS 179 -viitekehystä. Tätä ennen tarkastellaan lyhyesti Zachmanin viitekehystä sekä TOGAF-viitekehystä, johon JHS 179 pohjautuu. Zachmanin viitekehys Kokonaisarkkitehtuurin viitekehyksien tarkastelu on luonnollista aloittaa Zachmanin viitekehyksestä, jota pidetään yleisesti ensimmäisenä kokonaisarkkitehtuurin viiteke- 35 hyksenä. Viitekehys perustuu Zachmanin havaintoihin rakentamisen ja lentokoneteolli- suuden kaltaisista, monimutkaisia järjestelmiä tuottavista toimialoista, ja niiden yhtäläi- syyksistä tietojärjestelmien kehittämiseen (Zachman, 1987). Lähtökohtana kohdealueen tarkastelussa ovat eri roolien edustamat näkökulmat. Viite- kehys kuvaa kohdealueensa suunnittelijan (engl. planner), omistajan, järjestelmän suun- nittelijan (engl. designer), toteuttajan, ohjelmoijan ja käyttäjän näkökulmista. Näiden roolien katsotaan edustavan yleistä kohdealue- ja toimialariippumatonta prosessia, jossa abstraktin suunnitelman perusteella suunnitellaan ja toteutetaan konkreettinen tuotos. Näkökulmien tarkastelutaso etenee suurista kokonaisuuksista ja liiketoiminnasta kohti teknistä toteutusta ja sen yksityiskohtia. Näkökulmia tarkastellaan kuudella eri abstrak- tiotasolla eri kysymysten kautta. Tarkastellut kysymykset ovat mitä, miten, missä, kuka, milloin ja miksi. Näkökulmien pilkkominen näiden kysymysten kautta tarkasteltavaksi vähentää näkökulmaan liittyvää monimutkaisuutta (Zachman, 2002). Eri roolien kautta esitetyt näkökulmat ja kysymysten kautta tarkastellut abstraktiotasot muodostavat taulukon, jonka soluissa esitetään näkökulmaa ja abstraktiotasoa vastaava arkkitehtuuriin sisältyvä malli. Näin Zachmanin esittämä viitekehys jakaa monimutkai- sen kohdealueen edellä kuvatusti yksinkertaisempiin näkökulmiin ja malleihin. Zachmanin viitekehys kuvaa organisaation tai kohdealueen kattavat näkökulmat sekä sitä kuvaavan arkkitehtuurin muodostamat mallit, mutta ei sisällä prosessia tai menetel- miä tämän kuvauksen laatimiseen (Cameron & McMillan, 2013). Tarkastellaan seuraa- vaksi myös arkkitehtuurityötä ohjaavaa ja sen tuotoksia kuvaavaa TOGAF-viitekehystä. TOGAF The Open Group Architecture Framework (lyh. TOGAF) on laajalti tunnettu ja käy- tetty10 kokonaisarkkitehtuurin viitekehys. Jos edellä kuvattua Zachmanin viitekehystä ajatellaan lähinnä kohdealueen tarkasteluun ja pilkkomiseen käytettävänä käsitteellisenä kehyksenä, voidaan TOGAF:ia ajatella sekä loogisena viitekehyksenä että joukkona työkaluja tuon kehyksen mukaisen arkkitehtuurityön toteuttamiseen. 10 Cameronin ja McMillanin (2013) aineistossa yleistä viitekehystä käyttäneistä organisaatioista ylivoi- maisesti suurin osa käytti TOGAF:ia. Myös useasta lähteestä yhdisteltyä hybridiviitekehystä käyttävät organisaatiot kertoivat käyttäneensä yleisimmin TOGAF:ista lainattuja osia. 36 Lähimpänä Zachmanin viitekehyksen sisältöä olevana TOGAF:in osana voitaneen pitää arkkitehtuurin sisällön viitekehystä (engl. architecture content framework), joka kuvaa ja luokittelee arkkitehtuuria kuvaavat erilaiset tuotokset. Toiseksi erityisen huomionarvoiseksi piirteeksi TOGAF:issa voidaan katsoa sen sisäl- tämä arkkitehtuurin kehittämismenetelmä (engl. Architecture Development Method). Menetelmä kuvaa yksityiskohtaisen iteratiivisen prosessin kohdealueen arkkitehtuurin kehittämiseen. Prosessi koostuu kymmenestä vaiheesta, jotka puolestaan jakautuvat yk- sittäisiin tehtäviin. Vaiheet kattavat arkkitehtuurityön sen valmistelusta ja sillä tavoitel- tavan vision muodostamisesta eri alueiden arkkitehtuurien laatimiseen ja niissä kuvattu- jen muutosten toteuttamiseen. Lisäksi TOGAF sisältää menetelmiä ja ohjeistusta arkkitehtuurin kehittämismenetelmän soveltamiseen, mallin arkkitehtuurien ja niihin perustuvien ratkaisujen luokittele- miseksi, teknisiä järjestelmiä ja integroitua tietoinfrastruktuuria kuvaavat referenssimal- lit sekä mallin organisaation kokonaisarkkitehtuuritoiminnon järjestämiseksi. JHS 179 Julkisen hallinnon tietohallinnon neuvottelukunnan julkaisema kokonaisarkkitehtuurin suunnittelua ja kehittämistä koskeva JHS-suositus 179 on Suomessa valtion- ja kunnal- lishallinnossa yleisesti käytetty kokonaisarkkitehtuurin viitekehys. Se on osa julkishal- linnon tietohallinnolle tarkoitettuja JHS-suosituksia, joiden ”tavoitteena on parantaa tie- tojärjestelmien ja niiden tietojen yhteentoimivuutta, luoda edellytykset hallinto- ja sek- torirajoista riippumattomalle toimintojen kehittämiselle sekä tehostaa olemassa olevan tiedon hyödyntämistä” (JUHTA, 2017a). JHS 179 perustuu edellä kuvattuun yleiseen ja toimialariippumattomaan TOGAF-viitekehykseen, ja soveltaa sen sisältöä julkishallin- non toimialalle. Tarkastellaan seuraavaksi viitekehyksen kuvauksen aluksi kokonaisarkkitehtuuriin liit- tyviä keskeisiä käsitteitä vielä JHS 179 -viitekehyksen näkökulmasta. JHS 179 -suositus määrittelee kokonaisarkkitehtuurin olevan ”organisaation tai muun kohteena olevan kokonaisuuden rakenteen kuvaus, jota käytetään toiminnan kehittämi- sessä. Kokonaisarkkitehtuurin avulla on mahdollista hallinnoida ja kehittää organisaa- tioiden tai muiden valittujen kohteiden toimintaa systemaattisesti.” (JUHTA 2017b, s. 12.) 37 Kokonaisarkkitehtuurimenetelmän todetaan olevan ”menetelmä, jonka avulla kehite- tään suunnitelmallisesti ja systemaattisesti kohteena olevaa kokonaisuutta tai sen rajat- tua osaa” (JUHTA 2017b, s. 12). Arkkitehtuurin viitekehyksen suositus määrittelee olevan ”malli, jonka mukaan orga- nisaation tai muun kehittämiskohteen rakenteita jäsennetään, hallitaan ja kehitetään” (JUHTA 2017b, s. 10). Edellä kuvatusti JHS 179 liittää kokonaisarkkitehtuurin ja toiminnan kehittämisen hyvin tiiviisti toisiinsa – kokonaisarkkitehtuuri on määritelty käyttötarkoituksensa kautta orga- nisaation kehittämisessä käytettäväksi rakenteeksi. Viitekehys jäsentää kokonaisarkkitehtuuria hyödyntävän kehittämisen kuvan 12 mukai- sesti kolmeen vaiheeseen: organisaation toimintamallin tai -mallien määrittelyyn, arkki- tehtuurirakenteiden tunnistamiseen ja suunnitteluun sekä kehittämisen toimeenpanoon ja toteutukseen. (JUHTA 2017b, s. 25–27.) Kuva 12. JHS 179:n suunnittelurakenteiden kokonaisuudet (JUHTA 2017b, s. 27, muokattu). Lähtökohtana kehittämiselle on organisaation strategiaprosessi. JHS 179 ei edellytä käyttämään tai määrittele sisällöltään tietynlaista strategiaprosessia, mutta tarjoaa strate- giatyöhön välineitä ja toisaalta ohjaa sitä määritellyillä strategiaprosessilta tarvittavilla tuotoksilla. Strategiaa ja sen sisältämiä toimenpiteitä syötteenään käyttävä organisaation toiminta- mallin tai -mallien määrittely kuvaa, millaisella (liike-)toimintamallilla strategian 38 asettamat vaatimukset voidaan toteuttaa. Viitekehys ei kuvaa täsmällisesti liiketoiminta- mallilta vaadittavaa sisältöä, vaan toteaa sen yleisesti kuvaavan tapaa, jolla organisaatio järjestää toimintansa. Eräs tapa tarkastella liiketoimintamallia on katsoa sen koostuvan organisaation kyvyk- kyyksistä. Kyvykkyydellä tarkoitetaan ”organisaation kykyä ja taitoa saavuttaa päämää- riensä mukaisia vaikutuksia toiminnassa ja sen tuloksissa”. Kyvykkyydet toimivat JHS 179 -viitekehyksessä keskeisenä rajapintana muodosta- miensa toimintamallien ja organisaation kyvykkyyksiä toteuttavien arkkitehtuuriraken- teiden välillä. Arkkitehtuurirakenteiden tunnistaminen ja suunnittelu esittää, millai- sista prosesseista, tiedoista, järjestelmistä ja teknologioista kyvykkyydet muodostetaan siten, että niistä muodostuu yhtenäinen ja saumattomasti yhteen toimiva kokonaisuus. Arkkitehtuurirakenteiden kuvausten perusteella muodostetaan kehittämistoimenpiteiden toteuttamissuunnitelmat. Tarkastellaan seuraavaksi arkkitehtuurirakenteiden tunnistamista ja suunnittelua tukevia arkkitehtuurisisällön ja -kuvausten viitekehyksiä. Arkkitehtuurisisällön viitekehys sisältää toiminnan kannalta olennaiset rakenteet, jotka on ryhmitelty aikajärjestyksessä kokonaisarkkitehtuurityön vaiheiden mukaisesti periaatteisiin, visioon ja vaatimuksiin liittyviin sisältöihin, arkkitehtuurirakenteisiin sekä arkkitehtuurin toteutukseen ja toteutettavuuteen liittyviin sisältöihin. 39 Kuva 13. Kokonaisarkkitehtuurin sisältöviitekehys (JUHTA 2017b, muokattu). JHS 179 -viitekehyksen mukaisen arkkitehtuurityön perustana on arkkitehtuurin peri- aatteiden, vision ja vaatimusten tunnistaminen. Arkkitehtuurin lähtökohtana tunniste- taan tarkasteltava kehittämiskohde ja sen rajaukset, sekä muodostettavaa arkkitehtuuria ohjaavat periaatteet. Arkkitehtuurivision muodostamisella esitetään hahmotelma arkki- tehtuurin kohteen tulevaisuudesta. Lisäksi arkkitehtuurityön alkuvaiheessa tunnistetaan sidosryhmät ja niiden vaatimukset, ja sovitetaan ne yhteen. Arkkitehtuurivision tarkoi- tuksena on varmistaa koko arkkitehtuurityön ajan, että suunnittelun kohde ja suunta ovat jatkuvasti selvillä. (JUHTA, 2017b.) Arkkitehtuurirakenteet ovat edellä kuvatusti organisaation toiminnan vaatimia ja sen kyvykkyyksiä toteuttavia rakenteita. Arkkitehtuurirakenteet auttavat jäsentämään arkki- tehtuurin kohteen nykytilaa sekä kuvaamaan sen arkkitehtuurivision mukaista tavoiteti- laa. Tunnistetut arkkitehtuurirakenteet on jaoteltu viitekehyksessä toiminta-, tieto-, tie- tojärjestelmä- ja teknologia-arkkitehtuurin näkymien mukaisesti. Näitä kokonaisarkki- tehtuurin näkymiä tarkastellaan lähemmin kohdassa 3.2.3. Arkkitehtuurin toteutuksen sisällöillä varmistetaan suunnitellun arkkitehtuurin toteu- tettavuus. Tällöin arkkitehtuurirakenteilla kuvatun tavoitetilan perusteella muodostetaan 40 esimerkiksi hankkeiden työlistojen (engl. backlog) tai työpakettien muodossa esitettäviä kehitystoimenpiteitä. Arkkitehtuurikuvausten viitekehys esittää kuvaustapoja tarkasteltaviksi valituille ark- kitehtuurisisällöille. Jos arkkitehtuurisisällön viitekehyksen ajatellaan käsittävän kaikki arkkitehtuurityössä mahdollisesti tarvittavat sisällöt, voidaan arkkitehtuurikuvausten vii- tekehyksen katsoa sisältävän hyväksi havaitut kuvaustavat näille sisällöille. Yhtä sisäl- töön voi tällöin liittyä useita kuvaustapoja. Kuvaustavat on ryhmitelty niiden abstrak- tiotason mukaan. Näitä viitekehyksessä tunnistettuja tasoja ovat periaatteellinen taso (miksi?), käsitteellinen taso (mitä?), looginen taso (miten?) ja fyysinen taso (millä?). Kuva 14. Kokonaisarkkitehtuurin arkkitehtuurikuvausten viitekehys (JUHTA 2017b) Eri sisältöjä koskevat kuvaukset ovat käytännössä luetteloita, matriiseja, kaavioita tai tekstiä. Osa niistä keskittyy yhteen näkökulmaan liittyvän sisällön kuvaamiseen, ja osa esittää eri näkökulmien välisiä yhteyksiä. 41 Esimerkiksi palvelukartta voi sisältää luettelon kaikista organisaation tarjoamista palve- luista, kuvaten siten toiminta-arkkitehtuurin näkökulmaan liittyvä sisältöä. Palvelukar- tan voidaan ajatella vastaavan kysymykseen ”mitä palveluja organisaatio tuottaa” ja ole- van siten yksi toiminta-arkkitehtuuria esittävistä käsitteellisen tason kuvauksista. Toisena esimerkkinä voidaan tarkastella prosessit–tiedot -matriisia, joka taas yhdistää toiminta-arkkitehtuuriin sisältyvät liiketoimintaprosessit niissä tietoarkkitehtuurin näkö- kulmaan sisältyviin tietoihin. Tarkastellaan seuraavaksi lähemmin edellä mainittuja toiminta-, tieto-, tietojärjestelmä- ja teknologia-arkkitehtuurin näkökulmia. 3.2.3 Kokonaisarkkitehtuurin näkökulmat Edellä todetusti kokonaisarkkitehtuuria tarkastellaan tyypillisesti jonkin etukäteen vali- tun viitekehyksen kautta. Viitekehykset määrittävät tarkastelussa käytettäviä näkymiä ja käsitteitä, auttaen siten osaltaan hallitsemaan monimutkaisuutta, joka väistämättä liittyy organisaation monimutkaisen toiminnan tarkasteluun. Arkkitehtuurinäkökulmien käytön voidaan katsoa perustuvan tarpeeseen tarkastella monimutkaista kokonaisuutta yksi nä- kökulma kerrallaan. Tämän tarkoituksena on helpottaa suunnittelutyötä muistuttaen ke- hittämiskohteeseen liittyvistä erilaista näkökulmista ja niiden keskinäisistä riippuvuuk- sista (JUHTA 2016b). JHS 179 -viitekehyksessä käytettävä organisaation toiminnan ja tietojärjestelmien muo- dostaman kokonaisuuden jaotteleminen toiminta-, tieto-, sovellus- ja teknologia-arkki- tehtuuriin perustuu edellä esitetyssä TOGAF-viitekehyksessä käytettävään jäsennyk- seen. Tämän tyyppinen jaottelu on toisinaan hieman mukailtuna hyvin laajasti käytössä. Ensimmäisen tai erään ensimmäisistä näitä näkymiä käyttävistä arkkitehtuuriviitekehyk- sistä esitti Stephen Spewak vuonna 1992 (Spewak ja Tiemann 2006). Seuraavassa tarkastellaan JHS-179 -viitekehykseen sisältyviä toiminta-, tieto-, sovellus- ja teknologia-arkkitehtuurin näkökulmia JHS-suosituksen sisällön (JUHTA 2017b) mu- kaisesti. JHS 179 määrittelee toiminta-arkkitehtuurin kokonaisarkkitehtuurin näkökulmaksi, joka kuvaa organisaation toiminnalliset rakenteet. Organisaation toiminnallisilla raken- teilla tarkoitetaan muun muassa organisaation sidosryhmiä, palveluita ja tuotteita sekä 42 prosesseja ja organisaatiorakennetta. Toiminta-arkkitehtuurin piiriin sisältyvät itse toi- minnan rakenteiden lisäksi myös organisaation visioiden ja strategian kaltaiset toimin- nan kehittämisen perusrakenteet. Toiminta-arkkitehtuurin voidaan ajatella ohjaavan muiden näkökulmien mukaista kehit- tämistä, sillä se esittää muun muassa organisaation asiakkailleen tarjoamat palvelut, joita esimerkiksi organisaation tietojärjestelmillä tuetaan. Toiminta-arkkitehtuurin käsitteellinen taso esittää, mitä organisaatiossa tai kehitettävällä osa-alueella tehdään sekä mitkä ovat sen toimintaan liittyvät toimijat ja palvelut. Loogi- sella tasolla näkökulma kuvaa, miten toimitaan tarkemmalla tasolla eli mitkä ovat toi- mintaan liittyvät prosessit ja miten prosessit ja niissä liikkuvat tiedot liittyvät toisiinsa. Toiminnan fyysistä tasoa ei yleensä kuvata osana toiminta-arkkitehtuuria. Tietoarkkitehtuuri on ”kokonaisarkkitehtuurin näkökulma, joka kuvaa organisaation käyttämät tiedot sekä tietojen rakenteet ja suhteet”. (JUHTA 2017b, s. 18.) Toiminta-arkkitehtuurin voidaan ajatella ohjaavan tietoarkkitehtuuria siten, että tietoark- kitehtuurin tulisi sisältää toiminnan tarvitsemat ja käyttämät tiedot. Sen avulla pyritään luomaan organisaation tai muun kehittämiskohteen yhteinen näkemys keskeisestä tieto- pääomasta ja helpottamaan tiedon jakamista, hyödyntämistä ja löytämistä. Tietoarkkitehtuurin käsiteellisellä tasolla kuvataan, mitä tietoa organisaation toimin- nassa tarvitaan, käytetään ja tuotetaan, sekä miten tämä tieto liittyy muihin tietoihin (JUHTA, 2017b). Eräs keskeinen tietoarkkitehtuurin käsitteellisen tason tuotos on käsi- temalli, joka kuvaa organisaation tai muun kehittämiskohteen toiminnan keskeiset käsit- teet, käsitteiden tietosisällöt ja niiden väliset loogiset suhteet. Käsitemalli auttaa yhdis- tämään esimerkiksi organisaation eri toiminnoissa tai erityisesti laajan kehittämiskoh- teen eri organisaatioissa käytettävät käsitteet yhtenäiseksi malliksi. Tämä malli toimii muuta kehittämistyötä tukevana työvälineenä, jolla varmistetaan esimerkiksi kehitettä- vien tietojärjestelmien semanttinen yhteensopivuus. Toinen keskeinen käsitteellisen ta- son tuotos ovat päätietoryhmät, jotka antavat yleiskuvan organisaatiossa tai kehittämi- sen kohteessa käsiteltävistä tietoaineistoista. Loogisella tasolla tietoarkkitehtuuri tarkastelee toiminnan kannalta keskeisiä tietovaran- toja, niiden välisiä suhteet sekä sitä, miten tietoa käytetään. Tarkastelun keskeisiä tuo- toksia ovat loogisten tietovarantojen sekä loogisten tietomallien sekä soveltamisprofii- lien ja tietovirtojen kuvaukset. 43 Loogisella tietovarannolla tarkoitetaan toiminnalle ja palveluille olennaista, yhteisesti hallinnoitua joukkoa tietoja tai tietoaineistoja. Vaikka loogisen tietovarannon tiedot voi- vat käytännössä sijaita useissa eri järjestelmissä, muodostavat ne loogisen tason tarkas- telussa yhden toisiinsa liittyvien tietojen kokonaisuuden. Loogiset tietomallit taas täy- dentävät käsitemalleja lisäämällä niissä esitetyille käsitteille tarvittavia attribuutteja. Tietoarkkitehtuurin fyysinen taso esittää, missä organisaation tai muun kehityskohteen tuottama ja käyttämä tieto fyysisesti sijaitsee. Fyysistä tasoa kuvattavia tuotoksia ovat organisaation käyttämien tietokantojen, rekisterien ja rajapintojen sisältöjä kuvaavat fyysiset tietomallit ja fyysiset tietovarannot. Tietojärjestelmäarkkitehtuuri tarkastelee tietoarkkitehtuurissa kuvattuja keskeisiä tie- toja käsitteleviä sovelluksia ja niiden muodostamia sovelluskokonaisuuksia, ja määritel- lään sovellusten keskinäiset suhteet ja riippuvuudet sekä niiden keskeiset ominaisuudet. Tietojärjestelmäarkkitehtuuri ei ota kantaa sovellusten tekniseen toteutukseen, vaan määrittelee, millaiset sovellukset ovat tarpeen organisaatiolle ja mitä tietojärjestelmäpal- veluita niiden tulee toteuttaa tietoarkkitehtuurin kuvaamien tietojen käsittelyn ja esittä- misen toteuttamiseksi organisaation eri toimijoille ja toisille tietojärjestelmille. Käsitteellisellä tasolla tietojärjestelmäarkkitehtuuri kuvaa ylätasolla, mitä sovelluksia ja sovelluskokonaisuuksia organisaatio hyödyntää tukeakseen toimintaansa. Tarkastelun keskeisenä tuotoksena on tietojärjestelmäpalveluiden kuvaus. Tietojärjestelmäpalve- luilla tarkoitetaan sekä käyttöliittymän kautta käytettäviä loppukäyttäjäpalveluja sekä rajapinnan kautta käytettäviä automatisoituja sovelluspalveluita. Tietojärjestelmäarkkitehtuurin loogisella tasolla kuvataan, miten sovelluksia käytetään tietoarkkitehtuuriin sisältyvien tietojen siirrossa ja toiminnan tukena. Keskeinen loogi- sen tason tarkastelun tuotos on arkkitehtuurin kerrosnäkymä, joka kuvaa miten tietojär- jestelmät, tietojärjestelmäpalvelut ja tietovarannot tukevat sekä toisiaan että toiminnan prosesseja ja palveluja. Looginen tietojärjestelmäarkkitehtuuri sisältää myös mm. eri tietojärjestelmien välisen vuorovaikutuksen, tietojärjestelmäsalkun ja loogisten rajapin- tojen kuvaukset. Fyysisen tietojärjestelmäarkkitehtuurin keskeisenä kuvauksena ovat fyysiset riippuvuu- det tietojärjestelmien ja teknologioiden välillä, eli esimerkiksi sitä, millä teknologioilla tietojärjestelmät on toteutettu. 44 Teknologia-arkkitehtuuri tarkastelee organisaatiossa käytettäviä teknologioita, stan- dardeja, rakenteita ja infrastruktuuria siten, että niiden muodostama kokonaisuus tukee organisaation toimintaa ja tavoitteita parhaalla mahdollisella tavalla. Käsitteellisellä ta- solla teknologia-arkkitehtuuri tarkastelee organisaation teknologiavalintoja ja niille ase- tettuja tai asetettavia vaatimuksia sekä ylätason teknologiapalveluja. Teknologiavalinto- jen kuvaamisen avulla pyritään yhtenäistämään käytettäviä teknologioita, kehittämään organisaation perusteknologioihin liittyvää osaamista, tehostamaan ylläpitotoiminnan laatua sekä lisäämään kustannustehokkuutta vähentämällä organisaatiossa käytettäviä keskenään erilaisia laitteistoja ja ohjelmistoja. Ylätason teknologiapalveluilla tarkoite- taan loogisella tasolla tarkasteltavien teknologiaresurssien tarjoamia konkreettisia palve- luja. Loogisella tasolla teknologia-arkkitehtuurin osalta kuvataan teknologiaresurssit, loogi- nen alustajäsennys ja looginen verkkokaavio. Teknologiaresursseja ovat esimerkiksi oh- jelmistotuotteet ja suoritusympäristöt, joiden avulla toteutetaan edellä mainittuja tekno- logiapalveluja. Looginen alustajäsennys tarkentaa tietojärjestelmäarkkitehtuuriin sisälty- vää kerrosarkkitehtuurin kuvauksen esittämällä mistä loogisista osista teknologiapalve- lut koostuvat. Looginen verkkokaavio taas kuvaa tietoliikenneverkkojen loogisen raken- teen ja niiden yhteydet sidosryhmien verkkoihin ja tietovarantoihin. Viimeisenä tarkasteltavana osa-alueena fyysinen teknologia-arkkitehtuuri kuvaa käy- tössä olevat konkreettiset teknologiat, niiden ominaisuudet sekä niiden elinkaaret. Fyy- sisen tason teknologia-arkkitehtuuria kuvaavia tuotoksia ovat laiteluettelo, fyysisten lai- tetilojen tiedot, lisenssisalkku ja fyysinen verkkokaavio. Kokonaisarkkitehtuurin näkökulmia tarkasteltaessa nähdään siis tarkastelun tarkkuusta- son etenevän organisaation asiakkailleen tarjoamien palvelujen tasolta aina tietojärjes- telmien yhteydessä käytettävien laitteiden ja laitetilojen tarkasteluun asti. Sen toiminta- lähtöisen tarkastelun ei kuitenkaan voida katsoa kiinnittävän erityisesti huomiota orga- nisaation käyttämien ohjelmistojen sisäiseen toteutustapaan. Tarkastellaan seuraavaksi tätä tarkastelevaa ohjelmistoarkkitehtuurin näkökulmaa. 3.3 Ohjelmistoarkkitehtuuri Kokonaisarkkitehtuurin todettiin edellä organisaation rakennetta ja ominaisuuksia tie- tyistä näkökulmista tarkastelevaa kuvausta, eli yksinkertaistettua mallia organisaation 45 eri piirteistä. Samoin ohjelmiston arkkitehtuurin voidaan katsoa olevan yksinkertaistettu malli ohjelmistosta (Koskimies & Mikkonen, 2005). Perusluonteeltaan monimutkaisten, näkymättömien ja vaikeasti hahmotettavien ohjelmistojen tarkastelu arkkitehtuurin kei- noin auttaa erottamaan niiden keskeiset piirteet lukemattomien yksityiskohtien joukosta – näkemään metsän puilta. Ohjelmiston arkkitehtuuria voidaan haluta esittää eri käyttötarkoituksia varten erilaisilla tarkkuustasoilla, erilaisista näkökulmista ja erityyppisinä kuvauksina. Mallilla voidaan haluta tarkastella esimerkiksi millaisiin osiin ohjelmiston lähdekoodi on jaettu (staatti- nen kuvaus) tai miten se käyttäytyy suorituksen aikana (dynaaminen kuvaus). Ohjelmis- ton kehittäjät saattavat haluta tietää millaisista osista järjestelmä koostuu (looginen nä- kymä) tai miten järjestelmän eri osat sijoitetaan toimimaan useammalle tietokoneelle (fyysinen näkymä). (Koskimies & Mikkonen 2005, s. 35–38.) Taylorin, Medvidovicin ja Dashofyn (2010, s. 58) esittämän määritelmän mukaan ohjel- mistojärjestelmän arkkitehtuuri on tärkeimpien järjestelmään kohdistuneiden suunnitte- lupäätösten joukko11. Nämä suunnittelupäätökset voivat liittyä mihin tahansa järjestel- män piirteeseen, kuten järjestelmän osien väliseen rakenteeseen, sen suorituksenaikai- seen toimintaan, osien väliseen vuorovaikutustapaan, järjestelmän ei-toiminnallisiin ominaisuuksiin tai järjestelmän tekniseen toteutustapaan. Edellä esitettyjen kuvausten perusteella ohjelmistoarkkitehtuurin voidaan katsoa tar- koittavan ohjelmiston ominaisuuksiin liittyviä tärkeimpiä periaatteita. Nämä periaatteet muodostuvat järjestelmän suunnittelussa tehtyjen päätösten tuloksena ja ne ohjaavat jär- jestelmän kehittymistä koko sen elinkaaren ajan. Ohjelmistoarkkitehtuuriin voidaan eri- laisia arkkitehtuuriin liittyviä käsitteitä tarkasteltaessa viitata myös konkreettisena ark- kitehtuurina, sillä se kuvaa jonkin yksittäisen konkreettisen ohjelmiston arkkitehtuuria. Ohjelmiston toteutukseen liittyviä periaatteita ja suunnittelupäätöksiä kuvattaessa on tarkoituksenmukaista käyttää yleisesti tunnettuja kuvausmenetelmiä ja käsitteitä. Yksi- käsitteistä ja täsmällistä arkkitehtuurin kuvauskieltä (engl. architecture description language, lyh. ADL) käytettäessä ohjelmistoarkkitehtuuri voidaan esittää mahdollisim- man yksiselitteisesti ilman luonnollisesta kielestä aiheutuvia väärinkäsityksiä ja moni- tulkinnallisuuksia. 11 ”A software system’s architecture is the set of principal design decisions made about the system.” 46 Jos arkkitehtuurilla kuvataan konkreettisen toteuttavan tai jo toteutetun ohjelmiston piir- teitä, meta-arkkitehtuurilla tarkoitetaan itse arkkitehtuurikuvauksen kuvausta – arkki- tehtuurin arkkitehtuuria. Koskimies ja Mikkonen (2005, s. 33) esittävät meta-arkkiteh- tuurin kuvaavan ”käsitteistön ja mekanismit, joilla varsinaisia arkkitehtuurikuvauksia annetaan”. Meta-arkkitehtuuri voidaan katsoa tällöin tietyn aihepiirin arkkitehtuurien kuvaamiseen soveltuvaksi laajennukseksi arkkitehtuurin kuvauskielelle. Toisaalta jos arkkitehtuurin määritellään tarkoittavan tärkeimpiä ohjelmistoa koskevia suunnittelu- päätöksiä, voidaan meta-arkkitehtuuri ajatella laajemmin varsinaista arkkitehtuuria kos- kevina keskeisinä päätöksinä. Referenssiarkkitehtuuri eroaa meta-arkkitehtuurista kuvaamalla ratkaisun tietynlaisten ohjelmistojen toteuttamiseksi. Siinä missä meta-arkkitehtuuri kuvaa arkkitehtuuria, ku- vaa referenssiarkkitehtuuri monistettavaa ratkaisutapaa. Taylor ym. (2010, s. 58) määrit- televät referenssiarkkitehtuurin joukoksi tärkeimpiä suunnittelupäätöksiä, jotka ovat sa- manaikaisesti sovellettavissa useisiin toisiinsa liittyviin järjestelmiin. Näiden järjestel- mien Taylor ym. (2010) toteavat olevan tyypillisesti saman sovellusalueen järjestel- miä12. Arkkitehtuurityyli on referenssiarkkitehtuuria väljempään kohdealueeseen sovellettava arkkitehtuuri. Taylor ym. (2010, s. 73) määrittelevät arkkitehtuurityylin nimetyksi koko- elmaksi arkkitehtuurillisia suunnittelupäätöksiä, jotka ovat sovellettavissa annetussa ke- hityskontekstissa, rajoittavat kontekstin puitteissa suunniteltavan järjestelmän arkkiteh- tuurillisia suunnittelupäätöksiä ja tuottavat hyödyllisiä ominaisuuksia tuotettuihin järjes- telmiin.13 Seuraavassa luvussa tullaan tarkastelemaan kolmea erilaista – monoliittista, palvelukes- keistä ja mikropalveluihin perustuvaa – arkkitehtuurityyliä. 12 ”A reference architecture is the set of principal design decisions that are simultaneously applicable to multiple related systems, typically within an application domain, with explicitly defined points of varia- tion.” 13 ”An architectural style is a named collection of architectural design decisions that (1) applicable in a given development context, (2) constrain architectural design decisions that are specific to a particular system within that context and (3) elicit beneficial qualities in each resulting system.” 47 3.4 Yhteenveto luvusta Tässä luvussa tarkasteltiin kokonaisarkkitehtuurin ja ohjelmistoarkkitehtuurin käsitteitä. Luvun alussa tarkasteltiin lyhyesti sekä yleistä arkkitehtuurin määritelmää sekä koko- naisarkkitehtuurin käsitettä. Kokonaisarkkitehtuurille todettiin olevan tunnusomaista laaja katsantokanta, joka yltää toimintaprosesseista ja niitä tukevien tietojärjestelmien tekniseen toteutukseen asti. Kuvauksen kohdealueena voi olla useista organisaatioista muodostuva kokonaisuus, yksittäinen organisaatio tai sen osa. Kokonaisarkkitehtuuria voidaan näin ollen ajatella yhtenä menetelmänä strategisen yhdenmukaisuuden saavutta- miseen, eli organisaation ulkoisen toimintaympäristön ja sisäisen toiminnan sekä toi- saalta (liike-)toiminnan ja sitä tukevan informaatioteknologian yhdenmukaisiksi saatta- miseen. Kokonaisarkkitehtuuria todettiin voitavan tarkastella kilpailuetua tuottavana menetel- mänä, jolla luodaan organisaation toimintamallia (engl. operating model) toteuttava ydinprosessien ja niitä tukevien keskeisten järjestelmien muodostama toiminnan pe- rusta. Kokonaisarkkitehtuurilla saavutettaviksi hyödyiksi tunnistettiin kasvaneet mitta- kaavaedut, parantunut yhteensopivuus ja integrointi, lisääntynyt uudelleenkäytettävyys, lisääntynyt standardointi, alentuneet kustannukset ja lyhentyneet prosessin läpimenoajat sekä kehittyvä kokonaisarkkitehtuurin hallinta, parantunut päätöksenteko, ja kokonais- kuvan muodostuminen organisaatiosta. Kokonaisarkkitehtuurin tarpeen ja sillä saavutettavien hyötyjen tarkastelusta siirryttiin esittämään yksityiskohtaisemmin kokonaisarkkitehtuurin sisältöä. Sisältöä tarkasteltiin erityisesti julkishallinnolle suunnatun JHS 179 -viitekehyksen kautta. Viitekehyksen to- dettiin määrittelevän mm. arkkitehtuurisisältöjen ja -kuvausten mallit sekä arkkitehtuu- rityön etenemistä kuvaavan mallin. Erityistä huomiota kiinnitettiin viitekehykseen sisäl- tyviin toiminta-, tieto-, tietojärjestelmä- ja teknologia-arkkitehtuurin näkökulmiin. Ko- konaisarkkitehtuurin tarkastelun jälkeen esitettiin vielä ohjelmistoarkkitehtuuriin liitty- viä käsitteitä. 48 4 Mikropalveluarkkitehtuuri Tähän mennessä työssä on tarkasteltu liiketoiminnan ja informaatioteknologian yhden- mukaisuuteen liittyviä kysymyksiä, esitetty yhdenmukaisuutta tukeva bimodaalisen IT- toiminnon malli, sekä tarkasteltu kokonaisarkkitehtuuria organisaation strategian, pro- sessit ja tietojärjestelmät yhdistävänä menetelmänä. Tässä viimeisessä teorialuvussa esi- tetään keskeisiä piirteitä mikropalveluarkkitehtuurista, jonka soveltuvuutta digitaalisen ja perinteisen IT-toiminnon yhtenäistämiseen työssä arvioidaan. Arkkitehtuurityyli pyri- tään esittämään tarkkuustasolla, joka mahdollistaa tämän. 4.1 Mikropalveluarkkitehtuuri osana arkkitehtuurityylien jatkumoa Mikropalveluarkkitehtuuri esitetään usein seuraavassa kohdassa käsiteltävän monoliitti- sen arkkitehtuurin vastakohtana, ja toisaalta vaihtoehtoisena toteutustapana tai seuraa- vana kehitysaskeleena palvelukeskeiselle arkkitehtuurille (engl. service-oriented archi- tecture, lyh. SOA). Näitä kolmea arkkitehtuurityyliä voidaankin tarkastella kuvan 15 mukaisena jatkumona, jossa monoliittinen, palvelukeskeinen ja mikropalveluista koos- tuva toteutustapa asettuvat niin niiden yleistymisajankohdan, moduulien välisten riippu- vuuksien vahvuuden kuin toteutettavien ohjelmistomoduulien koon mukaiseen järjes- tykseen. Kuva 15. Monoliittinen sovellus, palvelukeskeinen arkkitehtuuri ja mikropalveluarkkitehtuuri jatkumona.. Eri arkkitehtuurityylien tarkastelu auttaa hahmottamaan, millaisia aiemman arkkitehtuu- rityylin haasteita sekä palvelukeskeisellä arkkitehtuurilla että mikropalveluilla on py- 49 ritty ratkaisemaan. Toisaalta on jatkumon eri kohtia tarkasteltaessa huomattava, että ark- kitehtuurityylit eivät ole korvanneet toisiaan siten, että palvelukeskeinen arkkitehtuuri tai mikropalvelut olisivat tehneet monoliittisen toteutustavan yleisesti vanhentuneeksi tai epätarkoituksenmukaiseksi. Siksi kaikkien kolmen tyylin tarkastelu auttaa työhön si- sältyvässä tapaustutkimuksessa tunnistamaan tarkoituksenmukaiset käyttökohteet kulle- kin tavalle toteuttaa sovelluksia. Luvun alussa tarkastellaan monoliittista arkkitehtuuria ja siihen liittyviä haasteita. Sa- massa yhteydessä tarkastellaan jo myös työn pääasiallisena aiheena olevaa mikropalve- luarkkitehtuuria niiltä osin, kuin se vastaa esitettyihin haasteisiin. Monoliittisen arkkitehtuurin jälkeen siirrytään tarkastelemaan palvelukeskeistä arkkiteh- tuuria, siihen liittyviä käsitteitä ja sen soveltamisessa noudatettavia suunnitteluperiaat- teita, jotka pätevät myös mikropalvelujen suunnittelussa. Lisäksi tarkastellaan lyhyesti palvelukeskeiselle arkkitehtuurille vakiintuneita teknisiä toteutustapoja. Palvelukeskei- sestä arkkitehtuurista siirrytään tarkastelemaan lopulta tarkastelemaan lähemmin mikro- palveluarkkitehtuuria ja sen yksityiskohtaisempia toteutustapoja. 4.2 Monoliittiset sovellukset mikropalvelujen vastakohtana Mikropalveluarkkitehtuuria koskevan tarkastelun aluksi on aiheellista tarkastella ohjel- mistoihin liittyviä haasteita, joita mikropalveluarkkitehtuurilla on pyritty ratkaisemaan. Mikropalveluihin perustuva ohjelmistoarkkitehtuuri esitetään kirjallisuudessa tyypilli- sesti vastakohtansa, monoliittisen arkkitehtuurin, kautta tarkasteltuna.14 Monoliittista arkkitehtuuria noudattavat ohjelmistot ovat kokonaisuudessaan toteutettuja yhdeksi käyttöjärjestelmän prosessissa suoritettavaksi ohjelmaksi. Vaikka tällaiset ohjelmistot koostuvat tyypillisesti useista toisistaan loogisesti erillisistä moduuleista, kaikki niiden moduulit sisältyvät samaan ohjelmaan, eikä niitä voida suorittaa erillisesti toisistaan. Esimerkiksi verkkosovellusten perinteinen monoliittinen toteutustapa perustuu kuvan 16 mukaisesti palvelimella suoritettavaan sovellukseen, joka huolehtii niin selaimella suo- ritettavan käyttöliittymän muodostamisesta ja lähettämisestä käyttäjälle, käyttöliitty- mästä tehtävien palvelukutsujen käsittelystä, liiketoimintalogiikasta kuin tyypillisesti 14 Monoliittista arkkitehtuuria mikropalvelujen vastakohtana käsitelevät esimerkiksi Lewis ja Fowler (2014), Dragoni ym. (2017) ja Strîmbei ym. (2015). 50 tietokantaan tallennettujen sovelluksen tietojen muokkaamisesta. Merkittävä osa sovel- luksesta koostuu tyypillisesti jostakin sovelluksen toteutuksen pohjaksi valitusta ohjel- mistokehyksestä, joka sisältää verkkosovelluksille yhteisiä toistuvia piirteitä, kuten se- laimelta tulevien HTTP-pyyntöjen käsittelyn ja niihin vastaamisen tai selaimessa esitet- tävän HTML-sivun muodostamisen. Monoliittisessa toteutustavassa myös kaikki sovellukseen sisältyvä liiketoimintaa tu- keva toiminnallisuus on toteutettu tähän samaan sovellukseen. Esimerkiksi tuntikirjan- pitojärjestelmä voisi sisältää sekä työntekijöille tarkoitetun tehtyjen työtuntien syöttötoi- minnallisuuden että syötettyihin tietoihin perustuvan palkanlaskentatoiminnallisuuden. Kuva 16. Monoliittinen ja mikropalveluihin perustuva verkkosovellus. Keskeisinä haasteina monoliittisessa toteutustavassa voidaan Lewisin ja Fowlerin (2014) esittämän mukaisesti pitää ainakin · laajoihin ohjelmistoihin muodostuvaa monimutkaisuutta, joka aiheuttaa sovel- luksen elinkaaren aikana ongelmia sen jatkokehityksessä ja ylläpidossa, · sovelluksen pitkäkestoisesta kääntämisestä ja asennuksesta aiheutuvaa ohjelmis- tokehityksen ja -testauksen hidastumista, · sovelluksen suorituskyvyn kasvattamista sen käytön lisääntyessä, sekä 51 · sovellusten toteutuksessa käytettävien ohjelmointikielten sekä ohjelmistokehys- ten ja -kirjastojen valinnan rajoittumista. Tarkastellaan seuraavassa lähemmin näitä haasteita, ja esitetään, miten mikropalveluihin perustuva toteutustapa vastaa niihin. Tarkasteltaessa monoliittisille sovelluksille monimutkaisuudesta aiheutuvia haasteita, on aiheellista todeta, että monoliittiset sovellukset voivat rakentua hyvin rajatuista mo- duuleista, noudattaa tarkoituksenmukaista ohjelmistoarkkitehtuuria ja säilyä ylläpidettä- vinä koko elinkaarensa ajan. Ohjelmistokehityksessä on jo kymmeniä vuosia sitten tun- nistettu tarve koostaa laajat ohjelmistot moduuleista, jotka ovat keskenään vuorovaiku- tuksessa rajapintojen kautta. Koskimies ja Mikkonen (2005) esittävät rajapinnan väli- neeksi erottaa toisistaan se, mitä halutaan saada aikaiseksi ja miten tämä saavutetaan. Rajapinta antaa moduulin käyttäjälle ne tiedot, joita hänen tulee sitä käyttäessään tietää. Moduulin sisäinen toteutustapa taas määrää sen, miten rajapinnassa kuvattu toiminnalli- suus toteutuu. Kun ohjelmiston moduuli käyttää toista moduulia, muodostuu niiden vä- lille riippuvuus. Rajapinnan käytön voidaan katsoa heikentävän tätä riippuvuutta, koska käytetyn moduulin sisäisen toteutustavan muutokset eivät vaikuta sitä hyödyntäviin mo- duuleihin. Ohjelmistoarkkitehtuurissa pyritään yleensä vähentämään ohjelmiston eri osien välisiä riippuvuuksia, sillä ne hankaloittavat muun muassa ohjelmiston ylläpidet- tävyyden, sen osien uudelleenkäytettävyyden ja kehitystyön hajauttamisen kaltaisia ta- voitteita (Koskimies & Mikkonen 2005). Edellä todetusti hyvä ohjelmistoarkkitehtuurin suunnittelu mahdollistaa riippuvuuksien vähentämisen myös monoliittisten sovellusten osien välillä. Koska moduulit suoritetaan kuitenkin samassa käyttöjärjestelmän prosessissa, ovat ne väistämättä melko vahvassa sidoksessa keskenään. Toisaalta saman prosessin sisällä toimimisesta on myös hyötynsä – esimerkiksi prosessin sisällä moduulista toiseen tehty proseduurikutsu on kertaluok- kaa nopeampi kuin toiseen mikropalveluun HTTP-pyyntönä tehty kutsu (kuva 17). 52 Kuva 17. Moduulien välinen vuorovaikutus monoliittisessa ja mikropalveluista koostuvassa so- velluksessa. Käytännössä monoliittisille ohjelmistoille suunnitellun ohjelmistoarkkitehtuurin ja mo- dulaarisen rakenteen ylläpito osoittautuu usein haastavaksi ohjelmiston elinkaaren ai- kana. Ohjelmistoon kohdistuvat vaatimukset voivat esimerkiksi elinkaaren aikana muut- tua siten, että ohjelmistolle alun perin suunniteltu arkkitehtuuri ei tue niitä. Ohjelmistoa kehittävät henkilöt voivat vaihtua useita kertoja ohjelmiston elinkaaren aikana, ja siihen toteutettavat uudet ominaisuudet voidaan toteuttaa alkuperäisen arkkitehtuurin vastai- sesti. Toisin sanoen ohjelmistolle suunniteltu arkkitehtuuri ja rakenne voivat ajan kulu- essa päästä rapautumaan useista eri syistä. Martin (2003) esittää tunnusmerkkejä, jotka kertovat ohjelmiston elinkaaren aikana ta- pahtuvasta ohjelmiston rakenteen rapautumisesta – ohjelmistoon tehdyt muutokset vaa- tivat lisää muutoksia ohjelmiston eri osiin ja toisaalta aikaansaavat virhetilanteita vaike- asti ennakoitavissa paikoissa ohjelmistossa, ohjelmistosta on vaikeaa eriyttää muualla uudelleenkäytettäviä osia, se sisältää tarpeetonta monimutkaisuutta ja turhaan toistuvia rakenteita ja sen toimintaa on vaikeaa hahmottaa sen lähdekoodia tarkastelemalla. Huo- nosti rakentunut ohjelmisto myös houkuttelee muutostilanteissa arkkitehtuurin vastaisiin ratkaisuihin, jotka entisestään huonontavat ohjelmiston rakennetta. Mikropalveluihin perustuvassa toteutustavassa yksittäisten palvelujen rakenteen voi- daan ajatella säilyvän niin yksinkertaisena, että sen sisäinen toteutustapa on helpommin ymmärrettävissä ja hallittavissa. Moduulien erottaminen toisistaan eri sovelluspalveli- 53 milla toimiviin mikropalveluihin myös pakottaa käyttämään niitä suunnitellusti rajapin- toja hyödyntäen ja auttaa siten säilyttämään sovellukselle suunniteltua arkkitehtuuria. Toisaalta mikropalveluihin perustuva toteutustapa luo monoliittiseen toteutukseen ver- rattuna uudenlaista monimutkaisuutta, jota tarkastellaan edempänä. Toinen käytännönläheinen haaste monoliittisesti toteutettujen ohjelmistojen kehittämi- sessä on, että sovellukseen tehtyjen muutosten testaus ja käyttöönotto vaativat tyypilli- sesti koko sovelluksen kääntämisen, asentamisen ja uudelleenkäynnistämisen. Vaikka muutos tehtäisiin vain yhteen sovelluksen useista moduuleista, sen testaaminen ja käyt- töönotto voi kestää käytännössä yhtä pitkään kuin laajempien, useita moduuleja koske- vien muutosten tekeminen. Mikropalveluina kehitettävän sovelluksen eri moduuleja voidaan kehittää, testata ja päi- vittää toisistaan riippumattomasti. Kun mikropalvelun kehitystyö organisoidaan siten, että kehittäjätiimit työskentelevät yksittäisen mikropalvelun parissa (esimerkiksi tunti- kirjauspalvelu) monoliittisen sovelluksen arkkitehtuurikerroksen sijasta (esimerkiksi da- takerros), saadaan palveluun tehdyt muutokset vietyä tuotantokäyttöön asti erittäin no- peasti. Mikropalvelujen ympärille organisoitumisen lisäksi tätä tavoitetta edesautetaan mikropalvelujen yhteydessä laajalti käytetyllä toistuvan työn automatisoinnilla. Edem- pänä tarkastellaan lähemmin mikropalvelujen kehittämisessä yleisesti käytettäviä väli- neitä ja menetelmiä. Kolmas edellä todettu monoliittisten sovellusten haaste liittyy niiden käsittelykapasitee- tin kasvattamiseen, eli niiden skaalautumiseen, sovelluksen käytön kasvaessa. Koska sovelluksen eri moduulit toimivat yhtenäisenä kokonaisuutena yhdessä käyttöjärjestel- män prosessissa, joudutaan suorituskykyä tyypillisesti kasvattamaan luomalla sovelluk- sesta useita ilmentymiä (engl. instance) toimimaan rinnakkain eri palvelimilla. Esimer- kiksi vuorovaikutteisen verkkosovelluksen tapauksessa sovellukselle eri käyttäjien se- lainkäyttöliittymistä tulevat pyynnöt ohjataan tällöin kuormanjakajan kautta näille rin- nakkain toimiville sovelluksen ilmentymille käsiteltäviksi. Mikropalveluina toteutettavassa sovelluksessa suorituskyvyn kasvattaminen voidaan tehdä edellä kuvattua tapaa täsmällisemmin. Kasvaneesta käytöstä aiheutuva suoritusky- vyn tarpeen kasvu voi kohdistua epätasaisesti sovelluksen eri moduuleihin, jolloin itse- näisinä mikropalveluina toteutettujen moduulien ilmentymiä voidaan tarpeen mukaan lisätä, luomatta samalla uusia tarpeettomia ilmentymiä muista moduuleista. 54 Neljäs ja viimeinen edellä tunnistettu haaste monoliittisten sovellusten toteutuksessa on, että samaan sovellukseen toteutettavat moduulit tulee ja kannattaa tyypillisesti toteuttaa samalla ohjelmointikielellä ja hyödyntäen samoja ohjelmistokehyksiä. Koska moduulit käännetään yhdeksi käyttöjärjestelmän suorittamaksi ohjelmaksi, tulee niiden tyypilli- sesti olla toteutettu samalla kääntäjän ymmärtämällä ohjelmointikielellä, joitakin poik- keuksia (esimerkiksi suorituksen aikaisesti tulkattavia sovelluksen osia) lukuun otta- matta. Samaan haasteeseen liittyvät myös monoliittisen ohjelmiston moduulien yhteiset riippu- vuudet ohjelmistokirjastoihin. Sovellusta varten toteutettavat moduulit käyttävät yleensä valmiita ohjelmistokirjastoja osana toimintaansa. Esimerkiksi palkanlaskusovellus voisi hyödyntää valmista ohjelmistokirjastoa, johon on toteutettu rahasummilla tehtävään las- kentaan liittyviä tietorakenteita ja proseduureja. Kun useat moduulit käyttävät samaa kirjastoa, voi aiheutua tilanteita, joissa ohjelmistokirjaston päivittäminen uuteen versi- oon auttaa korjaamaan ongelman toisessa moduulissa, mutta rikkoo aiemmin toimineen toisen moduulin. Ohjelmiston moduulien toteuttaminen itsenäisissä mikropalveluissa mahdollistaa tarkoi- tuksenmukaisten ohjelmointikielten sekä ohjelmistokehysten ja -kirjastojen vapaamman tapauskohtaisen valinnan. Yksittäisen mikropalvelun toteutukseen voidaan tällöin valita esimerkiksi palvelua kehittävän tiimin osaamista vastaava tai tietynlaisten ongelmien ratkomiseen hyvin soveltuva ohjelmointikieli. Käytettävät ohjelmistokehykset ja -kirjas- tot eivät muodostu riippuvuudeksi muille moduuleille, joten myös niiden valinta ja ver- siointi koskevat vain yksittäistä mikropalvelua. Monoliittisten sovellusten haasteiden tarkastelu on aiheellista päättää toteamalla mikro- palveluihin perustuvan toteutustavan aiheuttavan omanlaisiaan haasteita, joita tarkastel- laan edempänä. 4.3 Palvelukeskeinen arkkitehtuuri mikropalvelujen edeltäjänä Tarkastellaan seuraavaksi, millaisia arkkitehtuureja voidaan luonnehtia palvelukeskei- siksi. Tarkastelun aluksi esitetään palvelukeskeiseen arkkitehtuuriin liittyviä keskeisim- piä käsitteitä. Tämän jälkeen kuvataan palvelukeskeisessä arkkitehtuurissa noudatettavia suunnittelun periaatteita. 55 4.3.1 Palvelukeskeisen arkkitehtuurin käsitteitä Palvelukeskeisen arkkitehtuurin (kuten myöhemmin esiteltävän mikropalveluarkkiteh- tuurinkin) lähtökohtana on niin toiminnan kuin ohjelmistojenkin jakaminen itsenäisiin palveluihin. Palvelulle on palvelukeskeisen arkkitehtuurin yhteydessä esitetty useita keskenään sa- mansuuntaisia määritelmiä. The Open Group (2007) esittää palvelun olevan toistettavan ja määritellyn tuotoksen tuottavan liiketoiminnan aktiviteetin looginen esitys. Tällainen aktiviteetti voi olla esimerkiksi asiakkaan luottoluokituksen tarkastaminen tai säätiedon toimittaminen. Erlin (2008) mukaan palvelua voidaan ajatella toisiinsa liittyvien kyvyk- kyyksien kokoelmana. Näin ajateltuna palvelu koostuu nämä kyvykkyydet toteuttavasta sisäisestä logiikasta ja palvelun käyttäjälle esitetystä kuvauksesta tai sopimuksesta pal- velun hyödyntämiseksi. Palvelulle valitusta täsmällisestä määritelmästä riippumatta palveluille on keskeistä, että niiden käyttäjien ei tarvitse tuntea palvelun sisäistä rakennetta tai toteutustapaa, vaan he voivat käyttää palvelua siitä annetun kuvauksen – palvelun rajapinnan – perusteella. Rajapinta voi arkkitehtuurikuvauksen tasosta riippuen tarkoittaa loogista kuvausta, jonka perusteella asiakas voi esimerkiksi käyttää palveluntarjoajan palvelua (liiketoi- minta-arkkitehtuuri) tai teknisen rajapinnan täsmälliseen kuvauskieleen perustuvaa mää- rittelyä (järjestelmäarkkitehtuuri). Yhteistä rajapinnan käsitteelle tarkastelutasosta riip- pumatta on, että se kuvaa palvelua sen käyttäjän näkökulmasta palvelun, ja piilottaa pal- velun sisäisen toteutustavan. Koska palvelun toteutustapa ei näy sen käyttäjälle, voidaan useista palveluista koostaa palvelujen kompositio, joka näyttäytyy käyttäjälleen yhtenä rajapintana, mutta käyttää rajapinnassa kuvatun toiminnallisuuden toteuttamiseen koordinoidusti useita yksityis- kohtaisempia palveluja. Esimerkiksi tilauksen käsittely -palvelu voisi koostua toimintaa koordinoivasta logiikasta, joka muun muassa tarkastaa tuotteen varastotilanteen yhdestä palvelusta ja tarkastaa oletetun toimitusajan toiselta palvelulta. Palvelun käsitteen laajuudesta johtuen tässä työssä pyritään sekaannusten välttämiseksi tarvittaessa kutsumaan palveluja joko liiketoiminnan palveluiksi tai teknisiksi palve- luiksi. Liiketoiminnan palvelut ovat lähempänä arkielämän käsitystä palvelusta, jossa asiakas käyttää palveluntuottajan tarjoamaa palvelua tuntematta välttämättä sen toteu- tustavan yksityiskohtia. Tekniset palvelut taas ymmärretään Legnerin ja Heutschin 56 (2007) esittämän määritelmän mukaisesti ohjelmistojen toisille sovelluksille tarjoamana vakaana ja uudelleenkäytettävänä, liiketoiminnan tarkkuustasolla ja laajalti käytetyillä standardeilla esitettynä toiminnallisuutena.15 Yleisellä tasolla palveluista puhuttaessa tai asiayhteyden tehdessä täsmällisemmän merkityksen selväksi puhutaan näiden sijasta vain palveluista. 4.3.2 Palvelukeskeisen arkkitehtuurin suunnitteluperiaatteita Palvelukeskeiseen arkkitehtuuriin liittyvien käsitteiden ohella keskeinen tapa määritellä arkkitehtuurityyliä on siihen sisältyvien suunnitteluperiaatteiden tunnistaminen. Tarkas- tellaan seuraavaksi palvelukeskeiseen arkkitehtuuriin sisältyviä suunnitteluperiaatteita Erlin (2008) esittämän mukaisesti. On huomionarvoista, että periaatteet liittyvät usein vahvasti toisiinsa ja niiden noudatta- minen tukee toisten periaatteiden toteutumista. Standardoidun palvelusopimuksen, löy- hien sidosten, abstrahoinnin ja palvelujen löydettävyyden voidaan katsoa liittyvän eri- tyisesti palvelusopimuksen muodostamiseen, kun taas loppujen esitettävistä periaatteista voidaan katsoa liittyvän myös palvelun sisäiseen toteutustapaan. Standardoitu palvelusopimus (engl. standardized service contract). Palvelun ja palve- lurajapinnan määrittelyn yhteydessä todettiin, että palvelujen käyttäjille julkaistaan nii- den käyttöä koskeva sopimus, jonka avulla palvelun toteutustapaa ei tarvitse sitä käytet- täessä tuntea. Erl (2008, s. 71) toteaa näiden sopimusten yhdenmukaisuuden olevan kenties tärkein palvelukeskeisen suunnittelun periaate. Liiketoiminta-arkkitehtuuria tarkasteltaessa nämä kuvaukset vastaavat suurelta osin ar- kikielen sopimuksen käsitettä – ne määrittävät esimerkiksi vastuut ja palvelutasot palve- luntarjoajan palvelua käytettäessä. Järjestelmäarkkitehtuuritasolla ”palvelusopimukset” ovat tyypillisesti palvelun eri rajapintojen kuvauksia. Näiden kuvausten standardointi sekä mahdollistaa palvelujen paremman yhteentoimivuuden että tekee palvelujen tarkoi- tuksen ja kyvykkyyksien ymmärtämisestä helpompaa. Palvelujen löyhät sidokset (engl. service loose coupling). Palvelujen löyhillä sidoksilla tarkoitetaan, että palveluja ei suunnitella toisistaan vahvasti riippuvaisiksi. Sidoksella 15 ”Services represent abstract software elements and/or interfaces which provide other applications with stable, reusable software functionality at an application-oriented, business-related level of granularity using widely applied standards.”(Legner & Heutsch 2007) 57 tarkoitetaan mitä yhteyttä kahden palvelun välillä. Esimerkiksi edellä kuvatulle tilausten käsittely -palvelulle muodostuisi sidos varastotilanne- ja toimitusaikapalveluihin. Sidos- ten löyhyys tai tiukkuus taas määräytyy sen perusteella, kuinka paljon keskenään sidok- sissa olevat palvelut tietävät toisistaan. Palvelujen abstrahointi (engl. service abstraction). Palvelujen abstrahointi liittyy lä- heisesti palvelun jakamiseen sisäiseen toteutukseen ja ulospäin näkyvään palvelusopi- mukseen. Abstrahoinnilla tarkoitetaan, että palvelun käyttäjille esitetään palvelusta ai- noastaan ne tiedot, joita palvelun käyttämiseen tarvitaan. Esimerkiksi mitä enemmän eri tietoja palvelun palvelusopimuksessa julkaistaan, sitä vahvemmiksi muodostuvat sidok- set palvelun ja sen käyttäjien välille. Palvelujen uudelleenkäytettävyys (engl. service reusability). Liiketoiminnan näkökul- masta tarkasteltuna palvelujen uudelleenkäytettävyys mahdollistaa liiketoiminnan akti- viteettia tukevan teknisen palvelun käytön osana useita liiketoimintaprosesseja. Uudel- leenkäytettävät palvelut voivat sisältää liiketoiminnan toimintalogiikkaa, mutta soveltua silti käytettäviksi osana useampaa liiketoimintaprosessia. Toisten uudelleenkäytettävien palvelujen kyvykkyydet voivat taas olla niin yleisluontoisia, että niitä voidaan käyttää missä liiketoimintaprosessissa tahansa. Palvelujen autonomisuus (engl. service autonomy). Autonomiset palvelut pystyvät suorittamaan toimintalogiikkaansa itsenäisesti, niiden ympäristössä tapahtuvista muu- toksista riippumatta. Palvelun autonomiaa voidaan tarkastella sekä suorituksen että suunnittelun aikaisena. Suosituksen aikainen autonomia tarkoittaa, että palvelu toimii itsenäisesti ajonaikaiseen suoritusympäristöönsä nähden. Suunnittelun aikainen autono- mia tarkoittaa, että palvelun omistaja voi muuttaa palvelua itsenäisesti. Palvelujen tilattomuus (engl. service statelesness). Palvelujen toteuttaminen mahdolli- simman vähän tilatietoa sisältäviksi tukee palvelujen autonomisuutta ympäristöönsä nähden ja vähentää sen resurssienkulutusta. Erl (2008, s. 336) tunnistaa kolme eri tila- tiedon tyyppiä: sessio-, konteksti- ja liiketoimintadatan. Sessiodatalla tarkoitetaan usean palvelukutsun yhdistävän tunnistetiedon säilyttämistä palvelussa. Tällöin palvelukutsun käsittelyn yhteydessä voidaan kutsussa välitetyn ja palveluun tallennetun tunnistetiedon avulla yhdistää käsiteltävä kutsu aiempiin palvelun käyttäjän tekemiin kutsuihin. Koos- tettujen palvelujen yhteydessä voi olla tarpeellista ylläpitää sessiodatan lisäksi myös kontekstidataa, joka auttaa koordinoimaan palvelujen kutsumista. Liiketoimintadata liit- tyy liiketoiminnan aktiviteettiin, jota palvelu tukee. 58 Palvelujen löydettävyys (engl. service discoverability). Palvelujen löydettävyyteen py- ritään kuvaamalla palvelujen metatiedoilla, jotka mahdollistavat sekä ihmisten että so- vellusten tekemän tulkitsemisen. Tulkinnan mahdollistamisen voidaan katsoa vaativan edellä kuvatun palvelusopimusten standardoinnin periaatteen noudattamista; yhdenmu- kaiset kuvaustavat helpottavat tulkintaa molemmissa tapauksissa. Palvelujen koostettavuus (engl. service composability). Palvelujen koostettavuus liit- tyy vahvasti keskeiseen palvelukeskeisestä arkkitehtuurilla tavoiteltavaan hyötyyn: uu- sien palvelujen toteuttamiseen aiemmin toteutettuja palveluja hyödyntäen. Palvelujen koostettavuus liittyy vahvasti palvelujen uudelleenkäytettävyyden periaattee- seen. Koostettavaksi soveltuvien palvelujen tulee olla uudelleenkäytettäviä, mutta tämän lisäksi Erl (2008) tunnistaa niille kaksi erityispiirrettä: koostettavat palvelut tarvitsevat erityisen tehokkaan suoritusympäristön ja palvelusopimuksen tulee olla joustava palve- lun käyttäjän ja palvelun välillä välitettävän datan muodosta. 4.3.3 Palvelukeskeisen arkkitehtuurin toteutustapoja Tarkastellaan seuraavaksi, millaisilla tuotteilla ja teknologioilla palvelukeskeiseen ark- kitehtuuriin perustuvia järjestelmiä tyypillisesti toteutetaan. Viestinvälitys. Kenties tyypillisin tapa palvelukeskeisen arkkitehtuurin palvelujen väliselle kommunikoinnille on SOAP-protokollan käyttö. SOAP määrittelee standardoidut muodot palveluille lähetettäville palvelukutsuille sekä niiltä saataville vastauksille. Standardoitujen viestien tarkoituksena on piilottaa palvelun sisäinen toteutustapa ja -teknologia, ja tehdä siten esimerkiksi eri ohjelmointikielillä toteutetut palvelut keskenään yhteensopiviksi. Toinen yleinen toteutustapa palvelurajapintojen toteutukselle ovat REST-rajapinnat16, joissa järjestelmän palvelut esitetään resursseina, joihin voidaan kohdistaa jokin HTTP-protokollan määrittämistä operaatioista. Palvelusopimusten kuvailu. SOAP-protokollaa noudattavia rajapintoja kuvataan tyy- pillisesti WSDL-kuvauskielellä17. Se esittää palvelun kutsumiseen tarvittavat tiedot – esimerkiksi palvelun kutsuttavat operaatiot sekä niiden vastaanottamat ja palauttamat tietotyypit. 16 Representational State Transfer 17 Web Services Definition Language 59 Palvelujen löytäminen. Palvelujen löytämiseen käytetty UDDI-standardi määrittelee, miten palveluja voidaan julkaista ja löytää. Edellä kuvatut standardit muodostavat yhtenäisen kokonaisuuden, joka mahdollistaa palvelun löytämisen ja sen käytön. UDDI-standardin mukaisen hakemiston käyttäjä voi esimerkiksi hakea hakemistosta palvelua tietyllä hakukriteerillä, vastaanottaa haulla löy- tyneen palvelun WSDL-kuvauksen, ja WSDL-kuvauksessa esitetyn rajapinnan mukai- sesti kutsua sitä SOAP-viestillä. Eräs luonteenomainen piirre palvelukeskeisen arkkitehtuurin toteutukselle on palvelu- väylien käyttö. Palveluväylät ovat ohjelmistoja, jotka välittävät, reitittävät ja muuntavat viestejä palvelujen välillä. Niiden käytöllä pyritään esimerkiksi välttämään suoria ohjel- mistojen välisiä integraatioita, joiden hallinnan ja toteutuksen voidaan ajatella muodos- tuvan haastavaksi palvelujen ja niiden välisten mahdollisten yhteyksien määrän kasva- essa. Palveluväylät voivat sisältää myös toiminnallisuuksia liiketoimintaprosessien kuvaami- seen ja suorittamiseen. Esimerkiksi BPEL-kuvauskielellä voidaan yksittäisiä palveluja koostaa osaksi liiketoimintaprosesseja, joissa palveluja kutsutaan prosessin tietyissä vai- heissa. Nämä prosessit voidaan julkaista palveluväylästä jälleen SOAP-protokollan mu- kaisina palveluina. Näin palveluväylään voi muodostua yksittäisten palvelujen lisäksi koosteisia palveluita, jotka yhdistelevät yksittäisiä palveluja halutun toiminnallisuuden aikaansaamiseksi. 4.3.4 Palvelukeskeisen arkkitehtuurin haasteita Palvelukeskeisen arkkitehtuurin käyttöönottoon ja soveltamiseen on tunnistettu liittyvän useita haasteita. Näistä osan voidaan katsoa liittyvän pohjimmiltaan palvelukeskeisen arkkitehtuuriin itseensä (esimerkiksi palvelujen oikean tarkkuustason valitseminen) ja osan sille vakiintuneisiin toteutustapoihin (esimerkiksi Web services -protokollien mo- nimutkaisuus). Tämän mikropalveluja käsittelevän työn puitteissa palvelukeskeisen ark- kitehtuurin periaatteisiin liittyvät haasteet voidaan katsoa kiinnostavammiksi, sillä ne oletettavasti koskevat myös mikropalveluarkkitehtuurin soveltamista. Näitä tunnistettuja haasteita käsitellään edellä mikropalvelujen yhteydessä. 60 4.4 Mikropalveluarkkitehtuuri Luvun alussa todetusti mikropalveluja voidaan pitää osana jatkumoa, jossa sekä sovel- luksen itsenäisten moduulien koko että niiden keskinäinen riippuvuus pienenevät. Mo- noliittisessa arkkitehtuurissa sovellus muodostaa yhden kokonaisuuden, jonka sisältä- mät moduulit ovat tiukasti sidoksissa toisiinsa. Palvelukeskeisessä arkkitehtuurissa si- dokset ovat tätä löyhempiä ja moduulit useisiin itsenäisiin palveluihin jaettuina. Mikropalveluarkkitehtuurissa sovelluksen toiminnallisuus on pilkottu yhä pienemmiksi kokonaisuuksiksi ja ne on toteutettu entistä vähemmän riippuvaisiksi toisistaan. Mikro- palveluihin toteutetut sovelluksen moduulit kutsuvat toisiaan yleensä ohjelmistokirjas- toille tyypillisten proseduurikutsujen sijasta tietoverkon ylitse. Koska ne toteutetaan toi- sistaan täysin itsenäisinä kokonaisuuksina, niissä käytetyt ohjelmointikielet sekä ohjel- mistokehykset ja -kirjastot voivat erota toisistaan. Lisäksi niiden suorituksena aikana moduuleja voidaan käynnistää, sammuttaa ja päivittää täysin itsenäisesti muihin palve- luihin toteutettuihin moduuleihin vaikuttamatta. Samoin kuin edellä palvelukeskeisen arkkitehtuurin tarkastelussa, on myös mikropalve- luja tarkoituksenmukaista tarkastella erikseen niiden suunnitteluperiaatteiden ja toisaalta niiden toteutuksessa tyypillisesti sovellettavien toteutustapojen osalta. Tarkastellaan aluksi, millaisia periaatteita mikropalvelujen suunnitteluun liittyy. 4.4.1 Mikropalveluarkkitehtuurin suunnitteluperiaatteita Edellä todettiin mikropalveluja voitavan tarkastella eräänä toteutustapana palvelukes- keiselle arkkitehtuurille. Tästä näkökulmasta tarkasteltuna mikropalveluarkkitehtuuri noudattaa aiemmin esitettyjä palvelukeskeisen arkkitehtuurin periaatteita – mikropalve- lut tyypillisesti toteuttavat standardoitua palvelusopimusta, niiden väliset sidokset ovat löyhiä, ne esitetään abstrahoidusti, ja ovat uudelleenkäytettäviä, autonomisia, tilattomia ja koostettavia, sekä ne voidaan toteuttaa keskitetyn palvelurekisterin kautta löydettä- viksi. Mikropalveluarkkitehtuurille ei ole esitetty yleisesti hyväksyttyä täsmällistä määritel- mää, joka auttaisi erottamaan sitä noudattavat arkkitehtuurit yksikäsitteisesti muista pal- velukeskeisistä arkkitehtuureista. Täsmällisen määritelmän puutteesta huolimatta voi- daan edellä kuvattujen yleisempien piirteiden lisäksi tunnistaa suunnitteluperiaatteita, 61 jotka ovat osin päällekkäisiä edellä kuvattujen periaatteiden kanssa, mutta koskevat eri- tyisesti mikropalvelujen suunnittelua. Yhden liiketoiminnan palvelun tukeminen. Keskeinen mikropalvelujen suunnitteluun vaikuttava piirre liittyy niiden nimen mukaisesti palvelun laajuuteen: mikropalvelut to- teutetaan pieninä, yhtä liiketoiminnan palvelua tukevina teknisinä palveluina. Ne toteut- tavat kuvan 18 mukaisesti yhden tarkasti rajatun liiketoiminnan käsitteistöllä määritel- lyn toiminnon ja sisältävät kaikki siihen tarvitsemansa tekniset toiminnallisuudet. (Le- wis & Fowler, 2014.) Kuva 18. Esimerkki mikropalvelun rakenteesta Korkea koheesio ja löyhät sidokset. Yhden liiketoiminnan palvelun tukeminen liittyy läheisesti mikropalveluilla tavoiteltuun yhden vastuun periaatteeseen. Yleisiä ohjelmis- tokehityksen hyviä käytäntöjä kuvaavassa kirjassaan Martin (2003) esittää, että moduu- lilla tulisi olla vain vastuu ja siten vain yksi syy muuttua. Mikäli mikropalvelulla on useita vastuita, voi yhteen sen yhteen tehtävään liittyvä muutos olla ristiriidassa sen toi- sen vastuun kanssa. Kun palvelulla on vain yksi vastuu, liittyvät kaikki sen osat saman toimintoon, eli niillä on korkea koheesio. Toisaalta tähän vastuuseen liittyvät muutokset eivät vaadi muutoksia muihin palveluihin, eli palvelujen väliset sidokset ovat löyhiä. Yksinkertainen vuorovaikutus. Korkean koheesion ja löyhien sidosten saavutta- miseksi mikropalvelujen välinen tiedonvälitys pyritään tyypillisesti toteuttamaan mah- dollisimman yksinkertaiseksi, säilyttäen palvelujen vuorovaikutukseen liittyvän liiketoi- 62 mintalogiikan palvelujen sisällä. Vastakohtana tälle ovat palvelukeskeisen arkkitehtuu- rin yhteydessä usein käytetyt toteutustavat, joissa palvelujen vuorovaikutuksen mahdol- listavat ohjelmistot sisältävät myös muun muassa liiketoimintalogiikkaa ja -sääntöjä, välitettävälle tiedolle tehtäviä muunnoksia sekä viestien reititykseen liittyvää toiminnal- lisuutta. (Lewis ja Fowler, 2014.) Yksinkertaisiin vuorovaikutusmekanismeihin pyrkimisen voidaan katsoa noudatettavan yhden vastuun periaatetta: vastuuta palvelujen välisestä tiedonvälityksestä, liiketoimin- tasääntöjen ylläpidosta ja suorittamisesta tai palvelujen yhteistoiminnan orkestroinnista jonkin laajemman liiketoiminnan tarvitseman toiminnon toteuttamiseksi ei sekoiteta keskenään. Hajautettu hallinnointi. Aiemmin todetusti mikropalvelut ovat toteutustavoiltaan var- sin itsenäisiä toisistaan, ja tekniset rajoitteet eivät estä niiden kehittäjiä valitsemasta va- paasti kunkin palvelun toteutukseen parhaiten soveltuvia ohjelmointikieliä ja ohjelmis- tokirjastoja. Lewisin ja Fowlerin (2014) mukaan mikropalveluihin perustuvassa ohjelmistokehityk- sessä pääpaino onkin etukäteen tehtävän, myöhempää suunnittelu- ja toteutustyötä oh- jaavan hallinnoinnin (engl. governance) sijasta hyödyllisten ja uudelleenkäytettävien ohjelmiston osien levittämisessä ja jakamisessa. Hajautettu tiedonhallinta. Mikropalvelut käyttävät toteuttamansa liiketoiminnan pal- velun käsitteitä ja ylläpitävät tyypillisesti siihen liittyviä tietoja omassa tietokannassaan. Ne siis toteuttavat käsittelemiensä tietojen pysyväistallennuksen (engl. persistence). Sa- moin kuin ohjelmointikielien ja ohjelmistokirjastojen osalta, tämä mahdollistaa kunkin palvelun tiedoille parhaiten soveltuvan, usein perinteisiä relaatiotietokantoja yksinker- taisemman tallennustavan valinnan. (Lewis & Fowler, 2014.) Useisiin palveluihin hajautettuun tiedonhallintaan liittyy väistämättä haasteita muun muassa transaktioiden käsittelyssä – mikäli esimerkiksi tilauksen toimitus ja maksu olisi toteutettu omiin palveluihinsa, tulee molempien toimenpiteiden onnistua tai molempien peruuntua. Perinteiset relaatiotietokannat tukevat tällaisten riippuvuuksien määrittelyä tietojen välille, mutta mikropalvelujen hajautetun tiedonhallinnan mallissa niiden val- vonta tulee toteuttaa esimerkiksi palveluja käyttävään sovellukseen tapauskohtaisesti (Lewis & Fowler, 2014). 63 Virheisiin varautuminen. Edellä kuvatusti mikropalveluarkkitehtuuri eroaa monoliitti- sista sovelluksista toteuttamalla sovelluksen moduulien toiminnallisuuden omina itse- näisinä palveluinaan. Käyttöjärjestelmän prosessin sisällä tapahtuvan proseduurikutsun sijasta moduulit kutsuvat toisiaan tällöin tyypillisesti verkkoyhteyden ylitse. Verkkoyh- teyden käyttö moduulien välisissä kutsuissa tarkoittaa, että mikä tahansa kutsu voi yh- teyden puuttumisen takia epäonnistua. Virhetilanteiden mahdollisuus vaatii palvelujen toteutuksessa sekä virhetilanteisiin va- rautumista ja niistä toipumista että palvelujen suorituksenaikaisen monitoroinnin mah- dollistamista. Palveluja tarkastellaan sekä teknisten virhetilanteiden ja suorituskyvyn (esimerkiksi kuinka monta pyyntöä järjestelmä käsittelee sekunnissa) että liiketoimin- nan mittarien osalta (esimerkiksi kuinka monta tilausta järjestelmä on vastaanottanut minuutissa). (Lewis ja Fowler, 2014.) 4.4.2 Mikropalveluarkkitehtuurin toteutustapoja Tarkastellaan seuraavaksi lyhyesti, miten ja millaisilla teknologioilla mikropalveluja tä- mänhetkisten käytäntöjen mukaan tyypillisesti toteutetaan. Liiketoiminnan ja informaa- tioteknologian yhdenmukaisuuden tarkkuustasolta alkaneen tarkastelun yhteydessä yk- sittäisten tuotteiden ja teknologioiden tasolle menevä esitys voi vaikuttaa turhan yksi- tyiskohtaiselta, mutta sen voidaan myös katsoa konkretisoivan mikropalvelujen toteu- tustapaa ja auttavan esimerkiksi kaupunkiorganisaatioon kohdistuvien osaamisvaati- musten arvioinnissa mikropalveluarkkitehtuuria sovellettaessa. Ohjelmistokehykset. Vaikka mikropalveluilla pyritään toteuttamaan yksi liiketoimin- nan tarvitsema selkeästi rajattu toiminto, vaaditaan niiltä usein keskenään hyvin saman- kaltaista toiminnallisuutta: palvelujen tulee esimerkiksi käsitellä vastaanottamiaan tietyn muotoisia viestejä, joiden käsittelyn perusteita ei kannata jokaiseen palveluun toteuttaa alusta alkaen. Mikropalvelujen toteuttamiseen ja rungoksi tarkoitettuja ohjelmistokehyksiä on toteu- tettu runsaasti eri ohjelmointikielille. Tyypillisesti ohjelmistokehykset sisältävät palve- linsovelluksen, joka suorittaa mikropalveluja, ja erilaisia valmiita toiminnallisuuksia esimerkiksi REST-rajapintojen toteuttamiseen, JSON-muotoisen tiedon käsittelyyn ja palvelun tilan mittaamiseen. 64 Esimerkkejä mikropalvelujen kehittämiseen tarkoitetuista ohjelmistokehyksistä ja työ- välineistä ovat Dropwizard ja Spring Boot, joista molemmat perustuvat Java-ohjelmoin- tikieleen. Kommunikointi. Sekä mikropalvelujen ja niitä käyttävien sovellusten välinen että mik- ropalvelujen keskinäinen kommunikointi voidaan toteuttaa useilla tavoilla. Mikropalve- lujen viestinnän yhteydessä käytettävät tuotteet ja menetelmät ovat tyypillisesti merkit- tävästi palvelukeskeisen arkkitehtuuria kevyempiä ja yksinkertaisempia. Suoraviivai- simpana toteutustapana palvelujen väliselle kommunikoinnille voidaan pitää suoria raja- pintakutsuja palvelusta toiseen. Kutsuttavien palvelujen osoitteet voivat olla tällöin osana kutsuvan palvelun asetuksia. Viestinvälitys voi perustua myös yksinkertaisiin, esimerkiksi RabbitMQ:n kaltaisiin viestinvälitysohjelmistoihin, joihin palvelut sekä lähettää viestejä että rekisteröityä tie- tynlaisten viestien vastaanottajiksi. Näitä viestinvälitystuotteita voidaan verrata palvelu- keskeisen arkkitehtuurin yhteydessä käytettäviin palveluväyliin, mutta ne ovat merkittä- västi yksinkertaisempia, ja sisältävät vähemmän organisaation (liike-)toimintaan liitty- vää logiikkaa. Palvelujen välinen kommunikointi voi olla synkronista tai asynkronista – synkronisessa viestinnässä viestin lähettäjä odottaa saavansa viestiin vastauksen, asynkronisessa vies- tinnässä viesti lähetetään odottamatta vastausta. Synkronisessa kommunikoinnissa ylei- sin tapa on toteuttaa HTTP-pyynnöillä ja -vastauksilla toteutettuja REST-rajapintoja. Asynkronisessa viestinvälityksessä käytetään erilaisia viestinvälitysprotokollia, kuten AMQP:ta. Välitettävän viestin sisältönä käytetään JSON:in ja XML:n kaltaisia kuvaus- tapoja. Suoritusympäristö. Mikropalveluja suoritetaan usein ohjelmistokonteissa (engl. soft- ware container). Kun perinteiset virtuaalikoneet simuloivat kokonaista tietokonetta käyttöjärjestelmineen, sovelluksineen ja kirjastoineen, ohjelmistokontit eristävät sa- massa isäntäkäyttöjärjestelmässä suoritettavat sovellukset toisistaan. Ohjelmistokon- teilla on useita etuja virtuaalikoneisiin nähden – ne ovat suorituskyvyltään virtuaaliko- neita tehokkaampia ja niiden hallinnointi on yksinkertaisempaa. Toisaalta virtuaaliko- neen käyttö mahdollistaa suoritettavan sovelluksen täydellisemmän ja varmemman eris- tämisen ympäristöstään. (Herrera-Izquierdo & Grob, 2017.) 65 4.4.3 Mikropalvelujen kehittäminen Tarkastellaan seuraavaksi, miten mikropalveluihin perustuvan sovelluksen kehittäminen eroaa monoliittisen sovelluksen kehitystyöstä. Mikropalveluja käsittelevissä katsannoissa arkkitehtuurityylin mukaiseen ohjelmistokehitykseen esitetään usein liittyvän DevOps-toimintatavan (esim. Balalaie, Heydarnoori & Jamshidi, 2016). Toimintatavan nimi tulee ohjelmiston elinkaaren eri vaiheista – kehityksestä (engl. development) ja tuotannosta (engl. operation) – jotka toimintatapa yhdistää yhden tiimin tehtäväksi. Ketterän ohjelmistokehityksen yhdistettyä ohjelmistojen määrittely-, suunnittelu-, toteutus- ja testaustyövaiheet yhdeksi kokonaisuudeksi, DevOps-toimintatavan voitaneen ajatella liittävän myös ohjelmiston ylläpidon ja tuotannon vaiheet osaksi samaa iteratiivista prosessia. Mikropalveluja kehittävät tiimit ovat poikkitoiminnallisia (engl. cross-functional) ja ne muodostetaan liiketoiminnan kyvykkyyksien ympärille. Poikkitoiminnallisuudella tar- koitetaan, että tiimillä on kaikki tarvittava osaaminen palvelujensa kehittämiseen. Tiimi voi sisältää esimerkiksi käyttöliittymäsuunnittelu-, projektinhallinta- ja tietokantaosaa- mista. Vastakohta tälle poikkitoiminnallisuudelle olisi, että näille eri teknisille osa-alu- eille olisi muodostettu omat tiiminsä, jotka työskentelisivät useiden palvelujen kehittä- misessä oman erikoisosaamisensa osalta. (Lewis & Fowler, 2014.) Tiimit vastaavat kehittämästään palvelusta koko sen elinkaaren ajan. Tiimien työskente- lytapa muistuttaa tällöin enemmän tuotekehitystä kuin perinteistä ohjelmistoprojektia, jossa valmis tuotos luovutetaan projektin päätteeksi toisen tahon ylläpidettäväksi. Tä- män voidaan katsoa tukevan myös kehitettävästä palvelusta tiimin kesken jaettua vas- tuuta ottavan kulttuurin muodostumista, ja kasvattavan ohjelmiston kaikkien ohjelmis- ton kehitykseen ja ylläpitoon sisältyvien työvaiheiden toteutuksen laadukkuutta. (Lewis & Fowler, 2014.) Keskeisenä piirteenä mikropalvelujen kehittämiselle ja ylläpidolle voidaan pitää työs- kentelytapojen ja kulttuurin lisäksi myös laajaa toistuvien tehtävien automatisointia. Ohjelmiston testauksen ja asentamisen kaltaisten tehtävien automatisointi sekä nopeut- taa muutosten tekemistä ohjelmistoon ja vapauttaa aikaa enemmän arvoa tuottaviin teh- täviin että vähentää toistuvassa rutiinityössä ihmisten toisinaan tekemiä virheitä. Automatisointi mahdollistaa esimerkiksi jatkuvan jatkuva integraation (engl. continuous integration) käytännön, jossa ohjelmiston lähdekoodiin tehdyn yksittäisen muutoksen 66 seurauksena koko ohjelmisto voidaan kääntää ja testata automaattisesti, ja ohjelmistoa kehittävän tiimin saatavilla on jatkuvasti uusimmat muutokset sisältävä versio ohjelmis- tosta. Toinen keskeinen hyöty automaatiosta on jatkuvan toimituksen (engl. continuous deli- very) mahdollistaminen. Tällöin ohjelmiston viimeisin versio on koska tahansa julkais- tavissa tuotantokäyttöön, ja julkaisuajankohta voidaan päättää pikemminkin liiketoimin- nan tarpeiden kuin ohjelmiston kehittämiseen liittyvien rajoitteiden mukaisesti. Fowler (2013) määrittelee jatkuvan toimituksen mallin vaativan, että ohjelmisto on asennetta- vissa koko sen elinkaaren ajan, sitä kehittävä tiimi priorisoi ohjelmiston toimitettavassa kunnossa pysymisen uusien toimintojen lisäämisen edelle, ohjelmiston tuotantovalmiu- desta on jatkuvasti saatavilla tietoa, ja mikä tahansa versio ohjelmistosta voidaan asen- taa mihin tahansa ympäristöön18 napin painalluksella. Muita kehitys- ja ylläpitotyöhön vaikuttavia teknologioita on esimerkiksi edellä kuvattu virtualisoinnin ja erityisesti ohjelmistokontteihin perustuvan virtualisoinnin käyttö oh- jelmistojen asennukseen ja niiden skaalaamiseen. 4.4.4 Mikropalveluarkkitehtuurin haasteita Vaikka mikropalvelut on tässä tarkastelussa esitetty monoliittisen ja palvelukeskeisen arkkitehtuurin kautta kulkeneen kehityksen lopputuloksena, ei sen voida ajatella olevan näitä yksikäsitteisesti parempi ohjelmistojen toteutustapa. Kuten muiden arkkitehtuuri- tyylien, myös mikropalvelujen käyttöön liittyy haasteita, joita tulee käyttökohteittain ar- vioida mikropalveluihin perustuvan toteutustavan tuottamia hyötyjä vasten. Mikropalvelujen käytön haasteiksi voidaan todeta ainakin niiden toteutustavasta aiheu- tuva ylimääräinen monimutkaisuus ja työmäärä, niiden hallintaan liittyvä monimutkai- suus, haasteet palvelujen integroinnissa sekä oikean rajauksen löytäminen palvelujen välille. Toteutustavasta aiheutuva monimutkaisuus. Mikropalvelujen toteutustapaan liittyy tietty määrä ylimääräistä työtä monoliittiseen toteutustapaan verrattuna. Tämä työmäärä aiheutuu mikropalvelujen toteutukseen liittyvistä piirteistä ja käytännöistä, kuten esi- merkiksi verkkoyhteyksistä aiheutuviin virhetilanteisiin varautumisesta tai palvelujen 18 Tyypillisesti tällaisia ympäristöjä ovat esimerkiksi ohjelmiston kehitys-, testi- ja tuotantoympäristö. 67 suorituksenaikaisen monitoroinnin toteuttamisesta, joihin ei tyypillisesti ainakaan sa- massa laajuudessa jouduta paneutumaan yhdestä laajasta kokonaisuudesta koostuvaa monoliittista sovellusta toteutettaessa. Järjestelmän monimutkaisuuden kasvaessa kuvan 19 mukaisesti monoliittisen järjestel- män toteutustyön tuottavuus alenee kuitenkin nopeammin, kuin mikropalveluihin perus- tuvaa järjestelmää kehitettäessä. Näin ollen mikropalvelujen käyttö muuttuu kannatta- vaksi, kun kehitettävänä on riittävän laaja ja monimutkainen järjestelmäkokonaisuus. (Fowler 2015a.) Kuva 19. Järjestelmän monimutkaisuuden vaikutus sen toteutustyön tuottavuuteen (Fowler 2015a). Hallintaan liittyvä monimutkaisuus. Samoin kuin mikropalvelujen toteutuksen yhtey- dessä, voidaan niihin liittyvä monimutkaisuus ajatella haasteeksi myös mikropalveluista koostuvan järjestelmän ylläpidon ja tuotannon aikana. Toteutustavan hyötyjä tulee myös tästä syystä verrata siitä aiheutuviin haasteisiin järjestelmän arkkitehtuurityyliä valitta- essa. Palvelujen integrointi. Galen Gruman and Alan Morrison esittävät mikropalvelujen so- pivan huonosti käyttökohteisiin, joissa tarvitaan palvelujen laajaa integrointia (Strîmbei ym. 2015). Mikropalveluille tyypillinen niiden käsittelemien tietojen tallentaminen pal- velukohtaiseen tietokantaan tukee palvelujen autonomisuutta, mutta aiheuttaa edellä ku- vatusti merkittäviä esteitä esimerkiksi transaktioiden toteuttamiselle (Lewis & Fowler 2014). 68 Oikean rajauksen löytäminen. Fowler (2015b) toteaa mikropalveluihin perustuvan järjestelmän arkkitehtuurisuunnittelussa haasteeksi oikeiden rajausten löytämisen järjes- telmäkokonaisuuden jakamisessa palveluihin. Oikeanlaisen liiketoiminnan osa-alueisiin perustuvan rajauksen tekemisen voidaan aja- tella vähentävän esimerkiksi integraatioiden tarvetta palvelujen välillä – kun liiketoi- minnan palvelut rajataan toisistaan riittävän itsenäisiksi kokonaisuuksiksi, niitä pysty- tään tukemaan mikropalveluilla, jotka sisältävät kaikki liiketoiminnan palvelun suoritta- miseen tarvittavat tiedot. Yksittäisten mikropalvelujen pilkkomisen liian pieniksi kokonaisuuksiksi voidaan kat- soa kuvan 20 mukaisesti haittaavan myös kehitystyön tuottavuutta (kasvattamalla yli- määräistä monimutkaisuutta) ja järjestelmän suorituskykyä. Kuva 20. Palvelujen hienojakoisuuden vaikutus järjestelmän ominaisuuksiin (Zahed ym. 2013). Kehitystyön tuottavuus alenee, kun merkittävä suhteellinen osuus hyvin pienen toimin- non toteuttavan palvelun lähdekoodista liittyy vähäisen liiketoimintalogiikan sijasta esi- merkiksi palvelun vastaanottamien viestien käsittelyyn ja niihin vastaamiseen. Järjestel- män suorituskykyä liian pieniin toisiinsa yhteydessä oleviin palveluihin perustuva toteu- tustapa haittaa, koska se lisää palvelujen välillä tietoverkon yli tehtäviin kutsuja, joihin liittyy aina viivettä. 69 4.5 Monoliittisen, palvelukeskeisen ja mikropalveluarkkitehtuurin vertailu Tarkastellaan luvun lopuksi vielä Strîmbein ym. (2015) esittämää yhteenvetoa monoliit- tisen, palvelukeskeisen ja mikropalveluarkkitehtuurin piirteistä. Taulukossa 4 tarkastel- laan kansainväliseen eri yliopistojen väliseen järjestelmäkehitykseen liittyviä haasteita ja niistä aiheutuvia vaatimuksia, sekä sitä, miten eri arkkitehtuurityylit vastaavat näihin esitettyihin vaatimuksiin. Ottamatta kantaa yksittäisten vaatimusten täsmällisiin merkityksiin tai toteutumisen ar- viointiin eri arkkitehtuurityylien kohdalla, Strîmbein ym (2015) esitystä voitaneen tul- kita siten, että mikropalvelut tukevat kaikkia vaatimuksia, toisin kuin esimerkiksi mono- liittinen arkkitehtuuri. Niitä voidaan siis näiden vaatimusten toteuttamiseksi soveltaa ti- lanteessa kuin tilanteessa. Kuitenkin edellä mikropalvelujen haasteiden yhteydessä ku- vatusti toteutettavan järjestelmän tulee olla riittävän monimutkainen mikropalveluilla toteutettavaksi, jotta niistä aiheutuva ylimääräinen monimutkaisuus ja työmäärä eivät muodostu liian suuriksi. 70 Taulukko 4. Monoliittisen, palvelukeskeisen ja mikropalveluihin perustuvan arkkitehtuurin piir- teitä Strîmbei ym. (2015). Vaatimus Monoliittinen arkkitehtuuri Palvelukesk.- arkkitehtuuri Mikropalvelu- arkkitehtuuri Liiketoiminnan vaatimukset Joustavat toimintaprosessit Kyllä* Kyllä Kyllä Alueelliset erityispiirteet: maa, kieli tai maantieteellinen alue Kyllä Kyllä Kyllä Integraatio: Alueelliset eroavaisuudet Ei Kyllä Kyllä Orkestrointi: Globaalit yhteneväisyydet Ei Kyllä* Kyllä* Tekniset vaatimukset Integraatio: Autonomiset perinnejärjes- telmät Ei Kyllä Kyllä* Integraatio: Alustojen eroavaisuudet Ei Kyllä Kyllä Integraatio: Toiminnallisen joustavuu- den maksimointi Ei Kyllä* Kyllä Hallittu integraatioiden monimutkai- suus Ei Kyllä Kyllä* Toiminnallinen autonomisuus Kyllä Kyllä* Kyllä Skaalautuvuus Kyllä* Kyllä Kyllä Useiden käyttäjien pääsy Kyllä* Kyllä Kyllä* Verkko- ja mobiiliyhteys Ei Kyllä Kyllä Datan integrointi ja välitys Ei Kyllä Kyllä* Joustavat ohjelmistoratkaisut Ei Kyllä* Kyllä Suorituskyky: vasteajan minimointi Kyllä Kyllä Kyllä* Suorituskyky: viiveen minimointi Kyllä Kyllä Kyllä Offline- ja online-käsittely Ei Ei Kyllä Kyllä*-merkinnällä tarkoitetaan, että vaatimusta ei tueta täysin, mutta se voitaisiin toteuttaa tietyissä olosuhteissa tai ottaen huomioon joitakin poikkeuksia. (Strîmbei ym. 2015) 71 4.6 Yhteenveto luvusta Tässä luvussa käsiteltiin mikropalveluarkkitehtuuria ja sitä edeltäneitä monoliittista ja palvelukeskeistä arkkitehtuuria. Vaikka esitettyjen arkkitehtuurityylien voitaneen katsoa kehittyneen ratkaisemaan edeltäjiensä ongelmia, liittyy niihin kaikkiin omanlaisiaan haasteita, eikä mitään niistä voida katsoa täysin vanhentuneeksi tai nykyjärjestelmiin so- veltumattomaksi. Tästä johtuen kaikkien kolmen arkkitehtuurityylin käsittely auttaa seuraavassa, Turun kaupungin toimintaa tarkastelevassa luvussa arvioimaan kutakin kaupungin toiminnan osa-aluetta tukevalle informaatioteknologialle tarkoituksenmukai- sen teknisen toteutustavan. Luku aloitettiin tarkastelemalla monoliittista arkkitehtuuria, ja erityisesti sen haasteita. Monoliittisen arkkitehtuurin todettiin usein monimutkaisuudestaan johtuen rapautuvan elinkaarensa aikana, eli ohjelmistoon sen elinkaaren aikana tehdyt muutokset rikkovat sille alun perin suunniteltua arkkitehtuuria ja rakennetta. Lisäksi haasteiksi todettiin mo- noliittisen rakenteen ohjelmistokehitykselle aiheuttamat viiveet, suorituskyvyn skaalaa- misen haasteet ja se, ettei ohjelmiston moduulien teknisiä toteutustapoja, eli käytettyjä ohjelmointikieliä ja ohjelmistokehyksiä voida valita tarpeen mukaisesti moduulikohtai- sesti. Monoliittisen arkkitehtuurin jälkeen siirryttiin tarkastelemaan palvelukeskeistä arkkiteh- tuuria. Tarkastelun yhteydessä kuvattiin palveluihin ja niiden tekniseen toteutukseen liittyviä käsitteitä ja esitettiin palvelukeskeiselle arkkitehtuurille olennaisia suunnittelu- periaatteita. Palvelukeskeisen arkkitehtuurin suunnitteluperiaatteiden todettiin tyypilli- sesti pätevän myös mikropalveluarkkitehtuureihin, missä yhteydessä niitä tarkennetaan vielä mikropalveluihin liittyvillä periaatteilla. Palvelukeskeisen arkkitehtuurin tarkaste- lun lopuksi esitettiin yleisiä ja vakiintuneita toteutustapoja palvelukeskeiselle arkkiteh- tuurille, ja esitettiin sitä koskevaa kritiikkiä. Palvelukeskeisen arkkitehtuurin haasteiden katsottiin liittyvän usein pääosin sen toteutustapoihin, eikä niinkään arkkitehtuurityyliin itseensä tai siinä noudatettaviin suunnitteluperiaatteisiin. Luvun lopuksi tarkasteltiin tämän työn keskeisenä aiheena olevaa mikropalveluarkkiteh- tuuria. Samoin kuin palvelukeskeisen arkkitehtuurin tarkastelussa, mikropalvelujen osalta erotettiin toisistaan niiden keskeiset suunnitteluperiaatteet ja toisaalta niille tyy- pilliset tekniset toteutustavat. 72 Mikropalvelujen todettiin rakentuvan yleensä yhden tukemansa liiketoiminnan tarvitse- man kyvykkyyden ympärille. Ne toteutetaan tukemaan tätä palvelua siten, että ne eivät sisällä ylimääräistä toiminnallisuutta tai tarpeettomia riippuvuuksia muihin palveluihin, ja niiden välinen vuorovaikutus pyritään toteuttamaan mahdollisimman yksinker- taiseksi, säilyttäen palvelujen vuorovaikutukseen liittyvän liiketoimintalogiikan palvelu- jen sisällä. Lisäksi, koska mikropalveluarkkitehtuuria noudatettaessa sovelluksen mo- duulit on hajautettu kommunikoimaan verkon ylitse, tulee niihin perustuvia ratkaisuja suunniteltaessa varautua lähtökohtaisesti verkkoyhteyksistä johtuviin virhetilanteisiin. Mikropalvelujen todettiin sisältävän tyypillisesti palveluun liittyvien tietojen pysyväis- tallennuksen. Tämän todettiin toisaalta mahdollistavan kunkin palvelun tiedoille parhai- ten soveltuvan tallennusteknologian valinnan, mutta toisaalta aiheuttavan epäilemättä uudenlaisia haasteita organisaation laajuiselle tiedonhallinnalle. Mikropalveluarkkitehtuurin toteutustavoista eriteltiin niiden toteuttamiseen käytettävien ohjelmistokehysten, kommunikointimenetelmien ja suoritusympäristön erityispiirteitä. Mikropalvelut kommunikoivat keskenään muun muassa suorilla rajapintakutsuilla pal- velujen välillä, API-yhdyskäytävän kautta tai viestinvälityspalvelinta käyttäen. Tunnus- omaista niiden väliselle vuorovaikutukselle ovat palvelukeskeisen arkkitehtuurin yhtey- dessä käytettyihin teknologioihin verrattuna kevyemmät toteutustavat. Mikropalvelujen teknisten toteutustapojen jälkeen tarkasteltiin mikropalvelujen toteu- tuksessa käytettäviä työskentelymenetelmiä, DevOps-toimintatapaa ja mikropalvelujen käyttöön liittyviä haasteita. Toimintatavalle keskeiseksi piirteeksi todettiin, että palve- luja kehittävät tiimit vastaavat niistä palvelun koko elinkaaren ajan. Mikropalvelujen kehityksessä noudatetuiksi keskeisiksi periaatteiksi tunnistettiin myös toistuvien työteh- tävien automatisointi sekä jatkuvan integraation ja julkaisemisen periaatteet, joita nou- datettaessa kehitettävän ohjelmiston haluttu versio voidaan koska tahansa julkaista käyt- töön liiketoiminnan tarpeiden mukaisesti. Mikropalveluihin liittyvien haasteiden osalta todettiin erityisesti, että mikropalveluilla toteutettavan järjestelmän tulee olla riittävän monimutkainen, jotta mikropalveluista aiheutuva ylimääräinen monimutkaisuus ja työ korvautuvat niiden käytöstä saaduilla hyödyillä. Luvun lopuksi tarkasteltiin Strîmbein ym. (2015) esitykseen perustuen monoliittisen, palvelukeskeisen ja mikropalveluihin perustuvan arkkitehtuurin vaatimustenmukai- suutta erään esimerkkijärjestelmän toteutuksessa. Mikropalvelujen todettiin Strîmbein ym. mukaan vastaavan vaatimuksiin parhaiten. 73 Tämän teoriaosan päättävän luvun jälkeen siirrytään tarkastelemaan edellä kuvattua lii- ketoiminnan ja informaatioteknologian yhdenmukaisuuden haastetta, siihen vastaavaa bimodaalisen IT-toiminnon käsitettä sekä arvioimaan mikropalveluarkkitehtuurin sovel- tuvuutta digitaalisen ja perinteisen informaatioteknologian kokonaisuuksien yhdistäjänä Turun kaupungin toimintaympäristössä. 74 5 Bimodaalinen IT ja mikropalveluarkkitehtuuri Turun kaupungilla Työn toisessa osuudessa tarkastellaan bimodaalisen toimintatavan ja mikropalveluarkki- tehtuurin hyödyntämismahdollisuuksia Turun kaupungin toimintaympäristössä. Aloite- taan tarkastelu käymällä lyhyesti läpi Turun kaupungin organisaatiorakenne ja kaupun- gin kehittämistoimintaa ohjaava kehittämismalli. Tämän jälkeen siirrytään tarkastele- maan teorialuvuissa kuvattuja malleja Turun kaupungin toimintaympäristöön sovellet- tuina. Tarkastelun yhteydessä arvioidaan myös tutkimuskysymyksiä ja esitetään niihin liittyviä johtopäätöksiä. 5.1 Taustaa Turun kaupunki on yli kymmenen tuhannen työntekijän organisaatio, joka muodostuu kaupunginjohtajan johtamasta konsernihallinnosta ja neljästä toimialasta. Konsernihal- linto huolehtii kaupunginvaltuuston, kaupunginhallituksen sekä sen jaostojen päätök- senteon valmistelusta ja päätösten toteutuksesta. Kaupunginhallituksen alaisuudessa toi- mii lisäksi seitsemän palvelukeskusta, Varsinais-Suomen Pelastuslaitos sekä useita kon- serniyhtiötä. Kuva 21. Turun kaupungin organisaatiorakenne (lähde: https://www.turku.fi/organisaatio) 75 Kaupungin IT-toiminto on järjestetty pääosin IT-palvelut -palvelukeskukseen ja toimin- nan kehittämisen osalta Strategia ja kehittäminen -vastuualueelle. Näiden lisäksi IT-toi- minnon keskittämistoimenpiteistä huolimatta toimialoilla ja konsernihallinnossa arvioi- daan tehtävän yhä IT-palvelujen vuosittaista työmäärää vastaava määrä IT-järjestelmiin liittyvää työtä. Näiden tehtävien todetaan kaupungin tietohallintostrategiassa liittyvän pääosin toimialakohtaisten tietojärjestelmien pääkäyttäjätehtäviin sekä toiminnalliseen kehittämiseen, ja niiden todetaan vaativan usein syvällistä toimiala- tai liiketoiminta- osaamista. (Turun kaupunki, 2017.) Kaupungin kehittämistyötä ohjataan kehittämismallilla (kuva 22). Kehittämismalliin si- sältyvä kehittämissalkun hallinta varmistaa, että kaupungin kehittämisresurssien käyttö kohdistuu tavoitteiden kannalta tärkeimpiin asioihin. Hanke- ja projektihallinta taas var- mistavat, että kehittämisprojektien tehtävät ja resurssit organisoidaan ja hallitaan siten, että projekteille asetetut tavoitteet saavutetaan niille suunnitellun laajuuden, aikataulun ja budjetin mukaisesti. (Turun kaupunki, 2014.) Kuva 22. Turun kaupungin kehittämismalli (Turun kaupunki 2014) 76 IT-toiminnon näkökulmasta kaupungin kehittämismallilla varmistetaan, että IT-palvelut osallistuvat toimialojen kehittämisprojekteihin jo niiden varhaisessa vaiheessa ja että projektien informaatioteknologian hyödyntämiseen liittyvien osuuksien toteuttamiselle on olemassa selkeät kokonaisarkkitehtuuriin perustuvat suuntaviivat (Turun kaupunki, 2017). 5.2 Nykytila Aloitetaan tutkimuskysymysten tarkastelu kuvaamalla Turun kaupungin nykytilaa poh- jautuen sen informaatioteknologian hyödyntämistä ja kehittämistä ohjaavaan tietohallin- tostrategiaan. Tietohallintostrategiaa tarkastellaan edellä esitettyjen strategisen yhden- mukaisuuden sekä bimodaalisen IT-toiminnon mallien näkökulmista. Eli: onko bimo- daalinen IT-toiminto tarkoituksenmukainen toimintatapa Turun kaupungille? 5.2.1 Strateginen yhdenmukaisuus Henderssonin ja Venkatramanin (1993) esittämä strategisen yhteensopivuuden malli kä- sittelee toisaalta organisaation toiminnan ja sen käyttämän informaatioteknologian ja toisaalta organisaation toimintaympäristön ja sisäisen toiminnan yhteensovittamista. In- formaatioteknologiaa tulisi siis hyödyntää siten, että se vastaa organisaation toiminnan tarpeita, ja organisaation sisäisten toimintatapojen, rakenteiden ja kyvykkyyksien tulisi vastata organisaation toimintaympäristön vaatimuksia. Ulkoisen ympäristön ja sisäisen toteutustavan yhteensopivuutta kutsutaan mallissa stra- tegiseksi yhteensopivuudeksi, ja informaatioteknologian vastaavuutta toiminnan tar- peisiin taas toiminnalliseksi integraatioksi. Henderssonin ja Venkatramanin (1993) malli esittää kuvan 23 mukaiset neljä vaihtoeh- toista lähestymistapaa strategisen yhteensopivuuden ja toiminnallisen integraation ai- kaansaamiseksi. Lähestymistavoista kaksi käyttää lähtökohtanaan (liike-)toiminnan stra- tegiaa ja kaksi IT-strategiaa, ja ne kaikki yhdistävät esitetyistä neljästä osa-alueesta kolme toisiinsa. 77 Kuva 23. Lähestymistavat strategisen yhteensopivuuden ja toiminnallisen integraation saavutta- miseksi. (Hendersson ja Venkatraman, 1993) Tarkastellaan seuraavaksi, voidaanko Turun kaupungin toimintaa ja informaatioteknolo- giaa koskevien strategioiden katsoa noudattavan jotakin mallin esittämistä yhdenmu- kaistamisen lähestymistavoista. Turun kaupungin toimintaa ohjaa strategiahierarkia, jonka osa-alueita ohjaa vuoteen 2029 asti ulottuva kaupunkistrategia. Informaatioteknologian hyödyntämistä Turun kau- pungin toiminnassa sekä IT-toimintoa ohjaa kaupungin tietohallintostrategia19. Se on yksi kaupunkitason ohjausasiakirjoista, jotka täydentävät kaupunkistrategian ja strate- gisten ohjelmien muodostamaa kokonaisuutta (Turun kaupunki, 2017). Vuosille 2017–2021 laadittua tietohallintostrategiaa ohjaavat kaupunkistrategiasta ja strategisista ohjelmista johdetut tavoitteet. Strategia perustuu kaupungin konsernihallin- nolta, toimialoilta ja konserniyhtiöiltä kartoitettuihin tarpeisiin sekä kaupungin tietohal- lintoa koskevaan riskianalyysiin. 19 Kaupungin nykyinen tietohallintostrategia koskee vuosia 2017–2021. Se käsittelee varsinaisen infor- maatioteknologian hyödyntämisen ja IT-toiminnon toteutustavan lisäksi myös esimerkiksi kaupungin yh- teisten toimintamallien, johtamiskäytäntöjen ja osaamisen kehittämistä, minkä johdosta strategiaa halut- tiin nimittää sen sisältöä paremmin kuvaavasti aiemman IT-strategian sijasta tietohallintostrategiaksi. 78 Strategisen yhdenmukaisuuden mallin kautta tarkasteltuna Turun kaupunki näyttäisi ta- voittelevan strategista yhteensopivuutta ja toiminnan integraatiota soveltaen ensisijai- sesti ensimmäistä Henderssonin ja Venkatramanin (1993) esittämistä lähestymistavoista – strategian toteuttamista (kuva 24). Kuva 24. Turun kaupunki- ja tietohallintostrategia strategisen yhdenmukaisuuden mallin kautta tarkasteltuina. Strategian toteuttamisen näkökulmassa yhdenmukaisuuden tarkastelu aloitetaan ulkoi- seen (liike-)toimintaympäristöön nähden tehtäviä valintoja koskevasta strategiasta. Stra- tegia kattaa muun muassa organisaation sijoittumisen kilpailijoihinsa nähden, sen valin- nat kilpailijoistaan erottumiseen, organisaation valitsemat kumppanit ja suhteet organi- saation sidosryhmiin. Tästä strategiasta johdetaan toiminnan sisäiseen toteutustapaan liittyvät päätökset. Päätökset koskevat esimerkiksi organisaation hallinnollista infra- struktuuria, prosesseja ja osaamisia. Näiden jälkeen tarkastellaan informaatioteknologi- aan liittyviä sisäisiä kysymyksiä, kuten tietojärjestelmäinfrastruktuurin ja tietojärjestel- miin liittyvien prosessien toteutustapoja. Turun kaupungilla tämän tarkastelun voidaan yksinkertaistetusti katsoa tapahtuvan si- ten, että kaupunkistrategia ja strategiset ohjelmat kattavat sekä kaupungin toiminnan tar- kastelun ulkoisessa toimintaympäristössä että osin näistä johdettavat sisäisen toiminnan piirteet. Tietohallintostrategia taas tarkastelee kaupunkitasoiseen strategiaan pohjautuen 79 sekä toimintaan liittyviä kysymyksiä (esimerkiksi johtamiseen liittyvät käytännöt, osaa- misvaatimukset) että toiminnan tukemista informaatioteknologialla. Strategisen yhdenmukaisuuden käsittelyn lopuksi todettakoon, että eroavaisuus Hender- sonin ja Venkatramanin (1993) mallissa käytetyn ja Turun kaupungin käyttämän sanas- ton välillä voi aiheuttaa sekaannuksia sovellettaessa mallia Turun kaupungin toimin- taan: vaikka kaupunki tuottaa edellä kuvatusti aiemmin IT-strategiaksi kutsutun tieto- hallintostrategian, IT-strategian osa-alue ei kuvan 24 mukaisesti näyttäisi sisältyvän kaupungin käyttämäksi tunnistettuun strategisen yhdenmukaisuuden lähestymistapaan. Tämä johtuu siitä, että Henderson ja Venkatraman kutsuvat organisaation sijoittumista ulkoiseen IT-markkinaan nähden (ulkoinen–informaatioteknologia) IT-strategia -ni- miseksi osa-alueeksi. Ulkoiseen IT-markkinaan nähden sijoittumista ei voitane kuiten- kaan pitää keskeisenä näkökulmana kaupungin kaltaisen organisaation strategiassa. Tarkastellaan seuraavaksi, miten bimodaalinen toimintatapa ilmenee kaupungin toimin- nassa tietohallintostrategiaan nähden. 5.2.2 Bimodaalinen toimintatapa Kohdassa 2.4 esitettiin bimodaalisen IT:n toimintamalli, jossa IT-toiminto toimii rin- nakkain perinteisellä ja digitaalisuutta tukevalla toimintatavalla. Perinteistä toimintata- paa tarvitaan kustannustehokkuuden, toimintavarmuuden ja vakauden kaltaisiin vaati- muksiin vastaamiseksi ja digitaalista toimintatapaa ketteryyden ja nopeuden kaltaisten tavoitteiden toteuttamiseen. Turun kaupungin tietohallintostrategiasta voidaan tunnistaa näitä keskenään erisuuntai- sia informaatioteknologian hyödyntämiseen ja IT-toimintoon kohdistuvia vaatimuksia. Strategiassa tavoitellaan muun muassa perusjärjestelmien kustannustehokkuutta, skaala- etuja, resurssien tehokkaampaa käyttöä sekä toimintaprosessien ja näitä tukevien tieto- järjestelmien harmonisointia. Toisaalta IT-palveluilta toivottiin tietohallintostrategiatyön osana tehdyssä kyselyssä tu- kea toimialojen ja konserniyhtiöiden toiminnan kehittämiseen – toiminnon tulisi olla ”palvelupyyntöjen ja projektien toteuttajan sijaan aktiivinen ja innovatiivinen kehittämi- sen tukitoiminto, jolla on hyvä toimialaosaaminen”. IT-palvelujen tärkeäksi tehtäväksi todetaan ”jatkuvasti seurata teknologian kehitystä, kokeilla aktiivisesti uusia ratkaisuja 80 yhteistyössä strategian ja kehittämisen vastuualueen kanssa ja tuoda niitä toimialojen ja konserniyhtiöiden käyttöön”. (Turun kaupunki 2017.) Kaupunkiin ja sen IT-toimintoon voitaneen siis katsoa kohdistuvan näitä kahdenlaisia vaatimuksia. Tarkastellaan seuraavaksi, miten ne näyttäytyvät Turun kaupungin toimin- nassa. Kohdassa 2.4.3 kuvattiin Haffken ym. (2017a, s. 5464) esitykseen perustuen erilaisia ta- poja bimodaalisen toiminnan järjestämiseen. Tunnistettuja vaihtoehtoja olivat projekti- kohtainen toimintatavan valinta, IT-toiminnon rakenteellinen jakautuminen kahteen toi- mintatapaan ja toiminta kahtena erillisenä organisaatioyksikkönä. Projektikohtaisessa toimintatavassa osa projekteista toimii niihin kohdistuvia vaatimuksia vastaavasti kette- rälle digikehittämiselle tyypillisillä tavoilla, ja osa perinteisemmillä IT-projektien mene- telmillä. IT-toiminnon rakenteellisen jakautumisen vaihtoehdossa IT-toiminto organi- soituu sisäisesti kahdeksi eri yksiköksi, joilla on omat toimintatapansa. Selkein ero toi- mintatapojen välille tehdään kolmannessa vaihtoehdossa, jossa IT-toiminnon rinnalla toimii erillinen digikehittämisen yksikkö. Horlach ym. (2016, s. 1424) esittävät näiden lisäksi toimintatavan, jossa digitaalista ke- hittämistä tehdään liiketoimintayksiköissä ja IT-toiminto palvelee niitä perustoimintansa ohella ja valmentajan roolissa. Erityisesti tässä toimintatavassa IT-toiminto hyödyntää Horlachin ym. mukaan tyypillisesti ulkopuolisia kumppaneita riittävien resurssien ja osaamisen varmistamiseksi. Digitaaliseen IT-toimintoon liittyvät osaamisvaatimukset on tunnistettu keskeiseksi haasteeksi niin Horlachin ym. (2016) ja Haffken ym. (2017a) esityksissä kuin Turun kaupungin tietohallintostrategiassakin.20 Turun kaupungin informaatioteknologian hyödyntämisen ja digitaalisen kehittämisen voidaan katsoa toimivan osin kahteen yksikköön jakautuneena – varsinaisen IT-toimin- non toteuttamien projektien lisäksi toimialojen keskeisimmät digitalisointitavoitteet on koottu osaksi siitä erillistä, kaupungin kärkihankkeena toteuttavaa digitaalisten palvelu- jen kehittämishanketta. Toisaalta IT-toiminto toimii myös Horlachin ym. (2016, s. 1424) kuvaamalla tavalla organisaation sisäisen konsultin roolissa, hankkien tarvittaessa 20 Horlach ym. (2016, s. 1424) esittävät osaamisvaatimusten koskevan paitsi käyttäjäkokemuksen, älyk- käiden laitteiden ja robotiikan kaltaisia digitaalisen IT-toiminnon osaamisia, myös perinteiseen IT:hen liittyviä uusia tehtäviä. Perinteisen IT:n uudet osaamisvaatimukset liittyvät tarpeeseen tarjota perus-IT:tä liiketoiminnalle entistä tuotteistetumpana palveluna (ITaaS). Tämä vaatii mm. turvallisuuden ja riskien- hallinnan sekä ohjelmistokehitys- ja integraatio-osaamista. 81 digikehittämiseen liittyvää osaamista myös organisaation ulkopuolisilta toimittajilta. Li- säksi IT-toiminto toimii myös sisäisesti projektikohtaisesti eri menetelmillä projektin kohteen mukaisesti. Turun kaupungin voidaan todeta toimivan informaatioteknologian hyödyntämisessä sa- manaikaisesti sekä ketteryyden ja kokeellisuuden mahdollistavilla että perinteisillä, va- kautta ja toimintavarmuutta painottavilla menetelmillä. Kaupungin ei kuitenkaan voida katsoa valinneen digikehittämiselle selkeästi yhtä Horlachin ym. (2016) tunnistamista bimodaalisuuden toteutustavoista. Jatkettaessa tietohallintostrategian tarkastelua, nähdään strategian osana tehdyssä riskien kartoituksessa todettavan nykyisen toimintatavan pohjautuvan ”vahvaan keskittämiseen ja kustannustehokkuuden tavoitteluun, mikä saattaa johtaa joustavuuden vähenemiseen asiakkaiden näkökulmasta.” (Turun kaupunki, 2017.) IT-toimintoon tyypillisesti kohdistuvien kustannustehokkuuden, mittakaavaetujen ja standardoinnin vaatimusten voidaan ajatella olevan ristiriidassa tai ainakin merkittävänä reunaehtona (liike-)toiminnan ja IT:n yhdenmukaisuuden vaatimukselle. Edellä kuva- tusti toiminnan ja informaatioteknologian yhdenmukaisuudella (eli toiminnallisella in- tegraatiolla) tarkoitetaan, että informaatioteknologia vastaa mahdollisimman hyvin toi- minnan tarpeita. Voidaan ajatella, että mahdollisimman tehokkaasti toimintaa tukevat järjestelmät olisi- vat aina kyseistä organisaatiota ja sen toimintaympäristöön muokkaantuneita yksilöllisiä prosesseja varten täydellisesti räätälöityjä. Toisaalta IT-toiminnon kustannustehokkuu- teen pyritään tyypillisesti järjestelmien ja toimintatapojen yhtenäistämisellä ja standar- doinnilla. Näin ollen toiminnan tukemisessa informaatioteknologialla on tasapainoiltava toisaalta toiminnan vaatimusten mukaisuuden ja toisaalta standardoinnin ja harmoni- soinnin välillä. Silvius (2007) esittää, että organisaatioiden hyödyntämän informaatioteknologian stan- dardointi on edennyt kolmessa vaiheessa. Ensimmäisenä standardointikohteena olivat IT:n perusinfrastruktuuri sekä sähköpostin ja kalenterin kaltaiset yleiskäyttöiset sovel- lukset. Seuraavana kohteena ovat olleet IT-toiminnon palvelutuotannon prosessit, ja kolmantena toiminnanohjaus- ja asiakastietojärjestelmien kaltaiset standardit ohjelmis- topaketit. 82 Silviuksen (2007) esittämän standardoinnin vaikutus organisaation toimintaan on kasva- nut vaihe vaiheelta, kun se on siirtynyt IT-toiminnon sisäisistä ja organisaatio- ja toimi- alariippumattomista toteutus- ja toimintatavoista kohti (liike-)toiminnalle keskeisiä toi- mintoja. Hendersonin ja Venkatramanin malliin nähden standardointia voitaisiin ajatella kuvan 25 mukaisesti toisaalta toiminnallisen integraation lisäämisenä strategisen yhdenmukai- suuden kustannuksella, jos standardoinnin ajatellaan muokkaavan sekä organisaatio- että tietojärjestelmäinfrastruktuureja keskenään yhteensopiviksi, mutta huonommin or- ganisaation ulkoiseen toimintaympäristöön soveltuviksi. Toisaalta se voitaisiin ajatella myös vain tietojärjestelmäinfrastruktuuria ja -prosesseja koskevana sisäisenä muutok- sena, joka auttaa IT-toimintoa toimimaan kustannustehokkaasti, mutta samalla heiken- tää sekä ulkoisen ja sisäisen toimialueen että toiminnan ja informaatioteknologian yh- denmukaisuutta. Kuva 25. Sekä toimintaa että informaatioteknologiaa koskevan standardisoinnin vaikutuksia. Silvius (2007) näyttää mieltävän standardoinnin pääosin jälkimmäisen vaihtoehdon mu- kaiseksi, tietojärjestelmäinfrastruktuuria ja -prosesseja koskevaksi muutokseksi, joka kasvattaa IT-toiminnon tehokkuutta (engl. efficiency), mutta heikentää sen vaikutta- vuutta (engl. effectiveness). 83 Jos standardointi heikentää informaatioteknologian kykyä tukea tehokkaasti organisaa- tion toimintaa, vaatii standardoinnista saatavan kustannustehokkuuden ja toisaalta te- hokkaasti toimintaa tukevan IT-toiminnon tavoittelu tasapainoilua näiden kahden tavoit- teen välillä. Silvius (2007) esittää keskitetyn informaatioteknologian standardoinnin ja hajautettujen yksilöllisten toimintatapojen painotusten vaihtelevan organisaation toimin- nan eri osa-alueiden välillä kuvan 26 mukaisesti. Kuva 26. Keskitetyn standardoinnin ja hajautetun yksilöllisen IT:n painotukset toiminnan eri osa-alueilla (mukailtu, Silvius 2007) Voidaan ajatella, että mitä lähemmin osa-alue liittyy organisaation ulkoiseen toimin- taympäristöön ja esimerkiksi organisaation sijoittumiseen kilpailijoihinsa nähden, sitä enemmän painottuu toiminnan tarpeita mahdollisimman yksityiskohtaisesta vastaava in- formaatioteknologia. Toisaalta toteutustavaltaan organisaatio- ja toimialariippumatto- milla osa-alueilla, joita ei voida pitää esimerkiksi kilpailuedun perustana, standardoin- nista saavutettava kustannustehokkuus tuottaa enemmän hyötyä, kuin toimintaan räätä- löidysti sovitettu IT. 84 Tarkasteltaessa Turun kaupungin tietohallintostrategiaa huomataan, että esitetyt kustan- nustehokkuuden tavoitteet painottuvat erityisesti IT-infrastruktuurin sekä toimintapro- sessien ja näitä tukevien tietojärjestelmien yhtenäistämiseen. Tarkastellaan seuraavaksi, voidaanko Silviuksen (2007) esittämän mallin katsoa soveltuvan noudatettavaksi Turun kaupungin toiminnassa ja toimintaympäristössä. Kunnan tehtävänä on edistää asukkaidensa hyvinvointia ja alueensa elinvoimaa sekä jär- jestää asukkailleen palvelut taloudellisesti, sosiaalisesti ja ympäristöllisesti kestävällä tavalla. Kuntien toimintaympäristöä määrittävät erityisesti kunnille asetetut lakisääteiset tehtävät21, joiden lisäksi kunnat voivat ottaa itselleen tarpeelliseksi katsomiaan vapaaeh- toisia tehtäviä paikallisten olosuhteiden ja tarpeiden mukaisesti. (Kunnan johtamisen viitearkkitehtuuri, 2016.) Kuntien yhteisten lakisääteisten tehtävien voitaneen katsoa tarkoittavan, että kuntien toi- minnasta löytyy muihin toimialoihin nähden useampia osa-alueita, joilla yksilöllisen kilpailuedun tavoittelun sijasta toimintaa on tarkoituksenmukaista standardoida kustan- nustehokkuuden tavoittelemiseksi22. Koska esimerkiksi kuntien paikalliset toimintaympäristöt sekä poliittisen päätöksenteon linjaukset ja tavoitteet eroavat toisistaan, on kunnilla yhteisten piirteiden lisäksi myös eroavaisuuksia, jotka vaikuttavat niiden organisaation sisäiseen toimintaan. Tähän toi- mintaympäristöön tarkoituksenmukaisesti sijoittumalla ja organisoitumalla kunnan voi- daan ajatella saavuttavan kilpailuetua sekä kansallisesti että kansainvälisesti. Turun kaupunkia ja kuntia yleisesti koskevan version Silviuksen (2007) esittämästä mallista voitaisiinkin ehkä ajatella näyttävän kuvan 27 mukaiselta. Kunnan lakisäätei- sistä tehtävistä johtuen yksilöllisesti ja räätälöidysti toiminnan eri alueita tukevan infor- maatioteknologian rooli voitaneen ajatella tyypilliseen yritykseen nähden liittyen suppe- ammaksi, mutta silti merkittäväksi. 21 ”Vuoden 2013 alussa valmistuneen kuntien tehtäväkartoituksen (Valtiovarainministeriö 2013) mukaan kunnilla oli tuolloin 535 lakisääteistä tehtävää, jotka kuuluivat 10 ministeriön hallinnonalalle. Kuntien lakisääteiset tehtävät koskevat karkeasti sosiaalihuollon, terveydenhuollon, opetuksen ja kulttuu- rin, teknisen alan ja muita palveluita.” (Kunnan johtamisen viitearkkitehtuuri 2016, s. 35) 22 Standardoinnilla voidaan tässä yhteydessä saavuttaa kustannustehokkuuden lisäksi esimerkiksi käyttä- jäkokemukseen liittyviä hyötyjä yhtenäisen asioinnin ja asiakkaalle näyttäytyvän toimintatavan muo- dossa. 85 Kuva 27. Hahmotelma Silviuksen esittämästä mallista kunnan toimintaympäristössä (Liike-)toiminnan strategialla voidaan ehkä ajatella Silviuksen mallia kunnan toimin- taympäristössä tulkittaessa tarkoitettavan kaupungin tekemiä strategisia valintoja, joilla se erottuu muista kunnista. Tällaisina strategisina valintoina voidaan pitää esimerkiksi Smart City -aihepiirin tavoit- teita toteuttavia strategisia kärkihankkeita, jotka eivät ole itsessään osa kunnan lakisää- teisiä tehtäviä, mutta jotka on valittu keinoksi edistää kunnan kilpailukykyä ja hyvin- vointia. Kaupunkien Smart City23 -toimenpiteisiin voidaan katsoa liittyvän puhtaasti toi- minnan kehittämisen lisäksi keskinäistä kansainvälistä kilpailua näkyvyydestä, osaajista ja investoinneista, mikä edellyttää kaupungeilta jo lähtökohtaisesti jossakin määrin yksi- löllisiä ja innovatiivisia ratkaisuja standardoinnin sijasta. Strategisten hankkeiden lisäksi tilaa yksilöllisesti ja hajautetusti toiminnan tarpeisiin vastaavalle informaatioteknologi- alle jäänee erityisesti ainakin ydinprosessien ja spesifisten IT-sovellusten alueille. 23 Smart City -käsitteen sisältö ei ole vakiintunut ja termiä käytetään useissa eri yhteyksissä. Nam ja Pardo (2011) esittävät koosteen useista määritelmistä, joista osa painottaa teknologiaa keskeisenä mah- dollistajana ja osa keskittyy kaupungin tavoittelemien piirteiden kuvailuun. 86 Yhteenvetona Turun kaupungin nykytilan ja sitä koskevan tutkimuskysymyksen tarkas- telusta voidaan todeta kaupungin IT-toiminnon strategista yhdenmukaisuutta tavoitelta- van lähestymistavalla, jossa kaupungin ulkoisesta toimintaympäristöstä ja sen toiminnan sisäisestä toteutustavasta aiheutuvat vaatimukset toimivat syötteinä tietohallintostrategi- alle, joka ohjaa IT-toiminnon toimintatapoja ja teknologioita näihin mahdollisimman te- hokkaasti vastaaviksi. Koska kaupungin toimintaan todettiin liittyvän kahdenlaisia kes- kenään ristiriitaisia vaatimuksia, voitaisiin ajatella tarkoituksenmukaiseksi tukea toimin- nan eri osa-alueita bimodaalisesti niille parhaiten soveltuvilla menetelmillä. 5.3 Tavoitetila Jatketaan tutkimuskysymysten tarkastelua tavoitetilan osalta: miten bimodaalisuus tulisi Turun kaupungin toimintaympäristössä toteuttaa? Turun kaupungin todettiin edellä toimivan jo osin bimodaalisesti, eli osaa sen toimintaa tukevasta informaatioteknologiasta kehitetään kokeellisuuden ja ketteryyden kaltaisia vaatimuksia vastaavasti ja osaa perinteisen IT:n menetelmiä noudattaen. Jos toiminnan eri osa-alueita halutaan bimodaalisessa mallissa tukea eri menetelmillä, voidaan ensim- mäiseksi askeleeksi tätä kohti ajatella keskenään erilaisilla tavoilla tuettavien toiminnan alueiden mahdollisimman eksplisiittistä ja selkeärajaista tunnistamista. 5.3.1 Bimodaalinen toimintatapa toiminnan eri osa-alueilla Hahmotellaan seuraavaksi mahdollista tavoitetilaa yksittäisten palveluprosessien, kon- serninlaajuisten kyvykkyyksien ja standardoitujen tukiprosessien osalta. Palvelujen tukeminen digitaalisella informaatioteknologialla. Edellä kuvattiin Sil- viuksen (2007) esitykseen pohjautuen, miten toiminnan yksilöllisyyden ja standar- disoinnin painopisteet vaihtelevat eri prosesseittain. Toimintaan yksilöllisesti vastaavan informaatioteknologian tarve painottui ydinprosesseihin sekä niitä tukeviin spesifisiin IT-sovelluksiin24. Standardoinnin tarve taas liittyy liiketoiminnan laajuisiin sovelluksiin, tukiprosesseihin, yleisiin sovelluksiin ja IT-infrastruktuuriin. 24 Silvius (2007) ei avaa spesifisen IT-sovelluksen käsitettä tarkemmin, mutta sen voitaneen olettaa asia- yhteydestä päätellen (yleisiin ja liiketoiminnan laajuisiin sovelluksiin verrattuna) tarkoittavan organisaa- tion yksittäisten prosessien tarpeisiin vastaavia IT-sovelluksia. 87 Kohdassa 2.2 todettiin perinteisen IT:n soveltuvan käytettäväksi hyvin tunnetuilla ja en- nakoitavilla alueilla, ja digitaalisen IT:n kokeellisemmilla ja uuden luomista vaativilla alueilla. Arvioitaessa näiden toimintatapojen soveltuvuutta organisaation eri osa-alu- eille, voitaneen digitaalisen IT:n soveltamisalueen katsoa painottuvan yksilöllisesti lii- ketoimintaa vastaavan IT:n alueelle ja perinteisen IT:n standardoitavaksi soveltuvan toi- minnan alueelle. Lisäksi ydinprosesseja tarkasteltaessa digitaalisen IT:n voidaan katsoa painottuvan lä- hellä asiakasrajapintaa oleviin prosessin osiin. Esimerkiksi Bitnerin, Ostromin ja Mor- ganin (2008) esittämällä service blueprint -mallilla kuvattuna prosessin voidaan katsoa koostuvan asiakkaalle näkyvistä ja asiakkaalle näkymättömistä osista. Näkyviä osia ovat verkkosivujen, palvelupisteiden ja tilauslomakkeen kaltaiset asiakaskokemukseen vaikuttavat fyysiset todisteet, asiakkaan tekemät toimenpiteet ja asiakkaalle näkyvät työntekijöiden tehtävät. Asiakas ei näe näkyvyyden rajan taakse jääviä työntekijän toi- menpiteitä eikä tukiprosessien tapahtumia. Kuva 28. Esimerkki service blueprint -tyyppisestä prosessikaaviosta Kun kuvan mukaista asiakkaalle näkyvää prosessia tuetaan IT:n keinoin, voidaan karke- asti katsoa digitaalisen IT:n painottuvan asiakkaalle näkyviin osiin ja perinteisen IT:n erityisesti usein kustannustehokkuutta painottaviin tukiprosesseihin. Asiakkaaseen suo- rimmin vaikuttavien prosessin osien tukeminen ketterällä ja kokeellisuuden mahdollis- tavalla informaatioteknologialla mahdollistaa muun muassa palveluprosessien (ja niitä tukevien järjestelmien) jatkuvan kehittämisen ja havaittuihin ongelmiin reagoinnin. Digitaalinen IT tukisi siis erityisesti kaupungin toimialojen palvelutuotannon prosesseja ja erityisesti niiden asiakasrajapintaa lähellä olevia osia. Toimialat ja konserniyhtiöt 88 osallistuvat nykytilassa tietohallintostrategian mukaisesti toimialakohtaisten tietojärjes- telmien toiminnalliseen määrittelyyn ja kaupungin kehittämismallin mukaiseen kehittä- misen koordinointiin. Yhtenä etenemismahdollisuutena digitaalisen IT-kehittämisen tu- kemiseksi voitaisiin kenties pitää toimialojen ketterän kehittämisen ja teknisen osaami- sen kasvattamista, ja niiden entistä tiiviimpää osallistumista muihinkin kuin määrittely- työn tehtäviin ketterän kehitystyön kaikissa vaiheissa. Asiakasrajapintaa lähellä olevaa toimintaa mahdollisimman tehokkaasti tukevien digi- taalisten palvelujen kehittäminen mahdollistetaan muodostamalla esimerkiksi asiakas- segmentti- tai toimialakohtaisia digikehittämisen tiimejä. Toimintaa lähellä olevat itse- näiset ja poikkitoiminnalliset tiimit toteuttavat toimialaosaamiseen, ketterään kehittämi- seen ja mikropalveluarkkitehtuuriin tukeutuen toimialojen digitaalisia palveluja. Palve- lut toteutetaan kohdassa 4.4.1 kuvatun mukaisesti toiminnan palvelujen tai kyvykkyyk- sien ympärille, ja niitä kehittävät tiimit ovat vastuussa niistä koko niiden elinkaaren ajan. Keskeistä digitaaliselle kehittämiselle on mahdollistaa (liike-)toiminnan palvelusta vas- taavalle taholle ja toimintaa tukevia teknisiä palveluja toteuttavalle tiimille riittävä auto- nomisuus. Palveluprosessille tulisi tällöin määrittää tietyt tavoitteet ja reunaehdot, joita sen tulee noudattaa. Lisäksi prosessia tukevan informaatioteknologiaratkaisun toteutuk- sessa tulee huomioida digitaalisia palveluja läpileikkaavat, esimerkiksi esteettömyyden, graafisen ulkoasun tai käytettävyyden tyyppisiin piirteisiin liittyvät linjaukset. Palvelu- jen kehittäjät tulee myös velvoittaa käyttämään saatavilla olevia konsernin laajuisesti to- teutettuja maksamisen tai tunnistautumisen kaltaisia yhteisiä palveluja. Haasteena digikehittämisen hajauttamisessa ovat erityisesti käytettävään teknologiaan liittyvät osaamistarpeet. Lisäksi hajauttamisen voidaan ajatella tarkoittavan osin paluuta aiempaan tilanteeseen, jossa toimialat kehittivät omia informaatioteknologiaratkaisu- jaan, jotka eivät välttämättä muodostaneet konsernin laajuisesti tarkoituksenmukaista kokonaisuutta. Tällaista ei-toivottua ”siiloutumista” voitaneen välttää ainakin määrittelemällä selkeät rajat, joiden sisällä tiimit ja niiden tukevista palveluista vastaavat tahot voivat tehdä it- senäisiä päätöksiä, ja samoin tunnistamalla selkeästi konsernitasolla toteutettavat palve- lut. Lisäksi konsernitasoisesti voidaan toteuttaa asiakkaille tarkoitettuja käyttöliittymiä ja sovelluksia, joiden osana mikropalvelujen sisältöä esitetään. Toisaalta tietyn tasoinen 89 siiloutuminen voidaan ehkä ajatella hintana, joka yksittäisten palvelujen tarpeisiin vas- taavasta hajautetusta toteutustavasta on maksettava. Konsernin laajuiset kyvykkyydet. Yksittäisten palvelujen digitalisoinnin voidaan kat- soa vaativan tuekseen kuitenkin myös yhteisesti toteutettuja osia. Esimerkiksi käyttäjän tunnistamisen, asiakkaan yhteystietojen tallentamisen tai sukulaisen puolesta tehtävän asioinnin valtuuttaminen jokaisen yksittäisen palvelun yhteydessä aiheuttaa sekä yli- määräistä työtä ja kustannuksia että heikentää asiakaskokemusta. Näitä palvelujen yhtei- siä osia on tarkoituksenmukaista toteuttaa konserninlaajuisina (ja kansallisina), ja tarjota niitä käytettäviksi yksittäisiä palveluprosesseja tukevassa digikehittämisessä. Käytän- nössä nämä toiminnot voitaisiin tarjota digitaalisten palvelujen kehittäjille rajapintoina sekä rajapintojen käyttöä helpottavina ohjelmistomoduuleina. Kuva 29. Kaupungin toiminnan ja IT:n yhteensovittaminen ja eri osa-alueiden toteutustapoja. (Horlachin ym. esittämää mallia mukaillen) Konserninlaajuisten näkökulmien huomiointi itsenäisiin tiimeihin perustuvassa digi- kehityksessä vaatii väistämättä jonkinlaista konsernitasolta tehtävää ohjausta. Pakotta- van konsernitasolta tehtävän ohjauksen sijasta toimialoilla kehitettäviä palveluita voitai- siin ajatella ohjattavan yhtenäisiksi ja konsernitason palveluja hyödyntäviksi myös mah- dollistamisen keinoin, eli tukemalla niiden kehittäjiä suunnittelutyössä ja tarjoamalla kehittämisessä käytettäviksi esimerkiksi muualla toteutettuja valmiita komponentteja ja konsernitason palveluja. Tällöin konsernitasolla tehtävä arkkitehtuuri- ja IT-kehittämis- työ voisivat yksittäisten asiakasrajapinnan palvelujen toteutusten ohjauksen sijasta kes- kittyä konsernin laajuisten kyvykkyyksien rakentamiseen. 90 Edellä kuvatut konsernitason kyvykkyydet ja niitä tukevat tekniset palvelut tulisi tunnis- taa ja rajata siten, että niiden voidaan arvioida pysyvän yksittäisiin kaupungin asiak- kaille tarjottaviin palveluihin nähden kohtuullisen muuttumattomina. Niitä voidaan aja- tella rajapintana toiminnan täsmällisiin tarpeisiin sovitettujen digitaalisten ratkaisujen ja toisaalta kustannustehokkaan standardoidun informaatioteknologian välillä. Standardoidut palvelut ja infrastruktuuri. Silviuksen (2007) esittämän mukaisesti yleisten toimialariippumattomien sovellusten, tukiprosessien, niitä tukevan informaatio- teknologian ja IT-infrastruktuurin standardointi on usein kustannustehokkuuden saavut- tamiseksi tarkoituksenmukaista. Standardoitujen sovellusten ja palvelujen voidaan niiden varsinaisesta toteutustavasta riippumatta ajatella näyttäytyvän niitä käyttävälle organisaatiolle monoliittisina, koska ne on hankittu tyypillisesti palveluina tai valmistuotteina, jolloin niiden sisäinen toteu- tustapa näkyy kaupungille lähinnä välillisesti esimerkiksi niiden suorituskyvyn riittä- vyyden tai jatkokehittämisen kustannusten kautta. Niiden hankinnassa voidaan toki pai- nottaa esimerkiksi tarvittavien rajapintojen olemassaoloa, jotta ne voidaan liittää toi- siinsa ja osaksi palvelukeskeistä arkkitehtuuria. Kaupungin palveluprosessien digitalisoinnin, yhteisten palvelujen tunnistamisen ja nii- den konsernin laajuisiksi teknisiksi palveluiksi toteuttamisen sekä tukiprosessien ja IT- infrastruktuurin standardoinnin voitaneen yksinkertaistetusti ajatella vaikuttavan kau- pungin informaatioteknologian kokonaisuuteen kuvan 30 mukaisesti. Kuva 30. Digitaalisuuden, yhteisten palvelujen ja standardoinnin vaikutusten hahmottelua Kaupungin prosesseja tukevien palvelujen ja sovellusten voidaan ajatella niitä ylläpitä- vän tahon tai esimerkiksi niiden muokattavuuden ja muutosten nopeuden kaltaisten ominaisuuksien perusteella jakautuvan digitaalisen ja perinteisen IT:n piiriin kuuluviksi. 91 Järjestäydyttäessä tukemaan palveluprosesseja digitaalisilla menetelmillä ja teknologi- oilla, voidaan ajatella näiden digitaalisten sovellusten osuuden kaikista sovelluksista kasvavan. Perinteisen IT:n piiriin kuuluvina sovelluksina säilyisivät edelleen muun mu- assa yleiset toimialariippumattomat sovellukset sekä tukiprosesseja tukevat sovellukset. Samoin yhteisten palvelujen tunnistamisen ja toteutuksen voidaan ajatella kasvattavan niiden määrää, ja siirtävän niihin yhteiseksi katsottua toiminnallisuutta prosessikohtai- sista palveluista ja sovelluksista. Sekä konsernin laajuisten palvelujen toteutus että IT- infrastruktuurin standardointi kasvattaisivat organisaation laajuisesti harmonisoidun ja standardoidun informaatioteknologian suhteellista osuutta. Lopputuloksena toimenpi- teille informaatioteknologian kokonaisuus muodostuisi yhä selkeämmin digitaalisten toimintatapojen ja teknologioiden muodostamasta, asiakasprosesseja tukevasta osasta, ja toisaalta standardoidusta ja harmonisoidusta, kustannustehokkuutta tavoittelevasta osasta. 5.3.2 Tavoitetila strategisen yhdenmukaisuuden näkökulmasta Turun kaupungin toiminnan nykytilan tarkastelu aloitettiin liiketoiminnan ja informaa- tioteknologian yhteensopivuutta tarkastelevan Henderssonin ja Venkatramanin (1993) esittämän strategisen yhdenmukaisuuden mallin kautta. Kaupungin tietohallintostrategi- assa esitettyjen sitä ohjaavien lähtötietojen perusteella todettiin liiketoiminnan ja IT:n yhdenmukaisuutta tavoiteltavan aloittamalla tarkastelu kaupungin ulkoisesta toimin- taympäristöstä ja etenemällä siitä kaupungin toiminnan sisäiseen toteutustapaan, lopulta tätä tukevan informaatioteknologian toteutustapaan. Tarkastellaan seuraavaksi, miltä kaupungin toimintatapa edellä kuvatussa tavoitetilassa näyttäisi strategisen yhdenmukaisuuden mallin kautta tarkasteltuna. Horlach ym. (2016) esittävät kohdassa 2.4.2 kuvatun mukaisesti bimodaalisen IT-toi- minnon aiheuttavan kaksi uutta vaatimusta strategisen yhdenmukaisuuden mallin sovel- tamiseen – vaatimuksen digitaalisen ja perinteisen IT-toiminnon yhteensovittamisesta (kuva 6) sekä kahden keskenään erilaisen toimintatavan huomioimisesta organisaation liiketoiminnan strategiassa ja operatiivisessa toiminnassa (kuva 7). Edellä kuvattuun Turun kaupungin toimintatapaan nähden tämän voidaan ajatella tarkoittavan esimer- kiksi, että kaupungin tietohallintostrategia erittelisi eri toimintatavoilla tuettavat osa-alu- 92 eet toiminnassa, ja kuvaisi molemmille toimintatavoille erilliset toimenpiteet, jolla näi- den alueiden tarpeisiin vastataan. Toisaalta kuvattaisiin, miten digitaalisen ja perinteisen IT-toiminnon tehtävät ja vastuut jakautuvat niiden kesken. Voitaneen myös ajatella, että tämän ylimääräisen suunnittelutyön oikeuttamiseksi eril- listen toimintatapojen tulisi kyetä tukemaan (liike-)toimintaa sen vaatimuksiin entistä täsmällisemmin vastaten. Tarkastellaan tähän liittyen tavoitetilan kuvauksen lopuksi, miten bimodaaliseen informaatioteknologian hyödyntämiseen perustuva toimintatapa vastaa tietohallintostrategiassa tunnistettuihin riskikartoituksen tuloksiin. 5.3.3 Tavoitetila tietohallintostrategian näkökulmasta Turun kaupungin viimeisimmässä tietohallintostrategiassa riskeiksi ja haasteiksi tunnis- tettiin henkilöresurssien määrä ja osaaminen, vaatimusmäärittelyjen puutteellisuus pro- jekteissa, kokonaisarkkitehtuurin irrallisuus kaupungin johtamisesta ja prosesseista, IT- palvelujen kykyyn asiakastarpeisiin vastaamiseen, yleiseen kehittämispalvelujen kysyn- nän suureen määrään. IT-palvelujen toimintamalli. Selkeimmin bimodaalisen toimintatavan voidaan katsoa vastaavan IT-palvelujen nykyiseen toimintamalliin liittyvään haasteeseen. Turun kaupungin tietohallintostrategiassa todetaan nykyisen mallin pohjautuvan keskit- tämiseen ja kustannustehokkuuden tavoitteluun, ”mikä saattaa johtaa joustavuuden vä- henemiseen asiakkaiden näkökulmasta.” Lisäksi todetaan tarpeelliseksi pohtia ”tapoja vastata paremmin asiakkaiden yksilöllisiinkin kehittämistarpeisiin silloin kun ne ovat kaupungin strategian mukaisesti perusteltuja.” (Turun kaupunki, 2017) Haasteeseen voidaan bimodaalista toimintatapaa soveltaen vastata tunnistamalla ekspli- siittisesti, mitkä toiminnan osa-alueet tarvitsevat yksilöllistä toiminnan tukemista, ja missä toimintaa on tarkoituksenmukaisinta tukea kustannustehokkaalla ja keskitetyllä IT-toiminnolla. Henkilöresurssien määrä ja osaaminen. Turun kaupungin tietohallintostrategia toteaa, etteivät henkilöresurssien määrä ja osaaminen eivät kohtaa kaikilta osin nykyistä ja en- nakoitua tarvetta. Erityisesti haasteen katsottiin kohdistuvan projektipäälliköiden ja ko- konaisarkkitehtuuriasiantuntijoiden resursointiin. (Turun kaupunki, 2017) 93 Esitetyn toimintamallin voidaan katsoa osin vastaavan henkilöresurssien määrään ja osaamiseen liittyvään haasteeseen. Mallissa yksittäisiä prosesseja tukevalle digitaali- selle kehittämiselle annetaan selkeät rajat ja periaatteet, joiden puitteissa palveluja ke- hittävät tiimit ja toiminnan palvelun omistaja voivat toimia autonomisesti. Kohdista- malla kokonaisarkkitehtuuriin liittyvää työmäärää yhä selkeämmin konsernitasoisten yhteisten palvelujen ja kyvykkyyksien ohjaamiseen yksittäisiin asiakasprosesseihin liit- tyvän arkkitehtuurityön sijasta, voidaan ajatella vähennettävän kokonaisarkkitehtuuri- työhön käytettävää työmäärää. Lähellä toimintaa tapahtuva digitaalisen informaatioteknologian ja myös toiminnan pal- velujen kehittäminen aikaansaa epäilemättä myös uusia resurssi- ja osaamistarpeita. Olisi tutkittava tarkemmin, vähentäisikö vai lisäisikö selkeämpi jako yksilöllisten tar- peiden toteutuksen ja toisaalta toimintatapojen ja IT:n standardoinnin välillä resurssien tarvetta. Tavoitetilassa esitetyn toimintatavan voidaan katsoa vastaavan myös Turun kaupungin tietohallintostrategiassa tunnistettuun kokonaisarkkitehtuurin irrallisuuteen kaupun- gin johtamisesta ja prosesseista. Kun kokonaisarkkitehtuuritoiminto välttyy edellä ku- vatusti ohjaamasta ja ottamasta kantaa yksittäisiä asiakasprosesseja tukevaan digitaali- seen kehittämiseen, se voi keskittyä tiiviimmin kaupungin strategisen tason tavoitteiden toteuttamiseen sekä mm. kansallisten palvelujen hyödyntämiseen ja konserninlaajuisten kyvykkyyksien rakentamiseen. Lisäksi, jos digitaalinen kehittäminen järjestetään suu- relta osin projektitoiminnan sijasta jatkuvaksi toiminnaksi, vähenee kehittämismallin kautta ohjattavien projektien määrä, mikä auttaa osaltaan vähentämään IT-toiminnon kehittämispalveluihin kohdistuvaa kysyntää ja mahdollisesti auttaa noudattamaan kehittämismallia paremmin jäljelle jäävissä informaatioteknologiaan liittyvissä pro- jekteissa. Yhteenvetona tavoitetilan voidaan todeta vastaavan viidestä tietohallintostrategiassa tunnistetusta riskistä ja haasteesta taulukon 5 mukaisesti täysin kahteen ja osittain kol- meen. 94 Taulukko 5. Tavoitetilan ja tietohallintostrategian riskien ja haasteiden vastaavuus Tietohallintostrategiassa tunnistettu riski tai haaste Esitetyn tavoitetilan vastaaminen riskiin tai haasteeseen Henkilöresurssien määrä ja osaaminen Osittain Vaatimusmäärittelyjen puutteellisuus projekteissa Osittain Kokonaisarkkitehtuurin irrallisuus kaupungin johtamisesta ja prosesseista Kyllä IT-palvelujen kyky asiakastarpeisiin vastaamiseen Kyllä IT-toiminnon kehittämispalvelujen kysynnän määrä Osittain Tavoitetilan kuvaus on esittänyt, millä tavoin mitäkin toiminnan osa-aluetta tulisi tukea informaatioteknologialla. Se ei ole kuitenkaan vielä täsmentänyt, millaisilla arkkitehtuu- rityyleillä eri alueiden informaatioteknologiaratkaisut tulisi toteuttaa. Tarkastellaan seu- raavaksi osa-alueille tarkoituksenmukaisia arkkitehtuurityylejä. 5.3.4 Eri arkkitehtuurityylit tavoitetilassa Edellä tunnistettiin Turun kaupungin toiminnasta osa-alueita, joiden tukemisessa infor- maatioteknologialla esitettiin tavoitetilassa noudatettavan erilaisia toimintatapoja. Lä- hellä palveluprosessien asiakasrajapintaa esitettiin toimittavan prosessin tarpeisiin tar- koin vastaavilla ja ketterillä digikehittämisen menetelmillä, kun taas kauempana asiak- kaasta oleva toiminta, kuten tukiprosessit voitaisiin toteuttaa kustannustehokkaasti har- monisoimalla ja standardoimalla toimintaa ja sitä tukevia järjestelmiä. Näiden välillä voidaan ajatella olevan konserninlaajuisten yhteisten kyvykkyyksien toteutuksen, joka tukee digitaalisia palveluja ja toisaalta yhdistää ne esimerkiksi perinteisiin perusjärjes- telmiin. 95 Näiden toiminnan osa-alueiden tarvitsemien järjestelmien teknistä toteutustapaa ja niissä pääasiallisesti noudatettavaa arkkitehtuurityyliä on sivuttu jo aiemmin, mutta tar- kastellaan vielä järjestelmällisesti, millaiset tekniset ratkaisut tukevat parhaiten mitäkin osa-aluetta. Samalla tarkastellaan viimeisenä tutkimuskysymyksenä: miten mikropalveluarkkiteh- tuuri soveltuu digitaalisen informaatioteknologian toteutustavaksi? Taulukossa 6 on esitetty arvio eri arkkitehtuurityylien (ja niiden yhteydessä tyypillisesti sovellettavien teknisten toteutustapojen) soveltuvuudesta toiminnan eri osa-alueille. Tarkastelussa osa-alueina käytetään Silviuksen (2007) esittämää jaottelua yksinkertais- tettuna. 96 Taulukko 6. Eri osa-alueiden toteutustapojen arviontia. Digitaaliset palvelut Konsernin laajuiset palvelut Standardoidut sovellukset ja palvelut Monoliittinen arkkitehtuuri +/- Soveltuu jos ymmärre- tään yksittäisten palvelu- jen toteutustapana, ei alustana. - Ei tue muunneltavuuden ja integroitavuuden ta- voitteita. + Tarkoituksenmukaista käyttää valmissovelluk- sia ja palveluita, jotka näyttäytyvät monoliitti- sina. Palvelukeskeinen arkkitehtuuri - Tyypilliset tekniset to- teutustavat ja työskente- lymenetelmät eivät so- vellu. + Toimii hyvin integroin- nissa ja asiakasrajapintaa pysyvämpien palvelujen toteutuksessa. Samat tek- nologiat kuin kansalli- sissa palveluissa. +/- Ei tarkoituksenmukainen valmistuotteiden korvaa- jana, mutta tukee niiden integrointia. Mikropalvelu- arkkitehtuuri + Soveltuu työskentelyta- pojen ja suunnitteluperi- aatteiden osalta. Toi- saalta esimerkiksi osaa- miseen liittyviä haasteita. +/- Toimii teknisenä toteu- tustapana, mutta esimer- kiksi tyypilliset työsken- telymenetelmät eivät kai- kilta osin sovellu. - Ei kustannustehokas to- teutustapa standar- doiduissa prosesseissa tai valmistuotteiden korvaa- jana. Jo työn johdannossa todettiin digitaalisten palvelujen yhteen monoliittiseen asioin- tialustaan tai -sovellukseen perustuvan toteutustavan olevan osoittautuneen haasteel- liseksi kunnan toimintaympäristössä. Koska kunta tarjoaa useita satoja pääosin lakisää- teisiä ja osin itse valitsemiaan palveluja, jotka eroavat sisällöiltään merkittävästi, vaadi- taan tällaiselta asiointialustalta huomattavaa muunneltavuutta. Monoliittisen ratkaisuta- van ongelma korostuu, kun palveluprosesseja pyritään kehittämään ja tukemaan infor- maatioteknologialla muiltakin kuin niiden välittömien asiakkaalle näkyvien tehtävien osalta. Toisaalta toteutustapojen arvioinnissa korostuu monoliittisen arkkitehtuurin ”määrittely” mikropalvelujen yhteydessä lähinnä palvelukeskeisen ja mikropalveluark- kitehtuurin vastakohtana. 97 Jos kaupungin palveluja oletetaan toteutettavaksi laajan alustan sijasta yksittäisinä so- velluksina, ja näiden sovellusten monoliittisissa toteutuksissa noudatetaan soveltuvilta osin muiden arkkitehtuurityylien yhteydessä esitettyjä yleisesti hyviksi tunnistettuja suunnittelupiirteitä, voidaan monoliittisen toteutuksen katsoa soveltuvan digitaalisten palvelujen toteutukseen. Fowler (2015b) esittääkin mikropalvelujen yhteydessä sovel- lettavaksi toteutustapaa, jossa sovellukset toteutetaan ensin monoliittisiksi kokonaisuuk- siksi, ja pilkotaan tarvittaessa useiksi mikropalveluiksi. Oikeaoppisiin teknisiin mikropalveluihin perustumisen sijasta digitaalisten palvelujen kehityksessä keskeisimpänä noudatettavana käytäntönä voidaan pitää mikropalveluihin liittyviä toimintatapoja, joissa poikkitoiminnalliset tiimit kehittävät (liike-)toiminnan kyvykkyyttä tukevaa teknistä palvelua läheisessä yhteistyössä toiminnan kanssa. Tämä ja muut sovellettavissa olevat mikropalveluihin liitetyt toimintatavat tukevat digikehittä- mistä, vaikka kehitettävän palvelun sisäinen toteutustapa olisi monoliittinen. Mikropalveluihin liitettävä helppo skaalautuvuus voidaan katsoa mikropalvelujen muita ominaisuuksia vähemmän merkittäväksi, koska esimerkiksi kansainväliseen kuluttajille tarkoitettuun palveluun verrattuna kaupungin palvelujen kysynnällä voidaan katsoa ole- van pienempi ennakoitavissa oleva vaihteluväli. Mikropalvelujen soveltamiseen liittyy myös haasteita. Niiden voidaan katsoa liittyvän erityisesti mikropalveluihin perustuvan arkkitehtuurin suunnittelun ja toteutuksen vaati- maan osaamiseen sekä yksittäisiin palveluihin hajautettujen tietojen eheyteen ja yhdis- teltävyyteen. Konserninlaajuisten palvelujen toteutuksessa tarkoituksenmukaisimmaksi toteutusta- vaksi voidaan katsoa palvelukeskeinen arkkitehtuuri, jonka yhteydessä käytettävät tuot- teet, standardit ja teknologiat mahdollistavat palvelujen yhdenmukaisen julkaisun ja nii- den keskinäisen integroinnin. Koska yhteisiä palveluja käytetään jo niiden määritelmän- kin mukaan useiden prosessien yhteydessä, muodostuu niihin runsaasti riippuvuuksia. Tästä johtuen niiden elinkaaren aikana tehtävien muutosten tulee olla hallittuja. Konser- ninlaajuisten palvelujen yhteydessä voidaan julkaista saumattomasti käytettäväksi myös kansallisia palveluja. Niiden voidaan ajatella muodostavan hitaasti muuttuvan ”kivija- lan”, jonka päälle muokattavia ja kokeellisia asiakasprosesseja tukevia mikropalveluja voidaan toteuttaa. 98 Eräänä huomiona palvelukeskeiseen arkkitehtuuriin liittyen voidaan todeta merkittävän osan arkkitehtuurityyliä koskevasta kritiikistä kohdistuvan sen toteutustapaan, kuten monimutkaisiin web service -protokolliin ja niitä toteuttaviin ohjelmistoihin. Tästä joh- tuen voisi olla tarkoituksenmukaista tutkia mahdollisuutta toteuttaa konsernin sisäisiä yhteisiä palveluja noudattaen palvelukeskeisen arkkitehtuurin suunnitteluperiaatteita, mutta käyttäen toteutuksessa kevyempiä esimerkiksi mikropalvelujen yhteydessä usein käytettäviä protokollia ja tuotteita. Standardoidut sovellukset ja palvelut voidaan katsoa tarkoituksenmukaiseksi toteut- taa valmistuotteilla ja esimerkiksi pilvipalveluilla. Samalla näiden alueiden prosesseja tulisi standardoida ja harmonisoida, ja tarvittaessa sopeuttaa niitä valittujen keskeisim- pien järjestelmien mukaisiksi. Edellä kuvatusti valmistuotteet näyttäytyvät organisaatiolle yleensä monoliittisina, vaikka niiden sisäinen toteutustapa perustuisikin esimerkiksi mikropalveluihin. Yhteen- vetona edellä kuvatusta mikropalveluja voitaneen pitää parhaiten digitaalisten palvelu- jen toteuttamiseen soveltuvana toteutustapana, palvelukeskeisen arkkitehtuurin soveltu- van konsernin yhteisten palvelujen toteuttamiseen (ja kansallisiin palveluihin liittymi- seen), ja valmistuotteiden ja valmiiden palvelujen monoliittiseksi katsottavan toteutusta- van sopivan standardoitujen prosessien tukemiseen (kuva 31). Kuva 31. Näkemys eri osa-alueiden tarkoituksenmukaisimmista toteutustavoista. 99 5.4 Yhteenveto luvusta Tässä luvussa tarkasteltiin digitaaliseen ja perinteiseen toimintatapaan perustuvan eli bi- modaalisen IT-toiminnon mallin soveltamista Turun kaupungin toimintaympäristössä. Erityistä huomiota kiinnitettiin mikropalveluarkkitehtuurin hyödyntämiseen digitaalisen informaatioteknologian toteutuksessa. Luvun alussa tarkasteltiin Turun kaupungin nykytilaa, ja arvioitiin, kohdistuuko siihen kahdenlaisia vaatimuksia, joiden toteuttamiseen bimodaalinen toimintatapa voisi olla tarkoituksenmukainen. Tarkastelu aloitettiin Henderssonin ja Venkatramanin (1993) lii- ketoiminnan ja informaatioteknologian yhdenmukaisuutta tarkastelevan mallin kautta. Kaupungin informaatioteknologian hyödyntämistä ja kehittämistä ohjaavan tietohallin- tostrategian perusteella liiketoiminnan ja IT:n yhdenmukaisuutta todettiin tavoiteltavan johtamalla kaupungin ulkoisen toimintaympäristön perusteella sen toiminnan sisäinen toteutustapa, ja näistä IT-toiminnon toteutustapa. Lisäksi kaupungin toimintaan todettiin tietohallintostrategian sisällön perusteella kohdistuvan sekä sen toiminnan ketterän ja räätälöidyn ”yksilöllisillä” informaatioteknologian ratkaisuilla tukemisen että toisaalta standardoinnin ja kustannustehokkuuden vaatimuksia. 100 6 Yhteenveto Tämän työn tarkoituksena oli syventää ymmärrystä siitä, miten kokeellinen ja ketterä digitaalinen informaatioteknologia sekä vakauteen ja toimintavarmuuteen pyrkivä perin- teinen IT muodostavat organisaation toimintaa tukevan tarkoituksenmukaisen ja yhte- näisen kokonaisuuden. Tarkastelussa kiinnitettiin erityistä huomiota mikropalveluarkki- tehtuurin soveltuvuuteen tämän informaatioteknologian digitaalisen osuuden toteutusta- pana. Tarkasteltavana sovelluskohteena bimodaalisen IT-toiminnon mallille ja mikro- palveluarkkitehtuurille käytettiin Turun kaupungin toimintaympäristöä. Työ toimi sa- malla jatkona aiemmin aloitetulle mikropalvelujen hyödyntämisestä ja digitaalisten pal- velujen toteutuksen tarkoituksenmukaista toteutustapaa koskevalle selvitystyölle. 6.1 Aineistot Työssä tarkasteltiin niin valittuja aiheeseen liittyviä yleisluontoisia teoreettisia viiteke- hyksiä, lähempänä käytännön kokemusten dokumentointia olevia tieteellisiä artikkeleja että joidenkin aihepiirien osalta tieteellisen tiedon sijasta toimialan käytännön kokemuk- siin perustuvia kuvauksia. Kaikkien näiden tietolähteiden kuvauksia pyrittiin sovelta- maan Turun kaupungin toiminnan viitekehyksessä, ja hahmottamaan niiden perusteella tarkoituksenmukainen toteutustapa digitaaliselle kehittämiselle ja mikropalvelujen hyö- dyntämiselle kaupunkiorganisaatiossa. Henderssonin ja Venkatramanin (1993) malli kuvaa organisaatiota ja sen IT-toimintoa hyvin yleisellä tasolla. Tämä yleisluontoisuus tekee siitä varsin intuitiivisen ja järkeen- käyvän – on helppoa allekirjoittaa väite siitä, että organisaation tulee sovittaa sisäinen toimintatapansa ulkoiseen ympäristöönsä ja toisaalta sovitettava käyttämänsä informaa- tioteknologia ja toiminta tarkoituksenmukaiseksi kokonaisuudeksi. Mallia sovellettaessa sen voitaisiin ajatella sisältävän harmillisen niukasti käytännönläheisiä työvälineitä konkreettisen organisaation toiminnan tarkasteluun. Toisaalta juuri sen yleisluonteisuus mahdollistaa sen käytön viitekehyksenä arvioitaessa kaksikymmentä vuotta mallin jul- kaisun jälkeen yleistyneiden mikropalvelujen tarkoituksenmukaisuutta. Keskeisiä tieteellisiä lähteitä digitaalisesta ja perinteisestä IT:stä koostuvan toimintata- van tarkastelulle olivat myös Horlach ym. (2016) ja Haffke ym. (2017a). Näistä Horlach ym. 2016) tarkastelevat kirjallisuuskatsauksena bimodaalisuutta käsitteleviä – pääosin 101 muita kuin tieteellisiä – kuvauksia. Haffken ym. (2017a) kuvaus taas perustuu yhdek- säntoista eurooppalaisen yrityksen tarkasteluun. Molemmat artikkelit kuvaavat ansiok- kaasti vähän tutkittua bimodaalisen IT:n käsitettä ja toimintatavan mukaista organisaa- tion IT-toiminnon järjestämistä eri yrityksissä, mutta niitä täydentämään tarvittaisiin kenties tietoa myös digitaalisella ja perinteisellä tavalla tuettavaksi soveltuvan liiketoi- minnan tunnistamiseksi. Mikropalvelujen tarkastelussa tieteellisiä lähteitä hyödyllisemmäksi osoittautuivat usein käytännön kokemuksia kuvaavat blogitekstit ja muut vastaavat ammatilliset lähteet. Ai- hetta koskevat tieteelliset artikkelit (mm. lähteenä käytetty Strîmbei ym., 2015) viittaa- vat myös näihin käytännön kokemuksia kuvaaviin lähteisiin. Tämän voidaan olettaa johtuvan aihepiirin uutuudesta ja kypsymättömyydestä, mikä toisaalta teki siitä kiinnos- tavan tarkastelukohteen tälle työlle. 6.2 Johtopäätökset Työn tavoitteena oli kasvattaa ymmärrystä digitaalisen ja perinteisen IT:n tarkoituksen- mukaisista toteutustavoista ja siitä, miten mikropalveluarkkitehtuuri soveltuu digitaali- sen informaatioteknologian yhteydessä käytettäväksi. Kahdella tavalla toimivan IT:n voidaan tämän tarkastelun perusteella katsoa olevan tar- koituksenmukainen toimintatapa Turun kaupungin kaltaisille vakiintuneille organisaati- oille, joiden toisaalta tulee pyrkiä hyödyntämään informaatioteknologian uusia mahdol- lisuuksia ja vastaamaan niistä aiheutuvaan kilpailuun, ja samanaikaisesti pystyä ylläpi- tämään ja saamaan hyötyä nykyisistä toimintatavoistaan ja IT-järjestelmistään. Vaikka kilpailun ja kilpailuedun käsitteet eivät ehkä kaupungin toiminnan puitteissa ole yhtä suoraviivaisesti tunnistettavissa kuin yrityksiä tarkasteltaessa, joutuvat nekin vastaa- maan toimintaympäristössään tapahtuviin digitaalisuuteen liittyviin muutoksiin. Bimodaalisuuden elinkaarta, eli siihen siirtymistä ja siitä mahdollista palaamista tarkas- teltaessa Haffke ym. (2017a) esittävät havaintojensa perusteella, että kahdella tavalla toimiminen on organisaatioille vain välivaihe, josta ne palaavat yhteen toimintatapaan. Tällöin organisaatio toimii aluksi rinnakkain sekä ketteryyttä ja kokeellisuutta tukevassa digitaalisessa tilassa ja perinteisessä, vakautta ja ennakoitavuutta korostavassa tilassa. Lopulta tästä kahtiajakautuneesta toimintatavasta esitetään siirryttävän kokonaan digi- taaliseen toimintatapaan. Toimintatapojen yhdistäminen herättää ajatuksen siitä, voiko 102 tällaista lopullista toimintatapaa olla? Vaikka organisaation hyödyntämät ja sen toimin- taan vaikuttavat teknologiat ja toimintatavat ajan kuluessa muuttuvat, lienee aiheellista olettaa, että uusia teknologioita ja toimintatapoja korvaamaan on aina tulossa vielä uu- dempia. Edellä kuvatun mukaisesti bimodaalisuutta ei välttämättä tule ajatella tilapäi- senä toimintatapana, vaan jopa pysyvänä mekanismina, jolla organisaatio sekä hyödyn- tää sekä vakiintunutta toimintaansa ja sitä tukevaan informaatioteknologiaan jo tekemi- ään investointeja, ja samalla sopeutuu toimintaympäristössään tapahtuneisiin muutok- siin. Kahden rinnakkaisen toimintatavan tarkastelun lisäksi työssä tutkittiin mikropalveluark- kitehtuurin soveltuvuutta digitaalisen informaatioteknologian toteutustavaksi. Keskei- nen havainto tämän tarkastelun yhteydessä oli, että eri arkkitehtuurityyleihin näyttää liittyvän niitä noudattavien järjestelmien teknisten toteutustapojen piirteiden lisäksi myös työtapoihin ja organisoitumiseen liittyviä piirteitä. Toisin sanoen ei siis näytä ole- van tarkoituksenmukaista puhua esimerkiksi mikropalveluihin perustuvan ohjelmisto- arkkitehtuurin käytöstä jollakin (liike-)toiminnan osa-alueella, jos samalla ei tarkastella mikropalveluihin tyypillisesti liittyvien käytäntöjen ja työtapojen käyttöä. Tämä teki eri arkkitehtuurityylien soveltamiskelpoisuuden tarkastelun Turun kaupungin toimintaym- päristössä haastavaksi, ja ohjelmistoarkkitehtuurityylien lisäksi arviointi koskee miltei väistämättä myös niiden yhteydessä tyypillisesti sovellettavia toimintatapoja. Tähänkin nähden voidaan nähdä mielenkiintoisena lopputuloksena, että kahdesta toi- mintatavasta lähtenyt tarkastelu päätyy ehdottamaan kolmen arkkitehtuurityylin sovelta- mista toiminnan eri osa-alueilla. Jos bimodaalisen informaatioteknologian malli jakaa toiminnan digitaaliseen ja perinteiseen osuuteen, näyttää Turun kaupungin toimintaym- päristöä ja järjestäytymistapaa huomioiva tarkastelu vaativan vielä perinteisen IT:n toi- mintatavan kahtia jakamista – tarkoituksenmukaisimmaksi tavaksi jäsentää kaupungin toiminnan tavoitetilaa osoittautui jakaa se digitaalisen IT:n, palvelukeskeiseen arkkiteh- tuuriin perustuvan yhteisten palvelujen kokonaisuuden ja monoliittisena arkkitehtuurina näyttäytyvän standardoidun IT:n osa-alueisiin. 6.3 Rajoitteet ja jatkotutkimuskohteet Tutkimuksen toteuttamiseen tunnistettiin liittyvän sekä valituista menetelmistä aiheutu- neita että aineiston keräämiseen tehdyistä rajauksista aiheutuneita rajoitteita. 103 Tutkimus toteutettiin tapaustutkimuksena, joka hyödynsi sekä julkisia tietolähteitä että etnografista aineistonkeruuta. Eriksson ja Koistinen (2005) esittävät tapaustutkimuksiin liittyvän menetelmänä yleisesti seuraavia haasteita: - teoreettisten käsitteiden tai älyllisen rikkauden puuttuminen, - epäselvä tapauksen määrittely, - epäselvä tai liian yleinen tutkimuskysymyksen määrittely, - puutteellinen aineiston analysointi, näyttö ja yhteyksien häviäminen, - heikot yhteydet aikaisempaan tutkimukseen, - mitäänsanomaton raportointi ja - kontribuution vähäinen pohdinta. Kolmeen ensimmäiseen haasteeseen pyrittiin vastaamaan määrittelemällä käytetyt teo- reettiset käsitteet ja viitekehykset, tarkasteltava tapaus sekä tutkimuskysymys mahdolli- simman selkeästi ja yksikäsitteisesti. Erityisesti teoreettisten käsitteiden ja viitekehysten osalta pyrittiin liittämään alun perin toisistaan irralliset eri aihepiirien viitekehykset toi- siinsa tarkastelemalla organisaation strategiasta tietojärjestelmien toteutustapoihin ylet- tyvää kokonaisarkkitehtuurin viitekehystä. Tämän voidaan katsoa tukevan myös tapaus- tutkimuksen yhdistymistä aiempaan samoja teemoja ja kysymyksiä tarkastelevaan tutki- mukseen. Aihepiireistä ei suoritettu järjestelmällistä kirjallisuuskartoitusta, eikä itse tut- kimuksen hakuprosessia kuvattu. Eriksson ja Koistinen (2005) esittävät, että tämän tutkimuksen kaltaisen yhteen tapauk- seen keskittyvän intensiivisen tapaustutkimuksen tarkoituksena ”ei ole niinkään tehdä tapausta koskevia yleistyksiä, vaan selvittää, millä logiikalla juuri tämä ainutlaatuinen ja erityinen tapaus toimii.” Tutkimus tuotti ensisijaisesti tietoa valittujen mallien soveltu- misesta Turun kaupungin toimintaan, minkä tarkastelun tuloksena oli kuvaus kaupun- gille luodusta digikehittämisen toimintamallista. Se siis lisäsi ymmärrystä tutkimuksessa tarkastellusta tapauksesta ja tuotti siitä uutta syvempää tietoa, mutta ei ensisijaisesti tuottanut uusia muissa tapauksissa sovellettavia yleistyksiä. Tästä huolimatta muun mu- assa yhteisistä lakisääteisistä tehtävistä johtuen tutkimuksessa tuotettujen tulosten ja johtopäätösten voidaan ajatella palvelevan myös muiden kaupunkien toimintaa. Keskeiseksi aineiston keräämiseen liittyväksi rajoitteeksi – edellä kuvatun järjestelmäl- lisen kirjallisuuskartoituksen puuttumisen lisäksi – tutkimukselle voidaan tunnistaa eri- tyisesti Turun kaupungin monimutkainen toimintaympäristö sekä tietojärjestelmien lu- kumäärä. Toiminnan laajuudesta johtuen sekä kaupungin toimintoja ja prosesseja että 104 tietojärjestelmiä käsiteltiin yksittäisten kohteiden tarkastelun sijasta ryhminä. Toisaalta, koska tutkimuksen tarkoituksena oli muodostaa kaupungin toimintaympäristöön sovi- tettu malli, olisi jonkinlainen yksityiskohtien abstrahointi ollut tarpeellista, vaikka pro- sesseja ja järjestelmiä olisi tarkasteltu yksittäin. Tutkimuksen aihetta voitaisiin jatkossa tutkia myös kvantitatiivisilla menetelmillä. Bi- modaalisen IT-toiminnon tarvetta voitaisiin selvittää kyselytutkimuksella, joka käsitte- lisi kuntien eri toiminnoista niiden IT-toiminnolle aiheutuvia erilaisia vaatimuksia. Tämä auttaisi todentamaan, tulisiko eri toimintoja tukea erilaisilla toimintatavoilla, ja vastaavatko bimodaalisen IT:n mallin yhteydessä esitetyt kaksi tai tämän tutkimuksen tuloksena esitetyt kolme erilaista toimintatapaa näihin vaatimuksiin. Samoin kyselytut- kimuksella voitaisiin selvittää eri arkkitehtuurityylien käyttöä ja soveltuvuutta erilaisia vaatimuksia toteuttavien järjestelmien perustana. Mikropalveluarkkitehtuuria ja DevOps-toimintatapaa koskevaa tieteellistä tutkimusta todettiin ylipäätään olevan melko niukasti, oletettavasti aihepiirin suhteellisesta uu- tuudesta ja mikropalvelujen toteutustekniikoiden nopeasta kehittymisestä johtuen. Esi- merkiksi mikropalveluista koostuvien järjestelmäkokonaisuuksien tietojen hallinta ja tietoturva tulevat oletettavasti vaatimaan uutta tutkimusta. 105 LÄHTEET Aron, D. & McDonald, M. (2013). Taming the Digital Dragon: The 2014 CIO Agenda http://www.gartner.com/imagesrv/cio/pdf/cio_agenda_insights2014.pdf. (viitattu 21.4.2018) Baker J. & Jones J. (2008). A Theoretical Framework for Sustained Strategic Alignment and an Agenda for Research. All Sprouts Content. 222 Balalaie, A., Heydarnoori, A., & Jamshidi, P. (2016). Microservices architecture enables devops: Migration to a cloud-native architecture. IEEE Software, 33(3), 42-52. Bayley N. & Shacklady J. (2015). Gearing Up for Growth Using Multi-speed IT https://www.accenture.com/_acnmedia/Accenture/Conversion- Assets/DotCom/Documents/Global/PDF/Technology_10/Accenture-Multi-Speed-IT- PoV.pdf (viitattu 10.11.2017) Beimborn, D., Joachim, N., Schlosser, F., & Streicher, B. (2009). The role of IT/business alignm ent for achieving SOA business value-proposing a research model. AMCIS 2009 Proceedings, 335. Bieberstein, N., Bose, S., Walker, L., & Lynch, A. (2005). Impact of service-oriented architecture on enterprise systems, organizational structures, and individuals. IBM systems journal, 44(4), 691-708. Bitner, M. J., Ostrom, A. L., & Morgan, F. N. (2008). Service blueprinting: a practical technique for service innovation. California management review, 50(3), 66-94. Boerner, R. & Goeken, M. (2009). Service identification in SOA governance literature review and implications for a new method. In Digital Ecosystems and Technologies, 2009. DEST'09. 3rd IEEE International Conference on, 588-593. Cameron, B. H., & McMillan, E. (2013). Analyzing the current trends in enterprise architecture frameworks. Journal of Enterprise Architecture, 9(1), 60-71. Dragoni, N., Giallorenzo, S., Lafuente, A. L., Mazzara, M., Montesi, F., Mustafin, R., & Safina, L. (2017). Microservices: yesterday, today, and tomorrow. In Present and Ulterior Software Engineering, 195-216. Eriksson, P., & Koistinen, K. (2014). Monenlainen tapaustutkimus. Helsinki: Kuluttajatutkimuskeskus. 106 Erl, T. (2008). Soa: Principles of Service Design. Upper Saddle River: Prentice Hall. Fowler, M. (2013). Continuous Delivery https://martinfowler.com/bliki/ContinuousDelivery.html (viitattu 1.1.2018) Fowler, M. (2006). Continuous Integration https://martinfowler.com/bliki/ContinuousDelivery.html (viitattu 1.1.2018) Fowler, M. (2015a). Microservice Premium https://martinfowler.com/bliki/MicroservicePremium.html (viitattu 5.1.2018) Fowler, M. (2015b). Monolith First https://martinfowler.com/bliki/MonolithFirst.html (viitattu 5.1.2018) Gartner (2017). IT Glossary – Bimodal IT. https://www.gartner.com/it- glossary/bimodal/ (viitattu 16.11.2017) IEEE (2000). IEEE Recommended Practice for Architectural Description of Software- Intensive Systems. IEEE Standard 1471-2000, 2000. Haffke, I., Kalgovas B. & Benlian A. (2017a). The Transformative Role of Bimodal IT in an Era of Digital Business. Proceedings of the 50th Hawaii International Conference on System Sciences, Hawaii, 5460-5469. Haffke, I., Kalgovas, B., & Benlian, A. (2017b). Options for Transforming the IT Function Using Bimodal IT. MIS Quarterly Executive, 16(2). Hendersson, J. C. & Venkatraman N. (1993). Strategic Alignment: Leveraging information technology for transforming organizations. IBM systems journal, 32(1), 472-484. Herrera-Izquierdo, L., & Grob, M. (2017). A performance evaluation between Docker container and Virtual Machines in cloud computing architectures. Maskana, 8, 127-133. Horlach, B., Drews P, & Schirmer I. (2016). Bimodal IT: Business-IT alignment in the age of digital transformation. Multikonferenz Wirtschaftsinformatik (MKWI), 1417- 1428. JUHTA (2017a). JHS-suositukset. http://www.jhs-suositukset.fi/web/guest (viitattu 28.11.2017) JUHTA (2017b). JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen. http://docs.jhs-suositukset.fi/jhs-suositukset/JHS179/JHS179.pdf (viitattu 28.11.2017) 107 Hammersley, M., & Atkinson, P. (1983). Ethnography: Principles in practice. London and New York: Tavistock Publications. Kirschner, B. & Kenney, P. (2014). Lessons from the App Masters. http://pages.apigee.com/rs/apigee/images/apigee-ebook-app-masters-pdf.pd (viitattu 12.12.2017) Koskimies K. & Mikkonen T. (2005). Ohjelmistoarkkitehtuurit. Jyväskylä: Talentum Media Oy. Kunnan johtamisen viitearkkitehtuuri. (2016). Helsinki: Suomen Kuntaliitto ry. Legner, C., & Heutschi, R. (2007). SOA adoption in practice-findings from early SOA implementations. In Proceedings of the 5th European conference on information systems, st. Gallen, Switzerland. Lewis J. & Fowler M. (2014). Microservices. https://martinfowler.com/articles/microservices.html (viitattu 12.2.2018) Mesenbourg, T.L. (2001). Measuring the Digital Economy. U.S. Bureau of the Census. Moore, G. (2011) Systems of Engagement and The Future of Enterprise IT: A Sea Change in Enterprise IT. AIIM, Silver Spring, Maryland. Märijärvi ym. (2016) The Cookbook for Successful Internal Startups. DIGILE and N4S. Nam, T. & Pardo, T. A. (2011, June). Conceptualizing smart city with dimensions of technology, people, and institutions. In Proceedings of the 12th annual international digital government research conference: digital government innovation in challenging times (pp. 282-291). ACM. Niemi, E. (2008). Enterprise architecture benefits: Perceptions from literature and practice. Tietotekniikan tutkimusinstituutin julkaisuja, 1236-1615; 18. Papazoglou, M. P., Traverso, P., Dustdar, S., & Leymann, F. (2007). Service-oriented computing: State of the art and research challenges. Computer, 40(11). Ross, J. W., Weill, P., & Robertson, D. (2006). Enterprise architecture as strategy: Creating a foundation for business execution. Boston, Massachusetts: Harvard Business School Press. Namiot, D., & Sneps-Sneppe, M. (2014). On micro-services architecture. International Journal of Open Information Technologies, 2(9), 24-27. 108 Silvius, A. G. (2007, January). Business & IT Alignment in theory and practice. In System Sciences, 2007. HICSS 2007. 40th Annual Hawaii International Conference on (pp. 211b-211b). IEEE. Strîmbei, C., Dospinescu, O., Strainu, R. M., & Nistor, A. (2015). Software Architectures-Present and Visions. Informatica Economica, 19(4), 13. Spewak, S. (1992). Enterprise ArchitecturePlanning: Developing a Blueprint for Data, Applications, and Technology. New York, NY: John Wiley & Sons. Spewak, S. & Tiemann, M. (2006). Updating the enterprise architecture planning model. Journal of Enterprise Architecture, 2(2), 11-19. Taylor, R. N., Medvidovic, N. & Dashofy E. M. (2010). Software Architecture: Foundations, Theory and Practice. John Wiley & Sons. The Open Group. (2007). Service-Oriented Architecture (SOA). https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?catalogno=w 074 (viitattu 23.9.2017) Tiwana A. & Konsynski B. (2010). Complementarities between organizational IT architecture and governance structure. Information Systems Research, 21 (2010), pp. 288-304. Turun kaupunki (2014). Kehittämismallin käyttöönotto. http://ah.turku.fi/kh/2014/0929020x/3139306.htm (viitattu 21.12.2017) Turun kaupunki (2016). Tiedolla johtamisen viitearkkitehtuuri. Turun kaupunki (2017). Tietohallintostrategia. http://ah.turku.fi/kh/2017/0424010x/3537214.htm (viitattu 20.12.2017) Valtioneuvoston kanslia (2008). Valtioneuvoston kokonaisarkkitehtuurin toiminta- arkkitehtuuri. http://vnk.fi/hanke?tunnus=VNK002:00/2016 (viitattu 27.11.2017) Zachman, J. A. (1987). A framework for information systems architecture. IBM systems journal, 26(3), 276-292. Zachman, J. A. (2002). The zachman framework for enterprise architecture. Zachman International, 79. 109 Zadeh, A. T., Sahranb, S., & Mukhtar, M. (2013). Service Identification in SMEs: Appropriate Elements and Methods. International Journal of Machine Learning and Computing, 3(3), 279. 110 LIITE A Yhteenveto työn tuloksista Turun kaupungille Tämä pro gradu -tutkielmani tarkastelee Gartnerin esittämää kahdella rinnakkaisella ta- valla toimivan, eli bimodaalisen, IT-toiminnon mallia. Bimodaalisella toimintamallilla vakiintuneet organisaatiot pyrkivät vastaamaan toimintaympäristöstään aiheutuviin kah- denlaisiin vaatimuksiin. Organisaatioihin kohdistuu vaatimuksia hyödyntää uusien digi- taalisten teknologioiden tuottamia mahdollisuuksia ja vastata uusien, usein jo lähtökoh- taisesti digitaalisuuteen perustuvien ja perinteisiä liiketoimintamalleja haastavien toimi- joiden kilpailuun. Samaan aikaan niiden tulisi kyetä hyödyntämään nykyistä toiminta- malliaan ja ylläpitämään nykyistä informaatioteknologian kokonaisuutta, jolla ne tuke- vat toimintaansa. Nämä vaatimukset pakottavat organisaation IT-toiminnon toimimaan sekä ketterällä ja kokeellisella tavalla uuden teknologian mahdollisuuksien hyödyntämiseksi että vakau- den, virheettömyyden ja ennakoitavuuden kaltaisia perinteisesti IT-toimintoon kohdistu- via vaatimuksia toteuttaen. Turun kaupungin voidaan katsoa toimivan jo nyt osin digitaalisilla ja osin perinteisillä toimintatavoilla – muun muassa digitaalisten palvelujen kehittämisen kärkihanke on or- ganisoitu varsinaisen IT-toiminnon ulkopuolelle. Työssä tehdyn tarkastelun tuloksena voitaisiin pitää tarkoituksenmukaisena eriyttää nämä kaksi toimintatapaa toisistaan entistä selvemmin. Toimintatapojen eriyttäminen ei välttämättä tarkoita digitaalisen ja perinteisen IT:n palvelujen erottamista toisistaan or- ganisaatiorakenteessa, vaan niiden (liike-)toiminnan osa-alueiden yksikäsitteistä tunnis- tamista, joita tulee tukea digitaalisen IT:n toimintatavoilla. Lisäksi työssä tunnistetaan tarve tarkastella erikseen konsernitason yhteisiä palveluja ja jäljelle jäävää standardoitu- jen sovellusten ja prosessien kokonaisuutta. 111 Toiminnan osa-alueita tukevat IT-toiminnon toimintatavat ja niillä pääasiallisesti sovel- lettavat arkkitehtuurityylit. Työn perusteella tällainen digitaalinen IT katsotaan tarkoituksenmukaiseksi erityisesti palveluprosessien asiakasrajapinnan läheisyydessä. Työssä esitetyn jaottelun mukai- sesti digitaalista informaatioteknologiaa ja ketteriä hyödyntävä kehittäminen voitaisiin toteuttaa muusta IT:stä ja kehittämisestä erillisenä jatkuvana toimintana, joka työskente- lisi läheisessä yhteistyössä toimialojen palveluista vastaavien tahojen kanssa. Tällöin tu- lisi kuvata riittävällä tarkkuudella ne rajat, joiden sisällä palvelusta vastaava taho ja pal- velua tukevia teknisiä palveluja kehittävä tiimi voisivat toimia mahdollisimman autono- misesti. (Liike-)toiminnan palvelun omistaja ja digitaalisten palvelujen kehittäjät voisi- vat tällöin muokata palvelunsa sisältöä ketterästi, kokeellisesti ja parhaaksi katsomillaan teknologioilla, huomioiden kuitenkin esteettömyyden ja graafisen ulkoasun kaltaiset konsernitasolla määritellyt linjaukset sekä konsernitasolla toteutetut yhteiset palvelut. Palveluprosesseissa toistuvat niiden yhteiset piirteet ehdotetaan toteutettaviksi konser- nitasoisina palveluina. Yhteisesti toteutettavat palvelut kuvattaisiin osana kaupungin kokonaisarkkitehtuuria, ja yksittäisiä palveluprosesseja tukeva digikehittäminen velvoi- tettaisiin käyttämään niitä toteutuksissaan. Koska keskitetty IT ja kokonaisarkkitehtuuri- toiminto ohjaisivat digikehittämistä ensisijaisesti näiden toteuttamiensa yhteisten palve- lujen kautta, pystyttäisiin kokonaisarkkitehtuurissa keskittymään yksittäisten teknisten palvelujen toteutuksen sijasta tunnistamaan ja suunnittelemaan konsernitasolla toimin- taa parhaiten tukevia palveluja. Samoin, jos digikehittäminen organisoitaisiin asiakasra- japinnan lähellä eri palveluiden yhteydessä tehtäväksi jatkuvaksi toiminnaksi, kaupun- gin hankesalkkuun sisältyvien yksittäisiin palveluihin projektien määrä vähenisi, ja siten vapauttaisi kehittämisresursseja laajempien kokonaisuuksien tarkasteluun. 112 Konsernitasoisten yhteisten palvelujen lisäksi perinteisen IT-toiminnon tuettaviksi lue- taan standardoidut prosessit. Työssä tarkasteltiin kaupungin toiminnan jaottelua myös yksilölliset vaatimukset toteut- tavasti informaatioteknologialla tuettavan ja toisaalta standardoitavan toiminnan ja IT:n näkökulmista oheisen kuvan mukaisesti. Digitaalisten menetelmien käyttöönoton, yhteisten palvelujen toteutuksen ja infrastruk- tuurin standardoinnin vaikutusten hahmottelua. Kuvassa esitetysti voidaan ajatella, että toteuttamalla valittujen osa-alueiden (liike-)toi- mintaa tukevia sovelluksia yksilöllisesti digitaalisen IT:n toimintatavoilla ja teknologi- oilla, tunnistamalla ja toteuttamalla konsernin laajuisia palveluja yhä enemmän keskite- tysti, ja jatkamalla IT-infrastruktuurin ja yhteisten sovellusten standardointia ja harmo- nisointia, voidaan samanaikaisesti sekä standardoida yhä suurempi osa toiminnasta, ja toisaalta tukea yhä ketterämmin ja yksilöllisemmin niitä toiminnan osa-alueita, joilla kaupunki pyrkii toimimaan yksilöllisillä toimintatavoilla. Tämä voi olla tarkoituksen- mukaista ainakin edellä kuvatusti asiakkaille suunnatuissa palveluprosesseissa sekä niissä kaupungin strategisissa hankkeissa, joissa pyritään erottautumaan muista toimi- joista ja tuottamaan kaupungille kilpailuetua. Työssä tarkasteltiin myös eri arkkitehtuurityylien soveltumista toiminnan eri osa-aluei- den tukemiseen. Työn perusteella olisi aiheellista tutkia mikropalvelujen hyödyntä- mistä digitaalisten palvelujen kehityksessä. Mikropalvelujen soveltamisen voidaan kat- soa edellyttävän sekä tiettyjen arkkitehtuuriperiaatteiden että tiettyjen työmenetelmien noudattamista. Mikropalveluja ei näiden osalta tarvitse välttämättä toteuttaa kaupungin toimintaympäristössä täysin puhdasoppisesti, vaan niihin liittyviä toimintatapoja voi- 113 daan soveltaa kaupungin tarpeisiin sopiviksi. Kenties keskeisimpiä sovellettavista peri- aatteista ovat teknisten palvelujen toteutus tukemaan yhtä (liike-)toiminnan palvelua, tarvittavan teknisen ja toimialaosaamisen yhdistävän tiimin muodostaminen tämän pal- velun kehittämiseksi sekä se, että tiimi vastaa kaikista palvelun kehittämiseen ja ylläpi- toon liittyvistä tehtävistä koko sen elinkaaren ajan. Sekä digitaalisten toimintatapojen yleensä että digitaalisten palvelujen toteuttamisen mikropalveluilla voidaan katsoa aikaansaavan uusia osaamistarpeita ja joko tuottavan uusia resurssitarpeita tai kohdentavan niitä uudelleen. Turun kaupunki on pyrkinyt kes- kittämään IT-toimintonsa IT-palvelut -palvelukeskukseen, mutta sen toimialojen voi- daan katsoa edelleen vastaavan merkittävästä osuudesta informaatioteknologian käyt- töön liittyvistä tehtävistä. Toimialojen yhteisiin piirteisiin kohdistuva standardointi ja samanaikainen lähellä toimintaa tehtävä ja toiminnan tarpeita yksilöllisesti mikropalve- luilla toteuttava digikehittäminen aiheuttaisivat kiistatta uusia osaamisvaatimuksia, mutta eivät välttämättä kasvattaisi toimialoilla tehtävän IT-liitännäisen työn määrää. Kaupungin jo käyttämä palvelukeskeinen arkkitehtuuri (SOA) katsottiin tarkoituk- senmukaiseksi toteutustavaksi konsernitason palvelujen toteuttamiselle. Näiden palvelu- jen voidaan jo määritelmänsä mukaan katsoa olevan laajalti käytettyjä ja siten mikropal- veluja hallitummin ja hitaammin muuttuvia. Lisäksi palvelukeskeinen arkkitehtuuri yh- distää konsernitasolla tehtävät palvelut kansallisiin palveluihin, ja tarjoaa nämä käytettä- viksi yksittäisten palveluprosessien yhteydessä toimiville mikropalveluille. Yhteenvetona eri arkkitehtuurityylien soveltamisesta sekä toiminnan yksilöllisestä tuke- misesta ja standardoinnista voidaan todeta, että esitetyssä tavoitetilassa standardoidut toimintatavat ja niitä tukevat järjestelmät muodostavat kustannustehokkaasti ja vakaasti toimivan alustan ketterälle ja kokeelliselle digikehittämiselle.