Palautetta peruskuvausten sääntelyyn

Tarvitaan pykälä, joka antaa selvän pohjan tiedonhallinnan jatkuvuuden turvaamiselle. Maininta tietoturvasta ei riitä.

Tarvitaan laki, joka velvoittaa valtionhallinnossa tiedonhallinnan yhteentoimivuuden edistämiseen, mutta kuvauksia ja määrityksiä ei tule säätää laissa.

Laissa on velvoitettava kuvaamaan kaikki varusohjelmistojen väliset liitymät tavalla, joka edistää yhteentoimivuutta. Ei siis pelkästään tietojärjestelmän tai viraston tuotteistamat, vaan myös ne mitä käytetään tietojärjestelmäkokonaisuuden sisällä eri komponenttien välisessä yhteistoiminnassa. Ilman tätä ei järjestelmien joustava ja kustannustehokas elinkaaren hallinta ole mahdollista.

Hallinnollisten järjestelmien osalta tiedonhallinnan kuvauksista on tarpeen säätää lain tasolla. Lainsäädännössä tulee määritellä yhteensopivuuden takaamiseen liittyvät kuvaukset ja näiden kuvausmallit.
Lain ulkopuolelle tulee jättää turvallisuusviranomaisten (Poliisi, Puolustusvoimat, Rajavartiolaitos...) operatiiviseen toimintaan liittyvät järjestelmät ja tästä reunaehdosta tulee mainita laissa. Operatiiviset järjestelmät liittyvät kansalliseen turvallisuuteen ja näin ollen operatiiviset järjestelmät tulee kuvata organisaation ja järjestelmiin liittyvien sidosryhmien valitsemalla tavalla, tarkoituksenmukaisin välinein sekä menetelmin riittävän tietoturvan ympäristöissä.

Tarvelähtöisesti, eli mitä lainsäätäjä tahtoo edistää. Kuvauksista ei saisi tulla menetelmäsidonnaisia.

Tavoite lain tasolle lienee hyvä periaate. Jos kuvaustyön tavoitteena on edistää yhteentoimivuutta ja toiminnan tehokkuutta tarjoamalla riittävä läpinäkyvyys ainakin organisaation sisällä ja joissain tapauksissa myös organisaation ulkopuolelle, niin tuo läpinäkyvyys ja sen tuoma kokonaiskäsitys ja -ymmärrys on ehkä sitten se tavoite. Menetelmän tuominen lakiin ei ole hyvä asia, mutta kun se nyt siellä on jo viisi vuotta ollut, niin pitäisi pohtia mitä vaikutuksia sen poistamisella voi olla. Onko esimerkiksi riskinä että sitten keksitään jokin uusi menetelmä johon kaikkien on perehdyttävä ja hankittava uusi osaaminen?

Oma lausuntoni sisältää kuvia, joten lisäsin sen omalle kotisivulle seuraavaan osoitteeseen:
http://www.jukkarannila.fi/lausunnot.html#nro_105

Sinänsä on tarpeen, että julkishallinnon yhteentoimivuutta velvoitetaan lain tasolla - yhteentoimivuus on laaja käsite, jonka tulisi kattaa lainsäädännön, organisaatioiden, arkkitehtuurien, käsitteiden jne yhteentoimivuuden. Nykyinen tietohallintolaki on hyvä lähtökohta, mutta lain nimi on hieman harhaanjohtava: tietohallinto on merkitykseltään liian suppea tässä kontekstissa, ja johtaa ajattelemaan järjestelmälähtöisesti. Tarvitaan kokonaisarkkitehtuuria, ja on hienoa että on olemassa suositukset kehittämismenetelmästä ja peruskuvauksista. Lain tasolla voisi korkeintaan vaatia että organisaatiot toteuttavat kehittämistyössä yhteisiä, päällekkäistä työtä vähentäviä periaatteita ja linjauksia. Tavoitteena olisi että esim. yhtä tietoa kysytään vain kerran jne.

Lain tasolla pitäisi olla kuvaamisen tarkoitus. Kuvauksilla edistettäisiin hyvän tiedonhalllintatavan toteuttamista, esim. yhteentoimivuutta, hallinnon avoimuutta ja julkisuutta, tietosuojaa, tietoturvallisuutta, saatavuutta jne.
Myös kuvaamisen vastuut tulisi olla laissa, tuottaako kuvaukset tehtävän tai palvelun tai järjestelmän omistaja, käyttäjä vai tuottaja.
Lisäksi laissa pitäisi määrätä asetuksenantovaltuus ja se mikä taho antaa tarkemmat ohjeet kuvauksista.
Kuvattavista kohteista ja kuvaamistavoista säädettäisiin asetuksessa.

Kuvauksien ja määritysten säätäminen lain tasolla ei tuota yhteentoimivuutta. Yhteentoimivuuden ongelmat ovat muualla. Kuvaamisella täytyy olla järkevä tarkoitus. Ei pidä kuvata varastoon.

Tarvitaan asetus, joka määrittelee viranomaisyhteistyössä tehdyn jatkuvuudenhallinnan vastuut eritasoiset tietovarannot huomioiden.

Tarvitaan asetus, joka velvoittaa yhteisten tietojärjestelmien käyttöön silloin, kun se on tietojen sisältöä tarkastellen ja tietojen suojaustaso huomioiden perusteltua ja mahdollista. Kuvauksista ja määrityksistä tulee säätää asetuksella korkeintaan tietosisältöperusteisesti, ei määrämuotoon perustuen eikä tiettyihin menetelmiin, sovelluksiin ja työkaluihin sitoutuen. Esimerkki: tiedonhallinnan vastuurajapinnat, toimintamallit sekä järjestelmärajapinnat ja -riippuvuudet on kuvattava ja tiedot taltioitava korkean tason käytettävyyden omaaviin tietojärjestelmiin.

