Jrjestelmien integroinnista SOA an SOA Service Oriented Architecture

Järjestelmien integroinnista SOA: an SOA - Service Oriented Architecture, Helsinki, 29. 3. 2007 Juha Mykkänen, FT, tutkijatohtori Kuopion yliopisto, HIS-tutkimusyksikkö juha. mykkanen@uku. fi

Esityksen sisältö • • Yhteentoimivuus: mistä se muodostuu Eri tyyppisiin integrointivaatimuksiin vastaaminen SOA ja standardointi Palveluarkkitehtuurin hyödyt ja niiden arviointi • Konteksti: terveydenhuollon tietojärjestelmät – tietointensiivisyys, laajuus (puolet maailman käsitteistä liittyy lääketieteeseen / terveydenhuoltoon) – heterogeenisyys (esim. KYS 180 tietojärjestelmää, monet käytössä >10 v) - ei liikkeelle "puhtaalta pöydältä" – esityksessä poimintoja soveltavasta tutkimuksesta n. 7 v • komponentit -> sovellusintegraatio -> palvelupohjaisuus – väitöskirja "Specification of Reusable Integration Solutions for Health Information Systems", 01/07 • esityksen pyrky: integraatio SOA-näkökulmasta Järjestelmien integroinnista SOA: an 2

Konteksti: terveydenhuollon prosessit ja ohjelmistot • terveydenhuollon prosessit ja toiminta – useat prosessit vuorovaikutuksessa – paljon "poikkeuksia" usein pitkäkestoisissa prosesseissa – paljon ihmisten välistä kommunikaatiota, vain osa tehtävistä sovelluksissa / formalisoitavissa – asiantuntijuuden ja ammatillisten roolien korostuminen – eri organisaatioiden, ammattilaisten ja asiakkaiden osin ristiriitaiset tavoitteet • ohjelmistot ja tietojärjestelmät – – runsaasti sovelluksia esim. sairaaloissa, heterogeenisyys tiedon ja tietämyksen määrä kasvaa säilytys-, saatavuus- ja turvallisuusvaatimukset olennaisia runsaasti valmista pohjaa järjestelmissä ja aiemmin tehdyissä integraatioissa – uudet lähestymistavat sovitettava olemassa oleviin ratkaisuihin Järjestelmien integroinnista SOA: an 3

Taustaa: Ser. API: Palveluarkkitehtuuri ja websovelluspalvelut terveydenhuollon ohjelmistotuotannossa ja integraatiossa • • Tekesin Finn. Well-ohjelmaan kuuluva hanke, 3 vuotta, 9/04 - 8/07 14 yritystä, 4 shp/terv. huollon organisaatiota, 3 tutkimusyksikköä Joustavuus ja liitettävyys: SOA ja web services Keskeiset näkökulmat: Terveydenhuollon prosessit, Ohjelmistotuotteet, Teknologia-alusta • Avoimet ohjelmistorajapinnat ja integraatio: – mm. Kontekstinhallinta, Ajanvaraus, potilasryhmittelyt (DRG ja perusterveydenhuollon avohoidon potilasryhmitys), Päätöksentuki, OID, potilaslistat, käyttäjä- ja potilastietojen rajapinnat, koodistorajapinnat • Standardointi – HL 7 Finland Common Services SIG taustaprojekti – Healthcare Services Specification Project (HL 7 ja OMG-standardointijärjestöt) • Käytännössä: soveltamiskohteita ja tarpeita sairaaloista ja tuotteista, tuloksina palvelurajapintoja ja arkkitehtuurimäärityksiä, menetelmiä, esimerkkitoteutuksia ja selvityksiä, "katse yli seuraavan vuosineljänneksen" Järjestelmien integroinnista SOA: an 4

Keskeiset näkökulmat tarkemmin (SOA-viitekehys: monimutkaisen elefantin voi syödä vain pala kerrallaan) Järjestelmien integroinnista SOA: an 5

