Tietojärjestelmäintegraatio Kansallisten etuusjärjestelmien integroiminen osaksi monikansallista tietojenvaihtoverkkoa

Pekka Repo Tietojärjestelmäintegraatio Kansallisten etuusjärjestelmien integroiminen osaksi monikansallista tietojenvaihtoverkkoa Opinnäytetyö Tietotekniikan koulutusohjelma Joulukuu 2008

KUVAILULEHTI Opinnäytetyön päivämäärä 28.11.2008 Tekijä(t) Pekka Repo Koulutusohjelma ja suuntautuminen Tietotekniikka Nimeke Tietojärjestelmäintegraatio Kansallisten etuusjärjestelmien integroiminen osaksi monikansallista tietojenvaihtoverkkoa Tiivistelmä Tietoverkkojen ja järjestelmien monimutkaistuminen ja tiedon jakamistarpeen lisääntyminen organisaatioiden sisällä ja eri organisaatioiden välillä on aiheuttanut organisaatioissa tarpeen integroida eri tietojärjestelmiä tai niiden tuottamia tietoja. Integrointi on pitkä projekti, joka sisältää toimialan tuntemuksen, prosessien mallintamisen, nykyisen sovellusarkkitehtuurin, arkkitehtuuriratkaisut ja niiden toteuttamisen sekä ratkaisun testaamisen. Tässä työssä kuvataan, miten Kansaneläkelaitoksen mittavassa integraatiohankkeessa eri EU-maiden etuustiedot integroidaan osaksi tietojenvaihtoverkkoa. Tietojenvaihtoverkon kautta voidaan jakaa eri maissa myönnettävien sosiaaliturvaetuuksien tietoa ja huomioida niiden vaikutus päätettäessä henkilön etuuksista toisessa maassa. Tarkemmin työssä kuvataan Kansaneläkelaitoksen EESSIN osuudessa käytettävät arkkitehtuuriratkaisut sekä tekniikat. Integraatioon on olemassa erilaisia menetelmiä ja välineitä, joita voidaan käyttää hyväksi. Nykyisin on olemassa myös paljon valmistuotteita, joiden avulla voidaan saada järjestelmät toimimaan keskenään saumattomasti. Valmistuotteiden käyttöön liittyy aina haasteena valmistuotteiden suuri määrä ja eri valmistajien tarjoamat tekniikat. Eri valmistajien valmisohjelmistot saattavat myös toimia huonosti yhdessä muiden valmistajien valmisohjelmistojen kanssa. Kansaneläkelaitos on vastuussa Suomen osalta etuustietojen integroimisesta kansainväliseen tietojenvaihtoverkkoon. Integraatioratkaisussa sanomapohjaiset viestit tulevat kulkemaan Kelan järjestelmien läpi ja Kela välittää sanomia myös muihin etuuslaitoksiin. Integraatiohankkeet onnistuvat varmimmin, mikäli ratkaisut perustuvat yleisiin käytössä oleviin standardeihin ja tekniikoihin. Integraation tulisi olla joustava ja järjestelmät eivät saisi olla riippuvaisia toisistaan. Asiasanat (avainsanat) järjestelmäarkkitehtuuri, integraatio, SOA, tietojärjestelmät, tietoliikenne, sosiaalietuudet Sivumäärä Kieli URN 57 s. + liitt. 3 s. Suomi URN:NBN:fi:mamkopinn200829842 Huomautus (huomautukset liitteistä) Ohjaavan opettajan nimi Matti Koivisto Opinnäytetyön toimeksiantaja Kansaneläkelaitos, Tietohallinto

DESCRIPTION Date of the bachelor's thesis 28.11.2008 Author(s) Pekka Repo Degree programme and option Information Technology Name of the bachelor's thesis Information system integration National benefits system integration part of multinational information network Abstract These days the information networks are complicated and the sharing of data between organizations has grown. Because of this, the organizations have needed to integrate their systems and the information that systems produce. Integration is a long project that includes knowledge of the industry, modelling of processes, knowledge of system architecture and implementing and testing selected architecture solutions. The purpose of this bachelor s thesis is to describe how Kela will integrate its own systems as a part of the EESSI-architecture. The EESSI-information network will provide the sharing of information between the countries of the European Union. Such information will concern social benefits when a person is in another country inside the EU. There are many different kinds of technologies and tools that have been made available for the integration process. These integration tools are pre-made and they can be used when it is wanted for the systems to work together. Nevertheless when using these pre-made tools there can be challenges because of the differences between the tools and their manufacturers. There are large amounts of alternative techniques. Perhaps, products manufactured by different groups may not work together very well. Kela is responsible for integrating Finnish benefits systems to the international network. In this integration solution the messages will precede through Kela systems and Kela will forward these messages for other institutions in Finland as well. The most definite way for the integration projects to succeed without failing is if the techniques and standards are common. Therefore, Integration should be flexible and the systems should not be dependent on each other. Subject headings, (keywords) system architecture, integration, SOA, information systems, data communications, social benefits Pages Language URN 57 p. + app. 3p. Finnish URN:NBN:fi:mamkopinn200829842 Remarks, notes on appendices Tutor Matti Koivisto Bachelor s thesis assigned by Kansaneläkelaitos, Data Admistration

SISÄLTÖ 1 JOHDANTO... 1 2 INTEGRAATIOARKKITEHTUURI JA -PROJEKTI... 3 2.1 Integraatioarkkitehtuuri... 5 2.2 Integraatioprojekti... 7 2.2.1 Prosessien mallintaminen... 8 2.2.2 Tietoarkkitehtuurin mallintaminen... 8 2.2.3 Integraation hyötyjen selvittäminen... 8 2.2.4 Integraatioprojektin riskien kartoittaminen... 9 3 INTEGRAATIOTAVAT JA TYYPIT... 10 3.1 Integraatiotavat... 10 3.1.1 Organisaation sisäinen integraatio... 11 3.1.2 Integrointi ulkoisiin järjestelmiin... 11 3.2 Integraatiotyypit... 12 3.2.1 Tietokantojen yhdistäminen... 13 3.2.2 Portaalit... 14 3.2.3 Sovellusten jakaman businesslogiikan rakentaminen (SOA)... 15 3.2.4 Sovelluksia yhdistävän liiketoimintologiikan rakentaminen (BPM)17 3.2.5 Business-To-Business integraatio (B2B)... 18 4 TIETOJÄRJESTELMÄARKKITEHTUURIT JA INTEGRAATIO... 19 4.1 Keskuskonejärjestelmä... 19 4.2 Kaksitasoinen järjestelmä... 20 4.3 Monitasoinen järjestelmä... 20 5 INTEGRAATIOTEKNIIKAT JA -VÄLINEET... 21 5.1 Synkroninen kommunikaatio... 21 5.1.1 Soketit... 22 5.1.2 RMI, CORBA ja DCOM... 22 5.1.3 Web Service ja SOAP... 25 5.1.4 Sovellustason liittymät... 27 5.1.5 Liitynnät mainframe-järjestelmiin... 27 5.2 Asynkroninen kommunikaatio... 27 5.3 Tietokantojen kommunikaatio... 28

5.4 Xml... 29 6 INTEGRAATIO- JA MIDDLEWARE-TUOTTEET... 29 6.1 Tietovarastojen integroimisvälineet... 30 6.2 Enterprise Service Bus (ESB) ja palvelurekisterit... 30 6.3 Muita integraatiotuotteita... 31 7 EESSI-ARKKITEHTUURI... 32 7.1 Kansainvälinen osuus EESSIstä... 35 7.1.1 Coordination node... 36 7.1.2 Hakemistopalvelut... 36 7.1.3 Kansainvälinen runkoverkko stesta... 38 7.2 Kansallinen osuus EESSIstä... 38 7.2.1 LUOVA... 40 7.2.2 Reititys Kelan omiin etuuksiin... 41 7.2.3 Reititys muiden toimijoiden etuuksiin... 42 7.2.4 Yhteisten sanomien reititys... 43 8 ACCESS POINT... 44 8.1 Kansainvälinen osuus Access Pointista... 45 8.1.1 Reference Implementation... 46 8.1.2 Adapterit... 48 8.2 Kansallinen osuus Access Pointista... 49 8.3 Käyttöliittymät... 49 9 TEKNIIKAT, TIETOTURVA JA SANOMAT... 50 9.1 Rajapinnat ja tekniikat... 51 9.2 Tietoturva... 51 9.3 Sanomat ja niiden rakenne... 52 10 YHTEENVETO... 52 LÄHTEET... 55 LIITTEET

LYHE TEITÄ JA TERMEJÄ B2B: Business-To-Business. B2B on integraatiotyyppi, jossa tiedonvaihto tapahtuu organisaatioiden tai yritysten välillä. BPM: Business Process Management. BPM on integraatiotyyppi, jossa sovelluksia yhdistetään rakentamalla liiketoimintalogiikka. CICS: Customer Information Control System. CICS on transaktionhallintaan perustuva työkalu IBM-keskuskonemaailmassa. CORBA: Common Object Request Broker Architecture mahdollistaa prosuureiden etäkutsut. DCOM: Microsoftin versio etäkutsumenetelmästä. DECS: Synkroninen kutsumalli, joka paljastaa Lotus Notesin oliomallin. EAI: Enterprise Application Integration on yksinkertaista tiedonsiirtoa organisaation sisällä. EESSI: Electronic Exchange of Social Security Information. Sähköistä tiedonvaihtoa EU-maiden välillä. ESB: Enterprise Service Bus tarjoaa valmiin alustan sovellusarkkitehtuurille ETA: Euroopan Talous Alue eli yhteismarkkina alue Euroopan valtioille EU: Euroopan unioni on 27 jäsenmaan muodostama taloudellinen ja poliittinen liitto FTP: File Transfer Procol on tiedonsiirtomenetelmä kahden tietokoneen välille JCA: Java Connection Api on korkeantason protokolla, jolla voidaan yhdistää erityyppisiä taustajärjestelmiä toisiinsa. LUOVA: Kelan tietojen luovutus- ja vastaanottopalvelu Middleware: Väliohjelmisto, joka toimii kahden ohjelman välissä RMI: Remote Method Invication on etäkutsuprotokolla SAP: Toiminnanohjausjärjestelmä, joka on käytössä useissa yrityksissä SED: Standardized Electronic Document. Sähköinen xml-muotoinen sanoma SOA: Service Oriented Architecture tarkoittaa palvelukeskeistä arkkitehtuuria SOAP: XML-kieleen pohjautuva tietoliikenne etäkutsu-protokolla TLS: Transport Security Layer on nykyisin tavallisin salausprotokolla, jota voidaan käyttää suojaamaan Internet-sovellusten tietoliikenne Web Service: W3C mukainen ohjelmistojärjestelmä, joka mahdollistaa tietoverkon vuorovaikutuksen verkon yli XML: Rakenteinen standardi tiedonvälitystapa

1 JOHDA TO 1 Tietoverkkojen ja tietojärjestelmien monimutkaistuminen on nykyisin hyvin yleistä organisaatioissa. Tietojärjestelmiä on kehittynyt ajan kuluessa eri tarpeisiin. Järjestelmät ovat erillään, eivätkä ne toimi tehokkaasti keskenään. Järjestelmien väliseen tiedonsiirtoon tarvitaan paljon turhaa manuaalista työtä. Manuaalinen työ ja sen myötä syntyvät inhimilliset virheet aiheuttavat organisaatiossa paljon lisäkustannuksia. Niistä halutaan päästä eroon, jotta voidaan toimia mahdollisimman kannattavasti. Organisaatiot pyrkivät parantamaan tietojärjestelmiensä toimivuutta ja tehokkuutta integroimalla niitä. Tietojärjestelmäintegraation tavoitteena on pyrkiä tehostamaan ja yksinkertaistamaan liiketoimintaa ja parantamaan sen kannattavuutta. Integraation tarpeellisuutta ja sen todellisia hyötyjä täytyy kuitenkin aina miettiä ennen integraatiohankkeisiin lähtemistä. Euroopan unionin tulon myötä ihmisten liikkuvuus maiden välillä on kasvanut. Nykyisin maiden rajat ovat hälventyneet ja toisessa maassa ansiotyössä käyvien määrä on noussut. Sosiaaliturvaa sekä esimerkiksi etuuksien myöntämisperusteina olevia työskentelytietoja koskevien kyselyjen ja ilmoitusten määrä on kasvanut EU-maiden kesken. EESSI-projektin (Electronic Exchange of Social Security Information) tarkoituksena on siirtyä ensisijaisesti sähköiseen tiedonvaihtoon sosiaaliturvaa toimeenpanevien EU:n jäsenmaiden laitosten välillä. Tarkoituksena on sallia tiedonvaihto eri maiden välillä toimivaltaisten laitosten kesken sähköisiä dokumentteja käyttäen. EESSI perustuu EU:n asettamaan asetukseen 883/04. Asetus tulee sovellettavaksi, kun sitä koskeva täytäntöönpanoasetus on voimassa (arvio 2010 alku). Täytäntöönpanoasetuksen jälkeen jäsenmailla on 24 kuukautta aikaa siirtyä paperilomakkeista sähköiseen tietojenvaihtoon. Euroopan unionin kokonaisprojektia koordinoi Euroopan komission perustama Task Force. Suomessa EESSI-toteutusta seuraa Sosiaali- ja terveysministeriön asettama työryhmä. Nykyisin tiedonvaihto tapahtuu paperisia lomakkeita käyttäen. EESSIN tarkoituksena on korvata nämä nykyiset lomakkeet sähköisillä dokumenteilla (SED = Standardized Electronic Document), joita laitokset lähettävät toisilleen. Laitoksilla ei tule olemaan suoraa yhteyttä keskenään. Maiden välillä yhteydenpito ja tiedonvaihto tulevat tapah-

2 tumaan yhteyspisteiden (Access Point) kautta. Yhteyspisteistä sanomat ohjataan maiden toimivaltaisiin laitoksiin. Maiden yhteyspisteiden välissä tulee toimimaan komission hallinnoima olemassa oleva suljettu stesta-verkko. Kaikilla laitoksilla ei ole mahdollisuutta integroitua osaksi EESSIä, joten Komissio on määrännyt toteutettavaksi myös selainpohjaisen käyttöliittymän näiden käyttäjien käyttöön. Kansainvälinen osuus arkkitehtuurista toimitetaan EU:n komission valitsemalta ulkopuoliselta toimeksiantajalta ja kansallisesta osuudesta vastaa Suomessa Kansaneläkelaitos (Kela). EES- SIllä on yhteyksiä sisäisiin eli Kelan tarjoamiin sosiaalietuuksiin ja ulkoisiin, eli muiden suomalaisten laitosten tarjoamiin etuustietoihin. Etuuksilla tarkoitetaan yleiseen sosiaaliturvaan liittyviä etuuksia. Nykyisellään Kelan tietojärjestelmäarkkitehtuurilla ei ole täysiä valmiuksia vastata EESSIN asettamiin vaatimuksiin. Haasteena on EESSIN istuttaminen osaksi Kelan omaa tietojärjestelmäarkkitehtuuria. Lisäksi etuustietoja tuottavat organisaatioiden tietojärjestelmät pitäisi saada kommunikoimaan toistensa kanssa saumattomasti. Opinnäytetyö liittyy Kelan osuuteen EESSI-hankkeessa. Työn tavoitteena on kuvata sitä, miten kansallinen tietojärjestelmä integroidaan osaksi monikansallista tietojenvaihtojärjestelmäarkkitehtuuria. Osana opinnäytetyötä tarkastellaan tarkemmin sitä, miten Kelan olemassa olevia tietoliikenneyhteyksiä voidaan hyödyntää sosiaalietuuksien tiedonvaihtointegroinnissa. Työtä voidaan hyödyntää Kelassa, kun mietitään, miten EESSI istuu osaksi Kelan kokonaisarkkitehtuuria. Työssä kuvataan ensin tietojärjestelmäintegraatiota yleisellä tasolla. Alkupuolella valotetaan niitä liiketoiminnan ja toimintaympäristön muutoksia, jotka tyypillisesti johtavat integraatioprojektin käynnistämiseen sekä integraatiolla saataviin hyötyihin. Tämän jälkeen esitellään myös integraatioprojektin kulku sekä suurimpia riskejä, jotka niihin liittyy. Kappaleessa 3 kerrotaan, mitä erilaisia integraatiotapoja ja tyyppejä on. Eri tapojen osalta kerrotaan sisäisistä ja ulkoisista integraatioista ja kuvataan, mikä olisi kuhunkin integraatiotarpeeseen sopiva integraatiotyyppi, eli milloin on hyvä integroida yhdistämällä tietokantoja, milloin taas esimerkiksi käyttää portaalipohjaisia ratkaisuita. Kappaleessa 4 kuvataan integraatioon liittyvät tietojärjestelmäarkkitehtuurivaihtoehdot.

3 Teoriaosion jälkimmäisissä kappaleissa esitellään ne menetelmät ja välineet, joita voidaan käyttää, kun ryhdytään suunnittelemaan järjestelmien yhtenäistämistä. Erityisesti pureudutaan siihen, mitä integraatio- ja middlewaretuotteita on käytettävissä. Osiossa pyritään myös kuvaamaan, milloin kannattaa käyttää valmistuotteita. Teoriaa on sovellettu käytännössä EESSI-projektin arkkitehtuuriratkaisun kuvaukseen. EESSIN osalta kuvataan lyhyesti integraatioprojektin käynnistämisen syyt sekä integraatioprojektin kulku. Työssä kuvataan myös se, mitä olemassa olevia tai tulevaisuudessa rakennettavia yhteysmalleja Kelan ja yhteistyökumppaneiden välillä voidaan käyttää EESSI-projektissa. Tarkemmin kuvataan ratkaisulle suunniteltu arkkitehtuuri sekä siinä käytettävä tekniikka, rajapinnat, tuotteet, sanomarakenne ja yhteydet. Tässä työssä ei oteta kantaa siihen, miten muut yhteistyökumppanit tulevat hoitamaan tiedonvaihdon. 2 I TEGRAATIOARKKITEHTUURI JA -PROJEKTI Arkkitehtuuri syntyy suunnittelemattomasti, jos arkkitehtuuria ei suunnitella. Usein tuloksena on epämääräinen viidakko. Tietojärjestelmäratkaisut tehdään usein yhden sovelluksen näkökulmasta, josta tuloksena on, että kokonaisuuksien hallinnasta tulee vaikeaa ja kallista. Sovellusten riippuvuuksien takia hallinta ja muutokset ovat hankalia. (Lahti 2003, 3.) Organisaatioihin on ajan kuluessa syntynyt useampia osajärjestelmiä, jotka ovat erikoistuneet johonkin tiettyyn liiketoiminnan osa-alueeseen. Organisaatiossa on järjestelmiä, joiden tiedonsiirto vaatii manuaalista työtä ja näin inhimillisten virheiden määrä voi kasvaa (kuva 1). Inhimillisiä virheitä voidaan pitää järjestelmien ja tiedon eheyden riskeinä, joita järjestelmäintegrointi pyrkii poistamaan. Integroinnin tavoitteena onkin liiketoiminnan tehostaminen sekä sitä tukevien prosessien parantaminen. (Tieturi 2008, 5.)

4 KUVA 1. Informaatiota siirretään järjestelmien välillä manuaalisesti Liiketoiminta luo muutostarpeita yrityksen liiketoiminta-arkkitehtuurissa. Tieto- ja järjestelmävaatimukset saattavat muuttua nopeasti. Integraatioprojektin tavoitteisiin kuuluu luoda visio arkkitehtuurista, joka ohjaa eri järjestelmien kehittämiseen liittyviä teknisiä ja toiminnallisia valintoja. Liiketoiminnan avainjärjestelmien tulisi myös toimia tehokkaasti ja automaattisesti keskenään (kuva 2). Kokonaisuuden muuttuessa arkkitehtuurin täytyisi olla myös joustava ja järjestelmät eivät saisi olla liikaa riippuvaisia toisten toiminnasta. Integraation pitäisi myös taata tiedon laatu esimerkiksi keskittämällä tieto yhteen paikkaan. (Tähtinen 2005, 25 26.) KUVA 2. Informaatio siirtyy järjestelmien välillä automaattisesti

5 Integraatioprojekti pyrkii selkeyttämään ja yksinkertaistamaan organisaation arkkitehtuuria. Projektin tavoitteena on, että järjestelmät kommunikoivat toistensa kanssa ja että niihin voidaan tulevaisuudessa liittää uusia järjestelmiä osaksi organisaation arkkitehtuuria. 2.1 Integraatioarkkitehtuuri Tietojärjestelmien kokonaisarkkitehtuurin (Enterprice architecture) tulisi kuvata kaikki yrityksen tai organisaation tietojärjestelmät, niiden suhteet toisiinsa ja ulkopuolisiin toimijoihin. Toimijana voidaan pitää jotain toista tietojärjestelmää, organisaatiota tai jopa ihmistä. Yritysarkkitehtuuri on usein dynaaminen ja liiketoiminta luo sille jatkuvaa muutostarvetta. Integraatioarkkitehtuuri luo yrityksen tai organisaation tietojärjestelmille tavoitetilan, jota ne pyrkivät parhaansa mukaan toteuttamaan tulevaisuudessa. Yleensä integraatioratkaisu kohdistuu usein kaikkiin arkkitehtuurikerroksiin ja alla ne tarkemmin kuvattuina (kuva 3). Liiketoiminta-arkkitehtuuri pyrkii kuvaamaan organisaatioiden palvelut, prosessit, joissa palveluita tuotetaan ja tavoitteet. Tietoarkkitehtuuri eli informaatioarkkitehtuuri kuvaa tietotarpeet, tietovirrat, tietovarannot ja niiden väliset suhteet. Järjestelmäarkkitehtuuri kuvaa järjestelmien rakenteen, käytettävät standardit ja menettelyt. Liiketoiminta-arkkitehtuuri antaa säännöt järjestelmäarkkitehtuurille, joiden avulla järjestelmäarkkitehtuuri rakennetaan. Teknologia-arkkitehtuuri kuvaa myös standardit, teknologiat ja niiden ratkaisut. Arkkitehtuurin on tarkoitus kuvata sovellusten kehityksessä ja hallinnoinnissa käytettävät välineet.

6 KUVA 3. Kokonaisarkkitehtuurissa on monia muuttuvia elementtejä, joita integraatioarkkitehtuurin tulisi hallita Järjestelmäintegraatio voidaan määritellä useilla eri tavoilla. Käsitteellä voidaan tarkoittaa tapoja ja tekniikoita, joilla järjestelmät saadaan kommunikoimaan ja vaihtamaan tietoja toistensa kanssa. Sami Tähtinen (2005, 48.) on määritellyt teoksessaan järjestelmäintegraation toimintamalleiksi ja tekniikoiksi, joiden avulla voidaan saattaa vähintään kaksi eri toiminnallisuutta tarjoavaa tietojärjestelmää jakamaan informaatiota siten, että informaation siirto ja muunnokset ovat kontrolloitavissa ja monitoroitavissa yhdessä tai useammasta keskitetystä pisteestä. Onnistuneessa integraatioarkkitehtuurissa on yksinkertainen perusratkaisu, ja se käyttää standardeihin perustuvia tekniikoita. Integraatioarkkitehtuurin täytyy olla liiketoimintalähtöinen, jossa järjestelmät tukevat liiketoimintaprosesseja eivätkä luo uusia. Tavoitteena onkin työn tehostuminen ja toimintavarmuus. Informaation täytyy olla oikeaa ja riittävän reaaliaikaista. Kaikkein uusimpiin huipputekniikoihin ja tuotteisiin perustuvien ratkaisujen käyttö ei ole itsetarkoitus. (Tähtinen 2005, 27 32.) Seuraavaksi on arvioitava, millaisilla arkkitehtuurisilla muutoksilla tai ratkaisulla ongelmat olisivat ratkaistavissa. Tässä vaiheessa tulee myös esiin se, mitä rajoituksia integroitava ympäristö asettaa. Toteutustekniikkana voi olla myös valmiin integrointialustan tai tuotteen hankkiminen, joka usein tarjoaa valmiin integraatioarkkitehtuurin.

