Informationsmodellering som arkeologi – en metodbeskrivning

”Dataarkeologi” är metoden att utifrån befintliga datastrukturer och data få fram vilken information verksamheten hanterar. Så här gör man.

/Peter Tallungs, IRM, 2024-10-24

Dataarkeologi

Häromdagen bad en kollega mig att skriva om hur man utifrån vad man hittar i verksamhetens databaser, filer och tjänster, tar fram en gemensam informationsmodell. Den metod som jag kallar för ”dataarkeologi”. Här kommer det!

Olika metoder för att modellera en verksamhets information, begrepp och språk

En grundläggande uppgift för en informationsarkitekt i en verksamhet är att skapa en gemensam informationsmodell. Jag tycker att en informationsmodell kan och bör ha en betydligt större roll än vad den traditionellt har haft. Ty rätt utformad säger den inte bara vilka data man hanterar utan också vad dessa data representerar. Det vill säga allt det som verksamheten hanterar, med benämningar och definitioner. Därmed odlar vi fram ett normerat gemensamt språk för verksamhetens domän. Inte minst blir modellen, rätt utformad och gestaltad, en plattform för fortsatt gemensamt utforskande av verksamhetens domän.

Det finns olika metoder för att ta fram en sådan informationsmodell. Man kan göra det med verksamhetskunniga i seminarieform eller i mindre riktade workshops, och man kan studera beskrivningar av olika slag. Man kan också utgå från befintliga data i it-ekosystemet, det vill säga från innehållet i databaser, filer med mera. I verkligheten behöver man kombinera dessa metoder.
Du kan läsa mer om de olika metoderna i följande artiklar:

Hur kan informationsmodellering gå till? – del 1

Hur kan informationsmodellering gå till? – del 2

Om metoden dataarkeologi

Den metod som jag arbetat med och som jag ser som överlägsen, och därmed blivit till en grund i mina uppdrag är den jag kallar ”dataarkeologi”. Det innebär att jag utgår från de datastrukturer och den data jag hittar i verksamheten. Namnet ”arkeologi” kommer av att metoden har en liknande roll inom informationsmodellering som arkeologin har inom historievetenskapen. Precis som arkeologin ger den konkreta fakta att utgå ifrån. Fakta som förstås måste tolkas och sättas i sitt sammanhang, men ändå ovedersägliga fakta. Metodens stora styrka ligger i att den utgår från data. Data visar vad som faktiskt har hänt och händer i verksamheten. Finns det en post i en databas så har det ovedersägligt hänt något i verksamheten. Data speglar vad som hänt, med den struktur och de benämningar som förekommer rent fysiskt i informationssystemen. Sedan kan jag förstås inte bara rakt av ta de data jag hittar; jag behöver tolka fynden. Tillsammans med olika sakkunniga undersöker vi vad dessa data verkligen representerar. Det liknar hur verkliga arkeologer gör med de fynd de gräver fram.

Inte minst viktigt; metoden säkerställer att det hela tiden finns en direkt koppling mellan vad som finns i människornas huvuden (den mentala bilden) och vad som finns i datastrukturer (den fysiska representationen). Och det med två olika perspektiv i en och samma modell. På det sättet får alla samma bild och verklighet att förhålla sig till.

Det är vanligt att människor från olika delar av en verksamhet har olika bilder i huvudet, och mycket möda och misstag handlar om att man ständigt pratar förbi varandra. Inte minst gäller det klyftan mellan verksamhet och it. En gemensam karta och förståelse minskar friktionen i kommunikationen, och gör alla dialoger krispiga och effektiva. Det betyder inte att man alltid behöver vara överens – tvärtom. Men det förhindrar att man pratar förbi varandra i onödan, bara för att man lägger olika betydelse i begreppen. Med en gemensam karta blir det tydligt att när vi tycker olika, beror det på att vi verkligen har olika aspekter att bidra med. All utveckling blir då mycket mindre frustrerande och mycket mera effektivt.

Det är den stora poängen med en modell, att vi ska få en gemensam bild, tvärs över våra olika roller. En gemensam förståelse, ett gemensamt språk, en gemensam plattform att tillsammans utveckla över tid.

Gör så här

Så här vill jag beskriva metodens olika steg. I praktiken är arbetet mer iterativt än vad som framgår här, men sekvensen visar ändå hur arbetet gradvis skiftar fokus.

1. Skapa en grundläggande bild över vilka it-applikationer som finns i verksamheten

