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.

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

Nästa del i miniserien om informationsmodellerarens verktyg publicerar vi torsdag 20 maj. Då handlar det om samarbetsverktyg.
Vill du prenumerera på artikelserien Informationsarkitektens tankar? Registrera din mailadress här.


2 Kommentarer
  1. Marcus
    Marcus says:

    Har precis försökt skapa en sådan filstruktur för min organisations arkitekturdokumentation :). Tanken är ganska lik. Till att börja med inne på förmågor som vi är i uppstarten med att kartlägga. Märker att jag inte tänkt tillräckligt mycket kring versionshantering så får ta ett varv till kring det. Tänker mig att försöka samla både arkitekturella beskrivningar, metoddokumentation, mallar mm i samma struktur. Inte huller om buller så klart men ordnade utefter verksamhetens förmågor som första sortering. Så som indelningen fungerat hittills (efter organisation eller person…) gör det väldigt svårt att hitta och ännu svårare att förstå sammanhanget som dokumenten ska förstås i. Vilket gör att precis allt måste förklaras av den som upprättat materialet…Hoppas få till något som förklarar sig lite mer på egen hand med hierarkiskt uppbyggd struktur, från helhet ner till detalj. Får se hur det lyckas. Framförallt hur jag får övriga att hänga på :). Intressant att ta del av dina tankar i frågan hur som helst.

  2. Peter Tallungs
    Peter Tallungs says:

    Svar till Marcus:
    Så roligt att höra om ditt arbete!

    Verksamhetens förmågor är enligt mig den bästa första grunden för att dela in verksamhetens arkitektur, och därmed även sitt bibliotek av modeller och annan dokumentation. Förutsatt att man med verksamhetsförmåga menar avgränsad ”funktion” i verksamheten (”en verksamhet i verksamheten”). Termen förmåga kan ju förvillande nog även användas i andra betydelser.

    Fast det jag beskriver är en annan indelning, och jag ska försöka beskriva skillnaden här. Jag skriver ju nu specifikt om informationsmodeller och då blir det lite annorlunda, en mer fingraderad indelning. En viss informationsmodell har ju en kontext och den är alltid en förmåga av något slag. Den förmågan kan vara en hel verksamhet (Det är ju också en förmåga. Det finns ju förmågor i förmågor. Världen är fraktal!). Eller det kan vara något mindre, en viss verksamhetsförmåga, vare sig det är en utåtriktad förmåga eller en stödförmåga, t.ex. inköp, orderhantering, personalhantering, betalningshantering, ärendehantering, tidrapportering.

    Så en informationsmodell gäller alltid för en viss kontext, som i grunden är en verksamhetsförmåga. Den beskriver vad som hanteras i den förmågan, eller för en viss aspekt av en förmåga. Om den modellen blir omfattande behöver den delas ner i hanterbara delar. Det kallar jag för ämnesområden. Det är inte samma som verksamhetsförmågor även om de ibland kan sammanfalla.

    Oavsett denna skillnad i omfattning så gör du samma som jag.

    Jag berättar gärna hur den versionshantering jag beskrivit i artikeln fungerar i sina mer praktiska aspekter, och hur den versionshanteringen kan få modeller till att avspegla inte bara ett färdigt resultat utan en fortgående process. Det är en förutsättning för att kunna lyfta arkitekturarbetet att bli ett gemensamt lärande och forskande i stället för att i arkitekter bara påstår hur saker är. Kontakta mig i så fall så kan jag visa.

Lämna en kommentar

Want to join the discussion?
Dela med dig av dina synpunkter!

Lämna ett svar

Din e-postadress kommer inte publiceras. Obligatoriska fält är märkta *