Inlägg

Modellmönster: Produkt – del 2: Produktlivscykel och Leverantörsprodukt

En produkt har en livscykel. Den kan vara under utveckling, den kan vara öppen (att den finns tillgänglig) och den kan vara avslutad. Den kan också vara tillfälligt stängd, det vill säga suspenderad. Om vi ska kunna följa produkters beteende behöver vi veta vilka produkter vi har vid varje givet tillfälle. Därför behöver vi definiera en produktlivscykel. Den liknar i allt väsentligt den kundlivscykel jag beskrivit i tidigare artiklar.

Vi kan behöva hantera flera olika identiteter för samma produkt, till exempel då det gäller leverantörskedjor. Det beskrivs i mönstret Leverantörsprodukt.

Mönster 1: Produktlivscykel

En produkt har en livscykel. Det är viktigt att veta vilket tillstånd en produkt är i, då det bestämmer vad det går att göra med produkten i fråga. Man kan till exempel inte leverera en produkt som är under utveckling eller avvecklad. Ofta behöver man också registrera när livscykelhändelser inträffar för att kunna mäta och jämföra, till exempel hur länge produkter lever och hur många produkter som utvecklas men aldrig lanseras.

Det här är ett första försök till en livscykel för produkter i en verksamhet som både utvecklar och tillhandahåller produkter.

Vi inför ett supertillstånd

Det som utmärker ett tillstånd är att det bestämmer objektets beteende, det vill säga vad det går att göra med objektet. Att produkten är öppen innebär vanligen att man kan skapa produktindivider av den, det vill säga tillverka, tillhandahålla eller sälja exemplar av produkten (eller tjänsten).

Man inser då kanske att de andra två tillstånden har en viktig sak gemensamt. I båda fallen kan man inte skapa produktindivider. Ifall man ser detta som en grundläggande skillnad mellan produkterna i produktkatalogen, huruvida man kan tillhandahålla produkten till kunder eller ej, kan man tänka sig att man låter livscykeln avspegla detta tydligare.

Vi kan då bygga livscykeln kring två huvudsakliga tillstånd Öppen och Stängd, där stängd har olika undertillstånd, det vill säga specialfall. Det är egentligen samma modell, fast nu att vi har generaliserat tillstånden Under utveckling och Avslutad till att bli specialfall av tillståndet stängd.

Vi inför ett nytt subtillstånd

Låt oss säga att vi sedan kommer på att vi också behöver hålla reda på om produkten är tillfälligt avstängd eller inte. Det är ju ett subtillstånd, det vill säga ett specialfall av stängd. Då får vi följande modell.

Observera att livscykeln inte säger något om eventuella produktindivider. En produktindivid, det vill säga ett exemplar av en produkt, har sin egen livscykel.

Produktens livscykel säger inte ens något om det finns produktindivider eller inte. Både öppna och stängda produkter kan ha produktindivider, utom produkter under utveckling som ju rimligen inte kan ha någon produktindivid, såtillvida det inte är vidareutveckling.

Allt som jag här beskrivit om produktlivscykel är tillämpligt på livscykel för kunder, avtal med mera. Till exempel kan även kunder och avtal vara tillfälligt stängda. Denna bredd är typisk för mönster. Även om jag beskriver mönster för saker som kunder eller produkter har de nästan alltid en mycket bredare tillämpning. 

Mönster 2: Leverantörsprodukt

Om man är återförsäljare av produkter från olika leverantörer har man olika produktidentiteter att hålla reda på. Dels har vi vår egen produktkatalog, dels har vi de olika leverantörernas produktkataloger. Vi behöver vidare veta hur en produkt hos oss motsvarar en viss produkt hos en leverantör. En och samma produkt hos oss kan ha olika produktidentiteter hos olika leverantörer. Det är fallet där det är ett företag som specificerar produkterna men som använder sig av olika leverantörer vilka levererar enligt beställning.

Vi behöver då matcha ihop leverantörens produkt med den egna produkten i ett många-till-många-förhållande. Det kan kanske ändras över tid vilken underleverantör vi använder oss av för en viss produkt. Därför kan vi behöva sätta start- och slutdatum för matchningen.

Det är säkert ännu vanligare för komponenter, att ett företag bygger produkter av komponenter som de specificerar och låter olika underleverantörer tillverka och leverera till sig. Mönstret kan då tillämpas på komponenter i stället för produkter.

Kanske du har idéer om hur man kan tänka annorlunda, eller synpunkter på modellerna jag visar? Dela gärna med dig av dina tankar.

/Peter Tallungs, IRM 

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

Modellmönster: Kundlivscykel – del 2: Livscykelhändelser

Detta är andra delen av två om en kundlivscykel, där vi tittar närmare på hur vi kan hantera de händelser som innebär att kunden byter status.

Mönster 1: Livscykelhändelser för kund

För att analysera och förstå rörelser i kundstocken behöver vi tydligt definiera och namnge vilka händelser som kan inträffa i en kunds livscykel och som innebär att en kund byter status, till exempel övergår från prospekt till aktuell kund. Man kan mena olika saker med händelser. Här har jag valt att bara se själva övergången, från ett tillstånd till ett annat, som en händelse. Det vill säga att jag här inte inkluderar den bakomliggande orsaken som orsakade tillståndsförändringen. Det gör modellen renare och tydligare och därmed mer användbar för analyser. Den bakomliggande händelsen som är orsaken till tillståndsövergången hanteras i nästa mönster i artikeln.