Skapa en grundläggande bild över vilka it-applikationer som finns i verksamheten, inklusive databaser och tjänster. Välj ut den eller de mest centrala databaserna (eller filerna). Detta görs tillsammans med organisationens it-arkitekter eller motsvarande.

2. Etablera samarbete med den eller de personer som är mest kunniga

Ta reda på och etablera samarbete med den eller de personer som är mest kunniga om strukturen och innehållet i databasen. Det är vanligen någon it-utvecklare eller databasdesigner, ofta sekonderad av någon ovanligt kunnig verksamhetsexpert.

3. Se till att få tillgång och behörighet till databasen via lämpligt verktyg

Helst bör du använda verkligt produktionsdata, men om det inte är möjligt av behörighetsskäl kan det duga med testdata. Större verksamheter har ofta rutiner för att skapa testdata som är mycket likt produktionsdata, men med känsliga uppgifter maskerade. I värsta fall får man arbeta med olika utdrag av data.

4. Skapa en första överblick

Skapa en första överblick genom att rita en karta över vilka tabeller som finns och vad de verkar innehålla. Ta reda på vilka tabeller som anses vara mest centrala för att utgå från.

5. Börja rita en första version av informationsmodellen

För varje tabell i databasen, skapa en entitet med attribut på följande sätt: Titta på vilka kolumner det finns i tabellen. Utifrån kolumnnamnet och vad innehållet verkar vara, bestäm namn på entiteten och dess attribut. Ta hjälp av den datakunnige för att hjälpa till med tolkningen.

Observera att det inte alltid finns ett ett-till-ett-förhållande mellan tabeller och entiteter. Det som är en och samma tabell kan med tiden ha fått rymma olika saker och blir då skilda entiteter. Och omvänt, två eller fler tabeller kan ibland rymma attribut som avser samma typ av företeelse och blir då en och samma entitet.

Sortera bort det som är skräp. Vissa tabeller kan innehålla data som skapats för ett tillfälligt bruk och utan varaktigt värde, till exempel för att skapa en tillfällig rapport. Det kan vara något som bara råkat bli kvar och inte raderats. Eller så är det en tabell som skapats men aldrig kommit i bruk. Samma sak gäller för kolumner. Vissa kolumner har skapats men aldrig kommit till användning. De kan vara tomma eller innehålla skräpdata.

Vissa tabeller eller kolumner kan vara avsedda för att hantera saker som bara rör själva systemet internt, och saknar betydelse för verksamheten. Hoppa över dessa, men endast om du är helt säker på att de inte behövs.

Observera att de namn du väljer för entiteter och attribut ofta behöver skilja sig från tabell- och kolumnnamn, och det av många skäl. Namnen i databasen är vanligtvis förkortade, svåra att tyda och ofta otydliga. Det kan exempelvis stå ”Date” men man kan inte se om det är datum då posten skapades i detta system, i ett källsystem, eller datumet då händelsen inträffade som genererade posten. Ofta är namnen inte helt korrekta och ibland helt fel och missledande. Som när en entitet heter ”Juridisk person” eller ”Företag” fast man avser alla organisationer och inte bara de som råkar vara juridiska personer. När vi skapar en informationsmodell skapar eller normerar vi ett gemensamt språk för allt det som verksamheten hanterar. Det är en viktig uppgift där vi måste vara noggranna. Ty det är språket som på sätt och vis blir den värld vi uppfattar. Det hjälper oss att se klart eller hindrar oss från att göra det.

Dock behåller jag tabell och kolumnnamnen bredvid de namn jag skapar, för att behålla en spårbarhet från informationsmodell till datakällor. Det är något mycket viktigt för att behålla kopplingen mellan informationsmodellen och den fysiska lagringen av data. Jag skriver dessa tabell- och kolumnnamn i grått för att tydligt utskilja dessa från de nya namnen som blir grunden till det nya normerande och mera korrekta språk vi skapar.

6. Skapa entiteter för varje värdeförråd

För attribut med uppräknade värdeförråd, som till exempel statuskoder, skapa entiteter för varje värdeförråd även om dessa värden inte finns lagrade i tabeller. För varje sådan entitet behövs kod, namn, definition. Kanske också sorteringsordning med mera. Dessa värden är mycket viktiga för verksamhetslogiken och bör därför vara centrala i informationsmodellen.

