Abilitare l’agilità del business è un imperativo strategico per le tecnologie informatiche. Una strada obbligata, se si vogliono perseguire i guadagni di efficienza e i recuperi di produttività indispensabili in un’economia globale sempre più competitiva. La sfida per l’It dell’impresa è di evolvere al più presto verso la realizzazione di una infrastruttura capace di servire, in tempo reale e con latenza zero, il flusso principale delle operazioni quotidiane connesse ai processi del business, di sollecitare e sostenere le decisioni strategiche del management e di inseguire con un adattamento continuo, l’evoluzione della cosiddetta ‘real time enterprise’ (Rte), che non smette mai di cambiare.
Concettualmente, l’architettura per le operazioni e decisioni real time non è nulla più di una combinazione di applicazioni (native od ospitate dalle varie piattaforme Erp, Crm ed Scm) in grado, col supporto del middleware, di offrire servizi o reagire ad eventi. I servizi saranno innescati da una richiesta diretta del client o da eventi esterni; saranno componibili nei server applicativi Soa (con architettura Service Oriented) e saranno capaci di richiamarsi l’un l’altro come sottoprocessi, passandosi dati indipendenti dalle applicazioni (metadati), per la regia di un Business Process Management d’impresa.
Questi sottoprocessi fondamentalmente si fondono fra loro (Business Process Fusion). Sicché, ad una molteplicità di eventi esterni, il sistema-impresa (servito da una tecnologia che, per quanto si è detto, possiamo definire ‘service-oriented, event driven e metadata-enabled’), reagirà come un insieme di processi ognuno dei quali è un’istanza di aggregazioni dal ‘pool’ dei sottoprocessi disponibili; garantendo un ‘through processing’ pervasivo dell’evento innescante.
Secondo Gartner un’azienda è, a un livello di base, tecnologicamente abilitata per operazioni real time se le sue applicazioni sono in grado di rispondere automaticamente a cambiamenti che si verificano in due o più applicazioni. E stima che ad un’impresa occorrano da tre a cinque anni per sviluppare le competenze necessarie a diventare una real time enterprise. Ma è piuttosto l’It come settore d’industria che ha ancora davanti a sé una lunga marcia per giungere a un tale obiettivo, non tanto per la maturazione delle tecnologie, ormai definite e in larga parte disponibili, quanto per il consolidamento degli standard che li governano.
La figura 1 fotografa lo stato dell’arte al 2004: su un processo di maturazione di 15 anni, siamo circa al settimo anno. Sono oramai mature le tecnologie per Servizi (evolutesi dal Message Oriented Middleware alla scomposizione in componenti elementari nei server e ai servizi Web); sono mature, anche se tuttora in convergenza, le tecnologie Eai (Integration Broker e Portali nelle Application platform suite); sono definite e disponibili anche quelle per il Business Process Management (con aree di frontiera come Business Activity Management e Complex Event Management). Lo spaccato al 2004 delle tecnologie sottese dalla curva è anche indicativo del livello di effettiva penetrazione del mercato mainstream.
Il cammino verso la Real Time Enterprise
Fonte: Gartner
Servizi, funzioni e processi: i mattoni della business process fusion
Nella progressione delle tecnologie che rendono agile il business (vedi ancora la figura 1) i due trend di fondo sono integrazione e workflow; che alla fine agiscono sui componenti a livello elementare, dato che insiemi di componenti si combinano in servizi.
Un primo livello di standard è quindi quello che consente l’aggregazione di componenti elementari in servizio, conferendogli indirizzabilità da qualunque applicazione, dunque riusabilità. Insiemi più o meno complessi di componenti (sottofunzioni) si aggregano poi dinamicamente fra loro a formare una funzione: è l’integrazione delle applicazioni d’impresa (Eai), cui presiede un secondo livello di standard per Application e Integration Server (oggi confluiti nelle Aps, Application platform suite). Infine, insiemi di sottofunzioni si richiamano fra loro a formare un processo, regolato da un workflow aziendale, per il quale serve un terzo livello di standard. La grande importanza degli standard del secondo e del terzo livello sta nel fatto che estendono le doti di indirizzabilità, granularità e riusabilità/componibilità rispettivamente delle sottofunzioni interapplicative e dei sottoprocessi concatenati dal workflow aziendale.
La tabella che pubblichiamo, da noi realizzata elaborando informazioni provenienti da diverse fonti e che ha intenti più indicativi che esaustivi, indica per i tre livelli citati (servizio, funzione e processo) quali standard coprano quali tecnologie, e da quali organizzazioni (Standard body) o comunità siano regolati.
Il bicchiere è, al solito, mezzo vuoto e mezzo pieno. In negativo sta il fatto che il dispiegamento su base open standard (specie di terzo e secondo livello, nonché dei servizi Web “alti”) è condizionato da due fattori inibitori: da un lato il sistema di rapporti fra Standard body e vendor partecipanti (con annessa politica che cronicamente lo affligge); e dall’altro il riorientamento organizzativo necessario all’It a realizzare il dispiegamento di una Real time enterprise. In positivo, almeno per il secondo punto, c’è il fatto che l’It dell’azienda utente ha così l’opportunità di cominciare a pensarci ed organizzarsi per tempo.
Standard body e Vendor It, un complesso sistema
Uno standard oggetto di competizione fra più fornitori di tecnologia tenderà a frammentarsi sotto la spinta di ‘differenziatori’ che cercano di catturarlo: sembra un corollario della legge di Murphy, ma la riprova è il paradosso che Soap e Wsdl (come a suo tempo è accaduto per Ip o Http) si sono stabilizzati in pratica prima che nascessero gli enti che li gestiscono. E’ un fatto che sui protocolli ‘alti’ dei servizi Web (sicurezza, controllo processo…) ci sono numerosi padrini: ws-i.org (per esempio, per bpel4ws); bpmi.org (esempio: bpel) e oasis.org (esempio: ebXml, protocollo ‘alto’ preesistente ai servizi Web). Ma i veri padroni, ci si perdoni il gioco di parole, sono i vendor che contano, in lotta per dominarne il valore.
Non da oggi un inibitore è l’interoperabilità limitata fra le due architetture di rete: J2EE di paternità Sun, e .Net di Microsoft. Ma c’è un segnale fortemente incoraggiante l’interoperabilità e portabilità fra Aps: l’accordo tra Sun e Microsoft dello scorso aprile e la costituzione di www.java.net (vedi su ZeroUno n.272), che si focalizza sull’accordo dal punto di vista della comunità Java.
Per quanto riguarda l’interoperabilità delle funzioni nei confronti di una vera Enterprise application integration, Meta cita una serie di vendor impegnati su modelli a base Xml che avviluppano le Aps offerte. ‘Primus inter pares’, Sap con NetWeaver, definita “piattaforma applicativa aperta all’integrazione” e il relativo modello funzioni e metadati (Composite Application Platform). C’è poi l’atteso Longhorn, completo di un Microsoft Business Framework che per il 2006 avvolgerà Windows in modelli Xml: Avalon per la presentazione, Indigo per la comunicazione e WinFS per lo storage (di quest’ultimo però è stato annunciato ad agosto uno slittamento a data imprecisata). Sono impegnati su piattaforme applicative aperte anche Siebel, con l’Universal Application Network, e Bea con il recente annuncio di Beehive (vedi articolo in Update), mentre è lecito attendersi a breve le analoghe soluzioni di Ibm e di Oracle.
Per Meta questo trend verso piattaforme a base Xml incapsulanti le Application platform suite è positivo, anche se, inevitabilmente, innalza la dipendenza dell’utente nei confronti del vendor sulle funzioni e i metadati supportati. Consiglio di Meta: oltre a far pressione per avere un’interoperabilità fra modelli di business, investire in skill d’integrazione tra questi modelli stessi.
Un ultimo problema è dato dalla competizione in atto fra le suite di Business Process Management: sono addirittura 70 i vendor di suite Bpm, e anche se è prevedibile una drastica sfoltita entro qualche anno sono sempre tanti. L’approccio suggerito da Meta è di restringere la rosa dei vendor attraverso un’analisi preliminare dei requirement per il Bpm aziendale che classifichi degli scenari-utente (Use Case scenario) riconducibili a quattro situazioni fondamentali (o a loro combinazioni, come appropriato): case management; form-driven workflow; content collaboration; navigazione guidata.
