Mikä on integraation määritelmä?

Jaakko Alajoki twiittasi keväällä kotimaisten digitoimistojen heikosta integraatio-osaamisesta, ja ylipäätään siitä miten integraatio-sanalla saatetaan viitata alalla hyvin monenlaisiin toteutuksiin. Tästä lähti keskustelu, joka on nyt tuotettu haastatteluartikkelin muotoon.

Tämä integraatio-käsitteen sekavuus ehdottomasti näkyy myös esimerkiksi Vierityspalkin Julkaisut-palstalla, jossa referenssikuvauksissa osa toimistoja luettelee integraatioksi suurinpiirtein sivuston some-nappulatkin.

Myös Toimistot-hakemiston integraatiokokemus-tähtiluokituksessa on törmätty samaan haasteeseen, kun osa toimistoja ei ole kovin halukas kuvaamaan tarkemmin referenssien integraatioita. Osittain kyse on varmasti siitä, että referenssejä kirjoittavat usein ei-tekniset henkilöt, mutta osa tapauksista tuntuu olevan myös tarkoituksellista ilman puhaltamista, jotta työt kuulostaisivat vaativammilta.

Tilannetta vaikeuttaa, että nykyisin on hyvin vaikea ulkoapäin tietää, että onko joku integraatio ollut puolen tunnin naksuttelutyö vai kolmen viikon ankara ponnistus, jossa uutta koodia on täytynyt synnyttää monen henkilön voimin.

Tästä kaikesta johtuen, on syytä pureutua siihen mikä on vaativa integraatio ja mitä kaikkea sellaisen toteutus vaatii.

Kysymyksiin vastaamassa Evermaden CTO Jaakko Alajoki. Kysymykset lihavoituna.

Miten määrittelet integraation? Onko mikä tahansa kahden sivuston välillä liikkuva datan pätkä integraatiota?

Integraation määrittely on tosiaan usein aika häilyvää. Mielestäni se ei vielä täytä suoraan integraation määritelmää, että tietoa liikkuu kahden sivuston välillä. Minusta integraatio edellyttää myös jonkinlaista tiedon prosessointia. Hyvä esimerkki on vaikkapa RSS-syöte. Jos verkkopalvelu vain listaa toisen sivuston sisältöä RSS-syötteen avulla, olisi aika rohkeaa kutsua sitä integraatioksi. Toisaalta jos sisältöä haetaan RSS-syötteenä ja sitä esimerkiksi yhdistetään johonkin muuhun tietoon, kutsuisin sitä integraatioksi.

Onko alalla mielestäsi asioita joista puhutaan integraatioina, mutta joista ei oikeastaan pitäisi puhua integraatioina?

Olen nähnyt monesti some-nappeja, some-upotuksia, karttaupotuksia, ulkopuolisia RSS-syötteitä ja Google Analytics -skriptiä kutsuttavan integraatioksi. Joskus myös ihan pelkästä linkityksestä toiseen palveluun puhutaan integraationa.

Jos tieto saadaan liikkumaan asentamalla esimerkiksi WordPressiin joku lisäosa ja naksuttelemalla asetuksia, onko kyseessä integrointi?

WordPressille on saatavilla hyviä lisäosia, jotka voivat tehdä paljon asioita pelkästään konfiguroimalla ilman koodaustyötä. Esimerkiksi WP All Import on hyvin joustava lisäosa ja sillä voi tehdä monenlaisia asioita helposti. Minusta lisäosan käyttöä voi kutsua integraatioksi. Oleellista ei ole se, että joku on vuodattanut tuskan kyyneliä koodia hakatessaan. Pidän jopa hyvin tärkeänä sitä, että käytetään valmiita työkaluja, mikäli sellaisia on saatavilla.

Milloin voidaan puhua vaativasta integraatiosta?

