BLOOM! frammenti di organizzazione
Pubblicato in data: 09/08/2010

 

L'INFORMATION & COMMUNICATION TECHNOLOGY AL SERVIZIO DELL'AZIENDA. APPUNTI IN MERITO ALLO SCENARIO EMERGENTE

di Francesco Varanini

Premessa
E' importante per tutti riflettere sullo scenario dell'I&CT, ovvero sugli strumenti software e in genere dei supporti informatici che oggi possono essere messi a disposizione di chi lavora e chi è chiamato a prendere decisioni.
E' importante per i manager, per chi si occupa professionalmente di Risorse Umane, e anche per chi in azienda si occupa professionalmente di Informatica. Spesso, proprio perché siamo professionisti di qualcosa, ce ne sfugge la lettura critica. E proprio perché viviamo immersi in un mondo, ci risulta difficile cogliere il trend.
Va ricordato che il ruolo di chi si occupa di Informatica in azienda è enormemente cambiato negli ultimi dieci o venti anni. Da indiscutibili ed indiscussi sacerdoti di un sapere chiuso e predefinito si è passati ad essere fornitori di servizi 'su domanda'. Da garanti della certezza del dato si è passati ad essere 'conservatori e diffusori di conoscenze'.
Il ruolo è cambiato con le tecnologie: da un'informatica che si riassumeva in una unica cultura, in una univoca visione del mondo, si è passati alla compresenza di diverse culture informatiche.

Origine di questo testo
Nel maggio scorso, nel corso di un articolato intervento formativo presso una azienda del settore I&CT, ho tenuto un seminario sul tema 'Lo scenario tecnologico'. Mi sono rifiutato di usare slides Power Point. In cambio, ho promesso di scrivere un testo sugli argomenti trattati durante la giornata. Rileggendolo, mi pare interessante anche per i lettori di Persone & Conoscenze.
A proposito del rifiuto ad usare Power Point, ho scritto ai partecipanti al percorso formativo alcune parole che di seguito trascrivo.
“E' utile sperimentare accessi alla conoscenza diversi. Proprio perché normalmente usate Power Point, vale la pena di sperimentare un approccio differente. Un incontro formativo è una buona occasione per 'fare cose diverse'.
Comune vi interessasse un ragionamento più filosofico sul 'perché talvolta è meglio non usare  PowerPoint', potete leggere questo post: http://diecichilidiperle.blogspot.com/2009/08/per-una-fenomenologia-di-microsoft.html
Vi propongo quindi di leggere queste 6 pagine. Se comunque volete una presentazione in Power Point, ne trovate una a questo link: http://www.slideshare.net/fvaranini/francesco-varanini-l-ict-come-leva-strategica-del-business
Lì, nelle slide 112 e seguenti, troverete modo di approfondire quanto scrivo a p. 5, paragrafo 'La nuova fabbrica del software' , a proposito del paradigma Zachman e del paradigma Bohem (l'Extreme Programming e l'Agile Software Development possono essere considerati versioni particolari del paradigma Bohem)”.

SAP
SAP è il caso esemplare di una cultura informatica e di un approccio al software. Vale la pena di riflettere oggi su ciò che caratterizza l'approccio SAP, proprio perché lo scenario SAP è in via di mutamento, e perché il 'modello SAP' ha cessato di essere un punto di riferimento per chi sviluppa e gestisce sistemi informativi aziendali.
SAP fornisce, prima di software applicativo, un modello dei dati ed una architettura complessiva del sistema informativo. In senso più lato, propone ed impone una 'filosofia'.
SAP offre la promessa di garantire la migliore organizzazione delle informazioni. Allo stesso tempo SAP si presenta come garanzia di efficienza: adeguando i processi aziendali a ciò che SAP propone, l'impresa sarà indirizzata verso l''organizzazione perfetta'.
La 'filosofia' permane anche nelle ultime versioni di SAP -SAP ECC (Erp Central Component) 6.0-. Tecnologicamente non si tratta più di un sistema integrato, ma di una 'collezione' di applicazioni. Ma resta l'idea di una soluzione complessiva. Anche dove si acquisti e si usi un unico modulo di SAP (finanza, risorse umane, ecc.) resta l'idea che il software è per definizione, per sua stessa natura, adeguato e completo, rispondente alle specifiche, ai requirement e alle aspettative di chi si occupa di business.
Così chi è cresciuto professionalmente in una cultura SAP e ha lavorato prevalentemente con SAP si trova ad essere suo malgrado abituato ad affidarsi alle implicite potenzialità dello strumento, e non considerare compito proprio la costruzione di un legame tra processi, business e sistemi informativi: perché il legame tra processi, business e sistemi informativi ì 'già dato' da SAP. Chi è cresciuto professionalmente in una cultura SAP trova difficoltà a pensare come proprio compito la scelta del modello dei dati e dell'architettura complessiva del sistema informativo.

