La fusione dei processi dell’impresa grazie a SOA (Parte Prima)
In questi giorni di attenta revisione di tutte le spese It, dobbiamo continuare a domandarci quale sia il contributo dell’It alle capacità complessive dell’impresa? Molti dei processi operativi fondamentali sono stati già automatizzati, per esempio attraverso l’implementazione di sistemi Erp (Enterprise Resource Planning) e Scm (Supply Chain Management). Spesso sono necessari miglioramenti, ma si tratta di rendere più semplice l’attività dell’impresa, non di aggiungere nuove capacità. Gli investimenti in It possono essere utilizzati per realizzare nuove applicazioni che, normalmente forniscono all’impresa solamente limitate funzioni aggiuntive che risolvono necessità di nicchia. A questo punto, bisogna domandarsi dove sia maggiormente necessario il supporto It. Attualmente, due dei problemi maggiori con i quali si confrontano la maggior parte delle imprese sono la pressione competitiva per muoversi verso l’impresa in real time (Rte -Real Time Enterprise) e la capacità di raggiungere nuovi livelli di agibilità e di adattabilità. Lo scopo della Rte è di ridurre in modo significativo l’intervallo di tempo tra il momento in cui avviene un evento e il completamento delle attività richieste all’impresa per rispondere all’evento stesso. Un esempio tipico può essere quello della richiesta di un preventivo di polizza assicurativa, che normalmente attiva un processo di elaborazione batch notturno. In una Rete, questa richiesta verrebbe elaborata subito, dando luogo a una risposta immediata. Molte imprese non avevano questa necessità cinque anni or sono, ma la pressione competitiva attuale le spinge sempre di più verso una visione Rte. Bisogna però considerare che l’implementazione di una Rte non garantisce di per sé adattabilità e agilità all’impresa. La Rte influisce sulla velocità di completamento dei processi dell’impresa, mentre agilità e adattabilità riguardano il tempo necessario per l’attivazione di nuovi processi o per modificare quelli esistenti, in modo da reagire ai cambiamenti delle condizioni di mercato. Secondo Gartner, un ingrediente fondamentale per realizzare Rte, agilità e dattabilità è costituito dalla fusione dei processi. Questa è la loro definizione di fusione: “La fusione dei processi dell’impresa consiste nella trasformazione delle attività dell’impresa, da raggiungere integrando preventivamente i processi autonomi per fornire una nuova prospettiva alle capacità del management”. Cerchiamo di vedere quello che questa definizione tenta di esprimere. Il risultato della fusione dei processi dell’impresa è la trasformazione delle sue attività, in modo da allinearle con i principi della Rte, dell’agibilità e dell’adattabilità. In altre parole, le attività dell’impresa verranno condotte in (quasi) real time, saranno rapide da implementare e semplici da modificare. Questa trasformazione è ottenuta integrando processi multipli, precedentemente isolati, che attraversano i confini organizzativi e manageriali interni dell’organizzazione. Questa integrazione crea un nuovo processo interconnesso, che unisce (fisicamente) processi connessi strettamente ma (in termini di business) dipendenti. I processi così interconnessi consentono lo sviluppo di nuove capacità di management; per esempio, l’impresa adesso può offrire soluzioni che risultano dalla combinazione di parecchi prodotti e/o servizi. Altri esempi comprendono l’integrazione dei processi di business, dalla formazione del prezzo all’acquisizione dell’ordine e alla fornitura del servizo nel settore delle telecomunicazioni, oppure, in quello manifatturiero, l’integrazione dei processi dalla ricerca alla progettazione, costruzione e marketing del prodotto La fusione e l’Architettura Orientata al Servizio Come può l’It supportare la fusione dei processi dell’impresa? La fusione richiede un ‘architettura It che vada oltre un insieme tradizionale di applicazioni. L’architettura deve essere orientata alla granularità del servizio all’impresa, piuttosto che a grandi applicazioni che implementano una quantità di funzioni dell’impresa – questi sono gli aspetti fondamentali. Una volta che la logica dell’impresa è stata affrontata sotto forma di servizi, allora è possibile comporre questi servizi in processi interconnessi. Questo ci porta a considerare due importanti concetti che ultimamente hanno raggiunto una grande popolarità: Service Oriented Architecture (Soa) e Service Oriented Development of Applications (Soda), ovvero sviluppo di applicazioni orientate al servizio, all’interno di un’architettura It orientata completamente al servizio. L’architettura Soa sta guadagnando in popolarità soprattutto perché è vista dall’impresa come la chiave per raggiungere agilità operativa, migliore qualità di servizio e un minore costo dell’infrastruttura. Negli ultimi due anni, la maggior parte delle società della lista delle prime 1.000 di Fortune hanno iniziato ad adottare l’approccio Soa, applicandolo sia per lo sviluppo di nuove applicazioni sia per l’integrazione di quelle esistenti, oppure in entrambi i casi. Molti analisti del settore affermano che queste società adesso siano pronte per il passo successivo – ovvero per un’adozione più sistematica e un allargamento delle pratiche orientate al servizio. Il concetto di Soa non è completamente nuovo e oggi finalmente è arrivato il suo tempo. Soa prescrive servizi dell’impresa strettamente interconnessi, minimizzando le interdipendenze tra i fornitori e gli utenti dei servizi. Richiede interfacce standard, protocolli di accesso standard e una separazione delle interfacce dall’implementazione. Questo può sembrare familiare – anche tecnologie precedenti come quella degli oggetti e componenti distribuiti propugnavano idee simili. In aggiunta, molte imprese hanno sviluppato applicazioni orientate ai servizi usando proprio queste ultime tecnologie. Ma allora, qual è il significato reale di Soa e perché le cose saranno diverse questa volta? Confrontiamo gli aspetti di un’ architettura orientata ai servizi precedente l’era dei Web Services, con l’approccio odierno. Un servizio presenta interfacce ben definite e segue la nozione di incapsulamento, cioè l’implementazione del servizio è separata dall’ interfaccia e quindi rimane nascosta per il client. Le interfacce dei servizi vengono descritte utilizzando un meccanismo formale. Questi aspetti di un ambiente Soa possono essere trovati nella Common Object Request Broker Architecture (Corba) sotto forma di Interface Definition Language (Idl), così come nel Distributed Component Object Model (Dcom), sotto forma di Microsoft Idl (Midl). Anche J2ee prescrive l’uso del concetto di interfacce ben definite che vengono presentate ai client da Enterprise Java Beans, anche senza l’uso di qualche genere di Idl. Anche se in termini assoluti l’architettura Soa attuale non prescrive l’uso di una specifica tecnologia di implementazione, da un punto di vista pratico i Web Services sono la tecnologia da preferire. In questo caso, le interfacce dei servizi vengono definite usando il Web Services Definition Language (Wsdl), che costituisce una grande differenza nei confronti di Corba, Dcom e J2ee, secondo due aspetti. In primo luogo, Wsdl è divenuto uno standard accettato universalmente che trascende le piattaforme tecnologiche (per esempio, Java, C#, Windows, Unix ecc.), così come è indipendente dalle linee di prodotto dei venditori di software, compresi i forti concorrenti come Microsoft e Sun. Nessuno degli standard precedenti ha mai raggiunto questo stato; hanno sempre rappresentato soluzioni isolate, affette da problemi di portabilità e di interoperabilità. Il secondo e probabilmente più importante elemento di differenziazione è rappresentato dal fatto che l’architetttura Soa di oggi prescrive interfacce meno rigide e quindi più affidabili. Nel caso delle tecnologie precedenti, un piccolo cambiamento nell’interfaccia di un servizio è sufficiente per bloccare il client che lo stia utilizzando. Questo avviene perché non abbiamo a che fare realmente con l’interfaccia del servizio, ma piuttosto con una procedura di chiamata e riconoscimento che il client deve seguire per invocare un metodo, oppure un oggetto o un componente. La più piccola modifica in questa sorta di firma di chiamata rende quest’ultima invalida. Inoltre, gli oggetti sono fortemente caratterizzati, i caratteri sono sottoposti a verifica e gli oggetti vengono identificati mediante la firma di chiamata, per esempio, mediante gli identificatori di classe oppure di oggetto. In altre parole, applicando questo piccolo cambiamento si crea un tipo di oggetto completamente nuovo. Con i Web Services è possibile espandere l’interfaccia e il client può semplicemente ignorare i nuovi elementi. Per esempio, se un Wsdl per piazzare un ordine comprende una sezione per l’indirizzo del cliente, questa può essere ingrandita aggiungendo, per esempio, il numero del telefono. Poiché Wsdl prescrive uno standard, self-describing service invocation format, il client può determinare quali elementi deve prendere in considerazione e quali deve ignorare. Tuttavia, bisogna fare attenzione. Spesso i Web Services vengono usati con invocazioni del tipo Remote Procedure Call (Rpc), mentre il client fa riferimento a un sistema di generazione di Rpc che traduce la chiamata in un messaggio basato sul Simple Oriented Access Protocol (Soap). In questo caso, la modifica dell’interfaccia del Web Service richiederà un lavoro addizionale. Come possiamo vedere da quanto abbiamo detto fino a questo punto, le interfacce dei servizi in un ambiente Soa basato sui Web Services posseggono alcune importanti qualità che le distinguono da altre tecnologie. Infatti, forniscono flessibilità per le modifiche, stretto collegamento tra fornitore e utente del servizio, così come l’indipendenza dalla tecnologia; un insieme che comporta un alto grado di interoperabilità e di portabilità Queste sono tutte le caratteristiche fondamentali per un’mplementazione efficiente della fusione dei processi dell’impresa. Se uno di questi processi è costituito da un insieme di servizi (invece che da applicazioni monolitiche o da oggetti rigidi), allora possiede queste qualità e sarà molto più facile combinarlo con altri processi per creare un nuovo processo integrato. Segue nel mese di aprile….