Enterprise (Linked) Open Data

Tag

EA, EIM, Enterprise, LOD, OD, oddi2013, Open Data

Dopo aver letto questo bell’ articolo di Giovanni Meduni e fresco di una stimolante collaborazione nell’ambito dell’International Open Data Day Italia 2013, mi sento portato a pensare che Open Data sia la strada giusta per portare il dato ad uno stadio evolutivo superiore, in cui esso nasca già con una sua dignità ed un diritto/dovere di crescere, aggregarsi ad altri dati ed evolvere all’interno di un ecosistema vivo e aperto di informazioni in cui poter esprimere il suo vero potenziale grazie all’infinita gamma di possibili riusi che ne potrebbero essere fatti. Ma siamo sicuri che ciò valga solo per il Web?

Andiamo oltre
Proviamo a fare subito un piccolo passo avanti e superare la storia del dato aperto. Proviamo cioè ad immaginare cosa potrebbe significare Open Data se il contesto di applicazione non fosse più quello delle sterminate e infinite praterie del West…pardon…del Web. Immaginiamo di liberare i dati nel “giardino di casa” o nel “parco cittadino”, in un ambiente cioè i cui confini siano sempre sufficientemente ampi da non imbrigliare il dato ma non tanto sconfinati da rallentarne e diminuirne l’immediata percezione del cambiamento generato.
Sto pensando all’ Open Data applicato ad un contesto enterprise, in particolare a quelle aziende che per struttura, numero di dipendenti, estensione territoriale e di mercato potremmo chiamare “Big Enterprises“.
Negli ultimi anni, per motivi professionali, mi sono trovato spesso a che fare con problematiche di gestione della conoscenza in contesti molto ampi di grandi gruppi aziendali (principalmente bancari e assicurativi). Mi riferisco in particolare a tutte quelle attività volte a gestire problematiche che vanno sotto il nome di Enterprise Information Management [EIM].

Vi sono contesti specifici dove tali problematiche risultano particolarmente evidenti, come quello della Governance IT e dell’Enterprise Architecture, in cui i responsabili dell’IT, i manager business e i vari CIO, CTO e CEO di questi grandi ecosistemi informativi si accorgono che l’incisività della loro azione passa inesorabilmente per la possibilità di accedere e manipolare le informazioni in maniera nuova, libera da schemi predefiniti e da vincoli tecnologici e con la possibilità di integrare, disgregare e riaggregare (mesh-up) i dati in maniera rapida, naturale e il più possibile dinamica.

L’esperienza sul campo
Per quella che è la mia esperienza,molto spesso i clienti ritengono di non possedere molte delle informazioni necessarie al raggiungimento dei loro obiettivi. Nel 90% dei casi ciò è falso (e forse nel restante 10% non è del tutto vero).
In realtà quello che serve per capire un AS-IS, disegnare un TO-BE e definire una opportuna roadmap, quasi sempre esiste già  ma non si riesce a vedere o ad utilizzare direttamente. Il dato è nascosto, sepolto sotto tonnellate di applicazioni special purpose, imprigionato come una mummia nel ghiaccio dei complessi sistemi informativi dell’azienda, ridondato e aggrovigliato all’interno di innumerevoli database e data warehouse sotto forme diverse, per non parlare dei troppi casi in cui è umiliato ed esiliato all’interno di fogli excel sui desktop delle singole persone.

Il risultato è un ecosistema complicato di dati stagnanti, prigionieri di schemi e viste opportunamente assemblate in dati momenti storici e in alcuni casi poi riadattati forzatamente per ulteriori scopi. Questo è un ecosistema morto!

Un rischio sempre dietro l’angolo
Quando si dimostra che tali informazioni possono essere restituite tramite una non facile operazione chirurgica e di restauro informatico, si corre il rischio di ricadere inesorabilmente nello stesso errore andando a predisporre le basi per un nuovo ecosistema che le reimprigioni per ulteriori ere geologiche.

Proprio per evitare questo rischio credo si potrebbe pensare di introdurre l’illuminante pratica dell’Open Data a livello enterprise. Sarebbe infatti lecito porsi una domanda: se tale pratica nasce per liberare definitivamente il dato e a ridargli nuova linfa vitale e dignità su scala planetaria per quale motivo non dovrebbe poter funzionare su una scala più piccola come quella aziendale?

Un possibile percorso
Ma cosa si dovrebbe fare per rendere operativa tale pratica che potremmo chiamare senza grande sforzo di fantasia “Enterprise (Linked) Open Data“?
Senza voler entrare nei dettagli tecnici proviamo ad elencare una serie di macro step propedeutici all’introduzione della pratica degli Open Data a livello enterprise:

1. Censimento e definizione della topologia dei dati: quali aree aziendali prendere in considerazione e come organizzare i relativi dati in cataloghi e dataset.
2. Specificare i formati: .pdf (pessimo), .xls (si può fare di meglio), .csv/tsv(decente), .xml (buono), rdf/owl (optimum!)
3. Estrazione dei dati dalle fonti individuate nei formati prescelti
4. Predisposizione di una piattaforma centrale (o federata) di servizi per la gestione dei dati, la loro classificazione, integrazione, ricerca e pubblicazione
5. Definizione di un processo di lifecycle dei dati aperti
6. Definizione delle policy di sicurezza e permission di accesso ai dati aperti

