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ä.