Mikä ihmeen IT-arkkitehtuuri?

Mikä ihmeen IT-arkkitehtuuri?

Minulta kysytään usein, mitä työnkuvaani IT-arkkitehtina kuuluu. Yleensä käytän analogiaa rakennusalan arkkitehtiin, sillä tämä on syystä tai toisesta tutumpi rooli suurelle osalle ihmisistä. Kerron, kuinka rakennusarkkitehdit tuottavat teknisiä piirrustuksia, joiden avulla monimutkaisia kokonaisuuksia voidaan esittää yksikäsitteisesti niin liiketoiminnasta päättäville henkilöille kuin itse rakentajillekin, ja kuinka näitä piirrustuksia on eri tyyppisiä riippuen siitä mikä on kuulijalle relevanttia. Esimerkiksi rahoitusta hakiessa on tärkeämpää esitellä fiiliskuvia siitä, miltä tuleva rakennus näyttää, kun taas sisustussuunnittelijan on tiedettävä tilan mittasuhteet, materiaalit ja muut rajoitteet.

IT-arkkitehti tekee pitkälti samoja asioita, mutta digitaalisten projektien parissa. Rakennuksen sijaan kohteena voi olla uusi maksujenvälitysjärjestelmä tai vaikka sovellus videon livestriimaukseen. Yhtymäkohtia on paljon, mutta niin on eroavaisuuksiakin. Pyrinkin tässä artikkelissa tuomaan esille oman käsitykseni roolista ja siitä, mitä IT-arkkitehtuuri nykypäivänä tarkoittaa.

Mitä IT-arkkitehtuuri on?

Gartnerin mukaan kyse on kokoelmasta toimintaperiaatteita, ohjeita ja sääntöjä, mitä sovelletaan tietoteknisen järjestelmän suunnitteluun sekä sen komponenttien loogisten ja fyysisten suhteiden määrittelyyn. Arkkitehtuurin kautta määritellään mm. tietojärjestelmän rakentamiseen käytettävä laitteisto, ohjelmistot, käyttötavat ja protokollat.

Kuten edellä olevasta määritelmästä voi päätellä, IT-arkkitehtuuriin kuuluu paljon analyyttistä työtä. Uutta luotaessa on aina otettava huomioon olemassa olevat järjestelmät, sillä niillä saattaa olla yllättäviäkin vaikutuksia työn alla olevaan projektiin. Arkkitehdin onkin yleensä tunnettava ympäröivät tietojärjestelmät sekä liiketoiminnan asettamat vaatimukset ja rajoitteet. Esimerkiksi pankkijärjestelmiä suunniteltaessa on teknisten vaatimusten lisäksi otettava huomioon eri maiden lait, taloudellisten ja poliittisten liittojen asettamat säädökset sekä yritysten omat säännöt.

IT-arkkitehtuuri käytännössä

Viimeisen parin vuosikymmenen aikana tietojärjestelmien arkkitehtuurin suunnitteluun ja kuvaamiseen on kehittynyt joukko työkaluja ja -menetelmiä, joiden avulla monimutkaisiakin kokonaisuuksia voidaan hallita tehokkaasti.

Ei ole olemassa yhtä oikeaa tapaa, jolla arkkitehtuuria kuvataan, vaan yrityksestä, projektista sekä käyttökohteesta riippuen voidaan käyttää useitakin erilaisia menetelmiä. Samoin kuin rakennusarkkitehtuurissa, tekniset piirrokset jotka kuvastavat järjestelmän eri osia, niiden liitoksia sekä muita yksityiskohtia ja kokonaisuuksia, ovat elintärkeitä projektin onnistumiselle.

UML-kaaviot

UML (Unified Modeling Language) on standardoitu kokoelma kaavioita, joilla kuvataan rakennetta, käyttäytymistä ja vuorovaikutusta. Graafinen mallinnuskieli on alun perin kehitetty järjestelmä- ja ohjelmistokehitystä varten 90-luvun puolessa välissä. UML ei suinkaan ole ainoa kaaviostandardi, mutta se on ohjelmistoliiketoiminnassa selkeästi suosituin.

Alkuperäinen kuva: Kishorekumar 62 – Omaa työtä, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=5766927

UML:n avulla voidaan kuvantaa käytännössä kaikki arkkitehtuurin osa-alueet seuraavalla jaolla:

  1. Korkean tason toiminnallisuus käyttötapauskaavioiden avulla
  2. Järjestelmän staattinen ja dynaaminen rakenne olio-, luokka-, sijoittelu– ja komponenttikaavioiden avulla.
  3. Järjestelmän dynaaminen käyttäytyminen sekvenssi-, yhteistyö-, tila– ja aktiviteettikaavioiden avulla.

Aiheena UML on niin laaja, että siitä on kirjoitettu kokonaisia kirjoja. Jos haluat lukea aiheesta lisää, suosittelen tutustumaan Pasi Kellokosken UML perusteet -esitykseen.

Vapaamuotoiset kaaviot

Arkkitehdin työssä yksi tärkeimpiä tavoitteita on se, että dokumentoitu suunnitelma on selkeä ja ymmärrettävä. UML luo tälle hyvän perustan, sillä standardoitu mallinnuskieli antaa avainhenkilöille käyttöön yhteisen kielen, jolla asiaa ennestään tuntematonkin henkilö voi arvioida ja toteuttaa suunnitelman. Toisinaan on kuitenkin tärkeämpää viestiä jokin arkkitehtuurin osa-alue nopeasti ymmärrettävällä tavalla ilman että vastaanottaja tuntee UML:ää tai muuta mallinnuskieltä.

