Tiedonhallintalaki edellyttää julkisen hallinnon organisaatioita laatimaan tiedonhallintamallin vuoden 2020 loppuun mennessä. Tiedonhallintamallista on hyötyä organisaatiolle, joten sitä kannattaa ylläpitää ja päivittää jatkuvasti. Tiedonhallintamallissa on kenties hyödyllisintä se, että sen avulla voidaan tunnistaa organisaation toiminnan prosessit – eli mitä organisaatio varsinaisesti tekee.
Tiedonhallintamalli on kuvaus tiedonhallintayksikön toteuttamasta tiedonhallinnasta toimintaympäristössään. Tiedonhallintamallin laatimiseen on tarjolla melko paljon ohjeistusta eri toimijoiden taholta. Tässä on tiedonhallintalautakunnan antama suositus tiedonhallintalain vaatimasta tiedonhallintamallista (suora linkki).
Tiedonhallintamalli voidaan toteuttaa eri tavoilla. Sitä voidaan yrittää kuvata Exceliin, se voidaan koota eri lähteissä olevista materiaaleista, tai se voidaan kuvata osana kokonaisarkkitehtuuria. Sillä kokonaisarkkitehtuuria tiedonhallintamallin elementit epäilemättä ovat: organisaation palvelut, toimintaprosessit, tietovarannot ja tietojärjestelmät. Tiedonhallintamalli voidaankin mallintaa yleisimmin käytetyllä kokonaisarkkitehtuurin standardinotaatiolla, ArchiMatella. Kuten yleensä, myös tässäkin tapauksessa kaikki (!) asiat voidaan mallintaa ArchiMate:n perusmuotoisella metamallilla.
Metamalli
Alla olevassa kaaviossa on esitetty yksinkertaistettu versio perusmuotoisesta ArchiMate -metamallista, joka soveltuu sellaisenaan myös Tiedonhallintamallin tarpeisiin.
Erikoistaminen (Specialization). Tiedonhallintamallin elementtien mallintamisessa voidaan hyödyntää ArchiMaten erikoistamisominaisuutta (Specialization, linkki). Näin notaation peruselementtejä voidaan käyttää pohjana (yliluokkana) siitä erikoistetuille elementeille. Tällöin etuna on mm. se, että erikoistettuihin elementteihin pätevät samat yhteystyypit kuin varsinaiseen juurielementtiin (yliluokkaan). Tiedonhallintamallissa käytettäviä erikoistapauksia on havainnollistettu alla olevassa kaaviossa.
Huom! Yllä olevassa esimerkkikaaviossa Tietovaranto on esitetty passiivisena rakenne-elementtinä, jota mallinnetaan Data Object-elementin erikoistapauksena <<Tietovaranto>>. Tällöin siihen liittyvä yhteystyyppi on Access (pääsy). Jos Tietovarantoa mallinnetaan aktiivisena rakenne-elementtinä Application Component -elementillä, silloin siihen pätevät yhteystyypit ovat: Serving (palvelee), Realization (toteuttaa), Flow (tietovirta) ja Access (pääsy). Mikä mallinnustapa valitaan, on organsaatiokohtainen valinta.
Alla on esitetty versio ArchiMate metamallista, johon on lisätty Tiedonhallintalain elementtejä. Niiden tuominen kokonaisarkkitehtuurin perusasioiden päälle lisää turhaan monimutkaisuutta, kuten kaaviosta ilmenee. Seurauksena metamalli saadaan näyttämään monimutkaisemmalta kuin mitä varsinainen mallintaminen itse asiassa on. Lopulta on kuitenkin kyse samoilla ArchiMate-elementeillä mallinnettavista asioista.
Yllä olevassa kaaviossa on mukana Application Service -elementti, joka ei esiinny Tietohallintomallissa, mutta joka on oleellinen kokonaisarkkitehtuurin kannalta: sen avulla käy ilmi miksi järjestelmä on olemassa, mitä toiminnallisuuksia se tarjoaa ulospäin liiketoiminnalle. Applcation Service -elementillä voidaan mallintaa esimerkiksi sovelluksen (=järjestelmän) tarjoamia sovelluspalveluita (=järjestelmäpalveluita) tai IT-palveluita. Jos Application Service ei esiinny, silloin sovelluskomponentin (Tietojärjestelmä tai Tietovaranto) yhteys prosessiin ilmaistaan Serving (palvelee) -yhteystyypillä. (ArchiMate:n yhteystyyppien johtamissääntöjen mukaisesti, linkki.)
Terminologia
Tiedonhallintamallin terminologian mappaus ArchiMate-elementteihin.
Tiedonhallintamallin termi | Kuvaus | ArchiMate-elementti | Perustelut |
Tiedonhallintalaki | Ajuri (Driver) | ||
Tehtävä | Vaatimus (Requirement) | Kysymys on organisaatiolle ulkoa asetetusta tehtävästä. | |
Tiedonhallintayksikkö | Toimija (Business Actor) | ||
Palvelu | Liiketoimintapalvelu (Business Service) | Tässä yhteydessä kyse on organisaation tarjoamista (liike)toiminnallisista palveluista. Ei esim. järjestelmien tarjoamista palveluista (sovelluspalveluista, Application Services). | |
Toimintaprosessi | Liiketoimintaprosessi (Business Process) | ||
Tietoaineisto | Koostuu asiakirjoista tai tiedoista, joista voidaan muodostaa asiakirjoja. | Käsite (Business Object) | |
Tietovaranto | Sovelluskomponentti (Application Component) | Tietovaranto on rakenteellinen elementti (aktiivinen tai passiivinen). Luontevampaa on mallintaa aktiivisena rakenne-elementtinä, koska siihen voidaan kytkeä mm. tietovirtoja (Flow). Tällöin tietovarannon katsotaan olevaan konkreettinen entiteetti organisaation kokonaisuarkkitehtuurissa. | |
Tietojärjestelmä | Sovelluskomponentti (Application Component) | ||
Tietoryhmä | Tietoelementti (Data Object) |
Pohdintaa tiedonhallintamallin mallintamisesta
Tietovaranto
“Tietovarannon” olemus ei ole selkeä, koska sen määritelmä on epämääräinen. Se voidaan käsittää eri tavoin, joko a) passiivisena tiedon luokittelun asiana tai b) aktiivisena rakenne-elementtinä, joka sekä hallinnoi että käsittelee tietoa. Kyseessä on organisatiokohtainen, tapauskojtainen valinta. Tämä on tietysti yleisesti ottaen harmillista, ettei yksikselitteistä käsitystä ole.
Kun pyritään ratkaisemaan miten tietovarantoa tulisi mallintaa, eräs lähestymistapa on tarkastella tietovarantonnon roolia ja merkitystä organisaatiossa: onko kyse a) puhtaasti informaatiosta tai sen ryhmittelystä vai b) informaatiosta, sen hallinnasta ja käsittelystä. Edellisessä tapauksessa “tietovaranto” olisi täysin passiivinen tiedon ryhmittelyn käsite, kun taas jälkimmäisessä “tietovaranto” käsittäisi tiedon itsensä lisäksi sen tallentamisen ja mahdollisesti myös tiedon käsittelyä. Molemmissa tapauksissa tietovaranto on rakenteellinen elementti: edellisessä passiivinen rakenne-elementti ja jälkimmäisessä aktiivinen rakenne-elementti.
Tietovaranto – vaihtioehtoisia mallinnustapoja
“Tietovaranto” (Data Store) voidaan mallintaa ArchiMatella muutamin eri tavoin, joista speksi (3.1) esittelee vaihtoehtoja. Eri organisaatiossa tietovaranto voidaan käsittää eri tavoin. Jopa saman organisaation sisällä tietovaranto voi olla sekä ryhmittelytekijä, että konkreettinen entiteetti, tai näiden yhdistelmä. Kysymys on siis jälleen valinnoista, joita organisaatiossa on tehtävä. Kieli, kuten ArchiMate tässä tapauksessa, tarjoaa elementit ja suhteet. Mutta kieltä voidaan käyttää eri tavoin. Vastaavasti kuten luonnollista, puhuttua kieltä, voidaan käyttää eri tavoin – vaikka sanavarasto on kaikille sama.
Tietovarannon mallintamisen vaihtoehdot:
- Application Component
- Data Object
- Grouping
1) Tietovaranto = aktiivinen rakenne-elementti (Application Component)
Jos tietovaranto on aktiivinen rakenne-elementti, joka voi käsitellä tietoja, ja johon voi kohdistua tietovirtoja, silloin tietovarantoa mallintamiseen soveltuu Application Component -elementti. Tällöin tietovaranto on kuin mikä tahansa itsenäinen tiedonkäsittelykomponentti organisaation kokonaisarkkitehtuurissa, kuten järjestelmä. Esim. asiakastietojen MDM -ratkaisu voi olla ns. “asiakastietovaranto”. Tarvittaessa tietovarannot voidaan erottaa muista järjestelmistä ArchiMaten erikoistamisen (Specialization) avulla: elementin labelissa (“nimikyltissä”) näkyy sekä tyyppi (kuten <<Tietovaranto>>) että varsinainen nimi (“Asiakastietovaranto”).
2) Tietovaranto = passiivinen rakenne-elementti (Data Object)
Jos tietoravanto on passiivinen rakenne-elementti, jota käytetään vain luokittelemaan yhteen kuuluvien tietojen joukkoa, silloin tietovarantoa voidaan mallintaa Data Object -elementillä.
3) Tietovaranto = kooste-elementti (Grouping)
Jos tietovaranto voi olla niin aktiivinen kuin passiviinen rakenne-elementti, tai niiden yhdistelmä, tai joikin muu kokoelma yhteen kuuluuvia asioiya, silloin tietovarannon mallintaamiseen soveltuu Grouping -elementti. Se on kooste-elementti, joka voi koostua esimerkiksi tiedoista ja järjestelmistä. Kooste-elementti on monipuolisin, mutta se on samalla epätarkin, eikä se sovellu hyvin kuvauskannan sisällön analysointiin (jos käytettävässä mallinnusvälineessä on edistyneitä analysointiominaisuuksia).
Tehtävä
“Tehtävä” esiintyy Tiedonhallintamallissa ja tiedonohjaussuunnitelmassa (TOS), mutta sille ei ole täsmällistä vastinetta kokonaisarkkitehtuurin viitekehyksissä. Esimerkiksi ArchiMate-notaatiossa ei ole tehtävä (Task) -elementtiä. Tässä mielessä “tehtävä” on ongelmallinen käsite: se voidaan ymmärtää ja tulkita eri tavoin, tapaus- ja organisaatiokohtaisesti.
“Tehtävä” voidaan mallintaa se esim. vaatimuksena (Requirement), tai konkreettisempana asiana kuten liiketoiminnan palvelu (Business Service) tai -toiminto (Business Function). Vaatimus (Requirement) on kohteeseensa nähden luonteeltaan ulkoinen, se määrittelee mitä kohteen tulisi sisältää, se asettaa vaatimuksia kohteelle. Sen sijaan liiketoiminnan palvelu (Business Service) ja toiminto (Business Function) kuvaavat organisaation liiketoimintaa ja sen jäsentelyä, eli miten kohde (kuten organisaatio) toimii (toiminnot, prosessit) ja mitä toimintojaan se tarjoaa ulospäin (palvelut).
__________________________________________________________________________________
Lisämateriaalia
Katso video kuinka kehittämiskohdetta voidaan kuvata kokonaisarkkitehtuurin kerrosnäkymä -kuvan avulla: linkki.
ArchiMate malleja ja esimerkkejä löytyy täältä:
Katso myös tämä blogini aiheesta Kokonaisarkkitehtuuri ja liiketoiminnan kehittäminen:
_____________________________________________________________________________
Lataa ilmainen open-source mallinnusväline Archi: link.
_____________________________________________________________________________