DevOps Unbound: DevOps per Low-Code - Amico o nemico?

Trascrizione di DevOps Unbound

Lo sviluppo low-code è diventato sempre più popolare dall'inizio della pandemia di COVID-19 nel 2020. Le tecnologie low-code permettono alle organizzazioni di costruire e personalizzare applicazioni reattive e facili da distribuire con poca o nessuna riga di codice. Queste tecnologie accelerano la trasformazione digitale e danno potere ai citizen developer.
Quella che segue è la trascrizione di un episodio di DevOps Unbound, i padroni di casa Alan Shimel e Mitch Ashley sono affiancati da Derya Sousa (Kianda), Andrew Manby (HCL) e Brian ven den Blink (Valori) per discutere i benefici del low code e come sta trasformando lo sviluppo del software. Il video si trova nel link all’articolo originale.

Alan Shimel: Ehi, gente, benvenuti in un nuovo episodio di DevOps Unbound. DevOps Unbound è un appuntamento bisettimanale su tutto quello che riguarda il tema DevOps, senza restrizioni - da qui il nome, DevOps Unbound. È sponsorizzato dai nostri buoni amici di Tricentis, ai quali rivolgiamo i ringraziamenti.

Per quelli di voi che stanno vedendo DevOps Unbound per la prima volta, oltre alle nostre sessioni bisettimanali come questa, che sono preregistrate, facciamo anche una tavola rotonda mensile dal vivo aperta al pubblico, anche voi quindi avete la possibilità di essere tra gli ospiti della tavola rotonda dove potete fare domande e/o guidare voi stessi la discussione. Quindi, se andando su DevOpsUnbound.com o controllate su Digital Anarchist, TechStrongGroup.com, o DevOps.com, sarete in grado di vedere il programma e forse partecipare a una delle nostre tavole rotonde dal vivo.

Oggi, però, è uno dei nostri appuntamenti preregistrati. Il nostro argomento di oggi è il low code/no code e molti dei suoi aspetti e particolarità, se vi interessa.

Ma prima di entrare nel merito, voglio presentarvi il nostro panel di oggi. Lasciate che vi presenti prima Brian ven den Blink. Brian, benvenuto a DevOps Unbound.

Brian ven den Blink: Grazie, Alan. Sì, sono Brian, lavoro per Valori, è una società in Olanda. La nostra attività è incentrata completamente sul testing, quindi non abbiamo sviluppatori,ci occupiamo solo di test, ci ho lavorato per circa otto anni. Ho iniziato, in realtà, come tester di test automation, eccetera, ma poi ho anche notato negli incarichi che ho svolto che era anche importante imparare qualcosa sui requisiti, come prepararli per essere testati.

Così, mi sono focalizzato anche alcuni anni sull'analisi del business per andare avanti e sapere di cosa ho bisogno per i test, fino a, credo, circa cinque anni fa quando sono entrato in contatto con OutSystems, e occupandomi ora di soluzioni di test specificamente per la piattaforma OutSystems e vedendo come si può utilizzare una piattaforma low-code a proprio vantaggio come tester.
E sì, mi ha davvero offerto numerose opportunità, non solo per me ma anche per i tester.

Alan Shimel: Eccellente, e grazie mille, Brian. Poi, lasciate che vi presenti Derya Sousa.

Derya Sousa: È fantastico essere qui in questo panel oggi. Grazie mille per avermi invitato, prima di tutto. Allora, sono Derya Sousa, sono il co-fondatore e COO di una società chiamata Kianda Technologies, con sede in Irlanda, che aiuta le aziende in tutto il mondo. Kianda è una piattaforma di sviluppo di applicazioni no code/low code, e siamo degli abilitatori/acceleratori della trasformazione digitale per le aziende.

Il mio background è nell'IT. Ho lavorato come consulente IT sviluppatore in diverse aziende, industrie durante la mia carriera, e mi sono imbattuto nel fatto di quanto sia difficile fornire soluzioni digitali per le aziende. È così che è nata l'idea di Kianda a metà 2016, con la visione di aiutare le persone indipendentemente dalle loro competenze tecniche a creare la tecnologia di cui hanno bisogno.

Alan Shimel: Ok, grazie. Grazie per quello che state facendo e grazie per esservi uniti a noi oggi. Il nostro prossimo membro del panel è Andrew, scusatemi, è Andrew Manby, giusto? Andrew, ti dispiacerebbe presentarti?

Andrew Manby: Certo. Il mio nome è Andrew Manby. Sono a capo della gestione dei prodotti per il nostro portafoglio di soluzioni digitali qui a HCL Software. Nel nostro portafoglio, abbiamo sia piattaforme professionali low-code per sviluppatori che piattaforme a low-code per citizen developer.

Sono stato coinvolto in diversi prodotti software di successo. Alcuni di questi forse li conoscete, un prodotto chiamato DataStage, che abbiamo creato in una precedente società che davvero, insieme a Informatica, ha acceso l'immaginazione del mercato dell'integrazione dei dati e sono stato coinvolto anche in altri spazi di mercato, tra cui portare la leadership di pensiero in IBM attraverso i big data analytics.

Alan Shimel: Eccellente. E poi, ultimo ma non meno importante, Oltre ad essere un membro del panel è anche il mio co-ospite per DevOps Unbound, è CTO di TechStrong Group  e Research Principal e Co-fondatore TechStrong, Mitchell Ashley. Ehi, Mitch, come stai?