Jokaisen kuvauksen tuottamiseen käytettävästä työkalusta on säädettävä - esimerkiksi viitattava VM:n tarjoamaan työkaluun, joka kerää kaikki kuvaukset yhteen paikkaan. Yhteisten tietojärjestelmien käyttöön liittyen on tehtävä arvio yhteisen tietojärjestelmän soveltuvuudesta toiminnalliseen tarpeeseen. Jos soveltuvuus on korkea, yhteisen tietojärjestelmien käytön on oltava velvoittavaa, mutta soveltuvuuden ollessa alhainen siitä pitää saada automaattisesti vapautus. Lisäksi kannattaa harkita pykälää, jonka avulla kuvauksien tuottaminen siirretään soveltuvin osin myös pakolliseksi vaatimukseksi julkisiin ohjelmistohankintoihin.

Pakollinen tiedonhallinnan kuvausten katselmointi- ja hyväksyntäprosessi (JulkICT:n vastuulla?) voisi olla yhteentoimivuuden osalta yli 1M€ tai muuten kansallisesti merkittävissä hankkeissa pakollinen vaihe toteutuksen ja tuotantoonsiirron välissä.

Kuvausten tuottamisen tulee tapahtua tarveperustaisesti. Jos kyseiselle hallinnolliselle järjestelmälle on asetettu vaatimus yhtyeentoimivuudelle viranomaisjärjestelmien välillä, kuvaukset tulee tuottaa asetuksen määrittelemällä tavalla.

Asetus tarkentaa laissa määrättyä kuvausvelvollisuutta. Huomioitavaa on, että valtioneuvoston asetus velvoittaa lähtökohtaisesti valtion virastoja. Mikäli tavoitteena on parantaa yhteentoimivuutta eduskunnan alaiset laitokset huomioiden, vaatimukset on kirjattava lakiin.

Suomalaisessa "sääntelyprosessissa" asetuksien muuttaminen on hallinnollisesti kevyempää kuin lakien muuttaminen, joten asetuksessa pitäisi olla sellaiset vaatimukset joiden muuttuminen on todennäköistä ja suorastaan suotavaa. Kokonaisarkkitehtuurin sisältöihin (yksittäisiin kuvauksiin ja niiden tietosisältöihin) liittyvät vaatimukset ovat mielestäni sellaisia. Kun organisaatioiden kypsyys kasvaa, niin todennäköisesti kuvausvaatimuksia voidaan ja kannattaa laajentaa pikku hiljaa. Jos valtioneuvoston asetus ei koske kaikkia organisaatioita, niin olisiko syytä arvioida kuinka monta organisaatiota jäisi kuvausvelvoitteen ulkopuolelle ja olisiko se todella katastrofaalista kokonaisuuden kannalta? Eli kuinka suuri osa julkisesta hallinnosta jäisi velvoitteen ulkopuolelle ja mitä siitä konkreettisesti seuraisi. Jos kokonaisarkkitehtuurimenetelmää ei ole laissa tai asetuksessa, niin pitäisikö sitten asetuksen tasolla velvoittaa organisaatiot valitsemaan ja ottamaan käyttöönsä systemaattinen ja kokonaisvaltainen menetelmä, jolla voidaan luoda tarvittava kokonaisnäkemys ja riittävä läpinäkyvyys ja jonka avulla voidaan taata ainakin hallinnon sisäinen yhteentoimivuus? Tällöin kokonaisarkkitehtuurimenetelmä voitaisiin kuvata ohje/suositustasolla yhtenä ko. menetelmänä.

Oma lausuntoni sisältää kuvia, joten lisäsin sen omalle kotisivulle seuraavaan osoitteeseen:
http://www.jukkarannila.fi/lausunnot.html#nro_105

Kuvauksien ja määritysten säätäminen on mielekästä silloin jos niillä halutaan saada aikaan yhteentoimivuutta: kuvaustapakin voisi silloin olla toissijainen. Tulisi olla selvää, mitä standardeja noudatetaan. Erityisesti tietovarantojen ja tietovirtakuvausten tulisi olla sellaisia, ettei niitä(kään) tarvitsisi määritellä jatkossa kuin sen toimijan, joka vastaa kyseisestä tiedosta ja toisaalta tiedon hyödyntämisestä muualla.

Asetuksessa tulisi olla tarkempi luettelo kuvattavista asioista, kuvausten sisältöä ei kuitenkaan määrättäisi asetuksessa vaan normissa.

Jotta kuvaukset olisivat yhtenäisiä ja keskenään vertailukelpoisia/yhteentoimivia, myös kuvaustavan tai -menetelmän täytyy olla yhteinen. Asetuksessa pitäisi joko säätää suoraan kuvausmenetelmästä tai antaa jollekin taholle tehtäväksi määrätä yhteisestä kuvausmenetelmästä. Kuvausmenetelmän käytössä tulee huomioida siirtymäaika, vanhoja kuvauksia ei tarvitse muuntaa uusiin formaatteihin ennen kuin ne muutenkin uusittaisiin.