Trots detta ser man sällan att dessa värdeföråd tas med i informationsmodeller. Det är som att informationsmodellerare ofta automatisk utesluter dataförekomster utan att förstå att det är skillnad på förekomster och förekomster. När det gäller uppräknade värdeförråd, som ju är en form av referensdata, är dessa förekomster centrala för verksamhetslogiken och behöver hanteras.

Du kan läsa mer om referensdata i denna artikel: Glöm inte referensdata!

7. Strukturera modellen genom att dela in den i ämnesområden

Hur du kan gå tillväga kan du läsa om i denna artikel: Informationsmodellering: Om ämnesområden

8. Skapa en övergripande struktur genom hur jag placerar ämnesområdena

Kanske vi placerar vår organisationsstruktur separat, våra erbjudanden (produkter) för sig, omvärlden (kunder) för sig och interaktioner med omvärld (beställningar, leveranser, faktureringar, betalningar) däremellan.

Detta beskrivs närmare i denna artikel: Informationsmodellering: Om struktur i flera-nivåer

9. Stäm av med datakunniga

Har jag förstått det hela rätt? Det finns alltid saker att korrigera innan alla är överens. Men snart har man en gemensam modell som kan använda tvärs över både verksamhet och it. Och detta redan nu, och nästan alltid för första gången i organisationens historia.

10. Skapa formatet för textdelen av modellen

Hittills har modellen enbart varit grafiskt gestaltad. För att inkludera allt det som behövs krävs också en strukturerad, textuell del. Många ser detta som en beskrivning av modellen, men jag anser det är viktigt att se det som en integrerad del av själva modellen. Ty vi bör använda och kombinera alla beskrivningstekniker som gör jobbet. Då behöver vi både grafik och text – och dessa bör vara så integrerade som möjligt.

Skapa en struktur för detta. Jag använder dokument i MS Word. Alla entiteter och attribut behöver ha följande: namn (normativt namn, samt eventuella synonymer), definition (det viktigaste av allt) och ytterligare beskrivningar. Attribut behöver även format (text, heltal, decimaltal, längd) och värdeförråd. Både entiteter och attribut behöver beskrivas med verksamhetsregler i text.

Och överallt behövs noteringar, helst daterade och signerade. Revisionshistorik och versionshantering är också nödvändiga. På detta sätt blir modellen inte bara en ögonblicksbild av vår gemensamma förståelse vid en viss tidpunkt, utan en arbetsplattform över tid.

Se djupare beskrivning av detta i dessa artiklar:

• Informationsmodellering: Om namngivning
• Försvar för enkla verktyg – del 3: Skrivverktyg
• Informationsmodellering: Om verksamhetsregler

11. Ta fram alla textuella beskrivningar

Viktigast är definitionerna, så att vi verkligen har fått en gemensam förståelse av vad varje dataelement representerar för företeelse eller egenskap.

Du kan läsa mer om  detta i denna artikel: Det viktigaste du gör som informationsarkitekt: Arbetet med verksamhetens begrepp och språk

12. Arbeta igenom modellen

Arbeta igenom modellen i små riktade workshops med kunniga inom olika områden. Modellen blir snabbt den gemensamma förståelsen av verksamhetens operativa logik och det gemensamma språket.

13. Fortsätt med nästa it-applikation eller fil

Lägg till nya entiteter eller attribut till samma modell, eller, när samma data förekommer i olika sammanhang under olika namn, identifiera och dokumentera synonymer. Fortsätt att utöka modellen med fler applikationer och filer.

Standardsystem är en utmaning

Om it-systemet är skräddarsytt, det vill säga byggt av organisationen själv eller med hjälp av konsulter, är det här arbetet relativt rakt och enkelt. Strukturen återspeglar då oftast hur verksamheten fungerar, även om systemet kan vara mer eller mindre föråldrat. Men om det handlar om ett standardsystem har vi en helt annan utmaning. Strukturen är då mycket mer generell för att den ska kunna fungera för många olika verksamheter, och man har utan undantag behövt ”tweaka” strukturen för att passa verksamhetens specifika behov. Många tabeller och kolumner har mycket oklar användning. It-personalen har ofta sämre förståelse för systemet, och inte ens leverantörens personal vet hur de som anpassade standardsystemet till just denna verksamhet gick till väga.  Leverantören vill ofta inte ge tillgång till datastrukturer, med motiveringen att de är deras skyddade tillgångar. I praktiken innebär detta att verksamheten tappar kontroll över sina egna data. Varken leverantören eller kunden har tillräcklig dokumentation eller kunskap.

