Att gå från datamodell till informationsmodell är ett naturligt nästa steg när vi vill lyfta blicken från teknisk representation till verksamhetskrav. Bilden ovan visar skillnaden: till vänster en datamodell från ett befintligt system, och till höger en informationsmodell som speglar hur verksamheten egentligen behöver kunna strukturera informationen.
Återkoppling till tidigare steg: från dataskrapning till datamodell
I föregående artikel, "Från dataskrapning till datamodell", visade vi hur man genom dataskrapning kunde ta fram en datamodell baserad på skärmbilder från systemet Fortnox. Resultatet blev en konceptuell datamodell som ser ut så här:
Modellen ger en tydlig bild av hur systemet är uppsatt – men också av dess begränsningar. Det finns t.ex. bara plats för exakt en kundtyp, ett land och högst två adresser av fasta typer (leverans- och besöksadress). Den visar alltså hur systemet fungerar, inte hur det borde fungera.
För att förstå varför vi behöver gå vidare till en informationsmodell måste vi först skilja mellan begreppen data och information – något som bland annat förtydligas i Prime Arch-artiklarna Skillnad på data och information och Ett annat perspektiv på Information och Data.
Data är representationer av fakta, begrepp eller instruktioner – ofta i teknisk form, utan sammanhang eller tolkning. Data är ”det givna” (latin datum), men säger inget i sig.
Information är data som har bearbetats eller tolkats så att den får en mening för mottagaren. Det är innehåll som kan förstås och användas i ett sammanhang.
I praktiken innebär det att:
-
En datamodell beskriver hur information råkar vara lagrad i ett specifikt system – ofta med tekniska begränsningar.
-
En informationsmodell beskriver vilken information verksamheten vill kunna uttrycka och hantera, oberoende av teknisk implementation.
I Prime Arch arbetar vi med båda – men för att utveckla verksamheten framåt behöver vi gå från nulägets datamodell till mållägets informationsmodell.
Från teori till praktik – varför informationsmodellen behövs
Att förstå skillnaden mellan data och information är mer än en semantisk övning – det har direkt bäring på hur vi utformar våra modeller och ställer krav på system. Datamodellen vi tidigare granskade, hämtad från Fortnox, är ett tydligt exempel på hur information kan vara tekniskt realiserad, men ändå inte tillräckligt uttrycksfull ur ett verksamhetsperspektiv.
Fortnox-modellen visar hur kundrelaterad information lagras i dag – med fasta relationer till exakt ett land, en leveransadress och en besöksadress. Den strukturen speglar ett snävt antagande om kundernas behov och begränsar därmed vilka frågor man kan besvara, eller vilken flexibilitet man kan erbjuda i sin tjänst.
Detta skapar så kallade gap – brister mellan det som verksamheten vill kunna uttrycka och det som dagens datamodell tillåter.
De två exempel vi nu går vidare med illustrerar detta tydligt:
-
Gap 1: Det går inte att koppla en kunds verksamhet till flera länder.
-
Gap 2: Det går inte att ange flera adresser eller flexibelt definiera adresstyper (t.ex. fakturaadress, sommaradress).
För att åtgärda dessa brister ställer verksamheten därför icke-funktionella krav som handlar om vilken information som verksamheten vill kunna hantera och hur den ska vara strukturerad.
Exempel 1: Begränsningen i landkoppling
I Fortnox går det endast att koppla en kund till ett (och endast ett) land.
Detta är ett problem för organisationer som har kunder med verksamhet i flera länder. Ett bättre sätt är att använda en kopplingsbox mellan kund och land, t.ex. i form av entiteten Verksamhetsland. Då kan man enkelt beskriva relationen: "Kund A har verksamhet i Sverige och Tyskland", utan att duplicera kundposter.
Exempel 2: Begränsade adresstyper
Datamodellen tillåter endast en leveransadress och en besöksadress per kund.
Det gör det omöjligt att ange t.ex. faktureringsadress eller flera olika leveransadresser. Med ett mer generiskt informationsmönster skapar vi i stället en entitet Adress som kopplas till Kund via en koppling där varje adress får en Adresstyp. Det ger flexibilitet och framtidssäkerhet.
Slutlig mållägesmodell – informationsmodellen
Nedan visas den fullständiga informationsmodellen som realiserar verksamhetskraven:
Här har vi:
-
Frigjort kund från fast struktur
-
Använt kopplingsentiteter (t.ex. Verksamhetsland, Kundadress)
-
Möjliggjort flera förekomster där verksamheten behöver det
-
Tydliggjort att det är informationens betydelse för verksamheten som är styrande
Avslutning
Att ta fram en datamodell är ett bra sätt att förstå nuläget. Men det räcker inte om vi vill utveckla, förändra eller byta system. Då behöver vi en informationsmodell som speglar vad verksamheten behöver kunna uttrycka och hantera – oberoende av tekniska begränsningar.
I Prime Arch jobbar vi modellbaserat och verksamhetsnära – och genom att skilja på data och information skapar vi modeller som både stödjer kravställning, arkitektur och framtida systemlösningar.
Länkar
Metaobjekt
Vytyper
- Dataentitetsmodell (DEM)
- Informationsentitetsmodell (IEM)