Inlägg

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.


Försvar för enkla verktyg – del 2: Ritverktyg

Jag ritar modeller i Microsoft Visio och kombinerar med strukturerad text i Microsoft Word. I denna artikel vill jag motivera varför jag föredrar ett enkelt och flexibelt ritverktyg som Visio.

Det finns ett antal specialiserade modelleringsverktyg. De är tänkta att integrera grafiska och verbala beskrivningar på ett strukturerat sätt. En annan väg att gå är att använda sig av ett rent ritverktyg som till exempel Microsoft Visio och knyta ihop helheten med enklare och mer flexibla medel.

Visio ger de uttrycksmöjligheter vi behöver

För att göra kommunikativa modeller som blir effektiva tanke-, kommunikations- och samarbetsverktyg behöver vi utveckla den grafiska gestaltningen. Det är viktigt för att vi ska bli riktigt bra modellerare. Det är också viktigt för oss informationsarkitekter som profession för att vi ska utveckla vårt hantverk, vilket jag anser att vi behöver göra. Här följer några av de uttrycksmedel vi behöver använda när vi ritar modeller.

  • Struktur på ytan i diagram. Gråa bakgrundsytor för ämnesområden ger struktur.
  • Layout;hur vi placerar och grupperar ämnesområden, entiteter och relationer.Vi kan framhävavilka företeelser som är delar av andra företeelser. Vad hör ihop? Vilka saker är parallella med varandra i förhållande till något tredje? Vad är underställt något annat? Vad bildar en linje? Vilka mönster behöver jag framhäva i strukturen?
  • Rubriker på hela diagrammet, ämnesområden samt grupper av ämnesområden och grupper av entiteter. Vi behöver alltså rubriker i flera nivåer.
  • Storlek och form på de grafiska elementen de att framhäva vissa företeelser.
  • Ordning; vi bör se till att de olika grafiska elementen linjerar prydligt. Om grafiska former inte linjerar söker hjärnan hitta mönster som inte finns. Modellen upplevs som rörig vilket bromsar vår kognition.
  • Speciella färger för att framhäva, skilja, förklara.
  • Gråskalor för att tona ner sakerså att de hamnar i bakgrunden av vår perception. Det gäller både entiteter, namn och andra texter samt linjer, rubriker och ämnesområden. På så sätt framhäver vi det vi vill framhäva och tonar ner det som vi vill tona ner.
  • Linjetyper; heldragna, streckade eller punktade linjer för saker som vi vill skilja på.
  • Linjetjocklekar lyfter på likande sätt, som med gråskalor, fram vissa linjer och tonar ner andra
  • Typsnitt, textstorlekar och typografiska stilar som fetstil och kursivstil för att skilja på olika slags namn och texter
  • Integrerad text; förklarande text i och intill diagram så mycket som det går.

Det ovanstående är bara en enkel uppräkning, men jag planerar att ge råd om detta i artiklar framöver. Syftet är att vi ska kunna gestalta våra modeller så att de rymmer mer av den kunskap vi vill analysera, forma, dokumentera och förmedla, samtidigt som modellerna blir mer lättillgängliga.

Detta bygger på att vi kan styra fritt över det grafiska uttrycket, att vi har fri tillgången till alla de uttrycksmedel vi behöver. Vilket kräver ritverktyg som inte begränsar uttrycksmedlen.

En informationsmodell är inte ett diagram

Om vi ska få till den uttryckskraft vi behöver i våra modeller måste vi lämna föreställningen att en informationsmodell bara är ett diagram. En modell behöver oftast gestaltas av flera diagram och av diagram av olika typer samt också av strukturerad text. Det som gör det till en och samma modell är att den har en gemensam kontext, det vill säga beskriver samma sak i samma sammanhang, samt att den är konsistent, det vill säga inte självmotsägande. 

Den vanliga invändningen mot enkla ritverktyg

Den vanliga invändningen mot att använda ett enkelt ritverktyg för att modellera uttrycks av följande citat som jag ofta hört:

”Jag förstår att vi behöver göra kommunikativa presentationer av våra modeller för att nå ut till de som behöver ta del av dem. De modeller vårt modelleringsverktyg låter oss göra är inte lämpliga att presentera för vem som helst. Men vi kan ta fram presentationsmaterial separat från vårt modelleringsverktyg, till exempel i Powerpoint eller liknande presentationsverktyg”.

Min respons blir då följande: Om du tillstår att modelleringsverktyget inte ger de möjligheter du behöver för att göra klara, tydliga och begripliga modeller så kommer den bristen att slå brutalt och obarmhärtigt även mot dig och dina kolleger som arbetar i verktyget. Vi behöver kunna gestalta modeller så tydligt som möjligt, inte bara i efterhand för en publik utan också för oss själva när vi modellerar. Modellering handlar inte om att rita det vi redan begriper utan om att rita för att undersöka och förstå, hitta mönster och förmedla dessa. Kan du inte göra det i ditt verktyg så har du fel verktyg.

En känslig fråga

Jag förstår att det här är ett minerat område. Det kan kännas tryggt att luta sig mot ett specialiserat modelleringsverktyg. Det är svårt att stå emot de krafter som har en övertro på en standardisering och egentligen inte har förstått vad modellering handlar om, att med alla medel skapa en gemensam förståelse. Och det är svårt att bryta en vana.

Det kan kännas bekvämt att bara se sig som en operatör av ett verktyg i stället för att tänka fritt och göra det bästa som bara går. Då känns det inte riktigt som att man behöver ta det fulla ansvaret för resultatet. Man bara gör som metoden föreskriver och som alla andra gör. Det är en förödande fälla. Vi är då inga ansvarsfulla hantverkare. Då ger vi inte det vi kan ge, och vi får inte någon metodutveckling på vårt område. Då ger vi upp ambitionen att ge allt det vi skulle kunna ge, som individer, som team, som yrkesgrupp och som kunskapsområde.

Vad säger du? Vilket verktyg använder du? Hur väl lämpar sig verktyget till att uttrycka det du behöver uttrycka?
Kommentera gärna! Jag ser fram mot en dialog.   

/Peter Tallungs, IRM

Nästa del i miniserien om informationsmodellerarens verktyg publicerar vi torsdag 29 april. Då handlar det om verktyg för skriva strukturerad text.  Vill du prenumerera på artikelserien Informationsarkitektens tankar? Registrera din mailadress här.