Modellera strukturer med instansdiagram

Ofta behöver vi reda ut och beskriva de strukturer olika objekt kan bilda med sina relationer. Det kan till exempel vara olika varianter av avtals- och kontostrukturer. Då händer det att våra vanliga diagram, det vill säga ER-diagram, inte räcker till. Ett sådant avbildar ju bara den allmänna strukturen på typnivå, inte det individuella fallet. Då är det lämplig att komplettera sin modell med en annan typ av diagram; instansdiagram (Instance Diagram). Ett sådant beskriver nämligen strukturer som förekomster av verksamhetsobjekt kan bilda.

Att beskriva exempel på förekomster i stället för klasser av förekomster

Ett ER-diagram (liksom ett klassdiagram i UML) beskriver klasser av företeelser, inte vilka enskilda förekomster företeelserna kan ha. En entitet som heter ”Kund” beskriver vad som är gemensamt för alla kunder. Den omfattar själva begreppet ”Kund”, vilka egenskaper och relationer en kund kan ha som är intressanta för vår verksamhet att hålla reda på. Entiteten står alltså för en klass av företeelser. Den är som en mall för alla kunder. Den säger inget om någon enskild förekomst av en kund.

Den struktur som ett ER-diagram ger är precis vad vi behöver som bas i en informationsmodell. Men för vissa av de områden vi behöver analysera, beskriva och skapa ett språk för räcker inte ER-diagrammet till. Jag har i en tidigare artikel berört tillståndsdiagram för att modellera det dynamiska beteendet hos verksamhetsobjekt, det vill säga hur ett objekt kan ändra tillstånd som en reaktion på olika händelser. Men nu har turen kommit till instansdiagram (Instance Diagram eller som det heter i UML: Object Diagram).

Ett instansdiagram liknar ett ER-diagram, men en ruta (eller annan symbol) i ett instansdiagram avser inte en klass av företeelser utan är exempel på en förekomst (instans) av en företeelse. Instansdiagram kan därmed användas för att reda ut och beskriva hur förekomster av objekt kan uppstå och relaterar till varandra i olika situationer.

Exemplet ovan

Den illustration som inleder denna artikel är ett utsnitt ur ett större modelldokument. De två instansdiagrammen, diagram 7 och 8, förklarar tillsammans med texten skillnaden mellan två typfall av motorfordonsförsäkring som förekommer i försäkringsbranschen: Enskild försäkring och Samlingsförsäkring.

Varje symbol i diagrammet representerar ett exempel på en förekomst av ett verksamhetsobjekt. En bilsymbol representerar ett fordon, en fabriksymbol representerar en företagskund och en dokumentsymbol representerar ett avtal. I instansdiagram använder jag ofta symboler i stället för anonyma rektanglar. Det gör diagrammet mycket tydligare. Strecken representerar relationer, samma relationer som i motsvarande ER-diagram, men eftersom det handlar om relationer mellan förekomster och inte mellan klasser blir det inga gafflar i ändarna. En relation går ju alltid mellan en förekomst av en företeelse till en annan förekomst.

Avsikten med dessa diagram och medföljande text var att tydligt förklara skillnaden mellan de två typfallen. De skiljer sig inte nämnvärt åt vad beträffar vilka verksamhetsobjekt och relationer de har. Det vill säga att ER-diagrammen skulle vara förvillande lika. Den enda skillnaden är att Samlingsförsäkring har avtalsdelar samt andra kardinaliteter (multipliciteter) för relationerna. Ändå är skillnaden avsevärd vad gäller komplexitet i hela strukturen, och därmed i hanteringen. Detta var svårt att förmedla på annat sätt än med instansdiagram. Ett ER-diagram varken förklarar eller framhäver den stora skillnaden.

Det som är speciellt med instansdiagram

Det finns många olika sammanhang där ett instansdiagram kompletterar ett ER-diagram. Det är mångsidigt användbart och har visat sig oumbärligt i många situationer. Det är några saker jag vill framhålla vad gäller instansdiagram:

  • Ett instansdiagram ersätter sällan ett ER-diagram. Vi behöver nästan alltid ett ER-diagram i botten. Instansdiagrammet kompletterar ER-diagrammet.
  • Vi bör se ett instansdiagram som en integrerad del av informationsmodellen, inte som en förklaring av informationsmodellen. Detta av två orsaker:
    1. Vi bör vänja oss vid att en informationsmodell inte är liktydigt med ett ER-diagram, utan att vi bör använda oss av alla medel vi behöver, inklusive olika typer av diagram och texter.
    2. Ofta behöver vi instansdiagram inte bara för att förklara vad vi redan vet, utan även för att verkligen analysera och förstå en eller flera samverkande strukturer. Då är det inte ”bara” en förklaring av en modell. Precis som alla andra delar av en modell är det ett verktyg för utforskning och lärande. Jag kommer i senare artiklar att visa några exempel på situationer där jag menar att det hade varit omöjligt att komma till en gemensam förståelse på ett annat sätt än med instansdiagram som verktyg för gemensamt utforskande av en domän.   
  • Instansdiagram blir ofta bättre av att ha olika symboler i form av stiliserade bilder för de olika verksamhetsobjekten.
  • Ett instansdiagram har nytta av en förklarande text, som i exemplet ovan. Det är viktigt att texten finns i anslutning till själva diagrammet och inte någon annan stans. Synergin mellan text och bild ger ett större förklaringsvärde. Det är ett av skälen till att vanliga verktyg som MS Word och MS Visio är effektivare än de specialiserade arkitekturverktygen. Det är svårt att få till de symboler och den integration av text och bild du behöver med ett specialiserat verktyg.

Har du använt instansdiagram i dina informationsmodeller? Hur har det fungerat? Vad är din erfarenhet? Kommentera gärna.

/Peter Tallungs, IRM

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 17 juni. Då handlar det om uttrycksmedel som finns UML:s klassdiagram och som kanske borde finnas i fler notationer.
Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Modellera livscykler med tillståndsdiagram

I varje verksamhet finns det företeelser som transformeras till olika tillstånd. Dessa tillstånd är en central aspekt av verksamhetslogiken och är därmed något vi behöver definiera och hålla reda på. En informationsmodells ER-diagram behöver därför ofta kompletteras med tillståndsdiagram (Statecharts) för att visa vilka tillstånd ett verksamhetsobjekt kan växla mellan, vilka händelser som orsakar tillståndsförändringen och vilka orsakerna kan vara.

Verksamhetsobjekt har livscykler

De flesta verksamhetsobjekt har någon form av livscykel. Det brukar hanteras som att de har ett attribut som heter status med några fördefinierade värden. Ofta bara en kod, ibland även ett namn och om man har tur en tydlig definition. Här följer några exempel:

En kund kanske börjar sitt liv som ett prospekt (en intressent man tänker bearbeta för att bli kund). Sedan blir den en aktuell kund. Och till sist blir den en tidigare kund. Sedan kanske den någon gång kan återgå till prospekt. Eller till aktuell kund?

Ett ärende kanske börjar sitt liv som ankommet, sedan blir det under bearbetning för att till sist bli avklarat. Kan det då återgå till under bearbetning?

En produkt kanske börjar som under utveckling, sedan i produktion, sedan inte längre i produktion men fortfarande supportad, för att till sist bli avvecklad. Kan den någon gång senare gå i produktion, eller måste den då passera under utveckling?

En del verksamhetsobjekt kan ha fler än en tillståndscykel. Då brukar den ena cykeln vara den mer grundläggande, en som vi kan kalla för livscykel, som i exemplen ovan. Och de andra cyklerna handlar om andra tillstånd man vill hålla reda på. Till exempel kan ett bankkonto för tillfället vara övertrasserat eller inte övertrasserat. Det är inte samma sak som den mera grundläggande livscykeln som anger om kontot är öppet eller stängt, även om det naturligtvis finns orsakssamband mellan dessa.

Händelser och tillståndsövergångar

En händelse är något som inträffar med ett verksamhetsobjekt. Det kan till exempel vara att en kund gör ett köp eller att ett konto övertrasseras. Vanligen vill man hålla reda på olika typer av händelser. En händelse kan leda till att verksamhetsobjektet i fråga byter tillstånd, det vill säga en tillståndsövergång.Till exempel kan händelsen vara att vi avslutar en kundrelation och då blir kunden tidigare kund.

Orsaker till händelser

En och samma händelse kan ha olika orsaker. Ofta vill vi logga orsaken till en händelse. Om vi till exempel avslutar en kund kan det bero på en mängd olika orsaker. Kunden har kanske; inte uppfyllt sina skyldigheter, avvecklat sin verksamhet, avlidit, blivit dömd för olaglig verksamhet etcetera. Eller kanske har vi en gräns, så att vi automatiskt avför kunder som inte hörts av på ett par år.

Skilj på tillstånd, händelse, tillståndsövergång och händelseorsak

Vi ser ofta att man med sina statuskoder blandat ihop dessa saker. Så fort det kommit behov av att man vill följa något för mätetal och rapportering har man bara lagt till en kod till befintligt status-attribut. Vi hamnar ofta i situationer där vi behöver reda ut detta.

Vad är då ett tillstånd?

Med tillstånd menar vi ett läge som ett verksamhetsobjekt hamnat i vilket medför ett visst beteende och oberoende av hur det kom till detta läge. Ett avslutat konto beter sig på samma sätt, lyder under samma regler oberoende av orsaken till att det avslutades.

Tillståndsdiagram

För att modellera tillstånd, händelser, tillståndsövergångar och händelseorsaker räcker det inte med ER-diagram. Då behöver vi komplettera vår informationsmodell med en annan typ av diagram som heter tillståndsdiagram (Statechart eller Harel Statechart). Det är en diagramtyp som alla ingenjörer och programmerare som utvecklar inbyggda system är förtrogna med, men som är mer eller mindre okänd bland informationsmodellerare utan denna bakgrund.

På mina kurser brukar jag fråga hur många av eleverna som känner till och har använt tillståndsdiagram. Det brukar vara omkring hälften, vanligen de med en ingenjörsteknisk bakgrund. Sedan frågar jag hur många av dessa som har använt tillståndsdiagram för någon typ av verksamhetsmodellering. Då åker nästan alla händer ner. De har tydligen trott att tillståndsdiagram inte har sin användning annat än i rent tekniska sammanhang. Inget kan vara mer fel.

Tillstånd, händelser och händelseorsaker är viktiga företeelser i varje verksamhet. Det är grundläggande för att hålla reda på saker och ting, och är därför en viktig del av en informationsmodell. Då är det lämpligt att vi som informationsmodellerare utökar vår verktygslåda till att omfatta även tillståndsdiagram.

Men är det inte det vi har processmodellen till?

Det finns en viss likhet mellan å ena sidan ett tillståndsdiagram och å andra sidan en processmodell eller flödesschema. Båda visar det dynamiska beteendet hos något verksamhetsobjekt. Men skillnaderna är följande:

  1. En processmodell visar en viss process, det vill säga på ett visst flöde. Ett tillståndsdiagram visar alla flöden som är möjliga.
  2. En processmodell visar sällan tillstånd och händelser, utan vad som utförs för att åstadkomma ett resultat. Ett tillståndsdiagram ger reglerna för hur ett objekt kan och inte kan uppträda, genom alla processer det deltar i.
  3. I processmodellen sker det som sker i symbolerna (processfiskarna). Händelserna och tillstånden finns på strecket mellan symbolerna. I tillståndsdiagrammet händer det däremot inget i symbolerna (tillståndssymbolerna). Det är först i strecken mellan som det sker saker som ändrar tillstånd.
  4. Processmodellen är ofta inte heltäckande. Den visar de vanligaste scenarierna, inte allt som kan hända med ett verksamhetsobjekt. Ett tillståndsdiagram ska visa alla tillåtna tillstånd och händelser. Tillståndsdiagram beskriver reglerna för transformationer medan processer beskriver olika vanliga scenarier för transformationerna.

Sambandet mellan en processmodell och ett tillståndsdiagram

En processmodell och ett tillståndsdiagram har ett samband så till vida att allt som sker i processmodellerna bör täckas av tillståndsdiagrammet för samma verksamhetsobjekt.

Här förutsätter jag att vi talar om en processmodell som inte bara visar en serie arbetssteg i största allmänhet utan som är ren i den bemärkelse att processen beskriver hur ett och samma verksamhetsobjekt förädlas eller på annat sätt ändras genom en serie transformationer.

Sambandet mellan en processmodell och ett ER-diagram

Ett ER-diagram och ett tillståndsdiagram har ett samband så till vida att varje möjligt tillstånd, varje händelse och varje tillståndsövergång och händelseorsak som vi behöver hålla reda på behöver representeras i ER-diagrammet, som förekomster till entiteter. Jag brukar lista dessa i själva diagrammet med både namn och definition.
Tillståndsdiagrammet hjälper oss sålunda att undersöka och illustrera det dynamiska beteendet hos ett verksamhetsobjekt. Själva definitionen av tillstånd, händelser och orsaker finns i ER-diagrammet eller i textdelarna av modellen.

Var i informationsmodellen placerar jag tillståndsdiagrammet?

Det beror på i vilket sammanhang tillståndscykeln är viktig att beskriva, vilket varierar något. Jag brukar växla mellan tre olika placeringar.

  1. I textdelen av den allmänna beskrivningen av entiteten i fråga. Det gör jag när det handlar om en livscykel som är central för att förstå entiteten ifråga.
  2. I textdelen för beskrivning av attributet som representerar tillståndet, det vill säga det som brukar heta ”status”. Det gör jag när det inte handlar om en livscykel för objektet utan någon annan mindre central cykel av tillstånd.
  3. I ER-diagrammet tillsammans med de entiteter som representerar tillstånd, händelser och orsaker. Det gör jag i så fall i kombination med någon av beskrivningarna i textdelen ovan.  

Exempel på användning av tillståndsdiagram

Vi på IRM byggde för en tid sedan ett Data Warehouse hos en bank som köpt upp flera andra bankföretag. Bankföretagen hade liknande betalningsprodukter men det hade utvecklats olika avtalsstrukturer. Alla hade någon form av avtal för sina kunder. Alla system hade någon form av status för sina avtal, men man hade över åren bara lagt till nya statuskoder för allt möjligt som man ville hålla reda på.

Systemen behövde nu kunna rapportera in sina data i samma format så att vi i Data Warehouse kunde skapa översikter oberoende av hur de olika systemen såg ut internt. Vi var alltså tvungna att skapa ett ”lingua franca”, ett gemensamt språk för tillstånd, händelser och händelseorsaker. Vi samlade de som visste mest om detta och var mest beroende av att tolka dessa koder, det vill säga marknads- och riskanalytikerna. Sedan ritade vi upp en första version av ett tillståndsdiagram med de tillstånd och händelser vi trodde på.

Därefter fick analytikerna gå igenom en mängd olika händelsekedjor och se hur de passade in i livscykeln. Vi ändrade många gånger tills alla var nöjda. Vi jobbade mycket med namn och definitioner. Sedan fick de som var ansvariga för respektive system bygga översättningar från sina lokala språk till vårt nu gemensamma språk. Det hade varit svårt att åstadkomma detta på ett annat sätt än med tillståndsdiagram.

När behöver man ett tillståndsdiagram?

Man behöver kanske inte tillståndsdiagram för linjära cykler då ett objekt bara kan gå en rak väg längs en serie av tillstånd. Men man behöver i vilket fall lista tillstånden, se till att de har bra namn och definitioner, samt definiera händelser och orsaker till tillståndsförändringarna. Och för att vara alldeles säker på att ett objekt inte kan gå tillbaka till tidigare tillstånd bör man gå igenom alla tänkbara scenarion. Ett effektivt sätt är att undersöka befintligt data. Har det hänt att en avslutad kund har återöppnats? Eller blir denne definitionsmässigt en ny kund då?

Vad är en informationsmodell egentligen?

Jag menar att en informationsmodell inte måste vara samma sak som ett ER-diagram. Det behöver alltid finnas ett eller flera ER-diagram som bas i informationsmodellen, men vi behöver fler diagramtyper för att komplettera, då ER-diagram inte lämpar sig för att gestalta det vi behöver gestalta. Tillståndsdiagram är ett exempel på ett sådant komplement.  

Vi behöver helt enkelt utveckla vår verktygslåda, bruka de verktyg som gör jobbet. Inte bara bli operatörer av de oss givna verktygen. Många som informationsmodellerar känner bara till ER-diagram. Du är säkert bekant med liknelsen att om man bara har en hammare så ser man bara spikar, och bankar ner både spikar och skruvar.

Hur lär jag mig mer om tillståndsdiagram?  

Det finns gott om material om tillståndsdiagram, både i böcker och på webben. Googla ”Statecharts”. Har du använt tillståndsdiagram till informationsmodellering?

/Peter Tallungs, IRM

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 10 juni. Då handlar det fortsatt om notationer för informationsmodellering, men vi går närmare in på notationer för tillståndsdiagram.
Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

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.


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.

Försvar för enkla verktyg – del 1

En serie i serien. Med denna artikel inviger vi en artikelserie på fem artiklar om informationsmodelleringsverktyg i artikelserien Informationsarkitektens tankar.

Informationsmodellering är ett hantverk. För en hantverkare är verktygen viktiga. Låt oss se över vår verktygslåda. I den här artikeln vill jag försvara de enkla modelleringsverktygen.

Det finns ett antal specialiserade modelleringsverktyg, för både informationsmodeller och andra modeller. De är egentligen hela verktygsplattformar tänkta att stödja modelleringsarbetet genom att integrera grafiska och verbala beskrivningar på ett strukturerat sätt. De ger ofta även stöd för att bygga upp ett förråd för en organisations samtliga modeller, ett repository.

En annan väg att gå är att använda sig av en kombination av vanliga generella verktyg, såsom basala rit-, -skriv, dokumenthanterings- och samarbetsverktyg där man själv får bygga upp de strukturer man behöver. Det är en ”best of breed”- strategi, de vill säga att man strävar efter att använda det bästa verktyget man kan finna för varje enskild arbetsuppgift i modelleringsarbetet.

