Tulokset viety arkkitehtuuridokumentteihin

Arkkitehtuuriperiaatteet

Seminaariosuus Winhaajien ja Synergiaryhmän kesken - arkkitehtuuriperiaatteiden käsittely

Periaate nro 1: Yhteistyöllä yhteentoimivuus 

• Korkeakoulut sekä opetus- ja kulttuuriministeriö yhdessä muiden viranomaisten kanssa tuottavat yhteismitallisen tietomallin, joka palvelee myös korkeakoulujen omia tietojärjestelmätarpeita, ja toteuttavat yhteentoimivuutta edistävät ratkaisut muun muassa kokoamalla viranomaisten edellyttämät tiedot korkeakoulujen valtakunnalliseen tietovarantoon, josta tiedot ovat myös korkeakoulun käytettävissä. 

Keskustelu:

Taustaksi:

• Valmistelun pohjana ovat M-määritykset ja XDW-käsitemalli.
• Käynnissä OKM:n OKSA-ryhmän terminologinen sanastotyö, SADe-ohjelmaa toteuttava Oppijan tietomalli --työ, valmistelussa Oppijan/Raketin koodistomäärittelytyö

Hyödynsaajia

1. KSHJ --> koulutustarjonta
2. VIRTA --> suoritukset/tutkintotodistukset
3. TIPTOP --> suoritusvaihetieto,hops-tyyppinen tieto jne.

Lopputuloksia:

• Oppijan käsitemalli kattavuudeltaan suppeampi kuin XDW-kokonaisuus

Organisoitumiskysymyksiä:

• määriteltävä, miten uusi määrittelytieto viedään XDW:hen
• määriteltävä, miten oikeasti kaikki toimijaosapuolet voivat vaikuttaa tietomallin määrittelyyn

Olettaen, että yhteinen yhteismitallinen tietomalli toteutuu:

- Mitä tämä tarkoittaa esim. Winhan käytön kannalta?

• Amkeissa ollaan ostopalveluiden varassa. Ensimmäinen intressi (fyysinen taso) että tieto kulkee myös palvelun toimittajalle, että kehitystyö pysyy ajan tasalla. Toinen intressi (looginen taso) on, miten mapataan oma, käytössä oleva käsitteistö uuteen syntyvään määriteltävään käsitteistöön, millä tehokkuudella ja kustannustasolla.
• Oppijan tietomallia tullaan käyttämään valmisteilla olevissa järjestelmissä: amkeissa käytetään järjestelmien palveluja, jos ne ovat HYÖDYLLISIÄ tai PAKOTTIAVIA. Eli vallitseva periaate on välittömän hyödyn periaate ja velvoittavien rajapintojen huomioon ottaminen. 

- Mahd. tarve muuttaa omaa tulkintaa/toimintatapaa?

• Tässä käsiteltävä yleistavoite on hyvä. Edellä käsitelty mappaus-problematiikka paljastaa tietomallin soveltuvuuden käytännössä. 

- Mitä pitäisi selventää tai muuttaa?

• Viestinnässä haasteita. Kaikkea pitäisi selventää, akronyymiruuhka on vieraannuttavaa.
• Kaivataan myös näyttöjä siitä että jotakin tapahtuu konkreettisesti – pitkään on vain konseptoitu.
• Siis tulokset konkretisoituvat vasta tekemisen kautta. Ja tietysti katsotaan, mitä OKM tahtoo; se on vahva priorisoija.

- Mikä periaatteessa on hyvää / mahdollisuus?

• Luotu yhteistyö on ollut hyvää ja avannut uusia toimintamahdollisuuksia.

- Mikä periaatteessa on huonoa / uhka?

• Rönsyily. Siitä seuraava tehottomuus ja kokonaisuuden hahmottamisen vaikeus. 

- Tarvitseeko periaate rinnalleen joitain tiettyjä muita periaatteita?

• Viisi muuta on jo. 

Periaate nro 2: Korkeakoulukeskeisyys

• Yhteisen tietomallin ja tietovarannon ohella korkeakoulu päättää, mitä tietojärjestelmiä ja miten ne yhdessä tai erikseen tuottavat.  Tietojärjestelmillä tarkoitetaan sekä korkeakoulun tarjoamia palveluita että sovellustoteutuksia. Korkeakoulu päättää miten käyttää resurssinsa eikä korkeakoulujen resursseja oteta korkeakoulujen ohi palveluiden tuottamiseen. 

Vahvuudet

• Autonomia, OKM ei pääse määräämään mitä tehdään ja mihin resursoidaan, ei ohirahoitusta
• Korkeakoulujen erilaisuuden huomioiminen järjestelmätarpeissa
• Yhteismitallinen tieto mahdollistaa osaltaan järjestelmien yhteentoimivuuden
• Winha taipuu uuteen yhteiseen tietomalliin?

