Application Integration Architecture for Public Administration

TEKNILLINEN KORKEAKOULU Tietotekniikan osasto

Tietoliikenneohjelmistojen ja multimedian laboratorio

Riku Honkanen

Julkishallinnon sovellusintegraatioarkkitehtuuri

Diplomityö, joka on jätetty opinnäytteenä tarkastettavaksi diplomi-insinöörin tutkintoa varten Espoossa 19.1.2006

Valvoja Prof. Teemupekka Virtanen

Ohjaaja FM Olavi Rannisto

rk '■

■ HvSN KGR' :NUKAN taju:

7

TEKNILLINEN KORKEAKOULU Tietotekniikan osasto

DIPLOMITYÖN TIIVISTELMÄ

Tekijä

Riku Honkanen

Päiväys

19.1.2006

Sivumäärä 83 Työn nimi

Julkishallinnon sovellusintegraatioarkkitehtuuri

Professuuri

T ietoliikenneohj elmistot

Koodi

T-110

Työn valvoja

Professori Teemupekka Virtanen

Työn ohjaaja

FM Olavi Rannisto

Yritykset ja organisaatiot ovat jo vuosia hyödyntäneet tietotekniikkaa ja erilaisia tietojäijestelmiä toimintojensa automatisointiin ja tehostamiseen. Perinteisesti nämä tietojärjestelmät on suunniteltu toimimaan melko itsenäisinä kokonaisuuksina, mutta nykyisin yhä useammin organisaatioilla on tarpeita myös yhdistää erillisiä sovelluksia toimiviksi kokonaisuuksiksi, eli integroida sovelluksia.

Integroinnin avulla voidaan sekä tehostaa toimintaa että pidentää aiemmin hankittujen järjestelmi­

en käyttöikää.

Sovellusintegraatioprojekteihin liittyy kuitenkin useita ongelmia. Tyypillisesti näiden hankkeiden kustannukset nousevat korkeiksi ja lisäksi toteutetut integraatiot monimutkaistavat organisaatioi­

den tietoteknistä infrastruktuuria. Muun muassa näistä syistä johtuen Suomen valtionhallinnossa on laadittu suosituksia siitä, miten kokonaisvaltaista sovellusintegraatioarkkitehtuuria tulisi lähes­

tyä julkishallinnon organisaatioissa, jotta integraatioiden toteuttaminen olisi suunnitelmallisempaa ja järjestelmien hallittavuus säilyisi hyvänä.

Tässä työssä valtionhallinnon suosituksien sekä työn kohdeorganisaation ympäristön pohjalta laa­

ditaan julkishallinnolle soveltuva sovellusintegraatioarkkitehtuuri. Arkkitehtuuri hyödyntää hy­

väksi havaittuja arkkitehtuurimalleja sekä kuvaa integraatioinffastruktuurin rakenteen eri näkö­

kulmista arkkitehtuuriin liittyville eri osapuolille.

Lopuksi arkkitehtuuriin perustuva integraatioinfrastruktuuri toteutetaan kaupallisilla ohjelmisto­

tuotteilla. Lisäksi rakennetun integraatioinffastruktuurin toimivuutta testataan esimerkkisovelluk­

sella, joka hyödyntää laajasti arkkitehtuurin eri ohjelmistokomponentteja.

Avainsanat

Sovellusintegraatio, julkishallinto, tietojärjestelmäarkkitehtuuri

HELSINKI UNIVERSITY OF TECHNOLOGY Department of Computer Science and Engineering

ABSTRACT OF MASTER’S THESIS

Author

Riku Honkanen

Date

19 January 2006

Pages

83

Title of thesis

Application Integration Architecture for Public Administration

Professorship

Telecommunications Software

Professorship Code

T-110

Supervisor

Professor Teemupekka Virtanen

Instructor

M.Sc. Olavi Rannisto

Companies and other organizations have for years utilised information technology and information systems to automate and strengthen their operations. Traditionally these information systems have been designed to work as fairly independent entities but nowadays the organizations have more often needs to connect separate applications to form larger functional entities, thus to integrate applications. With application integration it is possible both to make the organization’s operation more effective and to extend the lifecycle of the existing applications.

However, application integration projects face several problems. Typically these projects are ex­

pensive and in addition the results complicate the information system infrastructure within the organizations. These reasons, among others, have led the state administration of Finland to formu­

late guidelines how application integration architecture should be approached in the public admini­

stration, so that integration implementation would be better designed and system controllability would stay on a good level.

In this thesis the state administration guidelines and the target organization’s environment form the basis for designing an application integration architecture for public administration. The architec­

ture utilises approved architecture patterns and represents the integration infrastructure from dif­

ferent viewpoints for the related stakeholders.

Finally, an integration infrastructure based on the architecture is implemented using commercial software products. Additionally, the functionality of the integration infrastructure is tested with an example application, which utilises broadly the different software components of the architecture.

Keywords

Application integration, public administration, information system architecture

Alkusanat

Tämä diplomityö on tehty työskennellessäni Säteilyturvakeskuksen tietohallinnos­

sa. Sovellusintegraatio on ollut Säteilyturvakeskuksessa aiemmin pienessä roolis­

sa, mutta sen merkittävä lisääntyminen on ollut havaittavissa viime vuosina, joka mahdollisti työni suuntaamisen tälle voimakkaasti kehittyvälle alueelle. Haluan täs­

sä yhteydessä kiittää mielenkiintoisesta työn aiheesta, aiemmin STUKissa tehdys­

tä pohjatyöstä sekä työn ohjaamisesta Olavi Rannistoa. Lisäksi haluan kiittää esi- miestäni Ari Rosenbergiä mahdollisuudesta keskittyä tämän työn tekemiseen lä­

hes täysipainoisesti työajalla.

Kiitokset ohjauksesta myös työn valvojalle Teemupekka Virtaselle parannusehdo­

tuksista sekä avusta työn viimeistelyssä.

Suuri kiitos Annalle sekä kaikille muille läheisilleni, jotka ovat jatkuvasti kannusta­

neet työn loppuunsaattamisessa.

Sisällysluettelo

Alkusanat... jjj Sisällysluettelo... jv Käsitteet...

1 Johdanto... 1

1.1 Aiheen tausta...1

1.2 Integraatio julkishallinnossa... 2

1.3 Säteilyturvakeskus... 3

1.4 Työn tavoitteet... 3

1.5 Tutkimuskysymykset... 3

1.6 Työn rakenne... 4

2 Sovellusintegraation lähestymistavat... 5

2.1 Informaatiokeskeinen integraatio... 5

2.2 Palvelukeskeinen integraatio... 8

2.3 Liiketoimintakeskeinen integraatio... 10

2.4 Portaalikeskeinen integraatio... 12

3 Sovellusintegraation toteutustavat... 14

3.1 Väliohjelmistot...14

3.2 Keskeiset integraation toteutukseen liittyvät käsitteet... 15

3.3 Integraatiostandardit... 16

3.4 Integraatiotapojen yhteenveto... 18

4 Tietojärjestelmäarkkitehtuurit...20

4.1 Arkkitehtuurikuvaukset...20

4.2 Arkkitehtuurimallit... 22

4.3 Mallipohjaiset järjestelmät... 27

4.4 Arkkitehtuurivaatimukset...27

4.5 Arkkitehtuurien arviointimenetelmät...29

4.6 Tietojärjestelmäarkkitehtuurien yhteenveto... 30

5 Vaatimusmäärittely... 32

5.1 Valtiohallinnon vaatimukset... 32

5.2 Vaatimusten tarkentaminen STUKissa... 34

5.3 Vaatimusmäärittelyn yhteenveto...37

6 Sovellusintegraatioarkkitehtuuri... 38

6.1 Osapuolet...38

6.2 Näkökulmat...38

6.3 Lähestymistapa... 39

6.4 Arkkitehtuurin perusvalinnat... 40

6.5 Arkkitehtuurin kuvaus...42

7 Arkkitehtuurin soveltaminen Säteilyturvakeskuksessa... 53

7.1 Arkkitehtuurin perusinfrastruktuurin rakentaminen... 53

7.2 Huomioita infrastruktuurin rakentamisesta... 54

7.3 Esimerkkisovelluksen määrittely... 57

7.4 Esimerkkisovelluksen toteutus... 59

7.5 Huomioita esimerkkisovelluksen toteutuksesta...61

8 Arkkitehtuurin arviointi... 63

8.1 Arviointimenetelmät...63

8.2 Vaatimusmäärittelyn toteutuminen...63

8.3 Toteutuksen arviointi...64

8.4 Kehitystarpeet... 67

8.5 Arkkitehtuurin vertailu...69

9 Yhteenveto... 73

Lähdeluettelo... 75

Käsitteet

Arkkitehtuuri Tietojärjestelmän rakenteen kuvaus.

Arkkitehtuurikuvaus Tässä työssä sama kuin arkkitehtuuri.

Järjestelmien välinen kytkentä Kuvaa tietojärjestelmien välistä riippuvuutta toisistaan. Vähäistä riippuvuutta kutsutaan löyhäksi kytkennäksi ja vahvaa riippuvuutta tiukaksi kytkennäksi.

Kohdejärjestelmä Sovellusintegraatiossa tietojärjestelmä, joka vastaanottaa informaatiota.

Lähdejärjestelmä Sovellusintegraatiossa tietojärjestelmä, joka tarjoaa informaatiota.

Malli Ohjelmistotekniikassa käytettäviä hyväksi

havaittuja ongelmanratkaisumalleja toistuviin tunnettuihin ongelmatilanteisiin.

(engl. pattern)

Näkymä Tietojärjestelmän rakenteen kuvaus tietystä

näkökulmasta tarkasteltuna.

Näkökulma Tapa katsoa tai jäsentää tietojärjestelmän

rakennetta.

Palvelukeskeinen arkkitehtuuri Arkkitehtuuri, jossa tietojärjestelmät tarjoavat toimintojaan muille järjestelmille palveluina palvelurajapintojen kautta.

