Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko

Esitys aiheesta: "Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko"— Esityksen transkriptio:

1 Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko
Huom! Kalvojen alapuolella on usein täydentävää tekstiä. Copyright © Valtiovarainministeriö

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ö v. 1.1 Copyright © Valtiovarainministeriö

3 Kokonaisarkkitehtuuriviitekehys
Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko v. 1.1 Kokonaisarkkitehtuuriviitekehys v. 1.1 Copyright © Valtiovarainministeriö

4 Kokonaisarkkitehtuuriviitekehyksen käyttötarkoitus
Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko v. 1.1 Kokonaisarkkitehtuuriviitekehyksen käyttötarkoitus Kokonaisarkkitehtuuriviitekehys = 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 Arkkitehtuurikehys toimii nimensä mukaisesti organisaation kehittämistoiminnan kehyksenä antaen puitteet tehtäville kuvauksille ja kuvausten tasoille. 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. v. 1.1 Copyright © Valtiovarainministeriö

5 Arkkitehtuurikehyksen näkökulmat
Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko v. 1.1 Arkkitehtuurikehyksen näkökulmat 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 Toiminta- arkkitehtuuri Tieto- arkkitehtuuri Tietojärjestelmä- arkkitehtuuri Teknologia- JHS 179: ”Kokonaisarkkitehtuuria voidaan kuvata kussakin päänäkökulmassa myös horisontaalisista näkökulmista, esim. palveluarkkitehtuurin-, integraatioarkkitehtuurin tai tietoturvallisuuden näkökulmasta. Tärkeytensä vuoksi kokonaisarkkitehtuuria kehitettäessä on tietoturvallisuuden näkökulma huomioitava koko ajan. Tietoturvallisuus edellyttää jo itsessään kokonaisvaltaista organisaation rakenteiden hallintaa ja huomioon ottamista. joten erilaisten ratkaisujen tietoturvallisuus tulee ottaa huomioon kautta linjan kaikissa eri kuvauksissa.” v. 1.1 Copyright © Valtiovarainministeriö

6 JHS 179 -arkkitehtuurikehys
Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko v. 1.1 JHS 179 -arkkitehtuurikehys 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. Lähde: JHS 179 v. 1.1 Copyright © Valtiovarainministeriö

7 Käsitetasojen väliset suhteet
Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko v. 1.1 Käsitetasojen väliset suhteet JHS 179: ” Käsitetasojen sisältämät kohteet yleensä täsmentyvät siirryttäessä käsitetasolta kohti fyysistä tasoa, mutta käsitetasoilla on myös muita riippuvuuksia. Esimerkiksi ylimmän, käsitteellisen tason palvelut, eli toiminnallisuudet, kohdistuvat monesta moneen -suhteella loogisen tason komponentteihin. Tyypillisintä on monen käsitteellisen palvelun kohdistuminen yhteen loogiseen komponenttiin, kuten kuvassa on esitetty.” Lähde: JHS 179 v. 1.1 Copyright © Valtiovarainministeriö

8 Arkkitehtuurikuvausten kuvausperiaatteet
Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko v. 1.1 Arkkitehtuurikuvausten kuvausperiaatteet v. 1.1 Copyright © Valtiovarainministeriö

9 Prosessien kuvausperiaatteet
Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko v. 1.1 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 Prosessien kuvaaminen tarkentuu ja yksityiskohtaisuus lisääntyy mitä lähemmäksi toteuttamis-(toimeenpano) rajapintaa mennään. Arkkitehtuurin suunnittelussa harvoin on tarvetta mennä tasolle neljä eli työnkulkukaavioihin asti. Prosesseja kuvattaessa huomioidaan organisaation hierarkiatasojen lisäksi myös käsitetasot. Kartta organisaation pääprosesseista kuvataan käsitteellisellä tasolla. Loogisella tasolla kuvataan organisaation toimintamalli- ja prosessinkulkukaaviot Fyysisellä tasolla kuvataan työnkulkukaaviot, eli tarkemmat ja yksityiskohtaisemmat kuvaukset prosessien kulusta eri vaihtoehtoineen. Prosessikuvauksiin kuuluu: Prosessikaaviot (prosessikartta ja –kaaviot) Prosessin perustietolomakkeet jokaisesta prosessista (JHS 152, liite 1) Prosessin sanallinen kuvaus (joko JHS 152, liite 2 tai yksinkertaisempi kuvaus) Lähde: JHS 152 v. 1.1 Copyright © Valtiovarainministeriö