Vapaamuotoiset kaaviot ovat juuri sitä, mitä niiden nimi antaa olettaa. Niitä ei sido mitkään standardit tai määritykset ja tärkein tavoite on visuaalisesti esittää jokin kokonaisuus niin, että kuka tahansa asiaa edes jotenkin tunteva ymmärtää mitä kaavio kuvaa. Yleensä kaavioissa käytetään laatikoita, muita geometrisia muotoja tai kuvakkeita eri komponentteja ja kokonaisuuksia esittämään. Tavallisesti niiden välille piirretään myös viivoja ja yhden- tai kahdensuuntaisia nuolia kuvaamaan erilaisia suhteita, kuten periytymistä, datan kulkusuuntaa ja fyysisiä yhteyksiä.

Joissain yrityksissä vältetään UML-kaavioiden käyttöä, sillä vapaamuotoiset kaaviot nähdään joustavampana ja nopeampana tapana esittää asioita. Omasta mielestäni kyseessä on kuitenkin menetelmä joka tukee UML:ää, muttei korvaa sitä. Esimerkiksi palaverin aikana tussitaululle piirretyt kaaviot on turha tehdä väkisin UML-standardin mukaiseksi. Aika on parempi käyttää selkeän ja yksinkertaisen kaavion piirtämiseen, sillä epäselvyyksiä ja puutteita voi aina täydentää sanallisesti.

Dokumentaatio

jos sitä ei ole kirjoitettu ylös, se ei ole olemassa

IT-alalla hallitseva vanha viisaus sanoo, että ”if it is not written down, it doesn’t exist”. Tästä syystä arkkitehtuurin pyrkimyksenä on kuvata joko tekstimuodossa tai visuaalisesti kaikki projektin osa-alueet, jotka ovat tärkeitä lopputuloksen kannalta.

Esimerkiksi suunnittelutyön aikana tehdyt päätökset tulisi dokumentoida, jotta tulevaisuudessa projektin parissa työskentelevät henkilöt ymmärtävät miksi jokin päätös on tehty. On lähes mahdotonta tehdä hyviä päätöksiä ilman minkäänlaisia perusteita, joten niiden ylöskirjaaminen toimii myös hyvänä mittarina niiden järkevyydelle. Jos perusteita on mahdoton keksiä, on päätös todennäköisesti tehty liian hätäisesti.

Dokumentaatio ei ole kuitenkaan pelkkää tekstiä, vaan se sisältää yleensä edellämainitut kaaviot ja muut visuaaliset elementit. Monesti teksti selventää ja avaa kaavioiden esittämiä konsepteja edelleen, täydentäen dokumentaation koherentiksi kokonaisuudeksi. Yleisesti ottaen tarkoitus on se, että koko dokumentaation läpi lukenut henkilö ymmärtää projektin niin hyvin, että hän pystyy osallistumaan projektiin oman roolinsa mukaisesti.

Tulen käymään tulevassa artikkelissa tarkemmin läpi eri dokumentaatiomenetelmiä ja arkkitehdin yleisesti tuottamia dokumentteja.

IT-arkkitehdin erikoistumisalueet

Siirtyminen arkkitehdiksi harvoin tapahtuu aivan uran alkupuolella, sillä hyvältä arkkitehdilta vaaditaan erittäin laajaa osaamista oman alansa tärkeimmistä osa-alueista. Ohjelmistoprojektissa hänen tulee esimerkiksi tuntea ainakin pintapuoleisesti eri ohjelmointikielet, ohjelmistokehykset sekä ajonaikaiset alustat joiden avulla projekti voidaan toteuttaa. Tämän lisäksi tietoa tulee olla myös pilvipalveluista, testauksesta, integraatioista, verkoista, tietoturvasta ja monesta muusta aiheesta. Esimerkiksi ohjelmoijan rooliin verrattuna, arkkitehdin tulee hakea osaamista horisontaalisesti kaikilta eri osa-alueilta, kun taas koodin parissa työskentelevä henkilö voi viettää koko uransa erittäin suppean aihealueen parissa, kehittyen sillä vertikaalilla todelliseksi erityisosaajaksi.

Tähän mennessä olen käyttänyt IT-arkkitehti-nimitystä varsin laveasti. Todellisuudessa suurin osa arkkitehdeista lasketaan kuuluvaksi johonkin alakategoriaan, joka rajaa selkeästi heidän osa-alueeseen kuuluvat roolit ja vastuut. Rooleja on erittäin teknisistä ei niin teknisiin ja yleensä arkkitehdin aiempi työkokemus määrittelee vahvasti sen, mihin suuntaan hän urapolullaan kulkeutuu. Ei kuitenkaan ole mitään yksittäistä sääntöä, että ohjelmoijasta tulee ohjelmistoarkkitehti ja integraatioinsinööristä integraatioarkkitehti.

Seuraavassa artikkelissa tulen käymään läpi eri roolit ja niiden eroavaisuudet. Olen tarkoituksella jättänyt useita aiheita kokonaan käsittelemättä tässä artikkelissa, sillä aihe on itsessään niin laaja, ettei tuhannella sanalla raapaista kuin pintaa. Aiheesta erityisen kiinnostuneille voin suositella seuraavien kirjojen lisäämistä lukulistalle:

Kirjoita kommentti

Nimi

Sähköpostiosoite