På nätverket Agile Swedens mejlinglista har den senaste tiden pågått en intensiv debatt kring arkitektrollen. Roten till diskussionen var ett ”upprop” till sveriges IT-arkitekter att gå med i IASA:s nybildade, svenska sektion. Jag inledde debatten med argumentationsstöd i Martin Fowlers artikel ”Who Needs an Architect?” och detta inlägg är i viss mån en fortsättning på detta.

Jag vill direkt medge att jag förhåller mig starkt skeptisk till något som kan vara början på bildandet av ett eget arkitektskrå. Skälen till detta är framför allt min rädsla för att ovanstående initiativ kan leda till en ofruktbar utformning av arkitektrollen och en ”vi-och-dom”-känsla i projekten. I detta inlägg tänkte jag försöka analysera de olika perspektiven på arkitektrollen och hur dessa göder eller förminskar olika framgångsfaktorer för systemutvecklingsprojekt.

Utvecklingsprojekt måste ge mer än bra system

Det finns inget tvivel om att alla grupper mår bättre av att ha medlemmar som är experter, allra helst uppblandat med mindre erfarna, men hungriga, lärlingar. Att det till exempel finns en eller flera erfarna och kompetenta systemutvecklare i en grupp som ska utveckla eller vidareutveckla ett IT-system är givetvis en stor tillgång. Frågan är bara hur de bäst ska verka i gruppen – och i så fall vad vi vill kalla den rollen?

För att kunna angripa detta måste vi först förklara vad vi menar med ett bra systemutvecklingsprojekt. De flesta kunder skulle kanske svara att det är att få ett bra system till rätt pris och i rätt tid; ett system som löser rätt uppgift och som användarna uppskattar och har nytta av. Det är vad man brukar kalla extern kvalitet. Tekniskt lagda personer kanske istället skulle föra fram andra viktiga saker; som att systemet är enkelt designat men ändå flexibelt på rätt ställen, att koden håller hög kvalitet, att systemet följer organisatoriska standarder för att enkelt kunna integreras med andra system etcetera. Detta är vad vi kan kalla intern kvalitet. Båda dessa egenskaper hos systemet är viktiga.

Hur uppnår vi då detta? Det är förstås en svår fråga, men inom Agile är vi övertygade om att människorna i projekten alltid är viktigare för resultatet än verktyg och processer (agiles första värdering). Det betyder till exempel att hur teamet fungerar som ett lag och hur bra de kommunicerar och samarbetar anses vara av största vikt. Ett dysfunktionellt team kan skapa glimtar av bra delar men aldrig en helgjuten produkt. Alltså bör faktorer som stimulerar lagkänsla, samarbete och kommunikation verkar rimliga att ta hänsyn till.

Vidare, om vi bara fokuserar på det nuvarande projektet glömmer vi bort en viktig sak. Som Alistair Cockburn påpekar i boken ”Agile Software Development” så är ett utvecklingsprojekt ett ”spel” som fortgår på två fronter, eller två spel, om man så vill. Det första spelet är det aktuella projektet, om det blir lyckat eller ej. Det andra spelet, som ofta tappas bort, är det som kommer efter projektet slut; förvaltningen av systemet och organisationens nästa utvecklingsprojekt. Varje projekts jobb är att balansera kraven från dessa båda spel.

Det som är viktigast för att lägga upp för ett bra nästa spel, enligt agila experters förmenande, är inte en bra systemdokumentation, förvaltningsbar kod eller ens en bra systemdesign (även om dessa saker hjälper), utan istället att personerna från det tidigare projektet 1. är kvar i företaget, 2. har blivit lite duktigare som programhantverkare och 3. har utvecklats till mognare människor som kan bidra till att skapa bättre team. Kan vi skapa miljöer i vilka människor trivs och växer har vi alltså större chanser att lyckas med nästa projekt.

Summerat kan man alltså med visst fog hävda att för att öka våra chanser till hållbar framgång bör vi arbeta med saker som

• stärker teamets lagkänsla
• uppmuntrar samarbete
• stimulerar kommunikation
• ger möjlighet till kompetensutveckling
• fostrar god känslomässig utveckling

samt givetvis undvika saker som motverkar dessa. Om vi ligger bra till på dessa faktorer har vi en mycket god chans att uppnå hög intern och extern kvalitet hos systemet.

Arkitekten som expert eller coach

Låt oss då återgå till arkitektrollen. Det verkar finnas två synsätt på denna som har framkommit under debatten. Dessa är, i min tolkning:

• Arkitekten som expert. Arkitekten är en tekniskt erfaren person som både har ansvar och tillhörande befogenheter för att fatta projektets arkitekturella beslut. Givetvis kan arkitekten konsultera personer i teamet, men arkitekten har sista ordet. Tanken är att om en person uttryckligen har ansvaret ökar chanserna till konceptuell integritet i systemet. Konsensusbeslut är bra, men effektivitet i besluten är bättre. Arkitekten kan, men behöver inte, vara en del av teamet; externa arkitekturgrupper förekommer. Detta kan sägas representera den idag dominerande synen.

• Arkitekten som coach. Arkitekten är en tekniskt erfaren och ledarskapskunnig teammedlem som har ansvar och befogenhet att coacha teamet att fatta arkitekturella beslut. Beslut fattas i konsensus eller i majoritet. Coachens ansvar är att hjälpa teamet att nå beslut eller acceptans även i segdragna frågor. Tanken är att om beslut fattas av många huvuden ökar kvaliteten i besluten och om arkitektur är allas ansvar ökar både kvalitet och medlemmarnas engagemang. Arkitektcoachen är alltid en del av teamet. Detta kan sägas representera den utmanande synen på rollen.

Låt oss nu se närmare på arkitektrollen utifrån de kriterier vi målade upp tidigare.

Arkitekten som expert

• Lagkänsla: Övriga teammedlemmar kan lätt känna sig underlägsna och bakbundna när det finns en uttalad expert, speciellt som det är mycket oklart vad personen är expert för (ingen vet egentligen exakt vad arkitektur är). Det leder lätt till en känsla av ”vi och dom” och försämrar teamkänslan.
• Samarbete & kommunikation: När en person anses viktigare för besluten än övriga deltagare försvåras samarbete. Om expertarkitekten är utanför teamet försvåras kommunikationen väsentligt. Om experten är i teamet är kommunikation möjlig, men försvåras av att övriga medlemmar inte ser arkitekturen som ”sitt bord”.
• Kompetensutveckling: Experten är där för att vara expert och fatta beslut, inte främst för att förbättra teamets kompetens, även om detta också förekommer.
• Känslomässig utveckling: Experten är definitivt inte ansvarig för övrigas känslomässiga utveckling.

Arkitekten som coach

• Lagkänsla: Övriga teammedlemmar känner sig stärkta av att folk frågar dem och att de engageras i viktiga systemfrågor. Det totala engagemanget i varandra och systemet växer.
• Samarbete & kommunikation: Arkitekturcoachen är uttalat en del av teamet. Coachen faciliteter designdiskussioner för att öka nivån av samarbete & kommunikation, stöttar medlemmar som har problem och ser till att alla är med i båten.
• Kompetensutveckling: Coachen har uttalat ansvar för att bistå i teamets kompetensutveckling.
• Känslomässig utveckling: Genom sitt ledarskap och goda exempel bidrar coachen till deltagarnas känslomässiga utveckling.

Kontentan av denna genomgång måste bli att den arkitektroll som ofta råder idag (expertarkitekten) har mycket lite att erbjuda på många områden som är vitala för att bygga bra team och få människor att växa. Coacharkitekten, å andra sidan, är stark på alla dessa områden för att rollen är formad just för detta syfte.

Arkitektur är en aspekt av kvalitet

Om en person görs ansvarig för arkitekturen är övriga lika tydligt inte ansvariga för systemets arkitektur. Jag vill påstå att det är samma sak med arkitektur som med kvalitet. Eller t o m att arkitektur är en aspekt av kvalitet. Insikten vi har gjort på det plågsamma sättet är att om man gör en ansvarig kommer de övriga att ignorera det. Om inte arkitekten tänkte sig att skriva all kod själv eller polismässigt granska all kod får h*n svårt att behålla någon slags integritet i systemet.

Med bra team följer ansvarkänsla, att folk är proaktiva och tar ansvar för hela systemet. Detta behövs då systemen idag är alldeles för komplexa för en enskild person att förstå.De flesta har idag insett att kvalitet måste göras allas ansvar. Jag tror att vi måste inse detsamma för arkitektur. Om alla ser den som sitt ansvar, om alla uppmuntras att lära sig mer om design på olika nivåer, om alla engageras i arbetet kommer både arkitekturen och människorna att växa storartat.

Upprop till alla systemutvecklare

Jag är övertygad om att det finns många som kallar sig arkitekter som i själva verket fungerar som arkitekturcoacher, speciellt bland personer som omfattar agila värderingar; som skapar god matjord för det samarbete som vi så förtvivlat behöver för lyckade projektresultat. Men den stora arkitektmassan kommer att titulera sig ”certifierad arkitekt” och tyvärr tolka detta som ett mandat att fungera som expert och av andra kräva att behandlas som en sådan. Frestelsen till ökad status och makt, som vi människor ju ofta innerst inne drivs av, är nog lite för stor för flertalet.

Jag tror sannerligen inte att egna föreningar för de av oss som vill envisas med att kalla sig något ”finare” är det bästa sättet att skapa en fruktbar grund för lyckade och engagerande projekt. Låt oss istället samla alla systemutvecklare, i ordets vidast betydelse dvs alla typer av experter som medverkar i projekt som utvecklar program eller system, och diskutera hur vi bäst drar nytta av varandra till våra kunder och projekts gagn.

Låt detta bli mitt upprop.

Spelar det egentligen någon roll vad vi kallar oss, våra titlar och rollnamn? Förutom att stå på ett visitkort och som ett redskap för att vi ska känna att vi faktiskt betyder något här i världen, menar jag?

Anledningen till denna undran är den mejldebatt som uppstod på Agile Swedens mejllista efter det ”upprop till Sveriges IT-arkitekter” som syntes där nyligen. Många menade i den debattet att det inte spelade någon roll vad man kallade sig så länge man utförde arkitektuppdraget på bästa sätt, dvs som en aktiv deltagare och coach i projekten. Jag tar bestämt avstånd från detta.

What’s in a name? Alla vettiga människor fattar väl att en arkitekt inte bör leka Gud (en expert med absolut veto som kommer in och kör över de ”vanliga” utvecklarna) utan faktiskt ska hjälpa teamet? Eller? Mitt svar är: Jo, titeln (på rollen) spelar roll. Ganska mycket roll, faktiskt.

Varje namn ger den som hör eller läser namnet en hel räcka med associationer. Det är därför som ”Rename” är en av de mest använda refaktoriseringarna. Vi vill att en metod eller fälts namn exakt ska beskriva och omfatta metodens ansvarsområde. Vi går till utomordentliga längder att hitta på bra namn i våra program så att de stackars läsare som kommer efter oss ska kunna orientera sig någorlunda. Vi säger att namnen måste vara beskrivande.

På samma sätt menar de flesta att en roll eller titels namn så nära som möjligt bör beskriva och motsvara rollens ansvarsområde. Att ha titeln ”trubadur” om man är universitetslektor är originellt men förvirrande (det fanns en lärare på LiTH som enligt ryktet beskrev sig sålunda).

Tänk dig en situation på ett nytt projekt. Det kommer fram en respektingivande och erfaren person och presenterar sig som ”David, arkitekten på projektet”. Du sträcker på dig och tar leende David i hand.

Fundera gärna, vilka associationer framkallade denna tänkta situation hos dig? Jag gissar att du som de flesta förmodar att David är ansvarig för systemets arkitektur. Men om David ansvarar för arkitekturen, vilket ansvar har då resten av gänget i fråga om arkitektur? Just det, ingen. Vi ska inte bry våra små hjärnor om detta. Vi förväntas blint följa riktlinjerna som lagts fram av ”den store”.

Jag kanske överdriver, de allra flesta förstår väl ändå att så får det inte gå till…? Jag tvivlar. Om alla vettiga människor fattade detta skulle inte ”arkitektrollen” ha den gloria av respekt som den har idag. De allra flesta, speciellt säljare, verkar se arkitekten som den frälsare som de behöver. Att säga att det bara är sunt förnuft kan inte stämma eftersom världen inte ser ut så. Den allenarådande idag är att arkitekten är våra himlasände expert. Punkt.

Men med bara en liten namnförskjutning, från ”arkitekt”, till ”arkitekturcoach” eller ännu bättre, ”designcoach” eller ”teknisk teamcoach” skulle vi uppnå en stor värdegrundsförskjutning. För när det kommer till teknisk design, i stort som i smått, är fler huvuden är bättre än ett.

Linköpings universitet var så vitt jag förstår först ut med Data som ett civilingenjörsprogram. När jag var student var de kända som föregångare vid antagningsprocessen till läkarlinjen. Man frågade helt enkelt ut kandidaterna för att i någon mån kunna bedöma om dessa personer kunde växa ut till personer man skulle vara villig att anförtro sitt liv till i framtiden (känns inte helt orimligt). I mitten på 90-talet startade Ingemar Ingemarsson IT-programmet där man till stor del använda PBI (problembaserad inlärning) vid undervisningen som ett sätt att förankra kunskaperna i verkliga fallstudier.

Och nu går man före igen.

I senaste numret av LiU Magasin (1-2007) kan man läsa att LiU i höst startar ett ”treårigt kandidatprogram med fokus på att utveckla studenternas kreativa och praktiska hantverkskunnande i programmering”. ”Innovativ programmering” är namnet på det nya programmet och Lars Degerstedt heter den ansvarige (se bild).

Äntligen!

• Äntligen någon som förstår att bra programmerare inte skapas genom att tänka utan genom att göra tillsammans; mäster, gesäll och lärling.
• Äntligen någon som inser att fem års teoretiska studier har en begränsad nytta vid programmering.
• Äntligen någon i den akademiska världen som insett att programmering till största del är ett hantverk.

Som de brukade säga i vinjetten till TV-serien Fame:

”You want flexibility!? Well, flexibility costs. And right here is where you start paying… in craftsmanship”.

Tror att det var så lärarinnan sa i alla fall.

Lars Degerstedt, jag utnämner dig till min hjälte för dagen.