Taggarkiv: Strategimönster

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.

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. Då kan det 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

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

Strategimönster för informationsarkitekter – del 1: Introduktion

Föregående artikel (Den omöjliga drömmen om den allomspännande informationsmodellen) handlade om att vi i en större verksamhet inte kan komma ifrån att olika delar av verksamheten har olika modeller som lever sina egna liv, mer eller mindre. Som informationsarkitekter måste vi därmed hantera att vi har olika modeller som ofta säger olika saker. Denna artikel är starten på en serie artiklar som handlar om de situationer som kan uppstå i dessa sammanhang och hur vi kan agera.

Utmaningen med flera modeller

Är det detta vi har att välja på? En monolitisk jättemodell eller flera mindre modeller som inte hänger ihop riktigt. Den monolitiska modellen är ohanterlig och trögrörlig, full av subtila dupliceringar och motsägelser. Flera mindre modeller kan inte användas för att lösa problem som spänner över hela verksamheten. De har konsistensproblem i varje integrationspunkt och hänger vanligen ihop endast med snabbt hopsydda ad-hoc-kopplingar mellan sig.

Det känns kanske som att välja mellan pest och kolera.
Låt mig inskjuta något om detta med pest eller kolera: Enligt vår kära professor Agnes Wold är valet självklart. Om du någon gång skulle få det valet ska du välja kolera. Pest är en förfärlig sak, med ganska säker snabb död. Kolera är däremot hanterbar. Du behöver inte ens läkarhjälp. Bara någon som ser till att du kontinuerligt får i dig vatten med salt och socker i. På samma sätt är det med valet mellan en monolitisk jättemodell och flera mindre. Du bör alltid välja flera mindre. De problem som uppstår går att hantera ganska enkelt.

Om du är med på det som föregående artikeln hävdade, att drömmen om den allomspännande informationsmodellen är omöjlig, så finns det inget val. Vi kan inte komma ifrån att vi behöver hantera flera olika modeller. I varje fall inte i en lite större verksamhet. Och att varje sådan modell behöver leva sitt eget liv, mer eller mindre.

Utmaningen blir då att modellerna behöver kunna samverka tillräckligt bra för att stödja gemensamma processer. Det handlar mest om förhandling och beslut mellan olika team. Vi befinner oss då i skärningen mellan design och politik.

Hur ska vi bryta ner domänen i flera modeller och hur ska vi hålla ihop den?

Vi behöver låta olika modeller leva parallellt med varandra i olika delar av organisationen. Men det betyder inte att vi kan släppa allt vind för våg. Vi behöver ha någon form av gemensam styrning. Vi behöver göra genomtänkta val av följande:

  1. Vilka ska de olika modellerna vara?
    En modell representerar en del av domänen som tillåts leva sitt eget liv och därmed divergera från helheten. Det är beslut vi måste ta gemensamt och även ompröva över tid, när så behövs.
  2. Hur ska modellerna relatera till varandra?
    Vi behöver fortfarande hantera en helhet. Det kan vi inte komma ifrån. Vi behöver hålla två saker i huvudet samtidigt. Vi behöver ta proaktiva beslut om vad som behöver vara gemensamt och enhetligt tvärs över hela domänen. Och vi behöver vara pragmatiska med vår förståelse för vad som inte behöver vara eller inte kan vara enhetligt.

Vi behöver skapa en tydlig gemensam bild av hela situationen. Sen gäller det att löpande se till att de gemensamma delarna fortsätter att vara gemensamma och att de delar som inte är enade hålls isär och inte skapar förvirring. Och det kommer att behöva omförhandlas över tid vad som ska vara gemensamt och vad som inte ska vara gemensamt.

Strategimönster för informationsarkitektur

Att på detta sätt balansera gemensamma behov med lokala är själva kärnan i informationsarkitektens arbete. Det är något som lyfter hela kunskapsområdet från det som bara är informationsmodellering, att få koll på en avgränsad och sammanhållen domän, till informationsarkitektur, att hantera flera domäner länkade till varandra.

