Rester fidèle

Chaque modèle que vous avez vu a eu raison, une fois.

La CMDB était exacte la semaine de sa mise en service. Le schéma d'architecture était correct lors de la revue. Le catalogue de données était complet à la livraison. Puis l'organisation a bougé, et rien, dans aucun d'eux, ne l'a remarqué. Si vous vous demandez si cela finit de la même façon, c'est exactement la question à se poser.

La CMDB

exacte la semaine de sa mise en service

Le schéma d'architecture

correct lors de la revue

Le catalogue de données

complet à la livraison

Le mode de défaillance

Né obsolète, et il ne fait illusion qu'un temps.

Tous ceux qui vendent de l'intelligence vous proposent une source unique de vérité. La seule source de vérité, c'est la réalité. Chaque modèle, catalogue et registre — le nôtre compris — en est une copie, et une copie dépourvue de mécanisme pour suivre la réalité à mesure qu'elle bouge ne va pas finir par se périmer : elle est née obsolète, et ne fait illusion que parce que l'écart met du temps à apparaître.

Un modèle que personne ne peut modifier se calcifie ; un modèle que n'importe qui peut modifier se dégrade.

personne ne peut le modifier

se calcifie

Verrouillez-le derrière un comité de gouvernance, et il devient un document sur l'organisation telle qu'elle était en mars.

n'importe qui peut le modifier

se dégrade

Ouvrez-le à tout le monde, et il devient un wiki avec des types — les mêmes contradictions qu'avant, désormais avec un schéma.

~1 an

Le piège, c'est que ces deux échecs ressemblent à un succès pendant environ un an. La calcification ressemble à de la stabilité. La dégradation ressemble à de l'adoption.

Ce qui montre où se situe réellement le problème. La dégradation n'est pas un problème de données. C'est un problème d'acheminement de la responsabilité.

L'organisation a toujours su que la chose avait changé — quelqu'un le savait. Rien n'a porté cette connaissance jusqu'au modèle, et personne n'a été consulté.

La moitié du modèle

Ce qui est lu depuis un système ne peut pas s'écarter de ce système.

Une grande partie de votre modèle n'est pas saisie du tout. Elle est lue — depuis le catalogue que vous avez déjà constitué, depuis le système RH, depuis le fournisseur d'identité, depuis les schémas eux-mêmes. Ces nœuds ne se périment pas, parce que personne ne maintient une seconde copie susceptible de prendre du retard. Ils sont l'état actuel de la source, typé.

Et quand quelque chose disparaît de la source, ce n'est pas un silence. Le nœud passe à Absent de la source — un statut de la famille Inactif. Il n'est pas simplement signalé : il est rétrogradé, et chaque parcours qui passe par lui le dit désormais.

C'est la moitié peu coûteuse de la réponse, et il faut être clair : c'est bien la moitié peu coûteuse. Elle couvre les systèmes, les jeux de données, les personnes et les accès. Elle ne couvre pas ce que seule une personne sait.

L'autre moitié

Le reste a un propriétaire. Et ce propriétaire est consulté.

Chaque type de nœud porte sa propre matrice de responsabilité — qui en est propriétaire, qui en assure la gestion, qui approuve une modification, qui en est l'expert. Ce n'est pas une convention qu'une équipe suit. Cela fait partie du type lui-même, si bien qu'un nœud de ce type ne peut exister sans que la question de qui en répond ait déjà été tranchée.

Par-dessus viennent des cas d'usage dotés de leurs propres workflows : ce que « réviser ceci », « transmettre ceci » ou « approuver cette modification » signifie réellement pour ce type d'élément. Réviser un accord fournisseur n'est pas le même acte que réviser une compétence technique, et le modèle connaît la différence.

Ainsi, quand quelque chose bouge, les personnes qui en répondent sont sollicitées — par le workflow adapté, pas par une simple notification. Quatre événements déclenchent cela :

Une source a changé

Le système de référence ne dit plus ce que dit le modèle.

réaction

Quelqu'un a proposé une modification

Une proposition gouvernée, avec une piste d'audit — pas une simple édition.

réaction

Un état de cycle de vie a changé

Un nœud qui passe en En cours d'examen ou en Désactivation en cours entraîne ses dépendants avec lui.

réaction

Une vérification périodique est arrivée à échéance

Rien n'a bougé, et c'est tout l'enjeu : le silence n'est pas une preuve.

le modèle qui demande

Le quatrième est celui qui distingue cette approche de tous les catalogues que vous avez utilisés. Les autres sont des réactions. Celui-ci, c'est le modèle qui demande s'il est toujours vrai, à la seule partie qui peut répondre.