Yhteentoimivuus (interoperability)

Organisaatioiden toiminnan ja arkkitehtuurien kehitys 1970 -luku 1980 -luku 1990 -luku 2000 -luku Toimintamalli Hierarkkinen organisaatio, toimintojen nopeus ja laatu Toimintayksiköt, prosessien tunnistaminen ja määrittely Toimitusketjut, alueellinen yhteistoiminta Globaali ja virtuaalinen, mukautuva prosessi -orientoitunut toiminta Sovellusarkkitehtuuri Heijastaa toiminnan rakennetta, tietokantojen hallintajärjestelmät, integroidut tietokannat Asiakas-palvelinarkkitehtuurit, oliopohjaisuus, kolmitasoarkkitehtuurit, erilliset käyttöliittymät, sovelluslogiikka ja tiedot, jaettu tietoarkkitehtuuri Monitasoarkkitehtuurit, hajautetut oliot, komponenttipohjaiset järjestelmät, viestipohjainen yksiköiden välinen integraatio, työnkulkujen hallinta, standardit Verkkosovellukset, palvelupohjainen integraatio, dynaamiset, joustavat ja komponenttipohjaiset sovellukset, peer-to -peer yhteistoiminta ICT- infrastruktuuri Keskuskoneet, minitietokoneet, terminaalikäyttö Työasemat ja palvelimet, graafinen käyttöliittymä, LAN Sovelluspalvelimet, web, WAN, langattomuus Web, sovellus- ja integrointipalvelimet, mobiilikäyttöliittymät, gridtekniikat Järjestelmien integroinnista SOA: an 7

Tietojärjestelmiin kohdistuvia tarpeita [Pekka Kähkipuro] Järjestelmien integroinnista SOA: an 8

Hankintavaihtoehtojen monipuolistuminen Osta valmis tuote Toteuta itse Teetä uusi järjestelmä Suunnitteluta ulkopuolisella Osta ja räätälöi järjestelmä Vuokraa ulkopuoliselta (ASP) Osta ja integroi komponentit Toteuta vanhan järjestelmän sovittimena Laajenna sovelluskehyksestä Kirjaudu käyttämään verkon kautta Järjestelmien integroinnista SOA: an 9

Yhteentoimivuus-käsitteen merkitykset Järjestelmien integroinnista SOA: an 10

Integrointitasot – mitä sovittava sovellusten yhdessä toimimiseksi • järjestelmän elinkaari • toiminnallinen ja tietoarkkitehtuuri • sovellusarkkitehtuuri • tekninen arkkitehtuuri • ratkaistava kaikissa sovellusintegraatiotilanteissa [Peter Herzum, Oliver Sims] Järjestelmien integroinnista SOA: an 11

SOA what: interoperability • SOA: lähestymistapa, jossa tietojärjestelmät ja prosessit koostetaan sovelluspalveluista – SOA ei ole arkkitehtuuri, mutta arkkitehtuuri (osat, niiden suhteet ja kehittämisperiaatteet) erittäin keskeinen – muutosherkkyys, toimialavastaavuus, uudelleenkäyttö • SOA yhteistoiminnallisuuden kannalta – yhdistelmä: EAI, BPM ja komponenttipohjaisuus – järjestelmäkokonaisuuden hahmottaminen palveluina – rajapinta- ja sopimuskeskeisyys • SOA-kehityksen paikallisten tavoitteiden määrittely – missä määrin eri yhteentoimivuustavoitteita korostetaan – mitkä integrointitasoista vakioidaan (ja millä ratkaisuilla), mitkä sovitetaan tapauskohtaisesti - vain osa asioista rajapinnoissa (lisäksi infrastruktuuri, policy-määrittelyt, käyttöliittymät jne. ) Järjestelmien integroinnista SOA: an 12

