Hændelsesdrevet arkitektur (EDA) er en måde at bygge software på, hvor dele af et system kommunikerer ved at annoncere, at noget er sket, i stedet for at kalde hinanden direkte. Én komponent udgiver en hændelse, f.eks. “faktura betalt” eller “kontrakt underskrevet”. Enhver anden komponent, der er interesseret, reagerer på den. Ingen af siderne behøver at vide, at den anden findes.

For en SaaS-virksomhed har det betydning langt ud over engineering. Den samme idé ligger bag rene overdragelser fra CRM til økonomi, pålidelig automatisering og AI-agenter, der handler på aktuelle data. Denne guide forklarer, hvordan EDA fungerer, hvordan en event bus adskiller sig fra en kø, hvordan man undgår de almindelige fejl, og hvor den hører hjemme, og hvor den ikke gør.

Kort fortalt

Indholdsfortegnelse

Hvad hændelsesdrevet arkitektur er

Microsofts retningslinjer for arkitektur beskriver stilen som hændelsesproducenter, der genererer en strøm af hændelser, hændelsesforbrugere, der lytter efter dem, og hændelseskanaler, der bærer hændelser fra den ene til den anden. Den tredelte model er hele idéen. Alt andet er detaljer om, hvor pålideligt og hvor hurtigt kanalen fungerer.

Kontrasten er request/response. I et request/response-design kalder din faktureringstjeneste dit CRM og venter på svar. Hvis CRM’et er langsomt eller nede, sidder fakturering fast. I et hændelsesdrevet design udgiver fakturering “betaling modtaget” og går videre. CRM’et, omsætningsrapporten og dashboardet for customer success henter hver især hændelsen, når de er klar.

To egenskaber følger heraf:

Hvad der tæller som en hændelse

En hændelse er et faktuelt udsagn i datid. Red Hat beskriver den som en uforanderlig registrering af, at noget er sket, ofte med et tidsstempel, der bevarer rækkefølgen i forhold til det system, der producerede den. Du redigerer ikke en hændelse bagefter. Hvis noget ændrer sig, registrerer en ny hændelse ændringen.

AWS bemærker, at hændelser kan være en tilstandsændring eller en opdatering, og at de enten kan bære tilstand eller være identifikatorer. To eksempler:

Type Eksempel Hvad forbrugeren får
Hændelse, der bærer tilstand Abonnement opgraderet, med plan, pris, ikrafttrædelsesdato og konto-ID Alt, hvad der skal til for at handle uden endnu et opslag
Hændelse som identifikator Ordre afsendt, kun med ordre-ID Et signal. Forbrugeren henter detaljerne fra kildesystemet

Den første er praktisk, men kobler forbrugerne til hændelsens form. Den anden holder hændelserne små, men sender forbrugerne tilbage til kildesystemet, hvilket rejser spørgsmålet om, hvilket system der er autoritativt. Vi vender tilbage til det nedenfor, fordi det er der, de fleste SaaS-virksomheders driftsopsætninger kommer i problemer.

En kommando er ikke en hændelse. “Send fakturaen” er en instruktion til en bestemt modtager. “Faktura sendt” er et faktum, som alle kan reagere på. At blande de to er en almindelig designfejl og genopbygger stille og roligt den tætte kobling, du forsøgte at fjerne.

Sådan fungerer et hændelsesdrevet system, trin for trin

Google Clouds dokumentation beskriver forløbet: producenter genererer hændelser, en router eller broker modtager og filtrerer dem og fordeler dem derefter til forbrugere på baggrund af abonnementer eller triggere. I praksis:

  1. Noget sker. En deal bliver flyttet til “Closed Won” i CRM-systemet.
  2. Producenten udgiver en hændelse. Den angiver kendsgerningen og den post, den vedrører.
  3. Brokeren router den. Den filtrerer hændelsen og leverer den til alle abonnenter.
  4. Forbrugerne reagerer uafhængigt af hinanden. Økonomi opretter et fakturakladde. Customer Success åbner en onboarding-plan. En provisioneringsproces forbereder adgang.
  5. Hver forbruger kvitterer. Brokeren ved, at hændelsen er håndteret, og kan forsøge igen, hvis den ikke blev det.

