SOA è solo tecnologia? Consigli utili su come approcciare un progetto SOA

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.

Risultati di BEA nello scorso quarto

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.

BEA Guardian – Ora disponibile gratuitamente a tutti i Clienti BEA

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

Applicazioni enterprise: i sei trend per il 2008

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

Non siate malEducati !!!

Ciao a Tutti, vorrei iniziare, da oggi, ad usare questo spazio per scambiare con voi impressioni, informazioni ed idee sulla formazione in generale e su quella BEA in particolare. Negli ultimi mesi, noi di BEA Education Services, stiamo facendo uno sforzo per cercare di adeguare la nostra offerta formativa alle richieste dei clienti e dei partner.  Nuove modalità di erogazione, personalizzazione dei contenuti, agende più “liquide” ci consentono di raggiungere un target di risorse prima impensabile. Se volete essere parte di questo processo aggiungete i vostri pensieri a questo post e sarò lieto di interagire con voi. Ricordatevi di consultare la nostra web page it.bea.com\formazione e di trovare il percorso formativo più adatto alle vostre esigenze. Per non essere male educati, sulle nostre tecnologie e sulle problematiche ad esse correlate, c’è solo un modo: seguire i corsi originali BEA. 

Fabrizio Fascia – Education Services Sr.Manager

SOA per Manager

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. 

Web 2.0 e servizi telefonici, due mondi che si incontrano?

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/

Le previsioni dei Partner BEA per il 2008

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.

Process Engine: sei per il SI o per il NO ?

“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? 😉

BEA primeggia in Cina

Qualche giorno fa si è concluso il tour del BEAWorld, la conferenza annuale mondiale di BEA: dopo la California e Barcellona e’ venuto il tempo della Cina e di Shangai. Ho ricevuto stamani le prime comunicazioni interne sui risultati della conferenza e sono rimasto impressionato: nei due giorni di conferenza (12 e 13 dicembre) hanno partecipato più di 6.000 persone !!! Seimila, lo scrivo in parole per vederlo meglio … ci pensate ? una sessione plenaria presieduta dal nostro CEO Alfred Chuang, od un coffee break con seimila cinesi che si fanno un te’ ? Sono piacevolmente affascinato … in Europa nessuna società che gravita attorno all’ICT è in grado di raccogliere così tante persone in una sala, nessuna.

Ma anche altri numeri che emergono dal BEAWorld Shangai 2007 possono farci riflettere sulla Cina, e sugli possibili scenari da medio-lungo termine a cui stiamo inevitabilmente andando incontro.

BEA, presente sul mercato cinese da una decina di anni, ormai primeggia a dispetto di big come Oracle o IBM (Fonte Gartner, Analysys International “Magic Quadrant for Middleware Producers in China 2007” ). Ed i clienti BEA asiatici portano nomi magari a noi sconosciuti (Chongqing Telecom, Jiangsu Electric Power o Daewoog Pharmaceutical), ma hanno dimensioni che intimoriscono: in Cina ci sono più di 500 milioni di utenti di telefonia mobili … i numeri europei spariscono.
E ancora, Marcus Tsoi, il nostro Vice President e General Manager di BEA Systems Cina è stato riconosciuto come uno dei personaggi più influenti del panorama IT cinese nel corso della Annual Economic Conference 2007 di Pechino.

Complimenti ai miei colleghi asiatici !!!