Sono stato assente per qualche mese...

...ho avuto la possibilità (unica nella vita! troppo importante per rinunciarvi!) di prestare qualche mese di consulenza per una delle più prestigiose aziende ICT del mondo... che ovviamente non posso rivelare per vincoli di riservatezza...

Durante qusto periodo sono stato nel cuore della Silicon Valley... Beh la trasferta mi è costata un botto (la consulenza era a titolo gratuito!) però ho avuto modo di presentare la mia visione sui dispositivi di memorizzazione a sola scrittura che si rivelano utilissimi per la storicizzazione dei Big&LargeData, permettendo una compressione elevatissima dell'informazione.

Ora non posso dilungarmi, però conto di fare un articolo e delle slide dedicate al tema.

Debriefing inglese o italiano? C'è differenza!

La scorsa settimana ho partecipato a un meeting internazionale a New York su XPDL. Al ritorno da New York, il volo ha subito un ritardo di 4 ore.

Rientrato in ufficio, il giorno successivo, ero stanichssimo e ancora non avevo smaltito la differenza di fuso orario.

Il Capo mi ha subito convocato nel suo ufficio per un veloce Debriefing (inglese) di sole 4 ore! Immediatamente dopo il primo ho sentito l'esigenza di un secondo e totalmente diverso Debriefing (italiano)!

La Turing-SOA permette un migliore allineamento Business-IT

La Service Oriented Architecture è molto di più di una semplice tecnologia: è un'architettura che utilizza una logica orientata ai servizi per supportare le esigenze degli utenti scomponendo le applicazioni in funzioni riutilizzabili. In questo modo, consente di allineare business e IT rendendo i processi più flessibili, economici ed efficienti. (IBM)

Uno dei paradigmi più noti delle composizioni di servizi è l’orchestrazione, in base al quale un processo centralizzato interagisce con un insieme di servizi componenti. Il linguaggio utilizzato per la definizione di un’orchestrazione è il BPEL (Business Process Execution Language for Web Service).

Un processo BPEL racchiude le attività necessarie a comporre diversi servizi sviluppati da terze parti. I passi di elaborazione di un processo può essere rappresentato con un automa a stati finiti. Ad un certo punto dell’esecuzione del processo BPEL questi servizi potrebbero essere soggetti a un cambiamento radicale o potrebbero non essere più disponibili. Questo è uno dei limiti della staticità di un sistema basato sulla SOA.

Orchestrazione di servizi tramite un processo BPEL

Per superare questa staticità è possibile prendere ispirazione dalla Macchina di Turing (MdT). Una MdT è un'astrazione che permette di elaborare un qualunque algoritmo. Si compone di un'unità di controllo, che può assumere una serie finita di diversi stati e una unità di memoria, esemplificata con una successione di caselle lungo un nastro di dimensioni infinite. Una elaborazione comincia da una casella di memoria iniziale; il passaggio da uno stato all'altro nell'unita di controllo è regolato da una tabella di istruzioni, in cui lo stato attuale, e la lettura dalla casella di memoria corrente, stabiliscono il nuovo stato. In pratica anche l'unità di controllo di una MdT implementa un automa a stati finiti. Ad ogni passo la TM può fare soltanto le seguenti mosse:

1. leggere il dato nella casella di memoria corrente
2. scrivere un nuovo dato nella casella di memoria corrente
3. spostarsi in avanti nel nastro
4. spostarsi indietro nel nastro
5. cambiare il suo stato interno

Macchina di Turing

Un'architettura SOA basata su un Process Server (che esegue processi BPEL) può essere facilmente assimilata a una MdT. Se si suddivide opportunamente l'elaborazione in passi elementari è possibile ridurre la complessità delle elaborazioni effettuate dai servizi orchestrati. Spingendosi oltre è possibile concentrare tutta la logica elaborativa nel processo BPEL, demandando ai servizi la sola scrittura e lettura di un dato elementare in una "casella di memoria". In questo modo l'elaborazione sarebbe definita solamente attraverso il processo. Per ogni tipo di elaborazione è possibile implementare uno specifico processo e riutilizzare completamente i servizi. In questo modo si rende molto più flessibile l'infrastruttura IT, permettendo un più veloce allinemanto Business-IT. Inoltre i servizi non dovrebbero mai essere cambiati e si eliminerebbe definitivamente il problema sopra evidenziato della staticità della SOA. I servizi inoltre sarebbero completamente sostituibili in modo da semplificare la scalabilità e l'alta disponibilità del sistema.

Il periodo più favorevole ai dirigenti Italiani?

