Enterprise architecture ed esami di “maturità”

Tag

,

worry student have a problem with mathematics

Una delle frasi ricorrenti che sentiamo dire dai clienti quando proponiamo o iniziamo con loro un percorso di enterprise architecture è “non siamo ancora maturi”: i dati non sono maturi, l’organizzazione non è matura, le persone non sono mature…
Ma cosa significa “essere maturi” dal punto di vista dell’enterprise architecture e quando un’organizzazione può considerarsi tale?

Il grado di maturità è legato al livello di conoscenza, condivisione e accettazione nell’organizzazione del processo e del modello dati di enterprise architecture. Compito dell’enterprise architect è promuovere una visione d’insieme dell’azienda, integrando informazioni potenzialmente eterogenee con livelli di dettaglio differenti dalle diverse aree e riconducendole ad un modello comune e condiviso. L’obiettivo è allineare le iniziative di evoluzione IT alle strategie aziendali fornendo viste sui dati (business, architetturale, applicativa, infrastrutturale, organizzativa) adeguate alle esigenze dei vari interlocutori. Il livello di maturità dipende quindi da quanto il processo di enterprise architecture incide sulle decisioni all’interno dell’organizzazione.

Sfortunamente dati, organizzazione e persone non maturano da soli. Se i dati e il modello non sono gestiti si rischia di trarre conclusioni basate su una fotografia che non corrisponde più alla realtà. Aggiornare dei dati obsoleti può avere dei costi molto elevati perché il divario può diventare talmente alto da vanificare gli sforzi iniziali, il che equivale quasi a ripartire da zero. Se non si coinvolgono le persone nel miglioramento dell’enterprise architecture le decisioni possono apparire come calate dall’alto, le informazioni possono risultare incomplete, inesatte o non del grado di dettaglio utile, di fatto diminuendo la credibilità e il livello di condivisione del processo e del modello dell’EA.

La buona notizia è che un percorso di enterprise architecture può essere intrapreso in modo graduale. Quando un’organizzazione si interessa ai temi di EA perché è consapevole che dover ricostruire lo stato corrente dei propri sistemi a ogni nuova iniziativa non è utile né efficace ha già un grado di maturità sufficiente per iniziare. Si può partire da qualsiasi area, in generale quella su cui si ritiene di avere più informazioni o si pensa che siano più facili da recuperare (processi? applicazioni? infrastruttura?). Si può proseguire per passi, aggiungendo i dati necessari per lo scopo che si vuole ottenere, mantenendo aggiornati quelli esistenti e migliorandone la qualità, coinvolgendo gli interlocutori potenzialmente interessati e cercando di fornire ad ogni passaggio analisi e informazioni significative.

Non esiste quindi un esame di maturità finale perché non c’è un punto di arrivo definitivo. L’enterprise architecture è un’attività continua che deve seguire e agevolare i cambiamenti all’interno dell’organizzazione.

Innovazione e architetture IT

Tag

, , , ,

L’information technology (IT) genera innovazione continua e saperla accogliere all’interno del proprio sistema informativo è all’ordine del giorno di ogni azienda competitiva che eroga servizi software.

Nella mia esperienza, la sfida risiede nel coniugare i seguenti aspetti:

  • acquisizione di nuove competenze: l’utilizzo di tecnologie e metodologie emergenti richiedono formazione e un nuovo assetto nella gestione del personale. Questo investimento non è sostenibile da tutte le imprese e spesso si scontra con un organico sottodimensionato e già oberato di attività;
  • integrazione con i sistemi esistenti: un’azienda IT ha un sistema informativo basato su una pluralità di soluzioni software che si sono succedute nel tempo. Saper conciliare le nuove tecnologie con quelle già presenti è un punto cruciale per un’adozione fattibile;
  • aggiornamento dei processi aziendali: il governo di una tecnologia è una precondizione per il suo utilizzo continuativo nel tempo. L’impresa deve aggiornare i processi interni per una gestione corretta della propria normale operatività;
  • gestione del rischio: spesso il fattore che limita il “cambiamento” è la paura delle possibili conseguenze negative (frase tipica: “è sempre andato bene, perché cambiare?”). Deve essere la lungimiranza a guidare: l’integrazione di una nuova tecnologia deve avvenire attraverso un piano prestabilito con lo scopo di creare il minor numero di problemi a tutto l’ecosistema software esistente.

In questo scenario considero fondamentale l’architettura IT perché ha il compito di “abilitare all’innovazione”. Questa disciplina detta i principi base e le linee guida di evoluzione di un sistema software dal punto di vista sia tecnologico che di processo e con l’obiettivo di governare e ridurre le problematiche descritte.

La centralità delle architetture IT è rimarcata dal tema della multicanalità: i clienti che usufruivano di servizi erogati solo attraverso il Web ora richiedono di accedervi anche con altri strumenti quali smartphone e tablet.