Per i più virtuosi
(7.) Volendo completare l’opera ci si può spingere ancora oltre e pubblicare i dati in modalità “Linked Open Data” (LOD) ossia sfruttando tecnologie semantiche come RDF, OWL, URI e SPARQL per dare ai dati una semantica esplicita, formale e renderli naturalmente interconnessi (tramite URL come avviene già per le pagine html), univoci, ricercabili e navigabili. Tutto in un colpo solo! Che meraviglia eh?… Vabbé ma questo è uno step solo per i più virtuosi.

Valore aggiunto
Una volta che i dati saranno così ben organizzati, aperti, classificati, ricercabili e facilmente integrabili fra loro, cosa avremo ottenuto di fatto? Quale potrebbe essere il reale e percepibile valore aggiunto di un tale approccio in ambito aziendale?
Proviamo a stilare un elenco di macro effetti benefici (a breve e a lungo termine):

• I dati non sarebbero più il mezzo con cui esercitare un potere che normalmente alimenta rischiose pratiche di presidio dei vari domini di competenza all’interno dell’azienda.
• Sì avrebbe un significativo e drastico calo della necessità di commissionare periodicamente assesment informativi ad aziende di consulenza esterna.
• Sì avrebbe una considerevole semplificazione nel processo di sviluppo di nuove applicazioni “data-consumer” e di “data-integration”.
• Semplificazione e gestione trasparente del patrimonio informativo dell’azienda tramite processi strutturati, condivisi e formali come da best practice di EIM.
• Ottimizzazione dei processi di comunicazione e condivisione delle informazioni fra le diverse aree aziendali.

…e ne avrei altri…ma provate a pensarci e vedrete che vi verranno in mente anche a voi.

L’hai fatta troppo facile!
Ho sicuramente e volutamente semplificato il tutto perchè l’obiettivo di questo post non era tanto quello di descrivere una soluzione basata su Open Data ma piuttosto di proporre tale approccio in un contesto diverso da quello canonico del web e provare quindi ad immaginarne quali ne potrebbero essere gli immediati effetti benefici.
Per esperienza sono quindi consapevole che nella pratica vi sarebbero diverse problematiche con cui ci si scontrerebbe, prima fra tutte e non banale la sensibilizzazione del cliente stesso in merito a tali pratiche di EIM, la difficoltà di censire i dati rispetto alle varie sotto strutture aziendali, la reticenza dei vari responsabili a condividere i propri dati e la necessità imprescindibile di definire delle politiche di sicurezza precise sugli accessi ai dati.
Il mio ottimismo però (qualcuno direbbe “sei giovane!“) mi porta a pensare che, se è vero che l’Open Data ultimamente sta diventando una realtà in un campo così ostico e per sua natura inerziale come la PA Italiana, beh allora mi sento abbastanza confidente che tutte le possibili problematiche appena esposte possano essere superate in un ambito come quello delle grandi aziende (che dovrebbe essere) più portato ad ottimizzare e innovare.

Think positive…and open!

- MATTEO BUSANELLI -
mbusanelli(AT)imolinfo.it

“Come possono gli open data rivoluzionare gli spostamenti ferroviari in Gran Bretagna?”

Tag

ODI, Open Data

Ho assistito oggi, 01/02/2013, a una lecture presso ODI, Open Data Institute, istituto, appunto, fondato a Londra nel corso del 2012 con lo scopo di promuovere l’evoluzione degli open data al fine di ricavarne valore dal punto di vista economico, ambientale e sociale.

ODI propone con cadenza settimanale incontri come quello odierno, gratuiti e per un numero limitato di partecipanti, una trentina circa, con il doppio fine sia di trattare gli argomenti indicati che di divulgare la notizia della propria presenza nelle comunità di interesse. Maggiori informazioni in merito sono reperibili nella sezione FAQ e nel calendario del relativo Web site.

La mia visita aveva innanzitutto la natura di primo approccio e lo scopo di osservare l’istituto in termini generali, nel senso di non strettamente legati alla lecture a cui ho assistito. In tale ottica, l’atteggiamento degli organizzatori, tra loro stessi e rispetto ai visitatori, è caratterizzato da:

• apertura (“we are open by default” attaccato alle pareti con esplicito riferimento non solo ai dati);
• ricerca del dialogo;
• facilitazione delle connessioni e collaborazioni;
• condivisione delle risorse (nome rete e password per l’accesso al WiFi interno sono facilmente individuabili anche nella sala adibita alla lecture, caffè e thé sono gratuiti, e così via).

In termini particolari, quindi scendendo nel dettaglio della lecture (il cui titolo originale era “How can Open Data Revolutionise your Rail Travel?”), e a prescindere dai dati tecnici, non rilevanti per Gruppo Imola, è possibile individuare alcuni output che ritengo valgano per qualunque contesto in cui gli open data si vogliano considerare, esplicitati dal citato relatore o da me dedotti:

• dove c’è un finanziamento pubblico (cioè proveniente dalla tassazione dei cittadini) devono esserci open data, cioè tali dati devono essere disponbili. Se i dati non sono disponibli è lecito anzi necessario lottare, tramite ricerca e dimostrazioni tecnologiche dei conseguenti vantaggi, per far sì che vengano resi disponibili;
• si percepisce una funzione sociale degli open data, al fine di preservare il singolo cittadino dal possibile monopolio economico di chi possiede i dati e non li rende disponibili. Le possibilità offerta dagli open data e la loro efficacia in questo senso sono innegabili;
• al fine di comprendere qualunque set di open data è innanzitutto necessario capire l’istituzione (o l’istituto) che li produce.

ODI ha inviato a oguno dei partecipanti le slide utilizzate nel corso della lecture e l’audio della stessa, entrambi in lingua inglese.

A livello di considerazioni personali l’esperienza è stata più che positiva, sia in termini dell’istituto nel suo complesso che grazie alla preparazione, alle idee e all’atteggiamento del relatore, Jonathan Raper di Placr Ltd, il quale è riuscito, per i 28 minuti del suo monologo, a far in modo che lo stato delle ferrovie in Gran Bretagna diventasse la mia priorità più alta.

Per i motivi appena citati ho già provveduto all’iscrizione a una ulteriore lecture, in data 22/02/2013, dal titolo “Building an open world“.

Matteo Manzini (mmanzini[at]imolinfo.it)

I perché sulle architetture

Questo post nasce da uno spunto (un video) che mi fa ricordare i dibattiti a cui partecipo nelle aziende che frequento.

I dibattiti, le riunioni, le chiacchiere informali a cui mi riferisco riguardano la necessità, le motivazioni, i vantaggi di avere un Gruppo Architetture formalizzato e operante, cosa fa e come lo fa, che ruolo deve avere, che relazioni con gli altri gruppi deve avere, che potere deve avere e a chi deve fare capo, se si deve occupare solo di IT o anche d’altro, …. e tutto ciò che si può collegare a questo tema.

Le situazioni e il tenore degli argomenti varia moltissimo da azienda a azienda, e in alcune occasioni i ragionamenti sfociano in autentica gazzarra ideologica; dipende molto dai partecipanti e dalla cultura e mentalità dell’azienda e degli individui. Quasi mai se ne esce sereni e migliori, perché il dibattito ristagna quasi sempre su domande di questo tipo, in modo dipendente da situazione e maturità dell’azienda:

che cosa è e perché serve avere un gruppo architetture?

perché delle architetture non basta che se ne occupino i progetti (NDR come si è sempre fatto, cioè non occupandosene quasi mai se non a livello di tecnologie da scegliere)?

ma perché ci deve essere qualcuno a cui raccontare cosa fa un progetto “al suo interno”?

ma gli architetti si devono occupare solo della parte IT o anche della organizzazione (cioè del modo in cui si svolgono le attività – nell’IT e/o anche fuori-)?

il modello architetturale SOA è meglio di un modello a Silos e perché?

Tutte queste domande sono lecite e al tempo stesso le risposte, quali esse siano, sono indimostrabili matematicamente quindi insoddisfacenti per chi è prevenuto. Ed è la quasi totalità dei casi.

La constatazione pratica è che chi non vuole convincersi di un cambiamento per sue valide ragioni individuali ha tutte le possibilità di giustificare il suo atteggiamento, e nessun argomento, se non dimostrabile matematicamente, lo convincerà per il solo fatto che non vuole essere convinto.

Lo spunto che mi ha fatto decidere di scrivere è un video che ha scatenato un dibattito tra la tribù che sostiene che l’Enterprise Architecture è una disciplina a livello aziendale e quella che sostiene che è una disciplina IT e a quella parte deve rimanere limitata.

Questo video mi piace perché è efficace per tutti quelli che non hanno dimestichezza con la globalità di un IT e non hanno presente la “complessità emergente” che negli anni sta caratterizzano i Sistemi Informativi. Spesso questo connubio porta alla sottovalutazione dell’impatto di un singolo progetto sul tutto, visto che la prospettiva da cui il progetto guarda le cose è individuale, ma il video sottolinea bene l’importanza di collegare una decisione al tutto e non solo al singolo obiettivo.

Ci sono però altri aspetti che non condivido affatto:

il video ha un titolo errato, in quanto quella di cui si parla non è come il titolo farebbe pensare Enterprise Architecture bensì IT Architecture

viene trattato solo un aspetto, la riduzione o la non generazione di inutile complessità, che non è certo la sola ragione per cui l’architettura deve esistere: quindi rischia di essere riduttivo e deviante

Al di là di questi “difetti” lo considero uno strumento di consapevolezza probabilmente efficace in qualche caso, quindi meritevole di essere diffuso.

Eccolo.

Disagreement rather than consensus

Tag

Carriera, Critica, Dissenso, Organizzazione

To make more effective decisions, develop disagreement rather than consensus.

Peter F. Drucker

Introduzione

Pochi giorni fa ho iniziato una discussione su Linkedin (Vedi gruppo Strategie competitive e modelli di business) che partiva da questa citazione.

