Hur kan vi organisera arkitektarbetet?

Hur kan vi organisera arbetet med informationsarkitekturen i en större organisation? Vad är viktigt för att få samverkan med de olika parterna att fungera? Något vi kan vi skippa på en gång är den traditionella toppstyrande arkitektfunktionen.

Men hur kan vi då göra? I denna artikel går jag igenom tänkbara organisationsmodeller samt ger grundläggande förhållningssätt för den samverkan vi behöver få till i våra organisationer.

De finns en traditionell organisationsmodell för arkitekturarbete i en organisation. Man tänker sig att en centralt placerad grupp av arkitekter tar fram en målarkitektur för olika områden och att denna grundritning sedan ska följas av de olika projektteamen. Denna toppstyrning fungerar inte alls. För att ett arkitekturarbete skall fungerar måste det drivas som en organisk och kontinuerlig samverkan med och mellan organisationens olika funktioner och utvecklingsinitiativ.

Så den traditionella toppstyrande arkitektfunktionen är ett alternativ vi kan skippa på en gång. Vilka andra organisationsmodeller kan då fungera? Låt oss gå igenom och jämföra några alternativ.

Organisationsmodell 1: Självorganiserande team

Team som är skickliga på att samverka och kommunicera kan operera utan central auktoritet. Oftast har en eller några få personer i teamet en viss grad av översiktligt ansvar för den övergripande strukturen. Det är viktigt att en sådan person är arkitekt/utvecklare och kommunikatör i samma person. Den personen ska inte ta designbesluten ensam utan behöver kontinuerligt samverka och kommunicera med berörda parter både inom och utanför teamet.

Ofta uppstår en sådan roll spontant. Teamet måste i så fall ha en kärna av ett fåtal personer med tillräcklig kompetens för att ta de större designbesluten. Detta kan fungera, åtminstone i en mindre organisation. Men det kräver som sagt en hel del av teamet.

Organisationsmodell 2: Informell samverkan mellan självorganiserande team

När en övergripande struktur spänner över flera områden börjar team som har beroende till varandra att samarbeta på ett informellt sätt. Varje team gör upptäckter som leder till idéer för den övergripande strukturen. De olika möjligheterna diskuteras av en informell kommitté med representanter från de olika teamen. Teamen rör sig framåt tillsammans som en lös sammanslutning.

Denna ordning kan fungera när det är få team som skall koordineras, när de alla är motiverade att koordinera sig, när deras designförmågor är jämförbara och deras behov av struktur tillräckligt lika för att tillgodoses av en gemensam övergripande struktur.

Det som effektivt saboterar ett sådant samarbete är när incitament att bli klar i tid och på budget övertrumfar nytta och långsiktighet. Vilket tyvärr är vanligt i många organisationer. Då tvingas teamen att var och en köra sitt eget race.

Organisationsmodell 3: Ett centralt arkitektteam

När en strategi skall spänna över många team behöver vissa beslut tas centralt. Då behövs ett centralt arkitektteam.

Ett centralt arkitektteam bör arbeta på ett kollegialt sätt tillsammans med de olika teamen. Man behöver ha inställningen att man stödjer teamen med att koordinera och harmonisera övergripande strukturer och andra frågeställningar mellan teamen.

På ett organisationsschema ser detta ut som det traditionella toppstyrande arkitektteamet, det ökända ”elfenbenstornet”, men det får inte förväxlas med detta. Det är i själva verket ett helt annat sätt att styra, i varje aktivitet. De centralt placerade arkitekterna arbetar tillsammans med projektarkitekterna och utvecklarna i teamen, vilka experimenterar tillsammans med olika team för att få fram bästa övergripande strukturen.
Kort sagt, de centralt placerade arkitekterna gömmer sig inte bakom sina PowerPoint. De är inte rädda för att smutsa ner händerna med riktigt arbete tillsammans med utvecklarna i teamen.

Grundläggande förhållningssätt för samverkan

I det följande listas några grundläggande förhållningssätt för den samverkan som behövs i arkitekturarbetet i en organisation.

1. Arkitekturen för ett visst utvecklingsinitiativ måste ägas av projektteamet självt, inte av ett separat arkitektteam

