Edellisessä artikkelissamme käsittelimme korkeakoulujen hiljaista elinkaaririskiä ja sitkeitä haamuoikeuksia. Mutta mitä tapahtuu, kun tietohallinto tunnistaa ongelman, mutta kaksi vuosikymmentä palvellut, talon sisällä mahdollisesti koodattu identiteetinhallintajärjestelmä on tullut tiensä päähän ja sen ainoa syvällinen asiantuntija ilmoittaa eläköitymisestään?
Korkeakouluissa saattaa olla tunnistettu tarve IAM-järjestelmän (Identity and Access Management) uudistamiselle, mutta kynnys muutokseen voi olla korkea. Huoli siitä, että kriittisen taustajärjestelmän korvaaminen voisi häiritä opiskelijoiden ja henkilökunnan kirjautumisia kesken kiireisimmän lukukauden, voi hidastaa päätöksentekoa. Järjestelmän modernisointi ei kuitenkaan vaadi kaiken räjäyttämistä kerralla, vaan se voidaan toteuttaa vaiheittain, jatkuvuus suunnitellen ja palvelukatkojen riskiä minimoiden.
Miksi vanhan IAM-järjestelmän uudistamisen kynnys voi olla korkea?
Vanhan järjestelmän korvaaminen voi herättää huolta, sillä vuosien aikana kertyneet tietokantarakenteet, järjestelmäkohtaiset mukautukset ja dokumentoimaton hiljainen tieto saattavat tehdä järjestelmän vaihtamisesta haastavaa. Muutokseen voi liittyä riskejä myös palveluiden jatkuvuuden kannalta.
Korkeakoulujen omat järjestelmät ovat saattaneet vuosien mittaan muodostua monimutkaisiksi kokonaisuuksiksi, joissa tieto kulkee useiden tietokantarakenteiden ja erillissovellusten kautta. Tällaiset riippuvuudet voivat vaikeuttaa kokonaisuuden hahmottamista ja lisätä järjestelmän uudistamiseen liittyvää epävarmuutta. Prosessit voivat nojata erillisiin työkaluihin tai vaatia edelleen runsaasti manuaalityötä opetushenkilökunnan ja opiskelijoiden roolilogiikan pyörittämiseen.
Suurin huoli liittyy jatkuvuuteen: miten siirtyä uuteen arkkitehtuuriin tiukassa aikataulussa siten, ettei yksikään kriittinen käyttöoikeus katkea? Kun vanhan järjestelmän yksityiskohdat ovat harvojen avainhenkilöiden muistin varassa, voi kerralla tehtävä siirtymä tuntua tietohallinnolle liian suurelta riskiltä.
Miten vaiheittainen rinnakkaisajo suojaa toiminnan jatkuvuutta?
Hallittu siirtymä toteutetaan irrottamalla järjestelmäkytkennät vaiheittain ja ajamalla uutta alustaa vanhan rinnalta, tavoitteena on pitää muutosten vaikutukset käyttäjille mahdollisimman vähäisinä.
Vanhaa järjestelmää ei tarvitse sammuttaa kerralla. Kansainväliset korkeakouluesimerkit osoittavat, että yksi hallitun siirtymän toimiva tapa on rakentaa uusi IAM-alusta rinnalle ja siirtää integraatioita uuden arkkitehtuurin piiriin asteittain. Rinnakkaiskäyttö edellyttää kuitenkin ehdottoman selkeää kirjoitusvastuuta: vanha ja uusi järjestelmä eivät saa tehdä ristiriitaisia muutoksia samoihin tileihin tai oikeuksiin.
Ensimmäisessä vaiheessa uusi alusta kytketään kriittisiin lähdejärjestelmiin – kuten HR- ja opintotietojärjestelmiin. Vanhoista järjestelmistä tietoa tuodaan kunkin ympäristön sallimilla rajapinnoilla, ja korrelaatio sekä tilien linkitys mahdollistavat olemassa olevien tilien liittämisen identiteetteihin ilman tuotantodatan rikkomista. Kohdejärjestelmien hallinta siirretään uudelle alustalle vaiheittain, ja palveluiden jatkuvuus varmistetaan kattavalla testauksella, sovituilla hyväksymiskriteereillä ja selkeällä palautumissuunnitelmalla.
Miten muutosriskejä ja testausaikaa voidaan leikata ennen käyttöönottoon siirtymistä?
Muutosriskejä vähennetään ajamalla taustalla simulaatioita, joilla arvioidaan tilimuutosten ja käyttöoikeuksien odotettuja vaikutuksia ennen varsinaisten muutosten toteuttamista. Tämä sopii myös tuotantoympäristössä tehtävään vaikutusarviointiin.
Aiemmin mainitsemamme poistumistilanteiden ja sääntömuutosten esitestaus nousee kriittiseen rooliin vastaavissa järjestelmämuutoksissa. Perinteisesti järjestelmämuutosten testaaminen on vaatinut raskaat ja aikaa vievät rinnakkaisajot sekä arvailun siitä, miten sääntömuutokset vaikuttavat eri käyttäjäryhmiin. Nykyaikaisissa IGA-alustoissa simulaatiot helpottavat vaikutusten arviointia ja auttavat kohdistamaan varsinaisen testauksen kriittisiin tilanteisiin.
Simulaation avulla tietohallinto voi testata sääntömuutoksia, poikkeustilanteita, roolipäivityksiä sekä tunnusten sulkemisia turvallisesti etukäteen. Simulaatio laskee ja raportoi valittujen sääntöjen vaikutukset ilman varsinaisten identiteetti- ja kohdejärjestelmämuutosten toteuttamista.
Simulaatio vähentää epävarmuutta merkittävästi ja voi nopeuttaa projektin läpivientiä, mutta on tärkeää muistaa, ettei se korvaa integraatio-, suorituskyky- tai hyväksymistestausta. Lisäksi vaikutusarvio rajautuu simulaatiossa käytettyyn aineistoon, tehtävään ja konfiguraatioon. Siksi aineiston ajantasaisuus, kattavuus ja poikkeustilanteiden huomiointi ovat olennaisia.
Miten korkeakoulu saa modernisoinnista tuloksia nopeasti ilman vuosien projektisuota?
Nopeita tuloksia saavutetaan etenemällä vaiheittain, aluksi kytketään kriittiset järjestelmät, siivotaan data ja automatisoidaan elinkaariprosessit. Modernisointihankkeen ei tarvitse kestää vuosia.
Asiantuntijoidemme hyväksi havaitussa kolmen askeleen etenemismallissa keskitytään ensin perustan rakentamiseen:
- Kytketään järjestelmät: Tiedon omistajuus ja yhdistämisen periaatteet sekä MVP-rajauksella (Minimum Viable Product) eli ensimmäiseen vaiheeseen valittavalla pienimmällä toimivalla kokonaisuudella määriteltävät järjestelmät ja toiminnot sovitaan ennen kuin rakennetaan tietoja kohdejärjestelmissä muuttavia integraatioita.
- Siivotaan data: Tunnistetaan ja oikaistaan unohdetut identiteetit. On ensiarvoisen tärkeää muistaa, että päällekkäisiä identiteettejä ei tule yhdistää ilman luotettavaa ja varmistettua tunnistusta.
- Automatisoidaan elinkaari: Otetaan käyttöön automaattiset Joiner–Mover–Leaver (JML) prosessit eli toimintamallit, joilla hallitaan käyttäjätunnusten ja käyttöoikeuksien muutoksia henkilön aloittaessa, vaihtaessa roolia tai päättäessä opiskelu tai työsuhteensa. Samalla huomioidaan henkilön rinnakkaiset opiskelu-, työ- ja muut suhteet: yhden suhteen päättyminen ei saa poistaa oikeuksia, joille on edelleen toinen voimassa oleva peruste.
Projektin onnistumisen kannalta on kriittistä, että valittu teknologia mukautuu korkeakoulun omiin opintoprosesseihin ja akateemisiin sääntöihin. Kun järjestelmä tarjoaa valmiit konfigurointimahdollisuudet ja taitavan kumppaniverkoston tuen, tietohallinto voi ottaa vaiheittain käyttöönsä kestävän, koodausriippuvuutta vähentävän ja tietoturvallisen identiteetinhallinnan. Konfiguroitavuus vähentää erillisen sovelluskehityksen tarvetta, mutta edellyttää silti vahvaa IGA-osaamista ja huolellisesti testattuja sääntöjä.
Miten järjestelmän ylläpito ja jatkuva kehitys järjestetään ilman oman ohjelmistotalon perustamista?
Pohditteko, riittävätkö organisaationne resurssit ja osaaminen joustavan IAM-alustan jatkuvaan kehitykseen tuotantoon viennin jälkeen? Hallittu arkkitehtuuri minimoi siirtymävaiheen riskejä, mutta pitkällä aikavälillä ratkaisevaa on operatiivisen ylläpidon laatu. Lue sarjan seuraavassa osassa, miten IGA-ratkaisun pitkäaikainen jatkuvuus turvataan ilman oman ohjelmistotalon perustamista.