Työpaja 3 SerAPI-työpajaseminaari 6.2.2006, Kuopio Juha Mykkänen, Heli Luostarinen,

1. Prosessit ja palvelut Työpaja 3 SerAPI-työpajaseminaari 6.2.2006, Kuopio Juha Mykkänen, Heli Luostarinen, Pasi Riikonen, Assi Pöyhölä, Esa Paakkanen versio julkiseen jakeluun

2. Työpajan runko • aamupäivä (prosessit, sisällöt, käsitteet, tiedot, toiminta) • Prosessit ja palvelut-kohde: tavoitteet, tilanne jne. • Työpajan ja osallistujien tavoitteet • ProPa-tuotoksista lyhyesti • Prosessikuvausesimerkkejä eri lähteistä: • äitiyshuolto (lyhyesti) / SerAPI, VSshp ja ydintietomäärittelyt • endoskopia, leikkaussali / Satshp • gastroskopia / SerAPI/PlugIT • eri mallien vertailu suhteessa tavoitteisiin, keskustelu mm. työtoiminnan kuvaus, toimintojen linkitys ja kuvaaminen • iltapäivä (arkkitehtuuri, palvelualusta, integraatio) • palvelualustojen käyttö • prosessimoottorin käyttömahdollisuudet • palvelujen luokittelu ja arkkitehtuuri • tarkempaa esimerkin läpikäyntiä / Satshp • jatkotyön tarkennukset ja tarpeet

3. ProPa-tavoitteet • Mitä tehdään: • toimintaprosessien ja sovelluspalvelujen tunnistamista, nimeämistä, määrittelyä ja kuvaamista • Tavoitteet: ratkaisuja ja esimerkkejä: • prosessien ja toiminnan ymmärtämiseen • palvelujen tunnistamiseen ja erottamiseen prosessimallinnuksesta • SerAPI-määrittelykohteet keskittyneet rajapintojen bottom-up määrittelyyn, tässä prosessilähtöinen palvelumäärittely (top-down)

4. Osapuolten tavoitteita • esimerkkejä palvelupohjaisista ratkaisuista • esimerkkejä prosessien mallinnuksesta • osastojärjestelmien liittämisen toistettava malli • palvelupohjaisen arkkitehtuurin "blueprint" • prosessimoottorin kokeilu • palvelualustan käytön ja käyttökohteiden tarkennus • Business Activity Monitoring -tiedon kerääminen palvelualustan kautta • yleiskuva terveydenhuollon / sairaalan prosesseista • mihin keskitymme tänään?

5. ProPa-tuotokset • prosessien ja sovelluspalvelujen kuvauksia tilanteessa, joka liittyy konkreettiseen terveydenhuollon prosessiin ja palvelu/järjestelmähankintaan • ratkaisuja ja esimerkkejä - prosessien mallintamisesta, välineistä ja tekniikoista • tietoa prosessimallinnuksesta ja palveluarkkitehtuurin suunnittelusta terveydenhuollossa • Prosessikartta • Prosessiesimerkit (endoskopia ja äitiyshuolto) • Sovelluspalvelujen tunnistaminen + toiminnalliset määrittelyt • (Sairaalan) SOA-arkkitehtuuri • (siirtymä- ja migraatiovaihtoehdot, ohjeet jne.)

6. Tilanne • 09/06 SerAPIn Prosessit ja palvelut-työpaja • -> soveltamiskohteen käynnistys + tavoitteiden 1. tarkennus -> ProPa-kohdekuvaus • 11/06 esimerkkiprosessien valinta • tuotettu prosessikartan ja -esimerkkien luonnoksia • koottu materiaalia (palvelupohjaisen määrittelyn menetelmät ja ratkaisut, esimerkkiprosessit, palveluarkkitehtuurin mallit) • 02/07 tavoitteiden 2. tarkennus, ProPa-työpaja • yhteyksiä (osapuolten lisäksi) • ZipIT-hanke: toimintalähtöinen vaatimusmäärittelymenetelmä, työtoiminnan kuvaaminen • Healthcare Services Specification Project (SOA4HL7) -työ etenkin SOA-lähestymistavassa • SerAPI:n SOA- ja web services-soveltamisopas • kansallisen Ajanvarauksen esiselvityshanke

