Sistemi a livello di organizzazione: definiscili una volta, riusali ovunque

Ecco uno schema che compare in ogni organizzazione oltre una certa dimensione. Il team A documenta la propria architettura. Aggiunge un box per l'Authentication Service: nome, descrizione, stack tecnologico. Il team B fa la stessa cosa nel suo progetto. Anche il team C. Tre progetti, tre definizioni separate dello stesso sistema, ognuna leggermente diversa. Una dice "Auth Service", un'altra "Authentication Platform", la terza "Identity Provider". Stesso sistema. Tre nomi. Tre descrizioni che mettono l'accento su cose diverse. Nessun collegamento tra loro.

Sei mesi dopo, il team di autenticazione rinomina il servizio e aggiorna lo stack tecnologico. La modifica arriva a zero di quei tre diagrammi. La versione della realtà di ogni progetto si allontana in silenzio dal sistema reale e dalle altre.

È il problema della coerenza. Non nasce dalla negligenza. Nasce da strumenti di architettura che trattano ogni progetto come un'isola. Se l'unico modo di rappresentare un sistema è crearlo dentro un progetto, allora ogni progetto che tocca quel sistema ne ottiene una copia propria. Le copie divergono. È quello che fanno le copie.

Abbiamo costruito i sistemi a livello di organizzazione per risolvere questo problema.

Sistemi che appartengono all'organizzazione, non a un progetto

Archyl ora supporta due ambiti per i sistemi C4. I sistemi con ambito di progetto funzionano esattamente come prima: appartengono a un solo progetto e vivono sul diagramma di quel progetto. I sistemi con ambito di organizzazione appartengono alla tua organizzazione. Esistono indipendentemente da qualsiasi progetto, e qualsiasi progetto può collegarli.

La distinzione conta perché rispecchia il modo in cui funziona l'architettura reale. Alcuni sistemi sono interni a un progetto: un microservizio che esiste solo all'interno di quel bounded context, un database che serve una sola applicazione. Quelli appartengono al progetto. Ma molti sistemi attraversano i confini dei progetti: infrastruttura condivisa, servizi di piattaforma, integrazioni di terze parti, capacità di business centrali da cui dipendono più team. Quelli appartengono all'organizzazione.

Quando crei un sistema a livello di organizzazione, stai affermando una cosa: questo sistema è una realtà condivisa. Nome, descrizione, tecnologia e tag sono definiti una volta sola. Ogni progetto che vi fa riferimento vede la stessa definizione.

Come funziona

Creare i sistemi dell'organizzazione

I sistemi dell'organizzazione si creano da una sezione dedicata della piattaforma. Definisci il sistema come faresti in un progetto: nome, descrizione, tipo (software system, sistema esterno o persona), tecnologia e tag. La differenza è che non è legato a nessun progetto. Vive a livello di organizzazione, visibile a tutti i team.

Collegare i sistemi ai progetti

Quando lavori sul diagramma di un progetto e vuoi fare riferimento a un sistema dell'organizzazione, lo colleghi. Una finestra mostra tutti i sistemi dell'organizzazione disponibili, con la ricerca. Attiva quelli che ti servono: compaiono subito sul tuo diagramma.

I sistemi collegati si comportano sul diagramma come quelli nativi. Puoi posizionarli dove ha più senso per il layout di quel progetto. Puoi creare relazioni verso di loro e a partire da loro. Puoi scendere nei loro container e componenti. L'unica differenza è che l'identità di base del sistema (nome, descrizione, tecnologia) viene dalla definizione dell'organizzazione, non dal progetto.

Ogni progetto memorizza la propria posizione per il sistema collegato, così lo stesso sistema può stare in punti diversi su diagrammi diversi. Il layout è per progetto. La definizione è condivisa.

Scollegare

Se un progetto non dipende più da un sistema condiviso, scollegalo. Il sistema sparisce dal diagramma del progetto ma continua a esistere a livello di organizzazione e in ogni altro progetto che vi fa riferimento. Nessun dato va perso. Nessun altro team ne risente.

Perché è importante

Coerenza senza coordinamento

L'approccio tradizionale per mantenere coerente la documentazione dell'architettura è il processo. Scrivi convenzioni di naming. Organizzi riunioni di revisione. Chiedi alle persone di controllare come gli altri team hanno chiamato lo stesso sistema. Il processo funziona finché non smette di funzionare, cioè di solito nel momento in cui qualcuno ha fretta, cioè quasi sempre.

