#BIMpill – I vincoli dell’ambiente

Lavorando su un modello informativo, nel senso più ampio del termine, gli strumenti e le piattaforme di produzione e coordinamento ci impongono una serie di vincoli e, come direbbe Morpheus, alcuni di questi vincoli possono essere sfruttati a nostro vantaggio mentre altri possono essere infranti.

Eliyahu Goldratt, nel suo Beyond the Goal, individua cinque passi per la gestione di questi vincoli:

1. Identificare i vincoli del sistema (es: nella gerarchia informativa del modello, una certa categoria di oggetti presenta una condizione di hosting rispetto ad un’altra categoria);
2. Decidere come sfruttare i vincoli del sistema: come mai il sistema presenta questi vincoli? I vincoli ad esempio allineati ai processi progettuali o costruttivi? Questi vincoli ci aiutano a essere maggiormente precisi / accurati / coordinati?
3. Subordinare qualunque decisione alle considerazioni emerse dal punto precedente;
4. Elevare i vincoli del sistema a vincoli di processo;
5. Se si decide di infrangere il vincolo, tornare al punto 1 senza lasciare che sia l’inerzia a provocare un vincolo nel sistema.

Nel nostro caso, si tratta di impedire che vincoli apparenti (il software normalmente funziona così) si trasformino in vincoli di processo (non si può fare).

I vincoli tipici individuati da Gene Kim nei suoi principi di DevOps, che ci stanno accompagnando da qualche mercoledì a questa parte, sono quattro:

1. Vincoli nella creazione dell’ambiente di sviluppo: gli ambienti di produzione o di test devono essere autonomi, in modo da essere a libera disposizione di chiunque in qualunque momento ne abbia bisogno;
   nel nostro caso: chiunque deve avere a disposizione modelli di esempio, script di test, e bisogna creare nel team la cultura di testare nuove componenti in un ambiente neutro, prima di mandarle in produzione.
2. Vincoli nel rilascio: le consegne devono essere il più possibile automatiche;
   nel nostro caso: è necessario evitare a tutti i costi situazioni in cui, prima della consegna e della condivisione, viene richiesto di effettuare operazioni manuali e ridondanti come l’eliminazione di oggetti segnaposto.
3. Vincoli nelle fasi di test: le procedure di test dovrebbero essere automatizzate il più possibile in modo da garantire rilasci in sicurezza e facendo sì che le operazioni di test non rimangano indietro rispetto alle operazioni di sviluppo;
   nel nostro caso: le eventuali procedure di controllo del modello dovrebbero essere automatizzate il più possibile, senza rimanere subordinati ad eventuali enti terzi incaricati di questo controllo.
4. Vincoli in architetture di sistema troppo restrittive: l’architettura dovrebbe essere flessibile in modo da consentire ai responsabili dei diversi moduli di effettuare modifiche in sicurezza e autonomia.
   nel nostro caso: discipline diverse hanno esigenze diverse (ad esempio nel breakdown dei modelli o nella strategia di gestione degli oggetti ospitanti) ed è necessario costruire standard che consentano a ciascuno di lavorare in modo ottimale.