Portaali Portaali on web-selaimen avulla käytettävä

yhtenäinen käyttöliittymäsovellus useisiin eri taustajärjestelmiin.

Sovellus Tietojärjestelmätyyppi, tietokoneohjelma.

(engl. application)

Sovellusintegraatio Kahden tai useamman tietojärjestelmän liittäminen toisiinsa niin, että ne muodostavat toimivan kokonaisuuden.

Taustajärjestelmä Tietojärjestelmä, joka toimii sovellus-

integraatiossa lähde- tai kohdejärjestelmänä.

Tietojärjestelmä Kokonaan tai osittain automatisoitu tietojen­

käsittelyjärjestelmä, joka tyypillisimmin on jonkinlainen tietokoneohjelmisto.

1 Johdanto

1.1 Aiheen tausta

Yrityksien ja organisaatioiden pyrkimys automatisoida toimintojaan on johtanut osaltaan tietotekniikan ja tietokoneohjelmistojen nopeaan yleistymiseen. Organi­

saatioiden tietojärjestelmät tänä päivänä keskittyvät taloushallintoon, dokumenttien käsittelyyn, kommunikaatioon ja tietovarastoihin, mutta usein käytössä on myös juuri kyseiselle alalle tai organisaatiolle ominaisia sovelluksia. Sovellukset ovat tukemassa hyvinkin erilaisia toimintoja organisaatiosta riippuen, mutta kaikkia näi­

tä yleensä yhdistää se, että ne tukevat organisaation liiketoimintaprosesseja.

Yritykset ja organisaatiot joutuvat kilpailun tai rajallisten resurssien vuoksi tehos­

tamaan ydintoimintojaan entisestään tavoilla, joihin jo käytössä olevat sovellukset eivät välttämättä riitä. Tällöin yhtenä toiminnan kehittämiskeinona on kahden tai useamman sovelluksen integroiminen, eli niiden yhdistäminen toimivaksi kokonai­

suudeksi. Kyseessä on oikeastaan liiketoimintaprosessien evoluutio, joka lähtee manuaalisista prosesseista, jatkuu osittain automatisoituihin sovelluksilla toteutet­

tuihin prosessisaarekkeisiin ja kehittyy edelleen kokonaan automatisoituja proses­

seja kohti sovellusintegraation myötä. Sovellusintegraation motivaationa voi olla myös muita syitä, kuten esimerkiksi tarve pidentää olemassa olevien järjestelmien käyttöikää antamalla niille lisäarvoa sovellusintegraatiolla.

Sovellusintegraatiolla tarkoitetaan kahden tai useamman tietojärjestelmän kytke­

mistä toisiinsa niin, että ne muodostavat toimivan kokonaisuuden. Sovellusinte- graatio sisältää liiketoimintalogiikkaa, rajapintoja, tuottavuuden hallintaa, liiketoi­

mintaprosesseja, työnkulunhallintaa, informaation käsittelyä, metatietoja, ohjelmis­

tojen suunnittelua, teknisiä standardeja sekä väliohjelmisto-teknologiaa. Se on siis strateginen toiminto- ja teknologiajoukko, joka mahdollistaa organisaation tehok­

kaamman toiminnan. (Linthicum 2003)

Nykyisin yleisemmin käytössä olevat integraatioratkaisut voidaan ongelman lähes­

tymistavan mukaan jakaa seuraaviin kategorioihin (Linthicum, 2003; Microsoft, 2004):

• informaatiokeskeinen integraatio

• palvelukeskeinen integraatio

• liiketoimintakeskeinen integraatio

• portaalikeskeinen integraatio

Näitä lähestymistapoja käsitellään tarkemmin luvussa 2. Nämä ovat teoreettisia malleja, joita käytännössä usein yhdistellään toisiinsa, niiden vahvuuksien ja heik­

kouksien mukaan.

Sovellusintegraatioon liittyy kuitenkin paljon erilaisia haasteita, kuten esimerkiksi (Hohpe 2003):

• integraatiohankkeet ovat perinteisesti olleet kalliita ja niiden taloudellista hyötyä on yleensä vaikea arvioida edes jälkikäteen.

• tietojärjestelmien kytkeminen toisiinsa aiheuttaa usein tiukkoja sidoksia näi­

den välille ja näin hallittavat kokonaisuudet kasvavat ja tietojärjestelmien hallinnointi monimutkaistuu. Samalla organisaatio saattaa myös sitoutua yh­

teen tekniseen ratkaisuun, jonka vaihtaminen myöhemmin on työlästä ja kallista.

• integroiduista tietojärjestelmistä muodostuu usein organisaatioille kriittiseksi määriteltäviä järjestelmiä, koska integroidut järjestelmät kattavat yhä suu­

remman osan organisaation kaikista toiminnoista.

• olemassa olevien tietojärjestelmien integroiminen jälkikäteen on usein han­

kalaa, koska nämä järjestelmät on alun perin suunniteltu käytettäväksi pää­

asiassa itsenäisinä kokonaisuuksina, eikä suuremman kokonaisuuden osa­

na.

• integraatioon liittyvien yleisten standardien puute on johtanut siihen, että in- tegraatioratkaisutavat vaihtelevat paljon ja organisaatioiden on vaikea valita heille sopivimmat ratkaisutavat.

Integraatiokokonaisuuksien hallintaan tulisikin löytää ratkaisuja suunnittelun ja en­

nakoinnin avulla. Aivan kuten ohjelmistokehityksessä on jo pitkään käytetty ohjel- mistoarkkitehtuurimalleja suunnittelun apuna, myös integraatioratkaisuissa on syy­

tä soveltaa samankaltaista arkkitehtuuriajattelua. Organisaatioiden tulisi siis tun­

nistaa ja väistää integraatiohankkeiden takana piilevät tyypilliset sudenkuopat ja luoda sovellusintegraatioarkkitehtuuri järjestelmien kokonaiskuvan hallitsemiseksi.

Sovellusintegraatioarkkitehtuuri on erityinen tietojärjestelmäarkkitehtuurityyppi, jossa arkkitehtuurin näkökulma painottuu sovellusten integroimiseen.

Arkkitehtuuri on ohjelmiston tai muun tietojärjestelmän rakenteen kuvaus, joka ku­

vaa järjestelmän komponentteja, komponenttien ominaisuuksia sekä näiden välisiä suhteita. (Bass, 2003)

Jokaisella tietojärjestelmällä on olemassa rakenne vaikka sitä ei olisi suunniteltu laatimalla arkkitehtuuri. Arkkitehtuurin suunnittelulla saadaan kuitenkin aikaan toi- mintavarmempia ja helpommin ylläpidettäviä järjestelmiä kuin, jos järjestelmiä suunnitellaan vasta toteutuksen aikana.

1.2 Integraatio julkishallinnossa

Suomen valtionhallinnossa on sovellusintegraatioiden tarve, haasteet sekä integ- raatioarkkitehtuurien tarve tiedostettu ja eri työryhmät ovat tutkineet julkishallinnol­

le sopivia tietohallinnon käytäntöjä (Akselin, 2005; Valtiovarainministeriö, 2004).

Keskeisenä kehityskohteena näissä dokumenteissa on sähköinen hallinto ja tä­

män merkittävimmiksi ajureiksi on tunnistettu:

• julkishallinnon tuottavuuden kohottaminen

• julkishallinnon tietojärjestelmien heterogeenisyyden huomiointi

• tiedon ja palvelujen löyhtymisen tehostaminen

• eteneminen virastokohtaisista ratkaisuista kohti virastojen ja niiden sidos­

ryhmien välisiä palveluprosesseja

• asiakkaan asiakokonaisuuden käsittelyn mahdollistaminen virastojen ja nii­

den sidosryhmien välisillä palveluprosesseilla

• lisääntyvä kansainvälinen ja erityisesti EU-yhteistyö

Myös Euroopan Unionin taholla Interchange of Data between Administrations (IDA) on julkaissut European Interoperability Framework (EIF) -viitekehyksen, joka pyrkii linjaamaan sähköisen hallinnon (e-government) ja sähköisten asiointipalve­

lujen yhteentoimivuutta EU:n jäsenmaiden välillä ja näin osaltaan vaikuttaa myös Suomen valtionhallinnon sähköisen hallinnon kehittämiseen. (Valtiovarainministe­

riö, 2004)

Yllämainittujen ajureiden sekä teknologisten ajureiden pohjalta valtiohallinnon työ­

ryhmät ovat suositelleet julkishallinnon organisaatioille palvelukeskeisen arkkiteh­

tuurin hyödyntämistä. (Akselin, 2005)

Palvelukeskeisellä arkkitehtuurilla (Service-Oriented Architecture, SO A) tarkoite­

taan tietojärjestelmien suunnittelumallia, jossa pääpaino on tietojärjestelmien tar­

joamissa palveluissa. Nämä palvelut, eli tietojärjestelmien ulospäin tarjoamat toi­

minnallisuudet, kuvataan tarkasti määritellyillä rajapinnoilla ja palvelusopimuksilla.

Tämä mahdollistaa tietojärjestelmien yleisen yhteensopivuuden riippumatta raja­

pintojen takana olevista järjestelmien erilaisista toteutustekniikoista. (Lomow, 2004)

Palvelukeskeisen lähestymistavan lisäksi myös portaalikeskeistä lähestymistapaa suositellaan monikanavaisen käyttöliittymän rakentamiseksi käyttäjille (kansalai­

set, virkailijat, yritykset). (Akselin, 2005)

Palvelukeskeinen ja portaalikeskeinen lähestymistapa ovat siis päälähtökohdat julkishallinnon integraatioarkkitehtuurille valtiohallinnon suositusten mukaan. Näis­

sä suosituksissa näkökulma on kuitenkin organisaatioiden välisessä eikä sisäises­

sä integraatiossa, eivätkä ne myöskään sido organisaatioita rajoittumaan näihin, vaan muitakin lähestymistapoja on mahdollista käyttää.

