# Eksempel: arkitekturreview af en Java-startup | Alli Araghi

URL: https://araghi.eu/da/cases/eksempel-paa-arkitekturreview/

Eksempelrapport

# Arkitekturreview: Tidsplan ApS (eksempel)

**Dette er et eksempel.** Virksomheden, personerne og tallene er opdigtede. Det viser, hvordan et arkitekturreview er bygget op: først forretningen, så hvad der er solidt, hvad der er risikabelt, og hvad der skal ændres først.

Tidsplan laver software til planlægning af opgaver for VVS'ere og elektrikere i Danmark: en webapp til kontoret og en mobilapp til folkene ude på pladsen. Seks udviklere, omkring 120 kundevirksomheder og en Java-backend (Spring Boot) på PostgreSQL i én cloudregion i EU.

## 1. Forretningens næste behov

Aftalt med stifterne og produktchefen, før jeg så på koden. Alt nedenfor er målt op imod det.

1. **Fem gange så mange kunder på 18 måneder,** og omkring ti gange så mange opgaver planlagt om dagen, mest fra Sverige.
2. **Svenske kunder:** svensk sprog og svensk moms, og kundedata, der bliver i EU.
3. **Integration med regnskabsprogrammer:** opgaverne overføres automatisk til kundernes regnskabsprogram, uden at nogen skal indtaste dem to gange.
4. **Arbejde på pladsen uden dækning:** kældre og nybyggerier har ofte ingen, og ændringer lavet offline må ikke gå tabt.
5. **Udgivelser flere gange om ugen, uden nedetid.** I dag sker det fredag aften, og appen er nede i omkring 15 minutter.
6. **En teknisk due diligence** til næste investeringsrunde, om cirka et år.
7. **AI-kodeagenter** til teamet, på en sikker måde.

## 2. Det er solidt

- **Én kodebase med klare moduler.** Planlægning, fakturering og kunder ligger i hver sin pakke med få kald imellem. Det er et godt sted at vokse fra; det behøver ikke blive til mange services.
- **PostgreSQL** er den rigtige database til forretningen og kan bære den planlagte vækst.
- **Faktureringen er godt testet,** og teamet stoler på sine tests der.
- **Teamet kender systemet.** To af de første udviklere er her stadig.

## 3. Det er risikabelt

Ordnet efter, hvor meget det truer planen i afsnit 1.

- A **Mobilsynkroniseringen overskriver hele opgaver: den enhed, der synkroniserer sidst, vinder** Ændringer lavet offline går tabt i dag, og det bliver værre med flere folk på pladsen. Krav: 1, 4
- B **Integrationerne til regnskabsprogrammer kører inde i webforespørgslerne** Et langsomt regnskabsprogram gør appen langsom for alle, og hvis et kald fejler, går opdateringen tabt. Krav: 1, 3
- C **Planlægningskalenderen læser én stor opgavetabel uden de rigtige indeks** I dag tager kalenderen omkring 2 sekunder, når der er travlt; med ti gange så mange opgaver kan den ikke bruges. Krav: 1
- D **Udgivelser kræver nedetid** Fint med 120 kunder, men ikke med 600 i to lande. Krav: 1, 5
- E **Adgangskoder og nøgler ligger i konfigurationsfiler i repositoriet** En risiko nu og en stopklods, før AI-kodeagenter får adgang, og før en due diligence. Krav: 6, 7
- F **Sletning af en kundes data kræver manuel SQL** Der kommer flere GDPR-anmodninger, når antallet af kunder vokser, og investorernes tekniske rådgivere vil spørge ind til håndteringen. Krav: 2, 6

## 4. Det skal ændres først

Med fordele og ulemper og et groft estimat for hvert punkt. Estimaterne gælder for dette team på seks.

1. **Adgangskoder og nøgler ud af repositoriet og regler for AI-kodeagenter** (risiko E) Et centralt lager til adgangskoder og nøgler, rotation af eksisterende nøgler, en regelfil til agenterne og review af deres ændringer. **Indsats:** 2 til 3 dage **Afvejning:** ingen, der er værd at nævne; gør det først.
2. **Indeks og forespørgsler pr. virksomhed til kalenderen** (risiko C) **Indsats:** 2 dage **Afvejning:** lidt mere omhu med hver ny forespørgsel; et tjek af forespørgslerne i testsuiten holder styr på det.
3. **Integrationer via en jobkø** (risiko B) En outbox-tabel i PostgreSQL og en worker, der prøver igen. **Indsats:** 1 til 2 uger **Afvejning:** opdateringer når frem til regnskabsprogrammet med nogle sekunders forsinkelse i stedet for med det samme; ingen her har brug for øjeblikkelig opdatering.
4. **Udgivelser uden nedetid** (risiko D) To instanser af appen bag load balanceren og databaseændringer, der virker med både den gamle og den nye version. **Indsats:** omkring 1 uge **Afvejning:** databaseændringer tager to udgivelser i stedet for én.
5. **Synkronisering pr. ændring, ikke pr. hel opgave** (risiko A) Telefonen sender det, der er ændret, felt for felt, og serveren gemmer ændringerne, så to personer, der retter i den samme opgave, ikke længere sletter hinandens arbejde. **Indsats:** 3 til 4 uger **Afvejning:** den største ændring her, så den starter efter punkt 1 til 4 og rulles først ud til nogle få kunder.
6. **Sletning af en kundes data som en funktion i appen** (risiko F) **Indsats:** omkring 1 uge

**Det skal ikke gøres nu:** dele systemet op i services eller skifte PostgreSQL ud. Ingen af delene løser en af risiciene ovenfor, og begge dele ville tage teamets næste seks måneder.

## 5. Beslutningslog

### Behold én kodebase, og styrk modulerne i den.

**Hvorfor:** modulerne er allerede klare, og teamet er seks personer.

**Alternativer:** separate services til planlægning og fakturering.

**Tages op igen, når:** et modul skal skalere eller udgives for sig selv, eller teamet kommer over omkring 15 udviklere.

### En jobkø i PostgreSQL, ikke en message broker.

**Hvorfor:** én database at drive, tage backup af og forstå.

**Alternativer:** Kafka eller en kø i skyen.

**Tages op igen, når:** køen bruges til mere end integrationer, eller mængden af jobs bliver for stor til én database.

### Synkronisering via registrerede ændringer.

**Hvorfor:** det er den eneste løsning, der forhindrer, at folk uden dækning mister deres arbejde.

**Alternativer:** lås en opgave, mens én person retter i den, hvilket fejler netop når der ikke er dækning.

**Tages op igen, når:** den nye synkronisering har kørt i tre måneder hos nogle få kunder.

## 6. Gennemgang

En time med stifterne og udviklerne til at gennemgå resultaterne, besvare spørgsmål og aftale rækkefølgen af arbejdet. Teamet planlagde derefter at gennemføre punkt 1 til 4 i løbet af de næste seks uger.

Vil du have et review som dette af dit eget system?

Book en samtale på 30 minutter

Sådan foregår et review