KuntaIT Kokonaisarkkitehtuurimenetelmän soveltamisohje palvelukeskeisessä arkkitehtuurissa

KuntaIT Kokonaisarkkitehtuurimenetelmän soveltamisohje palvelukeskeisessä arkkitehtuurissa versio 1.0 5.2.2009

2 (42) 1 JOHDANTO... 4 2 KÄYTETYT TERMIT... 5 3 YLEISET NIMEÄMISKÄYTÄNNÖT... 6 4 YLEISKUVAUS JA LINJAUKSET... 7 4.1 YLEISKUVAUS DOKUMENTISTA... 7 4.2 DOKUMENTIN RAKENNE... 7 4.3 RAJAUKSET... 7 4.4 KENELLE TÄMÄ SOVELTAMISOHJE ON TARKOITETTU... 8 4.5 DOKUMENTTIIN LIITTYMÄT MUIHIN OHJEISIIN... 8 4.6 KÄYTETTÄVÄT MALLINNUSTAVAT JA YLEISLINJAUS NIIDEN KÄYTTÄMISESTÄ... 8 4.7 SOA-TOIMISTO... 9 5 KOKONAISARKKITEHTUURIMENETELMÄN HYÖDYNTÄMINEN SOA-RATKAISUISSA... 10 5.1 KOKONAISARKKITEHTUURIMENETELMÄN RAKENNE... 10 5.2 TAVOITETILAN KUVAAMINEN YLEISESTI... 11 5.2.1 Tavoitetilan kuvaamisen pääperiaate... 11 5.2.2 Rajatun kohteen kohde- tai viitearkkitehtuurin tavoitetilan kuvaaminen... 12 5.3 SOA-RATKAISUN TAVOITETILAN KUVAAMINEN - PÄÄASKELEET... 13 5.4 MALLINNUSVAIHEIDEN JÄSENNYS... 14 6 PERIAATTEELLISEN JA KÄSITTEELLISEN TASON KUVAUKSET... 15 6.1 SIDOSARKKITEHTUURIEN TUNNISTAMINEN, RAJAUKSET... 15 6.2 KOHDEALUEEN KESKEISTEN STRATEGISTEN LINJAUSTEN MÄÄRITTÄMINEN... 16 6.3 SIDOSRYHMIEN JA ROOLIEN MALLINNUS... 17 6.3.1 Sidosryhmäanalyysi... 17 6.3.2 Roolit ja vastuut... 17 6.4 YDINPALVELUJEN TUNNISTAMINEN JA KUVAAMINEN... 18 6.5 PALVELUIHIN LIITTYVIEN ALIPALVELUIDEN MALLINTAMINEN... 19 6.6 TARVITTAVIEN TEKNOLOGIAPALVELUIDEN TUNNISTAMINEN... 20 6.7 PALVELUIHIN LIITTYVIEN PROSESSIEN TUNNISTAMINEN JA PROSESSIRIIPPUVUUKSIEN MALLINTAMINEN21 6.7.1 Yleistä... 21 6.7.2 Tunnista mitä prosesseja palveluiden tuottamiseen tarvitaan... 22 6.7.3 Mallinna prosessien väliset keskinäiset suhteet (JHS 152 - toimintamallitaso)... 22 6.7.4 Tunnista prosessiin liittyvät aliprosessit ja mallinna niiden suhteet... 22 6.8 PALVELUIHIN JA PROSESSEIHIN LIITTYVIEN TIETOTARPEIDEN MALLINTAMINEN... 22 6.8.1 Käsitemallinnus... 22 6.8.2 Karkea tietomallinnus... 23 6.9 PROSESSIEN KÄSITTEELLISEN TASON MALLINTAMINEN... 24 6.9.1 Yleistä... 24 6.9.2 Prosessien toimintalogiikan BPMN-mallinnus... 25 6.9.3 Yleiset ohjeet prosessimallinnukselle... 25 6.9.4 Keskitettyyn prosessiohjausnäkökulmaan perustuva mallinnus... 27 6.9.5 Ohjeistus ja rajoitteet BPEL-prosessimoottoria toteutukseen käyttäville prosessimallinnukselle... 32 6.10 PROSESSIIN LIITTYVIEN ROOLI- JA ORGANISAATIOTIETOJEN TARKENTAMINEN... 32

3 (42) 6.11 PALVELUIHIN JA PROSESSITOIMINTOIHIN LIITTYVIEN TIETOTARPEIDEN TARKENTAMINEN... 32 7 LOOGISEN TASON KUVAUKSET... 33 7.1 PROSESSITOIMINTOIHIN LIITTYVIEN SOA-PALVELUIDEN TUNNISTAMINEN... 33 7.1.1 Yleistä... 33 7.1.2 SOA-palveluiden tunnistaminen prosessimallien pohjalta... 34 7.1.3 SOA-palveluiden tunnistaminen tietomallien pohjalta... 34 7.1.4 Olemassaolevien SOA-palveluiden tarkistaminen... 34 7.2 PROSESSIEN LOOGISEN TASON MALLINTAMINEN... 35 7.2.1 Yleistä... 35 7.2.2 Loogisen tason BPMN-mallinnus... 36 7.2.3 BPEL-prosessimoottorien käytöstä seuraavat vaikutukset prosessimallinnukseen... 36 7.3 KÄYTTÖTAPAUSTEN KIRJOITTAMINEN... 37 7.3.1 Yleistä... 37 7.3.2 Käyttötapausten tunnistaminen... 37 7.3.3 Käyttötapausten kirjoittaminen... 38 7.4 TIETO- JA KÄSITEMALLIEN TARKENTAMINEN... 38 7.5 SOA-PALVELUIDEN KUVAAMINEN... 39 7.5.1 SOA-palveluiden kuvaaminen... 39 7.5.2 Keskeisimpien palvelurajapintatarpeiden kuvaus... 39 7.6 KA-MALLIEN VIIMEISTELY... 40 8 SUOSITUKSET VAIHEIDEN KÄYTÖLLE... 40 8.1 SUOSITELTAVAT VAIHEET... 40 8.2 ITERATIIVINEN VAIHEMALLI... 41 9 VAIHEIDEN VASTUUT JA TEKIJÄT... 41 10 VIITTEET... 42 11 MUUTOSHISTORIA... 42

4 (42) 1 Johdanto Tämän dokumentin tarkoitus on kuvata, kuinka mallintaa kokonaisarkkitehtuurin ja SOAperiaatteen mukaisesti organisaation toimintaa ja kehittää sitä tukevia tietojärjestelmiä tai teknologiaratkaisuja. Tämä dokumentti toimii ohjeena tvt-kehittämisprojektien toteuttamiselle KA-menetelmän mukaisesti, palvelukeskeistä periaatetta tukien. Ohjeistus perustuu KuntaIT:n kokonaisarkkitehtuurimenetelmään, palvelukeskeisen arkkitehtuurin (SOA) hyödyntämiseen ja prosessien mallintamiseen. Dokumenttia noudattamalla voidaan suunnitella SOA-periaatteen mukaisia sähköisen palveluympäristön ratkaisuja, joissa KA-menetelmän mukaisesti tulee huomioitua koko toiminta- ja teknologiaympäristön keskeisimmät alueet. Dokumentin lähtökohtana on tietohallinnon tai substanssitoiminnan johdon päätös perustaa kehittämisprojekti. Tässä ohjeessa ei oteta kantaa projektin tarkoituksen tarkoituksenmukaisuuteen. Ohjetta käyttäessä tulee kuitenkin huomioida yhteydet muihin projekteihin.