1.3 Säteilyturvakeskus

Tämä työ tehdään osana Säteilyturvakeskuksen (STUK) sovellusintegraatiohan- ketta ja Säteilyturvakeskus toimii työssä laadittavan sovellusintegraatioarkkitehtuu- rin kohdeympäristönä. Tämä tuo osaltaan omat reunaehtonsa arkkitehtuurille, sa­

malla tuoden arkkitehtuurin suunnittelun konkreettisemmalle tasolle, aina toteutus­

vaiheeseen asti.

1.4 Työn tavoitteet

Tämän työn päätavoite on suunnitella sovellusintegraatioarkkitehtuuri, joka toimii julkishallinnon organisaation sovellusintegraatioiden viitekehyksenä. Arkkitehtuurin tarkoituksena on ohjelmistokokonaisuuksien helppo hallinta sekä ennen kaikkea onnistuneiden sovellusintegraatiohankkeiden mahdollistaminen. Arkkitehtuurissa otetaan huomioon nykyinen heterogeeninen tietojärjestelmäympäristö sekä tule­

vaisuudessa odotettavissa olevat tietojärjestelmien kehityssuunnat.

Integraatioarkkitehtuurin kuvaus toimii myös yhtenä määrittelydokumenttina orga­

nisaation ulkopuolisille osapuolille ulkoistettaessa sovellusintegraatioprojektien toteutuksia.

Tarkoituksena on:

1. suunnitella julkishallinnon sovellusintegraatioarkkitehtuuri Säteilyturvakes­

kukselle

2. toteuttaa integraatioarkkitehtuurin perusinfrastruktuuri

3. toteuttaa yksittäinen sovellusintegraatioesimerkki integraatioinfrastruktuuria käyttäen

4. arvioida arkkitehtuuria toteutusvaiheiden jälkeen 1.5 Tutkimuskysymykset

Työn tavoitteena on vastata seuraaviin kysymyksiin:

• Mitä palveluita arkkitehtuuri tarjoaa?

• Mistä loogisista ja teknisistä komponenteista arkkitehtuuri koostuu?

• Mikä on arkkitehtuurin palveluiden ja komponenttien suhde, eli missä kom­

ponenteissa palvelut sijaitsevat?

• Mitä palveluita erityyppisten sovellusintegraatiototeutusten tulisi hyödyntää?

1.6 Työn rakenne

Työn ensimmäisessä osassa tutkitaan sovellusintegraatiota teorian ja hyväksi ha­

vaittujen arkkitehtuurimallien kautta.

Toisessa osassa määritellään valtiohallinnon sovellusintegraatioarkkitehtuurin vaa­

timusmäärittely tarkentaen tätä STUKin näkökulmasta. Tämän lisäksi aiemmin esi­

tettyjä arkkitehtuurimalleja sekä teknologisia näkökulmia tarkastelemalla valitaan perusmalli julkishallinnon integraatioarkkitehtuurille ja suunnitellaan varsinainen arkkitehtuuri.

Kolmannessa osassa arkkitehtuuri toteutetaan käytännössä rakentamalla perusinf­

rastruktuuri (palvelimet, ohjelmistot) ja lisäksi tätä infrastruktuuria hyödyntäen to­

teutetaan yksittäinen sovellusintegraatio. Esimerkkitoteutukseen valitaan sovellus, joka käyttää arkkitehtuurin eri osia mahdollisimman laajasti. Lopuksi arkkitehtuuria voidaan arvioida teorian ja käytännön kokemuksien perusteella.

2 Sovellusintegraation lähestymistavat

Liiketoiminnan tukeminen sovellusintegraatiolla tapahtuu käytännössä informaati­

on välittämisellä toisiaan tukevien tietojärjestelmien välillä. Informaation vaihto voi olla tietojärjestelmistä riippuen yksisuuntaista tai molemmansuuntaista. Tietojärjes­

telmät siis toimivat integraatiossa lähdejärjestelmänä, kohdejärjestelmänä tai mo­

lemmissa rooleissa. Kun varsinainen integraation tarve järjestelmien välillä on tun­

nistettu, on edelleen olemassa monia erilaisia tapoja integraation toteuttamiseen.

(Linthicum, 2003)

Vaikka sovellusintegraatioon on monia eri toteutusteknisiä lähestymistapoja, voi­

daan nämä jaotella korkealla tasolla neljään eri kategoriaan. Nämä ovat (Linthi­

cum, 2003; Microsoft, 2004):

• informaatiokeskeinen integraatio

• palvelukeskeinen integraatio

• liiketoimintakeskeinen integraatio

• portaalikeskeinen integraatio

Tässä luvussa syvennytään näihin eri lähestymistapoihin tarkastelemalla niiden perusperiaatteita, vahvuuksia ja heikkouksia.

2.1 Informaatiokeskeinen integraatio

Informaatiokeskeinen integraatio on perinteisin ja edelleen yleisin tapa lähestyä tietojärjestelmien integraatiota. Sen lähtökohtana on puhtaasti informaation välit­

täminen kahden tai useamman tietojärjestelmän välillä. Tällainen integraatio on käsitteellisellä tasolla helposti ymmärrettävissä, koska integraatiota ajatellaan lä­

hellä sovellusten perustoimintaa. Kyse on toisiinsa liittyvien sovelluksen kytkemi­

sestä laajemmaksi kokonaisuudeksi. (Linthicum, 2003)

Informaatiokeskeisessä integraatiossa siirrettävä informaatio on useimmiten järjes- telmäriippuvaista siten, että informaation semantiikka on integraatiossa sovittu ai­

noastaan lähde- ja kohdejärjestelmien välille yhteensopivaksi (Kuva 2-1). (Linthi­

cum, 2003)

asds )fasdsf

asdasd

fdsdfsdf.

sdgfgt^

werjht

Sovellus A Sovellus B

qewgh

Kuva 2-1 Informaatiokeskeisessä integraatiossa sovellusten välinen semantiikka on usein vain kyseisten järjestelmien välillä sovittua ja ymmärrettävää. (Linthicum, 2003) Informaatiokeskeistä integraatiota voidaan toteuttaa informaation eri tasoilla. Nä­

mä tasot voidaan jakaa kolmeen kategoriaan (Linthicum, 2003; Microsoft, 2004):

• tietotaso (data layer)

• sovelluslogiikkataso (functional layer)

• käyttöliittymätaso (presentation layer)

Tämä kolmikerrosmalli on myös sovelluksissa yleisesti käytetty arkkitehtuurimalli, joka tunnetaan myös nimellä MVC-malli (Model-View-Controller) (Buschmann, 1996). MVC-malli kuvataan tarkemmin luvussa 4.2. Tässä yhteydessä käymme läpi nämä tasot ainoastaan informaatiokeskeisen integraation näkökulmasta.

Tietotaso

Tietokannat ovat yleisimpiä informaation kohde- ja lähdejärjestelmiä. Nämä ovat luonnollisia lähtöpisteitä informaatiokeskeiselle integraatiolle, koska tietokannat on suunniteltu nimenomaan informaation varastointiin ja käsittelyyn. Moderneilla tie­

tokantatuotteilla on olemassa selvät rajapinnat, joiden kautta tietokannan tarjoamia palveluja voidaan käyttää muista tietojärjestelmistä käsin. (Linthicum, 2003)

Kuva 2-2 esittää miten ulkopuolinen tietojärjestelmä pyytää informaatiota tietokan­

nan rajapinnan kautta käyttämällä SQL-kieltä.

Tietojärjestelmä Tietokanta informaatio.

Kuva 2-2 Tietokannat tarjoavat palveluita informaation käsittelyyn. (Linthicum, 2003) Tietokantatuotteita on useita ja niissä on toiminnallisia eroavaisuuksia. Yleisimmät tietokannat ovat relaatiotietokantoja, mutta myös muun tyyppisiä tietokantoja käy­

tetään. Integraation kannalta nämä erot eivät kuitenkaan ole merkittäviä, koska tietokantoja käytetään hyvin määriteltyjen rajapintojen avulla. Varsinaisina haas­

teina ovat kuitenkin tietokantoihin talletetun tiedon semantiikan ymmärtäminen kun varsinainen sovelluslogiikka ei ole käytettävissä sekä informaation muuntaminen toisille järjestelmille sopivaan muotoon. (Linthicum, 2003)

Sovelluslogiikkataso

Sovelluslogiikkatason integraatio tapahtuu samalla tasolla, missä sovelluksien toimintalogiikka on toteutettu. Tämän tason integraatio on usein astetta monimut­

kaisempaa, koska eri sovellukset on toteutettu eri lähtökohdista ja niiden seman­

tiikka on sovelluskohtaista. (Microsoft, 2004)

Sovelluslogiikkatason integroinnin lähtökohtana ovat ohjelmointirajapinnat (API, Application Programming Interface). Ohjelmointirajapinta on joukko määrittelyjä, miten ohjelmakomponentti kommunikoi ulospäin. Komponentin sisäinen toiminto on enkapsuloitu siten, että toinen komponentti voi kommunikoida tämän kanssa ainoastaan rajapinnan määrittelemällä tavalla. Näin rajapinnan avulla luodaan abstraktio komponentin tarjoamista palveluista (Wikipedia). Kuva 2-3 kuvaa tieto­

järjestelmän rajapinnan toimintaa. (Linthicum, 2003)

Abstraktit palvelut Tietojärjestelmä

informaatio

Kuva 2-3 Komponentin ulkopuolinen kommunikaatio tapahtuu rajapinnan kautta (Wikipedia)

Kaikilla sovelluksilla ei kuitenkaan ole olemassa ulkoisia rajapintoja. Usein järjes­

telmät, jotka tarjoavat rajapintoja, eivät tarjoa näitä riittävän laajasti integraation näkökulmasta.

Rajapinnat ovat komponentti- ja sovelluskohtaisia ja tämän vuoksi jokainen raja­