Mitch Ashley: Ehi, Alan, è sempre bello fare parte di un panel insieme, per le persone del panel che conosco, è bello rivedervi, per chi invece incontro per la prima volta, come il nostro pubblico, è bello avervi tutti qui. So che ci aspetta una discussione interessante.

Alan Shimel: Assolutamente. Grazie. Allora, ragazzi e ragazze, lasciatemi iniziare. Come stavo dicendo prima di andare in diretta, io vedo  quasi come spartiacque nel discorso low/no code la diffusione del COVID, siete d'accordo? Proprio come Avanti Cristo/ Dopo Cristo, abbiamo PRIMA del COVID e poi DOPO il COVID. Penso - e Derya, tu ne sei la prova vivente. Il low code/no code era vivo e vegeto prima di COVID, giusto?

Hai iniziato nel 2016. Il low code/no code esiste, ovviamente, da molto più tempo, ma certamente, prima dell'inizio del COVID e della pandemia, non abbiamo mai sentito la necessità di fare di più, più velocemente, di far uscire più app, di espandere la base di persone che possono sviluppare come abbiamo fatto in questi ultimi quasi due anni. E così, abbiamo visto una sorta di rapido sviluppo nello stato di low code/no code.

E Derya, non voglio prendermela con te, ma ti chiedo di dirci la tua sul’argomento. Devo presumere che questo è ciò che hai vissuto nella tua azienda in particolare nell'ultimo anno e mezzo o due anni.

Derya Sousa: Penso che per iniziare, potrei dirvi che quando abbiamo fondato Kianda, quando dicevamo piattaforma low code/no code, il nostro pubblico diceva: "Cosa intendi?". Ora, siamo arrivati ad una fase in cui chiunque parli con noi sa di cosa parliamo, la maggior parte delle persone con cui stiamo parlando, capisce cosa facciamo grazie a questa tendenza e del movimento che si sta verificando, dovuto allo sfortunato evento della pandemia. Ma il low/no code è sempre esistito. È iniziato molto, molto tempo fa. Sapete, usavamo fogli Excel, usavamo Access, usavamo WordPress allora per creare il nostro sito web. Quindi, queste sono, credo, le soluzioni iniziali da cui siamo partiti.

Ma si è arrivati a una fase in cui il lavoro da casa e le crescenti esigenze di digitalizzazione riguardano sempre più imprese e organizzazioni. È quello che stiamo vedendo, questo è un problema che non è un problema nuovo. Attualmente, solo lo 0,5% della popolazione lavorativa è in grado di programmare.

Quindi, quello che succedeva prima era che gli utenti aziendali, chiunque lavori nelle organizzazioni, avevano bisogno di soluzioni tecniche, e rimanevano sempre in attesa che i team IT sviluppassero questi sistemi per loro. Ora è diverso, c'è più inclusività nella creazione di tecnologie, viene dato molto più potere alle persone, indipendentemente dal fatto che sappiano come programmare o meno. Si sta aprendo un incredibile mondo di opportunità per le persone che non erano in grado di farne parte, essere parte attiva della trasformazione digitale, ora stanno nascendo quelli che noi chiamiamo citizen developer. E naturalmente, viviamo in un mondo digital first ora con tutto quello che sta succedendo intorno a noi. Qualsiasi azienda che non cerca di trarre vantaggio da queste tecnologie che sono lo sviluppo rapido di applicazioni rimarrà, purtroppo, indietro quando si tratta di vantaggi competitivi e di migliorare o creare quel valore economico per le organizzazioni.

Alan Shimel: sono d'accordo. Gente del panel - altre riflessioni sull’argomento?

Andrew Manby: Sì, ho alcune idee. Come Mitch ed io abbiamo discusso un paio di volte, per me, il low code o una sorta di no code è esistito per un lungo periodo di tempo. Infatti, mio suocero programmava in dBase, sapete, molti anni fa, giusto? [Risate]

Alan Shimel: Questo è un altro nome che non sento da un po'.

Andrew Manby: Sì, ok, mettiamo Delphi, FoxPro, tutte queste cose sul tavolo. Facciamolo.

Mitch Ashley: Penso di aver incontrato tuo suocero, quindi.

Andrew Manby: [Risate] Sì. Quindi, tutte queste piattaforme sono sempre esistite, giusto? E se la tecnologia ci ha insegnato qualcosa è che si evolvono per servire un bisogno particolare e questo perché il business stava cercando di ottenere un risultato particolare, giusto? Quindi, hanno costruito qualcosa, l'hanno effettivamente implementato.

Ora, quello che è successo è che abbiamo molte più persone esperte di tecnologia nella forza lavoro e nel'IT sta prendendo un po' più di un approccio proattivo. Vogliono un po' più di governance, vogliono un po' più di standardizzazione, vogliono anche essere sicuri della sicurezza e della governance di ciò che il business compra, e penso che questa generazione di strumenti low-code e anche no-code ci aiutino molto.

Alan Shimel:  Assolutamente.

Andrew Manby: - ci aiutano a farlo. E così, non credo che sia una novità. Sai, quello che è interessante - e spero che ci arriveremo, Alan - è il tipo di cose che stiamo vedendo che le persone stanno costruendo con questi prodotti individuali.

