Vilken notation är bäst?

För informationsmodeller finns det många olika notationer. Nu ger jag min syn på det alla har en åsikt om: Vilken är bäst?

Jag talar här om det sätt att modellera som nästan är synonymt med begreppet informationsmodellering: Entity Relationship Diagrams, som förkortas ERD eller ER Diagrams. Det vill säga boxar som står för entiteter (klasser av företeelser) med streck för de relationer som kan finnas mellan dessa. För detta finns det en uppsjö av notationer att välja mellan, det vill säja sätt att rita sina boxar och relationer.

Först behöver jag gå igenom vilka vanliga ERD-notationer det finns. Jag berör vilka traditioner de är sprungna ur och därmed vilka grundläggande synsätt de bygger på. 

ER-modelleringens historia

Den första ERD-notationen togs fram av Peter Chen 1976. Ändamålet var att designa databaser. Relationsdatabaser var då något nytt. Edgar ”Ted”, F Codd hade föreslagit relationsmodellen 1970 då han var anställd på IBM. Codds idé om hur design av en relationsdatabas skulle gå till var att man skulle strukturera en från början ostrukturerad datamängd genom att steg för steg mekaniskt applicera ett antal så kallade normaliseringsregler. Peter Chens idé var att i stället modellera fram en struktur för sina data.

Under de följande decennierna utvecklades det ett antal varianter på Chens ursprungliga notation. Det är dessa varianter jag nu diskuterar.

Viktigt i sammanhanget är att vi sedan många decennier tillbaka använder ER-diagram till många andra syften än att designa relationsdatabaser. Det har blivit ett oerhört kraftfullt och effektivt verktyg för att analysera beskriva vilken data- eller informationsmängd som helst samt även företeelser och begrepp inom ett område.

ERD-notationer

Vi kan inte diskutera alla exotiska varianter av notationer utan får göra ett urval av de vanligaste. De man kan stöta på idag är främst följande:

  • IDEF1X som har sitt ursprung i amerikanska flygvapnet
  • Bachman
  • Barker, vanlig bland Oracle-folk
  • James Martin Information Engineering (JMIE), också kallad Information Engineering eller Crow’s Foot Notation, framtagen av den brittiske IBM-konsulten James Martin
  • Express, för produktdata
  • UML klassdiagram som vanligen inte räknas som en ERD-notation trots att den har samma ursprung och kan användas för samma ändamål. Modelleringsspråket UML (Unified Modeling Language) som innehåller notationer även för andra modelltyper än data- och informationsmodeller har en egen historia och tradition från metoder för design av objektorienterad programkod i mitten av 90-talet.

Aspekter att jämföra

Vi kan jämföra dessa notationer ur olika aspekter som vi bedömer som viktiga. Jag har valt följande aspekter:

  • Förekomst
    Hur vanlig är notationen? I Sverige? I världen? I olika specifika sammanhang?
  • Uttryckskraft
    Hur bra går det att uttrycka det vi behöver med hjälp av notationen?
  • Tydlighet
    Hur tydligt blir det att läsa och förstå notationen, (för en relativt ovan respektive van person).
  • Ändamålsenlighet
    Hur bra passar notationen för informationsmodellering?
  • Verktygsstöd
    I vilken mån har de vanliga rit- och modelleringsverktygen inbyggt stöd för notationen?
  • Kunskap
    Hur vanlig är notationen i facklitteratur, utbildningar och annat material?
  • Kultur
    I vilket sammanhang har notationen sitt ursprung. Det påverkar vilka underliggande synsätt notationen baseras på, vilket kan göra den mer eller mindre lämplig för olika ändamål.

Jag kommer nu att gå igenom aspekt för aspekt, i sju ronder.

Jämförelse 1: Förekomst

Det är förstås viktigt hur vanlig den notation man väljer är, både allmänt i världen och i Sverige samt inom det speciella område man är verksam.

