Inlägg

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” 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.

Informationsmodellen som domänmodell

En informationsmodell beskriver inte bara data i en verksamhet utan även det som data representerar. Det vill säga allt det som verksamheten behöver hålla koll på, med andra ord verksamhetens domän.

Varje gång jag säger att informationsmodellen beskriver information så skorrar det lite falskt i mig. För jag tycker inte att det är helt rätt beskrivet, eller i varje fall inte speciellt klargörande.
Ja faktiskt till och med missledande, på sätt och vis. För då utelämnar vi det viktigaste. Låt mig förklara.

Det är sant att en informationsmodell beskriver strukturen hos informationen i något sammanhang. (Eller ofta snarare hur den bör vara.) Det kan vara data i en databas, i en fil, i en applikation eller en tjänst. Men det kan också vara den konceptuella strukturen av den information som delas av en verksamhet eller en verksamhetsfunktion.

Så långt är allt väl. Lätt att förstå och prata om. Men sedan kommer det som komplicerar, men som också gör det hela mer intressant. Mycket mer intressant i min mening.

Data i sig representerar i sin tur något som finns där ute i verkligheten. Varje entitet i en informationsmodell representerar en klass av företeelser som verksamheten behöver hålla reda på förekomster av. Det kan vara kunder, produkter, produkttyper, ordrar med mera.

Den dubbla rollen

Alltså, informationsmodellen avbildar både strukturen hos data i sig och utgör samtidigt en modell av domänen det vill säga de företeelser som verksamheten behöver hantera.

Informationsmodellen är följaktligen lika mycket en domänmodell som en modell över informationen som behövs för att hantera domänen.

En domänmodell beskriver verksamhetens ”värld”, de företeelser som behöver hanteras av verksamheten, beskrivna och benämnda på ett sätt som passar verksamhetens sammanhang och syfte. Den vill uttrycka den gemensamma förståelsen av det som hanteras och utgöra det gemensamma språket. Det är svårt att överdriva betydelsen för en organisation av att utveckla och vårda den förståelsen och det språket.

Det här är något som sällan kommer upp på bordet, men som jag menar är väsentligt för att förstå vad vi egentligen håller på med när vi modellerar.

Informationsmodellens största potential

Det är just där, som domänmodell, informationsmodellens största potential ligger menar jag, och samtidigt den hittills mest underutvecklade. Vi har, om vi blir skickliga i vårt värv, en förmåga att beskriva, hantera och utveckla hela verksamhetslogiken på ett sätt som annars inte är möjligt.

Jag har sett hur informationsmodellen enkelt och naturligt kan fylla en central och viktig roll i en verksamhet. En informationsmodell kan bli en gemensam karta över det som verksamheten hanterar, en domänmodell. Den kan bli bäraren av de gemensamma begrepp och det gemensamma språk som vi behöver. Jag har till och med sett att den kan bli bäraren av hela den grundläggande verksamhetslogiken. Och inte bara det, den kan även bli plattformen för utforskandet och utvecklandet av verksamhetslogiken och språket. Och det med överraskande enkla medel.

Informationsmodellering kan därmed fylla en mycket mer central roll i analys och utveckling av en verksamhet och dess informationssystem än den gör idag. Inte bara vad gäller analys och utveckling. Vi har ju i alla sammanhang behov av att arbeta för en gemensam förståelse, krispiga begrepp och ett gemensamt språk.

Fast i så fall behöver vi tänka om och tänka nytt. Vi behöver öppna upp beskrivningstekniken till en helt annan kraftfullhet. En huvudtanke med denna artikelserie är att föreslå hur vi kan få till detta.

Vad säger ”information” egentligen?

Nu till något helt annat. Ett annat sätt som namnet ”informationsmodell” skorrar lite falskt för mig har med förledet ”information” att göra. Ett måhända mindre problem, men ändå irriterande.

Om jag säger till min granne att jag jobbar med informationen på ett företag så skulle hon anta att jag är informatör eller skribent av något slag. Och kanske skulle jag sedan försöka förtydliga genom att fortsätta med att jag arbetar med en modell över informationen. Då skulle hon nog, om hon inte ryckte på axlarna och gav upp, göra sig en bild av att jag på något sätt ser över hur företaget ska informera externa eller interna intressenter. Eller kanske ser hon framför sig hur jag tar fram en modell för omvärldsbevakning. Så låt oss vara överens om att ”information” inte är en tillräckligt specifik benämning på det vi modellerar.

I själva verket beskriver en informationsmodell inte strukturen på information i största allmänhet utan endast strukturen och meningen hos den information som behöver listas i en verksamhet. Det vill säga den data som beskriver klasser av företeelser som har förekomster av något slag. Förekomster av saker som verksamheten behöver hantera och därmed behöver lista på något sätt. Till exempel kunder, ordrar, produkter, anställda, postnummer och tusen andra saker.

Och egentligen aldrig det som man i första hand tänker på som företagets information som företagets historia, affärsplan, årsredovisning, ägarförhållande, affärsidé, verksamhetsbeskrivning, kundvärde, marknad, kreditvärdighet med mera.

Kanske det skulle vara tydligare att prata om ”datamodell” som amerikanarna gör?

Så vad blir mitt förslag på namn på de modeller vi gör? Tja, traditionen gör väl att vi får fortsätta att säga ”informationsmodell”, fast det inte är speciellt förklarande och måhända tar emot lite grand. Och vi kan väl tillstå att ”datamodell” är en synonym. Och vara medvetna om att vi i själva verket modellerar en domän i sig utöver informationen och språket om domänen. Även om vi kanske ännu inte är mogna för att kalla det för domänmodell?

Vad tycker du? Kan du se informationsmodellens roll som domänmodell?  

/Peter Tallungs, IRM

Prenumerera på artikelserien om informationsarkitektur

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 25 februari. Det handlar då om skillnaden mellan data och data.  Vill du prenumerera på denna artikelserie? Registrera din mailadress här.