2.2 Integraatioprojekti 7 Integraatioprojektiin ryhdyttäessä, on ensimmäiseksi kartoitettava projektiin liittyvät liiketoimintaprosessit, jotka ovat alimman tason toiminnallisia toimintoja. Prosessit ovat tyypillisesti monimutkaisia ja joiden syvällinen ymmärtäminen vaatii aikaa. Integraation tavoitteena tulee tukea liiketoimintaprosessia, eikä sen pidä pakottaa tekemään asioita tietyllä tavalla. On mahdotonta parantaa järjestelmää, jos ei tiedetä, mihin suuntaan pitää edetä. (Kuva 4.) (Tieturi 2008, 18 21.) KUVA 4. Integraatioprojektin kulku Seuraavana mallinnetaan prosessit. Tässä yhteydessä selviää myös, mitä tietoa eri järjestelmät tallentavat ja mitä tietoa ne tarvitsevat toisiltaan. Tämän jälkeen kuvataan arkkitehtuurin nykytila ja tunnistetaan integraatiotarpeet, sekä tehdään suunnitelmat tulevasta mahdollisesta ratkaisusta. Ennen uuden arkkitehtuuriratkaisun soveltamista täytyy kartoittaa riskit ja pohtia projektin kannattavuutta. Toteutuksen jälkeen testataan integraatioratkaisu ja havaitaan mahdolliset puutteet. (Kuva 4.) (Tieturi 2008, 18 19.) Eri sidosryhmillä on erilainen näkemys tietojärjestelmäarkkitehtuurista. Organisaation johdolle on tärkeitä esimerkiksi raportit järjestelmistä, kun taas järjestelmien toteuttajia kiinnostavat enemmän käytettävät tekniikat ja rajapinnat. Tämä pitäisi huomioida myös projektissa, jotta löytyy sopivat ihmiset projektiin mukaan. Seuraavassa integraatioprojektin eri vaiheet on kuvattu hieman tarkemmin.

2.2.1 Prosessien mallintaminen 8 Integroinnissa prosessien merkitys on suuri. Prosessit ovat alimman tason pieniä toimintoja. Integrointiprojektissa pitää pystyä mallintamaan prosessit, jotta voidaan suunnitella, miten niitä voidaan parantaa. Integraatiotarpeita tulee usein myös siitä, kun mietitään, mitä prosesseja voitaisiin automatisoida. Integraatiossa on tärkeä tunnistaa integraatioon liittyvät tarpeet. Nämä hahmottuvat yleensä parhaiten prosessien kautta. Integraatiotarpeet tulisi tunnistaa, kun halutaan ymmärtää, miten prosessit käyttävät eri sovelluksia ja miten kokonainen tietojärjestelmä voisi toimia tehokkaammin. Prosessien tarvitsema ja tallentama tieto tulee myös tuntea, jotta integraatio olisi tehokasta. Täytyy tunnistaa, mitä informaatiota prosessit tarvitsevat ja missä tieto sijaitsee. (Tieturi 2008, 37.) 2.2.2 Tietoarkkitehtuurin mallintaminen Informaation ymmärtäminen on erityisen tärkeää integraatioprojektissa. Projektissa on mallinnettava järjestelmien käyttämä tieto. Järjestelmät saattavat käyttää informaatiota monesta eri paikasta. On myös ymmärrettävä, onko järjestelmien välillä riippuvuuksia. Esimerkiksi jokin järjestelmä tuottaa tietoa, jota toinen järjestelmä käyttää. (Tähtinen 2005, 79 80.) Prosessit tarvitsevat myös tietoa. Täytyy tietää, mitä tietoa prosessit tarvitsevat, missä se sijaitsee ja mitä merkitsee. Tietoarkkitehtuuria voidaan mallintaa ymmärtämällä sovelluksia ja tutkimalla talletusrakenteita. Koska tietoa on paljon, haasteita tutkimiselle aiheuttaa yleensä tietokantojen runsas määrä sekä rakenteiden huono dokumentointi. (Lahti 2006, 22.) 2.2.3 Integraation hyötyjen selvittäminen Keskeistä on selvittää, onko integrointi kannattavaa ja onko integroinnilla merkitystä organisaatiolle tai yrityksen liiketoiminnalle. Usein integrointihankkeita tehdään, koska on tarve tehdä jotain romahtamaisillaan olevalle järjestelmälle. (Tieturi 2008, 23.)

9 Myös kustannuksia on mietittävä heti projektin alusta alkaen. Nykyisin on käytettävissä myös valmiita integrointialustoja, jotka usein pienentävät työmääriä. Välineet tosin tuovat mukanaan hankinnan ja koulutuksen kustannukset. Täytyy miettiä, maksaako investointi itsensä takaisin ja kuinka pian. (Tähtinen 2005, 44.) 2.2.4 Integraatioprojektin riskien kartoittaminen Integraatioprojektin haasteet keskittyvät yleensä siihen, että on monia erillisjärjestelmiä, jotka käyttävät monia eri tekniikoita ja rajapintoja. Toiminta eri yhteistyökumppaneiden kanssa saattaa olla myös hyvin hankalaa. Nykyisin organisaatioissa saattaa olla useita sidosryhmiä ja on vaikea tietää, kenelle päävastuu integraatioprojektista kuuluu. Kommunikointi eri sidosryhmien kanssa saattaa tuottaa ongelmia ja dokumentointi saattaa olla erilaista riippuen sidosryhmästä. (Tieturi 2008, 13.) Tilanteet ovat uusia organisaatioille ja aikaisempaa kokemusta ei välttämättä löydy. Ongelmia syntyy myös, kun lähdetään pelkästään ratkaisemaan integraatio-ongelmaa työkalun avulla. Markkinoilla on paljon erilaisia sekä eri valmistajien tuotteita. Valinta saattaa tuottaa vaikeuksia, jos päädytään integraatiotuotteisiin. (Tähtinen 2005, 149.) Integraatioprojektin toteutuksen haasteena on yleensä suuri määrä tarvittavia eri tekniikoita ja näiden tekniikoiden osaaminen. Valmiiden integraatioalustojen haasteina on yleensä se, että ne vaativat paljon tuotteen osaamista, jonka hankkimisesta voi aiheutua lisäkustannuksia. Kun organisaatio tai yritys on saanut toteutuksen valmiiksi, saattaa testaus olla hyvin hankalaa. Järjestelmät ovat yleensä liiketoiminnan kannalta välttämättömiä järjestelmiä, joiden toimintaa ei saa vaarantaa. On tärkeää pohtia, miten voidaan seurata, toimivatko järjestelmät oikein. (Tieturi 2008, 27.) Uusi haasteita saattaa tulla jossain vaiheessa, jos tapahtuu esimerkiksi kahden yrityksen fuusio. Yritysten järjestelmien saaminen toimimaan toistensa kanssa saattaa olla siinä vaiheessa huomattavan hankalaa. Ongelmia saattaa tulla esimerkiksi siitä, että toisessa yrityksessä on tehty jo valmiiksi jonkinlainen integraatioratkaisu. Järjestelmät saattavat näin ollen olla toistensa kanssa yhteensopimattomia. Tässä tapauksessa joudutaan integraatio aloittamaan alusta, jos halutaan, että järjestelmät tulevat toimimaan keskenään tehokkaasti. Hyvä esimerkki fuusioitumisen aiheuttamasta työmäärästä on,

10 kun Nokia Networks ja Siemens yhdistyivät vuonna 2007. Nokialla oli jo olemassa keskitetty integraatioratkaisu, mutta Siemensillä oli maakohtaiset hajautetut SAPjärjestelmät ja niiden yhdistämisessä oli valtavasti työtä. (Vuokola 2007.) Järjestelmät jakaantuvat yleensä osajärjestelmiksi, joiden tuntemus on myös avaintekijä, kun suunnitellaan integraatiota. Haasteita tulee, kun on paljon yhteistyökumppaneita ja sidosryhmiä. Pahimmillaan kaikkien taustalla on eri teknologioita ja toimittajia. Tämän vuoksi eri tekniikoiden tuntemus on tärkeää. Integraatioprojekteissa aiheutuu paljon ongelmia, kun ennustetaan aikatauluja tai työmääriä, koska ennustaminen on tyypillisesti hyvin hankalaa integraatioprojektin laajuudesta riippuen. (Tähtinen 2005, 23.) 3 I TEGRAATIOTAVAT JA TYYPIT Integraatioratkaisussa pyritään saamaan keskenään sopimattomat järjestelmät kommunikoimaan toistensa kanssa. Integraatiolla pyritään helpottamaan informaation siirtoa kahden tai useamman järjestelmän välillä, tietomuunnoksia sekä prosessien kontrollointia. Projekti pyrkii antamaan työkalut näiden asioiden ratkaisemiseksi. Ratkaisut riippuvat pitkälti siitä, minkälainen on nykytila organisaatiossa järjestelmien osalta. (Tähtinen 2005, 48.) Integraatio voi yhdistää organisaation sisäisiä järjestelmiä toisiinsa järjestelmien ja tietokantojen tasolla. Toinen tapa on yhdistää esimerkiksi kahden organisaation järjestelmiä toimimaan toistensa kanssa. 3.1 Integraatiotavat Organisaation järjestelmät ovat usein hajallaan ja ne voivat olla yhteyksissä toisiinsa hyvin erilaisten ratkaisujen avulla. Uuden järjestelmän lisääminen osaksi organisaation tietojärjestelmiä on haastavaa. Lisähaastetta tulee kun yritetään yhdistää kahden organisaation järjestelmiä toisiinsa. Seuraavassa on kuvattu erilaisia ja eri tilanteissa käytettäviä integraatiotapoja.

3.1.1 Organisaation sisäinen integraatio 11 Yrityksen tai organisaation sisäinen integraatio eli Enterprise Application Integration (EAI) on yksinkertaista informaation siirtoa yrityksen tai organisaation sisällä. Järjestelmät ovat kehittyneet organisaatiossa omia polkujaan ja eivät ole toisiinsa yhteyksissä. Informaation siirto ei ole mahdollista, koska järjestelmät eivät tarjoa toisilleen rajapintoja eivätkä siirtokerrosta. (Tähtinen 2005, 49.) Organisaatiossa voidaan integroida järjestelmiä tietokantatasolla tai järjestelmien tasolla. Integraation onnistuminen riippuu paljon siitä kuinka kirjava organisaation teknologia on ja kuinka teknologiat sopivat yhteen. 3.1.2 Integrointi ulkoisiin järjestelmiin Yritys tai organisaatio ei ole suljettu ympäröivästä maailmasta. Organisaation ulkopuolellakin saattaa olla sille sen toiminnan kannalta tärkeää informaatiota, johon sen on päästävä käsiksi (kuva 5). Organisaatio saattaa myös joutua lähettämään informaatiota ulkopuolelle. Yritysten välisestä integraatiosta käytetään termiä business-tobusiness integration (B2Bi). KUVA 5. Organisaatiot saattavat jakaa tietoa toistensa kanssa

12 Kommunikointiin yritysten välillä on kehitetty standardeja: EDI eli Electronic Data Interchange kuuluu ensimmäisiin laajassa käytössä oleviin standardeihin. Sitä käytetään edelleenkin Yhdysvalloissa yritysten välisessä kommunikaatiossa. Siinä tietoa siirretään standardimuodossa kahden eri tietojärjestelmän välillä. Edi rakentuu tietosisällöstä, esitystavasta ja tiedonsiirrosta. (Tähtinen 2005, 34.) UN/EDIFACT on johdettu EDI standardista. Se on monikansallinen rakenteinen tiedonesitystapa, joka luotiin 1980-luvun loppupuolella. Standardeissa kuvataan sanomien rakentamisen perusasiat kuten esimerkiksi tietoelementit ja segmentit.(hakala 1998) OVT eli Organisaatioiden Välinen Tiedonsiirto on suomalainen versio EDIFACT-standardista. ebxml on joukko standardeja, ja se välittää xml-merkintäkielen avulla informaatiota kahden yrityksen välillä. ebxml on pyritty luomaan mahdollisimman yleiskäyttöiseksi, ja se pyrkii ottamaan huomioon myös vanhat järjestelmät. ebxml:n toiminta yritysten tai organisaatioiden välillä perustuu rekistereihin ja tietohakemistoihin. (Lahti 2003, 39.) RosettaNet on voittoa tavoittelematon yritysten tiedonvälitykseen liittyvä standardi. RosettaNet on xml:n perustuva ja sen tarkoituksena on luoda yhteinen muoto esimerkiksi kahden kommunikoivan organisaation välille. RosettaNet on keskittynyt elektroniikan komponentteihin sekä informaatio- ja mobiiliteknologiaan. Esimerkiksi suuret yritykset, kuten Nokia ja Dell käyttävät RosettaNet-standardia. (Lahti 2003, 39.) Toimialoilla on erilaiset tarpeet ja näin ollen täysin yleiskäyttöisiä standardeja ei ole pystytty kehittämään. 3.2 Integraatiotyypit Integraatio voi keskittyä moniin eri tietojärjestelmien osa-alueisiin. Järjestelmien käyttämä informaatio voi sijaita monessa paikassa hajallaan ja sovellukset voivat jakaa tietoa tietokantojen tasolla, ja joskus niiden yhdistäminen on tarpeellista. Portaalisovellukset tulevat kysymykseen, kun halutaan yhdistää useita järjestelmiä toimimaan

