Taggarkiv: Modellmönster

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

Om den storskaliga skiktningen av en modell

Föregående artikel, Strategimönster för informationsarkitekter del 5 – Den storskaliga strukturen, handlade om själva processen att få till en bra storskalig struktur för sin informationsmodell. Ett av strategimönstren i artikeln hette ”Skiktning av modellen efter ansvar”.

Frågan blir då: Hur ska då en sådan skiktning se ut? Det finns inte ett svar på den frågan som fungerar för alla modeller, men det finns vissa mönster som ofta framträder då man betraktar domäner lite djupare, det vill säga då man modellerar. Låt mig beskriva några av dessa.

Inom arkitektur och ingenjörskonst, av vad slag det månne vara, finns det några verkligt grundläggande mönster som utgör själva basen i hur en arkitekt eller ingenjör kan tänka. Det handlar om hur man på ett logiskt sätt kan strukturera sin värld. Man behöver skapa någon slags ordning, hitta en struktur för att hantera den komplexitet som finns där. En ordning som hjälper oss att förstå och förklara. Ett sådant grundläggande mönster är hur saker och ting är ordnade i komponenter som är någon form av företeelser som var och en är tydligt avgränsade från varandra. Ett annat grundläggande mönster, det som vi här ska beröra, är att dessa komponenter på något sätt kan ordnas i skilda skikt, eller lager, som tänkes placerade över varandra. Vi kan kalla det för en skiktad arkitektur.

Vi har alltså två mycket grundläggande mönster. Dels hur man ordnar det man ska analysera eller designa i komponenter av något slag. Dels hur man sedan kan ordna dessa komponenter i skikt.  Man skulle kunna kalla dessa för supermönster eftersom de är så grundläggande för vår förståelse och överallt förekommande och användbara.

Vi kommer här att gå igenom vad en skiktad arkitektur innebär, först med exempel från helt andra områden än informationsmodellering, sedan vad det kan betyda för en informationsmodell.

Vad är en skiktad arkitektur?

Som sagt tänker man sig att komponenterna är ordnade i två eller flera skikt. Ett skikt längre ner förutsätts vara mer stabilt än det skikt som är över, det vill säga ha en långsammare förändringshastighet. Alla komponenter i ett visst skikt utgör tillsammans ett ”språk” och en bakgrund som komponenterna i det skikt som är över detta får mening av. Komponenterna i ett visst skikt har ett beroende till komponenter i det skikt som är direkt under sig, samt kan ha beroenden till andra komponenter i det egna skiktet. Däremot får de inte vara beroende av komponenterna i något skikt över sitt eget. Det är själva kärnan i tänkandet, att beroendena inte går hur som helst utan strikt i ena riktningen.

Det finns sedan två varianter av skikt; ”Strict layering” där komponenterna bara känner till och använder komponenter i skiktet direkt under sig (vid sidan av komponenter i det egna skiktet), samt ”relaxed layering” där komponenter även kan använda komponenter i skikt längre ner än det skikt som är direkt under.

Skiktning på detta sätt, ibland strikt, ibland mindre strikt, har tillämpats så gott som överallt där människor tänkt ut eller konstruerat saker. Det är detta som gör det till något av ett supermönster. För att ge en känsla för vad en sådan skiktning innebär, generellt sett, ger jag här några exempel från helt andra områden än informationsarkitektur.

Exempel 1 på skiktad arkitektur: Byggnadsarkitektur

En byggnad kan ses som att den har flera skikt som kan placeras längs en skala efter förändringshastighet:

  • Platsen där byggnaden är placerad (ca 100–1000 år).
  • Grund och stomme (ca 100–300 år).
  • Ytter- och innerpanel samt takbeklädnad
    (ca 50–100 år).
  • Installationer, dvs värme, vatten, avlopp, elektricitet (ca 40–60 år).
  • Ytskikt: Färg, tapeter (ca 10–30 år).
  • Inredning: Möbler, tavlor (ca 5–25 år).
  • Dekoration: Blomvaser, dukar (ca 1–30 dagar).

Här är det tydligare att prata om ett inre och yttre skikt, än ett undre och övre. De innersta lagren är det som sitter djupast i väggar, golv och tak och de yttersta det som sitter utanpå väggarna, på insidan eller utsidan. Vi ser att de olika lagren har mycket olika förväntad förändringshastighet. Därmed är det naturligt och mycket lämpligt att de som är mer snabbrörliga har ett beroende till de som är trögare, och inte vice versa. Samt att lagren hålls strikt åtskilda så beroendet är enkelt och lättförändrat.

Annars blir det problem. Till exempel om man gör möblerna väggfasta. Jag lade en gång ner en stor möda på att göra en mysig väggfast säng till min dotter, perfekt för den 10-åring hon var då. Men när hon blev femton och rummet blev till ett hang out för tjejgänget blev sängen pinsam, så jag fick riva.

Där bröt jag mot regeln att något (i detta fall en säng) som tillhör ett ganska snabbrörligt skikt inte bör ha för komplicerade beroendet till ett mera trögrörligt skikt (väggen).

För att inte tala om när våra hantverkare gjöt in elkablarna i betongen i källarväggarna!

Exempel 2 på skiktad arkitektur: Programvaruarkitektur

It-arkitekturer är nästan alltid skiktade på liknande sätt, vare sig det är arkitekturen i en specifik programvara eller det är den övergripande uppbyggnaden av applikationer eller tjänster i en verksamhet.

Men jag upplever att man inte så ofta har tänkt på varför man gör så, att det ytterst handlar om förväntad förändringshastighet och – sammankopplat med detta – var förändringskrav emanerar från.

Exempel 3 på skiktad arkitektur: Kommunikationsprotokoll

Kommunikationsprotokoll, det vill säga standarder för hur vi kommunicerar i olika sammanhang är alltid skiktade på liknande sätt.

Hur kan vi skikta en informationsmodell?

När vi tar fram en större informationsmodell behöver vi ge den någon slags övergripande struktur så att den blir begriplig och hanterbar. Först och främst behöver vi dela in den i sammanhängande ämnesområden. Det blir det vi kan se som våra komponenter i detta sammanhang. Sedan behöver på något sätt organisera dessa ämnesområden. Då kan det vara en idé att använda supermönstret ”Skiktad arkitektur”.

Men vad ska denna skiktning baseras på? Det är just detta den här artikeln vill hjälpa till med. Jag tror inte att det finns ett enda universellt svar som fungerar i alla verksamheter, men det finns vissa mönster för detta som ofta framträder då vi betraktar olika verksamheter. Låt mig beskriva några av dessa.

Strukturmönster 1: Skiktning i Tillgångar och Operationer

En del verksamheter är baserade på att exploatera fasta tillgångar som till exempel maskiner, fastigheter, fordon eller fartyg. Då kan man organisera informationsmodellen i följande två skikt:

  • Tillgångsskiktet (Capability layer eller Potential layer)

Tillgångsskiktet uttrycker vilka tillgångar och resurser som finns och vad som kan göras med dessa. Även personal och hur den är organiserad hör hit, likaså kontrakt med leverantörer, i de fall de kan betraktas som stabila.

Detta skikt kan man hitta i nästan varje verksamhetsområde, men det är mer framträdande i verksamheter som transport och tillverkning som har stora fasta kapitalinvesteringar (anläggningstillgångar) som möjliggör affären.

Skiktet innefattar också omsättningstillgångar (tillgångar avsedda för omsättning eller förbrukning), men verksamheter som drivs främst genom omsättningstillgångar bör i stället välja skikt som tydliggör detta.

  • Operationsskiktet (Operation layer)

Uttrycker vad som verkligen görs. Vilka aktiviteter som gjorts och vad som sålts.

Operationsobjekt refererar typiskt tillgångsobjekt, men ett tillgångsobjekt kan aldrig referera ett operationsobjekt. Vi får därmed en skiktning där tillgångsskiktet är ett undre skikt och operationsskiktet ett övre.

I de flesta fall i denna typ av verksamheter kan det räcka med ett tillgångs- och operationsskikt för att täcka allt på ett bra sätt. De rymmer både en beskrivning av den nuvarande situationen och aktiva operativa planer liksom händelserapportering.

Men ibland kan det finnas behov av ett till skikt, vilket presenteras i det följande.

Strukturmönster 2: Beslutstödsskikt (Descision Support layer):

Att bara spåra och rapportera vad som händer räcker inte för alla verksamheter. När modellen ska stödja beslutsfattande på ett mer genomarbetat sätt kan man tala om ett ytterligare skikt ovanför operationsskiktet; beslutstödsskiktet

Skiktet är till för analys av verksamheten och beslutstöd. Det baserar sin analys de lägre skikten, det vill säga tillgångs- och operationsskikten. Beslutsstödsystem använder historisk information för att aktivt söka möjligheter för nuvarande och framtida operationer.

Sammanställande beskrivning av de olika skikten så här långt

Här kommer en sammanställning av de tre möjliga skikt vi hittills tagit upp.
Observera att det som skiljer skikten inte bara är förändringshastigheten hos strukturerna i sig utan även, och kanske främst, tillståndsförändringar hos företeelserna i skiktet, vilket avspeglas i volatiliteten hos data.

Utöver de skikt vi nu har gått igenom kan det kanske i vissa speciella fall finnas fog för ett par mer udda skikt. De nämns i det följande.

Strukturmönster 3: Policyskikt (Policy layer)

Ett skikt skulle kunna vara för att hantera övergripande mål och regler. Det vanliga och mer lämpliga är att man lägger de regler som beskriver ett visst objekt i samma del av modellen som objektet självt. Men i vissa fall skulle man kanske kunna tänka sig regler som spänner tvärs över hela modellen. I så fall kan man behöva ett policyskikt.

Jag tror dock att det är mycket ovanligt att man vill ha med den typen av regler i en informationsmodell. Policyskiktet uttrycker regler och mål som spänner över hela verksamheten och som styr och begränsar beteendet i andra skikt. Den typen av allomspännande regler räknas inte till det man kallar verksamhetregler och hör därmed egentligen inte hemma i en informationsmodell. Jag kommer att ta upp detta med verksamhetregler i senare artiklar i denna serie.

Strukturmönster 4: Kundförbindelseskikt (Comittments layer)

Kundförbindelser uttrycker vad vi lovat. Det kan vara av mycket olika art och därmed motivera olika placering. De kan ibland vara av en art som liknar policys när de utrycker mål som styr framtida operationer. Men de kan också likna saker i operationsskiktet i det att förbindelser uppstår och förändras som en del av den pågående affärsaktiviteten. Kundförbindelser kan också i en del fall, då man har långa och varaktiga åtaganden mer eller mindre ersätta tillgångar. Det innebär att de kan finnas i ett eller flera av de andra skikten. Men ibland kan det kanske vara motiverat med ett särskilt skikt.

Var hamnar ett Policyskikt eller ett Kundförbindelseskikt i skiktningen?

Jag är mycket osäker på var dessa extra skikt hamnar i en skiktning, det vill säga om man kan säga något bestämt som alltid gäller om hur beroendena går mellan dessa och de övriga skikten. Jag tror att det beror på typen av verksamhet. I vilket fall bör man bestämma hur beroendena ska tillåtas gå. Om beroendena får gå hur som helst har man i realiteten ingen skiktning.

Skikt i en annan mening: Regelplan i modellen

Jag har i artiklarna om modellmönster tagit upp hur användbart det är att skikta en del av en modell, det vill säga ett ämnesområde, i ett operativt plan och ett regelplan. Det är en skiktning som inte får förväxlas med den storskaliga skiktningen i denna artikel. Den skiktningen verkar i en mycket mindre skala, det vill säga inom ett ämnesområde.

Inte bara för informationsmodeller

Ovanstående mönster är tillämpliga inte bara för informationsmodeller utan även i kanske ännu högre grad för förmågekartor och liknande. Det är ju i grunden ett sätt att gruppera och hantera alla förmågor i en verksamhet.

Vilka övergripande strukturer har du tillämpat?

Jag tycker att detta med strukturmönster är oerhört intressant och något jag skulle vilja utveckla än mera. Det finns nog fler mönster för hur man kan strukturera en informationsmodell. Hur har du gjort och hur har det fungerat?

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 3 februari. 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

Strategimönster för informationsarkitekter – del 4: Destillering av kunskap

Destillering är processen för att separera essensen från en blandning, och få den i en form som gör den mer värdefull och användbar. Informationsmodellering kan vi se som destillering av kunskap. Kunskap om de företeelser som verksamheten hanterar och hur de hanteras. Men vi kan behöva destillera vidare, ytterligare lyfta fram det som är viktigast i domänen. I följande artikel presenterar jag strategimönster som kan hjälpa oss med detta.

När man modellerar en domän, till exempel en verksamhetsfunktion eller ett it-system, så finns det saker i modellen som utgör själva essensen, det som är mest centralt och som är själva nyckeln till förståelsen av domänen. Denna essens, denna nyckelförståelse är, skulle jag vilja påstå, det som egentligen är verksamhetens viktigaste tillgång.

Men när man modellerar finns det alltid många olika saker som behöver hanteras. Därmed är det lätt att essensen kommer ur fokus, inte får den framträdande roll som den borde ha, och försummas.

Det finns flera orsaker till att det sker, bland andra de två följande.

  1. Behovet av specialisering
    En orsak är de specialiserade roller vi ofta måste ha i utvecklingsarbete. När en it-utvecklare rör sig utanför den del av systemet denne är välbekant med går hen lätt vilse i begreppen. Detta tvingar utvecklare att specialisera sig. När så var och en begränsar sitt arbete till specifika funktioner stryps kunskapsöverföringen mellan dem ytterligare. Isoleringen ökar därmed, vilket blir en ond spiral.
  2. Tendens till dragning mot teknik
    Det finns en tendens att erfarna it-utvecklare drar sig från kärnan av domänmodellen och mot den mer tekniska infrastrukturen, eller mot något tydligt avgränsat problem som kan förstås utan specialiserad domänkunskap. Ty detta är vanligen ett mer intressant område för en tekniskt intresserad och uppfattas också som att det ger färdigheter som är användbara i andra projekt och ser bra ut i ett cv.

Vi bör prioritera domänkärnan

Allt detta gör att domänkärnan ofta inte får den uppmärksamhet som den skulle behöva. I praktiken kan kanske inte alla delar av modellen hållas lika snygga. Vi måste då prioritera. För att göra domänmodellen till en tillgång måste vi framför allt se till att den kritiska kärnan i modellen bibehåller sin elegans och användbarhet.

I det följande presenterar jag fyra strategimönster som kan hjälpa oss att lyfta fram och förtydliga essensen i en modell.

Mönster 1: Domänkärnan (Core Domain)

Problem: Den specialiserade kärnan i domänmodellen, den viktigaste delen av modellen, det som verkligen gör modellen till en affärstillgång hanteras ofta styvmoderligt. Bland it-utvecklare är det vanligt att ny teknik och avancerade algoritmer ses som det viktiga. Datastrukturerna och begrepp ses som tråkiga och oviktiga och överlåts vanligen på en junior utvecklare, som får jobba tillsammans med en databasadministratör för att skapa ett databasschema.

Dålig design eller implementation av denna del av programvaran leder till att applikationen aldrig klarar av att göra viktiga saker för användaren. Och då spelar det ingen roll hur elegant infrastrukturen är.

Lösning: Koka ner modellen. Hitta domänens kärna och separera den från massan av modellen. Lyft fram de mest värdefulla och speciella begreppen. Håll kärnan liten. Domänkärnan är den del av modellen som särskilt tydligt representerar verksamhetsdomänen och som på bästa sätt löser de uppgifter som systemet ska lösa.

Sätt de skickligaste teammedlemmarna på kärnan och rekrytera enligt denna princip. Lägg kraften på kärnan för att hitta en djup modell. Utveckla en smidig design för denna – tillräcklig för att tillgodose visionen med systemet. Motivera investeringar i övriga delar av modellen efter hur de stödjer den destillerade kärnan.

Vem gör jobbet?

De utvecklare som är de skickligaste rent tekniskt är ofta inte så intresserade av den specifika verksamheten. Det begränsar dem i detta sammanhang och förstärker deras dragning till infrastruktur. De kan då inte bygga domänkunskap, och vi får en ond cirkel.

Vi behöver sätta samman teamet på följande sätt:

  • Utvecklare som är beredda till långvarigt engagemang och är beredda på att vara bärare av domänkunskap
  • En eller flera domänexperter som har djup kunskap om sin verksamhet
  • Informationsarkitekt, som faciliterar samverkan mellan dessa och aktivt arbetar med att förfina modellen.

En väldestillerad domänkärna är en tillgång som ger snabbhet, lättrörlighet och precision.
Första iterationen av ett utvecklingsprojekt bör alltid baseras på någon del av domänkärnan.

Men det här verkar jobbigt, säger kanske någon. Kan vi inte köpa ett standardsystem i stället, eller åtminstone en standardmodell? Reality check: Domänkärnan kan förmodligen inte köpas. Industrispecifika modellramverk har hitintills alltid misslyckats.

Mönster 2: Generiska subdomäner (Generic Subdomains)

Problem:Det finns alltid delar av en modell som ökar komplexiteten i modellen utan att egentligen fånga eller kommunicera någon specialiserad kunskap. Allt sådant sidoordnat i modellen drar uppmärksamheten från domänkärnan, vilket gör det svårare att uppfatta och förstå det som är centralt.

Modellen slammar igen av allmänna principer som alla känner till ändå, eller detaljer som bara har en stödjande roll. Men de kan ändå inte tas bort eftersom de behövs.

Lösning: Identifiera sammanhängande subdomäner som behövs men som inte är de som utgör motiveringen för projektet. Faktorera ut dessa till andra generiska modeller. Gör dessa så allmänna så att inga spår är kvar av den speciella situationen i dem. De blir kandidater till återanvändbara tillgångar.

En generisk subdomän kan bli en återanvändbar tillgång på två sätt:

  1. Återanvändning av programvaran
    Ni kan göra en egen programvarukomponent som kan återanvändas av andra. Detta skall dock inte vara din prioritering eftersom du skall rikta så mycket kraft åt kärndomänen som möjligt, inte bli en leverantör av generiska komponenter. Det är ju kärndomänen som är viktig.
  2. Återanvändning av modellen
    En viktig form av återanvändning som ofta har hamnat i skymundan, både internt i våra organisationer och i branschen/samhället i stort, är återanvändning av modellen. Här finns mycket att göra för oss. Ett sätt är att vi publicerar och diskutera modellmönster inom vår Community. Ett annat sätt är att vi publicera hela modeller, som exempel på hur man har gjort, med kommentarer.

Mönster 3: Domänens vision (Domain Vision Statement)

Problem: Vi behöver skapa och förmedla en gemensam bild av den centrala idén med domänen.

Lösning: Skriv en kort beskrivning (ungefär en sida) av domänkärnan och det värde den kommer att bidra med. Ta endast med sådant som utskiljer denna domänmodell från andra. Visa hur domänmodellen tjänar och balanserar skilda intressen. Skriv visionen tidigt och revidera den när du vinner ny insikt. Det är ungefär detta du skulle säga när du ska beskriva vad som är det speciella med verksamhetsfunktionen eller applikationen som modellen beskriver.

Exempel: Vision för Flygbokningssystemet

  • Passagerarnas prioriteringar ska balanseras mot flygbolagets bokningsstrategier
    Systemet ska kunna representera passagerarnas prioriteringar och bokningsstrategier och balansera dessa mot varandra baserat på flexibla regler.
  • Modellen av en passagerare skall avspegla den relation som flygbolaget strävar efter att utveckla med återkommande kunder.
    Därför skall modellen representera passagerarens historik i en användbar kondenserad form, deltagande i speciella program, anknytning till strategiska företagskunder och så vidare.
  • Användarroller
    Användarnas olika roller (som passagerare, agent, ledningsperson) tillhandahålls för att kunna föda säkerhetssystemet med nödvändig information.
  • Modellen skall stödja effektiv rutt/sittplats-sökning
  • Modellen ska möjliggöra integration med andra etablerade flygbokningssystem.

Mönster 4: Framhävd kärna (Highlighted Core)

Problem: Vi behöver skapa och förmedla en gemensam förståelse av domänkärnan, det vill säga de viktigaste strukturerna i modellen.

Lösning: Ta fram ett destillationsdokument (Distillation Document) på 3–7 sidor som beskriver och förklarar domänkärnan. Det kan innehålla följande:

  • En lista på de viktigaste entiteterna
  • Diagram som visar deras viktigaste relationer
  • En genomgång av deras viktigaste interaktionsmönster, antingen på abstrakt nivå eller med exempel.

Dokumentet ger en bred vy av hur bitarna passar ihop. Dokumentet skall vara läsbart för icke-tekniska personer och vara avgränsad till det som alla inblandade behöver veta. Använd det som en gemensam vy och en guide med vilken alla nya teammedlemmar kan starta.

Destillationsdokumentet fungerar som en gemensam förankring. Det är viktigt att det står klart för teamet vilken stor betydelse en ändring av domänkärnan innebär. En ändring av domänkärnan innebär en förändring av teamets gemensamma syn på domänens centrala begrepp och beteende.

Använd destillationsdokumentet som en indikator. Om en ändring i modellen gör att destillationsdokumentet behöver uppdateras för att vara i synk med modellen behövs en överläggning. Antingen har det skett en fundamental ändring av något element i domänkärnan eller då har domänkärnans gräns flyttat på sig.

Det är då nödvändigt att sprida den förändrade bilden till hela teamet, inklusive att dela ut den nya versionen av destillationsdokumentet till alla inblandade.

Källan till dessa strategimönster

Strategimönstren i denna artikel är hämtade från Eric Evans bok ”Domain Driven Design”. Jag tycker att de är så kloka så jag vill gärna lyfta fram dem till en bredare krets än de få som kommit så långt i hans bok. Jag har här översatt och tolkat dessa. För de som vill gå till originalen har jag skrivit Eric Evans namn på mönstren inom parentes.

/Peter Tallungs, IRM

Nästa artikel i serien på temat informationsarkitektur publicerar vi torsdag 20 januari 2022. 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

Strategimönster för informationsarkitekter – del 3: Modellens avgränsade kontext

Vilka informationsmodeller ska vi ha för ett visst område? Skall det vara en enda mycket bred modell eller flera som var och en är mer avgränsade? Hur långt ska en viss modell sträcka sig? Var ska vi låta gränsen till omvärlden gå? Låt oss se hur man kan resonera. Denna artikel handlar om hur man kan tänka för att bestämma vilken avgränsning en modell ska ha.

Först går jag igenom ett par allmänna principer om hur man kan tänka när man avgränsar kontext för en modell. Sedan går jag igenom fyra typiska fall och ger några praktiska råd. Råden är liksom i de tidigare artiklarna om modelleringsstrategi delvis baserad på Eric Evans tankar om strategi ur boken ”Domain Driven Design”.

Allmänna principer: Hur smal eller bred ska en modells kontext vara?

En modell har alltid en viss kontext. Den kan vara bred eller smal. Men hur ska vi avgöra om vi ska göra en bred modell som täcker mycket, eller flera smala som var och en är avgränsad till ett delområde?

Observera att jag här menar modell och inte modelldiagram. Det är viktigt att vi inte blandar ihop detta. En modell kan ofta behöva delas upp i flera diagram, men det är likafullt samma modell, så länge den har samma avgränsade kontext och är konsistent inom detta.

Hur omfattande en modell ska vara är en bedömningsfråga som till stor del handlar om intuition, det vill säga kunskap som vi har men som vi inte riktigt kan utrycka på annat sätt än som vad som känns rätt. Men vi kan i varje fall peka ut några faktorer som talar för en bredare kontext, och andra som talar för en smalare.

Det som talar för en bredare kontext:

  • En verksamhetsprocess går smidigare att implementera när den hamnar inom en enhetlig modell. Det är lättare att greppa en modell än två olika, samt att vi då även måste hantera mappningen däremellan.
  • Översättningen mellan de olika modellerna kan bli svår (och ibland till och med omöjlig).
  • Ett gemensamt språk ger tydlig kommunikation.

Det som talar för en smalare kontext:

  • Modellen blir enklare, vilket medför att kommunikationen mellan personer blir enklare, så länge man håller sig inom modellens kontext.
  • Enklare modellering, ty bredare modeller behöver vanligen bli mer abstrakta för att täcka fler alternativ.
  • Den kontinuerliga integreringen blir enklare. En smalare kontext betyder färre direkta intressenter med mer likartade behov som man behöver täcka.
  • Med separata modeller för olika intressenter kan man bättre tillgodose specifika behov och även specifika jargonger hos specialiserade grupper.

Allmänna principer: Var dra gränsen mellan flera avgränsade kontexter?

Då man delar en domän till två separata modeller, det vill säga två olika avgränsade kontexter, är det viktigt var man placerar gränsen mellan modellerna. Målet är att beroendet mellan modellerna blir så litet, enkelt och tydligt som möjligt. Då behöver vissa modellelement hamna på samma sida om gränsen.

Det som talar för att två modellelement bör hamna i samma avgränsade kontext, det vill säga i samma modell är följande:

  • Elementen hör samman på ett naturligt sätt.
  • Elementen brukar ofta refereras tillsammans.
  • Elementen har många och djupa kopplingar till varandra. Särskilt om sambanden är dubbelriktade.
  • Informationen i de två elementen ägs av samma verksamhetsfunktion.

Observera att det här egentligen går tillbaka på mycket generella principer för hur vi ordnar saker i största allmänhet. De gäller för alla typer av avgränsningar vi gör och kan göra. Till exempel när vi placerar saker i olika byrålådor, eller hur vi sorterar dokument i olika mappar. Eller då vi delar en modell i olika ämnesområden, men det fortfarande ändå ser det som samma modell.

Ett sammanhang där jag som informationsarkitekt deltar är i systemutvecklingsprojekt. Då behöver vi i projektet bestämma vilka kontexter vårt projekt och därmed våra modeller ska ha. Varje avgränsad kontext blir normalt ett eget system eller delsystem.
Nedan går jag igenom fyra olika typiska fall.

Fall 1: Vi bygger ett nytt it-system som ska integrera mot ett äldre system

Den information som finns i ett äldre system måste ses som sin egen kontext eftersom systemet inte kan stöpas om bara sådär. Det vill säga att vi måste acceptera det äldre systemet som det är, med sina begrepp och strukturer, vare sig det passar vår egen kontext eller inte.

Men se upp med att äldre system ibland, i praktiken, kan inrymma fler än en avgränsad kontext. Ty en avgränsad kontext bestäms av att det hos de som utvecklar och förvaltar systemet finns en avsikt att hålla ihop modellen för systemet inom dess gränser. Om förvaltningsteamet för det äldre systemet inte kontinuerligt har integrerat sina olika uppdateringar av kodbasen, eller databasen, kan det finnas svåra semantiska motsägelser inom systemet. Då går det inte att hantera det äldre systemet som en enda väldefinierad och avgränsad kontext, utan måste kanske hanteras som flera.

Fall 2: Du ska designa ett nytt it-system

När ett helt nytt it-system ska utvecklas behöver du definiera ett eller flera avgränsade kontexter för domänen, och sedan tillämpa kontinuerlig integration inom dessa. Men vilka kontexter ska du ha, hur många ska det vara, och vilka relationer skall de ha till varandra?

Om kraven på funktionaliteten håller ihop väl, och projektet inte är för stort, räcker det med en enda avgränsad kontext för hela systemet.

Om projektet växer och det blir svårt att kontinuerligt integrera allt, bör du dela modellen i två. Du bryter då isär på så sätt att beroendet mellan delarna blir så litet och tydligt som möjligt. Vi får då två delsystem som kan (men strikt inte behöver) utvecklas och förvaltas av olika team.

Beroendet behöver helst också gå endast i ena riktningen, så att vi kan upprätta ett kund-leverantörsförhållande mellan delarna. Om vi inte kan undvika ett beroende som går i båda riktningarna behöver vi upprätta en delad kärna.

Du har nu två team med varsin avgränsad kontext. Då kan det hända att de två teamen tänker så olika att det ständigt blir problem med det som måste hanteras gemensamt. Det kan bero på att de verkligen behöver helt olika saker från modellen eller att de har så pass olika bakgrund att de ser olika på företeelserna. Det kan också bero på att teamen arbetar på olika sätt.

Om detta är något du inte kan eller vill göra något åt kan du välja att låta delsystemen och därmed modellerna att gå skilda vägar. Du kan då skapa ett översättningslager (translation layer) mellan de olika delsystemen. Detta kan då underhållas gemensamt av de båda grupperna.

Det måste alltid finnas ett uttalat team, och inte flera, som är ansvarigt för en avgränsad kontext. Ett team kan hantera fler än en avgränsad kontext, men det är svårt för flera team att dela på en och samma avgränsade kontext.

Fall 3: Du behöver ta hand om speciella behov med en särskild modell

Olika grupper inom samma verksamhet har ofta egna specialiserade terminologier som skiljer sig från varandra. Det kan bero på att de har olika bakgrunder eller behöver hantera olika specialiteter. Dessa lokala jargonger kan vara mycket precisa och skräddarsydda för just deras arbete. Om man vill införa en standardiserad terminologi som ska ersätta de lokala är det mycket krävande. Det kräver en djup förståelse som man kan få först efter lång tids arbete inom domänen, och dessutom diplomati och samverkan under lång tid. Även om man lyckas finns det risk att den nya terminologin inte fungerar lika bra som den egna exakt anpassade terminologin.

Ett alternativ är att i stället tillgodose det speciella behovet av en egen terminologi i en separat avgränsad kontext. Men det finns en risk att denna möjlighet kan bli ett argument mot förändring, och bidra till att behålla ett dåligt fungerande och inskränkt terminologi och synsätt. Hur värdefull är egentligen den egna jargongen för gruppen? Och hur kan jag veta vad som är värt att behålla och vad som kan förändras? Jag behöver vara ödmjuk, och försiktig med det som faktiskt fungerar.

Ibland växer det fram en djupare modell som kan ena de olika språken och tillgodose de olika grupperna. Haken är att en djup modell alltid uppstår sent i livscykeln, efter mycket utveckling och tänkande, om den uppstår alls. Du kan inte planera för en djup modell. Du kan bara vara öppen för att det kan hända, acceptera möjligheten när den dyker upp, och då ändra strategi och refaktorera.

Fall 4: Du kommer in i ett projekt som pågår

Ibland kommer du som informationsarkitekt in i ett projekt som har pågått ett tag. Då kan du inte bara ge dig på att ändra allting efter eget skön. Men du behöver ändå ta kontroll över situationen. Du kan lämpligen göra så här:

  1. Definiera avgränsade kontexter Det första du då bör göra är att identifiera och definiera avgränsade kontexter, som det förhåller sig nu, det vill säga hur teamet är organiserat idag. Detta är avgörande. Kontextkartan måste avspegla verkligheten som den är just nu, inte den ideala ordningen som du ser den. Förändringar måste alltid utgå från nuläget.
  2. Tajta upp teamets arbetssätt baserat på den befintliga organisationen. Försök inte ändra allt, utan utgå även här från hur det fungerar idag. Förändringar måste alltid ske i små steg, och man måste ha människorna med sig.
  3. Se över och förändra så småningom, vilka olika kontexter som systemet omfattar och hur de är avgränsade från varandra. Det vill säga om det behövs, vilket inte alltid är fallet.

/Peter Tallungs, IRM

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

Strategimönster för informationsarkitekter – del 2: Bevarande av konsistens

Hur kan vi hantera att olika delar av vår verksamhet har olika informationsmodeller som behöver samverka? Och ändå att varje modell bevarar sin konsistens, det vill säga inte rymmer motsägelser. Peter Tallungs presenterar ett antal mönster för detta.

Följande strategimönster har sina ursprung i Eric Evans bok Domain Driven Design, som egentligen handlar om hur man kan strukturera en domänmodell i programkod. Det är inte precis samma som informationsmodellering, men närapå. Framförallt kan sammanhanget vara olika, vi informationsarkitekter fokuserar vanligen lite mer på verksamhetsfunktioner än it-system. Det gör att Eric Evans mönster kan behöva omtolkas lite grand. Fast om vi zoomar ut lite så är en verksamhetsfunktion och it-applikation mer eller mindre kommunicerande begrepp i detta sammanhang. En applikation är en integrerad och ofta central del av en viss verksamhetsfunktion.

Jag har med hjälp av mina kollegor gjort en viss omtolkning när jag tyckt det behövts, men för att läsaren själv ska kunna gå till källan har jag för varje mönster angivit Eric Evans motsvarighet inom parentes.

Mönster 1: Avgränsad kontext (Bounded Context)

Problem: Ofta finns det i en verksamhet flera modeller som helt eller delvis täcker samma domän. Då är det lätt att det blir oklart vilken modell som gäller och vilken som inte gäller för ett visst sammanhang. Kommunikationen mellan människor blir förvirrad, vilket hindrar utvecklingen.

Lösning:

  • Definiera för varje modell explicit det sammanhang för vilket modellen gäller.
  • Sätt tydliga gränser för varje modell; vilken organisation eller organisationsdel, vilket område (det vill säga tillämpningsdomän), vilket eller vilka it-system med mera gäller.
  • Håll modellen strikt konsistent inom dessa gränser, och bli inte distraherad av saker och ting utanför avgränsningen.

Kontext är ett viktigt begrepp då det gäller modeller och det är kanske på sin plats att här definiera vad som menas. Kontexten för en modell är samma som hela det sammanhang för vilket modellen gäller, till exempel ett visst informationssystem, en viss verksamhetsfunktion eller del därav, en viss process, ett visst informationsutbyte, en viss organisation, ett visst ämnesområde med mera.
(Även statusaspekten är en del av kontexten för en modell, det vill säga om modellen gäller nu, eller är det bara Peters vilda teori, eller Lenas förslag för framtiden, med mera, med mera. Med andra ord är modellens kontext hela den uppsättning villkor som måste vara uppfyllda för att man ska kunna säga att modellen gäller.)

Genom att dra en tydlig gräns för modellen kan du hålla modellen ren och därmed kraftfull inom det område där den är applicerbar. På samma gång undviker du förvirring när du flyttar blicken till en annan kontext. Men förr eller senare behöver vi integrera tvärs över en sådan gräns. Men den frågan tar vi hand om separat, och kan då ta hjälp av strategimönster i senare artiklar i denna serie.

Vad gör vi när en modell håller på att fragmenteras?

När vi utvecklar en modell får vi förr eller senare en tendens till fragmentering av modellen, det vill säga motsägelser och oklarheter. Speciellt om vi är flera som modellerar, och inte alltid tillsammans.

Tidiga tecken på fragmentering är följande:

  • Duplicerade begrepp. Två olika modellelement visar sig representera samma företeelse.
  • ”Falska vänner”. Två personer använder samma term, men menar olika saker.
  • Motsägelser. Man märker kanske att när vi ska använda modellen för en it-lösning, en datastruktur eller en rapport så finns det saker som säger emot varandra i modellen. Ofta handlar det om subtila skillnader.

Då måste vi ta ett beslut, och det finns då två vägar att gå:

Alternativ 1: Konsolidera modellen

Lös konflikterna. Vi kanske också behöver förfina arbetsprocessen för att hålla ihop modellen bättre i fortsättningen.

Alternativ 2: Splittra modellen

Fragmenteringen kanske beror på att vi är två grupper av människor som vill dra modellen åt olika håll, och att vi har goda skäl för detta. Det kan grunda sig på att olika intressenter verkligen har olika behov eller olika prioriteringar som är svåra att förena utan att modellen förlorar i användbar. Då behöver vi dela modellen till två separata modeller.

Mönster 2: Kontinuerlig integrering (Continuous Integration)

Problem: När ett antal människor jobbar inom samma modell, finns det alltid en tendens till fragmentering. Ju större team desto större tendens, men även ett litet team kan få problem.

Att alltid i dessa lägen splittra modellen i flera, är inte realistiskt. Då skulle vi förlora i samverkan och sammanhang. Därför måste vi kontinuerlig motverka tendenser till splittring. Vi behöver arbetssätt som ökar kommunikationen mellan människorna och hindrar att det uppstår onödig komplexitet i våra modeller. Ett sådant arbetssätt motverkar till exempel tendensen att man lägger till ett nytt modellelement för att man inte vågar ändra ett befintligt modellelement.

Lösning: Kontinuerlig integrering, innebär att allt som görs inom modellen förenas till en helhet och görs konsistent med täta mellanrum. Mellanrummen måste vara så täta att fragmenteringar fångas och korrigeras snabbt och enkelt. Om man låter tiden gå blir det snabbt svårare. Kontinuerlig integrering av en modell sker på detta sätt genom ständig kommunikation mellan teammedlemmarna. Teamet måste ta vård om den gemensamma förståelsen av modellen allt eftersom den förändras.

Mönster 3: Delad kärna (Shared Kernel)

Problem: Kontinuerlig integrering mellan två delar av ett team kan ibland bli för besvärlig att upprätthålla över tid. Det kan vara så att man egentligen inte har så mycket gemensam funktionalitet, eller att teamet är för stort för det nära samarbete som krävs för att hålla ihop en modell. Det kan också finnas organisatoriska hinder som gör att man inte kan jobba tätt ihop.

Lösning: Dela teamet till två team. Välj ut en del av modellen som de två teamen kan komma överens om att dela. Denna del ges en speciell status och skall inte gå att ändra utan att man överlägger med det andra teamet. Övriga delar blir i praktiken separata modeller som tillåts att mer eller mindre leva sina egna liv.

Mönster 4: Kund-/leverantörs-förhållande mellan team
(Customer Supplier Development Teams)

När två olika verksamhetsfunktioner har ett beroende mellan sig går beroendet mellan dem nästan alltid i ena riktningen. Den ena verksamhetsfunktionen befinner sig ”nedströms” i förhållande till den andra, det vill säga har ett beroende till den andra. De gör olika jobb och har därmed ofta varsin modell med sina egna begrepp och sätt att strukturera och hantera sin information.

Problem: Det kan uppstå problem i integrationen mellan funktionerna på grund av det politiska förhållandet mellan dessa. Uppströmsteamet kan känna sig låst av nedströmsteamet om de inte kan ändra saker och ting fritt. Nedströmsteamet kan känna sig utlämnade till uppströmsteamets godtycke.

Lösning: Etablera ett tydligt kund-/leverantörsförhållande mellan teamen. Det innebär att uppströmsteamet behöver se nedströmsteamet som en kund vars intressen de ska tillgodose.

Mönster 5: Konformist (Conformist)

Problem: När två team med ett uppströms-/nedströmsförhållande till varandra inte styrs av samma ledning händer det ofta att ett samarbetsmönster som ”kund-/leverantörsförhållande” inte fungerar.

Uppströmsteamet har inget tydligt ansvar att tillgodose nedströmsteamets intressen.

Om medlemmarna i nedströmsteamet då är naiva och inte inser att de är utlämnade till sig själva kommer de att få problem.

Lösning: När två team har ett uppströms-/nedströmsförhållande och där uppströmsteamet inte har någon motivering att tillgodose nedströmsteamets behov, måste nedströmsteamet inse realiteten och agera utifrån detta.

Uppströmsteamet kanske ger löften, men de kommer troligen inte att infrias. Nedströmsteamet måste lära sig att leva med det som redan finns. Ett gränssnitt anpassat till nedströmsteamets behov kommer inte att göras.

Det finns då tre vägar att gå för nedströmsteamet:

  1. Överge idén om att använda sig av uppströmsteamets tjänster
  2. Isolera sig från uppströmsmodellen med ett antikorruptionslager
  3. Bli konformist. Anpassa sig slaviskt till uppströms-teamets modell. Detta beslut ökar beroendet till uppströms-teamet. Det är ibland det rätta. Men vi bör då se det som ett aktivt val vi gör, och hantera de konsekvenser som kan uppstå.


Mönster 6: Antikorruptionslager (Anticorruption Layer)

Problem: När man bygger ett nytt informationssystem med ett stort gränssnitt mot ett befintligt system, kan det visa sig svårt att relatera företeelserna i de två systemens modeller till varandra.

I värsta fall kan det andra systemets modell korrumpera den egna modellens syften helt och hållet. Man anpassar då den egna modellen till den andra på ett ad-hoc-sätt för att få ihop det hela. Problemet är då ofta att modellen aldrig kan blir anpassad till de egna behoven så bra som den skulle kunna bli.

Lösning: Skapa ett isolationslager (antikorruptionslager) som tillhandahåller det andra systemets företeelser i termer av den egna domänmodellen. Detta lager kommunicerar med det andra systemet genom dess befintliga gränssnitt. Lagret översätter internt mellan de båda modellerna i båda riktningarna. På så sätt behöver endast antikorruptionslagret befatta sig med det andra systemets begrepp och strukturer och resten av vårt system kan ha sin egen modell mer lämplig för vårt syfte.

Mönster 7: Skilda vägar (Separate Ways)

Problem: När vi bygger ett it-system (eller en verksamhetsfunktion) behöver vi alltid avgränsa kraven. Vi kan aldrig lösa alla problem inom samma system.

Om vi har två uppsättningar krav som inte har täta band till varandra kan de delas upp till två system (eller delsystem) med olika modeller. Integration är alltid dyrt. Ibland är fördelarna små.

Lösning: Skapa en modell med en avgränsad kontext, som inte har någon knytning alls till den andra domänen. Den smala avgränsningen tillåter att man kan finna en enkel specialiserad lösning. Det här är ett val vi kanske är lite för obenägna att göra men som vi nog bör göra lite oftare.

/Peter Tallungs, IRM

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

Informationsarkitekt – Hur långt sträcker sig rollen?

Vad gör en informationsarkitekt? Hur långt sträcker sig rollen egentligen?
Den 15:e oktober 2021 bjöd vi på IRM in till diskussionsträff för att diskutera rollen Informationsarkitekt; vad som kan ingå i rollen och vad som inte ingår. Vi har röstat och vi har ett resultat!

De flesta som läser detta har nog en bild av vad en informationsarkitekt gör. Åtminstone vad kärnan i arbetet är och ungefär hur långt rollen kan sträcka sig. Och jag tror egentligen inte att vi har så olika uppfattning. Men ändå, det kan finnas aspekter där vi har en lite olika förståelse. Och det finns ju inget rätt eller fel egentligen, man kan absolut argumentera för en snävare eller vidare omfattning av rollen.

Den 15:e oktober 2021 bjöd vi på IRM in till diskussionsträff för att diskutera rollen Informationsarkitekt; vad som kan ingå i rollen och vad som inte ingår.

Vi var femton deltagare, nästan alla är verksamma informationsarkitekter och några andra med ett starkt intresse i området.

Röstningen

För att få en struktur på diskussionen hade jag förberett en röstning och listade de kompetensområden som vi såg som kandidater i sex rader. Sedan delade vi dessa i korsande kolumner för de olika sätt på vilka man kan tänkas kunna vara involverade i respektive område.  Detta resulterade i en matris, se nedan

Det är svårt att uttrycka sig riktigt entydigt så både raderna och kolumnerna kan tolkas lite olika. Man kan också argumentera för fler rader och kanske också fler kolumner. Men deltagarna denna dag var överens om att indelningen skulle fungera för en röstning. Vi skulle få ett grepp om ifall vi har ungefär lika uppfattning eller var skiljelinjerna går mellan olika uppfattningar.

Själva röstningen gick till så att deltagarna fick markera i respektive ruta om man ansåg att rollen omfattade det som påstods eller inte. Det fanns också möjlighet för ett tredje alternativ, kanske, och det hände även att någon avstod från att rösta i vissa rutor.

Resultatet

Här är röstresultatet

Jag tänker nu våga mig på en analys av resultatet. Men först några noteringar.

Vilken ”informationsarkitekt” röstade vi om?

Det finns ju två radikalt olika innebörder i termen informationsarkitekt. Se artikeln ”Informationsarkitekter – de två kulturerna”. Den betydelse vi röstade om var den roll vi på IRM är engagerade i, som är inriktad på en hel verksamhet eller del av en verksamhet. Den andra betydelsen av termen ”Informationsarkitekt” handlar om presentation av information på en specifik webbplats eller liknande.

Var gruppen representativ?

Vems uppfattning belyser röstningsresultatet? Vem var med och röstade? Jag och mina kollegor uppfattar att deltagarna på diskussionsträffen den 15 oktober 2021 kan räknas som ett representativt urval av de som är verksamma inom området. Åtminstone tillräckligt representativt för att vara intressant. Vi hade en ganska bra köns- och åldersfördelning, och deltagarna kom från både offentliga organisationer och privata företag.

Var gruppen tillräckligt stor?

En liten grupp ger ett lika bra resultat som en stor, så länge urvalet inte är skevt.

Det vi röstade om var kompetensroller, inte befattningsroller.

Jag menar att man vid diskussion om roller bör skilja på om vi pratar om kompetenser eller befattningar. Om jag säger att jag är informationsarkitekt så kan det betyda att jag har den kompetens man kan förvänta sig av en sådan. Det kan också betyda att jag har en befattning med det namnet i en viss organisation. Det är en viktig skillnad. Vi var här intresserade av själva kompetensen, inte hur man använder titeln i landets organisationer.

Rösten ”Ja” i en ruta, menar man då att en informationsarkitekt måste behärska det rutan står för?

Nej, inte riktigt, hela området är stort, och alla kan inte greppa alla delområden fullt ut. Vi menar snarare att en Ja-röst betyder att du anser att området ingår i kompetensområdet på något sätt. Att det är rimligt att anta att en utbildning eller certifiering inom området skulle omfatta området för att kunna sägas vara komplett. Det hindrar inte att jag som säger mig vara informationsarkitekt kan ha mindre kompetens inom ett eller flera av områdena. Fast jag måste nog kunna täcka de flesta i varje fall, annars blir det tunt.

Analys av resultatet

Låt mig gå igenom områdena rad för rad och försöka tolka röstresultatet.

Data- och informationsstrukturer

Syftet med data- och informationsmodellering är att få grepp om data- och informations-strukturerna i en verksamhet. Gruppen var ense om att det ingår i rollen. Så vi kan även fortsättningsvis betrakta modellering som en kärna i informationsarkitektens arbete. Närmare hälften har dock givit en liten reservation för att styra, leda och hantera med ett ”kanske”. Det beror förstås på vad vi menar med verben ifråga. ExKanske man lägger någon slags chefsroll i detta som man menar inte ingår.

Begrepp och språk

Detta område har fått lika höga röstetal som föregående. Jag tolkar det som att man vill se att vi med våra modeller, med sina benämningar och definitioner, fångar och formar ett språk för de företeelser som beskrivs av data. Jag tycker att resultatet är intressant, för jag upplever att den aspekten av modelleringen ofta inte uppmärksammas.

Försörjning, integration och användning av data/information

Analysera/utreda/dokumentera/modellera får närmast full pott i röstningen medans övriga rutor får succesivt fallande röstetal. Jag tolkar det som att man vill se det som att informationsarkitekter ser till att man har koll på hela dataförsörjningen, men att man däremot inte har ensamt ansvar för att få försörjningen att fungera. Utan det är ett ansvar för it-funktionen som helhet.

Ta hand om data som tillgång/resurs

Här återkommer mönstret från föregående rad, och min tolkning är densamma.

Ägarskap och styrning av dataresurser

Återigen samma mönster som de två föregående raderna. Samma tolkning

Styrning av dataresurser utifrån säkerhetskrav

Nu träder vi ut på lite mer främmande mark. Nästan alla röstade ”Nej”, och några är tveksamma, på om datasäkerhet verkligen är informationsarkitektens hemmaplan. Undantaget är uppgiften att analysera/utreda/dokumentera/modellera. Jag tolkar det som att informationsarkitekten kan ta en analyserande roll inom området men knappast ett större ansvar.

Jag hann själv inte med att rösta men min uppfattning stämmer väl med det samlade resultatet. Samtidigt är jag lite överraskad av samstämmigheten, jag uppfattar inte några tydliga skiljelinjer, annat än sådant som enklast kan förklaras av frågornas otydlighet.

Om jag ska våga mig på en sammanfattning så ger resultatet en vink om att det inom skrået finns en tydlig bild av vad en informationsarkitekt arbetar med. Jag vågar mig inte på en definition men vi har ringat in en bred roll runt data, information och vad det representerar i våra verksamheter. 

Du kanske läser in en annan tolkning av resultatet. Låt höra i så fall.

Tack till alla som var med och bidrog till detta och låt oss fortsätta dialogen. Vi planerar att ha fler träffar framöver. Du får gärna föreslå ämnen som du vill att vi tar upp och även former för träffar. Väl mött!

/Peter Tallungs, IRM

Nästa artikel i serien publiceras torsdag 11 november. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Modellmönster: Temporala mönster

Hur kan vi hantera tidsuppgifter i våra informationsmodeller? Det är en av de vanligaste utmaningarna, och kan samtidigt vara det stökigaste man har att göra med, som modellerare. Välkommen in i världen av temporala mönster! Det handlar om hur vi kan organisera informationen så att man kan ställa frågor på ett enkelt sätt, utan att man för den sakens skull trasslar ihop sin modell fullständigt.

Ibland räcker det helt enkelt med att bara hålla reda på vad som gäller just nu, att registrera ett snapshot av verkligheten. Det är enkelt och okomplicerat. Saker blir dock lite mer intressanta när vi inte bara vill veta tillståndet av världen just nu, utan även tillståndet för sex månader sedan. Riktigt jobbigt kan det bli om vi behöver veta vad vi för två månader sedan trodde om tillståndet för sex månader sedan. Välkommen in i världen av temporala mönster! Det handlar om hur vi kan organisera informationen så att man kan ställa frågor på ett enkelt sätt, utan att man för den sakens skull trasslar ihop sin modell fullständigt.

Mönster 1: Audit log

Det absolut enklaste sättet att registrera förändringar i data är med en så kallad audit log som finns i alla databaser. En audit log registrerar alla förändringar i en tabell.

Fördelen med en sådan logg är att den finns där färdig att använda, i varje fall om du har en databas. En annan fördel är att den inte komplicerar de vanliga frågorna mot databasen, som handlar om läget just nu och inte hur det var historiskt. Nackdelen med en audit log är att när du verkligen behöver få fram historiska data kräver det en större ansträngning. Du behöver manuellt gräva i en loggfil.

Med andra ord är en audit log är användbar då man bara behöver komma åt historiska data ibland och att det då inte behöver gå snabbt och enkelt.

Mönster 2: Giltighet

Det vanligaste mönstret man brukar använda för att hantera tidsaspekten, utöver audit log, är att märka dataposter med Giltighet, vanligen som Från och med- och Till och med-datum. Eller datum och tid i de fall man behöver den upplösningen. Man märker posten med den tidsperiod den anses vara giltig för. När man sedan ska komma åt poster måste man alltid ange vilket datum (eller datum och tid) man är intresserad av för att komma åt rätt poster.

Fördelen är att det är en enkel mekanism, både att bygga och använda. Nackdelen är att klienten, människan eller programvaran som läser uppgiften behöver känna till, och parameterisera frågan med, vilken tidpunkt den är intresserad av. Detta behöver den göra i alla lägen även om den nästan alltid bara är intresserad av nuläget.

Idealet är att kunna gömma och glömma den temporala aspekten tills man behöver den. Det kan åstadkommas på två sätt. Man kan automatiskt och standardmässigt parameterisera varje åtkomstmetod med aktuellt datum för frågetillfället. Eller man kan ha en vy som automatiskt ger den post som gäller vid frågetillfället. De båda metoderna gör egentligen samma sak, de förutsätter att man vill ha det som gäller just nu om man inte explicit anger en annan tidpunkt.

Mönster 3: Version

Ofta vill man tänka på företeelser som att de förekommer i versioner över tid. Det kan exempelvis vara kontrakt som genomgår en serie ändringar över tid. Du vill ibland betrakta varje version av kontraktet som det verkliga kontraktet, vilket det ju faktiskt också rent formellt är.

I den mer praktiska vardagen vill du kanske se det som flera versioner av ett och samma kontrakt.

Mönstret ger på så sätt en och samma företeelse två olika roller, å ena sidan en kontinuerlig över tid, å andra sidan de enskilda versionerna som fångar tillståndet hos objektet för en viss period i tiden. Så snart någon egenskap hos objektet ändras så får man en ny version.

Det kontinuerliga objektet är det man refererar till då man tänker på objektet över tiden. Det har endast de egenskaper som inte kan förändras över tid, framförallt id-begrepp, men även andra essentiella egenskaper.

Mönstret bör användas när verksamheten ser på objektet som att det förekommer i versioner i någon form. Jag har jobbat i försäkringsvärlden i många år. Det vi kallar ”försäkring”, men rätteligen heter ”försäkringsavtal”, har just detta mönster med versioner. Varje version är rent juridiskt ett eget avtal, men för kunden är det ”min bilförsäkring”, det vill säga en och samma försäkring över tid. Och därmed är det även så för alla som arbetar mot kunden, vilket inbegriper i stort sett alla aspekter av verksamheten.

Problemet med två tidsdimensioner

Ofta har vi två olika tidpunkter för en händelse:

1.   Verklig tidpunkt, det vill säga när händelsen inträffade.

2.   Registreringtidpunkt, det vill säga när vi fick reda på att händelsen inträffade.

Därmed har vi två tidsdimensioner att ta hänsyn till, och därmed två olika historier för ett objekt eller en egenskap hos ett objekt. Låt mig visa med ett exempel.

Säg att min timlön har förändrats enligt tabellen.

Registrerat datumVerkligt datumTimlön kr
1 jan1 jan100
15 feb15 feb100
25 feb15 feb100
25 feb25 feb100
14 mar15 feb100
15 mar1 jan100
15 mar15 feb200
15 mar25 feb200
Den verkliga historiken

Låt oss först titta på den verkliga historiken. Min timlön var 100 kronor fram till den 15 februari då den ökade till 200 kronor. Det är den verkliga historiken så som den är känd (registrerad) den 15 mars.

Om vi i stället tittar på den verkliga historiken så som den var känd den 15 februari så var min lön 100 kronor i timmen och några 200 kronor var det aldrig tal om. Varje enskild dag i registreringshistoriken har således en egen verklig historik. Historiken ändras allt eftersom vi får reda på att det som var sant inte längre är sant.

Den registrerade historiken

Min lön för den 25 februari var registrerad som 100 kronor fram till den 15 mars då den blev registrerad som 200 kronor. Registreringshistoriken talar om hur vår kunskap om en viss dag förändras. Varje dag i den verkliga historiken har på så sätt en egen registrerad historik.

Det här var väl inte så krångligt, tänker du kanske. Men vänta bara…

Registrerat datum Verkligt datum Timlön kr
1 jan1 jan100
15 feb15 feb100
25 feb15 feb100
25 feb25 feb100
14 mar15 feb100
15 mar1 jan100
15 mar15 feb200
15 mar25 feb200
26 mar25 feb200
4 apr1 jan100
4 apr14 feb100
4 apr15 feb250
4 apr25 feb250

Tänk att vi den 4 april får en korrigering som säger att lönen den 15 februari i stället höjdes till 250 kronor.

Det är sånt här som får en analytiker att vilja dunka huvudet i väggen! Men låt oss se hur man kan förstå det hela.

Om vi återigen tar fasta att vi har att göra med två olika tidsdimensioner så brukar det klarna för mig.

Den verkliga historiken, som den är registrerad den 4 april, säger att min timlön var 100 kronor från den 1 januari och höjdes till 250 kronor den 15 februari. En lön på 200 kronor förekom aldrig, för den var inte sann.  

Den registrerade historiken säger att timlönen för den 25 februari var 100 kronor och att den höjdes till 200 kronor den 15 mars.

Hur kan vi hantera detta? Låt oss titta på några modellmönster för att hantera situationer med två parallella tidsdimensioner.

Mönster 4: Både verkligt och registrerat datum i audit log

Ett sätt att göra det enkelt för sig är att helt enkelt logga alla ändringar i audit log och överlåta problemet till den som vill läsa ut och analysera tidsförloppet. Det är rätt lösning i det fall att det är sällan annat än aktuell lön är intressant.

Mönster 5: Verklig tid-modellen

Vi hanterar bara verklig tid i modellen. För de fall vi bara är intresserade av hur saker och ting har ändrats över tiden i verkligheten men inte bryr oss om när vi fick kunskap om händelserna. Det är rätt val i många fall, till exempel för en kunds adress.

Mönster 6: Registrerad tid-modellen

Vi hanterar bara registrerad tid i modellen. För de fall då själva registreringen är en händelse som styr annat och därmed är viktig att hålla reda på.

Exempel: Vi skapar fakturor automatiskt baserade på tillstånd hos objekt. Det är då viktigt att kunna spåra hur en faktura beräknats. Vi behöver därför hålla reda på vad vi trodde om ett tillstånd vid den tidpunkten då fakturan producerades.

Ett alternativ är att i stället lagra alla de argument som användes när fakturan beräknades, tillsammans med fakturan.

Mönster 7: Bi-temporala-modellen

Den fulla lösningen med båda tids-dimensionerna. Den behövs sällan.

Problemet med uppdatering av temporala poster är att det är stökigt att tillåta ändring av temporala poster, exempelvis en post som säger att en anställd har en lön från ett visst datum. En ändring kan omfatta varje möjlig kombination av startdatum, slutdatum och lön. Ett gränssnitt för detta kräver många regler som styr vad som går att göra och vad det får för effekter. Vi behöver därför förenkla. Låt oss titta på två mönster för detta.

Mönster 8: Tillåt endast tillägg av poster, ej borttag eller ändringar

Alla ändringar hanteras som tillägg eller som en kombination av tillägg.

Mönster 9: Tillåt endast uppdateringar som gäller från och med idag

De enda uppdateringar som tillåts är de som gäller från och med idag. Retroaktiva uppdateringar tillåts inte. 

Som sagt, detta är ett jobbigt område. Det kan vi inte komma ifrån. Men jag hoppas att vi genom dessa mönster har fått lite bättre grepp om vilka alternativ som står till buds.

Även i denna artikel har jag inspirerats från vad jag hittat i Martin Fowlers bok ”Analysis Patterns” från 1997. Boken är, som jag nu flera gånger tjatat om, en dold skatt vad gäller modellmönster för oss informationsmodellerare.

Det här var sista artikeln om modellmönster, åtminstone för nu. Men kanske har du några modelleringsproblem som du skulle vilja belysa, eller något mönster som du brukar använda jag vi inte tagit upp. Låt höra i så fall.

Nästa artikel handlar om informationsarkitekten, vad rollen kan innehålla och inte innehålla. Vi bjöd in till en frukostträff den 15 oktober i år, där vi diskuterade ämnet. Vi röstade då på ett antal möjliga omfattningar för rollen. Jag kommer att presentera resultatet från röstningen och även försöka mig på en analys av detta.

/Peter Tallungs, IRM

Nästa artikel i serien publiceras torsdag 4 november. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Modellmönster: Observationer

Föregående artikel, ”Modellmönster: Mätningar”, handlade om att registrera mätningar av olika slag. ”Mätningar” är ett namn vi använder för kvantitativa observationer, det vill säga observationer vars resultat kan uttryckas som ett mätvärde. Denna artikel breddar temat till att omfatta alla typer av observationer. Ty kvalitativa observationer blir viktigare i samma takt som kvantitativa.

Exemplen nedan är från sjukvården där man ju gör en stor mängd observationer. Men samma mönster är tillämpliga på alla sammanhang där man registrerar observationer av olika slag.

Mönster 1: Observationer

Precis som det finns många kvantitativa utsagor vi kan göra om en patient finns det också kvalitativa utsagor. Som blodgrupp, kön och om patienten har diabetes eller inte. Vi kan se dessa som Kategoriobservationer eftersom resultatet av observationen, det Observerade värdet, alltid representerar en kategori av något slag, till exempel alla med blodgrupp A, alla kvinnor eller alla som inte har diabetes.

Vi kan utöka mönstret från föregående artikeln, ”Modellmönster: Mätningar”, till att omfatta även sådana observationer.
Kön blir ett Kategorifenomen samt Man, Kvinna, och eventuellt andra kön, blir Observerbara värden. Blodgrupp blir ett annat kategorifenomen med de observerbara värdena A, B, AB och 0. Diabetes blir en tredje typ av kategorifenomen med de observerbara värdena Positiv och Negativ.

Om diagrammets layout

Innan vi går till nästa mönster vill jag ta upp detta med layouten i diagrammet ovan. Till höger har vi regler för observationer, det vill säga vilka fenomen som kan observeras, hur de är indelade i två typer samt vilka värden och måttenheter som gäller för varje fenomen. Till vänster har vi de observationer som gjorts. När något ändras till höger, till exempel att man inför underblodgrupperna A1 och A2 i vad som går att registrera, innebär det att verksamheten konfigureras. När något ändras till vänster, det vill säga att en observation görs, opereras verksamheten.

Jag har i flera av de tidigare artiklarna om modellmönster, till exempel den föregående artikeln ”Modellmönster: Mätningar”, skrivit om hur värdefullt det är att dela in ett modelldiagram (eller mer vanligt, en del av ett diagram, ett särskilt ämnesområde) på detta sätt. Det här är ett annat bra exempel.

Men vi har en dimension till hos modellen ovan som avspeglas i diagrammet. Entiteterna bildar två horisontella rader i diagrammet, en för observationer av kategorifenomen och en för kvantitativa fenomen. Vi ser således två dimensioner i den här delen av verksamheten och avspeglar det i diagrammet.

Spegla verksamheten i diagrammens struktur

Jag tycker att det är intressant hur vi kan strukturerar våra diagram för att avspegla de mönster vi vill se i verksamheten. Vi kan hitta mönster i den mentala strukturen hos de företeelser som verksamheten hanterar som vi på så sätt kan representera och kommunicera. Det är egentligen det enda sätt vi kan få grepp om och hantera det komplicerade maskineri en verksamhet faktiskt är. Jag har inte sett den aspekten av vårt arbete som informationsmodellerare beskrivet eller diskuterat någonstans. Det har varit och är fortfarande, märkligt nog, ignorerat i hela branschen trots att det är en så central aspekt av vårt yrkeskunnande. Hitta och förmedla användbara mönster är väl allt vi gör ungefär. Desto mer angeläget att vi inom vår yrkesgrupp tar upp och diskuterar och tillsammans utvecklar hur vi kan rita och strukturera våra diagram. Jag tror att det har en stor betydelse för hur bra våra modeller blir och är därmed en viktig faktor för hur vi lyckas som individer, team och profession.

Jag kommer att komma in lite djupare på detta ämne i kommande artiklar vilka mer direkt kommer att handla om hur vi kan gestalta våra modeller.

Mönster 2: Indikationer

Vissa fenomen indikerar andra fenomen. Exempel: Viktminskning indikerar Diabetes. Vi kan utöka regelplanet i modellen med sådan kunskap.

Mönster 3: Observationsmetod

När man registrerar en observation kan det vara mer än resultatet som är viktigt. Man vill gärna veta vilken observationsmetod som användes, då det kan förklara ett märkligt resultat eller användas för att bedöma noggrannheten i observationen. Vi lägger därför till observationsmetod i diagrammet.

Mönster 4: Tid för observationen och Tid för registreringen

En observation har en tid för när den gjordes och en tid för när den registrerades. Tiden för observationen kan vara en Tidpunkt eller en Tidsperiod. Tiden för registreringen kan dock bara vara en tidpunkt.

Det gäller de flesta händelser, att de har separata tider för när de inträffade och när de registrerades.

Jag kommer att komma in på detta med temporala mönster i en kommande artikel.  

Mönster 5: Ogiltig observation

Vi kan inte komma ifrån att vissa observationer förklaras ogiltiga genom att en eller flera nya observationer motsäger den första.

Vi kanske har regler som säger att registreringen av en observation aldrig får raderas. Då får vi i stället klassa om observationen som ogiltig och länka den till den eller de nya observationer som motiverar detta.

Var kommer dessa mönster från?

Även denna artikel, precis som den föregående om mätningar, har jag inspirerats från vad jag hittat i Martin Fowlers bok ”Analysis Patterns” från 1997. Boken är, som jag tidigare nämnt, en dold skatt, lite av en apokryfisk skrift, vad gäller modellmönster. Som härmed återupptäcks hoppas jag.

/Peter Tallungs, IRM 

Nästa artikel i serien publiceras torsdag 27 oktober. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Modellmönster: Planering

De flesta organisationer behöver planera sin verksamhet samt följa upp planerna. Till detta har de diverse informationssystem. I detta sammanhang finns det lite mer att tänka på än man kanske till förstone tror.

I denna artikel tar jag avstamp i det enklaste och vanligaste mönstret, Planerad – Pågående – Genomförd, och förklarar varför det inte alltid fungerar så bra. Jag ger i de senare mönstren i artikeln ett alternativt sätt att se på planer.

nster 1: Uppgift

Beståndsdelarna i en plan är de uppgifter som vi människor planerar och genomför. En uppgift kan definieras som en avgränsad enhet av arbete som man planerat att göra, gör just nu eller har gjort. En uppgift kan ha ett antal egenskaper baserat på vem, vad, var och när.

Mönster 2: Planerad – Pågående – Genomförd

När vi gör planer och när vi övervakar planer behöver vi ta hänsyn till de tillstånd en uppgift kan ha. Det är vanligt att man har tillstånden Planerad, Pågående och Genomförd, eller motsvarande.

Det här är ett enkelt och mycket vanligt mönster, som kan verka naturligt och självklart. Men Martin Fowler argumenterar i sin bok ”Analysis Patterns” för att mönstret egentligen inte är särskilt realistisk, det vill säga att den är en teoretisk modell som rimmar dåligt med hur vi gör i verkligheten.

Låt oss titta närmare på svagheterna med detta mönster.

Planering kan sägas bestå av tidsplanering och resursplanering. Dessa kan ske i vilken ordning som helst. Men många uppgifter sätts igång utan formella beslut. De har då varken tids- eller resursplanerats. Vi kan ju förstås alltid hävda att de planeras precis i det ögonblick de startas, men det blir då mer en teoretisk styrmodell än en korrekt bild av verkligheten. Ett annat problem med detta enkla mönster är att det inte tar höjd för att många aktiviteter sätts igång innan man har alla resurser som kommer att behövas. Man planerar att anskaffa det som behövs under vägen.

Hur ska vi då göra? Jo, antingen kan vi söka ett mönster som bättre avspeglar verkligheten. Eller så kan vi använda detta enkla linjära mönster. Men då bör vi i alla fall känna till och närmare förstå dess svagheter. I annat fall får vi svårt att hantera svagheterna när de ger sig till känna.

Mönster 3: Föreslagen uppgift och Implementerad uppgift

Ett helt annat sätt att se på uppgifter, ett sätt som enligt min mening stämmer bättre med verkligheten, är att de finns som två olika företeelser, Föreslagen uppgift och Implementerad uppgift.

En föreslagen uppgift finns bara i en plan som ett förslag. Där kan den resurs- och tidsplaneras i godtycklig ordning. Uppgiften har ingen verklig existens. Först om och när den påbörjas får den en verklig existens, den är då implementerad, det vill säga att uppgiften pågår eller är redan genomförd. Vi bör då se den implementerade uppgiften som en helt egen företeelse, och inte som en föreslagen uppgift som ändrat tillstånd.

Det gör att vi kan registrera skillnader mellan plan och genomförande. Skillnad i tid sker nästan utan undantag, men egentligen kan precis alla egenskaper ändras från plan till genomförande. För att få flexibilitet bör länken mellan föreslagen och implementerad uppgift vara icke-obligatorisk.

Planering är viktigt, men planen är bara en hypotes som snabbt kan bli överspelad. När verkligheten träffar våra planer blir ibland även de bästa planerna lagda på hyllan, och många andra saker händer utan att vara planerade.

En allmän reflektion är följande: Det som vi i förstone ser som två olika tillstånd hos en och samma företeelse, kan ibland förstås bättre som om vi ser det som separata företeelser med olika identiteter och egenskaper.

Frågorna man kritiskt bör ställa sig är följande:

  1. Följer tillstånden regelmässigt på varandra, inte bara i vår ideala föreställningsvärld utan även i verkligheten?
  2. Förblir de väsentliga egenskaperna desamma före och efter tillståndsövergången?
  3. Är det sällsynt att en företeelse i första tillståndet splittras i flera företeelser i andra tillståndet (som att en planerad uppgift implementeras som flera uppgifter), eller tvärtom, att flera företeelser i första tillståndet slås samman till en enda företeelse i andra tillståndet (som att flera planerade uppgifter genomförs som en uppgift)?

Mönster 4: Genomförd uppgift och Annullerad uppgift

Så här långt har vi undersökt hur uppgifter föreslås och hur de påbörjas, men ännu inte om de genomförs.

Ett problem är att vi i många sammanhang inte kan säga med säkerhet om en uppgift var en framgång eller ett misslyckande. Det är ofta endast en subjektiv bedömning, och kan kanske göras först långt i efterhand.

Därför tar vi i detta mönster bara med två möjliga utgångar: avslut eller nedläggning, det vill säga vi får Genomförd uppgift och Annullerad uppgift. Observera att faktat att en uppgift är genomförd inte säger något om resultatet, det vill säga om den lyckades eller misslyckades.

Besltet om att annullera en uppgift kan komma antingen före eller efter att den påbörjats. Att annullera en föreslagen uppgift är detsamma som att besluta att inte påbörja.


Mönster 5: Suspension

Vi kan pausa en uppgift med avsikt att fortsätta den senare. Tisperioden för suspensionen kan ha en öppen sluttid, vi vet inte hur länge en pågående paus kommer att vara.

Om supensionens sluttiden är passerad är den inte längre suspenderad utan aktiv. En uppgift är suspenderad om den har en för ögonblicket gällande Suspension.

Både föreslagna och implementerade uppgifter kan vara suspenderade. Att suspendera en föreslagen uppgift är samma som att senarelägga starten.


Mönster 6: Plan

En Plan är i sin enklaste form en samling uppgifter länkade i någon slags sekvens. Sekvensen uttrycker vanligen någon form av beroende, att en uppgift inte kan påbörjas förrän en annan är slutförd.


Mönster 7: Interagerar planer

I många situationer samverkar eller interagerar flera planer med varandra. En och samma uppgift ingår i flera planer. Ett beroende mellan två uppgifter gäller endast inom en viss plan.

Var kommer dess mönster ifrån?

Dessa mönster härstammar från Martin Fowlers bok ”Analysis Patterns”. Som jag tidigare har skrivit är det en orättvist bortglömd skatt, som jag gärna vill lyfta fram.

/Peter Tallungs, IRM

Modellmönster: Ekonomisk redovisning – del 2: Posteringsregler

En viktig del av informationshanteringen i en verksamhet handlar om att följa hur pengar rör sig genom verksamheten och hur pengar intjänas och spenderas. I två artiklar går jag igenom mönster för ekonomisk redovisning. De mönster som jag tar upp har egentligen en bredare tillämpning än vad artikelrubriken säger. Överallt där man behöver hålla reda på tillgångar i olika poster som till exempel lagerhantering är det användbart att tänka i ”konton”, ”posteringar” och ”transaktioner”.

I den föregående artikeln, Ekonomisk redovisning – del 1: Konto och transaktioner, gick jag igenom sex mönster för konton och posteringar. I denna artikel presenterar jag sju mönster på hur man kan automatisera posteringar med hjälp av regler.

/Peter Tallungs, IRM, 2021-09-30

Mönster 1: Posteringsregel med faktor

Låt oss ta som exempel att varje gång pengar kommer in på ditt inkomstkonto lägger du 30 procent av beloppet på ditt skattekonto (som är ett minneskonto). Du kan då ha en Posteringsregel som gör detta automatiskt.

En posteringsregel är en regel som bevakar ett visst konto. När regeln upptäcker en postering till kontot så skapar regeln en annan postering till ett förutbestämt annat konto. Det konto som bevakas kallas Triggerkonto. Den händelse som ska trigga åtgärden, det vill säga i detta fall en postering till triggerkontot kallas Triggerhändelse. Det andra kontot som ska ta emot posteringen kallas Målkonto.

Om beloppet som ska posteras till målkontot är, som i detta fall, en procentsats av beloppet i triggerhändelsen, räcker det med att regeln uttrycks som en faktor.

Mönster 2: Posteringsregel med särskild beräkningsmetod


Om vi behöver mer flexibla regler för att beräkna vad som ska hända behöver varje regel ha sin egen beräkningsmetod.

Reversering av posteringar

Om vi har gjort en felaktig postering kan vi vanligen inte bara radera den, för den kan ha lett till en utförd betalning eller en skickad faktura. Vi får i stället ta bort effekterna av den felaktiga posteringen genom att göra en ny omvänd postering, det vill säga en identisk postering fast med omvänt tecken. Därför måste varje posteringsregel kunna beordras att göra en postering som är omvänd.

Automatiserade kontosystem

I en del kontosystem är samtliga transaktioner genererade av posteringsregler. Då har man särskilda inkonton där man registrerar initiala posteringar från världen utanför. Alla andra posteringar sker automatiskt genom triggning av posteringsregler. Därmed automatiseras en stor del av kontohanteringen. Då är transaktioner inte lika nödvändiga för att spåra vad som hänt, men det kan ändå vara bra att ha registrerade transaktioner. Det förenklar hanteringen av reglerna.

När ska posteringsreglerna exekveras?

Det finns olika tänkbara modeller som man kan tillämpa i ett kontosystem för när, var och hur posteringsregler exekveras i programkod. Varje modell har sina styrkor och svagheter.

Det kan ske direkt när händelsen inträffar (vilket kallas Eager Firing inom programmerarvärlden), vid bestämda tillfällen eller först när någon efterfrågar kontoställningen (vilket kallas Backward Chained Firing). Varje modell har styrkor och svagheter. Det handlar mest om prestanda, det vill säga den tid det tar att exekvera reglerna, samt om när vi vill hantera fel. Eager Firing låter oss få felen tidigt. De andra modellerna ger oss större valfrihet när vi vill hantera felen, men till priset av större komplexitet.

Mönster 3: En posteringsregel för en grupp av konton

Det är vanligare att en posteringsregel gäller för en grupp av konton än för ett enstaka konto. Vi kan hantera det på två sätt.

  1. Genom att införa ett regelplan i modellen med kontotyper till vilka vi kan knyta posteringsreglerna.
  2. Genom att lägga posteringsregeln på ett summakonto. Då aktiveras regeln när en postering görs till ett underkonto (eller till kontot självt om det kan ta emot posteringar.) Regelns målkonto kan också vara ett summakonto, men tolkningen av regeln kommer i så fall att skapa postering till lämpligt underkonto.

Mönster 4: Posteringsregler med separata metoder

Man kan behöva ha separata metoder för att beräkna belopp, bestämma målkonto med mera. Då kan man ha fördefinierade metoder för olika ändamål. En regel blir då sammansatt av ett antal fördefinierade metoder.

Mönster 5: Konteringspraxis


Om vi har många olika konton som sitter ihop i ett nätverk av posteringsregler blir det hela oöverskådligt.

Vi behöver ett sätt att bryta ner nätverket av regler i lagom stora bitar. Till exempel kan varje typ av kund ha en särskild faktureringsprocess, och därmed ett nätverk av konton och posteringsregler som skiljer sig lite grand från en annan typ av kund.

Ett särskilt nätverk av konton och posteringsregler är en Konteringspraxis. Konceptuellt är en konteringspraxis helt enkelt en specifik uppsättning konteringsregler.

Mönster 6: Orsak till en postering

Det är ofta viktigt att kunna spåra varför en viss postering har gjorts och varför den har den form den har. Till exempel om en kund ringer och frågar om en viss post på en faktura, så behöver vi kunna se vilka posteringar som ledde fram till posten och vilken regel som skapade transaktionen.

Detta mönster låter varje transaktion minnas vilken post,,,,eringsregel som skapade den och vilka posteringar som var argument till transaktionen.

Mönster 7: Konton för lagerhantering

Kontomodellen passar bra för lagerhantering.

Vi kan skapa ett ”tillgångskonto” för varje lagersaldo (Ett Lagersaldo är att ett visst antal av en viss vara finns på ett visst lager). När vi flyttar en vara från ett lager till ett annat skapar vi en Lagertransaktion. Vi kan också hantera kundordar som ”posteringar till utgiftskonton” och leverantörsordrar som ”posteringar till inkomstkonton”. Vi kan också ha ”summakonton” för alla varor av samma varugrupp i ett lager och för en viss lagervara totalt i alla lager, eller för orderstocken. 

Varifrån kommer dessa mönster?

Många mönster i denna artikel och den förra utgår från vad jag hittat i Martin Fowlers bok Analysis Patterns från 1997. Boken är en dold skatt vad gäller modellmönster för informationsmodellering. Martin Fowler skrev boken för programmerare, vilket jag tror är orsaken till att den är så gott som okänd bland informationsmodellerare. Fast den är inte särskilt känd bland programmerare heller. Hans modellmönster förtjänar att lyftas fram och komma till nytta. Jag vill på detta sätt bidra till detta.

Vilka är dina erfarenheter? Har du arbetat med något av dessa mönster eller liknande? Kanske har du andra mönster att dela med dig av?

/Peter Tallungs, IRM

Nästa artikel i serien publiceras torsdag 30 september. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.