Försvar för enkla verktyg – del 4: Modellbibliotek

I en större verksamhet kan vi ha hundratals modeller. Vi behöver hålla reda på, klassificera, lagra och hantera våra modelldokument. Vi behöver ett modellbibliotek. För detta finns det verktyg, så kallade ”Model Repositories”. Ofta är de integrerade i de specialiserade modelleringsverktygen. Men jag menar att man bygger ett bättre modellbibliotek själv med en enkel mappstruktur med vilken vanlig fillagring som helst, i molnet eller som katalogstruktur på en filserver.

Det som är viktigt är att bygga en bra struktur och arbetsprocess och att vårda och utveckla den. Det fixar inget verktyg i världen åt oss.

Mappstruktur för ett modellbibliotek

I bilden ovan visar jag ett exempel på en mappstruktur som jag har använt i många sammanhang. Varje modell har en övergripande mapp med samma namn som modellen. I exemplet ovan heter modellen ”Business Information Model”. Under denna finns tre mappar som återkommer för varje modell:

  • General Material
    En mapp för material som inte är en del av modellen men som är lämpliga att spara tillsammans med denna, till exempel olika typer av material som man utgått från när man modellerat.
  • Overview
    En mapp för en översikt över hela modellen. Där har man till exempel ett översiktsdiagram.
  • Subject Areas. En mapp med en undermapp för varje ämnesområde som modellen är indelad i. I exemplet ovan ser vi mapparna för ämnesområdena ”Customer” och ”Products”.

Modellen i detta exempel beskriver en hel verksamhet och är uppdelad i ett trettiototal ämnesområden. Varje ämnesområde har en egen mapp som samlar de modelldokument som beskriver ämnesområdet. Modelldokumenten för ett ämnesområde är alltid ett textdokument samt oftast en Visio-fil med detaljdiagrammet för området. Dokumenten är namngivna med modellens namn, ämnesområdets namn samt versionsdatum.

Sedan finns det för varje ämnesområde en arkivmapp, ”Archived”, för att arkivera äldre versioner av modelldokumenten.

På detta sätt har vi en lagringsstruktur som håller ordning på en modell som bärs av många olika dokument för sina olika delar, både text- och diagram.

En sån här struktur behövs inte i början av ett modelleringsarbete, när modellen inte riktigt har funnit sin form ännu. Då jobbar man kanske med ett enda stort diagram utan textbeskrivningar. Det är först när modellen och ämnesområdena någorlunda har funnit sin form som man behöver en fastare struktur.

För mindre omfattande modeller behöver man kanske inte mer än ett textdokument och ett diagram. Men i övrigt fungerar lagringsstrukturen för alla situationer. Jag har aldrig upplevt att den här strukturen inte räckt till.

Versionshantering

Vi behöver hantera versioner av dokument. Eftersom det vanligaste är att en ändring håller sig inom ett eller ett fåtal ämnesområden är det lämpligt att låta varje ämnesområde ha sin egen livscykel och historik.

Versionshanteringen går i ett sådant här modellbibliotek till på följande sätt:

  1. När du vill ändra något i ett ämnesområde öppnar du de aktuella versionerna av modelldokumenten för ämnesområdet. Ofta behöver du ändra i både textdokumentet och diagrammet samtidigt, så du behöver öppna båda.
  2. Du spar dessa direkt som nya versioner med samma namn men nytt versionsdatum.
  3. Gör de ändringar du vill göra. Efter varje enskild ändring loggar du den i ändringshistoriken för ämnesområdet, som finns först i textdokumentet. Ofta gör jag flera ändringar i rad. För att noggrant komma ihåg att logga varje ändring gör jag det direkt efter varje ändring. Det underlättas av att jag kan dela fönstret i Word så jag ser de två avsnitten samtidigt; ändringshistoriken i den övre delen och själva texten där jag ändrar i den nedre. Det är ofta lämpligt att inte bara skriva när och av vem ändringen gjordes, utan också varför.
  4. Spara och stäng det som nu har blivit de nya dokumentversionerna.
  5. Till sist flyttar du de tidigare dokumentversionerna till arkivkatalogen för ämnesområdet.

Om ändringen påverkar andra ämnesområden, eller själva översikten gör du på liknande sätt med dessa.

Publicering av den uppdaterade modellen, att göra den tillgänglig för en publik, är en egen historia som jag skriver om i nästa artikel i serien om enkla verktyg. Det är lämpligt att skilja själva publiceringen från den bakomliggande modellhanteringen. Publicering är ett eget beslut. Det är inte självklart att varje ändring ska publiceras direkt.

Fördelarna med enkla verktyg

Vad är då vitsen med detta minimalistiska verktyg gentemot speciella repository- och versionshanteringsverktyg. Jag ser följande fördelar:

1. Verktygsoberoende

Vi gör oss inte beroende av speciella verktyg och standarder, ofta proprietära, vilket gör att vi inte blir inlåsta och sårbara. Vi kan fritt välja lagringsform och också över tid byta lagringsform.

De specialiserade verktygen för dokumentlagring och versionshantering av modeller kommer och går. Våra modeller, speciellt informationsmodeller, men även förmågekartor är, om de är bra gjorda, stabila över tid och ger ett bestående värde för en verksamhet. Vi behöver därmed en större stabilitet och hållbarhet över tid för vårt bibliotek. Därför bör vi undvika inlåsning där vi kan så göra. Verktygsoberoendet ger oss den öppenhet, flyttbarhet och flexibilitet vi behöver för att arbeta på ett hållbart sätt med ett långsiktigt värde för vår verksamhet.

2. Makt över våra verktyg

Det här är kanske mer en mental och sociologisk aspekt men nog så viktig. Ett specialiserat verktyg är mycket mindre fritt än ett enklare och mer generellt verktyg. När vi arbeta med ett specialiserat verktyg betingas vi att göra på det sätt som verktyget tillåter eller styr oss att göra. Vi tenderar att sluta tänka själva. Verktyget befrämjar vissa strukturer och arbetssätt och det blir lätt så att det är just på det sättet vi gör, och inget annat. Vi tänker då inte aktivt ut vad som egentligen fungerar bäst för det vi behöver göra.

Vi bör alltid välja och använda verktyg som stödjer det vi behöver och vill göra, aldrig tvärtom.
För då blir vi mer som operatörer av ett visst verktyg än de utforskare och kaospiloter vi ska vara.

Det är viktigt att vi – det vill säga både vi som profession, vi som team, och vi som individer – självständigt och utifrån vår profession, erfarenheter och sammanhang utforskar, lär oss och utvecklar arbetssätt och strukturer som stödjer dessa arbetssätt. Det är så utveckling inom en profession går till.

Du kanske inte tror att det händer just dig, att det inte är någon risk att du blir styrd av verktygen du använder? Men vi ser det hända hela tiden i de verksamheter vi jobbar i. Våra verktyg styr oss mycket mer än vi är benägna att se. Enkla verktyg är friare och blockerar oss inte på samma sätt. 

3. Versionshistorik integrerad i modellen

Ett ämnesområde i en modell har en historia. Det är inte bara ett färdigt resultat. Historien bör vara en integrerad del av modellen om den verkligen ska kunna vara en plattform för gemensamt utforskande av en verksamhet.

En modell bör på sätt och vis vara lika mycket en avbildning av en pågående process som ett färdigt resultat. Modellen ska visa mer än bara ett snapshot av det färdiga resultatet. Jag vill också kunna se hur man kom dit och varför. Inte minst vill jag se vilka vägar man prövat och förkastat. Det rymmer mycket kunskap som har fångats och som vi bör ta vara på. Det är inte ovanligt att man behöver ompröva val som gjorts längre tillbaka.

Vi behöver därmed beskriva vilka ändringar som gjorts, när, av vem och ofta även varför. Detta är en viktig dokumentation av ämnesområdet och bör därför vara en integrerad del av modelldokumentet och bäras med i dokumentet var det än tar vägen. Det blir inte fallet med ett särskilt versionshanteringssystem. Därför behövs ändringshistoriken listas i själva textdokumentet.

4. Rätt detaljeringsgrad för versionshanteringen
Ett mer automatiserat versionshanteringssystem kan inte skilja på ändring och ändring. Det skapar en ny version så snart någon ändring är gjord oberoende av om det är en ändring jag behöver hålla reda på eller inte. Den finkornigheten är lämplig för till exempel programkod eller avtalstexter där varje ändring, om det så är ett flyttat komma eller stavningsrättning kan ha betydelse.

Men inte när det gäller dokument av den typen vi pratar om här. Enstaka rättningar av stavning eller formuleringar bör inte rendera i en ny version. I så fall drunknar vi i versioner. Vi behöver bara hålla reda på väsentliga ändringar. På så sätt får vi en historik som avspeglar ämnesområdets historik på en mer lämplig nivå.

Jag är säker på att det här är ett område med många åsikter. Hur ordnar ni ert modellbibliotek och er ändringshantering? Kanske du också har tips att förmedla?

/Peter Tallungs, IRM

Nästa del i miniserien om informationsmodellerarens verktyg publicerar vi torsdag 20 maj. Då handlar det om samarbetsverktyg.
Vill du prenumerera på artikelserien Informationsarkitektens tankar? Registrera din mailadress här.


Försvar för enkla verktyg – del 2: Ritverktyg

Jag ritar modeller i Microsoft Visio och kombinerar med strukturerad text i Microsoft Word. I denna artikel vill jag motivera varför jag föredrar ett enkelt och flexibelt ritverktyg som Visio.

Det finns ett antal specialiserade modelleringsverktyg. De är tänkta att integrera grafiska och verbala beskrivningar på ett strukturerat sätt. En annan väg att gå är att använda sig av ett rent ritverktyg som till exempel Microsoft Visio och knyta ihop helheten med enklare och mer flexibla medel.

Visio ger de uttrycksmöjligheter vi behöver

För att göra kommunikativa modeller som blir effektiva tanke-, kommunikations- och samarbetsverktyg behöver vi utveckla den grafiska gestaltningen. Det är viktigt för att vi ska bli riktigt bra modellerare. Det är också viktigt för oss informationsarkitekter som profession för att vi ska utveckla vårt hantverk, vilket jag anser att vi behöver göra. Här följer några av de uttrycksmedel vi behöver använda när vi ritar modeller.

  • Struktur på ytan i diagram. Gråa bakgrundsytor för ämnesområden ger struktur.
  • Layout;hur vi placerar och grupperar ämnesområden, entiteter och relationer.Vi kan framhävavilka företeelser som är delar av andra företeelser. Vad hör ihop? Vilka saker är parallella med varandra i förhållande till något tredje? Vad är underställt något annat? Vad bildar en linje? Vilka mönster behöver jag framhäva i strukturen?
  • Rubriker på hela diagrammet, ämnesområden samt grupper av ämnesområden och grupper av entiteter. Vi behöver alltså rubriker i flera nivåer.
  • Storlek och form på de grafiska elementen de att framhäva vissa företeelser.
  • Ordning; vi bör se till att de olika grafiska elementen linjerar prydligt. Om grafiska former inte linjerar söker hjärnan hitta mönster som inte finns. Modellen upplevs som rörig vilket bromsar vår kognition.
  • Speciella färger för att framhäva, skilja, förklara.
  • Gråskalor för att tona ner sakerså att de hamnar i bakgrunden av vår perception. Det gäller både entiteter, namn och andra texter samt linjer, rubriker och ämnesområden. På så sätt framhäver vi det vi vill framhäva och tonar ner det som vi vill tona ner.
  • Linjetyper; heldragna, streckade eller punktade linjer för saker som vi vill skilja på.
  • Linjetjocklekar lyfter på likande sätt, som med gråskalor, fram vissa linjer och tonar ner andra
  • Typsnitt, textstorlekar och typografiska stilar som fetstil och kursivstil för att skilja på olika slags namn och texter
  • Integrerad text; förklarande text i och intill diagram så mycket som det går.

Det ovanstående är bara en enkel uppräkning, men jag planerar att ge råd om detta i artiklar framöver. Syftet är att vi ska kunna gestalta våra modeller så att de rymmer mer av den kunskap vi vill analysera, forma, dokumentera och förmedla, samtidigt som modellerna blir mer lättillgängliga.

