Palautekooste (2. vaihe): JHS 198 Kokonaisarkkitehtuurin peruskuvaukset 21.11.2016 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 2. Yhteyshenkilön tiedot Vastaajien määrä: 10 3. Yleiskommentit Vastaajien määrä: 8 - 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. 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" - 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. 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. Esimerkkiin voisi liittää kuvauksen, joka selostaa miksi kuvaustapaan ja tarkkuustasoon on päädytty. Tämähän vaihtelee tilanteittain. - Sovimme VM:ssä, että laitan huomiot viralliseen palauteprosessiin. - 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 - Lausunto suositusluonnoksesta JHS 198 Kokonaisarkkitehtuurin peruskuvaukset, 2. vaihe 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ä julki-sen 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. Suositus-luonnokseen 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 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 tieto-hallinnon 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. Tarkemmat huomiot on esitetty alla suositusluonnoksen pääotsikoinnin mukaisella jaottelulla. - 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. - 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ä. - 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 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. 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 - 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. 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. - 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. - 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 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. - Perustelut on kirjattu kohtaan 3. Yleiskommentit - 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 palaut-teiden 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)? - 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. 7. Muutosehdotukset kappaleeseen 1. Johdanto Vastaajien määrä: 3 - Tekninen eritelmä -käsite olisi hyvä kuvata tässä. - 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ääri-telmää. Suositusluonnos tulee kirjoittaa kokonaisuudessaan tarkemmin, jotta se voidaan muuttaa julkisen hallinnon tietohallinnon standardiksi ja edelleen antaa sen perusteella valtioneuvoston asetus. 8. Muutosehdotukset kappaleeseen 2. Soveltamisala Vastaajien määrä: 3 - Dokumentti on suositus, mutta siitä huolimatta sen ohjeita pitää hyödyntää. Mitä, jos ei hyödynnä niitä. - 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ä. 9. Muutosehdotukset kappaleeseen 3. Viittaukset Vastaajien määrä: 2 - 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 10. Muutosehdotukset kappaleeseen 4. Termit ja lyhenteet Vastaajien määrä: 8 - 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? - 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 - 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. - 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. 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")? - 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ä - 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. - 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) 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ä: 3 - 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.
- 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ä. 12. Muutosehdotukset kappaleeseen 6. Kokonaisarkkitehtuurin suunnittelun intensiteetti Vastaajien määrä: 6 - Termejä kehys ja viitekehys käytetään ristiin. Tekstissä viittaukset kuviin (ks. kuva X) joka kerta. - Kolmannessa kappaleessa esiintyvää sanaa "yhteentoimivuus" voisi avata - minkä yhteentoimivuuden kehittämisen vai yhteentoimivuuden kaikkien tasojen kehittämisen? - 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. - 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 setuksen 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. - Asia tässä kohdallaan, mutta intensiteetti on huonoa Suomea. Voisiko intensiteetin sijaan puhua vaikka panostuksista tai syvyydestä? - 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. 13. Muutosehdotukset kappaleeseen 7. Peruskuvaukset nykytilasta Vastaajien määrä: 10 - 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) - 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. 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 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ää. Käsitemallin ja tietomallin ero ja erilainen käyttötarkoitus - 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). - Aiemmin mainitut käsitemäärittelyn ongelmat toistuvat kuvassa 2. 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 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 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". - 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 - 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ä. 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. - 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 pois-taa 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. 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. - 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 - 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. - 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 14. Muutosehdotukset kappaleeseen 8. Peruskuvaukset tavoitetilasta Vastaajien määrä: 8 - 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 johonkin. - 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. Peruskuvaukset tavoitetilasta Taulukko: käsitteen kuvaus on eri asia kuin tietoluokkaan kuuluva attribuutti. Käsitteistä tarvitaan kuvaukset. - Periaatteellinen taso ei ole sen koommin nyky- kuin tavoitetilaa. Kehittämisen tiekartta: suunnittele arkkitehtuurin toimeenpano. Pitäisikö olla toiminnan kehittämisen toimeenpano? Taulukosta puuttuvat selitetekstit. Suuri osa soluista on pääosin tyhjiä. Lukijalle jää täten epäselväksi kuinka tarkkoihin kuvauksiin velvoitetaan. - 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)." Kohta 15 >> käsitteen kuvaus ei ole yhtä kuin attribuutti - Jako nyky- ja tavoitetilan kuvauksiin on monin paikoin keinotekoinen. Osa tavoitetilaan lisäyksenä vaadituista kuvauksista on käytännössä tavoitetilan kuvauksia (esim. ohjaavat 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 hetki-sen 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 - 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. - 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. - Onko realismia pakottaa organisaatio vaikkapa esittämään strategiansa strategiakarttana, jos organisaatio ei niitä osaa tehdä ja ei jäsennä ajatuksissaan strategiaansa kyseisellä tavalla? Voitaneen edellyttää organisaatiolta strategian olemassa olo, mutta sen muoto voisi mielstämme olla vapaa eli ko. organisaatiolle sopiva (vaikkapa tavoitetilojen esittäminen). Tämä koskee mielestämme myös kaikkia JHS:n kuvausvaateita. Muoto ei ole tärkeä vaan sisältö ja ajatus. Ehdotamme myös tarkemmin selvitettäväksi onko tarpeellista kuvata arkkitehtuuriin vaikuttavat lait ja säädökset sekä mitä hyötyä siihen liittyen tavoitellaan. 15. Muutosehdotukset kappaleeseen 9. Opastavat tiedot Vastaajien määrä: 1