Innovazione e multicanalità richiedono ai sistemi informativi una “maturità” valutata dall’architetto IT sulla base degli stessi principi con cui lui modella un’architettura:

  • genericità: l’architettura non deve dipendere da uno specifico scenario di utilizzo e da un insieme prestabilito di tecnologie. Deve essere in grado di adattarsi nel tempo a nuovi contesti;
  • disaccoppiamento: i pezzi che compongono il modello di un’architettura devono essere fra loro indipendenti. Si raggiunge questo concetto utilizzando standard open per realizzare le interazioni fra i vari componenti;
  • manutenibilità: ciascun componente architetturale ha un proprio ciclo di vita che deve essere indipendente dagli altri. In questo modo risulta più semplice la gestione delle evoluzioni e la risoluzione di errori;
  • facilità di integrazione: il modello architetturale deve essere tale da accogliere con semplicità nuovi componenti;
  • scalabilità: a fronte di un elevato utilizzo del sistema informativo deve essere possibile modificare l’architettura in modo tale da sostenere il nuovo carico.

Credo che l’architettura IT debba essere un elemento di continuità all’interno di un’azienda e che richieda personale dedicato: instaura un processo di cambiamento non solo del sistema informativo ma anche alla cultura stessa delle persone perché impatta il loro modo di lavorare e comunicare.

Solo con una reale presa di coscienza di questo tema è possibile fare il salto di qualità e dare la possibilità alla propria azienda di innovare.

Enterprise architecture: un interesse crescente

Tag

, ,

03rotterdam-oma-13-12-6345

Iwan Baan Photography, Rozenstraat 145, 1016 NP Amsterdam, The Netherlands e-mail: studio@iwan.com — all images © Iwan Baan 1996 – 2016

Negli ultimi decenni, per motivi economici, sociali e tecnologici la gestione di organizzazioni e aziende di grandi dimensioni ha raggiunto livelli di complessità tali da rendere insufficienti gli approcci classici. E’ stato quindi necessario individuare nuove metodologie, nuovi processi e nuovi strumenti. Per questo motivo si parla spesso di enterprise architecture come disciplina fondamentale per affrontare questa crescente complessità. Ma di che cosa si tratta e perché tanto interesse?

Se si pensa al significato più tradizionale del termine “architettura” viene in mente il disegno degli elementi che costituiscono una struttura e delle loro interazioni. L’enterprise architecture riprende questo concetto estendendolo alle organizzazioni. Fare enterprise architecture significa quindi descrivere l’architettura di un’organizzazione (enterprise) in tutti i suoi aspetti, a livello di business, di processi e di sistema informativo gestendo e analizzando i dati tramite metodologie adeguate. L’obiettivo è fornire le informazioni, le linee guida e gli strumenti necessari ai vari interlocutori per poter prendere decisioni consapevoli e avviare iniziative efficaci come risposta alle sfide e ai cambiamenti che coinvolgono le organizzazioni.

Nel settore finanziario una delle spinte principali che hanno incrementato l’interesse verso l’enterprise architecture è stata l’introduzione della normativa 263 della Banca d’Italia. Alcuni temi inseriti nella normativa sono la gestione dei rischi, della sicurezza, dei dati e della continuità operativa. Le banche hanno dovuto adeguarsi e, in qualche caso, dotarsi di processi e strumenti per governare i loro sistemi informativi.

Un altro fattore fondamentale è stato l’aumento del numero di fusioni e acquisizioni. Le società acquisite oltre ad essere strutturate in modo diverso hanno anche processi e IT eterogenei che occorre gestire e uniformare senza dare discontinuità di servizio, riducendo la complessità e i costi, mantenendo i dati ed eliminando eventuali duplicazioni funzionali. L’enterprise architecture fornisce la metodologia per costruire una mappa dei vari sistemi che lega le applicazioni ai processi di business e alle organizzazioni, fino alla parte tecnologica e infrastrutturale, in modo da poter valutare gli impatti dei cambiamenti, tempi, rischi e costi.

 

Affidabilità del software e semplicità delle architetture

Negli ultimi tempi sto affrontando tematiche relative a DevOps, container e infrastrutture resilienti. E sono sempre più convinto di un pensiero un po’ contro corrente nell’immaginario degli architetti software.

Spesso, per ottenere soluzioni in grado di resistere ai guasti, si realizzano architetture complicatissime. Configurazione e manutenzione di storage e application cluster sono aspetti che hanno impatto sul grado di affidabilità.
La configurazione e il test di sistemi complessi sono attività difficili. Nella mia esperienza di valutazione e revisione di architetture applicative mi è capitato spesso di notare che alla base della scarsa affidabilità di un sistema sono proprio le configurazioni sbagliate delle componenti utilizzate per proteggere dal fallimento.

