Programma di servizi di sviluppo low-code: una guida per l'acquirente

Un programma di servizi di sviluppo low-code è un modo strutturato per acquistare la distribuzione di applicazioni, raggruppando una piattaforma visiva, servizi professionali e supporto continuo attraverso circa quattro modelli di coinvolgimento: aumento del personale, consegna di progetti a portata fissa, servizi applicativi gestiti e partnership di piattaforma e abilitazione. Gartner ha coniato il termine “low-code” nel 2014 e da allora il mercato si è suddiviso in categorie di servizi distinte che si comportano in modo molto diverso in termini di costi, controllo e lock-in.

I programmi di servizi di sviluppo low-code raggruppano tre elementi che di solito vengono venduti separatamente nell’IT tradizionale: una piattaforma di sviluppo visivo, i servizi professionali per svilupparvi sopra e il supporto continuo per mantenere in esecuzione le applicazioni risultanti. Gli acquirenti che capiscono che il bundle possono negoziare ogni livello in modo indipendente ed è qui che si guadagna o si perde la maggior parte del valore.

Il livello della piattaforma è costituito dagli strumenti: generatori di moduli drag-and-drop, progettisti di modelli di dati, motori di flusso di lavoro, connettori API e pipeline di distribuzione. Gli esempi citati includono Microsoft Power Apps, OutSystems, Mendix, Appian, Retool, Budibase e, per i team già investiti nell’ecosistema 4D, gli strumenti di 4D per moduli, metodi e modelli dati.

Il livello dei servizi è il lavoro umano: workshop di scoperta, modellazione dei dati, integrazione, test e passaggio di consegne. Il livello di supporto è ciò che accade dopo il go-live: monitoraggio, richieste di modifica, aggiornamenti di versione e formazione degli utenti.

Un programma di servizi di sviluppo low-code differisce da un progetto una tantum per un aspetto importante: presuppone la ripetizione della consegna. Invece di commissionare una singola app, l’acquirente imposta una capacità permanente – un modello di governance, una libreria di componenti riutilizzabili e una cadenza di consegna – in modo che la seconda app costi molto meno della prima. Questa economia del riutilizzo è l’intera giustificazione per l’inquadramento del “programma”.

I quattro modelli di servizio a confronto

I servizi di sviluppo low-code sono disponibili in forme che si adattano a organizzazioni molto diverse. La tabella seguente è l’aiuto decisionale di cui la maggior parte degli acquirenti ha bisogno prima di parlare con qualsiasi fornitore.

Correlato: Claris FileMaker Pro — La piattaforma di database relazionale di lunga durata per i team che necessitano di app personalizzate su desktop, Web e dispositivi mobili da un singolo file..

Modello	Acquirente tipico	Controllo	Profilo dei costi	Rischio principale
Aumento del personale	Team IT con lacune nelle competenze della piattaforma	Alto: dirigi il lavoro	Tariffa oraria o mensile	Il know-how svanisce con il consulente
Progetto a portata fissa	Dipartimento con un’app definita	Basso durante la creazione	Prezzo fisso per app	Richieste di modifica fatturate separatamente
Servizi applicativi gestiti	Team operativo che esegue app live	Da basso a medio	Retainer ricorrente	Risposta lenta alle nuove esigenze
Piattaforma + partnership di abilitazione	Organizzazione che sviluppa capacità interne	Media, cresce nel tempo	Blended: piattaforma, formazione, creazione	Richiede tempo di assorbimento da parte del personale interno

L’aumento del personale è adatto ai team che dispongono già di una piattaforma standard e di un arretrato. I progetti con ambito fisso si adattano a un singolo flusso di lavoro di alto valore con requisiti stabili. I servizi gestiti sono adatti ad ambienti regolamentati in cui i tempi di attività e gli audit trail contano più della velocità. Le partnership di abilitazione sono adatte alle organizzazioni che intendono creare decine di app e desiderano le funzionalità internamente.

Una regola pratica: se l’acquirente non riesce a nominare la persona che sarà proprietaria dell’applicazione entro diciotto mesi, il programma viene acquistato per il motivo sbagliato. I programmi di servizi di sviluppo low-code falliscono molto spesso non perché la piattaforma fosse sbagliata ma perché non è mai stato assegnato alcun proprietario interno.