". . . mutta kuinka missäkin tilanteessa saa kaikki nuo tasot ratkaistua? " Eri tyyppisiin integrointivaatimuksiin vastaaminen

Integrointimäärittelyn eteneminen [Mykkänen, Porrasmaa, Rannanheimo, Korpela: A process for specifying integration for multi-tier applications in healthcare. Int J Med Inf 2003: 70(2 -3): 173 -182. ] Järjestelmien integroinnista SOA: an 14

Integrointimallit – vaatimusten ja perusratkaisujen ensisijainen luonne • Palvelupohjainen • Tietopohjainen – tiedonsiirto tai kopiointi – tietokannat, viestit, dokumentit, deklaratiivinen – yksinkertaisuus, runsaasti käytetty – ”business documents” • Prosessipohjainen – määriteltyjen ja keskitetysti ylläpidettyjen prosessien kerros – prosessin koordinaattori (orkestraatio), prosessien hajauttaminen (koreografia) – työnkulkujen ymmärtämisestä määrittelyyn ja ohjaukseen – jaetut toiminnot ja operaatiot, yhteiset palvelut (common services) – rpc-pohjainen middleware, Web services, imperatiivinen – uudelleenkäyttö, vähemmän päällekkäistä tietoa, toiminnallisuutta, ylläpitoa ja toteutustyötä • Käyttäjälähtöinen – yhdenmukainen näkymä moniin järjestelmiin – portaalit, sovellusten synkronointi – käytettävyys, personointi, monikanavaisuus jne. [David Linthicum] Järjestelmien integroinnista SOA: an 15

Esimerkkejä integrointirajapinnoista Järjestelmien integroinnista SOA: an 16

. . . esimerkkejä (jatkuu) Järjestelmien integroinnista SOA: an 17

SOA what: eri tyyppiset integrointitarpeet ja -ratkaisut • SOA: ssa korostetaan (usein) "suuria" rajapintoja ja dokumenttipohjaisuutta ≈ public enterprise service (kumppanien välillä)? – "business activity + entity", sekä yleistetyllä että tarkalla tasolla • lisäksi otettava kantaa mm. – käyttäjätarpeet (vuorovaikutteisuus vs. "eräkäyttöinen" webkäyttöliittymä, portaalit, monikanavaisuus) – prosessikerros: linkitykset vanhoihin järjestelmiin ongelmallisia, prosessipalvelut, prosessimoottori vai koreografia – voidaan määritellä SOA-palveluina tai muuten arkkitehtuurissa • yhdenlaisilla palveluilla ei ratkaista kaikkea – arkkitehtuurin kerroksellisuus – palvelujen luokittelut (esim. ): • integrointitapa • yleiskäyttöisyys: erityisesti YDINpalvelujen tunnistus ja uudelleenkäyttö – operaatioiden karkeajakoisuudessa vaatimuksista riippuvia eroja Järjestelmien integroinnista SOA: an 18

Esimerkki: nykytilanteeseen pohjautuva integrointiarkkitehtuuri ja eri tyyppisten integraatioiden tarve 1. keskitetyt, jaetut palvelut (ydinpalvelut) 2. lisäpalvelut, kontekstinhallinta jne. 3. löysästi kytketyt, yksiköiden ja organisaatioiden väliset palvelut [Mykkänen, Korpela, Ripatti, Rannanheimo, Sorri. Local, Regional and National Interoperability in Hospital-Level Systems Architecture. Meth Inf Med, 2007, in press] Järjestelmien integroinnista SOA: an 19

