Inlägg

Hur långt ska man generalisera?

En fråga som hela tiden är närvarande när man informationsmodellerar är följande; Hur kan jag hitta den rätta balansen så modellen varken blir för generell eller för specifik? Informationsmodellering är ingen exakt vetenskap utan ett hantverk. Det handlar om intuition, det vill säga sådant som vi vet men inte vet exakt hur vi kan veta.

Att generalisera lagom när jag informationsmodellerar är att gå en balansgång som kräver omdöme och erfarenhet. Det är en smal stig att gå på med diken på ömse sidor som jag inte vill trilla ner i. Om min modell blir för specifik kan den inte hantera de varianter av företeelser som dyker upp över tid. Om den blir för generell säger den inte speciellt mycket om domänen i fråga.

Det finns inga fasta regler; det som först kan vara rätt blir fel i ett senare läge, och det som är rätt i ett sammanhang kan vara fel i ett annat. Den enda ledstång jag kan ha är hur användbar min modell och mina begrepp blir för det den ska användas till.

Om jag i huvudet stegar mig igenom olika tänkbara användningsscenarior så är jag snart på god väg att hitta rätt abstraktionsnivå. Inte minst hjälper det mig att förstå vad jag behöver hålla utkik efter, vilka faktorer som kommer att påverka vilka abstraktioner verksamheten behöver. Men facit får jag inte förrän modellen används på riktigt. Därför är det avgörande att inte låsa sig till ett visst synsätt, utan att pröva sig fram hela tiden, och omvärdera sina antaganden. Jag behöver ofta ändra modellen, alltefter jag får återkoppling från de som använder den. Det är inte ett misslyckande utan något bra. Det är så det lärande som kallas utveckling går till.

Stabilt är inte alltid starkt

Det är precis det som menas med idén om att något är anti-fragilt (Se Nassim Nicholas Talebs bok ”Antifragile – things that gain from disorder”.) Ju mer min modell används desto fler prövningar utsätts den för och desto mer utmanas den på olika sätt, och blir därmed allt starkare. Det innebär inte att den är stark i den meningen att den är så stabil att den inte förändras, utan att den klarar stress för att den hela tiden utvecklas och anpassar sig till omständigheterna. Det kräver att vi arbetar med den mer eller mindre kontinuerligt under hela dess existens. Det finns ingen ”överlämning”, där vi släpper modellen, så länge den används.

Varning för att övergeneralisera!

Här ser vi två olika sätt att modellera samma företeelser; att en försäkring kan ha olika intressenter (parter) i olika roller. Den övre modellen är mer tydlig då den i ER-diagrammet visar vilka roller olika parter kan ha i en försäkring. Diagrammet säger att det måste finnas precis en försäkringstagare och det måste vara en kund, samt att det måste finnas precis en försäkringsgivare och att det måste vara ett försäkrings-bolag. Det visar således tydligt viktiga företeelser inom domänen och vilka begrepp som gäller för dessa. Modellen som diagrammet representerar kommunicerar tydligt och enkelt viktiga företeelser inom domänen och vilka regler som gäller för dessa.

Men ofta behöver man kunna hantera fler roller på en försäkring än försäkringstagare och försäkringsgivare. Och ofta vill man också kunna lägga till roller mer dynamiskt. Det kan till exempel vara rollerna Betalare och Försäkrad.

Vi kan då göra som i den nedre modellen, skapa en entitet för själva relationen ”Part i försäkring”. Om vi fortfarande vill kunna uttrycka de regler som vi har i den övre modellen så behöver vi göra det på andra sätt, till exempel genom att införa ett regelplan i modellen enligt ovan. Vi har därmed fått en mer robust modell, det vill säga att den håller bättre för förändringar, till exempel att nya roller tillkommer eller förändras. Men priset är att diagrammet kommunicerar sämre. Samt att de data som är strukturerat enligt modellen blir mer komplicerat att komma åt.

Är det ett pris som är värt att betala? Det beror på omständigheterna. Har vi en verksamhet som ska klara av många olika exotiska och varierande roller? Eller är de roller som finns relativt stabila?

Jag kanske förutser att nya roller framöver kommer att dyka upp ganska frekvent, roller som vi idag kan förutse exakt vilka de blir. Då kan jag inte se rollerna som speciellt stabila utan behöver ett smidigt sätt att lägga till, förändra och ta bort roller i våra system, liksom i rapporter med mera.

