Una piattaforma di sviluppo low-code è un ambiente di sviluppo che consente di creare applicazioni web (tipicamente gestionali) riducendo al minimo l’utilizzo di codice di programmazione.

Uno dei vantaggi è quello di permettere a persone senza particolari competenze tecniche di programmazione di contribuire alle fasi iniziali di sviluppo di un’applicazione.

Questo perché elementi grafici e blocchi di codice complessi, trasformati in componenti riutilizzabili, possono essere assemblati e configurati insieme per produrre velocemente applicazioni aziendali anche molto sofisticate.

Cosa avrebbe potuto dire Vilfredo Pareto se avesse visto la nascita delle piattaforme Low-Code?

In questo articolo provo a fare una riflessione su quali sono le caratteristiche che rendono gli ambienti di sviluppo Low-Code degli strumenti interessanti, soprattutto quando vuoi ottenere grandi risultati con sforzi relativamente contenuti.

Tutto è iniziato con una Pianta di Piselli

Tutto è iniziato proprio in Italia, quando Vilfredo Pareto, considerato come una delle personalità più illustri nel campo della sociologia e dell’economia italiana, notò che il 20% delle piante di piselli nel suo giardino generavano l’80% dei baccelli totali.

Non so se questa leggenda ha del vero, ma quello che sicuramente è accaduto è che nel 1897 lo stesso Pareto dimostrò all’Università di Losanna che l’80% dei terreni in Italia era di proprietà di solo il 20% della popolazione e che quindi l’80% della ricchezza italiana apparteneva a un quinto della popolazione complessiva.

Da questa dimostrazione venne poi formulata la cosiddetta “Legge 80/20“, una legge empirica di natura statistica nota anche con il nome di Principio di Pareto (o Principio della Scarsità dei Fattori) che possiamo sintetizzare nella seguente affermazione:

l’80% degli effetti è dovuto al 20% delle cause

Naturalmente i valori 80% e 20% sono stati ottenuti attraverso osservazioni di natura empirica e sono solo indicativi, ma è interessante notare come numerosi fenomeni abbiano una distribuzione statistica in linea con questi valori.

Ad esempio, nel business possiamo affermare che nelle vendite il 20% dei venditori contribuisce all’80% dei profitti mentre nei trasporti l’80% dei ricavi deriva dal 20% di rotte non in perdita.

Nella logistica, il 20% degli articoli a magazzino rappresenta l’80% del valore, mentre nel customer care l’80% dei reclami proviene dal 20% dei clienti.

La “verità universale” del principio di Pareto, anche se non necessariamente rappresentata dal rapporto 80/20, è un principio con cui viviamo quotidianamente: un modello che, consapevoli o no, guida molte delle nostre scelte.

Pensate ai vestiti che avete rispetto a quelli che indossate: quante volte vi mettete la stessa camicia o lo stesso paio di scarpe rispetto a tutto quello che tenete in armadio?

Non stupisce, quindi, come anche nell’ambito dell’informatica questa legge trovi riscontro.

In effetti in sembra che:

• l’80% del tempo di esecuzione di un programma è impiegato solo dal 20% delle istruzioni
• l’80% delle operazioni degli utenti che gli utenti eseguono in una applicazione sono dovute al 20% delle funzioni
• l’80% dei visitatori di un sito web vede solo il 20% delle pagine.

L’utilità della Legge 80/20 nella vita e nel lavoro

Tutte queste informazioni sono estremamente interessanti, ma come possono aiutarci a migliorare la nostra vita e il nostro lavoro?

Per rispondere a questa domanda, partiamo dal dire che uno dei corollari derivanti dal Principio di Pareto è che la maggior parte delle cose nella vita non sono equamente distribuite e che, se non facciamo attenzione, faremo inevitabilmente sempre più attività che richiedono sempre più tempo e che portano a risultati sempre meno rilevanti.

Questo effetto è conosciuto come la legge dei rendimenti decrescenti.

Ecco quindi che il Principio di Pareto può essere visto come uno strumento molto utile per renderci più efficaci e farci risparmiare molto tempo.

Prima di essere frainteso desidero fare una precisazione, ovvero che il principio di Pareto non è una scusa per fare meno: se Michelangelo avesse dipinto l’80% della Cappella Sistina nel 20% del suo tempo e avesse lasciato il resto in bianco, il Papa non sarebbe stato molto contento; dopo tutto, doveva pur sempre consegnare il 100% del suo capolavoro!