Palvelualustan vaikutukset suunnittelupäätöksiin • vaikuttaa – protokollasopimukset • rajapintojen syntaksi, kommunikaatioprotokollat, vaatimukset sovellusten teknisille adaptereille, joskus myös eri viestintämuotojen mäppäys mahdollista – reititys oikealle palvelulle vs. palvelurekisteri • loogisten osoitteiden asettaminen viestiin vs. palvelun käyttäjän vastuu paikallistaa vastaanottaja – ympäristön hallittavuus • keskitetty yhteys-, valvonta- (ja virhetilanne-) piste vai hajautetut integrointipalvelut – lisää joustavuutta ja erilaisia soveltamismahdollisuuksia, mutta myös uuden kerroksen järjestelmään ja eri soveltamistapoja • ei vaikuta – semanttiset ja toiminnalliset perusratkaisut (tietoelementtien ja kokonaisuuksien merkitykset, pl. yksinkertaiset yhdistelyt ja jaot, toiminnallisten vaatimusten perusluonne (integrointitapa)) Järjestelmien integroinnista SOA: an 20

". . . mutta eikö jotain voisi saada valmiina, mitäs muut tekevät? " SOA ja standardointi

Standardit ja standardointi • standardi: tunnustetun osapuolen hyväksymä dokumentti, jossa on määritelty yleistä ja toistuvaa käyttöä varten sääntöjä, ohjeita tai piirteitä tuotteille, prosesseille tai palveluille • tavoitteet ja motivaatiot: – – – yhdenmukaistaminen (laatu, tehokkuus) yhteensopivuus (palvelut, sovellukset, tekniikat) objektiivisuus (mittaus, neutraalius, monenvälisyys) oikeus (sääntely, tasapuolisuus) johtoaseman luominen (kilpailuedut) Järjestelmien integroinnista SOA: an 22

Standardien osa-alueita (terveydenhuollon tietojärjestelmät) Järjestelmien integroinnista SOA: an 23

1. HL 7 versio 2, nykytila 2, 67 Tavoitetaso 3, 60 2. HL 7 versio 3, nykytila 0, 38 Tavoitetaso 2, 80 3. CDA (Clinical Document Architecture), nykytila 1, 43 Tavoitetaso 2, 75 4. IHE (Integrating Healthcare Enterprice), nykytila 0, 40 Tavoitetaso 1, 50 5. DICOM, nykytila 1, 29 Tavoitetaso 2, 00 6. CCOW, nykytila 0, 14 Tavoitetaso 1, 50 7. Arden syntax, nykytila 0, 00 Tavoitetaso 0, 33 8. OMG Healthcare-standardit, nykytila 0, 43 Tavoitetaso 0, 33 9. HISA, nykytila 0, 00 Tavoitetaso 0, 33 10. Muut CEN TC 251 standardit, nykytila 0, 43 Tavoitetaso 1, 13 Järjestelmien integroinnista SOA: an 24

Esimerkki toimialakohtaisesta SOAstandardoinnista: Healthcare Services Specification Project (HSSP) • projekti terveydenhuoltospesifien palvelurajapintojen ja SOAlähestymistapojen (teollisuus)standardointiin – taustalla suurten palvelutarjoajien (USA) ja eri maiden SOA-hankkeet • 2 järjestöä – HL 7 (Health Level Seven), SOA SIG: toiminnalliset mallit, sisältö – OMG (Object Management Group), Healthcare DTF: tekniset mallit, toteutukset • palvelumäärityksiä mm. – – RLUS (Record Locator and Update Service) EIS (Entity Identification Service) DSS (Decision Support Services) CTS II (Common Terminology Services) • "pakko ratkaista": yhteisen lähestymistavan ja kehitysmenetelmän tarkentaminen, suhde moniin viesti- ja sisältöstandardeihin, ajan mittaan muodostuneiden "viestikerrosten" dekompositio • http: //hssp. wikispaces. com/ Järjestelmien integroinnista SOA: an 25