Välj en modell som passar syftet. Överdriv inte kravet på robusthet. Den ökade komplexiteten i den nedre modellen blir en kostnad att bära framgent i allt vi använder modellen till.

Varning för att vara för specifik

Det är viktigt att bygga en struktur tillräckligt stabil, det vill säga att man bör akta sig för att bygga in begränsningar i själva strukturen som kanske ändras över tiden. Det gäller särskilt då modellen ligger till grund för en databas eller liknande som kan vara svår att förändra i efterhand. En riktlinje kan då vara; Bygg inte in en regel (begränsning) i själva datastrukturen för ett system utan att du är tämligen säker på att regeln kommer att gälla för systemets livslängd. Generalisera för att avlägsna oönskade regler från datastrukturen.

Den typiska utvecklingsgången hos modelleraren

När man är nybörjare inom modellering avbildar man gärna de vardagliga verksamhetsbegreppen direkt i modellens struktur. Därmed bygger man ofta in specifika regler som inte alltid gäller framgent. Modellerna blir spröda, då de inte klarar minsta förändring.

Men snart, mycket snart, upptäcker man generaliseringens kraft och det blir då gärna en överdrift åt andra hållet. Modellen blir så generell så den kan härbärgera så gott som allting. Man känner sig därmed immun mot alla nya krav som riskerar att poppa upp.

Jag och mina kollegor känner så väl igen oss själva i denna typiska utvecklingsgång. Vi ler generat. Vi har alla, mer eller mindre, gått igenom detta.

En kontinuerlig utveckling

Att abstrahera allt och alltid är inte skicklig modellering utan snarare att man har abdikerat från sin uppgift. Ty uppgiften är aldrig att göra modeller som vi aldrig behöver ändra och som inte duger till något. Uppgiften är att göra så användbara modeller som möjligt för sitt syfte och sammanhang. Och att utveckla modellerna kontinuerligt så att de alltid bär vår gemensamma förståelse, just nu. En modell behöver så tydligt som möjligt beskriva det som verksamheten behöver hantera. Och det på ett sätt som passar sammanhanget. Modellen behöver vara så enkel som möjligt. Men inte enklare!

Nu har ju informationsmodeller ofta ett mycket brett syfte och sammanhang. Ofta bygger man med modellen ett verksamhetsspråk som både möjliggör och begränsar vad man kan prata om och hur. Det är ett stort ansvar. Men trots att syftet och sammanhanget ofta är mycket brett är det ändå ett syfte och sammanhang att ta hänsyn till. Det finns inte någon rent objektiv och alltid giltig modell. En modell är alltid en abstraktion, det vill säga att den lyfter fram vissa aspekter av de företeelser vi modellerar och ignorerar andra. Och vad vi lyfter fram och vad vi ignorerar beror på sammanhang och syfte.   

Hur långt ska man specialisera?

Vi kan specialisera (subtypa) så långt som det hjälper oss att beskriva de regler vi behöver beskriva. Ibland säger man: ”Ända tills alla attribut och relationer är obligatoriska”. Det kanske är att gå för långt, men kan ändå vara en hint om hur man kan tänka. ER-diagrammet till höger ger ett exempel på hur man kan behöva specialisera ”Anställd” och ”Kontrakt” om man vill uttrycka vilka kategorier av anställda som kan ta vilka roller i olika kategorier av kontrakt.

Hur långt kan man generalisera?

Ja, rent teoretiskt finns det förstås en absolut gräns när vi har nått ett generellt begrepp som täcker alla företeelser som finns i vår domän. Vi har då en generell entitet som heter ”Thing” eller liknande. Men då har vi förvillat oss långt bort från den praktiska verkligheten. I verkligheten når vi en praktisk gräns vid fem till tio mycket generella företeelser. Det kan vara Part, Roll, Händelse, Resurs, Arrangemang, Plats, Regel och några till. Så högt i abstraktionshierarkin går vi bara i de fall vi behöver kommunicera mycket breda koncept. Det kan vara då vi bygger upp en metamodell för ett Dictionary eller liknande.

Vi utvecklas genom att dela erfarenheter

