J - PowerPoint PPT Presentation

About This Presentation
Title:

J

Description:

Title: PowerPoint Presentation Last modified by: jumykkan Created Date: 1/1/1601 12:00:00 AM Document presentation format: On-screen Show Other titles – PowerPoint PPT presentation

Number of Views:102
Avg rating:3.0/5.0
Slides: 42
Provided by: uef7
Category:
Tags:

less

Transcript and Presenter's Notes

Title: J


1
Järjestelmien integroinnista SOAan
  • SOA - Service Oriented Architecture, Helsinki,
    29.3.2007
  • Juha Mykkänen, FT, tutkijatohtori
  • Kuopion yliopisto, HIS-tutkimusyksikkö
  • juha.mykkanen_at_uku.fi

2
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ä gt10 v) - ei liikkeelle "puhtaalta
    pöydältä"
  • esityksessä poimintoja soveltavasta tutkimuksesta
    n. 7 v
  • komponentit -gt sovellusintegraatio -gt
    palvelupohjaisuus
  • väitöskirja "Specification of Reusable
    Integration Solutions for Health Information
    Systems", 01/07
  • esityksen pyrky integraatio SOA-näkökulmasta

3
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

4
Taustaa SerAPI Palveluarkkitehtuuri ja
web-sovelluspalvelut terveydenhuollon
ohjelmistotuotannossa ja integraatiossa
  • Tekesin FinnWell-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
  • HL7 Finland Common Services SIG taustaprojekti
  • Healthcare Services Specification Project (HL7 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"

5
Keskeiset näkökulmat tarkemmin (SOA-viitekehys
monimutkaisen elefantin voi syödä vain pala
kerrallaan)
6
Yhteentoimivuus (interoperability)
7
Organisaatioiden toiminnan ja arkkitehtuurien
kehitys
  1970-luku 1980-luku 1990-luku 2000-luku
Toiminta-malli Hierarkkinen organisaatio, toimintojen nopeus ja laatu Toimintayksiköt, prosessien tunnistaminen ja määrittely Toimitusketjut, alueellinen yhteistoiminta Globaali ja virtuaalinen, mukautuva prosessi-orientoitunut toiminta
Sovellus-arkkiteh-tuuri Heijastaa toiminnan rakennetta, tietokantojen hallinta-järjestelmät, integroidut tietokannat Asiakas-palvelin-arkkitehtuurit, oliopohjaisuus, kolmitaso-arkkitehtuurit, erilliset käyttö-liittymät, sovelluslogiikka ja tiedot, jaettu tietoarkkitehtuuri Monitaso-arkkitehtuurit, hajautetut oliot, komponentti-pohjaiset järjestelmät, viestipohjainen yksiköiden välinen integraatio, työnkulkujen hallinta, standardit Verkkosovellukset, palvelupohjainen integraatio, dynaamiset, joustavat ja komponentti-pohjaiset sovellukset, peer-to-peer -yhteistoiminta
ICT- infra-struktuuri Keskuskoneet, minitietokoneet, terminaalikäyttö Työasemat ja palvelimet, graafinen käyttöliittymä, LAN Sovelluspalvelimet, web, WAN, langattomuus Web, sovellus- ja integrointi-palvelimet, mobiili-käyttöliittymät, grid-tekniikat
8
Tietojärjestelmiin kohdistuvia tarpeita
Pekka Kähkipuro
9
Hankintavaihtoehtojen monipuolistuminen
Osta valmis tuote
Toteuta itse
Teetä uusi järjestelmä
Suunnitteluta ulkopuolisella
Osta ja räätälöi järjestelmä
Osta ja integroi komponentit
Vuokraa ulkopuoliselta (ASP)
Toteuta vanhan järjestelmän sovittimena
Laajenna sovelluskehyksestä
Kirjaudu käyttämään verkon kautta
10
Yhteentoimivuus-käsitteen merkitykset
11
Integrointitasot mitä sovittava sovellusten
yhdessä toimimiseksi
Milloin?
  • järjestelmän elinkaari
  • toiminnallinen ja tietoarkkitehtuuri
  • sovellusarkkitehtuuri
  • tekninen arkkitehtuuri

Mitä?
Missä?
Miten?
  • ratkaistava kaikissa sovellusintegraatio-tilanteis
    sa

Peter Herzum, Oliver Sims
12
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.)

