Til grupper og flere brands
Flere virksomheder, én installation, ingen delte kunder
Grupper løser det plejer to gange dårligt: enten fem separate installationer og fem separate alting, eller én installation og et højtideligt løfte om, at applikationen altid filtrerer korrekt. Det første er dyrt. Det andet er et løfte, og løfter er ikke en sikkerhedsmodel.
Hvis du driver mere end én virksomhed — et holdingselskab med datterselskaber, en franchise, to brands rettet mod forskellige markeder, et bureau og det, bureauet spandt ud — kender du allerede problemets form. Brands deler folk, værktøj og en økonomiafdeling. De deler ikke kunder, og de må ikke se ud til at gøre det.
iKonekt kører dem alle fra én installation, og adskillelsen mellem dem håndhæves af databasen frem for af koden. Den skelnen lyder akademisk, indtil den dag, den ikke gør.
Hvorfor laget betyder noget
Et filter på applikationsniveau er en sætning i en forespørgsel. Det virker, så længe enhver forespørgsel, der nogensinde skrives, indeholder den — inklusive den, der skrives i en fart, den, der skrives af den nye udvikler, og den, der skrives til en rapport, der kun skulle bruges én gang.
Skub grænsen ned i databasen, og regnestykket vender. Politikken kører ved hver læsning og hver skrivning, under alt. En forespørgsel, der glemmer virksomheden, returnerer ikke de forkerte rækker; den returnerer ingen. Fejltilstanden bliver en tom skærm og en forvirret udvikler — hvilket er den korrekte fejltilstand.
Tomme skærme er en feature. Vi foretrækker at forklare en tom skærm for en af vores egne ingeniører frem for at forklare en kundeliste for to kunder, der ikke havde regnet med at mødes.
- 1Kunder & trådeAfgrænset. En sælger i brand A kan ikke nå brand B's – af konstruktion, ikke af konfiguration.
- 2Krav på en kunde"Vi har allerede denne konto" er en lås holdt pr. virksomhed – så to brands kan begge arbejde det samme marked uden at kollidere.
- 3Prompts & indstillingerHver virksomhed redigerer sine egne. Det eneste sted, dette nogensinde var delt, var en fejl – og det er fejlen, som systemet er stoldest af at have fundet.
- 4PartnerprogrammerEt modul pr. virksomhed, ikke et globalt, som alle arver.
Grænse håndhævet under applikationen
Hvad en gruppe reelt får lov at dele
Adskillelse er ikke isolation for isolationens skyld. Det, der er værd at dele på tværs af en gruppe, deles bevidst, og det er mest de kedelige ting – hvilket er præcis rigtigt, for de kedelige ting er, hvor den duplikerede omkostning bor:
- Én installation at køre og opdatere. Én deployment, ét sæt legitimationsoplysninger at passe på, én ting at holde opdateret.
- Ét team af mennesker med forskellige hatte på. En person kan arbejde i mere end én virksomhed; hvad de ikke kan, er at se begge på én gang gennem en forespørgsel, der glemte at spørge.
- Ét sæt vaner. Måden en lead tildeles på, måden en note skrives på, måden et job bliver til en faktura – lært én gang, anvendt overalt, hvilket forkorter onboarding til cirka en formiddag.
- Ét forhold til resten af familien. castomAPI nedenunder, samme konto, samme connectors – konfigureret pr. virksomhed, hvor det betyder noget.
Spørgsmålet, en gruppe altid stiller som det andet
"Kan vi rapportere på tværs af dem alle?" Ja – fra gruppens eget udsigtspunkt, bevidst og eksplicit, snarere end som en bivirkning af en utæt grænse. Skelnen er hele designet: At krydse linjen skal være en handling, nogen har udført med vilje og med myndighed til det. Det må aldrig være noget, en løs identifikator kan udrette ved et uheld.
Og spørgsmålet, de stiller som det tredje: "hvad sker der, hvis vi sælger et af brandene?" En grænse, som databasen holder, er også en grænse, du kan løfte en ren kopi ud af. Det er ikke en tilfældighed – adskillelse og portabilitet er samme egenskab set fra to forskellige møder.
Under gulvet
Hvad der holder linjen, konkret
Ikke et påstand, en liste. Hvis en leverandør ikke kan fremvise denne liste om deres eget produkt, er det værd at bemærke.
26
Tabeller, der bærer deres virksomhed, med tjekket tvunget til at være slået til, ikke blot tilgængeligt.
72
Politikker, skrevet ud én ad gangen, så hver enkelt er blevet læst af et menneske, ikke genereret i en løkke.
942
Tests, kørt mod en database, der bygges op fra nul hver gang, noget ændres.
0
Standardvirksomheder. En forespørgsel uden scope kaster en fejl, før den når dataene – der er intet fallback at glemme at deaktivere.
"Fem virksomheder, fem installationer, fem fakturaer fra jer."
Én installation. Fem grænser, databasen holder.
Fælles mennesker, fælles vaner, fælles platform – og ikke én fælles kunde. At krydse den linje skal være noget, et menneske gjorde med vilje, aldrig noget, en identifikator klarede ved et uheld.
Sådan bygges adskillelsen →