Det här är en aspekt av modellering, en färdighet man har som modellerare, där det är svårt att uttrycka precis hur man ska tänka. Det handlar om intuition, det vill säga sådant vi vet men inte vet exakt hur vi kan veta. Det kan också hänföras till så kallad tyst kunskap det vill säga sådant vi kan men som är omöjligt, eller i varje fall mycket svåra, att uttrycka verbalt. Förtrogenhetskunskap kallar man det för inom den praktiska filosofin.

Och som vanligt inom det mesta som rör utveckling finns det inget som är absolut fel eller rätt i alla situationer. Tvärt emot vad många tror finns det ingen ”best practice” att kopiera. Allt sånt kan vi glömma. Vi behöver studera olika lösningar, inte för att kopiera utan för att få en känsla för hur man kan hantera olika specifika situationer. Därför är det viktigt att vi delar erfarenheter. Så låt oss göra det! Kan vi göra det genom att vi har träffar om olika modelleringsproblem? Eller att vi delar exempel från verkligheten på något sätt, med kommentarer? ”War Stories”. ”From the trenches”. Så här gjorde vi, och det fungerade bra på dessa sätt men kanske mindre bra på dessa.

Hur skulle du vilja dela erfarenheter? Vilka utmaningar vill du diskutera med oss informationsarkitekter? Skriv i kommentarsfältet här nedan, så ser vi på IRM till att skapa tillfällen eller utrymme för erfarenhetsutbyten.

/Peter Tallungs, IRM

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

Informationsarkitekt – Hur långt sträcker sig rollen?

Vad gör en informationsarkitekt? Hur långt sträcker sig rollen egentligen?
Den 15:e oktober 2021 bjöd vi på IRM in till diskussionsträff för att diskutera rollen Informationsarkitekt; vad som kan ingå i rollen och vad som inte ingår. Vi har röstat och vi har ett resultat!

De flesta som läser detta har nog en bild av vad en informationsarkitekt gör. Åtminstone vad kärnan i arbetet är och ungefär hur långt rollen kan sträcka sig. Och jag tror egentligen inte att vi har så olika uppfattning. Men ändå, det kan finnas aspekter där vi har en lite olika förståelse. Och det finns ju inget rätt eller fel egentligen, man kan absolut argumentera för en snävare eller vidare omfattning av rollen.

Den 15:e oktober 2021 bjöd vi på IRM in till diskussionsträff för att diskutera rollen Informationsarkitekt; vad som kan ingå i rollen och vad som inte ingår.

Vi var femton deltagare, nästan alla är verksamma informationsarkitekter och några andra med ett starkt intresse i området.

Röstningen

För att få en struktur på diskussionen hade jag förberett en röstning och listade de kompetensområden som vi såg som kandidater i sex rader. Sedan delade vi dessa i korsande kolumner för de olika sätt på vilka man kan tänkas kunna vara involverade i respektive område.  Detta resulterade i en matris, se nedan

Det är svårt att uttrycka sig riktigt entydigt så både raderna och kolumnerna kan tolkas lite olika. Man kan också argumentera för fler rader och kanske också fler kolumner. Men deltagarna denna dag var överens om att indelningen skulle fungera för en röstning. Vi skulle få ett grepp om ifall vi har ungefär lika uppfattning eller var skiljelinjerna går mellan olika uppfattningar.

Själva röstningen gick till så att deltagarna fick markera i respektive ruta om man ansåg att rollen omfattade det som påstods eller inte. Det fanns också möjlighet för ett tredje alternativ, kanske, och det hände även att någon avstod från att rösta i vissa rutor.

Resultatet

Här är röstresultatet

Jag tänker nu våga mig på en analys av resultatet. Men först några noteringar.

Vilken ”informationsarkitekt” röstade vi om?

Det finns ju två radikalt olika innebörder i termen informationsarkitekt. Se artikeln ”Informationsarkitekter – de två kulturerna”. Den betydelse vi röstade om var den roll vi på IRM är engagerade i, som är inriktad på en hel verksamhet eller del av en verksamhet. Den andra betydelsen av termen ”Informationsarkitekt” handlar om presentation av information på en specifik webbplats eller liknande.

Var gruppen representativ?

Vems uppfattning belyser röstningsresultatet? Vem var med och röstade? Jag och mina kollegor uppfattar att deltagarna på diskussionsträffen den 15 oktober 2021 kan räknas som ett representativt urval av de som är verksamma inom området. Åtminstone tillräckligt representativt för att vara intressant. Vi hade en ganska bra köns- och åldersfördelning, och deltagarna kom från både offentliga organisationer och privata företag.

