All’epoca, la Harvard Business Review respinse il suo articolo originale basandosi sul fatto che non aveva dimostrato la sua ipotesi. Tuttavia, questa osservazione è diventata nota come la legge di Conway, e le esperienze collettive dei miei colleghi e mie hanno rafforzato più volte la verità di questa affermazione. Ma non dovete crederci sulla parola!
In “Exploring the Duality between Product and Organizational Architectures”, uno studio della Harvard Business School ha condotto un’analisi di diversi codebase per vedere se potevano provare l’ipotesi originale di Conway applicata ai sistemi software. In esso, hanno preso diversi esempi di software creati per risolvere lo stesso scopo (per esempio elaborazione di testi, gestione finanziaria e software di database), e hanno confrontato le basi di codice create da team open source liberamente accoppiati e quelle create da team strettamente accoppiati. Il loro studio ha trovato che i team di prodotto, spesso co-locati e focalizzati, hanno creato software che tendevano più verso codebase monolitiche strettamente accoppiate. Mentre i progetti open source risultavano in basi di codice più modulari e decomposte.
Le organizzazioni da qualche anno hanno capito questo legame tra la struttura organizzativa e il software che creano, e hanno abbracciato nuove strutture per raggiungere il risultato che vogliono. Netflix e Amazon, per esempio, si strutturano intorno a più piccoli team, ognuno con la responsabilità di una piccola parte del sistema complessivo. Questi team indipendenti possono possedere l’intero ciclo di vita dei servizi che creano, offrendo loro un maggior grado di autonomia di quanto sia possibile per team più grandi con codebase più monolitici. Questi servizi con le loro preoccupazioni indipendenti possono cambiare ed evolvere separatamente l’uno dall’altro, con la conseguente capacità di consegnare i cambiamenti alla produzione più velocemente. Se queste organizzazioni avessero adottato team di dimensioni maggiori, i sistemi monolitici più grandi che sarebbero emersi non avrebbero dato loro la stessa capacità di sperimentare, adattarsi e, infine, mantenere i loro clienti felici.
Potreste vedere tensioni nelle vostre organizzazioni dove la struttura e il software non sono allineati. Potreste aver visto, per esempio, le sfide coinvolte quando i team distribuiti cercano di lavorare sulla stessa base di codice monolitica. Qui, i percorsi di comunicazione a cui Conway si riferisce sono in contrasto con il codice stesso, dove la singola codebase richiede una comunicazione a grana fine, ma un team distribuito è capace solo di una comunicazione a grana grossa. Dove emergono queste tensioni, cercare opportunità per dividere i sistemi monolitici intorno ai confini organizzativi spesso produce vantaggi significativi.
Nei precedenti Radar tecnologici abbiamo evidenziato la crescente popolarità dei Microservizi, che sono sempre più adottati dalle organizzazioni che cercano di migliorare l’autonomia dei loro team e aumentare la velocità del cambiamento. L’articolo di Martin Fowler e James Lewis approfondisce l’argomento, sottolineando il fatto che queste architetture permettono alle organizzazioni molta più flessibilità nell’allineare l’architettura dei loro sistemi alla struttura dei loro team, al fine di garantire che la legge di Conway funzioni per voi. Nella prossima edizione del Tech Radar, discuteremo il riflesso della crescente influenza dei microservizi, dalla tecnologia dell’infrastruttura come Packer o Docker allo strumento di scoperta dei servizi Consul, o microcontenitori come il popolare DropWizard o il abbastanza nuovo SpringBoot. Discuteremo anche l’inverso – le organizzazioni che cambiano la struttura dei loro team per adattarsi ai loro sistemi IT.
Ci aspettiamo di vedere emergere altre tecniche e tecnologie di supporto per abilitare le architetture a microservizi, e ne terremo traccia nei prossimi mesi. Nel frattempo, se volete saperne di più, iscrivetevi all’ultimo Tech Radar, controllate l’articolo di Martin e James sui microservizi, o il mio libro di O’Reilly, Building Microservices.