Applicazioni aziendali CRUD

Dagli anni ‘80, la stragrande maggioranza delle applicazioni aziendali ha adottato un design interno simile, chiamato CRUD, che sta per Create / Read / Update / Delete. Questo design riflette l’adozione di un database relazionale per persistere i dati aziendali. Il design CRUD ha resistito a diversi grandi balzi tecnologici, dai terminali console collegati ai mainframe alle app mobili collegate alle piattaforme cloud. Comprendere il design CRUD è importante in campi complessi - come la supply chain - che operano tipicamente su un intero panorama applicativo composto da app CRUD. Questa conoscenza è fondamentale per navigare correttamente in questo panorama, dalla negoziazione con i fornitori di software allo sfruttamento delle voci di dati raccolte attraverso tutte queste app.

Panoramica

All’inizio degli anni ‘80, i database relazionali sono emersi come l’approccio dominante per memorizzare e accedere ai dati aziendali. Alla fine degli anni ‘90, i database relazionali open-source emergenti hanno ulteriormente consolidato questa pratica. Oggi, il design CRUD riflette l’approccio più diffuso per sviluppare un’applicazione aziendale su un database relazionale.

Un database, nel senso relazionale, include un elenco di tabelle. Ogni tabella include un elenco di colonne (anche chiamate campi). Ogni campo ha un tipo di dato: numero, testo, data, ecc. Una tabella contiene un elenco di righe (anche chiamate record). Come regola generale, ci si aspetta che il numero di colonne rimanga limitato, al massimo qualche centinaio, mentre il numero di righe è illimitato, potenzialmente raggiungendo miliardi.

Figura 1: una semplice tabella che riflette un elenco di prodotti e la loro situazione di inventario, illustrativa di ciò che si trova tipicamente in un database relazionale.

Nella pratica, l’approccio relazionale richiede diverse tabelle per riflettere qualcosa di interesse aziendale (ad esempio, ordini di acquisto). Questi “raggruppamenti” di tabelle sono chiamati entità. Un’entità riflette la comprensione a livello superiore del business.

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

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

• Create: aggiungere nuove righe alla tabella.
• Read: recuperare righe esistenti dalla tabella.
• Update: modificare righe esistenti nella tabella.
• Delete: eliminare righe esistenti dalla tabella.

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

Il design CRUD consiste nell’introdurre entità insieme ai loro controparti di interfaccia utente, generalmente chiamate “schermate”. Una schermata, che può essere una pagina web, di solito presenta le 4 operazioni per l’entità di interesse.

La stragrande maggioranza delle app aziendali “transazionali”, da un semplice tracker di tempo a un ERP o CRM molto complesso, adotta un design CRUD simile sotto il cofano, un pattern di design stabilito più di 4 decenni fa. Le app semplici presentano solo poche entità, mentre quelle complesse possono presentarne migliaia. Tuttavia, da semplice a complesso, in termini di design intrinseco, è sempre più dello stesso.

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

App CRUD nella supply chain

Quasi tutte le app (esposte agli utenti finali) 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 sempre implementato come CRUD. L’eccezione più nota a questa regola sono gli editor di documenti (ad esempio, software di fogli di calcolo), che rappresentano un tipo di tecnologia software completamente diverso.

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

Tali app CRUD contengono quasi tutti i dati storici transazionali rilevanti che possono essere sfruttati per migliorare quantitativamente la supply chain (ad esempio, ottimizzare i livelli di stock). Di conseguenza, molte app CRUD cercano¹, a un certo punto, di estendere le loro capacità analitiche (ad esempio, per scopi di pianificazione o ottimizzazione). Purtroppo, sebbene CRUD presenti numerosi vantaggi, presenta anche gravi limitazioni per quanto riguarda le capacità analitiche (vedi “I limiti di CRUD” di seguito).

I vantaggi di CRUD

CRUD è stato l’approccio preferito per le app aziendali per decenni. Dal punto di vista tecnologico, questo approccio beneficia di framework e strumenti open-source completi in tutte le principali stack software. Di conseguenza, il percorso tecnologico è eccezionalmente ben definito. Inoltre, 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 su CRUD.

Dal punto di vista del personale, c’è un ampio mercato di ingegneri del software esperti in CRUD. Inoltre, CRUD è una delle parti più accessibili dell’ingegneria del software, in gran parte grazie ai suoi strumenti di sviluppo di alta qualità. Di conseguenza, CRUD è estremamente accessibile anche per gli ingegneri del software junior (e per quelli senior meno talentuosi). Poiché i principi CRUD sottostanti sono stabili da decenni, la transizione verso uno stack tecnologico più recente può essere fatta con relativa facilità, almeno rispetto ad altri approcci più tecnologicamente avanzati.

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

I limiti di CRUD

Le app CRUD presentano limitazioni intrinseche legate al modo in cui sfruttano internamente il database relazionale al loro nucleo. Queste limitazioni non possono essere superate senza rinunciare fondamentalmente ai vantaggi associati a CRUD. Queste limitazioni rientrano in due categorie principali: espressività e prestazioni.

Il limite di espressività riflette il fatto che le quattro azioni (o “verbi”) - creare, leggere, aggiornare ed eliminare - non possono catturare correttamente una gamma più granulare di intenzioni. Ad esempio, consideriamo una situazione in cui un dipendente cerca di eliminare diverse voci di fornitore create per errore all’interno del SRM (Supplier Relationship Manager). Il verbo appropriato per questa operazione sarebbe “unire”. Tuttavia, il design CRUD non ha questo verbo. In realtà, questa capacità viene invariabilmente implementata come un processo in due fasi. Prima, si aggiornano tutte le righe che puntavano alle voci di fornitore che verranno presto eliminate, in modo che puntino ora a quella da conservare. Secondo, si eliminano tutte le voci di fornitore extra tranne una. Non solo l’intento originale (la fusione) viene perso, ma la trasformazione è distruttiva in termini di dati. Aneddoticamente, quando le app CRUD avvertono gli utenti che stanno per apportare un cambiamento irreversibile ai dati, è quasi sempre una limitazione di CRUD² che si sta intromettendo nell’esperienza dell’utente.

Il limite delle prestazioni riflette il fatto che qualsiasi operazione a lungo termine - cioè, qualsiasi operazione che legge più di una piccola frazione del database - mette l’app CRUD a rischio di diventare non reattiva. Infatti, per un’app CRUD, gli utenti finali si aspettano che la latenza sia appena percettibile per quasi tutte le operazioni banali. 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 assegnate all’app CRUD consumano risorse di calcolo dallo stesso database relazionale sottostante, quasi ogni operazione non banale mette a rischio il nucleo stesso di essere privato di risorse di calcolo. Aneddoticamente, nelle grandi aziende, le app CRUD diventano comunemente non reattive per secondi (anche minuti) alla volta. Queste situazioni sono quasi sempre causate da alcune operazioni “pesanti” che finiscono per monopolizzare le risorse di calcolo per una breve durata, ritardando così tutte le altre operazioni, comprese quelle “leggere”. Questo problema spiega perché le operazioni non banali di solito vengono separate in lavori batch che vengono eseguiti di notte. Spiega anche perché le app CRUD sono tipicamente poco adatte all’analisi, dato che i carichi di lavoro analitici sono impraticabili da eseguire solo al di fuori dell’orario di ufficio.

Le moderne varianti di 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 è passata da interfacce utente desktop a interfacce utente web. Negli ultimi dieci anni circa, la maggior parte delle app si è orientata verso SaaS (software come servizio) e si è spostata verso cloud computing nel processo. Tuttavia, il design CRUD è rimasto in gran parte intatto in queste evoluzioni.