7. Työpajan tavoitteet • tarkentaa tavoitteita ja toimenpiteitä osallistujien kannalta: • nimettyihin soveltamistarpeisiin • yleisesti prosessimallinnukseen ja palvelujen määrittelyyn prosesseista • arkkitehtuurimäärittelyyn • prosessimoottorin ja alustan käyttöön • yleisistä kysymyksistä kohti "kuinka sovellamme käytännössä" -suunnittelua • jatkoa 09/06 työpajan asioille

8. Terveydenhuollon yleistetyt prosessit

9. Prosessikartta - yleinen taso (esh organisaatiossa)

10. Prosessikartta - pohja tarkennuksille • tarkempia esimerkkejä mm. gastroskopiaan ja äitiyshuoltoon myöhemmin aamupäivällä

11. Prosessimallinnuksen esimerkit • äitiyshuolto (laaja) ja endoskopia (rajattu) valittu osapuolten aloitteesta tarkemmiksi esimerkeiksi • molemmissa myös valmiin materiaalin hyvä saatavuus vaikuttanut valintaan • lisäksi osapuolten kuvauksia (esim. leikkaussali) • äitiyshuolto aamupäivällä lyhyesti esimerkkinä (kaikki tarvittavat osapuolet ei paikalla) • endoskopiasta tarkempaa esimerkkiä • aamupäivällä prosessimallien ja -tuotosten vertailua (Satshp endoskopian ja leikkaussalin mallinnus ja -integraatio + SerAPI / PlugIT-gastroskopia prosessikartta ja -kuvaukset) • yleistettävyys ja käyttökelpoisuus ratkaisujen + arkkitehtuurin + alustan suunnittelussa • iltapäivällä samoja esimerkkejä integrointi-, alusta- ja arkkitehtuurinäkökulmista?

12. Prosessikuvausten tuottaminen 1 • Kuvataan prosessin tavoitteet • Nimetään prosessin omistaja (jos mahdollista) • Määritellään, mistä prosessi alkaa, mihin se loppuu ja mitä prosessi "tuottaa" • Tunnistetaan alustavasti prosessin päävaiheet (toiminnot) ja niiden järjestys, hyödyntäen esim. yleisiä hoito- ja tutkimus/toimenpideprosesseja • Tunnistetaan prosessin osallistujat • Kuvataan vaihe vaiheelta prosessin eri vaiheiden yhteydet muihin prosesseihin ja toimintoihin • Tuotetaan prosessikuva (esim. BPMN-notaatiolla), kuvassa esitetään keskeiset toimijat/yksiköt, prosessin vaiheet ja prosessin eteneminen eri vaiheiden välillä

13. Prosessikuvausten tuottaminen 2 • Tarkennetaan, mitä tietoa prosessin eri vaiheissa liikkuu. • Tarkennetaan, onko jokin prosessin osa (aliprosessi) kuvattava tarkemmin omana prosessinaan. Aliprosesseille kuvataan edeltävät askeleet siten kuin ne soveltuvat. • Kuvataan vaihe vaiheelta prosessin eri vaiheissa tapahtuva tietotekniikan käyttö ja tapahtumat, jotka ovat rajapinta käyttäjän/prosessin ja tietotekniikan välillä. • Tunnistetaan / nimetään yleiset tietojärjestelmä- ja sovelluspalvelut, jotka liittyvät vaiheen 10 tapahtumiin. • Tunnistetaan tietojärjestelmät ja sovellukset, joista sovelluspalveluja voidaan tarjota • Tunnistetaan valmiit palvelumääritykset tai rajapinnat, joita voidaan hyödyntää tai soveltaa • Siirrytään tarkempaan sovelluspalvelujen määrittelyyn tai soveltamiseen

