Appunti di

Prof. Ing.
Filippo Sorbello
Ing.
Raffaele Brucculeri
Appunti di
Impianti Informatici
(BOZZA)
1

1 INTRODUZIONE ...............................................................................................6
1.1 Obiettivi del testo ..........................................................................................................7
1.2 Generalità .........................................................................................................................10
Il Total Cost of Ownership (TCO)...............................................................................10
Una definizione di impianto informatico .................................................................11
L’ hardware .............................................................................................................................12
Il software.................................................................................................................................12
Gli addetti.................................................................................................................................13
I luoghi.......................................................................................................................................14
L’ambiente esterno ..............................................................................................................14
I requisiti (requirements) ..................................................................................................14
Impianti informatici grandi e piccoli..........................................................................15
Il progetto di un impianto informatico.......................................................................17
La valutazione dei rischi ed il disaster recovery.....................................................18
1.3 Principali metodologie di calcolo ....................................................................21
Le elaborazioni BATCH...................................................................................................22
Le elaborazioni interattive ...............................................................................................23
Le elaborazioni TIME SHARING..............................................................................23
Le elaborazioni individuali..............................................................................................24
Le elaborazioni CLIENT/SERVER ............................................................................25
Coesistenza di diverse metodologie di calcolo......................................................27
Il GRID computing..............................................................................................................28
SOA Service Oriented Architecture............................................................................30
2 L’HARDWARE..................................................................................................36
2.1 Introduzione....................................................................................................................37
2.2 Apparecchiature informatiche..........................................................................39
Miglioramenti tecnologici e miglioramenti architetturali ...................................39
2.2.1 Unità di elaborazione..............................................................................................41
Evoluzione tecnologica.....................................................................................................42
Considerazioni sulle prestazioni ...................................................................................46
I benchmark..........................................................................................................................49
La legge di Amdhal ..............................................................................................................50
Evoluzione architetturale .................................................................................................52
2

La server consolidation.....................................................................................................56
Tecnologie BLADE e VIRTUALIZZAZIONE ......................................................59
Classificazioni delle unità di elaborazione................................................................60
2.2.2 Unità di memorizzazione di massa..................................................................66
2.2.2.1 I dischi......................................................................................................................70
Evoluzione tecnologica.........................................................................................................70
Evoluzione architetturale ....................................................................................................74
La storage consolidation, NAS e SAN ................................................................................78
2.2.2.2 I nastri.......................................................................................................................84
Evoluzione tecnologica..........................................................................................................85
Evoluzione architetturale .......................................................................................................90
2.2.2.3 I dischi ottici ..........................................................................................................94
2.2.3 Altre unità...................................................................................................................100
2.2.3.1 Unità di stampa...................................................................................................100
Evoluzione tecnologica........................................................................................................101
Evoluzione architetturale .....................................................................................................103
Le unità di stampa in un impianto informatico....................................................................106
2.2.3.2 Unità di comunicazione...................................................................................108
3 IL SOFTWARE ...............................................................................................117
3.1 Generalità .......................................................................................................................118
3.2 Software di base .........................................................................................................121
3.3 Middleware....................................................................................................................127
3.4 Software applicativo ...............................................................................................130
Il software “LEGACY”...................................................................................................131
“Suite” di software applicativi.....................................................................................133
3.5 Software FREE, OPEN SOURCE e Proprietario............................135
3.6 I costi dei prodotti software ..............................................................................138
4 GLI ADDETTI...................................................................................................144
4.1 Generalità .......................................................................................................................145
4.2 Il settore “sviluppo”................................................................................................148
4.3 Il settore “sistemi”....................................................................................................150
3

4.4 Il settore “gestione”.................................................................................................151
4.5 I manager ........................................................................................................................152
4.6 Considerazioni sulle professionalità ...........................................................153
4.7 Qualche suggerimento...........................................................................................155
5 I LUOGHI ............................................................................................................161
5.1 Site Preparation .........................................................................................................162
5.2 Apparecchiature ausiliarie ................................................................................167
6 L’AMBIENTE ESTERNO ........................................................................175
6.1 I clienti...............................................................................................................................176
6.2 I fornitori.........................................................................................................................178
6.3 I contratti in area informatica ........................................................................181
7 I REQUIREMENTS ......................................................................................191
7.1 Generalità .......................................................................................................................192
7.2 Disaster recovery e business continuity ...................................................195
APPENDICE A - FACILITY MANAGEMENT E OUTSOURCING..................204
APPENDICE B – CENNI SUI MODELLI A RETE DI CODE............................207
APPENDICE C – ANALOGICO/DIGITALE ..........................................................217
APPENDICE D – CENNI SULLA TEORIA DEI SEMICONDUTTORI ............220
APPENDICE E – CENNI SULLA TECNICA DI FABBRICAZIONE PLANARE
DI DISPOSITIVI A SEMICONDUTTORE..............................................................223
APPENDICE F – FIBRE CHANNEL ......................................................................226
4

APPENDICE G - SISTEMI OPERATIVI PER I SISTEMI CENTRALI
(MAINFRAMES)..........................................................................................................229
BIBLIOGRAFIA ......................................................................................................248
5

1 INTRODUZIONE
Obiettivi del capitolo
- capire gli obiettivi del testo
- cominciare a familiarizzare con il concetto di Total Cost of Ownership (TCO)
- conoscere le varie componenti di un impianto informatico
- conoscere i principali argomenti che caratterizzano il progetto di un impianto
informatico
- conoscere la evoluzione delle modalità di elaborazione e la loro influenza sulla
organizzazione e sulla struttura dell’impianto informatico
6

1.1 Obiettivi del testo
L’obiettivo principale del presente testo è quello di fornire elementi che si ritiene possano essere
utili a chi si trovi ad operare all’interno di un Impianto Informatico o in relazione ad esso ma
dall’esterno.
Interno ed esterno devono essere intesi da un punto di vista “logico” e non da un punto di vista
puramente “fisico”; per chiarire questo punto basta pensare al fatto che nei locali di un impianto
informatico, specie se l’impianto è di medio-grandi dimensioni, è stabilmente presente personale
dipendente da altre aziende che hanno rapporti di lavoro con l’impianto (si pensi ad esempio alle
aziende che assicurano la manutenzione delle apparecchiature, o alle aziende che forniscono
personale a fronte di specifici progetti anche di lunga durata, etc.); questo personale, per quanto
abbia, in sostanza, il proprio luogo di lavoro all’interno dell’impianto, è ovviamente da intendersi
da un punto di vista organizzativo esterno all’impianto stesso. In questo senso, sono da intendersi
esterni all’impianto anche tutti gli altri settori della medesima azienda cui appartiene l’impianto.
Per quanto in qualcuno dei capitoli seguenti si farà cenno ad argomenti tecnico-informatici, non
rientra tra gli scopi del testo l’approfondimento di tali argomenti che, peraltro, sono trattati
diffusamente nella letteratura specialistica; l’intendimento è, invece, quello di fornire punti di vista
e suggerimenti in grado di aiutare a prendere decisioni e ad assumere quei comportamenti che si
ritengono corretti nelle varie situazioni che si possono presentare in un impianto informatico.
L’idea di scrivere quanto segue è nata in seguito alla istituzione del corso di “Progetto e Gestione di
Impianti Informatici” presso il Corso di Laurea in Ingegneria Informatica di Agrigento nell’anno
accademico 2004-2005.
L’obiettivo formativo del corso si propone di fornire ai futuri Ingegneri Informatici una visione
quanto più realistica possibile del day-by-day di un impianto informatico al fine di integrare e, se
possibile, arricchire le conoscenze tecnico-informatiche già acquisite tramite gli altri corsi del
curriculum accademico.
Ci si è chiesti, allora, quali potessero essere gli argomenti più idonei da trattare per il
conseguimento dell’obiettivo prefissato. Alla fine, la cosa migliore da fare è parsa quella di fornire
una descrizione delle varie componenti di un impianto informatico sottolineando la pari dignità di
ognuna di esse ed il pari contributo che ognuna di esse deve fornire per il funzionamento ottimale
dell’impianto stesso.
Il quadro che si propone ridimensiona, in qualche modo, il rilievo di alcuni componenti e ne fa
emergere altri che possono rischiare di rimanere confusi o del tutto invisibili fino a che, nella
pratica, non ci si imbatte in essi.
Così:
- il computer e gli altri componenti hardware, da unici protagonisti della scena, unici
argomenti di studio e di progettazione, diventano “semplicemente” protagonisti insieme ad
altri protagonisti;
- la progettazione stessa, spesso considerata una attività libera da vincoli (se non quelli
tecnici) diventa, invece, una attività che deve essere condotta alla luce di stringenti
condizioni economiche, di opportunità, di mercato, etc.
7

- le problematiche connesse alla gestione ed al ripristino delle funzionalità di un impianto, da
problematiche di secondo piano diventano di importanza cruciale per la sopravvivenza
stessa non solo dell’impianto ma dell’azienda o dell’ente che ne dispone.
Ci si augura, perciò, che gli studenti che leggeranno questo testo, pur ritrovando spesso, qua e la,
delle vecchie conoscenze, acquisiscano una mentalità idonea a consentire loro un inserimento più
agevole ed efficace nelle varie attività che si svolgono all’interno di un impianto informatico dei
nostri giorni.
Come si è detto, ci si augura anche che questi appunti possano essere di beneficio, oltre che a coloro
i quali opereranno all’interno di un impianto informatico nelle varie professionalità di cui si parlerà
più avanti, anche a chi si trova ad operare in qualche modo a contatto con un impianto informatico;
tra tutti costoro, una menzione particolare meritano i manager aziendali non di estrazione
informatica.
I manager aziendali, ovviamente, sono chiamati a prendere delle decisioni che riguardano le cose
informatiche allo stesso modo in cui sono coinvolti in altre faccende inerenti l’organizzazione e
l’operatività aziendale; in queste circostanze, finché si tratta di avallare le scelte proposte dal settore
informatico, il management può anche decidere, per lo più giustamente, di fidarsi di ciò che viene
proposto dai collaboratori che gestiscono gli impianti informatici.
I problemi possono cominciare quando si tratta di avanzare delle specifiche richieste al settore
informatico al fine di supportare adeguatamente delle necessità di business aziendale e le strategie
in genere.
Disporre di una “infarinatura” sulle problematiche connesse agli impianti informatici potrebbe,
infatti, evitare quelle situazione piuttosto delicate derivanti, ad esempio, dal:
- richiedere la predisposizione di nuove applicazioni e/o di nuovi luoghi operativi in tempi
pericolosamente brevi o addirittura proibitivi;
- imporre l’impiego di strumenti e procedure prima di aver consentito uno studio di fattibilità
e di inseribilità almeno minimale;
- richiedere livelli di servizio di un certo tipo senza la disponibilità agli investimenti
necessari;
- trascurare i piani di addestramento e formazione del personale informatico attendendosi allo
stesso tempo livelli di competenza e di aggiornamento ottimali;
- etc.
Insomma, una “infarinatura” sugli argomenti informatici, potrebbe consentire al management
aziendale di sapere, ad esempio, cosa non è realistico chiedere e, allo stesso tempo, potrebbe
consentire di individuare quei casi, che pure capitano, in cui lecite richieste sono ostacolate da
inesistenti problematiche che affondano le loro radici su argomenti tutt’altro che tecnici.
La eventualità che le strutture informatiche siano oggetto di comportamenti errati come quelli
descritti sopra non è purtroppo infrequente; ciò dipende anche dal fatto che, per la generalità delle
aziende, i managers aziendali hanno competenze ed attenzioni particolari nei riguardi del settore
specifico dove l’azienda opera e tendono a perdere di vista l’importanza strategica di settori che
possono essere definiti di servizio per l’operatività aziendale.
In altri termini, se è verosimile che i managers di una azienda che si occupa, ad esempio, della
produzione di motori per automobili non facciano mancare risorse al gruppo di ingegneri che si
8

occupa della progettazione e dello sviluppo di nuove soluzioni nel settore, non è altrettanto certo
che le problematiche connesse alla continuità ed alla sicurezza dei servizi informatici siano intese
come strategiche per il bene aziendale, almeno fino a quando il verificarsi di qualche avvenimento
infausto non richiama prepotentemente l’attenzione sull’argomento.
9

1.2 Generalità
Gli impianti informatici di cui si parlerà vengono di solito definiti “General Purpose”; in sostanza si
tratterà degli impianti informatici comunemente presenti nelle aziende e negli enti pubblici e che
non hanno necessità di speciali caratteristiche per svolgere il proprio compito.
Un impianto speciale, invece, può essere tale o per le condizioni in cui si trova ad operare o per
quello che fa, o per le due cose insieme.
Gestire i conti correnti di una banca, la fatturazione e la contabilità di una azienda, l’anagrafe di un
Comune e cose del genere si possono considerare compiti tipici di un impianto informatico general
purpose a patto che, ad esempio,
- l’impianto di cui si tratta non si trovi ad operare in un ambiente con una temperatura di 250
gradi centigradi, o in assenza di gravità, o in altre condizioni fisiche del tutto fuori dal
comune e che richiedono materiali speciali o speciali progettazioni
- dalla attività dell’impianto non dipendano vite umane o altre cose giudicate di vitale
importanza e tali da richiedere parametri di affidabilità e di continuità di servizio al di fuori
di quelli ottenibili con le progettazioni e le produzioni comuni
- non vi siano, insomma, requirements fuori dal comune la cui presenza, invece, porta a
considerare l’impianto informatico non general purpose.
Le apparecchiature e/o i prodotti software utilizzati in un impianto informatico general purpose
sono normalmente reperibili sul mercato; laddove, invece, le apparecchiature e/o i prodotti software
di cui necessità un impianto non general purpose possono essere progettati per soddisfare specifici
scopi e/o specifiche condizioni di funzionamento.
Il Total Cost of Ownership (TCO)
Il principale fattore che deve essere considerato nella progettazione e nella gestione di un impianto
informatico è il TCO (Total Cost of Ownership) cioè il costo complessivo indotto dal possesso
dell’impianto.
Il TCO di una determinata soluzione deve considerare tutti i costi di avvio e di gestione della
soluzione; il TCO considera perciò sia i costi non ricorrenti (come il costo di acquisto) sia i costi
ricorrenti (quali manutenzioni, canoni, personale, materiali di consumo, etc.) presenti nel periodo di
vita stimato della soluzione. Oltre a ciò, nel TCO bisogna anche includere i costi che derivano da un
eventuale successivo abbandono della soluzione; quest’ultimo punto intende mettere in evidenza
quanto una determinata soluzione vincola chi la sceglie nelle possibili scelte future; è evidente,
infatti, che la difficoltà o la impossibilità reale di abbandonare una soluzione per sceglierne una
diversa può esporre a costi anche elevati venendo a mancare una certa forza contrattuale a favore
dell’utilizzatore il quale, in sostanza, può trovarsi a dovere accettare forme e contenuti contrattuali
sfavorevoli.
E’ bene familiarizzare il più possibile con il TCO, e principalmente con il concetto che rappresenta,
in quanto, nella pratica, esso è il metro fondamentale tramite il quale misurare ogni realizzazione in
campo informatico così come in ogni altro settore. Una superficiale valutazione del TCO può
portare ad imboccare strade che si rivelano, dopo i primi chilometri, impervie e cariche di
conseguenze negative per il conto economico della realtà in cui si opera.
10

Il TCO comparirà spesso nelle note che seguono e, anche dove non è espressamente indicato, non
sarà difficile individuarlo. Sfortunatamente, la consapevolezza della importanza basilare del TCO
non vuol dire che sia sempre agevole una sua corretta valutazione; ciò in quanto gli elementi che lo
compongono possono essere poco visibili o, a primo acchitto, del tutto invisibili, pur non volendo
considerare, ottimisticamente, che non c’è peggior cieco di chi non vuol vedere.
La letteratura del settore trabocca di studi volti a definire il TCO in varie situazioni. Questo valore
deve tendenzialmente essere quanto più basso possibile pur consentendo il raggiungimento dei
benefici che si intendono ottenere in termini di servizi resi all’utenza.
Per un impianto general purpose l’ esame del TCO è, più o meno, prassi abituale; nel caso di un
impianto speciale, invece, in alcuni casi le scelte sono da effettuare “a tutti i costi” ed in altri la
quantificazione del beneficio ottenibile è impossibile “a priori”; si pensi ad esempio a quelle
apparecchiature utilizzate a fini di ricerca scientifica per consentire di affrontare la soluzione di
problemi complessi: nessuno può dire, in genere, cosa ne verrà fuori, ma non per questo gli
investimenti devono essere limitati. A ben vedere, in realtà, anche in questi casi “speciali” i principi
del TCO continuano a valere, solo che il potenziale vantaggio è talmente elevato da giustificare
sforzi anche molto elevati.
Una definizione di impianto informatico
Un impianto informatico è un LUOGO dove ADDETTI, con specializzazioni diverse, svolgono
attività di PROGETTAZIONE, REALIZZAZIONE e GESTIONE di componenti HARDWARE e
SOFTWARE al fine di soddisfare sia le esigenze (requirements) dell’UTENZA sia le
SPECIFICHE dei FORNITORI.
La definizione comprende gli aspetti che caratterizzano un impianto informatico e che saranno
oggetto della successiva trattazione.
E’ appena il caso di precisare che il progetto, la realizzazione e la gestione di un impianto
informatico non riguardano solo gli impianti che nascono “ex novo” nei casi cosiddetti di prima
informatizzazione, casi in realtà ormai piuttosto infrequenti, bensì riguardano anche tutte quelle
attività di implementazione, modifica, aggiornamento, etc., che si effettuano presso un impianto già
esistente ed operativo; queste eventualità, nettamente più frequenti, inducono tra l’altro alcune
condizioni aggiuntive da rispettare, derivanti dalla omogeneità che, se possibile, deve essere
assicurata con gli ambienti preesistenti e, in genere, dalla valutazione relativa alla inseribilità del
nuovo intervento nel tessuto esistente.
Sia il progetto di un impianto informatico ex novo sia il progetto di un intervento modificativo di un
impianto informatico esistente devono, perciò, occuparsi di ognuno degli aspetti che compaiono
nella definizione fornita, e cioè: i luoghi, gli addetti, l’hardware, il software, l’ambiente esterno
(utenti e fornitori), le esigenze e le specifiche.
Il progetto di un impianto informatico non ha niente a che vedere con il progetto di un computer o
con il progetto di un sistema operativo: le relative professionalità sono completamente diverse.
Un impianto informatico non è qualcosa dove effettuare delle attività di sperimentazione pura o di
ricerca teorica sui vari aspetti del mondo informatico; non è qualcosa dove mettere in pratica le
proprie convinzioni, peggio se del tutto preconcette, finendo spesso per pretendere di uniformare il
modello di business dell’azienda in cui si opera al proprio modello informatico; non è qualcosa
11

dove una casta di sommi sacerdoti depositari della verità svolgono la loro missione rivolgendo solo
di tanto in tanto, e con un certo fastidio, lo sguardo verso le necessità del mondo esterno, spesso
utilizzato, anzi, come cavia per la conduzione di misteriose pratiche sacrificali.
Al contrario, un impianto informatico esiste in quanto esiste l’utente finale che necessita di vari
servizi sulla base delle prassi e delle strategie aziendali le quali, correttamente, devono influenzare e
plasmare il modello informatico da impiegare.
In tutte le attività che si svolgono in un impianto informatico, sia progettuali sia di gestione, non
dovranno mai essere perse di vista le necessità dell’utente finale e i compiti di fornitore di servizi
cui l’impianto deve far fronte.
La centralità dell’utente finale e l’ottimizzazione del TCO sono due fattori in grado di determinare
la qualità del progetto e della gestione di un impianto informatico; tuttavia, spesso questi due
argomenti, al di la di generiche affermazioni di principio, sostanzialmente non ricevono l’attenzione
che meritano; in questi casi, prima o poi, è estremamente probabile che venga messa in discussione
l’esistenza stessa dell’impianto.
L’ hardware
Per quanto riguarda l’ hardware possiamo definire due grandi categorie:
- le apparecchiature informatiche vere e proprie :
o unità di elaborazione
o unità di memorizzazione di massa
o stampanti
o apparecchiature di rete
o altre unità di input/output
- le apparecchiature ausiliarie, tra le quali:
o apparecchiature per l’alimentazione elettrica
o apparecchiature per il condizionamento dell’ambiente
o apparecchiature per la sicurezza ambientale
Può accadere che diverse funzionalità informatiche (elaborazione, memorizzazione di massa, etc.)
siano comprese all’interno di una medesima macchina; altre volte le varie funzionalità sono svolte
da apparati diversi. In quest’ultimo caso la progettazione deve occuparsi anche della scelta tra
diverse alternative di collegamento. In ogni caso, i concetti generali relativi ad ogni singola
funzionalità continuano ad essere validi.
Il software
Nel campo del software si possono individuare tre macrocategorie:
- il software di base costituito dai sistemi operativi
- il middleware cioè tutta quella quantità di prodotti software che pur non essendo
strettamente appartenente ai sistemi operativi serve comunque al controllo, alla gestione ed a
migliorare, in genere, l’operatività (gestori di data base, prodotti per la sicurezza logica,
prodotti per il controllo delle performance, etc.)
12

- il software applicativo, cioè tutto quel software che realizza le varie necessità degli utenti
finali e che è utilizzato direttamente dagli utenti finali stessi.
Talvolta, specie nelle realtà medio-piccole, parte dei prodotti middleware sono inclusi nel sistema
operativo. I sistemi operativi ed il middleware, nella generalità degli impianti general purpose, sono
acquisiti dall’esterno, da fornitori specializzati, e non è più pensabile di svilupparli in proprio come
avveniva agli albori della informatica moderna. Agli albori della informatica, infatti, l’utente finale
era spesso anche il progettista del sistema di calcolo nelle sue componenti hardware e software, ne
era il manutentore, il programmatore, e così via.
Il software applicativo, invece, è costituito o da programmi di utilizzo generale, o da programmi
realizzati all’interno dell’azienda o da programmi commissionati a società esterne specializzate nel
settore.
L’insieme delle apparecchiature (hardware) e dei programmi (software) può essere installato e
gestito all’interno della azienda con personale interno; può essere installato e gestito all’interno
dell’azienda con personale esterno, e si parlerà allora di facility management (Appendice A –
facility management e outsourcing); può essere installato e gestito all’esterno dell’azienda, da
società di servizi specializzate, e si parlerà allora di outsourcing (Appendice A – facility
management e outsourcing).
Gli addetti
Le figure professionali coinvolte nella gestione informatica sono:
- i sistemisti, addetti alla gestione del sistema con il compito di assicurarne l’installazione, la
manutenzione e l’aggiornamento per quanto riguarda i sistemi operativi ed i prodotti
middleware
- gli operatori, addetti ad assicurare il corretto svolgimento delle attività sulla base della
migliore schedulazione dei lavori individuata di volta in volta
- gli analisti ed i programmatori, addetti all’esame di fattibilità, al progetto ed alla
realizzazione di nuove procedure applicative, oltre che alla relativa manutenzione durante
l’intero ciclo di vita delle procedure stesse.
Laddove esiste un reparto addetto al progetto ed alla realizzazione di nuove procedure applicative,
questo è il reparto composto da un maggior numero di persone; ciò in quanto l’attività di analisi e,
ancor più, quella di sviluppo richiedono l’intervento umano in maggior misura rispetto alle attività
sistemistiche ed operative le quali, invece, beneficiano di una quantità crescente di strumenti
ausiliari in grado di consentire il controllo e la gestione degli impianti, anche di grande dimensione,
da parte di un ristretto numero di persone.
Più è folta la schiera delle persone che operano nel settore dell’ Information Technology (IT) più è
folta, naturalmente, la schiera dei manager, di vario livello, chiamati a coordinarne le attività.
Parlando delle persone che operano in un impianto informatico non si può fare a meno di osservare
una marcata assenza di criteri ufficiali di certificazione delle competenze e delle responsabilità; per
quanto vi possano essere ottimi addetti ad impianti informatici provenienti da esperienze di studio
più o meno estranee all’informatica, una razionalizzazione del settore sembra opportuna; d’altra
parte la problematica è di più ampia portata, e se ne accennerà nel capitolo dedicato agli addetti.
13

I luoghi
I luoghi, all’interno dell’azienda, dove si svolge attività informatica si sono, nel tempo, moltiplicati
a seguito della diffusione degli strumenti informatici. Al centro di calcolo vero e proprio si sono
aggiunte le altre locazioni aziendali dotate di strumentazioni informatiche: uffici, dipendenze, filiali,
etc.
Inoltre, la necessità di assicurare una continuità operativa ha portato alla nascita di uno o più centri
di calcolo, geograficamente distanti ma in qualche modo connessi con il centro di calcolo
principale, per gestire eventuali situazioni di disservizio (disastri) senza interrompere l’operatività
aziendale.
La predisposizione dei luoghi dove si svolgeranno le attività informatiche possono richiedere
competenze non di tipo informatico (si pensi, ad esempio, allo studio delle soluzioni per il
condizionamento ambientale); perciò, spesso, è necessario il coinvolgimento di diverse
professionalità specifiche.
L’ambiente esterno
L’ambiente esterno all’impianto informatico è costituito da tutto ciò che ha a che fare con
l’impianto stesso ma che, da un punto di vista logico, si trova all’esterno dell’impianto stesso nel
senso prima specificato:
- primi tra tutti i “clienti” che possono essere suddivisi tra clienti interni all’azienda stessa e
clienti esterni; quest’ultima categoria si è, oggi, enormemente estesa con Internet che
consente, a vari livelli, l’ingresso degli utenti esterni direttamente nel sistema informativo
aziendale;
- quindi altre aziende o realtà di vario tipo con cui è opportuno o necessario scambiare
informazioni per il rispetto di specifiche normative o semplicemente per una migliore
efficienza delle attività;
- vi è poi la schiera dei fornitori: di hardware; di software; di specifici servizi; ed inoltre i
consulenti di mercato che operano in diversi settori e che possono costituire un supporto alle
scelte aziendali.
I requisiti (requirements)
Come si è già accennato, tutte le componenti viste prima devono operare in modo coordinato per il
raggiungimento degli obiettivi che l’impianto deve raggiungere, cioè dei suoi requirements.
Sono requirements
- ciò che l’impianto deve consentire e dove deve consentirlo
- le prestazioni in termini di tempi di risposta
- la sicurezza dei dati
- la continuità di servizio in base alle politiche aziendali
- l’economicità della gestione
Se i requirements fossero solo connessi ai livelli di servizio ed alla qualità in genere potrebbe non
essere difficile ottenerli; sfortunatamente, tra i requirements più importanti che devono essere
soddisfatti c’è, in genere, anche il costo complessivo che le varie soluzioni comportano.
14

Il mancato soddisfacimento di un certo requirement induce un costo per l’azienda; intraprendere le
azioni necessarie a soddisfare quel certo requirement è anch’essa una attività che costa; se
quest’ultimo costo è più basso del precedente allora l’attività ha senso e si giustifica, altrimenti
bisogna pensare a qualcosa di diverso o decidere di accontentarsi.
Se le analisi dicono, ad esempio, che la ricostruzione manuale di un certo archivio che dovesse
danneggiarsi costa X (mettendo un certo numero di persone per un certo tempo a ricostruire
l’archivio partendo, ad esempio, dai documenti cartacei, ammesso che tutto ciò sia possibile) e se
per mettere in piedi un sistema di sicurezza che consenta il ripristino automatico dell’archivio
danneggiato si va incontro ad un costo Y (in termini di macchine, in termini di persone, in termini
di luoghi, e tutto il resto), si tratta di vedere se Y è inferiore ad X, ed in questo caso conviene
effettuare l’intervento; se invece X è inferiore ad Y non resta che sperare che l’evento disastroso
non avvenga e, nell’eventualità malaugurata, procedere manualmente.
Bilanci di questo genere sono la base di ogni scelta progettuale, tuttavia difficilmente le cose sono
semplici come nell’esempio descritto; non nella teoria, che è semplice ed inequivocabile, ma
nell’ottenimento di valori corretti per X ed Y.
Si potrebbe infatti osservare che se l’evento disastroso è probabile che avvenga 10 volte in un anno,
allora X diventa 10 volte X (oltre magari al costo per l’intervento del miglior esorcista del paese,
ma questo è un costo facoltativo); e Y? Y potrebbe rimanere comunque Y nel caso in cui la
soluzione predisposta sia del tutto automatica e, una volta effettuati gli investimenti iniziali, non
induca altri costi derivanti, per dir così, dall’attivazione della soluzione. Le cose cambiano se, ad
esempio, la soluzione che porta ad Y è basata anche sull’acquisizione di un servizio a consumo da
parte di una società esterna; ad ogni disastro un tot. Ad ogni modo, in un caso del genere si tratta di
fare delle previsioni su elementi ragionevolmente prevedibili.
A volte le cose si complicano. Quale è il costo rappresentato da affari mancati a causa di un certo
tempo di risposta non eccezionale del sito web aziendale? Stuoli di società di consulenza fondano le
proprie fortune sfornando ricerche di straordinaria precisione, alla fine, però, chi ha il giusto
“intuito” e la giusta misura riesce a trovare il corretto bilanciamento.
Impianti informatici grandi e piccoli
Tornando alla definizione citata di impianto informatico, essa potrebbe in prima battuta far pensare
ad un impianto informatico di grande dimensione; parlare, ad esempio, di “un certo numero di
persone con specializzazioni diverse” sembrerebbe escludere quella miriade di realtà piccole e
piccolissime dove è molto contenuta o addirittura è del tutto assente una struttura in termini di
personale addetto all’impianto informatico e, in fin dei conti, anche il parlare di “impianto
informatico” sembra in questi casi piuttosto inappropriato.
Tuttavia, a prescindere dagli aspetti quantitativi, qualitativamente, la definizione di apertura calza
praticamente sempre ed è bene tenerla in evidenza in ogni caso. Anzi, paradossalmente, è bene
tenerla presente principalmente quando ci si trova a gestire o si ha a che fare con realtà piccole e
piccolissime. Infatti, nel caso di impianti di grandi dimensioni, si è, in genere, naturalmente indotti a
considerare ed affrontare i vari aspetti di un impianto informatico; nel caso di piccole realtà, invece,
spesso si tende a sottovalutare alcuni aspetti, o anche la maggior parte, nella convinzione (errata),
così facendo, di non arrecare alcun danno alla operatività complessiva.
15

Se il settore IT di una grande banca deve procedere alla definizione di una soluzione per gestire una
certa necessità di business aziendale, molto probabilmente disporrà già di una prassi più o meno
consolidata e magari contenuta in un qualche manuale operativo che indica “chi fa cosa” nelle varie
fasi del progetto; perciò, in modo pressoché automatico e sotto la guida di un responsabile, saranno
coinvolte le figure necessarie al momento opportuno, la nuova necessità sarà analizzata dai vari
punti di vista ed il tutto procederà sulla base di una pianificazione concordata tra le varie funzioni
interne ed esterne al settore IT.
Ciò è agevolato dal fatto che in una realtà di grandi dimensioni i ruoli sono nettamente distinti e,
giusto per citare qualche aspetto più immediatamente comprensibile:
- le risorse (intese sia come risorse finanziarie sia come competenze delle persone a fronte di
una certa attività) necessarie alla conduzione del progetto sono spesso suddivise in diversi
settori assegnati a diverse persone che sono chiamate a risponderne dell’utilizzo efficiente e
che perciò si impegneranno per assicurare il rapporto costo/beneficio migliore;
- le funzioni che danno il via libera alla diffusione di una certa procedura, sono generalmente
separate dalle funzioni operative potendo, così, espletare una funzione di controllo reale ed
abbastanza imparziale;
- la frequenza di preparazione di nuovi progetti genera una certa abitudine ad affrontare le
attività il maniera organica e con la giusta dose di “conflittualità” che dovrebbe condurre al
raggiungimento di soluzioni equilibrate ed efficienti.
Questo quadro è però spesso ideale, in quanto, sovente, non si opera seguendo una precisa traccia e
ciò induce vari livelli di inefficienza nel processo complessivo; spesso, e non per la presenza di
spiccati principi morali, ciò che fa la destra rimane segreto alla sinistra, la posizione a priori del
manager più influente finisce miracolosamente per coincidere con i risultati delle analisi più attente
e metodiche, la scelta di una determinata soluzione o di un determinato fornitore finisce per ricadere
su quelle più familiari ai livelli decisionali, etc.
Fortunatamente, le realizzazioni in campo IT si prestano a modifiche in corso d’opera ed anche ad
opera completata, riuscendo a nascondere con un certo numero di “toppe” poste qua e la, che
naturalmente vengono spacciate per interventi di consolidamento strategico o altre definizioni del
genere, difetti di progetto. Nel campo IT le scelte sbagliate e/o preconcette si riescono di frequente a
camuffare; naturalmente ciò costa, e qualcuno deve pagare e paga, ma non in genere gli autori delle
malefatte, bensì nella grande maggioranza dei casi gli utilizzatori ed i clienti in genere. Costoro
finiscono per pagare in termini di servizi scadenti e alti costi per essere giustappunto clienti.
Nel caso di realtà di medio-grandi dimensioni e immuni da condizionamenti e da vizi vari, seppure
a fronte di iterazioni successive, si riesce in genere ad effettuare un esame completo dei vari aspetti
coinvolti nella realizzazione di un impianto informatico prima delle fasi di realizzazione e di
rilascio effettivo.
Nelle piccole realtà, invece, spesso l’utente è anche il sistemista, l’operatore, il responsabile della
sicurezza della soluzione e tante altre cose ancora di cui, in genere, non ha una conoscenza
specifica, il che non sarebbe un grave danno se, almeno, avesse la consapevolezza della probabile o
possibile presenza di un problema a fronte del quale richiedere l’intervento di un esperto.
In questi casi, estremamente numerosi, la definizione fornita per impianto informatico potrebbe
tornare utile, se non altro, in funzione di check list da scorrere al fine di portare alla mente la
possibile presenza di un problema o di una area di problemi sottovalutati o del tutto trascurati.
16

Il progetto di un impianto informatico
Per il progetto di un impianto informatico si devono perciò definire tutti gli elementi più volte citati
e cioè: hardware, software, persone, luoghi, nel rispetto delle esigenze dell’utenza e delle specifiche
(requirements) ed in stretta connessione con l’ambiente esterno con cui si ha a che fare.
Per quanto concerne gli aspetti strettamente tecnologici, l’attività di progettazione deve muoversi
mantenendo un certo equilibrio tra novità e tradizione; in altre parole, non è sempre vero che
l’ultimo ritrovato della tecnologia è ciò che fa sempre al caso nostro, così come non è vero che una
certa soluzione, magari la più conosciuta, si adatta ad ogni evenienza.
Insomma, se si ha una grande familiarità con lo shuttle non per questo si deve progettare di andare a
fare la spesa qualche isolato più in là pilotando la navetta in mezzo al caotico traffico cittadino e
sperando anche di trovare parcheggio nel piazzale antistante il supermercato, potrebbe rivelarsi più
efficiente acquistare una utilitaria o, ancora meglio, andare a piedi; così come potrebbe essere
inadeguato porre il proprio sito web sul PC di casa e pretendere che l’umanità intera possa
accedervi per consultare le vostre informazioni con dei tempi di risposta attraenti.
Questi propositi molto saggi e razionali, però, sono difficili da mettere in pratica. Anche
ipotizzando un reparto IT composto da formidabili e scrupolosi strateghi, numerosi altri ostacoli si
frappongono sulla via della perfezione.
Tra tutti, il più pericoloso è costituito dai manager aziendali e da chi, a vario titolo, stabilisce cosa
serve e cosa non serve e, principalmente, quando serve.
Se qualcuno stabilisce che bisogna mettere su un sito web entro un mese perché il concorrente lo ha
già oggi e non si vuole essere da meno, è probabile che l’IT manager (che come tutti ha i suoi
problemi di carriera, le sue ambizioni e le sue debolezze) decida di mettere su qualcosa di
“temporaneo”, insomma una toppa, pur di soddisfare la richiesta; beh, alla fine, quasi certamente, a
parte una sfavillante home page esibita a qualche riunione di direzione generale, non si riuscirà da
quel sito a cavare niente di serio.
E poi, se solo il tutto funziona anche un pochino, non si ha idea di quante cose “temporanee” si
tramandino da IT manager ad IT manager costituendo dei veri e propri strati geologici all’interno
dei sistemi informativi delle aziende. Tuttavia, molti autori di toppo hanno fatto brillanti carriere,
imponendosi in più occasioni all’attenzione generale come i salvatori della patria, gli uomini giusti
al posto giusto, e così via.
In fin dei conti basta utilizzare il termine PATCH e la toppa sembra meno toppa di quello che è.
D’altra parte, nella pratica quotidiana, l’elasticità è una gran virtù, e perciò può essere anche utile
saper tappare qualche buco velocemente purché ciò non sia dovuto alla incapacità di vedere le cose
nel loro complesso ed in una prospettiva strategica (cioè di lungo periodo). Insomma, le toppe
possono anche andar bene, purché si sia coscienti che si tratta di toppe e perciò, una volta superato
il problema immediato, se ne gestisca anche la rimozione. Sfortunatamente (o fortunatamente per
alcuni), le toppe informatiche non sono evidenti e si prestano a scomparire nel tessuto dei sistemi
informativi lasciando però dei punti di debolezza strutturale che, prima o poi, produrranno i loro
effetti indesiderati.
In conclusione si può dire che gli aspetti tecnologici devono essere decisi con un certo equilibrio tra
novità e tradizione, per conseguire l’unico obiettivo che conta, e cioè realizzare ciò che si deve fare
17

minimizzandone i costi, purché in questi costi vengano inclusi quelli che deriveranno, anche in un
futuro più o meno remoto, da scelte affrettate.
Infine, la progettazione di un impianto informatico non può ritenersi completa se non prevede,
almeno:
- un dettagliato piano di ingresso in produzione, cioè un piano che consenta l’utilizzo
dell’impianto dal punto di vista degli utenti finali e dei luoghi dove l’utilizzo deve avvenire;
- l’analisi dell’impatto, anche transitorio, che l’ingresso in produzione può avere sulle normali
attività degli utenti;
- la stesura delle opportune istruzioni per chi operativamente dovrà gestire l’impianto;
- la valutazione dei rischi connessi ad eventuali malfunzioni o eventi di tipo disastroso e la
conseguente stesura di un piano operativo in tal senso (che preveda anche la realizzazione di
test per quanto possibile frequenti).
La valutazione dei rischi ed il disaster recovery
Questo punto è quello che più di frequente viene sottovalutato o del tutto trascurato; ciò accade
anche perché gli altri punti, se non correttamente affrontati in fase progettuale, producono disservizi
più o meno immediati nella fase di realizzazione del progetto e perciò, sebbene con una serie di
evitabili inefficienze ed in ritardo, vengono in qualche modo affrontati; invece, la mancanza di un
piano che stabilisca il da farsi in caso di “disastro” (cioè di un piano che va sotto il nome di disaster
recovery) può passare inosservata fino al momento in cui si presenta una situazione di emergenza
(ed in quel momento può non esserci la possibilità di rimediare).
Per precisare meglio questo fondamentale argomento, è bene evidenziare che per disastro
informatico non è solo da intendere un evento catastrofico naturale o “artificiale”, ma anche tanti
altri possibili eventi e/o situazioni meno appariscenti ma che possono produrre danni rilevanti,
quali:
- malfunzionamenti hardware
- errori umani
- fermi programmati dovuti a manutenzione o altro
- organici non adeguati a garantire la disponibilità delle competenze necessarie a far fronte
anche a indisponibilità individuali prevedibili o imprevedibili
- presenza (nelle componenti hardware e/o nelle componenti umane) di single point of failure
cioè di funzionalità e/o conoscenze non adeguatamente ridondanti
- carente produzione di documentazione adeguata in fase di modifica di prodotti software
applicativi o di aggiornamento di prodotti software di base e/o middleware
- etc.
Inoltre, è altrettanto importante sottolineare che la predisposizione di un piano di rientro da una
situazione di crisi non è, di per se, sufficiente a fornire le adeguate garanzie di successo se il piano
non viene sottoposto, con ragionevole frequenza, a test pratici che, simulando una situazione di
disastro, verifichino il corretto ingresso in funzione di tutti i rimedi pianificati ed il necessario
livello di preparazione delle persone che devono gestire l’evento.
La realizzazione delle simulazione non garantisce, purtroppo, circa la perfetta riuscita del piano in
un caso reale, però, una larga parte di inconvenienti, che possono derivare da:
- esatta comprensione del rispettivo ruolo da parte delle persone
18

- correttezza delle procedure informatiche di ripartenza
- funzionalità delle apparecchiature informatiche e delle apparecchiature ausiliarie
- etc.
vengono generalmente a galla e possono così essere corretti e nel futuro evitati.
La periodicità con la quale realizzare le simulazioni è di grande importanza sia perché un impianto
informatico è una struttura dinamica che si evolve nel tempo presentando nuove problematiche sia
perché i disastri più catastrofici non sono, fortunatamente, eventi frequenti e ciò fa in modo che le
procedure tendano ad essere dimenticate ed i controlli tendano ad non essere effettuati.
E’ bene, infine, sottolineare che il successo di ogni iniziativa che si intraprende nel vasto campo del
disaster recovery ha un prerequisito essenziale: la comprensione da parte della direzione aziendale
della importanza dell’argomento e della sua criticità per la stessa sopravvivenza aziendale; laddove,
infatti, il piano di disaster recovery viene considerato come una serie di attività, a carico
esclusivamente del settore IT, da effettuare nei ritagli di tempo, magari semplicemente per produrre
qualche documento da mettere in archivio per completare un dossier da esibire nelle occasioni
opportune, è molto probabile che, al momento del bisogno, non abbia nessuna utilità e perciò i costi,
anche minimi, sostenuti per produrlo risulteranno largamente sprecati.
Al contrario, il disaster recovery è un problema aziendale alla cui soluzione deve partecipare
l’intera azienda; ad esempio, la definizione di “disastro” non può essere fatta dal settore IT, bensì
dagli altri reparti dell’azienda che sono in grado di valutare quali servizi sono vitali per l’azienda e
quali, invece, non lo sono; una volta condotta questa analisi si dovrà valutare quali elementi
contribuiscono alla corretta operatività di quei servizi che sarebbe “disastroso” se non fossero
operativi; ed in questa valutazione entrerà sicuramente in gioco, per la sua parte, anche la struttura
IT.
In sostanza, ciò che può essere un disastro per la azienda A può non esserlo per l’azienda B e,
conseguentemente, le precauzioni richieste a fronte di un analogo evento possono essere diverse. E’
sempre e solo una questione di TCO, cioè una questione di denaro e nient’altro.
La raccomandazione migliore che si può dare a tutti coloro che devono prendere decisioni in
materia è quella di effettuare delle scelte al meglio delle proprie capacità e delle informazioni e/o
previsioni di cui si dispone; effettuare delle scelte, dunque, questo è il consiglio; ciò vuol dire che si
può anche decidere di non prendere alcun provvedimento, purché il non prendere alcun
provvedimento sia, appunto, una decisione e non il frutto di una mancata decisione.
L’attenzione alle problematiche della sicurezza informatica (in termini di sicurezza dei dati,
continuità operativa, disaster recovery, etc) è oggi spesso sollecitata se non imposta da normative e
raccomandazioni emanate da organizzazioni al di sopra delle aziende.
A titolo di esempio, si desidera citare, in quanto molto significativo, il risultato dei lavori del
“Comitato di Basilea” [1], un organismo di supervisione in area bancaria, che, in sostanza, porta a
valutare la solidità patrimoniale in funzione, oltre che di diversi altri fattori più consueti, dei
cosiddetti rischi operativi definibili come “… rischi di perdite risultanti da inadeguatezza e/o da
disservizi nei processi, nelle persone e nei sistemi interni….”; in ciò, come è ovvio, sono inclusi
pienamente anche i rischi connessi alla affidabilità dei sistemi informativi in senso lato e degli
impianti informatici in particolare.
19

Da questa direttiva (alla quale si fa spesso riferimento come Basilea II) deriva, in sostanza, un
concetto abbastanza nuovo, per quanto oggettivamente semplice ed intuitivo, che ha fatto correre ai
ripari, in fretta e furia, diverse organizzazioni: una azienda è tanto più solida quanto più è bene
organizzata e protetta, tra l’altro, in uno dei suoi beni più preziosi e cioè il suo sistema informativo;
in realtà l’aspetto realmente nuovo consiste nel fatto che gli eventuali rischi operativi dovrebbero,
oggi, essere effettivamente valutati e dovrebbero rientrare nella più ampia valutazione dei rischi cui
è esposta una azienda di credito.
Su questo argomento si tornerà anche in altre parti in quanto si ritiene che sia uno degli argomenti
che più di altri necessita della migliore comprensione possibile.
20

1.3 Principali metodologie di calcolo
Negli anni dei primi computer (anni 50) il normale impiego a supporto di attività commerciali
prevedeva che un operatore caricasse nella memoria del computer istruzioni e dati; il computer
eseguiva le istruzioni sui dati disponibili e produceva i risultati sotto forma di stampe e/o schede
opportunamente perforate per usi successivi. La successiva serie di istruzioni e dati che veniva
caricata nella memoria del computer cancellava ogni traccia del lavoro precedente.
L’operatore, inizialmente caricava dati ed istruzioni in memoria utilizzando una serie di interruttori.
Alcuni computer erano dotati di lettori di schede perforate tramite i quali poteva avvenire il
caricamento in memoria di dati e programmi. Analogo impiego avevano i nastri magnetici.
Nastri e schede perforate ben presto sostituirono gli interruttori e l’attività dell’operatore diventò
principalmente quella di montare nastri magnetici sugli opportuni lettori, inserire blocchi di schede
perforate nei lettori di schede dando quindi al computer il comando di leggere ed eseguire i
programmi. Il colloquio tra uomo e macchina era diretto ed il computer non aveva alcuna
“coscienza” di essere un computer se non quando l’operatore gli dava in pasto delle istruzioni da
eseguire; non aveva alcuna conoscenza delle periferiche che aveva a disposizione se non quando le
scopriva a fronte di una specifica istruzione di un programma applicativo che gli ordinava di
prelevare o inviare qualcosa da o verso una certa unità di Input/Output.
Il computer poteva eseguire una istruzione alla volta ed un programma alla volta, perciò, se aveva
ricevuto l’ordine di dialogare con una stampante, non poteva “contemporaneamente” eseguire
un’altra operazione e, tra l’altro, doveva attendere che il suo colloquio con la stampante fosse
completamente terminato prima di eseguire l’istruzione successiva.
Chi predisponeva il programma da eseguire aveva anche il compito di gestire al massimo dettaglio
ogni singola attività che intendeva far compiere al computer: un programma applicativo era
composto anche da procedure corrispondenti ai driver delle singole periferiche; in tale situazione
l’onere di lavoro del programmatore nel caso di introduzione di una nuova periferica era enorme.
I sistemi operativi hanno consentito un notevole passo in avanti con l’aggiunta di uno “strato
software” che realizza una sorta di astrazione dell’insieme delle apparecchiature hardware rispetto
al programma applicativo e consente anche la sovrapposizione delle attività tra le varie componenti
del sistema. Con l’introduzione dei sistemi operativi si è cominciata a delineare la differenza tra
software applicativo e software di sistema, il sistema operativo appunto, e conseguentemente si è
cominciata a delineare la differenza tra le figure di programmatore applicativo e programmatore di
sistema
L’introduzione dei sistemi operativi ha consentito al programmatore applicativo di disinteressarsi
quasi completamente della gestione degli apparati hardware demandandola al sistema operativo con
il conseguente vantaggio di non dover modificare il programma applicativo a fronte di una modifica
di un qualunque componente hardware.
Il dialogo tra l’uomo e la macchina non era più diretto bensì avveniva per il tramite del sistema
operativo il quale, tra l’altro, si occupava di richiedere l’intervento umano quando necessario, per
esempio per il montaggio di un nastro o altro.
Il fatto che la gestione delle varie apparecchiature hardware non fosse più affidata all’uomo si è ben
presto rivelato un vantaggio decisivo a seguito dell’aumento della complessità delle apparecchiature
21

stesse ed a seguito della conseguente necessità di una loro gestione efficiente al fine di
massimizzarne l’utilizzo quantitativamente e qualitativamente; nessuno, infatti, meglio del sistema
operativo può efficacemente gestire l’ hardware fornendo, dall’altra parte, una interfaccia evoluta
per dialogare con l’uomo. E’ del tutto evidente che continua ad essere l’uomo a gestire le risorse in
quanto il sistema operativo è messo a punto da tecnici, talvolta addirittura specializzati su un
singolo aspetto del sistema operativo.
Le elaborazioni BATCH
I primi sistemi operativi meccanizzavano il lavoro degli operatori accettando dei comandi con i
quali gli veniva comunicato l’ordine di esecuzione dei vari lavori e il luogo dove reperire i dati; una
volta partito il lavoro (JOB) composto da uno o più programmi, il sistema operativo prelevava, al
momento opportuno, il lotto ( BATCH) dei dati per consentirne l’ elaborazione.
Era nata la modalità di elaborazione BATCH (in italiano “a lotti”).
Esempi classici di elaborazioni BATCH sono il calcolo mensile degli stipendi e la produzione
bimestrale delle bollette della energia elettrica; queste attività, una volta lanciate, arrivano a
conclusione dopo avere trattato in sequenza tutti i dati disponibili.
Con un modello di elaborazione del genere il saldo dell’estratto conto di un cliente si leggeva dalla
lista di tutti i saldi, messi in un qualche ordine, prodotta con la periodicità più opportuna,
giornaliera, settimanale, etc. in base alla schedulazione della corrispondente procedura e in
conformità con le necessità aziendali.
L’hardware degli impianti informatici era costituito dal mainframe, da batterie di lettori/perforatori
di schede (successivamente anche da nastri magnetici) e da stampanti.
Il luogo dove avvenivano le elaborazione era la GLASS HOUSE : un ampio locale refrigerato e con
grandi vetrate che ne consentiano la visione dall’esterno.
All’interno della glass house, sui pavimenti sopraelevati necessari per consentire il passaggio dei
numerosi cavi per la connessione delle apparecchiature e per la loro alimentazione, gli addetti,
rigidamente in camice bianco, accudivano la macchina ventiquattro ore su ventiquattro con azioni
sicure che, nonostante fossero piuttosto ripetitive, necessitavano di un notevole addestramento.
L’utente finale non aveva alcun contatto con il sistema di elaborazione limitandosi a fornire gli
input agli addetti ai lavori ed a consultare gli output; in caso di errore le cause erano in genere da
ricercare nella inesattezza dell’input, quindi questo veniva corretto ed il tutto richiedeva una
ulteriore fase di elaborazione.
La modalità di elaborazione BATCH riusciva a meccanizzare egregiamente le elaborazioni basate,
sul trattamento sequenziale di grandi volumi di dati e trovava nelle uniche periferiche allora
disponibili, schede perforate prima e nastri magnetici successivamente, il supporto necessario e
sufficiente per svolgere le attività.
Attività tipicamente interattive come la interrogazione di archivi per il reperimento di singole
informazioni, la realizzazione di attività di aggiornamento di specifiche informazioni all’interno
degli archivi, etc., non trovavano risposte tramite il metodo di elaborazione batch.
22

Le elaborazioni interattive
Il sistema informativo deve soddisfare il modello di business delle aziende in modo più completo
possibile; il sistema di elaborazione BATCH soddisfaceva, in sostanza, le necessità di elaborazione
interne delle aziende, ma poco poteva fare per le necessità di quelle parti dell’azienda che, ad
esempio, operavano a diretto contatto con l’esterno e che perciò avevano necessità di uno strumento
interattivo e quanto più possibile veloce al fine di garantire la soddisfazione dei clienti.
Si pensò, allora, a nuovi strumenti software per interfacciare gli utenti finali (il cassiere di una
banca, l’operatore di un ufficio postale, l’addetto alle prenotazioni di una compagnia aerea, etc.) con
il sistema di elaborazione: era necessario, sostanzialmente, un intermediario che accettasse, da un
lato, le richieste provenienti da un posto di lavoro, attivasse tramite il sistema operativo le
necessarie operazioni e restituisse infine il risultato. Nascevano così i Transaction Processing
Monitor (TP monitor), prodotti software middleware, che si occupano di accettare una richiesta da
parte dell’utente, avviare una o più transazioni a fronte della richiesta, monitorare il corretto
completamento della attività e consegnare alla fine il risultato al richiedente. Tra i compiti dei TP
monitor vi sono il controllo e la gestione delle code di arrivo delle richieste di attività (transazioni) e
il controllo della corretta conclusione delle varie transazioni.
Una transazione è conclusa quando ha eseguito con successo tutte le singole operazioni di cui è
composta. Poiché ogni singola operazione può effettuare modifiche sui dati il TP monitor deve
essere in grado di ripristinare le condizioni iniziali nel caso in cui la transazione complessiva non
arrivi ad una conclusione regolare.
Le unità di elaborazione su cui gravava il carico di lavoro di tipo transazionale erano sempre i
mainframe, tuttavia le periferiche tipiche delle elaborazioni BATCH non erano adeguate alle
elaborazioni di tipo transazionale; da questa necessità, e grazie ai progressi tecnologici nell’area
della memorizzazione dei dati, si diffuse rapidamente l’impiego dei dischi magnetici che in quegli
ambienti vennero definiti con l’esatto acronimo rispondente alle specifiche caratteristiche: DASD,
cioè Direct Access Storage Device.
La composizione hardware degli impianti informatici si arricchiva, perciò, con le unità di
immagazzinamento a disco e, fuori dalla glass house, si moltiplicava la disponibilità di terminali
tramite i quali gli utenti interagivano con il sistema. I progressi nelle telecomunicazioni
consentirono la messa a punto di modelli per la realizzazione delle reti di comunicazione, a partire
dai modelli di rete puramente gerarchici.
La possibilità di disporre di un impianto informatico era comunque riservata alle grandi
organizzazioni visti i costi piuttosto elevati sia in termini di hardware e strutture connesse sia in
termini di personale, numeroso e altamente specializzato.
Vi era anche, però, un enorme potenziale rappresentato da piccole realtà e da singoli gruppi
all’interno di grandi realtà che, pur avendone necessità, non potevano “permettersi” uno strumento
informatico troppo costoso.
Le elaborazioni TIME SHARING
Una prima svolta nella diffusione dell’informatica si ebbe, negli anni 60, con la introduzione dei
minicomputer, macchine con potenzialità di calcolo ridotta rispetto ai mainframe, ma che si
adattavano perfettamente ad ambienti operativi piccoli e che non richiedevano rigide schedulazioni
23

né una accurata gestione delle transazioni. Queste apparecchiature, grazie a sistemi operativi
specificamente predisposti, consentivano ad un numero limitato di utenti il contemporaneo accesso
alle risorse di calcolo, riservando ad ognuno una parte del tempo e delle risorse complessive; i
sistemi cosiddetti TIME SHARING risolvevano bene questa necessità consentendo la costituzione
di ambienti fortemente interattivi; si trattava in sostanza di suddividere tra i vari utenti le risorse
disponibili (tempo di CPU, memorie, etc.) in modo da consentire le singole elaborazioni come se il
tutto fosse al servizio di ogni singolo utente.
In aggiunta, i minicomputers non necessitavano delle glass house in quanto le macchine non
avevano particolari requisiti in termini di raffreddamento, umidità, tecniche di connessione con altre
apparecchiature, etc, e richiedevano un numero di addetti inferiore. L’entusiasmo indotto dalla
disponibilità così vicina e di facile utilizzo degli elaboratori ha portato qualche volta ad un
sottodimensionamento del personale informatico, spesso addirittura assente in alcuni organici.
Le elaborazioni individuali
Gli anni 70 hanno visto la definitiva svolta nella diffusione della informatica con la introduzione del
Personal Computer.
La diffusione dei minicomputers e dei PC, specie con l’avvento delle Local Area Network (LAN),
ha indotto il mercato a cercare di trasferire attività residenti sui mainframe verso le nuove
architetture ritenute più semplici, meno costose e più pronte a soddisfare le necessità rispetto alle
organizzazioni basate sui mainframe.
In realtà, non erano infrequenti, tra gli addetti ai lavori nati ed operanti nel mondo mainframe,
atteggiamenti decisamente elitari che creavano tali attriti con l’utente finale da indurre quest’ultimo
a cercare altrove le risposte alle proprie necessità, producendo talvolta notevoli danni in termini di
efficienza complessiva.
Una parte delle motivazioni che hanno generato il cosiddetto downsizing , cioè il tentativo già citato
di sostituire le grandi apparecchiature di calcolo condivise e, forse principalmente, le strutture e le
organizzazioni connesse, con una grande quantità e varietà di apparecchiature più piccole sotto il
diretto controllo di strutture più vicine all’utente finale o sotto il suo diretto controllo, è da ricercare
anche in una certa inarrivabilità del mondo IT tradizionale.
Ai difetti dei primi grandi elaboratori centralizzati (costi, scarsa elasticità, precarietà e lentezza delle
prime reti di comunicazione, etc.) spesso si aggiungevano, infatti, i difetti indotti dalla
organizzazione dei centri di calcolo piuttosto chiusa su se stessa e non rivolta all’utente finale;
questo stato di cose ha portato ad oscurare i vantaggi di una gestione centralizzata (tra cui la
sicurezza, la continuità di servizio, l’efficienza nella gestione delle risorse, l’economia di scala e
così via).
Se a ciò si aggiunge l’avversione da parte di alcuni ambienti verso quello che veniva visto come il
tracotante e costosissimo strapotere di alcune grandi società del settore informatico storicamente
collegate con gli ambienti dei grandi computer, si capisce bene come si sia arrivati al punto da
ritenere il mainframe, al pari dei dinosauri, destinato all’estinzione e tutti quelli che ne sostenevano
i benefici insensibili alle novità ed al progresso tecnologico ed incapaci di pensare in termini nuovi.
L’estinzione, tuttavia, non si è verificata (almeno fino ad oggi), anche se quanto accaduto ha
lasciato qualche traccia; a cominciare dal fatto che al posto del termine mainframe si preferiscono
24

termini quali server o superserver o enterprise server che, pur riferendosi in sostanza alla stessa
cosa, non urtano la suscettibilità di nessuno.
E’ da precisare, però, che il mainframe (il superserver) di oggi è diverso da quello degli anni 60 in
quanto, tra l’altro:
- consente architetture di calcolo meno rigide di quelle dei primi tempi
- induce costi molto più ragionevoli (sia grazie ai progressi della tecnologia sia per
l’abbandono, imposto dalla pressione del mercato, di alcune “rendite di posizione”)
- è aperto al dialogo con il resto del mondo informatico
- è in grado di ospitare al proprio interno anche sistemi operativi differenti da quelli tipici
degli ambienti mainframe
Inoltre, il modello di business di molte aziende prevede di fornire l’accesso al proprio sistema
informativo direttamente all’utente finale (producendo carichi di lavoro notevoli e poco prevedibili)
24 ore al giorno; in questi casi la scelta non può prescindere dall’uso dei mainframe.
E’ opportuno sottolineare che negli anni 60 le apparecchiature mainframe erano l’unica possibilità
per avviare i processi di meccanizzazione e ciò ha portato al loro impiego anche presso realtà di
dimensioni non idonee a giustificare i costi di un reparto IT così strutturato; in questi casi il
downsizing, reso possibile dalla introduzione del minicomputer e dei personal computer, ha portato
indubbi benefici.
La storia del mainframe porta a riaffermare che non è sempre meglio né ciò che è percepito come
più nuovo o più alla moda né ciò che già si conosce e si è perciò, consciamente o inconsciamente,
indotti ad impiegare in ogni circostanza, ma è meglio ciò che consente di dispiegare la strategia
aziendale nel modo più efficace possibile ottimizzando il rapporto prezzo/beneficio.
Ad ogni modo, la varietà di strumenti di calcolo era, e lo è oggi ancor più, notevole e la cosa
migliore da fare era, ed è, trovare l’impiego più adeguato per ogni strumento nel rispetto del
modello organizzativo aziendale; questa è la vera sfida tutt’ora valida. Per vincere questa sfida le
armi del pregiudizio, nelle sue varie forme, sono sicuramente armi spuntate.
Le elaborazioni CLIENT/SERVER
La architettura di calcolo che si è affermata già da diversi anni, nata grazie alla grande disponibilità
di strumenti di differenti strumenti informatici ed alla evoluzione delle telecomunicazioni, è la
architettura nota come CLIENT/SERVER.
Nello schema seguente si possono ravvisare le principali figure che compongono il modello
client/server:
- chi necessita del servizio, cioè un programma applicativo
- il software client vero e proprio che interfaccia, da una parte, il programma applicativo che
necessita di un servizio e, dall’altra, il programma server che è in grado di erogare il servizio
- chi eroga il servizio, cioè il programma server.
Il software applicativo colloquia con il software client tramite le Application Programming
Interface (API) che quest’ultimo rende disponibili e che determinano quali interazioni sono
possibili tra il software applicativo e l’ambiente client/server specifico.
25

Il software client, a sua volta, dialoga con il software server tramite opportuni protocolli.
Il software server è solitamente in grado di accettare un gran numero di richieste di servizio
provenienti dai software client; analogamente un software applicativo può inoltrare, tramite i
software client, richieste di servizio a differenti software server localizzate su una stessa
apparecchiature o su apparecchiature diverse e talvolta geograficamente sparse.
Software
applicativo
Software
client
Software
server
Dal punto di vista di chi deve progettare, realizzare e gestire un impianto, l’architettura client/server
induce sicuramente delle complicazioni, tuttavia queste sono spesso giustificate dai vantaggi che se
ne traggono.
Quando si deve realizzare una nuova procedura e si ritiene che una architettura client/server soddisfi
al meglio le proprie necessità, si può decidere di sviluppare sia il programma applicativo, sia il
client, sia il server; tuttavia questa eventualità non è molto frequente; piuttosto, si verifica più
spesso il caso in cui si acquista la struttura client/server di cui si necessita e si realizza il programma
applicativo direttamente.
Ad esempio, una applicazione che necessita di una base di dati centralizzata, potrebbe utilizzare la
struttura client/server di un fornitore di data base e sviluppare il programma applicativo vero e
proprio effettuando i necessari collegamenti al data base impiegando le API del client che si è
acquistato (si parla di acquisto per semplicità, più avanti, quando si parlerà del software e dei
contratti informatici, si vedrà che non sempre è possibile parlare di acquisto ma di acquisizione di
una licenza d’uso).
Qualunque sia la scelta, schematizzando l’architettura client/server, si individuano come abbiamo
detto tre figure, l’applicazione, il client ed il server; nella realtà ognuna di queste può essere scritta
da un diverso attore, interno o esterno all’impianto informatico; se a ciò si aggiunge il fatto che
diversi ambienti client/server possono avere necessità di colloquiare tra loro, si intuisce come la
difficoltà progettuale possa aumentare e come possa aumentare ancora di più la difficoltà di
gestione di ambienti del genere.
Ciò non vuol dire, si ribadisce, che l’architettura client/server sia da evitare, bensì vuol dire che un
maggior livello di attenzione è d’obbligo.
26

In definitiva, il modello client/server è un modello di elaborazione distribuita tramite il quale si fa
svolgere ad ognuno ciò che sa fare meglio; è il caso di sottolineare che client/server non è sinonimo
di downsizing, non implica necessariamente un costo complessivo più basso di una metodologia di
elaborazione centralizzata e consente vantaggi che ne giustificano gli eventuali maggiori costi
quando il modello di business aziendale lo richiede.
È il caso di sottolineare che il concetto di “client” ed il concetto di “server” non contengono alcuna
ipotesi circa, ad esempio, la potenza di calcolo di cui devono disporre le apparecchiature dove
risiedono i software client ed i software server; infatti, in una determinata organizzazione
applicativa, un mainframe può contenere un software client che si interfaccia con un software server
che risiede su un minicomputer o su un personal computer; nell’uso gergale dei termini, però, il
concetto di server viene traslato in quello di una apparecchiatura di elaborazione con elevate
caratteristiche in termini di capacità di calcolo, affidabilità, etc., mentre per client si intende una
apparecchiatura di elaborazione con minori potenzialità.
Coesistenza di diverse metodologie di calcolo
Per quanto le elaborazioni BATCH siano nate agli albori della informatica moderna, non si deve
pensare che esse siano scomparse, tutt’altro. Ogni impianto informatico, specie se di medio-grandi
dimensioni, ha quotidianamente il suo carico BATCH.
Addirittura, alcuni delle elaborazioni BATCH che vengono eseguite ancora oggi hanno visto la luce
negli anni 60 o giù di li; ciò è stato reso possibile grazie alla compatibilità consentita nel campo dei
mainframe dai sistemi operativi relativi; la compatibilità di cui si parla si realizza quando con il
cambio di un sistema operativo verso una versione più aggiornata, i programmi applicativi possono
continuare a girare indisturbati, anche se progressivamente in modo meno efficiente. È evidente che
la compatibilità è stata ed è una buona cosa, specie perché testimonia di un disegno, o come si
preferisce dire di una architettura, alla base delle varie evoluzioni; tuttavia “abusare” della
compatibilità può rappresentare, prima o poi, un problema (si vedano a questo proposito i commenti
sul software legacy riportati nel capitolo relativo al software).
Le applicazioni BATCH, una volta uniche “proprietarie” dei sistemi di calcolo, oggi, nei grandi
impianti, devono convivere con altri tipi di carichi di lavoro, tra i quali i carichi di tipo interattivo e
di tipo transazionale, cioè quei carichi di lavoro indotti dagli utenti finali, geograficamente
distribuiti, che per svolgere la loro attività si interfacciano direttamente con i sistemi di calcolo.
I carichi di lavoro di tipo transazionale prefigurano una fila di clienti davanti ad uno sportello, e
perciò devono essere, in genere, privilegiati in termini di tempi di risposta e quindi di priorità di
calcolo; ciò porta alla necessità di una attenta schedulazione delle varie attività. Non si deve, per
questo, pensare che le attività BATCH siano meno importanti all’interno del sistema informativo,
anzi, tutt’altro, poiché di norma appartengono alla fase BATCH anche tutte le procedure di back-up,
e di sicurezza logica in genere, che sono assolutamente necessarie.
La maggior parte delle attività BATCH, d’altra parte, sono rappresentate da procedure in qualche
modo riassuntive delle attività on-line svolte, pertanto si prestano ad essere raggruppate e svolte, ad
esempio, in periodi notturni, durante quella che viene definita la finestra BATCH.
Non è raro il caso in cui la finestra BATCH si protragga per diverse ore durante la notte, talvolta
fino a sfiorare la riapertura dei servizi on line del giorno successivo. Una organizzazione di questo
genere può essere impiegata nel caso in cui le attività dell’azienda o dell’ente si svolgano
27

nell’intervallo di qualche fuso orario al massimo dando così alle ore notturne il significato di ore di
scarso o nullo carico interattivo; diversamente, nel caso di aziende a diffusione planetaria, il
concetto di giorno e notte come momento di carico interattivo forte e nullo si viene a perdere e,
conseguentemente, si devono usare altre soluzioni per consentire lo svolgimento delle eventuali
attività BATCH necessarie.
Le attività BATCH, tuttavia, non sono sempre raggruppabili in momenti “morti”, cioè che non
vedono presenza di altri carichi di lavoro prioritari, ma alcune di esse possono essere richieste in
periodi di normale attività (vuoi per necessità oggettive vuoi per necessità soggettive, cioè di
comodità di chi le richiede); in questi casi è perciò necessaria una attività di controllo volta a
definire le reali priorità e, se del caso, di modificare la schedulazione dei carichi complessivi.
Le attività di controllo e di gestione dei vari carichi di lavoro che gravano su un impianto
informatico sono agevolate dalla disponibilità di sistemi operativi e prodotti middleware idonei:
- a fornire al personale operativo una visione chiara e tempestiva dei livelli di utilizzo delle
varie risorse
- a formulare previsioni sul probabile andamento delle attività e delle performance delle varie
componenti del sistema di calcolo
- ad avviare in tempo reale azioni correttive volte a risolvere situazioni indesiderate
- etc.
Un metodo di analisi di complessi di calcolo sottoposti a differenti tipi di carico di lavoro consiste
nel costruire un modello del complesso di calcolo stesso; lo studio del modello può fornire valide
indicazioni sia al fine di individuare quei componenti che condizionano negativamente le
prestazioni sia al fine di prevedere il comportamento del complesso di calcolo nel caso in cui ne
venga modificata una sua parte (Appendice B – Cenni sui modelli a rete di code)
Il GRID computing
Attualmente, e già da qualche anno, si ipotizza una nuova metodologia di elaborazione la cui
realizzazione consentirebbe di risolvere un certo numero di problemi: si tratta del GRID
COMPUTING.
Il grid computing in realtà non è una novità assoluta nel campo della elaborazione in quanto, già da
molto tempo, è una realtà impiegata per soddisfare le richieste di elevate potenze di calcolo tipiche,
ad esempio, degli ambienti di dove si svolge attività di ricerca sia appartenenti al mondo
accademico e degli istituti di ricerca sia appartenenti all’industria.
La novità è rappresentata dal fatto che oggi si parla di tecniche di grid computing applicate anche ai
comuni ambienti commerciali.
Se il grid computing per la ricerca consiste prevalentemente nella predisposizione di unità di
elaborazione complesse, in cui un certo numero di CPU, anche elevatissimo, vengono connesse al
fine di fornire potenza di calcolo ad una determinata applicazione, nel mondo commerciale il
concetto di grid computing si amplia fino, in linea di principio, a coinvolgere ogni tipo di risorsa
informatica, sia hardware sia software.
L’obiettivo piuttosto ambizioso che si pone il grid computing in ambiente commerciale è quello di
rendere disponibile determinate risorse, rese condivisibili con determinate regole, a chi ne ha
28

isogno quando ne ha bisogno. L’esempio che di frequente viene portato per esemplificare il
concetto di grid computing è la rete di distribuzione della energia.
Nessuno di noi si preoccupa di sapere dove viene prodotta l’energia che preleva da una qualsiasi
presa di casa; se un certo impianto di produzione va, per qualche motivo, fuori servizio, l’utente, in
genere, non se ne accorge neppure in quanto il sistema rimpiazza l’impianto in avaria con uno o più
altri impianti che partecipano alla rete di produzione; se, improvvisamente e più o meno
temporaneamente, la necessità di energia di un utente cresce, il sistema gliela fornisce, entro certi
limiti che sono più dettati da necessità commerciali che tecniche, per soddisfare il picco. La
similitudine con la rete di distribuzione dell’energia si ferma più o meno qua, ma le potenzialità del
grid vanno avanti.
Se, ad esempio, un utente ha necessità di un tipo di risorsa molto costosa per un periodo così breve
da non giustificarne l’acquisto per uso individuale fa la sua richiesta al grid che provvederà a
soddisfarla utilizzando una apparecchiatura posta, da qualcun altro, in condivisione tramite il grid.
Si ritiene che l’accostamento tra grid computing e distribuzione dell’energia, per quanto utile a
rendere il concetto, è piuttosto lontano dalla realtà per diversi motivi:
- innanzi tutto, il livello di standardizzazione delle problematiche connesse alla produzione ed
alla distribuzione della energia è enormemente più elevato rispetto alla standardizzazione
del mondo della informatica; standardizzazione che, di fatto, non esiste;
- quando si parla di soddisfacimento di necessità di picco si può introdurre il concetto di
SCALABILITA’ delle applicazioni, cioè il concetto secondo il quale, semplificando, se si fa
girare una applicazione su due processori si raddoppiano le performance rispetto a quelle
ottenibili qualora girasse su uno solo dei due processori; ciò è prossimo alla realtà per quelle
applicazione che possono operare proficuamente in parallelo su un numero n, teoricamente
grande a piacere, di CPU moltiplicando per n le performance, ma è una situazione irreale
nella generalità dei casi
- le problematiche connesse ad un certo numero di aspetti ausiliari sono piuttosto rilevanti; tra
gli altri gli aspetti relativi alla sicurezza; nel caso dei sistemi di distribuzione dell’energia,
tra gli impianti di produzione e l’utente finale c’è, appunto, la rete di distribuzione che
realizza anche un isolamento, praticamente completo, tra utente ed impianto di produzione
eliminando così ogni problematica di sicurezza connessa ad un utente malintenzionato nei
riguardi dell’impianto; nel caso informatico, invece, l’utente che desidera prelevare potenza
dal grid ha necessità, in genere, di trasferirsi, informaticamente, presso la sorgente di volta
in volta definita dalla architettura del grid; bisogna perciò mettere in campo un sistema di
accreditamento dei vari utenti e, comunque, una serie di azioni per realizzare
quell’isolamento di cui si parlava.
In definitiva, dal punto di vista di chi gestisce gli impianti informatici il grid computing può indurre
un livello di complessità ancora maggiore rispetto al client/server in quanto il grid computing è una
specie di super client/server che non solo valica, nella sua più generale ideazione, i confini
aziendali, ma deve essere tendenzialmente dotato di una certa dinamicità; attualmente si parla di
organizzazioni “virtuali” per riferirsi a coloro che stabiliscono, a fronte, ad esempio, di uno
specifico progetto o di interessi più o meno stabilmente comuni, la costituzione di una struttura grid
tra di loro; ciò è percorribile quando si tratta di progetti di una certa durata e di una certa importanza
per cui si giustificano i relativi costi, ma l’obiettivo di un servizio “a consumo”, o come si suole dire
on demand, completamente senza vincoli, non appare vicino.
29

Tuttavia i vantaggi promessi dal grid computing sono affascinanti: elevato utilizzo delle
apparecchiature condivise, continuità di servizio pressoché assoluta, disponibilità di ciò che serve
quando (e solo quando) serve, etc. e non è, perciò, escluso che facciano da traino ad un generale
riassetto degli ambienti e delle modalità di calcolo, oggi di là da venire, verso una standardizzazione
reale.
E’ improbabile che il riassetto, a breve o medio termine, possa riguardare quanto già esistente, ma
sarebbe già un enorme passo avanti se questo riassetto coinvolgesse significativamente gli sviluppi
futuri dell’informatica. Per l’esistente, d’altra parte, si potrebbero continuare ad utilizzare le varie
tecniche basate su virtualizzatori, gateway, convertitori, simulatori, connettori ed altri pomposi
concetti del genere che, pur essendo, spesso, componenti anche illustri della grande famiglia delle
“pezze”, possono consentire una coesistenza accettabile grazie alla introduzione di ulteriori strati
software di adattamento tra ambienti intrinsecamente incompatibili.
SOA Service Oriented Architecture
Tra gli ultimi nati della famiglia delle modalità di elaborazione e, più in generale, delle metodologie
di creazione dei sistemi informativi, la Service Oriented Architecture sembra avere tutti i numeri
per far parlare molto di sé; diverse società che producono previsioni sul mondo dell’information
technology sono concordi nell’affermare che il prossimo triennio vedrà una ampia diffusione dei
principi della SOA ed una ampia disponibilità delle aziende ad investire sull’argomento.
È opportuno sottolineare che SOA non è un prodotto o un insieme di prodotti, bensì, così come per
tutte le altre modalità che abbiamo brevemente visto, un modo di progettare i sistemi informativi;
perciò, sfortunatamente non è possibile acquistare un certo prodotto e ritrovarsi, quasi per magia, a
disporre di una architettura SOA; ma si possono acquisire prodotti che agevolano nella
realizzazione di una SOA; naturalmente, disporre di prodotti che agevolano la realizzazione di
sistemi informativi SOA non garantisce circa la qualità del risultato finale.
Il concetto di SOA si basa essenzialmente:
- su tre entità
o l’ utilizzatore del servizio, cioè l’entità che necessita di una determinata funzione
o il fornitore del servizio, cioè l’entità che realizza una determinata funzione e la rende
disponibile, a chi volesse utilizzarla, tramite una sorta di interfaccia
o l’intermediario, cioè l’entità che può fornire supporto all’utilizzatore nel caso in cui
quest’ultimo non sappia già a chi rivolgersi per soddisfare la sua necessità
- e sulle attività da esse svolte
o la pubblicazione da parte di un fornitore delle caratteristiche del proprio servizio
seguendo modalità prestabilite
o la ricerca da parte di un utilizzatore della fonte a cui richiedere il servizio di cui
necessita
o la invocazione effettiva di un servizio da parte di un utilizzatore nei riguardi di un
fornitore
Utilizzatore, fornitore ed intermediario non fanno riferimento, naturalmente, a persone ma a
componenti del sistema informativo di una azienda o, più in generale, a componenti dei sistemi
informativi di aziende diverse che hanno necessità di interagire.
30

In base a questa architettura, l’utilizzatore non dovrà preoccuparsi del “come” un certo servizio è
implementato e, tanto meno, dei dettagli tecnici connessi alle piattaforme hardware e software che
realizzano quel determinato servizio ma, “semplicemente”, lo utilizzerà instaurando con il fornitore
un dialogo tramite un linguaggio comune e dettagliatamente regolamentato.
Ogni metodologia di elaborazione o architettura dei sistemi informativi ha come obiettivo primario
la realizzazione del miglior supporto possibile alle strategie di business delle aziende; un sistema
informativo costruito in base ai principi della SOA, partendo dalle necessità di business per la
individuazione dei servizi necessari, garantirebbe:
- una elasticità ottimale del sistema informativo in grado di rispondere velocemente alle
variazioni nelle necessità di business (grazie anche alla possibilità di riutilizzo dei singoli
servizi in coreografie differenti)
- una più agevole manutenzionabilità del sistema informativo nel suo complesso
- il “mascheramento” pressoché completo della complessità e della eterogeneità largamente
presenti nelle piattaforme hardware e software degli impianti informatici odierni.
Poiché, come si vedrà meglio più avanti, il patrimonio software applicativo delle aziende è
assolutamente rilevante, i principi della SOA contemplano anche la possibilità di impiegare il
patrimonio esistente purché opportunamente trasformato in ottica di servizio.
In definitiva SOA si ripromette di creare una ambiente, quanto più ampio possibile, in cui le
necessità dei vari attori possano trovare soddisfacimento “orchestrando” opportunamente diversi
servizi, provenienti da diversi fornitori di servizi, sulla base di determinate regole che consentano di
trascurare le specifiche implementazioni dei vari componenti; una grande standardizzazione che, da
un lato, consente a ciascuno di costruire il proprio sistema informativo mettendo insieme diversi
servizi, e, dall’altro lato, consenta il riutilizzo dell’esistente e la creazione di nuovi servizi
utilizzando differenti piattaforme ma presentandone una interfaccia in linea con determinate regole.
31

INTRODUZIONE - Domande di verifica
1 Un impianto informatico esiste perché esiste l'utente
per provare soluzioni nuove
perché è di moda
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
2 Il modello di business aziendale deve adeguarsi è vero
alla architettura IT scelta
è falso
dipende dai piani di disaster
recovery
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
3 Per TCO si intende la valutazione del "costo di relativo all' hardware
possesso" in un certo periodo di tempo e
relativo al software
complessivo
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
4 Anche secondo una direttiva del Ministero per costi per abbandonare una
l'Innovazione e le Tecnologie, cosa si intende per tecnologia
costo di uscita
costi per la produzione di
tabulati
costi per produzione di
nuove normative
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
32

5 E’ un impianto informatico "General Purpose" un impianto che non
necessita di speciali
caratteristiche
un impianto dotato di CPU
vettoriali
un impianto che opera in
condizioni ambientali
fuori dal comune
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
6 Il "downsizing" è consistito nel tentativo di da mainframe ad unità più
spostare carichi di lavoro piccole
da tecnologie CMOS a
tecnologie bipolari
da dischi a nastri
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
7 La grande diffusione della informatica distribuita dalla diffusione della
è stata agevolata anche tecnologia LTO
dalla scarsa sicurezza
degli impianti centralizzati
dalla scarsa attenzione ai
clienti
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
8 Uno dei vantaggi delle metodologie di elaborazione la presenza di compilatori
centralizzate spesso basate su mainframe
è in genere la disponibilità di più MIPS
l'affidabilità complessiva
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
33

9 La modalità di elaborazione batch è del tutto scomparsa
è l'unica tecnica esistente
è ancora presente
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
10 In una architettura client/server il concetto di l' elaboratore con sistema
server identifica operativo Linux
un mainframe
un componente software
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
11 In generale le metodologie GRID riguardano solo CPU
solo Dischi e nastri
vari tipi di risorse
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
12 Tra i vantaggi dell'impiego di architetture GRID l'uso di ambienti JAVA
vi è
l'uso condiviso di risorse
costose
l'uso di software OPEN
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
34

13 Parte integrante del progetto di un impianto la previsione dell'impiego
informatico è di una architettura SAN
la definizione di un piano
per il disaster recovery
l'outsourcing
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
14 Cosa si intende per "finestra batch" la grande vetrata che
consente la visione della
glass house
l'arco di tempo in cui sono
prevalentemente effettuate
elaborazioni batch
l'arco di tempo in cui le
elaborazioni batch sono
proibite
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
15 La presenza di "single point of failure" in termini diminuisce il TCO
di risorse e/o di persone
ottimizza l'impiego delle
risorse
espone a potenziali disastri
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
35

2 L’HARDWARE
Obiettivi del capitolo
- conoscere le componenti Hardware di un impianto informatico
- comprendere cosa si intende per miglioramenti tecnologici e per miglioramenti
architetturali
- conoscere le tendenze che caratterizzano l’evoluzione hardware di un moderno
impianto informatico e comprenderne le motivazioni
- familiarizzare con le principali apparecchiature ausiliarie presenti in un
impianto informatico
36

2.1 Introduzione
L’ informatica “moderna”, che impiega apparecchiature elettroniche e si differenzia dalla
informatica “antica” in cui l’elettronica non aveva ancora fatto la sua comparsa, è una materia che
risale ad una cinquantina di anni fa. Cinquanta anni di storia non sono apparentemente molti, ma
cominciano ad essere sufficienti, pare, per giustificare libri, corsi e quant’altro che abbiano come
oggetto, appunto, la storia della informatica.
I progressi fatti in questo periodo sono stati straordinari: hanno reso obsolete alcune cose ma molti
principi sono rimasti validi; perciò, in quanto segue, si cercherà di distinguere ciò che è superato e
si riporta a soli fini storici o per facilitarne la comprensione degli sviluppi, da ciò che esprime
concetti sempre validi.
La differenza tra ciò che è sempre valido e ciò che non lo è più è spesso connessa al fatto, ad
esempio, che quanto permane valido è connesso a leggi fisiche di natura mentre ciò che risulta
superato è connesso ad aspetti organizzativi predisposti dagli addetti ai lavori sulla base delle
conoscenze e delle tecnologie di certi momenti storici e poi superate con il progredire della materia.
Questa suddivisione apparentemente semplice è complicata dal fatto che, in campo informatico, non
di rado si assiste al ritorno, con nomi diversi, di concetti e organizzazioni già noti; questo fenomeno
avviene per vari motivi, non ultimi motivi commerciali, e richiederebbe la predisposizione di un
dizionario dei sinonimi.
Per la verità, anche ciò che si può definire legge fisica di natura è un argomento che può non essere
tanto stabile o, per meglio dire, è stabile entro certi limiti; e anche questi limiti non sono stabili e
continuano a spostarsi; chi si occupa di problematiche strettamente tecnologiche è avvezzo a questo
fenomeno e, anzi, contribuisce costantemente ad esso.
A proposito di progressi, qualcuno si è preso la briga di paragonare i progressi in campo
informatico con quelli ottenuti nel campo del trasporto aereo ed è arrivato alla conclusione che, se il
trasporto aereo fosse andato alla stessa velocità della informatica, oggi, un volo New York - Parigi
dovrebbe costare circa un centesimo di dollaro e durare circa 250 millesimi di secondo, millesimo
in più millesimo in meno.
Ci si può chiedere il motivo di queste differenze; probabilmente, uno dei fattori principali che hanno
fatto correre l’industria dell’ hardware per l’informatica è rappresentato dalla libertà di azione di cui
ha goduto la ricerca di base nel settore. A guardare bene, poi, ciò che nel settore informatico ha
fatto i maggiori passi avanti è stato tutto ciò che è connesso all’ hardware e, per maggiore
precisione, tutto ciò che è connesso alla parte elettronica dell’ hardware.
L’hardware presente in un impianto informatico e che necessità di progettazione e di gestione può
essere suddiviso in due grandi famiglie:
- apparecchiature informatiche;
- apparecchiature ausiliarie.
Per apparecchiature informatiche si intendono elaboratori, apparecchiature di memorizzazione di
massa, stampanti, apparecchiature per le comunicazione e altre apparecchiature di input-output.
37

Per apparecchiature ausiliarie si intendono tutte le apparecchiature di servizio necessarie al
funzionamento dell’impianto; tra di esse possiamo individuare le apparecchiature di alimentazione,
le apparecchiature per il controllo ambientale e di sicurezza, etc.
Alcuni cenni sulle apparecchiature ausiliarie sono forniti nel capitolo riguardante i luoghi.
38

2.2 Apparecchiature informatiche
Le apparecchiature informatiche svolgono diversi compiti; tuttavia per ogni compito non è
necessariamente presente una box (cioè un insieme elettromeccanico racchiuso in un singolo
armadio o Frame) fisicamente indipendente e connessa in qualche modo con le altre. Infatti, diverse
funzionalità possono talvolta essere svolte dalla medesima box; ma ciò in generale non influenza
quanto si dirà a proposito delle singole funzionalità.
L’esperienza del PC è comune a tutti ed in questo caso, ad esempio, la funzione di elaborazione
(CPU), parte più o meno rilevante della funzione di memorizzazione di massa (unità a disco), parte
della funzione di comunicazione (modem, schede di rete, etc), sono normalmente incluse nella
stessa box. Mentre chi ha esperienza in area mainframe, ed ancor di più nell’area mainframe così
come era fino a qualche anno fa, è abituato a vedere una box per ogni funzionalità e addirittura box
diverse a comporre una singola funzionalità.
La figura sottostante, tratta da una pubblicazione della IBM [2], riporta una parte di una sala
macchine di un impianto informatico di media grandezza di parecchi anni fa, dove fanno bella
mostra una serie di macchine per la gestione dei nastri magnetici.
Situazioni del genere sono praticamente del tutto scomparse dal punto di vista della occupazione di
spazi fisici mentre permangono dal punto di vista logico, cioè in termini di numero di dispositivi
(nella fattispecie di drives nastro, oggi drives a cassetta come si vedrà più avanti) necessari per
gestire il corretto svolgersi delle operazioni.
Ad ogni modo qualitativamente ciò che verrà detto in genere non cambia.
Miglioramenti tecnologici e miglioramenti architetturali
39

Le singole famiglie di apparecchiature informatiche hanno avuto, come detto, un progresso
tecnologico rilevante.
Il progresso tecnologico consiste, principalmente, nel consentire di effettuare lo stesso lavoro in
minor tempo, con minore ingombro e, in definitiva, ad un costo più basso, costruendo con tecniche
sempre più avanzate i vari componenti.
Le apparecchiature informatiche, al fine di realizzare le attività di volta in volta necessarie, devono
dialogare tra loro. Una unità di elaborazione scambia continuamente informazioni con la memoria
centrale,
molto probabilmente gli scambi di informazioni coinvolgeranno anche le unità di
memorizzazione di massa e le unità di comunicazione. La risposta da parte di una unità può essere
condizione necessaria per il proseguimento della attività della unità che ha effettuato la richiesta, e
così via.
Sfortunatamente la velocità con cui opera una unità di elaborazione è del tutto differente dalla
velocità
con cui opera una unità a disco ed entrambe sono del tutto diverse dalla velocità con cui
opera una stampante o una unità a nastro. Le velocità tipiche delle diverse famiglie di
apparecchiature informatiche sono del tutto differenti; ciò a causa delle caratteristiche fisiche delle
varie famiglie di apparecchiature. Una unità di elaborazione opera ad una velocità che dipende da
circuiti elettronici mentre una unità a disco deve ancora fare i conti con componenti meccanici così
come le unità a nastro e, ancor più, le stampanti.
E’
facile perciò intuire che se una unità di elaborazione che necessita di una informazione residente
su un disco dovesse fermarsi, in attesa della risposta del disco, il suo utilizzo sarebbe tutt’altro che
ottimale. Ad esempio, se una unità di elaborazione avesse una capacità di mille operazioni al
secondo ed una unità a disco di una operazione al secondo, ad ogni richiesta sottomessa al disco
l’unità di elaborazione perderebbe la possibilità di eseguire 999 altre operazioni
nell’attesa della
risposta
da parte del disco.
Così, al fine di migliorare l’efficienza complessiva dei sistemi, sono stati introdotti interventi
tecnologici per migliorare le prestazioni all’interno di una famiglia di apparecchiature, e interventi
architetturali
per migliorare le prestazioni sia all’interno di una famiglia di apparecchiature sia
nello scambio di informazioni tra le varie famiglie, realizzando un disaccoppiamento nel
funzionamento.
Un classico esempio di miglioramento tecnologico, come si vedrà meglio più avanti, è
rappresentato dalla evoluzione nelle tecniche di costruzione dei circuiti integrati; un altrettanto
famoso esempio di miglioramento architetturale è rappresentato dalle tecniche di caching e da tutte
le altre tecniche che hanno introdotto livelli di hardware intermedi tra famiglie distanti dal punto di
vista delle prestazioni ed il cui funzionamento, perciò, doveva essere reso, per quanto possibile,
indipendente.
Nel panorama informatico complessivo, le tendenze di sviluppo seguite dai vari attori del settore
sono, per quanto riguarda gli aspetti tecnologici, sostanzialmente coincidenti; a fare la differenza è
la capacità delle singole organizzazioni di ingegnerizzare prima degli altri il risultato della propria
ricerca scientifica passando dai prototipi di laboratorio ai prodotti commerciali.
Anche per quanto concerne gli aspetti architetturali, le tecniche di caching e gli altri interventi volti
a disaccoppiare il funzionamento tra famiglie differenti sono generalmente riconosciuti necessari ed
impiegati in ogni tipo di apparecchiature, dal più piccolo PC al più grande mainframe.
40

2.2.1 Unità di elaborazione
fig. 1 ASSC Automatic Sequence Controlled Calculator
La figura 1 rappresenta uno dei primi elaboratori.
Si tratta di una macchina installata da IBM nel 1944 presso la Università di Harward. Era lunga 51
piedi, pesava 6 tonnellate, conteneva 3300 relays e 530 miglia di fili. L’ASSC realizzava
mediamente una moltiplicazione in poco meno di 6 secondi.
41

Evoluzione tecnologica
Molta strada è stata percorsa da allora; basti pensare che il più piccolo personal computer è oggi
estremamente più potente dell’ ASSC.
L’ASSC, come i moderni computer, si basava su un sistema binario cioè era in grado di
riconoscere, come i moderni computer, solo due entità, che simbolicamente erano, e sono, indicate
come 0 e 1. Un alfabeto fatto solo di 2 simboli tramite i quali, però, è possibile rappresentare ogni
cosa. I contenitori fisici di questi due simboli erano, per l’ ASSC, i 3300 relays di cui si è detto;
cioè, in sostanza, 3300 interruttori che potevano assumere una posizione tra due possibili: acceso o
spento, ON o OFF, un livello di tensione alto o un livello di tensione basso, etc. ogni interruttore
rappresenta un bit, cioè la più piccola unità di informazione; mettendo insieme un gruppetto di
interruttori è, come è noto, possibile creare una corrispondenza biunivoca tra una informazione
espressa in un sistema che dispone di un numero diverso di simboli ed il sistema binario.
Il più noto gruppetto di bit è il byte che è composto da 8 bit. Tutte le apparecchiature che si basano
sul sistema binario vengono in genere definite apparecchiature digitali e sono contrapposte alle
apparecchiature analogiche le quali, in linea di principio, operano con un “alfabeto” composto da un
numero di simboli molto grande, anzi infinito (Appendice C – Analogico/Digitale).
Fisicamente il bit ha, nel tempo, cambiato “forma” ed i relays sono stati sostituiti, agli inizi degli
anni 50 dai tubi sottovuoto, noti anche come valvole. Le valvole ponevano seri problemi in termini
di affidabilità, le alte temperature in gioco inducevano una vita media piuttosto bassa dei
componenti, e nelle sale macchine dotate di computer a valvole non era strano vedere un addetto
andare in giro con un carrellino pieno di valvole nuove con le quali sostituire quelle che andavano
fuori servizio.
Le condizioni operative delle valvole non si prestavano, inoltre, ad una loro miniaturizzazione,
perciò le prestazioni complessive ottenibili erano anche limitate dai lunghi percorsi che i segnali
elettrici dovevano percorrere all’interno delle apparecchiature.
Agli inizi degli anni 50 il transistor ha spazzato via i suoi predecessori, così i componenti a stato
solido, basati sui semiconduttori (Appendice D – Cenni sulla teoria dei semiconduttori) hanno preso
un netto sopravvento.
Dalla introduzione dei componenti a stato solido è cominciata la grande corsa alla integrazione dei
componenti stessi che ha attraversato varie fasi ed ha visto impiegate varie tecniche (Appendice E –
Cenni sulla tecnica di fabbricazione planare di dispositivi a semiconduttore); questa corsa continua
ancora oggi.
Nel 1965, Gordon Moore, che successivamente sarebbe stato uno dei fondatori della INTEL, a
seguito delle sue osservazioni e dei suoi studi, arrivò ad una conclusione che, lì per lì, sembrò un
po’ azzardata. Moore predisse che la densità di integrazione dei circuiti a semiconduttore sarebbe
raddoppiata ogni anno; nel 1975 Moore corresse, per gli anni futuri, la sua previsione ipotizzando il
raddoppio della densità di integrazione all’incirca ogni 2 anni. Questa previsione è diventata
universalmente nota come la legge di Moore, e attualmente la sua validità continua ad essere
rispettata. Come detto precedentemente, vi sono leggi e leggi entro certi limiti; la legge di Moore è
una legge entro certi limiti, tuttavia tali limiti non sono ancora stati raggiunti; più volte, per la
verità, ne è stato preannunciato il raggiungimento, ma, fino ad oggi, quelli che sembravano limiti
invalicabili sono stati regolarmente superati consentendo alla legge di Moore di superare indenne i
decenni ed entrare nel nuovo millennio con immutata vitalità.
42

La vera forza che ha causato la corsa alla integrazione sempre più spinta è costituita, come spesso
accade, dai fattori economici che ne derivano; infatti, per quanto sia più costoso produrre chip
sempre più densi, la quantità di prodotto, cioè il numero di chip, che si ottiene cresce più
rapidamente consentendo, complessivamente, un costo inferiore per ogni pezzo finito. Per avere una
idea sulla riduzione dei costi indotta dalla crescente integrazione, basta dire che un transistor che
alla fine degli anni 60 costava all’incirca 1 dollaro oggi costa già meno di 1 nanodollaro.
Ma la evoluzione delle tecniche di integrazione non ha portato solo ad un abbattimento dei costi dei
chip.
La tecnologia CMOS, oggi prevalente e largamente diffusa, fino a metà degli anni 90 non
consentiva la costruzione di elaboratori basati su di essa e con potenze di elaborazione adeguate
specie nel campo dei mainframe; l’ottenimento delle potenze di calcolo desiderate era invece
possibile con l’impiego della tecnologia bipolare che perciò era la più impiegata per le grandi
apparecchiature di calcolo. Il motivo di ciò risiedeva nel fatto che il singolo transistor realizzato con
tecnologia CMOS era intrinsecamente meno veloce di un transistor realizzato con tecnologia
bipolare il quale, di contro, era molto più esigente in termini, ad esempio, di calore da dissipare e di
energia elettrica necessaria al suo funzionamento, mentre il transistor CMOS era, per dir così, molto
più freddo. Proprio queste caratteristiche hanno fatto si che la densità di integrazione dei circuiti
CMOS procedesse spedita, e procede ancora oggi, mentre la densità di integrazione delle porte
bipolari ha dovuto segnare il passo a causa delle crescenti difficoltà ad assicurare adeguate
condizioni operative.
Poiché, per quanto ciò non fosse una esplicita affermazione di Moore, più transistor equivalgono a
più potenza di calcolo, a metà degli anni 90 i componenti CMOS sono stati in grado di cominciare a
sostituire i componenti bipolari anche nei grandi mainframe conservando adeguate prestazioni.
Questo passaggio, oltre ad un abbattimento dei costi di acquisto delle apparecchiature, ha portato ad
un cambiamento veramente epocale nella predisposizione fisica dei centri di calcolo e nelle
necessità di energia per la alimentazione delle macchine.
La tabella sottostante riporta il confronto di alcune grandezze significative relative a due
apparecchiature mainframe IBM, una in tecnologia bipolare e l’altra in tecnologia CMOS
Mainframe “Bipolare” Mainframe “CMOS”
Peso complessivo Circa 14 tonnellate Circa 1 tonnellata
Potenza elettrica richiesta Circa 150 KVA Circa 5 KVA
Spazio richiesto Circa 670 piedi quadrati Circa 50 piedi quadrati
Numero totale di chips Circa 5000 Circa 30
Si tenga presente, inoltre, che il mainframe CMOS riportato nella tabella (rilasciato nel 1999)
disponeva di una potenza di calcolo circa doppia rispetto al sistema basato su tecnologia bipolare
(IBM ES/9000).
Come si vede le differenze sono davvero sostanziali e sono facilmente intuibili gli impatti di queste
differenze sul costo complessivo indotto dalle due apparecchiature grazie alle diverse tecnologie
impiegate.
43

Le due figure sotto riportate danno una idea di ciò che ha comportato l’evoluzione tecnologica e, in
particolare, il passaggio dalle tecnologie bipolari alla tecnologia CMOS nel campo dei mainframe.
Le funzionalità delle BOXES (armadi) che componevano il sistema IBM in tecnologia bipolare
riportato nella foto precedente (con l’esclusione dei terminali in primo piano e delle unità a disco ed
a nastro, cioè le unità più basse delle altre a sinistra nella foto) sono incluse nella singola BOX
riportata in basso che riporta un mainframe IBM in tecnologia CMOS.
44

L’International Technology Roadmap for Semiconductors (ITRS) [3] è un organismo
internazionale cui partecipano aziende, stati, università ed altri attori dei cinque continenti, e che si
occupa di monitorare l’andamento delle tecnologie dei semiconduttori producendo, periodicamente,
relazioni sullo stato dell’arte, previsioni a breve termine (5 anni) e previsioni a lungo termine (15
anni). Nelle relazioni vengono anche evidenziati i problemi all’orizzonte e le possibili soluzioni,
anche solo teoriche.
L’ITRS fornisce anche previsioni sugli anni in cui saranno disponibili nuove generazioni di circuiti
integrati; una nuova generazione, per convenzione, è ritenuta tale se una certa dimensione assunta a
riferimento, e definita hp (half pitch), è uguale o minore allo 0,7 della stessa dimensione nella
generazione precedente. Una nuova generazione è definita Technology Node. Le previsioni, basate
anche sulla recente storia, indicano un technology node ogni 3 anni; il technology node attuale è
definito hp90 (90 nanometri); il 2007 dovrebbe vedere il technology node hp65, il 2010 hp45, il
2013 hp32 ed il 2016 hp22.
A metà del 2004 la INTEL ha dato alcune anticipazioni sullo stato di avanzamento della tecnologia
presso i suoi laboratori fornendo alcuni dettagli sulla sua tecnologia hp 65.
In un mondo in cui più piccolo è sinonimo di più avanzato, c’è però una dimensione il cui aumento
consente di ridurre i costi; si tratta della dimensione della fetta di silicio (wafer) su cui vengono
realizzati i chip. Il wafer è ottenuto “affettando” lunghe barre cilindriche di silicio ottenute
purificando e lavorando opportunamente il minerale che si trova in natura.
Fino a qualche anno fa la dimensione universalmente impiegata era 200 mm (diametro della barra
cilindrica e quindi del wafer), oggi si opera con 200 mm e 300 mm, l’ impiego di wafer da 300 mm
consente un aumento di produzione tra 1,6 e 2,2 volte; questo miglioramento nella produttività
induce una serie di benefici generalmente riconducibili al fatto che la stessa quantità di prodotto può
essere realizzata con un numero minore di impianti; oltre ai benefici più facilmente intuibili se ne
ottengono altri, come un minore impatto ambientale per unità di prodotto, che contengono un
grande valore strategico.
Il passaggio da wafer di 200 mm a wafer di 300 mm non è una operazione semplice; si tratta infatti
di costruire nuovi impianti in quanto gli impianti esistenti non sono in grado di gestire il
cambiamento (basti pensare che la manipolazione delle barre di semiconduttore, che poi vengono
“affettate” in wafer, è manuale per il diametro di 200 mm mentre deve essere meccanizzata per il
diametro di 300 mm); tuttavia i costi complessivi per unità di prodotto decrescono di circa il 30 %.
Anche per la dimensione del wafer si fanno delle previsioni, il 2012 dovrebbe vedere l’impiego di
wafer da 450 mm ed il 2019 dovrebbe vedere l’impiego di wafer da 675 mm. E’ assolutamente
probabile che i laboratori delle società più importanti siano già al lavoro per consentire il rispetto
della data del 2012 (visto che il periodo di studio e di pre-produzione per il wafer da 300 mm è
durato 7 anni).
Convenzionalmente si parla di nanotecnologie quando una qualsiasi tecnologia ha a che fare con
dimensioni che vanno da 100 nm ad una decina di nm; la tecnologia dei semiconduttori è perciò già
una nanotecnologia; come è già accaduto in passato, alcuni scienziati vedono vicini limiti
invalicabili, perciò si stanno studiando soluzioni alternative (ed altre del tutto diverse) per il futuro.
45

Ma lasciamo ora il mondo dell’infinitamente piccolo e torniamo alle nostre abituali dimensioni
dando una occhiata alle unità di elaborazione da un punto di vista, per dir così, macroscopico, più
confacente a chi opera all’interno di un impianto informatico.
Considerazioni sulle prestazioni
Il ritmo delle attività di una unità di elaborazione (ciclo di clock) è scandito da un circuito
elettronico. Il ciclo di clock altro non è che l’inverso del cosiddetto clock rate o frequenza di clock
che tutti ben conosciamo in quanto viene elencato tra le prime caratteristiche di un certo processore.
Ogni unità di elaborazione è in grado di eseguire solo uno specifico insieme istruzioni (ISA cioè
Istruction Set Architecture), chiamate istruzioni macchina; due unità di elaborazione differenti
avranno in genere set di istruzioni macchina differenti. Come è noto, è terribilmente faticoso per gli
esseri umani normali esprimersi correntemente in linguaggio macchina, perciò preferiamo
esprimere i nostri comandi in linguaggi più evoluti e necessitiamo, quindi, di un traduttore che di
volta in volta è rappresentato dai cosiddetti compilatori ed interpreti.
L’esecuzione di una istruzione macchina richiede una o più operazioni elementari; assumeremo che
ciascuna di queste operazioni elementari venga eseguita in un ciclo di clock. Ciascuna istruzione
macchina, pertanto, richiederà uno o più cicli di clock per la sua esecuzione; pertanto l’esecuzione
di una istruzione macchina richiederà un determinato numero di CPI, ovvero cicli per istruzione.
Supponiamo allora che un certo programma produca la esecuzione di un certo numero di istruzioni
macchina che chiameremo I; supponiamo inoltre che sulla unità di elaborazione sulla quale stiamo
operando ogni istruzione eseguita necessiti mediamente di un certo CPI; se, infine, il ciclo di clock
della nostra unità di elaborazione (uguale all’inverso della famosa frequenza sopra citata) è pari,
diciamo a C, allora il tempo necessario a quel determinato programma per concludersi su quella
determinata CPU sarà :
Ad esempio, se il nostro programma
T = I x CPI x C
produce l’esecuzione di 20.000.000 di istruzioni, cioè I = 20.000.000
con un CPI medio di 3,5 cicli/istruzione, cioè CPI = 3,5
sulla nostra CPU con clock rate 800 MHz, cioè C = 1,25 10 -9 s
allora T = 20 10 6 x 3,5 x 1,25 10 -9 = 0,0875 s
E’ utile chiedersi, specie per chi all’interno di un impianto informatico dovesse trovarsi alle prese
con problematiche connesse alle prestazioni di una unità di elaborazione, da cosa sono influenzati i
tre elementi che ci forniscono il tempo di esecuzione in base alla formula riportata.
Il numero di istruzioni eseguite I è senza dubbio influenzato dal programma scritto da noi nel
linguaggio evoluto che abbiamo scelto, cioè dal programma sorgente; giusto per fare un esempio
estremo, un programma sorgente che contiene un errore logico tale da determinare un loop con
condizioni di uscita impossibili porterà il tempo di esecuzione all’infinito, o fino ai limiti
eventualmente consentiti dalla nostra pazienza o da strumenti idonei ad interromperne il
46

funzionamento; la componente I, inoltre, sarà influenzata anche dalla capacità del compilatore che
stiamo usando di ottimizzare la conversione; tale ottimizzazione dipenderà anche dal set di
istruzione macchina proprio della CPU sulla quale stiamo operando. E’ assolutamente probabile, ad
esempio, che a parità di codice sorgente ed a parità di CPU, l’impiego di un compilatore diverso o
di una versione diversa dello stesso compilatore produca tempi di elaborazione diversi.
Il numero medio di cicli per istruzione eseguita, CPI, dipende dalle variabili, viste prima, che
influenzano il numero di istruzioni eseguite I ed, inoltre, dipende anche da come è organizzata la
CPU, cioè dal suo disegno interno.
Il ciclo di clock dipende dalla architettura interna della CPU e dalla tecnologia impiegata nei chip
che compongono la CPU stessa.
Pertanto, se, ad esempio, disponessimo di una manopola per aumentare o diminuire il ciclo di clock,
ad ogni diminuzione (cioè ad ogni aumento della frequenza di clock) osserveremmo, ovviamente,
una riduzione del tempo di esecuzione del nostro programma, compilato con il nostro compilatore;
si noti che la riduzione della frequenza di clock viene adoperata per ridurre i consumi energetici
della CPU.
Come dovrebbe essere altrettanto ovvio, il semplice spostamento del nostro programma su una
CPU che ha una frequenza di clock maggiore non ci consente, in generale, di fare delle previsioni
sul tempo di esecuzione. Lo spostamento, frequentemente chiamato porting, infatti, richiederà
probabilmente la ricompilazione del programma sorgente, utilizzando il compilatore disponibile su
quella macchina, con l’ottenimento di un codice oggetto che, in genere, produrrà un diverso numero
di operazioni eseguite per la conclusione del lavoro.
Nessuna previsione può essere fatta anche se le due macchine sono compatibili a livello di codice
oggetto, il che vuol dire che per fare girare il programma sulle due macchine non c’è la necessità di
ricompilare ma è sufficiente trasportare il codice oggetto e farlo girare. Anche in questo caso la
diversa organizzazione interna della CPU può comportare un diverso numero di CPI medio visto
che, pur essendoci una compatibilità a livello di set di istruzioni macchina, queste, poi,
richiederanno un numero di CPI per singola istruzione, e quindi di CPI medio, dipendente dal
disegno della CPU.
Il tempo di esecuzione è una misura della performance di un certo programma in un certo ambiente
(i benchmark, di cui si parlerà in seguito, utilizzano il tempo di esecuzione di programmi campione
su vari ambienti al fine di metterne in relazione le prestazioni).
Progettare un impianto informatico può comprendere diversi aspetti. Tra gli altri, di frequente capita
di trovarsi di fronte ad una procedura con performance inadeguate alle necessità dell’utente finale;
si è perciò chiamati a progettare degli interventi per superare il problema, cioè per fare in modo che
il requisito relativo al tempo di esecuzione della procedura sia soddisfatto. Si potrebbe ipotizzare
allora che dotarsi di una CPU con frequenza di clock più elevata sia la soluzione migliore e più
sicura; sfortunatamente quanto abbiamo detto ci dice che non è così.
La comprensione dei vari parametri che abbiamo introdotto ci dicono, invece, che si potrebbe
cominciare con l’esaminare il nostro programma per capire se la sua stesura è ottimale o se è
possibile apportare dei miglioramenti, magari eliminando qualcuna delle “toppe” che
“temporaneamente” erano state introdotte in qualche epoca passata e che degradano le prestazioni
complessive. Questo esame dovrebbe in effetti essere sempre fatto, tuttavia, nella pratica, dovrebbe
essere fatto prima di trovarsi sotto la pressione di un inconveniente diventato già un problema; il
47

iesame di una procedura, anche di media complessità, è una faccenda che prende tempo, e quando
un inconveniente è diventato un problema è verosimile che sia già alla attenzione delle “alte sfere”;
in questi casi il tempo scorre con una velocità diversa e ciò che richiederebbe un mese deve essere
fatto in un giorno.
Il problema della revisione dei prodotti software applicativi (specie di quelli prodotti da reparti
interni) è un problema molto ampio e complesso. Presso gli impianti informatici di medie e grandi
dimensioni, il patrimonio di prodotti software ormai definibili antichi e che però giocano un ruolo
fondamentale all’interno del sistema informativo, chiamati spesso software LEGACY e di cui si
parlerà più avanti, ammonta a spaventose quantità di milioni di euro e la loro revisione
comporterebbe costi proporzionali; se il problema fosse stato affrontato via via nel tempo, le cose
sarebbero state forse diverse.
A proposito della quantificazione finanziaria dei prodotti legacy nessuno ovviamente conosce con
una certa precisione la cifra corrispondente, ciò non toglie che scorrendo la letteratura del settore si
trovino le cifre più disparate, tutte terribilmente alte, in grado di stupire l’uditorio di una conferenza
o di riempire una casella di qualche foglio di calcolo; il fenomeno delle stime senza possibilità di
prova contraria è piuttosto diffuso in vari settori e l’informatica non fa eccezione.
Per migliorare la nostra procedura, si potrebbe indagare, allora, sulla disponibilità di un compilatore
più efficiente e/o sulla disponibilità di versioni più aggiornate del compilatore e/o degli altri
strumenti software “di servizio” che influenzano le prestazioni della procedura sotto esame; ciò
potrebbe essere una attività più veloce a patto che essa non implichi modifiche, ancor più se
modifiche sostanziali, di tipo applicativo, cioè a livello di codice sorgente della procedura; in questo
caso si ricadrebbe fatalmente negli stessi inconvenienti della revisione applicativa.
Per potere effettuare immediatamente e semplicemente il confronto tra due unità di elaborazione,
sembra molto promettente il MIPS, cioè i Milioni di Istruzioni Per Secondo.
Nel caso dell’esempio riportato prima in cui avevamo un programma che eseguiva 20 milioni di
istruzioni in 0,0875 s, i MIPS corrispondenti sono immediatamente ricavabili come
MIPS = milioni di istruzioni/tempo di esecuzione = 20/0,0875 = 228,57
Allora, cosa possiamo affermare? Possiamo affermare che la CPU di cui disponiamo è capace di
228,57 milioni di istruzioni per secondo? Sfortunatamente no, in questa forma la nostra
affermazione è piuttosto lacunosa. Possiamo, invece, affermare che il nostro programma, compilato
con il nostro compilatore, porta la CPU di cui disponiamo ad eseguire 228,57 milioni di operazioni
per secondo. La faccenda è un poco diversa.
Cosa è possibile dedurre, ai fini di chi ha una procedura e deve scegliere tra due elaboratori dello
stesso prezzo quello con migliori prestazioni, se ci viene detto che la CPU A ha una velocità di 60
MIPS e la CPU B ha una velocità di 40 MIPS?
Occorre qualche calcolo.
Supponiamo che il programma compilato con il compilatore disponibile sulla CPU A produca
I = 10 10 6 istruzioni
CPI = 4
48

E supponiamo che il programma compilato con il compilatore disponibile sulla CPU B produca
I = 12 10 6 istruzioni
CPI = 2,5
Assumendo che le due CPU abbiano la stessa frequenza di clock, diciamo 200 MHz (cioè tempo di
ciclo C = 5 ns), indicando con Ta e Tb rispettivamente il tempo di esecuzione sulla CPU A e sulla
CPU B si ottiene
Ta = 10 10 6 x 4 x 5 10 -9 = 0,2 s
Tb = 12 10 6 x 2,5 x 5 10 -9 = 0,15 s
Incredibile, la CPU A, accreditata di un numero di MIPS maggiore richiede un tempo di esecuzione
maggiore rispetto alla CPU B accreditata di un numero di MIPS minore; il tutto, naturalmente, a
fronte dello stesso programma sorgente compilato con i compilatori disponibili sulle due macchine.
Da cosa dipende questo risultato? Vi sono alcune possibilità:
- il compilatore disponibile sulla CPU A è meno efficiente del compilatore disponibile sulla
CPU B;
- le istruzioni del programma sorgente si “prestano” meglio ad essere tradotte dal compilatore
disponibile sulla CPU B
D’altra parte, i MIPS per definizione sono pari al numero di istruzioni eseguite, I, riportato in
milioni (cioè diviso per un 10 6 ) diviso il tempo; allora
MIPS = I / (T x 10 6 ) = I / (I x CPI x C x 10 6 ) cioè
MIPS = 1 / (1 x CPI x C x 10 6 ) = Frequenza di clock / (CPI x 10 6 )
In sostanza, se per la misura del MIPS si usano istruzioni con CPI pari a 1 allora i MIPS coincidono
con la frequenza di clock, più è alto il CPI delle istruzioni impiegate più i MIPS si abbassano.
Insomma, si può dire che una stessa CPU ha tanti MIPS in base al tipo di istruzioni che si
impiegano nella rilevazione.
Si vede, perciò, che la strada che porta alla capacità di confrontare due unità di elaborazione non ha
scorciatoie per raggiungere semplicemente e rapidamente la meta.
I benchmark
Un soccorso, per la verità esiste, e può essere impiegato nel caso in cui (molto frequente) non vi sia
la possibilità, prima della scelta, di vedere all’opera la propria applicazione sui vari computer in
ballo.
Si tratta dei già citati BENCHMARK.
I benchmark non sono altro che insiemi di programmi, predisposti da organizzazioni super partes,
che vengono fatti girare sulle varie unità di elaborazione, con condizioni al contorno stabili e
documentate, producendo una graduatoria delle performance delle varie macchine. Come si è detto,
49

ogni istruzione eseguita richiede in genere un numero di CPI diverso dalle altre; in generale,
tipologie di programmi applicativi differenti hanno CPI medio differenti; in altre parole, una
procedura applicativa che serve un ambiente di tipo scientifico utilizzerà in prevalenza determinati
tipi di istruzioni che saranno statisticamente differenti dalle istruzioni impiegate in un ambiente
commerciale. Per fare in modo che il risultato del benchmark sia di reale utilità, esistono perciò
benchmark specialmente indicati per misurare le capacità puramente computazionali delle unità di
elaborazione; altri cercano di simulare i carichi di lavoro tipici di ambienti commerciali, e così via.
La legge di Amdhal
Tornando al tempo di elaborazione T, ed al caso in cui esso non sia del tutto soddisfacente,
supponiamo di scoprire la esistenza di un differente e più efficiente compilatore che riesce a
dimezzare, ad esempio, i CPI medi delle istruzioni di moltiplicazione le quali sono responsabili del
30 % del tempo di esecuzione. Se chiamiamo SPEEDUP il rapporto tra il tempo di esecuzione
originale ed il tempo di esecuzione con l’impiego del nuovo compilatore, quale speedup possiamo
aspettarci nella situazione descritta?
Cercando di isolare il tempo di esecuzione dovuto alla componente oggetto del miglioramento, cioè
l’istruzione di moltiplicazione, si può dire che il tempo di esecuzione originale è composto da una
parte (nell’esempio il 70 %) non dovuta alle operazioni di moltiplicazione e da un’altra parte
(nell’esempio il 30%) dovuta a tali operazioni; se chiamiamo F questa parte influenzata dal
miglioramento, allora
T = (1 - F) T + F T
Se chiamiamo S il miglioramento applicato, allora il nuovo tempo di esecuzione T(E) sarà
Si ottiene allora la legge di Amdahl
T(E) = (1 - F) T + (F/S) T
Speedup(E) = T / T(E) = 1 / ((1 - F) + F/S)
La legge di Amdahl ci dice che:
“lo speedup ottenibile in termini di prestazione mediante l’introduzione di
modalità di esecuzione più veloci è limitato dalla frazione di tempo in cui
tali modalità sono impiegate”
Ad esempio, supponiamo di avere un programma il cui tempo di esecuzione è influenzato per il
50% da una certa istruzione macchina (o più verosimilmente da un certo gruppo omogeneo di
istruzioni macchina) che richiede 4 cicli di clock per la sua esecuzione; supponiamo anche di avere
la possibilità di ridurre a 2 i cicli per la esecuzione di questa istruzione.
Quale sarà lo speedup che si otterrà?
Poiché Speedup(E) = 1 / ((1 - F) + F/S)
e F = 0,5
S = 2
50

Speedup(E) = 1 / (0,5 + 0,25) = 1,33
La legge di Amdahl si presta ad una rappresentazione grafica tanto semplice quanto efficace e
chiarificatrice
T = |___________1 - F____________|_________F__________|
T(E) = |___________1 - F____________|___F / S______|
Da ciò risulta evidente che nel caso si possa agire solo sulla componente F il margine di
miglioramento è limitato dall’ammontare della componente F stessa sulla quale si agisce.
La consapevolezza del significato della legge di Amdahl ci può dare aiutare nel prendere decisioni
di varia natura e in vari settori.
Rimaniamo all’interno della situazione che abbiamo ipotizzato prima.
Supponiamo cioè di trovarci di fronte ad una procedura che non soddisfa i requirements di business
(per usare termini molto di moda) e di avere notizia di un nuovo compilatore che assicuri il
miglioramento dei tempi di esecuzione di una certo gruppo di istruzione richiedendo, però, delle
modifiche non concettuali ma formali all’interno del codice sorgente. Un primo approccio sarebbe
quello di ordinare la revisione dei codici sorgente al fine di individuare e modificare le istruzioni
passibili di miglioramento.
Ma si supponga ancora che il tempo non sia sufficiente per effettuare una operazione così
massiccia; cosa fare?
Si potrebbe allora, aiutati magari da qualche software di servizio, creare una priorità tra le istruzioni
da modificare in base al loro impatto sul tempo di esecuzione della procedura ed intervenire su
quelle più promettenti (cioè con maggiore impatto sul tempo di esecuzione) o intervenire, anziché
sulla più promettente ma enormemente diffusa, su alcune altre di meno impatto singolo sul tempo di
esecuzione ma anche meno presenti e che quindi richiedono una attività più ridotta pur
consentendo, complessivamente, uno speedup adeguato.
La legge di Amdahl ci suggerisce di valutare correttamente la priorità degli interventi sui singoli
programmi che compongono una procedura, sempre al fine di rendere più efficiente il tempo speso
in queste attività.
Tramite la legge di Amdahl si possono risolvere anche questioni leggermente diverse quali ad
esempio:
- quale deve essere il miglioramento da applicare ad una certa componente del tempo di
esecuzione per ottenere lo speedup desiderato?
- richiesto un certo speedup, è possibile ottenerlo agendo solo su una determinata componente
del tempo di esecuzione?
51

La legge di Amdahl consente naturalmente una estensione al caso in cui siano presenti diversi
miglioramenti applicabili assumendo la seguente forma:
Con la seguente rappresentazione grafica
Speedup(E) = 1 / ((1 - Σi Fi) + Σi Fi/Si)
T = |___________1 - F____________|___F1___|___F2____|_____F3______|
T(E) = |___________1 - F____________|_F1/S1_|_F2/S2__|__F3/S3__|
Evoluzione architetturale
La formula che ci consente di ottenere il tempo di esecuzione di un programma sorgente, compilato
con un determinato compilatore, su una unità di elaborazione è:
T = I x CPI x C
Essa contiene una forte approssimazione o, in altri termini, assume come reale una condizione
piuttosto inverosimile; assume cioè che la memoria centrale, dalla quale e verso la quale la unità di
elaborazione preleva ed invia le informazioni, abbia un comportamento ideale grazie al quale non
venga prodotto, sul tempo di elaborazione, alcun ritardo. In effetti, la memoria centrale ha un peso
tutt’altro che trascurabile.
Il problema in sostanza nasce quando la esecuzione di una istruzione macchina richiede il
reperimento di una informazione che risiede nella memoria centrale; idealmente, la microistruzione
che carica l’informazione sulla unità di elaborazione, ad esempio l’operando di una operazione in
un registro della CPU, potrebbe impiegare un ciclo di clock se il tempo di accesso alla memoria
fosse equivalente al ciclo di clock; ciò in generale non è valido e, addirittura, potremmo trovarci ad
operare con una CPU con frequenza di clock di 1 GHz, cioè ciclo di clock di 1 ns, che dispone di
una memoria centrale con tempo di accesso di 100 ns; cosa succede in questo caso? In assenza di
rimedi adeguati, una microistruzione che poteva essere eseguita in 1 ns impiegherà 100 ns;
insomma, la CPU sprecherà 99 cicli (99 ns) nell’attesa che la memoria fornisca quanto richiesto.
Possiamo dire che la formula del tempo di esecuzione è, più correttamente, riscrivibile come
T = I x (CPIcpu+CPImem) x C
Dove con CPIcpu intendiamo i cicli per istruzione considerando una memoria ideale e con CPImem
consideriamo i cicli persi a causa delle attività di scambio di informazioni con la memoria centrale.
Questo problema si è andato sempre più imponendo negli anni in quanto, con il passare del tempo,
la differenza delle prestazioni tra CPU e Memoria si è amplificata e, per di più, si è amplificata con
una velocità molto sostenuta; alcune rilevazione parlano di una crescita del gap tra performance
delle CPU e performance delle memorie al ritmo del 50 % all’anno dalla metà degli anni 80.
Cosa ben diversa è, a fronte di un ciclo di clock, perdere 1 ciclo in attesa (sebbene impiegare 2 cicli
anziché 1 sia sempre una penalizzazione del 100 %) o, a fronte di un ciclo di clock, perderne 100.
52

Ci troviamo di fronte all’esempio, forse più classico, di due famiglie di componenti (CPU e
memorie centrali) con performance progressivamente sempre più diverse, e che però è necessario
che dialoghino tra loro per realizzare i vari lavori; in definitiva si è reso necessario disaccoppiare il
funzionamento delle due famiglie interponendo elementi in grado di alleviare i problemi: le
cosiddette memorie cache, cioè memorie, tecnologicamente diverse dalle memorie centrali, più
veloci frapposte tra CPU e memoria centrale.
La memoria centrale di un computer è in genere di tipo DRAM (Dynamic Random Access
Memory); questa architettura costruttiva dei chip di memoria si basa sul fatto che una informazione
elementare, un bit, è immagazzinata tramite l’impiego di un singolo transistor; l’utilizzo di una cella
di memoria così semplice richiede, però, un REFRESH periodico del contenuto della cella stessa
che, altrimenti, perderebbe la sua informazione; il refresh è effettuato con periodicità di qualche
millesimo di secondo.
Le memorie di tipo SRAM, cioè statiche, prevedono per la singola cella di memoria una architettura
più complessa, basata su un numero maggiore di componenti; le memorie SRAM non richiedono
refresh periodici e hanno migliori prestazioni rispetto alle memoria DRAM, però sono più costose e,
in genere, offrono una minore capacità di memorizzazione a parità di spazio occupato. Per questi
motivi, si può dire che, nella fascia dei computer general purpose, le memorie SRAM sono meno
utilizzate delle memorie DRAM come chip di memoria centrale mentre sono utilizzate per
realizzare le memorie cache dei vari livelli.
Abbiamo cominciato a delineare una sorta di gerarchia delle memorie in base alle loro prestazioni
(sostanzialmente il tempo di accesso) e alle loro capacità di memorizzazione; come dovrebbe essere
chiaro, queste due grandezze sono inversamente proporzionali e possono essere qualitativamente
rappresentate come segue
p memorie
r cache
e
s
t memorie
a centrali
z
i
o memorie
n di massa
i
capacità
La tecnica di gestione delle memorie cache è oggetto di studi che consentono di fare continuamente
passi avanti.
53

Riprendiamo ora l’esame di quella situazione in cui abbiamo ipotizzato di trovarci, cioè torniamo
all’esame di una procedura che non risulta (o non risulta più) idonea a soddisfare i requisiti di
business dal punto di vista delle prestazioni.
E’ evidente che la causa dei problemi può essere un accesso pesante alla memoria centrale (per non
parlare di eventuali accessi necessari sulle memorie virtuali residenti su unità di memorizzazione di
massa). Una diagnosi attendibile in tal senso può essere fatta se si dispone di strumenti (software)
adeguati a monitorare il funzionamento della unità di elaborazione e ad evidenziare l’impatto sulle
prestazioni complessive dei tempi “sprecati” per il reperimento delle varie informazioni nella
gerarchia di memorie disponibile.
Oggi è possibile effettuare interventi di ampliamento delle memorie cache anche sui personal
computer e ciò, talvolta, è più utile che disporre l’impiego di un processore più potente. Se infatti i
cicli in più per unità di tempo, che vengono resi disponibili da una CPU più potente, sono in larga
parte persi a causa dei ritardi (MISS Penalty) che avvengono nella catena della gerarchia di
memoria, il miglioramento macroscopico delle performance sarà deludente rispetto alle previsioni
ed alle attese degli utenti.
E’ facile convincersi di ciò anche alla luce della formula del tempo di esecuzione
T = I x (CPIcpu+CPImem) x C
L’impiego di una CPU più potente porta, in generale, a diminuire il fattore C mentre induce un
aumento sul termine CPImem (anche se nella pratica, la sostituzione di un processore porta in
genere, almeno, alla modifica dei livelli di cache che sono integrati sul medesimo chip e che sono
dimensionati in modo congruente alla potenza di elaborazione); perciò, l’influenza che l’impiego di
una CPU con ciclo di clock minore indurrà su T è tutta da valutare.
Per concludere questa panoramica sulle unità di elaborazione parliamo, brevemente, delle vie di
comunicazione tra CPU, livelli di cache, memoria centrale e mondo esterno.
Il diagramma in basso riporta uno schema semplificato che illustra i collegamenti tra CPU, memoria
centrale e mondo esterno.
Il system bus è progettato e realizzato sulla base di specifiche studiate dai vari costruttori al fine di
ottimizzare lo scambio di informazioni tra CPU e memoria centrale; normalmente non segue
standard di mercato bensì è “proprietario” e le specifiche non sono in genere conosciute nei vari
dettagli.
L’I/O bus, invece, segue standard di mercato, talvolta limitati a determinati ambienti come nel caso
dei mainframe, al fine di consentire una ampia collegabilità delle apparecchiature periferiche. E’
naturalmente interesse dei costruttori di periferiche, e di apparecchiature di I/O in genere, far si che
le loro macchine possano connettersi alla maggior parte dei bus di I/O o, almeno, ai più diffusi per
disporre di un potenziale mercato quanto più ampio possibile.
D’altra parte, a fronte di una vasta gamma di apparecchiature di I/O che prevedono la connessione
ad un determinato bus, i progettisti delle unità di elaborazione saranno indotti a supportare quel
determinato I/O bus al fine di consentire la collegabilità di una quantità di apparecchiature di I/O
quanto più ampia possibile.
54

CPU
cache
L1
L2
L3
System bus
Bus
adapter
I/O controllers
Memoria
controller
I/O bus
I/O controllers
55

La server consolidation
Fino ad ora abbiamo parlato delle componenti di una unità di elaborazione esaminandone, per
sommi capi, il comportamento e l’impatto che possono avere sulle prestazioni complessive. Da ora
in avanti, invece, guarderemo alle unità di elaborazione come un elemento unico che gioca,
naturalmente, un ruolo fondamentale in un impianto informatico.
La disponibilità, a partire dagli anni 70, di unità di elaborazione progressivamente più a basso costo
ha portato alla affermazione di nuovi modelli di elaborazione che hanno visto, progressivamente, lo
spostamento della capacità di calcolo verso l’utente finale; ai mainframe contenuti nelle glass house
e gestiti da specialisti in camice bianco, si sono affiancati nuovi sistemi di elaborazione spesso
definiti dipartimentali in quanto, inizialmente, nati per soddisfare le esigenze informatiche di singoli
gruppi all’interno delle aziende o per soddisfare singole necessità applicative.
L’introduzione dei minicomputer e, successivamente, dei personal computer ha portato alla
costituzione di poli informatici sostanzialmente fuori dal controllo centralizzato delle tradizionali
strutture IT.
La proliferazione di unità di elaborazione dipartimentali è stata rapida e, spesso, non del tutto
razionale, alimentata dal desiderio di autonomia dalle strutture centrali e supportata da una
riduzione dei costi che sembrava consequenziale. Per qualche tempo questa riduzione dei costi è
apparsa generale e reale; generale nel senso che veniva constatata in ogni ambiente, reale in quanto
i numeri sembravano confermarla.
Dal punto di vista dei costi, tuttavia, con l’impiego di tecniche di rilevazione più realistiche e
puntuali, ciò che appariva come una riduzione si è rivelata, al contrario, come un aumento. La
conclusione dei primi progetti di rilievo di migrazione dai grandi sistemi shared centralizzati verso
sistemi dipartimentali ha spesso portato con sé amare sorprese.
Alcune considerazioni si sono affermate con chiarezza; principalmente, si è verificato che venivano
perse delle economie di scala derivanti dalle organizzazioni centralizzate, in termini di
apparecchiature e forse ancor di più in termini di persone per la gestione di tali apparecchiature;
questo effetto non è venuto a galla facilmente in quanto, se è facile risalire ai costi di una struttura
centralizzata, non è semplice addebitare correttamente i costi di una struttura geograficamente
dispersa; in altre parole, ad esempio:
- se una persona definibile utente finale impiega una parte del suo tempo a gestire l’
elaboratore che ha a fianco non è semplice effettuare una conseguente ripartizione del
relativo costo del lavoro;
- se un elaboratore si trova in un ufficio diverso dalla glass house, non è sempre immediato
riuscire ad individuare, all’interno dei costi generali dell’ufficio, i costi indotti dalla
apparecchiatura in termini di energia, di spazi occupati, etc.;
- se vengono acquistati dei prodotti ausiliari (cartucce per stampanti, supporti di
memorizzazione mobili, etc.) presso la struttura IT i relativi costi vanno a quella struttura se,
invece, gli stessi prodotti vengono acquisiti in un qualsiasi altro ufficio, con molta facilità il
relativo costo confluirà nei costi per cancelleria o per materiali vari di consumo;
- infine, le inefficienze derivanti da apparecchiature affidate agli utenti finali, in termini di
continuità di servizio, sicurezza dei dati, etc., non sono immediatamente rilevabili e
richiedono una attenta e onesta attività di analisi.
56

La disponibilità di unità di elaborazione a costi contenuti era ed è, poi, un toccasana per tutti coloro
che desiderano evitare lungaggini apparentemente burocratiche nell’acquisto di una
apparecchiatura; infatti, di frequente, manager intermedi nella organizzazione aziendale godono di
autonomia di spesa entro certi limiti prefissati e variabili da azienda ad azienda; poiché un
elaboratore medio piccolo rientra spesso in questi limiti, la sua acquisizione può essere decisa in
autonomia dal singolo manager ed imputata sulle voci di spesa disponibili al momento ma, talvolta,
difficilmente riconducibili alle spese informatiche.
Addirittura, anche nel caso in cui l’acquisizione di un certo numero di apparecchiature per la
informatica distribuita, tutte insieme, portava a sforare la delega di spesa, nessuno vietava di
affettare il tutto in tempi diversi ed il gioco era fatto.
Queste scorciatoie consentono di evitare, ad esempio, l’invio ad un consiglio di amministrazione, di
una richiesta opportunamente corredata dalla documentazione volta a illustrare e giustificare la
spesa; tra l’altro, un consiglio di amministrazione, tramite lo staff tecnico di consulenza, tende,
solitamente, a vedere le cose nel loro insieme per cui potrebbe non trovare giustificata, in un’ottica
aziendale, uno sviluppo a pelle di leopardo.
Le apparecchiature dipartimentali, perciò, comportavano anche una certa decisionalità
dipartimentale, con l’effetto di ritrovare, all’interno della stessa azienda, apparecchiature
dipartimentali non completamente giustificate da un modello di business che le richiedesse, ma
anche apparecchiature del tutto differenti come ambiente operativo e, di conseguenza, come
conoscenze necessarie per la loro gestione. Due uffici vicini potevano, perciò, disporre di
apparecchiature diverse e trovarsi nella impossibilità di poter utilizzare comuni conoscenze per la
soluzione di malfunzionamenti.
Situazioni di questo genere, tra l’altro, non aiutano ad ottimizzare l’uso delle macchine; perciò i due
uffici vicini potevano trovarsi l’uno a soffrire di scarsità di risorse per far fronte ad un carico di
picco eccezionale o ad un aumento del carico di lavoro normale, mentre l’altro navigava
nell’abbondanza non potendo, però, per quanto generoso, alleviare i problemi del primo.
Tutto ciò, in estrema sintesi, vuol dire costi.
Una perversa versione informatica del famoso detto latino “a ciascuno il suo” si concretizzava nella
abitudine che si può riassumere come “a ciascuna applicazione un server”.
La constatazione che l’informatica distribuita non comportasse automaticamente una riduzione dei
costi rispetto all’informatica centralizzata, non si è facilmente palesata; tra l’altro, a parte le
difficoltà oggettiva nella rilevazione dei costi, bisogna considerare che in tanti avrebbero dovuto
ammettere di avere preso un abbaglio, e ciò non è assolutamente un comportamento che si
intraprende con facilità.
Ad ogni modo si è arrivati alla conclusione, piuttosto oggettiva, che la indiscriminata distribuzione
dei sistemi di calcolo rappresenta, quasi sempre, un costo complessivamente maggiore. Si tratta
allora di capire se questo costo maggiore è giustificato dalla realizzazione di un migliore modello di
business che non può farne a meno.
Ad onor del vero, l’informatica distribuita è stata anche spinta da una scarsa efficienza, tra gli anni
80 e 90, del settore delle comunicazioni e dai suoi costi, tuttavia spesso i motori che hanno spinto a
decentralizzare sono stati anche altri.
57

A causa di tutto ciò, ed a causa anche di una congiuntura economico-finanziaria che ha consigliato
un attento esame dei costi, sia in termini di costi per nuove acquisizioni sia in termini di migliore
utilizzo delle risorse già disponibili, verso la metà degli anni 90, si è fatta strada una nuova tendenza
oggi ancora in pieno vigore e comunemente indicata come server consodidation.
La server consolidation non deve essere vista come un semplice “macchina indietro” rispetto alla
informatica distribuita, bensì come una “macchina indietro” rispetto alla informatica distribuita
inutile ed anzi dannosa anche, semplicemente, nel senso di più onerosa.
I principi della server consolidation sono oggi abbastanza accettati anche da molti tra gli analisti di
mercato che avevano trovato solidi argomenti a favore di una indiscriminata distribuzione delle
architetture informatiche.
La server consolidation procede a diversi stadi.
Si parla di centralizzazione quando ci si “limita” a riposizionare le unità di elaborazione in un unico
luogo. Questo, ovviamente, è il passo meno difficile anche se, frequentemente, richiede lo
spostamento, oltre che delle apparecchiature, anche di persone e la definizione di nuove procedure
operative. Si realizza in pratica un ritorno a strutture informatiche logisticamente accentrate e, in
alcuni casi, ciò ha comportato l’ingresso nelle glass house, vale a dire nei centri di calcolo
tradizionali, delle apparecchiature intermedie e del relativo personale per la gestione.
La centralizzazione porta già alcuni vantaggi:
- i centri di calcolo sono luoghi attrezzati per ospitare apparecchiature e la contemporanea
riduzione degli ingombri indotti dai mainframe (vedi tecnologia CMOS e Bipolare) ha
portato a liberare notevoli spazi che così possono essere produttivamente occupati;
- la concentrazione di personale addetto alla gestione di sistemi rende più elastica la gestione
potendo disporre di un numero superiore di unità;
- la gestione informatica, specie per quanto riguarda le procedure di sicurezza quali il back up,
si svolge in maniera complessivamente più affidabile in quanto, checché se ne dica, le prassi
consolidate dei tradizionali centri di calcolo di grandi dimensioni affrontano le tematiche
della sicurezza in modo organico e prestabilito non affidandosi alla episodica buona volontà
dei singoli gestori o addirittura degli utenti finali;
- la presenza in un unico luogo e, presumibilmente, sotto un unico controllo tende ad evitare
l’ulteriore proliferazione delle apparecchiature sia in termini quantitativi sia in termini
qualitativi, cioè in termini di omogeneità degli ambienti operativi;
- etc.
Un secondo passo nel cammino della server consolidation è il consolidamento vero e proprio.
Il consolidamento consiste nel diminuire il numero di apparecchiature di elaborazione
consolidando, appunto, le applicazioni su un numero inferiore di elaboratori.
Questo è senza dubbio più difficile della semplice centralizzazione e può richiedere attività di
revisione delle procedure specie nel caso in cui si tratta di cambiare l’ambiente applicativo di
determinate applicazioni, cioè quando è necessario effettuare un porting applicativo.
I vantaggi del consolidamento possono essere più rilevanti di una pura centralizzazione in quanto,
oltre appunto ai vantaggi della centralizzazione, il consolidamento riesce in genere a migliorare la
percentuale di utilizzo delle varie unità di elaborazione evitando il caso già richiamato e molto
58

frequente di presenza, nella stessa realtà aziendale, di elaboratori “scarichi” e di elaboratori
pericolosamente vicini ad un livello di saturazione.
La server consolidation, come la maggior parte delle scelte con un certo grado di strategicità, deve
essere una decisone aziendale condivisa ai livelli più elevati; ciò per diversi motivi; prima di tutto,
laddove è necessaria una mutazione degli assetti relativi al personale il coinvolgimento della
direzione aziendale è necessario al fine di trovare le giuste misure e le giuste motivazioni per
discutere e portare avanti il riassetto.
Successivamente, è evidente che una delle cause della selvaggia proliferazione delle
apparecchiature dipartimentali va ricercata nel desiderio di autonomia delle varie realtà; se la nuova
organizzazione non è perfettamente condivisa dai vertici aziendali, è probabile che i vari “centri di
potere” dipartimentali riescano a frapporre ostacoli talvolta insuperabili sulla via della server
consolidation.
Infine, la server consolidation deve essere comunque in accordo con un modello di business
aziendale che non deve soffrire a causa di una nuova organizzazione; e ciò non può essere
compiutamente valutato se non dai vertici aziendali appunto.
Quest’ultimo punto è di grande importanza in quanto, come non si raccomanderà mai abbastanza,
ogni scelta non deve essere guidata dalle mode del momento, bensì dall’obiettivo di realizzare gli
ambienti più idonei al soddisfacimento delle necessità degli utenti finali nel rispetto del modello di
business che l’azienda ritiene più idoneo per i suoi affari e per la soddisfazione dei suoi clienti (è
appena il caso di rilevare che questi due aspetti sono in realtà strettamente connessi e il duraturo
conseguimento di uno dei due non può prescindere dall’attenzione all’altro).
La decisione aziendale, quindi, è la base per il successo di ogni scelta strategica e della server
consolidation tra le altre; l’avvio di una server consolidation con una adesione solo formale da parte
dei vertici aziendali non potrà che vedere la meta sempre più lontana ed addirittura perderla di vista
tra mille altre priorità.
Tecnologie BLADE e VIRTUALIZZAZIONE
La tecnologia attuale offre buoni strumenti per supportare una tale scelta.
Tra gli altri si citano :
- le apparecchiature BLADE cioè servers, basati su tecnologia INTEL o altre tecnologie,
montati su singole schede anche multiprocessore le quali, a loro volta, trovano posto
all’interno di un rack che può ospitare decine di queste schede; all’interno del rack sono resi
disponibili a tutti i server alcuni servizi comuni quali alimentazione, raffreddamento,
collegamento con dischi esterni o interni al rack, altri tipi di collegamenti, servizi di
diagnostica e gestione, etc.
- gli strumenti di VIRTUALIZZAZIONE consistenti generalmente in prodotti software che
consentono di vedere un insieme di unità di elaborazione, ad esempio di tipo blade ma non
solo, come una unica risorsa da suddividere, con determinati procedimenti e vincoli, in vari
ambienti operativi; la virtualizzazione, il cui principio è impiegato in diverse altre situazioni,
consente di ottimizzare la gestione dei componenti hardware variamente complessi fornendo
al gestore una interfaccia semplice e dinamica.
59

Con elaboratori di tipo blade è possibile procedere in maniera piuttosto agevole ad una efficace
centralizzazione dei server eliminando quantità talvolta anche rilevanti di server fisici trasferendone
il carico di lavoro all’interno dei servers presenti nella struttura blade; da ciò ne derivano vantaggi
in termini di spazi fisici occupati presso gli impianti informatici, in termini di una più agevole
condivisione di risorse esterne quali dischi o altro, in termini di scalabilità (cioè espandibilità) a
fronte di nuove necessità, etc.
Gli strumenti di virtualizzazione, consentono di affrontare anche il problema del consolidamento
vero e proprio rendendo possibile simulare diversi ambienti operativi sulla medesima struttura
hardware; la virtualizzazione può consentire, inoltre, una sorta di bilanciamento dinamico dei
carichi di lavoro che gravano su ambienti operativi diversi; ciò è reso possibile dal fatto che, in linea
teorica, la potenza di calcolo gestita dal virtualizzatore può essere dinamicamente assegnata dal
virtualizzatore stesso ai diversi ambienti operativi in base alle necessità effettive; questa possibilità
consente, tra l’altro :
- di evitare la necessità di potenziare un certo server, prossimo alla saturazione, operante in un
determinato ambiente mentre vi è disponibilità di potenza di calcolo su altri servers operanti
con differenti ambienti operativi
- di soddisfare la necessità di picchi di potenza elaborativa eventualmente richiesti
temporaneamente da qualcuno degli ambienti operativi
- di bilanciare i carichi di lavoro assegnati ai vari servers disponibili
- di isolare un server che dovesse per qualche motivo andare fuori servizio ridistribuendo il
carico di lavoro complessivo sui rimanenti fino al ripristino dell’unità
In ambienti del genere, una richiesta proveniente dall’esterno è gestita dal virtualizzatore il quale la
indirizza dove meglio ritiene, in base naturalmente alle varie opzioni che sono state stabilite in fase
di configurazione, al fine di soddisfare determinati criteri fissati da chi gestisce l’ambiente; l’autore
della richiesta non sa da chi la sua richiesta sarà elaborata; è appena il caso di osservare che
architetture del genere si prestano bene ad implementare le metodologie di calcolo del GRID
computing di cui si è già fornita una breve descrizione.
Alla luce di tutto ciò, nel progetto di un impianto informatico, che spesso significa il progetto di una
nuova procedura con la definizione, tra l’altro, degli strumenti hardware necessari e delle
competenze necessarie per la gestione, si ritiene che debbano essere tenute in evidenze le
motivazioni che hanno condotto alla diffusione dei principi della server consolidation.
Classificazioni delle unità di elaborazione
Per concludere questa sezione relativa alle unità di elaborazione si ritiene utile fornire qualche
ulteriore indicazione sulle apparecchiature di questa area al fine di consentire la familiarizzazione
con terminologie utilizzate comunemente nel settore.
Una classificazione spesso impiegata nell’area delle unità di elaborazione le suddivide, a grandi
linee, in base alla capacità di lavoro (in termini ad esempio di numero di transazioni evase per unità
di tempo, di numero di utenti interattivi gestibili, etc.) in
- server di tipo mainframe
- server di tipo minicomputer
- server di tipo personal computer
Una classificazione analoga che fa però riferimento ai settori di mercato è
60

- server enterprise (per grandi aziende)
- server per piccole e medie realtà (piccole e medie aziende o dipartimenti di grandi aziende)
Un modo ulteriore di ritrovare gli stessi concetti vede una classificazione effettuata in base agli
ambienti operativi; si parla allora di
- server 390 (per riferirsi ai server mainframe operanti nella architettura IBM 390, evoluzione
della architettura 360 e 370)
- server LINUX
- server UNIX
- server WINDOWS
- etc.
I vari modi di indicare le cose sottendono comunque la stessa sostanza.
Molto spesso si impiega il termine “architettura” per indicare un quadro di riferimento muovendosi
all’interno del quale ci si dovrebbe trovare meglio che movendosi senza dei precisi punti di
riferimento e reinventando frequentemente ogni cosa senza porsi obiettivi di continuità e di
compatibilità o, appunto, di architettura.
Una specie di codice di autoregolamentazione che serva da guida per chi progetta i prodotti e dia
una certa sicurezza a chi i prodotti li compra e su di essi costruisce il proprio sistema informativo.
In questo senso, vi sono state, spesso alla luce del senno del poi, delle buone architetture e delle
altre meno buone o addirittura cattive.
Una buona architettura
- deve sopravvivere alle innovazioni tecnologiche consentendo, più o meno efficacemente,
l’impiego di nuovi prodotti
- deve proteggere e valorizzare gli investimenti di chi le impiega in termini di conoscenze
delle persone, di realizzazioni (specie software), di apparecchiature, etc.
- si evolve per restare al passo con le nuove organizzazioni del lavoro e con le nuove
tecnologie con il minor numero possibile di discontinuità con il passato
- etc.
Il soddisfacimento di tutto ciò fa sì che una buona architettura abbia una vita abbastanza lunga e
non sia una meteora che sfreccia lasciando ingombranti detriti qua e la.
Uno dei casi più significativi è la architettura delle unità di elaborazione IBM 360, nata agli inizi
degli anni 60 e arrivata fino ad oggi nella sua “versione” 390, che ha consentito una elevata
protezione degli investimenti inducendo addirittura, a causa però di una gestione poco dinamica da
parte degli utilizzatori, una serie di problemi connessi all’impiego ed alla manutenzione di prodotti
software datati; di ciò si parlerà in maggiore dettaglio nel capitolo relativo al software.
Il termine mainframe è praticamente sinonimo di “unità di elaborazione in architettura IBM 390”.
61

UNITA’ di ELABORAZIONE – Domande di verifica
1 quale è il semiconduttore più impiegato nella uranio
costruzione dei chip
silicio
rame
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
2 la tecnologia bipolare rispetto alla CMOS produce più calore
produce meno calore
produce lo stesso calore
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
3 la tecnologia bipolare rispetto alla CMOS è stata meno "performante"
per lungo tempo
ugualmente "performante"
più "performante"
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
4 la legge di MOORE non è più valida
sarà valida per sempre
è attualmente valida
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
5 una CPU può eseguire direttamente solo istruzioni macchina
istruzioni fortran
istruzioni java
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
62

6 diverse istruzioni macchina richiedono, in uguale
generale, un numero di cicli per la loro
esecuzione diverso
pari a 10
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
7 un programma gira su una CPU con clock rate 125 s
di 200 MHz ed esegue 10 milioni di istruzioni
con CPI medio di 2,5; quale è il tempo di 25 ms
esecuzione
125 ms
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
8 il tempo di elaborazione di un programma è 1,50 X
influenzato per il 60 % da una determinata
istruzione sulla quale si può agire;di quanto deve 1,70
essere migliorata se si desidera ottenere uno
speed up di 1,25? 1,90
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
9 in base alla legge di amdhal raddoppiando la 1,25
performance di una componente del tempo di
esecuzione che impatta per il 50 % del tempo 1,33
totale quale è lo speed-up che si ottiene ?
1,50
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
10 agendo solo su una determinata componente sempre
del tempo di esecuzione è possibile ottenere
qualsivoglia speed-up se si è molto bravi
non sempre
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
63

11 noto un certo carico applicativo, quale sarebbe basarsi sui MIPS
il metodo migliore per scegliere la più adeguata comunicati dai fornitori
tra diverse CPU
far girare il carico sulle
varie CPU
basarsi sui MFlops
comunicati dai fornitori
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
12 cosa si intende per server consolidation diminuire luoghi con server
diminuire numero di server
entrambi
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
13 cosa si intende per centralizzazione dei server diminuire luoghi con server
diminuire numero di server
entrambi
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
14 le apparecchiature definite comunemente le necessità in termini di
BLADE consentono di affrontare i piani di spazi occupati (mq)
centralizzazione dei servers ottimizzando, tra
l'altro il riempimento delle
cartucce magnetiche
il seek time
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
64

15 nella scelta della piattaforma dove inserire prevedere un nuovo server
inserire una nuova applicazione è opportuno
seguire, se possibile,
un criterio di omogeneità
con quanto già installato
profittare per fare nuove
esperienze su ambienti del
tutto nuovi
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
65

2.2.2 Unità di memorizzazione di massa
Le unità di memorizzazione di massa di cui parleremo sono le unità a dischi magnetici, le unità a
nastro magnetico e le unità basate su dischi ottici.
Chi ha avuto a che fare con un impianto informatico sa bene che il progetto e la gestione delle
memorie di massa sono argomenti di grande importanza la cui sottovalutazione rischia di indurre
costi tutto sommato ingiustificati.
Il grafico che segue mette qualitativamente in relazione le tre famiglie di unità di memorizzazione
di massa con riferimento alla prestazione ottenibile (in termini di tempo necessario ad ottenere una
informazione dalle varie tipologie di sistemi) ed alla capacità di memorizzazione.
Prestazioni
DISCHI
MAGNETICI
DISCHI
OTTICI
NASTRI
MAGNETICI
Capacità
66

Volendo riportare sullo stesso schema, come abbiamo già fatto prima, anche gli altri tipi di memorie
che troviamo in un sistema di calcolo otteniamo, più o meno, qualcosa del genere.
Prestazioni
REGISTRI
CACHE
MEMORIA
CENTRALE
DISCHI
MAGNETICI
DISCHI
OTTICI
Capacità
NASTRI
MAGNETICI
Le unità di memorizzazione di massa, all’interno degli impianti informatici, rivestono un ruolo
fondamentale nel quadro complessivo.
Ciò è ancora più vero oggi visto che, negli ultimi anni, a causa delle nuove modalità di elaborazione
e dei nuovi servizi richiesti alle strutture IT, si è verificata una vera e propria esplosione nella
quantità di dati che devono essere memorizzati.
Con l’aumento delle necessità di memorizzazione è aumentato anche, in misura ancora più
rilevante, il carico di lavoro necessario alla gestione dei dati ed il relativo costo di gestione.
67

In sintesi, gestire i dati vuol dire:
- fare in modo che le varie informazioni siano accessibili con i necessari livelli di prestazione
richiesti dall’utilizzo specifico;
- trattare ed allocare in modo differente i dati in base ad una sorta di gerarchia delle memorie
di massa che, in pratica, assegni ad ogni dato il supporto più adeguato e ne gestisca il
cammino all’interno della gerarchia, dalla sua nascita fino al momento in cui il dato stesso
non sarà più ritenuto valido, con strumenti quanto più possibile automatizzati;
- garantire la sicurezza dei dati
Già da qualche tempo, le componenti puramente hardware dei sistemi di memorizzazione non
rappresentano che una parte minoritaria dell’intero Total Cost of Ownership indotto dal trattamento
dei dati; la figura sottostante sintetizza a grandi linee questa situazione rapportando, in anni diversi
ed in percentuale sul totale del TCO per il trattamento dei dati, il costo dei sistemi hardware e gli
altri costi indotti dalla soluzione.
Costo
hardware
Altri
costi
Costo
hardware
1980 2000
Tale andamento, che sembra destinato a proseguire, ha indotto dei cambiamenti nei requisiti
progettuali delle architetture per la gestione dei dati; i costi indotti dalla gestione, infatti, connessi
alla disponibilità di strumenti di controllo efficaci, vanno visti come prioritari rispetto al puro costo
hardware che, peraltro, si riduce, in percentuale, continuamente grazie ai rilevanti progressi
tecnologici.
La variazione dell’incidenza dei costi delle componenti hardware sul TCO di una soluzione per la
gestione dei dati ha fatto si che, negli ultimi anni, le componenti hardware non rappresentino più
l’elemento di differenziazione tra diverse soluzioni e siano diventate, invece, delle cosiddette
commodities, termine, difficilmente traducibile, che sta ad indicare un bene reperibile facilmente da
diverse fonti e con caratteristiche più o meno equivalenti.
Altri
costi
68

D’altra parte, come insegna la legge di Amdahl, l’obiettivo di migliorare un certo valore è più
efficacemente perseguibile concentrandosi, se possibile, sul fattore che maggiormente contribuisce
a determinare il valore che si vuole ottimizzare; in altri termini, non è corretto scegliere, ad
esempio, l’unità a disco in cui costo hardware è più basso di altre se poi l’inserimento della
apparecchiatura nella realtà specifica comporta dei costi spropositati in termini di inserimento vero
e proprio ed in termini di gestione.
Questo concetto, di per se elementare, non sempre si trasforma in scelte razionali e congruenti; ciò
in quanto i costi diversi dal puro costo di acquisto sono più complessi da valutare e perciò tendono a
sfuggire nella rilevazione del TCO complessivo delle differenti soluzioni.
69

2.2.2.1 I dischi
Le unità a disco magnetico, nella scala prima riportata delle prestazioni dei vari tipi di memorie,
occupano il gradino subito sotto le memorie centrali e sono oggi le unità di memorizzazione di
massa la cui prestazione può impattare più o meno direttamente la prestazione visibile dall’utente
finale.
Le unità a nastro, invece, per quanto fondamentali nella architettura di un impianto informatico,
sono quasi del tutto dedicate ad attività di servizio e rivestono un ruolo fondamentale nelle
procedure di sicurezza, tra le quali il back-up dei dati. In questa ottica le unità a nastro possono
anch’esse avere impatti sull’utente finale in quanto proteggono l’utente finale stesso da eventuali
disservizi o, come è bene che cominciamo a chiamarli, da eventuali disastri.
Le unità a disco, per quanto evolute, sono apparecchiature la cui velocità di funzionamento è di
qualche ordine di grandezza inferiore a quella delle unità di elaborazione; per convincersi di ciò,
basta pensare al fatto che in esse la meccanica gioca un ruolo importante quanto l’elettronica.
La necessità di dialogo tra unità di elaborazione ed unità di memorizzazione a disco, rappresenta
perciò un altro di quei casi in cui due famiglie di apparecchiature altrettanto necessarie ma con
caratteristiche prestazionali molto diverse entrano in contatto; si intuisce, quindi, perché la
connessione tra unità di elaborazione e dischi è stata una di quelle maggiormente soggetta a quelle
tecniche che abbiamo definito di disaccoppiamento.
Ciò ha fatto si che dalla definizione di unità a disco (Hard Disk Drive o HDD) si sia passati a quella
di sistemi di storage, includendo in questo nuovo concetto di “sistema” tutti gli accorgimenti
necessari, hardware e software, ad adattare i due mondi.
Evoluzione tecnologica
Una unità a disco è composta da un certo numero di dischi, appunto, sulle cui facce, grazie alla
presenza di un sottile strato di materiale ferromagnetico, può avvenire la memorizzazione di bit
tramite la creazione di minuscoli campi magnetici orientati in uno di due modi possibili al fine di
rappresentarne lo stato logico.
Tale orientamento permane anche in assenza di alimentazione elettrica e ciò costituisce la
cosiddetta non volatilità dello strumento.
Il diametro dei dischi, chiamato spesso anche form factor, è diminuito nel tempo (da circa 60 cm
fino agli attuali 5-6 cm) al fine di migliorare le performance.
Il gruppetto di dischi ruota solidale grazie ad un albero che li sostiene; i dati sono memorizzati in
circonferenze concentriche, chiamate tracce, le quali, a loro volta, sono suddivise in settori; il
settore è, generalmente, il più piccolo insieme di bit che può essere letto con una unica operazione;
l’eventuale reperimento, all’interno del settore, dell’informazione desiderata avviene altrove.
Considerando l’insieme dei piatti, le tracce che si trovano alla stessa distanza dal centro
costituiscono il cosiddetto cilindro; il concetto di cilindro richiama la figura ideale composta da
tracce equivalenti su diversi dischi dello stesso HDD.
La lettura e la scrittura avvengono grazie alle testine di lettura/scrittura che si trovano all’estremità
di un braccio; le testine sono, naturalmente, in numero tale da assicurare il raggiungimento delle
70

due facce di ogni piatto; conseguentemente vi sono anche un certo numero di braccetti che
costituiscono una struttura a pettine mossa da un attuatore che con il suo movimento consente di
raggiungere le parti utili dei dischi.
Dalla breve descrizione fornita, si cominciano ad individuare alcuni dei fattori che determinano la
prestazione dei dischi magnetici. Per prima cosa, è evidente che la lettura di una informazione posta
in una determinata posizione sulla superficie del disco richiede il posizionamento della testina sul
punto desiderato. Questa attività si divide in due parti; la prima, consistente nel posizionare la
testina sulla traccia desiderata, avviene in un tempo che viene chiamato SEEK TIME; la seconda,
consistente nel portare il settore desiderato sotto la testina, avviene in un tempo definito TEMPO DI
LATENZA.
Una volta completata la fase di posizionamento può cominciare, sfruttando la rotazione dei dischi,
la fase di lettura/scrittura vera e propria. A questo punto si evidenzia un terzo fattore rilevante ai fini
della performance, la densità di registrazione (o AREAL DENSITY) cioè, in definitiva, quanti bit
sono contenuti per unità di superficie. La areal density è misurata in (miliardi di) bit per inch al
quadrato o (G)b/in 2 .
La densità di registrazione si misura moltiplicando il numero di bit sulla traccia per unità di
lunghezza (chiamato Bit per Inch o BPI) per il numero di tracce contenute per unità di lunghezza in
senso radiale (chiamato Tracce per Inch o TPI).
Pertanto l’Areal Density è il prodotto BPI x TPI e si misura in bit/inch 2 .
A parità di velocità di rotazione del disco (RPM o rotazioni per minuto), la quantità di dati che si
riesce a leggere/scrivere nell’unità di tempo (DATA RATE) aumenta con l’aumento di BPI.
Analogamente, a parità di BPI, il DATA RATE può essere migliorato aumentando la velocità di
rotazione del disco; ciò evidenzia uno dei motivi che hanno portato alla generale adozione di dischi
di diametro sempre più piccolo, per i quali la velocità di rotazione può essere più elevata rispetto ai
dischi con diametro maggiore (ciò a causa del fatto che quanto più è grande il diametro del disco
tanto più impegnativi sono i problemi di tipo meccanico che devono essere risolti al crescere di
RPM).
I primi dischi magnetici sono stati introdotti verso la metà degli anni 50, da allora la areal density,
che rappresenta uno degli elementi chiave nel progresso tecnologico degli HDD, è aumentata di
circa sette ordini di grandezza ed oggi è intorno a 100 Gb/in 2 .
Come è successo per quanto concerne la densità di integrazione della tecnologia del silicio, anche
nel caso della memorizzazione magnetica sono state fatte, nel tempo, delle previsioni circa i limiti
che si pensava fossero invalicabili per diverse motivazioni; anche in questo caso, fino ad oggi,
questi limiti sono stati superati e, per il futuro, ne vengono posti altri; tuttavia, questi ultimi
sembrano più stringenti in quanto legati a limiti dettati dalla fisica dei materiali alle dimensioni in
cui si opera.
Gran parte della evoluzione tecnologica degli HDD è avvenuta grazie ad una, apparentemente
semplice, diminuzione delle dimensioni in gioco. Questo concetto, in prima approssimazione, porta
a dire che per ottenere un raddoppio del BPI e del TPI, ottenendo un miglioramento di un fattore 4
per l’areal density, potrebbe essere sufficiente dimezzare tutte le dimensioni dei componenti in
gioco.
71

L’immagine riportata, tratta da una pubblicazione IBM [4], sintetizza questo procedimento.
Questa tecnica però, per quanto sia stata in effetti largamente usata, è solo apparentemente semplice
in quanto il presentarsi di una serie di effetti richiede interventi sofisticati per mantenere una
corretta operatività dell’insieme.
Con la diminuzione delle dimensioni il segnale letto per via induttiva diminuisce mentre aumenta il
rumore
con l’aumento dal data rate; perciò, in caso di impiego di testine di tipo induttivo, il
rapporto segnale/rumore diminuisce notevolmente; l’impiego di speciali tecnologie (tecnologia
magnetoresistiva e super-magnetoresistive ) per la realizzazione delle testine, pur complicando i
progetti inerenti alla riduzione delle dimensioni, ha consentito di mitigare il problema.
La costruzione di testine del tipo a film sottile (thin film) è influenzata dai progressi delle tecniche
litografiche ed è condizionata da altre problematiche che inducono a non applicare esattamente le
regole di riduzione delle dimensioni (scaling), bensì ad applicare differenti riduzioni in differenti
dimensioni;
ciò induce problemi in termini di calore prodotto.
La diminuzione delle dimensioni porta anche ad una diminuzione della distanza tra testina e
superficie del disco che è ormai arrivata a qualche nanometro; ciò richiede di risolvere alcuni
problemi di tipo aerodinamico.
La
complicazione più grave che però sorge man mano che le dimensioni diminuiscono è legata al
comportamento magnetico dei materiali; questo comportamento, infatti, cambia al raggiungimento
di dimensioni meno che microscopiche a causa dell’effetto superparamagnetico.
L’effetto
superparamagnetico consiste
nella casuale variazione dello stato di magnetizzazione di
una particella magnetica; l’ effetto è fortemente influenzato dalla dimensione della particella; a
determinate dimensioni, dimezzare il diametro della particella può portare da un cambio casuale
ogni 100 anni ad un cambio casuale ogni 100 nano secondi. In sostanza può trasformare una
particella
che si può definire stabile
in una particella che non lo è affatto.
Poiché nel processo di scaling ideale la dimensione della particella dovrebbe diminuire assieme a
tutte le dimensioni degli altri componenti ecco che l’insorgere dell’effetto superparamagnetico
pone un serio limite.
72

Tutti gli sforzi che oggi vengono fatti, al fine di continuare ad utilizzare tecniche di memorizzazione
di
tipo magnetico, tendono a trovare nuovi metodi per spostare più in avanti possibile il presentarsi
dell’effetto
superparamagnetico.
Tra le soluzioni che si prospettano a questo problema la registrazione perpendicolare
(perpendicular recording) sembra avere buone possibilità di successo visto che, tra l’altro, vi sono
stati già degli annunci, da parte di qualche società costruttrice, di prodotti che si basano su questa
tecnica.
L’immagine riportata, tratta da una pubblicazione IBM [4], riporta, a sinistra, lo schema di
registrazione orizzontale e, a destra, due possibili varianti di registrazione perpendicolare.
In breve, la tecnica di registrazione attualmente più usata prevede di creare una magnetizzazione
orizzontale, cioè parallela alla superficie del disco; la registrazione perpendicolare, invece, prevede
un orientamento della magnetizzazione in senso perpendicolare alla superficie del disco.
La memorizzazione perpendicolare consente
di disporre di celle più grandi per la memorizzazione
del
bit; ciò, come abbiamo detto, consente di allontanare il disastroso insorgere dell’effetto
73

superparamagnetico. Gli esperti ipotizzano un fattore di 2 o 4 nel miglioramento della areal density
con l’impiego della memorizzazione perpendicolare.
Nei laboratori, ovviamente, si sta pensando anche a qualcosa di radicalmente diverso per la
memorizzazione, a qualcosa, cioè, che non si basi più sulle proprietà magnetiche dei materiali; a
questo proposito la pubblicazione indicata [5] fornisce una descrizione dei principi alla base della
tecnica di memorizzazione olografica.
La corsa all’aumento della areal density è valida finché, come è avvenuto fino ad oggi, le nuove
tecniche
comportano, in definitiva, una riduzione del costo complessivo per bit memorizzato; il
costo dell’ HDD, tuttavia, non è, per gli utenti, il costo principale per la memorizzazione dei dati;
altri costi, connessi alla prestazione complessiva dei sistemi di storage, alla ottimizzazione
dell’utilizzo dei sistemi ed
alla loro gestione, rappresentano una fetta via via crescente del costo
complessivo.
Da ciò deriva il fatto che la tecnologia è certamente importante, ma altro deve essere
contemporaneamente tenuto in conto.
Evoluzione architetturale
Il primo disco magnetico fu introdotto da IBM nel 1956 con il nome RAMAC (da non confondere
con la famiglia di dischi molto più moderna lanciata sempre da IBM intorno agli anni 90 sempre
con il nome RAMAC).
I primi dispositivi di storage su disco magnetico erano direttamente controllati dalle unità di
elaborazione, con tutti i problemi derivanti dall’interfacciamento diretto tra due dispositivi con
velocità intrinseche nettamente differenti.
Un
primo passo di grande importanza è stato, intorno agli anni 60, l’introduzione di apparecchiature
dedicate alla gestione dello storage e posizionate tra le unità di elaborazione e i dispositivi fisici di
memorizzazione (gli HDD). Tali apparecchiature sono le unità di controllo dei dischi.
Il vantaggio fondamentale ottenibile con l’introduzione delle unità di controllo
consiste nel
disaccoppiamento
tra CPU e dischi; un certo comando per una operazione di I/O proveniente dalla
CPU viene recepito dalla unità di controllo che provvede ad avviare, indipendentemente dalla CPU
ed in modo asincrono, le opportune azioni nei riguardi dell’ HDD.
Le unità di controllo dei dischi sono CPU dedicate alla gestione dello storage; come ogni CPU
necessitano di un programma per operare, ma il progetto e la realizzazione di questo programma
non è a carico dell’utente, bensì a carico
di specialisti trattandosi, in definitiva, di un sistema
operativo
ottimizzato per lo specifico compito di gestione della memoria su disco.
Questi speciali computer sono stati progettati con un numero di CPU maggiore di uno sia per
migliorare le performance sia per assicurare una maggiore affidabilità nei riguardi di eventuali
disservizi sia pianificati, come ad esempio attività di aggiornamento software, sia non pianificate,
cioè i guasti veri e propri; le unità di controllo dispongono anche di memorie elettroniche impiegate
sempre con l’obiettivo di migliorare i tempi di accesso alle informazioni ed il tempo necessario per
la memorizzazione delle
informazioni.
Il miglioramento dei tempi di lettura dai dischi è ottenuto sfruttando il medesimo principio di cui
abbiamo già parlato relativamente allo scambio di informazioni tra CPU e memoria centrale, cioè il
principio del caching delle informazioni. Le memorie cache fanno, ormai, parte integrante di
qualsiasi controller di dischi dal personal computer all’ambiente mainframe; poco importa,
74

qualitativamente, che l’unità di controllo in un ambiente mainframe si concretizzi spesso in una
macchina a sé stante mentre in realtà più piccole la funzione di controller è integrata insieme al
disco
vero e proprio.
Anche il miglioramento dei tempi di scrittura è ottenuto interponendo delle memorie veloci tra
l’elaboratore e, per intenderci, l’ HDD; proprio come avviene spesso con le unità di elaborazione
che depositano le informazioni su memorie cache che, a loro volta, passano i dati alla memoria
centrale nel momento ritenuto più opportuno (tipicamente quando è necessario liberare spazi in
cache per altri utilizzi).
Nel caso della scrittura su disco magnetico, però, le cose sono più delicate in quanto, per
definizione, un dato contenuto su un disco non deve subire danni in caso, ad esempio, della
mancanza di alimentazione, cosa che non è vera nel caso di memorie elettroniche come le cache; in
altri termini, un sistema operativo che dispone una scrittura su disco assume che quando viene
segnalato il completamento della operazione il dato sia al sicuro su un supporto di memorizzazione
permanente e su questa base procede con le altre attività.
Il problema è superato con l’impiego, all’interno delle unità di controllo dei dischi, di memorie
elettroniche non volatili (Non Volatile Storage o NVS); un
dato diretto su un disco, pertanto, viene
posto
in una memoria NVS gestita dalla unità di controllo dei dischi (il dato viene posto in genere
anche in cache per un eventuale riuso veloce); non appena il dato è registrato nella NVS l’unità di
controllo segnala al sistema operativo dell’unità di elaborazione il completamento della operazione
di scrittura sul disco; il trasferimento fisico sul disco avviene in modo asincrono quando il software
della unità di controllo decide che è il momento di farlo.
Questa modalità operativa è spesso chiamata Fast Write.
La successiva novità di grande rilievo nel campo della memorizzazione su dischi magnetici è
avvenuta agli inizi degli anni 90 con l’impiego di un numero maggiore di HDD con form factor
ridotto al posto di HDD singoli con form factor maggiore e con stringenti requisiti di qualità; questo
passaggio è stato reso possibile dalla evoluzione delle tecniche RAID oggi universalmente
impiegate
in ogni categoria di apparecchiature per la memorizzazione magnetica su dischi e dalla
disponibilità di dischi con diametro sempre più piccolo rispetto ai 24 pollici degli anni 50.
Le tecniche RAID (Redundant Array of Independent (o Inexpensive) Disk) forniscono precise
metodologie per consentire
l’impiego di un certo numero di dischi fisici per simulare un o più dischi
logici;
i principali vantaggi dell’impiego di unità RAID sono le migliori prestazioni ottenibili e la
affidabilità
complessiva derivante dai diversi sistemi di ridondanza previsti nella architetture RAID.
A questo punto, si comprende bene perché è il caso di parlare di sistemi di storage anziché
semplicemente
di dischi o HDD; il realtà le unità di storage sono dei sistemi veri e propri che si
interfacciano
con il resto delle apparecchiature informatiche tramite sofisticate funzioni hardware e
software
dedicate.
75

. . . . . . . . . . . . . . . . . . . . . .
Gestione connessioni verso l’elaboratore Gestione connessioni verso l’elaboratore
CACHE NVS
Gestione dei dischi Gestione dei dischi
LATO “A”
CACHE NVS
LATO “B”
La figura precedente mostra lo schema logico semplificato di un sistema di storage a dischi
magnetici con organizzazione RAID.
Si possono individuare i due “computer” (Lato “A” e Lato “B”), dotati di cache e memoria NVS,
che
gestiscono i dischi fisici veri e propri e la connessione con la unità di elaborazione.
La diffusione degli strumenti informatici già
esaminata prima, ha portato ad una equivalente
diffusione
delle apparecchiature per lo storage; la modalità più naturale per la connessione di una
unità di storage ad una unità di elaborazione vede lo storage connesso direttamente ad una, e solo ad
una, unità di elaborazione; la cosiddetta modalità DAS (Direct Attached Storage), schematizzata
nella figura sottostante
In un ambiente del genere, il sistema operativo della unità di elaborazione gestisce le unità di
storage per il tramite delle unità di controllo.
Il sistema operativo, con la sua componente definita File System, organizza la memorizzazione delle
informazioni
nel modo che gli è congeniale, normalmente del tutto diverso dal modo impiegato da
un
diverso File System di un differente sistema operativo.
La
proliferazione delle unità di elaborazione eterogenee con dischi connessi in modalità DAS ha
fatto
sorgere alcune inefficienze; tra le più evidenti, non è raro trovare in organizzazioni del genere
un
utilizzo assolutamente ridotto delle unità di storage.
76

Applicazione
Sistema operativo
File System
Unità di controllo
Si pensi ad organizzazioni con decine di servers Unix e Windows sparsi geograficamente e talvolta,
invece, localizzati nello stesso edificio o nello stesso ufficio; ogni server, con il proprio file system,
dedicato ad una specifica attività come server di posta, server per la gestione di transazioni, file
server, etc; in ambienti del genere è piuttosto comune constatare un utilizzo della maggior parte
delle
unità di storage anche solo del 10 o 20 %, mentre, contemporaneamente, qualcuno dei server
dispone di unità di storage prossime al livello di saturazione.
Secondo indagini svolte da società di consulenza nel settore informatico, casi del genere sono tanto
comuni in ambienti di elaborazione fortemente distribuiti quanto piuttosto rari negli ambienti
centralizzati basati su mainframe dove le percentuali di utilizzo si aggirano costantemente
intorno
all’
80% e anche oltre.
Nei casi in cui le percentuali di utilizzo delle risorse di storage sono molto disomogenee, è molto
frequente che si debba intervenire con nuovi investimenti per il potenziamento di apparecchiature
vicine alla saturazione pur disponendo, in altre parti del proprio sistema informatico, di risorse
scarsamente utilizzate. Queste, naturalmente, non
sono situazioni ottimali dal punto di vista
dell’impegno
economico e finanziario richiesto per il mantenimento dell’impianto.
La eccessiva e non giustificata distribuzione dello storage, oltre ai problemi connessi all’utilizzo
delle apparecchiature, pone inquietanti interrogativi sul livello di protezione e sicurezza delle
informazioni residenti in luoghi non opportunamente presidiati da personale adeguatamente
77

preparato o, addirittura, affidati alla custodia dell’utente finale che può non avere le necessarie
conoscenze per una corretta attività di gestione.
Tra l’altro, anche nel caso in cui non vi fossero altri impedimenti nella gestione della protezione dei
dati, una organizzazione che vede lo storage distribuito deve in qualche modo prevedere anche la
distribuzione degli strumenti informatici necessari allo scopo, principalmente apparecchiature di
back-up e relativi prodotti software per la gestione
del back-up stesso e dell’eventuali ripristino.
Un salto di qualità nella attenzione alle problematiche connesse alla sicurezza dei dati ed al loro
ripristino secondo tempi congruenti con le aspettative aziendali è stato indotto dagli eventi dell’11
settembre 2001 e da una serie di black
out, di diversa ampiezza, che si sono verificati; d’altra parte,
una
certa situazione economica congiunturale non positiva ha fatto aumentare l’attenzione
all’efficiente utilizzo delle risorse disponibili ed al conseguente ritorno degli investimenti effettuati.
La storage
consolidation, NAS e SAN
Queste ed altre motivazioni hanno portato i manager informatici ad avviare, analogamente a quanto
avviene nel campo delle unità di elaborazione, una attività di razionalizzazione che va sotto il nome
di STORAGE CONSOLIDATION.
Così come per le unità di elaborazione, nasce la tendenza a diminuire ove possibile la dispersione
delle unità di storage con l’impiego di differenti modalità di connessione delle unità di storage
stesse.
La prima modalità, definita NAS
(Network Attached Storage), è l’evoluzione del file server
impiegato
fin dalla diffusione delle LAN; inizialmente, il file server era un personal computer con
opportune caratteristiche di affidabilità, che metteva
a disposizione le proprie risorse disco ai
componenti
di una LAN; il NAS è una apparecchiatura connessa ad una LAN ed è specializzata
nella gestione dello storage; attività che conduce con un proprio file system ed un proprio sistema
operativo talvolta ottimizzato esclusivamente per la gestione dello storage.
Un
NAS, come un file server, fornisce files ed è in grado di interfacciarsi con un certo numero di
file system presenti nella LAN.
La figura seguente sintetizza questa situazione.
Nella figura due servers applicativi, tramite il client di un file system ottengono i servizi di file
server
dal NAS che contiene il server del file system e le unità a disco vere e proprie con le relative
componenti
di controllo.
Come
detto una unità NAS si affaccia su una LAN e perciò il traffico dati grava interamente sulla
LAN
insieme al resto del traffico e ciò può costituire un limite all’impiego di questo tipo di
organizzazione;
inoltre, per quanto alcune apparecchiature NAS siano in grado di gestire in
autonomia
delle unità di back-up, spesso le attività volte ad assicurare la protezione dei dati
finiscono,
anch’esse, per gravare sulla LAN.
78

LAN
Applicazione
Sistema operativo
File System client
File System server
Unità di controllo
Applicazione
Sistema operativo
File System client
Le attività di server consolidation, come abbiamo
visto in precedenza, vedono nella centralizzazione
un
primo e più abbordabile passo sulla strada del consolidamento vero e proprio; ciò ha portato alla
presenza, talvolta nella vecchia glass house, di una serie di servers, per lo più eterogenei, ognuno
con il proprio sistema di storage dedicato al seguito.
Si è fatta strada, così, la richiesta di poter connettere diverse unità di storage, per lo più eterogenee,
a diverse unità di elaborazione, per lo più eterogenee. Ciò avrebbe consentito, ad esempio, di
ritagliare all’interno di una unità di storage scarica degli spazi da assegnare ad un server con unità
di storage dedicata prossima alla saturazione.
Per soddisfare questa necessità, si è diffusa una ulteriore modalità di connessione tra unità di
elaborazione ed unità di storage definita SAN (Storage Area Network). La SAN, come traspare
chiaramente dal significato dell’acronimo, è una struttura di rete dedicata
al traffico indotto dallo
storage.
Deve essere chiaro, però, che in una struttura SAN dove, teoricamente, tutti i servers sono connessi
a tutte le unità di storage, ogni server deve comunque gestirsi con i suoi strumenti, tipici delle
connessioni
dirette, la sua porzione di storage, ovunque questa si trovi; le strutture SAN, perciò, di
per sé, non evitano la duplicazione delle informazioni, che può essere entro certi limiti superata con
le apparecchiature NAS, dovuta alle necessità dei vari sistemi operativi, presenti sulle varie
piattaforme servers, di vedere i dati secondo il proprio file system.
79

Uno degli obiettivi principali delle SAN è quello di consentire il collegamento di qualsiasi tipo di
server
a qualsiasi tipo di unità di storage; ciò presuppone la condivisione da parte di quanti più
fornitori possibile di un comune standard di connessione.
Questa
materia si arricchisce continuamente di nuove proposte, tuttavia, molte realizzazioni SAN
impiegano
una architettura di connessione Fibre Channel (Appendice F - Fibre Channel) che è uno
standard
ANSI; le connessioni di tipo FC consentono velocità molto elevate (oltre 1-2 Gb/sec) e,
con
l’utilizzo delle fibre ottiche, consente distanze di connessione dell’ordine dei Km.
Lo
schema logico di una SAN è riportato nella figura sottostante dove due server applicativi
accedono
alla SAN alla quale è connesso anche un sistema di storage.
Applicazione
Sistema operativo
File System
S A N
Unità di controllo
Applicazione
Sistema operativo
File System
La realizzazione di una SAN porta alcuni vantaggi; il più evidente è costituito dal fatto che il
traffico indotto dallo storage è ora isolato su una rete dedicata ad esso che non interferisce con la
LAN (non riportata nella figura in quanto non interessata dalla implementazione della SAN) la
quale, per canto suo, è così dedicata al resto del traffico client/server e può essere dimensionata
sulla base di tale traffico.
80

Un ulteriore, importante, vantaggio è rappresentato dalla possibilità di connettere agevolmente alla
SAN anche unità di storage basate su nastri; queste unità in SAN sono visibili a tutti i servers ed il
loro dimensionamento può perciò essere ottimizzato sulla base delle complessive necessità di backup
di tutti i servers. Quest’ultimo punto è particolarmente vantaggioso alla luce del fatto che il
traffico dei dati si appoggia su una rete dedicata; in questo modo, i back-up possono anche essere
effettuati
senza necessità di tenere in conto l’impatto, normalmente rilevante, sulla LAN.
Le realizzazione NAS e SAN non sono mutuamente esclusive e, anzi, spesso coesistono per
rispondere a determinate necessità; in linea del tutto generale, però, si può dire che, a causa anche
dell’impegno economico solitamente più rilevante indotto dalla realizzazione di una SAN, i NAS
sono
più diffusi in ambienti medio-piccoli mentre le SAN sono prevalentemente presenti in
ambienti
medio-grandi.
La
figura in basso riporta uno schema logico in cui un server applicativo richiede servizi di file
server
ad una apparecchiatura NAS la quale, anziché disporre di proprie unità a disco, accede ad
unità
di storage esterne collegate ad una SAN alla quale si collega anche un diverso server
applicativo.
Applicazione
Sistema operativo
File System
S A N
Unità di controllo
Applicazione
Sistema operativo
File System client
LAN
File System server
Per NAS Gateway si intende una apparecchiatura NAS che non dispone di unità a disco di proprio
esclusivo utilizzo bensì accede ad unità a disco disposte in SAN.
81

Ad ogni modo, anche in questo caso vale la legge aurea secondo la quale la cosa migliore da fare
presso
un certo impianto è ciò che serve e non ciò di cui si parla di più o che viene presentato come
più moderno e/o tecnologicamente più avanzato.
La evoluzione delle tecniche di connessione delle apparecchiature di storage sta consentendo di fare
passi avanti nella razionalizzazione delle risorse IT disponibili presso gli impianti; tuttavia la
presenza per tanto tempo di soluzioni del tutto eterogenee ed incompatibili ha un peso piuttosto
rilevante nel frenare i benefici che si possono ottenere.
Il sogno di ogni IT manager è quello di poter contare su apparecchiature di
memorizzazione che
possano
essere condivise da qualsiasi tipo di server non solo fisicamente (come reso parzialmente
possibile dalle SAN) ma anche logicamente (come reso parzialmente possibile dai NAS) evitando
duplicazioni dei dati e difficoltà di gestione; il tutto corredato da strumenti, per lo più software, in
grado
di mascherare l’inevitabile complessità del parco macchine esistente accettando da chi
gestisce l’ambiente comandi evoluti che non debbano tenere conto delle diversità.
La strada per ottenere ciò sembra essere quella della VIRTUALIZZAZIONE.
Il principio della virtualizzazione è una vecchia conoscenza dell’ambiente informatico che trova
svariate applicazioni in situazioni diverse.
Nel campo dello storage la virtualizzazione dovrebbe:
- dare la possibilità ad un qualsiasi server di chiedere un dato senza doversi preoccupare di
sapere dove tale dato si trovi e come sia scritto;
- dare la possibilità
a chi gestisce lo storage di chiedere la allocazione di spazi all’interno di
un insieme
(pool) di storage senza doversi preoccupare più di tanto del dove e del come;
- consentire, per quanto possibile, l’eliminazione della duplicazione dei dati a fronte di
piattaforme applicative distinte;
- consentire l’ impiego ottimale del parco macchine esistente;
- consentire, se necessario, l’ampliamento delle risorse disponibili a costi contenuti e senza
impatti negativi sulla normale operatività (che spesso deve essere 24 ore al giorno per 365
giorni
l’anno);
- etc.
Il tutto, naturalmente, senza sacrificare gli aspetti relativi alle prestazioni ed alla affidabilità.
La virtualizzazione è realizzata con la interposizione di nuovi strati di software evoluti e complessi
che consentono di dare al gestore una immagine quanto più possibile efficace e razionale del caos
sottostante.
D’altra parte, la gestione delle informazioni è un argomento critico all’interno di qualsiasi
organizzazione;
sia in termini di risorse (persone e cose) necessarie per effettuare le varie attività sia
in termini di importanza per le attività aziendali che, non dimentichiamo, sono l’unico vero
obiettivo di ogni impianto informatico. Se a ciò si aggiunge, come si è già citato, la vera e propria
esplosione nella richiesta di memorizzazione di dati derivante, tra l’altro, dalla diffusione di internet
e dalla conseguente necessità di disporre di informazioni on line in quantità sempre maggiore, si
comprende bene come sia auspicabile e bene accolto ogni strumento in grado di consentire una
gestione più efficiente delle problematiche connesse allo storage.
Che poi la enorme quantità di dati oggi disponibile on line e che si prevede crescerà ulteriormente
in futuro sia davvero necessaria o, almeno, utile o, almeno non dannosa, è un argomento che non
82

trova molti disposti a discuterne ed è un argomento che, in larga misura, esula l’ambiente
informatico e dovrebbe, in prima battuta, essere affrontato da chi si occupa di studiare il
comportamento umano per quanto riguarda le modalità e le reali necessità di comunicazione; perciò
non
si ritiene di dover esprimere commenti in questa sede, salvo il mostrare una certa perplessità.
Sta di fatto che la richiesta di memorizzazione
di dati cresce continuamente e corrispondentemente
crescono
le richieste di strumenti idonei a consentire una gestione ottimale; nel campo della
gestione dei dati, uno dei principali argomenti che devono essere affrontati è, come si è già
accennato
prima, quello delle procedure di sicurezza, cioè di quelle procedure volte ad assicurare il
superamento di situazioni di crisi che possono
essere causate da eventi di varia natura.
Si ribadisce
che il problema della sicurezza in genere, e della sicurezza dei dati in particolare, è un
problema
aziendale nel senso che:
- i benefici di una efficace gestione delle situazioni di crisi sono benefici per l’azienda nella
sua interezza, individuabili, talvolta, nella stessa sopravvivenza dell’azienda a fronte di
eventi disastrosi di varia natura;
- i requisiti di sicurezza, cioè cosa e in che misura proteggere, possono correttamente essere
definiti solo tramite un lavoro congiunto dei vari reparti aziendali; le conclusioni di questo
lavoro costituiscono poi l’input del settore informatico, così come di tutti gli altri settori per
le parti di loro competenza;
- la sicurezza non è un valore di per sé e neppure deve essere semplicemente una moda, bensì
è un valore se fornisce un servizio valutato utile a livello aziendale
a seguito di una attenta
valutazione dei rischi (risk assessment) circa l’entità dell’impatto di una situazione di crisi
sulla operatività aziendale;
- adottare procedure di sicurezza che riguardano solo l’ambiente IT è una procedura parziale
in quanto può consentire di superare solo quella parte di incidenti strettamente informatici
(fermi macchina programmati e non programmati, disservizi software, guasti nei sistemi di
alimentazione, etc.); in quanto generalmente parziale si giustifica solo se è il frutto di una
consapevole attività di risk assessment complessiva.
Vale la pena di ricordare che, nella maggior parte dei casi, la indisponibilità delle informazioni
blocca l’intero funzionamento aziendale. Inoltre, recenti normative inducono precisi requisiti in
termini di disponibilità e protezione dei dati [6].
83

2.2.2.2 I nastri
La indubbia importanza delle unità a disco porta spesso a trascurare l’altra grande famiglia delle
unità di memorizzazione di massa: le unità a nastro.
Eppure, è bene affermarlo fin dall’inizio, le unità a nastro sono, ancora oggi, l’insostituibile
strumento per la realizzazione di alcune attività, tra le quali, le più significative sono tutte le attività
volte ad assicurare la sicurezza dei dati.
Prestazioni
DISCHI
MAGNETICI
DISCHI
OTTICI
NASTRI
MAGNETICI
Capacità
Nel grafico prima riportato che evidenzia una sorta di gerarchia delle unità di memorizzazione di
massa, i nastri, per quanto siano accreditati della maggior capacità, rappresentano la famiglia che
consente l’accesso ai dati “più lento” rispetto agli altri supporti. Ciò in quanto i nastri, oltre ad
essere costruiti con una rilevante componente di parti meccaniche, sono supporti che tipicamente
forniscono una possibilità di accesso sequenziale.
84

Questa caratteristica, idonea ad una tipologia di elaborazione di tipo BATCH dove grandi quantità
di dati vengono elaborate sequenzialmente, non si addice a supportare carichi di lavoro di tipo
transazionale e/o interattivo che, al contrario, come già detto, richiedono un accesso diretto alle
informazioni reso disponibile dalle unità a disco magnetico.
Evoluzione tecnologica
Le unità nastro, introdotte intorno agli inizi degli anni 50, qualche hanno prima delle unità a disco,
hanno progressivamente sostituito le schede perforate. Il passaggio dalle schede perforate ai nastri
magnetici ha avuto risvolti molto importanti all’interno degli impianti informatici; si pensi, a questo
proposito, che anche con la densità di registrazione consentita dalle prime unità a nastro di circa 100
bpi (bit per inch o bit per pollice), che oggi fa sorridere se si pensa alle densità di registrazione
attuali che vanno oltre i 200.000 bpi, una bobina del diametro di circa 10 pollici (vedi foto sotto)
con nastro di larghezza mezzo pollice consentiva di sostituire circa 35.000 schede perforate!
Il supporto di memorizzazione delle unità a nastro è costituito da un nastro flessibile ricoperto di
materiale magnetizzabile; flessibile, come è intuitivo, vuol dire anche fragile, imperfetto e
tendenzialmente inaffidabile, eppure offre una serie di caratteristiche uniche.
Una cartuccia, ad esempio, rispetto alle unità a disco oggi impiegate, ha il notevole vantaggio di
potere essere rimossa e conservata in un luogo appropriato per garantire la sicurezza dei dati
contenuti nei riguardi di varie cause esterne.
Rispetto al disco, inoltre, ha la caratteristica di non contenere dentro di sé l’elemento di
lettura/scrittura che, invece, fa parte del drive, cioè della unità in cui si inserisce il nastro per potere
effettuare le operazioni di lettura e scrittura; ciò rende possibile e sufficientemente sicura la lettura
di un nastro anche dopo oltre un decennio dalla sua registrazione; le unità a disco, invece,
necessitano di un trattamento più frequente per assicurare la corretta funzionalità delle parti
meccaniche interne, l’integrità del lubrificante impiegato, etc.
La eventuale necessità di rileggere un nastro anche dopo molto tempo, però, pone stringenti limiti
sulla compatibilità che le nuove apparecchiature devono garantire verso nastri memorizzati anche
diverso tempo prima; questo problema è più delicato se si considera, come detto appena sopra, che
gli apparati di lettura sono esterni al nastro e perciò il loro progresso tecnologico deve anche tenere
nel giusto conto le necessità di compatibilità. La compatibilità, almeno in lettura, di vecchi nastri su
drives nuovi ha, in realtà, limitato il ritmo di crescita della tecnologia di memorizzazione su nastro
magnetico.
Il nastro era, inizialmente, avvolto in bobine circolari e, su richiesta del sistema operativo, veniva
caricato da un operatore sul lettore; alla bobina con il nastro veniva affiancata una bobina vuota
sulla quale il nastro veniva avvolto man mano che procedeva la lettura. In questa modalità operativa
si individua il limite, che sembrò addirittura destinare il nastro ad una rapida scomparsa, insito nella
gestione dei nastri montati su bobine, cioè la costante necessità dell’intervento umano per il
montaggio e smontaggio delle bobine; era comune trovare, negli impianti informatici dotati di folte
batterie di unità a nastro, una quantità rilevante di operatori addetti alla gestione delle nastroteche.
Agli inizi degli anni 70 erano stati introdotti dei nuovi supporti anch’essi basati sul principio della
memorizzazione su nastro magnetico e che si prestavano ad una certa automazione nella loro
gestione; si trattava di cilindretti di circa 3,5 pollici di altezza e 2 di diametro, all’interno dei quali
era avvolto un nastro prossimo ai 3,5 pollici di larghezza; un robot prelevava il cilindro richiesto da
85

una struttura ad alveare che li conteneva e provvedeva a montarlo nel drive; questo sistema non
ebbe, però, il successo sperato dai suoi ideatori.
La vera svolta nella gestione delle memorie a nastro avvenne con la sostituzione delle bobine con le
cartucce (cartridge) che oggi conosciamo; ciò ha consentito alle apparecchiature basate sui nastri
magnetici di sopravvivere e di affermarsi fino ai nostri giorni.
Nella seguente fotografia è riportata una bobina da 10,5 pollici in grado di memorizzare 180 MB ed
una moderna cassetta da 5,5 pollici in grado di memorizzare fino a 200 GB.
L’utilizzo delle cartucce non richiede una cartuccia vuota in quanto il nastro, tramite un gancio che
ne preleva la estremità accessibile, è avvolto, durante le operazioni di lettura/scrittura, su una
struttura interna al drive; quando la cartuccia deve essere scaricata dal drive il nastro viene riavvolto
nella sua sede originale.
La figura seguente, tratta da una pubblicazione IBM [8], riporta due unità per la gestione dei nastri e
due unità per la gestione delle cartucce.
86

Il passaggio dai nastri alle cassette ha aperto la strada alla soluzione del problema della
automazione
della gestione dello storage su nastro; un primo passo è stato l’impiego di lettori di
cassette
che consentissero di tenere in linea (cioè disponibili per un montaggio automatico) un
numero
limitato di cassette, con gli accessori cosiddetti ACL (Automatic Cartridge Loader);
apparecchiature
che si basano su strumenti di questo genere sono ancora diffuse presso gli impianti
informatici
attuali.
87

Il passo successivo, avvenuto intorno alla fine degli anni 80, è stato rappresentato dalla introduzione
degli
ATL (Automatic Tape Library) o Librerie di nastri, cioè di grandi apparecchiature in grado di
ospitare
e gestire migliaia di cartucce tramite un braccio robotico che ne cura la movimentazione tra
i drives di lettura/scrittura, anch’essi contenuti all’interno della libreria, e gli alloggiamenti.
La fotografia in alto mostra una libreria della ditta Storage Technology; si intravedono le cassette
ordinatamente disposte; un braccio meccanico controllato da appositi programmi preleva le cartucce
e le inserisce nei drives contenuti nelle strutture ben visibili accostate dall’esterno al silo.
L’evoluzione tecnologica dei nastri è perciò
passata da una completa revisione della struttura
all’interno
della quale risiede il supporto magnetico vero e proprio; a questa macroscopica
evoluzione si è affiancata la evoluzione tecnologica strettamente connessa alle tecniche di
88

memorizzazione che, come ormai noto, ha avuto, ed ha tutt’ora, l’obiettivo di aumentare la densità
di registrazione mantenendo, naturalmente, l’affidabilità a livelli adeguati.
Come abbiamo detto, la registrazione su nastro deve misurarsi con un mezzo di per sé fragile ed
inaffidabile;
come se ciò non bastasse il nastro è esposto all’ambiente esterno pieno di polvere e di
altre impurità; ciò ha condotto alla predisposizione di tecniche specifiche per assicurare una
affidabile
memorizzazione dei dati. La più significativa di queste tecniche consiste nel leggere, e
q uindi verificare, il dato subito dopo la sua scrittura; ciò si realizza facendo seguire ad ogni
elemento di scrittura un elemento di lettura; fino alla fine de gli anni 80 gli elementi di lettura e
quelli di scrittura erano elementi del tutto separati e ve nivano poi montati in
tandem per consentire
il procedimento cosiddetto read after (while) write prevedendo la registrazione in una sola
direzione di mot o del nastro; successiva mente tale vincolo è stato superato co n nuove tecnologie
costruttive consentendo la registrazione in entrambe le direzioni di moto del nastro. Per consentire
ciò
ha avuto un forte rilievo l’introduzione di servopiste per consentire il preciso posizionamento
delle
testine sul nastro.
L’aumento della densità di registrazione è ottenuto tramite la opportuna applicazione delle tecniche
di scaling, già richiamate relativamente alle unità a disco; nel caso dei nastri, la lunghezza del
nastro stesso fornisce un nuovo grado di libertà per il raggiungimento della capacità complessiva
della singola cassetta.
I prodotti per la memorizzazione su nastro che sono stati sviluppati da vari fornitori nel tempo sono
numerosi
e spesso incompatibili tra loro.
Nella fascia delle apparecchiature per mainframe sono presenti un certo numero di fornitori i quali
si sono uniformati a standard di fatto derivati dalle unità a nastro IBM e dalle necessità di
connessione verso i grandi elaboratori; negli ambienti di elaborazione medio-piccoli, vi è stata la
proliferazione di un numero rilevante di soluzioni.
A metà degli anni 90, Hewlett Packard, Seagate ed IBM hanno costituito un consorzio finalizzato
alla definizione di una nuova architettura per la memorizzazione su nastro che fosse particolarmente
rivolta
agli ambienti OPEN; nasceva così una nuova linea di prodotti definita LTO
(Linear Tape
Open – Ultrium Format) le cui caratteristiche sono pubbliche e perciò accessibili
a tutti i fornitori
intenzionati
a produrre macchine conformi.
Gli obiettivi del consorzio erano lo studio di un nuovo formato per la memorizzazione su nastro che
fosse affidabile,
che consentisse una elevata velocità di trasferimento dei dati, che disponesse di
una elevata capacità di memorizzazione per singola cartuccia e che avesse precise caratteristiche di
compatibilità all’interno della famiglia.
Per i prodotti
LTO venne stabilità anche una linea evolutiva, riassunta nella seguente tabella.
Drive di Drive di Drive di Drive di
Generazione 1 Generazione 2 Generazione3 Generazione 4
Capacità nativa 100 GB 200 GB 400 GB 800 GB
Può leggere da Generazione 1 Generazione 1-2 Generazione 1-2-3 Generazione 2-3-4
Può scrivere su Generazione 1 Generazione 1-2 Generazione 2-3 Generazione 3-4
89

Oggi tutti i principali fornitori di apparecchiature a nastro hanno, spesso affiancati ai tradizionali
prodotti, anche apparecchiature che rispettano le caratteristiche LTO; ciò, in un mondo come quello
della
informatica ricco di incompatibilità, è sicuramente un vantaggio in quanto crea una positiva
concorrenzialità.
Evoluzione architetturale
Anche
le unità di memorizzazione a nastro magnetico hanno avuto una evoluzione architetturale
analoga a quanto abbiamo visto per le unità a disco; la necessità di migliorare le prestazioni delle
apparecchiature
in termini di capacità ed in termini di velocità di dialogo con le unità di
elaborazione sgravando queste ultime dal compito di gestire direttamente
le periferie a nastro, ha
visto,
anche in questo caso, l’introduzione delle unità di controllo e la loro evoluzione.
Tra i numerosi miglioramenti intervenuti nel settore, una importante
evoluzione nelle modalità di
gestione dei nastri è stata l’introduzione di tecniche di virtualizzazione dei nastri.
A dare il via a questa implementazione sono stati diversi fattori, tra i quali:
- l’operatività sui nastri è comunque lenta rispetto alle velocità degli altri componenti
hardware di un impianto;
- il forte condizionamento delle attività di back-up derivante dalla performance delle unità a
nastro rendeva necessario un livello di disaccoppiamento
dalla attività specifica sui nastri;
- tecniche di gestione dei nastri risalenti a qualche decennio fa, ed ancora in uso specie negli
ambienti mainframe, causavano un utilizzo scarso della capacità della singola cartuccia
consentendo, in alcuni casi, un riempimento medio addirittura intorno al 10 %;
- il punto precedente vanificava, in pratica, ogni miglioramento in termini di capacità della
cartuccia
Gli anni 90 hanno visto, così, il diffondersi dell’impiego dei virtualizzatori dei nastri non solo
presso i grandi impianti informatici ma anche presso le installazioni
medie operanti in ambienti
mainframe.
Il virtualizzatore dei nastri, che si frappone tra unità di elaborazione ed unità a nastri, è, in sostanza,
una apparecchiatura che, tramite una sua capacità elaborativa, tramite unità a disco di proprio
esclusivo utilizzo e proprio software di gestione, rende visibili alla unità di elaborazione dei nastri
logici, simulati sulle proprie unità a disco, che provvede a trasferire sui nastri fisici con le modalità
e con i tempi decisi dai prodotti software di gestione propri del virtualizzatore stesso.
In pratica, il sistema operativo della unità di elaborazione indirizza le unità a nastro virtuali che gli
vengono presentate dal virtualizzatore
e su di esse effettua le proprie attività; è compito del
virtualizzatore
gestire le unità a nastro fisiche di cui dispone, scaricando su di esse i nastri virtuali o
caricando da esse i dati necessari a creare i nastri virtuali.
Normalmente il virtualizzatore utilizza dispositivi fisici a nastro contenuti in librerie automatiche.
I vantaggi della gestione dei nastri tramite virtualizzatore sono numerosi:
- innanzitutto, il virtualizzatore è in grado di inserire diversi nastri logici nel medesimo nastro
fisico ottimizzando il riempimento effettivo delle cartucce;
90

- il virtualizzatore costituisce anche uno strato di caching tra nastri e unità di elaborazione
consentendo l’accesso ad un nastro logico con tempi più vicini a quelli tipici dell’accesso ad
una unità a disco;
- il formato del nastro logico che il virtualizzatore presenta alla unità di elaborazione è
indipendente dal formato specifico del nastro fisico disponibile; in altre parole il sistema
operativo pensa di lavorare con un nastro che in realtà è solo una astrazione del nastro
effettivo, e in quanto astrazione può rimanere costante anche al variare del nastro fisico
stesso per adeguamenti tecnologici o altro.
Se volessimo indagare, anche nel caso dei nastri, sui sogni di un IT manager, molto probabilmente
ci
troveremmo di fronte al desiderio di poter disporre per qualsiasi piattaforma operativa delle
riso rse nastro necessarie o più adeguate senza per questo dover disporre, fisicamente, di quelle
unità.
E’ evidente
che un desiderio del genere diventa ancora più pressante quando si parla di strutture
SAN che
contengono anche nastri e/o librerie automatiche di nastri.
Le SAN,
infatti, pur consentendo ai vari servers applicativi di raggiungere, teoricamente, qualsiasi
unità di
storage servendosi di una rete dedicata, senza perciò appesantire il traffico sulla LAN (cosa
particolarmente importante quando si tratta, ad esempio, del pesante traffico dovuto alle attività di
back-up) lasciano buona parte del carico di gestione sulle spalle delle persone della struttura IT;
per
la verità, la attività di gestione dello storage in genere e delle unità a nastro in particolare è
effettuata tramite prodotti software di servizio che forniscono già delle funzioni evolute, tuttavia in
ambienti
che si complicano sempre di più a causa, tra l’altro, della coesistenza di apparecchiature
eterogenee,
il livello di astrazione che sarebbe necessario per assicurare un utilizzo efficiente delle
risorse non è ancora disponibile.
Nella realizzazione
del sogno di cui si diceva il ruolo dei virtualizzatori può diventare determinante.
Si
immagini ancora una volta la situazione, che si assume come riferimento in quanto comune a
molte realtà non solo di grandi dimensioni, di un impianto informatico in cui siano presenti servers
applicativi
operanti in diversi ambienti (mainframe, windows, unix, linux, etc.); per fare in modo
che tutti questi ambienti possano disporre di unità a nastri si dovrebbe:
- disporre delle unità a nastro richieste da ciascun ambiente (spesso incompatibili con
ambienti diversi);
- e/o, nei limiti del possibile, creare all’interno di una apparecchiatura per la gestione dei
nastri, ad esempio
una libreria automatica, quanto necessario in termini di drives e di media
(cioè
supporto fisico vero e proprio) per soddisfare le necessità delle varie piattaforme
operative. La prima soluzione, per quanto piuttosto inefficiente, è stata, per lungo tempo, l’unica possibile; la
seconda,
pur prestandosi ad un certo livello di automazione, crea comunque delle inefficienze in
quanto , all’interno della ipotetica libreria di nastri in comune, si verrebbero a creare ambienti del
tutto isolati, in termini di drives e cartucce, asserviti alle varie piattaforme; le prime inefficienze che
in questo
caso vengono a galla sono :
- il probabile scarso livello di utilizzazione di singole risorse a fronte di altre in saturazione; il
partizionamento, ad esempio, di una libreria a nastri consiste nell’assegnare ad un
determinato server applicativo un certo numero di drives, un certo numero di cartucce ed un
certo numero di vie di comunicazione; una assegnazione del genere, per quanto possa essere
91

en fatta e perfettamente bilanciata in un dato momento, è destinata ad essere superata con il
tempo in funzione delle variazioni dei carichi di lavoro; in questi casi si potrebbe rendere
necessaria una riconfigurazione ove fossero soddisfatti requisiti di compatibilità o, più
probabilmente, l’acquisto di nuove apparecchiature pur a fronte di altre scarsamente
utilizzate; insomma, il solito problema;
- la duplicazione di dati per consentirne il loro recupero da piattaforme servers diverse.
Da ciò il sogno:
- disporre di un supporto fisico di un unico tipo, standard e perciò acquisibile da diverse fonti,
sia in termini della libreria automatica sia in termini di drives e di cartucce;
- disporre di uno strato di virtualizzazione in grado di supportare, da un lato, gli standard fisici
di cui sopra, e dall’altro tutte le piattaforme servers possibili ed immaginabili o almeno,
(come è più realistico immaginare, anche se si tratta di sogni) quante più possibile.
Nel
sogno
- l’insieme drive-cartucce dovrebbero avere la capacità più elevata possibile, in quanto il reale
riempimento sarebbe a carico del virtualizzatore, e dovrebbe appartenere ad un unico gruppo
(pool) utilizzato dal virtualizzatore secondo le proprie necessità;
- il ciclo di vita delle cartucce
o prelievo dal pool di cartucce disponibili per l’uso(spesso chiamato scratch pool)
o utilizzo
o conservazione, dentro o fuori una eventuale libreria, fino alla cosiddetta data di
scadenza (che rappresenta il tempo fino al quale è necessario conservare i dati in
base a necessità di back-up o di altra natura)
o ritorno della cartuccia al pool scratch
dovrebbe essere gestito dal virtualizzatore in modo del tutto sconnesso, anche se ovviamente
coerente, con il ciclo di vita della cartuccia logica vista dal server applicativo;
- la duplicazione dei dati sulle cartucce dovrebbe essere quanto più contenuta possibile mentre
per quanto concerne la performance, cioè la capacità di trasferimento nell’unità di tempo, si
potrebbero accettare anche dei compromessi purché il virtualizzatore sia dotato di una
quantità di memoria a disco grande abbastanza da produrre un adeguato effetto di caching.
I mattoni base per avviare una architettura del genere potrebbero essere
- la tecnologia LTO, che, come abbiamo visto, prevede nella sua quarta generazione una
capacità non compressa per singola cartuccia di 800 GB (e sono in corso attività di studio,
che, sembra, si stiano approssimando a raggiungere il livello di produzioni industriali, per
cassette con capacità singole di 1 T(era)B);
- i concetti di virtualizzazione che, però, si dovrebbero spingere a livelli più evoluti.
Tra l’altro, l’attuale insostituibilità delle unità a nastro in attività chiave quali il back-up ed il
disaster recovery rendono verosimile, e probabile, un progresso nella gestione dei nastri stessi
verso architetture più evolute.
Nelle scelte che si devono fare relativamente a questo argomento si deve cercare di muoversi
avendo chiaro uno schema di riferimento, che può variare in base alle varie specifiche realtà, da
considerare come punto di arrivo; quanto più le singole scelte saranno un tassello coerente con il
quadro di insieme futuro tanto più l’impianto sarà pronto a beneficiare degli strumenti più evoluti
che potrebbero concretizzarsi in un futuro più o meno prossimo.
92

D’altra parte disporre di un quadro complessivo all’interno del quale effettuare i singoli interventi è
una buona norma in ogni caso ed in ogni ambiente.
93

2.2.2.3 I dischi ottici
I primi dischi basati su una tecnologia di memorizzazione ottica risalgono agli anni
80.
I dischi ottici occupano una posizione intermedia, sia in termini di capacità sia in termini di
performance,
tra i dischi magnetici ed i nastri magnetici. L’attuale impiego primario dei dischi ottici
li vede come i principali strumenti per la distribuzione del software e della relativa documentazione
nell’area
del personal computing, ed in questa area hanno praticamente soppiantato l’impiego dei
floppy
disk che si avviano a scomparire del tutto. Nell’area dei mainframe, invece, la distribuzione
del
software è prevalentemente ancora effettuata tramite cartucce di nastro magnetico e l’impiego
dei
dischi ottici è limitato alla distribuzione della documentazione che in forma cartacea è quasi del
tutto
scomparsa.
I primi dischi ottici che hanno avuto una larga diffusione sul mercato sono stati i dischi ottici a sola
lettura
(ROM) realizzati con l’impiego di un formato derivato dai Compact Disk audio; si tratta cioè
dei
CD-ROM.
La
memorizzazione dei dati avviene su una traccia a spirale (si ricorda che i dischi magnetici
impiegano,
invece, tracce concentriche) sulla quale vengono impresse le informazioni tramite la
creazione
di “avvallamenti” (pit) che riflettono la luce in modo differente rispetto alle zone
inalterate
della traccia (land) consentendo di ricostruire le informazioni.
La
creazione dei CD avviene tramite l’impiego di un disco master, che ha delle sporgenze nei punti
in cui devono essere realizzati i pit, e di un masterizzatore; i pit sono delle deformazioni permanenti
e consentono quindi una sola scrittura. Il processo di masterizzazione è costoso e, perciò, si
giustifica
quando devono essere prodotte grandi quantità del medesimo CD.
La
necessità di poter disporre di un supporto ottico registrabile a basso costo ha portato alla nascita
dei
CD-R, cioè CD registrabili una sola volta tramite l’impiego di masterizzatori a basso costo. La
tecnica
di registrazione prevede la simulazione dei pit tramite la bruciatura delle corrispondenti
aree;
le zone bruciate si comportano nei riguardi della luce come i pit impressi sui CD-ROM.
Poiché
le “bruciature” sono irreversibili, l’operazione di scrittura può avvenire una sola volta ed è
permanente.
I CD-R grazie alla loro caratteristica di consentire una sola scrittura hanno trovato un largo utilizzo
in quelle applicazioni
che richiedono, appunto, la memorizzazione irreversibile di informazioni;
questa caratteristica è oggi ottenibile anche con tecnologie di registrazione magnetica basandosi,
però, non su modificazioni permanenti del mezzo di registrazione, bensì su architetture software
che
consentono, in pratica, di raggiungere il medesimo risultato.
Il terzo tipo di disco ottico è denominato CD-RW cioè rewritable; in questo caso il disco ottico può
essere scritto più volte; per ottenere ciò è necessario che la scrittura non avvenga con un
procedimento che provoca delle modificazioni permanenti nel mezzo; infatti, la scrittura è ottenuta
tramite una variazione reversibile della fase (phase change) in cui si trovano i vari punti sulla
traccia. In particolare, quando il materiale viene portato ad una certa temperatura cristallizza e
riflette la luce; se invece viene portato ad una temperatura maggiore assume una struttura non
cristallina e diventa meno riflettente.
Più di recente, il campo della memorizzazione ottica ha visto la comparsa dei DVD che utilizzano,
in linea di principio, le stesse tecniche viste per i CD ma consentono di raggiungere capacità di
94

memorizzazione per disco estremamente più elevate. Ciò è ottenuto sia grazie ad una maggiore
densità
di registrazione superficiale sia grazie alla possibilità di registrare i dati su due livelli su
entrambe
le facce del disco.
Lo schema sottostante riassume quest’ultima possibili tà.
Nelle
tre immagini sono riportate, rispettivamente, una registrazione su singolo livello su una
faccia,
una registrazione su doppio livello su una facc ia ed una registrazione su dop pio livello su
entrambe le facce.
I dischi ottici si prestano anche ad una gestione automatizzata e sono, perciò, disponibili delle
librerie
ottiche in grado di gestire una certa quantità di media.
95

UNITA’ di MEMORIZZAZION E DI MASSA – Domande di verifica
1 n el campo della registrazione magnetica su
disco l'areal density è pari a
BPI x TPI
Seek Time+tempo latenza
Throughput x Miss penalty
Commenti: ..............................................................................................................................
..... ................................................................... ............ .. ... ................................... .....................
2 nelle unità a disco, la dista nza "head to media"
e la areal density sono
proporzionali
non hanno relazione
inversamente proporzionali
Commenti: ..............................................................................................................................
..... ................................................................. .............. .. ... ....... .................................................
3 il seek time è il tempo necessario a posizionare la testina di un disco sulla
traccia desiderata
la testina di un disco sul
settore desiderato
una cartuccia nel drive
Com menti: ..... ............................................................ .. ... ............................. ................ ...........
.. ... ... ............................................................................ .. ... ........................................................
4 l'e ffetto superparamagnetico si presenta al
crescere
della velocità di ca lcolo
della areal density
del livello di RAID
Com menti: ............................................................... .. .. ... ............................... .............. ...........
.. ... ... ............................................................................ .. ... ............................ ............................
96

5 la cache presente in un sottosistema a disco lettura dal disco
magnetico velocizza le attività di
scrittura su nastro
accesso a memoria
centrale
Comm enti: ..................................................................................................................... .........
.. ...............................................................................................................................................
6 la memoria non volatile (NVS) presente nei
sottosistemi a disco magnetico, velocizza
la "scrittura" sul disco
in condizioni di sicurezza l'accesso ai nastri
il seek time
Commenti: ..............................................................................................................................
.................................................................................................................................................
7
un NAS è dotato di un proprio File System no
qualche volta
Commenti: ................................................................. .. ... ... .......................................... ...........
.. ... ... ............................................................................ .. ... ........................ ................................
8 una SAN è un server storage
si
una rete dedicata ai dati
una unità a disco
Com menti: ............................................ ..................... .. ... ........................... .................. ...........
.. ... ... ............................................................................ .. ... ............................. ...........................
9 una delle attività più comuni al fine di assicurare la il back-up su nastri
sicurezza dei dati è
il site preparation
il think time
Commenti: ..............................................................................................................................
.. ...............................................................................................................................................
97

10 i/le nastri/cartucce, dopo la registrazione, dopo non più di un mese
possono, di norma, essere riletti
dopo non più di 12 mesi
anche dopo diversi anni
Commenti: ..............................................................................................................................
.................................................................................................................................................
11
l'impiego delle unità a nastro è stato rivitalizzato
dalla introduzione dei media a cartuccia perché,
sono più leggeri
principalmente, tali supporti c onsentono una gestione
automatizzata
sono più "performanti" dei
dischi magnetici
Comm enti: ..................................................................................................................... .........
.. ...............................................................................................................................................
12
i virtualizzatori impiegati nel campo delle unità la presentazione dei dati a
a nastro/cartuccia contribuiscono a migliorare
tra l'altro,
video
il riempimento delle
cartucce
la densità di registrazione
della cartuccia
Commenti: ..............................................................................................................................
.................................................................................................................................................
13 quale è la evoluzione che è stata prevista per la 100-200-400-800 GB
tecnologia LTO in termini di capacità non
compressa della cartuccia magnetica 10-20-40-80 GB
20-40-80-160 lpm
Commenti: ..............................................................................................................................
.................................................................................................................................................
98

14 uno degli obiettivi della storage consolidation è del seek time
il miglioramento
dell'utilizzo dello storage
della qualità delle stampe
Commenti: ..............................................................................................................................
.................................................................................................................................................
15 server consolidation e storage consolidation sempre coesistenti
sono
sempre in alternativa
indipendenti
Commenti: ..............................................................................................................................
.................................................................................................................................................
99

2.2.3
Altre unità
2.2.3.1
Unità di stampa
Se
le unità
a nastro magnetico vengono spesso trascurate nel commentare le apparecchiature
informatiche presenti in un impianto, le apparecchiature di stampa non subiscono una sorte
migliore.
Eppure, all’interno di un impianto
informatico, le problematiche connesse alle attività di stampa
devon o essere affrontate con cura in quanto le stampe hanno non solo un valore rilevante all’interno
delle
organizzazioni ma anche all’esterno di esse essendo uno degli strumenti con cui
frequentemente
una azienda si presenta all’esterno.
La scelta
della stampante più opportuna deve essere effettuata seguendo il consueto principio della
ottimizzazione
del TCO che, in questo
caso, potrebbe essere il costo complessivo necessario per la
produzione di una pagina, includendo:
- costo di acquisto;
- costo di manutenzione;
- costo dei materiali di consumo necessari;
- costo delle competenze necessarie a gestire le apparecchiature;
- etc.
Anche
nel campo delle stampanti, la corretta valutazione dei costi complessivi non è sempre
facile
in quanto l’incidenza dei materiali
di consumo può rappresentare percentuali molto diverse del TCO
costituendone,
addirittura, il componente fondamentale.
Inoltre, alcune voci di costo connesse sia ai prodotti ausiliari sia alla manutenzione delle
apparecchiature sono spesso contrattualmente legate al carico di lavoro effettivamente realizzato
dalle apparecchiature (cioè, ad esempio, al numero di pagine stampate in un certo tempo); ciò rende
necessario effettuare delle ipotesi sui volumi di lavoro basate, ove possibile, su dati storici
opportunamente rivisti e sulle previsioni relative agli sviluppi futuri.
E’ possibile raggruppare le stampanti secondo diversi punti di vista; si fornisce di seguito una
possibile suddivisione pur riconoscendo che, sovente, le divisioni sono meno nette e gli impieghi
talvolta sovrapposti.
Dal punto di vista della capacità di stampa intesa come quantità di pagine emesse in un determinato
periodo si parla di:
- stampanti utente, generalmente collegate ad un singolo posto di lavoro, sono impiegate
prevalentemente per la produzione degli
output derivanti da attività di informatica
individuale;
- stampanti di gruppo, generalmente connesse ad una rete locale e raggiungibili dagli utenti
che insistono sulla rete stessa, hanno una capacità in genere maggiore e su di esse vengono
prodotti output più impegnativi sia per quantità di stampa sia per qualità di stampa;
- stampanti di sistema, generalmente connesse a mainframe o a minicomputer, soddisfano in
genere le necessità di stampa più onerose prevalentemente sotto l’aspetto quantitativo.
Dal punto di vista della qualità di stampa si parla di:
100

- stampanti di qualità; macchine dotate di capacità grafiche, in grado di gestire i colori e che
possono avere costi estremamente variabili in base ai vari livelli di qualità raggiungibili ed
ai volumi di stampa che possono soddisfare;
- stampanti di massa; sono macchine per le quali gli aspetti connessi alla qualità
di stampa
sono secondari a fronte della robustezza e della velocità di stampa.
Dal punto di vista del supporto cartaceo utilizzabile si parla di:
- stampanti a foglio singolo, prevalentemente rivolte a soddisfare volumi di stampa non
elevatissimi;
- stampanti a modulo continuo, prevalentemente rivolte a soddisfare volumi di stampa elevati;
è sempre più raro trovare stampanti a modulo continuo nella fascia delle stampanti utente e,
generalmente, anche nella fascia delle stampanti di gruppo, mentre
presso gli impianti
informatici medio grandi continuano
ad essere presenti; consentono una capacità di stampa
complessiva più elevata.
Dal
punto di vista tecnologico si parla di:
- stampanti ad impatto, dedicate a necessità di stampa che necessitano di questa tecnologia e
praticamente scomparse dai posti di lavoro singoli dove, fino a qualche anno fa, erano molto
presenti;
- stampanti non ad impatto, che sono la quasi totalità delle apparecchiature per singolo utente
e per gruppi di utenti, e che svolgono una larga parte del lavoro di stampa anche negli altri
ambienti nel caso non vi sia una necessità specifica che non lo consenta.
Evoluzione tecnologica
La stampa ad impatto è stata la prima tecnologia di stampa disponibile; il sistema di stampa,
ricalcato da quello impiegato nelle prime macchine da scrivere, prevede l’interposizione tra la carta
ed il sistema
di impressione di un nastro inchiostrato; l’impatto, realizzato con varie modalità,
provvede
a trasferire l’inchiostro sulla carta. Queste stampanti possono trasferire, in un impatto, un
intero carattere (o parte di esso) e vengono allora chiamate stampanti seriali, oppure una intera linea
di stampa (o parte di una intera linea) e vengono allora chiamate stampanti a linee.
In sostanza, in una stampante seriale la stampa procede prima in direzione orizzontale e, via via, in
direzione verticale; in una stampante a linee la stampa procede in senso verticale poiché viene
prodotta una intera linea o parte di una intera linea (nel senso della medesima zona di ogni singolo
carattere che costituisce la linea) alla volta. Pertanto, una stampante seriale oltre che richiedere uno
scorrimento
della carta in senso verticale, necessita di un apparato di scrittura mobile in senso
orizzontale.
Nel caso in cui ad ogni impatto venga creato un carattere o una linea si parla di
stampanti
di tipo “a carattere”, nel caso in cui ad ogni impatto venga creato parte di un carattere o di
una linea si parla di stampanti di tipo “a matrice”.
La tecnologia delle stampanti ad impatto è necessaria in alcuni casi tra i quali, ad esempio, la
stampa su moduli multicopia (cioè moduli a ricalco) che non potrebbe essere ottenuta con stampanti
non ad impatto (tutti coloro che ricevono la comunicazione di PIN, codici segreti, ed altro del
genere, tramite moduli stampati hanno davanti agli occhi un esempio di stampa che richiede
obbligatoriamente una tecnologia ad impatto); inoltre consentono generalmente di ottenere:
- costi per pagina inferiori;
101

- una migliore affidabilità nel funzionamento specie in ambienti soggetti a condizioni
ambientali non ottimali (magazzini, etc.);
- una maggiore tolleranza verso diversi tipi di carta;
- la produzione, anche in prodotti di basso costo, di stampe su modulo continuo;
- etc.
di contro, le stampanti ad impatto hanno delle forti limitazioni:
- nella capacità di riprodurre contenuti grafici (disegni, immagini, etc.) specie, come è ovvio,
nel caso delle stampanti a carattere le quali, disponendo solo di uno specifico set di caratteri,
non consentono di riprodurre altre forme, mentre tale limitazione può essere in qualche
modo alleviata nel caso delle stampanti a matrice per le quali l’indirizzabilità dei singoli
punti della matrice può consentire qualche ulteriore grado di libertà;
- nella capacità di gestire i colori
inoltre,
come è facile comprendere, possono comportare una rumorosità piuttosto elevata.
Le limitazioni indicate per le stampanti ad impatto sono proprio i punti di forza delle stampanti che
impiegano tecnologie non ad impatto; cioè creano il trasferimento delle informazioni sulla carta con
sistemi che non richiedono alcun impatto bensì si basano su processi termici, elettrofotografici, di
gestione di inchiostri liquidi, etc.
Le
migliori capacità grafiche e di gestione del colore anche su macchine a basso costo di acquisto
hanno fatto si che le stampanti non ad impatto (tipicamente le stampanti a getto di inchiostro ink-jet
o simili) siano entrate a far parte stabilmente della postazione di lavoro abituale; sfortunatamente,
molto
spesso il TCO di soluzioni del genere non è affatto
favorevole rispetto a quello ottenibile con
altre tecnologie tuttavia, un costo di acquisto
molto contenuto fa si che spesso non si proceda con
una valutazion e complessiva del TCO;
anzi, il concetto stesso di TCO, visto anche l’ambiente
tipicamente
di largo consumo cui
si rivolgono principalmente queste soluzioni, spesso non è
conosciuto.
Le stampanti non ad impatto nella
fascia di costo di acquisto medio-bassa consentono,
normalmente, la stampa su moduli singoli
e possono contenere anche la funzionalità di stampa
fronte-retro.
N el campo delle stampanti non ad impatto nella fascia di costo alta
si trovano anche stampanti per
modulo continuo e, ricorrendo in genere a due unità di stampa operanti sullo stesso modulo cartaceo
(vedi foto sotto), stampanti per modulo continuo con la possibilità di produrre stampe in fronte
retro.
102

Nella foto precedente si vedono due stampanti laser di fascia alta operanti sullo stesso modulo
continuo al fine di produrre un output di stampa in fronte-retro; l’impaginazione è controllata da
adeguati prodotti software. Le due apparecchiature sono del tutto indipendenti e possono anche
operare come due stampanti singole per la produzione di output solo fronte; le due modalità di
funzionamento possono essere dinamicamente scelte sulla base delle necessità specifiche che si
presentano
per le varie attività di stampa.
L e diverse tecnologie hanno portato a misurare la velocità di stampa con diverse unità di misura;
così,
per le stampanti ad impatto, si parla in genere di:
- cps o caratteri per secondo;
- lpm o linee per minuto
per
quanto riguarda invece le stampanti non ad impatto, si parla di:
- ppm o pagine
per minuto;
- ipm o impressioni
per minuto;
- ips o inch per secondo (1 inch = 1 pollice = 2,539 cm);
- fpm o feet per minuto (1 foot = 12 pollici = 30,48 cm)
E’
bene ricordare che le velocità indicate per le stampanti rappresentano una sorta di velocità di
punta
e da queste non si può, in genere, risalire alla capacità di stampa in termini, ad esempio, di
pagine
al mese; questo valore, che dà in qualche modo una misura della affidabilità della
apparecchiatura,
è di solito indicato, sotto forma di “consiglio”, nelle specifiche fornite dal
costruttore
ed è un valore da tenere nella massima considerazione in fase di progetto.
Evoluzione
architetturale
Anche
l’evoluzione delle modalità operative delle stampanti all’interno di un impianto informatico
è stata una storia di disaccoppiamento volta a far pesare il meno possibile la intrinseca lentezza
delle
apparecchiature di stampa nei riguardi del resto delle apparecchiature (principalmente le unità
di
elaborazione) estremamente più veloci.
103

Inizialmente, infatti, le stampanti, come tutte le altre periferiche, avevano un funzionamento del
tutto sincrono con le unità di elaborazione le quali, tra l’altro, dovevano attendere il completamento
delle attività di stampa prima di continuare il proprio lavoro.
Come abbiamo già detto, la gestione delle unità di stampa era effettuata dal software che operava
sulle unità di elaborazione; prima che fossero introdotti i sistemi operativi tale software era proprio
il software applicativo ed al suo interno il programmatore doveva perciò prevedere l’intero
controllo delle stampanti.
Con l’introduzione dei sistemi operativi è stato introdotto un primo livello di disaccoppiamento
liberando
il software applicativo dallo svolgimento delle attività per il controllo diretto delle
stampanti che venivano, invece, gestite dal sistema operativo il quale, tra l’altro, riusciva anche a
mascherare al software applicativo una eventuale variazione del tipo di stampante utilizzata,
consentendo così un più agevole adeguamento tecnologico quando
ciò si rendeva opportuno o
necessario.
Un
successivo livello di disaccoppiamento è stato introdotto con le tecniche di buffering consistenti,
in sostanza, nel dotare le stampanti di una propria memoria in grado di immagazzinare una certa
quantità
di informazioni da stampare liberando l’unità di elaborazione per altre attività; le tecniche
di
buffering sono in genere accoppiate a meccanismi basati su interrupt che consentono alle unità
periferiche
di comunicare con le unità di elaborazione segnalando lo stato di avanzamento della
propria attività e richiedendo
lo svolgimento di specifiche procedure.
A questo punto il processo di stampa si presenta, più o meno,
secondo lo schema seguente
Documento
formattato
spool
Documento
formattato
Data
stream
104

Lo SPOOL (Simultaneous Print Operation On Line) non è altro, in genere, che uno spazio, su una
unità di memorizzazione a disco, dove vengono memorizzati i lavori di stampa provenienti dalle
varie
utenze; la gestione dello spool è a carico del sistema operativo e può consentire anche
funzionalità di gestione molto evolute.
Un ulteriore passo avanti è consistito nel dotare le unità di stampa di capacità elaborative proprie in
grado di svolgere una serie di attività in autonomia quali, ad esempio, la capacità di accettare veri e
propri job di stampa elaborandoli al proprio interno; in questo caso, l’invio di un lavoro in stampa si
realizza, in pratica, attraverso il colloquio tra due unità di elaborazione,
una, la CPU, e l’altra, quella
interna
alla stampante, specializzata per i lavori di stampa.
Lo
schema successivo riassume il processo di stampa nel caso in cui il lavoro di stampa sia, ad
esempio, formattato secondo il linguaggio Postcript e la stampante sia dotata di unità di
elaborazione in grado di comprendere e gestire tale linguaggio.
Documento
postscript
Gestore testi
spool
Printer
postscript
Postscript è un linguaggio, sviluppato dalla società Adobe appartenente alla categoria dei PDL
(Page Description Language); i PDL, rivolti generalmente alle stampanti laser ed inkjet, consentono
di definire in ogni dettaglio la pagina che deve essere stampata tramite informazioni sui fonts, sui
colori, sulle eventuali
immagini, etc.
Un altro linguaggio PDL abbastanza diffuso è il PCL (Printer Control Language) sviluppato dalla
società Hewlett Packard.
Anche nel campo delle stampanti, come in molti altri del settore informatico, le procedure per
potere definire degli standard sono state lunghe e farraginose portando le varie aziende operanti nel
settore
a darsi delle regole, in genere diverse da azienda ad azienda, al fine di poter costruire delle
macchine e delle architetture di stampa che fornissero una certa prospettiva al mercato; non di rado,
105

tra l’altro, le procedure di standardizzazione sono arrivate tardi trovandosi, nella realtà, a confronto
con standard di fatto, cioè sistemi la cui diffusione era tale da farli ritenere “come” uno standard.
Si sono, perciò, diffuse le procedure di emulazione, volte a presentare ai sistemi operativi una
immagine di una determinata stampante “come se fosse” una stampante diversa e “più familiare”;
questo processo si è molto evoluto anche per il fatto che le stampanti sono sempre più dotate di
capacità elaborative proprie, hard disk interni, etc. diventando, talvolta, dei sistemi di elaborazione
delle stampe sui quali operano software specializzati in grado di colloquiare con gli ambienti
applicativi al fine di gestire al meglio le necessità di stampa.
Le unità di stampa in un impianto informatico
Presso gli impianti informatici si è chiamati ad effettuare delle scelte che riguardano sia le
apparecchiature di stampa centralizzate sia quelle via via decentrate fino a raggiungere l’utente
finale; in ogni caso, escludendo le stampe di servizio ad uso interno dell’impianto, i contenuti delle
stampe, i requisiti specifici ed i vari livelli qualitativi richiesti sono scelte aziendali; sulla base di
questi parametri vengono poi effettuate le scelte al fine di ottimizzare i costi.
In altre parole, domande del tipo:
- cosa deve essere stampato, con quale periodicità e da quale fonte;
- dove deve essere stampato;
- con quale livello di qualità devono essere prodotte le stampe (colori, grafica, etc);
- su quali supporti cartacei devono essere prodotte le stampe (formato, qualità, grammatura,
etc.)
sono domande di pertinenza di quei settori aziendali che stabiliscono i criteri ed i requisiti per
assicurare il raggiungimento degli obiettivi di business. Le risposte a queste domande costituiscono
i vincoli entro i quali effettuare le scelte più specificamente informatiche quali:
- tecnologia;
- compatibilità con ambienti software;
- tipo di connessione (connessione diretta a posto di lavoro, connessione in LAN, etc.);
- velocità e capacità di stampa;
- etc.
Infine, sulla base di queste scelte si possono confrontare le varie possibilità offerte dal mercato al
fine di individuare la migliore soluzione dal punto di vista del TCO.
È importante sottolineare che le problematiche di stampa devono essere inquadrate nel più ampio
settore della gestione documentale che riguarda la produzione, l’archiviazione, la ricerca, la
duplicazione, la distribuzione e l’utilizzo dei documenti all’interno delle aziende e tra le aziende ed
il mondo esterno.
La gestione dei documenti induce notevoli costi (stimati da alcuni analisti in circa il 15 % del
fatturato) talvolta difficilmente rilevabili e riconducibili al tema specifico; ciò ha portato alla nascita
di una serie di prodotti software per la gestione documentale che hanno l’obiettivo di gestire i
documenti prevalentemente in formato elettronico e di ottimizzare i costi indotti dalla produzione
delle stampe.
106

La gestione documentale tende, frequentemente, ad avviare una sorta di consolidamento anche per
le risorse di stampa e ad utilizzare apparecchiature multifunzione (fax, scanner, copiatrice e
stampante) per consentire, ove opportuno, la digitalizzazione dei documenti.
Nella
predisposizione di un piano per la gestione documentale
vi è anche la possibilità di affidare a
terzi la gestione di parte dei documenti come, ad esempio, la gestione della corrispondenza (o di
parte di essa) con i propri clienti; POSTEL, per citare il caso più comune, è il servizio di Poste
Italiane volto ad acquisire in outsourcing servizi di produzione e distribuzione di corrispondenza; in
questo caso, Poste Italiane, dopo aver ricevuto dalla azienda cliente i dati, provvede a comporre,
stampare,
imbustare e recapitare i documenti al destinatario
sgravando l’azienda da una parte della
della gestione documentale cui deve far fronte.
107

2.2.3.2 Unità di comunicazione
Gli utenti di un moderno impianto informatico utilizzano i servizi a loro disposizione connettendosi
all’impianto con diverse modalità e da diversi luoghi.
Una prima suddivisione che può essere fatta consiste nel raggrupparli in utenti interni ed utenti
esterni; gli utenti interni sono tutti coloro che appartengono alla stessa azienda o ente cui appartiene
l’impianto; gli utenti esterni sono tutti coloro che utilizzano determinati servizi dell’impianto pur
non facendo parte dell’organico aziendale.
Gli utenti interni, possono risiedere nello stesso luogo dove si trova l’impianto, e si definiscono
locali, o possono trovarsi distanti (remoti) da esso richiedendo, in questo caso, una rete di
comunicazione che consenta l’accesso alle apparecchiature dell’impianto; alcuni utenti interni
operano da postazioni remote e geograficamente stabili (filiali, agenzie, postazioni automatiche,
etc.) mentre altri possono avere la necessità di connettersi da luoghi diversi e costituiscono l’utenza
in genere definita mobile.
Gli utenti esterni rientrano, per lo più, nella categoria degli utenti mobili per quanto non è raro il
caso in cui vi siano utenti
esterni, generalmente non privati ma appartenenti ad altre società, che
accedono da postazioni remote e geograficamente stabili.
Escludendo gli utenti interni locali, tutti gli altri utenti necessitano di reti di comunicazione.
Le reti di comunicazione hanno perciò rivestito un ruolo di cruciale
importanza negli impianti
informatici di ogni epoca. Le unità di comunicazione sono tutte quelle apparecchiature che
gestiscono le reti di comunicazione ottimizzando i livelli di servizio.
Una rete di comunicazione è costituita da linee di comunicazione e da nodi ai quali le linee si
attestano; le unità di comunicazione fanno parte dei nodi e, talvolta, rappresentano esse stesse un
nodo.
Le reti di comunicazione sono diventate sempre più complesse in base al modello di elaborazione
adottato e, corrispondentemente, sono diventate sempre più complesse ed evolute le funzioni
richieste alle unità di comunicazione necessarie per
la gestione.
In u n modello
di elaborazione centralizzato, costituito da un calcolatore (host) e da terminali “non
intelligenti”
connessi ad esso all’interno di un ambito geografico, le unità di comunicazione
potevano non avere, ad esempio, il compito di scegliere il cammino migliore per stabilire una
comunicazione
tra l’host e la sua periferia e potevano assolvere il loro ruolo “semplicemente”
presentando la periferia remota ai sistemi operativi sull’host come qualsiasi altra unità periferica
locale, mascherando, cioè,
la rete di comunicazione e gestendola con le proprie risorse.
In un modello
di elaborazione distribuito, quale il modello client/server, che richiede topologie di
rete
p iù complesse, alle unità di comunicazione sono richieste potenzialità molto più evolute
come,
ad
esempio, la capacità di prendere delle decisioni in maniera dinamica, in dipendenza, cioè, dalla
evoluzione nella disponibilità delle varie risorse della rete.
La storia della evoluzione delle
unità di comunicazione è stata segnata dalla necessità di liberare le
unità
di elaborazione dal compito della gestione diretta delle reti di comunicazione; ciò è stato
ottenuto
introducendo strati, hardware e software, sempre più ampi e con compiti specifici.
108

La evoluzione tecnologica delle unità di comunicazione coincide con la evoluzione delle unità di
elaborazione
e delle unità di memorizzazione in quanto, in definitiva, le unità di comunicazione
sono
elaboratori specializzati per la realizzazione di specifiche funzioni, cioè dotati di opportuni
prodotti
software che consentono lo svolgimento delle attività.
Come
in tutti gli altri casi in cui più componenti di un sistema di elaborazione sono chiamati a
scambiarsi
informazioni, anche le unità di comunicazione devono seguire precise regole affinché il
dialogo, tra unità di comunicazione
e tra queste e le unità di elaborazione, sia possibile ed efficiente;
queste
regole sono i protocolli di comunicazione.
Le
funzioni che devono essere realizzate per consentire la comunicazione tra due punti di una rete
sono
numerose e affrontano tutti i vari aspetti della comunicazione, dagli aspetti puramente elettrici
e meccanici relativi alle connessioni
fisiche, agli aspetti logici, cioè dagli aspetti connessi al
trattamento
di un segnale elettrico su una linea di comunicazione agli aspetti connessi al dialogo tra
due
programmi applicativi.
La
necessità già citata di svincolare le unità di elaborazione ed il suo sistema operativo dallo
svolgimento
delle funzioni di cui si è detto ha portato, intorno agli anni 70, alla nascita delle
architetture
funzionali.
Inoltre,
la varietà delle funzioni che devono essere svolte per consentire la comunicazione, ha
consigliato
di raggruppare queste funzioni in una struttura gerarchica in modo da rendere, per
quanto possibile, ciascun gruppo di funzioni indipendente dagli altri e, perciò, indipendente, per
quanto possibile, dalle evoluzioni degli altri gruppi di funzioni.
Nascevano così le architetture funzionali strutturate in livelli o strati gerarchici ciascuno dei quali si
occupava di svolgere un determinato
gruppo di funzioni.
Come spesso è avvenuto nel campo informatico, la mancanza di tempestive ed efficaci attività di
standardizzazione ha portato alla nascita di tante architetture funzionali quanti erano i principali
produttori;
successivamente, data la diffusione di realtà sempre più eterogenee e la conseguente
necessità di comunicazione tra diverse architetture, sono state messe a punto tecnologie hardware e
software in grado di consentire la comunicazione tra ambienti sostanzialmente differenti.
La
suddivisione in strati consente perciò:
- di modificare uno strato apportando ad esso dei miglioramenti prestazionali e/o consentendo
ad esso il supporto di nuove tecnologie mantenendo tendenzialmente immutati gli altri strati;
- di impiegare protocolli diversi per i vari strati in base alle funzioni effettivamente svolte.
In sostanza ogni strato :
- fornisce allo strato superiore il servizio di cui quest’ultimo
necessita
- conta sul fatto che la catena degli strati inferiori gli fornisca i servizi necessari.
In sostanza
il livello n, che dialoga con il corrispondente livello n del nodo con cui deve instaurare
una comunicazione, rappresenta il service
provider del livello n+1 e, contemporaneamente, è il
service
user del livello n-1.
109

Livello n + 1
Livello n
Livello n - 1
La linea che nello schema precedente unisce livelli analoghi di due nodi differenti è tratteggiata in
quanto la comunicazione tra i due livelli avviene direttamente solo da un punto di vista logico ma,
realmente, la comunicazione si realizza tramite l’attraversamento di tutti gli strati di livello più
basso fino al livello 1, o livello fisico, che è l’unico livello fisicamente interconnesso agli
equivalenti livelli degli altri nodi.
Come
detto, la maggior parte dei produttori, a partire dagli anni 70, ha studiato ed introdotto sul
mercato architetture funzionali idonee a supportare il proprio ambiente di comunicazione.
Naturalmente, ciascuna architettura funzionale, era particolarmente indicata per svolgere le funzioni
di comunicazione all’interno della più ampia modalità di elaborazione che ciascun
produttore
prediligeva.
Così, a titolo di esempio,
- la architettura SNA (Systems Network
Architecture) della IBM che ottimizza le
problematiche di gestione della rete in un modello di calcolo basato su grandi mainframe
dotati di enormi reti gerarchiche
di terminali geograficamente sparsi;
- la architettura
DNA (Digital Network Architecture) della Digital Equipment Corporation
che era più orientata alla gestione di reti in cui diverse unità di elaborazione erano chiamate
a comunicare in modo sostanzialmente paritario;
- la architettura DoD (che trae il suo nome dal Department of Defense statunitense in quanto
nasceva dalla esperienza della rete Arpanet, successivamente evolutasi nella attuale Internet,
voluta appunto dal Dipartimento della Difesa degli Stati Uniti) nota anche come TCP/IP
Suite o Internet Protocol Suite.
Altre architetture di rete erano:
Protocollo del livello n + 1
Protocollo del livello n
Protocollo del livello n - 1
- XNS (Xerox Network System) della società Xerox
Livello n + 1
Livello n
Livello n - 1
110

- WANGnet della società WANG
- AdvanceNet della società Hewlett Packard
- Burroughs Network Architecture della società Burroughs
- etc.
La nascita delle varie architetture funzionali insieme alle necessità sempre maggiori di
omogeneizzare
il settore delle reti telematiche che diventava sempre più eterogeneo ha portato alla
definizione del ben noto modello OSI (Open System Interconnection) con i suoi 7 strati funzionali;
OSI, come
detto, è un modello di riferimento che stabilisce le funzioni di ciascun livello e,
conseguentemente, quali servizi ciascun livello deve fornire al livello superiore e quali
servizi deve
attendersi
dal livello inferiore.
In questo quadro, le apparecchiature di comunicazione (quali routers, switch, unità di controllo,
etc.) svolgono le funzioni di uno o più livelli della architettura di comunicazione.
La letteratura tecnica nel campo delle reti è molto completa e perciò, in questa sede, non si entrerà
nei dettagli delle varie unità di comunicazione.
Si desidera solo evidenziare che la evoluzione delle reti di comunicazione non ha portato alla
scomparsa di modelli di comunicazione “antichi” i quali, al contrario, sono spesso ancora richiesti
per consentire l’utilizzo di modelli di elaborazione datati ma ancora in uso; ad esempio, per
consentire l’uso di prodotti software scritti per un modello di elaborazione che prevedeva l’impiego
di terminali non intelligenti connessi a minicomputer o mainframe, può ancora essere necessario
che un personal computer, che rappresenta il terminale intelligente odierno con potenzialità ben
superiori a quelle di semplici terminali non intelligenti oggi praticamente non più prodotti, si
presenti al software cui deve accedere “come se fosse”, appunto, un terminale non intelligente; in
altri termini, emulando le caratteristiche di una determinata famiglia di terminali non intelligenti.
Così, è frequente, specie presso gli impianti di dimensioni medio-grandi che hanno in genere una
storia di diversi decenni alle spalle, imbattersi in sigle del tipo “emulazione VT100” o “emulazione
3270” che fanno riferimento, rispettivamente, ad una famiglia di terminali tipica degli ambienti
Digital e ad una famiglia di terminali tipica degli ambienti IBM mainframe.
Gli specialisti che operano all’interno di un impianto informatico nell’area reti devono misurarsi
con diverse problematiche:
- ottimizzare la affidabilità della rete
- garantire un livello di sicurezza adeguato
- garantire prestazioni adeguate
- etc.
Il problema delle prestazioni è particolarmente complesso in quelle realtà che, per il modello di
business adottato, sono soggette a variazioni di carico ampie e talvolta imprevedibili; si pensi, ad
esempio, a quelle realtà dove è prevista la fornitura di servizi ad utenti esterni via internet; in questi
casi il dimensionamento delle apparecchiature di comunicazione è complesso e, ove disponibili, è
opportuno dotarsi di strumenti software di servizio in grado di monitorare costantemente le
prestazioni, individuare quanto più possibile in anticipo eventuali situazioni di sovraccarico ed
avviare le opportune azioni correttive.
111

Strumenti software di questo genere fanno parte della più ampia famiglia degli strumenti di ausilio
alla
gestione (di cui si accennerà più avanti nel capitolo dedicato al Software)
il cui impiego, anche
in aree differenti dalla gestione delle reti di comunicazione, ha come obiettivo strategico il
cosiddetto
Autonomic Computing cioè la creazion
e di ambienti tendenzialmente
in grado di
effettuare automaticamente, cioè senza intervento
umano se non nella
stesura degli obiettivi che si
intendono raggiungere, una serie di attività quali:
- “apprendimento” delle varie situazioni di funzionamento in base alle quali riuscire a fare
previsioni per il futuro
- riconfigurazione dinamica delle risorse in modo tale da prevenire, ove possibile, situazioni
di sovraccarico in grado di compromettere obiettivi di prestazione specifici.
112

ALTRE UNITA’ – Domande di verifica
1 le stampanti ad impatto rispetto alle stampanti
non ad impatto comportano in genere
minore qualità di stampa
maggiore qualità di stampa
uguale qualità di stampa
Commenti: ……………………………………………………………………………………
………………………………………………………………………………………………..
2 le stampanti ad impatto hanno solitamente dei stampe di massa
limiti nella produzione di
immagini
fatture commerciali
Commenti: ……………………………………………………………………………………
………………………………………………………………………………………………..
3
le stampanti ad impatto sono necessarie per la
stampa su
carta a modulo continuo
carta a foglio singolo
carta copiativa multicopia
Commenti: …………………………………………………………………………………… ………………………………………………………………………………………………..
4 nell'area delle stampanti sono definite fax, storage nastro,
multifunzione quelle apparecchiature che scanner e stampante
inglobano le funzioni
copiatrice, lettore di codice
a barre, stampante
stampante, fax, scanner,
copiatrice
Commenti: ……………………………………………………………………………………
………………………………………………………………………………………………..
113

5 POSTSCRIPT è uno dei più diffusi linguaggi per ambienti
scientifici
middleware di gestione
dello SPOOL
linguaggi per descrizione
di pagine (PDL)
Commenti: ……………………………………………………………………………………
………………………………………………………………………………………… ……..
6 lo SPOOL è
un'area di storage in cui
vengono posti i files di stampa
un tipo di stampante
l'outsourcing delle stampe
Commenti: ……………………………………………………………………………………
………………………………………………………………………………………………..
7 nel caso in cui una azienda abbia la necessità un outsourcing delle
di produrre stampe di elevata qualità in quantità
limitata e tale da non giustificare l'acquisto delle
stampe
sofisticate apparecchiature necessarie, può
ricorrere ad
u na stampante ad impatto
un Postscript aggiornato
Commenti: ……………………………………………………………………………………
………………………………………………………………………………………………..
8
nella scelta delle stampanti per posto di lavoro, dal costo di acquisto della
il TCO può essere fortemente influenzato stampante
dal costo dei materiali di
consumo(nastri, cartucce,
toner, etc.)
dal costo di uscita
Commenti: ……………………………………………………………………………………
………………………………………………………………………………………………..
114

9 le problematiche connesse alle stampe si lo storage consolidation
inquadrano nel più ampio argomento che tratta
il servless backup
la gestione documentale
Commenti: ……………………………………………………………………………………
………………………………………………………………………………………………..
10 nelle architetture funzionali di rete livelli direttamente
equivalenti su due nodi differenti dialogano
usufruendo di opportuni
servizi dei livelli inferiori
(tranne i più bassi che
dialogano direttamente)
usufruendo di opportuni
servizi dei livelli superiori
(tranne i più alti che
dialogano direttamente)
Commenti: …………………………………………………………………………………… ………………………………………………………………………………………… ……..
11 la architettura funzionale SNA rispecchia una
architettura di calcolo
peer to p eer
gerarchica
multicentrica
Commenti: ……………………………………………………………………………………
………………………………………………………………………………………………..
12
la architettura funzionale DNA rispecchia una
architettura di calcolo
peer to peer
gerarchica
multicentrica
Commenti: ……………………………………………………………………………………
………………………………………………………………………………………………..
115

13
l'impiego di prodotti software applicativi datati può
richiedere l'utilizzo di
personale specializzato
prodotti per la emulazione di
terminali
speciali apparecchiture
ausiliarie
Commenti: ……………………………………………………………………………………
………………………………………………………………………………………………..
14
una rete di comunicazione è costituita da nodi e linee di comunicazione
personal computer
mainframe
Commenti:
……………………………………………………………………………………
………………………………………………………………………………………………..
15
internet è una evoluzione di SNA
DNA
Arpanet
Commenti: ……………………………………………………………………………………
………………………………………………………………………………………………..
116

3 IL SOFTWARE
Obiettivi del capitolo
- conoscere le componenti Software di un impianto informatico
- comprendere le relazioni tra le componenti Software
- comprendere la necessità di disporre di ambienti Software aggiornati
- conoscere le modalità di aggiornamento dei prodotti Software
- capire le differenze tra software FREE, OPEN SOURCE e PROPRIETARIO
- conoscere la struttura dei costi dei prodotti Software
117

3.1 Generalità
L’insieme
dei prodotti software presenti in un impianto informatico può essere imponente e di
conseguenza
le attività di progettazione, realizzazione e gestione dei prodotti software costituiscono
un
onere piuttosto gravoso.
Nella
realizzazione dei componenti hardware di un impianto informatico ci si trova talvolta di
fronte
a fenomeni fisici che se da una parte limitano le possibili scelte progettuali, dall’altra
impongono
una certa tendenza evolutiva; nel campo del software, invece, l’unico limite è la fantasia
umana
e ciò, spesso, ha portato a realizzazioni del tutto divergenti che, a loro volta, hanno indotto la
necessità
di realizzare ulteriori prodotti in grado, ad esempio, di rendere compatibili cose, di per sé,
molto
dissimili non solo dal punto di vista della tecnica di realizzazione ma anche dal punto di vista
della
logica progettuale.
In altre parole, nel campo del software, proprio perché non sono presenti limiti fisici oggettivi, sono
ammissibili tutte le correnti di pensiero che riescono ad avere una certa penetrazione sul mercato
(anzi, in realtà, diventano “più ammissibili” quelle correnti di pensiero che hanno una maggiore
penetrazione sul mercato arrivando
anche a costituire uno standard di fatto); poiché, però, prima o
poi,
nasce la necessità di una qualche forma di dialogo tra le varie correnti di pensiero, ecco che si
rende
necessario un altro pezzetto di software che “adatti” il tutto coprendo le varie differenze; e
così
via fino a costituire un panorama di forte complessità.
Questa
situazione è aggravata dal fatto che, poiché i costi connessi allo sviluppo del software sono
piuttosto
elevati in quanto, a differenza del settore hardware dove i processi di produzione hanno
visto
ridursi sempre più la componente umana, ancora fortemente condizionati dall’impiego delle
risorse
umane, vi è la generale tendenza a continuare ad utilizzare prodotti software ormai datati
consentendone,
tra l’altro, l’integrazione in architetture più moderne tramite la realizzazione, ancora
una
volta, di specifici componenti.
Se a ciò si aggiunge che le correnti di pensiero di cui si diceva sono talvolta originate da ambienti
che poco o nulla hanno avuto a che fare con le problematiche pratiche di un impianto informatico
che, si ricorda, ha come unico obiettivo quello di dare ai suoi utenti un servizio economicamente
sostenibile e quanto più possibile affidabile, sicuro e adeguato nelle prestazioni, si può comprendere
come il mondo del software possa diventare un vero grattacapo per chi è chiamato a gestirlo.
Una prima suddivisione abbastanza intuitiva dei prodotti software può essere effettuata nelle
seguenti
tre grandi aree:
- software di base, ovverosia i sistemi operativi;
- software middleware, ovverosia tutto ciò che non appartiene alle altre due categorie;
- software applicativo, ovverosia tutto quel software che svolge una specifica attività e che in
genere è impiegato dagli utenti finali dell’impianto
Si
precisa che, specie tra software di base e middleware, le aree di appartenenza di determinati
prodotti
possono essere diversamente assegnate, tuttavia al livello di approfondimento del presente
testo
la suddivisione riportata si ritiene possa costituire una utile traccia di riferimento.
Il complesso mondo del software si può graficamente rappresentare con lo schema seguente
118

Sistema operativo
HARDWARE
Come abbiamo avuto modo
di dire quando sono state descritte le varie modalità di elaborazione, la
situazione
rappresentata non era quella effettiva agli albori della informatica moderna; allora infatti,
le cose stavano più o meno così
HARDWARE
Software applicativo
Middleware
Software applicativo
Il software applicativo doveva interfacciarsi direttamente con l’hardware e quindi doveva disporre
al suo interno di tutto ciò che era necessario per inviare i comandi, nel massimo dettaglio, ai
componenti hardware stessi; qualsiasi variazione nell’ hardware richiedeva, perciò, una revisione
del software; il programmatore doveva intendersi anche di argomenti piuttosto estranei alle
problematiche di programmazione come le intendiamo oggi; d’altra parte chi programmava in quel
periodo era spesso chi aveva collaborato al progetto del sistema complessivo, chi ne effettuava la
manutenzione e, frequentemente, anche l’utente finale.
L’introduzione dei sistemi operativi ha modificato la situazione nel seguente modo
Sistema operativo
HARDWARE
Software applicativo
119

In questo modo si ottenevano diversi vantaggi tra i quali
- l’hardware, che era una risorsa molto più “rara” e pregiata di oggi, veniva gestito in modo
ottimale in quanto i sistemi operativi erano, e sono, messi a punto da specialisti;
- il programmatore applicativo poteva concentrarsi
sul suo compito specifico dovendo
interfacciarsi
non più con la macchina fisica ma con una sua astrazione molto più semplice
da gestire e molto più
stabile nei riguardi di modifiche hardware
Tuttavi a, il software applicativo doveva ancora occuparsi di argomenti estranei al mondo
applica
tivo vero e proprio quali, ad esempio, il controllo degli accessi e della attività degli utenti, la
gestione dettagliata dello scambio di informazioni con altri programmi, la gestione logica dei dati,
etc.
Allo stesso tempo, la gestione del sistema di calcolo, in termini di controllo delle prestazioni,
schedulazione dei lavori, etc., richiedeva degli strumenti che consentissero di organizzare le attività
in modo più efficiente.
A tale scopo, nel tempo, sono stati messi a punto numerosi prodotti middleware, componendo così
lo schema riportato all’inizio di questo capitolo. I prodotti middleware, in sostanza, svolgono
attività di supporto ai software applicativi e alla gestione dell’impianto.
È bene precisare ancora che le zone di confine tra le varie aree riportate nello schema non sono, in
realtà, nette e rettilinee; inoltre, la distinzione tra le varie aree potrebbe far pensare ad una sorta di
compatibilità
tra middleware
diversi ed un sistema operativo, tra ogni software applicativo ed ogni
middleware,
e così via. Le cose non stanno così e, se si volesse realizzare una rappresentazione
grafic a più vicina al vero, si dovrebbe riportare una struttura tridimensionale
a puzzle i cui singoli
pezzi provengono da puzzle diversi e necessitano
perciò di adattamenti
(in sostanza di altre tessere)
per poter realizzare un collegamento stabile e funzionale.
120

3.2 Software di base
Come già detto, i sistemi operativi svolgono un ruolo di interfaccia tra l’hardware ed il mondo
esterno. In sostanza provvedono alla gestione di:
- processori;
- memoria centrale;
- memorie di massa;
- dispositivi di Input/Output
ottimizzandone
il funzionamento e presentando all’esterno una sorta di immagine virtuale del
mondo fisico gestito.
Sfortunatamente, come per quasi tutte le aree che fanno parte dell’ information technology, i sistemi
operativi non si sono sviluppati sulla base di standard o di altri concetti in qualche modo unificatori
la cui presenza, almeno per quanto riguarda la parte di interfaccia verso l’esterno, avrebbe
semplificato
di molto le cose; al contrario, ogni attore del settore ha operato per lo più in assoluta
autonomia
proteggendo, anzi, il frutto del proprio lavoro; ciò ha portato alla costituzione di standard
di fatto che si sono affermati in maniera direttamente proporzionale alla diffusione dei vari prodotti
sul
mercato.
I principali sistemi operativi che si possono trovare installati presso gli impianti informatici general
purpose sono:
- Per gli ambienti server mainframe
o MVS (Multiple Virtual Storage) OS/390 z/OS
o VM (Virtual Machine) z/VM
o VSE (Virtual Storage Extended)
- Per gli ambienti server intermedi e minicomputer
o LINUX
o UNIX
o IBM OS/400
o MAC OS per Server
- Per ambienti server medio-piccoli
o WINDOWS
o MAC OS
- Per ambienti workstation
o UNIX
o SOLARIS
- Per posti di lavoro
o WINDOWS
La suddivisione riportata è orientativa anche se rispecchia abbastanza fedelmente la realtà.
Mentre
alcuni dei sistemi operativi
citati (quali ad esempio quelli in area mainframe) sono costituiti
da un o specifico prodotto, per quanto estremamente variabile in termini di componenti, altri
rappresentano in realtà una famiglia di prodotti all’interno della quale sono presenti un certo
numero di sistemi operativi talvolta anche piuttosto differenti.
In altre parole, se il VSE o lo z/OS
individuano una precisa piattaforma software, UNIX, ad esempio, richiede qualche ulteriore
specificazione per individuare una precisa piattaforma.
121

I sistem i operativi in area mainframe indicati sopra sono di proprietà della IBM e sono, in effetti, i
sistemi più istallati in area mainframe per uso commerciale, sia
su hardware mainframe IBM sia su
hardware mainframe (talvolta definiti mainframe
IBM-compatibili) di altri costruttori (Hitachi,
Amdahl, etc.). Nell’elenco sono riportati i nomi, per dir così, storici di
questi sistemi operativi ed i
nomi delle loro più moderne evoluzioni, tralasciando una serie di passi
intermedi che talvolta hanno
comunque
incluso delle sostanziali innovazioni rispetto ai predecessori.
Tra i sistemi operativi per mainframe
- l’ MVS ed i suoi successori, ultimo in ordine di tempo lo z/OS, sono sicuramente i più
diffusi nelle grandi e grandissime installazioni; questo sistema dispone di un grande numero
di funzioni di controllo e gestione e sono disponibili per esso prodotti di servizio messi a
punto da diverse società di sviluppo software di primaria importanza;
- il VSE è particolarmente rivolto ad impianti informatici di media dimensione e la sua
diffusione ha risentito della proliferazione di piattaforme server differenti
in questa area;
- il VM è il sistema operativo più impiegato laddove vi sia la necessità di disporre di un
elevato numero di sistemi di elaborazione virtuali, cioè simulati su un unico sistema di
elaborazione fisico, assicurando singoli ambienti
sicuri e protetti; per assolvere
completamente a questa funziona il VM ha anche la capacità di ospitare altri sistemi
operativi quali z/OS e VSE e, recentemente, anche LINUX.
Un maggiore approfondimento sui sistemi operativi IBM per mainframe è riportato nella appendice
(Appendice G - Sistemi Operativi per i Sistemi Centrali-Mainframes) messa a punto dal Dott. A.
Barbarino specialista della IBM Italia spa.
Il precursore dei sistemi operativi UNIX è stato sviluppato da alcuni programmatori dei laboratori
BELL e da allora si è evoluto secondo diverse linee di sviluppo tra le quali si ricordano
- UNIX System V della AT&T
- UNIX BSD 4.2 della Università di Berkeley
LINUX si è andato diffondendo negli ultimi anni e rappresenta in qualche modo l’esempio più
citato di ambiente
software OPEN in contrapposizione ad ambienti software PROPRIETARIO dei
quali
non sono disponibili i codici sorgente del sistema e non è quindi possibile apportarvi alcuna
modifica né conoscere la loro struttura.
La suddivisione dei sistemi operativi in base alle dimensioni dell’ambiente server relativo è, come
già detto, orientativa e, probabilmente, destinata a modificarsi nel tempo. L’area che sembra
rappresentare, al momento attuale, il campo di competizione più aperto è quella dei server intermedi
dove
diverse ditte stanno cercando di imporsi.
Dal punto di vista di chi è chiamato a scegliere il sistema operativo da adottare per le sue specifiche
necessità, nella ipotesi in cui la scelta non sia obbligata da altri vincoli quali ad esempio la
disponibilità o l’obbligo di usare specifici software applicativi legati ad un determinato ambiente,
gli elementi da considerare sono:
- l’ambiente già esistente, se ve ne è uno, dal quale possono essere ricavate conoscenze ed
esperienze che possono utilmente essere impiegate;
- la strategia, se ve ne è una, dell’ente o dell’azienda per la quale si opera che può prevedere
una convergenza verso un ambiente operativo o verso un numero limitato di ambienti;
- i carichi di lavoro previsti per soddisfare le proprie necessità;
122

- i livelli di servizio che si intendono raggiungere;
- la disponibilità di software middleware e di gestione;
- le potenzialità dei vari sistemi operativi;
- la disponibilità di affidabili strutture di supporto ed assistenza;
- il rapporto costo/benefici ottenibile con le varie soluzioni;
- le necessità e/o le opportunità di comunicazione con altre realtà.
Ciascuno di questi punti dovrebbe contribuire ad una scelta per quanto possibile libera da pregiudizi
e non condizionata da mode o tendenze che possono rivelarsi effimere.
A tale proposito, si ritiene opportuno ribadire il concetto che, come già detto altrove, l’obiettivo
unico di un impianto informatico general purpose è, in estrema sintesi, quello di
fornire ai propri
utenti
un servizio che rispetti i livelli qualitativi richiesti ottimizzando il relativo TCO;
conseguentemente, tutte le scelte devono essere fatte tenendo sempre ben presente questo obiettivo
e valutando ogni cosa prescindendo da emotività, “simpatie” o “antipatie”.
Operando all’interno di un impianto informatico, oltre alla scelta, rivestono particolare importanza
le attività di gestione e manutenzione
del sistema operativo.
Infatti, i vari sistemi operativi subiscono continuamente delle modifiche sia per incrementarne le
funzioni sia per rendere più efficienti le funzioni già esistenti o, anche, per risolvere eventuali
malfunzionamenti che si dovessero presentare. È molto importante, perciò, conoscere esattamente
con quale livello di aggiornamento del proprio sistema operativo si sta lavorando o, più
specificamente, conoscere di quale versione/livello si dispone.
Si
parla così, ad esempio, di Windows 3.1, z/OS 1.6, e così via; il primo dei due numeri indica
generalmente la Versione del sistema operativo mentre il secondo numero indica la Release del
sistema operativo all’interno di quella versione; all’interno di una medesima release possono esserci
differenti stati di aggiornamento.
Come è intuitivo versioni diverse di un medesimo sistema operativo contengono, normalmente,
differenze
di entità più consistente rispetto a quelle presenti tra due release all’interno della stessa
versione.
Ogni fornitore di sistemi operativi garantisce in genere assistenza ad un certo numero di
versioni/release di un sistema operativo; ciò, sostanzialmente, vuol dire che accetta e gestisce le
segnalazioni di eventuali malfunzioni nel modo più tempestivo possibile; le versioni/release per le
quali non è più garantito il supporto (definite in genere back level) vengono comunicate con un
notevole anticipo
per dare modo agli interessati di effettuare le operazioni di migrazione necessarie.
Solitamente, eventuali malfunzionamenti su versioni/release back level possono anche essere risolti
dal fornitore, ad esempio sulla base di analoghe problematiche verificatesi altrove e già risolte,
tuttavia per lo più manca un impegno formale alla risoluzione del problema.
Ciò è dovuto al fatto
che
per l’esame e la risoluzione di un problema, di norma, il fornitore ha la necessità, ad esempio, di
riprodurre il problema stesso presso i propri laboratori; ciò implica la disponibilità presso i
laboratori degli ambienti informatici corrispondenti che però, dopo un certo tempo, non è più
assicurata.
A questo proposito, è importante sottolineare che un malfunzionamento sarà risolto tanto più
velocemente quanto più sono precise e definite le condizioni durante le quali la malfunzione si è
presentata consentendo così, se necessario, la ricostruzione del problema in laboratorio.
123

La rilevazione delle condizioni in cui si è verificato un malfunzionamento, spesso fornita da
prodotti software di supporto alla gestione, può richiedere tempo e ciò in genere contrasta con le
aspettative di continuità di servizio a livello aziendale.
Si tratta perciò di operare una sorta di compromesso tra la necessità di far ripartire al più presto le
attività coinvolte dal problema e la necessità di fornire al manutentore le informazioni necessarie a
fissare (cioè a risolvere) il problema; in generale, bisogna che vi sia la consapevolezza, non solo a
livello tecnico dove questa consapevolezza si suppone presente, ma anche a livello del management
aziendale, che è primario intereresse quello di creare le condizioni affinché il disservizio sia
individuato e risolto piuttosto che affrettare le procedure di ripartenza distruggendo talvolta
preziose informazioni in grado di agevolare la soluzione definitiva del problema.
In definitiva, la prassi piuttosto comune, specie in determinati ambienti operativi, e addirittura
talvolta suggerita, di risolvere un problema facendo “ripartire il sistema” (prassi alla quale
comunemente ci si riferisce elencando la serie di tasti da premere per effettuare la ripartenza del
sistema operativo) è la via migliore per far si che il problema non venga risolto e che, molto
probabilmente,
si ripresenti.
In generale, un malfunzionamento di un sistema operativo è da considerare alla stregua di un
“disastro” e perciò si devono predisporre le relative procedure operative da eseguire al fine di
consentire agli addetti di svolgere prontamente le azioni più opportune; tra queste, le ultime
dovrebbero essere quelle necessarie alla ripartenza del sistema e dovrebbero
essere precedute dalle
azioni
volte a rilevare, con il maggiore dettaglio possibile, lo stato che ha condotto al
malfunzionamento stesso.
Una delle prime cose da fare quando si comincia una attività lavorativa presso un impianto
informatico è quella di confrontare il livello di aggiornamento del software di base con il cosiddetto
livello corrente di quel sistema operativo, intendendo con livello corrente l’ultimo livello reso
disponibile dal fornitore per le normali installazioni, e con i vari livelli che, pur non essendo
correnti nel senso appena detto, godono comunque della regolare assistenza da parte del fornitore.
Questo semplice esame consente di farsi una prima
idea sull’andamento delle attività presso
l’ impianto informatico; nella realtà, non sempre presso gli impianti informatici si trovano installati i
livelli correnti dei sistemi operativi; in buona parte dei casi ci si trova di fronte a versioni/livelli non
correnti ma comunque supportati (cioè assistiti dai relativi fornitori), in alcuni casi, invece, ci si
trova
di fronte a versioni/livelli back level; quest’ultima, ovviamente, è una situazione di rischio
potenziale specie in ambienti complessi dove diversi prodotti software di diversi fornitori si trovano
a coesistere.
L’aggiornamento dei sistemi operativi è una attività che viene decisa e schedulata all’interno
dell’impianto informatico sulla base di una attenta analisi dell’insieme dei prodotti hardware e
software installati o di cui è prevista la installazione o la dismissione.
Presso
gli impianti medio-grandi questa analisi è, di solito, condotta in collaborazione con il
fornitore del sistema operativo e con gli altri fornitori, principalmente di prodotti software, al fine di
effettuare le varie verifiche di compatibilità e di quantificare il carico di lavoro indotto dall’attività.
Ufficialmente, ciascun fornitore rende note per un dato prodotto le compatibilità con altri prodotti;
ad
esempio, un fornitore che produce un middleware per un ambiente operativo z/OS renderà
pubbliche le versioni/livelli di z/OS necessarie per assicurare la corretta funzionalità del proprio
124

prodotto in una certa versione/livello; un fornitore che produce una certa apparecchiatura periferica,
oltre alle compatibilità di tipo hardware, renderà pubblici gli ambienti operativi, in termini di
sistema/i
operativo/i con rispettivi versione/livello, per consentire la corretta operatività della
apparecchiatura.
In genere ciò non implica che tutto ciò che non è ufficialmente affermato è realmente non
funzionante (per fortuna, diranno la maggior parte degli IT manager, visto che se così fosse quasi
tutti i centri di calcolo sarebbero fermi, compresi, forse, anche quelli dei produttori di software)
bensì implica, normalmente, che tutto ciò che è ufficialmente affermato è stato testato ed è perciò
garantito; tutte
le altre combinazioni non sono state sottoposte a specifici test da parte dei costruttori
e perciò onori (pochi) ed oneri (spesso tanti) sono a carico di chi le usa e non viene garantito da
nessuno il superamento di eventuali situazioni di malfunzionamento.
Si ritiene di dover richiamare l’attenzione su questi aspetti in quanto, se, da un lato, è vero che
spesso non vi sono motivazioni tecniche per far dubitare di certe compatibilità, dall’altro lato, è
buona norma di carattere generale muoversi all’interno di solchi già tracciati per evitare di trovarsi
all’improvviso di fronte ad un ostacolo sconosciuto.
Si evidenzia, inoltre, che ad alcuni fornitori è possibile richiedere, per periodi più o meno lunghi, il
supporto di situazioni fuori dalla norma; un tale servizio può essere rifiutato o concesso, ed in
questo caso, può essere gratuito o meno in base all’impegno cui il fornitore va incontro per
assicurare il servizio richiesto; ad ogni modo, è una possibilità da non trascurare in ambienti che,
d’altra parte, diventano sempre più complessi ed interdipendenti.
Operativamente, una nuova versione di un sistema operativo è inizialmente installata in test e solo
successivamente, dopo aver verificato la positiva inseribilità e/o dopo avere effettuato le azioni
necessarie, è resa disponibile negli ambienti di lavoro effettivi, generalmente chiamati “ambienti di
produzione”; per consentire questa organizzazione è necessario disporre di strumenti idonei a
mantenere contemporaneamente, o, come si dice, in parallelo, due o più ambienti operativi distinti
basati su medesime apparecchiature hardware o su apparecchiature duplicate; infatti, non è mai una
buona idea quella di svolgere test e sperimentazioni sugli ambienti di produzione mentre l’utenza
svolge le proprie attività né, tanto meno, è ipotizzabile, nella generalità dei casi, bloccare i servizi
per consentire lo svolgimento di attività tecniche.
Come per tutti gli altri prodotti software, da qualche anno si discute con sempre più insistenza di
software cosiddetto OPEN e di software PROPRIETARIO.
Un sistema operativo Open, il più famoso dei quali è LINUX, è un sistema operativo del quale, o di
parte del quale, sono disponibili i codici sorgente che, perciò, possono essere modificati a
piacimento per rispondere a specifiche esigenze; più avanti si parlerà in modo un poco più
dettagliato di software OPEN, ad ogni modo si precisa che OPEN non è sinonimo di “a costo zero”,
il concetto di OPEN non implica che il medesimo codice sorgente si possa riportare “brutalmente”
su qualsiasi piattaforma hardware né che per la acquisizione di un prodotto OPEN non sia
necessario sottostare a determinate condizioni contrattuali.
Un sistema operativo PROPRIETARIO, invece, è un sistema operativo del quale sono disponibili
solo i codici eseguibili mentre i codici sorgente non sono pubblici ed, anzi, sono segreti e molto
gelosamente coperti da copyright; il concetto di PROPRIETARIO non implica che il prodotto
debba avere un costo.
125

Sono sistemi operativi proprietari i sistemi indicati sopra come sistemi operativi IBM per
mainframe, WINDOWS nelle sue varie versioni, ed altri.
Nel caso dei sistemi operativi OPEN, quanto detto a proposito delle verifiche su versioni e release,
su up-grade e su compatibilità può risultare più complesso da realizzare in quanto i sistemi OPEN,
per loro natura, non sono sotto il controllo di un fornitore; in questi casi, in genere, un fornitore si
occupa
di approntare un subset più o meno ristretto del sistema operativo il cui adattamento e/o
completamento è spesso effettuato direttamente dall’utente che può scegliere all’interno di una
vasta gamma di utilities, sottoprogrammi, middleware, etc. sulla base delle proprie necessità e
preferenze.
126

3.3 Middleware
Com e abbiamo visto, il numero di sistemi operativi differenti è limitato, anzi, pur comprendendo le
varie mutazioni più conosciute di quei sistemi operativi che, essendo disponibili anche nel formato
sorgente, si prestano ad essere modificati, non si arriverebbe oltre qualche decina.
I prodotti middleware, invece, sono in quantità molto più rilevante ed i fornitori di questi prodotti
costituiscono uno scenario molto ricco e variegato poiché a produrre prodotti middleware non sono
solo i produttori di sistemi operativi ma anche altre società, talvolta di portata multinazionale,
fortemente specializzate e con rilevante esperienza.
L’ esistenza di una pluralità di fornitori
di middleware, distinti dai fornitori di sistemi operativi, è
protetta anche dalle più generali norme legali che tendono ad assicurare la realizzazione di
situazioni concorrenziali; proprio su questo argomento, a livello mondiale, sono in corso vivaci
dispute.
Il problema base è se sia commercialmente lecito, da parte dei produttori di sistemi operativi,
fornire dei prodotti middleware, e quindi, in sostanza, distinti dal sistema operativo, all’interno del
sistema
operativo stesso senza un relativo costo
specifico o con costi simbolici, spiazzando
commercialmente coloro i quali producono esclusivamente prodotti middleware più o meno
analoghi.
Nell’area dei mainframe è del tutto comune la presenza di fornitori di prodotti middleware distinti
dal fornitore del sistema operativo.
I prodotti middleware vanno a soddisfare necessità di tipo applicativo così come necessità di
gestione e controllo dei sistemi. La grande varietà di obiettivi cui fanno fronte questi prodotti ha
portato
ad avere diverse definizioni per essi;
tra le più originali vi sono le seguenti:
- tutto il software che è rappresentato dalla / nella definizione client/server; ed in effetti la
famiglia di middleware di supporto alle elaborazioni distribuite non potrebbe avere una
definizione migliore;
- il middleware è tutto quel software che nessuno vorrebbe pagare per averlo; in questa
definizione traspare la scarsa visibilità, per i non addetti ai lavori,
della importanza di questi
prodotti e dei risparmi che possono indurre in termini di tempo e quindi di denaro nello
sviluppo applicativo così come nella gestione dei sistemi.
Per quanto riguarda il software middleware a supporto del software applicativo si tratta, in sostanza,
di prodotti
che svolgono delle funzioni, originariamente incluse nelle applicazioni e perciò a carico
del programmatore,
abbastanza generali da rendere consigliabile la loro costituzione in entità a se
stanti più
o meno facilmente richiamabili dalle applicazioni vere e proprie per svolgere il loro
serviz io.
I vantaggi
di un tale approccio sono :
- una maggiore efficienza nello svolgimento delle funzioni interessate grazie al fatto che a
sviluppare questi prodotti sono degli specialisti dei vari settori specifici;
- una migliore portabilità
delle applicazioni tra ambienti operativi differenti per i quali è
disponibile
lo stesso middleware, opportunamente “personalizzato”;
127

- la possibilità per i programmatori applicativi di focalizzare la loro attenzione sugli aspetti
della logica specifica della applicazione da sviluppare senza doversi preoccupare di
faccende che si potrebbero definire più di architettura che applicative;
- etc.
Un classico esempio di software middleware in questa area è rappresentato da quei prodotti che
assistono i programmatori nello sviluppo di applicazioni distribuite, di tipo client/server, etc.
Le
applicazioni distribuite raggiungono i loro obiettivi tramite un dialogo tra client e server; se
questo dialogo dovesse interamente essere codificato dal programmatore con l’impiego diretto delle
funzioni, più o meno evolute, messe a disposizione dai sistemi operativi, l’onere a carico dei
programmatori stessi sarebbe, come in realtà era prima che si diffondessero
gli opportuni
middleware,
estremamente gravoso.
Per quanto riguarda, invece, il software middleware a supporto della gestione e del controllo dei
sistemi di elaborazione, si tratta di una folta schiera di prodotti, di cui la complessità delle attuali
strutture
informatiche non consente di fare a meno, che presentano a chi gestisce i sistemi una
immagine in qualche modo più chiara di ciò che avviene nel complesso di elaborazione, mettendoli
così
in grado di effettuare una attività di controllo più efficace ed accettando “ordini” strutturati in
mo do più
vicino alla maniera di pensare umana.
Probabilmente non sono molti i fortunati che non hanno mai ricevuto dai sistemi di elaborazione un
messaggio
del tipo “non vi è abbastanza memoria per la elaborazione” o che non siano stati bloccati
almeno qualche volta, nel bel mezzo di una crociera su internet, da un messaggio del tipo “il server
potrebbe essere occupato”; tuttavia, messaggi di questo tipo possono non corrispondere alla realtà o,
almeno, non completamente; spesso, infatti, si tratta di una carenza nella gestione delle risorse e, ad
esempio, la memoria c’è ma non è allocata alla attività che vi interessa, oppure, il server che avete
raggiunto
è davvero in saturazione ma ve ne è un altro che giace inutilizzato e che potrebbe invece
soddisfare
la vostra richiesta, e così via.
È perciò
molto utile disporre di strumenti middleware in grado di dare ai gestori una visione chiara
di
ciò che avviene nei sistemi ed è ancora più utile disporre di strumenti che, a seguito di
determinate disposizione
impartite da chi gestisce il complesso di calcolo, siano in grado di
prendere
in autonomia i più opportuni provvedimenti finalizzati al superamento di situazioni
anomale o, addirittura, alla prevenzione di situazioni anomale..
In altri termini
- una cosa è poter “ordinare” al sistema di calcolo che una certa transazione deve avvenire
con un determinato tempo di risposta, altra faccenda sarebbe esaminare tutte le componenti
che contribuiscono a formare il tempo di risposta ed agire su di esse, singolarmente, al fine
di raggiungere il livello di servizio desiderato;
- una cosa è, dopo aver impostato i livelli di servizio desiderati, delegare al middleware la
rilevazione in tempo reale degli andamenti e la decisione su cosa modificare in caso di
scostamento, altro sarebbe attendere, per adottare (ottimisticamente) le stesse misure, il
tempo di reazione umano;
- una cosa è poter disporre di strumenti che in qualche modo riescano a fare delle previsioni
su ciò che probabilmente succederà, altro sarebbe dovere effettuare queste attività
manualmente;
- etc.
128

Ogni impianto informatico dispone di una certa quantità di prodotti middleware di varia natura; più
l’impianto
è complesso maggiore è la quantità di questi prodotti.
A causa della elevata proliferazione di strumenti di calcolo distribuiti ed a causa dello scarso
controllo tecnico-organizzativo di tale proliferazione, non sono rari i casi in cui in medesime
organizzazioni coesistano middleware differenti per la realizzazione delle stesse funzioni; grazie
alle generali tendenza al consolidamento, però, anche questa area si presume possa essere ricondotta
ad
assetti più ragionevoli e giustificabili
sia tecnicamente sia finanziariamente.
Ogni ambiente operativo, specie se destinato ad impianti di grande dimensione, ha una serie di
prodotti middleware potenzialmente impiegabili e, corrispondentemente, è comune trovare prodotti
middleware per i quali sono disponibili versioni per diversi ambienti operativi.
I prodotti middleware hanno generalmente le stesse caratteristiche, già illustrate parlando dei
sistemi
operativi, in termini di versioni e release e tutto quanto detto a questo proposito rimane
valido.
Si ribadisce pertanto che :
- è sempre consigliabile un “ragionevole” aggiornamento in termini di versione/release dei
prodotti software installati;
- la pianificazione di un up-grade di un prodotto deve essere preceduta da una analisi volta a
stimare l’impatto che la modifica che si intende apportare può avere in termini di altri
prodotti che devono essere allo stesso tempo aggiornati;
- i livelli di compatibilità ufficialmente dichiarati, pur non essendo assolutamente stringenti,
devono rappresentare un obiettivo al quale tendere;
- ogni attività di up-grade e/o di manutenzione deve essere attentamente pianificata al fine di
ridurre al minimo l’impatto sulla normale operatività; si osserva a tale proposito che, nei
moderni sistemi di elaborazione, l’impatto maggiore sulla continuità di servizio è dovuto ai
fermi programmati
e non ai malfunzionamenti non programmati
129

3.4 Software applicativo
Il software applicativo è tutto quel software che fornisce più o meno direttamente un servizio
all’utente finale per la risoluzione di specifiche necessità. Più o meno direttamente in quanto si può
trattare di prodotti software che interagiscono con l’utente finale così come si può trattare di
prodotti software che, pur non richiedendo una interazione con l’utente finale, svolgono comunque
funzioni
tipicamente applicative.
Il cassiere di una banca, ad esempio, interagisce direttamente, tramite la sua postazione informatica,
con
il software applicativo per la gestione delle operazioni dello sportello bancario; il sistema
informativo della banca, però, richiede anche l’esecuzione di una serie di software applicativi non
direttamente innescati dall’utente e che sono altrettanto importanti per il controllo ed il
consolidamento delle varie attività di sportello, per i necessari collegamenti con i sistemi
informativi di altre aziende (altre banche, banche centrali, etc.) e per altri scopi.
Il software applicativo riveste una importanza decisiva in quanto, come detto più volte, un impianto
informatico general purpose esiste in quanto deve fornire dei servizi all’utente finale
nel rispetto
delle
strategie aziendali; il software applicativo è ciò che l’utente vede dell’impianto informatico e
il suo giudizio sull’impianto è perciò esclusivamente connesso al giudizio sulla qualità del software
applicativo, cioè su una serie di aspetti tra i quali rivestono particolare importanza i tempi di
risposta, la facilità di utilizzo e la completezza nel soddisfare le varie necessità.
Se, da un lato, i sistemi operativi, così come la grande maggioranza dei software middleware,
sono
prodotti
da un ristretto numero di addetti che operano per conto di fornitori specializzati, lo sviluppo
dei software applicativi è effettuato da una pluralità di figure professionali. In altri termini, chi
opera all’interno di un impianto informatico, non si occupa in genere di mettere le mani sui sistemi
operativi o sul software middleware (anche se i sistemi operativi ed il middleware open source
consentono per definizione di farlo); ben diversa è la situazione, invece, per quanto riguarda il
software
applicativo.
I software applicativi, infatti, possono essere sviluppati da personale interno alla azienda/ente o
possono essere sviluppati da personale di società esterne variamente specializzate; in quest’ultimo
caso si può trattare di prodotti sviluppati ad hoc per una azienda o che, affrontando tematiche
comuni
a diversi settori di mercato (esempio tipico sono i prodotti per l’informatica individuale
quali gestori di testi, fogli di calcolo, etc), sono sviluppati per una pluralità di utenti e si parla,
allora, comunemente di software applicativo a scaffale.
In linea di principio, disponendo di un patrimonio software applicativo ad hoc si ha, per lo più, la
certezza della rispondenza delle funzionalità applicative alle proprie esigenze, tuttavia, in molti casi,
è sicuramente più conveniente, ad esempio, adeguare le proprie prassi formali a prodotti già
disponibili piuttosto che affrontare il pesante onere economico richiesto per lo sviluppo di un
software.
Negli impianti informatici
di piccola dimensione il patrimonio software applicativo è largamente
rappresentato
da prodotti a scaffale; man mano che la dimensione dell’impianto cresce, cioè man
mano che cresce la dimensione della azienda e quindi la complessità delle problematiche, aumenta
la quantità di software sviluppato ad hoc per l’azienda da società esterne
e la quantità di software
sviluppato
da personale interno.
Il software applicativo, come tutte le altre tipologie di prodotti software, necessita anche di attività
di
manutenzione che comportano un notevole impegno; queste attività di manutenzione possono
130

essere originate da modifiche, per dir così, oggettive (derivanti da malfunzionamenti che vengono
scoperti durante il ciclo di vita dei prodotti, da modifiche in normative di legge, etc.) e possono
essere originate da modifiche soggettive, cioè richieste, ad esempio, da mutamenti nel modello di
business aziendale; da questo punto di vista, il software applicativo sviluppato internamente o ad
hoc da aziende esterne offre naturalmente maggiori garanzie rispetto al software a scaffale per il
quale, però, non è infrequente il caso in cui il fornitore
metta a disposizione un servizio di
manutenzione
ed aggiornamento per far fronte alle necessità di tipo oggettivo.
Il software “LEGACY”
Le tecniche e le tecnologie per lo sviluppo software, così come le architetture dei sistemi
informativi, si sono modificate nel tempo con l’obiettivo di ottimizzare quanto più possibile il
tempo necessario per lo sviluppo stesso, il tempo necessario per la gestione e la manutenzione
applicativa e la rispondenza del sistema informativo al modello di business aziendale. Il notevole
impatto economico richiesto per la produzione dei programmi, però, ha fatto si che le nuove
tecniche e le nuove architetture siano state impiegate solo per i nuovi sviluppi producendo, così, una
sorta di stratificazione nelle tipologie di software funzionanti presso gli impianti.
Gli impianti informatici, specie quelli di grande dimensione generalmente dotati di strutture interne
di sviluppo applicativo, sono, perciò, oggi, come dei musei in cui è possibile ritrovare “esemplari”
risalenti a tutte le ere dello sviluppo software. L’enorme patrimonio di prodotti software sviluppati
con tecnologie ormai datate ma che rappresentano, comunque, una componente insostituibile nei
sistemi
informativi aziendali è definito comunemente il patrimonio di software legacy.
Uno degli argomenti di maggiore interesse nel campo del software applicativo è la sostituzione dei
prodotti legacy con prodotti basati su tecnologie ed architetture più moderne. Sfortunatamente non
sono, almeno per il momento, disponibili strumenti automatici in grado di effettuare tali
aggiornamenti senza l’intervento umano.
Il problema della sostituzione dei software legacy si pone con forza sia a causa dei crescenti costi di
manutenzione che le aziende devono sopportare per gestire il loro portafoglio di applicazioni legacy
sia a causa della loro scarsa flessibilità ad assecondare con rapidità i mutamenti nella operatività
aziendale.
Le
applicazioni legacy presenti presso gli impianti informatici sono tipicamente applicazioni di tipo
batch e/o transazionale sviluppate in modo del tutto isolato le une dalle altre e contenenti perciò
vaste
aree di duplicazione sia in termini di dati sia in termini di funzioni.
E’ da sottolineare che l’isolamento delle varie applicazioni è stato agevolato anche dalla
organizzazione interna dei reparti di sviluppo software degli impianti informatici che, spesso,
vedevano gruppi di persone del tutto distinti e scarsamente intercomunicanti occuparsi di specifiche
aree applicative; per non parlare di prodotti applicativi presenti nello stesso impianto e sviluppati da
diverse terze parti esterne all’impianto le quali, tra di loro, non avevano alcun tipo di
coordinamento.
Lo schema
sottostante, tratto da una pubblicazione IBM [9], illustra tale situazione per quanto
riguarda
le funzioni contenute in applicazioni di tipo legacy diverse
131

Una possibile razionalizzazione di situazioni del genere consiste in una sorta di consolidamento
applicativo
che, in passi successivi e alla luce del modello di business aziendale, conduca alla
eliminazione, quanto più ampia possibile, delle aree di duplicazione scegliendo una applicazione da
mantenere ed avviando sulle altre le necessarie attività
di ristrutturazione schematizzate nella figura
seguente
estratta dalla medesima pubblicazione IBM [9].
La problematica della revisione dei cosiddetti prodotti legacy è piuttosto complessa e,
probabilmente, richiederebbe a monte un lavoro di standardizzazione, per la verità molto
poco
probabile, volto ad evitare che tra un certo numero di anni le soluzioni che si prospettano non
diventino un problema come sono un problema oggi le applicazioni legacy.
La pratica quotidiana presso gli impianti informatici evidenzia, inoltre, un altro elemento in grado di
far predire che la manutenzione e la gestione in genere dei prodotti legacy rappresenterà un peso
crescente; si tratta del fatto che le generazione di addetti che hanno scritto i software legacy hanno
già da qualche tempo cominciato a lasciare i loro posti di lavoro portando con sé conoscenze
talvolta non completamente documentate e che perciò possono essere andate perse.
132

Questo aspetto richiederebbe la predisposizione di un vero e proprio piano di disaster recovery.
Un approccio intermedio largamente usato negli ultimi anni è consistito più che nella revisione delle
applicazioni legacy nella predisposizione di strumenti per la loro integrazione in architetture
software più moderne; ciò è stato realizzato tramite l’uso di strumenti software di interconnessione
cioè di specifici software middleware (cui generalmente ci si riferisce con il termine connettori
software)
in grado, in qualche modo, di presentare una immagine dei prodotti legacy idonea a
interfacciarsi con prodotti di nuova generazione. Questo approccio ha più un respiro che si potrebbe
definire tattico, cioè di breve periodo, che non strategico, e, non di rado, ha introdotto ulteriori
livelli di duplicazione e, in genere, di inefficienza per quanto sia riuscito a soddisfare specifiche
esigenze.
Anche la già citata architettura SOA, che rappresenta una delle ultime evoluzioni nella
impostazione
dei moderni sistemi
informativi, prevede in qualche modo di riutilizzare il patrimonio
software legacy esistente trasformandolo, ove possibile e praticabile, in ottica di servizio.
È evidente che lo studio di modalità adeguate per affrontare il problema dei prodotti legacy ha una
rilevanza critica per le grandi organizzazioni; nelle realtà piccole, infatti, può non essere
finanziariamente improponibile un “drastico” aggiornamento del patrimonio software reperendo sul
mercato prodotti di più moderna tecnologia in grado di operare efficacemente nelle nuove
architetture
software.
“Suite” di software applicativi
A differenza di uno sviluppo applicativo che considerava una applicazione isolata dalle altre, gli
attuali
software applicativi cercano di privilegiare una visione integrata delle problematiche
aziendali; si sono diffuse perciò delle suite di prodotti software, cioè sostanzialmente degli insiemi
di programmi, che tendono a costruire un sistema informativo che integri vari aspetti quali gestione
delle vendite, attività
di marketing, produzione, gestione degli acquisti, pianificazione, etc.
all’interno
di una impostazione unica, in termini sia di presentazione sia di architettura interna, che
consente una migliore efficienza eliminando, per quanto possibile, duplicazioni e disallineamenti.
In questo ottica si inquadrano le suite cosiddette ERP ( Enterprise Resource Planning).
La dizione ERP, perciò, non individua un prodotto specifico, bensì una tipologia di prodotti che
coprono in maniera integrata varie area operative.
Oltre all’aspetto della integrazione delle varie problematiche aziendali all’interno di una unica
visione
logica, le necessità aziendali hanno sempre più richiesto l’impiego di prodotti in grado di
analizzare la quantità di dati disponibile, talvolta davvero enorme, al fine di individuare tendenze,
relazioni, etc. in grado di fornire una visione, si potrebbe dire, intelligente dell’insieme di dati.
Queste famiglie di prodotti sono frequentemente indicate come prodotti di Data Mining e Data
Warehouse e, nelle realtà di grande dimensione, sono oggi piuttosto diffusi; essi possono essere
definiti prodotti di tipo decisionale in quanto aiutano e rendono più efficaci le decisioni aziendali
tramite un esame dei dati volto ad individuare tendenze, andamenti ed altre informazioni che
altrimenti passerebbero inosservate; in questo senso vi è una chiara distinzione con i prodotti
cosiddetti gestionali che, invece, si occupano di informatizzare i processi e le operazioni di routine.
L’impiego
dei prodotti appartenenti a queste famiglie richiede, naturalmente, una vasta quantità di
dati su cui operare al fine di effettuare le relative analisi con un valore statistico attendibile; perciò
133

si è reso necessario, spesso, creare dei collegamenti con le banche dati presenti nelle aziende al fine
di estrarre le informazioni (anche dagli ambienti cosiddetti legacy) e convertirle nei modi più
opportuni per renderle disponibili ai prodotti di supporto decisionale citati.
Non di rado, al fine di effettuare analisi complesse e più affidabili, i dati interni aziendali vengono
integrati con banche dati esterne che forniscono informazioni su determinati settori.
134

3.5 Software FREE, OPEN SOURCE e Proprietario
La
discussione su software FREE, software OPEN SOURCE e software PROPRIETARIO è un
argomento
di grande attualità in quanto, ultimamente, ha investito non solo ambienti abbastanza
circoscritti come ad esempio gli ambienti accademici e della ricerca, ma anche gli ambienti
commerciali cioè delle aziende e degli enti pubblici.
In quanto segue si cercherà brevemente di puntualizzare le diverse impostazioni lasciando,
naturalmente, a ciascuno il compito di farsi una idea più precisa e di effettuare di conseguenza le
proprie
scelte; a proposito
di scelte, però, si suggerisce di evitare atteggiamenti pregiudiziali e di
tenere
ben presente che l’unico obiettivo di un impianto informatico deve essere la fornitura agli
utenti
finali di servizi affidabili e con un rapporto TCO/prestazioni adeguato alle scelte ed alle
necessità aziendali.
Il movimento del FREE SOFTWARE, del quale il più famoso esponente è Richard Stallman
fondatore del Free Software Movement e verso la metà degli anni 80 della Free Software
Foundation che aveva in precedenza operato all’interno del laboratorio di intelligenza artificiale del
MIT, affronta l’argomento del software da un punto di vista che si potrebbe definire a metà strada
tra il filosofico e l’etico; il movimento sostiene infatti che l’utente di prodotti software deve poter
disporre di alcune libertà tra le quali:
- la libertà di eseguire il programma per qualsiasi suo scopo
- la libertà di modificare il programma secondo i suoi bisogni
- la libertà di distribuire copie del programma
- la libertà di distribuire copie modificate del programma.
Per assicurare queste libertà è, tra l’altro, necessario che il software free sia reso disponibile con il
codice sorgente, cioè sia open source, ma ciò non vuol dire che free software ed open source siano
la medesima cosa.
Per quanto, spesso, ci si riferisca al free software come software gratuito, le libertà di cui sopra non
parlano di denaro e anzi, al fine di superare gli equivoci che potevano essere indotti dal termine
“free” nella lingua inglese, è stato coniato il famoso detto “free as free speech and not as free bier”
che, in pratica, precisa che gli autori intendono il termine free così come è inteso parlando di free
speech, cioè libertà di parola, e non come è inteso in free bier, cioè birra a sbafo per tutti. Da ciò
deriva che non sarebbe in contrasto con i principi del free software richiedere un pagamento a fronte
dell’impiego di un software free purché questo impiego non venga limitato alla luce delle libertà
sopra elencate.
Talvolta si ritiene che il concetto di licenza sia connesso esclusivamente ai software proprietari; in
realtà non è così, e non potrebbe essere diversamente; tra l’altro, nel caso del software free e per il
forte contenuto ideologico del movimento, è necessario garantire che le libertà insite nel concetto di
free siano anch’esse trasferite in caso di ridistribuzione del software; in altre parole, per assicurare
che nella distribuzione del software le libertà vengano mantenute bisogna togliere una libertà: la
libertà di togliere le libertà agli altri. Questo concetto, che si è tradotto nel cosiddetto copyleft (che
suonerebbe come “permesso d’autore” per contrapporsi al copyright cioè al “diritto d’autore”) era
contenuto in modo molto rigido nella normativa originaria della licenza GPL (General Public
License) che regolava l’utilizzo dei prodotti free; la GPL si è poi evoluta verso forme leggermente
più permissive.
135

L’ OPEN SOURCE, invece, affonda le sue
radici su motivazioni molto più pragmatiche;
scompaiono,
infatti, le motivazioni etiche presenti
all’interno del movimento del free software e le
argomentazioni sono più relative a tematiche tecniche; per i sostenitori dei prodotti open source,
questi, rispetto ai software proprietari, sono semplicemente migliori perché, tra l’altro, sono:
più sicuri perché più facilmente controllabili e riparabili visto che la comunità che se ne occupa è
piuttosto
ampia
qualitativamente migliori visto che chi opera nel mondo open è mediamente abbastanza competente
in grado di affrancare dalla dipendenza verso specifici fornitori per i quali gli aspetti finanziari
sarebbero prevalenti rispetto agli aspetti qualitativi
etc.
In questo senso, l’open source si presenta come una modalità di sviluppo software che si giustifica
in quanto produrrebbe una serie di benefici, alcuni dei quali sono quelli elencati sopra; niente di più,
si potrebbe dire, pur consapevoli che tutto ciò sarebbe già un vantaggio formidabile; il movimento
free software, per parte sua, sostiene ugualmente la possibilità di ottenere questi vantaggi; tuttavia,
questi vantaggi sono, per così dire, solo uno dei prodotti, e non il fine ultimo, di una impostazione
che ha come obiettivi concetti molto più vasti quali la libertà (..as free speech..) degli utenti, la
condivisione del sapere, la democrazia nella diffusione della conoscenza, etc. entrando decisamente
anche nella sfera della politica.
Anche nel mondo dell’open source non si parla espressamente di costi o di prodotti gratuiti; in
realtà vi sono, a questo proposito, pareri discordanti tra chi sostiene che il TCO, cioè il costo
complessivo
indotto dall’utilizzo del prodotto, connesso
ai prodotti open sia più alto rispetto a
quello dei prodotti proprietari e viceversa.
Dal
punto di vista delle licenze l’open source
è molto meno restrittivo, in quanto molto meno
pervaso, come detto, da motivazioni ideologiche, riguardo a ciò che può essere concesso o proibito
a chi acquisisce licenze open source.
Il software PROPRIETARIO, infine, è tutto quel software disponibile solo in formato eseguibile e
perciò non modificabile, di cui si acquisisce solo una licenza d’uso a condizioni ben precise e
variamente
onerose, che tra l’altro, in genere, proibiscono la distribuzione ad altri se non in casi
particolari singolarmente regolamentati.
I sostenitori del software proprietario ritengono che questo approccio, tra l’altro:
- garantisca uno sviluppo più ordinato e più controllato del prodotto
- individui un preciso responsabile che, eventualmente, può essere chiamato a rispondere
nelle sedi più opportune dei danni provocati
- sia il frutto di organizzazioni organizzate, collaudate e abbastanza stabili
- per quanto generalmente produca costi diretti di acquisizione più alti, induca un TCO
complessivamente più favorevole all’utenza
- etc.
Si ritiene utile segnalare a chi avrà a che fare con impianti informatici appartenenti alla pubblica
amministrazione il seguente link contenente documenti di indirizzo di necessaria consultazione in
materia di software http://www.inn ovazione.gov.it/ita/normativa/normativa_os.shtml .
Il link indicato riporta alcune indicazioni e raccomandazioni prodotte sull’argomento da parte del
Ministero per l’Innovazione; è bene però tenere presente che anche altre istituzioni, come ad
136

esempio le Regioni, hanno prodotto norme e leggi in materia; non è difficile prevedere che nel
tempo interverranno altre disposizioni su punti di particolare importanza in diretta relazione con
l’argomento o relative ad argomenti in qualche modo correlati.
Da quanto è stato prodotto fino ad oggi in termini di leggi e norme sembra di poter individuare un
richiamo alle pubbliche amministrazioni a considerare attentamente, in fase di scelta di prodotti
software, l’opportunità di impiego di software open source, purché venga salvaguardato il superiore
obiettivo
di un efficace impiego del denaro pubblico; non sembra però che vi siano, e non potrebbe
essere altrimenti, prescrizioni drastiche sull’impiego di prodotti appartenenti a specifiche famiglie
di software.
137

3.6 I costi dei prodotti software
I costi dei prodotti software possono essere di tipo ricorrente, cioè
sotto forma di canoni periodici
dovuti al proprietario per l’uso del prodotto, o di tipo una tantum (o OTC one tim e charge) ma
sempre, in genere, connessi alla acquisizione di una licenza d’uso ma non della proprietà del
prodotto. Nell’area
dei mainframe è sicuramente più comune la tipologia a canoni ricorrenti, specie per
quanto riguarda i sistemi operativi ed i prodotti middleware, mentre nell’area dei personal computer
è più frequente la metodologia OTC.
Grazie
ai progressi tecnologici che hanno consentito un costante e significativo abbassamento dei
costi hardware, i costi del software sono percentualmente diventati, specie nel campo dei
mainframe, sempre più rilevanti; si verificavano,
perciò, con frequenza crescente, casi in cui il costo
del le unità di elaborazione fosse più basso, e talvolta addirittura nettamente
più basso, del costo
complessivo dei prodotti software; per cercare di limitare questo fenomeno, già da diversi anni è
generalmente stata introdotta una tecnica di quantif icazione dei costi software che quota il
medesimo
prodotto software ad un prezzo differente in funzione della potenza di calcolo della
apparecchiatura su cui tale software viene impiegato. In sostanza, per acquisire la licenza d’uso di
un
prodotto software destinato ad operare su una CPU da, ad esempio, 100 MIPS (in realtà la
indicizzazione non è sul MIPS ma si basa su altre metriche) si pagherà una cifra decisamente
più
contenuta
di quella che si pagherà per acquisire la licenza dello stessi prodotto su una CPU da 1000
MIPS. Qu esta modalità di pricing è oggi molto diffusa in area mainframe
anche se non vi è nessun obbligo
p er i vari fornitori di software di aderirvi.
Questa tecnica richiede, naturalmente, che i produttori di hardware mainframe
definiscano per le
lo ro varie apparecchiature un indice di potenza verosimile e accettabile. Oltre ai costruttori, alcune
società di consulenza indipendenti forniscono del le stime sulle capacità di calcolo delle varie
apparecchiature
e tali stime sono, in genere, congruenti con quanto viene dichiarato dai produttori
stessi.
Sempre con l’obiettivo di contenere quanto più possibile i costi software (principalmente di
base e
middleware),
si vanno diffondendo metodologie volte ad effettuare una classificazione delle
potenze di calcolo presenti all’interno di un mainframe. Ad esempio, i moderni mainframe IBM
sono generalmente apparecchiature multiprocessore sulle
quali possono contemporaneamente
operare differenti sistemi operativi; i vari processori, pur tecnologicamente identi ci, possono essere
“ caratterizzati” per gestire esclusivamente determinati tipi di carico e non altri; da ciò deriva che la
potenza dei processori dedicati, diciamo, ad ospita re il sistema ope rativo LINUX non entra a far
parte
della potenza complessiva in base alla quale si effettuano i conteggi, e si ricavano i costi,
relativi al sistema operativo z/OS ed a tutti i prodotti ad esso connessi, e così via.
La tendenza attuale in area mainframe, in qualche modo e per forza di cose indotta dalle relative
iniziative
della IBM, sembra privilegiare, dal punto di vista dei costi software, gli ambienti
innovativi
(LINUX, JAVA, etc) rispetto agli ambienti tipicamente legacy operanti sui tradizionali
sistemi
operativi per mainframe.
Le
motivazioni di ciò risiedono nelle strategie di marketing dei fornitori, tuttavia sembra evidente il
desiderio
di spostare su piattaforme hardware di tipo mainframe carichi di lavoro che altrimenti
sarebbero
con molta probabilità gestiti su piattaforme hardware diverse.
138

In effetti, i server mainframe di oggi, non sono più al 100 % controllati dai classici sistemi
operativi
z/O S , VM e VSE, bensì fette sempre più ampie de lla potenza di calcolo sono i mpiegate per
supportare carichi di lavoro diversi. Dal punto di vista di chi opera all’interno di un impianto
informatico, considerando anche la generale tenden za a l consolidamento delle risorse, questa è una
possibilità
in più che si offre per far quadrare i conti non precludendo la possibilità di adottare
ambienti operativi differenziati.
Come per i prodotti a canoni ricorrenti, anche per i prodotti cosiddetti OTC possono essere previsti
importi
da corrispondere per la licenza d’uso commisurati alla potenza di calcolo del mainframe.
N el caso di prodotti OTC, inoltre, i fornitori mettono a disposizione anche varie forme contrattuali
idonee, a fronte di canoni generalmente annui, ad assicurare la fornitura di nuove relea se e/o nuove
versioni dei prodotti.
Tecniche
di valorizzazione analoghe sono talvolta ugualmente utilizzate in ambienti server non
mainframe, anche se, in questi casi, di frequente i prezzi, in genere di tipo OTC, non
sono
commisurati
alla potenza di calcolo bensì, ad esempio, al numero di CPU di cui l’apparecchiatura
dispone.
Nell’area dei personal computer, praticamente la totalità del software è commercializzato
in
modalità OTC con eventuale canone per assicurarsi l’ aggiornam ento del prodotto; in questa area
son o molto diffuse modalità di pricing dipendenti dal numero di posti di lavoro sui quali dovrà
essere installato il software stesso.
139

IL SOFTWARE – Domande di verific a
1 S ystem V e BSD (4.2) sono sistemi operativi
della famiglia
Windows
OS/390
UNIX
Commenti: .............................................................................................................................
.................................................................................... .. ... ........ ................................................
2 quale è il Sistema Operativo più presente ne gli
ambienti mainframe commerciali di fascia alta
Windows NT
OS/390-z/OS
TCP/IP
Commenti: .............................................................................................................................
.................................................................................... .. ... ........................ ................................
3 i componenti software impiegati per il controllo devono far parte del sistem a
degli accessi informatici ai sistemi di elaborazione
e per la gestione in genere delle problematiche di
operativo
sicurezza logica sono spesso prodotti
middleware esterni
sono indicati nelle norme
sulla privacy
Commenti: .............................................................................................................................
.................................................................................... .. ... ..................................... ...................
4 la coesistenza di prodotti software di fornitori
diversi la cui compatibilità non è ufficialmente
è proibita per legge
assicurata da parte dei fornitori medesimi
è, ove possibile, da evitare
è impossibile
Commenti:
.............................................................................................................................
.................................................................................................................................................
140

5 si usano definire Legacy quelle applicazioni anche qualche decennio fa
sviluppate
con tecniche ad oggetti
per gli studi legali
Commenti: ...................................................................... .................... ......................... ..........
.................................................................................................................................................
6 le applicazioni Legacy, specie negli impianti scomparse
informatici medio grandi, sono in genere
quasi del tutto scomparse
largamente presenti
C ommenti: ...................................................................... ............................. ................ ..........
.................................................................................................................................................
7 l'aggiornamento delle versioni dei prodotti software da non fare finchè tutto
installati in un impianto informatico è una attività funziona
da fare con ragionevole
frequenza
da fare ogni 2 anni
Commenti: .............................................................................................................................
.................................................................................................................................................
8 il passaggio da una versione a quella successiva meno laborioso
rispetto al passaggio da una release a quella
successiva, per lo stesso prodotto software, è in ugualmente laborioso
genere
più laborioso
Commenti: .............................................................................................................................
.................................................................................................................................................
9 per la soluzione di una malfunzione di un prodotto di lieve entità
software è molto importante che la malfunzione sia
riproducibile
intermittente
Commenti: .............................................................................................................................
.................................................................................................................................................
141

10 i prodotti software back level possono andare sottoutilizzo
incontro a problemi di
diritti d'autore
manutenzionabilità
Commenti: .............................................................................................................................
.. ...............................................................................................................................................
11
la migrazione ad una nuova versione di un
sistema operativo presso un impianto informatico
test
dovrebbe essere preceduta da una fase di produzione
sviluppo
Commenti:
.............................................................................................................................
.................................................................................................................................................
12
nel caso in cui una nuova applicazione possa
operare su diversi
sistemi operativi, quale fattore
che sia OPEN
tra quelli indicati terreste in maggiore conto per che vi sia competenza già
scegliere il sistema operativo disponibile in azienda
che abbia il costo di acquisto
(o il canone di licenza) più
basso
Commenti: .............................................................................................................................
.................................................................................................................................................
13 il concetto base insito nella idea di OPEN la gratuità del software
SOURCE è
la disponibilità dei codici
sorgente
l'abbandono delle
piattaforme mainframe
Commenti: .............................................................................................................................
.................................................................................................................................................
142

14 l'impiego di sistemi operativi
"proprietari" è da evitare
da valutare nel quadro del
TCO complessivo
da preferire
Commenti: .............................................................................................................................
.................................................................................................................................................
15
i costi dei prodotti software in area mainframe
sono spesso proporzionali
alla "potenza" di calcolo
al numero di sistemisti
al capitale sociale
Commenti: .............................................................................................................................
.................................................................................................................................................
143

4 GLI ADDETTI
Obiettivi del capitolo
- conoscere il posizionamento dell’impianto informatico all’interno di un
generico organigramma aziendale
- conoscere le principali figure professionali, i rispettivi compiti ed i rispettivi
obiettivi
- conoscere le relazioni tra gli addetti di un impianto informatico e le altre
funzioni aziendali
- capire l’importanza di entrare in relazione con le giuste figure professionali in
funzione dell’attività che si deve svolgere
144

4.1 Generalità
L’organigramma, semplificato e tradizionale rispetto alle nuove organizzazioni studiate dagli
esperti del settore, di una azienda è tipicamente il seguente
Direzione generale
Staff Staff
Direzione
Produzione
Direzione
Commerciale
Dir. Organizzazione interna e serv
Si ritiene utile sottolineare che gli organigrammi aziendali possono essere strutturati in modo molto
diverso sulla
base dello spiegamento con il quale una azienda intende affrontare il mercato; con lo
schema
precedente, che rappresenta una organizzazione gerarchica, si vuole evidenziare che, in
generale, all’interno di una azienda, sono presenti le seguenti figure
- chi produce (una automobile o un computer, così come un prodotto bancario o assicurativo,
etc.);
- chi vende (interfacciando direttamente l’utente finale o attraverso una struttura intermedia di
distributori/rivenditori);
- chi fornisce i servizi necessari.
Un impianto informatico si colloca, di solito, nell’ambito della direzione organizzazione interna e
servizi; all’interno delle altre direzioni di una azienda sono presenti strutture informatiche le quali
possono anche disporre, per la gestione informatica, di personale dedicato che riceve almeno guida
funzionale (cioè non gerarchica ma volta a stabilire un indirizzo omogeneo) dalla direzione servizi
informatici.
Negli ultimi anni, gli impianti informatici sono stati chiamati ad assolvere a nuovi compiti che
vanno al di la del supporto alle attività interne e si rivolgono, anche, direttamente ai clienti della
azienda rappresentando, talvolta, grazie ad internet, il primo punto di contatto tra l’azienda ed il
mondo
esterno. Questa nuova funzionalità, in realtà, dovrebbe continuare ad essere vista come un
servizio fornito ad un reparto interno della azienda sulla base di specifiche definite da quest’ultimo;
in altre parole, un sito internet altro non è se non un servizio fornito, ad esempio, alla direzione
Marketing sulla base di contenuti e specifiche indicate dalla stessa
direzione Marketing che è
istituzionalmente depositaria, tra l’altro, della immagine che l'azienda vuole trasmettere di sé.
145

Un impianto informatico, perciò, può essere in generale collocato all’interno dell’organigramma
aziendale come segue
Focalizzando ora l’attenzione sulla direzione IT, in generale, si trova una organizzazione che si può
schematizzare come segue
Settore
Sviluppo
Direzione Generale
Organizzazione interna
e servizi
Direzione IT
Direzione IT
Settore
Sistemi
Staff
Settore
Gestione
Una schematizzazione del genere è abbastanza consueta all’interno di un impianto informatico di
dimensione medio-grande; in impianti informatici di dimensioni molto contenute, pur conservando
146

qualitativamente le funzioni che devono essere svolte, il numero degli addetti diminuisce fino a
sommare i compiti sulla stessa persona o su un numero ristretto di unità.
La direzione IT ha la responsabilità di rappresentare l’impianto informatico nei confronti degli altri
attori aziendali esterni ad esso.
Perciò, nei riguardi della direzione aziendale riceve in genere dei budget di spesa che deve
amministrare e rispettare a fronte di servizi che deve assicurare in determinate quantità e
determinati livelli qualitativi; per quanto di solito non vi sia un rapporto codificato, il resto
dell’azienda deve essere visto come il cliente dell’impianto e trattato con tutti i “riguardi” che gli
competono.
La direzione IT cura i piani di formazione ed addestramento del personale e, più in generale, mette
in atto tutte le azioni più idonee, nel rispetto delle politiche aziendali, per la motivazione del
personale, argomento che, come per ogni altra struttura, è generalmente un prerequisito al
raggiungimento degli obiettivi generali. Queste azioni riguardano, naturalmente, gli aspetti
finanziari e di gestione delle carriere, ma riguardano anche altri aspetti quali la responsabilizzazione
delle persone, la delega di responsabilità, la giusta collegialità nelle decisioni, etc.
L’ambiente IT, come già detto, deve preoccuparsi di comprendere e soddisfare le richieste
provenienti dagli altri settori aziendali, cioè, in altri termini, il modello di business che l’azienda
intende adottare; il modello di business aziendale non deve essere vincolato dalle scelte
informatiche.
All’interno dell’impianto informatico, invece, possono essere decise, o, nel caso in cui gli interventi
di spesa fossero di entità superiore alle eventuali deleghe di cui il settore IT dispone, proposte alla
direzione generale, tutte le iniziative volte ad ottimizzare i costi e/o la qualità/affidabilità dei servizi
tramite:
- il rinnovo tecnologico delle apparecchiature obsolete per le quali, ad esempio, il TCO di
gestione supera il TCO derivante dalla sostituzione;
- l’adozione di strumenti nuovi e più efficaci che consentano, ad esempio, un miglior impiego
del personale;
- l’aggiornamento dei prodotti software finalizzato a mantenere l’impianto ad un livello di
manutenzionabilità soddisfacente;
- l’adozione di strumenti nuovi e più efficaci che consentano di evitare
necessità di blocco
programmato dei servizi.
Alla direzione
IT compete il compito di “negoziare” con le altre funzioni aziendali gli eventuali
periodi di interruzione di servizio nei casi, sempre
più rari negli impianti di una certa dimensione
normalmente attivi 24 ore x 365 giorni, in cui debbano essere svolte attività di gestione e/o
manutenzione. La direzione IT, inoltre, gestisce i rapporti tecnici con i fornitori del settore; per quanto riguarda,
invece,
i rapporti contrattuali e/o la gestione degli acquisti utilizza i supporti interni della società
preposti a questa attività (ufficio acquisti, ufficio gare e appalti, ufficio legale, etc.) fornendo ad
essi, ove opportuno, la consulenza tecnico-informatica necessaria.
All’interno della funzione di “staff” si intendono tutti gli addetti che svolgono attività
amministrative,
di controllo, di segreteria e di supporto in genere.
147

In quanto segue si forniscono delle brevi indicazioni sulle principali mansioni delle figure
professionali presenti in un impianto informatico; può essere di interesse rilevare che, per quanto
riguarda una definizione formale di “chi fa cosa”, quali competenze (skill) tecniche devono avere le
varie figure, quali backgroud culturali e quali esperienze devono avere, etc. vi sono delle iniziative
che si propongono di mettere ordine sulla materia (si veda ad esempio l’iniziativa EUCIP); al
momento queste iniziative sono in corso ed è auspicabile che raggiungano presto una positiva, e
principalmente
utile, conclusione; non è chiaro se attività di questo genere possano sfociare in
precisi prerequisiti normativi riguardanti i titoli necessari per accedere a determinate posizioni
professionali, o se, invece, si tratterà
di raccomandazioni più o meno pressanti o, per dir così, di
semplici consigli; ad ogni modo è comunque
da apprezzare lo sforzo che si sta compiendo per
razionalizzare e meglio definire l’argomento.
4.2 Il settore “sviluppo”
Il gruppo, ove presente, di persone generalmente più numeroso all’interno di un impianto
informatico
è costituito dal settore di sviluppo.
Questo
è il gruppo che si occupa della analisi delle richieste di nuove funzionalità da parte degli
altri
settori aziendali, della predisposizione fisica dei nuovi programmi, della loro verifica e della
loro
manutenzione.
Il settore di sviluppo, schematicamente, può essere rappresentato come segue
Sviluppo
Analisti Programmatori Collaudatori
Ha
come obiettivo la predisposizione del software applicativo necessario all’azienda dopo avere
ottenuto le necessarie autorizzazioni dalla direzione aziendale e dopo avere effettuato una analisi
delle problematiche in collaborazione con le funzioni utente interessate. Per realizzare questa
attività il gruppo di sviluppo è composto da analisti, programmatori e collaudatori per la copertura
dell’intero ciclo di vita di un prodotto software applicativo.
Gli
analisti sono il primo punto di contatto tra il gruppo di sviluppo e l’ambiente esterno che
richiede un nuovo servizio che si concretizzerà con un nuovo prodotto software o con la modifica di
un prodotto software già esistente. La caratteristica principale che l’analista deve possedere è
quella di capire le necessità dei “clienti” i quali, si presume, conoscono bene il loro problema ma
non sono tenuti a conoscere gli aspetti salienti ai fini informatici che ne derivano. Tali aspetti
devono
essere colti dall’analista che deve essere in grado di trasformare specifiche di business in
specifiche di tipo informatico.
148

Il compito di un analista inserito all’interno del gruppo di sviluppo di un impianto informatico e che
opera da tempo in collaborazione con le altre funzioni aziendali è in genere facilitato da una
migliore conoscenza dei servizi che vengono richiesti; in altre parole, un analista “anziano” che
opera
all’interno di un impianto informatico di una banca avrà certamente dimestichezza con gli
argomenti applicativi del settore bancario, con le terminologie e con le prassi comuni; ciò tuttavia
non deve portare ad una minore attenzione verso nuove problematiche nella presunzione di essere
esperti quanto lo sono le funzioni utente interessate.
Assieme
ad una buona conoscenza delle tecnologie informatiche, l’analista deve possedere spiccate
capacità di interazione con gli utenti e con le altre figure professionali del mondo informatico quali
responsabili di progetto, specialisti di architetture HW e SW di base e middleware, etc.
L’analista, dopo avere definito i vari aspetti progettuali ed avere ottenuto su di essi l’accordo delle
funzioni utente interessate, produce la documentazione necessaria alla fase di sviluppo applicativo
vero e proprio ed effettua un monitoraggio sulle fasi successive delle attività.
Il programmatore realizza, sulla base dei risultati della attività di analisi, lo sviluppo applicativo
con gli strumenti e con le prassi in uso e cura la produzione della documentazione relativa.
Il collaudatore, infine, provvede al collaudo informatico delle applicazioni sulla base dei criteri di
collaudo
stabiliti e produce la relativa documentazione di collaudo.
Presso
gli impianti informatici di grande dimensione si costituiscono spesso gruppi formati da
analisti, programmatori e collaudatori esclusivamente assegnati a specifiche problematiche
applicative
aziendali; questa eventualità è altrettanto frequente all’interno di società di sviluppo
software le quali, per assicurare una migliore assistenza ai clienti più critici, costituiscono gruppi di
lavoro
dedicati a specifici clienti o ad una determinata area applicativa di uno specifico cliente.
La
realizzazione di organizzazioni di questo genere, da un lato garantisce la migliore conoscenza di
singole aree applicative, ma, come si è osservato parlando del software legacy, deve essere
accompagnata
da misure che consentano di non isolare l’argomento specifico dal resto del sistema
informativo di cui fanno parte, con la conseguenza di aumentare, complessivamente, fenomeni di
duplicazione e di scarsa omogeneità nel progetto della architettura applicativa.
Come
detto prima, il settore di sviluppo, nel suo complesso, ha anche il compito di curare le
applicazioni
anche per quanto concerne la loro manutenzione che può essere:
- correttiva, volta a risolvere malfunzioni (questa attività in genere decresce con l’aumentare
della vita del prodotto in quanto gli errori che si vanno eliminando sono, generalmente, più
numerosi di quelli che si introducono);
- adeguativa, per soddisfare, ad esempio, nuovi requisiti normativi e/o di legge;
- evolutiva, necessaria per adeguare gli strumenti software
a nuove necessità di business;
- migliorativa, volta ad ottenere un miglioramento delle prestazioni, del livello di
integrazione con altre procedure, etc.
Come abbiamo
visto prima commentando la evoluzione delle modalità di elaborazione, inizialmente
la persona
che operava su un computer doveva occuparsi tanto degli aspetti applicativi quanto degli
aspetti di gestione delle componenti hardware, degli aspetti connessi alla schedulazione delle
attività, etc.
149

L’introduzione dei sistemi operativi ha fatto si che le professionalità cominciassero
a distinguersi
producendo una prima caratterizzazione precisa tra chi si occupava del software applicativo e chi si
occupava di tutto il resto del software che veniva utilizzato per ottimizzare
l’operatività delle
apparecchiature; nasceva così il programmatore di applicazioni ed il programmatore di sistema,
oggi ch iamato sistemista, che si occupa di gestire i software di base e larga parte del software
middleware. 4.3 Il settore “sistemi”
Del settore sistemi fanno parte coloro
che si occupano di software di base e di larga parte dei
prodotti middleware in termini di installazione
e gestione.
Il settore
sistemi potrebbe essere schematizzato come segue
Sistemi
centrali
Sistemi
Sistemi di
Telecomunicazionee
Sistemi dipartimentali
Il settore sistemi deve assicurare la corretta operatività dei software di ambiente tramite la
conoscenza dettagliata
e specialistica di tali software e delle interazioni tra essi e l’hardware.
Il sistemista, si occupa, perciò, di studiare i sistemi operativi ed i prodotti middleware a supporto
della gestione, di installarli, configurarli e parametrizzarli secondo le necessità specifiche e di
seguirne l’evoluzione in termini di aggiornamenti di versioni/release, di risoluzione di
malfunzionamenti e di attività di tuning, cioè di tutte quelle attività volte ad ottenere un ambiente
operativo equilibrato nella distribuzione delle risorse hardware nel rispetto delle priorità che
normalmente devono essere garantite.
La varietà e la crescente complessità dei vari ambienti operativi rende necessaria, almeno negli
impianti informatici più grandi ed eterogenei, la presenza di sistemisti specializzati nei vari settori
quali i sistemi
centrali mainframe, i sistemi di telecomunicazioni, i sistemi dipartimentali, etc. e,
talvolta,
anche di sistemisti specializzati ed operanti su singoli middleware quali, ad esempio,
prodotti per la gestione di banche dati (Data Base), prodotti per la sicurezza, etc.
A causa della già citata presenza all’interno degli impianti informatici medio-grandi di prodotti
software di base e middleware di diversi produttori, il compito del sistemista è ancora più
impegnativo poiché nelle moderne realtà è necessario uno studio non solo di singoli prodotti ma
anche delle relazioni
tra prodotti diversi.
150

L’attività del sistemista è caratterizzata da una forte interazione con i fornitori dei vari prodotti
software di base e middleware e, principalmente, con le strutture di supporto tecnico che i vari
fornitori mettono a disposizione per i loro clienti.
Nel caso, ad esempio, di malfunzionamenti non banali, cioè non dovuti a cause facilmente
individuabili
e risolvibili, è compito del sistemista, dopo avere effettuato una prima rilevazione
della problematica accompagnata dalla rilevazione di specifiche informazioni utili alla migliore
definizione del problema, attivare le strutture di supporto dei fornitori interessati.
I prodotti middleware sempre più completi e complessi sono sicuramente di ausilio ai sistemisti per
quanto riguarda il controllo e l’ottimizzazione dell’insieme hardware e software di un sistema di
calcolo; per sfruttare pienamente queste potenzialità è però necessaria una conoscenza approfondita
di questi strumenti che si ottiene sia con lo studio e la continua formazione sia con l’esperienza
diretta e quotidiana sul campo. Oltre alle approfondite conoscenze dei sistemi operativi e dei
prodotti
middleware, il sistemista deve anche conoscere le funzioni messe a disposizione dalle
macchine di cui dispone.
4.4 Il settore “gestione”
Il settore gestione può essere schematizzato come segue:
Gestione
Sala macchine Impianti ausiliari Schedulazione
Supporto utenti Sicurezza logica
Chi
opera nel settore gestione ha i seguenti compiti principali:
- assicurare, tramite gli operatori, il presidio della sala macchine (che, nel caso di impianti
basati su mainframe, può essere richiesto per 24 ore al giorno) al fine di svolgere tutte le
attività per le quali è richiesto l’intervento umano (ad esempio, in base alle richieste del
sistema opertativo, caricamento delle cartucce nastri, sostituzione carta nelle stampanti,
etc.);
- schedulare opportunamente le procedure giornaliere e periodiche che devono essere eseguite
sulla base delle necessità stabilite e codificate per le varie procedure in fase di progettazione
delle procedure stesse;
- fornire un primo supporto all’utenza per problemi connessi alla operatività dell’impianto;
151

- controllare il corretto funzionamento delle apparecchiature ausiliarie;
- pianificare le fasi relative alla installazione e/o alla rilocazione di apparecchiature
assicurando la corretta predisposizione dei luoghi (site preparation);
- rilevare eventuali malfunzioni delle apparecchiature e seguirne le fasi di diagnosi e
risoluzione in collaborazione con i supporti tecnici dei fornitori;
- etc.
La
distribuzione orientativa delle risorse umane nei vari settori all’interno di un impianto
informatico di tipo mainframe è la seguente:
- settore sviluppo 60%
- settore sistemi 15%
- settore gestione 30 %
4.5 I manager
All’interno
di un impianto vi sono anche, naturalmente, un certo numero di persone con compiti di
coordinamento e/o manageriali; l’evoluzione delle carriere dipende dalle impostazioni aziendali
relative alla gestione del personale; comunque, spesso, le varie figure di coordinamento e
manageriali sono reperite all’interno.
E’ bene precisare, a questo proposito, che non è sufficiente essere, ad esempio, un ottimo sistemista
per essere anche un ottimo responsabile del gruppo sistemi in quanto le problematiche e le
situazioni che deve affrontare chi è chiamato a coordinare altre persone richiedono anche, se non
principalmente, doti diverse da quelle puramente tecniche.
L’esperienza porta a dire che le grandi capacità tecniche solo raramente si sposano con grandi
capacità nella gestione di un gruppo di persone, se non altro perché le figure di tipo manageriale
devono affrontare anche problematiche non tecniche la cui importanza, talvolta, è sottovalutata o
non ben compresa.
Le elevate capacità tecniche dei manager informatici possono addirittura essere un limite se non
sono unite ad una giusta dose di autocritica e di capacità di gestione del ruolo; in questi casi, infatti,
può succedere che le impostazioni tecniche vengano decise solo dal manager anche se a fronte di
una
discussione che però è più spesso formale che
sostanziale; ciò, a lungo andare, produce
demotivazione nei collaboratori, genera un collo di bottiglia nella operatività del reparto ed una
generale tendenza ad uno scarso approfondimento degli argomenti; se a ciò si aggiunge il fatto che,
dovendo far fronte all’onere aggiuntivo indotto dalla attività di coordinamento, il manager può non
disporre del tempo necessario ad accrescere opportunamente il proprio bagaglio tecnico, ecco così
che
può instaurarsi
un meccanismo con effetti tutt’altro che positivi sulla efficacia dei processi e dei
risultati.
A causa di ciò non è infrequente il caso in cui, almeno nelle organizzazioni medio grandi, vi sia una
netta distinzione tra carriere tecniche e carriere manageriali, in questo modo si offrono le giuste e
necessarie
prospettive,
che rappresentano pur sempre una delle principali fonti di motivazione nel
lavoro, alle varie professionalità senza il rischio di trasformare un ottimo tecnico in un mediocre
manager e di perdere l’occasione di sfruttare le capacità manageriali di persone tecnicamente nella
media.
La comprensione dei vari ruoli è importante per chi opera all’interno
di un impianto ed
è altrettanto
importa nte per chi opera a contatto con un impianto informatico ma dall’esterno. Tra questi, come
152

si vedrà con maggior dettaglio nel seguito, vi sono i clienti interni,
ciò tutte quelle funzioni che
operano
all’interno della azienda e che richiedono servizi all’impianto, ed i fornitori.
I client i interni che hanno una qualche necessità di interfacciarsi con l’impianto sono, in genere,
agevolati dai manuali interni che definiscono il “chi fa che cosa” e/o sono guidati dagli help
desk
aziendali.
Per quanto riguarda i fornitori si tratta di individuare chi può meglio apprezzare la propria
“mercanzia”, cioè, in definitiva, trovarla
adeguata al raggiungimento dei propri obiettivi.
Se, ad esempio, si deve proporre una soluzione
di tipo prettamente applicativo, allora il miglior
interlocutore
può non trovarsi presso l’impianto,
bensì presso quella funzione aziendale interessata
alla soluzione e che, a sua volta, nel caso in cui ne riconosca la validità, può farsi carico al proprio
interno di promuoverne l’utilizzo.
S e, invece, si deve proporre l’adozione di un prodotto middleware in grado di velocizzare lo
sviluppo applicativo, allora ci si deve rivolgere a qualcuno all’interno dell’impianto; ma a chi? Beh,
è semplice,
bisogna rivolgersi agli sviluppatori, si potrebbe pensare; ed in effetti potrebbe essere la
soluzione giusta a patto che l’ambiente sia dinamico e propenso ad imparare cose nuove; ma se i
nos tri sviluppatori
fossero troppo attaccati alle loro abitudini e scarsamente propensi a modificarle
specie a costo di lunghe ore di studio? Allora si potrebbe trovare l’interlocutore giusto nel
responsabile del settore sviluppo, sempre alle prese con problemi di rispetto dei tempi e dei budget
nella realizzazione dei progetti; il responsabile del settore sviluppo potrebbe essere interessato alla
faccenda. Nella pratica,
le situazioni sono più complesse, tuttavia, chiedersi chi può realmente comprendere e
ritenere utile l a propria “mercanzia” è un buon punto di partenza per ogni fornitore.
4.6 Considerazioni sulle professionalità
Quanto si è detto circa gli addetti che operano all’interno di un impianto informatico deriva da
osservazioni
confermate nella generalità dei casi.
Si ritiene doveroso, però, osservare che non vi sono norme che definiscano i prerequisiti per
l’accesso alle varie professionalità
di cui si è detto e ciò è un aspetto piuttosto singolare se si
considera la pervasività e la criticità delle gestioni informatizzate nella società moderna.
Si desidera
precisare che queste osservazioni non intendono criticare, complessivamente, chi opera
nel settore informatico che da, in genere, prova di competenza e di buon senso, ma vogliono solo
evidenziare un punto che si ritiene debba essere soggetto ad interventi normativi.
Quest a mancanza di riferimenti oggettivi è piuttosto sentita ed ha portato alla nascita di iniziative
come la già citata iniziativa EUCIP che si sta inoltrando in questo campo; le altre iniziative
che da
qualch e tempo si stanno diffondendo su questo argomento sono quelle che vanno sotto il nome di
certificazio ni; si tratta in sostanza di test messi a punto dai vari produttori il cui superamento
consente di ottenere una certificazione, fornita dal produttore stesso, che attesta il livello di
competenza d i chi l’ ha ottenuta; un po’ come se si trattasse di una scuola privata che rilascia un
diploma; ma ci
si potrebbe chiedere, allora
- un diploma di questo genere, oltre che un valore strettamente connesso alla affidabilità della
Società che lo rilascia, giuridicamente, che valore ha?
153

- nel caso in cui un professionista in possesso di una certa certificazione rilasciata da una certa
Socie tà produce un danno chi ne risponde oltre che, nei limiti di legge, per quanto concerne
le inadempienze derivanti
dall’eventuale contratto stipulato?
Una chiave di lettura di questa situazione potrebbe essere rappresentata dal
fatto che l’informatica
in senso lato è ancora lontana dal potere essere considerata una scienza con un certo numero di
certezze.
Per chiarire meglio questa affermazione che può sembrare
piuttosto drastica si propone la seguente
similitudine.
Per la costruzione di una abitazione, ad esempio, vi sono, tra l’altro, delle norme precise che
riguardano le protezioni contro eventi sismici; la presenza di norme precise e generalmente
accettate consente di poter indagare sul grado di competenza che un professionista ha di queste
norme e, conseguentemente, a fronte di un certo percorso di studi, rilasciare una autorizzazione che
riconosce al professionista l’autorità di progettare secondo quelle norme, pur assoggettando il
progetto alle necessarie verifiche.
Parallelamente,
se vi fossero delle norme precise e generalmente accettate sulle capacità di far
fronte ad un disastro per quanto riguarda, ad esempio, un sistema informativo si potrebbe
indagare
sulla conoscenza di queste norme da parte dei vari professionisti e si potrebbe, conseguente,
rilasciare un a certificazione che autorizza il professionista a firmare progetti di sistemi informativi,
condizionando l’ingresso in produzione delle procedure (una specie di abitabilità) ad opportune e
stringenti verifiche.
Ciò richiederebbe la predisposizione di norme che definiscano, per i vari settori
di mercato ed in considerazione del relativo impatto sugli utenti
finali, i tempi di ripristino richiesti
per i sistemi
informativi.
(La definizione dei tempi di ripristino è oggi per lo più affidata alla sensibilità delle singole aziende
che cominciano a vedere in ciò un vantaggio competitivo, cioè un valore aggiunto in grado di
qualificare i propri servizi rispetto a quelli offerti dai competitori; in sostanza, come se una azienda
di edilizia fosse libera di applicare o meno dei criteri antisismici contando sul fatto che la loro
applicazione possa costituire una attrattiva di marketing in più rispetto ad un’altra azienda che
dec ida di non applicarli; eventualità che tutti riconosciamo assurda.)
Vi è ancora
molta strada da fare in questa direzione.
Tuttavia,
ci si augura che le varie iniziative, sostanzialmente episodiche, che nascono sulla base di
necessità
di marketing o a titolo di precauzione a fronte delle conseguenze economiche che possono
derivare da eventi catastrofici o per altro ancora, rappresentino le varie tappe di avvicinamento alla
meta finale.
Nell’attesa che vi siano dei riferimenti chiari circa le professionalità e le competenze necessarie
all’interno di un impianto informatico, ogni azienda o ente segue dei criteri più o meno strutturati
per il reperimento e la qualificazione del personale addetto ai sistemi informativi ed agli impianti
informatici.
A questo proposito si possono dare alcuni suggerimenti finalizzati alla creazione di una prassi nella
gestione del personale informatico:
- definire le conoscenze, generali e specifiche, necessarie per le varie funzioni;
- definire i compiti e le responsabilità delle varie funzioni;
154

- stabilire le modalità di documentazione delle varie attività;
- predisporre, internamente o tramite società esterne,
dei piani di formazione volti a fornire le
conoscenze stabilite per le varie funzioni;
- evitare, per quanto possibile, la presenza di competenze uniche su singole persone;
- predisporre piani di crescita professionale chiaramente identificabili e perseguibili.
Le
attività indicate devono essere riviste ed aggiornate continuamente in considerazione anche del
fatto che i progressi e le novità in area informatica
sono
molto frequenti e comportano,
perciò, un
rischio
di obsolescenza rilevante.
4.7 Qualche suggerimento
Le prime cose che si dovrebbero fare nel caso in cui ci si trovi ad avviare un rapporto di lavoro
in
qualità
di dipendente presso un impianto informatico sono:
- rendersi conto della organizzazione della azienda in cui si opererà cercando, per quanto
possibile, di attingere informazioni da documenti ufficiali interni (quali organigrammi, manuali operativi, etc.)
- rendersi conto della composizione della propri a linea gerarchica e di eventuali gerarchie
funzionali dipendenti da specifiche problematiche e/o da specifici progetti all’interno dei
quali si è chiamati ad operare
- rendersi conto di quali sono i clienti interni ed esterni con i quali vi è la possibilità di entrare
in contatto e delle modalità con le quali questi contatti devono essere condotti
- cercare, per quanto possibile, di ufficializzare all’interno della propria struttura lo stato di
avanzamento delle attività che si prendono in carico predisponendo documentazioni relative,
ad esempio:
o allo stato di avanzamento dei p rogetti e delle attività cui si
è assegnati
o alle varie situazioni pendenti
- verificare la reale disponibilità fisica di quan to si assume come esistente
(ad esempio source
di programmi sviluppati all’interno dell’azienda, copie di riserva aggiornate di software di
base, middleware e software applicativi necessarie per eventuali reinstallazioni)
Le prime cose da fare nel caso in cui ci si trovi ad avviare un rapporto di lavoro come manager di
un impianto informatico:
- rendersi conto della organizzazione della azienda in cui si opererà cercando, per quanto
possibile, di attingere informazioni da documenti ufficiali interni (quali organigrammi, manuali operativi, etc.)
- rendersi conto delle politiche di gestione del personale adottate dall’azienda
- rendersi conto delle strutture sindacali presenti presso l’impianto e/o presso l’azienda
- rendersi conto con la massima precisione possibile della struttura dei requirements aziendali
e della loro ricaduta sui servizi e sulle prestazioni dell’impianto informatico
- rendersi conto delle procedure presenti in area sicurezza esaminando in particolare:
o il livello di rispondenza ai requirements aziendali in area sicurezza (disaster recovery
e continuous availability)
o l’adeguatezza (in termini di conoscenze e di reali capacità operative) della
preparazione del personale finalizzata a fronteggiare le situazioni di disservizio cui i
piani di sicurezza prevedono di far fronte
155

o il livello di dipendenza dei piani di sicurezza aziendali da fattori esterni all’azienda
al fine di valutare la reale efficacia dei piani di sicurezza
stessi e gli effettivi livelli di
rischio presenti
- esaminare le competenze del personale e, nel caso in cui non fosse già disponibile,
predisporre una sorta di inventario delle competenze; ciò sarà utile:
o per definire eventuali situazioni di rischio connesse alla unicità di determinate
conoscenze
o per predisporre piani di formazione a breve termine, cioè volti a mettere in sicurezza
situazioni potenzialmente rischiose
o per predisporre piani di formazione strategici, cioè volti a creare le condizioni per
agevolare gli sviluppi futuri dell’impianto
- esaminare il livello tecnologico ed il livello di utilizzo delle apparecchiature informatiche ed
ausiliarie
- esaminare le piattaforme software ed hardwa re impiegate presso l’impianto al fine di
verificare la congruità delle stesse con le strategie di sviluppo aziendale ed i relativi
requirements
- esaminare il livello di aggiornamento dei prodotti software
- esaminare i contratti in essere con i fornitori dell’impianto al fine di verificare la
rispondenza dei servizi acquisiti alle necessità aziendali e la corrispondenza tra i contenuti
dei contratti ed i prodotti/servizi realmente utilizzati; non è raro il caso in cui:
o i servizi acquisiti non siano commisurati alle necessità ad esempio per quanto
riguarda la disponibilità temporale che può risultare sovrabbondante (comportando
un maggiore onere finanziario sostanzialmente ingiustificato) rispetto alle reali
necessità o, situazione ovviamente più rischiosa, insufficiente a garantire i livelli di
servizio derivanti dai requirements aziendali
o alcuni dei prodotti (tipicamente nel campo software) siano sotto utilizzati, non più
utilizzati o duplicati
o alcuni prodotti software siano realmente utilizzati in versioni/release differenti da
quelli contrattualizzati (ciò può indurre, oltre ad eventuali violazioni contrattuali,
difficoltà nelle operazioni di manutenzione e/o up-grade ordinarie a causa del
disallineamento tra quanto realmente utilizzato e quanto i diversi fornitori
presumono sia utilizzato)
- in ogni caso, operare avendo ben chiaro che riconoscere la validità di indirizzi e strategie
esistenti non è segno di scarsa capacità innovativa, bensì di maturità nell’esprimere giudizi
circa le varie situazioni; pertanto è bene astenersi dall’apportare
modificazioni derivanti da
posizioni preconcette
156

GLI ADDETTI – Domande di verifica
1 se l'organigramma aziendale prevede una
dire zione produzione, una direzione commerciale
direzione commerciale
e d una direzione organizzazione interna e servizi
dove si collo ca, di solito, l'impianto informatico
direzione produzione
d irezione organizzazione
interna e servizi
Commenti:
...............................................................................................................................
.. ................................................................................................................................................
2 gli interventi volti alla sostituzione di macchine
p er motivi esclusivamente tecnico/economici
direzione commerciale
sono decisi e/o proposti da direzione IT
direzione generale
Commenti: ...............................................................................................................................
............................................................................................................................... ...................
3 se l'organizzazione di un impianto informatico
prevede il gruppo sistemi, il gruppo sviluppo ed
gruppo sistemi
il gruppo gestione, chi si occupa, in genere,
di coordinare le attività di "site preparation"
gruppo sviluppo
gruppo gestione
Commenti: ...............................................................................................................................
............................................................................................................................... ...................
4 quale figura professionale opera in contatto con
i "clienti" dell'impianto al fine di comprenderne
programmatore
con precisione le necessità analista
operatore
Commenti: ...............................................................................................................................
............................................................................................................................... ...................
157

5 all'interno di un impianto informatico general sviluppare nuovi sistemi
purpose, il settore comunemente chiamato
"sviluppo" si occupa di
operativi
produrre e manutenere
software applicativi
site preparation
Commenti: ...............................................................................................................................
..................................................................................................................................................
6 quale figura professionale si occupa di eseguire collaudatore
le attività secondo la schedulazione stabilita
analista
operatore
Com menti: .......................................................... ....... .. ............................................................
.. ... .......................... ..................................................... .. ... ... ......................................................
7
quale figura professionale ha in genere il compito
di installare e gestire i prodotti middleware
operatore
sistemista
programmatore
Commenti: ...............................................................................................................................
..................................................................................................................................................
8 la fase iniziale del progetto di una nuova i collaudatori
applicazione è in genere condotta in
collaborazione tra le funzioni utente e gli operatori
gli analisti
Commenti: ...............................................................................................................................
..................................................................................................................................................
9 le necessità di manutenzioni software di tipo VERO
"correttivo" in genere decrescono con il tempo
FALSO
dipende dal TCO
Commenti: ...............................................................................................................................
..................................................................................................................................................
158

10 cosa si intende per manutenzione
software di la revisione dei prodotti per
tipo "evolutivo" soddisfare nuove
necessità di business
lo spostamento dei
prodotti su CPU più potenti
la correzione di errori logici
Commenti: ............................. ..................................................................................................
.. ................................................................................................................................................
11
il sistemista ha in genere un intenso rapporto con gli utenti finali
con la direzione generale
con i fornitori di sistemi
operativi e/o middleware
Comm enti: ..................................................................................................................... ..........
..... ..... . ..................................................................................................................................... ..
12 se l'organizzazione di un impianto informatico
prevede il gruppo sistemi, il gruppo sviluppo ed
gruppo sistemi
il gruppo gestione, chi si occupa, in genere,
del controllo delle aparecchiature ausiliarie
gruppo sviluppo
gruppo gestione
Commenti: ...............................................................................................................................
..................................................................................................................................................
13 i manager informatici devono essere i massimi VERO
esperti tecnici disponibili in azienda nella area
di competenza FALSO
vero solo per Mainframe
Commenti: ...............................................................................................................................
..................................................................................................................................................
159

14
la costituzione di gruppi di sviluppo (analisti, un degrado della qualità
programmatori, collaudatori) dedicati ad aree delle soluzioni aplicative
applicative specifiche può comportare dell'area
il rischio di scarsa
omogeneità del sistema
informativo complessivo
l'aumento dei fermi
programmati
Commenti: ...............................................................................................................................
. ............................................................................... ..................................................................
15 se l'organizzazione di un impianto informatico
prevede il gruppo sistemi, il
gruppo sviluppo ed
gruppo sistemi
il gruppo gestione, quale tra questi è in genere
il più numeroso
gruppo sviluppo
gruppo gestione
Commenti: ...............................................................................................................................
..................................................................................................................................................
160

5 I LUOGHI
Obiettivi del capitolo
- conoscere le diverse necessità connesse alle predisposizioni ambientali di un
impianto informatico
- comprendere la necessità di esaminare per tempo gli aspetti relativi alle
predisposizioni ambientali
- conoscere la struttura dei costi dei prodotti Software
- familiarizzare con i concetti di site preparation e cablaggio strutturato
161

5.1 Site Preparation
Le problematiche connesse ai luoghi dove si trovano gli impianti informatici sono di grande
importanza e devono essere attentamente considerate in caso di nuovi progetti o di adeguamenti di
impianti già in essere.
La corretta realizzazione di un progetto informatico non può prescindere da un esame degli aspetti
connessi ai luoghi.
I luoghi possono essere i più vari; dall’ufficio dove risiedono gli utenti finali alla complessa glass
house dove risiedono macchine informatiche, macchine ausiliarie, personale, etc.
I principali requisiti di site preparation (cioè di predisposizione dei luoghi) che devono essere
soddisfatti possono essere suddivisi come segue:
- requisiti connessi agli spazi fisici;
- requisiti ambientali;
- requisiti elettrici;
- requisiti connessi al cablaggio;
- requisiti connessi alla movimentazione
delle apparecchiature;
- etc.
Per
quanto concerne i requisiti sugli spazi fisici, per la installazione di una apparecchiata devono
essere
reperiti gli spazi necessari considerando le necessità legate allo spazio richiesto dalla
apparecchiatura, il peso, gli eventuali vincoli
connessi alle connessioni che devono giungere e/o
partire
dalla apparecchiatura stessa e le necessità di alimentazione.
Gli
ingombri di ogni apparecchiatura sono forniti dal produttore tramite i manuali di installazione
fisica
e riguardano sia l’ingombro in pianta ad apparecchiatura operativa sia l’ingombro dovuto alle
aree di servizio che servono in caso di manutenzione o di altre attività; le aree di servizio sono per
lo più necessarie per consentire l’apertura di eventuali sportelli di cui l’apparecchiatura può essere
dotata e che consentono al personale tecnico di effettuare le operazione che si dovessero rendere
necessarie sulle macchine; queste operazioni sono in genere richieste sia per le attività di
manutenzione
sia per gli eventuali up-grade o potenziamenti della configurazione della macchina.
Il peso della macchina è molto importante al fine di assicurarsi sulla portata del pavimento che,
specie nei centri di calcolo dotati di pavimento sopraelevato e attivi da diverso tempo, può
richiedere qualche intervento. In realtà, in area mainframe, le apparecchiature, grazie alla diffusione
della tecnologia CMOS, sono oggi fonte di minori preoccupazioni da questo punto di vista, tuttavia
le verifiche sono sempre di routine.
Il posizionamento della apparecchiatura, inoltre, può essere condizionato anche dalle necessità di
connessione
con altre apparecchiature; le connessioni possono essere disponibili nella parte
sottostante l’apparecchiatura
e, in questo caso, necessitano ovviamente di un pavimento
sopraelevato;
nella mattonella corrispondente sarà in questi casi praticato un foro di opportune
dimensioni
per consentire il passaggio dei cavi sotto il pavimento sopraelevato; non sono rari i casi
in cui, specie nei centri di una certa “età”, l’intercapedine tra il pavimento vero e proprio ed il
pavimento
sopraelevato sia piuttosto affollata da grandi quantità di cavi, bisogna perciò avere cura
di
assicurarsi che non vi siano problemi in tal senso.
162

L’”affollamento” del sottopavimento è dovuto al fatto che le installazioni successive di macchine
nuove
e le rimozioni di altre sono talvolta condotte, per motivi non sempre tecnici, lasciando al loro
posto i vecchi cavi, ormai sconnessi, per evitare di turbare “equilibri” talvolta delicati e
aggiungendo
i nuovi.
I ca vi in fibra ottica, attualmente molto diffusi,
richiedono meno spazio rispetto a cavi di vecchia
generazione, anche se sono più sensibili a problemi
di natura meccanica.
Il posizionamento delle apparecchiature deve tenere conto anche dei requisiti ambientali in termini
di
temperatura ed umidità; un posizionamento non adeguato potrebbe creare all’interno di un
medesimo ambiente zone con differenze anche forti in questi valori che potrebbero creare problemi
nella rilevazione, ad esempio, della temperatura finalizzata al controllo dei sistemi di
raffreddamento.
L’eventuale rumore prodotto dalle apparecchiature, anch’esso comunicato dai produttori, può
inoltre richiedere localizzazioni opportune al fine di assicurare un ambiente di lavoro confortevole e
secondo le norme.
L’esatta (riportata in scala) ed aggiornata disposizione delle apparecchiature delle sale macchine di
ogni impianto informatico dovrebbe essere contenuta in un documento (spesso chiamato layout) sul
quale effettuare e verificare le ipotesi di posizionamento di nuove apparecchiature e/o di rilocazione
delle apparecchiature esistenti; il layout,
inoltre, è un prezioso strumento nel caso in cui personale
esterno
debba intervenire nell’impianto in situazioni di emergenza che possono provocare
l’impossibilità di rapida individuazione a vista di determinati componenti (macchine, quadri
elettrici, interruttori, etc.).
E’ appena in caso di evidenziare che il mancato aggiornamento del layout può essere addirittura più
dannoso della sua assenza a causa delle informazioni errate che se ne potrebbero trarre.
I requisiti elettrici devono essere ben chiari con un certo anticipo al fine di consentire per tempo
l’avvio delle relative attività di preparazione e/o di adeguamento dei locali.
Per quanto concerne la predisposizione degli impianti elettrici, così come per la predisposizione di
una serie di impianti tecnologici, le leggi fanno spesso riferimento alla “regola d’arte” che deve
essere seguita per la realizzazione
dei lavori; questa regola d’arte è indicata da apposite prescrizioni
messe
a punto dal Comitato Elettrotecnico Italiano (CEI) il quale, anche attraverso il sito web
[www.ceiweb.it ], mette a disposizioni, naturalmente a pagamento, tutta la documentazione in
materia. Del CEI fanno parte in qualità di soci una grande quantità di enti e di aziende del settore i
quali contribuiscono con la loro esperienza alla predisposizione delle normative in armonia con gli
enti internazionali del settore.
La CEI fornisce anche indicazioni per quanto riguarda i requisiti sul cablaggio dei locali.
Questo
argomento è di notevole importanza, oltre che per motivi connessi alla sicurezza, anche
perché le necessità di cablaggio possono variare con più frequenza rispetto alle necessità di altre
aree; ciò in quanto le necessità di cablaggio risentono e sono condizionate, ad esempio, dalle
mutazioni nell’assetto organizzativo aziendale, così come dall’introduzione in ambienti preesistenti
di nuove apparecchiature.
Per
fornire un valido aiuto in questo senso, da qualche tempo si sono diffuse le tecniche del
cosiddetto cablaggio strutturato; queste forniscono dei criteri che consentono ai cablaggi di:
163

- essere idonei a supportare ambienti multiprodotto e multifornitore;
- consentire una riorganizzazione fisica in base alle variazioni nella organizzazione aziendale;
- essere scalabili, cioè aperti ad implementazioni future in termini di punti di accesso, quantità
di traffico consentito, etc.;
- essere indipendenti dagli impianti attivi di comunicazione;
- etc.
Lo schema generale di un cablaggio strutturato fa riferimento ad un modello costituito da una serie
di
edifici, posti all’interno di una area privata chiamata generalmente campus, all’interno dei quali
devono essere rese disponibili in determinate aree (work area) le possibilità di accesso ad una rete di
comunicazione che integra gli aspetti legati al trasferimento dei dati, al trasferimento della voce,
etc.
Vi sono diverse normative in materia a livello internazionale, EIA/TIA 568 per il mercato
americano, ISO 11801 per il mercato internazionale, EN 50173 per il mercato europeo, ed altre
ancora. Laddove gli standard internazionali
non dovessero prevedere delle norme (ad esempio per
argomenti
quali infiammabilità dei cavi, emissioni tossiche, sicurezza, etc.) le norme CEI
rappresentano comunque un riferimento sicuro.
Con riferimento al seguente modello
Dorsali
edificio
Centro stella
di piano
Centro
stella
di edificio
Work area
Centro stella di
campus
Dorsali campus
164

il cablaggio strutturato indica e descrive, tra l’altro:
- la topologia del cablaggio;
- i media (cioè i cavi) impiegati per le trasmissioni;
- i connettori;
- le distanze tra le varie componenti;
- le tipologie di verifiche del cablaggio;
- i valori di riferimento per definire le qualità trasmissive;
- le norme di installazione.
Alle modalità di cablaggio che impiegano media di comunicazione convenzionali (principalmente
rame e fibra ottica) si vanno aggiungendo con una frequenza sempre maggiore le modalità di
cablaggio wireless che si basano su trasmissioni radio e non richiedono perciò collegamenti fisici.
Le tecnologie wireless sono, in parte, una alternativa al cablaggio strutturato poiché introducono la
“novità” (che in realtà nei suoi principi risale a Marconi e, temporalmente, al XIX secolo) di una
rete che impiega le onde radio per realizzare i collegamenti.
Per quanto riguarda gli standards internazionali in questo campo, lo IEEE (Institute of Electrical
and Elettronics Engineering) tramite il comitato 802, che si occupa, tra l’altro, della definizione
degli standards per le LAN, ha prodotto e continua a produrre delle indicazioni che vanno sotto la
sigla IEEE 802.11(x).
Un ulteriore punto che deve essere tenuto in considerazione relativamente ai luoghi in cui risiede un
impianto
informatico riguarda i requisiti sulla movimentazione fisica delle apparecchiature.
E’ evidente che il luogo dove si pianifica la installazione fisica di una apparecchiatura deve
consentire il primo ingresso della apparecchiatura stessa e gli eventuali spostamenti che si
rendessero necessari nel tempo. Le apparecchiature, comunemente, vengono trasportate all’interno
di pacchi o casse che ne aumentano l’ingombro rispetto a quello riferito alla macchina in sé e ciò
deve essere considerato per quanto riguarda, ad esempio, l’attraversamento di porte.
Inoltre, nel caso in cui il luogo di installazione risieda su un piano diverso dal piano stradale
bisogna che siano disponibili delle strutture (ad esempio montacarichi) adeguate e commisurate ai
carichi
da trasportare.
Si sottolinea, a questo proposito che la maggior parte delle forniture di apparecchiature prevedono,
a meno di accordi diversi con i fornitori e/o con i trasportatori, la consegna al piano stradale
rimandando al cliente l’approntamento di quanto necessario per il raggiungimento della locazione
definitiva; qualora non vi siano ostacoli di un certo rilievo, in genere, la disponibilità degli operatori
del settore consente di trasportare l’apparecchiatura nel punto desiderato.
E’ bene effettuare per tempo l’esame di questo aspetto per evitare problemi successivi.
Naturalmente, la maggior parte dei punti illustrati assumono una maggiore rilevanza quando si tratta
di impianti informatici in area mainframe, dato che in questi casi i requisiti delle apparecchiature
sono
generalmente più impegnativi; un necessario contributo per affrontare con successo
i problemi
di site preparation presso impianti informatici di grandi dimensioni può essere richiesto ai fornitori
delle varie apparecchiature.
165

Problematiche di site preparation del tutto analoghe a quelle citate si presentano anche in caso di
adeguamenti di locali preesistenti volti a soddisfare nuove normative e/o necessari a consentire il
potenziamento
dei macchinari esistenti; quest’ultima eventualità merita particolare attenzione
specie nel caso in cui l’attività che si deve svolgere prevede la sostituzione di apparecchiature; in
questo caso, l’esame delle due situazioni (la configurazione “vecchia” e la configurazione “nuova”)
viste, per dir così, a regime, cioè quando le nuove apparecchiature hanno preso definitivamente e
completamente il posto delle vecchie, può far ritenere che non siano necessari interventi in termini,
ad
esempio, di potenze elettriche primarie e secondarie necessarie, di spazi fisici, di necessità di
cavi di connessione, di necessità connesse all’impianto elettrico, e così via.
In queste eventualità riveste una importanza fondamentale la schedulazione informatica dei lavori
che,
non di rado, prevede un periodo in cui le apparecchiature vecchie e quelle nuove devono essere
contemporaneamente installate ed operative (periodo di parallelo tra le apparecchiature vecchie e le
nuove); il periodo di parallelo ha una durata dipendente dalle attività che devono essere svolte
(spostamento di dati, creazione di nuovi ambienti applicativi, etc.) e può richiedere anche mesi
dovendo, tra l’altro, essere studiato in modo tale da non limitare le normali attività oltre quanto le
necessità di business consentono.
Con una attenta pianificazione delle nuove installazioni si può ridurre la durata del periodo di
parallelo effettuando per tempo le attività che non richiedono la presenza fisica delle nuove
apparecchiature.
Ad esempio, la installazione di nuove unità a disco in sostituzione di unità obsolete, può richiedere
degli
adeguamenti sul sistema operativo per consentire il supporto delle nuove macchine; in questo
caso potrebbe essere opportuno effettuare l’adeguamento del sistema operativo, comprendendo in
ciò
l’installazione delle modifiche nell’ambiente di test, la verifica dell’ambiente così ottenuto ed il
passaggio
in produzione del nuovo ambiente, prima dell’arrivo dei nuovi dischi limitando così il
periodo di parallelo al tempo strettamente necessario per migrare i dati dalle vecchie
apparecchiature alle nuove.
In ogni caso, qualunque sia la durata del periodo di parallelo bisognerà assicurarsi che tutte le
apparecchiature
siano correttamente installate seguendo i normali criteri di sicurezza ed evitando
situazioni precarie (cavi “volanti”, aree di servizio non disponibili, apparecchiature elettriche di
sicurezza non adeguate, etc.) che possono indurre disservizi imprevedibili oltre che creare
situazioni di pericolo.
Con riferimento alla eventualità di dismissione di apparecchiature, è bene ricordare che sono in
vigore
precise direttive (tra le quali la 2002/96/EC, nota anche come WEEE Waste Electrical and
Electronic Equipment, e successive modificazioni) che regolano l’argomento.
La
necessità della opportuna site preparation riguarda anche i luoghi diversi dalla sala macchine
quali
uffici, filiali, dipendenze, etc. in questi casi le normative possono essere differenti da quelle
previste per la sala macchine di un impianto informatico e, comunque, richiedono uno stretto
coordinamento con i responsabili delle varie sedi al fine di minimizzare i disagi.
Nell’ottica
più volte citata che vede la centralità dell’utente come condizione base, ogni attività di
site
preparation che può avere un qualsiasi impatto sull’utenza richiede un coordinamento con le
funzioni
aziendali interessate ed una chiara e preventiva indicazione specie per quanto riguarda gli
eventuali periodi di mancanza di servizio.
166

E’ importante sottolineare che, come è stato già detto, le attività di site preparation e, in generale, di
pianificazione delle installazioni devono essere condotte con la collaborazione dei fornitori; questa
collaborazione,
nei casi più semplici, può essere ottenuta tramite la attenta consultazione delle
documentazioni relative alle macchine; nei casi meno semplici che coinvolgono apparecchiature di
una certa complessità (come è il caso delle apparecchiature che si possono generalmente catalogare
di area mainframe) la collaborazione si concretizza in riunioni congiunte (cliente e fornitore) di
preinstallazione finalizzate all’esame
di documentazioni (check list di installazione, manuali di
installazione,
etc.) che consentono un esame puntuale delle varie aree che possono richiedere
interventi; è appena il caso di evidenziare che, qualora dall’esame svolto si individuino attività da
svolgere, è buona norma verbalizzare ciò che dovrà essere fatto con la indicazione di un
responsabile della attività e di una data alla quale effettuare una verifica sull’andamento delle
attività stesse; la presenza di un documento chiaro e preciso circa le attività da svolgere è uno
strumento insostituibile specie nel caso in cui alcuni interventi possono avere luogo solo al
completamento di altri, alcuni interventi devono essere fisicamente realizzati da ditte esterne, etc.
5.2 Apparecchiature ausiliarie
E’ opportuno
precisare che, nella pratica, le competenze necessarie per la progettazione dello
hardware ausiliario di un impianto sono talvolta molto ampie, generalmente in proporzione alla
dimensione dell’impianto e possono toccare argomenti, quali elettrotecnica, illuminotecnica,
acustica,
ergonomia, etc.;
inoltre, le conoscenze non riguardano il solo aspetto tecnico specifico,
bensì
anche gli aspetti normativi e legislativi che di frequente richiedono un costante aggiornamento
ed una collaudata esperienza per la “navigazione” tra uno standard e l’altro, una normativa e l’altra,
una “regola d’arte” e l’altra.
A meno
di casi particolari, l’informatico non possiede queste competenze, e d’altra parte, presso gli
impianti
informatici di una certa dimensione, sono presenti dei servizi specifici competenti per la
logistica
e le apparecchiature ausiliarie; il problema può nascere presso quegli impianti medio
piccoli dove non vi sono persone specificamente addette a sovrintendere a questi aspetti; in tal caso
è ut ile disporre di una conoscenza generale in grado di individuare quando
è il caso di rivolgersi ad
uno specialista. In quanto
segue si elencano le principali aree che possono richiedere il progetto e l’installazione di
apparecchiature ausiliarie.
A questo
proposito, le problematiche connesse alla alimentazione elettrica delle apparecchiature è
senza
dubbio
il primo argomento che viene in mente.
Nel campo degli impianti di medio-grandi dimensioni l’argomento è da affrontare sia in termini di
alimentazione primaria sia in termini di alimentazione secondaria o di emergenza; quest’ultimo
punto riguarda anche gli impianti di piccole dimensioni.
Per quanto riguarda l’alimentazione primaria, si tratterà di predisporre, in collaborazione
con il
fornitore di energia, la più opportuna modalità, e le eventuali apparecchiature necessarie, in base
alla potenza elettrica richiesta e ad altri fattori, non ultimi quelli di costo, facendo attenzione a
predisporre il tutto tenendo anche in considerazione le prevedibili necessità future.
Per quanto riguarda invece l’alimentazione di emergenza il relativo progetto è in larga parte analogo
ad ogni altro progetto di attività per il disaster recovery; si tratta infatti di prevedere quanto
necessario per consentire la ripartenza in caso di caduta della sorgente di energia primaria; pertanto,
si procederà con una analisi del rischio che avvenga un disservizio e dell’ impatto che tale
167

disservizio può avere sulle proprie attività; da ciò verranno decisi gli interventi ritenuti più idonei e
giustificati.
Una sorgente di energia di emergenza può avere una durata limitata, quale è ad esempio la durata
prevista da insiemi
di batterie (gruppo di continuità o UPS - Uninterruptable Power Supply ) o una
durata
virtualmente illimitata, quale è ad esempio la durata consentita dai cosiddetti gruppi
elettrogeni i quali operano grazie al carburante che alimenta il motore (frequentemente gasolio).
Spesso le due soluzioni sono utilizzate contemporaneamente in quanto le batterie possono
assicurare la continuità della alimentazione
che il gruppo elettrogeno non consente visto che la sua
attivazione
richiede più o meno tempo.
L’utilizzo delle sole batterie può essere sufficiente nel caso in cui si voglia solo assicurare un
determinato tempo per concludere regolarmente le procedure attive e procedere con lo spegnimento
delle macchine; ciò vuol dire che l’analisi di impatto del fermo delle macchine considera accettabile
il costo aziendale indotto dal blocco delle apparecchiature confrontato
al costo per la acquisizione di
un
gruppo elettrogeno.
L’utilizzo del solo gruppo elettrogeno può essere indicato quando le apparecchiature informatiche
contengono già al loro interno delle batterie in grado di assicurare la continuità operativa fino
all’entrata in funzione del gruppo stesso.
Uno schema logico comprendente gruppo di continuità e gruppo elettrogeno può essere il seguente:
RETE
ELETTRICA
COMMUTATORE GRUPPO di
ca cc
CONTINUITA’
cc ca
GRUPPO
ELETTROGENO
CARICO
E’ molto importante rilevare che i piani di copertura a fronte di cadute della alimentazione primaria,
come ogni piano di disaster recovery, deve essere sottoposto a verifiche periodiche al fine di
168

assicurare la corretta comprensione dei vari ruoli da parte delle persone ed al fine di verificare la
corretta
operatività delle apparecchiature coinvolte.
Naturalmente, le apparecchiature di alim entazione di emergenza, come anche le disponibilità di
energ ia dalla fonte primaria, devono essere riviste in occasione di ogni modifica
ai componenti
hardware
dell’impianto informatico al fine di verificare la loro idoneità
a soddisfare le nuove
richieste
di potenza elettrica.
In questi casi non è sufficiente esaminare le necessità di energia a regime, cioè considerando il
nuovo assetto che si intende raggiungere, bensì è altrettanto importante considerare, e d il non farlo è
spesso fonte di problemi, il periodo di parallelo più o meno lungo che le corrette procedure di
installazione
ed avvio in esercizio richiedono; infatti, è piuttosto
frequente il caso in cui
apparecchiature nuove ed apparecchiature esistenti, ma destinate alla sostituzione, devono
coesistere
per periodi anche lunghi (giorni o mesi) al fine di effettuare in sicurezza le attività di
migrazione; ciò induce un determinato carico elettrico che, per quanto destinato a diminuire
a
regime,
deve comunque essere soddisfatto; in questi casi la stessa attenzione deve, naturalmente,
essere dedicata alla predisposizione dei punti di
connessione per le varie macchine e dei relativi
impianti
di sicurezza elettrica.
P er quanto concerne la predisposizione delle apparecchiature di alimentazione secondaria,
vale la
pen a di ricordare che:
- l’analisi del rischio di black out può anc he portare a decidere di escludere alcune
apparecchiature dalla alimentazione di emergenza, garantendo l’operatività solo per quelle
giudicate indispensabili
- una volta definita la lista delle apparecchiature che devono essere alimentate in continuità
la
somma dei KW da esse richiesti, aumentata di un 30 – 50 % per tenere conti di eventuali
dimenticanze e di contenute variazioni future nelle configurazioni, fornisce il
dimensionamento del gruppo di continuità (attenzione alla conversione d a K W in KVA –
KVolt-Ampere per tenere conto del cos φ ; KW /0.8 = KVA)
- il carico cui deve far fronte il gruppo elettrogeno deve includere non so lo il carico del
gruppo di continuità ma, almeno, anche il carico prodotto dalle apparecchiature non
informatiche il cui funzionamento è indispensabile in caso di black out prolungato (ad
esempio i condizionatori) e che generalmente non sono in continuità
- assicurare l’alimentazione delle apparecchiature informatiche anche in caso di black out di
lunga durata può non essere razionale se non si assicura anche l’alimentazione di emergenza
agli utenti, includendo in ciò anche eventuali apparati di rete.
La
seconda area che può richiedere interventi specifici è quella del condizionamento ambientale. In
relazione a questo argomento, la differenziazione delle necessità tra impianti
medio-grandi e piccoli
impianti è ancora più netta; infatti, gli impianti medio-grandi hanno ancora
una struttura dedicata ad
osp itare le macchine, la sala macchine appunto, mentre negli impianti di piccola
dimensione le
apparecchiature sono collocate negli stessi locali che ospitano gli uffici ed il personale.
C hi ha avuto la possibilità di seguire l’evoluzione di un impianto di medio-grandi dimensioni ha
sicuramente assistito alla drastica riduzione degli spazi occupati dalle unità di elaborazione
di tipo
mainframe
avvenuta, come già detto, con il passaggio dalle apparecchiature basate su tecnologia
bipolare alle apparecchiature basate su tecnologia CMOS.
Anche
le unità di memorizzazione di massa hanno avuto e continuano ad avere un trend in continua
crescita
in termini di GB/mq.
169

Proporzionalmente alla riduzione degli spazi occupati si sono ridotte anche le necessità di
raffreddamento degli ambienti, e sono scomparsi gli impianti per il raffreddamento ad acqua (anche
se sotto il pavimento di qualche sala macchine giacciono, forse, ancora decine di metri di tubi non
p iù utilizzati).
In alcuni casi gli spazi liberati sono stati parzialmente occupati da batterie di servers che l’avvio
della centralizzazione ha ricondotto all’interno delle sale macchine, tuttavia, laddove sono
rimaste
le stesse apparecchiature di condizionamento, pur regolate al minimo, la temperatura presente in
queste glass house è piuttosto rigida.
Quando le glass house erano occupate dai mainframe di vecchia tecnologia, la distribuzione
delle
numerose
boxes era stabilita dal costruttore in base alle necessità di collegamento e tenendo anche
conto, tra l’altro, della emissione di calore da parte di ciascuna box al fine di ottenere
una
distribuzione
uniforme del calore all’interno dell’ambiente; perciò al responsabile dell’impianto
veniva fornita una piantina contenente il layout de lla installazione. La disposizione
delle varie unità all’interno di una sala macchine è oggi, invece, una attività a
carico di chi gestisce l’impianto visto che le apparecchiature sono generalmente
di fornitori diversi
e vengono installate in tempi diversi; è importante pertanto leggere attentamente le caratteristiche di
ogni macchina che deve essere installata al fine di trovare il migliore luogo di installazione anche in
considerazione
della necessità di assicurare la giusta temperatura all’intero ambiente. Nel caso di
sale macchine particolarmente affollate di apparecchiature può essere consigliabile richiedere
l’ intervento di un esperto per lo studio dei flussi all’interno del locale.
Assieme
ai controlli per la temperatura, presso gli impianti di grandi dimensioni era effettuato
anc he un controllo della umidità per assicurare ch e il valore fosse entro i limiti indicati
dai
costruttori per un corretto funzionamento delle apparecchiature.. P er quanto le necessità di controllo ambientale siano significativamente diverse rispetto a quelle di
u na decina di anni fa, nel caso di installazione ex no vo di apparecchiature di fascia mainframe
continua, in genere, ad essere necessaria una sala macchine dedicata presso la quale si assicurino le
condizioni operative indicate dai costruttori.
P er quanto riguarda, invece, gli impianti di piccole dimensioni basati su minicomputer e/o personal
computer,
non vi sono particolari misure da adottare relativamente al condizionamento ambientale
risultando generalmente sufficienti i normali accorgimenti idonei a creare un confortevole ambiente
di
lavoro per chi vi opera.
Le ulteriori apparecchiature ausiliarie necessarie riguardano gli aspetti della rilevazione ed
estinzione degli incendio, del controllo accessi, della mo bilità interna, etc.
N el progetto di un impianto informatico o, più comunemente, di una va riazione ad
un impianto
informatico esistente si è spesso portati ad indagare in dettaglio sui tempi di consegna di una certa
apparecchiatura o di un certo prodotto software, sui tempi necessari alla installazione di una nuova
procedura, o altro tipicamente informatico; la pratica invita, invece, a non trascurare gli aspetti
connessi alle apparecchiature ausiliarie ed ai servizi ausiliari in genere per l’ottenimento dei
quali
sono spesso coinvolti aspetti burocratici e contrattuali talvolta piuttosto lunghi.
170

I LUOGHI – Domande di verifica
1 la "site preparation" si occupa
degli aspetti contrattuali
connessi al personale
informatico
della predisposizione dei
luoghi che ospiteranno
apparecchiature
dell'acquisto di software
Commenti: ………………………………………………………………………………….. ………………………………………………………………………………………………. 2 le attività di site preparation che possono avere
ripercussioni sui servizi agli utenti
n on devono avvenire
devono essere concordate
con gli utenti
possono essere svolte anche
senza preavviso
Commenti: ………………………………………………………………………………….. ……………………………………………………………………………………………….
3 i dati riguardanti l'ingombro fisico di una nuova alla direzione immobili della
apparecchiatura devono essere richiesti propria azienda
agli operatori
al fornitore
Commenti: ………………………………………………………………………………….. ……………………………………………………………………………………………….
4 g razie alla progressiva diffusione della tecnologia
CMOS in sostituzione della tecnologia bipolare, le
sono aumentate
necessità in termini di spazi richiesti, di potenza sono rimaste invariate
elettrica necessaria e di condizionamento ambientale
si sono ridotte
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
171

5 le aree di servizio di una apparecchiatura sono i settori applicativi in cui è
utilizzata
gli spazi richiesti per poter
effettuare interventi sulla
apparecchiatura
i pannelli di alimentazione
da cui l'appare cchiatura
preleva l'energia
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
6 in genere, la c onsegna di una apparecchiatura è direttamente all'interno della
prevista sala macchine
al piano stradale
contrassegno
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
7 per "periodo di parallelo" si intende la contemporanea presen za
d i macchine alcune delle
quali saranno dismesse
contemporanea presenza
di macchine disposte
fisicamente in parallelo
presenza di personale in prova
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
8 il "periodo di parallelo"
può durare al massimo 8 ore
al massimo 7 giorni
anche diversi mesi
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
172

9 il pavimento sopraelevato è utile, tra l’altro, per il passaggio dei cavi
l'accesso alle macchine
una migliore visibilità della
sala macchine
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
10 i criteri del cablaggio strutturato
tendono a garantire un costo di realizzazione
tra l'altro basso
la scalabilità del cablaggio
l' accesso ai principali service
provider
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
11 le norme del cablaggio strutturato danno, tra sistemi operativi da
l'altro, indicazioni
su impiegare
tipi di connettori
tipi di CPU
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
12 i cavi di collegamento che possono essere impiegati esclusivamente in fibra ottica
in un cablaggio strutturato sono
escusivamente in rame
entrambi
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
173

13 nell'area del cablaggio
strutturato, per gli argomenti bisogna attenersi alle norme
non trattati dalle norme internazionali CEI
si può fare come si vuole
bisogna attenersi alle norme
sulla privacy
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
14 il cablaggio strutturato fa riferimento ad un modello una serie di edifici sparsi in
costituito da una vasta area geografica
un solo edificio
una serie di edifici sparsi in
una area privata
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
15 cosa è il layout di una sala macchine l'uscita di emergenza
la pianta in scala della
disposizione delle macchine e
degli impianti
gli output di stampa prodotti
Commenti: …………………………………………………………………………………..
……………………………………………………………………………………………….
174

6 L’AMBIENTE ESTERNO
Obiettivi del capitolo
- conoscere le realtà con le quali gli addetti ad un impianto informatico entrano
in contatto
- imparare a stabilire rapporti efficaci con l’ambiente esterno
- prendere coscienza dell’importanza e della complessità dei contratti che
regolano il settore informatico
175

6.1 I clienti
Come è stato più volte ripetuto, un impianto informatico, in fondo, non è diverso da qualsiasi altra
realtà di tipo commerciale e si giustifica in quanto ha dei clienti cui fornisce qualcosa.
Un impianto informatico, fino a qualche anno fa, aveva esclusivamente clienti che si possono
definire interni,
cioè appartenenti alla stessa azienda/ente, che richiedono all’impianto i servizi
informatici per svolgere le proprie attività; per indicare questo tipo di “clientela” più o meno
“costretta” ad utilizzare l’impianto informatico interno si usa spesso il termine inglese “captive” e si
parla, perciò, di clienti captive, utenza captive, mercato captive, etc.
Si parla di captive, insomma, tutte le volte in cui c’è uno che vende qualcosa a qualcun altro che, a
sua volta, ha una qualche forma di obbligo o di viva raccomandazione a rivolgersi al primo per
quell’acquisto.
Il termine captive indica qualcosa che nulla dovrebbe avere a che fare con i clienti, però, in effetti,
molto spesso
rappresenta bene il rapporto di “prigionia” che si instaura tra l’impianto informatico e
la sua clientela
interna.
A tutti, per un motivo o per un altro, sarà capitato di rivestire le scomode vesti di appartenenti ad un
mercato captive di altri, basta pensare al caso in cui ci si deve rivolgere, per ottenere informazioni,
certificazioni, o altro, ad un determinato ufficio che, in esclusiva, può fornire il servizio richiesto.
Tuttavia, è evidente che un rapporto basato sull’obbligo di una parte di ricorrere all’altra per
ottenere delle cose è la maniera migliore per rendere i servizi poco efficienti e di scarsa qualità, al
punto che l’instaurarsi di rapporti del genere
ha contribuito alla incontrollata diffusione della
informatica
distribuita, e, talvolta, al diffondersi delle metodologie di outsourcing dei servizi
informatici, anche se non sempre questi rimedi si sono poi rivelati all’altezza delle aspettative.
Per quanto l’importanza strategica che riveste la completa soddisfazione dei clienti per la
sopravvivenza di qualunque azienda sia cosa tanto evidente da non richiedere nessuna
dimostrazione, questo concetto ha prodotto una vastissima quantità di studi e di teorie che sono state
alla base del concetto di qualità nella gestione aziendale.
Infatti,
la ricerca della qualità nella gestione aziendale come prerequisito al successo delle
organizzazioni vede nella soddisfazione del cliente uno tra gli obiettivi più importanti se non il più
importante.
La qualità di una azienda è oggi testimoniata da specifiche certificazioni che dovrebbero servire
come biglietto
da visita di chi le possiede assicurando i clienti, tra l’altro, sulla bontà dei processi
impiegati
ed autorizzando nei clienti stessi l’aspettativa di un alto livello di soddisfazione nel
rapporto
con l’azienda certificata.
Sfortunatamente, a tale riguardo non sono rare le sorprese
e, in generale, pur non volendo entrare
nello specifico
delle metodologie di certificazione della qualità delle aziende, sulla certificazione
dei certificatori,
etc., si ritiene importante sottolineare che se l’acquisizione di un riconoscimento
più o meno
ufficiale è visto esclusivamente come strumento per potere operare sul mercato (ad
esempio, per poter partecipare a gare indette dalle pubbliche amministrazioni) il tutto comporta
perdita
di tempo, di denaro e, prima o poi, di clienti.
176

Laddove, invece, la ricerca della qualità nelle attività aziendali è vista come il principale strumento
quotidiano e strategico di successo, allora la soddisfazione dei propri clienti sarà elevata e la
redditività
aziendale sarà prossima ai massimi livelli raggiungibili.
Su questa base, la soddisfazione dei clienti interni di un impianto
informatico deve essere posta in
cima
alle attenzioni degli addetti ai lavori; l’impianto informatico deve essere considerato, infatti,
come una azienda all’interno della azienda, e deve giustificarsi, in un’ottica di libero mercato,
dimenticando ogni approccio di tipo captive e confrontandosi, in termini
di prezzo/prestazioni, con
le altre realtà alternative che possono proporsi per fornire i medesimi servizi.
Tra l’altro, la soddisfazione dei clienti interni, altro non è se non un passo necessario per
conseguire, a livello aziendale, la soddisfazione dei clienti esterni; ciò in quanto i servizi che
vengono forniti ai clienti interni sono, generalmente, strumentali alla fornitura di servizi e/o di
prodotti all’esterno dell’azienda.
Un approccio che ponga al centro dell’attenzione i clienti, è oggi sempre più necessario alla luce del
fatto che, con la diffusione di internet, anche i clienti esterni entrano direttamente in contatto con i
servizi degli impianti informatici aziendali e, addirittura, sempre più di frequente il primo impatto
tra una azienda ed un potenziale cliente avviene tramite la rete e la qualità di questo impatto è in
gra do di
determinare l’instaurazione o meno di un rapporto commerciale.
La strada
verso la soddisfazione del cliente di un impianto informatico, come in tutti gli altri casi,
ha alcune
pietre miliari che rendono più sicuro il cammino.
Per prima cosa è necessario accertarsi che il cliente sia davvero un cliente; la ricerca della
soddisfazione del cliente non deve far perdere la bussola al punto da essere esageratamente
disponibili ed assecondare richieste che non hanno i necessari livelli di autorizzazione; i rapporti tra
l’impianto informatico ed il resto della azienda/ente devono necessariamente sottostare a regole
piuttosto precise; negli impianti di grande dimensione queste regole sono per lo più codificate nei
manuali che regolano le procedure interne e ogni settore, gruppo, o altra entità ha una o più persone
che hanno l’autonomia di fare richieste così come di accettarle; attenersi alle regole non vuol dire
essere pignoli o eccessivamente formali o altro ancora, vuol dire, semplicemente rispettare quei
procedimenti che sono stati definiti come ottimali ed in grado di assicurare omogeneità, eventuali
priorità e controllo delle attività; un comportamento diverso, per quanto, specie nelle giovani leve,
dovuto ad inesperienza, crea in genere situazioni inefficienti e di potenziale disallineamento, se non
addirittura confusione, cosa che, in realtà, capita non di rado presso gli impianti di piccola
dimensione con una carente strutturazione dei processi dove comportamenti estemporanei
producono, prima o poi, effetti negativi.
Inoltre, ovviamente, è necessaria la comprensione delle necessità del cliente; a questo proposito
bisogna osservare che,
in genere, il cliente esprime le proprie necessità dal suo punto di vista e con
linguaggio
tecnico tipico della sua area applicativa; l’uno e l’altro possono richiedere numerosi
approfondimenti; pertanto, chiarire, si potrebbe dire, non è mai abbastanza e, principalmente, non è
disdicevole; inoltre, quanto detto presuppone che l’interlocutore abbia perfettamente chiari i suoi
obiettivi e, in sostanza, ciò che vuole, eventualità,
questa, non sempre scontata; a questo proposito,
è molto importante sottolineare che confessare di non aver capito può essere, tutto sommato, un
segno di maturità e, principalmente, può evitare grattacapi futuri.
Altro punto saliente nei rapporti con il cliente è la chiarezza; ciò vuol dire, tra l’altro, formalizzare i
vari momenti di analisi e, principalmente, le conclusioni che si raggiungono al fine sia di assicurarsi
di essere giunti alle stesse conclusioni sia di avere una traccia che contenga gli obiettivi delle
177

attività e le metriche per la misurazione dei risultati che via via saranno raggiunti; la
documentazione delle varie attività non va vista come un segno di sfiducia nel proprio interlocutore,
ma come uno strumento in grado di aiutare a raggiungere l’obiettivo comune.
Tornando per un attimo all’argomento “qualità”, i vari momenti descritti prima dovrebbero
dettagliatamente essere contenuti nei manuali di qualità, cioè nei manuali che descrivono le
modalità con cui la singola azienda ha deciso di condurre i propri processi, sia interni sia rivolti
all’esterno.
Un impianto informatico ha, ovviamente, un costo per l’azienda in termini di persone e di
strumenti;
normalmente queste costi vengono ripartiti alle varie strutture aziendali in funzione dei
servizi che queste ricevono dall’impianto; queste ripartizioni vengono effettuate tramite le
cosiddette procedure di accounting, variabili da azienda ad azienda, che hanno appunto lo scopo di
evidenziare
e quantificare i rapporti cliente/fornitore interni alla medesima azienda.
L’assenza di un sistema interno di ripartizione dei costi non solo induce a vedere le strutture di
servizio come puri costi, ma, allo stesso tempo, tende a sopravvalutare i risultati di quei settori
“clienti” che utilizzano i servizi senza, sostanzialmente, pagarne l’onere.
6.2
I fornitori
La seconda grande area che compone l’ambiente esterno all’impianto informatico è quella dei
fornitori.
Molte osservazioni fatte in merito
ai clienti si applicano altrettanto bene a proposito dei fornitori; ad
esempio, si può affermare, per quanto possa sembrare a prima vista singolare, che un obiettivo
importante è la soddisfazione dei fornitori.
I propri fornitori, infatti, sono uno degli anelli della catena che porta alla soddisfazione dei propri
clienti; in tal senso, l’instaurarsi di un rapporto non conflittuale, improntato ad una proficua e
duratura
collaborazione non può che portare beneficio alla migliore conduzione di tutte le attività.
Vale l a pena di soffermarsi brevemente sul concetto di “proficua e duratura collaborazione”.
Al di là delle prese di posizione di ampio respiro:
- per l’impianto informatico la collaborazione con un fornitore è proficua se i prodotti ed i
servizi che quest’ultimo fornisce consentono all’impianto di rispettare i propri requirements
tecnico/finanziari nei tempi previsti;
- per il fornitore, dall’altra parte,
il rapporto è proficuo se da esso ottiene i ricavi attesi nei
tempi previsti (per comprendere quest’ultimo punto si consideri che, spesso, i piani delle
aziende fornitrici prevedono dei momenti di consuntivazione periodica, tipicamente
trimestrale, all’interno dell’esercizio annuale che, si ricorda, può non coincidere con l’anno
solare; all’approssimarsi di queste scadenze vi è in genere una accelerazione delle azioni di
marketing volte a “chiudere” le varie trattative);
- per entrambi il rapporto sarà duraturo se ciascun attore avrà, per così dire, la giusta
considerazione delle necessità dell’altro e le eventuali necessità connesse alle specifiche
scadenze di cui si è detto non siano talmente pressanti da sovrastare i contenuti strategici del
rapporto.
178

In tema di fornitori, la prima categoria è rappresentata dai fornitori di prodotti hardware, di prodotti
software di base e middleware e di prodotti applicativi.
È opportuno fare una precisazione che può essere utile per individuare gli interlocutori che, in veste
di fornitori, hanno a che fare con gli impianti informatici.
Le organizzazioni dei principali produttori informatici si evolvono, nel tempo, in base alle strategie
con le quali le società decidono di realizzare la copertura del mercato.
Diversi anni fa sul territorio erano presenti strutture locali (filiali, uffici, etc) direttamente
dipendenti
dai produttori con il compito di seguire commercialmente aziende ed enti di varia
grandezza in tutti i settori di mercato (Banche, Piccole e Medie Imprese, Pubblica Amministrazione,
etc);
questo tipo di organizzazione variava da fornitore a fornitore in base al fatto che le rispettive
impostazioni volessero privilegiare:
- una organizzazione interna focalizzata sui prodotti; in questo caso la diretta responsabilità
commerciale era degli specialisti di prodotto (mainframe, minicomputer, storage, printer,
personal computer, etc.) che coprivano i vari settori di mercato richiedendo, all’occorrenza,
l’intervento di specialisti sulle problematiche applicative dei vari settori di mercato
- una organizzazione interna focalizzata sui settore di mercato; in questo caso la diretta
responsabilità commerciale era degli specialisti delle problematiche dei singoli settori di
mercato (settore bancario, settore assicurativo, settore industriale, settore commercio e
distribuzione, settore pubblica amministrazione, etc.) i quali, all’occorrenza, coinvolgevano
specialisti di prodotto
in realtà, all’interno di uno stesso fornitore, i due tipi di organizzazione si alternavano e si alternano,
più o meno periodicamente, in base a mutazioni nelle tendenze del mercato, a mutazioni nella
direzione aziendale, etc.
Successivamente, per contenere i costi, anche i fornitori che avevano strutture dirette capillarmente
diffuse hanno cominciato ad impiegare partners esterni affidando ad essi il compito di coprire fette
di mercato sempre più ampie a partire dal mercato delle piccole e medie aziende e/o dai prodotti
tipicamente rivolti alle piccole utenze; in tal modo, l’intervento diretto dei costruttori in qualità di
fornitori
diretti è oggi, specie in ambiti geografici definibili periferici, per lo più presente solo
presso le grandi aziende ed i grandi enti.
Si sono sempre più diffuse, perciò, organizzazioni tecnico-commerciali per la distribuzione e la
rivendita di prodotti hardware e prodotti software; a parte, quindi, le realtà dei grandi clienti e dei
grandi impianti informatici, i fornitori commerciali diretti sono in genere figure intermedie le quali,
spesso, arricchiscono con contenuti originali (ciò che in gergo si definisce “valore aggiunto”) le
soluzioni proposte.
In particolare, le organizzazioni con le quali più di sovente si ha a che fare quali fornitori sono i
rivenditori, i quali, a loro volta, si approvvigionano in genere dai distributori i quali, concludendo la
catena,
acquistano direttamente dai costruttori.
I distributori non interagiscono direttamente con gli utenti finali.
Le strutture dirette dei produttori continuano ancora, talvolta, ad essere presenti sul territorio, ma, in
genere, meno capillarmente e/o con un numero di addetti meno numeroso.
179

Nel caso in cui una piccola azienda o un ente locale abbia necessità di acquisire un personal
computer e/o dei prodotti software, deve entrare il contatto con uno o più rivenditori i quali
propongono i prodotti richiesti, arricchiti talvolta da propri servizi (ad esempio assistenza per la
installazione)
e/o prodotti.
Non è raro il caso
in cui differenti rivenditori propongano medesime apparecchiature,
differenziando
l’ offerta grazie ai propri servizi e/o prodotti o, semplicemente, cercando di essere
più attraenti dal punto di vista dei prezzi; il rivenditore che si aggiudica la fornitura acquisisce
generalmente quanto
necessario da un distributore, il quale può evadere la richiesta con i prodotti
che ha già a disposizione o tramite un ordine al produttore.
Il distributore, nella catena commerciale, è l’unico che dispone a magazzino di certi quantitativi di
prodotti per evasioni immediate; questo non avviene per i rivenditori se non per quantità molto
limitate.
I distributori provvedono a costituire il proprio magazzino con i prodotti che, in base alla propria
esperienza, ritengono di più facile evasione; essi, inoltre, pongono in essere iniziative speciali
(sconti, campagne, premi, etc) al fine di orientare opportunamente le richieste del mercato ed
impedire
che alcuni prodotti rimangano invenduti.
Le strutture dei rivenditori e ancor più, per chi può accedervi, le strutture dei fornitori sono, per chi
opera
all’interno degli impianti informatici, una fonte molto utile di informazione e di
aggiornamento. Per i clienti di grande dimensione, si può dire che rappresentano una fonte
insostituibile di cultura sia
in area tecnica sia, spesso, in area organizzativa e gestionale.
Per quanto la catena commerciale allontani l’utente finale dal produttore, molti produttori rendono
disponibili diversi strumenti (i siti internet sono l’esempio più comune) per consentire agli utenti di
entrare in contatto con essi sia per problematiche tecniche sia per problematiche commerciali.
Come si diceva prima, la maggior parte delle osservazioni fatte in merito ai clienti valgono anche in
merito ai fornitori:
- individuare esattamente il ruolo del proprio interlocutore nella catena commerciale ed
all’interno della sua organizzazione è di grande ausilio per riuscire a valutare il giusto peso
di determinate affermazioni, assunzioni di responsabilità, assicurazioni, etc. insomma, è
importante assicurarsi di discutere i vari argomenti con l’interlocutore giusto;
- chiarire quanto più possibile i vari argomenti, con particolare riguardo agli obiettivi ed ai
risultati che si intendono raggiungere, contribuisce ad evitare problemi in futuro;
- verbalizzare le decisioni prese, le richieste fatte, le risposte ottenute, etc., contribuisce
a
rendere più chiari i rapporti
La gestione di fornitori di servizi complessi, tra i quali l’outsourcing e lo sviluppo ad hoc di prodotti
software applicativi, necessita di un approccio sistematico e formale del tutto speciale e richiede
competenze sia informatiche sia giuridiche e contrattuali.
In questi casi, infatti, si passa da una prassi intesa a regolare rapporti tra strutture interne all’azienda
alla necessità di instaurare precise regolamentazioni per transazioni di mercato; i rapporti interni
non necessitano, solitamente, di una vero e proprio contratto (per quanto, come si è detto prima, si
tratta comunque di un rapporto che deve essere visto come un rapporto "cliente-fornitore"), mentre
nel caso in cui gli stessi servizi rappresentano una transazione tra aziende diverse è ovviamente
necessaria una appropriata disciplina contrattuale
180

In base alla attività che si svolge all’interno di un impianto informatico, si avrà poi a che fare con un
folto gruppo di altri fornitori, tra i quali
- fornitori di servizi vari (energia elettrica, telecomunicazioni, predisposizioni ambientali,
sicurezza, smaltimento rifiuti speciali, etc.);
- fornitori di servizi informatici (outsourcing totale o parziale, risorse umane aggiuntive per
specifici progetti, etc.);
- società di analisi di mercato (Gartner Group, IDC, etc.);
- etc.
Tra i fornitori possono
essere inclusi i consulenti in area informatica.
Il parere di un consulente è richiesto tutte le volte che nell’organico dell’impianto informatico non
sono presenti le conoscenze necessarie e sufficienti per prendere delle decisioni; questa eventualità
è del tutto comune presso gli impianti di piccola dimensione dove può non essere giustificata la
presenza in organico delle competenze richieste; non dovrebbe, in generale, essere altrettanto
comune
presso gli impianti di grandi dimensioni se non sporadicamente e/o per argomenti che
richiedono una grande specializzazione (ciò, naturalmente, se si da per scontato che al personale
non si facciano mancare i mezzi finanziari per poter curare il proprio aggiornamento e la propria
crescita professionale); eppure, nella realtà, dal punto di vista dei consulenti informatici, il mercato
delle grandi aziende è senza dubbio quello più redditizio.
L’intervento di consulenti esterni presso grandi organizzazioni è richiesto anche quando la direzione
aziendale abbia motivi per effettuare una sorta di verifica sulle capacità e/o sulle scelte del
personale interno; ciò avviene spesso, ad esempio, in occasione di variazioni nell’assetto della
proprietà aziendale o di avvicendamenti nella direzione aziendale; d’altra parte, non è inconsueto il
caso in cui chi opera all’interno di un impianto informatico tenda ad appiattirsi sulle proprie
conoscenze con l’effetto di continuare a percorrere le “solite” strade in ogni occasione; in queste
situazioni l’intervento di un consulente esterno può essere di aiuto, ma può essere di aiuto ancora
maggiore, almeno nel medio periodo, rivedere le procedure di selezione del personale e sostituire le
proprie persone con altre che abbiano un senso critico più spiccato o una maggiore “fantasia” e che
siano, perciò, in grado di non lasciarsi condizionare più del dovuto dalla consuetudine.
Certamente la figura del consulente ha tra i suoi valori aggiunti la familiarità con diversi ambienti e,
grazie a questo, può apportare un significativo contributo in termini di nuove conoscenze; tuttavia,
gran parte di queste conoscenze possono essere acquisite anche, come già detto, dai vari fornitori di
prodotti e servizi i quali, specie nel caso di grandi organizzazioni, sono in genere ben lieti di
effettuare, tra l’altro spesso a costo zero, interventi di approfondimento specifici; si potrà dire che
un certo fornitore non è, come è ovvio, imparziale come dovrebbe essere un consulente; ma a ciò si
può
ovviare con la capacità del proprio personale di comprendere e valutare opportunamente le
cose.
6.3 I contratti in area informatica
Parlando di fornitori è abbastanza naturale toccare anche l’argomento dei contratti che regolano il
campo
dell’Information Technology.
In verità, come già detto, anche il rapporto con i clienti interni ed, ancor più, esterni
dovrebbe essere
gestito
in base a precise regole, tuttavia, specie nel caso di clienti interni, ciò non avviene, se non,
nel
migliore dei casi, con particolari forme di impegni, che spesso vanno sotto il nome di Service
181

Level Agreement (SLA), tramite i quali ci si impegna in maniera informale “a fare il possibile” per
assicurare determinati livelli di servizio (in termini di continuità operativa, sicurezza, prestazioni,
etc.).
L’espressione “contratti informatici” ha assunto ultimamente un duplice significato, l’uno del tutto
distinto dall’altro:
- contratti che regolano il rapporto tra un fornitore di prodotti e/o servizi informatici ed i suoi
clienti;
- contratti che regolano il trasferimento di beni di qualsiasi natura realizzati tramite l’impiego
di tecniche informatiche (ad esempio l’e-commerce)
Per
essere più chiari, contratti che hanno come oggetto di scambio un bene informatico e contratti
che hanno come oggetto di scambio qualsiasi altra cosa ma che si realizzano con l’impiego di
strumenti informatici.
Per quanto concerne il secondo punto la materia, piuttosto giovane, è in via di definizione ed in
continua evoluzione.
Per quanto riguarda, invece, il primo punto, schematicamente l’oggetto di un contratto in area
informatica può essere :
- un componente hardware, cioè una parte meccanica e/o elettronica che fa parte di un sistema
di elaborazione;
- un componente
software che può essere di base, middleware o applicativo;
- un servizio informatico che può assumere le forme più svariate, dalla manutenzione delle
apparecchiature alla predisposizione di un complesso di programmi applicativi
I contratti relativi ai prodotti hardware possono essere facilmente qualificati se non fosse che,
spesso, un prodotto hardware include alcune componenti software (come, ad esempio, un sistema
operativo o anche un microcode, cioè del software incluso nella apparecchiatura e che ne determina
il funzionamento logico).
I contratti relativi ai prodotti software hanno diversi punti in comune con i contratti che riguardano
le creazioni intellettuali e le opere dell’ingegno; questa opera dell’ingegno, naturalmente, richiede
spesso un supporto fisico per la sua distribuzione cosa che, però, non toglie la sua appartenenza alla
famiglia dei prodotti immateriali. In questo senso le norme tendono a riservare all’autore del
software alcune prerogative; questa area è oggetto di vivace dibattito alla luce anche delle
divergenti impostazioni concettuali dei sostenitori del free software e del software proprietario.
Si ricorda che il free software non differisce dal software proprietario per l’assenza di uno
strumento normativo che regoli l’uso che si può fare di un determinato prodotto, bensì differisce in
ciò che è considerato lecito ed illecito dal relativo contratto che, in una forma o nell’altra e con
diverse ramificazioni, comunque esiste ed è necessario.
Una complicazione legale connessa al software è rappresentata dal fatto che la sua duplicazione è,
tecnicamente, piuttosto agevole e non richiede particolari
capacità; d’altra parte, l’utilizzo di un
software richiede però necessariamente la realizzazione di una copia per trasferire il prodotto dal
supporto con cui è distribuito al supporto dal quale viene normalmente utilizzato.
182

Già di per sé questi elementi, dal punto di vista contrattuale, sono tutt’altro che insignificanti; il
panorama si arricchisce di ulteriori elementi che necessitano di una normativa se si aggiunge che i
software,
a differenza dei prodotti hardware che vengono in genere realizzati per la generalità degli
utenti, sono spesso sviluppati ad hoc per un utente; ed allora è importante, in fase contrattuale,
stabilire di chi è la proprietà del prodotto finito e come sono ripartite le responsabilità in caso di
mancato raggiungimento degli obiettivi che si sono fissati.
A questo proposito, le norme generali prevedono che un fornitore possa assumere delle obbligazioni
di risultato, cioè l’obbligo contrattualmente garantito a mantenere gli obiettivi stabiliti, o delle
obbligazioni di mezzi, cioè, per dirla in un modo che farà rabbrividire gli esperti di diritto, l’obbligo
a fare del proprio meglio (in termini di capacità delle persone e di qualità degli strumenti impiegati)
ma niente di più.
I più comuni contratti relativi all’hardware configurano generalmente
un rapporto di vendita con
trasferimento della proprietà dal fornitore al cliente a fronte di un corrispettivo (che a sua volta può
essere corrisposto in soluzione unica o meno), o un rapporto di locazione tramite il quale si cede il
godimento di un bene ad un locatario a fronte di pagamenti periodici.
E’ importante rilevare che parlare di trasferimento di proprietà o, alternativamente, di locazione
(che
non prevede il trasferimento della proprietà), implica anche differenti ripercussioni in termini
di imputazioni di bilancio, rilevazione dei costi, gestione degli ammortamenti, etc.; la corretta
indicazione di una scelta a tale riguardo può essere indicata solo alla luce delle strategie e/o delle
necessità aziendali a tale riguardo e presuppongono, perciò, l’intervento delle funzioni aziendali
preposte ad assicurare l’applicazione di tali strategie. In altri termini, la parola finale circa la via
formale da seguire per ottenere la disponibilità di un determinato bene spetta alla direzione
aziendale che ha, naturalmente, un quadro di insieme della situazione e dispone, quindi, di tutti gli
elementi
per effettuare la scelta più opportuna; tale scelta deve essere supportata dal settore IT con
informazioni specifiche quali, ad esempio, le prevedibili evoluzioni tecnologiche, le conseguenti
prospettive di stabilità nel tempo del bene in questione, etc.; se, ad esempio, il prodotto di cui si
tratta l’acquisizione appartiene ad una categoria di prodotti in rapida evoluzione tecnologica o il cui
impiego è previsto per un tempo molto breve, si potrebbe rivelare più opportuna una acquisizione in
locazione nella ipotesi che altre necessità aziendali non consiglino di seguire vie diverse quali
l’acquisto.
I prodotti software sono in genere oggetto di contratti di licenza d’uso più o meno restrittivi
relativamente a ciò che è consentito a chi acquisisce la licenza (i prodotti cosiddetti “a scaffale” cioè
quei prodotti, sviluppati per utenze generiche, normalmente reperibili presso i punti vendita
utilizzano una modalità spesso chiamata “licenza a strappo” in cui la licenza vera e propria è
contenuta all’interno della confezione e si concretizza formalmente nel momento in cui, appunto,
viene “strappato” l’involucro).
Alcuni dei principali argomenti regolati dai contratti di servizio sono:
- i contratti di consulenza, tramite i quali un operatore analizza situazioni e suggerisce
soluzioni;
- i contratti di manutenzione di prodotti hardware o di prodotti software;
- i contratti di sviluppo software, tramite quali, come già detto, un operatore assume
l’incarico di sviluppare dei programmi software a fronte di specifiche del cliente;
- i contratti di facility management e di outsourcing di cui abbiamo parlato;
- etc.
183

Come si è cercato di evidenziare, i contratti informatici sono un argomento complesso che richiede
l’intervento di diverse professionalità per la sua definizione; difficilmente si trovano impianti
informatici all’interno dei quali sono presenti specifiche competenze giuridico legali.
Tra l’altro, la giurisprudenza in materia si va sempre più arricchendo, e ciò richiederebbe specifici
approfondimenti.
Purtroppo, all’interno delle aziende la normativa
inerente ai contratti informatici è, talvolta, un po’
trascurata.
A causa di ciò, ci si può trovare in due situazioni opposte ma ugualmente cariche di rischi dei quali,
però,
non sempre ci si rende conto.
Spesso, dopo avere effettuato tutte le analisi tecniche tipicamente informatiche che il caso richiede,
al momento di concretizzare il rapporto, il fornitore propone i propri moduli contrattuali i quali
vengono mandati, dal cliente, al legale di fiducia richiedendo un consulto attento ma
“estremamente” rapido, caratteristiche che, ovviamente, sono incompatibili e rendono del tutto
inutile il coinvolgimento del professionista incaricato o, addirittura, vengono sottoscritti con la
conseguente accettazione di una serie di clausole redatte dal “punto di vista” del fornitore.
I contratti prodotti dal fornitore, in grande maggioranza, pur generalmente rispettando le leggi, le
quali in caso di clausole illegali comunque prevalgono, tendono ad escludere ogni forma di
responsabilità per il fornitore e riservano allo stesso ogni privilegio ed ogni diritto che pure sarebbe
negoziabile e che, in realtà, è oggetto di negoziazione quando la controparte decide di mettere le
cose in discussione.
Per citare quella che può sembrare la più banale delle clausole, cioè la definizione del luogo di
giudizio dove una eventuale controversia deve essere portata, il cosiddetto “foro competente”, il
contratto del fornitore recherà una indicazione normalmente coincidente con il luogo dove ha sede
la propria struttura legale mentre, a parte eventuali diverse indicazioni di legge, il cliente potrebbe
richiedere un foro competente diverso al fine, nella malaugurata ipotesi di un contrasto da risolvere
per vie legali, di minimizzare le proprie spese per sostenere la partecipazione al giudizio.
Altre volte, la predisposizione contrattuale viene effettuata presso il cliente (caso molto frequente
nella pubblica amministrazione o nel caso di clienti privati di grande dimensione, il cui “potere
contrattuale” è in grado di condizionare i potenziali fornitori) da parte di personale con scarsa
dimestichezza specifica; ciò comporta, ad esempio, l’inserimento nel contratto di una quantità di
clausole e di una tale entità di penali, a scopi cautelativi, che però tali scopi cautelativi
frequentemente non raggiungono; infatti, l’accettazione di clausole così stringenti fa talmente
lievitare i costi da indurre alcuni fornitori a presentare offerte spropositate o a non presentarle
affatto e altri fornitori a presentare offerte economicamente “ragionevoli”, ma che non li coprono
adeguatamente dal rischio di incorrere in inadempienze; quest’ultimo comportamento, essendo
spesso sintomo di un più generale modo di operare scarsamente rigoroso, si accompagna,
frequentemente, al reale insorgere di inadempienze che portano a controversie legali generalmente
di lunga durata; in questa eventualità, se da un lato prima o poi il cliente sarà, forse, indennizzato,
dall’altro lato il suo obiettivo specifico, il cui raggiungimento era vincolato dal servizio o dal
prodotto oggetto del contratto, non viene raggiunto.
Se si osserva che l’obiettivo di ogni cliente dovrebbe essere quello di contribuire a creare le
condizioni più opportune per ottenere dei prodotti e/o dei servizi utili al proprio business e non
184

quello di creare le migliori condizioni per portare in tribunale i suoi fornitori, si comprende che tra
gli
sconfitti in una situazione di lite c’è sicuramente l’azienda o ente cliente.
In entrambi questi casi viene di
fatto a mancare una delle caratteristiche che sono alla base di un
buon
contratto, cioè stabilire, tra due o più parti, delle regole ragionevoli e di comune accordo; il
rapporto infatti risulta, per dir così,
sbilanciato o asimmetrico in quanto è una parte che in sostanza
impone le sue condizioni all’altra; il risultato finale, spesso, è comunque a svantaggio del cliente;
ciò è di facile comprensione nel primo caso in cui è il fornitore a dettare le condizioni, ma
anche nel
secondo caso, in cui è il cliente a predisporre gli aspetti contrattuali, la convinzione di avere
raggiunto una posizione vantaggiosa è largamente bilanciata dal fatto di avere allontanato i fornitori
probabilmente più scrupolosi, aumentando la possibilità di finire in lite con il risultato immediato di
un disservizio nel business aziendale, sebbene con il probabile risultato di un indennizzo in tempi
solitamente
molto lunghi e di dubbia reale consistenza anche in considerazione dell’impegno
eco nomico di cui necessita la conduzione di una disputa legale.
In sostanza si deve avere la convinzione, nel campo dei contratti informatici così come per i
contratti in altri campi, che il contratto deve essere uno strumento utile a stabilire le reciproche
responsabilità
per l’ottenimento di un certo obiettivo in certi tempi; insomma uno strumento per
lavorare
meglio e non una minacciosa spada di Damocle.
In quanto strumento di lavoro, tra l’altro, un contratto neces sita oltre che di cura ed equilibrio per la
sua stesura, anche di qualcuno che sia chiamato a gestirlo, cioè a farne rispettare le regole in corso
d’opera;
non è raro il caso in cui, dopo una lunga e faticosa fase di stesura del contratto, una volta
firmato, venga praticamente archiviato affidando il progetto al solo coordinamento tecnico,
salvo
ritirarlo
fuori nell’esclusivo caso di disputa insanabile quando è ormai troppo tardi per attivare
le
opportune azioni di prevenzione
di comportamenti o situazioni fuori linea.
Sia
nel
caso di clienti di grande dimensione sia nel caso di piccoli clienti, succede anche, spesso,
che si cerchi di definire una specie
di contratto informatico standard, pieno di puntini da riempire, di
volta
in volta, in risposta a domande sempre uguali; questa prassi è in genere errata perché ogni
contratto
informatico, a meno di casi banali, è un contratto a se stante e può richiedere la
precisazione
di cose non richieste in altre circostanze; tutto ciò che si può fare, a questo riguardo, è
stabilire a grandi linee le macrosezione che dovrebbero essere contenute nel contratto, ciò più al
fine di costituire una utile check list di aiuto nella fase di stesura che al fine di includere a tutti i
costi
particolari clausole che possono risultare del tutto fuori luogo, se non per altro per i costi
ingiustificati che possono indurre, in un determinato contesto.
Si pensi, ad esempio, ad una clausola, abbastanza
frequente nei contratti relativi ai servizi di
manutenzione, che impone certi tempi per
la risoluzione
di eventuali malfunzionamenti; non è raro
il caso in cui, una volta realizzato un contratto
a fronte del quale una azienda chiede un tempo di
risoluzione di 8 ore dalla segnalazione a fronte di necessità specifiche connesse all’oggetto del
contr atto, tale clausola con la stessa tempistica si ritrovi anche in altri
contratti, “copiati” dal
precedente,
che però, in base al diverso oggetto e alle diverse necessità, potrebbero non necessitare
di un limite così stringente; se poi si assume che, nella maggior parte dei casi, il limite adottato è
quello più stringente possibile, si capisce come l’azienda vada incontro a spese ingiustificate,
visto
che il probabile fornito re si attrezzerà di conseguenza caricando i relativi costi nella sua offerta, a
causa della incapacità di vedere nel contratto uno strumento variabile caso per caso.
In questo contesto, è anche da evitare il rinvio all’ultimo momento degli aspetti contrattuali anche
nel caso che si tratti di un rapporto da effettuare con un fornitore abituale, con il quale sono stati
definiti altri contratti della stessa tipologia formale; i contratti, si ribadisce, sono, con esclusione dei
185

casi più banali, tendenzialmente differenti da caso a caso, e, anche nei confronti di un medesimo
fornitore,
differenti nel tempo; inoltre, il prezzo di una determinata prestazione è naturalmente
dipendente, tra l’altro, dalle condizioni di fornitura, perciò, se tali condizioni vengono modificate
a lla fine di una trattativa che ha condotto
ad un prezzo, molto probabilmente questo prezzo sarà da
rivedere inducendo così inefficienze e revisioni generalmente evitabili adottando un procedimento
complessivo
più organico ed ordinato che potrebbe vedere le seguenti macro-fasi:
- definizione degli aspetti tecnici
- definizione delle condizioni contrattuali specifiche
- definizione della modalità di acquisizione (ad esempio acquisto o locazion e) e del relativo
prezzo
In definitiva la predisposizione e la gestione di un contratto informatico è, quindi, un lavoro di
gruppo cui devono contribuire, anche se in momenti differenti ma con pari dignità, diverse
professionalità
(informatiche, legali, contabili-fiscali, etc.) al fine di facilitare l’ottenimento del
risu ltato di business che il cliente si pone e, allo stesso tempo, al fine di costituire un ambiente di
collaborazione nella massima chiarezza con il fornitore; alcune di queste professionalità possono
n on essere disponibili all’interno dell’organico di un impianto informatico
e perciò si deve aver cura
di coinvolgerle, per tempo, fornendo ad esse tutte le informazioni tecnico-informatiche che possono
orientare le scelte.
186

L’AMBIENTE ESTERNO – Domande di verifica
1 i clienti "captive" sono clienti
a bassa priorità
come tutti gli altri
ad alta priorità
Commenti:
……………………………………………………………………………………
………………………………………………………………………………………………..
2 gli addetti ad un impianto informatico, prima di con un top manager
avviare un rapporto con un cliente interno è
opportuno che si assicurino di avere a che fare con persona autorizzata in
base alle norme aziendali
non importa con chi basta
che si mostri disponibilità
Commenti: ……………………………………………………………………………………
………………………………………………………………………………………………..
3 quando si instaura un rapporto di lavoro con un non dire mai non ho capito
cliente è molto importante
comprendere al meglio le
richeste dell'interlocutore
parlare solo in presenza del
proprio capo
Commenti: ……………………………………………………………………………………
………………………………………………………………………………………………..
4 l'ampia tematica della certificazione di qual ità
ha come fine ultimo il miglioramento del
rapporto con i superiori
rapporto con la pubblica
amministrazione
rapporto con i clienti
Commenti: ……………………………………………………………………………………
………………………………………………………………………………………… ……..
187

5 la certificazione di qualità e la applicazione dei partecipare ai bandi
relativi procedimenti è utile per pubblici
rendere più efficienti i processi
aziendali
la manutenzione delle
apparecchiature hardware
Commenti: ……………………………………………………………………………………
………………………………………………………………………………………………..
6 il successo delle iniziative nell'area della qualità d al reale impegno sul tema
è condizionato da parte dei manager
a ziendali
dalla buona volontà d ei
singoli
dall'ottenimento delle relative
certificazioni
Commenti: …………………………………………………………………………………… ………………………………………………………………………………………………..
7 l'a ddebito ai clienti interni dei costi dei servizi ricevuti
dall'imianto informatico è effettuato con tecniche di
autonomic computing
personal computing
accounting
Commenti: ……………………………………………………………………………………
………………………………………………………………………………………………..
8 ai fini della efficienza aziendale, la "soddisfazione" di utilità
dei fornitori è
un'invariate
di ostacolo
Commenti: ……………………………………………………………………………………
………………………………………………………………………………………………..
188

9 redigere dei verbali che riportino le decisioni prese una indispensabile attività
durante riunioni di lavoro è per rendere efficaci i lavori
una attività superflua
un segno di mancanza di
filucia nell'interlocutore
Commenti: ……………………………………………………………………………………
………………………………………………………………………………………………..
10 nella catena commerciale i distributori vendono ai grossi clienti
agli utenti finali
ai rivenditori
Commenti: ……………………………………………………………………………………
………………………………………………………………………………………………..
11
al fine di evitare lo studio di specifiche clausole
contrattuali, è buona norma predisporre un
VERO
"contratto tipo" ed applicarlo senza modifiche
in ogni caso
FALSO
dipende dalle modalità di
pagamento
Commenti: ……………………………………………………………………………………
………………………………………………………………………………………………..
12 nella definizione delle varie condizioni contrattuali imporre cautelativamente
relative ad una specifica fornitura, è bene condizioni più stringenti
di quelle necessarie
imporre le condizioni che
sono necessarie nel caso
specifico
definire condizioni fisse
per ogni fornitura ed
imporre queste
Commenti: ……………………………………………………………………………………
………………………………………………………………………………………………..
189

13 un contratto dovrebbe, principalmente, essere uno strumento di pressione
sulla controparte
uno strumento di lavoro
un mezzo per evitare le
proprie responsabilità
Commenti: ……………………………………………………………………………………
………………………………………………………………………………………………..
14 l'acquisizione di prodotti FREE software non richiede VERO
la accettazione di condizioni contrattuali
FALSO
vero solo per i prodotti
acquisiti via internet
Commenti: ……………………………………………………………………………………
………………………………………………………………………………………………..
15 la decisione di approvvigionarsi di un bene tramite all'IT manager
acquisto o tramite una locazione compete, in genere
all'ufficio delle imposte
alla direzione generale o suoi
delegati
190

7 I REQUIREMENTS
Obiettivi del capitolo
- conoscere i principali requirements che un impianto informatico deve
soddisfare
- comprendere la diversa importanza aziendale dei vari requirements
- imparare a soddisfare i diversi requirements in funzione della loro strategicità
nella visione aziendale
- familiarizzare con le tematiche di disaster recovery e business continuity
191

7.1 Generalità
Con il termine
requirements si intendono:
- le condizioni
ed i vincoli che un impianto informatico deve rispettare;
- le esigenze cui deve far fronte;
- i requisiti che deve possedere
Le attività indotte dalla necessità di conseguire i requirements ricadono, in genere, sia nella fase di
progetto sia nella fase di gestione dell’impianto e possono riguardare sia la realizzazione di un
impianto ex novo sia, più frequentemente, la realizzazione di uno specifico intervento, originato da
motivazioni tecnologiche e/o applicative, da effettuare in un impianto informatico già esistente.
I requirements di un impianto informatico discendono dai più generali requirements aziendali i
quali, a loro volta, possono assumere una importanza più o meno strategica; questa sorta di
trasmissione dei requirements lungo le varie componenti aziendali avviene spesso tramite un
sistema di obiettivi che ogni reparto deve raggiungere nella conduzione delle proprie attività; a
titolo di esempio, si pensi ad uno dei requirement generalmente presente in ogni organizzazione: il
requirement
che fissa un tetto di spesa.
Verosimilmente,
sulla base di diversi fattori sia di carattere storico sia di carattere previsionale, una
azienda fissa il proprio obiettivo di spesa complessivo, cioè, semplicisticamente, la cifra che non
deve essere superata per potere ottenere il valore di redditività desiderato; una volta fissato, questo
valore complessivo viene spezzettato secondo opportuni criteri e viene quindi distribuito ai vari
settori aziendali. Assieme all’obiettivo di spesa, ciascun settore aziendale riceve anche altri obiettivi
relativi, ad esempio, alla quantità ed alla qualità dei servizi e/o dei prodotti che quel settore deve
assicurare. I vari settori aziendali, poi, provvedono a ripartire al proprio interno i propri obiettivi in
modo da responsabilizzare adeguatamente le varie funzioni ed i vari reparti. Questo sistema tende a
fare in modo che l’organizzazione nel suo insieme operi in modo coordinato per l’ottenimento dei
requirements complessivi.
In questo senso, quanto più un requirement è strategico e connesso alla realizzazione del modello di
business aziendale tanto più vi sarà disponibilità all’investimento per il suo raggiungimento; la
comprensione del giusto livello di importanza di un determinato requirement può guidare nella
adozione delle misure più idonee per il suo soddisfacimento.
Da questo punto di vista, può essere utile distinguere tra:
- requirements imposti
o da leggi e normative
o da prassi operative
o da motivi tecnologici
o etc.
- requirements semi-imposti
o da “mode”
o da necessità commerciali
o da necessità di immagine
o etc.
- requirements scelti
o per far fronte a strategie di business aziendale
192

I requirements percepiti come imposti e semi-imposti sono in genere visti dal management
aziendale come una “grana” e per il loro soddisfacimento non vi è solitamente una corrispondente
ampia disponibilità di spesa; perciò, la predisposizione di un progetto più complesso del minimo
indispensabile è destinata, in questi casi, a risolversi in una attività inutile poiché ciò che è
esplicitamente o meno richiesto è la minimizzazione degli impatti economici e finanziari.
I requirements scelti, invece, sono visti dal management aziendale come una opportunità da
perseguire al fine di ottenere un vantaggio competitivo per l’ azienda e per il loro soddisfacimento,
seppure entro i limiti di un favorevole rapporto costi/benefici, è generalmente presente una più
ampia disponibilità di spesa in quanto questa è correttamente vista come un investimento che,
almeno nelle attese, porterà dei ritorni.
Sfortunatamente, non vi è univocità nel catalogare i vari requirements o, più correttamente, se sono
facilmente intuibili i requirements non strategici, possono non essere intuibili con altrettanta facilità
i requirements che abbiamo definito scelti; tra l’altro, frequentemente avvengono come dei salti di
qualità nell’importanza che viene assegnata ai vari requirements in base, ad esempio, a cambiamenti
manageriali o a revisioni nei modelli di business aziendale o altro ancora.
Si
è detto che al variare della importanza assegnata ad un certo requirement varia la disponibilità
all’investimento per il suo conseguimento; questo è abbastanza consueto ed è già un buon motivo
per
commisurare gli sforzi progettuali alla rilevanza con cui la specifica problematica è percepita;
tuttavia, si sottolinea che l’aspetto decisamente più importante che si accompagna alla scarsa
disponibilità all’investimento, tipica di un requirement non scelto, è la scarsa disponibilità
manageriale ad assumere efficaci e costanti iniziative in materia, al di là di una formale indicazione
circa l’obiettivo da conseguire.
In altri termini, come si è già detto, le probabilità di successo di un qualsiasi progetto sono
direttamente proporzionali alla reale (e non formale) risolutezza con cui il management affronta la
questione a prescindere, anche se vi è una correlazione, dai budget stanziati.
Un esempio evidente, a questo proposito, è fornito dal già citato campo della certificazione della
qualità aziendale; la stesura dei piani e le azioni da intraprendere come prerequisiti per
l’ottenimento della certificazione di qualità sono attività che richiedono tempo e denaro in misura
variabile
in funzione della reale consapevolezza manageriale dell’importanza dell’argomento.
Se, con un approccio che si ritiene discutibile, l’obiettivo della certificazione è solo strumentale, ad
esempio, ad ottenere un prerequisito per potere svolgere azioni commerciali in determinati ambienti
che dovessero richiederlo, allora probabilmente il tempo ed il denaro di cui viene dotato il progetto
saranno limitati e, principalmente, sarà limitata l’attenzione con cui la direzione aziendale seguirà la
corretta applicazione delle procedure relative; in sostanza si potrebbe dire che, in questo caso, la
certificazione di qualità è considerata, in sé, l’obiettivo e perciò il suo conseguimento sarà visto
come la conclusione dell’attività.
Al contrario, qualora l’interesse sia nei benefici effetti che il rispetto delle procedure di qualità
portano sulla organizzazione aziendale e, conseguentemente, sul business, allora l’interesse
manageriale,
assieme al tempo ed al denaro dedicati, crescerà proprio nella fase di attuazione delle
procedure rendendo possibili gli opportuni interventi a livello gestionale ed organizzativo; in
sostanza si potrebbe dire che, in questo caso, l’ottenimento della certificazione è solo una tappa del
processo complessivo.
I requirements di un impianto informatico possono essere suddivisi tra:
193

- requirements funzionali
o cosa deve fare
o dove e quando
o con quale carico di lavoro (attuale e previsto) e con quali performance
o chi deve operare e quali competenze ha (informatiche e non)
o cosa deve essere prodotto
o Etc.
- requirements economico finanziari
o rispetto budget
o TCO
- requirements connessi all’ambiente informatico
o omogeneità con l’ambiente esistente
o inseribilità nel sistema informativo
o riusabilità hardware e software
o congruenza con i piani futuri e le necessità stimate
o Etc.
- requirements qualitativi e strategici
o Sicurezza
o continuità di servizio (business continuity)
o etc.
Dalla lista precedente si deduce che alcuni requirements sono, per così dire, in contrapposizione con
altri; le necessità connesse ai tempi entro cui un certo progetto deve essere realizzato sono
frequentemente in contrapposizione con tutti gli altri requirements che richiedono adeguati tempi
per la analisi dell’intervento e per una opportuna progettazione; i requirements connessi all’impiego
di un certo prodotto software disponibile sul mercato e giudicato idoneo alle necessità applicative
possono essere in contrasto con l’omogeneità delle scelte in base all’ambiente operativo/applicativo
disponibile; i requirements di tipo economico-finanziario sono poi, in genere, in contrapposizione
con molti altri che in linea teorica, e naturalmente irrealistica, sarebbero più facilmente conseguibili
ipotizzando risorse (macchine, persone, mezzi e, in sostanza, denaro) “infinite”.
Queste contrapposizioni, contrariamente a quanto si potrebbe pensare a prima vista, sono tutt’altro
che negative; il corretto confronto tra le varie componenti, infatti, è spesso un buon metodo per
raggiungere soluzioni equilibrate ed efficienti; ciò naturalmente a patto che tra le varie parti che si
confrontano non ve ne siano alcune dotate di un “potere” nettamente più forte rispetto a quello di
cui dispongono le altre.
Per fare qualche esempio, se la componente che “difende” la minimizzazione dei budget di spesa è
più “potente” delle altre e, anche di fronte a valide motivazioni che richiederebbero una più ampia
disponibilità all’investimento per conseguire determinati vantaggi, riesce ad imporre il proprio
punto di vista, difficilmente la soluzione finale sarà ottimale; lo stesso risultato si ottiene, di solito,
se una parte è così forte da imporre
tempi di soluzione ingiustificatamente incompatibili con una
accurata analisi e con un eventuale necessità di periodi di sviluppo di una certa durata a fronte
dell’ottenimento di soluzioni più stabili e meglio integrate nel contesto esistente; un risultato
altrettanto inefficace si può ottenere quando una parte impone tempi di realizzazione così elevati da
compromettere certi risultati di business dipendenti, ad esempio, dalla tempestività con cui una
certa necessità viene evasa (questi ultimi due esempi rappresentano due delle cause più comuni che
hanno portato, a torto o a ragione, alla proliferazione di soluzioni cosiddette dipartimentali).
194

Il compito di calibrare la “potenza” delle varie parti in causa è, per definizione, a carico della
dirigenza aziendale la quale deve creare le condizioni affinché avvenga un confronto tra diversi
punti
di visti facendo in modo, allo stesso tempo, da non consentire, o addirittura creare, negative
situazioni di predominio nei processi che conducono alla definizione delle scelte; questo compito
non è semplice visto, tra l’altro, che i dirigenti aziendali hanno una specie di “imprinting” derivante
dalla loro estrazione e formazione professionale che può indurli, deliberatamente o meno, a
trasformarsi
da arbitri in giocatori.
In altri termini, un dirigente di estrazione commerciale e di marketing potrà spesso essere indotto a
privilegiare, in caso di contrasti, le motivazioni che provengono dalle funzioni utente rispetto a
quelle che provengono, ad esempio, dall’ambiente IT; così come un dirigente particolarmente
attento agli aspetti connessi ai limiti di budget potrà essere indotto a privilegiarli nei confronti di
visioni più strategiche.
In tutto ciò si inquadrano anche le problematiche connesse agli obiettivi della classe manageriale
nei confronti degli obiettivi della proprietà aziendale (concentrata o distribuita che sia); questo
argomento di grande interesse esula, ad ogni modo, dal nostro contesto e si rimanda, chi desiderasse
approfondirlo, alla consultazione delle relative documentazioni.
7.2 Disaster recovery e business continuity
Tra i vari requirements cui si è accennato, un rilievo sempre maggiore hanno quelli relativi alla
sicurezza, alla business continuity, al disaster recovery ed a tutti gli aspetti volti ad assicurare la
continuità operativa per fornire i servizi, almeno quelli ritenuti indispensabili, ai clienti e, più in
generale, la presenza sul mercato.
La cos cienza del rilievo che possono avere i problemi connessi alla sicurezza ha fatto un salto di
qualit à a causa di una serie di infausti eventi (attentati terroristici, blackout, etc.) che hanno
fatto
capire l’importanza di passare da generiche dichiarazioni di interesse e di intenti sull’argomento ad
un atteggiamento ben più operativo e concreto; gli eventi cui si allude, tra l’altro, hanno reso
lampante il carattere sistemico della problematica evidenziando le connessioni e le ripercussioni
reali che eventi catastrofici di vasta proporzione possono indurre su strutture ed organizzazioni
anche molto distanti sia in termini geografici sia in termini di settori di mercato.
Vale
la pena ribadire che le problematiche citate non sono problematiche di sola competenza del
settore IT, bensì sono problematiche
che coinvolgono l’intera azienda o l’intero ente; ciò vuol dire
che il settore IT è solo uno degli attori che deve intervenire nella definizione dei piani relativi alla
sicurezza; in questo senso per predisporre con successo dei piani di intervento in materia di
sicurezza è necessaria una completa consapevolezza ed un forte impegno da parte del management
o, con una espressione molto significativa, un completo commitment manageriale. Senza un
commitment manageriale nessun piano di disaster recovery potrà mai, nella malaugurata ipotesi in
cui dovesse servire, avere successo.
Sicurezza, business continuity e disaster recovery possono essere viste come tre problematiche con
livello
di generalità decrescente.
La sicurezza
aziendale può essere vista come l’argomento che si occupa di tutte le misure più
opportune per assicurare la sicurezza aziendale in
termini, tra l’altro, di operatività, beni materiali e
beni immateriali.
195

Contribuiscono, a vario titolo e con varie priorità, alla sicurezza aziendale dal controllo degli
accessi, alle procedure per la salvaguardia delle informazioni ovunque e su qualunque supporto
fisico
esse si trovino, dalle procedure per la salvaguardia delle conoscenze, alle procedure per
assicurare la continuità operativa cioè la business continuity, etc.; la business continuity si occupa di
assicurare, in caso di inconvenienti di varia natura, che l’azienda possa continuare ad effettuare le
attività
partendo da quelle ritenute indispensabili; poiché l’attività aziendale è sempre più realizzata
tramite strumenti informatici, nella business continuity entrano fortemente in gioco aspetti appunto
informatici e telematici; il disaster recovery, infine, è una attività volta ad assicurare la business
continuity in casi di inconvenienti di grande portata che comportano anche danni logistici rilevanti.
Se, piuttosto irrealisticamente, vi fosse oggi
una azienda totalmente priva di un qualsiasi supporto
informatico
per la realizzazione delle proprie attività, questa azienda dovrebbe comunque occuparsi
di sicurezza, di business
continuity e disaster recovery analizzando i processi e le informazioni
tramite i quali realizza il suo business, individuando quelli indispensabili per condurre, anche ad un
livello minimo vitale, le sue attività e impostando su di essi dei piani volti ad assicurarne la
disponibilità in caso di inconvenienti di varia natura.
In questo improbabile scenario, si immagini una azienda produttrice di un bene che pone sul
mercato tramite un certo numero di addetti, cui periodicamente spedisce le informazioni sui prodotti
e sui prezzi, che, in diverse zone, visitano i clienti, instaurano con essi un rapporto commerciale,
raccolgono
degli ordini che provvedono a spedire alla sede, fatturano, rigidamente a mano, al
momento opportuno quanto dovuto e chiudono il ciclo incassando il denaro e versandolo nelle casse
della azienda.
In una situazione del genere, per la salvaguardia della sicurezza aziendale potrebbe essere
opportuno fare in modo che i clienti siano conosciuti anche dalla azienda oltre che dal responsabile
locale; per assicurare la business continuity si dovrebbe fare in modo che in caso, ad esempio, di
indisponibili tà dell’addetto locale qualche altra persona
vada dai clienti a svolgere le attività; per
assicurare la business continuity nel caso in cui un evento calamitoso distrugga la sede centrale si
potrebbe definire un accordo con chi recapita la posta fornendo ad essi un indirizzo alternativo e
facendo in modo che a tale indirizzo vi sia qualcuno in grado di ricevere gli ordini
in caso di
chiusura forzata
della sede; quest’ultimo accorgimento può essere ancora più utile se in quella sede
di emergen za si provvede anche a mantenere un magazzino, in aggiunta a quello della
sede centrale,
anche se con una quantità di beni ridotta; va da se che, se ci si intende coprire dal rischio che un
piccol o incendio renda inagibile la sede, può essere sufficiente avere una sede alternativa
anche, ad
esempio, in un piano diverso dello stesso stabile; se, invece, si ha motivo per volersi cautelare nei
confronti di eventi di portata cosiddetta geografica (terremoti, alluvioni, etc.), allora potrebbe essere
il caso di spostare la sede alternativa quanto più lontano possibile facendosi consigliare da esperti
che studiano gli eventi naturali.
Entrando più in dettaglio circa le operazioni ed i flussi informativi della nostra arcaica azienda, si
potrebbero trovare altri interventi utili per mettere in pratica i concetti di sicurezza, di business
continuity e di disaster recovery.
Tuttavia, non è utile continuare con il nostro fantasioso esempio in quanto, l’essenziale, è mettere in
evidenza che i concetti di cui si parla non sono intrinseci dell’information technology bensì sono
intrinseci della gestione aziendale e, perciò,
per la loro soluzione non è possibile fare a meno di
indicazioni
ed analisi che devono derivare dai vari reparti aziendali.
In sostanza, il prerequisito per affrontare gli argomenti della business continuity e del disaster
recovery è la approfondita conoscenza dei processi e dei flussi di informazione aziendali; solo da
196

questa conoscenza si può decidere, a livello aziendale, cosa è necessario proteggere e quali servizi è
necessario assicurare oltre che, naturalmente, a fronte di quali rischi.
Uno studio volto a definire cosa proteggere a fronte di quali rischi può avere come obiettivo base
quello
di analizzare le eventuali obbligazioni che l’azienda è tenuta a rispettare a fronte di leggi o di
normative in genere.
In effetti, questa impostazione abbastanza minimale tende più a proteggere l’azienda verso
interventi variamente sanzionatori che a privilegiare quella impostazione, più volte richiamata, che
pone il cliente ed i servizi ad esso forniti in posizione centrale; in realtà, una forte spinta ad
affrontare
le problematiche di sicurezza è stata prodotta dalle norme sulla protezione dei dati
personali, sulle direttive cosiddette Basilea 2 che riguardano gli ambienti bancari, etc; tutto
sommato, però, è pur sempre un passo che, se affrontato con serietà e non come un requirement
imposto, porta dei benefici anche all’utenza.
In realtà, a prescindere da determinate imposizioni di legge, un progetto di business continuity o di
disaster
recovery dovrebbe partire cercando delle risposte, a livello aziendale, ad alcune domande
che, seppure apparentemente semplici, implicano, come si è detto, una profonda conoscenza dei
processi e dei flussi informativi aziendali ed una strategia interna che preveda un determinato livello
di servizio da fornire ai propri clienti; alcune di queste domande sono le seguenti:
- per quanto tempo ci si può permettere di rimanere privi dei propri dati e delle proprie
procedure?
- quale è il livello di continuità di servizio necessario per le varie procedure?
- il fermo di un impianto provoca disservizio su altri impianti e/o strutture informatiche
dell’azienda?
- quanto costa, in definitiva, all’azienda un fermo del proprio sistema informativo?
- quanti dati ci si può permettere di perdere (potendoli in qualche modo ricostruire)?
In sostanza, rispondere a queste domande equivale a valutare i rischi che l’azienda corre nella
situazione in cui si trova, cioè l’impatto che i vari rischi hanno sul business aziendale e sui livelli di
servizio che si è deciso di assicurare; fatta questa valutazione, il passo successivo è quello di
progettare gli interventi che si ritengono più opportuni per fronteggiare i vari rischi. Tra questi
interventi, una parte riguarderanno i sistemi informativi e gli impianti informatici, così come altri
riguarderanno aspetti logistici, aspetti organizzativi, etc.
Dal punto di vista informatico, perciò, si potrà dover decidere su modifiche al sistema informativo,
sulla acquisizione di apparecchiature e sui luoghi dove installarle e si potrà anche decidere di
affrontare i piani con l’ausilio di fornitori esterni ai quali delegare parti più o meno cospicue della
realizzazione dei piani.
E’ bene tenere presente che i piani di business continuity e di disaster recovery, per la parte
informatica così come per le altre parti
- non sono piani che in genere hanno una lunga vita nel senso che la dinamicità dell’ambiente
aziendale, e dell’ambiente informatico in particolare, richiederanno una frequente revisione
dei piani stessi al fine di adeguarli a nuove esigenze o, semplicemente, al fine di verificare
che le cose vanno bene così come sono;
- necessitano di test ripetuti periodicamente al fine di verificare che tutto ciò che, in genere,
sulla carta funziona perfettamente, si comporti altrettanto bene nella pratica; ciò sia per la
197

parte tecnologica sia, e forse principalmente, per la parte umana inerente al “chi fa che cosa
e quando”, alle deleghe di responsabilità, etc.
Questi due punti si sono spesso dimostrati le principali
fonti di problemi quando, sfortunatamente,
dalla
teoria si è dovuti passare alla pratica.
La analisi dei rischi di cui si è detto può anche, in teoria, portare alla conclusione che non è
necessario alcun piano in quanto l’azienda può tranquillamente correre tali rischi; in linea di
principio ciò può anche essere accettabile purché, appunto, derivi da una analisi e non sia il frutto
della incapacità di condurre una analisi e purché, ovviamente,
non vi siano prescrizioni di legge che
impongono un diverso comportamento.
In questi rari casi
- non vi sono dati e programmi tenuti
in luoghi diversi da quelli dove avviane il normale
trattamento o, come si dice, non vi sono dati off-site;
- non si dispone di un back-up dell’hardware;
- il recupero dei dati può perciò non essere possibile e la loro ricostruzione
può richiedere
tempi molto lunghi;
- così come può essere molto lungo il periodo di tempo per ripristinare l’operatività. Nell’ipotesi che si decida di fare qualcosa, le soluzioni, dal punto di vista informatico
essere diverse:
possono
- si può optare per una protezione che si può definire base, in cui
o esiste un back-up di dati conservato localmente (on-site)
o non vi è protezione da eventi disastrosi di carattere
naturale né da eventi disastrosi
locali (incendio, allagamento, etc.)
o si ottiene una protezione limitata a fronte di problemi che coinvolgono l’integrità dei
dati (errori operativi e/o applicativi, problemi hardware
alle unità di storage, etc.)
o la quantità di dati da ricostruire dipende dalla periodicità del back-up
o se il back-up non riguarda anche i programmi di base ed applicativi possono sorgere
serie difficoltà nel ricostruire tali ambienti (specie quelli applicativi)
- si può invece optare per una protezione che si può definire avanzata, in cui
o esiste un back-up (manuale o via rete) dei dati off-site in un luogo
che dispone di
hardware (hot site) installato dal quale far ripartire
l’operatività
(totale o delle
funzioni reputate di importanza critica)
o in base alle tecniche di aggiornamento dei data base remoti
le perdite di dati
informatici possono essere anche nulle
o il ripristino della operatività è tanto più rapido quanto più è automatizzato
(specie nei
riguardi della rete connessa agli impianti)
Tra il livello di protezione che abbiamo definito base e quello che abbiamo definito avanzato basato
su un hot site, che spesso consiste in una duplicazione del sito primario ad una distanza tale da far
ritenere che il disastro che interessa il sito primario non interessi l’hot site, ne esistono altre che
assicurano diversi livelli di protezione.
Tra queste vi è la cosiddetta tecnica “a freddo”, in cui si provvede al periodico back-up dei dati e
dei
programmi ed al trasferimento dei supporti di back-up (tipicamente nastri magnetici) in un
luogo sicuro e sufficientemente distante o alla creazione di copie di back-up per via telematica su
198

unità di storage connesse remotamente; nel caso in cui dovesse presentarsi la necessità gli ambienti
possono essere ricostruiti su hardware propri o di terzi e la operatività ripristinata in 24-48 ore; le
tecniche definite a freddo sono prevalentemente indicate per affrontare il problema
del disaster
recovery ma non consentono di affrontare efficacemente il tema della business continuity.
Business
continuity e disaster recovery non sono argomenti che riguardano solo le aziende di grandi
dime nsioni ed i relativi impianti informatici o solo determinati settori di mercato
quali le aziende
bancarie; bensì, i principi, specie per quanto concerne il disaster recovery cioè la capacità di
ripristino con tempi adeguati della operatività in caso di disastro, devono riguar dare og ni azienda ed
ogni tipo di impianto informatico, dal più piccolo al più grande.
In realtà dovrebbero essere argomenti tenuti in considerazione anche nelle installazioni
“ domestiche”; d’altra parte, quanto più semplici sono le installazioni informatiche tanto meno
onerose, in termini di tempo e di denaro, sono le iniziative che possono essere intraprese per evitare
fastidiosi
incidenti e, principalmente, per evitare di perdere dati ed informazioni la cui importanza,
sfortunatamente, si apprezza solo quando vengon o a mancare. 199

I REQUIREMENTS – Domande di verifica
1 il soddi sfacimento di un requirement contribuisce
sempre al soddisfacimento di tutti gli altri
VERO
FALSO
vero solo nelle aziende di
grande dimensione
Commenti: ...............................................................................................................................
. ..................................................................................................................................................
2 i requirements informatici discendono dai VERO
requirements aziendali
FALSO
dipende dai rapporti di forza
interni all'azienda
Commenti: ...............................................................................................................................
...................................................................................................................................................
3 un requirement derivante da una norma di legge si
può definire
"scelto"
"semi-imposto"
"imposto"
Commenti: ...............................................................................................................................
...................................................................................................................................................
4 per il soddisfacimento di un requirement percepito una sca rsa propensione
dal management aziendale come "imposto" c'è da
attendersi, in genere
ad investire
un forte interesse nella
qualità della soluzione
la propensione ad usare
soluzioni innovative
Commenti: ...............................................................................................................................
...................................................................................................................................................
200

5 per il soddisfacimento di un requirement una scarsa propensione
scelto dal management aziendale in quanto
fonte di un notevole vantaggio competitivo vi è,
a d investire
in genere, a livello aziendale un forte int eresse nella
qualità della soluzione
l'obiettivo di minimizzare
i costi
Commenti: ...............................................................................................................................
.. .................................................................................................................................................
6 la predisposizione di un sito internet aziendale è
una attività
o bbligatoria
decisa dalla direzione
aziendale
decisa dall a direzione
IT
Commenti: ...............................................................................................................................
.. .................................................................................................................................................
7 nel caso in cui una azienda scelga modaliltà di a lla società che fornisce il
outsourcing, la definizione dei requirements di
business compete
servizio di outsourcing
alla azienda
allo stato
Commenti: ...............................................................................................................................
...................................................................................................................................................
8
il disaster recovery è un argomento che deve
essere affrontato
a livello di azienda
a livello di direzione IT
a livello di sala macchine
Commenti: ...............................................................................................................................
...................................................................................................................................................
201

9 un corretto piano di disaster recovery deve tutti i dati gestiti presso
considerare l'impianto
i dati personali del top
manager
quanto necessario in base
ad una analisi dei rischi
Commenti: ...............................................................................................................................
...................................................................................................................................................
10 un piano di disaster recovery deve essere tenuto invariato nel tempo
modificato giornalmente
testato ed aggiornato
periodicamente
Commenti: ...............................................................................................................................
...................................................................................................................................................
11 le norme che regolano il trattamento dei dati
personali inducono, tra l'altro, dei requirements
alla velocità di calcolo
connessi all'accesso ad internet
alla sicurezza
Comm enti: ..................................................................................................................... ..........
.. .................................................................................................................................................
12 ogni impianto informatico deve assicurare la VERO
"Business Continuity" dell'intero sistema informativo
dipende dalla competenza
dell' IT manager
dipende dalle strategie
aziendali
Commenti:
...............................................................................................................................
...................................................................................................................................................
202

13 Le aree per le quali prevedere interventi volti ad Dalla funzione sviluppo del
assicurare la business continuity sono decise settore IT
Dalla funzione sistemi del
settore IT
Dalla direzione aziendale a
seguito di una attenta analisi
Commenti: ...............................................................................................................................
...................................................................................................................................................
14 le relazioni sempre più interdipendenti tra i sistemi in modo del tutto autonomo
informativi delle aziende e degli enti fanno sì che le
problematiche di disaster recovery e di business in modo del tutto autonomo ed
continuity debbano essere affrontate assolutamente riservato
quanto più possibile a livello
sistemico
Commenti: ...............................................................................................................................
...................................................................................................................................................
15 una delle principali cause del fallimento dei il mancato test periodico
procedure di disaster recovery è
il verificarsi di un disastro
la sfortuna
Commenti: ...............................................................................................................................
...................................................................................................................................................
203

Appendice A - FACILITY MANAGEMENT E OUTSOURCING
Facility management ed outsourcing sono due delle possibili tipologie con cui una azienda o un
può risolvere la problematica del reperimento della fonte (sourcing) da cui prelevare i servizi
informatici di cui necessita; con queste modalità i servizi vengono acquistati da aziende esterne
le quali si stipulano contratti talvolta anche molto complessi.
Tramite un contratto di facility management, in genere, una azienda affida ad un fornitore
esterno la
gestione delle proprie risorse hardware e dei sistemi operativi conservando gli altri aspetti,
tipicamente connessi con l’ impostazione e lo sviluppo del software applicativo, sotto il proprio
controllo.
L’outsourcing, invece, prevede l’acquisizione di servizi informatici completi
da terzi e può
implicare
il trasferimento al fornitore prescelto di hardware, software, contratti di manutenzione,
altri contratti di fornitura e, talvolta, anche di locali e di persone; il rapporto di outsourcing è perciò
il più ampio tra i contratti di servizio in area informatica e contiene, sostanzialmente, tutte le
problematiche singolarmente affrontate dalle altre tipologie di servizi.
L’impiego di strumenti quali il facility management e l’outsourcing (assieme ad altre tipologie di
strumenti della stessa area) hanno avuto un certo sviluppo negli ultimi anni per rispondere a
differenti necessità:
- soddisfare specifiche richieste la cui soluzione interna potrebbe richiedere investimenti, in
termini di persone e di strumenti, non giustificati;
- colmare carenze interne di tipo organizzativo che portano alla incapacità di gestire
efficacemente il proprio sistema informativo;
- realizzare delle economie di scala all’interno di gruppi pluriaziendali, affidando ad una
unica società (spesso anch’essa interna al gruppo nel qual caso si suole parlare di
insourcing) la gestione dei vari sistemi informativi;
- realizzare strutture consortili, che associno aziende appartenenti a medesimi settori di
mercato o a settori differenti, con il medesimo obiettivo del punto precedente, cioè la
realizzazione di economie di scala in termini di persone e di strumenti
- etc.
Lo scopo, insomma, è quello di ottenere servizi informatici migliori, o, almeno, non peggiori,
rispetto a quelli che si potrebbero ottenere con una gestione diretta delle faccende informatiche,
spendendo di meno.
Ad ogni modo, la scelta di modalità quali il facility management e/o l’outsourcing, dovrebbe essere
il frutto di una attentissima analisi che, tra l’altro, verifichi alcune aspetti basilari:
- ciò che si affida in qualche modo all’esterno non dovrebbe far parte di quell’insieme di
procedure e di modalità operative la cui realizzazione costituisce per l’azienda ciò che viene
definito “vantaggio competitivo”, cioè qualcosa che può fare la differenza tra l’azienda ed i
suoi competitori
- il servizio che si richiede all’esterno dovrebbe potere essere fornito (realmente e non solo in
teoria) da un certo numero di interlocutori affidabili e “sufficientemente” intercambiabili
- si dovrebbe disporre di un “potere contrattuale” adeguato a garantire l’accoglimento da parte
dell’interlocutore esterno di richieste di modifiche, implementazioni, etc.
ente
con
204

- dovrebbe essere comunque garantita, con relativa facilità, rapidità e sostenibilità finanziaria,
la possibilità di tornare sui propri passi nel caso in cui, per qualsiasi motivo, si decida di
farlo
- si dovrebbe definire una politica rivolta al personale informatico interno tesa a minimizzare
atteggiamenti più o meno ostili che non di rado si stabiliscono con l’interlocutore esterno e
tesa anche a limitare l’impoverimento culturale informatico che può derivare da un
approccio tendenzialmente decommesso dall’interesse aziendale
- etc.
Il primo dei punti sopra riportati è strettamente connesso al valore che la direzione aziendale da al
sistema informativo ed all’impianto informatico; ciò che viene visto come un male necessario per la
conduzione della operatività aziendale è un ottimo candidato alla esternalizzazione; ciò che, al
contrario, viene visto come un strumento che contribuisce al migliore soddisfacimento degli
obiettivi aziendali, e che perciò deve essere contraddistinto da una grande capacità di evolversi per
assecondare
e consentire il dinamico evolversi degli obiettivi aziendali, ben difficilmente sarà
esternalizzato; vederla in un modo o nell’altro, naturalmente, dipende dal valore strategico che il
management aziendale attribuisce al proprio sistema informativo.
Gli
altri punti sopra riportati servono a non doversi trovare in una scomoda posizione di dipendenza
da interlocutori esterni e/o nella scomodissima posizione di dover obbligatoriamente accettare varie
condizioni, cioè vari costi, che si potrebbero rivelare inaccettabili.
In generale, escludendo i casi di gruppi pluriaziendali e/o consortili che formano una
n-esima
società
per la fornitura dei servizi informatici a tutte le altre, nei casi in cui le attività informatiche
di una azienda abbiano una “massa
critica” qualitativamente e/o quantitativamente adeguata, non vi
dovrebbe
essere alcun motivo per procedere a forme di esternalizzazione se non l’incapacità,
normalmente non tecnico-informatica, di gestire le attività stesse; nel qual caso si dovrà ricorrere a
terzi remunerando, come è ovvio, opportunamente e spesso molto lautamente
le capacità
manageriali che non si possiedono.
In realtà, anche nel caso di gruppi pluriaziendali e consortili la decisione di ricorrere a servizi di
outsourcing, di facility management, etc. dovrebbe
essere preceduta da una analisi dettagliata, se
non
altro per valutare il “valore” che le singole aziende vengono in qualche modo a perdere non
essendo più, per così dire, autosufficienti; qualora, infatti, i piani strategici del gruppo dovessero
portare alla cessione di una azienda, il legame, talvolta fortissimo, con il fornitore dei servizi
informatici può non contribuire favorevolmente alla definizione del “valore” della azienda da
cedere.
Dal punto di vista meramente contrattuale, poi, la regolamentazione di un rapporto di outsourcing,
di facility management, e di altre forme di servizio, è un argomento di estrema complessità e
necessario per quanto assolutamente
non sufficiente, di per se, a garantire “sonni tranquilli” a chi
decide di esternalizzare componenti fondamentali del proprio sistema informativo privandosi, in
pratica, del controllo reale di alcuni dei fattori produttivi di cui necessita. In altre parole, si può
anche decidere di far firmare al medico cui si affida la propria salute un contratto pieno di
condizioni e di penali volte a punire eventuali inadempienze e/o errori del professionista, tuttavia,
almeno
nei casi più “vitali”, dove cioè una inadempienza o un errore può indurre conseguenze
molto
gravi, non si mancherà di acquisire qualche informazione sulla storia professionale
dell’interlocutore,
sulle strutture e sugli impianti di cui lo stesso dispone per svolgere il proprio
lavoro,
etc.
205

Pertanto, la scelta di un interlocutore cui affidare servizi di facility management e/o di outsourcing,
e la conseguente regolamentazione formale del rapporto, dovrebbe essere condizionata, oltre che da
fattori
tecnici ed applicativi, anche da una conoscenza quanto più approfondita possibile della
organizzazione
del fornitore in considerazione del fatto, tra l’altro, che, come è ovvio, ogni rischio
potenziale
connesso alla struttura ed alle capacità del fornitore diventa di fatto un rischio della
azienda
cliente.
E’ importante sottolineare che la conduzione di una rapporto di outsourcing, di facility
management,
etc., richiede che la struttura cliente disponga al proprio interno di un gruppo di
persone,
più o meno ampio e con competenze sia informatiche sia tecnico-giuridiche, incaricato di
interfacciare
la società di servizi per tutto ciò che riguarda il controllo e la gestione del rapporto in
termini,
ad esempio, di rispetto dei livelli di servizio previsti, adeguamento dei servizi,
manutenzioni
evolutive e correttive, adeguamento dei corrispettivi, etc.
206

Appendice B – CENNI SUI MODELLI A RETE DI CODE
Quanto segue è tratto dal testo:
E. D. Lazowska, J. Zahorjan, G. S. Graham, and K. C. Sevcik, Quantitative System Performance:
Computer System Analysis Using Queueing Network Models, Prentice-Hall, Inc., Englewood Cliffs,
NJ, 1984
al
quale si rimanda per ogni approfondimento.
In molti settori è comune l’impiego di modelli al fine di poter effettuare vari tipi di analisi che
altrimenti sarebbe difficoltoso o impossibile condurre; le analisi di cui si parla sono, in genere, volte
a prevedere il comportamento del sistema in esame e possono rendersi necessarie sia in fase di
progettazione
sia in fase di gestione e di adeguamento a nuove necessità.
Si parla di modelli matematici quando il comportamento del sistema è rappresentato da equazioni
matematiche;
si parla di modelli analoghi quando il sistema fisico in esame è trasformato in un
diverso
sistema fisico descritto da equazioni differenziali dello stesso tipo.
Evidentemente,
i sistemi analoghi possono avere una apparenza fisica del tutto differente; si pensi ai
sistemi meccanici per i quali possono costruirsi dei sistemi analoghi di tipo elettrico dove, ad
esempio, le forze, le velocità e le masse del sistema meccanico possono essere rappresentate per
analogia
con le tensioni, le correnti e le induttanze di un analogo sistema elettrico.
La disponibilità di un modello:
- in fase progettuale può guidare nella scelta tra diverse soluzioni evitando la dispendiosa
realizzazione di diversi prototipi
da assoggettare a sperimentazione
- in fase di gestione può aiutare ad individuare le componenti di un sistema che determinano
o
che possono determinare comportamenti fuori linea in funzione dei vari livelli di utilizzo
- in fase di adeguamento può consentire di effettuare analisi volte a prevedere il
comportamento del sistema
modificato.
L’utilizzo di un modello matematico di un sistema di calcolo per la valutazione, ad esempio, delle
performance, è di aiuto in q uanto, talvolta, le misurazioni che interessano non possono essere
condotte perché
il sistema non è ancora “esistente” o perché il costo di una simulazione sarebbe
troppo
elevato in termini di persone e di mezzi che si dovrebbero impiegare.
Un approccio alla creazione di un modello di un sistema di calcolo è costituito
dalla
rappresentazione del sistema stesso come una rete di centri di servizio, con relative code, e clienti
che utilizzano i centri di servizio.
La figura seguente rappresenta, con qualche approssimazione, un semplice sistema di calcolo
costituito da quattro centri di servizio, una CPU
e tre unità a disco con le rispettive code.
207

disco
CPU disco
disco
Il modello rappresentato nella figura precedente può sembrare così semplice da essere del tutto
irrealistico; tuttavia è bene tenere presente che un modello estremamente rispondente alla realtà può
diventare così complesso da richiedere tecniche di analisi talmente complesse e sofisticate da
rendere praticamente il modello stesso intrattabile; d’altra parte, in genere, il tipo di informazioni
cui si è interessati può consentire di tralasciare alcuni particolari di scarsa influenza specifica
inducendo ovviamente un certo livello di approssimazione ma, in compenso, rendendo il modello
trattabile e tutto sommato efficace.
L’opportunità, se non la necessità, di effettuare alcune approssimazioni nella realizzazione del
modello
fa intuire che l’attività di modellazione necessita comunque
di una buona dose di
esperienza e di un procedimento iterativo.
Come
si è detto, un modello è costituito da centri di servizio e da clienti.
I modelli a rete di code prevedono l’impiego di centri di servizio con caratteristiche semplici a
differenza
della teoria delle code che è orientata alla rappresentazione di sistemi complessi tramite
l’impiego di singoli centri di servizio con caratteristiche complesse.
I clienti non sono altro che il carico di lavoro cui il modello,
ed il sistema, dovrà far fronte; nei
modelli a rete di code possono essere considerati
i seguenti tipi di carico:
- transazionale, caratterizzato dal numero di transazioni al secondo che si presentano
- batch, caratterizzato dal numero di attività batch contemporaneamente presenti
nel sistema
- interattivo, caratterizzato dal numero di utenti complessivamente connessi e dal tempo
medio che ciascun utente impiega tra due comandi
(think time).
208

Nel caso in cui sia realistico impiegare un modello sottoposto ad un solo tipo di carico di lavoro si
parlerà di modelli a classe singola; altrimenti si parlerà di modelli
a classe multipla.
LE LEGGI FONDAMENTALI
Esaminiamo
il seguente centro di servizio
ARRIVI Richieste evase
Osservando il sistema per un certo tempo T si conteranno un determinato numero di arrivi A ed un
determinato
numero di richieste evase C.
Si
definiscono:
Coda Risorsa
λ = A / T frequenza degli arrivi (numero di arrivi per unità di tempo)
X = C / T throughput (numero di completamenti per unità di tempo)
Se
B è il tempo in cui la risorsa è occupata (busy time) allora si definiscono:
U = B / T utilizzazione della risorsa
S = B / C tempo di servizio medio necessario ad ogni richiesta presso la
risorsa (service requirement)
moltiplicando e dividendo per C, l’utilizzazione della risorsa può essere scritta come:
U = (C / T) * (B / C) cioè
U = X * S legge dell’utilizzo
Ovverosia l’utilizzo di una risorsa è pari al throughput moltiplicato per il service requirement
medio
presso quella risorsa.
La
legge dell’utilizzo è un caso particolare della legge di LITTLE illustrata nel seguito.
209

Consideriamo un sistema per il quale si conosca la distribuzione degli arrivi e quella dei
completamenti
in funzione del tempo come riportato nella figura seguente :
La linea rossa identifica gli arrivi, cioè al tempo 2 si verifica un arrivo, al tempo 3 un altro, al tempo
5 un altro ancora e così via; analogamente, la linea blu rappresenta i completamenti, cioè al tempo 3
una
richiesta lascia il sistema, un’altra al tempo 4, e così via. In ogni istante, la differenza verticale
tra
la linea rossa e la linea blu individua il numero di richieste presenti nel sistema; così al tempo
3,5
nel sistema è presente una richiesta mentre al tempo 4,5 non ne è presente nessuna. Integrando
questa differenza in un certo intervallo di tempo si ottiene il tempo accumulato nel sistema misurato
in richieste x tempo.
210

Nella figura precedente l’intervallo di tempo scelto è dal tempo 4 al tempo 8 e, in questo caso, il
tempo
accumulato nel sistema è pari a 3 richieste x tempo.
È appena il caso di osservare che il diagramma è particolarmente semplificato rispetto ai casi reali
in cui le frequenze degli arrivi e delle evasioni sono decisamente meno semplici e regolari.
Chiamato
W il tempo accumulato nel sistema, si definiscono :
(residence time)
Analogamente a quanto fatto per ottenere la legge dell’utilizzo, possiamo dire
Cioè
N = W / T numero medio di richieste nel sistema
R = W
/ C tempo medio in cui ogni richie
N = W / T = C / T * W / C
N = X * R legge di Little
sta risiede nel sistema
Ovverosia
il numero medio di richieste in un sistema è pari al prodotto del throughput del sistema
per
il tempo medio necessario ad ogni richiesta nel sistema.
Si osservi che R corrisponde esattamente al tempo di risposta solo nel caso in cui all’inizio ed alla
fine dell’intervallo di osservazione all’interno del sistema non siano presenti richieste.
Come si è detto, la legge dell’utilizzo equivale alla legge di Little nel caso in cui il sistema sia
composto
da una sola risorsa (escludendo la sua coda); in questo caso, infatti, il numero medio di
richieste nel sistema coincide con l’utilizzo della risorsa stessa ed il residence time coincide con il
service requirement.
Considerato un sistema nella sua interezza, la legge di Little può essere applicata a vari livelli con la
ovvia
accortezza di considerare valori di volta in volta congruenti per presenze nel sistema (N),
throughput e residence time.
Gli
schemi seguenti evidenziano questa circostanza; il modello assunto rappresenta un sistema di
calcolo
interattivo con un certo numero di utenti (rappresentati dal simbolo romboidale); la zona
tratteggiata in rosso e quella a cui di volta in volta è applicata la legge di Little.
211

In questo caso si può applicare la legge di Little, nella forma della legge dell’utilizzo, alla sola unità
a disco con esclusione della sua coda;
Così, nel caso in cui, ad esempio, si conoscano il throughput ed il service requirement si potrà
ricavare
l’utilizzo della risorsa.
Supponendo
e
allora
CPU disco
X = 40 richieste / secondo
S = 0,0225 secondi
U = X * S = 0,9 cioè 90 %
disco
disco
212

In questo caso si può applicare la legge di Little alla
unità a disco compresa la sua coda; in questo
caso
il numero di richieste presenti nel sistema comprende anche le richieste che si trovano in coda
in attesa di servizio ed il residence time corrisponde al tempo totale di servizio e di attesa; allora,
mantenendo per il throughput il valore di 40 richieste/secondo, supponendo
allora
N = 4 richieste nel sistema
R = N / X = 4 / 40 = 0,1 secondi
disco
CPU disco
disco
Poiché sappiamo che ciascuna richiesta necessita di un service requirement S = 0,0225 secondi,
possiamo
dedurre che il tempo impiegato in media in coda da ciascuna richiesta è pari a 0,0775
secondi.
213

In questo caso si può applicare la legge di Little all’intero sistema.
Supponendo
allora
CPU disco
X = 0,5 cioè una richiesta evasa ogni 2 secondi
N = 7,5 richieste nel sistema
R = N / X = 7,5 / 0,5 = 15 secondi
disco
disco
214

In questo caso
si può applicare la legge di Little all’intero sistema compresi gli utenti interattivi; per
fare
ciò è però necessario introdurre un nuovo elemento definito think time, cioè il tempo medio che
intercorre tra la sottomissione di due comandi successivi
da parte di un utente.
Chiamando Z il think time, la legge di Little si riscrive nella forma
Dalla quale si ottiene
N = X * (R + Z)
R = (N/X) - Z legge del tempo di risposta
Nel nostro caso, allora, supponendo
N = 64 utenti Z = 30 secondi X = 2 richieste/secondo
allora
CPU disco
R = (N / X) - Z = 2 secondi
disco
disco
215

Normalmente un sistema di calcolo è composto da diverse risorse; un argomento di interesse è lo
studio delle relazioni tra le varie parti del sistema e tra i vari valori in gioco.
Supponiamo, perciò, di misurare il numero di completamenti in un dato tempo a livello di sistema e
di
ottenere il valore C; nello stesso arco di tempo supponiamo di rilevare per la risorsa K il numero
dei
suoi completamenti che chiamiamo Ck; si definisce allora il numero di visite alla risorsa K
come:
Vk = Ck / C Visit count della
risorsa K
Pertanto, se in un dato intervallo misuriamo un numero di completamenti
a livello di sistema pari a
10 ed un numero di completamenti a livello della risorsa K, ad esempio una unità a disco, pari a
100, si può dire che mediamente ogni completamento a livello di sistema richiede 10 accessi al
disco
K.
Se
allo ra
Vk = Ck / C
= * C
Ck Vk
ma dividendo per il tempo di osservazione e considerando che
Allora si ottiene
Ck / T = Xk e C / T = X
Xk = Vk * X legge del flusso forzato
216

Appendice C – ANALOGICO/DIGITALE
Per simulare un computer analogico basta immaginare, ad esempio, tre bicchieri ognuno dei quali
può
contenere, diciamo, 1000 ml di liquido; volendo effettuare una operazione quale 375 + 250 e
stabilendo che un ml equival e ad una unità nei nostri conti, sarebbe sufficiente mettere 375 ml nel
primo bicchiere, 250 ml nel secondo e poi, tramite un sistema di tubi, far defluire il contenuto dei
primi due bicchieri nel terzo che, alla fine, conterrà 625 ml di liquido che è il risultato della
operazione.
Se, invece, volessimo effettuare una operazione quale 375 – 250, dopo aver riempito i primi due
bicchieri rispettivamente con 375 e 250 ml di liquido, sarebbe sufficiente, ad esempio, far
disperdere il liquido da entrambi i bicchieri fino a che uno dei due non si svuoti del tutto e quindi
misurare il contenuto ancora presente in uno dei due (nel nostro caso nel primo); questo sarà il
risultato della nostra operazione: 125. In sostanza il primo bicchiere ospita il primo operando (e
talvolta, alla fine della operazione, il risultato), il secondo bicchiere ospita il secondo operando ed il
terzo bicchiere ospita in genere il risultato.
Supponiamo ora di avere a disposizione, ma in grande quantità, solo dei bicchierini da, diciamo,
100 ml ciascuno; come possiamo organizzare il nostro computer per fare le nostre operazioni?
Evidentemente, vista la grandezza dei nostri operandi, non è più possibile far corrispondere ad un
operando un bicchiere, allora possiamo decidere che ogni operando è rappresentato da 10
bicchierini.
Così le cose tornano al loro posto, a parte il fatto che l’impianto di tubi che consentirà di effettuare
le operazione comincia a diventare complesso; naturalmente si deve continuare a stare bene attenti
che la quantità di liquido nei bicchieri sia assolutamente esatta, che i bicchieri completamente pieni
lo siano fino all’orlo e che quelli vuoti non contengano nemmeno una goccia; ad ogni modo può
funzionare.
Continuiamo ad avere un calcolatore analogico.
Ma, una volta che abbiamo deciso di usare più bicchierini per ogni operando, possiamo anche
decidere di assegnare ad ogni bicchiere un valore non solo in base alla quantità di liquido che
contiene, bensì anche in base alla posizione che occupa nella serie dei 10 bicchieri.
In fin dei conti nel nostro sistema decimale, come ci hanno insegnato alle scuole primarie, un 3 in
una certa posizione non equivale ad un 3 in una posizione diversa; ad esempio, il 3 nella prima
posizione vale 3 mentre il 3 nella posizione subito a sinistra vale 30. È vero che nel sistema binario
non disponiamo del 3 ma solo di 0 e 1, però si può fare lo stesso qualcosa di interessante.
Stabiliamo allora che la serie dei 10 bicchierini (da b10 a b1) abbia il seguente valore in base alla
posizione
b10 b9 b8 b7 b6 b5 b4 b3 b2 b1
512 256 128 64 32 16 8 4 2 1
tale valore, naturalmente, è da tenere in conto solo se il corrispondente bicchierino è pieno.
217

I valori di ogni posizione discendono, naturalmente, dal fatto che il mio sistema dispone solo di due
simboli,
0 e 1.
Quindi, se devo rappresentare il numero 375 riempirò i bicchierini b9, b7, b6, b5, b3, b2 e b1; infatti
b10 b9 b8 b7 b6 b5 b4 b3 b2 b1
0 256 0 64 32 16 0 4 2 1
conseguentemente la rappresentazione binaria del numero 375 sarà
0 1 0 1 1 1 0 1 1 1
se, invece, devo rappresentare il numero 250 riempirò i bicchierini b8, b7, b6, b5, b4 e b2; infatti
b10 b9 b8 b7 b6 b5 b4 b3 b2 b1
0 0 128 64 32 16 8 0 1 0
conseguentemente
la rappresentazione binaria del numero 250 sarà
0 0 1 1 1 1 1 0 1 0
Davvero una grande trovata. Apparentemente un po’ complessa ma funzionante e che porta diversi
vantaggi, tra i quali:
- il sistema si presta facilmente ad essere “ingegnerizzato” sostituendo il liquido ed i
bicchierini con differenti e più maneggevoli fenomeni fisici quali accensione o spegnimento
di un interruttore (o di un relay), presenza o assenza di una tensione elettrica o di una
corrente elettrica, etc.
- non ci si deve più preoccupare di riempire con estrema precisione ogni singolo bicchiere,
infatti ora si può assumere che se un bicchiere è pieno per più del 75 % è da considerarsi
pieno (cioè con valore 1) se è pieno per meno del 25 % è da considerarsi vuoto (cioè con
valore 0); quest’ultimo è un vantaggio formidabile ed insostituibile avendo a che fare con
l’elettricità, con gli elettroni che vanno da una parte e dall’altra e che sono influenzati nei
loro comportamenti da un certo numero di altre cose quali, ad esempio, la temperatura
circostante, etc.
- aggiungendo un bicchierino aumento il range dei valori che posso trattare esponenzialmente
secondo la potenza di 2 e non della semplice quantità che contiene il bicchierino;
- etc.
Operare con i bit(s), consente di costruire macchine digitali per il calcolo concettualmente molto
semplici. Tornando ai bicchierini, se devo calcolare 375 + 250, riempirò, senza l’assillo della
assoluta precisione, i bicchierini corrispondenti e mi troverò con la seguente disposizione degli
operandi :
operando
1 (375) 0 1 0 1 1 1 0 1 1 1
operando 2 (250) 0 0 1 1 1 1 1 0 1 0
218

da cui si può passare ad effettuare la somma che, tenendo conto che 1 + 0 (come 0 + 1) è pari ad 1,
0 + 0 è pari a 0 ed 1 + 1 è pari a 0 con il riporto di 1, è pari a
risultato 1 0 0 1 1 1 0 0 0 1
cioè 625 512 0 0 64 32 16 0 0 0 1
219

Appendice D – CENNI SULLA TEORIA DEI SEMICONDUTTORI
Se si considera un singolo atomo, gli elettroni possono solo occupare posizioni, ovvero livelli
energetici, ben definite (discrete) ruotando attorno al nucleo su orbite concentriche; quando due o
più atomi si trovano vicini, aggregandosi ad esempio in una struttura solida, avvengono tra di essi
delle
interazioni che hanno, tra l’altro, l’effetto di scindere i livelli energetici di cui si è detto dando
così luogo a delle bande di energia entro le quali risiedono gli elettroni. Perciò, da una struttura
atomica che vede la presenza di livelli energetici discreti si passa ad una struttura più complessa
dove si alternano bande di energia in cui possono trovarsi gli elettroni e bande di energia in cui ciò
non
è possibile.
Le
bande superiori ospitano gli elettroni più esterni dell’atomo e meno strettamente legati al nucleo;
la banda più esterna, detta banda di valenza, ospita gli elettroni provenienti dalle orbite periferiche
di
valenza dell’atomo.
Ancora più esterna della banda di valenza, e separata da questa da una banda proibita detta gap, si
trova
la banda di conduzione.
In un modello a bande energetiche, la differenza tra materiali isolanti, semiconduttori e conduttori
può
essere compresa esaminando l’ampiezza dei differenti gap. Il superamento di questo gap,
infatti,
è la condizione necessaria affinché un elettrone si renda libero nella banda di valenza.
Negli
isolanti il gap è molto ampio cioè, in altri termini, l’energia necessaria per spostare un
elettrone nella banda di conduzione è molto elevata; nei semiconduttori questa energia è circa 10
volte più piccola; nei conduttori invece, la banda di valenza e la banda di conduzione sono
addirittura parzialmente sovrapposte dando luogo ad una banda unica parzialmente piena che rende
possibile lo spostamento degli elettroni senza dover pagare grossi costi in termini di energia.
In altre parole, negli isolanti gli elettroni sono tanto legati ai loro atomi da non spostarsi, nei metalli
vi sono elettroni praticamente liberi e disponibili al movimento anche sotto
l’influsso di campi
elettrici deboli, mentre nei semiconduttori sono sufficienti apporti moderati di energia per
consentire ad un certo numero di elettroni di passare nella banda di conduzione ed essere quindi
liberi di muoversi.
Così, nei semiconduttori, ad una temperatura prossima
allo zero assoluto si ritrova un
comportamento
tipico degli isolanti, mentre a temperature superiori l’energia termica è sufficiente a
spostare alcuni elettroni nella banda di conduzione, cioè a rompere un legame covalente che lega
l’elettrone al suo nucleo, creando allo stesso tempo una lacuna nella banda di valenza.
Le sostanze più diffuse presentano comportamenti da isolante (ceramica,vetro, etc.) o da conduttore
(come i metalli); un certo numero di altre sostanze, meno comuni, presentano invece un
comportamento da semiconduttore; il germanio ed il silicio, ad esempio, conducono la corrente
molto peggio dei metalli ma molto meglio degli isolanti.
Quasi nessuno si era occupato dei semiconduttori fino agli anni 40 quando un gruppetto di
ricercatori americani ne esaminò in dettaglio le caratteristiche; tra l’altro, poterono constatare che le
qualità di “quasi conduttori” di questi materiali erano più spiccate se le sostanze non erano
perfettamente pure.
220

In un semiconduttore puro, o intrinseco, la concentrazione di elettroni liberi per la conduzione è,
ovviamente, pari alla concentrazione delle lacune;
questa concentrazione è il risultato di due
fenomeni
opposti:
- la generazione di coppie “elettrone di conduzione / lacuna” che è tanto più rapida quanto più
è elevata la temperatura e quindi l’energia termica
- la ricombinazione tra le coppie “elettrone di conduzione / lacuna” che è tanto più probabile
quanto maggiore è la loro quantità.
In condizioni di equilibrio i due fenomeni si compensano portando ad una concentrazione di
portatori intrinseci stabile.
La presenza di impurità modifica questa situazione.
Il silicio come il germanio presentano
quattro elettroni negli orbitali più esterni dell’atomo; nel caso
in cui il semiconduttore
sia non intrinseco o drogato:
- se sono presenti impurità di materiali quali fosforo o arsenico, che dispongono di cinque
elettroni esterni, un elettrone resta debolmente legato alla struttura; ciò equivale, nel modello
a bande, alla formazione di un livello posizionato all’interno del gap e prossimo alla zona di
conduzione, cosicché è sufficiente una piccola quantità di energia, detta energia di
ionizzazione, per portare questo elettrone nella zona di conduzione; impurità pentavalenti si
chiamano donatori e semiconduttori drogati con atomi donatori si definiscono di tipo “n”
- viceversa, se sono presenti impurità di materiali quali boro o gallio, che dispongono di tre
elettroni esterni, attorno all’atomo della impurità si crea una lacuna; ciò corrisponde, nel
modello a bande, alla formazione di un livello posizionato all’interno del gap e prossimo
alla zona di valenza, cosicché è sufficiente una piccola quantità di energia per portare un
elettrone ad occupare la lacuna creando a sua volta una nuova lacuna e così via, provocando
una corrente originata dall’ideale spostamento della lacuna; impurità trivalenti si chiamano
accettori e semiconduttori drogati con atomi accettori di definiscono di tipo “p”.
Un
pezzetto di semiconduttore n ed un pezzetto di semiconduttore p possono essere avvicinati fino
a realizzare un buon contatto elettrico, cioè una giunzione, ottenendo così un diodo; questa struttura,
inserita in un circuito elettrico, consente di realizzare una sorta di “senso unico” nella circolazione
della corrente; per fare un esempio idraulico, un diodo si comporta, più o meno, come una valvola
che consente il flusso del liquido in una direzione e la blocca nella direzione opposta.
Più precisamente,
quando alla regione p di una giunzione è applicata una tensione positiva rispetto
alla zona n, la giunzione
si dice polarizzata direttamente e consente il passaggio della corrente; in
caso
contrario la giunzione si dice polarizzata inversamente e in dispositivo non consente il
passaggio della corrente.
Così,
la caratteristica corrente/tensione di un diodo appare come riportato nella figura seguente che
rappresenta
la classica proprietà rettificante della giunzione p/n.
Dalla figura si evince che la resistenza offerta dal componente in zona di polarizzazione diretta è
molto
bassa mentre è molto elevata in zona di polarizzazione inversa; all’aumento della
polarizzazione inversa intervengono poi altri fattori che non è significativo commentare in questa
sede.
221

Ma ancor più
significativo è l’accostamento di tre pezzetti di semiconduttore in modo tale che il
pezzetto centrale abbia tipologia di drogaggio opposta agli altri due; ciò consente di lasciar passare
la corrente o di bloccarla o anche di regolarne l’intensità giostrando
opportunamente con le tensioni
elettriche
di polarizzazione delle due giunzioni; insomma, come trasferire un flusso elettronico
attraverso uno strato a resistenza variabile, ed infatti, dall’inglese transferring resistor deriva la
definizione
transistor, coniata da John Pierce, uno dei collaboratori di William Shockley che,
assieme ad altri, componeva il gruppetto di ricercatori di cui si è detto.
Era
il 1948, ed era nato il componente che avrebbe saziato, fino ai giorni nostri, la fame di
interruttori digitali che sono alla base degli elaboratori, evitando l’impiego dei tubi elettronici, o
“ valvole” elettroniche, che realizzavano lo stesso scopo (il controllo di un flusso elettronico) ma in
modo
molto più dispendioso ed ingombrante.
222

Appendice E – CENNI SULLA TECNICA DI FABBRICAZIONE PLANARE DI
DISPOSITIVI
A SEMICONDUTTORE
I microprocessori vengono creati su un disco di silicio, attualmente del diametro di 200 o 300 mm,
chiamato
wafer; i wafer vengono ricavati “affettando” delle barre cilindriche ottenute, con speciali
procedimenti,
dal silicio liquefatto. I wafer ottenuti tagliando le barre sono successivamente
sottoposti ad una serie di lavorazioni al fine di rendere
la superficie praticamente priva di qualsiasi
asperità.
La produzione dei microprocessori sul wafer è una attività molto complessa che richiede un
notevole numero di passi successivi; tuttavia, per schematizzare il procedimento, le principali
attività sono le seguenti (per facilitare la rappresentazione grafica le dimensioni relative non sono
in scala):
-
si parte dal wafer di silicio
- il primo passo consiste nella creazione di uno strato di biossido di silicio sulla superficie del
wafer; questa attività avviene ad altissime temperature e lo spessore dello strato di ossido
dipende dalla temperatura e dal tempo di lavorazione
- successivamente, hanno luogo i cosiddetti processi fotolitografici
o si provvede inizialmente a ricoprire l’ossido con uno strato di materiale fotosensibile
o una fonte luminosa illumina quindi il materiale fotosensibile; tra la fonte luminosa
ed il materiale fotosensibile è posta una maschera; la esposizione alla luce cambia
Si
SiO2
Si
SiO2
Si
223

maschera
chimicamente le porzioni del materiale fotosensibile che è esposto alla luce (le
maschere sono create durante la fase di progetto dei circuiti che devono essere
riportati sul wafer)
o a questo punto la parte del materiale fotosensibile
che è stata esposta alla luce (e che
per questo è diventata attaccabile con particolari procedimenti) viene rimossa e viene
rimossa anche la parte di ossido sottostante
o viene rimossa anche la parte restante del materiale fotosensibile lasciando il wafer
ricoperto dall’ossido solo nelle parti che non sono state esposte nel procedimento di
mascheratura
SiO2
- si passa quindi al processo di drogaggio delle zone di silicio esposte
Si
SiO2
Si
SiO2
Si
224

- il processo di mascheramento, illuminazione e rimozione viene ripetute più volte al fine di
consentire la creazione, in una struttura tridimensionale al di sopra del wafer, della
circuiteria necessaria alla operatività del circuito integrato
- le finestre appositamente lasciate durante le operazioni di mascheratura vengono riempite di
metallo costituendo i collegamenti del circuito integrato con l’esterno
Il procedimento illustrato crea sul wafer un gran numero di circuiti integrati.
Una volta effettuati dei primi test sul wafer, il wafer stesso viene tagliato per ottenere i singoli
circuiti
integrati (chiamati die) che vengono ulteriormente testati e quindi sottoposti al packaging;
tramite il packaging ogni die viene inserito in un contenitore di protezione che fornisce all’esterno i
collegamenti necessari per l’uso del circuito; dopo una fase finale di test il prodotto è disponibile
per l’utilizzo. 225

Appendice F – FIBRE CHANNEL
Fibre Channel (FC) è una architettura standard per il trasferimento dei dati ad alta velocità tra
diversi nodi che adotta una tecnologia seriale di comunicazione full duplex. Ogni nodo ha un World
Wide Node Name (WWNN) ed ha uno o più adattatori FC; la maggior parte degli adattatori FC
dispone di una porta con un World Wide Port Name (WWPN); se un adattatore FC ha due porte
avrà corrispondentemente due WWPN.
Nodi e porte hanno un indirizzo di 64 bit (normalmente indicato tramite 8 gruppi di due cifre
esadecimali) assegnato dal costruttore all’interno di un range assegnato da un opportuno comitato
interno all’IEEE.
Questo
standard, definito da un consorzio di produttori, è stato accreditato dall’ ANSI (American
National Standards Institute).
In generale, i mezzi di connessione possono essere sia il rame sia la fibre ottica anche se la parte del
leone, nella realtà, è svolta dalla fibra ottica; si fa rilevare, a questo proposito, che il temine “fibre”
di fibre channel è differente dal termine “fiber” di fiber optics cioè fibra ottica, forse anche per
sganciare la tecnologia fibre channel dal concetto di fibra ottica; questa sottigliezza, però, in italiano
viene persa.
La architettura FC standard ha 5 livelli definiti da FC-0 a FC-4; da FC-0 a FC-2 si definisce come le
porte FC interagiscono, tramite i links di connessione, con le altre porte FC; da FC-3 ed FC-4 si
definisce come le porte FC interagiscono con le applicazioni.
La architettura FC è usata per trasportare traffico dati usando differenti protocolli tra i quali il Fibre
Channel Protocol (FCP) che potrebbe diventare il protocollo prevalente negli ambienti Open e
FICON che è e sarà sempre più il protocollo dominante per gli ambienti mainframe di architettura
IBM s/390; la architettura FC può anche trasportare traffico dati che impiega il protocollo IP.
Le topologie di rete previste nella architettura FC sono:
- point to point, in cui tra due porte, una residente sul sistema di elaborazione e l’altra sulla
unità di storage, è stabilita una connessione bidirezionale;
- switched fabric FC-SW, dove la connessione tra server e unità di storage è effettuata tramite
uno switch o più switches interconnessi tra loro; in quest’ultimo caso tra server e unità di
storage sono possibili diverse vie (path) tra le quali vengono scelte prioritariamente quelle
più brevi
- arbitrated loop FC-AL, dove servers e unità di storage sono connesse in una topologia ad
anello.
Le varie porte FC, appartenenti a server, unità di storage e switches, vengono definite secondo
quanto riportato nella figura seguente estratta da una pubblicazione IBM [7]. Nella figura si
individuano:
- N-PORT rappresentano le porte che consentono ai nodi di entrare nella topologia
- NL_PORT rappresentano N_PORT capaci di connessione in LOOP
- F_PORT rappresentano le porte di uno switch che connette un N_PORT
- FL_PORT rappresentano le porte di uno switch capaci di connessione in LOOP
- E-PORT rappresentano porte di connessione tra switches
226

Come detto la tecnologia a fibra ottica è la più usata nella implementazione della architettura Fibre
Channel.
I vantaggi della fibra ottica, dove la trasmissione delle informazioni avviene tramite impulsi di luce
anziché segnali elettrici, sono :
- grande ampiezza di banda (che può superare i 100 MB/sec full duplex per un totale di 200
MB/sec teorici)
- interferenze elettromagnetiche nulle
- dimensioni e pesi dei cavi inferiori
- etc.
Lo svantaggio
principale nell’uso delle fibre ottiche consiste nel maggiore costo complessivo
comprendendo in ciò anche la maggiore cura che deve essere posta nell’effettuare i cablaggi; in
generale, infatti, i cavi in fibra ottica non possono essere curvati oltre un certo limite, possono
subire danni se schiacciati da oggetti pesanti e non è in genere una buona idea stenderli senza
protezione al di sotto dei pavimenti sopraelevati dei centri di calcolo; per ciò, è consigliabile far
eseguire il cablaggio da operatori esperti e specializzati nel settore. I cavi in fibra ottica possono
essere di diversi tipi:
- jumper cioè una singola coppia che rende disponibili due vie unidirezionali di
comunicazione
- multi-jumper cioè cavetti che rendono disponibili più coppie di fibre
- trunk cioè cavi che, oltre a mettere a disposizione un alto numero di coppie di fibre, hanno
anche delle protezioni particolari per assicurare l’integrità delle fibre stesse
227

Una fibra ottica ha una struttura interna (core) ed una parte (cladding) che circonda questa struttura
interna; queste due zone sono realizzate con materiali differenti cosicché la zona di contatto si
comporta come uno specchio nei riguardi della luce che viaggia nella parte interna.
I vari tipi di fibre ottiche sono individuati dalla misura del diametro del core e del cladding; in tal
modo si avranno, ad esempio, fibre 50/125 dove il diametro del core è 50 micron ed il diametro del
cladding è 125 micron, fibre 9/125, 62,5/125, etc.
Si impiegano differenti tecnologie laser per la trasmissione della luce (short wave o SX e long wave
o LX) e da ciò dipende il tipo di fibra che deve essere impiegato (multimode normalmente con il
rivestimento di colore
arancione, o singlemode normalmente con il rivestimento di colore giallo) e
la lunghezza massima
del collegamento (link) realizzabile.
Lo specchietto
riportato sotto riassume le caratteristiche citate
Gli asterischi stanno a segnalare che l’impiego di fibre multimode in caso di tecnologia di
trasmissione LX
è possibile solo se vengono impiegati particolari accorgimenti; nel caso invece di
laser SX devono
essere utilizzate fibre multimode.
228

Appendice G - Sistemi Operativi per i Sistemi Centrali (Mainframes)
Premessa
I Sistemi Centrali comunemente detti ‘Mainframes’ sono generalmente caratterizzati da una
alta efficienza ed affidabilità, tale caratteristica è dovuta a proprietà architetturali intrinseche
dell’Hardware ma soprattutto alle qualità dei Software di Base o Sistemi Operativi in essi attivabili.
I Sistemi Operativi dei Mainframes sono anche in grado di fornire una vasta gamma di funzionalità
per la gestione
del Sistema (System Management) che rendono gli ambienti Operativi (Operating
Environments) di facile gestione ed uso
anche a fronte di complesse realtà elaborative (Data
Centre).
Possiamo raggruppare i Sistemi Operativi in cinque grandi famiglie (le denominazioni
di
ciascuno di essi è cambiata nel tempo pur essendo state mantenute
alcune caratteristiche di base e
funzionalità ):
al Storage) tipici dei grandi
ambienti transazionali come Banche e Grandi Organizzazioni caratterizzate dall’uso di
grandi Basi di Dati ed alti volumi transazionali :
a. MVS/SP , prodotto negli anni settanta , ha introdotto per primo il concetto di
Memoria Virtuale consentendo di creare le prime grandi strutture informatiche
(Centri Elaborazione Dati), praticamente non più usato . La dimensione massima
della Memoria Virtuale era di 16 MegaBytes
b. MVS/XA, tipico dei primi anni ottanta ha introdotto l’architettura Estesa
(eXtended Architecture) fornendo l’indirizzamento di Memoria a 31bit, e quindi
estendendo la dimensione della Memoria Virtuale da 16 Mbytes a 2 GigaBytes.
c. MVS/ESA, Tipico della fine degli anni ottanta, ha affiancato alla architettura una
serie di nuove funzioni relative all’ I/O ed un tecnica intermedia di gestione della
memoria che consentiva di estenderla solo per la parte dati a più di 2 GigaBytes
(Data Spaces).
d. OS/390, Tipico degli anni novanta ha introdotto una nuova interfaccia utente di
tipo UNIX (Unix System Services) ed ha cominciato ad aprirsi a molti standard
di mercato introducendo il TCP/IP, il POSIX ed i Linguaggi C/C++ e JAVA.
e. z/OS, tipico dei nostri giorni ha introdotto prima l’indirizzamento a 64bit per la
memoria Centrale e poi per la memoria Virtuale portando la sua dimensione a 2 64
1. Sistemi Operativi derivanti da MVS (Multiple Virtu
Bytes . Ha inoltre ulteriormente ampliando l’adesione agli Standard. La versione
corrente è la 2.7.
2. Sistemi Operativi derivanti da TPF (Transaction Processing Facility), disegnato per
elaborare altissimi volumi di transazioni in tempo reale ed alta affidabilità, generalmente
usato per Sistemi di booking di Aerolinee ed altre Aziende di trasporto.
a. TPF. Disegnato negli anni settanta e poi migliorato in quattro versioni successive
ha costituito la base per i Sistemi di Prenotazione di molte aziende che gestiscono
il trasporto di persone. Ha una struttura estremamente semplice ed un dimensione
contenuta: è in grado di avviarsi in pochi secondi e funzionare per anni senza
essere mai “spento”. Non fornisce ambienti di Programmazione
e Supporto per i
quali si appoggia ad un Sistema Operativo della Famiglia MVS.
b. zTPF è la versione a 64bit , resa disponibile da poco tempo. La versione corrente
è la 1.1.
3. Sistemi Operativi derivanti da VM (Virtual Machine), cioè Software in grado di
‘virtualizzare’ ambienti operativi suddividendo i Calcolatori in ‘macchine virtuali’ tali
229

che mediante una condivisione di Risorse Elaborative si abbia la sensazione di disporre
di una quantità di esse maggiore di quelle realmente disponibili.
a. VM/SP – è la prima versione risalente agli anni settanta, era in grado di
virtualizzare altri sistemi della stessa architettura e Gestire 16 Megabytes di
Memoria Virtuale e Reale.
b. VM/XA – prodotto agli inizi degli anni ottanta, funziona a 31bit e può
virtualizzare altri sistemi di tipo XA (eXstended Architecture) gestendo un
massimo di 2 GigaBytes di Memoria Virtuale e Reale.
c. VM/ESA – Prodotto alla fine degli anni ottanta funziona a 24 o 31 bit e può
virtualizzare sia Sistemi XP, che sistemi XA che Sistemi ESA .
d. z/VM – Tipico della fine degli anni novanta è la versione corrente e funziona a
64 bit. Dal 2000 in poi anche il Sistema Operativo LINUX può essere ospitato in
macchine Virtuali sotto z/VM. La versione corrente è la 5.1.
4. Sistemi Operativi derivanti da VSE (Virtual Storage Extended), disegnato come
alternativa più semplice e a costi più contenuti di MVS con fini similari e tuttora in uso
in un certo numero di installazioni per funzioni commerciali e di uso generale.
a. VSE/SP – è la versione degli anni settanta , mantenuta fino a tutti agli anni
ottanta, funziona a 24 bit ed indirizza 16Mbytes di memoria.
b. VSE/ESA prodotto negli anni 90 ha esteso l’indirizzamento a 2 Gigabytes. Del
VSE non sono state prodotte le versioni XA.
c. z/VSE – è la versione corrente ma a scapito del nome continua ad indirizzare a
31 bit. Il VSE al momento non prevede il supporto a 64bit.
5. Sistemi Operativi LINUX, sorto agli inizi degli anni 2000 come alternativa a basso
costo e ‘collaterale’ ai sistemi maggiori per ospitare su uno stesso elaboratore centrale
anche funzioni di supporto infrastrutturale sussidiarie a quelle principali usualmente
svolte da MVS , VSE o TPF.
a. Linux for S/390- è a 31bit , le distribuzioni più usate sui Sistemi Mainframe
sono la SuSe e la RedHAt. Si basa sul Kernel 4.2.
b. Linux for Zeta Series (zLINUX)- a 64 Bit è la versione corrente basata sul
Kernel 4.6
230

Caratteristiche comuni dei Sistemi Operativi (z/Architecture)
I Sistemi Operativi dei Mainframes si fondano sulla architettura dei Calcolatori Centrali
IBM variamente denominata nei successivi momenti storici S/360, S/370, S/390 , z/Architecture ....
Tale architettura rappresenta una serie di regole comuni a tutti i calcolatori della Famiglia
dei Mainframes ed è descritta in una specifica pubblicazione denominata “Principle of Operations” .
Sono elementi della architettura:
1. Il SET di istruzioni Macchina (Complex Instruction Set Computer – CISC)
2. I Registri del Calcolatore (Registers)
3. L’organizzazione ed i metodi di indirizzamento della Memoria (Memory Addressing)
4. Il metodo per elaborare le interruzioni (Interrupt Hadling)
5. Le caratteristiche di Immissione ed Emissione dei Dati (I/O Handling)
6. L’interfaccia Operativa (Operator Facilities)
7. Il metodo per elaborare gli errori (Machine Check Handling)
8. L’Organizzazione Generale dei Calcolatori (Figura 1)
Figura 1 – Organizzazione Generale dei Calcolatori
L’architettura dei
Calcolatori è
elemento essenziale per la costruzione degli strati a più basso livello dei Sistemi Operativi: in
quanto essi prendono il controllo del Calcolatore ed hanno il compito di gestirlo:
231

Analogamente la comprensione delle caratteristiche architetturali è essenziale al fine di valutare
l’efficienza funzionale e complessiva del Sistema
di Elaborazione, costituito da Hardware +
Sistema Operativo.
In dettaglio la z/Architecture definisce oggi circa 640 istruzioni CISC in 21 formati; circa 64
registri di macchina per uso generale o specifico, ed una particolare struttura denominata PSW
(Program Status Word ) in grado di realizzare un complesso metodo per eseguire differenti
programmi contemporaneamente (Fig 2).
Figura 2 – Struttura della PSW a 64 bit
Le caratteristiche più importanti dei Sistemi Operativi che usano la z/Architecture rimangono
tuttavia:
- l’organizzazione e gestione della Memoria Virtuale
- la compatibilità binaria del codice eseguibile attraverso le varie versioni di Sistema
(programmi ‘compilati’ negli anni sessanta sono infatti tutt’oggi eseguibili sui Sistemi più
moderni senza alcuna ricompilazione)
- l’indirizzamento tri-modale (24 , 31 e 64 bit) che riguarda dati e programmi
- ed il sofisticato Sistema di gestione dei lavori eterogenei (Workload Management) il quale
consente un alto livello di multiprogrammazione all’interno della stessa immagine di
Sistema Operativo (il workload management dei Sistemi di tipo MVS consente ad esempio
di fissare degli obiettivi di prestazione in termini di tempi di risposta che vengono poi
‘onorati’ automaticamente dal Sistema mediante modulazione dell’uso delle risorse
disponibili).
Elementi collaterali ma connessi con l’architettura sono invece il Sottosistema di I/O la
Virtualizzazione dell’ Hardware e dalla tecnica di Clustering di Sistemi denominata Parallel
Sysplex.
Una caratteristica peculiare della Architettura introdotta da IBM nel 1964 , è rappresentata
dalla “compatibilità binaria del codice” dichiarata come principio fondante della architettura
232

stessa e fino ad oggi mantenuta: in base a questo principio un programma scritto seguendo regole
della Architettura potrà sempre essere eseguito su un qualunque calcolatore della stessa Architettura
senza alcuna modifica. In pratica ciò significa che applicazioni scritte negli anni sessanta
funzionano ancora oggi senza mai essere state ricompilate.
233

Gestione della Memoria (Virtual Storage)
La gestione della Memoria e l’introduzione del concetto di Memoria Virtuale rappresentano
uno degli elementi essenziali della Architettura sin dalla sua prima pubblicazione risalente agli anni
sessanta.
Memoria Virtuale (Pages)
Processo1 Processo2
1
2
3
4
1
2
3
Processo3
Figura 7 – Schema della Memoria Virtuale
1
2
3
Memoria Reale (Frames)
La Memoria Virtuale è un artificio tecnico che consente di eseguire in un dato elaboratore
programmi di dimensioni complessive maggiori a quelle della memoria realmente disponibile
(Memoria Reale),
facendo uso di aree di transito su altri dispositivi (ad esempio dischi magnetici
detti in questi caso Memoria Ausiliaria).
Il processo consiste nello scomporre tutti i programmi in strutture di lunghezza fissa
usualmente pari a 4KBytes (detti Pagine o Pages) mantenendone una definizione della loro struttura
iniziale in un Indice fissato in memoria centrale (Page Index) . Da allora le pagine usualmente
residenti in memoria Ausiliaria verranno trasportate in Memoria Reale (Page IN) solo al momento
del
loro effettivo utilizzo (Elaborazione) e poi riportate in Memoria Ausiliaria (Page Out) quando
non più necessarie all’elaborazione. Tale processo avviene in modo trasparente all’utente
1
4
2
3
Memoria Ausiliaria (Slots)
2
Index
Index
PAGE IN PAGE OUT
FIXED FRAMES
1 3 1 2 3
234

(Programma) che avrà l’illusione di disporre di una memoria (detta appunto Virtuale) pari alla
dimensione
del Programma , anche se in effetti dispone solo di una parte di essa in ogni momento.
I processi di ‘paginazione’ a carico del Sistema Operativo sono in generale molto efficienti
ed hanno consentito nel passato la gestione di molti grandi programmi con memorie relativamente
piccole. Oggi a cause delle accresciute dimensioni delle Memorie Reali (Central Storage) e del loro
diminuito costo la Memoria Virtuale anche se divenuta standard su tutti i Sistemi Operativi ha
perduto parte della sua importanza e le attività di ‘paginazione’ si sono notevolmente ridotte nei
Sistemi reali. La tecnica rimane comunque valida ed in uso.
L’uso di memoria Virtuale rende altresì necessaria la presenza di un ulteriore componente
hardware denominato DAT (Dynamic Address Translator). Il DAT è reso necessario per tradurre in
ogni momento gli indirizzi virtuali in indirizzi reali ed è un elemento indispensabile per la gestione
della Memoria.
235

Sottosistema di I/O (Channel Subsystem)
Il sottosistema di Input/Output (I/O) dei Calcolatori realizzati secondo le regole della
z/Architecture si basa su uno schema di principio introdotto da IBM negli anni settanta e
caratterizzato dal concetto di Canale (Channel
Path), Unità di Controllo (Control Unit) e
Dispositivo (Device) (Figura 3).
CPU
Multiplexor
Memoria
Sottosistema I/O
Canale
Canale
Canale
Canale
Daisy Chaining
Figura 3 – Sottosistema di I/O IBM a canali
Multiple Path
Lettore Schede
Unita Nastro
Perforatrice
Stampante
Tamburo
Ogni Device è collegato al complesso elaborativo attraverso una o più Control Unit e ciascuna
Control Unit è collegata al Sistema Elaborativo mediante uno o più canali.
I canali hanno la caratteristica di collegare più unità di controllo (daisy chaining) ovvero più
di un canale può collegare la stessa Control Unit allo stesso elaboratore, in questo caso i vari
percorsi disponibili ( fino a 16) vengono automaticamente bilanciati (Dynamic path reconnection).
Tale schema di funzionamento è stato ulteriormente migliorato nel corso degli anni
introducendo vari tipi di protocollo di canale e processori dedicati all’ I/O e modificando le
tecnologie del mezzo trasmissivo (Rame, Fibra ottica multimodale, Fibra ottica monomodale) e del
protocollo comunicativo (Parallelo, EsCON, FICON , ETHERNET) ed è stato arricchito di
funzionalità collaterali richieste principalmente dall’uso di Sistemi Operativi non proprietari come
LINUX (QDIO, SCSI).
Disco
Disco
IperNastro
DispositivoTP
236

La tecnica di funzionamento del Sottosistema di I/O è schematizzata nella Figura 4:
FREE
CPU
USER PGM
Channel PGM
USER PGM
Elaboratore Unita’ Periferica
Interrupt
Disconnect
Interrupt
SAP
Sub Channel
FREE
Sub Channel
Dynamic Path
Reconnect
Il programma utente che necessita di effettuare una operazione di I/O interrompe la propria
elaborazione ed attiva uno speciale programma detto Channel Program il quale sarà eseguito da una
CPU differente e specializzata denominata SAP (Service Assist Processor), tale CPU che utilizza
una memoria dedicata denominata HSA (Hardware System Area) si occuperà di gestire mediante
una componente attiva esterna al Calcolatore denominata Control Unit (CU)la quale a sua volta si
occuperà della vera operazione di I/O.
Poiché SAP, CU e canale sono componenti attive dotate di memoria e capacità elaborativa
indipendenti l’operazione di I/O non verrà eseguita a carico del Processore Centrale (CPU) che
rimarrà libero durante tutta l’operazione e potrà quindi dedicarsi agli altri utenti del Sistema e verrà
riattivato solo ad operazione conclusa. Il Daisy Chaining se presente e la Dynamic Path
Reconnection restano a carico del SAP.
Questa tecnica di gestione dell’I/O consente ai Sistemi funzionanti con la z/Architecture di
realizzare un gestire grandi volumi di dati con alte prestazioni complessive ed inoltre consente di
condividere in modo semplice i dispositivi (devices) tra varie immagini di Sistema Operativo
operanti sullo stesso complesso elaborativo o su complessi diversi.
CU
CU-Firmware
Figura 4 – Schema di Funzionamento Sottosistema di I/O
Device
237

Gestione di lavori eterogenei (Workload Management)
Il Gestore di Carichi di lavoro eterogenei (Workload Manager) è un componente del Sistema
Operativo in grado di suddividere le risorse elaborative (CPU, Memoria e I/O ) tra diversi lavori
concorrentemente attivi nello stesso sistema.
La necessità di un tale componente
nasce dalla constatazione che lavori con diverso profilo
di carico possono interferire tra loro allorquando essi operano sotto il controllo dello stesso Sistema
Operativo.
In particolare lavori che vengono costantemente alimentati con dati di ingresso (Job Batch)
che provengono da dispositivi pre registrati (Dischi o nastri), tendono a richiedere risorse con
maggiore
frequenza rispetto a lavori con interfaccia umana a terminale video (Interattivi) i quali
sono soggetti
a tempi di reazione dell’individuo, viceversa i lavori con interfaccia Interattivi
richiedono
tempi di risposta più rapidi, in quanto questi sono direttamente percepiti dall’individuo
che opera,
al contrario dei Lavori Batch nei quali il tempo di risposta incide soltanto sul tempo
complessivo
di elaborazione.
Sono lavori Batch la produzione di estratti conto trimestrali di una banca, la stampa delle
Fatture,
la produzione di tabulati su carta, le copie di archivi; sono invece lavori Interattivi la
immissione
delle prenotazioni di Voli o treni, le richieste dello sportellista bancario, la navigazione
su Web etc.
Infine anche i programmi che costituiscono il Sistema Operativo (Programmi di
Sistema) in
quanto utilizzatori di risorse possono essere influenzati negativamente dai lavori utente in
esecuzione,
essi invece dovrebbero risultare prioritari comunque.
La
simultanea presenza di lavori batch ed interattivi sotto il controllo dello stesso Sistema Operativo
che tra l’altro esegue i suoi programmi di Sistema può comportare, se non gestita, un notevole
rallentamento
dei tempi di risposta percepiti a scapito dagli utenti interattivi ed in favore del batch
ed inoltre può compromettere la corretta gestione dei programmi di Sistema: compito del Workload
Manager
è quello di consentire tale concomitanza ed in più di fare in modo che il Gestore del
Sistema (System Administrator) possa definire all’interno della stessa classe di lavori (Batch,
Interattivi
o di Sistema) varie classi di importanza , fino a definire i tempi di risposta del Singolo
lavoro interattivo in termini di secondi o frazioni(Goal).
In tal modo sarà sempre possibile eseguire carichi di lavoro eterogenei sotto il controllo dello stesso
Sistema
Operativo.
Tutti i Sistemi Operativi che seguono la z/Architecture ed in particolare quelli della famiglia
MVS/ESA , OS/390 e z/OS sono dotati di un dispositivo Software per gestire carichi eterogenei:
inizialmente
tale dispositivo si è sostanziato attraverso una serie di Sottoprogrammi di Sistema
(Routines) che vanno sotto il nome di SRM (System Resources Manager) e successivamente si è
evoluto in un componente dedicato e specifico denominato WLM (WorkLoad Manager) in grado di
definire degli obiettivi di prestazione valutandone in ogni
istante il grado di raggiungimento
intervenendo sulla distribuzione delle risorse tra i vari utilizzatori (compreso lo stesso Sistema
Operativo) in modo da tentare di mantenere le prestazioni richieste.
238

Il meccanismo
di funzionamento del WLM è schematizzato nella Figura 5
Job 1 Job 2 Job 3
Goal < 1 sec Goal < 5 sec Discrectionary
Figura 5 – Schema di Funzionamento del WLM
Execute
Job 1
Execute
Job2
Goal
OK
Y
Goal
OK
Y
Execute
Job3
N
N
ENDED
Y
ENDED
Y
N
N
239

Virtualizzazione mediante Hardware (PR/SM)
o Software (VM)
La possibilità di suddividere un Elaboratore in un numero di Sistemi separati ed indipendenti
tali che le risorse vengano ripartite tra di essi in modo che la somma percepita sia maggiore delle
risorse effettivamente
disponibili (altrimenti noto come Virtualizzazione delle risorse) è una
caratteristica presente su tutti gli elaboratori di Tipo Mainframe. Anche se non specificamente
contenuta nelle specifiche architetturali è ormai divenuta un dispositivo standard di tutti gli
elaboratori di tale classe.
La virtualizzazione è resa possibile solo dalla capacità dei dispositivi virtualizzatori di
condividere (sharing) risorse tra più ambienti virtuali e si estrinseca in due possibili opzioni:
• Virtualizzazione Mediante Hardware (meglio nota come Partitioning Resources and
System Management o PR/SM), ovvero la possibilità offerta dall’ Hardware di suddividere
l’elaboratori in parti dette Partizioni Logiche o LPAR tali che tutte le risorse possano essere
condivise tra le LPAR. Nei Sistemi più moderni si possono realizzare fino 60 LPAR,
indipendentemente dal numero e tipo di processori installati. Le LPAR si presentano ai
Sistemi Operativi come se fossero degli Elaboratori distinti ed isolati anche se esse possono
essere interconnesse mediante dispositivi interni ad alta velocità detti HiperSockets.
• Virtualizzazione Mediante Software attraverso il Sistema Operativo z/VM in grado di
creare degli ambienti separati ma capaci di condividere le risorse, denominati Macchine
Virtuali. Un Sistema z/VM può ospitare un grande numero di macchine virtuali ciascuna
delle quali può attivare un Sistema Operativo che funzioni con la z/Architecture, compreso
una nuova istanza di Virtualizzatore z/VM che viene detto di Secondo Livello. Un
Virtualizzatore Software usualmente è attivato in una partizione Logica LPAR.
z/OS Linux
VLAN
z/OS
z/VM
Linux
z/OS Linux
z/VM z/VM
Hypersockets
Linux Linux z/OS
La Virtualizzazione Hardware e Software sono meccanismi complementari e possono operare
contemporaneamente sullo stesso sistema fisico (Figura 8).
VLAN
Figura 8 – Livelli multipli di Virtualizzazione dei Mainframes
Sistemi Operativi
Sistemi Operativi o VM 2° Livello
MACCHINE VIRTUALI
LPAR
PR/SM
HARDWARE
240

A differenza di altre realizzazioni presenti sul mercato la Virtualizzazione presente nei
Sistemi Mainframe di IBM presenta alcune caratteristiche degne di rilievo e a volte uniche, ad
esempio:
• Un ottimo isolamento degli ambienti virtuali con completa indipendenza delle macchine
virtuali le une dalle altre
• Una ottima capacità di condivisione delle risorse fisiche: ad esempio la capacità di
condividere i processori ed i dispositivi
di I/O tra diverse LPAR o Macchine Virtuali e
parimenti la possibilità di dedicarli ad una LPAR o Macchina Virtuale se ritenuto
necessario.
• Il controllo da una ‘console’ unica o da una Macchina Virtuale di servizio.
• La totale dinamicità delle definizioni che sono modificabili sia in modo automatico che
manuale a Sistemi attivi e senza
necessità di interrompere i lavori in corso .
• L’integrazione su Sistemi Multipli o Cluster con meccanismi di Workload Management che
consente di variarne la distribuzione tra le partizioni logiche in modo da realizzare gli
obiettivi di prestazione in funzione dei “Goals” previsti.
Il PR/SM è un dispositivo standard in tutti gli elaboratori denominati System Zeta di ultima
generazione, mentre il Software z/VM è un software opzionale.
Le tecniche di virtualizzazione ed il supporto di Linux da parte delle macchine Virtuali consentono
di realizzare attraverso gli elaboratori di tipo Mainframe la cosiddetta “Server Consolidation” cioè
il consolidamento
fisico di molti Serventi all’interno di un unico Grande Sistema virtualizzato nel
quale ogni Servente di partenza può mantenere le sue caratteristiche pur risiedendo su una parte di
un elaboratore più grande.
La Server Consolidation (Figura 9 ) consente di utilizzare meglio i Sistemi e permette di
contenerne i costi Operativi se e solo se la virtualizzazione che la realizza consente la condivisione
di risorse (Tecnologia Abilitante).
Paris
London
Accentramento
Rome Rome
Figura 9 – Il Processo di Server Consolidation
Consolidamento
Fisico
Consolidamento
Logico
241

Tecnologia di Clustering (Parallel Sysplex)
Gli elaboratori IBM di tipo Mainframe consentono di realizzare un cluster di Sistemi denominato
Parallel Sysplex sotto il controllo del Sistema Operativo
z/OS o Sistemi precedenti della stessa
famiglia. (Figura 6)
IBM System Z
40 Km
z/OS
Sysplex Timer
40 Km
40 Km
IBM System Z
z/OS
CF
IBM System Z
CF
IBM System Z
Sysplex Timer
IBM System Z
Il Parallel Sysplex è costituito da tre elementi tipici :
• Sistemi componenti : da due a trentadue immagini di Sistema Operativo z/OS o OS/390 che
costituiscono le componenti operative del Cluster.
• Coupling Facilities : Speciali componenti che hanno la responsabilità di mantenere traccia
degli aggiornamenti effettuati sui Dati da ciascun componente Sistema in modo da ricostruirli in
caso di caduta di uno di essi e di garantire la sequenzialità degli aggiornamenti . Ne servono
almeno
due su Sistemi Fisici diversi.
• Sysplex Timer : Orologi elettronici in grado di fornire lo stesso ‘tempo’ a tutti i componenti.
Ne servono almeno due.
Ciascun Elaboratore può ospitare uno o più Sistemi ed uno o più Coupling Facilities, in
partizioni logiche LPAR distinte; i Sysplex Timer invece sono dispositivi esterni.
Allo stato attuale della tecnologia che comunque è in fase di miglioramento la distanza
massima tra due componenti del Parallel Sysplex deve essere di 40 Km.
Il Parallel Sysplex nato intorno alla fine degli anni ottanta , inizialmente come strumento di
scalabilità orizzontale degli Elaboratori, assume oggi la caratteristica di Sistema per garantire la
continuità di Servizio
del complesso a fronte di fermi di una delle Immagini di Sistema per cause
pianificate (Manutenzione) o non pianificate (Guasto).
z/OS
Figura 6 – Architettura di Clustering denominata Parallel Sysplex
z/OS
40 Km
242

Le caratteristiche peculiari del Parallel Sysplex sono:
• La possibilità di vedere il Cluster come un Sistema unico sia ai fini delle esecuzioni dei
lavori , sotto il controllo del WLM, che ai fini della Gestione (Console Unica)
• La possibilità di condividere basi dati (Data Sharing) tra i Sistemi Componenti con garanzia
di aggiornamenti controllati e coerenti.
• La possibilità di attivare (aggiungere) o disattivare (togliere) Sistemi durante le fasi di
lavoro in maniera completamente trasparente rispetto al complesso e senza interruzioni di
servizio.
• La possibilità di controllare tutto il cluster da un unico punto ‘console’ indipendentemente
dalla sua locazione fisica.
• La capacità del complesso di continuare ad operare , ricoverando
tutte le attività in corso e
senza perdita di dati in occasione di distruzione (guasto o disastro) di una parte del
complesso quando siano ancora attivi almeno un Sistema, una Coupling Facility ed un
Sysplex Timer , senza alcuna interruzione apprezzabile di Servizio.
Il Parallel Sysplex si presenta come il Cluster più completo e sofisticato del mercato,
essendo in grado di agire su base geografica operando in perfetta continuità di Servizio a fronte di
fermi pianificati e non pianificati.
Esso potrà indifferentemente essere attivato come strumento di Business Continuity e di
Disaster Recovery ovvero come strumento di scalabilità orizzontale presentando anche la
caratteristica di fare crescere i Sistemi oltre la loro massima espandibilità con l’aggiunta di altri
Sistemi (fino a 32) nello stesso complesso elaborativo.
243

Strumenti
per la Gestione del Sistema (System Management )
I Sistemi Centrali (Mainframes) sono stati progettati per garantire una continuità di
Servizio a fronte di qualunque tipo di evento esterno.
La sigla ‘Zeta’ ricorrente nel nome che IBM suole dare a tali Sistemi sta ad indicare la frase
‘Zero Downtime’ che equivale a dire ‘mai
fermi’ .
La continuità
di Servizio e più in generale la resilienza dei Sistemi sono frutto di una grande
affi dabilità dell’ Hardware ma anche e soprattutto dalle caratteristiche del Software e dai sofisticati
strumenti di Gestione del Sistema (System Management) che esso stesso mette nativamente a
disposizione degli Utenti.
In particolare riferendoci al Sistema Operativo z/OS oltre ai già citati Workload Manager
(WLM + SRM) e Parallel Sysplex, ricordiamo il Sistema unificato per il trattamento dei dati detto
Storage Managem ent System (SMS) basato cinque componenti essenziali:
• DF/SMS responsabile della allocazione degli spazi su Disco, della gestione dei Cataloghi
di Archivi (Data sets) su Disco o Nastro.
• DF/HSM gestore integrato delle gerarchie di memoria, in grado di spostare
automaticamente dati su vari tipi di Supporto Fisico (Disco Veloce, Disco Lento, Nastro)
in base al loro utilizzo.
• DF/DSS strumento per eseguire le copie, integrato con strumenti tipici dello Storage come
la Flash Copy o la Concurrent Copy.
• DF/RMM strumento per gestire le nastroteche o le copie su nastro, compresa la
catalogazione e gestione dei supporti (Data Cartridge).
• DF/SORT strumento in grado di operare ordinamenti e selezioni di dati.
SMS è
Centre
un componente standard del Sistema Operativo e facilita enormemente la gestione del Data
dal punto di vista dello Storage su disco.
Altri strumenti fondamentali per il System Management sono le componenti di z/OS
denominate:
• JES2 (Job Entry Subsystem) responsabile della sottomissione e controllo dei lavori a
blocchi (Batch Jobs), ovvero che vengono sottomessi al Sistema ed eseguiti senza intervento
umano nelle fasi intermedie (ad esempio la stampa delle fatture, la stampa degli Stipendi, la
creazione di tabulati sono tipici lavori batch)
• TSO (Time Sharing Option) lo strumento interattivo per accedere al Sistema da un
Terminale Video e dare Comandi al Sistema Stesso. Fornisce anche un ambiente per la
creazione e compilazione dei Programmi
• ISPF/PDF lo strumento che consente l’Editing e la gestione degli archivi e dei programmi
sotto il controllo del TSO.
• SDSF (Spool Display and Search Facility) . Consente di visualizzare lo stato dei lavori
sottomessi al Jes2 e di visualizzarne le stampe prodotte ovvero di avviarne l’emissione su
una stampante. Opera sotto il controllo del TSO
• VTAM/TCPIP . Sono le componenti comunicative per le connessioni SNA e di tipo
Internet
244

• SMF/RMF . Sono componenti in grado di monitorare il Sistema in tutte le sue parti e di
fornire dati sul suo utilizzo.
• USS (Unix System Services) .Fornisce una interfaccia di tipo POSIX con una Shell in grado
di eseguire programmi con modalità UNIX.
Oltre alle componenti sopra citate esistino altri Strumenti per il System Management forniti
come prodotti Software separati da IBM o da ISV, di questi fanno parte:
• Gestori della Sicurezza controllano gli accessi al Sistema e le autorizzazioni all’uso delle
risorse
• Schedulatori sono in grado di sottomettere lavori al Sistema secondo calendari prestabiliti
(Piani di Schedulazione ) e di controllarne Automaticamente l’esito
• Altri prodotti di Monitoring del Sistema e dei Sottosistemi.
I Sistemi Operativi diversi da z/OS presentano anch’essi una vasta gamma di componenti
per il System Management , con denominazioni differenti, ma simili
nella funzionalità.
245

Sottosistemi Applicativi e Compilatori
Per concludere questa breve dissertazione sui Sistemi Operativi dei Mainframe ricordiamo
l’area prettamente applicativa costituita dai Sottosistemi Applicativi e dai compilatori.
Partendo da questi ultimi ricordiamo relativamente a z/OS (ma genericamente
per tutti i
Sistemi) che i principali linguaggi utilizzabili sui Sistemi Centrali sono:
• COBOL
• PL/I
• REXX
• C
• C++
• Java
Mediante questi possono essere realizzate applicazioni
BATCH o sotto il controllo di un
Sottosistema
Applicativo
I Sottosistemi Applicativi (detti anche MiddleWare) sono Software di uso generale che si
interpongono
tra il Sistema Operativo ed i programmi Applicativi per facilitarne l’esecuzione in
particolari condizioni ad esempio da parte di molti utenti concorrenti. Nell’area dei Sottosistemi
Applicativi annoveriamo quattro importanti strumenti Software:
• CICS si tratta di un gestore di contesto per ambienti ad utenti interattivi multipli: Consente
l’esecuzione simultanea da parte di molti utenti di programmi scritti in COBOL, PLI, C,
C++,JAVA che accedano a dati gestiti da SMS o da un Data Base Gerarchico (DLI) o
relazionali (DB2) , controllandone il contesto, l’integrità e gestendo le condizioni di errore
(rollback).
• DB2 è il gestore di data Base Relazionale accessibile con linguaggio SQL o con schemi
XML. Consente di eseguire direttamente programmi in COBOL o JAVA (detti Stored
procedure) o può essere richiamato da CICS, IMS o Batch.
• IMS/DLI si tratta di un gestore di contesto per ambienti ad utenti multipli e
contemporaneamente di un Gestore di dati gerarchici (DLI). La componente transazionale
può usare anche dati relazionali DB2, mentre il Data Base Gerarchico DLI può essere usato
separatamente per esempio dal CICS o da Batch.
• WebSphere AS è il Motore di applicazioni interattive scritte in JAVA, secondo il Modello
J2EE. Si occupa di gestire entità e contesto (session), può accedere a programmi relazionali,
generalmente accoppiato a presentazione HTML o XML.
246

Riferimenti Bibliografici della Appendice E
• SA227832 - z/Architecture – Principle of Operations International Business
Machines Corporation Poughkeepsie , N.Y.,
12601-5400 United States of America
(September 2005).
• William Stallings – Architettura e Organizzazione dei Calcolatori Elettronici edizioni
Pearson – Prentice Hall – 2004
• J Hoskins – B Frank – Exploring IBM ^ zSeries and s/390 Servers
• IBM Scholar Program Course Material – Versione
Italiana a cura di Angelo
Barbarino – Ottobre 2005
Elenco delle Figure e Fonti della Appendice E
1. Organizzazione Generale dei Calcol atori – SA227832 – z/Architecture – Principle of
Operation – IBM Corporation NY Usa – (Sept
2005)
2. Struttura della PSW a 64 bit – SA227832 – z/Architecture – Principle of Operation –
IBM Corporation NY Usa – (Sept 2005)
3. Sottosistema I/O IBM a Canali – William
Stallings – Architettura e Organizzazione
dei Calcolatori Elettronici edizioni Pe arson – Prentice Hall – 2004
4. Schema di Funzionamento Sottosist ema I/O
- IBM Scholar Program Course
Material – Versione Italiana a cura di Angelo
Barbarino – Ottobre 2005
5. Schema di Funzionamento del WLM - IBM Scholar Program Course Material –
Versione Italiana a cura di Angelo Barbarino
– Ottobre 2005
6. Architettura di Clustering denominata
Parallel
Sysplex - IBM Scholar Program
Course Material – Versione Italiana a cura di Angelo Barbarino – Ottobre 2005
7. Schema della Memoria Virtuale - IBM Scholar
Program Course Material – Versione
Italiana a cura di Angelo Barbarino – Ottobre 2005
8. Livelli Multipli di Virtualizzazione - IBM Scholar
Program Course Material – Versione
Italiana a cura di Angelo Barbarino – Ottobre
2005
9. IL Processo di Server Consolidation - IBM Scholar Program Course Material –
Versione Italiana a cura di Angelo Barbarino
– Ottobre 2005
247

Bibliografia
[1] Nuovo accordo di Basilea sui requisiti patrimoniali http://www.bancaditalia.it/vigilanza_tutela/vig_ban/pubblicazioni/basilea/basilea_patrim.pdf [2] IBM Journal of Research and Development vol 47, Nr 4 July 2003
Innovation in tape storage automation at IBM
[3] L’International Technology Roadmap for Semiconductors
(ITRS)
http://public.itrs.net
[4] IBM Journal of Research and Development vol 44,
Nr 3 May 2000
The future of magnetic data storage technology
[5] IBM Journal of Research and Development
vol 44, Nr 3 May 2000
Holographic data storage
[6] Codice in materia di protezione dei dati personali
http://www.garanteprivacy.it/garante/doc.jsp?ID=722132
[7] IBM REDBOOKS
– Ficon Implementation Guide Febbraio 2005
capitolo 1
[8] IBM Journal of Research and Development
vol 47, Nr 4 July 2003
Fifty years of IBM innovation with information storage on magnetic tape
[9] IBM Systems Journal vol 44, Nr 1, 2005
Aligning technology and business: Applying
patterns for legacy transformation
248

A
accettori......................................................204
accounting ..................................................172
ACL (Automatic Cartridge Loader).............82
alimentazione elettrica ...............................161
Amdahl, legge di..........................................45
Analista ......................................................143
Application Programming Interface.............22
architetture funzionali ................................104
Areal Density ...............................................66
aree di servizio ...........................................156
Arpanet.......................................................105
ATL (Automatic Tape Library) ...................83
attuatore........................................................66
B
back level (versione software) ...................118
benchmark....................................................44
Bit per Inch...................................................66
BLADE ........................................................54
bobine di nastro............................................80
Business continuity ....................................189
C
cartucce di nastro (cartridge)........................81
CD-R
............................................................89
CD-RW
........................................................89
centralizzazione............................................52
ciclo di clock ................................................41
cilindro .........................................................65
Client/Server ................................................22
Clienti.........................................................170
captive ....................................................170
interni .....................................................170
qualità nella gestione aziendale..............170
clock rate......................................................41
Collaudatore...............................................144
condizionamento ambientale......................163
conduttori ...................................................203
connettori software.....................................128
consolidamento ............................................53
consulenti ...................................................175
Contratti informatici...................................176
prodotti hardware ...................................176
prodotti software ....................................176
servizi.....................................................177
costo di abbandono.........................................8
CPI ...............................................................41
D
DAS (Direct Attached Storage)..................71
DASD ..........................................................20
Data Mining...............................................128
Data rate.......................................................66
Data Warehouse.........................................128
Disaster recovery ...................16; 17; 162; 189
dischi ottici...................................................89
Distributori.................................................173
DNA (Digital Network Architecture)........105
DoD............................................................105
donatori......................................................204
downsizing...................................................21
DRAM .........................................................48
DVD.............................................................89
E
effetto superparamagnetico..........................67
elaborazione BATCH ..................................19
elaborazioni interattive ................................20
emulazione 3270........................................106
emulazione VT100.....................................106
ERP ( Enterprise Resource Planning)........128
F
facility management.....................................11
Fast Write.....................................................70
Fibre Channel...............................................75
File System ..................................................71
finestra batch................................................24
form factor ...................................................65
Fornitori .....................................................172
G
Gartner Group............................................175
General Purpose.............................................8
gestione documentale.................................101
Glass House .................................................19
GRID computing .........................................25
gruppo elettrogeno.....................................162
H
half pitch ......................................................40
Hard Disk Drive...........................................65
I
I/O bus .........................................................49
249

IBM 360 .......................................................56
IBM 390 .......................................................56
IBM OS/400...............................................116
IDC.............................................................175
informatica “antica” .....................................32
informatica “moderna”.................................32
ISA ...............................................................41
isolanti........................................................203
ITRS.............................................................40
L
laboratori BELL .........................................117
land...............................................................89
Librerie di nastri...........................................83
LINUX .......................................................116
LTO..............................................................84
M
MAC OS ....................................................116
mainframe ....................................................22
Manutenzione software
adeguativa ..............................................144
correttiva ................................................144
evolutiva.................................................144
migliorativa ............................................144
Middleware ................................................122
MIPS ............................................................43
MISS penalty ...............................................49
Moore, Gordon.............................................37
MVS...........................................................116
N
nanotecnologie .............................................40
NAS (Network Attached Storage) ...............73
Nastri, unità a ...............................................79
Non Volatile Storage....................................70
O
on demand....................................................26
Organigramma ...........................................140
OS/390 .......................................................116
OSI (Open System Interconnection)..........106
OTC one time charge .................................133
outsourcing...................................................11
P
PCL (Printer Control Language)................100
PDL (Page Description Language) ............100
periodo di parallelo ........................... 160; 163
Personal Computer.......................................21
pit .................................................................89
porting..........................................................53
Postscript....................................................100
Programmatore ..........................................144
protocolli di comunicazione ......................104
R
RAID............................................................70
read after write.............................................84
registrazione perpendicolare........................68
Requirements .............................................186
di ambiente informatico.........................187
economico-finanziari .............................187
funzionali ...............................................187
imposti ...................................................186
qualitativi e strategici.............................188
scelti.......................................................186
semi-imposti ..........................................186
Requisiti ambientali...................................157
requisiti elettrici.........................................157
Requisiti sugli spazi fisici..........................156
Requisiti sul cablaggio...............................157
Requisiti sulla movimentazione fisica delle
apparecchiature......................................159
Rivenditori .................................................173
RPM.............................................................66
S
SAN (Storage Area Network)......................74
Scalabilità....................................................25
Seek time .....................................................66
semiconduttori ...........................................203
server consolidation.....................................51
settore di sviluppo......................................143
Settore gestione..........................................146
settore sistemi ............................................145
sistema binario.............................................37
sistema operativo
back level...............................................118
livello corrente.......................................119
OPEN.....................................................120
proprietario ............................................120
release ....................................................118
versione..................................................118
sistemi operativi.........................................116
aggiornamento .......................................119
Sistemista...................................................145
Site preparation..........................................156
SNA (Systems Network Architecture) ......105
Software applicativo
a scaffale ................................................125
250

Software applicativo ..................................125
ad hoc .....................................................125
software FREE ...........................................130
software legacy ............................. 24; 43; 126
software OPEN ..........................................117
software OPEN SOURCE..........................130
software PROPRIETARIO ............... 117; 130
SOLARIS...................................................116
Speedup........................................................45
SPOOL.......................................................100
SRAM ..........................................................48
Stallman, Richard.......................................130
stampanti a foglio singolo............................96
stampanti a modulo continuo .......................96
stampanti ad impatto ....................................96
stampanti di gruppo......................................95
stampanti di massa .......................................96
stampanti di qualità ......................................96
stampanti di sistema.....................................95
stampanti non ad impatto .............................96
stampanti utente ...........................................95
Storage consolidation...................................73
suite di prodotti software............................128
system bus....................................................49
T
TCO......................................................... 8; 63
Technology Node.........................................40
Tempo di latenza..........................................66
Time Sharing ...............................................21
Tracce per Inch ............................................66
Transaction Processing Monitor..................20
transistor ......................................................37
tubi sottovuoto .............................................37
U
UNIX .........................................................116
UNIX BSD 4.2...........................................117
UNIX System V.........................................117
UPS............................................................162
V
virtualizzazione dei nastri............................85
VM.............................................................116
VSE............................................................116
W
wafer ............................................................40
WINDOWS................................................116
Z
z/OS ...........................................................116
z/VM..........................................................116
251