In un altro articolo, abbiamo parlato di implementazioni di software e vi abbiamo chiesto se la vostra azienda si affida a soluzioni standard per gli acquisti. Qui stiamo affrontando la domanda: dobbiamo rinunciare alla personalizzazione con soluzioni standard? E: cosa intendiamo per software configurabile?

Software standard: molti termini - un principio

Cominciamo dall'inizio. Decidiamo di comprare una cosiddetta soluzione standard. Che cos'è comunque? Ci sono sicuramente opinioni diverse su questo, così come ci sono termini diversi, come software out-of-the-box o commercial off-the-shelf (COTS). Qui definiamo un software standard principalmente in riferimento al modo in cui il software è sviluppato e mantenuto dal fornitore.

Lo sviluppo di un software standard corre lungo un unico percorso senza diramazioni . Su questo percorso di sviluppo principale - noto anche come trunk - vengono poi create in sequenza le release , che contengono sempre nuove funzioni (note anche come features). In questo modo, la soluzione standard continua ad evolversi nel tempo. Questo assicura anche che una versione precedente del software possa essere facilmente aggiornata a una versione più recente in qualsiasi momento. Questo è indicato come la capacità di rilascio del software, un punto molto critico nella configurabilità, a cui arriveremo in seguito.

La strategia di sviluppo è cruciale

Diversi clienti o utenti del software possono quindi avere lo stesso software standard ma con diversi stati di rilascio. Nel caso del software standard, non ci sono mai versioni parallele che sono nate da una release precedente comune (cioè rami) e che coprono diverse esigenze dei clienti. Per essere precisi: tali versioni parallele non esistono "esternamente", cioè verso il mercato. Internamente, lo sviluppo può avere diversi rami in modo che diversi team possano lavorare su diverse parti del software in parallelo. Questi rami di sviluppo sono poi semplicemente fusi in una release di mercato al momento opportuno. Questo si chiama fusione.

La strategia di sviluppo del fornitore dovrebbe ora essere (almeno secondo noi) di conciliare il più possibile tutte le diverse esigenze dei vari clienti trovando soluzioni generiche. Queste soluzioni ampiamente applicabili possono poi essere configurate in modo specifico per il cliente al fine di tenere comunque conto della situazione specifica del cliente. È qui che incontriamo per la prima volta il termine "configurabile".

Con una tale strategia di sviluppo, si devono naturalmente trovare dei compromessi in certe situazioni, ad esempio implementando deliberatamente solo una delle diverse varianti di soluzione per una stessa esigenza del cliente, che può quindi non essere configurata affatto o solo in misura limitata. In questo caso, il fornitore di software deve accettare che non sarà in grado di soddisfare tutti i clienti per perseguire la sua strategia in modo coerente. Tutti i clienti beneficeranno quindi dei vantaggi. Torneremo su questo punto alla fine di questo articolo.

La configurabilità è nel database, non nel codice sorgente

E ora passiamo al concetto centrale di questo testo: Configurabilità. Altri parlano anche qui di parametrizzazione o termini simili. La configurabilità di una soluzione standard può essere spiegata come segue.

Nel caso di un'applicazione aziendale con una comune architettura a 3 livelli, una tipica installazione software consiste in un application server (middle tier) e un database server (lower tier). L'utente accede al server dell'applicazione tramite un client (upper tier, nel caso di un'applicazione web questo è il browser). Per installazione, le impostazioni(valori di configurazione) possono ora essere memorizzati nel database del sistema, che controllano il comportamento del sistema. Tuttavia, l'application server è basato su una release specifica. Tuttavia, gli utenti notano diverse funzionalità o comportamenti del sistema, a seconda di come il sistema è configurato.

