Pour les groupes et plusieurs marques
Plusieurs sociétés, une seule installation, aucun client partagé
Les groupes résolvent généralement ce problème deux fois mal : soit cinq installations séparées et cinq fois tout le reste, soit une seule installation et la promesse solennelle que l'application filtrera toujours correctement. La première option coûte cher. La seconde est une promesse, et les promesses ne sont pas un modèle de sécurité.
Si vous gérez plus d'une société — une holding avec des filiales, une franchise, deux marques visant des marchés différents, une agence et l'entité qu'elle a créée — vous connaissez déjà la forme du problème. Les marques partagent les personnes, les outils et un service financier. Elles ne partagent pas les clients, et elles ne doivent surtout pas le paraître.
iKonekt fait fonctionner toutes ces sociétés depuis une seule installation, et la séparation entre elles est assurée par la base de données plutôt que par le code. Cette distinction semble académique jusqu'au jour où elle ne l'est plus.
Pourquoi cette couche est importante
Un filtre au niveau applicatif est une phrase dans une requête. Il fonctionne tant que chaque requête qui sera jamais écrite le contient — y compris celle écrite à la hâte, celle écrite par le nouveau développeur, et celle écrite pour un rapport qui ne devait servir qu'une fois.
Repoussez la frontière dans la base de données et l'arithmétique s'inverse. La politique s'applique à chaque lecture et à chaque écriture, sous tout le reste. Une requête qui oublie la société ne renvoie pas les mauvaises lignes ; elle n'en renvoie aucune. Le mode de défaillance devient un écran vide et un développeur perplexe, ce qui est le bon mode de défaillance.
Les écrans vides sont une fonctionnalité. Nous préférons expliquer un écran vide à l'un de nos propres ingénieurs qu'expliquer une liste de clients à deux clients qui ne s'attendaient pas à se rencontrer.
- 1Clients & fils de discussionCloisonnés. Un vendeur de la marque A ne peut pas accéder à ceux de la marque B, par construction plutôt que par configuration.
- 2Revendications sur un client« Nous avons déjà ce compte » est un verrou détenu par société — deux marques peuvent donc travailler le même marché sans entrer en collision.
- 3Invites & paramètresChaque société modifie les siens. Le seul endroit où cela a jamais été partagé était un bug, et c'est le bug dont ce système est le plus fier d'avoir trouvé.
- 4Programmes partenairesUn module par société, et non un module global que tout le monde hérite.
Frontière appliquée sous l'application
Ce qu'un groupe peut réellement partager
La séparation n'est pas l'isolement pour le plaisir. Ce qui mérite d'être partagé au sein d'un groupe l'est délibérément, et ce sont surtout les choses ennuyeuses — ce qui est exactement juste, car c'est dans les choses ennuyeuses que se loge le coût de la duplication :
- Une seule installation à exploiter et à mettre à jour. Un déploiement, un seul jeu d'identifiants à gérer, une seule chose à maintenir à jour.
- Une seule équipe, avec des casquettes différentes. Une personne peut travailler dans plusieurs sociétés ; ce qu'elle ne peut pas faire, c'est voir les deux à la fois via une requête qui a oublié de le demander.
- Un seul ensemble d'habitudes. La façon dont un prospect est attribué, dont une note est rédigée, dont une tâche devient une facture — appris une fois, appliqué partout, ce qui réduit l'intégration à environ une matinée.
- Une seule relation avec le reste de la famille. castomAPI en dessous, le même compte, les mêmes connecteurs — configurés par société là où cela compte.
La question qu'un groupe pose toujours en second
« Pouvons-nous établir des rapports sur l'ensemble ? » Oui — depuis le point de vue propre du groupe, délibérément et explicitement, plutôt qu'effet secondaire d'une frontière qui fuit. La distinction est tout le design : franchir la ligne doit être un acte que quelqu'un a accompli volontairement, avec l'autorité de le faire. Cela ne doit jamais être quelque chose qu'un identifiant égaré peut accomplir par accident.
Et la question qu'ils posent en troisième : « que se passe-t-il si nous vendons l'une des marques ? » Une frontière que la base de données maintient est aussi une frontière dont vous pouvez extraire une copie propre. Ce n'est pas une coïncidence — séparation et portabilité sont la même propriété vue depuis deux réunions différentes.
Sous le plancher
Ce qui tient la ligne, concrètement
Pas une affirmation, une liste. Si un fournisseur ne peut pas produire cette liste au sujet de son propre produit, cela mérite d'être remarqué.
26
Des tables qui portent leur société, avec la vérification forcée plutôt que simplement disponible.
72
Des politiques, rédigées une par une afin que chacune ait été lue par une personne, et non générées en boucle.
942
Des tests, exécutés sur une base de données reconstruite de zéro à chaque modification.
0
Des sociétés par défaut. Une requête sans périmètre échoue avant d'atteindre les données — il n'existe aucun repli qu'on pourrait oublier de désactiver.
« Cinq sociétés, cinq installations, cinq factures de votre part. »
Une seule installation. Cinq frontières que la base de données maintient.
Des personnes partagées, des habitudes partagées, une plateforme partagée — et pas un seul client partagé. Franchir cette ligne doit être un acte délibéré d'une personne, jamais un identifiant géré par accident.
Comment la séparation est construite →