La necessità di avere una figura che possa essere da raccordo delle diverse iniziative IT da un punto di vista architetturale è già abbondantemente evidente e discussa in Disciplined Agile Delivery, tanto da introdurre il ruolo dell’Architecture Owner e il concetto di enterprise awareness (ovvero una consapevolezza architetturale a livello aziendale).

Anche qui è doverosa una nota: in generale con Enterprise Architecture si intende l’organizzazione aziendale nel suo complesso vista nei processi, ruoli, strutture, ecc.. DA2, invece, ne limita il perimetro all’ambito IT, esattamente come per il Portfolio, approccio si rileva decisamente efficace nel percorso di adozione di Disciplined DevOps, rafforzandolo con una serie di strategie a supporto:

• Reuse mindset, si tratta di promuovere e stimolare il riuso dei diversi assett, dai sevizi, ai componenti ai framework, in modo da creare una architettura solida e riutilizzabile che possa essere riutilizzabile nel tempo. Il “come” i vari assett vengano riutilizzati è oggetto di governance da parte dell’azione del process blade di Reuse Engineering;
• Technical-debt mindset, si tratta di avere ben chiaro il concetto di “debito tecnico” che, per quanto possa essere ridotto al minimo, è comunque sempre presente nei propri prodotti. Esistono diverse strategie per “pagare” il debito tecnico, a partire dall’utilizzo delle pratiche atte a promuovere la qualità del codice, fino a quelle che prevedono liberamente di tollerare un certo “debito” per raggiungere determinati obiettivi temporali. In ogni caso è necessario sempre puntare alla sua riduzione costante, onde evitare di raggiungere il punto di massa critica e non poter più attuare alcuna azione di miglioramento;
• Development guidelines, l’obiettivo è quello di definire le “linee guida” (development of guidelines) di riferimento per le attività di tutti i team. Standard di Codifica e Gestione della Sicurezza sono due esempi evidenti di cosa ciò voglia dire e di come la loro condivisione e standardizzazione sia di ausilio anche al delivery e quindi all’ottica DevOps. Resta da evidenziare la necessità di far evolvere costantemente le diverse linee guida per evitare che la loro adozione si trasformi in un vincolo per la crescita e l’evoluzione dei team;
• Technical roadmaps, è necessario creare un piano per lo sviluppo e l’evoluzione degli aspetti tecnici. Ciò incide praticamente su tutti i livelli aziendali e diventa abilitante per sfruttare nuovi approcci e soluzioni tecnologiche che migliorano i diversi aspetti, dallo sviluppo al continuous delivery. Il punto di partenza è la big picture attuale da cui partire per ipotizzare una serie specifica di evoluzioni che porteranno alle opportune trasformazioni. In particolare è fondamentale analizzare gli aspetti relativi all’Infrastruttura IT nel suo insieme (network, servizi, server, middleware, data source, ecc) e decidere dove posizionarsi nell’IT Infrastructure Strategies Quadrant.

IT Infrastructure strategies Quadrant

<

p style=”margin: 6pt 0cm 0.0001pt 30px; line-height: 150%;”>Come è ben visibile dalla figura, due sono le dimensioni di rilievo: Ownership, che evidenzia il livello di outsourcing dell’infrastruttura, e Virtualization, che ne sottende la specializzazione.