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