Differenza tra framework visuali e framework non visuali nella RPA
Framework visuali
I framework visuali sono dei prodotti, nati espressamente per la RPA, programmabili e gestibili quasi esclusivamente in modo grafico. La stragrande maggioranza di questi ha licenza commerciale e gira su sistema operativo Windows. Andare a descrivere in dettaglio cosa sono in grado di fare è abbastanza complicato ma in sostanza si prefiggono di automatizzare tutte le possibili interazioni di un utente con i programmi del computer, attraverso una serie di strumenti quasi sempre grafici e tendenzialmente semplici da usare per chi ha un minimo di dimestichezza con la programmazione; gli strumenti comuni più o meno a tutti i framework di questo tipo sono:
- l’ambiente di sviluppo – un ambiente predisposto per sviluppare l’automazione, attraverso la programmazione fatta in varie forme (come scripting proprietario o diagrammi a blocchi), anche con l’ausilio di oggetti preconfezionati, procedure guidate e utilità di vario genere, tra le quali quasi sempre si trovano:
- il registratore, che permette di registrare le azioni compiute dall’utente sui programmi tramite i dispositivi di input (mouse, tastiera, ecc.).
- l’esploratore di interfaccia, che permette di analizzare e selezionare porzioni di interfaccia dei programmi e trasformarle in “oggetti” del formato del framework che si possono successivamente referenziare, manipolare, parametrare, riutilizzare, ecc.
- gli esecutori, che sono gli interpreti dell’automazione RPA che, installati su uno o più computer, eseguono l’automazione che è stata sviluppata
- il gestore centralizzato, che è un programma centrale, quindi lato server, che permette di coordinare gli esecutori (schedulando e monitorando le esecuzioni), memorizzare dati da elaborare, parametri e dati comuni a più automazioni (spesso chiamati “asset”), gestire i permessi, le versioni, la distribuzione, la sicurezza delle automazioni ed altro ancora
Il vantaggio di tali framework è che offrono questa gamma di strumenti e oggetti predisposti a gestire i casi d’uso più frequenti e importanti in ambito RPA, accelerando notevolmente lo sviluppo e la messa in produzione degli automatismi. Il potenziale svantaggio principale, come per tutti i prodotti commerciali, è il vincolo a schemi e convenzioni proprie di tali prodotti. La questione più spinosa e paradossale, però, è che questi framework stanno stretti un po’ a tutte le categorie di utilizzatori e nessuna di queste, singolarmente, riesce a beneficiarne al massimo della potenzialità, anche per i motivi che cerco di spiegare a seguire. I produttori di questi framework indirizzano le aziende nel farli adoperare ad analisti (o comunque non a sviluppatori IT), asserendo che siano alla loro portata. In molte aziende, però, questi prodotti prudenzialmente si danno in mano a sviluppatori IT, dato che c’è di mezzo anche della programmazione vera e propria. Di qui in avanti descriverò una serie di problemi relativi a questa diatriba sui framework visuali e, per semplicità, chiamerò “n.i.” (non informatici, quindi tipicamente analisti funzionali) e “i.” (informatici, quindi tipicamente sviluppatori IT) queste due categorie di addetti ai lavori della RPA.
Un i. si potrebbe imbattere nell’utilizzo di nuovi linguaggi di scripting oppure di schemi a blocchi di tipo “workflow” che spesso limitano le capacità tecniche di chi vi deve operare. D’altro canto un n.i. potrebbe trarre vantaggio da alcune semplificazioni che in linea teorica permettono anche a chi non ha la dovute competenze di costruire automazioni. Ma il rovescio della medaglia è il seguente: tendenzialmente un n.i. affronterà lo sviluppo dell’automazione in modo semplicistico ed ottimistico, andando incontro a potenziali fallimenti in alcune circostanze, anche cruciali (per cui, ad esempio, non gestirebbe le eccezioni); un i., invece, avendo la professionalità di gestire le complessità e le eccezioni di un processo da costruire, potrebbe trovare difficoltà a barcamenarsi tra gli oggetti semplificati e schematici messi a disposizione dal framework. Altro svantaggio è che affidando ad un n.i. un framework visuale, proprio grazie alla dovizia di strumentazioni in dotazione, molte delle quali facili da usare, costui ne abusi quale surrogato di strumenti più idonei a determinati scopi. Altrettanto svantaggioso, infine, è considerare tali framework a prova di sostituibilità in corso d’opera della tipologia di sviluppatori. Nel caso in cui un’automazione sia stata sviluppata da n.i., infatti, un i. che subentri potrebbe dover rifare tutto se rileva gravi problemi di stabilità, correttezza e manutenibilità. Nel caso in cui un’automazione sia stata sviluppata da i., invece, questi potrebbero aver combinato in modo talmente articolato e complesso gli strumenti in dotazione che un n.i. subentrante non potrebbe mai gestirli ed anche un nuovo i. subentrante potrebbe avere difficoltà interpretative, proprio a causa dei predetti problemi di leggibilità e gestibilità.
Per arginare in parte le difficoltà fin qui elencate, si possono combinare vari approcci.
L’approccio fondamentale è quello di stabilire regole e modelli. Come già detto, infatti, i framework visuali permettono con estrema semplicità di creare e combinare tra loro raffiche di oggetti preconfezionati e, di pari passo, generare molta confusione e discrepanze di struttura tra un’automazione e l’altra. Fissando invece dei modelli e degli schemi predefiniti, spesso proposti anche dagli stessi framework, e fissando anche regole sugli oggetti da prediligere, sulla modularità, su nomi e tipi delle variabili, sulla modalità di acquisizione e scambio dati ecc., si mette ordine in partenza al potenziale caos. Un altro approccio, specifico per gli i. ed applicabile solo nei framework espandibili, è quello di creare librerie ed estensioni ad hoc e riusabili, tramite linguaggi di programmazione compatibili, nel caso in cui il framework non disponga di un oggetto adeguato per una determinata operazione semplice o nel caso in cui si debbano combinare un notevole numero di oggetti semplici del framework per effettuare operazioni complesse (a scapito di linearità e leggibilità). Un ultimo approccio utile e sempre valido è quello di limitare l’uso del framework solo allo scopo per cui è nato. Ad esempio, nel caso in cui una automazione al proprio avvio richieda una scelta iniziale interattiva, in base alla quale si stabiliscono i parametri da usare nei passi successivi, non conviene abusare del framework per creare eventuali maschere o per far sì che tali scelte debbano effettuarsi tramite la compilazione di un foglio elettronico da parte dell’utente finale (con il rischio di errori od omissioni). E’ più opportuno in tal caso creare un applicativo grafico che permetta di effettuare le scelte iniziali in modo guidato e controllato e dal quale scaturisca o l’avvio diretto dell’automazione (solitamente tramite un web service) o, tuttalpiù, l’esportazione di un file con i parametri da dare in input all’automazione.
Framework non visuali
I framework RPA non visuali sono quelli sui quali, di fatto, si basano i framework visuali. In altre parole, nella maggior parte dei casi, i framework visuali sono arricchimenti ed estensioni di Microsoft Ui Automation (nel caso dell’ambiente Windows). A loro volta, anche molti altri framework non visuali si basano su questo stesso framework non visuale. Si tratta in generale di librerie utilizzabili, spesso, tramite i più diffusi linguaggi di programmazione, quindi riservati solo a sviluppatori di professione. Vantaggi e svantaggi sono all’incirca speculari a quelli dei framework visuali. Lo svantaggio è di non avere oggetti riccamente predisposti che accelerino lo sviluppo ma solo oggetti di livello piuttosto basso che devono essere necessariamente combinati tra loro per poter ottenere risultati utili. Il vantaggio invece è quello che uno sviluppatore riesce ad avere pieno controllo e cognizione dei meccanismi che stanno dietro l’automazione dei quali invece, nei framework visuali, sarebbe all’oscuro e non potrebbe gestire appieno.
Questi framework non visuali sono nati a suo tempo per poter fare i test sulle interfacce e poi si sono diffusi anche per l’uso in ambito RPA ed in fin dei conti uno sviluppatore otterrebbe risultati più efficaci, efficienti ed affidabili con questi framework piuttosto che con quelli visuali. In ambiente Linux, peraltro, non esistono framework visuali e pertanto quelli non visuali risultano essere l’unica alternativa.
Probabilmente in grosse realtà aziendali tali framework non prendono molto piede, sebbene facciano risparmiare e, facendone buon uso, rendono di più di quelli visuali. Una possibile spiegazione è che, poiché tale categoria di framework è materia per professionisti, è più sensato (allargando la visione) che si impieghi un team di sviluppo professionale per l’informatica tradizionale piuttosto che per la RPA e di conseguenza si assegni la gestione di quest’ultima a non informatici oppure a sviluppatori meno d’esperienza. Ciò induce quindi ad optare per framework visuali che si pensa siano più alla loro portata ma la storia spiegata nel precedente paragrafo è un po’ più lunga.
