Päivitetty viimeksi 04.07.2006

Takaisin sisällysluetteloon
IT Universitas nro 9 / 30. kesäkuuta 2006

SOA

1. MÄÄRITELMÄ

SOA:n tavoitteena on tietojärjestelmien nykyistä parempi muutosjoustavuus ja palvelu-komponenttien uudelleenkäyttö, mikä tehostaa järjestelmien toteutustyötä ja säästää kustannuksia. SOA soveltuu malliksi sekä nykysovellusten kehittämiseen että uusien järjestelmien suunnitteluun ja toteutukseen. Parhaiten SOA:n edut tulevat esiin, kun sitä sovelletaan yrityksen kokonaisarkkitehtuuriin (jäljempänä yritysarkkitehtuuri).

2. PARADIGMAMUUTOS

Löyhän kytköksen voimakas periaate osana SOA:n filosofiaa johtaa järjestelmien sisäisen rakenteen sekä järjestelmien välisen integraation voimakkaaseen muutokseen. SOA-mallissa järjestelmien välille ei enää rakenneta toiminto- tai tietokohtaisia liittymiä. Tietovirrat kulkevat palvelupyyntöjen kautta osana toteutettavaa liiketoimintaprosessia ja palvelupyynnöt itsessään muodostavat toiminnallisen integraation.

Kuva 1 - SOA paradigmamuutos

Edellinen kuva pyrkii havainnollistamaan SOA:an siirtymisen paradigmamuutoksen. Keskeisimpänä muutoksena mainittakoon prosessikeskeisyys joka leimaa paitsi fyysisiä toteutuksia myös koko systeemityöprosessin luonnetta.

Palveluiden abstraktiotaso on toinen merkittävä muuttuva kohta. SOA-maailmassa palveluväylällä julkaistavat palvelut ovat liiketoimintaprosesseja palvelevia ja tämän vuok-si merkitystasoltaan tyypillisesti huomattavasti korkeammalla abstraktiotasolla verrattuna perinteisiin tietojärjestelmäpalveluihin.

Kolmas keskeinen muutos on järjestelmäkeskeisyyden poistuminen. Tämä tarkoittaa käytännössä sitä että osa palveluista, joilla tietty liiketoimintaprosessi toteutuu, voidaan tuottaa eri järjestelmissä ja jopa eri toimijoiden toimesta. Kun eri toimijat yhdistyvät osana prosessi-integraatiota, puhutaan yleisesti virtuaaliorganisaatiosta.

3. PALVELURAKENNE

Kuva 2 - Palveluverkostot

Vaikka SOA:n periaatteissa korostuu löyhä kytkös, muodostuu palveluiden välille riippuvuussuhteita vähintään loogisella tasolla. Järjestelmärajat hämärtyvät palvelukeskeisen kehittämisen myötä ja prosessit korostuvat. Prosessit muodostavat kuitenkin loogisen kokonaisuuden ja kontekstin joka sitoo palvelut toisiinsa. Kun samoja palveluita lisäksi hyödynnetään useassa eri prosessissa, ja sikäli useassa kontekstissa, muodostuu palveluiden välille paikoin monimutkaisiakin rakenteita.

Koska palvelut teknisesti kytkeytyvät toisiinsa vasta suorituksen aikana ja tarvittaessa, on palveluiden väliset suhteet hallittava prosessien näkökulmasta perinteisistä sovelluskehityksen välineistä ja menetelmistä poikkeavilla menettelyillä.

4. SOA – YRITYSARKKITEHTUURIN NÄKÖKULMASTA

Siirtyminen palvelukeskeiseen arkkitehtuuriin on osa yrityksen kokonaisvaltaista yritysarkkitehtuurin kehittämistä.

Kuva 3 - Ylätason kaavio yritysarkkitehtuurista

Edellä oleva kuva kuvaa yritysarkkitehtuurin ylätasolla. Yritysarkkitehtuuri koostuu pääpiirteittäin neljästä näkökulmasta: liiketoimintanäkökulma, tietonäkökulma, teknologianäkökulma sekä näistä johdettu järjestelmä- tai ratkaisunäkökulma.