SOA
Si può ragionevolmente sostenere che il ricorso a SAP, motivato negli anni '80-'90, è molto meno motivato oggi. La Service Oriented Architecture  (SOA) è, in sostanza, un SAP senza SAP. Offre come SAP il vantaggio dell'interscambio dei dati tra applicazioni 'verticali'. Ma SAP parte dall'idea di un modello già dato, proposto come soluzione ottimale, mentre l'architettura SOA è pensata in partenza come supporto alla strategia della singola impresa. SAP offre un modulo per ogni funzione aziendale, quindi il SAP implementato in una data azienda è un insieme di moduli SAP, mentre l'architettura SOA è una 'collezione' di applicativi verticali diversi, prodotti da softwarehouse differenti, ma in grado di funzionare insieme per via di uno strato di software –un middleware– che  garantisce un sistema di regole comune. Definite le regole di interfacciamento con il middleware, è possibile sostituire i moduli verticali con altri moduli orientati allo stesso scopo funzionale.

Architettura
Mentre con  il SAP l'architettura è data, 'embedded' nel sistema informativo fornito, nella logica SOA ogni azienda disegna la propria architettura in funzione delle proprie strategie e del proprio business. Emerge così la centralità dell'architettura e l'importanza dell'architetto.
SAP propone soluzioni fondate sull'omogeneità, ma l'omogeneità delle applicazioni finisce  per risultare nella pratica impossibile, e comunque sottopone l'azienda al 'comando esterno' del fornitore che offre i componenti omogenei.  La scelta aziendale per la definizione di una propria architettura, così come la logica di sviluppo di tipo SOA, si fondano invece sul dato di fatto della disomogeneità. I sistemi informativi sono per loro natura complessi. 
L'architettura è la ricerca di un ordine nel caos. E' la definizione di 'regole minime necessarie', la definizione di standard di interfacciamento e di interoperabilità.
L'architettura può essere definita come segue: un insieme di decisioni significative sull'organizzazione di un sistema software, sulla selezione degli elementi strutturali e sulle interfacce di cui il sistema è composto, insieme con i comportamenti così come specificati nelle collaborazioni tra questi elementi.

Servizi
SOA è uno stile architetturale basato sul concetto di servizio. Il servizio rappresenta quindi l'elemento strutturale su cui le applicazioni vengono sviluppate. Occorre quindi definire cosa si intende per servizio.
Un servizio è, in prima analisi, una funzionalità di business realizzata tramite un componente che rispetta un'interfaccia.

I Servizi sono ricercabili e recuperabili dinamicamente.
Chi necessita di un servizio deve essere in grado di ricercarlo tramite l'interfaccia e di invocarne l'esecuzione, nel momento in cui ciò serve. La richiesta delle funzionalità e la fornitura della funzionalità sono disaccoppiate. Ciò rende possibile cambiare l'entità che esegue il servizio in maniera trasparente rispetto al chiamante.

I Servizi devono essere autocontenuti e modulari.
I servizi ben costruiti sono stateless. L' 'invocazione del servizio' è gestito dal middleware, e non riguarda in nessuna misura il fornitore del servizio. Ogni servizio è indifferente all'esistenza di altri servizi e allo stato di altri servizi. I servizi non sono costruiti in base a presupposizioni sul loro uso, ma si definiscono al momento, in risposta ad  una richiesta.

I Servizi si propongono tramite interfacce esplicite e indipendenti dall'implementazione
Deve essere possibile invocare servizi in maniera indipendente dal linguaggio e dalla piattaforma. Questo si può ottenere definendo delle interfacce che possono essere invocate tramite protocolli compresi da tutti.

