Idea principale

«Voglio sapere chi si collega all'applicazione.» Letta come una richiesta funzionale, la frase dice poco: un registro degli accessi, niente di spettacolare.

Spesso, però, dice tutt'altro. Dietro possono esserci un audit ISO, una policy di sicurezza, un team di cybersecurity, un SIEM centrale, una procedura di indagine — o semplicemente una cultura aziendale in cui ogni accesso deve essere tracciabile.

Lo stesso vale per le richieste affini: usare l'IAM del cliente, le sue chiavi di cifratura, il suo contratto con il fornitore del modello, il suo gateway email. Sembrano eterogenee e raccontano la stessa cosa.

Perché è importante

Trattate come requisiti tecnici, queste richieste si valutano in base al costo di sviluppo, e spesso si conclude che non creano alcun valore di business. Il giudizio è corretto, ma fuori tema.

Lette come espressione di una governance, si valutano in un altro modo: non «che cosa aggiunge al prodotto?», ma «che cosa permette a questa organizzazione di accettare?».

Sfumature e limiti

Non tutte nascono dalla cultura: alcune sono veri obblighi normativi, altre semplici preferenze di un team. Il lavoro consiste proprio nel non confonderle.

E la cultura di un grande cliente non è omogenea: ciò che chiede la sicurezza e ciò che chiedono le direzioni di business possono essere in contrasto.

Domande aperte

• Come distinguere, leggendo una richiesta, l'obbligo normativo dall'abitudine organizzativa?