Hur får vi ordning på vår dataresurs?
Del 1: Om röran i struktur, begrepp och namn

Begreppsförbistring råder överallt i våra data. Dataelement representerar de företeelser i verksamheten som behöver vara tydliga namngivna och definierade. Varför har vi denna röra och vad vi kan göra åt den?

/Peter Tallungs, IRM, 2024-03-14

Vi har ett trassel

Jag tror att inte så många är medvetna om vilken oreda vi har i våra verksamheter vad gäller data, och vilka begrepp i verksamheten de representerar. Jag tror inte heller att det är allmänt känt hur allvarligt det är, hur detta hämmar försök till gemensam förståelse och utveckling. Det är mer eller mindre samma tillstånd i alla verksamheter jag kommit i kontakt med, fast kaoset växer förstås exponentiellt med komplexiteten i verksamheten.

Inte bara data

Bristen på struktur gäller inte bara data utan också – inte minst viktigt – definitionerna och benämningarna för allt det som data representerar. Detta för att vi med precision och klarhet behöver kunna benämna allt det som verksamheten hanterar och behöver hålla reda på, det vill säga allt vi behöver veta, resonera om och hantera, som till exempel kunder, produkter, avtal, regler, leveranser, tjänster, anläggningar, installationer med mera. Det som vi kan kalla för domänmodellen, den föregivna gemensamma bild av den värld verksamheten finns i och dagligen hanterar.

Utan ett effektivt språk blir det mesta grumligt, inte bara i vår kommunikation utan också i vår egen förståelse. Som Ludwig Wittgensteins berömda citat: ”Mitt språks gränser är min världs gränser”.

Vad gör vi åt det?

Detta är första artikeln i en serie som går igenom var begreppsförbistringen finns, varför den finns och vad vi kan göra åt den. Här finns det en dålig nyhet och en god. Den dåliga nyheten är att förbistringen finns överallt och att det inte finns en mekanisk lösning. Trots att många tror det. Marknaden översvämmas av en mångfald repositories, modelleringsverktyg, arkitekturverktyg, data managementverktyg med mera. Problemet är inte tekniskt och då är inte lösningen heller teknisk. Vad vi behöver är kunskap, ansvar och envist arbete.

Den goda nyheten är att arbetet med att få ordning och ett gemensamt språk med tydliga termer och klara definitioner egentligen är enkelt och inte särskilt resurskrävande. Ja, enkelt är väl kanske att lova lite för mycket, men i varje fall inte svårare än att vi med lite envishet kan ta tag i problemet och få ordning. Och att vi får nytta av arbetet nästan med en gång. Vi kommer dock aldrig bli helt färdiga. Det handlar mer om att i vår verksamhet bygga upp en förmåga som kontinuerligt kan vårda och utveckla något av det viktigaste vi har: våra data, våra begrepp, vårt effektiva språk, ja vår gemensamma förståelse av hela den operativa logiken i allt det vår verksamhet hanterar.

Vari ligger förbistringen?

Det man ser när man studerar data är att man har olika namn, olika eller obefintliga definitioner, olika förståelser, samt olika strukturer för företeelserna som vi hanterar.

Det som spretar på detta sätt är följande:

• Företeelsernas definitioner, som till exempel kund, produkt, beställning med mera.
• Företeelsernas egenskaper och möjliga värden, som till exempel kundstatus, produkttyp med mera.
• Reglerna för företeelserna, som till exempel när blir en kund en aktiv kund. Vilken händelse gör att en kund övergår till att bli en tidigare kund?
• Namn på dataelement som representerar ovanstående.

Var spretar det?

Det spretar överallt; i data, i användargränssnitt, i programkod, i filer, i rapporter, i modeller, i beskrivningar, i process- och rutinbeskrivningar och i dokumentation. Kort sagt överallt där man refererar, beskriver eller analyserar något i verksamheten.

Röran består alltså av en diskrepans, inte bara i namn och definitioner utan i synsättet hur man strukturerar allt det man hanterar.

Skillnaderna är inte alltid av dåliga orsaker, långt därifrån. Olika sammanhang kräver olika synsätt på samma företeelser, inte bara mellan olika verksamheter utan även ibland inom en och samma verksamhet. Men vi behöver överblick och att kunna mappa mellan olika strukturer och begrepp inom olika deldomäner. Samt att på sikt arbeta bort de felaktigheter och onödiga skillnader vi med tiden upptäcker.

Datatransformationer hanteras inte bra

