Den omöjliga drömmen om den allomspännande informationsmodellen

Det är vanligt att stora organisationer startar ambitiösa modelleringssatsningar, med målet att skapa en informationsmodell som spänner över hela verksamheten och integrerar alla upptänkliga behov de olika delarna av verksamheten kan ha. Men det är ingen bra idé! Det är inte genomförbart att uppnå och kontinuerligt bevara total enighet över en större domän. Denna artikel beskriver varför.

Att uppnå och behålla total enighet över en större domän är inte genomförbart och bör inte vara ett mål

Varför fungerar det inte att ha en enda informationsmodell för en verksamhet större än den allra minsta? För att förstå detta måste vi släppa tanken på att en verksamhet är som en maskin och i stället se en verksamhet som ett organiskt ekosystem. Att ha en enda informationsmodell för en mer omfattande verksamhet skulle fungera om verksamhetens alla delar hade helt och hållet samma mål och samma prioriteringar, det vill säga att verksamheten var som en maskin där alla kugghjulen gick i takt. Men så är inte fallet, så kan en verksamhet aldrig fungera, och det vore inte heller önskvärt. En verksamhet är något helt annat, ett nätverk av olika funktioner med olika fokus och prioriteringar. Egna agendor, om man vill hårdra det (även om många skulle studsa på de orden). Och så måste det vara. Det är något bra och något vi ska bejaka.

Denna, som det kan tyckas, spretighet är inte en brist på samordning utan det är en högst ändamålsenlig organisationsform i en föränderlig värld. Så har egentligen alla organisationer fungerat i alla tider, även om många managementkurser försöker påstå något annat. Varje affärsområde, funktion, avdelning, team och individ är specialiserad på en egen aspekt av verksamheten. Det kan vara ett produktområde, ett kundsegment, en aspekt av de produkter eller tjänster man producerar, någon leverantör eller något annat i omvärlden. Många delar av en verksamhet stödjer interna kunder och är helt koncentrerade på den uppgiften. Varje del av en organisation behöver, för att kunna reagera och verka effektivt inom sitt område, ett stort mått av självständigt agerande.

Genom den mångfald som på detta sätt uppstår har organisationen förmågan att snabbt upptäcka och effektivt anpassa sig till nya möjligheter och hinder. En verksamhet är därmed inte som en maskin utan som ett ekosystem, en dynamisk och levande helhet, i ständigt omstöpande. Detta är inget nytt utan välkänt inom organisations- och managementteori, och har faktiskt varit så allt sedan den moderna organisationsteorin uppstod för ca hundra år sedan. Även om populära managementkurser och böcker har försökt tuta i oss motsatsen, att det är toppstyrning som är grejen.

I och med detta kan heller inte alla delar av verksamheten ha gemensamma begrepp och strukturer för allting. Inte ens förr, då de verksamheter vi modellerade var relativt enkla och statiska jämfört med idag, lyckades vi skapa allomspännande modell för en hel verksamhet. I varje fall om den skulle vara användbar, det vill säga ge mer än en mycket ytlig, överförenklad och ofta bedräglig bild.

En större verksamhet består av ett antal deldomäner som aldrig kan vara helt synkade

Jag brukar dra en liknelse: ”Om det vore en så bra idé att skapa en enda modell för en större verksamhet, varför har vi då inte en enda databas med en enda datastruktur som täcker alla behov i en verksamhet?”. När man hör detta tror jag att man tänker lite djupare och inser att olika delar av verksamheten har olika behov och olika prioriteringar. Och att det måste vara så om man inte ska låsa in hela verksamheten i något statiskt och extremt trögrörligt. Något som bara, i bästa fall, kan bli halvbra för de olika behoven.

Med andra ord; en större verksamhet måste ses som ett antal deldomäner som inte alltid går helt i takt och är helt synkade. Skillnaden mellan olika deldomäner beror mer på att olika delar av organisationen har olika historia, olika kulturer, ser olika saker som viktiga och har olika prioriteringar än av rena tekniska orsaker.

Förändring kräver erfarenhet och insikt

Förresten, om vi föreställer oss att vi efter långa och hårda mödor verkligen skulle lyckas ena en hel organisation runt en gemensam syn på allting av väsentlighet. Vad händer då när företaget köper upp ett annat företag, ingår ett branschsamarbete eller outsourcar några verksamhetsfunktioner? Jo, då blir vi tvungna att överge vår snygga enhetliga modell och gå tillbaka till att hantera att olika delar av verksamheten har olika modeller som vi behöver sy ihop på olika sätt.

