Tiera Yhteistyöfoorumi 2014 1. rinnakkaisohjelma: Kuntakentän yhteiset ICT-palvelut © Copyright Kuntien Tiera Oy Tiera Yhteistyöfoorumi 2014 Infra-osaamiskeskus ja Valtakunnalliset Infra-palvelut 26.8.2014 29.8.2014 Jari Nevalainen Turun kaupungin IT-palvelut Määre Määrä Työntekijöitä (IT) 72,8 htv Työasemia 12 600 Sovelluspaketteja 250 Sovelluspalvelimia 400 Sopimuksia 350 Tuettavia toimipisteitä 280 ympäri Varsinaissuomea Yrityksiä ja yhteisöjä 43 Palvelupyyntöjä ja vikailmoituksia / vuosi 29.8.2014 ~ 62 000 Käyttötalous (IT) 20,4 milj € Investoinnit (IT) 7,5 milj € Jari Nevalainen 3 ICT monessa puristuksessa toimiala johto Uudet Tarpeet kaupungin johto Tehostus Tarpeet ICT Teknologian uudistamisteknologia paine toimittajat Jatkuvuus Tarpeet käyttäjät 29.8.2014 Jari Nevalainen 4 kaupungin johto Make or Buy? Tehostus Tarpeet Oma osaaminen keskitetään toimiala- ja toimintaympäristö ICT osaamiseen toimiala johto Uudet Tarpeet ICT Teknologian uudistamisteknologia paine toimittajat Kustannustehokas palveluhankinta ja economy of scales yhteistyön avulla Jatkuvuus Tarpeet käyttäjät 29.8.2014 Jari Nevalainen 5 Infra ja Tiera 2011 ServiceDesk ja Lähituki -palvelut 2012 Incident Manager, Etätukipalvelu, Sovelluspaketointi 2013 Konesalipalvelu, Sovelluspalveluita 2014 Työasemapalvelu 2015 KuntaAD ja AD liittyvät palvelut, IDM, Seudullinen Tietoliikenneyhteistyö 2014 29.8.2014 2015 Jari Nevalainen 2013 6 Käyttäjien palaute palveluista • Toimialapalaute käyttäjiltä: • Jokaisen palvelupyynnön ja vikailmoituksen ratkaisun jälkeen kysytään tyytyväisyys (1-5) saatuun palvelutapahtumaan. Keskiarvo vuodelta 2013 oli 4,6. Vuonna 2014 keskiarvo noin 4,7. • Johdon palaute 29.8.2014 Jari Nevalainen 7 Kiitos! 29.8.2014 Jari Nevalainen Kaarinan tuotantopalveluiden kehitys, Tieran kapasiteettipalvelut ja skaalautuvuus Kari Hölsö, tietohallintojohtaja Kaarina ja tuotantopalveluiden perusta  Nykyinen konesali otettu käyttöön 2007 – 35 m2, 5 räkkikaappia (tarve 2007) – Kahdennettu varavirta (UPS-kesto vain noin 1 h) – Kahdennettu jäähdytys, mutta ei sammutusjärjestelmää  VMWare käyttöön 2007 (Dell Blade) – 16 korttipalvelinta (VMWare kolmella kortilla) – VMWare:ssa noin 100 virtuaalipalvelinta – Erillispalvelimet 40 kpl (2007)  n. 5 kpl (2014)  Levyjärjestelmä käyttöön 2007 (HP EVA 4000) – Tuotantodataa noin 15 TB  Erillinen varmistusjärjestelmä (toisessa kiinteistössä) – D2D -levyvarmistus ja nauharobotti Tietohallinto Jatkokehitys ja tekniikkanäkökulmat  Palvelintila ja tuotantotekniikka – Konesali kiinteistössä, josta Kaarinan muu toiminta poistuu – Konesali pakko uusia, mutta todellinen tilatarve 1-2 räkkiä – Uuden palvelin- ja tallennusjärjestelmän riittävän laaja osaamisen ylläpitäminen varusohjelmisto- ja rautatasolla? – Rautatasolla ”harvoin” ongelmia  ongelmat ainutkertaisia – Varmistustekniikat osoittautuneet ”haastaviksi”  Tietoliikenneyhteydet – Kaikesta huolimatta tarvitaan nopeat tietoliikenneyhteydet Turun kaupungin tuotantoympäristöön ja VSSHP:lle (MedBit) Tietohallinto Jatkokehitys ja toiminnalliset näkökulmat  Seudullisuus – Kaarina käyttää useita sovelluksia Turun hallinnoimasta tuotantoympäristöstä (mm. Xcity, VASKI –kirjasto) – Yhteyksiä myös välillä Kaarina – VSSHP (MedBit) – Muut pienet kuntien väliset ”palveluvaihdot”  ”Rakenteelliset” muutokset – SOTE –ratkaisujen vaikutukset tietotekniseen ympäristöön – Opetusympäristön siirtyminen vahvasti ”pilvipalveluihin” • Kaarinan Tablet –hanke – Vahva suuntaus kohti digitaalisempaa toimintaa • Vaikutukset tallennuskapasiteettiin • Vaikutukset varmistusjärjestelyihin Tietohallinto Hankittavan järjestelmäkokonaisuuden on mukauduttava teknisesti, toiminnallisesti, ja myös oma osaaminen huomioiden Tietohallinto Tieran kapasiteettipalvelut ja skaalautuvuus  Palvelinjärjestelmä – Vain konesalitarve  palvelimien siirto – Kapasiteettipalvelutarve  palvelinrauta ja tallennus/varmistusjärjestelmä palveluna – Järjestelmäpalvelut hankitaan täyspalveluna  Tallennusjärjestelmä – Tallennustilan laajennus joustavasti porrastettuna – Useita eri teholuokkia  Varmistusjärjestelmä – Perusvarmistukset levylle toiseen levyjärjestelmään – Nauhavarmistukset asiakkaan tilauksen mukaan Tietohallinto Kaarinan valinnat Tieran ”palvelusalkusta” 1  Tietoliikenne – Vahvistetaan tietoliikenne (10 Gbits) välillä Kaarina – Tiera JOKE (Kaarina järjestänyt itse) – Lisäkustannukset vähäiset, koska samalla purkautuu vanhoja yhteyksiä (Kaarina – Turku, Kaarina - MedBit)  Palvelinjärjestelmä – – – – Hankitaan palveluna palvelimet VMWare alustaksi Asennetaan oma VMWare ja hallinnoidaan itse Hankitaan palveluna lisäpalvelinkortteja erikoispalveluihin Osa nykyisistä korttipalvelimista virtualisoidaan suoraan VMWareen Tietohallinto Kaarinan valinnat Tieran ”palvelusalkusta” 2  Tallennusjärjestelmä – VMWaren siirtovaiheessa 10 TB – Jatkovaraukset + 5-10 TB  Varmistukset – Perusvarmistus toiseen levyjärjestelmään – Säilytys levyllä min. n kk – Varmistukset nauhalle tietyin väliajoin Tietohallinto Kaarinan ”skaalavalinnat” 1  Tietoliikenne – Vahvistetaan tietoliikenne (10 Gbits) välillä Kaarina – Tiera JOKE (Kaarina järjestänyt itse) – Lisäkustannukset vähäiset, koska samalla purkautuu vanhoja yhteyksiä (Kaarina – Turku, Kaarina - MedBit)  Palvelinjärjestelmä – – – – – Hankitaan palveluna palvelimet VMWare alustaksi Asennetaan oma VMWare ja hallinnoidaan itse Hankitaan palveluna lisäpalvelinkortteja Osa nykyisistä korttipalvelimista virtualisoidaan suoraan VMWareen Tietohallinto Eteneminen  Kaupunginhallituksen päätös 31.3.2014  Siirtoprojektin aloitus myöhästynyt Kaarinasta johtuvista syistä – Tablet –hanke – Tietoliikenneverkon kehittäminen  Perussopimus allekirjoitettu 21.8.2014  Tavoite: 80% siirretty 31.12.2014 mennessä Tietohallinto Arkkitehtuurin mallinnuspalvelu Case Espoo Marko Kukkonen, Konserniesikunta - Tietohallinto Kokonaisarkkitehtuuri (KA) Enterprise Architecture (EA) Näkökulmat: • • Kokonaisarkkitehtuuri kuvaa, kuinka organisaation toimintaprosessit, tiedot ja järjestelmät toimivat kokonaisuutena. Kehittämisen tulee olla toimintalähtöistä ja lähteä liikkeelle organisaation strategisista tavoitteista ja kansalaisille tarjottavien palveluiden parantamisesta. – • Näin saadaan parempia tuloksia kuin lähtemällä liikkeelle teknologian näkökulmasta. Kokonaisarkkitehtuuri on – suunnittelumenetelmä, jolla tuotetaan toiminnan ja IT-ratkaisujen tavoitetilan kuvaukset. – kuvaukset tavoitetilasta, nykytilasta ja siirtymäpolusta tavoitetilaan. – toiminta- ja hallintamalli, jonka avulla ohjataan suunnittelua, tunnistetaan ja poistetaan päällekkäinen kehittämistyö, varmistetaan laatu ja saadaan tehdyt suunnitelmat laajasti uudelleen käytettäviksi. Toiminta Tiedot • Palvelut • Prosessit Tietojärjestelmät • Tietojärjestelmäratkaisut • Käsitteet • Tietomallit Teknologia • Teknologiaratkaisut Tietoturva ja integraatio Arkkitehtuurilla tarkoitetaan kokonaisuuden ja sen osien rakennetta ja osien välisiä suhteita, sekä periaatteita ja suuntaviivoja niiden suunnittelemiseksi ja kehittämiseksi. 29.8.2014 20 Kokonaisarkkitehtuurityö Espoossa nyt Tehty ja käyttöönotettu Kehitystyö/käyttöönotto kesken • • • • • • • • Kokonaisarkkitehtuurityö on aloitettu 08/2011 ICT-ratkaisukehitysmalli käyttöönotettu 4/2014 (EsPro-malli jo 8/2013) Espoon KA-ryhmä läpikäy kaikki (lähes) ICT-ratkaisukehitystä sisältävät projektiaihiot Espoon KA-periaatteet hyväksytty kaupungin johtoryhmässä KA-ryhmän toiminta nojaa tällä hetkellä vahvasti KA-periaatteisiin Kokonaisarkkitehtuurin omistaja on kaupunginjohtaja Toiminta-arkkitehtuurin nykytilan kuvaus tehty • • • • KA-kuvausvälineen (QPR) käyttöönotto käynnissä (keskeisiä kehitysprojekteja tuetaan) Ylätason tavoitearkkitehtuuri (ja ylätason nykyarkkitehtuuri), jotka muodostavat jatkossa yhden KAohjauksen kulmakivistä Toimijarekisterin käyttöönotto ja tietoarkkitehtuurin jatkokehitys Kaupungin integraatiovalmiuksia/kyvykkyyttä kehitetään nopealla aikataululla KA-periaatteet päivitetään tämän vuoden kuluessa 21 Mihin KA-ongelmiin KA-väline erityisesti auttaa Toimintaa kehitetään teknologian tai teknologiatoimittajien ehdoilla Toimintayksiköt eivät ymmärrä tietojärjestelmiin tai tietoon liittyvien päätöksien vaikutuksia tai heijastuksia muihin VAIKUTUKSET yksiköihin Tuleviin toiminnan muutoksiin ei ehditä varautua Tehdään päällekkäisiä/turhia investointeja ja projekteja SUUNNITTELUVAIHEEN NÄKYVYYS KA-väline IT/tietohallinto koetaan toiminnan kehittämisen jarruna YHDENMUKAISUUS Toimintaprosessit hahmotetaan vain organisaation kautta Toiminnan ja ITyksiköiden/tietohallinnon yhteistyö kangertelee Sopimukset tehdään palvelutoimittajien ehdoilla, eikä ymmärretä sopimusteknisiä tai arkkitehtuurillisia ankkureita LISÄÄ YMMÄRRYSTÄ Järjestelmäkokonaisuuden kompleksisuus rajoittaa toiminnan kehittämistä Palvelukehityksessä ei hyödynnetä toimintaympäristön mahdollisuuksia kannustamalla kehittämään palveluita julkista tietoa avaamalla 22 KA-väline QPR: mitä, kuka ja miksi • Mitä – Eri arkkitehtuurialueiden dokumentointi • Kuka – Dokumentoijat eri KA-alueilla / toimialoilla, dokumentointien katselmoijat/katsojat ja ympäristön pääkäyttäjät – TIERA antaa tuen pääkäyttäjille ja tarjoaa teknisen ympäristön • Miksi – Kuvaukset aiemmin staattisina erillisinä dokumentteina – Järjestelmällinen KA-työ edellyttää vaivatonta kuvausten käyttöä – Kuvaa ja selittää kehittämisprojektien / prosessien väliset suhteet – Apu muutoksenhallinnassa ja hankinnoissa – Muutosten vaikutusten läpikäynti ja arviointi – On KA-työn apuväline, ei itsetarkoitus 29.8.2014 23 Arkkitehtuurin mallinnuspalvelu Arkkitehtuurin mallinnuspalvelu  Arkkitehtuurin mallinnuspalvelu on Tieran kunnille tarjoama palvelu kokonaisarkkitehtuurin mallintamiseen  Arkkitehtuurin mallinnuspalvelu kattaa kaikki kokonaisarkkitehtuurin kuvaukset: – Prosessit, tiedot, tietojärjestelmät, teknologian – Kaaviokuvat, luettelot, taulukot © Copyright Kuntien Tiera Oy 2 5 Arkkitehtuurin mallinnuspalvelun sisältö  Palvelu sisältää mallinnustyövälineen ja asiantuntijapalvelua  Mallinnustyöväline koostuu QPR-mallinnusohjelmistosta, QPR-palvelinohjelmistoista ja niihin liitetystä tietokannasta Arkkitehtuurin mallinnuspalvelu Mallinnustyöväline QPR-mallinnusohjelmisto QPRpalvelinympäristö Arkkitehtuurin mallintamisen asiantuntijapalvelu © Copyright Kuntien Tiera Oy 2 6 Monet kunnat palvelun asiakkaina  Tiera tarjoaa arkkitehtuurin mallinnuspalvelua asiakkailleen  Jokaisella palvelua käyttävällä kunnalla on palvelimella oma mallinnusympäristö  Kunnat voivat jakaa ja yhteiskäyttää yhteisiä arkkitehtuureja Espoo Espoo Kunta 2 Kunta 2 Kunta 3 Kunta 3 Kunta 4 Kunta 4 Kuntien yhteinen QPR-palvelinympäristö © Copyright Kuntien Tiera Oy 2 7 Arkkitehtuurin mallinnuspalvelun visio Valtionhallinnon kokonaisarkkitehtuuri STM OKM Vero VM (julkishallinnon yhteinen) muut Tieran hallintamalli Espoo Kunta 2 Kunta 3 Kuntien yhteinen kokonaisarkkitehtuuri Tieran palveluarkkitehtuuri Tieran arkkitehtuurin johtoryhmä Kunta 4 Kunta 5 Yhteinen mallinnuksen perusta (pohjamallit, mallipohjat, metamalli) Tieran arkkitehtuurin mallinnusympäristö KA-klubi (seminaarit, hyvät käytännöt) Asiantuntijapalvelut Mallinnusympäristön tuki 2 8 © Copyright Kuntien Tiera Oy Arkkitehtuurin mallinnuspalvelun hyödyntäminen kuntatoimijalla Mallinnustyövälineen käyttökohteet  JHS 179 – suosituksen mukaiset kuvaukset  Arkkitehtuurin eri näkökulmien kuvaukset  Organisaatiokohtaiset kuvaukset  Nykytilan ja tavoitetilan kuvaukset 30 Osa Kouvolan tietojärjestelmäkartasta © Copyright Kuntien Tiera Oy 3 1 Arkkitehtuurin osien yhteydet Eri näkymissä käytetään samoja elementtejä Kuvan lähde: QPR Kuvan lähde: QPR 32 Mallinnus ja katselu  Kuvaukset luodaan QPR työasemaohjelmistolla QPR Enterprise Architect QPR Portaali  Kuvaukset voidaan julkaista ja jakaa QPR portaalissa verkon kautta 33 Yhteiskäyttö kunnan sisällä Kunnan yhteiset arkkitehtuurielementit ja kaaviot Kunta Arkkitehtuurimalli 2 Arkkitehtuurimalli 1 Yhteisten tuotosten käyttö Uusien tuotosten luonti Kunnan pohjamalli 34 Yhteiskäyttö kuntien välillä Kuntien yhteiset arkkitehtuurielementit ja kaaviot Kunnat Kunta 2 Kunta 1 Tiera Yhteisten tuotosten käyttö Uusien tuotosten luonti Yhteinen tietokanta 35 Palvelun hyöty kunnalle Edut piirtotyökaluihin verrattuna • • • • • • • • • Arkkitehtuurin kaikki näkökulmat voidaan kuvata yhdessä työkalussa Palvelu tukee kokonaisarkkitehtuurin kuvaamista JHS 179 –suosituksen mukaan ArchiMate-, UML-, BPMN- ja toimintaprosessinotaatiot käytössä Arkkitehtuurin elementtien tiedot ja niiden suhteet ovat yhteisessä tietokannassa Kuvausten versionhallinta käytettävissä Ulkoista tietoa voidaan liittää arkkitehtuurikuvauksiin Arkkitehtuurikuvausten editointi on mahdollista tiimityönä Arkkitehtuurikuvaukset voidaan julkaista ja jakaa verkossa Arkkitehtuurin elementtejä ja kaavioita voidaan helposti uudelleenkäyttää Hyödyt yhteisestä palvelusta • • • • Kunnan ei tarvitse investoida oman palvelinympäristön perustamiseen ja ylläpitoon Kunta voi hyödyntää yhteisiä menetelmiä ja malleja Kuntien yhteisten arkkitehtuurien ja elementtien jakaminen ja hyödyntäminen mahdollista Arkkitehtuurin mallintamisen asiantuntijapalvelu käytettävissä 36 Vielä: Tieran valmiiksi kilpailuttama palvelu QPR paikalla asiakaspäivillä Kiitos! Yhteystiedot Espoon kaupunki: Marko Kukkonen TIERA: Jari Hintsala Kansallinen palveluväylä – käyttöönotto kuntakentälle Tieran yhteistyöfoorumi 27.8.2014 Espoon palveluväyläpilotti 29.8.2014 40 Espoon palveluväyläpilotin sisältö Projektin tavoitteena oli todentaa palveluväylän soveltuminen paikallisten integraatioiden toteuttamiseen eri ympäristöissä olevien tietojärjestelmien välillä. Espoo testasi palveluväylään perustuvaa tiedonsiirtoa hoitotyön ydinjärjestelmän ja eri järjestelmätoimittajien hoitotyötä tukevien järjestelmien välillä. Pilotti toteutettiin seuraavien järjestelmien välillä palveluväylän ylitse: • kotihoidon toiminnan ohjauksen ja optimoinnin järjestelmä (Tiera Mobiili Kotihoito), • potilastiedon perusjärjestelmä (Tieto Oyj:n Effica) sekä • kotihoidon työvuorosuunnittelun järjestelmä (CGI:n Titania). Pilotoinnin pohjaratkaisuksi valittu Viron kansallinen palveluväylä ”X-Road” on todettu toimivaksi sekä konseptina että tuotannossa olevana ratkaisuna. 29.8.2014 41 Espoon palveluväyläpilotti Effica (Tieto) Ulkopuolinen palveluntuottaja (Tieto) Tiedon tarjous: • Potilaan riskitiedot • Kertomustiedot Optio 1: • Potilaan perustiedot • Ajanvaraustiedot Optio 2: • Koodistot • Tilastotiedot Kotihoidon toiminnanohjaus + sähköinen oven avaus Ulkopuolinen (Fastroi) palveluntuottaja (Tiera) Kansallinen palveluväylä Internet Työvuorototeuma: vuoron alkuaika ja vuoron loppuaika Työvuorosuunnitelma: vuorossa olevat henkilöt Titania (CGI) Ulkopuolinen palveluntuottaja (Fujitsu) Palveluväyläpilotoinnin kokemuksia • Palveluväyläpilotti –projekti tuo kustannushyötyjä vasta kun integraatio viedään tuotantoon. Laskennalliset hyödyt mobiiliratkaisun käyttöönotosta: • Esimerkkilaskelma kun palveluaika lisääntyy 40 %:sta 60 %:iin (Espoon tavoite siirryttäessä mobiiliin kotihoitoon) 300 hengen kotihoitoyksikössä: • Säännöllisessä kotihoidossa noin 1290 asiakasta / kk, joka voisi nousta 1560 asiakkaaseen / kk (+ 270 asiakasta) • Tilapäisessä kotihoidossa noin 1000 asiakasta / kk, joka voisi nousta 1200 asiakkaaseen / kk (+ 200 asiakasta) • Tai asiakkaan luona vietetty aika voisi pidentyä • Jos lisäksi oletetaan, että Espoossa 80 % hoitajista on lähihoitajia ja 20 % sairaanhoitajia, vuotuinen säästöpotentiaali säännöllisessä kotihoidossa olisi 2 130 000 € / v ja tilapäisessä kotihoidossa 2 050 000 € / v. • Kun tilastointi ja kirjaaminen suoritetaan käynnin yhteydessä toiminnanohjaussovelluksella eikä toimistolla saavutettava laskennallinen työajan säästö olisi noin 2 900 000 € / v. 29.8.2014 43 Espoon palveluväyläpilotti HILKKA kotihoidon toiminnanohjaus (Fastroi) fw turvapalvelin / adapteri Ulkopuolinen palveluntuottaja (Tiera) Keskuspalvelut Palvelukatalogi Sopimuskatalogi fw Autentikointipalvelu Osoitteet Kansallinen palveluväylä Loki Internet Ulkopuolinen palveluntuottaja (Tiera) Espoon konesali fw turvapalvelin Effica (Tieto) Ulkopuolinen palveluntuottaja (Tieto) adapteri fw adapteri Titania (CGI) Ulkopuolinen palveluntuottaja (Fujitsu) Palveluväyläpilotti Kaupunki X palvelu palvelu fw turvapalvelin / liityntäpalvelin Ulkopuolinen palveluntuottaja Keskuspalvelut Palvelukatalogi fw liityntäpalvelin Autentikointipalvelu turvapalvelin turvapalvelin Sopimuskatalogi Osoitteet palveluväylä Loki Internet Espoon konesali fw turvapalvelin palvelu fw palvelu Ulkopuolinen palveluntuottaja Ulkopuolinen palveluntuottaja liityntäpalvelin liityntäpalvelin Palveluväyläpilotoinnin kokemuksia • Palveluväylä on turvallinen tiedonvälitysratkaisu julkisen internetin yli (vrt. esim. SOTE –alueen asettamat tietoturvavaatimukset) • X-Road on Virossa käytössä oleva standardoitu palveluväyläratkaisu, joka mahdollistaa julkisen ja yksityisen sektorin hallinnoimien ja eri puolille hajautettujen tietokantojen yhdistämisen yhdeksi palvelukokonaisuudeksi. • Palveluväylän hallintamalli / hallinta (vrt. Viron RIHA). • Hallintaprosessi (liittyminen, muutosten ylläpito, irtautuminen) • Auditoinnit • Sertifikaatit • Palvelun tuottaja / asiakas > nimeämiset (Y-tunnusten käyttäminen) • Väylän ryhmiä ei testattu (ryhmäjäsenyyden saamisen ohjeistus / edellytykset) • Lokitukset (lokien arkistointia taustajärjestelmään ei testattu, vrt. ohjeistus / lainsäädäntö) • Tietoliikennejärjestelyt (avaukset, yhteyksien testaus ja kuittaukset) • Informointitapojen kiinnittäminen (yleinen info, vastuuhenkilökohtainen…) • WSDL -kuvaukset (palvelukuvaus, jakeluihin sisäänrakennettu ominaisuus > ei sisällä toimivuuden tarkistusta) ja hallinnointi • Ympäristön pystytyksen tuki 29.8.2014 • Ympäristön valvonta (24/7, lokitukset, yhteyshenkilöt…) 46 Palveluväyläpilotoinnin kokemuksia • Yhtenäinen käsitteistö puuttuu (adapteri / liityntäpalvelin…) • Tietoarkkitehtuurista päättäminen haasteellista esim. ”potilaan perustiedot” Efficassa, Pegasoksessa, Hilkka kotihoidossa, Espoossa, Lahdessa ja Kanta palvelussa eri sisältöisiä • Teknisen ympäristön pystyttäminen (keskuspalvelut, turvapalvelin, liityntäpalvelin) • Päivitysten jakaminen (päivityksiä HTTPS konfigurointeihin) • Toteutus suoraviivaista saadun ohjeistuksen perusteella • Teknisen ympäristön pystyttäminen / turvapalvelimen käyttöjärjestelmä (Ubuntu 10.04 LTS) / tuetut laiteympäristöt • Valmiit laitespeksit (vrt. tietoliikenteen määrä) • Käyttäjien autentikointi (kaikki palvelimen käyttäjät voivat lähettää sanomia) • Organisointi ja sidosryhmäyhteistyö helppoa / haasteellista, nykyisen toimintatavan muutokset (omistaja) • Kaikkien palveluväylään liittyvien toteutusten tulee olla standaradinmukaisia • Integraatiokustannusten aleneminen • vrt. kustannukset: p-2-p • Käytetään yleiskäyttöisiä ratkaisuja (kelpaa moneen tarpeeseen) 29.8.2014 47 Palveluväyläpilotoinnin kokemuksia • Palveluväylä parantaa tietojen saatavuutta ja ohjaa yhteentoimivuuteen (mutta ei tuo mitään sisällölliseen yhteentoimivuuteen) • Palveluväylän tuotteistaminen (VM / Tiera / Espoo) • Työssä tulee huomioida kansallinen palveluarkkitehtuuri, kansallinen palveluväylä, tunnistamisen ja muiden yhteisten kansallisten palveluiden kehittäminen • Tukipalvelut • Ylläpidon aikainen tekninen tukipalvelu • Integraatioiden mallintaminen / -kuvaaminen (KA-väline / -välineet / ympäristö) • Integraatio strategia, periaatteet ja linjaukset sekä menetelmät ja standardit (kuka hallinnoi ja standardoi)? • Laajemmat integraatioratkaisut / Espoon sisäiset integraatioratkaisut (erillisen integraatioalustan tarve)? • Monitorointi tietosisältöön, triggerit, jonokäsittelyt ja adapterit eri tietomuodoille puuttuvat • Vain yksi palveluväylä mahdollinen? (mahdollistaa samat domain-nimet, vrt. yhdistäminen ESB:llä, tuleva versio mahdollistaa yhdistämisen + luottosuhteet, vrt. yhdistämisessä latenssiongelmat) 29.8.2014 48 Palveluväyläpilotoinnin kokemuksia • Kansallisen palveluväylän tuotantoympäristön valmistumista odotellessa (etenemispolku, jotta siirtymäaikana työmäärät minimoidaan): XML-pohjaiset Webservice –rajapinnat muutettavissa pienimmällä työllä palveluväylärajapinnoiksi • Pilotin jälkeen rakentamiskustannukset ennustettavissa melko hyvin • Palvelujen / intergraatioiden priorisointi palveluväylään liitettäessä (vrt. kansalliset tietovarannot / kuntakohtaiset integraatiot) • Ympäristön vikasietoisuudesta: Ei kahdennuksia, ei klustereita > sanoma voidaan menettää, jonka huomiointi jää lähettävän järjestelmän vastuulle • Mahdollistaa asynkronisen tiedonsiirron (antaa mahdollisuuksia organisaatioiden väliseen isojen tietomäärien siirtoon) • Testauksen tarkka ohjeistaminen (muuten runsaasti iterointia: ”liittymän rakentamista 95% ja 5% palveluväylää”) • Tarvitaan testiympäristö (ja sen hallinta) • ”Pystytetty ja toimiva palvelu tarvitsee vain vähän valvontaa / ylläpitoa” • Kaikkea ei voi / ei kannata siirtää palveluväylään • Turvapalvelinkoulutuksesta: Koulutus ei vaadi paikalle tuloa > aineisto oli riittävä 29.8.2014 49 Palveluväyläpilotoinnin kokemuksia • Kuinka laajasti X-Roadia käytetään Viron terveydenhuollon organisaatiossa yhdistämään sisäisesti eri it-järjestelmiä (esim. kaksi it-järjestelmää samassa sairaalassa) - X-roadia käytetään ulkoisiin yhteyksiin kansallisen tason integraatioissa (terveydenhuollon palveluntuottajien integrointiin kansallisiin rekistereihin, eresepiin tai kansalliseen terveysrekisteriin). - X-roadia käytetään harvoin terveydenhuollon eri palvelutarjoajien integrointiin (esimerkiksi perhelääkäreiden integrointiin joihinkin sairaaloihin, jotka tarjoavat palveluja X-Roadille). - X-roadia ei käytetä saman sairaalan sisällä. Se johtuu X-Roadin arkkitehtuurista, se tarjoaa turvallisen yhteyden (internetin yli) kahden X-Roadin turvapalvelimen välillä. Yhdessä sairaalassa on vain yksi X-Road -palvelin ja ei ole tarkoituksenmukaista tällöin siirtää dataa X-Roadin kautta. • Onko Viron sairaaloissa käytössä muita integraatioalustoja (esim. ESB, Microsoft BizTalk, IBM WebSphere ..) - Ei ole yhteistä alustaa sisäiseen integrointiin, kunkin sairaala päättää niistä itse. - Nortal käyttää räätälöityihin integrointeihin Oracle ESB:tä. Samaa alustaa käytetään sisäisten järjestelmien integraatioissa ja ulkoisten palveluntarjoajien 29.8.2014 yhteyksien rakentamisessa X-Roadin kautta (tiedossa on yksi Microsoft BizTalk 50 toteutus). Espoon linjaukset palveluväylästä ja integraatioarkkitehtuurista Asia Periaate Tarkempi kuvaus Kansallinen vai paikallinen palveluväylä (x-road) Espoo tukeutuu kansalliseen palveluväylään eikä toteuta paikallista palveluväylää (x-road) Nykyinen X-road-teknologia ei mahdollista väylien kytkemistä peräkkäin/rinnakkain. Sisäiset ja ulkoiset integraatiot kansallisessa palveluväylässä Kansallista palveluväylää käytetään pääsääntöisesti ulkoisten integraatioiden toteuttamiseen, pääkohteena tällöin kansalliset perustietovarannot. Sisäiset integraatiotarpeet on ratkaistava toisella tavoin. Kansallisen palveluväylä (x-road) ei ratkaise Espoon sisäisiä integraatiotarpeita. Sisäiset integraatiot ja rajapinnat kansalliseen palveluväylään Espoossa tarvitaan sisäinen integraatioalusta/palvelu (ESB), joka huolehtii organisaation sisäisistä integraatiotarpeista sekä voi liittää myös Espoon omat järjestelmät kiinni kansalliseen palveluväylään. Palveluväylä ei sinänsä ratkaise tietojärjestelmien rajapintaongelmia, vaan rajapinnat on kehitettävä sekä teknisessä että sisällöllisessä mielessä. Sisäinen integraatioalusta mahdollistaa integraatioiden toiminnan hallinnan ja valvonnan (eri lähteistä tulevan tiedon yhteismitallistaminen) 29.8.2014 51 Espoon linjaukset palveluväylästä ja integraatioarkkitehtuurista Asia Periaate Tarkempi kuvaus Sisäinen integraatioalusta kaupunkitasoisesti Espoo kehittää yhtä yhtenäistä integraatioalustaa koko kaupungin tarpeisiin. Espoon uusi sairaala (EUS) toimii tässä pilottina. Integraatiotarpeita on runsaasti ympäri kaupunkia eikä ole tarpeen kehittää pistemäisiä ratkaisuja päällekkäin (tuottavuus, kyvykkyys, jne.), aikataulu on sovitettava EUS-projektin tarpeisiin Sisäinen integraatioalusta kuntayhteisesti (Tiera) Espoo toimii pilottina/edelläkävijänä kehittämässä sisäistä integraatioalustapalvelua yhdessä Tieran kanssa ja lähtökohtana on integraatioalustapalvelun tekninen ja sopimuksellinen skaalautuvuus koko kuntakentälle. Sisäisten integraatioiden, palveluväylään liittymisen ja kuntien tietojärjestelmien rajapintojen kehittämisen tarpeet ovat samankaltaisia kaikilla kunnilla. Tieran toimiessa operaattorina voidaan sama kehitystyö hyödyntää useamman kunnan kohdalla (tuottavuus). 29.8.2014 52 Integraatioarkkitehtuuri Kaupunki X palvelu palvelu fw turvapalvelin / liityntäpalvelin Ulkopuolinen palveluntuottaja Keskuspalvelut Palvelukatalogi fw liityntäpalvelin Autentikointipalvelu turvapalvelin turvapalvelin Sopimuskatalogi Osoitteet Kansallinen palveluväylä Loki Internet Ulkopuolinen palveluntuottaja Integraatiopalvelu Espoon konesali Integraatioalusta turvapalvelin / liityntäpalvelin palvelu Ulkopuolinen palveluntuottaja turvapalvelin / liityntäpalvelin fw turvapalvelin fw palvelu Ulkopuolinen palveluntuottaja turvapalvelin / liityntäpalvelin Palveluväyläpilotin dokumentaatio • Espoo.fi > Espoon kaupunki > Uutiset > Espoon palveluväyläpilotoinnin kokemuksia 29.8.2014 54 Palveluväylän käyttöönoton haasteita Nykytilan toiminta-arkkitehtuurin keskeisiä haasteita: • Toiminta-arkkitehtuurin ylätason määrittelyn puute yhteentoimivuuden ja tehokkuuden varmistamiseksi. • Byrokraattisuus (kehittämisessä), joka on johtanut julkisen sektorin osa-optimointiin nykytilassa. Nykytilan tietoarkkitehtuurin keskeisiä haasteita: • Tietojen yhteensopimattomuus. • Tietojen kopiointi ympäri julkista sektoria sekä vaihteleva tietojen laatu. • Yhteistä tietomallia ja käsitteistöä ei ole määritelty. • Rajapintojen standardointia ja harmonisointia ei ole tehty. Nykytilan tietojärjestelmäarkkitehtuurin keskeisiä haasteita: • Kunnissa on toteutettu paljon eri tietojärjestelmäpalveluita, joissa on periaatteessa samanlaista toiminnallisuutta. • Tiedonvälityksen reaaliaikaisuuden ja kokonaisvaltaisen hallinnan puuttuminen. • Modulaaristen tietojärjestelmäpalveluiden puuttuminen, jotka ovat helpommin uudelleenkäytettävissä ja yhdisteltävissä erilaisiin koostettuihin palveluihin. 29.8.2014 55 Integraatioarkkitehtuuri – haasteet • • • • • • • • • • • tiedonsiirtojen hallinnan puute runsas manuaalinen työ järjestelmien ikä ja vanhakantaisuus järjestelmissä olevien kyvykkyyksien hyödyntämättömyys vastuiden määrittelyn epätarkkuus tietojen omistajuuden osalta tiedon uudelleenkäytön matala aste yksittäisen prosessinosan optimoiminen koko prosessin tukemisen sijaan tietojen laadun matala taso: eheys, reaaliaikaisuus, oikeellisuus, yksiselitteisyys vanhanaikaisten tiedonsiirtomenetelmien käyttö (siirtotiedostot) tiedonhallinnan matala kypsyysaste toimittajariippuvuus ja toimittajien suljetut rajapinnat käytetyissä järjestelmissä 29.8.2014 56 Integraatioarkkitehtuuri – tarpeet • tiedon yksiselitteisyys koko kaupungin sisällä (yhteinen käsitemalli) • tiedon luokittelu yhtenäisesti läpi koko kaupungin (tietoturva) • tiedon tuottamisen ja uudelleenkäytön järkeistäminen (samaa tietoa ei tuoteta useaan kertaan, yhteinen tietomalli) • tiedon saatavuus ja hyödynnettävyys useamman toimialan käyttöön tietojen yhdisteltävyys (yhteinen tietomalli) • tiedon hallinnan prosessi (yhteinen tietomalli) • tiedon hallinnan kehittäminen (roolit (erityisesti omistajuus), vastuut) • integraatioiden luomisen/käyttöönoton toimintamalli (sisältäen integraatioista aiheutuvat muutokset toimintaan ja toiminnan taustalla oleviin järjestelmiin) 29.8.2014 57 Kansallinen palveluväylä • • • • • • • • Kansallista palveluväylää käytetään pääsääntöisesti ulkoisten integraatioiden toteuttamiseen (integraatioissa, joissa ei ole tiedon manipulointitarvetta ja jos on, niin se tehdään jossain muualla esim. ESB -ratkaisussa), pääkohteena tällöin kansalliset perustietovarannot. Kansallisen palveluväylän toteutukset ja alueelliset / paikalliset ESB –ratkaisut ovat toisiaan tukevia ratkaisuja, joissa pitää noudattaa tarkoituksenmukaisuusperiaatetta Kansallinen palveluväylä (X-Road) muodostuu hajautetusta palvelinympäristöstä ja tarjoaa vakioidun, turvallisen tavan liittyä tarjoamaan / käyttämään palveluita julkisen palvelurajapinnan kautta ja rakentaa integraatioita. Mahdollistaa julkisen ja yksityisen sektorin hallinnoimien ja eri puolille hajautettujen tietovarantojen yhdistämisen yhdeksi palvelukokonaisuudeksi. Palveluväylä parantaa tietojen saatavuutta ja ohjaa yhteentoimivuuteen sekä tukee tiedonsiirtoa alueiden välillä. Sanoman hallinnointi jätetty liitettävien järjestelmien vastuulle (sanoma voidaan menettää). Ei sisällä mitään palveluita laajempia integraatioratkaisuja varten, joissa on tarve sanomien keskitettyyn valvontaan, tietosisällön monitorointiin, triggerointiin, jonokäsittelyihin, erilaisiin adaptereihin eri tietomuodoille tai tiedon roolipohjaiselle käyttämiselle. Kansallinen palveluväylä ei tarjoa tukea itse palvelujen kehittämiseen. Alueellinen/paikallinen ESB -ratkaisu • • • • • • • Alueellista / paikallista ESB –ratkaisua käytetään pääsääntöisesti sisäisten integraatioiden toteutuksessa tai integraatioissa, joissa on pyrkimyksenä tukea mahdollisimman monipuolisesti eri integraatiotekniikoita, mahdollistaa koosteisten palveluiden rakentaminen ja nostaa palvelukehityksen abstraktiotasoa perinteisestä ohjelmoinnista. Käytetään laajemmissa integraatioratkaisuissa / sisäisissä integraatioratkaisuissa, joissa on tarve sanomien keskitettyyn valvontaan, tietosisällön monitorointiin ja raportointiin, käyttäjän päätöksenteolle, triggerointiin, jonokäsittelyihin ja erilaisiin adaptereihin eri tietomuodoille tai ratkaisuissa, joissa tarvitaan kahdennuksia ja / tai klusterointeja. Mahdollistaa prosessien orkestroinnin Tukee eri elinkaaren vaiheissa olevien tietojärjestelmien integraatiotarpeita Palveluväyläratkaisut voivat olla sovelluskohtaisia (SB), organisaatiokohtaisia (ESB) tai useamman organisaation yhteisiä eli alueellisia. Kaikilta em. tasoilta voi liittyä kansalliseen palveluväylään – tarkoituksenmukaisuus, monistettavuus ja skaalautuvuus ratkaisee toteutusmallin käyttötarkoituksen mukaan. Toteutuksen tulee noudattaa valtakunnassa, alueella ja organisaatiossa hyväksyttyjä kokonaisarkkitehtuuriperiaatteita (mm. JHKA ”Vältä päällekkäisiä ratkaisuja”). 29.8.2014 60 29.8.2014 61 Kansallisen palveluarkkitehtuurin toteuttamisohjelma (KaPA) 29.8.2014 62 Kansallisen palveluarkkitehtuurin toteuttamisohjelma (KaPA) Kansalliseen palveluarkkitehtuurikokonaisuuteen sisältyvät seuraavat osat: • Kansallinen palveluväylä (tiedonvälityskerros) • Kansallinen sähköinen tunnistusmalli • Kansalliset ratkaisut yritysten, muiden organisaatioiden ja luonnollisten henkilöiden roolien ja valtuutusten hallintaan • Kansalaisten, yritysten ja viranomaisten tarvitsemat yhteiset palvelukanavat (palvelunäkymät) • Ohjelman toimeenpanon ja toteutettavien kokonaisuuksien jatkuvan ylläpidon ja valvonnan edellyttämät ohjaus- ja toimintamallit • Lainsäädäntötoimien valmistelu 29.8.2014 63 Kansallisen palveluarkkitehtuurin toteuttamisohjelma (KaPA) Aikataulu: • 2015 palveluväylä ja julkisen hallinnon tuottamia rekisteritietoja sisältävä katselupalvelu kansalaisille (ns. kansalaisnäkymä) avataan tuotantokäyttöön, kansallinen sähköinen tunnistusmalli valmisteltu • 2016 tarvittavat lainsäädäntömuutokset on selvitetty ja valmisteltu; kansallisen palveluarkkitehtuurin ja sen osakokonaisuuksien jatkuvan ylläpidon ja kehittämisen ohjaus- ja hallintamallit sekä toimintaprosessit on jalkautettu osaksi toimintaa asteittaisen kehityksen ohella • 2017 rooli- ja valtuutuspalvelu, sähköinen identiteetti ja palvelunäkymät ovat tuotantokäytössä siten, että niihin on integroitu keskeiset kansalaisia, yrityksiä ja hallintoa koskevat palvelut ja tietovarannot 29.8.2014 • 2018 kansallinen palveluarkkitehtuuri siihen kuuluvine osineen on 64 kokonaisuudessaan tuotantokäytössä Kansallisen palveluarkkitehtuurin toteuttamisohjelma (KaPA) 29.8.2014 65 Kari Kankaanhuhta kari.kankaanhuhta@espoo.fi 29.8.2014 66