Allekirjoitan toisaalta mitä kirjoitat, sillä noinhan se menee, ja laajempi konteksti on toki syytä ymmärtää. Onnistuneessa IAM-hankkeessa mennään aina EA:n tontille, esimerkiksi organisaatioon jalkautettavien yhteisten tietomallien ja standardien taholla jne.

Toisaalta taas, se syy miksi kirjoitan IAMista muutosjohtamisen kontekstissa on kaksijakoinen. Ensiksi triviaali syy, joka on se, että Trusteq keskittyy toiminnassaan IAM-hankkeisiin, joten viran puolesta on jonkin verran scoupattava tekemistä. Toisekseen tärkeämpi ja käytännöllisempi syy; Asiakasympäristöissä joissa olen työskennellyt lähes poikkeuksetta EA koetaan diplomaattisesti sanottuna “hieman erillisenä”. Sekä liiketoiminta, että ICT näkevät monesti kokonaisarkkitehtuurin ja siihen liittyvän tekemisen aika etäisenä asiana, koska tämä jalkautuu harvoin kovin paljon ICT- tai business tekemisen arkipäivään. Monet EA:n määrittelemät asiat jäävät käytännössä paperille, sillä koko yrityksen muutos on iso, hidas ja kallis juttu.

Minusta IAM poikkeaa tässä olennaisesti hankkeena ja on yksi niitä harvoja asioita firmoissa, joissa oikeasti saadaan aikaan koko organisaatiota koskevia muutoksia ja vieläpä niin, että nämä muutokset ovat linjassa määriteltyjen EA-standardien kanssa. Tietoturva ja spesifimmin käyttöoikeuksien määrämuotoinen hallinta toimivan käyttäjäidentiteettien hallinnan yhteydessä ovat asioita, joiden on yleensä vaan pakko toimia tai seurauksena on isoja ongelmia. Tästä johtuen tähän keskimäärin ollaan valmiimpia satsaamaan. Tästä syystä IAM on otollinen alue alkaa purkamaan kokonaisarkkitehtuurin solmuja.

Lisäksi identiteetinhallinnassa esimerkiksi tiedon looginen mallinnus on kohtuullisen paljon helpompaa kuin monen muun tietoalueen kanssa. Niinikään tiedon lähdejärjestelmiä on yleensä vähemmän (HR ja CRM tyypillisesti), eli hanke ei kompastu integraatiospagettiin heti ensimetreillä. Lisäksi matalalla roikkuvia hedelmiä, joista saa heti businesshyötyä on paljon ja business casejen laskenta on helpompaa. (Esim. Mitä maksaa yksi salasanan vaihtaminen jos sitä ei tehdä itsepalveluna vaan se tilataan hosting-toimittajalta?)

Yksi hyvän (muutos-)johtamisen tunnusmerkkejä on minusta, että osataan kertoa isojen linjojen ohella konkreettisia toimenpiteitä miten tavoitteeseen päästään. Siksi positioin mielessäni IAM-hankkeet muutosjohtamisen kannalta tärkeämmiksi kuin EA-tekemisen.

Ensiarvoisen tärkeää on ymmärtää MITÄ muutosta ollaan tekemässä ja MINNE muutoksella pyritään menemään. Muutos vaatii myös aikaa. Liikkuvaan maaliin ajaminen on muutosjohtamisessakin haasteellista.

IAM ei mielestäni ole “the thing” muutosjohtamisen konteksina, vaan kokonaisarkkitehtuuri (EA). Ilman mallinnettua tai ainakin tavoitteena olevaa kokonaisarkkitehtuurin framea en näe IAM tai IdM palvelulle menestymisen ennusmerkkejä.

Itseasiassa näen I** enemmänkin yhtenä käytännön esimerkkinä EA:n kyvystä integroida liiketoiminta ja ICT.