Yritysohjelmistot/6 min luku

Integraatiot eivät ole ominaisuuksia

Jokaisella toimittajalla on dia, joka näyttää mihin järjestelmiin he yhdistävät. Se dia on paikka, jonne rehellisyys menee kuolemaan.

Jossain vaiheessa melkein jokaisen yritysohjelmiston myyntisykliä ilmestyy dia. Se näyttää logoja. SAP. Salesforce. NetSuite. Shopify. QuickBooks. Riveittäin tuttuja kuvakkeita ruudukkoon aseteltuna, toisinaan ohuilla viivoilla keskellä olevaan keskimmäiseen logoon yhdistettynä. Piiloviesti on selvä: tämä tuote puhuu samaa kieltä kuin kaikki muu, jota jo käytät.

Tuo dia on yksi ohjelmistomyynnin harhaanjohtavimmista asioista, ja jokainen pöydän molemmilla puolilla tietää sen kaikessa hiljaisuudessa.

Mitä integraatio oikeasti on

Kun myyntiesitys sanoo "integroituu SAP:hen", se tarkoittaa tyypillisesti yhtä kolmesta asiasta. Ensinnäkin on olemassa kolmannen osapuolen rakentama connector, joka siirtää dataa yhteen suuntaan, aikataulun mukaisesti, mapping-tiedostolla, johon koskettiin viimeksi vuonna 2021. Toiseksi, on olemassa Zapier-workflow, jonka joku pystytti kokeilujakson aikana ja joka on ollut käynnissä valvomattomana siitä lähtien. Kolmanneksi, on olemassa webhook, joka laukeaa yhdessä tietyssä event-tyypissä, ja joka oli ainoa asia, josta potentiaalinen asiakas kysyi demon aikana.

Mitä se ei melkein koskaan tarkoita, on: näiden kahden järjestelmän välillä on ylläpidetty, versioitu, kaksisuuntainen data contract, jossa on error handling, retry logic, schema validation, monitoring, alerting, ja nimetty omistaja toimittajaorganisaation sisällä, joka on siitä vastuussa, kun asiat menevät rikki.

Kuilu näiden kahden kuvauksen välillä on se, mihin useimmat yritysohjelmistojen käyttöönotot kaatuvat.

Failure mode, josta kukaan ei puhu

Ominaisuudet vikaantuvat äänekkäästi. Jos painike lakkaa toimimasta, käyttäjät huomaavat sen heti. Tukipyyntöjä avataan. Joku hälyttää insinöörin. Vika on näkyvä, ajoitettavissa ja jäljitettävissä.

Integraatiot vikaantuvat hiljaa. API-versio on deprecated upstreamissa. Authentication token vanhenee ja se hylätään hiljaisesti. Kenttä, joka sisälsi ennen numeerisen arvon, alkaa saapua stringinä, ja vastaanottavan järjestelmän parser käsittelee sen tallentamalla nollan. Rate limit saavutetaan kello 2 aamuyöllä batch syncin aikana, joitakin tietueita ohitetaan, ja työ valmistuu statuksella "success".

Data on väärin. Kukaan ei tiedä. ERP näyttää yhtä varastosaldoa; varastonhallintajärjestelmä näyttää toista. Raportti vedetään torstaina. Luvut eivät vastaa kenenkään odotuksia, mutta ne ovat tarpeeksi uskottavia, jotta eroavuus laitetaan ajoituksen piikkiin. Vaatii kolme viikkoa ja manuaalisen täsmäytysharjoituksen, jotta voidaan todeta, että integraatio on hiljaisesti pudottanut tietueita kuuden viikon ajan.

Tämä ei ole hypoteettista. Se on kuvaus jostain, mitä tapahtuu jatkuvasti kaikenkokoisissa yrityksissä, jokaisessa yritysohjelmistojen kategoriassa.

Omistajuustyhjiö

Syvin ongelma ei ole tekninen. Se on organisatorinen.

Kun ominaisuus on rikki, sille on tuotepäällikkö, joka omistaa sen, engineering-tiimi, joka on siitä vastuussa, ja roadmap-kohde, joka seuraa sitä. Kun integraatio on rikki, se ei usein ole kenenkään backlogilla. Sen rakensi konsultti implementaation aikana. Konsultti on poissa. Toimittajan tukitiimi sanoo, että connector on kolmannen osapuolen komponentti. Kolmannen osapuolen komponentin ylläpitäjä sanoo, että ongelma on upstream API:ssa. Upstream API:n dokumentaatio päivitettiin viimeksi silloin, kun edellinen versio oli nykyinen.

