Förmågekartor för informationsarkitektur – del 2: Förmågor är verksamhetens meningsfulla byggblock

Som informationsarkitekter behöver vi analysera och beskriva hur data flödar genom verksamhetens landskap och var data kommer från, var den lagras, var den hanteras och var den används, både internt i organisationen och externt, hos de parter man utbyter data med. Kanske kan vi kalla det för verksamhetens datalogistik. Men då måste vi först ha ett sätt att kartlägga och representera detta landskap. Vi behöver kunna ta fram en karta. Den första frågan blir då: Vad blir komponenterna i en sådan karta? Det vill säga de entiteter som data flödar mellan och hanteras i.

/Peter Tallungs, IRM 2022-11-24

Vi kan se på en verksamhet som att den består av ett antal delar som samverkar i ett nätverk för att producera varor eller tjänster av något slag, som en maskin eller fabrik. Eller om man vill, som ett ekosystem. Hur kan man då se på dessa avgränsade delar? Vad är de? Vissa vill kalla dem ”komponenter”, andra ”funktioner”. Vanligast har nog blivit att säga verksamhetsförmågor, även om termen ibland kan ha en lite annorlunda betydelse. Men låt oss inte fastna i själva ordvalet.

I denna artikel, och följande, vill jag beskriva hur vi kan se på en verksamhetsförmåga. Men först några ord om den helhet vi vill beskriva, en verksamhet. Vad är det?

Vad är en verksamhet, egentligen?

En verksamhet är, brett sett, ett sammanhang där människor verkar tillsammans i ett visst syfte. Det kan egentligen vara vilket sammanhang och organisationsform som helst. I det följande ger jag min bild av vad en verksamhet är, och jag gör det i form av ett antal frågor och svar.

• Är en verksamhet ett företag?

  Nej, inte riktigt. Ett företag (eller annan organisation) har vanligen en viss en verksamhet, men många har fler än en verksamhet. Det är när de gör olika saker som inte är tätt och ömsesidigt beroende av varandra som det är fruktbart att se det som olika verksamheter.

  Skatteverket till exempel sköter både folkbokföring och skatteväsende. Det är två olika uppgifter som mycket väl skulle kunna skötas av separata organisationer. Det betyder inte att de två olika verksamheterna inte har samband med varandra. Skatteväsendet är beroende av en fungerande folkbokföring. Men folkbokföringen är inte direkt beroende av skatteväsendet och folkbokföringen tjänar också många andra verksamheter i samhället. Därför är det att betrakta som två skilda verksamheter.

  Ett annat exempel: Konsultbolag bedriver ibland både konsult- och utbildningsverksamhet. Det är två verksamheter som visserligen har ömsesidig synergi, men ändå har olika affärsmodeller, olika processer, olika puls, olika informationsbehov, olika stödfunktioner med mera. Därför är det lämpligt att beskriva dessa som olika verksamheter, även om de bedrivs inom samma bolag.

• Kan en verksamhet spänna över flera organisationer?

  Ja, nästan alltid är det så. Om jag till exempel vill se hur skadehanteringen fungerar i försäkringsbranschen så är det ett samarbete mellan många parter. Om jag har krockat min bil så gör jag kanske först en skadeanmälan till mitt försäkringbolag, som har en outsourcad kundtjänst. Sedan tar en bärgningsfirma bilen till en verkstad. Verkstan inspekterar och bedömer skadan, på uppdrag av försäkringsbolaget som är ansvarig för skadehanteringen. Om bilen är bortom räddning så finns det speciella branschsamarbeten som administrerar skrotningen. Sedan hanteras ersättningen genom att jag kanske kan hämta ut en ny bil hos någon bilfirma eller får pengaersättning via bank.

  För de flesta syften behöver vi se hela skadehanteringen som en och samma verksamhet, trots att det mesta av hanteringen sker hos andra parter än det försäkringsbolag som hanterar skadan.Visst kan man se varje organisation som bidrar till helheten som en egen verksamhet. Men ofta behöver vi analysera och på något sätt hantera den större helheten.

• Är verksamhet samma som ”affär”?

  Nej, ”affär” handlar om de existentiella frågorna för en organisation; Hur finansierar vi vår verksamhet? Vilka är våra kunder? Varför behövs vi? Vilka tjänster eller produkter tillhandahåller vi och på vilket sätt? Affär är alltså inte samma som verksamhet. Affär är en av flera aspekter på en verksamhet. Det finns mycket inom en verksamhet som inte direkt handlar om själva affären, även om affären alltid är det yttersta syftet med allt inom verksamheten.

  En del tycker att man inte kan tala om affär då det handlar om en verksamhet som inte är vinstdrivande, men frågeställningarna blir ungefär desamma. Det är nog mest termen ”affär” man då studsar på, inte dess betydelse och innehåll.

