Il costo di uscita non è mai in fattura

La settimana scorsa ho scritto che il costo di disfare una decisione non nasce con la decisione. Si accresce dopo, attraverso ogni scelta successiva che dà silenziosamente per scontato che la cosa difficile da invertire resterà dov'è. L'ho scritto parlando di codice. Uno schema, uno scheduler, un'interfaccia su cui quattro team hanno costruito senza che nessuno la chiamasse decisione di architettura.

Le risposte sono arrivate da gente che il codice non lo scrive. Chi gestisce le valutazioni di procurement. Chi fa third-party risk di mestiere. Un advisor che guarda cinque applicazioni che fanno lo stesso lavoro nella stessa azienda. Un enterprise architect che discute di chi debba possedere quali capability AI. Stanze diverse, vocabolari diversi, e ognuno di loro stava descrivendo lo stesso meccanismo.

Di solito è il segno che il confine l'hai tracciato nel punto sbagliato. L'accrescimento non è una proprietà del codice sorgente. È una proprietà della dipendenza, e in una grande organizzazione la dipendenza è comprata più che costruita.

Il che fa emergere una domanda che sembrerebbe avere già una risposta. Quanto ti costerebbe andartene? Quel numero non ce l'ha nessuno. L'altro ce l'hanno tutti.

Il contratto prezza il restare, non l'andarsene

Una relazione con un fornitore viene valutata seriamente esattamente una volta, ed è all'inizio. Questionario di sicurezza, SLA, referenze, solidità finanziaria, sintesi del penetration test, a volte una visita in sede. Lavoro vero, fatto da gente che lo sa fare. Poi la relazione entra nel registro dei rischi con un rating e viene rivista una volta l'anno, il che in pratica significa che qualcuno conferma che non è cambiato niente.

Quello che quel processo misura è lo stato di salute del fornitore oggi. Quanto è probabile che ti lasci a piedi, quanto gravemente, quanto bene gestirebbe il guasto.

Non misura la cosa che decide cosa potrai farci. Se questo fornitore peggiora, viene acquisito, triplica il prezzo al rinnovo o semplicemente smette di essere la scelta giusta, le tue opzioni non le determina la sua condizione. Le determina quanto è difficile lasciarlo. E quel numero non compare da nessuna parte nella valutazione, perché nel momento in cui stai facendo la valutazione è vicino allo zero. Al primo giorno cambieresti fornitore in due settimane. Non c'è niente da pianificare, quindi nessuno pianifica.

Sì, il contratto ha una clausola di uscita. Ha i termini di preavviso, gli obblighi di restituzione dei dati e un paragrafo sull'assistenza alla transizione che qualcuno ha negoziato duramente. Tutto questo prezza l'uscita legale. Niente di tutto questo prezza l'uscita operativa, e l'uscita operativa è il conto intero.

Le carte ti dicono la condizione di un fornitore oggi. Non ti dicono niente su quanto sarà difficile lasciarlo una volta che ci dipendi.

Si accresce fuori dal campo visivo

Il meccanismo è quello della settimana scorsa, che gira in un posto con una strumentazione peggiore.

Mese dopo mese l'integrazione si fa più profonda, e non perché qualcuno abbia deciso di approfondirla. I loro identificatori diventano i tuoi identificatori, perché tenere i tuoi e mappare i loro era lavoro in più che nessuno riusciva a giustificare. I loro valori di stato finiscono nei tuoi report. L'ordine in cui i loro webhook capita che arrivino diventa un'assunzione su cui la tua logica di riconciliazione si appoggia, non documentata, scoperta tardi. Il team di supporto costruisce il proprio processo attorno al loro flusso di ticket. Un report per la finanza esiste nella forma in cui esiste perché quella è la forma del loro export. Due persone nel team conoscono le "stranezze" abbastanza bene da aggirarle, e quella conoscenza è il motivo per cui le cose girano lisce, ed è anche un costo di uscita che nessuno ha mai registrato.

Nessuna di queste è stata una decisione di architettura. Ognuna era una scelta locale ragionevole, presa da qualcuno che non aveva motivo di consultare nessuno. La dipendenza è diventata meno reversibile ogni mese, mentre il registro dei rischi la segnava come chiusa.