Jag påstår inte att alla skillnader i begrepp och strukturer inom en och samma verksamhet är bra. Vissa diskrepanser mellan olika verksamhetsfunktioner är nödvändiga. Andra skillnader är kanske onödiga och till besvär, vilket kanske mest beror på att man har olika ursprung och inte har jobbat tillräckligt med att samordna och förenkla. De olikheterna behöver kanske i längden arbetas bort.

Men det är inte möjligt att utan den insikt som en längre tids arbete med modeller, data och funktioner ger oss, skilja på vad som bör få vara som det är mot vad som faktiskt bör förändras. Och för det som bör samordnas krävs det ännu mer insikt om alla olika aspekter om just denna verksamhet, för att förstå vad som krävs för att samordna och hur vi kan få det att hända. Insikt som vi får först efter ganska lång tid av praktiskt arbete inom domänen.

Det första som krävs är i vilket fall att vi verkligen förstår de olika delarna av verksamheten, hur de fungerar och hur deras data ser ut och används. Det vill säga att vi modellerar de olika delarna av verksamheten som egna avgränsade domäner. Så hur vi än vänder oss måste vi börja med att modellera de olika delarna av en verksamhet med separata modeller. Det kommer vi inte ifrån. I alla fall inte i en hyfsat stor verksamhet.

Vi kan dock behöva en översiktlig horisontell modell

Den här artikeln bör inte tolkas som att jag påstår att man inte kan skapa en gemensam ”tunn” horisontell modell för en hel verksamhet, eller en hel bransch. ”Tunn” i meningen att den inte tränger så djupt i området, inte tar med alla förekommande begrepp utan tar ett mer ytligt grepp. Det kan man, och det gör vi ofta, men då för ett avgränsat syfte, till exempel för analys och uppföljning tvärs över en eller flera verksamheter. Det är till exempel grundbulten inom rapportering och Business Intelligence. Det kräver visserligen ett envist och långvarigt arbete, men går att göra.

Men detta är något annat än att man i grunden förändrar de olika verksamhetsfunktionernas egna begrepp och sätt att fungera. Vad vi gör när vi tar fram en modell specifikt för rapportering, analys och uppföljning är att vi skapar ett gemensamt språk ett ”lingua franca” för de aspekter av en verksamhet som man har behov att analysera och följa upp. Det kan vara mycket men långtifrån allt. Och man förändrar då inte samtidigt de olika lokala begreppen och synsätten i de olika operativa delarna av verksamheten.  

Varför vi ofta har svårt att acceptera

Vi har ofta svårt att acceptera den förbistring det innebär att olika delar av vår verksamhet har olika begrepp och olika syn på saker och ting. Det är förklarligt då det ju orsakar uppenbara problem. Olika begrepp och sätt att definiera dessa försvårar kommunikationen och är egentligen det enda som gör integration besvärlig. Det känns inte så elegant, utan mer som en fullösning. Det är detta som ligger bakom alla ambitiösa försök att ena en större domän under en gemensam modell. Men riskerna är många. Låt mig nämna några.

Risker med försök till en gemensam modell för en större domän

  • För stort grepp. Man försöker åstadkomma för mycket på en gång, till exempel då man försöker ersätta flera äldre it-system med ett gemensamt nytt system.Projektet blir nedtyngt när arbetet med att koordinera så många olika intressenter överstiger förmågan och resurserna. Vi har sett många stora och spektakulära it-haverier på grund av detta genom åren.

      Att bara öka på resurserna, det vill säga mer personal, är aldrig en lösning. Det bara ökar behovet av koordinering, och snart går all tid åt till möten. Projektet står helt stilla samtidigt som det bränner pengar och resurser i hög takt. Alla som varit med i större organisationer har nog upplevt detta. Som den kände projektledaren Fred Brooks sa redan på 70-talet: ”To add people to a late project makes it later” eller “Nine women can´t deliver a child in one month”.

      Projekt måste hållas små för att lyckas. Stora projekt har en mycket liten chans att lyckas. Små projekt har däremot en bra track record. Men vad gör man då när uppgiften är stor? Måste man inte driva ett stort projekt då. Nej, hävdar jag bestämt. Stora uppgifter går alltid att dela ner i flera mindre självständiga som var och en levererar nytta i sig självt, menar jag. Även om många inte tror det.

  • Modellen försöker få in alla behov i samma grova mall, vilket leder till att behoven tillfredsställs mycket fyrkantigt, om alls. Många kommer inte att kunna använda modellen utan tvingas ta fram egna modeller ändå.
  • Modellen försöker verkligen tillgodose alla, vilket gör att den får många alternativ och specialfall, vilket gör den mycket svår och omständlig att använda.
  • Arbetet med den stora modellen som ska lösa allt skymmer eller blockerar all annan viktig modellering. Man får då ofta höra: ”Nej, lägg inte ner något arbete på det, det kommer att lösas av den stora kommande (eller pågående) satsningen, som ska leverera om två år!”

