Korkeakoulujen IT-päivät

Transkriptio

1 KA-tutkimusta yliopistoissa: SOLEAhanke Service-Oriented Locally Adapted Enterprise Architecture Palvelupohjainen paikallisesti sovitettava kokonaisarkkitehtuuri Korkeakoulujen IT-päivät Juha Mykkänen, Itä-Suomen yliopisto, Tietojenkäsittelytieteen laitos, -yksikkö Kari Hiekkanen, Aalto-yliopiston Teknillinen korkeakoulu, SoberIT-laboratorio

2 Esityksen sisältö Yleistä SOLEAsta Tavoitteet, osapuolet Työkohteet Poimintoja ja esimerkkejä tuloksista Toiminnan kuvausten tasot ja näkökulmat KA + vaatimusten hallinta + mittaus Hallintamalli KA-työssä huomioitavaa 2

3 Motivaatio Toimintaympäristön muutos, verkottuminen nopea mukautuminen uusiin toimintamalleihin tietojärjestelmien muutospaineet Palvelukeskeinen arkkitehtuuri (SOA) noussut keskeiseksi arkkitehtuurikehykseksi joustava, nopealiikkeinen, mutta hallittu "enterprise"-tason tietojärjestelmäympäristö, liitettävyys Miten palvelukeskeisyyden kautta saadaan konkreettisesti tuettua näitä arkkitehtuuritavoitteita organisaatioissa ja verkostoissa? 3

4 SOLEA: Tekes-tutkimushanke, / Itä-Suomen yliopisto Terveydenhuollon tietojärjestelmien T&K-yksikkö, tkt-laitos SoberIT / Aalto-yliopiston Teknillinen korkeakoulu Ohjelmistoliiketoiminnan ja tuotannon laboratorio Terveyspalvelujen tuottajat Helsingin ja Uudenmaan shp, Medbit / Varsinais-Suomen shp, Pohjois-Savon shp/istekki, Satakunnan shp Teollisuusyritykset ja palvelutuottajat Konecranes, Metso, Osuuspankkikeskus, Raha-automaattiyhdistys, Järjestelmä- ja teknologiatoimittajat ja IT-integraattorit Commit;, Datawell, Fujitsu Services, Intersystems, Itella, Logica, Mawell, CSC Yhteistyöorganisaatiot Tieke, HL7, Kela, STM, Kuntaliitto, Kunta-IT, Sosiaalialan tietoteknologiahanke 4

5 Mikä on yritysarkkitehtuurinne (EA) nykytila? Ei ole / ei tarvita Suunnit -teilla Kokeilu tai pilotti Käytössä EA roadmap/ tavoitearkkitehtuuri Standardoidut rajapintateknologiat Standardoidut teknologia-alustat Yhteinen sanasto tai tietomalli koko organisaation tasolla Yhteisiä prosessimäärittelyjä organisaation eri osissa Yhteisten palveluiden ja sovellusten rahoittamisprosessi Tietotekniikkahankkeilla aina business-case Kaikki IT-projektit katselmoidaan kokonaisarkkitehtuurin kannalta [SOLEA-kohdistuskysely ote, 2008] 5

6 KA-tutkimus SOLEAssa Tutkitaan ja kehitetään palvelukeskeisen arkkitehtuurin (SOA) hyödyntämistä osana organisaatioiden kokonaisarkkitehtuuria (EA) Tutkitaan & mitataan miten joustavuus ja liitettävyys saavutetaan (kokonaisuuden kehittäminen, nopeat kehityssyklit) Keskitytään osapuolten kannalta olennaisimpiin arkkitehtuuri- ja integraationäkökulmiin, joita voidaan soveltaa osapuolten toiminnassa Menetelmäkohteet esim. EA- ja SOA-kuvausten hyödynnettävyys, prosessien ja toiminnan kuvauksen yhteiset tasot ja näkökulmat, Agile Governance Model, SOA-siirtymästrategiat, SOA-hyötyjen mittaus, SOA + integraatio + standardit Soveltamiskohteet yhteiset, esimerkiksi käyttäjähallinnan segmenttiarkkitehtuuri, terveydenhuollon palvelutapahtumien hallinta osapuolten omat, esim. Satshp päivystysprojekti ja kokonaisarkkitehtuuri, Raketti/KOKOA - Kartturi Yhteisiä malleja, tietoa eri kuvaustapojen ja menetelmien käyttökelpoisuudesta 6

