JHS 179 ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurin kehittäminen

Transkriptio

1 JHS 179 ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurin kehittäminen Versio: luonnos Julkaistu: Voimassaoloaika: toistaiseksi Sisällys 1 Johdanto ICT-palvelujen kehittäminen -suositussarja Organisaation kokonaisarkkitehtuurilähtöinen toiminnan kehittäminen Suosituksen sisältö ja rakenne Soveltamisala Termit ja määritelmät Arkkitehtuurikehys Kokonaisarkkitehtuurin suunnitteluprosessi Kokonaisarkkitehtuurin suunnittelun valmistelu Kokonaisarkkitehtuurin nykytilan analysointi Kokonaisarkkitehtuurin tavoitetilan suunnittelu Toimeenpanon suunnittelu Arkkitehtuurikuvausten tuottaminen Arkkitehtuuriperiaatteet ja linjaukset Nykytilan ja tavoitetilan kuvaus Standardit Toiminta-arkkitehtuurin suunnittelu Tietoarkkitehtuurin suunnittelu Tietojärjestelmäarkkitehtuurin suunnittelu Teknologia-arkkitehtuurin suunnittelu Opastavat tiedot Liitteet /34

2 1 Johdanto Tässä suosituksessa määritellään menetelmä, jolla organisaation kokonaisarkkitehtuuri suunnitellaan sekä annetaan suositukset kokonaisarkkitehtuurin eri osa-alueiden kuvausten laatimisesta. Suosituksen tarkoituksena on antaa yhtenäinen suunnittelumenetelmä, suunnittelun viitekehys sekä yhtenäiset kuvaustavat ja -mallit julkisen hallinnon organisaatioiden kokonaisarkkitehtuurin kehittämiseen sen eri vaiheissa. Suosituksen mukaan toimitaan sekä organisaation kokonaisarkkitehtuurin kuvaamisen ensimmäisellä kierroksella että kehittämisen seuraavilla iteraatiokierroksilla. Tässä suosituksessa annettavina kokonaisarkkitehtuurin kehittämisen ydinkohtina voidaan pitää seuraavia suosituksia: organisaation nykytilan arkkitehtuuri tulee kuvata tämän suosituksen mukaisesti. organisaation tavoitetilan arkkitehtuuri tulee kuvata tämän suosituksen mukaisesti. kokonaisarkkitehtuurin kaikkien osa-alueiden kehittämisestä tulee laatia ylätason toimeenpanosuunnitelma tämän suosituksen mukaisesti. Yksittäiset, tarkemmat hanke- ja kehittämissuunnitelmat laaditaan JHS 171 ICT-palvelujen kehittäminen: Kehittämiskohteiden tunnistaminen -suosituksen mukaisesti. kaikissa kehittämisprojekteissa tulee noudattaa tämän suosituksen perusteella tehtyjä tavoitetilan arkkitehtuurikuvauksia. organisaation nykytilan arkkitehtuurikuvaukset tulee päivittää kehittämisprojektien tuotoksien perusteella. Arkkitehtuurimenetelmällä luotujen linjausten ja kuvausten käyttö ja varsinkin niiden ylläpito vaativat, että organisaatio toimii kehitystyössä järjestelmällisesti noudattaen organisaatiossa sovittua arkkitehtuurin hallintamallia. Arkkitehtuurin hallintamalli koostuu organisaation yhteisesti sopimista periaatteista liittyen arkkitehtuurilähtöisen kehittämisen organisointiin (kokonaisarkkitehtuurista ja arkkitehtuurinäkökulmista vastaavien tahojen määrittely). kokonaisarkkitehtuurin johtamiseen (arkkitehtuurin kehittäminen ja käyttöönoton ohjaus). arkkitehtuurin hyödyntämiseen ja noudattamiseen (ratkaisujen elinkaaren hallinta). Tässä suosituksessa ei erikseen anneta suosituksia arkkitehtuurin hallintamallin toteuttamisesta, vaan organisaation on luotava sellainen itse. Esimerkkinä voi käyttää ValtIT:n luomaa arkkitehtuurin hallintamallia ( tehtuurin_hallintamalli.pdf ) tai TOGAF 9:n arkkitehtuurin hallintaan (Architecture Governance) liittyviä osioita F-H ( 2/34

3 Kuva 1 Kokonaisarkkitehtuurin suunnittelu, hallinta ja toteutus 1.1 ICT-palvelujen kehittäminen -suositussarja Tämä suositus on osa ICT-palvelujen kehittäminen -suositussarjaa (kts. kuva 2) ja se täydentää muita sarjan suosituksia antamalla pohjan suosituksissa kuvatulle arkkitehtuuriohjatulle organisaation toiminnan kehittämiselle. Muita ICT-palvelujen kehittäminen sarjan suosituksia ovat: JHS 171 ICT-palvelujen kehittäminen: Kehittämiskohteiden tunnistaminen. JHS 172 ICT-palvelujen kehittäminen: Esiselvitys. JHS 173 ICT-palvelujen kehittäminen: Vaatimusmäärittely. Kehittämiskohteiden tunnistaminen -suositus opastaa kokonaisarkkitehtuurin suunnittelun yhteydessä havaittujen kehittämiskokonaisuuksien yksityiskohtaisempien kehittämiskohteiden tunnistamisessa ja kuvaamisessa, kun taas esiselvitys-suositus antaa suositukset tietoteknisen ratkaisun esiselvitysvaiheen suorittamiseen. Vaatimusmäärittely-suositus jatkaa arkkitehtuuriohjattua toiminnan kehittämistä antamalla suositukset kehitettävän ratkaisun vaatimusten määrittelystä ja niiden priorisoinnista ennen mahdollista järjestelmähankintaa. 3/34

4 Kuva 2 ICT-palvelujen kehittäminen suositukset Kokonaisarkkitehtuurin kuvausvaiheessa tehdyt nyky- ja tavoitetilan kuvaukset auttavat hahmottamaan organisaation arkkitehtuurin eri osa-alueita kehittämisen eri vaiheissa ja ne antavat pohjan tarkempia kehittämisalueita ja -ratkaisuja kuvattaessa ja suunniteltaessa. Nyky- ja tavoitetilan kuvausten pohjalta tehty toimenpidesuunnitelma kehittämisen osa-alueista antaa pohjan organisaation TTS-suunnittelulle (toiminta- ja taloussuunnittelu), jonka perusteella kehittämishankkeet ja -projektit käynnistetään. Vastaavasti esimerkiksi vaatimusmäärittelyvaiheessa koostetut tarkennetut kehittämisvaatimukset sekä hankinnan jälkeen tehdyt toteutus- ja käyttöönottovaiheet tuottavat syötteen kokonaisarkkitehtuurin nykytilan kuvausten päivittämiselle ja mahdollisten uusien tavoitetilan vaatimusten syntymiselle. Kokonaisarkkitehtuurin kehittäminen osana ICT-palvelujen kehittämisprosessia rakentuu siis iteratiivisesta prosessista, joka alkaa kehitettävän kohteen tai toiminnan tavoitetilan määrityksestä, jatkuu kohteen tarkemmilla kuvauksilla ja etenee aina muutosten toteuttamiseen ja tehtyjen muutosten hallintaan, kuten kokonaisarkkitehtuurin nykytilan päivitykseen. 1.2 Organisaation kokonaisarkkitehtuurilähtöinen toiminnan kehittäminen Kokonaisarkkitehtuurilähtöinen organisaation toiminnan kehittäminen lähtee johtamisprosessista, jonka osana tätäkin suositusta tulee hyödyntää. Organisaation johto asettaa kehittämisen vaatimukset strategiaprosessin mukaisesti ja se vastaa kokonaisarkkitehtuurilähtöisen kehittämisen johtamisesta ja hallinnoinnista. Kokonaisarkkitehtuurin suunnitteluprosessi saa syötteen strategiaprosessista ja vastaavasti suunnittelun tulokset toteutetaan TTS-suunnittelun kautta käynnistettävänä kehittämiskohteiden tunnistamistyönä tai kehittämishankkeina (kts. kuva 3). Kokonaisarkkitehtuurin suunnittelu ei ole kertaluontoinen projekti, vaan se on jatkuva prosessi, jonka aikana arkkitehtuuria ylläpidetään ja muokataan muuttuvien tavoitteiden, yhteentoimivuudelle asetettujen vaatimusten sekä uusien palveluiden perusteella. Organisaation kehittämishankkeiden ja arkkitehtuurin kehittämisen aikana saadut kokemukset muodostavat kokoelman parhaita käytäntöjä. Tieto parhaista käytännöistä välittyy eri tahoille käytännön projektien ja arkkitehtuurin kehittämistahojen välisen vuorovaikutteisen yhteistyön kautta. 4/34

5 Kuva 3 Kokonaisarkkitehtuurin suunnittelu osana strategiaprosessia ja TTS-suunnittelua Tässä suosituksessa kuvattu kokonaisarkkitehtuurin suunnitteluprosessi (kts. kuva 3) koostuu seuraavista vaiheista: Kokonaisarkkitehtuurin suunnittelun valmistelu (mihin tähdätään?) - Valmistele ja organisoi organisaation johdolta saatujen strategisten toiminnan kehittämisen vaatimusten ja muiden kehittämisvaatimusten pohjalta kokonaisarkkitehtuurin kehittäminen ja suunnittelun eteneminen (kts. luku 5.1). - Määrittele ja tarkenna myös suunnittelussa käytettävät arkkitehtuuriperiaatteet. Tarkenna myös arkkitehtuurin hallintamalli tai mikäli sitä ei ole vielä olemassa, määrittele ja hanki organisaation tarvittavilta tahoilta sille vahvistus. Kokonaisarkkitehtuurin nykytilan analysointi (missä nyt mennään?) - Tarkista ja analysoi organisaation nykytilan arkkitehtuurikuvaukset. Mikäli kuvauksia ei ole olemassa, tee kuvaukset tämän suosituksen mukaisesti. (kts. luku 5.2). Kokonaisarkkitehtuurin tavoitetilan suunnittelu (millaisilla ratkaisulla tavoite saavutetaan?) - Suunnittele ja kuvaa organisaation toiminnan tavoitetila huomioiden mm. arkkitehtuurille asetetut periaatteet, strategiset vaatimukset, lainsäädäntö sekä sidosryhmät (kts. luku 5.3). - Tee tavoitetilan kuvaukset tämän suosituksen mukaisesti. - Täsmennä kuvaukset toteutuksen ja käyttöön oton jälkeen toteutuneen ratkaisun kuvauksella. Ne muodostavat pohjan seuraavien suunnittelukierrosten nykytilan kuvauksille. Toimeenpanon suunnittelu (miten ratkaisuun päästään?) - Kokoa ylätason toimeenpanosuunnitelmaksi nykytilan ja tavoitetilan kuvauksien yhteydessä tarkentuneet, strategiaan ja periaatteisiin perustuvat kehittämisen osa-alueet (kts. luku 5.4). 5/34

6 - Toteuta toimeenpanosuunnitelmaan kootut kehittämiskohteet TTS-suunnittelun kautta perustettavina kehittämishankkeina ja -projekteina. - Tarkenna yksittäiset kehittämiskohteet JHS 171 ICT-palvelujen kehittäminen: Kehittämiskohteiden tunnistaminen -suosituksen kuvaamalla tavalla. Tässä suosituksessa kuvattu lähestymistapa tehostaa organisaation toiminnan kehittämistä tarjoamalla työkaluja organisaation nykytilan ymmärtämiseen ja toimintaympäristön hallinnan parantamiseen. Lähestymistapa mahdollistaa myös, että kehittämisen suunnittelusta tulee järjestelmällisempää ja että organisaation eri tasoilla tapahtuva kehittämistyö pysyy linjassa kokonaisuuden kehittämisen kanssa. Erityisasemassa tässä lähestymistavassa on tieto- ja viestintäteknologian hyödyntäminen sekä niiden tehokas integroituminen toiminnan prosesseihin ja organisaation tavoitteisiin. Lähtökohtana arkkitehtuurilähtöiselle organisaation toiminnan kehittämiselle on, että organisaation rakenteet, kuten prosessit, tiedot ja järjestelmät on kartoitettava ja niiden vuorovaikutussuhteet ymmärrettävä, ennen kuin niitä voidaan käsitellä kokonaisuutena. Tämä on myös vaatimuksena toiminnan optimoinnille. Tässä suosituksessa organisaation rakenteiden tarkastelu ja niiden suunnittelu tapahtuu eri arkkitehtuurinäkökulmien kautta (kts. luku 4 Arkkitehtuurikehys). Arkkitehtuurin johtamisesta lähtevillä periaatteilla ja linjauksilla taas ohjataan arkkitehtuurin kehittämistä tavoitteiden mukaisiin ratkaisuihin. Tarve kokonaisarkkitehtuurilähtöiseen organisaation toiminnan kehittämiseen kasvaa yleensä organisaation koon ja iän kasvaessa. Organisaation pitkän kehittymisen tuloksena muodostuu laajoja ja monimutkaisia organisointimalleja sekä järjestelmäratkaisuja, joiden yhteys- ja vaikutussuhteita on vaikea ymmärtää ja hallita ilman kokonaisarkkitehtuurilähtöisen kehittämisen mukanaan tuomia konkretisoivia välineitä (mm. yhtenäinen kuvausprosessi ja kuvaustavat). Arkkitehtuurilähtöisen organisaation toiminnan kehittämisen suunnittelu ja yhtenäinen mallintaminen ja kuvaus tekevät organisaation toiminnan eri osa-alueista näkyviä. Näkyvyyden myötä kehittämisasioista voidaan keskustella ja sopia tarvittavien sidosryhmien kesken tehokkaasti ja ymmärrettävästi. Arkkitehtuurilähtöinen toiminnan kehittäminen edistää siis osaltaan organisaatioiden välistä yhteistyötä sekä yhteentoimivuutta. Arkkitehtuurilähtöisen toiminnan kehittämisen hyödyistä ja kehittämissyklistä lisää liitteissä 1 Organisaation toiminnan kehittämisen sykli sekä 3 Arkkitehtuurisuunnittelun hyödyt. 1.3 Suosituksen sisältö ja rakenne Tämä suositus koostuu suositusosasta sekä yhdeksästä liitteestä: Suositusosa: Johdanto-luvussa kuvataan suosituksen suhde muihin kokonaisarkkitehtuurilähtöisen kehittämisen JHSsuosituksiin (ICT-palvelujen kehittäminen -suositussarja) sekä kokonaisarkkitehtuurilähtöisen kehittämisen perusteet. Arkkitehtuurikehys-luvussa esitellään suositeltu arkkitehtuurikehys. Arkkitehtuurikehys toimii nimensä mukaisesti organisaation kehittämistoiminnan kehyksenä antaen puitteet tehtäville kuvauksille ja kuvausten tasoille. Kokonaisarkkitehtuurin suunnitteluprosessi -luvussa kuvataan kokonaisarkkitehtuurin suunnitteluprosessin eri vaiheet sekä vaiheissa suoritettavat toimenpiteet. Suosituksessa kuvatun prosessin mukaisesti voidaan toimia niin ensimmäisellä arkkitehtuurin suunnittelukierroksella, kuin myös sitä seuraavilla iteraatiokierroksilla. Kokonaisarkkitehtuurin suunnittelussa tunnistettujen kehittämisalueiden tarkentamisessa ennen kehittämisen hankkeistamista hyödynnetään JHS 171 -suosituksessa kuvattua prosessia. 6/34

7 Arkkitehtuurikuvausten tuottaminen -luvussa annetaan suositukset eri arkkitehtuurinäkökulmien kuvaukseen ja kuvauksessa käytettävien kuvien, mallien tai matriisien toteuttamiseen. Liitteet : Liitteen 1 tarkoituksena on syventää suosituksen lukijan tietämystä arkkitehtuuriohjatusta organisaation kehittämisestä ja kehittämisen syklistä sekä sen käytöstä johtamisprosessissa. Liitteessä 2 kuvataan tarkemmin suosituksessa käytetty arkkitehtuurikehys sekä sen eri ulottuvuudet. Liitteessä 3 kuvataan arkkitehtuuriohjatun kehittämisen yleisiä hyötyjä sekä eri arkkitehtuurinäkökulmista tehtyjen kuvausten ja -mallien tuomia hyötyjä. Liitteessä 4 annetaan suosituksia nykytilan ja tavoitetilan kuvauksien tekemiseksi. Nykytilan ja tavoitetilan kuvauksissa suositellaan myös hyödynnettäväksi JHS 171 -suositusta, kun on kyse kokonaisarkkitehtuurin suunnittelussa havaittujen kehittämisalueiden ja -kohteiden jatkoselvityksistä ja kuvauksista. Liitteessä 5 annetaan suosituksia arkkitehtuuriperiaatteiden kuvauksessa. Arkkitehtuuriperiaatteiden kuvaus on olennainen osa kokonaisarkkitehtuurin kuvausta ja arkkitehtuurin hallintaa. Liitteessä 6 esitellyn Puuteanalyysi-matriisin avulla nykytilan ja tavoitetilan kuvausten väliset erot kuvataan selkeästi ja systemaattisesti taulukkomuodossa. Liitteessä 7 on kuvattu ydintiedonhallinnan (Master Data Management) periaatteet ja hyödyt. Ydintiedonhallinnan kuvaaminen on osa tietoarkkitehtuurin kuvauksia. Liitteestä 8 löytyy tässä suosituksessa esiteltyihin arkkitehtuurien kuvaustapoihin liittyvät kuvauspohjat ja - taulukot. Niitä käytetään kokonaisarkkitehtuurin periaatteiden ja eri arkkitehtuurinäkökulmien kuvaamisessa. Liitteestä 9 löytyy suosituksessa esiteltyihin arkkitehtuurien kuvaustapoihin liittyvät matriisit eli eri näkökulmien välisten osa-alueiden suhteiden kuvaamiseen liittyvät taulukot. 2 Soveltamisala Tämä suositus ohjaa organisaatioita kokonaisarkkitehtuurilähtöiseen kehittämiseen ja arkkitehtuurisuunnitteluun sekä arkkitehtuurin ylläpitoon liittyvässä prosessissa. Tässä suosituksessa kuvattua arkkitehtuurin suunnitteluprosessia ja kuvausmalleja tulee hyödyntää organisaation kokonaisarkkitehtuurin suunnittelussa ja arkkitehtuurikuvausten tuottamisessa. Suosituksessa kuvattu kokonaisarkkitehtuurin suunnitteluprosessi toimii sekä ensimmäisellä suunnittelukerralla että sitä seuraavilla iteraatiokierroksilla. Suosituksen kohderyhmiä ovat organisaation strategiasta vastaava taho (ts. toimiva johto). organisaation arkkitehtuurista vastaavat henkilöt (arkkitehdit). toiminnan kehittämisestä vastaavat henkilöt. tietojärjestelmien hankinnasta päättävät tai tietojärjestelmiä hankkivat henkilöt. projektipäälliköt. tiedosta ja tiedonhallinnasta vastaavat henkilöt. toiminnasta ja toimintaprosesseista vastaavat henkilöt. 7/34

8 3 Termit ja määritelmät JUHTA - Julkisen hallinnon tietohallinnon neuvottelukunta arkkitehtuurikehys Jäsennysmalli, jonka mukaan organisaation rakenteita jäsennetään, hallitaan ja kehitetään. Se kuvaa käytettävät arkkitehtuurin näkökulmat ja tasot. Arkkitehtuurikehys voi olla valmis jäsennysmalli (esim. Zachman Framework, TOGAF) tai organisaation omaan käyttöön räätälöity arkkitehtuurirakenteiden jäsennys. arkkitehtuurimenetelmä Toimintamalli, jonka avulla kehitetään suunnitelmallisesti ja systemaattisesti arkkitehtuurikokonaisuutta tai sen rajattua osaa. Tässä suosituksessa kuvatun arkkitehtuurimenetelmän avulla suunnitellaan ja kuvataan organisaation kokonaisarkkitehtuuri. Kokonaisarkkitehtuurin suunnittelun yhteydessä havaittujen kehittämisalueiden ja kohteiden tarkempi suunnittelu toteutetaan JHS 171 -suosituksen mukaisesti edeten. arkkitehtuurinäkökulma Arkkitehtuuria suunnitellaan eri näkökulmista niitä tilanteen ja suunniteltavan kohteen mukaisesti painottaen. Suunnittelu voi keskittyä vain yhteen näkökulmaan tai yhdistää useamman näkökulman. Arkkitehtuurinäkökulmat ovat toiminta-arkkitehtuurin näkökulma, tietoarkkitehtuurin näkökulma, tietojärjestelmäarkkitehtuurin näkökulma ja teknologia-arkkitehtuurin näkökulma. arkkitehtuuriperiaate Periaate tai linjaus, jolla ohjataan kehittämistä ja toteutusta tavoitteellisesti linjausten mukaisiin arkkitehtuuriratkaisuihin. arkkitehtuuriviitekehys Kts. arkkitehtuurikehys. hallintamalli Arkkitehtuurin hallintamalli käsittää roolien ja vastuiden määrittelyn, organisoinnin sekä johtamisen ja hyödyntämisen prosessit (ohjausmalli) sekä toimintamallin (tässä suosituksessa kuvattu arkkitehtuurimenetelmä). Arkkitehtuurin hallintamallia noudattaen hallinnon toimijat kehittävät, hyödyntävät ja ylläpitävät arkkitehtuuria sekä virasto- ja hallinnonalatasolla että koko hallinnon organisaation tasolla. kohdearkkitehtuuri Organisaation rajatun toiminnallisen osa-alueen (esim. prosessin tai toiminnon) arkkitehtuurikokonaisuus. Kohdearkkitehtuuri sisältää kaikki arkkitehtuurikehyksen näkökulmat (toiminta, tieto, tietojärjestelmät, teknologia) rajatun kohteen alueelta. kokonaisarkkitehtuuri Kokonaisarkkitehtuuri on toiminnan, prosessien ja palvelujen, tietojen, tietojärjestelmien ja niiden tuottamien palvelujen muodostaman kokonaisuuden rakenne. Kokonaisvaltainen lähestymistapa organisaation toiminnan ja sen rakenteiden hallinnoimiseksi ja kehittämiseksi. MD, Master Data Master Dataksi eli ydintiedoksi luokitellaan tieto, jota käytetään useassa käyttökohteessa samanlaisena tai jota useampi prosessi/toiminto tarvitsee tai hyödyntää. Ydintieto on pysyväisluonteista tietoa, joka kuvaa tietokokonaisuuksia, joista on tai josta tulisi olla yhtenäinen käsitys koko organisaatiossa ja joka on samalla avaintietoa organisaation toiminnalle. Ydintietoa on yleisesti asiakas-, tuote-, henkilöstö-, materiaali- ja toimittajatieto jne. MDM, Master Data Management MDM on toiminto ja prosessi joka hallinnoi, korjaa ja ylläpitää toiminnan edellyttämän Master Datan eli ydintiedon. Sen tehtävänä on huolehtia riittävästä ydintiedon laadusta, jotta raportointi ja seuranta voidaan pitää luotettavana ja yksikäsitteisenä. 8/34

9 referenssiarkkitehtuuri Kts. viitearkkitehtuuri. JUHTA - Julkisen hallinnon tietohallinnon neuvottelukunta sanasto Sanastolla tarkoitetaan yleensä luetteloa jossain kielessä tai ympäristössä sallituista sanoista (termeistä) luokitteluineen, määritelmineen, kuvauksineen ja esimerkkeineen. Sanastotyyppejä ovat muun muassa terminologiset sanastot, asiasanastot, ontologiat sekä tietojärjestelmien ja sovellusten integrointia tukevat sanastot. sidosarkkitehtuuri Sidosarkkitehtuurit ovat muualla määritettäviä arkkitehtuurilinjauksia, joilla on tai voi olla vaikutusta kyseisen organisaation tai toimialueen arkkitehtuurityöhön ja -linjauksiin ontologia Ontologioilla määritellään tietyn aihealueen käsitteistöjä. Usein ne muodostetaan olemassa olevien sanastojen avulla. Ontologioilla määritellään käsitteet ja niiden suhteet. teknologia-arkkitehtuuri (technology architecture) Kokonaisarkkitehtuurin näkökulma, joka kuvaa organisaation teknologista infrastruktuuria ja järjestelmäarkkitehtuurin teknologiavalintoja. Teknologia-arkkitehtuurin suunnittelussa linjataan käytettävät tekniset järjestelmien ja ICT-infrastruktuurin ratkaisuvaihtoehdot, standardit ja rakenteet siten, että kokonaisuus tukee parhaalla mahdollisella tavalla organisaation tavoitteita. tietoarkkitehtuuri (data architecture) Kokonaisarkkitehtuurin näkökulma, joka kuvaa organisaation käyttämät tiedot, niiden rakenteet sekä suhteet. Tietoarkkitehtuurin suunnittelun tavoitteena on luoda organisaatiotasoinen yhteinen näkemys keskeisestä tietopääomasta sekä helpottaa tiedon löytämistä, välittämistä ja hallintaa. Suunnittelulla tähdätään tietorakenteiden vakiointiin ja sen mahdollistamaan tietojen uudelleenhyödynnettävyyteen. tietojärjestelmäarkkitehtuuri (application architecture) Kokonaisarkkitehtuurin näkökulma, joka kuvaa organisaation keskeiset tietojärjestelmät, niiden suhteet sekä ominaisuustiedot. Tietojärjestelmäarkkitehtuurin suunnittelu on ko. arkkitehtuurin rakenteellista suunnittelua, elinkaarisuunnittelua sekä kustannus- ja käyttöoptimointia. Tietojärjestelmäarkkitehtuurin suunnittelussa tavoitteena on suunnitella tietojärjestelmäkokonaisuutta siten, että muodostuva tietojärjestelmäkokonaisuus tukee parhaalla mahdollisella tavalla organisaation tavoitteita. toiminta-arkkitehtuuri (business architecture) Kokonaisarkkitehtuurin näkökulma, joka kuvaa organisaation toiminnalliset rakenteet. Näitä ovat mm. sidosryhmät, palvelut ja tuotteet sekä prosessit ja organisaatiot. Myös toiminnan kehittämisen perusrakenteet, kuten visiot ja strategiat, ovat osa toiminta-arkkitehtuuria. Toiminta-arkkitehtuurin suunnittelun tavoitteena on optimoida ja suunnitella asiakkaiden tarpeisiin ja odotuksiin liittyvää palvelutarjontaa sekä palveluiden tuottamiseen tarvittavia toiminnan rakenteita. Tunnetaan myös termillä liiketoiminta-arkkitehtuuri. viitearkkitehtuuri Viitearkkitehtuuri on rajatun arkkitehtuurikokonaisuuden abstrakti toimittaja- ja toteutusneutraali rakenne. Se on esitys arkkitehtuurikokonaisuuden loogisista osista ja niiden välisistä suhteista. Viitearkkitehtuurilla ohjataan arkkitehtuurisuunnittelua halutunlaiseen toteutusrakenteeseen. Viitearkkitehtuuri voi olla organisaation sisäinen, toimialaan liittyvä tai yleinen looginen rakennemalli. 4 Arkkitehtuurikehys Arkkitehtuurikehyksellä tarkoitetaan kokonaisarkkitehtuurin jäsennysmallia, joka tarjoaa näkökulmia ja lähestymistapoja kokonaisuuden hahmottamiseksi ja jäsentämiseksi paremmin käsiteltävään ja 9/34

10 ymmärrettävään muotoon. Kehyksen avulla tunnistetaan kehittämisessä huomioonotettavia näkökulmia ja asioita riittävän kokonaiskuvan saamiseksi sekä tietojen ja kokonaisuuteen vaikuttavien rakenteiden välisten suhteiden selvittämiseksi. Kehyksen tehtävä on nostaa esiin niitä kysymyksiä, joita kokonaisarkkitehtuurin tai valitun ja rajatun kokonaisarkkitehtuurin osa-alueen kehittämisessä on huomioitava ja tarkasteltava. Se rajaa mm. tarkasteltavia arkkitehtuurinäkökulmia, organisatorista kattavuutta ja tarkkuustasoa (hierarkiatasot) sekä suunnittelun abstraktio- eli käsitetasoja. Tässä suosituksessa suositeltu arkkitehtuurikehys on kuvattu kuvassa 4. Se sisältää neljä eri arkkitehtuurinäkökulmaa: toiminta-, tieto-, tietojärjestelmä- ja teknologia-arkkitehtuurinäkökulman. Tämän suosituksen arkkitehtuurikehys pohjautuu TOGAF-mallin arkkitehtuurikehykseen. Kehyksessä on kolme käsitetasoa: käsitteellinen, looginen ja fyysinen taso. Lisäksi kehyksessä kuvattu on periaatteiden taso, jolla määritetyt periaatteet ja tehdyt linjaukset ohjaavat kaikkien käsitetasojen kuvauksia. Kuva 4 Arkkitehtuurikehys: arkkitehtuurinäkökulmat ja käsitetasot Suosituksen arkkitehtuurikehys sekä hierarkiatasot on kuvattu tarkemmin liitteessä 2 Arkkitehtuurikehyksen kuvaus. 5 Kokonaisarkkitehtuurin suunnitteluprosessi Kokonaisarkkitehtuurin suunnitteluprosessi (kuva 5) mahdollistaa järjestelmällisen organisaation toiminnan kehittämisen. Menetelmän avulla voidaan suunnitella yhden tai useamman kokonaisarkkitehtuurinäkökulman sisältöä ja erisuuruisia kokonaisuuksia. Menetelmä on iteratiivinen. Suunnitteluprosessi on jaettu neljään päävaiheeseen: 1. kokonaisarkkitehtuurin suunnittelun valmistelu. 2. kokonaisarkkitehtuurin nykytilan analysointi. 3. kokonaisarkkitehtuurin tavoitetilan suunnittelu. 4. toimeenpanon suunnittelu. Yllämainitut vaiheet ovat kuvattu tarkemmin seuraavissa luvuissa (luvut ). 10/34

11 Kuva 5 Kokonaisarkkitehtuurin suunnitteluprosessi Kokonaisarkkitehtuurin suunnitteluprosessissa tärkeimpänä syötteenä toimii organisaation johdon asettama strategia (strategiaprosessi). Suunnitteluprosessin tuotokset, erityisesti toimeenpanosuunnitelma, toimivat vastaavasti pohjana organisaation TTS-suunnittelulle (kts. kuva 5). Ensimmäisen kokonaisarkkitehtuurin suunnittelukierroksen jälkeen suoritettavilla iteraatiokierroksilla huomioidaan edellisten suunnittelukierrosten suunnitelmat ja kuvaukset sekä toimeenpanon suunnittelun ja toteutuksen ja käyttöönoton aikana tehdyt tarkemman tason kuvaukset ja määritykset (vrt. JHS 171- ja JHS 172 -suositukset). 5.1 Kokonaisarkkitehtuurin suunnittelun valmistelu Kokonaisarkkitehtuurin suunnittelun valmisteluvaiheen (kts. kuva 6) voi käynnistää arkkitehtuurin johtamisprosessista tuleva pyyntö, heräte tai muulta taholta noussut tarve kehittää nykytilaa. 11/34

12 Kuva 6 Kokonaisarkkitehtuurin suunnittelun valmisteluvaihe Vaiheen tarkoituksena on tunnistaa ja hahmottaa organisaation toiminnan tulevaisuuden tavoitetila ja sen rajaukset. varmistaa toiminnan ja ICT-johdon tuki. rajata ja suunnitella arkkitehtuurin suunnitteluprojekti rinnakkaiset kehitysprojektit huomioiden. tunnistaa kehittämiseen vaikuttava olemassa oleva kokonaisarkkitehtuurin sisältö. tunnistaa kehittämisen sidosryhmät ja niiden tavoitteet. analysoida toiminnan kehittämistarpeet ja vaikutukset eri osapuolten näkökulmasta sekä analysoida kehittämisen perustelut toiminnan näkökulmasta. tunnistaa ja määritellä kehittämisen tavoitteet. perustella suunnittelun tavoitetila. Syötteet työn käynnistyessä ovat tarve kehittämiseen. toiminnan kehittämisen tavoitteet ja strategiat. organisaation ja organisaatiota ylemmän tason kokonaisarkkitehtuurin nykytila ja tavoitetilakuvaukset. edellisten arkkitehtuurin suunnittelukierrosten suunnitelmat ja kuvaukset. toteutettujen kehittämiskohteiden tarkemmat kuvaukset. kehittämisen yhteydessä havaitut uudet kehittämistarpeet Määritä ja rajaa kehittämistarpeen mukaiset kokonaisarkkitehtuurin kehittämisalueet Määritä ja rajaa kehittämistarpeen mukaiset kokonaisarkkitehtuurin kehittämisalueet. Arvioi lisäksi aiheuttaako pyydetty kehityskohde muutoksia tehtyjen rajausten ulkopuolella olevissa kohteissa, jotka ovat riippuvaisia tai liittyvät ko. kehittämiskohteeseen. 12/34

13 Rajausvaihtoehtoja ovat mm. tarkkuustaso. organisaatiolaajuus. tietty/tietyt näkökulmat. kehittämisen aikaikkuna. Rajausten ja reunaehtojen kuvaaminen on opastettu tarkemmin liitteessä 5 Arkkitehtuuriperiaatteiden kuvaus, kappaleessa 1.1 Sidosarkkitehtuurit, rajaukset, reunaehdot. Ensimmäisellä kokonaisarkkitehtuurin suunnittelukierroksella arkkitehtuurin laajuus on loogisesti koko arkkitehtuurin laajuus, mutta suunnittelu voidaan vaiheistaa ja jakaa eri kokonaisuuksiin, jolloin rajaukset tehdään kunkin kokonaisuuden kohdalla myös erikseen Tunnista ja kokoa ohjaava tieto Tunnista, mitä kokonaisarkkitehtuuriin vaikuttavaa sisältöä (esim. strategia, arkkitehtuuriperiaatteet, tehdyt toimeenpanosuunnitelmat) on huomioitava ohjaavana tietona ja vaatimuksina arkkitehtuurin ylemmiltä tasoilta sekä saman tason toisista näkökulmista. Huomioi olemassa olevat nykytilan ja tavoitetilan kuvaukset. Varmista, että ko. dokumentaatio on käytettävissä suunnitteluvaiheessa. Arvioi, ovatko nykytilan tiedot riittäviä ja ajantasaisia. Mikäli tiedot ovat puutteellisia, varaa suunnitteluvaiheeseen aikaa niiden täsmentämiseen. Arvioi riskit, mikäli nykytilan tietojen täsmentäminen ei ole ajallisesti tai käytössä olevien resurssien näkökulmasta mahdollista. Arkkitehtuuriperiaatteiden kuvausten laatiminen on kuvattu tarkemmin liitteessä 5 Arkkitehtuuriperiaatteiden kuvaus. Nykytilan ja tavoitetilan kuvauksien tekemiseen liittyvät suositukset löytyvät tarkemmin liitteestä 4 Nykytilan ja tavoitetilan kuvaaminen sekä JHS 171 -suosituksesta Määritä ylätason toimintalähtöinen tavoitetila Kuvaa tarvittaessa ylätason toimintalähtöinen tavoitetila (kts. luku Organisaation toiminnan tavoitteet). Tavoitetilan eli vision kuvaaminen on tarpeen, mikäli kehittämiskohde on iso ja kehittämisen seurauksena tehtävää muutosta ei ole kuvattu kokonaisuutena, tai jos kehittämisen perusteluja ei ole mietitty toiminnan näkökulmasta. Huomioi tässä vaiheessa myös organisaatiohierarkia, eli millä tasolla arkkitehtuurisuunnittelua ollaan tekemässä, sekä kuinka montaa osa-aluetta tai kohderyhmää suunnittelu koskee Organisoi arkkitehtuurin suunnitteleminen Valmistele ja organisoi arkkitehtuurin suunnittelu tässä suosituksessa annetun menetelmän mukaisesti ja tee projektisuunnitelma tai tarkenna olemassa olevaa projektisuunnitelmaa. Analysoi suunnitteluprojektin riskit ja ilmoita aikatauluun tai lopputulokseen liittyvistä riskeistä arkkitehtuurin johtamisprosessille. Tarvittaessa arkkitehtuurin suunnittelutyö voidaan tehdä linjaorganisaation työnä, mutta tällöin tulisi myös toimia projektinomaisesti ja määritellä suunnittelulle aikataulu, sekä selvät tavoitteet ja tarkistuspisteet. Tunnista kehittämiseen liittyvät sidosryhmät ja heidän tarpeensa. Varmista myös sidosryhmien hyväksyntä ja tuki. Hyödynnä sidosryhmien kuvaamisessa ja analysoimisessa tämän suosituksen liitteen 8 Kokonaisarkkitehtuurin kuvauspohjat Sidosryhmät -välilehden taulukkoa. Arkkitehtuurin suunnittelutyön organisoinnissa hyödynnetään organisaation arkkitehtuurin hallintamallissa 13/34

14 määriteltyjä vastuita, jotta suunnittelu- ja kehittämistyö pysyy hallittavana ja noudattaa kokonaisuudelle asetettuja vaatimuksia. Mikäli organisaatiolla ei ole vielä arkkitehtuurin hallintamallia käytössään, määrittele se viimeistään tässä vaiheessa tarvittavien sidosryhmien kanssa Lopputulokset Vaiheen lopputuloksia ovat lista suunnittelussa tarvittavista olemassa olevista kokonaisarkkitehtuurikuvauksista. hyväksytty suunnitelma arkkitehtuurin suunnittelukierroksesta, sen osa-alueista ja mahdollisesta vaiheistuksesta. ylätason toimintalähtöinen tavoitetilan kuvaus (visio). suunnitelma arkkitehtuurisuunnittelun organisoinnista (pohjalla organisaation arkkitehtuurin hallintamalli). 5.2 Kokonaisarkkitehtuurin nykytilan analysointi Kokonaisarkkitehtuurin kuvaamisessa lähdetään liikkeelle organisaation nykytilan toiminnan analysoinnista. Arkkitehtuurimenetelmän nykytilan analysointivaiheessa (kts. kuva 7) selvitetään organisaation toiminnan, käytettävien tietojen, tietojärjestelmien ja teknologioiden nykytila. Nykytilan analysointi ja sen kuvaus toimivat pohjana tavoitetilan suunnittelulle auttaen ymmärtämään toiminnan rakenteita ja riippuvuuksia sekä hahmottamaan ratkaistavia haasteita. Kuva 7 Kokonaisarkkitehtuurin nykytilan analysoinnin vaiheet 14/34

15 5.2.1 Analysoi nykytilan kuvaukset Analysoi organisaation arkkitehtuurin nykytilan kuvaukset. Mikäli kuvauksia ei ole, kuvaa ne tämän suosituksen mukaisesti. Tässä suosituksessa annettuja minimivaatimuksia tulee noudattaa kuvauksien toteuttamisessa. Selvitä, onko tarpeen kuvata enemmän kuin minimivaatimukset edellyttävät. Kohteen tarpeet määrittelevät kuvausten tason ja niiden laajuuden yli minimivaatimusten. Ensimmäisellä suunnittelukierroksella nykytilan kuvaamiseen kannattaa usein käyttää enemmän aikaa ja tehdä kuvauksista perusteellisempia, kuin seuraavilla suunnittelukierroksilla Kuvaa nykytilan arkkitehtuuri Kuvaa nykytila valituilla kuvaustavoilla ja kuvaustasoilla huomioiden valitut arkkitehtuurinäkökulmat sekä kehittämisen tavoitteet ja rajaukset, kuten myös tässä suosituksessa annetut minimivaatimukset kuvauksille. Nykytilan kuvauksesta lisää liitteessä 4 Nykytilan ja tavoitetilan kuvaus. Käytä kuvauksessa luvussa 6 Arkkitehtuurikuvausten tuottaminen annettuja kuvaustapoja, malleja, matriiseja ja listauksia. Hyödynnä myös suosituksessa JHS 171 annettuja nykytilan kuvauksen suosituksia. 5.3 Kokonaisarkkitehtuurin tavoitetilan suunnittelu Kokonaisarkkitehtuurin tavoitetilan suunnitteluvaiheessa (kts. kuva 8) vaiheessa voidaan menetelmän joustavuusperiaatteen mukaisesti suunnitella mitä tahansa toiminnallista kokonaisuutta tai arkkitehtuurin näkökulmaa. Kuva 8 Kokonaisarkkitehtuurin tavoitetilan suunnittelun vaiheet 15/34

16 Jos kehittämiskohteen arkkitehtuurisuunnitteluun tarvitaan useampia näkökulmia, suositeltu suunnittelujärjestys on seuraava toiminnan vaatimusten huomioimiseksi: toiminta-arkkitehtuurinäkökulma. tietoarkkitehtuurinäkökulma. tietojärjestelmäarkkitehtuurinäkökulma. teknologia-arkkitehtuurinäkökulma. Kokonaisarkkitehtuurin suunnittelu etenee seuraavien päätehtävien mukaisesti kaikissa näkökulmissa: kuvaustapojen kokoaminen tehtyjen rajausten perusteella. kohderyhmien analysointi. arkkitehtuuriin vaikuttavien tekijöiden analysointi. tavoitetilan arkkitehtuurin mallinnus. toiminnan tavoitetilan (visio) kehittäminen. puuteanalyysin tekeminen. Päätehtävät on kuvattu tarkemmin luvuissa Kunkin arkkitehtuurinäkökulman suunnittelun erityispiirteitä on käsitelty luvuissa Näissä luvuissa on myös kuvattu tarkemmin minkälaisia kokonaisarkkitehtuurin suunnittelun tuloksia kustakin yllä mainitusta näkökulmasta tuotetaan. Kuvauksien tekemisessä käytetään tässä suosituksessa ja sen liitteissä annettuja kuvaustapoja Kokoa kehittämisalueen kuvaustavat Kokoa ongelmalähtöisesti tavoitetilan kuvauksessa käytettävät kuvaustavat. Käsittele tavoitetilan suunnitteluun osallistuvien tahojen kanssa suunnittelussa käytettävät kuvaustavat. Minimivaatimukset ovat samat kuin nykytilan kuvauksissa. Niitä voidaan laajentaa tarvittaessa ja valitun kehittämisen osa-alueen niin vaatiessa (esim. hyvin laaja kokonaisuus tai uusi toiminnallinen ratkaisu). Arkkitehtuurikehyksessä (kts. luku 4 on kuvattu suositukset eri käsitetasoilla ja -näkökulmissa tehtävistä kuvauksista. Suositellut kuvaustavat eri arkkitehtuurinäkökulmista löytyvät luvusta 6 Arkkitehtuurikuvausten tuottaminen. Hyödynnä olemassa olevia kuvauksia, mikäli se on mahdollista Analysoi arkkitehtuurin ja kuvausten kohderyhmät Analysoi, miten arkkitehtuurin suunnittelun eri sidosryhmät osallistuvat kokonaisarkkitehtuurin kehittämiseen tai hyödyntävät suunnittelun tuloksia. Tuotettavien kuvausten sisällön tulee olla sellainen, että tarpeelliset sidosryhmät tulevat huomioitua. Kunkin sidosryhmän tulee lisäksi ymmärtää niille tarkoitettujen kuvausten sisällöt (esim. ylimmälle johdolle kuvaukset tehdään toiminnan käsittein ja tekniselle asiantuntijalle teknisin käsittein). Huomioi analyysin tulokset kokonaisarkkitehtuurin kehittämisessä ja tulosten dokumentoinnissa. Sidosryhmien kuvauksessa käytetään luvussa Asiakkaiden ja sidosryhmien kuvaaminen esitettyjä menetelmiä Analysoi ja huomioi arkkitehtuuriin vaikuttavat tekijät. Analysoi aiemmissa vaiheissa (kts. luvut 5.1 Kokonaisarkkitehtuurin suunnittelun valmistelu ja 5.2 Kokonaisarkkitehtuurin nykytilan kuvaus) koottu materiaali ja kirjaa arkkitehtuurin kehittämisprojektin suunnitteluun ja rajaamiseen vaikuttavat asiat. Arkkitehtuurin kehittämisen rajaukseen vaikuttavia asioita ovat mm. 16/34

17 ylemmän tason arkkitehtuurivaatimukset ja periaatteet (kts. liite 2 Arkkitehtuurikehyksen kuvaus, luku 1.3 Kokonaisarkkitehtuurin hierarkiatasot). kuvausten kohderyhmä. sidosryhmien tarpeet ja määrä. budjetti. käytettävissä oleva aika. henkilöresurssit. muut aiemmissa vaiheissa määritellyt rajaukset ja erityistapaukset Kuvaa tavoitetilan arkkitehtuuri Käynnistä arkkitehtuurin tavoitetilan kuvaaminen suositeltuja ja valittuja kuvaustapoja käyttäen (kts. luku 5.3.1). Hyödynnä aikaisempien suunnitteluvaiheiden tuotoksia. Etene luvussa 6 Arkkitehtuurikuvausten tuottaminen kuvatun ohjeistuksen mukaisesti. Huomioi arkkitehtuurin suunnitteluun vaikuttavat tekijät (kts. luku 5.3.3). Mallinnus voi olla nykytilan kuvaamista ja sen kautta kehittämiskohteiden tunnistamista tai se voi olla kehitettävän kohteen tavoitetilan suunnittelua. Huomioi erot lähestymistavoissa näissä näkökulmissa. Käytä JHS-suositusten kuvauspohjia täydentämään tavoitetilan kuvausta Tee puuteanalyysi Arvioi, onko jotain asioita tai näkökulmia jäänyt huomioimatta suunnittelussa käyttäen hyödyksi puuteanalyysi-matriisia, jonka löydät tämän suosituksen liitteestä 4 Puuteanalyysi-matriisi Kehitä toiminnan tavoitetilaa tarvittaessa Arvioi, vaikuttaako kokonaisarkkitehtuurin kehittämisen tulos toiminnan tavoitetilaan (olemassa oleva organisaation strategia) ja tee tarvittaessa muutosehdotus. Lähetä muutosehdotukset katselmoitavaksi tarvittaville tahoille (mm. johtamisprosessi). Päivitä tavoitetila katselmoinnin jälkeen Lopputulokset Kokonaisarkkitehtuurin tavoitetilan suunnittelun lopputulokset ovat kokonaisarkkitehtuuriin vaikuttavien tekijöiden listaus ja analyysi. sidosryhmien kartoitus ja analyysi. puuteanalyysi. päivitetyt ja tarkennetut muutosehdotukset (= tarpeet). tavoitetilan arkkitehtuurin kuvaus, jossa on huomioitu eri näkökulmat ja tarkastelutasot. Tavoitetilan arkkitehtuuri sisältää ratkaisut lähtökohtina olleisiin kehittämistarpeisiin. 5.4 Toimeenpanon suunnittelu Toimeenpanon suunnitteluvaiheessa (kts. kuva 9) määritellään kokonaisarkkitehtuurin tavoitetilaan pääsemiseksi vaadittavat kehittämisalueet ja laaditaan ylätason toimeenpanosuunnitelma TTS-suunnittelua varten. Tässä vaiheessa määritellään toimeenpanosuunnitelma organisaation kokonaiskehittämistä ajatellen. 17/34

18 TTS-suunnittelun kautta sovitut kehittämisalueet tarkennetaan yksityiskohtaisemmiksi kehittämishankkeiksi ja -projekteiksi, sekä arvioidaan niiden hyödyt ja riskit. Kehittämiskohteiden tarkennus toteutetaan JHS 171 ICT-palvelujen kehittäminen: Kehittämiskohteiden tunnistaminen -suosituksen ( kuvaamalla tavalla. Yksittäisten kehittämisalueiden tai -kokonaisuuksien toimeenpanosuunnitelma laaditaan yllä mainitun suosituksen mukaisesti. Kuva 9 Toimeenpanon suunnittelun vaiheet Toimeenpanon suunnittelu koostuu seuraavista vaiheista: Kehittämistarpeiden tunnistaminen Määrittele kehittämisalueet esim. puuteanalyysin tulosten perusteella (kts Tee puuteanalyysi). Tunnista kehittämistyötä vaativat osa-alueet. Suunnittele alustavasti tarvittavien ylätason kehityshankkeiden tavoitteet ja sisältö. Kustannus- ja hyötyanalyysien tekeminen Tee alustava kustannus- ja hyötyanalyysit ylätason kehittämisalueista kokonaisuus huomioiden. Riskien analysointi Analysoi riskit ja laadi ylätason riskienhallintasuunnitelma. Kehitystarpeiden priorisointi Arvioi ylätason kehittämistarpeet mm. niiden merkittävyyden, vaikuttavuuden ja kustannussäästöjen kannalta sekä priorisoi kehitystarpeet ja niihin liittyvät kehittämishankkeet. 18/34

19 Kehittämispolun suunnittelu Suunnittele valittujen ylätason kehittämisalueiden pitkän tähtäimen aikataulutus huomioiden organisaation kehittämistoiminnan vuosikello. Toimeenpanosuunnitelman tekeminen Kokoa kokonaisarkkitehtuurin suunnittelussa tuotetut kuvaukset, analyysit ja laskelmat ja tee niiden perusteella alustava kokonaisuutta koskeva toimeenpanosuunnitelma. Katselmointi Katselmoi kuvaukset, analyysit ja muut arkkitehtuurikuvausten tuotokset tarpeeksi laajalti kehittämisessä mukana olleissa sidosryhmissä. Toimeenpanosuunnitelman esittely sidosryhmille Esittele katselmoinnin tulosten perusteella päivitetty toimeenpanosuunnitelma sidosryhmille. Toimeenpanosuunnitelman linkittäminen TTS-prosessiin Toimita toimeenpanosuunnitelma TTS-suunnitteluprosessin vastuutahoille. Noudata toimeenpanon suunnittelussa organisaation omia investoinneille, projektien- sekä hankkeiden hallinnalle asetettuja vaatimuksia ja menetelmiä, mikäli niitä on käytettävissä. Huomioi myös arkkitehtuurin johtamisprosessi. 6 Arkkitehtuurikuvausten tuottaminen Tässä luvussa annetaan suositukset arkkitehtuurikuvausten tuottamiseksi ja kuvaamiseksi eri näkökulmista sekä esitellään menetelmät ja mallit kuvauksien dokumentoimiseksi. Tuotettujen arkkitehtuurikuvausten tuottamat hyödyt on kuvattu kootusti liitteessä 3 Arkkitehtuurisuunnittelun hyödyt. 19/34

20 Kuva 10 Arkkitehtuurimenetelmän tarjoamat kuvausmallit ja -pohjat Arkkitehtuurin visualisointiin käytetään UML- ( tai ArchiMate-notaatiota ( ja Tässä luvussa suositeltujen kuvaustapojen lisäksi arkkitehtuurin suunnittelussa ja eri iteraatiokierroksilla suositellaan käytettäväksi muita JHS-suosituksia. Mm. prosessien kuvaaminen on suositeltavaa tehdä JHS 152 Prosessien kuvaus -suosituksen mukaisesti. Kokonaisarkkitehtuurin ensimmäisen kuvauskierroksen jälkeen, siirryttäessä tarkempiin kehittämiskohteiden tunnistamis- ja esiselvitysvaiheisiin, käytetään JHS-suositusten JHS kuvausmalleja ja -pohjia tämän suosituksen pohjien lisäksi. 6.1 Arkkitehtuuriperiaatteet ja linjaukset Kokonaisarkkitehtuurin suunnittelussa tehtävien arkkitehtuurikuvausten pohjalla ovat erilaiset sisäiset tai ulkoiset periaatteet ja linjaukset, esimerkiksi arkkitehtuurin tai tietoturvallisuuden suhteen. Organisaation arkkitehtuuriperiaatteiden määrittelyn ja valinnan pohjana suositellaan käytettäväksi VM:ssä määriteltyjä yleisiä arkkitehtuuriperiaatteita ( Suositukset periaatteiden ja linjausten kuvaamiseksi sekä kuvauksien tuotokset on kuvattu tarkemmin liitteessä 5 Arkkitehtuuriperiaatteiden kuvaus. Ko. liitteessä ovat myös suositusten sidosarkkitehtuurien kuvaamiseen, rajausten ja reunaehtojen tekemiseen, sekä tietoturva- ja integraatioperiaatteiden kuvauksesta. 20/34

21 6.2 Nykytilan ja tavoitetilan kuvaus Nykytilan kuvaaminen luo kokonaisarkkitehtuurin suunnittelussa käsityksen olemassa olevista toimintamalleista, käytettävistä järjestelmistä sekä käytetystä tiedosta. Nykytilasta tehdään vähintään seuraavat kuvaukset: arkkitehtuuriperiaatteet. - Noudatetaan vähintään ylemmän tason periaatteita, jos ne on määritelty. Mikäli periaatteita ei ole määritelty, ne tulee määritellä tavoitetilan kuvaamisen yhteydessä. asiakkaat ja sidosryhmät. palveluiden kuvaukset. - Palveluiden kuvauksessa käytetään Palvelusalkku-pohjaa. prosessien kuvaukset. - Prosessit kuvataan vähintään loogisella tasolla. informaatiosalkku. tietojärjestelmäsalkku. - Havainnollisuuden vuoksi on suositeltavaa kuvata myös tietojärjestelmäkartta. prosessien, tietojen ja tietojärjestelmien suhteiden kuvaus - Kuvataan vähintään Prosessit-tiedot-, Tiedot-tietojärjestelmät- sekä Prosessittietojärjestelmät -matriisit. integraatioratkaisut. - Integraatioratkaisuista kuvataan vähintään Liittymät ja rajapinnat -pohjan mukaiset tiedot. Nämä ns. minimivaatimukset kuvataan kaikissa organisaatioissa tämän suosituksen mukaisesti. Tavoitetilan kuvaaminen luo käsityksen halutuista toimintamalleista, tietojärjestelmistä sekä toiminnassa tarvittavasta tiedosta. Tavoitetilan kuvauksissa noudatetaan samoja minimivaatimuksia kuin nykytilan kuvauksissa. Nykytilan ja tavoitetilan kuvaamisessa suositellut vaiheet on kuvattu tarkemmin liitteessä 4 Nykytilan ja tavoitetilan kuvaus. 6.3 Standardit Standardit ovat toiminnan ja kehittämisen taustalla olevia yksikäsitteisiä määrittelyn reunaehtoja. Standardointi on teknistä kehitystä ohjaava keskeinen tekijä. Standardeista kuvataan sekä toimintaan, tiedonhallintaan että teknologiaan liittyvät standardit. Suositeltavia standardeja ovat julkisessa hallinnossa yleisesti käytössä olevat standardit. Myös kansainväliset standardit on huomioitava standardeja kerättäessä. Kansainvälisiä standardeja löytyy mm. seuraavilta sivustoilta. CEN (The European Committee for Standardisation) ISO (International Organization for Standardization) The Open Group W3C (World Wide Web Consortium) 21/34

22 Käytettävät standardit listataan organisaation standardisalkkuun. Malli standardisalkusta löytyy tämän suosituksen liitteen 8 Standardisalkku -välilehdeltä. 6.4 Toiminta-arkkitehtuurin suunnittelu Toiminta-arkkitehtuurin suunnittelun tarkoituksena on suunnitella ja kehittää organisaation strategisia tavoitteita toteuttavaa ydintoimintaa, sitä tukevia tukitoimintoja, toiminnan vaatimia resursseja sekä toiminnan lopputuloksena olevia tuotoksia tai palvelutarjontaa. Toiminta-arkkitehtuurin lähtökohtina ovat organisaation toimintaa ohjaava lainsäädäntö, kuvaus organisaation toiminnan nykytilasta ja siitä johdettu tavoitetila, strategiakuvaukset, mahdolliset skenaariokuvaukset sekä organisaation rakenne ja vastuualueet, toiminnalliset tarpeet ja trendit. Toimintaarkkitehtuuri on tapa jäsentää ja hahmottaa toimintaa sekä toiminnan kehittämistä organisaation tavoitteiden näkökulmasta. Kuvauksissa lähdetään liikkeelle vaatimuksista ja hahmotellaan niitä vasten palvelut ja prosessit ylätasolla. Ylätason kuvauksen jälkeen kuvataan toimintamallit sekä tarvittavan tasoiset tarkemmat prosessikuvaukset. Toiminnan selkeyttämiseksi kuvauksia voidaan tehdä huomioimalla eri arkkitehtuurinäkökulmat. Etenemisjärjestykseen vaikuttavat organisaatiossa jo olemassa olevat kuvaukset sekä kuvausten taso. Mikäli kuvaukset ovat olemassa ja ne sisältävät tarvittavat tiedot päätöksen teon ja johtamisen tueksi, ei kuvauksia tarvitse tehdä uudelleen, vaan niitä muutetaan tarvittaessa tai seuraavilla suunnittelukierroksilla Organisaation toiminnan tavoitteet Voimassaolevat organisaation strategiat taltioidaan arkkitehtuuridokumentaation liitteiksi. Sekä substanssistrategiat (esim. organisaation tai organisaatioyksiköiden toimintastrategia, asiakas- ja palvelustrategia), organisaation sidosryhmien strategiat että tietohallintostrategiat tulee ottaa arkkitehtuurityössä huomioon. Strategioista kuvataan liitteen 8 Strategiat -välilehden mukaiset tiedot. Organisaation visioista ja strategiasta johdetaan tavoitteet ja priorisoitavat vaatimukset. Vaatimuksien kokoamisessa käytetään liitteen 8 Kehittämisvaatimukset ja tavoitteet -välilehden kuvauspohjaa. Yksi toiminnan tavoitteiden suositeltu kuvaustapa on ns. strategiakartta Asiakkaiden ja muiden sidosryhmien kuvaaminen Sidosryhmien kuvaamisvaiheessa selvitetään ja kuvataan minkälaisessa toimijaympäristössä organisaatio tai sen viite- tai kohdearkkitehtuurissa käsiteltävä osa toimii. Toimijoilla tarkoitetaan tässä sekä organisaation sisäisiä ja ulkoisia tilaajia ja tuottajia, organisaation palveluiden asiakkaita sekä muita organisaation toimintaan vaikuttavia tai siinä huomioitavia sidosryhmiä. Asiakkaiden ja sidosryhmien kuvaamisessa huomioidaan mm. seuraavat asiat: analysoidaan, ketkä ovat sidosryhmiä (asiakkaat mukaan lukien). kuvataan sidosryhmät sekä kirjataan sidosryhmien tärkeys organisaation kannalta. kirjataan, mitä sidosryhmät odottavat organisaatiolta eli sidosryhmien vaatimukset. kuvataan, mitä organisaatio odottaa sidosryhmiltä. asetetaan vaatimuksille mittarit, jotka kuvaavat, miten vaatimuksen toteutumista voidaan mitata. kirjataan organisaation asettama tavoitearvo (tavoitetilanne) mittareille. Sidosryhmät kuvataan liitteen 8 Sidosryhmät-välilehden mukaisesti. Vaatimuksien kuvauksessa käytetään liitteen 8 Sidosryhmien vaatimukset ja tavoitteet -välilehden 22/34

23 kuvauspohjaa Palveluiden kuvaus Organisaation kokonaisarkkitehtuurin kuvauksissa kuvataan kolmenlaisia palveluita: Palvelut Toiminnan ylätason palvelut. Organisaation arkkitehtuuria kuvattaessa nämä ovat koko organisaation keskeisimmät palvelut. Tietojärjestelmäpalvelut Varsinaista toimintaa tukevat järjestelmillä toteutettavat palvelut, esimerkiksi käyttäjänhallintapalvelut ja integraatiopalvelut. Teknologiapalvelut Laiteteknologian ja muun tekniikan tarvitsemat palvelut, kuten esimerkiksi laitetila- ja laitteiden kapasiteettipalvelut, tietoliikenne-, tele- ja nimipalvelut. Toiminta-arkkitehtuurinäkökulmassa kuvataan siis keskeiset substanssitoiminnan pääpalvelut. Vastaavasti tietojärjestelmäpalvelut kuvataan tietojärjestelmänäkökulmassa ja teknologiapalvelut teknologianäkökulmassa. Palvelut ryhmitellään ja kustakin palvelusta kuvataan liitteen 8 Palvelusalkkuvälilehden mukaiset tiedot. Palveluiden muodostamia kokonaisuuksia visualisoidaan myös palvelukartan avulla. Mallina palvelukartasta voi käyttää kappaleessa Tietojärjestelmäkartta kuvattua karttaa. Yksittäisten palveluiden kuvaamisessa käytetään JHS 171 -suosituksen Palvelukuvaus-liitettä ( Prosessien kuvaaminen Prosessien kuvaamisessa suositellaan käytettäväksi JHS 152 Prosessien kuvaaminen -suositusta ( Prosessit kuvataan huomioiden organisaation hierarkiatasojen lisäksi myös käsitetasot. Esimerkiksi kartta organisaation pääprosesseista (vrt. kuva 11) kuvataan siis käsitteellisellä tasolla organisaation ylimmän tason (kokonaisuuden taso) toiminnasta. Loogisella tasolla kuvataan organisaation toimintamalli- ja prosessinkulkukaaviot ja vasta fyysisellä tasolla työnkulkukaaviot, eli tarkemmat ja yksityiskohtaisemmat kuvaukset prosessien kulusta eri vaihtoehtoineen. Prosessit kuvataan riittävällä tarkkuustasolla. Prosessien kuvaaminen tarkentuu ja yksityiskohtaisuus lisääntyy mitä lähemmäksi toteuttamis-(toimeenpano) rajapintaa mennään (kts. liite 2 Arkkitehtuurikehyksen kuvaus, luku 1.3 Kokonaisarkkitehtuurin hierarkiatasot). Arkkitehtuurin suunnittelussa harvoin on tarvetta mennä tasolle neljä eli työnkulkukaavioihin asti. 23/34

24 Kuva 11 Prosessien kuvaustasot Organisaatiorakenteiden kuvaus Organisaation rakenteista kuvataan organisaation rakenne eli eri osastot, yksiköt tai toiminnalliset kokonaisuudet sekä niiden vastuut (kts. liitteen 9 Organisaatiot ja sidosryhmät -välilehden taulukko). Organisaatio kuvataan hierarkkisesti eli eri tasoilla. Suositeltuja organisaation kuvaustapoja ovat myös organisaatiokaaviot ja -matriisit. Valmiita malleja löytyy useista yleisesti käytetyistä toimisto-ohjelmistoista. 6.5 Tietoarkkitehtuurin suunnittelu Tietoarkkitehtuurissa tarkastellaan organisaation tietotarpeita, tietopääomaa, tietojen välisiä suhteita sekä informaatioarvoketjuja. Lisäksi tarkastellaan tietojen rakenteita sekä tiedon organisointia ja hallintaa. Tarkoituksena on luoda organisaatiotasoinen yhteinen näkemys organisaation keskeisestä tietopääomasta ja helpottaa tiedon ja siitä jalostetun informaation käyttöä, hyödyntämistä ja löytämistä. Tietoarkkitehtuurin kuvauksen tarkoituksena on helpottaa tiedon välittämistä eri toimintojen ja prosessien kesken sekä tiedon hallintaa. Organisaatiossa tarvittavan tiedon alustava määrittely on osa toimintaarkkitehtuuria ja sisältyy toiminnalle asetettuihin vaatimuksiin. Toiminnan vaatimuksien pohjalta määritellään organisaation ydintiedot päätietoryhmittäin. Myös organisaatiossa olemassa olevat tietojärjestelmät käsittelevät ja synnyttävät tietoa. Tällöin voidaan tunnistaa päätietoryhmiä myös järjestelmien näkökulmasta lähtien. Tietoarkkitehtuurin keskeisimpiä tavoitteita on löytää, määrittää, jäsentää ja kuvata organisaation kannalta keskeisimmät tietotarpeet, jotka liittyvät kriittisimpiin ydin- ja palveluprosesseihin. Tietoarkkitehtuurissa tulee huomioida ja hallita tiedon muuttuminen ajan, ympäristön tarpeiden, käyttäjän tulkinnan ja mieltymyksen sekä trendien suhteen. Lisäksi tulee huomioida tietoturva- ja tietosuojavaatimukset (kts. 24/34

25 VAHTI-ohjeet, Tiedon määrittelyssä ja kartoituksessa tulee huomioida tiedonlähteiden riittävän laaja-alainen seuranta ja keskeisten tiedonlähteiden valinta. Tiedon hyödyntämisessä tulee lisäksi arvioida tiedon harmonisointiaste. Se kertoo, onko tieto määritelty niin, että se on yleisesti käytetyn standardin mukaista ja eri osapuolten välillä siirreltävässä muodossa (esim. XML). Tiedon jakelun yhteydessä on mietittävä tiedon merkityksen viestintä ja olemassa olevien ontologioiden käyttö. Toiminnan tarvitsemaa tietoa kartoitettaessa tulee pitää mielessä, millä päätöksentekotasolla ja mistä näkökulmasta tietotarvetta määritellään ja mihin käyttötarkoitukseen tietoa kerätään. Nämä vaikuttavat osaltaan tietojen hyödyntämiseksi tehtävien ratkaisujen vaatimuksiin Käsitemalli Käsitemallin kuvauksen tarkoituksena on selvittää organisaation ja ko. toiminnon keskeiset käsitteet. Käsitteet on syytä ryhmitellä kuvattavalla arkkitehtuurialueella luonnostaan olevien ryhmien mukaan, esimerkiksi yhteisiin käsitteisiin ja toimialueiden käsitteisiin. Käsitemallissa tulee myös viitata eri toimialueiden kansallisiin käsitemalleihin, jos näitä on olemassa. Käsitemallin kuvauksessa käytetään liitteen 8 Käsitemalli-välilehden kuvauspohjaa. Listamuotoisen käsitteiden luetteloinnin lisäksi on tärkeää visualisoida käsitemallia kuvaamalla käsitteet ja niiden väliset riippuvuudet. Tämä visualisointi voidaan tehdä hyvinkin yksinkertaisesti sijoittamalla käsitteet laatikoihin ja kuvaamalla niiden väliset riippuvuudet viivoilla ilman suuntaa. Tarkempaan visualisointiin suositellaan käytettäväksi UML-luokkakaaviota (kts. kuva 12) tai ER-kaaviota (Entity Relationship). Kuva 12 Käsitemalli Käsitemallin lisäksi suositellaan kuvattavaksi myös tietomalli, jonka kuvausvälineenä voidaan käyttää esimerkiksi kuvan 12 kaltaista luokkakaaviota. Kun käsitemalli on karkeampi loogisen tason kuvaus, tietomalli on vastaavasti tarkempi ja lähempänä fyysisen tietokannan suunnittelua. 25/34

26 6.5.2 Sanasto Sanastot kuvaavat fyysisen tason jäsennettyä tietoarkkitehtuuria, eli mitä termejä ja nimityksiä käytetään eri tilanteissa ja eri asioista. Usein sanastot sekoitetaan käsitteistöihin. Sanastot ovat lähempänä tarkkoja termejä tai koodistoja kuin hyvin ylätason merkitystä eritteleviä jäsennyksiä. Sanastoja määriteltäessä on suositeltavaa toimia JHS 175 Julkisen hallinnon sanastotyö -suosituksessa kuvatun prosessin mukaisesti sekä huomioida julkisen hallinnon eri osa-alueilla tehdyt tai tekeillä olevat sanastot tai sanastotyöryhmät. Sanastot kuvataan liitteen 8 Sanastot-välilehden mukaisesti Päätietoryhmien määrittely Päätietoryhmien määrittelyssä kuvataan prosessien ja palveluiden käyttämät tiedot, kuten prosessien syötteet ja niiden tuottamat tiedot alustavasti päätietoryhmittäin. Lisäksi kuvataan tietojärjestelmät, jotka osallistuvat tiedon tuottamiseen, hallintaan ja säilyttämiseen. Päätietoryhmien määrittelyssä käytetään liitteen 8 Informaatiosalkku -välilehden kuvauspohjaa. Tietoryhmien, prosessien ja tietojärjestelmien suhteiden kuvaamisessa hyödynnetään liitteen 9 Kokonaisarkkitehtuurin kuvausmatriisit Prosessit-tiedot- sekä Tietojärjestelmät-tiedot -välilehtiä. Kyseisistä matriiseista nähdään, mitkä prosessit omistavat tai käyttävät tietoa, kuten myös mitkä järjestelmät osallistuvat tiedon tuottamiseen ja hallintaan. Matriisin avulla voidaan myös tunnistaa keskeisimpiä tietoryhmiä Tietovirtojen kuvaaminen Tietovirtakuvauksen (kts. kuva 13) tarkoituksena on luoda laajempi näkymä toimintaan liittyvien prosessien väliseen tiedonvaihtoon, tunnistaa toiminnassa hyödynnettävät tietovarannot sekä toiminnan tietovirtoihin vaikuttavat ulkopuoliset toimijat (esim. asiakkaat) ja lopputuotteet. Tietovirtojen kuvaamisen yhteydessä on huomioitava toiminta-arkkitehtuurin kuvaukset, erityisesti prosessien kuvaukset. Tietovirtoja voidaan kuvata monesta eri näkökulmasta, kuten esimerkiksi organisaation, tietojärjestelmien tai prosessien näkökulmasta. Suositeltavaa on kuvata tietovirrat vähintään prosessien näkökulmasta Tietovirtakuvauksessa kuvataan tiedon kulku tiedon syntymislähteestä (esim. kansalaisen tekemä hakemus) loppusijoituspaikkaan (esim. organisaation sähköinen arkistointijärjestelmä) eri rakenneosien (esim. järjestelmien, sovellusten tai prosessinosien) kautta. 26/34

27 Kuva 13 Esimerkki asiakaspalvelun tietovirtakuvauksesta Tietovarantojen kuvaaminen Tietovarantojen ja tietosisältöjen kuvaamisen avulla on mahdollista hahmottaa organisaation tiedonhallinta ja tietojen ylläpito selkeämmin ja tarkemmin. Prosesseissa käytettävien tietovarantojen (organisaation sisäiset ja ulkoiset tietovarannot) kuvaaminen auttaa organisaatiota suunnittelemaan tiedonhallinnan ja huollon mahdollisimman hyvin toimintaa tukevaksi ja järkeistämään tiedon tuottamisen prosesseja. Tietovarantojen kuvaaminen tehdään tarvittavalla tarkkuustasolla (kts. esimerkiksi kuva 14). Tietovarantojen kuvaamisessa käytetään liitteen 8 Loogiset tietovarannot -välilehdellä olevaa kuvauspohjaa. Kuva 14 Visuaalinen esitys tietovarannoista ja päätietoryhmistä 27/34

28 6.5.6 Tietoarkkitehtuurin kuvausmatriisit Tietoarkkitehtuurien kuvausmatriisien avulla mahdollistetaan tietojen ja niitä käyttävien tai niitä tuottavien sidosryhmien, prosessien sekä tietojärjestelmien välisten yhteyksien kuvaaminen. Tämän suosituksen liitteessä 9 Kokonaisarkkitehtuurin kuvausmatriisit on yhteyksien kuvaamista selventävä mallipohja, jota suositellaan käytettäväksi. Mallipohjassa on kuvattu seuraavat yhteydet: sidosryhmät-tiedot -matriisi. prosessit-tiedot -matriisi. tietojärjestelmät-tiedot -matriisi. 6.6 Tietojärjestelmäarkkitehtuurin suunnittelu Tietojärjestelmien tarkoituksena on tukea organisaation toimintaa, toimia työvälineenä operatiivisissa prosesseissa ja hallita organisaation tietoja. Tietojärjestelmät muodostavat merkittävän osuuden organisaatioiden ICT-kustannusrakenteessa ja siksi on järkevää tavoitella myös tietojärjestelmäratkaisujen osalta mahdollisimman suuria hyötyjä kustannusten- ja riskienhallinta huomioiden. Tähän auttaa kokonaisarkkitehtuurin suunnittelun käyttäminen tietojärjestelmien suunnittelua ja kehittämistä ohjaavana tekijänä Looginen järjestelmäjäsennys Looginen järjestelmäjäsennys kuvaa tietojärjestelmien, tietovarantojen ja teknologiakomponenttien sekä parhaissa tapauksissa myös keskeisten toiminnan palvelujen tai prosessien merkittävimmät keskinäiset suhteet. Looginen järjestelmäjäsennys kuvataan aina visuaalisesti eri elementtien välisenä riippuvuutena. Loogisessa järjestelmäjäsennyksessä kuvataan seuraavien komponenttien ja osien looginen jäsennys ja keskinäiset riippuvuudet: toiminnan pääpalvelut ja prosessit. tietovarannot. keskeisimmät järjestelmäpalvelut. integraatioratkaisut. tärkeimmät teknologiapalvelut. keskeisimmät toimijat. käyttäjärajapinta. Kuvassa 15 on esimerkkikuva ylätason loogisesta järjestelmä- ja ratkaisujäsennyksestä. 28/34

29 Kuva 15 Ylätason looginen järjestelmä- ja ratkaisujäsennys Tietojärjestelmäpalvelut Tietojärjestelmäpalveluita ovat keskeisimmät järjestelmäympäristön loogiset kokonaisuudet. Tyypillisiä tietojärjestelmäpalveluita ovat: substanssitoimintaa suoraan tukevat järjestelmäpalvelut. - Esimerkiksi oppilashuollon järjestelmäpalvelut, taloushallinnon järjestelmäpalvelut, HRjärjestelmäpalvelut (Human Resource). hallinnointipalvelut. - Esimerkiksi identiteetinhallinta, käyttövaltuushallinta, toimijatietojen hallinnointi, hakemistopalvelut. selailu- ja raportointipalvelut. - Esimerkiksi hakupalvelut, BI-raportointiratkaisut (Business Intelligence), julkaisupalvelut. palveluita tukevat järjestelmätoiminnot. - Esimerkiksi asiointitilipalvelu, pääsynhallinta, aikaleimapalvelut, sähköinen allekirjoittaminen, prosessimoottori, keskitetty loki. integraatiopalvelut. 29/34

30 Tietojärjestelmäpalvelut jäsentyvät tietyiltä osin substanssipalveluiden mukaisesti, mutta ne sisältävät usein myös varsinaisia palveluita tukevia ja substanssialueesta riippumattomia palveluita. Tietojärjestelmäpalveluiden kuvauksessa käytetään liitteen 8 Tietojärjestelmäpalvelut-välilehden kuvauspohjaa Tietojärjestelmäsalkku Organisaation järjestelmät kuvataan tietojärjestelmäsalkkuun järjestelmien nykytilan mukaan, mutta salkkuun voidaan dokumentoida myös esimerkiksi tiedossa olevat kehittämissuunnitelmat järjestelmäkohtaisesti. Kuvattaessa tavoitetilan tietojärjestelmäsalkkua, kuvataan tietojärjestelmäsalkun kuvauspohjan (liitteen 9 Tietojärjestelmäsalkku-välilehti) uusimistarve-kohtaan nykytilan järjestelmä. Tietojärjestelmäsalkku sisältää järjestelmistä mm. seuraavat tiedot: järjestelmien tuomat hyödyt, niiden kustannukset ja riskit sekä tietojärjestelmien käyttäjät, käyttäjämäärät ja käyttötiheydet sekä elinkaaren. Lisäksi järjestelmät luokitellaan niiden strategisen merkityksen mukaan. Mikäli järjestelmiin liittyvää tietoa on paljon, on niiden hyödyntämiseksi syytä luoda useita erillisiä näkymiä (esim. vastuunäkymä, kustannusnäkymä, elinkaarinäkymä). Järjestelmäsalkun kuvaamisessa käytetään liitteen 9 Tietojärjestelmäsalkku-välilehden kuvauspohjaa Tietojärjestelmäkartta Tietojärjestelmäkarttaan kuvataan organisaation käytössä olevat tai muille tarjoamat järjestelmät visuaalisena karttana. Järjestelmät tulee kuvata vähintään organisaation näkökulmasta, myös toiminnallinen jaottelu (esim. taloushallinto, sähköinen asiointi) on suositeltavaa (kts. kuva 16 Tietojärjestelmäkartta). Tietojärjestelmäkartta voidaan kuvata myös esimerkiksi poikkihallinnollisen prosessin tai muun vastaavan kokonaisuuden näkökulmasta. 30/34

31 Kuva 16 Tietojärjestelmäkartta Kuvassa 16 on tietojärjestelmäkartta kuvattuna organisaation ja järjestelmien käyttötarkoituksen näkökulmasta. Tietojärjestelmäkartan pohjana voidaan esittää organisaatioiden asemesta myös esim. prosessikartta, jolloin kartan tarkoitus on kertoa, mitkä järjestelmät tukevat mitäkin prosessia. Järjestelmäkarttoja voidaan kuvata myös muista näkökulmista tietojärjestelmäsalkkuun kirjattujen tietojen perusteella Tietojärjestelmäarkkitehtuurin kuvausmatriisit Tietojärjestelmäarkkitehtuurin kuvausmatriisien avulla mahdollistetaan tietojärjestelmien yhdistäminen niitä käyttäviin sidosryhmiin, prosesseihin sekä myös tietojärjestelmissä käsiteltäviin tietoihin. Tämän suosituksen liitteessä 9 Kokonaisarkkitehtuurin kuvausmatriisit on suositeltu pohja eri tekijöitä yhdistävistä matriiseista. Erityisesti tietojärjestelmäarkkitehtuurin määrittelyssä käytettäviä matriisipohjia ovat: prosessit-tietojärjestelmät -matriisi. tietojärjestelmät-tiedot -matriisi. 6.7 Teknologia-arkkitehtuurin suunnittelu Teknologia-arkkitehtuuri vastaa kysymyksiin miten ja millä. Teknologia-arkkitehtuuri on kehittämisen näkökulmasta mahdollistava tekijä. Teknologia-arkkitehtuurin keskeinen tavoite on linjata ja rajata käytettävät tekniset vaihtoehdot, standardit ja rakenteet siten, että kokonaisuus tukee parhaalla mahdollisella tavalla organisaation tavoitteita. Linjaukset ovat yhteiseksi sovittuja teknisiä ratkaisuja, jotka on kuvattu teknologiasalkussa (kts Teknologiasalkku). Salkun sisältö koostuu erilaisista teknisistä ratkaisuista. Tällaisia voivat olla muun muassa integraatioarkkitehtuuri, tunnistaminen tai hakukoneratkaisu. 31/34