Asetuksessa tulisi säätää kuvausten ylläpidosta ja ylläpitovastuista, sekä saatavuudesta - miten kuvauksia tulee säilyttää ja miten ne toimitetaan yleisesti tai rajatusti saataville.

Kuvauksien ja määritysten säätäminen asetuksen tasolla ei tuota yhteentoimivuutta. Yhteentoimivuuden ongelmat ovat muualla. Kuvaamisella täytyy olla järkevä tarkoitus. Ei pidä kuvata varastoon.

Tarvitaan ohjeet, joiden mukaan jatkuvuutta ylläpidetään:
- Millä tasolla tarvitaan tietovarantoon tai sen liikenteen solmukohtiin vuosittainen palotarkastus, entä millä tasolla esim. kolmen vuoden välein riittää?
Millä tasolla tarvitaan tietovarantoon tai sen liikenteen solmukohtiin esim. poliisin tekemä vuosittainen fyysisen suojauksen arviointi, entä millä tasolla esim. kolmen vuoden välein riittää?
- Missä vaiheessa kohde pitää auditoida säännöllisesti niin verkkoa, kuin fyysistä kontaktia hyväksi käyttävän red team -toiminnan avulla?
- Millä tasolla tietovaranto ja sen solmukohdat tulee olla 24/7 verkkovalvonnan alla?
- Millä tasolla tietovaranto ja sen solmukohdat tulee olla 24/7 fyysisen valvonnan alla?

Jne.

Kuvausten ja määritysten pohjia(templatet) voidaan antaa suositusten ja ohjeiden muodossa.

Jokaisesta vaadittavasta kuvauksesta pitää olla saatavilla laaja esimerkki oikeasta elämästä (=mittatikku, johon omia tuotteita verrataan). Jos tietojärjestelmän kustannuksia pitää kuvata, määrityksien sisällytettävistä kustannustekijöistä tulee olla äärimmäisen tarkat.

Suosituksia ja ohjeita tulee voida soveltaa organisaation toimintaan ja vaatimuksiin. Pääperiaatteena on päällekkäisen työn välttäminen. Jos organisaatiolla on olemassa toimiva malli tarvittavan dokumentaation luomiseen, kahdennettua kuvaamista tiettyyn formaattiin ei tarvita. Kuvaukset tulee tehdä aina tarpeeseen ja oikea-aikaisesti. Suositusten ja ohjeiden tulee tukea tätä periaatetta.

Suosituksien ja ohjeiden tulee olla selkeitä ja hyvää kieltä. Esimerkkejä kuvauksista on oltava saatavilla. Jonkinlainen interaktiivinen www-palvelu olisi hyvä.

Mentelmän tulisi olla ohje/suositustasoinen. Laki esittää tavoitteen ja velvoitteen. Ohje/suositus kuvaa miten kuvaaminen voidaan esimerkiksi tehdä.

Suositus- ja ohjetasolla pitäisi olla tarkemmat kuvausmallit ja ohjeet kuvausten tekemisestä. Niiden olisi oltava myös riittävän yksityiskohtaisia ja selkeitä, jotta niiden hyödynnettävyys on paras mahdollinen. Ohjeet ja suositukset otetaan käyttöön vain silloin kun niistä on organisaatiolle konkreettista apua ja tukea toimintaan.

Oma lausuntoni sisältää kuvia, joten lisäsin sen omalle kotisivulle seuraavaan osoitteeseen:
http://www.jukkarannila.fi/lausunnot.html#nro_105

Keskeistä olisi saada määriteltyä kunkin tiedon master - eli mikä taho vastaa mistäkin tiedosta. Nykytilakuvauksissa on tarpeen saada nimenomaan selville ne päällekkäisyydet, joita jatkossa tulee välttää: tulee olla selvillä, mistä mikäkin tieto saadaan rajapinnan kautta käyttöön. Vuosittaiset tietotilinpäätökset voivat auttaa (sidottuna tulossopimuksiin) keskittymään sen tiedon hallintaa, mikä kulloinkin vaatii laadun yms. tarkistamista. Näin saadaan laadukkaampaa tietoa päätöksentekoa ja tietojohtamista varten. Ohjeistusta tarvittaisiin siitä miten tietotilinpäätökset tehtäisiin yhtenäisellä tavalla. Tilinpäätökset tulisi olla koordinoidusti saatavilla.

Suosituksissa tulisi olla kuvaamismenetelmästä tarkemmat ohjeet: mihin formaattiin (uudet) kuvaukset laaditaan, mitä yhteisiä työvälineitä käytetään, kuvausten yksiselitteinen tietosisältö huomioiden pakolliset tiedot, kuvausten ylläpidosta ja päivittämisestä.
Suojattavia tietoja sisältäviin kuvauksiin tulisi voida käyttää samoja menetelmiä ja välineitä soveltuvin osin.

Suuntaaminen avoimeen lähdekoodiin. On jatkuvuuden kannalta hyvä, jos toinen toimittaja kykenee jatkamaan esim. konkurssiin menneen toimittajan töitä.

Kuvausmielessä tarvitaan vastuurajapintojen tunnistamista, sovittu yhteistoimintamalli ja muutoksen hallinta, järjestelmärajapintojen ja -riippuvuuksien tunnistamista, tietorakenteiden ja tietoliikennemääritysten tunnistamista.

Rajapintojen täytyy sellaisilla toiminnallisilla alueilla, millä on löydettävissä julkisia (de facto) -standardeja, perustua juurikin niihin. Toimittaja- ja teknologiariippuvaisten rajapintojen käytön tulee olla hyväksyttävää vain kun on arvioitu vaihtoehtojen puuttuvan.