Quindi, penso che sia sempre stato lì prima. Penso che un sacco di organizzazioni come, per esempio, una grande compagnia aerea in cui ci sono un paio di centinaia di persone che sono utenti aziendali che costruiscono applicazioni su di essa, giusto? Ma tipicamente, molte di queste applicazioni sono rivolte ai dipendenti, e riempiono il vuoto tra alcune di quelle tradizionali applicazioni aziendali o forse ad alcune di quelle franchigie SaaS di cui sentiamo spesso parlare ora per ottenere il lavoro fatto, giusto? Quindi, penso che fosse vivo e vegeto prima, e penso che stia continuando.

Alan Shimel: Assolutamente, sta continuando, ma penso che stia cambiando. E Brian, penso che tu possa essere un esempio da seguire.

Brian ven den Blink: Penso che, in realtà, se si guarda a qualche anno fa, forse quattro o cinque, un sacco di aziende stavano forse iniziando a lavorare con, per esempio, i sistemi sanitari con piattaforme low-code, usandole come piccole applicazioni, fondamentalmente, nella loro organizzazione.

Per esempio, registrando le ore di lavoro e poi iniziando a crescere, pensavano: “hey, possiamo davvero arrivare a un prodotto davvero veloce, e poi altri dipartimenti dell'organizzazione vedono”, “hey, hanno realizzato un'app in pochi mesi, ed è interessante forse espandersi su di essa”. E poi si vede, tipo, un centro di eccellenza all'interno di un'azienda iniziare a costruire app, e poi si ingrandisce, e ora, penso, attualmente sempre più organizzazioni usano effettivamente il low-code anche per le loro applicazioni principali. Così, in realtà, i processi più importanti sono anche fatti con low-code al giorno d'oggi, e la tendenza sta crescendo così, perché vedono i benefici, credo. È quando vedo...

Alan Shimel: Beh, perché non dovrebbero?

Brian ven den Blink: - Sì. E quello che vedo anche nel mio lavoro è che, se si lavora in un ambiente ad “high code”, potrebbe essere difficile per un tester o per un analista aziendale dire: "Ehi, è così che funziona" e immergersi nel prodotto e nel codice, allora hai bisogno di competenze tecniche. Ma penso che con il low-code, è più facile, per esempio, per un tester dire, "E' davvero questo che volevamo dire con questo pezzo di software?" e si può davvero avviare il dialogo con il vostro sviluppatore, anche con il vostro product owner, per esempio, per vedere, sta davvero facendo quello che vogliamo che faccia, e come possiamo migliorarlo, per esempio? E questo è molto più facile in un ambiente low-code, credo, che in un ambiente tradizionale.

Mitch Ashley: Sai, Alan, ci sono alcune strategie accelerate, ora TechStrong Research ha fatto alcune ricerche all'inizio di quest'anno sul low/no code e sono emerse alcune tendenze interessanti. E penso che parte di essa sia stata guidata dal Covid, Derya stava parlando dell'effetto della pandemia; anche tu. Questo ha portato il software alla ribalta in termini di capacità indispensabili per la strategia aziendale. E insieme a questo, una sorta di low code/no code è stato visto dall'IT come qualcosa che è accaduto al di fuori dell'IT, non ci interessa davvero, le business unit stanno facendo qualcosa, qualunque cosa, per diventare una piattaforma mainstream.

E non sto dicendo che non lo fosse prima, ma penso che l'abbracciare il low code/no code come strategia,sia un fenomeno in crescita iniziato negli ultimi 18 mesi, e si può anche dimostrare dalla necessità di accedere ai dati, di quali informazioni la gente ha bisogno, perché nessuna applicazione è veramente un'isola. Alla fine devono ottenere la sicurezza, alla fine devono arrivare ai dati e ad altri sistemi e il fatto che, Andrew, tu parli di citizen developer come legittimi creatori di applicazioni.

Stai vedendo anche tu questa tendenza? Questo è certamente emerso dalla nostra ricerca.

Andrew Manby: Sì, abbiamo una nostra indagine che uscirà a breve e che abbiamo fatto con Forrester. Sai, abbiamo scoperto che, dal punto di vista del processo decisionale aziendale per le persone intervistate, l'80% di loro ha detto che il low-code era una delle prime tre priorità IT per l'organizzazione, giusto?

Mitch Ashley: Mm-hmm.

Andrew Manby: Sai, il 77% degli intervistati ha effettivamente detto che, l'agilità e la velocità erano le due cose più importanti per il loro business nel raggiungere questo obiettivo.

Quindi sì, penso che le aziende se ne stiano rendendo conto. Penso che ci siano un paio di altri fenomeni diversi, e penso, Mitch, io e te ne abbiamo parlato in un’altra occasione. Penso che ci siano alcune cose cresciute organicamente di cui parlava Brian, cioè si fornisce uno strumento di sviluppo al comune cittadino, si stabilisce un centro di eccellenza, giusto, e poi si inizia a drenare il desiderio dell'organizzazione di riempire il vuoto con la costruzione di queste applicazioni.

Ma penso che ci sia anche - e forse ne hai parlato, Brian -  il fatto che le organizzazioni stanno prendendo anche un approccio di tipo top down, giusto? E stanno dicendo, quali sono i punti di contatto digitali importanti che ho nella mia organizzazione? inoltre, dato l'avvento del COVID, di cosa ho bisogno per essere in grado di colmare il divario o continuare il mio business? Quindi, se sono un rivenditore, nella prima parte del COVID, una delle maggiori sfide che ho avuto è stata: come gestisco il commercio senza contatto? Come faccio a prendere le consegne e a permettere al mio reparto di vendita al dettaglio di funzionare, giusto?

