Tag Archive

Caffè con BEA si rinnova, e con lo stile ‘innovativo’ che ci contraddistingue. Nuovo layout, nuovi RSS, una sezione dedicata a La voce dalle aziende, la sezione Editoriale di Marco Bucci, una serie di feed da altri blog che riteniamo interessanti per il nostro mercato, i link ai nostri social network come Facebook, LinkedIn e tanto altro ancora.

Venite a trovarci su www.caffeconbea.it!

Firmato Booz Allen Hamilton è il recente survey “Quanto è efficace la tua organizzazione IT”, indirizzato a CIO, manager dell’IT e non. Il survey è ancora aperto (se volete compilarlo lo trovate qui, sono 24 domande) ma l’articolo odierno su CWI fa emergere già interessanti dati. Certo il tema del connubio tra Business e IT, più volte ripreso da BEA, è sempre più scottante: da un lato un IT troppo spesso ingessato da architetture e soluzioni ‘rigide’ e silos verticali, e dall’altro modelli di Business sempre più reattivi, veloci ed aggressivi. E con la figura del CIO o dell’IT manager a gestire il difficile compito di allineare il proprio IT alle incalzanti richieste del Business. BEA risponde con numerose soluzioni volte a ridurre il gap IT-Business, e le raccoglie sotto un unico messaggio dal chiaro ed evocativo nome “Liquid Enterprise”: provate a fare un giro sul sito per scoprire qualcosa in più sulla Business Agility.

Sviluppato come guida per il governo del Regno Unito, l’Information Technology Infrastructure Library (ITIL) è uno standard nato alla fine degli anni ’80 con lo scopo di offrire una serie di “best practice” per la gestione dei servizi IT, promuovendo un approccio di qualità al fine di ottenere maggiore efficacia nel lavoro e sempre più efficienza nell’utilizzo dei sistemi informativi.

Il crescente affermarsi sul campo di questo standard dipende dal riconoscimento e dall’adesione da parte di quelle organizzazioni che, in modo sempre maggiore, sono dipendenti dall’Information Technology, e che sono decise a soddisfare i loro scopi e le loro necessità di affari.
Questa dipendenza conduce alle necessità di servizi di qualità dell’IT sempre maggiori, qualità per la quale lo standard ITIL fornisce una serie di indicazioni da seguire.
Esso, infatti, descrive i processi, le attività, i ruoli e le responsabilità per poter gestire in modo flessibile l’organizzazione e i problemi che possono sorgere, al fine di migliorare la qualità dei servizi forniti e di rispondere alle esigenze del mercato, dei clienti e degli acquirenti. ITIL è supportato da uno schema di qualifica completo, da organizzazioni accreditate di training, e da strumenti di implementazione e di valutazione.
Questo insieme di “best practice”, in sostanza, non si presenta come una serie di rigide regole, ma più semplicemente come una traccia da adattare caso per caso a seconda delle necessità, dei bisogni, delle particolarità e delle caratteristiche dell’azienda. Lo standard può essere utilizzato:

• nel settore pubblico - Governo centrale e locale, Autorità sanitarie e politiche
• nel settore privato - Banche, Assicurazioni, Telecomunicazioni, Servizi Pubblici, Trasporti
• dalle società IT - Fornitori di prodotti, Società di System Integration, Società di Outsourcing

La documentazione ITIL è suddivisa in più libri, che trattano ognuno un aspetto diverso della gestione dei servizi IT; sono tutti leggibili in modo indipendente, ma ovviamente presentano sempre concetti strettamente correlati tra di loro. I libri di cui la documentazione è composta sono i seguenti:

SERVICE SUPPORT :
assicura che il Customer abbia accesso ad appropriati servizi per il supporto di funzioni di business. I processi descritti sono: il Service Desk, l’Incident Management, il Problem Management, il Configuration Management, il Change Management e il Release Management.
SERVICE DELIVERY :
questa sezione riguarda il rilascio del servizio richiesto per permettere un supporto adeguato ai clienti. Vengono trattati i processi del Capacity Management, del Financial Management per i Servizi dell’IT, dell’Availability Management, del Service Level Management e dell’IT Service Continuity  Management.
PIANIFICAZIONE PER IMPLEMENTARE IL SERVICE MANAGEMENT :
questa parte introduce all’utilizzo dell’ITIL in quanto fornisce una guida sull’allineamento dei bisogni di business all’IT e sulla valutazione dei livelli correnti di maturità del Service Management. Aiuta l’organizzazione ad identificare i punti di forza e di debolezza, permettendo di sviluppare i primi e di superare gli ultimi.
ICT INFRASTRUCTURE MANAGEMENT :
si occupa dei processi, dell’organizzazione e degli strumenti necessari per fornire un’infrastruttura stabile di IT e comunicazioni ed è la base per i processi di ITIL Service Management. Questa parte si occupa di Design & Planning, Operations e Technical Support.
APPLICATION MANAGEMENT :
fornisce un aiuto agli utenti, agli sviluppatori e ai manager del servizio per identificare quali applicazioni possono esser gestite da una prospettiva di service management.
SECURITY MANAGEMENT :
questa sezione si occupa della sicurezza dal punto di vista del fornitore del servizio, identificando come il Security Management si relaziona con l’IT Security Officer e come fornisce il livello di sicurezza necessario.
THE BUSINESS PERSPECTIVE :
si occupa di far comprendere ai manager il carico di business. Le questioni trattate includono il Business Relationship Management, il Partnership and Outsourcing, dei continui miglioramenti e sfruttamenti dell’informazione, Communication and Technology (ICT) per trarre vantaggio dal business.

La figura seguente mostra i processi che fanno parte dell’area “Service Support”

Ogni processo ITIL è a se stante nella sua definizione, ma per svolgere pienamente il suo scopo deve essere preso in considerazione con tutti gli altri.BEA Systems ha adeguato la propria struttura di supporto per essere in linea con le Best Practices ITIL, con particolare riferimento al Service Support, e inoltre richiede che i Support Account Manager che hanno la responsabilità dei Clienti di tipo Mission Critical siano certificati ai maggiori livelli ITIL. Come a dire: “al vostro servizio” con le nostre “migliori risorse”.
Per informarsi o saperne di più www.itsmf.it

Chiara Scarafiotti, ITIL Practitioner Support & Restore

Una caratteristica utile di Weblogic Server, dalla versione 9 in poi, è il cosiddetto production redeployment: una strategia di deployment delle applicazioni web che consente la coesistenza di due versioni dell’applicazione, garantendo il rilascio di una nuova release senza interrompere il servizio offerto agli utenti. E’ utile per la correzione di bug o per l’aggiunta di nuove funzionalità, senza dover chiudere l’applicazione nè aggiungere server ridondanti per redirigere il traffico durante la sostituzione.

Quando la nuova versione viene attivata, la vecchia viene mantenuta in funzione dal server finchè le sessioni utente già attive vengono completate oppure vanno in time out: nel frattempo la nuova versione comincia a servire tutte le nuove richieste. La figura seguente mostra come le richieste http vengono gestite da WLS:

