dynaaminen malli liiketoimintasovellusten ...puh. 017-162 802 [email protected] isbn 951-781-473-9 (koko...

PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 15 STUDIES AND REPORTS OF THE PLUGIT PROJECT 15

Harri Karhunen

D Y N A A M I N E N M A L L I L I I K E T O I M I N TA S O V E L L U S T E N I N T E G R O I M I S E K S I

KUOPION YLIOPISTO SAVONIA-AMMATTIKORKEAKOULU KUOPIO 2004

Teki jä: Harr i Karhunen Tietojenkäsit telyt ieteen laitos PlugIT-projekt i Kuopion yl iopisto Myynti : Tietotekni ikkakeskus / kansl ia Kuopion yl iopisto puh. 017-162 802 www.plugit . fi t [email protected] i

ISBN 951-781-473-9 (koko teos) ISBN 951-27-0234-7 (osa 15) ISBN 951-27-0254-1 (PDF) Kopi jyvä Oy, Kuopio 2004

Harri Karhunen. Dynaaminen malli l iiketoimintasovel lusten integroimiseksi. Painos. PlugIT-hankkeen selvityksiä ja raportteja 15. 103s. 2004. ISBN 951-781-473-9 (koko teos) ISBN 951-27-0234-7 (osa 15) ISBN 951-27-0254-1 (PDF)

Yleinen kymmenluokittelu UDK: 681.3 Asiasanat (YSA): komponentit, ohjelmistot, atk-ohjelmat, integraatio, sovellukset, verkkopalvelut

T I I V I S T E L M Ä

Tässä selvityksessä esitetään keinoja liiketoimintasovellusten yhteistoiminnallisuuden parantami-seksi palvelupohjaisessa ohjelmistoarkkitehtuurissa. Yrityksen tai yhteisön tuotantoprosessi näh-dään palveluiden muodostamana joukkona. Palvelu voi koostua useiden palveluiden yhteistyön tu-loksesta. Tavoitteena on kehittää ohjelmistoarkkitehtuuria siten, että palveluparadigman avulla voi-daan parantaa eri liiketoimintasovellusten integroitumista toistensa kanssa. Tavoitteena on osoittaa yrityksille polku, jota kohti kulkea, jotta yritykset saavuttaisivat liiketoimintatavoitteensa ja menes-tyisivät kilpailussa toisten yritysten kanssa.

Ohjelmistot tarvitsevat keinoja dynaamiseen kommunikointiin toimijaverkossa (many-to-many). Palvelupyynnön esittämisen ja suorittamisen tulee tapahtua turvallisesti, luotettavasti ja si-ten, että tiedon yhtenäisyys taataan kaikissa olosuhteissa. Lisäksi toiminnassa tulee huomioida or-ganisaation erilaiset vaatimukset:

- Hanketta varten tarvitaan erillisiä tiimejä. - Sovellus tai käyttäjä voi olla useassa tiimissä. - Käyttöoikeuksien hallinnan tulee tapahtua joustavasti. - Sovellusten kesken on kyettävä ylläpitämään kontekstia liiketoimintaprosessin toteuttami-

seksi. - Palvelun tuottamiseksi tarvitaan tuotantoprosessi. Tuotantoprosessi ja sen erityispiirteet on

hallittava.

Sovellusintegraatio tulee huomioida jo kehitysaikaisissa liittymissä ja on pyrittävä siihen, et-tä integrointi tapahtuu prosessi-integraation muodossa. Prosessi-integraatio mahdollistaa aikaisen kehittämisen ja myöhäisen sidonnan, jolloin integroituvien järjestelmien kehittäminen on helpom-paa, koska hyvin määritellyt integrointipisteet auttavat rajoittamaan sovellusten välisiä riippuvuuk-sia. Usein jo olemassa oleviin sovelluksiin joudutaan rakentamaan liittymiä toisiin ohjelmistoihin. Liittymien rakentaminen tulee toteuttaa hyödyntäen olemassa olevaa teknologiaa. Verkkopalvelui-den ja komponenttipohjaisen sovelluskehityksen yhdistämisen avulla voidaan erilaiset järjestelmät yhdistää ja taata tietoturva, transaktioiden hallinta ja riittävän luotettava toiminta kriittisissä liike-toimintajärjestelmissä.

Selvityksessä esitetään dynaaminen malli palvelupyyntöjen käsittelemiseksi. Malli perustuu hierarkiseen Broker-arkkitehtuurimalliin. Mallin avulla kuvataan organisaation toimintaa ja sääntö-jen avulla luodaan organisaation eri ohjelmistojen (ja käyttäjien) välille yhteistoiminnallisuutta. Mallin avulla luodaan universaali virtuaalikone, jonka kautta eri komponenttialustoilla toimivat ohjelmistot voidaan yhdistää yhdeksi toimivaksi kokonaisuudeksi.

E S I P U H E

Tämä selvitys on tehty PlugIT-hankkeessa sen TEHO-osaprojektissa vuosina 2003-2004. PlugIT-hankkeessa on tuotettu avoimia ohjelmistorajapintojen määrityksiä sekä niihin liittyviä menetelmiä ja osaamista terveydenhuollon ohjelmistoyrityksille ja niiden asiakkaille. TEHO-osaprojektin ta-voitteena on kehittää yhteistyöyritysten toimintaperiaatteita ja yhteisiä pelisääntöjä ja ratkaisuja ohjelmistotuotantoon, laadunvarmistukseen ja testaukseen. Tämä lisää yritysten tuotteiden integroi-tavuutta ja mahdollistaa kokonaisuuden integraatiotestauksen.

Tämän selvityksen lähtökohtana on ollut PlugIT-hankkeessa tehty kehitystyö. Tämä selvitys tutkii liiketoimintaprosessien integraatiota palvelukeskeisen ajattelutavan näkökulmasta. Selvitys esittelee mallin, jonka avulla liiketoimintasovellusten yhteistoiminnallisuutta voidaan lisätä. Malli on rakennettu mahdollisimman yleiseksi, jotta siitä voidaan rakentaa toimialakohtaisia toteutuksia. Lähtökohtana selvityksessä on ollut prosessikeskeisyys. Sen ansiosta malli soveltuu teollisuuden, kaupan ja palvelusektorin sekä myös terveydenhuollon sovellusten yhteistoiminnallisuuden paran-tamiseen. Hanke tukee terveydenhuollon palvelutoimintaa ohjelmistotuotannon palveluketjun kaut-ta, paremmin integroituvien ohjelmistokokonaisuuksien avulla.

Kohderyhmänä ovat yritysten ja organisaatioiden tietohallinnossa työskentelevät henkilöt. Selvitys pyrkii siihen, että yritysten ja organisaatioiden avainhenkilöt näkisivät informaatioteknii-kan tuomat mahdollisuudet keinona lisätä yrityksen toimintakykyä vastata asiakkaiden muuttuviin vaatimuksiin.

PlugIT-hanketta ovat rahoittaneet ja siihen ovat osallistuneet TEKES, Mawell konserni, Me-dimaker Oy Ltd, Medici Data Oy, Mediweb Oy, Mylab Oy, Tietoenator Oyj, WM-data Novo Oyj, Atkos Oy, BEA Systems Oy, Commit; Oy, Enfo Oy, Fujitsu Services Oy, General Electric Health-care CIS EMEA, Mediconsult Oy, Microsoft Oy, Oracle Finland Oy, Helsingin ja Uudenmaan sai-raanhoitopiirin kuntayhtymä, Pirkanmaan sairaanhoitopiirin kuntayhtymä, Pohjois-Savon sairaan-hoitopiirin kuntayhtymä, Pohjois-Pohjanmaan sairaanhoitopiirin kuntayhtymä, Satakunnan sairaan-hoitopiirin kuntayhtymä, Varsinais-Suomen sairaanhoitopiirin kuntayhtymä, Kuopion kaupungin sosiaali- ja terveyskeskus sekä Siilinjärven ja Maaningan terveydenhuollon kuntayhtymä.

Esitän kiitokseni jatko-opintojeni ohjaajalle Anne Eerolalle kriitikistä ja kannustuksesta. Kii-tän myös PlugIT-projektiin osallistuvien yritysten ja sairaaloiden edustajia hyvistä ideoista ja näkö-kulmista.

Kuopiossa 26. elokuuta 2004

Harri Karhunen

SISÄLLYSLUETTELO 1 JOHDANTO.................................................................................................................... 9

1.1 Tavoitteet .......................................................................................................... 9 1.1.1 Business to Business............................................................................... 9 1.1.2 Taustaa, tavoitteita ja vaatimuksia......................................................... 10

1.2 Ongelmat ja voimat ......................................................................................... 11 1.2.1 Ongelmat ............................................................................................... 11 1.2.2 Monoliittisten arkkitehtuurien ongelmat.................................................. 12 1.2.3 Voimat ................................................................................................... 12 1.2.4 Tutkimuksen sisältö ............................................................................... 13

1.3 Historiaa .......................................................................................................... 13 2 KONTEKSTI ................................................................................................................. 15

2.1 Yleistä ............................................................................................................. 15 2.2 Palvelukeskeinen arkkitehtuuri ........................................................................ 16 2.3 Verkkopalvelut (Web-services)........................................................................ 17

2.3.1 Bottom-up ja top-down........................................................................... 18 2.3.2 Etäproseduurikutsu (RPC Remote prosedure call) - ja viestipohjainen

(Message-oriented middleware MOM) -tyyli .......................................... 19 2.3.3 Web Services (WS) -verkkopalvelumäärittely........................................ 19

3 YRITYSPALVELUARKKITEHTUURI RATKAISUNA .................................................. 22 3.1 Yleistä ............................................................................................................. 22 3.2 Yritystason palveluarkkitehtuuri (Enterprise service architecture ESA) ........... 22

3.2.1 Yleistä.................................................................................................... 22 3.2.2 Standardit ovat elintärkeitä .................................................................... 23 3.2.3 Trendejä, jotka vaativat yritystason arkkitehtuuria ................................. 24 3.2.4 Arkkitehtuurin transformaatio................................................................. 24 3.2.5 Tietojärjestelmien evoluutio ................................................................... 24 3.2.6 Yritystason arkkitehtuurin (ESA) sisäinen rakenne................................ 25 3.2.7 Yritystason palveluarkkitehtuurin perusarvot ja merkitys ....................... 27 3.2.8 Komponentit ja palvelut, yrityssovellusten kerrokset.............................. 28 3.2.9 Yritystason arkkitehtuuri (ESA) ja liiketoiminnan lisäarvo (Business Value

of ESA) .................................................................................................. 29 3.2.10 Koostesovellukset eli komposiittisovellukset (Composite applications)29 3.2.11 Joustavuus ja yhdenmukaisuus (Compliance)..................................... 30 3.2.12 Esimerkkejä ......................................................................................... 31 3.2.13 Portaalien avulla käytettävyyttä erilaisiin tarpeisiin .............................. 33 3.2.14 Liiketoiminta-ajattelu ja arkkitehtuuri.................................................... 34 3.2.15 Arkkitehtuurin edut/haitat ..................................................................... 35 3.2.16 Yrityspalveluarkkitehtuurin luonne ja tavoitteet.................................... 36 3.2.17 Sovellusten luokittelua......................................................................... 37 3.2.18 Toiminta-alusta (Platform) ................................................................... 37

4 DYNAAMINEN MALLI SOVELLUSINTEGRAATIOON................................................ 39 4.1 Yleistä ............................................................................................................. 39 4.2 Dynaaminen arkkitehtuurimalli integroinnin suorittamiseksi ............................ 39 4.3 Hypoteesit ....................................................................................................... 40

4.4 Prosessin mallintaminen ................................................................................. 41 4.4.1 Prosessin mallintaminen........................................................................ 41 4.4.2 Prosessin palveluketju ........................................................................... 43 4.4.3 Järjestelmän määrittely ja palveluarkkitehtuurin tarve ........................... 46

5 ARKKITEHTUURIKUVAUS ......................................................................................... 48 5.1 Yleistä ............................................................................................................. 48 5.2 Uudet roolit – palveluintegraattori.................................................................... 50 5.3 Arkkitehtuurimalli ............................................................................................. 52 5.4 Komponentit ja komponenttikaavio.................................................................. 53 5.5 Komponentit ja komponenttien tehtävät .......................................................... 55

5.5.1 Yleistä.................................................................................................... 55 5.5.2 Asiakassovellus ja adapteri (Client Application and Adapter) ................ 55 5.5.3 Palvelun edustajakomponentti asiakkaalla ............................................ 58 5.5.4 Palvelukomponentti (Service component) ............................................. 59 5.5.5 Palveluagentti (Service Agent) .............................................................. 62

5.6 Palvelukomponentti koordinaation- ja transaktionhallinta................................ 63 5.6.1 Yleistä.................................................................................................... 63 5.6.2 Koordinaationhallinta hajautetussa ympäristössä.................................. 63 5.6.3 Komponentin tilat................................................................................... 67 5.6.4 Transaktioiden hallinta........................................................................... 68

5.7 Rajapinnat ja niiden operaatiot ........................................................................ 72 5.7.1 Yleistä.................................................................................................... 72 5.7.2 IAdapter................................................................................................. 73 5.7.3 IService.................................................................................................. 73 5.7.4 IMessage............................................................................................... 74 5.7.5 ITransaction........................................................................................... 75 5.7.6 IRules .................................................................................................... 75

5.8 Palvelypyyntö yhteistyökaavion avulla kuvattuna............................................ 75 5.9 Nimipalvelu...................................................................................................... 79

6 DYNAAMINEN ARKKITEHTUURI TERVEYDENHUOLLOSSA .................................. 81 6.1 Yleistä ............................................................................................................. 81 6.2 Terveydenhuollon yleinen palvelurakenne ...................................................... 81 6.3 Skenaarioita .................................................................................................... 83

6.3.1 Skenaario1: asiakkaan terveyskeskuskäynti ......................................... 84 6.3.2 Skenaario 2: asiakas kutsutaan lähetteen pohjalta sairaalaan .............. 85

7 YHTEENVETO JA TULEVAISUUDEN HAASTEET .................................................... 87 7.1 Implementaation ongelmia .............................................................................. 87 7.2 Tietojärjestelmät ja ohjelmistotoimittajat .......................................................... 87 7.3 Tulevaisuus ..................................................................................................... 88

8 LÄHTEET ..................................................................................................................... 90 LIITE1. SANASTO JA KÄSITTEET ................................................................................... 1 LIITE2. DOKUMENTTIPOHJAISET LIIKETOIMINTAPROTOKOLLAT (EBXML, ROSETTANET, XCBL)....................................................................................................... 1

SELVITYS 15 9

1 JOHDANTO

1.1 Tavoitteet

1.1.1 Business to Business Liiketoiminta vaatii yrityksiltä yhteistoimintaa ja verkostoitumista. Yritykset luovat yhteenliittymiä valmistaakseen palvelukokonaisuuksia asiakkaiden tarpeisiin. Yhdessä yritykset ja yritysten osaa-minen ovat enemmän. Asiakas esittää palvelupyynnön ja palveluntarjoajat muodostavat renkaan ja toteuttavat palvelupyynnön. Teknologian kehittyminen tarjoaa keinot yhteistoiminnan tehostami-seksi ja automatisoimiseksi.

Ohjelmistotekniikassa palvelukeskeinen arkkitehtuuri pyrkii toteuttamaan yritysten tarpeet. Palvelutuotanto on toteutettava tehokkaasti, dynaamisesti, luotettavasti ja turvallisesti. Verkkopal-velutekniikoiden ja komponenttitekniikoiden avulla voidaan luoda skaalautuva ympäristö yhteis-toimintaa varten (Sessions, 2000). Tuotantoprosessien toteuttaminen vaatii ohjelmistojen integroin-tia yhteistoiminnallisuuden aikaansaamiseksi. Integroinnin tulee tapahtua Prosessikeskeisesti (pro-cess-oriented). Yhteistoiminnallisuuden rakentaminen on tehokkaampaa tuotantoprosessin pohjalta, koska yhteistoiminnallisuus voidaan huomioida koko tietojärjestelmän kehityskaaren ajan (life-cycle). Prosessikeskeisyys mahdollistaa myös sovelluksen joustavamman muuttamisen. Integroin-nin ongelmana korostuu sekä yrityskulttuurien erilaisuus että yritysten tietotekniikkaratkaisujen heterogeenisuus. Verkottuminen muodostuu hankalaksi teknisten esteiden johdosta. Tehokkainta olisi, jos informaatiojärjestelmät voisivat kommunikoida standardilla tavalla ja niiden semantiikka (tiedon syntaksi ja merkitys) olisivat samat kaikilla yrityksillä. Valitettavasti näin ei ole ja siksi yri-tysten ja sovellusten välille joudutaan suorittamaan yhteensovittamista eli integrointia yhteistoimin-nallisuuden aikaansaamiseksi. Ihanteena on integraatio, johon organisaatiot voivat liittyä yhteisen rajapinnan kautta. Rajapinnan tulee olla niin yleinen ja yksinkertainen, että hyvinkin erilaisilla so-velluksilla on kyky hyödyntää rajapintaa.

Tässä dokumentissa pyritään esittämään yleinen arkkitehtoninen ratkaisu, joka on yleistettä-vissä yritysten väliseen integraatioon. Esitettävä dynaaminen malli on nähtävä abstraktina viiteke-hyksenä, johon voidaan peilata järjestelmän nykyistä tilaa ja jota kohti voidaan pyrkiä. Modernit ohjelmistotalojen sovelluspalvelimet sisältävät yleensä kaikki verkkopalvelujen rakentamiseen tar-vittavat komponentit kuten web-palvelimen, kehitystyökaluja mm. dokumenttien automaattiseen generointiin, integrointiin muiden järjestelmien kanssa sekä sovelluspalvelimen. Malli on tarkoitettu määrittely-, analyysi- ja suunnitteluvaiheen tarpeisiin. Rakentamisvaiheessa luodusta mallista teh-dään tekniikkariippuva toteutus.

Dynaaminen malli perustuu hierarkisten Broker-komponenttien käyttöön ja tarjoaa ansain-tamahdollisuuden yritysten välisten liiketoimintojen järjestelijälle ja soveltuu erinomaisesti esimer-kiksi erilaisten hankintarenkaiden rakentamiseen tai esimerkiksi teollisen tuotannon järjestämisessä. Terveydenhuollossa mallin avulla voidaan rakentaa esimerkiksi asiantuntijapalveluita tai luoda eri-laisia hoitoprosesseja, käyttää mallia potilashallinnossa sekä rakentaa käyttöliittymäportaaleja, joi-den avulla eri sovellusten toiminnallisuutta voidaan yhdistellä kunkin käyttäjäryhmän vaatimusten mukaisesti.

PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 15 10

1.1.2 Taustaa, tavoitteita ja vaatimuksia Tämä dokumentti on tarkoitettu johdatukseksi yritysten ja organisaatioiden tietohallinnossa työs-kenteleville henkilöille. Tavoitteena on antaa eväitä ohjelmistoarkkitehtuurin suunnitteluun. Doku-mentin ymmärtäminen edellyttää jonkin verran ohjelmistotekniikan käsitteiden tuntemusta. Doku-mentti on jatkoa PlugIT:n E2-projektissa kehitettyyn sovellusulokkeen avulla tapahtuvaan integraa-tioon, jossa määriteltiin ja suoritettiin kahdenvälistä integraatiota KYS:n Puijon Sairaalan gastroen-terologisen tutkimusyksikön ja kliinisen patologian laboratorion välillä. Integraatiotarve oli seuraa-va: Gastroenterologinen tutkimusyksikkö pyytää patologin lausunnon näytteestä lähettämällä lähet-teen patologille. Integraation avulla lähettävä järjestelmä käyttää vastaanottavan järjestelmän palve-luja mm. muodostaen omasta lausunnostaan pyynnön, täydentäen pyyntöä ja lähettäen sen vastaan-ottavaan järjestelmään. E2-projektissa sovellettiin PlugIT-hankkeessa kehitettyä integrointimenette-lyä. Integrointi suoritettiin kahdenvälisesti siten, että toisen sovelluksen sovellusuloke tarjosi toisel-le sovellukselle rajapinnan, jota toinen hyödynsi. Siirrettävä tieto sovellusten välillä muodostettiin rakenteisena dokumenttina XML-merkkauskielen avulla, jotta järjestelmän muutoksen takia ei in-tegrointia tarvitse suunnitella kokonaan uudelleen.

Kahden välinen integrointi ei kuitenkaan riitä yleiseksi ratkaisuksi liiketoimintaprosessien hallintaan. Tarvitaan yleisempi ratkaisu, joka mahdollistaa liiketoimintaa osallistuvien kumppanei-den yhteistoiminnan joustavammin ja useiden toimijoiden kesken. Tämän dokumentin mallin ta-voitteena on suorittaa integrointeja monesta-moneen-tyyppisesti (many-to-many) ja suoraan sovel-lusten kesken. Aluksi näkökulma oli bottom-up –tarkastelu, jonka pohjalta tutkittiin integraatiota ja sen ongelmia. Tarkastelukulma tutki suunnittelumallien avulla E2-arkkitehtuurimallia. Tutkimuksen pohjalta syntyi Broker-arkkitehtuurimalliin pohjautuva arkkitehtuurikuvaus. Mallissa tutkittiin pal-velupyyntöjen välitystä tavoitteena tehokas ja skaalautuva komponenttirakenne erilaisten sovellus-ten kesken. Mallin nimipalveluominaisuuksia suunnittelumallien avulla on tutkittu edelleen. Palve-lupyyntö voi muodostaa monimutkaisen tuotantoketjun, jossa transaktiot on hallittava. Palvelu-pyynnön kulloinenkin käsittelytilanne ja sisältö on hallittava, kun palvelu toteutetaan eri toimijoiden kesken. Sanotaan, että on hallittava konteksti (context management). Tutkittiin myös kontekstinhal-linnan ongelmankenttää hajautetussa verkkoympäristössä. Luotu arkkitehtuurikuvaus pyrkii yksin-kertaisuuteen ja joustavuuteen. Liiketoimintaprosessit voivat olla monimutkaisia. Pyrittäessä auto-matisoituihin tuotantoprosesseihin on prosessiin kyettävä tuomaan mukaan joitakin tekoälyyn liitty-viä piirteitä kuten yksinkertaista päättelyä (jos x niin y) ja toimintaskriptien toteutusta. Siksi avuksi tarvitaan ohjelmistoagentteja. Agentit ovat palveluohjelmistoja, joiden tarkoituksena on tutkia an-nettua tehtävää ja tehdä tarvittavia johtopäätöksiä. Agentilta vaaditaan jonkinlaista älykkyyttä, jotta se voisi suorittaa päättelyä (Autonomous Interface Agents, 1997).

Selvitysten perusteella kävi ilmi, että bottom-up -lähestymistapa on liian rajoittunut. Jos nä-kökulma on pelkästään tekninen, on tuloksena integraatio, joka voi olla toiminnaltaan tehokas, mut-ta joustamaton, koska tarkastelutapa ei huomioi liiketoimintaympäristöä ja sen asettamia vaatimuk-sia liiketoiminnan kehittyessä. Lähtökohdaksi on otettava top-down -lähestymistapa, mikä mahdol-listaa liiketoimintaprosessien huomioimisen integraatiovaatimuksia laadittaessa. Muita vaatimuksia ovat tekniikkariippumattomuus, skaalautuvuus, tehokkuus ja yksinkertaisuus. Top down –lähestymistapa tarkoittaa sitä, että lähtökohtana on tuotantoprosessi, jonka kaikki osat (=toiminnot) nähdään palveluina. Palvelut koostuvat toisista palveluista muodostaen toimintaverkon, joka toteut-taa tuotantoprosessin. Tekniikkariippumattomuus merkitsee sitä, että tämän määrittelyn mukainen järjestelmä on toteutettavissa kaikilla olemassa olevilla väliohjelmistoalustoilla. Skaalautuvuutta (scalability) tarvitaan, jotta järjestelmä selviää nopeista palvelupyyntöjen määrän muutoksista. Jär-jestelmän tulee olla tehokas, joten teknologiaa on sovellettava siten, että välitysjärjestelmän aiheut-tama tehokkuushäviö voidaan minimoida. Hajautettu tiedonvälitys lisää väistämättä monimutkai-suutta ja virheen syntymisen mahdollisuus kasvaa verrattuna monoliittiseen keskitettyyn järjestel-mään. Järjestelmän on tarjottava virheenkäsittely. Järjestelmän osien tulee olla mahdollisimman

SELVITYS 15 11

standardeja ja yksinkertaisia, jotta järjestelmä toimii luotettavasti ja virheenjäljitys on mahdolli-simman helppoa. Koska malli pohjautuu jo olemassa olevaan teknologiaan ja koettuihin käytäntöi-hin, on sen soveltaminen yritystasolla kohtuullinen tehtävä. Koska integroinnin lähtökohtana on prosessikeskeisyys, niin tehdyt integrointiratkaisut kestävät ja skaalautuvat paremmin yrityksen toimintojen kehittyessä ja muuttuessa.

Sovellusten esittämä palvelupyyntö muutetaan rakenteiseksi dokumentiksi XML-koodattuna SOAP-sanomaan paketoituna, joka toimitetaan vastaanottajalle. Kuopion yliopistolla on tutkittu XRake-projektissa (XBI/XRAKE-projekti 2002) merkintätapoja ja menetelmiä heterogeenisten järjestelmien integroimiseen XML-rajapintoja käyttäen. Plugit-hankkeessa on tutkittu kontekstin-hallintaa sekä eri järjestelmien välistä käyttäjän tunnistamista ja autentikointia. PlugIT:ssa on myös kehitetty suunnittelumenetelmä komponenttipohjaisten sovellusten kehittämiseksi. Tutkimusten tuloksia sovelletaan tässä mallissa soveltuvin osin. Sovellusten tarjoamat palvelut kuvataan verkko-palvelukuvauskielen (Web Service Description Language WSDL) avulla (Web Services Activity, 2004). 1.2 Ongelmat ja voimat

1.2.1 Ongelmat Eri organisaatioilla on käytössään sekä organisaation sisällä että organisaatioiden välillä runsaasti erilaisia ohjelmistoja, joiden kyky yhteistoimintaan toisten ohjelmien kanssa on puutteellista. On-gelmana on kuinka tarjotut palvelut löydetään, tunnistetaan ja kuinka palveluiden semantiikka kye-tään hallitsemaan. Lisäksi palvelua vailla olevan on kyettävä esittämään ja toimittamaan palvelu-pyyntö palvelua tarjoavalle sovellukselle ja päinvastoin. Lisäksi organisaatiot kehittyvät ja muuttu-vat nopeasti ajan mukana. Palvelupyynnön toteuttaminen toteutetaan usein verkostoituneesti, jolloin tuotantoprosessista voi muodostua monimutkainen ketju, jossa kunkin osan keskinäiset suhteet ja toteutusjärjestys on hallittava. Tarvitaan koordinaatiota. Asiakkaan pyytämä palvelu voi koostua useista palvelupyynnöistä. Koordinaation avulla asiakkaalle voidaan taata hänen haluamansa palve-lu. Koska palvelupyyntö koostuu erillisistä palvelupyynnöistä, joiden suoritukset voivat kokonais-palvelua koottaessa riippua toisistaan, tarvitaan transaktioiden hallintaa.

Ongelmaksi muodostuu muodostuvan palvelukokonaisuuden transaktioiden hallinta. Koska palvelupyyntöjen toteuttaminen tuotannossa voi muodostaa pitkän tuotantoketjun, jolloin reaaliai-kaisuuden vaatimusta ei voida toteuttaa, ei RPC-tyyliä voida käyttää prosessien toteuttamisessa. Lisäksi yhteistoiminnallisuuden toteuttaminen vaatii eri tiedostomuotojen ja tiedonsiirtotekniikoi-den hallintaa kuten rakenteiset dokumentit, binääritiedostot, kokonaisina (block) tai tietovirtoina (stream) siirrettävät dokumentit. Eri vaatimusten toteuttaminen standardilla tavalla voi olla mahdo-tonta, jolloin joudutaan rakentamaan ongelman ratkaisemiseksi epästandardeja ratkaisuja kuten pal-velupyynnön liitteenä toimitettavien binääritiedostojen kuten esimerkiksi kuvatiedostojen siirtämi-seksi pyynnön mukana osapuolelta toiselle. Tämä voi tapahtua esimerkiksi http-protokollan mukai-sesti MIME-koodattuna lohkoina (Alonso, 2004).

Eri yritysten järjestelmien integroiminen on kallista, hankalaa ja hidasta. Yhteistoiminnalli-suuden aikaansaaminen vaatii tiedolta formaalia esitysmuotoa. Jotta tietoa voitaisiin käyttää virheet-tömästi, on sen syntaksi kyettävä esittämään siten, ettei tiedon käsitteleminen aiheuta eri järjestel-missä virheitä (poikkeuksia). Tiedolla on myös merkitys. Tieto on kyettävä määrittelemään siten, että se merkitsee kaikille samaa ja vain samaa. Jo tiedosta sopiminen voi olla integraatiossa vaikeaa. Eräs ratkaisu tiedon ongelmaan ovat koodistot koodistopalvelimineen.

Aluksi ajateltiin, että verkkopalveluiden avulla muodostetaan yleisiä kauppapaikkoja, jossa yritykset tarjoavat palveluitaan ja josta asiakkaat löytävät palvelut ja kauppaa käydään automaatti-


sesti verkkopalveluiden avulla. Siihen on vielä pitkä matka. Ongelmana on luottamus. Kuinka voi-daan varmistua, että palveluntarjoajan identiteetti on se, miksi hän sen ilmoittaa, jottei tapahdu vää-rinkäytöksiä? Kuinka voidaan varmistaa tuntemattoman palveluntarjoajan tarjoaman palvelun laatu? Entäpä huomenna, onko palveluntarjoajaa olemassa? Yrityskumppaneiden on tunnettava toisensa, luotettava toiseen ja varsinkin, jos toisen palvelua käytetään osana omaa tuotetta, vaikuttaa huonon alihankkijan suorittama palvelu omaan yrityskuvaan. Verkottuminen tapahtuu suljetummin esimer-kiksi siten, että yritykset, jotka tuntevat toisensa, muodostavat tuotantorenkaita. Tai yritys voi ra-kentaa oman tuotemerkin alihankkijoiden palveluiden avulla vastaten palvelun laadusta.

1.2.2 Monoliittisten arkkitehtuurien ongelmat Palveluarkitehtuurin näkökulmasta monoliittisuus tarkoittaa kerran (one time), yhteen tarkoitukseen (one purpose) ja yhdellä tavalla (one way). Useimmilla yrityksillä ei ole ohjelmistoja, jotka toteut-taisivat yritystason arkkitehtuurin (ESA) periaatteita. Yritykset kärsivät tästä ongelmasta monin tavoin. Usein yrityksellä on useita ohjelmistoja, jotka on kehitetty tai hankittu koordinoimatta nii-den välistä yhteistoimintaa järjestelmällisesti. Seurauksena tästä on järjestämätön monimutkaisuus. Tässäkin tapauksessa automaation lisääminen onnistuu, se vain on kallista, hidasta ja lisää moni-mutkaisuutta entisestään. Monoliittisuuteen liittyvä tiukka sidonta (tight coupled) hidastaa kykyä muutoksiin. Tällöin yrityksen IT-osastosta tulee kehityksen jarru. IT-osasto suhtautuu kaikkeen kehitykseen negatiivisesti pyrkiessään välttämään työmäärän paisumista (”ei onnistu...”). Tämä hankaloittaa yrityksen liiketoimintastrategioiden suunnittelua ja toteutusta. Tarvitaan joustavuutta. Tiukka sidonta aiheuttaa sen, että johonkin ominaisuuteen vaadittu muutos voi vaikuttaa myös mui-hin tekijöihin. Esimerkiksi, jos CRM-järjestelmä käyttää toisen järjestelmän tietovarastoja. Tiukka sidonta merkitsee esimerkiksi sitä, että sen sijaan, että tietoja tarjoava sovellus tarjoaisi operaation avulla vastauksen tehtyyn kyselyyn (API-rajapinnan kautta), järjestelmän tietoja käytetäänkin sen tietokantaresurssin kautta. Mikäli tietokantaresurssiin tehdään muutoksia, on muutos huomioitava myös toisessa järjestelmässä. Mitä enemmän riippuvuuksia ohjelmistojen välillä on, sitä hanka-lammaksi ja kalliimmaksi muutoksiin vastaaminen ja ylläpito muodostuvat.

1.2.3 Voimat Palvelupyynnön esittäjän palvelupyyntö on välitettävä palveluntarjoajalle ja muunnettava palvelun-tarjoajan ymmärtämään muotoon. Sovellukset voivat toimia erilaisilla alustoilla. Sovellukset voivat olla perinnejärjestelmiä (legacy), joilla on erittäin vajavainen kyky yhteistoimintaan. Sovellusten välinen kommunikointi on kyettävä toteuttamaan joustavasti, tehokkaasti, turvallisesti ja skaalautu-vasti. Asiakkaan tulee kyetä esittämään palvelupyyntö usealle sovellukselle (one-to-many) ja asiak-kaan tulee kyetä saamaan vastaus monelta sovellukselta (many-to-one). Tarvitaan siis kykyä many-to-many –tyyppiseen viestintään.

Organisaatiot toimivat tiimeissä, joita on kyettävä muodostamaan dynaamisesti. Tämä tar-koittaa sitä, että muodostettaessa ryhmiä niiden käyttöoikeudet voidaan hallita oletusarvoisesti ryh-män organisatorisen aseman perusteella. Jotta tämä saavutettaisiin, on ohjelmistoilla oltava kyky mallintaa organisaatiota.

Liiketoimintaprosessit voivat olla monimutkaisia. Prosessi voi sisältää vaatimuksia suoritus-järjestyksestä. Prosessin aiheuttamat poikkeukset on osattava käsitellä. Prosessin on kyettävä esit-tämään vaihtoehtoisia skenaariota siitä kuinka menetellä kussakin tilanteessa.

Yritysten toiminta on dynaamista. Liiketoiminnan perusteet ovat aina samat. Kilpailukyky muodostuu siitä, kuka tuntee parhaiten asiakkaan tarpeet, tunnistaa oman liiketoimintansa vahvuu-det ja heikkoudet ja pystyy tarjoamaan asiakkaalle parasta mahdollista palvelua kilpailukykyisesti. Jotta tämä onnistuu, tarvitaan joustavuutta.

SELVITYS 15 13

1.2.4 Tutkimuksen sisältö Tutkimuksen toisessa luvussa käydään lävitse verkkopalveluiden perusteita. Kolmannessa luvussa tutustutaan yritystason palveluarkkitehtuureihin. Luvussa korostetaan yrityksen siirtymäpolkua mo-noliittisistä sovelluksista yhteistyötä tekeviin komponenttipohjaisiin sovelluksiin. Yritystason sovel-lusten yhteistoiminnallisuus toteutetaan verkkopalveluarkkitehtuurien avulla. Eri tilanteissa tarvi-taan erilaisia ratkaisuja. Yrityksen on kussakin tapauksessa mietittävä, mikä on sille parasta. Nel-jännessä luvussa esitellään dynaamisen integrointimallin teoreettinen perusta. Esitellään mallin perusarkkitehtuuri ja keskeisimmät hypoteesit. Liiketoimintaprosessin mallintamiseksi esitellään arkkitehtuurin määrittelyprosessi, jossa lähtökohtana ovat yrityksen liiketoimintaprosessit ja liike-toimintaentiteetit. Prosessit muodostavat palveluketjuja. Palvelukeskeisen arkkitehtuurin keskei-simpiä tehtäviä on prosessin mallintaminen. Viidennessä luvussa kuvataan dynaaminen arkkitehtuu-ri ja toimintaympäristö. Luvussa kuvataan komponentit, rajapinnat, koordinaationhallinnan ja trans-aktioiden perusteet. Luvussa kuusi sovelletaan dynaamista arkkitehtuuria terveydenhuollossa mal-lintamalla tuotantoprosessia palvelukomponenttien avulla. Kahden skenaarion avulla esitetään ku-vitteellinen tilanne sekä perusterveydenhuollosta että erikoissairaanhoidosta. Viimeisessä luvussa luodaan yhteenveto ja arvioidaan tulevaa kehitystä. 1.3 Historiaa

Tietojenkäsittelytehtävien historia voidaan jakaa kolmeen tai neljään jaksoon. 80-luvulle asti tieto-jenkäsittelytehtävät perustuivat eräajotyyppisiin järjestelmiin, jolloin ensin tallennettiin järjestel-mään tarvittavat tiedot ja tallennuksen jälkeen suoritettiin tarkistusajo ja varsinainen tuotantoajo. Teknologian kehittymättömyys ja kalleus johti siihen, että tietojenkäsittelyä käytettiin yritysten pro-sessien hallinnassa pääasiassa hallinnollisissa tehtävissä esimerkiksi henkilöstöhallinnossa ja las-kentatoimessa. Hallinnolliset tehtävät tarjosivat olemassa olevalle tietojenkäsittelymallille sopivia tehtäviä sisältäen lajittelu-, laskenta- ja tulostustehtäviä. Malli tarjosi mahdollisuuden palvelupoh-jaiseen tuotantoon, jossa tietojenkäsittelypalvelut ostettiin palveluoperaattorilta. Tällöin tallennus-vaihe tehtiin usein itse, ja operaattori suorittu tarpeelliset tietokoneajot ja toimitti asiakkaalle asiak-kaan tarvitsemat tulosteet. Käytetyintä tällainen ohjelmistopalvelu oli esimerkiksi palkanlaskennas-sa (palkka-ajot, tilipussit, maksatus) ja kirjanpidossa (kirjanpito, reskontrat, laskutus ja ulkoinen laskentatoimi).

Teknologia kehittyi. Halvat PC-laitteet, minitietokoneet ja mikroverkot laajensivat tietoko-neiden käyttöä ja loivat uusia käyttötapoja. Entistä tehokkaammat mikrotietokoneet tarjosivat käyt-töliittymänsä kautta mahdollisuuden tehdä reaaliaikaisia kyselyjä, päivityksiä ja tulostuksia. Aiem-min päivitys- ja kyselytehtävät pystyttiin tekemään ainoastaan suurten yritysten tietojärjestelmissä. Tietojen ja tietojenkäsittelyn hallinta siirtyi palvelukeskuksilta yrityksille. Yritykset omistivat usein laitteensa ja ohjelmistonsa. Teknologia tarjosi aiempaa paremman palvelukyvyn, ja tietojenkäsitte-lyä voitiin soveltaa uusissa liiketoimintatehtävissä. Lopulta Internet ja sen globaali rakenne mahdol-listi yritysten välisen tietojenvaihdon. Tyypillinen tälle ajalle ominainen yritysratkaisu oli usein se, että toimistopalvelut toimivat käyttäjien mikrotietokoneissa (fat client) ja yhteisiä palveluja olivat tiedosto- ja tulostuspalvelut (Sessions, 2000). Taloushallinto hoidettiin pääasiassa minitietokonei-den avulla, koska ohjelmistotoimittajat tarjosivat ohjelmistopalveluita omilla alustoillaan. Talous-hallinnon ohjelmistot olivat luonteeltaan monoliittisia ja niiden integrointi mikroverkkoihin oli vai-keaa.

90-luvun lopulla tietojenkäsittely oli osa jokaisen yrityksen arkea, se oli jokaisella työ-pöydällä. Tiedon ja tiedonkäsittelyn hallinta johti siihen, että tietojenkäsittelytehtävät suoritettiin hajautetusti verkossa. Ongelmaksi muodostui vaatimus ohjelmistojen yhteistoiminnallisuudesta, ylläpidettävyydestä ja järjestelmien hallinnasta. Pyrittiin vähentämään käyttäjän työpöytäkerroksen tehtäviä (workspace tier). Asiakaskerroksen tehtäviä siirrettiin sovellustason kerrokselle (thin-


client). Tavoitteena oli, että työpöytäkerros hallitsee sovellusten esittämisen (käyttöliittymän) ja varsinaiset työtehtävät keskitetään sovelluspalvelimille, jotka käyttävät tiedonhallintaan siihen eri-koistuneita tietokantapalvelimia. Siirryttiin komponenttipohjaiseen ajatteluun (component-oriented approach), mikä tarkoittaa sovellusten jakamista osiin siten, että näitä osia voidaan uudelleenkäyt-tää (Reuse) maksimaalisesti.

Pian havaittiin, että ohjelmistojen kyky yhteistoimintaan (interoperability) oli puutteellista. Internetistä oli jo muodostunut globaali kaikkialle ulottuvat tietoverkko. Tämän vuoksi ryhdyttiin kehittämään tekniikoita kuten ebXML liiketoimintojen dokumenttien vaihtoa varten (Top-down dokumenttipohjainen lähestymistapa) ja verkkopalveluarkkitehtuuri (Web Service Architecture WSA) ohjelmistojen operaatioiden hallintaan (bottom-up prosessipohjainen lähestymistapa), joiden avulla tietoverkon kautta voitiin vaihtaa palvelupyyntöjä tai dokumentteja yritysten välillä. Syntyi-vät verkkopalvelut (Web services). Jo hajautuksen käyttöönotto 90-luvulla loi monimutkaisen oh-jelmistoinfrastruktuurin. Verkkopalvelutekniikoiden käyttöönotto lisää edelleen monimutkaisuutta. Tämän vuoksi markkinoille on syntynyt tarvetta ja kysyntää palveluista. Vanha palvelukeskusajatte-lu uudessa muodossa on muodostumassa houkuttelevaksi ja kilpailukykyiseksi ratkaisuksi. Asiakas ostaa palveluita ja maksaa palveluista käytön mukaan. Ulkoistamalla osan toimintoja palveluiden avulla, yritys voi keskittyä ydintoimintoihinsa. Palvelutarjoaja voi erikoistua palvelutuotantoon ja tarjota asiakkailleen parasta mahdollista palvelua. Palveluntarjoaja voi ostaa osan palveluita toisilta palveluntarjoajilta ja niin edelleen. Palvelukeskeinen lähestymistapa (service-oriented approach) tuottaa yritysten kesken monipuolisia verkostoja, joissa toiminnan tehokkuus saavutetaan erikois-tumalla.

Ohjelmistot kykenevät automaattiseen yhteistoimintaan verkkopalveluiden avulla. Verkko-palveluiden avulla palvelujen rakenne ja semantiikka kuvataan, palvelut löydetään ja palveluja kut-sutaan. Yritykset voivat luoda yhteistoimintaverkostoja ja sovittaa tietojärjestelmänsä yhteen siten, että voidaan luoda palvelukokonaisuuksia. Yhteistoiminta ratkaistaan palvelukeskeisen arkkitehtuu-rin avulla (SOA Service-oriented Architecture). Palveluoperaattori saa tulonsa myymästään palve-lusta. Asiakas liittää omat tietojärjestelmänsä palveluun ja palveluoperaattori kokoaa oman palve-lunsa muista palveluista. Markkinoilla on tarvetta palveluintegraattorista (service integrator), joka liittää eri palvelut toisiinsa ja luo rajapinnan asiakkaan ja palvelun välille. Palvelukeskeinen toimin-tamalli muuttaa ohjelmistoliiketoiminnan ansaintalogiikkaa. Ohjelmistoyrityksen on kyettävä hyö-dyntämään palveluliiketoiminnan antamat mahdollisuudet ja parantamaan tuotteidensa ominaisuuk-sia siten, että niillä on tarvittava yhteistoiminnallisuus verkkopalveluympäristössä.

SELVITYS 15 15

2 KONTEKST I

2.1 Yleistä Tässä luvussa esitellään perusteet ja määrittelyä palvelupohjaisen arkkitehtuurin ymmärtämiseksi. Palvelut nähdään yritysten liiketoimintaprosessien toteuttajina. Liiketoimintasovellusten konteksti palvelukeskeisessä arkkitehtuurissa pohjautuu yhteisiin sopimuksiin, määrittelyihin ja standardei-hin. Ohjelmistot toimivat hajallaan verkossa. Ohjelmat ovat yhteistoiminnassa toistensa kanssa pyy-täen ja tarjoten palveluita. Palvelupyyntöjä esitetään myös eri organisaatioiden välillä. Organisaatiot toimivat joustavasti ja muodostavat erilaisia tiimejä hankkeiden toteuttamiseksi (Taulukko 1).

Taulukko 1: Tavoitteita ohjelmistojen välisessä integraatiossa

Yrityssovellusten integraatiotavoitteita (Goals for modelling enterprise integration) Sovellusten välinen yhteistoiminnallisuus (interoperability between applications) Dynaaminen käyttäytyminen (dynamic behaviour) Tekninen riippumattomuus ja läpinäkyvyys (technical independency, transparency) Aikainen suunnittelu, myöhäinen sidonta = uudelleenkäytettävyys (aarly design + late binding = software reuse Turvallisuus, luotettavuus, jäljitettävyys (security, reliability, traceability)

Asiakas esittää palveluoperaattorille palvelupyynnön. Asiakas ei tiedä kuinka palvelu raken-

netaan, asiakkaalle riittää tieto eli kuvaus siitä, millaisen palvelun hän saa sitä pyydettyään. Palve-luoperaattori koostaa asiakkaalle sopivan palvelun. Palvelu voi koostua muiden palveluntarjoajien palveluista. Palvelut kommunikoivat keskenään käyttäen välittäjää (Broker), joka integroi palvelut toisiinsa. Palveluintegraatio voidaan tarjota ulkopuolisena palveluna tai yritykset voivat verkostoi-tua ja rakentaa tarvitsemansa integraatiopalvelun (Kuva 1).

Service1

Service2

ServiceN

Client

Service

Kuva 1: Asiakas esittää palvelupyynnön

Jotta palvelupyyntöjen käsittelyssä saavutetaan riittävä skaalautuvuus (scalability), tulisi

kommunikaation olla asynkronista (asynchronous). Komponenttien tulisi olla tilattomia (stateless). Komponentit saavat tarvittavat tilatiedot taustalla olevalta tietokannalta (back-end data-base). Ti-


lattomuus mahdollistaa tehokkaan instanssien hallinnan (instance management), koska ei tarvitse pitää kirjaa siitä, monellako asiakkaalla on viite instanssiin. Jokaiselle asiakkaalle tarjotaan oma istunnon aikainen instanssi. Instanssien hallinta voidaan hoitaa joko alustamalla instanssi tarvitta-essa (JIT just-in-time) tai käyttäen instanssipoolia (instance pooling algorithm). Toinen mahdolli-suus on käyttää tilallista instanssia, jonka useat asiakkaat jakavat (shared instances) (Sessions, 2000).

Tilattomuuden tavoitteesta voidaan poiketa, jos (Sessions, 2000):

- Komponentin instanssilla voi olla tila, jos tila ei kohdistu tiettyyn asiakaskomponenttiin. - Olioiden ilmentymillä (object instance) voi olla tila, mutta ei komponentin ilmentymällä

(component instance). - Tarvittaessa komponenttiin voidaan laittaa tila. Tällöin komponenttia ei voi hallita instans-

sienhallinta-algoritmien avulla. Tässä tapauksessa instanssi varataan yhden proxyn käyttöön. Tätä kutsutaan keskustelevaksi moodiksi (conversational mode).

Komponentin alustana toimivalta sovelluspalvelimelta ja siinä toimivalta komponentilta vaaditaan ominaisuuksia (Sessions, 2000):

- Tilatiedot eivät ole instanssissa, koska instanssienhallinta voidaan suorittaa tehokkaasti in-stanssienhallinta-algoritmien avulla. Samoin säikeidenhallinta voidaan hoitaa automaattises-ti instanssienhallinta-algoritmien avulla.

- Voidaan hyödyntää kuormituksentasausalgoritmeja (load balancing algoritms). - Käytetään resurssipooleja (resource pooling). - Sidotaan metodit transaktioihin (transactional boundary). Transaktioiden hallinta kuuluu vä-

liohjelmistolle (middletier)-ohjelmistolle. - Turvallisuus (safety) on mukana komponenttiprosessissa. Tietoturva (security) kuuluu vä-

liohjelmistolle. 2.2 Palvelukeskeinen arkkitehtuuri

Palvelukeskeinen arkkitehtuuri (SOA Service-oriented architecture) määrittelee arkkitehtuuriset periaatteet itsenäisten systeemien yhteistoiminnan toteuttamiseksi. Systeemien autonomisuus (Au-tonomy) tarkoittaa niiden erillisyyttä, kykyä toimi itsenäisesti ja kykyä itse määritellä tarjoamansa toiminnallisuuden. Yhteistoiminnallisuus (interoperate) tarkoittaa kykyä toimia yhteistoiminnassa (ObjectWatch Newsletter Number 45).

Palvelukeskeisen arkkitehtuuri pohjautuu seuraaviin periaatteisiin (ObjectWatch Newsletter Number 45 ):

- Asynkroninen kommunikaatio sovellusten ja järjestelmien välillä. - Kyky käyttää heterogeenisia kommunikaatiokanavia eli erilaisten järjestelmien on kyettävä

yhteistoimintaan. - Tietoturvallisuustekijöiden huomioonottaminen eli tunnistaminen (identifiointi) ja varmen-

taminen (verifiointi ja sertifiointi) sekä kyky kommunikaation salaukseen. Osapuolet todis-tavat (Proof) identiteettinsä toiselle osapuolelle.

- Virheidenhallinta palveluketjussa (error management across the systems matrix). - Koska kommunikointi on asynkronista, tarvitaan työnkulun koordinaatiota (workflow coor-

dination), jotta voidaan seurata palvelupyynnön käsittelytilannetta. Synkronisessa kommu-nikaatiossa samaa tarvetta ei ole, koska palvelupyyntö käsitellään välittömästi.

SELVITYS 15 17

2.3 Verkkopalvelut (Web-services) Palvelukeskeisen arkkitehtuurin kommunikaatiokanava toteutetaan verkkopalvelujen (Web-services) avulla. Tällöin tietojenkäsittely on palveluorientoitunutta (SOA Service-oriented Comput-ing) (Standards for Service-Oriented Architecture, 2004).

Verkkopalvelut voidaan nähdä yhteisenä kommunikointikanavana, jossa sovitaan yhteinen tiedon esitysmuoto (syntaksi ja semantiikka) ja vaihdetaan informaatiota organisaatioiden välillä. Verkkopalveluiden autonomisuus mahdollistaa hyvinkin erilaisten sovellusten integroinnin, kuten esimerkiksi graafisten kuvantamisohjelmien ja tietokantapohjaisten sovellusten yhteistoiminnan. Menetelmän vahvuutena on se, että itse integraation tekninen toteutus ei rajoita verkottumista, vaan on mahdollista suorittaa aidosti integraatiota prosessikeskeisesti esimerkiksi mallintamalla liiketoi-mintaprosessia ja liiketoimintaentiteettejä ja yhdistelemällä entiteettejä ja operaatioita palvelukom-ponenttien avulla luoden tarvittavan yhteistoiminnallisuuden. Verkkopalveluarkkitehtuuri perustuu kerrosarkkitehtuuriin, jolloin pinoon liitetään yhä uusia abstraktioita. Usein joustavuuden lisäys johtaa suorituskyvyn (performance) laskuun. Eli yhteistoiminnallisuudesta joudutaan maksamaan. Kuvassa 2 on esitetty sovellusten välinen löyhä kytkentä (loose-coupled) käyttäen verkkopalvelu-tekniikoita.

Browser

HTML

ApplicationPresentation logic

ApplicationBusiness services

WM (Java,C#)

Hardware (OS)

XML +WS-*

Other applicationsBusiness services SQL RDBMS

Kuva 2: Verkkopalvelut ja sovellusten kommunikaatio (Standards for Service-Oriented Archi-

tecture, 2004) Verkkopalvelut toimivat kommunikaatiokanavana ja ne voidaan kuvata protokollapinon

(Web service stack) avulla. Protokollapino toimitetaan vastaanottajalle kulloinkin soveltuvaa kom-munikaatiokanavaa pitkin. Kuvassa 3 verkkopalvelupino muodostuu jakamalla palvelu abstraktiota-son mukaisesti. Liiketoimintaprosessi alkaa ylimmältä tasolta (service negotiation), jossa sovitaan verkkopalveluissa käytettävistä protokollista, viitataan prosessinmäärittelydokumenttiin, työnkul-kuun, transaktioihin ja prosessinkulkuun. Seuraavalla tasolla (workflow, discovery, registries) mää-ritellään työnkulku jollain työnkulun kuvaamiseen soveltuvalla XML-pohjaisella kuvausnotaatiolla (esim. WSFL , BPEL4WS). Tällä tasolla ovat määrittelyt palveluiden julkaisemiseksi ja löytämi-seksi (UDDI, ebXML Registry). Seuraavalla tasolla (Service description language) on palveluiden


kuvausdokumentti (WSDL, WSCL). Viestitasolla (Messaging) kuvataan viesti rakenteisen SOAP-dokumentin avulla. Kaikki liikenne kuljetaan lähettäjältä vastaanottajalle SOAP-sanomassa. Jotta sanoma voitaisiin siirtää teknisiä siirtoteitä pitkin vastaanottajalle, on sovittava siirtoyhteydessä käytettävästä protokollasta. Protokollina voidaan käyttää kaikkia soveltuvia protokollia kuten esi-merkiksi HTTP, HTTPS, FTP, IIOP, RMI ja SMTP. Käytännössä vain HTTP, HTTPS ovat suostel-tavia protokollia, koska eri järjestelmien palomuurit hankaloittavat muiden protokollien (porttien) käyttöä. Alimpana ovat liiketoimintanäkökohdat (business issues). Tässä kerroksessa sovitaan kaik-ki liiketoimintaan liittyvät asiat kuten standardit, palvelun laatukysymykset sekä palveluiden järjes-tämiseen ja organisointiin liittyvät kysymykset. Nämä päätökset ovat lähtökohtana verkkopalvelun toteuttamisessa (Web Service Architectures, 2002).

Kuva 3: Verkkopalveluprotokollapino (Web Service Architectures, 2002)

2.3.1 Bottom-up ja top-down Palvelupyynnön ja vastauksen rakentamiseksi tarvitaan yhteistoimintaa varten useita näkökulmia. Horisontaalinen näkökulma lähtee siitä, että pyritään kehittämään menettelyjä, jotka ovat yleisiä riippumattomia liiketoiminnan erityispiirteistä. Ajatuksena on, että määrittelyt soveltuvat kaikille sellaisenaan. Tämä lähestymistapa keskittyy bottom-up –tyylisesti teknisistä lähtökohdista lähtien yhteistoiminnallisuuden suunnitteluun. Esimerkiksi ensiksi määritellään asiakkaan toiminta-alusta (käyttöjärjestelmä, väliohjelmistot) ja yhteistoimintakanavat. Sen jälkeen tutkitaan olemassa olevat resurssit ja niiden tarjoama toiminnallisuus. Sen jälkeen kääritään olemassa olevat resurssit ja integ-roidaan niiden tarjoama toiminnallisuus yhtenäisen rajapinnan taakse. Lopuksi mukautetaan sovel-luslogiikan syötteet siten, että sovellusta voidaan käyttää asiakkaan käyttämän protokollan avulla käyttäen soveltuvia kanavia. Tätä lähestymistapaa joudutaan käyttämään silloin, kun integroidaan jo olemassa olevia järjestelmiä toisiinsa (Alonso ym., 2004).

Uutta järjestelmää suunniteltaessa luonteva lähestymistapa on top-down –tyyli. Ongelma-kenttää tarkastellaan kokonaisuutena ja määritellään toiminnallisuutta jakaen ongelmakenttä pie-nempiin osiin. On tutkittava myös, mitkä kerrokset eli esitys, sovelluslogiikka tai resurssikerros (presentation tier, application logic tier, resource management tier) on tarpeen toteuttaa hajautettu-na. Tällä periaatteella suunniteltu uusi järjestelmä toteuttaa yleensä yhtä järjestelmäarkkitehtuuria, josta johtuen sen osien (komponenttien) välille muodostuu yleensä tiukka sidonta (tight coupling). Tämä tarkoittaa sitä, että komponenttien välillä on riippuvuuksia, jolloin muutos yhdessä kom-ponentissa voi johtaa muutokseen toisessa komponentissa, jos rajapinnat muuttuvat.

SELVITYS 15 19

2.3.2 Etäproseduurikutsu (RPC Remote prosedure call) - ja viestipoh-jainen (Message-oriented middleware MOM) -tyyli

Verkkopalvelujen perustyyli on etäproseduurikutsujen käyttö (RPC-tyyli), jolloin asiakas on vailla palvelua ja pyytää palveluntuottajalta palvelua ja jää odottamaan vastausta. Vastaus kyselyyn saa-puu sovitun ajan puitteissa tai käsittely päättyy poikkeukseen (esim. timeout). RPC-tyyli ei kuiten-kaan sovellu pitkäkestoisten palvelupyyntöjen toteuttamiseen, vaan tällöin joudutaan yhteistoiminta rakentamaan viestipohjaisesti (message-oriented). Viestipohjaisuus tarkoittaa sitä, että asiakas lä-hettää palvelupyynnön omaan lähtevään työjonoonsa, josta se aikanaan siirtyy palveluntarjoajan saapuneitten pyyntöjen työjonoon odottamaan käsittelyä. Verkkopalvelumääritelmät pyrkivät ku-vaavamaan yhteistoimintaa horisontaalisesti, mikä tarkoittaa sitä, että ne ovat toteutettavissa alasta ja sovelluksesta riippumatta. Alakohtaiset erityispiirteet kuten koodistot, esitysmuoto ja dokument-timallit on sovittava erikseen (Alonso ym., 2004).

2.3.3 Web Services (WS) -verkkopalvelumäärittely Verkkopalvelut pohjautuvat rakenteisiin dokumentteihin. Palvelupyyntö kuljetetaan SOAP-sanomassa osapuolelta toiselle. Sanoma sisältää liiketoiminnan palvelupyynnön (operaatio paramet-reineen tai dokumentti). Omana kerroksenaan on huomioitava tietoturva, luotettavuus, koordinointi ja transaktioidenhallinta. Sanoman rakentamiseksi voidaan käyttää esimerkiksi dokumenttipohjaista OASIS:ksen ebXML-arkkitehtuuria (ebXML, 2004), (kts. Liite 2) tai IBM:n ja kumppaneiden ke-hittämää prosessilähtöistä verkkopalveluarkkitehtuuria (Service Oriented Architectures and Web Services, 2004). Prosessikeskeisyys tarkoittaa tässä sitä, liiketoimintaa tarkastellaan matalantason operaatikutsuina ja näiden kutsujen parametreina. Lähtökohta keskittyy liiketoimintaprosessin ku-vaamiseen ja toteuttamiseen toimijaverkossa (Alonso ym., 2004).

Verkkopalvelut määritellään standardisoituna tapana integroida web-perustaisia sovelluksia käyttäen XML, SOAP, WSDL ja UDDI-standardeja. Nämä standardit ovat avoimia, joten niistä ei tarvitse suorittaa lisenssimaksuja. Sen sijaan lisäpalvelut kuten WS-Security, WS-Reliable Messa-ging, WS-Transactions, WS-Trust –määrittelyt eivät ole avoimia määritelmiä ja ovat siten riskejä integraation rakentajalle (Alonso ym., 2004).

Palvelupyynnön välittämiseksi ja automatisoimiseksi tarvitaan (Ferris ym., 2003):

- Palvelun löytäminen rekisterin "puhelinluettelon" avulla. Esimerkiksi UDDI (Version 3) on OASIS:n määrittely (UDDI.org, 2004).

- Palvelun ominaisuuksien kuvaaminen rakenteisen dokumentin avulla. W3C:n suositukset kattavat SOAP:n (Version 1.2) ja WSDL:n (version 2.0 working draft) (Web Service Activ-ity Statement, 2002).

- Liiketoimintaprosessit toteutetaan palveluiden avulla. Palveluketjun hallintaan tarvitaan pro-sessinhallintavälineitä. Palvelukokonaisuuden toteuttamiseksi palvelujen toteuttamisketju siis se, missä järjestyksessä palvelut toteutetaan, on kuvattava standardilla tavalla. Palvelu-ketjun kuvaaminen voidaan tehdä esimerkiksi BPEL –kielellä (BPEL4WS Business Process Execution Language for Web Services) (BPEL4WS Specs. 1.1, 2003).

- Palvelun semantiikan kuvaaminen automatisointia varten (semanttinen web) (McIlraith ym., 2003),

- Tietoturva, luotettavuus, transaktioiden hallinta, palveluiden koordinaatio, luottamus toteu-tetaan käyttäen komponenttipohjaisia väliohjelmistoja. Sovelluspalvelinten välistä yhteis-toimintaa varten on laadittu määrittelyjä kuten esimerkiksi WS-security, WS-reliable messa-ging,. Web-service coordination ,WS-transactions, WS-trust.

- Verkkopalvelujen luotettavuus (WS-reliable messaging) merkitsee, että taataan toimituksen perillemeno ja että viesti menee ainoastaan kerran (ei duplikaatteja). Malli käyttää consu-


mer/producer –suunnittelumallia, jos palvelun laatu (quality of service) on omana kerrokse-naan. Viestin luotettavuus voidaan varmistaa joko request/response, callback tai poll –menettelyillä (Alonso ym., 2004).

- Verkkopalvelujen koordinaatio (WS-coordination) on kehys, joka koostuu aktivointipalve-lusta, rekisteröintipalvelusta sekä joukosta koordinaatioon liittyvistä koordinaatioprotokol-lista. Koordinaation avulla voidaan hallita hajautettujen sovellusten operaatioiden toteutusta, voidaan luoda konteksti ja julkaista toiminto toisissa palveluissa ja suorittaa koordinaatio-protokollan rekisteröinti. Kehys mahdollistaa transaktioiden prosessoinnin, työnkulun hal-linnan sekä muiden järjestelmien toimintojen koordinoinnin heterogeenisessa ympäristössä (WS-coordination, 2003).

- Verkkopalvelujen turvallisuus (WS-security) takaa sovellusten turvallisen viestienvaihdon, jossa sovellusten kesken voidaan vaihtaa mm. käyttäjätunnuksia ja salasanoja (WS-security, 2002). Verkkopalvelujen luottamus (WS-trust) auttaa osapuolia vaihtamaan valtuutustietoja (credentials) (WS-trust, 2004). Sun ja joukko muita yrityksiä ovat alkaneet laatia omaa verkkopalvelustandardia (Web Ser-

vices Composite Application WS-CAF) suositusta, jonka avulla on tarkoituksena mahdollistaa komposiittisovellusten (composite application) rakentaminen. Suositus koostuu kolmesta määritel-mästä (WS-CAF Announcement, 2004):

- Kontekstinhallinta (Web service context WS-CTX), joka yksinkertainen kehys kontekstin-hallintaan, jonka avulla osallistuja voivat jakaa saman kontekstin ja vaihtaa informaatiota.

- Koordinaationhallinta (Web service coordination framework WS-CF) määrittelee ohjelmis-toagentin ominaisuudet kontekstinhallitsemiseksi. Koordinaattori varmistaa, että viestit ja tulokset kommunikoivat asianmukaisesti niin, että jonkin palvelun toteutuminen tai virhe-toiminto voidaan sitoa osaksi suurempaa kokonaisuutta ja luoda siten verkkopalvelukoko-naisuuksia.

- Transaktionhallinta (Web services transaction management WS-TXM) määrittelee transak-tioprotokollat, jotka voidaan liittää (plugged) koordinaatiokehykseen ja luoda yhteistoimin-taa transaktiomanagereiden, pitkäkestoisten tapahtumien ja asynkronisten liiketoimintapro-sessien kesken. Sen tarkoituksena on olla siltana erilaisten transaktionhallintamallien välillä kuten esimerkiksi MQ Series:n ja JMS:n välillä. Kuvassa 4 on esitetty IBM:n verkkopalveluiden pino (Web Services Stack).

Kuva 4: Verkkopalvelupino (Curbera ym., 2003)

SELVITYS 15 21

Näitä määrittelyjä tehtäessä lähtökohtana on ollut bottom-up näkökulma, jolloin määrityksiä

on laadittu teknisistä lähtökohdista. Tavoitteena on, että määrittelyä voidaan soveltaa mahdollisim-man monessa integrointiratkaisussa (horisontaalinen näkökulma). Edelleen tavoitteena tehostaa ohjelmistokehitystä ja parantaa ohjelmistojen ylläpidettävyyttä, edullisemmin (cost-effective) ja yksikertaisemmin.


3 YR I TYSPALVELUARKK ITEHTUUR I RATKA I SUNA

3.1 Yleistä Tässä luvussa on johdatus yrityspalveluarkkitehtuureihin (enterprise service architecture). Tavoit-teena on selvittää yrityssovellusten erikoispiirteet integraation kannalta. Johdatus pohjautuu pääosin Dan Woods:n näkemyksiin (Woods, 2003).

Informaatiotekniikan markkinoilla on tultu vaiheeseen, jossa tietotekniikan käytön lisäämi-nen arvotetaan kustannusten leikkaamisen (cost-cutting) ei niinkään innovaatioiden lähteenä. In-formaatioteollisuus on alana kypsymässä. Ala kasvaa ja kasvua haetaan sovellusten paremmasta yhteistoiminnasta ja automaation lisäämisestä liiketoimintaprosesseissa. Tämä merkitsee liiketoi-mintasovellusten yhteistoiminnan kehittämistä ja automaation laajentamista alkaen keskuskoneym-päristöistä laajentuen työasemiin, asiakas/palvelinjärjestelmiin ja Internettiin sekä myös sovelluk-siin kuten ERP (Enterprise Resource Planning), henkilöstöhallinnon ohjelmistoihin (HR human resources), asiakkuuden hallintaohjelmistoihin (CRM customer relationship management) ja toimi-tusketjunhallinta (SCM supply chain management). Lähes kaikkia ajateltavia tarpeita varten on teh-ty ohjelmistoja.

Informaatiotekniikkaa hyödyntävä yritys haluaa saada teknologian hyödyntämisen avulla kilpailuetua. Teknologia nähdään keinona toteuttaa yrityksen tavoitteet. Yritys haluaa hyödyntää hankkimansa ohjelmistot siten, että se voi niiden avulla kehittää ja toteuttaa liiketoimintaansa ja olla yhteistoiminnassa muiden yritysten kanssa. Tavoitteena on myös automatisoida rutiinitoimintoja eli siirtää staattiset liiketoimintatapahtumat (kerta toisensa jälkeen samanlaisina toteutettavat tuotanto-prosessit) koneiden tehtäväksi. Tällöin tuotantoketjut ylittävät yrityksen ja ulkomaailman rajat ulot-tuen alihankkijoihin, tavarantoimittajiin, asiakkaisiin. Tämä aiheuttaa ongelmia automaation kan-nalta. Yritysten rajat ylittävä automaatio on kallista ja vaikeaa. Informaatiotekniikasta on muodos-tunut pullonkaula yritysten välisen automaation kehittämisessä ja toteuttamisessa. Porttaaliteknolo-gian avulla voidaan erilaisten sovellusten välistä yhteistoimintaan lisätä. Verkkopalvelut, XML-standardit ja muut integraatiotekniikat lisäävät yhteistoiminnan mahdollisuuksia. Pelkkä porttaalien rakentaminen tai verkkopalveluiden käyttö yksinään ei ratkaise liiketoimintaprosessien automaa-tiotarvetta. Tällä hetkellä yrityksissä olevat sovellukset eivät ole valmiita yhteistoimintaan. 3.2 Yritystason palveluarkkitehtuuri (Enterprise service archi-

tecture ESA)

3.2.1 Yleistä Yritystason palveluarkkitehtuurin (ESA Enterprise Services Architecture) avulla yritykset ja niiden muodostamat verkostot voivat luoda ja organisoida yhteistoimintaa. ESA ei ole yksittäinen tuote, vaan ajattelutapa (filosofia), joka ohjaa yrityksen IT-arkkitehtuuria sen pyrkiessä lisäämään liiketoi-mintojensa tuottamaa lisäarvoa.

ESA:n ydin koostuu komponenttien muodostamasta kerroksesta, joka rakentaa tiedosta ja sovellusten toiminnallisuudesta käyttökelpoisia ja uudelleenkäytettäviä moduuleita. Komponentit

SELVITYS 15 23

kommunikoivat käyttäen yrityspalveluita (mm. verkkopalvelut). Yrityspalvelut vähentävät kompo-nenttien välisten yhteyksien monimutkaisuutta ja sallivat uudelleenkäytön.

Yritysten siirtyminen kohti yritystason palveluarkkitehtuuria tapahtuu vähitellen hybridivai-heen kautta. Tämä tarkoittaa sitä, että monoliittisiin sovelluksiin rakennetaan sovittimia, joiden avulla niiden tarjoamia palveluita voidaan käyttää yritystason palveluarkkitehtuurissa. Lopputulok-sena on tilanne, jossa sovellukset rakentuvat komponenteista, joilla on kyky yhteistoimintaan mui-den komponenttien kanssa. Tuotantoprosessi koostuu koostesovelluksista (composite application), jotka on rakennettu markkinoilta saatavilla sekä itse rakennetuilla komponenteilla. Yrityksellä käy-tössään oleva arkkitehtuuri muodostuu ajan mittaan tehdyistä kehityspäätöksistä ja niiden toteutuk-sesta. ESA on analyysi arkkitehtuurin rakentamisesta sekä ne toimenpiteet, joiden avulla analyysin vaatimat valinnat toteutetaan, jotta käytettävissä olevien teknologioiden avulla voidaan tuottaa liike-toiminnalle lisäarvoa.

ESA:n lisäarvo ja vaatimukset yritykselle:

- Liiketoiminta vaatii yrityksiltä lisää joustavuutta, ja ESA mahdollistaa joustavan toimintata-van.

- Mahdollistaa arkkitehtuurin, joka rakentuu komponenteista ja palveluista. - ESA:n alusta muodostaa rakenteen, jonka avulla yrityksen tarjoamat palvelut (enterprise

services) voidaan toteuttaa ja luoda lisää arvoa liiketoiminnalle. - ESA vaikuttaa koko tuotantoketjuun: yrityksiin ja yhteistyökumppaneihin, teknologiatoimit-

tajiin (technology vendors) ja lopulta koko talouteen. USA:n kansantalouden tuottavuuden etumatka eurooppalaiseen verrattuna, johtuu paljolti

tietotekniikan paremmasta soveltamisesta. Ero on suurimmillaan aloilla, joissa jakelutieratkaisuissa voidaan hyödyntää automaatiota kuten vähittäiskauppa, tukkukauppa ja finanssiala (Baes, 2004). Näillä aloilla USA:n yritykset pyrkivät parempaan yhteistoiminnallisuuteen käyttäen yrityspalvelu-arkkitehtuureja.

Yrityspalveluarkkitehtuurit tarjoavat yrityksille standardin tuotantokanavan, jota voidaan verrata esimerkiksi autoteollisuuden tuotantoprosesseihin. Tähän pääseminen vaatii, että yritykset ymmärtävät paremmin tuotantoprosessinsa sekä prosessin rakenteen siten, että siitä voidaan analy-soida sekä staattiset (muuttumattomat) että dynaamiset prosessit. Toistaiseksi komponentteja on saatavilla vain perusosiin kuten esimerkiksi relaatiotietokantoihin, web-palvelimiin tai selaimiin. Ongelmana ovat eri valmistajien tuotteiden yhteensopivuusongelmat. Vaikka eri tuottajien kom-ponentit olisi rakennettu noudattaen yhteisiä standardeja, voivat standardit olla liian yleisiä tai kom-ponentit voivat sisältää ylimääräisiä piirteitä. Käyttötarkoitukseen sopivan komponentin löytäminen on vaikeaa.

3.2.2 Standardit ovat elintärkeitä Standardit eli sopimukset toimintatavasta ovat tärkeitä. Tuotantoprosessin IT-palvelujen standar-dardisoinnissa on kaksi osaa: koko yritysarkkitehtuurin sekä yksittäisten komponenttien suunnittelu. Yritysarkkitehtuurin suunnittelu tarkoittaa sitä, kuinka yksittäiset komponentit toimivat yhdessä toteuttaakseen yrityksen tuotantoprosessin. Myös yritystason sovellusten rakenne on tärkeää. Haas-teena yritysarkkitehtuurissa on luoda toimintaympäristö, jossa komponentit voivat toimia yhdessä ilman tarvetta palata takaisin monoliittisiin sovelluksiin.


3.2.3 Trendejä, jotka vaativat yritystason arkkitehtuuria Tehokas tuotantoketju vaatii, että yritys avaa tietojärjestelmänsä ytimen ja integroi sen toimitusket-jun muiden toimittajien järjestelmiin. Toimitusketjun automatisointi on tässä avainasemassa. Alati muuttuvissa olosuhteissa sekä ketjulta että sen jäseniltä vaaditaan joustavuutta, nopeutta ja tehok-kuutta. Tehtävä on vaativa, järjestelmän tulisi olla tehokas, luotettava, turvallinen sekä ennen kaik-kea joustava.

Asiakkuuden hallinta ja asiakkaiden merkityksen kasvu vaativat myös joustavuutta. Uudet tiedonvälityskanavat kuten Internet, ovat lisänneet asiakkaiden vaikutusmahdollisuuksia. Toinen trendi on tietokoneiden välisen viestinnän lisääntyminen kuluttajien, toimittajien, alihankkijoiden, rahoittajien sekä muiden yrityksen ja sen sidosryhmien välillä. Monella yrityksellä on ongelmana se, että niiden jäykkä informaatiojärjestelmä ei kykene mukautumaan asiakkaiden tarpeisiin ja yri-tys ei tämän vuoksi kykene hyödyntämään kaikkia markkinoilla olevia mahdollisuuksia.

Verkkopalvelut jakelutienä antavat mahdollisuuksia uusille toimijoille. Uusien markkinara-kojen hyödyntäminen on joustaville, nopeille yrityksille helpompaa kuin monoliittisia sovelluksia käyttäville staattisille yrityksille. Yritykset nähdään sekä toisten yritysten että asiakkaiden taholta joukkona palveluita. Yritykset pyrkivät differoimaan tarjoamansa palvelut sillä, kuinka ne palvelut toimittavat ja millaisia palveluita ne toimittavat. Pyrkiessään saamaan tuotteilleen lisäarvoa asiak-kaiden silmissä joustava ja nopea yritys pystyy paremmin reagoimaan markkinoiden vaatimuksiin.

3.2.4 Arkkitehtuurin transformaatio Koska tietotekniikka ei ole arvo sinänsä, vaan tuotannontekijä, johon panostetaan vain, jos siitä us-kotaan saatavan lisäarvoa (ROI), on yritystason arkkitehtuurin (ESA) kyettävä vastaamaan odotuk-sia:

- Ratkaisun on perustuttava jo olemassa olevaan teknologiaan, koska uuden testaamattoman teknologian käyttöönottaminen sisältää omat riskinsä.

- Arkkitehtuuri on suunniteltava siten, että on olemassa selkeä käsitys olemassa olevasta jär-jestelmästä ja yrityksen liikestrategiasta.

- Arkkitehtuurin on perustuttava löyhästi kytkettyihin komponentteihin ja palveluihin tarjoten mahdollisimman paljon joustavuutta edullisin kustannuksin.

- Koska IT-infrastruktuuriin tehtävien muutosten yksikköhinta alenee, voidaan liiketoiminto-jen vaatimia erilaisia strategioita toteuttaa nopeammin ja joustavammin.

- Kyky muuttaa IT-infrastruktuuria nopeammin kuin kilpailijat tukee evolutiivista strategiaa ja mukautumiskyky tuottaa merkittävää kilpailuetua suhteessa kilpailijoihin. Tästä on seurauksena se, että IT-strategia ei voi olla enää hajautettu vaan sen on tuettava ha-

jautusta. Kaikkien sovellusten on puhuttava samaa kieltä. Sovelluksen hajautus on rakennettava siten, että sen osat mikäli mahdollista käyttävät samaa kieltä. Tällöin prosessi säilyttää dynaamisuu-tensa ja joustavuutensa.

3.2.5 Tietojärjestelmien evoluutio Yritysten informaatiojärjestelmien kehitys ja käyttöönotto viime vuosisadan jälkipuoliskolla poh-jautui sekä teknologian kehitykseen että IT-tietojärjestelmien massatuotannon markkinoiden synty-misen hintoja alentavaan vaikutukseen. Nopean kehityksen on mahdollistanut kyky tuotteistaa tek-niset innovaatiot ja tuoda ne markkinoille nopeasti.

Ensimmäinen tekijä koostuu viimeisen 30 vuoden aikana tapahtuneesta ohjelmistokehityk-sestä yrityksissä. Aluksi tietojärjestelmiä käytettiin keskuskoneympäristössä (mainframe) lähinnä

SELVITYS 15 25

talouden ja erilaisissa kontrollitehtävissä. Asiakas/palvelin-arkkitehtuurin hyödyntäminen lisäsi järjestelmiin joustavuutta ja toi järjestelmät pienempien yksikköjen saataville ja lisäsi tietotekniikan käyttöä. Tällöin syntyi ohjelmistoja mm. henkilöstöhallinnon (HR human resource) ja myynnin automatisointia varten. Verkon valtakausi toi uusia sovelluksia asiakkuudenhallintaan (CRM Cus-tomer relationship management), toimitusketjun valvontaan (SCM Supply chain management) sekä toimittajien suhteiden hallintaan (SRM), joiden avulla tuotantoprosesseja voitiin automatisoida. Tämän seurauksena yritysten ohjelmistot koostuvat erilaisten sovellusten sekoituksesta ja nämä ohjelmat on usein hankittu useilta toimittajilta.

Toinen tekijä koostuu infrastruktuurin evoluutiosta. Tämä tarkoittaa rinnakkaista alustojen ja työkalujen kehitystä. Tähän ryhmään kuuluvat käyttöjärjestelmien, väliohjelmistojen ja relaatiotie-tokantojen kehitys. Komponenttijärjestelmien alustat sisältöjen hallitsemiseksi, tiedonlouhinta ja sovellusten integrointi tarjoavat vahvat eväät asiakassovellusten rakentamiseksi ja laajentavat jo olemassa olevien perinne- ja yrityssovellusten toiminnallisuutta.

Kolmantena evoluutiota vauhdittavana tekijänä voidaan nähdä kommunikaatiokanavien ke-hittyminen. Tiedonvälitysstandardien kuten TCP/IP:n käyttö sekä Internet:n käyttö ovat luoneet keinot palveluntarjoajien ja asiakkaiden väliseen kommunikaatioon. Yhteinen kanava mahdollisti sovellusten välisen kommunikaation syntymisen. Tähän aikakauteen kuuluvat verkkosuuntautunei-den yrityssovellusten (network-oriented applications) ja alustakomponenttien (platform com-ponents), kuten sovelluspalvelimien ja yrityssovellusintegraatiojärjestelmien, syntyminen (EAI En-terprise application integration). Tieto valmistellaan yritystason arkkitehtuuria varten varten XML:n avulla.

Kaikista edellä luetelluista tekijöistä merkittävin yritystason arkkitehtuurin kehittymiseen vaikuttava tekijä on verkkopalvelujen kehittyminen (Web Services). Verkkopalvelut tarjoavat uni-versaalin liittymän sovellusten väliseen kommunikaatioon, jossa sovellukset voivat kuvata tarjoa-mansa palvelut, asiakkaat tutkia ja käyttää palvelua kuvauksen mukaisesti sekä palveluntarjoaja toteuttaa palvelu itsenäisesti muista riippumatta ja tarvittaessa muita hyväksikäyttäen (loose coup-led). Toisin kuin alustariippuvat (=sovelluspalvelin) teknologiat kuten DCOM, CORBA, EJB, .NET verkkopalvelutekniikka tarjoaa riippumattoman kanavan tiedonvälitykseen kunhan osapuolet nou-dattavat tiedonvaihdossaan yhteistä tiedonesitysmuotoa. Siirrettävä tieto kuljetetaan standardilla tavalla osapuolelta toiselle esimerkiksi XML-merkattuna SOAP-sanomissa. Verkkopalvelutekniik-ka ja sen yksinkertaisuus toteutuksen osalta jättävät tietojärjestelmän ja sovellusten vastuulle tieto-turvan (security), turvallisuuden (safety) vastuun viestin perillemenosta (quaranteed delivery, re-liability) sekä transaktiohallinnan (transaction management).

Verkottuva yhteistoiminta vaatii prosessienhallintaa. Prosessienkuvaukseen on XML:n poh-jalta kehitelty useita kuvauskieliä. OASIS:n dokumenttipohjainen ebXML-standardi kuvaa liike-toimintaprosesseja osapuolten kesken dokumenttipohjaisesti. Liiketoimintaprosesseja mallintavia kuvauskieliä ovat mm. IBM:n ja Microsoftin BPEL4WS Business Process Execution Language for Web Services sekä vastaava BPML Business Process Modeling Language ja myös W3C:n WSCL Web Service Choreography Language. Yhteistä määrittelyille on se, että ne kuvaavat osapuolten vaihtamaa sanomaa rakenteisesti pyrkien mallintamaan prosessia ja sen osanottajien roolia sekä prosessin operaatiota siten, että osapuolet ymmärtävät toisensa. Useiden määrittelyjen käyttö laajas-sa mitassa ei ole suotavaa vaikka ohjelmistotoimittajien ohjelmistot kykenisivätkin tulkkaamaan kunkin määrittelyn mukaisen dokumentin ja viestin. Jatkossa käyneekin niin, että olemassa olevista määrittelyistä jokin muodostuu tai niistä rakentuu jokin uusi standardi (de facto-standardi) kuvaa-maan liiketoimintaprosesseja.

3.2.6 Yritystason arkkitehtuurin (ESA) sisäinen rakenne Sovellusten rakenne on kehittynyt täysin monoliittisista (keskuskoneympäristöt) osittain monoliitti-siin kaksi- ja kolmikerrosarkkitehtuurimalleihin (two or tree tiers). Tällä hetkellä yritysten infor-


maatiojärjestelmät ovat monoliittisten ohjelmistojen muodostamia kokoelmia, joissa eri ohjelmisto-jen yhteistoiminta toteutetaan joko monoliittien tarjoamien API-rajapintojen kautta tai tietokeskei-sesti käyttämällä yhteisiä tietovarastoja tai toisen sovelluksen ylläpitämää tietokantaa. Näiden oh-jelmistojen käytettävyyttä voidaan parantaa esimerkiksi luomalla käyttöliittymiin työpöytäintegraa-tiota synkronoimalla ohjelmistot tietoon siten, että käsiteltävän tiedon tunnistetiedon muuttuessa yhdessä ohjelmistossa, muuttuu käyttäjän työpöydällä myös muiden ohjelmien tunnistetieto. Sovel-lusten toisiltaan tekemiä kyselyjä varten tarvitaan API-rajapinta, johon kussakin sovelluksessa jou-dutaan rakentamaan sovelluskohtainen sovitin, jonka avulla voidaan toisen monoliitin palveluita hyödyntää.

Yritystason palveluarkkitehtuuri (ESA) pyrkii siihen, että monoliittisten sovellusten integ-rointi olisi entistä helpompaa. Integrointitarpeita ovat mm. käyttöliittymien parempi integrointi, sovellusten parempi yhteistoiminta, uudelleenkäytettävyyden lisäys. Tavoitteena on, että päästään sovellusten välisistä sovittimien rakentamisesta koko arkkitehtuurin kattavaan ratkaisuun, jossa so-velluksille rakennetaan vain yksi sovitin, jolla sovellus liitetään palveluarkkitehtuuriin. Ohjelmisto-toimittajat rakentavat ohjelmistonsa sellaiseksi, että ne ovat aidosti komponenttipohjaisia ja kyke-nevät joustavasti osallistumaan yritysarkkitehtuuriin sen jäsenenä. Välivaiheena siirryttäessä kohti aitoja komponenttipohjaisia sovelluksia on ns. hybridivaihe, jossa monoliittiset sovellukset ja aidot komponenttipohjaiset sovellukset toimivat rinnakkain. Yritysarkkitehtuuri rakentuu sovelluksista ja koostesovelluksista (composite applications), jotka lisäävät järjestelmän toiminnallisuutta. Käyttö-liittymien rakennetta yksinkertaistetaan niin, että käyttäjälle rakennetaan usein yhteen liittymään kokonaisuus, jolla käyttäjä liittyy useaan sovellukseen ja voi näin esimerkiksi käsitellä tietoa yhte-näisellä tavalla (vrt. työpöytäintegraatio). Käyttäjä ei ole enää suoraan yhteydessä monoliittiseen kokonaisuuteen, vaan komposiittisovellus (composite application) huolehtii monoliittisen sovelluk-sen ja käyttäjärajapinnan välisestä kommunikoinnista (Kuva 5).

Enterprise servicesfor CRM

Database

User interface

Enterprise servicesfor ERP

Database

User interface

Enterprise servicesfor SCM

Database

User interface

Compositeapplications



Kuva 5: Yrityspalveluarkkitehtuuri (Woods, 2003)

Tavoitteena rakennettaessa hyvää yritystason palveluarkkitehtuuria on, että monoliittiset so-

vellukset jaetaan palveluiksi (yhdeksi tai useammaksi tai yksi palvelu koostuu yhdestä tai useam-masta sovelluksesta) siten, että rajapintoja ei enää linkitetä monoliittisiin sovelluksiin. Koostesovel-lusten avulla luodaan näistä sovelluksista (monoliiteista) uutta toiminnallisuutta, jota tarvitaan yri-tyksen toimintojen automatisointiin. Tavoitteena on parantaa tietojärjestelmän käytettävyyttä ja luo-da uusia palveluita käyttäjille ja yrityksille. Yllä kuvattu toiminnallisuus ei ole mahdollista maail-massa, jossa monoliittiset sovellukset esittävät toiminnallisuutensa API-rajapintojensa kautta. Tar-

SELVITYS 15 27

vittava toiminnallisuus rakennetaan yleiskäyttöisten sovittimien kautta (Kuva 6). Toiminta-alusta tarjoaa palvelut kommunikointia varten ja niiden avulla voidaan kommunikoida toisten komponent-tien ja muiden kerrosten kanssa. Käyttäjän käyttöliittymä räätälöidään noudattaen tiettyjä rooleja ja prosesseja yhdistellen sovellusten tarjoamia palveluita. Koostesovellukset (composite applications) yhdistelevät komponentteja ja sovelluksia luoden uusia käyttötarkoituksia. Komponenttipohjainen integraatio tarjoaa joustavan tavan integroida toiminnallisuutta.

Enterprise Service Architecture Platform

ESA Platform Structure

Monolithicapplication

Database

User interface

Monolithicapplication

Database

User interface

service

service serviceservice

serviceservice

User InterfaceCompositeapplications

service

Component-based

integrationservice

CRMERP

Kuva 6: Yritystason palveluarkkitehtuurin toiminta-alustan rakenne (mukaellen Woods, 2003)

3.2.7 Yritystason palveluarkkitehtuurin perusarvot ja merkitys Yritystason palveluarkkitehtuurin (ESA) perusarvot koostuvat: abstraktiosta, malleista, komponen-teista, olioista, palveluista, prosesseista ja löyhästä kytkennästä sovellusten välillä. Abstraktion avulla kätketään tekniikan monimutkaisuus. Modulaarisuuden avulla monimutkainen kokonaisuus jaetaan pienempiin osiin, joista kukin sisältää riittävästi toiminnallisuutta, jotta se kykenee suorit-tamaan tietyn rajatun tehtävän. Arkkitehtuuri liittää modulaariset osat käyttäen palveluita. Palvelu on kuvaus komponentin tarjoamasta tietystä rajapinnasta, joka toteuttaa jonkin toiminnon. Löyhä kytkentä (loose coupling) tarkoittaa sitä, että palvelun tarjoama rajapinta paljastaa mahdollisimman vähän (tai ei mitään) palvelun takana olevasta palvelun implementaatiosta (toteutuksesta). Löysä


kytkentä toteutetaan kitkattomasti verkkopalveluiden avulla. Löyhästi kytketyt palvelut voivat liit-tyä yhteen ja tarjota koostepalveluita, tai palvelut voidaan purkaa helposti toiminnallisiin kom-ponentteihinsa. Löyhä kytkentä vaatii osapuolten välille yhteisen käsitteistön eli kontekstin. Kon-tekstin avulla osapuolet ymmärtävät toisiaan. Osapuolten on luotava yhteinen jaettu semanttinen kehys, jotta voitaisiin varmistaa se, että viesti kulkee yhtenäisenä (consistent) osapuolten välillä (Loose Coupling, 2004). Tarvitaan koordinaation hallintaa.

Yritystason palveluarkkitehtuurin kehitysprosessi on inkrementaalinen. Arkkitehtuuri raken-netaan vähitellen lähtien olemassa olevasta tilanteesta ja miettien, mitä tarpeita ja muutoksia tule-vaisuus mahdollisesti tuo tullessaan. Tällöin joudutaan mallintamaan tuotantoprosessia ja mietti-mään, mitkä osat prosessista ovat muuttumattomia (static) ja mitkä muuttuvia (dynamic). Samoin joudutaan miettimään, mitkä prosessit ovat ydinliiketoimintaa (core) ja mitkä toiminnot ovat kon-tekstia (context). Ydinliiketoiminnat pidetään yleensä omassa hallussa, sen sijaan kontekstitoimin-not voidaan ulkoistaa. Palvelukomponentteja suunnitellessa, vaaditaan komponenteilta joustavuutta eri tavalla. Jos jonkin palvelun ajatellaan olevan muuttumaton (vaikkapa palkkahallinto) nähtävissä olevassa tulevaisuudessa, ei sille vaadita joustavuutta. Jos on oletettavissa, että palvelu muuttuu usein, joudutaan muutoksen aiheuttamat vaatimukset huomioimaan ja rakentamaan se komponen-teista siten, että muutokset voidaan helposti modifioida (esimerkiksi vaihtamalla jokin osakom-ponenteista uuteen).

3.2.8 Komponentit ja palvelut, yrityssovellusten kerrokset Komponentit ja palvelut parantavat monoliittisten sovellusten puutteita. Yritystason palveluarkki-tehtuuri (ESA) voidaan nähdä polkuna tiukasti toisiinsa sidotusta monoliittisesta arkkitehtuurista kohti löyhästi sidottuja eli riippumattomia komponentteja ja palveluita. Jokaisessa yritysarkkiteh-tuurin toteuttavassa sovelluksessa voidaan erottaa perusrakenneosat. Kuvassa 7 kuvataan yritysso-vellusten rakenneosat, jotka koostuvat sovelluskerroksista (application stack).

User Interface

ProcessServicesObjects

Persistence

Kuva 7: Yrityspalveluarkkitehtuurin sovelluspino (Woods, 2003) Käyttäjäkerroksen (user interface layer) tehtävänä on kommunikoida käyttäjän kanssa. Pro-

sessointikerros (process layer) on vastuussa siitä, mikä on käyttäjän toimintaprosessin kulloinenkin vaihe, ja johtaa palveluiden toteuttamista ja liiketoimintaentiteettejä, jotta tehtävä tulisi suoritettua. Palvelukerros (services layer) liittää komponentin toiseen komponenttiin ja toimii usealla tasolla. Olioiden metodit voidaan nähdä palveluina. Oliokerros (object layer) sisältää liiketoimintaentiteetit, jotka ovat kokoelmia tiedosta (data) ja palveluista (services), jotka ylläpitävät ja esittävät tiedon muunnokset eli tehtävän toteuttamiseen tarvittavat tietotyypit. Varastointikerros (persistence layer) varastoi olioiden sisältämän tiedon. Komponentit rakennetaan näistä elementeistä koostuen olioista, palveluista ja prosesseista, jotka ovat suhteissa toistensa kanssa. Yleisellä tasolla voidaan sanoa, että

SELVITYS 15 29

komponentti yhdistää monet näistä elementeistä ja kommunikoi ulkopuolisen maailman kanssa yk-sinkertaistetun palvelujoukon avulla, joka on komponentin abstraktio. Komponentin rakeisuus voi olla suuri tai pieni. Useat sovellukset voivat työskennellä yhdessä tarjotakseen yhden komponentin. Toisaalta yksi sovellus voi osallistua usean komponentin toteuttamiseen. Komponentti voi myös luoda näkymiä toisiin komponentteihin. Palvelut kytkevät komponentit toisiinsa. Olioiden metodien voidaan ajatella olevan palveluita. Nimipalvelun salliva verkkopalvelu voi myös olla palvelu. Yri-tyspalvelu voi olla verkkopalveluiden joukon yhteenliittymä, joka toteuttaa jonkin yleisen toimin-non esimerkiksi kontrolliprosessin, joka luo uuden asiakastietueen.

3.2.9 Yritystason arkkitehtuuri (ESA) ja liiketoiminnan lisäarvo (Bu-siness Value of ESA)

Yrityspalveluarkkitehtuurin rakentaminen yrityksessä lähtee olemassa olevasta ohjelmistosta ja ra-kentamisessa on tavoitteena:

- automatisoida ne toimintoprosessit (cross-functional processes), jotka ylittävät olemassa olevien järjestelmien ja organisaation rajat,

- tukea sellaisia strategisia prosesseja, jotka vaativat joustavaa työnsuorittamista (workflows) ja yhteistoiminnallisuuden integrointia ja sellaista ei-rakenteista tietoa kuten dokumentteja ja laskentataulukoita rahoituksen ja erilaisten operaatioiden järjestelmiin, joissa tarvitaan transaktioiden hallintaa,

- laajentaa olemassa olevaa liiketoimintasovelluksen käyttäjäkuntaa organisaatiossa laajenta-malla käyttäjien määrää ja parantamalla erilaisten roolien tukea tarjoamalla uusia käyttäjära-japintoja,

- tiukempi integraatio järjestelmän toimittajien ja avainkumppaneiden välillä, - asiakkaiden, toimittajien ja avainkumppaneiden suora pääsy omaan järjestelmään, - parantaa markkinoinnin tukitoimintoja, - parantaa muutoksenhallintaprosessia.

3.2.10 Koostesovellukset eli komposiittisovellukset (Composite ap-plications)

Koostesovellukset (packaged composite applications) koostuvat eri lähteistä koostuvista sovelluk-sista, komponenteista ja palveluista, jotka koostetaan palvelukeskeisen arkkitehtuurin (SOA) avulla. Komponentit voivat olla yksittäisiä verkkopalveluita, toisista sovelluksista valittua toiminnallisuutta tai kokonainen järjestelmä, joka on paketoitu verkkopalveluksi. Usein nämä kokonaiset järjestelmät ovat perinnejärjestelmiä (Loosely coupled, 2004).

Koostesovellukset ovat ylimpänä kerroksena yritystason palveluarkkitehtuurissa. Alla olevat sovellukset voivat olla näkymättömiä komposiittisovellukselle. Tämä ristiin tapahtuva toiminnalli-suus (cross-functional) laajentaa järjestelmän toiminnallisuutta. Komponentit, joilla on transaktio-ominaisuudet, jäljittävät tietokannan tietueita. Niitä voidaan täydentää komponenteilla, jotka hoita-vat ei-rakenteista tietoa, mitä löytyy dokumenteista, sähköposteista ja keskusteluryhmistä. Tiedosto-jenjakaminen (file sharing) voidaan hallita ja koordinoida keskitetysti. Kuvassa 8 on kuvattu verk-kopalvelujen ja yritysarkkitehtuurien integrointi. Integroinnissa käytetään hyväksi komposiittipalve-luita, joiden avulla toteutetaan liiketoimintaprosessi ja hallitaan siihen liittyvät liiketoimintayksiköt (liiketoimintaentiteetit, -oliot).


Kuva 8: Verkkopalveluiden integroinnin perusteet

(Using Model Driven Architecture to Develop Web Services, 2002)

3.2.11 Joustavuus ja yhdenmukaisuus (Compliance) Yrityspalveluarkkitehtuuri kuvataan seuraavin joustavuusnimikkein (compliance), jotka kuvaavat myös arkkitehtuurin kehitystilaa:

- Ensimmäisellä tasolla (Level 1) kyetään ymmärtämään ja dokumentoimaan yrityksen tar-joama tieto, liiketoimintaentiteetit, palvelut ja prosessit.

- Toisella tasolla (Level 2) järjestelmän liiketoimintaentiteetteihin päästään käsiksi (Read/write) siten, että järjestelmän yhtenäisyys voidaan säilyttää kaikissa tilanteissa.

- Kolmannella tasolla (Level 3) kyetään käyttäjärajapinta erottamaan muusta järjestelmästä niin, että palveluita voidaan käyttää komponentteina komposiitti-käyttäjärajapinnoissa (Composite user interfaces) tai toisissa järjestelmissä.

- Tasolla neljä (Level 4) tiedot ja toiminnot ryhmitellään komponenteiksi ja palveluiksi. Komponentit suunnitellaan siten, että niiden välillä vallitsee löyhä sidonta (loosed coupled).

- Ylimmällä tasolla (Level 5) on määritelty prosessit ja ne ovat konfiguroitavissa siten, kom-ponenttien käyttäytymistä voidaan helposti muuttaa (Woods, 2003) (Kuva 9).

SELVITYS 15 31

Level 5: Process Control

Level 4: Loosely Coupled Components and Services

Level 3: User Interface Abstraction

Level 2: Data Services

Level 1: The Big Think

Compliance

Kuva 9: Yhdenmukaisuus, kypsyys (Woods, 2003)

3.2.12 Esimerkkejä Esimerkkeinä arkkitehtuurin soveltamisesta esitetään toimitusketjun ja valmistuslinjojen tuotanto-laitteiden ylläpidon hallintajärjestelmä ja niiden arkkitehtuuri. Kuvassa 10 on kansainvälistä liike-toimintaa harjoittavan jotain tuotetta valmistavan yrityksen monimutkainen yritysarkkitehtuuri. Yri-tyksen markkinointistrategia perustuu siihen, että se suunnittelee tuotantonsa itse, mutta hoitaa jake-lun toimittajiensa (suppliers) avulla kuluttajalle. Tuotanto (manufacturers) ja kuljetus (shipping consolidators) sekä tukkuporras (distribution centers) on ulkoistettu. Toimitus-ketjun automaatio hoitaa tuotantoprosessin, jossa valmistusta tehdään useassa maassa. Tuotanto-prosessia hallitaan myös monessa maassa. Hoidettaviin tehtäviin kuuluvat mm. tuotesuunnittelu, kysynnän vaatimus-tenhallinta, toimitusten suunnittelu, tuotannon suunnittelu, asiakkuudenhallinta, työlainsäädännön hallinta ja logistiikan hallinta. Kaiken lisäksi järjestelmän tulee kyetä hallitsemaan suuretkin vaihte-lut (volatility), joita tapahtuu markkinoiden kysynnässä ja tuotannon määrässä ääripäinä vähäisen volyymin erikoistuotteet ja massamarkkinoiden hintaherkät (price-sensitive) tuotteet.

Arkkitehtuurin voidaan ajatella olevan kolmitasoinen: Ylimpänä ovat käyttöliittymiä tarjoa-vat portaalit, suunnitteluun ja koordinointiin erikoistuneet komposiittisovellukset sekä koordinointi-välineet. Välikerroksena on yritystason palveluarkkitehtuurin alustalla toimivat komponentit, jotka toteuttavat abstraktin tuotantoprosessin komponenttiensa avulla käyttäen verkkopalvelutekniikoita. Alimpana ovat verkoston jäsenten (mm. alihankkijoiden) tietoj�

dynaaminen malli liiketoimintasovellusten ...puh. 017-162 802 [email protected] isbn 951-781-473-9 (koko...

Documents