Mantenere il sistema più semplice possibile, quindi, è un obiettivo da perseguire nella progettazione del software e delle infrastrutture. In certi casi conviene mettere in conto fallimenti, purché accadano di rado. Ripristinare un sistema più semplice è un’attività che avviene in tempi rapidi.

Dunque, quale può essere una strategia vincente? Non cercare di evitare tutti i possibili disastri, ma fare in modo di essere sicuri di poter gestire le conseguenze in modo semplice. Soprattutto quando questo semplifica molto il sistema che stiamo realizzando.

Aziende sull’orlo di una crisi di nervi

Tag

,

Citazione dal file "Tempi moderni"

Citazione dal file “Tempi moderni”

Negli ultimi anni abbiamo assistito a una serie di cambiamenti che hanno messo in crisi le aziende su molti aspetti. Uso l’espressione “crisi di nervi” perché nelle aziende sono saltati, o stanno saltando, i modelli tradizionali di gestione [001].

Ma cosa è realmente successo alle organizzazioni?

A mio parere, 2 parole chiave archiviate con il XX secolo sono ‹‹pianificazione›› e ‹‹isolamento››: due concetti fondanti del taylorismo [002] e più in generale delle teorie manageriali [003].

Non è un caso che negli ultimi anni siano emerse molte discipline alternative, spesso identificate con il termine ‹‹agile management›› [004]. Tuttavia queste discipline sono spesso applicate in contesti verticali e di piccole dimensioni, per cui non possono incidere in modo significativo sull’organizzazione nel suo complesso.

Ma cosa non funziona più?

In termini organizzativi si è sempre seguito il concetto del ‹‹dividi et impera››, che gli inglesi hanno poi tradotto in segregation of duties. Si è sempre pensato di poter suddividere le funzioni aziendali, e in particolare quelle operative, in attività singole e indipendenti.

Una volta suddivise le attività, e quindi le responsabilità, è sufficiente avere un gruppo di lavoro specializzato per ogni attività e un livello superiore di controllo per verificare gli avanzamenti o, più in generale, le performance.

Questo modello funziona bene se l’azienda è capace di pianificare con continuità le proprie scadenze. Se invece il lavoro diventa discontinuo, come nei mercati attuali, allora ci sono molte più giornate con un fermo di produzione e questo è un problema serio quando si segue il modello della fabbrica.

In pratica, il gruppo di lavoro risulta sovradimensionato rispetto alla mole assoluta degli ordini, ma non può essere ridimensionato perché non sarebbe in grado di far fronte ai picchi di lavoro. Allo stesso tempo c’è il rischio di avere altri gruppi sottodimensionati, ma di non poterli aiutare perché l’isolamento organizzativo impedisce di fatto una collaborazione.

In questo caso il primo effetto evidente è la riduzione dei margini operativi [005] delle aziende e quindi occorre una spinta sul management per cercare di cambiare le cose.

Ma perché l’isolamento organizzativo amplifica il problema?

In base alle teorie di Taylor, per ogni mansione viene identificato un profilo ideale di lavoratore, uno specialista.

Questo significa che se un gruppo di lavoro risulta sovradimensionato, allora è difficile ricollocare le persone in altri gruppi proprio perché sprovviste delle competenze necessarie.

Inoltre, per le stesse teorie, non è banale nemmeno pensare di riqualificare le persone per favorirne l’inserimento in nuovi gruppi: potenzialmente è troppo grande il divario tra i profili diversi per pensare a una formazione utile in concreto [006].

In questo scenario, le risposte in termini gestionali sono state:

  • Lasciare le cose come stanno e lavorare sul flusso e il volume degli ordini
  • Licenziare il personale in eccesso e assumere le figure che mancano
  • Esternalizzare le parti di produzione più difficili da dimensionare.

La prima risposta è la preferibile perché ricrea il contesto originale di funzionamento dell’azienda e quindi risolve i problemi, ma è anche la più difficile da realizzare.

La seconda è quella più banale ma meno interessante, perché rinvia solo il problema nel tempo e causa forti tensioni sul personale, e introduce altri fattori di rischio.

La terza è l’opzione che consente i risultati migliori nel breve periodo, ma sposta il problema sui fornitori anziché risolvere effettivamente il problema. In ogni caso, questa opzione è largamente utilizzata [007]: l’azienda può così dedicarsi agli aspetti di maggior valore aggiunto e acquistare sul mercato quello che manca per la creazione di prodotti e servizi.

Quindi problema risolto? … nemmeno per sogno!

Quando viene esternalizzata una parte dell’azienda c’è una perdita di conoscenze che può tradursi in una minor competitività dell’azienda.

A questo si deve aggiungere il rischio di dipendere da uno o più fornitori. È una situazione che ho potuto osservare personalmente molte volte: l’azienda si riduce alla gestione del brand e alla rivendita di prodotti e servizi pensati da altri, mentre le attività di ricerca e sviluppo restano limitate.

Per queste ragioni è importante pensare soluzioni organizzative diverse.