I Servizi sono 'debolmente accoppiati' ('loosely coupled')
L'architettura è orientata ad avere accoppiamenti deboli, cioè un numero di dipendenze tra le entità basso e ben controllato. Questo stile architetturale si oppone alle architetture tradizionali, che si presentano come sistemi formati da componenti fortemente accoppiati: ne sono esempio sistemi legacy è più rigido e difficilmente modificabile.

I Servizi hanno un'interfaccia distribuita e sono accessibili in maniera trasparente rispetto all'allocazione
Un servizio con un'interfaccia distribuita può essere pubblicato sulla rete, diventando così disponibile ai componenti che lo vogliano utilizzare. L'accesso tramite la rete permette inoltre di avere trasparenza rispetto alla reale allocazione del servizio.

I Servizi hanno preferibilmente un'interfaccia a 'grana grossa' ('coarse-grained')
Un servizio che corrisponda ad un'unica chiamata e un'unica esecuzione complessa ha vantaggi rispetto a una serie di chiamate a tanti servizi più piccoli. In questo modo infatti si riducono le chiamate remote (tipicamente poco efficienti) ed è più semplice gestire problematiche legate al fallimento della chiamata.

I Servizi sono essere componibili
Dal punto di vista SOA le applicazioni sono aggregazione di servizi. E' quindi importante disegnarne le interfacce in modo che corrispondano a funzioni di business riusabili, ovvero a servizi indipendenti e autocontenuti.

Ubiquitous, Seamless, Cloud Computing
E' terminata l'epoca dei sistemi informativi 'chiusi'. Il SAP, nella sua forma tradizionale ed originaria, possiamo dire fino a SAP ECC, è il culmine del sistema informativo chiuso. Ogni sistema informativo aziendale ha la stessa forma, la stessa logica, la stessa articolazione interna, ma ogni azienda detiene le proprie informazioni. 
Le diverse aziende possono scambiarsi informazioni, ma domani l'idea di informazione 'proprietaria', e quindi protetta, riservata,
Negli Anni Novanta, e poi in misura maggiore nell'ultimo decennio, le cose sono mutate radicalmente.

The uncertain promise of computing that is foolproof, invisibile and everywhere

It is increasingly painful to watch Carly Fiorina, the boss of Hewlett-Packard (HP), as she tries to explain to yet another conference audience what her new grand vision of “adaptive” information technology is about. It has something to do whit  “Darwinian reference architectures”, she suggest, and also whit “modularising” and “integrating”, as well as whit lots of “enabling” and “process”. IBM, HP’s arch rival, is trying even harder, whit a marketing splurge for what  it calls “on-demand computing”. Microsoft’s Bill Gates talks of “seamless computing”. Other vendors prefer “ubiquitous”, “autonomous” or “utility” computing. Forrest Research, a consultancy, likes “organic”. Gartner, a  rival, opts for “real-time”.
(Tratto da “Future of computing. The next big thing?”, The Economist, January 17th, 2004)

Seamless computing
Possiamo dire che è mutato paradigma. Oggi esiste un unico tessuto di dati, al quale tutti partecipiamo, un tessuto privo di cuciture, seamless. Un tessuto di dati privo di confini definiti a priori. Il confine viene 'segnato' di volta in volta, a seconda del punto di vista: possono considerare una immagine della mia impresa che 'tiene dentro' le informazioni prodotte dai fornitori, e/o i clienti, e riguardante i fornitori e/o i clienti, oppure ima immagine dell'organizzazione che 'ritaglia' nello sconfinato tessuto dei dati, solo i dati prodotti da coloro che lavorano all'interno dell'azienda.
Di volta in volta è possibile costruire, a partire da questo tessuto, sistemi informativi diversi.

Cloud computing
E' un modello ibrido di sfruttamento delle risorse offerte dalle reti di computer, Internet principalmente, che va oltre lo schema client/server, che ha dominato gli anni '80 e -nonostante l'affermazione di Internet- anche gli anni '90. La premessa basilare consiste nell’assumere che in questa architettura i data service (servizi hardware) e le funzionalità offerte (servizi software) non sono più 'diffusi' sui singoli computer connessi in rete, ma invece risiedono prevalentemente sui server web (le ‘nuvole’).