Quelque chose bouge, ou une vérification arrive à échéance

La matrice de responsabilité indique qui répond

Le workflow du cas d'usage leur pose la bonne question

La réponse devient un changement d'état, avec sa piste d'audit

Métamodèle

Produit de données

Types de responsabilité

Attribuer un type de responsabilité

Propriétaire

A pour propriétaire

La partie qui porte la responsabilité ultime du nœud et détient une pleine autorité sur toute décision le concernant. Répond de son existence, de son exactitude et de son devenir, de bout en bout.

Gestionnaire de données

Est géré par

La partie chargée d'entretenir au quotidien la signification métier et la qualité des données du nœud. Maintient sa définition, son exactitude et son adéquation à l'usage, mais ne détient aucune autorité de décision ultime sur lui.

Approbateur

Est approuvé par

La partie qui détient l'autorité pour valider formellement le nœud, ou ses modifications, afin qu'il devienne valide ou publié. Répond de la décision de validation elle-même, distincte de l'évaluation continue comme de la responsabilité de bout en bout.

Expert métier

Reçoit l'expertise de

La personne désignée pour apporter des éclaircissements sur le sujet que représente le nœud, sollicitée pour sa connaissance approfondie et directe de celui-ci. Fournit le contexte et l'éclairage que les enregistrements et la documentation du nœud ne capturent pas — une autorité consultative sur le sujet lui-même, et non sur la façon dont le nœud est maintenu.

la matrice de responsabilité d'un type de nœud — propriétaire, gestionnaire de données, approbateur, expert

Dans tout cela, ce n'est jamais l'agent qui modifie votre organisation. Il identifie, signale, surveille et escalade — autonomie d'attention, pas d'autorité. C'est toujours une personne qui décide. Ce qui a changé, c'est que la décision lui parvient tant qu'elle coûte encore peu.

L'absence, rendue visible

Manquant est un état que vous pouvez voir, pas un champ vide.

Les modèles se dégradent en silence parce que l'absence ne ressemble à rien. Un propriétaire non renseigné, une frontière jamais écrite, un nœud dont la source a disparu — aucun d'eux ne lève la main. Le même principe opère ici à trois endroits, et c'est chaque fois le même principe.

Assignée · pas encore Informée

Une responsabilité qui a été distribuée et jamais communiquée. Pas un champ vide — un barreau d'échelle sur lequel le modèle peut voir que vous vous trouvez.

Absent de la source

Un statut de la famille Inactif. Le nœud est rétrogradé, pas annoté.

Certifié Bronze · Argent · Or

Dans la famille Actif. La vérification est une façon d'être à jour — et son absence est tout aussi lisible.

Ce qui fait de la santé du modèle un parcours comme un autre. Pas un rapport de maturité que quelqu'un assemble une fois par trimestre : une question que vous posez au même graphe, avec la même syntaxe que pour tout le reste.

Ce que cela ne corrige pas

Rien ici ne modélise ce qui n'a jamais été modélisé.

la limite de la boucle

Si une aptitude, une obligation ou une dépendance n'a jamais été typée, aucun routage ne la fera apparaître. La boucle maintient fidèle ce qui est dans le modèle. Elle ne découvre pas ce qui se trouve en dehors.

la limite de la moitié lue

Un nœud lu depuis un système reste fidèle à ce système. Si le système se trompe, le modèle se trompe fidèlement. Ce que le modèle apporte, c'est que le désaccord entre deux systèmes devient visible, parce que les deux sont typés dans le même graphe.

C'est pourquoi la couverture s'étend par décision, pas par ambition. Vous étendez le modèle là où une erreur vous coûterait quelque chose — et tout ce que vous avez étendu reste fidèle grâce au même mécanisme que tout ce qui précédait.

Vérifiez par vous-même

Tout ce qui précède est vérifiable sans nous parler.

Les familles de cycle de vie, la matrice de responsabilité d'un type, une responsabilité restée à l'état Assignée sans que personne en ait jamais été informé — tout cela se trouve dans un tenant de démonstration où Adventure Works est entièrement modélisée. La même organisation que celle dont vous venez de lire la description.

sans nous

Allez vérifier.

Connectez-vous avec un compte professionnel et posez une question au modèle. Aucun appel, aucun formulaire, aucun essai à lancer.

Ouvrir la démo

avec nous

Ou modélisez la vôtre.

Le Design Partner Program s'adresse aux organisations qui veulent faire construire leur propre modèle aux côtés de notre équipe, avant la disponibilité générale.

Design Partner Program →

L'une de ces options prend deux minutes et ne nous implique pas. Commencez par là.