AAA cercasi T-shape person !!! [008]

Dopo anni di ricerca del profilo ideale e con la massima specializzazione, ora dobbiamo cercare profili più flessibili. Figure capaci di dialogare con persone che lavorano su diverse discipline e che, quando serve, possano offrire loro un supporto.

T

Non ho statistiche ma riporto la mia esperienza diretta a supporto della funzione HR della mia azienda.

Ho l’impressione che i profili flessibili siano molto difficili da trovare. Noi, per esempio, selezioniamo laureati con voti molto alti e quelli che si inseriscono meglio in azienda sono persone con forti interessi extra lavorativi … Ogni tanto scherzo con i colleghi dicendo che per noi tutti in verità questo è un secondo lavoro, perché il primo è altrove.

Questo è comunque solo l’inizio!

Se lasciati fermi su un ruolo troppo a lungo allora queste persone perdono l’abitudine al confronto e al cambiamento. Pur partendo da una risorsa più flessibile c’è il rischio che tali caratteristiche vadano perdute perché azienda e lavoratore sono rimasti nella propria comfort zone [009] per troppo tempo.

Gestire questo tipo di risorse è quindi molto più complesso rispetto alla gestione di specialisti su incarichi immutabili (o quasi), perché anche l’azienda deve evolversi culturalmente per sostenere questo tipo di situazione.

Ovviamente le figure specialistiche non devono sparire, ma non possono essere predominanti altrimenti l’azienda risulta troppo resistente al cambiamento.

Altre forme di isolamento organizzativo: il sistema di budgeting [011]

Fin qui abbiamo parlato di risorse umane, ma supponiamo per un attimo di avere persone completamente intercambiabili. Riusciremmo a spostare le persone dove serve? … Forse sì o forse no!

Per farlo, i manager delle strutture organizzative classiche [012] dovrebbero usare le proprie risorse per raggiungere gli obiettivi di altri gruppi di lavoro oppure dipendere da altri per conseguire i propri.

E, in particolare, se un gruppo di lavoro è riconducibile a un centro di costo [013] o a un budget predefinito, i diversi manager coinvolti devono trovare una serie di regole di ingaggio per poter attribuire in modo corretto le competenze dei costi relativi al l’uso delle risorse.

Difficile pensare che questi accordi siano veloci e indolore. È più facile immaginare lunghe ed estenuanti riunioni fra chi ha l’opportunità di trovarsi in una posizione dominante e chi rischia di fallire i propri obiettivi.

Purtroppo ho vissuto più volte situazioni di questo genere e non si sono mai tradotte in maggior flessibilità.

Verso la distensione

È quindi facile capire perché le aziende siano sull’orlo di una crisi di nervi. Esse debbono infatti:

  • Rivedere la strategia sulle risorse umane
  • Capire come attuare una strategia di esternalizzazione che non impoverisca l’azienda
  • Rivedere il sistema di budgeting per facilitare gli obiettivi aziendali a scapito di quelli dei singoli manager

Tutto questo ovviamente continuando a fare business.

C’è quindi tanto da fare e, come dice un mio cliente, al cambiamento siamo tutti favorevoli purché a cambiare siano gli altri [014]. Difficile quindi indicare da dove iniziare.

In ogni caso, come consulente devo iniziare a pormi la domanda e, se possibile, anche ad abbozzare una risposta.

Prima di tutto penso che gli interventi debbano essere piccoli, costanti e progressivi. Diversamente le incognite crescono più velocemente rispetto alla nostra capacità di analizzarle e affrontarle, ottenendo il cosiddetto effetto farfalla [015].

Si potrebbe quindi pensare che una delle funzioni aziendale in cui l’azienda studia se stessa, così da poter individuare i punti su cui intervenire di cesello anziché con ristrutturazioni pesanti e dolorose.

In questo contesto l’Enterprise Architecture [016] è la disciplina che potrebbe svolgere tale funzione.

Questo gruppo di lavoro dovrà essere collocato il più vicino possibile al vertice aziendale, in modo tale da poter influire in modo concreto. Diversamente, si rischia di introdurre un costo senza capirne bene i vantaggi.

Questo gruppo deve analizzare i diversi settori dell’azienda, per cui è importante che sia composto da persone con diverse competenze. In questo modo le soluzioni proposte saranno più adatte alla complessità della situazione esaminata [017].

È quindi impossibile indicare l’elenco delle soluzioni da applicare a tavolino, perché ogni azienda avrà le sue caratteristiche. Una cosa è certa: il vertice aziendale dovrà dare prova di coraggio perché, come diceva Winston Churchill, il coraggio è la prima delle qualità umane, perché garantisce tutte le altre.

 

Riferimenti

[001] www.treccani.it/enciclopedia/l-impresa-di-terzo-millennio_(XXI-Secolo)

[002] https://it.wikipedia.org/wiki/Taylorismo

[003] https://it.wikipedia.org/wiki/Direzione_aziendale