14. Prosessiesimerkkien läpikäyntiä • äitiyshuolto • SerAPI: toimintatarina äitiyshuollon palvelukokonaisuudesta (taustamateriaalina), synnytys-hoitokokonaisuuden prosessikartta • VSshp: palvelukokonaisuus- ja palvelutapahtuma-esimerkit • endoskopia ja leikkaussalijärjestelmät • Satshp: endoskopian ja leikkaussalin prosessit • SerAPI: gastroskopian prosessikartta, toimintatarina, prosessikuvaukset • pohjana jatkokeskustelulle, palvelujen määrittelylle, yleistämiselle, parhaiden käytäntöjen + tarkkuustason valitsemiselle jne.

15. Äitiyshuollon palveluketjun tärkeimmät osat [Äitiyshuollon prosessi ja tietotarpeet: Saumattoman palveluketjun tietoteknisen tuen malliratkaisu - hankesuunnitelma, Silvennoinen, Korpela 2004]

16. Äitiyshuollon prosessikartta (esh)

17. Synnytys-hoitokokonaisuuden prosessikartta

18. Esimerkki äitiyshuollon palvelukokonaisuudesta [Pirkko Kortekangas, 2006]

19. Esimerkki hoitokokonaisuuden tapahtumista/toiminnoista ja niiden tehtävistä [Pirkko Kortekangas, 2006]

20. Äitiyshuollon rakenteiset tiedot • äitiyshuollon palveluketjun keskeiset rakenteiset tiedot • kuvaa myös äitiyshuollon tyypillisen palveluketjun • dokumentti sisältää prosessikuvauksia (eri lähteistä + päivitetty) • esim. synnytysvastaanotto ja synnytyksen hoito -> • [Äitiyshuollon sähköisen potilaskertomuksen rakenteiset tiedot, luonnos v1.1, 25.10.2006]

21. Prosessikuvausten esimerkkejä • Satakunnan shp: • endoskopian prosessit • leikkaussaliprosessit • ks. Satshp esitys • endoskopiaosion vertailu: gastroskopian prosessikuvaus -esimerkki / SerAPI • gastroskopian prosessikartta • gastroskopian prosessikaavioiden luonnokset • gastroskopian hoitoprosessin kuvaus / PlugIT

22. Gastroskopia-esimerkin kokemuksia ja pohdintaa • työpajan pohjamateriaalina hoitoprosessin kuvaus • lähdemateriaalin prosessikuvauksissa ei ole erittelyä, mitä loppujen lopuksi hoidetaan missäkin tarkalleen • olisi mahdollista jaotella organisaatiota toiminnallisesti tarkemmin esim. gastroenterologiassa, mitä missäkin (poliklinikka - mm. esitutkimus, vuodeosasto ja toimenpideyksikkö) - voi poiketa paikallisesti • prosessikartan "organisaatioyksiköt" voivat käytännössä sisältää useita toimipisteitä esim. sisätautien poliklinikka - tutkimusosasto • esi- ja jälkitoimenpiteet voivat poiketa, esim. tarvitseeko potilaan aina käydä poliklinikalla ennen ajanvarausta toimenpiteeseen • lääkityksen tilaus on tehtävä "jossain vaiheessa ennen tutkimusta", mutta ei välttämättä esim. heti ajanvaraukseen liittyen • tarvitaanko esim. skopiatoimenpiteen tarkempaa kuvausta? • hallinnolliset järjestelyt (esim. kuvataanko aina ilmoittautumisen tarkastus omana vaiheenaan ennen toimenpidettä) • jatkotarkennuksia mm. tietokokonaisuuksien erittely, tapahtumat, palvelujen, järjestelmien ja rajapintojen tunnistaminen

23. Keskusteluaiheita • nykytila vs. tavoitetila: • nykytilan ymmärtäminen välttämätöntä - mutta kuinka tarkalla tasolla? • miten syvälle on uppouduttava työtoiminnan kuvaamiseen? • onko SOA-lähestymistavassa itse asiassa kyseessä "hiukan parannetun nykytilan" mallinnus + toteuttaminen + jatkossa pienillä parannuksilla kehittäminen? • yleistäminen • välttämätöntä, jotta tietotekninen ratkaisu saadaan aikaan + etenkin jos pyritään sovelluspalvelujen uudelleenkäyttöön • hyvät käytännöt • kuvataanko prosessin käynnistävät tapahtumat osana prosessia? • prosessien ohjaus -> guideline, malli josta pitää voida poiketa? • prosessikartan toiminnallinen jaottelu esim. yksiköiden suhteen - pitäisikö "missä" erottaa "mitä"-kysymyksestä?