L’idea l’avevo in testa da qualche mese, perché sulla lavagna del mio capo compare una scritta simile:
“Non stai facendo al meglio il tuo lavoro se non sei in disaccordo con me almeno una volta al giorno”.

Ci riflettevo anche perché avevo la necessità di spiegare l’azienda ad alcuni colleghi più giovani,
e perché abbiamo un’organizzazione orizzontale: a mio parere, più difficile spiegare di quelle classiche.

Non volevo però fare un “auto citazione”, ma volevo piuttosto qualcosa che venisse dalla letteratura, ma senza dover spiegare Viable System Model [VSM], System Thinking [ST] o la Cibernetica [KYB].

Nella discussione facevo notare come la critica fosse alla base di una buona decisione,
mentre spesso siamo di fronte a dei modelli organizzativi a “pensiero unico”.
Ovvero modelli in cui il capo ha ragione per definizione e nessuno osa contraddirlo,
pena l’esclusione dai ruoli che contano e derisione da parte dei colleghi.

Costruire invece di distruggere

Nella discussione ho sottolineato una differenza fra critica e critica costruttiva,
però mi hanno fatto notare che tale differenza non esiste, in quanto o si trova una soluzione che mette insieme i pezzi, oppure si aprono due strade differenti.

Io, invece, ritengo che esistano delle critiche fatte per distruggere e altre fatte per costruire.
In particolare mi lascia perplesso l’idea che alla fine della discussione, se non si trova un accordo, allora si aprono delle strade alternative.

Trovo questa situazione estrema e in generale da scongiurare, perché la tensione in azienda sarebbe forte e sarebbero a rischio anche i rapporti umani presenti, oltre alla qualità percepita dal cliente e il fatturato.

Inoltre ritengo che la critica non debba proprio essere fatta con l’obiettivo di intraprendere una strada a scapito di quella originalmente proposta, ma deve essere fatta prima di scegliere una strada, e per ponderare la decisione in maniera più profonda.

Credo cioè che la critica serva per far affiorare i punti di vista e le informazioni meno evidenti o addirittura sconosciute, e non certo per mettere in discussione la decisione per un particolare interesse.

Come si sviluppa il dissenso

Sviluppare il dissenso è tutt’altro che facile.

Da noi lo si fa introducendo persone con caratteri e obiettivi personali molto diversi fra loro.

Non esiste una gerarchia, ma un responsabile del progetto che ha l’obbligo di coniugare
l’interesse del progetto con quello dell’azienda … e non solo quello del progetto come se fosse un’entità isolata rispetto all’azienda stessa.

Inoltre i responsabili di progetto cambiano spesso e quindi tutti si ritrovano con diversi ruoli
su diverse iniziative su diversi clienti in tempi abbastanza ravvicinati.

In un contesto del genere il dissenso è abbastanza fisiologico come l’abitudine al cambiamento.

Dico fisiologico, ma certamente non indolore

A volte si rischia molta confusione e in qualche caso si sente addirittura parlare di disorganizzazione.

E’ per questo che è importante la presenza di un responsabile.
Dando l’effettiva connotazione al termine, esso non è il capo ma colui che si fa carico
di trovare un equilibrio tra le tante posizioni presenti e di spiegare le sue decisioni.

Non può ignorare l’opinione di qualcuno o addirittura soffocare le opinioni, o quanto meno non è nel suo interesse, perché a breve potrebbe cedere il suo ruolo e vedersi smontate le sue teorie (e i suoi giochetti).

Voi cercate il dissenso ? e come ?

Carriera

In questo tipo di organizzazioni è anche difficile parlare di carriera, almeno nella sua percezione classica.

Non ci sono poltrone su cui sedersi in eterno, non sei giudicato in base al numero dei tuoi subalterni, i numeri dei tuoi progetti sono irrilevanti rispetto a quelli dell’azienda.

Non ho nemmeno una risposta inattaccabile su cosa vuol dire carriera in un’organizzazione orizzontale.

Ti piace quello che fai ?
La tua parola viene riconosciuta come importante ?
Ci sono sempre cose nuove da imparare ?
Condividi le responsabilità e non ti senti solo ?
Non sei mai il colpevole ma uno di quelli che devono trovare la soluzione ?
Non sei escluso dai temi importanti ?

Non so se hai fatto carriera e non so se è merito dell’organizzazione, ma andare al lavoro potrebbe non essere così brutto

E voi come vi trovate al lavoro ?
E a cosa date il merito o la colpa ?

Referenze

[VSM]

http://en.wikipedia.org/wiki/Viable_system_model

[ST]

http://en.wikipedia.org/wiki/Systems_thinking

[KYB]

http://it.wikipedia.org/wiki/Cibernetica

[Gruppo Imola]

http://www.linkedin.com/company/imola-informatica

[Mirco Casoni]
it.linkedin.com/in/mcasoni

Per tentare un salto di qualità

Esco da un paio di settimane di incontri e tavoli di brainstorming con manager IT di vari livelli riguardanti i loro obiettivi e desideri per il prossimo anno, i piani che li vedono coinvolti, le difficoltà che vivono e che rendono problematica la realizzazione dei piani.