[004] https://en.wikipedia.org/wiki/Agile_management

[005] https://it.wikipedia.org/wiki/Margine_operativo_lordo

[006] http://www.aidp.it/riviste/articolo.php?id=1&ida=1318&idn=156&idx=

[007] http://adapt.it/adapt-indice-a-z/wp-content/uploads/2013/07/Esternalizzazioni_in_Italia.pdf

[008] https://en.wikipedia.org/wiki/T-shaped_skills

[009] https://en.wikipedia.org/wiki/Comfort_zone

[011] https://it.wikipedia.org/wiki/Controllo_di_gestione

[012] https://it.wikipedia.org/wiki/Organizzazione_aziendale#Macrostruttura_a_matrice

[013] https://en.wikipedia.org/wiki/Cost_centre_(business)

[014] www.slideshare.net/cbergamini/governare-la-complessita-e-favorire-il-cambiamento

[015] https://it.wikipedia.org/wiki/Effetto_farfalla

[016] https://it.wikipedia.org/wiki/Enterprise_architecture

[017] https://en.wikipedia.org/wiki/Variety_(cybernetics)

 

Motore di ricerca semantico in ambito enterprise per facilitare la gestione delle informazioni

Nella primavera del 2015 abbiamo effettuato una riunione con un nostro cliente storico per riprogettare alcune componenti del suo parco applicativo, che ha le seguenti caratteristiche:

  • applicativi differenti, ognuno con le sue informazioni (parco dati);
  • ogni applicativo gestisce le informazioni e il modo di reperirle in maniera differente;
  • l’utente deve conoscere i percorsi di ricerca specifici per ogni applicativo;
  • i dati sono disomogenei tra gli applicativi, di conseguenza per trovare o gestire una determinata informazione può rendersi necessario effettuare ricerche su più applicativi.

Nel corso della riunione è emersa l’idea di creare un motore ricerca semantico Google style per valorizzare e facilitare la gestione dell’enorme insieme di informazioni memorizzate e gestite dai vari applicativi:

  • oltre 1000 servizi;
  • applicazioni e integratori per un totale di 1200 installazioni;
  • oltre 13 milioni di anagrafiche.

Motore di ricerca Imola Informatica

Il motore di ricerca è una soluzione un po’ fuori dagli schemi:

  • l’utente ricerca un’informazioni sui dati di tutti gli applicativi contemporaneamente; è poi il motore di ricerca a suggerire all’utente su quali applicativi specifici è presente l’informazione ricercata.
  • è possibile, attraverso il motore di ricerca, aprire l’applicativo che gestisce o contiene l’informazione, facilitando e velocizzando il lavoro quotidiano dell’utente.

Per ottenere un risultato analogo si dovrebbe riprogettare ed integrare gli applicativi con costi decisamente superiori. Il motore di ricerca fornisce una nuova modalità di ricerca mantenendo le logiche di scrittura e l’indipendenza delle applicazioni.

Perché un motore di ricerca semantico? Le informazioni hanno un significato specifico all’interno degli applicativi di provenienza. Il motore di ricerca deve mantenere questa peculiarità e contemporaneamente utilizzarla per raggruppare e categorizzare le informazioni. Le tecnologie semantiche sono utili per raggiungere l’obiettivo in quanto, da un lato consentono di creare un modello di alto livello con all’interno tutti i significati attribuibili alle informazioni e dall’altro permettono di mappare sul modello le informazioni gestite dai sistemi, così da renderle omogenee per l’utilizzatore finale. Ad esempio, il concetto di anagrafica della persona è unico, ma le singole istanze sono trattate differentemente da applicativo ad applicativo (informazioni gestite, persistenza, … ): quando un motore di ricerca le indicizza, deve riconoscere che si tratta di anagrafiche di persona e, nel caso, di una stessa persona.

Il risultato ottenuto è una visione dei dati ad alto livello che mantiene allo stesso tempo l’eterogeneità delle fonti dei dati.

Il supporto dell’approccio semantico consente inoltre di mettere le informazioni in relazione le une con le altre. Ad esempio: una persona ha un indirizzo inerente ad una città; la città, a sua volta, è un concetto legato a molte altre informazioni . Si crea quindi un grafo navigabile di relazioni. Il grafo è estendibile senza modificare le informazioni indicizzate.

In questo modo è possibile eseguire ricerche su informazioni di tipo differente evitando la replicazione. Ad esempio: cercando “Imola”, si può ottenere Imola come città, ma navigando il grafo si possono ottenere tutte le aziende che hanno delle sedi a Imola e quindi le persone che vi lavorano.