pinta on erilainen. Sovelluslogiikkatason integraatiossa jokaisen integroitavan so­

velluksen rajapintoihin täytyy perehtyä tapauskohtaisesti ja rajapinnat voivat lisäksi rajoittaa mahdollisuuksia, jos haluttuja palveluja ei ole määritelty sovellusten raja­

pintoihin. Oikeista lähtökohdista aloitettaessa sovelluslogiikkatason integraatio voi kuitenkin olla erittäin tehokasta. (Microsoft, 2004)

Käyttö liitty m ätaso

Informaatiokeskeisen integraation kolmas taso on käyttöliittymätaso. Sovellusten käyttöliittymiä ei ole suunniteltu integraation näkökulmasta sovellusten väliseen kommunikaatioon ja tämän vuoksi käyttöliittymätason integraatio voi olla vaikeaa.

Toisena käyttöliittymäintegroinnin ongelmana on skaalautuvuus, koska jokainen integraatiossa käytettävä käyttöliittymän näkymä täytyy määritellä ja toteuttaa erik­

seen. (Linthicum, 2003)

Käyttöliittymätason integraatio saattaa kuitenkin olla erittäin edullinen tapa toteut­

taa integraatiota. Vaikka itse yhteyden muodostus näin saattaa olla edullista, on tämä kuitenkin riskialtis muutoksille. Mikäli sovelluksen käyttöliittymä muuttuu, täy­

tyy myös osa integraatioyhteydestä rakentaa uudelleen vaikka sovelluksen sovel­

luslogiikka pysyisi samana. (Microsoft, 2004)

Toisinaan käyttöliittymätaso on ainut vaihtoehto kommunikoida jonkin sovelluksen kanssa. Tämä johtuu useimmiten rajapintojen puutteesta sekä sovelluksista, joissa myös sovelluksen toimintalogiikka on osittain tai kokonaan toteutettu käyttöliitty- mätasolla. Tällaisen integraation tekemiseen on olemassa työkaluja, mutta tämä vaatii integraation toteuttajilta erityistä huolellisuutta käyttöliittymän toiminnan ym­

märtämisessä. (Linthicum, 2003)

Informaatiokeskeisen integraation vahvuudet ja heikkoudet

Informaatiokeskeisen integraation vahvuuksia ovat (Linthicum, 2003; Microsoft, 2004):

• konsepti on helposti ymmärrettävissä

• informaatio on valmiiksi oleellinen osa jokaista tietojärjestelmää

• kohde ja lähdejärjestelmiä ei yleensä tarvitse muuttaa, koska kyse on vain näiden käsittelemän informaation välittämisestä

• laajasti käytössä ja parhaiten tunnettu lähestymistapa

Vastaavasti heikkouksia ovat (Linthicum, 2003; Microsoft, 2004):

• vaikka konseptin ymmärtäminen on yksinkertaista, on sen toteuttaminen käytännössä usein monimutkaista, koska tietojärjestelmien ja informaatio­

virtojen ymmärtäminen vie aikaa

• lähde- ja kohdejärjestelmien välille syntyy helposti tiukka kytkentä

• taustalla olevia liiketoimintaprosesseja ei voida tukea ja mallintaa täysin in- formaatiokeskeisen lähestymistavan kautta, koska lähtöpisteenä ovat in­

formaatiovirrat eivätkä toiminnan taustalla olevat liiketoimintaprosessit

• informaatioon liittyvä semantiikka on usein sovelluskohtaista ja kaksi näen­

näisesti samaa tietoa käsittelevää tietojärjestelmää saattavat tarkoittaa sillä eri asioita

• informaatiokeskeinen integraatio ei ole ainoastaan informaatiovirtojen ohja­

usta vaan informaatiota täytyy usein myös muuntaa ja hallita muilla tavoin, jotta tietojärjestelmät saadaan toimimaan yhteen

2.2 Palvelukeskeinen integraatio

Palvelukeskeisen lähestymistavan pääpaino on tietojärjestelmien tarjoamissa pal­

veluissa. Palvelukeskeisen integraation avulla organisaatiot voivat jakaa tietojär­

jestelmien tarjoamat palvelut ja informaation ainakin periaatteessa kaikkien mui­

den tietojärjestelmien käytettäväksi. Nämä palvelut, eli tietojärjestelmien ulospäin tarjoamat toiminnallisuudet, kuvataan tarkasti määritellyillä rajapinnoilla ja palvelu­

sopimuksilla. Tämä mahdollistaa tietojärjestelmien yleisen yhteensopivuuden riip­

pumatta rajapintojen takana olevista järjestelmien erilaisista toteutustekniikoista.

(Linthicum, 2003)

Palvelukeskeinen integraatiokaan ei ole uusi ilmiö. Palvelukeskeiset arkkitehtuurit ovat kuitenkin viime vuosina saaneet paljon huomiota organisaatioissa teknologis­

ten standardien kehityksen myötä. Palvelukeskeisen integraation yksi suurimpia heikkouksia on perinteisesti ollut yhtenäisten avointen standardien puute, joilla rajapinnat ja tietojärjestelmien välinen kommunikaatio toteutettaisiin. Palvelukes­

keisestä integraatiosta ei saada todellista hyötyä irti, jos käytössä on erityyppisiä ratkaisuja, jotka eivät kykene kommunikoimaan suoraan keskenään. Yksi palvelu­

keskeisten arkkitehtuurien idealistinen tavoite on ollut luoda universaali kieli järjes­

telmien rajapinnoille ja kommunikaatiolle, jota käytetään jokaisessa palvelussa.

Integraation pohjana on tällöin sopimus siitä, miten rajapinnat toteutetaan. Käy­

tännössä palveluiden rakentaminen kuitenkin rajoittuu tällä hetkellä enemmän or­

ganisaatioiden sisälle, eikä laajoja organisaatiorajoja ylittäviä palveluhakemistoja ole syntynyt. (Linthicum, 2003)

Palvelukeskeisessä lähestymistavassa tietojärjestelmien toiminnallisuus kootaan palveluihin eikä lähde- ja kohdejärjestelmien välille rakenneta tiukkaa kytkentää vaan järjestelmien välinen kytkentä on voimassa ainoastaan ajonaikaisesti. Tämän myötä palveluja voidaan käyttää joustavammin, koska samaa palvelua voi käyttää moni eri järjestelmä ja palveluja voidaan myös yhdistää tai käyttää uudelleen tule­

vaisuudessa. (Linthicum, 2003)

Palvelukeskeisen integraation sovellusmallit

Palvelukeskeisen integraation sovellusmallit voidaan jakaa seuraaviin kategorioi­

hin (Linthicum, 2003):

• tapahtumapohjainen

• komposiittipalvelut

• hajautetut itsenäiset sovellukset

Tapahtumapohjaiset ratkaisut koostuvat yksittäisistä palveluista, jotka aktivoituvat määriteltyjen tapahtumien laukaisemina. Jos ensimmäinen tapahtuma synnyttää uuden tapahtuman, seuraa tästä tapahtumaketju, joka on myös informaatiovirta (Kuva 2-4). Tämä malli muistuttaa informaatiokeskeistä integraatiota, jossa keski­

tytään enemmän informaation ohjaamiseen kuin suurempiin palvelukokonaisuuk­

siin. (Linthicum, 2003)

tanahtuma 1 tapahtuma 5

tapahtuma 2

tapahtuma

tapahtuma 3 Sovellus D Sovellus C

Sovellus B Sovellus A

Kuva 2-4 Tapahtumapohjaisessa ratkaisussa tapahtumat synnyttävät informaatiovirran (Linthicum, 2003).

Komposiittisovelluksilla tarkoitetaan ratkaisuja, joissa useampi taustalla oleva tie­

tojärjestelmä piilotetaan yhden yhteisen rajapinnan taakse (Kuva 2-5). Taustajär- jestelmillä voi olla omat yksilölliset rajapinnat, mutta näiden lisäksi luodaan yhtei­

nen komposiittirajapinta, joka yksinkertaistaa järjestelmien käyttöä yhdeksi koko­

naisuudeksi (Linthicum, 2003). Komposiittipalvelusta käytetään suomeksi myös nimitystä yhteispalvelu (Akselin, 2005).

Sovellus A

Sovellus B

*o

T53

O 3

_

Kuva 2-5 Komposiittipalvelu yhdistää taustalla olevat järjestelmät yhdeksi abstraktiksi so­

vellukseksi (Linthicum, 2003).

Hajautetut itsenäiset sovellukset ovat tietynlainen palvelupohjaisten arkkitehtuuri­

en tavoitetila, jossa itsenäiset sovellukset ja komposiittipalvelut muodostavat yh­

den ison kokonaisuuden eri palveluita (Kuva 2-6). Tämä tavoitetila ei kuitenkaan todennäköisesti tule toteutumaan vuosiin muuten kuin organisaatioiden sisäisinä palvelukokonaisuuksina. (Linthicum, 2003)

Sovellus A

Sovellus B

Sovellus

Kuva 2-6 Hajautetut itsenäiset sovellukset muodostavat universaalin palvelujoukon (Linthi- cum, 2003).

Nämä edellä kuvatut palvelukeskeiset sovellusmallit muodostavat hierarkian.

Alimmalla tasolla ovat yksinkertaiset tapahtumapohjaiset ratkaisut, jotka perustu­

vat tapahtumiin ja näistä seuraaviin informaatiovirtoihin. Astetta ylemmällä tasolla ovat komposiittipalvelut, joissa useampia taustasovelluksia abstrahoidaan yhdeksi palveluksi. Ylimmällä tasolla joukko alempien tasojen sovelluksia muodostaa yhte­

näisen palvelujoukon, jossa kaikki sovellukset voivat teoriassa kommunikoida kes­

kenään. (Linthicum, 2003)

Palvelukeskeisen integraation vahvuudet ja heikkoudet

Palvelukeskeisen lähestymistavan vahvuuksia ovat (Lomow, 2004; Linthicum, 2003):