5 (42) 2 Käytetyt termit Termi Selitys Aliprosessi Prosessi, joka on toisen prosessin osa. Prosessi Prosessi on joukko toisiinsa liittyviä toistuvia tehtäviä ja niiden toteuttamiseen tarvittavia resursseja, joiden avulla syötteet muutetaan tuotoksiksi. (mukautettu: Laamanen, Prosessijohtamisen käsitteet, JHS 152). Prosessi on johtamisen apuväline, keino saada aikaan haluttu tulos. Prosesseja jatkuvasti kehittämällä pyritään tehostamaan toimintaa ja nopeuttamaan läpimenoaikoja sekä parantamaan laatua, palvelutasoa, kustannustehokkuutta ja vaikuttavuutta (ValtIT). Prosessimalli Prosessimalli on graafinen esitys prosessin tehtävistä. Prosessimallista tulisi ilmetä vähintäänkin seuraavat asiat: tehtävien järjestys tehtävien keskinäiset riippuvuudet tehtävien kulku ja siihen liittyvät ohjaustiedot: tehtävien välisten siirtymien ehdot ja logiikka Prosessin omistaja Prosessin omistaja on prosessin toiminnasta, tuloksesta ja kehittämisestä vastuussa oleva henkilö (JHS 152). Syöte Syöte on tietoja ja materiaalia, joka syötetään prosessiin (JHS 152, Laamanen Kai, Prosessijohtamisen käsitteet). Syöte ei ole sama asia kuin raha, laitteet tai ihmisten osaaminen, jotka ovat resursseja ja siten osa prosessia. Toimenpide Toimenpide on prosessiin kuuluva käsittelyvaihe, jonka sisäistä toimintaa ja työnkulkuja ei tarkasteltavalla mallinnustasolla enää tarkenneta. Toimenpidettä voidaan pitää prosessimalliin sisältyvänä työtehtävänä, joka ei ole aliprosessi. Tapahtuma Tapahtuma on jotain, mitä tapahtuu prosessin aikana. Tapahtuma voi aloittaa prosessin, tapahtumia voi syntyä prosessin suorituksen seurauksena, niitä voidaan käsitellä prosessin aikana ja ne voivat olla prosessin

6 (42) lopputuloksia. Prosessin lopputapahtumia lukuun ottamatta niillä on lähes aina vaikutusta prosessin etenemiseen. Tuotos Tuotos on prosessin tai toiminnon lopputulos. Ydinpalvelu Ydinpalvelu on prosessimallinnuksen näkökulmasta organisaation toimintaa keskeisesti tukeva ylätason prosessijoukko. Ydinpalvelu sisältää yleensä useampia prosesseja, joiden suhde ydinpalveluun kuvataan pelkästään rakenteen tasolla (esim. mistä prosesseista ydinpalvelu koostuu ja mikä on niiden keskinäinen suhde). Toimenpidepalvelu Toimenpidepalvelu on prosessimallin toimenpiteeseen liittyvä palvelu. Toimenpidepalvelu voi olla tietojärjestelmän tarjoama palvelu tai jokin muu toimenpidettä tukeva palvelu, esim. asiakirjan arkistointipalvelu. SOA-palvelu SOA-palvelu on jonkin tietojärjestelmän tarjoama toimenpidepalvelu, joka täyttää Kuntasektorin teknologialinjausten [4] määrittelemät vaatimukset SOA-palveluille. SOA-palvelu sisältää aina tarkan rajapintakuvauksen ja se toteutetaan lähes aina Web Service teknologialla (ks. SOA-palvelun ja Web Servicen tarkempi kuvaus Kuntasektorin teknologialinjaukset [4] dokumentista). 3 Yleiset nimeämiskäytännöt Tässä luvussa esitetään mm. prosessien, toimintojen ja tapahtumien nimeämiskäytännöt. Termi Nimeämiskäytäntö Aliprosessi Aliprosessit nimetään samoin kuin toimenpiteet. Prosessi Prosessin nimen tulisi alkaa substantiivilla. Tapahtuma Tapahtuman nimen tulisi olla muotoa: substantiivi (yleensä käsiteltävän tieto-objektin nimi) + verbi imperfektissä Toimenpide Toimenpiteen nimen tulisi olla muotoa: verbi + substantiivi (yleensä käsiteltävän tieto-objektin nimi). Ydinpalvelu Ydinpalvelun nimen tulisi olla substantiivi.

7 (42) Toimenpidepalvelu Toimenpidepalvelun nimen tulisi olla substantiivi Substanssipalvelu Substanssipalvelun nimen tulisi olla substantiivi. 4 Yleiskuvaus ja linjaukset 4.1 Yleiskuvaus dokumentista Tässä dokumentissa kuvataan kuntasektorin kokonaisarkkitehtuurimenetelmän (KAmenetelmä) hyödyntämistä sellaisissa kehittämisprojekteissa ja -hankkeissa, jossa kuntatoimija on valinnut SOA-ratkaisumallin sähköisen palveluympäristönsä keskeiseksi ohjenuoraksi. Tämä dokumentti toimii varsinaisen KA-menetelmän ja sen sisältämien kuvauspohjien käytön tukena tällaisissa tapauksissa. Varsinainen kuntasektorin kokonaisarkkitehtuurimenetelmä ja siihen kuuluvat kuvauspohjat on kuvattu omassa itsenäisessä dokumentaatiossaan (Viitteet [1] ja [1.1]). SOA-periaatteiden hyödyntäminen kuntasektorilla on kuvattu omassa dokumentissaan (Viite [5]). 4.2 Dokumentin rakenne 4.3 Rajaukset Dokumentissa kuvataan ensin yleisesti KA-menetelmän soveltamiseen liittyviä yleisiä periaatteita. Suurin osa dokumentista kuitenkin keskittyy KA-menetelmän soveltamisen vaiheiden kuvaamiseen ja niissä tehtävien toimenpiteiden toteuttamisen ohjeistamiseen SOAviitekehyksessä. o Tämä soveltamisohje on tarkoitettu erityisesti kuntatoimijoille, jotka ovat valinneet SOA-ratkaisumallin tietoteknisen palveluympäristönsä kehittämisen keskeiseksi periaatteeksi. o Tämä soveltamisohje sopii erityisesti rajattujen kohteiden tavoitetilaarkkitehtuurin kuvaamiseen. Nykytilan kuvaamiseen sekä koko organisaation KA-tavoitetilan kuvaamiseen suositellaan käytettäväksi yleistä kuntasektorin KA-menetelmän soveltamisohjetta [2]. o Ohje ei ole tarkoitettu projektityöohjeeksi o Ohjeen sisältö rajoittuu prosessien mallintamisen ja niistä muodostettujen sähköisten palveluiden valmistumisen välissä tapahtuvan toiminnan ohjeistamiseen.

8 (42) o Dokumentissa ei oteta kantaa sähköisten palvelutoteutusten toteuttamiseen tai hankintaan. 4.4 Kenelle tämä soveltamisohje on tarkoitettu Tämä soveltamisohje on tarkoitettu kuntatoimijoiden tietojärjestelmä- ja tvtarkkitehtuuriprojektien vastuuhenkilöille ja tietohallinto-organisaatioille. Keskeisiä kohderooleja SOA-periaatteen kehittämisen ohjenuoraksi valinneissa kunnissa ja kuntayhtymissä ovat: Tietohallintojohtajat ja tietohallintopäälliköt Kokonaisarkkitehtuurista tai IT-arkkitehtuurista vastaavat asiantuntijat Kuntien IT-asiantuntijat, suunnittelijat, järjestelmävastaavat Kehittämisprojektien vastuuhenkilöt, projektipäälliköt sellaisissa projekteissa, joissa toiminnan kehittämiseen liittyvät suoraan tai välillisesti tietoteknisen ympäristön palvelut Edellisten lisäksi tämän soveltamisohjeen kohderyhmään kuuluvat SOA-ratkaisumallia hyödyntäville kuntatoimijoille tietojärjestelmiä, IT-palveluja, konsultointi- ja asiantuntijapalveluja tai kehittämispalveluja tarjoavat julkishallinnolliset ja yksityissektorin palveluntuottajat. 4.5 Dokumenttiin liittymät muihin ohjeisiin Yleinen KA-menetelmän kuvaus löytyy Viitteestä 1. Yleinen KA-menetelmän soveltamisohje on kuvattu Viitteessä 2. 4.6 Käytettävät mallinnustavat ja yleislinjaus niiden käyttämisestä Kokonaisarkkitehtuuriin ja prosessien rakenteiden mallintamiseen suositellaan käytettävän Archimate-notaatiota. Tämänkaltaisia rakenteita ovat mm. prosessihierarkia (prosessien väliset suhteet), käsitemalli (sekä käsitteiden keskinäinen suhde että suhde prosessin eri toimintoihin), roolit (roolien keskinäinen suhde ja suhde prosessin toimintoihin) sekä palvelurakenne. Prosessien toimintalogiikan ja työnkulkujen kuvaamiseen suositellaan käytettävän JHS 152 suosituksen mukaisesti BPMN-notaatiota. Tarvittaessa näistä suosituksista voidaan hyvin perusteltujen ja dokumentoitujen syiden vuoksi poiketa. Mallinnuskielen tulisi kuitenkin pysyä samana eri projekteissa. Esim. tarvittaessa tietojen mallinnukseen voidaan käyttää UML-notaatiota, jos sitä sitoudutaan käyttämään muissakin projekteissa. Prosessmallinnuksen pääperiaate on, että BPMN-kaavioiden aktiviteetit sijoitetaan prosessirakenteita kuvaaviin Archimate-kaavioihin, jossa määritellään BPMN-aktiviteettien keskinäinen suhde ja suhteet eri prosesseihin. Riippuen minkä tason BPMN-mallista on kyse, voi aktiviteetti olla Archimate-kaaviossa liiketoimintapalvelu (jonka ei tarvitse tukeutua mihinkään tietojärjestelmään), aliprosessi tai SOA-palvelu. Näihin aktiviteetteihin voidaan Archimate-kaaviossa liittää myös roolit ja käsitemallin sisältämät käsitteet.

