Informationsarkitektens bokhylla – del 10: En bok om att bygga verksamhetsarkitektur för komplexa verksamheter

En bok som beskriver det som är viktigast inom all verksamhets- och it-arkitektur, hur vi kan förstå, hantera och kontrollera och reducera komplexitet. Detta beskrivs grundligt och genomtänkt, med en fast grund i teori och samtidigt ett praktiskt angreppsätt.

/Peter Tallungs, IRM 2023-09-07

Hur kan vi hantera komplexitet?

En verksamhet är ett komplext system. Ett i grunden socialt system med många olika parter som samverkar i olika mönster, med varandra och med omvärlden. Enterprise-arkitektur (EA) är det begrepp vi använder för de olika sätt som vi försöker hantera verksamheter som system – mer eller mindre systematiskt och mer eller mindre framgångsrikt.

Själva kärnproblemet är just komplexiteten. Om vi kan bemästra den så kan vi hantera de flesta möjligheter och problem. Om inte så är vi dömda att drunkna i alla kända och okända beroenden kors och tvärs. Speciellt som vi också behöver klara den ständiga anpassning som krävs för att hantera en föränderlig omvärld, med ständigt nya möjligheter och risker.

Trots detta ger inget av de vanliga EA-ramverken och metoderna någon egentlig vägledning för hur vi ska kunna hantera komplexiteten i en verksamhet. Vilket är märkligt då komplexiteten är det som driver precis alla de svårigheter som EA annars försöker hantera. Men hur ska vi då göra?

Vi behöver en arkitektur och ett arkitekturarbete för att hantera komplexiteten. Vi behöver i grunden förstå hur något sådant ser ut. Och det behöver inte vara så svårt egentligen. Vi har redan svaret framför våra ögon om vi tänker efter lite.

En arkitektur behöver inte vara komplex för att hantera en komplex verksamhet. Tvärtom, en arkitektur måste vara enkel för att kunna hantera komplexa och föränderliga krav.
Det enda sättet att hantera komplexitet, i alla sammanhang, är att dela ner ett komplext system i meningsfulla delar som samverkar med enkla och tydliga beroenden mellan sig. På så sätt minskar vi komplexiteten i systemet. Vi får då en enkel arkitektur som kan hantera en komplex verklighet.

Det är faktiskt så det mesta som skapas av människor ser ut. En dator består av olika komponenter med tydliga och enkla beroenden mellan sig. Så även en bil. Så även en offentlig förvaltning. Varje offentlig administration har ett tydligt uppdrag och tydliga sätt att samverka.

Och det stannar inte vid system skapade av människor. Även naturen är uppbyggd av autonoma komponenter. Ditt hjärta och dina lungor styr sig själva. En mänsklig cell är tydligt avgränsad från omgivningen, styr sig själv och har tydliga gränssnitt till sin omgivning.

En som har tänkt till ordentligt på detta är Roger Sessions.

Roger Sessions

Roger Sessions är känd som en expert inom programvaruarkitektur för verksamheter. Han har skrivit många böcker och en är särskilt intressant för det större EA-området. Det är Simple Architectures for Complex Enterprises som kom 2008.

Roger Sessions har inte nått ut så brett med boken som den är värd. Jag tror det beror på att han kommer från systemutvecklingsvärlden, och därför inte läses av de som verkligen skulle behöva det, de som är verksamhetsutvecklare av olika slag. Men jag uppfattar hans systemutvecklingsbakgrund som en styrka i och med att det har givit honom hans systematiska synsätt. Om man är en framgångsrik it-arkitekt har man en förmåga och vana att strukturera problem och lösningar. Det är dock sällan den förmågan tillämpas på en verksamhet som helhet.

Boken