O diciamo, per esempio, che sono un ufficio delle tasse, giusto, e all'improvviso, il periodo delle tasse, non ci sono persone nell'ufficio, e quello che vogliamo che la gente faccia è iniziare a presentare una richiesta di sospensione per ritardare la consegna delle tasse: come fare? Oppure, le famiglie cercano un supporto speciale, un supporto per i servizi sociali. Così, questi tipi di cose sono diventati improvvisamente molto, molto importanti e il low-code, sia che sia stato costruito dall'organizzazione IT o che sia stato costruito dal business ha davvero aiutato a riempire il vuoto. A volte, ci sono state cose nuove di zecca, e a volte si tratta solo di adattare il business alla nuova realtà.

Alan Shimel: Assolutamente. Lasciatemi intervenire. Sapete, penso che prima della pandemia, c'è una lunga storia di low-code, come Andrew ha sottolineato, anche se potrebbe non essere stato chiamato low-code allora. Ma prima della pandemia, il low code/no code era in giro, ma molte persone lo vedevano come un facilitatore di compiti. È semplice come un foglio di calcolo.

E poi penso che quello che abbiamo visto con la pandemia è, a parer mio, abbiamo visto tre rami di low/no code, e penso, Andrew e Mitchell, entrambi lo avete menzionato. Uno è il no code, e devo essere davvero onesto con voi: ho un problema con questo. Ho lo stesso problema con il no code che ho con il no ops. Penso che sia puro marketing, e non so cosa si possa fare veramente, veramente senza scrivere codice. E possiamo parlarne, sentitevi liberi di andare avanti.

Andrew Manby: Sto solo pensando al tuo foglio di calcolo Excel, giusto?

Alan Shimel: Uh huh.

Andrew Manby: Sai, Excel non è codice finché non digiti quella formula.

Alan Shimel: Giusto, e poi all'improvviso, è meglio che tu lo prenda da me, sono analfabeta sulle formule di Excel, quindi so che c'è del codice lì.

Mitch Ashley: Perché hai messo un'espressione, ora stai codificando, giusto?

Andrew Manby: Sì, esattamente. [Risate]

Alan Shimel: Ma quando guardiamo al low-code, ecco il grande risultato del COVID per me è che abbiamo low-code per i team di sviluppatori e Brian, includerò i tester, perché i tester stavano già scrivendo script e facendo un po' di codice per scrivere i loro test.

Quindi, abbiamo il low-code per i team di sviluppo - team DevOps, o come volete chiamarli, sviluppatori - e poi abbiamo un low-code per il citizen developer, tra virgolette. Queste sono persone che tradizionalmente non facevano alcuno sviluppo, a parte forse i fogli di calcolo. E, sapete, ecco che l'analista aziendale, la persona nelle vendite o nel marketing o nelle risorse umane, ora hanno la capacità di non dover aspettare o passare attraverso l'intero processo IT guidato dalla formula, ma potrebbero usare un po' di vernice con i numeri e costruire relativamente facilmente un'applicazione molto funzionale. Non equiparare il citizen developer con una semplice applicazione. Ci sono alcune cose sofisticate che si possono fare ora.

Brian ven den Blink: Alan, volevo dire su questo che, effettivamente, i citizen developer, ma anche i team di sviluppo IT  lavorano con il low-code.

Alan Shimel: Sì.

Brian ven den Blink: Ma quello che vedo è che sempre più aziende scelgono il low code per ristrutturare fondamentalmente le loro applicazioni legacy, ricostruirle o ripensare il loro software. E penso che sia davvero cruciale avere ancora - forse si può lavorare con i citizen developer come parte del IT, ok, quali sono i requisiti di business di cui abbiamo bisogno e come lo implementeremo, ecc. Ma è super importante, penso, avere ancora le tue capacità di sviluppo alla pari con ciò di cui hai bisogno. Perché anche con il low code, forse è più facile fare qualcosa, ma hai ancora bisogno dello stesso tipo di abilità che avrebbe lo sviluppatore per sapere come strutturo le cose, sai, come imposto la mia architettura intorno ad esso. Questo tipo di cose sono ancora abilità di sviluppo, forse senza codifica, ma sono ancora abilità di sviluppo, penso.

Ed è per questo che penso che tu abbia sempre bisogno di uno sviluppatore senior, o quello che è, nel tuo team per essere in grado di gestire questo tipo di domande e poi supportato, penso, naturalmente, da sviluppatori junior o citizen, anche, ma le competenze di sviluppo che ti servono per costruire un'applicazione sono ancora molto necessarie, penso.

Alan Shimel: Sono d'accordo. Derya, sembra che tu voglia...

Derya Sousa: Vorrei aggiungere qualcosa, un punto a quello che hai detto, Alan, alle tue definizioni. Ci sono soluzioni  low/no-code sul mercato che generano codice per uno sviluppatore per andare a velocizzare questo processo di consegna e fare le modifiche che gli vengono chieste.

Alan Shimel: Sì.

Derya Sousa: Ci sono soluzioni come quella che forniamo noi. Non generiamo codice, quindi ci definiamo una vera piattaforma no code. Tuttavia, permettiamo agli sviluppatori di entrare e creare widget, creare regole e azioni che possono aiutarli a portare in vita l'applicazione di business end to end. E penso che questo sia importante, perché c'è una buona differenziazione tra loro, e dalla nostra esperienza, lavoriamo con i team IT così come con i dipartimenti di business.