9 (42) 4.7 SOA-toimisto Monissa SOA-periaatteen käyttöönottoa ja jalkautusta kuvaavissa ohjeissa ja menetelmissä neuvotaan aloittamaan SOA-periaatteen mukainen toiminta perustamalla SOA-toimisto. SOA-toimiston keskeisiä tehtäviä ovat: SOA-periaatteen käyttöönoton johtaminen SOA-käyttöönoton etenemissuunnitelman laatiminen SOA-käyttöönoton ohjaus SOA-hankkeiden valvonta SOA-periaatteiden noudattamisen valvonta SOA-palvelujen hyväksyminen ja SOA-palvelukatalogin ylläpito Nämä ovat kaikki laajemman arkkitehtuurinhallinnan tehtäviä. SOA-ratkaisut ovat yksi keskeisimpiä arkkitehtuurinhallinnan osa-alueita organisaatiossa, joka on valinnut SOAperiaatteen sähköisen palveluympäristönsä kehittämisen periaatteeksi. Kuntasektorin KA-hallintamalli [6] soveltuu sellaisenaan SOA-toimistotyöhön. Esimerkiksi SOA-etenemissuunnitelmaa vastaa puolestaan KA-tiekartta. Samoin SOA-toimiston organisointia vastaa arkkitehtuuriryhmä. Erillistä arkkitehtuuriryhmästä erillistä SOA-toimistoa ei kannata perustaa. SOA-toimiston täydentäviä erityispiirteitä muuhun arkkitehtuurityöhön ovat: Tämän ohjeen koulutus ja soveltaminen kehittämishankkeissa Tämän ohjeen soveltamisen valvonta SOA-palvelujen hyväksyminen ja SOA-palvelukatalogin ylläpito

10 (42) 5 Kokonaisarkkitehtuurimenetelmän hyödyntäminen SOA-ratkaisuissa 5.1 Kokonaisarkkitehtuurimenetelmän rakenne Kokonaisarkkitehtuurimenetelmä jäsentyy näkökulmiin ja käsitteellisiin tasoihin (abstraktiotasoihin) seuraavasti: Arkkitehtuuriperiaatteet Sidosarkkitehtuurit, rajaukset ja reunaehdot Tietoturvatarpeet ja -periaatteet SOA-linjaukset Tietoarkkitehtuuri Toimintaarkkitehtuuri Tietojärjestelmäarkkitehtuuri Teknologiaarkkitehtuuri Käsitteellinen taso - MITÄ Strategia Palvelut Sidosryhmät, roolit Palvelut-käsitteet - matriisi Käsitemalli Tietojärjestelmäpalvelut Teknologiapalvelut Looginen Taso - MITEN Prosessikartta Prosessikuvaukset Prosessit-tiedot matriisi Tietomallit Loogiset tietovarannot Loog. järjestelmäjäsennys Järjestelmät-tiedot matriisi Järjestelmät-prosessit matriisi Integraatioperiaatteet (sis. liittymät) Teknologiakomponentit Valvonta- ja hallintaarkkitehtuuri Integraatioratkaisut (sis. rajapinnat) Fyysinen taso - MILLÄ Fyysiset tietovarannot Sanastot Fyys. järjestelmäsalkku Sijoituskaavio Verkkokaavio Teknologiasalkku Standardit Kuva 1 Kokonaisarkkitehtuurimenetelmän jäsentyminen Kokonaisarkkitehtuurimenetelmää hyödynnetään siten, että kehitettävä ratkaisu tai nykytila kuvataan yllä kuvatun kokonaisarkkitehtuurijäsennyksen eri näkökulmien ja abstraktiotasojen kuvauspohjiin (kuvattu oranssilla värillä). Kokonaisarkkitehtuurikuvaus esim. koulutuspalveluiden uusien ratkaisujen tai vaikkapa konsernihallinnon tulevien johtamisvälineiden ratkaisujen tavoitearkkitehtuurit muodostuvat siis kattavasta joukosta yksittäisiä kokonaisarkkitehtuurimenetelmän osakuvauksia. Kokonaisarkkitehtuurimenetelmä on kuvattu tarkemmin Viitteessä 1.

11 (42) 5.2 Tavoitetilan kuvaaminen yleisesti 5.2.1 Tavoitetilan kuvaamisen pääperiaate Kokonaisarkkitehtuurimenetelmän tavoitteena on varmistaa, että kehittämisessä otetaan huomioon erityisesti toiminnan tarpeet ja luodaan yhdenmukainen ja ristiriidaton ratkaisukehikko, johon voidaan sovittaa yhteentoimivasti erilaisia yksittäisiä teknisluontoisia ratkaisuja tietojärjestelmiä, teknologiapalveluita, tietorakenteita ja tietovarantoja. Tästä peruslähtökohdasta johtuen kokonaisarkkitehtuurimenetelmällä kuvatut sähköisen palveluympäristön tavoitetilat kannattaa kuvata ns. ylhäältä alas kaikkea kehittämistä ja jäsentämistä koskevista periaatteista yksityiskohtaisempiin toteutuslinjauksiin. Tavoitetila kuvataan pääsääntöisesti siis KA-menetelmäjäsennyksessä ylhäältä alas tarkentuvasti periaatteellisen tason linjauksista, käsitteellisten linjausten kautta loogisiin linjauksiin seuraavasti: Arkkitehtuuriperiaatteet Sidosarkkitehtuurit, rajaukset ja reunaehdot Tietoturvatarpeet ja -periaatteet SOA-linjaukset Tietoarkkitehtuuri Toimintaarkkitehtuuri Tietojärjestelmäarkkitehtuuri Teknologiaarkkitehtuuri Käsitteellinen taso - MITÄ Strategia Palvelut Sidosryhmät, roolit Palvelut-käsitteet - matriisi Käsitemalli Tietojärjestelmäpalvelut Teknologiapalvelut Looginen Taso - MITEN Prosessikartta Prosessikuvaukset Prosessit-tiedot matriisi Tietomallit Loogiset tietovarannot Loog. järjestelmäjäsennys Järjestelmät-tiedot matriisi Järjestelmät-prosessit matriisi Integraatioperiaatteet (sis. liittymät) Teknologiakomponentit Valvonta- ja hallintaarkkitehtuuri Integraatioratkaisut (sis. rajapinnat) Fyysinen taso - MILLÄ Fyysiset tietovarannot Sanastot Fyys. järjestelmäsalkku Sijoituskaavio Verkkokaavio Teknologiasalkku Standardit Kuva 2 Yleinen organisaatiotason tavoitetila-arkkitehtuurin kuvaaminen Arkkitehtuurin tavoitetilaa kuvattaessa kannattaa lähteä periaatteellisen tason kuvauksista. Nämä muodostavat arkkitehtuurin laatimisen ja kehittämisen peruskivet, jotka tulisi ottaa huomioon kaikilla kuvaamisen tasoilla ja kaikissa kohdealueissa, on kysymyksessä sitten

