Verksamhetsmodellering som arkeologi – en metodbeskrivning

Hur man kan kartlägga en verksamhet utgående från dess it-landskap?

/Peter Tallungs, IRM, 2024-11-21

Prolog

Förra artikeln ”Informationsmodellering som arkeologi – En metodbeskrivning” beskrev hur man kan kartlägga en verksamhets information, liksom de företeelser som hanteras, utgående från datastrukturer och data. Jag kallar metoden för data-arkeologi. Termen ”arkeologi” indikerar att man utgår från fakta, vad man fysiskt hittar, vilket sedan tolkas och sätts i sammanhang.

Det är kanske inte så förvånande att man från befintliga datastrukturer och data kan härleda verksamhetens informationsmodell.

Arkeologi

Denna artikel tar upp en annan form av liknande ”arkeologi” som är mer okänd. Nämligen hur man utifrån verksamhetens it-landskap kan få fram verksamhetens operativa uppbyggnad och arkitektur. Resultatet blir en karta som visar vilka komponenter verksamheten består av och hur de förhåller sig till varandra och dess omgivning. Något vi kan kalla för en verksamhetskarta.

Vi behöver en sådan karta för att kunna kartlägga datalogistiken, var en viss datamängd kommer ifrån, vilka vägar den tar, vad som händer med den på vägen och vem som använder den.

Vi behöver en verksamhetskarta

En verksamhetskarta visar verksamhetens funktioner, tjänster, roller, it-applikationer och informationsflöden. Kartan har en struktur som placerar in alla dessa komponenter i sina sammanhang i relation till varandra.

Epitetet ”karta” visar att den har en geografi i två dimensioner.

Denna artikel beskriver hur man kan ta fram en sådan karta. Men först behöver vi gå igenom lite underliggande teori.

Conways lag

Metoden bygger på det som kallas ”Conways lag”. Den säger att om en organisation bygger ett it-system så får det en struktur som avspeglar organisationens kommunikationsstruktur. Tillämpat på en verksamhet innebär det att strukturen hos en verksamhets it-landskap avspeglar organisationens struktur. Jag menar att vi på detta sätt kan få fram är den verkliga operativa strukturen, ofta dold bakom organisationsschemat.

Det betyder att man utgående från vilka it-applikationer det finns kan identifiera vilka verksamhetsfunktioner det finns. Samt att man utgående från vilka systemintegrationer det finns kan deducera hur verksamhetsfunktionerna samverkar: Därigenom också via vilka vägar de kommunicerar och hur de beror av varandra.

Som exempel: Finns det en säljstödsapplikation så finns det en säljfunktion. Finns det en produkthanterings-applikation så finns det en produkthanteringsfunktion och så vidare. Kanske inte att funktionen alltid är uttalad i organisationsschemat men den finns ändå på något sätt i arbetssättet. Formell organisation är inte alltid samma sak som verklig operativ organisation, och det är det senaste vi är ute efter om vi vill förstå en verksamhet på riktigt.

Hur applikationsportföljen kan berätta om vilka verksamhetsfunktioner som finns

En verksamhetsfunktion är i detta sammanhang en avgränsad operativ och autonom del av en verksamhet. Alltså ett eget delsystem av det ”system” som en verksamhet kan ses som enligt den systemteori som handlar om verksamheter.

Jag vill alltså använda termen ”verksamhetsfunktion”, men det går också att kalla det för ”verksamhetsförmåga”. Men bara om man verkligen avser en avgränsad del av en verksamhet. Ty ofta används termen verksamhetsförmåga för vad verksamheten ska åstadkomma, vilket inte är samma sak.

Definitionen och förståelsen av termen ”verksamhetsförmåga” svajar inom enterprisearkitektur och management mellan dessa två oförenliga betydelser. Därmed vill jag i stället kalla de avgränsade delar en verksamhet är uppbyggd av, och som vi avser, för verksamhetsfunktioner. Inte för att den termen heller är fri från andra betydelser, men jag ser ändå det som ett mindre bekymmer än de vi ständigt har med termen ”verksamhetsförmåga”. Allt för att bringa större klarhet i begreppen vi använder.

Verksamhetsfunktioner har olika placering i den geografi som är verksamhetens arkitektur. Det kan vara en funktion riktad mot kunder som marknadsföring eller försäljning. Det kan vara en kärnfunktion längre bak som olika former av produktion. Det kan vara en funktion som stödjer andra funktioner såsom tidrapportering, ekonomihantering, HR, ärende- och dokumenthantering med mera.

