Blogi

Kokonaisarkkitehtuurin tavoitteena on yhdistää IT-kenttä vahvemmin yrityksen muuhun toimintaan

Julkaistu 10.05.2021 kirjoittaja Arter

Pohjimmiltaan kokonaisarkkitehtuurin tavoitteena on yhdistää IT-kenttä vahvemmin yrityksen muuhun toimintaan.

Kokonaisarkkitehtuurissa puhutaan kuitenkin, ainakin Suomessa, verrattain uudesta tavasta toimia. Tästä vakiintumattomuudesta johtuen erityyppiset organisaatiot saattavat erilaisten valintojen, linjausten tai kypsyystason vuoksi puhua siitä eri nimillä. Jotkut saattavat jopa vierastaa jotakin toista tapaa puhua asiasta.

Kokonaisarkkitehtuurin monet kasvot

Tämän blogin tavoitteena on löytää yhteistä tarttumapintaa eri termien välille ja selittää, miten kokonaisarkkitehtuurista on päädytty puhumaan useilla eri sanoilla.

👉 Kootusti saat tästä parhaiten tietoa Arterin kokonaisarkkitehtuurin pikaoppaasta.

Kokonaisarkkitehtuurista puhuttaessa nämä kuusi termiä toistuvat yleensä ihmisten puheissa:

kokonaisarkkitehtuuri,
yritysarkkitehtuuri,
Enterprise Architecture,
ratkaisuarkkitehtuuri,
Solution Architecture,
IT-arkkitehtuuri.

Kokonaisarkkitehtuuri

Ainakin me Arterilla olemme päätyneet puhumaan asiasta enimmäkseen tällä nimityksellä, kokonaisarkkitehtuurilla.

Kokonaisarkkitehtuuri on muuten hyvä, yleinenkin, termi, mutta monet mieltävät sen liittyvän vahvasti nimenomaan julkiseen hallintoon ja lakitekstiin. Sanaan liitetään usein julkisen hallinnon JHS 179 -viitekehys, 2011 voimaan astunut tietohallintolaki sekä 2019 voimaan astunut tiedonhallintalaki. Mahdollisesti näiden vuoksi monet yrityspäättäjät eivät samaistu termiin ja kokevat, että se ei liity heihin millään tavalla.

Termissä on kuitenkin paljon hyvää nimenomaan kokonaisuus-sanan tuoman kaikenkattavuuden mukana. Kysehän ei ole kuitenkaan siitä, että ainoastaan se IT-osasto, julkinen hallinto tai ainoastaan yritykset kuvaisivat kokonaisarkkitehtuuria. Näiden organisaatioiden motivaatiot työn tekemiselle saattavat olla erilaiset, mutta päämäärä ja työskentelytavat kuitenkin samanlaista.

Yritysarkkitehtuuri tai Enterprise Architecture

Siinä missä kokonaisarkkitehtuuri tulee vahvasti julkiselta puolelta, yritysarkkitehtuuri taas on vahvemmin sidoksissa englanninkieliseen Enterprise Architecture -sanaan ja siihen liittyvään TOGAF-viitekehykseen.

Tämän sanan kohdalla olennainen kysymys lienee, että onko tarpeen käyttää suoraa käännöstä, vai kestäisikö IT-kenttä sittenkin vielä yhden anglismin sanan alkuperäisessä ”Enterprise Architecture”-muodossa. Tarvitseeko jokaisesta sanasta olla täsmällinen suomenkielinen käännös?

Mitä eroa ja yhteistä Enterprise Arkkitehtuurilla ja Yritysarkkitehtuurilla nyt sitten on? Yksi merkittävä ero liittyy sanojen yleisyyteen ja henkilöbrändäyspotentiaaliin. Jos teen tällä päivämäärällä LinkedIn-haun ihmisistä Suomen alueella sanalla Yritysarkkitehtuuri ja Enterprise Architecture, niin Yritysarkkitehtuuri antaa 6 tulosta, kun taas Enterprise Architecture noin satoja tuloksia.

Yritysarkkitehtuurin suomenkielisen sanan sijaan käyttäisin siksi mieluummin kokonaisarkkitehtuuri-termiä. Tosin, jos halutaan lähteä tekemään arkkitehtuurikuvauksia nimenomaan TOGAF-viitekehystä käyttäen, niin Enterprise Architecture on varsin suosittu ja selkeä tapa ilmaista asia Suomenkin kamaralla.

IT-arkkitehtuuri

