Rimanere vero

Ogni modello che hai visto era corretto, una volta.

Il CMDB era accurato nella settimana in cui è entrato in produzione. Il diagramma architetturale era corretto al momento della revisione. Il catalogo dati era completo al momento della consegna. Poi l'organizzazione è cambiata, e nulla, in nessuno di essi, se n'è accorto. Se ti stai chiedendo se anche questo finirà allo stesso modo, è proprio la domanda giusta da porsi.

Il CMDB

accurato nella settimana in cui è entrato in produzione

Il diagramma architetturale

corretto al momento della revisione

Il catalogo dati

completo al momento della consegna

La modalità di fallimento

Nato già obsoleto, e sembra andare bene solo per un po'.

Chiunque venda intelligenza ti offre una fonte unica di verità. L'unica fonte di verità è la realtà. Ogni modello, catalogo e registro — compreso il nostro — ne è una copia, e una copia senza un meccanismo per seguire la realtà mentre cambia non diventerà obsoleta prima o poi: nasce obsoleta, e sembra andare bene solo perché il divario impiega un po' a manifestarsi.

Un modello che nessuno può modificare si calcifica; un modello che chiunque può modificare degrada.

nessuno può modificarlo

si calcifica

Chiudilo dietro un comitato di governance e diventa un documento su com'era l'organizzazione a marzo.

chiunque può modificarlo

degrada

Aprilo a tutti e diventa un wiki con dei tipi — le stesse contraddizioni di prima, ora con uno schema.

~1 anno

La trappola è che entrambi i fallimenti sembrano un successo per circa un anno. La calcificazione sembra stabilità. Il degrado sembra adozione.

Il che indica qual è davvero il problema. Il degrado non è un problema di dati. È un problema di instradamento delle responsabilità.

L'organizzazione sapeva sempre che la cosa era cambiata — qualcuno lo sapeva. Niente ha portato quella conoscenza al modello, e nessuno è stato interpellato.

Metà del modello

Ciò che viene letto da un sistema non può discostarsi da quel sistema.

Gran parte del tuo modello non viene scritta affatto. Viene letta — dal catalogo che hai già curato, dal sistema HR, dall'identity provider, dagli schemi stessi. Quei nodi non diventano obsoleti, perché nessuno mantiene una seconda copia che potrebbe restare indietro. Sono lo stato attuale della fonte, tipizzato.

E quando qualcosa scompare dalla fonte, non è silenzio. Il nodo passa a Assente nella sorgente — uno stato della famiglia Inattivo. Non viene semplicemente segnalato: viene retrocesso, e ogni attraversamento che passa da lì ora lo dichiara.

Questa è la metà economica della risposta, e vale la pena dirlo chiaramente: è la metà economica. Copre sistemi, dataset, persone e accessi. Non copre ciò che solo una persona sa.

L'altra metà

Il resto ha un owner. E all'owner viene chiesto.

Ogni tipo di nodo porta con sé la propria matrice delle responsabilità — chi ne è l'owner, chi ne è lo steward, chi approva una modifica, chi è l'esperto. Non una convenzione che qualche team segue. Parte del tipo, così un nodo di quel tipo non può esistere senza che sia stata risolta la questione di chi ne risponde.

A questo si aggiungono casi d'uso con i propri workflow: che cosa significano davvero «rivedi questo», «passa le consegne» o «approva questa modifica» per quel tipo di cosa. Rivedere un accordo con un fornitore non è lo stesso atto che rivedere una competenza tecnica, e il modello conosce la differenza.

Così, quando qualcosa si muove, le persone che ne rispondono vengono coinvolte — dal workflow adatto, non da una notifica. Quattro cose lo avviano:

Una fonte è cambiata

Il sistema di riferimento non dice più ciò che dice il modello.

reazione

Qualcuno ha proposto una modifica

Una proposta governata, con una traccia di audit — non una modifica diretta.

reazione

Uno stato del ciclo di vita è cambiato

Un nodo che entra in In revisione o in Disattivazione in corso trascina con sé i propri dipendenti.

reazione

Un controllo periodico è arrivato a scadenza

Niente si è mosso, ed è proprio questo il punto: il silenzio non è una prova.

il modello che chiede

La quarta è quella che distingue tutto questo da ogni catalogo che hai usato. Le altre sono reazioni. Quella è il modello che chiede se è ancora vero all'unica parte in grado di rispondere.

Qualcosa si muove, oppure un controllo arriva a scadenza

La matrice delle responsabilità dice chi risponde

