Modellmönster: Ansvarsförhållanden mellan parter 

I en verksamhet behöver man hantera olika typer av ansvarsförhållanden mellan parter. De man kanske först tänker på är de som uttrycks i organisationshierarkier, men det är bara ett av en mängd olika slag av ansvarsförhållanden. I denna artikel beskriver jag några användbara mönster för att hantera förhållanden där en part har ett ansvar gentemot en annan. Jag passar också på att ta upp hur man kan införa ett regelplan i sin modell. Det är ett effektivt sätt att göra sin informationsmodell tydligare. 

/Peter Tallungs, IRM, 2021-08-19

Mönster 1: Organisationshierarki med explicita nivåer

Det här är ett vanligt och naturligt sätt att modellera organisationshierarkier, liksom hierarkier i övrigt. Varje typ av organisationsenhet har sin egen entitet. Det har sin stora fördel i att det känns naturligt, det vill säga överensstämmer med den bild vi har naturligt i huvudet. Men det har en begränsning. Om organisationsstrukturen ändras – om till exempel nivån med avdelningar tas bort för att platta till strukturen – måste vi bygga om modellen helt och hållet.

Mönstret ger alltså en tydlig och naturlig men inte speciellt flexibel modell.
Det räcker till i de fall vi inte behöver hantera historik, det vill säga hur organisationen förändras över tid.

Mönstret passar inte heller då vi behöver en mer generisk modell som ska användas för flera olika organisationer.

Mönster 2: Organisationshierarki med generaliserade organisationsenheter

Vi kan skapa en mer generell entitet som gäller för alla organisationsenheter oavset

t typ. Vi kan sedan ha mer dynamiska regler för vilka subtyper som finns samt begränsningsregler för hur de kan relatera till varandra.

Detta mönster har möjligen en något större flexibilitet än föregående, det vill säga att det blir lite lättare att förändra organisationsstrukturen. Men vad vi nu vunnit i flexibilitet har vi förlorat i tydlighet.

Mönster 3: Flera organisationshierarkier

Ofta har man två eller flera parallella organisationshierarkier, det vill säga multipla rapportvägar. Det avbildar man på enklaste sätt genom att ha fler än en moder-dotter-relation.

(Subtyper och begränsningsregler har inte tagits med i diagrammet här).

Men om vi vill hantera egenskaper hos själva relationen, till exempel historik som vilken tidsperiod relationen gällde för, behöver vi lyfta själva relationen till att representeras av en egen entitet. Vilket tar oss till nästa mönster.

Mönster 4: Organisationshierarki med relationsobjekt

Vi kan göra själva relationen till en egen entitet. Då öppnas flera möjligheter:

1. Nya typer av ansvarsrelationer kan lätt läggas till.
Vi kan typa relationerna så att en organisationsenhet kan ingå i flera hierarkier samtidigt. Man kan till exempel ha en organisationshierarki baserad på produkt och en annan baserad på säljorganisation.

Om vi endast har två hierarkier är detta knappt värt besväret, men för fler hierarkier än så är det användbart.

2. Vi kan ge varje relation en tidsperiod då den gäller.
På så sätt kan vi hantera förändringar över tid, till exempel att en enhet byter plats i strukturen.

När man på detta sätt gör entitetstrukturen mera generell blir det viktigt att i text uttrycka de regler som begränsar vilka relationer som är möjliga. Observera att reglerna i detta fall läggs på själva relationen.

Vi kan använda detta som en metamodell vilken kan härbärgera alla möjliga ansvarsstrukturer mellan organisationsenheter.

Mönster 5: Relationsobjekt för ansvarsförhållanden för olika typer av intressenter

Det förra mönstret (mönster 4) handlar om organisationsenheter där en organisationsenhet kan ha en relation till en annan organisationsenhet, enligt en viss regel för en viss tidsperiod.

Alltid när något gäller för organisationer eller organisationsenheter kan man fråga sig om detsamma inte kan gälla för andra typer av intressenter, som till exempel personer. I just detta fall kan man ställ sig frågan: ”Kan en person ha en relation till en organisationsenhet eller till en annan person, enligt viss regel, för en viss tidsperiod?”. Eller motsvarande fråga för organisationer som helhet.