12 (42) koko organisaation arkkitehtuurin tavoitetilan kuvaamisesta tai yksittäisen, rajatun ratkaisun tavoitetilan kuvaamisesta. 5.2.2 Rajatun kohteen kohde- tai viitearkkitehtuurin tavoitetilan kuvaaminen Rajatun kohteen - kuten tietyn toiminnon järjestelmäympäristö - tavoitearkkitehtuuri kuvataan yksityiskohtaisemmin kuin koko organisaation tavoitearkkitehtuuri. Yleensä rajatun kohteen tavoitearkkitehtuuri kannattaa aloittaa tunnistamalla alueeseen liittyvät kansalliset ja koko organisaation arkkitehtuurilinjaukset. Esimerkiksi kunnan sähköisen asianhallinnan tavoitetila-arkkitehtuurissa tulee ottaa huomioon kansalliset SÄHKEmääritykset. Tämän jälkeen kuvataan tavoitelinjaukset käsitetaso kerrallaan vasemmalta oikealle siten, että toiminnan ja kunnan palvelujen tarpeet huomioidaan systemaattisesti tavoitetilaa kuvattaessa. 1 Arkkitehtuuriperiaatteet Sidosarkkitehtuurit, rajaukset ja reunaehdot Tietoturvatarpeet ja -periaatteet SOA-linjaukset Tietoarkkitehtuuri Toimintaarkkitehtuuri Tietojärjestelmäarkkitehtuuri Teknologiaarkkitehtuuri Käsitteellinen taso - MITÄ 2 Strategia Palvelut Sidosryhmät, roolit Palvelut-käsitteet - matriisi Käsitemalli Tietojärjestelmäpalvelut Teknologiapalvelut Looginen Taso - MITEN Fyysinen taso - MILLÄ 3 4 Prosessikartta Prosessikuvaukset Prosessit-tiedot matriisi Tietomallit Loogiset tietovarannot Fyysiset tietovarannot Sanastot Standardit Loog. järjestelmäjäsennys Järjestelmät-tiedot matriisi Järjestelmät-prosessit matriisi Integraatioperiaatteet (sis. liittymät) Integraatioratkaisut (sis. rajapinnat) Fyys. järjestelmäsalkku Sijoituskaavio Teknologiakomponentit Valvonta- ja hallintaarkkitehtuuri Verkkokaavio Teknologiasalkku Kuva 3 Rajatun kohdealueen tavoitearkkitehtuurin kuvaaminen Rajatun kohteen arkkitehtuurin tavoitetilan kuvaamisessa kannattaa erityisesti panostaa toiminta-arkkitehtuurin käsitteelliseen ja loogiseen tasoon sekä tietoarkkitehtuurin kuvaamiseen. Tyypillisesti virheet näissä johtavat mahdollisesti jopa muuten laadukkaaseen tietojärjestelmäperheeseen, jota ei vaan voi täysipainoisesti hyödyntää niihin asioihin, joihin ne

13 (42) on tarkoitettu. Myös rajatun kohteen tavoitearkkitehtuurit yleensä huipentuvat yhteen loogisen järjestelmäjäsennyksen kuvaan, mutta tämä ei saa olla ainoa tuotos vaan sen tulee olla loogisella tasolla kaikkien ylempien tasojen kuvausten pohjalta laadittu lopputulos. SOA-ratkaisuissa voidaan ottaa kantaa jonkin verran jo fyysisen tason kuvauksiin - erityisesti rajapintaratkaisuihin. 5.3 SOA-ratkaisun tavoitetilan kuvaaminen - pääaskeleet Kehittämisen kohteen SOA-periaatteiden mukainen tavoitetila-arkkitehtuuri syntyy vaiheittaisen kuvausprosessin mukaisesti edellä kuvattua yleistä kuvausperiaatetta soveltaen seuraavasti: Kuva 4 Kehittämisprojektin arkkitehtuurisuunnittelun vaiheet Mitkä vaiheet tulee käydä läpi Kehittämisprojektin alussa kannattaa mallinnusvaiheen 1 kohdalla sopia, mille tasolle arkkitehtuurisuunnittelu kyseisessä projektissa viedään. Tämä riippuu pitkälti projektin tavoitteista, käytettävissä olevista resursseista sekä kehittämisen aikataulutavoitteista. Kaikissa tapauksissa kannattaa käydä läpi vaiheet 1-12 (sekä soveltuvin osin vaihe 17). Tällöin lopputuloksen saadaan tunnistettu lista SOA-palveluita, joita voidaan suoraan käyttää hankintojen ja tarkemman suunnittelun tukena. Näitä tukevat tuotetut kuvaukset esimerkiksi sidosryhmistä ja rooleista, käsitteistä ja tiedoista, sekä toiminnoista ja prosesseista. Nämä kaikki ovat erinomaista tietoa varsinaiselle ratkaisutoteutukselle.

14 (42) Mikäli kehittämistyötä halutaan suoraan jatkaa tarkemmalla teknisellä suunnittelulla ja toteutuksella, kannattaa kuvata myös vaiheet 13-17. Tämä voi vaatia erityistä suunnitteluosaamista tai tämän tukea. Vaiheen 13, prosessien looginen mallintaminen edellyttää vahvaa panosta substanssiasiantuntijoilta. Ylipäätään olennaista on ottaa kehittämisessä huomioon kaikkien eri vaiheiden asiat. Yksittäisiä virheitä tai kuvaustavan haasteita ei tarvitse pelätä. 5.4 Mallinnusvaiheiden jäsennys Mallinnusvaiheet ja niiden tuotokset on jäsennetty kokonaisarkkitehtuurimenetelmän mukaisiin näkökulmiin ja käsitteellisiin tasoihin. Käsitteellisten tasojen määrittelyssä hyödynnetään MDA:n mukaista jäsennystä. Tässä dokumentissa kokonaisarkkitehtuurimenetelmän mukaiset abstraktiotasot sidotaan MDA:n mukaisiin tasoihin kaavion (kuva 5) mukaisesti. Tarkemmin MDA:n mukaisia mallinnustasoja on käsitelty Kuntasektorin teknologialinjauksissa [4]. MDA Käsitteellinen taso - MITÄ CIM (Computation Independent Model), Tietojärjestelmäriippumaton malli Looginen Taso - MITEN PIM (Platform Independent Model), Sovellusalustariippumaton malli Fyysinen taso - MILLÄ PSM (Platform Specific Model), Sovellusalustakohtainen malli Kuva 5 Abstraktiotasojen määrittely Kokonaisarkkitehtuurimenetelmän ja MDA:n mukaista jaottelua käyttäen mallinnusvaiheiden tuotokset jäsentyvät seuraavasti:

15 (42) Tietoarkkitehtuuri Toimintaarkkitehtuuri Tietojärjestelmäarkkitehtuuri Teknologiaarkkitehtuuri Käsitteellinen taso - MITÄ Käsitetason prosessimallit Palvelumallit Käsitemallit Sidosryhmä,- roolija organisaatio mallit Tietomallit Käyttötapaukset SOA-palvelumallit Looginen Taso - MITEN SOA-palvelut toimenpiteet,tiedot,roolit, prosessit,palvelut malli Loogisen tason prosessimallit SOApalvelukuvaukset SOA-palvelurajapinnat Fyysinen taso - MILLÄ BPELprosessikuvaukset XSD-tietomallit WSDL-kuvaukset Kuva 6 Mallinnusvaiheiden tuotosten jäsentyminen Eri käsitteellisten tasojen kuvaukset rakentuvat osittain iteratiivisesti. Kunkin kuvauskierroksen jälkeen on hyvä tarkistaa, onko tarkemmissa kuvauksissa noussut esiin uusia tekijöitä (esim. rooleja, prosesseja, käsitteitä, tietoja), jotka pitää lisätä jo aiemmin tuotettuihin kuvauksiin. 6 Periaatteellisen ja käsitteellisen tason kuvaukset 6.1 Sidosarkkitehtuurien tunnistaminen, rajaukset Tunnistakaa ja listatkaa KA-menetelmäpohjaan keskeisimmät sidosarkkitehtuurit sekä kehittämisprojektin rajaukset ja reunaehdot. Sidosarkkitehtuurit ovat kyseisen kehittämisprojektin ulkopuolella määritettäviä arkkitehtuurilinjauksia, joilla on tai voi olla vaikutusta kyseiseen kehittämisprojektiin. Esimerkki: Kuntasektorin arkkitehtuurilinjaukset ja KANTO-arkkitehtuuri ovat kaupungin terveystoimialueen arkkitehtuurin sidosarkkitehtuureita Huomatkaa, että organisaationne arkkitehtuurityön kehittyessä myös kuntatoimijan omat arkkitehtuurikuvaukset ja linjaukset voivat toimia sidosarkkitehtuureina, jotka on otettava kehittämisessä huomioon. Tällaisia voivat olla esim. SOA-arkkitehtuurin yleiskuva, sähköisen asioinnin arkkitehtuuri tai kunnan yleinen tavoitearkkitehtuurikuvaus.