13 yhdessä. Nykyisin moderni tietojärjestelmä pyrkii uudelleen käyttämään käytössä olevia palveluita ja komponentteja. SOA-ideologia pyrkii antamaan ratkaisun tähän arkkitehtuurimalliin. Myös kahden organisaation osajärjestelmien yhdistäminen saattaa olla käytettävä integraatioratkaisu. Alla on esitelty tarkemmin yleisimmät integraatiotyypit. 3.2.1 Tietokantojen yhdistäminen Tietokantojen yhdistäminen on tyypillinen integraatiotapa, jossa sovellukset voivat jakaa informaatiota toisilleen tietokantojen tasolla. Tietoa voidaan yhdistää kahden tai useamman kannan osalta. Tietokantojen yhdistämisessä ei oteta huomioon minkään sovelluksen käyttäytymistä tietokantojen toiminnassa. Vaan pyritään siihen, että sovellukset toimivat itsenäisesti ottamatta kantaa siihen minkälainen rakenne tietokannassa on. Integraatiotapa sopii erityisesti silloin, jos kantojen rakenne on samanlainen. Yritysten ja organisaatioiden tulisi rakentaa toimiva informaatioarkkitehtuuri, koska rakennettu malli selkeyttää tulevia hankkeita. Esimerkiksi Nokia on luonut yleiskäyttöisen pohjan, jolle uusien järjestelmien informaatioarkkitehtuuri rakennetaan. (Information architecture at Nokia 2006.) Mikäli kantojen rakenteet ovat täysin erilaisia, voidaan käyttöön ottaa väliohjelmisto, joka konvertoi alkuperäisen tiedon rakennetta kohdetietovarastoon sopivaksi. Mikäli tietokantoja käyttävät sovellukset ovat sidoksissa liikaa tietokantojen rakenteeseen, voidaan joutua itse sovellusta muuttamaan. (Lahti 2003, 22.) Relaatiotietokannat ovat nykyään yleisin tietokantatyyppi. Integrointimenetelmästä riippumatta projektin vaiheisiin kuuluu aina, että ymmärretään ja dokumentoidaan tietovarastot ja niiden tasot. (Sainio 2001, 35.)

3.2.2 Portaalit 14 Usein samaa työtehtävää hoitaakseen käyttäjän pitää käyttää useita sovelluksia. Sovelluksien käytön opettelu vie yleensä aikaa ja niiden tekniikat ovat usein erilaisia. Portaalit ovat integraatioratkaisuna usein silloin, kun halutaan yhdistää eri käyttöliittymiä. Portaalien rakentamisen tarkoituksena on tehdä sovellus, joka liittää toisiinsa useita järjestelmiä käyttöliittymätasolla (kuva 6). Integroitu käyttöliittymä eli portaali piilottaa käyttäjän näkyvistä useita turhia toimintoja. Sovellukset eivät tiedä toisistaan portaalimallissa. Jokaisella portaalilla on oma käyttäjäryhmä sekä ulkoasu. Käyttäjillä on omat roolinsa, jonka kautta heille näytetään omat halutut näyttökokonaisuudet. Portaali ei itsessään liiketoiminnallista sisältöä vaan se tarjoaa ainoastaan tuen sellaisen sisällön näyttämiseen eri käyttäjille. (Tieturi 2008, 47.) Markkinoilla on paljon valmiita ja kypsiä portaalituotteita, jotka tarjoavat helpon tavan rakentaa korkeanluokan portaalisovelluksia. Portaalituotteille ei ole täsmällistä määritelmää ja eri valmistajat sisällyttävät tuotteisiinsa eri piirteitä. Markkinoille on tullut myös avoimen lähdekoodin tuotteita, jotka haastavat suuret valmistajat. Portaalituotteiden kautta saadaan ammattimainen ulkonäkö portaalille ja hyvä käytettävyys. Portaalituotteissa on mahdollisuus muokata sen ominaisuuksia. Portaalituotteet tarjoavat kuitenkin myös paljon valmiita ominaisuuksia, esimerkiksi roolituksen. (KOKO 2008.)

15 KUVA 6. Portaali esimerkki PLAZA.fi portaalipalvelusta 3.2.3 Sovellusten jakaman businesslogiikan rakentaminen (SOA) Nykyisin arkkitehtuurit, kielet ja tekniikat kehittyvät. Yritysorganisaatioissa tapahtuu muutoksia arkkitehtuurin muutosten ja tekniikkavalintojen myötä. Onkin pyritty kehittymään siihen suuntaan, että liiketoiminta luo tarpeet ja järjestelmät pyrkivät tukemaan liiketoimintaa tarjoamalla palveluja. SOA (Service Oriented Architecture) mallin mukaiset arkkitehtuuriratkaisut pyrkivät toimimaan liiketoiminnan ehdoilla. SOA ei tarjoa itsessään minkäänlaista teknologiaa, vaan se on puhdas ideologinen ratkaisu. (Tieturi 2008, 168.) SOAn tarkoituksena on tietojärjestelmien nykyistä parempi joustavuus muutosten tapahtuessa (kuva 7). Tavoitteena on myös, että palveluja pystytään uudelleen käyttämään. Palvelukomponentit ovat kaikkien järjestelmien käytössä. Tästä seuraa säästöjä ja palveluiden uudelleen käyttö tehostaa järjestelmien toteutustyötä. SOA-malli pyrkii

tarjoamaan myös alustariippumattomuuden. Palveluiden täytyy myös tarjota selkeä rajapinta ja riippuvuudet on minimoitava. (Hallanaro ym. 2006.) 16 KUVA 7. Jos yksi järjestelmä on pois käytöstä, vaikuttaa se kaikkiin muihinkin järjestelmiin SOA-mallissa ei järjestelmien välille rakenneta enää toiminto- ja tietokohtaisia liittymiä. Informaatio kulkee järjestelmien välillä palvelukohtaisina pyyntöinä. Mallissa prosessikeskeisyys on tärkeää. SOA-mallissa on palveluväylä, jossa ovat julkaistavat palvelut. Ne palvelevat liiketoimintaprosesseja ja ovat näin korkeammalla tasolla verrattuna perinteisiin tietojärjestelmäpalveluihin. SOA-mallissa tärkein muutos on se, että järjestelmäkeskeisyys on poistunut. Palvelut ovat kaikkien käytössä ja palveluita voivat kutsua jopa ulkoiset sidosryhmät. Web service (5.1.3) on yksi SOA-mallisen arkkitehtuurin työkaluista. (Hallanaro ym. 2006.) (Kuva 8.)

17 KUVA 8. SOA-mallin mukainen arkkitehtuuri Yhä useampi tuote tarjoaa helppoja tapoja integroitua Web Service teknologian avulla. Java-maailmassa Session Bean palvelukomponenteista voi rakentaa helposti Web Service palveluita. Microsoftin.Net-komponenteilla on jo olemassa luontainen kommunikaatiomenetelmä SOAP. Jopa Microsoftin Office-tuotteet tarjoavat Web Servicepalveluita. Liiketoimintoprosessien hallintaan ja mallintamiseen on myös olemassa paljon valmiita tuotteita, kuten esimerkiksi MS Biztalk Server. (Tieturi 2008, 170.) SOA-mallissa on myös heikkouksia. Tiettyyn pisteeseen asti keskitetty arkkitehtuuri on hyvä. Kaikkea informaatiota ei voida kuitenkaan siirtää yhden pisteen kautta. Nykyiset integraatioalustat ovat varsin vikasietoisia, mutta jos ratkaisu toimii tuotantoympäristössä ja keskitetty informaatiopiste vikaantuu voi organisaation arkkitehtuuri pahimmillaan lamaantua täysin. (Tähtinen 2005, 144.) 3.2.4 Sovelluksia yhdistävän liiketoimintologiikan rakentaminen (BPM) Yleensä prosessit tarvitsevat useita sovelluksia ja niiden automatisointi voi tapahtua sovellusrajat ylittäviä ratkaisuja rakentamalla. Vaihtoehtoja ratkaisulle on nykyisin

olemassa erilaisten asynkronisten prosessinohjausjärjestelmien avulla, jotka automatisoivat prosessienkulkua. 18 Alla on kuvattu hieman tarkemmin eri prosessinohjausjärjestelmiä. BPEL-prosessimoottori on prosessinkuvaus, jonka suorituksesta vastaa siihen hankittu tuote. Prosessimoottori perustuu liiketoimintaprosessien määrittämiseen tarkoitettuun BPEL-kieleen (Business Process Execution Language). Prosessit suoriutuvat lineaarisesti ja palveluita kutsutaan mallinnuksen avulla. (Leppänen 2006.) Sääntöpohjainen prosessinohjaus on looginen prosessi, jonka suoritus kuvataan sääntöjoukoksi. Näiden sääntöjen pohjalta käsitellään suoritettava palvelu. Tilakonepohjainen prosessiohjaus perustuu tapahtumien havainnointiin ja seurantaan. Kyseinen prosessinohjaus hyödyntää prosessien tilaa ja sen jälkeen kutsuu haluttua palvelua. Tiedon sisältöön pohjautuva prosessiohjaus tapahtuu olemassa olevan tiedon pohjalta. Tietorakenne on määritelty ennalta ja se sisältää myös tiedon siitä mitä palveluita pitää kutsua. (KOKO 2008.) 3.2.5 Business-To-Business integraatio (B2B) Joskus integraatioratkaisut saattavat ylittää organisaatiorajat. B2B-termi (Business-To- Business) tarkoittaa mitä tahansa organisaatioiden tai yritysten toimintaa, missä yritys myy tuotteitaan tai tarjoaa palveluitaan toisten organisaatioiden tai yritysten käyttöön. Yritysten ulkoiselle integraatiolle on kehitetty ohjelmistoja, jotka mahdollistavat tiedonvaihdon organisaatioiden tai yritysten välillä. Organisaatiot voivat esimerkiksi hoitaa prosessien integroimisen tai automatisoinnin internetin kautta. Riippuen yrityksen tai organisaation nykyisistä järjestelmistä, ne voivat liittyä toisiinsa erinäisten adaptereiden kautta. Yleensä tiedonvaihto perustuu eri xml-standardien käyttöön. Eri liittimet kuljettavat ohjelmistojen käskyt infrastruktuureiden läpi ja adapterit hoitavat sisällön organisaation sisäjärjestelmiin.

4 TIETOJÄRJESTELMÄARKKITEHTUURIT JA I TEGRAATIO 19 Tietojärjestelmän muodostavat ihmiset, tiedonkäsittelylaitteisto, tiedonsiirtolaitteisto sekä ohjelmisto. Tietojärjestelmäarkkitehtuuri kuvaa käytössä olevan tietojärjestelmän rakenneosat, niiden väliset suhteet sekä ominaisuudet. Arkkitehtuuria voidaan käyttää hyväksi suunnitellessa ja toteuttaessa uusia järjestelmiä. Alla kuvattuina eri tietojärjestelmäarkkitehtuurityyppejä ja miten niihin on mahdollista liittyä. 4.1 Keskuskonejärjestelmä Keskuskone-järjestelmässä tieto, sovelluslogiikka ja käyttöliittymämäärittelyt sijaitsevat yhdellä koneella. Järjestelmää voidaan käyttää pääteyhteyden avulla. Perinteisillä keskuskonejärjestelmillä on yleensä tarjota tuki sanomapohjaiselle viestinnälle. Keskuskonejärjestelmän muokkaaminen voi olla todella työlästä ja joissain tapauksissa jopa mahdotonta. Liittymät järjestelmään voidaan jopa joutua rakentamaan suoraan tietokantaan. Keskuskonejärjestelmiin pääsee käsiksi eri liityntöjen kautta, mutta joissain tapauksissa se vaatii liityntäpinnan rakentamista. (Tieturi 2008, 133.) (Kuva 9.) KUVA 9. Keskuskonejärjestelmiin voidaan liittää uusia järjestelmiä liitäntöjen kautta