Differenze nella pratica tra i servizi low-code e no-code

I servizi di sviluppo low-code e no-code sono spesso commercializzati come un’unica categoria, ma le due metà impongono vincoli diversi sull’coinvolgimento dei servizi. Gli strumenti senza codice sono destinati agli utenti aziendali che configurano le applicazioni senza scrivere la logica; gli strumenti a basso codice presuppongono che uno sviluppatore estenderà la piattaforma con il codice quando il costruttore visivo esaurisce la strada.

La nostra scelta: Airtable — Un'interfaccia semplice come un foglio di calcolo posizionata sopra un vero database relazionale, con automazioni, visualizzazioni e interfacce condivisibili..

Questa distinzione modifica il contratto di servizi. Un impegno senza codice riguarda principalmente la configurazione, la formazione e la governance: il compito del fornitore è mantenere gli sviluppatori cittadini all’interno di confini sicuri. Un impegno low-code aggiunge ingegneria di integrazione, componenti personalizzati, ottimizzazione delle prestazioni e configurazione CI/CD, perché si prevede che le applicazioni tocchino i sistemi di produzione e siano scalabili.

La maggior parte dei programmi aziendali finiscono per diventare ibridi. Un livello senza codice gestisce i tracker dipartimentali, i flussi di approvazione e la raccolta dei dati. Un livello di programma di servizi di sviluppo low-code gestisce tutto ciò che scrive su un sistema principale, applica regole aziendali complesse o necessita di una traccia di controllo. I fornitori che vendono solo un livello spingeranno tutti i requisiti in quel livello, cosa che vale la pena tenere d’occhio durante la definizione dell’ambito.

Come si presenta un vero engagement, fase dopo fase

La fornitura di servizi di sviluppo low-code segue un arco riconoscibile e conoscere le fasi consente all’acquirente di individuare un fornitore che sta saltando quelli costosi.

Discovery e modellazione dei dati. Il fornitore mappa il processo aziendale, identifica le entità e le relazioni e decide cosa risiede nella piattaforma low-code rispetto a cosa rimane nel sistema di record. La modellazione dei dati è il luogo in cui ha origine la maggior parte delle rielaborazioni; un modulo creato su un modello di entità errato viene ricostruito, non corretto.

Prototipo e validazione. Un prototipo funzionante verrà presentato agli utenti reali entro le prime settimane. Le piattaforme a basso codice lo rendono conveniente e un fornitore che non può creare rapidamente un prototipo cliccabile non sfrutta il vantaggio principale della piattaforma.

Creazione e integrazione. Vengono assemblate schermate, flussi di lavoro, elenchi di valori e connessioni API. L’integrazione è solitamente la voce più importante in qualsiasi stima onesta, perché l’autenticazione, la gestione degli errori e la sincronizzazione dei dati non sono mai così semplici come suggerisce la demo.

Correlato: Knack — Un generatore di database senza codice rivolto a portali, directory e strumenti interni, con prezzi forfettari anziché tariffe per utente..

Test e rafforzamento. L’accesso basato sui ruoli, la convalida dell’input, il comportamento della concorrenza e le prestazioni con volumi di dati realistici vengono controllati. Le piattaforme low-code nascondono la complessità, il che significa che i problemi di prestazioni spesso emergono tardi.

Distribuzione e passaggio di consegne. L’applicazione passa alla produzione e, aspetto fondamentale, la documentazione, la formazione amministrativa e il processo di richiesta di modifica vengono trasferiti al team interno.

Gestione e iterazione. Il programma dei servizi di sviluppo low-code continua con un backlog, una cadenza di rilascio e aggiornamenti periodici della piattaforma. I fornitori di piattaforme rilasciano nuove versioni secondo il proprio programma e qualcuno deve assorbire tali cambiamenti.

Preferiti dai lettori: Microsoft Power Apps — Sviluppo di app low-code di livello aziendale collegato a Microsoft 365, Dataverse e Power Automate..

Criteri di selezione che effettivamente predicono il successo

Valutare i fornitori di servizi di sviluppo low-code basandosi solo sul riconoscimento del marchio produce errori costosi. I criteri seguenti sono quelli correlati ai programmi di servizi di sviluppo low-code che sopravvivono al secondo anno.