Detta bygger på att vi kan styra fritt över det grafiska uttrycket, att vi har fri tillgången till alla de uttrycksmedel vi behöver. Vilket kräver ritverktyg som inte begränsar uttrycksmedlen.

En informationsmodell är inte ett diagram

Om vi ska få till den uttryckskraft vi behöver i våra modeller måste vi lämna föreställningen att en informationsmodell bara är ett diagram. En modell behöver oftast gestaltas av flera diagram och av diagram av olika typer samt också av strukturerad text. Det som gör det till en och samma modell är att den har en gemensam kontext, det vill säga beskriver samma sak i samma sammanhang, samt att den är konsistent, det vill säga inte självmotsägande. 

Den vanliga invändningen mot enkla ritverktyg

Den vanliga invändningen mot att använda ett enkelt ritverktyg för att modellera uttrycks av följande citat som jag ofta hört:

”Jag förstår att vi behöver göra kommunikativa presentationer av våra modeller för att nå ut till de som behöver ta del av dem. De modeller vårt modelleringsverktyg låter oss göra är inte lämpliga att presentera för vem som helst. Men vi kan ta fram presentationsmaterial separat från vårt modelleringsverktyg, till exempel i Powerpoint eller liknande presentationsverktyg”.

Min respons blir då följande: Om du tillstår att modelleringsverktyget inte ger de möjligheter du behöver för att göra klara, tydliga och begripliga modeller så kommer den bristen att slå brutalt och obarmhärtigt även mot dig och dina kolleger som arbetar i verktyget. Vi behöver kunna gestalta modeller så tydligt som möjligt, inte bara i efterhand för en publik utan också för oss själva när vi modellerar. Modellering handlar inte om att rita det vi redan begriper utan om att rita för att undersöka och förstå, hitta mönster och förmedla dessa. Kan du inte göra det i ditt verktyg så har du fel verktyg.

En känslig fråga

Jag förstår att det här är ett minerat område. Det kan kännas tryggt att luta sig mot ett specialiserat modelleringsverktyg. Det är svårt att stå emot de krafter som har en övertro på en standardisering och egentligen inte har förstått vad modellering handlar om, att med alla medel skapa en gemensam förståelse. Och det är svårt att bryta en vana.

Det kan kännas bekvämt att bara se sig som en operatör av ett verktyg i stället för att tänka fritt och göra det bästa som bara går. Då känns det inte riktigt som att man behöver ta det fulla ansvaret för resultatet. Man bara gör som metoden föreskriver och som alla andra gör. Det är en förödande fälla. Vi är då inga ansvarsfulla hantverkare. Då ger vi inte det vi kan ge, och vi får inte någon metodutveckling på vårt område. Då ger vi upp ambitionen att ge allt det vi skulle kunna ge, som individer, som team, som yrkesgrupp och som kunskapsområde.

Vad säger du? Vilket verktyg använder du? Hur väl lämpar sig verktyget till att uttrycka det du behöver uttrycka?
Kommentera gärna! Jag ser fram mot en dialog.   

/Peter Tallungs, IRM

Nästa del i miniserien om informationsmodellerarens verktyg publicerar vi torsdag 29 april. Då handlar det om verktyg för skriva strukturerad text.  Vill du prenumerera på artikelserien Informationsarkitektens tankar? Registrera din mailadress här.

Försvar för enkla verktyg – del 1

En serie i serien. Med denna artikel inviger vi en artikelserie på fem artiklar om informationsmodelleringsverktyg i artikelserien Informationsarkitektens tankar.

Informationsmodellering är ett hantverk. För en hantverkare är verktygen viktiga. Låt oss se över vår verktygslåda. I den här artikeln vill jag försvara de enkla modelleringsverktygen.

Det finns ett antal specialiserade modelleringsverktyg, för både informationsmodeller och andra modeller. De är egentligen hela verktygsplattformar tänkta att stödja modelleringsarbetet genom att integrera grafiska och verbala beskrivningar på ett strukturerat sätt. De ger ofta även stöd för att bygga upp ett förråd för en organisations samtliga modeller, ett repository.

En annan väg att gå är att använda sig av en kombination av vanliga generella verktyg, såsom basala rit-, -skriv, dokumenthanterings- och samarbetsverktyg där man själv får bygga upp de strukturer man behöver. Det är en ”best of breed”- strategi, de vill säga att man strävar efter att använda det bästa verktyget man kan finna för varje enskild arbetsuppgift i modelleringsarbetet.

Jag och mina kollegor har hjälpt många team och organisationer att bygga upp verksamhets- och informationsarkitektur samt Data Management. Vi har därmed erfarenheter från många olika sammanhang och förutsättningar.

Mot denna bakgrund har jag kommit till att förorda det senare alternativet då en kombination av enkla verktyg inte bara är gångbart utan det enda verkligt framgångsrika jag känner till. Enkla verktyg är inte enkla i den meningen att de är simpla. Tvärtom! De ger den flexibilitet och uttrycksfullhet vi behöver för att göra ett bra jobb som informationsarkitekter.

Jag har upplevt att denna ståndpunkt är kontroversiell bland enterprise- och it-arkitekter. Jag vill därför i denna artikel, och fyra efterföljande, tydligt och noggrant argumentera för den vägen. Kanske kan jag få någon att bli mer öppen för det alternativet. Eller också blir jag avfärdad som Luddit. (Ludditer var de engelska teknikfientliga väveriarbetarna som bjöd våldsamt motstånd till de nya effektiva vävstolarna i början av 1800-talet.)

Den enkla verktygslådan

Här är listan på de typiska verktyg jag rekommenderar. Det finns förstås likvärdiga alternativ, men då av samma enkla slag.

  • Microsoft Visio: För att rita
  • Microsoft Word: För textdokument och för att integrera text och bild
  • Katalogstruktur på server, eller liknande: Som repository för modeller
  • Ändringshistorik i dokument samt rutin för att spara versioner i katalogstrukturen: För versionshantering
  • Wiki eller det samarbetsverktyg som används i den organisation jag jobbar: För att publicera modeller samt kommunicera ut vad som händer
  • Storformatskrivare: För utskrift av modeller
  • Whiteboard och digitala samarbetsverktyg: För modelleringssessioner.

Jag kommer i följande fyra artiklar motivera och beskriva hur man kan använda respektive verktyg i verktygslådan. I denna inledande artikel ger jag generella motiveringar för kombinationen av enkla verktyg i motsats till de specialiserade.

Motivering för enkla verktyg

Här följer ett antal motiveringar till att välja enkla verktyg.

Motivering 1: Enkla verktyg ger frihetsgrader och möjliggör den rikare och mer kraftfulla gestaltning som vi behöver

Våra modeller kan bli mycket bättre gestaltade än vad som är vanligt idag. Det gäller alla slags modeller. Om vi ska lyckas få en organisation att samlas kring modellerna och låta dem representera en gemensam förståelse måste de bli mycket mer överskådliga, tydliga och tillgängliga. Samtidigt behöver de ges ett rikare uttryck genom att kombinera olika slags kunskap. Det handlar om hur vi ritar. Det vill säga struktur, disposition, färger, gråskalor, linjetyper, typsnitt, symboler, samt hur vi integrerar text och bild. Vi behöver kombinera och integrera olika slags diagram med varandra samt med textuella beskrivningar.

Det sätt vi i branschen idag arbetar med våra modeller har en stor potential till förbättring. Det handlar också om hur vi hanterar våra modeller, och hur vi tillgängliggör dem. För att kunna göra allt detta på ett bra sätt behöver vi verktyg som ger frihetsgrader, som inte begränsar oss, låser in oss och hindrar oss i det vi behöver göra.

Motivering 2: Enkla verktyg främjar experimenterande och därmed utveckling av alla våra områden där modellering är en viktig del.

Som yrkesgrupp behöver vi utveckla informationsmodelleringsområdet. För det behöver vi verktyg som ger oss den friheten.

Jag vill jämföra med vad som hände inom systemutveckling kring millennieskiftet. Vid slutet av 90-talet var tron på specialiserade modelleringsverktyg stor. Rational Unified Process var den förhärskande utvecklingsmetoden och Rational Rose var det modelleringsverktyg som skulle stödja hela utvecklingsprocessen. De organisationer som var ambitiösa och anammade detta arbetssätt fick det svårt. Metoden framställdes och tolkades på ett sätt som gjorde den överlastad och rigid. Själva metoden och verktyget styrde tänkandet och arbetssättet i stället för att vara en verktygslåda. Det blev att man fokuserade på att betjäna verktyget och utvecklingsmetoden i stället för att koncentrera sig på vad användare och verksamhet behövde. Man blev på så sätt en operatör av ett verktyg utan egen agens och ansvar.  

I det sena 90-talet växte missnöjet hos utvecklare och utifrån några individer växte det fram en motrörelse. Några utvecklare, på lite olika ställen, började tänka på vad de själva verkligen behövde och vad som fungerade. De tog fram mer basala och hantverksmässiga arbetssätt som parprogrammering, test-first design, scrum-tavlor med mera. Det nya tänkesättet grodde och spred sig i utvecklarsamhället. Ett par år efter millenniumskiftet fick det etiketten agila rörelsen. Utvecklare byggde själva enkla verktyg för att stödja sitt arbete. Mest kända blev testverktyg för att automatisera tester samt så kallade refactoring-verktyg för att snabbt och enkelt göra ändringar i kod.

Jag menar att vi behöver en liknande rörelse bland oss informationsarkitekter. Det vi behöver är en ny vår för arkitektarbetet som ett hantverk, precis det som agila rörelsen var för systemutvecklare för två årtionden sedan. Vad gäller arbetssätt så har vi redan lärt av agila rörelsen och alla förstår nog nu att vi behöver smidiga och mer kommunikativa arbetssätt. Men då det gäller verktyg återstår att överge de stora tunga modelleringsverktygen och i likhet med systemutvecklarna gå till oss själva, och ställa oss frågan vad vi egentligen behöver. Tillbaka till hantverket, och vad som verkligen stödjer det.

Jag har sett organisationer där arkitekterna varit som slavar under avancerade verktyg. De har varit upptagna med att mata verktygsmonstret. Resten av organisationen har inte haft nytta av arkitekterna, som befunnit sig i en parallell värld utan kontakt med verksamhetsutvecklingen.

Och denna nya vår jag hoppas på har faktiskt redan grytt på en del ställen. Jag har sett organisationer där verksamhets- och informationsarkitekter till sist givit upp sina tunga arbetssätt och verktyg. De har lämnat sina slutna rum, klivit ner från elfenbenstornet och gått ut där verksamhetsutvecklingen sker, bland utvecklarna och i verksamheten. De har sett hur de kan stödja utvecklingsarbetet. De har då, för första gången, känt sig välkomnade av utvecklare och domänexperter. De modellerar fortfarande, men nu med enkla tekniker som tjänat syftet på ett helt annat sätt.

I de fall de trots allt behövt lite mer verktygsstöd har de, precis som utvecklarna, själva experimenterar och byggt de verktyg de behövt. Jag ska försöka ge exempel på sådana verktyg framöver.

Dessa egenbyggda verktyg kan sedan i likhet med vad som hänt inom utvecklarvärlden så småningom kommersialiseras och bli standard. Det är egentligen alltid så det sker då ett yrkesområde utvecklas på riktigt. Alltid utifrån professionen och hantverket. Aldrig från verktygsleverantörerna.

Motivering 3: Enkla verktyg sätter fokus på uppgiften

Att ta ansvar för något stort, till exempel en informationsarkitektur, kan vara skrämmande. Det är många saker man måste ta ställning till och kanske behöva försvara. Då är det lockande att gömma sig bakom ett ramverk, en industrimodell, en metod eller ett verktyg som synes ge objektiva svar. Det är att fly undan det ansvar vi har. Då blir jag en operatör av ett verktyg i stället för informations- eller verksamhetsarkitekt.

Vi behöver i stället fokusera på vad som behöver lösas i verksamheten och använda de verktyg som gör jobbet. Inte först välja verktyg för att sedan bara mata detta.

