Ratkaisuarkkitehtuuri sisältää sekä ratkaisun että arkkitehtuurin

Published 16.5.2024
Reading time approx 4 min

Vuosien mittaan on tullut häärättyä pitkään sekä ratkaisuarkkitehtinä että projektipäällikkönä. Käsittelen tässä lyhyesti kokemuksiani ja näkemyksiäni ratkaisuarkkitehtuurin tuottamiseen liittyvistä haasteista ja niiden mahdollisista ratkaisuista.

Meillähän on tässä kaksi osaa – ratkaisu ja arkkitehtuuri. Ratkaisu on vastaus organisaation toiminnasta ja tavoitteista johdettuun ongelmaan. Arkkitehtuurin avulla kuvataan, millainen ratkaisu on kyseessä ja miten ratkaisu vastaa tarpeisiin sekä toiminnallisiin ja ei-toiminnallisiin (teknisiin) vaatimuksiin.

Arkkitehtuuri on kommunikointia.
– Ben Kalland

Hahmottelin aikanaan joitakin huomioitavia asioita, kun ratkaisua ryhdytään työstämään. Tämä rautalankamalli ei korvaa eikä kata järjestelmällisiä vaatimushallinnan menetelmiä, vaan on tarkoitettu yleisluontoiseksi keskustelun avaajaksi eri sidosryhmille.

Ratkaisun tuottamiseen vaikuttavia tekijöitä

Ratkaisuarkkitehtuuri keskittyy yksittäisen ratkaisun tai palvelun arkkitehtuuriin ja määrittelee ratkaisun toiminnalliset, tekniset, laadulliset ja hallinnolliset vaatimukset sekä niiden toteutustavan.

Ratkaisuarkkitehtuuria voidaan tarkastella kahdellakin tavalla:

  • Voidaan ensinnäkin ottaa näkökulmaksi kokonaisarkkitehtuuri (KA; enterprise architecture, EA), joka kuvaa organisaation tietojärjestelmien, prosessien, tietovarantojen ja liiketoiminnan yhteensovittamista. Tällöin ratkaisuarkkitehtuuri (solution architecture) tarkoittaa organisaation omaa kehittämistä ohjaavaa ”enterprise solution architecturea”, jolloin kyseessä on kokonaisarkkitehtuurikeskeisten kuvausten kokonaisuus.
    Kokonaisarkkitehtuurissa yleisesti sovellettu viitekehys on The Open Groupin TOGAF®, ja siitä johdettu kotimainen versio, suositus Kokonaisarkkitehtuurin suunnittelu ja kehittäminen JHS179.
  • Toisena näkökulmana ratkaisuarkkitehtuuri voi tarkoittaa kehittämishankkeen tai -projektin toteutuskokonaisuutta kuvaavaa arkkitehtuuria. Tällöinkin ratkaisuarkkitehtuuri olisi syytä katsoa osaksi kokonaisarkkitehtuuria; muussa tapauksessa ratkaisuita kehitetään pistemäisinä ratkaisuina. Yleisen elämänkokemuksen perusteella tästä seuraa hankalasti ja kalliisti ylläpidettäviä järjestelmiä, joiden toteutukset, kuvaukset ja ylläpidon menetelmät vaihtelevat tapauskohtaisesti. (Erään konkarin kommentin mukaan ”jonkinlainen arkkitehtuuri tuostakin seuraa; ei hallittu eikä suunniteltu, mutta jotain kuitenkin.”)

Toteutuksen aikaisessa ohjauksessa olen törmännyt edellä mainittujen näkökulmien aiheuttamiin ”hankauksiin”; jos kokonaisarkkitehtuurin kautta ohjausta ei ole saatu, tyypillinen tarve on ollut saada ohjausryhmältä päätös (tai ”linjaus”) siitä, miten ja millä vaihtoehdolla tietty tekninen ratkaisu tulisi toteuttaa, ja miten ratkaisu tulisi kuvata:

  • Päätöksentekoon on liittynyt se ongelma, että ratkaistavilla asioilla on vaikutuksia laajemminkin. Ohjausryhmän kautta eskalointi saattaa olla hidasta ja/tai tehotonta. Muutoshallinnan kautta vastauksien hakeminen taas on… vähän jälkijättöistä.
  • Kuvauksiin liittyi se ongelma, että esimerkkejä tai malleja ei ollut välttämättä saatavissa. Silloin tietysti käytetään niitä menetelmiä, jotka ovat tuttuja, käytettävissä ja ainakin subjektiivisesti tarkasteltuna hoitavat hommansa. Hyvä juttu sinänsä, ainakin projektin kannalta. Mutta ei välttämättä jatkokehityksen eikä ylläpidon.

Ratkaisuarkkitehtuurin tavoitteena on varmistaa, että ratkaisu on yhteensopiva kokonaisarkkitehtuurin kanssa ja että se on (helposti ja kustannustehokkaasti) ylläpidettävä, kehitettävä ja skaalattava.

