Software architect e solution architect: un ruolo che cambia con la dimensione del progetto.

Un sistema in produzione deve raggiungere obiettivi precisi: prestazioni, affidabilità, sicurezza e conformità, tracciabilità, gestibilità, flessibilità, costi. Per ottenerli si lavora su due livelli, prima ancora di entrare nelle funzioni dell'applicazione.

Il solution architect definisce l'architettura dei servizi: quali servizi cloud usare e come collegarli per raggiungere quegli obiettivi. Microsoft lo descrive come chi consiglia gli stakeholder e traduce i requisiti di business in progetti tecnici, insieme a sviluppatori, amministratori ed esperti di sicurezza e di dati.

Il software architect definisce le regole software comuni che fanno funzionare quelle scelte: come ogni componente scrive i log e usa gli strumenti di monitoraggio, come usa i servizi, come gestisce errori e configurazione.

I due livelli non bastano l'uno senza l'altro. Il monitoraggio va previsto nell'architettura, ma i dati utili arrivano solo se anche lo sviluppo segue regole precise. Con accesso limitato alla produzione è evidente: davanti a un'anomalia si può contare solo su ciò che è stato previsto prima.

Esperienza cloud →

Per entrambi i ruoli questi servizi e queste regole sono quasi sempre da valutare: formano una base, quasi un framework a sé stante, per un progetto che sfrutta l'ambiente cloud, può crescere e si può monitorare.

Fatto questo si entra nel singolo progetto, capendo cosa serve davvero. Il software architect sceglie quale architettura sviluppare, per esempio se usare la Clean Architecture, e definisce le regole di sviluppo; insieme si scelgono i servizi e i pattern cloud adatti al caso. Secondo la situazione si parte da un prototipo (proof of concept) che verifica il rispetto di queste regole, poi si passa allo sviluppo vero e proprio.

Come organizzo il codice →

Anche le esigenze del progetto possono cambiare la base: dati regolamentati o volumi elevati possono richiedere servizi diversi.

Non sono titoli standard. Nelle organizzazioni grandi si aggiunge l'enterprise architect, che lavora sull'insieme dei sistemi e sulla strategia tecnologica, non sul singolo progetto.

Il ruolo non nasce con il cloud, ma oggi i due temi si incontrano quasi sempre. Nel cloud l'infrastruttura non si compra una volta: si sceglie tra molti servizi, si descrive in file versionati e si paga ogni mese. Una scelta di architettura diventa anche una scelta di costi, di rischi e di dipendenza da un fornitore.

Questo profilo si applica solo a una parte dei progetti a curriculum.

• Ho definito architettura e scelte tecniche, da unico sviluppatore, con clienti diretti (C-06, C-07).
• Ho lavorato dentro soluzioni già operative, come parte del team: rilasci su più sistemi, diagnosi con produzione ad accesso limitato, infrastruttura come codice (C-01, C-05, Esperienza cloud).
• Non mi sono occupato di migrazioni al cloud di un'intera azienda: le mie migrazioni riguardano singole applicazioni (Migrazione).

Le fonti descrivono ruoli e servizi. Le quattro situazioni e il modo di lavorare in questo ruolo sono una mia lettura basata sull'esperienza, non una classificazione ufficiale.

• Microsoft — Azure Solutions Architect Expert (si apre in una nuova scheda): descrizione del ruolo.
• Microsoft — Cloud Adoption Framework (si apre in una nuova scheda): fasi dell'adozione e team coinvolti.
• Microsoft — Cloud strategy team (si apre in una nuova scheda): funzioni coinvolte nella strategia, compresi i lead architect.
• SAFe — System Architect (si apre in una nuova scheda), Solution Architect (si apre in una nuova scheda), Enterprise Architect (si apre in una nuova scheda): ruoli per livello.
• Martin Fowler — Software Architecture Guide (si apre in una nuova scheda): architettura e programmazione.
• Microsoft — Well-Architected Framework (si apre in una nuova scheda): i cinque pilastri di una soluzione cloud.
• Microsoft — Cloud Design Patterns (si apre in una nuova scheda): scelta dei pattern a partire dal problema.
• Microsoft — Azure landing zone (si apre in una nuova scheda): separazione tra base comune e carichi di lavoro.
• Microsoft — Platform engineering (si apre in una nuova scheda): percorsi predefiniti per gli sviluppatori e crescita graduale della piattaforma.
• Chris Richardson — Microservice chassis (si apre in una nuova scheda): una base riutilizzabile per log, metriche, tracciamento e configurazione.
• Microsoft — OpenTelemetry in Application Insights (si apre in una nuova scheda): il monitoraggio richiede sia la risorsa sia la modifica dell'applicazione.
• AWS — Migration strategies (si apre in una nuova scheda): le sette strategie di migrazione.
• Microsoft — Comparing Container Apps with other options (si apre in una nuova scheda): servizi di esecuzione e accesso a Kubernetes.
• Microsoft — Bicep (si apre in una nuova scheda): infrastruttura come codice.
• Microsoft — Infrastructure as code (si apre in una nuova scheda): l'infrastruttura come codice come standard, eseguita tramite le pipeline.
• Microsoft — Comparing Terraform and Bicep (si apre in una nuova scheda): differenze tra i due strumenti.
• Microsoft — Point-to-Site VPN (si apre in una nuova scheda): collegamento di un singolo computer alla rete virtuale.
• Microsoft — Private endpoint (si apre in una nuova scheda): accesso privato ai servizi, anche via VPN.
• Microsoft — Entra Private Access (si apre in una nuova scheda): accesso alle risorse private senza VPN tradizionale.
• Microsoft — Windows 365 e reti Azure (si apre in una nuova scheda): collegamento dei Cloud PC alla rete virtuale.
• Microsoft — Budget (si apre in una nuova scheda): i budget non fermano il consumo.
• Microsoft — Container Apps billing (si apre in una nuova scheda): costi a zero repliche e costi che restano.
• Microsoft — Deployment Stamps (si apre in una nuova scheda): copie indipendenti di una soluzione, vantaggi e costi.
• Microsoft — Data, privacy and security for Foundry Models sold by Azure (si apre in una nuova scheda): trattamento di prompt e risposte.