Integraatio voi olla vaativa monella tapaa. Jos tietoa pitää yhdistellä useasta eri lähteestä tai prosessoida paljon, se nostaa heti vaatimustasoa. Myös tiedon suuri määrä lisää vaativuutta. Jos datamäärät ovat suuria, pitää ottaa huomioon suorituskykyasioita. Esimerkiksi kaikkea tietoa ei välttämättä voida tuoda (tai viedä) kerrallaan vaan prosessi pitää pystyä pilkkomaan osiin. Myös bisneskriittisyys vaikuttaa. Toteutimme hiljattain verkkokaupan integraation asiakkaan CRM:ään. Integraation vastuulla on myös laskujen luonti. Tällaiset integraatiot ovat asiakkaan liiketoiminnan kannalta hyvin tärkeitä, joten se asettaa myös vaatimustason tekemiselle.

Minkälaista osaamista vaativan integraation toteutus tyypillisesti tekijältään tarvitsee?

Toki ihan lähtötasona on ymmärrys erilaisista teknisistä rajapintatoteutuksista, kuten REST tai GraphQL. Todellisuudessa usein vastaan tulee myös SOAP-toteutuksia sekä epästandardeja XML-virityksiä. Eipä salaamattoman FTP-yhteyden yli CSV-tiedostoilla operoiminenkaan ihan tavatonta ole. Kerran asiakkaan avaama rajapinta paljastui vain yhteydeksi heidän SQL-kantaan.

Dokumentaatio jättää monesti toivomisen varaa, joten ongelmanratkaisukykyä ja kykyä ottaa asioista selvää tarvitaan. Monesti valmiita vastauksia ei ole, vaan ne pitää itse ottaa selville. Tämä edellyttää usein teknisesti monimutkaisten asioiden kommunikoimista ihmisille, joilla ei ole vastaavia teknisiä valmiuksia.

Integraatioita tehdessä on myös oltava ymmärrys siitä, miten tieto tallennetaan. Huonot suunnitteluratkaisut voivat näkyä suorituskykyongelmina. Vaikkapa 10 000 tuotteen tuominen sivustolle voi edellyttää datan käsittelyä rivi riviltä. Tällaisessa tilanteessa jokainen millisekunti pitää kertoa kymmenellä tuhannella ja virheet kertautuvat helposti.

Minkälaista osaamista tai menetelmiä ta järjestelmiä tarvitaan toimistotasolla, jotta voidaan luottaa vaativan integraation pysyvän toiminnassa myös jatkossa? (Jos alkuperäinen tekijä esim vaihtaa työpaikkaa).

Integraation dokumentointi on tietysti ilmeinen asia, joka pitää huolehtia kuntoon. Dokumentaatiota voi periaatteessa aina kirjoittaa rajattomasti, mutta integraatioissa minusta tärkein on ymmärtää, miten sitä voi testata. Testaaminen ja haluttu lopputulos saattaa olla vaikeita hahmottaa koodista, joten tällainen tieto on mukava lukea dokumentaatiosta ja se auttaa myös uusia kehittäjiä hyppäämään kelkkaan.

Oleellisia asioita ovat myös valvonta ja logitieto. Jokainen integraatio menee enemmin tai myöhemmin rikki. On mukavampi saada hälytys integraation hajoamisesta kuin viesti asiakkaalta, että data ei ole kulkenut viikkoon. Ja logitieto on tärkeää virheiden selvittämisessä. Integraatiot tapahtuvat yleensä pinnan alla ja niihin liittyy erilaisia ajastettuja tehtäviä. Ilman lokitietoa on käytännössä mahdotonta tietää, mitä virhetilanteissa on tapahtunut.

Miten integrointi on muuttumassa? Onko tulevaisuudessa kaikissa järjestelmissä julkiset rajapinnat ja laadukkaat dokumentaatiot?

Esimerkiksi WordPressissä on valmiina hyvät REST-rajapinnat, mutta ne eivät silti riitä aina kattamaan kaikkia tarpeita. On hyvin tyypillistä, että rajapintaa laajennetaan palauttamaan jotain sellaista tietoa, jota ei oletuksena saada. Rajapintojen muokkaaminen tarpeita vaativiksi on varmasti työtä, jota tullaan jatkossa tekemään.

