Systèmes au niveau de l'organisation : définir une fois, réutiliser partout

Voici un schéma qui apparaît dans toute organisation au-delà d'une certaine taille. L'équipe A documente son architecture. Elle ajoute une boîte pour le Service d'Authentification — nom, description, stack technique. L'équipe B fait la même chose dans son projet. L'équipe C aussi. Trois projets, trois définitions séparées du même système, chacune légèrement différente. L'une dit "Service Auth", l'autre dit "Plateforme d'Authentification", la troisième dit "Fournisseur d'Identité". Même système. Trois noms. Trois descriptions qui mettent l'accent sur des aspects différents. Aucune connexion entre elles.

Six mois plus tard, l'équipe d'authentification renomme le service et met à jour sa stack technique. Le changement se propage à zéro de ces trois diagrammes. La version de la réalité de chaque projet diverge silencieusement du système réel et des autres.

C'est le problème de cohérence. Il ne vient pas de la negligence. Il vient d'outils d'architecture qui traitent chaque projet comme une ile. Si la seule façon de représenter un système est de le créer à l'intérieur d'un projet, alors chaque projet qui touche ce système obtient sa propre copie. Les copies dérivent. C'est ce que font les copies.

Nous avons construit les systèmes au niveau de l'organisation pour résoudre ce problème.

Des systèmes qui appartiennent à l'organisation, pas à un projet

Archyl supporte désormais deux portées pour les systèmes C4. Les systèmes de portée projet fonctionnent exactement comme avant — ils appartiennent à un seul projet et vivent sur le diagramme de ce projet. Les systèmes de portée organisation appartiennent à votre organisation. Ils existent indépendamment de tout projet, et n'importe quel projet peut s'y lier.

La distinction compte parce qu'elle reflète le fonctionnement réel de l'architecture. Certains systèmes sont internes à un projet — un microservice qui n'existe que dans ce contexte délimité, une base de données qui sert une seule application. Ceux-là appartiennent au projet. Mais beaucoup de systèmes traversent les frontières des projets — infrastructure partagée, services de plateforme, intégrations tierces, capacités métier centrales dont plusieurs équipes dépendent. Ceux-là appartiennent à l'organisation.

Quand vous créez un système au niveau de l'organisation, vous faites une declaration : ce système est une réalité partagée. Son nom, sa description, sa technologie et ses tags sont définis une seule fois. Chaque projet qui le référence voit la même définition.

Comment ça fonctionne

Créer des systèmes d'organisation

Les systèmes d'organisation sont créés depuis une section dédiée dans la plateforme. Vous définissez le système de la même manière que dans un projet — nom, description, type (système logiciel, système externe ou personne), technologie et tags. La différence est qu'il n'est lié à aucun projet. Il vit au niveau de l'organisation, visible par toutes les équipes.

Lier des systèmes aux projets

Lorsque vous travaillez sur le diagramme d'un projet et souhaitez référencer un système d'organisation, vous le liez. Une modale vous montre tous les systèmes d'organisation disponibles avec une recherche. Activez ceux dont vous avez besoin — ils apparaissent immédiatement sur votre diagramme.

Les systèmes liés se comportent comme des systèmes natifs sur le diagramme. Vous pouvez les positionner ou bon vous semble pour la mise en page de ce projet. Vous pouvez créer des relations vers et depuis eux. Vous pouvez explorer en détail leurs conteneurs et composants. La seule différence est que l'identité fondamentale du système — son nom, sa description, sa technologie — provient de la définition de l'organisation, pas du projet.

Chaque projet stocke sa propre position pour le système lié, donc le même système peut se trouver à des endroits différents sur différents diagrammes. La mise en page est par projet. La définition est partagée.

Délier

Si un projet ne dépend plus d'un système partage, déliez-le. Le système disparaît du diagramme du projet mais continue d'exister au niveau de l'organisation et dans tous les autres projets qui le référencent. Aucune donnée n'est perdue. Aucune autre équipe n'est impactée.

Pourquoi c'est important

Cohérence sans coordination

L'approche traditionnelle pour maintenir la cohérence de la documentation d'architecture est le processus. Vous écrivez des conventions de nommage. Vous organisez des réunions de revue. Vous demandez aux gens de vérifier comment les autres équipes ont nommé le même système. Le processus fonctionne jusqu'à ce qu'il ne fonctionne plus — c'est-à-dire généralement au moment où quelqu'un est pressé, ce qui est la plupart du temps.

