d60 Lotte Tue Munk
+45 3211 6660 | lta@d60.dk
IT support Lars Kock Larsen
+45 2713 9792 | lkl@d60.dk
Rådgivning og procesanalyse Robert Svarer Olivarius
+45 4058 0002 | rso@d60.dk

d60 Cirqus

Bedre it-systemer gør Business Intelligence bedre

I d60 udvikler vi vores it-systemer, så de kan håndtere data på den bedst mulige måde. Til det formål har vi udviklet et framework baseret på principper fra Event Sourcing + CQRS, som danner udgangspunkt for de fleste af de applikationer, vi udvikler. Vi kalder det d60 Cirqus. Denne måde at udvikle it-systemer på giver hurtigere, bedre og fremtidssikrede it-systemer og  Business Intelligence-løsninger.

It-systemer med en traditionel datamodel kan bruges til at vise verdens nuværende tilstand og besvare rigtig mange spørgsmål. Men ofte er det endnu mere interessant at se på, hvordan vi nåede frem til denne tilstand. Ved at gemme alle mellemregningerne får man mulighed for at besvare spørgsmål, man ikke vidste, man ville stille, på det tidspunkt løsningen blev udviklet. Det giver dermed bedre muligheder for at optimere forretningen fremadrettet. Det er netop dette, d60 Cirqus håndterer.

Med d60’s systemer baseret på d60 Cirqus frameworket kan vi genskabe historien på et splitsekund. Vi kan spole frem og tilbage i tid og fx idenfiticere, hvor fejl opstår, identificere ændringer samt replaye handlinger for at se udviklingen. It-systemer, der er udviklet på denne måde, gør det langt lettere og mindre tidskrævende at sikre god datakvalitet, udvikle skalerbare it-systemer og lave gode Business Intelligence-løsninger.

Helt nye muligheder for brug af data

Systemer baseret på d60 Cirqus opdeles i en skrive- og en læsedel. Skrivedelen gemmer hver hændelse, som brugeren laver i systemet, som et event eller en lille databid. Den anden del abonnerer så på de genererede hændelser. Det betyder, at alle de indtastninger, ændringer, opdateringer osv. som laves i systemet, gemmes som data og kan tilgås i realtid i mange samtidige views.

Fordele

  • Højere datakvalitet

It-system: Nemmere at identificere fejl og optimere processer.

Business Intelligence: Nemmere at udvikle – mindre data cleansing

  • Bedre analysemuligheder

It-system: Mere værdi af samme system.

Business Intelligence: Svar på spørgsmål du ikke har stillet endnu

  • Højere datatilgængelighed

It-system: Højere oppetid og skalerbarhed.

Business Intelligence: Realtime 

  • Øget data performance  

It-system: Bedre brugeoplevelse.

Business Intelligence: Højere frekvens på rapporterne

  • Understøttelse af fremtidige og endnu ukendte behov

Begge: Fremtidssikring

  • Let at generere views og målrette data til forskellige behov

It-system: Nemmere at videreudvikle.

Business Intelligence: Kortere udviklingstid

  • Skalerbar til vækst i virksomheden

Begge: God performance – selvom antal af brugere vokser.

Traditionelle udfordringer forsvinder

Normalt vil det, i de fleste tilfælde, være en umulig opgave at genskabe historiske handlinger af denne art, fordi systemer normalt ikke vil gemme denne historik, men i stedet overskrive den. Storage er efterhånden så billigt at det ikke kan betale sig at smide data ud.


Når man indenfor BI arbejder med data, etablerer man normalt et data warehouse, hvor man integrerer virksomhedens data. Et centralt sted at tilgå data. Men det data, der gemmes, kan kun være det, der er taget en beslutning om at gemme, da man identificerede behovet i sin tid. Med den måde, d60 udvikler systemer på, gemmes al data. Det gør det derfor let at få svar på de spørgsmål man ikke er kommet i tanke om at stille endnu eller hvor der er behov for at kigge tilbage i tid. Det overflødiggør ikke et data warehouse men styrker det.

Eksempler

  • En revisor skal køre en audit.

It-systemet gemmer automatisk, hvem der har ændret noget, samt på hvilket tidspunkt ændringen er sket igennem hele systemets levetid. Dvs. at du kan trække en liste over en specifik kunde, medarbejder osv. og følge forløbet i en detaljegrad, der ikke er mulig med traditionelle systemer eller med traditionel BI.

  • Et Contract-management-system gemmer de kontrakter, der er færdigforhandlet med kunderne.

It-systemet gemmer automatisk alle de trin, der har været i forhandlingen. Dvs. man vil efterfølgende kunne lave en analyse på, hvordan en sælger eller en kunde forhandler. Hvem er de dygtige forhandlere? Hvem starter højt – men slutter lavt. Disse spørgsmål, og andre man kan komme i tanke om, kan kun besvares, fordi alle ”mellemregningerne” er gemt. Dette vil kræve ekstra udvikling i traditionelle systemer, og denne type data kan ikke genskabes bagudrettet.

Lidt om det tekniske 

Event sourcing og command query segregation principle (CQRS) som koncepter er rimelig gamle, men har mest været brugt til at løse problemer i meget specifikke domæner - som f.eks. at holde styr på betalingstransaktioner i banker og gemme transaktionsloggen i databasesystemer.

Event sourcing og CQRS er to af hinanden uafhængige arkitekturprincipper, som tilfældigvis supplerer hinanden virkelig godt og giver nogle fantastiske muligheder, når de kombineres.

Event sourcing

Event sourcing er en måde at gemme data på, hvor man gemmer data som de ændringer, der fører frem til systemets tilstand, i stedet for at gemme systemets tilstand "som den er".

Et eksempel kan være en bankkonto - her kunne man beskrive den nuværende tilstand som "saldo er 10 kr". Dette er den traditionelle måde at gemme en tilstand i almindelige forretningssystemer.

En anden måde at beskrive kontoens tilstand på er at gemme de ændringer, der fører frem til den nuværende saldo - f.eks. "indsatte 20 kr", efterfulgt af "hævede 15 kr", efterfulgt af "indsatte 5 kr". Denne måde at beskrive tilstanden på kaldes "event sourcing", hvilket betyder, at systemets tilstand beskrives med hændelser som kilde.

De to beskrivelser af kontoens tilstand er enige om, at der står 10 kr på kontoen, blot er versionen baseret på event sourcing meget mere detaljeret, idet den bevarer al historik.

CQRS

At gemme systemets tilstand i form at hændelser er effektivt til at beskrive, hvad der er sket, men det er knapt så godt til f.eks. at vise kundens aktuelle balance på skærmen. Tager vi en netbank og eksemplet med bankkontoen, så ville det være uoverskueligt at vise kundens saldo på 5-10 konti, idet samtlige hændelser - måske tusindvis pr. konto - skulle summeres for at finde hver saldo.

Det er her, CQRS kommer ind i billedet og giver en arkitektur, hvor alle systemets hændelser flyder videre og hjælper med at opdatere en live "læsemodel" af systemet, således at man kan se sin saldo i netbanken, uden at systemet skal summere tusindvis af transaktioner for hver eneste saldo. De pågældende saldi er simpelthen forudberegnet og ligger i en separat database, klar til at blive vist på skærmen.         

CQRS står for Command/Query Responsibility Segregation og dækker altså over, at systemet opdeles i en Command-del (der genererer hændelser og på den måde ændrer ting - "skrivemodellen") og en Query-del (der holder sig opdateret med hændelserne i takt med, at de sker - "læsemodellen").

Command-delen tager således imod input (fra brugerens handlinger i systemet) og omsætter de foretagne handlinger til hændelser, som gemmes i event-databasen. Query-delen abonnerer så på de genererede hændelser og kan holde sine views opdateret i realtid. Man kan lave lige så mange former for views, som man ønsker, da det er nemt at distribuere de genererede hændelser rundt, og man kan således holde vilkårligt mange views opdateret på grundlag af hændelserne.

Fordele

Lettere at arbejde med forecasting og simulering

Dette betyder for eksempel, at man lettere i et handelssystem vil kunne finde statistikker og udlede tendenser på grundlag af hændelser - f.eks. "hvor ofte er der problemer med bekræftelsen af aftaler med en bestemt modpart?", "hvor ofte fortrydes handler med en bestemt modpart?", "hvor ofte har en modpart restance i forbindelse med opkrævninger?" osv.

Og den virkelig interessante egenskab ved event sourcing er jo så, at man ikke på nogen måde behøver at forudsige behovet for disse oplysninger - man kan altid på bagkant udlede dem, og de vil indeholde den pågældende information baseret på alt, hvad der er sket, siden systemet blev implementeret.

Det samme gælder, når man introducerer nye views eller ændrer på de eksisterende views i systemet - så kan man blot slette den pågældende læsemodel og lade den blive gendannet ved at køre alle hændelser ind i det pågældende view igen.

Skalerbar

CQRS kombineret med event sourcing giver en super-skalerbar arkitektur, idet læsemodellen af systemet kan have forberedt stort set alle skærmbilleder i systemet, inden der er brugere, der forespørger på det - og da læsemodellerne kan opdateres i parallel, eksempelvis på flere maskiner, er der stort set ingen grænser for, hvor mange views systemet kan holde opdateret.

Tilgængelighed

Derudover kan views distribueres, sådan at man eksempelvis kører systemet lokalt og holder nogle views ajour i skyen - eller omvendt. På den måde giver CQRS nogle unikke muligheder i forhold til at bygge hybride cloud-løsninger.

Fleksibelt

Samtidig har man en enorm fleksibilitet i forhold til repræsentationen af data, idet man med CQRS har mulighed for at modellere data optimalt i forhold til formålet med det enkelte view - de fleste views er måske henvendt mod brugeren og indeholder data til skærmbilleder i systemet, mens andre views kunne tænkes at opdatere en relationel database med information, som bliver benyttet til rapportering.

 

 Find d60 Cirqus på Github HER.

 

 

Integrerede løsninger

Software er igennem historien blevet integreret på mange forskellige måder via filoverførsel, delte databaser og diverse remote procedure call-protokoller, men den model, der bedst understøtter kravet om realtid og integration, er messaging.

Mogens er d60's Technical Evangelist og er to gange blevet udnævnt til MVP af Microsoft for sit arbejde med Enterprise Servicebussen Rebus (https://github.com/rebus-org/Rebus)

Mogens Heller Grabe Technical Evangelist