Hur gör vi då?

Vi kan alltså inte komma ifrån att vi behöver hantera flera olika modeller i en större verksamhet, där varje modell faktiskt lever sitt eget liv, mer eller mindre.

Om vi helt lämnar tanken på en stor gemensam modell kommer vi att ha ett antal mindre omfattande modeller där var och en beskriver en del eller en aspekt av verksamheten. Utmaningen blir då att se till att de olika modeller vi har ska kunna samverka tillräckligt bra för att stödja gemensamma processer. Det handlar då mycket om förhandling och beslut mellan team.

Det är ett löpande arbete i skärningen mellan design (modellering) och politik. Med andra ord är vi inne på ett ämnesområde som är strategi vad gäller informationsarkitektur. De närmast följande artiklarna handlar om just detta. Då kommer jag att resonera om hur vi på ett mer realistiskt och hållbart sätt kan möta behovet av att få grepp om företeelser, begrepp och information i en verksamhet.

/Peter Tallungs, IRM

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

Om organisationer och personer – fyra vanliga missar

Organisationer och personer är centrala företeelser i varje verksamhet. Men vilka begrepp använder vi för dessa? I denna artikel tar jag upp några vanliga misstag, och ger råd om bra och vedertagna begrepp.

Hur det brukar se ut

I de organisationer jag verkat händer det att man delat in alla intressenter i fysiska och juridiska personer, samt haft personnummer och organisationsnummer som unikt id för respektive kategori. Jag menar att man då lyckats göra flera misstag på en och samma gång. Jag går igenom dem ett efter ett nedan.

Misstag 1: Förväxling av begreppet Organisation med begreppet Juridisk person

Det är inte alla organisationer som är juridiska personer, inte ens merparten, utan faktiskt endast cirka 40 procent av Sveriges tre miljoner registrerade organisationer. De som inte är juridiska personer utgörs främst av enskilda näringsverksamheter, de som i dagligt tal brukar kallas enskilda firmor. De är cirka 1,8 miljoner till antalet. Juridiskt och skattemässigt ingår de i den enskilda näringsidkarens person. Men de är ändå organisationer. De är ibland lite större företag, med många anställda. En och samma person kan äga flera sådana företag som till och med kan finnas på olika orter och ha olika verksamheter. Men de är inte juridiska personer.

Bland andra former av organisationer som inte är juridiska personer finns cirka 20 000 enkla bolag, 200 partrederier, 1 700 värdepappersfonder, 330 statliga enheter, 7 regionala statliga myndigheter samt cirka 6 500 verksamheter som drivs av oskiftade dödsbon. Att kategorisera alla dessa som juridiska personer blir i grunden fel.

Misstag 2: Tron att alla personer i Sverige identifieras med personnummer

Endast personer som är folkbokförda i Sverige har svenskt personnummer. Övriga som ska arbeta i landet, eller av annan anledning behöver få en registrerad identitet i Sverige, får ett så kallat samordningsnummer. Det liknar visserligen personnummer i formatet men har talet 60 tillagt till dagnumret.
(Skatteverket förklarar det så här: Samordningsnummer består liksom personnumret av tio siffror. De inledande sex siffrorna utgår från personens födelsetid med den skillnaden att man lägger till 60 till födelsedagen. För en person som är född den 23 augusti 1964 så blir de sex första siffrorna i samordningsnumret därför 640883).