16 (42) Kuvatkaa kuvauspohjaan, miten tunnistetut sidosarkkitehtuurit otetaan tässä projektissa huomioon. Reunaehdot ja rajaukset puolestaan kuvaavat, miten laajasti kuvattavaa arkkitehtuuria sovelletaan mikä on nyt kuvattavan arkkitehtuurin ns. pätevyysalue. Yksittäisen järjestelmän kohdearkkitehtuurissa puolestaan voidaan esim. ilmaista, että tämä kuvaus koskee vain esim. tietovarastoarkkitehtuuria ja siinä noudatetaan muuten kaupungin kokonaisarkkitehtuurin tavoitetilalinjauksia. 6.2 Kohdealueen keskeisten strategisten linjausten määrittäminen Tunnistakaa, priorisoikaa ja listatkaa KA-menetelmäpohjaan keskeisimmät kohdealueen substanssitoiminnan strategiset linjaukset Toiminnan strategia kuvaa keskeiset tavoitteet organisaation substanssitoiminnalle. Tämä tulee heijastumaan palveluihin ja tätä kautta IT-ratkaisuihin. Esimerkiksi strateginen linjaus sähköisen asioinnin lisäämisestä tai kokonaan uusien substanssipalvelujen kehittämisestä vaikuttaa kaikkiin muihin arkkitehtuurinäkökulmiin seuraavasti: Uusia tietojärjestelmäpalveluita (esim. asiointitili, tunnistaminen) Uusia tietovarantoja asiointitiedot Täsmennettyä tietoturvaa Uusia vaatimuksia valvontaan ja hallintaan 24/7 palvelut lisääntyvät Uusia vaatimuksia teknologiasalkkuun korkean käytettävyyden alustat Rajatun kohdealueen tavoitearkkitehtuuriin keskityttäessä käsitellään lähinnä kyseisen alueen substanssistrategialinjauksia. Samalla on kuitenkin hyvä tarkistaa myös kunnan yleisen strategian keskeisimmät strategialinjaukset. Strategisten linjausten listauksen ja priorisoinnin avulla voidaan dokumentoida, mikä kyseisessä kehitettävässä ratkaisussa ja palvelussa on ylätasolla kaikkein tärkeintä. Osa strategisista tavoitteista voi olla jo kuvattu koko organisaation KA-tavoitetilan arkkitehtuuriperiaatteissa. Tarkistakaa tämä. Voimassaolevat strategiat taltioidaan arkkitehtuuridokumentaation liitteiksi. Sekä substanssistrategiat, sidosryhmien strategiat että tietohallintostrategiat tulee ottaa arkkitehtuurityössä huomioon. Näistä listataan: Strategian keskeinen linjaus o Kysykää toiminnan avainhenkilöiltä, mitkä ovat ko. strategian kaikkein keskeisimmät kohdat Linjauksen vaikutukset arkkitehtuuriin / IT-toimintaan

17 (42) Miten vaikutukset huomioidaan arkkitehtuurityössä 6.3 Sidosryhmien ja roolien mallinnus Tunnistakaa ja kuvatkaa KA-menetelmäpohjaan keskeisimmät kohdealueen toimintoihin ja palveluihin liittyvät sidosryhmät ja roolit Sidosryhmät ja roolit osakuvaus kuvaa, minkälaisessa toimijaympäristössä organisaatio tai sen viite- tai kohdearkkitehtuurissa käsiteltävä osa toimii. Toimijoilla tarkoitetaan tässä sekä tuottajia, asiakkaita että muita sidosryhmiä. Roolit sisältävät sekä organisaatiorooleja että henkilörooleja. 6.3.1 Sidosryhmäanalyysi 6.3.2 Roolit ja vastuut Kehitettävän ratkaisun palvelevuuden, suorituskyvyn ja joustavuuden mittaamisen lähtökohtina ovat sidosryhmien asettamat vaatimukset, vaatimusten tavoitearvot ja niiden toteutuminen. (vrt. JHS 142) Mittaamisessa on huomioitava se, mitä sidosryhmät odottavat organisaatiolta, mistä organisaation vaikuttavuus syntyy. Mittaaminen on suositeltavaa tehdä sidosryhmäkohtaisesti. Mitattaviin asioihin kannattaa ottaa vain strategisesti tärkeimmät asiat (ei pieniä yksityiskohtia). Tavoitearvon asettaminen auttaa kiinnittämään huomion oikeisiin asioihin. Analysoi, ketkä ovat sidosryhmiä (asiakkaat mukaan lukien) Kuvaa sidosryhmät sekä kirjaa sidosryhmien tärkeys organisaation kannalta Kirjaa, mitä sidosryhmät odottavat organisaatiolta eli sidosryhmien vaatimukset Kuvaa, mitä organisaatio odottaa sidosryhmiltä. Aseta vaatimuksille mittarit, jotka kuvaavat, miten vaatimuksen toteutumista voidaan mitata Kirjaa organisaation asettama tavoitearvo (tavoitetilanne) mittareille Jaa roolit projektikohtaisiin ja yleisiin. Yleisten roolien osalta vertaa ovatko roolit jo aiemmin määritelty ja voidaanko niitä käyttää tässä yhteydessä. Organisaation toimijoiden rooleista tulee kuvata Osapuolen tai toimijan roolin nimi Roolin ja roolin tehtävien sanallinen kuvaus Roolin vastuut ja oikeudet Roolien ja vastuiden kuvaamista voi hyödyntää esimerkiksi roolipohjaisen käyttövaltuushallinnan määrittämisessä ja tietomallien roolipohjaisessa kehittämisessä. Organisaatiotasolla usein riittää, kun tunnistetaan roolityypit ja kaikkein keskeisimmät sidosryhmät ja roolit. Varsinaiset tarkemman tason roolit (lääkäri, esikäsittelijä, ylihoitaja, lu-

18 (42) vanhakija jne.) kuvataan vasta järjestelmien tai tietovarantojen kohde- ja viitearkkitehtuureissa. Osa rooleista ja sidosryhmistä nousee luontevasti esiin vasta palvelujen ja prosessien kuvaamisen yhteydessä. Tarkista ja tarvittaessa täydennä sidosryhmiä ja rooleja palvelujen ja prosessien kuvaamisen yhteydessä. 6.4 Ydinpalvelujen tunnistaminen ja kuvaaminen Tunnistakaa ja kuvatkaa KA-menetelmäpohjaan keskeisimmät kohdealueen substanssitoiminnan ydinpalvelut. Kuvatkaa keskeisten ydinpalvelujen riippuvuudet ja keskinäiset suhteet hyödyntäen Archimate-kuvausmallia. Kokonaisarkkitehtuuriin kuuluu useanlaisia palveluja: Substanssipalvelut = Tässä palveluilla tarkoitetaan substanssitoiminnan ylätason palveluita (palveluryhmät ja ydinpalvelut) o Organisaation arkkitehtuuria kuvattaessa nämä ovat koko organisaation keskeisimmät palvelut Tietojärjestelmäpalvelut = varsinaista substanssitoimintaa tukevat järjestelmillä toteutettavat palvelut o Esim. käyttäjähallintapalvelut, integraatiopalvelut Teknologiapalvelut = laiteteknologian ja muun tekniikan tarvitsemat palvelut o Esim. laitetilat, laitteiden kapasiteettipalvelut, tietoliikennepalvelut, telepalvelut, ns. infrapalvelut (nimipalvelut, proxyt jne.) Tässä askeleessa tunnistetaan erityisesti juuri keskeiset substanssitoiminnan pääpalvelut/ydinpalvelut. Kuntasektorilla organisaatiotason pääpalvelut määräytyvät varsin pitkälti lainsäädännöstä. Lainsäädäntö ei ota juurikaan kantaa palvelujen toteutustapaan, näissä kuntatoimijoilla on vahva autonomia. Kuntatoimijat ovatkin pääpalvelujen pohjalta usein määritelleet organisaation ydinprosessit ja muut toiminnan prosessit. Näitä prosesseja tarkasteltaessa löydetään usein lakisääteisiä pääpalveluja pienempiä osapalveluita (tai palvelukomponentteja), jotka ovat usein keskeisten järjestelmäpalveluiden aihioita. Tässä suhteessa palvelut ja prosessit kietoutuvat toisiinsa. Lähtökohtana ovat tunnistetut asiakkaat ja heidän vaatimuksensa, joita vasten voidaan hahmottaa palveluajatukset asiakasprofiileittain. Yhtenäinen palvelutarjonta edellyttää yhtenäistä toimintamallia ja sujuvaa yhteistyötä palvelun tuottajien organisaatioilta. Organisaatioiden välinen yhteistoimivuus palvelujen suhteen edellyttää yhteistä palveluprosessia ja toiminnan koordinointia. Palveluprosessien kuvaaminen on verrannollinen mihin tahansa prosessin kuvaamiseen.