Saas (Software as a Service)
E' il modello di distribuzione del software applicativo coerente con il Cloud Computing. Il software applicativo non è più caricato sulle macchine degli utenti, o su un server locale, ma è messo a disposizione, via Internet, da un qualsiasi service collocato in un qualsiasi luogo (Ubiquitous Computing).
Questa scelta è resa possibile dalla sostituzione generalizzata del tradizionale desktop Windows con un desktop fornito via Web, e costituito da un browser privo di speciali plug in (quindi Explorer o Firefox in versione standard).
Date queste condizioni cambiano le strategie di sviluppo, cambia il modo di lavorare nella 'fabbrica del software' e cambiano le pratiche di rilascio.

La nuova 'fabbrica del software'
Nel paradigma dato da tutti per scontato fino all'inizio degli anni '90 del secolo scorso, ma in grande misura ancora oggi adottato, la logica di base è taylorista e fordista: il lavoro di sviluppo è assoggettato a un piano definito a priori. Le singole attività sono dettagliatamente descritte in una Work Breakdown Structure (WBS, Struttura Analitica di Progetto). L'attività di sviluppo è quindi parcellizzata e scomposta in microattività. Chi lavora allo sviluppo non sa nulla del servizio che dovrà essere offerto al  cliente, la sua attenzione è concentrata sull'attività tecnica che deve svolgere.
Rappresentazione esemplare del progetto di sviluppo così inteso è la matrice di Zachman.
In questo paradigma, particolarmente critico è il passaggio tra sviluppo e 'esercizio': la 'messa in produzione' di un software passa attraverso un roll out costituito da attentissimi collaudi, caricamento di software su ogni stazione di lavoro, addestramento degli utenti. La modalità più conveniente prevedeva un test con alcuni utenti pilota e poi un rilascio contemporaneo presso tutti gli utenti (Big Bang).
Nel nuovo paradigma la nozione di release perde importanza, fino a scomparire. La fabbrica del software lavora migliorando progressivamente il codice. Appena il software, anche con funzionalità minime, può essere usato, è messo a disposizione degli utenti. Gli utenti, con i loro commenti e suggerimenti, partecipano allo stesso processo di sviluppo. Questa modalità si afferma già negli anni '80 del secolo scorso, con la definizione di prototyping, avendo come modello di riferimento più interessante la spirale di Boehm (1988).
La logica di sviluppo parcellizzata, scomposta scientificamente in singola attività, è da questo momento superata. Ogni singola funzionalità è rilasciata già allo stato prototipale e affinata in piena trasparenza, in sinergia con l'utente/cliente.
Cade il confine della fabbrica del software - in una logica open source, partecipa allo sviluppo chiunque sia interessato. Viene meno la sequenza raccolta  dei requirement-analisi-sviluppo. La sequenza è sostituita da un circolo virtuoso (vedi spirale di Boehm). Il ciente/utente partecipa a tutti gli effetti allo sviluppo, non solo segnalando disfunzioni, ma indirizzando lo sviluppo. La partecipazione allo sviluppo dell'utente è sia esplicita -può cioè tradursi in esplicite indicazioni e suggerimenti e commento al software rilasciato- che implicita.
Si arriva così al software in versione beta permanente. La versione beta è una versione di prova di un software non definitivo, già testato dagli esperti, che viene messo a disposizione anche dei meno esperti. Nel nuovo paradigma, la versione beta viene messa subito  in esercizio, a disposizione di tutti gli utenti. Gli stessi comportamenti dell'utente -non solo la richiesta di informazioni, ma già in sé l'uso delle funzionalità rese disponibili- guidano nello sviluppo.

