Taggarkiv: strategi

Strategimönster för informationsarkitekter – del 4: Destillering av kunskap

Destillering är processen för att separera essensen från en blandning, och få den i en form som gör den mer värdefull och användbar. Informationsmodellering kan vi se som destillering av kunskap. Kunskap om de företeelser som verksamheten hanterar och hur de hanteras. Men vi kan behöva destillera vidare, ytterligare lyfta fram det som är viktigast i domänen. I följande artikel presenterar jag strategimönster som kan hjälpa oss med detta.

När man modellerar en domän, till exempel en verksamhetsfunktion eller ett it-system, så finns det saker i modellen som utgör själva essensen, det som är mest centralt och som är själva nyckeln till förståelsen av domänen. Denna essens, denna nyckelförståelse är, skulle jag vilja påstå, det som egentligen är verksamhetens viktigaste tillgång.

Men när man modellerar finns det alltid många olika saker som behöver hanteras. Därmed är det lätt att essensen kommer ur fokus, inte får den framträdande roll som den borde ha, och försummas.

Det finns flera orsaker till att det sker, bland andra de två följande.

  1. Behovet av specialisering
    En orsak är de specialiserade roller vi ofta måste ha i utvecklingsarbete. När en it-utvecklare rör sig utanför den del av systemet denne är välbekant med går hen lätt vilse i begreppen. Detta tvingar utvecklare att specialisera sig. När så var och en begränsar sitt arbete till specifika funktioner stryps kunskapsöverföringen mellan dem ytterligare. Isoleringen ökar därmed, vilket blir en ond spiral.
  2. Tendens till dragning mot teknik
    Det finns en tendens att erfarna it-utvecklare drar sig från kärnan av domänmodellen och mot den mer tekniska infrastrukturen, eller mot något tydligt avgränsat problem som kan förstås utan specialiserad domänkunskap. Ty detta är vanligen ett mer intressant område för en tekniskt intresserad och uppfattas också som att det ger färdigheter som är användbara i andra projekt och ser bra ut i ett cv.

Vi bör prioritera domänkärnan

Allt detta gör att domänkärnan ofta inte får den uppmärksamhet som den skulle behöva. I praktiken kan kanske inte alla delar av modellen hållas lika snygga. Vi måste då prioritera. För att göra domänmodellen till en tillgång måste vi framför allt se till att den kritiska kärnan i modellen bibehåller sin elegans och användbarhet.

I det följande presenterar jag fyra strategimönster som kan hjälpa oss att lyfta fram och förtydliga essensen i en modell.

Mönster 1: Domänkärnan (Core Domain)

Problem: Den specialiserade kärnan i domänmodellen, den viktigaste delen av modellen, det som verkligen gör modellen till en affärstillgång hanteras ofta styvmoderligt. Bland it-utvecklare är det vanligt att ny teknik och avancerade algoritmer ses som det viktiga. Datastrukturerna och begrepp ses som tråkiga och oviktiga och överlåts vanligen på en junior utvecklare, som får jobba tillsammans med en databasadministratör för att skapa ett databasschema.

Dålig design eller implementation av denna del av programvaran leder till att applikationen aldrig klarar av att göra viktiga saker för användaren. Och då spelar det ingen roll hur elegant infrastrukturen är.

Lösning: Koka ner modellen. Hitta domänens kärna och separera den från massan av modellen. Lyft fram de mest värdefulla och speciella begreppen. Håll kärnan liten. Domänkärnan är den del av modellen som särskilt tydligt representerar verksamhetsdomänen och som på bästa sätt löser de uppgifter som systemet ska lösa.

Sätt de skickligaste teammedlemmarna på kärnan och rekrytera enligt denna princip. Lägg kraften på kärnan för att hitta en djup modell. Utveckla en smidig design för denna – tillräcklig för att tillgodose visionen med systemet. Motivera investeringar i övriga delar av modellen efter hur de stödjer den destillerade kärnan.

Vem gör jobbet?

De utvecklare som är de skickligaste rent tekniskt är ofta inte så intresserade av den specifika verksamheten. Det begränsar dem i detta sammanhang och förstärker deras dragning till infrastruktur. De kan då inte bygga domänkunskap, och vi får en ond cirkel.

Vi behöver sätta samman teamet på följande sätt:

  • Utvecklare som är beredda till långvarigt engagemang och är beredda på att vara bärare av domänkunskap
  • En eller flera domänexperter som har djup kunskap om sin verksamhet
  • Informationsarkitekt, som faciliterar samverkan mellan dessa och aktivt arbetar med att förfina modellen.

En väldestillerad domänkärna är en tillgång som ger snabbhet, lättrörlighet och precision.
Första iterationen av ett utvecklingsprojekt bör alltid baseras på någon del av domänkärnan.

Men det här verkar jobbigt, säger kanske någon. Kan vi inte köpa ett standardsystem i stället, eller åtminstone en standardmodell? Reality check: Domänkärnan kan förmodligen inte köpas. Industrispecifika modellramverk har hitintills alltid misslyckats.

Mönster 2: Generiska subdomäner (Generic Subdomains)

Problem:Det finns alltid delar av en modell som ökar komplexiteten i modellen utan att egentligen fånga eller kommunicera någon specialiserad kunskap. Allt sådant sidoordnat i modellen drar uppmärksamheten från domänkärnan, vilket gör det svårare att uppfatta och förstå det som är centralt.