Bristerna uppstår särskilt vid integrationer av olika slag då en datatransformation sker utan att utvecklaren som bygger integrationen har det stöd som behövs för att jobba med begrepp och termer. Det finns ingen att tillgå som tar ansvar för att gemensamma termer, definitioner och förståelse hänger ihop. Utvecklaren är då hänvisad till att själv försöka förstå och hitta på namn. Ibland kanske hen frågar någon i verksamheten, men får då svar som inte är så genomtänkta. Att arbeta med begrepp och termer kräver ett visst handlag och en kontinuitet.

Var sker datatransformationer?

I det följande gör jag en genomgång av de olika ställena i en verksamhet som integration mellan två kontexter, och därmed transformation från en datastruktur till en annan brukar ske. Samt vilka faktorer som påverkar att det där uppkommer större eller mindre diskrepans mellan hur saker benämns och definieras.

Datatransformation inom en och samma it-applikation

Ofta har man separerat kodbasen för en applikation i tre skikt: användargränssnitt, verksamhetslogik och datalagring. Ibland har olika team ansvarat för respektive skikt och därmed har det vuxit fram lite olika syn på strukturer och namn.

Speciellt tydligt blir det i det fall man ser en applikation som ett antal separata återanvändbara tjänster, som i tjänstebaserad it-arkitektur eller när man bygger mikrotjänster. Då ser man inte en applikation som en helhet. Tvärtom vinnlägger man sig om att varje mikrotjänst ska vara en autonom komponent.

En faktor som allvarligt försvårar är när man har valt olika nationella språk för användargränssnitt och programkod. Programmerare har ofta tron att alla namn och kommentarer i programkod bör vara på engelska och då även för alla verksamhetstermer. Det är vanligt även i helsvenska verksamheter där man inte har etablerat ett korrekt engelskt språkbruk. Då kan man få se en undermålig och missvisande, ofta förvirrande, engelska. En soppa man måste översätta till och från överallt, eftersom användargränssnitt med mera fortfarande är på svenska.

Ibland har man programmerare som inte kan svenska och ser sig tvingade att ha alla verksamhetsbegrepp, alla kommentarer och all dokumentation både på engelska och svenska. It-ledningen har då ofta trott att det är en smal sak att översätta fram och tillbaka. Men det blir många termer, definitioner och beskrivningar som hela tiden måste övervägas och hanteras parallellt med två språk, och det i alla sammanhang som rör förståelse och utveckling. I en verksamhet jag jobbat i rör det sig om tvåtusen termer. Det skapar friktion i all kommunikation.

I en bransch som till exempel försäkring eller finans är det inte ett arbete att ta lätt på. Det krävs stor kunskap att översätta korrekt och också hantera alla definitioner och beskrivningar i två språk. Ofta har man inte ens gjort klart för sig om det ska vara brittisk eller amerikansk försäkringsterminologi. Att bara ta in en språkkonsult fungerar inte. Det behöver vara en som verkligen behärskar området och som också kan studera programkod, databasstrukturer med mera, samt kommunicera om allt detta med alla berörda. Det är en last man måste dra om det inte ska bli kaos.

En situation som genererar en kakafoni mer än allt annat är när det är en standardapplikation man anpassar till sin verksamhet. Då behöver man pressa in den egna domänmodellen i leverantörens modell. Sällan går det smärtfritt, utan måste ske med skohorn och ett inte så litet mått av mental dissonans. Ty verksamheter kan tyckas vara lika inom samma bransch, men tittar man närmare är de mer olika än man tror. Lite friktion på många ställen gör att man snart har ett sammelsurium av kompromisser, skevande anpassningar och work-arounds. Och man kan inte, som så ofta hävdas, bara utan vidare anpassa sitt eget sätt att göra saker till leverantörens sätt. Inte då hela verksamheten i stort sett i varje rutin är uppbyggd runt en världsbild som vuxit fram och finmejslats under lång tid. Resultatet blir ett skav, i alla delar.

Ibland har man i bank- och försäkringsbranschen försökt anamma en standardmodell som någon leverantör har tagit fram. Tanken är att då ska man slippa modellera sin egen verksamhet. Vilket är befängt om man betänker att det är samma sak som att påstå vi skulle kunna köpa oss en egen gemensam förståelse av vår egen verksamhet. Hur ska man kunna anpassa sig till en standardmodell om man inte först har skapat sig en gemensam förståelse av vad vi själva hanterar för saker? Den förståelsen får man endast genom att modellera sin egen verksamhet, tillsammans och noggrant. Och det i detalj, ty ”the devil is in the details”.

