FI
SV
ENDigitaalisten kehityshankkeiden on edettävä entistä ketterämmin, jolloin myös integraatiotekemisen on oltava entistä tiiviimmin mukana kehityksessä. Perinteisestä integraatioiden hallintamallista ollaan siirtymässä hajautettua toimintamallia tukevaan federoituun ICC-malliin.
Perinteisen integraation hallintamallin haasteet modernissa maailmassa
Perinteisesti integraatiotyö on organisoitu yrityksissä integraatiokeskuksen (Integration Competency Center, ICC) alle. Tämän keskitetyn toiminnon tarkoitus on ollut vastata kaikesta integraatiokehityksestä, ylläpidosta sekä arkkitehtuurista ja hallinnosta. Uudet integraatiot tilataan ICC:ltä, joka määrittelee, suunnittelee ja toteuttaa ne sekä vie tuotantoon ja hoitaa ylläpidon.
Digitalisaatio on kuitenkin kasvattanut kehitysprojektien tarvetta tuottaa arvoa nopeasti. Kuukausien sijaan näkyvää tulosta halutaan saada viikoissa iteraatio kerrallaan. Muutoksia tapahtuu nopeasti.
Olemmekin viime aikoina käyneet asiakkaidemme kanssa keskusteluita siirtymisestä perinteisestä keskitetystä ICC-mallista moderniin hajautettua toimintamallia tukevaan ICC-malliin (Federated ICC), jossa asiakkaan eri digitalisaatiohankkeiden kehitystiimit tulevat mukaan integraatioiden kehittämiseen. Tässä taustalla on yleensä nopeasti muuttuvan maailman vaatimukset tehdä digitaalisten kehityshankkeista entistä ketterämpiä ja nopeampia, mitä myös integraatiotekemisen tulee hyvin tukea.
Perinteisellä keskitetyllä ICC:llä on haasteita vastata tähän muutokseen. Integraatiotöiden määrän ja vaaditun nopeuden kasvaessa ICC uhkaa jäädä digitalisaatioprojektien pullonkaulaksi.
Uusien iPaaS-alustojen käyttöönoton yksi motivaatio onkin mahdollistaa integraatioiden tekeminen myös sovellusten kehitystiimeille, jotta digitalisaation myötä alati lisääntyvä integraatiotyö saadaan hajautettua keskitetyn integraatiotiimin ulkopuolelle. Tämä mahdollistaa ketteryyden ja tekemisen skaalautuvuuden. iPaaS-alustat tarjoavat usein hyvät työvälineet tällaiseen monitiimiympäristöön sisäänrakennetun keskitetyn käyttöliittymän, roolipohjaisen käyttäjänhallinnan ja helppokäyttöisten kehitystyökalujen kautta. Enää yksinkertaisten integraatioiden rakentamiseen ei välttämättä tarvita pitkää kokemusta integraatiovälineistä.
Hallittua ketterää kehittämistä – kehitystiimit keskiössä
Keskitetyn integraatiokeskuksen sijaan integraatiokehitystä tehdään eri puolella organisaatiota olevissa sovelluskehitystiimeissä (LOB team kuvassa). Tiimit voivat olla projektikohtaisia tai esimerkiksi liiketoimintayksikkökohtaisia. Kaikki tiimit käyttävät samaa iPaaS-alustaa, mutta luvitettuna niin, että he pääsevät muokkaamaan ainoastaan omia integraatioitaan ja näkemään niiden lokitiedot.
Yrityksen eri kehitystiimeissä integraatio-osaaminen on kuitenkin todennäköisesti hyvin eri tasoista. Jotkut tiimit oppivat nopeasti uusia teknologioita ja haluavat heti lähteä toteuttamaan integraatioita itse iPaaS-alustalle. Heille täytyy tarjota koulutusta ja tukea iPaaS-alustan käyttöön ja integraatioiden kehittämiseen. He voivat kuitenkin haluta, että integraatiota ylläpidetään keskitetysti.
Toiset tiimit ovat kiireisiä itse front- ja backend-toteutusten kanssa, eivätkä halua tehdä koko integraatiototeutusta itse. He voivat tehdä iPaaS-alustalle nopean toteutuksen, jonka tuotantokäyttöön saattamisen tulee tehdä joku kokenut iPaaS-kehittäjä.
Edellä mainitut iPaaS-käyttöön opastus, koulutus ja integraatioiden viimeistely tuotantokäyttöön esimerkiksi virhekäsittelyn, lokituksen ja tietoturvan kannalta ovat tehtäviä, joihin on luontevaa edelleen käyttää keskitettyä integraatioihin erikoistunutta tiimiä. Kutsumme sitä ketteräksi integraatioiden ydintiimiksi (Agile Core Integration Team). Tämä tiimi hoitaa myös monimutkaisemmat integraatiototeutukset, joihin muilla kehitystiimeillä ei ole riittävästi aikaa tai osaamista.
Ydintiimin tehtävä onkin mahdollistaa sovelluskehitystiimien mahdollisimman tehokas toiminta tarjoamalla iPaaS-kehitystyön ympärille koulutusta, coachausta ja toteutusten katselmointia.
Vanhassa mallissa ICC oli vastuussa kaikesta integraatioalustan patternien, nimeämiskäytäntöjen, dokumentaation ynnä muiden laadukkaan integraatiotyön tekemiseksi tarvittavan materiaalin tuottamisesta ja siitä, että niitä käytetään integraatiotyössä. Uudessa iPaaS-maailmassa sekä kehitystiimit että ydintiimi toimivat kaikki saman integraatiotekemisen ympärillä. Kaikki kontribuoivat iPaaS-alustan kehittämiseen, ja paljon uusia kaikkia hyödyttäviä malleja syntyy projekteissa. Siksi on luontevaa, että tiimit yhdessä kokoontuvat aika ajoin, ja keräävät tätä tekemisen kautta syntynyttä tietoa kaikille hyödynnettävään muotoon. Tiimeillä on myös tarve vaihtaa tietoa iPaaS-teknologiaan ja arkkitehtuurikysymyksiin liittyen.
Tätä tärkeää yhteistyömallia tiimien välillä laadukkaamman integraatiotekemisen hyväksi kutsutaan integraatioiden kehittäjäyhteisöksi tai tutummin Community of Practiceksi. Se voi sisältää säännöllisiä (virtuaalisia) tapaamisia, webinaareja ja esim. Slackissa tai vastaavassa sosiaalisen median kanavassa tapahtuvaa jatkuvaa keskustelua. Tämän toiminnan johtamiseen tarvitaan kuitenkin joku, ja usein se annetaan luontevasti integraatioiden ydintiimin tehtäväksi.
Kohti tavoitetilaa
Kuvattuun toimintamalliin on usein luonteva siirtyä samalla kun otetaan organisaatiossa laajemmin käyttöön uusia integraatioteknologioita. Usein kyseessä on jonkin iPaaS-alusta.
Käytännössä kannattaa aloittaa käynnistämällä integraatioiden ydintiimin toiminta. Tiimille laaditaan selkeä yhteinen työjono (backlog), jota lähdetään ketterästi työstämään. Työjonossa kuuluu olla sekä teknisiä alustaan liittyviä tehtäviä, että hallintamalliin liittyviä toiminnan kehittämisen tehtäviä.
Usein tiimin ensimmäinen tehtävä onkin iPaaS-alustan käyttöönotto ja perusohjeistuksen laatiminen sille. Ydintiimin kannattaa myös itse toteuttaa ensimmäiset integraatiot alustalle, jotta voidaan varmistua siitä, että alusta vastaa käyttötarkoitusta ja siinä samalla saadaan vielä hienosäädettyä ohjeistuksia ennen kuin toiminta laajenee.
Kun alusta ja ohjeistukset ovat käyttövalmiit, voi ydintiimi ottaa muita osapuolia mukaan tekemiseen. Ensimmäisten kuukausien aikana tiimin kannattaakin yleensä keskittyä seuraaviin tehtäviin:
- Ydintiimin toiminnan optimointi
- Integration Community of Practice -tapaamiset ja keskustelukanavat käyntiin
- Kuvataan integraatioperiaatteet ja yleisimmät suunnittelumallit
- Kehittäjän käsikirjan jatkuva kehittäminen
- Laadunvarmistusmallit (auditoinnit, tuotantojulkaisumallit, jne).
- Tukimallin optimointi (esim. service deskin mukaanotto, älykäs valvonta, jne.)
Toiminnan jatkokehittämisessä ”sisällysluettelona” toimii itse asiassa perinteisen ICC-mallin tehtäväkuvaukset. Vaikka siirrytään hajautettuun malliin, tarve näiden tehtävien suorittamiselle ei poistu mihinkään. Niiden vastuujako kuitenkin muuttuu, kun osa tehtävistä tehdään sovelluskehitystiimeissä ja osa ydintiimissä.
Kaikkea tehtäviä ei kuitenkaan kerralla kannata tehdä valmiiksi vaan niitä kannattaa käydä pikkuhiljaa läpi ketterän mallin mukaisesti silloin kun tarve sitä edellyttää. Pitkään kirjoitetut laajat hallintamallikuvaukset jäävät kuitenkin ikävän usein vain kaappiin keräämään pölyä, joten varastoon ei näitä toimintamalleja kannata laatia.
Ydintiimin ketterä lähestyminen auttaa tunnistamaan tärkeimmät toimintamallien kehitystehtävät tiimin työjonoon. Ja integraatioiden kehittäjäyhteisö puolestaan tarjoaa erinomaisen foorumin näiden jalkauttamiselle. Olkaa siis pragmaattisia mutta kuitenkin kunnianhimoisia.
Kuvattu Federoitu ICC-malli yhdistää keskitetystä mallista tutut laadukkaat toimintamallit ja hajautetun kehittämisen ketteryyden. Näin saavutetaan liiketoiminnan ja kehitystiimien edellyttämää projektivaiheen nopeutta ja ketteryyttä vaarantamatta integraatioiden hallittavuutta koko niiden elinkaaren osalta.
Kirjoittajat: Janne Nieminen & Jonas Källström