Gli strumenti low-code e no-code, su cui gli utenti aziendali possono fare affidamento per creare le proprie app, si stanno diffondendo nelle imprese. Secondo Gartner, il 41% dei dipendenti non IT crea o personalizza le proprie soluzioni e la società di ricerca prevede che, entro il 2023, questi “citizen developer” supereranno di quattro volte gli sviluppatori professionisti nelle grandi imprese. La maggior parte delle organizzazioni utilizza già almeno uno strumento low-code, adottato da reparti o singoli utenti con un problema da risolvere.

Un giorno, forse presto, sviluppare app senza scrivere codice diventerà un’abilità aziendale comune quanto l’e-mail e i fogli di calcolo, secondo Forrester. Tuttavia, con il vantaggio di uno sviluppo più rapido derivano maggiori rischi.

I team IT devono quindi occuparsi della governance della maggiore autonomia offerta da strumenti self-service e low code. Sebbene le strutture di governance formali non siano ancora comuni, i leader IT stanno iniziando ad affrontare il problema della gestione del low code. “L’obiettivo è consentire a molte persone di svolgere il lavoro tecnologico, gestendo questa opportunità in modo semi-ordinato”, afferma John Bratincevic, analista senior di Forrester.

Le piattaforme low-code offrono una maggiore produttività, risparmi sui costi e spesso un cambiamento culturale che migliora le relazioni tra l’azienda e l’IT. Se eseguito correttamente, il low code può aiutare le organizzazioni a raggiungere quel miglioramento continuo che la trasformazione aziendale ha sempre promesso, con una cultura del problem solving digitale.

Ecco come i CIO possono aiutare i loro “citizen developer” ad avere successo adottando un approccio pragmatico, che riduca i rischi senza scoraggiare la sperimentazione e il self-service.

1. Uscire dall’ombra

Affinché il low code abbia successo, “i CIO non possono considerarlo come shadow IT e non dovrebbero vederlo come un potenziale onere”, afferma Jason Wong, analista di Gartner. “Incoraggiare i citizen developer significa affermare che c’è un accordo tra l’IT e l’azienda, che il team IT li sostiene in ciò che vogliono costruire e li aiuta a comprendere quali sono i migliori strumenti per loro”.

Inoltre, le piattaforme low-code e no-code non forniscono solo un modo per creare app visivamente: centralizzano anche l’accesso e le risorse e tengono traccia di come vengono utilizzate. Per questo motivo, l’IT può creare criteri su chi avrà accesso a quali origini dati e su come è possibile condividere app e flussi di automazione che incorporano tali dati.

Il controllo granulare degli accessi basato sui ruoli consente all’IT di gestire l’accesso a specifici endpoint e tabelle di dati, fino al livello di campo e di record, fornendo l’accesso appropriato a diversi dipartimenti in diversi ambienti di sviluppo. Il team IT dovrebbe anche gestire quali connettori sono disponibili e quali azioni possono essere intraprese su un endpoint. Per esempio, l’assistenza clienti potrebbe creare app in grado di leggere ma non di pubblicare tweet, oppure potrebbe essere permesso agli utenti low-code di aggiornare i record ma di non eliminare mai nulla.

2. Bilanciare equilibrio e autonomia

Ottenere il giusto equilibrio tra controllo e autonomia per i citizen developer è fondamentale. Garantire la sicurezza è importante, ma se la governance e i processi di accesso sono troppo onerosi, le persone torneranno semplicemente alla shadow IT.

Ciò richiede pianificazione”, osserva Bratincevic. “Non è una cosa troppo complessa, ma va pensata bene ed è specifica per ogni ambiente. Prima di impostare la governance, è necessario stabilire dei criteri per i dati, chiedendosi quali dati sono disponibili, quali sono sensibili e quali no”.

Assicuratevi di applicare la protezione dalle fughe di dati a tutti i dati condivisi esternamente e di disporre di policy che avvertono i citizen developer se stanno creando un’automazione o un flusso di lavoro che potrebbe violare la conformità, per esempio copiando un’email.

I citizen developer dovrebbero anche avere autonomia nella scelta della piattaforma. “È un errore costringere l’azienda a standardizzare su un’unica piattaforma low-code”, avverte Wong. “Se gli utenti aziendali non hanno l’autorità di scegliere gli strumenti che funzionano per loro, il processo non funziona”.

Wong suggerisce ai responsabili IT di affidarsi al proprio framework di governance e chiarire quanto supporto possono aspettarsi gli utenti se scelgono uno strumento diverso. “Va chiarito lo scopo di ciò che si può fare, indicando la ‘zona sicura’ e l’ambito in cui il team IT può fornire supporto”, aggiunge, “specificando quali risorse può o non può mettere a disposizione l’IT”.

