Le regole del gioco
Modello, contratti, relazioni, interfacce generiche, controlli, piani, ricevute e audit. Definisce come una realtà operativa si descrive e si governa; non contiene gli endpoint o le credenziali del cliente.
Dentro CIGP
Un modello comune. Sistemi reali.
La forza di CIGP non sta in un elenco di script o di console per vendor. Sta nel descrivere oggetti, relazioni e regole in modo coerente, poi nel collegare capacità tecniche riusabili ai sistemi concreti del cliente.
Il confine che rende estensibile il prodotto
Prodotto, Libreria e Istanza hanno responsabilità diverse.
È così che una tecnologia nuova può entrare senza trasformarsi in una nuova funzione verticale e senza confondere una capacità disponibile con il permesso di usarla.
La capacità riusabile
Definizioni, adapter, mapping, reader, writer e template versionati per una famiglia tecnica. Porta la specificità necessaria a leggere o modificare un sistema; non abilita da sola il target di un cliente.
La realtà del cliente
Sistemi, connessioni, asset, dati, riferimenti alle credenziali, selezioni, regole applicate e deleghe concrete. È qui che una capacità compatibile viene configurata e autorizzata per un contesto reale.
Aggiungere una descrizione non crea magicamente un'integrazione. Una scrittura reale richiede capacità tecnica attestata, configurazione coerente e autorizzazione per quel target.
Una tecnologia nuova
La specificità entra; il governo non si riscrive.
Si descrive la realtà
Che cosa sono gli oggetti, quali attributi hanno e come si collegano agli altri.
Si porta la traduzione
Una libreria rende disponibili mapping, lettura, scrittura o viste per la tecnologia interessata.
Si configura l'ambiente
L'istanza collega il sistema concreto, i target, le connessioni, i riferimenti credenziali e le regole.
Le superfici lo usano
Le funzioni consumano ciò che il modello e la capacità installata rendono effettivamente disponibile.
Il punto non è promettere «nessuno sviluppo»: una nuova tecnologia può richiedere lavoro di integrazione. Quel lavoro rimane circoscritto e riusabile, invece di diventare un'altra applicazione separata.
Il modello dichiarativo
Che cosa significa «dichiarativo»?
DataSource indica la capacità di dominio, DataSourceSystem il sistema concreto e DataLayer l'insieme di record governati. Il contratto descrive identità, attributi e operazioni ammesse; i riferimenti dichiarano come gli oggetti si collegano anche fra Data Layer diversi.
Queste definizioni sono una base comune per le funzioni che le supportano: osservare il contesto, preparare un'azione, applicare una regola o costruire un documento non richiede di inventare ogni volta il significato dei dati.
La descrizione, da sola, non esegue una modifica: per agire su un target servono una capacità tecnica attestata, il collegamento al sistema, i controlli e l'autorizzazione.
Una macchina virtuale nel modello
Identità e attributiQuale VM, stato, provenienza
RelazioniJob di backup, ultimo esito, monitoraggio
OperazioniCiò che è ammesso per quel tipo di oggetto
Il job di backup può vivere in un altro DataLayer. Il legame è esplicito nel contratto, non nascosto in una stringa.
Il lavoro quotidiano
Una realtà condivisa, tre modi distinti di lavorarci.
La forma delle viste e la disponibilità delle azioni derivano dai contratti e dalle capacità effettive, non da una nuova pagina costruita per ogni prodotto.
Operation Workspace
Consulta asset e dati collegati, osserva il contesto e apre le connessioni interattive autorizzate. Non crea, modifica o provisiona.
Azioni sui sistemi
Seleziona uno o più target e presenta le azioni mutative realmente disponibili per quell'oggetto, con campi, piano, controlli e risultato.
Workflow Provisioning
Compone azioni dello stesso modello in procedure con dipendenze e fasi, senza creare una via parallela per aggirare deleghe e controlli.
Il modello in pratica
Un servizio non è la somma di cinque schermate.
Una macchina virtuale può essere collegata al proprio job di backup, all'esito più recente, allo stato di monitoraggio e a osservazioni di sicurezza derivate dagli eventi del SIEM. Ogni dato conserva provenienza e significato; la relazione rende leggibile il servizio.
Gli stessi riferimenti possono sostenere osservazione, scelta del target, regole, verifica e documentazione, secondo le capacità presenti nell'istanza.
Quando si interviene
Un'azione parte dal target, non da un comando isolato.
La piattaforma risolve ciò che è disponibile per quel tipo di oggetto e per quel sistema concreto. L'operatore dichiara il perimetro; la capacità tecnica realizza l'intervento solo dopo le verifiche pertinenti.
1. Contesto e pianoTarget, azione, campi e impatto sono leggibili prima dell'esecuzione.
2. Decisione e delegaGrant, regole e Change quando richiesto controllano l'atto; le credenziali target restano lato server.
3. Esecuzione e memoriaLa transazione registra il risultato per ogni target; ricevuta e verifica dello stato seguono il contratto della mutazione.
Un'azione non compare solo perché un Data Layer è scrivibile. Servono copertura, writer attestato, binding, policy e autorizzazioni coerenti.
Oltre la singola operazione
Le stesse definizioni aiutano a vedere, controllare e documentare.
Asset Intelligence
Raccoglie e riconcilia osservazioni, identità e provenienza per rendere gli asset parte del contesto operativo.
Policy e conformità
Le regole possono intervenire prima di un'azione; la valutazione periodica della conformità è un lavoro distinto.
Document Builder
Riusa dati, relazioni e regole per documenti versionati e tracciabili, da rivedere e approvare dalle persone responsabili.
Parliamo del tuo contesto
Da quale sistema o processo partiresti?
Un confronto su una situazione reale è il modo più rapido per vedere come modello comune, capacità riusabili e configurazione d'istanza lavorano insieme.
Parliamo di un processo criticoAny system. Any vendor. One way. Always proven.