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

Föregående artikeln 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. 

/Peter Tallungs, IRM, 2021-12-02

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.
(Fast får jag 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 informations-arkitektens 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önster fö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.

Jag blev ivrig att dela mina tankar med folk i DDD-rörelsen, men gav 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.

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 Chrisopher 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. 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.