4.2 Kaksitasoinen järjestelmä 20 Kaksitasoisessa järjestelmässä sovelluslogiikka ja käyttöliittymä muodostetaan työasemalla. Esimerkki tällaisesta on käyttöliittymäsovellus, joka toimii tietokannan kanssa. Tietokantaan liittyminen on helppoa, mutta ongelmana on tiedon eheyden varmistaminen. Kaksitasoisen osajärjestelmän kehittäminen kannattaa aloittaa siitä, että siirretään sovelluslogiikka erilliselle palvelimelle. Näin saadaan luotua uusi uudelleenkäytettävä liiketoimintologiikkakerros. (Nykänen 2003, 39 40.) 4.3 Monitasoinen järjestelmä Kaksitasoinen järjestelmä ei erota sovelluslogiikkaa käyttöliittymästä. Monitasoista järjestelmää voidaan pitää modernina, koska sovelluslogiikka sijaitsee erillisellä palvelimella. Tämä tarjoaa integraationäkökulmasta mahdollisuuden luoda uudelleenkäytettävän liiketoimintalogiikkakerroksen, jota voidaan käyttää muissakin järjestelmissä. (Kuva 10.) KUVA 10. Moderni järjestelmä pitää business-logiikan erossa muusta toiminnasta Moderni tietojärjestelmä on muuntautuvainen, helppo ylläpitää ja käytössä on useita välineitä. Tässä järjestelmätyypissä on huomioitu käyttäjien määrät sekä tyypit. Skaalautuvuus ja vikasietoisuus ovat myös modernin järjestelmän avaintekijöitä. Huonoja

puolia aiheuttavat korkeat kustannukset ja järjestelmän monimutkaisuus. (Nykänen 2003, 41.) 21 5 I TEGRAATIOTEK IIKAT JA -VÄLI EET Tietojärjestelmissä on kyse kommunikoinnista kahden tai useamman järjestelmän välillä. Tietojärjestelmien verkoston arvo voidaan laskea ns. Metcalfen lain avulla, jossa verkon arvo on suhteessa verkossa olevien päätepisteiden lukumäärän neliöön. (Tähtinen 2005, 22.) Mitä enemmän siis verkolla on käyttäjiä, sitä hyödyllisempi se on. Integraatioratkaisuissa palvelupyyntöjen sekä tiedon välittäminen järjestelmien välillä on keskeisessä roolissa. Tiedostomuotoisessa tiedonvälityksessä tietoa voidaan välittää esimerkiksi levykkeiden tai liitetiedostojen kautta. Tietoa voidaan myös hakea järjestelmän tietokannoista tietokanta-ajureiden ansiosta. Järjestelmien kommunikoinnissa palvelupyynnöt ja tieto voivat liikkua järjestelmien välillä myös etäkutsujen avulla. Järjestelmien kommunikointi voidaan jakaa synkroniseen ja asynkroniseen. Tätä jakoa voidaan kuvata tosielämän tilanteeksi esimerkiksi siten, että vertaillaan puhelua ja puhelinvastaajaa. Puhelu on synkroninen. Siinä toisen henkilön on oltava langan toisessa päässä, jotta informaatio menee perille. Puhelinvastaaja taas toimii asynkronisesti. Kenenkään ei tarvitse olla paikalla, kun viesti jätetään vastaajaan. Viestit tallennetaan puhelinvastaajassa jonoon, josta ne voidaan purkaa yksi kerrallaan. Seuraavassa on kuvattu tarkemmin eri integraatiotekniikoita. 5.1 Synkroninen kommunikaatio Synkronisessa, eli reaaliaikaisessa kommunikaatiossa järjestelmän tila tiedetään ajantasaisesti. Käyttäjät odottavat keskitettyjä resursseja, eli toisiaan. Kerralla siirretään yleensä vain vähän tietoa ja tiedonsiirto on kiireellistä. Osajärjestelmät puhaltavat yhteen hiileen koko ajan. Metatieto kysytään keskitetyltä resurssilta tai toiselta osajärjestelmältä lennossa. Reaaliaikaisuus on yleensä tavoiteltavaa, mutta joskus esimerkiksi järjestelmien vasteajat voivat muodostua kohtuuttomiksi. Järjestelmien vikasietoisuus

kärsii myös. Prosessit voivat jopa keskeytyä, koska palvelupyynnöt ovat niin hitaita. Reaaliaikaisuutta voi olla vaikea toteuttaa organisaatioiden välillä. (Lahti 2003, 7.) 22 Parhaimmillaan reaaliaikainen järjestelmä on yhden organisaation sisällä. Järjestelmän täytyy myös olla reaaliaikainen erilaisten kriittisten resurssien hallinnassa, esimerkiksi pankkitilien hallinnassa. Sovelluspalvelinkeskeisiin ratkaisuihin synkroninen kommunikaatio on myös sopiva. (Tieturi 2008, 106.) 5.1.1 Soketit Soketit ovat tehokas ja alustariippumaton kommunikointimalli matalalla tasolla. Parhaimmillaan se on, jos kommunikointiprotokolla täytyy itse suunnitella. Toteutus on työlästä, mutta soketit ovat tehokkaita ja optimoitavissa. Soketit vaativat säikeiden käyttöä, eivätkä ne näin sovellu kaikkiin ympäristöihin. Soketti-yhteys on tiedonsiirron kannalta tietovirta. Tietoa voi vain lukea, jos toinen osapuoli lähettää vastaavan tiedon. Soketit kulkevat yleensä pisteestä pisteeseen yli TCP/IP-verkon. (Tieturi 2008, 107.) 5.1.2 RMI, CORBA ja DCOM RMI (Remote Method Invocation) mahdollistaa Java-komponenttien väliset etäkutsut (kuva 11). Kutsut koostuvat rajapinnoista ja luokista. Rajapinnat esittelevät luokat ja luokkien palvelut ja luokat toteuttavat nämä palvelut. (Itäpelto-Hu ym., 4.)

23 KUVA 11. RMI mahdollistaa komponenttien väliset etäkutsut RMI koostuu tynkä eli stub- ja skeleton-kerroksesta, etäviittauskerroksesta ja kuljetuskerroksesta. Asiakas- ja palvelinohjelmat sijaitsevat sovelluskerroksessa. Rajapinta ja sen toteuttavat luokat sijaitsevat palvelinkerroksella. Palvelinohjelmalla on käytössään myös rajapinta. Stubit ja skeletonit ovat generoituja ja ne toteuttavat kaikki palvelimen luokat ja metodit. (Grosso 2001, 21.) CORBA (Common Object Request Broker Architecture) on IIOP-binääriprotokollaan pohjautuva etäkutsutekniikka. Se mahdollistaa etäkutsuja välittävän kommunikaatiokanavan luomisen kahden ORB-sovelluksen välille. (Kuva 12.) CORBA on perinteinen alustariippumaton arkkitehtuuri integraatioon. Erityisesti Java-maailmassa CORBA:lle on vahva tuki. ORB-rajapinnat kuvataan käyttämällä hyväksi IDLkuvauskieltä. (Mälkki & Haimakainen, 1.)

24 KUVA 12. CORBA-toteutus CORBA on vain OMG-spesifikaatio hajautetuille objekteille. Tämän takia CORBA on ohjelmariippumaton, mikä on sen suuri etu. CORBA rakentuu ORB-kerroksen (Object Request Broker) päälle. ORBn tehtävänä on olioiden hoitaminen verkon yli. Asiakas ohjelman päässä on tynkä, jonka avulla voimme kutsua muita olioita verkon yli käyttäen ORBtä. Toteutuspäässä on skeleton, jonka päälle voidaan tehdä oma toteutus oliolle. (Lahti 2005, 11.) DCOM (Distributed Component Object Model) on Microsoftin malli hajautettujen komponenttijärjestelmien toteutukseen. Perustana mallille on Microsoftin COMteknologia komponenttien väliseen vuorovaikutukseen. DCOM paketoi COM:n objektin siten, että paketin lähetys on mahdollista verkon yli. Objektien rajapinnat määritellään kuten CORBAssa, eli IDL-kielen avulla. DCOMn vahvuuksia ovat jaettu muistinhallinta objektien kesken, verkkoliikenteen piilotus, voidaan tuhota ja luoda objekteja tarvittaessa ja monipuoliset virhe- ja tilaviestit sovelluskehittäjille. (Lahti 2003, 12.)

5.1.3 Web Service ja SOAP 25 Web Service on rakennettu xml-standardien varaan. SOAP (Simple Object Access Protocol) on kaiken Web Service-tiedonvaihdon pohjana. Web Service teknologiat ovat lyöneet itsensä läpi modernissa tietojenvaihdossa lähimpien vuosien aikana. Tekniikan edut ovat alustariippumattomuus ja yksinkertainen tekniikka. Informaatio liikkuu paikasta toiseen tekstimuodossa. SOAP toimii sanoman kehyksenä, eli kirjekuorena. (Tieturi 2008b, 49.) Web Service tekniikka rakentuu xml:n käyttöön. Operaatiokutsut paketoidaan xmlviesteiksi, joita lähetetään yleensä http:llä tai smpt:llä. Paluutiedot palautuvat myös xml-muodossa. SOAP (Simple Object Access Protocol) on W3C:n standardoima protokolla. SOAP määrittelee viestin perusmuodon ja se ei ota kantaa kieleen, käyttöjärjestelmään eikä ympäristöön. WSDL eli Web Service Description Language määrittelee standardoidusti xml-pohjaisen web-palvelun. WSDL kertoo mitä palveluita on tarjolla ja miten niitä on mahdollista kutsua. UDDI (Universal Description, Discovery Language) kuvailee yritystä ja niiden toimintoja. UDDI-rekisteri on palveluhakemisto, josta voi hakea automaattisesti eri palveluita. Palvelu liitetään UDDIin WSDL-kuvauksella. (Chappell & Jewell 2002, 7 8.) (Kuva 13.) KUVA 13. Web Service-teknologia

26 Organisaatioiden välinen kommunikointi on helppoa Web Service-tekniikoiden avulla. Internetiin julkaistaan palveluita ja organisaatiot pääsevät niihin käsiksi avoimilla XML- ja SOAP-protokolilla. Käytännössä nämä palvelut ovat yksittäisiä metodeja. Web Service-teknologian vahvuutena on palveluiden tarjoaminen ulospäin alustariippumattomasti ja tekniikan kehitykseen uskotaan niin Java- kuin Microsoftmaailmassa. Web Service-tekniikan kanssa toimitaan julkisen Internetin yli ja palveluiden tietoturvakysymykset ovat keskeisiä. Web Service määrittelee vain siirtotavat ja siirtokanavan. Riskinä tulevaisuudessa on uusien standardiehdotusten myötä, että XML- ja Web Service-tekniikat monimutkaistuvat, vaikka alkujaan yksinkertaisuus oli syy siihen, miksi niitä alettiin käyttää. (Tieturi 2008, 113.) Uudet standardiehdotukset koskevat mm. tietoturvaa, transaktioita, reititystä ja luotettavuuden takaamista. Web Servicen heikkous osaltaan onkin, että ei ole yhtä jättimäistä spesifikaatiota, vaan se rakentuu yksittäisten moduulien varaan. Standardeja luovat mm. isot ohjelmistotalot kuten IBM ja Microsoft. Useat uudet standardit perustuvat SOAP header -tiedon käyttöön. Headerissa voidaan siirtää datan ulkopuolista tietoa. (Kuva 14) WS-I eli Web Service Interoperability määrittelee profiileja, joita pyritään toteuttamaan. WS-I kertoo esimerkiksi mitä xml-standardeista käytetään. (Web Service Interoperability Organization 2008.) KUVA 14. Esimerkki SOAP-kirjekuoresta ja sen sisällöstä