10 Prosessien kuvauskieli BPMN
Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko v. 1.1 Prosessien kuvauskieli BPMN Prosessien kuvaamisessa käytetään BPMN-kuvauskieltä JHS 152 mukaisesti Prosessikuvauksiin kuuluu kaavio, prosessin perustiedot ja sanallinen kuvaus Esimerkki BPMN-prosessikaaviosta BPMN eli Business Process Modeling and Notation –kuvauskieli Prosessien graafinen kuvauskieli, joka kuvaa toimintaprosessin kulun päästä päähän. Object Management Groupin (OMG) hyväksymä standardi v. 1.0 hyväksyttiin v. 2.0 hyväksyttiin Prosessikaaviossa painopiste on tekemisellä ja kuka tekee. Prosessissa liikkuva tieto tai materia on vähemmällä huomiolla. Käytetään sekä organisaation sisäisten prosessien että organisaatioiden välisten toimintaprosessien kuvaamiseen. Käytetään myös koreografioiden mallintamiseen. v. 1.1 Copyright © Valtiovarainministeriö

11 Palvelujen kuvausperiaatteet
Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko v. 1.1 Palvelujen kuvausperiaatteet Jos julkista hallintoa koskevia palvelukuvauksia (viitearkkitehtuuri) 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 Palvelut: Toiminnan ylätason 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. Sähköisen asioinnin viitearkkitehtuuri sisältää mm. ohjeita ja hyviä käytäntöjä sähköisten palvelujen kehittämiseen sekä palvelukatalogin teknisistä palveluista. JHS 179, Liite 8, Palvelusalkku –välilehden tiedot: Palvelu (palvelutyyppi, palveluryhmä, palvelu) Vastuu Kuvaus Asiakkaat ja Asiakasmäärät Volyymit Merkitys Tehokkuus Automaatio ja Sähköistys Kehittämistarve Muuta v. 1.1 Copyright © Valtiovarainministeriö

12 Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko
Palvelun elinkaari Toiminta / asiakkaat Vaatimukset Muutosehdotus ja palvelun perustamiskirja Palvelu-strategia Resurssit ja rajoitteet Politiikat Strategiat Palvelutietämyksen- hallintajärjestelmä Palvelu-suunnittelu Palvelu-suunnittelu- paketit Standardit Ratkaisu- suunnitelma Arkkitehtuurit Palvelu- transitio Transitio-suunnitelmien toteutus SKMS päivitykset Testatut ratkaisut Uudet/muutetut/ poistetut palvelut Palvelujen kuvaamisessa käytetään yleisesti ITIL:in mukaista lähestymistapaa. Palvelun elinkaari voidaan jakaa viiteen päävaiheeseen: Palvelustrategian luominen Palvelusuunnittelu Palvelutransitio eli käyttöönotto Palvelutuotanto Jatkuva palvelun parantaminen, joka onkin palautesilmukka alkuun. Kuvassa esiintyvät lyhenteet: SKMS = Service Knowledge Management System  - itse asiassa se on kuvassa ison tietovaraston nimi englanninkielisenä lyhenteenä. Kyseessä on tietovarasto, jossa on kaikki palvelun tuottamiseen liittyvä tietämys, jota palveluntuottaja tarvitsee. Käytännössä tämä on käsitteellinen kokonaisuus, joka koostuu monista tietokannoista ja järjestelmistä paperidokumentteja ja ihmisten päässä olevaa tietoa unohtamatta. CSI-rekisteri = Continual Service Improvement –register  - kehitysideat sijoitetaan tänne luokiteltavaksi ja priorisoitavaksi, mikä on jatkuvan palvelun parantamisen (CSI) elinkaaren vaiheen vastuulla. Kun kehitysidea hyväksytään se siirretään CSI-rekisteristä palvelun kehityssuunnitelmaan (SIP). Näitä yllä olevia englanninkielisiä lyhenteitä käytetään myös Suomessa. Virallinen ITIL:in suomennus ei tunne suomenkielisiä termejä näille. Toiminnan arvo Palvelu-salkku Tuotanto- palvelut Palvelu- tuotanto Tavoitteiden saavuttaminen Palvelu- luettelo Jatkuva palvelun parantaminen CSI-rekisteri, kehittämis- toimenpiteet ja suunnitelmat v. 1.1 Based on the Cabinet Office ITIL® material. Copyright © Valtiovarainministeriö

