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ål-arkitektur 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 arkitekt-team

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

Ett centralt arkitekt-team 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 arkitekt-teamet, 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 projekt-arkitekterna 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 projekt-teamet självt, inte av ett separat arkitekt-team

Centrala arkitekt-team har vanligen en officiell auktoritet. Men de ignoreras ofta eller kringgås. Orsaken är följande: När det som arkitekt-teamet tar fram skall tillämpas i projekten fungerar det inte så bra. Arkitekt-teamet ä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 arkitekt-teamet.

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 projekt-arkitektur skapad och ägt av ett separat arkitekt-team 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. Arkitekt-teamet måste undvika att suga upp alla de bästa och smartaste utvecklarna

Ledningen brukar vilja överföra de skickligaste utvecklarna till arkitekt-teamet. 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 elit-team. 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 arkitekt-teamet. Båda teamen, både det centrala arkitekt-teamet 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.