System Integration
Il 'sistema' è una aggregazione di sottosistemi cooperanti. Essendo tramontata la speranza implicita in SAP -sottosistemi nativamente orientati alla cooperazione-, ed essendo impossibile riassumere i sistemi informativi operanti in una azienda a una unica logica SOA, appare evidente la centralità della System Integration. Tramite System Integration si garantisce -accettando la complessità e la ridondanza- la complessiva efficacia. La System Integration garantisce il 'collante' (glue).
La System Integration rende importante la presenta dell'architetto. I concetti di 'System Integration' e di 'Architettura' tendo a convergere: l'Architettura è una System Integration consapevolmente vissuta, e legata ad una strategia
Allo stesso tempo, possiamo intendere la System Integration come 'nuova fabbrica del software': più progettare ex novo, si incollano (glue) e accoppiano (coupling) sistemi esistenti, di natura diversa: sistemi informativi legacy, già esistenti in casa, sistemi prodotti  da sosftwarehouse diverse,  sistemi di clienti  e fornitori ecc.

Ubiquitous computing
Come recita un azzeccato slogan della madre di tutte le compagnie telefoniche, l'AT&T: “Be there here” ('Sii lì qui'). Il telefono è non a caso la prima tecnologia che crea un non-luogo -appunto: un mondo virtuale- nel quale si situa il nostro colloquio con l'interlocutore.
Tramite l'uso di computer, ci muoviamo oggi nel ciberspazio. L'idea di Cyberspace esce nel 1984 dalla penna di William Gibson, autore di fantascienza. Il ciberspazio è l'universo parallelo creato e alimentato dalle reti globali di comunicazione via computer. Ogni computer connesso può entrarvi, da ogni luogo, senza limiti, da un grattacielo di New York o da uno scantinato di Calcutta o da una barca ai Caraibi o dalla stanza nella quale sto scrivendo.

Semantic Web
Il World Wide Web pensato originariamente attorno al 1990 da Tim Bernes-Lee non era solo fatto di 'raccolte' di pagine html. Si pensava invece a 'oggetti di conoscenza' loosely coupled, assemblati 'su domanda' (on demand) in modo di volta in volta diverso. Gli 'accoppiamenti strutturali' non sono più definiti da un modello dato a priori (da model), ma sono costruiti a fronte di una esigenza emergente. Il Semantic Web organizza la conoscenza in funzione di questa esigenza. Ogni informazione è accompagnata da metainformazioni (metatag) che la descrivono, e che rendono possibili i diversi accoppiamenti. Al linguaggio di base, Html, nato per costruire pagine statiche, si sostituise l'Xml, metalinguaggio di descrizione degli oggetti.
Le metainformazioni servono alla costruzione di architetture virtuali -un data base 'virtuale' è fatto sia di tradizionali relazioni predefinite tra entità, sia di 'puntatori' xml-. E servono anche a rendere possibile il funzionamento dei 'motori di ricerca'. 