Utilizzando un motore di ricerca tradizionale, si sarebbero potuti ottenere risultati analoghi mettendo in ogni blocco di informazioni anche le altre informazioni ad esso correlate, ad esempio indicizzando le anagrafiche assieme alle informazioni sulla città, l’azienda in cui si lavora e quant’altro. Senza il motore semantico le correlazioni sono pensate durante l’indicizzazione dei dati, con il supporto semantico occorre conoscere il modello e durante la ricerca navigare il grafo per un adeguato numero di livelli. Un’eventuale cambio di correlazioni porta da un lato a dover modificare tutti i dati indicizzati, dall’altro a cambiare solamente il modello semantico.

Le performance cambiano. Il supporto semantico risulta meno performante in quanto deve risolvere i livelli di navigazione del grafo. I dati sono denormalizzati in entrambi i casi, garantendo le prestazioni su grosse moli di dati. Si tratta di un piccolo costo da pagare per avere una elevata dinamicità nell’aggregazione dei dati.

Per il POC che abbiamo implementato abbiamo usato:

  • Virtuoso come storage (Triple Store), che fornisce anche un endpoint SPARQL;
  • SPARQL come linguaggio di interrogazione;
  • OWL / RDF come linguaggio per la modellazione delle informazioni di dominio (modello);
  • JAVA per il front-end.

Dal punto di vista architetturale Virtuoso rappresenta lo strato di persistenza, mentre il front-end Java implementa il layer di presentazione, in cui presentiamo dinamicamente le informazioni ricercate, un layer di logica applicativa che permette di attuare:

  • logiche di autorizzazione;
  • logiche autenticazione;
  • logiche di reperimento di dati per contestualizzare i risultati della ricerca;
  • un layer di accesso ai dati.

Per quanto riguarda la presentazione Google style delle informazioni, oltre ad elencare i dati e a creare i “link” per aprirli nei corrispondenti applicativi, è stato anche introdotto un sistema che mostra dinamicamente le informazioni correlate al singolo risultato della ricerca, in modo tale da contestualizzarlo, ampliarlo e facilitare quindi l’operatore nell’individuare l’informazione di suo interesse. Cercando ad esempio “Mario Rossi”, oltre al nome ed il cognome vengo mostrati il codice fiscale, il luogo di residenza e l’azienda pressa la quale lavora.

Motore di ricerca Imola Informatica - Risultati

Il Proof Of Concept (POC) è stato realizzato in 10-15 giornate, avendo una piena conoscenza del dominio. Il cliente ha apprezzato il POC, che verrà evoluto ampliando il numero di concetti all’interno del modello e la quantità di informazioni presenti, modificando di conseguenza l’interfaccia grafica.

 

Andrea Ravagli

Francesco Panico

Normanno Cacciari

Complicato e Complesso. Cosa fare di diverso?

Ho dedicato il post precedente a chiarire -spero- la differenza tra situazioni Complicate e Complesse, vista l’ambiguità della lingua parlata italiana in proposito.

Nella realtà quotidiana non è facile distinguere nettamente le due situazioni, che spesso compaiono insieme creando terreno fertile per valutazioni errate.
E’ infatti molto frequente che si estragga una parte del problema, la si definisca -correttamente- Complicata, e da lì si ottenga la conferma che lo stile giusto di gestione è quello di sempre.
Parto innanzitutto a definire lo stile di gestione “ di sempre” che ha portato organizzazioni e società a risultati sensazionali, frutto di miglioramenti iniziati a inizio secolo scorso e tuttora in corso. 
E’ uno stile adatto ai Sistemi Complicati, che posso riassumere nel modo seguente:
  • Prendere decisioni – trovare la scelta migliore
  • Definire i ruoli e responsabilità – per le attività che vanno svolte
  • Definire il piano – utilizzando le priorità e la catena di comando
  • Governare – decidere e dire agli altri cosa devono fare
  • Controllare – allineare e mantenere il focus sull’obbiettivo

Building

Con questo approccio siamo andati sulla luna, abbiamo costruito edifici e città, abbiamo trapiantato cuori, faremo ancora milioni di cose nuove. Farlo è familiare, dà un senso di sicurezza, ha portato a grandi risultati. Perché confutarlo?

Ecco la mia risposta.

Perché oggi frequentemente non basta, e non mi sembra opportuno accontentarsi.
Mi sembra abbastanza evidente che a fronte di situazioni in cui semplice, complicato e complesso si mischiano occorra pensare meglio ad approcci migliori, che facciano distinzioni e gestiscano in modo appropriato le diverse parti.
Ci sono molte situazioni in cui è possibile attribuire una Responsabilità: per andare sulla luna Houston ha la responsabilità,  il chirurgo ha la responsabilità del trapianto,  l’ingegnere ha la responsabilità dell’edificio o del piano regolatore.
La Responsabilità dà il potere di gestire con lo stile descritto sopra.
Ma ci sono casi in cui la eventuale Responsabilità non dà questo potere: quando il risultato emerge da una creazione non possibile con la coercizione, dalla collaborazione, dall’interazione delle varie parti.
Basta pensare ad un bambino recalcitrante o ai dipendenti di una azienda o agli abitanti di una città, per rendersi conto che le relazioni non permettono di prevedere un controllo efficace, qualsiasi buon piano io abbia fatto.