Motivering 4: Enkla verktyg minskar beroendet

Om man i en organisation har tagit in ett avancerat modelleringsverktyg så medföljer det ett antal metamodeller, vilka styr hur de modeller man tar fram måste se ut och relatera till varandra. Om man senare vill ändra detta kan det bli mycket dyrt och svårt. Verktygen är i själva verket ofta en hel plattform av verktyg som hänger samman. Man blir på flera sätt, på gott och ont, beroende av leverantören och dennes utveckling av plattformen.  

Vanliga argument för specialiserade verktyg

När man argumenterar för en enkel verktygslåda får man ofta mothugg. Här följer ett antal argument som man stöter på och hur jag vill bemöta dem. 

Argument 1: Specialiserade verktyg ger konsistens

Specialiserade verktyg har en metamodell som styr hur vi kan modellera. Det gör att vi alla ritar och beskriver på samma sätt vilket är viktigt. Om vi inte gör på samma sätt blir resultatet spretigt, återanvändningen svår och kvaliteten lidande. Det följer vanligen med metamodeller vi kan välja mellan och i de mer avancerade verktygen kan vi själva, eller med hjälp från konsulter, ta fram en egen metamodell som passar oss.

Mitt motargument: Sättet vi modellerar behöver utvecklas för att på allvar bli relevant för våra verksamheter. Vi behöver alltså se det som ett hantverk i utveckling. Då är experimenterandet viktigt, att vi söker oss fram och lär oss. Vi ska då inte standardisera arbetssätt, notationer, metamodeller med mera. Det skulle frysa all utveckling och fortsätta hålla oss fast på det stadium vi är idag. Däremot ska vi dela erfarenheter och inspireras av varandra. Men det är något helt annat.

Det finns alltid, inom alla områden en motsats mellan utveckling och standardisering. Vi ska standardisera det vi tycker att vi nått en mognad inom. Men bara där. Där vi behöver utveckling ska vi tvärtom befrämja att vi gör olika, inte bekämpa. Vi behöver tåla och bejaka spretigheten. Utveckling innebär experimenterande.

När vi har lärt oss vad som verkligen fungerar kommer saker och ting att mogna och vi kommer naturligt att gravitera mot något av en de facto-standard. Men att gå utvecklingen i förväg och bestämma en standard innan vi har nått den mognaden är fel. Det är att frysa all utveckling. Därför behöver vi frihetsgrader. Det betyder inte kaos, utan bara att vi i får vara beredda på varianter och förbättringar i små steg. Och även något vilt försök ibland! Det är så utveckling går till. Överallt och alltid.

Argument 2: Specialiserade verktyg ger struktur och ordning

Specialiserade verktyg styr hur och var vi spar, versionshanterar och publicerar modeller. De ger oss ett strukturerat repository. Det gör att resultatet inte bara blir högar av osorterade modeller på olika ställen med oklara syften och sammanhang.

Mitt motargument: Vi behöver alltid ett strukturerat repository. Vi vill inte ha oordning. Men det är mycket lätt att ordna det på ett enkelt sätt och på vilken lagringsyta som helst där man kan ha filkataloger av något slag, och något slag av enkel åtkomstkontroll och versionshantering.

Det är fel att tro att ett specialiserat repository krävs för ordning och reda. Ett specialiserat repository ger heller inte ordning och reda av sig självt. Vi behöver även då tänka igenom och komma överens om saker och ting. Den största faran med verktyg som styr oss är kanske just den tankefällan, att vi tror att vi inte behöver tänka själva. Vi har sett modellbibliotek som varit total kaos i verktygsbaserade repositories och jag tror faktiskt att vi sett fler välordnade bibliotek bland de som byggs mera manuellt. Jag är övertygad om att när jag behöver bygga något själv leds jag in på att tänka igenom och ta ansvar för vad som behövs.   

Argument 3: Specialiserade verktyg ökar produktiviteten

Verktyget hjälper mig. Jag kan återanvända delar av andra modeller när jag gör en ny, eller referera till befintliga. När jag vill göra en ändring av något som manifesterar sig på många ställen behöver jag bara ändra på ett ställe. När jag vill publicera en modell gör jag det automatiskt. Versionshanteringen är inbyggd vilket gör att den går lätt och smidigt. Jag behöver inte fundera så mycket på hur jag ska göra rent praktiskt med dessa hushållsbestyr så jag kan koncentrera mig på själva modellerandet.

Mitt motargument: Jo, verktyget hjälper dig förvisso med några enkla uppgifter. Men inte alls så mycket som man kan tro, och inte alls med det som är det väsentliga; hur du gör riktigt bra modeller och hur du når ut med dem. Tvärt om hindrar det dig. Så triviala uppgifter går kanske något snabbare – men till ett mycket högt pris.

Om vi definierar produktivitet som hur mycket nytta vi gör, hur bra vi når ut och hur vi hjälper människor och team att hantera sin komplexitet så vinner de enkla verktygen överlägset. 

Det finns ett talesätt som säger ”A fool with a tool is still a fool”. Det brukar motvilligt citeras av verktygssäljare när man pekar på misslyckade införanden av deras produkter. De vill betona att deras fina verktyg trots allt inte garanterar ett bra resultat, utan att det kan finnas dumma människor som inte begriper hur de ska användas. Det finns ett tillägg till talesättet som säger ”A fool with a tool makes a faster fool”. Det vill säga att om ett verktyg ökar produktiviteten utan att verktygsanvändaren gör ett bra jobb hamnar man snabbt i ett dåligt läge.

Argument 4: Specialiserade verktyg stödjer samarbete

Verktyget stödjer att flera kan jobba samtidigt med samma modell, kanske även från olika geografiska platser.

Mitt motargument: Jo, verktyget har funktioner för detta. Men det fungerar bättre med de generella samarbetsverktygen vi använder i övrigt i våra distansarbeten.

Konflikten mellan viss automatisk hantering och stöd för rik gestaltning

Jag menar att om vi använder de specialiserade verktyg som finns så får vi visserligen stöd för vissa enkla uppgifter.

Men vi väljer samtidigt bort möjligheten till att göra riktigt bra modeller.

Vi kan inte få både och. Åtminstone inte idag. Och inte förrän vi själva inom professionen bidrar till den utveckling som kanske kan ge oss sådana verktyg.

Och vi tenderar till att både övervärdera nyttan av den lilla automatisering vi kan få samt att undervärdera vikten av att göra riktigt bra modeller som når fram.

I själva verket är det så krasst att om vi inte når fram har vi inget som motiverar vår existens.

De ivrigaste proponenter för specialiserade verktyg jag mött har nästan i samma mening beklagat att de inte har gehör hos it- och verksamhetspersoner för vad de gör, utan blir ständigt kringrända av utvecklingsprojekten. Det kanske skvallrar om något?

Fortsättning följer

Jag är medveten om att den här posten väcker många frågor. ”Peter pratar mycket om att vi ska göra bättre modeller men inte hur det går till.” Det är ett stort område, men jag vill steg för steg i den här artikelserien ge mitt bidrag till det.

Vad är din erfarenhet? Vilka verktyg använder du? Handen på hjärtat, vad fungerar på riktigt?

/Peter Tallungs, IRM

Nästa del i miniserien om informationsmodellerarens verktyg publicerar vi torsdag 22 april. Vill du prenumerera på artikelserien Informationsarkitektens tankar? Registrera din mailadress här.

Data management – se hela kedjan

För att en organisation ska få nytta av sina data behöver en hel kedja av förutsättningar vara uppfyllda. Vi behöver se och förstå hela kedjan för att hitta och förstärka svaga länkar.

En organisations data är en tillgång. Om vi kan hantera den tillgången på ett bra sätt så ger den mångfalt tillbaka. Data kan inte bara stödja verksamheten operativt utan också användas analytiskt, det vill säga ge insikter och kunskap och därmed ligga till grund för beslut och handling. Men för att en datatillgång verkligen ska ge nytta måste den tas om hand, den måste förvaltas aktivt. Det är det vi kallar Data Management.

En modell i form av en kedja

Data Management är ett område med stor spännvidd och som inkluderar alla de åtgärder som behövs för att ta hand om en dataresurs för att maximera dess värde.
För att få överblick över området kan vi använda oss av en modell över en tänkt kedja av förutsättningar, från det att data registreras någonstans tills det att man får nytta av dessa data i organisationen. Modellen är en uppräkning av förutsättningar som tillsammans bildar en kedja, där varje förutsättning behöver uppfyllas. Jag har ofta visat denna modell i olika sammanhang för att visa vad Data Management kan omfatta. Modellen kan dock kännas en aning konstlad. Man har försökt pressa in lite för mycket, speciellt i slutet av kedjan. Som jag skrev i artikeln ”Data eller information” skapas sällan kunskap direkt ur data på ett linjärt sätt vilket modellen ger sken av. Kunskapsprocessen i en organisation är en växelverkan mellan flera olika handlingar och källor, där data visserligen är en viktig källa men ändå endast en av de inblandade faktorerna. Så vi ska ta modellen med en nypa salt. Men jag tycker ändå att modellen, trots sina begränsningar, har sin poäng i att den positionerar Data Management i förhållande till angränsande och överlappande discipliner. Modellen presenteras i det följande.

Kedjan av förutsättningar

Nyttan av data uppstår bara om en serie av förutsättningar är uppfyllda. Dessa förutsättningar bildar länkar i en kedja. Varje förutsättning blir meningsfull endast om alla föregående förutsättningar i kedjan är uppfyllda. Som bekant är det den svagaste länken i en kedja som avgör om den håller. Det spelar då ingen roll hur starka de andra länkarna är. Svagheten i en länk vägs inte upp av styrkan i de andra.

Kedjan av förutsättningar kan listas som nedan. För varje förutsättning ger vi exempel på faktorer som kan bidra till att den förutsättningen kan uppfyllas.

  1. Att rätt data finns
    Att det någonstans (innanför eller utanför organisationen) finns rätt data, det vill säga som handlar om rätt saker och är anpassade till situationen.
    Bidragande faktorer: Dataplanering, dataanalys, processutveckling, utveckling av applikationer för registrering, Business Intelligence, givare för insamling av data, givare för maskindata med flera.
  2. Att man känner till att dessa data finns och var de finns
    Det händer ofta att data finns men att de som behöver den inte vet om det. Då stoppar det redan här.
    Bidragande faktorer: Aktivt sökande av datakällor och datatjänster, datakataloger, Data Dictionary, utbildning, kommunikation, informationsmodeller/- kartor med flera.
  3. Att man kan nå och få fram dessa data
    Kan vara via maskinella eller manuella tekniker.
    Bidragande faktorer: Applikationer, intranät, internet, sökmotorer, SQL, Data Warehouse, API-er, datatjänster, presentationstekniker med flera.
  4. Att man kan förstå dessa data
    Det vill säga att man kan tolka dess innebörd och syfte med stöd av sina egna referensramar.
    Bidragande faktorer: Utbildning, erfarenhet, definitionsarbete, namngivning, modeller/kartor, metadata, dokumentation, informationsanalys med flera.
  5. Att man kan lita på informationen
    Att man kan lita på att den information man tagit till sig stämmer med verkliga förhållanden.
    Bidragande faktorer: Metadata, källhänvisningar, goda erfarenheter, datakvalitetsarbete, redundans med flera.
  6. Att man kan vidarebearbeta data
    Att man kan sortera, filtrera, kombinera, summera och sammanställa data och därmed bilda sig ytterligare sammanfattad/komplex information som blir mer användbar för att dra kunskaper ur.
    Bidragande faktorer: Data-analysverktyg och metoder, Data Science, rapportverktyg, aktivt arbete med framtagning och förvaltning av rapporter med flera.
  7. Att man kan dra korrekta slutsatser från informationen
    Från informationen man fått fram behöver man sedan kunna dra slutsatser som är relevanta i sammanhanget.
    Bidragande faktorer: Domänkunskap, erfarenhet, överblick, logisk förmåga, abstraktionsförmåga, konkretionsförmåga med flera.
  8. Att man kan besluta sig för ett handlingsalternativ
    Detta baserat på slutsatserna, intuition, beslutsstil och personliga faktorer.
    Bidragande faktorer: Beslutstil, beslutsförmåga, belöningssystem, rekrytering, organisationskultur, personlig utveckling med flera.
  9. Att man kan gå från beslut till handling
    Det vill säga verkställa och agera.
    Bidragande faktorer: Genomförandekraft, motivation, handlingsberedskap, inräkning och kultur för att agera med flera.