SOA what - standardointi • näennäisesti vastakkaisia tavoitteita: joustavuus (SOA) vs. yhdenmukaisuus (standardit) – SOA-joustavuuden perustana kuitenkin modulaarisuus, avoimuus, sopimuksellisuus, joita kaikkia standardit tukevat – vaarana liika yleistäminen, "maximize reuse minimize use" – toimialastandardeilla (epäyhteensopivia) oletuksia arkkitehtuurista ja integrointimalleista - sovitusta tarvitaan • tekninen ja sisällöllinen (toiminnot, tiedot, semantiikka) taso – web services, WS-* tekniset edut selviä, mutta runsaasti soveltamistapoja – näkyvissä: siirtymä teknisistä standardeista sisällöllisiin: toimialakohtaiset viite- ja tietomallit, prosessimäärittelyt – tulossa: profiiliajattelu = toisiaan täydentävien standardien valinta + rajoitteita yleisten standardien soveltamiseen • eb. XML, Rosetta. Net, WS-I, IHE integration profiles, HL 7 + CEN TC 251 semantic profiles, HL 7 functional profiles Järjestelmien integroinnista SOA: an 26

". . . mutta miten voin perustella SOA-lähestymistavan? " Palveluarkkitehtuurin hyödyt ja niiden arviointi

Ratkaisujen ja hyötyjen arviointi: tasot evaluointi (‘tekee oikean asian oikein’, arviointi käyttökontekstissa, suhteessa käytön tavoitteisiin) validointi (‘tekee asian oikein’, ‘toimii käytännön tilanteessa’) Kaikille uusille tekniikoille ja tuotteille verifiointi (‘määritysten mukaisesti’) [Saranummi N. Healthcare Technology Assessment and Evaluation. VTT Information Technology, 2003. ] Järjestelmien integroinnista SOA: an 28

Tietojärjestelmien arviointitapoja Lopputulos Summatiivinen arviointi Kehittäminen Prosessi arviointi Suunnittelu Formatiivinen arviointi Normatii vinen arviointi Valinta / Päätöksenteko Tulosten ja vaikutusten arviointi Arvioitavuuden arviointi Vaihtoehtojen arviointi Ennen-jälkeen arviointi Riskien analysointi Summatiivinen arviointi Normatiivinen arviointi Ohjaaminen Mittaaminen Järjestelmien integroinnista SOA: an 29

SOA ja web services - tavoitellut hyödyt (joita analysoitu Ser. API: ssa, ei normalisoitu) • käyttäjäorganisaation hyödyt – toiminnallinen joustavuus, sovellusten uudelleenkäyttö, sovellusten parantunut liitettävyys, jo tehtyjen investointien hyödyntäminen, sovellushankinta- ja integraatiokustannusten aleneminen, tietojärjestelmäympäristön vähittäinen kehitys, prosessien määrittely ja tukeminen, järjestelmäympäristön tehostunut hallinta ja ylläpito, parantunut käytettävyys, tietotekniikan ja toiminnan lähentäminen • sovelluskehityshyödyt – uusien palvelujen ja sovellusten nopea toteuttaminen, integroinnin tehostuminen kumppanijärjestelmiin, palveluiden ja komponenttien uudelleenkäyttö, inkrementaalinen kehittäminen, kehitysympäristöjen valinnanvara, teknologian keveys ja opittavuus • tekniset hyödyt – tekninen joustavuus, infrastruktuurin uudelleenkäyttö, välineautomaatio, eri tekniikoilla tehtyjen sovellusten ja palvelujen liittäminen, sovelluspalveluiden ja hyödyntäjien löysä kytkentä, globaalien teknisten standardien käyttö, järjestelmien hajautus Järjestelmien integroinnista SOA: an 30

Mittarit ja suureet: tyypit ja aihealueet • tyypit: lukumäärämittarit, työmäärä- ja ajalliset mittarit, laadulliset mittarit, taloudelliset mittarit • osa-alueet: käyttäjä-ja asiakastyytyväisyys, käytettävyys ja saatavuus, toimintaprosessit, tiedot, kehitys- ja integraatioprosessi (toimittaja + asiakas), tekniset mittarit • yht. 126 eri kokoista suuretta ja mittaria, esim. – – – muutospyyntöjen määrä (ITIL) palvelun saatavuus (availability) % käyttäjäkokemukset (kysely) työnkuvan muutoksista kassavirta-analyysi (sis. nykyarvo, diskonttokorko jne. ) Mean Time Between Failures (MTBF) tietojen päällekkäiseen syöttöön käytetty aika Järjestelmien integroinnista SOA: an 31

