iPaaS vs. direkte API: Hvad koster mindst i teknisk gæld?

Valget mellem en iPaaS og direkte API-integrationer afgøres af systemantal og ændringstempo: Forbinder I to faste systemer med uændret datastruktur, koster direkte API mindst. Skal I derimod integrere tre eller flere forretningssystemer med hyppige procesændringer, mindsker en iPaaS den tekniske gæld markant ved at samle fejlhåndtering, datatransformation og overvågning i én central grænseflade.

Hvad er den reelle forskel i arkitekturen?

For at vælge rigtigt skal I se på, hvordan data flyttes mellem jeres applikationer. Ved en direkte API-integration (punkt-til-punkt) skriver en softwareudvikler kode, der forbinder to specifikke endepunkter. Koden henter data fra System A, omskriver formatet fra JSON eller XML og sender det videre til System B via en REST- eller GraphQL-forespørgsel. Løsningen afvikles ofte på en serverless cloud-funktion i Microsoft Azure eller AWS til 50-200 kr. om måneden.

En iPaaS (Integration Platform as a Service) som Make, Workato, Celigo eller Azure Integration Services fungerer i stedet som et centralt knudepunkt. Hvert system sender sine data til platformen én gang. Herfra håndterer platformen validering, opsplitning og transformation, før data sendes ud til de relevante modtagere.

Hvis I vil se grundprincipperne for, hvordan et endpoint overhovedet snakker sammen med en database, kan I læse vores artikel om hvordan API-integrationer binder forretningssystemer sammen.

Hvor opstår den tekniske gæld i direkte API-integrationer?

Teknisk gæld er den fremtidige regning for valg, der løser et akut behov på bekostning af driftsstabilitet. Ved direkte kodede integrationer viser regningen sig sjældent i udviklingsfasen. Den dukker op i driftsfasen efter 12 til 24 måneder.

Gælden opstår typisk i tre bestemte flaskehalse:

• Eksponentielt voksende kompleksitet: To systemer kræver én integrationslinje. Fire systemer, der udveksler data indbyrdes, kræver op til seks forbindelser. Ved seks systemer skal I vedligeholde 15 separate snitflader. Formlen bag er n(n-1)/2, og hver linje kræver selvstændig dokumentation og test ved opdateringer.
• Manglende kø-håndtering og tabt data: Hvad sker der, hvis Microsoft Dynamics 365 Business Central eller e-conomic lukker midlertidigt under en natlig opdatering? Uden en indbygget kømekanisme (dead-letter queue) tabes kaldet. Resultatet er tabte ordrer eller ufuldstændige kundekartoteker, som medarbejdere skal genskabe manuelt.
• Sårbarhed ved medarbejderskift: Hjemmebygget kode er sjældent dokumenteret fyldestgørende. Forlader den ansvarlige udvikler virksomheden, koster det typisk 20-35 konsulenttimer blot at afkode integrationslogikken, første gang et API fejler på grund af et ændret datafelt.

Vil I undgå de klassiske arkitekturfælder, når cloud-systemerne kobles op, dækker vi de mest udbredte problemer i vores gennemgang af faldgruber ved integration af cloud-systemer.

Myten om den billige no-code integrationsplatform

Mange IT-ansvarlige falder i den modsatte grøft. De antager, at en grafisk no-code integrationsplatform eliminerer alle fremtidige vedligeholdelsesudgifter. Virkeligheden er mere nuanceret.

En professionel iPaaS koster typisk mellem 1.800 kr. og 22.000 kr. om måneden afhængigt af datavolumen, antal forbindelser og krav til sikkerhed. Vælger I en licensmodel baseret på transaktionsantal, kan uventet vækst i ordrevolumen mangedoble regningen på få måneder.

