järjestelmien integroinnista soa:an

Järjestelmien integroinnista SOA:an

SOA - Service Oriented Architecture, Helsinki, 29.3.2007Juha Mykkänen, FT, tutkijatohtoriKuopion yliopisto, HIS-tutkimusyksikkö[email protected]

Järjestelmien integroinnista SOA:an 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ä >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


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


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"


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

Yhteentoimivuus (interoperability)

Page 8

Context of HSSP SpecificationsContext of HSSP Specifications

Ab

ilit

y to

In

tero

per

ate

High

Low


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


Tietojärjestelmiin kohdistuvia tarpeita

Kompone nttimarkkinat-m a hdollisuus m yydä ja ha nkkia

va lm iita , te sta ttu ja osia-m a hdollisuus va lita itse lle sop ivin

Laajoje n järje ste lmie nhallittav uus

-suuria to im inna llisuus-kokona isuuksia

-pa ljon yhtä a ika ista kä yttöä-ska a la utuvuus

Uude lle e nkäyte ttäv yys-o le m a ssa ole va n ka pse lo in ti

-pä ä lle kkä isyyksie n vä he ntä m ine n-yhte nä iste n pa lve lu je n

ta rjoa m ine n-oh je lm isto työn tuotta vuus

M uutoksiin v arautumine n janope a sope utumine n-to im inta prose ssie n ja

pa lve luke tju je n m uutoksiin-te kn iika n m uutoksiin

He te roge e niste n ratkaisuje ninte grointi

-e rila isia kä yttö jä rje ste lm iä ,kä yttö li ittym iä , pa lve lim ia

-e ri te kn iiko illa te htyjäsove lluksia

[Pekka Kähkipuro]


Hankintavaihtoehtojen monipuolistuminen

Osta valmis tuote Toteuta itse

Osta ja integroi komponentit

Suunnitteluta ulkopuolisella

Vuokraa ulkopuoliselta (ASP)

Toteuta vanhan järjestelmän sovittimena

Laajenna sovelluskehyksestä

Kirjaudu käyttämään verkon kautta

Teetä uusi järjestelmä

Osta ja räätälöi järjestelmä


Yhteentoimivuus-käsitteen merkitykset

Yhteentoimivuus(interoperability)

Yhteen-sopivuus

Integroitavuus

Koostettavuus

Korvattavuus

Siirrettävyys

sisäisetominaisuudet

jaetutominaisuudet

staattinen suunnittelu

dynaaminen muokkaaminen

Page 8


Ab

ilit

y to

In

tero

per

ate

High

Low


Integrointitasot – mitä sovittava sovellusten yhdessä toimimiseksi

• järjestelmän elinkaari• toiminnallinen ja

tietoarkkitehtuuri

• sovellusarkkitehtuuri• tekninen arkkitehtuuri

Te knise t liittymät

Te knine n infrastruktuuri

Sov e llusinfrastruktuuri

Toiminnallise t liittymät

Se mantiikka

Toiminnalline n v iite malli

Ke hitysprose ssin liittymät

• ratkaistava kaikissa sovellusintegraatio-tilanteissa

[Peter Herzum, Oliver Sims]

Page 8


Ab

ilit

y to

In

tero

per

ate

High

Low


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

Page 8


Ab

ilit

y to

In

tero

per

ate

High

Low

Eri tyyppisiin integrointivaatimuksiin vastaaminen

SerAPI 41

Web services-soveltamistavat arviointi

Se mantiikan tarkkuus

Ke hitysv älin e tuki

Opittav uus

Te knine nlaaje nne ttav uu s

Ke hitykse nsuorav iiv aisuus

Sisällö lline njoustav uus

XM L/http

Ope n CDA /SOAP

WSDL/SOAP

HL7 v 3 + WS-transport

"...mutta kuinka missäkin tilanteessa saa kaikki nuo tasot ratkaistua?"


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.]

1 . K o hde alue e nanalyso int i

2 .So ve llus arkkite htuur intunnis tam ine n

3 . O lem as s ao le vie nso ve l lus te n te kniiko ide n

tunnis tam ine n