13 Elinkaaren vaiheiden tarkoitus
Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko v. 1.1 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 v. 1.1 Copyright © Valtiovarainministeriö

14 Tietojärjestelmäpalvelujen orkestraatio
Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko v. 1.1 Tietojärjestelmäpalvelujen orkestraatio Kurssisihteeri Kurssilainen 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 Orkestrointikerros Tietojärjestelmä- palvelukerros Palvelukerros Internet Sisäverkko Asiakkaat UI Kumppanit UI HenkilöstöUI Kurssille ilmoittautuminen Yksittäisen järjestelmän tai sovelluksen arkkitehtuurin lisäksi on mietittävä koko organisaation järjestelmäarkkitehtuuria (Enterprise Architecture, EA). Tämän lisäksi yhä useampi organisaatio on lähtenyt kehittämään toiminta-arkkitehtuuria (Business Architecture, BA) tai prosessiarkkitehtuuria (Process Architecture, PA), joiden avulla hallitaan myös itse toimintaa. Esimerkkikuvassa on hyvä huomata, että arkkitehtuurikerrokset eivät tarkoita välttämättä vain yhden järjestelmän tai sovelluksen arkkitehtuurikerroksia, vaan laajempaa kokonaisuutta, jossa voi olla useita järjestelmiä ja sovelluksia. Prosesseissahan usein tarvitaan useiden sovellusten apua: Orkestrointikerroksen ideana onkin koordinoida, miten nämä kaikki toimivat yhteen. Käytännössä orkestrointikerros toteutetaan jonkin välineen avulla, johon kuvataan (ohjelmoidaan) toimintaprosessit (vrt. toiminnanohjausjärjestelmät). Alimpana kerroksena on matalan tason palvelukerros (vakiintunut SOA:n termi), jossa mennään yhden järjestelmän sisäisiin, matalan tason palveluihin, joiden avulla esim. haetaan dataa tietokannasta tai tehdään järjestelmän sisäisiä toimintoja. Kurssi - nimi - kurssikuvaus. v. 1.1 Copyright © Valtiovarainministeriö

15 Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko
Pilvipalvelut Palveluiden virtualisointi tarjoaa mahdollisuuden palvelun ja sen tuottajan erottamiseen Usein taustalla tarvitaan mahdollisuutta kuorman-tasaukseen sekä vika-sietoisuuden parantamiseen 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ä? Pilven toteutusmalleja on kahta tyyppiä: Yksityinen (private) pilvi Palvelut toimitetaan organisaation oman intranetin kautta palomuurin sisäpuolella. Organisaatio voi myös hankkia oman pilven, mutta laitteistot ja palvelut tarjotaan palveluntarjoajan konesalista. Julkinen (public) pilvi Julkisen pilven tapauksessa pilvipalvelut tarkoittavat tietokonekapasiteetin ja -palvelujen ostamista/hyödyntämistä joustavasti palveluna internetin välityksellä. Sovellusten ja palvelujen ylläpito siirtyy kokonaan pilven ylläpitäjälle, ja organisaatio voi keskittyä omaan ydintoimintaansa. Ts. organisaatio ei itse omista tai hallitse sovelluksia tai palveluja. Julkisten pilvipalvelujen käytössä voi tulla lainsäädännöllisiä rajoituksia vastaan. Pilvipalvelujen toimittajien auditoitavuus voi olla vaikeaa. v. 1.1 Copyright © Valtiovarainministeriö

16 Terminologian kuvausperiaatteet
Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko v. 1.1 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 JHS 179, Liite 8, Sanastot –välilehden tiedot: Termi (+ sanastoryhmä) Selite Lähde Synonyymit Termi ruotsiksi Termi englanniksi Muuta v. 1.1 Copyright © Valtiovarainministeriö

