Scegliere un sistema per un'azienda significa partire dal lavoro da svolgere, non dal marchio o dalla piattaforma che preferisci. È il criterio che ho messo alla prova parlando con InMarvinWeTrust, che di mestiere valuta le esigenze dei clienti.
Marvin preferisce l'open source e lo dice apertamente, ma non lo impone a ogni progetto. La soluzione deve reggere il contesto e le dipendenze che già ci sono.
La prima domanda riguarda le funzioni
Si comincia parlando con il cliente e con chi sviluppa il software: che cosa deve fare il servizio, con quali tecnologie è costruito, dentro quale infrastruttura dovrà stare.
Vale anche quando il cliente non è tecnico. Il bisogno arriva espresso come obiettivo operativo — «devo poter emettere fatture da casa» — e tradurlo in requisiti è esattamente il lavoro per cui viene pagato un professionista.
Le preferenze possono decidere fra due alternative equivalenti. Non dovrebbero venire prima dell'analisi delle condizioni che rendono un progetto funzionante.
Due esempi con esigenze opposte
Marvin racconta il caso di un e-commerce costruito con uno stack adatto a un ambiente GNU/Linux. Lì propone un'infrastruttura coerente con le tecnologie dell'applicazione, e la scelta si fa da sola.
Poi ne porta uno opposto: un progetto .NET con integrazioni e API legate a Windows. Pur sapendo che strumenti .NET esistono anche su Linux, osserva che quelle dipendenze rendevano sensato restare dov'erano.
La distinzione è decisiva. Il nome del linguaggio o del framework non determina la portabilità dell'intero progetto: contano librerie, integrazioni e il modo in cui quella cosa funziona davvero.
I costi fanno parte del progetto
Entrano in gioco licenze e investimenti già fatti. Un'infrastruttura può comprendere decine di macchine e servizi, quindi il conto non è mai quello di un singolo server.
Una decisione tecnica porta con sé migrazione, formazione e nuove attività di gestione. Dall'altro lato, aver già speso in una tecnologia non la rende conveniente per sempre: quel ragionamento tiene in vita sistemi che costano più di quanto rendano.
Il punto è confrontare le alternative nel loro contesto, su un orizzonte coerente con la vita del progetto.
L'esperienza non produce una ricetta unica
Marvin dice di non aver mai trovato due infrastrutture identiche. Anche progetti simili hanno vincoli diversi, e il suo contributo sta nell'adattare la soluzione a quelli che contano davvero.
È il senso di quella che chiamiamo analisi funzionale: capire che cosa deve succedere prima di decidere con quali componenti farlo succedere.
L'open source resta la sua inclinazione quando non ci sono ostacoli specifici. È una preferenza dichiarata, e dichiararla è il modo corretto di tenerla separata dalla responsabilità verso il bisogno del cliente.
Il lavoro remoto come acceleratore
Sul finale si parla di cloud e del periodo del lockdown. Marvin racconta un forte aumento delle richieste di accesso remoto e digitalizzazione fra i suoi clienti.
È la sua esperienza professionale in quel periodo, non una misura dell'intero mercato. Mostra però bene una cosa: le condizioni esterne possono riscrivere i requisiti di un'infrastruttura nel giro di poche settimane.
Il criterio finale non si muove: scegliere ciò che permette all'organizzazione di lavorare, e mettere per iscritto le ragioni e i compromessi della decisione.
