Sarà il tuo patrimonio di database pronto se la velocità di sviluppo aumenta di un ordine di grandezza?

Gli strumenti assistiti da intelligenza artificiale hanno aumentato la velocità e ridotto il costo della produzione di codice. Tuttavia, i leader aziendali si chiedono perché questa efficienza non si traduce in innovazione superiore e in un tempo di mercato più veloce. Invece di accelerare l’intero ciclo di consegna, questo aumento di velocità ha semplicemente esposto la fragilità dei processi di modifica del database esistenti.

Negli ultimi dieci anni, la risposta a “come possiamo muoverci più velocemente?” è stata quella di costruire pipeline migliori, investire in CI/CD e spostare a sinistra i test. Questi investimenti hanno dato i loro frutti: il codice dell’applicazione si muove a un ritmo notevole nelle organizzazioni di ingegneria mature. Tuttavia, questi guadagni non sono stati percepiti in modo uniforme in tutto lo stack tecnologico. Il database è stato spesso trattato come un caso speciale; un asset protetto che richiede uno standard di cura diverso, processi più lenti e un controllo manuale. C’erano buone ragioni per cui questo modello si è sviluppato, poiché i database contengono i dati sui quali l’azienda si basa e gli errori possono essere catastrofici. Mentre una volta la prudenza sembrava ragionevole, il costo di quella prudenza è cambiato. Aumentando la pressione sui DBA e sui team operativi per apportare modifiche al database allo stesso ritmo dei developer, la disparità nello stack è diventata un vincolo. Questi team non possono tenere il passo e le modifiche al database stanno uccidendo il vantaggio di velocità fornito dagli strumenti assistiti da intelligenza artificiale. Risolvere un vincolo – il tempo necessario per scrivere il codice – ha semplicemente evidenziato il prossimo collo di bottiglia nel processo. Si tratta di pensiero sistemico portato alla vita e l’attrito risultante sta diventando sempre più doloroso per l’azienda.

La velocità e il controllo non sono opposti. Ma il modo in cui la maggior parte delle organizzazioni governa la modifica del database li tratta come se lo fossero.

Il modello tradizionale di governance del database è stato progettato per un mondo di rilasci trimestrali. Richieste di modifica, comitati di approvazione, cicli di revisione manuale, piani di rollback scritti in anticipo dei deploy che avvengono quattro volte all’anno. Niente di tutto ciò è intrinsecamente sbagliato. Si trattava di una gestione del rischio che è cresciuta per adattarsi al tempo disponibile nel tempo tra i deploy. Il problema è che la cadenza dei deploy è cambiata e, per la maggior parte delle organizzazioni, l’approccio di governance non ha tenuto il passo. I team sono tenuti a consegnare in modo continuo, ma ancora instradano le modifiche al database attraverso processi costruiti per un’era diversa. Il risultato non è la sicurezza. Il risultato è l’attrito, i lavori intorno e una classe crescente di “piccole” modifiche al database che bypassano la governance del tutto perché il processo formale è troppo lento per essere pratico.

È lì che vive il vero rischio.

Quando la governance è troppo lenta per essere utilizzata, le persone smettono di utilizzarla. Le modifiche dello schema vengono applicate direttamente in produzione. Le patch di hotfix vengono rilasciate senza controllo versione e con l’intenzione di spingerle attraverso la prossima release formale, ma ciò non accade perché le persone sono occupate. I passaggi manuali che dovevano essere la rete di sicurezza diventano la cosa che le persone aggirano quando sono sotto pressione. E la pressione, nella consegna del software, è lo stato predefinito.

La risposta non è rallentare la pipeline. È spostare la governance all’interno di essa.

Le organizzazioni che hanno risolto questo problema non lo hanno fatto rilassando i loro standard. Hanno fatto il lavoro più difficile di rendere la governance abbastanza veloce da essere il percorso più breve. Le modifiche dello schema controllate dalle versioni, la rilevazione automatica della deriva, i controlli di politica deterministici incorporati nella pipeline CI/CD piuttosto che applicati come un gate alla fine. Mentre gli strumenti guidati da intelligenza artificiale sono probabilistici – offrono suggerimenti basati su modelli – la governance deve rimanere deterministica per essere efficace. Utilizzando controlli prevedibili e ripetibili, si assicura che ogni modifica sia tracciabile e soddisfi gli standard di sicurezza prima di raggiungere la produzione. L’approvazione avviene ancora. La traccia di audit esiste ancora. Ma avviene nello stesso flusso di tutto il resto, piuttosto che come un processo separato e più lento che si trova al di fuori di esso.

