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.
The Blogging Terrier | Den bloggande terriern 
Mina tankar efter att ha läst detta är:
1. Arkitekten som expert
Jag håller helt med dig. En kille som med hög svansföring skall ta alla beslut rörande arkitektur är helt fel för projektet. Det blir snarare ett hinder. Däremot om utvecklarna delat upp sig i två läger som tycker olika, då tycker jag att arkitekten kan vara med och lösa upp knuten och i värsta fall bestämma vilken väg man skall välja bland de två. I din coachroll så saknar jag just denna aspekt att ytterst vara ansvarig för besluten. Jag anser att arkitektrollen skall vara delegerande/stödjande för de som arbetar med lösningar.
2. Perspektivet är alltför begränsat till utvecklingsprojekt
Problemen som jag ser i branschen är inte alltid inne i ett utvecklingsprojekt. Arkitektrollen är större än bara utvecklingsprojekt. Om jag tittar tillbaka så är det ofta de verkliga hindren i för att få ett gott resultat ligger utanför själva utvecklingsprojektet.
I övrigt tycker jag att det är synd att vissa arbetsuppgifter skulle uppfattas som “finare” än andra. Det tycker inte jag. Däremot för min egen del kan jag tycka att vissa frågor intresserar mig som person och har alltid intresserat mig. Jag märker också att jag är bättre på dem än många andra, men även inom det området har jag också föredömen/mentorer som är bättre och som jag lär mig av. Sedan att dessa uppgifter är “högre” upp i värdekedjan är bara ett lyckligt sammanträffande för mig.
Jag satsar numera på arkitektrollen med inriktning på ECM och tjänstebaserad arkitektur(SOA). Därutöver vill jag speciellt ägna mig åt frågor som kallas “Human Dynamics” inom IASA och jag hoppas att jag kan bli respekterad för det valet på samma sätt som jag respekterar andra som gjort andra val.
Har du i den roll som du valt problem med att respektera det? Och att vi tillsammans vill utveckla den rollen genom att gå samman?
Pingback: Datateknikelit :: Arkitektrollen ifrågasätts :: March :: 2007
Jag tror att vi måste skilja på utveckling och allmänt systemägande. Den roll som förespråkarna av arkitektrollen beskriver liknar mycket en form av aktiv förvaltning – en sorts kunniga kravställare – jmfr med förvaltare/beställare på fastighetsbolag med ingenjörskunskaper.
Vi som envisas med att förespråka programmeringen etc, ser främst vårt värde i själva processen att koda, inte att hålla översikt över stora systemstackar.
Angående Andrés kommentar så ser jag inte någon direkt konflikt mellan den lite mer verksamhetsorienterade arkitekten som du strävar efter och den mer grupporienterade coachen som Jocke (och även jag) förespråkar. Däremot tycker jag att behovet av duktiga och erfarna coacher är en stor bristvara i vår bransch medan det, i min mening, kryllar av folk som tänker “SOA” och “Verksamhetsmodeller”. Visst finns det behov av ett sådant fokus och det är kul att duktiga och agila personer som du André och Peter Tallungs nosar på det området, men bristen är mer skriande på utvecklarsidan. Där behövs erfaranheten, det sociala ansvaret och mentorskapet mest. Att erfarna utvecklare lämnar implementationsarbetet till förmån för visionerande/modellerande tror jag kan vara skadligt för programmeraryrkets framtid.
Jag tror att Måns har kommit något på spåren. Vi pratar nog förbi varandra mer än att vi verkligen har olika ståndpunkter. Vi har inte tillräckligt tydligt definierat vilka roller vi egentligen pratar om.
1. Ett läger, där Jocke ingår, pratar om en ren systemutvecklingsroll, eller snarare en ren programmeringsledarroll, för kravformulering, avgränsning, samverkan med alla intressenter och så vidare ligger nog utanför, precis som i XP där man placerar detta hos någon man kallar för “kunden”.
2. En annan roll är en mera utpräglad systemutvecklingsroll, i dess (i min mening) rätta betydelse, utveckling av ett visst avgränsat itstöd. Där måste kravformulering (obs ej kravställande), avgränsning, samverkan med alla olika intressenter och mycket tät samverkan med verksamhetsutveckling ingå. (Mer än samverkan, utveckling av en viss verksamhet och utveckling av dess it-stöd är två sidor av samma mynt).
Observera att jag inte påstår att detta måste vara två olika personer eller ens två olika roller, bara att det är två olika betydelser man kan lägga i termen arkitekt.
Enligt min mening är roll nummer ett inte en arkitektroll. Roll nummer två har däremot en nära analogi med en “riktig” arkitekt (i byggbranschen), därför gillar jag termen arkitekt för detta.
Det finns en tredje roll
3. Enterprise Architect, som nog egentligen ligger utanför den här diskussionen, men som har en nära analogi med en stadsarkitekt, eller arkitekt för en stadsdel. En Enterprise Architect ser en organisation och dess IT-stöd som två oupplösligt förenade saker, som måste förstås och hanteras tillsammans.
Jag tycker att vi gör ett stort misstag om vi tror att roll 2 och 3 är verksamhetskonsulting. Roll 2 är systemutvecklingsroll (med mycket inslag av och tät samverkan med verksamhetsutveckling). Roll 3 är både verksamhets- och systemutveckling fast på övergripande nivå. (Övergripande nivå måste inte, och skall inte enligt min mening, betyda luddigt, högsvävande utan markkontakt)
Jag håller med Måns om att det finns många som pratar, men det är mycket snack och liten verkstad. Jag vill verka för att skapa en ny generation EA och arkitekter i betydelse nummer två med mera EA-kunskap, med ett mera praktiskt angreppsätt, mera fältmässiga om man så vill än dagens.
Jag håller på att dra igång ett slags utvecklingsprogram för seniora systemarkitekter som vill utvecklas åt det hållet. De kommer att bli bättre systemarkitekter (i betydelse nummer två), och på sikt kunna fylla en EA-roll.
/Peter Tallungs
Skulle vilja lägga till en sak som är en fördel med en arkitekt som coach: utvecklarna känner sig då delaktiga i arkitekturen och det är inte lika stor risk för en mental låsning vid att “jag bryr mig inte om det inte fungerar så bra, det är ändå inte mitt fel”. Helst är ju hela laget tillräckligt duktiga för att skapa liknande arkitektur själva…