24. Keskustelu: työtoiminnan kuvauksen suhde prosessikuvauksiin • työtoiminta = esim. organisaatioyksikön, ammattiryhmän tai henkilön tekemät toiminnot tai tehtävät • poikkeaa prosessikuvauksesta: prosessi kulkee monien työtoimintojen läpi, työtoiminnassa toistuvat pienet osat useista eri prosesseista ja saman prosessin instansseista • työtoiminnan kuvaukseen eri kuvaustavat kuin prosessin (työnkulku, tiedonkulku, henkilöiden, materiaalin kulku) kuvaukseen • työtoiminnan kautta toisistaan täysin irralliset eri prosessit liittyvät toisiinsa ja vaikuttavat toisiinsa • työtoimintaa ei automaattisesti huomioida työnkulkujen ja tietovirtojen optimoinnissa ja automatisoinnissa

25. Keskustelu: tapahtuma/toiminto-käsitteen suhde prosessien kuvauksiin ja toteutuksiin • "palvelutapahtuma"-käsite on tietyn palvelun järjestäminen tai toteuttaminen - kansallisia määritelmiä liittyen mm. lainsäädäntöön, hoitojaksoihin ja ydintietoihin • prosessimallinnuksen kannalta tarvitaan toiminto (/ tapahtuma), joka kuvaa tietyn palvelun toteuttamiseksi tarvittavat tehtävät • terminä "toiminto" [JHS 152] tai "palvelutoiminto"? • ei "tapahtuma" (jolla prosessimallinnuksessa yleensä käännöksenä "event")? • jos yksi toiminto kuvataan tehtävinä, päästään riittävälle tarkkuustasolle palvelujen tunnistamista (/prosessin koordinointia?) varten? • toinen vaihtoehto keskittyä vain yksiköiden / toimintojen / ihmisen ja sovelluksen rajapintoihin • myös eri asiakirjat on saatava liittymään toisiinsa • palvelutoiminnon sisällä, hoitojakson, palvelukokonaisuuden sisällä...

26. Toiminto [kansallinen ajanvarauspalvelu - käsitemalli (yleinen)]

27. Työpajan runko • aamupäivä (prosessit, sisällöt, käsitteet, tiedot, toiminta) • Prosessit ja palvelut-kohde: tavoitteet, tilanne jne. • Työpajan ja osallistujien tavoitteet • ProPa-tuotoksista lyhyesti • Prosessikuvausesimerkkejä eri lähteistä: • äitiyshuolto (lyhyesti) / SerAPI, VSshp ja ydintietomäärittelyt • endoskopia, leikkaussali / Satshp • gastroskopia / SerAPI/PlugIT • eri mallien vertailu suhteessa tavoitteisiin, keskustelu mm. työtoiminnan kuvaus, toimintojen kuvaaminen • iltapäivä (arkkitehtuuri, palvelualusta, integraatio) • viitearkkitehtuuri • tarkempaa esimerkin läpikäyntiä / Satshp <- tässä kohden? • palvelujen luokittelu • palvelualustojen käyttö • prosessimoottorin käyttömahdollisuudet • jatkotyön tarkennukset ja tarpeet

28. Iltapäivän lähestymistapa • viime kerralla keskityttiin mallinnusnotaatioiden lisäksi palvelupohjaiseen kehitysprosessiin • nyt prosessin sijaan (/ lisäksi) eri arkkitehtuurinäkökulmien pohjalta etenemistä • viitearkkitehtuurin kerrokset / näkökulmat • erityishuomion kohteena tänään: • palvelualustat • prosessimoottori • palvelujen luokittelu • sovelluspalvelut • järjestelmät • järjestelmien komponentit / rajapinnat • prosessikerros • käyttöliittymät • integraatioarkkitehtuuri • hallintamekanismit

