IT-arkkitehtuuri tuo kaaokseen järjestyksen – miksi kokonaisuus on syytä pitää aina mielessä

Yrityksillä on nykyisin käytössään lukuisia tietoteknisiä ratkaisuja, kuten järjestelmiä ja sovelluksia. Yhdessä ne muodostavat kokonaisuuden, jota kutsutaan IT-arkkitehtuuriksi. Tämän kokonaisuuden hahmottaminen on liiketoimintaa kehitettäessä erityisen tärkeää, mutta jää usein liian vähälle huomiolle. 

Haastattelu: Jaakko Koivisto

Lataa tästä Biit Fiid Winter ’21 Release kokonaan (.pdf)

Kuvittele, että sinulla on maalla pieni mummonmökki, jota lähdet parantelemaan. Haluat mökkiin sähköt ja lämmityksen sekä lisää elintilaa.

Mitä enemmän haluat mökkiä parantaa ja laajentaa, sitä tärkeämmäksi kokonaisuuden hahmottaminen ja järkevien valintojen tekeminen nousevat. Jos sähkön saaminen on välttämätöntä, kannattaisiko sähköverkkoon liittymisen sijaan harkita aurinkopaneelia ja kenties säästää samalla tuhansia euroja?

Jatketaanpa ajatusleikkiä mummonmökistä hieman pidemmälle. Olet jatkanut mökin tuunaamista kymmenien vuosien ajan ilman selkeää suunnitelmaa. Sinulla on nyt monikerroksinen rakennus, jossa ei ole edes portaita. Talon eri kerroksiin pääsee vain ulkoseinää pitkin kiipeämällä. Lisäksi talossa on useiden valintojen seurauksena valtava määrä pieniä vikoja, joiden korjaaminen vaatii jatkuvaa remontoimista.

Asiansa osaava arkkitehti ei olisi koskaan päästänyt sinua tähän pisteeseen.

Voimme ajatella, että organisaation tietotekniset ratkaisut muodostavat rakennuksen kaltaisen kokonaisuuden, jolloin IT-arkkitehtuurin avulla varmistetaan, että kokonaisuus säilyy eheänä silloinkin, kun nykyisiä ratkaisuja kehitetään tai otetaan käyttöön kokonaan uusia tietojärjestelmiä. IT-arkkitehdin tehtävänä on varmistaa, että suunnitellut ratkaisut ovat järkeviä, teknisesti toteuttamiskelpoisia ja kustannustehokkaita.

IT-arkkitehtuuri saattaa kuulostaa monen mielestä hankalalta, tekniseltä ja monimutkaiselta asialta, mutta todellisuudessa kyse on helposti ymmärrettävästä kokonaisuudesta, joka jää usein aivan liian vähälle huomiolle. IT-arkkitehtuurin laiminlyönnin seurauksena voi esimerkiksi joutua rakentamaan eri järjestelmien välille useita kalliita integraatioita, joilta oltaisiin säästytty paremmalla suunnittelulla.

Kokonaisuus aina mielessä

Biitillä arkkitehteinä toimivat Jesse Julkunen ja Mikko Cavenius ovat vakaasti sitä mieltä, että IT-arkkitehtuuri on asia, jota pitäisi miettiä aina järjestelmiä hankittaessa ja kehitettäessä.

”Kaikkien ei tarvitse tuntea oman organisaationsa IT-arkkitehtuuria, mutta jonkun olisi hyvä olla siitä perillä.”

– Kaikkien ei tarvitse tuntea oman organisaationsa IT-arkkitehtuuria, mutta jonkun olisi hyvä olla siitä perillä. Jos yrityksellä ei ole omaa arkkitehtia, niin kehitysprojektien yhteydessä kumppaneilta pitäisi löytyä myös tämän puolen osaamista. Jos kumppanit ainoastaan toimittavat yksittäisiä ratkaisuja, mutta kukaan ei hahmota kokonaisuutta, niin tuloksena on usein siiloutumista ja tehottomuutta, Julkunen kertoo.

