Agilt arkitekturarbete

januari 12, 2010

Under den långsamma övergången till ett agilt arbetssätt har en del av de traditionella rollerna och artifakterna visat sig vara problematiska. Inget arbete har stötts och blötts så mycket som arbetet med ”arkitekturen”. Frågan hur man arbetar med en arkitektur i ett agilt sammanhang är ganska knepig att besvara, men jag tänkte göra ett försök.

Arkitekturbegreppet

Ralph Johnson säger (fritt översatt) i Martin Fowlers artikel Who needs an architect:

Arkitekturen omfattar det som utvecklare anser viktigt för att kunna förstå hur systemet fungerar och kunna delta i vidareutvecklandet av det.

Vissa delar av arkitekturen är på låg nivå, andra på högre nivå. Om vi måste anpassa en produkt efter hur den integrerar med befintliga tjänster eller produkter är lösningen för det en del av produktens arkitektur, men även hur vi väljer att kommunicera mellan mindre komponenter inom vår produkt är en del av arkitekturen. På lägsta nivån är språkval och runtime-miljö även där en del av arkitekturen, med det inte sagt att den aspekten behöver vara enhetlig genom hela produkten men det är en arkitekturell aspekt på det vi gör. Kort sagt vi har arkitektur på alla olika nivåer av abstraktion.

Den agila ansatsen

I agila sammanhang är man mån om att man inte ska lita för mycket till gammal kunskap. Under utvecklandet av en produkt är vi i ständigt lärande. Den nya kunskapen vill vi, så fort det är möjligt, införliva i produkten. Därför försöker vi göra allt arbete kontinuerligt under utvecklandet. Kommer man till en situation med okända behov är det egetligen inte något problem, det tillhör det dagliga agila systemutvecklingsarbetet att utreda behov. På samma sätt förhåller det sig med arkitekturarbetet, vi kommer att vara tvungna att kontinuerligt se över vår arkitektur. En agil arkitektur ska svara mot de behov vi uppfyller nu, inte mot de vi kanske uppfyller imorgon, men inte heller mot de vi uppfyllde igår. Arkitekturen är på tok för viktig för att vi ska kunna nöja oss med att bara ägna den uppmärksamhet i början av utvecklingsarbetet.

Med det inte sagt att agila utvecklare inte kan tänka efter före. Många av dem jag känner gör en första, rimligt initierad, gissning innan de sätter igång med utvecklingsarbetet. De aktar sig bara för att tro att den initiala gissningen är rätt arkitektur och förbereder sig istället för att den ska kunna förändras.

Två skrån med olika fokus

Inom den agila rörelsen har det varit stort fokus på tvärfunktionella arbetslag som arbetar koncentrerat med en produkt och att låta arbetslaget gemensamt ta ansvar för det tekniska helhetsperspektivet för produkten.
Arkitektskrået har samtidigt rört sig längre bort från tekniken och man pratar om strategisk IT och verksamhetsutveckling. Här fokuserar man mycket på synergieffekter av olika integrationsstrategier och, i viss mån, verksamhetsmål med IT-förvaltning alltid sett över en hel produktportfölj. Där skiljer sig de åt, olika horisont och olika perspektiv.

Spekulativ och oavsiktlig design

Att dessa två, tillsynes välvilliga, rörelser har svårt att finna gemensam mark beror på följande problematik. De agila arbetslagen vill låta arkitekturen växa fram allt eftersom behoven manifesteras och de vill själva välja hur de tekniskt ska implementera de verksamhetskrav som framställs samtidigt som arkitektskrået gärna ser sig som ett kompetent tekniskt roder för hela verksamheten där de bidrar med tydliga riktlinjer för hur vissa aspekter av systemet ska implementeras.

Arkitekterna uppfattar här de agila utvecklarnas process som något som leder till en oavsiktlig design eftersom designen bara blir det som behoven påkallar. Agila utvecklare, å sin sida, tycker att det arkitekterna gör sig skyldiga till är spekulativ design som, allt som oftast, visar sig vara onödigt komplex och tungrodd.

Agilisterna uppfattar att arkitekterna fråntar utvecklarna designansvaret vilket leder till osäkerhet bland utvecklarna när man upptäcker svagheter i designen. Arkitekterna å sin sida tycker att utvecklarna inte är kompetenta nog att förvalta helhetsdesignen.

Det är alltså inte en argumentation om huruvida arkitekturkompetens är viktig eller ej – båda läger tycker att den är av avgörande betydelse. Konflikten ligger i hur den ska tillämpas.

Fördomarnas ursprung