Rajapintakuvaukset, palvelukuvaukset, SLA:t, edellisissä käytetyt standardit sekä tiekartat. Lisäksi muutostenhallintaprosessit ja vastuut edellisiin liittyen.

Tietojärjestelmien rajapinnat täytyy kuvata. Toisaalta, vaikka tietojärjestelmät itsessään toimisivatkin yhteen, vasta semanttinen yhteentoimivuus mahdollistaa automaattisen tiedonsiirron.

Asetusluonnoksessa on jo listattuna tietovarantojen kuvaukset ja rajapintojen kuvaukset, jotka ovat hyvä lähtökohta yhteentoimivuudelle. Niiden lisäksi voisi ehkä kuvata kansallisten ydintietojen (asiakastiedot, kiinteistötiedot jne) tietomallit. Tietojen siirtämisestä jäisi pois turhaa "konvertoimista" ja muokkaamista. Järjestelmien tietomallit voitaisiin tämän jälkeen harmonisoida ko. keskitetysti hallittujen ja kuvattujen tietomallien kanssa pikku hiljaa järjestelmien uudistamisen yhteydessä. Lisäksi pitäisi purkaa turhaa sääntelyä, joka rajoittaa tiedonvaihtoon liittyviä toteutusmahdollisuuksia. On esimerkiksi täysin turhaa määritellä lain tasolla käytetäänkö jossakin tietyssä tiedonvaihdossa teknistä yhteyttä vai ei.

Oma lausuntoni sisältää kuvia, joten lisäsin sen omalle kotisivulle seuraavaan osoitteeseen:
http://www.jukkarannila.fi/lausunnot.html#nro_105

Organisaatiossa tarvittavien ja hyödynnettävien tietojen kuvaukset niin, että keskeinen, ns. arvotieto/käyttötieto saadaan esiin, ja hyödyttämään muita toimijoita. Tulisi edellyttää, että organisaatiot käyttävät YTI-menetelmiä ja yhteisesti sovittuja tietokomponentteja, ja rakentaisivat ns. substanssikomponenttinsa näihin nojautuen.

Palveluiden kuvaukset (vrt. palvelutietovaranto), tietovarantojen kuvaukset, tietojen elinkaari, tietosisältö, tietomalli, rajapintojen kuvaukset, järjestelmien vastuutahot, omistajat

Mikäli viranomainen tarjoaa tietojaan rajapintapalvelussa, on itsestään selvää, että sekä palvelu että tuotteet on kuvattu (vai eikö ole). Muiden kuin tietopalvelua tarjoavien tietojärjestelmien taikka niiden osien kuvaukset ovat organisaation sisäistä toimintaa.

Tietojärjestelmien yhteentoimivuus ei tuota yhteistä ymmärrystä. Tarvitaan tiedon yhteentoimivuutta.

Tiedon säilöminen siten, että sen saa ulos missä muodossa tahansa. Emem me tiedä, miten arkistoja tullaan tulevaisuudessa käyttämään.

Arkiston muodostus tulee jättää suurelta osin toimijoiden vastuulle. Voidaan määrittää keskeiset formaatit, esimerkiksi tekstitiedostot, pdf jne, sekä mahdollisesti arkistointijärjestelmän redundanttisuusvaatimukset.

Ei ehkä liity suoraan tietohallintolakiin ja sen asetukseen, mutta arkistointiin on määritelty kansallinen tietomalli. Arkistointiin ei ole määritelty kansallisia rajapintoja (vrt. HL7 terveydenhuollon alalta). Tämä pitäisi antaa Arkistolaitokselle erittäin korkean prioriteetin tehtäväksi (puute tulee mm. estämään SAPA:n käyttöönoton yhdelläkään asiakkaalla kustannustehokkaasti).

Keskeiset toimintatavat ja reunaehdot arkistojen muodostamiselle, huomioiden eri sidosryhmät.

Arkistonmuodostussuunnitelman, tai nykyiseltä nimeltään tiedonohjaussuunnitelman, tekeminen edellyttää määräysten mukaan toimintaprosessien kuvaamista hyvinkin tarkalla tasolla nimenomaan asian- ja asiakirjahallinnon näkökulmasta. Kyseinen kuvaustyö on substanssitoiminnan kannalta lisätyötä, josta ei synny lisäarvoa. Olisi niin sanotusti kokonaistehokkaampaa kuvata toiminta (toiminta-arkkitehtuurin nykytila) vain yhden kerran ja siten että kuvaustyössä huomioitaisiin erilaiset vaatimukset (läpinäkyvyys, kokonaisymmärrys, asiakirjahallinnon vaatimukset, mahdollisen laatujärjestelmän vaatimukset).

Oma lausuntoni sisältää kuvia, joten lisäsin sen omalle kotisivulle seuraavaan osoitteeseen:
http://www.jukkarannila.fi/lausunnot.html#nro_105

Tietosisällöt, tiedon säilytysajat, julkisuustiedot, säilytysformaatit, kontekstitiedot, omistajuus, säilytysvastuut elinkaaren aikana.
Sähke-määräyksen metatietomallia ei pidä kopioida sellaisenaan.

Julkisuusperiaate edellyttää riittävää automatisointia ja asiakkaalle räätälöityä rajapintaa. Tietojärjestelmät tulee rakentaa siten, että viranomainen kykenee suuntaamaan työpanoksensa siihen mistä on kansalaiselle hyötyä, ja tiedon tarvitsija saa palveltua itse itsensä.