Gli utenti che stavano navigando non subiscono alcun effetto dell’attivazione della nuova versione, quindi non è necessario pianificare finestre temporali di rilascio, magari di notte o nel week end come a volte si è costretti a fare. Versioni successive delle applicazioni possono essere storicizzate sui server, per cui è sempre possibile tornare indietro ad una versione precedente con la stessa modalità trasparente agli utenti. Inoltre, se una nuova versione viene attivata in Administration Mode, questa diviene visibile solo sul canale di amministrazione di WLS: ciò consente di eseguire test di corretto funzionamento prima dell’apertura al normale traffico utente.

Le operazioni di deployment e di attivazione delle versioni possono, come tutte le operazioni di amministrazione, essere eseguite attraverso la console web di WLS, attraverso script ANT o WLST, programmi java o strumenti esterni di configuration management. Alcuni tipi di applicazione non possono essere gestiti con questa modalità di rilascio, che è limitata a web applications e enterprise applications: vedere la documentazione online di WLS per i dettagli.

Un bel post apparso sul blog Manageability, descrive i 5 prossimi trend per sviluppatori Java, Lo trovate qui.

In anteprima un nuovo whitepaper scritto a 4 mani con gli amici di VMWare: vengono analizzati i trend di adozione di SOA e Virtualizzazione, e vengono analizzate situazioni in cui una tecnologia sfrutta l’altra o ne abilita migliori risultati. Un bel documento di valore per CIO, IT manager ed architetti enterprise. Scarica il whitepaper

Cosa può spingere Microsoft ad offrire la cifra record di 44,6 miliardi di dollari per acquistare il controllo di Yahoo ? Lo storico motore di ricerca è da qualche tempo in crisi eppure risulta ancora una delle priorità di Microsoft. Certo, la prima risposta è Google e il suo strapotere, ma se analizziamo a fondo la vicenda scopriamo che la vera risposta all’Opa di Microsoft è la pubblicità online.

Mentre Microsoft ha cercato di sviluppare – senza successo - un motore di ricerca alternativo e servizi online competitivi, Google è passato nel 2007 dal 60 al 75 per cento del mercato americano della pubblicità nei motori di ricerca, contro il 9% di Yahoo! (la stima è di eMarketer). Quindi, tanto vale per Microsoft mettere sul banco 44,6 miliardi di dollari per non esserne tagliato fuori dalla pubblicità che è la moneta delle attività gratuite in rete. Google ha capito questo da tempo ed ha vinto una “sfida impossibile”: crescere in Internet, oltre il motore di ricerca, con una quantità di servizi gratuiti.

Microsoft è ancora leader nell’off-line – sono suoi 9 computer su 10 al mondo – ma non è mai entrata in partita nell’online, a differenza – ad esempio – della rivale Apple. Basterà un investimento di 44,6 milardi di dollari (pari agli utili dei prossimi 3 anni) per ribaltare un trend strutturale? E’ questa la sfida più impegnativa per il Ceo di Microsoft, Steve Ballmer, dopo l’uscita del fondatore Bill Gates. In palio c’è la leadership del settore per i prossimi anni.

Sono appena tornato da un viaggio di lavoro in un paese arabo, dove ho tenuto un SOA Discovery Workshop. E’ stata un’esperienza che mi ha fatto riflettere sui vantaggi - che non sempre ho tenuto presenti - derivanti dal fatto di lavorare per una multinazionale dell’informatica.

Non mi riferisco ai vantaggi ovvii, come essere costantemente proiettati sulla frontiera della tecnologia e delle nuove tendenze nel campo dell’IT oppure essere a contatto con le diverse realtà costituite da clienti che sono sempre grandi aziende, contenenti a loro volta una varietà di culture, di tecnologie e di personaggi. Negli otto anni che ho passato finora in BEA mi sono trovato davanti a molte sfide professionali e umane. Molte volte sono andato oltre quello che ritenevo il limite delle mie conoscenze e delle mie capacità, spesso ottenendo risultati che mi hanno fatto crescere in esperienza e consapevolezza. Dopo i primi anni in cui ero molto focalizzato sulla tecnologia, ultimamente sono stato affascinato dai rapporti tra le persone: ho studiato con attenzione la capacità di comunicare, i rapporti di forza, l’abilità diplomatica, il rispetto per le posizioni differenti dalla propria, l’efficacia nel convincere gli altri. Ho incontrato tante persone da prendere come esempio e altri che erano la dimostrazione vivente degli errori nella comunicazione. Io stesso a volte ho sbagliato approccio di fronte a opinioni discordanti.

Certe volte le persone, pur di affermare il proprio punto di vista su quello degli altri, sprecano ottime occasioni per mettersi d’accordo su un punto che garantisce la soddisfazione propria e quella dell’interlocutore: quello che viene definito un “win-win“. Spesso chi non fa parte della propria squadra, della propria fazione o non condivide la nostra fede viene considerato “l’altro”, con cui il conflitto è inevitabile.

Lunedì scorso ho avuto una sensazione diversa anzi, citando John Belushi, “ho visto la luce”. Ero in volo su un panorama stupendo, e il cielo era colorato da un tramonto difficile da descrivere (sono un ingegnere con tendenze sociologiche, non ancora un poeta…). Sotto di me le montagne di un paese straniero dove, in mezzo alla neve che per molti chilometri copriva tutto, potevo vedere le luci di una piccola città e un serpente di luci che la raggiungeva: peccato non avere la macchina fotografica… Mentre stavo pensando “deve essere una località di sport invernali, come ce ne sono da noi: allora le hanno anche loro…” mi sono detto: “ma chi sono i loro e i noi?”. Di fronte alla bellezza della natura e alla considerazione che il genere umano è un ospite sulla Terra (forse influenzato anche dal fatto che stavo ascoltando Starway to heaven dei Led Zeppelin e avevo appena finito di leggere Prelude to foundation di Asimov) mi sono reso conto che noi e loro eravamo la stessa cosa. Popoli differenti, nonostante le lingue e le religioni, sono sempre ospiti dello stesso mondo e apprezzano la stessa bellezza (e contribuiscono ugualmente alla sua rovina). A parte piccoli o grandi egoismi, tutti hanno bisogno degli altri e si sentirebbero soli se non potessero confrontarsi con loro. Credo che abbiamo tutti da imparare dal confronto con qualcuno che può dare, su quello che pensiamo o che facciamo, una visione complementare alla nostra. Se ci troviamo d’accordo ne usciamo rafforzati e più sicuri, se no potremmo anche scoprire di aver trascurato qualche aspetto importante e trarne comunque un vantaggio; a volte invece, dovendo arrivare a un compromesso perchè nessuno dei due riesce a convincere pienamente l’altro, si può avere la soddisfazione di aver evitato un conflitto che avrebbe fatto maggiori danni.

Ovviamente questo discorso vale su piani differenti: partendo da considerazioni sull’umanità intera si può arrivare alla propria famiglia oppure ai rapporti di lavoro: tra colleghi, tra cliente e fornitore, tra concorrenti. A volte la volontà di collaborare per l’interesse comune e quella di accettare un diverso punto di vista consentono risultati che sarebbero irraggiungibili se fossimo concentrati solo nel dimostrare di essere più intelligenti o più bravi.Per un architetto, che deve garantire per definizione l’armonia dell’insieme, è una bella lezione (non che io abbia sempre cercato di imporre la mia visione, anzi è da un po’ di tempo che stavo lavorando sulle capacità di mediazione: però sicuramente quelli che mi conoscono sanno che non sono uno tenero…).Giusto per concludere: perchè ho voluto raccontarvi queste considerazioni? Perchè sicuramente, prima o poi, io e qualcuno di voi ci incontreremo per motivi di lavoro… magari ci troveremo in disaccordo, ma spero che aver condiviso queste considerazioni ci aiuterà a trovare una soluzione che vada bene a entrambi