Jag har försökt att rita in varje möjlig tillståndsövergång, och därmed livscykelhändelse, som en pil i diagrammet här till höger och ge händelsen ett tydligt namn. Jag tror att det finns många andra förslag.

Pilen längst ner i diagrammet innebär att vi någon gång rensar ut minnet av den avslutade kunden. Det är ju också en händelse, men inte en händelse som har med kundrelationen i sig att göra utan bara med informationshanteringen som avbildar händelsen i verkligheten. Därför har den händelsen inte något namn och finns då inte heller registrerad någonstans, eftersom informationen om kunden då är borttagen.  

Nu kan vi skapa en entitet, kallad Livscykelhändelse, som har de sju möjliga händelserna i diagrammet ovan som förekomster.

Därefter kan vi skapa en entitet, kallad Kunds inträffade livscykelhändelse, för att registrera de kundhändelser som inträffar för kunden.

Observera att de två högra entiteterna i diagrammet tillhör ett regelplan. De definierar reglerna som finns, det vill säga vilka kundstatusar och livscykelhändelser som kan förekomma. När något händer i regelplanet, till exempel att en ny kundstatus läggs till, konfigureras verksamheten, det vill säga att vi förändrar reglerna för vad som kan inträffa. När något händer i det operativa planet, till exempel att ett prospekt blir ny kund, så opererar verksamheten.  

Om rubriker i diagrammet: Jag brukar gruppera entiteter och sätta rubriker i diagram enligt ovan. Modellen blir tydligare om man på detta sätt separerar regelplanet från det operativa planet. Det blir då tydligt var man sätter regler och var saker och ting händer operativt.

Men märk att vad som är konfigurering och vad som är en operativ händelse beror på sammanhanget. I modellen i stort kan man mycket väl hävda att detta att ett prospekt blir till aktuell kund är en konfigurering. De verkliga operativa händelserna är med detta större perspektiv först när en kund köper något. Skillnaden mellan det lilla sammanhanget och det stora visar bara att världen är fraktal. Den distinktion som gjorts mellan de två planen är endast för just detta sammanhang. Om man zoomar ut till ett större sammanhang kan mycket väl en operativ händelse (en ny kund) skifta till att ses som en konfigurering.

Mönster 2: Händelseorsaker

Vi har hittills definierat en händelse som det faktum att en viss tillståndsövergång har skett, oberoende av orsaken. Särskilt då det gäller avveckling av en kund brukar det vara värdefullt att registrera orsaken. Orsaken kan till exempel vara något av följande:

  • Kunden har varit inaktiv under en lång period (som man bör bestämma längden på).
  • Kunden har upphört att existera (avliden, utflyttad från landet, avvecklat företag).
  • Kunden har sagt upp sig.
  • Kunden har misskött sig, till exempel inte reglerat sina skulder till oss.
  • Kunden är misstänkt för brottslig verksamhet, eller på andra sätt blivit ej önskvärd.

Men även orsakerna till att man vinner prospekt eller att en kund skapas utan att tidigare varit prospekt är intressant att studera, för att förstå hur vi vinner kunder över huvud taget. Man kan förstås se och hantera allt detta som olika händelser, men jag anser att modellen blir renare och lättare att förstå, hantera, förändra och använda i analyser om man separerar livscykelhändelsen, det vill säga själva tillståndsövergången från den bakomliggande händelsen, det vill säga orsaken till tillståndsövergången. Om vi lägger till livscykelhändelser och händelseorsaker till modellen får vi modellen nedan. Vi ser nu att övre delen av diagrammet handlar om nuläget, kunders aktuella status, och nedre delen om kundernas historik, det vill säga vilka händelser som inträffat och varför. Och som tidigare visar högra delen av modellen själva regelverket, vad som kan inträffa, och vänstra delen det som verkligen inträffat.     

Enkel uppföljning

Om vi kan registrera kundhändelser på detta vis, blir mycket av uppföljningen enkel.
Vi kan till exempel göra följande:

  • Veta exakt hur många (aktuella) kunder vi har just nu och vi varje givet tillfälle i historien.
  • Veta och analysera churn rate (kundomsättning), det vill säga hur många kunder som tillkommer och försvinner under varje tidsperiod, och orsakerna till detta (så långt vi har kunskapen).
  • Analysera hur länge vi behåller kunder.

Om vi som brukligt har delat in kunder efter geografi, segment och kategorier av olika slag kan vi analysera beteendet för olika grupper av kunder enligt ovan utefter olika grupptillhörighet. Det finns då ingen ände på de analyser som vi direkt kan göra.

Inte bara kunder har en livscykel

Dessa modellmönster är användbara inte bara för kunder utan för alla företeelser vars livscykel man vill kunna analysera. Särskilt vanligt är det för produkter. Men även produktindivider, avtal och konton har ofta livscykler man vill hålla reda på.

Inte bara livscykler utan även andra cykler

Jag brukar kalla de övergripande tillstånden och händelserna i en företeelses liv för livscykel, men det finns ofta andra parallella förlopp som är värda att följa. För kunder kan det ofta vara att vi vill veta om de är i skuld eller inte, och händelsen att de hamnar i skuld och händelsen att vi aviserar skulden och när de reglerar skulden. På så sätt kan vi mäta hur lång tid det går, i allmänhet, innan betalning sker och vilka kategorier av kunder som är särskilt sena med mera.