Mittausesimerkki: järjestelmäympäristön tehostunut hallinta ja ylläpito • toisaalta mitataan organisaation "SOA-tasoa", toisaalta ylläpitoja hallintatyön "tehoa" • tunnistettu asiaan liittyvät 46 (10+13+11+12) mittaria • valittu mitattavissa olevia, poistettu päällekkäisiä ja välillisiä mittareita, tavoitetasot määriteltävä mittareiden kautta • valitut 12 ydinmittaria (suluissa tavoitesuunta) – lukumäärä: päällekkäisten tietojen määrä eri järjestelmissä ( ), sovelluspalvelujen lukumäärä ( ), virhetilanteiden lukumäärä ( ) – työmäärä ja ajalliset: MTTR ( ), sovelluspalvelujen saatavuus ( ), palvelujen vasteajat ( ), prosessimuutosten osuus, jotka voidaan tehdä ilman palvelujen muokkaamista (% ) – laadulliset: ylläpidon kokemat työnkuvan muutokset, tiedon eheys -mm. EUCS ( ), prosessien seurantatietojen saatavuus ( ) – taloudelliset: ylläpitokustannukset ( ), IUM - Impacted User Minutes ( ), hankinta- ja integraatiokustannukset (keskipitkällä aikavälillä ) Järjestelmien integroinnista SOA: an 32

". . . entäs sitten? " Yhteenveto

Organisaation SOA-paletti • strategiset tavoitteet: priorisointi, omistajuus, ydinprosessit ja -palvelut • viitearkkitehtuuri (kokonaisuuden jäsentämiseen) – osat (esim. SOMA): käyttöliittymät, prosessit, sovelluspalvelut, komponentit, järjestelmät, integrointiarkkitehtuuri, hallinta • paikalliset valinnat – pelisäännöt kuhunkin arkkitehtuurin osaan: tekniset käytännöt, hankintastrategiat, metadata, keskeiset standardit – uudelleenkäytettävä infrastruktuuri (tekniset alustavalinnat, ESB? ) • kehitys / hankinta / integraatioprosessi – siirtymä tietokantapohjaisesta ajattelusta tehtäväpohjaiseen – toimialan asiantuntemuksen valtaistaminen kehitykseen – top-down (prosessikuvaukset) ja bottom-up ("valmiit" komponentit) yhdistäminen – strategiset kumppanuudet: ydinjärjestelmä + integraattori • lähtö- ja tavoitetasojen määrittely (kypsyysmallit) Järjestelmien integroinnista SOA: an 34

Viitearkkitehtuuri: esimerkki [Arsanjani A. Service-oriented modeling and architecture. ] Järjestelmien integroinnista SOA: an 35

Kriittiset valinnat maksimoitu joustavuus plug and play-tarkkuus matala toteutuskynnys vähäinen invasiivisuus korkean tason yhdenmukaisuus standardienmukaiset hankinnat paikallinen sovittaminen = painotuksia monenvälisissä terveydenhuollon IT-hankkeissa Suomessa = esimerkki suuren USA: laisen terveyspalvelujen tarjoajan IT-strategiasta Järjestelmien integroinnista SOA: an 36