Vorrei condividere alcune riflessioni sintetiche sull’aria che si respira in molte delle aziende che frequento, e tentare alcune domande.

Lo scenario che spesso (troppo) mi viene raccontato è un mix di vari archetipi assai noti nelle organizzazioni tecniche e non, che vado di seguito ad elencare.

Fantasy world

Di fronte ad un problema, una persona si muove a intuito. Spesso i manager non hanno una idea diretta del problema e sulla base di informazioni di seconda mano, parziali e ritenute poco affidabili, devono comunque decidere. Per cui si costruiscono un modello della realtà che secondo loro ha un senso e giustifica le azioni che vogliono intraprendere.

Baronies

Le Baronie sono un pessimo punto di partenza per creare sinergie, essendo straordinariamente resistenti ad ogni cambiamento che non sia legato ad un interesse individuale. Cercano di accaparrarsi risorse di ogni tipo, praticano la competizione fratricida e rifuggono volontariamente la condivisione di informazioni e conoscenza.

Here be Dragons

Strategie e/o attività vengono ostacolate da disturbi dell’ambiente che non erano per nulla inattesi e imprevedibili, ma che non erano state volontariamente evidenziate e preannunciate.

Bean Counters

Il sintomo più frequente consiste in una fissazione ossessiva all’efficienza e al taglio dei costi. Lo stile manageriale dei Bean Counter vede il futuro come semplice estensione (prolungamento) del passato ed il cambiamento come “fare più o meno quello che abbiamo sempre fatto”. Per cui si può migliorare, ma solo facendo meglio quello che si è sempre fatto, nel modo in cui lo si è sempre fatto. Frequentemente gli obiettivi sono espressi da miglioramenti nei grandi numeri, senza preoccuparsi delle azioni reali che vanno fatte e delle loro conseguenze.

Silo Decision

E’ dovuto a processi decisionali altamente politicizzati dovuti a fazioni contrapposte. Ne risultano decisioni che una parte del management non condivide o perché non sono stati coinvolti o perché le considerano impraticabili. Queste due cause sono interdipendenti: vengono escussi se sembra che non condividano e non condividono perché sono stati esclusi. Questo modo di procedere produce strategie che falliscono e non sono attuabili perché vengono ignorati i problemi chiave.

La presenza più o meno spinta di questi archetipi organizzativi ha conseguenze evidenti: organizzazioni rissose, politiche, poco efficienti, sprecone e inconcludenti, con la maggior parte delle persone frustrate e superoccupate, che producono risultati veramente modesti rispetto alle potenzialità, ma a prezzo di grande fatica soprattutto psicologica.

A questo punto le mie domande:

Può l’Enterprise Architecture fare qualcosa di buono per queste situazioni?

Se no, chi se ne deve occupare?

C’è qualcuno che lo ha posto (o se lo è posto) come obiettivo?

C’è qualcuno che ci è riuscito, con che “cappello” e come?

C’è qualcuno a cui interessa discuterne?

C’è qualcuno a cui interessa migliorare (pur nei limiti e nei perimetri di influenza) o no?

Le motivazioni come motore del team di lavoro

Gestire un team apre spunti di riflessione non solo sulle modalità di soddisfacimento degli obiettivi di progetto, ma anche su quelli personali del team.

Da qui, è compito del referente di progetto capire le motivazioni del proprio gruppo e di ciascun singolo, ponendosi l’obiettivo di soddisfarli, perché questo si coniuga con l’obiettivo di progetto, perché se il team è motivato farà meglio il suo lavoro!

Partirei da una distinzione fondamentale delle motivazioni: intrinseche ed estrinseche.

Le motivazioni intrinseche sono quelle naturali, basate sulla curiosità e sul il bisogno di esplorare l’ambiente alla ricerca di nuove informazioni e soluzioni. Importante per la motivazione intrinseca è, inoltre, la padronanza, cioè il bisogno di sentirsi sempre più competenti.

Le motivazioni estrinseche sono quelle dettate da un impegno in un’attività per scopi che sono estrinseci all’attività stessa, quali, ad esempio, ricevere lodi, riconoscimenti, buoni voti o per evitare situazioni spiacevoli.

Notate queste caratteristiche trai propri membri del team, non sarà facile trovare il giusto compromesso tra le due; spingiamo su quelle intrinseche che mi ispirano parecchio.

La Self-determination theory (Deci, Ryan 2004) propone queste caratteristiche intrinseche:

Competence: ciò che una persona dimostra di saper fare (anche intellettualmente) in modo efficace, in relazione ad un determinato obiettivo, compito o attività in un determinato ambito disciplinare o professionale [ Centro studi Erickson].

Autonomy: non è da intendere come il dover sapere fare tutto da soli, ma consiste nella capacità di saper ricavare le giuste informazioni dai giusti interlocutori, necessarie a portare avanti il proprio lavoro.

Relatedness: la capacità di sapersi relazionare non solo coi propri colleghi ma anche coi propri clienti,  al fine di riuscire a soddisfare gli obiettivi business e commerciali.

Notare come queste 3 caratteristiche siano strettamente correlate tra loro.

