Passa al contenuto principale

Comprensione del metamodello basato sui dati

La maggior parte degli strumenti di EA codifica il proprio modello a oggetti direttamente nel codice sorgente dell'applicazione. Canopy adotta un approccio diverso: ogni concetto strutturale — tipi di scheda, campi, sottotipi, relazioni, ruoli stakeholder e campi calcolati — è memorizzato come dato nel database, non come codice. Questa pagina spiega perché è stata presa questa decisione e cosa significa nella pratica.

Cos'è il metamodello​

Il metamodello è lo schema del proprio modello di AE. Definisce:

  • Tipi di scheda — i tipi di entità che si tracciano (Application, BusinessCapability, Initiative, ecc.)
  • Campi — le proprietà che tali entità possono avere (stato del ciclo di vita, costo, proprietario, stack tecnologico, ecc.)
  • Sottotipi — varianti più specifiche di un tipo che condividono lo stesso insieme di campi (ad es. Application → Microservice, SaaS, AI Agent)
  • Tipi di relazione — i collegamenti consentiti tra i tipi (Application «gira su» ITComponent, Initiative «realizza» BusinessCapability, ecc.)
  • Ruoli stakeholder — i ruoli che gli utenti possono ricoprire su una scheda specifica (Proprietario tecnico, Proprietario aziendale, Data Steward, ecc.)
  • Campi calcolati — formule che derivano i valori dei campi da altri dati al momento del salvataggio

Tutti questi elementi sono righe nelle tabelle card_types, relation_types e nelle relative colonne JSONB. Nessuno di essi richiede una modifica del codice o un riavvio dell'applicazione per essere modificato.

Perché dati e non codice?​

Personalizzazione senza fork​

Le organizzazioni hanno metamodelli di AE molto diversi tra loro. Alcuni team tracciano «Fornitore», «Licenza» e «SLA». Altri tracciano «Dominio dati», «Capacità ESG» e «Flusso di valore». Se il metamodello fosse codice, ogni personalizzazione richiederebbe un fork del prodotto o un sistema di plugin — entrambi costosi da mantenere.

Con un metamodello basato sui dati, un amministratore può aggiungere un nuovo campo, rinominare un tipo di scheda o definire un tipo di relazione personalizzato in pochi minuti tramite l'interfaccia utente o l'API. Il frontend si adatta automaticamente: la griglia dell'Inventario acquisisce una nuova colonna, la pagina di dettaglio della scheda mostra la nuova sezione e i report possono filtrare sul nuovo campo. Nessuna distribuzione richiesta.

Evoluzione dello schema senza migrazioni per cliente​

Quando Canopy introduce un nuovo tipo di scheda o campo integrato, lo fa tramite seed.py — una routine di avvio che verifica se la riga integrata esiste e la crea solo se mancante. Le personalizzazioni esistenti non vengono mai toccate. Ciò significa:

  • L'aggiornamento di Canopy non sovrascrive i campi personalizzati
  • I tipi integrati rimangono modificabili (è possibile cambiare l'icona, il colore o l'etichetta di «Application» senza creare un fork)
  • Se un valore predefinito integrato si discosta dal suo valore originale, una migrazione Alembic protetta corregge solo le righe non modificate

Multi-tenancy in un unico codice base​

Poiché il metamodello è un dato, un'unica istanza di Canopy può servire team con modelli a oggetti completamente diversi — oppure la stessa istanza può essere riconfigurata interamente senza toccare il codice sorgente.

La struttura di fields_schema​

Ogni tipo di scheda memorizza le proprie definizioni di campo come array JSONB di sezioni:

[
  {
    "section": "Technology",
    "columns": 2,
    "fields": [
      {
        "key": "techStack",
        "label": "Technology Stack",
        "type": "multiple_select",
        "options": [{"key": "java", "label": "Java"}, {"key": "python", "label": "Python"}],
        "weight": 2
      }
    ]
  }
]

Il valore weight su ciascun campo alimenta il punteggio di qualità dei dati — le schede vengono valutate da 0 a 100% in base a quanti campi ponderati sono compilati. Questo trasforma il metamodello in un meccanismo di controllo della qualità: si definisce cosa significa avere dati «buoni» assegnando pesi più alti ai campi più importanti.

Cosa non è possibile modificare tramite il metamodello​

Il metamodello governa la struttura, non il comportamento. Alcune cose rimangono nel codice:

  • Il motore di calcolo — l'ambiente sicuro che valuta le formule è una libreria Python (simpleeval). Le formule stesse sono dati, ma il valutatore è codice.
  • Il sistema dei permessi — l'insieme delle chiavi di permesso valide è un elenco consentito in backend/app/core/permissions.py. L'aggiunta di una nuova chiave di permesso (non solo la sua concessione) richiede una modifica del codice.
  • Lo schema del database — l'aggiunta di una nuova tabella di primo livello (ad es. un nuovo modulo come PPM o GRC) richiede una migrazione Alembic. Lo schema degli attributi delle schede si espande senza migrazioni perché gli attributi sono JSONB.

Vedere anche​