Heikkoudet

• Vähäiset resurssit, ei mahdollista tehdä itse kaikkea mitä tarvitaan
• Kumppaneita ei löydy, päällekkäiset ratkaisut, tehoton resurssien käyttö
• Epätasainen palvelutaso korkeakoulujen opiskelijoiden ja opettajien välillä
• Järjestelmät eivät ole kilpailutekijä; tavoite yhteismitallisesta tiedosta on ”vaatimaton” – vaikkakin vaikea

Mahdollisuudet

• Mahdollistaa yhteistyön korkeakoulujen välillä niin pitkälle kuin korkeakoulut haluavat, ei estä korkeakoulukohtaisia tai sektorikohtaisia erillisratkaisuja
• Tarjoaa edellytykset pidemmälle menevälle yhteistyölle, baby steps; tämä on välttämätön pohja, jota on tehtävä

Uhat

• Ei ole korkeakoulut-nimistä subjektia, jotka optimaalisella tavalla löytävät yhteistyömuotoja sieltä missä tarvittaisiin; kehitys pirstoutuu
• Periaate ei toteudu tälläkään tasolla – ei saavuteta mitään
• Autonomia – korkeakoulut tietohallintolakia pilkun tarkasti lukien eivät lähde mukaan

Periaate nro 3: Tieto ytimessä

• Opiskelijan ja opetuksen tukipalveluiden yhteisen ytimen muodostavat tietovarannot, jotka sisältävät yhteisesti määriteltyä ja yhteisesti käytettävissä olevaa tietoa. Tietovarannot yhdistävät eri KA-tasoja ja toimijoita. Tietovarannot ovat erillinen kerros, joka eroaa sovelluksista, käyttöliittymistä ja järjestelmäpalveluista eli kyseessä eivät ole yhteisiä tietoja sisältävät yhteiset sovellukset joita kaikki käyttävät (kuten yhteiset rekisterijärjestelmät) vaan kyseessä on tallennettu tieto, jota erikseen toteutetut tietojärjestelmät voivat rajapintojen avulla käyttää. 

Mitä tämä tarkoittaa esim. Winhan käytön kannalta?

• Winhaa käytetään eri organisaatioissa eri tavoin. Esimerkiksi suoritusten kirjauskäytänteet yms. eroavat toisistaan. Tämäntyyppisissä tapauksissa kirjauskäytänteitä tarpeen yhtenäistää esimerkiksi määrittelemällä minkälaisen statuksen omaava suoritus katsotaan olevan "siirtokelpoinen" oletettuun suoritusrekisteriin tietovarannossa.
• Koodistoja yhtenäistettävä. Mieluiten erilaisilla koodistoilla tulisi olla valtakunnalliset starndardit, jotta mahdollisilta päällekkäisyyksiltä ja ristiriidoilta vältytään keskitetyssä tietovarannossa.

Mitä pitäisi selventää tai muuttaa?

• Ylipäätään viestintää ja siinä käytettävää terminologiaa korkekoulukentän suuntaan tulisi selkiyttää siten, että "normaali" ihminen ymmärtäisi mistä puhutaan. Esimerkiksi keskitetty tietovaranto joissain tapauksessa mielletään edelleen yhteiseksi perusrekisteriksi, perusjärjestelmäksi yms.

Mikä periaatteessa on hyvää / mahdollisuus?

• Se, että tietoa käsitellään ja hallitaan edelleen korkekoulun perusrekisterissä on hyvä asia. Tietovaranto voi myös palvella korkeakoulun perusrekisteriä monella tavoin. Esimerkiksi VRK:n tietojen käyttö tietovarannossa voisi palvella korkekoulujen perusrekistereitä tuottamalla mm. ajantasaista tietoa opiskelijoiden osoitetiedoista. Toisin sanoen tiedon tulisi liikkua kahteen suuntaan korkekoulun perusrekisterin ja keskitetyn tietovarannon välillä.
• Osa viranomaisraportoinnista ja tiedonkeruusta saataisiin siirtymään keskitettyyn tietovarantoon.

Mikä periaatteessa on huonoa / uhka

• Tietosuoja/tietojen käyttöoikeudet määriteltävä huolellisesti
• Virheellisen tiedon korjaus ei saa tapahtua korkeakoulun näkökulmasta kahdessa paikassa
• Yleinen huoli esim. suoritustietoa siirrettäessä siitä, miten nämä tiedot saadaan yhteismitallisesti tietovarantoon.

Periaate nro 4: Kokonaisuuden hallinta