5.1.4 Sovellustason liittymät 27 Käytettävissä olevat taustajärjestelmät saattavat olla erityyppisiä. Käytössä saattaa olla eri tekniikoita ja eri valmistajien tuotteita. JCA (Java Connector API) on korkean tason protokolla. Tekniikka mahdollistaa erityyppisten taustajärjestelmien, kuten esimerkiksi SAPIN toiminnanohjausjärjestelmän ja CICSIN transaktiojärjestelmän käsittelemisen standardi API:n avulla. Malli ei pakota tuntemaan taustajärjestelmien rakennetta. Malli vaatii, että käytössä on resurssiadapteri, joka kommunikoi taustajärjestelmien kanssa. JCA on helppo ja tehokas tapa integroitua järjestelmään, jos valmis ajuri on saatavilla. Ajurin voi myös tehdä itse. (Tieturi 2008, 124.) DECS (Domino Enterprise Connection Services) on synkroninen kutsutekniikka, joka paljastaa NOTES-palvelimen oliomallin käyttäen CORBAa hyväkseen. DECS on käytössä hieman hidas toiminnoiltaan. 5.1.5 Liitynnät mainframe-järjestelmiin Suurtietokonemaailmassa tieto, sovelluslogiikka ja käyttöliittymämäärittelyt sijaitsevat yhdellä koneella. Järjestelmää voidaan hyödyntää pääteyhteydellä. Itse järjestelmän muokkaaminen voi tuottaa suuria vaikeuksia, ja se voi olla osin jopa mahdotonta. Jos halutaan rakentaa liittymä, niin se voidaan joutua rakentamaan suoraan tietokantaan. Voidaan myös tehdä CORBA-liityntä. Perinteiset keskuskone-järjestelmät tarjoavat yleensä tuen sanomapohjaiselle viestinnälle. (Tieturi 2008, 107.) APPC (Advanced Program-to-Program Communications) on perinteinen ja ehkä hieman työläskin protokolla mainframe-integraatioon. Kyseessä on matalan tason protokolla, ja se vaatii protokollan rakentamisen. APPC käy hyvin palvelupyyntöjen käyttöön, kun tietomäärät ovat pieniä. (Tieturi 2008, 107.) 5.2 Asynkroninen kommunikaatio Asynkroninen tiedonvaihto on sanomapohjaista. Järjestelmät ovat itsenäisiä ja tietoon ei odoteta vastausta heti. Sanomapohjaisessa kommunikaatiossa siirretään yleensä kerralla paljon tietoa. Tiedon mukana siirretään paljon turhaa metatietoa. Sanomapoh-

28 jainen ratkaisu on hyödyllinen organisaatioiden väliseen tiedonvaihtoon. Sanomapohjaisuus lisää toiminnan joustavuutta ja suorituskykyä ja tämän takia yhteistyökitka pienenee. Yksinkertaisimmillaan asynkroninen kommunikaatio esimerkiksi on silloin, kun tehdään xml-tiedosto kovalevylle. Viestin rakenne kuvataan xml-skeemana. Yksi sovellus tuottaa tiedostoja ja toinen lukee niitä. (Kuva 15.) KUVA 15. Asynkroninen kommunikaatio yksinkertaisemmillaan JMS (Java Message Service) on Sunin sanomapohjainen viestinvälitysratkaisu, jonka avulla J2EE-komponentit voivat lähettää ja vastaanottaa synkronisia sanomia. Sanomapohjaiset Beansit voivat säilöä asynkronisia sanomia. Palvelimen objekteja on mahdollista tutkia JNDIn (Java Naming and Directory Interface) avulla. JMS tukee point-to-point-viestinvälitystapaa ja publish-descripe tapaa. (Lahti 2005, 19.) Sanomanvälittäjien (Message Broker) avulla voidaan välittää tietoa useiden sovellusten välillä. Paras puoli sanomanvälittäjissä on alustariippumattomuus. Sanomanvälittäjien ominaisuuksiin kuuluvat konversiot, älykäs reititys ja sääntökone mahdollisuus. (Lahti 2005, 20.) 5.3 Tietokantojen kommunikaatio Tietokantojen kommunikaatio sovelluksen tai toisen kannan kanssa on mahdollista erilaisten standardoitujen komentorajapintojen kautta. Tällaisia komentorajapintoja

29 ovat mm. JDBC, ODBC ja OLE DB. Sovellukset tai tietokannat voivat myös keskustella toistensa kanssa eri valmistajien valmiiden väliohjelmistojen avulla. Valmistuotteiden huono puoli on se, että ne toimivat yleensä vain valmistajan omissa tietokannoissa ja tuki muille kannoille on yleensä huono. (Lahti 2005, 14.) 5.4 Xml Xml (extensible Markup Language) on World Wide Web Consoriumin (W3C) suositus jakaa tietoa tietoverkossa. Xml on metakieli, eikä sitä käytetä sellaisenaan mihinkään, vaan sillä määritellään omia käyttökelpoisia kuvauskieliä. Xml on tekstipohjainen ja rakenteinen kuvauskieli. Sen kuvaa tiedon sisältöä, eikä se puutu mitenkään tiedon ulkoasuun. Xml:n edut tulevat siitä, koska se on ympäristö- ja alustariippumaton. Xml-kielellä voidaan rakentaa integraatiossa tarvittavia xmldokumenttiformaatteja joustavasti Javalla. Tiedonvaihto tapana se on hyvä, koska se on neutraali ja yksinkertainen tapa. Xml-dokumenttejen rakenteiden määrittely on mahdollista dtd:n tai xml-schemojen avulla. DTD:ssä (Document Type Definition) määritellään elementtien ja atribuuttien järjestys. DTD ei mahdollista elementtien sisällön määrittämistä. Xml-schema on alkanut korvata DTD-määrittelyä. Schemoissa kuvataan elementtien ja atribuuttien rakenne. (Zimmermann ym. 2003, 37.) 6 I TEGRAATIO- JA MIDDLEWARE-TUOTTEET Integraatioratkaisua mietittäessä, organisaatio tai yritys voi turvautua valmistuotteisiin. Markkinoilla on tarjolla yksittäisien ominaisuuksien kuten sanoman välitys-, sanoman muunnos- ja konversiotuotteita. Osa toimittajista tarjoaa myös kaikki nämä tuotteet yhdessä paketissa. Pakettien etuna on se, että järjestelmien yhdistäminen käy helposti konnektoreiden ja adaptereiden kanssa. Integraatiotuotteita tarjoavat suurina toimittajina mm. IBM, Microsoft ja BEA. Yrityksessä saattaa olla otettu käyttöön jossain vaiheessa jonkun suuren valmistajan tuotteita ja sen jälkeen onkin suuri houkutus ottaa saman valmistajan integraatiotuotteet käyttöön. (Tähtinen 2005, 149 150.)

30 Valmistuotteen toimittajaa kannattaa aina harkita. Organisaation täytyy miettiä, onko tarjottava teknologia tarpeeksi kypsä toimiakseen organisaation tai yrityksen järjestelmissä. Ratkaisua täytyy myös pystyä täydentämään jopa toisen valmistajan tarjoamalla tuotteella ja se ei saa tuottaa ongelmia yhdistämisessä. Tuotteen toimittajalla pitää myös olla selkeä näkemys siitä, minkälaista tekniikkaa on tarjolla tulevaisuudessa. Tarjolla täytyy myös olla osaamista, koulutusta ja virheiden ratkaisukykyä kun hankitaan valmistuotteita. (Tähtinen 2005, 150.) Middleware- eli väliohjelmistot ovat tuotteita, jotka ovat käyttäjien ja tietolähteiden välissä. Ne välittävät viestejä sovellukselta toiselle ja ne liittävät järjestelmät toisiinsa. Väliohjelmistot ovat tärkeässä roolissa integraatioratkaisuissa. Väliohjelmistot myös osaltaan yksinkertaistavat järjestelmäarkkitehtuuria organisaatiossa. Niillä voi esimerkiksi piilottaa käyttöjärjestelmän tai verkkoteknologian sovelluskehittäjältä. Sovellukset liittyvät väliohjelmistoihin eri rajapintojen kautta. (Lahti 2006, 5.) Alla tarkemmin kuvattuina eri väli- ja integraatiotuotteta. 6.1 Tietovarastojen integroimisvälineet ETL-tuotteiden (Extract, Transform and Load) ideana on tarjota mahdollisuus siirtää dataa tietovarastojen välillä. Tuotteet tarjoavat valmiiksi konfiguroitavia sovelluksia tiedon siirtämiseen. Kyseiset tuotteet tarjoavat usein myös mahdollisuuden tiedostopohjaisten informaatioiden hallintaan. Tietokonversiot ovat myös mahdollisia, jos kohde tietovarasto sitä vaatii. (Tieturi 2008, 168.) 6.2 Enterprise Service Bus (ESB) ja palvelurekisterit Enterprise Service Bus (ESB) on kokoelma teknologioita, joiden avulla SOA-mallin mukainen palvelukohtainen sanomanvälitys voidaan toteuttaa. ESB-tuotteita voidaankin kutsua palveluväyliksi. ESB:n avulla voivat eri tekniikoilla tehdyt järjestelmät kommunikoida toistensa kanssa laitteisto- ja ohjelmistoriippumattomasti. Tyypillisesti sanomat ovat xml-pohjaisia. (Tähtinen 2005, 146.)

31 Palveluväylien ominaisuuksiin kuuluvat viestien muunnokset sekä älykäs reititys. Viestien validointi sekä autentikointi onnistuu myös kyseisillä tuotteilla. ESB-tuotteet tarjoavat tuen löyhälle kytkeytyvyydelle ja siksi niiden käyttö voi olla hyvä ratkaisu, kun halutaan liittää yrityksen järjestelmiä toisiinsa palvelupohjaiseen arkkitehtuuriin. Tuotteita tarjoavat yritykset ovat eri mieltä mitä palveluväylä-tuotteilla halutaan tarkoittaa. Esimerkiksi Microsoftin mukaan kyseinen tuotekategoria on turha (Microsoft 2005). Erillään palveluväylätuotteista ovat palvelurekisterituotteet. SOA-arkkitehtuurin palveluiden hallinta ja jakaminen on avainroolissa. Palvelurekisterit tarjoavat monipuolisia hallinnointimahdollisuuksia. Tuotteita on paljon erilaisia ja niitä on joskus integroitu muihin tuotteisiin. Tuotteet tarjoavat tuen palveluiden hallintaan ja ryhmittelyyn. Palvelutiedoille on myös hallinta- ja etsintätyökalut. (Tieturi 2005, 166.) 6.3 Muita integraatiotuotteita Yllä mainittujen integraatiotuotteiden lisäksi on olemassa myös portaalituotteita, jotka antavat näkymiä prosesseihin. Portaaleita voidaan rakentaa itse, mutta markkinoilla on myös paljon valmiita portaalituotteita. Ongelmaksi on muodostunut se, että portaalituotteiden raja on häilyvä ja eri valmistajat sisällyttävät tuotteisiinsa eri piirteitä. (Tieturi 2008, 190.) B2B Gateway-ohjelmistot tarjoavat keskitettyjä integraatiorajapintoja yhteistyökumppaneille. Ohjelmistot ovat tyypillisesti ESB-tuotteiden kaltaisia palvelualustoja, joissa onnistuu profiilien luominen sekä hallinta, prosessien hallinta, palvelurekisteri ja adaptereita taustajärjestelmiin liittymiseksi. Tälläisiä tuotteita ovat mm. Oraclen Integration B2B, IBMn Paartner Gateway ja BizTalk Server. (Tieturi 2008, 201.) Reaaliaikaisen datan hankkiminen organisaatiosta on yksi integraation tarkoituksista. Tätä varten on valmistuotteita myös raportointiin. Tuotantoympäristössä on myös tärkeää seurata kuinka ratkaisut toimivat. Ongelmien huomaaminen ajoissa on hyvin merkittävää järjestelmien kannalta. Valmiita monitoroimisvälineitä tarjoavat mm. Oracle ja IBM. Organisaatioissa voi olla myös tarvetta esimerkiksi luoda perinteisestä palvelusta Web Service. Tämän kaltaisia tilanteita varten on myös olemassa valmis-

