Informationsarkitektens drömjobb

Som informationsarkitekt är business intelligence-området det bästa sammanhanget att verka. Där har vi en central roll i ett utvecklingsarbete som är verksamhetsövergripande och samtidigt så konkret att det ger tydlig återkoppling.

/Peter Tallungs, IRM, 2024-06-19

Datahanteringen i BI-världen

I min förra artikel beskrev jag hur business intelligence (BI)-området skiljer ut sig från vanliga operativa verksamhetsfunktioner då det gäller datahantering. De flesta informationsarkitekter känner sig nog mer hemma i den vanliga verksamheten med sin transaktionella datahantering. Då kan det vara en tröskel att ta sig till BI-världen. Men det är mödan värt, ty det är svårt att tänka sig ett bättre område för en informationsarkitekt att verka inom. Det vill jag motivera i den här artikeln.

Observera att jag i denna artikel för enkelhetens skuld har förutsatt en BI-arkitektur med ett traditionellt centralt DW (data warehouse). Om ni i er verksamhet har en annorlunda arkitektur gäller fortsatt det som sägs här, fast kanske formulerat lite annorlunda.

Våra modeller behöver vara relevanta och användbara

Varför BI-världen är ett så bra ställe att verka på för oss informationsarkitekter har att göra med vilket sammanhang vi behöver för att bäst komma till rätta. Vi vill känna att vi gör nytta, att våra modeller verkligen brukas och hjälper verksamhets- och it-folk att analysera, förstå, definiera, benämna och kommunicera om verksamheten och vad den hanterar. En förutsättning är att våra modeller är relevanta och användbara, adresserar det som behövs och uttrycker vår gemensamma förståelse. Det är ju det vårt arbete går ut på.

Och vidare, för att våra modeller ska vara relevanta och användbara måste de ha en nära koppling till verkligheten, hur data och de företeelser data representerar verkligen företer sig i verksamheten. Annars blir det som ett gap mellan karta och verklighet och våra modeller blir skrivbordsprodukter utan praktisk användning.

Detta tror jag vi alla skriver under på. Men vad betyder det? Var i verksamheten ska vi då verka för att få de förutsättningarna?

Vi behöver jobba i konkreta utvecklingsarbeten

Vi behöver jobba integrerat i konkreta utvecklingsarbeten. Ty det är först i den praktiska verkligheten, i det iterativa utvecklingsarbetet, som vi på djupet kan se och förstå hur saker fungerar och behöver vara. Vi skapar oss en gemensam förståelse både i detalj och översikt. Vi behöver en interaktion, en ständig iterativ återkoppling mellan vad modellen säger och modellens konkreta användning. Innan dess är modellen bara en första hypotes, mer som frågor än svar.

Dilemmat med konkreta utvecklingsarbeten

Ett exempel på ett konkret utvecklingsarbete kan vara att man bygger en it-applikation eller en tjänst i någon form. Sådant som man gör då man utvecklar verksamhetens operativa funktioner. Men man har då den begränsningen att man inte jobbar med större helheter, som en verksamhets hela domän.

Å andra sidan, då vi jobbar verksamhetsövergripande, som att ta fram en informationsmodell för en hel verksamhet, så blir det inte samma konkreta koppling till verkligheten. Modellen blir då bara grov och riskerar att vara ganska missvisande så snart man kommer ner på lite mer detaljnivå. De modeller vi tar fram på ett sådant övergripande plan brukar inte bli användbara annat som en mycket grov översikt. På så sätt blir det att vi offrar den konkreta nyttan mot en bred överblick. Det är ett dilemma.

Måste vi välja mellan nytta och överblick?

Det kan verka vara en omöjlighet att jobba verksamhetsövergripande och på samma gång åstadkomma ett riktigt konkret användbart resultat. Men det finns ett sammanhang där förutsättningarna är helt annorlunda, där vi kan slippa ifrån det dilemmat. Där överblick och konkret utveckling förenas. Det är i BI-världen. Ty där hanterar vi begrepp, regler, benämningar och data från många olika delar av verksamheten, alltså det som ger en bred överblick, samtidigt som vi har en central roll i ett konkret utvecklingsarbete.

