Förmågekartor för informationsarkitektur – del 8: Hur man kan använda integrationskartan

Föregående artikel presenterade hur en integrationskarta kan se ut. I denna artikel berättar jag vad en sådan kan användas till. Inte minst för att analysera, beskriva och hantera datalogistiken i din verksamhet och it.

/Peter Tallungs, IRM 2023-02-09

Det jag kallar för en integrationskarta, och som presenterades i den föregående artikeln i serien ”Förmågekartor för informationsarkitektur – del 7 – Integrationskartan” är en ritning eller karta över en verksamhet. Den visar vilka operativa delar en verksamhet består av (det vi kan kalla verksamhetsförmågor), samt hur dessa delar samverkar operativt genom att tillhandahålla varandra tjänster av olika slag.

En grundkarta

Denna typ av förmågekarta fungerar som en grundritning vilken visar verksamhetens operativa struktur, det vill säga vilken plats verksamhetens olika delar har i förhållande till varandra. Den visar också it-landskapet i samma vy, där applikationer och integrationer ses som integrerade delar i verksamheten. Kartan ger översikt och orientering och är samtidigt tillräckligt konkret och detaljrik för att ge stadga åt dialoger runt applikationer, roller, tjänster med mera.

Jag brukar börja mina uppdrag med att ta fram en sådan integrationskarta. Jag gör det för att jag alltid, oberoende av vad uppdraget handlar om, behöver förstå hur verksamheten hänger ihop.

Det jag behöver förstå är följande:

• Vilka delar (verksamhetsförmågor) verksamheten består av.
• Vilka externa parter i det omgivande landskapet man interagerar med, det vill säga kunder, partners, leverantörer med flera.
• Hur dessa externa parter är placerade i förhållande till varandra i verksamhetens struktur (eller om vi vill kalla det för arkitektur), det vill säga det storskaliga mönster det operativa beroendet mellan delarna bildar.
• Hur delarna är integrerade med varandra (vem som tillhandahåller nytta åt vem och vilken nytta), det vill säga vilka tjänster varje verksamhetsförmåga tillhandahåller och vem som använder dessa tjänster.
• Hur beroendena går mellan delarna. Vilken del som är beroende av vilken.
• Vilka it-applikationer som finns och var de hör hemma i verksamheten, det vill säga vilken förmåga varje enskild applikation är en integrerad del av.
• Vilka roller personer har och var de har sina roller i detta landskap.
• Hur data delas och distribueras i detta landskap.

Den här kartan går överraskande enkelt att ta fram. I varje fall i sin grundversion, ty sedan kommer jag att lära mig mer allt eftersom.

Kartan blir en grund för arbetet. Den behövs verkligen, ty man kan inte förändra det man inte vet vad det är eller hur det fungerar.

I en senare artikel ska jag visa hur man kan ta fram en integrationskarta.

En gemensam bild

Integrationskartan visar hur hela it-landskapet är en integrerad del av verksamhetslandskapet. Varje applikation har en bestämd plats i verksamheten. Likaså har varje tjänst och varje integration sin plats. Därmed är kartan gemensam för verksamhet och it. Det är, mig veterligen, enda sättet vi kan se verksamhet och it i samma vy. Vilket vi behöver, för hur ska vi annars kunna hantera it som en integrerad aspekt av verksamheten?

Kartan är en gemensam grund för allt arbete där man behöver se hur en verksamhet hänger ihop, i första hand inom alla typer av utvecklingsarbete men också allt annat arbete som kräver en gemensam överblick över de olika delarna och hur de interagerar.

Man kan säga att en verksamhet i sin dagliga funktion är som en maskin där material, tjänster och data strömmar genom dess delar. Integrationskartan är ritningen på den maskinen.

Eller om man föredrar att se det som ett ekosystem. Kartan är schemat över ekosystemet, visar vilka organismer som finns och hur de utbyter ekosystemtjänster.

Användning inom informationsarkitektur

Integrationskartan har ett mycket brett användningsområde, men i mitt arbete som informationsarkitekt vill jag fokusera på följande två användningar:

• Kontextkarta för informationsmodeller

En informationsmodell visar en domän av något slag, det vill säga vilka företeelser som hanteras, inklusive företeelsernas egenskaper, samband och regler, samt begrepp och benämningar för detta (definitioner, namn, synonymer), samt vilka data som representerar dessa företeelser.

Men en informationsmodell svävar inte i luften. Den har en kontext, ett område inom vilket den gäller. Den kan gälla för en hel verksamhet, men kanske inte för verksamhetens samverkan med externa parter.
Den kan också gälla för en viss förmåga eller för flera samverkande förmågor. Den kan också gälla endast för en viss tjänst eller grupp av tjänster. Därmed har en informationsmodell alltid en viss räckvidd, det vill säga ett område inom vilken den gäller. Det vi kallar för kontext. Då behöver vi integrationskartan för att definiera och avgränsa vilken kontext en viss informationsmodell har.