Innovazione è uno termini più ricorrenti nel mondo della tecnologia (se ci pensiamo bene anche in politica, ma è un settore in cui preferisco non addentrarmi …). Non passa giorno, non si chiude riunione che questo termine non ritorni prepotentemente. La parola innovazione viene usata a supporto, come corroborante, di ciò che ognuno di noi intende presentare, ideo o progetto che sia. Sembra quasi che inserendo la parola magica “innovazione” tutto ciò che noi stiamo facendo acquisti più valore o, meglio, “valore aggiunto”. Talvolta capita che, una volta conclusa la relazione o l’esposizione del progetto, ci si interroghi sulla pertinenza tra il significato di innovazione e ciò che abbiamo udito. Ancor più spesso la risposta è negativa. E allora è bene chiedersi cosa davvero significhi innovazione. Se ci affidiamo ad un vocabolario tra i più quotati possiamo leggere che innovare significa “mutare qualcosa, aggiungendo nuovi elementi”. La definizione non ci può soddisfare, perché troppo generica ed indefinita. Personalmente ho la curiosità, oltre che la necessità, di trovare una definizione di innovazione, in quanto io stesso uso spesso questo termine. La risposta è arrivata inattesa, leggendo il keynote di Eric Reiss sul tema “Invenzione, innovazione e futuro dell’architettura dell’informazione”.Reiss, nel corso della sua relazione, dà una definizione di innovazione tanto semplice quanto esaustiva: “Innovare significa trasformare i problemi in soluzioni”. Questa è la summa del concetto di innovare. E Reiss offre questa definizione contrapponendola a invenzione, altro tema che ricorre nel nostro mondo e che spesso si sovrappone a innovazione: “Gli inventori trasformano idee in realtà”.Due termini talvolta scambiati e confusi, in verità contengono significati molto diversi: l’invenzione è legata all’idea, l’innovazione alle pratiche.Ed è da qui che conviene muoversi quando ci interroghiamo sul grado o la capacità di un’azienda di innovare. Un’azienda innova quando, grazie ai prodotti o ai servizi, riesce a risolvere con nuove soluzioni i problemi degli utenti o a migliorarne la qualità della vita, perché lavorare meglio significa vivere meglio… Si badi bene, un’azienda può vincere la sfida del mercato con un prodotto che risponde ad una domanda rimasta inevasa. Ma innovazione significa altro, ovvero saper leggere il mercato, la domanda del pubblico, le criticità e offrire una risposta ad esse.Quindi se un’azienda e i suoi uomini vogliono diventare davvero innovativi, in quanto professionisti, devono costruire una solida esperienza su cui creare le best practice in grado di generare il prossimo ciclo innovativo.Reiss porta uno splendido esempio, la ruota: nulla vieta di considerare un’invenzione un’automobile a otto ruote (quattro per parte), costruita grazie ad una serie di idee nuove, ma se poi questa automobile si impianta nel fango appena affronta lo sterrato a causa del peso, è veramente difficile considerarla un’innovazione. Alla ruota e alla sua rotondità è legata una delle più grandi scoperte della storia dell’uomo, che ha permesso di “risolvere” il problema del trasporto di merci e persone da un luogo all’altro. E questa è innovazione.In conclusione, se un’azienda vuole essere innovativa non può considerare l’innovazione come un obiettivo, bensì come un modello di lavoro e compenetra l’essenza e l’idea stessa di azienda. Innovare non è inventare l’inedito a tutti i costi ma è un modo di pensare ed agire, che si esprime ad ogni azione in modo naturale, senza evidenziatore. Se dobbiamo essere noi a pronunciare la parola innovazione per ciò che stiamo facendo, abbiamo già perso.

L’articolo di Paul Callahan Top 10 mistakes when implementing SOA projects su Zdnet è molto chiaro e personalmente condivido tutto il suo contenuto. Ripetere gli stessi concetti, per quanto possa sentirli anche miei, sarebbe inutile e potrebbe dare l’impressione di attribuirsi il lavoro degli altri…

Comunque voglio aggiungere qualche considerazione, raggruppandole in sei categorie – il che non implica necessariamente che io ne sappia meno di Paul che elenca 10 argomenti – per dare il mio contributo basato sull’esperienza personale. Sono solo spunti di discussione, perchè non possiamo dilungarci su questo blog: sarei in ogni caso felice di approfondire l’argomento con chiunque sia interessato a condividere le proprie esperienze, quindi scrivete i vostri commenti o mandateci una email, ci farebbe piacere.

Tecnologia

Spesso l’adozione di SOA viene interpretata come un’iniziativa meramente tecnologica e si concentrano (a volte si sprecano) molto tempo e molte risorse nel definire puntigliosamente le caratteristiche dei prodotti che si dovranno usare per coprire ogni eventuale necessità futura.

In questo modo l’avvio di un progetto richiede lungo tempo, e si guardano da lontano quelli che sono partiti in modo più pragmatico. Pur essendo uno dei sostenitori di un’architettura di riferimento ben definita (basata su tutti prodotti BEA o meno, va bene lo stesso: e poi un’architettura non è fatta di soli prodotti) sostengo che si può anche procedere per iterazioni successive, cominciando a sperimentare e facendo tesoro dell’esperienza; definendo una visione di ampio respiro mentre si implementano le cose semplici che sono a portata di mano. Pensando in modo strategico e agendo contemporaneamente in modo tattico. Programmando una roadmap che sia oggettivamente realizzabile.

Tra l’altro, a volte la tecnologia di cui si dispone è già sufficiente per iniziare la realizzazione di quello che serve: ho visto fior di architetture realizzate utilizzando Tuxedo o il CICS, quindi non sempre la tecnologia più attuale è necessaria per ogni progetto.

Governance

Molte decisioni devono essere prese nella realizzazione di un programma SOA di livello enterprise:

• Chi definisce e modifica i servizi?
• A chi è consentito l’uso dei servizi?
• Quale livello di servizio dobbiamo fornire?
• Chi paga per la costruzione del servizio?
• Chi paga per l’infrastruttura per i servizi?
• Come devono essere gestite le interdipendenze tra i servizi?
• Come esporre i servizi all’esterno?

Si devono fare anche queste, ed altre, considerazioni:

• Struttura organizzativa
• Finanziamento
• Processi Operativi e strumenti di supporto
• Standard
• Competenze
• Principi Guida
• Change Management

Non ci si può illudere di non dover affrontare questi argomenti, sicuramente quando sono spinosi: quindi metteteli in conto dall’inizio. In ogni azienda esistono posizioni di potere che possono essere intaccate da una strategia basata sulla condivisione e sulla collaborazione: oltre a una rivoluzione culturale servono regole (rispettate) che consentano all’intero sistema di funzionare, possibilmente con il coinvolgimento attivo di tutti gli attori.

Esperienza