Yhteenveto: palveluarkkitehtuurin merkitys • SOA integraation syventäjänä: IT-integraatiosta tietojärjestelmien ja toiminnan yhdessä kehittämiseen – tarkempia ratkaisuja - kehitys lähemmäs käyttöä ja prosesseja – standardointi siirtymässä tekniseltä tasolta toimialakohtaisiin ratkaisuihin – web services ja standardit ratkaisevat vain jotkin integrointitasot - paljon jää edelleen paikallisesti tarkennettavaksi – tekniikat jo käytössä ja tulossa yhä enemmän varusohjelmistoihin – erilaisten integrointiratkaisujen tarve: ei vain yhdenlaisia palveluja • palveluarkkitehtuuri luo pohjaa mukautuville järjestelmille – ulkoistaminen, kumppanuudet, lainsäädännön muutokset, palvelujärjestelmän ja organisaatioiden muutokset – uudet tekniikat esim. Web 2. 0, mobiilikäyttö, prosessimoottorit – alkuvaiheessa hyödyt uudelleenkäytöstä, sitten yhdenmukaisuudesta, myöhemmin mukautuvuudesta • . . . mutta yhteentoimivuus on vain osa ratkaisua. . . – liiketoiminta-ajurit, riskit, elinkaari, hallinta, hallinta Järjestelmien integroinnista SOA: an 37

SOA-siirtymän päävaiheiden hyötymalli [Sprott D. Best Practice Report - The Business Case for SOA. CBDI Journal, June 2006. ] Järjestelmien integroinnista SOA: an 38

www. uku. fi/tike/his/serapi/ Kiitos Tämä työ on osa Ser. APIhanketta, johon osallistuvat Kuopion yliopisto, TEKES, Medici Data Oy, Datawell Oy, Fujitsu Services Oy, Pohjois. Savon sairaanhoitopiiri, WM-data Oy, Commit; Oy, Intersystems B. V. Finland, Mediconsult Oy, Microsoft Oy, Oracle Finland Oy, Satakunnan sairaanhoitopiiri, Bea Systems Oy, Helsingin ja Uudenmaan sairaanhoitopiiri, Kuopion kaupunki, Kustannus Oy Duodecim, Mawell Oy Juha. Mykkanen@uku. fi Järjestelmien integroinnista SOA: an 39

Hyvinvointi-IT: n tutkimus ja kehitys: palvelut prosessit ja ohjelmistot Seminaari 12. 6. 2007 Helsingissä Ser. API - Zip. IT - Avointa - Export HIS - e. HP - Äippä - Indehela Ilmoittautumiset ja lisätietoja: www. uku. fi/hyvinvointi-it Terveydenhuollon prosessit ja ohjelmistotuotanto 2007 -hankeryväs on hyvinvointitietotekniikan ja tiedonhallinnan seitsemän tutkimushankkeen muodostama verkosto. Hankeryppään seminaarissa esitellään hankkeissa tehdyn tutkimuksen tuloksia. Mukana on myös puheenvuoroja terveydenhuollon tietotekniikan toimittaja-, asiakas- ja rahoittajaosapuolilta. Seminaari on maksuton ja on tarkoitettu erityisesti terveydenhuollon organisaatioiden päättäjille, asiantuntijoille ja ohjelmistotoimittajien edustajille. 40

Palveluarkkitehtuuri (Serviceoriented architecture, SOA) • lähestymistapa, jossa tietojärjestelmät ja prosessit koostetaan sovelluspalveluista – ei ole arkkitehtuuri, mutta arkkitehtuuri (osat, niiden suhteet ja kehittämisperiaatteet) erittäin keskeinen – yhdistää sovellusintegraation (EAI), prosessien hallinnan (BPM) ja komponenttipohjaisuuden perusajatuksia • keskeiset piirteet – muutosherkkyys: pienemmistä palveluista koostetut ratkaisut helpommin muutettavissa ja mukautettavissa – toimialavastaavuus: ratkaisut toimialan asiantuntijoiden määriteltävissä (abstraktiotaso) – uudelleenkäyttö: vanhat sovellukset ja kerran toteutetut palvelut uusien ratkaisujen pohjana; vähittäinen kehittäminen – rajapinta- ja sopimuskeskeisyys Järjestelmien integroinnista SOA: an 41