Argumentet för best-of-breed-inköp av mjukvara har alltid varit övertygande. Istället för att köpa en enda plattform som gör allt tillräckligt bra, köper du det bästa CRM-systemet, det bästa ERP-systemet, det bästa lagersystemet, det bästa HR-verktyget. Varje system är klassledande inom sin kategori. Varje system förbättras ständigt av en leverantör vars hela företag är beroende av att den produkten är bättre än konkurrenternas. Du undviker inlåsning. Du behåller flexibiliteten. Du får det bästa.
Det finns ett system som detta argument glömmer att ta hänsyn till. Det är det som byggs någonstans mellan den tredje och femte SaaS-prenumerationen, oftast av en utvecklare som egentligen skulle göra något annat. Ingen budgeterade för det. Ingen avgränsade det. Ingen gav det ett namn. Det har ingen produktchef, ingen färdplan och ingen dokumentation förutom en README som var aktuell år 2022.
Detta är SaaS-lagret ingen bad om, och i många organisationer har det i tysthet blivit den mest kritiska delen av den infrastruktur de driver.
Hur det börjar
Den utlösande faktorn är alltid en rapport som inte kan produceras. Försäljningsdata finns i CRM-systemet. Intäkter finns i bokföringsprogrammet. Lagersaldo finns i lagerhanteringssystemet. En högre chef vill ha en enhetlig vy — ordrar, kostnader, marginaler, lagernivåer — och inget av de tre systemen kan producera det på egen hand.
Den första åtgärden är att exportera CSV-filer och kombinera dem i ett kalkylblad. Detta fungerar. Det fungerar tillräckligt bra för att kalkylbladet ska bli en veckovis artefakt. Någons fredagseftermiddag blir permanent reserverad för att köra det. När den personen slutar, försvinner också kunskapen om vilka kolumner som ska hämtas och i vilken ordning.
Så småningom ersätter någon kalkylbladet med ett skript. Skriptet körs enligt ett schema. Det hämtar data från CRM-API:et, bokförings-API:et och lager-API:et, slår ihop datan och skriver den någonstans där alla kan se den. Detta är en märkbar förbättring. Det är också, utan att någon har fattat ett formellt beslut om det, den första komponenten i en dataintegrationsplattform som organisationen nu är beroende av.
Hur det växer
Skriptet löser rapporteringsproblemet. Men så fort det existerar blir det en yta för nya önskemål. Orderbekräftelsemailet borde inkludera lagerstatusen från lagerhanteringssystemet. CRM-systemet borde uppdateras automatiskt när en faktura har betalats. När en kund markeras som högrisk i ERP-systemet borde säljteamet se den flaggan i sin CRM-panel.
Varje önskemål är rimligt. Varje önskemål kräver att man läser från ett system och skriver till ett annat. Utvecklaren som byggde det ursprungliga skriptet lägger till logiken. Sedan ännu mer. Skriptet blir till en tjänst. Tjänsten får konfigurationer. Konfigurationerna blir mer komplexa. Vid någon tidpunkt blir det något som tar mer än femton minuter att förklara för en ny tekniker.
Organisationer som noggrant spårar sina mjukvaruutgifter upptäcker ofta att detta interna lager — obudgeterat, olicensierat, onamngivet — utför mer faktisk affärslogik än flera av de SaaS-produkter det sammankopplar. Regler för kundlivscykeln. Prisjusteringar. Utlösare för orderuppfyllelse. Spärrar för regelefterlevnad. Den inköpta mjukvaran hanterar lagringen och UI:t. Klisterlagret hanterar besluten.
Problemet med klister
Klisterkod har en egenskap som är lätt att förbise när det inte finns så mycket av den: den är bärande i proportion till hur många saker den kopplar samman. En enskild integration mellan två system är en bekvämlighet. Fem integrationer mellan sex system är infrastruktur. Ta bort en komponent och flera affärsprocesser stannar.
Infrastruktur kräver att bli behandlad som infrastruktur. Den behöver övervakning av drifttid. Den behöver varningar när något misslyckas i tysthet. Den behöver versionshantering, så att när ett uppströms-API ändras kan du testa mot den nya versionen utan att störa produktionsmiljön. Den behöver dokumentation som en ny tekniker kan läsa och förstå utan att behöva skugga personen som byggde den. Den behöver någon som är ansvarig för den en söndagsmorgon när ett orderhanteringsjobb avstannar och driftteamet inte kan leverera.
De flesta interna SaaS-lager har inga av dessa saker, eftersom de aldrig var tänkta att bli infrastruktur. De växte till det av misstag. Och eftersom de aldrig designades avsiktligt bär de på varje genväg som togs under de fjorton månader av nya funktioner som följde på det ursprungliga fredagseftermiddags-skriptet.
Vad leverantörerna inte berättar för dig
Enterprise-SaaS-leverantörer har en term för den kategori av mjukvara som konkurrerar med det interna klisterlagret: iPaaS, integration platform as a service. Zapier är konsumentversionen. MuleSoft, Boomi och Workato är företagsversionerna. Säljpunkten är att istället för att bygga ett eget integrationslager så köper du ett managerat.
Detta löser en del av infrastrukturproblemet. iPaaS-plattformar hanterar drifttid, versionshantering och övervakning. Men de löser inte designproblemet. En iPaaS-plattform byggd ovanpå en dåligt förstådd datamodell — där samma kundpost existerar i tre system med tre olika identifierare — kommer att misslyckas på exakt samma sätt som ett hemmabyggt skript byggt på samma grund. Plattformen är bättre konstruerad. Affärslogiken är fortfarande fel.
Leverantörerna gör inte heller reklam för hur snabbt kostnaden för en iPaaS-prenumeration skalar med komplexiteten i det du integrerar. Ett enkelt trigger-action-arbetsflöde kostar nästan ingenting. Tvåvägssynkronisering över fem system med villkorslogik, felhantering och anpassade transformationer kostar betydligt mer, ofta mer än någon enskild SaaS-produkt den ansluter. Vid den punkten blir frågan om man ska köpa eller bygga genuint intressant igen.
Designbeslutet som gömmer sig i ett inköpsbeslut
Best-of-breed-inköp är inte fel. Det finns genuina fall där det rätta svaret är att köpa den bästa produkten i varje kategori och acceptera det integrationsarbete som följer. Organisationer med ovanliga behov inom en enskild domän — en specialistlogistikverksamhet, en forskningsinstitution med specifika datakrav — kan ofta inte hitta en enda produkt som hanterar deras kärndomän väl. Då är best-of-breed rätt beslut.
Men det är ett designbeslut, och det måste fattas som ett sådant. Integrationslagret är inte en extra kostnad som uppstår efter inköpsbeslutet. Det är ett system som kommer att byggas som en konsekvens av inköpsbeslutet, och det måste budgeteras, bemannas, ägas och designas med samma noggrannhet som vilket annat system som helst.
Organisationer som hanterar detta väl upptäcker inte sitt integrationslager av en slump. De definierar det medvetet: här är systemen vi köper, här är datan vi behöver flytta mellan dem, här är teamet som ansvarar för infrastrukturen som flyttar den, så här vet vi när den går sönder. Klistret blir till arkitektur.
Organisationer som hanterar det dåligt slutar med ett kritiskt system som ingen äger, som körs på en server som ingen övervakar, och som utför affärslogik som ingen har skrivit ner. De får reda på att det existerar först när det slutar fungera.
Best-of-breed plus ett oavsiktligt integrationslager är i praktiken inte best-of-breed. Det är best-of-breed i de delar du utvärderade, plus vad som var billigast att bygga för stunden i de delar du glömde att utvärdera. Att förstå det innan inköpsbeslutet är skillnaden mellan en genomtänkt arkitektur och en dyr överraskning.