4 . To im innall is te nl i i t tym ie n tunnis tam ine n

5 . L ii t tym äte kniiko ide nvalinta

7 . To te utuks e s s akäyte t tävie n tuo tte ide n

valinta

6 . L ii t tym ie n m äär i t te ly

- inte gro intivaat im uks e t-o lem as s ao le vie n so ve l lus te n to im innal l is uus

- s o ve l lus arkkite htuur i- s o ve l lus te n alus ta

- to im innal l is e t inte gro intipis te e t

- s em antt is e t vaatim ukse t

to im ialans tandardit

- te knis e ts tandardit

-uude t m e to dit , työ kalutja te kniikat

- inte gro intipis te e tko hde arkkite htuur is s a

-o lem as s ao le va te knine n inf ras truktuur i

- te kniikkar i ippum attom atl i i t tym ät

-uus i s o ve l lus inf ras truktuur i- inte gro inti te kno lo giat

- te knis e t l i i t tym ät

1. INTEGRAATIO -VAATIM UKSET

2. TEKNIIKKA-RIIPPUMATON

LIITTYMÄMÄÄRITTELY

3. TEKNINENLIITTY M Ä-

M ÄÄRITTELY

SerAPI 41




Opittav uus




XM L/http

Ope n CDA /SOAP

WSDL/SOAP



Integrointimallit – vaatimusten ja perusratkaisujen ensisijainen luonne

• 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

• 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.

[David Linthicum]

SerAPI 41




Opittav uus




XM L/http

Ope n CDA /SOAP

WSDL/SOAP



Esimerkki DRG-luokittelija Sähköinen potilas-kertomusarkisto

Kontekstinhallinta

Vaati-mukset

Tuottaa tietoa mm. diagnoosiin perustuen resurssien käytön arviointia ja vertailua varten

Yleinen rajapinta eri tyyppisten hoito-dokumenttien arkistointiin (esim. potilaskertomuksen lomakkeet, lääkemääräys)

Säilyttää käyttäjä-kohtaista kontekstitietoa useille sovelluksille (sisäänkirjautunut käyttäjä, valittu potilas jne.)

Integrointi-malli

palvelu tieto käyttäjä

Joustavuus staattinen, vakioparametrit

dynaaminen, eri-tyyppisiä dokument-teja, paikallisia erityistarpeita

staattinen rajapinta, laajennettavat subjekti-tiedot

Jaettu vai välitetty ratkaisu

jaettu (common service / yleinen palvelu)

jaettu (loogisesti keskitetty arkisto) ja välitetty (sisältö-muunnokset, viitteillä tapahtuva tiedon haku)

jaettu (yhteinen palvelu / sessiotietovarasto)

Esimerkkejä integrointirajapinnoista SerAPI 41




Opittav uus




XM L/http

Ope n CDA /SOAP

WSDL/SOAP



Esimerkki DRG-luokittelija Sähköinen potilas-kertomusarkisto

Kontekstinhallinta

Terv.huollon standardit

NordDRG-luokittelu-järjestelmä

sähk. potilas-kertomuksen sisältö-määrittelyt, HL7 CDA, HL7 versio 3-viestit

HL7 CCOW mallina

Tekniset standardit

WSDL, SOAP XML, SOAP, (PKI) http

Arkkitehtuuri etäohjelmakutsu, keskitetty palvelu

keskitetty dokumenttivarasto, viitehakemisto

keskitetty palvelu, "liitutaulu"

Viestin-välitys

välitön vastaus ei välitöntä vastausta, taattu toimitus

välitön vastaus, sessionhallinta

Tila tilaton tilaton tilallinen Muuta voi käyttää

vuorovaikutteisesti tai eräajopohjaisesti

hoitodokumentaation monimuotoisuus, suostumus, sähköinen allekirjoitus

matala toteutuskynnys olemassaoleville sovelluksille, vuorovaikutusproto-kollan yksinkertaistaminen

... esimerkkejä (jatkuu)SerAPI 41




Opittav uus




XM L/http

Ope n CDA /SOAP

WSDL/SOAP



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" 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

SerAPI 41




Opittav uus




XM L/http