Samtidig introducerer platformene vendor lock-in. Hvis I bygger hundredvis af forretningsregler ind i et proprietært værktøj, er det tids- og omkostningskrævende at migrere væk. Kræver jeres forretning komplekse beregninger – eksempelvis specifikke split-momsregler for 14 EU-lande eller avanceret rabatberegning på tværs af 50.000 varenumre – bliver visuelle workflows i en iPaaS hurtigt langsomme og svære at overskue.

Tommelfingerregel: Brug en iPaaS til transport, synkronisering, validering og hændelsesstyring. Læg tunge beregninger, databaserensning og kompleks logik i selve kernesystemerne eller i en dedikeret mikrotjeneste for at undgå unødvendigt højt forbrug af platformens ressourcer.

Konkret sag: Grossistens nedbrud og den økonomiske regning

En mellemstor dansk B2B-grossist med 42 ansatte sælger reservedele via en Shopify Plus-webshop, styrer lager og bogholderi i Microsoft Dynamics 365 Business Central og håndterer tilbudsprocesser i HubSpot. Grossisten valgte oprindeligt en direkte API-model. Et eksternt bureau kodede to direkte integrationer i Node.js: Shopify til Business Central og HubSpot til Business Central. Etableringen kostede 75.000 kr.

Løsningen kørte fejlfrit i 14 måneder med et gennemsnit på 400 månedlige B2B-ordrer. Problemerne ramte i forbindelse med højsæsonen i november, hvor ordreantallet steg til 3.200 på en måned. Shopify udrullede en ændring i deres GraphQL Admin API, som ændrede navnet på et metadatafelt for betalingsbetingelser.

Uden centraliseret overvågning fejlede synkroniseringen i stilhed. Ordrerne blev oprettet i Shopify, men stoppede før integrationen nåede Business Central. Fejlen kørte ubemærket i 4 arbejdsdage, før lagerchefen undrede sig over manglende pluklister. På det tidspunkt lå 186 ordrer fastlåst uden for regnskabet.

Det økonomiske efterspil blev markant:

• Akut konsulentbistand: Bureauet brugte 38 timer á 1.350 kr. på at lokalisere fejlen, rette koden og genkøre ordrefilerne. Regning: 51.300 kr.
• Internt tidsforbrug: Kundeservice og bogholderi brugte anslået 60 timer på at håndtere forsinkede leverancer, kreditnotaer og manuelle tjek af lagerantal. Interne lønomkostninger: ca. 21.000 kr.
• Samlet ekstraregning for hændelsen: 72.300 kr. på under én uge.

Til sammenligning ville en standardiseret iPaaS med indbygget Shopify- og Business Central-stik have kostet cirka 2.500 kr. om måneden (30.000 kr. årligt). Platformen havde opdaget feltfejlen ved første ordre, standset kørslen, sendt en fejlnotifikation til IT-ansvarlig og sat ordrerne i en fejlkø, klar til genkørsel med ét klik.

Direkte sammenligning: Hvad koster de to modeller over 3 år?

Når I vurderer den samlede ejeromkostning (TCO), skal I medregne både udvikling, faste licenser og løbende vedligeholdelse. Tabellen herunder illustrerer et realistisk omkostningsbillede for en virksomhed, der forbinder 3 kernesystemer (fx ERP, CRM og e-handel) over en treårig driftsperiode.

Som tabellen viser, er de to modeller prismæssigt tæt på hinanden over tre år. Forskellen ligger i, hvad I betaler for: Ved direkte kode betaler I for uforudsigelige konsulenttimer ved fejl og opdateringer. Ved en iPaaS betaler I en fast, forudsigelig platformlicens til gengæld for overblik og stabilitet.

Før I låser jer fast på nye teknologier, kan I hente inspiration i vores tjekliste før investering i forretningssystemer for at afdække systemkravene.

Tjekliste: Vurder jeres integrationsmodel i 5 trin

Brug disse 5 afklarende spørgsmål i jeres IT-styregruppe, før I vælger mellem kode og middleware:

1. Hvor mange integrationer skal køre om to år? Hvis I kun har brug for et simpelt flow mellem et kontaktformularmodul og e-conomic, er en direkte serverless integration billigst. Forventer I at forbinde ERP, PIM, WMS og CRM inden for 24 måneder, vokser den tekniske gæld ved direkte kode for hurtigt.
2. Hvem skal løse problemerne i det daglige? Råder virksomheden over egne softwareudviklere, som kan tilgå cloud-miljøer og læse logfiler? Hvis ansvaret ligger hos forretningsfolk, bogholdere eller en enkelt IT-generalist, sparer et visuelt iPaaS-interface mange konsulenttimer.
3. Hvor standardiserede er jeres systemer? Arbejder I med gængse SaaS-værktøjer som Shopify, Business Central, HubSpot eller Pleo, har de fleste iPaaS-løsninger færdigbyggede stik. Benytter I et lokalt SQL-databasesystem fra 2011, skal der alligevel kodes en del brugerdefineret logik for at hente data ud.
4. Hvad er jeres krav til transaktionshastighed? Kræver forretningen millisekund-respons – for eksempel ved beregning af dynamiske fragtpriser under checkout i en travl webshop? Middleware tilføjer et ekstra netværkssnitfladelag, som typisk øger svartiden med 150-400 millisekunder sammenlignet med direkte API-kald.
5. Hvor hyppigt ændrer forretningsgangene sig? Ændrer I ofte rabatsatser, kundestatuser eller godkendelsesprocedurer? I en iPaaS kan en superbruger rette et filter på 10 minutter, hvorimod en ændring i direkte kode kræver udvikling, lokal test og deployment.

Faldgruber: Hvornår er en iPaaS den forkerte vej?

Selvom en middleware-platform løser mange arkitekturudfordringer, findes der scenarier, hvor den skaber flere problemer end den fjerner.

Fælden med uoverskuelige visuelle flows

At erstatte spaghetti-kode med et uoverskueligt net af 50 dårligt navngivne no-code flows flytter blot rodet til en anden skærm. Teknisk gæld opstår lige så hurtigt i Make eller Zapier, hvis flows oprettes af skiftende medarbejdere uden standarder for fejlhåndtering, versionering og dokumentation.

Tunge datamængder sprænger budgettet

Skal I flytte store filformater, CAD-tegninger eller behandle millioner af IoT-datapunkter i timen, er en almindelig iPaaS sjældent økonomisk rentabel. Licensmodellen straffer høje datamængder. I sådanne tilfælde er en hændelsesdrevet cloud-arkitektur med Azure Service Bus, RabbitMQ eller Apache Kafka langt mere skalerbar.

Når data først flyder stabilt mellem systemerne, kan I koble rapportering på. Læs eventuelt mere om, hvordan I opbygger ledelsesoverblik i vores guide til dashboards der driver forretningsvækst.

Arkitekturen skal afspejle organisationens ressourcer

Valget mellem direkte API-kode og en iPaaS handler sjældent om, hvilken teknologi der er "bedst". Det handler om at afveje driftsrisiko mod faste omkostninger. Hvis I bygger direkte API'er uden dedikerede interne udviklere og struktureret logning, opbygger I teknisk gæld, der før eller siden resulterer i dyre konsulentregninger eller tabt omsætning.

Omvendt er der ingen grund til at betale 5.000 kr. i månedlig licens for en platform, hvis jeres databehov er statisk og kun involverer to velafgrænsede systemer. Balancen findes i at kende jeres langsigtede systemlandskab og vælge arkitektur derefter.

Overvejer I, hvordan jeres integrationslandskab bedst skrues sammen uden uoverskuelige licenser eller teknisk gæld? Hos Optify rådgiver vi uvildigt om systemintegration, arkitektur og valg af middleware. Book et arkitekturtjek af jeres forretningssystemer, og få en konkret gennemgang af jeres dataflows, risici og besparelsespotentiale.