mercoledì 25 settembre 2013
martedì 24 settembre 2013
Dalla Spaghetti Integration alla SOA di ultima generazione
Spaghetti Integration
Nell’ impresa moderna, la gestione dei dati associati al business e' distribuita su un numero variabile di sistemi informativi aziendali (EIS - Enterprise Information Systems).
Si definisce EIS qualsiasi sistema aziendale che comprende dati, informazioni e processi necessari all'azienda per la gestione del proprio business.
I sistemi EIS:
- Gestiscono aree indipendenti e separate di informazioni aziendali (CRM, OM, Marketing, ERP, Finance, Billing, Portal, SelfCare...)
- Tendono ad espandersi in modo spesso disordinato e scorrelato
- Sono estremamente eterogenei tra loro in termini di: rappresentazione dei dati, modellizzazione dei processi aziendali, interfacce.
I primi tentativi di integrazione, originati dalla necessita' di stabilire una interconnessione ad-hoc point-to-point tra sistemi, hanno portato a un modello di integrazione povero e inutilmente complesso, soprannominato Spaghetti Integration.
Riassumendo, gli aspetti negativi della Spaghetti Integration sono:
- Specifiche di integrazione definite in modo disordinato dai referenti dei singoli sistemi (gruppi di lavoro differenti) e non seguendo direttive comuni
- Molteplicità di protocolli e dI tecnologie utilizzate
- Lentezze nello sviluppo e nella manutenzione delle integrazioni per i flussi Enterprise (processi dati che impattano su diversi sistemi della architettura IT)
- Difficoltà nel controllo di processi e flussi che attraversano la catena dei sistemi
- Impossibilità di avere una governance centralizzata.
Enterprise Application Integration
L’ Enterprise Application Integration (EAI), il cui Il concetto chiave e' la centralizzazione delle comunicazioni e delle funzionalita', e' il primo approccio alla soluzione per una integrazione corretta ed efficente.
Questo approccio, la cui diffusione ha inizio nella seconda metá degli anni 90, prevede un layer applicativo centrale (Middleware) che funge da intermediario nelle comunicazioni tra i sistemi e fornisce servizi MOM (Message Oriented Middleware) di piattaforma di base (messaging, load balancing, fault tolerance, transazionalita'...).
I sistemi risultano in questo modo debolmente accoppiati, in quanto non devono piu' comunicare direttamente l'uno con l'altro, ma unicamente tramite un Broker di integrazione preposto al routing dei messaggi (modello hub-and-spoke).
Al fine di razionalizzare il numero e il tipo di connessioni tra i sistemi e, conseguentemente, le attivita' aziendali, i principi cardine dell'EAI sono i seguenti:
Integrazione dei processi di business
- Transazioni di business che coinvolgono molteplici EIS devono essere trattate come unita' logiche
- Per l'implementazione di tali transazioni di business, deve essere possibile definire Workflow complessi che coinvolgano molteplici EIS
- Eventi di business devono poter scatenare azioni globali che si estendano oltre il dominio del singolo EIS
Integrazione delle applicazioni
- Le funzionalita' di business implementate da un'applicazione devono essere esposte e rese disponibili alle altre applicazioni
Integrazione dei dati
- I dati devono essere condivisi e distributi attraverso molteplici EIS differenti
- Devono essere garantiti l'allineamento e la consistenza dei dati
Con l'adozione da parte delle imprese di metodologie e tecnologie di integrazione EAI, si riscontrano i seguenti benefici:
- Razionalizzazione dei flussi e degli sviluppi
- Maggiore disponibilita' delle informazioni distribuite attraverso le isole applicative aziendali
- Risposte piu' rapide alle nuove opportunità di business con conseguente riduzione del Time-to-Market
- Maggiore efficienza e migliore qualità dei servizi offerti
- Maggiore controllo sui processi di business
- Un supporto piu' efficace ai processi decisionali aziendali
- Un aumento dell'efficienza dei processi aziendali nel loro complesso.
Da EAI a SOA (Service Oriented Architecture)
L'approccio EAI si e' dimostrato vincente nel fornire soluzioni efficienti di integrazione, ma esistono alcune limitazioni nell'architettura EAI che ne limitano la capacita' di fornire una soluzione completa al problema dell'integrazione aziendale:
- Architettura monolitica: soluzione server-centrica, centralizzazione dei processi di integrazione, architettura Hub-and-Spoke
- API proprietarie, formati chiusi/non-standard
- Modalitá di integrazione vincolata alle caratteristiche del MOM utilizzato
- Architettura chiusa verso il mondo esterno (business partner, clienti), difficilmente accessibile dalla extranet
- Soluzione che lega le aziende a prodotti specifici e soluzioni proprietarie non standard offerte dai vendor EAI
- I progetti di integrazione in StartUp hanno una lunga durata (20+ mesi) per introdurre il middleware nella architettura generale ed adeguare tutti i sistemi.
A partire dai primi anni 2000 all'interno delle aziende con una IT complessa ed evoluta, si è iniziato a parlare di integrazione di sistemi e processi mediante un approccio a servizi, ma solo qualche anno più tardi si realizzeranno soluzioni di buon livello.
La SOA (Service Oriented Architecture) separa le funzionalita' di un EIS raggruppandole in un insieme di componenti ad alto livello che espongono "porzioni" di logica di business sotto forma di servizi accessibili attraverso interfacce documentate e tecnologie standard. Quindi non più una metodologia di integrazione basata su un middleware tecnologico unico che veicola le informazioni, ma un approccio più Open, basato sul rispetto degli standard, quali XML, JSON, Web Services, Http/SOAP, REST, J2EE, etc., che consente il disaccoppiamento (decoupling) dei protocolli di comunicazione e la fruizione di servizi che implementano workflow di processi più o meno complessi.
La messa in opera della SOA in un contesto IT Enterprise prevede, oltre alla adozione di best practices e standard, la messa in campo di alcuni moduli applicativi fondamentali di cui il più importante è l'ESB (Enterprise Service Bus).
L'ESB rappresenta una nuova tipologia di BUS che combina Web Services, messaggistica e servizi di integrazione di base quali la trasformazione dati, il disaccoppiamento dei protocolli e il content-based routing (routing su base contenuto).
La sua architettura lo rende indipendente dagli Application server, MOM e protocolli utilizzati, pertanto risulta particolarmente adatto a costituire in modo progressivo la struttura portante di una nuova integrazione orientata ai servizi che nel contempo preservi, interoperando con esse, le risorse IT pre-esistenti quali applicazioni legacy e piattaforme di middleware eterogenee.
L'ESB permette di adottare una strategia di integrazione progressiva che fornisce la possibilita' di costruire, in maniera incrementale e a costi minori, una rete di integrazione aziendale.
Altri strumenti abilitanti per una architettura SOA completa sono:
- BPM (Business Process Management), design e orchestration dei servizi come workflow
- BAM (Business Activity Monitoring), monitoring dei servizi e dei processi di business
- Service Registry, registro dei servizi esposti dall'ESB con definizione dei contratti di protocollo (wsdl).
Una architettura IT orientata ai servizi, flessibile e disaccoppiata, riduce i tempi e i costi di manutenzione dei progetti, nonche' le necessita' di customizzazione ed evoluzione degli stessi a fronte di nuovi requisiti di integrazione.
I principali vantaggi per l'azienda sono:
- Razionalizzazione delle informazioni e dei processi nell'area aziendale
- Riutilizzo delle funzionalità/servizi
- Aumento della efficenza/qualita' del servizio
- Centralizzazione della Governance
- Drastica diminuzione del Time-To-Market
- Riduzione del TCO (Total Cost of Ownership) grazie alla dismissione progressiva di middleware vendor locked.
Comparativa sui costi
Il grafico illustra le differenze di costo dei diversi approcci nelle varie fasi di vita di un progetto software.
Risulta evidente come un' approccio Custom point-to-point abbia dei bassissimi costi iniziali per realizzare le prime integrazioni tra i sistemi ma poi con il passare del tempo aumenta la complessità di manutenzione ed evoluzione con conseguente aumento di costi e tempi.
Un approccio di tipo EAI invece, similmente a quello basato sull'utilizzo da parte dei sistemi di Web Services standard ma senza una infrastruttura ESB, ha dei costi di realizzazione iniziale medi, garantisce successivamente dei costi abbastanza contenuti nella manutenzione della infrastruttura ma necessita di un effort con dei picchi molto alti per la realizzazione di nuovi flussi Enterprise o la modifica di processi già esistenti,
Utilizzando i paradigmi e gli strumenti SOA invece si rileva un impegno considerevole nell'introduzione e sviluppo iniziale della infrastruttura di base, ma un progressivo risparmio nelle fasi successive dovuto alla capacità di riutilizzo dei servizi (Service Reusability) e della loro orchestrazione (Service Orchestration).
La SOA di ultima generazione
Nel periodo che va dal 2004 al 2010, un po' tutte le aziende medio-grandi, con a disposizione un parco di sistemi informatici importante, ha intrapreso un percorso di adeguamento dell'architettura dei sistemi ai paradigmi della SOA.
Nel tempo la Service Oriented Architecture è diventata quasi un tormentone, passando da essere un "must have" ad una locuzione passata un po' di moda.
Questo ciclo di vita è stato storicamente percorso da gran parte delle proposte tecnico/informatiche che, da essere spinte commercialmente, adottate con grandi sforzi economici e pubblicizzate oltremodo in alcuni casi anche in contesti non idonei, diventano soluzioni un po' dimenticate, anche se mai completamente portate a termine per arrivare a beneficiarne dei vantaggi.
In un mondo IT che almeno in apparenza evolve a grandi velocità, diventa fondamentale per continuare ad attrarre investimenti, la proposizione continua di nuove soluzioni agganciate a slogan in voga che riescono a smuovere almeno un minimo il mercato anche in ambiti enterprise ormai consolidati.
Tuttavia di fatto la SOA resta l'approccio più valido per l'interpretazione dei requisiti di integrazione e di gestione dei processi di business anche se nel maggior parte dei contesti non è stata adottata con una pervasività ed un livello di maturità sufficiente; il termine "servizio" in ambito IT è diventato sinonimo di funzionalità offerta sulla rete in un contesto di cooperazione applicativa tra i sistemi.
Negli ultimi anni, grazie al perfezionamento degli strumenti e ad una maggiore esperienza maturata da Solution Architect e System Integrator, è aumentata la capacità di rilasciare soluzioni stabili, proponendo all'interno della infrastruttura di base della SOA anche degli "accessori" utili a migliorare le performance di risposta ai servizi.
Negli ultimi anni, grazie al perfezionamento degli strumenti e ad una maggiore esperienza maturata da Solution Architect e System Integrator, è aumentata la capacità di rilasciare soluzioni stabili, proponendo all'interno della infrastruttura di base della SOA anche degli "accessori" utili a migliorare le performance di risposta ai servizi.
Data Caching
Con il Data Caching la piattaforma di integrazione ESB si dota anche di funzionalità di memorizzazione in cache dei flussi dati provenienti dai sistemi client e server, in modo da velocizzare quando possibile l'accesso alle informazioni ed i tempi di riposta ai servizi.
La memorizzazione dei dati viene demandata a layer applicativi fortemente scalabili in cache chiamati InMemory DB, Data Grid Memory o Data Service Layer che si occupano anche di gestire l'invalidazione dei dati stessi, secondo delle policy pre-definite, ed il loro ricaricamento dai sistemi owner mediante interazione con i servizi di integrazione dell'ESB.
Rule Engine (motore a regole)
Un altro modulo applicativo accessorio che sempre più spesso viene affiancato ai componenti infrastrutturali della SOA è il Rule Engine: motore a regole configurabile ed estendibile in grado di interagire con i servizi ESB per la interpretazione di algoritmi complessi applicati ai dati. Avere un Rule Engine risulta molto utile quando è necessario implementare operazioni di routing numerose e complesse difficilmente configurabili all'interno dell'ESB o del BPM.Articoli correlati:
Introduzione al Customer Journey
Con la locuzione inglese Customer Journey si intende il percorso decisionale ed operativo che il cliente compie nelle varie fasi di acquisto di un qualcosa. Con i cambiamenti introdotti dalla rete e dalle nuove tecnologie:
L'influenza dei canali online nel Customer Journey
http://think.withgoogle.com/customer-journey-to-purchase/
- le ormai consolidate modalità di acquisto e pagamento online,
- la possibilità di effettuare autonomamente e velocemente indagini su ciò che si desidera comprare,
- la facilità con cui si può avere un confronto preventivo o successivo con coloro che world wide hanno già avuto la stessa esperienza,
- l’utilizzo massivo dei nuovi terminali Always On (Smartphone e Tablet) con cui si può accedere sempre ai canali di shopping e di informazione (Forum, Feedback e Social Network),
si sono modificate anche le dinamiche del processo di acquisto.
In che modo ora il compratore da un momento X arriva ad acquistare il prodotto Y ?
In che modo l’esperienza d’acquisto influisce successivamente su se stessi e sugli altri ?
Come è cambiato il ruolo del venditore ?
Si tratta di un processo complesso che nel corso del tempo è stato descritto e schematizzato in diversi modi, negli ultimi anni sono stati fatti degli studi che, alla luce delle nuove dinamiche, lo hanno esteso e ne hanno cambiato le caratteristiche.
Per tutti, sia compratori che venditori, è opportuno tenerne conto.
Le fasi fondamentali
Un po' di storia
Studi di qualche anno, basati sulle dinamiche di acquisto fino ai primi anni 2000, non consideravano il momento di Indagine e Riflessione come una delle fasi fondamentali, ma la sovrapponevano ai momenti di Stimolo e di Acquisto.
In effetti nelle fasi 1 e 3, quando si viene in contatto con chi/cosa innesca lo stimolo, con l’oggetto da comprare e con il venditore, sicuramente il cliente effettua degli approfondimenti e delle considerazioni sull’acquisto che sta valutando.
Nel 2005 un approfondimento di Procter & Gamble sintetizzava il Customer Journey in 3 sole fasi:
1. Stimolo (Pubblicità, Visibilità, Disponibilità)
2. Il primo momento della verità (FMOT), ovvero il primo contatto con il prodotto e con il venditore addetto
3. Il secondo momento della verità (SMOT), ovvero la fase post-vendita, quando il cliente utilizza effettivamente il prodotto e giudica le caratteristiche.
Nel 2011 Google, effettuando studi sulle dinamiche di vendita online, perfeziona ed introduce il concetto di ZMOT conseguenza del fatto che oggi la ricerca, il confronto con gli stimoli e la fase di “persuasione” si giocano sul Web:
FMOT – First Moment Of Truth (Shelf)
Quel momento, che dura tra i tre e i sette secondi, durante i quali una persona all’interno di un negozio (fisico o digitale) rivolge la sua attenzione verso un prodotto e decide o meno di comprarlo. È il momento il cui il consumatore entra in contatto con il prodotto e con il venditore, valuta e decide o meno per l’Acquisto.
ZMOT – Zero Moment Of Truth
Fase in cui il potenziale acquirente, attraverso ricerche su Forum, Motori di ricerca e sui Social Network, raccoglie informazioni sui prodotti e decide (ancora prima essere in contatto fisico con l’oggetto nel negozio) che cosa comprare.
È il momento che precede l’acquisto ed è di fatto la fase di Indagine e Riflessione ora basata soprattutto sui nuovi canali tecnologici oltre che sulle vecchie modalità
SMOT – Second Moment Of Truth (Experience)
E’ l’esperienza di consumo del prodotto che viene fatta successivamente all’acquisto: la persona può vivere un’esperienza positiva che conferma quanto deciso durante lo FMOT oppure negativa che fa sì che la persona decida di non comprare più quel determinato prodotto. È il momento post-vendita, di fatto la fase di Esperienza e Considerazioni.
Impatti dello ZMOT tecnologico
- Dal 2007 al 2009 la percentuale di clienti che decide un acquisto all’interno del punto vendita è diminuito dal 40% al 17%
- Nel 2011 l’88% dei consumatori USA è coinvolto nello ZMOT prima di andare in un negozio on-line o off-line per un acquisto
- Nel 2011 in media un consumatore consulta 10.4 fonti prima di effettuare una acquisto «significativo», il doppio rispetto all’anno precedente.
Nella realtà....
…il processo di acquisto è molto più complesso. Le fasi principali possono essere ulteriormente suddivise, dettagliate molto accuratamente e si diversificano a seconda del contesto e del prodotto.
E’ buona cura del venditore approfondire e conoscere le dinamiche del proprio settore e della tipologia dei propri clienti al fine di controllare meglio il processo e poterlo governare.
Considerazioni
- Costruire stimoli basati sulla sola pubblicità in TV, garantire visibilità all’interno dei punti vendita, ecc. sono aspetti non più sufficienti
- La ricerca, l’indagine, il confronto con gli stimoli e la persuasione si giocano sul Web
- Verificare e curare la Web Reputation del prodotto, del brand e del Venditore sono aspetti fondamentali
- Siti web, social network, blog, forum e community varie sono il nuovo luogo all’interno del quale il consumatore desidera e sceglie il proprio acquisto, prodotto o servizio che sia.
- Conoscere gli strumenti/canali di ZMOT che utilizza la clientela per anticiparne le riflessioni, è propedeutico per la vendita
- Capire in quale fase del percorso si trova il cliente rispetto ad un acquisto e quale è stato lo stimolo, sono aspetti basilare per poter modificare/migliorare la strategia presente e futura di persuasione e vendita
- Capire quali sono gli Stimoli principali del contesto di marketing e chi/cosa li veicola, è fondamentale per una strategia di vendita
- Per un successo commerciale è importante prevedere il Customer Journey e percorrerlo in anticipo rispetto ai potenziali clienti
- E’ opportuno attendersi clienti preparati, in grado di confutare il venditore sulle caratteristiche del prodotto.
Approfondimenti
La ricerca di Google «Winning the Zero Moment of Truth»
ZMOT Overview & eBook
L'influenza dei canali online nel Customer Journey
http://think.withgoogle.com/customer-journey-to-purchase/
SOA Overview
Al fine di ottimizzare i costi e di migliorare la gestione dell’ IT, le aziende guardano, sempre più con maggiore interesse, alle problematiche di gestione ed ottimizzazione dei processi aziendali.
L’attuale modello di riferimento per l’implementazione e la gestione dei Business Process è il modello SOA (Service Oriented Architecture), particolarmente utile alle aziende con un portafoglio di applicazioni complesso dal momento che agevola l’interazione tra le diverse realtà aziendali permettendo alle attività di business di sviluppare processi efficienti e nel contempo di aumentarne la flessibilità e l’adattabilità.
Il modello SOA è in grado di raccogliere le sfide che l’IT riceve quotidianamente dalle nuove forme ed esigenze di business, fornendo risposte concrete e rapide al fine di ottenere più efficienza, flessibilità e qualità con meno risorse, maggiore allineamento col business, migliore consistenza e qualità dei dati e un rapido “time to deploy” delle nuove applicazioni.
In tale contesto i System Integrator collocano la propria offerta mettendo a disposizione del mercato la propria competenza derivata dalla conoscenza di prodotti, framework, tecnologie, standard, best practices e dalle esperienze acquisite.
In tale contesto i System Integrator collocano la propria offerta mettendo a disposizione del mercato la propria competenza derivata dalla conoscenza di prodotti, framework, tecnologie, standard, best practices e dalle esperienze acquisite.
SOA REFERENCE MODEL
A livello di Information Technology, la SOA è un’infrastruttura software che consente ad applicazioni eterogenee ed a sistemi diversi di implementare processi di business, scambiare dati ed eseguire transazioni tramite l’utilizzo di componenti software (servizi) con caratteristiche ben definite, orientate al riutilizzo ed alla integrazione. Tali servizi sono esposti con modalità standard risultando così fruibili da qualsiasi utilizzatore (service consumer) che si interfacci, nelle modalità richieste, al fornitore di servizi (service provider).
Nell’ambito di un’architettura SOA è possibile modificare, in maniera semplice, le modalità di interazione tra i servizi, la combinazione nella quale essi risultano utilizzati, così come risulterà agevole aggiungerne di nuovi o modificarne i processi per rispondere alle specifiche esigenze di business. In tale scenario il processo di business non sarà più vincolato ad una specifica piattaforma o applicazione ma potrà essere considerato come un componente di un processo più ampio e quindi riutilizzato o modificato.
Il modello SOA nasce dall’idea di realizzare ed esporre servizi offerti da un’organizzazione in modo che siano accessibili in modo automatico, uniforme e con protocolli standard e aperti.
Nell’ambito di un’architettura SOA è possibile modificare, in maniera semplice, le modalità di interazione tra i servizi, la combinazione nella quale essi risultano utilizzati, così come risulterà agevole aggiungerne di nuovi o modificarne i processi per rispondere alle specifiche esigenze di business. In tale scenario il processo di business non sarà più vincolato ad una specifica piattaforma o applicazione ma potrà essere considerato come un componente di un processo più ampio e quindi riutilizzato o modificato.
Il modello SOA nasce dall’idea di realizzare ed esporre servizi offerti da un’organizzazione in modo che siano accessibili in modo automatico, uniforme e con protocolli standard e aperti.
APPROCCIO METODOLOGICO
La definizione e la realizzazione di Progetti SOA prevedono soluzioni personalizzate che si adattano di volta in volta alle specifiche esigenze del Cliente, mediante l’utilizzo di tre diversi approcci strategici:
Top-Down: il focus è posto sull’analisi dei processi di business, per poi identificare i servizi attraverso raffinamenti successivi. Tale approccio è quello più corretto partendo da una situazione scratch.
Meet-In-The-Middle: il focus è posto sull’analisi della situazione attuale (applicazioni as-is) per poi raggiungere il grado di astrazione necessario per l’integrazione dei processi. Tale approccio cerca di integrare la SOA con applicazioni sviluppate in precedenza: questo è il caso più frequente che prevede di operare su applicazioni esistenti.
Bottom-Up: il focus è posto sull’analisi della definizione dei componenti per poi disegnare i servizi. Tale approccio rivela una mancanza del grado di astrazione necessario per la definizione di servizi realmente riusabili e non è quindi consigliabile.
Meet-In-The-Middle: il focus è posto sull’analisi della situazione attuale (applicazioni as-is) per poi raggiungere il grado di astrazione necessario per l’integrazione dei processi. Tale approccio cerca di integrare la SOA con applicazioni sviluppate in precedenza: questo è il caso più frequente che prevede di operare su applicazioni esistenti.
Bottom-Up: il focus è posto sull’analisi della definizione dei componenti per poi disegnare i servizi. Tale approccio rivela una mancanza del grado di astrazione necessario per la definizione di servizi realmente riusabili e non è quindi consigliabile.
Con l’approccio SOA è possibile:
- Garantire l’allineamento tra le funzioni IT e quelle di Business grazie alla definizione di soluzioni infrastrutturali in grado adeguare l’IT dinamicamente alle diverse esigenze di Business rispettando gli SLA concordati,
- Abilitare l’erogazione di servizi IT in modalità on demand sia verso il mercato interno che esterno,
- Ridurre il Time-to-Market per lo sviluppo di nuovi servizi di Business mediante i concetti di riutilizzo delle risorse introdotti dall’Utility Computing e dalla SOA,
- Ridurre il Total Cost of Ownership (TCO) dell’infrastruttura grazie all’introduzione di nuovi strumenti che abilitano la standardizzazione dei processi di comunicazione,
- Ridurre il numero di sistemi grazie alla possibilità di consolidare su un unico sistema più applicazioni sulla base del concetto di condivisione introdotto dall’integrazione,
- Offrire elevati livelli di disponibilità e scalabilità per mezzo di tecnologie innovative che permettono la veloce allocazione di risorse infrastrutturali ove necessario,
- Ridurre il costo dell'intero ciclo di vita del software e della evoluzione dei flussi di business.
FASI DI REALIZZAZIONE
L’adozione di una architettura SOA oriented, all’interno di una infrastruttura IT complessa già esistente, va pianificata progressivamente in un percorso che prevede un punto di partenza nel momento in cui ci si trovi di fronte ad un caso concreto.
Le fasi operative/progettuali previste sono:
SOA Assessment: mediante lo studio dei processi di business sono individuate nel dettaglio le esigenze del Cliente ed è rilevato il grado di maturità tecnologica dell’organizzazione attraverso l’utilizzo del SOA Maturity Model in modo da garantire opportuna aderenza alla SOA,
SOA Solution Planning: identifica lo scenario applicativo SOA verso cui evolvere e si pianificano tempi e attività di implementazione,
Service Management: attività di service analysis, service design, build, testing, deployment dei servizi, workflow e applicazioni sulla base di quanto identificato nelle fasi precedenti,
Integration Management: con il rilascio in produzione di sistemi operativi, middleware, applicazioni si possono realizzare infrastrutture efficienti reattive e correlate alle reali esigenze del Cliente,
SOA Governance: attività di controllo dei servizi SOA che prevede:
SOA Solution Planning: identifica lo scenario applicativo SOA verso cui evolvere e si pianificano tempi e attività di implementazione,
Service Management: attività di service analysis, service design, build, testing, deployment dei servizi, workflow e applicazioni sulla base di quanto identificato nelle fasi precedenti,
Integration Management: con il rilascio in produzione di sistemi operativi, middleware, applicazioni si possono realizzare infrastrutture efficienti reattive e correlate alle reali esigenze del Cliente,
SOA Governance: attività di controllo dei servizi SOA che prevede:
- Governance Process Definition
- Governance Process Execution
- Governance Process Monitoring
per garantire solidità alla struttura del processo decisionale, gestione delle relazioni tra servizi e componenti e il rispetto della conformità delle normative vigenti, degli standard e delle procedure stabilite dalle aziende. La Governance rappresenta la chiave di successo delle iniziative SOA in quanto permette di verificare costantemente l’affidabilità dei servizi e la coerenza con le attività ed i processi che i servizi devono supportare, riducendone in tal modo sia i rischi che i costi.
In un momento in cui la concorrenza ed i vincoli normativi si intensificano nel mercato dei servizi finanziari, le installazioni SOA stanno arrivando a un livello in cui la loro governance è fondamentale per la gestione dei servizi ed il loro ri-utilizzo durante l’interno ciclo di vita SOA. Dopo la fase iniziale di adeguamento al modello SOA, il focus di un’azienda non è più rivolto a realizzare servizi ma piuttosto a “governarli” in maniera efficiente e performante: il processo di “governance” è essenziale per il successo della SOA.
In quest’ottica i modelli SOA devono essere fortemente orientati alla Governance, basandosi sulla riusabilità, sulla riduzione della complessità del portafoglio applicativo eliminando le funzionalità ridondanti, sulla messa in sicurezza delle applicazioni integrate che vengono usate da un numero sempre crescente di utenti, sull’assicurazione del rispetto dei Service Level Agreements (SLAs).
In quest’ottica i modelli SOA devono essere fortemente orientati alla Governance, basandosi sulla riusabilità, sulla riduzione della complessità del portafoglio applicativo eliminando le funzionalità ridondanti, sulla messa in sicurezza delle applicazioni integrate che vengono usate da un numero sempre crescente di utenti, sull’assicurazione del rispetto dei Service Level Agreements (SLAs).
DIRETTIVE E STRUMENTI
L’ architettura SOA è basata sui seguenti elementi:
- Standard aperti: per poter operare in ambienti multipiattaforma è necessario utilizzare standard aperti quali XML, WSDL e WS-Security (WSS),
- Modularità: è necessario individuare il corretto equilibrio tra i servizi utilizzabili nelle funzioni comuni ed i servizi dedicati a processi specifici,
- Contratti di servizio: WSDL (Web Services Description Language) è la specifica standard per la creazione di contratti per i Web Services
e sui seguenti strumenti applicativi:
- Service Registry/Repository: strumento che elenca e descrive i servizi disponibili e le modalità di accesso agli stessi. Garantisce una più semplice interoperabilità tra i sistemi e facilita la SOA Governance,
- ESB (Enterprise Service Bus): layer applicativo che implementa la pubblicazione dei servizi e le interfacce di integrazione agli stessi da e verso i sistemi esterni. Prevede adattatori per i sistemi legacy, orchestrazione di servizi per la definizione delle regole di business, componenti per autorizzazione e autenticazione (security), trasformazione dati e capacità di monitorare i service-level agreement (SLA),
- BPM (Business Process Management): layer applicativo che abilita l’implementazione, la gestione e l’orchestrazione dei workflow e dei processi di business di più alto livello.
- BAM (Business Activity Monitoring): strumento il monitoring dei servizi e quindi dei processi di business,
- Data Management: piattaforma di gestione del Common Data Model in ottica SOA e dei servizi di trasformazione e validazione dati come sottoservizio dell’ESB; lo scopo primario è il governo centralizzato dei metadati aziendali basato su standard.
Articoli correlati:
Web 2.0 ?
"Web 1.0 was all about connecting people. It was an interactive space, and I think Web 2.0 is of course a piece of jargon, nobody even knows what it means. If Web 2.0 for you is blogs and wikis, then that is people to people. But that was what the Web was supposed to be all along."
"Il Web 1.0 voleva consentire alle persone di comunicare, quindi voleva essere uno spazio interattivo.
Credo che il Web 2.0 sia piuttosto una forma di slang, nessuno sa cosa significhi. Se il Web 2.0 per voi sono i blog ed i wiki, allora sono persone che si connettono ad altre persone... ed è questo che il Web sin dall'inizio era pensato per essere."
Credo che il Web 2.0 sia piuttosto una forma di slang, nessuno sa cosa significhi. Se il Web 2.0 per voi sono i blog ed i wiki, allora sono persone che si connettono ad altre persone... ed è questo che il Web sin dall'inizio era pensato per essere."
(Tim Berners Lee - Director of W3C)
 |
| Image courtesy of Stuart Miles / FreeDigitalPhotos.net |
Il valore di un Framework software
In informatica, un Framework software e' lo scheletro di un'applicazione che deve essere esteso e customizzato per ottenere la soluzione specifica ad un dato problema riguardante un ambito applicativo.
L'utilizzo di un framework impone allo sviluppatore una precisa metodologia di implementazione del software facilitandone nel contempo il lavoro: si e' sollevati dalla necessità di rifare molte funzionalità comuni dato che vengono fornite dalle componenti di base del framework stesso (infrastruttura) e ci si può concentrare maggiormente sui problemi riguardanti lo specifico scenario in esame e le funzionalità applicative richieste.
Un framework è sicuramente sempre estendibile seguendo le direttive ed i modelli di programmazione pre-definiti (pattern) e, se il codice è OpenSource, è anche customizzabile nei suoi moduli fondamentali chiamati Engine o Core.
L'arricchimento delle funzionalità del framework avviene seguendo le specifiche e sviluppando i moduli software di cui si ha bisogno, le nuove implementazioni ereditano la filosofia di funzionamento dei moduli Core.
Le caratteristiche principali di un buon framework sono:
- il livello di maturità della infrastruttura Core
- il rispetto degli standard, dei protocolli e delle best practices di quell'ambito tecnologico ed applicativo
- l'alta configurabilità (configuring, not coding)
- la facilità con cui si riescono a realizzare ed aggiungere i nuovi moduli (plugin)
- la chiarezza e la completezza dei pattern
- le facilities di contorno (debugging, monitoring, logging, console, ecc.)
- la qualità della documentazione fornita che ne facilità l'uso
- l'esistenza di un supporto tecnico o di una community di sviluppatori a cui rivolgersi
- l'esistenza di una roadmap evolutiva che prevede anche l'adeguamento verso le nuove versioni del software di base
- la retro-compatibilità delle nuove versioni.
Ad oggi, esistono Framework applicativi di tutti i tipi, per tutti gli ambiti applicativi e tecnologici a diversi livelli di qualità e maturità.
La maggior parte nascono e vengono evoluti in un contesto di community OpenSource ma i più consolidati sono spesso utilizzati esplicitamente o re-impacchettati anche all'interno di soluzioni commerciali di tipo Enterprise in ambito Business.
 |
| Image courtesy of Stuart Miles / FreeDigitalPhotos.net |
Don’t crack software
Don’t crack the software you use: Buy it !
By purchasing legal software you are supporting PEOPLE LIKE US that creates tools for you to work with.
In the long run you benefit yourself by ensuring that these companies, often small and composed by few men, have the resources to continue to develop better tools and ideas.
Maybe one day you’ll collaborate with them. Educate yourself !
Non crackare il software che usi: Compralo !
Acquistando il software legalmente si supportano PERSONE COME NOI STESSI che creano gli strumenti di lavoro.
A lungo andare ne beneficerai anche tu garantendo che queste aziende, spesso piccole e composte da poche persone, abbiano le risorse per continuare a sviluppare migliori strumenti e idee.
Magari un giorno collaborerai con loro. Educa te stesso !
 |
| Image courtesy of Salvatore Vuono / FreeDigitalPhotos.net |
Articoli correlati
Come sminuire il proprio lavoro di informatico
Perchè odio i frameworks
(libera traduzione del post “Why I hate frameworks” di BenjiSmith http://discuss.joelonsoftware.com/?joel.3.219431.12)
Attualmente sto pianificando la realizzazione di una applicazione web in Java (deve essere Java per una serie di ragioni che non ho voglia di raccontare in questo momento).
In relazione alla suddetta attività, sto valutando una serie di portlet J2EE-enabled JSR-compliant MVC role-based CMS web service application container frameworks.
Dopo aver speso decine di ore a leggere lunghi elenchi di funzionalità e tanta tanta documentazione, sono pronto a storcere il naso nell’utilizzo di un framework.
Per spiegare i miei dubbi in tal senso, procedo con un esempio: facciamo finta che io abbia deciso di costruire un Portaspezie.
In passato ho fatto piccoli lavoretti con il legno e quindi credo di avere un'idea abbastanza precisa di quello che mi serve, un po’ di legno e altri strumenti fondamentali: un metro, una sega, una livella e un martello.
Se dovessi costruire una intera casa piuttosto che un portaspezie, tra le altre cose avrei ugualmente bisogno di un metro a nastro, di una sega, di una livella ed un martello.
Quindi vado al negozio di ferramenta per comprare gli strumenti e chiedo al commesso dove posso trovare un martello.
"Un martello?" chiede sorpreso il commesso, "Nessuno compra più martelli. Sono una cosa vecchio stile, ormai superata. "
Io, basito da questa affermazione, gli chiedo perché.
"Beh, il problema con martelli è che possono essere di tanti diversi tipi: mazzette, martelli artigliati, martelli a rotondi, ecc.. Cosa succederebbe se, dopo aver comprato un tipo di martello, vi rendeste conto che avevate bisogno di un altro tipo ? Dovreste comprare un altro martello per fare il vostro lavoro.
Come abbiamo riscontrato, la maggior parte dei clienti vorrebbe un singolo martello universale in grado di andare bene per tutti i tipi di lavoro".
"Hmmmmmm. Bene, posso essere d’accordo. Puoi dirmi dove posso trovare un martello universale ?"
"No, noi non li vendiamo più. Sono obsoleti."
"Davvero?!!?? Anche questi ?!?!? Ma mi sembra di aver capito che mi hai appena detto che il martello universale è la cosa più richiesta per poter fare anche in futuro lavori di tutte le tipologie".
"Si, ma come abbiamo riscontrato, se avessi un solo tipo di martello universale in grado di eseguire tutte le operazioni fattibili con tutti i diversi tipi di martelli, non sarebbe in effetti specifico per nessuna di esse.
Per esempio, mettere un chiodo con un mazza non è molto efficace oppure se volete uccidere la vostra ex-fidanzata non c'è davvero niente di meglio di un martello con la testa arrotondata ".
"OK, quindi se nessuno compra più martelli universali e voi non state più vendendo i vecchi tipi di martelli di una volta, che tipo di martelli vendete? ".
"In realtà, noi non vendiamo martelli per niente".
"Quindi ...".
"Secondo la nostra ricerca, quello di cui la gente ha davvero bisogno, dopo tutto non è un martello universale dato che è 'sempre meglio avere il giusto tipo di martello per ciascun lavoro.
Quindi, abbiamo iniziato a vendere fabbriche di martelli in grado di produrre qualunque tipo di martello che potrebbe essere utile.
Tutto quello che devi fare è riempire la fabbrica con i lavoratori, attivare le macchine, comprare le materie prime, pagare le bollette e ... avrai esattamente il tipo di martello che ti serve".
"Ma io non voglio comprare una fabbrica di martelli ...".
"Giusto !! E’ per questo che noi non le vendiamo più.".
"Come ?!??!?! Ma... io pensavo di aver capito che ....".
"Si, ma abbiamo scoperto che la maggior parte delle persone non ha effettivamente bisogno di un’intera fabbrica di martelli. Alcune persone, per esempio, non hanno mai bisogno di un martello con la testa rotonda (forse non hanno mai avuto ex-fidanzate o forse le uccidevano con le pinze per ghiaccio),
quindi non c'è alcun motivo per chi compra una fabbrica di martelli di produrre ogni tipo di martello".
"Certo, quello che dici è sensato".
"Così, abbiamo iniziato a vendere Template di fabbriche di martelli, permettendo ai nostri clienti di costruire le loro fabbriche di martelli, personalizzando i progetti al fine di produrre solo i tipi di martelli di cui hanno effettivamente bisogno. ".
"Lasciami indovinare.... ora non vendete più neanche i template".
"No, certo che no. A quanto pare, la gente non vuole progettare e personalizzare un’ intera fabbrica solo per costruire un paio di martelli ".
"Mi pare chiaro".
"Quindi abbiamo smesso di vendere i template ed iniziato a vendere fabbriche di fabbriche di martelli. Ogni fabbrica di fabbriche di martelli è realizzata per voi dai migliori esperti in fabbrica di fabbriche di martelli, quindi per il cliente non c'è bisogno di preoccuparsi di tutti i dettagli che servono nella costruzione di una fabbrica.
In questo modo, i clienti hanno ancora tutti i benefici di avere una propria fabbrica di martelli al fine di produrre i propri martelli personalizzati secondo le proprie specifiche, ma non hanno problemi di progettazione e realizzazione".
"Beh, ma poi....".
"So cosa stai per dire!! ... Che noi non vendiamo più neanche quelle.
Infatti, per qualche ragione, non molte persone hanno acquistato le fabbriche di fabbriche di martelli, così siamo arrivati a una nuova soluzione per affrontare il problema".
"Dimmi dimmi".
"Abbiamo fatto un passo indietro e guardato l'infrastruttura globale, stabilendo che le persone erano frustrate dal dover gestire una fabbrica di martelli, nonché la fabbrica di fabbriche che l’ha prodotta.
Questo tipo di sovraccarico può diventare molto pesante quando bisogna gestire analoghe situazioni di fabbriche di fabbriche di metro a nastro, fabbriche di fabbriche di seghe, fabbriche di fabbriche di livelle.
Quando abbiamo analizzato la situazione, abbiamo determinato che questo è troppo complesso per chi davvero vuole solo costruire un portaspezie ".
"Sì, condivido".
"Così questa settimana, stiamo introducendo un strumento generico, la fabbrica di fabbriche di fabbriche, in modo che tutte le tue fabbriche di fabbriche di utensili possano essere prodotte da una singola, unica fabbrica.
La fabbrica di fabbriche produrrà solo le fabbriche di fabbriche di cui si ha veramente bisogno e ciascuna di queste fabbriche di fabbriche produrrà una singolo fabbrica in base alle specifiche da voi fornite riguardo allo strumento personalizzato.
Alla fine, gli strumenti che usciranno da questo processo, saranno gli strumenti ideali per lavorare al vostro particolare progetto. Avrete esattamente il martello che vi serve ed esattamente il metro giusto per il vostro scopo, il tutto con la semplice pressione di un pulsante (anche se potrebbe essere necessario valorizzare alcuni files di configurazione per far funzionare il tutto secondo le vostre aspettative). ".
"Quindi non ci sono martelli? Niente? Neanche un avanzo di magazzino ?".
"No. Se si vuole veramente produrre qualcosa alta qualità, ad esempio un portaspezie realizzato industrialmente, hai disperatamente bisogno di qualcosa di più avanzato di un semplice martello preso in un negozio di ferramenta ".
"Chiariscimi bene, questo è quello che tutti stanno facendo ora ? Tutta la gente usa un general-purpose tool-fabbrica di fabbriche di fabbrica ogni volta che hanno bisogno di un martello? ".
"Sì".
"Beh ... Va bene. Credo che è quello che dovrò fare. Se questo è il modo con cui le cose vanno fatte, credo che sia meglio imparare a farlo".
"Buon per te!".
"Scusami ancora, con questa tool fabbrica di fabbriche di fabbrica di...... viene fornita la documentazione, giusto ?".
Giorni dopo l’acquisto....
Ora che sono l'orgoglioso proprietario del mio general-purpose tool-fabbrica di fabbriche di fabbrica, sono soddisfatto di sapere che esso soddisfa con il progetto 0,97 specifiche GPTBFFF RC2 per lo strumento di costruzione fabbrica di fabbriche.
Per fortuna, il 70% dei lavoratori nel Tool-Oriented Metafactory Union sono certificati con questa versione di specifiche.
All'orizzonte però c’è uno standard concorrente: il molto convincente metafactory technology chiamato UXCTBFFF (Universal Trans-Continental strumento per la creazione FFF), che promette di unificare la fabbrica fabbrica industria fabbrica per rispettare le linee guida dei paesi che utilizzare entrambi gli strumenti metrici e standard.
La mia comprensione è che ci sarà un service pack al mio GPTBFFF0,97 RC2 per portare in quasi il 95% di conformità con il UXCTBFFF standard, semplicemente creando un livello di astrazione attraverso la sua facilità di utilizzo dell’interfaccia.
Grandioso !!
Sicuramente questo nuovo sviluppo migliorerà la qualità del mio portaspezie.
(che dovrò in effetti costruire uno di questi giorni, appena avrò in esecuzione la mia fabbrica fabbrica di fabbriche, la mia forza lavoro addestrata, le mie materie prime importate dalla Cambogia, ecc.).
Traduzione di Savedev
 |
| Image courtesy of jscreationzs / FreeDigitalPhotos.net |
Iscriviti a:
Post (Atom)