Möjligheterna är stora. Vi kan med enkla grepp få kontroll på det dynamiska flödet i våra verksamheter. Det enda som behövs är en tydlig och genomtänkt struktur för tillstånd, händelser och händelseorsaker.

Kommentera gärna. Berätta hur du använder livscykler, händelser och händelseorsaker för att få koll på flödet i din verksamhet.  

Vad vi nu kan göra

Om man skapar en gemensam modell på detta sätt, i till exempel ett gemensamt Data Warehouse, och låter de olika kundsystemen rapportera enligt detta så får man på ett ganska enkelt sätt helt nya möjligheter. Den stora fördelen med detta är att vi inte behöver bygga om alla källsystem innan vi kan få gemensamma begrepp. Översättningen från de lokala begreppen görs där det finns bäst förutsättningar, det vill säga i de team som hanterar respektive källsystem. Alltså en pushmodell där den gemensamma modellen blir det semantiska formatet i kontraktet de måste rapportera enligt.

Det är en stor skillnad mot hur det vanligtvis är, det vill säga att man har flera olika system med olika, och vanligen oklara definitioner, och ingen gemensam modell. Analytiker får sitta och försöka tolka och pussla ihop data från olika system. Beroende på vem som tar fram rapporten blir resultaten olika. Jag får ofta höra från ledningar: ”Om jag ber om en viss rapport blir resultatet olika beroende på vem som tar fram den, och alla svar är sanna, fast på olika sätt och oklart hur.” Osäkerheten och bristande jämförbarhet är således ett problem. Ett annat problem är tidsåtgången och arbetsbelastningen. I en bank tog det analytikerna hela månaden att ta fram månadsrapporten. De hade därmed inte någon tid alls att göra det de ville göra och var bra på, att analysera resultatet och dra lärdom. Efter att vi implementerade en gemensam modell enligt ovan kunde de ta fram månadsrapporten på några sekunder. Det är svårt att tänka sig något annat vi som informationsarkitekter kan göra som ger större förändring på lika enkelt sätt.

Som vanligt skulle jag uppskatta om du ville kommentera detta. Kanske du har idéer om hur man kan tänka annorlunda, eller synpunkter på modellerna jag visar.

/Peter Tallungs, IRM 

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

Modellmönster: Kundlivscykel – del 1: Kundstatus

Kunder kommer och kunder lämnar. En kund kanske börjar som prospekt, blir sedan en aktuell kund för att senare lämna av någon orsak. Kunder har alltså en livscykel, med tillstånd och händelser. Om vi skapar en modell för denna livscykel, med namngivna och definierade tillstånd och händelser, öppnar sig många möjligheter till att analysera rörelserna i kundstocken.

Hur det brukar se ut

Vanligen har man i ett kundsystem ett fält för status. Där kan det finnas en kod för om kunden är ett prospekt (det vill säga någon person eller organisation som man registrerat för att man aktivt vill bearbeta denne för att bli en kund) eller en riktig kund (det vill säga en som köper ens varor eller tjänster). Vanligen har man även en kod för om kunden är avslutad. Fast det är ofta oklart hur lång tid en kund ska avstå från att köpa något för att betraktas som avslutad. Vanligen har man olika uppsättningar av koder i olika system och ofta är inte tillstånden väldefinierade.

Det är också vanligt att man blandat in flera betydelser i samma fält. Till exempel kan man ha en kod för att kunden är avslutad på egen begäran och en annan kod för om kunden är avslutad för att den inte betalt sina skulder. Det vill säga att ett och samma fält har två betydelser, dels status (att kunden är avslutad) och dels orsaken till att kunden är avslutad. 

I avsaknad av en gemensam modell med gemensamma definierade begrepp så blir det besvärligt att göra analyser av rörelserna i kundstocken, eller att ens säga hur många kunder man egentligen har. Något som varit bland det första jag ofta fått höra i de verksamheter jag kommit till är just: ”Vi vet inte ens hur många kunder vi har!”.

Hur kan man göra?

Det första man behöver göra är att skapa en gemensam modell för kundlivscykeln. Sedan kan man mappa alla de lokala koderna i de olika kundsystemen mot denna. Eller egentligen är det ju tvärtom man gör. Man går igenom och analyserar de olika statuskoderna som finns i källsystemen och vilka kunder som har vilken kod och varför. Med den direkta kunskapen vi då får om verksamheten kan vi skapa en gemensam modell som blir det gemensamma språket för hela verksamheten. Sedan låter man de olika källsystemen rapportera status och händelser, till exempel till ett Data Warehouse, för sina kunder enligt denna modell. På så sätt får man möjlighet till gemensamma rapporter som kan jämföras med varandra. Och detta utan att man behöver ensa hela verksamheten i alla sina delar samtidigt. Med tiden kommer de olika delarna av verksamheten att gravitera mot det gemensamma synsättet, fast varje del i sin egen takt. Om det inte händer så har vi förmodligen de facto ett lokalt behov som inte tillgodoses av den gemensamma modellen. Vad bra då att vi inte tvingade på varje hörn av verksamheten den gemensamma modellen. Det är så vi på samma gång kan få ett gemensamt språk och ändå kan låta varje del ha sina egenheter anpassade för de lokala behoven. 

I diagrammet visas hur en informationsmodell för en kundlivscykel kan se ut.

I det följande kommenterar jag modellen, hur de olika begreppen är definierade, namngivna och gestaltade.