• Kan man översätta ”business” med ”verksamhet”?

  Ja, fast långt ifrån alltid. ”Business” kan betyda två olika saker, och dessa saker har olika namn på svenska. Den ena betydelsen är det vi kallar ”verksamhet” och den andra är det vi kallar ”affär”. Så man måste skilja på detta. På engelska kan man, om man vill förtydliga, kanske säga ”business strategy” om affär och ”business operation” om verksamhet. Säger man bara ”business” så får sammanhanget avgöra om man avser bara själva affären, eller verksamheten som helhet. Eller kanske till och med bara någon aspekt av verksamheten.

• Kan man skilja på verksamhet och it, som två olika delar av en organisation?

  Det är en gränsdragning som vi gjort historiskt, och det är en ovana som fortlever hos oss. Men det är en olycklig dysfunktionell gränsdragning som vi behöver överge. Varför det?

  Jo, när vi analyserar en verksamhet behöver vi dela ner den i komponenter som är relativt löst kopplade till varandra, med tydliga och enkelriktade beroenden. Om man har en it-applikation som stödjer en verksamhetsfunktion så är den applikationen på alla sätt en integrerad del av den verksamhetsfunktionen. Utvecklingen av informationstekniken och utvecklingen av andra aspekter av verksamhetsfunktionen såsom arbetssätt, organisation, roller, kunskap, processer och information är så ömsesidigt beroende av varandra så det inte går att dra någon tydlig skiljelinje mellan dessa.

  Informationssystemen är således en integrerad aspekt av en verksamhet och inte en separat funktion. Informationssystemen stödjer inte verksamheten, utan de är en fullvärdig aspekt av verksamheten. Om man, som det ofta görs, försöker skilja på dessa, till exempel genom att ha ett separat it-projekt och verksamhetsprojekt så skapar det en barriär som effektiv hindrar det täta och dubbelriktade samarbetet som behövs.

  Idealt borde det inte finnas någon separat it-del av en verksamhet, utan det borde vara en integrerad del av verksamheten. Undantaget är möjligen rent tekniska it-funktioner som kanske serverdrift, som inte har ett lika starkt dubbelriktat beroende från och till verksamheten.

Förmågor som verksamhetens meningsfulla byggblock

Vi kan se en verksamhetsförmåga som en komposit av processer, information, verksamhetsregler, kompetens, it-stöd med mera – en liten komplett verksamhet i sig.

Här är det på sin plats med en liten parentes om ordvalet. Nu talar vi inte om förmåga i den ordboksmässiga betydelsen av ordet; ”vad man kan göra”, utan i betydelsen ”en avgränsad del av en verksamhet som levererar den förmågan”. Det är därför jag har tvekat att använda termen ”förmåga”, men nu är det så att det är den termen som vunnit användning, så vi får nog leva med det.

På så sätt får vi en komponentmodell för en verksamhet.

En verksamhet är som sagt ofta ett komplext system som människor byggt. Vi kan betrakta en verksamhet som ett system av samverkande komponenter.

Det är så vi människor förstår och hanterar komplexa system av olika slag. Det här är egentligen inget nytt påhitt, utan helt enkelt det sätt vi människor hanterar komplexitet i alla möjliga sammanhang. Det är bara det att vi tidigare, innan förmågeperspektivet fick ett uppsving, av någon anledning inte har gjort så när det gäller verksamhetsarkitektur.

Den här utvecklingen mot ett komponenttänkande inom verksamhetsarkitektur är något som jag och mina kollegor tror starkt på och gärna vill puffa för, och utveckla.

En komponentmodell tjänar många syften, användningen av synsättet är så mångfaldigt och rikt. Jag kommer nu försöka beskriva, i generella termer, vad en sådan verksamhetskomponent är.

De bakomliggande djupa tankarna om vad komponentarkitektur innebär syns sällan i litteraturen om Enterprise-arkitektur. Som så ofta får vi gå utanför EA-samhället för att hitta vägledning.

Jag har utgått från något av det bästa som skrivits om komponentarkitektur; Boken handlar visserligen om komponenter i programvara. Men jag ser de grundläggande principerna som generellt tillämpliga för alla slags system, uppbyggt av komponenter.

Jag har här anpassat hans beskrivning av programvarukomponenter till verksamhetskomponenter, det vill säga det vi vill kalla för verksamhetsförmågor.

Vad är en verksamhetskomponent egentligen?

Man kan beskriva vad en verksamhetskomponent ”är” ur olika aspekter, närmare bestämt vilka roller eller syften en verksamhetskomponent fyller, och vad det synsättet hjälper oss med i hanteringen av verksamhetens arkitektur.

