Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko

1. Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko v. 2.030.9.2013

2. Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko • Esitietovaatimukset: • Kokonaisarkkitehtuurin yleisesittely –moduulin tiedot • Tavoite: • Osallistuja tietää kokonaisarkkitehtuuriviitekehyksen käyttötarkoituksen ja arkkitehtuurin eri näkökulmien kuvausperiaatteet. Hän tietää projektien, hankkeiden ja kehitysohjelmien kuvaamisen periaatteet. • Sisältö: • Kokonaisarkkitehtuuriviitekehyksen käyttötarkoitus • Arkkitehtuurikuvausten kuvausperiaatteet • Projektien, hankkeiden ja kehitysohjelmien kuvaamisen periaatteet • Tietojärjestelmähankkeiden arviointi • Arkkitehtuurien kuvausympäristö • Tietoarkkitehtuurit • Kohdealueen kokonaisarkkitehtuuri

3. Kokonaisarkkitehtuuriviitekehys

4. JHKA-viitekehys • Julkisen hallinnon kokonaisarkkitehtuuri (JHKA) yleiskuvaus • JHKA suunnittelu- ja kuvausmenetelmät (JHS 179) • Sisältää kokonaisarkkitehtuurikehyksen ja menetelmän • JHKA hallintamalli • JHKA kohdealuejako • JHKA kohdealueen tehtävät • JHKA kypsyystasomalli • JHKA kehittämispolku • JHKA arkkitehtuuriperiaatteet • JHKA tavoitteet ja mittarit • JKHA yhteisen kokonaisarkkitehtuurin sisällön yleiskuvaus

5. Kokonaisarkkitehtuurikehyksen käyttötarkoitus • Kokonaisarkkitehtuurikehys on osa KA:n viitekehystä • Kuvattu JHS 179:ssä ja sen liitteessä 2 • Kokonaisarkkitehtuurikehys = Kokonaisarkkitehtuurin jäsennysmalli, joka tarjoaa näkökulmia ja lähestymistapoja kokonaisuuden hahmottamiseksi ja jäsentämiseksi paremmin käsiteltävään ja ymmärrettävään muotoon. • Tehtävänä on • Auttaa tunnistamaan kehittämisessä huomioonotettavia näkökulmia • Nostaa esiin tarkasteltavia kysymyksiä • Rajata mm. organisatorista kattavuutta ja tarkkuustasoa

6. Arkkitehtuurikehyksen näkökulmat Toiminta-arkkitehtuuri Tieto-arkkitehtuuri Tietojärjestelmä- arkkitehtuuri Teknologia- arkkitehtuuri • JHS 179 -suosituksen mukainen arkkitehtuurikehys sisältää neljä eri arkkitehtuurinäkökulmaa: • toiminta-, • tieto-, • tietojärjestelmä- ja • teknologia-arkkitehtuuri. • Kaikkia näitä näkökulmia koskettavat • Palveluarkkitehtuuri • Integraatioarkkitehtuuri • Tietoturva

7. JHS 179 -arkkitehtuurikehys Lähde: JHS 179

8. Käsitetasojen väliset suhteet, analogia Lähde: JHS 179

9. Arkkitehtuurikuvausten kuvausperiaatteet

10. Prosessien kuvausperiaatteet • Prosessien kuvaamisessa suositellaan käytettäväksi JHS 152 Prosessien kuvaaminen -suositusta. • Prosessien kuvaamisessa on eri käsitetasoja. • Pääprosessikartta • Toimintamalli ja prosessikuvaukset • Työnkulkukuvaukset • Kuvaukset tehdään loogiselle tasolle asti (taso 3) • Kaaviot • Prosessin perustietolomake • Prosessin sanallinen kuvaus Lähde: JHS 152

11. Prosessien kuvauskieli BPMN Prosessien kuvaamisessa käytetään BPMN-kuvauskieltä JHS 152 mukaisesti Prosessikuvauksiin kuuluu kaavio, prosessin perustiedot ja sanallinen kuvaus Esimerkki BPMN-prosessikaaviosta

