Fællesoffentlig Datafordeler – Åh nej…

Da jeg hørte om Fællesoffentlig Datafordeler (FD) for første gang, var det som del af en dialog om udvikling af systemer med beskedudveksling som en integreret del af applikationsdesignet. Jeg spurgte lidt mere ind til løsningen, og vedkommende fortalte mig, at jo, den var god nok, man havde planer om at lave en stor, central platform for dataudveksling imellem udvalgte myndigheder.

TL;DR Hører om et nyt offentligt IT-projekt, der umiddelbart vækker dårlige minder og associationer. Men ved gennemlæsning af udbudsdokumenter lærer jeg, at man faktisk har taget hånd om de største forbehold, jeg personligt har til offentlige IT-projekter, og har tænkt nogle gode tanker. Læs videre, hvis du vil vide, hvad nogle af dem er…

Min første reaktion på denne nyhed havde sit ophav i forskellige inputs, jeg har fået, og erfaringer, jeg selv har akkumuleret:

  • Først og fremmest de historier vi alle kender fra medierne om store, offentlige IT-projekter, som skal være åh-så-omsiggribende, og som enten fejler på det groveste eller bliver 3-4 gange dyrere end forudset (dog ser tendensen ud til at være brudt).
  • At udvikling af store, centrale systemer (læs: monolitiske, på trods af de SOA-venlige intentioner, man starter med) generelt går imod min overbevisning om hvordan systemer bør bygges.
  • At jeg for nogle år siden arbejdede med en større dansk virksomhed, som havde opbygget en intern broker, der skulle stå for at udstille services og data fra gamle, proprietære systemer – og de kæmpede med konstant med (1) teknisk performance, (2) meget forskellige (og nogen gange enorme) data og (3) at få nye endpoints på løsningen, da kun nogle få specialister kunne udvide brokeren.
  • At alle offentlige løsninger, der starter med “Nem” eller “Fælles” generelt giver mig udslæt, givet min og andres erfaring med de eksisterende, centrale produkter under disse betegnelser.

Jeg må indrømme at min første reaktion var … “Åh nej”.

De kritiske spørgsmål hobede sig derudover op på få sekunder: (1) hvordan skal en løsning, som tilsyneladende tager udgangspunkt i en brokerarkitektur, succesfuldt kunne opfylde sin rolle (både teknisk og organisatorisk) på tværs af myndigheder, når det er en enorm udfordring vedligeholde en tilsvarende løsning for bare en enkelt virksomhed? (2) hvordan skal videreudvikling og tilkobling af nye systemer kunne gennemføres med en god kadence? (3) dataduplikering – er det ikke et generelt anti-pattern at lade et andet system repræsentere sine data (ud fra et SOA-perspektiv)?

Nå, jeg rystede det af mig – jeg havde nok at se til i mit eget projekt.

Lidt nysgerrig, alligevel…

Jeg har stor interesse for udvikling af skalérbare systemer, hvor asynkronitet og out-of-web-process er en indbygget del af applikationsarkitekturen, og hvor messaging ikke kun en tilgang og teknologi, men benytter sig af ved integration til andre systemer, men derimod benytter aktivt i applikationsdesignet. Og jeg kender vejen til success med sådanne implementationer, og jeg kender hvilke tradeoffs, der følger med. Så interessen for FD forlod mig aldrig rigtigt. Den lagde sig i baggrunden (no pun). Og forleden blev jeg alligevel nysggerig nok til at vende tilbage igen: Hvad var den nu for noget, hvor kommer den fra, hvad skal den – og hvordan? Det er da lidt interessant :-)

Så jeg vendte tilbage til hjemmesiden og begyndte at skimme. Jeg downloadede udbudsmaterialet og begyndte at læse. Det følgende er et antal udvalgte observationer og personlige kommentarer til projektet, som sikkert ikke kommer hele vejen rundt, og som udelukkende fokuserer på ting, jeg finder interessante. Så hvis du vil have hele billedet, kan jeg anbefale at hente Bilag 3, Leverancebeskrivelse, en godt 90 siders kravspecifikation, selv gå i krig. Derudover skelner jeg ikke om kravene er must have, eller optioner.

Udfordringerne

Overordnet er udfordringerne, som FD skal løse, dels at ensrette adgangen til data fra et antal udvalgte registre (CPR, CVR, kort-/matrikel, m.fl.). Det nævnes at det er en udfordring for nuværende aftagere af data, at de skal tilgå forskellige systemer. En ting er at registrerene lever i deres egne øer, men jeg antager, der også er tale om en bred skare af forskellige teknologier (eller sågar samme teknologi, men i forskellige versioner) og adgangskontroller.