1. En verksamhetskomponent är en abstraktionsenhet (unit of abstraction)

   Den mänskliga hjärnan abstraherar bort detaljer så att de föremål vi betraktar blir enklare att hantera för oss. Abstraherande är nödvändigt för all slags tänkande. Vi behöver goda abstraktioner för att hantera den nödvändiga komplexiteten och för att slippa onödig komplexitet. En verksamhetskomponent håller samman vad som behöver hållas samman som en enhet i vår syn på en verksamhet, och separerar vad som naturligt är separata företeelser.

2. En verksamhetskomponent är en analysenhet (unit of analysis)

   En verksamhet är ett komplicerat ekosystem. Ett kraftfullt sätt att försöka förstå en verksamhet är att i tanken bryta ner verksamheten i mindre och mindre delar. Men inte hur som helst, utan nedbrytningen bör ske på ett sådant sätt så att kopplingen mellan delarna blir så lös och explicit som möjligt.Utan en bra gjord indelning blir det omöjligt att förstå (analysera) ett så komplext system som en verksamhet. Än mindre kan vi planera och konstruera (syntetisera) en ny eller förändrad verksamhetsdel.

   Arten och graden av koppling mellan verksamhetskomponenterna bestämmer till vilken grad analysen av en komponent måste ta hänsyn till egenskaperna hos andra komponenter. Det vill säga, om man inte tydligt separerat delarna från varandra utan bara säger att allt har beroende till allt, på alla möjliga sätt, så kan man inte analysera varje del för sig. Då blir en global analys den enda möjligheten. Resultatet blir en mycket svåröverskådlig, svårarbetad och oflexibel verksamhetsarkitektur.

3. En verksamhetskomponent är en enhet att utveckla, förvalta och styra (unit of development, maintenance and management)

   Eftersom de inneboende aspekterna av en verksamhetskomponent är tätt sammanvävda är det inte görligt att utveckla en aspekt utan att de andra aspekterna påverkas. Vi kan till exempel inte utveckla it-stödet för en verksamhetskomponent utan att påverka information, verksamhetsregler och processer. Vanligen kan vi inte heller utveckla processerna utan att påverka it-lösningen eller informationen. Det minsta objektet för verksamhetsutveckling är sålunda en verksamhetskomponent som en helhet.Varje leverans från ett utvecklingsarbete är och måste vara en förändrad verksamhetskomponent i sin helhet. Ändringen kan vara liten, men omfattar normalt fler än en aspekt och ofta mer eller mindre alla aspekter av en verksamhetskomponent.

4. En verksamhetskomponent är en leveransenhet (unit of independent deployment)

   En verksamhetskomponent behöver utvecklas och driftsättas. Det måste göras som en helhet. Den är oberoende av andra komponenter så länge gränssnitten för dess verksamhetstjänster fungerar. De ingående processerna, informationen, verksamhetsreglerna, kompetensen och it-funktionaliteten har rika och nära beroenden med varandra och kan inte separeras. Om du behöver stycka elefanten är tillvägagångssättet att identifiera de verksamhetskomponenter den består av och hantera var och en av dessa som en helhet.

5. En verksamhetskomponent är en distributionsenhet (unit of locality)

   En verksamhetskomponent kan placeras ut geografiskt som en helhet, förutsatt att kompetens och andra resurser finns på plats, och tjänsterna fortfarande kan levereras till dess kunder. Om man försöker sprida personerna som har roller i en verksamhetskomponent geografiskt kan man få betala ett pris. Eftersom arbetet inom en komponent är tätt integrerat behöver dessa personer kommunicera effektivt. Och geografiskt avstånd är en hämsko för bandbredden i den mänskliga kommunikationen.Även it-personal som arbetar med it-lösningen för en verksamhetskomponent behöver ses som verksamhetskompetens och ska helst samallokeras med resten av verksamhetsfolket. Det gäller för all it-personal med applikations- och verksamhetsfokus, såväl applikationsutvecklare och applikationsförvaltare som användarstöd och applikationsdrift.Är du applikationsutvecklare så är du i själva verket verksamhetsutvecklare. Förvaltar du en applikation så förvaltar du i själva verket en verksamhetsprocess, funktion eller tjänst. Stödjer du användare av en applikation så stödjer du i själva verket en användare av en verksamhetsprocess av något slag. Driftar du en applikation så driftar du en verksamhetsprocess. Ty om man tänker efter handlar allt detta i grunden om verksamhet, även om det också kräver tekniska färdigheter.

   Jag tror att många har börjat förstå detta nu, när vi har haft ett decennium där man okänsligt och okunnigt har outsourcat it-utveckling långt från den verksamhet den ska stödja. Jag har inte hört om något lyckat försök, och har själv på nära håll sett vilken katastrof det varit. Hur mycket pengar har inte försvunnit, men värre ändå är den förlust i kunskap i de organisationerna, och de möjligheter till utveckling man gått miste om. Jag vill skylla allt detta på tron att informationstekniken är ett stöd till verksamheten och att det därmed finns ett ensidigt och tydligt beroende från verksamhet till it. När det i själva verket är så att det vi kallar informationsteknik är, och måste vara en integrerad aspekt av verksamheten, som inte går att separera från denna.

   Teknisk drift däremot som server- och plattformsdrift, där specifik verksamhetskunskap inte behövs, kan vi se mera som infrastrukturtjänster och är inte del av verksamhetskomponenten. Detta levereras av en särskild stödfunktion.

   Det är möjligt att behovet av samallokering av personal kan tonas ner något i många verksamheter där distansarbete är möjligt. Men det försvinner inte. Som sagt, vi som verkar inom en och samma verksamhetskomponent behöver samverka tätt.

