Palautekooste ja työryhmän vastine: JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen muutosehdotusten hyväksyminen (2.

Transkriptio

1 Palautekooste ja työryhmän vastine: JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen muutosehdotusten hyväksyminen (2. vaihe) 1. Organisaatio Vastaajien määrä: 10 - THL - KAOS-osaamisyhteisö - Gerenios Oy - Valtion tieto- ja viestintätekniikkakeskus Valtori - Terveyden ja hyvinvoinnin laitos (THL) - Maanmittauslaitos - JHS XXX Rekisteritiedon metatiedot -työryhmä - QPR Software - Sosiaali- ja terveysministeriö - Verohallinto Yhteyshenkilön tiedot Vastaajien määrä: Suositusluonnoksen hyväksyminen työryhmän tekemillä muutoksilla Vastaajien määrä: Vastustusperusteet Vastaajien määrä: Tämä palaute on täydennys THL:n lähettämään palautteeseen. Vastustusperusteet on esitetty aiemmassa Vastustusperiaatteet annettu JHS 198- palautteessa. palautteen joukossa. Ne huomioidaan ko. palautteen käsittelyssä. 4.2 Jotta kokonaisarkkitehtuurikuvauksia voitaisiin laajamittaisesti hyödyntää yhteentoimivuuden edistämiseksi julkishallinnossa, tulisi kaikkien julkishallinnon organisaatioiden toiminnan kehittämiseen osallistuvien ymmärtää, mistä kokonaisarkkitehtuurimenetelmässä on kyse ja mitä konkreettisia hyötyjä yhteisen menetelmän käytöllä voidaan saavuttaa. JHS 179 -suosituksen päivitysluonnos on nykyisellään liian laaja ja vaikeasti ymmärrettävä kokonaisuus tämän Kokonaisarkkitehtuuri tulisi ottaa käyttöön kattavasti julkisessa hallinnossa. KA-menetelmä on monin osin hyvin abstrakti ja sen ymmärtäminen ei onnistu vain suositukseen perehtymällä, VM onkin

2 ymmärryksen avaamiseksi. Edellisen lausuntokierroksen vastineessa todetaan, että suositus on suunnattu arkkitehdeille ja että suosituksen jalkauttamisen tueksi on tulossa VM:stä koulutus- ja esittelymateriaaleja. Pelkästään arkkitehtien vastuulle jalkauttamista ei voida sälyttää, vaan kaikkien toiminnan kehittämiseen osallistuvien, ml. organisaatioiden johdon, on ymmärrettävä, mistä kokonaisuudessaan on kysymys. Kahdesta edellisestä JHS 179 -suositukseen ja kokonaisarkkitehtuuriin liittyvästä VM:n järjestämästä koulutuskierroksesta saatujen omien kokemusten ja muiden koulutuksiin osallistuneiden palautteiden perusteella tätä ymmärrystä ei ole onnistuttu riittävästi lisäämään. Miten tämä ongelma on ajateltu ratkaistavan seuraavalla koulutuskierroksella? Viittaus 1. palautteen vastineeseen: "Työryhmä ei näe suosituksen jakamista erillisiksi suosituksiksi tarpeellisena. Kokonaisuuden ymmärtäminen vaikeutuisi ko. toimenpiteen myötä merkittävästi." Pienempiä selkeitä kokonaisuuksia on helpompi ymmärtää kuin sekavaa ja laajaa, osin keinotekoisesti ja löyhästi yhteen liitettyä kokonaisuutta. Esimerkiksi tietoarkkitehtuuri on niin laaja ja tärkeä kokonaisarkkitehtuurin osa-alue, ettei sen typistäminen ja liittäminen osaksi laajempaa kokonaisuutta ole tarkoituksenmukaista. järjestynyt koulutusohjeman KA:n opiskelua varten. Koulutuksesta on saatu käyttäjiltä pääosin hyvää palautetta. Perehtyminen edellyttää toki lisäksi käytännön harjoittelua, sitä varten on ITluokkakoulutusta ja tulee ilmainen KA-mallinnuspalvelu organisaatioiden käyttöön. Koulutusohjelma päivitetään tukemaan uutta JHS 179-suositusta. Suosituksen käyttöönottosuunnitelmassa huomioidaan koulutuksen uudistustarve. JHS 179 on jaettu mahdollisimman selkeisiin kappaleisiin ja tarkemman tason ohjeistukset ovat liitteinä. Tietoarkkitehtuurin tulee olla osa kokonaisuutta, koska se liittyy kiinteästi muihin näkökulmiin, erityisesti toimintaarkkitehtuuriin. Lisäksi Yhteentoimivuusmenetelmästä tulee erillistä, täydentävää ohjeistusta. Muutosta erillisiin suosituksiin ei tehdä. Johdon ja toiminnan kehittäjien tarkemmat työskentelytavat KA-työssä eivät sisälly tarkemmin suositukseen, mutta tässä suosituksessa on pyritty parantamaan ymmärrystä kokonaisarkkitehtuurin hyödyntämisestä johtamisen ja toiminnan kehittämisen apuvälineenä. KA-tulee huomioida muiden menetelmien soveltamisessa, kuten esimerkiksi riskien hallinnassa, tietoturvallisuuden hallinnassa jne. Johdantoa tarkennetaan (tarvelähtöinen kuvaaminen tarkoituksenmukaisella laajuudella ja tarkkuustasolla). 4.3 STM esitti suuren joukon muutosehdotuksia ensimmäisellä palautekierroksella. Lähtökohtaisesti toivomme, että nuo palautteet huomioitaisiin vielä tällä kierroksella ja suositukseen tehtäisiin sen mukaisesti riittävän suuria muutoksia. Mikäli suurempia muutoksia ei olla enää valmiita tekemään, niin ehdotamme, että tämä suositus nykyistä selkeämmin todetaan arkkitehtien materiaaliksi ja erikseen käynnistetään JHS työ mallin tekemiseksi siitä, että miten kokonaisarkkitehtuurityötä tehdään yhteistyössä toiminnan kehittäjien ja johdon kanssa. Tässä muodossa suositus on aivan liian raskas ja vaikea hyödynnettäväksi tietohallinnon, toiminnan kehittämisen ja johdon välisessä vuoropuhelussa. Johdantoa muokataan. Luvussa 2 Soveltamisala painotus on jo olemassa toivotulla tavalla (suunnattu erityisesti arkkitehdeille ja arkkitehtuurityöstä vastaaville tahoille). JHS 179:ssä on paljon ohjeistusta ja työvälineitä johdon ja toiminnankehittäjien arkkitehtuurityötä varten. Strategiakartta tehdäänkin usein johdon ja muun henkilökunnan yhteistyönä ja asetetaan strategiset tavoitteet ja tavoitteet, jotka ovat lähtökohtana organisaation toimeenpanosuunnitelmalle. Lisäksi liiketoimintamallien ja kyvykkyyksien suunnittelu voidaan tehdä johdon ja toiminnankehittäjien yhteistyönä. Kyvykkyyksien kehittämispaketit kannattaa tehdä toiminnan kehittäjien, taloussuunnittelijoiden ja

3 kokonaisarkkitehtien yhteistyönä. Yhteistyötapoja ei ole tarkemmin kuvattu, koska organisaatiot ovat hyvin erilaisia toimintatapojensa, tehtäviensä ja kokonsa puolesta. Suositusta tukee VM:n järjestämä KAkoulutus ja verkossa julkaistavat koulutusmateriaalit. 5. Muutosehdotukset kappaleeseen 1. Johdanto Vastaajien määrä: Palaute suositusluonnoksesta JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen, 2. vaihe Hylätty. Viite: Palautepyyntö: JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen, 2. vaihe -suositusluonnos Kiitos palautteesta. Julkisen hallinnon neuvottelukunta (JUHTA) on pyytänyt Valtion tietoja viestintätekniikkakeskus Valtorilta palautetta toisella palautekierroksella olevasta suositusluonnoksesta JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen. Valtori pitää tarpeellisena kehittää edelleen ja ottaa käyttöön julkisessa hallinnossa yhteinen kokonaisarkkitehtuurimenetelmä, jonka myötä tietotekniikka tulee näkyväksi osaksi toiminnan suunnittelua ja johtamista sekä luo yhteisen kielen ja lisää yhteistä ymmärrystä eri tasoilla tapahtuvassa kehittämistyössä. Tämä on perusedellytys digitalisaation edistämiselle sekä julkishallinnon organisaatioiden toiminta- ja tuottavuustavoitteiden saavuttamisessa tietotekniikkaa tehokkaasti hyödyntämällä. Valtorin näkemyksen mukaan suositusluonnos on kattava ja antaa hyvän kuvan julkishallinnon organisaatioille suositeltavista kokonaisarkkitehtuurin kuvauskohteista. Arkkitehtuurimenetelmä suunnitteluprossin osalta on selkeä, joskin kokonaisuudessaan suosituksen luettavuutta voisi parantaa. Tarkemmat huomiot on esitetty alla suositusluonnoksen pääotsikoinnin mukaisella jaottelulla. 1 MUUTOSEHDOTUKSET SUOSITUSLUONNOKSEEN 1.1 Kappale 1. Johdanto Suositusluonnoksessa tuodaan esille, että kokonaisarkkitehtuurityö on osa organisaation strategiatyötä, johtamisprosessia ja talouden ja toimin-nan suunnittelua. Menetelmän käyttöä voisi tukea kuvaamalla mm. pro-sessikuvauksina arkkitehtuurityön liittyminen em. prosesseihin sekä suosituksessa kuvattuihin muihin toiminnan kehittämisen keskeisiin aihealueisiin (kehittäminen, riskienhallinta, laadunhallinta ja toiminnan ja palveluiden hallinta). Suositusluonnos ei edelleenkään huomioi laatutyötä tai riskienhallintaa muutoin kuin toteamuksen tasolla. Nämä olennaiset organisaation toiminnan ja organisaation tuottamien palvelujen kehittymiseen vaikuttavat elementit tulee tuoda voimakkaammin esille. Organisaation erilaisuuden vuoksi geneeristenkin prosessikuvien tuottaminen ei ole mahdollista tämän hankkeen puitteissa. Kuva 5 esittää prosessinomaisesti periaatteen liitynnöistä johtamiseen ja toiminnan suunnitteluun. Organisaatio tulee soveltaa ja tarkentaa kuvassa esitettyä mallia omaan toimintaansa. Kokonaisarkkitehtuurimenetelmä tulee huomioida vastavuoroisesti muiden menetelmien soveltamisessa, kuten

4 Johdannossa tuodaan esille, että arkkitehtuurimenetelmää voidaan käyttää lähinnä vain soveltaen yksittäisten tietojärjestelmä- ja ratkaisuarkkitehtuurien kuvaamiseen. Arkkitehtuurimenetelmän keskeisin soveltamisalue organisaatioissa on kuitenkin ratkaisuarkkitehtuuritaso, jolla käytännön arkkitehtuurityö nimenomaan toteutetaan. Suositusta tulisikin tarkentaa ja kohdentaa enemmän mainitulle ratkaisuarkkitehtuuritasolle. esimerkiksi riskienhallinnassa ja laatutyössä. Tarkempi em. osuuksien käsittely ei kuulu suositushankkeen scopeen (laajuus) eikä sitä sen vuoksi voida tällä erää laajentaa. Suosituksen tarkoituksena on tuottaa kokonaisarkkitehtuurimenetelmä eli menetelmä kokonaisarkkitehtuurin kuvaamiseen. Sitä voidaan hyödyntää eri tasoilla, toki soveltaen suunniteltavan /kehitettävän kohteen suhteen. 5.2 Kuva 1 - parempi olisi viitata JHKA hallintamalliin (v ) ja ottaa alkuperäinen kuva sieltä. Suosituksen kuvassa 1 esitetyssä kuvassa on on painotettu toiminnan osaalueiden liittymistä kokonaisarkkitehtuuriin. JHKA Hallintamallin kuvassa on puolestaan esitetty menetelmien suhdetta. Korjataan kuvateksti kuvaan 1: Kuva 1. Kokonaisarkkitehtuuri osana toiminnan kehittämistä. Kuvaa ei vaihdeta. 6. Muutosehdotukset kappaleeseen 1.1 Uudistuksen tausta ja sisältö 7. Muutosehdotukset kappaleeseen 1.2 Suosituksen sisältö ja rakenne Vastaajien määrä: Selkeämmin nostetaan esiin se, että suositus on tarkoitettu arkkitehdeille. Toiminnan kehittäjille ja johdolle on saatavassa erillinen Tarkennetaan johdantoa. materiaali osoitteeesta xx. Kohderyhmät lukevat jo luvussa 2 Soveltamisala toivotulla painotuksella. Viittaus KA-koulutuksiin ja niiden materiaaleihin löytyy myös luvusta Muutosehdotukset kappaleeseen 2. Soveltamisala Vastaajien määrä: Selkeämmin nostetaan esiin se, että suositus on tarkoitettu arkkitehdeille. Toiminnan kehittäjille ja johdolle on saatavassa erillinen Tarkennetaan johdantoa. materiaali osoitteeesta xx. Kohderyhmät lukevat jo luvussa 2 Soveltamisala toivotulla painotuksella.

5 Viittaus KA-koulutuksiin ja niiden materiaaleihin löytyy myös luvusta Muutosehdotukset kappaleeseen 3. Viittaukset Vastaajien määrä: Viitauksiin voisi lisätä ArchiMate-, UML- ja BPMNkuvausnotaatiot/kielet TOGAFin rinnalle, kun niihin dokumentissa kuitenkin viitataan eri yhteyksissä. Vastaavasti dokumentaatiossa viitataan SAVI-viitearkkitehtuuriin, joka voisi olla viitattuna myös tässä yhteydessä. Hyväksytty. Lisätään ArchiMate-, UML- ja BPMNkuvausnotaatiot/kielet. Lisätään listaan viitearkkitehtuurit, joihin viitataan suosituksessa. 10. Muutosehdotukset kappaleeseen 4. Termit ja määritelmät Vastaajien määrä: Sanasto sisältää monia kohtia, jotka eivät kuulu kokonaisarkkitehtuurimenetelmän keskeisimpiin seikkoihin. Mukana on teknistä sanastoa, joka ei kuulu kokonaisarkkitehtuurimenetelmän sanastoon. Suosituksen käsitteet olisi hyvä laatia terminologisen sanastotyön menetelmien mukaisesti. Termit on koottu JHS-suositusten laadinnan periaatteiden mukaisesti. Terminologi viimeistelee termien määritelmät. Osa teknisistä termeistä poistetaan suosituksesta. KA sisältää uutta käsitteistöä ja terminologiaa, joka ei ole vielä vakiintunutta. Terminologisen sanastotyön menetelmät ovat hyödyksi, mutta eivät ratkaise kaikkia kysymyksiä Palautteessa luvattiin, että terminologi tarkastaa termistön ("Termistö käydään läpi yhdessä terminologin kanssa (pohjalla yhteinen JHSsanasto)."), onko näin tehty? Sillä voi olla laajempiakin vaikutuksia kuin pelkkä viimeinen stilisointi. CI (en Continuous integration) määritelmä on väärin. Pitää olla ohjelmisto-osien jatkuva integraatio. Jatkuvalla integraatiolla (continuous integration) tarkoitetaan prosessia, jossa koko ohjelmisto koostetaan ja integroidaan jatkuvasti, ei vasta kehittämisen loppuvaiheessa. Terminologi on tarkistanut termistön kerran ja tekee sen vielä toisen palautekierroksen jälkeen. Tarkistustyön pohjana on ollut yhteinen JHS-termistö. Korjataan seuraavasti: CI: jatkuva ohjelmiston koostaminen, kääntäminen ja testaus Integraatioarkkitehtuuri: määritelmän sanamuoto on huono, sillä se Usein ketterään ohjelmistokehitykseen liittyvä toimintatapa, jossa eri kehittäjien tuottama ohjelmistokoodi kootaan, käännetään, verifioidaan ja testataan pitkälle automatisoidusti useaan kertaan saman päivän aikana.

6 väittää, että vuorovaikutuksen suunnittelua tehdään tietoja siirtämällä. Parempi muotoilu: arkkitehtuurinäkökulma, jossa suunnitellaan ja kuvataan organisaatioiden ja tietojärjestelmien vuorovaikutusta. Eli jätetään määritelmätekstin loppu pois. Korjataan seuraavasti: integraatioarkkitehtuuri: kokonaisarkkitehtuurin näkökulma, jossa suunnitellaan ja kuvataan organisaatioiden ja tietojärjestelmien vuorovaikutusta Integraatioarkkitehtuuri kuvaa myös periaatteet, joilla sovelluksen liittymät muihin järjestelmiin ja sovelluksiin toteutetaan ADSL: Tarvitaanko suosituksessa oikeasti esimerkiksi ADSL menetelmän määritelmää? Hybridipilvi: Määritelmän mukaan mm. IaaS on virtualisointimallin käyttämä tietoverkko. Tulisi olla esimerkiksi pilvipalvelun tyyppi tms. OpenShift: Onko asianmukaista sisällyttää yhden kaupallisen toimittajan (Red Hat) PaaS alusta sanastoon? Tietojohtaminen: Määritelmä eri sanamuodossa kuin muut. Suosituksessa käytetyt termit on listattu termilistaan JHS-periaatteen mukaisesti. Korjataan seuraavasti: hybridipilvi pilvipalvelun toteutusmalli, jossa käytetään vähintään kahta eri pilvipalvelun toteutusmallia IaaS-, PaaS- ja SaaS - pilvipalveluluokkien toteutusmalli voi olla julkinen pilvi (public cloud), yksityinen pilvi (private cloud), luotettu pilvi (trusted cloud) tai hybridipilvi (hybrid cloud). Poistetaan sanastosta Open Shift. Poistetaan myös Docker. Muutetaan seuraavasti: tietojohtaminen organisaatiossa olevan tiedon ja osaamisen hyödyntäminen organisaation tavoitteiden saavuttamiseksi ja lisäarvon tuottamiseksi Tietojohtamisella varmistetaan, että organisaatiossa sisällä tai sen saavutettavissa on olemassa tulevaisuudessa tarvittava tieto ja osaaminen Termien määritelmät eivät ole parantuneet ensimmäisen kierroksen mukaisista ja ovat edelleen itseään toistavia eivätkä juurikaan kuvaa/avaa kyseisen termin sisältöä tai tarkoitusta. Suositusluonnoksen termiluettelossa on edelleen turhia termejä, joilla ei ole arkkitehtuurimenetelmän tai sen ymmärtämisen kannalta merkitystä Tehdään tarkistuksia saatujen palautteiden perusteella, mutta teknisten termien mukaan ottamiseen kanta tapahtuu JHS-suositusten periaatteiden mukaisesti.

7 (esim. termit ADSL, AMS, CMDB, Docker, Ethernet, Help desk, CI, EDI, IaaS, PaaS, ipaas, MOLS, SaM, XaaS, jne.). Ne heikentävät oleellisesti suosituksen luettavuutta ja ne tulee poistaa suosituksesta. Termiluettelossa on edelleen myös termejä, jotka eivät esiinny koko suositusluonnoksessa tai sen liitteissä kertaakaan; vain siis termiluettelossa. Ne tulee poistaa. Termiluettelo tulisi tarkentaa koskemaan vain menetelmän kannalta oleelliset termit sekä kuvata termien sisältö tarkemmin. Myös suomenja englanninkieliset käännökset tulee karsia turhana pois. Myös liitteissä olevat termiluettelot tulee karsia ja yksinkertaistaa JHS179:n ensimmäisellä palautekierroksella kommentoimme suosituksen epäselvää käsitteistöä ja suosituksen alussa olevia käsitteiden määritelmiä, joissa ei ole noudatettu systemaattisen sanastotyön standardoituja periaatteita. Epäselviä käsitteitä ja termien ristiriitaisuuksia kommentoitiin paljon myös muiden organisaatioiden palautteissa. Työryhmän vastineessa todetaan, että käsitteistö ja termit käydään suosituksen viimeistelyvaiheessa läpi yhdessä terminologin kanssa ja tehdään tarvittavat korjaukset ja harmonisoinnit. Mielestämme samat käsitemäärittelyn epäselvyydet ja epäjohdonmukaisuudet ovat kuitenkin mukana myös päivitetyssä suosituksessa. Riittävää terminologista osaamista ei ole ilmeisesti ollut käytettävissä kommentoijien esille nostamien epäselvyyksien ja ristiriitaisuuksien korjaamiseksi. Ohessa joitakin yksittäisiä esimerkkejä siitä, mitä käsitteiden sisältöön ja määrittelylogiikkaan liittyviä ongelmia suosituksen kappaleeseen 4 edelleen sisältyy. Poistetaan ne termit, jotka eivät sisälly suositusluonnokseen tai sen liitteisiin. Poistetaan termit OpenShift ja Docker. Mahdolliset kieliversiot termeistä ovat mukana selkeyttämistarkoituksessa. Kieliversioiden ilmaisu JHStermilistalla on perusteltua ja kuuluukin tehdä valikoiduissa tapauksissa. Toisen kierroksen palautteiden perusteella tehdään vielä terminologinen tarkastus arkkitehtuurimenetelmä: Tarkoittaako samaa kuin kokonaisarkkitehtuurimenetelmä? Kokonaisarkkitehtuurimenetelmä on sanastossa mukana omana terminään ja siitä on vain ks.-viittaus käsitteeseen arkkitehtuurimenetelmä mutta ei päinvastoin. Jos arkkitehtuurimenetelmä tarkoittaa samaa kuin kokonaisarkkitehtuurimenetelmä (ovat siis synonyymisia termejä), niin miksei arkkitehtuurimenetelmän määritelmässä viitata käsitteeseen kokonaisarkkitehtuuri, mikä olisi loogista? Sen sijaan määritelmässä käytetään ilmausta arkkitehtuurikokonaisuus. Mitä tämä tarkoittaa? Arkkitehtuurikokonaisuutta ei ole määritelty sanastossa. kokonaisarkkitehtuuri: Määritelmässä sanotaan, että on kyse toiminnan, prosessien ja palvelujen, tietojen muodostaman kokonaisuuden rakenteesta, jolla hallinnoidaan ja kehitetään organisaation toimintaa ja sen rakenteita. Pitääkö tämä tulkita niin, että kokonaisarkkitehtuuri on tietynlainen organisaation toimintaan liittyvä kokonaisrakenne, jolla hallinnoidaan ja kehitetään organisaation toimintaa ja rakennetta. Kuulostaa saman asian toistamiselta kahteen kertaan, ja tämä ei avaa itse käsitteen sisältöä millään tavalla. Edelleen jää siis epäselväksi, mitä käsite kokonaisarkkitehtuuri oikeastaan tarkoittaa. Määritelmää täydentävässä huomautuksessa puolestaan sanotaan, että kokonaisarkkitehtuuri on tietynlaisten asioiden mallintamista, kuvaamista ja suunnittelemista yhtenäisen mallin mukaisesti. Myöhemmin huomautuksessa sanotaan, että kokonaisarkkitehtuuri on malli jossa tietotekninen varustus kuvataan ja huomioidaan osana liiketoimintaa tai muuta toimintaa. Näin monen, keskenään erilaisen määritelmän antaminen yhdelle ja samalla käsitteelle on systemaattisen sanastotyön periaatteiden vastaista ja johtaa vain entistä suurempiin epäselvyyksiin siitä, mistä tässä koko suosituksen kannalta keskeisessä käsitteessä on kyse. Muutetaan: arkkitehtuurimenetelmä ks. kokonaisarkkitehtuurimenetelmä. Korjataan seuraavasti: kokonaisarkkitehtuurimenetelmä menetelmä, jonka avulla kehitetään suunnitelmallisesti ja systemaattisesti kohteena olevaa kokonaisuutta tai sen rajattua osaa Tässä suosituksessa kuvatun kokonaisarkkitehtuurin suunnittelun yhteydessä havaittujen kehittämisalueiden ja -kohteiden tarkempi suunnittelu toteutetaan JHS 171 -suosituksen mukaisesti edeten. Muutetaan seuraavasti: kokonaisarkkitehtuuri 1) organisaation tai muun kohteena olevan kokonaisuuden rakenne 2) organisaation tai muun kohteena olevan kokonaisuuden rakenteen kuvaus, jota käytetään toiminnan kehittämisessä Kokonaisarkkitehtuurin avulla on mahdollista hallinnoida ja kehittää organisaatioiden tai muiden valittujen kohteiden toimintaa systemaattisesti.

