TYÖPAJA ARKKITEHTUURIN KÄYTÖSTÄ - OHJELMA -

Liikennetelematiikan kansallinen järjestelmäarkkitehtuuri TYÖPAJA ARKKITEHTUURIN KÄYTÖSTÄ - OHJELMA - Liikenne- ja viestintäministeriön työpaja 21.9.2000

Sisällys 1 Työpajan agenda...3 2 TelemArk-yleisesittely...4 2.1 Järjestelmäarkkitehtuurin sisältö...4 2.2 Järjestelmäarkkitehtuurin lukeminen...4 2.3 Järjestelmäarkkitehtuurin käyttö ministeriön näkökulmasta...4 3 Prosessikohtaisten lopputulosten läpikäynti...5 3.1 Toimintoprosessi...5 3.2 Tietojärjestelmien ja tietojärjestelmäkomponenttien hajautuskaaviot...5 3.3 Standardit ja standardit rajapinnat...5 3.4 Puutteet, kehitystarpeet ja jatkosuositukset...5 4 Case LM - arkkitehtuurin käyttö liikennetelematiikan ohjaamiseen...7 4.1 Yksittäisen palvelun arviointi...7 4.1.1 Palvelun kuvaus...7 4.1.2 Palvelun vertaaminen arkkitehtuuriin...7 4.1.3 Puutteiden, kehitystarpeiden ja toimenpiteiden arviointi...9 4.1.4 Reunaehtojen huomiointi...9 4.2 Kehityksen ohjaus...10 4.3 Arkkitehtuurin käyttö ja...11 5 Raportointi...12

1 TYÖPAJAN AGENDA Paikka: Cap Gemini Oy, Niittymäentie 9, Espoo HPY:n karttalehti 11, ruutu 73-43 Aika: Torstai 21.9.2000 9.00-10.00 TelemArk-yleisesittely Järjestelmäarkkitehtuurin sisältö Järjestelmäarkkitehtuurin lukeminen Järjestelmäarkkitehtuurin käyttö 10.15-10.30 Tauko 10.30-12.00 Prosessikohtaisten lopputulosten läpikäynti Toimintoprosessi Tietojärjestelmien ja tietojärjestelmäkomponenttien hajautuskaaviot Standardit ja standardit rajapinnat Puutteet, kehitystarpeet ja jatkosuositukset 12.00-13.00 Tauko 13.00-15.45 Case LM - arkkitehtuurin käyttö liikennetelematiikan ohjaamiseen (Tauko noin kello 14.30) Yksittäisen projektin arvioiminen Kehityksen ohjaus Käyttö ja 15.45-16.00 Yhteenveto päivästä Ohjelman kellonajat ovat ohjeellisia.

2 TELEMARK-YLEISESITTELY 2.1 Järjestelmäarkkitehtuurin sisältö Esitellään yleisesti Liikennetelematiikan kansallisen järjestelmäarkkitehtuurin tavoitteet, toteutus ja sisältö. 2.2 Järjestelmäarkkitehtuurin lukeminen Esitellään, miten järjestelmäarkkitehtuuria lähdetään lukemaan. Arkkitehtuurin lukuohjeet on kuvattu Kehittämissuunnitelman luvussa 3.1.1 Arkkitehtuurin lukeminen. Kaikkia arkkitehtuuriraportteja ei ole tarkoitus lukea aina tarkasti kannesta kanteen vaan arkkitehtuuria voidaan lukea tarkoituksen perusteella valikoiden. Lukeminen on perusteltua aloittaa Arkkitehtuurikuvauksen sivulla 15 olevasta yleiskuvasta liikennetelematiikan prosesseista ja niiden välisistä yhteyksistä. Yleiskuvasta lukija voi siirtyä suoraan niihin Arkkitehtuurikuvauksen kappaleen 3 Käsitteellinen arkkitehtuuri prosessikuvauksiin, jotka häntä kiinnostavat. Prosessikuvauksiin tutustumisen jälkeen lukija voi siirtyä katsomaan samojen prosessien tietojärjestelmien hajautuskaavioita Arkkitehtuurikuvauksen lukuun 4 Looginen arkkitehtuuri. Tämän jälkeen lukija voi tutustua prosesseissa tunnistettuihin puutteisiin ja kehitystarpeisiin Kehittämisuunnitelman luvussa 4 ja tärkeimmiksi katsottuihin jatkotoimenpiteisiin luvussa 5 2.3 Järjestelmäarkkitehtuurin käyttö ministeriön näkökulmasta Esitellään, miten ministeriö voi käyttää arkkitehtuuria hankearvioinnin lähtökohtana ja liikennetelematiikan kehityksen ohjaamiseen. Tätä on kuvattu Kehittämisuunnitelman luvussa 3. Lisäksi esitellään, miten eri organisaatioit voivat käyttää kansallista järjestelmäarkkitehtuuria oman työnsä lähtökohtana. Myös tätä on kuvattu Kehittämisuunnitelman luvussa 3.

3 PROSESSIKOHTAISTEN LOPPUTULOSTEN LÄPIKÄYNTI 3.1 Toimintoprosessi Seinällä isossa koossa Tiedotus julkisesta liikenteestä toimintoprosessi, jota työpajassa käytetään esimerkkiprosessina tulosten esittelystä. Esitellään esimerkkiprosessin kuvaustapa miten prosessikuvaus on syntynyt työpajassa varsinainen prosessi (prosessikomponentit, mitä niissä tapahtuu sekä komponenttien väliset yhteydet) Tietoturva- ja telematiikkariippuvuusluokitukset Keskustellaan esityksen oikeellisuudesta ja kattavuudesta 3.2 Tietojärjestelmien ja tietojärjestelmäkomponenttien hajautuskaaviot Esimerkkiprosessin tietojärjestelmien ja tietojärjestelmäkomponenttien hajautuskaaviot suuressa koossa seinällä. Esitellään esimerkkitapaus ja keskustellaan esityksestä. 3.3 Standardit ja standardit rajapinnat Esimerkkiprosessiin liittyvät standardit ja standardit rajapinnat suuressa koossa seinällä. Esitellään standardikuvaukset ja keskustellaan niistä Esitellään standardien rajapintojen kuvaukset katsotaan mistä yhteyksistä standardit rajapinnat ovat olemassa keskustellaan siitä, miten toimitaan, jos rajapintakuvausta pitää muuttaa tai laajentaa keskustellaan siitä, miten toimitaan, jos rajapintakuvausta ei ole 3.4 Puutteet, kehitystarpeet ja jatkosuositukset Tiedotus julkisesta liikenteestä esimerkkiprosessin puute- ja tarveanalyysikuvat selityksineen suuressa koossa seinällä. Lisäksi seinälle koottu toimenpiteet, jotka koskevat erityisesti esimerkkiprosessia.

Esitellään puutteet, tarpeet ja kehitysehdotukset. Keskustellaan havaintojen ja ehdotusten oikeellisuudesta ja tärkeydestä.

4 CASE LM - ARKKITEHTUURIN KÄYTTÖ LIIKENNETELEMATIIKAN OHJAAMISEEN 4.1 Yksittäisen palvelun arviointi 4.1.1 Palvelun kuvaus Arvioitavana on kuvitteellinen hankehakemus TETRA II ohjelmaan. Rahoitusta hakevassa hankkeessa Pääkaupungin liikenneinfo Oy pilotoi pääkaupunkiseudun joukkoliikenteen ja pääkaupunkiseudulta lähtevien kaukoliikenteen bussien reitinsuunnittelupalvelua. Hankkeen tekninen yleissuunnitelma on seuraavassa kuvassa. Sybase SQL Server Esimerkkiehdotus Pääkaupunkiseudun JL-WEB palvelusta pysäkki.dat reitti.dat aikataulu.dat paik.txt vrpis.txt vuoro.txt liik.txt RS6000 palvelin SQ Server WAN Link esikäsittely palvelin WAN Link station_mh.dat stations_ytv.dat timetab_mh.dat timetab_ytv.dat FTPpalvelin reitinsuunnittelu palvelin MH_YTV.dbb LAN Link WEB palvelin HTML JAVA script Hankkeessa tuottajina toimivat Matkahuolto Oy ja YTV. Pääkaupungin liikennetieto Oy huolehtii reittisuunnitelmien tekemisestä ja WEB-palvelusta. Palvelu tarjotaan yhtenä Sonera Plazan osana. 4.1.2 Palvelun vertaaminen arkkitehtuuriin Prosessikuvaus Vertailun tekevät LM:n edustajat työpajan vetäjän avustuksella.

Seinällä suuressa koossa TelemArkin toimintoprosessi, joka vastaa arvioitavana olevaa hanketta. Rajataan toimintoprosessista komponentit ja yhteydet, jotka palvelu kattaa. Merkitään palvelussa mukana olevat organisaatiot muistilapuilla prosessikuvauksen arkkitehtuuriin aktoreiden kohdalle. Mikäli saman aktorin kohdalla on useampia todellisia toimijoita tehdään kullekin toimijalle oma prosessikomponentti. Täydennetään/muutetaan prosessikomponenttien nimiä tarpeen mukaan. Merkitään muutokset prosessikuvaan oikeille kohdilleen muistilapuilla. käyttäjä toinen prosessi haku/ vastaanotto palvelun joku muu käsittely palvelun tarjonta liikenneinfon liikenne YTV MH joukkoliikenneinfon reitti ja vuoro tieverkon tieverkon Looginen arkkitehtuuri Työpajan vetäjä esittelee, miten vertailu loogiseen arkkitehtuuriin tehdään. Seinällä suurena ko. palvelun kattava tietojärjestelmätoimintojen ja tietojärjestelmäkomponenttien hajautuskaavio. Rajataan tietojärjestelmätoiminnot ja yhteydet, joita palvelussa tarvitaan. Selvitetään palvelussa mukana olevien organisaatioiden oikeat järjestelmät ja sijoitetaan niiden nimet loogiseen arkkitehtuuriin oikeille paikoilleen muistilapuilla. Katsotaan tietojärjestelmäkomponenttien hajautuskaaviosta osat, joita palvelun toteutuksessa tarvittaisiin.