Var gruppen tillräckligt stor?

En liten grupp ger ett lika bra resultat som en stor, så länge urvalet inte är skevt.

Det vi röstade om var kompetensroller, inte befattningsroller.

Jag menar att man vid diskussion om roller bör skilja på om vi pratar om kompetenser eller befattningar. Om jag säger att jag är informationsarkitekt så kan det betyda att jag har den kompetens man kan förvänta sig av en sådan. Det kan också betyda att jag har en befattning med det namnet i en viss organisation. Det är en viktig skillnad. Vi var här intresserade av själva kompetensen, inte hur man använder titeln i landets organisationer.

Rösten ”Ja” i en ruta, menar man då att en informationsarkitekt måste behärska det rutan står för?

Nej, inte riktigt, hela området är stort, och alla kan inte greppa alla delområden fullt ut. Vi menar snarare att en Ja-röst betyder att du anser att området ingår i kompetensområdet på något sätt. Att det är rimligt att anta att en utbildning eller certifiering inom området skulle omfatta området för att kunna sägas vara komplett. Det hindrar inte att jag som säger mig vara informationsarkitekt kan ha mindre kompetens inom ett eller flera av områdena. Fast jag måste nog kunna täcka de flesta i varje fall, annars blir det tunt.

Analys av resultatet

Låt mig gå igenom områdena rad för rad och försöka tolka röstresultatet.

Data- och informationsstrukturer

Syftet med data- och informationsmodellering är att få grepp om data- och informations-strukturerna i en verksamhet. Gruppen var ense om att det ingår i rollen. Så vi kan även fortsättningsvis betrakta modellering som en kärna i informationsarkitektens arbete. Närmare hälften har dock givit en liten reservation för att styra, leda och hantera med ett ”kanske”. Det beror förstås på vad vi menar med verben ifråga. ExKanske man lägger någon slags chefsroll i detta som man menar inte ingår.

Begrepp och språk

Detta område har fått lika höga röstetal som föregående. Jag tolkar det som att man vill se att vi med våra modeller, med sina benämningar och definitioner, fångar och formar ett språk för de företeelser som beskrivs av data. Jag tycker att resultatet är intressant, för jag upplever att den aspekten av modelleringen ofta inte uppmärksammas.

Försörjning, integration och användning av data/information

Analysera/utreda/dokumentera/modellera får närmast full pott i röstningen medans övriga rutor får succesivt fallande röstetal. Jag tolkar det som att man vill se det som att informationsarkitekter ser till att man har koll på hela dataförsörjningen, men att man däremot inte har ensamt ansvar för att få försörjningen att fungera. Utan det är ett ansvar för it-funktionen som helhet.

Ta hand om data som tillgång/resurs

Här återkommer mönstret från föregående rad, och min tolkning är densamma.

Ägarskap och styrning av dataresurser

Återigen samma mönster som de två föregående raderna. Samma tolkning

Styrning av dataresurser utifrån säkerhetskrav

Nu träder vi ut på lite mer främmande mark. Nästan alla röstade ”Nej”, och några är tveksamma, på om datasäkerhet verkligen är informationsarkitektens hemmaplan. Undantaget är uppgiften att analysera/utreda/dokumentera/modellera. Jag tolkar det som att informationsarkitekten kan ta en analyserande roll inom området men knappast ett större ansvar.

Jag hann själv inte med att rösta men min uppfattning stämmer väl med det samlade resultatet. Samtidigt är jag lite överraskad av samstämmigheten, jag uppfattar inte några tydliga skiljelinjer, annat än sådant som enklast kan förklaras av frågornas otydlighet.

Om jag ska våga mig på en sammanfattning så ger resultatet en vink om att det inom skrået finns en tydlig bild av vad en informationsarkitekt arbetar med. Jag vågar mig inte på en definition men vi har ringat in en bred roll runt data, information och vad det representerar i våra verksamheter. 

Du kanske läser in en annan tolkning av resultatet. Låt höra i så fall.

Tack till alla som var med och bidrog till detta och låt oss fortsätta dialogen. Vi planerar att ha fler träffar framöver. Du får gärna föreslå ämnen som du vill att vi tar upp och även former för träffar. Väl mött!

/Peter Tallungs, IRM

Nästa artikel i serien publiceras torsdag 11 november. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.