CRM, CIM & IP Contact Management Advanced Solutions

L’analisi si sviluppa nell’ambito delle metodologie di progettazione dei S.I.A. (Sistemi Informativi Aziendali), studiando la scalabilità sia in termini tecnologici che di costo. Da un lato si analizzano le relazioni esistenti tra la Capacità Computazionale e la Dimensione Architetturale e dall’altro si misura la Capacità di soddisfare i requisiti Futuri e la Dimensione Futura dell’Architettura, minimizzando il costo cumulativo.

Tradizionalmente la scalabilità è stata approfondita a livello di singolo elaboratore al fine di avere una maggiore capacità computazionale, ed ottenere così le economie di scala teorizzate da Grosch già nel 1959. Negli anni ‘60-‘70 infatti era ritenuto più produttivo eseguire un qualsiasi processo su un solo computer in grado di svolgerlo.

I successivi sviluppi tecnologici (hardware più potente ed economico, architetture Client/Server) hanno indotto Ein-Dor (1985) a rivisitare le teorie di Grosch ed introduttre così nuovi concetti, secondo i quali l’hardware distribuito ha costi minori, la decentralizzazione aumenta la scalabilità e di conseguenza i costi di processo diminuiscono utilizzando l’hardware minimo in grado di svolgerlo.

Operativamente la scalabilità può essere definita introducendo il concetto di misura intensionale e misura estensionale. La prima intende evidenziare la "potenza elaborativa" del sistema, indipendente quindi dal numero di client, di server e dall’architettura software utilizzata. La seconda invece intende evidenziare la parte dimensionale del sistema, funzione diretta del numero di client e server presenti nel sistema, ma indipendente dalla potenza elaborativa degli stessi. Queste due misure vengono analizzate sia in termini assoluti o "dimensione", sia in termini relativi o "scalabilità". In altre parole si utilizzano i Mips per misurare la potenza elaborativa dell’architettura e i Delta Mips per individuare la Spare capacity, mentre si usa il numero Client per avere la misura estensionale dell’architettura e il delta Client per individuare il numero di Client che è possibile aggiungere al server senza modificare l’hardware esistente. Lo studio separato di due aspetti dimensionali è reso necessario dall’analisi empirica condotta con svariati livelli di decentralizzazione. L’aspetto intensionale ed estensionale infatti potrebbero anche coincidere in architetture altamente centralizzate, ma forniscono indicazioni molto differenti in architetture distribuite, dove il Delta Client diventa concettualmente diverso dal Delta Mips.

La scalabilità viene quindi analizzata non su un singolo elaboratore, bensì sull’intera architettura, composta da un singolo server e un numero di Client variabile da un minimo di 25 ad un massimo di 500.

Le analisi empiriche sono state condotte utilizzando un database costituito da 128 elaboratori di recente manifattura provenienti da 21 differenti produttori che sono stati in grado di offrire un range di Mips variante da un minimo di 130 ad un massimo di 10000. Si parla ovviamente di Mips teorici utilizzati per stimare empiricamente la capacità computazione degli elaboratori usando le frequenze di lavoro dei microprocessori espresse in Mhz ed i CPI (Cicli per istruzione) forniti dai vari costruttori.

I dati così raccolti sono stati utilizzati per l’analisi dell’architettura con 200 diversi livelli di decentralizzazione discreti con un carico di lavoro sul client variante da 0,5% a 99,5%. L’intervallo di espandibilità in Delta Mips e Delta Client, è stato calcolato come la capacità a disposizione in termini di MIPS e Numero Client in funzione dei requisiti iniziali (Numero Client e MIPS richiesti) mantenendo costante l’HW.

Attraverso l’elaborazione di milioni di possibili combinazioni tra server, client e i livelli di decentralizzazione sono state effettuate cinque analisi (H1...5), evidenziate in seguito.

H1: Con la prima si è voluto ricercare la relazione esistente tra la scalabilità estensionale e la relativa dimensione. I dati riportati su un grafico hanno mostrato che il numero di Client che è possibile aggiungere ad una architettura è direttamente proporzionale al Numero client presenti, più è grande il numero di client presenti più Client si può aggiungere. Ciò è vero per qualunque livello di decentralizzazione della computazione e derivante dall’esistenza di server molto più potente in architetture di grandi dimensioni.