3. Scegliere il giusto approccio strategico

Anche stabilire il giusto modello strategico per gestire i citizen developer della propria azienda è fondamentale.

Forrester identifica tre approcci comunemente adottati. Il primo prevede la creazione di un piccolo team autonomo, composto da persone con esperienza nel miglioramento dei processi, approvato dall’IT ma integrato in una business unit e che riporta a un dirigente aziendale. “Questo approccio strategico è molto agile, ma non scalabile”, sottolinea Bratincevic. “Si tratta di una piccola squadra che fa tutto il lavoro”.

Il secondo è l’approccio self-service, in cui chiunque può sviluppare con strumenti low-code basati su policy e guardrail nelle piattaforme. “Il CIO controlla il ‘cosa’, invece del ‘chi’. Il chi può essere chiunque, mentre il cosa è vincolato dalla natura della piattaforma e dalle policy di accesso ai dati”, spiega Bratincevic.

Il terzo approccio, più maturo, combina team agili e ampia democratizzazione in un modello federato, con un Centro di Eccellenza (CoE) che gestisce piattaforme low-code, implementa guardrail e supporta team o singoli “champion” nei dipartimenti e unità aziendali, nonché sviluppatori self-service e low-code.

In questo modello il modo in cui viene sviluppata un’app specifica dipende dal suo caso d’uso, dai dati utilizzati e dall’esperienza dello sviluppatore coinvolto”, precisa Bratincevic. “Potresti avere più o meno passaggi nel ciclo di vita dello sviluppo della sicurezza; potresti avere più o meno requisiti riguardo alle preview; potresti dover lavorare con qualcuno prima di utilizzare una determinata fonte di dati”.

Questo modello è più complesso, ma anche più pragmatico e permette il controllo sui dati e il processo di sviluppo.

4. Fornire un supporto IT adeguato

Oltre alla governance e alle policy, i CIO devono fornire risorse e supporto. “L’atteggiamento dell’IT nei confronti dei citizen developer è fondamentale per la loro produttività e i loro risultati positivi”, afferma Wong di Gartner.

La società di ricerca suggerisce di formalizzare l’attività dei citizen developer con un framework di governance che copra le zone sicure “verdi”, dove gli utenti possono creare flussi di lavoro e automazione; zone di supporto “gialle”, in cui lavorano con sviluppatori professionisti per creare applicazioni più potenti; e zone di pericolo “rosse” che richiedono la supervisione e l’approvazione dell’IT, con alcune app considerate così complesse e critiche per l’azienda da rimanere sotto il controllo dell’IT.

Un Centro di Eccellenza, per esempio, potrebbe creare API e componenti personalizzati o consentire la fusione di team con sviluppatori professionisti che lavorano sia in ambienti di sviluppo low-code che tradizionali. Il COE potrebbe anche fornire risorse di apprendimento e aiuto esperto ai citizen developer per lavori più complessi o critici, come la scrittura di espressioni di query.

Questo tipo di collaborazione e supporto è ciò che differenzia il low code dallo shadow IT.

In un contesto di shadow IT ci sono individui che lavorano da soli, facendo cose nell’ombra”, afferma Wong. “Incoraggiando i citizen developer, invece, agli utenti viene offerto un percorso per imparare a utilizzare gli strumenti opportuni, con la possibilità di chiedere aiuto alla comunità, ad altri utenti esperti, ma anche potenzialmente all’IT”.

5. Scegliere API e connettori giusti

Per avere successo, l’IT deve essere proattiva nel rendere disponibili i connettori e nella creazione di API robuste per l’accesso ai dati interni.

Assicuratevi che le API siano ben definite, dispongano di un livello di gestione o catalogo e quindi siano facilmente collegate alle soluzioni low-code/no-code”, afferma Kin Lane, chief evangelist della piattaforma API Postman.

È inoltre necessario tenere traccia di dove vengono utilizzate le API in produzione, sia per tenere sotto controllo i costi per le API esterne sia per assicurarsi che i sistemi che forniscono un’API interna dispongano di risorse adeguate. Non tutto ciò che funziona come un’API è prodotto da un back-end robusto. “Per quanto ci piaccia credere che un’API RESTful ben progettata sia ciò che costituisce un’API, semplicemente non è così”, osserva Lane.

Da non dimenticare l’automazione dei processi robotici (RPA), un modo sempre più diffuso per ottenere informazioni dai sistemi legacy, nelle app low-code e nei flussi di lavoro di automazione. Per esempio, stabilendo un flusso di lavoro RPA che automatizza l’estrazione dei dati dai PDF scansionati, l’IT può ulteriormente consentire ai citizen developer di creare app aziendali vantaggiose.