A volte ci si fa prendere dall’entusiasmo, avendo intuito (o anche studiato in modo approfondito) i benefici che si possono ottenere da un approccio SOA. Quindi si parte in quarta: si studia, si organizza, si acquista quello che serve e si inizia un bel progetto.

Se però non si ha esperienza di iniative di questa portata, sia dal punto di vista di una architettura enterprise che da quello della famosa governance, si rischia di ritrovarsi in mezzo a una palude.

I tempi di realizzazione, l’integrazione, il budget o il change management possono diventare dei problemi in corso d’opera. A volte si costruisce un bel prototipo, che però non ha le caratteristiche sufficienti per la messa in esercizio; oppure si realizza l’infrastruttura perfetta, ma nessuno ha un servizio utile da metterci sopra.

Vale quindi la pena di confrontarsi con qualcuno che abbia già intrapreso (e portato avanti con successo) lo spesso percorso, per fare tesoro della sua esperienza e impostare il proprio lavoro nel modo migliore.

Consiglio di parlare con project manager, program manager e architetti che abbiano già realizzato progetti SOA reali per farsi raccontare quali difficoltà hanno incontrato e come le hanno eventualmente risolte. Tra questi potete considerare colleghi che hanno il vostro stesso ruolo in altre aziende, consulenti che lavorano per i system integrator o i software vendor, tra cui ovviamente BEA. Mi raccomando però di verificare le credenziali dei sedicenti esperti, perchè SOA è sulla bocca di tutti e il mondo è pieno di “enterprice architett”.

Iniziativa IT senza partnership con il business

Se la divisione IT di un azienda intraprende un’iniziativa SOA in modo autonomo, di solito lo fa per uno di questi motivi:

• va di moda, quindi se gli altri lo fanno un motivo ci sarà
• è moderno, quindi se lo facciamo possiamo metterci in evidenza come innovatori
• possiamo chiedere una quota di budget per rinnovare le nostre infrastrutture.

E’ invece consigliabile che l’inizio del progetto derivi da un’iniziativa condivisa con i responsabili del business dell’azienda: a seconda del settore, con la produzione, la logistica, il marketing, il demand management.

Se l’iniziativa è fine a se stessa, non produrrà un valore per l’azienda. Non avrà un ROI dimostrabile e non darà lustro ai suoi responsabili. Se invece è condivisa con chi può beneficiare dei suoi risultati in termini di fatturato, dimostrerà di portare vantaggi al business. E’ essenziale un sistema di metriche per dimostrare in modo quantitativo il vantaggio generato. Ma soprattutto è necessario che ogni attività sia mirata alla soluzione di un reale problema che gli utenti di business percepiscono nella loro attività. Se per esempio un processo di vendita richiede troppo tempo, ridurne la durata ottimizzando il processo (eliminando attività manuali, per esempio) può avere effetto sul flusso di cassa. Rendere la produzione più efficiente può diminuire l’immobilizzo di capitale e le spese per la logistica. L’IT dovrebbe imparare a parlare lo stesso linguaggio del business e a interpretarne le necessità (condividendole in modo esplicito ed evitando assunzioni che potrebbero non essere condivise).

Mancanza di pragmatismo

Tra l’altro, la condivisione di una roadmap può evitare che si creino aspettative ingiustificate o, peggio, che non ci siano aspettative. Rendere visibili i risultati ottenuti nelle fasi intermedie della roadmap, secondo quanto pianificato, garantisce il supporto degli sponsor di business e non fa venire meno il sostegno negli eventuali momenti in cui il progetto incontra dei problemi. Per questo motivo bisogna assolutamente evitare approcci di tipo Big Bang, in cui risultati eclatanti vengono promessi alla fine di un arco di tempo troppo lungo: si potrebbe non arrivare mai a dimostrarli…

La figura seguente mostra che – a seconda della situazione che fa nascere l’iniziativa SOA – è opportuno organizzarsi in modo differente: la roadmap conterrà azioni adeguate alla situazione e nella sequenza più opportuna.

Comunicazione

• Marketing interno: come detto nell’introduzione, occorre definire un piano strategico e realizzarlo in modo tattico. E’ importante che l’azienda cominci presto ad apprezzare i risultati, per creare un circuito virtuoso intorno all’iniziativa SOA.
• Riuso degli asset nei progetti: se si realizzano dei servizi utili ma pochi ne conoscono l’esistenza, probabilmente il vantaggio del riuso sarà limitato. Conviene mettere a punto una strategia di comunicazione e gli strumenti a supporto (service repository e/o un portale intranet, newsletter, eventi periodici…).
• Demand management: dare a chi si interfaccia con il business la visibilità degli asset disponibili (possono nascere nuove idee dalla conoscenza dei servizi esistenti) o la possibilità di esprimere i requisiti in modo da iniziare il ciclo di vita dei servizi (o delle applicazioni composite): il repository è sempre utile.
• Diffusione della cultura della condivisione: le modalità dipendono dal contesto aziendale, ma questa attività è quanto mai necessaria.

Un altro prodotto BEA finisce nel quadrante Leader di Gartner: è il BPM (Business Process Management). Il report Magic Quadrant Report for Business Process Management Suites (BPM)” descrive in dettaglio quali tipi di processo possono essere migliorati con un BPM, i punti di forza e di debolezza di 22 fornitori di soluzioni, ed i 10 fattori più importanti che un’azienda deve considerare nell’acquisto di un prodotto di BPM. Il report completo è scaricabile a questo indirizzo. Buona lettura.

 Anche quest’anno BEA partecipa al Forum valueIT dedicato a SOA. La qualità dei contenuti rimane elevata e cosi la qualità dei partecipanti. Uno dei, purtroppo non numerosi, convegni di middleware che hanno un ottima partecipazione ed interesse. Speaker BEA sarà Paolo Salvalaglio che racconterà delle migliori best practices che BEA oggi può mettere in campo in tema di architetture service-oriented. Altre news sul blog di ValueIT.

Segnalo questo bell’articolo tratto da ZDNet, dove l’autore evidenzia 12 fattori che contribuiranno allo sviluppo di SOA, Web 2.0 e SaaS (Software as a Service) nel breve-medio termine. L’autore sostiene che queste tre tecnologie hanno caratterizzato le discussioni nell’IT nell’ultimo periodo, ma che il 2008, per una serie di trend che si stanno concretizzando, sarà l’anno in cui vedremo queste tecnologie applicate nelle “next generation enterprises”. Buona lettura.

http://blogs.zdnet.com/Hinchcliffe/?p=157

Il mese di dicembre ha registrato una serie di record in casa del più grande retailer online al mondo. Il 10 dicembre, il giorno dei record, sono stati venduti 5,4 milioni di articoli, che vuol dire 62,5 articoli al secondo! Ma non basta, Amazon ha anche fornito interessanti dati sugli articoli venduti nel periodo natalizio: una Nintendo Wii ogni 17 secondi! Top seller sono stati i DVD di Harry Potter, Apple MacBook, i Gps di Garmin, iPod ed iPhone.Un gran bel segnale per chi si occupa di e-commerce, e per chi come noi dell’IT deve supportare tali volumi di business con architetture adeguate. Dimenticavo, Amazon è un cliente BEA …