29. Kertausta: vaiheet (soddm) vaihtoehtojen tarkastelu prosessien toteuttamiseksi tavoitteet, mittarit, lähtökohdat, suunnitelma web-sovelluspalveluiden ja prosessien tunnistaminen ja määrittely asteittain web-sovelluspalveluiden ja prosessien kehittäminen ja kuvaaminen, teknisten rajapintojen kuvaaminen, palveluja käyttävien osien kehittäminen palvelutason seuranta, mittaus, raportointi, parantaminen kehitettyjen palveluiden ja prosessien toiminnallisen oikeellisuuden ja täydellisyyden sekä yhteentoimivuuden testaaminen web-sovelluspalveluiden käyttö, prosessien määrittelyjen mukainen suorittaminen hallinta- (keskitetty/hajautettu), sertifiointi-, mittaus- ja laskutusmallien määrittely palveluiden ja prosessien käyttöönotto sovelluksissa, käyttäjillä ja kumppaneilla [Michael P. Papazoglou ja Willem-Jan van den Heuvel.International Journal of Web Engineering and Technology (IJWET), 2006.]

30. Viitearkkitehtuuri-käsittelyn runkona

31. Viitearkkitehtuuri: perusteet • viitearkkitehtuuri ohjaa miettimään ja ratkaisemaan tietyn tyyppisiä seikkoja kerrallaan, ei kaikkea yhtä aikaa • myös muiden seikkojen kuin "palvelut" huomiointi • "riittävän vähäinen" määrä kerroksia ja näkökulmia • pohjana useita arkkitehtuurikuvauksia, mukana useissa kuvauksissa näkyvät kerrokset / näkökulmat • esimerkkejä • ei "ainoa oikea" lähestymistapa • lisäksi tarvitaan mm. kehitysprosessin ja hallinnan näkökulmia • esim. CBDI "meta model for service architecture and engineering" -näkökulmat: • business modelling, solution modelling, specification of BSA, service specification detail, planning and provisioning policy, implementation, deployment, runtime • tässä vaiheessa kuitenkin keskitytään vielä lähinnä analyysi- ja suunnitteluvaiheeseen

32. Viitearkkitehtuuri: ehdotus [Arsanjani A. Service-oriented modeling and architecture.]

33. Viitearkkitehtuurin soveltaminen:sovelluspalvelut (services) -palvelujen luokittelu -hiukan määrittelyprosessista -palvelujen tunnistamisesta lisää "alakerrosten" yhteydessä

34. Palvelujen luokittelun perusteet • luokittelun tarkoitus: samantyyppisiä ratkaisuja samantyyppisiin tarpeisiin • kaikki palvelut eivät voi olla samantyyppisiä (ja ratkaisuissa tarvitaan muutakin kuin palveluja) • erilaisia luokittelulähtökohtia • teknisyys ja yleiskäyttöisyys: infrastruktuuri / ydinpalvelut / lisäpalvelut • arkkitehtuurin kerrokset + karkeajakoisuus: järjestelmäpalvelut, business services, process services • palvelun kattamien integrointivaatimusten ensisijainen luonne: tietopalvelut, toiminnalliset palvelut, käyttäjäkeskeiset palvelut, prosessipalvelut • toiminnallinen luokittelu: tekniset palvelut (viestinvälitys), yleispalvelut (ajanvaraus), toimintokohtaiset palvelut (radiologian sovelluspalvelut) • rakenteisuuden ja "epävarmuuden" aste