8 arkkitehtuurin viitekehys: Määritelmässä sanotaan, että on kyse mallista, jonka mukaan organisaation tai muun kehittämiskohteen rakenteita jäsennetään, hallitaan ja kehitetään. Määritelmä on sisällöltään lähes sama kuin kokonaisarkkitehtuuri-käsitteen määritelmä (tai ainakin sen huomautuksessa esitetyt määrittelyt). Miten nämä kaksi käsitettä eroavat siis toisistaan ja mikä niiden välinen suhde on? Tämä ei käy ilmi määritelmistä, vaan käsitteet jäävät epäselviksi. arkkitehtuurin metamalli: Määritelmässä sanotaan, että on kyse tietynlaisesta arkkitehtuurin sisällöllisestä viitekehyksestä. Onko arkkitehtuurin metamallilla siis joku suhde käsitteeseen arkkitehtuurin viitekehys? Määritelmän mukaan tuntuisi olevan, mutta tätä ei kuitenkaan ilmaista selkeästi. Näiden kahden käsitteen suhde jää epäselväksi, koska käsiteanalyysia ei ole tehty loogisesti eikä määritelmiä ole kirjoitettu systemaattisesti. Määritelmässä sanotaan myös, että on kyse viitekehyksestä, jonka tehtävänä on jäsentää ja ohjata suunnittelua toiminnan kannalta olennaisiin näkökulmiin ja rakenteiseen. Mistä näkökulmista tässä on kyse? Onko kyse arkkitehtuurinäkökulmista (tämä käsite on määritelty erikseen sanastossa)? Onko arkkitehtuurin metamallilla siis jonkinlainen suhde käsitteeseen arkkitehtuurinäkökulma? Määritelmän mukaan tuntuisi olevan, mutta tätä ei kuitenkaan ilmaista selkeästi. Näiden kahden käsitteen suhde jää epäselväksi, koska käsiteanalyysia ei ole tehty loogisesti eikä määritelmiä ole kirjoitettu systemaattisesti. sidosarkkitehtuuri: Määritelmässä sanotaan, että on kyse muualla määritettävästä arkkitehtuurilinjauksesta, jolla on tai voi olla vaikutusta arkkitehtuurityöhön tai -linjauksiin. Mihin eri arkkitehtuurilinjauksiin määritelmässä viitataan (>> arkkitehtuurilinjaus mainittu määritelmässä kahteen kertaan)? Entä onko arkkitehtuurilinjaus sama asia kuin arkkitehtuuriperiaate (tämä käsite on määritelty erikseen sanastossa)? Näiden käsitteiden väliset suhteet jäävät epäselviksi, koska käsiteanalyysia ei ole tehty loogisesti eikä määritelmiä ole kirjoitettu systemaattisesti. koodisto: Määritelmän mukaan koodisto on luettelo luokan ominaisuuden sallituista arvoista. Tämä määritelmä voisi yhtä hyvin päteä myös käsitteisiin arvojoukko tai arvoalue. Onko koodisto siis sama asia kuin arvojoukko tai arvoalue vai onko näillä käsitteillä jotain eroa? Tämä ei ilmene määritelmästä millään tavalla, ja käsitteet jäävät epäselviksi. rajapinta, fyysinen rajapinta, looginen rajapinta Käsite rajapinta on määritelty sanastossa näin: yksittäisen järjestelmän yhdelle tai useammalle osapuolelle tarjoama tietokokonaisuus integraation mahdollistamiseksi. Onko oikein sanoa, että rajapinta on eräänlainen tietokokonaisuus, kuten määritelmä väittää? (vrt. JHS173 ja JHS180: rajapinta = tietyn standardin mukainen käytäntö tai yhtymäkohta, joka mahdollistaa tietojen siirron laitteiden, ohjelmien tai käyttäjien välillä)? Entä miksi käsitteitä fyysinen rajapinta ja looginen rajapinta ei ole määritelty rajapinnan alakäsitteiksi, vaikka loogisesti näin olisi? Sen sijaan on sanottu, että fyysinen rajapinta kuvaa rajapinnan teknisen toteutuksen (määritelmä ei noudata systemaattisen määritelmänkirjoituksen periaatteita) ja looginen rajapinta kuvaa yhteyksiä eli integraatioita (määritelmä ei noudata systemaattisen määritelmänkirjoituksen periaatteita). tietojohtaminen: Määritelmän mukaan tietojohtaminen tarkoittaa sitä, että organisaatiossa olevaa ja sen saavutettavissa olevaa osaamista ja tietoa hyödynnetään organisaation tavoitteiden saavuttamiseksi ja lisäarvon tuottamiseksi. Eikö kaikki organisaatiossa toteutettava johtaminen ole tällaista? Määritelmä on aivan liian laaja, koska se voisi Arkkitehtuurin viitekehys-termiä ei muuteta. ks. muutokset kokonaisarkkitehtuuri-termiin. Muutetaan termi seuraavasti: arkkitehtuurin metamalli arkkitehtuurin sisällöllinen viitekehys, jonka tehtävänä on jäsentää ja ohjata suunnittelua toiminnan kannalta olennaisiin näkökulmiin ja rakenteisiin Muutetaan termi seuraavasti: sidosarkkitehtuuri muualla määritettävä arkkitehtuuri, jolla on vaikutus organisaation tai muun tarkasteltavan kohteen arkkitehtuurityöhön Koodisto -käsitteeseen liittyy kovasti erilaisia näkemyksiä, mutta esim. kansainväliset määritelmät ovat hyvin samankaltaisia, kuin tässä suosituksessa esitetty määritelmä. Ei muutoksia. Muutetaan seuraavasti: rajapinta tietyn standardin mukainen tai muuten sovittu käytäntö tai yhtymäkohta, joka mahdollistaa tietojen siirron laitteiden, ohjelmien tai käyttäjien välillä

