Hur får vi ordning på vår dataresurs?
Del 2: Hantering av struktur, begrepp och namn

Hur kan vi hantera den röra av termer som används i våra it-miljöer: i databaser, tjänster, filer, programkod, rapporter, formulär och användargränssnitt? Hur kan vi skapa någon slags ordning i ”Babels Torn”?

/Peter Tallungs, IRM, 2024-03-28

Problembilden

I en verksamhet kan en och samma sak ha olika namn det vill säga att vi har att göra med synonymer. Samtidigt kan en och samma term användas i olika betydelser, det som kallas homonymer. Både de synonymer och homonymer som förekommer i en verksamhet kan förstås vara korrekta, men är inte sällan falska och missvisande. I vilket fall är det något vi behöver hantera.

Det är inte bara själva namnen som kan vara vårt problem, utan vi har ofta att göra med hela strukturer som ser olika ut. Det kan till exempel vara att vi har flera olika produkt- eller avtalsstrukturer i spel i en och samma verksamhet.

Därmed har vi en komplexitet i våra data, vilket grundar sig på röran i det språk vi använder för att beskriva det som våra data representerar, det vill säga alla de företeelser i verksamheten som våra data representerar. Om vi ska kunna få ordning på våra data behöver vi först och främst få ordning på vår gemensamma förståelse av verksamhetsdomänen, det vill säga våra begrepp.

Vi behöver kunna benämna och resonera om allt det som verksamheten hanterar och behöver hålla reda på. Vi behöver ett språk som har precision och klarhet.

Föregående artikeln ”Hur får vi ordning på vår dataresurs – Del 1: Om röran i struktur, begrepp och namn” ville visa på alla ställen hela it-landskapet där begreppsförbistring uppstår.

Följdfrågan blir då: Vad kan vi göra åt detta? Hur städar man och håller någon slags ordning i ”Babels Torn”?

Kan vi inte bara ensa upp allting och skapa ordning en gång för alla?

Jag tror att vi alla någon gång har tänkt: ”Vi måste skapa en gemensam struktur, bestämma termer för alla företeelser och egenskaper, och sedan hålla oss till dessa, överallt i vår verksamhet och våra data”.

Men problem har inte alltid en enkel lösning. Det finns två hakar med den tanken.

1. Ofta klarar vi oss inte med en enda gemensam produktstruktur, avtalsstruktur eller liknande.

Ofta sträcker sig en verksamhet över en större domän och man behöver hantera produkter och avtal olika. Man kanske ser på produktportföljen på ett sätt inom inköp eller tillverkning, men gör en annan skärning på logistiksidan och på försäljningssidan en tredje skärning. Kanske också den ekonomiska uppföljningen har skapat en egen struktur. Man har alltså behövt hantera produktportföljen olika.

Och jovisst är det möjligt att skapa en generisk struktur som täcker alla aspekter. Men det blir då kanske en komplicerad struktur som egentligen inte passar någon. Utom kanske för uppföljning där man kanske ändå måste ha en gemensam struktur tvärs över alla produkter.

På liknande sätt kan det vara med avtalsstrukturer. Om vi har många olika slags kunder med olika behov, till exempel företagskunder med olika slags avtalsstrukturer, är de på samma sätt svårt att skapa en gemensam struktur som täcker alla behov. Men ibland är det ändå nödvändigt, åtminstone för den gemensamma rapporteringen.

Om vi har att göra med leverantörer eller partners vars strukturer vi behöver hantera har vi inte ens makt att eller möjlighet att påverka deras strukturer och termer. Vi kan bara gilla läget.

2. Vanligen är det i praktiken inte möjligt att ensa överallt.

Även om vi verkligen vill och borde ensa våra produkt- eller avtals-strukturer kan det vara ett formidabelt arbete. Vi behöver ändra på många ställen, i databaser, integrationer, filer och rapporter. Ofta har man byggt hela system på vissa strukturer, och skapat beroenden kors och tvärs som är svåra att överblicka. Det är ofta inte värt arbetet som krävs, men det minskar inte behovet av att hantera situationen idag.

Det är aldrig fel att städa upp, men det är naivt att tro att det är den enda lösningen vi behöver, eller ens den huvudsakliga. Vi behöver kunna leva med att vi har olika benämningar för samma sak på olika ställen, ofta många olika och ibland rent missvisande. Och att vi ibland har helt olika strukturer att hantera för det som vi egentligen tycker skulle kunna ha en gemensam struktur. Men hur gör vi det, hur håller vi ändå ordning?

Hur kan vi då hantera och leva med alla olika strukturer och benämningar?

Om det i praktiken är omöjligt att få en fullständig, eller kanske inte ens någorlunda, överensstämmelse överallt i vår verksamhet, hur ska vi då göra? Leva med röran? Gilla läget? Nej då, vi kan faktiskt få ordning ändå.

Vi kan skapa ett gemensamt språk, ett lingua franca, för vår verksamhetsdomän (allt det vår verksamhet hanterar) och för de data som representerar det som finns i domänen. Vi kan göra det genom att skapa en gemensam informationsmodell som bär den gemensamma förståelsen och det gemensamma språket.

Den modellen kan sedan vara normerande för hela vår verksamhet, det vill säga utgöra det rekommenderade språket då man kan välja benämningar, och samtidigt mappa mot alla synonymer som förekommer på olika ställen.

Det är inte bara benämningar som ska mappas utan ibland även olika strukturer.

Det innebär att vi måste ha mycket mer än en ordlista. Vi behöver ha ett tematiskt lexikon. Det vill säga ett kapitel som beskriver allt om kunder, ett annat kapitel som beskriver allt om produkter, och så vidare. Det innebär att modellen blir mer än en traditionell informationsmodell. Den blir faktiskt en domänmodell. Det vill säga en modell av vår hela domän, i både diagram och text.