Till det behövs strategitänkande. Hur ska vi lösa de situationer som uppkommer? Vilka möjligheter finns det? Jag vet inte att det någonstans i vår bransch har diskuterats hur vi kan tänka där. Tvärtom är det som om problemet inte existerade, som om det vore självklart att alla verksamheter ska enas om en modell, nu genast och för alltid.

Strategi kräver kunskap och omdöme. Så låt oss samtala om detta, för att utveckla vår förståelse. Det är just så vi utvecklar vårt omdöme.

Jag tror att det bästa sättet att angripa detta, som individ, som team och som profession är att diskutera och tillämpa olika strategimönster. Strategimönster är mönster som beskriver olika strategier man kan tillämpa i situationer i arbetet. Rent allmänt beskriver ett mönster ett generellt problem och en generell möjlig lösning med sina styrkor och svagheter. Jag har i tidigare artiklar beskrivit ett antal modellmönster, hur man kan angripa enskilda modelleringsproblem. Nu är turen kommen för strategimönster för informationsarkitektur, det vill säga mönsterför hur man kan hantera olika situationer för samverkan mellan ett antal informationsmodeller inom en verksamhet, eller mellan olika verksamheter. Om vi tar del av strategimönster inom vårt område blir vi bättre på att se vilka val vi har i olika situationer och vad de kan innebära.

Var hittar vi strategimönster för informationsarkitektur?

Var hittar vi då strategimönster för informationsarkitektur? Jag har hittat några mönster i boken Domain-Driven Design av Eric Evans. Det är en bok som är tämligen okänd bland informationsarkitekter. Denna bok riktar sig egentligen till programmerare, och handlar om hur man designar den del av programkoden som är en modell av den domän som programkoden handlar om.

Inom objektorienterad programmering har man ju klasser som representerar företeelser i domänen och försöker avbilda beteendet hos dessa. På så sätt är hela det kunskapsområdet i stort sett analogt med vårt som informationsmodellerare och informationsarkitekter. Våra modeller är ju på liknande sätt avbildningar av företeelser i domänen. Eric Evans skrev ovan nämnda bok 2003. Det är först i fjärde och sista delen, av den 530 sidor tjocka boken, som han kommer in på dessa strategimönster. Han har sagt att det egentligen är den viktiga delen av hans bok och att han önskar att han hade lagt den delen först i boken, då programmerare inte brukar läsa ända dit.

Kan vi använda strategier för programkod för informationsmodellering?

Boken gav upphov till en rörelse bland programmerare med namnet Domain-Driven Design eller DDD. När jag läste boken tänkte jag genast att detta är mer eller mindre tillämpligt även för informationsmodellering. Jag vill påstå att bokens sätt att se på samverkan mellan det som finns i verkligheten (det vill säga domänen i fråga) och det sätt som detta representeras i informationsstrukturer (i Eric Evans fall programkoden) har gjorde mer för min utveckling som informationsmodellerare än något annat. Jag är djupt tacksam till Eric Evans för detta.

Trots min iver att dela mina tankar med folk i DDD-rörelsen, gav jag snart upp. På den tiden fanns det en vanlig inställning hos programmerare att programkoden och dess utformning var det enda intressanta. Databasens struktur var ointressant för dem. Databasens uppgift sågs som rent mekanisk, att persistera objekt i koden. Och att göra informationsmodeller sågs av många programmerare som ett verktyg för att avbilda verksamhetsobjekt i en databas, vilket var fel enligt dem, det skulle man göra i den objektorienterade programkoden. De ansåg att jag var en gammaldags figur, en kvarleva som inte hade fattat grejen, när jag ville prata informationsmodellering. Det var något omodernt, överspelat.

Ett väl övervägt svar från Eric Evans