Data Mining, Business Intelligence, Search Engine, KDD
I sistemi informativi aziendali rispondono, in ultima analisi, al bisogno di Business Understanding. Ma esistono modi diversi di 'conoscere il business'. Ricordiamo il senso del termine business: essere indaffarato, occupato, intento a fare qualcosa. Chi 'fa business' si attende che i sistemi informativi non indichino solo come seguire una procedura, un 'modo di fare le cose' definito nel passato. Il contributo più ricco è sostenere l'azione, e la tensione verso gli obiettivi, 'in questo momento', di fronte a situazioni nuove, sconosciute.
Possiamo dire che il SAP, nella sua conformazione originaria, è il culmine dei sistemi informativi orientati a garantire il rispetto di procedure.
Mentre SAP si affermava, emergeva un trend differente. I software gestionali, prendiamo sempre ad esempio il caso esemplare, SAP, propongono agli utenti  query già definite, incroci di dati già predisposti. Ci si può forse contentare dell'informazione così organizzata se si svolgono attività esecutive. Ma il manager ha bisogno di qualcosa di più.
Né possiamo limitarci a guardare alle informazioni così come ce la rende disponibile una buona architettura SOA, o una buona System Integration.
Molte conoscenze utili a 'fare business' sono 'nascoste nei dati', per estrarle non sono sufficienti le query definite a priori. Il manager ha bisogno di strumenti  che aiutino a muoversi nell'incertezza, di fronte a situazioni nuove e sconosciute. Per far questo deve lavorare per tentativi ed errori, per simulazioni, sperimentando diverse soluzioni. Così dalla fine degli anni '80 il computer arriva sul tavolo del manager.
Il primo approccio del manager all'uso personale e 'creativo' dei dati, è l'uso di uno Spreadsheet, caso esemplare Excel. Ma Excel lavora su un insieme di dati limitato. Pensiamo di poter lavorare con query 'inventate' al momento, frutto dell'esigenza presente, pensiamo di poter lavorare, per simulazioni e per tentativi ed errori, su masse sterminate di dati, magari su tutti i dati di cui l'azienda dispone, o anche 'mischiando' dati aziendali con dati di altra provenienza. La conoscenza che aiuta ad affrontare la situazione presente, è frutto di nuove connessioni tra i dati, connessioni che non erano state previste.
Questo è il campo del Data Mining, della Business Intelligence. Si tende a parlare oggi di KDD:  Knowledge Discovery and Data Mining (o Knowledge Discovery in Databases). Nel KDD agli strumenti di Business Intelligence si affiancano i Search Engine (i 'motori di ricerca'), strumenti di Information Retrieval a partire dall'enorme massa di informazioni non strutturate accessibili via World Wide Web.
I software di Business Intelligence e i motori di ricerca lavorano in fondo allo stesso modo: permettono al manager di 'programmare' personalmente, organizzando i dati in funzione di ciò che gli serve.
Siccome non si sa a priori quale dato -di fronte ad una nuova ed imprevista esigenza conoscitiva- sarà utile, aspetti chiave del KDD sono: 'prendere per buono qualsiasi dato' e 'ricercare su basi dati non-finite'. Quindi l'utilizzo di Datawarehouse -'magazzini' di dati magari vastissimi, ma di dimensioni predefinite, e frutto di scelte fatte a priori- limita, e alla fin fine nega il concetto che sta alla base di Data Mining, Business Intelligence e KDD. In uno senario tecnologico passato, il limitarsi all'uso di Datawarehouse era reso necessario dal rischio di danneggiare, con query estemporanee, il funzionamento gestionale e transazionale di una procedura applicativa. Ma i DBMS (Data Base Mangement System) oggi permettono l'OLAP (On-Line Analytical Processing), ovvero proprio la costruzione di conoscenze sulla base di modelli dei dati costruiti ad hoc, di volta in volta.

Web 2.0, Portale Interno, Enterprise 2.0
E', sostanzialmente, una piattaforma dove tutti scrivono e tutti leggono. Ne sono esempio piattaforme non aziendali, come www.facebook.com, www.linkedin.com, www.youtube.com, www.scribd.com, www.ebay.com. C'è un paradosso nel fatto che i Portali interni aziendali girano ancora spesso solo su rete privata (VPN), e sono fondato su una strategia top down, qualcuno dall'alto e dal centro carica informazioni, E le possibilità di caricare informazioni dal basso, da parte di ognuno, bottom up, sono limitate a priori da rigide procedure. Così non accade su Facebook, Linkedin ecc., qui tutte le persone sono uguali, tutti nodi di una rete. Accade che sia più semplice ed agevole reperire informazioni sul Web piuttosto che tramite le fonti aziendali.
A questa situazione si tende a rispondere con Portali Interni costruiti come Facebook, Linkedin ecc., accessibili via Internet (e non solo via VPN).  Ogni utente è profilato in base al suo ruolo organizzativo. Ma non gli è impedito di accedere a conoscenze lontane da ciò che è previsto serva per il lavoro che svolge.  Si favorisce così la circolazione di conoscenze, la mobilità interna, l'emersione di talenti. Il lavoro è delocalizzato (Ubiquitous), ognuno accede via browser alle risorse che servono, quando servono (Cloud Computing, SaaS), ivi comprese le applicazioni aziendali necessarie per svolgere il lavoro assegnato.
Dal Portale Interno si passa così all'Enterprise 2.0: l'azienda, viva non solo in un luogo, ma nel non luogo che è il Cyberspace, è virtualmente rappresentata dalla piattaforma. L'architettura 'a servizi' (SOA), costruita sulle esigenze dell'azienda -della sua cultura, della sua strategia, del suo business- finisce per convergere con il Portale Interno. Portale e SOA sono la stessa architettura. Così come tramite la piattaforma dipendenti e collaboratori lavorano, tramite la stessa piattaforma clienti e fornitori interagiscono con l'azienda.

 

Pagina precedente

Indice dei contributi