App CRUD aziendali

Dagli anni ‘80, la stragrande maggioranza delle app aziendali ha adottato un design interno simile, ovvero il CRUD, che sta per Create / Read / Update / Delete. Questo design riflette l’adozione di un database relazionale per la persistenza dei dati aziendali. Il design CRUD ha resistito a diversi grandi salti tecnologici, dai terminali console collegati ai mainframe alle app mobile connesse a piattaforme cloud. Comprendere il design CRUD è importante in settori complessi - come supply chain - che tipicamente operano su un intero panorama applicativo composto da app CRUD. Tale comprensione è fondamentale per navigare correttamente questo panorama, dalla negoziazione con i software vendors all’utilizzo delle voci di dati raccolte attraverso tutte queste app

Panoramica

All’inizio degli anni ‘80, i database relazionali erano emersi come l’approccio dominante per memorizzare e accedere ai dati aziendali. Entro la fine degli anni ‘90, i database relazionali open-source emergenti avevano ulteriormente consolidato questa pratica. Oggigiorno, il design CRUD riflette l’approccio più diffuso per progettare un’app aziendale su un database relazionale.

Un database, nel senso relazionale, include una lista di tabelle. Ogni tabella include una lista di colonne (chiamate anche campi). Ogni campo ha un tipo di dato: numero, testo, data, ecc. Una tabella contiene una lista di righe. In linea di massima, il numero di colonne dovrebbe rimanere limitato, al massimo poche centinaia, mentre il numero di righe è illimitato, potenzialmente raggiungendo miliardi.

Figura 1: una tabella semplice che riflette un elenco di prodotti e la loro situazione d'inventario, esemplare di quanto si trova tipicamente in un database relazionale.

In pratica, l’approccio relazionale richiede diverse tabelle per riflettere qualcosa di rilevante per il business (ad es., ordini di acquisto). Questi raggruppamenti di tabelle sono chiamati entità. Un’entità riflette la comprensione ad alto livello del business.

Figura 2: un'entità "carrello della spesa" semplice composta da due tabelle. Questa entità riflette lo stato del carrello per il visitatore di un sito ecommerce.

Come menzionato sopra, CRUD si riferisce a Create, Read, Update e Delete, le 4 operazioni fondamentali da eseguire sulle tabelle all’interno di un database relazionale.

• Create: aggiungi nuove righe alla tabella.
• Read: recupera le righe esistenti dalla tabella.
• Update: modifica le righe esistenti nella tabella.
• Delete: elimina le righe esistenti dalla tabella.

Queste operazioni vengono eseguite attraverso un linguaggio di database dedicato, quasi sempre un dialetto SQL (Structured Query Language) al giorno d’oggi.¹

Il design CRUD consiste nell’introdurre entità insieme ai loro corrispettivi nell’interfaccia utente, tipicamente chiamati “screens”. Uno screen, che può essere una pagina web, presenta solitamente le 4 operazioni per l’entità di interesse.

La stragrande maggioranza delle app aziendali “transazionali”, da un semplice tracker del tempo a un molto complesso ERP o CRM, adotta un design CRUD simile alla base - un pattern di design stabilito più di 4 decenni fa. Le app semplici presentano solo poche entità, mentre quelle complesse ne possono avere migliaia. Tuttavia, dal semplice al complesso, in termini di design intrinseco, è semplicemente più o meno lo stesso.

La diversità delle interfacce utente, come si trova tra le app aziendali, può essere fuorviante nel senso che sembra che le app abbiano ben poco in comune. Tuttavia, in pratica, la maggior parte delle app ha un design interno quasi identico allineato con la prospettiva CRUD.

App CRUD nella supply chain

