Analytiska it-system – Verksamhetens stöd för att rapportera, utforska och förklara

Analytiska it-system och deras användare utgör i mångt och mycket en egen värld i våra verksamheter, skild från de vanliga operativa it-systemen och deras verklighet. Som informationsarkitekt är det ett bra ställe att finnas på.

Två typer av it-system

I våra verksamheter finns två grundläggande typer av it-system. Dels har vi de operativa systemen, som har en direkt roll i verksamhetsfunktioner som till exempel marknadsföring, försäljning och ärendehantering. Hit hör även system som stödjer verksamheten med exempelvis kund- och produktinformation.

Den andra kategorin är de analytiska systemen, som lagrar och tillhandahåller data för analys och rapportering. Det handlar om det som brukar kallas Data Warehouse, datalager, Data Lake eller Lakehouse. Som samlingsnamn används ofta Business Intelligence-system. Dessa system stödjer dem som rapporterar, utforskar och försöker förklara vad som händer i verksamheten, både nu och över tid.

De två typerna av system har helt olika uppgifter och skiljer sig därför grundläggande åt när det gäller krav och egenskaper.

Denna artikel handlar om de analytiska systemen, hur de skiljer sig från de operativa och vad dessa skillnader betyder för oss som informationsarkitekter.

Analytiska system är annorlunda

De analytiska systemen skiljer sig radikalt från de operativa. Skillnaden har sin grund i deras särskilda uppgift och i den typ och takt av förändringskrav som följer med den.

Ett operativt system stödjer en specifik verksamhetsfunktion, där det är möjligt att definiera användningsfall som förändras i ganska maklig takt. Systemet kan därmed optimeras för dessa interaktioner.

Analytiska system lever i ett mycket mer rörligt sammanhang. Deras uppgift är att lagra data som ska konsumeras av analytiska dataprodukter, till exempel rapporter och dashboards för att se vad som hänt i verksamheten, eller olika slags modeller och datamängder för att upptäcka och utforska trender och mönster i verksamhetens händelser.

Den stora skillnaden mot operativa system är att många av användningsfallen inte är kända när vi bygger systemet. Vi bygger för okända krav.

Orsaken till denna osäkerhet är följande: Analytiska system stödjer lärande och utforskande – att bygga kunskap. Människor bygger kunskap sekventiellt. En besvarad fråga vidgar vår förståelse och för upp nya frågor till ytan, frågor som vi tidigare inte kunnat förutse. En dataprodukt som börjar som något enkelt kan därför snabbt bli komplex, och systemet måste kunna rymma en sådan växande komplexitet utan att brista.

Förändringarna kommer inte bara från utsidan – när en verksamhetsprocess ändras och systemet måste följa efter – utan även från insidan, en förändring driven av systemets egen användning. Varje fråga systemet besvarar ger upphov till frågor dess användare vill ställa härnäst. På detta sätt genererar systemet sina egna ändringskrav. Ju mer lyckat systemet är desto snabbare kommer de nya kraven.

Man kan visserligen hävda att något liknande gäller även för operativa system, men där är förändringskravens takt och omfattning betydligt mer begränsade.

Vi behöver en arkitektur som kan hantera förändring

Vi kan inte designa det färdiga systemet i förväg, eftersom användarna ännu inte har formulerat de frågor som kommer att driva dess utveckling. Vi behöver en arkitektur som hanterar förändring som ett normaltillstånd under systemets hela livscykel.

Arkitektur handlar alltid om att ta höjd för en osäker framtid. När vi designar system kokar det ner till tre utmaningar. Vi vill:

• minimera beroenden,
• hantera förändringar smidigt och
• begränsa komplexiteten.

Dessa tre utmaningar är tätt relaterade: Beroenden förstärker hur hårt förändringar påverkar systemet, och okontrollerade förändringar multiplicerar komplexiteten.

I det följande går vi närmare igenom var och en av dessa utmaningar, med särskilt fokus på analytiska system.

Vi behöver minimera beroenden

Analytiska system har vanligen många datakällor och ett antal konsumenter som i sin tur bygger olika dataprodukter för slutanvändare.

Dataprodukt syftar på en kurerad, återanvändbar datamängd, inklusive metadata, semantik och format, som underhålls och är direkt tillgänglig och användbar för verksamhetsändamål. Det kan till exempel vara en rapportmall för en standardrapport, en dashboard eller en datamängd tillgänglig för analytiker i ett star schema.

