You are currently browsing the tag archive for the ‘BEA Systems’ tag.

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!

logo.jpg

Annunci

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.

liquid-enterprise-bea.jpg

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”
ITIL Support Processes

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:

Side by side deployment

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.

test della nuova versione in administration mode

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

soavirtual.jpg

microhoo.jpg 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 🙂

reiss-car.jpg 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.

entry points

 

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.

Attenzione!

Questo sito non è piu' aggiornato. Vieni a trovarci sul nuovo Caffe' con BEA

Disclaimer

I post su questo blog rappresentano i pensieri personali dei singoli autori e non rappresentano le posizioni ufficiali di BEA Systems. Se scrivete commenti, essi saranno rivolti solo ai singoli autori e non a BEA Systems. Le immagini ed i filmati possono essere tratti da Internet: qualore violassero eventuali diritti di autore, segnalatelo subito a pfurini@bea.com.