• Arkkitehtuuri- ja integraatiotason kontrolli halutaan säilyttää ”in house”. Opiskelun ja opetuksen tukipalvelut koostuvat useista eri palveluista, joiden omistajat saattavat olla eri kokonaisarkkitehtuurien tasoilla (esim. väestötietojärjestelmä, OKM, OPH, korkeakoulujen yhteistyö, korkeakoulu). Korkeakoulun tukipalveluiden kokonaisuus muodostuu rakentamalla, hankkimalla, käyttämällä tarjolla olevia palveluita ja kokoamalla palveluista kokonaisuuksia. Kokonaisarkkitehtuurinäkemys on palvelukeskeinen (SOA) tässä ja sidosarkkitehtuureissa, mikä tarkoittaa, että sama asia pyritään hoitamaan yhdellä ratkaisulla. 

Yleistä keskustelua:

• Arkkitehtuuriperusteita on hankala käsitellä irrallisina.
• Samat asiat tuntuivat sekä mahdollisuuksilta että uhilta. Tämä riippui paljon näkökulmasta.
• Winha koetaan tällä hetkellä kohtuullisen suljetuksi ”monoliittiksi”
  • Sillä tehdään paljon asioita kuten mm. henkilöstöhallintoa sekä käyttäjähallintoa.
  • Tietoja saadaan Winhasta kohtuullisesti ulos, mutta tietoja ei saada helposti sisälle

 Nähtyä hyviä asioita tai mahdollisuuksia:

• Vanhaa ja toimivaa ei tarvitse poistaa käytöstä vaan voidaan helposti ottaa mukaan uusia osia.
• Korkeakoulut voivat edetä omien prosessiensa suuntaan (nähtiin myös huonona)
  • Mahdollisuus toteuttaa käyttäjiä paremmin tukevia palveluita
• Nyt ongelmana on, että samaa tietoa syötetään useampaan järjestelmään, koska eri palat eivät keskustele keskenään. Tästä aiheutuu paljon päällekkäistä työtä. Integraatioiden olemassaolo helpottaisi tilannetta.
• Hyvä mahdollisuus kehittää Winhaa eteenpäin mm. yhtenäisten tietomallien mukaiseksi.
• Nykytilassa toimittajalla on paljon valtaa ja vastuuta arkkitehtuurien ja integraatiotason osalta.

 Nähtyjä huonoja asioita tai uhkia

• Korkeakoulut ovat menossa omaan suuntaansa ja tämä aiheuttaa paljon räätälöintiä
• Tietojärjestelmä ei välttämättä vastaa käyttäjien tarpeisiin, mikäli asia toteutuu huonosti.
• Nykyisin kahdenkymmenen korkeakoulun yhteinen voima antaa parempia mahdollisuuksia vaikuttaa. Tämän vuoksi tulevaisuudessakin kannattaa tehdä tiivistä yhteistyötä korkeakoulujen välillä.
• Tietohallinto osaaminen on nykyisellään ulkoistettu, joten omasta organisaatiosta puuttuu asiantuntemusta hallita ja kehittää tätä kokonaisuutta. Kokonaisuuden rakentaminen voi aiheuttaa osaamistarpeen kasvun, mutta tulevaisuudessakaan ei haluta ostaa kaikkea osaamista korkeakouluun.
• Maailma kuulostaisi aika kaoottiselle, jos järjestelmä toimittajia olisi 10 kappaletta. Tämän vuoksi yhteensopivuuden on oltava hyvä. Tästä heräsi kysymyksinä seuraavia:
  • Miten kaikki palaset sopisivat toisiinsa?
  • Miten kaikki palaset pysyisivät ajan tasalla?

Periaate nro 5: Asteittain korkeakoulukohtaisesti

• Siirtymä kohti tavoitetilaa on asteittainen, korkeakoulukohtainen ja ”modulaarinen”. Korkeakoulu päättää toimintansa tarpeiden ja nykyisten tietojärjestelmiensä pohjalta, mitä tietojärjestelmiä ja miten ne yhdessä tai erikseen tuottavat ja ottavat käyttöönsä. Palveluita varten käytetään ja tuotetaan sovelluksia, käyttöliittymiä, järjestelmäpalveluita jne. Palveluiden käyttämiseksi ja toteuttamiseksi korkeakoulu muodostaa tarpeelliset yhteenliittymät, konsortiot, verkostot, osakeyhtiöt ym. 

- Mitä tämä tarkoittaa esim. Winhan käytön kannalta?

Uusia palveluja, ja Winhan käyttö supistuu (nyt Winha toimii HR:nä, toiminnansuunnittelujärjestelmänä, raportointijärjestelmänä). Winhan arkkitehtuuri uudistuu.
Osa Winha-korkeakouluista on jäänyt kehitystyöstä ulkopuolelle.
Winha-Korkeakoulut kehittävät aktiivisesti palveluja yhdessä.