IBM beskriver det samme mønster som udgivelse, indfangning, behandling og lagring af hændelser og påpeger, at en hændelses værdi kan ændre sig over tid. En “ny lead”-hændelse er værd at handle på inden for få minutter. Et år senere er den mest nyttig til analyse.

Hændelsesdrevet arkitektur og mikroservices

Man behandler ofte disse to begreber som det samme. Det er de ikke. Mikroservices beskriver, hvordan man opdeler en applikation i små, uafhængigt udrullede services. EDA beskriver, hvordan disse services kommunikerer. Man kan have mikroservices, der kalder hinanden synkront, og man kan have en monolit, der udgiver hændelser internt.

De to fungerer godt sammen. Googles vejledning bemærker, at mikroservices kan reagere asynkront på hændelser og kun behøver at kende hændelsesformatet, ikke hinandens forretningslogik. Det fælles format er kontrakten. Alt bagved kan ændre sig.

Microsofts dokumentation beskriver det typiske mønster som mikroservices, der udgiver en hændelse, når der sker noget bemærkelsesværdigt, mens andre mikroservices abonnerer.

Event bus vs. kø vs. strøm

Disse tre begreber skaber mest forvirring, og valget ændrer, hvordan dit system opfører sig.

Event bus (publish/subscribe). En event bus er en mekanisme, hvor udgivere annoncerer hændelser, og abonnenter modtager dem. Microsoft forklarer, at den kan implementeres på messaging-infrastruktur som en kø eller en service bus, der understøtter asynkron publish/subscribe. En kø kan altså være en af byggeklodserne i en bus. Bussen er hensigten. Køen er én måde at gennemføre den på.

Kø. En kø rummer beskeder, indtil en worker henter dem. Hver besked håndteres normalt af én forbruger. Køer er det rigtige værktøj til at fordele arbejde på flere workers og til at absorbere spidsbelastninger. Azures integrationsvejledning nævner at sætte beskeder i kø, når et back end er utilgængeligt, som én grund til at bruge en broker.

Event stream. Azure adskiller publish/subscribe fra streaming. I publish/subscribe gælder, at når en hændelse er modtaget, gemmes den ikke i en varig log, så nye abonnenter ikke ser tidligere hændelser. Ved streaming skrives hændelser til en log, der er varig og strengt ordnet inden for en partition, og klienter læser fra loggen og kan til enhver tid tilslutte sig og afspille hændelser igen.

Kø Publish/subscribe-bus Event stream
Levering Én forbruger pr. besked Alle abonnenter Enhver læser, fra et vilkårligt punkt
Tidligere hændelser Fjernes efter behandling Ikke tilgængelige for nye abonnenter Gemmes og kan afspilles igen
Typisk brug Arbejdsfordeling, buffering Underretning af flere systemer Historik, analyse, genopbygning af tilstand

En praktisk tommelfingerregel: Hvis flere systemer skal reagere på den samme kendsgerning, så brug publish/subscribe. Hvis én worker skal udføre et job, så brug en kø. Hvis du har brug for historik eller muligheden for at genopbygge et efterfølgende system, så brug en stream. Red Hat tilføjer, at der ikke findes én løsning, der passer til alt, så vælg teknologi efter hændelsestype.

Er Kafka en hændelsesdrevet arkitektur?

Nej. Kafka er en teknologi, du kan bruge til at bygge en sådan. Dokumentationen til Apache Kafka beskriver den som en platform til event streaming: at indfange hændelser i realtid, lagre dem varigt, behandle dem og route dem til andre systemer. Det gør den til en event stream i tabellen ovenfor.

En arkitektur er et sæt designbeslutninger: Hvad er hændelserne, hvem ejer dem, hvordan isoleres forbrugerne, og hvad sker der ved fejl. Du kan træffe disse beslutninger og køre dem på en administreret cloud-bus, en kø-tjeneste eller Kafka. Du kan også køre Kafka og stadig have et tæt koblet system, hvis hver service afhænger af en anden services interne hændelser. Vælg værktøjet, efter du har defineret hændelserne og den volumen, du reelt forventer.

Hændelsesdrevet integration og automatisering

Her bliver EDA relevant for ledere i driften og ikke kun for ingeniører.

Integration