Ormai tutti, nel mondo dell’IT, conoscono i principi di SOA e i benefici che si possono ottenere adottando una architettura orientata ai servizi. Molto spesso, però, il primo approccio di chi deve valutare se e come intraprendere un percorso verso SOA è puramente orientato alla tecnologia: si parte con la scelta dei prodotti che dovrebbero consentire la costruzione e la gestione di servizi riutilizzabili e si ragiona sugli standard per l’interoperabilità tra le diverse piattaforme presenti in azienda.

Molto spesso ho visto assimilare SOA all’uso dei web services, come se questi fossero la panacea di tutti i mali. Altre volte, aver realizzato applicazioni che esponevano qualche servizio è stato considerato un traguardo di successo nella creazione di un’architettura. In altri casi è stata costruita un’infrastruttura per i servizi, ma mancano i servizi…In realtà, per la visione che io mi sono creato partecipando a qualche progetto, bisognerebbe affrontare la materia con uno sguardo un po’ più allargato.

Uno degli aspetti fondamentali che possono garantire il successo (oppure minarlo alle fondamenta) è il fattore umano: in termini di motivazione ma anche di organizzazione e disciplina.

Il riuso dei servizi e tutto quello che ne consegue (agilità, time to market, etc.) non può prescindere dalla condivisione del lavoro e dei risultati. Non si combattono i silos tecnologici se non si eliminano quelli legati alla conoscenza e all’iniziativa delle persone: se ciascuno pensa di lavorare per se stesso, anzichè per l’azienda, sarà difficile ottenere risultati significativi indipendentemente dalla bontà delle infrastrutture.

Nella definizione di BEA Systems, SOA è una strategia IT che organizza le diverse funzioni contenute nelle applicazioni dell’azienda in servizi interoperabili, basati sugli standard, che possono essere combinati e riusati rapidamente per soddisfare i requisiti di business.Le parole chiave sono strategia e requisiti di business. Organizzazione, comunicazione e governance contano almeno quanto la tecnologia. I requisiti di business sono l’unica cosa che può dare senso ad ogni iniziativa IT, che non deve essere fine a se stessa: una bella architettura non si costruisce perchè è di moda, oppure per raccontarla in un evento pubblico, ma perchè è utile all’azienda. E l’utilità si misura in termini di fatturato: soldi guadagnati in più, perchè i processi di business beneficiano dei risultati ottenuti in modo quantificabile, oppure si spende di meno perchè si ottimizzano procedure e implementazioni.Non a caso la metodologia proposta da BEA si basa sul cosiddetto “Modello dei sei domini”, che prevede l’analisi e l’ottimizzazione - in parallelo - di tre aspetti legati alla tecnologia (Architecture, Building Blocks e Projects & Applications) e tre legati alla organizzazione e alla comunicazione (Business Strategy & Processes, Organization & Governance, Costs & Benefits). Tutti e sei i domini contribuiscono al risultato finale e, pur raggiungendo l’eccellenza in alcuni di essi (per esempio Building Blocks), si potrebbe perdere una buona parte dei vantaggi se qualcosa non funziona negli altri (per esempio Organization & Governance).

Adozione di una Organizzazione e di un processo di Governance SOA

Di solito i gruppi di lavoro che implementano i sistemi nelle varie aree funzionali hanno già realizzato un buon livello di condivisione interna. Programmi, componenti e transazioni vengono, molto spesso, riutilizzati per consentire un risparmio di tempo e per evitare sforzi duplicati di manutenzione.

Tuttavia lo scambio di informazioni è basato sulla iniziativa dei singoli individui, che vanno alla ricerca del collega in grado di ricordare se e come un certo programma può essere utilizzato. Non esiste un deposito centralizzato ed accessibile delle informazioni sugli asset aziendali, nè un processo standardizzato per la catalogazione dei servizi.Per gestire in modo coerente l’adozione di una nuova metodologia, indirizzando le attività all’interno dei vari progetti e verificando il raggiungimento degli obiettivi desiderati, è opportuno che venga costituito un team dedicato a questa attività.In particolare, essendo l’adozione di SOA una estensione dei processi già in uso per quanto riguarda la Governance IT e influenzando parti dell’azienda che non sono propriamente all’interno della struttura IT (si veda la figura seguente, che mostra le relazioni tra le attività e le strutture), è opportuno un coinvolgimento del management al più alto livello per indirizzare il processo e monitorarne l’avanzamento.

<clicca per ingrandire>

Il ciclo di vita dei servizi - parallelo a quello delle applicazioni composite, che li utilizzano per fornire agli utenti finali il valore aggiunto - deve avere delle solide basi di riferimento, quali:

• Organizzazione dei gruppi di lavoro: ruoli e responsabilità;
• Processo (e strumenti) per l’individuazione, la creazione e la gestione dei servizi;
• Linee guida per l’implementazione, coerenti con l’architettura di riferimento che è stata definita;
• Metriche per misurare i benefici e i costi sostenuti, consentendo la valutazione del ritorno sull’investimento (ROI) e la conferma (o la correzione) della roadmap definita per SOA.

Organizzazione

Si propone quindi la creazione delle seguenti strutture organizzative, che possono eventualmente essere mappate sulla organizzazione esistente riconoscendo ruoli o responsabilità aggiuntive ai gruppi di lavoro.Si evidenziano i ruoli che dovrebbero essere rappresentati in ciascuna struttura; a seconda della disponibilità di persone e competenze, più ruoli potrebbero anche essere assegnati alla stessa persona (all’interno di un gruppo o a cavallo di più gruppi).

In particolare, il gruppo definito al punto 2 potrebbe basarsi sulle figure attualmente inserite nel team di Architettura, assegnando ad esse nuove responsabilità (descritte nei paragrafi seguenti), compatibilmente con i carichi di lavoro esistenti.I gruppi definiti ai punti 3 e 4 sono in realtà quelli che già attualmente si occupano dello sviluppo dei progetti nelle varie aree funzionali. Eventualmente il punto 3 potrebbe essere assegnato su base temporanea (quando la sua attività si rendesse necessaria) a risorse che normalmente appartengono alle aree verticali del punto 4.1. Comitato guida SOA Composto dal Direttore dei Sistemi Informativi, da un Architetto che sia in grado di rappresentare l’evoluzione nell’adozione di SOA, e da rappresentanti delle linee di business.Tiene sotto controllo l’avanzamento delle iniziative legate a SOA e ne rende conto alla direzione dell’azienda.2. Gruppo per la gestione dell’Architetture SOA, composto dalle seguenti figure/ruoli:

• gestore del catalogo dei servizi,
• metodologo (per definire, guidare e raffinare il processo),
• architetto dei dati,
• architetto di integrazione (EAI),
• architetto dedicato alla Security.

Questo gruppo dovrebbe riunirsi periodicamente con i gruppi di sviluppo (una riunione ogni due settimane salvo necessità diverse) per allineare tutti gli attori sulle nuove realizzazioni, le best practices, le strategie di medio termine.Valida le richieste di realizzazione dei nuovi servizi utilizzando il processo definito, li censisce nel catalogo, opera a supporto dei gruppi di sviluppo fornendo competenze tecniche o metodologiche, valida l’architettura proposta per i nuovi progetti.Tra le responsabilità di questo gruppo di lavoro:

• Condivisione dell’informazione (best practices, processi gestionali, evangelizzazione SOA, descrizione dei processi di business dei clienti con modello standard, per esempio UML o BPEL).
• Realizzazione della SOA Dashboard (che deve mostrare al comitato guida lo stato di avanzamento della roadmap).

