Suveränitet är ett arkitekturbeslut, inte ett val av driftplats

Ett företag bestämmer sig för att det vill ha kontroll över sin data. Projektet får en budget, en leverantör väljs, och arton månader senare körs systemen i ett datacenter inom landet, på avtalsvillkor som den juridiska avdelningen är nöjd med. Styrelsen får beskedet att företaget nu är suveränt.

Sedan ställer någon en praktisk fråga. Om leverantören höjde priserna kraftigt nästa år, hur lång tid skulle det ta att lämna? Ingen kan svara. Datamodellen tillhör leverantörens produkt. Godkännandekedjorna är konfigurerade i leverantörens administrationsskärmar. Krypteringsnycklarna ligger i leverantörens nyckeltjänst, och språkmodellen som skriver utkast till kundsvar anropas via leverantörens konto. Servrarna flyttade. Beroendet gjorde det inte.

Orsaken är att suveränitet behandlades som en fråga om var, när det är en fråga om vem som kan göra vad utan att be om lov. Platsen spelar roll: den avgör vilken lag som gäller och vem som kan tvingas lämna ut data. Men den är en egenskap bland flera, och den är den enda du kan köpa färdig. De andra måste byggas in i designen.

Där ”suverän” i tysthet misslyckas

Nycklar som hålls någon annanstans. Om krypteringsnycklarna finns i en tjänst som leverantören kontrollerar kan leverantören läsa datan, och det kan också alla som kan tvinga leverantören. Data som lagras i ditt land och krypteras med en nyckel du inte håller är placerad, inte kontrollerad.

En modell av verksamheten som du inte kan ta med dig. Varje system erbjuder en export. Få exporterar relationerna, reglerna och historiken i en form som ett annat system kan läsa in. En uppsättning tabeller utan kolumnernas betydelse är en säkerhetskopia, inte ett utträde.

Logik som bor i konfigurationen. Godkännandegränser, prisregler, routning: när de är klick i en proprietär skärm kan de inte läsas, granskas eller flyttas. Sättet företaget arbetar på hålls i ett format som bara en produkt förstår.

En modell, en leverantör. Om allt språkarbete går genom en enda extern modell under ett enda konto beror företagets förmåga att verka nu på den leverantörens priser, tillgänglighet och användarvillkor. Det är en risk i leveranskedjan, och den dyker sällan upp i ett riskregister.

Ett utträde som ingen har övat. En utträdesplan som aldrig har körts är en förhoppning. Första gången någon testar om företaget kan flytta är oftast i det ögonblick det måste.

Vad du ska utforma i stället

Behandla suveränitet som en uppsättning egenskaper hos arkitekturen, där var och en kan kontrolleras av någon som inte behöver ta leverantörens ord för det.

Nycklarna är dina. Krypteringsnycklar genereras och hålls på infrastruktur som företaget kontrollerar, och den som driftar plattformen kan inte använda dem utan att företaget är inblandat.

Modellen av företaget följer med datan. Objekt, relationer och regler beskrivs i en öppen, läsbar form och versionshanteras, så att det verksamheten menar med en order eller en kund kan lämna tillsammans med posterna. Det är uppgiften för en ontologi: betydelsen finns bredvid datan, inte inuti en enskild leverantörs produkt.

Logiken är något du kan läsa. Regler och processer lagras som granskningsbara artefakter med en historik, inte som tillståndet i en konfigurationsskärm. Om en agent ändrade en regel har ändringen en upphovsperson, ett skäl och ett godkännande.

Modellerna är utbytbara. Språkarbetet routas per uppgift, så att känsligt arbete kan gå till en modell på din egen hårdvara och allmänt arbete till en spjutspetsmodell, och vilken som helst av dem kan bytas ut utan att de processer som använder dem skrivs om. Där en liten modell på egen hårdvara räcker ska arkitekturen låta dig använda den.

Stacken är öppen källkod där det spelar roll. Öppen källkod garanterar inte suveränitet, men den tar bort det enda beroende du aldrig kan förhandla bort: tillåtelsen att överhuvudtaget köra programvaran.

Det är den design som Hurukan byggs efter. Dess lager Säkerhet och suveränitet upprätthåller behörigheter på servern, granskar varje ändring som gjord av en människa, en agent eller systemet, körs på infrastruktur som företaget väljer och skriver ner utträdet från början. Det är under uppbyggnad, inte i drift, så det som beskrivs här är designen, inte en meritlista.

Ett test du kan göra den här veckan

Ta en process som spelar roll. Fakturering är en bra kandidat, eftersom den berör kunder, priser, betalningar och lagen. Besvara fem frågor skriftligt:

1. Var finns krypteringsnycklarna för den här datan, och vem kan använda dem?
2. Om du exporterade allt i dag, skulle ett annat system kunna återskapa vad en faktura betyder här: dess tillstånd, dess godkännanderegler, dess kopplingar till ordrar och betalningar?
3. Var finns reglerna för den här processen, och kan en människa läsa dem utan att logga in i leverantörens verktyg?
4. Vilka externa modeller rör den här datan, under vems konto, och vad händer med processen om modellen är otillgänglig i en vecka?
5. När flyttade någon senast den här processen, eller en kopia av den, till en annan infrastruktur?

Varje fråga som tar mer än en dag att besvara markerar ett beroende som ingen har utformat. Svaren visar också vilken data som förtjänar mest omsorg, vilket är ämnet för en separat text om vilken data som inte får lämna huset.

Suveränitet som köps som ett driftavtal håller fram till den första svåra förhandlingen. Suveränitet som är inbyggd i nycklarna, modellen, logiken och utträdet finns kvar när förhandlingen blir svår. Översikten över Hurukan visar hur lagren passar ihop.