7 Näkökulmia kokonaisarkkitehtuuriin [Dragstra, 2005] Prosessien hallinta ja parantaminen (Business process centric) Toiminnan ymmärtäminen ja johtaminen (Governance centric) Toiminnan ja tietoteknisten ratkaisujen vastaavuus (IT centric) 7

8 KA ja KA-menetelmä erottaminen Kokonaisarkkitehtuurimenetelmä on tapa jäsentää ja hallita kokonaisuutta jäsennysmallit, toimintatavat, kuvaustavat, hallintamallit Kokonaisarkkitehtuuri: menetelmää käyttäen tehty jäsennys organisaation / yksikön toiminnasta ERIKSEEN Kohdealuearkkitehtuuri: yleistetty, kattaa useita organisaatioita / yksiköitä ERIKSEEN Segmenttiarkkitehtuuri tietystä näkökulmasta tehty tarkempi kuvaus, voi kattaa useita organisaatioita / yksiköitä KA-menetelmä on hyödyllinen myös kohdealue- ja segmenttiarkkitehtuurien jäsentämisessä mutta monet kuvaukset ja ohjeet keskittyneet tiettyyn ympäristöön sidotun kokonaisarkkitehtuurin kuvaamiseen SOLEA - 8

9 Tarkasteltuja haasteita yleisten mallien riittävä soveltaminen paikallisesti arkkitehtuurin käyttö kommunikoinnissa oikean kielen ja kuvaustason valinta erityisesti johto ja kohdealueen asiantuntijat hallintamallien jalkauttaminen vaatimusten hallinta suhteessa kokonaisarkkitehtuuriin yhteentoimivuuden tukeminen ja standardien sovitus kokonaisarkkitehtuuriin palvelupohjaisuuden ja SOA:n konkretisointi kokonaisarkkitehtuurissa ja integraatioissa joustavuus ja uudelleenkäyttö vs. tarkkuus JOHTO TYÖNTEKIJÄ KEHITTÄJÄ TOIMINTA TIETO ASIAKAS TIETOJÄRJESTELMÄ TEKNOLOGIA 9

10 Työkohteiden tuloksia 1 EA ja SOA Governance: yleinen hallintakehikko + soveltaminen ja validointi mm. tietoturvallisuuden ja tietoarkkitehtuurin alueella EA- ja SOA-menetelmät ja välineet TOGAF-, Archimate- ja JHS-kuvauskohteet ja kuvaustavat EA-välineet, kuvaus- ja mallinnusesimerkit KA-arkkitehtuurikuvausten ja -mallien hyödynnettävyys eri tilanteissa (kokonaisarkkitehtuuri, rajattu arkkitehtuurikokonaisuus, integraatio) Prosessien ja toiminnan kuvausten yhteiset mallit: prosessien ja toiminnan kuvausten tasot ja näkökulmat, prosessiopas, kysely prosessimallintamisen nykytilasta ja kehityskohdista vaatimusten hallintamalli suhteessa kokonaisarkkitehtuuriin 10

11 Työkohteiden tuloksia 2 SOA, integraatio ja standardit: SOA -pohjaisen integraation käsitemalli Object Role Modelling-soveltaminen integraatiossa standardien arviointi suhteessa SOA:an, standardointiyhteistyö (OASIS, Open Group, HL7, IHE, SFS, JHS ) SOA roadmap ja SOA-kehitysmallit: SOA roadmap- ja kypsyysmallit kartoitus kehitysmallien kartoitus ja kysely EA- ja SOA-menetelmien soveltaminen segmenttiarkkitehtuureissa / kohdealuearkkitehtuureissa käyttäjä- ja käytönhallinnan palvelupohjaiset määrittelyt palvelutapahtumien hallinta / terveydenhuolto tarkennuksia kansallisiin määrittelyihin osapuolikohtaiset esimerkit 11

12 Poimintoja ja esimerkkejä Toiminnan ja prosessien kuvaustasot Kehittämisen ja mallintamisen näkökulmat Vaatimusten hallinta ja mittaus Palvelupohjaisuus ja SOA

13 TOIMINTA JOHTO TYÖNTEKIJÄ KEHITTÄJÄ ASIAKAS TIETO TIETOJÄRJESTELMÄ TEKNOLOGIA [SOLEA-prosessimallinnuskysely] 13