17 Käsitteistön kuvausperiaatteet 1/2
Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko v. 1.1 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 Päätietoryhmä = Organisaation tai organisaatioryhmän, tässä tapauksessa koko julkisen hallinnon, toiminnasta ja tietotarpeista johdettu ylätason looginen tietokokonaisuus. Päätietoryhmien ja niitä tarkentavien tietoryhmien tarkoitus on mallintaa ja jäsentää tietokokonaisuus hallittavissa oleviin osiin. Jäsennystä käytetään tietojen ja niitä tuottavien ja käyttävien palvelujen ja prosessien välisten suhteiden kuvaamiseen. Jäsennystä käytetään myös kuvaamaan tietojen sijoittumista tietovarantoihin ja tietojärjestelmiin. JHS 179, Liite 9, Informaatiosalkku –välilehden tiedot: Päätietoryhmän nimi (+ tietoryhmät) Kuvaus Omistaja Lähde Tila Synonyymi Tietosuojataso v. 1.1 Copyright © Valtiovarainministeriö

18 Käsitteistön kuvausperiaatteet 2/2
Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko v. 1.1 Käsitteistön kuvausperiaatteet 2/2 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 (class diagram) Opiskelija Kurssisuoritus * 1 Kurssitoteutus Kurssi Esitiedot Kurssi- ilmoittautuminen Käsitemalli piirretään usein käyttäen vain luokkien nimiä. Luokasta tulisi olla lyhyt kuvaus, mikäli luokan nimi ei itsestään selvästi kerro, mistä on kyse. Muista, että kaikki eivät välttämättä ymmärrä toimialueen käsitteistöä. Myös attribuutit eli tietosisältö kaipaa kuvaamista. Käsitemallin käsitteiden kuvaus viedään JHS 179 liitteen 8 taulukkoon (ks. esimerkki alla). v. 1.1 Copyright © Valtiovarainministeriö

19 Tietojärjestelmien kuvausperiaatteet 1/3
Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko v. 1.1 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 v. 1.1 Copyright © Valtiovarainministeriö

20 Esimerkki tietojärjestelmäsalkusta
jatkuu. . . v. 1.1

21 Esimerkki integraatioratkaisusta
v. 1.1