Da queste 3 caratteristiche sono state formulate altre teorie basate sulle motivazioni, sino ad arrivare alla definizione di quelli che sono i 10 Desideri dei membri del team (di cui 3 sono quelli sopra descritti):

Feel accepted: sentirsi parte integrante del team, mediante la collaborazione con tutti e la condivisione delle proprie esperienze e del proprio background professionale;

Curiosity: trovare, anche di fronte ad un’attività noiosa, qualcosa di nuovo che possa stimolare la propria curiosità;

Honor: la squadra deve proporre le proprie regole di gioco (condivise dal referente), così saranno più facili da seguire;

Purpose: avere sempre obiettivi di breve, medio e lungo termine, non solo circoscritti al perimetro dell’attività che si sta portando avanti in quel periodo;

Order: recepire le norme aziendali sufficienti a consentire il buon vivere all’interno della propria organizzazione;

Influence: percepire ciò che sta accadendo intorno a noi, ascoltando ciò che hanno da dire gli altri e aiutarli col nostro contributo e col nostro carisma (avendo la fortuna di averlo;))

Status: capire il proprio valore all’interno dell’organizzazione.

Approccio alle applicazioni orientate ai servizi

Tag

SOA

Questi ultimi anni sono stati caratterizzati dalle nuove tendenze architetturali che hanno visto sulla cresta dell’onda il modello architetturale SOA.

SOA è un’architettura orientata ai servizi e si propone come metodologia per organizzare gli elementi delle applicazioni come servizi. La letteratura presenta però svariate definizioni e il modello di riferimento non è standard.

Per cui tutto ciò lascia spazio ai vendor che “propongono” i loro prodotti e le proposte dei vari fornitori sono dei modelli che non sempre rispecchiano dei principi architetturali corretti e pur dichiarando di implementare SOA, contraddicono regole di buona programmazione enterprise.

Molto spesso l’errore è quello di lasciarsi guidare e partire dalle tecnologie abilitanti una soluzione, senza invece partire dalla soluzione al problema, depurata dagli strumenti atti a realizzarla.

In questi anni abbiamo lavorato a un modello architetturale orientato ai servizi, applicato in seguito in ambito bancario, con le customizzazioni del caso.

Il modello architetturale è stato ideato partendo dall’assunto che i modelli applicativi tipici prevedono l’esistenza di un front-end (illustrato nella parte sinistra della figura sotto); da qui vogliamo poi integrare quello che fa parte del contesto SOA (data la necessità di esporre i sistemi come servizi) con tutto ciò che non fa parte di un contesto a servizio (illustrato nella parte destra della figura sotto).

Ecco i layer architetturali del mondo SOA:

• Integration: risolve il problema dell’eterogeneità delle tecnologie. E’ lo strato di confine tra il mondo soa e quello non soa, come tale riesce ad integrare le funzionalità dei sistemi esistenti come database o sistemi legacy. Tale layer presenterà una interfaccia che riesce ad interagire col mondo non-soa ed una seconda che interagisce col sistema di riferimento soa;
• Execution: gestisce la logica di business;
• Composite: orchestra i servizi di sistema ed espone le funzionalità business mediante dei processi orchestratori del flusso generale;
• Service: questo livello, ”realizza” le funzionalità business, per cui si vuole separare la realizzazione o implementazione da quello che è la presentazione del servizio. E’ una sorta di delega che espone il servizio business verso l’esterno. La sua utilità è legata anche alla possibilità di presentare un certo sotto-insieme dei servizi che si vogliono esporre in base ai diritti di chi accede al sistema.

Il modello descritto si è prestato a supportare casi reali di nostri clienti, soprattutto di ambito bancario.  Il contesto molto spesso è stato quello di effettuare la migrazione del loro prodotto o di parte di esso verso uno nuovo  che rispondesse ai principi SOA. Non sempre tutti i layer sono stati necessari, la loro introduzione o meno dipende dai contesti in cui si opera.

Il modello permette di rispondere agli obiettivi di integrazione e di facilitare il processo di sviluppo delle applicazioni SOA-oriented. Inoltre, vuol essere un’alternativa ai modelli proposti dai fornitori, sottolineando il fatto che non sempre è necessario utilizzare un ESB per fare SOA.

You Think Changing To Increase Business Agility Is Hard?

Tag

ITTransformation

Spendendo pressochè ogni giorno a dialogare con i Top Manager dei nostri clienti più importanti, non ci vuole molta fantasia a constatare che uno dei problemi più sentiti, e non da oggi, sia come portare -e dimostrare di portare- valore all’azienda, al di là del solito “ridurre i costi” che non sembra soddisfare più di tanto le Direzioni.

Io credo che portare risultati sia un buon modo per iniziare. Ma quali risultati?

La velocità, ad esempio, che è sempre più necessaria al giorno d’oggi. Un modo trendy per chiamare la velocità oggi nelle aziende è la Business Agility, cioè la velocità nell’implementare nuove idee business di attacco o difensive che siano, una necessità sempre più frequente nel mondo stressato, competitivo, pazzo in cui ci troviamo tutti.

La necessità deriva da tutto quello che ci è successo intorno negli ultimi anni con questa timeline:

1990 Tim Berners-Lee crea il World Wide Web e finisce ARPAnet.
1993 Marc Andreesen alla Università dell’Illinois, Champaign-Urbana sviluppa il Web browser Mosaic.
1994 Viene fondata Netscape Communications, Jeff Bezos scrive il Business Plan di Amazon.com, Java viene dimostrato in pubblico.
1995 Sun Microsystems rilascia Java.
1997 Google viene registrato come dominio.

Parlerò in un prossimo post di come la colpa e/o il merito della situazione attuale sia legata a questa Timeline.
Fatto sta che la velocità è diventata necessaria e gli IT Enterprise fanno fatica, molta fatica a stare al passo, oppressi dalla difficoltà di:

capire perchè sia necessario cambiare,

capire cosa cambiare,

riuscire a cambiare.

Tentando di innescare e governare il cambiamento ci sono giorni felici e giorni di sconforto. Un giorno felice è stato quando, poche settimane fa, Forrester ha pubblicato il Case Study IOR Transformed To Increase Business Agility (richiede la sottoscrizione).
Diego Lo Giudice, che ha curato la ricerca insieme con Phil Murphy e Alissa Anderson, ha scritto sul suo blog You Think Changing To Increase Business Agility Is Hard? If IOR Did It, Believe Me: You Can Do It Too a commento.
Imola Informatica svolge dal concepimento del progetto il ruolo di partner del cliente, con una strategia tipica per noi:

IOR has selected a local partner, Imola Informatica (www.imolinfo.it), to assist in all phases from design and development to integration and testing and up to deployment. At the end of each new project, knowhow that was not transferred during the critical phases of the project is transferred through a dedicated handover period.

SOA e gli indecisi a tutto

Tag

SOA

Il mondo sta attraversando una recessione globale e su questa situazione c’è anche troppa enfasi.
Probabilmente siamo solo all’inizio di quello che potenzialmente può andare storto quindi, data l’attuale pressione economica globale, è comprensibile che nel 2009 le organizzazioni indecise fino ad oggi nell’introdurre SOA continuino a rinviare le iniziative volte in tal senso.
Questo beninteso non significa che in futuro non intendano indirizzarsi verso uno “stile SOA” ma solo che attualmente, visto lo scenario, sono cambiate le priorità e di conseguenza e’ cambiato l’orizzonte temporale in cui pensano di dover seriamente fare qualcosa di nuovo.
In una situazione così imprevedibile, investire in qualcosa in un’ottica di ritorno futuro sembra un rischio eccessivo.
Questa scelta sembra logica, per come si sono tipicamente affrontate le cose fino ad ora.
Non è il momento giusto per investire in architettura IT, proprio perché non ci sono soldi in abbondanza quindi si puo’ andare avanti con i sistemi inefficienti, inflessibili, ridondanti e non interoperabili che hanno elevati costi di manutenzione e gestione, nonche’ scarsa capacità di provvedere alle richieste di oggi, figuriamoci a quelle non prevedibili di domani.
Questa situazione conferma che la responsabilità del sistematico mancato investimento nel ciclo continuo dell’architettura va spesso divisa equamente tra le imprese e l’organizzazione IT, come dicevamo a meta’ 2007.
Mi rendo conto quasi sempre del fatto che fino ad oggi chi si e’ avvicinato a SOA, lo ha fatto spesso in modo inappropriato trattando SOA come un progetto di infrastruttura tecnologica, cioe’ ha acquistato le infrastrutture prima di aver capito quali servizi costruire, e prima di avere capito quali problemi risolvere.
O ancora peggio, ha trattato SOA come una soluzione tecnologica affascinante in cerca di un problema.
Come sempre in tempi di incertezza e di stress, il modo migliore per andare avanti sembrerebbe quello di procedere a piccoli passi e misurare i risultati di ogni passo, in modo da essere sicuri che ci si sta muovendo nella giusta direzione. Da questo punto di vista, SOA è una strategia tra le meno rischiose, e questo approccio e’ da sempre quello che tutte le Roadmap SOA prescrivono. In realtà l’obiettivo fondamentale di uno sforzo SOA è quello di consentire un cambiamento continuo negli ambienti eterogenei attraverso la capacità di astrarre fornita dai Servizi. E’ possibile ottenere vantaggi immediati da SOA semplicemente costruendo un servizio che è ampiamente utilizzato nella organizzazione e che, possibilmente, affronta un problema chiave dei processi di business relativi al cambiamento.
Se è possibile identificare un processo da migliorare, la chiave è quella di iniziare con il più piccolo dei processi di business che si può trovare e tra quelli inefficienti, dove l’inefficienza è causata da un aspetto di continuo cambiamento: il miglioramento di quel processo di business permette di recuperare i costi e utilizzare i fondi recuperati per reinvestire in architettura ricominciando di nuovo il ciclo.
Questo non è un approccio da “tempi di crisi”, ma quello che dovrebbe essere SOA, a prescindere.

I Key-point del Semantic Web di oggi

Prendo spunto da una intervista a Tim Berners Lee fatta da un giornalista di Talis, per commentare alcune frasi sparse estratte dal transcript e raccordarlo con le nostre attivita’ sul Semantic Web.