Tiedonhallintaratkaisujen julkisuusmääritykset(tietosuojatasot) on jätettävä viranomaisten arvioitavaksi. Tietojärjestelmäselosteiden keskeiset tietosisällöt voidaan määrittää, mutta kuitenkin ilman määrämuotovelvoitteita ja järjestelmäsidonnaisuutta.

Viranomaisten asianhallintajärjestelmien osana tulee aina toteuttaa julkisen tietoaineiston osalta yleinen rajapinta kansalliseen palveluväylään - tunnistettiin siihen hankkeessa tarvetta tai ei.

Tietoaineistojen tietoturvaluokittelut sekä yhteisten julkisten tietoportaalien hyödyntämisen periaatteet organisaatiossa. Prosessikuvaukset tietoaineistojen käsittelyyn.

Asetusluonnoksessa ja JHS198-luonnoksessa listatuilla kuvauksilla tietosisältövaatimuksineen katetaan ainakin järjestelmäselosteessa oleva sisältö jo melko hyvin (tietovarannon kuvaus ja tietojärjestelmäsalkku). Eli tiedot on koottavissa ko.kuvauksista, joten tarvitaanko muita määrityksiä uusista kuvauksista? Jo nyt on päällekkäisyyttä; kansalaisille tarjotaan rekisteriseloste, järjestelmäseloste ja tulevaisuudessa EU:n tietosuoja-asetuksen edellyttämät selosteet käsittelytoimista. Uusien kuvausvaatimuksien sijaan pitäisi miettiä millaiset selosteet ovat asiakkaan näkökulmasta tarpeen ja miten päällekkäisyyksiä voitaisiin purkaa.

Oma lausuntoni sisältää kuvia, joten lisäsin sen omalle kotisivulle seuraavaan osoitteeseen:
http://www.jukkarannila.fi/lausunnot.html#nro_105

Järjestelmäajattelusta tulisi ehkä päästä eroon - järjestelmät ovat kuitenkin vain väline siihen miten tietoja käsitellään, ja siirretään jne. Tärkeintä olisi saada selville mitä keskeistä tietoa organisaatio käsittelee ja tarvitsee. Nykytilassa tarvitaan vielä selosteita ja järjestelmäkarttojakin. Tavoitteena voisi olla kuitenkin se, mitä palveluita tuotetaan. Tietovirrat, rajapinnat ja tietovarannot ovat keskeisessä roolissa. Tekniikka palvelee näiden komponenttien käyttöä.

Kuvaukset viranomaisen tehtävistä palvelukuvauksina (vrt. palvelutietovaranto), tiedot viranomaisen käsittelemistä asioista, ja kuvaukset käsittelyprosesseista, kuvaukset viranomaisen tietojärjestelmistä, niiden omistajuudesta, julkisuudesta, tietosisällöstä, käytön edellytyksistä.

Järjestelmäselosteet ovat vanhaa kirjallisen kuvaamisen aikakautta sekä aikaa, jolloin yksi järjestelmä hoiti kaiken. Nykyinen järjestelmäinfrastruktuuri ja -ekosysteemi on muuntunut taikka muuntumassa sellaiseksi, että vanhoilla järjestelmälähtöisillä ja selostetyyppisillä tavoilla ei sitä voi enää kuvata. Kokonaisarkkitehtuurimenetelmä antaa tavat järkevämpään sekä loogisen että fyysisen tason kuvaamiseen. Menetelmän käyttö kasvaa hitaasti ja varmasti.

Viranomaiselle tulee antaa laajemmat mahdollisuudet ajaa rekistereitä ristiin. Nykytilanne heikentää päätöksenteon laatua ja estää ammattitaidon kehittymisen, kun verrokkitapaukset jäävät selvittämättä ja tapauksien tausta tai palvelutilanteen jälkeen tapahtunut jatkumo jäävät pimentoon.

Asiakkaan tekemä käyttö edellyttää riittävää automatisointia ja juuri asiakkaalle räätälöityä rajapintaa. Tietojärjestelmät tulee rakentaa siten, että viranomainen kykenee suuntaamaan työpanoksensa siihen mistä on kansalaiselle hyötyä, ja tiedon tarvitsija saa palveltua itse itsensä.

Tietojärjestelmärekisterin keskeiset tietosisällöt voidaan määrittää, mutta kuitenkin ilman määrämuotovelvoitteita ja järjestelmäsidonnaisuutta. Viranomaisilla tulee olla pääsy heidän toiminnan kannalta katsoen keskeisiin rekistereihin.

Rekisterien käyttö vaatii uuden yleislain, jossa mainitaan periaatteet ja perusteet, joita noudattamalla viranomaiset voivat solmia sopimuksen rekisterien ristiinkäytöstä, tavalla jolla on laillisuusvalvoja.

Rakenteellinen kuvaus organisaation käyttämistä ja muille viranomaisille tarjoamistaan rekistereistä. Rekisteriselosteet.

Asetusluonnoksessa ja JHS198-luonnoksessa listatuilla kuvauksilla ja niiden tietosisältövaatimuksilla saadaan nykyistä parempi näkyvyys eri viranomaisten rekistereiden tietosisältöön (tietovarantoihin). Rekistereiden ristiinkäyttöä vaikeuttaa tällä hetkellä paitsi läpinäkyvyyden puute, myös lainsäädännölliset rajoitukset tiedonvaihdossa eri viranomaisten välillä. Myös käsitteiden harmonisointi pitäisi tehdä jonkin tahon toimesta; rekisteri on nyt lainsäädännössä yleisesti käytetty termi, mutta on hyvin epäselvää miten se suhteutuu täällä informaatio-ohjauksen puolella käytettyyn tietovaranto -termiin.