Quanti di voi hanno la sventura di aver assistito (o subìto) una discussione tra un dirigente (D) e un suo sottoposto (S) che, più o meno, ricalca i ritmi indicati di seguito?

D : "Se tu mi avessi informato prima dei problemi con l'altra area, io sarei intervenuto in modo decisivo per risolverli"
S : "In verità l'ho fatto, ti ho inviato due email a riguardo diversi mesi fa"
D : "Sì, vero, ma se tu fossi stato più chiaro nell'email, io avrei capito la criticità e sarei intervenuto"
S : "Pensavo che, durante la riunione che hai indetto a seguito della seconda email, il problema fosse stato ben analizzato e compreso da tutti noi"
D : "Se fosse stato ben analizzato e compreso da tutti noi, come sostieni tu, io l'avrei gestito!"

...e così la colpa ricade sul sottoposto oppure, se il Dirigente ha un minimo di dignità, il problema viene ridefinito come "di comunicazione", attribuendolo quindi a una entità impersonale.

Dopo aver assistito a molte conversazioni simili, sono giunto alla conclusione che il periodo più favorevole ai dirigenti italiani è quello "ipotetico del terzo tipo o dell'immpossibilità"!

Cosa è un periodo ipotetico del terzo tipo? E perché è quello più favorevole ai dirigenti italiani?

Il periodo ipotetico (da Wikipedia) è una struttura sintattica composta da una proposizione subordinata condizionale (detta anche protasi) e dalla sua reggente (detta anche apodosi). La subordinata è introdotta dalla congiunzione se ed esprime la premessa, cioè la condizione da cui dipende quanto predicato nella reggente; la reggente indica la conseguenza che deriva o deriverebbe dal realizzarsi della condizione espressa dalla proposizione subordinata.

Il periodo ipotetico viene tradizionalmente distinto in tre tipi, a seconda del grado di probabilità dei fatti indicati nella condizionale. Si parla allora di periodo ipotetico

1. di primo tipo o della realtà quando l'ipotesi è presentata come un fatto reale o sicuro; 
2. di secondo tipo o della possibilità quando l'ipotesi è presentata come un fatto non sicuro ma probabile;
3. di terzo tipo o della impossibilità quando l'ipotesi è presentata come un fatto impossibile;

In particolare nel periodo ipotetico di terzo tipo la protasi è al congiuntivo trapassato e l'apodosi è al condizionale passato.

L'uso del congiuntivo trapassato fa ben capire che l'azione indicata nella premessa non è più realizzabile. Ma proprio essendo oramai irrealizzabile, questo costrutto linguistico presenta un vantaggio per il dirigente non da poco: è difficile da confutare!

E' possibile sostituire i dirigenti con un algoritmo? (1)

Osservando attentamente, per anni, il lavoro di diversi dirigenti (nel settore ICT in Italia, ma credo si possa generalizzare ben oltre questo contesto) ho riscontrato un modo di lavorare abbastanza omogeneo tra le diverse persone. Quasi come se tutti i dirigenti che ho incontrato avessero seguito lo stesso corso di "management"! Forse, semplicemente, i comportamenti da me notati sono quelli che più facilmente permettono di ottenere un avanzamento nella carriera. Credo che il modo con cui le organizzazioni selezionano il personale da promuovere alla carriera direttiva sia una delle maggiori cause della loro inefficienza.

Già dopo poco tempo di osservazione si è insinuato in me il dubbio... E' possibile sostituire questo tipo di dirigenti con un algoritmo? 

Lasciando l'analisi degli effetti di questo approccio a un prossimo post, di seguito provo a riportare i lineamenti dell'algoritmo che vorrei provare. In futuro penso di creare un progetto open source per implementare l'algoritmo (si cercano collaboratori). Il software si potrebbe validare in azienda utilizzando qualche dirigente reale come oracolo.

Il dirigente è modellato come un agent: reagisce a richieste che gli vengono sottoposte dall'esterno.

Request è la richiesta che perviene al dirigente. Una richiesta è caratterizzata da un mittente (from), una domanda a cui rispondere (question) e una data di scadenza opzionale (due_date).

 L'elaborazione delle richieste avviene nel metodo onRequest dove si innesca un ciclo in cui ciascuna iterazione si compone di due fasi (round). Durante la prima fase sono raccolte le opinioni dai propri collaboratori; mentre durante la seconda il dirigente cerca di raggiungere un consenso.

Il ciclo termina quando viene raggiunto il consenso ovvero quando il tempo a disposizione si esaurisce.

In grassetto le funzioni che saranno analizzate in un prossimo articolo.

