Tietoja Ville Tenhunen

The Project Manager. IT Center of the University of Helsinki.

Kuinka valita integroitavat palvelut?

Yksi integraatioryhmän käynnistämisen kannalta keskeinen kysymys on se, miten olemassa olevat tietojärjestelmät integraatioineen saadaan käyttämään hyväkseen palveluväylää?

Tähän voidaan ajatella olevan kaksi erilaista lähestymistapaa:

  • Arkkitehtuuri- ja MDM-lähtöinen malli, jossa ensin toteutetaan MDM-määrittelyt ja katsotaan mitä tietoja tietoarkkitehtuuriin kuuluu ja sen jälkeen integroidaan tietojärjestelmistä nämä tiedot saataville palveluväylälle. Kun tämä on tehty – tai elävässä elämässä osin samaan aikaan – käynnistetään tietoja käyttävien järjestelmien integraatioiden muutostyöt.
  • Toimintalähtöinen malli, jossa etsitään sopivat projektit, jotka tarvitsevat integraatioihinsa väylän kautta määriteltäviksi soveltuvia tietoja. Kun projektit ja niiden tarpeet on tunnistettu ja määritelty, toteutetaan integraatiot palveluväylän avulla ja haetaan uudet tiedot väylälle, mikäli ne eivät siellä jo ole.

Näitä malleja käytännössä erottaa se, miten ja mistä palveluväylän kehittäminen saa kulloisessakin tapauksessa liikevoimansa. Saako se sen arkkitehtuurista ja hallintamallista vai toiminnasta ja sen kehittämisestä?

Vastaus on parhaassa tapauksessa se, että integraatioiden siirtäminen palveluväylälle lähtee liikkeelle sekä toiminnoista että arkkitehtuurista ja jatkumon kumpaakin päätä voidaan kehittää yhtäaikaa.

Kuitenkin viestinnän ja motivoinnin kannalta on tärkeää käynnistää tekemistä toimintalähtöisesti ja pyrkiä siihen, että integraatioilla voidaan palvella suoraan käyttäjiä tai heidän käyttämiään palveluita. Siksi olisi hyvä löytää sopivia ja kattavia projekteja, joita integraatiopalvelu voi tukea.

Näin toimittaessa saattaa jossain vaiheessa tulla vastaan harmaa vyöhyke, jossa jokin tai jotkin MDM:n ydintiedoiksi määrittelemät kokonaisuudet eivät ole hallitusti palveluväylältä saatavissa (koska niiden sinne organsoimiseksi ei ole löytynyt sopivaa projektia). Tämä ongelma on toisisijainen toiminnallisiin tarpeisiin katsottuna, mutta pitemmällä aikavälillä hoidettavaksi tuleva kysymys.

Kun palveluväylää pistetään pystyyn, kannattaa siis etsiä ja löytää hyviä projekteja.

Toinen noita kahta näkökulmaa erottava tekijä voi olla se, miten kehitystoimissa suhtaudutaan eri arkkitehtuuriperiaatteisiin. Onko jokin periaate jossain tilanteessa tärkeämpi kuin toinen? Niistä vähän tuonnempana.

Puolitieltä eteenpäin

Kun integraatioryhmän käynnistämiseen tähtäävää projektia on tehty kohta puoli vuotta, on hyvä aika hieman tarkastella tekemistä ja sen käänteitä. Tarkastelukulma on projektipäällikön näkökulma ja tekniset yksityiskohdat jätetään tästä nyt pois. Koitetaan vastata kysymykseen:”Miten projekti on edennyt?”

Projektissa on tehtävät jaettu käytännössä kolmeen osaan;

  1. integraatioalustan asennukset, ylläpito ja huoltotoimet
  2. pilottiprojektin integraatiot ja liittymät
  3. arkkitehtuuri, dokumentaatio, projekti, kompetenssit

Alustan osalta on edetty jo siihen vaiheeseen, että ensimmäiset alustaversioiden päivitykset on jo tehty. Kun käytetään kahdennettua toimintaympäristöä, päivitykset voidaan tehdä kuten ne normaalisti tehtäisiinkin.

Apache ServiceMix-alustan ylläpito ja toteutus on ollut varsin vakaata ilman suurempia ongelmia. Tietokantojen klusteroinnin kanssa on hieman jouduttu työskentelemään, mutta sekin sektori näyttää voitetulta.

Pilottiprojektin liittymien kanssa on töitä pitänyt tehdä hieman enemmänkin. Yksi osa-alue on ollut liitymissä kulkevien tietojen ja järjestelmien välisten mappausten määritteleminen.

Kun kysymyksessä on suoraan toimintaprosesseihin vaikuttavat integraatiot, niin tietojen ja niiden liikuttelun määrittely vaatii toimintaprosessien ja tietojen omistajien vahvaa panosta. Toimintaprosessien omistajat ovat olleet käsillä olevien integraatioiden integraatioiden osalta esimerkillisen sitoutuneita, mikä käytännössä tekee mahdolliseksi keskitetyn palveluväylän käytön integraatioissa.