Quello che devi tenere a mente è che concentrandosi sugli aspetti e sulle azioni veramente importanti, quelle che danno i maggiori risultati per intenderci, è possibile ottenere dei risultati che da soli valgono la quasi totalità del risultato finale.

Applicare la Legge 80/20 allo sviluppo delle Applicazioni Gestionali

Lavoro nell’ambito dell’information technology da circa 15 anni, prima come consulente informatico e poi come project manager, ho una certa esperienza del lavoro che c’è dietro la costruzione delle applicazioni gestionali.

Per questo motivo, mi chiedo spesso quali siano aspetti su cui è necessario focalizzarsi per massimizzare il risultato.

Qual è quel 20% veramente importante e che da solo sarà in grado di contribuire all’80% del risultato finale?

Com’è facile immaginare, la risposta non è semplicissima e molto dipende dal contesto e dagli utenti.

Partiamo dal dire subito che spesso e volentieri i nostri interlocutori non vorranno, come giusto che sia, rinunciare a nulla.

L’applicazione dovrà essere veloce, intuitiva e facile da utilizzare.

Inoltre, dovrà implementare tutte le funzionalità e gli automatismi ritenuti necessari (inutile dire che dovranno essere tutti quelli espressi).

Tutto sarà indispensabile e con molta probabilità dovrà essere pronto in tempi rapidi.

Insomma, messa così ci si rende subito conto che applicazioni di questo tipo, soprattutto se sviluppate da zero, richiedano uno sforzo non indifferente, rendendo difficile trovare quel 20% su cui focalizzarsi.

Ciononostante, oggi siamo in un momento in cui è possibile investire in soluzioni e tecnologie che possono concretamente aiutarci a rendere questo lavoro un po’ più semplice.

L’adozione delle Applicazioni Gestionali

Le aziende tradizionalmente hanno due modi per acquisire software aziendale: acquistarlo tramite licenza oppure svilupparlo internamente.

Decidere di acquistare un software è sicuramente una scelta che ha dei vantaggi, soprattutto se stiamo parlando di prodotti che ormai sono diventati dei veri e propri standard di mercato (es: Salesforce se parliamo di CRM, SAP, Microsoft Dynamics oppure Oracle per quel che riguarda i classici ERP).

Tuttavia l’idea (o il sogno) che un qualsiasi software, per quanto configurabile, possa essere utilizzato così com’è (spesso si usa l’espressione out of the box), è a mio avviso una chimera.

Di fatto, si tratta di software complessi e nella quasi totalità dei casi sarà necessario avvalersi dei servizi di un system integrator affinché possa essere configurato, personalizzato e adattato alle specifica realtà aziendale, piuttosto che essere integrato con gli altri le altre applicazioni del nostro ecosistema aziendale.

Voglio essere chiaro: non dico che questa strategia sia sbagliata, anzi.

Per definizione queste soluzioni sono state concepite e realizzate per gestire la maggior parte dei processi, pertanto non ti costringono, come dice il detto, a reinventare l’acqua calda.

Tuttavia va tenuto conto del fatto che acquistare un software non vuol dire sempre avere qualcosa di immediatamente pronto all’uso e che in generale i costi potrebbero andare oltre il semplice acquisto di licenze.

D’altro canto, come un abito fatto su misura, un’applicazione aziendale sviluppata internamente deve essere concepita per soddisfare i requisiti aziendali in modo univoco.

In genere, inoltre, la creazione interna richiede più tempo e necessita di avere personale tecnico qualificato che deve essere in grado di gestire i diversi aspetti che stanno dietro lo sviluppo di una applicazione software.

Se il nostro obiettivo è essere veloci, anche in questo caso potremmo trovarci nella situazione di dover rincorrere un sogno.

Lo Sviluppo di Applicazioni Gestionali secondo il paradigma Low-Code

L’avvento e affermazione delle piattaforme low-code ha introdotto, a mio avviso, una nuova possibilità che consente agli sviluppatori (occhio che ho usato la parola sviluppatori) di creare e distribuire applicazioni che risolvono problemi reali e forniscono valore immediato.

Certo, usare la parola sviluppatori potrebbe sembrare azzardata quando si parla di low-code però credo che sia tutto frutto di un enorme malinteso.

