Försvar för enkla verktyg – del 4: Modellbibliotek

I en större verksamhet kan vi ha hundratals modeller. Vi behöver hålla reda på, klassificera, lagra och hantera våra modelldokument. Vi behöver ett modellbibliotek. För detta finns det verktyg, så kallade ”Model Repositories”. Ofta är de integrerade i de specialiserade modelleringsverktygen. Men jag menar att man bygger ett bättre modellbibliotek själv med en enkel mappstruktur med vilken vanlig fillagring som helst, i molnet eller som katalogstruktur på en filserver. Det som är viktigt är att bygga en bra struktur och arbetsprocess och att vårda och utveckla den. Det fixar inget verktyg i världen åt oss. 

/Peter Tallungs, IRM, 2021-05-06

Mappstruktur för ett modellbibliotek

I bilden ovan visar jag ett exempel på en mappstruktur som jag har använt i många sammanhang. Varje modell har en övergripande mapp med samma namn som modellen. I exemplet ovan heter modellen ”Business Information Model”. Under denna finns tre mappar som återkommer för varje modell:

• General Material
  En mapp för material som inte är en del av modellen men som är lämpliga att spara tillsammans med denna, till exempel olika typer av material som man utgått från när man modellerat.
• Overview
  En mapp för en översikt över hela modellen. Där har man till exempel ett översiktsdiagram.
• Subject Areas. En mapp med en undermapp för varje ämnesområde som modellen är indelad i. I exemplet ovan ser vi mapparna för ämnesområdena ”Customer” och ”Products”.

Modellen i detta exempel beskriver en hel verksamhet och är uppdelad i ett trettiototal ämnesområden. Varje ämnesområde har en egen mapp som samlar de modelldokument som beskriver ämnesområdet. Modelldokumenten för ett ämnesområde är alltid ett textdokument samt oftast en Visio-fil med detaljdiagrammet för området. Dokumenten är namngivna med modellens namn, ämnesområdets namn samt versionsdatum.

Sedan finns det för varje ämnesområde en arkivmapp, ”Archived”, för att arkivera äldre versioner av modelldokumenten.

På detta sätt har vi en lagringsstruktur som håller ordning på en modell som bärs av många olika dokument för sina olika delar, både text- och diagram.

En sån här struktur behövs inte i början av ett modelleringsarbete, när modellen inte riktigt har funnit sin form ännu. Då jobbar man kanske med ett enda stort diagram utan textbeskrivningar. Det är först när modellen och ämnesområdena någorlunda har funnit sin form som man behöver en fastare struktur.

För mindre omfattande modeller behöver man kanske inte mer än ett textdokument och ett diagram. Men i övrigt fungerar lagringsstrukturen för alla situationer. Jag har aldrig upplevt att den här strukturen inte räckt till.

Versionshantering

Vi behöver hantera versioner av dokument. Eftersom det vanligaste är att en ändring håller sig inom ett eller ett fåtal ämnesområden är det lämpligt att låta varje ämnesområde ha sin egen livscykel och historik.

Versionshanteringen går i ett sådant här modellbibliotek till på följande sätt:

1. När du vill ändra något i ett ämnesområde öppnar du de aktuella versionerna av modelldokumenten för ämnesområdet. Ofta behöver du ändra i både textdokumentet och diagrammet samtidigt, så du behöver öppna båda.

2. Du spar dessa direkt som nya versioner med samma namn men nytt versionsdatum.

3. Gör de ändringar du vill göra. Efter varje enskild ändring loggar du den i ändringshistoriken för ämnesområdet, som finns först i textdokumentet. Ofta gör jag flera ändringar i rad. För att noggrant komma ihåg att logga varje ändring gör jag det direkt efter varje ändring. Det underlättas av att jag kan dela fönstret i Word så jag ser de två avsnitten samtidigt; ändringshistoriken i den övre delen och själva texten där jag ändrar i den nedre. Det är ofta lämpligt att inte bara skriva när och av vem ändringen gjordes, utan också varför.

4. Spara och stäng det som nu har blivit de nya dokumentversionerna.

5. Till sist flyttar du de tidigare dokumentversionerna till arkivkatalogen för ämnesområdet.

Om ändringen påverkar andra ämnesområden, eller själva översikten gör du på liknande sätt med dessa.

Publicering av den uppdaterade modellen, att göra den tillgänglig för en publik, är en egen historia som jag skriver om i nästa artikel i serien om enkla verktyg. Det är lämpligt att skilja själva publiceringen från den bakomliggande modellhanteringen. Publicering är ett eget beslut. Det är inte självklart att varje ändring ska publiceras direkt.

Fördelarna med enkla verktyg

Vad är då vitsen med detta minimalistiska verktyg gentemot speciella repository- och versionshanteringsverktyg. Jag ser följande fördelar:

1. Verktygsoberoende
Vi gör oss inte beroende av speciella verktyg och standarder, ofta proprietära, vilket gör att vi inte blir inlåsta och sårbara. Vi kan fritt välja lagringsform och också över tid byta lagringsform.

De specialiserade verktygen för dokumentlagring och versionshantering av modeller kommer och går. Våra modeller, speciellt informationsmodeller, men även förmågekartor är, om de är bra gjorda, stabila över tid och ger ett bestående värde för en verksamhet. Vi behöver därmed en större stabilitet och hållbarhet över tid för vårt bibliotek. Därför bör vi undvika inlåsning där vi kan så göra. Verktygsoberoendet ger oss den öppenhet, flyttbarhet och flexibilitet vi behöver för att arbeta på ett hållbart sätt med ett långsiktigt värde för vår verksamhet.

2. Makt över våra verktyg
Det här är kanske mer en mental och sociologisk aspekt men nog så viktig. Ett specialiserat verktyg är mycket mindre fritt än ett enklare och mer generellt verktyg. När vi arbeta med ett specialiserat verktyg betingas vi att göra på det sätt som verktyget tillåter eller styr oss att göra. Vi tenderar att sluta tänka själva. Verktyget befrämjar vissa strukturer och arbetssätt och det blir lätt så att det är just på det sättet vi gör, och inget annat. Vi tänker då inte aktivt ut vad som egentligen fungerar bäst för det vi behöver göra.

Vi bör alltid välja och använda verktyg som stödjer det vi behöver och vill göra, aldrig tvärtom.
För då blir vi mer som operatörer av ett visst verktyg än de utforskare och kaospiloter vi ska vara.

Det är viktigt att vi – det vill säga både vi som profession, vi som team, och vi som individer – självständigt och utifrån vår profession, erfarenheter och sammanhang utforskar, lär oss och utvecklar arbetssätt och strukturer som stödjer dessa arbetssätt. Det är så utveckling inom en profession går till.

Du kanske inte tror att det händer just dig, att det inte är någon risk att du blir styrd av verktygen du använder? Men vi ser det hända hela tiden i de verksamheter vi jobbar i. Våra verktyg styr oss mycket mer än vi är benägna att se. Enkla verktyg är friare och blockerar oss inte på samma sätt.

3. Versionshistorik integrerad i modellen
Ett ämnesområde i en modell har en historia. Det är inte bara ett färdigt resultat. Historien bör vara en integrerad del av modellen om den verkligen ska kunna vara en plattform för gemensamt utforskande av en verksamhet.

En modell bör på sätt och vis vara lika mycket en avbildning av en pågående process som ett färdigt resultat. Modellen ska visa mer än bara ett snapshot av det färdiga resultatet. Jag vill också kunna se hur man kom dit och varför. Inte minst vill jag se vilka vägar man prövat och förkastat. Det rymmer mycket kunskap som har fångats och som vi bör ta vara på. Det är inte ovanligt att man behöver ompröva val som gjorts längre tillbaka.

Vi behöver därmed beskriva vilka ändringar som gjorts, när, av vem och ofta även varför. Detta är en viktig dokumentation av ämnesområdet och bör därför vara en integrerad del av modelldokumentet och bäras med i dokumentet var det än tar vägen. Det blir inte fallet med ett särskilt versionshanteringssystem. Därför behövs ändringshistoriken listas i själva textdokumentet.

4. Rätt detaljeringsgrad för versionshanteringen
Ett mer automatiserat versionshanteringssystem kan inte skilja på ändring och ändring. Det skapar en ny version så snart någon ändring är gjord oberoende av om det är en ändring jag behöver hålla reda på eller inte. Den finkornigheten är lämplig för till exempel programkod eller avtalstexter där varje ändring, om det så är ett flyttat komma eller stavningsrättning kan ha betydelse.

Men inte när det gäller dokument av den typen vi pratar om här. Enstaka rättningar av stavning eller formuleringar bör inte rendera i en ny version. I så fall drunknar vi i versioner. Vi behöver bara hålla reda på väsentliga ändringar. På så sätt får vi en historik som avspeglar ämnesområdets historik på en mer lämplig nivå.

Jag är säker på att det här är ett område med många åsikter. Hur ordnar ni ert modellbibliotek och er ändringshantering? Kanske du också har tips att förmedla?

/Peter Tallungs, IRM