Vendor-neutral guide

Vad du måste tänka på när du bygger en integrationsförmåga

En integrationsplattform är inte en motor — det är sex dimensioner som måste hänga ihop. Här är checklistan vi går igenom med varje kund innan vi pratar leverantör eller licens. Använd den oavsett om ni går vidare med oss eller någon annan.

Sex dimensioner

Funktion, organisation, SLA, TCO, säkerhet och livscykel

Saknas en av dimensionerna tas kostnaden ut någon annanstans — oftast i förvaltningsbudgeten, i jourtimmar eller i risk. Använd listan som diskussionsunderlag internt eller mot er nuvarande leverantör.

01 · Funktioner

Vilka förmågor behöver faktiskt finnas?

En modern integrationsförmåga är inte en motor. Det är en uppsättning funktioner som måste samspela. Saknas en — tas kostnaden ut någon annanstans.

  • Integrationsmotor(er) för meddelanden, dokument, EDI/HL7
  • API gateway, policy, rate limiting, OAuth & nycklar
  • Event/stream-hantering (Kafka, AsyncAPI)
  • Tjänstekatalog med ägarskap, SLA och beställning
  • Versionering, kontrakt och konsekvensanalys
  • Observability: spårbarhet meddelande → API → infrastruktur
  • ITSM & CMDB kopplat till varje integration
  • AIOps: korrelering, prediktion, auto-remediering
  • Säkerhet, loggning, GDPR/NIS2-spårbarhet
  • Test, mock och kontraktstestning
  • Release-, miljö- och förändringshantering
  • Centralt ramverk för namngivning och felhantering
  • Supportmodell med dokumenterad SLA per nivå

02 · Organisation

Vem äger förmågan — och vem ringer man kl 02?

Tekniken faller om ingen äger den. Integrationsförmågan måste finnas som en tjänst, inte som en hög med projekt.

  • Integration Competence Center (ICC) eller motsvarande
  • Tydligt ägarskap per integration — inte per system
  • Gemensamma arbetssätt över förvaltningar och team
  • Eskaleringsväg L1 → L2 → L3 → leveransledning
  • Plan för nyckelpersonberoenden och kunskapsöverföring
  • En supportväg, ett SLA — inte tre olika per förvaltning

03 · SLA & support

Vad är ni överens om när det brinner?

Utan dokumenterad SLA per prioritet blir P1 och P3 samma sak. Och då blir allt P1.

  • Definierad prioritetsmodell P1–P4 utifrån verksamhetspåverkan
  • Svars- och åtgärdstid per prioritet och nivå
  • Kontorstid, jour eller fullt 24/7 — medvetet val per system
  • Underhållsfönster och förändringsklasser
  • Eskalering, kommunikation och rapportering
  • Tjänstebeskrivning som faktiskt går att granska

04 · TCO & dolda kostnader

Det som inte syns på licensraden

Den största kostnaden ligger sällan i licensen. Den ligger i jourtimmar, manuell felsökning, parallella verktyg och beroenden av enskilda personer.

  • Manuell korrelering vid larm — timmar per incident
  • Larm utan ägare och utan ITSM-flöde
  • Releaser utan konsekvensanalys
  • Parallella verktyg för logg, APM, ITSM och dashboards
  • Återkommande incidenter som ingen hinner åtgärda permanent
  • Beroende av två–tre seniora integratörer
  • Olika arbetssätt per förvaltning
  • Spridda licenser och avtal per verksamhet
  • Spridd supportmodell utan central SLA

05 · Säkerhet & efterlevnad

Spårbart, granskbart, försvarbart

GDPR, NIS2, patientdatalagen, ISO 27001 — alla kräver att ni kan visa vad som hände, vem som hade access och hur länge.

  • End-to-end spårbarhet per meddelande och API-anrop
  • Auktorisering, scopes och nyckelhantering
  • Loggretention och åtkomststyrning
  • Hantering av personuppgifter i loggar
  • Datalokalisering och leverantörsavtal

06 · Livscykel

Från beställning till avveckling

En integration lever i 10+ år. Bygg för förvaltning, inte för leverans.

  • Beställningsflöde via tjänstekatalog
  • Standardiserad design, kontrakt och namngivning
  • Automatisk testning och miljöhantering
  • Förändringshantering — standard, normal, akut
  • Avveckling och migrering utan big-bang
  • Kapacitets- och kostnadsuppföljning

Vad kostar det att inte ha det

Kostnaderna syns sällan i licensen — de syns i driftbudgeten

30–60%

av jourvolymen

är återkommande felmönster som ingen hinner bygga bort. Korrelering och AIOps tar bort merparten.

2–5×

MTTR utan observability

Tekniker hoppar mellan loggverktyg, integrationsmonitor och infrastrukturövervakning innan rätt person är engagerad.

3–4×

fler verktyg än nödvändigt

Egen logg, separat APM, separat ITSM, separat dashboard — var och en med eget avtal och kompetensbehov.

Veckor

leveranstid per integration

utan tjänstekatalog, standarder och självbetjäning. Med katalog: dagar.

2–3 personer

vet hur allt hänger ihop

Semester, sjukdom eller uppsägning blir en akut risk. Ny personal tar månader att produktivisera.

0 SLA

i praktiken

Olika förvaltningar har egna supportvägar. Ingen kan visa svars- eller åtgärdstid mot ett gemensamt åtagande.

Siffrorna är typiska för organisationer som vuxit ur en projektbaserad integrationsmodell utan att modernisera ramverk, ITSM eller observability. Vi gör gärna en baseline-mätning hos er innan ni beslutar om plattform.

Vår lösning

Sex dimensioner i en svit — Swedwise Healthcare Suite

Vi har samlat alla sex dimensioner i en sammanhållen svit. Samma ramverk, samma katalog, samma ITSM-flöde, samma supportmodell — oavsett om integrationen körs på xT, MuleSoft eller Omnigateway. Ett ägarskap, en avtalsbild, en livscykel.

Integration & API

xT, MuleSoft och Omnigateway under ett gemensamt ramverk för säkerhet, kontrakt och felhantering.

Governance & katalog

Tjänstekatalog, ägarskap, beställning, versionering och konsekvensanalys i ett flöde.

Observability & AIOps

End-to-end spårbarhet, korrelerade larm och föreslagna åtgärder över hela kedjan.

ITSM & CMDB

ServiceNow-baserat flöde där varje ärende är kopplat till exakt det API eller meddelande som triggat det.

Support med SLA

Base, Enterprise eller Platinum. P1 24/7 på Enterprise — fullt 24/7 på Platinum.

Livscykel & förvaltning

Från beställning till avveckling, med strangler-mönster för migrering utan big-bang.