Source unique de verite : des systemes d'organisation que vous definissez une fois et utilisez partout

Voici un schema qui apparait dans toute organisation au-dela d'une certaine taille. L'equipe A documente son architecture. Elle ajoute une boite pour le Service d'Authentification — nom, description, stack technique. L'equipe B fait la meme chose dans son projet. L'equipe C aussi. Trois projets, trois definitions separees du meme systeme, chacune legerement differente. L'une dit "Service Auth", l'autre dit "Plateforme d'Authentification", la troisieme dit "Fournisseur d'Identite". Meme systeme. Trois noms. Trois descriptions qui mettent l'accent sur des aspects differents. Aucune connexion entre elles.

Six mois plus tard, l'equipe d'authentification renomme le service et met a jour sa stack technique. Le changement se propage a zero de ces trois diagrammes. La version de la realite de chaque projet diverge silencieusement du systeme reel et des autres.

C'est le probleme de coherence. Il ne vient pas de la negligence. Il vient d'outils d'architecture qui traitent chaque projet comme une ile. Si la seule facon de representer un systeme est de le creer a l'interieur d'un projet, alors chaque projet qui touche ce systeme obtient sa propre copie. Les copies derivent. C'est ce que font les copies.

Nous avons construit les systemes au niveau de l'organisation pour resoudre ce probleme.

Des systemes qui appartiennent a l'organisation, pas a un projet

Archyl supporte desormais deux portees pour les systemes C4. Les systemes de portee projet fonctionnent exactement comme avant — ils appartiennent a un seul projet et vivent sur le diagramme de ce projet. Les systemes de portee organisation appartiennent a votre organisation. Ils existent independamment de tout projet, et n'importe quel projet peut s'y lier.

La distinction compte parce qu'elle reflete le fonctionnement reel de l'architecture. Certains systemes sont internes a un projet — un microservice qui n'existe que dans ce contexte delimite, une base de donnees qui sert une seule application. Ceux-la appartiennent au projet. Mais beaucoup de systemes traversent les frontieres des projets — infrastructure partagee, services de plateforme, integrations tierces, capacites metier centrales dont plusieurs equipes dependent. Ceux-la appartiennent a l'organisation.

Quand vous creez un systeme au niveau de l'organisation, vous faites une declaration : ce systeme est une realite partagee. Son nom, sa description, sa technologie et ses tags sont definis une seule fois. Chaque projet qui le reference voit la meme definition.

Comment ca fonctionne

Creer des systemes d'organisation

Les systemes d'organisation sont crees depuis une section dediee dans la plateforme. Vous definissez le systeme de la meme maniere que dans un projet — nom, description, type (systeme logiciel, systeme externe ou personne), technologie et tags. La difference est qu'il n'est lie a aucun projet. Il vit au niveau de l'organisation, visible par toutes les equipes.

Lier des systemes aux projets

Lorsque vous travaillez sur le diagramme d'un projet et souhaitez referencer un systeme d'organisation, vous le liez. Une modale vous montre tous les systemes d'organisation disponibles avec une recherche. Activez ceux dont vous avez besoin — ils apparaissent immediatement sur votre diagramme.

Les systemes lies se comportent comme des systemes natifs sur le diagramme. Vous pouvez les positionner ou bon vous semble pour la mise en page de ce projet. Vous pouvez creer des relations vers et depuis eux. Vous pouvez explorer en detail leurs conteneurs et composants. La seule difference est que l'identite fondamentale du systeme — son nom, sa description, sa technologie — provient de la definition de l'organisation, pas du projet.

Chaque projet stocke sa propre position pour le systeme lie, donc le meme systeme peut se trouver a des endroits differents sur differents diagrammes. La mise en page est par projet. La definition est partagee.

Delier

Si un projet ne depend plus d'un systeme partage, deliez-le. Le systeme disparait du diagramme du projet mais continue d'exister au niveau de l'organisation et dans tous les autres projets qui le referencent. Aucune donnee n'est perdue. Aucune autre equipe n'est impactee.

Pourquoi c'est important

Coherence sans coordination

L'approche traditionnelle pour maintenir la coherence de la documentation d'architecture est le processus. Vous ecrivez des conventions de nommage. Vous organisez des reunions de revue. Vous demandez aux gens de verifier comment les autres equipes ont nomme le meme systeme. Le processus fonctionne jusqu'a ce qu'il ne fonctionne plus — c'est-a-dire generalement au moment ou quelqu'un est presse, ce qui est la plupart du temps.