Quasi tutte le app (destinate agli utenti finali) che vengono utilizzate per gestire le aziende e i loro processi sono CRUD. In generale, se un software aziendale beneficia di un acronimo di 3 lettere come ERP, MRP, CRM, SRM, PLM, PIM, WMS, OMS, EDI (ecc.), allora è quasi invariabilmente implementato come CRUD. L’eccezione più notevole a questa regola sono gli editor di documenti (ad es., software per fogli di calcolo), che rappresentano un tipo completamente diverso di tecnologia software.

Internamente, il dipartimento IT utilizza una vasta gamma di tecnologie che non sono CRUD: networking, virtualizzazione, strumenti per amministratori di sistema, ecc. Tuttavia, queste tecnologie tendono ad essere in gran parte invisibili, o quantomeno non intrusive, per gli utenti finali.

Tali app CRUD contengono quasi tutti i dati transazionali storici rilevanti che possono essere sfruttati per migliorare quantitativamente la supply chain (ad esempio, ottimizzando i livelli di stock). Di conseguenza, molte app CRUD tentano², a un certo punto, di sviluppare capacità analitiche (come per scopi di pianificazione o ottimizzazione). Sfortunatamente, sebbene il CRUD presenti numerosi vantaggi, presenta anche brutali carenze per quanto riguarda le capacità analitiche (vedi “I limiti del CRUD” qui sotto).

I vantaggi del CRUD

Il CRUD è stato l’approccio di riferimento per le app aziendali per decenni. Dal punto di vista tecnologico, questo approccio beneficia di framework e strumenti open-source completi in tutti i principali stack software. Di conseguenza, il percorso tecnologico è eccezionalmente ben definito. Inoltre, il CRUD beneficia anche di strumenti di sviluppo di alta qualità e, di conseguenza, la produttività tende ad essere elevata per gli ingegneri del software coinvolti nello sviluppo di un’app basata sul CRUD.

Dal punto di vista delle risorse umane, esiste un vasto mercato di ingegneri del software esperti di CRUD. Inoltre, il CRUD è tra le parti più accessibili dell’ingegneria del software – in gran parte grazie ai suoi strumenti di sviluppo di alta qualità. Di conseguenza, il CRUD è estremamente accessibile anche per gli ingegneri del software junior (e per quelli senior meno talentuosi). Poiché i principi fondamentali del CRUD sono stabili da decenni, il passaggio a uno stack tecnologico più recente può essere effettuato con relativa facilità – almeno rispetto ad altri approcci più orientati alla tecnologia.

Infine, dal punto di vista della continuità aziendale, il CRUD offre tutti i vantaggi associati al suo database relazionale sottostante. Ad esempio, finché il database è accessibile all’azienda cliente, i dati rimarranno accessibili; ciò è valido anche se il vendor originale dell’app CRUD non è più operativo o collaborativo con l’azienda cliente. Anche in questo caso estremo, l’accessibilità ai dati è raggiungibile con modesti sforzi di reverse engineering.

I limiti del CRUD

Le app CRUD si trovano ad affrontare limitazioni intrinseche associate al modo in cui sfruttano internamente il database relazionale alla loro base. Queste limitazioni non possono essere superate senza rinunciare fondamentalmente ai benefici stessi del CRUD. Queste limitazioni si suddividono in due ampie categorie: espressività e prestazioni.

La limitazione in termini di espressività riflette il fatto che le quattro azioni (o “verbi”) – create, read, update e delete – non possono catturare adeguatamente una gamma più granulare di intenzioni. Ad esempio, considera una situazione in cui un dipendente cerca di deduplicare diversi record di fornitori che sono stati creati per errore all’interno del SRM (Supplier Relationship Manager). Il verbo appropriato per questa operazione sarebbe merge. Tuttavia, il design CRUD non prevede questo verbo. In effetti, tale capacità viene invariabilmente implementata come un processo in due fasi. Prima, aggiornare tutte le righe che puntavano ai record dei fornitori che presto saranno eliminati, in modo che ora puntino a quello da conservare. Secondo, eliminare tutte tranne una delle voci extra dei fornitori. Non solo l’intento originale (il merge) si perde, ma la trasformazione è distruttiva in termini di dati. In via aneddotica, quando le app CRUD avvertono i loro utenti che stanno per apportare un cambiamento irreversibile ai dati, è quasi sempre una limitazione del CRUD³ a interferire con l’esperienza utente.