Ope n CDA /SOAP

WSDL/SOAP



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

Administration and management

Financials

Materialsmanagement

Personnelmanagement

Property andinfrastructuremanagement

Sales, CRM,marketing, PR

Clinical subsystems

Surgery

Neonatal

Cardiology

Pathology

Anaesthesiology+ ICU

Gastroenterology

Clinical core

Patient andprovider id

Decisionsupport

Pharmacy

Terminology

Etc

EHR repository

Administrative core

Patient / providerdemographics

Invoicing

Admisstion,discharge,

transfer

Inpatient andoutpatient

management

Resource /operationsplanning

Materials& meal

ordering

Orders / referrals,prescriptions,consultations

Scheduling,Resouce

Management

Patientgrouping,

DRG

User management, security and access control

Integration, data access

Workflow and process management

Professional front-endsPatient/citizen front-end

Lab

Radiology+ PACS

Medication

Results

Problems

Population /community health

Insurance

Reporting, Data warehousing, Management

Workstations Web Mobile Ubiquitous

Statisticalreporting

Research

Guidelines,protocols

Equipment

Diseasemanagement

1. 2. 3.

1. Common, shared and centralized services2. Context management, added value services3. Loosely-coupled messages, documents, cross-facility invocations

Identification User role Care relationship Consent

[Mykkänen, Korpela, Ripatti, Rannanheimo, Sorri. Local, Regional and National Interoperability in Hospital-Level Systems Architecture. Meth Inf Med, 2007, in press]

SerAPI 41




Opittav uus




XM L/http

Ope n CDA /SOAP

WSDL/SOAP



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

SerAPI 41




Opittav uus




XM L/http

Ope n CDA /SOAP

WSDL/SOAP


SOA ja standardointi

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


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)


Standardien osa-alueita (terveydenhuollon tietojärjestelmät)

medicineand

healthcare

info

rma

tion

mo

de

ls an

d e

lem

en

tste

rmin

olo

gie

s, classifica

tion

s, cod

es

pro

cesse

s, pa

thw

ays

qu

ality o

f care

gu

ide

line

s, kno

wle

dg

e

arch

itectu

re

healthcare IT and IS

da

ta typ

es a

nd

form

ats

ele

ctron

ic clinica

l do

cum

en

tsm

essa

ge

inte

rface

sa

rchivin

g a

nd

lon

g te

rm sto

rag

ese

rvice a

nd

AP

I inte

rface

ssu

pp

ort fo

r pro

cesse

sse

curity a

nd

con

fide

ntia

lity

IT, domain-neutral andcross-domain

ele

ctron

ic he

alth

reco

rds

standardization relevant to eHealth and HIS

da

ta co

mm

un

icatio

ns

ide

ntifica

tion

eG

ove

rnm

en

an

ce a

nd

arch

itectu

ree

lectro

nic d

ocu

me

nts

me

ssag

ing

an

d e

nve

lop

ing

inte

rface

tech

no

log

ies

pro

cess d

escrip

tion

an

d d

efin

ition

secu

rityso

ftwa

re p

rod

uctio

n / d

eve

lop

me

nt


1. HL7 versio 2, nykytila 2,67 Tavoitetaso 3,602. HL7 versio 3, nykytila 0,38 Tavoitetaso 2,803. CDA (Clinical Document Architecture), nykytila 1,43 Tavoitetaso 2,754. IHE (Integrating Healthcare Enterprice), nykytila 0,40 Tavoitetaso 1,505. DICOM, nykytila 1,29 Tavoitetaso 2,00

6. CCOW, nykytila 0,14 Tavoitetaso 1,507. Arden syntax, nykytila 0,00 Tavoitetaso 0,338. OMG Healthcare-standardit, nykytila 0,43 Tavoitetaso 0,339. HISA, nykytila 0,00 Tavoitetaso 0,3310. Muut CEN TC 251 standardit, nykytila 0,43 Tavoitetaso 1,13

Integroinnissa hyödynnettävät terveydenhuollon standardit

0 0

3,6

2,8 2,75

1,5

2

1,5

0,33 0,33

1,13

2,67

0,38