Bland de traditionella ERD-notationerna, det vill säga alla utom UML klassdiagram, sägs JMIE (Kråkfotsnotation) vara överlägset vanligast, både i världen och i Sverige. Och det stämmer nog. Jag har många böcker om informationsmodellering, både nyare och äldre, och kan nästan inte påminna mig om att jag sett någon annan notation. Alla de övriga verkar vara på utdöende eller återfinns endast i speciella sammanhang. Som Barker bland Oracle-folk och Express för produktmodellering. Dock kan även JMIE i sig själv förekomma i lite olika varianter med mindre avvikelser från varandra.

UML är en familj av notationer för modellering av programkod. UML kom 1996 och användes först endast för programvarudesign inom den objektorienterade paradigmen. Senare har några börjat använda UMLs olika notationer även för verksamhetsmodellering, och bland dessa klassdiagram, både för verksamhets- och databasmodellering.

Så idag finns det i stort sett bara två olika läger vad beträffar notation.

  • JMIE som har sitt starka fäste i databasdesign, liksom i de yrkesgrupper som historiskt kommer därifrån, som enterprise-, verksamhets- och informationsarkitekter, Business Intelligence-folk med flera.
  • UML klassdiagram som fortfarande har sin spridning främst bland programmerare och då främst för modellering av programkod.

För informationsmodellering är alltså JMIE vanligast, även om UML klassdiagram också förekommer.

Resultat: JMIE vinner i den här kategorin, fast med UML klassdiagram som god tvåa.

Eftersom aspekten ”Förekomst” är så viktig så kan vi redan här räkna bort alla andra notationer än JMIE och UML klassdiagram. Det är ingen idé att beakta en notation som inte används i praktiken, så till vida den inte har alldeles extraordinära kvaliteter i övrigt som motiverar att den blir kvar. Vilket jag bedömer att de inte har. Av startfältets sex tävlande återstår alltså redan nu bara två.

Jämförelse 2: Uttryckskraft

Det är viktigt att den notation jag väljer kan uttrycka det jag behöver uttrycka.

Jag anser att JMIE och UML klassdiagram har mer eller mindre samma uttryckskraft. Liksom de flesta andra notationer som vi redan har räknat bort. Skillnaderna är små, så det ska egentligen inte påverka valet. Men jag tycker att UML klassdiagram har två uttrycksmedel som jag tycker är värdefulla och som vanligen saknas i de traditionella ER-notationerna.

1.  ”Composition”, en fylld romb i änden på relationslinjen som markerar att en entitet är en integrerad del av en annan och inte kan existera självständigt. Som att en fakturarad hör till en faktura och att fakturaraden inte kan existera självständigt, oberoende av fakturan.

2.  Möjligheten att rita en specialiserad entitet (en subtyp) skild från den generella (supertypen), alltså det som man kan kalla en ”is-a”-relation eller ”arv” inom programmering, med en linje mellan entiteterna markerad med en ofylld triangelformad pilspets i änden. Det är värdefullt då man behöver utveckla flera olika specialiserade entiteter i olika ämnesområden. Det vanligaste i ERD-notationer är annars att en eller flera specialiserade entiteter ritas inuti den generella entiteten.

Observera att jämförelsen här endast handlar om uttryckskraften hos notationen vad gäller just informationsmodellering. UML klassdiagram är ju i grunden avsett för design av programkod och har därför möjlighet att uttrycka beteende hos klasser i form av metoder vilket det inte finns behov av hos en informationsmodell.

Resultat: Ett plus till UML klassdiagram.

Jämförelse 3: Tydlighet

En notation behöver vara så tydlig som det bara går för att vi ska kunna göra modelldiagram som kommunicerar effektivt.

Här finns det ofta starka åsikter som dra åt olika håll. Traditionella informationsmodellerare tycker att UML är obegripligt och UML-konnässörer tycker att traditionella ERD-notationer är passé. Men min uppfattning är att det handlar mer om det som kallas ”confirmation bias” än verklig skillnad, att man gärna vill tro att det man är van med är lättast att begripa. Jag tycker att det är hugget som stucket mellan JMIE och UML klassdiagram.