Request : {
  from : senderDomain
  question : string;
  due_date : date;
}

onRequest(initial_req : Request) { 
  try { 
    due_date = due_date != null ? 
             initial_req.due_date : determine_due_date(initial_req);

    priority = prioritize_request(initial_req.from, due_date);
 
    first_iteration = true;
     
    repeat {
      // first round : ask for candidate solutions
      if (first_iteration) {
        interpreted_req1 = new Request();
        interpreted_question = randomized_summarization(initial_req);
        interpreted_req1.question = ask_for_candidate_solution();
        interpreted_req1.priority = priority;
        interpreted_req1.due_date = calculate_due_date(priority, due_date);
      } else {
        interpreted_req1 = new Request();
        interpreted_req1.question = ask_for_new_candidate_solutions(response, most_frequent_res1);
        interpreted_req1.priority = priority;
        interpreted_req1.due_date = calculate_due_date(priority, due_date);
      }
         
      responses1 = send_request_and_collect_responses(team, interpreted_req1);
      most_frequent_res1 = randomized_mode_scoring(responses1);
         
      // second round : ask to to vote for the most common solution
      interpreted_req2 = new Request();
      interpreted_req2.question = proposal_with_default_on_due_date(most_frequent_res1);
      interpreted_req2.priority = priority;
      interpreted_req2.due_date = calculate_due_date(priority, due_date);
         
      responses2 = send_request_and_collect_responses(team, interpreted_req2);
      most_frequent_res2 = randomized_mode_scoring(responses2);
         
      // loop until convergence
      has_converged = most_frequent_res2 == YES;
    } until (has_converged);
     
   solution = most_frequent_res1;
  } catch (timeout) {
    // no convergence in allowed time-frame
    solution = randomized_select(most_frequent_res1, responses1);
  }
 
  reply(initial_req.from, team, solution); 
}

Con la laurea in Fisica si acquisiscono tutte le competenze necessarie per lavorare nel settore ICT

I'm a physicist. I have a working knowledge of the entire universe and everything it contains - Sheldon Cooper

Altro che investimento in formazione... il mattone è una certezza...

Beh questi hanno guadagnato un botto!!!... dicono di essere in crisi perché nessuno compra più... Uno di loro dice anche di aver perso 24 milioni di euro in borsa!!!

Certo acquistare una casa di 400-800 mila, con un reddito da neolaureato... la vedo proprio dura, molto dura...

Requisiti colpevoli!

Il progetto ha un ritardo di sei mesi perché, nella fase di analisi, i requisiti utente non si sono materializzati (qui la responsabilità è inequivocabilmente dei requisiti) - un Business Analyst, collega di Mr Sneer

Un CTO con laurea in Scienze politiche

...non voglio ascoltare altre technicalities... Che il sistema implementi le funzionalità necessarie a supportare tutti i requisiti entro la fine di questo mese! - un collega di Mr Sneer

Eseguire un Cabbage

Oggi ho imparato a eseguire un CABG (si pronuncia Cabbage). 

Nel seguito descrvo il significato dell'acronimo e le motivazioni per cui è utile tale intervento, illustrando anche la corretta procedura per effettuarlo. Chi è interessato a un approfondimento può accedere (vi prego senza diffonderlo in quanto raccoglie dettagliate informazioni, aggiornate allo stato dell'arte, sui più importanti argomenti tecnici - non a caso i principali utilizzatori sono alcuni miei conoscenti esperti del settore ICT) al seguente link.

Il CABG è un intervento di bypass aorto-coronarico (Coronary Artery Bypass Graft surgery) che serve per superare un condotto vascolare parzialmente o totalmente ostruito al fine di ridurre il rischio di infarto miocardico, eliminando anche l'eventuale dolore retrosternale dovuto a insufficienza del flusso sanguigno attraverso le arterie coronarie.

Per effettuare l'intervento è sufficiente effettuare un'incisione longitudinale sul torace, attraverso lo sterno in modo da accedere al cuore e all'aorta. Si deve quindi suturare a valle del restringimento un tratto di vena safena o di arteria mammaria prelevata dal paziente stesso. Successivamente si collega l'altra estremità a monte del restringimento o dell'occlusione. In questo modo il sangue avrà un passaggio per aggirare l'ostacolo.

E' possibile evitare l'approccio tradizionale che prevede il collegamento a una macchina cuore-polmone in favore di un più recente intervento a cuore pulsante che in genere comporta minori rischi per il paziente.

Dopo l'intervento è importante monitorare le condizioni generali del paziente e in particolare che non vi siano sanguinamento postoperatorio o infezioni.