For grupper og flere merkevarer
Flere selskaper, én installasjon, ingen delte kunder
Grupper løser vanligvis dette dobbelt dårlig: enten fem separate installasjoner og fem separate alt-mulig, eller én installasjon og et høytidelig løfte om at applikasjonen alltid filtrerer riktig. Det første er dyrt. Det andre er et løfte, og løfter er ikke en sikkerhetsmodell.
Hvis du driver mer enn ett selskap — et holdingselskap med datterselskaper, en franchise, to merkevarer rettet mot ulike markeder, et byrå og det byrået ble spunnet ut av — kjenner du allerede formen på problemet. Merkevarene deler folk, verktøy og en økonomiavdeling. De deler ikke kunder, og de må ikke fremstå som om de gjør det.
iKonekt kjører alle fra én installasjon, og skillet mellom dem holdes av databasen og ikke av koden. Den distinksjonen høres akademisk ut til den dagen den ikke gjør det.
Hvorfor laget betyr noe
Et filter på applikasjonsnivå er en setning i en spørring. Det fungerer så lenge hver spørring som noensinne skrives inneholder den — inkludert den som skrives i hastverk, den som skrives av den nye utvikleren, og den som skrives for en rapport som bare skulle brukes én gang.
Flytt grensen ned i databasen, og regnestykket snur. Policyen kjører på hver lesing og hver skriving, under alt. En spørring som glemmer selskapet returnerer ikke feil rader; den returnerer ingen. Feilmodusen blir en tom skjerm og en forvirret utvikler, som er den riktige feilmodusen.
Tomme skjermer er en funksjon. Vi heller med å forklare en tom skjerm for en av våre egne ingeniører enn å forklare en kundeliste for to kunder som ikke ventet å møtes.
- 1Kunder & tråderAvgrenset. En selger i merkevare A kan ikke nå merkevare B sine, ved konstruksjon og ikke ved konfigurasjon.
- 2Krav på en kunde«Vi har allerede denne kunden» er en lås holdt per selskap — så to merkevarer kan begge jobbe samme marked uten å kollidere.
- 3Prompter & innstillingerHvert selskap redigerer sine egne. Det eneste stedet dette noen gang var delt var en feil, og det er feilen dette systemet er mest stolt av å ha funnet.
- 4PartnerprogrammerÉn modul per selskap, ikke en global som alle arver.
Grense håndhevet under applikasjonen
Hva en gruppe faktisk får dele
Separasjon er ikke isolasjon for sin egen skyld. Tingene som er verdt å dele på tvers av en gruppe deles bevisst, og det er stort sett de kjedelige — som er akkurat riktig, for de kjedelige er der den dupliserte kostnaden bor:
- Én installasjon å drifte og oppdatere. Én utrulling, ett sett med legitimasjoner å passe på, én ting å holde oppdatert.
- Ént team av folk, med ulike hatter. En person kan jobbe i mer enn ett selskap; det de ikke kan, er å se begge samtidig gjennom en spørring som glemte å spørre.
- Étt sett med vaner. Måten en lead tildeles, måten et notat skrives, måten et jobb når en faktura — lært én gang, brukt overalt, noe som forkorter opplæringen til omtrent en formiddag.
- Étt forhold til resten av familien. castomAPI under, samme konto, samme koblinger — konfigurert per selskap der det betyr noe.
Spørsmålet en gruppe alltid stiller som nummer to
«Kan vi rapportere på tvers av alle?» Ja — fra gruppens eget ståsted, bevisst og eksplisitt, og ikke som en bivirkning av en lekk grense. Distinksjonen er hele designet: å krysse linjen må være en handling noen utførte med vilje, med myndighet til å gjøre det. Det må aldri være noe en løs identifikator kan utrette ved et uhell.
Og spørsmålet de stiller som nummer tre: «hva skjer hvis vi selger en av merkevarene?» En grense som databasen holder, er også en grense du kan løfte en ren kopi ut av. Det er ikke et sammentreff — separasjon og portabilitet er samme egenskap sett fra to ulike møter.
Under gulvet
Hva som holder linjen, konkret
Ikke et påstand, en liste. Hvis en leverandør ikke kan fremlegge denne listen om sitt eget produkt, er det verdt å legge merke til.
26
Tabeller som bærer sitt selskap, med sjekken tvunget på og ikke bare tilgjengelig.
72
Policies, skrevet ut én om gangen slik at hver er lest av et menneske, ikke generert i en løkke.
942
Tester, kjørt mot en database gjenoppbygd fra null hver gang noe endres.
0
Standardselskaper. En forespørsel uten omfang kaster feil før den når dataene — det finnes ingen fallback å glemme å deaktivere.
«Fem selskaper, fem installasjoner, fem fakturaer fra dere.»
Én installasjon. Fem grenser databasen holder.
Felles folk, felles vaner, felles plattform – og ikke én felles kunde. Å krysse den linjen må være noe en person gjorde med vilje, aldri noe en identifikator klarte ved et uhell.
Hvordan separasjonen er bygget →