Archivi categoria: organizzazione

No DBA

In molte organizzazioni la progettazione delle basi dati è un’attività centralizzata, delegata ad un ruolo distinto dai gruppi di sviluppo, la Data Base Administration (DBA).
Le ragioni sono due: favorire una migliore integrazione dei dati tra i diversi sistemi che vi accedono, e usare al meglio competenze specialistiche particolari, come quelle necessarie per ottimizzare le prestazioni negli accessi.

A volte, purtroppo, la DBA centralizzata diventa un collo di bottiglia, e ricorrere ai servizi che offre crea impedimenti e ritardi ai progetti.

Martin Fowler, nell’articolo No DBA, rileva che questi impedimenti possono portare in alcuni casi i gruppi di sviluppo alla scelta di non usare i DBMS relazionali, gestiti dalla DBA, sostituendoli con altri tipi di tecnologia, come i DBMS NoSQL, che invece la DBA non presidia e che vengono gestiti direttamente dai progetti. E che ciò accade anche quando per le caratteristiche dei progetti un DBMS relazionale andrebbe meglio.

L’immagine sociale del programmatore

Nei paesi più vitali dal punto di vista economico, come Stati Uniti, nord Europa, Cina, India, il ruolo del programmatore software è ben conosciuto, e considerato in modo molto positivo.

Lo sviluppo software è trattato frequentemente dai media non specializzati (giornali e riviste per non addetti ai lavori, televisioni). I programmatori compaiono nelle pubblicità e in fumetti diffusi, come Dilbert. Soprattutto, partiti politici e governi hanno ben chiara l’importanza dello sviluppo software e provano ad incentivarlo il più possibile.

Un esempio: in Estonia è stata appena approvata una legge per insegnare la programmazione nelle scuole, a partire dalle elementari, in quanto la programmazione software è ritenuta un fattore strategico per il paese e in Estonia, dove tra l’altro si sviluppa Skype, mancano programmatori.

In Italia, invece, il ruolo di programmatore software è da sempre poco noto. Se ne parla poco, o per nulla. E laddove è conosciuto, come all’interno dei settori IT delle organizzazioni (grandi e medio-grandi), è considerato come un ruolo di secondo piano.

Almeno dagli anni settanta del ‘900, esistono centinaia di migliaia di persone che operano nel campo del software in Italia. Ma mi occupo di informatica da oltre 30 anni e mi è capitato molto raramente di leggere un articolo sullo sviluppo software in una rivista non specializzata. Sarò stato distratto, forse. Ma sicuramente si è parlato molto di più dei tassisti.

Forse è anche per questo motivo che l’immagine sociale del programmatore software in Italia è così scarsa. In molte organizzazioni italiane il ruolo del programmatore è probabilmente uno di quelli meno considerati. Un ruolo di basso livello, operativo, con basso status sociale. Uno dei primi ruoli da eliminare, da esternalizzare, perché non porta valore aggiunto all’azienda.

Ma forse, invece, a ben guardare, lo sviluppo software porta valore aggiunto. Forse, la programmazione software non è affatto un’attività operativa, ripetitiva, di basso livello intellettuale.

Lo dimostrano i paesi più dinamici e vitali dal punto di vista economico, che hanno bisogno di programmatori e cercano in ogni modo di attrarli dall’estero. E anche molte aziende, come la General Motors, che dopo aver attraversato ed essere uscita da una crisi profonda ha capito che si era spinta troppo in là, con l’outsourcing dello sviluppo software, e sta ora assumendo migliaia di programmatori.

Il futuro delle IT aziendali

“The Future of Enterprise IT in the Cloud”, di Jamie Erbes, Hamid R. Motahari-Nezhad, Sven Graupner, in IEEE Computer, May 2012.

“For many decades, IT was largely shielded inside an enterprise. Enterprises used traditional ways to map their internal business needs to the IT processes and systems that they built, operated, and maintained in-house. Although IT vendors still cater to this closed ecosystem, new trends— cloud services, mobile consumer devices, and increased cross-enterprise collaboration—challenge the fundamental assumption of shielded IT in a closed enterprise.”

Rispettare il tempo delle persone

Perché molte intranet aziendali sono fatte male? Perché il management non ha rispetto per il tempo sprecato dai propri dipendenti, afferma l’esperto di comunicazione internet Gerry Mc Govern.

L’articolo è da leggere, anche perché affronta il tema degli effetti negativi del lavoro straordinario sulla produttività aziendale. Nulla di nuovo, ma ben scritto ed argomentato in modo convincente.

Ma ritornando al tema, perché molti servizi internet (non intranet) offerti dalla pubblica amministrazione e da aziende in situazioni di relativo monopolio (ad esempio Trenitalia) sono fatti così male e senza rispetto per gli utenti?