Derudover vokser antallet af opslag konstant. Som et eksempel, kan det nævnes at antallet af opslag på kortforsyningen forventes at være på 2 milliarder opslag her i 2014(!). Der er behov for en løsning, der kan bære alle disse læsninger, og kravet til FD er 2000 opslag i sekundet ved spidsbelastning. For at kunne opfylde belastninger i denne størrelsesorden, er der fokus på at FD skal kunne auto-skalere, som man kender det fra cloud-baserede løsninger (man noterer her, at personfølsomme informationer nok ikke kan lægges ud i skyen, men andre, mere generelle data burde kunne). (Skat.dk kunne måske lære noget her, angående auto-skalering?)

Alt ovenstående, ref. Opsamling Teknisk Dialog.

Indtil videre virker intentionerne ganske gode, og man har tænkt nogle gode tanker, og har fået gode input fra de 15 leverandører, der har deltaget i dialogen.

FD’s roller

Udbyder af data

Selv efter jeg havde læst bevæggrundene i Opsamling Teknisk Dialog var jeg stadig lidt lunken. Tanken er jo, at alle de involverede registre skal kopiere deres data til FD. Jo jo, det er da en fordel at FD infrastrukturelt er gearet til de mange læsninger på disse data, som fremtiden byder på. Men som nævnt tidligere, så mener jeg også at rå dataduplikering kan være lidt af et antipattern. Man overlader jo ansvaret til at sikre datakorrekthed og tilgængelighed til “anden part”, i stedet for at holde kortene ind til kroppen. Opslag på rå data kan fungere og kan give mening, hvis man som aftager udelukkende er interesseret i at kende state på opslagstidspunktet. Og det giver da mening at gøre disse data tilgængelige i en form og på en måde, der er optimerede imod læsninger.

Med andre ord, og måske lidt søgt, hvis man kender til CQRS (Command / Query Responsibility Segregation), så man kan sige, at registrene (som håndterer “Commands”), nu får en stor, fed platform (i positiv forstand), hvorfra registrenes “Queries” kan udbydes. Purister ville sikkert sige, at ansvaret for at udbyde Query-modeller skulle indeholdes i samme service / system, hvor tilhørende Commands håndteres – at ansvaret skal holdes ét sted. Men, og jeg gætter her, realiteterne er jo nok, at det ikke giver mening at udbygge / opgradere eksisterende registre hver for sig til mængden af forventede læsninger. Så dette tradeoff omkring ansvar i forhold til FD’s infrastrukturelle styrke må siges at være helt retfærdig, efter min mening.

Processen for overførsel af data er defineret således (gengivet med tilladelse, fra kravspecifikationen sektion 2.4.3):

FD - Opdatering af Register

Diagram for processen Opdatering af Register

Afhæntning kan så ske som udlæsning af onlinedata…

FD - Hent online data

Diagram for processen Hent online data

… eller som bestilling af data:

FD - Hent filudtræk

Diagram for processen Hent filudtræk

Men ofte er det jo ikke bare nok at kende basal state. Men er jo også interesseret i at vide hvorfor data har ændret sig.

I mit seneste projekt havde vi lige præcis en sådan udfordring, i sin absolut simpleste form, men som jeg synes beskriver problemstillingen ret fint: vi skulle modtage en dato fra et andet system. Vi lærte fra systemejer, at datoen kunne være midlertidig og systemberegnet eller repræsentere resultatet fra en konkret sagsbehandling. Men vi fik kun datoen. Ingen kontekstinformation. Egentlig overvejede / ønskede vi at udskyde følgeeffekterne i vores modtagersystem til kun blive udført når vi modtog datoen fra sagsbehandlingen, og således ignorere den midlertidige dato. Når man ikke har kontekst for dataændringer introduceres enten ikke helt præcis forretningslogik … eller hacks. Derudover kan det siges, at modtagersystemet overlades til selv at finde ud af, hvornår data er ændrede. Hvad vi havde brug for var en eller anden indikator for, hvilken forretningsmæssig type, datoen repræsenterede.

Beskedudveksling

Min interesse blev derfor for alvor tændt, da jeg kiggede igennem kravspecifikationen, og kunne se, at FD’s rolle er mere end blot “passiv”, skalérbar  udbyder af duplikerede data, som er kopieret til FD. Dette giver sig allerede til udtryk i Hent filudtræk processen ovenfor, hvor der indbygget asynkronitet i behandlingen af forespørgslen. Noget processing-tilstand må således forventes at være til stede, lige som messaging patterns som correlation id må være i spil, for at modtager kan matche resultatet til oprindelig forespørgsel.

Men der er en proces, som er endnu mere interessant og kraftfuld (siger jeg, på denne blog, hvilken overraskelse :-) , og det er muligheden for registrene at publicere forretningshændelser via FD, og for andre registre / aftagere at abonnere på disse forretningshændelser. Boom! En publish / subscribe model til notifikation af forretningshændelser, på tværs af registrene!

