Människors samverkan och dess påverkan på arkitektur

Det här är första delen i en serie artiklar om hur Archify ser på IT-arkitektur. Med värderingar och reflektioner om hur vi bygger bra IT-system som är följsam med förändringar.

Som IT-arkitekt har jag som syfte att bygga bättre IT-system. Att göra verksamheter bättre med hjälp av IT, helt enkelt. Det är mitt perspektiv. Det är sällan enbart nya processer, teknologier och verktyg som gör att vi kommer göra bättre IT-system. Det är också vi människor och hur vi interagerar som är av avgörande betydelse. Ibland saknas insikter och medvetenhet om det. Vad kan det få för konsekvenser? Hur kan en ökad medvetenhet om det bidra till bättre IT-system? Min teori är att människors samverkan kan begränsa de möjligheter vi har för att skapa den IT-arkitektur vi skulle vilja.

Agila metoder

Det skulle vara olyckligt om det är våra processer och verktyg som avgör hur vi bygger system. Det skulle ju kunna tolkas som att vi människor inte är i full kontroll, även om det är människan som väljer de processerna och verktygen. Men en relevant fråga är varför vi väljer att följa en specifik struktur. Jag kan ofta se att vi oreflekterat följer t ex en metod såsom den är föreskriven, och att vi på vägen glömmer bort varför och vad den egentligen syftar till. Jag tänker främst på den vanligaste metoden som används inom vår bransch idag, Scrum. I det agila manifestet finns följande citat som poängterar:

”Individuals and interactions over processes and tools”

— The Agile manifesto

Människor och deras interaktion alltså. Interaktion tolkar jag likställt med kommunikation, hur vi människor kommunicerar med varandra. Så vad har det med arkitektur att göra och hur kan det påverka våra IT-system?

Conway

Jag ser väldigt ofta att Conways Law regerar när organisationer bygger IT. Det behöver inte vara dåligt. Men avsaknad av medvetenheten kan göra att det blir dåligt, lite plumpt utryckt. Conways lag brukar beskrivas med följande citat från grundaren av detsamma:

"organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."

— Melvin Conway, 1967

De IT-system vi bygger i en organisation tenderar att speglas av hur organisationen ser ut. Conway menar att förmågan att bygga IT-system begränsas av kommunikationsstrukturen. Den svagaste länken styr och vi kan inte bygga bättre IT-system än vad strukturen medger. Organisationens kommunikationsprocesser kan styras baserat på dess organisationsstruktur, och hur man sitter grupperade rent fysiskt. Sedan finns ju massor av ytterligare dimensioner som påverkar kommunikationen inom en organisation. Ta bara det här med kultur, individers självkänsla, ledning och styrning, osv, osv. För att belysa vad jag syftar på tänkte jag ge några till viss del fiktiva exempel på hur detta kan avspegla sig på hur vi bygger IT-system.

Monoliten

En egen IT-avdelning som sitter i ett eget rum med en dörr som gärna stängs. Övriga verksamheten sitter utanför i till viss del öppet landskap. Ganska vattentäta skott där verksamheten drar sig för att komma och ”störa” IT-avdelningen. IT-avdelningen skapar sin egen bild av hur verksamheten fungerar genom teknikens glasögon, kanske specifikt genom en relationsdatamodell som är facit för allt. En monolitisk IT-arkitektur växer fram, som försöker hantera allt verksamheten önskar, utan att IT egentligen behöver förstå verksamheten. Oavsett vilken fråga som kommer från verksamheten, fixar IT det genom att rita in några extra entiteter i datamodellen. ”Systemet” är det centrala i en monolitisk arkitektur. Det finns ett system, en arkitektur, en datamodell. Systemet är flerskiktad utifrån tekniskt perspektiv, tex med de klassiska lagren; presentation – affärslogik - data. Datamodellen och objektmodellen är oftast tätt sammankopplad med substantiv som leder till entitet, där vi får logik överallt där vi använder entiteterna, dvs lite överallt, men kanske främst brett i affärslogiklagret. Traditionellt tror jag att system som är monolitisk i sin natur ofta har växt fram där det saknas ett öppet klimat, nära samarbete och djup förståelse mellan IT och verksamhet.

En iakttagelse kring monolitiska system är att i förlängningen blir de oftast en bromskloss när verksamheten förändras. Ett stort monolitiskt system med starka beroenden gör att vi lätt får oväntade kaskadeffekter vid förändring. Vilket så småningom leder till att vi skrotar allt det gamla och bygger allt nytt. Om vi behåller vår organisation och våra kommunikationsstrukturer är vi dömda att återupprepa oss själva, tyvärr.

