Enterprise and Application Architecture: le practice di Gartner

Nell’economia industriale digitale, le organizzazioni si trovano faccia a faccia con sfide e opportunità senza precedenti e guardano alle architetture enterprise come guida e supporto alla trasformazione di business. Affinché ciò avvenga concretamente, però, le architetture devono essere ripensate tenendo conto delle nuove tecnologie ma anche di processi, policy, persone, skill, practice… Da Gartner, ecco alcuni utili suggerimenti

Pubblicato il 24 Set 2014

Architetture enterprise, applicazioni e soluzioni tecnologiche devono necessariamente integrarsi per poter rispondere con efficacia alle sfide di business odierne. È questo il primo ‘must’ con cui Gartner invita i professionisti Ict a riflettere sull’importanza e la valenza delle architetture enterprise e applicative nelle proprie aziende. Cloud deployment, interfacce mobile e analytics avanzati stanno cambiando il modo in cui sono strutturale le applicazioni. Gli application manager devono garantire che le architetture applicative siano efficaci nel migliorare determinati aspetti quali versatilità, usabilità, mantenibilità e robustezza e, al tempo stesso, che rispondano alle esigenze e alle aspettative degli utenti. Gartner sottolinea infatti come l’Enterprise Application Architecture (Eaa) sia oggi una disciplina critica nell’ambito dell’application development e identifica quindi una serie di ‘practice’ utili per i professionisti del settore affinché tale disciplina sia di reale efficacia rispetto alle esigenze e agli obiettivi aziendali.

Integrazione, fattore critico di business

I responsabili delle application leader devono ‘posizionare’ correttamente le architetture applicative all’interno della propria azienda al fine di assicurare allineamento tra le strategie di business e i progetti It che coinvolgono le applicazioni. Gli architetti, di fatto, ricorrono a diversi paradigmi tecnologici quali Soa (Service Oriented Architecture), Rest (Representational State Transfer), Eda (Event-driven Architecture) nel disegnare e modellare un’applicazione cercando di massimizzarne determinate caratteristiche (usabilità, robustezza, versatilità, ecc.).

Figura 1: Scopi e focus nella definizione delle architetture applicative. Fonte: Gartner 2013

Nella visione di Gartner è sicuramente importante adottare specifici framework metodologici ma, rispetto alle odierne dinamiche di business e al determinante valore delle applicazioni software su di esse, ciò non risulta più sufficiente. “I risultati di business dipendono strettamente dalle applicazioni (quindi dalle architetture applicative); non esistono più progetti It, ma progetti di business guidati e supportati dalla tecnologia”, scrive in un report dedicato all’Eaa Cathleen Blanton, Vice President di Gartner Research. “Per affrontare correttamente la disciplina dell’Eaa, diventa fondamentale seguire best practice e framework di riferimento. Il primo step riguarda l’integrazione, intesa anche come punti di vista tra ‘passato’ e ‘futuro’ (di business, di approcci e progetti realizzati e realizzabili), guardando per esempio ai successi raccolti, identificando modelli comparabili, creando risorse condivise, incorporando prospettive esterne, gestendo interazioni cross-dominio”.

Gartner, in proposito offre alcuni suggerimenti utili con i quali invita i professionisti It coinvolti nello sviluppo applicativo e architetturale non solo a collaborare attivamente tra loro, ma anche con colleghi di altre discipline solo apparentemente ‘distanti’ quali Bpm (Business Process Management), Eim (Enterprise Information Management), Ppm (Program and Portfolio Management), Hcm (Human Change Management)…

Figura 2: Le aree di sovrapposizione nelle architetture applicative. Fonte: Gartner 2013

Rispetto a ciò, la società di analisi americana propone di “misurarsi” sulla base del quadrante di figura 1 per determinare ‘scopi’ e ‘focus’, distinti rispettivamente tra ‘local-enterprise’ e ‘tactic-strategic’, e dal quale ricavare, in base alla propria specifica realtà aziendale, il giusto mix tra Ea (Enterprise Architecture), Aa (Application Architecture), Sa (Solution Architecture) e le eventuali aree di sovrapposizione/collaborazione (figura 2), sempre ricordando di affrontare i progetti condividendoli con le altre discipline citate.

Ea+Aa+Sa: le best practice dell’Eaa

Ricordando come approcci e discipline complesse come quelle dell’Eaa debbano necessariamente tenere conto di processi e persone, che come sempre hanno un ruolo specifico determinante insieme al fattore tecnologico, Cathleen Blanton chiude la sua analisi con un elenco di suggerimenti da tenere in considerazione:

Figura 3: I peggiori errori da evitare nella definizione dell'Enterprise Architecture. Fonte: Gartner 2013

1) l’Eaa deve essere ancorato alla strategia di business e guidato da una capacità di visione futura, utilizzando per esempio un modello di ‘Business Outcome Statement’ (dal quale ricavare obiettivi, step procedurali, pianificazione e controllo, azioni attuative, ecc.);

2) i cambiamenti di business e tecnologici devono essere guidati e supportati in parallelo;

3) orientare i risultati (rendendoli misurabili, raggiungibili, comparabili);

4) affrontare i cambiamenti in modo incrementale, evolutivo, pragmatico;

5) stabilire un rapporto inclusivo e collaborativo tra business e It;

6) identificare gli scopi aziendali tenendo conto di persone, processi, informazioni e tecnologia;

7) supportare e ‘ingaggiare’ tutti gli stakeholder;

8) misurare il valore dei risultati in termini sia qualitativi sia quantitativi.

Figura 4: Buone pratiche ed errori da evitare nella definizione dell'Application Architecture. Fonte: Gartner, 2013

Questi suggerimenti, in genere, valgono oggi un po’ per tutti i progetti Ict il cui impatto e valore è in strettissima relazione con i risultati, le esigenze e gli obiettivi di business. Così, l’analista americana aggiunge ai consueti suggerimenti che la società di ricerca generalmente propone ai professionisti Ict rispetto a una determinata tematica, alcuni interessanti ‘worst’, ossia i peggiori errori da evitare (figura 3 e figura 4), quali per esempio “confondere l’It Architecture con l’Enterprise Architecture”, “non misurare le performance”, “acquistare tool prima di aver compreso le esigenze di business” o “prevedere nei team Ea solo risorse It”.

Valuta la qualità di questo articolo

La tua opinione è importante per noi!

Articoli correlati

Articolo 1 di 4