De fleste SaaS-virksomheder forbinder deres CRM-, fakturerings-, support- og produktdata med punkt-til-punkt-synkroniseringer. Hvert nyt værktøj tilføjer endnu en forbindelse, der skal vedligeholdes. Azure anbefaler asynkron kommunikation via en message broker i stedet for direkte synkrone kald af fire grunde, som Azure selv oplister: afkobling af applikationer, udsendelse til flere forbrugere, pålidelig sporing af langvarige workflows og kø-lagring af beskeder, når et back end er utilgængeligt.

Fordelen viser sig, når du tilføjer et system. Med en publish/subscribe-tjeneste kan nye abonnenter tilføjes uden at opdatere afsenderen. Tilføjelsen af et nyt analyseværktøj kræver ingen ændring i dit CRM.

Automatisering

Hændelsesdrevet automatisering betyder, at en forretningsproces starter, fordi der skete noget, ikke fordi nogen klikkede på en knap, eller et natligt job kørte. ServiceNows flow-guide giver en praktisk metode: identificér triggeren, planlæg logikken, vælg handlingerne og identificér genbrugelig logik. Den anbefaler også at holde flows fokuserede og bruge ét verbum pr. handling.

Når en proces strækker sig over flere services, bemærker Microsoft, at hændelsesdrevne systemer ofte bruger koreografi- og saga-orkestreringsmønstre til at koordinere forløbet. Ved koreografi reagerer hver service på hændelser og udsender sine egne. Ved orkestrering fortæller en koordinator hvert trin, hvad det skal gøre, og følger hele processen. Til et første projekt er et orkestreret flow som regel lettere at læse og revidere.

Et enkelt SaaS-eksempel:

Best practices og almindelige udfordringer

Azure peger på de vigtigste udfordringer: eventual consistency, asynkron fejlhåndtering, datatab, observerbarhed og test, for mange eller for sammenlagte hændelser samt skemaudvikling. Hver af dem har en tilsvarende praksis.

  1. Planlæg for eventual consistency. Systemerne vil kortvarigt være uenige. Beslut, hvilket system der er autoritativt for hver enkelt oplysning, og lad de andre følge det.
  2. Tilføj en dedikeret fejlhåndtering. Hændelser, der fejler, har brug for et sted at gå hen og en person, der ser på dem.
  3. Behold hændelser, indtil modtagelsen er bekræftet. Det beskytter mod datatab, når en forbruger er nede.
  4. Brug korrelations-ID'er. Ét ID, der følger med gennem hvert trin, gør det muligt at spore en enkelt kundehandling på tværs af systemer.
  5. Find den rette granularitet for hændelser. Én hændelse pr. feltændring skaber støj. Én kæmpehændelse for alt genskaber den tætte kobling.
  6. Versionér skemaer tidligt. Hændelsesformater vil ændre sig. Beslut hvordan, før du har tyve forbrugere.

Til disse vil vi tilføje tre driftsvaner: navngiv hændelser i datid, giv hver hændelsestype én ejer, og skriv ned, hvilke forbrugere der afhænger af den.

Hvor hændelsesdrevet design ikke hører hjemme

EDA er ikke svaret på alle problemer. Vær tydelig om begrænsningerne, før du forpligter dig:

Den samme logik gælder for AI. En AI-assistent, der læser og handler i dine systemer, er både forbruger og producent af hændelser. Hvis den læser inkonsistente data eller handler uden en tilladelsesgrænse, har du fået en hurtigere måde at begå fejl på.

Hvor det møder AI-agenter og compliance

AI-agenter, der henter data (spørger, rapporterer, slår op) og sender data (opdaterer en post, udløser en proces, tildeler adgang), opfører sig som deltagere i et hændelsesdrevet system. De har brug for en pålidelig kilde at læse fra, et klart afgrænset sæt handlinger, de må udføre, godkendelse af følsomme trin og en registrering af, hvad de har gjort. En hændelseslog er et naturligt sted for den registrering.

Operatør, der gennemgår en AI-agents hændelseslog

For europæiske virksomheder påvirker GDPR, NIS2 og EU AI Act alle, hvordan sådanne systemer designes. Generelt har de betydning for, hvilke personoplysninger der flyder gennem hændelser, hvordan sikkerhed og håndtering af hændelser organiseres, og hvordan AI-systemer styres og dokumenteres. Behandl dem som designinput fra start, og indhent juridisk rådgivning hos en jurist om, hvordan de gælder i netop jeres tilfælde. Intet arkitekturvalg gør i sig selv et system compliant.