Kysymys: ”Ai puhutaanko tässä nyt talojen rakentamisesta vai tietohallinnosta” ei ole pelkästään loistava puujalkavitsi, vaan auttaa myös ohjaamaan keskustelua oikeaan suuntaan. Joskus yhteistä ajatusta pitää lähteä hakemaan hieman kauempaa.

IT-arkkitehtuuri on kuitenkin hieman harhaanjohtava nimenomaan kattokäsitteenä. Vaikka kokonaisarkkitehtuuria usein tekevät tietohallintoihmiset, on sen tulokulma silti hieman toisenlainen. Tavoitteena on nimenomaan kuvata miten ylätason strategiset päämäärät, yrityksen kyvykkyydet ja roolit liittyvät tekemiseen, esimerkiksi prosesseihin ja tietojärjestelmiin.

Joskus taas termiin törmää, koska inhimillisistä syistä suuremmissa organisaatioissa arkkitehtuurityö on saatettu jakaa moneen osioon. Yksi kuvaa IT-arkkitehtuuria tai tietojärjestelmiä, toinen liiketoimintaa, kolmas integraatioita, neljäs fyysisiä palvelinkaappeja, viides tiedon liikkeitä.

Kattokäsitteenä en kuitenkaan näe tätä hyväksi termiksi, koska se menee hieman ohi työn perusajatuksesta eli toiminnan ja strategisten tavoitteiden linkittämistä tiedon- ja järjestelmien hallintaan. Toisinaan se on kuitenkin varsin toimiva tarkennus kokonaisarkkitehtuurin sisällä.

Ratkaisuarkkitehtuuri tai Solution Architecture

Ratkaisuarkkitehtuuri, kuten IT-arkkitehtuurikin, on terminä usein sidoksissa työn tulokulmaan, vaikka kyse on edelleen tietynlaisesta kokonaisarkkitehtuurityöstä. Ratkaisuarkkitehti keskittyy tavallisesti johonkin yhteen tarkoin määriteltyyn projektiin sen sijaan, että kuvaisi laajaa organisaation kokonaisuutta.

Ratkaisuarkkitehtuurin kuvaaminen keskittyy ainoastaan tai ainakin todella vahvasti vain määritellyn projektin kohteena olevan järjestelmän tai järjestelmähankkeen suoriin yhteyksiin. Esimerkiksi siis siihen ketkä ratkaisua käyttäisivät, millaisiin prosessivaiheisiin ratkaisun pitäisi vastata, mihin järjestelmiin ratkaisun pitäisi integroitua ja millä tavoin. Ratkaisuarkkitehdin työ saattaa vaatia myös huomattavasti perinteistä kokonaisarkkitehtuurityötä enemmän sormien mutaan asettamista, eli ihan rehellistä koodaamista.

Joskus taas ratkaisuarkkitehdin työ saattaa olla tarkoituksella valittu yhtä järjestelmää suurempi osakokonaisuus organisaation koko arkkitehtuurista. Esimerkiksi ratkaisuarkkitehti saattaa keskittyä vain GDPR-kuvauksiin.

Ratkaisuarkkitehtuuria itseään, toisin kuin IT-arkkitehtuuria, harvoin mielletään kattokäsitteeksi. Useimmiten se liitetään yksittäisen henkilön, usein projektia tekevän konsultin, toimenkuvaan tai titteliin. On olemassa kokonaisarkkitehtuuri, jonka eri osioita toteuttavat ratkaisuarkkitehdit.

Onko sanavalinnalla edes merkitystä?

Pohjimmiltaan kokonaisarkkitehtuurityötä tekevissä henkilöissä on kyse liiketoimintaa ymmärtävistä tietohallinnon asiantuntijoista ja kokonaisarkkitehtuurin tavoitteena on yhdistää IT-kenttä vahvemmin yrityksen muuhun toimintaan.

Mitä tekijöiden työnkuva tarkalleen ottaen sisältää, riippuu jokaisen organisaation omista tarpeista.

Tästä Arterin ARC-ohjelmistossa on kyse. Tehdään joustavasti juuri sellaisia kuvauksia juuri sille tarkkuudelle, että ne vastaavat organisaation tilanteeseen ja että niistä on aitoa hyötyä.

Yhdet haluavat ymmärtää kokonaiskuvaa ja hahmottaa palveluiden, prosessien ja tietojärjestelmien välisiä yhteyksiä. Toisille taas on tärkeää kuvata integraatiot ja virtualisointiympäristöjen eri kerrokset. Kolmannet haluavat esimerkiksi ymmärtää tietosuoja-asetuksen näkökulmasta, missä järjestelmissä heillä on henkilötietoa ja kuinka sitä käytetään.