Oma lausuntoni sisältää kuvia, joten lisäsin sen omalle kotisivulle seuraavaan osoitteeseen:
http://www.jukkarannila.fi/lausunnot.html#nro_105

Rekisterit tulisi saatta sille tasolle, että päällekkäisyyksiä niiden välillä ei ole. Tulisi määritellä kunkin tiedon omistaja. Rajapintojen kautta muut toimijat voisivat käyttää näitä tietoja, ja toisaalta vaihtaa omia tietojaan muiden kanssa.

Tietosisällöt ja tietomallien kuvaukset, tiedon omistajuus ja ylläpitovastuut, tietojen käyttöoikeudet ja käytön lakisääteiset edellytykset, oikeudet ja tavat omien tietojen ylläpitoon, rajapintojen kuvaukset

Rekisteri-termiä käytetään, kun puhutaan viranomaisen velvollisuudesta huolehtia lainsäädännön mukaisesta tehtävästään ja lain tähän tarkoitukseen säätämistä tiedoista. Tehtävän toteuttamisen detaljit jäävät (toivottavasti) viranomaisen päätettäväksi. Eli pitää erottaa velvoite ja velvoitteen toteutus. Rekisteriä ei pidä tulkita loogiseksi eikä fyysiseksi tietovarannoksi. Nykyisin rekisteri-termiä käytetään turhan usein myös korostamaan viranomaisen tehtävän ja tietojen ylläpidon velvoittavuutta ja viranomaisen toiminnan tärkeyttä.

Tekstissä on turhan paljon juuri tähän aikakauteen liittyvää ammattiterminologiaa. Kyllä, oikeilla termeillä teksti on täsmällistä. Vaan entä, jos teksti olisi selkokielisempää ja hieman vapaammin tulevaisuuteen suuntautunutta?

Osa kuvauksista voisi olla todellisuudessa osittain mm. Valtorin TOP-järjestelmän automaattisesti tuottamaa. Käyttöön esitettävien kuvaustyökalujen täytyy tukea automaattista yhteyttä organisaatioiden käyttämään toiminnanohjaukseen (ehdoton vaatimus kuvaustyökaluille, tai ne jäävät puhtaasti arkkitehtien käyttöön eikä kuvauksien kautta työskennellä organisaatioissa).

Organisaatioiden rajat ylittävän yhteistoiminnan parempi huomioiminen. Voivatko esim. pienet organisaatiot tehdä kuvaamisessa yhteistyötä ja miltä osin. Tulevaisuuden digitaaliset yhteiskäyttöiset palvelut ja niiden asettamien toiminnallisten muutosten huomioiminen.

Oma lausuntoni sisältää kuvia, joten lisäsin sen omalle kotisivulle seuraavaan osoitteeseen:
http://www.jukkarannila.fi/lausunnot.html#nro_105

Viranomaisten yhteentoimivuutta ylipäänsä, esim. maakunnilta tullaan keräämään eri tarkoituksiin paljon indikaattoritietoa, joista osa on väistämättä samoja tietoja, joita kuitenkin käsitellään eri tahoilla ja järjestelmissä.
Yhteentoimivuutta edistäisivät kuvaukset esim. tietovarannoista, tietojen avoimuudesta, käyttöedellytyksistä, tietoprosesseista, tiedon omistajista ja vastuutahoista elinkaaren aikana, tietojärjestelmistä ja rajapinnoista.

Voitaisiin velvoittaa kaikissa hankinnoissa tekemään erillinen perustelumuistio, jos valittu ohjelmistotuote ei ole avointa lähdekoodia.

Oma lausuntoni sisältää kuvia, joten lisäsin sen omalle kotisivulle seuraavaan osoitteeseen:
http://www.jukkarannila.fi/lausunnot.html#nro_105

Arkkitehtuurimenetelmä, jolla kokonaisarkkitehtuurikin muodostetaan, on vain yksi monista menetelmistä toiminnan ja kyvykkyyden kehittämisessä sekä hallinnassa. Sille ei pidä antaa liian suurta painoarvoa, etenkin kun samoista asioista puhutaan ja samoja tietoja dokumentoidaan eri toimijoiden taholla joka tapauksessa, ilman että niille annetaan arkkitehtuurileimaa. Pelkästään menetelmillä ja eri työkaluilla ongelmat eivät ratkea. Hyvillä ja sopivilla menetelmillä ja työkaluilla voidaan kuitenkin tukea toimintaa ja kehittämistä.

Kokonaisarkkitehtuuri on strategisen johtamisen menetelmä. Kuvaukset ovat vasta pieni osa tarvittavia toimenpiteitä. Strategista johtamista käyttäen siihen tarkoitettuja työkaluja ei ole edelleenkään tarkoitus velvoittaa?

Kokonaisarkkitehtuuriin sisältyvien kuvausten tekeminen olisi velvoitettava osaksi uusia digitalisaatiohankkeita. Uusien hankkeiden kautta tehtynä työmäärä ei kasva liian suureksi organisaatioissa joissa arkkitehtuurityötä ei ole vielä aloitettu.

Laissa/asetuksessa ei pitäsi pitäytyä yhteen menetelmään, vaan kuvata mitä halutaan saada aikaan. Se mitä menetelmää käytetään on sivuseikka.

Lakia tarvitaan ohjaamaan organisaatioita toimimaan kokonaisarkkitehtuuria hyödyntäen, ja yhteentoimivuuteen pyrkien. Suosituksissa on tarkempia ohjeita. Asetuksella voitaisiin säätää oleellisista yhteentoimivuuteen velvoittavista asioista. Kuvaustavat ja menetelmät sinänsä ovat toisarvoisia, mutta esimerkkejä ja malleja on hyvä olla ainakin tässä vaiheessa yhteentoimivuuden tavoitteiden toteuttamisen tiellä.

Kokonaisarkkitehtuurimenetelmän käyttö on vasta alkuvaiheessa, pitäisi osata olla kärsivällisempi, tulokset eivät synny hetkessä, mm. johdon sitouttaminen kestää hetken aikaa (ja joskus tarvitaan myös henkilövaihdoksia).

Kokonaisarkkitehtuurimenetelmän hienous piilee siinä, että useimmat KA-ohjeistuksessa mainitut asiat dokumentoidaan jo nyt. Valitettavasti nyt niitä tehdään pelkkinä visuaalisina tai kirjallisina esityksinä. Eli ei tarvita aina uutta tietoa vaan tieto olisi esitettävä tavalla, josta joku toinenkin saa selvää.

Saattaa olla, että KA-koulutusten ja muiden tilaisuuksien mukanaan tuoma verkostoituminen eri organisaatioiden välillä tuottaa enemmän yhteentoimivuutta ja yhteistä ymmärtämystä kuin mitkään kuvaukset konsanaan.

Keskeistä on tunnistaa tarvittavat tietosisällöt, tarkasteltiinpa sitten nykytilaa tai tavoitetilaa. Sääntelyllä ei saada muuta kuin hankaloitettua kuvausten tuottamista. Parempi tapa on antaa toimijoille hyviä esimerkkejä ja pohjia kuvausten tekemiseksi. Viranomaiset laativat joka tapauksessa tavoitetiladokumentteja, joissa on heidän kannalta katsoen keskeiset tietosisällöt. Yhteismitallisella sääntelyllä ei saavuteta mitään parannusta aikaiseksi, koska mm. toimijat ja toimintaympäristöt ovat valtionhallinnossa niin erilaisia.

Strategia, visio ja kehittämistoiminta eivät ole kuvauksia, vaan johtamisprosesseja. Tyhjiä papereita, jotka eivät sisällä konkreettisia tavoitteita, on jo ihan tarpeeksi. Pitäisi miettiä hallinnollisten tarkastuspisteiden rakentamista johtamisen käynnistämiseksi.

Jokaisen strategia- ja visio-paperin lauseen tulee aina läpäistä SMART: Specific, Measurable, Actionable, Relevant, and Timely -testi.

Säätelyn painopisteenä tulee olla yhteentoimivuus ja tähän liittyvät kuvaukset sekä muutoksenhallinta.

Tavoitetilan kuvauksia ei tule säädellä. Kehittämistoiminnassa, jollaista myös strategiat ja visiot ovat, tulee säilyttää toiminnan vapaus ja luovuus.

Minimissään hankkeen/projektin scopella pitäisi tuottaa tavoitetilan kuvaukset ylätasolla ennen investointipäätöksen tekemistä (eli mitä palveluita, prosesseja, tietovarantoja/tietosisältöjä ja niitä tukevia tietojärjestelmiä on sitten kun hanke/projekti on valmis, ketkä ko.palveluita tuottavat). Organisaation laajuisen tavoitetilan kuvausten tuottaminen kannattanee tehdä organisaation tarpeista lähtien; joskus voi olla järkevää johtaa se strategiasta ja joskus taas voi olla mielekkäämpää johtaa se tiedossa tai käynnissä olevien hankkeiden pohjalta. Ilman konkreettista käytännön kokemusta kuvaustyöstä (disclaimer) luulisin, että on järkevää aloittaa ylätasolta; millaisia palvelukokonaisuuksia organisaatiolla tulee olemaan, miten niitä tuotetaan (ulkoistukset, kumppanit), millaisilla järjestelmäkokonaisuuksilla niitä tuetaan jne. Tässä vaiheessa ja kypsyystasossa tavoitetilan kuvausten vaatiminen voisi muodostua ylitsepääsemättömäksi vaatimukseksi ja vaarantaa koko kuvaustyön.

Nimenomaan tietosisältöjen yhdenmukaisuus edellyttää että saadaan kuvattua se oleellinen tieto, mitä kukin tuottaa, käsittelee ja toisaalta tarvitsee. Tietotilinpäätöksessä, voisi kuvata miten tavoitteisiin on pasty, ja mitä on vielä kesken.

Strategia ja visio ovat yleensä jo kuvauksia itsessään, joten niistä ei pitäisi vaatia uusia kuvauksia. Keskeiset (tunniste)tiedot voidaan liittää muihin kuvauksiin.
Kehittämistoimista tulisi laatia vaiheittain tarkentuvat suunnitelmat toiminta- ja tietoarkkitehtuurin näkökulmista.

Ministeriö voi hyvin olla vastuullinen taho, mutta ministeriöiden on viisasta käyttää hyväksi alaisten organisaatioiden osaamista.

Ministeriöille voisi järjestää kehittyneempää koulutusta arkkitehtuurin hallinnasta ja erityisesti tietomalleista.

