C’è un ciclo che si ripete in molte organizzazioni con una cadenza quasi prevedibile. Ogni tre, quattro anni arriva il momento in cui il sistema attuale non basta più. È lento, non si integra con quello che è arrivato dopo, costa troppo da mantenere. Si decide di cambiarlo.
Si compra qualcosa di nuovo. Si migra. Si forma il team. Si va in produzione.
E dopo qualche anno, il nuovo sistema ha gli stessi problemi del vecchio. Non si integra con quello che è arrivato dopo. Costa troppo da mantenere. Il ciclo ricomincia.
Il problema non è il sistema scelto. È il modo in cui è stato progettato.
Perché i sistemi invecchiano prima del previsto
Un sistema software non diventa obsoleto perché la tecnologia avanza. Diventa obsoleto perché è stato progettato per rispondere a un insieme di requisiti fissi, quelli che esistevano nel momento in cui è stato costruito, e non è stato pensato per evolvere quando quei requisiti cambiano.
Ogni integrazione che si aggiunge dopo è un rattoppo. Ogni nuovo processo che il sistema deve supportare richiede un intervento custom. Ogni evoluzione del business diventa un progetto IT. E ogni progetto IT su un’architettura rigida è più costoso, più rischioso e più lento del precedente, perché il sistema è diventato più complesso, non più capace.
La rigidità non è una caratteristica dei sistemi vecchi. È una caratteristica dei sistemi progettati senza pensare al cambiamento. Ed è proprio da questa osservazione che nasce il concetto di architettura componibile.
Cosa significa architettura componibile
L’architettura componibile parte da una domanda diversa rispetto a quella che si fa di solito quando si progetta un sistema. Non “cosa deve fare questo sistema oggi?” ma “come farà questo sistema a fare cose diverse domani?”
La risposta è costruire il sistema come un insieme di componenti indipendenti, ciascuno con una responsabilità precisa, interfacce definite, e la capacità di essere sostituito, aggiornato o integrato senza toccare tutto il resto.
Un esempio concreto: un’azienda decide di sostituire il proprio CRM perché il business richiede funzionalità che il sistema non offre più. In un sistema fortemente accoppiato, questo significa riscrivere integrazioni con ERP, portale clienti, marketing automation e sistemi di reporting: un progetto che coinvolge tutto e blocca tutto. In un’architettura componibile, se il CRM comunica attraverso interfacce stabili, la sostituzione riguarda il solo componente CRM: gli altri sistemi continuano a funzionare senza modifiche sostanziali.
La differenza non è nella tecnologia usata. È nel modo in cui i componenti sono stati progettati per comunicare tra loro.
Nei sistemi con componenti strettamente dipendenti, le connessioni tendono ad aumentare nel tempo, rendendo ogni modifica sempre più estesa e difficile da isolare. In un sistema componibile, ogni cambiamento è circoscritto al componente che si sta modificando, perché le interfacce tra i componenti sono stabili, anche quando i componenti cambiano.
Perché non basta comprare un sistema “flessibile”
Molti vendor vendono flessibilità. Piattaforme configurabili, moduli aggiuntivi, integrazioni native con i principali sistemi del mercato. E spesso, nei primi anni, quella flessibilità è reale.
Il problema arriva quando le esigenze escono dal perimetro di quello che il vendor aveva previsto. Quando serve un’integrazione che non è in catalogo. Quando un processo aziendale non corrisponde a nessuno dei workflow preconfigurati. Quando si vuole sostituire un modulo con qualcosa di più adatto e si scopre che i dati, la logica e le interfacce sono così intrecciati che separare un pezzo significa smontare tutto.
La flessibilità venduta da un vendor è flessibilità entro i confini che quel vendor ha immaginato. La flessibilità architetturale è la capacità di cambiare qualsiasi cosa, indipendentemente da quello che il vendor aveva previsto.
Non è la stessa cosa. E la differenza non emerge nei primi anni. Emerge esattamente quando il business cambia in un modo che nessuno aveva previsto, che è sempre.
Il costo che non appare nei budget
Quando si parla di sistemi rigidi, il costo più visibile è quello della manutenzione: le ore necessarie per mantenere in piedi integrazioni fragili, gli interventi custom che si accumulano, il debito tecnico che cresce. Ma il costo più elevato è spesso quello dell’immobilità.
Se ogni nuova esigenza di business richiede mesi di analisi, sviluppo e test prima di poter essere implementata, il sistema non è solo costoso da mantenere: è un limite alla capacità competitiva dell’organizzazione. Ogni cambiamento diventa un progetto con tempi e costi che spesso superano il valore del cambiamento stesso. E nel frattempo, il mercato non aspetta.
Le organizzazioni che riescono a rispondere rapidamente ai cambiamenti non sono quelle con i budget IT più alti. Sono quelle i cui sistemi rendono il cambiamento ordinario invece che straordinario.
Dove si decide se un sistema sarà flessibile
La flessibilità di un sistema non si decide quando serve cambiare qualcosa. Si decide quando il sistema viene progettato: nella scelta di come i componenti comunicano tra loro, come i dati sono strutturati, come le interfacce sono definite.
Un sistema costruito con dipendenze pervasive non diventa componibile aggiungendo un layer di integrazione sopra. Le dipendenze sono già dentro, incorporate nelle scelte architetturali iniziali. Rimuoverle richiede un intervento che, nella maggior parte dei casi, equivale a ricostruire il sistema.
Questo è il motivo per cui il ciclo si ripete. Non perché le organizzazioni scelgano male i sistemi. Ma perché scelgono sistemi senza aver progettato la flessibilità che servirà tre anni dopo.
Cosa cambia quando si progetta per il cambiamento
Le organizzazioni che escono da questo ciclo non cercano il sistema perfetto. Progettano sistemi che possono evolvere.
La differenza operativa è concreta. Invece di sostituire un sistema ogni tre anni con un progetto da milioni di euro, si sostituiscono componenti specifici quando non rispondono più alle esigenze, senza toccare quello che funziona, senza bloccare l’operatività, senza ricominciare da capo.
Non è un approccio più costoso. Nel tempo, è molto meno costoso, perché il costo del cambiamento diminuisce invece di crescere ad ogni ciclo.
I sistemi non dovrebbero essere progettati per durare dieci anni. Dovrebbero essere progettati per cambiare per dieci anni.
Perché la vera longevità di un sistema non dipende da quanto resiste al cambiamento, ma da quanto rende semplice cambiare.