Att sortera in samordningsnummer under personnummer kan synas vara en oskyldig förenkling. Men jag har varit med om att detta fått följder. Det var ett försäkringsbolag som hade företagskunder och privatkunder i samma register. De ville separera dessa genom att skapa separata register för dessa. Inte minst för att företag och privatpersoner omfattas av olika lagstiftning runt försäkring, och erbjuds olika produkter med olika skydd och olika premier. En programmerare gjorde ett sållningsfilter som baserat på om kunden hade ett giltigt personnummer blev klassad som privatperson, i annat fall som företag. Ett giltigt personnummer har, förutom en giltig checksiffra på slutet, ett giltigt datum, det vill säga de första sex siffrorna. Eftersom samordningsnummer inte klarade det testet blev alla tusentals kunder med samordningsnummer klassade som företag. Innan misstaget upptäcktes och åtgärdades blev det en hel del kostsamma och besvärliga följdfel.

Misstag 3: Tron att alla organisationer i Sverige identifieras med organisationsnummer

Eftersom en enskild näringsidkare kan driva fler än en enskild näringsverksamhet räcker det inte att använda näringsidkarens personnummer för att unikt identifiera en enskild näringsverksamhet. Enskilda näringsverksamheter identifieras därför officiellt med näringsidkarens personnummer följt av en löpsiffra, en etta för personens första näringsverksamhet, en tvåa för den andra och så vidare.

Misstag 4: Ej anpassat till kunder som inte är personer eller organisationer registrerade i Sverige

De identitetsbegrepp vi nämnt gäller endast för personer och organisationer registrerade i Sverige. Om vi har intressenter som saknar en svensk identitet behöver vi ha mer generella namn på våra id-begrepp samt kvalificera dessa med vilket land som utfärdat identiteten.

Hur ska man göra då?

Jag brukar göra så här när det handlar om verksamheter med endast svenska intressenter.

Och så här när intressenterna är internationella.

Det här kan kanske tyckas petigt, det är lättare att bara fortsätta göra som alla andra. Vi är sociala varelser så ibland tror vi att det som alla gör är korrekt bara för att alla gör så. Men det är ett farligt gruppbeteende. Om vi inte kan klara av att fixa det som är enkelt att få ordning på, hur ska vi då kunna reda ut det som verkligen är svårt? Som modellerare är vi ansvariga för begreppen. Då behövs det att vi anstränger oss att använda de termer som korrekt representerar de företeelser vi modellerar. 

Andra intressenter än organisationer och personer

Det jag inte berört här är hur man tänker när man behöver hantera andra intressenter än organisationer eller personer. Ibland vill man se delar av en och samma organisation som olika kunder. Jag har varit med om följande situation i en verksamhet. Vi hade två bröder som kunder. De hade registrerat en firma ihop men sedan gått skilda vägar. De drev separata verksamheter, men hade ändå stannat kvar i samma firma. De hade inte talat med varandra på 20 år och ville absolut inte ses som en och samma kund. Ett annat fall är hur man i försäkringsvärlden ser hushållet som kund. För privat sakförsäkring som till exempel villa-/hemförsäkring och motorfordonsförsäkring är det i de flesta situationer ointressant just vem i familjen som faktiskt står som försäkringstagare. Jag minns knappt inte ens om bilen och villan står på mig eller min partner. Därför är det vanligt att man inom privat sakförsäkring ser hushållet som kund mer än den person som råkar vara försäkringstagare. Men detta är en annan historia.

Vad tycker du?

Jag har säkert missat någon aspekt. Du får gärna komplettera eller rätta om du har en annan synvinkel.

/Peter Tallungs, IRM

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

Hur långt ska man generalisera?

En fråga som hela tiden är närvarande när man informationsmodellerar är följande; Hur kan jag hitta den rätta balansen så modellen varken blir för generell eller för specifik? Informationsmodellering är ingen exakt vetenskap utan ett hantverk. Det handlar om intuition, det vill säga sådant som vi vet men inte vet exakt hur vi kan veta.

Att generalisera lagom när jag informationsmodellerar är att gå en balansgång som kräver omdöme och erfarenhet. Det är en smal stig att gå på med diken på ömse sidor som jag inte vill trilla ner i. Om min modell blir för specifik kan den inte hantera de varianter av företeelser som dyker upp över tid. Om den blir för generell säger den inte speciellt mycket om domänen i fråga.

Det finns inga fasta regler; det som först kan vara rätt blir fel i ett senare läge, och det som är rätt i ett sammanhang kan vara fel i ett annat. Den enda ledstång jag kan ha är hur användbar min modell och mina begrepp blir för det den ska användas till.