35. Palvelujen luokittelu - ehdotus • luokittelu tehty lähinnä services-kerrosta varten hyödyntäjänäkökulmasta • luokitellaan tunnistettavat palvelut kahden erillisen näkökulman mukaisesti [SOA4HL7, Herzum&Sims, CBDI, RM-ODP, Linthicum] • palvelun integrointitapa - koska tarvitaan erilaisia palveluita • prosessipalvelu: toteuttaa suoraan prosessia tai osaprosessia • tietopalvelu: liittyy suoraan tietokokonaisuuteen, tietyn tyyppisiin dokumentteihin jne. • toiminnallinen palvelu: keskeistä tarjottava toiminnallisuus (business capability) • tukipalvelu • palvelun yleiskäyttöisyys - koska on määriteltävä uudelleenkäyttöä • yleispalvelut - hyödynnettävissä hyvin monien eri tyyppisten palvelujen, sovellusten ja prosessien toteutuksissa (utility service) • ydinpalvelut - monissa prosesseissa ja yksiköissä / sovelluksissa hyödynnettäviä toiminnallisia tai tietopalveluja (common service) • erikoispalvelut - tiettyihin erikoistilanteisiin vastaavia toimintoja, voi olla osasto/sovellus/tehtäväkohtainen (specialized service)

36. Esimerkkejä (eri kokoisia) • kansallinen arkistopalvelu (tieto- ja ydinpalvelu) • DRG-ryhmittelijä (toiminnallinen- ja erikoispalvelu) • viestinvälityspalvelu (tuki- ja yleispalvelu) • kontekstinhallinta (toiminnallinen- ja yleispalvelu) • kansallinen koodistopalvelu (tieto- ja yleispalvelu) • koodistojen CodeAPI-rajapinnan toteuttava palvelu sairaalassa (toiminnallinen- ja ydinpalvelu) • alueellinen viitetietopalvelu (tieto- ja yleispalvelu) • ajanvarauspalvelu (toiminnallinen- ja ydinpalvelu) • diabetes-hoitoketjua ohjaava käypä hoito-palvelu (prosessi- ja erikoispalvelu) • sosiaalihuollon yleinen asiointiprosessin ohjauspalvelu (prosessi- ja yleispalvelu) • keskitetty käyttöoikeuksien hallintapalvelu (toiminnallinen- ja ydinpalvelu)

37. Palvelujen suunnittelu: vaiheet (1/2) Lähtökohtana vaatimukset ja olemassa olevat sovellukset + ratkaisut • tarvittavan toiminnallisuuden kartoitus (vaatimukset, prosessit) • palvelun rajaus ja päävaatimusten valinta • sisällöllisten standardien ja valmiiden mallien tutkiminen + valinta • osallistuvien sovellusten vastuiden määrittely • keskittyminen vain palvelun tarjoajaan - uudelleenkäyttö? • rajapintojen tunnistaminen ja toimintojen ryhmittely niihin

38. Palvelujen suunnittelu: vaiheet (2/2) • toimintokohtaisesti operaatioiden "koko" + tarvittava / käytettävissä oleva infrastruktuuri • vuorovaikutuksen määrittely (rajapinta + käyttäjä) • palvelukuvauksen määrittely (rajapinnat, toiminnot, tiedot) • pakollisten ja vapaaehtoisten ominaisuuksien ja sallittujen laajennusten määrittely • vaatimusten tarkentaminen teknisille määrittelyille ja toteutuksille  tuloksena palvelun rajapinnan määrittely ja suuntaviivat teknisille ratkaisuille

39. palvelu- ja viestimäärittelyn toimenpiteet (valkea) ja tuotokset (värillinen) • A generic process for HL7 Messaging Dynamic Model and SOA approach (viestinvälityksen ja palvelulähestymistavan lähentämistä) • [Healthcare Services Specification Project: Services and the HL7 V3 Messaging Dynamic Model, v. 0.98]

40. Viitearkkitehtuurin soveltaminen:integrointiarkkitehtuuri+ hallintamekanismit -erityisesti palvelualusta (ESB)

41. Integrointiarkkitehtuurin rajapintojen ja liitäntöjen tyyppejä • keskitetyt, jaetut palvelut (ydinpalvelut) • lisäpalvelut, kontekstinhallinta jne. • 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, under revision]

