Arkitekturreview: Tidsplan ApS (eksempel)

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

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.