13
Eri tyyppisiin integrointivaatimuksiin vastaaminen
"...mutta kuinka missäkin tilanteessa saa kaikki
nuo tasot ratkaistua?"
14
Integrointimäärittelyn eteneminen
  • Mykkänen, Porrasmaa, Rannanheimo, Korpela A
    process for specifying integration for multi-tier
    applications in healthcare. Int J Med Inf
    200370(2-3)173-182.

15
Integrointimallit vaatimusten ja
perusratkaisujen ensisijainen luonne
  • Palvelupohjainen
  • 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.
  • 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

David Linthicum
16
Esimerkkejä integrointirajapinnoista
17
... esimerkkejä (jatkuu)
18
SOA what eri tyyppiset integrointitarpeet ja
-ratkaisut
  • SOAssa 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" web-kä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

19
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
20
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))

21
SOA ja standardointi
"...mutta eikö jotain voisi saada valmiina, mitäs
muut tekevät?"
22
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)

23
Standardien osa-alueita (terveydenhuollon
tietojärjestelmät)
24
  • 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
  • 1. HL7 versio 2, nykytila 2,67
  • Tavoitetaso 3,60
  • 2. HL7 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

25
Esimerkki toimialakohtaisesta SOA-standardoinnista
Healthcare Services Specification Project (HSSP)
  • projekti terveydenhuoltospesifien
    palvelurajapintojen ja SOA-lähestymistapojen
    (teollisuus)standardointiin
  • taustalla suurten palvelutarjoajien (USA) ja eri
    maiden SOA-hankkeet
  • 2 järjestöä
  • HL7 (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/

26
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
  • ebXML, RosettaNet, WS-I, IHE integration
    profiles, HL7 CEN TC251 semantic profiles, HL7
    functional profiles

27
Palveluarkkitehtuurin hyödyt ja niiden arviointi
"...mutta miten voin perustella
SOA-lähestymistavan?"
28
Ratkaisujen ja hyötyjen arviointi tasot
evaluointi (tekee oikean asian oikein,
arviointi käyttökontekstissa, suhteessa käytön
tavoitteisiin)
Kaikille uusille tekniikoille ja tuotteille
validointi (tekee asian oikein, toimii
käytännön tilanteessa)
verifiointi (määritysten mukaisesti)
Saranummi N. Healthcare Technology Assessment
and Evaluation. VTT Information Technology,
2003.
29
Tietojärjestelmien arviointitapoja
30
SOA ja web services - tavoitellut hyödyt (joita
analysoitu SerAPIssa, 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

31
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

32
Mittausesimerkki järjestelmäympäristön
tehostunut hallinta ja ylläpito
  • toisaalta mitataan organisaation "SOA-tasoa",
    toisaalta ylläpito- ja hallintatyön "tehoa"
  • tunnistettu asiaan liittyvät 46 (10131112)
    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ä ?)

33
Yhteenveto
"...entäs sitten?"
34
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)

35
Viitearkkitehtuuri esimerkki
Arsanjani A. Service-oriented modeling and
architecture.
36
Kriittiset valinnat
  • maksimoitu joustavuus plug and
    play-tarkkuus

matala toteutuskynnys korkean tason
yhdenmukaisuus vähäinen invasiivisuus
standardienmukaiset hankinnat paikallinen
sovittaminen
painotuksia monenvälisissä terveydenhuollon
IT-hankkeissa Suomessa
esimerkki suuren USAlaisen terveyspalvelujen
tarjoajan IT-strategiasta
37
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, hallinta, hallinta

38
SOA-siirtymän päävaiheidenhyötymalli
Sprott D. Best Practice Report - The Business
Case for SOA. CBDI Journal, June 2006.
39
Kiitos
www.uku.fi/tike/his/serapi/
  • Tämä työ on osa SerAPI-hanketta, 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_at_uku.fi
40
Hyvinvointi-ITn tutkimus ja kehitys
Seminaari 12.6.2007 Helsingissä
palvelut prosessit ja ohjelmistot
SerAPI - ZipIT - Avointa - Export HIS - eHP -
Ä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.
41
Palveluarkkitehtuuri (Service-oriented
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
Write a Comment
User Comments (0)
About PowerShow.com