Förmågekartor för informationsarkitektur – del 7: Integrationskartan

Som informationsarkitekt behöver jag inte bara analysera och beskriva datamängder utan även analysera och beskriva hur data rör sig genom verksamheten. Varifrån en viss datamängd kommer, hur den delas och hanteras, var den används och av vem. Till detta behöver vi en gemensam karta över verksamhetens landskap. Här kommer förmågekartan in, som basen för en sådan integrationskarta.

/Peter Tallungs, IRM 2023-01-26

Föregående sex artiklar om förmågekartor för informationsarkitektur har egentligen inte alls handlat om arbetet med informationsarkitektur. De har mer varit avsedda som en upptakt, en grund för följande artiklar. Jag har förmedlat hur jag menar att begreppet verksamhetsförmåga behöver kunna förstås, för att vara användbart i detta sammanhang.

Först denna artikel, den sjunde i serien, beskriver hur en förmågekarta kan se ut för att fungera för arbetet med verksamhetens informationsarkitektur.

Vi behöver rika förmågekartor

Vi behöver en förmågekarta. Men den vanliga förmågekartan duger inte, den man brukar möta, som bara radar upp förmågor utan att visa vad de består av eller hur de relaterar till varandra. Den är tunn och abstrakt och säger inte så mycket.

Vi behöver möjligheter att avbilda själva landskapet, det ekosystem som en verksamhet är, med applikationer, tjänster, roller och integrationer. Vi behöver en rik förmågekarta. I detta sammanhang vill jag kalla det för en integrationskarta.

En rik förmågekarta är en grund för all verksamhetsarkitektur

Första gången jag tog fram en rik förmågekarta var för femton år sedan. Det var för ett affärsområde på ett stort internationellt företag. Vi kartlade och ritade hur verksamheten hängde ihop som ett helt ekosystem, med förmågor, externa parter, applikationer, tjänster och integrationer.

Det som sedan hände förbluffade mig. Verksamhetsfolk blev frälsta över vad de såg. De tyckte att de för första gången fick en karta över sin verksamhet där de kunde se hur allt hängde ihop. De kunde nu se det som man inte hade kunnat se i de modeller de hade sedan tidigare. Vare sig i organisationsschema, processkartor, informationsmodeller eller i systemkartor. Och inte heller i en vanlig förmågekarta, som bara radar upp förmågor, om de nu haft en sådan.

Sättet vi ritade, med förmågor som tydliga komponenter i en verksamhet, med sina applikationer, tjänster och integrationer, spred sig till de andra affärsområdena i företaget, och en febril aktivitet tog fart då jag fick hjälpa dem att ta fram liknande kartor.

Numera börjar jag alltid mina uppdrag med att ta fram en sådan förmågekarta. Detta oavsett uppgift. Jag gör det för att få överblick och sammanhang. Vilka delar består den här verksamheten av, hur ser själva den övergripande strukturen ut och hur samverkar delarna operativt med varandra och med omgivningen? Vilka applikationer, tjänster och personroller finns i dessa förmågor och vad är deras roll i integrationen?

De i organisationerna som sedan ser kartan blir nästan alltid engagerade. De börjar själva rita på kartan, korrigerar det jag inte förstått och kompletterar med det jag inte sett. Det är ett säkert tecken på att vi har en typ av modell som betyder något och är användbar för dem.

Denna typ av förmågekarta är den bästa grunden för förståelse av hur en verksamhet fungerar menar jag. Det blir själva grundkartan för en verksamhet och som många andra modeller kan relatera till och få sitt sammanhang från. Den knyter ihop många olika perspektiv.

En sådan karta är användbar för allt slags arbete med en verksamhet, men i denna artikelserie fokuserar jag på hur en sådan karta kan användas för arbetet med informationsarkitektur.

Exemplet på en integrationskarta

Jag använder i fortsättningen av denna artikel det enkla exemplet på en integrationskarta som visas i bilden ovan. Jag har utgått från ett verkligt exempel, men gjort det anonymt. Kartan visar inte en komplett verksamhet utan bara ett utsnitt. Uppdraget i vilket den togs fram handlade om att kartlägga situationen för hur och var kundinformation uppstår, hanteras och används i verksamheten, inklusive i it-system och integrationer. Därför är endast vissa förmågor med, de som är direkt inblandade i hanteringen i fråga. Kartan är inte heller komplett utan exemplet visar ett halvfärdigt arbete. Förmodligen kan det tillkomma fler förmågor.