12. Palvelujen kuvausperiaatteet • Jos julkisen hallinnon palveluja koskevia viitearkkitehtuureja on olemassa, noudatetaan niitä • Esim. Sähköisen asioinnin viitearkkitehtuurin palvelukuvaukset • Palveluja on eri tasoisia: • Palvelut: toiminnan tarjoamat ylätason palvelut • Tietojärjestelmäpalvelut • Teknologiapalvelut • Palvelut kuvataan JHS 179 liitteen 8 Palvelusalkkuun • Lisäksi tärkeimmistä palveluista kuvataan JHS 171 liitteen 4 mukainen kuvaus

13. Palvelun elinkaari Toiminta / asiakkaat Vaatimukset Muutosehdotus ja palvelun perustamiskirja Palvelu-strategia Resurssit ja rajoitteet Politiikat Strategiat Palvelutietämyksen- hallintajärjestelmä Palvelu-suunnittelu- paketit Palvelu-suunnittelu Standardit Arkkitehtuurit Ratkaisu- suunnitelma Transitio-suunnitelmien toteutus Palvelu- transitio SKMS päivitykset Testatut ratkaisut Uudet/muutetut/ poistetut palvelut Toiminnan arvo Palvelu-salkku Tuotanto- palvelut Tavoitteiden saavuttaminen Palvelu- tuotanto Palvelu- luettelo Jatkuva palvelun parantaminen CSI-rekisteri, kehittämis- toimenpiteet ja suunnitelmat Based on the Cabinet Office ITIL® material.

14. Elinkaaren vaiheiden tarkoitus • Palvelustrategia • Määrittää näkökulma, asema, suunnitelmat ja mallit, joita palvelutuottajan tarvitsee toteuttaa saavuttaakseen organisaation toimintatavoitteet • Palvelusuunnittelu • Suunnitella IT-palveluja, mukaan lukien hallintamenettelyt, prosessit ja politiikat, joita tarvitaan palvelutuottajan strategian toteuttamiseen ja palvelujen viemiseen tuettuihin tuotantoympäristöihin. Näin varmistetaan laadukkaiden ja vaikuttavien palvelujen tuottaminen ja asiakastyytyväisyys • Palvelutransitio • Varmistaa, että uudet, muutetut tai poistuvat palvelut vastaavat palvelustrategia- ja palvelusuunnitteluvaiheessa dokumentoituja toimintavaatimuksia • Palvelutuotanto • Koordinoida ja toteuttaa aktiviteetit ja prosessit, joita tarvitaan tuottamaan ja hallitsemaan sovituntasoisia palveluja toiminnan asiakkaille ja käyttäjille • Jatkuva palvelun parantaminen • Varmistaa, että IT-palvelut vastaavat toiminnan muuttuvia tarpeita tunnistamalla ja tekemällä parannuksia toimintaprosesseja tukeviin IT-palveluihin

15. Kumppanit UI HenkilöstöUI Asiakkaat UI Sisäverkko Internet Kurssille ilmoittautuminen Orkestrointikerros Tietojärjestelmä-palvelukerros Palvelukerros Kurssi Kurssisihteeri Kurssilainen - nimi - kurssikuvaus. Tietojärjestelmäpalvelujen orkestraatio • Toimintaprosessi orkestrointikerroksessa • Kukin toiminnan prosessi ohjaa toiminnallisuutta (orkestrointipalvelut) • Tietojärjestelmäpalvelut • Ylätason palveluja, jotka on löydettävissä automatisoitavista käyttötapauksista • (Alempi) Palvelukerros • Matalan tason palveluja, jotka koskettavat yhtä järjestelmää tai sen osaa • Tyypillisesti tietojen (datan) käsittelyyn liittyviä palveluja

16. Pilvipalvelut • Palveluiden virtualisointi tarjoaa mahdollisuuden palvelun ja sen tuottajan erottamiseen • Usein taustalla tarvitaan mahdollisuutta kuorman-tasaukseen sekä vika-sietoisuudenparantamiseen • Palvelupyyntöjen muunnokset sekä eri alustojen sekä tuotteiden yhteensovittaminen • Palveluiden tulee olla itsenäisiä, itseriittoisia • Irrotettavissa alustastaan ja siirrettävissä toiseen paikkaan • Käytetäänkö julkisia vai yksityisiä pilvipalveluja? • Palveluiden hallinta • Miten hallitaan palveluiden eri versioita käytännössä? • Miten palvelupyyntö reititetään sen version perusteella? • Ostetaan kapasiteettia tarpeen mukaan • Automaattinen konfiguraation muutos tarvittaessa • Miten tietoturva hoidetaan? • Kuka omistaa tiedot? • Miten haasteet ratkaistaan käytännössä?