Om vi byter supertypen Organisationsenhet mot Intressent kan vi täcka en vid uppsättning relationer mellan parter, till exempel ledningsrelationer, anställningar och kontrakt.

Vi har emellertid introducerat komplexitet genom att vi nu täcker en mycket större variation i relationer mellan parter än bara mor-dotter-förhållanden. Det krävs regler för att styra vilka parter som kan ingå i vilka relationer.

Det kan vi hantera genom att introducera något i modellen som kan kallas regelplan.

Mönster 6: Relationer styrda av ett regelplan

Vi kan dela upp vår modell i två delar.

• Operativa planet registrerar de dagliga förhållandena (eller händelserna) i domänen. I detta fall vilka konkreta ansvarsförhållanden som finns i verksamheten
• Regelplanet håller de regler som styr strukturen i det operativa planet. I detta fall vilka typer av parter det kan finnas och vilka typer av ansvarsförhållanden som kan finnas för varje kombination av två typer av parter.

På så sätt definierar varje förekomst i regelplanet en tillåten konfiguration av förekomster i operativa planet.

Exempel: Ett specifikt ansvarsförhållande (en länk mellan två specifika parter) kan endast skapas mellan parter enligt vad som är angivet i Typ av ansvarsförhållande.

Det är intressant att notera hur det operativa planet speglas i regelplanet. De två planen har liknande men inte identiska relationer. Det operativa planet registrerar de specifika parterna i ett visst ansvarsförhållande medan regelplanet definierar vilka typer av parter som är tillåtna för en viss typ av ansvarsförhållande. Detta är ett typiskt mönster: Flervärd mappning i regelplanet för att visa tillåtna typer för en envärd mappning i operativa planet.

Metadata utrycks nu inte längre bara av entitetsstrukturen utan även av förekomsterna i regelplanet. För att systemet (det vill säga informationssystemet i bred bemärkelse) ska fungera räcker det inte med att implementera modellens struktur (till exempel skapa de tabeller som behövs). Vi måste också instansiera objektförekomsterna i regelplanet. Det vill säga till exempel att populera de tabeller som beskriver vilka parter som kan finnas och vilka relationer varje kombination av dessa kan ingå i. Att instansiera regelplanet innebär att konfigurera systemet, det vill säga verksamheten.

Notera att mappningen från Part till Typ av part ersätter subtypning av Part. Att en mappning definierar en subtyp kallas ibland ”power type”.

När ska detta mönster användas? Vi kan inte undvika att hantera den inbyggda komplexitet som finns inom en domän. Vi kan bara fråga oss vilket mönster som enklast representerar den komplexitet vi behöver hantera. Se upp bara så att detta mönster inte blir ett catch-all för alla typer av relationer mellan två parter.

Om regelplan i modeller

Det är fruktbart att tänka i begreppen regelplan och operativt plan när man modellerar och att hålla isär dessa grafiskt inom ett ämnesområde. Fast jag skriver aldrig ut termen ”regelplan” utan något i stil med ”Regler för kund” eller ”Produktregler” som rubrik för den delen av ämnesområdet.

Regelplan kan ibland också kallas typplan eftersom de oftast innehåller entiteter vars instanser definierar typer. Det är också ett metaplan rent definitionsmässigt, men jag tycker vi ska undvika namnet ”metaplan”, för begreppet ”meta” är ett alldeles för vitt begrepp, det vill säga att det kan betyda lite vad som helst och kan därmed förvirra mer än det tydliggör. Metadata är ju data om data och det rymmer allt möjligt.

Att skikta en modell – eller vanligare ett ämnesområde inom en modell – på detta sätt är ett mycket kraftfullt sätt att ordna sin domän. Det är inte speciellt känt, men jag hoppas att det härmed sprider sig.

Var kommer dessa mönster från

Jag har hämtat dessa mönster från Martin Fowlers bok ”Analysis Patterns”, från 1997. Det är bok som inte många känner till, i det närmaste en apokryfisk skrift, som jag menar har ett stort värde. Speciellt vill jag nämna detta med regelplan, vilket jag en gång lärt mig från denna bok, och använt i tjugo år i mina modeller. Det är mer eller mindre nödvändigt för att hantera lite mer komplicerade verksamhetsdelar.

/Peter Tallungs, IRM