La divulgazione e l’utilizzo della metodologia Agile sta dimostrando da alcuni anni di saper creare notevole valore per il Cliente. Abbattuti i tempi della sequenza analisi-sviluppo in favore del metodo analisi+sviluppo, i Clienti sono in grado di visionare le soluzioni in corso di sviluppo, avendo il tempo di riconoscere in esse i requisiti dichiarati e familiarizzare con le interfacce sempre più sofisticate. Passando dallo sviluppo applicativo ad ambiti più articolati, la metodologia Agile applicata a progetti più di stampo organizzativo, può provocare momenti di imbarazzo laddove l’Enterprise Architect non riesca a cogliere tutti gli elementi necessari al buon esito del progetto.
Molti sono gli elementi che l’Enterprise Architect deve tenere a mente in sede di analisi, proposizione e validazione del suo disegno architetturale:
- Processi in ambito e di contorno
- I dati coinvolti nel suo disegno
- Le Risorse Umane e il contesto di inquadramento
- Le modalità con le quali l’Azienda ha implementato i Processi
- La generazione del valore
- La ricaduta sulle attese del Cliente
- La normativa cogente e le sanzioni previste
- La logistica e l’ambiente
- Il ciclo di vita del parco applicativo
… e molto altro. Ora è più che evidente che di fronte ad una tale mole di informazioni, il metodo Agile non riesce ad onorare i propri fondamentali ed il Progetto diventa, appunto, FRAGILE (!).
Quindi, come approcciare ad un problema dove i requisiti metodologici non si allineano perfettamente con le difficoltà di reperire tutte le informazioni ?
Cerchiamo di analizzare il contesto.
Le informazioni necessarie ad un progetto sono spesso cross-funzionali, ovvero sono detenute da diverse Funzioni Aziendali e quindi seguono una logica più di processo.
Inoltre si presentano sotto varie forme, dal dato acquisito a quello elaborato, in forma analitica o in forma sintetica, dal requisito tecnico a quello funzionale, da quello normativo a quello politico, e così via.
Se lo scenario è questo, è evidente che l’Enterprise Architect ha la necessità di disporre del maggior numero di informazioni per essere Agile nello sviluppo della sua soluzione. Ma non tutte le informazioni possono essere raccolte al momento del progetto e non tutte possono essere disposte da lui. Di qui, la necessità di disporre di un repository condiviso e manutenuto nel tempo.
Hopex consente tutto questo. Ovvero permette agli EA di disporre di un Repository ad accesso olistico, condiviso con le altre funzioni aziendali ed in base al quale disegnare, proporre, verificare e certificare la soluzione disegnata come pure le sue singole componenti.
Inoltre Hopex consente anche di assegnare un ciclo di vita alla soluzione da distribuire o distribuita, verificandone periodicamente una serie di requisiti che verifichino l’aderenza della soluzione ai desiderata dell’Azienda, e tale modalità può riferirsi ad aspetti organizzativi (processi, strutture, regole) come a quelli applicativi (sistemi, API, applicazioni e sue componenti).
Nella nostra esperienza ventennale di disegno di soluzioni funzionali, organizzative ed applicative mediante Hopex, possiamo affermare che costi e tempi di progetto sono stati ridotti di almeno la metà. Ed inoltre il valore di quanto svolto dal Team di Progetto è divenuto facilmente patrimonio aziendale in quanto custodito nel Repository di Hopex, pronto a successivi utilizzi ed analisi.
