Asiakkaani kyseli alustavasti rajapinnasta, joka juttelisi Clover Shopin ja Netvisorin välillä. Asiakkaani verkkokaupassa on Clover Shop -ohjelmisto ja varastomyymälässä Netvisor-palvelu. Tällä hetkellä hän lisää jokaisen tuotteen erikseen Clover Shoppiin ja Netvisoriin.
Asiakkaani haluaa, että kun hän lisää tuotteen jompaan kumpaan järjestelmään, niin samalla rajapinta lisää tuotteen toiseen järjestelmään, eli tiedot kulkevat automaattisesti kumpaankin suuntaan. Näin ollen yrityksen varastoa voi ylläpitää jomman kumman järjestelmän kautta, toisinaan molempien kautta, ja tiedot pysyvät synkassa keskenään.
Huom! Kirjoitukseni ei koske Clover Shoppia ja Netvisoria. Voit kuvitella niiden paikalle mitkä tahansa kaksi eri järjestelmää.
Vastasin asiakkaalle, että emme tee rajapintoja, joissa järjestelmät keskustelevat keskenään. Lisäsinkö vielä perään, että se olisi loputon suo.
Ajatellaan vaikka, että Boschin astianpesukone on lisätty ensin Netvisoriin Astianpesukoneet-nimiseen tuoteryhmään. Lisätään se ensin esimerkin vuoksi käsipelillä Clover Shoppiin. Clover Shopissa on Kodinkoneet-niminen tuoteryhmä, jonka alaryhmänä on Asianpesukoneet-niminen tuoteryhmä. Siitähän se löytyi, mutta mistä tietokone osaisi sen päätellä? Jos halutaan täydellistä synkkaa, niin rajapinnan on pidettävä tuoteryhmätkin synkassa.
PerustavaA laatua olevia haasteita riittää. Verkkokauppojen tuotekuvat olivat 90-luvulla postimerkin kokoisia ja tietokannan kentät lyhyitä. Tallennustila oli kallista. Tietokannan kenttien pituudet rajoittavat vielä tänäkin päivänä tietojen synkronointia. Epäilen että koodarit on aivopesty!
Entä jos toisessa järjestelmässä on kolme osoitekenttää ja toisessa vain kaksi? Tai jos toisessa järjestelmässä maat on tallennettu maakoodeilla, mutta toisessa sekä maakoodeilla että maiden nimillä? Yhteensovittamista riittää.
Jos kahden eri järjestelmän tietokannat ovat rakenteeltaan identtiset, niin kenttien merkitykset eivät varmasti ole. Esimerkiksi negatiivinen saldo voi olla toisessa ohjelmistossa 1=sallittu ja toisessa 0=sallittu. Tämä on vielä helppo päätellä.
No mutta seuraavaksi kahden eri järjestelmän prosessikaaviot eivät osu kohdalleen. Esimerkiksi varastosaldot päivittyvät eri vaiheessa tilaustapahtumaa. Viimeistään tässä vaiheessa rajapinnan toteutuskustannukset karkaavat käsistä.
Entä jos toinen järjestelmä kaatuu? Entä jos toinen järjestelmä uudistuu? Kuka kaivaa kuvetta? Mistä on sovittu? Kuka päivystää? Kuka johtaa? Kuka maksaa?
Avoimesti dokumentoidut rajapinnat eivät ratkaise ongelmia. Niin kauan kuin on olemassa kaksi erilaista järjestelmää, niin tietoja putoaa välistä pois. Jos lähtöpään järjestelmässä on faksinumero ja kohdepään järjestelmässä ei ole, niin faksinumeroa ei voida siirtää, vaikka avoin rajapinta tukisi faksinumeroa. Avoimet rajapinnat ovat tiukasti speksattuja, joten luovat ratkaisut ovat vaikeita.
Avoimet rajapinnat ovat erinomaisia silloin, kun integraation laajuus on lähes nollatasolla. Esimerkiksi kun verkkokauppa keskustelee maksunvälittäjän kanssa, niin ei siinä paljon nokka tuhise.
Ammatikseen integraatioita tekevillä integraattoreilla on paremmat mahdollisuudet onnistua. Eri järjestelmien välisiä eroja he eivät kuitenkaan voi ratkaista, kuten eivät voineet avoimet rajapinnatkaan.
Integraattoreiden liikeidea perustuu siihen, että he voivat jakaa tuotekehityskustannukset usean eri verkkokaupan kesken. Jos yhden rajapinnan tuotekehityskustannukset ovat esimerkiksi 70 000 euroa ja ylläpitokustannukset 5 000 euroa vuodessa, ja rajapinnan ostaa 100 verkkokauppiasta, niin yhtälö toimii kaupallisesti.
Integraattorit ovat verkkokauppiaan näkökulmasta tervetullut ilmiö; rajapinta on mahdollista ottaa käyttöön edullisesti vakiosopimuksella – ei tarvitse lukea IT-alan yleisiä sopimusehtoja tai neuvotella sopimuksesta.
NYT päässäni alkaa raksuttaa. Kahta erilaista järjestelmää ei voida koskaan synkronoida 100-prosenttisesti, mutta onko niin, että vain alle 50-prosenttiset synkronoinnit toimivat? Tietoja täydennetään ja päivitetään toisesta järjestelmästä, mutta pystytään myös olemaan yksin. Miten yli 50-prosenttisissa synkronoinneissa hoidetaan tietojen kertaantumisen riski, jos tietoja siirretään tarkoituksella vääriin kenttiin (esimerkiksi faksinumero on siirretty aukioloaikoihin)? Kohta pääni räjähtää.
Mutta ja nyt hyvää syksyn aloitusta! Syksy on vuoden paras ajankohta kehittää verkkokauppaa. Koodarit ovat palanneet töihin, mökkeilijät mökeiltä ja edessä on kuukausitolkulla tehokasta työaikaa.