Dentro il tuo sistema almeno uno strumento grezzo ce l'hai. Un dependency graph ti mostra i chiamanti. Si perde parecchio, come continuo a ripetere, ma qualcosa te lo mostra. Attraverso il confine di un fornitore non hai nemmeno quello. I punti di integrazione li puoi elencare, perché stanno in un file di configurazione da qualche parte. L'adattamento non lo puoi elencare, perché l'adattamento vive nei processi, nei report, nelle abitudini e nella testa di due persone.

Quindi il test che funziona è imbarazzantemente semplice, e lo puoi fare questa settimana. Chiedi cosa si rompe davvero se ce ne andiamo, e cronometra la risposta. Se torna indietro in un pomeriggio, l'opzione ce l'hai ancora. Se la risposta onesta è che qualcuno dovrebbe andare a vedere, l'opzione l'hai persa un pezzo fa e nessuno te l'ha detto.

A volte quello che hai comprato è un processo

C'è una versione di tutto questo più affilata del lock-in, e sfugge proprio perché non sembra affatto una dipendenza.

Federi l'identità a un provider e non hai semplicemente scelto un meccanismo di login. Hai adottato il loro processo joiner, mover e leaver. Non lo gestisci tu. Non lo puoi osservare. Non hai nessuna strumentazione sopra. E da quel giorno un contractor che esce dalla tua organizzazione è un cambio di stato in un sistema che appartiene a qualcun altro, di cui adesso si fida tutto il tuo parco applicativo.

La riga nella architecture review dice che ci fidiamo di questo provider. Quello che dice davvero è che abbiamo adottato il loro comportamento di offboarding senza mai valutarlo. Sono due affermazioni diverse e solo una delle due è stata messa per iscritto.

Non è un argomento contro il federare. Federare di solito è la scelta giusta, e l'alternativa sono cinque identity store locali peggiori su ogni dimensione. È un argomento sul fatto che la decisione che hai preso era più grande della decisione che hai registrato, che è il problema più vecchio di questa serie. La stessa forma riappare ogni volta che compri un managed service: hai comprato una capability, e insieme hai adottato in silenzio una procedura operativa che non vedrai mai girare.

Niente di tutto questo è in fattura

L'esempio dal vivo più nitido è il tooling AI, dove il dibattito si è assestato su possedere contro comprare. Costruisci la capability in casa e tieni la sovranità, oppure compri il tool e accetti la dipendenza.

Proprietà e dipendenza non sono lo stesso asse, e trattarli come se lo fossero è il modo in cui le organizzazioni finiscono per comprare una sovranità che non hanno.

Tutti guardano il contratto e la API surface, perché sono le parti visibili. Sostituire l'endpoint di un provider è la metà facile del lavoro ed è la metà che viene stimata. Quello che non si sostituisce è l'adattamento accumulato. Prompt tarati per mesi sulle "stranezze" particolari di un modello. Suite di eval scritte per descrivere il suo comportamento specifico, il che significa che la tua definizione di "funziona" ha ormai la forma di quel modello dentro. Workflow, passi di review e istinti del team riorganizzati attorno a ciò in cui quel modello è bravo e a ciò che sbaglia in modo affidabile.

Niente di tutto questo è in fattura, e tutto va ricostruito.

Ed è per questo che "alla sovranità ci pensiamo dopo" è una posizione costosa, non soltanto tardiva. La dipendenza non aspetta educatamente che la domanda venga posta. Cresce esattamente nel periodo in cui stai rimandando la decisione, quindi il costo della risposta che darai è determinato da quanto ci hai messo a fare la domanda.

L'evidenza che avresti dovuto chiedere

Se quello che conta è il costo di uscita, allora l'evidenza che pretendi prima di firmare dovrebbe scalare con quel costo. Costo di uscita basso, una risposta scritta va benissimo. Costo di uscita alto, una risposta scritta vale quasi zero.

E lì dentro c'è un'inversione antipatica, che ho pagato di persona. Le affermazioni che costano di più da disfare sono esattamente quelle che sopravvivono a ogni demo. Gestisce i retry in sicurezza. Nessuna doppia elaborazione. I tenant restano isolati. Passano tutte, ogni volta, nella sandbox, nel walkthrough, nella reference call, perché il guasto non è mai stato nella logica che il fornitore ti sta mostrando. Il guasto è in cosa il volume reale, la concorrenza reale e i retry reali fanno a quella logica, mesi dopo che hai integrato, quando ormai quell'affermazione è una fondamenta invece che una riga in una proposta.