La limitazione in termini di prestazioni riflette il fatto che qualsiasi operazione a lunga durata – cioè, qualsiasi operazione che legge più di una minima frazione del database – mette a rischio l’app CRUD di diventare non responsiva. Infatti, per un’app CRUD, gli utenti finali si aspettano che la latenza sia a malapena percepibile per quasi tutte le operazioni di routine. Ad esempio, l’aggiornamento di un livello di stock nel WMS (Warehouse Management System) dovrebbe avvenire in millisecondi (per mantenere le operazioni fluide). Poiché tutte le operazioni affidate all’app CRUD consumano risorse informatiche dallo stesso database relazionale sottostante, quasi qualsiasi operazione non banale mette a rischio questo nucleo, facendolo restare a corto di risorse computazionali. In via aneddotica, nelle grandi aziende, le app CRUD comunemente diventano non responsivi per secondi (o anche minuti) alla volta. Queste situazioni sono quasi invariabilmente causate da alcune operazioni “pesanti” che finiscono per monopolizzare le risorse computazionali per brevi periodi, ritardando così tutte le altre operazioni - incluse quelle " leggere". Questo problema spiega perché le operazioni non banali sono solitamente segregate in job batch che girano di notte. Spiega anche perché le app CRUD sono tipicamente pessime in termini di analisi, dato che eseguire carichi di lavoro analitici risulta impraticabile se fatto solo fuori dall’orario di ufficio.

Varianti moderne del CRUD

Negli ultimi decenni, il software aziendale ha subito evoluzioni sostanziali. Negli anni ‘90, la maggior parte delle app è passata da terminali console a interfacce utente desktop. Negli anni 2000, la maggior parte delle app ha fatto il passaggio dalle interfacce desktop a quelle web. Negli ultimi dieci anni circa, la maggior parte delle app ha adottato il modello SaaS (software as a service) e si è migrata verso il cloud computing. Tuttavia, il design CRUD è rimasto in gran parte intatto da queste evoluzioni.

Il passaggio da una singola locazione (single tenancy) a una multi-locazione (multi-tenancy)⁴ ha costretto i vendor di software a limitare gli accessi ai dati delle entità tramite API (Application Programming Interfaces). Infatti, l’accesso diretto al database, anche se in sola lettura, crea la possibilità di esaurire le risorse computazionali del nucleo transazionale tramite un piccolo numero di richieste pesanti. L’API mitiga questo tipo di problemi. Limitare l’accesso ai dati dell’app tramite un’API elimina anche alcuni dei benefici del CRUD, almeno per quanto riguarda l’azienda cliente. Estrarre in modo affidabile una grande quantità di dati da un’API richiede tipicamente più sforzo che comporre una serie comparabile di query SQL. Inoltre, l’API potrebbe essere incompleta – non esponendo dati che esistono nell’app – anche se il database diretto avrebbe dovuto garantire un accesso completo ai dati per progettazione.

L’evoluzione principale del CRUD si trova negli strumenti di supporto. Durante gli anni 2010, è emersa una vasta gamma di ecosistemi open-source di alta qualità per supportare lo sviluppo delle app CRUD. Questi ecosistemi hanno ampiamente commoditizzato lo sviluppo delle app CRUD, riducendo notevolmente le competenze necessarie per svilupparle e diminuendo le difficoltà associate al processo di sviluppo.

Dinamiche dei vendor

Il costo di sviluppo di un’app CRUD è in gran parte determinato dal numero di entità. Maggiore è il numero di entità, più schermate vanno sviluppate, documentate e mantenute. Pertanto, il percorso naturale per un vendor di software che promuove un’app CRUD consiste nel partire con un numero limitato di entità e, col tempo, aggiungerne altre.