Les systèmes au niveau de l'organisation rendent la cohérence structurelle. Il y a une définition. Les projets la référencent. Quand quelqu'un met à jour la description ou la stack technique du système, chaque projet qui y est lié reflète le changement automatiquement. Pas de messages Slack. Pas de "merci de mettre à jour votre diagramme". L'architecture reste cohérente parce que le modèle d'architecture l'impose.

Des dépendances inter-projets précises

Quand plusieurs projets sont liés au même système d'organisation, la plateforme connaît ces connexions. Ce n'est pas une convention visuelle — c'est une relation de données. Impact Radar peut tracer les dépendances à travers les systèmes d'organisation au-delà des frontières des projets. Si vous analysez l'impact de la modification d'un service de plateforme partage, vous voyez chaque projet qui en dépend, parce qu'ils sont tous liés au même système plutôt que de maintenir des copies indépendantes.

Intégration et découverte

Les nouveaux membres d'équipe rejoignant un projet voient les mêmes noms de systèmes, descriptions et labels de technologie que tous les autres projets utilisent. Il n'y a pas de moment "c'est quel Service Auth ?". Le système d'organisation porte son identité avec lui, et cette identité est la même partout.

Duplication réduite

Au-delà de l'avantage de cohérence, les systèmes d'organisation réduisent simplement le travail. Au lieu que chaque projet documente indépendamment la même infrastructure — le broker de messages, la passerelle API, le fournisseur d'identité, la stack de monitoring — vous définissez chacun une seule fois. Les projets s'y lient en quelques secondes. Le temps passe à recréer les mêmes boîtes avec des labels légèrement différents tombe à zéro.

Ce qui change dans le modèle de données

Sous le capot, l'entité système C4 supporte désormais deux portées mutuellement exclusives. Un système appartient soit à un projet soit à une organisation — jamais les deux, jamais aucun. Ceci est imposé au niveau de la base de données par une contrainte.

Une table de liaison séparée suit quels projets référencent quels systèmes d'organisation, avec la position par projet sur le diagramme. Cela signifie que le même système peut apparaître sur dix diagrammes de projets différents, chacun positionne différemment, chacun avec son propre ensemble de relations vers les éléments locaux du projet.

Quand vous chargez le modèle C4 d'un projet, la plateforme récupère à la fois les systèmes propres au projet et les systèmes d'organisation qui y sont liés. Ils fusionnent de manière transparente sur le diagramme. La distinction est visible dans l'interface — les systèmes d'organisation portent un indicateur subtil montrant qu'ils sont partagés — mais fonctionnellement, ils participent au modèle d'architecture de la même manière que les systèmes de projet.

La vision d'ensemble

Cette fonctionnalité s'inscrit dans une direction plus large : faire en sorte qu'Archyl fonctionne comme les organisations fonctionnent réellement. L'architecture n'est pas une collection de projets indépendants. C'est un réseau de systèmes partagés, de capacités de plateforme et de préoccupations transversales. Les outils devraient refléter cela.

Les systèmes au niveau de l'organisation sont la première étape vers un modèle ou l'infrastructure partagée est documentée une fois et référencée partout. Combinés avec la vue Architecture Globale pour la visualisation inter-projets et Impact Radar pour l'analyse des dépendances inter-projets, vous disposez maintenant d'une plateforme qui comprend votre architecture comme un tout connecte — pas comme un ensemble de diagrammes déconnectés.

Pour commencer

Les systèmes au niveau de l'organisation sont disponibles dès maintenant. Rendez-vous dans la section organisation, créez vos systèmes partagés, puis liez-les à n'importe quel projet depuis la vue diagramme. Si vous avez déjà documenté le même système dans plusieurs projets, c'est l'occasion de consolider — définissez-le une fois, liez-le partout, et laissez les copies prendre leur retraite.

Votre architecture a une source unique de vérité. Votre documentation devrait en avoir une aussi.

Pour en savoir plus sur l'architecture inter-projets, consultez Architecture Globale et Collaboration en Temps Réel. Pour comprendre comment les changements sur les systèmes partagés se propagent, essayez Impact Radar. Pour des changements gouvernes sur les systèmes partagés, explorez les Demandes de Changement d'Architecture.