Tjänsteöar

I ett annat företag har man organiserat sig genom att bryta isär IT-avdelningen till att ha utvecklingsteam inom varje avdelning, inom varje affärsområde. Varje team bygger sina egna IT-tjänster, microservices. Inom varje team återfinns proprietär kommunikation med definierade kontrakt. Nu menar jag på hur IT-tjänsterna kommunicerar med varandra, men det återspeglar även den kommunikationsstruktur man har inom teamet. Inom ett team är man ganska förlåtande och snabbfotad när det blir förändringar som påverkar kommunikationen i de egna interna IT-tjänsterna. När man däremot ska börja kommunicera med andra teams IT-tjänster, fortfarande inom samma organisation, blir det problem. Då gränssnitt förändras utan kommunikation, uppstår irritation, som försöker lösas genom att helt enkelt ha mindre med varandra att göra. Man försöker lösa det genom separata miljöer, skapa viss redundans av gemensamma IT-tjänster. Man diskuterar även andra, icke-proprietära, kommunikationssätt som ger lösare koppling, t ex REST över http, just mellan olika teams tjänster. Så här får vi öar av tjänster som påverkats av organisationsstruktur och fysisk platsseparation.

En fundering som väcks i detta exempel är vad som händer vid en omorganisation. Eller när man övergår i en förvaltningsorganisation som kanske inte följer verksamhetsorganisationen längre. Varför har man då grupperat och namngett tjänster och byggt upp gränssnitt som enbart kommit till på grund av en organisationsstruktur som inte längre finns?

Medvetna val

Frågan är om det gjorts medvetna val kring hur man vill utforma sin IT-arkitektur?

Vi kikar tillbaka på det agila manifestet igen och hittar följande citat:

“The best architectures, requirements, and designs emerge from self-organizing teams”

— The Agile manifesto

En verksamhetsledning som sätter en organisation, tänker den på att optimera för hur vi bygger bra system? Hur mycket självorganisation tillåts i en organisation? Här blir ju exempelvis kultur extremt viktigt. Självorganiserade team skapas organiskt och måste bygga på tillit och ansvarsfrihet. Om det finns en mentalitet (kultur) att vissa saker inte är tillåtna eftersom det är bestämt uppifrån, så kan det även bli svårt att självorganisera sig.

Evolutionär arkitektur och självorganisation

Det är viktigt att ha en tydlig vision på vilken typ av IT-system man vill bygga. En IT-arkitektur sätter ramarna inom den visionen. Att vara medveten exempelvis om Conways lag gör att vi kan skapa förutsättningarna att bygga de IT-system på det sätt vi vill. Jag tror att det finns risk att man i en verksamhet för snabbt bildar sig sin egen sanning och blir hemmablind. Att ha en stark och tydlig IT-arkitektur som genomsyrar alla team är en nödvändighet. Den ska inte vara stark i den meningen att det inte tillåts egna initiativ eller en diversifierad portfölj av arbetssätt och teknologier. Tvärtom. IT-arkitekturen måste tillåta en organisk evolution av de system och tjänster som byggs. Det måste finnas en framåtanda och vilja att våga prova nya saker i varje team. De saker som funkar bra måste tillbaka och påverka IT-arkitektur och andra team. Vi måste vara agil på alla plan, även från arkitekturperspektiv.

Hur man uppnår detta öppna och evolutionära arbetssätt kan andra än jag bättre bidra till insikter om. Dock vill jag här lyfta fram hur viktigt det är att ha medvetna människor med hög självkänsla som vill förändras, som vill utvecklas, som vill förbättra sig, utan prestige. Och kombinera det med strukturella ingredienser som arbetsrotation, samordning och styrning. Teamen får inte bli för statiska. De bör vara självorganiserande och omformas vid behov. Och spegla den arkitektur och den uppdelning av tjänster vi vill ha. På det sättet får vi en naturlig kompetensspridning och en evolution av de system vi bygger, hela tiden. Jag tror också att IT-arkitekter inte kan vara i ett eget team, eller tillhöra en egen avdelning. De ska vara högst integrerad i teamen och själva delta i utvecklingen och det dagliga teamarbetet.

För att förbättra förutsättningarna att bygga bra IT-system, var medveten om hur människors samverkan inverkar på förmågan.

Så bra och kloka reflektioner Peter!! Det här kan vi ju prata mer om tänker jag 😀

Marcus Nyberg

.NET Developer at Masarin Consulting

5y

Jättebra Peter! Ser.fram emot att läsa nästa artikel.

To view or add a comment, sign in

Explore topics