Varje dataprodukt kan behöva data från flera källor samtidigt som en och samma källa kan föda flera dataprodukter. Detta skapar ett många-till-många-beroende mellan källa och konsumtion. Om varje dataprodukt kopplades direkt till sina källor skulle vi få just de direktberoenden vi vill undvika. Varje förändring i en källa skulle då kunna orsaka en kaskad av ändringar i de dataprodukter som använde den. I takt med att systemet växer skulle också nätet av beroenden växa och bli allt svårare att hantera.

Vi kan därför inte bara bygga en dataprodukt i taget utan eftertanke. Vi måste ta höjd för framtiden och bygga ett system som över tid kan stödja skapandet av många nya dataprodukter, vars krav vi ännu inte känner till.

Vi behöver kunna hantera förändringar

Ett analytiskt system är i konstant förändring genom hela sin livscykel. Vissa förändringar har externa orsaker – källsystem ändras eller ersätts, nya källor tillkommer eller lagar och regler påverkar vad vi kan lagra och hur. Andra förändringar är interna: nya entiteter, relationer och attribut tillkommer, nya dataprodukter skapas eller tekniska förändringar kräver migrering.

Eftersom vi inte i förväg kan veta vilka dataprodukter som kommer att behövas måste systemet stödja iterativ utveckling, det vill säga kontinuerlig utveckling under hela sin livscykel.

Hur stor påverkan en förändring får beror inte bara på förändringen i sig, utan på den arkitektur och de designmönster vi valt. Ett byte av källsystem kan, med en genomtänkt systemarkitektur, begränsas till en enda transformation. Med en mindre genomtänkt arkitektur kan samma förändring få varje dataprodukt som är beroende av källan att sluta fungera. Skillnaden ligger i arkitekturen.

Vi behöver hålla komplexiteten i schack

Ett diversifierat it-landskap, olika sätt att representera, segmentera, aggregera och kalkylera data samt den oundvikliga osäkerheten kring systemets framtida design – allt detta gör det lätt att hamna i extremt komplexa kod och datastrukturer. När koden blir så komplex att ingen vågar röra den, eller när en ny funktion tar så lång tid att få på plats så att användarna i stället bygger egna lösningar, har systemet fallerat.

Utmaningen är att stödja många dataprodukter, var och en med sina egna krav, utan att låta komplexiteten sprida sig och kontaminera andra dataprodukter. När vi dessutom tar med i beräkningen att varje dataprodukt också i sig kan växa och utvecklas iterativt, så förstår vi att behovet av att hålla komplexiteten i schack blir än viktigare.

Hur gör man?

Hur ser då den systemarkitektur ut som kan hantera dessa utmaningar?

Det finns en systemvetenskaplig princip som heter ”Separation of Concerns”. Den innebär att ett system delas upp i tydligt avgränsade delar, där varje del har ett specifikt ansvar. Syftet är att reducera komplexitet genom att göra delarna mer oberoende av varandra.

Analytiska system brukar designas med tre konceptuella lager som data rör sig genom i följd. Fysiskt kan det finnas fler än tre lager, men dessa kan i regel grupperas i tre konceptuella nivåer:

• Data according to System (DAS) – Data som det tas emot från källsystemen.

• Data according to Business (DAB) – Data integrerade och modellerade utifrån verksamhetens begrepp.

• Data according to Requirements (DAR) – Data formade för specifika analytiska användningsfall.

Beteckningarna för dessa lager varierar, men själva indelningen återkommer mer eller mindre tydligt i analytiska system. Jag använder här de beteckningar som datarkitekturexperten Patrik Lager företräder.

Indelningen i dessa lager bryter beroenden, innesluter och begränsar omfattningen av ändringar och bryter ner komplexitet till hanterbara delar. I det följande beskriver jag varje lager närmare.

Data according to System (DAS)

Det är i detta lager som systemet tar kontroll över inkommande data från de olika källsystemen. Data anländer via batchfiler, Kafka, JSON eller API-anrop och lagras i sina råa format. Ibland behöver dessa data göras mer hanterbara inför nästa lager. Nästlade strukturer kan packas upp till tabellformat och strömmande data persisteras i historiserade tabeller. Men data förblir i sin representation ändå alltid källsystemorienterad.

Detta konceptuella lager är ofta i sin tur uppdelat i två fysiska lager: en rå landningszon där data anländer och en staging area där data packas upp till tabellstrukturer för vidare bearbetning nedströms.

Här är två saker särskilt viktiga. För det första metadata: att registrera vilka data som anländer, när och hur för att skapa spårbarhet från producent till konsument genom alla lager.