Vores perspektiv

De fleste SaaS-virksomheder, vi taler med, har ikke et hændelsesproblem. De har et ejerskabsproblem. Flere teams bruger AI, flere værktøjer rummer hver deres version af kunden, og ingen er ansvarlig for, hvilken version der er rigtig.

Derfor arbejder vi i en fast rækkefølge. Først data foundation: CRM- og økonomidata som den aftalte sandhedskilde. Derefter AI-laget, der forbinder de data med den assistent, jeres team allerede bruger. Så afdelingsagenter til Finance, Sales og Customer Success. Hændelser er nyttige i alle tre lag, men de hjælper først, når de fakta, de bærer, er aftalt.

Vi indfører også én proces ad gangen og begynder med den dyreste. En fornyelsesproces eller en overdragelse fra faktura til betaling er et bedre første hændelsesdrevet projekt end en virksomhedsdækkende ombygning. Du ser resultatet, dine folk lærer mønstret, og den næste proces bliver billigere.

Fordi vi driver operationer og ikke kun designer systemer, går vi op i de kedelige dele: tilladelser, godkendelser, revisionsspor og en overdragelse, hvor du ejer koden, dokumentationen og infrastrukturen.

Claus Nielsen

Kom i gang i din egen virksomhed

Du behøver ikke vælge en broker først. Start med disse spørgsmål:

  1. Hvilken proces koster dig mest i manuelt arbejde, forsinkelser eller fejl?
  2. Hvilke to eller tre hændelser sætter den i gang (for eksempel aftale lukket, faktura forfalden, fornyelse nærmer sig)?
  3. Hvilket system er sandhedskilden for dataene i disse hændelser?
  4. Hvem ejer hver hændelsesdefinition?
  5. Hvilke trin kræver menneskelig godkendelse?

Hvis du ikke kan besvare det tredje spørgsmål, kommer data foundation først. Hvis du kan, vil et lille pilotprojekt på én proces vise dig, om en hændelsesdrevet tilgang kan betale sig.

Sådan kan vi hjælpe

Hvis jeres team bruger AI, men ingen ejer det, kan vi hjælpe jer med at beslutte, hvor det kan betale sig, og bygge det i den rigtige rækkefølge. Vores AI Readiness Assessment fås fra €4,500 og ser på jeres data, systemer og processer, før noget bygges. Hvis I ønsker løbende ledelse, starter Fractional Chief AI Officer-aftalen fra €1,500 pr. måned.

Løsninger prissættes til 30% af en første-års besparelse, der er målt og dokumenteret, eller til en fast pris aftalt, før arbejdet begynder. Du kan også booke et gratis opdagelsesopkald på 30 minutter via vores side. Vores AI-agenter til Finance, Sales og Customer Success viser, hvordan afdelingslaget ser ud, når fundamentet er på plads.

FAQ

Hvad er hændelsesdrevet arkitektur i enkle ord?

Det er et design, hvor softwarekomponenter meddeler, at noget er sket, og andre komponenter reagerer. Afsenderen ved ikke, hvem der lytter. Det gør det muligt at tilføje eller ændre systemer uden at omskrive dem, der producerer hændelserne.

Hvad er forskellen på en event bus og en message queue?

En kø leverer typisk hver besked til én arbejder. En event bus leverer hver hændelse til alle abonnenter. En bus kan bygges på køinfrastruktur, så forskellen ligger i hensigten og leveringsmønstret, ikke altid i produktet.

Er hændelsesdrevet arkitektur det samme som mikroservices?

Nej. Mikroservices handler om, hvordan en applikation opdeles i services. Hændelsesdrevet arkitektur handler om, hvordan delene kommunikerer. De bruges ofte sammen, men hver kan eksistere uden den anden.

Hvornår bør en SaaS-virksomhed bruge hændelsesdrevet automatisering?

Brug den, når en forretningsproces skal starte ud fra et faktum, for eksempel en lukket aftale eller en forestående fornyelse, og flere teams eller systemer skal reagere. Start med én dyr proces, og sørg for, at kildedataene er aftalt på forhånd.

Kilder