• palvelukomponenttien uudelleenkäytettävyys

• löyhä kytkentä tietojärjestelmien välillä

• tietojärjestelmien muutosten joustavuus

• tämän hetken lupaavimpia integraation lähestymistapoja uusien verkkopal- velutekniikoiden (kuten esimerkiksi Web Services) myötä

• organisaatioiden välisen integraation helpottaminen sopimalla yhteiset standardit

• lähempänä todellisia liiketoimintaprosesseja kuin informaatiokeskeinen in­

tegraatio

Heikkouksia puolestaan ovat (Lomow, 2004; Linthicum, 2003):

• palvelukeskeisten ratkaisujen rakentaminen on alussa hidasta ja kallista ja edut tulevat esiin vasta myöhemmissä vaiheissa kun palveluita on toteutettu paljon

• olemassa olevien sovellusten integrointi on hankalaa, koska näihin täytyy lähes aina tehdä muutoksia rajapintojen luomiseksi

• yhtenäisten standardien puute on ollut tähän asti estämässä ratkaisujen laajempaa leviämistä ja vahvuuksien täyttä hyödyntämistä

2.3 Liiketoimintakeskeinen integraatio

Organisaatioiden tietojärjestelmien päätarkoitus on tukea organisaation operatiivis­

ta toimintaa eli liiketoimintaprosesseja. Näin ollen on luonnollista lähestyä myös tietojärjestelmien integraatiota prosessinäkökulmasta, jossa tietojärjestelmät näh­

dään suoraan prosessien osina. Informaatiokeskeiseen ja palvelukeskeiseen in­

tegraatioon verrattuna liiketoimintakeskeinen integraatio käsittelee tietojärjestelmiä

korkeammalla konseptuaalisella tasolla, jossa informaatiovirtoja käsitellään liike­

toiminnan prosessien ja osaprosessien kautta. (Linthicum, 2003)

Liiketoimintakeskeisen lähestymistavan pääerot informaatiokeskeiseen ja palvelu­

keskeiseen lähestymistapaan ovat (Linthicum, 2003):

• lähtökohtana liiketoimintaprosessit.

• usein käytännössä toteutetaan alemmilla tasoilla informaatiokeskeistä ja palvelukeskeistä integraatiota hyödyntäen (Kuva 2-7).

• enkapsuloi kokonaisia liiketoimintaprosesseja yksittäisiksi abstrakteiksi so­

velluksiksi.

• riippumaton alla olevista lähde- ja kohdejärjestelmistä, koska prosesseja voidaan periaatteessa muuttaa muuttamatta alla olevia tietojärjestelmiä.

• strateginen liiketoiminnallinen näkökulma tietojärjestelmiin ja siihen kuinka niiden tulisi ideaalisessa tilanteessa toimia

Liiketoimintaprosessit

Palvelukeskeinen

informaatlokeskel

Kuva 2-7 Liiketoimintakeskeinen integraatio käyttää usein alemmilla tasoilla muita integraa­

tion lähestymistapoja. (Linthicum, 2003)

Liiketoimintakeskeinen integraatio on sovellusintegraation perimmäinen tavoite, mutta käytännössä sen toteuttaminen on erittäin vaikeaa. Ensimmäinen haaste on, että liiketoimintaprosessit pitäisi onnistuneesti kuvata ja mallintaa. Organisaatioi­

den prosessit ovat kuitenkin monimutkaisia ja niitä on paljon. Toisena haasteena on, että automatisoitavat prosessit täytyy saada kuvattua niin, että ne voitaisiin toteuttaa tietojärjestelmien avulla, mutta tämän hetken työkaluilla mallinnettujen liiketoimintaprosessien rakentaminen laajoiksi tietojärjestelmiksi on vaikeaa ja hi­

dasta. (Linthicum, 2003)

Vaikka organisaation useat prosessit tai osaprosessit olisi jo automatisoitu, tieto­

järjestelmät eivät kuitenkaan ole yleensä yhteydessä toisiinsa riittävästi toteuttaak­

seen laajempia liiketoimintaprosesseja (Kuva 2-8). (Linthicum, 2003)

Kuva 2-8 Organisaation prosessit muodostuvat sovellussaarekkeista, joiden välillä informaation kulku on vajavaista. (Linthicum, 2003)

Liiketoimintakeskeisen integraation vahvuudet ja heikkoudet

Liiketoimintakeskeisen integraation vahvuuksia ovat (Linthicum, 2003; Microsoft, 2004):

• lähtökohtana organisaation operatiivinen toiminta

• hyödyntää joustavasti alemmilla kerroksilla eri tekniikoita ja integraation lä­

hestymistapoja

• prosesseja voidaan teoriassa muuttaa riippumatta taustalla olevista tietojär­

jestelmistä

• mahdollisuus rakentaa raportointityökaluja suoraan prosesseille

Liiketoimintakeskeisen integraation heikkouksia ovat (Linthicum, 2003; Microsoft, 2004):

• vaatii syvällistä liiketoimintaprosessien tuntemista

• mahdollisesti luo pullonkaulan kun useita eri prosesseja hallitaan yhden pis­

teen kautta

• teoreettinen lähestyminen tietojärjestelmiin, jonka toteuttaminen käytännös­

sä on vaikeaa

• tekniset työkalut ja standardit eivät ole vielä kypsiä laajaan käyttöön.

• toteuttaminen on hidasta ja kallista 2.4 Portaalikeskeinen integraatio

Portaalikeskeinen lähestymistapa tuo Internet-tekniikoihin pohjautuvat portaalit integraation keskeiseksi kohdejärjestelmäksi. Portaali on web-selaimen avulla käy­

tettävä yksi yhteinen käyttöliittymä useisiin eri taustajärjestelmiin. Termiä "portaali”

käytetään nykyään laajemmin kuvaamaan myös erilaisia laajoja web-sivustoja, mutta tässä yhteydessä portaalilla tarkoitetaan järjestelmää, joka tarjoaa näkymiä ja kommunikaatiota useisiin erillisiin taustalla oleviin tietojärjestelmiin. Integraation kannalta kyseessä on siis asetelma, jossa lähdejärjestelmiä on useita, mutta koh­

dejärjestelmänä on mahdollisesti ainoastaan portaali (Kuva 2-9). (Linthicum, 2003) Portaalikeskeinen integraatio voidaan jakaa eri tasoihin (Microsoft, 2004):

• näkymäpohjainen - portaalissa käytetään staattisia näkymiä eri järjestelmiin

• kevyt prosessointi - portaaliin määritellään erilaisia sääntöjä, joiden mukaan käyttäjän näkymät saattavat vaihdella

• interaktiiviset sovellukset - portaalin käyttöliittymän kautta voidaan käyttää ohjelmia yksi kerrallaan

• interaktiiviset komposiittisovellukset - sovellusnäkymät voivat reagoida toi­

siinsa

web-selain

portaalipalvelin

Sovellus A

Sovellus B

Kuva 2-9 Portaalikeskeisessä integraatiossa portaalipalvelin toimii keskitettynä pisteenä kaikkien järjestelmien välillä. (Microsoft, 2004)

Tarjoamalla yhteisen käyttöliittymän eri sovelluksille eli laajentamalla sovellusten käyttöliittymiä, portaalikeskeinen integraatio välttää useat suoran sovellusten väli­

sen integraation ongelmat. Tällöin taustajärjestelmiä ei yleensä tarvitse muuttaa ollenkaan, vaan niiden päälle rakennetaan uusi käyttöliittymäkerros. Portaalikes- keisen integraation tavoitteena ei useimmiten ole suora sovellusten välinen kom­

munikaatio, vaan välittää eri sovellusten informaatiota keskitetysti käyttäjälle, joka voi tarvittaessa manuaalisesti siirtää tietoa sovelluksesta toiseen. Portaaleilla on oma tärkeä roolinsa integraatiohankkeissa, joissa on tarve käyttöliittymälle. Usein tämä taso on integraatiolle riittävä, mutta pelkästään portaalien avulla ei voida to­

teuttaa automatisoitua järjestelmien välistä integraatiota, jossa ei tarvita käyttäjän interaktiota. (Linthicum, 2003)

Portaalikeskeisen integraation vahvuudet ja heikkoudet

Portaalikeskeisen integraation vahvuuksia ovat (Linthicum, 2003; Microsoft, 2004):

• hallinnointi, koska tietojärjestelmien välinen kommunikaatio tapahtuu keski­

tetyn pisteen kautta

• web-tekniikoiden ansiosta nopeasti toteutettavaa

• voidaan usein toteuttaa muuttamatta integroitavia sovelluksia

• tekniikka on kypsää ja perustuu yleisiin standardeihin

• joustavuus, koska käyttäjä tekee varsinaiset päätökset näkemänsä infor­

maation perusteella

Vastaavasti portaalikeskeisen integraation heikkouksia ovat (Linthicum, 2003; Mic­

rosoft, 2004):

• tehoton, koska informaatio ei kulje automaattisesti ja reaaliajassa järjes­

telmien välillä vaan vaatii interaktiota käyttäjältä

• virhealtis, koska järjestelmät ovat riippuvaisia käyttäjän päätöksistä ja toi­

minnoista

• taustajärjestelmien integroiminen web-pohjaiseksi vaatii usein myös sovel­

luspalvelimen, joka hidastaa ja monimutkaistaa toteutusta

• portaalista muodostuu kriittinen järjestelmä, koska se on keskitetty käyttö­

liittymä useisiin eri taustajärjestelmiin

• tietoturvan merkitys nousee käytettäessä julkista Internetiä organisaation ulkopuoliseen kommunikaatioon.

3 Sovellusintegraation toteutustavat

Luvun 2 integraation lähestymistavat ovat melko teoreettisia viitekehyksiä integ­

raatioon. Nämä ovat merkittäviä arkkitehtuurin suunnittelun kannalta, mutta arkki­

tehtuurin yksityiskohtaisemman suunnittelun sekä toteutuksen kannalta on tärkeä­