9 päteä ihan mihin tahansa johtamiseen tai johtamisen osa-alueeseen eikä se tällaisenaan yksilöi niitä olennaisia piirteitä, jotka erottaisivat nimenomaan tietojohtamisen muusta organisaatiojohtamisesta. käsitemalli: Määritelmän mukaan käsitemallissa on kyse tietynlaisesta tietomallista ( tietomalli, joka määrittelee tarkastelun kohteena olevat kohdemaailman käsitteet ja niiden väliset suhteet ). Määritelmä on epäonnistunut eikä pidä paikkaansa. Käsitemalli ei ole eräänlainen tietomalli, vaan käsitemallin pohjalta voidaan laatia tietomalli. Käsitteellisen tason malleja ei pidä sekoittaa loogisen tason tietomalleihin. käsitteistö Määritelmä ei pidä paikkaansa, koska se sekoittaa keskenään käsitteistöt ja sanastot. Käsitteistöt ovat valikoimia tarkastelun kohteeksi otettuja käsitteitä. Se esitetäänkö käsitteistöt sanastoissa vai ei, on epäolennaista. Sanastot sen sijaan sisältävät aina tietyn valikoidun käsitteistön ja esittävät tähän kokonaisuuteen sisältyvien yksittäisten käsitteiden tietoja (yleensä käsitteiden nimitykset eli termit, määritelmät, määritelmiä täydentävät lisätiedot ja mahdollisesti muuta käsitekohtaista tietoa). sanasto: Määritelmään on sekoitettu eri sanastotyyppien käsitepiirteitä tavalla, joka ei pidä paikkaansa yleiskäsitteen sanasto kanssa (siis kaikkien mahdollisten sanastojen ominaisuuksien kanssa). Kaikista sanastoista ei voida sanoa, että ne ovat luettelo jossain kielessä tai ympäristössä sallituista sanoista tai termeistä, koska tämä pätee vain kontrolloituihin sanastoihin tai esim. asiasanastoihin. On myös väärin puhua termien määritelmistä, koska määritelmät laaditaan aina käsitteille, ei termeille. Termit puolestaan ovat käsitteestä käytettyjä nimityksiä. Sanastojen olennainen piirre on se, että ne ovat aineistoja, jotka sisältävät käsitekohtaista tietoa tietystä valikoidusta käsitteistöstä. Vrt. myös käsitteistöä koskeva kommentti edellä. Havainto on osuva, mutta tietojohtaminen ei välttämättä ole eriytettävissä organisaatiojohtamisesta muussa, kuin siinä että johtamisessa otetaan erityisesti huomioon organisaation tieto ja osaaminen (vrt. talousjohtaminen, henkilöstöjohtaminen). Tietojohtaminen-termiä muokataan: tietojohtaminen organisaatiossa olevan tiedon ja osaamisen hyödyntäminen organisaation tavoitteiden saavuttamiseksi ja lisäarvon tuottamiseksi Tietojohtamisella varmistetaan, että organisaatiossa sisällä tai sen saavutettavissa on olemassa tulevaisuudessa tarvittava tieto ja osaaminen. Muutetaan seuraavasti: käsitemalli käsitteitä ja niiden välisiä suhteita kuvaava malli. Muutetaan seuraavasti: käsitteistö valittu joukko käsitteitä Sanasto on hyvin monimuotoinen käsite. Määritelmä ei sisällä kaikkien mahdollisten sanastojen ominaisuuksia, mutta pätee pitkälti laajasti ymmärrettynä tämän suosituksen yhteydessä tarkoitettuihin sanastotyyppeihin asiasanalistasta ontologiaan. Palautteessa ehdotettu vaihtoehtoinen määritelmä: aineisto, joka sisältää käsitekohtaista tietoa tietystä valikoidusta käsitteistöstä ei ole aukoton sekään. Huomautuksessa on otettu huomioon sanastojen monimuotoisuus. Korjataan seuraavasti: sanasto valikoima jossain kielessä tai ympäristössä sallittuja sanoja tai termejä

10 Ontologiat eivät ole sanastotyyppi samalla tavalla kuin esim. asiasanastot tai terminologiset sanastot. Ontologiat ovat tietyn teknisen rakenteen ja muodon mukaisesti laadittuja, koneymmärteisiä kuvauksia käsitteistä ja niiden välisistä suhteista (vrt. ontologia-käsitteen määritelmä suosituksessa). Mikä tahansa sanasto tai vaikkapa luokitus, joka sisältää tietoa käsitteistä ja niiden välisistä suhteista, voidaan ontologisoida Viittaus 1. palautteen vastineeseen: "Termit ja määritelmät kuuluvat suosituksen rakenteeseen ko. kohtaan. Luvussa esitetään myös liitteiden olennaiset termit ylläpidon vuoksi." Joukossa on termejä, kuten jo käytöstä lähes kokonaan poistunut teknologia ADSL, jotka eivät kuulu tämän päivän kokonaisarkkitehtuurimenetelmän termistöön. Liitteiden termien listaaminen päädokumentissa ei ole suositusrakenteessa pakotettu, eikä se helpota termien ylläpitoa kokonaisuudessaan (selitykset eivät ole tällä hetkelläkään 1:1, esim. soveltamisprofiili ja tietokomponentti). Sanastot voivat sisältää luokitteluja, määritelmiä, kuvauksia ja esimerkkejä. Sanastoja voidaan laatia monin eri tavoin ja eri käyttötarkoituksiin. Sanastotyyppejä ovat muun muassa terminologiset sanastot, asiasanastot, ontologiat sekä tietojärjestelmien ja sovellusten integrointia tukevat sanastot. Tietoteknisessä ympäristössä sanastoilla kuvataan käsitteiden merkityksiä siten, että eri tietojärjestelmät voivat ymmärtää käsittelemäänsä tietoa. Pitää paikkansa ontologioista. Ei muutoksia. Noudatetaan JHS suositusten toimitusteknisiä periaatteita. Joitain teknisiä termejä poistetaan suosituksesta Rekisteri: Rekisterin määritelmä "tiettyä käyttötarkoitusta varten koottu ja järjestetty, tiettyjä yksiköitä ja niiden ominaisuuksia koskevia tietoja sisältävä looginen tietovaranto" on hyvä määritelmä ja käyttökelpoinen myös valmisteilla olevan JHS Rekisteritiedon metatiedot -suosituksen näkökulmasta. Ollakseen ymmärrettävä määritelmä vaatii kuitenkin, että myös "looginen tietovaranto" määritellään. On hyvä, että rekisterin määritelmän yhteydessä viitataan myös JHS Rekisteritiedon metatiedot -suositukseen. Suosituksen valmistumisaika olisi hyvä korjata vuodeksi Tietovaranto: Tietovarannon määritelmä on sinänsä hyvä ja ymmärrettävä. Määritelmän viimeiseen lauseeseen tarvitaan kuitenkin pieni kielellinen korjaus, koska on epäselvää mihin ne viittaa; parempi muoto olisi käyttää saman tietovarannon tietoja, jotka voivat olla peräisin Loogisen tietovarannon määrittely ilmenee suosituksen tekstistä. Ei muutoksia. Korjataan valmistumisaika. Korjataan seuraavasti: tietovaranto looginen tietoaineistojen kokoelma Tietovaranto-käsitteen lisäksi tai sen alakäsitteeksi on kuitenkin määriteltävä myös looginen tietovaranto, jota käytetään rekisterin määritelmässä ja joka on keskeinen käsite myös KA-taulukoissa. Ko. taulukon listauksissa näkyy myös käsite fyysinen tietovaranto, joten on tarpeen antaa selkeät kriteerit sille, mikä on looginen tietovaranto (niin että fyysisiä tietovarantoja ei sekoiteta loogisiin). Tietovarannon määritelmän perusosassa esiintyvä termi looginen ( looginen Toiminnan ja hallinnon tarpeista johdettu ja määritelty tietoaineistojen kokoelma. Se voi koostua tai olla osa yhden tai useamman järjestelmän tuottamista tai tietokannan sisältämistä tiedoista. Usea järjestelmä voi käyttää saman tietovarannon tietoja, jotka voivat olla peräisin yhdestä tai useammasta lähteestä eli tietokannasta tai muista tietorakenteista. Loogisen ja fyysisen tietovarannon eroja on selitetty suositustekstissä. Muokataan seuraavasti:

11 tietoaineistojen kokoelma ) saattaa myös viedä ajatukset suoraan loogisiin tietovarantoihin, mikä ei liene tarkoitus. Tuossa oleva looginen lienee sovellettavissa niin loogisiin kuin fyysisiinkin tietovarantoihin. looginen tietovaranto toiminnassa tai palveluissa tarvittavien ja yhteisesti hallittujen tietojen tai tietoaineistojen joukko Looginen tietovaranto sisältää usein useiden tietojärjestelmien tietokantoja tai rekistereitä. Vastaavasti sama looginen tietovaranto voi sisältää useiden eri tahojen hallinnoimia tietoja, vaikka tiedot sijaitsisivatkin samassa fyysisessä tietokannassa Kohdassa kuvataan looginen tietovaranto siten, että se sisältää usein useiden tietojärjestelmien tietokantoja tai rekistereitä. Tässä yhteydessä looginen tietovaranto ei vastaa käytännössä missään olosuhteissa rekisterin käsitettä vaan on tietojärjestelmäarkkitehtuuriin liittyvä käsite. Mikropalvelu (microservice / microservices) termiä ei määritellä, mutta käytetään luvussa 7.5.1, 8 ("Monoliittisten sovellusten sijaan palvelut hankitaan yhä useammin pienempinä osina"); Oma määritelmä tai mukaan "sovellusarkkitehtuuri" -termin SOA kohtaan Rekisteri on looginen tietovaranto, mutta kaikki loogiset tietovarannot eivät ole rekistereitä. Ei toimenpiteitä. Mikropalvelu-termiä ei käytetä suosituksessa. 11. Muutosehdotukset kappaleeseen 5. Toiminnan kokonaisvaltainen kehittäminen Vastaajien määrä: Yleisesti ottaen voisi harkita kuvausten tuottamista jollain yleisellä Hylätty. standardilla/notaatiolla. Esim. kuva 3 ei ole täysin yksiselitteinen, voisi Kuva on ylätason kaavio, joka ei edellytä miettiä toimisiko ArchiMate notaatio tässä? yksittäisen notaation käyttämistä. Kuvaa 3 korjattiin 1.palautekierroksen palautteiden perusteella tähän suuntaan Suositusluonnoksen toiseen version on pyritty tarkentamaan ja selventämään esille tuotuja uusia toiminnan johtamiseen ja jäsentämisen käsitteitä (liiketoimintamalli ja kyvykkyys). Selvennykset ovat pääosin onnistuneita ja tervetulleita, joskin niiden sisäistäminen vaatii organisaatiossa aikaa. Käsitteet tulisi ottaa käyttöön eri julkishallinnon tasoilla hallinnonalakohtaisesti ministeriölähtöisesti tulosohjauksen prosesseihin ja sitä kautta vakiinnuttaa käytännön toimintaan. Pelkästään arkkitehtuurimenetelmään liitettynä nämä käsitteet eivät tule juurtumaan organisaatioiden johtamisen käsitteistöön. Toiminnan kokonaisvaltainen kehittäminen on kuvattu suositusluonnoksessa edelleen sekavasti. Suosituksessa viitataan eri kohdissa ICT-palvelujen kehittämisen suosituksiin (JHS 171 ICTpalvelujen kehittäminen: Kehittämiskohteiden tunnistaminen sekä JHS 172 ICT-palvelujen kehittäminen: Esiselvitys), mutta suosituksessa ei tule edelleenkään selkeästi esille, miten nämä suositukset suhteutuvat tähän luonnokseen ja etenkin luonnoksen uusiin osa-alueisiin, kuten kyvykkyyksien kehittäminen ja niiden jalostuminen työkokonaisuuksiksi (kehittämispaketti) ja edelleen konkreettisiksi työpaketeiksi. Suosituksessa tulisi tuoda esille yhtenä kuvana (esim. kuvaan 3), miten kokonaisarkkitehtuurimenetelmä suhteutuu JHS171 Kiitos palautteesta. Kyllä, mutta jalkautus ei ole hankkeen ja työryhmän vallassa. JHSkäyttöönottosuunnitelmassa voidaan esittää jatkotoimenpide-ehdotuksissa tarve käsitteiden jalkauttamiselle. JHS 179:ssä on hyödynnetty VM:n tulosohjauksen ajattelutapaa, jolloin kehittämisen lähtökohtana on strategia, josta tavoitteet johdetaan. Ei ole ristiriitaa JHS 179- ja JHS suositusten välillä, jos ajattelee, että kehittämiskohteiden tunnistaminen on strategisten tavoitteiden mukaisten kehittämiskohteiden tunnistamista.

12 ja JHS172 -suosituksiin. Tavoiteltavana tulisi olla näiden suositusten sulauttaminen yhdeksi eheäksi kokonaisuudeksi. Lisätään liitteeseen 2 maininta JHS 171- hyödyntämisestä. Muutospyynnöt olemassa olevista suosituksista voi esittää JHSprojektipäällikölle JHS-prosessin mukaisesti Viittaus 1. palautteen vastineeseen: "Suositus JHS 152 tullaan päivittämään mm. tämän hankkeen tuottamien muutostarpeiden perusteella." Osa suosituksessa nyt esitetyistä prosessikaavioista (esim. kuvat 5 ja 10) eivät tällä hetkellä noudata mitään prosessien kuvaamisessa yleisesti käytettyä notaatiota ja/tai standardia, joten JHS 152:n muokkaaminen tämän suosituksen kaavioiden mukaiseksi saattaa muodostua haasteelliseksi. Selvitettävänä oleva JHS suosituksen päivityshanke määrittelee käytettävät notaatiosuositukset ja notaatiot, joita kuvauksissa käyttävät. Kuvat 5 ja 10 ovat tarkoituksella ylätason esityksiä asioiden kulusta ja eri vaiheiden suhteista (notaatiovapaa kuvaustapa). Kuvan 5 kuvatekstiä muokataan seuraavasti: Kuva 5. Kokonaisarkkitehtuurimenetelmä osana organisaation kokonaiskehittämistä. 12. Muutosehdotukset kappaleeseen 5.1 Toiminnan kehittämisen rakenteellinen kokonaisuus 13. Muutosehdotukset kappaleeseen Organisaation tavoitteet ja toimintamallit Vastaajien määrä: Toisessa kappaleessa muutama kirjoitusvirhe: Hyväksytty. "..sekä niihin liittyvät." -> mitkä? Korjataan virheet kappaleessa. sekä "Tietoturvallisuus tulee huomioida osana tavoitteiden asettamista ja niihin liittyvät muutostarpeet. varmistaa myös tietosuojan, varautumisen kehittäminen ja ylläpito." Korjataan lause tietoturvallisuudesta. 14. Muutosehdotukset kappaleeseen Rakenteiden suunnittelu 15. Muutosehdotukset kappaleeseen Toimeenpanon ja toteutuksen mallit 16. Muutosehdotukset kappaleeseen 6. Kokonaisarkkitehtuurimenetelmä Vastaajien määrä: 1

13 16.1 Kappaleessa tuodaan esille, että kokonaisarkkitehtuurisuunnittelu lähtee kehitettävän kokonaisuuden tunnistamisesta ja rajaamisesta, sekä siihen liittyvien kehittämisvaatimusten ja reunaehtojen tunnistamisesta. Tällä tarkoitettaneen tässä kohtaa eri asiaa kuin JHS 171 kehittämiskohteiden tunnistamista. Suositusluonnoksessa tuodaan esille arkkitehtuurikuvausten viitekehyksen rinnalle uutena rakenteena arkkitehtuurisisällön viitekehys. Uudistuksen tarkoituksena on saada huomio kiinnittymään enemmän kuvaussisältöjen valintaan. Saman olisi voinut toteuttaa olemassa olevaan kuvausviitekehykseen, sillä todellisuudessa uudistus ei tuo lisäinfoa menetelmään, mutta tuo uuden rakenteellisen kerroksen tai vaiheen menetelmän käytölle. Ymmärrystä ei myöskään helpota se, että kuvausviitekehys tuodaan esille vain esimerkinomaisena esityksenä sisältörakenteiden esittämiseen. Hylätty. JHS 179:ssä on hyödynnetty VM:n tulosohjauksen ajattelutapaa, jolloin kehittämisen lähtökohtana on strategia, josta tavoitteet johdetaan. Ei ole ristiriitaa JHS 179- ja JHS suositusten välillä, jos ajattelee, että kehittämiskohteiden tunnistaminen on strategisten tavoitteiden mukaisten kehittämiskohteiden tunnistamista. Sisältöviitekehys (metamalli, kuva 7) on kuvattu arkkitehtuurisisällön näkökulmasta. Se on otettu mukaan jo arkkitehtuurityötä tehneiden organisaatioiden hyödynnettäväksi. Se perustuu TOGAFiin, jota suositellaan hyödynnettäväksi arkkitehtuurityössä, jossa kypsyystaso on jo korkeammalla. Mikäli sisältöviitekehystä halutaan korostaa erillisenä metatason viitekehyksenä, tulisiko sitä esimerkinomaisesti ilmentävän kuvausviitekehyksen olla myös sisäiseltä rakenteeltaan (kuva8) sisältöviitekehyksen sisäisen rakenteen (kuva 7) mukaisesti rakentunut. Nyt esim. kuvausviitekehyksen käsitteellinen, looginen, ja fyysinen taso eivät ole yhteneviä sisältöviitekehyksen rakenteen kanssa. Myöskään kuvausviitekehykseen valitut kuvauskohteet eivät ole loogisesti kohdennettavissa em. tarkastelutasoille. Esim. Teknologiavalinnat on sijoitettu käsitteelliselle tasolle teknologiaarkkitehtuurinäkökulmaan, mutta paremminkin kyseinen kuvaus ilmentää fyysisen tason tietoa. Kappaleessa 6.3 on kuvattu KA:n suunnitteluprosessi ja sen kaksi erilaa-juista sisältökokonaisuutta (peruskuvakuset ja laajennetut kuvaukset). Näistä tulee suositusluonnoksen mukaan kuitenkin kuvata vähintään peruskuvaukset. Tämä tuntuu olevan ristiriidassa kappaleessa 6.1 kerrottuun, jossa organisaatio itse määrittelee sisältöviitekehyksen ja sen mukaiset kuvaukset; näihin itse määriteltyihin ei välttämättä kuulu peruskuvausten sisältö. Viitekehysten - etenkin kuvausviitekehyksen - sisältöihin ja tulisi kiinnittää tarkemmin huomioita myös sen suhteen, että niistä ollaan toisaalla (JHS 198) säätämässä tietohallintolain nojalla asetusta organisaatioilta vaadittavista kuvauksista. Kuvausten viitekehys (kuva 8) perustuu sisältöviitekehykseen, josta se on johdettu tarkemmaksi jäsentämisen apuvälineeksi ja hyödynnettäväksi erityisesti organisaatioissa, jotka aloittavat KA-työtään. Kuvaa 8 ei muokata uudelleen. Teknologiavalinnat voidaan esittää eri tarkkuustasoilla tarpeen mukaisesti. Suositus painottaa, että valinnat tulee tietää ja kuvata vähintään käsitteellisen tason tiedoin. Suosituksessa suositellaan peruskuvauksien tuottamista yhteentoimivuuden vähimmäistason saavuttamiseksi julkisessa hallinnossa. Se ei siis velvoita. Tekeillä oleva asetus tulee vasta velvoittamaan tietyt kuvaukset ja kuvausten sisällöt pakollisiksi. Peruskuvauksiin valitut kuvaukset on valittu siten, että niistä on yleensä erityistä hyötyä kehittämisen kohteen tarkentamisessa ja sen tavoitetilan määrittämisessä. JHS 198 -sisältö on valittu tämän suosituksen peruskuvausten pohjalta eri työryhmässä. Luvussa 6.3 sekoittuu suunnitteluprosessi kuvattavaksi valittuihin sisältöihin. Suositusluonnoksen peruskuvaukset ja laajennetut kuvaukset voisi kuvata erillisen kappaleessa/luvussa; esim. luvussa 7 (Kokonaisarkkitehtuurin kuvaukset) ja tässä kohtaa vain itse suunnitteluprosessi. se selkiinnyttäisi dokumentin luettavuutta oleellisesti. Kuvaustaulukot ja niitä käsittelevät kohdat ovat olennaisia suunnitteluprosessin vaiheita, jonka vuoksi ne katsotaan tärkeiksi esittää nykyisessä kontekstissaan. Peruskuvaukset on lisäksi esitetty liitteessä 3 Arkkitehtuurin nykytilan ja tavoitetilan kuvaus.

14 Sinällään suunnitteluprosessi etenee kuvauksessa loogisesti ja on sovellettavissa eri organisaatioiden tarpeeseen. Kiitos palautteesta. 17. Muutosehdotukset kappaleeseen 6.1 Arkkitehtuurisisällön viitekehys 18. Muutosehdotukset kappaleeseen 6.2 Arkkitehtuurikuvausten viitekehys Vastaajien määrä: Kyvykkyyskartta <=> Kyvykkyydet; Kyvykkyyskartta riittää kehyksessä, Kyvykkyydet on vain taulukko (luvussa 7.1)? Hylätty. Työryhmä katsoo, että molemmat kuuluvat kehykseen. Kyvykkyyskartta on visuaalinen kuvaus kyvykkyyksistä ja niiden suhteista, Kyvykkyydettaulukkoon kirjataan tarkempia tietoja kyvykkyyksiin liittyen (tarkentaa kartalla olevien kyvykkyyksien tietoja). 19. Muutosehdotukset kappaleeseen Arkkitehtuurikuvausten viitekehyksen hyödyntäminen arkkitehtuurisuunnittelussa Vastaajien määrä: Ensimmäisen kappaleen lopussa viitataan kuvaan 10. Tarkoitettaneen Hyväksytty. kuvaa 11. Korjataan virhe, viittaus on kuvaan Muutosehdotukset kappaleeseen Arkkitehtuurisuunnittelun tasot ja arkkitehtuurihierarkia Vastaajien määrä: Kuvassa 9 pieni kirjoitusvirhe: "JHKA-kohde-alueiden kokonaisarkkitehtuuri". Lukua ja kuvaa 9 muokataan. 21. Muutosehdotukset kappaleeseen 6.3 Kokonaisarkkitehtuurin suunnitteluprosessi 22. Muutosehdotukset kappaleeseen Kokonaisarkkitehtuurin suunnittelun valmistelu

15 23. Muutosehdotukset kappaleeseen Tunnista ja kokoa ohjaava tieto 24. Muutosehdotukset kappaleeseen Organisoi arkkitehtuurin suunnitteleminen 25. Muutosehdotukset kappaleeseen Kokonaisarkkitehtuurin suunnittelun valmisteluvaiheen lopputulokset 26. Muutosehdotukset kappaleeseen Arkkitehtuurivision määrittely 27. Muutosehdotukset kappaleeseen Määrittele suunnittelun tavoitteet 28. Muutosehdotukset kappaleeseen Tarkenna toimijat, heidän roolinsa ja tehtävänsä 29. Muutosehdotukset kappaleeseen Määritä ja rajaa kehittämistarpeen mukaiset kokonaisarkkitehtuurin kehittämisalueet 30. Muutosehdotukset kappaleeseen Määrittele arkkitehtuurin toteuttamismalli 31. Muutosehdotukset kappaleeseen Arkkitehtuurivision määrittelyvaiheen lopputulokset 32. Muutosehdotukset kappaleeseen Kokonaisarkkitehtuurin nykytilan analysointi 33. Muutosehdotukset kappaleeseen Kokoa nykytilan arkkitehtuurikuvaukset ja analysoi nykytila

16 34. Muutosehdotukset kappaleeseen Arkkitehtuurin nykytilan kuvaaminen perus- ja laajennetuin kuvauksin Vastaajien määrä: Kaikkiin kuvauksiin tulisi lisätä esimerkki kuvauksen hyödyntämisestä. Tämä auttaisi ymmärtämään kuvausten merkitystä erityisesti mahdollisesti asetuksella velvoitettujen peruskuvausten osalta. Hylätty. Ei ole mahdollista tuottaa toivotun laisia esimerkkejä tämän hankkeen puitteissa. VM:n tarjoamassa koulutuksessa ja koulutusmateriaaleissa annetaan lisäesimerkkejä kuvausten hyödyntämisestä. 35. Muutosehdotukset kappaleeseen Nykytilan analysointivaiheen lopputulokset 36. Muutosehdotukset kappaleeseen Kokonaisarkkitehtuurin tavoitetilan suunnittelu 37. Muutosehdotukset kappaleeseen Analysoi ja huomioi tavoitetilan arkkitehtuuriin vaikuttavat tekijät 38. Muutosehdotukset kappaleeseen Arkkitehtuurin tavoitetilan kuvaus perus- tai laajennetuin kuvauksin Vastaajien määrä: Kaikkiin kuvauksiin tulisi lisätä esimerkki kuvauksen hyödyntämisestä. Tämä auttaisi ymmärtämään kuvausten merkitystä erityisesti mahdollisesti asetuksella velvoitettujen peruskuvausten osalta. Hylätty. Ei ole mahdollista tuottaa toivotun laisia esimerkkejä tämän hankkeen puitteissa. VM:n tarjoamassa koulutuksessa ja koulutusmateriaaleissa annetaan lisäesimerkkejä kuvausten hyödyntämisestä. 39. Muutosehdotukset kappaleeseen Tee puuteanalyysi 40. Muutosehdotukset kappaleeseen Päivitä arkkitehtuurivision tavoitetilaa tarvittaessa

17 41. Muutosehdotukset kappaleeseen Arkkitehtuurin tavoitetilan suunnitteluvaiheen lopputulokset 42. Muutosehdotukset kappaleeseen Toimeenpanon suunnittelu 43. Muutosehdotukset kappaleeseen 6.4 Kokonaisarkkitehtuurin hallintamalli 44. Muutosehdotukset kappaleeseen 7. Kokonaisarkkitehtuurin kuvaukset Vastaajien määrä: Ei toimenpiteitä. Suositusluonnoksen esittämät kuvattavat sisällöt ovat keskeisiä arkkitehtuurikuvauksia, joilla saadaan koostettua yhtenäinen näkemys organisaation toiminnasta ylätasolla. Menetelmän käytön ja soveltamisen kannalta kuvauskehikon jakaminen eri kuvaustasoihin (käsitteellinen, looginen ja fyysinen) ei tuo lisäarvoa kuvauksiin. Kuvauskehikossa olevat kuvattavat sisällöt eivät ole luokiteltavissa nykyisiin kuvaustasoihin esitetyllä tavalla. Kuvaustasot eivät päde aukottomasti myöskään siirryttäessä arkkitehtuurihierarkiassa tasolta toiselle (esim. kokonaisarkkitehtuuri ja ratkaisuarkkitehtuuri), joka oli yksi menetelmän käyttötarkoitus. Yksinkertaisempaa olisi käsitellä kuvauksia (vain) kuvattavina sisältöinä, joihin ei liity turhaa luokittelua. Kuvaamista ja kuvausten käyttöä hankaloittaa helposti myös se, että toisen organisaation käsitteellisen tason kuvaus (esim. palvelu) ovat toisen organisaation fyysisen tason kuvaus. Osin periaatetasolla olevat kuvaukset ovat erillisiä dokumentteja, joihin arkkitehtuurityössä viitataan (esim. arvot, visio), sillä niiden viestinnällisellä esitystavallakin on merkitystä. Strategiakartan, liiketoimintamallin ja kyvykkyyksien kuvaaminen tulee organisaation johdon sitoutumisen kautta ja vaatii myös uudenlaista ajattelumallia organisaatioihin. Tätä tulee ohjata esim. tulosohjauksen kautta. Suositusluonnoksessa suositeltujen kuvausnotaatioiden käyttäminen vaatii osaamista. Perustason kuvausten tullessa asetuksella voimaan, tulee kuvaamisen aloittamisen tueksi järjestää myös koulutusta. Kiitos palautteesta. Näkökulmia ja kuvaustasoja (käsitteelliset tasot) käytetään jäsentämisen apuvälineinä eikä niiden tarkoitus olekaan olla aukottomia tai betoniin valettuja. Tässä esitettyjen näkökulmien ja käsitteellisten tasojen pohjalla on TOGAF. Tässä suosituksessa esitettyjen näkökulmien ja käsitteellisten tasojen käyttäminen vuoropuhelussa eri julkisen hallinnon organisaatioiden välillä varmasti helpottaa asioiden käsittelyä, ymmärtämistä ja tavoitetilan suunnittelua. VM tarjoaa KA-koulutusta jo tällä hetkellä, kuten myös tulevaisuudessa. 45. Muutosehdotukset kappaleeseen 7.1 Periaatteellisen tason kuvaus 46. Muutosehdotukset kappaleeseen 7.2 Toiminta-arkkitehtuurin kuvaus

18 47. Muutosehdotukset kappaleeseen Toiminta-arkkitehtuurin kuvaus käsitteellisellä tasolla 48. Muutosehdotukset kappaleeseen Toiminta-arkkitehtuurin kuvaus loogisella tasolla 49. Muutosehdotukset kappaleeseen Toiminta-arkkitehtuurin kuvaus fyysisellä tasolla 50. Muutosehdotukset kappaleeseen 7.3 Tietoarkkitehtuurin kuvaus 51. Muutosehdotukset kappaleeseen Tietoarkkitehtuurin kuvaus käsitteellisellä tasolla Vastaajien määrä: Kuvauksessa päätietoryhmissä ei ole otettu huomioon tiedon käyttötarkoitussidonnaisuutta. Tekstiä : Jos esimerkiksi kuvauksista nähdään, että asiakastiedot ovat jo olemassa, niitä ei tarvitse luoda aina uudelleen joka järjestelmään." tulee täydentää seuraavasti : Jos esimerkiksi kuvauksista nähdään, että asiakastiedot ovat jo olemassa, niitä ei tarvitse luoda aina uudelleen joka järjestelmään, mutta asiakastiedon käytön hallinnassa on tällöin on voitava tunnistaa kaikki erilaiset asiakastiedon käyttötarkoitukset. Hyväksytty. Muokataan esitetyllä tavalla: Jos esimerkiksi kuvauksista nähdään, että asiakastiedot ovat jo olemassa, niitä ei tarvitse luoda aina uudelleen joka järjestelmään, mutta asiakastiedon käytön hallinnassa tällöin on voitava tunnistaa kaikki erilaiset asiakastiedon käyttötarkoitukset. 52. Muutosehdotukset kappaleeseen Tietoarkkitehtuurin kuvaus loogisella tasolla 53. Muutosehdotukset kappaleeseen Tietoarkkitehtuurin kuvaus fyysisellä tasolla 54. Muutosehdotukset kappaleeseen 7.4 Tietojärjestelmäarkkitehtuurin kuvaus 55. Muutosehdotukset kappaleeseen Tietojärjestelmäarkkitehtuurin kuvaus käsitteellisellä tasolla

19 56. Muutosehdotukset kappaleeseen Tietojärjestelmäarkkitehtuurin kuvaus loogisella tasolla 57. Muutosehdotukset kappaleeseen Tietojärjestelmäarkkitehtuurin kuvaus fyysisellä tasolla 58. Muutosehdotukset kappaleeseen 7.5 Teknologia-arkkitehtuurin kuvaus 59. Muutosehdotukset kappaleeseen Teknologia-arkkitehtuurin kuvaus käsitteellisellä tasolla 60. Muutosehdotukset kappaleeseen Teknologia-arkkitehtuurin kuvaus loogisella tasolla 61. Muutosehdotukset kappaleeseen Teknologia-arkkitehtuurin kuvaus fyysisellä tasolla 62. Muutosehdotukset kappaleeseen 7.6 Toimeenpanon kuvaus 63. Muutosehdotukset kappaleeseen 7.7 Arkkitehtuurikuvausten hallinta 64. Muutosehdotukset kappaleeseen Kuvausten nimeäminen ja versiointi 65. Muutosehdotukset kappaleeseen Kuvauksissa käytettävät notaatiot 66. Muutosehdotukset kappaleeseen Kuvausten hyödyntäminen 67. Muutosehdotukset kappaleeseen Yhteenkokoava dokumentti 68. Muutosehdotukset kappaleeseen 8. Integraatioarkkitehtuuri

20 69. Muutosehdotukset kappaleeseen 9. Tietoturvallisuus 70. Muutosehdotukset kappaleeseen 10. Opastavat tiedot 71. Muutosehdotukset kappaleeseen 11. Liitteet Vastaajien määrä: Palaute (vastaus kysymykseen 3.34) on "Esimerkit ovat esimerkkejä kuvauksista ja ne eivät jokaisessa tapauksessa ole yksityiskohtaisesti notaatioiden mukaisia." ja silti väitetään, että kommenttimme on huomioitu, vaikka se on lähinnä päätetty olla huomioimatta. Esimerkkejä ei liene muutettu lainkaan. Jos ei työryhmässä saada aikaiseksi helposti kokonaista hyvää esimerkkiä, joka on notaation mukainen, tarkoittaa se, että suositus on vaikea soveltaa. Esimerkit on korjattava. Muualla suosituksessa ei ole juurikaan kuvitusta tai esimerkkejä enää. Viitataan lähinnä exceliin tai visualisointeihin. Siihen nähden olisi entistäkin tärkeämpää tuottaa kunnolliset esimerkit. Liitteessä 6 oleva biopankkitoimintaan liittyvä esimerkki loogisista tietovarannoista jättää epäselväksi sen, ajatellaanko kuvion kuvaavan yhtä loogista tietovarantoa vai ovatko kuviossa näkyvät rekisterit ym. aineistot kukin erikseen looginen tietovaranto. Kuvion sisällä olevat tekstit ovat kussakin lokerossa monikkomuodossa ("tietovarannot"), mikä johtaa ajattelemaan, että kukin aineisto on oma tietovaranto (esim. "Näyte- ja tietorekisteri", "Biopankin perustiedot"), mutta ne kuuluvat tiettyyn kokonaisuuteen ("Biopankin biopankkitoiminnan tietovarantoja"). Mikä tuo kokonaisuus KA-terminologialla on, se jää epäselväksi. Esimerkit ovat käytännön työstä ja monia niistä ei voida muokata toivotulla tavalla resurssi- ja aikataulusyistä. Osaa kuvista muokattiin jo 1. palautekierroksen perusteella. Esimerkkien saaminen oli erittäin haasteellista johtuen siitä, että organisaatiot eivät halua jakaa tekemiään kuvauksia syystä tai toisesta. Tämän vuoksi esimerkit ovat parhaita mahdollisia saatuja. Niistä saa kuitenkin hyvän kuvan mistä on käytännön soveltamisessa kyse. Liitteeseen 7 lisätään muutamia uusia esimerkkikuvia/korvataan edellisessä versioita olleita kuvia. Ei toimenpiteitä. KA-visualisointien Loogiset tietovarannot-esimerkkikuvassa esitetään biopankin omat ja siihen olennaisesti liittyvät tietovarannot. Rekisterit ovat aina loogisia tietovarantoja, mutta kaikki tietovarannot eivät ole rekistereitä. 72. Haluatko kommentoida liitettä 1. Strategian kuvaaminen strategiakartan avulla? Vastaajien määrä: 10

21 73. Muutosehdotukset liitteen 1 kappaleeseen 1. Strategiakartta johdon työvälineenä 74. Muutosehdotukset liitteen 1 kappaleeseen 2. Strategia- ja toimenpidekarttojen muodostaminen 75. Muutosehdotukset liitteen 1 kappaleeseen 3. Yhdessä tekemällä 76. Muutosehdotukset liitteen 1 kappaleeseen 4. Karttojen eri tasot ja suhteet 77. Muutosehdotukset liitteen 1 kappaleeseen 5. Esimerkki strategiakartasta ja toimenpidekartoista 78. Muutosehdotukset liitteen 1 kappaleeseen 6. Strategian seuranta ja arviointi 79. Haluatko kommentoida liitettä 2. Liiketoimintamallit ja kyvykkyydet KA-suunnittelussa? Vastaajien määrä: Muutosehdotukset liitteen 2 kappaleeseen 1. Johdanto 81. Muutosehdotukset liitteen 2 kappaleeseen 2. Liiketoimintamalli 82. Muutosehdotukset liitteen 2 kappaleeseen 2.1 Liiketoimintamallin kuvaus

22 83. Muutosehdotukset liitteen 2 kappaleeseen 3. Kyvykkyydet 84. Muutosehdotukset liitteen 2 kappaleeseen 3.1 Kyvykkyyksien tunnistaminen 85. Muutosehdotukset liitteen 2 kappaleeseen 3.2 Kyvykkyyksien suunnittelu 86. Muutosehdotukset liitteen 2 kappaleeseen 3.3 Kyvykkyyksien johtaminen ja kehittäminen 87. Muutosehdotukset liitteen 2 kappaleeseen 4. Kehittämispaketit 88. Muutosehdotukset liitteen 2 kappaleeseen 4.1 Kehittämispaketin kuvaus 89. Haluatko kommentoida liitettä 3. Arkkitehtuurin nykytilan ja tavoitetilan kuvaaminen? Vastaajien määrä: Muutosehdotukset liitteen 3 kappaleeseen 1. Johdanto 91. Muutosehdotukset liitteen 3 kappaleeseen 2. Arkkitehtuurin nykytilan analysointi ja kuvaaminen 92. Muutosehdotukset liitteen 3 kappaleeseen 2.1 Organisaation arkkitehtuurin nykytilan kuvaaminen 93. Muutosehdotukset liitteen 3 kappaleeseen 2.2 Rajatun kehittämiskohteen arkkitehtuurin

23 nykytilan kuvaaminen 94. Muutosehdotukset liitteen 3 kappaleeseen 2.3 Nykytilan peruskuvaukset 95. Muutosehdotukset liitteen 3 kappaleeseen 3. Arkkitehtuurin tavoitetilan suunnittelu Vastaajien määrä: Liite 3 kpl 3:Kuva 3 - kuvaan olisi hyvä laittaa myös nuolet vasemmalta oikealle kuvaamaan toimintalähtöistä kehittämistä. Hyväksytty. Lisätään nuolet. 96. Muutosehdotukset liitteen 3 kappaleeseen 3.1 Organisaation arkkitehtuurin tavoitetilan suunnittelu 97. Muutosehdotukset liitteen 3 kappaleeseen 3.2 Rajatun kehittämiskohteen arkkitehtuurin tavoitetilan suunnittelu 98. Muutosehdotukset liitteen 3 kappaleeseen 3.3 Tavoitetilan peruskuvaukset 99. Haluatko kommentoida liitettä 4. Puuteanalyysimatriisi (Excel-tiedosto)? Vastaajien määrä: Muutosehdotukset liitteeseen 4. Puuteanalyysimatriisi (Excel-tiedosto) 101. Haluatko kommentoida liitettä 5. KA-taulukot (Excel-tiedosto)? Vastaajien määrä: 10