tuotteita. Esimerkiksi Crossvision Legacy Integrator ja Novell extend. (Tieturi 2008, 203.) 32 Nykyisin on myös olemassa valmiita integraatioalustoja, jotka antavat samassa paketissa tarvittavat ympäristöt sekä niiden kehitysvälineet. Kokonaan ei pidä myöskään unohtaa avoimenlähdekoodin tuotteita, jotka tarjoavat samoja ominaisuuksia kuin edellä mainitut tuotteet. Avoimen lähdekoodin tuotteet kilpailevat ominaisuuksillaan lähellä kaupallisia tuotteita. 7 EESSI-ARKKITEHTUURI Ihmisten liikkuvuus on lisääntynyt Euroopan unionin jäsenmaiden kesken. Maat vaihtavat sosiaaliturvaa koskevia tietoja keskenään käyttämällä paperisia lomakkeita (liite 1). Vuosittain lomakkeita lähetetään maiden kesken n. 8.5 miljoonaa kappaletta. (Taulukko 1.) Euroopan komissio on antanut asetuksen 883/04, mikä velvoittaa Euroopan unionin jäsenmaat siirtymään sähköiseen tiedonvaihtoon koskien etuusliikennettä toimivaltaisten laitosten kesken. Tällä pyritään turvaamaan sosiaaliturvan saatavuus ja kattavuus missä tahansa Euroopan alueella. EESSI-projekti tulee tarjoamaan jäsenmaille tavan siirtää turvallisesti dataa sähköisesti. EESSI tarjoaa liikkuville jäsenmaiden kansalaisille palvelun, joka helpottaa ja nopeuttaa etuuksiin liittyvää päätöksentekoprosessia, kun henkilö on toisessa maassa. (Asetus 883/4 2004) TAULUKKO 1. ykyinen lomakkeiden vaihto maiden välillä (EUROPEA COMISSIO 2008b) Kansaneläkelaitos hoitaa Suomessa ja ulkomailla asuvien suomalaisten sosiaaliturvaa. Kelan toiminta perustuu lainsäädäntöön. EESSI-projektissa on Suomesta mukana

33 myös muita laitoksia, jotka ovat tekemisissä sosiaaliturvan kanssa. Suomesta mukana ovat Eläketurvakeskus, työeläkeyhtiöt, työttömyyskassat, työvoimatoimistot, tapaturmavakuutuslaitokset ja terveydenhuollon palveluntarjoajat. EESSI-projektissa Suomessa on tärkeää olla toimialan tuntemusta. Projektissa täytyy olla tuntemusta etuuksista ja niitä koskevasta lainsäädännöstä. Kansaneläkelaitoksella hanke tulee olemaan organisaation sisäisten järjestelmien integroimista osaksi EESSI-arkkitehtuuria ja lisäksi integrointia tulee tapahtumaan yhteistyökumppaneiden ulkoisiin järjestelmiin. Liikenne tulee kulkemaan Kelan järjestelmien kautta. Sähköinen liikenne tulee olemaan sanomapohjaista tietojenvaihtoa maiden kesken, mutta myös reaaliaikainen liikenne on mahdollista. EESSI-arkkitehtuuri koostuu kansallisesta ja kansainvälisestä osuudesta. Tietojenvaihto tulee pohjautumaan olemassa olevan Euroopan unionin komission koordinoiman stesta-verkon käyttöön. Tiedot, jota vaihdetaan, ovat standardoituja sähköisiä xmlsanomia. Kaikki sanomat tulevat kulkemaan Euroopan Komission data keskuksessa sijaitsevan keskussolmun (Central Node) kautta, jossa sijaitsevat keskitetyt hakemistopalvelut. Jokaisella jäsenmaalla tulee olemaan yhteyspisteitä (Access Points), joiden kautta maat vaihtavat informaatiota. Yhteyspisteet jakaantuvat kansainväliseen ja kansalliseen osuuteen. (Kuva 16)

34 KUVA 16. Arkkitehtuuri jakaantuu kansainväliseen ja kansalliseen osuuteen EESSI-arkkitehtuurin rahoittaa Euroopan unionin komissio. Komissio on käynnistänyt tarjouskilpailun, jonka perusteella valitaan se, kuka toimittaa EESSIn kansainvälisen osuuden palvelut. Jäsenmaat rakentavat kansallisen osuuden itse. Suomessa kaikki tietoliikenne tulee kulkemaan Kansaneläkelaitoksen järjestelmien kautta, josta ne ohjataan eteenpäin oikealle sektorille ja laitokseen. Suomessa Access Pointin kansallisen osuuden rakentamisesta vastaa Kansaneläkelaitos. Suomessa laitokset ovat käyneet sähköistä tiedonvaihtoa muutamien laitosten osalta. Ongelmia tulee, koska käytössä on erilaisia järjestelmiä sekä tekniikoita ja niiden sulauttaminen osaksi EESSIarkkitehtuuria on hankalaa. Niitä laitoksia varten, ketkä eivät kykene integroitumaan osaksi EESSI-arkkitehtuuria toteutetaan web-käyttöliittymä. Tällä hetkellä sosiaaliturvasektorilla on EU-tasolla vaihdettu tietoja EDIFACTsanomaliikenteen avulla(3.1.2 Integrointi ulkoisiin järjestelmiin), käyttäen hyväksi X400-protokollaa. (Nieminen 2006, 13.) Kansaneläkelaitoksesta on kahdenkeskinen suojattu sähköpostiyhteys Ruotsin ja Viron sosiaalivakuutuslaitoksiin. Viron yhteydet toimivat EU:n koordinoiman Testa-verkon kautta ftp-tekniikalla ja Ruotsin yhteydet

35 on toteutettu VPN-tekniikalla. Lisäksi Suomella on ollut vuodesta 2005 käytössä selainsovelluksiin perustuva YW-systeemi, jolla EU-mailta laskutetaan maksetut sairaanhoitokorvaukset. YW-systeemi on käytössä sähköisesti vain Viron kanssa, jossa xml-lomakkeet hoidetaan FTP-eräsiirtoina maasta toiseen. (Hyppönen 2008.) 7.1 Kansainvälinen osuus EESSIstä EESSI rakentuu monesta eri palasesta. Euroopan unionin komissio on käynnistänyt tarjouskilpailun, jossa valitaan toimittaja kansainväliseen osuuteen. Euroopan unionissa on huomioitu, että tällaisen projektin kustannukset saattaisivat kasvaa hyvinkin suuriksi. Komissio onkin todennut tarjouspyynnössään, että käytettäisiin olemassa olevaa suljettua stesta-verkkoa ja järjestelmä koostuisi paljolti vapaan lähdekoodin tuotteista. Ensimmäisessä vaiheessa projektia komission on tarkoitus valita kuusi jäsenmaata testaamaan arkkitehtuuria pilottiin. Tähän pilottiin on ilmoittautunut alustavasti halukkaaksi Suomen lisäksi Itävalta, Bulgaria, Tsekki, Saksa, Unkari, Alankomaat, Italia, Slovakia, Slovenia ja mahdollisesti Kreikka. (Hyppönen 2008) Pilotissa valitut jäsenmaat integroivat EESSI:n osaksi tietojenvaihtojärjestelmää ja pyrkivät lähettämään testisanomia toisilleen. Reititys Suomessa toimivaltaisten laitosten kesken testataan myös. Pilottimaat testaavat myös web-käyttöliittymän toiminnan. Pilotin päätyttyä loput jäsenmaat tulevat mukaan. Mukaan tulevat maat ovat niitä maita, jotka kuuluvat Euroopan unionin lainsäädännön piiriin. Lisäksi mukaan tulee mahdollisesti Euroopan talousalueeseen (ETA) kuuluvia maita. Tarjouskilpailun voittaneen toimittajan on määrä suunnitella ja rakentaa kansainvälinen osuus EESSI:stä. Toimittajan on tarkoitus rakentaa järjestelmäkokonaisuus, joka tarjoaa päähakemiston, välittää sanomia maiden yhteyspisteiden välillä ja tarjoaa xmlskeeman sanomille. Tätä sovellusta kutsutaan Coordination nodeksi (ks. luku 7.1.1). Yhteyspisteet jakaantuvat myös kansallisiin ja kansainvälisiin osuuksiin. Toimittaja rakentaa kansainvälisen osan Access Pointista, joka asennetaan jäsenmaahan. Kansainväliseen osuuteen kuuluu tarvittavien palvelinten perustaminen, kansainvälisen

sovelluksen asentaminen palvelimille ja käyttöliittymän asentaminen osaksi järjestelmää. 36 7.1.1 Coordination node Coordination node on solmupiste ja se sijaitsee EESSIn kansainvälisessä osuudessa ja tarjoaa sovelluksen, jolla on kolme päätarkoitusta. Coordination node tarjoaa päähakemiston (master directory), jossa tiedonvaihtojen sähköiset osoitteet ovat. Se säilöö sanoman ja välittää sanomat molempiin suuntiin eri maiden Access Pointeille. Coordination node tarjoaa myös sanomille xml-skeeman, jolla voidaan kuvata käytettävien xml-dokumenttien rakenne. Coordination nodella on rooli toimia ns. keskittimenä Access Pointtien välillä. Se toimii myös yhdyskäytävänä ja tarjoaa valvonta- ja lokityökalut. Coordination noden hallintaan tulee oma sovellus, jonka kautta on mahdollisuus pienellä käyttäjäkunnalla muokata päähakemistoa. Sovellukseen ei ole pääsyä julkisesta Internetistä, koska sovellus sijaitsee suljetussa verkossa (stesta). 7.1.2 Hakemistopalvelut Master Directory eli päähakemisto on virallinen säilö, jossa on lista toimivaltaisista laitoksista, niiden osoitteista ja laitosten toimivallasta. Laitosten toimivalta määrittelee sen, mitä etuusasioita kyseinen laitos käsittelee. Se sisältää mm. tietoa toiminnoista, eduista, reititystiedoista ja toimivaltaisten laitosten osoitteista, jotta sanomat voidaan ohjata oikeaan paikkaan. EESSIn hakemistopalvelut tulevat tarjoamaan kolmenlaista informaatiota. Reititys informaatio tarjoaa toimivaltaisten laitosten tarvittavat tiedot, jotta sanomat reitittyvät oikeisiin paikkoihin. Tietoturvainformaatio tarjoaa sertifikaatit ja avaimet, jotta palvelun käyttö olisi luotettavaa ja turvallista. Hakemistopalvelut tarjoavat myös tiedon käyttöoikeuksista, jotta oikeat ihmiset pystyvät muokkaamaan ja päivittämään hakemistopalvelua.

37 Saattaa käydä niin, että sanomat joutuvat väärään paikkaan tai niiden lopullista päämäärää ei saa selville. Manuaalinen käsittely on silloin mahdollista. Jotta lista laitoksista ja niiden osoitteista olisi saatavilla tavallisilla laitosvirkailijoilla, on päätetty, että Master Directory tulee kopioitumaan jokaiseen yhteyspisteeseen ja komission ylläpitämään keskitettyyn tietovarastoon. (Kuva 17.) Suomi on tehnyt komissiolle Kansaneläkelaitoksen aloitteesta ehdotuksen, että päähakemiston kopio voitaisiin sijoittaa yhteyspisteen kansalliseen osuuteen, joka lisäisi tietoturvaa arkkitehtuurissa. KUVA 17. Master Directory kopioituu jokaiseen Access Pointtiin (EUROPEA COMISSIO 2008a) Mukana tulee olemaan iso määrä eri maiden laitoksia, joten sanomalla pitää olla osoite, jotta se saavuttaa määränpään. Osoite tullaan mahdollisesti jakamaan hierarkkiseen neljän tason malliin, jonka järjestys on maa, laitos, alueellinen toimisto, ylimääräinen osoitetieto.

7.1.3 Kansainvälinen runkoverkko stesta 38 STesta-verkko (secured Trans European Services for Telematics between Administrations) on EU-jäsenmaiden yhteinen tiedonsiirtoverkko, jolla on erillisiä palvelimia eri sektoreita varten. Belgiassa sijaitsevilla palvelimilla ovat maakohtaiset tiedostohakemistot, joihin tiedostot siirretään kansallisen reitityspisteen kautta. Suomessa reitityspiste sijaitsee Valtioneuvoston tietohallintoyksikössä. Eri maiden yhteyspisteet eivät voi tietoturvallisuussyistä olla toistensa kanssa suorassa yhteydessä esimerkiksi julkisen Internetin ylitse. Maiden välissä on suojattu yksityinen stesta-verkko. Verkkoon ei pääse käsiksi julkisen Internetin kautta. Hyviä puolia stestassa on, että turvallisuus jo valmiiksi taattu ja verkkoa ei tarvitse EESSIÄ varten uudelleen rakentaa. Tähän mennessä stestaa on käytetty Suomessa eräsiirtoihin mm. sairaanhoitolaskutuksessa Viron kanssa. 7.2 Kansallinen osuus EESSIstä Kansaneläkelaitos tulee tarjoamaan paikan yhteyspisteelle. Kaikki sanomat ja kyselyt tulevat menemään Kelan tarjoamien palveluiden kautta Kelan omiin etuusjärjestelmiin tai ulkoiselle yhteistyökumppanille. Kansalliseen osuuteen kuuluu yhteyspisteen kansallinen osa ja yhteydet muihin sosiaaliturvaan liittyviin sektoreihin. Yhteistyökumppanit on kuvattu tarkemmin alla. (Kuva 18.) Eläketurvakeskus, joka hoitaa yhdessä Kansaneläkelaitoksen kanssa eläketurvaan liittyviä asioita. Työvoimahallinto, joka vastaa työvoimatoimistojen järjestelmistä ja tietoliikenteestä. Työvoimahallinnosta voidaan saada esimerkiksi työvoimapoliittinen lausunto. Työttömyyskassat, jotka toimivat henkilöiden työasioiden kanssa. Kassoja on Suomessa noin 50 kappaletta. Ohjelmistot näille kassoille tarjoavat kolme eri yritystä, DIGIA, LOGICA ja YAP. Tapaturmavakuutusliitto, joka hoitaa vakuutusasioita ja koordinoi vakuutusten toimeenpanoa

