Med nyfikenhet och glädje ser vi fram emot 2022

Inför stundande högtider vill vi rikta ett stort tack till partners och kunder för årets fina minnen, goda samarbeten och för det förtroende ni ger oss. Med glädje ser vi fram emot 2022 och alla spännande projekt som väntar.

Istället för att köpa en massa klappar har vi skänkt pengar till Sveriges största miljöorganisation Naturskyddsföreningen, som arbetar för en rik natur och hållbar framtid. Det är något vi gärna stöttar.

Från oss alla till er alla – En riktigt God Jul och Gott nytt år!

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 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. Peter Tallungs presenterar ett antal mönster för detta.

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.

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 16 december. 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.