17. Terminologian kuvausperiaatteet Sanastot kuvaavat fyysisen tason jäsennettyä tietoarkkitehtuuria, eli mitä termejä ja nimityksiä käytetään eri tilanteissa ja eri asioista. Sanaston kuvaamiseen käytetään JHS 179 liitteen 8 välilehteä Sanastot

18. Käsitteistön kuvausperiaatteet 1/2 • Käsitteistöstä kuvataan päätietoryhmät ja käsitteet • Päätietoryhmä = Organisaation tai organisaatioryhmän toiminnasta ja tietotarpeista johdettu ylätason looginen tietokokonaisuus. • 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 • JHS 179 liite 9 välilehti Informaatiosalkku

19. Käsitteistön kuvausperiaatteet 2/2 Opiskelija Kurssitoteutus Kurssi * 1 1 1 1 1 * * * * Kurssisuoritus Kurssi- ilmoittautuminen Esitiedot • Käsite = vakiintunut tietoryhmä • Käsitemallin kuvauksen tarkoituksena on selvittää organisaation ja ko. toiminnon keskeiset käsitteet • Käsitteiden luetteloinnin lisäksi on tärkeää visualisoida käsitemallia kuvaamalla käsitteet ja niiden väliset riippuvuudet • Kuvaustapana UML:n luokkakaavio (classdiagram)

20. Tietojärjestelmien kuvausperiaatteet 1/3 • Tietojärjestelmistä kuvataan vähintään • Tietojärjestelmäsalkku • = ”inventaariotaulukko” kaikista järjestelmistä ja niiden elinkaaresta • Havainnollisuuden vuoksi on suositeltavaa kuvata myös tietojärjestelmäkartta • Prosessien, tietojen ja tietojärjestelmien suhteiden kuvaus • Prosessit-tiedot-, Tiedot-tietojärjestelmät- sekä Prosessit-tietojärjestelmät -matriisit • Integraatioratkaisut • Integraatioratkaisuista kuvataan vähintään Liittymät ja rajapinnat -pohjan mukaiset tiedot

21. Esimerkki tietojärjestelmäsalkusta jatkuu. . .

22. Esimerkki integraatioratkaisusta

23. Tietojärjestelmien kuvausperiaatteet 2/3:Yhteydet julkisen hallinnon integraatioalustaan • Valtion yhteisen integraatiopalvelun (VIA) avulla valtionhallinnon organisaatiot voivat siirtää tietoja (sanomia) omien tietojärjestelmiensä ja muiden organisaatioiden tietojärjestelmien välillä tai omien tietojärjestelmiensä välillä • VIA on tuotantokäytössä Valtion IT-palvelukeskuksessa. • Valtion yhteisen verkon VY-verkon käyttöönotto Integraatiopalvelun yhteydessä on erittäin suositeltavaa • VY-verkko muodostaa siihen liittyneiden virastojen välisen valtion sisäisen verkon. • Näin viestinvälityksen tietoturva valtion organisaatioiden välillä parantuu. Lisätietoa: http://www.valtiokonttori.fi/fi-FI/Virastoille_ja_laitoksille/Yhteiset_ICTpalvelut

24. Vaatimukset Optimoi Suunnittelu Käytä Toteutus Käyttöönotto Tietojärjestelmien kuvausperiaatteet 3/3: Tietojärjestelmien elinkaarenhallinta Sovellushallinta on vakiintunut termi, joka kattaa kaikentasoiset ohjelmistot Sovellus-kehityksenvaiheet Palvelun-hallinnanvaiheet • Sovellushallinta on sovellusten ja tietojärjestelmien elinkaaren hallintaa toiminnan prosessien näkökulmasta • Sovellusten kehittäminen (development) • Sovellusten ylläpito (maintenance) • Sovellusten uudistaminen (renovation) • Sovellusten laajentaminen (enhancement)