39 KUVA 18. EESSI-arkkitehtuurin toimijat Suomessa Kansaneläkelaitos reitittää sanoman oikealle sektorille. Sektoreiden täytyy hoitaa reititys esimerkiksi siihen laitokseen, jolle tapaus kuuluu. Kela on keskeinen toimija viestinvälityksessä, joten arkkitehtuurin täytyy olla linjassa Kelassa tehtyihin arkkitehtuuriratkaisuihin. Kelan kokonaisarkkitehtuuri (KARKKI) on tehnyt linjauksia liittyen Kelan arkkitehtuuriin. Esimerkiksi KARKKI on rajannut, että sisäiset uudet ja uudistettavat järjestelmät toteutetaan SOA-arkkitehtuurin mukaisesti ja tiedonsiirtoon Kelan ulkopuolelle käytetään xml-muotoa, joko sanomina tai eräsiirtoina. (KARKKI 2008.) Tähän mennessä Kansaneläkelaitoksella on ollut yhteyksiä eri yhteistyökumppaneihin. Työttömyyskassoihin on ollut FTP-liikennettä VPN-yhteyksillä. Kansaneläkelaitos kuitenkin pyrkii VPN-yhteyksistä siirtymään turvallisempiin SSL- tai TLS-yhteyksiin yhteistyökumppaneiden kanssa. Eläketurvakeskuksen ja tapaturmavakuutuslaitosten kanssa on vaihdettu tietoa myös FTP-liikenteen avulla, jossa välittäjänä on toiminut IBM. Eläketurvakeskuksen ja Kansaneläkelaitoksen kesken on myös APPC-rajapinta, jonka kautta laitokset ovat vaihtaneet eri etuustietoja keskenään. Suomen sisällä tulee tapahtumaan Kansaneläkelaitoksen kannalta kolmenlaista sanomaliikennettä, riippuen siitä mitä asiaa sanoma koskee. Sanomia tulee pelkästään Ke-

laan, ulkoiselle sidosryhmälle tai sanoma voi myös koskea Kansaneläkelaitosta ja ulkoista sidosryhmää, joten se tulee molemmille. 40 7.2.1 LUOVA Kelan tietojen luovutus- ja vastaanottopalvelu (LUOVA) tulee tarjoamaan Kelassa ulkoisen viestinvälityksen. Integraatioarkkitehtuuri muodostuu kahdesta viestinvälityskeskuksesta, sisäisestä ja ulkoisesta viestinvälityksestä. Ulkopuolinen viestinvälitys hoitaa liikennettä ulkoisten sidosryhmien ja Kansaneläkelaitoksen välillä. Sisäinen viestinvälitys huolehtii liikenteestä Kelan omien järjestelmien välillä. Suoria yhteyksiä ei järjestelmien välillä ole, eikä tietoa siirretä tietokantatasolla järjestelmästä toiseen. (LUOVA 2008.) (Kuva 19.) KUVA 19. Kelan kokonaisarkkitehtuuri kuvaus (TukiWiki 2008) Viestinvälitys tullaan toteuttamaan eri tuotteiden avulla. Kelassa on pitkä historia IBM-tuotteiden kanssa. Viestinvälitystuotteeksi esiselvitysten jälkeen on hankittu

IBMn Websphere Enterprise Service Bus ohjelmistot, sekä IBMn FlatFile-adapteri tiedostonkäsittelyä varten. Lisäadaptereiden hankinta on mahdollista, mikäli niille tulee tarvetta. LUOVA tulee myös tarjoamaan myös esimerkiksi viestinvälitykseen tarvittavia palveluja ulkoisten sidosryhmien käyttöön. 41 7.2.2 Reititys Kelan omiin etuuksiin Sanomat, jotka koskevat vain Kelaa, liittyvät perhe-etuuksiin. Niitä koskevat sanomat tulevat vain Kansaneläkelaitokselle. Reititys tulee tapahtumaan LUOVAN kautta Kelan etuusjärjestelmiin. Sanoman lähtiessä toisesta jäsenmaasta, se siirtyy ensimmäiseksi maan omaan Access Pointtiin, jossa esimerkiksi tehdään tarvittavat konversiot. Konversiot ovat tarpeellisia, koska esimerkiksi suurissa Euroopan maissa kuten Saksassa ja Ranskassa on käytössä MTF-formaatti, joka ei sovellu Suomen ympäristöön. Yhteyspisteestä se siirtyy stesta-verkon sisällä olevaan Coordination nodeen, jossa tiedonvaihdon osoitteet ovat. Coordination node liittää sanomaan xml-skeeman ja reitittää sen eteenpäin. Sanoma saapuu Suomen Access Pointtiin kansainväliseen sovellukseen (Reference Implementation). Sovelluksessa tehdään sanomalle tarvittavat muutokset ja se säilötään. Access Pointin kansainvälisestä osiosta se siirtyy Kelan LUOVA-viestinvälitykseen. Viestinvälitys tarkistaa sanomakehyksen ja tarkastaa onko sanomalla määränpää. Jos sanomakehyksessä on jotain vikaa, tai osoite puuttuu kokonaan, siirtyy se manuaalisesti käsiteltäviin sanomiin. Sanoman käsittelee joku Kelan virkailija ja antaa sille määränpään tai siirtää sen Kelan etuustöiden hallintajärjestelmään (OIWA), jossa sen kirjaa Kelan järjestelmiin käsin joku toinen virkailija. Jos sanoma on kunnossa, siirtyy se automaattisesti LUOVAN saapuvien sanomajonosta tietovarastoon ja Kelan omia etuuksia varten perustettavaan tietokantaan. Kelan etuusjärjestelmät hakevat automaattisesti kannasta sanoman. (Kuva 20.)

42 KUVA 20. Yhteys Kelan etuuksiin tapahtuu LUOVA viestinvälityksen kautta 7.2.3 Reititys muiden toimijoiden etuuksiin Sanomat, jotka koskevat esimerkiksi tapaturma-asioita eivät tule Kelaan. Sanoma lähtee jäsenmaasta sen oman Access Pointin kautta stesta-verkkoon, jossa sanoma kulkee Coordination nodeen, missä sanoma reititetään Suomen Access Pointtiin Reference Implementationin sanomavarastoon. Sanoma reititetään sieltä Kansaneläkelaitoksen LUOVA-viestinvälityskeskukseen, jossa tapahtuu sanomien validointiin ja konversioihin liittyviä toimenpiteitä. LUOVA tallentaa palvelun avulla sanoman tietovarastoon saapuviin sanomiin. LUOVA tekee konversion sanomalle, jotta se on mahdol-

lista reitittää sanoma myös ulkoiselle vastaanottaja sektorille. Vastaanottaja sektorilla on mahdollisuus ottaa sanomia vastaan FTP:n tai SOAP:n avulla. (Kuva 21.) 43 KUVA 21. Informaatio tulee kulkemaan Kelan järjestelmien kautta 7.2.4 Yhteisten sanomien reititys Jotkut sanomat saattavat koskea, sekä Kansaneläkelaitosta että jotain toista sidosryhmää. Esimerkiksi eläke-etuudet koskevat Kansaneläkelaitosta ja Eläketurvakeskusta. Sanoman lähtiessä toisesta maasta ja stesta-verkon kautta Suomen yhteyspisteeseen, LUOVA tulee reitittämään sanoman kolmeen paikkaan. Sanoma reitittyy tietovarastoon saapuviin sanomiin, Kelan omia etuuksia koskevaan tietovarastoon ja ulkoiselle sidosryhmälle. (Kuva 22)

44 KUVA 22. Sanoma saattaa koskea myös Kelan lisäksi jotain muuta sidosryhmää 8 ACCESS POI T Access Point on yhteyspiste, jonka kautta saapuvat ja lähtevät sanomat reitittyvät oikeisiin paikkoihin. Access point jaetaan näennäisesti kansalliseen ja kansainväliseen osaan (kuva 23). Kelan tehtävänä on saada toimivat yhteydet Access Pointista eteenpäin omiin taustajärjestelmiin ja tarjota palveluja omista taustajärjestelmistä muiden sektoreiden järjestelmille. Access Pointtia voidaan pitää kansallisena keskittimenä, joka lähettää tiedot muuttumattomana eteenpäin. Jäsenmaat yhdistävät heidän toimivaltaisensa laitokset yhteyspisteihin ja tiedot reititetään yhteyspisteiden kautta. Access Pointeissa on myös kopio Coordination nodessa (2.1.1.) olevasta päähakemistosta.

45 KUVA 23. Access point jaetaan kansalliseen ja kansainväliseen osaan Komissio on määrännyt, että jäsenmailla täytyy olla 1-5 yhteyspistettä. Monella jäsenmaalla lainsäädäntö ja järjestelmät eroavat toisistaan paljon ja tämä antaa hieman liikkumavaraa integroida järjestelmiä osaksi EESSIä. Suomi on päätynyt yhden yhteyspisteen malliin, jossa Kansaneläkelaitos rakentaa ja toimii yhteyspisteen sijoituspaikkana Suomessa. Kaikki sanomat ja kyselty kulkevat siis Kelan tarjoamien palveluiden kautta. 8.1 Kansainvälinen osuus Access Pointista Kansainvälinen osuus yhteyspisteestä tulee komission valitsemalta palveluntarjoajalta. Se on osa EESSIn kansallista aluetta. Access Pointtiin tulee sovellus, jota kutsutaan Reference Implementationiksi (ks. luku 8.1.1). Tietoliikenne protokollana toimii kansainväliseen Access Pointtiin asti SOAP ja käytössä on Web Service-ratkaisut, mutta siitä eteenpäin EESSI tulee tukemaan muitakin protokollia adaptereiden (ks. luku 8.1.2) avulla. (Kuva 24.) Toimitettava sovelluskokonaisuus tullaan asentamaan Kansaneläkelaitoksen tiloihin Kelan Jyväskylän atk-keskukseen, missä palvelinsali sijaitsee. Sovelluskokonaisuus liitetään yhteyspisteen kansalliseen osuuteen, joka tarkoittaa Kelassa LUOVA-viestinvälityskeskusta. Jäsenmaat saavat itse päättää käyttävätkö komission tarjoamaa sovellusta vai tekevätkö he itse komission määritelmien mukaisen sovelluksen ja liittävät sen kautta järjestelmät stesta-verkkoon. Pilottivaiheeseen mukaan pääsemiseksi, jäsenmaan on kuitenkin käytettävä komission tarjoamaa sovellusta ainakin aluksi.

46 KUVA 24. Reference Implementation kuuluu Access Pointin kansainväliseen osuuteen 8.1.1 Reference Implementation Reference Implementationia (RI) voidaan pitää kansainvälisenä osuutena Access Pointissa. Toimeksiantaja toimittaa sovelluksen jäsenmaiden käyttöön, mutta jäsenmaat voivat päättää käyttävätkö sitä, vai toteuttavatko he sen itse. AP:n kansainvälisen osuuden täytyy kuitenkin olla komission määritelmien mukainen. Se tarjoaa yhteyden stesta-verkossa sijaitsevaan Coordination Nodeen ja näin ollen eri maiden Access Pointit ovat yhteydessä toisiinsa. Suomen RI tullaan sijoittamaan sovelluspalvelimelle Kansaneläkelaitoksen palvelinsaliin.