Taggarkiv: Gestaltning av modeller

Informationsmodellering: Om struktur i flera nivåer

I en informationsmodell med många ämnesområden har vi ett behov av att gruppera dessa i större områden. Det vill säga att etablera en övergripande struktur för modellen. Sedan finns det också ofta ett behov av att dela in ett enskilt ämnesområde i mindre avsnitt. På så sätt kan vi strukturera en informationsmodell i flera nivåer. Denna artikel visar hur vi kan gestalta denna struktur grafiskt i ett ER-diagram.

Gruppering av ämnesområden

Låt mig visa ett exempel, se bild I. Detta är ett utsnitt av ett ER-diagram som är en översikt av en större informationsmodell, vilken omfattar en hel verksamhet. Modellen som helhet har ett femtiotal ämnesområden. Förutom det översiktliga ER-diagrammet finns det ett detaljerat ER-diagram och detaljerade textuella beskrivningar för varje ämnesområde.
Du kan läsa mer om ämnesområden i artikeln Informationsmodellering: Om ämnesområden

För att få till en övergripande struktur räcker det inte med ämnesområdena. Det finns ett behov av en mer övergripande struktur. För detta skapade vi femton övergripande områden med upp till kanske sex-sju ämnesområden i varje.

Lägg märke till hur vi har gestaltat denna indelning grafiskt. Varje sådan grupp av ämnesområden bildar en egen avgränsad rektangel i ER-diagrammet, med extra luft runt och en rubrik över. För att tydligt ringa in varje grupp har vi gjort en bred grå linje över gruppen, på vilken grupprubriken är skriven. Linjen spänner över hela bredden på gruppen för att tydligt markera vilka ämnesområden som ingår i gruppen. Även grupprubriken är grå, för att den inte ska framhävas lika mycket som entiteterna.

Det är viktigt att både rubrik, definition och rubriklinje är gjord i en mörkgrå färg, i likhet med ämnesområdets rubrik. Det gör att hela den underliggande strukturen hamnar på ett mentalt plan som är mindre framträdande, för att inte förvirra vårt mönstersökande synsinne. Det gör att entiteterna och deras relationslinjer framhävs i förhållande till strukturen. Allt detta gör modellen tydligare. 

Det vanligaste sättet att gruppera saker i flera nivåer i en graf brukar annars vara att rita rutor i rutor. Men det bör vi undvika. Det blir svårare att överblicka. Förmodligen för att hjärnan hela tiden söker mönster, och om rutor ibland kan vara entiteter och ibland ämnesområden och ibland grupper av ämnesområden så går en del mental kapacitet åt till att hela tiden försöka skilja mellan dessa. Synsinnet belastas ju mycket av att leta mönster bland myllret av synimpulser och försöka ge dessa mening. Vad hör ihop med vad? Vad är parallella företeelser? Vad är viktigast? Låt oss då hjälpa till, genom att göra de mönster vi vill förmedla visuellt tydliga, och låt oss avstå från sådant som förvirrar.

Bild I Exempel på gruppering av ämnesområde

Vi har lagt till en definition under, eller efter, grupprubriken när vi tyckt att det behövts, skrivet med ett mindre typsnitt. Detta har vi gjort med ämnesområdenas rubriker också, liksom med entiteterna.

Vi älskar definitioner! Inget skapar så mycket förvirring och tveksamhet helt i onödan, som en modell utan definitioner. Ett namn kan stå för lite av varje, och ofta är man osäker på vad den som gjort modellen har tänkt sig. Definitioner i ER-diagrammet ger läsaren en betydligt bättre chans att förstå.

Att skriva definitioner tvingar mig som modellerare att tänka igenom vad jag egentligen menar, och hur det kan uttryckas tydligt. Vilket ofta leder till att jag för mig själv reder ut inkonsekvenser och oklara tänkesätt. Esaias Tegnér sa det väl: ”Det dunkelt sagda är det dunkelt tänkta”. När vi tvingas att uttrycka våra uppfattningar tydligt, till exempel genom att tydligt definiera våra modellelement så som entiteter, ämnesområden, attribut och relationer, blir vi nödgade att tänka klarare och tydligare. Jag kommer i en senare artikel att berätta om vad en bra definition är och vad den inte är.