Jag tror det är svårt att hitta denna kombination av verkligt konkret detaljarbete och överblick på något annat ställe i en verksamhet.

Du kanske tänker att samma gäller för integrationssatsningar, där man bygger tjänster för data från många olika håll och tillhandahåller dessa tjänster för många funktioner. Men skillnaden är att man där inte är lika tvingad till att begrepp och dimensioner hänger ihop tvärs över hela tjänstekatalogen på samma sätt som begrepp och dimensioner behöver vara kompatibla inom BI-värden. Man har där inte heller samma tradition av arbetssätt och modellmönster för att få det hela att hänga ihop.

En annan skillnad är att de begrepp och benämningar man där normerar endast gäller för de tjänster man bygger. Det vill säga att dessa benämningar blir synliga bara för de programmerare som använder tjänsterna i programkod. Till skillnad från BI-sammanhang där allt du gör blir synligt både för alla analytiker och rapportmakare som använder BI. Samt att de termer och begrepp du tar fram kan bli normerande även för begreppsapparaten i alla rapporter i verksamheten. På så sätt skapar du ett normerat verksamhetsspråk med definitioner och benämningar som snabbt sprids och gör att hela verksamheten får en enhetlig och väldefinierad terminologi. Och det inte bara på papperet utan i den praktiska verkligheten.

Så om jag får välja är BI-gänget ”the right place to be”.

BI formar verksamhetens begrepp och språk

En DW/BI-funktion har konkret och direkt påverkan på hela verksamheten, hur man förstår och ser på verksamhetens data och därmed även på det som verksamhetens hanterar, inklusive begrepp och språk. Påverkan är större och mer direkt än andra typer av övergripande arbeten som integrationsprojekt, data management-projekt och andra.

De olika modellerna

Det är framför allt tre typer av modeller jag behöver ta fram för att stödja DW/BI-funktionen.

Den gemensamma informationsmodellen

I BI-sammanhang behöver vi arbeta runt en gemensam konceptuell och detaljerad informationsmodell (eller om man vill se det som en domänmodell) över hela det område (domän) som man täcker. Modellen behöver vara normaliserad och gestaltad både med diagram och text. Där behöver samtliga begrepp definieras, benämnas och beskrivas, samt verksamhetsregler med mera. Det vill säga hela verksamhetslogiken egentligen, hur den är förstådd, och hela det normerade verksamhetspråket. Det blir alltså den mest samlade beskrivningen av allt det som verksamheten hanterar och samtidigt detaljerad ner till mest finkorniga nivå. Som informationsarkitekt blir det min viktigaste uppgift att ansvara för det arbetet, i tät samverkan med olika parter.

Transformationsmodeller

Data från de olika källorna behöver översättas till de gränssnitt man upprättar mot DW. Gränssnitten följer kontrakt som baseras på begreppen i den gemensamma informationsmodellen. Transformationerna från källornas struktur och begrepp till kontraktet mot DW följer regler som bör dokumenteras i modeller.

BI-kartan

Du behöver också ta fram en karta över hela dataflödet för BI, både internt och externt. Den kartan omfattar hela det ekosystem som BI är:

• Källorna, samtidigt både verksamhetsfunktioner och it-applikationer. Ofta även källornas källor.
• DW-miljön, de olika staging-areorna och transformationerna.
• BI-miljön, hur data exponeras och för vilka BI-användare, både för ad-hoc-analyser och rapporter.
• Standardrapporter, vem som ansvarar för rapportmallarna och vilka det är.
• Vem som genererar själva rapporterna.
• Vem som konsumerar själva rapporterna, ofta även konsumenternas konsumenter.

