Hittade en spännande studie om hur företag som inte bara använder öppen mjukvara utan också lägger tid på att bidra till den ökar sin effektivitet eftersom företaget samtidigt lär sig mjukvaran på ett djupare plan. En tänkvärd studie som stöttar en ide som jag haft ett tag kring delaktig arkitektur och jordnära arkitektur. Det är alltid kull att hitta stöd för sina idéer i forskning.

Rapporten berör mjukvara och hur delaktighet i öppen mjukvara ger ökad effektivitet i företag men konstigt nog finns det en del relevanta likheter mellan mjukvara som används i en affärsaktivitet och Arkitektur. Kanske oväntat men ändå…

Mjukvarans påverkan på en affärsaktivitet Fundera lite på vad en specifik mjukvara innebär för det arbete som utförs där den används.

Först är det förstås en hjälp på något, annars hade man inte använt den. Men den är samtidigt också en begränsning eftersom den nästan aldrig passar perfekt, och om den gör det just nu blir förmodligen sämre vid förändring av aktiviteten. Man kan se det som att verktygen ger stöd men samtidigt ramar in utrymmet för att lösa aktiviteten effektivt (eller mer effektivt än utan).

Det är rimligt att det uppstår ett gap mellan verktygets nuvarande stöd och hur man skulle vilja att den ger stöd, ett gap som skapar önskemål om förändring. Detta kan uppstår om aktiviteten förändras av vilket som helst skäl, plötsligt behöver mjukvaran anpassas för att bidra bra.

Rapporten berör vad som händer om anställda på företaget själv ges möjlighet att jobba med att lösa den förändring som önskas i mjukvaran jämfört med om någon annan tar emot den, gör jobbet och kommer med en uppdatering. Nyckeln är den kultur som finns inom Öppen Mjukvara, där vem som helst kan bidra men någon som verkligen kan bedömer bidraget och ger feedback och därmed hjälper bidragsgivaren att utvecklas. Det kallas ”Learning by Contributing” eller Lärande genom att Bidra. Genom denna lärandeprocess kommer den som bidrar att få en större insyn i mjukvaran som hjälper företaget att bättre förstå men också att bättre utnyttja den funktion som mjukvaran ger och på så sätt höjs effektiviteten.

Arkitekturs likhet med mjukvara

Tänker man efter lite så inser man att arkitektur har stora likheter med ett affärssystem på vissa relevanta punkter (jag påstår inte på något sätt att det är samma sak!).

Fokus här är på aktiviteter som rör företagets förändring och utveckling medan affärsmjukvaran berör aktiviteter som sker i drift eller produktion. Men aktivitet är aktivitet oavsett vad den syftar till.

Liksom ett affärssystem innebär Arkitektur ett stödi förändringsarbete på olika sätt. Arkitektur visar på en riktning och en målbild och flyttar fram startpunkten jämfört med att börja från noll. Samtidigt innebär arkitekturstyrningen att förändringen som skall göras inte kan ske helt fritt utan begränsas. Man får ett lösningsutrymme att jobba inom, Arkitekturen ramar in uppgiften (i syfte att nå företagsgemensamma mål och strategier men ändå en begränsning för aktiviteten)

Precis som med mjukvara skapas det hela tiden gap som driver behov av förändring. Och precis som rapporten beskriver är det här magin sker.

Ett nytt grepp kring Arkitektur

Detta är otroligt spännande. Jag har länge haft en idé om hur jag vill jobba med arkitektur som påminner starkt om hur man jobbar med öppen mjukvara under en period.

Tänk er att arkitekturdokumentation aktivt används som ett led i företagets tekniska dokumentation, dvs arkitekturen har en reell och konkret innebörd för många som inte är arkitekter. Detta innebär ett ökat mervärde för organisationen men normalt också en ökad belastning på arkitekten som skall hålla allt material uppdaterat.

Vad händer om vi tar in principerna från öppen mjukvara; Vem som helst kan bidra men en sakkunnig granskar, ger feedback och slutligen godkänner ändringarna?

När en tekniker gör en förändring skall det dokumenteras. Så långt är vi säkert överens. Traditionell kopplar man aldrig samma arkitektur med teknisk dokumentation eftersom bara arkitekten jobbar med arkitektur och då får lägga för mycket tid på att följa John med verkligheten. Dessutom kommer frågan upp om vad som är arkitektur och vad som inte är det, vilket är en djupt filosofisk diskussion som inte har några bra svar och slutligen innebär att man skyr man icke-arkitektoniska element som pesten, det får inte finnas i arkitekturmodellen. Detta är normalt viktigt för skapa en gräns mellan det som Arkitekten bestämmer över och det som Teknikern bestämmer över.

Men nu skall vi prova ett nytt grepp. Vi struntar i vad som är arkitektur och inte, vi drar inte den gränsen, i stället fokuserar vi på att utveckla kulturen kring arkitektur och att gemensamt ge ökat mervärde för den organisation som berörs. I en sådan värld suddas gränserna kring vem som beslutar vad ut och polariseringen mellan arkitektur och övriga minskas.

