È necessario progettare una nuova soluzione per un’IT system complesso. Quali azioni intraprendere?
Prima di iniziare a sviluppare un piano d’azione, è essenziale riunire tutte le migliori pratiche dei leader e degli esperti in un diagramma chiaro (anche se parzialmente). Nell’esempio seguente è mostrata una diagramma che spiega che, in ogni caso, deve sempre esserci un fattore che diventa il punto di partenza. Questo primo mattoncino determinerà il formato di tutto il lavoro.
Nel mio approccio allo sviluppo del software, suggerisco di prendere come tale mattoncino il server Gitlab o GitHub e il formato Markdown per la documentazione, che deve essere in un unico luogo e considerata come codice da gestire. Suggerisco di adottarlo e mai modificarlo. Perché la documentazione in qualsiasi progetto è tutto ciò che hai (a cui torneremo ancora di più - è un principio consolidato).
Il problema dell’obsolescenza della documentazione durante lo sviluppo o l’evoluzione del prodotto in questa struttura è minimo. Le principali cause dell’obsolescenza delle informazioni sono:
- la documentazione non viene mai scritta da nessuno
- la documentazione è disseminata e non è possibile raccogliere una versione completa e aggiornata dai pezzi frammentari
Entrambi questi fattori sono mantenuti sotto controllo in questa struttura.
In alcune squadre c’è la possibilità di sviluppare un comunita dove ogni dipendente può contribuire autonomamente alla documentazione.
Tre forze devono procedere in parallelo: l’architetto, lo specialista e il curatore del progetto.
Lo specialista deve eseguire le attività pianificate dall’architetto. Gli specialisti di diversi livelli risolvono autonomamente i problemi. L’architetto definisce il formato per descrivere il progetto. Il curatore del progetto si occupa di ruoli e regole per garantire che il lavoro proceda in modo fluido, prevedibile e, se possibile, confortevole.
Senza una chiara definizione delle zone di responsabilità, sia da parte dello sviluppatore del software che da parte del cliente, il lavoro sarà inefficiente.
Questo topic è un’introduzione al concetto di Gemba, l’approccio giapponese per il monitoraggio dei processi operativi.
Per iniziare un progetto di grandi dimensioni, è necessario partire da una diagramma ad alto livello (ricordo che il mattoncino iniziale git+markdown è stato già posizionato in precedenza). Questa diagramma permette di comunicare a tutti i partecipanti con un linguaggio comune e di eliminare ambiguità e spiegazioni a dito.
A ogni stadio vengono coinvolti i dipendenti di diversi settori e competenze.
Un approccio diffuso tra i clienti è la visualizzazione dell’architettura del software secondo il modello “C4” (si-4: Context, Containers, Components, Code) e le sue varianti.
Le diagrammi a diversi livelli di dettaglio sono progettati in modo diverso, quindi sono comprensibili sia per i tecnici che per i non tecnici.
Nel mio lavoro utilizzo:
High Level Design - è una diagramma con dispositivi di rete e contorni. Include il firewall e i mezzi di protezione. Sulla mappa sono rappresentati i flussi di dati, evidenziando la posizione dei dati sensibili. I componenti sono collegati con linee senza frecce, indicando porte e protocolli.
Da questa diagramma si crea una diagramma di deployment (senza esempio), in cui vengono aggiunti:
- la piattaforma di virtualizzazione
- il nome e le versioni del sistema operativo e del DBMS
- i contenitori e l’orchestratore
- le richieste hardware
- la relazione con il fornitore di hardware
- l’ambiente di deployment
Con questa diagramma è chiaro come la sistema viene deployato e gestito. Come avviene il suo scaling. Come avvengono i lavori di manutenzione e il backup/ripristino.
Infine, viene creata una diagramma dei contenitori, in cui vengono indicati i server (come servizi), i servizi, i microservizi, descritto l’IaaS, le interfacce, i protocolli di comunicazione, i tipi di integrazione, il DBMS, i broker di messaggi, le bus, i gateway, la sincronizzazione e il tipo di interazione (XML, API, file).
(L’ultima diagramma, Diagramma delle classi, è opzionale.)> Descrivendo i componenti di ogni diagramma passo dopo passo, il curatore e l’architetto hanno una comprensione di quali attività emergono e come devono essere distribuite tra i partecipanti. Il diagramma dei passaggi permetterà a ciascun partecipante di vedere in quale punto si trova e qual è il suo prossimo passo.
Scarica il diagramma Mermaid: flow_new_arch.md (2,5 KB)
flowchart TD
classDef pclass fill:#f5f5dc
classDef wclass fill:#f96
classDef pmclass fill:#4f7
classDef yclass fill:#ff9
classDef oclass fill:#ffbf00
classDef gclass fill:#c5e384
a((Inizio)):::gclass --1-->
b(Chiave di soluzione<br><i>nel progetto Gitlab<br>formato Markdown</i>):::wclass -->
q{ } -.2.->
g[Processi] --3-->
h[Regolamenti] --4-->
i[Zone di responsabilità] -.->
p
g -->
s(Scema di interazione tra le persone nel progetto tenendo conto dei tipi di task e della loro sequenza):::pclass
h -->
t(Requisiti da rispettare: codifica, revisione, formattazione, comunicazione, ordine, cultura, compliance):::pclass
i -->
u(Precisione nell'assegnazione e nell'esecuzione delle attività, fluidità nella collaborazione):::pclass
q --5-->
c(HLD-diagramma):::oclass --6-->
d(Diagramma di deploy):::oclass --7-->
e(Diagramma dei container):::oclass --8-->
p(Documentazione online):::yclass -->
j[[Soluzione tecnica]]:::pmclass
c --> k(contorni di rete, distribuzione dei container, MSO e elementi di sicurezza, modalità di connessione al supporto tecnico):::pclass
c --> o(flussi di dati chiave, posizionamento dei dati sensibili secondo il tipo: dati personali, segreti commerciali, ecc.):::pclass
d --> m(requisiti per il tipo di hardware, per l'equipaggiamento, per le prestazioni, legame con il fornitore, virtualizzazione, containerizzazione, orchestrazione, ambiente di deploy):::pclass
e --> n(server come servizio, servizi, IaaS, microservizi, interfacce, protocolli e tipi di integrazione, DBMS, broker, componenti esterni, integrazioni: bus, code, gateway, tipo di connessione sync/async, protocolli di interazione):::pclass
Seguite sempre i blocchi del diagramma. Trovate le corrispondenze e costruite il lavoro in modo che non vi siano lacune. Se è necessario apportare modifiche al processo, fattele gradualmente.