Alan Shimel: Sì.

Derya Sousa: Ma iniziamo con i dipartimenti IT, perché hanno visto i benefici che possono ottenere-

Alan Shimel: La forza, il potere.

Derya Sousa: - usando una piattaforma come questa - esattamente, colmando le lacune che potrebbero avere. E ora, anche dopo la pandemia, stiamo parlando con più enti pubblici, gli ospedali per esempio o le le agenzie governative. Anche loro tendono ad essere più lenti a mettersi al passo con l'innovazione e le tecnologie. Anche loro stanno guardando ai sistemi a low-code/no-code, come sostituti per i loro sistemi legacy, che hanno usato forse per due decenni, ma non hanno idea di come, in realtà, potrebbero portare un'interfaccia user-friendly sopra questi sistemi.

Quindi, è qui che, penso, soluzioni come lo sviluppo rapido di applicazioni entrano in gioco e portano un sacco di vantaggi alle organizzazioni.

Andrew Manby: Sì, sono d'accordo che certamente alcuni di quelli che pensi siano una sorta di tradizionali ritardatari nella curva di adozione, lo stanno certamente facendo. Lo abbiamo visto nel governo statale, lo abbiamo visto nelle grandi autorità fiscali. L'abbiamo visto anche nel registro automobilistico del distretto di Columbia. Ma penso anche che le organizzazioni e molte aziende vogliono passare attraverso un'ulteriore trasformazione digitale, giusto? So che tutti abbiamo sentito questo termine, ma hanno davvero impostato un piano per un certo numero di anni per pensare a come potrebbero non solo sostituire alcune delle eredità, ma davvero pensare di spostare il focus su cosa significa digitalizzare i processi che effettivamente fanno.

Quindi, penso che alcune organizzazioni, non stiano solo pensando - “ok, come posso mettere un nuovo front end su un sistema esistente?”. Molti di loro stiano pensando come spostare i dati. Così, nel caso della D.C. DMV, per esempio, loro dicono: "Non voglio che la gente vada in un registro automobilistico per registrare il proprio veicolo, giusto? Non voglio che vadano in un ufficio pubblico per pagare una multa per divieto di sosta o una multa per eccesso di velocità - e se cambiassimo semplicemente i nostri processi e li mettessimo su una di queste cose, giusto?

Quindi, penso che molte organizzazioni là fuori stiano effettivamente pensando al low code in questo modo, e penso che sia qui che la conversazione si sposta dall'essere un IT e un abilitatore all'essere anche, il CMO, il COO ha un posto al tavolo e sta dicendo, "Guarda, come possiamo migliorare l'impegno con i nostri clienti dove i nostri modi tradizionali di impegno con loro sono cambiati significativamente?" E vedo probabilmente la stessa quantità di aziende che vengono da noi e dicono: "Vorrei fare questo", giusto? Sapete, "Voglio cambiare il modo in cui le persone comprano i pneumatici per le loro auto", giusto?

Mitch Ashley: Sai, pensando a questo, sembra che a volte i termini che creiamo non sempre facciano al caso nostro, giusto?

Andrew Manby: Giusto, giusto.

Mitch Ashley: E, sai, la programmazione visiva è ciò che avremmo chiamato low code forse 5 o 10 anni fa e sai, una macro è low code o no code? E in realtà, non mi interessa molto, è una macro, è proprio come Python è un linguaggio di scripting o un linguaggio di programmazione? Non mi interessa davvero. In un certo senso non importa. Penso che il risultato finale sia, sai, hai parlato di Derya, lo sviluppo rapido di applicazioni, e non intendo il termine RAD, ma creare applicazioni rapidamente ed espandere l'universo di persone che possono farlo in tutto il business è tutto buono. Voglio dire, è a beneficio, alla fine del business. E possiamo creare un casino per noi stessi, o possiamo farlo bene, in modo che funzioni insieme.

Ma penso che, se tutto va bene, arriveremo ad un punto in un anno o due in cui non penseremo al low-code/no-code, giusto, sarà  solo un altro modo di..., è una piattaforma applicativa per creare applicazioni. E chiunque può farlo, non mi interessa se Trello è un no code o un low code. Non mi interessa se Zapier è un no code o un no code, sapete, solo per scegliere alcune cose comunemente usate. Penso che siamo sul risultato che vogliamo ottenere.

Andrew Manby: Sì, sono d'accordo, Mitch. Voglio dire, penso che alla fine della fiera la tecnologia funziona per cicli. Sai, certamente, nel nostro portafoglio, abbiamo low code che venderemmo a un cliente per fare quel compito specifico, giusto, e questi sono casi d'uso più ampi.

Ma, sapete, il low/no-code esiste nella nostra piattaforma di esperienza digitale ed esiste anche in alcune tecnologie che abbiamo specificamente per il processo DevOps, che è una versione low-code per aiutare ad orchestrare ciò che fanno nel processo DevOps. E pensi a te stesso - beh, sono uno strumento commerciale a low-code? Beh, no, ma stanno portando il, sancendo il valore di uno strumento no code/low code ad una sfida specifica.

Sapete, forse questo sarà il modo in cui questo mercato si evolverà nel tempo, ma sicuramente, direi che dove siamo ora è, si sta permeando in un sacco di posti diversi, giusto? Sapete, questo significa che, diciamo, Monday è uno strumento no-code? Ma probabilmente ciò che lo rende più attraente è il fatto che ha alcune capacità di tipo no code, giusto? E forse questo va bene, giusto, per personalizzare certi tipi di applicazioni.