Det går att göra. Jag vet, för vi har gjort det i flera verksamheter. Och jag påstår att vi behöver göra det.

Men jag förstår att det finns invändningar hos alla de som jobbar med data, annars skulle vi redan ha sett detta förverkligat på fler ställen. Låt mig bemöta de sex vanligaste invändningarna.

Vanliga invändningar mot att skapa en informationsmodell som är normerande för verksamhetens terminologi

Invändning 1: Ordlista finns redan.

Vi har en ordlista med verksamhetstermer. Den ska vara normerande. Det är den vi har att hålla oss till. Informationsmodellen ska inte vara normerande för verksamhetens språk, utan bara följa ordlistan.

Svar: En ordlista är en listning av termer, vanligen alfabetisk ordnad. Det räcker inte. Det är skillnad på att bara lista termer med förklaringar och att verkligen beskriva hur saker och ting hör ihop, i sitt sammanhang. Termer förstås och definieras i sitt sammanhang, det är en grundsats inom terminologiarbete. Varje term vi behöver förklara, behöver vi förklara tillsammans med omkringliggande termer, lite som en lärobok som går igenom ämnesområde för ämnesområde och beskriver strukturer, samband, logik och regler. Det är just det vi kan göra med en rik informationsmodell, vilken går igenom ämnesområde för ämnesområde och beskriver vad som vi hanterar, egenskaperna, definitioner, benämningar, både normerande och synonymer i olika sammanhang, livscykler och regler, med både grafik och text.

Invändning 2: Inte vårt jobb.

Data Management och informationsarkitektur handlar om data och information. Verksamhetsbegrepp är inte vårt område. Det är verksamhetens jobb att ta fram, vilket vi sedan har att förhålla oss till.

Svar: Det är sant att Data Management formellt inte inbegriper begreppsanalys och att hantera verksamhetstermer. I varje fall är det så om man bara tar dessa områdens definitioner.
DAMA (Data Administration and Management Association) har inte heller med det i sin skrift DAMA BOK, ”Body of Knowledge”, i vilken de vill definiera hela områdets olika discipliner.

Men jag vill påstå att det i praktiken är omöjligt att se hantering av informationsarkitekturen och hantering av verksamhetstermer som två åtskilda discipliner. Det kanske gick för fyrtio år sedan, då verksamheter jobbade mer manuellt och att hela hanteringen var mer transparent än idag. Men med dagens digitalisering har mycket av verksamhetsprocesserna flyttat in i ett moln av it-system, och är därmed till stor del blivit osynlig för verksamhetsfolket. Det är vårt jobb som verksamhets- och informationsarkitekter att göra detta synligt igen.

Det gör att arbetet med informationsarkitektur och arbetet med verksamhetsterminologi är som yin och yang, ler och långhalm.

Det är i våra databaser, filer och liknande vi ser vad verksamheten hanterar och hur. Det är som arkeologi, och i likhet med arkeologi behöver vi tolka det vi hittar.

Invändning 3: Vi har inte kompetensen.

Vi är inga terminologer. Vi har inte kunskap om hur man jobbar med termer och definitioner.

Svar: Då får vi skaffa oss tillräckligt med kunskap för att ta det ansvaret. Ok, vi kanske inte kan bli lika skickliga som en utbildad terminolog, men vi kan mycket väl fungera som ”barfota-terminologer”. Många av oss i branschen har den kompetensen. Vi jobbar ibland tillsammans med terminologer och en del av oss är utbildade inom datalingvistik. Vi ser hur området informationsarkitektur just nu mognar till en mer central roll.

Invändning 4: Vi har inte verktygen.

Våra modelleringsverktyg räcker inte till för att beskriva och hantera benämningar och definitioner.

Svar: Ja det är sant, om vi talar om de vanliga modelleringsverktygen och hur de begränsar oss. Men låt oss i stället ta fram och använda verktyg som gör jobbet. Jag och mina kollegor gör det vi kallar ”rika informationsmodeller” i enkla verktyg som ordbehandlare och ritprogram. Då kan vi hantera synonymer, definitioner, liksom allt annat vi behöver.
Vi kan enkelt bygga de beskrivande strukturer vi är i behov av.

Invändning 5: Våra modeller når inte ut.

Våra informationsmodeller är svåra att läsa och förstå. De avbildar inte verksamhetsdomänen på ett sätt som går att förstå utanför de som dagligen jobbar med dessa.

Svar: Ja så är det ofta. Vi behöver därför bli bättre på hur vi gestaltar modeller, i diagram och text, så att de blir mer klara och tydliga, det vill säga att hanterar och kommunicerar det vi behöver. Det handlar inte bara om att modellerna behöver kommunicera bättre. Om vi ritar bättre så förstår vi också bättre själva. Det handlar om gestaltning, hur vi använder grafikens och texten möjligheteter.

Invändning 6: Vi når inte ut.

Vi som jobbar med informationsmodeller är ofta mer inriktade på att analysera och beskriva datastrukturer än att nå ut till och samverka med alla olika intressenter.

Svar: Ja det stämmer. Vi behöver därför bli bättre på hur vi når ut, hur vi håller oss med skyltfönster för våra modeller, hur vi engagerar oss i olika initiativ och hur vi marknadsför vårt arbete.

Hur gör vi rent praktiskt?

Men om vi ska skapa en gemensam informationsmodell som blir normerande för vilka verksamhetstermer vi ska använda, hur gör vi då rent praktiskt? Hur ser en sådan modell ut? Hur når vi ut med den? Och hur får vi genomslag i hela verksamheten?

Det får bli nästa artikel.