Millainen on tyypillinen integraatioprojekti? – “Laadukkaat toimintamallit auttavat asiantuntijaa keskittymään oleelliseen”

tyypillinen integraatioprojekti Devikoneella

Kun uusi integraatioprojekti pyörähtää Devikoneella käyntiin, on integraatiokehittäjille selkeät sävelet siihen, miten homma tulee etenemään. Näin voit asiantuntijana keskittyä siihen, mitä osaat parhaiten: asiakkaan arjen helpottamiseen integraatioiden avulla. Millaisia vaiheita tyypillinen integraatioprojekti oikein sisältää?

Ennen kuin paneudumme itse integraatioprojektin kulkuun ja yksityiskohtiin, selvitetäänpä vastaus kysymykseen: millainen on tyypillinen integraatioprojekti?

Monelle kokeneemmallekin ohjelmistokehittäjälle saattaa nimittäin tulla yllätyksenä, miten “yksinkertaisia” integraatioprojektit ovat.

“Pääosa integraatioista on luonteeltaan vesiputousmallisia projekteja. Siinä siis tiedetään, että on lähde- ja kohdejärjestelmä, jonka välillä pitää siirtää tietoa ennalta määriteltyjen sääntöjen mukaisesti”, sanoo Tuomas Palenius, CTO ja yksi Devikoneen perustajista. Tästä esimerkkinä voisi olla esimerkiksi kahden järjestelmän välille API-rajapinnan tekeminen.

Integraatiokehittäminen eroaakin perinteisestä ohjelmistokehittämisestä siinä, että asiakkailla ei usein ole erityisiä räätälöintitoiveita tai monia käyttäjä- ja kokemustasoja.

“Integraatiotyössä on käytössä hyvin kaavamaiset mallit, joka helpottaa myös sitä, että pystymme antamaan hyvinkin tarkat työaika-arviot, eli integraatiot ovat enemmän tiedettä kuin taidetta”, Tuomas kertoo. Näin kehittäjälläkin on selkeämmät sävelet siitä, miltä työpöytä tulee näyttämään.

Kun ohjelmistokehittäjä hyppää Devikoneen matkaan, häntä odottavat kattava perehdytys, jota usein kylläkin suoritetaan oikean asiakasprojektin ohella.

“Täällä asiantuntija pääsee tekemiseen kiinni mahdollisimman pian”, Tuomas toteaa. 

Integraatioprojektin aloitus – hyvin suunniteltu on puoliksi tehty

Ennen integraatioprojektin varsinaista aloitusta, on tehty selvitys asiakkaan muista järjestelmistä, kartoitettu tietovirtoja eri järjestelmien välillä, selvitetty asiakkaan tilannetta ja toiveita sekä kerätty lista yhteyshenkilöistä.

Sen jälkeen alkaa varsinainen suunnitteluvaihe asiakkaan kanssa.

“Tähän vaiheeseen osallistuvat kaikki oleelliset henkilöt eli se, joka koodaa integraatioita ja suunnittelee arkkitehtuurin”, Tuomas sanoo ja jatkaa: “Meillä on kuitenkin tavoitteena kouluttaa devikonelaiset niin, että heillä olisi taidot hoitaa molemmat roolit.”

Jokaisella uudella devikonelaisella on apunaan Integraatioakatemia perehdytyskäytössä, jossa kerrotaan kattavasti käyttämistämme avoimen lähdekoodin integraatiovälineistä mm. suunnittelun, koodauksen ja testauksen näkökulmasta. Lisäksi akatemiassa käydään läpi erilaisia integraatioarkkitehtuureja. “Ne auttavat alkuun tuomaan kontekstia ja ymmärrystä siitä millä periaatteilla ja toimintamalleilla teemme integraatiotyötä”, Tuomas sanoo.

Ensimmäiseen projektiin – ja toki tuleviinkin – hyppäämistä helpottavat meidän sisäiset projektipohjat ja toimintamallit. Tyhjästä ei missään nimessä tarvitse lähteä. “Kehittäjillä ei ole – hyvässä mielessä – taiteilijan vapautta, koska olemme valinneet selkeän näkökulman miten Devikoneella toteutetaan integraatioprojekteja”, Tuomas kertoo hymyillen.

Miksi näin?

“Työn laatu pysyy parempana ja tekijän on mielekkäämpää keskittyä itse ongelman ratkaisuun, kun toimintamalleja ei tarvitse lähteä keksimään ja luomaan tyhjästä. Voit noudattaa teknistä suunnitelmaa ja valittuja kaavoja”, Tuomas kertoo ja jatkaa: “Näin varmistetaan, että integraatiot kestävät aikaa ja dokumentointi hoituu jokaisessa projektissa samalla tavalla.”

“Työn laatu pysyy parempana ja tekijän on mielekkäämpää keskittyä itse ongelman ratkaisuun, kun toimintamalleja ei tarvitse lähteä keksimään ja luomaan tyhjästä”

Projektin aloitusvaiheessa on tärkeä asiakkaan yhteyshenkilöiden lisäksi hoitaa myös erilaiset teknisten yhteyksien avaukset, tietovirtakaaviot, keskusteluyhteydet eri toimittajien suuntaan, käyttöoikeudet eri järjestelmiin, ja käydä läpi olemassa olevat mäppäysdokumentit.