Ciò è importante per una ragione al di là della produttività dei developer. I requisiti di conformità non stanno diventando più leggeri. La combinazione di GDPR, DORA (Atto di resilienza operativa digitale dell’UE) e una gamma crescente di regolamenti specifici del settore significa che la governance del database è sempre più una questione legale e regolamentare, non solo operativa. Le organizzazioni che non possono dimostrare una storia tracciabile e tracciabile di modifica del database sono esposte in modi che stanno diventando materiali. L’argomento per incorporare la governance nella pipeline non è solo che rende la consegna più veloce. È ciò che rende la conformità tracciabile su larga scala.

L’intelligenza artificiale sta aggravando l’urgenza.

L’attuale ondata di sviluppo assistito da intelligenza artificiale sta rendendo questo problema più acuto, non meno. Quando i developer possono generare e iterare il codice dell’applicazione un ordine di grandezza più veloce di prima, il database diventa un collo di bottiglia più ovvio rispetto a tutto ciò che lo circonda. Ma c’è un effetto secondario che è meno discusso. Gli strumenti di intelligenza artificiale sono molto bravi a generare logica di applicazione. Sono meno bravi a comprendere le conseguenze a lungo termine delle modifiche dello schema in un database di produzione complesso e live. La combinazione di velocità di sviluppo dell’applicazione più veloce e suggerimenti di modifiche dello schema generati da intelligenza artificiale senza una governance matura è esattamente il tipo di pressione che produce incidenti. La velocità senza paratie strutturali crea le condizioni per errori più rapidi.

Le organizzazioni che saranno in grado di navigare bene in questo sono quelle che trattano la governance del database come una preoccupazione di ingegneria di prima classe e non come un ripensamento di conformità. Ciò significa che il controllo delle versioni per lo schema del database è un default non negoziabile e che i test automatici gestiscono i controlli di routine in modo che il controllo manuale possa concentrarsi su modifiche ad alto rischio e ad alto giudizio piuttosto che diventare un collo di bottiglia a livello di fine. Infine, significa rilevamento della deriva che identifica la divergenza prima che causi un incidente.

La maggior parte dei patrimoni aziendali rende le cose più difficili di quanto dovrebbero essere.

C’è una realtà composta che siede accanto alla maggior parte di queste osservazioni. La maggior parte dei patrimoni di database aziendali non sono greenfield. Rappresentano decenni di modifiche dello schema accumulate, in esecuzione su più piattaforme DBMS, alcune on-premises e alcune nel cloud, con gradi di documentazione e conoscenza tribale variabili diffuse tra team che si sono avvicendati molte volte. La conversazione di modernizzazione spesso presume un punto di partenza pulito che la maggior parte delle organizzazioni non ha. È qui che la sfida è in realtà più acuta e spesso impedisce il progresso. Che l’obiettivo sia supportare l’innovazione, pulire e migrare i dati per l’intelligenza artificiale o migliorare la resilienza operativa; si tratta sempre delle stesse cose. La domanda non è come costruire una pratica di DevOps del database perfetta su un nuovo sistema. La domanda è come introdurre una governance significativa su un patrimonio legacy complesso senza fermare l’azienda mentre lo si fa.

La governance incorporata nella pipeline in modo incrementale è la sola risposta pratica a questa domanda. Non è necessario ripiattare l’intero patrimonio prima di poter migliorare le pratiche di gestione dei cambiamenti. Gli strumenti moderni come Redgate Flyway esistono per alleviare il database come collo di bottiglia e iniziare con le modifiche che vengono apportate oggi, nelle pipeline che già esistono, e costruire da lì.

Le organizzazioni che vinceranno in termini di crescita nei prossimi cinque anni non saranno quelle che hanno i patrimoni più puliti. Saranno quelle che hanno capito come rendere il cambiamento affidabile, al ritmo richiesto dall’azienda, nel patrimonio che hanno effettivamente.

È il problema che vale la pena risolvere. E si può risolvere.