A differenza di quello che si potrebbe pensare, per sfruttare appieno le potenzialità delle più famose piattaforme low-code è necessario avvalersi delle capacità di sviluppatori professionisti che abbiano le capacità tecniche necessarie per progettare e sviluppare soluzioni software efficaci, robuste e scalabili.

Ciononostante, il low-code ha un grande vantaggio, ovvero quello di permettere a chi sviluppa di concentrarsi sugli quegli aspetti a vero valore aggiunto che una applicazione aziendale deve avere.

Per utilizzare piattaforme low-code come Oracle APEX, di cui parlo ampiamente in questo blog, non sarà necessario essere esperti in una vasta gamma di tecnologie per fornire soluzioni sofisticate.

Quello che dovrai fare sarà concentrarsi su alcuni aspetti e competenze specifiche e lasciare ad APEX tutto il resto.

Vediamo quindi, quali sono le cose su cui concentrarti per creare applicazioni gestionali usando le piattaforme Low-Code.

Saper definire il Modello Dati

È inutile girarci intorno: il cuore di una qualsiasi sistema gestionale sono i dati e questo vale per qualsiasi tipo di applicazione, dall’e-commerce al magazzino, passando dalla gestione finanziaria, dei prodotti e dei clienti, fino ad arrivare alle soluzioni di business intelligence e all’IoT. 

Tutti queste applicazioni hanno (o dovrebbero avere) un ingrediente comune ed essenziale: il Modello Dati.

Vale la pena ricordare che sto parlando di qualcosa che esiste fin dai primordi dell’informatica e che è il fondamento di un qualsiasi percorso accademico in questo settore (e non solo).

Tuttavia, ci tengo a fare una precisazione: essere in grado di costruire un modello dati non è, o per lo meno non dovrebbe essere, una prerogativa dei programmatori software, tutt’altro.

Non è necessario saper programmare per disegnare un modello dati, tuttavia secondo me non puoi definirti un programmatore software se non sai costruire un modello dati.

I dati devono essere strutturati bene per poter avere senso dare un reale contributo. 

Sicuramente oggi abbiamo a che fare anche con dati non strutturati e semi-strutturati, ma questo per me implica semplicemente che siamo passati a paradigmi più sofisticati di quelli con cui hanno avuto a che fare i nostri predecessori. 

Il Modello Dati dunque rimane e fornisce la base su cui creare applicazioni aziendali estremamente sofisticate. 

Saper costruire la Logica di Business

Le moderne applicazioni web sono basate su un pattern architetturale molto diffuso chiamato MVC (Model View Controller), in grado di separare la logica di presentazione dei dati dalla logica di business.

Il modello dati (il Model, ne abbiamo parlato poco fa), l’interfaccia utente (View) e la logica di business (Controller) sono i tre strati che costituiscono le applicazioni basate su questo pattern.

Cos’è esattamente la logica di business?

Con il termine logica di business si intende l’insieme dei vincoli che regolano la gestione delle informazioni in un database.

Facciamo un esempio pratico: supponiamo di aver sviluppato una applicazione che consente di gestire la spedizione di materiale dal magazzino.

È lecito aspettarsi che ogni volta che viene evaso un ordine di vendita la quantità disponibile in magazzino di quello specifico prodotto venga aggiornata.

Ecco quindi che è necessario implementare, all’interno dell’applicazione stessa, del codice che si occupi di automatizzare questo aggiornamento.

Il non farlo implicherebbe che qualcuno debba aggiornare mano ogni volta la quantità: questo è, come immaginerai, impensabile.

Nei database (DBMS) ci sono già gli strumenti per implementare la logica di business, alcuni in maniera molto semplice, altri utilizzando dei linguaggi di programmazione.

Ecco alcuni esempi:

• Le chiavi primarie possono garantire l’univocità dei codici.
• Il controllo sui campi con la clausola NOT NULL permette di far inserire obbligatoriamente un valore.
• Le viste o query permettono di mettere insieme i dati per generare informazione utile.
• Una stored procedure è un programma in grado di manipolare i dati e che può accettare dei parametri in ingresso e rilasciarne altri in uscita.

Pensando ad Oracle APEX, che si basa sul database Oracle, implementare la logica di business significa in fin dei conti saper programmare in PL-SQL.

Questa è sicuramente una attività a valore aggiunto, che richiede allo sviluppatore capacità di progettazione oltre che di sviluppo.

