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.

Annunci

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.

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.

1541b58d-925b-428f-9a98-45da9736cad5_gartner_mgq.jpg

 

forumvalueit.jpg 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.

2008nextgen_enterprises.jpg

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.

governance1.jpg <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:

governance2.jpg <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.

governance3.jpg <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.

governance4.jpg <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.

governance5.jpg <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.

Come non iniziare la partecipazione a questo blog se non parlando degli ottimi risultati finanziari di BEA del trimestre chiuso lo scorso 31 ottobre 2007. Trimestre, che ha visto finalmente la possibilità di divulgare pienamente i risultati finanziari nella massima trasparenza e rigore che da sempre contraddistinguono il mondo BEA in materia di accounting.
Con un cash flow operativo pari a 87,5 milioni di $ generato nel trimestre, in crescita del 62% rispetto allo scorso anno, BEA ha riportato un saldo di cash e investimenti a breve pari a 1,2 miliardi di $ riportando inoltre sempre in termini patrimoniali un fatturato differito in crescita del 15%.
La famiglia AquaLogic ormai rappresenta il 27% del fatturato di licenze ed è cresciuta dell’ 11% rispetto al terzo trimestre dello scorso anno (AquaLogic User Interaction ha registrato il miglior risultato di trimestre di sempre, e AquaLogic Enterprise Registry and Repository, sempre più importanti per l’emergente e interessante area del SOA management and governance, hanno consolidato gli ottimi risultati iniziati nel secondo trimestre).
Ma questo è stato anche il trimestre della WebLogic Communication Platform che ha ottenuto i migliori risultati di sempre, dimostrandosi sempre più come una soluzione dirompente ed innovativa per il mercato delle TLC.
Continuando a parlare di conto economico il miglioramento in termini di profittabiltà ha dell’incredibile … con un fatturato di 384,4 milioni di $ nel trimestre, in crescita dell’11% rispetto al terzo trimestre dello scorso anno, l’utile operativo su base GAAP ( i principi contabili americani generalemente accettati) ha registrato un incremento di ben il 70% rispetto allo scorso anno, passando da 37.7 milioni di $ registrati nel terzo trimestre dell’anno scorso  ai 64,3 milioni di $ registrati nel terzo trimestre di quest’anno.  
Dal punto di vista geografico da segnalare la continua e progressiva crescita in Asia dove, guidata da Cina e Giappone, BEA ha riportato ricavi di licenze in crescita del 24% ad ennesima dimostrazione di come BEA stia ben operando in questi territori andando a cogliere le clamorose opportunità di crescita. In ultimo, ottima performance dell’Italia che dopo un brillante inizio anno si conferma anche nel terzo trimestre in linea con gli obiettivi di crescita, e con un ultimo trimestre estremamente promettente.

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

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.