Dal transcript dell’intervista del 7 febbraio 2008 a Tim Berners Lee da parte di Paul Miller di Talis.

TBL chiarisce innanzi tutto il campo di azione del Semantic Web, che viene spesso visto come “estrazione di concetti dai testi”, cosa vera ma non rappresentativa ne’ esaustiva, ed indica che l’associare i dati (testi o dati nel senso piu’ largo) ai concetti  chiave di un’azienda o di un mondo piu’ largo puo’ essere utile e praticabile con profitto in moltissime situazioni diverse per scopi diversi. Cito:

“I think the Semantic Web is such a broad set of technologies and is going to do so many different things for different people. It is really difficult to put it on one thing. What are the steps necessary right now for the life sciences community to be able to use it for their data about proteins is probably different from which steps do we need to be able to get interoperability between repositories of library data and museum data.”
C’e’ poi una frase che mi fa particolarmente felice, perche’ conferma la visione che in Gruppoimola abbiamo sempre avuto delle tecnologie semantiche, che abbiamo interpretato come un vantaggio immediato nell’integrazione intelligente di forme diverse di dati, che permette di integrare dati da fonti diverse secondo una logica comune. Abbiamo usato queste tecnologie per integrare dati provenienti da repository diversi (file system, WebDav, blog, wiki, database) e permetterne navigazione, ricerca, elaborazione e modifica in ambienti diversi da quelli in cui i dati risiedono fisicamente, come ad esempio applicazioni e portali. Ecco la frase:

“So the Semantic Web is about integration, it is like getting power when you use the data, it is giving people in the company the ability to do queries across the huge amounts of data the company has.”
Si accusa poi di un errore nella comunicazione riguardo a cosa il Semantic Web sia, dicendo che sarebbe stato molto piu’ veloce da comprendere se avesse detto che era un approccio per la “enterprise and intra-enterprise data integration” , che e’ esattamente la visione che abbiamo praticato da quattro anni a questa parte:

“….I think, that really what we have… the message has been… it was looking too far into the future. ….
… the gain from the Semantic Web comes much before that. So maybe we should have written about enterprise and intra-enterprise data integration and scientific data integration. So, I think, data integration is the name of the game. That’s happening, it’s showing benefits. Public data as well; public data is happening and it is providing the fodder for all kinds of mashups.
So, what we should realize is that the return on investment will come much earlier when we just have got this interoperable data that we can query over.”
E alla domanda di che libro dovrebbe scrivere ora, dopo la strada gia’ fatta dalle tecnologie semantiche, cioe’ di quale e’ l’argomento da fissare e organizzare, dimostra di nuovo di essere sui nostri stessi binari, parlando esplicitamete di architettura con cui il Semantic Web si deve integrare con il resto dell’esistente:

“I would like to write a whole bunch of technical books about actually practically how to do Semantic Web things. I’d like to write a book about Semantic Web Architecture. And I’d like to write a book sort of painting the path for people in the industry, because I get a lot of questions along the lines of “OK, I read the specs, OK, but here I am, I am the CIO of a company, what does it mean for us now, what should we do?”"
Non casualmente ci siamo gia’ occupati di questo argomento e ne parliamo al JavaOne.
Il tema e’ una architettura standard di integrazione per produrre metadati e dati semantici al fine di produrre semantic web e semantic integration.

TBL enfatizza piu’ volte che non vanno creati nuovi dati in forme nuove per avere il Semantic Web: il modo di trarre vantaggio dal Semantic Web c’e’ gia’ adesso e sta nell’utilizzare dati che gia’ esistono in forme eterogenee, e’ nell’integrazione dei dati attuali, presenti nei database, nei file system, nei dati interni delle applicazioni (CRM, ERP, sistemi documentali, wiki, blog, etc.):

“So, where is the data going to come from? It’s already there. It’s in databases. So, most of this data is in databases. Often the data is already available through some kind of a Web interface.”

C’e’ un punto dell’intervista in cui TBL si sofferma sul modo in cui si produce l’RDF (cioe’ il dato standard semantico a fronte del dato proprietario nel database), che ci porta proprio sul caso d’uso dei componenti JBI per il Semantic Web, soluzione che supera la via che TBL propone, e che secondo me e’ incongruente con la visione si architettura semantica detta sopra, perche’ troppo legata alla scrittura custom di codice:

“…. Well, there’s a couple of ways of doing it. Say that you’ve got a database-type website. One way to do it is to look at it… let’s stay with the printers, for example. When you look at the website you notice there’s a page on the printer, which has got the specifications, and it’s got a little table of the properties of the printer. And there’s a PHP script somewhere, which produces that.
So, you get somebody who understands these things to write another PHP script which is totally parallel, which just expresses the same information in RDF. That’s all. “

Lo scopo dei nostri BC JBI e’ proprio quello di non dover scrivere quel codice ma di configurare il componente sull’ESB perche’ cio’ avvenga automaticamente quando si inseriscono, modificano o cancellano i dati sul database o nel repository proprietario, creando cosi’ una architettura di integrazione semantica.

Commentero’ successivamente la seconda parte dell’intervista, che e’ lunghissima e densa di argomenti interessanti da approfondire.

Claudio Bergamini