Inte för att jag behövde någon välsignelse från DDD-rörelsen, men en händelse år 2004 gjorde ändå att jag kände mig mindre udda. Jag hade tagit en Greyhound-buss från Chicago över oändliga åkerlandskap och prärier till Denver i Colorado för att gå på konferens.

Det var den legendariska årliga OOPSLA-konferensen, ”Object-oriented Programming, Systems, Language and Design”. Ett återkommande evenemang där mycket av det nya inom systemutveckling introducerades, det som vi nu tar som självklart. Inte bara objektorientering utan även designmönster (ursprungligen av Kent Beck och Ward Cunningham, inspirerad av byggnadsarkitekten Christopher Alexander) och Kent Becks Extreme Programming och senare Agila manifestet. Det var ett ställe där historia skapades, och jag ville vara där och se det hända.

Men konferensen och hela det samhälle som var representerat där var mer eller mindre avvisande till allt som inte andades och levde objektorientering. Som till exempel XML och allt det som kom med internet som motsade att man skulle skicka hela objekt över nätet. Och inte minst detta att data i databaser kunde vara något annat än rent mekaniskt persisterade objekt från programkoden.

Jag hade läst Eric Evans bok och hade under första konferensdagen deltagit på hans workshop. Jag var övertygad om att Eric Evans idéer om domändriven design var tillämpliga utanför den objektorienterade programkoden, inte minst inom databasdesign och informationsmodellering.
Fast det var nästan inte möjligt att nämna där och då, det skulle vara som att svära i kyrkan.

Det var heller ingenting som Eric Evans hade berört, vare sig i hans bok eller i andra sammanhang. Hans värld var i mina ögon helt begränsad till programkod. Jag bodde på konferenshotellet och på konferensens tredje dag råkade jag hamna vid samma lilla frukostbord som Eric Evans. Jag var starstrucked! Men dristade mig så småningom att presentera min syn på saken för honom. Jag berättade att jag ofta designade system där tabellerna i databasen mer eller mindre avbildade domänen i fråga. Och jag frågade honom om han inte trodde att hans idéer var tillämpliga för detta. Jag väntade på hans svar med en viss bävan, för jag tänkte att han kanske skulle dissa hela idén om att databasen skulle kunna avbilda verksamheten direkt.

Nu hör det till saken att Eric Evans är känd för att vara en person som inte tar lätt på frågeställningar. Det sägs att när man ställer en fråga till honom så sitter han tyst i tio minuter och sedan så kommer det ett mycket övervägt och klokt svar. Och det var precis vad som hände nu. Vi hann avsluta mellanvästernfrukosten med bacon, ägg och hasch browns, och satt kvar med det blaskiga kaffet när hans svar kom. ”Yes Peter, as long as you get your database designers to really understand that when they change the database they change the model of the enterprise”. Jag blev så glad! Jag var förvisso redan tidigare övertygad om att jag var på rätt väg i mina tankebanor, men det kändes ändå skönt att jag nu hade fått någon slags välsignelse av självaste gurun på området, och inte måste kämpa i total motvind.   

Eric Evans strategimönster tillämpade på informationsmodellering

Eftersom Eric Evans sätt att tänka runt modeller är av en klass som jag inte mött någon annanstans, och att i stort sett inga informationsarkitekter hittar till hans bok, så vill jag gärna se till att fler får ta del av hans tänkande. Jag kommer därmed att publicera fyra artiklar som presenterar och diskuterar hans strategimönster.

Jag har översatt till svenska samt försökt att efter bästa förmåga tolka varje mönster i kontexten informationsmodellering. Vilket jag inte tycker har varit speciellt svårt, men ändå vill jag reservera mig för att det är min tolkning. Jag kommer därför att för varje mönster jag presenterar bifoga Eric Evans ursprungliga namn på mönstret. Då kan den som är intresserad och vill höra det hela från hästens mun, slå upp och studera mönstret i fråga i hans bok.

/Peter Tallungs, IRM

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