Mitch Ashley: Beh, si avventura nell'intero spazio del flusso di lavoro, giusto? Voglio dire Atlassian ora si sta posizionando come un concorrente di Monday e altri come strumento di flusso di lavoro, e si potrebbe dire che anche questo è low-code o no-code. Quindi, è davvero, quando parliamo di questo come un segmento del mercato, è davvero molto più grande di quello che potremmo definire strettamente come low-code.

Alan Shimel: Sì. Quindi, per me, la definizione torna a qualcosa di cui Brian stava parlando prima, e cioè - qual è il coinvolgimento dell'IT, giusto? Anche con questa cosa del citizen developer, la vedo biforcarsi. Ci sono alcuni casi in cui i team IT tradizionali stanno chiamando una persona IT non tradizionale per aiutare con la costruzione, l'architettura, il dimensionamento di un'applicazione. E questa persona IT non tradizionale beneficia del fatto che il team sta usando strumenti a low-code/no codice, giusto? Quindi, questo è uno scenario con il coinvolgimento del dipartimento IT.

Poi c'è una sorta di operazione ombra di sviluppo low code/no code senza IT, giusto? Dove - ehi, amico, ci vuole troppo tempo, non voglio passare attraverso l'intero processo di gestione del cambiamento e l'architettura, ho solo bisogno di questo velocemente. E ho lo strumento per farlo ed è economico ed è SaaS ed è boom, boom, boom e ho finito. "Ehi, da dove viene?" "Eh, l'ho costruito io". "L'hai costruito tu?" "Sì, l'ho costruito io". Giusto? E questo è potente. Non voglio... non prendiamoci in giro. Questo è un potente abilitatore in un'organizzazione quando la persona IT dice, "Ehi, aspetta un secondo, dove l'hai preso?" "L'ho costruito io". Giusto?

Come si conciliano le due cose? E penso che sia davvero dove l'attrito, dove la gomma incontra la strada, e cosa è low-code, cosa è no-code, chi lo fa? Penso che la delimitazione sia: l'IT è coinvolto o no? E, sai, Derya, stavi dicendo che la maggior parte dei tuoi impegni passano attraverso il dipartimento IT. Brian, anche tu sembri essere sul lato del dipartimento IT coinvolto. Andrew, ti ho sentito andare un po' in entrambe le direzioni. Ma, per me, questo è il tipo di indicatore chiave.

Andrew Manby: Bene, e Alan, posso farti una domanda, allora, giusto?

Alan Shimel: Certo.

Andrew Manby:Sai, tendo a pensare che il low code per gli citizen developer sia un po' come una sandbox, giusto? Sapete, io vivo - dove vivo io, c'è uno zoo a un miglio di distanza, giusto, e c'è un'area lì e un parco giochi per bambini, c'è una tenda e c'è una sandbox sotto di essa, giusto? E questo rende molto facile per la famiglia sedersi e osservare i propri figli, giusto?

Quindi, sapete, penso che il modo in cui il no code si sta sviluppando da una prospettiva IT, è fiducia ma verifica. Posso vedere cosa stanno facendo? Se si mettono nei guai, posso aiutarli, o come ha detto Derya, sai, se c'è qualcosa di cui hanno bisogno, giusto, forse hanno bisogno di un widget specifico per fare un pagamento o hanno bisogno di qualcosa per consegnare un pacchetto o hanno bisogno di qualche tipo molto specifico di problema matematico e costruiscono un algoritmo nel laboratorio di matematica e vogliono portarlo qui, è allora che l'IT fa questo, ma anche, di nuovo, è quella supervisione e governance, giusto? Fidati ma verifica, ma sai, chi sta usando l'applicazione? A quali dati hanno accesso? Stanno facendo la Select Star dagli stipendi dei dirigenti delle risorse umane, giusto? Qualcuno sta curando quelle fonti di dati per loro in modo che non possano fare danni nei loro sviluppi?

Quindi, penso che questo sia il luogo in cui lo sviluppo dei citizen sta andando. Penso che sia dove le organizzazioni vogliono investire, è dove metteranno i COE. Penso che i giorni in cui, per esempio, mio suocero costruiva qualcosa in dBase scompariranno dal punto di vista dell'IT.

Alan Shimel: Quindi, lasciami usare la tua analogia della sandbox. Ti propongo la proposta che la maggior parte dei genitori, molte mamme, portano i loro bambini nella sabbiera e li lasciano lì perché è un ambiente relativamente sicuro e possono concentrarsi su altre cose, magari facendo un po' del loro lavoro o parlando con le altre mamme o quello che vuoi, e lo considerano un ambiente sicuro per lasciare i loro bambini, e li tengono d'occhio solo a metà rispetto a, sai, essere sull'altalena o altro. La stessa cosa, qui.

Andrew Manby: Esattamente, Alan. Quindi, penso, per me, hai colto nel segno, giusto? Se si tratta di backlog IT, hai effettivamente dato una strategia per dimezzare o ridurre il tuo backlog IT perché, con la tua supervisione, giusto, le mamme possono andare a fare qualcos'altro su cui si concentrano e che richiede davvero le loro competenze.

Alan Shimel: Mm-hmm.

