Suverænitet er en arkitekturbeslutning, ikke et valg af hosting

En virksomhed beslutter, at den vil have kontrol over sine data. Projektet får et budget, en leverandør vælges, og atten måneder senere kører systemerne i et datacenter i landet på kontraktvilkår, som den juridiske afdeling er tilfreds med. Bestyrelsen får at vide, at virksomheden nu er suveræn.

Så stiller nogen et praktisk spørgsmål. Hvis leverandøren hævede priserne kraftigt næste år, hvor lang tid ville det så tage at komme ud? Ingen kan svare. Datamodellen tilhører leverandørens produkt. Godkendelseskæderne er konfigureret i leverandørens administrationsskærme. Krypteringsnøglerne ligger i leverandørens nøgletjeneste, og den sprogmodel, der skriver udkast til kundesvar, kaldes via leverandørens konto. Serverne flyttede. Afhængigheden gjorde ikke.

Årsagen er, at suverænitet blev behandlet som et spørgsmål om hvor, når det er et spørgsmål om hvem der kan gøre hvad uden at spørge. Placering betyder noget: Den afgør, hvilken lovgivning der gælder, og hvem der kan tvinges til at udlevere data. Men det er én egenskab blandt flere, og det er den eneste, du kan købe færdig. De andre skal designes ind.

Hvor »suveræn« stille og roligt svigter

Nøgler, der ligger andre steder. Hvis krypteringsnøglerne ligger i en tjeneste, som udbyderen kontrollerer, kan udbyderen læse data — og det kan enhver, der kan tvinge udbyderen. Data, der er gemt i dit land og krypteret med en nøgle, du ikke har, er placeret, ikke kontrolleret.

En model af forretningen, du ikke kan tage med. Alle systemer tilbyder en eksport. Få eksporterer relationerne, reglerne og historikken i en form, et andet system kan indlæse. Et sæt tabeller uden betydningen af deres kolonner er en backup, ikke en exit.

Logik, der bor i konfiguration. Godkendelsesgrænser, prisregler, routing: Når de er klik i et proprietært skærmbillede, kan de ikke læses, gennemgås eller flyttes. Den måde, virksomheden arbejder på, ligger i et format, som kun ét produkt forstår.

Én model, én udbyder. Hvis alt sprogarbejde går gennem én ekstern model under én konto, afhænger virksomhedens evne til at fungere nu af den udbyders priser, tilgængelighed og brugsvilkår. Det er en forsyningskæderisiko, og den optræder sjældent i et risikoregister.

En exit, ingen har øvet. En exitplan, der aldrig er blevet kørt, er et håb. Første gang nogen tester, om virksomheden kan flytte, er som regel det øjeblik, den er nødt til det.

Hvad du skal designe i stedet

Behandl suverænitet som et sæt egenskaber ved arkitekturen, hvor hver enkelt kan kontrolleres af en person, der ikke behøver at tage leverandørens ord for gode varer.

Nøglerne er dine. Krypteringsnøgler genereres og opbevares på infrastruktur, virksomheden kontrollerer, og den, der driver platformen, kan ikke bruge dem uden virksomhedens medvirken.

Modellen af virksomheden følger med data. Objekter, relationer og regler beskrives i en åben, læsbar form og versioneres, så det, forretningen forstår ved en ordre eller en kunde, kan følge med posterne ud. Det er opgaven for en ontologi: Betydningen bor ved siden af data, ikke inde i én leverandørs produkt.

Logik er noget, du kan læse. Regler og processer gemmes som artefakter, der kan gennemgås og har en historik, ikke som tilstanden i et konfigurationsskærmbillede. Hvis en agent ændrede en regel, har ændringen en ophavsperson, en begrundelse og en godkendelse.

Modeller kan udskiftes. Sprogarbejde routes pr. opgave, så følsomt arbejde kan gå til en model på din egen hardware og generelt arbejde til en frontiermodel, og begge kan udskiftes uden at omskrive de processer, der bruger dem. Hvor en lille model på egen hardware er god nok, bør arkitekturen lade dig bruge den.

Stakken er open source, hvor det betyder noget. Open source garanterer ikke suverænitet, men det fjerner den ene afhængighed, du aldrig kan forhandle dig ud af: tilladelsen til overhovedet at køre softwaren.

Det er det design, Hurukan bygges efter. Laget Sikkerhed og suverænitet håndhæver rettigheder på serveren, reviderer hver ændring som foretaget af et menneske, en agent eller systemet, kører på infrastruktur, virksomheden selv vælger, og skriver exitten ned fra starten. Det er under opbygning og ikke udrullet, så det, der beskrives her, er designet — ikke en dokumenteret historik.

En test, du kan køre i denne uge

Tag én proces, der betyder noget. Fakturering er en god kandidat, fordi den berører kunder, priser, betalinger og lovgivningen. Besvar fem spørgsmål skriftligt:

1. Hvor er krypteringsnøglerne til disse data, og hvem kan bruge dem?
2. Hvis du eksporterede alt i dag, kunne et andet system så genskabe, hvad en faktura betyder her: dens tilstande, dens godkendelsesregler, dens forbindelser til ordrer og betalinger?
3. Hvor bor reglerne for denne proces, og kan et menneske læse dem uden at logge ind i leverandørens værktøj?
4. Hvilke eksterne modeller rører disse data, under hvis konto, og hvad sker der med processen, hvis den model er utilgængelig i en uge?
5. Hvornår har nogen sidst flyttet denne proces, eller en kopi af den, til anden infrastruktur?

Hvert spørgsmål, der tager mere end en dag at besvare, markerer en afhængighed, som ingen har designet. Svarene viser også, hvilke data der fortjener mest omhu — emnet for et særskilt indlæg om hvilke data der skal blive i huset.

Suverænitet købt som en hostingkontrakt holder indtil den første hårde forhandling. Suverænitet designet ind i nøglerne, modellen, logikken og exitten er der stadig, når forhandlingen bliver svær. Hurukans oversigt viser, hvordan lagene hænger sammen.