Om status, även kallat tillstånd: Först behöver vi diskutera detta med status. Vad innebär en status egentligen? Med status menar vi ett tillstånd ett objekt (en förekomst av något) kan befinna sig i. För att vara ett tillstånd ska det vara definierat av ett visst beteende, det vill säga att tillståndet bestämmer vad det går att göra med objektet. Ett exempel: En aktuell kund kan vi sälja något till, men ett prospekt måste vi kanske först göra till kund för att kunna sälja till. En aktuell kund kan vi avsluta, men en avslutad kund kan vi inte avsluta igen.

Vi bör inte kontaminera våra tillstånd med att definiera dessa utifrån händelsen eller orsaken som gjorde att objektet nådde det tillståndet. Ett exempel: En avslutad kund kan vara avslutad av många olika orsaker. Men beteendet, det vill säga vad man kan göra med en avslutad kund, är precis detsamma oavsett orsaken till att kunden är avslutad. Vi vill förmodligen hålla reda på orsaken till att en kund avslutats men det blir fel om vi skapar en specifik status för varje orsak. Jag visar i nästa artikel hur man kan hålla reda på orsaken.

Om begreppet Kund: I dagligt tal menar man med begreppet Kund någon som just idag är kund. Men jag menar att det blir mer praktiskt om vi utökar begreppet och även inkluderar prospekt och tidigare kunder. Vi behöver ju ett begrepp för den intressent som gör hela resan, från prospekt (en som är en kandidat till att bli kund i en nära framtid, via aktuell kund (en som är kund i egentlig mening just nu) till avslutad kund. Jag tycker att det är mest praktiskt att kalla alla dessa för kunder, även om det avviker från dagligt språkbruk. Ty det finns inget annat namn som är användbart vad jag förstår.

Om tillståndet ”Aktuell”: Ofta kallar man detta tillstånd för ”Aktiv”, men min erfarenhet är att det kan bli ett problem med det namnet i många verksamheter. En kund som vi har en aktuell kundrelation till kan ju vara mer eller mindre aktiv över tiden. I perioder handlar kunden ofta och i perioder är kunden frånvarande. Det vill man ofta följa. Till exempel kanske man vill ”väcka” kunder som inte varit aktiva på ett tag, genom en riktad kampanj.

Om kunden har uteblivit under lång tid vill vi förmodligen se det som att vi förlorat kunden. Men huruvida kunden just nu är aktiv eller inte är ändå inte samma sak som om vi ser kunden som aktuell. Därför föredrar jag termen ”aktuell”. (I brist på bättre får jag väl säga. Du kanske har ett bättre förslag?).

Om att skriva definitioner i entitetsrutorna: Jag gillar att skriva definitionen av en entitet i själva diagrammet under namnet. Det är ett enkelt sätt att öka chansen till att läsaren direkt förstår vad som företeelsen står för.

Om definitionen för entiteten Kundstatus: Observera att definitionen för Kundstatus är ”Status som en kund kan ha”. Det för att inte blanda ihop det med den status som en kund verkligen har, som ju betecknas av attributet Kundstatus i Kund och relationen från Kund till Kundstatus. En förekomst av entiteten Kundstatus är ju en status en kund kan ha, och säger inget om hur många, om ens någon, som har denna status.

Om redundans i modellen för attributet/relationen Kundstatus: Attributet Kundstatus hos Kund och relationen från Kund till entiteten kundstatus står ju båda för samma sak och är därmed redundanta. En del tycker att det är fel att i informationsmodellen ha med en och samma sak två gånger. Det har jag också tyckt en gång men har med tiden vägt över till att jag alltid tar med det attribut (eller i vissa fall de attribut) som manifesterar relationen. Jag har flera skäl till detta:

  1. Jag vill se även relationer som attribut, för det är de i all väsentlighet. Till exempel Kundstatus är en egenskap hos en kund, det vill säga ett attribut. Att värdeförrådet finns uppräknat i en annan entitet ändrar inte detta. När jag i text dokumenterar attribut och relationer finns det ingen skillnad. Alla relationer behöver definieras, beskrivas och dokumenteras på samma sätt som attribut som inte är relationer.
  2. Spårbarheten blir tydligare om man sedan ska realisera modellen, som till exempel en databas. För då blir det ju databaskolumner, och jag vill gärna att det ska finnas en så direkt koppling som möjligt mellan informationsmodellen och databasen.
  3. I informationsmodellen vill jag gärna markera vad som unikt identifierar en förekomst, eftersom det hjälper läsaren att förstå vad en entitet egentligen är. Då måste jag ha med de attribut som ingår i en kompositnyckel, även om de är nycklar till andra entiteter och sålunda manifesterar relationer.

Om att redovisa förekomsterna av till exempel Kundstatus: Det är inte bara entiteter, attribut och relationer som vi behöver namnge och definiera. Då det gäller attribut med ett antal definierade förekomster (som i exemplet Kundstatus) så behöver vi namnge och definiera varje förekomst. Det rör sig ju i stort sett alltid om centrala verksamhetsbegrepp som används i rapporter och analyser. Det är ett vanligt missförstånd att det räcker med att definiera och dokumentera entiteter, attribut och relationer. Men förekomster av detta slag är minst lika viktiga, men nästan alltid ignorerade. 

Det som behövs dokumenteras för varje förekomst är i regel en kod, eller ett kortnamn, ett namn och en definition. Det kan också behövas ett ordningsnummer för att visa förekomsterna i en logisk och återkommande sorteringsordning i en valbar ruta eller i en rapport. Vi kan även behöva giltigt från och med- samt till och med-datum, om vi kommer att behöva hantera förändringar.

Jag dokumenterar förekomsterna i textdelen av modellen, med tar vanligen med dem även i diagrammen. Det underlättar förståelsen av diagrammet avsevärt. Jag ser till att de rutor i diagrammet där förekomsterna listas skiljs ut tydligt från entitetsrutorna.

Om kod, för till exempel Kundstatus: Förr var det så att alla värden för en status (ett tillstånd) hade en kod. Det var så vanligt att den entitet som jag i modellen ovan kallar för Kundstatus, skulle många kallat för Kundstatuskod. Skälet till att man hade koder var att man behövde snåla med utrymmet i databaser och därmed behövde använda så få tecken som möjligt. Men idag finns inte just den begränsningen. Men det är ändå så att vi ofta behöver ett kort namn (vare sig man nu ser det som en kod eller ett kortnamn, gränsen är flytande) för saker och ting, speciellt då man ska visa saker i kolumner i en rapport eller dylikt. Så jag är kluven. I varje fall behöver vi någon form av kod eller kortnamn, kanske både och. Ibland ett maximalt kompakt (bara ett tecken), ett kort (tre eller fyra tecken) och ett fullt utskrivet namn.

Om tillståndsdiagram i informationsmodellen: Jag har alltid med tillståndsdiagram (Harel statechart eller state machine) i diagramdelen till min modell, som visat ovan. Men observera att tillståndsdiagrammet i det exemplet är ofullständigt. Kunder tar inte alltid den raka vägen. Somliga blir kunder utan att först vara prospekt. Somliga som är avslutade återkommer och så vidare. Jag kommer i nästa artikel komplettera tillståndsdiagrammet och även hantera händelser och händelseorsaker.

Till dess skulle det vara roligt att höra dina synpunkter och erfarenheter. Vad håller du med om och vad skulle du vilja göra annorlunda?

/Peter Tallungs, IRM 

Modellmönster: Intressentroller

Företag och andra organisationer har relationer till olika intressenter. Dessa intressenter är personer och organisationer som har specifika roller i relation till den verksamhet du modellerar. Det kan vara kunder, leverantörer, anställda, interna enheter, kontaktpersoner, avtalsparter eller andra intressentroller. Vi behöver begrepp och strukturer för att hantera dessa relationer. Vilka strukturer som är mest lämpade beror på vilka relationer vi behöver hålla reda på och vad vi behöver hålla reda på för varje relation. Detta är en central uppgift i varje organisation och ett kunskapsområde där informationsmodellering är ett centralt verktyg. Jag beskriver i denna artikel ett antal modellmönster som har med intressenter att göra. 

Mönster 1: Generalisering med Intressent

När två entiteter har samma attribut eller relationer söker man instinktivt efter en generalisering.
Generaliseringen av Person och Organisation är ett klassiskt exempel på en namnlös företeelse, något som alla känner till och använder men som det saknas ett naturligt namn för. ”Part” (engelskans ”Party”) eller ”Intressent” (engelskans ”Stakeholder”) är de namn som oftast används för den generaliserade företeelsen.

Intressent är en generalisering (supertypen) av Person och Organisation.

Mönster 2: Intressentroll

Många verksamheter behöver hålla reda på olika typer av intressenter, inte bara kunder. Det är då naturligt att dela in dem efter vilken roll de spelar i förhållande till den verksamhet du modellerar. Leverantör, Kund eller Partner är bara några exempel bland flera. Det är vanligt att se dessa roller som specialiseringar av intressent.

Vad vi då har avbildat är egentligen inte intressenterna i sig utan endast intressenterna i den roll de spelar för oss. Supertypen står då för den generaliserade rollen ”Intressent”. Fördelen är att det är en enkel modell. Men nackdelen blir att vi då inte skiljer ut de egenskaper som intressenten har oberoende av den roll den spelar för oss i motsats till de egenskaper som handlar om relationen till vår verksamhet.

Ett exempel: Om en organisation är både kund och partner till oss så förekommer den två gånger, en gång som kund och en annan som partner. Egenskaper som organisationens namn, adress, typ av organisation med flera som inte har med den specifika rollen att göra blir då redundanta. Det behöver i och för sig inte vara ett problem, men vi bör vara medvetna om den förenkling vi gjort. I de fall vi har intressenter av olika slag och där en intressent ofta förekommer i flera roller så kan den förenklingen bli ett hinder. I så fall behöver vi använda mönster 3.

Mönster 3: Intressent i intressentroll

Om vi tydligare behöver skilja på å ena sidan uppgifter som hör till intressenten i sig, oberoende av vilken roll denne har till oss, och å andra sidan uppgifter som har med den specifika rollen att göra, då passar detta mönster.

Inget av dessa två sätt (mönster 2 och mönster 3) att se på sina intressenter är objektivt rätt eller fel. Båda sätten har styrkor och svagheter, så vilket man ska välja beror på sammanhanget.

En sak vi inte hanterat i detta mönster är det vanliga fallet att personer inte alltid kan förekomma i samma uppsättning av roller som organisationer. Om vi behöver tydliggöra detta i vår modell kan vi tillämpa mönster 4. 

Mönster 4: Organisation och person i intressentroller

Ofta kan både organisationer och personer vara intressenter. Men det kan skilja vilka roller de kan ha i förhållande till vår verksamhet.

Kontaktperson är en roll en person har hos en intressent utifrån den specifika roll intressenten har i förhållande till vår verksamhet. Om en viss organisation är både leverantör och kund till oss så har den organisationen vanligen olika kontaktpersoner, en som leverantör och en annan som kund.

Dock är det viktigt att vi inte blandar ihop dessa generella och varaktiga intressentroller med de specifika roller en intressent kan ha i ett visst sammanhang. Vilket tar oss till mönster 5. 

Mönster 5: Avtalsroller

En intressent har vanligen en roll i olika specifika sammanhang, till exempel i olika avtal.

Det är viktigt att skilja på den generella roll en intressent har i vår verksamhet och den specifika roll intressenten har i ett specifikt sammanhang, till exempel ett avtal. De har ofta samma namn men är olika saker. Jag kan vara kund till företaget och jag kan vara avtalsparten ”kund” i ett specifikt avtal.

Det här är ett mönster som täcker det mesta man kan behöva hantera beträffande intressenter i sina intressentroller.

Refaktorera till enklast möjliga – men inte enklare!

Varje mönster har styrkor och svagheter och kan därmed passa mer eller mindre bra i olika verksamheter och för olika syften. Därför behöver vi förstå de olika mönstren och när de passar det vi behöver hantera. Att välja ett mönster som tar höjd för precis allt är förmodligen lika fel som att välja det enklaste som inte ta höjd för något. Ty ett alltför komplicerat mönster innebär en onödig komplexitet som för med sig en hanteringskostnad som verksamheten behöver bära framgent. Vi bör tänka på Einsteins devis: ”Allt bör göras så enkelt som möjligt men inte enklare”. Vi ska alltså lyfta fram och tydliggöra den inneboende komplexitet som finns i en verksamhet men sträva efter att reducera all onödig och pålagd komplexitet.

Vi behöver använda vårt omdöme och vår erfarenhet. Vi ska inte välja ett mönster för att sedan låsa oss till det i fortsättningen. I stället behöver vi refaktorera (stegvis omstrukturera) våra modeller allt eftersom vi lär oss mer om vår domän. Jag refaktorerar till ett mer kompetent mönster när jag ser att modellen inte uttrycker det jag behöver uttrycka. Och jag refaktorerar till ett enklare mönster när jag märker att saker kan uttryckas enklare och ändå räcka till.

Vi kan växa som informationsmodellerare genom att utveckla den repertoar av mönster vi har och på djupet förstår. Vi gör det bäst genom att dela, diskutera och tillämpa olika mönster.

Jag vill försöka ange källor för de mönster jag presenterar men just mönstren i denna artikel är sånt allmängods att det känns hopplöst att spåra dem.

Kanske du som läser detta kan komplettera med varianter på samma tema? Hur ser ni i er verksamhet på de olika intressentrollerna? Hur fungerar det?

/Peter Tallungs, IRM 

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

Om mönster för informationsmodeller

”När vi gör en informationsmodell brukar vi inte börja med endast ett blankt papper och grundprinciperna inom vårt område. Precis som designers inom andra områden så tillämpar och anpassar vi lösningar som har visat sig användbara tidigare. Utvecklingen och användningen av standardlösningar (”modellmönster”) är en viktig del av informationsmodelleringens praktik.” Detta är ett citat av Graeme Simsion, den australienske författaren till en av de viktigaste böckerna om informationsmodellering ”Data Modeling Essential”.

Repertoarer av mönster

Om jag vill lära mig att spela schack lär jag mig kanske först hur brädet och de olika pjäserna ser ut, sedan hur de får lov att flyttas, därefter att vi turas om att göra våra drag och vad spelet går ut på. Detta tar inte så lång tid att lära sig. Har jag då lärt mig allt som där finns att lära? Nej, knappast, jag har knappt ens börjat! Resten av min resa inom området, från gröngöling till mästare, handlar om mönster. Inte så mycket om enskilda drag, mest om kombinationer av drag. Många kombinationer är kända och namngivna. Andra hittar jag själv fram till och kan dra ess ur rockärmen när så passar.

Det är så det går till inom i stort sett alla områden av mänsklig verksamhet. Både som kollektiv och individer har vi en repertoar av mönster som vi uppfinner, tillämpar, utvecklar och traderar.

Så har vi alltid gjort inom olika områden. Det som jag här benämner mönster kan kallas för en mängd olika saker men det har, i olika sammanhang, blivit mer vanligt att prata om just ”mönster”.

Mönster-begreppet inom informationsmodellering

Inom informationsmodellering har begreppet mönster använts och definierats på följande sätt:

  • Data Model Patterns (Dave Hay)
    ”Common situations that are present in a variety of business and government agencies, and which can be modeled in a standardized way – conventions of thought.”
  • Analysis Patterns (Martin Fowler)
    ”[in object-oriented analysis we] are regularly seeing problems repeat themselves.”
    ”A pattern is an idea that has been useful in one practical context and will probably be useful in others.”
  • Universal Patterns for Data Models (Len Silverston)
    ”The common underlying structures that are applicable to all data models.”
  • Patterns of Data Modeling (Michael Blaha)
  • Patterns and generic models (Graeme Simsion och Graham Witt)

Hur tanken om mönster växt fram och nått området informationsmodellering

Jag har tidigare gjort grafen nedan för att visualisera min tolkning av hur idén om mönster växt fram; från byggnadsarkitektur, via programvaruutveckling till informationsmodellering.

Den som först började tala om mönster i den här meningen var byggnadsarkitekten och designteoretikern Christopher Alexander. Det handlade då om byggnadsarkitektur, allt från stadsplanering till inredningsarkitektur. Hans filosofi har inspirerat många inom olika designdiscipliner, inte minst inom systemutveckling och verksamhetsarkitektur.

Viktigt om mönster

Det finns i några av idéerna formella krav på hur man ska strukturera beskrivningen av ett mönster. De härstammar från Christopher Alexanders idéer om designmönster. De är lite olika men kan se ut så här:

  • Namn
  • Det generella problemet som ska lösas
  • Den generella lösningen
  • Exempel på konkreta lösningar
  • Konsekvenser
  • Samband med andra mönster

Det som ibland har missförståtts, är att mönster inte är ett självändamål. Det var något som hände inom programvaruutveckling efter 1994 när designmönster gjorde sin entré i programmerarvärlden genom boken ”Design Patterns”. Då blev det en sport att klämma in så många som möjligt av bokens designmönster i sin kod.

Christopher Alexanders idé var att alla mönster inom ett område skulle fungera som ett språk för olika designlösningar. Han kallade det ett mönsterspråk (”Pattern Language”). Tanken är att vi tillsammans kan tradera olika lösningar samt diskutera, värdera och tillämpa dessa. Varje mönster har sina styrkor och svagheter, och passar olika bra beroende på sammanhanget. Vi ska inte bara kunna tillämpa mönster utan också välja bort ett mönster när det inte passar.

Mönster för informationsmodeller

Jag kommer i artiklar framöver att presentera ett antal mönster för informationsmodeller. En del av dessa mönster har jag lärt mig från olika böcker och sedan tillämpat i olika sammanhang. (Eller kanske glömt varifrån jag fått inspirationen. Vem kan komma ihåg var man får allt ifrån?) Jag kommer inte att vara så noga med strukturen på beskrivningen, utan min tanke är att grundligt presentera och diskutera varje mönster. I det sammanhanget kommer jag också, när det passar, ta upp andra mer grundläggande frågor runt modellering.

Syftet är att dela kunskap och erfarenheter inom informationsmodellering, samt att inspirera till en dialog runt detta. På så sätt kan vi kanske få igång en utveckling inom vårt kunskapsområde.

Källor för modellmönster

Jag har angivit några av mina källor ovan och jag kommer fortsättningsvis att försöka ange källorna för de mönster jag beskriver. Var har du hittat dina mönster? Har du något tips på en bra källa så tror jag att vi alla som läser detta blir tacksamma.

/Peter Tallungs

I och med denna artikel har vi ett sommaruppehåll. Torsdag 12 augusti kommer nästa artikel i denna serie om informationsarkitektur publiceras.

Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Saker jag stjäl från UML

UMLs klassdiagram har ett par uttrycksmedel som jag saknar i de vanliga ER-notationerna. Det finns inget som hindrar att vi ”lånar” in dessa.

Jag brukar använda den vanligaste notationen för informationsmodeller, det vill säga JMIE (James Martin Information Engineering), kanske mest känd som ”Crow foot notation” (kråkfotsnotation). Främst för att den är vanligast i de sammanhang jag jobbar. Men i den notationen saknar jag ett par saker som finns i UML. Då brukar jag helt sonika låna in dessa.

Ett försvar för att låna från olika notationer

Jag kan tänka mig att en och annan nu sätter kaffet i vrångstrupen bara av tanken på att blanda notationer. Man tycker det är viktigt att vara korrekt, följa regler och att alla gör likadant.

Mitt försvar är att det finns en tid för regler och konsekvens, och det finns en tid för experimenterande och utveckling. Informationsmodellering har som kunskapsområde stått still, i min mening stelnat redan för flera decennier sedan.

Ska vi få till en utveckling av området behöver vi experimentera. Vi behöver vara nyfikna, inspireras från andra områden, kombinera idéer och prova oss fram. Standardisera kan vi vänta med tills vi kommit fram till något som känns någorlunda stabilt. Och dit har vi en bit kvar.

I det följande redovisar jag det jag saknar i vanliga ER-notationer men som finns i UML, och som jag därför fräckt och oblygt lånar in.

Supertyp och subtyp separerade från varandra

Om en entitet är en generalisering av två eller flera andra så ritar man i de vanliga ER-notationerna den generaliserade entiteten (supertypen) som en ram runt de specialiserade entiteterna (subtyperna).

I UML ritar man i stället subtyperna separerade från supertypen, och en relationslinje emellan dessa med en ofylld triangelspets i änden mot supertypen.

(Det finns dock även en del äldre ER-notationer som också separerar super- och subtyp på samma sätt som UML. Relationen kallas då
”is-a”-relation)

Båda ritsätten har sina styrkor och svagheter menar jag.

Fördelen med ritsättet med supertypen som ram är att det intuitivt ger en bättre förståelse för vad det handlar om. Relationen mellan sub- och supertypen är inte en relation mellan två separata företeelser, utan en relation mellan två begrepp, ett mera generellt och ett mera specifikt. En sådan relation har alltså en helt annan natur än de vanliga relationerna som övriga streck representerar. Därför är det bra med ett ritsätt som kraftigt avviker från övriga relationer.

Supertypen är ett mer generellt begrepp för samma företeelser som subtypen. En förekomst av subtypen är samtidigt en förekomst av supertypen. Det finns på så sätt en likhet med de Venndiagram som vi minns från skolans mängdlära. Ritsättet gör att risken minskar att en ovan betraktare av en informationsmodell ska tro att en motorfordonsförsäkring är något annat än en försäkring.

Med UMLs ritsätt är det däremot lätt för en ovan betraktare att tro att vi, precis som med andra typer av relationer, har två olika företeelser med olika förekomster. Där har vi svagheten att relationer med så helt väsensskilda naturer har så lika grafisk gestaltning.

Men det finns också en baksida med ritsättet i JMIE. Det finns tillfällen då det blir omöjligt att rita subtyperna inuti supertypen. Det är när varje subtyp behöver veckla ut sig till ett eget ämnesområde med många egna entiteter runtomkring som är unika för just det ämnesområdet. När det behovet uppkommer ritar jag som i UML, trots att jag i övrigt använder JMIE. Det vill säga sub- och supertyper för sig, förbundna med en linje med en ofylld triangelformad pilspets.  

Komposition

Det är vanligt att två entiteter har en särskilt existentiell koppling. Det vill säga att en förekomst av en entitet inte kan existera oberoende av en förekomst av en annan entitet. Ett exempel är en faktura med en eller flera fakturarader. Relationen mellan faktura och fakturarad innebär en mycket starkare koppling än vanliga relationer. En fakturarad har nämligen ingen självständig existens, den kan aldrig existera utan att tillhöra en faktura, den kan inte byta faktura, och om fakturan raderas så försvinner också fakturaraden. I en del äldre notationer kallas den beroende entiteten för beroendeobjekt. Jag tycker att en informationsmodell blir mycket tydligare om man tydligt kan uttrycka den starka relationen.

I de vanliga ER-notationerna finns det ingen möjlighet att uttrycka detta på annat sätt än med den vanliga min 1 – max 1-symbolen, trots att det är en koppling som är väsensskild från vanliga min 1 – max 1-kopplingar.

I UML kallas den relationen komposition och uttrycks med en romb och en pilspets enligt bild. Egentligen ska romben vara fylld men den symbolen finns inte som standard i Visio så vi får nöja oss med en ofylld.
Inom parentes sagt: Den ofyllda romben uttrycker i UML ett aggregat, vilket i praktiken är samma som en min 1 – max 1-koppling, och därför är tämligen meningslös. Jim Rumbough, en av grundarna till UML, liknade det själv vid placebo och Martin Fowler ägnar en hel uppsats till att avfärda konstruktionen. 

Så fort jag har en relation i ett ER-diagram som har denna täta koppling så markerar jag det med en romb. På så sätt tycker jag att modellen blir tydligare. Man ser då vad som har en självständig existens och vad som är en integrerad del av en annan företeelse. Dessutom brukar jag placera entiteterna med den beroende entiteten placerad under och med vänsterkanten indragen från huvudentiteten, som bilden till höger visar. På så sätt vill jag tydlig signalera det nära och underställda beroendet.

Vilka innovativa idéer har du?

Jag vill med detta inspirera till experimenterande. Att vi kan lösa modellerings- och gestaltningsproblem på ett nyskapande sätt när så behövs. Vi ska inte vara rädda för att göra fel och måste inte alltid ”play by the book”. Ett område kan bara gå framåt när någon med ett tydligt syfte bryter mot ingrodda regler och ”sanningar”. Den lilla risken vi får ta är att våra modeller därmed blir lite brokigare. Men det är ett lätt pris om det kan bidra till att avancera hela vårt område.

Nu är det din tur. Vad brukar du göra annorlunda?

/Peter Tallungs

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 24 juni. Då handlar det om mönster för informationsmodeller.
Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Modellera strukturer med instansdiagram

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

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

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

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

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

Exemplet ovan

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

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

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

Det som är speciellt med instansdiagram

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

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

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

/Peter Tallungs, IRM

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

Modellera livscykler med tillståndsdiagram

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

Verksamhetsobjekt har livscykler

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

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

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

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

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

Händelser och tillståndsövergångar

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

Orsaker till händelser

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

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

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

Vad är då ett tillstånd?

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

Tillståndsdiagram

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

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

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

Men är det inte det vi har processmodellen till?

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

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

Sambandet mellan en processmodell och ett tillståndsdiagram

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

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

Sambandet mellan ett ER-diagram och ett tillståndsdiagram

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

Var i informationsmodellen placerar jag tillståndsdiagrammet?

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

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

Exempel på användning av tillståndsdiagram

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

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

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

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

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

Vad är en informationsmodell egentligen?

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

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

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

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

/Peter Tallungs, IRM

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

Vilken notation är bäst?

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

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

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

ER-modelleringens historia

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

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

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

ERD-notationer

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

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

Aspekter att jämföra

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

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

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

Jämförelse 1: Förekomst

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

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

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

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

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

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

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

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

Jämförelse 2: Uttryckskraft

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

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

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

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

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

Resultat: Ett plus till UML klassdiagram.

Jämförelse 3: Tydlighet

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

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

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

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

Resultat: Jämnt skägg alltså.  

Jämförelse 4: Ändamålsenlighet

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

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

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

Jämförelse 5: Verktygsstöd

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

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

Resultat: Återigen oavgjort.

Jämförelse 6: Kunskap

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

Resultat: Oavgjort.

Jämförelse 7: Kultur

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

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

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

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

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

Konklusion

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

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

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

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

Exotiska svenskar

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

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

Avgränsning

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

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

Vad tycker du?

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

/Peter Tallungs, IRM

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