14 Mallinnuksen tavoitteet: tarkennusta tarvittaisiin Kuvausten käyttötarkoitus Kuvausten tavoiteltu tarkkuustaso Kuvausten sisältö, kohde Muut * Mallintamisen tavoitteet yleensä Kuvaustavat, nimeämiskäytännöt 0 % 5 % 10 % 15 % 20 % 25 % * prosessin omistajuus; resurssointi (mallintamisosaaminen ja sitoutuminen) Poimintoja vastauksista: Nämä jääneet epäselviksi Ketä varten mallinnettava prosessi tehdään? Mallin käyttötarkoitus? Mitä hyötyä mallista on käytännössä? Mikä on kuvaamisen tarkkuustaso? [SOLEA-prosessimallinnuskysely]

15 Toiminnan kuvaamisen tasot SoberIT Yleiskuva tunnistetut yleiset prosessit Software Business prosessikartta and Engineering Institute prosessihierarkia toimintamalli luku: Yleistetyt prosessit ja työnkulut Prosessi yksittäinen prosessi työnkulkujen kuvaukset luku: Yleistetyt prosessit ja työnkulut Toiminto prosessien vaiheina olevien toimintojen kuvaukset lukujen: Toiminnot listaukset/taulukot Teot ja välineet tehtävät: käyttäjien toimenpiteiden ja tietojärjestelmien operaatioiden kuvaukset lukujen: Tehtävät/Teot ja [Case Palvelutapahtumien välineet listaukset/taulukot hallinta]

16 Yleiskuva-tason kuvaus (yleistetty prosessikartta) [Case Palvelutapahtumien hallinta]

17 Prosessitaso, esim. BPMN [Case Satshp päivystys] 17