tä tuntea varsinaisia integraation toteutustapoja. Tässä luvussa keskitytään ku­

vaamaan integraatiotekniikoita, integraatiotermejä sekä integraatioon liittyviä tek­

nologisia standardeja.

3.1 Väliohjelmistot

Teknisesti sovellusintegraatiota toteutetaan väliohjelmistojen (middleware) avulla (Linthicum, 2003). Väliohjelmistot ovat ohjelmistoja, jotka edistävät kahden tai useamman tietojärjestelmän välistä kommunikaatiota. Väliohjelmistojen päätarkoi­

tus on siis tiedon välittäminen eri järjestelmien välillä, mutta usein tämä käsittää pelkän tiedon siirtämisen lisäksi myös tietojärjestelmille tarjottavaa läpinäkyvyyttä esimerkiksi niiden sijainnin, rinnakkaisuuden, replikaation, virheiden tai liikkuvuu­

den suhteen. (Bakken, 2003)

Väliohjelmistoja voidaan jaotella niiden teknisten periaatteiden mukaan. Alla on lueteltu tyypillisimmät kategoriat (Bakken, 2003; Butler Group, 2005):

• hajautetut tietokannat (distributed tuples / shared database). Informaation välitys tapahtuu tietojärjestelmille yhteisen tietovaraston kautta.

• etäproseduurikutsut (remote procedure call). Lähdejärjestelmä mahdollistaa sen funktioiden kutsun etänä verkon yli.

• viestinvälitys (message-oriented middleware, MOM). Tietojärjestelmät kommunikoivat keskenään yhteisen viestijonon avulla.

• hajautetut oliot (distributed object middleware). Oliopohjaiset ohjelmisto- komponentit hajautetaan verkon yli.

• transaktiot (transaction-oriented middleware). Kommunikaatio jaetaan ja­

kamattomiksi transaktioiksi siten, että niiden vaikutukset voidaan peruuttaa epäonnistuneiden transaktioiden kohdalla.

Sovellus- ja integraatiopalvelimet

Edellä lueteltujen väliohjelmistokategorioiden kohdalla on kuitenkin markkinoilla tapahtunut 1990-luvun lopulta lähtien konvergenssia, eli eri väliohjelmistokonseptit sulautuvat entistä enemmän yhteen tarjolla olevissa ohjelmistotuotteissa. Näin sama tuote saattaa käyttää esimerkiksi viestinvälitystä joissain toiminnoissa ja etäproseduurikutsuja toisissa. (Bakken, 2003)

Eri väliohjelmistotyyppejä yhdistäviä ohjelmistotuotteita on alettu viime vuosina kutsua sovellus- tai integraatiopalvelimiksi. Sovelluspalvelimella yleensä tarkoite­

taan palvelinta, joka pääasiassa käsittelee sovelluslogiikkaa ja koordinoi yhteyksiä muihin tietojärjestelmiin. Integraatiopalvelimet puolestaan pyrkivät entistä enem­

män vastaamaan integraatiotarpeisiin myös korkeammalla tasolla mm. liiketoimin­

taprosessien mallinnusmahdollisuuksilla. (Linthicum, 2003)

Sovelluspalvelimet ja viestinvälitykseen pohjautuvat integraatiopalvelimet ovat tällä hetkellä markkinoiden kaksi vahvinta trendiä integraatioratkaisuissa. (Butler Group, 2005)

3.2 Keskeiset integraation toteutukseen liittyvät käsitteet Löyhä ja tiukka kytkentä

Löyhän kytkennän perusperiaate on, että kaksi kommunikoivaa osapuolta (sovel­

lus, komponentti, palvelu, käyttäjä) tekevät mahdollisimman vähän oletuksia toisen osapuolen suhteen. Osapuolten välinen kommunikaatio tehostuu tekemällä ole­

tuksia toisen ominaisuuksista, mutta samalla tämä muodostaa tiukemman kytken­

nän juuri näiden osapuolten välille. Löyhä kytkentä vastaavasti on tehottomampaa, koska kommunikaatiossa tehdään vähemmän oletuksia ja tiedonvälityksessä on enemmän tarvetta metatiedoille, jotka kuvaavat lähetettävää tietoa. (Hohpe, 2003) Väliohjelmistotyyppien hajautetut oliot ovat esimerkki tiukan kytkennän hyödyntä­

misestä. Hajautetuissa olioissa toisen osapuolen oletetaan käyttävän täsmälleen samaa teknologiaa kuin toinen, ja olioita kutsutaan verkon yli samaan tapaan kuin ne olisivat paikallisia. Löyhää kytkentää edustavat puolestaan viestinvälitysratkai- sut, joissa osapuolet eivät kommunikoi suoraan toistensa kanssa, vaan käyttävät tähän viestejä välittävää keskitintä. Viime vuosina suuntaus on ollut selvästi kohti löyhää kytkentää käyttäviä ratkaisuja, koska löyhä kytkentä mahdollistaa tietojär­

jestelmien paremman ylläpidettävyyden ja laajennettavuuden avoimuutensa vuok­

si, vaikka tehokkuudesta joudutaan tällöin tinkimään. (Hohpe, 2003) Synkroninen ja asynkroninen tiedonsiirto

Väliohjelmistojen toiminnan kannalta on tärkeää tarkastella tarkemmin käsitteitä synkroninen ja asynkroninen tiedonsiirto. Kirjaimellisesti synkroninen tiedonsiirto tarkoittaa välitöntä tiedonsiirtoa. Synkronisessa tiedonsiirrossa kaksi tietojärjestel­

mää kommunikoi suoraan toistensa kanssa reaaliaikaisesti. Asynkronisessa tie­

donsiirrossa tietojärjestelmien ei tarvitse olla välittömästi saatavilla, vaan ne ovat toisistaan riippumattomampia. Asynkroninen kommunikaatio toteutetaan käytän­

nössä jonkin välittävän keskittimen, kuten viestijonon, avulla. (Charren-Bost et ai., 1996)

Asynkroninen tiedonsiirto on analoginen perinteisen postin tai sähköpostin kanssa, jossa lähettäjä ja vastaanottaja kommunikoivat jonkinlaisen välivaraston (postilaa­

tikko, sähköpostipalvelin) kautta. Synkroninen tiedonsiirto puolestaan on verratta­

vissa puhelinsoittoon, jossa molemmat osapuolet ovat välittömässä yhteydessä toisiinsa.

Yhteydellinen ja yhteydetön kommunikaatio

Tietoliikenne voidaan jakaa yhteydelliseen ja yhteydettömään kommunikaatioon.

Yhteydellisessä kommunikaatiossa yhteydellä on tietty tila ja usein myös tätä yh­

teyttä varten varatut resurssit. Kommunikaation osapuolet muodostavat siis yhtey­

den ja lähetettävän informaation järjestystä ja perillepääsyä valvotaan. (Comer, 2000) Yhteydellisestä kommunikaatiosta käytetään myös nimitystä request- response (pyyntö-vastaus) -malli. (Linthicum, 2003)

Yhteydettömässä kommunikaatiossa puolestaan yhteyttä ei erikseen luoda (tilaton yhteys), vaan tietoa voidaan osapuolten välillä lähettää välittömästi. Tällöin ei kui­

tenkaan voida taata tiedon perillepääsyä eikä saapumisjärjestystä. Yhteydetöntä ja yhteydellistä kommunikaatiota voidaan kuitenkin käyttää myös yhdessä, kuten esimerkiksi TCP-ja IP-protokollia. (Comer, 2000) Yhteydettömästä kommunikaati­

osta käytetään toisinaan nimeä fire-and-forget (lähetä ja unohda) -malli. (Linthi- cum, 2003)

Integraatiossa yhteydellinen tiedonsiirto on useimmiten synkronista ja yhteydetön tiedonsiirto asynkronista. Näin ei kuitenkaan välttämättä aina ole. (Linthicum, 2003)

Topologiat

Tietotekniikassa topologialla viitataan jonkinlaiseen kuvaukseen, jossa esitetään eri osien sijainti suhteessa toisiinsa. Topologia voidaan ajatella joko fyysisellä tai loogisella tasolla. Integraation yhteydessä topologia käsitetään lähes aina loogise­

na kuvauksena integroitavien järjestelmien välisistä yhteyksistä, joka ei ole riippu­

vainen esimerkiksi alla olevasta fyysisestä verkkotopologiasta. Perustopolo- giatyyppejä on kolme: suorat yhteydet (point-to-point), välittäjä (broker) sekä väylä (bus) (Microsoft, 2004; Butler Group, 2005).

Suorat yhteydet -topologiassa kaikki integroitavat tietojärjestelmät yhdistetään suoraan toistensa kanssa. Tämä johtaa järjestelmien väliseen tiukkaan kytken­

tään. Suorat yhteydet ovat yksinkertainen tapa yhdistää sovellukset ja se toimii melko hyvin, kun sovelluksia on suhteellisen vähän ja tarvittavia yhteyksiäkin on vähän. Suoria yhteyksiä voidaan myös käyttää, kun tiedetään yhteyden pysyvän muuttumattomana pitkään tulevaisuudessa. Muutoin suorien yhteyksien käyttöä ei suositella, koska integroitavien sovellusten määrän kasvaessa kasvaa ylläpidettä­

vien yhteyksien määrä eksponentiaalisesti. Tämän vuoksi suorien yhteyksien käyt­

täminen suuremmissa organisaatioissa on vähentynyt. (Butler Group, 2005)

Välittäjätopologiassa kaikki integroitavat sovellukset ovat yhteydessä keskitettyyn pisteeseen. Näin saadaan aikaan löyhä kytkentä järjestelmien välillä eikä yhteyk­

sien määrä kasva eksponentiaalisesti integroitavien sovellusten määrän kasvaes­

