Hvordan vurderer du et SaaS-produkts arkitekturmæssige egnethed?

Question

IT Interview Practice · Accepted Answer

Vurdér et **SaaS-produkts arkitekturmæssige egnethed** ved at teste, om dets faktiske integrations- og driftsadfærd opfylder løsningens begrænsninger. Det er en fit-gap-vurdering af et konkret produkt, ikke blot en generel beslutning om at bygge eller købe software.

## Start med et integrationskort

```text
[Identity provider] --> [Candidate SaaS] <--> [Integration adapter]
                              |                      |
                        [Data export]          [Internal systems]
```

Registrér for hver forbindelse den nødvendige adfærd, leverandørens dokumenterede funktionalitet, beviser fra en afprøvning og resterende mangler. Adskil ufravigelige hindringer fra præferencer før pointgivning; flere gode funktioner kan ikke kompensere for en manglende obligatorisk egenskab.

## Områder, der skal verificeres

- **Identitet:** loginintegration, kontooprettelse, rolletilknytning og rettidig fjernelse af adgang.
- **Data:** ejerskab, understøttede placeringer, eksportens fuldstændighed, identifikatorer og sletning på tværs af kopier.
- **Grænseflader:** API-dækning, kvoter, paginering, genafspilning af webhooks, versionspolitik og sandboxbegrænsninger.
- **Drift:** supporteskalation, servicetilsagn, indsigt i auditdata og ansvar for genetablering.
- **Exit:** praktisk mulighed for at hente data og tilslutte forbrugere igen, hvis produktet udskiftes.

## Eksempel

En CRM-demo kan vise kundeposter og samtidig skjule en kritisk mangel: eksportendepunktet udelader måske vedhæftninger, eller webhooken understøtter ikke historisk genafspilning. Test en repræsentativ post med vedhæftninger, og simulér en mistet hændelse. Estimér indhentningstiden med den faktiske API-kvote og forventede daglige mængde.

## Beslutning og faldgruber

Klassificér hver mangel som konfiguration, adapterarbejde, accepteret begrænsning eller hindring. Udpeg en ejer, og medtag løbende supportomkostninger for enhver adapter. Kontrollér funktionerne igen mod det foreslåede abonnement og kontrakten, da et testmiljø kan give adgang til andre funktioner.

Vis ved jobsamtalen, hvordan beviser ændrer anbefalingen. En leverandørtjekliste med “ja” i alle felter er svag, hvis ingen har testet det forretningskritiske forløb.

Start med et integrationskort

Områder, der skal verificeres

Eksempel

Beslutning og faldgruber

Relaterede spørgsmål