Siamo entrati in una nuova
epoca d'oro del software custom? A guardare alcune evoluzioni dell'IT, parrebbe proprio. Da un lato, tutto sembra poter diventare software-defined. Il che dà una rilevanza sempre maggiore allo sviluppo, anche se inteso in senso lato e non solo di vere e proprie applicazioni monolitiche. Dall'altro, molte aziende sentono la necessità di differenziarsi dalla concorrenza proprio
creando applicazioni e/o servizi digitali su misura. O creandone sempre di nuovi.
Il risultato di tutto questo lo abbiamo già visto. All'IT aziendale - o ai consulenti e fornitori - viene chiesto di
sviluppare di più e più velocemente. Da qui l'importanza di approcci
come DevOps. Ma anche della disponibilità di strumenti che permettando sviluppare in modi nuovi. Ma se DevOps è un tema molto popolare, i tool per lo sviluppo (più) rapido non lo sono altrettanto. La parola magica in questo ambito è
low-code. Un termine creato da Forrester qualche anno fa e che poi è stato esteso (non da Forrester) al concetto di sviluppo
no-code.
In teoria il concetto di low-code o no-code
dovrebbe essere di grande successo. Anche più di DevOps. In fondo, tutti vogliono applicazioni e servizi mentre di skill adeguati allo sviluppo se ne sente sempre la mancanza. Invece è difficile sentir parlare di low-code e no-code fuori dagli ambiti degli addetti ai lavori. Il motivo? L'idea piace ai business manager e anche ai software architect, dicono le analisi di mercato, ma
molto poco agli sviluppatori.
La promessa low-code
Ma cosa promette, in sintesi, l'approccio low-code? In linea di principio, una piattaforma low-code promette di creare la maggior parte di una applicazione
combinando fra loro, attraverso una interfaccia grafica, componenti predefiniti. Resta del codice da scrivere, ma essenzialmente per tre soli scopi. Collegare questa applicazione ad
altre custom che già esistono, ottimizzare l'interfaccia utente, inserire funzioni che non sono previste dalla libreria di partenza. Un tool no-code va
in teoria anche oltre e fa tutto senza richiedere alcuna linea di codice.
Tutto ciò è davvero possibile, secondo i critici, solo se l'applicazione che ne risulta è molto semplice. È una critica che deriva anche dalla
proposizione iniziale degli strumenti low-code. Che sono stati presentati come un modo per permettere agli utenti business di creare applicazioni semplici, senza scomodare lo staff IT. Un approccio di marketing che aveva un senso ma che
ha generato confusione: a chi sono davvero rivolti questi tool, adesso?
Per cercare di risolvere questo equivoco, diversi software vendor usano il termine no-code per indicare le soluzioni
indirizzate agli utenti non tecnici. Questi possono assemblare componenti base per automatizzare alcuni processi di business, magari grazie a funzioni di machine learning che
consigliano cosa fare, e come. La
RPA è ad esempio diventata un campo d'elezione per lo sviluppo no-code. Che quasi non viene nemmeno chiamato sviluppo.
Le piattaforme low-code sono invece destinate ai
professionisti della programmazione. Anche qui lo sviluppo è "componibile", combinando elementi che spaziano dai database ai microservizi, dall'autenticazione alle API. Ma con, si suppone, il supporto per ambienti e componenti enterprise. E soprattutto la possibilità di
intervenire direttamente sul codice generato dalla piattaforma.
Si intuisce come la distinzione tra low-code e no-code sia piuttosto capziosa,
più di comodo che di sostanza. I casi in cui si riesce a costruire qualcosa di articolato senza scrivere davvero nemmeno una riga di codice sono molto pochi. E perlopiù relegati ad ambienti proprietari, non ad applicazioni che definiremmo standard. Quindi, i tool
sono un po' tutti low-code, con gradi diversi di complessità. Il no-code,
afferma ad esempio Forrester, "è un'aspirazione e solo qualche volta una realtà".
A chi piace il low-code, e a chi no
Sui tool low-code
spesso non ci sono mezze misure. O li si considera una grande e positiva rivoluzione, o nemmeno li si considera. Ciò non deriva tanto dalle funzionalità delle singole piattaforme. Le principali sul mercato sono tutte solide, articolate ed anche ben diverse fra loro. Tanto che probabilmente chiunque ne trarrebbe, alla fine, un beneficio concreto.
C'è uno
scetticismo di fondo da superare, per il low-code. Scetticismo che deriva anche dalle promesse non mantenute degli "antenati" (presunti) dei tool low-code. Ossia le piattaforme
CASE (Computer Aided Software Engineering) e quelle
RAD (Rapid Application Development) che andavano di moda soprattutto negli anni Novanta. E che non portarono in fondo grandi risultati: troppo rigide, troppo complesse, poco standard. Non a caso
le stesse critiche che si fanno oggi ai tool low-code.
Per i sostenitori del low-code questo scetticismo nasconde semplicemente una sorta di
machismo da sviluppatori. L'idea che programmare seriamente sia solo macinare codice, mentre assemblare componenti serva a poco e sia per gli sviluppatori di serie B. O, meglio, per i non sviluppatori. E se vogliamo il
complottismo, c'è anche quello. Gli scettici sono accusati di voler mantenere una complessità inutile, ma che fa
gonfiare i budget dei consulenti e in fondo anche dei dipartimenti IT. Se sviluppare è diventato semplice, come giustificare le spese dei mega-progetti IT?
La posizione più pragmatica è che i tool low-code possano trovare spazio in qualsiasi azienda, se sono
gestiti con una certa attenzione. Finché si tratta di piccole applicazioni o servizi che automatizzano processi limitati, di solito non ci sono problemi. Quando si parla di applicazioni articolate e di produzione, le cose cambiano
Il low-code che fa bene
La principale considerazione da fare è di semplice buon senso.
Nessuna applicazione opera da sola, ma dialoga con il resto dell'IT. Per questo chi la sviluppa - con poco o tanto codice - deve
considerare l'ecosistema in cui sarà operativa. E questo approccio non è proprio degli sviluppatori "business" non professionali. Motivo per cui qualsiasi applicazione nata su basi low-code dovrebbe, se cresce oltre un certo limite, essere
supervisionata dall'IT tradizionale.
Un altro elemento di importante distinzione è
quanto "blindate" sono le applicazioni (in senso lato) generate da un tool low-code. In molti casi non è importante solo che un'applicazione svolga una determinata funzione, ma anche sapere in che modo lo fa. E poter intervenire per
cambiare quel modo. E bisogna chiedersi anche quanto le applicazioni generate automaticamente siano "aperte", nel senso di quanto possano operare anche
al di fuori dall'ambiente in cui sono nate. Come un particolare cloud o una specifica piattaforma PaaS.
Sono considerazioni, spiegano gli analisti, che comunque non freneranno lo sviluppo del mondo low-code. I vantaggi ci sono e molte imprese li hanno già riconosciuti. Anche per questa evoluzione, come per molte altre legate alla digitalizzazione, il consiglio è quello di
sperimentare direttamente. Adottare cioè strumenti low-code con cui portare avanti progetti semplici e Proof of Concept. Per capire meglio come sfruttare le potenzialità - che indubbiamente ci sono - delle nuove piattaforme.