Boken Simple Architectures for Complex Enterprises är mig veterligen den enda litteraur som seriöst och utförligt har behandlat hur vi kan hantera komplexitet i vår verksamhetsarkitektur. Inte bara inom programvaruarkitekturen utan i verksamheten som helhet. Nyckeln är att dela ner verksamheten i avgränsade autonoma delar. Han kallar det för Autonomous Business Components (ABC). Vi skulle nog kalla det för Business Capabilities eller Verksamhetsförmågor. I varje fall om vi med dessa termer verkligen menar avgränsade autonoma delar av en verksamhet.

Boken är intressant för alla som arbetar med EA i någon form. Jag vill påstå att om vi på allvar kunde tillägna oss budskapet så skulle hela EA-området ha en helt annan relevans. Budskapet stämmer också med hur man ser på verksamheter inom systemteori, samt med kända moderna och välbeprövade organisations- och ledningsteorier, såsom uppdragsstyrning (auftragstaktik), Teal (självstyrning och självorganisation) med flera.

Jag menar att boken är intressant inte bara för enterprise- och verksamhetsarkitekter utan även för informationsarkitekter. Just detta med verksamhetsförmågor är en nyckel i en informationsarkitektur. Data skapas, hanteras, används i förmågor och utbyts i tjänster mellan förmågor. Verksamhetsförmågor är helt enkelt själva subjekten i informationsarkitekturen.

Allt detta har jag försökt beskriva i artikelserien ”Förmågekartor för informationsarkitektur – del 1 till 10”. Men jag vill uppmana alla intresserade att gå till källorna, inte minst Roger Sessions bok.

Bokens innehåll

Boken har två delar. Den första delen diskuterar vad komplexitet är och den andra delen hur vi kan hantera den komplexitet vi möter i våra verksamheter.

Del I: The Question of Complexity

Chapter 1: Enterprise Architecture Today (36 sidor)

Bokens första kapitel går igenom vilka svårigheter vi ställs inför i våra verksamheter idag samt går igenom de vanligaste EA-ramverken som finns.

Chapter 2: A First Look at Complexity (31 sidor)

Författaren formulerar tre strategier för att kontrollera komplexitet i en verksamhet:

Strategi 1: Partitionering (Partitioning)

Dela upp verksamheten i avgränsade partitioner. Varje partition kan i sin tur innehålla fler mindre partitioner. Om delningen görs enligt vissa regler så minskar komplexiteten avsevärt. (Sessions kallar en sådan partition för Partition eller ABC, Autonomous Business Component. Vi skulle nog säga Verksamhetsförmåga, såtillvida man med denna term verklig menar en avgränsad autonom del av verksamheten.)

Det handlar i detta läge inte om att omorganisera utan att tydliggöra och befästa de naturliga gränserna i den verksamhet som organisationen ägnar sig åt.

Strategi 2: Förenkling (Simplification)

Vi kan ytterligare reducera komplexitet genom att, där det går, slå ihop saker som görs på flera ställen.

Strategi 3: Upprepning (Iteration)

Detta arbete behöver upprepas i tydligt avgränsade omgångar.

Den första och viktigaste strategin, att dela upp verksamheten i avgränsade delar, bör enligt Sessions göras enligt vissa regler, som han kallar lagar:

• Lag 1: Partitionerna är sanna partitioner
  Det vill säga att en och samma företeelse inte ska finnas i mer än en partition.

• Lag 2: Partitionerna är ändamålsenlig
  Partitionerna måste ha mening för verksamheten.

• Lag 3: Partitionerna är lagom många
  Vi bör inte dela ner verksamheten i alltför många smådelar och inte heller i bara några få stora klumpiga. En verksamhet har alltid naturliga delningslinjer som vi kan finna.

• Lag 4: Partitionerna är av ungefär samma storlek och omfattning
• Lag 5: Partitionerna har minsta möjliga behov av interaktion och att denna är väl definierad

Att undvika komplexitet är helt beroende av att partitionerna är definierade så att de kan verka så självständigt som möjligt.

Chapter 3: Mathematics of Complexity (23 sidor)

Här visar Sessions med stöd av mängdlära och kombinatorik hur komplexiteten ökar dramatiskt om man inte ser till att hålla partitionerna så autonoma som möjligt.