Se i risultati che vogliamo ottenere dipendono dalla collaborazione e co-creazione e non possediamo espliciti e definitivi strumenti di controllo, allora probabilmente lo stile che abbiamo usato finora non è il migliore.
Quale stile funziona meglio nei Sistemi Complessi?

  • Costruire le relazioni – pattern utili di interazione
  • Sense making – interpretazione allargata della situazione
  • Loose coupling – supporto alle Comunità di Pratica e aggiunta di autonomia
  • Apprendimento – agire/imparare/pianificare nello stesso tempo
  • Osservare cosa emerge – costruire sulle evidenze di buon risultato

child

By Tom Jacobs

Quando non possiamo specificare -in senso ingegneristico- né determinare cosa vogliamo ottenere, dobbiamo adeguare il nostro stile e abilitare i risultati intervenendo sul sistema.
Quando non è possibile pensare che con una correzione si aggiusti tutto, allora devo cercare i punti di leva che devo cambiare per migliorare il sistema.
Ad esempio posso cambiare quello che le persone fanno, e dovrò quindi cambiare le regole attuali, che faranno cambiare le relazioni, le reti e i comportamenti, e sarò costretto a cambiare gli strumenti.
Parlando di organizzazioni cambieranno le regole, le norme tacite di comportamento, come vengono gestiti i conflitti, gli errori, il potere, le linee guida e le checklist.

Il bello è che probabilmente se mi comporto nello stesso modo in due comunità diverse -aziende, quartieri, città, mercati-, otterrò due risultati diversi: magari buoni risultati, ma diversi. 
I risultati dipendono dal contesto, dal momento, dalla cultura e dai valori della comunità e lo stile diverso, in ultima analisi, consiste nel tenerne conto.

Complicato o complesso ?

Mi è servito un sondaggio tra colleghi e clienti per decidere di scrivere con l’obiettivo di chiarire la differenza tra complicato e complesso, che nel linguaggio comune vengono utilizzati in modo pressoché intercambiabile.

Ho scoperto con sorpresa che il linguaggio che utilizzo normalmente non è affatto chiaro agli altri, ma immediatamente mi sono sorpreso di essermi sorpreso.
Quindi cerco di chiarire i termini, per poi parlare delle implicazioni.
Con COMPLICATO definiamo un problema o una situazione che siamo in grado di descrivere compiutamente, di cui siamo in grado di definire una strategia e un piano per affrontarlo, dei tempi e delle milestones per arrivare a un risultato che siamo in grado di descrivere.
Con COMPLESSO definiamo invece una situazione in cui non siamo in grado di definire una serie di milestones precise, dei tempi precisi e un risultato preciso da raggiungere.
Sono definizioni un po’ grossolane rispetto a quanto si trova in letteratura, ma secondo me rendono bene l’idea.
Uso alcuni esempi tipici per tradurre in pratica:
COMPLICATO: assemblare un mobile dell’IKEA, mandare un razzo sulla luna, smontare e rimontare un orologio, costruire una barca.
La complicazione può venire dalla vastità del compito e dagli skill molteplici che sono necessari, ma se della situazione conosco cosa so fare e cosa non so fare,sono comunque in grado di descrivere i passi certi per arrivare ad una risoluzione.
COMPLESSO: crescere bene un figlio, impostare un piano strategico – che funzioni -, gestire un gruppo di persone, realizzare un progetto software grosso che non ho mai fatto prima, gestire un’azienda, o l’IT di una azienda.
Complexity Cloud
In altre parole, se esiste una ricetta, pur con molti ingredienti e con molti step, se anche non ho alcuni degli ingredienti e non so fare alcuni step, posso comunque procurarmi ciò che manca ed essere pressoché sicuro del risultato. E si tratta di situazioni complicate.
E’ abbastanza chiaro che tutte le volte in cui sono coinvolte persone non come “ingranaggi di un orologio”, cioè esecutori di procedure, ma come elementi portanti di un’attività che ha interconnessioni ed evoluzioni nel tempo, siamo di fronte a problemi complessi.
I sistemi complicati sono predicibili. Li possiamo prendere, separare nelle parti, capire le interazioni, e riprodurre. A meno di errori di esecuzione, sono in grado di ripetere l’evento.
Per i sistemi complessi non è così. Per quanti figli io possa avere non ne usciranno mai due uguali, per quante aziende abbia gestito non potrò mai garantire che fare le cose che ho fatto in una farà funzionare la prossima. I sistemi complessi sono in larga parte impredicibili, e quando li sollecito con un’azione non so con certezza cosa aspettarmi (a meno che non sia un peccatore cronico di “overconfidence”).
L’incertezza è sovrana, averlo fatto bene una volta non dà garanzie per la prossima, non ho garanzie di successo. Molte volte non riesco nemmeno a definire esattamente cosa sia il successo.
Per riassumere:
Sistemi complicati (come costruire una barca)
  1. Le formule sono critiche e necessarie
  2. Riuscire una volta garantisce che anche la prossima riuscirà
  3. Servono livelli di esperienza adeguati nei diversi campi coinvolti
  4. Ci sono molte similitudini (se non uguaglianza) tra le ripetizioni
  5. Ci sono alti livelli di certezza sul risultato