Saper implementare una Applicazione (sfruttando i componenti low-code standard)

Abbiamo parlando di modello dati e logica di business.

Cosa dire riguardo alla interfaccia utente?

Ebbene, uno dei vantaggi nell’uso dei framework low-code sta proprio nel fatto che sono in grado di accelerare significativamente lo sviluppo del front-end.

Gli ambienti di sviluppo low-code dispongono di un nutrito set di componenti grafici riutilizzabili e all’occorrenza configurabili: lo sforzo richiesto ad una persona non esperta di UX è sicuramente molto ridotto.

In questo blog ho scritto decine di articoli che mostrano come implementare in pochi minuti applicazioni basate su Oracle APEX, che normalmente avrebbero richiesto svariate giornate di sviluppo.

Considerando il fatto che poi queste app nascono già web-responsive è, secondo me, il vantaggio competitivo che le piattaforme low-code offrono agli sviluppatori in termini di time to market non può essere trascurato.

Ecco quindi che creare un MVP (Minimum Viable Product), è qualcosa che assume un significato concreto e tangibile perché ci consente di rendere disponibile una applicazione funzionante e bella in un tempo ridotto.

Ho parlato di MVP, ma cos’è esattamente un MVP?

Nel gergo imprenditoriale, un Minimum Viable Product (MVP) è la versione minima ma funzionale di un prodotto, di un’interfaccia o di un servizio.

Prima di sviluppare un prodotto, spesso si preferisce realizzare un MPV permette di testare rapidamente un’idea: se l’idea risulterà vincente questo ci porterà a continuare ad investire tempo e risorse nella sua realizzazione.

Quella di sviluppare un MPV per testare una idea o un progetto è una strategia che permette di conoscere il proprio obiettivo, in modo rapido e a basso sforzo.

Nell’ambito dello sviluppo delle applicazioni gestionali tramite low-code, il concetto di un MPV si traduce nella possibilità di realizzare con un sforzo ridotto un prodotto software completo e funzionante che può essere utilizzato fin da subito.

Possiamo quindi testare con gli utenti direttamente sul campo l’efficacia della nostra soluzione e riservarci poi il tempo di poterla raffinare ulteriormente.

La mia esperienza con Oracle APEX

Ricordo il giorno in cui ho conosciuto Oracle APEX.

Lavoravo per una società di consulenza informatica su Oracle EBS e avevo a che fare praticamente tutti i giorni con Oracle Forms e OAF.

Un mio collega mi suggerì di provarlo e ricordo ancora come, seguendo un semplice tutorial, fui in grado di trasformare un banale file excel in una applicazione fatta e finita in pochissimi minuti.

Non nascono che rimasi particolarmente colpito.

In pochi minuti ero stato in grado di realizzare qualcosa che mi avrebbe richieste molto più sforzo usando un approccio tradizionale.

Per questo motivo, da quel momento, ho iniziato a studiarlo (le mie conoscenze dei database Oracle e del PL-SQL mi hanno aiutato molto) e tuttora lo utilizzo tantissimo sia per progetti personali che per sviluppare rapidamente applicazioni per gli utenti con i quali lavoro ogni giorno.

Di cosa hai bisogno per creare applicazione gestionali con Oracle APEX?

Poche cose ma che sono sostanziali (anche se c’è da dire che Oracle APEX offre molto di più):

• saper progettare basi di dati
• saper interrogare una base dati con SQL
• saper programmare in PL-SQL.

Ammetto che qualche volta mi permetto di usare qualche riga di JavaScript (anche se non sono assolutamente un esperto) ma, devo dire, è più un sfizio che una reale necessità.

Ovviamente questo non vuol dire che non dobbiamo coltivare, se lo desideriamo, competenze tecniche in ambito UX né, tantomeno, che non servano.

Quello che vorrei dire è che oggi abbiamo a disposizione strumenti e tecnologie che ci consentono davvero di ottenere risultati eccellenti senza dover necessariamente investire troppo tempo e risorse laddove non strettamente necessario.

Magari non saranno perfette in ogni aspetto e necessiteranno di qualche raffinamento, ma non si può dire che non siano una risposta più che soddisfacente al crescente bisogno di digitalizzare i processi di business.

E tu, cosa ne pensi? Fammelo sapere nei commenti.

Un abbraccio

Daniele