Jag brukar utforma denna karta som en verksamhetskarta med verksamhetsfunktioner och verksamhetstjänster. Kartan blir den gemensamma förståelsen av hela BI-ekosystemet, med alla dess komponenter och samband, där informationstekniken blir till en integrerad del av verksamheten och inget separat.

Utöver dessa modeller som listats här finns också de fysiska datamodellerna. Dels modeller för datalagring i DW (Data Vault eller motsvarande), dels modeller för presentation till BI-användare (dimensionsmodeller). Särskild de senare är det intressant för mig som informationsarkitekt att vara med att ta fram. Det ger mig en djupare förståelse på två sätt. Dels för hur data behöver användas till analyser, dels sätter våra vanliga normaliserade modeller i ett perspektiv.

Samverkan med olika parter

Som informationsarkitekt inom BI behöver jag samverka med olika parter enligt följande:

Samverkan med dataproducenter

För att förstå det data som levereras från källsystemen behöver jag jobba nära källsystemens användare, it-folk och områdesexperter. Det gör att jag får en bra förståelse för hur data ser ut och vad de betyder i de olika sammanhang källsystemen verkar. Det ger upparbetade kontakter som jag behöver samverka med kontinuerligt. Utanför BI-världen har man sällan den bredden över många olika sammanhang.

Samverkan med verksamhetsexperter

Jag behöver jobba nära olika verksamhetsexperter. Ofta i små riktade och återkommande workshops.

Samverkan med BI-användare

BI-användarna är analytiker och rapportmakare som behöver en samlad, koordinerad och integrerad bild av data från olika källor. Därmed behöver du jobba tillsammans med dem. De kan vara affärs-, produkt-, kund- eller riskanalytiker.

Detta samarbete är guld värt, ty det är de som kan säga när något av det du gör fungerar eller inte. De har till skillnad från vanliga verksamhetsroller en större förståelse för och behov av ordning i begrepp och data. Min erfarenhet är att de som jobbar i verksamhetens operativa delar, som kundtjänst, tillverkning och leverans, inte alltid är så intresserade av begrepp och datakvalitet som vi kanske ofta tror. Deras arbete fungerar ändå.

Det är analytikerna som svettas över skilda definitioner, strukturer och benämningar. Som inte ens kan svara på ens hur många produkter eller kunder vi har då vare sig kund- eller produktbegrepp är tydliga och gemensamt definierade, förstådda eller benämnda. Det är dessa som blir dina närmaste allierade, dina sagesmän, och ger den ultimata återkopplingen på om det du gör är bra.

Det kan dock ta lite tid innan man får deras förtroende. De är ofta frustrerade både på it-folk och konsulter, då de tycker att de inte får det de vill ha. Du behöver först bevisa dig. Förtroende är något som vinns, och sällan något som delas ut på förhand.

Men när du bevisat dig, och när de börjar förstå att de i dig har en partner som kan lösa deras problem, få ordning på begrepp och data, blir de dina starkaste supportrar. Det är de som till verksamhet- och it-ledning kan motivera ditt arbete och din nytta, något som du själv har mycket svårt att göra.

Samverkan med DW-teamet

De du samverkar närmast med, där du är själva spindeln i nätet, är själva DW-teamet. Ett DW-team gör ett viktigt tekniskt jobb men har sällan intresse och ork att ta tag i annat än det rent tekniska. De utformar fysiska modeller, både de som behövs i själva DW och de som används av DW-användarna. De bygger rutiner som laddar och transformerar data från källsystemen och hela vägen genom de olika staging-areorna och till BI-användarna. De är mer än glada att du tar ansvar för allt det andra, de mera mjuka aspekterna, som att facilitera samarbete med de olika parterna, få alla på samma spelplan, förstå och normera begrepp och data.

Hur låter detta?

Så välkommen du också till BI-världen, du som vill känna glädjen i att göra konkret nytta nu och här.
Och till dig som redan jobbar med BI, hur bra stämmer min bild med din uppfattning av hur det fungerar? Hur gör ni i er verksamhet? Jag tror de finns mycket att diskutera. Jag har bara skrapat på ytan.