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

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

/Peter Tallungs, IRM, 2021-12-16

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

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

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

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

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

Det som talar för en bredare kontext:

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

Det som talar för en smalare kontext:

• Modellen blir enklare, vilket medför att kommunikationen mellan personer blir enklare, så länge man håller sig inom modellens kontext.

• Enklare modellering, ty bredare modeller behöver vanligen bli mer abstrakta för att täcka fler alternativ.
• Den kontinuerliga integreringen blir enklare. En smalare kontext betyder färre direkta intressenter med mer likartade behov som man behöver täcka.
• Med separata modeller för olika intressenter kan man bättre tillgodose specifika behov och även specifika jargonger hos specialiserade grupper.

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

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

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

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

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

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

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

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

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

Fall 2: Du ska designa ett nytt it-system

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

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

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

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

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

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

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

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

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

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

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

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

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

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

/Peter Tallungs, IRM