Del II: The Quest for Simplification

Chapter 4: The ABCs of Enterprise Partitions (20 sidor)

I detta kapitel diskuterar Sessions vad det egentligen innebär att se en verksamhet som ett antal autonoma delar och hur en sådan del ser ut. Han kallar själva den struktur man får fram av ett sådant synsätt för Simple Iterative Partitions (SIP)

Observera att när Sessions pratar om en partition av verksamheten så innefattar han de it-system och den it-verksamhet som direkt stödjer just den delen av verksamheten. Alltså att it är en integrerad del av verksamheten och således en integrerad del av varje partition. De flesta ansatser inom området ser annars it som något utanför den egentliga verksamheten, som en stödfunktion. Vilket enligt mig är ett grundläggande missförstånd.

Det handlar i detta läge inte om hur en viss funktion är implementerad utan om hur de är relaterade till varandra. Det som alltid måste ske tillsammans hör ihop, annars inte.

Kapitlet gå igenom hur man behöver skilja på en verksamhetskomponents utformning och dess fysiska placering där två komponenter kan vara kloner eller syskon.

Komponenter har typer, till exempel: Mitt företags HR-funktion är av typen HR-funktion. Vidare finns det relationer mellan komponenter som kompositioner, det vill säga att en komponent är en del av en annan. Komponenter samverkar genom att de har väldefinierade interaktioner. Sessions kallar det partnerskap. En partnerrelation kan vara Information Request, Information Broadcast eller Work Request.

Chapter 5: SIP Process (23 sidor)

Detta kapitel beskriver själva arbetsgången i hur man som arkitekt kan bidra till att minska komplexiteten i sin verksamhet. Processen använder sig av de tre strategierna beskrivna i kapitel 2: Partitionera, Förenkla, Upprepa.

Dessutom beskrivs hur man med hjälp av den metodik som beskrivs i boken kan hantera vanliga situationer som osäker eller oläglig information, nytt komplext projekt på gång, uppköp eller spin-off av företag, utkontraktering, regulatoriska krav, automatisering av interaktioner med partners eller kunder, dåliga relationer mellan it och verksamhet, bristande interoperabilitet mellan it-system eller ohanterliga it-system.

Den process som beskrivs i boken motsäger inte andra vanliga arkitekturmetoder utan är snarare ett komplement.

Chapter 6: A Case Study in Complexity (18 sidor)

Ett exempel från Brittiska National Helth Service.

Chapter 7: Guarding the Boundaries: Software Fortresses (11 sidor)

Kapitlet presenterar det som Roger Sessions är känd för bland systemutvecklare; idén om Software Fortress, hur man designar it-system så att de kan samverka utan att kompromissa med sina oberoenden. Efter som it-applikationer är en integrerad del av varje verksamhetskomponent så är it-applikationernas interaktioner på samma gång interaktioner mellan verksamhetskomponenter. Därför är detta en viktig aspekt i sammanhanget.

Chapter 8: The Path Forward (9 sidor)

En kort betraktelse om vart vi är på väg inom verksamhets- och it-utveckling i våra samhällen och verksamheter. Om hur komplexiteten ökar och vad vi kan göra åt detta.

Appendix: This Book at a Glance (7 sidor)

Kort sammanfattning av bokens innehåll.

Varför ska du läsa boken?

För att den beskriver det som är viktigast inom all verksamhets- och it-arkitektur, hur vi kan förstå, hantera och kontrollera och reducera komplexitet. Det är det enda verket jag känner till, som gör det så grundligt och genomtänkt, med en fast grund i teori och samtidigt ett praktiskt angreppsätt.

Jag är bara rädd för att Roger Sessions bakgrund inom it, och bokens språk som kan kännas mer tekniskt än vad ämnet egentligen är, kan skrämma bort läsare. Jag hoppas att det inte skrämmer bort dig.

Jag tror som sagt att Sessions bakgrund inom systemutveckling är just det som har gjort att han djupare än någon annan har greppat hur man förstår och hanterar komplexitet.