Se hela kedjan

Varje gång en nytta av dataförsörjningen har uppstått har varje länk i kedjan hållit. Om en enda länk i kedjan brister blir värdet noll. Det vill säga ingen nytta, endast kostnader. Helheten är därmed viktig. Inom Data Management behöver vi se hela kedjan, hitta de svaga länkarna och stärka dessa. Vi behöver därmed satsa brett på informationsteknik och verksamhet samt människa och teknik i samverkan.

Var kommer Data Management in?

Vi kan succesivt dela in kedjan i större sträckningar, vilka var och en kan ges en rubrik. Låt oss se var vi som jobbar med Data Management kommer in.

  • Länk 1-3: Utdata till användaren
    Det är det som it- funktionen i organisationer vanligen avgränsar sin uppgift till. Man ser vanligen inte det som sin uppgift att tala om vad data betyder eller vilken kvalitet de har.
  • Länk 1-5: Informationsförsörjning
    Det bör vara vår uppgift inom Data Management att lyfta organisation och arbetssätt till att omfatta hela informationsförsörjningen. Vi informationsarkitekter kan kanske göra störst nytta då det gäller att stärka länk fyra och fem så att hela informationsförsörjningen håller.
  • Länk 1-7: Informationsförsörjning och användning
    Det bör även ingå i informationsarkitektens uppgift att bidra till att analytiska användare har verktyg för att bearbeta de data de har tillgång till. Vi behöver av många skäl samarbeta nära med den typen av användare. Inte minst för att det ger insikter i hur vi kan bidra med att få mer data och i rätt form.
  • Länk 1-9: Hela kedjan till och med att nytta uppstår
    Hur användarna av data drar slutsatser, beslutar och agerar, på basis av data, kan vi inte direkt påverka. Dock behöver vi observera och arbeta tätt ihop med de som gör det. För det ger insikter om vad vi som arbetar med informationsarkitektur eller Data Management behöver bidra med.

Hur långt sträcker sig ditt intresse?

Hur långt sträcker sig ditt intresse och engagemang? Hur ser du på din eller ditt teams roll? Vilken länk är svagast i din organisation? Kan du göra något för att stärka den?
Dina erfarenheter och tankar är välkomna.

/Peter Tallungs, IRM 

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 15 april. Då inleder vi en liten serie i serien. Den kommer handla om hantverket informationsmodellering.
Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

”Data” eller ”information”

Vad är skillnaden? Jag tvekar ofta om jag ska benämna något som ”data” eller ”information”. Är det data eller är det information? Är detta som jag tar fram en datamodell eller en informationsmodell?

I Sverige kallas en konceptuell modell ofta för informationsmodell och en logisk eller fysisk modell ofta för datamodell. Men i USA talar man vanligen bara om ”Data Models” oavsett om de är konceptuella, logiska eller fysiska. Hur kan vi se på det?

Den påstådda teoretiska skillnaden

Alla som definierat begreppen data och information verkar vara överens om att data är råa uppgifter utan sammanhang och tolkning. Tänk att du tittar på en massa siffror men inte vet, eller bryr dig om, vad de står för. Vidare är man överens om att information är data som har ett sammanhang och tolkning.

Hur uppkom distinktionen?

Det kan vara intressant att veta hur distinktionen mellan data och information kom till. Inom system- och informationsvetenskap skedde detta i skiftet mellan 70- och 80-tal. Det var när man strävade efter att få sina områden att bli respekterade som strategiska management-discipliner. Man ville få företagsledningar att se data som en strategisk tillgång och lanserade därför en tänkt process med en transformering och filtrering från data via information till kunskap och ibland till och med ända till visdom.

Bild från gapingvoid.com

Synsättet har genom åren kritiserats som en alldeles för mekanisk och förenklad syn på kunskapsprocessen i en organisation. Visst spelar data och information en roll i kunskapsskapandet men sammanhangen är mycket mer dubbelriktade och sammansatta.

Se till exempel David Weinbergers artikel ”The Problem with the Data-Information-Knowledge-Wisdom hierarchy” och Patrick Lambs bloggartikel  “From Data, with Love”.

Det var i sammanhanget som är beskrivet ovan som en del började kalla datamodeller för informationsmodeller och Data Management för Information Management. Förmodligen för att få företagsledningars uppmärksamhet. Av någon anledning slog det språkbruket igenom i Sverige men inte i USA.

Som så ofta handlade det alltså mer om politik och revirpinkande än om någon verklig insikt.

Idag, ett halvsekel senare, kan man tro att ordens statusordning har kastats om. ”Data” har fått en ny laddning. Trenduttryck som ”Data is the new oil”, ”Data driven enterprise”, ”Data Science” och “Chief Data Officer” vittnar om att data inte längre ses som någon tråkig mekanisk infrastruktur.

Detta var en liten historisk bakgrund. Låt oss återgå till distinktionen mellan data och information. 

Vad är sammanhang och tolkning?

Om vi för diskussionens skull godtar att data blir till information vid den tidpunkt då den kläs på med ett sammanhang och en tolkning. När inträffar då denna punkt i processen? Problemet kommer då vi ska bestämma vad vi egentligen menar med sammanhang och tolkning. Vad är tolkning och sammanhang? När sker tolkningen av data? När sätts data i sitt sammanhang? Dessa frågor kan först verka ha enkla svar men blir vid en närmare betraktelse meningslösa.

Redan när data samlas in görs det i ett sammanhang som är känt och ges direkt en tolkning genom hur den hanteras.

Låt mig ta ett exempel. En givare av något slag ger ett mått på något, säg värdet ”23”. Någonstans där värdet från givaren registreras bör det nödvändigtvis finnas inbyggd kunskap om sammanhang och mening med mätningen. Man vet kanske att det är en temperaturgivare och att det är grader Celsius. Man vet var givaren sitter och därmed inte bara att det är lufttemperatur utan också på vilket ställe lufttemperaturen är registrerad. Utöver detta vet man också redan vid registreringen vilken tidpunkt värdet registrerades. Allt detta är mening och sammanhang för datapunkten och registreras alltså med en gång, bara genom vad det är för slags sensor och var den sitter. Om man ska vara strikt kan man hävda att det aldrig är frågan om rådata i egentlig mening. Om vi kan vara överens om detta så är det alltid fråga om information, ända från då den registreras.

Så, en sådan distinktion vi tidigare gjorde blir meningslös. I så fall, med det resonemanget, finns aldrig data, bara information. 

Vad det beträffar de modeller vi gör så blir det väl då alltid frågan om informationsmodeller. Ty där bryr vi oss alltid om meningen med de data vi hanterar.

Låt oss pröva ett annat synsätt. Kanske vi kan se det som att data blir till information först när någon människa har tagit hand om de insamlade data, gett det en ännu mer utarbetad tolkning. Om vi tänker oss att man samlat in lufttemperaturer under en tid och jämför med andra år och därmed kan säga att det varit en ovanligt varm marsmånad i år. Är det först då det blir information? I så fall hanterar vi vanligen inte alls information i våra informationsmodeller. Informationen uppstår först i de analyser och slutsatser som dras efter ett mänskligt bearbetande, och hanteras typiskt som text i en rapport av något slag.

Det är tydligt att vi har att göra med ett kontinuum där övergången från data till information är helt och hållet flyttbar. Den rör sig beroende på vad man lägger i begreppen ”sammanhang” och ”mening”.

Data och information på samma gång?

Vi kan i stället se det hela på ett annat sätt. Vi kan lämna resonemanget med en tänkt process, det vill säga föreställningen att data övergår till att bli information vid någon bestämd punkt. Istället kan vi se det så att samma insamlade siffror är både data och information samtidigt beroende på vilka aspekter vi för tillfället fokuserar på. När vi pratar om megabytes eller megabits per sekund så bryr vi oss inte om vare sig mening eller sammanhang. Då pratar vi om lagring eller transport av data, utan att bry oss om vad de står för. Men när vi verkligen vill titta på och förstå vad dessa data betyder ser vi det som information.

Det är det synsättet jag har fastnat för. Det är helt analogt med andra mänskliga områden. Om jag kör lastbil så kanske jag bara bryr mig om hur många ton och kubikmeter gods jag har. Men för mottagaren är det inte bara gods utan angivna mängder av specifika varor.

Några siffror är inte antingen data eller information utan både och, beroende på vilket perspektiv jag har för stunden. Distinktionen är ingen inneboende egenskap hos uppgifterna utan skillnaden ligger i betraktarens öga.

Problem med begreppet ”information”

Ett annat problem med termen ”information” är att den kan leda fel. Begreppet information leder närmast tankarna till sådant som ostrukturerad text och bild, det vill säga sådant som vi inte direkt hanterar i vårt skrå. Våra informationsmodeller visar ju endast sån information som är strukturerad som poster i en lista. Repeterbar abstraherad information, strukturerad för någon form av informationsprocessande. Termen ”data” ringar på ett bättre sätt in vad det handlar om än den alltför breda termen ”information”. I stora delar av världen kallas följaktligen det vi gör vanligen för ”Data Models”, ”Data Modeling”, ”Data Management” och så vidare.
”Information Management” står vanligen för en managementdisciplin, det vill säga hur man leder en verksamhet med information i centrum, alltså något helt annat.

Mer eller mindre synonymer?

Egentligen är väl distinktionen inte så viktig. Jag vill se termerna ”data” och ”information” som mer eller mindre synonyma. I varje fall i det sammanhang vi arbetar. Jag säger oftast ”data” eftersom jag anser att det leder tankarna lite mera rätt. Utom då det gäller modeller. Då säger jag vanligen ”informationsmodeller”. Inte så konsekvent språkbruk kanske, det är mest av gammal vana, och utan närmare eftertanke.

Vad säger du: data eller information? Gör du det som jag, av gammal vana eller har du reflekterat över vad orden egentligen står för?

/Peter Tallungs. IRM

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 8 april. Då handlar det om Datamanagement – hela kedjan.
Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Varför en industrimodell är en dålig idé

Varför inte en standardmodell i stället för en hemmasnickrad? Varför uppfinna hjulet på nytt? Är det inte bättre med en etablerad och beprövad standard? 

Det finns många generella standard-informationsmodeller för olika branscher, så kallade industrimodeller. De täcker alla upptänkliga aspekter av en bransch och finns för i stort sett alla branscher, till exempel transport-, telekom-, finans- och försäkringsbranschen. De är internationella och generella, och tänkta att kunna anpassas till de specifika behov man kan tänkas ha i sin egen organisation. Varför inte anamma en sådan modell för vår verksamhet i stället för att ta fram en egen?  

Lockelsen hos en industrimodell

I många organisationer har man sett det som en bra idé att införa en industrimodell. De fördelar man tänker sig är följande

  • Slipper besväret med att ta fram en själv
  • Får tillgång till all den kunskap och erfarenhet som finns inarbetad i modellen
  • Får kontrollerade och exakta begrepp
  • Det blir lättare att utbyta information med andra i branschen.
    (Förutsatt att modellen är accepterad av tillräckligt många.)

Ofta är man frustrerad över alla försök som gjorts med att få till gemensamma begrepp i organisationen. Då ser en redan färdig modell ut som en enkel lösning. Man påhejas av konsultföretag som har som affärsidé att erbjuda en industrimodell, och konsulter för att hjälpa till att implementera. Varför bygga något själv när det finns en färdig standard? Man förstår förstås att det ändå blir ett arbete med att anpassa sig till standarden och att man ibland även måste göra avsteg från själva standarden för sina egna specifika behov. Konsultföretagen brukar nämna att det brukar röra sig om runt tjugo procent egna anpassningar.

Allt verkar bra. Det känns tryggt att luta sig mot något etablerat. Därför har också många organisationer valt den vägen.

Det finns gott om misslyckanden

