Voor groepen en meerdere merken
Meerdere bedrijven, één installatie, geen gedeelde klanten
Groepen lossen dit meestal twee keer slecht op: ofwel vijf aparte installaties en vijf keer alles apart, ofwel één installatie en een plechtige belofte dat de applicatie altijd correct filtert. Het eerste is duur. Het tweede is een belofte, en beloftes zijn geen beveiligingsmodel.
Als je meer dan één bedrijf runt — een holding met dochterondernemingen, een franchise, twee merken gericht op verschillende markten, een bureau en het ding dat het bureau uitspon — dan ken je de vorm van het probleem al. De merken delen mensen, tooling en een financiële afdeling. Ze delen geen klanten, en het mag ook niet lijken alsof ze die delen.
iKonekt draait ze allemaal vanaf één installatie, en de scheiding ertussen wordt door de database bewaakt in plaats van door de code. Dat onderscheid klinkt academisch totdat de dag komt dat het dat niet is.
Waarom de laag ertoe doet
Een filter op applicatieniveau is een zin in een query. Het werkt zolang elke query die ooit geschreven zal worden het bevat — inclusief degene die in haast is geschreven, degene die door de nieuwe ontwikkelaar is geschreven, en degene die voor een rapport is geschreven dat toch maar één keer gebruikt zou worden.
Duw de grens de database in en de rekening keert zich om. Het beleid draait bij elke lees- en elke schrijfactie, onder alles. Een query die het bedrijf vergeet, geeft niet de verkeerde rijen terug; hij geeft er geen. De faalmodus wordt een leeg scherm en een verwarde ontwikkelaar, en dat is de juiste faalmodus.
Lege schermen zijn een feature. We liever een leeg scherm uitleggen aan een van onze eigen ingenieurs dan een klantenlijst uitleggen aan twee klanten die elkaar niet verwachtten te ontmoeten.
- 1Klanten & threadsAfgeschermd. Een verkoper bij merk A kan die van merk B niet bereiken, door constructie in plaats van door configuratie.
- 2Claims op een klant"We hebben dit account al" is een slot dat per bedrijf wordt vastgehouden — zodat twee merken aan dezelfde markt kunnen werken zonder met elkaar te botsen.
- 3Prompts & instellingenElk bedrijf bewerkt zijn eigen. De ene plek waar dit ooit gedeeld werd, was een bug, en het is de bug waar dit systeem het meest trots op is gevonden te hebben.
- 4Partnerprogramma'sEen module per bedrijf, geen globale die iedereen erft.
Grens afgedwongen onder de applicatie
Wat een groep daadwerkelijk met elkaar mag delen
Scheiding is geen isolatie om het isoleren. De dingen die het delen waard zijn binnen een groep worden bewust gedeeld, en het zijn vooral de saaie — en dat is precies goed, want in de saaie zit de dubbele kosten:
- Eén installatie om te draaien en bij te werken. Eén deployment, één set inloggegevens om te beheren, één ding om te patchen.
- Eén team mensen, met verschillende petten op. Iemand kan bij meer dan één bedrijf werken; wat niet kan, is beide tegelijk zien via een query die vergat te vragen.
- Eén set gewoontes. Hoe een lead wordt toegewezen, hoe een notitie wordt geschreven, hoe een klus tot een factuur komt — één keer geleerd, overal toegepast, waardoor het inwerken nog ongeveer een ochtend kost.
- Eén relatie met de rest van de familie. castomAPI eronder, hetzelfde account, dezelfde connectors — per bedrijf geconfigureerd waar dat telt.
De vraag die een groep altijd als tweede stelt
"Kunnen we over ze allemaal rapporteren?" Ja — vanuit het eigen standpunt van de groep, bewust en expliciet, in plaats van als bijeffect van een lekkende grens. Dat onderscheid is het hele ontwerp: de lijn oversteken moet een handeling zijn die iemand met opzet en met de bevoegdheid daartoe heeft uitgevoerd. Het mag nooit iets zijn dat een verdwaalde identifier per ongeluk voor elkaar krijgt.
En de vraag die ze als derde stellen: "wat gebeurt er als we een van de merken verkopen?" Een grens die de database bewaakt, is ook een grens waar je een schone kopie uit kunt tillen. Dat is geen toeval — scheiding en portabiliteit zijn dezelfde eigenschap, bekeken vanuit twee verschillende vergaderingen.
Onder de vloer
Wat de lijn precies bewaakt
Geen claim, maar een lijst. Als een leverancier deze lijst over het eigen product niet kan produceren, is dat het vermelden waard.
26
Tabellen die hun bedrijf meedragen, met de check afgedwongen in plaats van slechts beschikbaar.
72
Beleidsregels, een voor een uitgeschreven zodat elk erdoor iemand is gelezen, niet in een lus gegenereerd.
942
Tests, gedraaid tegen een database die bij elke wijziging opnieuw vanaf nul wordt opgebouwd.
0
Standaardbedrijven. Een verzoek zonder scope gooit een fout voordat het de data bereikt — er is geen fallback die je kunt vergeten uit te schakelen.
“Vijf bedrijven, vijf installaties, vijf facturen van jou.”
Eén installatie. Vijf grenzen die de database bewaakt.
Gedeelde mensen, gedeelde gewoontes, gedeeld platform — en niet één gedeelde klant. Die lijn oversteken moet iets zijn dat iemand met opzet heeft gedaan, nooit iets dat een identifier per ongeluk voor elkaar kreeg.
Hoe de scheiding is gebouwd →