L’aggiunta di entità sblocca nuove capacità e offre al vendor l’opportunità di aumentare i prezzi, riflettendo il valore aggiunto creato per l’azienda cliente. Inoltre, i moduli⁵, ovvero raggruppamenti di entità legate al business, vengono frequentemente introdotti come meccanismo di prezzo per addebitare di più (a seconda dell’estensione dell’utilizzo del prodotto software).

Di conseguenza, le app CRUD tendono a diventare più complesse nel tempo, ma anche meno rilevanti. Infatti, man mano che nuove entità vengono aggiunte per servire l’interesse dell’intera base clienti, molte (se non la maggior parte) delle nuove entità introdotte non sono rilevanti per nessuna azienda cliente individuale. Queste entità “morte” – dal punto di vista dell’azienda cliente – rappresentano una complessità accidentale in crescita che inquina il CRUD.

Le app CRUD vendute come SaaS tendono a diventare più costose man mano che crescono in capacità e notorietà. Tuttavia, poiché ci sono pochissime barriere all’ingresso⁶, nuovi vendor emergono frequentemente, ognuno concentrandosi su casi d’uso a prezzi molto più bassi - e il ciclo si ripete all’infinito.

Il punto di vista di Lokad

Molte, se non la maggior parte, delle grandi aziende sottovalutano l’entità della commoditizzazione delle app CRUD. Per la maggior parte dei vendor di software aziendale che le vendono, il costo di sviluppo rappresenta solo una piccola frazione della spesa totale dell’azienda, ben al di sotto dei costi legati al marketing e alla vendita delle app stesse. In particolare, i vendor che sviluppano app CRUD frequentemente delocalizzano i loro team di ingegneria in paesi a basso costo, poiché l’approccio CRUD (dato la sua accessibilità complessiva) può tollerare una forza lavoro ingegneristica meno talentuosa - e meno costosa.

Al giorno d’oggi, c’è ben poca ragione per pagare importi elevati per app CRUD. Come regola generale, qualsiasi app CRUD che costa oltre 250k USD all’anno è una seria candidata per essere sostituita da software interno. Qualsiasi app CRUD che costa oltre 2,5M USD all’anno dovrebbe, quasi senza eccezioni, essere sostituita da software interno (possibilmente partendo da una base open-source preesistente e personalizzandola).

I vendor di software aziendale che vendono app CRUD sono molto consapevoli di questo problema (e lo sono da molto tempo). Pertanto, è allettante per il vendor aggiungere funzionalità/app/elementi non-CRUD⁷ alla soluzione e cercare di convincere i clienti (a) che questi elementi sono importanti e (b) che rappresentano una sorta di “salsa segreta” che il cliente non sarà in grado di replicare. Tuttavia, questo approccio quasi non riesce mai, principalmente perché il vendor non ha il giusto DNA ingegneristico⁸. A titolo aneddotico, quasi tutti gli ERP notabili e consolidati dispongono di estese capacità di previsione e pianificazione, quasi tutte delle quali rimangono per lo più inutilizzate data la loro scarsa efficienza nell’eseguire tali compiti.

Lokad è un fornitore di software enterprise specializzato nell’ottimizzazione predittiva della supply chain. La nostra tecnologia è stata progettata per sfruttare i dati transazionali storici – quel tipo di dati che possono essere estratti dalle app CRUD che supportano le operazioni quotidiane di un’azienda. Tuttavia, Lokad non è un’app CRUD. Il nostro ambiente di produzione non include nemmeno un database relazionale. Sebbene CRUD rappresenti una risposta tecnologica valida per la gestione dei flussi di lavoro transazionali di un’azienda, non ha alcuna rilevanza né per la modellizzazione predittiva né per l’ottimizzazione matematica della supply chain.

Note