sa. Yhteyksien ylläpito saadaan myös muutoin keskitettyä ja tehostettua suoria yhteyksiä paremmin. Välittäjätopologian suurin heikkous on, että välittäjä saattaa kuormittua, kun kaikki yhteydet kulkevat tämän solmun kautta. Kuormitusongel- maa voidaan helpottaa hajauttamalla välittäjän toimintaa, mutta tällöin puolestaan keskitetty ylläpito saattaa hankaloitua. Välittäjämalli on ollut viime vuosina integ- raatioarkkitehtuurien suosituimpia topologioita erityisesti viestinvälittäjien vuoksi.

(Butler Group, 2005)

Väylätopologiassa muodostetaan kaikille järjestelmille yhteinen kommunikaa­

tiokanava, eli väylä. Välittäjätopologiaan verrattuna väylämalli skaalautuu suoritus­

kyvyltään paremmin, kun integroitavia sovelluksia on paljon. Väylämalli soveltuu myös hajautettuihin ympäristöihin ja palvelukeskeisen arkkitehtuurin toteuttami­

seen. Väylämallin käyttö on näistä syistä vähitellen kasvamassa. (Butler Group, 2005)

3.3 Integraatiostandardit XMLja XSLT

Extensible Markup Language (XML) on dokumenttien kuvauskielistandardi. Se on joukko sääntöjä siitä, miten merkkauskieliä (markup language) tulee luoda. XML- dokumentti on tekstipohjainen tiedosto, jossa kuvataan dokumentin rakennetta, mutta ei oteta kantaa dokumentin esittämiseen. (Harold, 1999)

Integraation kannalta XML:n suurin vahvuus on, että tietotekniikan alalla vallitsee yhteisymmärrys siitä, että XML-muotoiset tiedostot ovat hyvä tiedonsiirtoformaatti.

Todellinen hyöty saatetaan saada irti käyttämällä tietylle alalle luotuja XML- vakiosanastoja. Toisaalta ilman vakiosanastojakin voi XML:ää hyödyntää, koska sen tuki on laaja sekä integraatiotuotteissa että yhä enemmän myös integroitavis­

sa sovelluksissa. (Linthicum, 2003)

Extensible Stylesheet Language Transformation (XSLT) on kieli, jonka avulla XML-tiedostoja voidaan muuntaa toisiksi XML-tiedostoiksi. XSLT on osa Extensi­

ble Stylesheet Language -kieltä (XSL), joka määrittelee XML-tiedostojen muotoilu- tyylejä. XSLT on suunniteltu toimimaan myös itsenäisenä kokonaisuutena, vaikkei se ole tarkoitettu täysin yleiskäyttöiseksi XML-muuntimeksi. (W3C, 1999)

XSLT on oleellinen integraatiotyökalu tilanteissa, joissa integroitavat järjestelmät tukevat XML-tiedostojen lähettämistä/vastaanottamista, mutta näissä ei ole käytet­

ty samaa XML-vakiosanastoa. (Linthicum, 2003) Web Services

Web Services (WS) on joukko XML-pohjaisia teknologioita viestinvälitykseen, pal­

velukuvauksiin ja palveluiden etsimiseen (Lomow, 2004). WS on mikä tahansa palvelu, joka on saatavilla verkon (esim. Internet) yli, käyttää XML-viestejä ja on alustariippumaton (Cerami, 2002).

WS-tekniikoiden avulla tietojärjestelmät tarjoavat palveluita, kuten esitettiin aiem­

min palvelukeskeisen integraation lähestymistavan yhteydessä (luku 2.2). WS tar­

joaa: (Lomow, 2004)

• yleisiä avoimia standardeja palvelurajapintojen kuvauksiin

• riippumattomuutta tietojärjestelmien toteutukseen käytetystä tekniikasta

• laajennettavuutta tietoturvalle, luotettavalle kommunikaatiolle ja transaktioil­

le

• tuen komposiittipalveluille

Keskeisimmät WS-tekniikat ovat (Cerami, 2002):

• WSDL (Web Service Description Language), palvelukuvaukset

• SOAP (Simple Object Access Protocol), kommunikaatiomekanismi

• UDDI (Universal Description, Delivery and Integration), tietokanta WSDL- kuvauksille

Näiden lisäksi on olemassa useita muita WS standardeja, kuten erilaisia tietoturva- laajennuksia: WS-Security, XML Encryption, XML Signature, XML Key Manage­

ment Specification, SAML. (Linthicum, 2003) EDI ja XML/EDI

Electronic Data Interchange (EDI) on standardi määrämuotoiseen binääriseen tie­

donsiirtoon. EDI koostuu kahdesta erillisestä standardista: ANSI-organisaation X12 -standardi ja Yhdistyneiden Kansakuntien EDIFACT-standardi. EDI standar­

dia on käytetty yleisesti jo ennen Internetin yleistymistä sähköisen kaupankäynnin välineenä. EDIn toteutukseen edellytettiin kuitenkin monimutkaisen vaatimusmää­

rittelyn toteuttamista, josta seurasi että monet toteutukset eivät olleet keskenään yhteensopivia (Kihniä, 2003). Viime vuosina integraatiostandardien suuntaus on ollut kohti avoimempia tietoformaatteja, jonka vuoksi EDIn rooli on vähentynyt.

Tämän vuoksi EDIn seuraajaksi on kehitetty XML-pohjainen XML/EDI. (Linthicum, 2003)

XML/EDI:n pyrkimyksenä on ollut siirtää EDI-standardi XML-muotoisiin viesteihin, mutta yleistymistä ei ole tapahtunut (Kihniä, 2003). Syynä tähän on mahdollisesti kilpailevien standardien ebXML ja RosettaNET laajuus ja teollisuuden tuki.

XML/EDI ei ole vahvasti esillä tämän hetken integraatiotuotteissa (Butler Group, 2005).

ebXML

Electronic business XML (ebXML) on OASIS- ja UN/CEFACT-organisaatioiden yhteinen hanke, jossa on kehitetty XML:ään pohjautuva toimialariippumaton avoin sähköisen liiketoiminnan viitekehys (Valtiovarainministeriö 2001). Se on suunnattu lähinnä organisaatioiden väliseen integraatioon (business-to-business, B2B).

Standardi pyrkii määrittelemään menetelmät, joiden avulla organisaatiot voivat löy­

tää toisensa ja suorittaa keskinäistä liiketoimintaa hyvin määritellyillä XML- viesteillä. (Chappell, 2001)

EbXML ei ole vaihtoehtoinen standardi Web Services -tekniikoille, vaan se on en­

nemminkin kokoelma näitä täydentäviä työkaluja organisaatioiden väliseen tiedon­

vaihtoon. Se tarjoaa XML vakiosanastoja, joiden avulla saadaan sovittua Web Services -palvelujen tarkempi muoto, ja tätä kautta integraation pitäisi helpottua.

Ilman tällaisia vakiosanastoja Web Services -palveluiden suurin potentiaalinen hyöty saattaa jäädä kokonaan saavuttamatta. (Chappell, 2001)

EbXML on hankkeena erittäin kunnianhimoinen, koska se pyrkii kattamaan sekä kaikki toimialat että teknologiat. Tämä on samalla ebXML:n suurimpia heikkouksia, koska spesifikaatiossa ei sidota käyttämään mitään tiettyjä menetelmiä ja tekniikoi­

ta riittävän vahvasti vaan ne jätetään suositusten asteelle tai niihin ei oteta ollen­

kaan kantaa. (Rawlins, 2002) Rosetta N et

RosettaNet on sekä organisaation että standardin nimi. RosettaNet-standardi on suurten informaatioteknologiayritysten muodostaman organisaation kehittämä XML:ään pohjautuva sähköisen liiketoiminnan viitekehys (Valtiovarainministeriö 2001). Kuten ebXML, myös RosettaNet pyrkii standardoimaan yhteisen kielen or­

ganisaatioiden väliselle tiedonvaihdolle.

RosettaNet ja ebXML ovat kilpailevia standardeja. RosettaNet on kuitenkin näistä paljon suppeampi, koska se on suunniteltu ebXML:ää enemmän toimialakohtai­

seksi, erityisesti elektroniikkateollisuuden tarpeisiin. Näin ollen RosettaNetin käyttö ei ole mahdollista kaikilla toimialoilla, mutta toisaalta se tuo spesifikaation ebXML:ää konkreettisemmalle tasolle. RosettaNetin taustalla on laaja joukko teol­

lisuuden yrityksiä, jonka vuoksi siitä saattaa muodostua helpommin de facto - standardi kuin ebXML:stä. (Kihniä, 2003)

3.4 Integraatiotapojen yhteenveto

Edellinen luku (luku 2) esitteli integraatiotapojen jaottelua teoreettisella tasolla, jolla ne jaettiin neljään eri lähestymistapaan: informaatio-, palvelu-, prosessi- ja portaalikeskeinen. Monissa integraatiotapauksissa eri näkökulmien välille vedetty raja ei ole selvä, ja usein käytännössä joudutaan yhdistämään eri lähestymistapo­

ja. Yksittäinen lähestymistapa saattaa olla sopiva jos organisaation integraatiotar­

peet ovat vähäiset, ja tällöin luonnollisimmat lähestymistavat ovat informaatiokes- keinen ja portaalikeskeinen. Informaatiokeskeinen ja portaalikeskeinen näkökulma ovat ideologialtaan lähempänä toteutusteknistä tasoa, kun taas palvelukeskeinen ja prosessikeskeinen näkökulma edustavat abstraktimpaa tapaa jäsentää integ­

raatiota. Abstraktimpien näkökulmien toteuttaminen vaatii yleensä enemmän re­

sursseja, ja nämä ovat luonnollisia valintoja silloin, kun organisaatiolla on paljon integroitavia sovelluksia.

Tässä luvussa (luku 3) on käsitelty integraatiota teknisten toteutustapojen kautta.

Teknisesti integraatiota toteutetaan siis väliohjelmistojen avulla, joissa mahdolli­