Vanligt i branschen är annars att man tar fram modeller som har oklar räckvidd. Man anser kanske att de gäller för hela verksamheten. Vad nu ”hela” verksamheten är. Gäller den precis fram till organisationens gräns? Inbegriper man partners, outsourcade funktioner, leverantörer?
I en stor organisation har man sällan varken den överblicken eller mandatet att kartlägga en hel verksamhet, i varje fall inte från början. Vanligen är räckvidden oklar för de modeller man möter. Resultatet blir ofta att man har olika disparata modeller i svang med olika räckvidd och status men sällan tydligt tänkt och deklarerat.

Det är viktigt att vi tydligt deklarerar vilken räckvidd våra modeller har. Till det behöver vi en integrationskarta, att använda som ”kontextkarta” det vill säga en karta där vi kan diskutera och markera vilket sammanhang en viss modell gäller för.

• Grund för arbetet med datalogistiken

Som informationsarkitekt behöver jag analysera och dokumentera var en viss datamängd uppstår, fångas eller anskaffas, var och hur den delas, förvaras, hanteras och transformeras, samt inte minst var och av vem den används. För detta behöver jag en karta som visar verksamhetens operativa delar (förmågor) samt vilka applikationer som finns var och vilka tjänster som används för deras samverkan. Ty det är ju via dessa integrationer som data rör sig i verksamheten. Jag kan med kartans hjälp följa en viss datamängd i många steg genom landskapet, från dess källa, där den uppstår eller först uppträder, genom alla steg och förvandlingar till de olika ställen den används. Jag kan hitta vem som använder denna datamängd och till vad. Jag kan ta kontakt med användarna, förstå vad de behöver, vad som brister och vad de skulle behöva. På så sätt får vi både överblick och detaljer om hela de långa kedjorna och vilka effekter vi behöver hantera och var det behöver göras.
Jag vet inget annat sätt att åskådliggöra och hantera detta, som verkligen fungerar.

Andra användningar

Denna typ av förmågekarta har många andra användningsområden inom verksamhetsarkitektur-arbetet. De som jag nämnt ovan är endast de som mer eller mindre direkt är en grund för arbetet med informationsarkitekturen.

Men ett annat användningsområde som jag tycker är viktigt att nämna är att kartan är en grund för tjänsteorientering som en del av verksamhetsarkitekturen. Tjänster är viktiga komponenter i en verksamhetsarkitektur och har haft en intensiv hajp inom it-arkitektur under ett och ett halvt decennium, men sorgligt nog betraktats som något av rent tekniskt intresse och därmed inte fått en plats hos verksamhetsarkitekter.

Vi behöver se tjänster som fullvärdiga medlemmar av verksamhetsarkitekturen.
Tjänster frikopplar vad en viss verksamhetsförmåga gör från hur den gör det, det vill säga utsida från insida. Det kallas för ”decoupling” och är den viktigaste egenskapen hos en arkitektur för att göra den robust och flexibel. Utan tjänster har vi ingen verksamhetsarkitektur värt namnet skulle jag vilja påstå.

Jag vill se precis varje integration i en verksamhet som en tjänst, även om namnet ofta har använts för bara vissa typer av integrationer. Men verksamhetsmässigt behöver vi se och hantera varje integration på samma grundläggande sätt, och vi behöver ett namn för detta. Låt oss kalla det för tjänster. Sedan finns de förstås skillnader, beroende på teknik och meddelandemönster, där olika tekniker och meddelandemönster ger olika egenskaper för integrationen. Men det är en problematik på lägre nivå. Först och främst behöver vi förstå, kartlägga och hantera alla integrationer på samma grundläggande sätt. Att se dessa som tjänster betyder att vi gör synligt att någon är producent (ägare) av tjänsten och andra (en eller flera) är konsumenter. Därmed har vi också synliggjort riktningen för det direkta beroendet, som ju är viktigt för all typ av arkitekturtänk.

Att en viss tjänst har en plats betyder att den är förankrad någonstans i verksamheten. En tjänst behöver precis som allt annat återfinnas någonstans i verksamheten, ha sin kontext och sin ägare. Det naturliga är att de ägs av verksamhetsförmågor, på det sätt som vi visar här.

Kartan ger helt enkelt tjänster sin plats i verksamhetens arkitektur. Det är kanske första gången. Jag har i varje fall inte sett det tidigare någonstans.

Dialog

Jag för här fram synsätt som är nya och inte allmänt delade. Därför är det intressant att höra dina tankar. Dialogen är viktig för att utveckla området. Så nu är det din tur. Kanske vill du invända mot något eller komplettera med dina erfarenheter? Hur gör du för att bygga informationsarkitekturen i en verksamhet? Vad av detta jag beskriver har du provat? Hur gick det? Eller gör du helt annorlunda?

Nästa artikel

Vi har nu gått igenom hur en integrationskarta kan se ut och översiktligt vad man kan använda den till. Nästa artikel visar hur vi kan uppnå det som måste räknas som verksamhetsarkitekturens heliga gral, att knyta ihop verksamhets- och it-arkitektur till att bli en gemensam arkitektur.

/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.