You are currently browsing the category archive for the ‘Servizi’ category.
L’obiettivo di SOA è allineare le capacità dell’IT agli obiettivi di business: secondo le statistiche, il principale motivo per cui molte aziende hanno adottato, o stanno adottando, questa strategia è l’agilità che essa consente al sistema informativo.
La metafora dei mattoncini del LEGO rende bene l’idea: diversi assemblaggi degli stessi componenti possono produrre rapidamente costruzioni diverse, soddisfacendo i requisiti di business in un tempo ridotto, ma con una qualità superiore, rispetto all’approccio IT tradizionale.
Oltre alle dichiarazioni di principio e alla corretta gestione delle informazioni all’interno dell’azienda, è necessario però che esista un quadro di riferimento architetturale in cui i servizi che vengono sviluppati trovino una adeguata collocazione. Oltre al modello da fornire ai progettisti, servono una infrastruttura tecnologica e un piano di investimenti per la sua realizzazione.
La figura seguente mostra uno schema sintetico di architettura di riferimento, in cui vengono evidenziati i Service Consumers e i Service Providers insieme a tutti i servizi condivisi che comprendono quelli applicativi e quelli infrastrutturali.
Come usare la SOA Reference Architecture
Il primo passo per l’adozione della SOA Reference Architecture di BEA è la sostituzione dei generici tipi di componente descritti dal modello con i componenti specifici del cliente: per esempio, “Portali” può essere specificato come “Portale Risorse Umane” e “Portale Customer Service”. “Packaged Applications” può diventare “SAP” e “Oracle Financials”. “Atomic Business Activities” può comprendere “Emissione dell’ordine” e “Pagamento”.
L’azienda può anche identificare come i nuovi progetti si adattano allo scenario complessivo, per esempio mettendo a disposizione un processo di business condiviso “Aggiunta Nuovo Prodotto” o fornendo un data service “Cliente”.
Il risultato è una istanza concreta della SOA Reference Architecture – un modello specifico per quell’azienda che diventa la definizione formale della architettura SOA. Fornisce lo schema per classificare l’infrastruttura e i servizi condivisi; definisce le relazioni tra la SOA desiderata e l’architettura esistente. Specifica la visione architetturale e determina il percorso da seguire per la sua costruzione. Infine, serve come cruciale strumento di comunicazione e di verifica della conformità.
Oltre a focalizzare le risorse dello sviluppo nella creazione delle soluzioni, le aziende devono gestire i progetti che ne risultano. La SOA Reference Architecture può servire da modello per un singolo progetto così come per l’intera SOA.
Un architetto e il responsabile del progetto possono usarla per scomporre le funzionalità di business in un insieme di servizi, assegnare la responsabilità per ciascun blocco al gruppo di sviluppo più adatto, monitorare l’implementazione.
In questo modo si possono ottenere il parallelismo nello sviluppo dei componenti, l’eliminazione delle duplicazioni, una efficace attribuzione dei costi a diverse voci di bilancio.
Il white paper
La SOA Reference Architecture di BEA fornisce benefici di lungo termine alle aziende fornendo un modello per costruire una SOA di livello enterprise in modo scalabile.
La potenza di SOA è la sua flessibilità. Ogni azienda può adattare i suoi particolari asset IT al suo business specifico.
Tuttavia questa potenza è inutile senza controllo: è necessario un modello che indirizzi il lavoro e permetta di verificarne i risultati.
Usando una SOA Reference Architecture, le aziende possono stabilire quali servizi dovrebbero costruire e quando farlo.
Possono aumentare il parallelismo e ridurre le duplicazioni nel portafoglio dei progetti di sviluppo. Possono imporre una governance efficace basata su policy che applicano correttamente i principi generali a circostanze specifiche.
La chiave per ottenere questi benefici è la conoscenza del posto che ciascun progetto e ciascun servizio occupano nello schema più ampio della SOA a livello enterprise. Usando la SOA Reference Architecture, sia le persone di business che quelle dell’IT possono indicare con precisione il ruolo di ogni servizio esistente o proposto.
Le dipendenze, le mancanze e le duplicazioni appaiono evidenti. La pianificazione, la cooperazione e l’approvvigionamento diventano più semplici. Le aziende possono finalmente trasformare l’agilità in un processo gestibile. BEA ha tracciato la strada con una SOA Reference Architecture basata su anni di esperienza nel mondo reale.
Un white paper che espone in dettaglio il valore della costruzione di una SOA Reference Architecture può essere scaricato dal sito BEA, nella sezione SOA.
La struttura di consulenza di BEA offre diversi servizi – che saranno discussi in altri post su questo blog – mirati alla definizione di un’architettura di riferimento specifica per il cliente e alla sua realizzazione.
Nella versione di Guardian rilasciata agli inizi di Febbraio 2008 ci sono novità significative.
Durante lo scorso anno abbiamo avuto indicazioni da molti Grandi Clienti che ritenevano che l’auto installazione (auto-deploy) dell’Agente di Guardian fosse in contrasto con le policy di sicurezza e di auditing in essere.
Per queste ragioni abbiamo rimosso, a partire da Guardian 1.0.7, la funzione di auto-deploy, e di conseguenza l’Agente dovrà essere installato manualmente, ad esempio tramite la BEA WebLogic Console.
Nel prossimo futuro, a partire dalla release WLS 10.3, l’Agente Guardian sarà incluso direttamente in WLS Server e non sarà più necessario installarlo.
Per maggiori informazioni e per scaricare gratuitamente BEA Guardian cliccare QUI
Sviluppato come guida per il governo del Regno Unito, l’Information Technology Infrastructure Library (ITIL) è uno standard nato alla fine degli anni ’80 con lo scopo di offrire una serie di “best practice” per la gestione dei servizi IT, promuovendo un approccio di qualità al fine di ottenere maggiore efficacia nel lavoro e sempre più efficienza nell’utilizzo dei sistemi informativi.
Il crescente affermarsi sul campo di questo standard dipende dal riconoscimento e dall’adesione da parte di quelle organizzazioni che, in modo sempre maggiore, sono dipendenti dall’Information Technology, e che sono decise a soddisfare i loro scopi e le loro necessità di affari.
Questa dipendenza conduce alle necessità di servizi di qualità dell’IT sempre maggiori, qualità per la quale lo standard ITIL fornisce una serie di indicazioni da seguire.
Esso, infatti, descrive i processi, le attività, i ruoli e le responsabilità per poter gestire in modo flessibile l’organizzazione e i problemi che possono sorgere, al fine di migliorare la qualità dei servizi forniti e di rispondere alle esigenze del mercato, dei clienti e degli acquirenti. ITIL è supportato da uno schema di qualifica completo, da organizzazioni accreditate di training, e da strumenti di implementazione e di valutazione.
Questo insieme di “best practice”, in sostanza, non si presenta come una serie di rigide regole, ma più semplicemente come una traccia da adattare caso per caso a seconda delle necessità, dei bisogni, delle particolarità e delle caratteristiche dell’azienda. Lo standard può essere utilizzato:
-
nel settore pubblico – Governo centrale e locale, Autorità sanitarie e politiche
-
nel settore privato – Banche, Assicurazioni, Telecomunicazioni, Servizi Pubblici, Trasporti
-
dalle società IT – Fornitori di prodotti, Società di System Integration, Società di Outsourcing
La documentazione ITIL è suddivisa in più libri, che trattano ognuno un aspetto diverso della gestione dei servizi IT; sono tutti leggibili in modo indipendente, ma ovviamente presentano sempre concetti strettamente correlati tra di loro. I libri di cui la documentazione è composta sono i seguenti:
SERVICE SUPPORT :
assicura che il Customer abbia accesso ad appropriati servizi per il supporto di funzioni di business. I processi descritti sono: il Service Desk, l’Incident Management, il Problem Management, il Configuration Management, il Change Management e il Release Management.
SERVICE DELIVERY :
questa sezione riguarda il rilascio del servizio richiesto per permettere un supporto adeguato ai clienti. Vengono trattati i processi del Capacity Management, del Financial Management per i Servizi dell’IT, dell’Availability Management, del Service Level Management e dell’IT Service Continuity Management.
PIANIFICAZIONE PER IMPLEMENTARE IL SERVICE MANAGEMENT :
questa parte introduce all’utilizzo dell’ITIL in quanto fornisce una guida sull’allineamento dei bisogni di business all’IT e sulla valutazione dei livelli correnti di maturità del Service Management. Aiuta l’organizzazione ad identificare i punti di forza e di debolezza, permettendo di sviluppare i primi e di superare gli ultimi.
ICT INFRASTRUCTURE MANAGEMENT :
si occupa dei processi, dell’organizzazione e degli strumenti necessari per fornire un’infrastruttura stabile di IT e comunicazioni ed è la base per i processi di ITIL Service Management. Questa parte si occupa di Design & Planning, Operations e Technical Support.
APPLICATION MANAGEMENT :
fornisce un aiuto agli utenti, agli sviluppatori e ai manager del servizio per identificare quali applicazioni possono esser gestite da una prospettiva di service management.
SECURITY MANAGEMENT :
questa sezione si occupa della sicurezza dal punto di vista del fornitore del servizio, identificando come il Security Management si relaziona con l’IT Security Officer e come fornisce il livello di sicurezza necessario.
THE BUSINESS PERSPECTIVE :
si occupa di far comprendere ai manager il carico di business. Le questioni trattate includono il Business Relationship Management, il Partnership and Outsourcing, dei continui miglioramenti e sfruttamenti dell’informazione, Communication and Technology (ICT) per trarre vantaggio dal business.
La figura seguente mostra i processi che fanno parte dell’area “Service Support”
Ogni processo ITIL è a se stante nella sua definizione, ma per svolgere pienamente il suo scopo deve essere preso in considerazione con tutti gli altri.BEA Systems ha adeguato la propria struttura di supporto per essere in linea con le Best Practices ITIL, con particolare riferimento al Service Support, e inoltre richiede che i Support Account Manager che hanno la responsabilità dei Clienti di tipo Mission Critical siano certificati ai maggiori livelli ITIL. Come a dire: “al vostro servizio” con le nostre “migliori risorse”.
Per informarsi o saperne di più www.itsmf.it
Chiara Scarafiotti, ITIL Practitioner Support & Restore
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.
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
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.
Caffè con BEA 