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 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.

L’approccio DocFlow

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.

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.