
L’Enterprise Architecture (EA), per sua natura, raccoglie un numero molto ampio di informazioni tra loro strettamente interconnesse. Se in una prima fase embrionale delle iniziative è possibile utilizzare per la modellazione strumenti software di produttività individuale, al crescere del livello di maturità diventa indispensabile adottare strumenti avanzati di Enterprise Architecture Management System (EAMS).
I sistemi di EA coniugano i benefici della modellazione delle architetture mediante diagrammi a quelli di un vero e proprio database, in grado di garantire la consistenza delle informazioni, facilitare il riutilizzo dei componenti architetturali e fornire utili strumenti di analisi e di reporting.
Il passaggio a tali strumenti spesso avviene quando l’EA esce dal perimetro di pochi ispirati Enterprise Architect per diffondersi ad altri gruppi aziendali. L’estensione di tale perimetro accresce l’esigenza di collaborazione e condivisione del lavoro e rende indispensabile una gestione ordinata del ciclo di vita dei modelli architetturali. L’adozione di un EAMS diviene anche occasione per definire delle line guida di modellazione, con lo scopo di aumentare la qualità degli artefatti, da veicolare attraverso i manuali utenti e durante la formazione sull’utilizzo del tool adottato.
Un progetto d’istituzione di un software di EAMS presenta diverse criticità e un errato impianto iniziale può avere conseguenze molto gravi sull’investimento.
Sin dal principio è necessario definire in modo dettagliato l’ambito del progetto, individuare i ruoli da coinvolgere, le interazioni con eventuali altre iniziative contigue già avviate, come ad esempio modellazione dei processi e gestione dei rischi operativi, in modo da prevedere sin da subito le possibili sinergie.
Un ulteriore aspetto riguarda l’integrazione dell’EAMS con altri applicativi aziendali, al fine di scambiare con questi informazioni anagrafiche di cui sono proprietari. Sebbene le sincronizzazioni tra i sistemi e l’EAMS possano portare notevoli vantaggi in termini di riutilizzo e consistenza di dati aziendali, l’esperienza ci insegna come sia sconsigliabile partire da subito con obiettivi ambiziosi. Viceversa è più indicato attendere che le pratiche operative dell’EA siano sufficientemente consolidate.
Gli EAMS non sono del tutto indipendenti dalle metodologie e dai processi, ciascuno ha delle proprie caratteristiche peculiari, ad esempio per quanto riguarda le funzionalità di analisi o di versionamento. La metodologia e i processi di governance dell’EA definiti in precedenza devono essere rivisti, adattati e calati sul sistema selezionato.
Un’attenta software selection dovrebbe considerare molti parametri e prima ancora dell’acquisizione è sempre consigliabile una prova sul campo (Proof of Concept) per verificare la compatibilità dei sistemi con la metodologia adottata, o che si vuole adottare, e con l’organizzazione interna.
Lo sponsor del progetto, pur avendo in genere una forte competenza nell’EA, ha solitamente difficoltà nel guidare le scelte di configurazione non conoscendo in modo approfondito il tool e le possibilità da questo offerto. Un approccio che ha dimostrato dare buoni risultati è quello prototipale, in cui il tool viene progressivamente configurato e popolato con lo scopo di mostrare sin dalle prime fasi progettuali una struttura realistica del repository delle architetture e dei suoi processi gestionali.
La raccolta della documentazione disponibile, che normalmente include processi, organigramma, disegni architetturali, standard e metodologie già applicate, permette di svolgere una prima analisi dei requisiti di parametrizzazione del sistema e di ipotizzare per ciascuno di questi una soluzione. Oltre a sessioni di analisi con i singoli stakeholder, un approccio vantaggioso è quello di organizzare dei workshop con tutte le risorse coinvolte in modo da far emergere le esigenze dei singoli gruppi e arrivare in breve tempo a una soluzione condivisa da tutti.
Nel primo workshop, infatti, vengono selezionati gli elementi da utilizzare: viste, oggetti, associazioni e proprietà e viene definito il loro livello di dettaglio. Nella stessa sede sono definiti i bisogni di reportistica (es. Impact Analysis, Software Life Cycle, ecc...) anche con lo scopo di verificarne la compatibilità con il meta-modello in definizione.
Oltre a sessioni di analisi con i singoli stakeholder, un approccio vantaggioso è quello di organizzare dei workshop con tutte le risorse coinvolte in modo da far emergere le esigenze dei singoli gruppi e arrivare in breve tempo a una soluzione condivisa da tutti.
A seguito del primo workshop in genere è possibile iniziare a configurare il linguaggio e a disegnare sia le viste di alto livello e sia delle viste esemplificative di livello inferiore. In un secondo workshop con i referenti l’obiettivo è quello di verificare il recepimento dei requisiti e validare la soluzione individuata presentando una demo del repository e dei processi gestionali.
Successivamente alla validazione è possibile importare i dati anagrafici, come l’organizzazione, i processi e gli altri elementi architetturali.
Nel caso in cui siano presenti in azienda eventuali modelli in altri formati (Visio, Archi, ecc...), sarà possibile procedere a un loro recupero automatico. Ovviamente questo nel solo caso in cui le regole di modellazione siano state definite in precedenza in modo chiaro e che tali regole siano compatibili con il metodo impostato nel nuovo tool. In caso contrario è consigliabile procedere a un loro nuovo disegno.
Il repository così fatto diviene la baselane 0.1 delle architetture pronto per il successivo popolamento da parte degli Enterprise e Solution Architect. Al fine di garantire un corretto utilizzo del tool è indispensabile organizzare delle sessioni di formazione e successivamente di training on the job. La formazione per essere efficace e portare i risultati sperati, deve combinare la conoscenza dell’utilizzo del sistema con nozioni sulla metodologia selezionata.