Conways lag brukar citeras som en varning: ett system kommer att spegla kommunikationsstrukturen hos organisationen som byggde det. Det citeras oftast av någon som vill förklara varför arkitekturen blev fel. Men lagen är inte en varning, den är ett verktyg. Om strukturen ändå kommer att avgöra arkitekturen kan man lika gärna välja strukturen medvetet.
Vår erfarenhet är att kultur är den mest underskattade arkitekturfrågan i de flesta organisationer. Inte kultur i betydelsen värdeord på en vägg, utan i den konkreta betydelsen: vem som pratar med vem, vad som är tillåtet att göra utan att fråga, och vad som händer när något går sönder.
Gränserna följer samtalen
Två team som sitter tillsammans, äter lunch ihop och läser varandras kod kommer att bygga saker som hänger ihop tätt. Det är varken bra eller dåligt i sig, men det är förutsägbart. Två team på olika orter med varsin chef kommer att bygga ett tydligt gränssnitt mellan sig, eftersom allt annat är för dyrt att samordna.
Det betyder att man kan använda organisationen som ritverktyg. Vill du ha en skarp gräns mellan betalning och leverans, se till att de två inte sitter i samma dagliga flöde. Vill du att två delar ska utvecklas tillsammans, låt samma personer äga båda. Vi har sett fler arkitekturproblem lösas genom att flytta ansvar mellan team än genom att rita om diagram.
Den vanligaste varianten av problemet är ett system som ska vara löst kopplat men där alla ändringar ändå kräver samordning mellan tre grupper. Koden ser modulär ut. Kalendern gör det inte. Kalendern är den ärligare bilden.
Vad som händer efter en incident
Det snabbaste sättet att förstå en organisations tekniska kvalitet är att fråga vad som hände efter den senaste allvarliga störningen. Svaret säger mer än någon arkitekturgenomgång.
I organisationer där svaret handlar om vad man lärde sig ser man en viss sorts system: felhantering på rätt ställen, larm som någon faktiskt bryr sig om, och en vilja att ta bort komplexitet som visat sig farlig. I organisationer där svaret handlar om vem som gjorde fel ser man en annan sorts system: fler kontrollsteg, längre releaseprocesser och kod som ingen vill röra.
Det andra mönstret är dyrare, men kostnaden syns aldrig i en budget. Den syns i att en enkel ändring tar tre veckor för att fyra personer måste godkänna den, och i att de mest erfarna utvecklarna slutar föreslå förbättringar eftersom förslag skapar risk för den som lägger dem.
Ägarskap är en teknisk egenskap
Ett system utan tydlig ägare degraderas långsamt, oavsett hur väl det var byggt från början. Ingen enskild ändring är dålig nog att stoppa, och summan av femtio sådana ändringar är ett system ingen förstår.
Ägarskap i den här meningen är inte samma sak som ansvar i ett organisationsschema. Det handlar om huruvida det finns någon som blir irriterad när något görs slarvigt i just den koden. Den irritationen är en teknisk resurs, och den försvinner så fort ansvaret sprids ut på tillräckligt många.
Vår tumregel är att varje system som är värt att behålla ska ha ett team som kan svara på tre frågor utan att fråga någon: vad det gör, vem som använder det och vad som händer om det slutar fungera. System där de tre frågorna inte har en tydlig adressat är alltid de som orsakar mest bekymmer, och nästan alltid de som ingen tänkte på när riskanalysen skrevs.
Att välja struktur medvetet
Om du står inför en större teknisk omställning är det värt att ställa den organisatoriska frågan först. Vilka grupper ska kunna leverera utan att vänta på varandra? Den frågan avgör var gränserna i systemet ska gå, och den avgör den mer än något tekniskt övervägande gör.
Det motsatta greppet, att först rita systemet och sedan hoppas att organisationen anpassar sig, fungerar sällan. Organisationen anpassar sig inte. Den fortsätter kommunicera som den gjorde, och systemet dras med tiden tillbaka mot den formen. Det man ser efteråt beskrivs oftast som att arkitekturen urholkades, men det som hände var att den aldrig hade organisationen bakom sig.
Det här är också varför de mest lyckade tekniska förändringar vi varit med om har haft en ledningsgrupp som var beredd att ändra vem som rapporterar till vem. Utan den beredskapen blir arkitekturarbete en övning i att rita det man önskar, medan det man har fortsätter växa i sin egen riktning.