25. Teknologioiden kuvausperiaatteet • 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 (Ks. seuraava sivu) • Teknisten linjausten lisäksi tulee kuvata teknologia-arkkitehtuurin kehittämistä ohjaavat arkkitehtuuri-periaatteet • EuropeanInteroperabilityFramework:n (EIF) teknologia-näkökulman periaatteet ovat keskeinen lähtökohta yhteentoimivuuttasuunniteltaessa (http://ec.europa.eu/idabc/en/document/5319/5883)

26. Teknologiapalvelut Teknologiapalveluilla tarkoitetaan laitteisiin ja laiteympäristöihin liittyviä palveluita ja ratkaisuja

27. Teknologiasalkku • Teknologiasalkku kuvaa laite- ja tuotetasolla käytettävän alustateknologian. • Suositeltavaa on kuvata teknologiasalkkuun myös teknisesti erilaiset työasemat ja päätelaitteet (esim. älypuhelimet). • Keskeistä arkkitehtuurin kannalta on tunnistaa kohteiden teknisten tietojen lisäksi laitteiden palvelutasot. • Teknologiasalkkuun kuvataan erityisesti palvelinten ja tietoliikenteen aktiivilaitteiden teknologiapalvelua koskeva sisältö • Tietoliikennekomponenteista tällaiseen salkkuun tallennetaan vain aktiivilaitteiden tiedot

28. Teknologiasalkun sisältö • Laite • Laitetyyppi • Laiteluokka • Laitteen nimi • Tyyppi ja malli • Valmistaja • Keskeisin varusohjelmstosisältö • Sijoituspaikka • Toimipiste, toimittajan laitetila • Palvelutaso • 24/7, laajennettu virka-aika, virka-aika • Tietoturvataso • Laitteen kriittisyys • Elintärkeä, tärkeä, hyödyllinen, ei luokiteltu • Muuta

29. Organisaatioiden kuvaamisperiaatteet • Organisaation rakenteista kuvataan organisaation rakenne eli eri osastot, yksiköt tai toiminnalliset kokonaisuudet sekä niiden vastuut • Kuvaus JHS 179 liitteen 9 Organisaatiot ja sidosryhmät -välilehden taulukon mukaisesti. • Suositeltuja organisaation kuvaustapoja ovat myös organisaatiokaaviot ja -matriisit. • Valmiita malleja löytyy useista yleisesti käytetyistä toimisto-ohjelmistoista.

30. Projektit, hankkeet ja kehitysohjelmat • Hankehallinnassa hallitaan suunniteltujen hankeaihioiden sekä käynnissä olevien kehittämishankkeiden kokonaisuutta • Hankeaihioiden osalta tehdään kustannus- ja hyötyanalyysit sekä hankkeiden toteutukseen johtavat investointipäätökset • Kehittämishanke hankkeistetaan, suunnitellaan ja toteutetaan arkkitehtuuri-suunnittelun ja investointipäätöksen mukaisesti • Kehittämisen toteutus-vaiheessa tehdään arkkitehtuurisuunnittelua tarkempi vaatimusmäärittely, jossa yksilöidään tuotettavan ratkaisun toiminnalliset ja laatuvaatimukset riittävällä tarkkuustasolla

31. Tietojärjestelmähankkeiden arviointi

32. Tietojärjestelmähankkeiden arvioinnin tarkoitus ja kohde • Arvioinnin tavoitteena on varmistaa, että • Suunnitelluilla tietojärjestelmäinvestoinneilla saavutetaan tavoiteltu vaikuttavuus, tuottavuus ja yhteentoimivuus • Toteutettavilla hankkeilla on onnistumisen edellytykset • Virastoja suositellaan arvioimaan menetelmän avulla • Kaikki tietojärjestelmähankkeet • Sellaiset toiminnan kehittämishankkeet, joihin sisältyy tietojärjestelmän kehittämistä • Lisäksi, arviointi mahdollistaa hankkeen hyötyjen jälkiseurannan • Jälkiseuranta ei ole osana arviointikehikkoa

33. Näkökulma ICT-hankkeiden arviointiin Onko tavoiteltavista hyödyistäyhdenmukainen käsitys? Onko hyötyjen realisointisuunniteltu ja vastuutettu? Onko arkkitehtuurit ja yhteentoimivuus huomioitu? Onko riippuvuudet muuhun kehittämiseen tunnistettu? Onko hankkeella osaava ja riittävä resursointi? Onko hankkeella tarkoituksen-mukainen ohjaus- ja hallintamalli? Lähde: Governance of IT investments, ISACA / IT Governance Institute Onko hanke strategian mukainen? Tuotokset suhteessa kustannuksiin ja riskitasoon?

34. Milloin arvioidaan • Kehikon mukainen arviointi on tarkoitettu tehtäväksi esiselvitysvaiheen jälkeen • Toteutettavasta ratkaisusta ja sen toteutukseen liittyvästä kokonaisuudesta on olemassa vähintään alustava suunnitelma • Tietohallintolaki edellyttää VM:n lausuntoa taloudelliselta arvoltaan tai muuten merkittävistä hankkeista ennen hankintaa • Merkittävä hanke = sillä on laajaa toiminnallista merkitystä ja se koskee olennaisesti keskeisiä rekistereitä tai yhteisiä tietojärjestelmiä tai hankinnalla olisi muista vastaavista seikoista johtuen laajaa toiminnallista merkitystä • VM:n ohje: taloudellisen arvon raja 5 milj. euroa • Lausunnon edellytyksenä on arviointikehikon mukainen arviointi

35. Arviointikehikon osa-alueet tiivistettynä VM/1640/00.00.00/2012

36. 1. Vaikuttavuus ja asiakashyödyt

37. 2. Tehokkuus, Tuottavuus, Taloudellisuus

38. 3. Osaaminen ja resursointi

39. 4. Yhteentoimivuus

40. 5. Toteutettavuus

41. Arvioinnin toteutus käytännössä Sovitaan arviointimenettelystä ja valmisteluvastuista sekä nimetään arvioijat Hankkeen vastuutahot kuvaavat arviointikehikon mukaiset kohdat arviointilomakkeelle (sis. viittaukset mahdollisiin liitteisiin) Hanke esitellään arvioijille ja arvioijat tutustuvat materiaaliin Arvioijat esittävät tarkentavia kysymyksiä hankkeen avainhenkilöille ja mahdollisesti keskeisille sidosryhmille (haastattelut) Arvioijat kirjaavat havaintonsa ja laativat arvioinnista yhteenvedon (ml. havainnot sekä suositukset jatkotoimenpiteiksi) Palautekeskustelu, jossa havainnot ja suositukset käydään läpi hankkeen vastuutahojen kanssa Arvioijat viimeistelevät arviointiraportin

42. Arviointiraportti • Täytetty arviointilomake (+ liitteet) = Arviointiraportti • Kehikkoon kuvataan asiat tiivistetysti, tarkemmat kuvaukset liitteiksi • Arviointilomakkeessa on eroteltu • Kuvattavat asiat (hanke täyttää) • Arvioitavat asiat (arvioijat täyttävät) • Etusivu, jossa hankkeen perustiedot ja arvioinnin yhteenveto • Keskeiset havainnot • Suositukset jatkotoimenpiteiksi • Arviointilomake ja ohjeita: http://www.julkict.fi/arviointi

43. Arkkitehtuurien kuvausympäristö

44. Arkkitehtuurien kuvausympäristö • Arkkitehtuurien kuvaukset kannattaa tallettaa keskitettyyn paikkaan, josta ne ovat kaikkien uudelleen käytettävissä • Kuvauksia pitää voida myös selailla vapaasti • Kuvaukset pitää versioida ja muutosten hallinta pitää hoitaa • Tarvitaan välineitä sekä kaavioiden piirtämiseen, taulukoitujen tietojen kuvaamiseen että sanallisten kuvausten luomiseen.

45. QPR Enterprise Architect • VM kilpailutti talvella 2011-12 kokonaisarkkitehtuurin kuvaamiseen tarkoitettuja välineitä yhteisten arkkitehtuurien kuvausvälineeksi • JHKA, kohdealueiden yhteiset kokonaisarkkitehtuurit, VHKA, Kuntasektorin yhteinen KA • Hankinnassa päädyttiin QPR Enterprise Architect –välineeseen • Kohdealueen vastuuministeriö voi jakaa käyttöoikeuksia edelleen niille organisaatioille, jotka osallistuvat kohdealueen yhteisen arkkitehtuurin ylläpitoon, ja nimenomaan yhteisen arkkitehtuurin ylläpitämistä varten, ei organisaation oman.

48. Toiminta Tietojärj. Tieto Teknologia Linjaukset

49. JHKA:n rakenne QPR:nEA:ssa

50. Tietoarkkitehtuurit