Perinteisiin tietojärjestelmäarkkitehtuureihin nähden SOA nousee lähemmäksi yritysjohdon näkökulmia samalla tukien tietojärjestelmä arkkitehtuuria. Samalla myös proses-silähtöisyys kasvaa. Tämä edellyttää muutoksia henkilöstön osaamisessa.

Liiketoimintanäkökulmassa kuvataan yrityksen liiketoimintaprosessit jotka järjestelmäarkkitehtuurissa toteutuvat osittain tietoteknisin keinoin. Tästä johtuen tietohallinnon on ymmärrettävä merkittävästi aiempaa paremmin liiketoimintaprosessien mallintamista ja kehittämistä. Samoin liiketoiminnan ja prosessien kehittämisestä vastaavien on ymmär-rettävä paremmin tietotekniikan kehittämistä.

5. SIIRTYMINEN PALVELUKESKEISEEN ARKKITEHTUURIIN

5.1 Organisationaaliset edellytykset

SOA edellyttää sen käyttöönottoa harkitsevalta yritykseltä tiettyä kypsyyttä tietotekniikan hyödyntäjänä. Samoin liiketoimintaprosessien ja tietotekniikan yhä tiiviimpi kytkeytyminen toisiinsa edellyttää sekä liiketoiminnan kehityksestä että tietohallinnosta vastaavilta uudenlaista ajattelutapaa.

Vaikutukset ulottuvat yrityksen ylimpään johtoon saakka, sillä heidän tavoitetila-asenteensa heijastuu liiketoimintaprosessien kautta yrityksen liiketoimintainfrastruktuuriin. Johdolta edellytetään kykyä huomioida sen hetkisen infrastruktuurin rajoitukset kuin myös uusien mahdollisuuksien saattavan edellyttää mittavaa panostusta. Näin varsinkin SOA-transformaation alkumetreillä.

5.2 Liiketoiminnalliset edellytykset

Liiketoiminnan tulee olla kuvattuna arkkitehtuurina sekä mallinnettuna prosessikartoiksi ja malleiksi. Ei riitä, että ne on kertaalleen tehty ns. PowerPoint-tasolle, vaan niistä pitää olla myös ylläpidettävä kuvauskanta, jossa niitä voidaan muuttaa ja samalla tehdä vai-kuttavuusarvioita ja analyysejä. Prosessit on kyettävä prosessimalleista viemään saumattomana ketjuna tietohallinnolle implementointia varten.

Tätä varten prosessien hallinta, mallinnus, simulointi, toteutus ja mittaus (BPM) saavat aiempaa suuremman merkityksen.

5.3 Tietotekniset edellytykset

Tähän mennessä liiketoiminnallisia ja prosessinäkökulmia on tuotu korostuneesti esille, koska ne ovat lähtökohta ja perusta SOA-mallin soveltamisessa.

Kuva 4 - Esimerkki SOA-siirtymäpolusta

Laadittaessa siirtymäpolun suunnitelmaa joudutaan tekemään myös päätöksiä, mitkä kaikki palvelut SOA-kehikkoon halutaan siirtää, ja mitkä on syytä hylätä ja rakentaa uudelleen SOA-pohjaisesti. Esimerkiksi 2-tasoista client/server-mallia hyödyntävät ratkaisut, joissa liiketoimintalogiikka sijaitsee asiakassovelluksessa, on äärimmäisen vaikea siirtää SOA-kehikkoon.

SOA-transformaatio on kuitenkin syytä tehdä evoluutionäärisesti ja paloittain, joten kaikkia päätöksiä ei tarvitse kerralla tehdä.

6 SOA-KEHIKKO

SOA-kehikon tulee tukea merkittävästi aiempia kehikoita enemmän liiketoimintaprosessien siirtämisestä mallinnuksesta ajonaikaiseen implementaatioon. Tämä johtaa kehitykseen, jossa liiketoiminnan kehityksen ja tietohallinnon välisestä rajasta tulee yhä häilyvämpi. Implementoitavalta SOA-kehikolta tämä vaatii aivan uudenlaisia ominaisuuksia.