Entä mistä IT-arkkitehtuurissa on ammattilaisen silmin kyse? Arkkitehtina monenlaisten asiakkaiden parissa työskentelevä Julkunen korostaa, että arkkitehdin on aina ymmärrettävä, kenen kanssa hän asioista milloinkin puhuu. Kaikki eivät nimittäin tarkastele asioita samoista lähtökohdista.

– IT-arkkitehtuuri tarkoittaa eri ihmisille eri asioita. Vähemmän teknisille ihmisille se tarkoittaa useimmiten sitä, miten organisaation käyttämät järjestelmät keskustelevat keskenään ja missä liiketoiminnan kannalta kriittinen master data sijaitsee. Teknisemmille henkilöille IT-arkkitehtuuri tarkoittaa hyvinkin syvälle meneviä asioita, kuten järjestelmien tietoturvaa. Yksinkertaistettuna kyse on kuitenkin kokonaisuuden hahmottamisesta, Julkunen tiivistää.

Eroon siiloista ja roolijaoista

Cavenius kertoo, että tämän yrityksen käyttämien tietoteknisten ratkaisujen muodostaman kokonaisuuden hahmottaminen jää usein liian vähälle huomiolle, sillä organisaatioiden sisällä ihmisten roolit ovat liian tiukasti määriteltyjä ja toiminta siiloutunutta. IT-infrastruktuurin hallinta saattaa olla kaukana organisaation kehitystoiminnasta. 

– Muutos, jota kaipaisin on, että tiukoista roolijaoista luovuttaisiin. Liiketoimintapäättäjät ja IT-osaajat olisi tuotava lähemmäs toisiaan, jolloin IT:tä ei myöskään nähtäisi niinkään kuluna, vaan liiketoiminnan mahdollistajana. Nykymaailmassa IT ei ole pelkästään teknologiaa, vaan ennen kaikkea liiketoiminnan tukemista, Cavenius esittää.

Hieman kärjistäen tilanne on pahimmillaan sellainen, ettei vasen käsi tiedä, mitä oikea käsi tekee. Bisnespuoli ymmärtää kaiken liiketoiminnasta ja sen tarpeista, mutta ei tunne yrityksen käyttämiä tietojärjestelmiä eikä niiden asettamia reunaehtoja tai mahdollisuuksia lainkaan, kun taas IT-osasto ei välttämättä ymmärrä liiketoimintaa riittävästi.

”Pahimmillaan voidaan päätyä esimerkiksi rakentamaan uusi järjestelmä, vaikka saman bisnestarpeen olisi voinut täyttää vanhaa järjestelmää täydentämällä.”

– Kuten Cavenius tuossa totesi, niin IT ja bisnes ovat usein liian kaukana toisistaan. Monesti ollaan esimerkiksi hankkimassa jotain järjestelmää tai softaa, joka täyttää jonkin tietyn liiketoiminnan tarpeen, mutta ei mietitä, miten se istuu kokonaisuuteen. Pahimmillaan voidaan päätyä esimerkiksi rakentamaan uusi järjestelmä, vaikka saman bisnestarpeen olisi voinut täyttää vanhaa järjestelmää täydentämällä. Toisinaan eri järjestelmien välille joudutaan myös rakentamaan useita integraatioita, joilta oltaisiin vältytty paremmalla suunnittelulla, Julkunen kertoo.

Julkunen kertoo, että nykyisessä roolissaan häneltä toivotaan asiakkaiden suunnalta usein ajatuksia siitä, mitä järjestelmiä Salesforcella voitaisiin korvata. Asiakkaat eivät halua maksaa tuplalisensseistä, joten yhdellä järjestelmällä halutaan taklata mahdollisimman monia haasteita. Se on IT-arkkitehdin päivätyötä.

