Il contratto prematrimoniale nel divorzio tecnologico: come prevenire il vendor lock-in

Come la consapevolezza di una via d’uscita possa essere la spinta finale per adottare una nuova tecnologia

In questo articolo andremo a parlare del procedimento di separazione di una tecnologia da un vendor, dei motivi per i quali è importante avere ben chiaro come si svolga questo processo e di come affrontarlo con il supporto di specialisti del settore.  

The digitalizzazione dei processi aziendali ha spinto un numero crescente di aziende ad adottare applicazioni specifiche per sostituire processi di business non strutturati e spesso manuali. Di conseguenza, il mercato digitale propone continuamente sistemi innovativi per la creazione di applicazioni. 

Oggi l’attenzione non si concentra più solo sulla qualità, ormai considerata un requisito imprescindibile per qualsiasi tecnologia, ma anche sulla capacità di soddisfare la crescente e continua domanda del business, una necessità che non può più essere affrontata con i metodi di sviluppo tradizionali. 

Per questo motivo, il mercato delle piattaforme di sviluppo low-code e no-code ha registrato una crescita significativa, offrendo soluzioni rapide e collaborative per la creazione di applicazioni. Promuovendo il concetto di Citizen Developer, queste tecnologie permettono di sviluppare applicazioni complete senza la necessità di scrivere codice, accelerando i tempi di sviluppo, favorendo una maggiore collaborazione tra business e IT e generando soluzioni immediatamente fruibili ed espandibili. 

Tuttavia, nella fase di software selection, emerge spesso una domanda cruciale: cosa accade alla mia applicazione se decido di interrompere il contratto con il vendor?  

Questo dubbio è particolarmente rilevante per molte tecnologie low-code e no-code, poiché il modello di sviluppo utilizzato non genera un file di codice sorgente tradizionale che possa essere facilmente trasferito o modificato. La struttura delle applicazioni è strettamente legata alla piattaforma stessa, il che rende complesso estrarre e migrare l’applicazione verso un ambiente alternativo senza un processo di adattamento e conversione approfondito. 

Una situazione che, di fatto, amplifica il rischio di vendor lock-in. 

La sfida del vendor lock-in 

Non è più pensabile impegnarsi a tempo indeterminato con una sola tecnologia.  

Infatti, non siamo più all’inizio del processo di digitalizzazione: ormai sono 20 anni che diverse aziende si sono imbarcate in questa avventura, passando attraverso numerose tecnologie. Il mercato ed i bisogni evolvono ad una velocità tale che risulta impensabile rimanere legati per sempre ad una sola soluzione tecnologica. Di conseguenza, il vendor lock-in è diventato più un ostacolo alle vendite che un’assicurazione per i fornitori. 

Non c’è quindi da stupirsi che le aziende comincino a considerare non solo le performance nella creazione e nello sviluppo di applicazioni, ma anche la facilità con cui queste possono essere esportate e trasferite su altre piattaforme. Le tecnologie possono nascere e morire, ma la cosa più importante è preservare il valore intrinseco di un’applicazione: la proprietà intellettuale del progetto. 

Come analisti funzionali in WEGG, abbiamo assistito a numerose situazioni di “divorzio tecnologico” e ai drammi che possono derivarne. Questo ci ha reso pienamente consapevoli dell’importanza di supportare i nostri clienti anche nelle fasi più critiche, garantendo che il valore del progetto resti intatto durante ogni transizione 

Proprio come un bravo avvocato riesce a gestire un divorzio risparmiando mal di testa ai propri clienti, noi di WEGG siamo pronti a intervenire per facilitare queste transizioni. Crediamo che ogni relazione tecnologica debba essere paritaria e, quando necessario, concludersi in modo amichevole e professionale. 

La scelta della tecnologia giusta 

Tenendo conto di queste riflessioni, è evidente come sia fondamentale scegliere una tecnologia che non solo soddisfi le esigenze attuali del business, ma che offra anche una strategia chiara e concreta per prevenire il rischio di vendor lock-in 

Partiamo dalle brutte notizie: non esiste da nessuna parte un tasto che traduce tutto il modello dell’applicazione in codice e lo copia su un file, ma ci sono delle tecnologie che ci permettono di farlo con il supporto di specialisti: tra i nomi presenti sul mercato abbiamo individuato Mendix technology., che secondo Gartner si riconferma anche nel 2024 piattaforma leader per la creazione di applicazioni low-code. 

In Mendix è possibile migrare l’applicazione al di fuori dell’ambiente di sviluppo per farla funzionare in un altro contesto.  

Ecco che nasce questo articolo, in cui vogliamo illustrare in maniera chiara come è possibile separare l’applicazione creata dalla tecnologia Mendix, mantenendo intatto il vero valore del prodotto, ovvero la proprietà intellettuale di chi l’ha ideato 

Come prevenire il rischio di lock-in in Mendix 

Iniziamo spiegando prima di tutto in che cosa consiste, in concreto, un’applicazione sviluppata su Mendix. 

Essendo una piattaforma low-code, tutto il lavoro di sviluppo è principalmente in forma di modello visivo, senza scrivere quindi un codice sorgente. Il modello visivo definisce l’intero funzionamento dell’applicazione, ovvero il flusso, i dati, le logiche, l’interfaccia utente, le integrazioni con sistemi esterni.  