SOA-kehikko toteutettaan jollakin implementaatioteknologialla, SOA-alustalla. Seuraavassa kuvassa on esitetty SOA-kehikon loogisen tason malli.

Kuva 5 - Looginen SOA-kehikko

SOA:n laajentuessa järjestelmien sisäisestä arkkitehtuurista organisaatiotason arkkiteh-tuuriksi, korostuvat eritasoiset hallinnan vaatimukset. Kun prosessien kehittämisestä li-säksi pyritään tekemään organisaation jatkuvaa toimintaa korostuvat erilaisten hallinnan kautta tehtävien analyysien, simulaatioiden ja muutosvaikutusten ennakointiratkaisut.

Valmiit alustat ovat voimakkaasti kehittymässä ja valitsemalla jonkin tunnetun valmis-tajan kehikon, on mahdollista päästä kohtuullisen kattavaan ratkaisuun. On kuitenkin huomattava, että koska SOA-transformaatio on asteittainen, ei valittavan alustan tarvitse olla heti alussa täydellinen. SOA:n hengen mukaisesti myös palvelualusta on mahdollis-ta ja joissain tilanteissa jopa suositeltavaa koota SOA-kehikko ”Best of Breed” tuotteis-ta ja teknologioista.

7. MISSÄ MENNÄÄN?

Palvelukeskeinen arkkitehtuuri SOA sitoo luontevalla tavalla yhteen liiketoiminnan ja sitä tukevat tietojärjestelmät. SOA on suunnittelu- ja toteutusmalli, joka mahdollistaa paremmin hallitavan ja joustavammin kehitystarpeisiin vastaavan IT-ympäristön raken-tamisen. SOA korostaa IT-arkkitehtuurin kokonaisvaltaista liiketoimintalähtöistä suun-nittelua.

SOA-mallin yksi keskeinen ajatus on palvelukomponenttien uudelleenkäyttö. Tehok-kuus- ja kustannussäästöt saavutetaan sitä paremmin mitä laajempaa on palvelujen hyö-dyntäminen. Juuri tämä tavoite edellyttää hyvää ymmärrystä liiketoiminnasta ja kykyä määritellä palvelujen oikea rakenne, abstraktiotaso, toiminnallisuus ja tietosisältö. Tek-ninen toteutus on haasteena tämän jälkeen vähäisempi.

Palvelukeskeinen arkkitehtuuri tulee yleistymään yrityksissä asteittain lähivuosina. Hyödyt kasvavat vastaavasti osaamisen karttuessa, tekniikan kypsyessä ja tuotantokäyt-töön saatavien SOA-toteutusten myötä.

Kuva 6 - SOA:n elinkaarivaiheet

Edellinen kuva pyrkii havainnollistamaan palvelukeskeisen arkkitehtuurin elinkaarivaiheet. SOA nousi ilmiönä ja voimakkaana hypenä 2004 vuoden aikana. Todellinen käyttö oli kuitenkin hyvin vähäistä ja SOA elikin lähinnä kalvoilla. Vuoden 2005 aikana tehtiin runsaasti pilottitoteutuksia. SOA on kuitenkin edelleen pääosin yksittäisten projektien tai tuotteiden arkkitehtuuri eikä se vielä ole lunastanut paikkaansa osana laajempaa yritysarkkitehtuuria. Syy hitaaseen yleistymiseen organisaatiolaajuisena arkkiteh-tuurina on pitkälti SOA:n myötä muodostuvan palveluverkoston hallinnan vaikeus. Onkin selvästi nähtävissä hallintaratkaisutarjonnan yleistymisen ja tähän liittyvän tietoisuuden lisääntyvän. 2006 aikana SOAn käyttöönotto on alkanut myös laajemmassa mit-takaavassa, mutta maltillisesti edeten. SOA:n laajamittaisen käytön esteenä on usein myös SOA kyvykkyyden puuttuminen. Prosessikeskeisenä arkkitehtuurina SOA edel-lyttää toimintaprosessien tuntemista ja formaalia kuvaamista jotka monella organisaati-olla vielä tänä päivänä puuttuvat.

