Design af et Event-Driven Architecture-baseret system

Trustpilot.com gør det, famly.dk gør det, mikz.com og CPR-registeret gør det.

Alle disse virksomheder og organisationer bruger i varierende grad hændelser i krav, systemdesign og kode (og jeg har hørt, at Saxo Bank gør det!). Visse af dem bruger hændelser som en teknisk løsning på skaleringsproblemer, andre som en mere bevidst tilgang allerede i systemdesignet. Imellem disse virksomheder og organisationer varierer tilgangen og teknologierne i de konkrete realiseringer. Definitionen af en hændelse, hvad den repræsenterer og hvordan den skal bruges, varierer tilsvarende.

I løbet af det seneste år er der sket en del i EDA-regi for mig. Jeg har arbejdet på projekter, hvor hændelser beklageligvis var helt fraværende i systemdesignet og teknikken, og hvor hændelsesorientering kunne have løst mange problemer og mindsket hård binding imellem både processer og delsystemer. Jeg fik også fornøjelsen af at blive bedt om at gennemlæse og give feedback på Digitaliseringsstyrelsens kommende referencearkitektur for håndtering af hændelser, og var desuden været involveret i en superinteressant workshop hos styrelsen om definition af hændelser, som skulle udveksles imellem DAGI, DAR og CPR via Grunddataprogrammets Fælles Datafordeler.

En af de ting, jeg blev bedt om ved Digitaliseringsstyrelsen, var at komme med forslag til hvordan arbejdet med hændelser kunne forbedres. Et af mine forslag var, at man burde komme med et eksempel på, hvordan et system konkret designes. Med andre ord, hvordan man igennem kravspecifikation, analyse og (senere) design får kommunikeret sine hændelsesorienterede ønsker. Dette mener jeg er særligt vigtigt, når man som organisation skal give specifikationen videre som en del af et udbudsmateriale.

Ovenstående forslag kom jeg med ud fra en overbevisning om, at det ikke er nok at forklare fordelen ved brug af forretningshændelser på forretningsniveau, og at det er ikke nok at læse en bog om en konkret teknologi eller platform. For meget baggrundsviden falder imellem stolene, og et eventuelt tiltag vil enten være forretningsdrevet uden teknisk understøttelse, eller en teknisk tilgang uden forankring i virksomheden. Og vi har jo set før, hvordan det ender!

Der er brug for en guide, der tager udgangspunkt i det generelle, danske IT-landskab, som det ser ud i dag og som kombinerer forretningsperspektivet med teknologi. En sådan guide skal give et konkret eksempel på, hvordan et EDA-baseret system kan designes, samt hvilke muligheder det giver i forhold til status quo. Med andre ord, der brug for en model for, hvordan man repetitivt kan kravspecificere, analysere og designe systemer, der baserer sig på eller udnytter EDA! 

Et forsøg på en sådan guide går jeg i gang med nu! Hvis du synes det lyder som en god idé og gerne vil følge med, så giv mig et praj nedenfor, så vil jeg sende dig et link, efterhånden som jeg får noget ned på skrift. Tidshorisonten er 2-3 måneder.

Dit navn (skal udfyldes)

Din e-mail (skal udfyldes)

Hvad er dine erfaringer med EDA? Hvilke emner kunne du godt tænke dig se blive behandlet i guiden? Er du skeptisk - hvorfor?

 Ja, jeg kunne godt tænke mig at være beta-læser