Facendo un’analogia con il mondo delle costruzioni, prima di erigere un edificio, nella fase progettuale interviene sempre un ingegnere strutturale, incaricato di calcolare e definire le basi necessarie per la realizzazione.
Una prassi non solo logica ma anche imprescindibile: non si può costruire una casa o un palazzo senza considerare la sua architettura o la solidità del suo scheletro. Ogni esigenza costruttiva richiede soluzioni architettoniche specifiche.
E qui nasce la mia riflessione: perché nel mondo dello sviluppo software questo approccio non è altrettanto diffuso? E, quando avviene, perché la progettazione architetturale non viene sempre analizzata con la profondità che merita?
Nel nostro settore, la figura equivalente all’ingegnere strutturale è il Software Architect, un ruolo che, in molti contesti, sembra quasi appartenere a una leggenda.
La figura dell’Architect nel mondo reale
In base alla mia esperienza di circa otto anni nel settore, ho notato che questa figura è spesso assente. Nella maggior parte dei progetti a cui ho partecipato, il ruolo dell’architect veniva svolto, quando necessario, dai membri più senior del team di sviluppo. Tuttavia, c’è una differenza sostanziale: il Software Architect non è semplicemente uno sviluppatore esperto, ma una persona con un know-how esteso e approfondito sulle architetture software.
Il ruolo del Software Architect: competenze e responsabilità
Il Software Architect è il professionista responsabile di progettare l’architettura di un sistema software, garantendo che sia robusta, scalabile e adeguata alle esigenze attuali e future del progetto. È una figura strategica che unisce competenze tecniche avanzate a una visione d’insieme dei processi aziendali e delle esigenze del cliente.
Egli deve possedere un vasto bagaglio di conoscenze tecniche, che includono:
- Conoscenza delle architetture software: Microservizi, monolitiche, serverless, event-driven, SOA, ecc.
- Progettazione e modellazione: Capacità di definire diagrammi di architettura, come quelli UML o C4, per descrivere la struttura del sistema.
- Tecnologie e linguaggi: Esperienza pratica con linguaggi di programmazione (ad esempio Java, Python, JavaScript, ecc.) e framework, per valutare e scegliere quelli più idonei al progetto.
- Database e storage: Conoscenza approfondita di database relazionali (es. PostgreSQL, MySQL) e non relazionali (es. MongoDB, DynamoDB), così come delle soluzioni di storage distribuito.
- Cloud computing: Esperienza con servizi cloud (AWS, Azure, Google Cloud) e containerizzazione (Docker, Kubernetes), fondamentali nei progetti moderni.
- Pattern architetturali: Familiarità con design pattern come CQRS, Event Sourcing, Repository Pattern, Singleton, ecc.
- Scalabilità e performance: Capacità di progettare sistemi che reggano carichi elevati, utilizzando tecniche come il load balancing e il caching distribuito.
Responsabilità principali e soft skills
Esso ha un ruolo cruciale in ogni fase del progetto:
- Definizione dell’architettura: analizzare i requisiti del progetto e progettare la struttura software scegliendo l’architettura più adatta.
- Scelta delle tecnologie: valutare framework e strumenti per garantire scalabilità e manutenibilità.
- Allineamento con il business: collaborare con gli stakeholder per garantire che l’architettura risponda agli obiettivi aziendali.
- Supporto al team di sviluppo: fornire linee guida, risolvere problemi complessi e promuovere buone pratiche.
- Gestione dei compromessi: bilanciare qualità, velocità di sviluppo e rischi tecnologici.
- Evoluzione dell’architettura: monitorare e aggiornare l’architettura per adattarla alle esigenze in evoluzione.
- Comunicazione efficace: spiegare concetti complessi a tecnici e non tecnici.
- Leadership: guidare il team nelle decisioni tecniche e motivarlo verso obiettivi comuni.
- Problem solving: affrontare sfide complesse in modo rapido e strategico.
Progettazione: un momento cruciale
La fase di progettazione, inclusa la scelta delle tecnologie e dell’architettura, è un momento cruciale nello sviluppo di un software. Scelte ponderate in questa fase possono facilitare enormemente non solo lo sviluppo, ma anche il funzionamento, l’evoluzione e la manutenibilità del prodotto.
Nonostante l’importanza strategica di questa figura, mi chiedo: perché il Software Architect è così raro nei team, anche nelle grandi società di consulenza?
Un costo o un investimento?
Alla luce di tutte queste riflessioni, forse a renderelo latitante nei team di sviluppo, potrebbe essere un problema di budget?
Quindi il Software Architect è un costo o un investimento?
Perché è indispensabile
Potremmo dire che, non è un costo, ma un investimento:
- Previene errori strutturali: Una progettazione solida riduce la probabilità di problemi tecnici a lungo termine.
- Accelera lo sviluppo: Fornisce una base chiara e ben definita, riducendo gli sforzi di coordinamento del team.
- Garantisce scalabilità: Consente di realizzare software che cresca con le esigenze del business, senza doverlo riprogettare da zero.
- Riduce i costi: Scelte architetturali ponderate evitano spese aggiuntive in manutenzione e riprogettazione.
Comprendo però che, per un’azienda, inserirne uno in ogni progetto può rappresentare un costo significativo. Tuttavia, una possibile soluzione potrebbe essere quella di introdurre un numero limitato di architect dedicati, distribuiti tra le business unit, in modo che possano supervisionare e supportare più progetti contemporaneamente. Questo approccio non solo abbatterebbe i costi, ma garantirebbe un livello più alto di qualità e coerenza nelle soluzioni progettuali.
Il Software Developer, un Software Architect inside?
In molte realtà aziendali, soprattutto quelle di dimensioni medio-piccole, avere un architect dedicato per ogni progetto è insostenibile. La soluzione potrebbe essere quella di formare i software developer affinché acquisiscano conoscenze abbastanza approfondite di architettura, senza necessariamente trasformarli in architect. Questo approccio permetterebbe ai developer di prendere decisioni progettuali più consapevoli, mitigando l’assenza di una figura dedicata.
E cosa cambierebbe rispetto al demandare la progettazione ai senior del gruppo?
Non sempre senior significa avere conoscenze di soluzioni architettoniche, o di diverse tecnologie, per questo c’è bisogno di un vero focus sulla materia.
Conclusione: il Software Architect oggi e domani
In conclusione, sembra davvero che questa figura sia mitologica.
Ma forse la vera domanda è: i team, hanno davvero bisogno di un architect dedicato?
Ma se oggi la situazione è questa, domani, con l’AI alle porte, quale sarà il futuro del nostro caro amico?
E voi?, cosa ne pensate?
Parliamone nella community Telegram o sui social.
