Arkitektur

Vi arbejder med en række forskellige arkitekturmodeller og -metoder for at sikre, at vores løsninger er skalerbare, sikre og lette at vedligeholde. Vores tilgang er pragmatisk og situationsbestemt, for der findes ikke en "one-size-fits-all"-arkitektur. En god arkitektur er tilpasset de specifikke behov og krav i projektet og den kontekst, den skal fungere i, og den er nærmest altid iterativ og organisk.

Vi designer systemer med tydelige grænser og eksplicitte kontrakter mellem komponenter. Det giver mulighed for at udskifte dele, skalere det, der har brug for det, og teste hver del isoleret. Vi vælger monolit, modulær monolit eller services ud fra teamets størrelse og driftens kompleksitet, ikke ud fra, hvad der er på mode, og vi pakker systemerne i containere og beskriver infrastrukturen som kode, så miljøerne kan genskabes.

Digitale produkter og forretningssoftware stiller forskellige krav. Et produkt skal kunne udgives i nye versioner, bære mange brugere og ofte flere platforme: Apps, web og forbundne enheder, der taler med den samme backend. Forretningssoftware skal oftere integreres med eksisterende systemer og kunne leve og ændres i mange år. Vi designer efter de krav, der gælder.

Domain-driven design (DDD) er et centralt element i vores tilgang. Vi fokuserer på at forstå de forretningsmæssige krav og på at skabe en fælles forståelse, begrebsverden og terminologi mellem teknikere og interessenter.

Integration er en førsteklasses bekymring. Vi arbejder API-first og eventdrevet, hvor det giver mening, og vi dokumenterer grænseflader, så andre leverandører og kundens egne udviklere kan arbejde mod dem.

Vi har en bevidst holdning til cloud. Mange af vores kunder drager fordel af offentlige cloud-platforme, men vi ser også en opblomstring i interessen for digital suverænitet og databeskyttelse og for monolitiske arkitekturer on-prem og i europæiske cloudmiljøer. Udviklingen afspejler en stigende bevidsthed om vigtigheden af at beskytte data og sikre systemers resiliens. Vi rådgiver om, hvilke data og systemer der bør blive i egne rammer eller hos danske og europæiske leverandører, og hvordan man undgår lock-in.

Til dokumentation bruger vi typisk Arc42-formatet og C4-diagrammer, suppleret af relevante UML-diagrammer. Arc42 og C4 er designet til at tjene både tekniske og forretningsmæssige interessenter og er derfor velegnede til at etablere og fastholde en fælles forståelse af, hvad der laves, hvordan det laves, og ikke mindst hvorfor. Arkitekturbeslutninger dokumenteres som Architecture Decision Records, så begrundelsen følger med systemet.