Det går inte att komma i från att den tekniker som genomfört en systemförändring också vanligen är sakkunnig kring förändringen. I det nya greppet dokumenteras inte förändringarna i ett separat dokument utan som en del av arkitekturen som då också blir en naturlig del av den dokumentation över systemen som finns och ändå skall finnas – man dubbeldokumenterar inte, man bara gör det i arkitekturmodellen. Diagram från modellen kan sedan användas i eventuella kompletterande rapporter som skrivs. Teknikern ritar själv sina ändringar i arkitekturmodellen, Arkitekten granskar, ger återkoppling och slutligen godkänner genom en ömsesidig lärandeprocess. Detta innebär en inledande pedagogisk ansträngning för Arkitekten och en startsträcka för teknikern, modellen är inte bara en bild som kan ritas lite som man vill, det är en modell med stringent notation. Teknikern behöver lära sig att rita i den notationen enligt de mönster som Arkitekten har tagit fram. Detta innebär också att teknikern blir en hejdundrare på att läsa diagrammen och därmed djupare förstå vad som står när hen får ett diagram att ta ställning till, t.ex. vid granskning av en planerad ändring eller vad en kollega gjort. Det ger också en sammantagen dokumentation som hänger samman via arkitekturen.

Har man väl kommit så här långt är steget vidare lätt att ta. När Teknikern börjar planera en förändring börjar hen också rita på den och innan förändringen sker kan Arkitekten och andra (eftersom många nu börjar kunna läsa dokumentationen) ge återkoppling och styrning.

Här berör vi två olika områden som jag driver; Jordnära Arkitektur som innebär att jobba med arkitektur på ett sätt så så att det är meningsfullt för de flesta på företaget och Delaktig Arkitektur där arkitekten släpper in andra att delta i arkitekturarbetet vilket är skapar en gemenskap kring arkitektur.

Med jordnära arkitektur och en fungerande delaktighet löser man flera ständigt återkommande problem som Arkitekturfunktionen vanligtvis står inför. Dels svårigheten att följa vad som händer i företaget på olika nivåer, det pågår ofta en kamp om att får vara med från början och inte komma in sent vid förändringar. Dels svårigheten med att ha en bra karta över vad som är på gång och hur landskapet faktiskt ser ut.

Nu kan man hävda att allt blir enklare om man bara höjer blicken lite, blir lite mer abstrakt och arkitektisk i sitt arbete, ritar på ”rätt nivå”. Jag hävdar att ökad abstraktion inte hjälper men att det möjligen döljer. En modell av verkligheten blir alltid inaktuell om inte de som jobbar med att förändra verkligheten också bidrar till att modellen är uppdaterad, och intresse för det är svårt om man inte samtidigt själv får ett direkt och konkret värde. Abstraktioner bidrar bara till att gör det lite mer suddigt i kanten så att förändringarna inte syns eller påverkar så snabbt.

Man kan också hävda att man bara skall ha med sådant som är stabilt och inte rör sig i sin arkitektur, här tänker jag på Förmågor (VAD) i kontrast till processer (HUR) och på så sätt ducka för problemet. Som jag ser det blir arkitekturen meningsfull när mottagare i verkligheten förstår den och få medarbetare är så bra på att se sin plats i en VAD värld.

I bägge fallen riskerar man att tappa fotfästet från verkligheten och sväva upp i det blå, vilket är en större fråga än att arbetet man gör inte blir så värdeskapande. Sociala grupper har en tendens att stöta bort den man inte förstår och därmed driver ett ökande gap mellan arkitektfunktionen och övriga. Grupperna polariseras allt mer i en spiral och vid en punkt blir det svårt att överbygga kommunikationen.

Jordnära Arkitektur

Jordnära arkitektur innebär att arkitekturmodellerna medvetet skall utformas så att så många som möjligt kan hitta delar och områden där man kan identifiera sig och helst kunna ha åsikter om. Detta fungerar som en ingång till modellen som annars kan vara övermäktig att läsa och förstå.

Detta innebär inte att man inte också har abstrakta modeller. I en bra modell bör man kunna navigera abstraktionerna till konkreta modeller och på så sätt kunna dra slutsatser. Den som just nu tänker att det är svårt att göra i Visio bör notera att jag skriver modell, inte diagram. Arkitektur kräver ett modellverktyg för att blir bra, men det får adresseras i ett annat inlägg.

Delaktig Arkitektur

I en Delaktig Arkitektur låter man arkitekturen bli en påtaglig del av verkligheten även om det råkar innebära att de mest detaljerade delarna av modellen inte är arkitektur men i stället låta de berörda bidra aktivt till modellen, inledningsvis som dokumentation men på sikt även för att planera ändringar. Detta kan ofta upplevas riskabelt men efter 30 år av framgångsrik öppen källkod kan man dra slutsatsen att det är en fungerande modell. Verktyg för att lösa detta finns som kombinerar webbaserad teknik med lokalt installerad program.

Slutkläm

Med Jordnära och Delaktig arkitektur har man alla förutsättningar att skapa en relevant och kontinuerligt uppdaterad arkitektur med bred förankring, med stor delaktighet och som många har möjlighet att läsa, förstå och ta till sig. Samtidigt skapar den ömsesidiga delaktigheten möjlighet för Arkitekten att bli mer påtagligt medvetande om andras perspektiv och bättre förstå när man bör skall blanda olika personer för att få en realistisk bild av ett problem.

Detta innebär också möjlighet till en spiral med ökat ömsesidig förståelse och goda förutsättningar att bilda en kultur där arkitektur inte är någon annan nästan utomstående som skall peka med handen utan i stället tillför viktiga strategiska och holistiska perspektiv på vårt gemensamma arbete.
En bra balans mellan teknikerns detaljkunskaper och alla problem och begränsningar det innebär med arkitektens holistiska och strategiska perspektiv.

Dessutom blir det en punkt för samarbete och kommunikation som river murarna som finns i en polariserad organisation.