Centrala arkitektteam har vanligen en officiell auktoritet. Men de ignoreras ofta eller kringgås. Orsaken är följande: När det som arkitektteamet tar fram skall tillämpas i projekten fungerar det inte så bra. Arkitektteamet är då vanligen inte så mottagligt för återkoppling. De är avskärmade från den praktiska verkligheten och har sällan de praktiska kunskaperna som skulle behövas för att kunna engagera sig. Fenomenet är så vanligt att det fått ett namn: ”Ivory Tower Architects”. Därmed har utvecklare ofta inget annat val än att ignorera eller kringgå det centrala arkitektteamet.

Om den strategiska designen i stället växer fram inom projektteamet når den ut mycket mera effektivt, förutsatt att teamet kommunicerar och samverkar med sin omgivning på ett bra sätt. Designen blir då relevant för projektet och får den naturliga auktoritet som följer med ett genomtänkt community-beslut. De centrala arkitekterna är mindre av poliser och mera av facilitatorer, kommunikatörer och coacher för att stödja projektet. De hjälper teamen med att se och beakta de bredare och långsiktiga perspektiven i verksamheten.  

För att skapa en övergripande struktur måste man ha en djup förståelse för projektet och för domänen. De enda som kan nå det djupet av förståelse är medlemmarna i teamet. Det förklarar varför en projektarkitektur skapad och ägt av ett separat arkitektteam sällan fungerar.

2. Arkitekturen måste tillåta ständig utveckling

Om arkitekturen är låst i onödan så får inte teamet den flexibilitet de behöver för att lösa det problem det har ansvar för. En överordnad harmoniseringsprincip kan behövas, men arkitekturen måste kunna utvecklas och förändras i takt med att projektet lever sitt liv.

3. Arkitektteamet måste undvika att suga upp alla de bästa och smartaste utvecklarna

Ledningen brukar vilja överföra de skickligaste utvecklarna till arkitektteamet. De vill få en hävstångseffekt på deras talang. Utvecklaren själv är tilltalad av möjligheten att få ett bredare inflytande och/eller arbeta med ”mera intressanta” problem. Det är också prestigefyllt att vara medlem i det som upplevs som ett elitteam.

Problemet blir då att bara de mest oerfarna utvecklarna blir kvar för att bygga och vidareutveckla applikationerna. Men att bygga och förvalta en bra applikation kräver erfarenhet.
Ett annat problem är att utvecklare med mest kunskap om domänen sällan blir medlemmar av arkitektteamet.

Båda teamen, både det centrala arkitektteamet och utvecklingsteamet, kräver utvecklare med designförmåga och domänkunskap.

4. Strategisk design kräver minimalism och ödmjukhet

Destillering och minimalism är viktig för all design, men mest av allt för den strategiska designen. Det är en kärna i arkitekturarbetet. Men allra viktigast är ödmjukheten, att inte låsa fast sig, utan lyssna, ompröva och fördjupa designen kontinuerligt.

Akta dig för masterplanen!

Till sist vill jag citera Christopher Alexander, byggnadsarkitekten och designteoretikern, fadern till idén om mönster inom design:

The master plan attempts to set down enough guidelines to provide for coherence in the environment as a whole – and still leave freedom for individual buildings and open spaces to adapt to local needs.

…in practice master plans fail—because they create totalitarian order, not organic order. They are too rigid; they cannot easily adapt to the natural and unpredictable changes that inevitably arise in the life of a community.

… The attempt to steer such a course is rather like filling in the colors in a child’s coloring book…. At best, the order which results from such a process is banal.

…Thus, as a source of organic order, a master plan is both too precise, and not precise enough. The totality is too precise: the details are not precise enough.

… the existence of a master plan alienates the users [because, by definition] the members of the community can have little impact on the future shape of their community because most important decisions have already been made.

Från: The Oregon Experiment (Alexander et al. 1975) 

                                      

Alexander och hans kollegor förespråkar i stället en uppsättning principer som alla medlemmar av en community ska tillämpa för varje steg i den gradvisa framväxten av det man utvecklar.
Då växer det fram något av en organisk ordning, som är väl anpassad till omständigheterna.

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 10 februari. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

PS Vi har tyvärr varit tvungna att ta bort möjligheten att kommentera på artiklarna för en tid. Har du tankar om innehållet i artikeln som du vill dela? Välkommen att kommentera på vår linkedin där lägger vi ut en post vid varje publiceringstilfälle. Eller skicka ett mail till Peter Tallungs: peter.tallungs(at)irm.se