24 102. Muutosehdotukset liitteeseen 5. KA-taulukot (Excel-tiedosto) 103. Haluatko kommentoida liitettä 6. KA-kuvausten visualisointi (Powerpoint-tiedosto)? Vastaajien määrä: Muutosehdotukset liitteeseen 6. KA-kuvausten visualisointi (Powerpoint-tiedosto) Vastaajien määrä: Esimerkin on oltava kokonainen. Siinä käytetty tarkkuustaso on perusteltava, jotta se avautuu lukijalle ja sen on oltava tismalleen notaatioiden mukainen, sillä lukijat kaipaavat esimerkkiä, josta voi oikeasti ottaa mallia. Nyt muualla suosituksessa ei kuvia juuri ole. Erityisesti prosessikartta on huono (elementit eivät ole prosesseja, prosessien nimeäminen epäonnistunut myös) Esimerkit ovat käytännön työstä ja monia niistä ei voida muokata toivotulla tavalla resurssi- ja aikataulusyistä. Osaa kuvista muokattiin jo 1. palautekierroksen perusteella. Esimerkkien saaminen oli erittäin haasteellista johtuen siitä, että organisaatiot eivät halua jakaa tekemiään kuvauksia syystä tai toisesta. Tämän vuoksi esimerkit ovat parhaita mahdollisia saatuja. Niistä saa kuitenkin hyvän kuvan mistä on käytännön soveltamisessa kyse. Prosessikartta -esimerkki on ko. organisaation itse tuottama ja on käytetty heille ominaisia nimeämistapoja. Liitteeseen 7 lisätään muutamia uusia esimerkkikuvia/korvataan edellisessä versioita olleita kuvia Liitteen visualisoitujen kuvausten tulisi muodostaa yksi kokonaisuus, jossa kaikissa erillisissä kuvauksissa olisi kuvattu samaa kohdetta. Esimerkkikaavioiden sisältöihin tulisi kiinnittää erityistä huomiota, jotta ne ohjaisivat oikeaan suuntaan mm. kuvattavien kohteiden nimeämisessä ja jäsentämisessä. Ei toimenpiteitä. Esimerkit ovat käytännön työstä ja monia niistä ei voida muokata toivotulla tavalla resurssi- ja aikataulusyistä. Osaa kuvista muokattiin 1. palautekierroksen perusteella

25 Resurssi- ja aikataulullisista syistä ei ollut mahdollista tehdä yhden kokonaisuuden kuvauksia, vaan esimerkit on pyydetty käytännön tilanteista eri organisaatioilta. Esimerkkien saaminen oli erittäin haasteellista johtuen siitä, että organisaatiot eivät halua jakaa tekemiään kuvauksia syystä tai toisesta. Tämän vuoksi esimerkit ovat parhaita mahdollisia saatuja. Niistä saa kuitenkin hyvän kuvan mistä on käytännön soveltamisessa kyse Liite 6 dia 10-11:Korvaa/lisää uusi esimerkki maistraatin strategiasta (käytetään valmennuksissa). Ks. Liite 'Esimerkit JHS179' Liite 6 dia 14:Korvaa/lisää uusi esimerkki maistraatin liiketoimintamallista (käytetään valmennuksissa). Ks. Liite 'Esimerkit JHS179' dia 10-11: Korvataan uudella kuvalla esitetyn mukaisesti. Strategian kuvaus. dia 14: Ei muuteta. Liite 6 dia 17: Korvaa uusi esimerkki maistraatin kyvykkyyskartasta (käytetään valmennuksissa). Ks. Liite 'Esimerkit JHS179' dia 17: Lisätään esitetty kuva toiseksi esimerkkikuvauksi. Ei poisteta vanhaa esimerkkikuvaa. Liite 6 dia 24-25: Korvaa uusi esimerkki maistraatin toimijoiden vuorovaikutuksesta (käytetään valmennuksissa). Ks. Liite 'Esimerkit JHS179' Liite 6 dia 33-34: Korvaa uusi esimerkki maistraatin prosessien vuorovaikutuksesta (käytetään valmennuksissa). Ks. Liite 'Esimerkit JHS179' Liite 6 dia 45: Poista, ei käytetä enää valmennuksissa dia 24-25: Ei muuteta. dia 33-34: Ei muuteta. dia 45: Ei poisteta. Liite 6 dia 76: Lisää uusi esimerkki maistraatin käsitemallista (käytetään valmennuksissa). Ks. Liite 'Esimerkit JHS179' dia 76: Esitetty käsitemalli on jo tietomalli eli sitä ei tähän laiteta esimerkiksi. Ei muuteta. Liite 6 dia 37: Korvaa uusi esimerkki maistraatin järjestelmien vuorovaikutuksesta (käytetään valmennuksissa). Ks. Liite 'Esimerkit JHS179' Liite 6 dia 87: Lisää uusi esimerkki maistraatin kehittämisen tiekartasta (käytetään valmennuksissa). Ks. Liite 'Esimerkit JHS179' dia 37: Muutetaan kalvolle 77. dia 87: Lisätään esimerkiksi Haluatko kommentoida liitettä 7. Semanttisen yhteentoimivuuden menetelmäohje? Vastaajien määrä: 10

26 106. Muutosehdotukset liitteen 7 kappaleeseen 1. Johdanto Vastaajien määrä: Liite 7 Semanttisen yhteentoimivuuden mentelmäohje Kommentoimme ensimmäisellä palautekierroksella liitettä seuraavasti: Kokonaisuutena liite ei riitä kuvaamaan Yhteentoimivuusmenetelmää, soveltamistapa ei käy ilmi riittävästi. Yhteentoimivuusmenetelmä on tavoitetilana hyvä, mutta onnistuminen valtakunnan tasolla edellyttää riittävää henkilöstöä, osaamista ja resursointia. Asema on selkiytettävä suhteessa muuhun julkishallinnon toimintaan, ja suunniteltava käytännön toteutus, hallintamalli ja päätöksenteko sekä käyttöönoton organisointi huolellisesti. Selkiytettävä julkishallinnon yhteisten määrittelyjen suhde toimialakohtaisiin. Ennen kuin yhteentoimivuusmenetelmää suositellaan JHStasolla laajempaan käyttöön, tulisi olla näyttöä sen soveltamisesta useammissa suppeammissa soveltamiskohteissa. Työryhmän palautteessa vastataan kommenttiin näin: Liitteen 8 tekstiä tarkennetaan soveltuvin osin. Tarkemmasta yhteentoimivuusmenetelmän määrittelystä ja hallintamallista vastaa Yhteinen tiedon palvelumalli -kärkihanke, tässä suosituksessa menetelmä ja sen soveltamisen periaatteet esitellään lyhyesti. Olemme edelleen sitä mieltä, että menetelmän käyttöönotto, varsinkin jos siitä tulee asetuksen myötä pakollinen kaikille julkishallinnon toimijoille, vaatisi ensin pilottihankkeiden kautta selvitystä siitä, minkälaisiin henkilö-, osaamis- ja muihin resursseihin organisaatioissa tulee varautua, jotta voidaan toimia liitteessä kuvatun semanttisen yhteentoimivuuden menetelmän mukaisesti. Tällaista arvokasta tietoa saataisiin juuri esim. YTI-kärkihankkeesta, jonka tulokset olisi hyvä saada ensin käyttöön. Marssijärjestys pilotointien ja menetelmän laajemman soveltamisvaatimuksen välillä tuntuu nyt olevan väärä. Ei toimenpiteitä. Liite 7 Semanttisen yhteentoimivuuden menetelmäohje on osa JHS-179 Kokonaisarkkitehtuurin kehittäminen - suositusta ja annetut kommentit kohdistuvat liitteeseen tässä roolissa. JHS-179-suosituksen pohjalta laadittava tekninen eritelmä ja/tai asetus on erillinen asiakirjansa. JHS-179- suosituksen osana liitteessä kuvattua menetelmää suositetaan sovellettavan julkisen hallinnon yhteisen ja yhteentoimivan tietoarkkitehtuurin muodostamiseksi ja turvaamiseksi. Pienimmillään semanttisen yhteentoimivuuden toteuttaminen vaatii yhteisten sanastojen hyödyntämistä määritysten merkityssisällön kuvaamisessa. Tämän minimin toteuttamisen ei nähdä vielä vaativan merkittävää resursointia organisaatioissa verrattuna nykyiseen tilanteeseen. Semanttisen yhteentoimivuuden menetelmän kuvaaminen osana JHS-179-suositusta mahdollistaa tietoisuuden ja osaamisen levittämisen muun muassa suositukseen liittyvien koulutusten kautta Muutosehdotukset liitteen 7 kappaleeseen 1.1 Taustaa 108. Muutosehdotukset liitteen 7 kappaleeseen 1.2 Termit ja määritelmät 109. Muutosehdotukset liitteen 7 kappaleeseen 2. Tavoitetila

27 110. Muutosehdotukset liitteen 7 kappaleeseen 3. Menetelmän viitekehys 111. Muutosehdotukset liitteen 7 kappaleeseen 4. Yhteentoimivuusmenetelmä 112. Muutosehdotukset liitteen 7 kappaleeseen 4.1 Tietokomponentit 113. Muutosehdotukset liitteen 7 kappaleeseen 4.2 Sanastot 114. Muutosehdotukset liitteen 7 kappaleeseen 4.3 Koodistot 115. Muutosehdotukset liitteen 7 kappaleeseen 4.4 Soveltamisprofiilit 116. Muutosehdotukset liitteen 7 kappaleeseen 5. Yhteentoimivuusmenetelmän soveltaminen 117. Muutosehdotukset liitteen 7 kappaleeseen 5.1 Työohje 118. Haluatko kommentoida liitettä 8. Integraation ja rajapintojen kuvaus? Vastaajien määrä: Muutosehdotukset liitteen 8 kappaleeseen 1. Johdanto 120. Muutosehdotukset liitteen 8 kappaleeseen 2. Integraatiokokonaisuuden analyysi