3. Sviluppo dei servizi di business condivisiUna volta che i servizi candidati sono stati individuati dal Gruppo per la gestione dell’Architetture SOA, se la visibilità dei servizio va oltre il singolo progetto e/o se la realizzazione richiede un parallelismo per rispettare la pianificazione del progetto, si incarica della implementazione e del rilascio dei nuovi servizi.Questo gruppo è anche responsabile della creazione dei servizi infrastrutturali per arricchire l’architettura con tutte le funzionalità di base riutilizzabili in ogni progetto: sicurezza, log, audit, monitoraggio, reporting.4. Sviluppo dei servizi verticaliI vari gruppi di progetto, strutturati secondo le aree funzionali esistenti, si incaricano di realizzare i servizi con visibilità locale in autonomia. Resta la collaborazione con il Gruppo per la gestione dell’Architetture SOA, con cui le scelte architetturali devono essere concordate.La figura seguente mostra l’intersezione delle responsabilità dei gruppi di lavoro definiti in precedenza:

<clicca per ingrandire>

La tabella seguente mostra in che modo i gruppi definiti in precedenza collaborano e si dividono la responsabilità relativamente al ciclo di vita dei servizi (SDLC = Service Development Life Cycle) e dell’architettura SOA.

<clicca per ingrandire>

Processo di gestione del ciclo di vita dei servizi

Per facilitare e rendere più rapida l’adozione della metodologia SOA, BEA propone ai propri clienti l’uso del proprio Enterprise Service Engineering Framework (ESEF). All’interno di ESEF sono definiti:Processo di proposta, approvazione, implementazione dei serviziLinee guida e template per:

• Identificazione dei servizi
• Analisi e progettazione
• Costruzione e rilascio
• Esposizione dei servizi e versionamento
• Monitoraggio

La figura seguente mostra l’overview del processo definito per gestire i servizi che vengono identificati analizzando i requisiti di un nuovo progetto oppure razionalizzando l’accesso a funzionalità già esistenti nei sistemi attuali.

<clicca per ingrandire>

La maturity matrix

L’utilizzo delle best practices può essere misurato secondo due direzioni ortogonali: la maturità (qualità di quello che è stato realizzato) e l’adozione (misura quantitativa dell’estensione). La tabella seguente mostra una prima rappresentazione di come si possa valutare lo stato attuale di una organizzazione per valutare se soddisfa le necessità di business. In base alla stessa tabella si può ipotizzare un percorso per raggiungere il livello ritenuto necessario in base a considerazioni pragmatiche, che tengano conto delle effettive necessità e delle risorse (tempo e costo) che si possono realisticamente mettere in campo.

<clicca per ingrandire>

La struttura di cui faccio parte mette a disposizione dei clienti una serie di strumenti per affrontare le varie fasi del percorso verso la realizzazione di una Service Oriented Architecture:

• esplorazione dei possibili ritorni e delle risorse necessarie
• pianificazione del percorso (roadmap relativa all’architettura e all’organizzazione)
• costruzione dell’infrastruttura e dei servizi

Nella prima fase vengono proposti, a seconda delle condizioni di partenza: un self assessment, un SOA Discovery Workshop, un SOA Assessment effettuato da consulenti della SOA practice di BEA in collaborazione con il cliente.Nelle fasi successive sono disponibili servizi di consulenza orientati maggiormente alla tecnologia o alla governance, oppure che abbracciano tutti i sei domini contemporaneamente. Tutti sono strutturati secondo una struttura modulare per adattarsi alle esigenze specifiche di ogni organizzazione, evitando l’imposizione di un modello fisso che potrebbe essere inapplicabile in certi contesti.Chi volesse approfondire le tematiche trattate in questo post, oppure il contenuto e lo scopo dei servizi di consulenza legati a SOA, può contattarmi per discuterne di persona.

Attualmente, nell’industria del software il Supporto Clienti rientra in una delle seguenti categorie: il supporto proattivo e il supporto reattivo.Il supporto proattivo (in BEA è rappresentato dal livello di Supporto deniminato Mission Critical) rappresenta un approccio intensivo alla risoluzione dei problemi di sistema individuati, prima che questi ultimi provochino tempi elevati di inattività o influiscano sulla produttività e sul business dei Clienti. Con il supporto proattivo si controllano i sistemi e interviene sulla causa principale di un problema prima che si aggravi.Il supporto reattivo, al contrario, risolve i problemi dopo che essi hanno già avuto qualche impatto sulle applicazioni e sul business, cercando di eliminare il problema esistente e di ripristinare il normale funzionamento del sistema.Tuttavia, sia il modello di supporto proattivo che quello reattivo lasciano talvolta i Clienti insoddisfatti.  Entrambi i tipi di supporto possono risultare dispendiosi, sia in termini di tempo che di denaro; infatti entrambi i modelli implicano che il problema si verifichi prima che sia possibile intervenire. L’identificazione e la risoluzione dei problemi esistenti possono richiedere un numero maggiore di ore di lavoro e di impiego di risorse.BEA sa che i sistemi complessi rappresentano il centro nevralgico delle aziende dei Clienti, che non possono certo affidarsi solo a questi modelli di supporto “guasto/riparazione”. I nostri Clienti richiedono sempre di più un supporto continuo (24 ore al giorno, sette giorni su sette), in grado di identificare i potenziali problemi prima che si verifichino.Necessitano inoltre di un paradigma di supporto assolutamente affidabile.BEA ha quindi indicato una nuova tipologia di supporto, che ha chiamato “preventivo“.BEA Guardian è la risposta di BEA alle esigenze precedenti, individuate grazie ad approfondite ricerche e analisi sul campo. (Scaricate le analisi di Forrester Research)Le ricerche eseguite da BEA indicano che oltre il 40% dei problemi sono dovuti a errori di configurazione e amministrazione.L’identificazione dei problemi di configurazione e amministrazione e l’elaborazione dei relativi report garantiscono che l’implementazione disponga di patch, impostazioni di configurazione e altri attributi corretti. BEA Guardian notifica persino gli eventuali conflitti di configurazione con le best practice applicate da BEA.BEA Guardian è uno strumento intuitivo per il supporto di sistema preventivo, progettato per individuare i potenziali problemi prima che questi richiedano l’intervento del personale di supporto IT o influiscano negativamente su operazioni e clienti.BEA Guardian consente inoltre di ottimizzare le implementazioni e le operazioni giornaliere.Se l’installazione di BEA Guardian dispone di connettività Internet, è anche possibile trarre vantaggio dalla creazione diretta di Chiamate (CASI) al BEA Customer Support, nonché dagli aggiornamenti automatici.Per saperne di più e per scaricare documenti e prodotto visitate la pagina “BEA Guardian” sul sito www.bea.com

Parola di Gartner, IDC e Forrester. Segnalo qui un interessante articolo di un magazine olandese che riassume le indicazioni dei maggiori analisti in sei grandi trend per il 2008: qualche suggerimenti per CIO e IT manager per i prossimi mesi.http://www.webwereld.nl/articles/49082/six-enterprise-application-trends-to-watch-in-2008.html