Resultatet av denna ignorans har gjort att många verksamheter hamnat i ett riktigt dåligt läge, då man allvarligt hämmat utvecklingen av det viktigaste man har, sin egen gemensamma förståelse och språk. Inte minst allvarlig är att man då också undvikit att bygga upp förmågan att kontinuerligt vårda och utveckla begrepp och språk.

Datatransformation mellan delar av verksamheten

Ofta har tillverkningssidan i ett tillverkande företag en annan syn på produktstrukturen än försäljningsfolket. Vanligt är också att den ekonomiska uppföljningen har sin egen produkt-struktur. Ofta är det av skäl som är goda, att man verkligen behöver olika struktur. Ibland inte så goda skäl, utan mer för att det bara har blivit så, när man arbetat i sina stuprör.

Men vi kan inte utan vidare veta om skillnad är nödvändig eller onödig. Inte utan att verkligen tillägnat en djupare förståelse, det vill säga modellerat. Och i vilket fall som helst behöver vi hantera skillnaden och mappa mellan de olika modellerna eller se det som delar av samma modell. Ty även om det skulle vara möjligt att sammanföra till en och samma begreppsrymd, tar det tid och kraft och är kanske inte mödan värt. Kanske det kan vara en framtida ambition, men till dess måste vi lika fullt hantera de olika strukturerna, begreppen och översättningen mellan dessa.

Om man har slagit samman företag har varje av de ursprungliga företagen ett eget arv. Även om man har motsvarande produkter så är de vanligen produktbegrepp och strukturer olika och inte möjliga att direkt ersätta med en gemensam.

Datatransformation till och från ett integrationsskikt

Ofta har man ett skikt av dataintegration mellan olika delar av verksamheten som lever sitt eget liv. Man har kanske en idé om att man kan underlätta integration genom att skapa en så kallad kanonisk modell, en domänmodell som ska uttrycka en gemensam standard av begrepp med termer och definitioner som ska användas av integrationerna, för att de inte ska behöva befatta sig med enskildheterna i de olika applikationerna.

I det fall man inte har en gemensam integrationsarkitektur så har varje datafil, API eller tjänst som används ofta sin egen struktur och terminologi.

Datatransformation mellan verksamheter

Alla verksamheter tar in data från externa källor eller exporterar till externa parter. Då har man ett kontrakt, ofta inofficiellt, antingen den externa partens, vårt eget eller en tredje parts som uttrycker syntax och semantik för datautbytet. I vilket fall behöver man transformera data från ett externt format till vårt eget eller omvänt.

Datatransformation mellan operativa och analytiska förmågor

Ofta behöver man strukturera data för analys och rapportering på ett helt annat sätt än för den vanliga operativa hanteringen. Ofta gör man det i ett gemensamt data warehouse, eller på motsvarande sätt fast utspritt i olika applikationer. Då behöver man transportera och transformera data från de operativa applikationerna till data warehouse. Vanligen sker det i flera steg genom en serie av staging-areor och bearbetningar. Ofta ändrar man inte bara struktur utan även benämningar. Ibland i många steg. Om man inte gör detta kontrollerat blir det som viskleken, med tilltagande förvirring i benämningar ju längre man kommer i kedjan av transformationer.

Datatransformation till rapporter och analyser

De analytiker som sedan tar ut standardrapporter eller gör särskilda analyser på data från data warehouse behöver ofta ändra namn och strukturer för att passa det speciella syftet. Det är naturligt men tillför en ytterligare risk för språkförbistring om det inte hanteras bra.

Bra och dåliga diskrepanser

Dessa integrationer är alla nödvändiga och därmed behöver vi transformationer. Vissa av de skillnader i struktur och språk som då uppkommer är också nödvändiga. De beror på att vi inom samma verksamhet, liksom mellan olika verksamheter, har olika kontext och därmed ibland behov av något olika synsätt. Det är naturligt och får inte ignoreras.

Men andra diskrepanser har bara uppstått med tiden eller är ett arv, som till exempel spåren efter sammanslagningar av olika organisationer.

Hur ser det ut i din verksamhet?

Känner du igen dig? Är det din verksamhet jag beskriver?

Vad att göra?

Vi har diskrepanser som är nödvändiga och andra som är onödiga. I vilket fall som helst behöver vi kunna sortera, förmedla och hantera denna mångfald. Och så gott det går skapa en gemensam syn vilket omfattar att göra skillnaderna tydliga och hanterbara. Och givetvis med tiden om så möjligt arbeta bort felaktigheter och onödiga skillnader.

Hur gör vi det? Det får bli ämnet för nästa artikel.