För det andra datakvalitet: att upptäcka och profilera brister så tidigt som möjligt. Filosofin bör vara att ta emot all data i landningszonen, oavsett brister, men att sedan inte släppa vidare data till staging-arean som inte följer de datakontrakt man har.

Data according to Business (DAB)

Det är i detta lager som problemen med beroenden, förändringar och komplexitet adresseras på allvar. Det är också här det avgörs om systemet kommer att lyckas eller misslyckas över tid.

Här är Bill Inmons klassiska principer fortfarande relevanta. I Building the Data Warehouse beskriver han fyra grundläggande krav. Data i detta lager ska vara:

Subject Oriented

Organiserat kring verksamhetsbegrepp, inte källsystem.

Integrated

Semantiskt och strukturellt integrerat och källsystemagnostiskt, det vill säga oberoende av enskilda källsystem.

Time-variant

Historiserat, så att vi kan följa hur data förändras över tid.

Non-volatile

Data varken raderas eller ändras någonsin. Tidigare versioner behålls för att säkerställa historik, spårbarhet och kontroll. Vi behöver alltså lagra både historiska och aktuella poster, i stället för att skriva över äldre värden.

För att åstadkomma detta behöver vi en struktur som utgår från vår gemensamma konceptuella modell av verksamhetens data, den centrala modell som jag ofta kallar BIM, Business Information Model.

Men datastrukturen i DAB är inte en exakt fysisk kopia av BIM. Den behöver transformeras till en struktur som kan hantera förändringar och historik över tid. Det görs på ett tämligen mekaniskt sätt. Hur det går till återkommer jag till längre fram.

DAR (Data According to Requirements)

I detta lager möter data de analytiska användarna och är strukturerade för att passa deras särskilda behov. Här är det alltså användningen som styr. Dataanalytiker och rapportbyggare behöver kunna vända och vrida på data obehindrat. Därför struktureras data här vanligen i stjärnmodeller (Star Schemas).

Om de fysiska strukturerna i de olika lagren

Den grundläggande skillnaden mot operativa system är att vi i analytiska system har flera helt olika fysiska strukturer. De skiljer sig både från varandra och från strukturen i den konceptuella modellen.

Konceptuell modell Med konceptuell modell menar jag den gemensamma, systemoberoende modell som visar hur vi vill se på, definiera och benämna företeelserna som verksamheten hanterar och som avspeglas i våra data, inklusive deras egenskaper och relationer. Fysisk modell Med fysisk modell menar jag en modell som visar hur data faktiskt är strukturerat i ett specifikt system, så som det ser ut om man går in och tittar i datastrukturen.

När det gäller operativa system kan vi nästan alltid representera den konceptuella modellen och den fysiska modellen tillsammans, i samma explicita modell, ibland till och med i samma vy. Orsaken är att de vanligen inte skiljer sig särskilt mycket åt i struktur. Skillnaden ligger oftare i namn. Det är en ytlig skillnad som vi kan hantera och representera i en gemensam modell. Att konceptuell och fysisk modell ligger så nära varandra i operativa system är egentligen inte så konstigt.

Kraven på ett operativt system gör att den lagringsstruktur som fungerar bra där råkar likna den struktur vi också gärna använder för att beskriva verksamhetens information konceptuellt. Det var något man upptäckte redan på 1980-talet. ER-modellering och dess normaliserade struktur hade ursprungligen utvecklats för att designa relationsdatabaser, men visade sig fungera förvånansvärt bra även för att analysera och beskriva verksamhetsinformation och begrepp. Likheten förstärks dessutom av att vi faktiskt vill att de operativa systemen ganska noggrant ska spegla vår gemensamma syn på de företeelser som informationen representerar.

Med analytiska system ser det annorlunda ut. Här skiljer sig de fysiska strukturerna både från den konceptuella modellen och från varandra. Vi behöver helt enkelt olika strukturer för olika syften i de olika lagren.

Datastrukturen i DAS (Data According to System) har, med små undantag, samma struktur som i källsystemen.

Datastrukturen i DAB (Data According to Business) ska i stället utgå från vår gemensamma konceptuella modell av verksamhetens data, det vill säga BIM. Men vi kan inte bara kopiera den konceptuella modellen rakt av. Den behöver göras om, på ett ganska mekaniskt sätt, brytas upp i mindre delar för att vi ska kunna hantera förändringar och historik på ett robust sätt.