Modellen slammar igen av allmänna principer som alla känner till ändå, eller detaljer som bara har en stödjande roll. Men de kan ändå inte tas bort eftersom de behövs.

Lösning: Identifiera sammanhängande subdomäner som behövs men som inte är de som utgör motiveringen för projektet. Faktorera ut dessa till andra generiska modeller. Gör dessa så allmänna så att inga spår är kvar av den speciella situationen i dem. De blir kandidater till återanvändbara tillgångar.

En generisk subdomän kan bli en återanvändbar tillgång på två sätt:

  1. Återanvändning av programvaran
    Ni kan göra en egen programvarukomponent som kan återanvändas av andra. Detta skall dock inte vara din prioritering eftersom du skall rikta så mycket kraft åt kärndomänen som möjligt, inte bli en leverantör av generiska komponenter. Det är ju kärndomänen som är viktig.
  2. Återanvändning av modellen
    En viktig form av återanvändning som ofta har hamnat i skymundan, både internt i våra organisationer och i branschen/samhället i stort, är återanvändning av modellen. Här finns mycket att göra för oss. Ett sätt är att vi publicerar och diskutera modellmönster inom vår Community. Ett annat sätt är att vi publicera hela modeller, som exempel på hur man har gjort, med kommentarer.

Mönster 3: Domänens vision (Domain Vision Statement)

Problem: Vi behöver skapa och förmedla en gemensam bild av den centrala idén med domänen.

Lösning: Skriv en kort beskrivning (ungefär en sida) av domänkärnan och det värde den kommer att bidra med. Ta endast med sådant som utskiljer denna domänmodell från andra. Visa hur domänmodellen tjänar och balanserar skilda intressen. Skriv visionen tidigt och revidera den när du vinner ny insikt. Det är ungefär detta du skulle säga när du ska beskriva vad som är det speciella med verksamhetsfunktionen eller applikationen som modellen beskriver.

Exempel: Vision för Flygbokningssystemet

  • Passagerarnas prioriteringar ska balanseras mot flygbolagets bokningsstrategier
    Systemet ska kunna representera passagerarnas prioriteringar och bokningsstrategier och balansera dessa mot varandra baserat på flexibla regler.
  • Modellen av en passagerare skall avspegla den relation som flygbolaget strävar efter att utveckla med återkommande kunder.
    Därför skall modellen representera passagerarens historik i en användbar kondenserad form, deltagande i speciella program, anknytning till strategiska företagskunder och så vidare.
  • Användarroller
    Användarnas olika roller (som passagerare, agent, ledningsperson) tillhandahålls för att kunna föda säkerhetssystemet med nödvändig information.
  • Modellen skall stödja effektiv rutt/sittplats-sökning
  • Modellen ska möjliggöra integration med andra etablerade flygbokningssystem.

Mönster 4: Framhävd kärna (Highlighted Core)

Problem: Vi behöver skapa och förmedla en gemensam förståelse av domänkärnan, det vill säga de viktigaste strukturerna i modellen.

Lösning: Ta fram ett destillationsdokument (Distillation Document) på 3–7 sidor som beskriver och förklarar domänkärnan. Det kan innehålla följande:

  • En lista på de viktigaste entiteterna
  • Diagram som visar deras viktigaste relationer
  • En genomgång av deras viktigaste interaktionsmönster, antingen på abstrakt nivå eller med exempel.

Dokumentet ger en bred vy av hur bitarna passar ihop. Dokumentet skall vara läsbart för icke-tekniska personer och vara avgränsad till det som alla inblandade behöver veta. Använd det som en gemensam vy och en guide med vilken alla nya teammedlemmar kan starta.

Destillationsdokumentet fungerar som en gemensam förankring. Det är viktigt att det står klart för teamet vilken stor betydelse en ändring av domänkärnan innebär. En ändring av domänkärnan innebär en förändring av teamets gemensamma syn på domänens centrala begrepp och beteende.

Använd destillationsdokumentet som en indikator. Om en ändring i modellen gör att destillationsdokumentet behöver uppdateras för att vara i synk med modellen behövs en överläggning. Antingen har det skett en fundamental ändring av något element i domänkärnan eller då har domänkärnans gräns flyttat på sig.

Det är då nödvändigt att sprida den förändrade bilden till hela teamet, inklusive att dela ut den nya versionen av destillationsdokumentet till alla inblandade.

Källan till dessa strategimönster

Strategimönstren i denna artikel är hämtade från Eric Evans bok ”Domain Driven Design”. Jag tycker att de är så kloka så jag vill gärna lyfta fram dem till en bredare krets än de få som kommit så långt i hans bok. Jag har här översatt och tolkat dessa. För de som vill gå till originalen har jag skrivit Eric Evans namn på mönstren inom parentes.

/Peter Tallungs, IRM

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

PS Vi har tyvärr varit tvungna att ta bort möjligheten att kommentera på artiklarna för en tid. Har du tankar om innehållet i artikeln som du vill dela? Välkommen att kommentera på vår linkedin där lägger vi ut en post vid varje publiceringstilfälle. Eller skicka ett mail till Peter Tallungs: peter.tallungs(at)irm.se

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.