Architetti software e sviluppatori

Ci sono ancora architetti software che non sviluppano? Sì, nelle organizzazioni ancora influenzate dall’approccio a cascata. Ma il fenomeno è in calo, afferma Philippe Krutchen in IEEE Software, May/June 2011, Walking across the Seam.

“In our industry, I see fewer software architects throwing their designs over the wall to the hordes of programmers. In many organizations, these entities— architects and programmers—are roles, not individuals, and we’ve known for a long time that the best architects are also implementers; and vice versa, the best programmers understand the function of architecture and respect it.

The architect-programmer dichotomy might still exist, mostly in large organizations, as a sort of remnant of the waterfall approach, where the organization tended to match the phases. But today, the most successful software development organizations are staffed by people with a broad range of competencies, able to embrace multiple roles. We hear calls for more T-shaped individuals and less hyperspecialists.”

Poche donne nel mondo del software

Perché ci sono poche donne nel mondo del software? Poche, si intende, rispetto a quante potrebbero essercene, costituendo almeno il 50% della popolazione.

Per inclinazione? Per attitudine? Improbabile, sostiene Martin Fowler in questo articolo.

Fowler sottolinea come la compresenza di persone diverse tra loro (per genere, per razza, per cultura) nel settore del software sia estremamente vantaggiosa. E come in Cina, ad esempio, la presenza delle donne nel mondo del software sia, in percentuale, molto più alta che negli USA.

Competenze a T

In un mondo complesso come il nostro le specializzazioni sono
necessarie. Il “faccio tutto io” funziona solo in contesti limitati, non
in progetti dove è necessario il contributo di varie conoscenze ed
esperienze.

Lo sviluppo di software, in particolare, richiede competenze
specialistiche in diverse aree: competenze relative alla materia
trattata, agli aspetti relazionali e di comunicazione, all’analisi e
design del software e dei dati, tecnologiche. Quando anche solo una di
queste competenze manca, il prodotto finale ha poca qualità.

Le competenze specialistiche sono necessarie. Ma non sono sufficienti. È
necessario che si integrino e che non facciano a pugni tra loro. Cosa
che a volte capita quando tra specialisti di ambiti diversi non si trova
un linguaggio comune, un terreno d’incontro. Quando ognuno vede le cose
dal proprio punto di vista, e percepisce solo i problemi e le
opportunità legati a quel limitato punto di vista.

Come nella storia dell’elefante, nella quale a un gruppo di persone
cieche viene chiesto di toccare l’elefante e di dire poi a cosa
assomigli ciò che sta toccando. Chi tocca le zampe lo confronta a delle
colonne di un tempio, chi tocca la testa a una caldaia, chi tocca la
coda a una fune, chi tocca le zanne a un aratro. Nessuno riesce a
ottenere una visione d’insieme.

Per superare questo limite è necessario che chi partecipa ai progetti di
sviluppo acquisisca, oltre alla propria competenza specialistica, anche
una conoscenza almeno superficiale delle competenze con cui le sue si
devono integrare. Se sono un esperto di analisi dei requisiti, è utile
che sappia quali sono i problemi principali che gli sviluppatori
software devono di solito affrontare. E viceversa. Non devo diventare
esperto di tutto, ma devo sapere come integrare al meglio il mio lavoro
con quello degli altri, e per farlo devo conoscere il loro punto di
vista e le loro criticità.

Bisogna, in altri termini, sviluppare competenze a T. Come recita
Wikipedia, “Il concetto di competenze a T (T-shaped skills), o di
persone a T (T-shaped persons), è una metafora usata nelle assunzioni
del personale per descrivere le abilità delle persone”.

La linea verticale della T rappresenta la profondità delle competenze e
delle esperienze in uno specifico settore, mentre la linea orizzontale
rappresenta l’abilità di collaborare con esperti di altre aree, e di
usare in modo appropriato concetti propri degli altri settori.
Un’abilità indispensabile.

Su questo argomento, anche:
http://www.core77.com/hack2work/2009/09/on_being_tshaped.asp

T-Shaped People


http://www.alfonsofuggetta.org/?p=9422

Enterprise Architecture: risorse

ACM (Association for Computing Machinery) è la maggiore organizzazione professionale IT a livello internazionale.

Tra i benefici per i soci, ha recentemente inaugurato i “Tech Pack”, pacchetti di letture selezionate per guidare nell’apprendimento di concetti rilevanti dell’informatica. Ai primi due, relativi al Cloud Computing e al Parallel Computing, se ne è ora aggiunto uno sulla Enterprise Architecture.