I själva verket är den vägen allt annat än trygg. Alla sådana satsningar jag känner till har misslyckats. I bästa fall har de runnit ut i sanden efter ett tag, då satsningen har tappat fart och inte visat sig ge den nytta man trodde. Ibland har satsningen ändå fortsatt, eftersom projekt har en tendens att bara fortsätta fastän de inte fungerar.

I många fall har industrimodellen då satt sin prägel på begreppen och språket i verksamheten. Men inte på ett bra sätt. Tvärtom har man då skadat organisationens möjlighet att få till en gemensam förståelse och ett gemensamt språk. Detta eftersom arbetet har varit mer inriktat på att matcha ihop företeelserna i domänen med modellen, än att verkligen skapa en förståelse av verksamheten.

Organisationen har då inte bara slösat pengar, kraft och tid samt missat möjligheter utan också hamnat i ett betydligt sämre läge än innan. Man har då förstört något av det viktigaste man har, de gemensamma begreppen och det gemensamma språket.

Ibland hör man förklaringen att de industrimodeller som finns än så länge är för dåliga, vilket inte är sant. Eller att de är för generella, vilket är sant, men den förklaringen missar ändå själva kärnproblemet. Jag vill nu försöka förklara varför hela tanken med att köpa in en industrimodell är en dålig idé.

Första skälet: Det är vägen som är mödan värd

Som jag beskrivit i min tidigare artikel, ”Om modeller på papper och modeller i huvudet”, så har modellen i sig inget värde så länge den inte representerar en gemensam förståelse. Det är modellering som skapar en gemensam förståelse och ett gemensamt språk. Det är detta som är det verkliga värdet. Det finns ingen smitväg förbi detta.

Modellen i sig är vilseledande och skadlig om den inte representerar en gemensam förståelse som är tillräckligt krispig och genomtänkt. Och det kan den bara bli genom att vi verksamhets- och it-kunniga arbetat fram den själva, tillsammans.

Det är förstås möjligt att använda en industrimodell som referens och inspiration, något att plocka begrepp, benämningar och mönster från när de passar vår förståelse av vår domän. Men det är något helt annat än att implementera industrimodellen som vår egen. Vi som modellerar har alltid olika källor för inspiration, det är inget nytt och det är inte det vi pratar om här.

När man inför en industrimodell för sin verksamhet brukar det gå till så här. Man försöker matcha ihop de företeelser och begrepp man hittar i den egna verksamheten, med begrepp och mönster i standardmodellen. Men man saknar då den djupa förståelse för de egna företeelserna som bara en modellering av den egna verksamheten kan ge. Matchningen blir ytlig, grov och skev.

Andra skälet: En modell har alltid en viss kontext

Det som ofta glöms bort är att en modell aldrig är universell. En modell är framtagen för ett visst sammanhang, det vi kallar för kontext. Kontext kan vara smalare eller bredare, utefter olika dimensioner. En modell för en viss verksamhet passar sällan en annan verksamhet trots att de är i samma bransch. Om man håller sig på en mycket generell nivå passar den förstås, men då är ju kontexten inte längre samma. Kontexten är då mer allmän, den som är gemensam för verksamheterna. Därmed kan man naturligtvis skapa en gemensam standard för en hel bransch. Men då avgränsar vi oss till just det som ska delas mellan organisationerna, det som är en delad kontext, inte hela deras respektive interna världsbild.

Vi kan förstås matcha ihop begrepp för två eller flera olika verksamheter, det gör vi ju ofta som informationsmodellerare. Det gör vi genom att först skaffa oss en djup förståelse för respektive verksamhet, det vill säga att vi först behöver modellera respektive verksamhets begreppsvärld och först därefter kan vi ta fram den gemensamma modellen.

En industrimodell är extremt generell, eftersom den ska passa alla varianter av verksamheter i branschen i fråga, i alla länder med olika lagstiftning, kultur och språk. Det blir ”one size fits all” eller snarare ”one size fits no one”.

Resultatet

Resultatet av en satsning på att implementera en industrimodell för sin verksamhet blir att hopmatchningen mellan de egna företeelserna och begreppen i industrimodellen blir slarvig och skev. Begreppen blir för vida eller smala. Namnen blir missvisande. Man har helt enkelt inte tillämpat det enda arbetssätt som kan skapa den gemensamma förståelsen. Med andra ord: man har inte modellerat. I min tidigare artikel ”Om modeller på papper och modeller i huvudet” förklarar jag vikten av att bygga gemensam förståelse i en verksamhet och ett gemensamt språk som speglar den förståelsen.

Detta gör att man, om man inte ger upp tidigare, får en begreppsvärld och ett språk som blir trubbigt, skevt och missvisande. Det blir motsatsen till vad man behöver uppnå. I stället för att bygga en gemensam förståelse och ett krispigt språk så fryser man förståelsen och förstör språket. Och det är något som skadar en verksamhet för lång tid, ofta decennier. Jag har sett verksamheter där man inte kan använda allmänna termer som ”transaction”, ”agreement” och ”service” eftersom de har låsts fast i alldeles för specifika och missvisande betydelser. Jag har sett det hända gång på gång.

Specifika standarder

Det betyder inte att standarder är en dålig idé rent allmänt. Utan standarder kan vi inte kommunicera effektivt mellan organisationer. Men då handlar det om specifika mycket smalare standarder för vissa typer av data. Till exempel hur en order ser ut inom en viss bransch, eller hur ekonomiska data rapporteras. Vanligen har de mognat fram under många år. Och det handlar då aldrig om hur en hel bransch fungerar, tvärs över alla företeelser som hanteras i de respektive verksamheterna.

Och en sådan standard ersätter aldrig vår interna modell. Den interna modellen är tvärtom en förutsättning för att vi ska kunna matcha våra egna data mot standarden.

Orsaken till övertron på industrimodeller

Jag tror att det finns flera samverkande orsaker till föreställningen att en industrimodell kan ersätta en egen modell:

  1. Fokusering på konkret synligt resultat
    En tendens att fokusera på det synliga yttre resultatet i ställe för på det vi verkligen vill ha. Man ser bara själva modellen som det viktiga, utan att förstå att den inte har något värde om den inte representerar en gemensam förståelse och ett gemensamt språk i verksamheten.
  2. Saknad förståelse av kontextens betydelse
    Man har inte har förstått att en modell alltid avser en viss kontext, det vill säga hela det sammanhang där den är giltig. Det kan vara en bred kontext, men ändå alltid en viss kontext. En modell för en hel bransch kan aldrig vara en modell för en specifik verksamhet. En modell kan inte passa överallt och ändå vara tillräckligt specifik i alla lägen.
  3. Oseriösa leverantörer
    Leverantörer säljer in industrimodeller som om det vore en beprövad och framgångsrik lösning. Leverantörernas säljare har dock inte den kunskap som krävs för att ge bra råd.
  4. Saknad förståelse hos it-ledningar
    It-ledningar har vanligen inte den förståelse för informationsmodellering som krävs för att rätt bedöma säljarnas utsagor.
  5. Akuta behov
    Man har ofta misslyckats med tidigare försök att skapa en gemensam modell, och behovet blir alltmer trängande.
  6. Invändningar framstår som flummiga
    Det är svårt att argumentera för vad modellering egentligen handlar om och hur den bör bedrivas. Det låter flummigt och svårt och det kräver erfarenhet och kunskap som man saknar. Det alternativet står sig slätt mot ett mer konkret alternativ, att bara köpa in något så är problemet snart löst.

Vad kan vi göra?

Vad kan vi göra åt det? Ja, vi som är verksamma i branschen, skriver och undervisar om modellering har uppenbarligen inte lyckats förmedla en förståelse av vad vi egentligen håller på med. Men det är aldrig för sent att göra rätt. Låt oss hjälpas åt. Det här är i mitt bidrag.

Har du varit med om att införa en industrimodell? Hur gick det? Har du andra erfarenheter? Kommentarer är välkomna.

/Peter Tallungs, IRM

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 1 april. Då handlar det om skillnaden mellan data och information.
Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Om modeller på papper och modeller i huvudet

Med ”modell” i ”Informationsmodell” menar vi vanligen en konkret gestaltning av något. Boxar och linjer på ett papper eller liknande. Det jag gestaltar är det jag har i huvudet, en mental modell, de vill säga min föreställning av hur saker och ting hänger ihop. För att rätt förstå vad vi egentligen håller på med då vi modellerar behöver vi först prata om vad en mental modell är.

Det här är kanske den viktigaste text jag skrivit. Jag försöker förmedla det jag menar är den springande punkten i allt modelleringsarbete.

Mentala modeller

En mental modell är min uppfattning om en viss företeelse eller ett system av flera sammanhängande företeelser. Vad de har för egenskaper, hur de hänger ihop och hur de fungerar.

För oss människor är de mentala modeller vi har i huvudet helt grundläggande för oss. Det är på det sättet vi har en uppfattning om saker och ting över huvud taget. Vi har mentala modeller för allt vi kan föreställa oss och allt vi därmed kan tänka något om och hantera. Om hur tvättmaskinen fungerar, vad min partner gillar för mat och hur man hittar i kvarteret. Från abstrakta saker som hur det politiska systemet hänger ihop till konkreta saker som hur Eiffeltornet ser ut. Och kanske till och med saker som hur den tyska 1800-talsromantiken har satt spår i dagens litteratur. Varje gång jag tänker på, pratar om, medvetet förnimmer eller hanterar något använder jag mig av en mental modell av företeelsen.

Jag har med tiden, alltifrån jag föddes, ja förmodligen redan i livmodern, bit för bit byggt upp mentala modeller av min omvärld. När jag lär mig något, antingen genom erfarenhet, eller teoretiskt, så innebär det att jag prövar, verifierar och falsifierar, bygger upp och bygger om min egen mentala modell av företeelserna i fråga.

En mental modell kan aldrig vara en exakt avbildning av något. Den är alltid en abstraktion, det vill säga en förenkling. Den lyfter fram och renodlar vissa egenskaper och ignorerar andra. Det är därför meningslöst att fundera på om den är sann eller falsk. Den har både styrkor och svagheter. Den kan bara vara mer eller mindre ändamålsenlig, de vill säga huruvida den passar det jag behöver använda den till. Då kan den vara allt från helt värdelös och missledande till högst adekvat. Hur den blir beror på det sammanhang jag befann mig i när jag skapade och utvecklade den. Vad som var framträdande då, i det sammanhanget. Samt av mina sinnen och mentala förmåga.

Den modell jag har i huvudet om något styr hur jag kan tänka om detta något. Den både möjliggör och hindrar. Mina mentala modeller blir min världsbild, på gott och ont. Vi formar våra modeller. Sedan formar de oss. 

Modellering

För att kunna arbeta med något, inte alltför enkelt, låt oss säga de företeelser som en verksamhet hanterar, behöver jag forska och bygga upp en mental modell av dessa företeelser, vilka egenskaper som är relevanta och hur företeelserna relaterar till varandra. Det är där modellering kommer in. För att utforska något och effektivt bygga upp en mental modell av detta något, hjälper det att jag modellerar. Det vill säga skapar mig någon form av konkret representation av företeelserna för att hålla reda på allt det jag ser som relevant och tydligare kunna se hur allt detta hänger ihop. Jag gestaltar således min mentala modell, genom att modellera. Jag har normalt inte bilden klar i huvudet när jag ritar den. Det går inte till så att jag först har bilden i huvudet och sedan bara ritar den. När jag ritar boxar och relationer, delar in saker i ämnesområden, namnsätter och definierar företeelser, egenskaper och relationer så blir jag tvungen att bli tydlig och konsekvent.  

Ritandet hjälper mig att se saker och att formulera de frågor jag behöver besvara. På så sätt bygger jag också upp min mentala modell genom att modellera. Modellerandet blir ett mycket kraftfullt tankeverktyg. Det är ping-pong-matchen mellan vad som finns i mitt huvud och på papperet som är själva grejen.

Men hittills har vi bara berört förhållandet mellan modellen som finns i mitt huvud och dess gestaltning på papper eller liknande. Vanligen är vi fler personer inblandade i ett modelleringsarbete. Och då blir modellerandet än viktigare.