För detta finns tre närbesläktade modelleringstekniker som alla utvecklades från slutet av 90-talet och in på 2000-talet: Data Vault av den amerikanske svenskättlingen Dan Linsted, Focal Framework av svensken Per Olof Eriksson och Anchor Modeling av svenskarna Olle Regardt och Lars Rönnbäck. Hans Hultgren, också amerikansk svenskättling, som bland annat utbildar inom Data Vault, har använt samlingsnamnet Ensemble Modeling för den här typen av tekniker.

Gemensamt för dem är att man bryter isär den normaliserade konceptuella modellen likt ett sprängschema. Varje entitet blir ett eget objekt som aldrig ändras. Varje attribut, eller grupp av samhörande attribut, blir egna objekt. Varje relation blir ett eget objekt. Både attribut och relationer blir egna tabeller som innehåller både aktuellt värde och alla historiska värden.

På så sätt kan historik bevaras även när begrepp och struktur förändras över tid. Inget tas någonsin bort eller skrivs över. Förändringar i den konceptuella modellen, till exempel att det tillkommer ett attribut eller en relation, hanteras i stället genom att något objekt läggs till. Skillnaden mellan de olika metoderna handlar om hur radikal man är i nedbrytning av entiteterna i sina beståndsdelar där varje del har sin egen historik.

Datastrukturen i DAR (Data According to Requirements) behöver återigen se annorlunda ut, vara anpassad till behoven för de som använder data till att skapa dataprodukter. Som jag tidigare nämnt är det vanliga att man använder stjärnmodeller (star schemas). Det är en modelleringsteknik där man skiljer på grundläggande fakta och dimensioner som dessa fakta kan summeras ur. Till exempel kan en försäljningssiffra (fakta) betraktas ur dimensioner som köpare, försäljningsställe, produkt, tidpunkt, datum med flera. Metoden kallas dimensionsmodellering (Dimension Modeling).

Alla fysiska datastrukturer behöver relatera till en detaljerad gemensam konceptuell modell, Business Information Model (BIM)

Alla dessa fysiska modeller kan inte ha egna namn och definitioner på allting, utan måste referera till en gemensam konceptuell modell – den jag ofta kallar BIM (Business Information Model). BIM bär den gemensamma förståelsen mellan verksamhet och IT och ger definitioner och namn åt företeelser och egenskaper, inklusive beskrivningar och verksamhetsregler. De olika fysiska modellerna uttrycker samma innehåll, men med mer specialiserade strukturer.

Om man gör den på rätt sätt är den inte bara en representation av vår nuvarande gemensamma förståelse utan visar också hur vi kommit fram till denna, vad som hänt på vägen och vad som är utestående frågor. BIM är på så sätt också en arbetsplattform för vårt gemensamma lärande och utveckling av förståelse.

Min roll som informationsarkitekt

Var i detta behövs jag som informationsarkitekt? BIM (Business Information Model) har ju en mycket central roll i allt detta. Det är där som data och verksamhetsbegrepp definieras och får sina benämningar. Det är den modell som är ”rikslikare” för begrepp och benämningar i alla fysiska datastrukturer, från de olika lagren i det analytiska systemet till dataprodukterna. BIM representerar helt enkelt det gemensamma verksamhetsspråket. Där finns lämpligen även översättningar till de olika systemspecifika benämningarna och strukturerna i de olika källsystemen.

Därmed är utvecklingen och förvaltningen av BIM den viktigaste uppgiften för en informationsarkitekt. Det arbetet måste ske i nära samarbete med både verksamhets- och it-kunniga. Särskilt viktigt är samarbetet med analytikerna som är användare av dataprodukterna.

I övrigt är det intressant att delta i designen av de olika fysiska modellerna, speciellt star schemas, då det ger en intressant inblick i dataanvändningen. Det är också en nyttig utvidgning av mitt kunnande inom datamodellering, från de normaliserade modeller vi är vana vid till en värld som ser helt annorlunda ut. Det kan liknas vid den generella förståelse man vinner för vad språk är då man studerar andra språk.

Över huvud taget är det en bra plats att vara på som informationsarkitekt, att jobba nära dem som bygger och dem som använder analytiska system. Eftersom dessa använder data och begrepp som gäller över hela verksamheten och it-landskapet får man där den direkta kunskapen och återkopplingen.

Jag vill tacka Patrik Lager som bidragit med insikter och formuleringar som jag hämtat från hans lysande artiklar om analytiska system. Läs Patrik Lagers artiklar om analytiska system här.