6. En verksamhetskomponent är en redovisningsenhet (unit of accounting)

   Verksamhetskomponenter är naturliga och meningsfulla enheter för uppföljning av kostnader. På så sätt kan kostnader och vinster länkas till vad som verkligen levereras som helhet.

7. En verksamhetskomponent är en enhet att ifrågasätta (unit of dispute)

   Förr eller senare fallerar en verksamhet på ett eller annat sätt. Det kan röra kvalitet, säkerhet, prestation, kostnad, syfte eller annat. Med en komponentvy över verksamheten blir det lättare att lokalisera problemet, eller delar av problemet, till en specifik komponent eller några få samverkande komponenter. Detta underlättar problemanalys och åtgärder.

8. En verksamhetskomponent är en enhet för felisolering (unit of fault containment)

   När något går fel ska inte felet propagera tvärs över gränsen till andra verksamhetskomponenter. Normalt ska verksamhetskomponenten upptäcka och åtgärda felet själv. Ingen annan del av verksamheten kan förväntas att ha den detaljkunskap som behövs för att hantera felet och se till att det inte händer igen.

Alla ovan aspekter gäller för alla slags ”system”. Vi kan se mycket i vår omgivning som nätverk av samverkande komponenter. Från fysiska artefakter som datorer och bilar, till sociala artefakter som verksamheter, samhällssystem etcetera.

En annan tänkare som lyft fram komponentperspektivet inom verksamhetsarkitektur är Roger Session med boken ”Simple Architectures for Complex Enterprises” (ISBN 978-0735625785). Det är en bok som går på djupet med att motivera de viktigaste påståendena om en verksamhetskomponent, nämligen 1, 2 och 3 ovan. Det jag i dessa artiklar kallar för verksamhetsförmåga kallar ”Autonomous Business Component”.
Han betonar särskilt att komponenterna måste vara autonoma, det vill säga att de har sin egen styrning. Annars gör kombinatoriken att sambanden, kopplingarna mellan komponenterna snabbt exploderar i antal och komplexitet.
Komponentperspektivet är således kraftfullt och viktigt när vi vill förstå vad en verksamhetsförmåga är. Det är intressant att både Szyperski och Session kommer från programmerarvärlden. Man kan förstå varför det är just detta område som föder dessa idéer. Det är inom systemutveckling man hela tiden tänker på hur man ska organisera stora komplexa system.

Next stop: Systemteori

Det finns ett äldre tvärvetenskapligt och mycket rikt kunskapsområde som tillför ett fördjupat perspektiv på samma problematik. Det heter systemteori och handlar om hur man kan se på komplexa system i allmänhet. Där vill man dela ner ett komplext system i autonoma komponenter, vilka också är system. Man betonar särskilt att system är självreglerande, det vill säga att de har mekanismer för att styra sig själva. Exempel är system i naturen, så som en växt eller ett djur, hjärta och lungor i ett däggdjur, eller ett helt ekosystem. Eller en cell i ett djur eller i en växt. Eller värmesystemet i ett hus, en dator, en bil etcetera. Eller sociala system som en familj eller ett samhälle. Eller, det vi är intresserade av, en verksamhet. Eller en avgränsad del av en verksamhet, det vill säga det vi här kallar för en verksamhetskomponent eller verksamhetsförmåga. I nästa artikel dyker vi ner i systemteori.

/Peter Tallungs, IRM

Välkommen att maila mig på peter.tallungs(at)irm.se eller kommentera artikelns post på IRM:s linkedin.

Vill du prenumerera på denna artikelserie? Det innebär att du får ett nyhetsbrev, samtidigt som vi publicerar en ny artikel i ämnet informationsarkitektur, med länk till den senaste artikeln. Skriv ett mail till info@irm.se med namn och e-postadress. Skriv IA-artikelserie i ämnesraden.