Gruppering i två dimensioner

Ibland finner man att man att det vore bra att strukturera sin modell i två dimensioner. Då kan man ordna ämnesområdena i rader och kolumner med rad- och kolumnrubriker. Se exempel bild II.

Bild II Exempel på gruppering av ämnesområde i två dimensioner

Gruppering inom ämnesområden

Vanligen finns det även ett behov av att gruppera entiteter inom ett ämnesområde. Det underlättar ofta läsningen och förståelsen av modellen.

Då använder jag ett liknande sätt att rita som för grupper av ämnesområden. Det vill säga att jag skapar en rubrik på en bred horisontell linje där linjen dras ut så den tydligt markerar vad gruppen omfattar. Det som omfattas är alltid en eller flera entiteter men kan även inkludera andra modellelement. Se bild III.

Bild III Exempel på gruppering av entiteter inom ett ämnesområde

Viktigt att vi identifierar och gestaltar meningsfulla strukturer

Jag menar att det är viktigt att vi identifierar meningsfulla strukturer i vår verksamhetsdomän, samt att vi gestaltar dessa i vår modell. På så sätt kan vi skapa en mer tydlig gemensam karta över vår data-/informationsresurs, de företeelser som hanteras och vår verksamhetslogik. Detta har ett stort värde för vår gemensamma förståelse och lärande, och därmed för verksamhetens hela hantering och utveckling.

Varning för övertro på industrimodeller.

Men se upp för att använda en generell struktur för alla verksamheter du stöter på. Det har många gånger gjorts försök i olika branscher att skapa generella strukturer som fungerar för en hel bransch. Men det är omöjligt att bedöma om en sådan struktur skulle fungera för ens egen verksamhet innan vi ens har förstått och kommit överens om vår egen struktur. Ty varje typ av verksamhet har sin egen struktur. Till och med verksamheter i samma bransch har ofta ganska olika sätt att hantera saker. Det kan bero på att de har lite annorlunda gränsdragning mot partners eller leverantörer. Eller att deras produkt- eller tjänstestruktur är annorlunda uppbyggd.

Tyvärr ser man ofta en övertro på så kallade industrimodeller. Man har grovt generaliserade strukturer för en hel bransch, och försöker tvinga alla i samma mall. Det skulle kanske fungera någorlunda om man såg till att förstå sin egen verksamhet på djupet, och i detalj, där det trixiga gömmer sig. Det vill säga om man modellerade först. Men det var ju det man hoppades slippa genom att köpa in en industrimodell.

Dock finns det mönster som återkommer både inom branscher och också tvärs över olika branscher. Men det är något annat. Det är sådant vi ska hålla utkik efter. Det är ett spännande och outforskat område som det skulle vara intressant att gräva mer i. Men det är inte alls samma sak som att tro att man bara kan applicera en industrimodell för sin egen verksamhet.
För att läsa mer om problemet med industrimodeller se artikeln: ”Varför en industrimodell är en dålig idé”

Hur gör du?

Nu har jag berättat hur jag gör för att strukturera modeller. Berätta gärna hur du gör. Kanske kan vi lära oss mer tillsammans? Hör av dig via LinkedIn eller mejl, peter.tallungs@irm.se.

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 24 mars. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

PS Vi har tyvärr varit tvungna att ta bort möjligheten att kommentera på artiklarna för en tid. Har du tankar om innehållet i artikeln som du vill dela? Välkommen att kommentera på vår linkedin där lägger vi ut en post vid varje publiceringstilfälle. Eller skicka ett mail till Peter Tallungs: peter.tallungs(at)irm.se

Tio tips för bättre gestaltning av en informationsmodell

Jag ger här några enkla tips om hur du kan göra dina informationsmodeller tydligare. Tipsen förändrar inte modellen i sig, det vill säga vad modellen säger, utan endast hur den säger det den säger.

I min föregående artikel ”Vi kan göra bättre modeller – Om gestaltning med grafik och text” påstod jag att vi kan göra modeller som bättre förmedlar allt det vi vill förmedla. Jag planerar en rad artiklar om detta. Som en rivstart kommer här en liten guide med tio praktiska tips på hur du på ett enkelt sätt kan få dina modeller att bli tydligare.