Modellering som social företeelse

Min mentala modell av något är förmodligen aldrig precis samma som din mentala modell av samma sak. I bästa fall, om vi båda är i ett och samma sammanhang och har någorlunda samma syfte, stämmer de tillräckligt mycket med varandra för att vi ska kunna resonera oss fram om saker och ting. Det är i varje fall målet med att vi modellerar gemensamt. När vi modellerar tillsammans blir modellen ett socialt tankeverktyg, en plattform för att tänka tillsammans. Våra olika mentala modeller möts och påverkar varandra, vår kollektiva intelligens skapar så småningom en gemensam bild. Eller i varje fall tillräckligt överensstämmande för att vår dialog ska bli meningsfull. Vi koordinerar våra respektive mentala modeller. Den modell vi då skapar blir med alla sina begrepp, samband och regler ett gemensamt domänspecifikt språk.

Mitt språk är min värld

Det här med språk är viktigare än man kanske tror. Det är faktiskt så att det vi inte har exakta begrepp för blir svåra att över huvud taget uppfatta och tänka på. Min fru kan mycket om växter och fåglar. Efter alla skogsvandringar med henne, där jag frågat och fått svar, uppfattar jag nu fler växter och fåglar. Ja, jag ser och upplever mer i skog och mark än jag gjorde tidigare.

Så ett språk är inte bara något för att kommunicera med varandra. Språk är också något vi använder för att tänka med, även som individer. Det vi har begrepp för kan vi föreställa oss. ”Mitt språks gränser är mitt universums gränser.” sade filosofen Wittgenstein.

Modellen är ett språk, och där är namn och definitioner viktiga beståndsdelar. Vi kan egentligen inte ha en gemensam förståelse utan att också ha gemensamma namn på saker och ting, så att vi inte pratar förbi varandra. Modellen hjälper oss med detta, att skapa gemensamma begrepp, med definitioner och benämningar.

Informationsmodellen som plattform för det gemensamma utforskandet av domänen och bärare av det gemensamma språket

På så sätt blir den gestaltade modellen, det vill säga den modell vi har på papper eller liknande, inte bara ett tankeverktyg, utan den kopplar också ihop våra hjärnor på ett mycket effektivt sätt. Den gestaltade modellen blir, rätt använd, plattformen för det gemensamma utforskandet av domänen och utvecklingen av det domänspecifika språket. Att i möjligaste mån ha samma mentala modell och att den är ändamålsenlig för vad vi vill göra är helt grundläggande för att vi ska kunna hantera och utveckla något tillsammans. 

Informationsmodellens värde

Nu till det viktiga. Informationsmodellen får sitt värde av att den korresponderar med vad vi har gemensamt i våra huvuden. Den har egentligen inget värde i sig själv, fristående från vår gemensamma förståelse. Den är en representation av, och ett språk för, denna vår gemensamma förståelse. Processen är lika viktig som resultatet.

Det är processen, själva modellerandet, som mer än något annat, sammanlänkar våra hjärnor. Sedan är informationsmodellen den som även fortsatt skapar en permanens i förståelsen, språket och lärandet. Vi kan ta vid där vi slutade även efter ett uppehåll. Vi kan också lättare få upp en ny deltagare på banan.

Allt det här kan kanske tyckas självklart. Men det är något det inte brukar pratas om. Det kanske känns för flummigt? Jag är ganska övertygad om att det är få som verkligen har förstått detta på djupet och vad det betyder för oss. Trots att det är själva kärnan inom allt det vi håller på med som informationsarkitekter och som verksamhetsarkitekter. Jag är övertygad om att det är denna bristande förståelse som ligger bakom fatala missförstånd inom vårt område. Till exempel tron att vi kan köpa en standardmodell för vår verksamhet i stället för att själva ta fram en.  Mer om detta i nästa artikel.

Vad tänker du kring detta? Kommentarer är välkomna.

/Peter Tallungs, IRM

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 25 mars. Peter Tallungs utvecklar sina tankar kring informationsmodeller och jämför industrimodellen med den hemmasnickrade modellen Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

En informationsmodell istället för flera

Vi behöver inte separata konceptuella, logiska och fysiska modeller. Vi kan kombinera perspektiven i en och samma modell och därmed få ett gemensamt språk och en gemensam förståelse tvärs över verksamhet och it.

/Peter Tallungs, IRM, 2021-03-11

Inom informationsmodellering har man vanligtvis delat in modeller efter vilken aspekt av en datadomän de beskriver. Man har tänkt sig att samma domän behöver beskrivas på olika sätt för olika intressenter. Ofta har man då skilt mellan konceptuella, logiska och fysiska modeller. Det finns andra indelningar och benämningar, men tanken är i grunden densamma. 

  • Konceptuell modell En översiktlig konceptuell beskrivning på hög nivå, för att diskutera med verksamhetsfolk. Den konceptuella modellen avbildar ”verkligheten” eller rättare sagt en översikt av de företeelser som verksamheten behöver hantera. Då är inte detaljer viktiga menar man.
  • Logisk modell För att ställa krav på vilka data som behöver hanteras behöver man en logisk datamodell. Det är en modell som visar hur till exempel en databasstruktur är designad och visar all data fullständiga i alla sina detaljer. Dock innan man gjort tekniska anpassningar och prestandaoptimeringar.
  • Fysisk modell För att visa exakt hur man implementerat en databas på en specifik plattform behöver man en fysisk modell. Den visar precis hur databasen ser ut.

Tanken är (åtminstone som den ofta har framställts) att man arbetar mer eller mindre sekventiellt när man designar en databas eller någon annan datahantering. Först tar man fram den konceptuella modellen och sedan den logiska modellen som en detaljering av den konceptuella. Till sist tas den fysiska modellen fram med de avsteg man gjort för den logiska modellen av tekniska skäl. Alla tre modeller ska sedan leva vidare tillsammans. Ty alla tre perspektiven på samma datamängd behöver fortleva kontinuerligt.

Dessutom behöver man kunna spåra alla samband mellan dessa, det vill säga att man på något sätt behöver bevara alla kopplingar mellan dessa modeller. När något förändras behöver den eventuella påverkan mellan modellerna hanteras.

Problemen med separata modeller för samma domän

Synsättet ser bra ut i teorin, men jag menar att det för det första hindrar möjligheten att skapa ett gemensamt synsätt och en förståelse tvärs över it och verksamhet, och för det andra att det är ogörligt i praktiken att ha tre olika modeller för olika perspektiv på samma sak och dessutom kopplingar däremellan.

Anledningen till att vi över huvud taget skapar en modell är för att alla inblandade ska få samma gemensamma karta i huvudet, samma spelplan för att bygga vårt forskande och lärande runt. En modell ska vara vårt gemensamma språk oavsett om man är systemutvecklare eller verksamhetsexpert. När alla intressenter har olika kartor i huvudet slöar det ner all kommunikation. Kanske inte om de bara skulle röra sig om enstaka skillnader, men små skillnader på många ställen ger en kognitiv och kommunikativ friktion som kraftigt hämmar den samverkan som vi behöver.

Jag har aldrig i praktiken sett att det fungerat med att parallellt hantera och arbeta med tre olika modeller över samma domän på detta sätt. Jag vill argumentera för ett annat synsätt och ett annat sätt att lösa att vi faktiskt behöver hantera flera perspektiv samtidigt. Vi kan göra det i en och samma modell. Det går alldeles utmärkt att förena alla tre perspektiven i en och samma modell.

Jag påstår inte att alla andra typer av modeller över en verksamhet kan ersättas av en enda. Det finns perspektiv som verkligen behöver beskrivas separat. Vi kan till exempel inte trycka in en funktionskarta eller en processmodell i en informationsmodell. Men vi kan faktiskt hantera de olika perspektiven för informationsmodellering i samma modell. Jag har gjort så i många år och jag visar gärna hur, men det får bli i senare artiklar. I denna artikel ger jag en första inblick i tankesättet.

Men först, låt mig ta stöd i min argumentation från två olika håll. Det handlar om inflytelserika tankeriktningar vad gäller modellering och informationsdesign inom två delvis andra områden. De har båda varit viktiga inspirationskällor för mig.

Inspiration 1: Modellering inom programvarudesign – Domändriven design

Det finns en filosofi inom modern programvarudesign som heter ”domändriven design” (förkortat DDD), beskriven i boken Domain-Driven Design av Eric Evans. Den handlar om hur man designar den del av programkoden som representerar domänen i fråga. Det vill säga där vi har klasser som heter saker som ”Customer”, ”Product”, ”Product type”, ”Order” etcetera. Den delen av programkoden är en domänmodell, det vill säga en modell av det som verksamheten behöver hantera med hjälp av programvaran i fråga. Författaren hävdar att när man designar den delen av programkoden bör den i största möjliga utsträckning vara identisk med den mentala modell som man vill att alla inblandade, både från it och verksamhet, ska ha i huvudet. Det innebär att när man designar domänmodellen i programvaran, designar man samtidigt den mentala modell som verksamheten behöver. Det vill säga att domänmodellen i programkoden verkligen blir det gemensamma språket, tvärs över verksamhet och it. De konceptuella och logiska modellerna (vad folk i verksamheten har i huvudet) blir samma som den fysiska modellen (hur programkoden som representerar detta är strukturerad och namngiven).

Detta är i skarp kontrast till en vanlig tidigare uppfattning bland systemutvecklare där man ofta såg det som att koden gjorde man på sitt eget sätt (den fysiska modellen), sedan översatte man fram och tillbaka i användargränssnitten till hur användarna behövde se det hela (den konceptuella modellen).

Domändriven design är allmänt accepterat inom systemutveckling idag, även om tankesättet kanske inte helt och hållet har nått ut till alla systemutvecklare i sin fulla innebörd.

Boken Domain-Driven Design är även i övrigt en av mina största inspirationskällor då det gäller informationsmodellering (trots att den egentligen handlar om programvarudesign). Det är en bok jag varmt vill rekommendera till alla som arbetar med informationsmodellering. Eric Evans har en förmåga att förmedla djupa klokheter om modellering.

Det finns dock några allvarliga begränsningar med idéerna inom domändriven design:

  1. Domänmodellen är manifesterad i programkoden och därmed otillgänglig för andra än programmerare och egentligen bara de programmerare som arbetar med just den applikationen. Vi behöver en gestaltning av modellen som är tillgänglig för alla.
  2. Domänmodellen är endast uttryckt i programkod, vilket inte ger samma överblick som en grafisk beskrivning. Vi behöver en gestaltning av modellen som både ger visuell överblick och detaljerade definitioner och beskrivningar.
  3. Domänmodellen omfattar endast en enda applikation. Vanligen har vi i en verksamhet att göra med många samverkande applikationer, databaser, integrationer med mera. Vi behöver modeller som sträcker sig över flera samverkande applikationer.

Det är här jag menar att informationsmodellen kommer in. Vi kan låta den vara en domänmodell för hela den domän vi behöver hantera, tillgänglig för alla.

Inspiration 2: Informationsdesign – Multidimensionella grafer

Edward Tufte

Informationsdesignern Edward Tufte har betytt mycket för hur synen på hur man designar grafer och kartor för att förmedla data, information och kunskap ser ut idag. Han argumenterar, med många olika exempel, att alla riktigt intressanta grafer sammanför flera olika typer av kunskap eller information. Han kallar det för multidimensionella grafer. Tänk bara på vanliga geografiska kartor som sammanför naturgeografi (sjöar, höjdkurvor, naturtyper), politisk geografi (landskap, län, kommuner) och transportinfrastruktur (vägar, järnvägar, färjelinjer) i samma karta. Tufte har skrivit många böcker i ämnet men beskriver just detta bäst i boken Beautiful Evidence.

Hur hanterar vi då alla tre perspektiv i en och samma modell?