Näemme että SOA tulee yleistymään voimakaammin vuoden 2007 aikana. Samalla siirrytään johdettujen ja hallittujen arkkitehtuurien aikakauteen jonka vuoksi ITG (IT Go-vernance), EAM (Enterprise Architecture Management) ja BPM (Business Process Ma-nagement) ratkaisut tulevat yleistymään voimakkaasti.

8 MIKSI HALLINTA KOROSTUU JUURI SOA:SSA?

Siirryttäessä kohti SOA-maailmaa, muodostuu liiketoimintaprosessien kautta joukko palveluiden välisiä loogisia riippuvuussuhteita. Näistä riippuvuussuhteista syntyy rajoit-teita ja vaatimuksia palveluiden ja prosessien kehittämiseen. Palvelut, niiden toteuttamat vaatimukset sekä rajaukset niihin, niiden elinkaari ja mahdollinen kontekstiriippuvai-suus sekä suhteet muihin palveluihin ja prosesseihin on pystyttävä mallintamaan ja hal-litsemaan jotta kehitystoimenpiteiden aiheuttamat muutosvaikutukset olisivat millään tavoin ennakoitavissa.

Kuva 7 - Hallitsemattoman palveluverkoston hallinta

Käytännön kokemukset osoittavat, että ylevistä tavoitteista huolimatta, järjestelmäkes-keisessä kehitysprosessissa palveluverkostojen hallintaan ei kiinnitetä riittävästi huo-miota. Kuva edellä kuvaa tilannetta jossa palveluverkoston ”hallinnan” kustannus ylit-tää sen tuottamat liiketoimintahyödyt. Kokemuksen osoittava myös että palveluverkos-ton hallintaan käytettävä aika kasvaa hallitsemattomassa ympäristössä eksponentiaali-sesti suhteessa palveluverkoston kokoon.

Alla oleva kuva pyrkii havainnollistamaan syyn edelliseen.

Kuva 8 - Hallitsemattoman palveluverkoston kustannukset

Kaavio lähtee liikkeelle päätöksestä kehittää liiketoimintaa. Jokainen päätös johtaa joukkoon toimenpiteitä, mutta samalla se johtaa joukkoon odottamattomia vaikutuksia palveluverkostossa. Jälkimmäisten määrä on yleensä suorassa suhteessa palveluverkos-ton kompleksisuuteen ja kokoon. Myös suunnitelluista toimenpiteistä syntyy kustannuk-sia, mutta nämä ovat ennakoitavissa. Odottamattomat vaikutukset ja niistä syntyvät kus-tannukset on mahdotonta ennakoida varsinkin koska jokainen palveluverkostoon koh-distuva toimenpide, suunniteltu tai ennakoimaton, yleensä johtaa joukkoon uusia enna-koimattomia toimenpiteitä. Ennakoimattomien vaikutusten analysointi ja korjaus, yleen-sä kiireellä, on itsessään virhealtista työtä.

Käytännössä hallitsematon palveluverkosto toimii kustannustehokkaasti ainoastaan riit-tävän pienissä kokonaisuuksissa.

Mallintamalla formaalilla ja koneellisesti tulkittavassa muodossa palveluverkoston elin-kaarivaiheineen, pystytään palveluverkostoon kohdistuvien toimenpiteiden muutosvai-kutukset analysoimaan luotettavasti, kattavasti ja kustannustehokkaasti jo toimenpiteitä harkittaessa. Samalla liiketoimintaa kehittävien päätösten tueksi saadaan luotettava tieto muutoksen kustannusvaikutuksista jolloin kehittämisen kannattavuus voidaan aidosti arvioida.

Kuva 9 - Hallittu palveluverkosto

Taneli Hallanaro, johtaja, liiketoiminnankehitys 040-549 3521
Pauli Kilpikivi, johtaja, arkkitehtuurit 040-580 4820
Jan Mickos, kehityspäällikkö, liiketoiminnan kehitys 040-847 8740
Juha Martikainen, integrointiarkkitehti 040-503 3456