Startläget

Bild I. Före alla ändringar

Tänk dig att du har följande ER-diagram, se bild I. Tänk dig också att du är nöjd med vad diagrammet visar. Det är precis så du vill uppfatta de företeelser som hanteras i den domän du beskriver. Det vill säga följande:

  • Man har kunder som kan lägga beställningar av färdiga paket av produkter.
  • En beställning kan avse ett eller flera produktpaket, där man också väljer hur man vill ha respektive paket förpackat.

Jag tycker egentligen inte att detta ER-diagram är uppseendeväckande dåligt. Jag har sett värre. Men ändå, jag menar att det finns utrymme för förbättring.

Jag ska visa hur vi med enkla medel kan förbättra diagrammet, steg för steg. Vi ändrar inte själva modellen, det vill säga det som modellen uttrycker, vilka företeelser som hanteras och hur de är relaterade till varandra. Resultatet blir i varje steg samma modell fast med en ny gestaltning.

Steg 1: Identifiera och rita ut ämnesområden för att ge modellen en geografi

En modell blir mer begriplig om man delar in den i olika ämnesområden. Ett ämnesområde är en del av en modell med företeelser som hör samman på något sätt, och gärna beskrivs tillsammans.

När jag får ett ER-diagram i min hand så är alltid det första jag gör att försöka ringa in olika delar av diagrammet så att varje del bildar en sammanhängande helhet av saker som hör ihop. I denna modell tycker jag att Beställning och Beställningsrad hör tätt ihop eftersom beställningsrader är delar av en beställning. Sedan tycker jag att Produkt, Produktpaket och Förpackningsalternativ hör samman eftersom de tillsammans utgör det som kunder kan beställa. Till sist får Kund bli ett eget område. (Bild nedan)

Bild II. Ämnesområden inringade

Det här sättet att dela in en modell är inte någon exakt vetenskap. Det finns ofta flera alternativ. Men det finns ändå vissa principer som avgör vad som bör hamna i samma ämnesområde. I senare artiklar återkommer jag till det ämnet.

Rita nu grå rektangulära ytor, en för varje ämnesområde. Flytta entiteterna så att de hamnar på rätt plats. (Bild III)

Ge ämnesområdena beskrivande namn. Försök placera ämnesområdena så att ordningen får någon slags mening. Här tänker jag mig att vi å ena sidan har kunder (de vi erbjuder saker) och å andra sidan har erbjudanden (det vi erbjuder våra kunder). Mitt emellan har vi det som knyter ihop dessa två kategorier av företeelser nämligen de beställningar som är lagda av kunderna.

Lägg märke till ritsättet:

  1. Ämnesområdena ritas som ljusa grå ytor, med mellanrum emellan.
  2. Ämnesområden bildar tillsammans en rektangel.
  3. Namnen på ämnesområdena skrivs med fetstil och med en mörkt grå färg.

Tillsammans gör detta att ämnesområdena bildar en neutral bakgrund för diagrammet. Indelningen tillför inte komplexitet utan reducerar komplexitet. Detta är en grundprincip för en bra gestaltning. Hur vi fångar och tillför så mycket kunskap och mening till modellen som möjligt, utan att i onödan tillföra komplexitet.

När jag handleder elever i informationsmodellering och visar dem detta steg blir de alltid överraskade av hur mycket tydligare modellen blir redan av detta första enkla steg. Till och med en så enkel modell som denna blir mycket tydligare. Tänk då hur det blir med modeller som är mycket mer komplexa. Och det handlar inte bara om hur jag kan kommunicera modellen till andra. Även jag själv ser och förstår modellen tydligare. Modeller är som sagt inte bara ett kommunikationsverktyg utan också – egentligen först och främst när man tänker efter – ett tanke- och analysverktyg.

Bild III. Efter steg 1: Ämnesområden inritade

Steg 2: Byt versaler mot gemener

Det är välkänt att versaler ger sämre läsbarhet än gemener. De gäller inte bara löptext utan även rubriker och dylikt. Därför är det bättre att skriva allt med gemener, förutom inledande versal på namn. (Bild IV)

Steg 3: Rita relationslinjer med vinkelräta linjer