1,43

0,4

1,29

0,14

0,43 0,430,33

0

1

2

3

4

5

1 2 3 4 5 6 7 8 9 10

nykytila

tavoitetaso


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/


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

Palveluarkkitehtuurin hyödyt ja niiden arviointi

"...mutta miten voin perustella SOA-lähestymistavan?"


Ratkaisujen ja hyötyjen arviointi: tasot

verifiointi (‘määritysten mukaisesti’)verifiointi (‘määritysten mukaisesti’)

validointi (‘tekee asian oikein’,‘toimii käytännön tilanteessa’)

validointi (‘tekee asian oikein’,‘toimii käytännön tilanteessa’)

Kaikille uusille tekniikoille ja tuotteille

Kaikille uusille tekniikoille ja tuotteille

[Saranummi N. Healthcare Technology Assessment and Evaluation. VTT Information Technology, 2003.]

evaluointi (‘tekee oikean asian oikein’, arviointi käyttökontekstissa, suhteessa käytön tavoitteisiin)

evaluointi (‘tekee oikean asian oikein’, arviointi käyttökontekstissa, suhteessa käytön tavoitteisiin)


Tietojärjestelmien arviointitapoja

Lopputulos

Kehittäminen

Suunnittelu

Valinta / Päätöksenteko

Ohjaaminen Mittaaminen

Summatiivinen arviointi

Ennen-jälkeen arviointi

Prosessiarviointi

Formatiivinen arviointi

Normatiivinen arviointi

Summatiivinen arviointi

Vaihtoehtojen arviointi

Arvioitavuuden arviointi

Ennen-jälkeen arviointiNormatiivinen arviointi

Tulosten ja vaikutusten arviointi

Riskien analysointi


SOA ja web services - tavoitellut hyödyt (joita analysoitu SerAPI: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


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


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 (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ä )

Yhteenveto

"...entäs sitten?"


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)


Viitearkkitehtuuri: esimerkki

Operationalsystems

Mainframe

Enterprisecomponents

Services

Business processChoreography

Presentation Portlets WSRP

Composite services

Project or enterprise components

Object-oriented

CRM,ERP

Businessintelligence

Inte

gra

tion a

rchite

cture

Se

curity, M

ana

ge

me

nt,

Mo

nitorin

g, Q

ua

lity of service

[Arsanjani A. Service-oriented modeling and architecture.]


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 USA:laisen terveyspalvelujen tarjoajan IT-strategiasta


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


SOA-siirtymän päävaiheidenhyötymalli

[Sprott D. Best Practice Report - The Business Case for SOA. CBDI Journal, June 2006. ]

Kustannus-säästöt

Nopeusvaatimuksistakäyttöönottoon

Toiminnanyhdenmukaisuus

ja suunnittelu

Oppimisvaihe Integrointivaihe Uudelleensuunnittelu-vaihe

Kulttuurillinenintegraatio

Uudelleenkäyttö

projektissa

Uudelleenkäyttö

organisaatiossa,

vähentynyt integrointityö

Komponenttikehitys,

yleiskäyttöiset ratkaisut,

sovellusten korvaaminen

Prosessien tehokkuus

Uudelleenkäyttö

projektissa

Uudelleenkäyttö

organisaatiossa

Mukautettavat

prosessit

Toiminnan ja IT:n

yhtenevyys

Palvelu

jen

yhde

nmuk

aista

mine

n

Prosessien

yhdenmukaistaminen

Strategian ja operatiivisen

toiminnan yhtenevyys


Kiitos

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

[email protected]

www.uku.fi/tike/his/serapi/

http://www.uku.fi/tike/his/serapi/

http://www.uku.fi/tike/his/serapi/

40

palvelutprosessitja ohjelmistotTerveydenhuollon 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.

Hyvinvointi-IT:n tutkimus ja kehitys:

Ilmoittautumiset ja lisätietoja: www.uku.fi/hyvinvointi-it

SerAPI - ZipIT - Avointa - Export HIS - eHP - Äippä - Indehela

Seminaari

12.6.2007Helsingissä


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

järjestelmien integroinnista soa:an

Documents