L’ acronimo S.O.A. è ormai entrato nel vocabolario di coloro che operano nel mondo  dell’Information Tecnology: lo si trova in ogni presentazione, report, articolo che quotidianamente cattura la nostra attenzione.  Ma l’adozione di un’architettura a servizi (una SOA appunto) è un processo merita attente valutazioni; soprattutto perchè deve diventare una strategia che coinvolge l’azienda nel suo complesso.Per ogni manager diventa, quindi, fondamentale capire quali siano le motivazioni a monte di questa scelta e come questa possa essere giustificata sul piano dei costi e governata in fase di adozione.

• Perchè un’azienda dovrebbe adottare un’architettura a servizi?
• Quali sono gli impatti che tale scelta ha sul business e sull’IT?
• Quali sono i possibili cambiamenti che si devono portare all’organizzazione?
• Come si deve cambiare la governance per adeguarla al nuovo modo di lavorare? 
• Quali sono i benefici derivanti dall’adozione di una SOA?
• Come può essere definito un modello per il calcolo del ROI?

BEA ha messo a punto un seminario di 4 ore in cui condividere  idee ed esperienze e presentare  un possibile approccio metodologico . Il seminario è studiato per executive, manager e leader non necessariamente appartenenti al mondo ICT. 

All’inizio era la telefonia tradizionale con i suoi servizi voce in grado di mantenere in crescita le revenue dei vari operatori telefonici. Poi sono arrivati i servizi a valore aggiunto (VAS) e la continua ricerca della killer application, l’ “Applicazione” che avrebbe dovuto colmare la diminuizione dei profitti dei servizi voce e degli sms. Sono stati fatti diversi tentativi, gli operatori hanno iniziato a collaborare con alcuni partner selezionati, per fornire servizi alternativi. Tutto questo non ha funzionato, o solo in parte. La dimostrazione sono le continue pubblicità che si vedono in giro dove gli operatori insistono ancora su offerte di voce e SMS/MMS senza mai promuovere nulla di nuovo.Nel frattempo sono arrivati i vari Google, Skype, Youtube, SecondLife che stanno catalizzando l’attenzione degli utenti relegando i carrier a semplici fornitori di connettività. L’utente acquista un abbonamento flat (a breve anche su terminale mobile), ottiene il suo accesso internet e diventa un nodo della rete, libero di decidere cosa fare e con chi.Ed ancora, l’introduzione di applicazioni quali wikies e blogs hanno spostato il ruolo dell’utente che da singolo consumatore dei contenuti presenti su internet a produttore. Gli americani hanno coniato il termine “prosumer”.E’ nato così il social networking con i sui strumenti di condivisione delle informazioni , di tagging, bookmarking, blogging e tutte quelle forme di aggregazione che fanno parte ora di un fenomeno chiamato Web2.0.Ora lo scenario sta cambiando, gli operatori hanno smesso da tempo di cercare la killer application e stanno cercando di inseguire questa nuova onda di entusiasmo e soprattutto hanno realizzato che o si alleano o perdono la guerra.

Si cominciano a concretizzare i primi progetti di Service Exposure che consistono nel rendere disponibili le funzionalità della rete come servizi accessibile dall’esterno a disposizione di chiunque voglia realizzare applicazione composite (mashup networks).

Questo perchè, sul piano tecnologico, gli operatori hanno ancora diverse carte da giocare perchè una delle grosse limitazioni nei servizi offerti dalle varie “Google companies” è data dal fatto che l’utente è anonimo in quanto si presenta con un indirizzo internet o al più è l’utente virtuale che ha deciso di essere. L’applicazione Google puo’ al massimo lavorare sugli header HTTP o sui cookies per cercare di gestire in qualche modo l’utente.

Gli operatori invece sono in possesso di un insieme di informazioni pregiate sull’utente per la realizzazione di servizi innovativi in quanto sono “fisicamente connessi” con loro:

• Location – hanno l’informazione su dove l’utente si trova a diverse granularità
• Network – hanno l’informazione su quale rete sono attestati
• Bandwidth – hanno l’informazione sulla banda disponibile per una specifica sessione
• Presence – hanno l’informazione sul terminale che l’utente sta utizzando tra quelli a disposizione con la stessa identita

Questi sono solo alcuni esempi di informazioni che fino ad oggi hanno tenuto gelosamente all’interno delle proprie reti sia per questioni puramente tecnologiche sia soprattutto perchè considerate un loro valore da non condividere

Ma oggi più che mai gli operatori possono raccogliere la sfida del Web 2.0 mettendole a disposizione sotto forma di Web Services , API, Widget, Pagelet.

BEA Systems ha creato da tempo una famiglia i prodotti WebLogic Communication Platform proprio per rispondere a questa nuova esigenza offrendo agli operatori una serie di soluzioni che permettono in modo rapido, seguendo un approccio SOA, di “esporre la rete come servizio”.

Per ulteriori approfondimenti vedi il sito http://www.bea.com/wlcp/

Abbiamo appena rilasciato i risultati di una interessante ricerca condotta su 134 Partner di BEA in Europa (26 paesi), Partner che operano su Clienti Enterprise, Grandi aziende e Medium e Small Business. Ecco cosa ne emerge:

1. il 36% ritiene che la maggiore opportunità di business per il 2008 sarà il BPM (Business Process Management), su tutte le tipologie di Clienti;
2. al secondo posto la Business Integration (20%) ed al terzo la SOA Governance (13%);
3. le soluzioni di Portale saranno quelle più interessanti nel settore Enterprise e Grandi Aziende;
4. mentre il maggior ostacolo che stanno affrontando ora sono le barriere tra l’IT ed il Business all’interno dei Clienti

Non possiamo che essere d’accordo con queste valutazioni che arrivano da Partner in tutta Europa.In particolare due commenti. BPM: da buzzword a progetti reali. Tutti ne parlano ma non solo: molti clienti stanno realizzando fior di progetti sul BPM, e stanno toccandone con mani i positivi risultati.Secondo punto: IT e Business a confronto, altro tema ricorrente ed evidenziato non solo da noi, ma da Clienti ed Analisti: ed ancora una volta, BEA è in prima linea con le soluzioni di Business Liquidity ….Grazie a tutti i Partner che hanno contribuito … e vedremo come le aspettative si tradurranno in realtà nel prossimo anno.

“Non è un blog, è una brochure!” Questo è stato il commento di un amico che ha letto Caffè con BEA e sigh, io sarei tra i colpevoli. In effetti nel mio post precedente ho parlato e dato un giudizio positivo di un prodotto BEA, WebLogic Integration. Chiedo venia, purtroppo posso parlare di ciò che conosco. Per tentare di farmi perdonare, vi propongo un’altra riflessione, certo basata su WLI (vedi sopra) ma applicabile a tutti i prodotti dello stesso tipo.Spesso mi sono imbattuto in clienti che mi chiedevano: perchè dovrei usare un motore di processi ? Ecco, secondo me, le ragioni per utilizzarlo e quelle per farne a meno:I motivi del SI

1. si sviluppa più in fretta (perchè i wizard mi nascondono le complessità delle interfacce da usare)
2. si fà l’integration test più in fretta (perchè il debug di front-end e back-end è integrato)
3. la gestione dello stato dei processi è già pronta e non richiede ulteriore sviluppo
4. il monitor dei processi in produzione è già pronto e non richiede ulteriore sviluppo
5. è più semplice modificare l’applicazione quando è già in produzione