Andrew Manby: Ma poi, sai, come citizen developer nella sandbox, posso ottenere più velocemente ciò di cui ho bisogno per il business. Non è come una divisione di-

Alan Shimel: Beh, è da provare.

Andrew Manby: - una divisione del lavoro?

Alan Shimel: È una sorta di divisione del lavoro, perché non stiamo parlando di bambini nella sandbox. Ma quando hai dei tester che fanno low-code/no codice costruendo velocemente, essendo in grado di testare più velocemente e meglio, per me, è un uso molto diverso di low-code/no codice, giusto? Questo è un...

Brian ven den Blink: Quello che vediamo spesso, per esempio, con Tricentis, Tricentis è uno strumento di test a low-code, e penso che sia importante come azienda se, per esempio, scelgo lo sviluppo low-code per le mie applicazioni principali. Poi, probabilmente, bisogna anche pensare a cosa significa questo per gli altri ruoli all'interno del dipartimento IT, ad esempio, dobbiamo pensare anche a uno strumento di test a low-code che si adatti alla nostra piattaforma di sviluppo, per esempio? Spesso, penso che quello che vedo ancora accadere è che scegliamo il low code per diverse ragioni e le decisioni che aiutano questo. Inoltre, si può fare affidamento su-okay, sono le stesse decisioni di cui abbiamo bisogno per i nostri strumenti di test, per esempio. E penso che ciò che è importante è che penso che ciò che il low-code apre è che si può lavorare con una piattaforma a low-code e usare quelle capacità anche per una prospettiva di test.

Così, per esempio, se collaudo un processo, ci vuole molto tempo per passare attraverso tutte le schermate e testare un flusso di lavoro, per esempio. E sto testando un flusso di lavoro e ci sono tutti i tipi di dati di cui ho bisogno per testare i risultati specifici di quel flusso di lavoro, prova a trovare soluzioni nella tua piattaforma per prendere quei dati o per impostare quei dati attraverso un modo più veloce che passare attraverso tutte quelle schermate, forse puoi usare un'API o puoi sfruttare qualcosa dalla piattaforma per renderlo più veloce. E penso che è qui che entrano in gioco i test low code, è che è più facile spostarsi a sinistra verso uno sviluppatore e discutere questo tipo di cose. Come-okay, abbiamo un requisito che vogliamo da questa prospettiva di business, di cosa abbiamo bisogno per costruirlo come sviluppatore e di cosa abbiamo bisogno come tester per testarlo in modo più efficiente? E penso che questo sia il punto in cui la cosa si unisce, se discutiamo di questo all'interno di un team e poi è davvero una cosa IT, di cosa abbiamo bisogno da un punto di vista tecnologico per rendere la vita di tutti più facile, fondamentalmente?

E penso che le aziende usano il low-code, per esempio, perché hanno difficoltà nel reperire le persone tecniche in grado di costruire le loro applicazioni. E noi abbiamo sfide simili nei test che è difficile trovare le persone tecniche per costruire gli script tecnici. Quindi, lì, penso che abbiamo bisogno di assicurarci, come azienda, che voi abbiate queste sfide nello stesso modo in cui - ok, le piattaforme a low-code probabilmente hanno anche bisogno di tester a low-code, perché prendete queste decisioni per un motivo, credo. E questo è ciò che vedo nel mio lavoro.

Sì, apre un sacco di opportunità come tester per essere più efficiente nel tuo lavoro e per assicurarti di tenere il passo con i tuoi sviluppatori. Perché lo sviluppo a low-code è molto più veloce dello sviluppo tradizionale, e se non cambi anche tu come tester, sarai sempre, tipo, un collo di bottiglia nel processo, perché non sei più così veloce. Ed è per questo che devi pensare anche a soluzioni più intelligenti.

Alan Shimel: Derya, le app a low-code hanno bisogno di tester low-code?

Derya Sousa: Scusa?

Alan Shimel: Brian ha detto qualcosa sul fatto che se hai applicazioni low-code, ha senso avere tester low-code.

Derya Sousa: Tester low-code - sì, sì, assolutamente. Solo per tornale alla conversazione  sulla governance e la sicurezza, vorrei aggiungere un paio di punti. Penso che, ancora una volta, la soluzione a ciò che hai menzionato, Alan, c'è - sì, abbiamo a che fare con i dipartimenti IT e, sai, gli utenti aziendali sono esposti a queste soluzioni, soluzioni low code/no code - dove è la sicurezza, chi ha accesso a cosa, e come possiamo implementare la governance. E sembra un concetto ampio, ma sapete, qualsiasi organizzazione avrebbe bisogno di implementare la governance, sapete, come operano.

E lo stesso approccio dovrebbe essere implementato quando si tratta di impiegare questo tipo di soluzioni low code/no code. Quindi, solo perché la piattaforma è come un blocco di costruzione LEGO o una sandbox, come hai menzionato, non significa che dovremmo dimenticare tutto, è troppo eccitante, costruiamo tutto ciò di cui abbiamo bisogno e, sai, srotoliamolo rapidamente. Penso che lo stesso approccio che l'azienda avrebbe avuto nella gestione dei cambiamenti, nel controllo dei cambiamenti, nella governance, dovrebbero essere tutti considerati allo stesso modo per approcci a low-code/no codice, sia che sia l'IT a costruirlo o che siano gli utenti aziendali a costruirlo.

