Perustelu best-of-breed-ohjelmistohankinnalle on aina ollut vakuuttava. Sen sijaan, että ostaisit yhden alustan, joka tekee kaiken kohtalaisesti, ostat parhaan CRM:n, parhaan ERP:n, parhaan varastojärjestelmän ja parhaan HR-työkalun. Jokainen on luokkansa johtava tuote. Toimittaja, jonka koko yrityksen toiminta riippuu siitä, että tuote on kilpailijoita parempi, kehittää sitä jatkuvasti. Vältät toimittajaloukun. Säilytät joustavuuden. Saat parasta.
Tämä perustelu unohtaa kuitenkin ottaa huomioon erään järjestelmän. Sen, joka rakennetaan jossain kolmannen ja viidennen SaaS-tilauksen välillä, yleensä kehittäjän toimesta, jonka piti tehdä jotain aivan muuta. Kukaan ei budjetoinut sitä. Kukaan ei määritellyt sen laajuutta. Kukaan ei antanut sille nimeä. Sillä ei ole tuotepäällikköä, ei tiekarttaa eikä muuta dokumentaatiota kuin README, joka piti paikkansa vuonna 2022.
Tämä on SaaS-kerros, jota kukaan ei pyytänyt, ja monissa organisaatioissa siitä on kaikessa hiljaisuudessa tullut niiden kriittisin infrastruktuurin osa.
Miten se alkaa
Laukaisijana on aina raportti, jota ei voida tuottaa. Myyntidata on CRM:ssä. Liikevaihto on kirjanpito-ohjelmistossa. Varastotilanne on varastonhallintajärjestelmässä. Joku johtoportaasta haluaa yhden yhtenäisen näkymän — tilaukset, kulut, katteet, varastotasot — eikä mikään näistä kolmesta järjestelmästä pysty tuottamaan sitä yksin.
Ensimmäinen ratkaisu on viedä CSV-tiedostoja ja yhdistää ne taulukkolaskentaohjelmassa. Tämä toimii. Se toimii riittävän hyvin, jotta taulukosta tulee viikoittainen rutiini. Jonkun perjantai-iltapäivä on pysyvästi varattu sen ajamiseen. Kun kyseinen henkilö lähtee, tieto siitä, mitä sarakkeita tulee hakea ja missä järjestyksessä, poistuu hänen mukanaan.
Lopulta joku korvaa taulukon skriptillä. Skripti ajetaan ajastetusti. Se hakee tiedot CRM API:sta, kirjanpidon API:sta ja varaston API:sta, yhdistää datan ja kirjoittaa sen paikkaan, josta kaikki voivat sen nähdä. Tämä on merkittävä parannus. Se on myös, ilman kenenkään tietoista päätöstä, dataintegraatioalustan ensimmäinen komponentti, josta organisaatio on nyt riippuvainen.
Miten se kasvaa
Skripti ratkaisee raportointiongelman. Mutta kun se on olemassa, siitä tulee alusta uusille pyynnöille. Tilausvahvistussähköpostin tulisi sisältää varastotilanne varastonhallintajärjestelmästä. CRM pitäisi päivittää automaattisesti, kun lasku on maksettu. Kun asiakas merkitään korkeariskiseksi ERP:ssä, myyntitiimin pitäisi nähdä tämä merkintä CRM-näkymässään.
Jokainen näistä on kohtuullinen pyyntö. Jokainen vaatii lukemista yhdestä järjestelmästä ja kirjoittamista toiseen. Kehittäjä, joka rakensi alkuperäisen skriptin, lisää logiikan. Sitten hän lisää hieman lisää. Skriptistä tulee palvelu. Palvelu saa konfiguraation. Konfiguraatiosta tulee monimutkaisempi. Jossain vaiheessa se muuttuu joksikin, jonka selittäminen uudelle insinöörille vie enemmän kuin viisitoista minuuttia.
Organisaatiot, jotka seuraavat ohjelmistokulujaan tarkasti, huomaavat usein, että tämä sisäinen kerros — budjetoimaton, lisensoimaton ja nimetön — suorittaa enemmän varsinaista liiketoimintalogiikkaa kuin useat sen yhdistämistä SaaS-tuotteista. Asiakkaan elinkaarisäännöt. Hinnoittelumuutokset. Tilaustenkäsittelyn herätteet. Vaatimustenmukaisuuden estot. Ostettu ohjelmisto hoitaa tietovaraston ja UI:n. Liimakerros tekee päätökset.
Liiman ongelma
Liimakoodilla on ominaisuus, joka on helppo sivuuttaa silloin kun sitä on vähän: se on kantava rakenne suhteessa siihen, kuinka monta asiaa se yhdistää. Yksittäinen integraatio kahden järjestelmän välillä on mukavuus. Viisi integraatiota kuuden järjestelmän välillä on infrastruktuuria. Poista mikä tahansa komponentti, ja useat liiketoimintaprosessit pysähtyvät.
Infrastruktuuri vaatii, että sitä kohdellaan infrastruktuurina. Se vaatii käytettävyyden valvontaa. Se vaatii hälytyksiä silloin, kun jokin epäonnistuu hiljaisesti. Se vaatii versiointia, jotta ylävirran API:n muuttuessa voit testata uutta versiota rikkomatta tuotantoa. Se vaatii dokumentaatiota, jota uusi insinööri voi lukea ja ymmärtää ilman, että hänen tarvitsee seurata sen rakentanutta henkilöä vierestä. Se vaatii jonkun, joka on siitä vastuussa sunnuntaiaamuna, kun tilauksenkäsittelytyö jumittuu eikä operatiivinen tiimi pysty lähettämään toimituksia.
Useimmilla sisäisillä SaaS-kerroksilla ei ole mitään näistä asioista, koska niiden ei koskaan pitänyt muodostua infrastruktuuriksi. Ne kasvoivat sellaiseksi vahingossa. Ja koska niitä ei koskaan suunniteltu tarkoituksella, ne kantavat mukanaan jokaista oikoreittiä, joka on otettu niiden neljäntoista kuukauden ominaisuuslisäysten aikana, jotka seurasivat alkuperäistä perjantai-iltapäivän skriptiä.
Mitä toimittajat eivät kerro sinulle
Enterprise SaaS -toimittajilla on termi ohjelmistokategorialle, joka kilpailee sisäisen liimakerroksen kanssa: iPaaS, integraatioalusta palveluna. Zapier on sen kuluttajaversio. MuleSoft, Boomi ja Workato ovat enterprise-versioita. Myyntipuheena on, että sen sijaan, että rakentaisit oman integraatiokerroksen, ostat hallinnoidun sellaisen.
Tämä ratkaisee osan infrastruktuuriongelmasta. iPaaS-alustat hoitavat käytettävyyden, versioinnin ja valvonnan. Mutta ne eivät ratkaise suunnitteluongelmaa. Huonosti ymmärretyn tietomallin päälle rakennettu iPaaS-alusta — jossa sama asiakastietue on olemassa kolmessa järjestelmässä kolmella eri tunnisteella — epäonnistuu täsmälleen samoilla tavoilla kuin samalle perustalle rakennettu itsetehty skripti. Alusta on paremmin rakennettu. Liiketoimintalogiikka on edelleen pielessä.
Toimittajat eivät myöskään mainosta sitä, kuinka nopeasti iPaaS-tilauksen kustannukset skaalautuvat integroitavan kokonaisuuden monimutkaisuuden mukaan. Yksinkertainen laukaisin-toiminto-työnkulku ei maksa juuri mitään. Kaksisuuntainen synkronointi viiden järjestelmän välillä ehdollisella logiikalla, virheenkäsittelyllä ja kustomoiduilla muunnoksilla maksaa huomattavasti enemmän, usein enemmän kuin yksikään niistä SaaS-tuotteista, joita se yhdistää. Tässä vaiheessa kysymys siitä, kannattaako ostaa vai rakentaa itse, muuttuu jälleen todella mielenkiintoiseksi.
Hankintapäätöksen sisään piilotettu suunnittelupäätös
Best-of-breed-hankinta ei ole väärin. On aitoja tapauksia, joissa oikea ratkaisu on ostaa kunkin kategorian paras tuote ja hyväksyä siitä seuraava integraatiotyö. Organisaatiot, joilla on epätavallisia tarpeita yhdellä tietyllä osa-alueella — erikoistunut logistiikkaoperaatio, tutkimuslaitos tarkkoine datavaatimuksineen — eivät useinkaan löydä yhtä tuotetta, joka hoitaisi niiden ydinosa-alueen hyvin. Best-of-breed on silloin oikea valinta.
Mutta se on suunnittelupäätös, ja se on tehtävä sellaisena. Integraatiokerros ei ole yleiskulu, joka syntyy hankintapäätöksen jälkeen. Se on järjestelmä, joka tullaan rakentamaan hankintapäätöksen seurauksena, ja se on budjetoitava, sille on osoitettava henkilöstö ja omistaja, ja se on suunniteltava yhtä tarkasti kuin mikä tahansa muukin järjestelmä.
Organisaatiot, jotka hoitavat tämän hyvin, eivät löydä integraatiokerrostaan vahingossa. Ne määrittelevät sen tietoisesti: tässä ovat järjestelmät, jotka ostamme; tässä on data, jota meidän on siirrettävä niiden välillä; tässä on tiimi, joka on vastuussa sitä siirtävästä infrastruktuurista; tässä on tapa, jolla saamme tietää, kun se rikkoutuu. Liimasta tulee arkkitehtuuria.
Organisaatiot, jotka hoitavat sen huonosti, päätyvät kriittiseen järjestelmään, jota kukaan ei omista, joka pyörii palvelimella, jota kukaan ei valvo, ja joka suorittaa liiketoimintalogiikkaa, jota kukaan ei ole kirjannut ylös. Ne huomaavat sen olemassaolon vasta, kun se lakkaa toimimasta.
Best-of-breed yhdistettynä vahingossa syntyneeseen integraatiokerrokseen ei ole käytännössä best of breed. Se on best of breed niissä osissa, jotka arvioit, sekä mitä tahansa sattui silloin olemaan halvinta rakentaa niissä osissa, jotka unohdit arvioida. Tämän ymmärtäminen ennen hankintapäätöstä on ero harkitun arkkitehtuurin ja kalliin yllätyksen välillä.