När man har många relationer och de behöver dras lång väg blir det tydligare om linjerna dras vinkelräta än om de går kors och tvärs. (Bild IV)

Steg 4: Böjda hörn på relationslinjerna

Böjda hörn är att föredra. En fördel är följande: Hjärnan letar hela tiden efter mönster i synimpulserna. Hjärnan behöver då skilja mellan olika typer av hörn. Om hörnen på relationslinjerna skiljer ut sig tydligt från hörnen på entitetsrutorna så kan vi avlasta den kognitiva funktionen.
(Bild IV)

Bild IV. Efter steg 2, 3 och 4: Namn skrivna med gemener, relationslinjer med vinkelräta linjer och böjda hörn
Bild V. Reltationslinjen från Payment Batch ansluter en annan relationslinje. Den runda böjen gör att man ser vilket håll den tar vägen.

Detta kan tyckas som en liten sak, och är kanske det. Men det är enkelt att åstadkomma och det ger en effekt.

En annan fördel med böjda hörn på relationslinjerna är följande: När man drar flera relationslinjer till samma mål kan man dra dem tillsammans. Om man då ansluter linjen med en böj så visar man vilket håll en anslutande linjen tar vägen. Se exempel, bild V

Steg 5: Byt princip för namngivning av relationer

Relationer mellan entiteter är egentligen också attribut hos entiteter, och bör benämnas med en verksamhetsterm. Om vi som exempel tar relationen mellan Beställning och Kund som i diagrammet heter läggs av, se bild 5. Det är ingen verksamhetsterm. Verksamhetstermen för relationen är lämpligen Beställare, och är inte bara en relation utan manifesteras som en egenskap hos enbeställning med samma namn.Det attributet kommer behöva beskrivas med namn, egenskaper och regler, i modellens textdel precis som andra attribut. Det kommer också att behöva representeras av något dataelement, kanske en kolumn i en tabell eller liknande.  

Därför anser jag att principen för att namnge en relation i ett ER-diagram bör vara en princip som fungerar inte bara i diagrammet utan också i övriga delar av modellen, samt i alla övriga sammanhang där relationen förekommer i verksamheten. En informationsmodell som kommer till användning i en verksamhet normerar ju ett verksamhetsspråk. Och Beställare är då en verksamhetsterm som vi bör definiera och beskriva i vår modell. Läggs av är inte på samma sätt en verksamhetsterm, den har ingen mening utanför detta diagram, och inte ens någon mening utanför den linje den är placerad på.

Jag vet att detta går emot det som brukar läras ut. Men om vi ska utveckla vårt kunskapsområde behöver vi vara beredda att ompröva ingrodda ”sanningar”.

Lägg också märke till att en relation, inte bara en entitet, alltid hör till ett visst ämnesområde. Beställare är en relation/egenskap hos en beställning och hör därmed till ämnesområdet Beställningar, och inte till Kunder. Därför bör relationslinjens etikett, namnet på relationen, alltid placeras hel och hållen inom ämnesområdet i diagrammet. (Bild 5)

Steg 6: Markera läsriktning för relationsnamn

Namnet på relationer är alltid avsedd att läsas i en viss riktning. Gör det tydligt med en lite pilspets som det visas i exemplet nedan, bild VI

Bild VI. Efter steg 5 och 6: Relationer namngivna med verksamhetsbegrepp och som egenskaper, och med läsriktning markerad

Steg 7: Lös upp många-till-många-relationer

Modeller blir tydligare om man uttrycker många-till-många-relationer som entiteter i sin egen rätt. Se entiteten Produkt i produktpaket i bild VII nedan.Lägg märke till namnet. Precis som övriga entiteter så bör man vara noga med att ge den ett namn som uttrycker vad en enskild förekomst av entiteten står för. En förekomst av den entiteten uttrycker ju fakta att en viss produkt förekommer i ett visst produktpaket.

Steg 8: Placera en entitet som är underställd en annan entitet under denna och med indrag