E ciò che di solito vediamo funzionare è quando l'IT e i dipartimenti di business lavorano insieme. Così, l'IT crea una sorta di ambiente controllato per questi utenti non-IT per andare a creare soluzioni mentre l'IT li segue o li supervisiona, dando loro gli strumenti di cui hanno bisogno. Ma alla fine, è tutto un ambiente controllato io sono la prima persona che vuole dare alle persone soluzioni libere e innovative che possono liberamente innovare e creare le soluzioni di cui hanno bisogno, ma questo non dovrebbe venire senza un piano. Quindi, un sistema low code/no code non dovrebbe essere implementato senza un piano.

Quindi, è per questo che a volte vediamo una lotta che le aziende attraversano, perché vedono le opportunità, iniziano con una soluzione e vogliono implementarne tante altre in un paio di mesi, e può essere impegnativo se non c'è un piano. Può essere impegnativo se non c'è una strategia, una strategia globale che guarda a diversi tipi di aspetti di come implementare un sistema di sviluppo di applicazioni così rapido, sì.

Brian ven den Blink: Sì, quando abbiamo...

Andrew Manby: Probabilmente non sono d'accordo, perché penso che ci siano diverse modalità. Direi che un sacco di citizen developer low code sviluppano un prototipo e poi lo passano all'IT una volta che lo hanno effettivamente provato, a volte sono lì per un periodo di tempo quindi è letteralmente come uno stand pop-up o un food truck. Sai, arriva, serve al suo scopo e poi viene demolito, giusto? Quindi, non penso che si possa necessariamente avere l'IT coinvolto in tutto.

Voglio dire, certamente, avete una sorta di squadra per farlo, ma non credo che tutto avvenga così. Penso che ci siano diversi modi, sì, alcuni di essi sono sicuramente pianificati attraverso l'IT e il business per fornire qualcosa. A volte si tratta di un team interfunzionale ed è guidato dal business. Ma penso che parte dell'attrazione del low code, e non dobbiamo dimenticarcene, è quella natura organica e l'empowerment delle persone nel business per fare il loro lavoro.

E a volte, sapete, tornando al punto di Alan, non volete essere rallentati da ciò che fa l'IT e come venditori, se facciamo il nostro lavoro correttamente, diamo loro quello spazio sicuro per essere in grado di farlo, giusto? Fidati ma verifica.

Brian ven den Blink: Penso che sia importante - penso, infatti, che ciò che apre, e sono d'accordo, ti permette di prototipare le cose da una prospettiva di business, ma penso che ciò che è importante poi nello spazio successivo è che quel prototipo non deve andare nel nostro ambiente di produzione, fondamentalmente. Quindi, dovete assicurarvi che a volte quello che diciamo è che, se rapportiamo il vecchio spaghetti code, con il low-code, si può dire che quest’ultimo è come  gli spaghetti a cottura rapida, fondamentalmente. Perché vi permette di creare le cose più velocemente ma anche di sbagliare più velocemente.

Quindi, penso che, in effetti, si inizia con un prototipo, si verifica il concetto di base, e poi ad un certo punto, se si vuole davvero avere un'applicazione di base da esso, deve passare attraverso i principi dell'architettura e cose del genere. Ma penso che questo è ciò che Derya intende, forse, con il piano è che, una volta che si passa a questo, dopo la prima fase, si entra davvero in quella fase di pianificazione e come faremo ad ampliare strutturalmente questa applicazione, per esempio?

Derya Sousa: Assolutamente. Solo per aggiungere, quindi, le applicazioni che costruiamo, forniamo, o che i nostri clienti stanno fornendo sono applicazioni di base, applicazioni di core business, e non le vedo funzionare bene in termini di sicurezza e governance se sono solo lasciate e non c'è un piano o non c'è cooperazione con i team IT.

Così, dalla mia esperienza, ho visto questo e ci sono, soluzioni davvero critiche che vengono costruite con sistemi a low-code/no codice, e si stanno collegando a dati critici, e soprattutto con la sicurezza in mente, che tutti dobbiamo avere al giorno d'oggi. Non vedo questo arrivare al massimo potenziale senza che l'IT sia coinvolto.

Andrew Manby: Sì, sono d'accordo su questo, ma vorrei sostenere, continuare a sostenere che ci sono molte cose che devono essere messe in produzione in uno spazio sicuro che sono state curate dall'IT e con le quali permettiamo al business di funzionare, giusto? Questa è solo la natura della bestia, giusto?

Alan Shimel: Assolutamente

Andrew Manby: E ad essere onesti, non so perché vorresti cambiare questo.

Alan Shimel: Beh, questa è una grande conversazione, ma siamo fuori tempo, siamo fuori tempo.Avremmo potuto passare tutto il giorno a parlare e comunque non coprire tutto. Forse dovremo riproporlo e riportarlo per un altro episodio low code/no code, presto.

Ma dobbiamo concludere questo episodio di DevOps Unbound. Brian, Andrew, Derya - grazie mille per aver partecipato e contribuito a questo panel, è stato fantastico. Mitchell, come sempre - buon lavoro.

Mitch Ashley: Mi è piaciuto partecipare. È un grande gruppo.

Alan Shimel: Assolutamente. Grazie mille a Tricentis per aver sponsorizzato DevOps Unbound. Torneremo tra due settimane con un nuovo argomento legato a DevOps. Spero di vedervi lì e di avervi con noi, ma per ora, questo è Alan Shimel per DevOps Unbound. Buona giornata a tutti.