Palautekooste ja työryhmän vastine (2. vaihe): JHS 198 Kokonaisarkkitehtuurin peruskuvaukset 1. Organisaatio Vastaajien määrä: 10 - Yksityishenkilö - THL - KAOS-osaamisyhteisö - valtiovarainministeriö - TEM - Valtion tieto- ja viestintätekniikkakeskus Valtori - JHS XXX Rekisteritiedon metatiedot -työryhmä - Maanmittauslaitos - Sosiaali- ja terveysministeriö - Verohallinto 26.04.2017 2. Yhteyshenkilön tiedot Vastaajien määrä: 10 3. Yleiskommentit Vastaajien määrä: 8 3.1 Luonnos on melko keskeneräinen. Käsitteet pitäisi olla paremmin määritellyt, koska tämä on pohjana asetukselle, tulkinnanvaraa ei saa jäädä. Käsitteet järjestelmä/system, tietojärjestelmä/information system, ohjelmistojärjestelmä/software system, sovellusjärjestelmä/application system tulisi eritellä ja määritellä selkeästi sekä käyttää niitä johdonmukaisemmin. Tällä tuetaan sitä, että suositus olisi yhdenmukaisempi vastaavien EU-säädösten kanssa ja tarvittaessa kansainvälisten sopimusten kanssa. Määritelmiä on muokattu. Nykytilakuvaus ja tavoitetilakuvaus pitää vastata toisiaan jokaiselta arkkitehtuurin osa-alueelta, jotta hallittu siirtyminen nykytilasta tavoitetilaan olisi mahdollista, muuten jotain osa-alueita jää huomioimatta. Tehkää yhdenmukaiset taulukot, jotta suositus ei ohjaa jättämään huomioimatta joitain osa-alueita. Kannattaisiko otsikkoon lisätä "...peruskuvaukset nykytilasta ja tavoitetilasta" Pääsääntöisesti vastaavat toisiaan, menetelmäpiirre (samat kuvaukset mutta eri kohteet). Koska kohde on eri (nykytila vs. suunnitelma) eivät kuvauksetkaan voi täsmälleen samoja olla. Kuvauksia saa toki käyttää muitakin. Ei muuteta otsikkoa. 3.2 Hylkäämisen perusteluissa on mukana yleiskommentteja. Niiden lisäksi vielä muutama huomio. Kun puhutaan yhteentoimivuudesta, se väistämättä tarkoittaa tietojen julkaisemista. Ovat kaikki kysytyt tiedot julkaistavissa ilman, että vaarannetaan jotain toiminnan/tiedon turvallisuutta? Minimikuvausten suhde ketterään kehittämiseen olisi hyvä avata. Käytännössä kehittämisessä ollaan joka tapauksessa menossa ketteryyteen. Kyseessä kaksi asiaa: kuvausten tekeminen ja kuvausten julkaiseminen. Tekemistä voidaan edellyttää, mutta julkaiseminen menee julkisuuslain (621/1999) mukaan. Totta, mutta ketterän kehittämisen suositus tulee tehdä erikseen. JHS179 sisältää iteratiivisen kehittämisen ajatuksen. Lisätään maininta iteratiivisuudesta suositukseen.
Liite: visualisoinnit (olennainen osa suositusta, sillä siihen viitataan koko ajan) Erityisesti prosessikarttaesimerkki on korvattava paremmalla. Esimerkeissä on lisäksi usein kuvattu hyvin pientä osa-aluetta (kuten nimen muutos), sellaisen esimerkin katselu ei ole hyödyllistä, jos on analysoimassa isompaa (kokonaisarkkitehtuurille tyypillisempää) kokonaisuutta. Esimerkki verokortti on tuotos, ei palvelu. Palvelun nimessä on oltava verbi. Joitain JHS179-visualisointeja on muokattu palautekierrosten perusteella, esimerkit tulevat muun KA-työn kautta (esim. JHKA, kuntien KA-työ). Visualisoinnit ovat vain esimerkkejä, suositus ei määrittele muotoa, vaan kuvausten sisällön. Esimerkkiin voisi liittää kuvauksen, joka selostaa miksi kuvaustapaan ja tarkkuustasoon on päädytty. Tämähän vaihtelee tilanteittain. 3.3 Sovimme VM:ssä, että laitan huomiot viralliseen palauteprosessiin. Tässä hankkeessa ei aika riitä, mutta muu KA-työ tuottaa ko. esimerkkejä. 3.4 Suosituksessa ja jatkossa velvoittavassa standardissa tulisi huomioida että KA kuvaaminen tulee olla tarvelähtöistä ei itsetarkoitus. Suosituksessa tulisi huomioida organisaation hyöty suhteessa tehtyyn työmäärään sekä tätä kautta viranomaisten hallinnollinen taakka. Onko syytä vielä pohtia perustason edellyttämän KA-velvoitteiden rajausta 3.5 Lausunto suositusluonnoksesta JHS 198 Kokonaisarkkitehtuurin peruskuvaukset, 2. vaihe Tarkennetaan lukua 6 (korostetaan tarvelähtöistä kuvaamista tarkoituksenmukaisessa laajuudessa). Asetustyö määrittelee velvoitteet. Suositus antaa kuvaussuositukset, joita on suositeltavaa hyödyntää riittävien tietojen selvittämiseksi kehittämistä ajatellen. Viite: Palautepyyntö: JHS 189 Kokonaisarkkitehtuurin peruskuvaukset, 2. vaihe -suositusluonnos Julkisen hallinnon neuvottelukunta (JUHTA) on pyytänyt Valtion tieto- ja viestintätekniikkakeskus Valtorilta palautetta suositusluonnoksesta JHS 198 Kokonaisarkkitehtuurin peruskuvaukset. Suositusluonnoksen tarkoituksena on listata julkishallinnon organisaatiolta vaadittavat kokonaisarkkitehtuurin peruskuvaukset ja niiden sisällölliset vaatimukset teknisenä eritelmänä. Suositus (tekninen eritelmä) on tarkoitus muuttaa myöhemmin valtiovarainministeriön päätöksellä julkisen hallinnon tietohallinnon standardiksi ja edelleen antaa tämän pohjalta tietohallintolain (Laki julkisen hallinnon tietohallinnon ohjauksesta, 634/2011) nojalla valtioneuvoston asetus. Kuvaamisesta saatavan hyödyn tulisi, suosituksen tavoitteen mukaan, näkyä julkishallinnossa yhteentoimivuuden parantumisena. Suositusluonnokseen valitut peruskuvakset, jotka keskittyvät lähinnä organisaation oman sisäisen toiminnan ylätason kuvaamiseen, eivät kuitenkaan edistä näkemyksemme mukaan tätä asetettua tavoitetta. Suositusluonnos ei myöskään määrittele ketä varten tai kenen näkökulmasta kuvaukset tuotetaan; vaarana on, että tulevan asetuksen vaatimus täytetään tuottamalla valtiovarainministeriölle erillisiä listauksia kunkin organisaation palveluista, prosesseista ja tietojärjestelmistä muodossa, jotka eivät tuota käytännön hyötyä yhteentoimivuuden edistämiseen. Peruskuvauksia, kuten koko julkishallinnon arkkitehtuuriohjausta, tulisi tarkastella niin, että se edistää julkisen hallinnon toimijoiden omien sähköisten asiointipalvelujen ja sähköistä tiedonhallintaa tukevien tietojärjestelmien sekä laajasti digitalisointia tukevien Kun kaikki kuvaavat samat asiat (vaikkakin oman organisaation kannalta), ko. asiat yhdistettäessä saadaan kokonaisuudelle yhteentoimivuutta. mukaisessa laajuudessa). Yhteentoimivuuden kannalta oleelliset kuvaukset kerätään yhteen. Juuri näin. Ei toimenpiteitä
yhteisten tausta- ja teknologiapalvelujen kehittämistä kohti yhteistä tavoitetilaa (tavoitearkkitehtuuria). Valtorin näkemyksen mukaan suositusluonnoksen ja edelleen asetuksen perusteella vaaditut peruskuvaukset ovat kuitenkin maltillisia tietosisällön osalta. Peruskuvausten tuottaminen ei ole liikaa organisaatioita rasittava tehtävä, joskin edelleen koko julkishallintotasoisena hallinnollista taakkaa lisäävä. Kuvaamiseen käytetyn työmäärän laajuuden tulee määrittämään lähinnä kuvauksilta vaadittu tarkkuustaso, joka täytyy kiinnittää aseteuksen yhteydessä. Eniten työllistäväksi Valtori arvioi kuvauksessa tietoarkkitehtuuriin liittyvien kuvausten toteuttamisen sekä prosessikuvausten toteuttamisen. Näkemyksemme mukaan tietohallintolain (Laki julkisen hallinnon tietohallinnon ohjauksesta 2011/634) perusteella asetuksella voidaan säätää julkisen hallinnon tietohallinnon yhteisestä kokonaisarkkitehtuurista siltä osin kuin se koskee tieto-, järjestelmä- ja teknologia-arkkitehtuuria ja sen edellyttämien yhteentoimivuuden kuvausten ja määritysten sisältöä. Suositusluonnoksen peruskuvaukset kattavat myös toiminta-arkkitehtuuriin liittyviä kuvauskohtia, joista ei em. lain perusteella voida säätää asetuksella. Edellä mainitun perusteella Valtori näkee tarpeelliseksi lisätä arkkitehtuurinohjausta koko julkishallinnossa. Valtori ei kuitenkaan näe tarpeelliseksi säätää asetuksella itse kuvaamista, vaan ohjauksen tulisi painottua enemmän valtion ja laajemmin koko julkishallinnon kuvattuun tavoitetila-arkkitehtuuriin (tahtotilaan), jota toimeenpannaan suositusten sekä tulos-ohjaksen keinoin. Totta, on otettu huomioon asetusvalmistelussa. Toiminta-arkkitehtuuri on suunnittelun perusta ja siten tärkeä kuvattava kohde, vaikka siitä ei asetuksella voidakaan määrätä. Tämä suositus on asetuksen pohja, mutta se myös tukee JHS179 -suositusta. Ohjausta tehdään myös muuna VM:n ohjauksena (JHKA, hankkeet ). Säädösohjaus on yksi, muttei ainoa keino. Tarkemmat huomiot on esitetty alla suositusluonnoksen pääotsikoinnin mukaisella jaottelulla. 3.6 Suositus määrittelee eksplisiittisesti arkkitehtuurikuvaukset, jotka jokaisen julkisen hallinnon organisaation pitää vähintään tuottaa. Julkisen hallinnon organisaatiot ovat hyvin erilaisia ja erikokoisia, eikä kaikille organisaatioille ole välttämättä tarkoituksenmukaista tuottaa kaikkia suosituksessa määriteltyjä kuvauksia. Määritellyissä kuvauksissa tulisi konkreettisin esimerkein avata niiden hyödyntämismahdollisuuksia. Jos organisaatio tai sen sidosryhmät eivät hyödy millään tavalla jostain kuvauksesta, ei sellaista kuvausta tulisi laatia ollenkaan. Nyt suositus ohjaa kuvaamaan kaikki listatut kuvaukset riippumatta siitä, voidaanko tai tullaanko niitä koskaan hyödyntämään mitenkään. 3.7 Tällainen tiivistys on oikein tarpeellinen ja paikallaan. Varsinainen suositus on turhan paksu ja monimutkainen aloitteleville organisaatioille. Tämä auttaa pääsemaan nopeammin kiinni siihen, että mitä kannattaa tehdä. Tässä on kuitenkin samaa ongelmaa kuin varsinaisessa suosituksessakin eli kieli on osittain kankeaa ja käsitteellisesti kovin tietohallintolähtöistä. 3.8 Suosituksessa ei mielestämme huomioida riittävästi yhä kiihtyvämmässä tahdissa ketterän kehittämisen myötä tapahtuvia muutoksia organisaatioissa sekä palveluntuottajista muodostuvia tuotantoketjuja sopimuksineen. Kokonaisarkkitehtuurilla onkin verohallinnossa käytännössä jatkuvasti muuttuva nykytila sekä useita eri ajankohdan tavoitetiloja, joita kuvataan ja joiden mukaisessa laajuudessa). JHS 179 -suositus sisältää myös muuta ohjeistusta ja materiaalia (JHKA). Koulutus ja muu materiaali tukee suositusta. Suositus on suunnattu erityisesti asiantuntijoille ja kun siinä on tavoiteltu täsmällisyyttä, kieli tulee väkisinkin tietyin osin vaativaksi. Muuta materiaalia ja viestintää tarvitaan lisäksi jalkauttamiseen sekä eri sidosryhmien kanssa läpikäymiseen. Selvitetään tarve erillisestä suosituksesta ketterälle kehittämiselle. Lukuun 6 lisätään maininta iteratiivisesta kuvaamisesta.
kuvauksia ylläpidetään samanaikaisesti sekä rinnakkain. Myös kansallisen palveluarkkitehtuurin ja valtion yhteisten palvelujen hyödyntämisen vaikutus tulisi mielestämme huomioida selkeämmin kuvaamisen vaatimuksissa. Verohallinto on investoinut kokonaisarkkitehtuurityöhön jo vuodesta 2010 alkaen. Tähän mennessä tehtyjen investointien lisäksi suositusluonnoksessa esitetyn kuvaustason saavuttaminen vaatisi Verohallinnolta merkittäviä rahallisia lisäinvestointeja sekä asiantuntijoiden työpanosta kokonaisarkkitehtuurityöhön. Investoinnit pitäisivät sisällään mm. merkittävän määrän kuvaamistavan koulutusta sekä suurimpana alueena itse kuvausten laadintaa sekä ylläpitotyötä. Jo nykyisenkin kuvaustason ylläpito vaatii merkittävästi resursseja. Verohallinnolla on myös parhaillaan käynnissä mittavia kehittämishankkeita, joihin liittyy pitkäaikaisia toimitussopimuksia. Osa perustason kuvauksiin liittyvistä kuvaamisvaatimuksista kohdistuu juuri noihin hankkeisiin ja luonnoksessa esitetty kuvaamisvaatimusten taso aiheuttaisi alkuperäisiin suunnitelmiin peilattuna merkittävästi lisätyötä. Kokonaisuutena pidämmekin peruskuvauksille suositusluonnoksessa esitettyä tasoa varsin vaativana sekä kuvausten laadinnan ja ylläpidon näkökulmasta. Huomioitu JHS 179 -liitteissä. Suositus kuvaa sisällön, ei muotoa. Verohallinto voi käyttää olemassa olevia kuvauksia. Suositus on yhä suositus. mukaisessa laajuudessa). mukaisessa laajuudessa). 4. Anna arviosi seuraavista suositusluonnokseen liittyvistä väitteistä asteikolla 1-5 (5 = samaa mieltä, 1 = eri mieltä) Vastaajien määrä: 9 5 4 3 2 1 Yhteensä Keskiarvo Suositus on tarpeellinen 2 2 3 1 1 9 3,33 Suositus on otettavissa käyttöön ilman tukea ja koulutusta Suosituksen luettavuus ja ymmärrettävyys ovat hyvällä tasolla 0 0 4 2 3 9 2,11 0 2 3 2 2 9 2,56 Yhteensä 2 4 10 5 6 27 2,67 5. Suositusluonnoksen hyväksyminen Vastaajien määrä: 10
6. Vastustusperusteet Vastaajien määrä: 5 6.1 Ennen eri kuvausten pakolliseksi julistamista tulisi pakollisten kuvausten joukkoa pilotoida erilaisissa käyttökohteissa. Kaiken arkkitehtuuri- ja mallinnustyön kultainen sääntö on älä tee turhaa työtä, ja nykyinen ja laajentunut vähimmäiskuvausten pakollisuus tulee aiheuttamaan valtavasti turhaa työtä läpi julkishallinnon. Kunkin kuvauksen käyttötarkoitus ja hyödyntäjät on pystyttävä perustelemaan siten, että kuvauksen tuottamisen hyödyt ylittävät kuvauksen tekemiseen tarvittavan työmäärän ja kustannukset. Eri kuvausten soveltaminen käyttökohteen tarpeiden mukaisesti on välttämätöntä. JHS 179 suunnitteluvälineenä sisältää erittäin paljon hyödyllisiä malleja, mutta turhan työn ja periaatteen vuoksi mallintamisen vaatiminen voi tuhota välineen hyödynnettävyyden. Suosituksissa ja pakollisuuksissa on ehdottomasti huomioitava järkevä ja arkkitehtuurityön kohteesta riippuva kuvaamisen laajuus. Suosituksen lähtökohtana on selvästi ollut yksittäisten virastojen kokonaisarkkitehtuurityö, joka ei kuitenkaan vastaa kaikkea julkisen hallinnon (mm. kunnat, julkinen osuus sote-palveluista) toimintaympäristöä. Perustason kuvaukset ovat liian laajat muussa kuin virastokäytössä. Suurimmissa virastoissakin ehdotetun perustason tavoittelu aiheuttaisi kohtuuttoman suuren työmäärän. Jos kehikko / menetelmä on tarkoitettu monenlaisiin käyttökohteisiin, siihen pitää jättää soveltamisvaraa. Jos sen käyttöalue rajataan vain tietyn tyyppiseen tekemiseen, ei sen hyödyntäminen muussa tekemisessä ole järkevää. JHS 179 on ollut hyödyllinen järkevästi sovellettuna ja tarvittaessa täydennettynä ja toivottavasti on sovellettavissa jatkossakin. mukaisessa laajuudessa). Vasta asetus määrittää pakollisuuden, asetus ei ole sama kuin suositus. JHS 179 -suositus on ollut käytössä jo vuosia, joten käyttökokemusta on syntynyt ja JHS 179 -työssä on myös testattu kuvauksia. mukaisessa laajuudessa). Kuten JHS 179 -suosituksessakin on painotettu, kuvaaminen tulee tapahtua tarvelähtöisesti (kehittämisen tarpeet) ja soveltaen (tarkoituksen mukainen laajuus ja tarkkuustaso). Kuvaaminen on myös hyvä useimmiten toteuttaa iterativiisesti. Lukua 6 tarkennetaan suosituksessa näiltä osin. 6.2 - Suositus on liian keskeneräinen ja tulkinnanvarainen muuttuakseen tekniseksi eritelmäksi, jonka perusteella voitaisiin velvoittaa organisaatioita sen noudattamiseen. Suositus on ehdottomasti laitettava vielä yhdelle lausuntokierrokselle korjausten jälkeen. - Keskeneräisyydestä kielii mm. se, että taulukoita ei ole täytetty kokonaan, mukana on soluja, joita ei ole täytetty juuri koskaan. Lisäksi terminologiassa on edelleen korjattavaa. Asetusluonnos perusteluineen tulee vielä erikseen lausunnoille. Taulukkoa ei ole täytetty, koska kaikkiin kohtiin ei ole tarkempia vaatimuksia. Lisätään taulukon yhteyteen maininta asiasta. Määritelmiä on muokattu. - Suosituksessa viitataan usein dokumenttiin Visualisoinnit, johon ei ole saatu koottua yhtenäistä, ehyttä esimerkkiä. Esimerkkiä tullaan noudattamaan hyvässä ja pahassa, lisäksi organisaatioilta tulee menemään merkittävästi aikaa asioiden tulkitsemiseen. Liitteeksi on tuotettava kunnollinen esimerkki, vaikka erikseen tilattavana työnä, jos kenelläkään ei ole sellaista valmiina. Valitettavasti kokonaista esimerkkiä ei ole tässä yhteydessä saatavilla, mutta sellaisia tehdään osana muuta KA-työtä. Koulutus ja muu materiaali tukee kuvausta. - Suosituksen noudattamisen työmäärä vs. hyödyt on analysoitava. Suositusta ei voi laittaa 500 organisaation koekäyttöön, jos tekijöidenkään mielestä ei ole mahdollista tuottaa päästä-päähän Menetelmää on käytetty vuodesta 2012. Tietoja valtion tietohallinnosta -kyselyn
esimerkkiä. Jos joku noudattaa suositusta listamuodossa, on varsin kyseenalaista onko sen laajuisesta excel-harjoituksesta koskaan ollut hyötyä kenellekään. Myöskään PowerPointin käyttäminen ei ole realistinen vaihtoehto, paitsi jos kuvattava osa-alue on erittäin pieni. On myös epätodennäköistä, että eri organisaatioiden tuotokset olisivat yhteismitallisia. mukaan KA-työtä tehdään jo laajasti. Kustannus/hyöty-analyysi tulee osaksi asetuksen perustelua. Tämä suositus osaltaan tekee tuotoksista yhteismitallisia. 6.3 Perustelut on kirjattu kohtaan 3. Yleiskommentit 6.4 Julkisen hallinnon organisaatiot ovat arkkitehtuurien hallinnassa eri vaiheessa ja kypsyystasoilla. Jos tämä suositus muutetaan myöhemmin hallinnon tietohallinnon velvoittavaksi standardiksi, tulee se aiheuttamaan suurelle osalle julkisen hallinnon organisaatioita todella paljon töitä ja kustannuksia. Jotta kokonaisarkkitehtuurikuvauksia voitaisiin laajamittaisesti hyödyntää yhteentoimivuuden edistämiseksi julkishallinnossa, tulisi kaikkien organisaatioiden ymmärtää, mistä kokonaisarkkitehtuurimenetelmässä on kyse ja mitä konkreettisia hyötyjä yhteisen menetelmän käytöllä voidaan saavuttaa. Kuvausten tuottaminen ilman riittävää ymmärrystä niiden hyödyntämisestä tuottaa dataa, mitä tuskin koskaan tullaan tai edes pystytään laajemmin hyödyntämään. Lausunnoilla oleva JHS 179 -suosituksen päivitysluonnos on nykyisellään liian laaja ja vaikeasti ymmärrettävä kokonaisuus tämän ymmärryksen avaamiseksi. JHS 179 -päivitysluonnoksen lausuntojen 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 myös johdon on ymmärrettävä, mistä kokonaisuudessaan on kysymys. Omien, kahdesta edellisestä JHS 179 -suositukseen ja kokonaisarkkitehtuuriin liittyvästä koulutuskierroksesta saatujen kokemusten ja palautteiden perusteella tätä ymmärrystä ei ole onnistuttu merkittävästi lisäämään. Onko tutkittu tai yritetty arvioida, voiko tämä asetus saada käytännössä aikaan muutoksia, jotka voisivat jatkossa säästää tämän asetuksen julkisen hallinnon organisaatioille aiheuttamat lisäkustannukset? Yksityiseltä sektorilta löytyy paljon esimerkkejä kokonaisarkkitehtuurimenetelmän onnistuneesta hyödyntämisestä, mutta onko olemassa referenssejä julkishallinnosta, joissa tässä suosituksessa määriteltyjen kuvausten tuottaminen olisi merkittävästi parantanut yhteentoimivuutta (tai edes organisaation toimintaa)? 6.5 JHS 179-suositusluonnos sekä JHS 198-suositusluonnos ovat molemmat mielestämme suosituksina kannatettavia. JHS 198-suosituksessa esitetyn minimitason vaatiminen sellaisenaan pakollisena asetukseen perustuen ei mielestämme ole kuitenkaan kannatettavaa, sillä se ei huomioi eri kokoisten ja eri tilanteissa olevien organisaatioiden tarpeita. Asetus voi johtaa tilanteeseen, jossa kuvauksia laaditaan vain asetuksen olemassaolon vuoksi, jolloin syvempi kuvaamisen hyötyihin liittyvä ajattelu jäisi taka-alalle. mukaisessa laajuudessa). Standardi ei ole velvoittava, asetus vasta on. Koulutus ja muu materiaali tukevat suositusta ja sen soveltamista. JHS 198 on tiivistetty ja siten yksinkertaisempi. Koulutus ja muu materiaali tukevat suositusta ja sen soveltamista. Tarve koulutukselle erilaiset kohderyhmät huomioiden otetaan huomioon käyttöönottosuunnitelmassa. mukaisessa laajuudessa) ja siten viranomainen itse arvio kustannukset ja Kustannus-hyöty-arvio tulee osaksi asetuksen perustelua mukaisessa laajuudessa). Vasta asetus luo velvoitteen, asetuksella velvoitettavat kuvaukset ovat vain osa peruskuvauksista. 7. Muutosehdotukset kappaleeseen 1. Johdanto Vastaajien määrä: 2
7.1 Tekninen eritelmä -käsite olisi hyvä kuvata tässä. Hylätty. Kuvattu JHS136 -suosituksessa. 7.2 Tämä suositusluonnos (JHS 198) ei täytä voimassa olevan JHS 136-suosituksessa kuvatulla ja tarkoitetulla teknisen eritelmän määritelmän tavalla teknisen eritelmän vaatimuksia eikä siten ole luonteeltaan tekninen eritelmä. JHS 198:n sisältö ei kuvaa tietojärjestelmää tai sen osaa tai tietojärjestelmällä käsiteltäviä tietoja. JHS 198 sisällön tarkkuus ei myöskään vastaa tekniseltä eritelmältä vaadittua tasoa. Tämä suositusluonnos ei vastaa myöskään paraikaa palautekierroksella olevan uuden JHS 136 -suositusluonnoksen teknisen eritelmän määritelmää. Suositusluonnos tulee kirjoittaa kokonaisuudessaan tarkemmin, jotta se voidaan muuttaa julkisen hallinnon tietohallinnon standardiksi ja edelleen antaa sen perusteella valtioneuvoston asetus. Huomioitu Tietojen ja tietojärjestelmien kuvaukset ovat osa tietojärjestelmää. Siten tekniseen eritelmään sisältyvät myös kuvaukset. Tämä tekninen eritelmä ei kohdistu yksittäiseen tietojärjestelmään eikä tietoon, vaan yleisiin tietojärjestelmien ja tietojen kuvauksiin. Teknisen eritelmän voi siten katsoa kattavan myös kuvaukset. Teknisen eritelmän määritelmä on kuitenkin hankala. Suosituksessa teknisen eritelmän edellyttämiä vaatimuksia on annettu vain osalle kuvauksia. Nämä kuvaukset ovat tietojärjestelmien ja tietojen kuvauksia prosessikuvauksia lukuun ottamatta. Näiltä osin suositus täyttää teknisen eritelmän vaatimukset. Vaatimukset on kuvattu suosituksessa riittävällä tarkkuudella tarvittavilta osin. Suosituksessa on siis myös muutakin ohjeistusta, joka ei sisällä vaatimuksia. Asetusvalmistelu tehdään tämän jälkeen. 8. Muutosehdotukset kappaleeseen 2. Soveltamisala Vastaajien määrä: 2 8.1 Dokumentti on suositus, mutta siitä huolimatta sen ohjeita pitää hyödyntää. Mitä, jos ei hyödynnä niitä. 8.2 organisaation kokonaisarkkitehtuurin suunnittelussa. Usein kuvattava kokonaisuus on kohdealue tai toiminnallinen kokonaisuus, jossa on monta eri osapuolta mukana. Lisäksi kokonaisarkkitehtuuria tehdään tyypillisesti erilaisilla rajauksilla ja tarkkuustasoilla. Suosituksen perusteella voi kuitenkin tulla siihen tulokseen, että kokonaisarkkitehtuuri on tehtävä kaikesta. TOGAF preliminary phase mm. kertoo tästä. Tekninen eritelmä on yhä suositus. Viranomaisen on itse arvioitava suosituksen hyödyntämisen laajuus ja tarve. Muutetaan kohtaa seuraavasti: organisaation tai muun kehittämisen kohteen kokonaisarkkitehtuurin suunnittelussa. 9. Muutosehdotukset kappaleeseen 3. Viittaukset Vastaajien määrä: 1 9.1 Tulisiko viittauksiin lisätä suositusluonnoksessa muualla viitatut suositukset (JHS 171, JHS175) Onko tarpeen viitata liitteen liitteisiin (JHS 179)? Viitattu liite kattaa kokonaisuudessaan myös sen liitteet Lisätään viittaukset JHS 171- ja JHS 175- suosituksiin lukuun 3. Tarkemmat viittaukset helpottavat
suosituksen lukijaa. Viittaukset pidetään suosituksessa. 10. Muutosehdotukset kappaleeseen 4. Termit ja lyhenteet Vastaajien määrä: 7 10.1 Sana, käsite, termi -käsitteet tulee kuvata. Kuvattava terminologinen sanasto, asiasanasto, ontologia ja lisättävä mahdollisesti linkit soveltuville sivustoille. JHS 179:ssä ja JHS 198:ssa on useita päällekkäisiä termejä. Päällekkäisyyksiä kannattanee karsia? toiminta-arkkitehtuuri --> toiminta-arkkitehtuuri (=liiketoiminta-arkkitehtuuri) -Ovatko tuotteet organisaation toiminnallisia rakenteita? 10.2 Käsitteet: Käsitemalli EI ole tietomalli, tieto on eri asia kuin käsite. Korjaus käsitemallin määritelmään: tietomalli, joka määrittelee tarkastelun kohteena olevia kohdemaailman käsitteitä ja niiden välisiä suhteita 10.3 Tietoarkkitehtuuriin liittyviä termejä ovat: sanasto, käsite, käsitteistö, käsitemalli, tietoaineisto. Kun vertaa termistöä sekä selitteitä muualla dokumentissa käytettyyn, erityisesti sana käsite esiintyy monessa merkityksessä, lisäksi käsitemallin ja käsitteistön ero ei ole selvä (liittyy myös taulukoihin). Tätä kohtaa ei ole avattu visualisointiesimerkeissä. Lisäksi kannattaa kiinnittää huomiota englanninkielisten vastaavien termien etsimiseen. Kaikki viitekehykset ja kansainväliset standardit ovat englanniksi. Palvelut = Toiminnan palvelut. Sanaa palvelu pitäisi käyttää aina tarkenteen kanssa. 10.4 Määrittelynäkökulma käsitteisiin "käsite", "käsitemalli", "sanasto" ja "käsitteistö" on ongelmallinen. Käsite on määritelty tiedon yksiköksi, joka muodostuu käsitepiirteiden ainutkertaisesta yhdistelmästä. Sen huomautuksessa otetaan kantaa kieli- ja kulttuurisidonnaisuuksiin. Tässä tuntuu menevän sekaisin ns. reaalimaailman tarkoitteita kuvaavat "käsitteet" ja tietomallinnuksessa hyödynnettävät "käsitteet". Käsitepiirteet ja kieli- ja kulttuurisidonnaisuudet liittyvät ensisijassa sanastotyön tarkoittamiin käsitteisiin, niihin reaalimaailman kuvauksiin. Tiedon yksikkö liittyy taas tietomallinnuksen tarvitsemaan kuvaukseen tiedosta. Määrittelyjä muokattu ja lisätty termin määritelmä. Termit eivät ole päällekkäisiä, vaan ne on pyritty pitämään täsmälleen samoina. Lisätty selitys lisätietoa sarakkeeseen ja muokattu määrittelyjä. Määrittelyjä muokattu Lisätty selitys lisätietoa sarakkeeseen ja muokattu määrittelyjä. Käsite-käsitteen määrittelyn ongelma toistuu käsitemallissa, jonka todetaan kuvaavan kohdemaailman käsitteet ja niiden väliset suhteet. Jos määrittelyä luetaan huomioimalla "käsitteelle" annettu määritys, muodostuu käsitemallin merkitykseksi " tietomalli, joka määrittelee tarkastelun kohteena olevat tiedon yksiköt, jotka muodostuvat käsitepiirteiden ainutkertaisesta yhdistelmästä, ja niiden väliset suhteet. Eli onko käsitemalli käsitteiden ja niiden suhteiden kuvaus vai tietomalli eli tietotarpeen kuvaus? Käsitteistö ei ole luettelo käytetyistä sanastoista. Se voi muodostua sanastoissa määritellyistä käsitteistä. Sanaston toinen huomautus asettaa "käsite"-käsitteen eri valoon kuin sen oma tässä asiakirjassa määritelty merkitys; tässä kohtaa puhutaan käsitteistä, jotka on sijoitettu sanastoon (ei siis vaikkapa käsitemalliin).
Perimmäinen ongelma lienee siinä, että viime aikoina sanastotyön ja sanastojen merkitystä myös tietomallinnuksen osana on ryhdytty korostamaan. Sanastotyössä käsite on tosiaan reaalimaailman kohteen (kielellinen) kuvaus, minkä lisäksi kuvataan käsitteiden keskinäiset suhteet. Tätä suhdeverkostoa sanastotyössä kutsutaan käsitejärjestelmäksi (ei käsitemalliksi). Tietomallinnuksessa on puhuttu käsitemallista, joka on jonkinlainen ylätason kuvaus organisaation tietotarpeista. TIETOtarpeista, ei käsitteistä, vaikka niin puhunta meneekin. Tätä tietotarvetta voidaan kyllä määrittää sanastossa kuvatun käsitteen avulla, mutta kyseessä on silti kaksi eri tiedon hallinnan elementtiä. Tätä käsitteellistä (heheh, vaikka ei oikeasti nauratakaan) ristiriitaa ei ole pystytty vielä täysin ratkaisemaan JHS-179-suosituksessa eikä siten tässäkään siihen nojautuvassa asiakirjassa. Ehdotan siis harkitsemaan, että nämä suositusten käsite/termimäärittelyt tarkastetaan vielä. Tiedon hallinnan elementtien eri tasojen huomioiminen on minusta osa kokonaisarkkitehtuurin suuntaamista nimenomaan toiminnan johtamiseen, pois aiemmin painottuneesta tietojärjestelmien suunnittelusta. "Käsitemalli" esiintyy nähdäkseni erityisen usein silloin, kun vasta hahmotellaan tietotarvetta. Jos haluamme kerätä tietoa punaisista ferrari-merkkisistä autoista, niin onko "auto" tässä "käsite" (reaalimaailman kohteen kuvaus, "nelipyöräinen maata pitkin liikkuva ajoneuvo") vai tietoelementti (käsite=luokka, jolla on attribuutit "merkki" ja "väri")? 10.5 Käsite " toimija" - keskinäiseen toimintaan osallistuva olio, joka voidaan yksilöidä ja jolla voi olla tai johon voi kohdistua oikeuksia, velvollisuuksia ja vastuita. Toimija voi olla henkilö tai organisaatio. Huomioitava että määritystä edelleen editoitu JHSmeta.fi:ssä ydinsanastotyöryhmän kokouksessa, ja termin tila on edelleen luonnos. 10.11.2016 on termin merkitys muotoiltu keskinäiseen toimintaan aktiivisesti osallistuva olio, joka voidaan yksilöidä 10.6 Eivät kuvaa/määrittele riittävän kattavasti termin sisältöä; ovat epämääräisiä ja itseään selittäviä. Termien sisältöihin tulee kiinnittää erityistä huomioita varsinkin, kun suositusluonnoksesta on tarkoitus säätää asetuksella. 10.7 Ehdotetaan lisättäväksi termi "rekisteri". Perustuu siihen, että rekisteri on luultavasti yleisin loogisen tietovarannon ilmenemismuoto ja se tulisi ottaa mukaan sivun 9/19 taulukosso lueteltuihin loogisen tietovarannon kuvauksessa vaadittaviin tietoihin. (ks. kohta Muutosehdotukset kappaleeseen 7) Päivitetty luonnoksen mukaiseksi. Terminologista sanastotyötä jatketaan tiedonhallinnan sanaston parissa. Määrittelyjä on päivitetty. Määritelmät lisätty. Lisäksi tulisi määritellä "looginen tietovaranto". Pelkkä tietovarannon määritelmä ei ole riittävä. Ehdotamme tätä korjausta myös JHS 179:n käsitteisiin. 11. Muutosehdotukset kappaleeseen 5. Arkkitehtuurikuvausten viitekehys Vastaajien määrä: 2
11.1 Aiemmin mainitut käsitemäärittelyn ongelmat toistuvat kuvassa 1. Esimerkiksi, jos käsitemalli onkin itse asiassa tietomalli, onko sen paikka kuvauksissa käsitteellisellä tasolla? Yksi ongelma tässä voi olla KA-menetelmän soveltamisen kohde: voidaanko kaikkia kokonaisarkkitehtuurin käyttötapauksia (mm. hallinnonala/toimiala tai organisaatio tai yksittäinen kehittämishanke) ohjeistaa samalla tavalla? Tätä olisi hyvä miettiä tarkemmin erityisesti tietoarkkitehtuurin kuvausten osalta. 11.2 Suositusluonnoksessa ei tuoda esiin JHS 179 -suosituksen sisältöviite-kehyksen ja kuvausviitekehyksen välistä eroa. JHS179 suosituksessa kuvausviitekehys on vain esimerkinomainen esitys sisällöllisestä viitekehyksestä. Käsitemallia on selvennetty lisätietoja -sarakkeessa. kuvaukset tarkoituksen mukaisessa laajuudessa ja soveltuviin osien. Tietoarkkitehtuuria on käsitelty tarkemmin JHS 179-suosituksessa luvussa 7.3. JHS 198 tukee JHS 179-suositusta, jossa kokonaisarkkitehtuurimenetelmä (ja kehykset) on ensisijaisesti kuvattu. 12. Muutosehdotukset kappaleeseen 6. Kokonaisarkkitehtuurin suunnittelun intensiteetti Vastaajien määrä: 6 12.1 Termejä kehys ja viitekehys käytetään ristiin. Tekstissä viittaukset kuviin (ks. kuva X) joka kerta. 12.2 Kolmannessa kappaleessa esiintyvää sanaa "yhteentoimivuus" voisi avata - minkä yhteentoimivuuden kehittämisen vai yhteentoimivuuden kaikkien tasojen kehittämisen? 12.3 Luvussa 6 todetaan Peruskuvaukset, jotka organisaatioiden on vähintään tuotettava, mahdollistavat yhteentoimivuuden kehittämisen ja parantamisen läpi koko julkisen hallinnon. Miten on tarkoitus ratkaista niiden säilyttäminen ja julkisuuden hallinta? TIETOSUOJA NÄKÖKULMA Julkisella hallinnolla on paljon toimintaa, joka ei ole kuvauksina julkistettavissa (vrt. avoin tieto), vaan joka on vain toimintaan osallistuvien tahojen kesken käytettävää ja tietosuojattavaa. Mikäli on tarkoitus muodostaa sitova standardi asetuksella, käyttöalaa ja tarkoitusta tulee tarkentaa/kuvata lisää, tai erikseen mahdollistaa kuvausten julkisuuden osalta vastuullisen tahon harkinta. Tehdäänkö siis kahdentyyppisiä kuvauksia, julkaistavia ja ei-julkaistavia tietosuojattavia peruskuvauksia? Suositusluonnos ei ota tähän kantaa. Suosituksen käyttöalassa tulisi jotenkin syytä ottaa kantaa siihen, että kuvaukset ja kuvaaminen itsessään on ensisijainen menetelmätavoite (eli KA-menetelmän käyttöönotto itsessään), ja kuvaukset siis tuottavat keskeistä merkittävää lisäarvoa yhteentoimivuuden näkökulmasta, niiltä osin kun kuvaukset ovat avoimesti julkaistuja tai julkaistavissa. 12.4 Turha kappale. Tämän tiedon voisi yhdistää kappaleisiin yksi tai kaksi. Kappaleessa perustellaan peruskuvausten vähäistä laajuutta vedoten organisaatioiden vähäiseen kypsyystasoon arkkitehtuurin suunnittelussa, kuvaamisessa ja soveltamisessa. Käytännössä tällä suositusluonnoksella naulitaan tulevan asetuksen myötä julkishallinnon organisaatioiden arkkitehtuurin kehittäminen pysyvästi kuvattuun tasoon. Siksi vaadittu minimi-taso tulisi olla mietitty niin, että se tuottaa aidosti hyötyä koko julkishallintoon ja yksittäiseen organisaatioon. Hyväksytty. Korjataan viitekehys kaikkiin kohtiin. Lisätään viittaukset kuviin. Muokattu kappaletta. Kuvaaminen ja julkaiseminen ovat eri asioita. Julkaiseminen tehdään julkisuuslain mukaan. Julkisuuslain mukaan tietojärjestelmäkuvaukset ovat yleensä julkisia. Vaikka järjestelmä sisältää salassa pidettäviä tietoja, järjestelmän kuvaus ei välttämättä ole salassa pidettävä. Viranomainen tekee salassapitopäätöksen julkisuuslain 24 perusteella. Lukua ei yhdistetä edellisiin lukuihin. Luvun sisältöä muokataan ja tarkennetaan. Asetusvalmistelu tehdään erikseen.
12.5 Asia tässä kohdallaan, mutta intensiteetti on huonoa Suomea. Voisiko intensiteetin sijaan puhua vaikka panostuksista tai syvyydestä? 12.6 Tästä kohdasta puuttuu hyötyjen tarkastelun näkökulma. Kokonaisarkkitehtuurityöhön tehtävästä panostuksesta ja tavoiteltavasta kypsyystason nostamisesta pitää mielestämme tunnistaa ja arvioida organisaation siitä saama hyöty, jotta voidaan myös perustella siihen liittyvät investoinnit. Muokataan lukua ja sen otsikkoa. Tehdään osana asetusvalmistelua (perustelut-osuudessa). 13. Muutosehdotukset kappaleeseen 7. Peruskuvaukset nykytilasta Vastaajien määrä: 9 13.1 Pitäisikö kuvan 2 kohdassa toimeenpano lukea jotain? Tyhjät kohdat ohjeistuksen nykytilan peruskuvauksissa eivät anna kovin vakuuttavaa kuvaa siitä, mitä organisaatiolta vaaditaan. Eikö organisaation tarvitse tietää, millä niiden järjestelmät on toteutettu? Nykytilataulukolla tulee olla nimi, esim. Taulukko 1. Eikö nykytilassa tarvitse tietää miksi järjestelmä on tehty (periaatteellinen taso)? Tyhjät kohdat taulukossa eivät vakuuta ohjeistuksen tasosta. Esimerkiksi taulukon rivillä 1 voisi olla sisällöllisiä vaatimuksia vastuista,... Rivillä 14 voisi olla tukena jonkinlainen jaottelu tai luokittelu toteutuksen geneerisistä osista (vrt. pilvistandardin kerrosmalli) Taulukkoa ei ole täytetty, koska kaikkiin kohtiin ei ole tarkempia vaatimuksia. Lisätään taulukon yhteyteen maininta asiasta. Lisätään taulukon otsikko. Rivi 14: Tämä on jätetty kuvausten laatijan vastuulle. Ei lisätä tarkempaa jaottelua/luokittelua. 13.2 Vaadittavien peruskuvausten joukko on liian laaja sekä nykytilassa että tavoitetilassa, mikäli suositusta on sovellettava kaikessa julkishallinnon arkkitehtuurityössä, mukaan lukien kohdealueiden arkkitehtuurityö tai viitearkkitehtuurityö. Liian laaja peruskuvausten joukko tulee aiheuttamaan erittäin paljon ylimääräistä työtä, joka ei ole perusteltavissa kaikissa arkkitehtuurityön kohteissa. Mikäli julkisen hallinnon piirissä olevilta toimijoilta edellytetään näin laajaa kuvaamista, on suuri osa niiden kehittämispanostuksista kohdistettava arkkitehtuurikuvausten tekemiseen, ja seikoissa joissa. mukaisessa laajuudessa) ja siten viranomainen itse arvio kustannukset ja Monet kuvauksista ja niissä vaadittavista voivat olla relevantteja yksittäisen organisaation kokonaisarkkitehtuurissa, mutta eivät laajoisssa monia erilaisia toimijoita ohjaavissa kohdealue- ja viitearkkitehtuureissa. Esimerkiksi loogisten tietovarantojen tietoturvataso ja varautumistaso. Nykytilan kuvauksista tulisi poistaa aina edellytettävistä: Toimijoiden välinen vuorovaikutus ja Prosessien välinen vuorovaikutus / nykytilan kuvaukset: useilla toimialoilla prosessien kirjo on niin laaja, että kattavaa kuvausta prosessien välisestä vuorovaikutuksesta ei voida edellyttää. Nykytilan prosessien kattava kuvaaminen esimerkiksi asiantuntijatyön toiminnoissa ja sosiaali-, terveys- ja hyvinvointipalveluissa on työmäärällisesti mahdoton tehtävä. Käsitemallin kuvaus nykytilassa on minimikuvauksena liian raskas. Kunkin käsitteen osalta attribuutit eivät ole käsitemallin yleisen käyttötarkoituksen aina tarvittavia. Tietojärjestelmien välinen vuorovaikutus: ei voida edellyttää monimutkaisten verkostojen osalta kattavaa järjestelmien Tietoturvataso ja varautumistaso ovat relevantteja tietoja loogisissa tietovarannoissa. Niitä ei poisteta. Kuvakset tehdään tarvelähtöisesti ja riittävällä tarkkuustasolla. Nykytilasta ei edellytetä äärimmäisen tarkkoja prosessikuvauksia vaan sellaisia, joiden perusteella voidaan hahmottaa nykytila ja tukea tavoitetilan suunnittelua. Ei poisteta prosessikuvauksia peruskuvauksista. Lisätty tarkennus käsitemallista Lisätietoja-kenttään. Kuvaukset voivat olla työläitä, varsinkin kun kohde on laaja. Toisaalta, tällaistakin kohdetta pitäisi pystyä johtamaan, ohjaamaan ja kehittämään. Kuvausten avulla kehittämisestä tulee
vuorovaikutuksen kuvausta (esim. satoja tietojärjestelmiä), siirtyvän tiedon kuvaaminen edes otsikkotasolla ei sovellu. Tietojärjestelmäsalkkua yksityiskohtineen voi edellyttää lähinnä yksittäiseltä virastolta tai organisaatiolta. Suurissa virastoissa ja organisaatiossa yksityiskohtaisen tietojärjestelmäsalkun ylläpito tarkoittaa huomattavaa työmäärää. suunnitelmallista ja hallittua, ilman niitä kehittäminen on satunnaista. Kuvaus ei itsessään ole ongelma, vaan kohteen monimutkaisuus. Ilman tietojärjestelmien välisten kytkentöjen ymmärrystä esim. häiriön hallinta, riskianalyysit tai muutosten tekeminen on vaarallista ja aiheuttaa ennakoimattomia katkoja. Kuvaus voi jälleen olla työläs, mutta se on perusedellytys järjestelmien hallinnalle. Suurissa organisaatioissa tietojärjestelmät ovat myös merkittävä kustannusten lähde. Jo kustannusseurannan kannalta tietojärjestelmäsalkku on tarpeen. Eli jokin salkun taso on joka tapauksessa oltava, tietosisällön laajuus on arvioitava erikseen. Vuorovaikutuskuvauksia ei poisteta peruskuvauksista. Organisaation tulee tietää mitä tietojärjestelmiä sillä on käytössään. Tietojärjestelmäsalkun sisältö määrittyy myös tarvelähtöisesti, tässä esitetty hyvin pieni määrä erittäin olennaisia tekijöitä, jotka tulee olla tiedossa. Ei poisteta tietojärjestelmäsalkkua. Käsitemallin ja tietomallin ero ja erilainen käyttötarkoitus 13.3 Taulukosta puuttuvat selitetekstit. Suuri osa soluista on pääosin tyhjiä. Lukijalle jää täten epäselväksi kuinka tarkkoihin kuvauksiin velvoitetaan. Taulukko, erityisesti rivit 8 ja 9 (selitteineen ja sisältöineen puuroutuvat yhteen). 13.4 Aiemmin mainitut käsitemäärittelyn ongelmat toistuvat kuvassa 2. Lisätty tarkennus lisätietoa -sarakkeeseen. Hyväksytty. Taulukkoa ei ole täytetty, koska kaikkiin kohtiin ei ole tarkempia vaatimuksia. Lisätään taulukon yhteyteen maininta asiasta. Lisätään taulukoiden otsikot. Taulukkoon voidaan lisätä välilyöntejä selkeyden parantamiseksi. Kohta 2 >> Olisi tärkeä selventää, että "palvelutietovaranto" viittaa nimenomaan "PTV:hen", eli suomi.fi-palvelutietovarantoon. Kohta 8 >> Tämä on hyvin kerrottu sanastojen käytöstä. Kohta 9 >> Tässä tulee hyvin ilmi "käsite"-käsitteen ongelmallinen käyttö: käsite=luokka. Eli ollaan tietomallintamassa tietoja, ei käsitteitä. Tiedon synonyyminä käsite ei voi kuulua sanastoon, mutta luokan (käsite merkityksessä tieto) merkitys voidaan määritellä sanastossa olevan käsitteen avulla. Kyllä kyllä, tällä puhunnalla on pitkät perinteet. Ja yhtä pitkät ovat perinteet hämmennyksellä näissä asioissa. Varmaan niistä ajoista alkaen, kun tiedon hallinta ei ollutkaan enää pelkästään tietokannan asia. Kohta 2: Lisätään maininta PTV/suomi.fi-palvelutietovaranto. kohta 8: Kiitos palautteesta. Kohta 9: Muokattu käsiteiden määrittelyjä ja lisätty käsitemalliin liittyen tarkennus lisätietoa -sarakkeeseen. Kohta 10 >> pitäisikö vaadittujen tunnusten olla pysyviä? Kohta 12 >> viimeinen pallura "siirtyvä tieto"; voi kuulostaa ns. tyhmältä kysymykseltä, mutta mitä tämä oikeastaan tarkoittaa, että pitää olla tieto "siirtyvästä tiedosta"? Onko tällä kytkös niihin käsite/tietomalleihin eli tietosisällön kuvauksiin? Vai onko tämä tarkoitettu esimerkiksi tasolla "asiakastieto"? Mihin määritellään Kohta 10: Ei tarvitse olla pysyviä. Kohta 12: Siirtyvä tieto on yleensä ylätason tieto, kuten esitetty
mitä on "asiakastieto"? Jos kyse on tietojärjestelmien vuorovaikutuksesta, niin ei riitä, että toinen osapuoli tietää mitä se on, molempien on ymmärrettävä vuorovaikutuksessa oleva tieto samalla tavalla. Jos tietojärjestelmissä käsitellään tietoa, niin voisimme vähitellen luopua sen tiedon kutsumista "käsitteeksi". 13.5 Suosituksessa ja jatkossa velvoittavassa standardissa tulisi huomioida että KA kuvaaminen tulee olla tarvelähtöistä ei itsetarkoitus. Suosituksessa tulisi huomioida organisaation hyöty suhteessa tehtyyn työmäärään sekä tätä kautta viranomaisten hallinnollinen taakka. Onko syytä vielä pohtia perustason edellyttämän KA-velvoitteiden rajausta 13.6 Toiminta-arkkitehtuurin kuvaukset: - Pääosin vaaditut kuvaukset eivät tuo lisäarvoa yhteentoimivuuden edistämiselle. eri organisaatioiden kuvaukset tulevat olemaan myös käytännössä samanlaisia; mm. toimija- ja palvelukarttakuvaukset sekä niiden vuorovaikutuskuvaukset ovat esim. kunnissa lähes identtisiä. Tieto-arkkitehtuurin kuvaukset: - Loogisista tietovarannoista kerättävät tiedot tulisi olla yhteneviä mm. rekisteri- ja tietosuojaselosteiden tietovaatimusten kanssa. - Tietovarantojen ja tietojärjestelmien tiedot tulisi olla myös mahdollisimman yhtenevät mm. tietoturvaan ja varautumiseen liittyvien metatietojen osalta. Esim. nyt vaaditaan varautumistasotietoa tietovarannolta muttei tietojärjestelmältä. asiakastieto. Hyväksytty. mukaisessa laajuudessa) ja siten viranomainen itse arvio kustannukset ja Asetus valmistellaan edelleen ja siinä kuvauksia on rajattu. Lukua 6 tarkennetaan (tarvelähtöisyys, tarkoituksenmukaisesti). mukaisessa laajuudessa) ja siten viranomainen itse arvio kustannukset ja Kuvauksia tekemistä voi tehostaa esim. laatimalla samansuuntaiset kuvaukset yhdessä. Kuntaliitto on ollut tässä aktiivinen. Yhtenevyys on tarkennettu lisätietoa -sarakkeeseen Organisaatio voi lisätä tietoja tarpeen mukaan eri kuvauksiin. Tarkennettu tietoturva-kuvausta. Auttaa organisaatioiden välisten samankaltaisuuksien löytämiseen. Järjestelmäarkkitehtuurin kuvaukset: - Vaaditut kuvaukset tuovat esille organisaatiossa käytetyt järjestelmät sekä niiden väliset ylätason yhteydet. yhteentoimivuuden edistämisen näkökulmasta hyöty on vähäinen. Tämä tarkoittaisi muutoksia tietojärjestelmäsalkun sisältöön JHS 179 -suosituksen liitteessä. Tässä aikaikkunassa muutos ei ole mahdollinen. Organisaatio voi lisätä tietoja tarpeen mukaan eri kuvauksiin. - Tietojärjestelmäsalkkuun kerättävät tiedot ovat lähes samoja kuin mm. julkisuuslain (621/1999) mukaisiin tietojärjestelmäselosteisiin sekä riskienhallinnan ja tietoturvan eri kuvausten kanssa. Kuitenkin nyt suositusluonnoksen ohjeistettu luokittelu poikkeaa osin em. kuvauksissa käytetyistä luokitteluista. Nämä ristiriitaisuudet tulisi poistaa ja laatia uudet yhtenevät sisällöt niin, että kerättävä tieto määritellään yhteneväksi ja tukee eri näkökulmia. Julkisuuslain mukaan viranomaisen tulee laatia ja pitää saatavilla kuvaukset pitämistään tietojärjestelmistä sekä niistä saatavissa olevista julkisista tiedoista. Esitetyt kuvaukset kattavat tämän. Kuvaukset on tarkistettu mm. poistuvan JHS 146:n kanssa. Tavoitteena on juuri tuo esitetty yhteneväinen sisältö, mutta se edellyttää myös lainsäädännön kehittämistä. Teknologia-arkkitehtuurin kuvaukset: - Teknologiavalintojen kuvaaminen on yhteentoimivuuden näkökulmasta täysin turhaa työtä. Enemmän tulisi keskittyä rajapintojen kuvaamiseen loogisella ja fyysisellä tasoilla. Teknologiavalintojen kuvaaminen katsotaan tärkeäksi osaksi nykytilan ja tavoitetilan määrittelyä. Ei poisteta suosituksesta. Asetus määrittelee vain rajapinnat.
13.7 Loogisen tietovarannon kuvauksen pakollisiin (pitää olla) tietoihin tulisi lisätä KA-taulukosta vielä "Tieto siitä, onko kyseessä rekisteri". Tämä parantaisi huomattavasti mahdollisuuksia yhdistää peruskuvauksia rekistereiden tarkempiin (tulevaan JHS Rekisteritiedon metatiedot -suositukseen perustuviin) kuvauksiin käyttäen tietovarannon tunnusta ja/tai nimeä. Loogisentietovarannon taulukossa on JHS rek metan kanssa seuraavat yhteiset kuvailutiedot: Tietovarannon tunnus = rekisterin yksilöivä tunniste Tietovarannon nimi = rekisterin nimi Kuvaus tietovarannosta ja sen sisällöstä : tietojen käsittelyn tarkoitus Tietovarannon keskeisen tietosisällön kuvaus = julkiset tiedot tietoryhmittäin, salasspiudettävät tiedot tietoryhmittäin Tietoturvataso = toteutunut tietoturvan taso Varautumistaso = Varautumistaso Tieto siitä sisältääkö tietovaranto henkilötietoja = henkilötietoluonne 13.8 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. Lisätään loogisten tietovarantojen vaatimuksiin: onko rekisteri (kyllä /ei). Suositusta tukee VM:n järjestämä KA-koulutus ja verkossa julkaistavat koulutusmateriaalit. 13.9 Nykytilan kuvaamisen laajuutta tulisi tehdä sen mukaan mikä on kulloinkin tarkoituksenmukaista. Kuvaaminen vain itsensä vuoksi ei ole mielekästä. Lisäksi tulisi tarkkaan arvioida kuinka syvälle kuvaaminen kannattaa viedä. Esim. nykytilan prosessien kuvaaminen koko organisaation tasolla tuskin on kovinkaan useassa tapauksessa järkevää vaan sitä tulee arvioida sen mukaan millaisessa tilanteessa organisaatio varsinaisesti on. Yleensäkin syvällinen prosessien kuvaaminen on mielekästä vain sellaisessa tilanteessa, että prosessit ovat selvästi organisaation johtamisen väline. Tämän vuoksi kuvaukset voisi jakaa ensisijaisesti tehtäviin ja toissijaisesti tehtäviin. Toissijaisesti tehtäviksi tästä listasta siirtäisimme seuraavat kuvaukset: - toimijoiden välinen vuorovaikutus - prosessien välinen vuorovaikutus - prosessit - toiminnan palvelut -prosessit - Käsitteistö - Käsitemallit mukaisessa laajuudessa) ja siten viranomainen itse arvio kustannukset ja Asetukseen ollaan nostamassa vain osa kuvauksista (nykytilasta järjestelmäsalkku, loogiset tietovarannot ja rajapintakuvaukset). Suosituksen lukua 6 tarkennetaan (korostetaan tarvelähtöistä kuvaamista ja kuvaamista riittävällä tarkkuustasolle jne.) Ei erotella ensisijaisesti /toissijaisesti tehtäviin kuvauksiin. 14. Muutosehdotukset kappaleeseen 8. Peruskuvaukset tavoitetilasta Vastaajien määrä: 8 14.1 Sisällölliset vaatimukset -kohdissa voisi olla esimerkkejä tai muuta ohjeistusta. Rivi 17: looginen tietomalli tietojärjestelmistä --> tiedoista. Eikö loogisia tietomalleja tarvita nykytilassa? Rivi 24: järjestelmän suunniteltu elinkaari olisi hyvä kirjata Hylätty. Vaatimukset- sarake sisältää teknisen eritelmän edellyttämät vaatimusten kuvauksen. Siihen ei voi lisätä muuta ohjeistusta, jolle on varattu oikeanpuoleinen sarake. Rivi 17: Nykytilan ja tavoitetilan kuvauksia voi laajentaa tarpeen mukaan. Nykytilan tietomallit voivat olla jossain tapauksessa
johonkin. 14.2 Loogiset tietomallit eivät kuulu esitetyllä tarkkuustasolla kokonaisarkkitehtuurityön piiriin, vaan tarkempaan järjestelmäsuunnitteluun tai hankintoja varten tehtävään määrittelyyn. Suosituksessa tulisi keskittyä kuvauksiin, jotka ohjaavat projekteja, hankkeita ja hankintoja siten, että myös valmistuotteiden kautta käyttöön tulevat tietomallit ovat mahdollisia. 14.3 Peruskuvaukset tavoitetilasta Taulukko: käsitteen kuvaus on eri asia kuin tietoluokkaan kuuluva attribuutti. Käsitteistä tarvitaan kuvaukset. tarpeellisia Rivi 24: Järjestelmän elinkaari on tietojärjestelmäsalkussa (nykytila). Kehittämisen tiekartta voi olla muukin kuin järjestelmän kehittämisen tiekartta, kuten esimerkiksi toiminnan eri osa-alueiden kehittämisen tiekartta tai kyvykkyyksien kehittämisen tiekartta. Organisaatio voi halutessaan lisätä järjestelmän elinkaaren omaan tietojärjestelmien kehittämistä kuvaavaan tiekarttaan. Loogiset tietomallit voivat ohjata myös projekteja ja hankintoja. Jo varhaisessa suunnittelun vaiheessa on päätettävä tietosisällöistä ja -kokonaisuuksista, ennen järjestelmäsuunnittelua. Siten loogiset tietomallit voivat olla perusteltuja. kuitenkin kuvaukset tarkoituksen mukaisessa laajuudessa ja siten viranomainen itse arvioi kustannukset ja Määritelmät ovat samat nyky- ja tavoitetilassa. Määritelmiä on muokattu. Periaatteellinen taso ei ole sen koommin nyky- kuin tavoitetilaa. Kehittämisen tiekartta: suunnittele arkkitehtuurin toimeenpano. Pitäisikö olla toiminnan kehittämisen toimeenpano? Erityisesti tavoitetilassa periaatteellisen tason kuvaukset ovat olennaisia, jotta tavoitetilaa voidaan perustellusti ja johdonmukaisesti suunnitella ja kuvata. Tässä kohdassa tarkoitetaan arkkitehtuurin tavoitetilan toimeenpanoa, joka on jo osa toiminnan kehittämistä ja sen toimeenpanoa. Taulukosta puuttuvat selitetekstit. Suuri osa soluista on pääosin tyhjiä. Lukijalle jää täten epäselväksi kuinka tarkkoihin kuvauksiin velvoitetaan. Taulukkoa ei ole täytetty, koska kaikkiin kohtiin ei ole tarkempia vaatimuksia. Lisätään taulukon yhteyteen maininta asiasta. Tavoitetilan taulukkoon ei ole myöskään täytetty jo nykytilan taulukossa kuvattuja vaatimuksia, ne tulee siis tarkemmin katsoa ko. taulukosta. 14.4 Aiemmin mainitut käsitemäärittelyn ongelmat toistuvat kuvassa 3. Kohta 14 >> Toinen kappale olisi aivan loistavasti sanottu, jos käsitteen tilalla olisi tieto (tai luokka). "Tiedon kuvauksen tulee perustua yhteisissä sanastoissa ja ontologioissa määriteltyihin käsitteisiin (tai käsitteiden merkityssisältöön)." Määritelmiä on muokattu. Kohta 15 >> käsitteen kuvaus ei ole yhtä kuin attribuutti 14.5 Jako nyky- ja tavoitetilan kuvauksiin on monin paikoin keinotekoinen. Osa tavoitetilaan lisäyksenä vaadituista kuvauksista on käytännössä tavoitetilan kuvauksia (esim. ohjaavat Hylätty. Menetelmä lähtee siitä, että kuvaukset
lait ja säädökset, strategia, järjestelmäsalkku) eikä niitä ole perusteltua käsitellä erillisinä nyky- tai tavoite-tiloina. Osa vaadituista tavoitetilan kuvauksista voisi jättää myös kuvaamatta. Esim. käsitteistöä ei useinkaan kuvata tavoitekäsitteinä, vaan ovat sen hetkisiä nykykäsitteitä. näin ollen käsitemallitkin muovautuvat sen hetkisen kehittämisen yhteydessä ja ovat käytössä nykytilassa. Vastaavasti osa tavoitetilassa vaadituista kuvauksista olisi hyödyllisen myös nykytilan kuvauksena. Esim. arkkitehtuurin kerrosnäkymä palvelee myös nykytilassa organisaatiota 14.6 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. ovat samoja nyky- ja tavoitetilassa, vaikka kohde on eri. Ne siis kuvaavat eri asioita, ja osa kuvauksista on merkityksellisiä vain jommassakummassa. Kuvauksen sisältö on siis erilainen eikä kaikkia kuvauksia ole mielekästä tehdä molemmille. mukaisessa laajuudessa) ja siten viranomainen itse arvioi kustannukset ja Organisaatio voi kuvata halutessaan nykytilasta enemmän kuin peruskuvauksissa on määritelty, sama koskee tavoitetilaa. Käsitteistö jää osaksi tavoitetilan peruskuvauksia. Arkkitehtuurin kerrosnäkymään ei lisätä nykytilan kuvauksiin. Suositusta tukee VM:n järjestämä KA-koulutus ja verkossa julkaistavat koulutusmateriaalit. 14.7 Periaatteessa peruskuvausten painopiste on oikea eli toimintalähtöinen. Tärkeintä kuitenkin on, että kuvaaminen sovelletaan organisaation tilanteen mukaan sopivalle tasolle. Ehdotamme tähänkin kuvausten jakamista ensi- ja toissijaisiin kuvauksiin. Ensisijaiset kuvaukset olisivat: - kehittämisvaatimukset- ja tavoitteet - toimijat - palvelukartta - prosessikartta - loogiset tietovarannot - tietojärjestelmäpalvelut - tietojärjestelmien välinen vuorovaikutus - tietojärjestelmä salkku Loput kuvaukset olisivat sitten toissijaisia. Erityisesti prosessien kuvaamisen tasoa tulee soveltaa sen mukaan, mikä on tarkoituksenmukaista, mutta ylätason prosessien tunnistaminen on tärkeää erityisesti johtamisen kannalta. Tavoitetilan kuvaamisessa tulisi huomioida se, että millaisesta organisaatiosta tai kehittämiskohteesta on kysymys. Pitkälle katsovat tavoitearkkitehtuuri sopii tilanteeseen, jossa ollaan isommassa muutosvaiheessa tai jonkinlaisen uuden ison kehityskokonaisuuden suunnitteluvaiheessa (esim. Tulorekisteri, Kanta / Kansa, tulevat maakunnat). Tämän vuoksi kokonaisarkkitehtuurin yhteys erityisesti organisaatioiden strategiaprosessiin on ensiarvoisen tärkeä. Lisäksi tavoitetilan kuvaamisessa olennaista on huomioida julkisen hallinnon isot yhteiset tai toimialakohtaiset muutoskokonaisuudet, kuten ym. tulorekisteri, Kanta-palvelut sekä kansallisen palveluarkkitehtuurin uudet muutokset. mukaisessa laajuudessa) ja siten viranomainen itse arvioi kustannukset ja Jakoa ensisijaisiin/toissijaisiin kuvauksiin ei tehdä. Lukuun 6 lisätään tarkennus tarvelähtöisestä kuvaamisesta (joka on JHS 179-suosituksen peruslähtökohta) sekä tarvittavan tarkkuustason määrittämisestä ennen kuvauksien tekemistä. Tavoitetilan kuvaukset on tarkoitus tehdä silloin, kun halutaan muutosta. Muussa tapauksessa niihin ei saada mielekästä sisältöä. Periaatteiden kuvaamisen yksi osa ovat viite- ja sidosarkkitehtuurien, rajausten ja reunaehtojen, lainsäädännön muutosten ym. vaikuttavien tekijöiden vaikutusten arviointi tavoitetilan suunnittelussa. Myös strategisten tavoitteiden ja tarkempien tavoitteiden sekä kehittämistavoitteiden määrittelyssä korostuvat sekä muualta tulevien että sisältä tulevien vaatimusten (esim. huomioitava uusi kansallinen järjestelmä) huomiointi. 14.8 Onko realismia pakottaa organisaatio vaikkapa esittämään strategiansa strategiakarttana, jos organisaatio ei niitä osaa tehdä ja ei jäsennä ajatuksissaan strategiaansa kyseisellä tavalla?