Toimialakohtaiseen tietoarkkitehtuuriin, mikäli tarkoitetaan VNOS:n mukaista toimialaa, ministeriö on oikea taho. Mutta kuka vastaa kaikille yhteisestä tietoarkkitehuurista? Tässäkin pitäisi huomioida yhteentoimivuus kaikilla tasoilla. Toimialojen arkkitehtuurikin liittyy johonkin.

Kyllä ministeriöllä pitäisi mielestäni olla myös ylätasoinen käsitys niistä ulkoisista palveluista, joita toimiala/hallinnonala tarjoaa yhteiskunnalle. Eli ylätasoinen nykytilan palvelukartta ja sidosryhmä(toimija) kartta.

Oma lausuntoni sisältää kuvia, joten lisäsin sen omalle kotisivulle seuraavaan osoitteeseen:
http://www.jukkarannila.fi/lausunnot.html#nro_105

Kaikkien julkishallinnon toimijoiden tulisi katselmoittaa tietomallit ja käsitteet YTI-menetelmän avulla - se on ainoa keino saada yhteentoimivuutta aikaan. Tällainen prosessi on jo olemassa!

Ministeriö on sopiva vastuutaho, mutta käytännön tietoarkkitehtuurityössä tulisi käyttää virastojen ja muiden toimijoiden asiantuntemusta.

Tässä vaiheessa ei ole mitenkään järkevää tehdä velvoittavaa lainsäädäntöä käsitteistä. Sanasto- ja käsiteinfrastruktuuri on vasta kehittymässä eikä kaikkia osia ja järkevää prosessia vielä ole koeistettu. Työväline on vasta testivaiheessa.

Palaute asetusluonnoksesta:
Asetusluonnos, 5§: hankkeiden / projektien osalta on tunnistettava tavoitetilan osalta kohteeseen liittyvät sidos- ja viitearkkitehtuurit. Missään ei kuitenkaan ole yksikäsitteisesti avattu sitä mitkä ovat näitä velvoittavia kuvauksia ja mistä ne löytyvät (JHS 198 jättää tämän erittäin epämääräiseksi). Ei voida velvoittaa tekemään jotain sellaista, joka on näin tulkinnanvaraista.
Asetusluonnos, 8 §: nykytilan kuvaukset velvoitetaan viemään VMn työkaluun. Näin ollen koko julkinen hallinto pakotetaan käytännössä käyttämään yhtä kuvaustyökalua, koska kuvausten ylläpitäminen kahdessa työkalussa ei ole työmäärällisesti järkevää. Tämä ei ole mielestäni hyväksyttävää, vaan työkalu pitäisi olla valittavissa organisaation tarpeiden perusteella. Esimerkiksi työkalun analysointitoimintojen tarve kasvaa, kun organisaation KA-kypsyys nousee. Onko nykyisessä työkalussa ko. analysointitoimintoja?
Palaute JHS 198-luonnoksesta:
Peruskuvauksien tavoitetilasta pitää suosituksen mukaan kuvata kehitysvaatimukset. Tämä on hieman päällekkäistä projektihallinnan kanssa, koska keskeiset vaatimukset ja tavoitteet kuvataan yleensä projekti- tai hankesalkkuun. Jos taas tällä tarkoitetaan järjestelmävaatimuksia, niin ne pitäisi kuvata jonnekin muualle, esimerkiksi ISO/IEC 20 030 -standardin luokittelujen mukaisesti. Tämä on hieman epäselvä kuvausvaatimus, koska tästä ei ole yhtään konkreettista esimerkkiä edes JHS 179 -suosituksessa tai sen liitteissä.

Oma lausuntoni sisältää kuvia, joten lisäsin sen omalle kotisivulle seuraavaan osoitteeseen:
http://www.jukkarannila.fi/lausunnot.html#nro_105

Korvaako tämä kysely JHS 198 -suositusluonnoksen 2. palautekierroksen?

Perustelumuistio on hyvä ja selkeä. Valitettavasti kaikki siinä esitetyt ajatukset kokonaisarkkitehtuurin sääntelystä ja hyödyistä eivät realisoidu kokonaisarkkitehtuurin peruskuvauksissa.

Hyvä perustelumuistio. Sopisi melkein sellaisenaan opetus- tai ohjemateriaaliksi.

Oma lausuntoni sisältää kuvia, joten lisäsin sen omalle kotisivulle seuraavaan osoitteeseen:
http://www.jukkarannila.fi/lausunnot.html#nro_105

Perustelumuistion pohjalta syntyy käsitys, että nyt ollaan säätämässä palvelutietovarannon ja liityntäkatalogin kaltaisesti tietojärjestelmävarannosta ja tietovarantovarannosta. Ovatko perustelut niiden tarpeelle riittävät ja tulisivatko ko. varannot olemassaolollaan aikaansaamaan niitä hyötyjä, mitä perusteluissa varantojen synnyttämisestä kuvataan.

Onko VM varautunut tarjoamiensa tietojärjestelmien ylläpitoon koko niiden elinkaaren ajaksi siihen liittyvine toimintoineen riittävän pitkäksi aikaa? Saavutetaanko riittävän laadukasta sisältöä?

Perustelumuistiossa on muutamia väitteitä, jotka kyseenalaistavat sen, onko sääntelyn sisältö ja vaikutukset osattu arvioida oikein (mm. Käsitemallit ovat hyvin lähellä tietojärjestelmien toteutuksessa käytettäviä tietomalleja. Näitä tietomalleja voidaan käyttää esim.
kuvaamaan perusrekisterien tietosisältöjä.)