Il punto cruciale è il seguente: i valori di configurazione menzionati sono nel database (al massimo nei file di configurazione nell'application server), ma mai come parte del codice sorgente nell'application server. La configurazione reale non ha quindi nulla a che fare con un ulteriore sviluppo o adattamento del codice sorgente specifico del cliente. Questo comporterebbe una spiacevole ramificazione, che poi metterebbe in pericolo o addirittura renderebbe impossibile la capacità di rilascio. Questo è esattamente ciò che rende l'ulteriore sviluppo costoso per il cliente, poiché tali ulteriori sviluppi devono essere fatti separatamente per ogni cliente e il singolo cliente non può trarre profitto da un ulteriore sviluppo globale per tutti i clienti.

La configurabilità non significa quindi, in particolare, che gli adattamenti si fanno programmando il codice sorgente. L'adattamento del codice sorgente avviene sempre ed esclusivamente attraverso l'ulteriore sviluppo generico delle funzionalità di base del software standard e porta ad una nuova release. Le configurazioni esistenti possono semplicemente essere adottate nella nuova versione. Questa è la capacità di rilascio di sistemi software standard configurabili o già configurati.

Come si riconosce un software configurabile?

Questa domanda non è così facile da rispondere dalla prospettiva esterna, cioè dalla prospettiva del cliente che vuole valutare e comprare tale software. Dal punto di vista interno dello sviluppatore, questo è ovviamente facile. Ma nel processo di vendita, al cliente può essere presentato come "configurabile" un software che in realtà non è affatto configurabile (nel senso definito sopra), che non merita affatto questa etichetta.

Una tale soluzione può essere giustamente chiamata software standard perché è sviluppata lungo un unico percorso di rilascio. Ma non è stato costruito fin dall'inizio con una strategia di sviluppo che implementa le funzionalità in modo generico e le rende adattabili attraverso la configurazione. La "configurabilità" di tali sistemi è poi effettivamente implementata attraverso un ulteriore sviluppo. Naturalmente, questo non viene venduto al cliente in questo modo.

Alcune semplici caratteristiche di un software (veramente) configurabile sono le seguenti:

• Una configurazione specifica per il cliente è efficace dal punto di vista dei costi perché comporta un piccolo sforzo di implementazione per il fornitore.
• La configurazione può essere implementata rapidamente in termini di tempo (con la stessa giustificazione).
• Il sistema rimane sempre pronto per il rilascio, cioè gli aggiornamenti alle versioni future non costano nulla, né soldi né sforzi.

Nel caso di PQFORCE, per esempio, una configurazione del cliente (di tutto il sistema, si badi bene) significa uno sforzo approssimativo da ½ a 2 giorni, a seconda dei desideri specifici e della portata dei dettagli. E quando offriamo una nuova release, può essere facilmente installata per ogni cliente senza alcuno sforzo.

sondaggio/110626]

I vantaggi del software standard configurabile dal cloud

Infine, vorremmo elencare i vantaggi più importanti del software standard configurabile dal cloud rispetto al software individuale. Software come PQFORCE...

• ...è significativamente più economico da procurare. E qui non stiamo parlando di percentuali, ma di fattori. Semplicemente perché nessun progetto di sviluppo costoso deve essere finanziato. E la configurabilità permette anche un adattamento specifico per il cliente a costi estremamente bassi - per tutti quei clienti che non vogliono accontentarsi della soluzione out-of-the-box.
• ...è pronto per l'uso in un tempo molto breve dopo l'acquisto. L'impostazione di un client PQFORCE richiede pochi minuti (sic!), e l'operazione pilota può quindi iniziare immediatamente. Qui, la prontezza dell'organizzazione del cliente è piuttosto il fattore frenante.
• ...rende possibile l'utilizzo di economie di scala. L'ulteriore sviluppo è guidato(crowdsourcing) e finanziato(crowdfunding) da un intero portafoglio clienti.
• ...offre innovazioni regolari (feature release) in cicli brevi di qualche settimana, che possono essere avviate dai clienti e utilizzate immediatamente non appena sono disponibili(principio DevOps).

Quindi non c'è da meravigliarsi che oggi la tendenza si stia chiaramente muovendo nella direzione del software standard basato sul cloud. Se questo è poi anche molto ben configurabile, allora voi come cliente avete tutti i vantaggi dalla vostra parte.