Når man skal evaluere arkitekturen til en løsning er det fort å bli overveldet og ikke helt vite hvor man skal begynne eller å bruke nesten all tid på det du selv kan best. For å sikre at man får evaluert de viktigste tingene og sett løsningen fra flere sider har vi laget en sjekkliste på 8 punkter for hva du bør ta en nærmere titt på.

Overordnet arkitektur​

Som arkitekt er du ansvarlig for de «arkitekturelle karakteristikkene» som påvirker din løsning som også ofte kalles «ikke-funksjonelle krav». I min erfaring er skalerbarhet, ytelse, fleksibilitet, sikkerhet og spesielt enkapsulering av 3. part systemer de viktigste av disse karakteristikkene. Med det sagt er det viktig å påpeke at arkitekten ikke er ansvarlig for å løse og implementere alle disse selv! Da blir man en flaskehals. Jobben er å belyse og måle effekten av arkitekturmessige valg man tar, og legge til rette for disse kravene på et overordnet nivå.

Skalerbarhet/ ytelse​ går ofte ut på å vite hvor og når det kommer til å være mye last, og legge til rette for skalering på en fleksibel og kosteffektiv måte. Dette fører ofte til at man må splitte opp datalager eller API-er i mer spesialiserte enheter.

Fleksibilitet​ går på hvor lett det er å gjøre endringer eller utvidelser i arkitekturen, api-er eller data.

Sikker arkitektur handler om å bruke kjente mønster for autentisering og autorisasjon på tvers og beskyttelse av infrastrukturen gjennom brannmur, IP whitelist og V-nett. ​

Endringshåndtering i 3. part systemer​ er alltid vanskelig å koordinere siden det går på tvers av bedrifter. Det er derfor viktig å innkapsle disse avhengighetene så tidlig som mulig slik at datatyper og logikk ikke sprer seg inn i resten av systemet man bygger. 

CI/CD​

En av de andre hovedoppgavene som arkitekt er å legge til rette for at teamet kan utføre arbeidet sitt raskt og effektivt over lang tid. Dette betyr ofte at man bør automatisere så mye som mulig og gjøre det lett for alle å gjøre ting rett. Her er spesielt infrastrukturer som kode, passord og konfigstyring, ​utrulling uten nedetid​ og kontroll på miljøene blant det viktigste å se på. ​

Backup/retention​

Når uhellet først er ute så er det viktig å kunne rulle tilbake eller migrere med en tidligere versjon for å sikre seg mot tap av data og lenger nedetid på løsningen. En ting mange glemmer er at det kan være VELDIG lurt å teste dette av og til, også slik at man har erfaring med hvordan å utføre en gjenoppbygging og hvor lang retentionpolicy man trenger for å klare å få dette til i praksis.

Database – arkitektur​

Det er få ting som kan ta ned en løsning så hardt som dårlig database-arkitektur eller feil valg av lagring. Som regel vokser datastørrelse fort og det å bytte fra dokument-database til relasjonell-database, eller motsatt, kan fort være en stor investering. Det å gjøre litt analyse av hva man tror størrelsesbehovet er, hvilke type data man skal lagre og hvilke aksessmønster som skal benyttes kan være essensielt. 

Kodestruktur​

Her er det viktig å ikke dykke for dypt, men heller passe på at man har brukt riktig og standardiserte kodemønster for å dele opp og innkapsle logikk på en god måte.

Logging & monitorering​

Det er mange gode systemer der ute som gir deg generiske logger og monitorering. Dette er en veldig god start, men man har som regel behov for mer spesialisert monitorering og metrikker for å ikke bare sikre at serveren kjører, men at den også gjør jobben sin og det å avdekke tidlig at man sliter med ytelse eller at ingen av kundene faktisk får gjennomført noen handler. Det er også viktig at man har et begrep om data som ikke bør logges slik som passord og person-data.

GDPR​

GDPR er vanskelig, men også viktig! Det å tidlig kartlegge hva man har grunnlag for å lagre av data og hvor lenge, samt rutiner for sletting og innsyn er essensielt. En god start er å se om alle tjenestene kjøres innenfor EU for eksempel. Dersom du er usikker, så har mange bedrifter en ansvarlig nettopp for dette som bør rådføres.

Driftskostnader

Mye av driftskostnader er innlysende, men lisenser på data og sikring mot at automatisk skalering ikke koster uendelig med penger er ting man fort kan overse.