Det som skiljer är främst hur man betecknar kardinalitet (multiplicitet) i relationerna. Det vill säga vilka symboler man har i ändarna av relationsstrecken. UMLs min- och maxvärden i form av siffror är möjligen enklare att direkt förstå för den oinvigde. Fast JMIEs tvärstreck och gafflar är grafiskt tydligare så snart man fått dem förklarade för sig.

För övrigt har tydlighet hos våra modeller mer att göra med hur vi använder disposition, struktur, namngivning, texter, gråskalor, färger och så vidare, vilket har mer att göra med vår kunskap om grafisk gestaltning än om vilken notation vi använder.

Resultat: Jämnt skägg alltså.  

Jämförelse 4: Ändamålsenlighet

Jag tror att många skulle anta att UML är bäst för programvarudesign och de traditionella ER-notationerna bäst för informationsmodellering. Man kan anta att eftersom olika notationer ursprungligen är framtagna för olika ändamål så kan de vara bättre eller sämre lämpade för det jag behöver gestalta. Men skillnaden i hur väl lämpade JMIE och UML klassdiagram är för informationsmodellering är, om den ens finns, så liten så att jag bedömer den som betydelselös.

Det är dock sant att ERD-diagram inte täcker det som behövs för programvarudesign. Det som saknas är framförallt möjligheten till att beskriva vilka metoder en viss klass har. Men däremot passar UML klassdiagram alldeles utmärkt för informationsmodellering. Men eftersom det är för ändamålet informationsmodellering jag gör denna jämförelse så blir det inge tydligt utfall åt ettdera hållet.

Resultat: Därmed är det oavgjort även här.

Jämförelse 5: Verktygsstöd

Det är så klart viktigt att mitt verktyg kan användas för den notation jag har valt.

Både JMIE och UML klassdiagram tillhör de vanliga notationerna och har därmed lika bra stöd i alla vanliga verktyg.

Resultat: Återigen oavgjort.

Jämförelse 6: Kunskap

Jag behöver kunna hitta utbildningsmaterial för den notation jag väljer. Jag tror att det är ungefär lika lätt att hitta utbildningsmaterial och läroböcker om JMIE som inom UML.

Resultat: Oavgjort.

Jämförelse 7: Kultur

En viss notation lever inte i ett vakuum utan är inbäddad i en kultur inom ett visst område. Kulturen för med sig vissa föreställningar, som man visserligen kan förhålla sig till men som ändå påverkar kunskapsområdet på många sätt.

Det är här vi har den enda större och riktigt intressanta skillnaden mellan de traditionella ERD-notationerna och UML. Fast den slår åt båda håll! ERD-notationer har en äldre historia och har därmed använts i ett halvsekel för modellering tvärs över hela verksamheter. Det var vitrockarnas värld bland stordatorerna i datorhallen. Därför finns det gott om erfarenhet och modelleringsmönster att ta del av. Dock är det en kultur som i mina ögon stelnade någon gång på 90-talet.

UML uppstod först under andra halvan av 90-talet, i den objektorienterade programmerarkulturen. Det vill säga mikrodatorvärlden. Länge tog man fram endast enstaka specialiserade applikationer som var relativt fristående. Man hade inget samröre med stordatorfolket. Därför finns det inte alls samma erfarenhet i den kulturen av verksamhetsövergripande information. Däremot finns det en hel del friskt nytänkande som saknas i den gamla världen. Framförallt vill jag framhålla idén om domändriven design (Domain Driven Design) av Eric Evans som är något av det bästa som tänkts och skrivits på vårt område.

Men du behöver inte begränsa dig till böcker och erfarenheter från ERD-samhället bara för att du använder ERD-notation. Om man vill utveckla sitt kunnande är det viktigt att söka kunskap och inspiration bredare. Och är du UML-anhängare bör du ta del av den rika erfarenhet som generationer av kollegor har gjort. De problem du stöter på har sannolikt många hanterat före dig.

Resultat: Oavgjort. Fast vi bör förstå att både den traditionella ERD-kulturen och UML-kulturen har både styrkor och svagheter av betydelse. Det betyder att du som informationsarkitekt inte kan välja. Du behöver ta del av båda kulturerna.

Konklusion

Om du håller med om ovanstående så finns det bara två alternativ, och det är JMIEsamt UML klassdiagram. Och det är inte så tydligt vem av dessa som är vinnaren.

Jag har växlat fram och tillbaka genom åren. Vanligen, när jag kan välja, använder jag JMIE, av skälet att det är vanligast bland informationsarkitekter. Fast när jag behöver något element från UML klassdiagram, som jag nämnt ovan att jag saknar, så lånar jag helt sonika in dem. Så om jag skulle känna behov av att vara lite mer konsekvent skulle jag kanske gå över till UML klassdiagram. Fast jag är inte så stor anhängare av konsekvens. Det är viktigare att vi söker fritt och lånar friskt för att utveckla vårt område.

Vi som arbetar med detta måste förstås vara väl förtrogna med både ERD-notation och UML klassdiagram. Framförallt behöver vi kunna ta del av den kunskap som finns inom båda områdena. Sorgligt nog finns det en kulturell gräns som verkar svår att överstiga. Få informationsarkitekter tar del av saker från programmerarvärlden. Och tvärtom. Få programmerare från UML-världen känner ens till det som har tänkts och gjorts innan de kom in på banan. Det är så synd.

Mitt råd till dig som kollega är att vara mer öppen för ”den andra sidan”.

Exotiska svenskar

Om du varit med ett tag i branschen i Sverige vet du att det finns ett par rent svenska varianter på notationer. Jag vill bara kort nämna dem här. Stanli var ett standardiseringsorgan för geografisk information som drevs av Svenska Standardiseringsinstitutet. De tog fram en standard för begreppsmodellering – Stanli-notation – som i praktiken var en ERD-notation, fast relationer var begreppsmässiga i stället för informationsmässiga.

På åttiotalet fanns det ett samarbete mellan svenska myndigheter som tog fram en standard för systemutveckling. Jag tror att det bland andra var Kommundata som var drivande. Det resulterade bland annat i en variant av ERD-notation som i grunden liknar JMIE men har fyrkantiga gafflar och några andra egenheter. Den har levt vidare ända till idag som ett rent svenskt unikum. Den är idag känd som IRM-notation.   

Avgränsning

Jag har i den här artikeln avgränsat mig till de vanligaste och mest generella notationerna. Det vill säga de som hör till familjen Entity-Relational Diagram samt klassdiagram i UML Vi har därmed inte tagit upp följande notationer:

  • Object-role modelling (ORM) som är ett alternativ till ER-notation där man endast uttrycker elementära fakta, utan att strukturera dessa i entiteter, attribut och relationer.
    (Bör inte förväxlas med Object Relational Mapping). Det kanske jag återkommer till i någon senare artikel.
  • Diagramtyper som är värdefulla komplement till ett ER-diagram. Jag tänker särskilt på förekomstdiagram (Instance Diagram) och tillståndsdiagram (State charts), vilka jag planerar att beskriva i senare artiklar.

Vad tycker du?

Notationer är det ett område med personliga preferenser. Jag har nu redogjort för mina, fast försökt vara någorlunda objektiv ändå, om det nu alls är möjligt. Det är möjligt att du gör en annan bedömning. Det skulle vara intressant att höra både vad du håller med om och vilka andra bedömningar du gör.

/Peter Tallungs, IRM

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 3 juni. Då handlar det fortsatt om informationsmodellering, men med fokus på tillståndsdiagram.
Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Försvar för enkla verktyg – del 5: publicerings- och samarbetsverktyg

En arkitektfunktion behöver vara tillgänglig för en större krets intressenter. Vi behöver därmed någon form av media för att kommunicera effektivt. Vi behöver också virtuella whiteboards för modelleringssessioner. Samt något så otippat som en storformatskrivare.

Som arkitektfunktion i en organisation är vi som vilken verksamhet som helst. Vi behöver berätta att vi finns och vad vi kan bidra med (vår marknadsföring). Vi behöver nå de som behöver våra tjänster (våra kunder) och har nytta av våra modeller, analyser och beskrivningar (våra tjänster och produkter). Vi behöver leverera det de behöver på det sätt som passar dem (vår ”försäljning”). Våra kunder behöver kunna nå oss (vår kundtjänst) och vi behöver modellera tillsammans med våra kunder (co-creation).

Vi kan jobba inbäddat i utvecklingsteam, vi kan köra workshops, vi kan intervjua och forska själva. Men vid sidan av dessa nära och påtagliga samverkansformer behöver vi också vara tillgängliga för en större krets i den organisation vi jobbar. Vi behöver därmed någon form av media så vi kan nå ut bredare. Det här är en av de vanligen misskötta delarna av arkitektarbetet; att förstå att vi är en verksamhet, som vilken som helst, med många intressenter och att vi därmed behöver agera som en sådan.

Vi behöver en kommunikationskanal

Vi behöver därmed någon form av kanal för att kommunicera brett. Jag beskriver nedan hur vi har gjort i de sammanhang jag jobbat. Oftast finns det någon form av samarbetsplattform, kanske en wiki eller något annat, i organisationen där man kan publicera material och skapa olika former av dialogtjänster. Det ska kunna gå att göra följande:

  • Bygga en lämplig struktur
  • Publicera texter, så som meddelanden, annonser och artiklar
  • Publicera länkar till material som man kan ladda ner
  • Prenumerera på notifieringar
  • Kommentera saker och ting, och att diskutera i forum.

Vi behöver ett skyltfönster, ett bibliotek och en anslagstavla

På en samarbetsplattform, av något slag, kan vi bygga upp en webbplats som blir vårt skyltfönster, vårt öppna bibliotek med publicerade modeller och andra dokument samt vår anslagstavla. Där kan vi göra följande:

  • Publicera basinformation om vår funktion:
  • Vilken funktion vi är, till exempel Informationsarkitekt-teamet (IA-teamet)
  • Vilka personer vi är (foton, namn, beskrivning av roll)
  • Vad vi kan bidra med
  • Hur man når oss (telefon och mejladress).
  • Publicera material, till exempel befintliga modelldokument, både för att titta på och ladda ner för att skrivna ut och använda.
  • Publicera händelser. Berätta vad som hänt, till exempel att vi nu uppdaterat en modell i något avseende.
  • Ta emot och bemöta kommentarer,det vill säga få till en dialog.

Vi behöver skilja på arkivet i bakgrunden, vårt repository där vi förvarar och versionshanterar allt vårt material och det öppna tillgängliga biblioteket av publicerat material. I alla verksamheter som hanterar material finns det ett arkiv där allt material förvaras och ett allmänt rum där det som är publicerat finns tillgängligt för de som behöver.  

Vi behöver en redaktör

Som vilken mediekanal som helst så behöver vi en redaktör. Det fungerar inte tillfredsställande med delat ansvar. Det kan vara en person som på en del av sin arbetstid ser till att sköta både struktur och innehåll, kräva in och publicera material och notifiera prenumeranter.

Vi behöver virtuella whiteboard-verktyg

Vi är många som i dessa Coronatider kört modellerings-sessioner på distans med hjälp av virtuella whiteboard-verktyg som till exempel Miro, Mural och Lucidspark och upptäckt att det går utmärkt. Det är klart att inget slår den dialog vi kan få till runt en fysisk whiteboard, men dessa verktyg är ändå fullgoda ersättare och vi kommer förmodligen att även i framtiden komplettera fysiska sessioner med virtuella.  

Vi behöver en storformatskrivare

Modelldiagram behöver bära mycket kunskap samtidigt som de är översiktliga och detaljrika. De kommer inte till sin fulla rätt vare sig på skärm eller projektorduk. De behöver kunna skrivas ut i stort format. Därför förespråkar jag en storformatskrivare.