För att förstå vad dessa ömsesidiga fördomar bottnar i måste man se till de olika grupperingarnas vardag. I lite mer traditionellt ledda systemutvecklingsorganisationer tillhör det god sed att uppmärksamma talangfulla programmerare och genast göra dem till arkitekter eller, t.o.m. projektledare (ja, jag har sett det hända). Kvar blir, generaliserat, oerfarna och mindre engagerade programmerare som inte har erfarenhet nog att själva fatta goda designbeslut. Faktum är att de ofta inte heller är kapabla att förstå och följa de direktiv som överlämnas från arkitekterna. För att komma till rätta med utvecklarnas tillkortakommanden har man typiskt en designfas. Ett par arkitekter samarbetar (i bästa fall) för att fixera grundtankarna i produktens arkitektur. Vikten av att tänka efter före är enorm – just eftersom man inte kan lita på att utvecklarna kommer att själva kunna förvalta designen aktivt.

I agila sammanhang ser det lite annorlunda ut, som talangfull programmerare blir man inte arkitekt, istället är den viktigaste uppgiften att agera designcoach och parprogrammeringspartner i arbetslaget. Kompetensen inte bara uppmärksammas, den anses t.o.m. så viktig att man inte vill isolera den till någon viss person. Man tar den initiala kostnaden för att sprida kompetensen eftersom man vet att det kommer att betala sig på kort tid. Faser finns inte inom agil utveckling, istället strävar man efter att kontinuerligt hålla uppmärksamheten på produkten som helhet.

Som vanligt kan vi konstatera att båda läger har kommit till en insiktsfull, men fördomsfull, slutsats baserat på den vardag man befinner sig i. Den stora skillnaden är att de agila arbetslagens vardag kan beskrivas som samarbetsorienterad och platt medan arkitekternas vardag baseras på en traditionell ledarskapssyn enligt command-and-control och top-down hierarkier.

Annonser

4 svar to “Agilt arkitekturarbete”

  1. Anders said

    Stiligt, Måns!

    Här poängterar du några områden som kanske inte penetrerades fullt ut i paneldebatten vi hade tidigare. En dylik bloggpost är ett bra sätt att spinna vidare debatten.

    Arkitekturen på den lägre abstraktionsnivån är jag helt enig att den ska förvaltas gemensamt av ett team, och inte en dedikerad ”applikationsarkitekt”.

    Vad gäller den mer strategiska arkitekturen som du adresserar under rubriken ”Två skrån med olika fokus” behöver man applicera agila principer i större utsträckning än vad som sker idag. Till detta finner vi inget egentligt stöd i befintliga agila metoder.

    Några punkter som enl mig förenar arkitekt o agilist:
    * Generalist snarare än specialist
    * Förvaltningsbarhet – gemensam syn på långsiktighet och att sudda ut den förhatliga gränsen mellan projekt och förvaltning.

    En skiljelinje är väl kanske att i det agila utvecklingsarbetet är fokus på en produkts utveckling och dess kontinuerliga tillväxt. Arkitektens fokus är att integrera flera produkter att stödja de övergripande verksamhetsprocesserna. I detta arbete behöver vi kunna prioritera mellan standardsystem och egenutvecklat, samt hybrider där emellan. Då måste vi också åtminstone beakta framtida tänkbara behov. Hur mycket är en grannlaga avvägning.

    Jag tänkte länka din artikel i ett arkitektforum på LinkedIn om du inte misstycker.

  2. Tack Anders!
    Jag håller med om att de agila metoderna inte, på något tydligt vis, besvarar hur man ska jobba med arkitekturfrågor som spänner över flera produkter. Men man kan dra slutsatser om hur den agila ansatsen bör vara genom att se på hur de löser andra problem.

    Framtida tänkbara behov… jag känner mig tveksam till att man ska agera på dem nu. Kanske om man är besvärad av för mycket tillgångar. Bygg istället för att kunna skjuta upp valet till dess man vet hur det blir med dem behoven.

    Du får givetvis gärna länka till artikeln.

  3. Tack för en mycket bra post! Det här resonemanget kommer jag ha konkret användning av i praktiken, i pågående projekt.

Kommentera

Fyll i dina uppgifter nedan eller klicka på en ikon för att logga in:

WordPress.com Logo

Du kommenterar med ditt WordPress.com-konto. Logga ut / Ändra )

Twitter-bild

Du kommenterar med ditt Twitter-konto. Logga ut / Ändra )

Facebook-foto

Du kommenterar med ditt Facebook-konto. Logga ut / Ändra )

Google+ photo

Du kommenterar med ditt Google+-konto. Logga ut / Ändra )

Ansluter till %s

%d bloggare gillar detta: