Förmågekartor för informationsarkitekter – del 9: Hur man beskriver sin verksamhet i en karta

Denna artikel handlar om tre delar som hänger ihop. Den första är att vi behöver beskriva och hantera it och verksamhet som den gemensamma helhet den egentligen är. Den andra hur vi kan göra det med den typ av rika förmågekarta som jag beskrivit i denna artikelserie. Den tredje är den teoretiska grunden för att det kan fungera på det sättet som beskrivs.

/Peter Tallungs, IRM 2023-02-23

Vi behöver se it och verksamhet som hopvävda aspekter av en och samma helhet

I våra organisationer hanteras it nästan alltid som en egen avgränsad verksamhet, en egen avdelning, vilken utgör en stödfunktion till den egentliga verksamheten. Det man ofta hör är om det som ibland kallas ”IT and Business Alignment”; att informationstekniken inte finns till för sin egen skull utan ska tjäna verksamhetens behov. Men det uttrycket skvallrar om att man fortfarande ser it som en separat företeelse. Något som tjänar verksamheten men är skilt från denna, det vill säga ett stöd till verksamheten men inget som är integrerat i verksamheten.

Detta är i grunden fel menar jag. It är inte ett stöd till verksamheten, it är och bör hanteras som en integrerad aspekt av verksamheten. Ty många av verksamhetens processer går till stor del genom det moln av olika sammanhängande it-system som finns spridda över en verksamhets olika delar. Åtminstone gäller det för centrala delar av mer digitaliserade verksamheter. Därmed är varje it-applikation en integrerad del av den verksamhetsförmåga (eller om vi vill benämna det verksamhetsfunktion) den finns till för. Och därmed är utveckling av en applikation utveckling av den verksamhetsförmåga den ingår i. Vidare är drift av en applikation drift av en verksamhetsförmåga, och förvaltning av en applikation förvaltning av en verksamhetsförmåga. Användarstöd är stöd för användningen av en verksamhetstjänst. Integration av applikationer är integration av de verksamhetsförmågor applikationerna ingår i.

För oss informationsarkitekter innebär det att när vi modellerar information och data så modellerar vi den information en verksamhetsförmåga hanterar eller behöver hantera. Samt inte minst vad denna information handlar om, vilka företeelser denna information representerar, vilka egenskaper hos dessa företeelser man behöver hantera och språket vi behöver för att benämna allt detta.

Allt detta är intimt relaterat till informationsteknik men det är lika sant att det helt och hållet är verksamhet vi beskriver och utvecklar.

Melvin Conways lag från 1967 är den heliga gral som vi söker, som just kan få oss att beskriva och hantera verksamhets- och it-arkitektur som en helhet. Mer om det längre fram i artikeln.

Hur vi delar in saker och ting har betydelse

Det har betydelse hur vi delar in saker och ting. Jo visst, kanske du tänker. Men vi kan inte ta in alla perspektiv på en gång. Måste vi inte stycka upp helheten så att vi kan ta ett område åt gången? kanske du tänker. Jo, visst är det så. Men vi bör då dra snittet där beroendet är någorlunda rakt och enkelt och inte där beroendena går kors och tvärs överallt. Vi kan se varje förmåga som en autonom helhet, som en egen liten verksamhet med allt vad det innebär. Vi kan lätt hantera och utveckla en förmåga avgränsat, så länge vi har definierat våra förmågor som autonoma avgränsade helheter. En förmåga har tydliga enkla och raka operativa beroenden till andra förmågor, som vi kan se som tjänster, där en förmåga tillhandahåller en nytta till en eller flera andra förmågor. Men vi bör däremot aldrig tro att vi kan utveckla it-systemen för en förmåga för sig och verksamheten för sig, som om de vore olika företeelser.

Vi är själva en del av problemet

Om vi går med på det ovanstående, hur kan vi som arkitekter bidra till att våra organisationer börjar hantera verksamhet och it som en helhet? Vi är en del av problemet menar jag, alla vi som har olika arkitektroller. Det handlar om hur vi beskriver saker och ting, att vi har helt separata vyer på en och samma verksamhet. It-arkitekter har systemkartor utan några spår av den verksamhet som systemen är en del av. Och verksamhetsarkitekter tar fram förmågekartor som bara radar upp verksamhetsförmågor utan spår av de applikationer och tjänster som är påtagliga beståndsdelar av förmågorna och hur de samverkar. Eller ännu värre, ser it-förmågor som något separat, skilt från verksamheten.

Det är viktigt hur vi ritar

Hur vi avbildar verksamhet och it har betydelse. Vi skapar våra modeller, sedan formar modellerna oss. Det är en djup och betydelsefull sanning. Det är så vi människor fungerar. Det är så vi bygger vår förståelse. Vi har mentala modeller och de formas av de explicita modeller vi ritar.

Det handlar förstås också om vad som intresserar oss. Det finns it-arkitekter som intresserar sig för verksamhet men de är i minoritet. Jag upplever också att verksamhetsarkitekter under de senaste åren har rört sig bort från den operativa verksamhetslogiken och mer mot affärsfrågor. Och därmed bort från det som riskerar att inbegripa informationssystemen och hur de är integrerade. Det är en sorglig utveckling, som gräver diket mellan it och verksamhet ännu djupare, när vi i stället borde flytta ihop och hjälpas åt.

Vad kan vi göra åt det?

Om vi är överens om att detta är ett problem, vad kan vi göra åt det, på riktigt(!), utan att bara slå ut med händerna och bekvämt skylla på organisationsformer med olika kulturer och uppdelade budgetar?

En grundförutsättning för att vi it- och verksamhetsarkitekter ska kunna jobba tillsammans är att vi har effektiva gemensamma modeller. Framför allt en karta som visar verksamhets- och it-landskapet i samma vy. Modeller är ju till för att samlas runt, för att få ett gemensamt språk och gemensam plattform. Om vi har olika modeller för samma sak, fast med olika vyer, måste vi hela tiden översätta mellan dessa. En it-person och en verksamhetsperson har då olika bilder i huvudet, vilket skapar friktion i kommunikationen. Inte så farligt tycker man kanske, men en liten friktion på många, många ställen blir till en stor friktion, vilket resulterar i att man kör fast.

Matriser är inte lösningen

Ibland ser man ambitiösa modeller som ska knyta ihop it och verksamhet genom att vara en brygga mellan en verksamhetsvy och en it-vy. Som till exempel matriser av olika slag som exempelvis visar vilken process som använder vilket it-system. Men det är inte lösningen. Då får vi tre representationer i stället för två. En för it och en annan för verksamhet och en tredje som redovisar de korsvisa sambanden. Det blir då visserligen möjligt att punkt för punkt översätta mellan två världsbilder. Men grundproblemet att vi har två olika världsbilder kvarstår. Vad vi behöver är i stället en gemensam bild, som rymmer flera aspekter i samma vy.

Vi behöver modeller som visar verksamhet och it i en och samma vy

Vad vi behöver är inte en tredje vy som knyter ihop två olika vyer. Vi behöver en och samma modell som ger båda perspektiven, det vill säga både verksamhet och it i en och samma vy.

Men är det möjligt att trycka in allt detta i samma struktur? Vad bygger det på för principer? Har inte it-landskapet i en verksamhet en helt annan struktur än verksamheten i sig? Nej, faktiskt inte. It-strukturen speglar alltid organisationsstrukturen. Det har systemutvecklare vetat i ett halvsekel, men den kunskapen har ännu inte bubblat upp till arkitektskrået.

Det som kallas Conways lag är den heliga gral vi söker, den ”rosettesten” som knyter ihop verksamhet med it genom att se it-applikationer som integrerade delar av verksamhetsförmågor, och därmed integrationer mellan it-applikationer som integrationer mellan verksamhetsförmågor.

Men hur kan det fungera? Vad är det som säger att det är så? Låt oss se hur Conways lag lyder.

Conways lag: It-landskapet speglar verksamhetsstrukturen

Any organization that designs a system (defined broadly) will inevitably produce a design whose structure is a copy of the organization’s communication structure.

Det var den amerikanske programmeraren Melvin Conway som uttryckte sin tanke på detta sätt år 1967. Detta plockades sedan upp och formulerades som en lag av Fred Brooks, år 1975. (Fred Brooks var dataarkitekt på IBM och lade fram detta i boken ”The Mytical Man-Month”. Hans bok är en av de få från den tiden som fortfarande är en av de viktigaste om utveckling av informationsteknik och verksamhet.)

Conways lag är allmänt accepterad inom systemutvecklingsvärlden. Den har använts och diskuteras på många platser under halvseklet sedan den publicerades. Jag upplever inte att regeln är ifrågasatt. Diskussionen handlar mera om vad den exakt innebär i olika sammanhang och hur vi kan använda oss av den. Ta del av ett diskussionsexempel av Martin Fowler via denna länk.

Men regeln har aldrig applicerats på något annat än enskilda systemutvecklingsprojekt och utvecklingsteam, vad jag vet. Mig veterligen har ingen använt regeln för hela it-landskap. Men enligt min erfarenhet från många år med att analysera och beskriva it-landskap gäller den på samma sätt även där. Ja, om något, är den snarare mer än mindre giltig inom detta område.

Nämligen på följande sätt (min formulering):

Varje fungerande verksamhet har ett it-landskap med en struktur som avbildar dess kommunikationsstruktur.

Det vill säga att varje it-applikation är en integrerad del av en viss verksamhetsförmåga, och varje integration mellan applikationer är en tjänst som en verksamhetsförmåga exponerar för en eller flera andra verksamhetsförmågor.

Men då måste vi först, för detta ändamål, definierar följande begrepp:

Verksamhetsförmåga:

Avgränsad autonom del av en verksamhet som realiserar en viss förmåga som verksamheten behöver ha (ej alltid strikt kopplat till den formella organisationsstrukturen).

It-applikation:

It-system, eller avgränsad del av ett sådant som är en integrerad del av en viss verksamhetsförmåga. För att rätt förstå vad en it-applikation är: Ett standarverktyg, exempelvis Microsoft Excel, är aldrig i sig en applikation, däremot kan implementationen av ett standardverktyg vara en applikation, exempelvis den Excel-applikation som producerar månadsrapporten.

Inte heller är en affärsystemplattform en applikation, men kan däremot vara basen för ett eller flera applikationer som Kundreskontra, Huvudbok, Kunddatabas med flera.

En integrationsplattform är inte heller en applikation. Däremot kan det på integrationsplattformen exekveras scriptkod som representerar verksamhetslogik i någon form och bör därmed betraktas som egna applikationer och ägas av lämpliga verksamhetsförmågor.

En it-applikation kan också vara ett kortregister, ett Excel-ark, ett script och så vidare

Tjänst:

En viss definierad nytta som en verksamhetsförmåga tillhandahåller en eller flera parter i omgivningen. Som det används här är begreppet inte begränsat till tjänster som tillhandahålls med en specifik teknik utan kan vara allt från filöverföring, programanrop med svar, att en applikation skriver i en annan applikations databas, prenumeration på händelser, med mera. Det kan också vara att någon person tillhandahåller något manuellt, eller att man har ett användargränssnitt som någon kan använda. Huvudsaken är att det sker regelbundet och återkommande och som en del av den operativa verksamhetslogiken.

Varför Conways lag inte är känd inom EA-världen

Conways lag har, så vitt jag vet, aldrig tidigare använts för arbetet med hela verksamhetslandskap och dess it-miljöer. Jag tror att en anledning har varit att lagen endast varit känd bland systemutvecklare. It-arkitekter bryr sig sällan om kopplingen till verksamhet.

Och verksamhetsarkitekter har historiskt och även fortfarande undvikt att befatta sig med allt som närmar sig informationsteknik. En viktig anledning är nog att vi aldrig har haft något sätt att rita upp verksamhetslandskapet förut. Vi fick förmågemodeller först för en femton år sedan och fortfarande ser man inte att de ritas med sina kommunikationsvägar.

Men det kan vi mycket enkelt börja göra! Det är det jag vill inspirera till med denna artikel, hur man med stöd av Conways lag, tillämpad på hela it-landskap, kan bygga upp en förmågekarta av den typ som denna artikelserie handlar om, som visar verksamhet och it i en och samma vy.

Hur du tar fram en integrationskarta

Här presenterar jag en speciell metod för att snabbt och effektivt ta fram en karta över en verksamhet. Jag och mina kollegor har tillämpat metoden i många olika verksamheter, och alltid med gott resultat. Att metoden fungerar är tack vare Conways lag.

Jag ska här beskriva hur den fungerar.

Vilka kunskapskällor har vi?

Att ta fram en förmågekarta är en slags forskning, om än inte akademisk. Det vill säga ett systematiskt arbete med att bringa kunskap. I detta fall kunskap om hur en verksamhet är uppbyggd. Det finns då två slag av kunskapskällor man kan tänka sig. Vi kan utgå från hur folk i organisationen ser på sin verksamhet. Eller så kan vi kartlägga it-landskapet och se vad det berättar om verksamheten.

Båda slagen av analys inbegriper intervjuer och workshops, men alternativet som utgår från it-landskapet betonar verkliga fakta som applikationer, datainnehåll och integrationer. Och det är alltid bra att förankra sin karta i fakta, även om vi behöver mer än bara rena fakta i längden.

Antropologi och arkeologi

Jag brukar – inte helt på skämt – likna dessa två angreppssätt vid historievetenskapens två slag av kunskapskällor; antropologi och arkeologi. Antropologer intervjuar ”infödingarna” och arkeologer gräver i ruinerna.

Antropologi ger oss folkets egen förståelse, med alla de svagheter det kan föra med sig. Det man får fram kan vara hörsägen av skiftande värde. Det är okej så länge man är kritisk och kollar upp mot egna observationer.

Arkeologi ger oss i stället fakta. Det är därmed handfast kunskap, men ger oss inte direkt det vi vill veta utan det måste tolkas.

När man grävde ut slagfältet vid Poltava hittade man stora mängder av föremål i Ukrainas svarta jord. Skelett och rester av uniformsknappar som härrör från Karl den tolftes karoliner och som tydligt visar exakt var på slagfältet de olika förbanden i den svenska hären mötte sina öden. Dock var det inte någon av dessa platser som utpekats i skildringarna av slaget. Historien fick skrivas om. Fakta ger oss en fast grund på ett sätt som inget annat kan ge.

På motsvarande sätt är det inom vårt område. Om vi vill ha en fast grund för vår förståelse av hur verksamheten fungerar bör vi utgå från vilka applikationer som finns, vad de gör, vem som använder dessa och hur de är integrerade. Därav kan vi härleda vilka förmågor som finns och hur de samverkar.

Conways lag ger enligt mig just detta; att vi kan härleda verksamhetens förmågor, tjänster och vilka vägar de samverkar ur it-landskapet.

I mina uppdrag, vad de än handlar om, börjar jag alltid med att göra en kartläggning av it och verksamhet, och hur de hänger ihop. Resultatet blir en integrationskarta, det vill säga en detaljerad och mycket konkret förmågekarta av det slag jag beskrivit i denna artikelserie. Den är i början mer skissartad med en del gissningar. Men allt eftersom arbetet fortskrider och fler personer blir inblandade får den en fastare form och blir mer detaljrik.

Metoden

Kartläggningen brukar gå tillväga på i grunden samma sätt. Det jag beskriver här är endast arbetet med att ta fram integrationskartan, inte det verkliga uppdraget som kan handla om allt från att bygga upp en Data Management-förmåga till att åtgärda specifika problem med data i organisationen.

Efter den vanliga allmänna orienteringen om verksamheten och uppdraget blir det dags att rita kartan. Detta för att få överblick och sammanhang. Jag går då till väga på följande sätt.

Steg 1: Hitta de som kan mest

Jag tar reda på vilka personer som kan mest om vilka applikationer det finns och hur de är integrerade. Ofta är det it-arkitekter, databasansvariga eller de som jobbar med systemförvaltning. Ofta skickar de fram chefer först, men de har sällan denna konkreta kunskap.

I nästan alla verksamheter finns det någon enstaka person som vet väldigt mycket, någon som kan nästan allt. Alla brukar veta vem det är, en go-to-person, värd sin vikt i guld. Det är denne de snart pekar på.

Steg 2: Skörda från it-kartor

Jag tar möte med denna person, eller dessa om de är fler, och vill ha reda på vilka applikationer det finns och hur de är integrerade. Ofta tar de med sig någon form av it-systemkarta. Den kan se ut på två sätt.

1. It-karta centrerad på ett system
   Om de har ansvar för ett specifikt system, till exempel ett ERP-system som har en central roll, har de placerat detta system i mitten på kartan och ett stort antal andra system i en cirkel runt detta. Varje system har pilar till och från ERP-systemet som visar integrationerna. Om det är en stor verksamhet kan de ha ett sådant schema för varje större system.

2. It-karta centrerad på en integrationsplattform
   Om man har en eller flera integrationsplattform brukar man placera dessa centralt på kartan och de olika it-systemen i förhållande till dessa, ofta i olika skikt.

Ofta finns det även med några externa integrationer.

Dessa kartor är alltså rent tekniska. De visar inte applikationer i sig utan it-system, och de visar inte heller var dessa system hör hemma i verksamheten. Men ändå är en sådan systemkarta i högsta grad användbar som kunskapskälla för mig. Ibland finns det inte någon karta alls, men då brukar några personer ha detta i huvudet och kan rita upp det på en whiteboard.

Vi går så tillsammans igenom system för system och vad pilarna mellan dessa står för. Jag frågar vad det är för system, och va det gör och för vem. Ofta står det bara en akronym eller så har man benämnt systemet efter vilket standardsystem det är baserat på. Varje pil är en integration. Jag får reda på vilka data som överförs och vem som har nytta av den och på vilket sätt.

Steg 3: Rita förmågekarta

Sedan sätter jag mig själv med MS Visio eller liknade och ritar upp ett första försök till en förmågekarta, utifrån det jag fått reda på. Jag kan från deras beskrivning identifiera it-applikationer och ge dem beskrivande namn och beskrivning. De namn de gett mig får vara kvar som synonymer. Jag kan, utifrån vilka applikationer det finns, deducera vilka verksamhetsförmågor det måste finnas. Allt enligt Conways lag. Finns det en applikation så finns det en verksamhetsförmåga som applikationen är en del av. Jag försöker att placera ut verksamhetsförmågorna efter någon princip om skiktning och riktning för beroenden. Oftast de kundnära (front office, kundtjänst mm) högst upp, de mest centrala i mitten (back office eller business backbone) och stödförmågor längst ner.

Integrationerna ritar jag som att en förmåga producerar en tjänst (”godisklubba”) och att en eller flera parter/förmågor använder den tjänsten som ett streck från konsumenten till tjänsten. Jag skriver vad tjänsten heter (om den har ett namn) samt skriver vilken typ av information som överförs, och markerar riktningen på informationsöverföringen med en fylld pilspets. Detta följer också Conways lag; om det finns en integration av något slag mellan it-applikationer så är det också på samma gång en integration mellan förmågor.

Steg 4: Få återkoppling

När jag ritat upp min karta, så som jag på detta stadium har förstått verksamhets- och systemladskapet, tar jag ett möte med samma personer och ser om jag förstått rätt. Sedan får jag vanligen justera i ett par vändor.

Steg 5: Bredda undersökningen

Vanligen blir det sedan aktuellt att blanda in än fler personer, både från it- och från verksamhetssidan. Det är personer som har sina speciella områden de är insatta i. Vilka de är har jag fått höra under arbetets gång. På så sätt växer kartan fram, både justeras och byggs på. Jag är noga med att få med inte bara rent tekniska integrationer och applikationer utan även rutinmässiga manuella datauttag, analyser och rapporter.

Resultatet

Nu har vi en karta som visar vår gemensamma förståelse, tvärs över verksamhet och it. Med it som en integrerad del av verksamheten. Ofta blir det flera mindre justeringar allt eftersom, men kartan blir snart mycket stabil. Som förmågekarta blir den baserad på fakta, det vill säga vilka applikationer och integrationer som verkligen finns och hur de används, och därmed vilka förmågor det per definition måste finnas.

Ett exempel på integrationskarta

Det är förvånande hur lätt och snabbt, mer eller mindre mekaniskt, det går att ta fram en sådan karta. Och vilken stor nytta den ger i allt arbete där man behöver analysera, förstå, förmedla, hantera och utveckla verksamheten. Det som krävs är dock en stor omtanke om hur man placerar ut förmågorna i förhållande till varandra. Mer om detta i nästa artikel.

Första gången vi tog fram en sådan karta var för femton år sedan i en större internationell organisation. De hade kartlagt något hundratal it-system som alla fanns med i deras integrationer. Den kartläggningen hade tagit två år, men de hade sedan inte lyckats rita upp det på något sätt som inte såg ut som en höstack. Vi kom då på idén att ta fram en förmågekarta och rita ut it-systemen på denna. Det vill säga på det sätt som beskrivits i denna artikelserie. Resultatet blev en överraskning. Verksamhetsfolk började ta med sig kartan på olika möten, där de behövde diskutera verksamhetens utveckling. De upplevde att de för första gången såg hur deras verksamhet hängde ihop.

Det var den händelsen som gjorde att vi började utveckla och lära ut hur man tar fram denna typ av kartor och hur de kan se ut.

Användning

Denna typ av kartor är värdefulla för i stort sett all typ av arkitektur- och utvecklingsarbete. Men eftersom denna artikelserie handlar om informationsarkitektur vill jag särskilt peka på användningen inom detta område. Dock ber jag då att få referera till min tidigare artikel: Förmågekartor för informationsarkitektur – del 8: Hur man kan använda en integrationskarta

Nästa artikel

I nästa artikel går jag igenom hur vi i kartan kan fånga och avbilda verksamhetens övergripande struktur, det vill säga hur verksamhetens olika förmågor förhåller sig till varandra och till helheten.
Det handlar om ett litet antal grundläggande mönster.

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