• Costo di uscita dalla piattaforma. Chiedi cosa succede all’applicazione se il coinvolgimento termina. I dati possono essere esportati in un formato utilizzabile? La logica può essere letta da qualcun altro? La logica visiva proprietaria rappresenta il rischio di lock-in più grande in questo mercato.
• Track record di integrazione. Richiedi due referenze che coinvolgono la stessa classe di sistema che devi connettere: un ERP, un CRM, un database legacy o una directory locale.
• Team nominato, non elenco delle capacità. Chiedi chi svolgerà effettivamente il lavoro e se tali persone sono dipendenti o subappaltatori.
• Artefatti di governance. Un programma serio produce una strategia ambientale, un modello di controllo degli accessi e una convenzione di denominazione. I fornitori che li considerano opzionali stanno costruendo futuri debiti di mantenimento.
• Impegno di consegna. Il contratto deve specificare la documentazione, la formazione amministrativa e un periodo definito di supporto post-lancio.
• Trasparenza dei prezzi. Esistono prezzi per app, per utente, per ora e a retainer. Il modello conta meno del fatto che il venditore ti mostri come è stato costruito il numero.

Per la due diligence a livello di piattaforma, la ricerca degli analisti pubblicata da aziende come Gartner e Forrester è un punto di partenza ragionevole e la voce di Wikipedia sulle piattaforme di sviluppo low-code fornisce una panoramica neutrale della storia e delle definizioni della categoria. Gli acquirenti nei settori regolamentati dovrebbero anche verificare la posizione del fornitore rispetto al NIST Cybersecurity Framework, che molti team di procurement aziendale ora utilizzano come vocabolario comune per le domande di sicurezza.

Dove i programmi low-code danno davvero risultati e dove no

I programmi di servizi di sviluppo low-code offrono i rendimenti più elevati su applicazioni numerose, simili e di breve durata. Moduli di richiesta interni, flussi di lavoro di approvazione, liste di controllo di ispezione, tracciatori dell’inventario e dashboard dipartimentali si adattano a questo schema: ognuno è piccolo, ognuno condivide i componenti con i suoi fratelli e ognuno altrimenti rimarrebbe in un arretrato IT per mesi.

I programmi hanno difficoltà quando l’applicazione è veramente complessa. I sistemi transazionali ad alto volume, le applicazioni con complessi requisiti di concorrenza e qualsiasi cosa con pesanti calcoli in tempo reale sono solitamente meglio serviti dallo sviluppo convenzionale o da un ibrido in cui il livello a basso codice gestisce l’interfaccia e un servizio convenzionale gestisce la logica principale.

Un secondo modello di fallimento è il pilota abbandonato. Le organizzazioni spesso eseguono una prova di concetto con successo, poi si bloccano perché nessuno ha finanziato il livello di governance. Il progetto pilota dimostra che la piattaforma funziona; non dimostra che il programma funzioni. Il budget per le parti noiose – gestione dell’ambiente, revisione della sicurezza, formazione e supporto – è ciò che trasforma un progetto pilota in un programma.

Un terzo modello è l’shadow sprawl. Quando gli sviluppatori cittadini creano liberamente senza una libreria di componenti o un processo di revisione, un’organizzazione può ritrovarsi con centinaia di applicazioni quasi duplicate e senza alcun inventario di ciò che esiste. Un programma di servizi dovrebbe includere un registro delle applicazioni fin dal primo giorno.

Build vs Buy: quando un programma interno batte uno esterno

Le organizzazioni con capacità di sviluppo esistente a volte chiedono se hanno bisogno di servizi di sviluppo esterni a basso codice. La risposta onesta dipende da tre variabili: quante applicazioni sono pianificate, quanto insoliti sono i requisiti di integrazione e se la piattaforma è già standardizzata.

Un programma interno ha senso quando l’organizzazione si è impegnata a utilizzare una piattaforma, pianifica più di una manciata di applicazioni e può dedicare almeno uno sviluppatore esperto alla proprietà della piattaforma. Il ruolo del fornitore esterno si riduce quindi all’abilitazione iniziale e al lavoro specialistico occasionale.