Okej, säger du. Så om vi översätter detta till databasdesign så behöver strukturen i databasen så mycket som möjligt stämma överens med hur vi tror att verksamheten behöver se på sakerna? Men i verkligheten har vi inte så ofta lyxen att designa en ny databas. Oftast finns det redan en databas, där saker heter som de gör och är strukturerade som de är, ofta med inkonsekvent och inte så bra namngivning och struktur. Då måste jag väl ha två olika modeller? Dels en fysisk som visar hur det ser ut i databasen samt en konceptuell som visar hur vi tror att verksamhetens personer behöver se på sakerna i verkligheten? Det vill säga att vi både skapar ett korrekt, tydligt och användbart gemensamt språk för verksamheten och samtidigt dokumenterar hur det ser ut rent fysiskt i datalagringen?

Ja, det stämmer att vi behöver beskriva och hantera de två perspektiven, fast det betyder inte att vi rent fysiskt behöver två informationsmodeller. Vi kan hantera båda perspektiven i samma modell. Det underlättar mycket om vi på detta sätt kan koppla ihop vad verksamheten faktisk hanterar med hur informationen om detta är strukturerad.

Jag går tillväga på följande sätt. Den informationsmodell jag tar fram är i grunden konceptuell. Det vill säga att den struktur jag visar och de namn jag använder är det vi kommer överens om som det mest korrekta, användbara och tydliga sättet att se på och benämna företeelserna och deras egenskaper och relationer. Så om jag hittar en tabell i en databas som heter ”Customer”, men jag inser att det inte bara finns kunder i denna utan även leverantörer, så skapar jag två entiteter för dessa. Fast jag anger också att de båda återfinns i tabellen ”Customer”. Om jag sedan hittar att någon har lagt kundens personnummer i den kolumn som heter ”PhoneNbr2” (jo det har faktiskt hänt!) så skriver jag in ett attribut i min modell som heter ”Personnummer” men anger att den ligger i kolumnen  ”PhoneNbr2”.

På så sätt blir modellen alltså i grunden konceptuell, och blir med tiden det gemensamma språket för verksamheten. Men den har också krokar ner i var och hur informationen om dessa företeelser ligger lagrade. Den blir på detta sätt en modell som verkligen kan bygga ihop de två perspektiven.

Synonymer

I verkligheten har ett och samma informationsobjekt ofta fler än två namn. Det kan heta olika saker i databasen, i programkoden, i API-er, i filer och i Data Warehouse och i rapporter. Det hanterar jag i informationsmodellen som synonymer, att en och samma egenskap heter olika saker i olika sammanhang. Det spelar mindre roll om det är av bra eller dåliga anledningar, det måste i varje fall hanteras. Då redogör jag i informationsmodellen för vilka olika synonymer som förekommer och i vilka sammanhang de förekommer. På det sättet får vi spårbarhet åt alla håll.

Informationstätheten

Det hävdas ofta att vi inte ska ha för mycket information i en och samma modell. Överblicken blir lidande. Allt flyter ihop till en enda röra. Men då kommer vi in på området grafisk gestaltning. Vi kan bli mycket mycket bättre på hur vi ritar. Vi kan få både överblick, tydlighet och detaljrikedom i samma graf om vi gör på rätt sätt. Det handlar om disposition, struktur, gråskalor, färger, linjebredder med mera. Det är ett område som är sorgligt eftersatt inom informationsmodellering. Där finns mycket att lära från andra discipliner som behöver kommunicera grafiskt, som byggnadsarkitektur, grafisk design, informationsdesign, ritteknik, kartritning. Jag planerar att visa hur i artiklar framöver.

Skillnad på modell och diagram

När vi resonerar om hur vi gestaltar modeller behöver vi skilja på ”modell” och ”diagram”. En och samma modell kan vara gestaltad i flera diagram. Jag brukar, när jag tar fram lite mer omfattande modeller, göra ett översiktsdiagram över hela modellen. Där har jag med alla ämnesområden och entiteter, men inga attribut, och bara de viktigaste relationerna. Det blir som en översiktskarta. Sedan tar jag fram flera detaljerade diagram, ett för varje ämnesområde eller sammanhållen grupp av ämnesområden. På så sätt får jag både en ”ut-zoomad” vy och en ”in-zoomad” vy på en och samma modell. I varje diagram samsas det logiska perspektivet (vad data representerar i verksamheten) med det fysiska (hur data lagras och transporteras).

Kanske är det hopblandningen av begreppen ”modell” och ”diagram” som har skapat behovet av att vilja skilja ut vad man kallar för en konceptuell modell från en logisk modell? Det vill säga att behovet av att ha olika detaljeringsgrad vid olika tillfällen har tvingat fram två separata modeller?

Men vad är då villkoret för att flera diagram ska kunna sägas vara samma modell? Jo, de måste beskriva samma domän och ha samma kontext (det vill säga sammanhang) och vara konsistenta (de vill säga inte säga emot varandra).

Vi behöver ju kunna använda alla uttrycksmedel som står oss till buds då vi modellerar. Då måste vi lämna begränsningen att en gestaltning av en modell består av endast ett diagram. Den kan bestå av flera diagram och flera olika typer av diagram, den kan bestå av diagram och text integrerat.
Mer om detta beskriver jag i artiklar framöver.

Att skapa en världsbild

På det här sättet kan vi få en och samma modell att avbilda inte bara informationen i sig utan även det som informationen handlar om, de företeelserna som informationen representerar. Vi får en och samma verklighetsbild, som omfattar både vad och hur saker hanteras i verksamheten samt hur detta representeras i informationssystemen, inklusive de diskrepanser vi tyvärr kan ha däremellan.

På så sätt riskerar vi inte att få det som vi så ofta ser i våra verksamheter, två grupper av individer med olika världsbild. En på it-sidan som ser ”verkligheten”, det vill säga hur det verkligen ser ut i databaserna. Och en annan på verksamhetsidan som också ser ”verkligheten”, och då en annan verklighet, det vill säga hur det fungerar i verksamheten utanför it.

Det är dags att vi börjar se det som en och samma verklighet. It-systemen är idag en integrerad del av verksamheten, inte som tidigare bara ett ”stöd” till verksamheten.  

Modellen blir ett gemensamt språk för alla parter. Detta är i min mening det mest intressanta och kraftfulla med informationsmodellering. Som modellerare skapar du faktiskt, tillsammans med de berörda, en gemensam världsbild över allt det som behöver hanteras i en verksamhet. Det är ett stort ansvar med stora möjligheter om vi tar det ansvaret på allvar. Liksom stora missade möjligheter om vi inte gör vårt bästa, utan bara fortsätter på samma sätt som vi en gång lärt oss.

Det skulle vara intressant att få höra dina synpunkter på detta. Kommentarer är välkomna.

/Peter Tallungs /IRM

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 18 mars. Då handlar det om modeller på papper och modeller i huvudet.  Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Data management

De data som en organisation äger är en värdefull resurs. Hur kan vi bygga en förmåga att ta hand om denna resurs?

Data är inte bara en bas i den dagliga operativa verksamheten, data används också för att monitorerna, analysera, styra och förbättra verksamheten. Ofta kan data ge innehåll till nya tjänster för kunder och andra intressenter. Det finns många exempel på datadrivna tjänster som skapar helt nya affärsmöjligheter.

Men precis som andra resurser behöver dataresursen tas om hand. För detta behöver vi ett strukturerat arbetssätt. Vi behöver ägarskap och förvaltningsansvar på olika ställen i organisationen. Tillika behöver vi en stödfunktion som stödjer och utvecklar arbetssättet.

Vi kan ju jämföra med hur vi gör med andra resurser. För personal har vi en personalavdelning. För ekonomiska värden har vi en ekonomiavdelning. För informationsteknik har vi en it-funktion. För varje slag av resurs har vi vanligen någon form av stödfunktion. Men var har vi den funktion som stödjer vårdandet och utvecklandet av organisationens data? Om den inte finns i vår organisation idag behöver vi på något sätt skapa den, vilket innebär att bygga kompetens, kultur och arbetssätt för data management.

Jo, men borde inte det vara it-avdelningens ansvar, kanske du invänder? Jovisst, det kan man tycka. Men det sker inte idag, i alla fall inte i de organisationer jag har insikt i. Ansvaret faller mellan stolarna. It-folket tycker att det är verksamhetens data och därmed verksamhetsfolkets ansvar. Verksamhetsfolket å sin sida har svårt att på egen hand verkligen ta hand om data på ett bra sätt.
Det är en resurs de har otillräcklig insikt i då den ligger dold för dem i databaser och flyttas runt och misshandlas i en spaghetti av integrationer.

Verksamheten har också sällan den kompetens som behövs för att hantera data. Det har visserligen inte alltid it-folket heller, annars skulle det inte se ut som det gör på många ställen idag. Men it-sidan har åtminstone de grundläggande förutsättningarna och verktygen för att ta itu med uppgiften om de bara ville ta det ansvaret.

I vilket fall som helst, var ansvaret än bör placeras, behöver vi få ett grepp om vad det innebär att ta hand om data. Först därefter kan vi bygga en förmåga för detta, med lämpliga kompetenser.

För övrigt är det hög tid att it-sidan inte ser sig som en servicebyrå till verksamheten. Man bör se sig som en lika tätt integrerad del av verksamheten som övriga stödfunktioner. Som till exempel ekonomi- eller personalavdelningarna. Men det är en annan frågeställning som vi får ta en annan gång.

Masterdata

Jag har tidigare skrivit om att det är lämpligt att skilja på masterdata, global referensdata och händelsedata, i artikeln ”Det är skillnad på data och data”. Vi vill förstås få koll på all data. Arbetssättet är ungefär lika för alla typer av data men det finns skäl att prioritera masterdata. Första skälet är att masterdata är grundläggande för övriga data. Har du inte koll på masterdata går det inte att få koll på övriga data. Har du koll på masterdata blir det relativt enkelt att få koll på resten.

Det andra skälet är att det är mer oklart var ansvaret för varje typ av masterdata ska ligga än för andra typer av data. Det är en delad resurs och är därmed utsatt för de krafter som inom ekonomi brukar kallas för ”tragedy of the commons”. Det vill säga att alla vill utnyttja det gemensamma men ingen vill ta ansvar för att vårda det.

Masterdata är vanligen kund- och produktdata, men kan också vara andra data.
Vi går i det följande igenom några masterdatadomäner.

Kunddata

Den centrala informationen om kunder är en typisk kategori av masterdata. Dit kan man räkna alla uppgifter om kunder (både privatkunder och organisationskunder) som namn, kontaktuppgifter, status med mera. Normalt omfattar det både befintliga och tidigare kunder. Ofta även prospekts, det vill säga personer eller organisationer som ännu inte är kunder men som man har valt ut som kandidater till att bli kunder.

Uppgifter om enskilda kontakttillfällen med en kund eller köptransaktioner klassas emellertid inte som masterdata eftersom det representerar händelser i tiden och därmed är händelsedata.

Alla verksamheter har eller borde ha en centraliserad hantering av kunddata. Ofta brukar det finnas i ett ERP-system eller CRM-system. Om kunddata finns spritt behöver vi ha mekanismer som håller ihop detta.

Något som vi brukar stöta på är att man saknar en tydlig livscykelmodell för kunder. När blir en kund en kund? Är det vid första köpet? Eller tidigare? När blir en kund en tidigare kund? Är en kund som inte handlat på tre år fortfarande kund? Om man inte har tydliga regler för detta går det inte att veta hur många kunder man har eller att räkna på det som kallas ”churn rate”, det vill säga kundbortfall. Sedan bör man ju också hålla reda på orsaken till att kunder slutar. Det kan vara vårt val, kundens val eller helt enkelt att kunden avlidit eller konkursat. 

De senaste årens lagstiftningar har också gjort att organisationer behöver ha bättre koll på kunduppgifter. Ett exempel är krav på skydd av personuppgifter (GDPR). Ett annat exempel är de krav finansorganisationer har på sig att ha noggrann kännedom om sina kunder för att kunna reagera på signaler om penningtvätt. 

Data om övriga intressenter

Nästan alla verksamheter behöver hålla reda på också andra intressenter än kunder. Det kan vara leverantörer, partners eller andra. Medarbetare i den egna organisationen och kontaktpersoner hos olika intressenter är också intressenter. Då behöver man bestämma sig för om man ska ha en så kallad intressentmodell (party model), det vill säga att man har entiteter som representerar alla organisationer och personer man behöver hålla reda på oavsett roll dessa har till ens verksamhet. Där finns de uppgifter som inte har med den specifika rollen att göra, som organisationsnummer och namn och typ av organisation.