Verksamheten är en finansverksamhet, därför hanterar man många uppgifter om kundernas organisationer och personer för att kunna upptäcka och rapportera misstankar om penningtvätt eller annan olaglig verksamhet. Det handlar både om data som kommer från externa källor och data som skapas internt i monitoreringen av kundens transaktioner. Det är i dag ett vanligt ansvar för finans- och försäkringsföretag med flera, så jag tror att många läsare känner igen sig.

Utsida och insida

Vi måste bestämma vad vi beskriver, om det är en organisations hela verksamhet, en del därav eller en verksamhet som är ett samarbete över flera organisationer. Vi behöver tydligt visa vad som är verksamhetens avgränsning från sin omgivning. Det betyder att vi inte bara beskriver det som är på insidan, utan även saker som finns på utsidan och som vår verksamhet interagerar med.

Gränsen mellan utsida och insida har jag ritat med en tjock grå linje. Innanför finns de förmågor verksamheten består av. De är ritade som ljusgrå rektangulära ytor. Alla förmågor är dock inte utritade i exemplet utan endast de som varit intressanta för just detta uppdrag.

Yttre struktur

Utanför finns de parter som verksamhetens egna förmågor interagerar med. De är också ritade som ljusgrå rektangulära ytor. De är ju hela verksamheter, men sådana kan också ses som förmågor i en större skala, när man anlägger ett fraktalt perspektiv.

Kunder

Högst upp i diagrammet, utanför ramen, finns de intressenter som vi finns till för. Det brukar alltid vara kunder i någon form, men kan ofta vara indelade i kategorier av kunder som man tillgodoser på olika sätt. Ibland, i vissa verksamheter, behöver man gå längre. Det är kanske så att vår verksamhet tillhandahåller tjänster åt våra kunder som i sin tur tillhandahåller tjänster åt sina kunder, där våra tjänster är en viktig del. I så fall behöver jag förstå och representera både våra kunder och kundernas kunder. (Hans Willars sa en gång: ”Ofta behöver man förstå kundens kund. Och ibland kundens hund.”)

Leverantörer

Längst ner, utanför ramen, ligger våra leverantörer. I detta fall leverantörer av data om kunder och personer. Vanligen är de, som i detta fall, dataleverantörer som samlar ihop data från ursprungliga källor. I detta fall torde de ursprungliga källorna vara Bolagsverket, Statistisk Centralbyrån, med flera. Jag brukar när det behövs rita ut även dessa under våra leverantörer för att få ett grepp om hela kedjan.

Andra externa parter

Till höger om ramen har vi en part som inte är leverantör och inte kund men som spelar en viktig roll. Det är Finanspolisen till vilken man rapporterar misstänkt beteende hos en kund. Eftersom jag inte ser det varken som kund eller leverantör har jag lagt det på sidan.

Till vänster har jag lagt den part som tillhandahåller den identifieringstjänst man använder. Det är visserligen strikt sett en leverantör och kunden borde därför placerats längst ner. Men eftersom den inte är någon leverantör av data så har jag lagt den vid sidan. Överhuvudtaget hur vi ritar är inte en exakt teknik utan mer av en avvägning av vad som fungerar bäst för att framhäva verksamhetens arkitektur.

Inre struktur

Inom ramen har jag placerat förmågorna efter vilken roll de spelar i helheten. Längst upp, närmast kunderna har jag lagt de förmågor som jag vill kalla för Front office capabilities, det vill säga det som direkt och närmast är det som kunderna möter. Där har jag lagt Försäljning samt Onboarding av kunder och Kundtjänst.

I mittenraden har jag lagt det som man vill se som kärnan i verksamheten (Main capabilities). Man kan säga att det är där själva operativa arbetet utförs i verksamheten. (Det vill säga det som är den operativa kärnan när vi betraktar verksamheten som en helhet. I själva verket är alla förmågorna operativa i sin egen rätt när vi zoomar in.)

