Förmågekartor för informationsarkitektur – del 1: Vad ger en förmågekarta?
Utan en förmågekarta som stöd är det nog omöjligt att prata om informationsarkitektur för en hel verksamhet, eller större del därav. Precis som alla modeller är den lika mycket en fråga som ett påstående. Kan vi se det så här? Kan vi utveckla vår gemensamma förståelse? Jag skulle vilja säga att det är förmågekartan som lyfter mig från att bara vara informationsmodellerare till att fungera som informationsarkitekt.
/Peter Tallungs, IRM 2022-11-17
Informationsarkitektur är mer än informationsmodellering
Jag har de senaste två åren skrivit artiklar om informationsarkitektur. Många har handlat om informationsmodellering. Med informationsmodeller analyserar och beskriver vi de data och den information en verksamhet eller tjänst hanterar, eller behöver hantera.
Och som jag beskrivit i flera artiklar: Om man inte bara beskriver informationen utan också de företeelser som informationen representerar, inklusive regler för företeelsernas beteende, det vill säga verksamhetsregler. Då fångar informationsmodellen mer kunskap och blir mer av en komplett domänmodell. Ett format där man kan fånga, analysera, hantera, normera och förmedla den operativa verksamhetslogiken.
Jag har på så sätt velat visa hur våra informationsmodeller kan spela en mycket bredare roll än de traditionellt har gjort.
Men det räcker ändå inte. Om vi ska hantera informationsarkitekturen med allt vad det innebär behöver vi mer än bara informationsmodeller.
Vi behöver kartlägga och beskriva datalogistiken
Vi behöver analysera och beskriva hur data/information importeras, skapas, paketeras, transporteras, transformeras, tillgängliggörs och används i olika delar av verksamheten, samt i olika applikationer och tjänster, liksom i hela det omgivande ekosystemet av leverantörer, partners och kunder. Jag vet inte vad vi ska kalla hela det perspektivet. Man kan se det som att det är dataflödet i verksamheten man beskriver. Men det är mer än så. Det är också vad som händer med data på vägen. Vi kanske kan kalla det för datalogistiken?
För att analysera och beskriva datalogistiken behöver vi mappa in den någonstans. Vi behöver någon slags karta över verksamhetens landskap, inklusive dess omgivning. En karta som visar vilka avgränsade delar verksamheten består av, inklusive informationssystem, roller och tjänster. Detta är det landskap som data och information strömmar genom, lever i och används.
Förmågekarta som grund för att beskriva en verksamhet
Jag vill i ett antal artiklar visa hur en sådan karta kan se ut, hur man tar fram den och hur man använder den. Men för att göra det behöver vi först vara överens om vad en sådan karta kan vara till sin grund. Hur beskriver vi det landskap som data flödar genom?
I början av 00-talet började jag och mina kollegor ta fram förmågekartor (Capability maps) i de organisationer vi jobbade i. En sådan karta ger ett gemensamt, stabilt och användbart grundperspektiv på en verksamhet. Det är något man inte kan få med organisationsschema, processmodeller, informationsmodeller eller applikationskartor.
Förmågekartor blev till ett beskrivningssätt som vi utvecklat och använt i många år, och är det första jag tar fram i alla uppdrag. Jag behöver en sådan karta för att förstå och överblicka vilka delar verksamheten består av och hur dessa samverkar. I min erfarenhet finns det inget annat sätt att få den överblicken.
Vi utgår från det som vanligen kallas Förmågekarta (Capability Map). Men med den termen kan man dock mena ganska olika saker. Där finns det inget fel eller rätt, men den typen av förmågekarta som vi menar är användbar har vissa särdrag.
Jag ser ett behov av att från grunden förklara och motivera det synsätt vi kommit fram till, efter experimenterande i många olika verksamheter. Jag tror inte att det är något egentligt brott mot de mest vanliga synsätten som finns där ute, utan mer av en konkretisering och påbyggnad.
Man kan se det som att det handlar om rikare förmågekartor än de gängse. Jag har i tidigare artiklar visat hur vi kan göra rikare informationsmodeller, det vill säga informationsmodeller som innehåller mer och kan användas till mer än de vanligen gör. På liknande sätt vill jag med dessa artiklar visa hur vi kan göra rikare förmågekartor. Förmågekartor som innehåller mer än vad som är vanligt och kan användas till mer än vad som är brukligt.
Så de första artiklarna som jag nu skriver om förmågekartor kommer inte alls att handla om dataflöden och informationsarkitektur, utan bara om den grund i vilken informationsarkitekturen lever, det vill säga verksamhetens grundläggande operativa arkitektur och hur vi vill se på den.
Vad är en förmåga?
Det finns olika uppfattningar om vad en förmåga är för något, och därmed vad en förmågekarta är. Vad alla är överens om är att en förmåga uttrycker ”vad” en verksamhet gör eller behöver kunna göra. Men det är en i högsta grad luddig definition som öppnar upp för många olika tolkningar.
Som vanligt finns det inget rätt eller fel. Men det finns synsätt som är mer eller mindre användbara för olika syften. Jag menar dock att det synsätt jag använder och vill förmedla är det som är användbart på många sätt i arbetet med Enterprise-arkitektur, och då inte minst för att beskriva datalogistiken.
Ett användbart synsätt
Det synsätt jag använder är att en förmåga är en operativ del av en verksamhet som man kan se som avgränsad, det vill säga som en egen liten verksamhet med allt vad det innebär. Det är inte vad man menar med termen förmåga i vanligt tal utan mera hur en viss operativ förmåga är konkret förverkligad i en verksamhet som en avgränsad autonom funktion.
Förmågeperspektivet ger en fraktal vy, vilket innebär att en förmåga kan delas ner så att den i sin tur är uppbyggd av förmågor. En verksamhet är på så sätt ett nätverk, eller ekosystem, av mindre enheter (som vi kallar förmågor) som samverkar för att leverera produkter och tjänster till sin omgivning.
Detta synsätt behöver motiveras, vilket jag kommer göra de närmast efterföljande artiklarna. Men för nu räcker det med att acceptera att en förmåga inte är något annat än en egen avgränsad liten verksamhet i verksamheten.
Eftersom det finns så många olika uppfattningar om vad termen förmåga ska stå för, tvekar jag ofta att kalla det för förmågekarta. Jag säger ofta funktionskarta eller integrationskarta. Men låt oss se det jag framför i dessa artiklar som en stipulerande definition, det vill säga ”med förmågekarta menar jag här detta…”.
Vad ger en förmågekarta?
Syftet med en förmågekarta i detta sammanhang är att ge en gemensam bild för följande:
- Vilka avgränsade operativa delar (förmågor) en verksamhet består av
Vilka namn vi kan ge dem och hur vi kan definiera dem
- Hur dessa förmågor kan positioneras i förhållande till varandra
Vilka förmågor som är delar av större förmågor. Vilka förmågor som är bakomliggande stöd (stödförmågor) till de mer centrala förmågorna (kärnförmågorna).
- Vilka it-applikationer som ingår som en del av en viss förmåga
Vad applikationen heter (konceptuellt och fysiskt) och hur den definieras.
- Vilka tjänster (digitala eller manuella) som tillhandahålls av en viss verksamhetsförmåga eller extern part
- Vilken applikation eller personroll som realiserar tjänsten
- Vilka förmågor (eller externa parter) som använder en viss tjänst
- Vilken applikation eller personroll (hos förmågan eller den externa parten) som använder en viss tjänst
- Vilken data-/informationsöverföring som sker vid användandet av en viss tjänst
Kartan gör det som en bra karta gör, den ger både överblick och detaljrikedom. Den ger en gemensam bild för både verksamhets- och it-folk av hur deras verksamhet egentligen är uppbyggd. Jag har ofta fått höra att det är för första gången de fått en samlad bild av alla delar av verksamheten, alla applikationer, alla tjänster. En gemensam bild av sin verksamhet tvärs över verksamhet och it.
Den blir en plattform för gemensamt lärande. Precis som alla modeller är den lika mycket en fråga som ett påstående. Kan vi se det så här? Kan vi utveckla vår gemensamma förståelse?
Vad ger en förmågekarta till informationsarkitekturen?
En stor del av mitt jobb som informationsarkitekt är att ta fram och använda beskrivningar (modeller kartor och annat) för att styra data-/informationstillgångarna, och guida dataintegration.
Som informationsarkitekt använder jag förmågekartan till två saker:
- En kontextkarta för mina informationsmodeller. För vilken del av verksamheten gäller denna modell? Vilka applikationer används var, av vem och till vad?
- Den ger en möjlighet att kartlägga ”linage”, det vill säga härstamning för olika data. Var kommer en viss datamängd ursprungligen från? Var och i vilket sammanhang överförs den? Hur och till vem överförs den? Samt var och av vem används den?
Utan en förmågekarta som stöd är det nog omöjligt att prata om informationsarkitektur för en hel verksamhet, eller större del därav. Ty för detta behöver man skapa och använda en översikt, en gemensam karta som visar hur allt hänger ihop i det ekosystem som en verksamhet är. Jag skulle vilja säga att det är förmågekartan som lyfter mig från att bara vara informationsmodellerare till att fungera som informationsarkitekt.
Så, i min mening är förmågekartan det viktigaste verktyget för oss informationsarkitekter vid sidan av informationsmodeller.
Kommande artiklar
Det finns några olika teoretiska ramverk som är värdefulla att tillämpa och även kombinera. Enterprise-arkitektur har ju egentligen ingen egen sammanhängande teoretisk grund, utan vi får låna från andra teoribildningar. Jag vill presentera vad jag kommit fram till, vilket kommer att kräva ganska många artiklar eftersom det finns många aspekter att prata om.
Nedan är de frågor jag kommer försöka besvara. Se det som en grov och preliminär plan.
- Vad är en verksamhet, egentligen?
- Hur kan vi se på en verksamhetsförmåga, med grund i komponentteori?
- Hur kan vi se på en verksamhetsförmåga, med grund i systemteori?
- Hur kan vi se på en verksamhetsförmåga, med grund i den systemteori som handlar specifikt om verksamheter?
- Hur får vi med styrning och ledning av olika slag i förmågekartan?
- Hur kan vi se på stödförmågor, det vill säga interna förmågor som enbart är till för att stödja andra förmågor?
- Hur relaterar olika verksamhetsförmågor till varandra?
- Vad består en verksamhetsförmåga av?
- Hur kan man gestalta hela landskapet av verksamhetsförmågor i en förmågekarta?
- Hur förhåller sig våra it-system till våra verksamhetsförmågor?
- Hur förhåller sig våra interna och externa tjänster till våra verksamhetsförmågor?
- Hur förhåller sig processer till tjänster och förmågor?
- Hur förhåller sig informationsmodeller till förmågor?
- Hur kan man representera data-/informationstransporter i en förmågekarta?
- Hur kan man ta fram en förmågekarta?
- Hur kan man gestalta en förmågekarta?
- Vad kan man använda en förmågekarta till i allmänhet?
- Hur kan man använda en förmågekarta till i arbetet med informationsarkitektur?
Min förhoppning är att du som jobbar med informationsarkitektur (eller för den delen någonstans inom hela det stora EA-området) och läser detta vill hänga med på denna resa. Hoppas du vill läsa, begrunda, och diskutera. Och själv prova för att se om det hjälper dig i ditt arbete, att guida verksamheter till att bättre hantera sin informationsresurs.
/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.