Om jag i huvudet stegar mig igenom olika tänkbara användningsscenarior så är jag snart på god väg att hitta rätt abstraktionsnivå. Inte minst hjälper det mig att förstå vad jag behöver hålla utkik efter, vilka faktorer som kommer att påverka vilka abstraktioner verksamheten behöver. Men facit får jag inte förrän modellen används på riktigt. Därför är det avgörande att inte låsa sig till ett visst synsätt, utan att pröva sig fram hela tiden, och omvärdera sina antaganden. Jag behöver ofta ändra modellen, alltefter jag får återkoppling från de som använder den. Det är inte ett misslyckande utan något bra. Det är så det lärande som kallas utveckling går till.

Stabilt är inte alltid starkt

Det är precis det som menas med idén om att något är anti-fragilt (Se Nassim Nicholas Talebs bok ”Antifragile – things that gain from disorder”.) Ju mer min modell används desto fler prövningar utsätts den för och desto mer utmanas den på olika sätt, och blir därmed allt starkare. Det innebär inte att den är stark i den meningen att den är så stabil att den inte förändras, utan att den klarar stress för att den hela tiden utvecklas och anpassar sig till omständigheterna. Det kräver att vi arbetar med den mer eller mindre kontinuerligt under hela dess existens. Det finns ingen ”överlämning”, där vi släpper modellen, så länge den används.

Varning för att övergeneralisera!

Här ser vi två olika sätt att modellera samma företeelser; att en försäkring kan ha olika intressenter (parter) i olika roller. Den övre modellen är mer tydlig då den i ER-diagrammet visar vilka roller olika parter kan ha i en försäkring. Diagrammet säger att det måste finnas precis en försäkringstagare och det måste vara en kund, samt att det måste finnas precis en försäkringsgivare och att det måste vara ett försäkrings-bolag. Det visar således tydligt viktiga företeelser inom domänen och vilka begrepp som gäller för dessa. Modellen som diagrammet representerar kommunicerar tydligt och enkelt viktiga företeelser inom domänen och vilka regler som gäller för dessa.

Men ofta behöver man kunna hantera fler roller på en försäkring än försäkringstagare och försäkringsgivare. Och ofta vill man också kunna lägga till roller mer dynamiskt. Det kan till exempel vara rollerna Betalare och Försäkrad.

Vi kan då göra som i den nedre modellen, skapa en entitet för själva relationen ”Part i försäkring”. Om vi fortfarande vill kunna uttrycka de regler som vi har i den övre modellen så behöver vi göra det på andra sätt, till exempel genom att införa ett regelplan i modellen enligt ovan. Vi har därmed fått en mer robust modell, det vill säga att den håller bättre för förändringar, till exempel att nya roller tillkommer eller förändras. Men priset är att diagrammet kommunicerar sämre. Samt att de data som är strukturerat enligt modellen blir mer komplicerat att komma åt.

Är det ett pris som är värt att betala? Det beror på omständigheterna. Har vi en verksamhet som ska klara av många olika exotiska och varierande roller? Eller är de roller som finns relativt stabila?

Jag kanske förutser att nya roller framöver kommer att dyka upp ganska frekvent, roller som vi idag kan förutse exakt vilka de blir. Då kan jag inte se rollerna som speciellt stabila utan behöver ett smidigt sätt att lägga till, förändra och ta bort roller i våra system, liksom i rapporter med mera.

Välj en modell som passar syftet. Överdriv inte kravet på robusthet. Den ökade komplexiteten i den nedre modellen blir en kostnad att bära framgent i allt vi använder modellen till.

Varning för att vara för specifik

Det är viktigt att bygga en struktur tillräckligt stabil, det vill säga att man bör akta sig för att bygga in begränsningar i själva strukturen som kanske ändras över tiden. Det gäller särskilt då modellen ligger till grund för en databas eller liknande som kan vara svår att förändra i efterhand. En riktlinje kan då vara; Bygg inte in en regel (begränsning) i själva datastrukturen för ett system utan att du är tämligen säker på att regeln kommer att gälla för systemets livslängd. Generalisera för att avlägsna oönskade regler från datastrukturen.

Den typiska utvecklingsgången hos modelleraren

När man är nybörjare inom modellering avbildar man gärna de vardagliga verksamhetsbegreppen direkt i modellens struktur. Därmed bygger man ofta in specifika regler som inte alltid gäller framgent. Modellerna blir spröda, då de inte klarar minsta förändring.

Men snart, mycket snart, upptäcker man generaliseringens kraft och det blir då gärna en överdrift åt andra hållet. Modellen blir så generell så den kan härbärgera så gott som allting. Man känner sig därmed immun mot alla nya krav som riskerar att poppa upp.