Längst ner ligger stödförmågorna, som man också kan kalla för verksamhetens infrastruktur. Det vill säga det som är stöd åt de mer centrala förmågorna.

På det sättet kan vi åskådliggöra hur verksamhetens arkitektur är skiktad med ett beroende som går i huvudsak uppifrån och ner. Kunderna känner till och interagerar med front office. Front office behöver back office och dessa båda behöver en infrastruktur i form av stödförmågor. Att på detta sätt avbilda och hantera en verksamhet som en skiktad arkitektur är viktigt. Om vi tydligt kan förmedla det storskaliga mönstret för beroendena mellan verksamhetens olika delar blir det lättare att hantera all förändring.

Det finns också någon form av idé om en vänster-högeraxel i kartan. Det som naturligt kommer före i tid till vänster och med en (till största delen teoretisk) tidsprogression åt höger. Till exempel kommer försäljning före onboarding och kundtjänst. Och hantering av basdata om kunder före själva riskhanteringen där data används, och så vidare. Dock vill jag inte kalla vänster-högerdimensionen för en process i någon mera meningsfull betydelse. Det finns otaliga processer som löper kors och tvärs bland förmågorna, och det är sällan man verkligen kan peka ut ett huvudflöde på det sättet. Verksamheter gör ofta olika saker som har olika flöden, även på huvudnivån. Men om man verkligen kan peka ut ett enda operativt flöde som centralt och viktigt för hela verksamheten så ska man naturligtvis göra det.

Att försöka tolka och representera verksamhetens överordnade struktur på detta sätt är viktigt när man ritar kartan. Vad ligger nära varandra? Vad ligger långt ifrån varandra? Vad är parallella företeelser i förhållande till något annat?

Observera att jag utgår från VSM (Viable System Model, den systemteoretiska organisationsmodell som jag beskrivit i en tidigare artikel) i min syn på vad som är en förmåga. Således är samtliga förmågor operativa. Det vill säga att de utför något arbete som kan ses som operativt, vilket i sin tur vill säga att de kan ge ett återkommande och direkt och resultat för någon intern eller extern part. Följaktligen finns det inga förmågor som bara är ledning. Ledning är en integrerad aspekt av samtliga förmågor och även av den förmåga som utgörs av verksamheten som helhet.

Förmågeperspektivet är som bekant ett fraktalt perspektiv, vilket innebär att en förmåga alltid består av komponenter som också är förmågor. Men när jag gör denna typ av kartor har jag inte alltid ett behov av att rita ut de olika nivåerna. Men det har hänt att jag ibland behövt redovisa fler nivåer av förmågor.

Applikationer

De vita rektanglarna med rundade hörn representerar it-applikationer (it-tillämpningar), det vill säga it-system som stödjer en viss verksamhetsförmåga. Observera att det är skillnad på it-system och it-applikation. En it-applikation är alltid ett it-system eller del därav, men det finns it-system som inte är applikationer, som till exempel operativsystem, integrationsplattformar eller standardverktyg som ordbehandlare eller kalkylblad.

En integrationsplattform är således i sig inte en applikation utan snarare meddelande-infrastruktur. Däremot om man har någon form av programkod som körs på integrationsplattformen som innehåller någon form av verksamhetslogik, så bör just den programkoden ses som en it-applikation och ägas av en verksamhetsförmåga.

Som sagt är inte heller Microsoft Excel en applikation. Däremot om någon tillämpar någon form av verksamhetslogik i ett Excel-ark, till exempel för att sammanställa en månadsrapport, så är just detta en it-applikation.

Omfattande affärssystem är inte heller it-applikationer utan snarare breda plattformar på vilka man kan implementera ett antal olika it-applikationer, som till exempel kundreskontra, kunddatabas med mera.

En grundregel är att en viss it-applikation alltid är en integrerad del av en del av en viss verksamhetsförmåga. Det kanske inte känns så intuitivt att det är på det sättet. Jag får ofta spontana invändningar. Men om man verkligen tänker efter så är det faktiskt så. Fast då måste man först vara överens om vad en it-applikation är, och se dessa som viktiga komponenter i en verksamhet. Hittar du en it-applikation, det vill säga per definition ett it-system (eller avgränsad del av ett it-system), som stödjer en viss aspekt av en verksamhet (det vill säga en viss förmåga) så måste den applikationen utgöra en integrerad del av den verksamhetsförmågan.

