Uuden tietojärjestelmän hankkiminen tai rakentaminen on aina suuri ja monitahoinen asia. Ainakin silloin, kun on ensimmäistä kertaa johtamassa sitä. Eikä se ole helppoa seuraavillakaan kerroilla. Organisaation johto odottaa strategiaa tukevia parannuksia ja järjestelmäsuunnittelijat odottavat innolla parannusten suunnittelua. Käyttäjät kyselevät, miten tämä vaikuttaa jokapäiväiseen toimintaan. Hankejohtajan pitäisi pystyä ohjaamaan työtä kaikista näkökulmista. Tuntuu siltä kuin toimistoon olisi muuttanut norsu keskelle käytävää seisoskelemaan. Jostain pitäisi aloittaa, mutta mistä?
Eihän siinä muu auta, kuin lopulta tarttua härkää sarvista – tai norsua korvista – ja ryhtyä tuumasta toimeen. Pala palalta. Siivu kerrallaan.
Kokonaisarkkitehtuuri ja näkökulmat jäsentävät tekemistä
Kokonaisarkkitehtuurin avulla hanke voidaan sitoa strategisiin tavoitteisiin ja jakaa pienempiin hallittaviin osiin. Kokonaisarkkitehtuurikehyksen kerroksittain tarkentuva lähestymistapa tarjoaa hallitun mallin siitä, kuinka ratkaisu ja komponentit tarkentuvat suunnittelun ja toteutuksen edetessä.
Arkkitehtuurinäkökulman lisäksi on huomioitava myös muut näkökulmat: palvelut, vaatimukset ja projektointi. Palvelunäkökulma määrittää uuden tietojärjestelmän tarjoaman palvelukokonaisuuden, vaatimusnäkökulma määrittää palvelujen ja arkkitehtuurin ominaisuudet sekä rajoitteet. Projektointinäkökulma puolestaan määrittää työn organisointi- ja resursointimallin.
Näkökulmista ja kerroksista muodostuu matriisi, jonka jokainen rivi vastaa yhtä abstraktiotasoa ja jokainen sarake yhtä näkökulmaa. Oleellista on, että kutakin kerrosta ja näkökulmaa voidaan hallita itsenäisesti kun ne samaan aikaan ovat linkittyneet keskenään. Kerroksittainen lähestymistapa auttaa eri näkökulmien välistä keskustelua ja määrittelyjä pysymään samalla abstraktiotasolla. Esimerkiksi ratkaisuarkkitehtuurin tasolla tehdään vaatimusmäärittelyä epiikkien, ominaisuuksien ja rajoitteiden avulla tietojärjestelmäpalveluille, jotka toteutetaan projekteissa. Vasta seuraavalla tasolla(tietojärjestelmäarkkitehtuuri) vaatimusmäärittelyt ovat käyttäjätarinoiden muodossa ja kohdistuvat tietojärjestelmäkomponentteihin, joita tehdään osaprojekteissa.
Näkökulmista vaatimustenhallinta on keskeisessä roolissa. Se tarjoaa mekanismit eri näkökulmien ja kerrosten linkittämisessä hallittavaksi kokonaisuudeksi. Vaatimukset kohdistuvat oman tasonsa arkkitehtuurielementteihin ja kuvaavat millaisia palveluja niiden odotetaan tuottavan. Hankkeen, projektin ja osaprojektin työlista syntyy niille allokoiduista vaatimuksista. Myös suunnitelmiin tulevat muutokset voidaan tuoda hallitusti osaksi kokonaisuutta vaatimustenhallinnan kautta. Vaatimustenhallinta yhdessä arkkitehtuurin kanssa onkin oiva paikka aloittaa norsun palastelu.
Kullakin hankkeen sidosryhmällä on oma kieli
Yrityksen ylin johto puhuu sujuvasti palveluportfoliosta ja allokoi rahaa budjetista eri hankkeille toiminnan kehittämisen näkökulmasta. Samaan aikaan järjestelmäsuunnittelussa mietitään SOA -pohjaista ratkaisua ja Data Vaultien hyödyntämistä johdon raportoinnissa. Koodareiden puheissa vilisee Clojure, Angular, AWS ja monta muuta kryptistä sanaparia. Ei uskoisi, että kaikki puhuvat samasta asiasta. Ero johtuu eri kerrosten yksityiskohtien määrästä sekä kunkin toiminnallisen tason päätehtävistä. Ylimmällä tasolla yrityksen johto vastaa toiminnan kehittämisestä ja ohjauksesta sekä hankehallinnasta. Siinä yhteydessä yksittäiset tekniset ratkaisut eivät ole kiinnostavia – niissä luotetaan täysin tietojärjestelmätyön tekijöiden osaamiseen.
Järjestelmäsuunnittelutyössä keskitytään tietotekniseen kokonaisratkaisuun ja sen tarkempaan määrittelyyn. Järjestelmä määritellään arkkitehtuurin ja vaatimusmäärittelyn keinoin. Toteutustasolla ratkaistaan viimeisimmätkin tietotekniset yksityiskohdat ja lähdetään toteuttamaan tietojärjestelmäkomponentteja pala kerrallaan. Työn ohjaus tapahtuu osaprojekteissa käyttäjätarinoiden ja tehtävien avulla.
Käytännössä kokonaisarkkitehtuurikehyksen lähestymistapa luo oman hallintakerroksen kullekin hankkeen sidosryhmäjoukolle: johtajille, arkkitehdeille ja koodareille. Kun kerrokset tuodaan selkeästi esiin, on mahdollista luoda yhteinen sanasto, jonka avulla kaikki osapuolet tietävät minkä tasoista määrittelyä tarkoitetaan. Pelkän arkkitehtuurin sijaan puhutaan kokonaisarkkitehtuurista, kohdearkkitehtuurista, ratkaisuarkkitehtuurista ja tietojärjestelmäarkkitehtuurista. Palvelujen osalta erotellaan aina, onko kyse palveluportfoliosta, substanssipalvelusta, tietojärjestelmäpalvelusta vai yksittäisestä tietojärjestelmäkomponentista. Vastaavasti myös vaatimus- ja projektointinäkökulmasta määritellään tarkempi termistö.
Pala palalta siivu kerrallaan
Kun organisaatiolle on sovittu yhteinen näkökulmista ja kerroksista muodostuva matriisi, pilkotaan norsu sen mukaisesti: palastellaan näkökulmittain ja siivutetaan palat kokonaisarkkitehtuurikehyksen mukaisiin kerroksiin. Päätettäville asioille on nyt helpompi löytää omistaja ja erilaiset vastaukset alkavat vaikuttaa ymmärrettäviltä, kun ne sijoitetaan syntyneen matriisin mukaisiin lokeroihin.
Norsun pilkkominen tapahtuu yhteisesti sovitun, näkökulmista ja kerroksista muodostuvan matriisin mukaisesti: palastellaan näkökulmittain ja siivutetaan palat kokonaisarkkitehtuurin mukaisiin kerroksiin. Päätettäville asioille on nyt helpompi löytää omistaja ja erilaiset vastaukset alkavat vaikuttaa ymmärrettäviltä, kun ne sijoitetaan syntyneen matriisin mukaisiin lokeroihin.
Sitten ei tarvitakaan enää kuin se tukeva ote norsun korvista. Isokin järjestelmä näyttää pienemmältä kun sen ensin pilkkoo hallittaviin, toisiinsa kytkeytyviin osiin.