Integraatiot ovat infrastruktuuria. Ne eivät ole ominaisuuksia. Ne eivät kuulu tuotteen roadmapille "add dark mode" -tehtävän rinnalle. Ne kuuluvat "keep the database running" -tehtävän rinnalle — välttämättöminä, näkymättöminä, arkisina ja katastrofaalisina, kun ne laiminlyödään.

Yritykset, jotka ovat oivaltaneet tämän, kohtelevat jokaista ulkoista datariippuvuutta ensiluokkaisena engineering-huolenaiheena. He versioivat integraatioiden contractinsa. He kirjoittavat testejä, jotka ajetaan todellisia ulkoisia järjestelmiä vasten aikataulun mukaisesti. He hälyttävät datamäärien anomalioista — koska jos feed, joka normaalisti toimittaa 4 000 tietuetta tunnissa, toimittaakin yhtäkkiä 40, jokin on vialla, ja se on havaittavissa lukematta itse tietueita. He määrittävät omistajan. Ei tiimiä — vaan henkilön.

Mitä oikeasti kannattaa kysyä

Kun arvioit ohjelmistoa, jonka on vaihdettava dataa olemassa olevien järjestelmiesi kanssa, logodia on väärä asia katsottavaksi. Kysymykset, joilla on merkitystä, ovat suorasukaisempia.

Mitä tapahtuu, kun yhteys katkeaa? Laittaako järjestelmä queueen ja tekeekö se retryn? Vikaantuuko se hiljaisesti? Antaako se alertin jollekin? Onko olemassa manuaalista reprocessing-polkua, ja kuka sen ajaa?

Kuka omistaa tämän integraation teidän organisaatiossanne? Ei "kuka sen rakensi" — kuka on vastuussa siitä, että se on oikein ensi vuonna? Jos vastaus on olkapäiden kohautus, se on rehellinen vastaus, ja sinun tulisi suhtautua siihen sen mukaisesti.

Miltä schema-muutos näyttää teidän päästänne? Kun upstream-järjestelmä muuttaa kentän tyyppiä tai nimeää endpointin uudelleen, miten saatte tietää siitä, ja mikä on päivitysprosessi? "Julkaisemme uuden connector-version" ei ole sama asia kuin "annamme alertin 90 päivää etukäteen, tarjoamme migration guiden, ja tuemme molempia versioita rinnakkain."

Voinko nähdä error logit? En demoa happy pathista — vaan error logit. Jokaisella järjestelmällä, joka on ajanut integraatioita tuotannossa yli vuoden, on error logeja. Mitä niissä on, ja miten nämä virheet ratkaistaan?

Data contract on se integraatio

Ajattelutavan muutos, joka oikeasti auttaa, on lopettaa integraatioiden ajatteleminen yhteyksinä järjestelmien välillä ja alkaa ajatella niitä contracteina data producerien ja data consumerien välillä.

Contractilla on versio. Sillä on omistaja kummallakin puolella. Se ei määritä vain schemaa vaan myös semantiikan — mitä tämä kenttä tarkoittaa, mitkä ovat validit arvot, mitä tapahtuu jos se on null. Sillä on test suite. Sillä on muutosprosessi. Sillä on tapa kertoa toiselle osapuolelle, kun sitä on rikottu.

Integraatioiden rakentaminen contracteina pikemminkin kuin connectoreina on enemmän työtä etukäteen. Se on huomattavasti vähemmän työtä kolmen vuoden aikajänteellä. Ja se on ainoa lähestymistapa, joka skaalautuu yli sen pisteen, jossa yksi ihminen pystyy pitämään koko data topologyn päässään.

Logodia ei ole katoamassa minnekään. Mutta ensi kerralla kun näet sen, kysymys ei ole "mitkä logot siellä ovat" — se on "minkä arvoinen on jokainen noista yhteyksistä, kun jokin menee vikaan kello 2 aamuyöllä maanantaina?"

Tuo vastaus on se integraatio. Kaikki muu on markkinointia.

Mikael Koskinen Guru Meditation