– Uusi asiakas ei yleensä tiedä, mitä kaikkea Salesforcella pystytään tekemään, sillä he mieltävät sen usein pelkäksi CRM-järjestelmäksi. Tällaisessa tilanteessa lähdemme yhdessä tutkimaan heidän olemassa olevaa arkkitehtuuria ja miettimään, mitä kaikkea uudella järjestelmällä voitaisiin korvata. Tiedämme myös, milloin asiakas tarvitsee jotain räätälöityä ratkaisua.

Ei vain suuryritysten asia

IT-arkkitehtuuri saattaa kuulostaa mahtipontiselta asialta, joka koskettaa vain isoja ja monimutkaisia organisaatioita. Julkunen ampuu tämän ajatuksen heti alas.

”Väittäisin, että IT-arkkitehtuurista huolehtiminen on jopa pienille organisaatioille tärkeämpää, koska niillä ei useinkaan ole varaa siihen, että järjestelmät tekevät päällekkäisiä asioita.”

– Väittäisin, että IT-arkkitehtuurista huolehtiminen on jopa pienille organisaatioille tärkeämpää, koska niillä ei useinkaan ole varaa siihen, että järjestelmät tekevät päällekkäisiä asioita. On myös syytä huomioida, että järjestelmien on oltava skaalautuvia ja muuntautumiskykyisiä – ja tämä siis koskettaa kaikenkokoisia yrityksiä. Jos esimerkiksi yrityksemme myy autoja, mutta yhtäkkiä kaikki haluavatkin ostamisen sijaan vuokrata niitä, myös järjestelmän on taivuttava tähän muutokseen, Julkunen kertoo.

IT-arkkitehtuurissa on siis kyse paitsi nykyhetken ymmärtämisestä, myös tulevaisuuteen varautumisesta. Julkunen kertoo esimerkin hänelle varsin tutusta verkkokauppamaailmasta. Verkkokaupan liikenne saattaa olla tasaista, mutta ampaista yhtäkkiä jyrkkään kasvuun. Voi myös olla, että tietyt ajankohdat, kuten Black Friday tai joulu saattavat aiheuttaa vierailijamäärissä piikkejä.

– Jos järjestelmiä suunniteltaessa ei ole mietitty arkkitehtuuria, on nopeisiin muutoksiin vastaaminen hankalaa. On esimerkiksi arkkitehtuurinen päätös maksaa skaalautuvasta SaaS-palvelusta, joka perustuu käyttäjävolyymeihin. Tällöin voidaan yhtä lailla palvella tuhatta tai miljoonaa käyttäjää, eivätkä yksittäiset piikit aiheuta ongelmia.

Milloin tarvetta kunnostamiselle?

Hyvin rakennettu IT-arkkitehtuuri on kuin öljytty ratas, joka saa pyörän rullaamaan sulavasti. Mistä sitten voi tunnistaa, että organisaation IT-arkkitehtuuri olisi syytä laittaa kuntoon?

”Jos yleisimmin käytetty tieto löytyy seitsemän painalluksen jälkeen, niin ratkaisuarkkitehdille olisi varmasti käyttöä.”

– Asiaa voi tarkastella monelta eri kantilta. Data-arkkitehtuurin osalta on varmasti jotain parannettavaa, jos tieto on pirstaloitunutta ja sitä joutuu käyttäjänä kaivelemaan monesta eri paikasta. Bisnesarkkitehtuurin osalta parantamisen varaa on silloin, jos bisnesprosessit ovat hankalia – esimerkiksi asiakkaalle on hankalaa luoda uusi tarjous. Asiaa voi lähestyä myös ratkaisuarkkitehtuurin osalta, eli käytettävyyden näkökulmasta. Kuinka monta kertaa joudun painamaan hiiren painiketta päästäkseni haluttuun tietoon käsiksi? Jos yleisimmin käytetty tieto löytyy seitsemän painalluksen jälkeen, niin ratkaisuarkkitehdille olisi varmasti käyttöä, Julkunen kertoo.