Sistemi complessi (come crescere un figlio o gestire un gruppo di persone)
  1. Le formule hanno un’applicazione limitata
  2. Riuscire una volta dà esperienza, ma non garantisce il risultato ripetibile
  3. L’esperienza è necessaria, ma non sufficiente
  4. Ogni persona o gruppo è unico (e cambia nel tempo) nelle caratteristiche, e le relazioni sono fondamentali
  5. Ci sono bassi livelli di certezza sui risultati
Una prima conclusione che si può trarre è che lo stile con cui si affrontano situazioni complicate e complesse non può essere lo stesso.
Mentre per le prime ho una relazione diretta tra causa ed effetto, cosa che mi permette uno stile di monitoraggio e gestione consolidato e abbastanza ripetitivo, per le seconde le indicazioni devono servire a capire i trend e i modelli di comportamento del “sistema” per giurarlo nella direzione giusta tenendo conto che un’azione provocherà sicuramente reazioni che non sono in grado di predire con certezza.
Prossimamente cercherò di illustrare gli stili più appropriati per affrontare situazioni complicate e complesse, sempre cercando di essere molto pratico.

Al ritorno dalla Complexity Management Summer School

Tag

,

Vi risparmio la faccia tra il compatimento e il sarcastico di mio figlio quando gli ho detto un paio di mesi fa: “A cavallo di luglio e agosto vado per dieci giorni a seguire un corso”.

“Spero che ne valga la pena” gli ho risposto, e adesso posso dire che ne valeva proprio la pena. Quindi vorrei condividere l’esperienza della partecipazione alla Complexity Management Summer School.

 Image
Innanzi tutto è stata una fatica fantastica.
Dieci giorni e parecchie notti di una intensità pazzesca, con una batteria di “docenti” e ospiti da favola e una ventina di alunni estremamente “intriganti” per varietà di estrazione: dal fotografo professionista, al direttore d’ospedale, al responsabile della innovazione, all’imprenditore belga, al responsabile dell’Enterprise Architecture di una banca, all’HR, alla Social Responsability, e così via.
I docenti restavano a disposizione per 4-5 giorni di cui 1 e mezzo a fare lezioni, giochi, laboratori e “community” o consulenze personali (anche in team) per il resto del tempo.
Diciamo che ci si poteva “ubriacare” facilmente con le diverse sfaccettature della complessità: l’aspetto filosofico, sociologico, tecnologico, organizzativo sono stati quelli più nettamente emersi durante il “corso”.
Per farla molto breve quello che ho imparato è che c’è un tipo di complessità oggettivamente evidente ma spesso non considerata: la complessità sociale.
Il fatto cioè che in qualsiasi aggregato di persone ognuna è un individuo con una sua visione di sé, degli altri (come genere) e del mondo ai vari livelli che si intersecano (la famiglia, le comunità in cui vive -città, azienda, etc.-) e che porta questo suo “essere e credere” nelle interazioni che ha con gli altri, influenzando con la sola sua presenza il comportamento di ognuna di queste.
Alla faccia del disegnare le organizzazioni con rettangoli e frecce!!
Tenere conto della complessità sociale significa tenere conto di questo aspetto, e quindi essere consapevoli della realtà che il comportamento degli aggregati di persone è largamente impredicibile, quindi occorre guidarlo dolcemente piuttosto che prescrivere. La prescrizione influenza i comportamenti pressoché sempre in modo negativo, e sono veramente pochi i casi -almeno nel knowledge work- in cui una prescrizione viene vista come una indicazione chiara da supportare.
La mia conclusione è che tutte le organizzazioni sono socialmente complesse per definizione e gli stili correnti di gestione (command and control) vengono sopportati ma non supportati, con la conseguenza diretta che le persone si difendono anziché partecipare.
Un po’ di riferimenti sui docenti, per chi avesse interesse a leggere.
Alberto De Toni e, particolarmente didattiche le slide 
Alberto Gandolfi su Google Scholar
Valerio Eletti  con un sacco di belle presentazioni 
e l’ospite “off the records” che ci ha mostrato che è possibile cambiare le organizzazioni:
Beppe Carrella e il suo BClab e il suo eBook scaricabile “Provocazioni Manageriali” 
Chi è interessato a qualche approfondimento, non deve fare altro che chiedere.

Enterprise (Linked) Open Data

Tag

, , , , , ,

WildHorsesHeaderDopo 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