- Mitä pitäisi selventää tai muuttaa?

Ainakin useissa ammattikorkeakouluissa on se käsitys, että uusi perusrekisteri eli se uusi Winha on tulossa tämän RAKETTI-hankkeen kautta.

- Mikä periaatteessa on hyvää / mahdollisuus?

Tietojärjestelmät ovat palvelupohjaisia ja niiden moduulit joustavasti vaihdettavissa tarvittaessa.
Korkeakoulut päättävät itse mitä palveluja ja missä määrin sekä miten niitä yhdistetään.
Yhteinen sopimus, mitä tietoa tuotetaan missäkin palvelussa. 
Ratkaisut noudattavat standardeja. Modulaarisuus on tärkeä, samoin moduulien vaihdettavuus ja siirrettävyys.

- Mikä periaatteessa on huonoa / uhka?

Palvelukeskeinen arkkitehtuuri ei ole tuttua ja monet rakentavat omia järjestelmiään melko itsenäisesti.
Tieto ei välttämättä ole yhteismitallista. Yhteinen järjestelmä ei poista sitä ongelmaa, että tiedot kirjattaisiin samalla tavalla. Jokaisella on omia tulkintoja ohjeista.
Palvelujen täytyy olla niin hyviä ja käytettäviä, että korkeakoulut ottavat ne käyttöön. Nyt moni korkeakoulu on tehnyt mittavia järjestelmähankintoja, joihin liittyy kalliita/räätälöityjä palveluita. Voi olla erittäin suuri kynnys ottaa käyttöön jokin kansallisesti tuotettu palvelu, kun juuri on otettu käyttöön kalliilla tuotettu/ostettu palvelu omassa korkeakoulussa. Miten palvelu saadaan myytyä korkeakouluille?

- Tarvitseeko periaate rinnalleen joitain tiettyjä muita periaatteita?

EOS.

Periaate nro 6: Yhteiset alemman tason palvelut

• Yhteiset toimintaa tukevat palvelut keskeisille tiedoille (esim. opiskelijat, suoritukset, opetustarjonta jne.), mikä tarkoittaa, että yhteisen ytimen muodostavilla tietovarannoilla on rajapinnat (atomiset tiedot) ja näitä käsittelemään on yhteisiä alemman tason palveluita (esim. suoritusten esittäminen tai tallentaminen; opiskeluoikeuden lukeminen tai lisääminen). Erillisiä ratkaisuja tuotetaan erityistarpeisiin (kuten kansainväliseen opiskelijavaihtoon liittyviin palveluihin). Loppukäyttäjän palvelut kootaan ja toteutetaan korkeakoulun strategisten valintojen mukaan korkeakoulukohtaisesti. 

Tällä hetkellä käytössä eri opiskelijahallintojärjestelmiä

• Yhteiset palvelut olisi hyvä asia, jos ne saataisiin rakennettua eri opiskelijahallintojärjestelmien päälle.
• Tällä hetkellä tietoja joudutaan ottamaan eri järjestelmistä ja tietojen saaminen näistä järjestelmistä yhteiseen yhteen "paikkaan" (raporttiin tai käyttöliittymään) hankalaa
• Periaatetta tulisi selkeyttää niin, että sen ymmärtää helpommin esimerkiksi konkreettisen esimerkin kautta.
• Eri järjestelmissä tulisi olla rajapintoja
• Tietomallit tulisi olla yhteneväisiä
• Kansallisten tietovarantojen käyttäminen?
  • Paremmin lausua ylös, että kansallisia tietovarantoja tulisi hyödyntää
  • Master data - > Tulisiko tähän pyrkiä vai onko tämä korkeakoulujen itse päätettävä asia?
• Miten päästään eri perusrekisterien osalta samoihin tietomalleihin. Viimeistään yhteisissä tietovarannoissa tietomalli tulee olla samanlainen
• Tietovarannon odottaminen suhteessa TIPTOP:n etenemiseen.

Kysymyksiä

Periaate nro 1
- Tarkoittaako ensimmäine periaate sitä, että OKM vastaa tietojen yhteimitoittamisesta. Jos korkeakouluilla on joku rooli tai vastuu tämän asian suhteen, niin sitä tulisi lauseessa tarkentaa

Periaate nro 2
- Kumoaako toinen periaate ensimmäisen (ks. edellinen lause).

- Uusi yhteinen perusrekisteri olisi toivottavaa, jolla yhteistyöhönö liittyvät nykyiset haasteet saataisiin varmasti ratkaistua.

Liitteet