Les systemes au niveau de l'organisation rendent la coherence structurelle. Il y a une definition. Les projets la referencent. Quand quelqu'un met a jour la description ou la stack technique du systeme, chaque projet qui y est lie reflete le changement automatiquement. Pas de messages Slack. Pas de "merci de mettre a jour votre diagramme". L'architecture reste coherente parce que le modele d'architecture l'impose.

Des dependances inter-projets precises

Quand plusieurs projets sont lies au meme systeme d'organisation, la plateforme connait ces connexions. Ce n'est pas une convention visuelle — c'est une relation de donnees. Impact Radar peut tracer les dependances a travers les systemes d'organisation au-dela des frontieres des projets. Si vous analysez l'impact de la modification d'un service de plateforme partage, vous voyez chaque projet qui en depend, parce qu'ils sont tous lies au meme systeme plutot que de maintenir des copies independantes.

Integration et decouverte

Les nouveaux membres d'equipe rejoignant un projet voient les memes noms de systemes, descriptions et labels de technologie que tous les autres projets utilisent. Il n'y a pas de moment "c'est quel Service Auth ?". Le systeme d'organisation porte son identite avec lui, et cette identite est la meme partout.

Duplication reduite

Au-dela de l'avantage de coherence, les systemes d'organisation reduisent simplement le travail. Au lieu que chaque projet documente independamment la meme infrastructure — le broker de messages, la passerelle API, le fournisseur d'identite, la stack de monitoring — vous definissez chacun une seule fois. Les projets s'y lient en quelques secondes. Le temps passe a recreer les memes boites avec des labels legerement differents tombe a zero.

Ce qui change dans le modele de donnees

Sous le capot, l'entite systeme C4 supporte desormais deux portees mutuellement exclusives. Un systeme appartient soit a un projet soit a une organisation — jamais les deux, jamais aucun. Ceci est impose au niveau de la base de donnees par une contrainte.

Une table de liaison separee suit quels projets referencent quels systemes d'organisation, avec la position par projet sur le diagramme. Cela signifie que le meme systeme peut apparaitre sur dix diagrammes de projets differents, chacun positionne differemment, chacun avec son propre ensemble de relations vers les elements locaux du projet.

Quand vous chargez le modele C4 d'un projet, la plateforme recupere a la fois les systemes propres au projet et les systemes d'organisation qui y sont lies. Ils fusionnent de maniere transparente sur le diagramme. La distinction est visible dans l'interface — les systemes d'organisation portent un indicateur subtil montrant qu'ils sont partages — mais fonctionnellement, ils participent au modele d'architecture de la meme maniere que les systemes de projet.

La vision d'ensemble

Cette fonctionnalite s'inscrit dans une direction plus large : faire en sorte qu'Archyl fonctionne comme les organisations fonctionnent reellement. L'architecture n'est pas une collection de projets independants. C'est un reseau de systemes partages, de capacites de plateforme et de preoccupations transversales. Les outils devraient refleter cela.

Les systemes au niveau de l'organisation sont la premiere etape vers un modele ou l'infrastructure partagee est documentee une fois et referencee partout. Combines avec la vue Architecture Globale pour la visualisation inter-projets et Impact Radar pour l'analyse des dependances inter-projets, vous disposez maintenant d'une plateforme qui comprend votre architecture comme un tout connecte — pas comme un ensemble de diagrammes deconnectes.

Pour commencer

Les systemes au niveau de l'organisation sont disponibles des maintenant. Rendez-vous dans la section organisation, creez vos systemes partages, puis liez-les a n'importe quel projet depuis la vue diagramme. Si vous avez deja documente le meme systeme dans plusieurs projets, c'est l'occasion de consolider — definissez-le une fois, liez-le partout, et laissez les copies prendre leur retraite.

Votre architecture a une source unique de verite. Votre documentation devrait en avoir une aussi.

Pour en savoir plus sur l'architecture inter-projets, consultez Architecture Globale et Collaboration en Temps Reel. Pour comprendre comment les changements sur les systemes partages se propagent, essayez Impact Radar. Pour des changements gouvernes sur les systemes partages, explorez les Demandes de Changement d'Architecture.