För grupper och flera varumärken
Flera bolag, en installation, inga delade kunder
Grupper löser vanligtvis detta två gånger, båda dåligt: antingen fem separata installationer och fem separata allting, eller en installation och ett högtidligt löfte om att applikationen alltid filtrerar rätt. Det första är dyrt. Det andra är ett löfte, och löften är ingen säkerhetsmodell.
Om du driver mer än ett bolag — en holding med dotterbolag, en franchise, två varumärken riktade mot olika marknader, en byrå och det som byrån snurrade ut — känner du redan till problemets form. Varumärkena delar människor, verktyg och en ekonomiavdelning. De delar inte kunder, och de får inte heller framstå som att de gör det.
iKonekt kör alla från en installation, och separationen mellan dem hålls av databasen snarare än av koden. Den distinktionen låter akademisk tills den dagen den inte gör det.
Därför spelar lagret roll
Ett filter på applikationsnivå är en mening i en fråga. Det fungerar så länge varje fråga som någonsin kommer att skrivas innehåller den — inklusive den som skrevs i hast, den som skrevs av den nya utvecklaren, och den som skrevs för en rapport som bara skulle användas en gång.
Flytta gränsen ner i databasen och aritmetiken vänder. Policyn körs vid varje läsning och varje skrivning, under allt. En fråga som glömmer bolaget returnerar inte fel rader; den returnerar inga. Felfunktionen blir en tom skärm och en förvirrad utvecklare, vilket är den korrekta felfunktionen.
Tomma skärmar är en funktion. Vi föredrar att förklara en tom skärm för en av våra egna ingenjörer framför att förklara en kundlista för två kunder som inte räknade med att träffas.
- 1Kunder & trådarAvgränsat. En säljare i varumärke A kan inte nå varumärke B:s, till följd av konstruktionen snarare än konfigurationen.
- 2Anspråk på en kund"Vi har redan det här kontot" är ett lås som hålls per bolag — så två varumärken kan båda arbeta samma marknad utan att kollidera.
- 3Uppmaningar & inställningarVarje bolag redigerar sina egna. Det enda ställe där detta någonsin delades var en bugg, och det är buggen som det här systemet är stoltast över att ha hittat.
- 4PartnerprogramEn modul per bolag, inte en global som alla ärver.
Gränsen tillämpas under applikationen
Vad en grupp faktiskt får dela
Separation är inte isolering för sin egen skull. Det som är värt att dela över en grupp delas medvetet, och det är mest de tråkiga sakerna — vilket är precis rätt, för de tråkiga sakerna är där den duplicerade kostnaden bor:
- En installation att driva och uppdatera. En driftsättning, en uppsättning inloggningsuppgifter att vårda, en sak att hålla uppdaterad.
- Ett team av människor, med olika roller på. En person kan arbeta i mer än ett företag; det man inte kan göra är att se båda samtidigt genom en fråga som glömde att fråga.
- En uppsättning vanor. Hur ett lead tilldelas, hur en anteckning skrivs, hur ett jobb blir en faktura — lärs en gång, gäller överallt, vilket kortar introduktionen till ungefär en förmiddag.
- En relation med resten av familjen. castomAPI under huven, samma konto, samma kopplingar — konfigurerade per företag där det spelar roll.
Frågan en grupp alltid ställer sig som andra
"Kan vi rapportera över alla?" Ja — från gruppens egen utikspunkt, medvetet och uttryckligen, snarare än som en bieffekt av en läckande gräns. Skillnaden är hela designen: att korsa linjen måste vara en handling någon utförde med flit, med befogenhet att göra det. Det får aldrig vara något som en vilseledd identifierare klarar av en slump.
Och frågan de ställer sig som tredje: "vad händer om vi säljer ett av varumärkena?" En gräns som databasen upprätthåller är också en gräns som du kan lyfta ut en ren kopia ur. Det är ingen slump — separation och portabilitet är samma egenskap sedd från två olika möten.
Under golvet
Vad som specifikt håller linjen
Inte ett påstående, en lista. Om en leverantör inte kan visa upp den här listan om sin egen produkt är det värt att notera.
26
Tabeller som bär sitt företag, med tvångskontrollen påslagen snarare än bara tillgänglig.
72
Policyer, skrivna en och en så att var och en har lästs av en människa, inte genererats i en loop.
942
Tester, körda mot en databas som byggs om från noll varje gång något ändras.
0
Standardföretag. En begäran utan scope kastar fel innan den når datan — det finns ingen återgång att glömma att inaktivera.
"Fem företag, fem installationer, fem fakturor från er."
En installation. Fem gränser som databasen upprätthåller.
Gemensamma personer, gemensamma vanor, gemensam plattform — och inte en enda gemensam kund. Att korsa den linjen måste vara något en person gjorde med flit, aldrig något en identifierare lyckades med av en slump.
Hur separationen är byggd →