H2: Con la seconda si è voluto ricercare la relazione esistente tra la scalabilità intensionale e la relativa dimensione. Anche questi dati riportati su un sistema di assi cartesiani hanno mostrato che il Delta MIPS è direttamente proporzionale ai MIPS per bassa decentralizzazione, mentre si ha un inversione di tendenza nel caso di alta decentralizzazione. Ciò è dovuto al fatto che il server ha un ruolo predominante nei sistemi centralizzati ed offre molta potenza, nei sistemi distribuiti invece è il client che svolge un ruolo preponderante, ma ha meno potenza da offrire a fronte di nuove richieste di capacità computazionale dato che rispetto ai server è proporzionalmente meno scalabile.

H3: Con la terza analisi si introducono i costi, in particolare si parla dei costi per aggiungere 1 client e per aggiungere 1 MIPS, ossia di costi marginali, e si constata che questi costi unitari della scalabilità crescono con le dimensioni intensionali / estensionali dell’architettura. Il costo totale dell’hardware diviso per il numero complessivo di utenti o per il numero complessivo dei Mips dell’architettura, dà un’indicazione del costo da sostenere per aggiungere un nuovo utente o un mips. Si definisce intervallo di "crescita incrementale", l’intervallo all’interno del quale l’aggiunta di un client o di un MIPS non comporta sostituzioni HW. In tale intervallo, il costo unitario diminuisce per effetto della maggiore distribuzione del costo del server sul numero totale di client (o Mips), ma al momento di cambiare il server si esce dall’intervallo di crescita incrementale e il maggior costo è tale da creare un andamento correlato positivamente con la dimensione estensionale e intensionale. Nel dettaglio aggiungere 1 Client in una architettura distribuita costa meno, in quanto il client richiede meno risorse al server che lo accetta senza problemi, cosa che per la bassa decentralizzazione non vale in quanto il server diventa facilmente il collo di bottiglia e più spesso la aggiunta di un nuovo client comporta la sostituzione del server per inserirne uno più potente. La curva dei costi ha pendenza maggiore proprio per via dei costi relativamente alti che la sostituzione del server comporta. Considerazione analoghe sono valevoli per quanto riguarda l’aggiunta di 1 MIPS, la bassa decentralizzazione fa spesso cambiare il costoso server per soddisfare la richiesta di maggiore capacità elaborativa, cambio meno frequente (costi inferiori) per l’alta decentralizzazione.

Con le analisi precedenti si è potuto constatare che con la dimensione dell’architettura aumenta sia la scalabilità che i costi unitari collegati e ciò è dovuto al principalmente al cambio del server. Tali costi possono essere ridotti utilizzando due strategia di progettazione: la decentralizzazione della computazione sui client (il server viene sostituito meno) o attraverso un ridimensionamento dell’architettura, utilizzando un sistema multiplo di cooperazione tra i server. Nel primo caso la soluzione di decentralizzazione crea un vantaggio economico dovuto al minore costo dell’HW distribuito (server + piccoli e meno costosi H3) ed una maggiore scalabilità in termini assoluti. A lungo andare la forte decentralizzazione tenderebbe a rendere la potenza elaborativa del client una variabile critica che a fronte di una nuova richiesta di MIPS implica la sostituzione di tutti i client presenti nell’architettura vanificando tutti i vantaggi di costo precedentemente ottenuti. Nel secondo caso si analizza la soluzione di ridimensionamento del server. Se si vuole avere vantaggi di costo è possibile utilizzare più server in cooperazione che costano meno di un server unico ma hanno anche una scalabilità inferiore.

Se l’obiettivo è di risparmiare sui costi, dato che non si prevede una espansione dell’architettura tutto va bene, ma se ci sarà in futuro un bisogno di espansione si è costretti a sostituire il server, perdendo tutti i vantaggi economici precedentemente ottenuti.

In conclusione, se la crescita è prevista limitata nel tempo, le considerazioni sui costi vengono privilegiate e passano in secondo piano quelle relative alla scalabilità, ma se la crescita si prevede estensiva, i costi cumulativi saranno diminuiti nel lungo termine se è massimizzata la scalabilità mantenendo grosse le dimensioni intensionale ed estensionali.