Jag och mina kollegor känner så väl igen oss själva i denna typiska utvecklingsgång. Vi ler generat. Vi har alla, mer eller mindre, gått igenom detta.

En kontinuerlig utveckling

Att abstrahera allt och alltid är inte skicklig modellering utan snarare att man har abdikerat från sin uppgift. Ty uppgiften är aldrig att göra modeller som vi aldrig behöver ändra och som inte duger till något. Uppgiften är att göra så användbara modeller som möjligt för sitt syfte och sammanhang. Och att utveckla modellerna kontinuerligt så att de alltid bär vår gemensamma förståelse, just nu. En modell behöver så tydligt som möjligt beskriva det som verksamheten behöver hantera. Och det på ett sätt som passar sammanhanget. Modellen behöver vara så enkel som möjligt. Men inte enklare!

Nu har ju informationsmodeller ofta ett mycket brett syfte och sammanhang. Ofta bygger man med modellen ett verksamhetsspråk som både möjliggör och begränsar vad man kan prata om och hur. Det är ett stort ansvar. Men trots att syftet och sammanhanget ofta är mycket brett är det ändå ett syfte och sammanhang att ta hänsyn till. Det finns inte någon rent objektiv och alltid giltig modell. En modell är alltid en abstraktion, det vill säga att den lyfter fram vissa aspekter av de företeelser vi modellerar och ignorerar andra. Och vad vi lyfter fram och vad vi ignorerar beror på sammanhang och syfte.   

Hur långt ska man specialisera?

Vi kan specialisera (subtypa) så långt som det hjälper oss att beskriva de regler vi behöver beskriva. Ibland säger man: ”Ända tills alla attribut och relationer är obligatoriska”. Det kanske är att gå för långt, men kan ändå vara en hint om hur man kan tänka. ER-diagrammet till höger ger ett exempel på hur man kan behöva specialisera ”Anställd” och ”Kontrakt” om man vill uttrycka vilka kategorier av anställda som kan ta vilka roller i olika kategorier av kontrakt.

Hur långt kan man generalisera?

Ja, rent teoretiskt finns det förstås en absolut gräns när vi har nått ett generellt begrepp som täcker alla företeelser som finns i vår domän. Vi har då en generell entitet som heter ”Thing” eller liknande. Men då har vi förvillat oss långt bort från den praktiska verkligheten. I verkligheten når vi en praktisk gräns vid fem till tio mycket generella företeelser. Det kan vara Part, Roll, Händelse, Resurs, Arrangemang, Plats, Regel och några till. Så högt i abstraktionshierarkin går vi bara i de fall vi behöver kommunicera mycket breda koncept. Det kan vara då vi bygger upp en metamodell för ett Dictionary eller liknande.

Vi utvecklas genom att dela erfarenheter

Det här är en aspekt av modellering, en färdighet man har som modellerare, där det är svårt att uttrycka precis hur man ska tänka. Det handlar om intuition, det vill säga sådant vi vet men inte vet exakt hur vi kan veta. Det kan också hänföras till så kallad tyst kunskap det vill säga sådant vi kan men som är omöjligt, eller i varje fall mycket svåra, att uttrycka verbalt. Förtrogenhetskunskap kallar man det för inom den praktiska filosofin.

Och som vanligt inom det mesta som rör utveckling finns det inget som är absolut fel eller rätt i alla situationer. Tvärt emot vad många tror finns det ingen ”best practice” att kopiera. Allt sånt kan vi glömma. Vi behöver studera olika lösningar, inte för att kopiera utan för att få en känsla för hur man kan hantera olika specifika situationer. Därför är det viktigt att vi delar erfarenheter. Så låt oss göra det! Kan vi göra det genom att vi har träffar om olika modelleringsproblem? Eller att vi delar exempel från verkligheten på något sätt, med kommentarer? ”War Stories”. ”From the trenches”. Så här gjorde vi, och det fungerade bra på dessa sätt men kanske mindre bra på dessa.

Hur skulle du vilja dela erfarenheter? Vilka utmaningar vill du diskutera med oss informationsarkitekter? Skriv i kommentarsfältet här nedan, så ser vi på IRM till att skapa tillfällen eller utrymme för erfarenhetsutbyten.

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 18 november. 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: Mätningar