server@ workstation @ server@ JORE LAN@ LAN@ workstation @ WAN LK- TIETO LAN@ server@ workstation @ server@ other device @ 4.1.3 Puutteiden, kehitystarpeiden ja toimenpiteiden arviointi Seinällä ko. palvelun prosessikuvaus, josta puutteet ja tarpeet on osoitettu. Lisäksi puutteet, tarpeet ja ko. prosessiin liittyvät toimenpide-ehdotukset paperilla. Keskustellaan mitä ovat suunnitteilla olevan palvelun kannalta suurimmat puutteet ja kehitystarpeet nykyjärjestelmissä. Keskustellaan miten hyvin arvioitavana oleva pilotti paneutuu tai ratkaisee näitä tarpeita. Merkitään tärkeimmät pilotissa ratkeavat asiat toimintoprosessikuvaan oikeille paikoilleen. Pohditaan mitkä tärkeät kysymykset jäävät vastausta vaille ja voisiko hankkeelle osoittaa lisätehtäviä näiden miettimiseksi? 4.1.4 Reunaehtojen huomiointi Työpajan vetäjä esittelee. Keskustellaan listatuista reunaehdoista. Seinällä ja erillisillä papereilla ko. toimintoprosessit, joihin on merkitty sovellettavat kansainväliset standardit ja sovitut kansalliset standardit rajapinnat. Poimitaan kuvauksista standardit, jotka hankkeessa olisi huomioitava. Tehdään muistilapuilla prosessikuvauksen viereen lista huomioitavista standardeista.

käyttäjä palvelun toinen prosessi käsittely palvelun tarjonta haku/ vastaanotto GDF RDS- TMC liikenneinfon joukkoliikenneinfon liikenne reitti ja vuoro ISO 12345 RDS-TMC tieverkon tieverkon ISO 77777 GDF Poimitaan kuvauksista standardit rajapinnat, jotka hankkeessa olisi huomioitava. Tehdään muistilapuilla prosessikuvauksen viereen lista huomioitavista rajapinnoista. Listataan vastaavasti palvelussa tarvittavat rajapinnat, joille siirtoformaattia ei ole yhteisesti sovittu. käyttäjä toinen prosessi haku/ vastaanotto palvelun liikenneinfon olennainen rajapinta liikenne käsittely palvelun tarjonta standardi rajapinta puuttuu joukkoliikenneinfon tieverkon tieverkon reitti ja vuoro olennainen rajapinta 4.2 Kehityksen ohjaus Työpajan vetäjä esittelee yhden esimerkin, miten TETRA II -ohjelman yksi hankealue voidaan liittää arkkitehtuurin prosessikuvauksiin. Esimerkkinä toimii TETRA II -ohjelman osahanke 4 Liikenteen häiriötilanteiden hallinta, jota verrataan TelemArkin Häiriönhallinta, Yksilöliikenne -prosessiin.

osa-alueen rajaus 1 riskikulj. hallinta Tiedotus autoilijoille ajoneuvo havaitseminen tunnistettu havainnoija havaitseminen 2 3 tienpitäjä havaitseminen vastaanotto hoito pelatustoimi havaitseminen vastaanotto hoito poliisi havaitseminen vastaanotto hoito Käydään läpi prosessiin liittyvät TelemArkin kehittämissuunnitelmassa määritellyt tärkeimmät puutteet ja kehitystarpeet. Ja arvioidaan ollaanko Liikenteen häiriötilanteiden hallinta osahankkeessa tai jossakin muussa hankkeessa tekemässä näitä asioita. Puute/tarve 1. Häiriö välittäminen ajoneuvosta prosessi ja yhteydet puuttuvat 2. Häiriö välitys ja vastaanotto viranomaisten välillä kehitysasteella - muoto epäyhtenäistä 3. Häiriötilanteiden hoitamisen yhteistyömallit kehitysasteella Jne. Vastaus Ei sisälly nykyisiin hankkeisiin TETRA II osahanke 4, osahankeessa 1 rajapintojen kuvaukset TETRA II osahanke 4 Keskustellaan Arkkitehtuurin ja hankkeiden yhdistämisen järkevyydestä Miten hankkeet pitäisi kytkeä arkkitehtuuriin 4.3 Arkkitehtuurin käyttö ja Keskustellaan siitä miltä arkkitehtuuri vaikutti onko siitä hyötyä liikenneministeriölle ja alan organisaatioille. Työpajan vetäjä esittelee ajatuksia siitä, mitä asioita arkkitehtuurin on liittyy Keskustellaan, miten arkkitehtuurin tulisi organisoida

5 RAPORTOINTI Jokaisesta työpajasta tehdään lyhyt muistio, jossa käsitellään seuraavia asioita Miten työpajan osanottajat kokevat arkkitehtuurin käytön Miten osanottajat kokivat työpajan (hyödyt/haitat) Palaute arkkitehtuurin sisältöön ja on Työpajakohtaisten muistioiden perusteella tehdään yhteenveto, jossa arvioidaan tarvetta toteuttaa uusia työpajoja ja tehdään suositus jatkotoimenpiteiksi.