Facilitare l'architettura del software

Prefazione

Oggi sviluppiamo software in modo molto diverso rispetto a quando ho iniziato a lavorare come sviluppatore più di 20 anni fa.

I cambiamenti avvenuti - tra cui Agile, DevOps e il passaggio dal progetto al prodotto - hanno comportato una crescente decentralizzazione e indipendenza. I team ora rilasciano generalmente il proprio codice, supportano i propri sistemi e decidono come risolvere le esigenze aziendali.

Tuttavia, nella mia esperienza, il ruolo più difficile da risolvere è stato quello dell'architetto.

Quando costruivo sistemi monolite più di dieci anni fa, gli architetti lavoravano in un team separato, progettando l'architettura dell'intero sistema, definendo gli standard e scegliendo quale database, linguaggio di programmazione o meccanismo di distribuzione utilizzare. Ci sono diversi motivi per cui questo non funziona nelle moderne organizzazioni di ingegneria: queste decisioni diventano un collo di bottiglia, impedendo ai team di progredire, ma oggi c'è anche meno possibilità che una singola decisione vada bene per tutti i team.

Ma qual è l'alternativa? Puoi permettere ai team di prendere le proprie decisioni architettoniche, assegnando agli architetti il compito di lavorare a stretto contatto con i team stessi o facendo dell'"architettura" una cosa che fanno le persone che ricoprono ruoli ingegneristici di alto livello (insieme a tutto il resto). Tuttavia, questo può portare a un'ampia divergenza di approcci. Questo può essere rischioso: tutti i diversi data ...