Palautekooste: JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen muutosehdotusten hyväksyminen 1. Organisaatio 0 - 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 14.11.2016 2. Yhteyshenkilön tiedot 0 3. Suositusluonnoksen hyväksyminen työryhmän tekemillä muutoksilla 0 4. Vastustusperusteet Vastaajien määrä: 3 - Tämä palaute on täydennys THL:n 10.11.2016 lähettämään palautteeseen. Vastustusperusteet on esitetty aiemmassa palautteessa. - 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 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. - 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. 5. Muutosehdotukset kappaleeseen 1. Johdanto Vastaajien määrä: 2 - Palaute suositusluonnoksesta JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen, 2. vaihe Viite: Palautepyyntö: JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen, 2. vaihe -suositusluonnos Julkisen hallinnon neuvottelukunta (JUHTA) on pyytänyt Valtion tieto- ja 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ä tieto-tekniikka tulee näkyväksi osaksi toiminnan suunnittelua ja johtamista se-kä luo yhteisen kielen ja lisää yhteistä ymmärrystä eri tasoilla tapahtu-vassa kehittämistyössä. Tämä on perusedellytys digitalisaation edistämi-selle sekä julkishallinnon organisaatioiden toiminta- ja tuottavuustavoit-teiden saavuttamisessa tietotekniikkaa tehokkaasti hyödyntämällä. Valtorin näkemyksen mukaan suositusluonnos on kattava ja antaa hy-vän kuvan julkishallinnon organisaatioille suositeltavista kokonaisarkki-tehtuurin 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. prosessikuvauksina arkkitehtuurityön liittyminen em. prosesseihin sekä suo-situksessa kuvattuihin muihin toiminnan kehittämisen keskeisiin aihealu-eisiin (kehittäminen, riskienhallinta, laadunhallinta ja toiminnan ja palve-luiden hallinta). Suositusluonnos ei edelleenkään huomioi laatutyötä tai riskienhallintaa muutoin kuin toteamuksen tasolla. Nämä olennaiset organisaation toi-minnan ja organisaation tuottamien palvelujen kehittymiseen vaikuttavat elementit tulee tuoda voimakkaammin esille. Johdannossa tuodaan esille, että arkkitehtuurimenetelmää voidaan käyt-tää lähinnä vain soveltaen yksittäisten tietojärjestelmä- ja ratkaisuarkki-tehtuurien kuvaamiseen. Arkkitehtuurimenetelmän keskeisin sovelta-misalue organisaatioissa on kuitenkin ratkaisuarkkitehtuuritaso, jolla käy-tännön arkkitehtuurityö nimenomaan toteutetaan. Suositusta tulisikin tarkentaa ja kohdentaa enemmän mainitulle ratkaisu-arkkitehtuuritasolle. - Kuva 1 - parempi olisi viitata JHKA hallintamalliin (v1.1 24.4.2014) ja ottaa alkuperäinen kuva sieltä.
6. Muutosehdotukset kappaleeseen 1.1 Uudistuksen tausta ja sisältö 7. Muutosehdotukset kappaleeseen 1.2 Suosituksen sisältö ja rakenne - Selkeämmin nostetaan esiin se, että suositus on tarkoitettu arkkitehdeille. Toiminnan kehittäjille ja johdolle on saatavassa erillinen materiaali osoitteeesta xx 8. Muutosehdotukset kappaleeseen 2. Soveltamisala - Selkeämmin nostetaan esiin se, että suositus on tarkoitettu arkkitehdeille. Toiminnan kehittäjille ja johdolle on saatavassa erillinen materiaali osoitteeesta xx 9. Muutosehdotukset kappaleeseen 3. Viittaukset - Viitauksiin voisi lisätä ArchiMate-, UML- ja BPMN-kuvausnotaatiot/kielet TOGAFin rinnalle, kun niihin dokumentissa kuitenkin viitataan eri yh-teyksissä. Vastaavasti dokumentaatiossa viitataan SAVIviitearkkitehtuuriin, joka voisi olla viitattuna myös tässä yhteydessä. 10. Muutosehdotukset kappaleeseen 4. Termit ja määritelmät Vastaajien määrä: 8 - 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. - Palautteessa luvattiin, että terminologi tarkastaa termistön ("Termistö käydään läpi yhdessä terminologin kanssa (pohjalla yhteinen JHS-sanasto)."), 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. Integraatioarkkitehtuuri: määritelmän sanamuoto on huono, sillä se 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. - 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. - Termien määritelmät eivät ole parantuneet ensimmäisen kierroksen mu-kaisista 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ä (esim. termit ADSL, AMS, CMDB, Docker, Ethernet, Help desk, CI, EDI, IaaS, PaaS, ipaas, MOLS, SaM, XaaS, jne.). Ne heikentävät oleel-lisesti suosituksen luettavuutta ja ne tulee poistaa suosituksesta. Termi-luettelossa 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 suomen- ja 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. 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. 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 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ä. 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). - 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 2017. 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 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 tietoaineistojen kokoelma ) saattaa myös viedä ajatukset suoraan loogisiin tietovarantoihin, mikä ei liene tarkoitus. Tuossa oleva looginen lienee sovellettavissa niin loogisiin kuin fyysisiinkin tietovarantoihin. Kohdassa 7.3.2 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 11. Muutosehdotukset kappaleeseen 5. Toiminnan kokonaisvaltainen kehittäminen Vastaajien määrä: 3 - Yleisesti ottaen voisi harkita kuvausten tuottamista jollain yleisellä standardilla/notaatiolla. Esim. kuva 3 ei ole täysin yksiselitteinen, voisi miettiä toimisiko ArchiMate notaatio tässä? - Suositusluonnoksen toiseen version on pyritty tarkentamaan ja selven-tämään esille tuotuja uusia toiminnan johtamiseen ja jäsentämisen käsit-teitä (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 hallinnonalakoh-taisesti 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 joh-tamisen käsitteistöön. Toiminnan kokonaisvaltainen kehittäminen on kuvattu suositusluonnok-sessa edelleen sekavasti. Suosituksessa viitataan eri kohdissa ICT-palvelujen kehittämisen suosituksiin (JHS 171 ICT-palvelujen kehittämi-nen: Kehittämiskohteiden tunnistaminen sekä JHS 172 ICT-palvelujen kehittäminen: Esiselvitys), mutta suosituksessa ei tule edelleenkään sel-keästi esille, miten nämä suositukset suhteutuvat tähän luonnokseen ja etenkin luonnoksen uusiin osa-alueisiin, kuten kyvykkyyksien kehittämi-nen 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 ja JHS172 -suosituksiin. Tavoiteltavana tulisi olla näi-den suositusten sulauttaminen yhdeksi eheäksi kokonaisuudeksi. - 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. 12. Muutosehdotukset kappaleeseen 5.1 Toiminnan kehittämisen rakenteellinen kokonaisuus 13. Muutosehdotukset kappaleeseen 5.1.1 Organisaation tavoitteet ja toimintamallit - Toisessa kappaleessa muutama kirjoitusvirhe: "..sekä niihin liittyvät." -> mitkä? "Tietoturvallisuus tulee huomioida osana tavoitteiden asettamista ja varmistaa myös tietosuojan, varautumisen kehittäminen ja ylläpito." 14. Muutosehdotukset kappaleeseen 5.1.2 Rakenteiden suunnittelu 15. Muutosehdotukset kappaleeseen 5.1.3 Toimeenpanon ja toteutuksen mallit
16. Muutosehdotukset kappaleeseen 6. Kokonaisarkkitehtuurimenetelmä - 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 viitekehyk-sen rinnalle uutena rakenteena arkkitehtuurisisällön viitekehys. Uudis-tuksen tarkoituksena on saada huomio kiinnittymään enemmän kuvaussisältöjen valintaan. Saman olisi voinut toteuttaa olemassa olevaan ku-vausviitekehykseen, sillä todellisuudessa uudistus ei tuo lisäinfoa mene-telmään, mutta tuo uuden rakenteellisen kerroksen tai vaiheen mene-telmän käytölle. Ymmärrystä ei myöskään helpota se, että kuvausviite-kehys tuodaan esille vain esimerkinomaisena esityksenä sisältörakentei-den esittämiseen. Mikäli sisältöviitekehystä halutaan korostaa erillisenä metatason viiteke-hyksenä, tulisiko sitä esimerkinomaisesti ilmentävän kuvausviitekehyk-sen olla myös sisäiseltä rakenteeltaan (kuva8) sisältöviitekehyksen sisäi-sen rakenteen (kuva 7) mukaisesti rakentunut. Nyt esim. kuvausviiteke-hyksen käsitteellinen, looginen, ja fyysinen taso eivät ole yhteneviä sisäl-töviitekehyksen rakenteen kanssa. Myöskään kuvausviitekehykseen va-litut kuvauskohteet eivät ole loogisesti kohdennettavissa em. tarkastelu-tasoille. Esim. Teknologiavalinnat on sijoitettu käsitteelliselle tasolle tek-nologia-arkkitehtuurinä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 pe-ruskuvaukset. Tämä tuntuu olevan ristiriidassa kappaleessa 6.1 kerrot-tuun, jossa organisaatio itse määrittelee sisältöviitekehyksen ja sen mu-kaiset kuvaukset; näihin itse määriteltyihin ei välttämättä kuulu perusku-vausten sisältö. Viitekehysten - etenkin kuvausviitekehyksen - sisältöihin ja tulisi kiinnit-tää tarkemmin huomioita myös sen suhteen, että niistä ollaan toisaalla (JHS 198) säätämässä tietohallintolain nojalla asetusta organisaatioilta vaadittavista kuvauksista. Luvussa 6.3 sekoittuu suunnitteluprosessi kuvattavaksi valittuihin sisäl-töihin. Suositusluonnoksen peruskuvaukset ja laajennetut kuvaukset voi-si kuvata erillisen kappaleessa/luvussa; esim. luvussa 7 (Kokonaisarkki-tehtuurin kuvaukset) ja tässä kohtaa vain itse suunnitteluprosessi. se sel-kiinnyttäisi dokumentin luettavuutta oleellisesti. Sinällään suunnitteluprosessi etenee kuvauksessa loogisesti ja on sovel-lettavissa eri organisaatioiden tarpeeseen. 17. Muutosehdotukset kappaleeseen 6.1 Arkkitehtuurisisällön viitekehys 18. Muutosehdotukset kappaleeseen 6.2 Arkkitehtuurikuvausten viitekehys - Kyvykkyyskartta <=> Kyvykkyydet; Kyvykkyyskartta riittää kehyksessä, Kyvykkyydet on vain taulukko (luvussa 7.1)? 19. Muutosehdotukset kappaleeseen 6.2.1 Arkkitehtuurikuvausten viitekehyksen hyödyntäminen arkkitehtuurisuunnittelussa - Ensimmäisen kappaleen lopussa viitataan kuvaan 10. Tarkoitettaneen kuvaa 11. 20. Muutosehdotukset kappaleeseen 6.2.2 Arkkitehtuurisuunnittelun tasot ja arkkitehtuurihierarkia
- Kuvassa 9 pieni kirjoitusvirhe: "JHKA-kohde-alueiden kokonaisarkkitehtuuri". 21. Muutosehdotukset kappaleeseen 6.3 Kokonaisarkkitehtuurin suunnitteluprosessi 22. Muutosehdotukset kappaleeseen 6.3.1 Kokonaisarkkitehtuurin suunnittelun valmistelu 23. Muutosehdotukset kappaleeseen 6.3.1.1 Tunnista ja kokoa ohjaava tieto 24. Muutosehdotukset kappaleeseen 6.3.1.2 Organisoi arkkitehtuurin suunnitteleminen 25. Muutosehdotukset kappaleeseen 6.3.1.3 Kokonaisarkkitehtuurin suunnittelun valmisteluvaiheen lopputulokset 26. Muutosehdotukset kappaleeseen 6.3.2 Arkkitehtuurivision määrittely 27. Muutosehdotukset kappaleeseen 6.3.2.1 Määrittele suunnittelun tavoitteet 28. Muutosehdotukset kappaleeseen 6.3.2.2 Tarkenna toimijat, heidän roolinsa ja tehtävänsä 29. Muutosehdotukset kappaleeseen 6.3.2.3 Määritä ja rajaa kehittämistarpeen mukaiset kokonaisarkkitehtuurin kehittämisalueet 30. Muutosehdotukset kappaleeseen 6.3.2.4 Määrittele arkkitehtuurin toteuttamismalli 31. Muutosehdotukset kappaleeseen 6.3.2.5 Arkkitehtuurivision määrittelyvaiheen lopputulokset
32. Muutosehdotukset kappaleeseen 6.3.3 Kokonaisarkkitehtuurin nykytilan analysointi 33. Muutosehdotukset kappaleeseen 6.3.3.1 Kokoa nykytilan arkkitehtuurikuvaukset ja analysoi nykytila 34. Muutosehdotukset kappaleeseen 6.3.3.2 Arkkitehtuurin nykytilan kuvaaminen perus- ja laajennetuin kuvauksin - 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. 35. Muutosehdotukset kappaleeseen 6.3.3.3 Nykytilan analysointivaiheen lopputulokset 36. Muutosehdotukset kappaleeseen 6.3.4 Kokonaisarkkitehtuurin tavoitetilan suunnittelu 37. Muutosehdotukset kappaleeseen 6.3.4.1 Analysoi ja huomioi tavoitetilan arkkitehtuuriin vaikuttavat tekijät 38. Muutosehdotukset kappaleeseen 6.3.4.2 Arkkitehtuurin tavoitetilan kuvaus perus- tai laajennetuin kuvauksin - 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. 39. Muutosehdotukset kappaleeseen 6.3.4.3 Tee puuteanalyysi 40. Muutosehdotukset kappaleeseen 6.3.4.4 Päivitä arkkitehtuurivision tavoitetilaa tarvittaessa 41. Muutosehdotukset kappaleeseen 6.3.4.5 Arkkitehtuurin tavoitetilan suunnitteluvaiheen lopputulokset 42. Muutosehdotukset kappaleeseen 6.3.5 Toimeenpanon suunnittelu
43. Muutosehdotukset kappaleeseen 6.4 Kokonaisarkkitehtuurin hallintamalli 44. Muutosehdotukset kappaleeseen 7. Kokonaisarkkitehtuurin kuvaukset - Suositusluonnoksen esittämät kuvattavat sisällöt ovat keskeisiä arkkiteh-tuurikuvauksia, joilla saadaan koostettua yhtenäinen näkemys organi-saation 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ä toi-sen 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älli-sellä esitystavallakin on merkitystä. Strategiakartan, liiketoimintamallin ja kyvykkyyksien kuvaaminen tulee organisaation johdon sitoutumisen kautta ja vaatii myös uudenlaista ajattelumallia organisaatioihin. Tätä tu-lee ohjata esim. tulosohjauksen kautta. Suositusluonnoksessa suositeltujen kuvausnotaatioiden käyttäminen vaatii osaamista. Perustason kuvausten tullessa asetuksella voimaan, tu-lee kuvaamisen aloittamisen tueksi järjestää myös koulutusta. 45. Muutosehdotukset kappaleeseen 7.1 Periaatteellisen tason kuvaus 46. Muutosehdotukset kappaleeseen 7.2 Toiminta-arkkitehtuurin kuvaus 47. Muutosehdotukset kappaleeseen 7.2.1 Toiminta-arkkitehtuurin kuvaus käsitteellisellä tasolla 48. Muutosehdotukset kappaleeseen 7.2.2 Toiminta-arkkitehtuurin kuvaus loogisella tasolla 49. Muutosehdotukset kappaleeseen 7.2.3 Toiminta-arkkitehtuurin kuvaus fyysisellä tasolla 50. Muutosehdotukset kappaleeseen 7.3 Tietoarkkitehtuurin kuvaus 51. Muutosehdotukset kappaleeseen 7.3.1 Tietoarkkitehtuurin kuvaus käsitteellisellä tasolla
- 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. 52. Muutosehdotukset kappaleeseen 7.3.2 Tietoarkkitehtuurin kuvaus loogisella tasolla 53. Muutosehdotukset kappaleeseen 7.3.3 Tietoarkkitehtuurin kuvaus fyysisellä tasolla 54. Muutosehdotukset kappaleeseen 7.4 Tietojärjestelmäarkkitehtuurin kuvaus 55. Muutosehdotukset kappaleeseen 7.4.1 Tietojärjestelmäarkkitehtuurin kuvaus käsitteellisellä tasolla 56. Muutosehdotukset kappaleeseen 7.4.2 Tietojärjestelmäarkkitehtuurin kuvaus loogisella tasolla 57. Muutosehdotukset kappaleeseen 7.4.3 Tietojärjestelmäarkkitehtuurin kuvaus fyysisellä tasolla 58. Muutosehdotukset kappaleeseen 7.5 Teknologia-arkkitehtuurin kuvaus 59. Muutosehdotukset kappaleeseen 7.5.1 Teknologia-arkkitehtuurin kuvaus käsitteellisellä tasolla 60. Muutosehdotukset kappaleeseen 7.5.2 Teknologia-arkkitehtuurin kuvaus loogisella tasolla 61. Muutosehdotukset kappaleeseen 7.5.3 Teknologia-arkkitehtuurin kuvaus fyysisellä tasolla 62. Muutosehdotukset kappaleeseen 7.6 Toimeenpanon kuvaus
63. Muutosehdotukset kappaleeseen 7.7 Arkkitehtuurikuvausten hallinta 64. Muutosehdotukset kappaleeseen 7.7.1 Kuvausten nimeäminen ja versiointi 65. Muutosehdotukset kappaleeseen 7.7.2 Kuvauksissa käytettävät notaatiot 66. Muutosehdotukset kappaleeseen 7.7.3 Kuvausten hyödyntäminen 67. Muutosehdotukset kappaleeseen 7.7.4 Yhteenkokoava dokumentti 68. Muutosehdotukset kappaleeseen 8. Integraatioarkkitehtuuri 69. Muutosehdotukset kappaleeseen 9. Tietoturvallisuus 70. Muutosehdotukset kappaleeseen 10. Opastavat tiedot 71. Muutosehdotukset kappaleeseen 11. Liitteet Vastaajien määrä: 2 - 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. 72. Haluatko kommentoida liitettä 1. Strategian kuvaaminen strategiakartan avulla? 0
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? 0 80. Muutosehdotukset liitteen 2 kappaleeseen 1. Johdanto
81. Muutosehdotukset liitteen 2 kappaleeseen 2. Liiketoimintamalli 82. Muutosehdotukset liitteen 2 kappaleeseen 2.1 Liiketoimintamallin kuvaus 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? 0 90. 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 nykytilan kuvaaminen 94. Muutosehdotukset liitteen 3 kappaleeseen 2.3 Nykytilan peruskuvaukset 95. Muutosehdotukset liitteen 3 kappaleeseen 3. Arkkitehtuurin tavoitetilan suunnittelu - Liite 3 kpl 3:Kuva 3 - kuvaan olisi hyvä laittaa myös nuolet vasemmalta oikealle kuvaamaan toimintalähtöistä kehittämistä. 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)? 0
100. Muutosehdotukset liitteeseen 4. Puuteanalyysimatriisi (Excel-tiedosto) 101. Haluatko kommentoida liitettä 5. KA-taulukot (Excel-tiedosto)? 0 102. Muutosehdotukset liitteeseen 5. KA-taulukot (Excel-tiedosto) 103. Haluatko kommentoida liitettä 6. KA-kuvausten visualisointi (Powerpoint-tiedosto)? 0 104. Muutosehdotukset liitteeseen 6. KA-kuvausten visualisointi (Powerpoint-tiedosto) Vastaajien määrä: 3 - 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) - 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ä. - 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' Liite 6 dia 17:Korvaa uusi esimerkki maistraatin kyvykkyyskartasta (käytetään valmennuksissa). Ks. Liite 'Esimerkit JHS179' 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 Liite 6 dia 76:Lisää uusi esimerkki maistraatin käsitemallista (käytetään valmennuksissa). Ks. Liite 'Esimerkit JHS179' 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' 105. Haluatko kommentoida liitettä 7. Semanttisen yhteentoimivuuden menetelmäohje? 0 106. Muutosehdotukset liitteen 7 kappaleeseen 1. Johdanto - 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ä. 107. 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 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? 0 119. Muutosehdotukset liitteen 8 kappaleeseen 1. Johdanto
120. Muutosehdotukset liitteen 8 kappaleeseen 2. Integraatiokokonaisuuden analyysi 121. Muutosehdotukset liitteen 8 kappaleeseen 3.1 Toiminnan palvelut 122. Muutosehdotukset liitteen 8 kappaleeseen 3.2 Toimijoiden välinen vuorovaikutus 123. Muutosehdotukset liitteen 8 kappaleeseen 3.3 Prosessien välinen vuorovaikutus 124. Muutosehdotukset liitteen 8 kappaleeseen 4.1 Tietoarkkitehtuuri ja yhteentoimivuusmenetelmä integraatiosuunnittelussa 125. Muutosehdotukset liitteen 8 kappaleeseen 4.2 Loogiset tietomallit ja soveltamisprofiilit 126. Muutosehdotukset liitteen 8 kappaleeseen 4.3 Tietojärjestelmien välinen vuorovaikutus - Liite 8; 4.3 Tietojärjestelmien välinen vuorovaikutus; 5.5 Tietoliikennearkkitehtuuri: ArchiMate v3.0 standardissa jäljellä vain 1 rajapintaelementti ("tikkari"), ei kahta. Tämä näkyy luvun 4.3 kuvassa 5, mutta luvun 5.5 kuvat ovat ArchiMate v2 notaatiota; Tämä koskee kaikkia rajapintaelementtejä (prosessi, applikaatio, teknologia) 127. Muutosehdotukset liitteen 8 kappaleeseen 4.4 Rajapintojen kuvaaminen 128. Muutosehdotukset liitteen 8 kappaleeseen 4.4.1 Esimerkki ESB-palvelun käytöstä (VIA) 129. Muutosehdotukset liitteen 8 kappaleeseen 4.4.1.1 Sanomapohjaiset integraatiot 130. Muutosehdotukset liitteen 8 kappaleeseen 4.4.1.2 Suurten liiteaineistojen siirto SOAP/RESTkutsuissa
131. Muutosehdotukset liitteen 8 kappaleeseen 4.4.1.3 Tiedostojen siirrot (SFTP) 132. Muutosehdotukset liitteen 8 kappaleeseen 5 Teknologia-arkkitehtuuri integraation näkökulmasta 133. Muutosehdotukset liitteen 8 kappaleeseen 5.1 Tietoliikennearkkitehtuuri osana ITinfrastruktuuria 134. Muutosehdotukset liitteen 8 kappaleeseen 5.2 Tietoliikennearkkitehtuuri verkon näkökulmasta (alhaalta ylös) 135. Muutosehdotukset liitteen 8 kappaleeseen 5.3 Tietoliikenneverkon liityntärajapinnat (RP = ReferenssiPiste) 136. Muutosehdotukset liitteen 8 kappaleeseen 5.4 Tietoliikennearkkitehtuurin verkkokuvaukset 137. Muutosehdotukset liitteen 8 kappaleeseen 5.5 Tietoliikennearkkitehtuuri sovellusmallintajan näkökulmasta (ylhäältä alas) 138. Muutosehdotukset liitteen 8 kappaleeseen 6 Kansallinen palveluarkkitehtuuri integraation näkökulmasta 139. Haluatko kommentoida liitettä 9. Virtualisointi ja pilvipalvelut teknologia-arkkitehtuurin suunnittelussa? 0
140. Muutosehdotukset liitteen 9 kappaleeseen 1. Johdanto 141. Muutosehdotukset liitteen 9 kappaleeseen 2. Virtualisointi 142. Muutosehdotukset liitteen 9 kappaleeseen 3. Pilvipalvelut ja pilvilaskenta 143. Muutosehdotukset liitteen 9 kappaleeseen 3.1 SaaS (Software-as-a-Service) 144. Muutosehdotukset liitteen 9 kappaleeseen 3.2 IaaS (Infrastructure-as-a-Service) 145. Muutosehdotukset liitteen 9 kappaleeseen 3.3 PaaS (Platform-as-a-Service)