I exemplet nedan, bild VII, så är Beställningsrad underställd Beställning i den meningen att den förra är en del av den senare. Samma gäller för Produkt i produktpaket i förhållande till Produktpaket. Det framgår tydligt att de hör samman i en hierarki på det sättet om man placerar Beställningsrad och Produkt i produktpaket i diagrammet som jag har gjort, under och med ett indrag. Ofta har man flera underställda entiteter och ibland i flera nivåer. Då blir det ännu viktigare att vi tydligt visar hierarkin.

Lägg också märke till att jag fann det tydligare att bryta ut Produkt till ett eget ämnesområde. Detta eftersom man i detta fall inte erbjuder produkter till kunder annat än som ingående i paket. (Bild VII)

Bild VII. Efter steg 7 och 8: Många-till-många-relation upplöst. Underställda entiteter placerade för att uttrycka beroendet.

Steg 9: Skriv entiteternas definitioner i entitetsrutorna

Om man tar med definitionen i entitetsrutan så får läsaren en extra möjlighet att förstå vad entiteten står för. Definitioner är mycket centrala delar av en informationsmodell. Egentligen mer centrala än namnen. Namnen är viktiga som mentala ”etiketter”. Men det är definitionerna som uttrycker vad företeelserna i fråga är för något. (Bild VIII)

Bild VIII. Efter steg 9 och 10: Relationer som innebär komposition (beroendeobjekt) särskilt markerade. Definitioner i entitetsrutor.

Steg 10: Markera beroendeobjekt

Vissa relationer där en entitet är underställd en annan entitet innebär en starkare bindning än andra. Den underställda entitetens livscykel är då sammankopplad med den andra entiteten. Till exempel kan en beställningsrad inte existera utan att den hör till sin specifika beställning. Den kan alltså varken existera självständigt eller byta vilken beställning den är en del av. Det är en permanent relation. Det är en viktig egenskap hos relationen men den uttrycks inte av den vanliga 1–1-relationen. En vanlig min 1- max 1-koppling säger ju bara att beställningsraden alltid måste var knuten till precis en beställning, men inte att det alltid måste vara samma beställning. I en del notationer kallas det för beroendeobjekt.

Jag tycker att mina modeller blir tydligare om jag markerar vilka entiteter som hör samman på det här starka sättet. En beställning och dess beställningsrader är inte olika informationsobjekt, utan beställningsraderna är integrerade delar av en beställning med ett existentiellt beroende. Det vill säga att en beställningsrad inte kan existera oberoende av sin beställning.

Bild IX. Composition (beroendeobjekt) i UML

I UMLs klassmodeller kallas den relationen sammansättning (composition) och uttrycks med en romb. Egentligen ska romben vara fylld men den symbolen finns inte som standard i Visio så jag brukar nöja mig med en ofylld. (Bild IX)

Inom parentes sagt: Den ofyllda romben uttrycker i UML en mängd (aggregation), vilket i praktiken är samma som en vanlig association med en min 1 – max 1-koppling. Därför är symbolen tämligen meningslös i UML. Jim Rumbough, en av grundarna till UML, liknade den vid placebo och Martin Fowler ägnar en hel uppsats till att avfärda konstruktionen.

Jag har skrivit om detta tidigare, i artikeln ”Saker jag stjäl från UML”.

Vad har vi gjort egentligen

Lägg märke till att vi inte på minsta sätt har förändrat modellen, endast dess gestaltning. Diagrammet som det blev till slut uttrycker exakt samma modell som diagrammet gjorde från början, det vill säga vi har inte ändrat något i vår bild av vår förståelse av det som avbildats. Det vi har ändrat är endast gestaltningen, det vill säga sättet modellen säger det den säger.

Bild X. Från före alla ändringar till efter steg 9 och 10: Relationer som innebär komposition (beroendeobjekt) särskilt markerade. Definitioner i entitetsrutor.

Men jag menar att skillnaden är avsevärd. Jag vill på detta sätt visa hur vi med mycket enkla medel kan få till mycket bättre informationsmodeller. Det är därför jag tycker att det är så viktigt att vi börjar diskutera gestaltning av modeller och utveckla sättet vi gestaltar på. Målet för mig är inte att alla skall göra som jag. Pröva själv, på dina egna diagram. Se om du tycker att det blir någon skillnad. Min vilja är att vi kommer loss från den dogmatik och förstening som rått i några decennier nu, och att vi kan börja utveckla vårt område. Låt oss pröva olika sätt, låt oss diskutera och låt oss dela med oss.

De finns de som är rädda för en sådan öppenhet och frihet. De tycker att vi då visar oss som amatörer, att vi visar upp en tvekan, att vi inte alltid vet vad som är bäst, och att vi öppnar upp för anarki och oordning. Till dessa vill jag säga: Utveckling innebär alltid en viss oordning. Leve denna oordning! 

Fortsättningen

Du kanske har andra tankar om hur vi kan göra bättre modeller. Det är bra, låt oss få höra. Det är så ett område kan utvecklas.

Det kommer fler artiklar om gestaltning av modeller. Detta var bara en liten början, varje steg ovan går det att säga mer om och det finns andra områden av ämnet att diskutera, inte minst de delar av våra modeller som består av text.

Hoppas du vill hänga med på detta.

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 10 mars. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

PS Vi har tyvärr varit tvungna att ta bort möjligheten att kommentera på artiklarna för en tid. Har du tankar om innehållet i artikeln som du vill dela? Välkommen att kommentera på vår linkedin där lägger vi ut en post vid varje publiceringstilfälle. Eller skicka ett mail till Peter Tallungs: peter.tallungs(at)irm.se

Vi kan göra bättre modeller – om gestaltning med grafik och text

Jag påstår att vi arkitekter kan bli bättre på hur vi utformar våra modeller. Mycket bättre! Detta är introduktionen till en serie artiklar där jag kommer att ge mina råd om hur vi med hjälp av bättre grafik och strukturerad text kan få våra modeller att bära mer kunskap och bli mer effektiva tanke- och kommunikationsverktyg.

Modeller är våra viktigaste verktyg

Modeller är arkitektens viktigaste verktyg. Vi arkitekter – vare sig vi är informations-, verksamhets- eller it-arkitekter – är i grunden modellerare. En nestor i branschen sa en gång: ”Jag modellerar vad som helst, var som helst, i vilket sammanhang som helst”. Jag brukar tänka på det.

Modeller är på samma gång ett tanke-, analys och kommunikationsverktyg. De blir mycket kraftfulla verktyg om vi förstår att utforma och använda dem rätt. En modell kan, rätt utformad, bli till en samarbetsplattform för lärandet i en organisation. 

Modellering är ett hantverk

Det är ett hantverk att göra bra modeller. Det kräver kunskap, vana och handlag. Och för en hantverkare är verktygen allt, de är som en förlängning av kroppen, sinnena och hjärnan. En hantverkare behöver därmed hålla sina verktyg i gott skick, så att de är skarpa och precisa.

Låt oss göra det.

Gestaltning är viktigt

En modell står och faller med hur den är utformad, i grafik och text. Om den tydligt förmedlar det som modelleraren vill förmedla, om den är krispigt klar, då gör den sitt jobb. Oavsett om den är en sann och användbar representation av det som modelleras, egentligen. Ty om modellen är tydlig går innehållet alltid att kritisera och förbättra. Den är lika mycket en fråga som ett påstående: ”Kan vi se det så här?”. Och frågor är minst lika viktiga som påståenden.

Om modellen inte är tydlig går idéinnehållet egentligen inte ens att kritisera. Ty det som man inte kan förstå kan man inte heller kritisera. Därför är det oerhört viktigt hur vi ritar våra modeller. Hela vårt yrke och yrkesområde, både som individer och som yrkesgrupp, står och faller med detta. Fast inte bara hur vi ritar. Modeller bör ha text också, och vi bör integrera grafik och text så att det bildar en helhet. Därför vill jag hellre säga gestalta och inte rita trots att grafiken har en framträdande roll.  

Hur står det egentligen till där ute?

Om man googlar på ”informationsmodell”, ”datamodell” eller liknande får man upp många olika exempel på diagram. Bilden som inleder denna artikel visar några slumpvisa träffar. Jag har inte valt ut vare sig bra eller dåliga exempel, utan bara det jag tycker kan vara representativt för hur det ser ut i våra verksamheter.

Jag tycker inte att man i något av dessa exempel, eller andra man kan hitta när man letar, har lyckats få modellerna att kommunicera på ett effektivt sätt. Vi kan göra mycket bättre, och det med enkla medel.

Hur ska man då göra?

Det finns inte mycket skrivet om hur man gestaltar modeller, och det lilla som är skrivet brukar vara upp åt väggarna enligt mig. Det är en stark åsikt och jag kommer att motivera den. Och inte bara motivera utan även visa på bättre sätt i de artiklar jag planerar att skriva framöver.

Det gäller inte bara informationsmodeller utan även andra modeller inom it- och verksamhetsarkitektur, så som förmågekartor, systemkartor, processmodeller med flera.

Låt oss bli bättre – tillsammans! 

Jag har i ett par decennier arbetat med att försöka utveckla hur man kan rita och skriva, för att göra bättre modeller. Jag har varit nyfiken på hur man gör inom andra yrkesområden där man gör modeller, ritningar, kartor och grafik i största allmänhet. Det jag lärt mig har jag sedan prövat att tillämpa på vårt område, i första hand informationsmodeller samt förmåge- och systemkartor. Och jag vill påstå att jag funnit sätt att rita och skriva, samt kombinera grafik och text, som jag menar har potential att lyfta hela vårt område. För om vi kan göra tydligare, skarpare och mer informativa modeller så kan vi bli mycket mer relevanta för våra organisationer.

Det betyder inte att jag vet och kan allt. Du kanske också har något att bidra med. Du har kanske andra insikter. Det är värdefullt om du då delar med dig. Så att vi tillsammans kan utveckla hela vårt område.

Exempel från ett helt annat område

Som en liten inledning vill jag visa ett mycket enkelt och vardagligt exempel från en helt annan bransch. Det är det elektriska kopplingsschemat till elsystemet på en bil, en Nash Ambassador från 1957. Det kanske inte är något märkvärdigt, det är så kopplingsscheman brukar ritas. Men ändå. Jag tycker att det finns så mycket klokskap och skicklighet i den grafiska gestaltningen som man kan begrunda och bara måste beundra. 

Lägg till exempel märke till följande:

  • Begränsningar: Tänk först på de begränsningar man hade: inget färgtryck samt begränsat utrymme.
  • Geografin i schemat: Titta sedan på hur man ordnat geografin i schemat. Längst upp har vi framlyktorna, sedan motorutrymmet med tändspole, fördelardosa och batteri. instrumentpanelen hittar vi långt ner på ritningen med alla strömbrytare och instrument. Baklyktorna ser vi längst ner. Hela ritningen är alltså utlagd schematiskt efter var i bilen respektive komponent sitter. Komponenterna är ordnade i grupper som är tydligt avgränsade från varandra. Man kan naturligt och utan ansträngning orientera sig i ritningen i förhållande till bilen i verkligheten.
  • Symboler: De olika komponenterna har symboler som är lätta att känna igen eftersom de avbildar komponenten ifråga symboliskt. Så länge man vet något om bil-el kan man mer eller mindre automatiskt känna igen komponenterna och behöver ingen symbolförklaring. Eller i varje fall, när man har stött på dem en gång är det lätt att erinra sig vad de står för nästa gång.
  • Linjer: Alla ledningar ritas som linjer, men de som går mellan batteri, laddningsrelä och generator är kraftigare. De representerar kraftigare kabel som ska klara starkare ström. Kabeln till startmotorn är på liknande sätt lite mittemellan i grovlek. Grovleken på linjen symboliserar hur grov kabeln är.  Linjerna är dragna med räta vinklar och ”hopp” där de korsar varandra. Linjer som ska till samma ställen är dragna tillsammans som grupp.
  • Ordning: Symboler, linjer och texter är placerade med raka marginaler. Hela diagrammet bildar en rektangel med raka marginaler.

Jag har försökt tänka hur man ska kunna förbättra kopplingsschemat ovan, men har inte hittat något sätt. Det är helt enkelt perfekt. Idag har vi förstås färgtryck, vilket skulle vara en fördel. Men i övrigt?

När jag ser vad man gjort inom detta och andra områden med grafik och gestaltning blir jag lycksalig, imponerad och ödmjuk. Det finns så mycket kunskap om hur man gestaltar ritningar och modeller inom olika yrkesområden. Det finns så mycket att lära sig av.