Quando si parla di modello dell’applicazione si intende l’insieme di queste caratteristiche che la definiscono. Tutti questi elementi vanno esportati e trasportati nella piattaforma finale di arrivo, e per facilitare questo processo, Mendix mette a disposizione due risorse: 

  • File .mpk
    Il File .mpk può essere estratto tramite la piattaforme di sviluppo e contiene tutte le informazioni essenziali per l’applicazione: modello dati con definizione di entità e relazioni, micro-flussi, logiche aziendali, pagine, widget e stili che compongono l’interfaccia utente, moduli aggiuntivi scritti in Java, API, configurazioni per il deployment e per l’esecuzione nell’ambiente Mendix Cloud o su un server.  

 

  • Piattaforma SDK
    Mendix's native Software Development Kit fornito da Mendix è una piattaforma utilizzata principalmente per espandere la propria applicazione scrivendo del codice Java, che potrà poi essere riutilizzato in futuro. In questo contesto però, può essere utilizzata sia per accedere al modello dell’applicazione sia per convertire programmaticamente le logiche dei micro-flussi in codice Java.  
Article written by Francesco Clabot, CTO di WEGG e docente di IT Service Management all’Università di Padova

Ora che abbiamo tutti gli elementi, possiamo effettuare concretamente la procedura di migrazione dell’applicazione. Questa si divide in due fasi: l’estrazione del modello da Mendix e la ricreazione del modello nella nuova piattaforma.

Estrazione del modello da Mendix 

Per estrarre il modello da Mendix, dobbiamo essere in possesso della documentazione di analisi completa dell’applicazione. Niente paura! Noi di WEGG siamo molto attenti al processo di analisi e di progettazione, creando delieverables che ne descrivono graficamente e in linguaggio naturale l’intero funzionamento.  

La documentazione si divide principalmente in due aree, analisi funzionale ed analisi tecnica, che nel loro insieme contengono la logica di business e i micro-flussi, il modello dei dati, l’interfaccia utente ed una descrizione di metodi aggiuntivi, API ed integrazioni.  

Questi elementi rappresentano in maniera concreta dei concetti astratti, che sono la base e la traduzione logica dell’idea dell’applicazione. Costituiscono pertanto la proprietà intellettuale del progetto che deve essere preservata anche se si dismette la tecnologia attuale.  

Ora che abbiamo chiaro quali sono i concetti astratti che dobbiamo trasportare, pensiamo ai dati concreti: questi si possono trovare nel database Mendix o in un database esterno in base alle esigenze tecniche riscontrate in fase di progettazione e sviluppo. I dati si possono esportare in entrambi i casi, usando un file .CSV o .JSON oppure trasferendoli direttamente sul database finale. Per questo passaggio, è essenziale aver creato una struttura dati finale compatibile con quella di partenza, in modo che tutti i dati possano essere rappresentati ed utilizzati correttamente.  

Se sono presenti dei moduli Java aggiuntivi o dei micro-flussi, è il momento di utilizzare la piattaforma SDK ed estrarre il codice.  

Ricreazione del modello nella nuova piattaforma 

Dopo tutta la fase di estrazione e preparazione, è ora il momento di ricreare l’applicazione nella piattaforma finale. In base al tipo di piattaforma usata, ci saranno più o meno operazioni manuali da fare (ad esempio, la creazione ed il popolamento del database). Di certo c’è che, se si è in possesso di codice sorgente Java, l’ambiente finale deve essere in grado di leggerlo ed eseguirlo. Per essere guidati nella ricreazione degli elementi del modello, è anche possibile consultare il contenuto del file .mpk contestualizzato dalla documentazione funzionale e tecnica.  

Una volta costruiti il modello dei dati, le pagine di interfaccia e importate le logiche dei micro-flussi sottoforma di codice, è il momento di adattare il codice al nuovo ambiente in modo che sia perfettamente funzionante. Per questo passaggio è consigliato il supporto di sviluppatori con esperienza.  

A questo punto rimangono solo il test dell’applicazione nel nuovo ambiente e le procedure di deployment et voilà, abbiamo migrato tutta l’applicazione al di fuori dell’ambiente di sviluppo Mendix.  

Conclusioni 

Come qualsiasi divorzio, migrare un’applicazione dalla piattaforma in cui si trova non è mai un processo semplice. Tuttavia, con una tecnologia low-code che supporti tale transizione e il contributo di specialisti competenti, è un obiettivo assolutamente realizzabile. 

Vi lascio con una riflessione personale: come analista funzionale, comprendo quanto sia cruciale essere preparati ad affrontare queste situazioni. Le tecnologie sono in continuo cambiamento, ma nonostante ciò è indispensabile riuscire a preservare il valore intrinseco di un progetto – ovvero la proprietà intellettuale e l’idea alla base.  

Per questo motivo, attribuiamo un’importanza fondamentale alla creazione e alla cura della documentazione di analisi, uno strumento indispensabile per ricreare e trasferire un progetto in qualsiasi contesto, e alla scelta di una tecnologia che permetta di gestire una separazione tecnologica senza dover pagare “alimenti a vita”. 

In WEGG supportiamo i nostri clienti in ogni fase progettuale di sviluppo di applicazioni e siamo pronti anche a gestire un’eventuale separazione tecnologica. Quindi, nel caso arrivasse il momento di salutarsi, non temete: avremo già pronto il “contratto prematrimoniale” fin dal giorno delle nozze, nonostante il nostro augurio sia sempre quello di celebrare matrimoni duraturi e felici. 

*Articolo a cura di Virginia Lazzari, Business Consultant in WEGG

02-s pattern02

Would you like to discover how to optimize IT service management?

Contact us at [email protected] for a consultation!