Julkusen esimerkki avaa hyvin erästä IT-arkkitehtuurin kannalta erittäin oleellista seikkaa. Se koskettaa organisaatiossa kaikkia, jotka joutuvat järjestelmiä käyttämään. Loppukäyttäjät kyllä huomaavat, jos kokonaisuus ei toimi.

– Järjestelmiä kehitettäessä mietitään kyllä aina asiakkaita, mutta entä firman sisäiset käyttäjät? Järjestelmien on vastattava myös heidän tarpeisiin, Cavenius muistuttaa.

Piirustukset yhteisenä pohjana 

Moni saattaa yhdistää arkkitehtuurin kauniiden piirrosten ja näyttävien mallien luomiseen. Piirtävätkö myös IT-arkkitehdit hienoja kuvia?

– Kyllähän me piirrämme! Usein projekti asiakkaan kanssa alkaa siitä, että heidän IT-arkkitehtuurista piirretään ajantasainen kuva, joka helpottaa asioista keskustelemista ja oikeisiin asioihin keskittymistä. Joskus toki asiakkaalla on jo tällainen kuva olemassa, Julkunen päättää.

Loppuun Julkunen ja Cavenius esittävät vielä kertauksen omaisesti muutamia asioita, joita jokaisen olisi hyvä IT-arkkitehtuurista tietää:

1. Sitä ei kannata pelätä. Se on hyvinkin looginen ja ymmärrettävä kokonaisuus.
2. On hyvä ymmärtää, että järjestelmät muodostavat kokonaisuuden, jonka palaset vaikuttavat toisiinsa.
3. IT-arkkitehtuurista huolehtiminen onnistuu parhaiten silloin, kun kehitystyöhön otetaan mukaan niin bisnes, IT kuin loppukäyttäjätkin. Kaikilla on omat tärkeät näkökulmat asioihin. 
4. Toimiva IT-arkkitehtuuri mahdollistaa nopeat muutokset ja on helposti skaalattavissa.
5. Siihen kuuluu useita eri kerroksia, joita ei tarvitse tuntea syvällisesti. Usein riittää, että tietää käyttämiensä järjestelmien nimet sekä sen, mihin niitä käytetään.

Määritelmiä

Data-arkkitehtuuri. Osa yrityksen kokonaisarkkitehtuuria. Kuvaa sitä, miten data organisaation sisällä liikkuu. Data-arkkitehtuuri keskittyy datan rakenteisiin sekä niiden tarkempaan kuvaukseen.

IT-arkkitehtuuri. Tarkastelee organisaation käyttämien tietoteknisten ratkaisujen muodostamaa kokonaisuutta. IT-arkkitehtuurin avulla tarkastellaan esimerkiksi sitä, miten eri järjestelmät keskustelevat toistensa kanssa sekä miten yksittäisten järjestelmien kehittäminen tai uusien järjestelmien hankinta vaikuttavat kokonaisuuteen.

Yritysarkkitehtuuri. Yritysarkkitehtuuri, enterprise architecture, kokonaisarkkitehtuuri tai bisnesarkkitehtuuri toimivat kattokäsitteenä kokonaisuudelle, joka tarkastelee yritystä kokonaisuutena ottaen huomioon muun muassa liiketoimintasuunnitelmat, organisaatiorakenteet, prosessit ja IT-infrastruktuurin.

Ratkaisuarkkitehtuuri. Ratkaisuarkkitehtuuri keskittyy etsimään mahdollisimman tehokkaita teknisiä ratkaisuja liiketoiminnan tarpeisiin. Ratkaisuarkkitehtuurilla voidaan esimerkiksi löytää keinoja tehostaa organisaation liiketoimintaprosesseja.

Service Blueprint. Palveluiden kehittäminen edellyttää selkeää käsitystä siitä, mitä ollaan tekemässä sekä asioiden tarkastelua asiakkaan näkökulmasta. Service Blueprint on työkalu, jolla kehitettävä palvelu pystytään kuvaamaan yksityiskohtaisesti prosessikaavion muodossa.