Beskedbaseret publish / subscribe er utroligt stærkt, især hvis de rigtige tekniske mekanismer er på plads og de rigtige patterns bruges til situationen. Dels skal der være god performance (i krav 3.162 opererer man med nær-realtid aflevering af hændelsesbeskeder til abonnenter), og dels skal der være mekanismer på plads, hvis et modtagersystem midlertidigt er nede (retry-strategi, durable messaging etc.), og ligeledes for sikring af, at samme besked ikke dobbelt-processeres. I relation til konkret implementation af disse hændelser, vil valget typisk stå imellem tykke beskeder med al state (som omtalt i bl.a. i bogen Event-Driven Architecture) eller tynde beskeder, hvor beskederne kun indeholder identifiers på de opdaterede data, og hvor data eventuelt efterfølgende udlæses som følge af hændelsen (hvilket så åbner for nogle udfordringer, hvis beskederne er forsinkede, og der sker flere opdateringer). Disse tilgange berøres i kravspecifikationens sektion 5.4.1.

I FD arbejder man med to klasser af hændelser: datanære hændelser og forretningshændelser (kravspecifikation, sektion 5.4.1). De datanære hændelser kan kort sagt siges at være hændelser dannet på baggrund af CRUD i FD, og det er FD, der står for at danne og publicere disse hændelser (krav 3.174).

FD - Hændelser

Diagram for Hændelser

Datanære hændelser dannet af FD er en god start, men ville f.eks. ikke løse det forretningsmæssige eksempelproblem, jeg nævnte tidligere om datoen, vi havde behov for, og dens manglende kontekst. FD giver dog mulighed for registrene at danne specifikke forretningshændelser (på et højere niveau, så at sige) og publicere dem. Med disse forretningshændelser er der mulighed for at kommunikere at hændelsen er forekommet og data relateret til hændelsen. I forhold til tidligere nævnte problem kunne dette eksempelvis være DatoFastlagtAfSagsbehandler. Dette ville have løst vores problem.

Det er mig ikke helt tydeligt, om registrene konkret udformer hændelserne (givet ovenstående digram ser det ikke sådan ud) og publicerer dem, eller blot bruger en uniformt format og en foruddefinerede hændelseskoder, som eksempelvis kunne repræsentere hændelsen DatoFastlagtAfSagsbehandler, og FD så står for konkret at generere og pulicere hændelsen. Jeg tror det sidste, muligvis for at holde de tekniske konsekvenser ved indførsel af hændelsesbeskeder på et minimum for registrene.

Alle hændelser skal potentielt kunne leveres som push eller pull (krav 3.175), hvor sidstnævnte stiller krav til at FD opretholder et arkiv af hændelser. Ud over at understøtte pull muliggør dette også seeding af kommende services / systemer.

Til ovenstående fremgår det også, at man søger at understøtte et multileverandørmiljø. Det lyder umiddelbart godt, da dette forhindrer at kun nogle få kan opdatere FD til f.eks. at indeholde og udbyde nye data. Det vil dog blive rigtig spændende at se, hvordan dette konkret vil blive løst, især hvis man skal understøtte vilkårlige releasevinduer fra leverandørerne bag de forskellige registre. Meget spændende udfordring for systemforvaltningen :)

Nå, jeg tror ikke jeg vil trække denne blog post længere…

Efter at have læst udvalgte dele af specifikationen igennem, er det betryggende at vide, at man har haft fokus de problemområder, jeg personligt har set som en hæmsko for en sådan løsning (performance, centraliceret udvikling på platformen – kun af specialister). Dertil ser jeg det personligt som en force, at man vil introducere af distribution af forretningshændelser imellem registrene, og må jeg sige at jeg tror Fællesoffentlig Datafordeler blive et godt svar på de udfordringer, man forsøger at løse. Spændende projekt, som bliver interessant at følge!

Christer Ø. on twitterChrister Ø. on linkedin
Christer Ø.
Software Development Consultant stratal ApS
Christer Østergaard er freelance forretningsanalytiker og softwarearkitekt med mere end 16 års erfaring. Har arbejdet med STAR (tidl. Arbejdsmarkedsstyrelsen), DSB, Kommunernes Landsforening, Digitaliseringsstyrelsen, Egmont, Banedanmark, Elsparefonden, Armada Shipping, Unik HR, Fødevareministeriet og Ministeriet for Flygtninge, Indvandrere og Integration, Knowledge Cube, mikz.com, Ankestyrelsen m.fl. Dertil et par Open Source projekter. Lige nu læser Christer Data and Reality. Christer er klar til at sikre leverance af nye softwareprodukter fra 1. Januar 2016.