Därutöver behöver man separata rollspecifika entiteter för varje roll i förhållande till vår verksamhet som intressenten har. En och samma organisation kan ju vara både kund och leverantör. En och samma person kan på samma gång vara kund, representant för ett kundföretag eller anställd hos oss. Dessa rollspecifika entiteter rymmer det som har att göra med just den specifika relationen.

En intressentmodell behöver man i de fall då det är viktigt att ha en direkt överblick över vilka roller en och samma part har i förhållande till oss. Det brukar vara fallet i sammanhang där man behöver ha direkt koll på dubbla roller hos sina intressenter, som fallet ofta är i finansiella verksamheter. För andra verksamheter är en intressentmodell ofta overkill.

Produkter

De flesta verksamheter har produkter eller tjänster av något slag som man erbjuder omvärlden. Ofta går tjänster under namnet produkter, och ur informationssynpunkt är det ingen större skillnad. Så även jag kallar här tjänster för produkter.

Ofta har man en hel flora av produkter och ofta har man oordning i namngivning, klassificering, livscykelhantering med mera. Ofta har man inte definierade begrepp för ”produkt”, ”produktvariant”, ”produktversion”, ”produktkomponent”, ”produktlivscykel”, ”produktgrupp”, ”produkttyp”, ”produktindivid”, ”produktstatus”, ”externt namn”, ”internt namn”, ”leverantörens produktnamn” med mera. Det här är viktigt att reda ut, liksom regler för namngivning.

Om man utvecklar en befintlig produkt är resultatet att betrakta som en ny produkt eller är det en ny variant av en den befintliga produkten? Vad är det som kännetecknar en produkt, till skillnad från en variant på en produkt? Och det här som vi säljer, är det en produkt som består av ett antal komponenter, eller är det en paketering av flera produkter? Allt detta måste redas ut och standardiseras om man ska få ordning på en produktflora.

Tillverkare och försäljare av fysiska produkter har ofta behov av omfattande data om sina produkter, baserat på olika branschspecifika regelverk. Det kan vara dokumentation av olika slag som materialdata, testdata med mera.

Data management öppnar för mer än management av data

Det är lätt att inse att det inte går att isolera uppgiften att ta hand om data från att fånga, formulera, dokumentera begrepp och terminologi liksom verksamhetslogik. Vanligen blir det även påkallat att driva arbetet att inte bara dokumentera utan även utforma och standardisera begrepp, benämningar och verksamhetslogik. Detta är något bra. En informationsmodell och arbetet med den är, om det görs på ett bra sätt, en utmärkt plattform för det.

Roadmap för data management

Hur kan man då ta sig an jobbet att bygga upp data management i en organisation? Så här brukar vi gå till väga i de sammanhang jag jobbat i:

1. Kartlägg verksamhets- och systemlandskapet

Vi skapar en gemensam karta av vilka funktioner verksamheten består av och hur de samverkar med varandra och med omgivningen. Vi ritar in applikationer och hur de är integrerade så att vi får en karta som visar hur applikationer och dataströmmar är djupt integrerade delar av verksamheten. Vi gör detta genom en serie mindre arbetsmöten med verksamhets- och it-specialister. Kartan behöver vi för att förankra och ge kontext till alla övriga dialoger och modeller.

Det här är ett arbete som brukar gå förvånansvärt fort. På ett medelstort företag tar det kanske två till tre arbetsveckor att få fram en karta som är tillräcklig för att gå vidare med. Men naturligtvis kommer den att fortsätta förfinas under resans gång.

Resultatet brukar bli att verksamhet och it för första gången ser en ritning över hur verksamheten hänger ihop i alla sina delar, och får en gemensam spelplan för den dialog som behövs för all gemensam utveckling av it och verksamhet. Vilket är grundläggande, inte bara för data management, utan för all verksamhets- och it-utveckling.

2. Kartlägg datastrukturerna

Vi gör en eller flera detaljerade informationsmodeller för att förstå vilka företeelser som hanteras, deras egenskaper och hur de representeras i data.

Det här är inget annat än informationsmodellering, fast mer detaljerat och noggrant än vad som är vanligt. Arbetet går vanligen fort om man har tillgång till material och kunskap från it-kunniga. Säg att det tar återigen i storleksordningen två till tre arbetsveckor att få fram en tillräckligt säker modell för att kunna gå vidare. Arbetet kan göras delvis parallellt med steg 1 ovan. Modellen kommer naturligtvis att uppdateras efter hand ju mer vi lär oss. Arbetssättet består i koncentrerade mindre möten med kunniga personer, kombinerat med egen genomgång av databas- och filbeskrivningar.

Modellerna ger oss en tänkt bild, en hypotes, om hur det ser ut men ännu har vi egentligen inte studerat verkligheten närmare, det vill säga data i sig. När vi verkligen dyker ner i data upptäcker vi saker som gör att vi får ändra i modellerna.

3. Prioritera datadomän

Vi väljer ut en viss datadomän att fokusera på. Normalt är det en masterdatadomän, vanligen kund- eller produktdata. Ofta är kriteriet det som känns mest akut, men egentligen borde man kanske också väga in var man enklast kan få tidig nytta. Normalt är det redan bestämt eftersom själva orsaken till att vi blev inkallade berodde på ett visst problem man känt av. Men det händer ändå ganska ofta att vi ser att det finns ett mer akut behov eller en mer grundläggande datadomän, så att vi gärna vill styra om ordningen.

4. Kartlägg data

Vi går metodiskt igenom all data för den utvalda domänen i de centrala databaserna, samt hur de hanteras i integrationer. Resultatet blir en rapport över hur tillståndet är för datadomänen.

Detta moment kan ta längre tid. Det är ett ganska mekaniskt, rakt och enkelt arbete, men det tar tid att verkligen traska igenom stora datamängder ur alla möjliga aspekter. Men låt mig säga att det tar i storleksordningen fem arbetsveckor. Arbetssättet är en genomgång av data i databaser med enkla verktyg som SQL eller liknande.

5. Kartlägg produktion och användning av data

Vi kartlägger hur och var data skapas, hur de transporteras, och hur det används. Ofta får vi gå vidare till externa leverantörer av data, ibland leverantörens leverantör. Likaså får vi ofta söka upp externa konsumenter av data. Vi får en bild av vilka behov som finns, hur de tillgodoses, vilka verkliga brister som finns i praktiken och hur dessa uppstår. Vi intervjuar då de som känner till integrationerna och de som har kunskap om de olika applikationerna och hur de används. Det kan ta från ett par arbetsveckor beroende på hur stort ekosystemet visar sig vara.

Det är först nu vi har en tillräckligt tydlig problembild för att veta vad som behövs göras. Tills nu har det handlat om kunskapsinsamling.

6. Planera åtgärder

Nu har vi en klar bild av var och hur problemen känns av och var de uppstår. Då är det lämpligt att sätta samman en åtgärdsplan. Av nödvändighet är den endast preliminär. Ju längre vi kommer i arbetet desto tydligare blir det vad vi behöver göra.

7. Bygg organisation och arbetssätt och sätt igång

Vi bygger en rudimentär organisation för data management av den aktuella datadomänen och sätter igång med de åtgärder som prioriterats. Det handlar om en rad åtgärder, från rent tekniska till förändrade beteenden i verksamheten. Både engångsåtgärder för att åtgärda brister och nya rutiner för att förebygga nya brister.

Det här arbetet tar egentligen aldrig slut utan fortsätter som ett lågintensivt arbete för alltid. En datadomän behöver alltid vårdas mer eller mindre kontinuerligt. Så det här är mer en första enkel och prövande uppstart av en förmåga i organisationen.

När vi har fått rull på den första datadomänen sätter vi igång med nästa. Nu har jag beskrivit arbetet övergripande men mycket mer finns förstås att säga om varje steg. Jag planerar att beskriva varje steg mer i detalj, i olika artiklar, framöver.

Men viktigt att påpeka redan nu är att inget av arbetet handlar i grunden om teknik. Tvärtom vad många system- och konsultleverantörer påstår finns det inga speciella systemplattformar som gör jobbet och det är sällan andra verktyg än de enklaste är till hjälp. Det säljs speciella masterdatasystem, men enligt vår erfarenhet skymmer de uppgiften i stället för att hjälpa.

Och tvärt om en vanlig uppfattning behöver inte en masterdata-satsning vara stor, dyr och konsultintensiv. I själva verket motverkar det syftet. Det handlar om ett uthålligt lågintensivt agilt arbete, en mognadsprocess, en resa där vi tillsammans utforskar våra data och vår gemensamma förståelse för vad de representerar och steg för steg bygger ett sätt att bättre ta hand om data. 

Invändning 1: Bör man inte ta fram problembilden först?

Jag tror att man kan invända följande: Bör man inte först och främst ta reda på vad problemen är, innan man sätter igång? Mitt svar blir att det är sällan de i organisationen har en tydlig överblick över sin dataresurs. Olika personer upplever problem i olika situationer men de är inte på det klara med hur orsakssambanden ser ut. Det krävs en kartläggning. Och det är vad vi gör i steg 1 till 5. Det är först när vi vet hur saker hänger ihop som vi lite mer utförligt kan intervjua olika nyckelpersoner och representanter för användare. Det är först då vi kan ställa rätt frågor, förstå svaren, samt sätta samman och presentera en tydlig gemensam problembild. Och det är faktiskt sällan som den första beskrivningen är speciellt intressant.

Det är som att gå till läkaren. Jag har ett symptom jag söker för. Läkaren börjar med att skicka mig till blodprov, sedan röntgen av lungor och hjärta, ultraljud av levern och så vidare. Vid återbesöket får jag veta att jag har begynnande diabetes, högt blodtryck och dåliga levervärden. Läkaren sätter utifrån dessa resultat samman en åtgärdsplan i dialog med mig.

Det jag sökte för var endast ett symptom, den ytliga signalen på att allt inte var bra. Den verkliga problembilden behövde vi komma fram till tillsammans. Läkaren ställde inte direkt en diagnos utifrån mitt symptom, utan skapade sig först en helhetsbild genom de olika testerna för att kunna ge rätt hjälp. Det är alltså inte så att hon bara frågar om det jag söker för och fixar det.

På samma sätt är det med en dataresurs. En stor del av arbetet handlar om att ta reda på hur saker och ting hänger ihop, vad de olika aktörerna behöver och har respektive inte har idag, och hur de olika orsakskedjorna hänger ihop. Att åtgärda handlar sedan om ett uthålligt arbete.

Invändning 2: Bör man inte bygga organisation först?

Vi behöver bygga en central stödfunktion och vi behöver bygga roller och arbetssätt i olika delar av organisationen. Ska vi inte börja med det och först därefter sätta igång? Det är en vanlig uppfattning, men min erfarenhet är att det inte fungerar. Kultur, arbetssätt och roller behöver mogna fram. Det behöver få ta tid. Det är en dålig idé att stressa fram detta. Det som fungerar är att börja med enklast möjliga process och organisation och låta det hela växa fram efter hand. Den kände dataspecialisten Bob Seiner kallar den hållningen för ”Non-invasive Data Management”. Och visst borde egentligen all verksamhetsutveckling vara icke-invasiv! Det vill säga att coacha individer och team så att arbetssätt får mogna fram på individerna och teamens egna villkor.

Invändning 3: Varför smådutta? Vi behöver en större transformation, och det genast!

Jag tycker att vid det här laget borde vi ha lärt oss att stora projekt är en dålig idé. Många små steg betyder inte att verksamhetsutvecklingen går långsammare. Det gör att förändringen över huvud taget fungerar och att förändringen går precis så fort som är möjligt. Vilket ofta är överraskande snabbt. Och att det blir bra.

Vi ser fram mot din syn på data management. Kommentera gärna!

/Peter Tallungs, IRM 

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 11 mars under rubriken ”En informationsmodell istället för flera”. Peter Tallungs visar hur vi kan kombinera flera perspektiv i en och samma modell  Vill du prenumerera på denna artikelserie? Registrera din mailadress här.