Xurrent bygger en iPaaS inn i ITSM-plattformen sin, uten ekstra kostnad
Xurrent inkluderer nå en innebygd iPaaS i alle abonnement på plattformen for service management. Hvorfor applikasjonsleverandører bygger sitt eget integrasjonslag.
De fleste nyhetene om iPaaS kommer fra integrasjonsleverandørene selv. Denne kommer fra en kunde av integrasjon: Xurrent, en plattform for IT service management som brukes av IT-avdelinger og leverandører av managed services. 23. juni lanserte Xurrent sin egen integrasjonsplattform, bygget inn i produktet og inkludert i alle abonnement uten ekstra kostnad.
Hva Xurrent lanserte
Xurrent iPaaS lar brukerne bygge og administrere integrasjoner direkte i Xurrent, uten et eget integrasjonsverktøy eller egen kode. Ifølge kunngjøringen:
- behandles incidents, endringer, forespørsler og CMDB-poster som egne objekter, ikke som generelle data,
- kobler den seg til systemer som ServiceNow, Jira, Okta, ClickUp og Google Drive,
- er typiske bruksområder opprettelse av brukere, routing av incidents, å legge kontekst til incidents og å holde ITSM og utviklingsverktøy synkronisert.
Produktet er tilgjengelig nå, med generell tilgjengelighet fra 1. juli 2026.
Toppsjefen i Xurrent, Brian Wenngatz, knytter det direkte til AI: integrasjon er det som gjør AI fra råd til handling, og uten den er en AI-agent en dyr demo uten noe å handle på.
Hvorfor det betyr noe
Xurrent er ikke et stort navn innen iPaaS, og trenger ikke å være det. Det interessante er mønsteret. Flere applikasjonsleverandører bygger integrasjon inn i sine egne produkter, fordi AI-funksjonene deres er lite verdt hvis agentene ikke når andre systemer. Integrasjon blir en del av produktet i stedet for et eget innkjøp.
For kunden har en innebygd iPaaS klare fordeler. Den forstår datamodellen i applikasjonen, den er inkludert i prisen, og den driftes av samme leverandør. For en ITSM-plattform gjør det mange integrasjoner mye enklere at den vet hva en incident eller en endring er.
Hvordan det står seg
Ulempen er fragmentering. Hvis hver applikasjon har sitt eget integrasjonslag, ender virksomheten opp med mange små integrasjonsplattformer, hver med egne regler, logger og credentials. Det er nettopp det problemet en sentral iPaaS skulle løse.
Det realistiske svaret er en arbeidsdeling. Integrasjoner som holder seg innenfor ett område, som å koble ITSM og et utviklerverktøy, kan ofte kjøre i det innebygde laget. Integrasjoner som går på tvers av mange områder, eller som bærer sensitive data, hører bedre hjemme i en sentral plattform som integrasjonsteamet kontrollerer.
Hva du bør spørre om
- Hvor skal denne integrasjonen ligge? Lag en enkel regel for hvilke integrasjoner som kan kjøre i innebygde iPaaS-lag, og hvilke som må gå gjennom den sentrale plattformen.
- Kan dere se den? Sjekk om logger og feil fra innebygde integrasjoner kan sendes til den samme overvåkingen som resten.
- Hvem eier credentials? Sørg for at credentials som brukes av innebygde integrasjoner, administreres og roteres som alle andre.
Kilder
Innlegget er skrevet med hjelp av AI og gjennomgått av redaksjonen før publisering.