Monien isojen SaaS-tuotteiden rajapinnat on ovat kattavia ja kauniisti dokumentoituja ja niiden perusteella saattaa syntyä vähän turhan ruusuinen kuva rajapintojen maailmasta. Realismia arkipäivän työssä on kuitenkin se, että integraatioita tehdään vaikkapa asiakkaiden olemassaoleviin vanhoihin ERP- tai CRM-järjestelmiin. En näe ihan lähitulevaisuudessa sellaista todellisuutta, että tällaisissa järjestelmissä olisi valmiit ja hyvin dokumentoidut rajapinnat. Monesti tällaiset järjestelmät ovat räätälöityjä toteutuksia ja rajapintoja tehdään tarvittaessa tiettyyn käyttötarkoitukseen vähin resurssein, mikä näkyy dokumentaation ja rajapintasuunnittelun laadussa.

Ja vaikka palveluissa olisikin täydelliset rajapinnat, integraattorin rooli on silti edelleen hakea tietoa, prosessoida sitä ja siirtää palvelusta toiseen.

Näetkö Zapierin kaltaisten työkalujen muuttavan integroinnin maailmaa?

Ensivilkaisulla nämä vaikuttavat usein houkuttelevilta ja yksinkertaisissa tapauksissa näiden avulla voi säästääkin aikaa. Oma kokemus on kuitenkin se, että rajat tulee usein vastaan. Ja edelleen todellisuus on se, että integraatioita tehdään hyvin vaihteleviin järjestelmiin, jotka eivät ole tällaisissa palveluissa tuettuja.

Maailma on kuitenkin menossa suuntaan, missä erilaisista järjestelmistä alkaa löytyä hyviä rajapintoja. Toisaalta integraatioiden tekeminen on pahimmillaan työlästä ja kallista. Kaikenlainen automaatio ja valmiit ratkaisut ovat ehdottomasti tervetulleita.

Näetkö jotain riskejä tai kääntöpuolia näissä integraatiopalveluissa, jotka tekevät valmiita putkia erilaisten järjestelmien välille?

Varmasti näissä isoin ongelma on kontrollin puute. Jos joku muuttaa automaatioita, saattaa itselle oleellinen tieto lakata kulkemasta. Joissain tapauksissa tämä ei ole ongelma, mutta joissain tapauksissa kyseessä voi olla jopa liiketoiminnallinen riski. Jos homma on omissa käsissä, niin yllätykset ovat epätodennäköisempiä.

Myös tietosuoja mietityttää. Olen ollut mukana monissa projekteissa, joissa sopimusteknisesti tiedon kierrättäminen jonkun ulkopuolisen palvelun kautta ei ole yksinkertaisesti mahdollista. Mikäli integraatiossa käsitellään henkilötietoja, tietosuojan merkitys korostuu entisestään.

PS. Tilaa Vierityspalkin kerran kuukaudessa ilmestyvä uutiskirje, joka koostaa artikkelit, linkkivinkit, työpaikat ja julkaisut (uutiskirjeellä on yli 800 tilaajaa).

Aiempia juttuja, joissa käsitellään asioita, joita hyvän ostajan kannattaisi ymmärtää:

• Katsaus mobiilikehityksen eri toteutusmalleihin
• Kun etsit digitoimistoa: Arvioi referenssejä
• Milloin kannattaa tehdä html-proto, milloin pelkät leiskat, milloin vaatimusmäärittely, milloin riittää tuotevisio?
• Asiakas: Ota selvää toimiston kehityskäytänteistä
• Natiivit mobiilisovellukset ratkaisevat vaativia erikoistilanteita
• Milloin mobiilisovelluksen toteutus on järkevää?
• Asiakas: Osta läski ylläpitosopimus – pysyt onnellisena
• Tavoitehintamalli ja sen eri variaatiot