Det påståendet möts ofta med misstro och ibland till och med lite löje. Vi lever ju i digitalåldern. Inte behöver vi pappersutskrifter då? Men papper är i detta fall det rätta.

En storformatskrivare är en färgskrivare med papper på rulle som skriver ut upp till A0-format (ca 84x119cm). Den är en bläckstråleskrivare vilket gör den enkel, billig och lättskött. Den kostar ca 15 000 kronor. Den är inte större än den gamla synten hemma i gillestugan och kan lätt rullas undan när den inte behövs.

Man kan visserligen få utskrifter från en kopieringsbyrå på stan. Men det tar arbetstid och ledtid och kostar dessutom mycket mer. En egen skrivare betalar sig i ren kostnad efter färre än tio utskrifter. Men det är inte den stora vinsten. Om man inte kan skriva ut direkt så är det en hämsko på arbetet, det segar ner den interaktiva processen. Ty när man skrivit ut en modell man tror man är klar med så upptäcker man direkt, och nästan utan undantag, att man vill ändra något.

Papprets kraft

Det är något magiskt med det fysiska papperet och hur man interagerar med det. Sätt upp din modellutskrift bredvid kaffeautomaten så kommer medarbetare att bli intresserade. Min kollega lägger till och med dit en bunt post-it-lappar och tuschpennor och lockar kaffetörstiga att förbättra modellen. Så bryter man den onödiga respekten för modellen och bjuder in till nyfikenhet, diskussion och engagemang. Man visar att modellen är ett påstående, en hypotes som ska prövas; lika mycket en fråga som ett påstående. ”Vår nuvarande missuppfattning” brukar jag säga. Är det så här saker och ting hänger ihop? Och är det här det bästa sättet att gestalta det? Vi vill veta vad du ser!

Organisationer som har tillgång till storformatskrivare tapetserar väggar och korridorer med modeller, samlas runt dem och ritar. Ibland breder de ut papper på golvet för att tillsammans stega sig igenom sina processer. Storformatskrivaren blir populär i organisationen. Det ligger något fantastiskt i det. Om vi verkligen vill ha engagemang och medskapande så är detta, det mest otippade verktyget i verktygslådan, även det viktigaste.    

På IRMs kontor har vi sedan många år tillbaka en storformatskrivare. Mycket av vårt sätt att utveckla hur vi gestaltar olika typer av modeller som informationsmodeller och förmågekartor hade inte varit möjligt utan den. Ofta tar jag med en rulle med modelldiagram till den kund jag är hos för tillfället. De hamnar på kundens korridorväggar och väcker nyfikenhet och intresse för vad vi gör.

Slutord

Det här var den sista artikeln i den fem delar korta artikelserien ”Försvar för enkla verktyg”. Jag har argumenterat för att en uppsättning vanliga verktyg som i de flesta fall redan nu finns tillgängliga från ditt ”skrivbord” är ett bättre alternativ för oss informationsmodellerare än de mer specialiserade verktyg som finns på marknaden.

Observera att inget av argumenten har varit att det är en billig och tillgänglig verktygslåda, även om det är sant. Ty det är ett argument som bör väga lätt. I stället har jag på punkt efter punkt velat visa att de enkla verktygen är de bästa verktygen. Ja, ofta till och med de enda verktyg som duger utmärkt för det vi behöver för att få till en hållbar och varaktig nytta i en verksamhet. 

Jag har skrivit detta utifrån min roll som informationsarkitekt. Men jag menar att det gäller i lika hög grad för de andra arkitekt-, analytiker- och utvecklarrollerna i våra organisationer. Behovet att arbeta modelldrivet, kommunicera och samverka är precis detsamma.

Det skulle vara intressant med en dialog runt detta. Vilka verktyg använder du? Har du gjort andra val än jag?

/Peter Tallungs, IRM

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 27 maj. Då handlar det om notationer för informationsmodellering. Vilka finns det och vad skiljer dem åt?
Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

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.