19 (42) Palveluiden tuottamisessa on tärkeää sisäisen osaamisen kehittäminen palveluajattelun ja palvelutuotannon suhteen sekä asiakkaalle annetun palvelulupauksen varmistaminen. Palveluiden tunnistamisessa huomioidaan seuraavat vaiheet: tunnista palvelut keskeisten organisaation lakisääteisten velvollisuuksien, strategian, tavoitteiden ja sidosryhmien (myös asiakkaat) vaatimusten ja tarpeiden perusteella. määrittele, mihin palvelulla pyritään eli miksi se on olemassa, mitä lisäarvoa se tuottaa organisaatiolle tai sidosryhmille ryhmittele ja nimeä palvelut, jotka toteuttavat organisaatiolle asetettuja tehtäviä ja tavoitteita tunnista palveluiden väliset riippuvuudet muodosta palveluista Archimate-muotoinen palvelukartta kuvaa palvelujen sisältö KA-menetelmän kuvauspohjaan Palveluiden suunnittelussa kannattaa huomioida myös jaa palvelut palvelutyyppien mukaan (esim. JHS 145), mieti palvelun käytön toistuvuutta, käyttötiheyttä (satunnaisesti, kerran kuukaudessa, päivittäin, säännöllisesti mutta harvoin,.) mieti, mikä on palvelun tuotos tai tuotokset sekä mistä raaka-aineesta se rakentuu arvioi palvelun elinkaari mieti, mitä kanavia käyttäen palvelua tarjotaan mitä muita yhteispalveluja käytetään (tunnistamiseen, verkkomaksamiseen, ) tunnista ja analysoi organisaation oma palvelukyky 6.5 Palveluihin liittyvien alipalveluiden mallintaminen Tunnistakaa ja kuvatkaa mallinnustyökaluun tai KA-menetelmäpohjaan ydinpalveluihin liittyvät alipalvelut hyödyntäen. Kuvatkaa hierarkia ja riippuvuudet Archimatekuvaukseen Arvioikaa tarkemmin, mistä alipalveluista edellä kuvatut ydinpalvelut muodostuvat. Määrittäkää täten kohdealueeseen liittyvät alipalvelut. Mallintakaa palveluiden ja alipalveluiden välinen hierarkia. Tunnistakaa tässä vaiheessa alipalveluihin myös varsinaisten substanssi- tai liiketoimintapalveluiden lisäksi keskeiset näitä tukevat palvelut: Hallinnointi- ja tiedonhallintapalvelut Tiedonhallinnan, käyttäjähallinnan ja muut tietoja hallinnoivat palvelut (esim. käyttövaltuuksien ja käyttäjätietojen hallintaa, perustietojen poistamista, ryhmittelyä, täydentämistä, tietohuoltoa ym. koskevat palvelut, hakupalvelut jne.) Johtamista ja seurantaa tukevat palvelut Raportointia, toiminnanohjausta, seurantaprosesseja ym. tukevat palvelut Hallinnointi- ja tiedonhallintapalveluita sekä johtamista ja seurantaa tukevista palveluista voidaan usein tunnistaa juuri tarpeita tietojärjestelmäpalveluille osana varsinaisia ydinpalveluita.

20 (42) Palvelun sähköistämisen tasot Kirjatkaa palvelujen ja alipalvelujen tavoiteltava sähköistämistaso. Sähköistämistasot suositellaan luokiteltavaksi seuraavasti: Taso 0 Ei saatavissa Taso 1 Informaatio Taso 2 Yksisuuntainen vuorovaikutus Taso 3 Kaksisuuntainen vuorovaikutus Taso 4 Transaktio Taso 5 Personointi Palvelua ei ole saatavissa sähköisessä muodossa. Palvelun käynnistämiseen tarvittava informaatio on saatavilla sähköisesti (esim. julkisen verkkosivun kautta) Palvelun käynnistämiseen tarvittava paperinen (tulostettava) lomake on saatavilla julkisen nettisivun kautta. Tämä taso sisältää myös yksinkertaisen sähköisen lomakkeen, jonka käyttö ei vaadi käyttäjän tunnistamista. Palvelu voidaan käynnistää syöttämällä siihen tarvittava informaatio julkisella nettisivulla olevan sähköisen lomakkeen kautta. Palvelun käynnistäminen vaatii henkilön luotettavan tunnistamisen. Koko palvelutapahtuma voidaan suorittaa sähköisesti julkisen verkkosivun kautta. Palveluun liittyvään päätöksentekoon ja toimittamiseen ei tarvita manuaalista paperityötä. Asiakaskeskeiset, käyttäjän tarpeiden mukaan muokattavat palvelut. Julkishallinto kehittää aktiivisesti palvelun laatua ja käyttäjäystävällisyyttä, toimii ennakoivasti palvelun toimittamisessa (esim. hälytykset asiakkaille, tietojen automaattinen täydennys rekistereistä), sekä suorittaa asiakkaan lakisääteiset palvelut automaattisesti, ilman asiakkaan pyyntöä tai vuorovaikutusta. 6.6 Tarvittavien teknologiapalveluiden tunnistaminen Tunnista, mitä erityisiä teknologiapalveluita ja palvelutasoja kyseisen kohdealueen ratkaisut edellyttävät. Kirjaa nämä KA-menetelmän kuvauspohjaan. Teknologiapalveluilla tarkoitetaan tässä yhteydessä laitteisiin ja laiteympäristöihin liittyviä palveluita ja ratkaisuja. Pelkillä sovelluksilla ja niiden riippuvuuksilla ei saada aikaiseksi vielä toimivia kokonaisuuksia vaan tarvitaan laitteita, alustoja, laitetiloja, tietoliikenneverkkoja ja muuta laiteläheistä teknologiaa. Usein teknologiapalveluihin sijoitetaan vielä esim. palvelinten käyttöpalvelun vaatimukset. Tunnista palveluiden keskeisimmät teknologiavaatimukset ja luokat. Tyypillisiä tarvittavia teknologiapalveluita ovat mm: Laitetilavaatimukset Palvelimiin liittyvät palvelut (virtuaalikoneet, palvelimet jne.)

21 (42) Työasemiin tai päätelaitteisiin liittyvät palvelut Tietoliikenteen pääpalvelut (päätasolla erilaiset verkkoympäristöt, etätyöympäristöt jne.) Yleensä ns. perusinfrapalvelut kuvataan vielä tähän osakuvaukseen o Pääsynhallintapalvelut, nimipalvelut, välimuistipalvelut jne. Ympäristöjen jäsennys o Tarvitaanko tuotantoympäristön lisäksi testi-, koulutus-, koekäyttö-, kehitysja/tai raportointiympäristö Yksinkertaisimmillaan teknologiapalveluihin listataan työasema/päätevaatimukset sekä palvelinpalveluiden keskeiset vaatimukset. Käy substanssiasiantuntijoiden kanssa läpi, mitä palvelutasoja teknologiapalveluissa tarvitaan ja esimerkiksi minkälaisia toipumisaikoja tavoitellaan. Voit hyödyntää palvelutasoja arvioitaessa ns. keskeytysvaikutusanalyysiä, jossa arvioidaan, mitä toiminnalle tapahtuu, jos teknologiapalvelu katkeaa. 6.7 Palveluihin liittyvien prosessien tunnistaminen ja prosessiriippuvuuksien mallintaminen 6.7.1 Yleistä Tunnista keskeiset prosessit ja listaa niiden perustiedot. Mallinna keskeisten prosessien keskinäiset suhteet Archimate-kuvaukseen Prosessien tunnistamisessa huomioidaan seuraavat vaiheet: mieti, mikä on prosessin alku ja mihin se päättyy (alkaako se asiakkaasta ja päättyy asiakkaaseen) ryhmittele ja nimeä prosessit Prosessien toimintamallikuvauksessa tulee huomioida seuraavat asiat: kuvaa prosessin omistajat ja tai vastuut kuvaa prosessien tavoitearvot, mittarit ja menestystekijät kuvaa prosessienvälinen vuorovaikutus, työn ohjauksellinen kulku (numeroi prosessit) kuvaa prosesseihin vaikuttavat voimatekijät ja ympäristö kuvaa liittymät asiakkaan prosesseihin, asiakasrajapinta kuvaa liittymät sidosryhmiin kuvaa liittymät taustajärjestelmiin (karkealla tasolla) Tunnista substanssi- ja liiketoimintaprosessien lisäksi näitä täydentävät hallinnointiprosessit sekä johtamis- ja seurantaprosessit (vrt. hallinnointipalvelut sekä johtamis- ja seurantapalvelut edellä).

