Può una “legge” formulata nel 1968 sull’architettura software davvero essere influente ancora oggi? Scopriamolo insieme partendo dalla sua formulazione:

“Le organizzazioni che progettano sistemi … sono indotte a generare design che sono copie dei legami nelle organizzazioni stesse.” – M. Conway

Il significato concreto della legge indica che le architetture software che vengono progettate da un’azienda sono il riflesso dell’organizzazione dei dipartimenti di sviluppo.

Nel suo studio originale, Conway, fece l’esperimento di commissionare lo sviluppo di un compilatore per COBOL e di uno per ALGOL a otto persone. Osservò che “Dopo alcune stime iniziali sulla difficoltà e sul tempo, cinque persone furono assegnate al lavoro sul compilatore COBOL e tre a quello sul compilatore ALGOL. Il compilatore COBOL risultante era strutturato in cinque fasi, mentre quello ALGOL in tre.”

Caliamola ora nel contesto di un team. Cosa accadrà di conseguenza? Quando un singolo team sviluppa un sistema, svilupperà un’architettura a monolite. E questo non è un problema. Infatti, un team può comunicare in modo informale, rapidamente e con una memoria condivisa efficace.

È quando i numeri cominciano a crescere che la legge di Conway va tenuta in considerazione perché da essa non c’è scampo.

In altre parole, come organizziamo i team ha un impatto diretto sull’architettura dei sistemi che vengono progettati e costruiti.

Azioni

Se da tutto questo non c’è scampo, cosa possiamo fare? Invece che essere vittime passive di questa legge, possiamo sfruttarla in modo intelligente a nostro favore. Come? Lo vediamo nel prossimo messaggio.

Sharing is caring

Se conosci qualcuno che potrebbe trovare utile ricevere e-mail per migliorare l’organizzazione dei team di sviluppo software, DevOps e software engineering in generale inoltragli questo post! Qui può iscriversi e cominciare a ricevere subito!