22 Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko
Tietojärjestelmien kuvausperiaatteet 2/3: Yhteydet julkisen hallinnon integraatioalustaan Valtion yhteinen integraatiopalvelu (VIA) on tuotantokäytössä Valtion IT-palvelukeskuksessa. Palvelun avulla julkisen hallinnon organisaatiot voivat siirtää tietoja (sanomia) omien tietojärjestelmiensä ja muiden organisaatioiden tietojärjestelmien välillä tai omien tietojärjestelmiensä välillä Lisää tietoa: Integraatiopalvelut ( 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 intranetin. Näin viestinvälityksen tietoturva valtion organisaatioiden välillä parantuu. Lisää tietoa: Valtion yhteinen verkko VY-verkko ( VIP eli Valtion IT-palvelukeskus voi tarjota integraatiopalvelua (VIA) koko julkiselle hallinnolle. Tosin voi olla, etteivät kunnat voi käyttää palveluja kilpailuttamatta. Integraatiopalvelu mahdollistaa sanomien välittämisen tietojärjestelmien välillä sanomaliikenteen valvonnan ja hallinnan integraatiopalvelun teknisen tuen Raportoinnin Lisäksi palveluun voi erikseen tilata integraatiokonsultaatiota integraatioiden hyväksymistestausta erittelyn sanomaliikenteestä asiakkaan edelleen laskutusta varten Valtion yhteinen turvallinen tietoliikenneratkaisu VY-verkko tarjoaa valtionhallinnon organisaatioille nopean, luotettavan ja turvallisen tavan kytkeytyä valtion yhteisiin palveluihin, toisiinsa sekä ulkoisiin palveluihin, kuten internetiin. VY-verkko muodostaa siihen liittyneiden virastojen välisen valtion sisäisen intranetin. Näin viestinvälityksen tietoturva valtion organisaatioiden välillä parantuu. VY-verkon keskitetty tietoturva tarjoaa virastoille palomuuripalvelun, tunkeutumisenestojärjestelmän, haittaohjelmien ja roskapostin suodatuksen sekä palvelunestohyökkäysten torjunnan. Tietoliikenteen, tietoturvavalvonnan ja postinvälityksen ongelmanselvitys kootaan VY-verkossa keskitettyihin palvelupisteisiin, joita koordinoidaan Valtionkonttorissa toimivassa Valtion IT-palvelukeskuksessa. v. 1.1 Copyright © Valtiovarainministeriö

23 Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko
Tietojärjestelmien kuvausperiaatteet 3/3: Tietojärjestelmien elinkaarenhallinta Sovellushallinta on sovellusten elinkaaren hallintaa toiminnan prosessien näkökulmasta Sovellusten kehittäminen (development) Sovellusten ylläpito (maintenance) Sovellusten uudistaminen (renovation) Sovellusten laajentaminen (enhancement) Suunnittelu Toteutus Käyttöönotto Käytä Optimoi Vaatimukset Valitettavasti sovellusten kehittäminen ja toiminnan kehittäminen nähdään toisistaan erillisinä. Tämän takia sovellusten kehittäjät ja toiminnan kehittäjät eivät kommunikoi riittävän ajoissa. Seuraukset: Sovellusten elinkaarta ei ole suunniteltu Sovellusten ylläpitoon tarvittavia resursseja ei käytetä suunnitelmallisesti Ylimääräisiä kustannuksia Sama juttu pätee sovellusten kehittämiseen ja käyttöön: ne nähdään peräkkäisinä vaiheina. Niinpä sovellusten kehittäjät ja käyttöä tukeva tuotantohenkilökunta eivät kommunikoi riittävän ajoissa. Sovellusten tuotantovaatimukset eivät täyty Tieto ei siirry tuotantohenkilöstölle ja päinvastoin Palveluissa tuotantoaikaisia ongelmia turhaan Palvelun- hallinnan vaiheet Sovellus- kehityksen vaiheet v. 1.1 Copyright © Valtiovarainministeriö

24 Teknologioiden kuvausperiaatteet
Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko v. 1.1 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 European Interoperability Framework:n (EIF) teknologia-näkökulman periaatteet ovat keskeinen lähtökohta yhteentoimivuutta suunniteltaessa ( v. 1.1 Copyright © Valtiovarainministeriö

25 Teknologiapalvelut Teknologiapalveluilla tarkoitetaan laitteisiin ja laiteympäristöihin liittyviä palveluita ja ratkaisuja v. 1.1

26 Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko
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 Teknologioiden kuvausperiaatteet, mm. standardit, suositellut tuotevalinnat ja konfiguraatiot v. 1.1 Copyright © Valtiovarainministeriö

27 Teknologiasalkun sisältö
Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko v. 1.1 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 v. 1.1 Copyright © Valtiovarainministeriö

28 Organisaatioiden kuvaamisperiaatteet
Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko v. 1.1 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. Toimitusjohtaja Kehittäjät toimintajohtaminen Tietotyöläiset Taloushallinto Organisaatio kuvataan hierarkkisesti eli eri tasoilla. Liite 9 käyttää organisaatiosta ja sidosryhmästä yhteisnimitystä ’toimija’. v. 1.1 Copyright © Valtiovarainministeriö

29 Projektit, hankkeet ja kehitysohjelmat
Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko v. 1.1 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 Huom! Ministeriötasolla puhutaan usein hankkeista, vaikka kyse olisi projektista 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 tekniset vaatimukset riittävällä tarkkuustasolla v. 1.1 Copyright © Valtiovarainministeriö

30 Tietojärjestelmähankkeiden arviointi
Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko v. 1.1 Tietojärjestelmähankkeiden arviointi v. 1.1 Copyright © Valtiovarainministeriö

31 Arvioinnin tarkoitus ja kohde
Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko v. 1.1 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 v. 1.1 Copyright © Valtiovarainministeriö

32 Näkökulma ICT-hankkeiden arviointiin
Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko v. 1.1 Näkökulma ICT-hankkeiden arviointiin Onko hanke strategian mukainen? Tuotokset suhteessa kustannuksiin ja riskitasoon? Onko tavoiteltavista hyödyistä yhdenmukainen käsitys? Onko hyötyjen realisointi suunniteltu 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 v. 1.1 Copyright © Valtiovarainministeriö

33 Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko
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 yli 5 M€:n 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ä Lausunnon edellytyksenä on arviointikehikon mukainen arviointi Tietohallintolain 4 § Ennen kuin 2 §:n 2 momentin 1 ja 2 kohdassa tarkoitettu viran-omainen päättää tietohallintoa koskevasta omasta hankinnastaan taikka muusta sellaisesta sen ratkaistavissa olevasta valtion talousarviosta rahoitetusta tietohallintoa koskevasta hankinnasta, jolla on laajaa toiminnallista merkitystä tai joka on taloudelliselta arvoltaan merkittävä, sen on pyydettävä asiasta valtiovarain-ministeriön lausunto. Lausuntomenettely koskee tietohallintolain piiriin kuuluvien viranomaisten tietojärjestelmä- ja tietohallintohankkeita, jotka ovat joko viraston omia tai joita se rahoittaa. Hankkeilla tulee lisäksi olla laajaa toiminnallista merkitystä Ne koskevat olennaisesti keskeisiä rekistereitä tai yhteisiä tietojärjestelmiä tai hankinnalla olisi muista vastaavista seikoista johtuen laajaa toiminnallista merkitystä Esimerkiksi tietosisältö tai rajapinta muuttuu oleellisesti tai muutokset koskevat useamman viraston välisiä yhteisiä prosesseja tai ne ovat taloudelliselta arvoltaan merkittäviä : hankinta-arvo vähintään 5 miljoonaa euroa (hankintalainsäädännön mukainen hankinnan ennakoitu arvo v. 1.1 Copyright © Valtiovarainministeriö

34 Arviointikehikon osa-alueet tiivistettynä
Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko v. 1.1 Arviointikehikon osa-alueet tiivistettynä Perustiedot Miksi hanke on käynnistetty ja mistä siinä on kyse? Mitä on tarkoitus saada aikaiseksi? 1. Vaikuttavuus ja asiakashyödyt Mitä vaikuttavuus- ja asiakashyötyjä hankkeella tavoitellaan? Miten hyödyt realisoidaan? 2. Tehokkuus, Tuottavuus, Taloudellisuus Mitä tehokkuushyötyjä hankkeella tavoitellaan? Onko laadittu elinkaaren aikainen kustannus-hyötyanalyysi? 3. Osaaminen ja resursointi Onko hankkeella riittävästi osaamista ja resursseja? Miten tarvittavaa osaamista kehitetään? 4. Yhteentoimivuus Mitkä ovat hankkeessa keskeiset yhteentoimivuuden tarpeet ja miten ne on suunniteltu ratkaistavan? 5. Toteutettavuus Onko hanke kokonaisuutena valmisteltu ja suunniteltu siten, että sen läpiviennillä on onnistumisen edellytykset? VM/1640/ /2012 Copyright © Valtiovarainministeriö

35 1. Vaikuttavuus ja asiakashyödyt
Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko v. 1.1 1. Vaikuttavuus ja asiakashyödyt Mitä kuvataan Mitä arvioidaan Tavoiteltava yhteiskunnallinen vaikuttavuus, esim. Palvelujen laadun paraneminen, hyödyt asiakkaalle Hallinnollisen taakan väheneminen Hyötyjen realisoiminen Mahdolliset ei-toivotut vaikutukset Onko vaikuttavuustavoitteet ja asiakashyödyt tunnistettu? Onko hyötyihin mahdollisesti liittyvät oletukset tai epävarmuus- tekijät tunnistettu? Onko hyötyjen realisoimiseksi tarvittavat toimenpiteet tunnistettu ja suunniteltu? Copyright © Valtiovarainministeriö

36 2. Tehokkuus, Tuottavuus, Taloudellisuus
Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko v. 1.1 2. Tehokkuus, Tuottavuus, Taloudellisuus Mitä kuvataan Mitä arvioidaan Prosessien tehostuminen Taloudelliset hyödyt Kustannukset Hyötyjen realisoiminen Hankkeen rahoitus Onko hankkeella tavoiteltavat tehokkuushyödyt tunnistettu? Onko hankkeesta laadittu kustannus-hyötylaskelma, jossa on esitetty taloudelliset hyödyt ja hankkeen kokonaiskustannukset? Onko hyötyjen realisoimiseksi tarvittavat toimenpiteet tunnistettu ja suunniteltu? Onko hankkeen rahoitus kunnossa? Copyright © Valtiovarainministeriö

37 3. Osaaminen ja resursointi
Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko v. 1.1 3. Osaaminen ja resursointi Mitä kuvataan Mitä arvioidaan Tarvittava osaaminen hankkeen aikana ja sen jälkeen Hankkeen resursointi Onko hankkeen aikaiset ja sen jälkeiset osaamistarpeet tunnistettu? Onko mahdollisten osaamis- vajeiden täyttämiseksi olemassa suunnitelma? Onko hankkeen resursointi suunniteltu ja onko se hankkeen laajuuteen nähden tarkoituksen- mukaisella tasolla? Copyright © Valtiovarainministeriö

38 Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko
4. Yhteentoimivuus Mitä kuvataan Mitä arvioidaan Yhteentoimivuuden tarpeet ja kuvaukset Miten huomioitu Yhteiset arkkitehtuuri- periaatteet Yhteiset arkkitehtuurit Organisaation kokonais- arkkitehtuuri Onko hankkeessa tunnistettu oleelliset organisaation ulkoiset sekä sisäiset yhteentoimivuuden tarpeet? Onko suunniteltu, miten ne ratkaistaan? Onko arkkitehtuurikuvaukset tehty ja ovatko ne menetelmän (JHS 179) mukaisia? Onko yhteiset arkkitehtuuriperiaatteet ja arkkitehtuurit huomioitu ja hyödyn- netty? Onko hanke linjassa oman organisaa- tion kokonaisarkkitehtuurin kanssa? Copyright © Valtiovarainministeriö

39 Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko
5. Toteutettavuus Mitä kuvataan Mitä arvioidaan Riippuvuudet muuhun kehittämiseen Hankkeen valmistelu ja suunnittelu Hankkeen ohjaus Lainsäädäntö Riskit Tietoturva Onko riippuvuudet muuhun kehittämiseen tunnistettu? Onko hankkeen rajaus selkeä? Onko hankkeesta olemassa kokonaissuunnitelma? Onko hankkeen ohjausmalli ja organisointi suunniteltu? Onko tunnistettu keskeiset sidosryhmät ja suunniteltu niiden osallistuminen? Onko yhteydet lainsäädäntöön tunnistettu? Onko riskit tunnistettu? Onko tietoturva-asiat huomioitu? Copyright © Valtiovarainministeriö

40 Arvioinnin toteutus käytännössä
Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko v. 1.1 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 v. 1.1 Copyright © Valtiovarainministeriö

41 Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko
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: v. 1.1 Copyright © Valtiovarainministeriö

42 Arkkitehtuurien kuvausympäristö
Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko v. 1.1 Arkkitehtuurien kuvausympäristö v. 1.1 Copyright © Valtiovarainministeriö

43 Arkkitehtuurien kuvausympäristö
Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko v. 1.1 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. v. 1.1 Copyright © Valtiovarainministeriö

44 QPR Enterprise Architect
Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko v. 1.1 QPR Enterprise Architect VM kilpailutti talvella 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. v. 1.1 Copyright © Valtiovarainministeriö

45 Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko
QPR Enterprise Architect –välineessä on useita erilaisia näkymiä, joiden kautta voidaan kuvata ja tarkastella kuvattavaa asiaa. v. 1.1 Copyright © Valtiovarainministeriö

46 Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko
JHS 179 suunnittelunäkymä on työkalun vuokaavionäkymä, jonka kautta laaditaan kaikki kaaviot. JHS 179 kuvaukset näyttämästä kuvasta valitaan kuvaus, jota laatimaan siirrytään hiiren 2. näppäimen takaa löytyvällä komennolla ’Alemmalle prosessitasolle’. v. 1.1 Copyright © Valtiovarainministeriö

47 Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko
Toiminta Tietojärj. Tieto Teknologia Linjaukset JHS 179 navigaattorinäkymän kautta laaditaan sanalliset kuvaukset. Sitä kautta löytyvät kaikki JHS 179 liitteiden 8 ja 9 taulukkojen tiedot. v. 1.1 Copyright © Valtiovarainministeriö

48 JHKA:n rakenne QPR:n EA:ssa
Kokonaisarkkitehtuurin yleisesittelyn syventävä jatko v. 1.1 JHKA:n rakenne QPR:n EA:ssa QPR:n EA-välinettä voidaan käyttää yhteisenä kuvausvarastona eli repositorynä, jonne viedään kaikki ylimmän tason kokonaisarkkitehtuurikuvaukset. Tällä saavutetaan uudelleenkäytettävyyttä. v. 1.1 Copyright © Valtiovarainministeriö