I de flesta organisationer görs mätningar av olika slag. I stort sett alla verksamheter blir mer och mer datadrivna, vilket innebär att en mängd olika typer av kvantitativa data samlas in och hanteras. Denna artikel tar upp några användbara mönster för att registrera mätningar. Exemplen är tagna från sjukvården, men mönstren är tillämpliga på alla slags verksamheter.   

/Peter Tallungs, IRM, 2021-10-14

Mönster 1: Specifika attribut per mätvärde

Det vanligaste sättet att registrera ett mätvärde i ett informationssystem är att registrera ett numeriskt värde i ett fält avsett för ett visst mätvärde.

Ett problem är att det vanligen inte anges vilken måttenhet som avses. Det har lett till fatala misstag många gånger.

Ett sätt att åtgärda detta är att alltid baka in namnet på måttenheten i attributnamnet. Det är ett enkelt och effektivt sätt att öka datakvaliteten och minska risken för missförstånd. Ändå är det sällan så görs. Kanske det ännu finns en kvardröjande uppfattning om att attributnamn måste vara korta. Men det var länge sedan vi hade den tekniska begränsningen i våra informationssystem.

Mönster 2: Entitet för mätvärde

I till exempel medicinska sammanhang vill man av säkerhetsskäl kunna registrera en mätning exakt som den gjordes, utan att behöva räkna om måttenhet. Då blir det användbart att introducera en särskild entitet för Mätvärde där vi ser måttenhet, värde och tecken som en sammanhållen enhet.

Monetära belopp kan hanteras på samma sätt. På det sättet kan man hantera flera valutor samtidigt.

Mönster 3: Omräkningsfaktor

Om vi som i föregående mönster har måttenheter som är explicit angivna i modellen så kan vi automatiskt omvandla ett mätvärde från en enhet till en annan, om vi har en Omräkningsfaktor. En sådan kan hantera de flesta omräkningar, dock inte alla. Till exempel Celsius till Fahrenheit kräver en formel. Dagar, månader och år konverterar inte heller så lätt till varandra, utan kräver lite mer avancerad omräkning.

Detta mönster är vanligt för automatisk omräkning av monetära belopp i olika valutor. Vanligen vill man hålla reda på valutakurser över tiden vilket gör att de behöver datumstämplas.

Mönster 4: Mätning

På ett sjukhus måste man kunna registrera många olika slags mätningar för samma patient. Då kan man inte ha ett attribut per möjlig mätning. Det skulle bli hundratals attribut, där de flesta förblir oanvända för en och samma patient.

En lösning är att betrakta alla saker som kan mätas (längd, vikt, blodsockernivå mm) som Typ av fenomen samt införa Mätning, en entitet för själva mätningen som görs. Vi kan då också lägga på attribut på mätningen, så som vem som gjorde den, när den gjordes och var. 

Det är värdefullt att dela in den del av modellen som är för mätningar i ett operativt plan och ett regelplan enligt ovan. Det operativa planet registrerar de mätningar som görs dagligen. Regelplanet representerar reglerna om vad som kan mätas och uppdateras endast då dessa ändras.


Man kan också ha en lista av tillämpliga måttenheter för varje fenomen, för användarna att välja från.

Kvantitativa och kvalitativa observationer

”Mätningar” är ett namn vi använder för kvantitativa observationer, det vill säga observationer vars resultat uttrycks som kvantitet eller antal av något slag. Nästa artikel breddar temat till att omfatta även kategoriobservationer, det vill säga observationer vars resultat uttrycks som tillhörande en kategori av något slag.

/Peter Tallungs, IRM

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.

Modellmönster: Ekonomisk redovisning – del 1: Konto och transaktioner

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”.

Mönster 1: Konto och Postering

Den grundläggande idén bakom ekonomisk redovisning är att man har olika högar med pengar för olika syften, och att vi registrerar hur pengar flyttas mellan högarna. Vi kallar en sådan hög för Konto.

Det behöver inte handla om pengar. Vilka resurser som helst kan hanteras, och hanteras i olika verksamheter, på samma sätt, som till exempel lagervaror eller poäng av olika slag.

I de flesta sammanhang vill vi inte bara hålla reda på hur mycket det finns på kontot utan även varje förändring som påverkat innehållet.

Ett konto håller saker av värde – pengar eller gods.

Pengar, eller gods, kan endast läggas till eller tas bort genom att göra en Postering. Posteringarna utgör tillsammans en historik av alla förändringar på kontot. Beloppets tecken (plus eller minus) anger om posteringen är en debitering eller kreditering (insättning eller uttag).