Varför har vi inte lärt oss?

Men varför är det så bristfälligt inom vårt område? Det vill säga allt som har med it- och verksamhet att göra. Varför har vi inte lärt oss?
Du som läser detta, tror du inte att vi inom vårt område skulle kunna bli lika bra på att gestalta med grafik och text som i andra branscher? Eller är det så att just vårt område är så omöjligt, att vi har en omöjlig uppgift? Vi kan i varje fall inte skylla på att vi är i en ung bransch. Verksamhets- och it-arkitekter har funnits i någon form i minst ett halvsekel. För mig är det en gåta. Hur har vi kunnat undgå att inte lära oss med tiden? Vad har hållit oss tillbaka? Jag vet inte, men jag tycker att vi nu har ett ansvar att bli bättre.

Hur blir vi bättre?

Vad kan vi då göra för att bli bättre? Jag vill i varje fall dra mitt strå till stacken. Jag kommer i en rad av artiklar framöver stegvis gå igenom det jag kommit fram till, med exempel och motiveringar. Några saker är kanske självklara för läsaren, några är kanske nya. Några är kanske kontroversiella i det att de motsäger sådant som annars brukar läras ut. Men jag tror verkligen att du, om du läser, begrundar och provar det som sägs kommer att utvecklas som modellerare och arkitekt.

Du behöver inte ens hålla med om allt, och det är ok. Men du kommer att bli tvungen att reflektera över hur du gör och varför.

Jag hoppas också att du vågar och vill kritisera mina råd. Det kan ju inte vara så att det bara är jag som har kunskap inom området. Eller att det jag säger är den slutgiltiga visdomen inom området. Min önskan är att fler vill bidra.

Det mesta jag kommer att skriva om framöver är mer eller mindre tillämpligt på alla slags modeller, och ibland till och med på alla slags grafiska representationer. Men en del konkreta råd gäller specifikt för informationsmodeller.

Mitt hopp är att det finns läsare som blir nyfikna på att utvecklas, som blir inspirerade till att experimentera och förbättra sina modeller i detta avseende. Det är det jag vill, så ett frö till en renässans inom området.

Vad jag kommer att beröra

Följande är en preliminär och grov plan över vilka ämnen jag kommer att ta upp i artikelserien.

  • Disposition:
    Hur vi placerar elementen i förhållande till varandra på diagrammet så att vi förmedlar vilken relation företeelserna har till varandra.
  • Struktur:
    Hur vi ger diagramytan en struktur som förmedlar hur vi ser på relationen mellan företeelserna.
  • Övergripande struktur:
    Hur vi kan ge hela modellen en meningsfull övergripande struktur.
  • Fokus:
    Hur vi lyfter fram centrala element.
  • Linjer:
    Hur vi drar relationslinjer så de blir tydliga och inte stör.
  • Namn:
    Hur vi benämner företeelserna och placerar namn.
  • Definitioner:
    Hur vi skriver definitioner och använder definitioner i diagrammet.
  • Verksamhetsregler:
    Hur verksamhetsregler har sin naturliga plats i informationsmodellen.
  • Färg:
    Hur vi använder färg.
  • Gråskalor:
    Hur vi använder gråskalor.
  • Samverkan tex och grafik:
    Hur vi får grafik och text att samverka.
  • Informationstäthet:
    Hur vi får våra modeller att förmedla allt vi behöver förmedla.
  • Diagramtyper:
    Hur vi kan utöka vår verktygslåda med fler diagramtyper.
  • Rika informationsmodeller:
    Hur vi kan få informationsmodeller att bära mycket mer kunskap och spela en mer central roll i en verksamhet.

Nästa artikel blir en rivstart.
Hoppas du vill hänga med! Om du har tankar kring detta – mejla mig: peter.tallungs@irm.se

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 3 mars. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

PS Vi har tyvärr varit tvungna att ta bort möjligheten att kommentera på artiklarna för en tid. Har du tankar om innehållet i artikeln som du vill dela? Välkommen att kommentera på vår linkedin där lägger vi ut en post vid varje publiceringstilfälle. Eller skicka ett mail till Peter Tallungs: peter.tallungs(at)irm.se