I motivi del NO

1. non ho controllo del codice perchè uso molti wizard e componenti già pronti
2. non posso realizzare certi trucchi, perchè lo strumento me lo impedisce
3. vorrei poter controllare alcuni dettagli dei processi in esecuzione, mentre lo strumento me ne visualizza altri

Le due liste non sono esaustive, anzi vi esorto a completarle o a modificarle secondo la vostra esperienza. Per quanto mi riguarda, e qui rischio l’ennesima stroncatura, i sostenitori della seconda lista finiscono spesso per riscriversi un process engine quasi per intero e dunque, io che sono di natura un pigro, mi chiedo: non era meglio prenderlo già pronto?

Tempo fa partecipai ad un avvincente progetto di integrazione: inserimmo un “bus” per lo scambio di messaggi fra le diverse applicazioni di una SIM (Società di Intermediazione Immobiliare) e grazie a questo “strano oggetto” i traders ed i loro capi potevano vedere informazioni tra loro correlate ma che risiedevano in sistemi differenti ed isolati. Le modifiche avvenivano in tempo reale ed i dati erano dunque sempre aggiornati.

Ma non fu questa la parte che più piacque al cliente. L’iniziativa ebbe successo grazie alla rapidità con la quale l’IT riusciva a realizzare le richieste dell’utente finale. Oltre naturalmente, all’affidabilità del sistema, che non perdeva un messaggio.

Se, dopo quasi dieci anni, cito ancora quell’esperienza è perchè il confronto con la realtà di oggi appare ancora istruttivo: le interfaccie di comunicazione fra il bus e le applicazioni da integrare venivano sviluppate a mano di volta in volta, partendo da un set di librerie proprietarie. Non esisteva il concetto di processo o di orchestrazione. Il mapping dei dati era realizzato con uno strumento visuale che alimentava un motore esterno al bus. Forse ciò che è cambiato meno da allora ad oggi è la trasformazione dei messaggi. Eravamo già ad uno stadio evoluto, anche se non utilizzammo standards come XML.

In un progetto più recente che ho potuto osservare da vicino, il system integrator ha semplificato la componente di integrazione ed introdotto l’uso di un motore di processi utilizzando WebLogic Server e WebLogic Integration. Il bus comunica con le applicazioni via SOAP, RMI o JDBC, ed ha integrato la componente di processo consentendo la creazione di nuove funzionalità basate su quelle offerte dei sistemi esterni.

WebLogic Integration ha fatto la parte del leone. Ha consentito l’integrazione delle applicazioni e lo sviluppo dei processi in pochissimo tempo. L’infrastruttura di test inclusa nel prodotto ha ridotto i tempi di collaudo e le funzionalità del motore hanno sollevato il system integrator dall’onere di dover sviluppare da sé la logica di stato e persistenza di messaggi e di processi.

Naturalmente non solo BEA Systems offre strumenti di questo tipo. Ma ciò che voglio evidenziare, al di là dei prodotti utilizzati, è il progresso avvenuto in questo campo. Si programmano sempre meno le interfaccie di comunicazione (che son sempre state una materia ostica, nello sviluppo e nel collaudo) e si riduce sempre di più il tempo di realizzazione di nuove funzionalità, grazie all’uso dei process engine come WebLogic Integration.

Oggi affronto un progetto d’integrazione con grande serenità, convinto che l’adozione di WebLogic Integration sollevi il team da molto lavoro inutile, elimini le cause di tanti errori e consenta di raggiungere l’obiettivo con tempi certi e, cosa più importante, con la soddisfazione del cliente.

Qualche giorno fa BEA ha rilasciato il nuovo report “State of the Portal Market 2007: Portals and The Power of Participation” (bea_state_of_portal_market_2007-wp-it.pdf)(46 pg) che riassume i dati della annuale ricerca (ormai la sesta edizione), frutto di oltre 450 interviste a CIO clienti di BEA, più un centinaio di report di analisti (Gartner, IDC, Forrester ed altri) collezionati negli ultimi 12 mesi. Una fonte ragguardevole di informazioni che fotografano una serie di aspetti su cui le aziende italiane ed internazionali stanno riflettendo.

1. Business e IT – BPM e SOA: l’incremento delle iniziative di business process management (BPM) e Service Oriented Architecture (SOA) stanno spingendo l’uso di portali. Questo perchè i portali sono la naturale interfaccia di architetture a servizi, di sistemi di process management, e di sistemi di collaborazione. 
2. Business participation – Web 2.0: dopo l’impatto rivoluzionario delle società Web 2.0 sul consumer, le aziende stanno adottando questi stessi principi per utilizzarli all’interno. Ed i portali sono ancora una volta lo strumento principe per rendere disponibili funzionalità Web 2.0 e di social computing enterprise.
3. Benefici: oltre ai benefici legati strettamente al fatturato evidenziati dal report, i clienti dei portali BEA sottolineano benefici come l’aumento della produttività e dell’efficienza dei dipendenti, la riduzione dei costi di supporto e servizio, l’aumento della fidelizzazione dei clienti, il consolidamento dell’infrastruttura IT e la riduzione dei costi operativi, grazie alla diminuzione dei processi manuali o basati su carta.
4. Costi di implementazione: Per il 77% dei clienti di portali BEA, i costi di consulenza e personalizzazione sono stati minori dei costi di licenza, e questo dimostra come il portale sia un mezzo di implementazione rapido e flessibile per un’ampia gamma di iniziative aziendali.
5. Ampliamento dell’audience: nonostante la tendenza al consolidamento, il numero di portali implementati in azienda è in aumento. E questo incremento è dovuto all’aumento delle audience supportate dai portali e dalla maggiore flessibilità della tecnologia per velocizzare lo sviluppo e l’implementazione delle applicazioni.

Riassumendo, il report rivela che, per il sesto anno consecutivo, i portali rimangono una priorità per i CIO delle aziende. Conferma, inoltre, che i portali rimangono la piattaforma ideale per consolidare le applicazioni, permettere l’integrazione e il riutilizzo dei sistemi e dei dati esistenti ed aiutare i clienti a mettere a disposizione degli utenti - sempre più amanti delle community - le funzionalità Web 2.0 e le tecnologie di social computing.È possibile scaricare questo studio all’indirizzo: http://bea.com/whitepapers/portal-marketQui sotto uno dei tanti grafici che supportano i risultati del report.

Nasce oggi un nuovo blog. Ed è la voce alle persone che lavorano in BEA Systems Italia. Una voce “informale” di professionisti dell’IT, che si apre sulla blogosfera, ed arricchirà presto la blogosfera stessa di contenuti utili e stimolanti. Scriveremo di tecnologia, di soluzioni, di clienti, di novità, di concorrenti, potremo aprire discussioni con clienti, partner e collaboratori, parleremo di BEA ma non solo. Insomma la voce di un nutrito gruppo di professionisti che da tempo porta sul mercato italiano competenza, talento e ottime (concedetemelo) soluzioni IT (quelle di BEA intendo …).Lascio ora la parola al nostro Vice President Marco Bucci, che con un breve video apre i battenti di Caffè con BEA …<p><p>Per ora è tutto da Caffè con BEA, lasciate pure commenti qui sotto.Alla prossima