Saldo, hur mycket det finns på kontot vid ett givet tillfälle, är en nettoeffekt av samtliga posteringar på kontot fram till den valda tidpunkten. Regeln innebär att saldot beräknas varje gång den efterfrågas. Det hindrar inte att föregående saldo lagras internt från gång till gång för att snabba upp beräkningen.

Med detta mönster kan man också se hur saldot har ändrats under en tidsperiod. Ett Kontoutdrag är en lista på samtliga posteringar som gjorts under en tidsperiod.

Lägg märke till att man vanligen håller reda på två tidpunkter för en postering. Den tidpunkten då posteringen gäller, samt tidpunkten då posteringen registrerades.

Det är ofta så att vi behöver veta både tidpunkten för en händelse i verkligheten och tidpunkten för vår kunskap om denna händelse.

Mönster 2: Transaktion

En kontoändring innebär vanligen att ett belopp flyttas från ett konto till ett annat. Det räcker oftast inte med att registrera att beloppet har kommit eller gått utan vi måste också hålla reda på varifrån och varthän.

En Transaktion länkar explicit ihop ett uttag från ett konto med en insättning på ett annat. Att två posteringar hör samman på detta sätt visar på en viktig bokföringsprincip. Pengar, eller gods, uppstår aldrig ur intet och de försvinner aldrig, de bara flyttas runt mellan olika konton.

I bokföringssystem strävar vi efter att få kontona balanserade, det vill säga att få saldo lika med noll vid en viss tidpunkt i affärscykeln (bokslutet).

Med hjälp av explicita transaktioner bygger vi in denna kontroll i själva strukturen. Det gör det lättare att hitta läckor i systemet.

Märk att jag satt en tvåa vid relationen från Transaktion till Postering, detta för att markera att en transaktion måste omfatta precis två posteringar, varken mer eller mindre. Fast man kan egentligen mycket väl tänka sig transaktioner som omfattar ett godtyckligt antal uttag och insättningar, fast alltid minst två, bara summan blir noll. I själva verket är den tvåvärda transaktionen endast ett specialfall av den flervärda.

Mönster 3: Transaktion utan explicita posteringar

I kontosystem med endast tvåvärda transaktioner behöver man egentligen inte en särskild entitet för posteringar, utan kan förenkla modellen enligt följande.


Mönster 4: Summakonto och detaljkonton

I kontosystem är det ofta användbart att gruppera konton till summakonton. Om jag till exempel har separata konton för olika utgifter så vill jag kanske gruppera vissa som personliga utgifter och andra som affärsutgifter.

Posteringar kan då endast göras mot detaljkonton. Ett summakonto har ändå transaktioner genom sina underkonton. Summakonton kan i sin tur grupperas i mer övergripande summakonton.

Mönster 5: Gruppering av konton utan
explicita summakonton

Det är vanligt att dela upp konton i två typer; summakonton och detaljkonton, men egentligen är det inte nödvändigt. I detta mönster kan alla konton ha underkonton.

Mönster 6: Minneskonto

Ibland behöver man reservera pengar för ett visst ändamål, till exempel skatt. Då kan man ha ett konto där man löpande registrerar hur mycket man reserverar, ett så kallat Minneskonto. Då vet jag hur mycket av de pengar jag har som jag verkligen kan disponera.

Observera att när jag reserverar pengar på ett minneskonto så flyttas inte pengar. Det är bara en notering om hur mycket jag är skyldig. På så sätt innehåller ett minneskonto pengar fast inte ”riktiga” pengar. Det innebär att dubbel bokföring inte är nödvändig, det vill säga att en postering till minneskontot inte behöver speglas av en postering från ett annat konto. Det går att öka skulden i skattekontot utan att minska tillgångarna någon annanstans.

Det finns två sätt att hantera detta:

  1. Skapa ett motkonto. På detta sätt blir principen om dubbel bokföring genomgående för alla konton.
  2. Undanta minneskonto från regeln om att en transaktion alltid ska balansera. Tvärtom måste det då finnas en regel som säger att transaktioner mot minneskonton inte får balansera. I annat fall läcker verkliga pengar till minneskontot!

Fortsättning i nästa artikel

I nästa artikel tar jag upp hur man kan styra posteringar med hjälp av posteringsregler. 

/Peter Tallungs, IRM

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