18 Prosessi- / työnkulkutaso: Virtausmalli (Stock and Flow Map) Virtausmalli kuvaa prosessia kokonaisuutena (ei yksittäisen tapahtuman kulkua vaan koko asiakasvirran kulkua Missä ovat virtauksen pullonkaulat? Minkä ongelman ne aiheuttavat? Mikä on ongelman koko? Mitä pullonkauloille voi tehdä? Kokonaistilanne [Case Satshp päivystys] 18

19 [Case palvelutapahtumien hallinta] Toiminnonkuvaustaulukko 1.15 Tutkimus- tai konsultaatiopyynnön vastaanottaminen ja toteutus Tarve Pyynnön käsittely ja palvelun tarjoaminen pyytäjälle Heräte Pyynnön saapuminen ja valitseminen käsiteltäväksi Osallistujat hoidon toteuttamiseen osallistuva palvelunantaja, ammattihenkilö, palvelunantajan tietojärjestelmä (mahdollisesti useita), erityisesti erillisjärjestelmän kannalta relevantti, hoidon toteuttamisvastuussa oleva palvelunantaja Esiehdot Pyyntö on saapunut ja käytettävissä Kuvaus / tarkemmat Mikäli kyseessä on ulkoinen pyyntö, muodostetaan uusi tehtävät palvelutapahtuma 2.13 palvelutapahtuman muodostaminen. Suoritetaan pyynnössä ilmaistu palvelu Tuotetaan vastaus, josta näkyvät suoritetun palvelun tulokset. 1.6 hoidollisen merkinnän tekeminen. Poikkeukset Jälkiehdot Tarvittavat tiedot Tuotettavat tiedot Palvelun toteutuksesta syntyneet tiedot ovat käytettävissä, vastaus on toimitettu, palvelu on päättynyt. Tuloksiin liitetään tieto palvelunantajan siitä palvelutapahtumasta, jossa palvelu on annettu. Jos kyseessä on ulkoinen pyyntö, tulokset liitetään sekä palvelunantajan että tilaajan / pyytäjän palvelutapahtumaan. 19 Tällöin

20 [Case palvelutapahtumien hallinta] Tehtävänkuvaustaulukko (lähellä SOA-toteutuksia) 2.18 Palvelutapahtumatunnuksen luonti (10.1. Luo palvelutapahtuman OID-tunniste - alikäyttötapaus (KT09b)) Tarve Kun palvelutapahtuma syntyy, sille tarvitaan yksiselitteinen tunniste. (KT09b) Heräte 2.13 Palvelutapahtuman muodostaminen Osallistujat palvelunantajan tietojärjestelmä Esiehdot Potilaalla on hoitosuhde ko. palvelujen antajan kanssa (KT09b) Kuvaus / tarkemmat Luodaan ja palautetaan tunniste (KT09b) tehtävät. Muodostetaan yksikäsitteinen OID-ohjeistuksen mukainen palvelutapahtumatunnus (OID) ja muut tarvittavat tiedot, joilla eri merkintöjä tai asiakirjoja voidaan liittää palvelutapahtumaan. Tunnistetut poikkeukset Jälkiehdot Tarvittavat tiedot Tuotettavat tiedot Automatisoinnin tarve Muuta Palvelutapahtumalla on yksikäsitteinen tunniste Palvelutapahtumatunnus automatisoitava OID-tunnistetta ei välttämättä tarvitse tuottaa potilastietojärjestelmässä, vaan organisaatiolla voi olla erillinen sovellus tai palvelu niiden tuottamiseksi. Organisaation on kuitenkin pidettävä huolta siitä, ettei

21 Kehittämisen ja mallinnuksen näkökulmat Näkökulma Mallintamisen tavoite Mitä kehitetään Mitä kuvataan Työn organisointi ja tehostaminen tai (liike) toiminnan Arvon kehittyminen ja Johto/ yhdenmukaistaminen, laatutyö, tulosten tuloksia ja laatua arvoverkko (value network), johtaminen parantaminen, toiminnan seuranta keskeiset (liike)toiminta-prosessit, ylätason prosessit (process) Työntekijä/ työn tekeminen/ työtoiminta (yhteistoiminnallinen tai yksilön työtä kuvaava) Kehittäjä / tieto-järjestelmä / tietojärjestelmän kehittäminen / ohjelmiston kehittäminen Asiakas, palvelu tai itsepalvelu; palvelun hankkiminen Kuvata prosessit niin, että työntekijä (myös uusi) osaa toimia prosessikuvausten perusteella, tai että voidaan tunnistaa parannuskohteita Työtoiminnan ymmärtäminen; työhön liittyvien tietotarpeiden esilletuominen työn automatisointi, prosessin tai sen osan suorittaminen tai tukeminen ohjelmiston avulla => ohjelmiston tuottaminen / ohjelmiston määrittely, kohdealueen ymmärtäminen, simulointi ja eri vaihtoehtojen löytäminen vrt työntekijä: asiakas osaa toimia kuvauksen perusteella oman tilanteensa edellyttämällä tavalla SOLEA - 21 työn sujuvoittaminen ohjelmistoja / tietojärjestelmiä / SOA-palveluita Palvelu-toiminta tai itsepalvelu Prosessit (process), Työnkulut (workflow). Tehtävät ja suoritusjärjestys. Työnkulut + tarkat toiminnot, toisiinsa liittyvät toiminnot ja työnkulut, rajapinnat, esi- ja jälkiehdot, heräte (event/ trigger), toiminnossa käsiteltävät tiedot: syöte (input) ja tulokset (output); Työnkulku / asiakasprosessin kulku, ulkoinen näkymä tarjottaviin palveluihin

22 Toimintamallin kommunikointi liiketoimintajohdon kielellä: esimerkkinä Business model canvas PIILOTA arkkitehtuurista piirteet, jotka eivät ole vastaanottajan kannalta olennaisia 22 [Osterwalder]

23 Tarina KA-näkökulmien ja sidosryhmänäkökulmien linkitys Aarnen kurkku on tullut niin kipeäksi, että nieleminenkin tuntuu mahdottomalta. Lisäksi häntä paleltaa. Aarne soittaa oman terveyskeskuksensa terveydenhuollon palvelunumeroon, kertoo haluavansa ajan lääkärille, minkä jälkeen puhelu ohjataan hoidon tarvetta arvioivalle hoitajalle. Aarne kertoo tilanteen. Lääkäriajat menevät monta tuntia eteenpäin, mutta koska terveydenhoitajan vastaanotolle pääse puolen tunnin päästä, Aarne saa ajan sinne. Terveydenhoitaja katsoo Aarnen kurkkuun, koettelee kaulaa, ja mittaa kuumeen. Terveydenhoitaja epäilee angiinaa, ja ottaa pikatestin vastaanotolla. Testin tulos on negatiivinen. Terveydenhoitaja Palveluketjun lähettää Aarnen kuvaus laboratorioon verikoetta varten, jolla (asiakkaan selvitetään ns. mononukleoosin ja mahdollisuus ja otetaan influenssan nielunäyte. Aarne tulee takaisin terveydenhoitajan luo, joka antaa Aarnelle nestemäistä särkylääkettä. Aarne menee kotiin apteekin kautta, matkalla kurkku alkaakin jo tuntua siedettävämmältä eli särkylääke helpotti vaivan siedettäväksi. Aarne soittaa illalla vastauksista terveydenhoitajalle, ja kuulee sairastavansa mononukleoosia. Terveydenhoitaja antaa Aarnelle ohjeet omahoidosta ja siitä, koska pitää hakeutua uudestaan hoitoon. Lisäksi hän kirjoittaa todistuksen työantajaa varten kolmeksi päiväksi. Kolmen päivän päästä Aarnella on edelleen kuumetta, kurkku kipeä ja särkylääkkeen tarve melkoinen. Työhön ei tässä kunnossa voi mennä, ja tarttuvaksikin tautia oli sanottu. 23 Aarne asiantuntija-työntekijän näkökulma) Palvelutapahtuma Merkinnät Toiminnot (Luku 7.1) 1. pt alkaa Hoidon tarpeen arvioinnista Ajanvaraus 1. pt jatkuu Käyntimerkin tä Lab pyynnöt 1. pt jatkuu Käyntimerkintä jatkuu 1. pt jatkuu 1. pt päättyy Lab tulokset Puhelinkäyntimerkin nät Todistus 2. pt alkaa Hoidon tarpeen arviointi 1.6 Hoidollisen merkinnän tekeminen 1.2 Ajanvarauksen tekeminen ilman lähetettä Linkitys 1.6 Hoidollisen merkinnän tekeminen tarvittavan 1.14 Tutkimus- tai konsultaatiopyynnön toiminnon tekeminen kuvaukseen 1.6 Hoidollisen merkinnän tekeminen (tj-kehittäjän näkökulma) 1.6 Hoidollisen merkinnän tekeminen 1.13 Potilaan kotiutus / käynnin päättyminen 1.6 Hoidollisen merkinnän tekeminen 1.2 Ajanvarauksen tekeminen

24 Vaatimusten hallinta ja KA Tausta: arkkitehtuurimenetelmän (kuten TOGAF ADM) keskellä on vaatimusten hallinta, josta on kaksisuuntainen nuoli jokaiseen työvaiheeseen. Miten erotan kokonaisarkkitehtuuritason ja projektitason vaatimukset? Miten tunnistetaan oikean kokoiset vaatimukset kullakin kierroksella? Miten vaatimukset kuvataan? Miten liiketoiminnan vaatimukset ja reunaehdot sekä tietotekniikan vaatimukset ja reunaehdot sovitetaan yhteen? Miten vaatimusten tuotto- ja kustannusvaikutukset sekä taloudelliset reunaehdot ja resurssit otetaan huomioon?

25 Tavoitteiden ilmaisu kokonaisarkkitehtuurin kuvauksissa H I E R A R K I A DRIVER yleensä ulkoisia mitataan tarkkailemalla toimintaympäristöä GOAL strategiset tavoitteet: yleensä yleisellä tasolla mahdollisuus määrällistämiseen? OBJECTIVE tavoitteita, joille on voitava määritellä toteutumisen seuranta tai mittaus MEASURE mittarit (ks. mitattavat suureet ja mittarityypit: erityisesti toimintaprosessit, käyttäjä- ja asiakastyytyväisyys, tiedot) [esimerkit: Kari Lehtinen] 25

26 Tavoitteiden ilmaisu kokonaisarkkitehtuurin kuvauksissa - jatkuu VOIVAT LIITTYÄ MONIIN KA-ELEMENTTEIHIN REQUIREMENT toiminnalliset ja ei-toiminnalliset vaatimukset PRINCIPLE sekä arkkitehtuuriperiaatteet että eri näkökulmien ohjaavat periaatteet CONSTRAINT sekä arkkitehtuurin että eri näkökulmien rajoitteet ASSUMPTION sekä arkkitehtuurin että eri [esimerkit: näkökulmien oletukset Kari Lehtinen] Kaikissa eri karkeustasoja ja kohdistumista eri näkökulmiin, mittaaminen vaatii usein purkamista pienempiin indikaattoreihin

27 Mittarityypit Lukumäärämittarit Työmääräja ajalliset mittarit Laadulliset mittarit Taloudelliset mittarit Mitattavat kohteet käyttäjä- ja asiakastyytyväisyys käytettävyys- ja saatavuus toimintaprosessit tiedot kehitysprosessi / toimittaja kehitysprosessi / asiakas tai integraattori tekniset 27

28 Hallintamalli (Agile Governance Model) (Ei kokonaisarkkitehtuurin vaan organisaation johtaminen) [Korhonen, Hiekkanen, Lähteenmäki] SOLEA - 28

29 Soveltaminen vaatimustenhallinnassa ja kokonaisarkkit ehtuurissa SOLEA - 29

30 Palvelupohjaisuus: eri kerrosten tarjoamat palvelut Business services SOA services IT services

31 Archi esimerkki (Archimatenotaatio) Business service SOA service / application 31

32 Palvelut / tehtävät matriisi Kontekstinhallinta Palvelutapahtumien integraatioinfrastruk- Potilashallinnollisen prosessin hallinnoija Tietosisällön hyödyntäjä Tietosisällön tuottaja Luettelon hakupalvelu Asiakirjojen hakupalvelu Tapahtumatietojen varasto Merkintöjen muodostamispalvelu Asiakirjojen lähettämispalvelu Asiakirjojen muodostamispalvelu Arkistopalvelu Käyttäjä (ammattihenkilö, asiakas) Aktiivisista palvelutapahtumista yhden valinta k,l k k, P l, P k, P P l l Aktiivisten palvelutapahtumien selvittäminen l? k, P l, P l? k, P k,p l Asiakirjan arkistointi k P l P k k? Asiakirjan haku arkistosta k P l? P l k,l l Asiakirjojen kuvailutietojen haku arkistosta k l, P l? P k,l l Asiakirjan liittäminen palvelutapahtumaan l P l l l k,l P,l l Asiakirjan muodostaminen merkinnöistä P l l, k k Tietojen näyttämisen viivästyttäminen l,k P? P? P, k Asiakkaan tapahtumien listaus l k P,l k k Asiakkaan valinta vastaanoton tai k P, P,l osaston potilasluettelosta l Merkinnän liittäminen palvelutapahtumaan l P l k,l k,l l,p,k l 32

33 Järjestelmät / palvelut matriisi Kontekstinhallinta Palvelutapahtumien integraatioinfra Potilashallinnollisen prosessin hallinnoija Tietosisällön hyödyntäjä Tietosisällön tuottaja Luettelon hakupalvelu Asiakirjojen hakupalvelu Tapahtumatietojen varasto Merkintöjen muodostamispalvelu Asiakirjojen lähettämispalvelu Asiakirjojen muodostamispalvelu Arkistopalvelu Valtakunnallinen palvelu P?? m P P Alueellinen tai paikallinen palvelu m m m m m m m m P P (Potilashallinnon) ydinjärjestelmä P P P P P P P P P m Yksikkökohtainen erillisjärjestelmä P m m P m P m Organisaatioiden yhteinen erillisjärjestelmä P m m P m P m p=palvelun tarjoaja (varmasti jossakin tiedossa olevassa ympäristössä), m=mahdollinen palvelun tarjoaja. 33

34 Yhteenveto Kokonaisarkkitehtuuri ja KA-menetelmä on vahva väline monimutkaisen kokonaisuuden jäsentämiseen käyttö erilaista organisaation, kohdealueen tai segmentin kannalta Ensin valot päälle: arkkitehtuurin ja kuvausten käyttötarkoitus ja kohderyhmät oltava kirkkaasti selvillä! kuvausten kohteet, kuvaustavat, kehittämisprosessi, hallintamalli sovitettava paikallisiin tarpeisiin arkkitehtuuritaulukoiden ja mallien sokea täyttäminen ja kokoaminen aiheuttaa runsaasti turhaa työtä kehittämisen tavoitteiden ja vaatimusten määrittely mittarien avulla! Palvelupohjainen ajattelu toimintatason palvelut erotettava tietojärjestelmäpalveluista SOA ja tietojärjestelmäpalvelut loogisen tason jäsennyksessä / tietojärjestelmäarkkitehtuuri-näkökulmassa: hyviä kokemuksia etenkin kohdealue- ja segmenttiarkkitehtuureissa huomiointi mahdollista myös suhteessa nykyjärjestelmiin ja siirtymäpolkuihin 34

35 Kiitokset Ks. myös TTL / KAOS-yhteisö Sytyke / SOA SIG 35

36 Kuvaustavat ja kuvausten kohteet SoberIT Preliminary Phase Principles catalog Phase A, Architecture Vision Stakeholder Map matrix Value Chain diagram Solution Concept diagram Phase B, Business Architecture Organization/Actor catalog Driver/Goal/Objective catalog Role catalog Business Service/Function catalog Location catalog Process/Event/Control/Product catalog Contract/Measure catalog Business Interaction matrix Actor/Role matrix Business Footprint diagram Business Service/Information diagram Functional Decomposition diagram Product Lifecycle diagram Goal/Objective/Service diagram Use-Case diagram Organization Decomposition diagram Process Flow diagram Event diagram Phase D, Technology Architecture Technology Standards catalog Technology Portfolio catalog System/Technology matrix Environments and Locations diagram Platform Decomposition diagram Processing diagram Networked Computing/Hardware diagram Communications Engineering diagram Phase C, Data Architecture Data Entity/Data Component catalog Data Entity/Business Function matrix System/Data matrix Class diagram Data Dissemination diagram Data Security diagram Class Hierarchy diagram Data Migration diagram Data Lifecycle diagram Phase E. Opportunities & Solutions Project Context diagram Benefits diagram Phase C, Application Architecture Application Portfolio catalog Interface catalog System/Organization matrix Role/System matrix System/Function matrix Application Interaction matrix Application Communication diagram Application and User Location diagram System Use-Case diagram Enterprise Manageability diagram Process/System Realization diagram Software Engineering diagram Application Migration diagram Software Distribution diagram Requirements Management Requirements catalog [TOGAF 9] 36

37 Soveltaminen tietoturvan johtamiseen [Korhonen, Yildiz, Mykkänen] SOLEA - 37

38 Organisaation päätöksenteko ja johtamistasot (Requisite control structure) SOLEA - 38

39 Esimerkkiorganisaation hallintamalli service modeling support integrations support team EA team EA steering Chief architect BA & TA virtual teams Area specific Steering Groups Architecture area virtual teams process modeling support data modeling support appl.arch. support team Planning CIO Bus. exec. Product managers Head of IT Operational infra SG IT mgmt. group ICT operations managers operations teams ICT depart. SGs end-user support teams project SGs project teams Execution on-site support Real-Time Operational Tactical Strategic

40 Change Response time goal example Responsiveness to change Business reengineering (e.g. change E2E process using standardized services) Business process outsourcing (e.g. credit card processing) Change of business rules (e.g. new delivery unit with some new products and rules) New Business Services assembly and rapid consumption (e.g. ) Dynamic Consumer service discovery and consumption (e.g. MyMusic, user-driven mash-up) Dynamic Business Service discovery and real time consumption, (e.g. commodity process elements, new distributed resource service instance) Physical resources (e.g. storage service) Months / years / weeks Weeks / Months Days / Weeks Days / Weeks Minutes Subsecond Subsecond 40

41 ENTERPRISE ARCHITECTURE - A FRAMEWORK Software DATA Business FUNCTION and Engineering NETWORK Institute SCOPE (CONTEXTUAL) List of Things Important to the Business MOTIVATION What How Where PEOPLE Who When Why List of Processes the Business Performs List of Locations in which the Business Operates List of Organizations Important to the Business TIME List of Events Significant to the Business TM List of Business Goals/Strat SCOPE (CONTEXTUAL) Planner ENTITY = Class of Business Thing Function = Class of Business Process Node = Major Business Location People = Major Organizations Time = Major Business Event Ends/Means=Major Bus. Goal/ Critical Success Factor Planner ENTERPRISE MODEL (CONCEPTUAL) e.g. Semantic Model e.g. Business Process Model e.g. Business Logistics System e.g. Work Flow Model e.g. Master Schedule e.g. Business Plan ENTERPRISE MODEL (CONCEPTUAL) Owner Ent = Business Entity Reln = Business Relationship Proc. = Business Process I/O = Business Resources Node = Business Location Link = Business Linkage People = Organization Unit Work = Work Product Time = Business Event Cycle = Business Cycle End = Business Objective Means = Business Strategy Owner SYSTEM MODEL (LOGICAL) e.g. Logical Data Model e.g. Application Architecture e.g. Distributed System Architecture e.g. Human Interface Architecture e.g. Processing Structure e.g., Business Rule Model SYSTEM MODEL (LOGICAL) Designer Ent = Data Entity Reln = Data Relationship Proc.= Application Function I/O = User Views Node = I/S Function (Processor, Storage, etc) Link = Line Characteristics People = Role Work = Deliverable Time = System Event Cycle = Processing Cycle End = Structural Assertion Means =Action Assertion Designer TECHNOLOGY MODEL (PHYSICAL) e.g. Physical Data Model e.g. System Design e.g. Technology Architecture e.g. Presentation Architecture e.g. Control Structure e.g. Rule Design TECHNOLOGY MODEL (PHYSICAL) Builder DETAILED REPRESEN- TATIONS (OUT-OF- CONTEXT) Ent = Segment/Table/etc. Reln = Pointer/Key/etc. e.g. Data Definition Proc.= Computer Function I/O = Data Elements/Sets e.g. Program Node = Hardware/System Software Link = Line Specifications e.g. Network Architecture People = User Work = Screen Format e.g. Security Architecture Time = Execute Cycle = Component Cycle e.g. Timing Definition End = Condition Means = Action e.g. Rule Specification Builder DETAILED REPRESEN- TATIONS (OUT-OF CONTEXT) Sub- Contractor Ent = Field Reln = Address Proc.= Language Stmt I/O = Control Block Node = Addresses Link = Protocols People = Identity Work = Job Time = Interrupt Cycle = Machine Cycle End = Sub-condition Means = Step Sub- Contractor FUNCTIONING ENTERPRISE e.g. DATA e.g. FUNCTION e.g. NETWORK e.g. ORGANIZATION e.g. SCHEDULE e.g. STRATEGY FUNCTIONING ENTERPRISE John A. Zachman, Zachman International (810) SOLEA - 41

42 SOLEA - 42

43 Tähänastisia tuloksia o = opinnäyte t = työkohdemateriaalit j = julkaisuja m = muita tuotoksia Kohdistuskysely, osapuolitarkennukset m Service oriented EA metamodel tarkennukset ja soveltaminen eri osapuolicase-tilanteissa jt EA Governance Model tarkennukset ja soveltaminen tietoturvan hallintaan jt TOGAF ja Archimate kuvaukset ja kuvaustavat t SOA- ja arkkitehtuurimittarit mt Prosessimallinnuksen tasojen ja näkökulmien tarkennukset ja soveltamiskokemuksia tj Prosessimallinnuskysely t Toimintalähtöisen mallinnustavan tarkennukset ja suhteutus muihin mallinnustapoihin j Käyttäjähallinnan vaatimukset, rajaukset, jäsentämismallit, standardit ja palvelut t Käsitteellisen tietomallinnuksen mallit, ORM ja DEMO t Standardien SOA-arviointiin ja kehittämiseen liittyvät tulokset ja materiaalit jm Palvelutapahtumien arkkitehtuuritarkennukset ja arkkitehtuurikuvasesimerkit tm IHE-selvitykset ja profiilikuvaukset m Ajanvaraukseen ja sähköiseen reseptiin liittyvät toimintoanalyysi- ja standardien hyödyntämisen mallit j SOA-kehitysmallien kartoitus o SOA-migraatiomallit o SOA-projektien sidosryhmien tunnistaminen o SOA terveydenhuollon ohjelmistotuotannossa o BPMN- ja BPEL-mallinnus terveydenhuollossa o Työpöytäintegraatio o Soveltamiskohteiden taustamateriaalit, mm. APQC, TOGAF, Archimate, MDM ja tietoarkkitehtuuri, HL7/SOA, OASIS SET TC, SOA consortium, osapuolten esitykset m 24 seminaarin ja työkokouksen järjestäminen ja materiaalit, SOLEA symposium, matka- ja hankeraportteja 43

44 Kuinka usein mallinnuksen tulokset toimitetaan seuraaville: (1= Ei koskaan 5=Aina) Kuvatun prosessin omistaja Kuvatun prosessin suorittaja Organisaation prosessimallintajat Kuvatun prosessin suorittajan esimies Kaikkien prosessia Kaikkien koskevien prosessia yksiköiden koskevien johto Organisaation tietotekniset osaajat Koko organisaation johto Kuvatun prosessin asiakas Ohjelmistokehittäjät Ohjelmisto, joka suoraan hyödyntää Arkkitehtuurisuunnittelijat 0 % 10 % 20 % 30 % 40 % 50 % 60 % 70 % 80 % 90 % 100 % Harvoin Joskus Yleensä [SOLEA-prosessimallinnuskysely]