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

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

/Peter Tallungs, IRM, 2021-12-09

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

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

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

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

Lösning:  

• Definiera för varje modell explicit det sammanhang för vilket modellen gäller.

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

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

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

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

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

Tidiga tecken på fragmentering är följande:

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

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

Alternativ 1: Konsolidera modellen

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

 

 

 

Alternativ 2: Splittra modellen

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

Mönster 2: Kontinuerlig integrering (Continuous Integration)

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

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

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

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

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

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

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

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

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

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

Mönster 5: Konformist (Conformist)

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

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

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

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

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

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

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

Mönster 6: Antikorruptionslager (Anticorruption Layer)

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

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

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

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

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

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

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