Mutta mihin vedetään raja kokonaisarkkitehtuurin ja ratkaisuarkkitehtuurin välille – mitä evästystä kokonaisarkkitehtuuri antaa ratkaisuarkkitehtuurille? Olen käyttänyt havainnollistamiseen suosituksen JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen -kuvausta. Tavoitteet ja edellytykset hahmoteltavalle ratkaisulle tulisivat – täydellisessä maailmassa – kokonaisarkkitehtuurin kautta. Periaatteellinen (MIKSI) ja käsitteellinen taso (MITÄ), jopa osa loogisesta tasosta (MITEN) saattaisivat tulla ”valmiiksi annettuna”. Saattaapa olla valmiiksi laadittu tavoitearkkitehtuurin kuvauskin.

Ratkaisuarkkitehtuurin skooppi

Ratkaisuarkkitehtuuri keskittyy erityisesti ”alakertaan” – miten loogisesta tasosta johdetaan fyysisen tason (MITEN) kuvaukset, kuten mitä tietojärjestelmiä ratkaisu koskee, ja mitä teknologiavalintoja tehdään.  

On huomattava, että tietoarkkitehtuurin merkitys on lisääntynyt huomattavasti digitalisaation ja tiedon määrän moninkertaistumisen myötä.

Virtualisoinnin ja pilveistymisen myötä taas tarve kuvata fyysisiä laitteistoja (fyysiset palvelimet, verkkolaitteet) yksityiskohtaisella tasolla on vähentynyt huomion kiinnittyessä ohjelmallisesti tuotettuihin konfiguraatioihin (Infrastructure as Code, IaC).  

Tietoturva (cybersecurity) on huomioitava kaikilla tasoilla, varsinkin tietojärjestelmä- ja teknologiarkkitehtuurissa.

Ratkaisuarkkitehtuurin suunnitteluun liittyen olen tehnyt pari havaintoa. Ongelmia saattaa syntyä yksittäisessä kehittämishankkeessa tai -projektissa, jos ratkaisuarkkitehtuuri tuotetaan vain projektin omilla resursseilla:

  • Projektissa ei välttämättä olla varauduttu ottamaan vastaan tai tuottamaan kokonaisarkkitehtuurin mukaisia kuvauksia; käsitteet, terminologia, menetelmät jne. eivät välttämättä ole tuttuja projektin henkilöille. Samoin käytettävät työvälineet ja niiden edellyttämät kuvausmenetelmät edellyttävät omaa erityistä osaamistaan.
  • Projekteissa ei tyypillisesti ole aikaa käytettäväksi uusien välineiden opiskeluun, eikä budjettia esimerkiksi tarvittavien lisenssien hankkimiseen.

  • Voi myös olla, että organisaation kokonaisarkkitehtuurista vastaava (virtuaali)yksikkö on hyvin ohut. Välttämättä ei ole edes tarjota projekteille valmiita malleja, ohjeita tai kuvauksia. 

Kehittämishankkeen tai -projektin tavoitteet voivat olla ristiriidassa kokonaisarkkitehtuurin kanssa:

  • Jos päädytään kokonaisarkkitehtuurin sanelemaan ratkaisuun, projektissa joudutaan tekemään tai tukeutumaan ei-optimaalisiin väliaikaisratkaisuihin. Kokonaisarkkitehtuurissa tehdyt linjaukset eivät jousta, tai ota huomioon muuttuneita tilanteita toimintaympäristössä. Projektin kannalta joudutaan ottamaan käyttöön ”vanhanaikainen” tai liian kallis ratkaisu.

  • Jos päädytään projektin ohjaamaan ratkaisuun, kokonaisarkkitehtuurin kannalta saatetaan joutua myöntämään poikkeuksia (exception), jotka kokonaisuuden kannalta saattavat varsinkin pidemmällä aikavälillä olla hankalasti ja kalliisti ylläpidettäviä.

Omasta mielestäni kehittämishankkeet ja -projektit tulisi nähdä tehokkaana menetelmänä tuottaa kokonaisarkkitehtuuria rikastavia ratkaisuita. Jo konseptin validoinnissa (Proof-of-Concept, PoC) olisi hyvä olla mukana kokonaisarkkitehtuurin näkökulma. Esimerkiksi yksittäisessä projektissa käyttöönotettavan ratkaisun skaalautuminen suuremmalle käyttäjäjoukolle (more of the same) – suuruuden ekonomia – tai laajemmalle käyttäjäkunnalle (esimerkiksi lisäpalveluiden tai -moduleiden kautta). Teknologian evoluution myötä uudet ratkaisut korvaavat aiemmat, ja niiden validointia olisi kätevä suorittaa kehitysprojektien kautta.

Kehity arkkitehtuurissa – tutustu koulutuksiin

TOGAF® is a registered trademark of The Open Group.

About author:

Jyrki Kivimäki

Jyrki Kivimäki on toiminut pitkään IT-alalla eri tehtävissä. Jyrki toimii arkkitehtinä ja projektipäällikkönä liiketoimintavetoisten ratkaisuiden suunnittelussa ja tuottamisessa.

Tags

Ratkaisuarkkitehtuuri Arkkitehtuuri