22 (42) Muita tyypillisiä prosessien jaottelutekijöitä ovat mm käyttötarkoitus tai jako sisäisiin ja ulkoisiin prosesseihin. Joskus prosessit voidaan jakaa myös asiakasprosesseihin ja tuotantoprosesseihin. 6.7.2 Tunnista mitä prosesseja palveluiden tuottamiseen tarvitaan Kuvaa prosessien perustiedot joko KA-menetelmän kuvauspohjaan (prosessikartta) tai erilliseen mallinnustyökaluun. Prosesseista on hyvä taltioida seuraavat tiedot: Prosessin nimi, kuvaus, omistaja, tavoitteet, toimijat, syötteet tuotokset 6.7.3 Mallinna prosessien väliset keskinäiset suhteet (JHS 152 - toimintamallitaso) Mallinna edellisessä vaiheessa tunnistettujen prosessien keskinäiset suhteet ja kuvaa nämä esim. Archimate-kuvauksena graafisesti. 6.7.4 Tunnista prosessiin liittyvät aliprosessit ja mallinna niiden suhteet Mallinna prosesseihin liittyvät aliprosessit ja niiden suhteet ylätason prosesseihin. Kaikkia aliprosesseja ei tarvitse tunnistaa vielä tässä vaiheessa, vaan aliprosesseja voidaan tunnistaa lisää prosessien mallinnusvaiheessa. 6.8 Palveluihin ja prosesseihin liittyvien tietotarpeiden mallintaminen Tunnista palveluiden ja prosessijäsennyksen perusteella, mitä käsitteitä näihin liittyy. Täsmennä näitä karkeiksi tietomalleiksi. 6.8.1 Käsitemallinnus Käsitemalliin kuvataan organisaation ja ko. toiminnon keskeiset käsitteet, jotka voidaan tunnistaa edellä kuvattujen palvelujen ja ydinprosessien sekä prosessikartan avulla. Käsitemallin tehtävänä on hahmotella, minkälaisia peruskäsitteitä kohdealueen toiminnassa käsitellään. Osa käsitteistä määräytyy hierarkisesti. Esim. kunnan yleinen toiminta: kuntalainen, asiakas. Koulutoimessa asiakas tarkentuu sitten käsitteeksi: oppilas tms. Käsitteiden kuvaamisessa on huomioitava kuntatoimijan mahdolliset ns. Master Data Management (MDM)-periaatteet ja linjaukset.

23 (42) Käsitemallissa tulee viitata eri toimialueiden kansallisiin käsitemalleihin, jos näitä on olemassa. Listaa jokaiselle alimman tason prosessille siihen liittyvät käsitteet ja tarvittaessa luo niille hierarkinen malli (käsitemalli). Käsitteet on syytä ryhmitellä kuvattavalla arkkitehtuurialueella luonnostaan olevien ryhmien mukaan, esim. yhteisiin käsitteisiin ja toimialueiden käsitteisiin. Käsitteistä muodostetaan käsitteistö kuvaamalla seuraavat asiat: Käsiteryhmä Käsite Määritelmä Lähde Synonyymi Muuta Listamuotoisen käsitteiden luetteloinnin lisäksi on tärkeää visualisoida käsitemallia kuvaamalla käsitteet ja niiden väliset riippuvuudet joko yhteen tai hierarkiseen kuvaan. Tämä visualisointi suositellaan tehtäväksi käyttäen Archimate-kuvausmalleja. Mikäli palvelun prosesseja ei ole mallinnettu tai prosessit eivät kata kaikkia palveluun liittyviä käsitteitä, tulisi käsitteet listata palvelukohtaisesti. Jaa käsitteet projektikohtaisiin ja yleisiin. Yleisten palveluiden osalta vertaa ovatko käsitteet jo aiemmin määritelty ja voidaanko niitä käyttää tässä yhteydessä. Tarkista tässä vaiheessa onko sidosryhmä- tai roolikuvauksia tarpeen täydentää. 6.8.2 Karkea tietomallinnus Tietomalli on käsitemallin tarkennus, jossa edetään käsitteistä tietotasolle ja kuvataan tietojen väliset riippuvuudet sekä tarkempi tietosisältö. Tarkenna tarvittaessa käsitteisiin liittyviä tietoja. Selvitä mitä olemassa olevia tietomalleja ja tietoja palveluihin ja prosesseihin liittyy. Kuvaa palveluiden ja prosessien tarvitsemat tiedot tässä vaiheessa pelkästään karkealla tasolla. Tietomallit kannattaa kuvata esim. UML 1 -kuvausnotaatiolla pitäen silmällä jo tässä vaiheessa mahdollinen mallintaminen tietokantoihin tai muihin tietovarantoihin. Tietosisällön keskeisiä osia ovat: Tiedon jäsennys loogisiin tietoelementteihin (käsitetasoa tarkemmin lähestyy tietokantojen taulurakennetta) Yksittäisten tietojen tarkemmat elementit, kentät Tietojen väliset riippuvuudet 1 Unified Modeling Language

24 (42) Arkkitehtuurissa sallitaan tietomallissa jonkin verran karkeistusta. Tietoja ei välttämättä tarvitse esittää tässä vaiheessa kenttien tyyppi- ja arvotasolla. Tämä tieto täydennetään tarkemmassa suunnittelussa. Keskeisiä tietomallien hyödyntäjiä ovat tietokantojen ja tietovarantojen kehittäjät ja hyödyntäjät. Erityisen hyödyllisiä tietomallikuvaukset ovat tietokantojen kehittäjien lisäksi myöhemminkin tietovarastoratkaisujen kehittäjille. 6.9 Prosessien käsitteellisen tason mallintaminen 6.9.1 Yleistä Kuvaa prosessikarttaan tunnistetut prosessit BPMN-notaation mukaisina prosessikuvauksina. Prosessien käsitteellisen tason mallintamisella tarkoitetaan prosessien toiminnan kuvaamista tietojärjestelmäriippumattomasta näkökulmasta. Päätehtävänä on mallintaa palvelujen toteuttamisiin tarvittavien prosessien toimenpiteet ja toimintalogiikka. Mikäli prosesseihin liittyy tietojärjestelmiä, on malleista hyvä käydä ilmi järjestelmien käyttötilanteet ja potentiaaliset tietojärjestelmien hyödyntämismahdollisuudet. Prosessin toimenpiteitä ei kuitenkaan yleensä sidota tässä vaiheessa toteutusta tarjoaviin tietojärjestelmiin, vaan päätös tietojärjestelmien hyödyntämisestä tehdään myöhemmissä vaiheissa. Tämä mallinnustaso vastaa MDA:n CIM-tasoa (computation independent model). MDA:n mallinnustasoja käydään tarkemmin läpi Kuntasektorin teknologialinjauksissa [4]. Prosessiin kuuluvia toimenpiteitä ja toimintalogiikkaa sekä tarkempia työnkulkuja kannattaa mallintaa julkishallinnon suositusten mukaisesti BPMN-notaatiolla (JHS 152). BPMN soveltuu hyvin prosessien yksityiskohtaiseen mallintamiseen ja tukee SOA-palveluiden löytämistä ja johtamista prosessimalleista Toimntalogiikkaa kuvaavissa prosessimalleissa tulee esittää vastaavat asiat kuin prosessien yleistiedoissa, mutta yksityiskohtaisemmin. Prosessien ja vaiheiden kuvaamisessa tulee huomioida seuraavat asiat: Kuvaa valitun prosessin jakautuminen osaprosesseiksi toiminnoiksi ja tarvittaessa tehtäviksi Nimeä prosessit, toiminnot ja tarvittaessa tehtävät Kuvaa prosessin, toiminnon tai tehtävän tarkoitus Kuvaa palveluiden ja prosessienvälinen vuorovaikutus, työn ohjauksellinen kulku (numeroi prosessit ja osaprosessit ja tehtävät hierarkkisesti) Kuvaa prosesseihin vaikuttavat voimatekijät ja ympäristö Liittymät asiakkaan prosesseihin (asiakas on nimetty, esim. kansalainen) Liittymät sidosryhmiin Liittymät taustajärjestelmiin Kuvaa prosessin, osaprosessin, toiminnon, tehtävän saamat syötteet ja tiedot Kuvaa prosessin, osaprosessin, toiminnon, tehtävän tuottamat lopputulokset ja tuotokset Kuvaa viestit myös muille sidosryhmille, prosesseille ja taustajärjestelmille Kuvaa prosessin ja osaprosessin omistajat ja vastuut, tehtävissä suorittajan roolit