Selkeät toimintamallit ja projektivaiheet auttavat kehittäjää onnistumaan

Kun suunnitteluvaihe on hoidettu, alkaa varsinainen hauskuus eli lähdetään koodaamaan itse integraatiota. Se tarkoittaa yhteyksien rakentamista lähde- ja kohdejärjestelmiin ja mäppäyksien toteuttamista. “Meillä on integraatioita varten olemassa vakioidut hyväksi todetut ja testatut kooditemplaatit, joiden avulla pääsee nopeasti alkuun”, Tuomas sanoo. 

Työhön kuuluu yhteydenpito asiakkaan kanssa sekä työn touhussa vastaan tulevien esteiden purkaminen. Näitä voidaan puida yhteisissä sisäisissä palavereissa ja apuna on muun muassa Tuomas. 

“Tärkeintä minulle on rakentaa asiantuntijalle mahdollisuus päästä flow-tilaan työn tekemisessä.” 

“Tärkeintä minulle on rakentaa asiantuntijalle mahdollisuus päästä flow-tilaan työn tekemisessä. Jos päivä päättyy ratkaisemattomaan ongelmaan, se voi jäädä vaivaamaan”, Tuomas kertoo. 

Projektien kulmakiviä ovat aina päivittäiset palaverit, joissa käydään erilaisten asiantuntijakokoonpanojen kesken käsillä olevat tiedot ja niiden pohjalta luodaan toteutustaskeja Trelloon. Yksittäisen integraation taustalla on aina suunnitteludokumentti, ja tarpeen mukaan sitä tarkastellaan, tarkennetaan tai päivitetään riippuen mitä asioita toteutuksessa ilmenee. Toteutus ja suunnitelma synkronoidaan päivittäin päivittäisessä palaverissa.

Kun integraatioprojekti alkaa olla kasassa, siirrytään testausvaiheeseen. Tämä tapahtuu usein asiakkaan testiympäristöissä. Kun testausta on tehty tarpeeksi, se siirretään tuotantoympäristöön. “Tuotantoon vieminen on kaavamainen prosessi, jonka jälkeen testataan lisää ja tarkastellaan tuloksia”, Tuomas kertoo. 

Koko projektin aikana työtä myös dokumentoidaan huolella. Laatuperiaatteena on, että toisen ulkopuolisen kehittäjän pitäisi pystyä ottamaan integraatio työn alle versionhallinnasta. Se tarkoittaa, että dokumentointi on ajantasalla, koodit on kommentoitu riittävällä tavalla, sovittuja tyyliohjeita on noudatettu ja testit ovat olemassa ja kaikki toimivat. Ennen tuotantoonsiirtoa integraatioille on tehty laaduntarkastus, jolloin laatulistalta tarkistettu, että sovitut asiat ovat tehty.

Ajallisesti mediaanina voisi sanoa, että yksi integraatioprojekti on paketoitu noin viidessä työpäivässä. Tuon rinnalla asiakkaalla voi olla muitakin integraatioprojekteja käynnissä yhtäaikaisesti. Päällekkäistä työtä eri projektien välillä siis saattaa ajoittain olla, mutta tavoitteena on kuitenkin se, että devikonelaisilla olisi vastuullaan yksi asiakas kerrallaan.

“Se ei edistä kehittäjien ydintyötä, jos pallottelee monen eri projektinhallintaan liittyvän asian välillä”, Tuomas sanoo.

Projekti paketissa – mitä tästä jäi käteen?

Kun yksi integraatioprojekti on saatu paketoitua, on aika pysähtyä ja arvioida, miten toteutettu työ sujui. Joidenkin asiakkaiden kanssa saatetaan myös sopia erillisistä ylläpitosopimuksista, joka tarkoittaa rakennettujen integraatioiden valvontaa.

“Se on varmaa, että jokaisen rakennetun integraation jälkeen osaaminen kehittyy, vaikka sitä ei juuri siinä hetkessä ymmärtäisi”, Tuomas toteaa. Siispä, vaikka integraatioiden rakentaminen saattaakin olla suoraviivaista puuhaa, on jokainen asiakas omanlaisensa ja jokainen integraatio uniikki heidän haasteidensa kanssa. Osaamisen kehittymistä ei voi estää.

Kuten integraatioarkkitehtimme Kari Aarniokin totesi puolen vuoden devikonelaisuuden jälkeen: “Olen oppinut puolessa vuodessa Devikoneella enemmän kuin sitä ennen moneen vuoteen.”

👉Jos siis haluat viedä ohjelmistokehityksen osaamisesi uusille urille, tutustu urasivuihimme ja ota yhteyttä niin tutustutaan tarkemmin!

Lue lisää työstä integraatioiden parissa:

Miten kokenut integraatiokehittäjä voi kasvattaa ammatillista osaamistaan Devikoneella?

Tuomas halusi perustaa parhaan työpaikan niille, jotka haluavat rakentaa syväasiantuntijuuden integraatioista

linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram