È ormai folta la schiera dei vendor che offrono servizi di piattaforma tecnologica e/o di It governance in ambiente Service Oriented Architecture. Diciamo meglio in ambiente ibrido, dato che le applicazioni business a silos continueranno per un pezzo a coesistere con quelle costruite da un pool di componenti. Facciamo il punto con Forrester, che considera la Soa solo un elemento – sia pure cardine – di un quadro più vasto, la digitalizzazione del business. Diego LoGiudice (nella foto in alto), principal consultant Emea (e consulting director in Italia) della società di ricerca, professionalmente un “addetto ai lavori” di lungo corso nello sviluppo applicativo e nell’It Management, delinea senso e valore della composizione dei servizi al business basati sulla Soa, e della It Governance in un contesto Soa (ormai nota come Soa governance tout court).
ZeroUno: Come inquadrate il trend in atto in cui, magari in ordine sparso, i clienti vanno oltre lo sviluppo dipartimentale, diciamo verso un governo del cambiamento aziendale?
LoGiudice: Il trend è la “digitalizzazione del business”. Ma andiamo per gradi. Il prerequisito per le aziende su questa strada è l’ingegnerizzazione del software di classe enterprise per modelli (model driven), in cui nel ciclo di vita applicativo si modella a un livello di dettaglio sufficiente per consentire, in un sistema o in un’applicazione target, o l’interpretazione diretta del modello – grafica (Uml), visuale (Gui) o testuale (Xml) non importa – o la generazione automatica dell’eseguibile. Un esempio semplificato di auto generazione è la configurazione con i Wizard, cui Microsoft ci ha abituato: come un Wizard automatizza la configurazione di un sistema, così si può automatizzare anche la generazione di codice, almeno in percentuale economicamente significativa.
ZeroUno: Componentizzare le applicazioni produrrà nuova efficienza e flessibilità aziendale?
LoGiudice: La corsa alla Soa è una tappa cruciale ma di per sé insufficiente per arrivare all’agilità promessa, che viene da una completa digitalizzazione del business. La visione di Forrester è che per digitalizzare il business serve una Digital Business Architecture (Dba), di cui la Soa è solo un primo dominio, quello in cui si sviluppano e si implementano i servizi al business: software organizzato organicamente in micro-servizi, tipicamente ma non esclusivamente servizi web, composti e condivisi in combinazioni che formano i vari macro-servizi al business (vedi figura 1).
Figura 1 – La Digital Business Architecture, la base infrastrutturale per l’agilità delle imprese
Per visualizzarla correttamente cliccare sull’immagine
Ma il Cio deve guardare anche ad aspetti di integrazione dei dati, di coordinamento dei processi, di interazione unificata con l’utenza, che nel quadro del business digitalizzato, costituiscono altrettanti domini a se stanti. In altri termini, la Dba si articola in altri quattro domini: integrazione e trasformazione, per aggregare i dati, con strumenti del tipo Extract, Transform, Load (Etl); orchestrazione (il Bpm), per la composizione dei processi con uno specifico linguaggio (Bpel), e il loro coordinamento; interazione, per rendere visibili i servizi al business attraverso interfacce utente strutturate con strumenti e linguaggi ad hoc, abilitanti la ricchezza funzionale appropriata alla figura utente e al canale usato. Il quinto dominio, centrale a tutti gli altri, Soa compresa, è la gestione dei metadati: una rappresentazione standard comune dei “dati” generati nei vari domini, in modo che i vari ambienti possano interoperare capendo il dato nel contesto (di business o di infrastruttura) e risolvendo problemi di tracciabilità (per esempio un componente Soa in produzione occorre sia tracciabile, sia dal servizio business che lo usa, che dall’hardware che lo supporta).
ZeroUno: Quali effetti ha lo sviluppo basato sulla Soa per sviluppatore e utente business?
LoGiudice: La differenziazione degli skill di sviluppo. La molteplicità di domini è un moltiplicatore di specializzazioni. Servono maggior disciplina organizzativa e una più variegata tipologia di skill: sviluppo interfacce, servizi business, infrastruttura tecnologica, implementazione. Cambiano le modalità di test, diventa centrale verificare interoperabilità e integrazione. Un secondo effetto è la comparsa di due livelli di sviluppatori: l’analista di business, specializzato in un linguaggio di dominio del business, che in molte aziende già lavora a contatto con l’utente per definire i processi business e identificarne le metriche, e lo specialista che resta “vicino alla macchina” in uno dei diversi domini tecnologici con il relativo linguaggio specifico, Java o C# che sia. L’analista diventa un architetto di business che usa strumenti basati su notazioni standard Omg, per produrre sottoprocessi pregenerati, poi dati in pasto all’It.
ZeroUno: Cosa caratterizza la Soa Governance rispetto alla classica It Governance?
LoGiudice: Di nuovo, più che di Soa è corretto parlare di effetto Dba sulla It Governance, che è impattata dall’insieme dei domini tecnologici Dba, non dal solo sviluppo dei servizi al business. L’impatto non rivoluziona i processi della It Governance, ma la gestione dei suoi contenuti, che da una tipologia di oggetti da gestire (management), diventa una popolazione disparata di progetti, componenti e asset da governare sul ciclo di vita (governance). Ogni processo ha così una sua governance (vedi figura 2).
Figura 2 – La Soa governance impatta sui contenuti dei processi dell’It governance
Per visualizzarla correttamente cliccare sull’immagine
Il Project Portfolio Management diventa (Asset) Portfolio Governance: oltre ai progetti che in pianificazione rispondono al Requirement Management, contiene oggetti che vanno dalle componenti Soa agli elementi infrastrutturali; lo status degli oggetti si aggiorna a fronte di quanto succede (se per esempio ritiro un componente devo capire quali servizi sono impattati e aggiornare il Portafoglio). È la condivisione di componenti Soa in servizi business diversi, con un maggior livello di rischio inerente (sconosciuta nel mondo delle applicazioni a silos), che impone di rifocalizzare il portafoglio sull’intero ciclo di vita degli oggetti. Nella Technology Governance nasce l’esigenza di introdurre una pianificazione strategica (Strategic Soa platform planning), con un team dedicato. Rispetto allo sviluppo dipartimentale, ci sono molti più elementi da mettere a fattor comune, e la piattaforma è influenzata dalla strategia di ingaggio (parto su un pilota o su un progetto mission critical o magari il primo apre la strada al secondo?). Può darsi che per le esigenze di ingaggio Soa non serva subito un repository di metadati, ma un contingency plan di un anno. Cruciale nella Project governance è il Service Interface Design, cioè il disegno delle interfacce da esporre per i servizi al business, visti dall’utente: è in riferimento a queste interfacce che si va poi a sviluppare la tassonomia di microservizi che serve. Infine, la Service level governance, il governo nel tempo delle operazioni riferito a un livello di soddisfazione negoziato con il business, richiede interventi sulle componenti Soa. Tutte le discipline di It governance sono coinvolte.
ZeroUno: Ma un’organizzazione It può avere già operativa una It Governance…
LoGiudice: Vorrà dire che sta un passo avanti a chi non l’ha: dovrà affrontare una Soa Governance come “migrazione” dalla sua It Governance “legacy”. E non solo per la Governance, ma in generale, lo sforzo di ingaggio con una Soa dipende da dove si sta tecnologicamente, e a monte ancora dalla cultura aziendale.
ZeroUno: La strategia dell’utente con la Soa dipende dal punto di partenza?
LoGiudice: Certo. L’utente può essere a zero, o aver già investito sulla Soa senza saperlo, con componentistica Soa presente nell’Erp scelto. La prima cosa è farsi un bel self assessment: preparare questionari e interviste conoscitive sui metodi di sviluppo che si hanno in casa e sulla cultura Governance già instaurata. Qualunque percorso verso la Soa dovrà prendere le mosse dalla configurazione di partenza.
ZeroUno: E per il dualismo buy–build: cosa cambia con la Soa?
LoGiudice: I clienti conservatori continueranno il buy in modo legacy (continueranno a non sfruttare la Soa nel middleware dell’Erp scelto). Tipicamente si inizia da un build con isole Soa, circondato da un ambiente che resta buy. Due fattori aiutano: uno sviluppo model driven resta il più possibile indipendente dalle piattaforme specifiche; e il lavoro di orchestrazione con Bpm ha un buon livello di indipendenza da scelte conservatrici o avanzate sui processi sottostanti, o se stanno in un Oracle piuttosto che in un Sap.
ZeroUno: C’è un’economia di ingaggio con la Soa?
LoGiudice: Assolutamente si. All’insegna del pragmatismo: se il vecchio sistema funziona e performa, non ha senso migrarlo alla Soa. Nessuno mette lì 10 milioni di euro per rifare tutto in chiave Soa. Ma pragmatismo non vuol dire inerzia: c’è la consapevolezza che gli strumenti sono maturi. Avranno successo investimenti Soa coesistenti col vecchio mondo tutte le volte che c’è un’opportunità di business che finanzia il business case. Servirà calibrare un minimo iniziale con l’occhio ad arricchimenti rinviati a progetti successivi. Gioca anche la fortuna: per esempio se nuove regolamentazioni (compliance) o deregolamentazioni (telecom, energetici) impongono logiche di investimento aggressive.