suuksia on useita. Hajautetut tietokannat, viestinvälitys ja transaktiot ovat välioh- jelmistotekniikoita, joissa toteutus painottuu enemmän varsinaisiin väliohjelmistoi- hin. Etäproseduurikutsut ja hajautetut oliot puolestaan edellyttävät väliohjelmiston lisäksi tukea myös taustajärjestelmältä. Eri väliohjelmistotekniikoiden kirjosta on kehittynyt erityisiä integraatiopalvelintuotteita, jotka pyrkivät monipuolisesti tuke­

maan erilaisia väliohjelmistotarpeita. Näin ollen ne tarjoavat yksittäisiä ratkaisuja selvästi suuremman hyödyn.

Integraation lähestymistapojen ja toteutustekniikoiden yhteensovittamisessa on olemassa omat haasteensa. Teoreettisten lähestymistapojen avulla saadaan tyy­

pillisesti paljon parempi käsitys integraation päämääristä ja näin ollen päästään helpommin lopputulokseen, josta organisaatio hyötyy eniten. Näiden tekninen to­

teutus vaatii kuitenkin soveltamista erityisesti prosessi- ja palvelukeskeisten lähes­

tymistapojen kohdalla, joihin ei ole vielä olemassa vakiintuneita menetelmiä. Muu­

toinkaan ei toteutustekniikoita ja lähestymistapoja voida yhdistää toisiinsa yksi yh­

teen, minkä vuoksi integraatiopalvelintuotteet ovat hyvä lähtökohta jokaisen lähes­

tymistavan tukemiseen laajan tekniikkatuen vuoksi.

4 Tietojärjestelmäarkkitehtuurit

Sovellusintegraatioarkkitehtuurin suunnittelu vaatii sovellusintegraatio-osaamisen lisäksi tietojärjestelmäarkkitehtuurien ymmärrystä, etenkin kun integraatioarkkiteh- tuureihin keskittyvää lähdeaineistoa ei yhtä laajasti ole saatavilla. Tämän luvun tarkoituksena on perehtyä näin ollen yleisemmällä tasolla tietojärjestelmäarkkiteh­

tuurien suunnitteluun ja arviointitapoihin.

Tietojärjestelmäarkkitehtuuri on ohjelmiston tai muun tietojärjestelmän rakenteen kuvaus, joka koostuu komponenteista, komponenttien ominaisuuksista sekä näi­

den välisistä suhteista. (Bass, 2003)

Vastaavia tietojärjestelmä- tai ohjelmistoarkkitehtuurin määritelmiä on lukuisia, mutta vielä tärkeämpää on ymmärtää yleiset arkkitehtuurien tavoitteet (Clements, 2002; Smolander, 2003):

• Arkkitehtuuri on kommunikaatioväline eri osapuolten välillä. Arkkitehtuurin avulla voidaan muodostaa yhteinen näkemys ja lähtökohta siitä, millaista järjestelmää ollaan rakentamassa.

• Arkkitehtuuri on ilmentymä ensimmäisenä tehdyistä suunnittelupäätöksistä.

Arkkitehtuurin avulla osoitetaan järjestelmälle suunnitteluvaiheessa asetet­

tuja ominaisuuksia ja vaatimuksia.

• Arkkitehtuuri on muunnettavissa oleva ja uudelleenkäytettävä koko järjes­

telmän abstrakti esitysmuoto. Arkkitehtuuri ei ole sidottu vain tiettyyn toteu­

tettavaan järjestelmään vaan se on yksinkertainen malli järjestelmän kom­

ponenteista, jota voidaan käyttää useiden eri järjestelmien suunnittelussa.

4.1 Arkkitehtuurikuvaukset

Arkkitehtuurikuvaukset (architecture description, AD) ovat tapa, jolla arkkitehtuuri kuvataan eri osapuolille. Arkkitehtuureja kuvataan usein yksinkertaisilla diagram­

meilla, joissa komponentit ja näiden väliset suhteet on piirretty. Usein näissä dia­

grammeissa kuvan semantiikka on kuitenkin jätetty määrittelemättä ja seuraukse­

na tällainen arkkitehtuurikuvaus epäonnistuu antamaan vastausta moniin oleellisiin kysymyksiin, kuten: Mitä komponentit ovat? Miten komponentit käyttäytyvät ja mis­

tä ne ovat riippuvaisia? Mikä on yhteyksien merkitys?

(Clements, 1996)

Tämän seurauksena ovat syntyneet formaalit arkkitehtuurikuvauskielet (Architectu­

re description languages, ADL). ADL-kielten lähtökohtana on muodostaa sovittu semantiikka arkkitehtuurikuvauksille samaan tapaan kuin luonnollisten kielien kie­

lioppi. (Clements, 1996)

ADL-kieliä on olemassa useita, joista tunnetuimpia ovat Acme ja Wright. Näiden kielten avulla voidaan arkkitehtuureja kuvata järjestelmällisesti. Muodollisten ADL- kielien käyttö ei kuitenkaan ole yleistynyt organisaatioissa, koska näiden kielien oppiminen ja käyttäminen vaatii aikaa. Suosituimmaksi kuvauskieleksi onkin levin­

nyt Unified Modeling Language (UML). UML:n soveltuvuus ADL-kieleksi on ollut kiistanalaista, koska sitä ei ole suunniteltu alun perin arkkitehtuurikuvauksia ajatel­

len. UML:n suosio perustuu lähinnä siihen, että se on notaatioltaan yksinkertai­

sempi ja jo ennestään laajasti käytössä muussa ohjelmistojen mallintamisessa.

UML versiossa 2.0 onkin kiinnitetty erityisesti huomiota UML:n hyödyntämiseen arkkitehtuurikuvauksissa ja UML symboleita on muokattu tähän sopivammiksi.

(Sunghwan, 2004; McGovern, 2004)

UML-kielen kehityksestä vastaa Object Management Group (OMG). UML 1.x ja UML 2.0 kielten spesifikaatiot ovat vapaasti saatavilla OMG:ltä.

(Object Management Group, 2005)

Arkkitehtuurikuvauksiin liittyen on olemassa myös IEEE 1471 standardi. Tämä standardi määrittelee arkkitehtuurikuvausten sisältövaatimukset. Standardin kes­

keisimpiä käsitteitä ovat näkymät (view), näkökulmat (viewpoint) ja osapuolet (sta­

keholder).

• Osapuolet ovat järjestelmään liittyviä toimijoita, kuten esimerkiksi järjestel­

män tilaaja, tekijä tai loppukäyttäjä.

• Näkökulma on määritelty lähtökohta näkymälle (esim. näkymän osapuolet, vaatimukset, kuvaustapa)

• Näkymä on arkkitehtuurikuvauksessa näkyvä esitysmuoto tietystä näkö­

kulmasta.

(Hilliard, 2001)

Käytännössä ajatusmalli on sama kuin perinteisessä rakennustekniikassa, jossa rakennuksen piirrokset laaditaan eri osapuolille (julkisivu, pohjapiirros, putket, säh­

köt, ym.). (Maier, 2001)

Varsinaiset kuvausten sisältövaatimukset IEEE 1471 :ssä ovat tiivistettynä (Kuva 4-1) (Hilliard, 2001):

• Kuvauksen rakenne riippuu eri osapuolten eri intresseistä

• Kuvauksen on otettava kantaa eri osapuolten kaikkiin mielenkiinnon kohtei­

siin

• Kuvaus muodostuu yhdestä tai useammasta näkymästä siten, että jokainen näkymä kuvaa järjestelmän kokonaan tietystä näkökulmasta tarkasteltuna

• Näkymät ovat modulaarisia siten, että näkymä voi koostua yhdestä tai use­

ammasta moduulista

Kuva 4-1 esittää standardin konseptuaalisen tietojärjestelmäviitekehyksen.

Mission

fulfills 1..*

inhabits

is addressed to participates in

used to

participates in

establishes methods for Stakeholder

Model

Rationale

Viewpoint Environment

Kuva 4-1 IEEE 1471 konseptuaalinen viitekehys (IEEE, 2000)

Näkökulmien, näkymien ja osapuolten käyttäminen ei ole uusi idea, vaan vastaa­

via ajatuksia on esitetty usein ennen IEEE 1471 standardiakin. Esimerkiksi Philip­

pe Kruchten on määritellyt arkkitehtuurien "4+1 näkökulmat”, joita voidaan sovel­

taa yleensä tietojärjestelmäarkkitehtuurien kuvauksissa (Kruchten, 1995):

• Looginen näkökulma - järjestelmän toiminnallisuus, järjestelmän palvelut, kuvaa yleensä luokat ja niiden interaktiot

• Kehitysnäkökulma - sovelluskehittäjien näkökulma, joka kuvaa ohjelmien rakentamista

• Prosessinäkökulma - suorituskyky, laajennettavuus, ym. - miten toiminnalli­

suudet liittyvät joihinkin ei-toiminnallisiin vaatimuksiin

e Fyysinen näkökulma - luotettavuus, tietoliikenne, laitteet, ym.

• Viides näkökulma muodostuu neljän näkökulman toimintaa kuvaavista ske­

naarioista ja käyttötapauksista

Vastaavaa näkökulmajaottelua on käytetty myös muissa lähteissä (Kazman, 2002). Kruchtenin 4+1 näkökulmien lisäksi muita tunnetumpia lähestymistapoja on (Garland, 2002):

ISO Reference Model for Open Distributed Processing (RM-ODP) näkökulmat, Bass arkkitehtuuriset rakenteet sekä Hofmeister ohjelmistoarkkitehtuurinäkymät.

4.2 Arkkitehtuurimallit

Tietotekniikan alalla mallit (patterns) ovat ohjelmistotuotannossa käytettäviä kollek­

tiivisesti löydettyjä ja muotoutuneita käytäntöjä. Ne ovat hyväksi havaittuja tapoja tietojärjestelmien suunnitteluun ja niillä kuvataan tietojärjestelmien ominaisuuksia.

Ne määrittelevät järjestelmille komponentteja, rooleja sekä näiden välisiä suhteita.

(Buschmann, 1996)