I sådana fall gäller det att vara envis och framhålla att kunden faktiskt har rätt till sina egna data. Då brukar leverantören släppa ifrån sig data i någon form, men ofta mot betalning för arbetsinsatsen. Man kan hoppas på att få någon form av stöd från leverantörens utvecklare, men det brukar vara svårt att få.

Tillvägagångssättet som jag beskrivit är detsamma, men framfarten blir knöligare och betydligt långsammare. Trots detta är det alltid viktigt att ta kontroll över sina egna data. Man skulle önska att organisationer förstod värdet av att äga och kontrollera sina informationstillgångar, och inte släppa kontrollen på det sätt som ofta sker när man inför standardsystem.

Kartlägg data

Nu kan man tycka att man är klar, men jag menar att man bör gå ännu djupare. För att gå djupare, få till en än mer djup förståelse, behöver man gå vidare från datastrukturerna och gå igenom själva datainnehållet ordentligt. Det ger två viktiga resultat: dels en fördjupad förståelse av vad datan representerar, vilket ofta leder till vissa korrigeringar av informationsmodellen, dels något annat – något som egentligen inte tillhör informationsmodellering eller informationsarkitektur, utan snarare datainventering.

Datainventering är en grund inom dataförvaltning (data management), där syftet är att ta reda på vilken data man har och vilken kvalitet den håller. Hur man utför detta arbete kan bli en egen artikel, men eftersom det bidrar till informationsmodellen beskriver jag processen här.

Gör så här

Använd ett SQL-verktyg, eller liknade, för att ställa frågor mot data. För varje kolumn i varje tabell (och även kombinationer av kolumner) ställ följande frågor.

1. Finns det innehåll som bryter mot regler om vad som är obligatoriskt?

Borde det ha innehåll, antingen för att det är ett obligatoriskt fält eller för att det är obligatoriskt på grund av sammanhanget, så är det ett fel i data.

2. Finns det värden som bryter mot vad som ska vara unikt?

3. Bryter innehåll mot regler för formatet?

Textfält: Sortera kolumnen från kortaste till längsta textsträng. Kolla om texten är avhuggen i slutet. Kontrollera om språk, stavningen och användningen av versaler stämmer överens med de riktlinjer som vi har angivit för datakvalitet.

Numeriskt fält: Sortera från lägsta till högsta värde. Kolla om det finns orimliga värden.

Datumfält: Kolla om det finns innehåll som inte är giltiga eller rimliga datum.

4. Finns det tomma referenser?

Om kolumnen är en främmande nyckel kolla om det finns värden som inte refererar något som finns i den refererade tabellen.

5. Finns innehåll som är föråldrat eller felaktigt?

För globala referenstabeller, till exempel landskoder, postnummer, kommuner i Sverige.

6. Finns det innehåll som bryter mot regler i övrigt?

Det vill säga data som är motsägande eller orimligt. Som att kunder inte är aktiva men ändå har aktuella beställningar, eller har adresser i kommuner som inte längre finns, med mera med mera.

När något bryter mot en regel som jag antagit som gällande, är det vanligtvis en brist i datakvalitet. Men inte sällan beror det på att mina antaganden om datan är felaktiga, vilket innebär att jag behöver justera i datamodellen. Det är därför själva dataanalysen också bidrar till att förbättra informationsmodellen.

Resultatet sammanställer jag i en rapport som bygger på och utökar textdelen av informationsmodellen. Detta eftersom informationsmodellen fungerar som ”facit”, det vill säga visar vad som bör betraktas som korrekt datakvalitet. De rapporterade bristerna är avvikelserna mellan det som informationsmodellen stipulerar (regelverket) och det faktiska datainnehållet.

I rapporten redovisar jag inte bara vilka brister jag identifierat, utan även vilka regler jag har antagit för vad som är korrekt data, samt vilka undersökningar jag har gjort.

Jag har med tiden också lärt mig att det är bra att spara själva SQL-frågorna i rapporten, så att jag snabbt och enkelt kan upprepa undersökningen vid behov.

Hur gör du?

Det här är ett sätt att gå till väga när jag modellerar. Hur gör du? På något helt annat sätt? Vill du lägga till något?

Jag tror att det är bra att vi delar erfarenheter för att utveckla vårt område som informationsarkitekter.

Arkeologi för enterprise-arkitektur

Det finns även en form av ”arkeologi” att tillämpa för att få fram en verksamhetskarta som visar vilka komponenter en verksamhet består av och hur de relaterar till varandra. Men det tar jag upp i nästa artikel.