Käytännössä pilotti-integraatioiden toteutus on vaatinut usean osapuolen yhtäaikaista toimintaa ja yhteistyötä. Siinä on omat haasteensa sekä viestinnän, että asioiden joustavuuden kannalta, mutta tässäkin on pyritty toimimaan mahdollisimman suoraan, jolloin asioilla on taipumus edistyä.

Yksi olennainen asia projektipäällikön näkökulmasta on ollut se, että toisin kuin ilmeisesti helposti ajatellaan, työskentely ServiceMixin kaltaisen koodaamista edellyttävän työkalun kanssa ei ole luonteeltaan aivan samalaista kuin jonkun ohjelmiston tai sovellusalustan kanssa koodaaminen.

Palveluväylän työkalua voi toki käyttää kuin sovellusalustaa, mutta voidaan valita myös selvästi omaa koodia vähemmän vaativa strategia eri komponenttien kanssa eli annetaan osa töistä palveluväylän komponenttien tehtäväksi. Toisaalta tämä vaatii kuria tekemiseen, mutta myös antaa mahdollisuuden vähentää oman koodin määrää.

Toinen asia, jota palveluväylä kehitystöissä muuttaa, on järjestelmäkehitykseen liittyvien integraatioiden toteutuksen periaatteet. Sovellusta ei enää tehdä päästä päähän niin, että se hoitaa kaiken tiedon kokonaisina paketteina suuntaan ja toiseen. Järjestelmät luovuttavat osa omasta toiminnallisuudestaan väylälle, joka voi toimia asynkronisesti ja siten, että se hajottaa saamansa paketit tiedoiksi, joita välitetään sovittuihin paikkoihin.

Kehittäjillä ei ole välttämättä aivan samanlaista hallintaa järjestelmän tekemisiin kuin point-to-point -integraatiostrategialla toimittaessa.

Eri yhteyksissä vastaan tulleita linjattavia kysymyksiä ovat olleet mm.

  • Mitkä palvelut väylä tarjoaa kehittäjille?
  • Kuka hallinnoi väylää ja voivatko kehittäjät tehdä väylälle (ts. sen testiympäristöön) omia testejään ja sovelluksiaan?
  • Tehdäänkö kyselyt reaaliaikaisena vai eräajoina ja mitä kumpikin toimintatapa teknisesti edellyttää?
  • Tallennetaanko väylälle dataa esimerkiksi välimuistiin?
  • Mitä formaattia, protokollaa tms. integraatiossa käytetään ja miten ratkaisu neuvotellaan kunkin integraation kohdalla sellaiseksi, että integraatiopalvelun tarvitsee hallita mahdollisimman vähäinen määrä erilaisia teknologioita ja samaa asiaa tekeviä rajapintoja?
  • Missä tehdään sovitut muunnokset tietoihin?
  • Kuka vastaa tietojen mappaustauluista ja minne taulut sijoitetaan ylläpidettäväksi?
  • Missä tarkistetaan siirrettävien tietojen oikeellisuus?
  • Miten häiriötilanteet käsitellään eli mihin ongelmalliset viestit siirretään ja miten ne hoidetaan?
  • Kuinka varmistetaan, että tietoja ei voida manipuloida väylällä?
  • Päivittyvätkö palveluväylään liittyvien järjestelmien tiedot push- vai pull-menetelmällä eli miten tiedonsiirto käynnistetään?
  • Tehdäänkö järjestelmien välisiä integraatioita väylän avulla vai palveluita, joita loppukäyttäjät käyttävät?
  • Mitkä ovat keskeiset tietoturvakysymykset ja vastaukset niihin?
  • Mitkä ovat suorituskykyvaatimukset ja kuinka niitä eri tilanteissa mitataan?
  • Mitä kaikkea täytyy dokumentoida?

Kaikkiin näihin – sekä muutamiin muihin – on projektissa löytynyt jonkinlainen vastaus tai ainakin tapa etsiä vastauksia, mutta esimerkiksi tietoturva on luonteeltaan liikkuvaan maaliin ampumista, jolloin nk. valmista ei tule koskaan.

Yksi osa integraatioryhmän toiminnan käynnistämistä on sen sitominen kokonaisarkkitehtuuriin ja arkkitehtuuriperiaatteisiin.

Ydintietojen hallinta on keskeinen lähestymiskulma siihen mitä tietoja väylän välitettäväksi kannattaa ottaa. Johtava ajatus on se, että vaikka palveluväylällä olisi millaiset sääntömoottorit tai monitoroinnit tahansa, se ei itsessään paranna tiedon laatua, jos sisään tulevan tiedon laatu on alhainen. Tiedon laatu on keskeinen syy miksi integraatiopalvelua kannattaa työstää.