I sistemi a livello di organizzazione rendono la coerenza strutturale. C'è una sola definizione. I progetti vi fanno riferimento. Quando qualcuno aggiorna la descrizione o lo stack tecnologico del sistema, ogni progetto collegato riflette automaticamente la modifica. Niente messaggi su Slack. Niente "per favore aggiorna il tuo diagramma". L'architettura resta coerente perché è il modello di architettura a imporlo.

Dipendenze tra progetti accurate

Quando più progetti collegano lo stesso sistema dell'organizzazione, la piattaforma conosce quelle connessioni. Non è una convenzione visiva: è una relazione nei dati. Impact Radar può tracciare le dipendenze attraverso i sistemi dell'organizzazione oltre i confini dei progetti. Se analizzi l'impatto della modifica di un servizio di piattaforma condiviso, vedi ogni progetto che ne dipende, perché tutti collegano lo stesso sistema invece di mantenerne copie indipendenti.

Onboarding e reperibilità

I nuovi membri che entrano in un progetto vedono gli stessi nomi di sistema, le stesse descrizioni e le stesse etichette tecnologiche usate da ogni altro progetto. Non c'è il momento "quale Auth Service è questo?". Il sistema dell'organizzazione porta con sé la propria identità, e quell'identità è la stessa ovunque.

Meno duplicazione

Oltre al vantaggio della coerenza, i sistemi dell'organizzazione riducono semplicemente il lavoro. Invece di far documentare a ogni progetto la stessa infrastruttura (il message broker, l'API gateway, l'identity provider, lo stack di monitoraggio), definisci ciascuno una volta sola. I progetti li collegano in pochi secondi. Il tempo speso a ricreare gli stessi box con etichette leggermente diverse scende a zero.

Cosa cambia nel modello dei dati

Dietro le quinte, l'entità sistema C4 ora supporta due ambiti mutuamente esclusivi. Un sistema appartiene a un progetto oppure a un'organizzazione: mai a entrambi, mai a nessuno dei due. Questo è garantito a livello di database da un vincolo.

Una tabella di collegamento separata tiene traccia di quali progetti fanno riferimento a quali sistemi dell'organizzazione, insieme alla posizione per progetto sul diagramma. Lo stesso sistema può quindi comparire su dieci diagrammi di progetto diversi, ciascuno posizionato in modo diverso, ciascuno con il proprio insieme di relazioni verso gli elementi locali del progetto.

Quando carichi il modello C4 di un progetto, la piattaforma recupera sia i sistemi propri del progetto sia i sistemi dell'organizzazione collegati. Si fondono senza soluzione di continuità sul diagramma. La distinzione è visibile nell'interfaccia (i sistemi dell'organizzazione hanno un indicatore discreto che li segnala come condivisi), ma dal punto di vista funzionale partecipano al modello di architettura esattamente come i sistemi di progetto.

Il quadro più ampio

Questa funzionalità fa parte di una direzione più ampia: far funzionare Archyl nel modo in cui funzionano davvero le organizzazioni. L'architettura non è una raccolta di progetti indipendenti. È una rete di sistemi condivisi, capacità di piattaforma e aspetti trasversali. Gli strumenti dovrebbero rifletterlo.

I sistemi a livello di organizzazione sono il primo passo verso un modello in cui l'infrastruttura condivisa viene documentata una volta e referenziata ovunque. Insieme alla vista Architettura Globale per la visualizzazione tra progetti e a Impact Radar per l'analisi delle dipendenze tra progetti, ora hai una piattaforma che comprende la tua architettura come un insieme connesso, e non come una serie di diagrammi scollegati.

Per iniziare

I sistemi a livello di organizzazione sono disponibili ora. Vai alla sezione dell'organizzazione, crea i tuoi sistemi condivisi, poi collegali a qualsiasi progetto dalla vista del diagramma. Se hai già documentato lo stesso sistema in più progetti, è l'occasione per consolidare: definiscilo una volta, collegalo ovunque e manda in pensione le copie.

La tua architettura ha un'unica fonte di verità. Anche la tua documentazione dovrebbe averla.

Per saperne di più sull'architettura tra progetti, vedi Architettura Globale e collaborazione in tempo reale. Per capire come si propagano le modifiche ai sistemi condivisi, prova Impact Radar. Per modifiche governate ai sistemi condivisi, esplora le Architecture Change Request.