Jag och mina kollegor har hjälpt många team och organisationer att bygga upp verksamhets- och informationsarkitektur samt Data Management. Vi har därmed erfarenheter från många olika sammanhang och förutsättningar.

Mot denna bakgrund har jag kommit till att förorda det senare alternativet då en kombination av enkla verktyg inte bara är gångbart utan det enda verkligt framgångsrika jag känner till. Enkla verktyg är inte enkla i den meningen att de är simpla. Tvärtom! De ger den flexibilitet och uttrycksfullhet vi behöver för att göra ett bra jobb som informationsarkitekter.

Jag har upplevt att denna ståndpunkt är kontroversiell bland enterprise- och it-arkitekter. Jag vill därför i denna artikel, och fyra efterföljande, tydligt och noggrant argumentera för den vägen. Kanske kan jag få någon att bli mer öppen för det alternativet. Eller också blir jag avfärdad som Luddit. (Ludditer var de engelska teknikfientliga väveriarbetarna som bjöd våldsamt motstånd till de nya effektiva vävstolarna i början av 1800-talet.)

Den enkla verktygslådan

Här är listan på de typiska verktyg jag rekommenderar. Det finns förstås likvärdiga alternativ, men då av samma enkla slag.

  • Microsoft Visio: För att rita
  • Microsoft Word: För textdokument och för att integrera text och bild
  • Katalogstruktur på server, eller liknande: Som repository för modeller
  • Ändringshistorik i dokument samt rutin för att spara versioner i katalogstrukturen: För versionshantering
  • Wiki eller det samarbetsverktyg som används i den organisation jag jobbar: För att publicera modeller samt kommunicera ut vad som händer
  • Storformatskrivare: För utskrift av modeller
  • Whiteboard och digitala samarbetsverktyg: För modelleringssessioner.

Jag kommer i följande fyra artiklar motivera och beskriva hur man kan använda respektive verktyg i verktygslådan. I denna inledande artikel ger jag generella motiveringar för kombinationen av enkla verktyg i motsats till de specialiserade.

Motivering för enkla verktyg

Här följer ett antal motiveringar till att välja enkla verktyg.

Motivering 1: Enkla verktyg ger frihetsgrader och möjliggör den rikare och mer kraftfulla gestaltning som vi behöver

Våra modeller kan bli mycket bättre gestaltade än vad som är vanligt idag. Det gäller alla slags modeller. Om vi ska lyckas få en organisation att samlas kring modellerna och låta dem representera en gemensam förståelse måste de bli mycket mer överskådliga, tydliga och tillgängliga. Samtidigt behöver de ges ett rikare uttryck genom att kombinera olika slags kunskap. Det handlar om hur vi ritar. Det vill säga struktur, disposition, färger, gråskalor, linjetyper, typsnitt, symboler, samt hur vi integrerar text och bild. Vi behöver kombinera och integrera olika slags diagram med varandra samt med textuella beskrivningar.

Det sätt vi i branschen idag arbetar med våra modeller har en stor potential till förbättring. Det handlar också om hur vi hanterar våra modeller, och hur vi tillgängliggör dem. För att kunna göra allt detta på ett bra sätt behöver vi verktyg som ger frihetsgrader, som inte begränsar oss, låser in oss och hindrar oss i det vi behöver göra.

Motivering 2: Enkla verktyg främjar experimenterande och därmed utveckling av alla våra områden där modellering är en viktig del.

Som yrkesgrupp behöver vi utveckla informationsmodelleringsområdet. För det behöver vi verktyg som ger oss den friheten.

Jag vill jämföra med vad som hände inom systemutveckling kring millennieskiftet. Vid slutet av 90-talet var tron på specialiserade modelleringsverktyg stor. Rational Unified Process var den förhärskande utvecklingsmetoden och Rational Rose var det modelleringsverktyg som skulle stödja hela utvecklingsprocessen. De organisationer som var ambitiösa och anammade detta arbetssätt fick det svårt. Metoden framställdes och tolkades på ett sätt som gjorde den överlastad och rigid. Själva metoden och verktyget styrde tänkandet och arbetssättet i stället för att vara en verktygslåda. Det blev att man fokuserade på att betjäna verktyget och utvecklingsmetoden i stället för att koncentrera sig på vad användare och verksamhet behövde. Man blev på så sätt en operatör av ett verktyg utan egen agens och ansvar.  

I det sena 90-talet växte missnöjet hos utvecklare och utifrån några individer växte det fram en motrörelse. Några utvecklare, på lite olika ställen, började tänka på vad de själva verkligen behövde och vad som fungerade. De tog fram mer basala och hantverksmässiga arbetssätt som parprogrammering, test-first design, scrum-tavlor med mera. Det nya tänkesättet grodde och spred sig i utvecklarsamhället. Ett par år efter millenniumskiftet fick det etiketten agila rörelsen. Utvecklare byggde själva enkla verktyg för att stödja sitt arbete. Mest kända blev testverktyg för att automatisera tester samt så kallade refactoring-verktyg för att snabbt och enkelt göra ändringar i kod.

Jag menar att vi behöver en liknande rörelse bland oss informationsarkitekter. Det vi behöver är en ny vår för arkitektarbetet som ett hantverk, precis det som agila rörelsen var för systemutvecklare för två årtionden sedan. Vad gäller arbetssätt så har vi redan lärt av agila rörelsen och alla förstår nog nu att vi behöver smidiga och mer kommunikativa arbetssätt. Men då det gäller verktyg återstår att överge de stora tunga modelleringsverktygen och i likhet med systemutvecklarna gå till oss själva, och ställa oss frågan vad vi egentligen behöver. Tillbaka till hantverket, och vad som verkligen stödjer det.

Jag har sett organisationer där arkitekterna varit som slavar under avancerade verktyg. De har varit upptagna med att mata verktygsmonstret. Resten av organisationen har inte haft nytta av arkitekterna, som befunnit sig i en parallell värld utan kontakt med verksamhetsutvecklingen.

Och denna nya vår jag hoppas på har faktiskt redan grytt på en del ställen. Jag har sett organisationer där verksamhets- och informationsarkitekter till sist givit upp sina tunga arbetssätt och verktyg. De har lämnat sina slutna rum, klivit ner från elfenbenstornet och gått ut där verksamhetsutvecklingen sker, bland utvecklarna och i verksamheten. De har sett hur de kan stödja utvecklingsarbetet. De har då, för första gången, känt sig välkomnade av utvecklare och domänexperter. De modellerar fortfarande, men nu med enkla tekniker som tjänat syftet på ett helt annat sätt.

I de fall de trots allt behövt lite mer verktygsstöd har de, precis som utvecklarna, själva experimenterar och byggt de verktyg de behövt. Jag ska försöka ge exempel på sådana verktyg framöver.

Dessa egenbyggda verktyg kan sedan i likhet med vad som hänt inom utvecklarvärlden så småningom kommersialiseras och bli standard. Det är egentligen alltid så det sker då ett yrkesområde utvecklas på riktigt. Alltid utifrån professionen och hantverket. Aldrig från verktygsleverantörerna.

Motivering 3: Enkla verktyg sätter fokus på uppgiften

Att ta ansvar för något stort, till exempel en informationsarkitektur, kan vara skrämmande. Det är många saker man måste ta ställning till och kanske behöva försvara. Då är det lockande att gömma sig bakom ett ramverk, en industrimodell, en metod eller ett verktyg som synes ge objektiva svar. Det är att fly undan det ansvar vi har. Då blir jag en operatör av ett verktyg i stället för informations- eller verksamhetsarkitekt.

Vi behöver i stället fokusera på vad som behöver lösas i verksamheten och använda de verktyg som gör jobbet. Inte först välja verktyg för att sedan bara mata detta.

Motivering 4: Enkla verktyg minskar beroendet

Om man i en organisation har tagit in ett avancerat modelleringsverktyg så medföljer det ett antal metamodeller, vilka styr hur de modeller man tar fram måste se ut och relatera till varandra. Om man senare vill ändra detta kan det bli mycket dyrt och svårt. Verktygen är i själva verket ofta en hel plattform av verktyg som hänger samman. Man blir på flera sätt, på gott och ont, beroende av leverantören och dennes utveckling av plattformen.  

Vanliga argument för specialiserade verktyg

När man argumenterar för en enkel verktygslåda får man ofta mothugg. Här följer ett antal argument som man stöter på och hur jag vill bemöta dem. 

Argument 1: Specialiserade verktyg ger konsistens

Specialiserade verktyg har en metamodell som styr hur vi kan modellera. Det gör att vi alla ritar och beskriver på samma sätt vilket är viktigt. Om vi inte gör på samma sätt blir resultatet spretigt, återanvändningen svår och kvaliteten lidande. Det följer vanligen med metamodeller vi kan välja mellan och i de mer avancerade verktygen kan vi själva, eller med hjälp från konsulter, ta fram en egen metamodell som passar oss.

Mitt motargument: Sättet vi modellerar behöver utvecklas för att på allvar bli relevant för våra verksamheter. Vi behöver alltså se det som ett hantverk i utveckling. Då är experimenterandet viktigt, att vi söker oss fram och lär oss. Vi ska då inte standardisera arbetssätt, notationer, metamodeller med mera. Det skulle frysa all utveckling och fortsätta hålla oss fast på det stadium vi är idag. Däremot ska vi dela erfarenheter och inspireras av varandra. Men det är något helt annat.

Det finns alltid, inom alla områden en motsats mellan utveckling och standardisering. Vi ska standardisera det vi tycker att vi nått en mognad inom. Men bara där. Där vi behöver utveckling ska vi tvärtom befrämja att vi gör olika, inte bekämpa. Vi behöver tåla och bejaka spretigheten. Utveckling innebär experimenterande.

När vi har lärt oss vad som verkligen fungerar kommer saker och ting att mogna och vi kommer naturligt att gravitera mot något av en de facto-standard. Men att gå utvecklingen i förväg och bestämma en standard innan vi har nått den mognaden är fel. Det är att frysa all utveckling. Därför behöver vi frihetsgrader. Det betyder inte kaos, utan bara att vi i får vara beredda på varianter och förbättringar i små steg. Och även något vilt försök ibland! Det är så utveckling går till. Överallt och alltid.

Argument 2: Specialiserade verktyg ger struktur och ordning

Specialiserade verktyg styr hur och var vi spar, versionshanterar och publicerar modeller. De ger oss ett strukturerat repository. Det gör att resultatet inte bara blir högar av osorterade modeller på olika ställen med oklara syften och sammanhang.

Mitt motargument: Vi behöver alltid ett strukturerat repository. Vi vill inte ha oordning. Men det är mycket lätt att ordna det på ett enkelt sätt och på vilken lagringsyta som helst där man kan ha filkataloger av något slag, och något slag av enkel åtkomstkontroll och versionshantering.

Det är fel att tro att ett specialiserat repository krävs för ordning och reda. Ett specialiserat repository ger heller inte ordning och reda av sig självt. Vi behöver även då tänka igenom och komma överens om saker och ting. Den största faran med verktyg som styr oss är kanske just den tankefällan, att vi tror att vi inte behöver tänka själva. Vi har sett modellbibliotek som varit total kaos i verktygsbaserade repositories och jag tror faktiskt att vi sett fler välordnade bibliotek bland de som byggs mera manuellt. Jag är övertygad om att när jag behöver bygga något själv leds jag in på att tänka igenom och ta ansvar för vad som behövs.   

Argument 3: Specialiserade verktyg ökar produktiviteten

Verktyget hjälper mig. Jag kan återanvända delar av andra modeller när jag gör en ny, eller referera till befintliga. När jag vill göra en ändring av något som manifesterar sig på många ställen behöver jag bara ändra på ett ställe. När jag vill publicera en modell gör jag det automatiskt. Versionshanteringen är inbyggd vilket gör att den går lätt och smidigt. Jag behöver inte fundera så mycket på hur jag ska göra rent praktiskt med dessa hushållsbestyr så jag kan koncentrera mig på själva modellerandet.

Mitt motargument: Jo, verktyget hjälper dig förvisso med några enkla uppgifter. Men inte alls så mycket som man kan tro, och inte alls med det som är det väsentliga; hur du gör riktigt bra modeller och hur du når ut med dem. Tvärt om hindrar det dig. Så triviala uppgifter går kanske något snabbare – men till ett mycket högt pris.

Om vi definierar produktivitet som hur mycket nytta vi gör, hur bra vi når ut och hur vi hjälper människor och team att hantera sin komplexitet så vinner de enkla verktygen överlägset. 

Det finns ett talesätt som säger ”A fool with a tool is still a fool”. Det brukar motvilligt citeras av verktygssäljare när man pekar på misslyckade införanden av deras produkter. De vill betona att deras fina verktyg trots allt inte garanterar ett bra resultat, utan att det kan finnas dumma människor som inte begriper hur de ska användas. Det finns ett tillägg till talesättet som säger ”A fool with a tool makes a faster fool”. Det vill säga att om ett verktyg ökar produktiviteten utan att verktygsanvändaren gör ett bra jobb hamnar man snabbt i ett dåligt läge.

Argument 4: Specialiserade verktyg stödjer samarbete

Verktyget stödjer att flera kan jobba samtidigt med samma modell, kanske även från olika geografiska platser.

Mitt motargument: Jo, verktyget har funktioner för detta. Men det fungerar bättre med de generella samarbetsverktygen vi använder i övrigt i våra distansarbeten.

Konflikten mellan viss automatisk hantering och stöd för rik gestaltning

Jag menar att om vi använder de specialiserade verktyg som finns så får vi visserligen stöd för vissa enkla uppgifter.

Men vi väljer samtidigt bort möjligheten till att göra riktigt bra modeller.

Vi kan inte få både och. Åtminstone inte idag. Och inte förrän vi själva inom professionen bidrar till den utveckling som kanske kan ge oss sådana verktyg.

Och vi tenderar till att både övervärdera nyttan av den lilla automatisering vi kan få samt att undervärdera vikten av att göra riktigt bra modeller som når fram.

I själva verket är det så krasst att om vi inte når fram har vi inget som motiverar vår existens.

De ivrigaste proponenter för specialiserade verktyg jag mött har nästan i samma mening beklagat att de inte har gehör hos it- och verksamhetspersoner för vad de gör, utan blir ständigt kringrända av utvecklingsprojekten. Det kanske skvallrar om något?

Fortsättning följer

Jag är medveten om att den här posten väcker många frågor. ”Peter pratar mycket om att vi ska göra bättre modeller men inte hur det går till.” Det är ett stort område, men jag vill steg för steg i den här artikelserien ge mitt bidrag till det.

Vad är din erfarenhet? Vilka verktyg använder du? Handen på hjärtat, vad fungerar på riktigt?

/Peter Tallungs, IRM

Nästa del i miniserien om informationsmodellerarens verktyg publicerar vi torsdag 22 april. Vill du prenumerera på artikelserien Informationsarkitektens tankar? Registrera din mailadress här.

Data management – se hela kedjan

För att en organisation ska få nytta av sina data behöver en hel kedja av förutsättningar vara uppfyllda. Vi behöver se och förstå hela kedjan för att hitta och förstärka svaga länkar.

En organisations data är en tillgång. Om vi kan hantera den tillgången på ett bra sätt så ger den mångfalt tillbaka. Data kan inte bara stödja verksamheten operativt utan också användas analytiskt, det vill säga ge insikter och kunskap och därmed ligga till grund för beslut och handling. Men för att en datatillgång verkligen ska ge nytta måste den tas om hand, den måste förvaltas aktivt. Det är det vi kallar Data Management.

En modell i form av en kedja

Data Management är ett område med stor spännvidd och som inkluderar alla de åtgärder som behövs för att ta hand om en dataresurs för att maximera dess värde.
För att få överblick över området kan vi använda oss av en modell över en tänkt kedja av förutsättningar, från det att data registreras någonstans tills det att man får nytta av dessa data i organisationen. Modellen är en uppräkning av förutsättningar som tillsammans bildar en kedja, där varje förutsättning behöver uppfyllas. Jag har ofta visat denna modell i olika sammanhang för att visa vad Data Management kan omfatta. Modellen kan dock kännas en aning konstlad. Man har försökt pressa in lite för mycket, speciellt i slutet av kedjan. Som jag skrev i artikeln ”Data eller information” skapas sällan kunskap direkt ur data på ett linjärt sätt vilket modellen ger sken av. Kunskapsprocessen i en organisation är en växelverkan mellan flera olika handlingar och källor, där data visserligen är en viktig källa men ändå endast en av de inblandade faktorerna. Så vi ska ta modellen med en nypa salt. Men jag tycker ändå att modellen, trots sina begränsningar, har sin poäng i att den positionerar Data Management i förhållande till angränsande och överlappande discipliner. Modellen presenteras i det följande.

Kedjan av förutsättningar

Nyttan av data uppstår bara om en serie av förutsättningar är uppfyllda. Dessa förutsättningar bildar länkar i en kedja. Varje förutsättning blir meningsfull endast om alla föregående förutsättningar i kedjan är uppfyllda. Som bekant är det den svagaste länken i en kedja som avgör om den håller. Det spelar då ingen roll hur starka de andra länkarna är. Svagheten i en länk vägs inte upp av styrkan i de andra.

Kedjan av förutsättningar kan listas som nedan. För varje förutsättning ger vi exempel på faktorer som kan bidra till att den förutsättningen kan uppfyllas.

  1. Att rätt data finns
    Att det någonstans (innanför eller utanför organisationen) finns rätt data, det vill säga som handlar om rätt saker och är anpassade till situationen.
    Bidragande faktorer: Dataplanering, dataanalys, processutveckling, utveckling av applikationer för registrering, Business Intelligence, givare för insamling av data, givare för maskindata med flera.
  2. Att man känner till att dessa data finns och var de finns
    Det händer ofta att data finns men att de som behöver den inte vet om det. Då stoppar det redan här.
    Bidragande faktorer: Aktivt sökande av datakällor och datatjänster, datakataloger, Data Dictionary, utbildning, kommunikation, informationsmodeller/- kartor med flera.
  3. Att man kan nå och få fram dessa data
    Kan vara via maskinella eller manuella tekniker.
    Bidragande faktorer: Applikationer, intranät, internet, sökmotorer, SQL, Data Warehouse, API-er, datatjänster, presentationstekniker med flera.
  4. Att man kan förstå dessa data
    Det vill säga att man kan tolka dess innebörd och syfte med stöd av sina egna referensramar.
    Bidragande faktorer: Utbildning, erfarenhet, definitionsarbete, namngivning, modeller/kartor, metadata, dokumentation, informationsanalys med flera.
  5. Att man kan lita på informationen
    Att man kan lita på att den information man tagit till sig stämmer med verkliga förhållanden.
    Bidragande faktorer: Metadata, källhänvisningar, goda erfarenheter, datakvalitetsarbete, redundans med flera.
  6. Att man kan vidarebearbeta data
    Att man kan sortera, filtrera, kombinera, summera och sammanställa data och därmed bilda sig ytterligare sammanfattad/komplex information som blir mer användbar för att dra kunskaper ur.
    Bidragande faktorer: Data-analysverktyg och metoder, Data Science, rapportverktyg, aktivt arbete med framtagning och förvaltning av rapporter med flera.
  7. Att man kan dra korrekta slutsatser från informationen
    Från informationen man fått fram behöver man sedan kunna dra slutsatser som är relevanta i sammanhanget.
    Bidragande faktorer: Domänkunskap, erfarenhet, överblick, logisk förmåga, abstraktionsförmåga, konkretionsförmåga med flera.
  8. Att man kan besluta sig för ett handlingsalternativ
    Detta baserat på slutsatserna, intuition, beslutsstil och personliga faktorer.
    Bidragande faktorer: Beslutstil, beslutsförmåga, belöningssystem, rekrytering, organisationskultur, personlig utveckling med flera.
  9. Att man kan gå från beslut till handling
    Det vill säga verkställa och agera.
    Bidragande faktorer: Genomförandekraft, motivation, handlingsberedskap, inräkning och kultur för att agera med flera.

Se hela kedjan

Varje gång en nytta av dataförsörjningen har uppstått har varje länk i kedjan hållit. Om en enda länk i kedjan brister blir värdet noll. Det vill säga ingen nytta, endast kostnader. Helheten är därmed viktig. Inom Data Management behöver vi se hela kedjan, hitta de svaga länkarna och stärka dessa. Vi behöver därmed satsa brett på informationsteknik och verksamhet samt människa och teknik i samverkan.

Var kommer Data Management in?

Vi kan succesivt dela in kedjan i större sträckningar, vilka var och en kan ges en rubrik. Låt oss se var vi som jobbar med Data Management kommer in.

  • Länk 1-3: Utdata till användaren
    Det är det som it- funktionen i organisationer vanligen avgränsar sin uppgift till. Man ser vanligen inte det som sin uppgift att tala om vad data betyder eller vilken kvalitet de har.
  • Länk 1-5: Informationsförsörjning
    Det bör vara vår uppgift inom Data Management att lyfta organisation och arbetssätt till att omfatta hela informationsförsörjningen. Vi informationsarkitekter kan kanske göra störst nytta då det gäller att stärka länk fyra och fem så att hela informationsförsörjningen håller.
  • Länk 1-7: Informationsförsörjning och användning
    Det bör även ingå i informationsarkitektens uppgift att bidra till att analytiska användare har verktyg för att bearbeta de data de har tillgång till. Vi behöver av många skäl samarbeta nära med den typen av användare. Inte minst för att det ger insikter i hur vi kan bidra med att få mer data och i rätt form.
  • Länk 1-9: Hela kedjan till och med att nytta uppstår
    Hur användarna av data drar slutsatser, beslutar och agerar, på basis av data, kan vi inte direkt påverka. Dock behöver vi observera och arbeta tätt ihop med de som gör det. För det ger insikter om vad vi som arbetar med informationsarkitektur eller Data Management behöver bidra med.

Hur långt sträcker sig ditt intresse?

Hur långt sträcker sig ditt intresse och engagemang? Hur ser du på din eller ditt teams roll? Vilken länk är svagast i din organisation? Kan du göra något för att stärka den?
Dina erfarenheter och tankar är välkomna.

/Peter Tallungs, IRM 

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 15 april. Då inleder vi en liten serie i serien. Den kommer handla om hantverket informationsmodellering.
Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

”Data” eller ”information”

Vad är skillnaden? Jag tvekar ofta om jag ska benämna något som ”data” eller ”information”. Är det data eller är det information? Är detta som jag tar fram en datamodell eller en informationsmodell?

I Sverige kallas en konceptuell modell ofta för informationsmodell och en logisk eller fysisk modell ofta för datamodell. Men i USA talar man vanligen bara om ”Data Models” oavsett om de är konceptuella, logiska eller fysiska. Hur kan vi se på det?

Den påstådda teoretiska skillnaden

Alla som definierat begreppen data och information verkar vara överens om att data är råa uppgifter utan sammanhang och tolkning. Tänk att du tittar på en massa siffror men inte vet, eller bryr dig om, vad de står för. Vidare är man överens om att information är data som har ett sammanhang och tolkning.

Hur uppkom distinktionen?

Det kan vara intressant att veta hur distinktionen mellan data och information kom till. Inom system- och informationsvetenskap skedde detta i skiftet mellan 70- och 80-tal. Det var när man strävade efter att få sina områden att bli respekterade som strategiska management-discipliner. Man ville få företagsledningar att se data som en strategisk tillgång och lanserade därför en tänkt process med en transformering och filtrering från data via information till kunskap och ibland till och med ända till visdom.

Bild från gapingvoid.com

Synsättet har genom åren kritiserats som en alldeles för mekanisk och förenklad syn på kunskapsprocessen i en organisation. Visst spelar data och information en roll i kunskapsskapandet men sammanhangen är mycket mer dubbelriktade och sammansatta.

Se till exempel David Weinbergers artikel ”The Problem with the Data-Information-Knowledge-Wisdom hierarchy” och Patrick Lambs bloggartikel  “From Data, with Love”.

Det var i sammanhanget som är beskrivet ovan som en del började kalla datamodeller för informationsmodeller och Data Management för Information Management. Förmodligen för att få företagsledningars uppmärksamhet. Av någon anledning slog det språkbruket igenom i Sverige men inte i USA.

Som så ofta handlade det alltså mer om politik och revirpinkande än om någon verklig insikt.

Idag, ett halvsekel senare, kan man tro att ordens statusordning har kastats om. ”Data” har fått en ny laddning. Trenduttryck som ”Data is the new oil”, ”Data driven enterprise”, ”Data Science” och “Chief Data Officer” vittnar om att data inte längre ses som någon tråkig mekanisk infrastruktur.

Detta var en liten historisk bakgrund. Låt oss återgå till distinktionen mellan data och information. 

Vad är sammanhang och tolkning?

Om vi för diskussionens skull godtar att data blir till information vid den tidpunkt då den kläs på med ett sammanhang och en tolkning. När inträffar då denna punkt i processen? Problemet kommer då vi ska bestämma vad vi egentligen menar med sammanhang och tolkning. Vad är tolkning och sammanhang? När sker tolkningen av data? När sätts data i sitt sammanhang? Dessa frågor kan först verka ha enkla svar men blir vid en närmare betraktelse meningslösa.

Redan när data samlas in görs det i ett sammanhang som är känt och ges direkt en tolkning genom hur den hanteras.

Låt mig ta ett exempel. En givare av något slag ger ett mått på något, säg värdet ”23”. Någonstans där värdet från givaren registreras bör det nödvändigtvis finnas inbyggd kunskap om sammanhang och mening med mätningen. Man vet kanske att det är en temperaturgivare och att det är grader Celsius. Man vet var givaren sitter och därmed inte bara att det är lufttemperatur utan också på vilket ställe lufttemperaturen är registrerad. Utöver detta vet man också redan vid registreringen vilken tidpunkt värdet registrerades. Allt detta är mening och sammanhang för datapunkten och registreras alltså med en gång, bara genom vad det är för slags sensor och var den sitter. Om man ska vara strikt kan man hävda att det aldrig är frågan om rådata i egentlig mening. Om vi kan vara överens om detta så är det alltid fråga om information, ända från då den registreras.

Så, en sådan distinktion vi tidigare gjorde blir meningslös. I så fall, med det resonemanget, finns aldrig data, bara information. 

Vad det beträffar de modeller vi gör så blir det väl då alltid frågan om informationsmodeller. Ty där bryr vi oss alltid om meningen med de data vi hanterar.

Låt oss pröva ett annat synsätt. Kanske vi kan se det som att data blir till information först när någon människa har tagit hand om de insamlade data, gett det en ännu mer utarbetad tolkning. Om vi tänker oss att man samlat in lufttemperaturer under en tid och jämför med andra år och därmed kan säga att det varit en ovanligt varm marsmånad i år. Är det först då det blir information? I så fall hanterar vi vanligen inte alls information i våra informationsmodeller. Informationen uppstår först i de analyser och slutsatser som dras efter ett mänskligt bearbetande, och hanteras typiskt som text i en rapport av något slag.

Det är tydligt att vi har att göra med ett kontinuum där övergången från data till information är helt och hållet flyttbar. Den rör sig beroende på vad man lägger i begreppen ”sammanhang” och ”mening”.

Data och information på samma gång?

Vi kan i stället se det hela på ett annat sätt. Vi kan lämna resonemanget med en tänkt process, det vill säga föreställningen att data övergår till att bli information vid någon bestämd punkt. Istället kan vi se det så att samma insamlade siffror är både data och information samtidigt beroende på vilka aspekter vi för tillfället fokuserar på. När vi pratar om megabytes eller megabits per sekund så bryr vi oss inte om vare sig mening eller sammanhang. Då pratar vi om lagring eller transport av data, utan att bry oss om vad de står för. Men när vi verkligen vill titta på och förstå vad dessa data betyder ser vi det som information.

Det är det synsättet jag har fastnat för. Det är helt analogt med andra mänskliga områden. Om jag kör lastbil så kanske jag bara bryr mig om hur många ton och kubikmeter gods jag har. Men för mottagaren är det inte bara gods utan angivna mängder av specifika varor.

Några siffror är inte antingen data eller information utan både och, beroende på vilket perspektiv jag har för stunden. Distinktionen är ingen inneboende egenskap hos uppgifterna utan skillnaden ligger i betraktarens öga.

Problem med begreppet ”information”

Ett annat problem med termen ”information” är att den kan leda fel. Begreppet information leder närmast tankarna till sådant som ostrukturerad text och bild, det vill säga sådant som vi inte direkt hanterar i vårt skrå. Våra informationsmodeller visar ju endast sån information som är strukturerad som poster i en lista. Repeterbar abstraherad information, strukturerad för någon form av informationsprocessande. Termen ”data” ringar på ett bättre sätt in vad det handlar om än den alltför breda termen ”information”. I stora delar av världen kallas följaktligen det vi gör vanligen för ”Data Models”, ”Data Modeling”, ”Data Management” och så vidare.
”Information Management” står vanligen för en managementdisciplin, det vill säga hur man leder en verksamhet med information i centrum, alltså något helt annat.

Mer eller mindre synonymer?

Egentligen är väl distinktionen inte så viktig. Jag vill se termerna ”data” och ”information” som mer eller mindre synonyma. I varje fall i det sammanhang vi arbetar. Jag säger oftast ”data” eftersom jag anser att det leder tankarna lite mera rätt. Utom då det gäller modeller. Då säger jag vanligen ”informationsmodeller”. Inte så konsekvent språkbruk kanske, det är mest av gammal vana, och utan närmare eftertanke.

Vad säger du: data eller information? Gör du det som jag, av gammal vana eller har du reflekterat över vad orden egentligen står för?

/Peter Tallungs. IRM

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 8 april. Då handlar det om Datamanagement – hela kedjan.
Vill du prenumerera på denna artikelserie? Registrera din mailadress här.