25 (42) Kuvaa prosessin ja osaprosessien mittaaminen (miten mitataan ja millä tavoitearvoilla) Prosessimallinnus muodostuu prosessikaavioista sekä niitä täydentävistä tekstimuotoisista prosessikuvauksista. Tekstimuotoiset prosessikuvaukset voidaan liittää myös prosessikaavioon, mikäli mallinnustyökalu tukee riittävän kattavasti tekstimuotoisia prosessikuvauksia ja niiden raportointia. Tällöin mallinnustyökalun tulisi tukea mallipohjien käyttöä eli syötettävälle tiedolle pitää pystyä luomaan yhtenäinen rakenne lomakepohjia vastaavalla tavalla. 6.9.2 Prosessien toimintalogiikan BPMN-mallinnus Prosessien toiminta tulisi mallintaa BPMN-mallinnuskielellä JHS 152 suositusten mukaisesti. BPMN-standardi ja JHS 152 suositukset eivät sisällä menetelmäkuvauksia eivätkä ne kuvaa minkälaisia prosessimalleja BPMN-notaatiolla tulisi tehdä. Palvelukeskeinen arkkitehtuuri asettaa vaatimuksia prosessitoteutuksille ja ohjaa näin myös prosessimallinnusta. SOA ei kuitenkaan suoraan määrittele minkälaisia prosessimalleja SOA:n mukaisiin prosessitoteutuksiin pääsemiseksi pitää tehdä. Merkittäviä lisävaatimuksia prosessimallinnukselle aiheuttaa BPEL-prosessimoottorien käyttäminen prosessien toteutuksessa. Prosessimoottorit tuovat merkittäviä hyötyjä prosessien mittaamiseen ja tekniseen joustavuuteen. Ne auttavat näin merkittävästi myös kokonaisarkkitehtuurin kehittämisessä ja tukevat mm. arkkitehtuurikyvykkyyden parantamisessa (prosessimoottoreita on käsitelty tarkemmin Kuntasektorin teknologialinjauksissa [4] ja arkkitehtuurikyvykkyyttä dokumentissa Kuntasektorin arkkitehtuurikyvykkyyden kypsyystasomalli [3]). Prosessimoottoreiden käyttö tuo kuitenkin merkittäviä reunaehtoja ja vaatimuksia prosessien mallintamiseen. Näitä vaatimuksia käsitellään alakohdassa 6.9.5. 6.9.3 Yleiset ohjeet prosessimallinnukselle Ennen prosessimallinnuksen aloittamista on tärkeää määritellä mallinnustyön tavoitteet. Tässä dokumentissa prosessimallinnuksen keskeisiksi tavoitteiksi on asetettu prosessien kehittäminen ja laadullinen parantaminen. Tämä linjaus vaikuttaa merkittävästi tässä vaiheessa kuvattuihin mallinnusohjeistuksiin. Esimerkiksi JHS 152 suosituksissa käytettyä toimijakohtaista mallinnusta voidaan käyttää näiden ohjeiden tukena, mutta yksinään sitä ei suositella käytettävän. Tähän tapaan liittyviä ongelmia käsitellään tarkemmin kohdassa 6.9.5. Prosessimallinnuksessa tulee kiinnittää huomiota seuraaviin asioihin: Prosessimallinnuksen tavoitteet ja lähtökohdat. Onko mallinnuksessa keskitytty prosessin tavoitteiden, mittaamisen ja kehittämisen kannalta oleellisiin asioihin. Sisältääkö malli näiden asioiden suhteen vähemmän oleellisia tietoja, esim. kolmansien osapuolien toimenpiteitä, jotka eivät tähän prosessiin ja tavoitteisiin suoraan liity. Prosessin tietotarpeet. Käyvätkö prosessiin liittyvät käsitteet ja prosessin tarvitsemat tiedot (karkealla tasolla) prosessimallista ilmi. Tarvittaessa näitä voidaan mallintaa myös prosessirakenteita kuvaavissa Archimate-muotoisissa malleissa. Prosessin laajuus ja elinikä. Onko prosessin laajuus riittävä, käykö prosessin alkaminen ja päättymistilanteet selkeästi ilmi.

26 (42) Prosessin päättymisen varmistaminen jokaisen altaan osalta ja päättymisehtojen läpikäynti. Symboleiden käytön yhdenmukaisuus. Nimeämiskäytäntöjen noudattaminen (ks. kohta 3). Mallielementtien yhdenmukaiset nimet kaikkien kokonaisarkkitehtuuriin kuuluvien mallien osalta. Samaan asiaa ei tule viitata eri nimillä. BPMN-määrityksien noudattaminen. Lisäksi on suositeltavaa, että mallinnuksessa noudatetaan seuraavia periaatteita: Prosessi alkaa ja päättyy aina tapahtumalla Mikäli prosessi alkaa viestin (esim. hakemus) vastaanotolla, aloitussymbolina käytetään viestityyppistä alkutapahtumaa, ei tyypittömän alkutapahtuman ja toimenpiteen yhdistelmää. Mikäli prosessi päättyy viestin (esim. lopputulos) lähettämiseen, lopetussymbolina käytetään viestityyppistä lopputapahtumaa, ei toimenpiteen ja tyypittömän lopputapahtuman yhdistelmää Prosessissa käytetään aina haarautumiseen ja virtojen yhdistämiseen porttisymbololeita (ei kontrolloimattomia virtoja) Pyri tekemään valinnat ja haarautumiset (porttisymboli) mahdollisimman lähellä näihin liittyviä toimenpiteitä ja tapahtumia. Mikäli on epäselvää esim. mihin tietoon tai aikaisempaan toimenpiteeseen valinta kohdistuu, voidaan porttisymbolin eteen liittää valintaa tukeva toimenpide (esim. tarkasta loma-anomustiedot). Tarvittaessa asiaa voidaan selventää myös BPMN-kielen mukaisella tekstiannotaatiolla. Prosessi ei voi päättyä ilman loppusymboliin päätymistä (minkä tahansa tyyppinen lopputapahtuma) kuin harvinaisissa poikkeustapauksissa Mallin sisältämät toimenpiteet numeroidaan ja ne vastaavat prosessin muissa kuvauksissa käytettyä numerointia Prosessien mallintamisessa tulisi pyrkiä mallien ymmärrettävyyteen, minkä vuoksi mallielementtejä tulisi käyttää yhdenmukaisella tavalla. Jos mallissa käytetään esimerkiksi viestitapahtumasymbolia (ks. kuva 8) viestin vastaanottamisen kuvaamiseen, pitää näin toimia mallissa kauttaaltaan. Viestin vastaanotto voidaan kuvata usein sekä toimenpiteenä (BPMN task) että viestitapahtumana. Viestitapahtuma on aina yhdensuuntainen (joko lähetys tai vastaanotto), mutta toimenpide voi olla joko yksi- tai kaksisuuntainen. Kaksisuuntaista toimenpidettä tulee käyttää tilanteissa, jossa viestitys halutaan mallintaa synkronisena eli lähettäjä jää odottamaan paluuviestiä lähettämäänsä viestiin. Tällöin toimenpide katsotaan suoritetuksi vasta paluuviestin vastaanottamisen jälkeen. Tämä on hyvä huomioida myös toimenpiteen nimeämisessä (esim. hae jotain on parempi nimi kaksisuuntaiselle toimenpiteelle kuin lähetä jotain ). Asynkronisen viestin lähettämis- ja vastaanottosymbolin valintaan voidaan hyödyntää luvun 3 nimeämiskäytäntöjä. Esim. mallin (kuva 8) päivähoitopäätös vastaanotettu -tapahtuma pitää muuttaa muotoon vastaanota päivähoitopäätös, jos tapahtuma muutetaan toimenpiteeksi. Prosessimallin laajuus tulee määritellä ennen mallinnustyön aloittamista. Joskus voi olla hankalaa päättää mistä prosessin tulisi alkaa ja mitä kaikkea siihen tulisi liittää. Esimerkiksi pitäisikö lomahakemusten käsittelyprosessin käsittää koko hakemus vai pelkästään siihen kuuluvat lomajaksokohtaiset anomukset. Samoin ongelmia voi ilmetä prosessin aloittamiskohdasta. Tuleeko prosessi aloittaa vasta hakemuksen vastaanotosta vai siitä kun hakemuslomake välitetään loman hakijalle. Näiden määrittelyssä voidaan monesti käyttää apu-