42. Palvelualustojen käyttö • palvelualusta (ESB) perusteet [mukaillen Gartner + Bea + Chappell]: • lähettäjien ja vastaanottajien välissä (intermediary) • ohjelmistojen välinen kommunikointi • aina SOAP/http • yleensä myös viestipohjainen middleware (MOM) • eri viestinvälitysmallit: synkroninen, ei-synkroninen, publish/subscribe • tukee Web services-standardeja (XML, WSDL, SOAP, http) • reititys (mm. palveluntarjoajien löytäminen / korvaaminen, ajonaikainen sidonta) • muunnokset (tietomuotojen + viestinvälitysprotokollien välillä) • metatietojen käyttö (osoitteet, rajapinnat, skeemat, policy-määrittelyt) • seuranta (esim. Business Activity Monitoring, tekninen toimivuus, SLA-valvonta), turvallisuusominaisuudet • (usein) prosessimoottorin käyttö • ESB ei ole yhtä kuin hub and spoke-integrointialusta: myös integrointikomponentit hajautettu palveluiksi palveluväylän kautta

43. Palvelualusta: Basic SOA [SOA4HL7]

44. Palvelualusta: Orchestrated (& statically & dynamically intermediated) SOA [SOA4HL7] Static intermed. Dynamic intermed.

45. 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))

46. Filosofinen ero (tai USA-Ruotsi-maaottelu)

47. Palvelualustojen käyttöön liittyviä kysymyksiä • palvelujen (toiminnallisessa) määrittelyssä tehtävät oletukset alustan hoitamista seikoista • esim. "pyynnön vastaanottajan" määrittelyn eri tasot - onko osa palvelun rajapintaa vai alustan / hakemiston hoidettava asia? • kulkeeko "kaikki" palvelualustan kautta, vai tehdäänkö suoria liitäntöjä esim. ydinpalveluihin - esim. kontekstinhallinta ei ole ESB-palvelu? • vaatimusten luonne • esim. vuorovaikutteisuus vs. viestipohjaisuus • infrastruktuuriresurssit vs. sovellushankintaresurssit • policy-määritysten suhde toiminnallisiin määrityksiin • periaatteessa kaikki voi olla joko rajapintaa tai konfiguraatiota • arvio [Bea]: 20 palvelun sovellukset onnistuvat vielä point-to-point-tavalla, laajemmat sovellukset vaativat keskitetyn väylän • mitä erityisesti jää "yhteisesti sovittavaksi" palvelualustoja käytettäessä • sisältö ja perusratkaisut • toiminnalliset palvelumäärittelyt

48. Viitearkkitehtuurin soveltaminen:prosessikerros (business process / choreography) -erityisesti prosessimoottori

49. Viitearkkitehtuurin soveltaminen: business process / choreography • vaihtoehtoja • prosessimoottori - orchestration • keskitetty prosessin ohjaus, oma kerros arkkitehtuurissa, prosessin osana olevien palvelujen ei tarvitse tuntea prosessimäärittelyä • prosessin dokumenttien kunkin osapuolen tuntemat prosessimäärittelyt - choreography • hajautettu prosessin ohjaus, kaikkien osapuolten mukauduttava määrittelyihin • prosessimäärittelyjä voi myös kuljettaa dokumenttien "mukana"? • erikseen rakennetut prosessipalvelut osana arkkitehtuuria - kuten prosessimoottori • käyttöliittymäsovellus (myös vanhat sovellukset) / asianhallintasovellus / portaali prosessin ohjaajana

50. Prosessimoottorin käyttökohteet ja edellytykset • prosessimoottori: keskitetty prosessin kontrolloija • ohjaa ennalta määritellyllä tavalla viestien ja vastausten liikkumista • säilyttää tiedon prosessin tilasta • prosessin seuranta, poikkeamien hallinta ym. • teknistä tietoa prosessien etenemisestä, virhetilanteista jne. • toiminnallista tietoa prosessien kulusta, läpimenoajoista, määristä jne. • prosessin askelten deterministinen määrittely • tunnettava, kuinka prosessi etenee • ottaa usein kantaa sekä tiedonkulun että työnkulun etenemiseen • prosessimäärittelyn hienojakoinen karkeustaso