La transizione da una singola locazione a una multi-locazione³ ha costretto i fornitori di software a limitare l’accesso ai dati delle entità dietro le API (Interfacce di Programmazione delle Applicazioni). Infatti, l’accesso diretto al database, anche se in sola lettura, crea la possibilità di affamare le risorse di calcolo del core transazionale attraverso un numero limitato di richieste pesanti. L’API mitiga questi tipi di problemi. Limitare l’accesso ai dati dell’app dietro un’API annulla anche alcuni dei vantaggi del CRUD, almeno per quanto riguarda l’azienda cliente. Estrarre in modo affidabile molti dati da un’API richiede tipicamente più sforzo rispetto alla composizione di una serie comparabile di query SQL. Inoltre, l’API potrebbe essere incompleta, non esponendo dati che esistono nell’app, anche se il database diretto dovrebbe aver garantito un accesso completo ai dati per design.

L’evoluzione principale del CRUD si trova negli strumenti. Durante gli anni 2010, è emersa una vasta varietà di ecosistemi open-source di alta qualità per supportare lo sviluppo di app CRUD. Questi ecosistemi hanno ampiamente reso le app CRUD una merce comune, riducendo notevolmente le competenze necessarie per svilupparle e riducendo gli attriti associati al processo di sviluppo.

Dinamiche dei fornitori

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

L’aggiunta di entità sblocca nuove funzionalità e dà al fornitore l’opportunità di aumentare i prezzi, riflettendo il valore aggiunto per l’azienda cliente. Inoltre, i moduli⁴, ovvero raggruppamenti di entità correlate al business, vengono spesso 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 vengono aggiunte nuove entità per servire gli interessi dell’intera base clienti, molte (se non la maggior parte) delle entità appena introdotte non sono rilevanti per nessuna singola azienda cliente. Queste entità “morte” - dal punto di vista dell’azienda cliente - rappresentano una crescente complessità accidentale 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 fornitori emergono frequentemente, ognuno concentrato 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 fornitori di software aziendale che le vendono, il costo di sviluppo è solo una piccola frazione della spesa totale dell’azienda, molto dietro ai costi legati al marketing e alla vendita delle app stesse. In particolare, i fornitori che sviluppano app CRUD spesso delocalizzano i loro team di ingegneria in paesi a basso costo, poiché l’approccio CRUD (dato il suo accesso globale) può tollerare una forza lavoro meno talentuosa - e meno costosa.

Oggi non c’è molto motivo di pagare cifre considerevoli per le app CRUD. Come regola generale, qualsiasi app CRUD che costa più di 250.000 USD all’anno è un serio candidato per la sostituzione con un software interno. Qualsiasi app CRUD che costa più di 2,5 milioni di USD all’anno dovrebbe, quasi senza eccezioni, essere sostituita da un software interno (possibilmente partendo da una base di codice preesistente open-source e personalizzando da lì).

I fornitori di software aziendale che vendono app CRUD sono ben consapevoli di questo problema (e lo sono da molto tempo). Pertanto, è tentatore per il fornitore aggiungere funzionalità/app/elementi non-CRUD⁶ alla soluzione e cercare di convincere i clienti (a) che queste parti sono importanti e (b) che queste parti rappresentano una sorta di “salsa segreta” che il cliente non sarà in grado di replicare. Tuttavia, questo approccio quasi mai ha successo, principalmente perché il fornitore non ha il DNA di ingegneria giusto⁷. A titolo di prova aneddotica, quasi tutti gli ERP noti e consolidati hanno ampie capacità di previsione e pianificazione, la maggior parte delle quali rimangono in gran parte inutilizzate a causa delle loro scarse prestazioni in queste attività.

Lokad è un fornitore di software aziendale specializzato nell’ottimizzazione predittiva della supply chain. La nostra tecnologia è stata progettata per sfruttare i dati transazionali storici - quelli che possono essere estratti dalle app CRUD che supportano le operazioni quotidiane di un’azienda. Tuttavia, Lokad stesso non è un’app CRUD. Il nostro ambiente di produzione non include nemmeno un database relazionale. Mentre CRUD è una risposta tecnologica valida per la gestione dei flussi di lavoro transazionali di un’azienda, non ha alcuna rilevanza per la modellazione predittiva o l’ottimizzazione matematica di una supply chain.

Note