Hela synsättet med verksamhetsfunktioner är fraktalt, så en verksamhetsfunktion kan vara uppbyggd av flera mindre verksamhetsfunktioner.

Alltså: Om vi vet vilka it-applikationer som används så kan vi därifrån härleda vilka verksamhetsfunktioner det finns. Vi bör se det som att it-applikationen är en integrerad del av verksamhetsfunktionen, inte ett stöd till verksamhetsfunktionen vilket tidigare varit vanligt. Ty en it-applikation innehåller och exekverar alltid verksamhetslogik i någon form. På så sätt kan vi förändra synsättet till att se it som en integrerad del av verksamheten – på riktigt!

En applikation är inte alltid detsamma som det som benämns som it-system. En it-applikation är per definition ett it-system (eller avgränsad del av it-system) utformat för en viss funktion i verksamheten. Ett affärssystem är vanligen att se som en svit av olika applikationer. En Excelsnurra eller ett Excelark kan vara en it-applikation så länge den innehåller verksamhetslogik i någon form.

Hur it-integrationerna kan berätta om hur verksamhetsfunktionerna samverkar via tjänster

En tjänst är i detta sammanhang något en part – tjänstens ägare och producent – erbjuder en eller flera andra parter (tjänstens konsumenter). Vanligen i avsikt att tillhandahålla en nytta av något slag. Parterna i fråga är alltid verksamhetsfunktioner, antingen interna eller externa. Tjänsterna kan vara antingen materiella eller immateriella och de kan efterfrågas och levereras med vilken kommunikationsteknik som helst. Tjänster har egentligen alltid någon form av kontrakt, det vill säga ömsesidiga överenskommelse mellan producent och konsument om vad, hur och när tjänsten ska tillhandahållas. Kontrakten är oftast helt eller delvis underförstådda och bristfälligt dokumenterade – men de finns där likafullt.

Alltid då det finns en integration mellan två it-applikationer i olika verksamhetsfunktioner, eller mellan en it-applikation och en mänsklig roll, alternativt mellan två mänskliga roller, så är det att se som en tjänst. Den ena funktionen erbjuder andra funktioner en möjlighet till samverkan.

På så sätt är verksamhetens samlade tjänster hela det nervsystem medelst vilka verksamhetens delar samverkar med varandra och omgivningen.

Hur verksamhetstjänsterna ger den övergripande verksamhetsarkitekturen

Viktigt för hela verksamhetsarkitekturen är att se de beroenden som tjänsterna indikerar. Vilka verksamhetsfunktioner som betjänar vilka. På så sätt kan vi se en verksamhets hela operativa struktur som ett antal skikt; en ”business front” eller ”front end” som direkt möter kunder och andra intressenter man betjänar, en ”business core” eller ”business backend” som ligger där bakom och utför själva kärnprocesserna, samt längst där bak alla stödfunktioner som utgör den infrastruktur som betjänar de övriga verksamhetsfunktionerna. Beroenden går på så sätt alltid från kunderna mot business front, som i sin tur är beroende av business core. Båda dessa skikt är beroende av stödfunktionerna. På så sätt får vi fram verksamhetens geografi, både den inre geografin (hur de olika funktionerna är skiktade) och förhållandena till omvärlden, det större ekosystem som verksamheten är en del av. Vi ser vad som är nära och vad som är långt ifrån varandra och vad som ligger parallellt i förhållande till varandra. Vi får en gemensam bild av hur verksamheten är uppbyggd. Det finns återkommande mönster för olika verksamhetsstrukturer, vilka beskrivs i en av artiklarna som ingår i den artikelserie som refereras till i slutet av denna artikel.

Verksamhetskartans användning för data management

Verksamhetskartan behövs för många saker i en organisation, inte minst för verksamhetsutveckling med it. För oss informationsarkitekter är kartan viktig av två skäl. För det första behöver vi kartan för att analysera och dokumentera den väg en viss datamängd tar genom en verksamhets olika delar och vad som händer på vägen. Var, hur och av vem den skapas, vart och hur den transporteras, transformeras, lagras, tillhandahålls och används. Vilka it-applikationer, tjänster och roller som gör allt detta.

En annan användning av verksamhetskartan för oss informationsarkitekter är att den utgör en kontextkarta för våra informationsmodeller. En informationsmodell har ju alltid en viss kontext, ett område inom vilken den gäller. Den kan gälla för en hel verksamhet, men den kan också gälla endast för en viss verksamhetsfunktion eller en tjänst, en grupp av verksamhetsfunktioner eller tjänster, en viss leverantörskedja eller för samverkan inom en hel bransch. Vi kan markera i verksamhetskartan för vilket sammanhang respektive informationsmodell gäller.

Gör så här

Så här vill jag beskriva metoden i olika steg. I praktiken är arbetet mer iterativt än vad som framgår här.

1. Ta reda på och etablera samarbete med den eller de personer som är mest kunniga om it-portföljen och integrationerna mellan it-systemen

Det är vanligen någon it-arkitekt eller motsvarande.

2. Gå igenom it-kartan med dessa it-kunniga personer

Vanligen finns det en karta över vilka it-system det finns och hur de är integrerade med varandra. Om inte annat så kan de rita upp en sådan.

3. För varje it-system: Ta reda på var det hör hemma i verksamheten

Ta reda på vad systemet gör i stort, vilka olika delar av verksamheten och vilka roller som använde det. Detta klargör systemets roll som en it-applikation och visar var i verksamheten det hör hemma.

I det fallet it-systemet är tydligt uppdelat i olika delsystem, som var och en används av olika delar av verksamheten, så är it-systemet flera olika it-applikationer som hör hemma i olika verksamhetsfunktioner.

I det fall att it-systemet stödjer olika delar av verksamheten så är det förmodligen en it-applikation med gemensam funktionalitet som hör till en stödfunktion som inte är riktigt formaliserad.

4. För varje it-applikation: Ta reda på vilka integrationer som finns

Det kan vara integrationer med andra it-applikationer eller med interna eller externa roller. Integrationerna kan ske via api:er, filer, web services, eller manuella integrationer som via användargränssnitt med mera.

Ta reda på vad integrationen innehåller för data, vilken (eller vilka) riktningar dataöverföringen går, vilken integrationsteknik, integrationsmönster och periodicitet som används. Samt inte minst viktigt, vilken sida som kan sägas äga kontraktet och vilken sida som har nyttan av integrationen så att vi därmed kan säga vem vi kan betrakta som producent av tjänsten och vilken (eller vilka) konsumenterna är. Anteckna även vad filen, api:et eller liknande heter och vem som kan visa det för dig.

5. Börja rita en första version av verksamhetskartan

Du har nu ett utkast med förmodade verksamhetsfunktioner med sina respektive it-applikationer och roller. Du har även hur de samverkar med varandra via tjänster. Därmed kan du se hur de operativa beroendena går och kan rita upp verksamhetens olika skikt: business front, business core och stödfunktioner.

6. Expandera kartan till kundsidan

Ta reda på vilka kunderna är och hur de interagerar med vår verksamhet via de tjänster vi tillhandahåller. Det kan vara api:er, digitala tjänster eller manuella tjänster via telefon, mejl eller fysiska besök. Det kan också vara fysiska varuleveranser. I många verksamheter är det också intressant med kundernas kunder.

7.Expandera kartan till leverantörssidan

Ta reda på vilka leverantörer det finns och hur vi interagerar med dessa via tjänster. Det kan vara api:er, digitala tjänster eller manuella tjänster via telefon, mejl eller fysiska besök. Det kan också vara fysiska varuleveranser. I många verksamheter är det också intressant med leverantörernas leverantörer.

8. Detaljera it-applikationerna och tjänsterna

Ta kontakt med kunniga för varje it-applikation och gå igenom följande i mer detalj:

• Vilka roller använder it-applikationen?
• Vad gör de i applikationen?
• Exakt vad gör varje integration och vilken data är det som överförs?

9. Identifiera och dokumentera ”skugg-it”

Ofta finns det informationssystem av olika slag som it-sidan inte har närmare kunskap om eller saknar ansvar för. Det kan vara Excelark eller rent manuella beställnings- och leveransrutiner via mejl.

Dessa är också en del av verksamhetens landskap och bör tas med som verksamhetsfunktioner, it-applikationer, roller, och tjänster som alla tillhör olika verksamhets

Jag och mina kollegor har gjort på detta sätt i många olika verksamheter. Det är verkligen ett sätt att snabbt få upp en karta över en verksamhets struktur och komponenter.

Lästips

Vill du fördjupa dig i vad en verksamhetskarta av detta slag är så har vi en artikelserie om tio delar på temat förmågekartor för informationsarkitekter, och som börjar med följande artikel: Förmågekartor för informationsarkitekter del 1.

Observera att i artikelserien kallar jag verksamhetsfunktioner för verksamhetsförmågor. Men eftersom termen verksamhetsförmåga tenderar att leda tankar i fel riktning använder jag i denna artikel i stället termerna ”verksamhetsfunktion” och ”verksamhetskarta”.