Quindi per quelle affermazioni specifiche l'evidenza giusta non è una dimostrazione scriptata. È un test costruito per rompere l'invariante. Rimanda lo stesso identico trigger due volte e mostrami un solo risultato. Colpiscilo in concorrenza e mostrami lo stato dopo. Due tenant, una query avversariale, mostrami la risposta vuota. Costa una giornata e un account di sandbox. Se regge hai imparato qualcosa di vero, e se non regge l'hai imparato mentre andarsene costa ancora zero.

Una risposta scritta lusinga proprio le affermazioni più care da disfare.

Progetta l'uscita finché è ancora gratis

L'asimmetria di timing è la stessa della settimana scorsa, ed è tutto il motivo per cui questa roba va fatta alla firma e non al rinnovo.

Alla firma, decidere cosa resta sostituibile costa un pomeriggio di discussione. Tieni i tuoi identificatori e mappa i loro al bordo. Tieni il loro vocabolario fuori dal tuo domain model, così i loro valori di stato non diventano mai i tuoi valori di stato. Scrivi quali dati ti servirebbero uscendo, in che formato, e poi quell'export eseguilo davvero almeno una volta, perché un export che non hai mai lanciato è un'affermazione, non una capacità. Ognuna di queste cose è economica finché la giuntura è ancora aperta, e quasi impossibile da retrofittare dentro un anno di integrazione accumulata.

Non è una difesa dell'avvolgere ogni fornitore in un layer di astrazione. Quello è l'eccesso di opzionalità della settimana scorsa con il badge del procurement, e finisce allo stesso modo: un'interfaccia costruita per poter sostituire la cosa che non sostituirai mai, portata avanti per anni, pagata ogni giorno. La regola di prezzo non cambia. Progetta l'uscita dove sbagliare è insieme costoso e plausibile. Dati che non puoi ricreare. Una forma su cui altri team costruiranno. Qualcosa che sta tra te e il tuo cliente. Per tutto il resto, firma e torna a lavorare.

E se vuoi un momento naturale per prezzarla, il rinnovo è l'unico che il calendario ti regala. È anche quello che le organizzazioni sprecano più spesso, perché il rinnovo automatico è la forma più pura di tutto questo problema. La dipendenza si estende da sola per altri tre anni e nessuno deve decidere niente. Ribalta quel default, e chi firma il rinnovo possiede la decisione di tenersela, il che significa che finalmente qualcuno ha un motivo per chiedere quanto costerebbe andarsene.

Tra parentesi, è su questa domanda che si blocca davvero il consolidamento di portfolio. La spesa di licenza, l'infrastruttura, il valore di contratto e l'utilizzo sono tutti dati raccoglibili, e le organizzazioni li raccolgono con diligenza. Ma il numero che determina se cinque applicazioni ne diventano una è il costo di rimuoverne quattro, e quel numero non sta su nessuno spreadsheet, perché non esisteva quando la duplicazione è nata. Si è accresciuto, un'integrazione alla volta, ognuna costruita contro un doppione mentre stava lì. Diecimila risparmiati non decidendo, mezzo milione per rimuoverlo cinque anni dopo, e poi il risultato lo chiamano legacy.

La regola che ti lascio

Valuta un fornitore e hai misurato quanto è probabile che ti lasci a piedi. Utile, e non è la cosa che governa le tue opzioni.

Misura la tua uscita e hai misurato cosa potrai farci, che è l'unica parte della relazione davvero tua. Fallo alla firma, dove è quasi gratis. Pretendi evidenza in proporzione a quanto costerà sbagliare, e tieni l'asticella più alta proprio sulle affermazioni che fanno una gran figura in demo. Tieni l'opzione dove il danno sarebbe reale, e saltala ovunque altro, perché la cautela uniforme qui compra lo stesso niente che compra dappertutto.

Poi scrivi, una volta sola, cosa ti faceva credere che da questo fornitore sarebbe stato facile andarsene. Non per l'archivio. Per chi scoprirà tra tre anni, forse tu, che ha smesso di essere vero, e non riuscirà a capire se qualcuno lo avesse mai saputo.

Quindi ecco la domanda a cui vorrei davvero una risposta sul tuo parco applicativo. Prendi il fornitore che meno vorresti perdere, e chiediti quanto ci metterebbe la tua organizzazione a dire con precisione cosa si rompe se lunedì non ci fosse più. Se la risposta è che qualcuno dovrebbe andare a vedere, il costo di uscita lo conosci già, ed è più alto di quanto chiunque abbia messo per iscritto.