Kokonaisarkkitehtuurista ja koko organisaatiota – integraatiopalvelun kohdalla yliopistoa – koskevista arkkitehtuuriperiaatteista on omana osanaan lähdetty johtamaan integraatiotoiminnan arkkitehtuuriperiaatteita. Niitä tarvitaan vastausten etsimiseen sellaisiin kysymyksiin, jotka eivät ole vielä tulleet vastaan sekä saamaan aikaan johdonmukaisen toimintatavan.

Arkkitehtuuria on tietysti sekin, että pyritään vakioimaan esimerkiksi rajapintateknologiat ja määrittelemään järjestelmäarkkitehtuurin osaset. Nämäkin ovat johdettavissa arkkitehtuuriperiaatteista.

Integraatiopalvelu edellyttää vahvaa dokumentointia, koska asiat on pysyttävä jäsentyneesti kertomaan muille kehittäjille, projekteille, arkkitehtuurista vastaaville sekä organisaation strategiaa johtaville päälliköille. Toisaalta, mitään ei kannata dokumentoida useaan kertaan tai turhaan. Jokaiselle dokumentille on löydettävä peruste, muuten dokumentaation tuottamisesta vastaavien motivaatio työstää dokumentaatiota lepää turhan pehmeällä perustalla.

Tämäkin olennainen kysymys on jo esitetty ennen projektin puoliväliä:”Miten integraatiotoimintaa jatketaan sen jälkeen kun ryhmän käynnistämiseen liittyvä projekti on ohi?”

Tarkkaa vastausta tähän on vielä turhan varhaista antaa, mutta jo tässä vaiheessa on selvää, että käynnistysvaiheessa toteuttavista integraatioista huolehtimiselle löytyy järjestäytynyt tapa myös projektin päättymisen jälkeen ja hyvin todennäköisesti sitä kutsutaan integraatiopalveluksi.

Oma haasteensa on siis se, miten projektin tuotokset siirretään linjaorganisaatioon ja tätä haastetta kannattaa käsitellä kohtuullisen varhaisessa vaiheessa projektia.

Nyt käsillä oleva projekti jatkuu vuoden loppuun ja sillä on syksyllä edessä monia mielenkiintoisia kysymyksiä ja uusia liittymiä.

Integraatiopalvelua-blogin tarkoitus

Kohti SOA:aa

Tämän blogin ideana on viestiä siitä miten laitetaan pystyyn organisaation integraatiopalvelu ja mitä näkökulmia siihen liittyy.

Helsingin yliopiston tietotekniikkakeskuksessa on käynnistynyt projekti, joka kantaa nimeä “Intergaatioryhmän käynnistäminen”. Projekti kestää vuoden 2013 loppuun ja sen visio on esitetty seuraavasti:

Projektin valmistuttua tietotekniikkakeskuksella on käytössään palveluväylä, siihen liittyvät toimintatavat ja rajaukset määriteltynä, palvelu kuvattuna Tietotekniikkakeskuksen palveluna, palvelua tuottava integraatioryhmä koottuna ja nimettynä, sen toiminta järjestettynä ja ensimmäiset ESB-pilottitoteutukset valmiina.

Projekti tuottaa käyttöön otetun palveluväylän, sen dokumentaation ja arkkitehtuurikuvaukset, käytön ohjeistuksen ja integraatiopolitiikat, ensimmäiset projektitoteutukset sekä toiminnan evaluoinnin. Ensimmäisen vaiheen painopiste on yliopiston ydintietoihin liittyvissä integraatioissa ja niiden toteutuksessa.

Miksi moinen projekti?

Aikojen saatossa yliopiston tietotekninen infrastruktuuri on kehittynyt kulloisenkin ajan parhaiden käsitysten ja ideoiden mukaisesti eteenpäin. Aikaa myöten monimutkaisuus on kuitenkin lisääntynyt ja samalla kehittämiselle asetetut vaatimukset lisääntyneet.

Tavallaan on tullut aika tehdä uudet arkkitehtuurilinjaukset ja pyrkiä järjestämään asiat uudelleen, nykyaikaan sopivammalla ja hallittavammalla tavalla. Tieto pitää saada entistä paremmin haltuun ja hyödynnettäväksi.

Integraatioryhmä ei tätä kaikkea yksin voi järjestää, vaan kyseessä on monia tahoja koskettava arkkitehtuurin kehittämiseen tähtäävä hanke. Hyvin tärkeässä osassa ovat kaikki ne sidosryhmät, joita tietojärjestelmien tai tietojen integrointi jotenkin koskettaa.

Jos joku haluaa nähdä tässä kaikessa kehityksen kohti SOA-ajattelua, ei välttämättä ole väärässä. Ehkä se SOA ei ole sitä samaa kuin muualla, mutta sen kaltainen ajattelutapa muutoksen taustalla on nähtävissä.

Tästä kaikesta on tässä blogissa tarkoitus kirjoittaa.