Miksi organisaatioissa pitäisi nyt kiinnostua palveluarkkitehtuurista?

Palveluarkkitehtuuria on pitkään vähätelty verrattuna esimerkiksi organisaatioiden kokonaisarkkitehtuuriin. Nyt palvelukeskeisen arkkitehtuurin hallinnan tarpeeseen aletaan herätä. Seuraan elokuusta alkaen blogissa erään tosielämän SOA-hankkeen vaiheita.

Kokonaisarkkitehtuurin suunnittelussa on viime aikoina ollut nähtävissä ryhtiliikettä, jota on julkisella puolella haettu jopa lain voimalla (lue lisää Anne Honkarannan bloggauksesta). Palveluarkkitehtuuriin (engl. Service-oriented Architecture / SOA Governance, suomeksi myös SOA-hallinta/hallintomalli) ei kukaan pakota edes julkisella puolella, vaikka laki ohjaakin palveluiden jakamiseen ja yhteiskäyttöisyyteen. SOA-hallinnan tarpeellisuuteen on kuitenkin viime aikoina alettu herätä.

Esimerkiksi kansallisen palveluarkkitehtuurin ohjelman tavoitteiksi määritellään ”yhteentoimiva digitaalisten palvelujen infrastruktuuri”, joka edistää julkisen hallinnon avoimuutta ja lisää kansalaisten, yhteisöjen ja viranomaisten vuorovaikutusmahdollisuuksia tietoturvallisesti.

Mikä SOA-hallinta? Tavoitteena järjestelmien yhteiskäyttöisyys

Järjestelmiä on organisaatioissa vuosikausia hankittu ja ylläpidetty siilomaisesti: asiakastietojärjestelmä on erikseen, taloushallinta erikseen ja niin edelleen. SOA-hallinnan tavoitteena on edistää järjestelmien yhteiskäyttöisyyttä: järjestelmät käyttävät ristiin toistensa palveluita (ja tarjoavat niitä tarvittaessa myös organisaation ulkopuolelle). Onkin koko organisaation etu, että eri järjestelmiin kertyvä tieto saadaan siiloista joustavasti käyttöön.

SOA- eli palvelupohjaisesta arkkitehtuurista on puhuttu toistakymmentä vuotta, ja samalla järjestelmien yhteiskäyttöisyyteen on puolihuomaamatta siirrytty – mutta ilman järkevää kokonaissuunnittelua. Samaan aikaan toimittajakunta on laajentunut. Useissa asiakkaissa näkee, kuinka sekavaksi kokonaisuus on mennyt. Kun kukaan ei oikein tiedä, mikä järjestelmä keskustelee minkäkin kanssa, käsissä on monessa paikassa katastrofaalinen soppa.

Vastuuta yhtenäisestä mallista ei voi ulkoistaa

Tyypillisin malli SOA-palvelujen järjestämiseen on ollut, että jokainen taho organisaation sisällä tekee palvelut kuten parhaaksi näkevät. Myös jokaisella toimittajalla on omat periaatteensa ja mallinsa, joilla haetaan kilpailuetua. Organisaatiossa on päätettävä, miten palvelutuotantoa hallinnoidaan. Tätä vastuuta ei voi tapauskohtaisesti ulkoistaa järjestelmätoimittajille.

Jos organisaatiossa ei ole yhtenäistä SOA-hallintomallia, yhteiskäyttöisten palveluiden kehittämisessä on tiedossa ongelmia:

  • Kuinka yhteiskäyttöiset palvelut saadaan levitettyä käyttöön?
  • Kuinka niiden toimivuutta seurataan?
  • Kuinka niiden palvelutaso määritetään, ja miten sitä seurataan?
  • Kenen vastuulla on mikäkin asia? Monesti nykytilanteessa tarvitaan iso joukko ihmisiä selvittelemään ongelmaa, joka saattaa olla hyvinkin yksinkertainen, koska mikään ei tunnu kuuluvan oikein kenellekään.

Näitä ongelmia SOA-hallintomallin avulla taklataan: palvelunhallinnalle määritellään periaatteet, joita nykyiset ja tulevat järjestelmätoimittajat ohjeistetaan noudattamaan.

Kirjoista ei löydy valmista mallia

Palveluarkkitehtuurin hallinnasta löytyy paljon kirjallisuutta. Olen kuullut joskus ehdotettavan, että eikö palveluntuotannon ongelmat voisi ratkaista kirjasta katsomalla? Ei toimi, ikävä kyllä. Kyseessä on asia, jota ei voi valmiina ostaa. Se täytyy rakentaa. Vieläpä niin, että se mikä toimi paikassa A, ei välttämättä toimi paikassa B. Organisaatiot ovat erilaisia ja SOA-kypsyystaso on erilainen.

SOA-hallintomallin rakentaminen ei olekaan helppo projekti. Miksi siihen silti kannattaa ryhtyä? Olen omien kokemusteni perusteella yhtä mieltä Nicolai M. Josuttisin (SOA in Practice, 2009) kanssa:

Governance is necessary to avoid chaos
and/or a waste of money and resources.

Tiedossa tositarinoita SOA-projektin vaiheista

Kirjoitan blogiin elokuusta alkaen noin kerran kuussa eräästä elävän elämän SOA-hallintomallin perustamisprojektista – nimeltä mainitsemattoman asiakkaan suostumuksella totta kai. Tarkastelussa on, miten palveluarkkitehtuurin hallinta jalkautuu eräässä suuressa organisaatiossa, minkälaisia haasteita ja asioita matkalla tulee vastaan, ja miten niitä taklataan.

Tähän asti on lämmitelty, kesän jälkeen alkaa täysi rytinä. Seuraava aihe on alkukankeus palveluarkkitehtuurin hallinnan jalkauttamisessa. Hyvää kesää!

palveluarkkitehtuuri




Tero Rönkä | Chief SOA Architect

Tero Rönkä | Chief SOA Architect

Teron erityisosaamista on liiketoiminnan ja IT:n yhdistäminen sopivia tekniikoita hyödyntäen. Hän on käytännönläheisenä arkkitehtinä keskittynyt viime vuodet integraatioihin ja palvelupohjaisiin ratkaisuihin, aina toteutuksesta hallinnointiin. Terolle on tärkeää olla tempautumatta nopeatahtisen arjen vietäväksi: hän tarkastelee asioita analyyttisen rauhallisesti ja arvostaa konkreettisia lopputuloksia. Hänen johtoajatuksensa on, että ylimitoitettujen toiveiden ja täydellisyyden tavoittelun sijaan kannattaa keskittyä lopputuloksiin, jotka ovat konkretisoitavissa hyödyksi arjessa. Vapaa-ajalla Tero tuulettaa ajatuksia polkupyörän selässä ja frisbeegolfkentällä.

Kirjoittajan kaikki blogitekstit

Tilaa blogikirjoitukset sähköpostiisi




Seuraa meitä somessa

LinkedIn Twitter Facebook YouTube YouTube