Men nu kanske du som läsare invänder; det finns ju applikationer som används på många ställen, så som tidrapporteringssystem, epost-system, ärendehanteringssystem. Mitt svar blir då att också dessa är integrerade delar av sina specifika verksamhetsförmågor, som då är stödförmågor som används på många ställen. Det finns en förmåga som är tidrapportering, som då inte bara består av ett tidrapporteringssystem utan också av verksamhetsregler, processer, ansvarsroller, tjänster med mera. En hel liten verksamhet således, liksom fallet är med alla verksamhetsförmågor. Tricket är att inse att vi har många olika stödförmågor som alla är som hela små verksamheter och används av flera mer centrala förmågor.

Detta, att en applikation alltid är en del av en förmåga, går tillbaka på det som kallas ”Conway´s Law”. Jag kommer beskriva den regeln i en artikel längre fram samt hur man kan tillämpa den på sin it- och verksamhetsarkitektur.

Jag har ritat en del applikationer som en cylinder, det vill säga en symbol för en databas. Jag gör så ibland när det handlar om en applikation där jag bedömer att fokus är datalagring och verksamhetslogiken i övrigt är föga framträdande. Men jag har ingen tydlig regel för när jag använder den symbolen.

Tjänster

Jag använder termen ”tjänst” i en bred mening; Det är när en part erbjuder en eller flera andra parter någon form av upprepbar nytta. Och jag menar att parterna i fråga alltid är verksamhetsförmågor, i den betydelse som vi här talar om. Även externa parter kan vi som sagt se som verksamhetsförmågor, eftersom vi rör oss med ett fraktalt begrepp är hela verksamheter också verksamhetsförmågor.

Så det är alltid en verksamhetsförmåga som äger och producerar en tjänst. Rent tekniskt kan det vara en automatiserad tjänst. Då är det en applikation som ligger bakom. Det kan också vara en manuell tjänst, som då betjänas av en mänsklig roll.

Den eller de som använder (konsumerar) en tjänst är också verksamhetsförmågor. Det kan vara en automatiserad användning. Då är det en it-applikation som använder ett elektroniskt gränssnitt av något slag. Det kan också vara en manuell användning, det vill säga att en människa använder någon form av användargränssnitt.

Så vi har alltså två nivåer av producenter och konsumenter. Dels verksamhetsförmågor, dels it-applikationer eller mänskliga roller.

Jag menar att en verksamhet alltid består av ett antal verksamhetsförmågor som samverkar operativt i olika mönster. All sådan samverkan kan vi se som att man producerar och använder tjänster. All integration går således via tjänster, oavsett vilken teknik som används, vilket meddelandemönster som används. vilken part som initierar utbytet, eller i vilken riktning det sker dataöverföring.

Beroendet går nästan alltid från den som konsumerar till den som producerar tjänsten. Genom att rita ut ”godisklubban” ser vi beroende-riktningen. Denna riktning är inte kopplad varken till vilken part som initierar utbytet eller i vilken riktning det sker dataöverföring.

Tjänster har ofta namn och detta skriver jag på klubbskaftet.

Dataflöde

Speciellt viktigt för oss som arbetar med informationsarkitekturen är det att vi har ett sätt att markera vilken datamängd som transporteras och i vilken riktning. Jag menar att data när den delas alltid gör detta via användning av en tjänst och att riktningen som sagt inte alltid stämmer med beroende-riktningen. Jag markerar på linjen vilken data det rör sig om och i vilken riktning överföringen sker. Jag bryr mig endast om det som verkligen är ett informationsutbyte och inte eventuella frågeparametrar. Ibland går utbytet båda vägarna. Då markerar jag båda riktningarna.

Fortsättningen

Nu har jag visat hur en integrationskarta kan se ut. Men fortfarande har vi inte gått in på hur den kan användas, och inte heller hur man tar fram en sådan. Det får följande artiklar i serien handla om. Samt hur kartan kan knyta ihop verksamhet och it i samma vy, och hur man kan utforma den för att verkligen fånga verksamhetens övergripande struktur.

Häng med!

/Peter Tallungs

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.