Un programma esterno ha senso quando la decisione sulla piattaforma è ancora aperta, quando le prime applicazioni comportano integrazioni sconosciute o quando semplicemente non è possibile liberare il personale interno dagli impegni esistenti. In tal caso, il contratto dovrebbe essere scritto con una rampa di uscita esplicita – un punto in cui il team interno subentra – piuttosto che con un retainer a tempo indeterminato.

I team che si basano sulla 4D spesso siedono in una posizione intermedia. Il modello di dati, i moduli e i metodi sono già familiari allo sviluppatore interno, quindi i servizi esterni sono più preziosi per il lavoro di integrazione, l’architettura di distribuzione e la modernizzazione delle strutture binarie precedenti. Si tratta di un impegno più ristretto rispetto a un programma completo e dovrebbe essere valutato di conseguenza.

Fonti e ulteriori letture

• Piattaforma di sviluppo a basso codice - Wikipedia: una piattaforma di sviluppo a basso codice (LCDP) fornisce un ambiente di sviluppo software, in genere un’interfaccia utente grafica (GUI), che richiede poca o nessuna scrittura…

Domande frequenti

Cos’è un programma di servizi di sviluppo low-code?

Un programma di servizi di sviluppo low-code è un accordo permanente in cui un fornitore fornisce sia una piattaforma low-code che i servizi professionali per creare, distribuire e mantenere le applicazioni su di essa. Si differenzia da un singolo progetto perché presuppone consegne ripetute, componenti condivisi e un modello di governance continuo. Gli acquirenti in genere scelgono tra aumento del personale, progetti con ambito fisso, servizi gestiti e partnership di abilitazione.

Quanto costano i servizi di sviluppo low-code?

I prezzi variano troppo ampiamente per una singola figura affidabile, perché dipendono dalla licenza della piattaforma, dal modello di coinvolgimento e dalla complessità delle integrazioni. I fornitori quotano per ora, per applicazione, per utente o come anticipo mensile e la licenza della piattaforma viene solitamente fatturata separatamente dai servizi. Il confronto più utile è il costo totale per applicazione consegnata su una roadmap multi-app, non la tariffa principale.

Lo sviluppo low-code è adatto alle applicazioni aziendali?

Il low-code è adatto alle applicazioni aziendali numerose, guidate dal flusso di lavoro e ad alta integrazione: sistemi di approvazione, tracker, portali e strumenti dipartimentali. È una soluzione più debole per core transazionali ad alto volume, calcoli in tempo reale e sistemi con richieste di concorrenza insolite. Molte aziende utilizzano un approccio ibrido: low-code per il livello di interfaccia e flusso di lavoro, codice convenzionale per la logica principale.

Qual è la differenza tra i servizi di sviluppo low-code e no-code?

I servizi senza codice si concentrano sulla configurazione e sulla governance in modo che gli utenti aziendali possano creare in sicurezza senza programmazione. I servizi low-code aggiungono ingegneria di integrazione, componenti personalizzati, ottimizzazione delle prestazioni e pipeline di distribuzione, perché si prevede che le applicazioni tocchino i sistemi di produzione. La maggior parte dei programmi aziendali opera su entrambi i livelli, indirizzando le app semplici al no-code e quelle complesse al low-code.

Quanto tempo è necessario per fornire un’applicazione tramite un programma di servizi low-code?

Spesso un prototipo può essere mostrato entro le prime settimane, mentre una semplice applicazione dipartimentale raggiunge generalmente la produzione nel giro di mesi anziché trimestri. Le tempistiche si allungano quando le integrazioni sono complesse, la revisione della sicurezza è impegnativa o i requisiti cambiano durante la creazione. Il vero vantaggio in termini di velocità del programma si manifesta nella seconda e nella terza applicazione, una volta che i componenti e la governance sono a posto.

Cosa dovrebbe includere un contratto di servizi low-code?

Un contratto dovrebbe specificare il team di consegna nominato, la piattaforma e le responsabilità di licenza, l’ambito di integrazione, la documentazione e la formazione per gli amministratori, un periodo di supporto post-lancio definito e i termini in base ai quali l’acquirente può internalizzare il lavoro. I diritti di esportazione dei dati e la leggibilità della logica personalizzata meritano un linguaggio esplicito, perché determinano quanto sarà costoso lasciare il fornitore in un secondo momento.