Il workflow del caso d'uso pone loro la domanda giusta

La risposta diventa un cambio di stato, con la propria traccia

Metamodello

Prodotto dati

Tipi di responsabilità

Assegna tipo di responsabilità

Proprietario

È di proprietà di

La parte con la responsabilità ultima sul nodo e piena autorità su ogni decisione che lo riguarda. Risponde della sua esistenza, della sua correttezza e del suo destino, dall'inizio alla fine.

Steward dei dati

È curato da

La parte responsabile di curare, giorno per giorno, il significato di business e la qualità dei dati del nodo. Ne mantiene la definizione, l'accuratezza e l'idoneità all'uso, ma non detiene su di esso l'autorità decisionale ultima.

Approvatore

È approvato da

La parte che detiene l'autorità per approvare formalmente il nodo, o le sue modifiche, affinché diventi valido o rilasciato. Risponde della decisione di approvazione in sé, distinta dalla valutazione continuativa o dalla responsabilità complessiva.

Esperto in materia

La competenza è fornita da

La persona designata a fornire chiarimenti sull'argomento che il nodo rappresenta, a cui ci si affida per una conoscenza approfondita e diretta di esso. Fornisce il contesto e le informazioni che i record e la documentazione del nodo non catturano — un'autorità consultiva sull'argomento in sé, non su come il nodo viene mantenuto.

la matrice delle responsabilità su un tipo di nodo — proprietario, steward, approvatore, esperto

Niente di tutto questo è l'agente che cambia la tua organizzazione. Identifica, segnala, monitora ed effettua escalation — autonomia dell'attenzione, non dell'autorità. A decidere è sempre una persona. Ciò che è cambiato è che la decisione le arriva quando costa ancora poco.

L'assenza, resa visibile

Mancante è uno stato che puoi vedere, non un campo vuoto.

I modelli si deteriorano in silenzio perché l'assenza non sembra nulla. Un owner non compilato, un confine mai scritto, un nodo la cui fonte è svanita — nessuno di questi alza la mano. Qui lo stesso principio attraversa tre punti, ed è ogni volta lo stesso principio.

Assegnato · non ancora Informato

Una responsabilità assegnata e mai comunicata. Non un campo vuoto — un piolo di una scala su cui il modello può vedere dove ti trovi.

Assente nella sorgente

Uno stato della famiglia Inattivo. Il nodo viene retrocesso, non annotato.

Certificato Bronzo · Argento · Oro

Nella famiglia Attivo. La verifica è un modo di essere aggiornati — e la sua assenza è altrettanto leggibile.

Il che rende la salute del modello un attraversamento come un altro. Non un report di maturità che qualcuno assembla una volta al trimestre: una domanda che poni allo stesso grafo, con la stessa sintassi che usi per tutto il resto.

Ciò che questo non risolve

Qui nulla modella ciò che non è mai stato modellato.

il confine del ciclo

Se un'abilità, un obbligo o una dipendenza non sono mai stati tipizzati, nessun instradamento li farà emergere. Il ciclo mantiene vero ciò che è nel modello. Non scopre ciò che ne sta fuori.

il confine della metà letta

Un nodo letto da un sistema resta fedele a quel sistema. Se il sistema è sbagliato, il modello è fedelmente sbagliato. Ciò che il modello aggiunge è che il disaccordo tra due sistemi diventa visibile, perché entrambi sono tipizzati nello stesso grafo.

Ecco perché la copertura cresce per decisione, non per ambizione. Estendi il modello dove sbagliare ti costerebbe qualcosa — e tutto ciò che hai esteso resta vero grazie allo stesso meccanismo di tutto ciò che c'era prima.

Verificalo tu stesso

Tutto quanto sopra è verificabile senza parlare con noi.

Le famiglie del ciclo di vita, la matrice delle responsabilità su un tipo, una responsabilità ferma allo stato Assegnato di cui nessuno è mai stato informato — si trovano in un tenant demo con Adventure Works completamente modellata. La stessa organizzazione di cui hai letto finora.

senza di noi

Vai a verificarlo.

Accedi con un account aziendale e chiedi qualcosa al modello. Nessuna chiamata, nessun modulo, nessuna prova da avviare.

Apri la demo

con noi

Oppure modella il tuo.

Il Design Partner Program è per le organizzazioni che vogliono il proprio modello costruito insieme al nostro team, prima della disponibilità generale.

Design Partner Program →

Una delle due strade richiede due minuti e non ci coinvolge. Inizia da lì.