6. Non dimenticare recensioni e metriche

È improbabile che i singoli utenti aziendali che stanno risolvendo il proprio problema pensino all’elevata disponibilità, alle metriche aziendali o a qualsiasi tipo di revisione formale. Poche piattaforme low-code includono strumenti per questo, ma possono essere utili metriche come il conteggio del tempo necessario per completare un processo, così come l’introduzione di revisioni regolari per tenere traccia delle prestazioni e analizzare le opportunità per un ulteriore sviluppo.

Le metriche e le revisioni offrono anche l’opportunità di esaminare i processi aziendali, poiché l’automazione di un processo errato porta più rapidamente a risultati negativi. Gli strumenti di process mining permettono di scoprire le inefficienze o il lavoro extra che alcuni team potrebbero svolgere. E’ importante anche permettere al personale che lavora effettivamente su un processo di semplificarlo, invece che creare app che mette un cerotto sul problema.

7. Evolvere le operazioni secondo necessità

Gli strumenti di analisi e monitoraggio nelle piattaforme low-code possono non solo tenere traccia dell’utilizzo delle API, ma anche segnalare le app che sono diventate così popolari o critiche per l’azienda che sarebbe opportuno spostarle nelle zone di supporto gialle o rosse delineate da Gartner.

Idee rivoluzionarie che si trasformano in app così popolari da richiedere più supporto IT sono un segno di innovazione aziendale”, afferma Wong. “Il compito dell’IT è renderle sostenibili”.

In pratica, questa progressione può creare tensione; lo sviluppatore originale low-code potrebbe avere dubbi sull’acquisizione dello strumento da parte dell’IT e il team IT potrebbe avere dubbi sul supporto di un’app che non ha creato. Una cultura di collaborazione tra business e IT dovrebbe aiutare a evitare sospetti da entrambe le parti.

8. Promuovere una cultura dell’innovazione

I leader IT possono temere che la sperimentazione low-code produca troppe app che poi il team IT dovrà gestire. Tuttavia, un problema più comune è non suscitare abbastanza interesse per far funzionare la strategia. Come sottolinea Bratincevic, molti utenti aziendali che potrebbero efficacemente sfruttare il low code non penseranno naturalmente a loro stessi come “sviluppatori”.

Ci sono molti manager del business con una mentalità tecnica che svolgono lavori tecnici o in shadow IT”, afferma, “ma non vorranno necessariamente acquistare un programma formale con una piattaforma di governance”.

Molte aziende trovano efficaci gli hackathon interni, con tempo per formazione, tutoraggio e supporto, per stimolare l’interesse e generare un nucleo di app iniziali. In alternativa, è possibile cercare “risolutori di problemi” che potrebbero offrirsi come early adopter. Le persone che stanno già utilizzando l’IT ombra come parte di un ruolo che prevede il miglioramento continuo o progetti speciali sono i primi candidati per diventare champion in un determinato ambito, soprattutto se hanno richiesto un’app su cui l’IT non ha avuto il tempo di lavorare.

Il low code può consentire una significativa progressione di carriera, man mano che gli utenti aziendali acquisiscono esperienza per ruoli più tecnici. E’ un modo per far crescere la futura forza lavoro digitale: i dipendenti vanno preparati e premiati per raggiungere questo obiettivo. Uno dei motivi per cui i programmi low-code non riescono a scalare è l’aspettativa che i dipendenti ci lavorino in aggiunta al loro carico di lavoro giornaliero, piuttosto che come parte di questo, soprattutto se la cultura aziendale non apprezza il miglioramento continuo.

Il CIO deve occuparsi anche dell’aspetto umano della gestione del cambiamento. Cosa succede se il citizen developer passa a un altro lavoro e i suoi colleghi o chi lo sostituisce non sono interessati ad accettare l’app? Oppure, se sono interessati, lo scopo e lo background dell’app sono stati adeguatamente documentati per consentire la distribuzione?

D’altra parte, non tutte le app low-code rimarranno utili per sempre”, afferma Wong. “Se nessuno è interessato a un’app, significa che non è stata molto utile e si può lasciarla andare. E’ un problema minore, considerato che il costo di implementazione è stato molto basso”.

Il CIO deve pensare al low code come a un’opportunità, ma rendersi anche conto che è inevitabile”, suggerisce Bratincevic. “Non sarà perfetto, ci saranno problemi, commetterà degli errori, ma questa è la sua opportunità per orchestrare tutte le persone che sviluppano app all’interno dell’azienda in modo connesso, automatizzato e sensato; per gettare le basi giuste, senza lasciare tutto al caso”.