Inlägg

Om mönster för informationsmodeller

”När vi gör en informationsmodell brukar vi inte börja med endast ett blankt papper och grundprinciperna inom vårt område. Precis som designers inom andra områden så tillämpar och anpassar vi lösningar som har visat sig användbara tidigare. Utvecklingen och användningen av standardlösningar (”modellmönster”) är en viktig del av informationsmodelleringens praktik.” Detta är ett citat av Graeme Simsion, den australienske författaren till en av de viktigaste böckerna om informationsmodellering ”Data Modeling Essential”.

Repertoarer av mönster

Om jag vill lära mig att spela schack lär jag mig kanske först hur brädet och de olika pjäserna ser ut, sedan hur de får lov att flyttas, därefter att vi turas om att göra våra drag och vad spelet går ut på. Detta tar inte så lång tid att lära sig. Har jag då lärt mig allt som där finns att lära? Nej, knappast, jag har knappt ens börjat! Resten av min resa inom området, från gröngöling till mästare, handlar om mönster. Inte så mycket om enskilda drag, mest om kombinationer av drag. Många kombinationer är kända och namngivna. Andra hittar jag själv fram till och kan dra ess ur rockärmen när så passar.

Det är så det går till inom i stort sett alla områden av mänsklig verksamhet. Både som kollektiv och individer har vi en repertoar av mönster som vi uppfinner, tillämpar, utvecklar och traderar.

Så har vi alltid gjort inom olika områden. Det som jag här benämner mönster kan kallas för en mängd olika saker men det har, i olika sammanhang, blivit mer vanligt att prata om just ”mönster”.

Mönster-begreppet inom informationsmodellering

Inom informationsmodellering har begreppet mönster använts och definierats på följande sätt:

  • Data Model Patterns (Dave Hay)
    ”Common situations that are present in a variety of business and government agencies, and which can be modeled in a standardized way – conventions of thought.”
  • Analysis Patterns (Martin Fowler)
    ”[in object-oriented analysis we] are regularly seeing problems repeat themselves.”
    ”A pattern is an idea that has been useful in one practical context and will probably be useful in others.”
  • Universal Patterns for Data Models (Len Silverston)
    ”The common underlying structures that are applicable to all data models.”
  • Patterns of Data Modeling (Michael Blaha)
  • Patterns and generic models (Graeme Simsion och Graham Witt)

Hur tanken om mönster växt fram och nått området informationsmodellering

Jag har tidigare gjort grafen nedan för att visualisera min tolkning av hur idén om mönster växt fram; från byggnadsarkitektur, via programvaruutveckling till informationsmodellering.

Den som först började tala om mönster i den här meningen var byggnadsarkitekten och designteoretikern Christopher Alexander. Det handlade då om byggnadsarkitektur, allt från stadsplanering till inredningsarkitektur. Hans filosofi har inspirerat många inom olika designdiscipliner, inte minst inom systemutveckling och verksamhetsarkitektur.

Viktigt om mönster

Det finns i några av idéerna formella krav på hur man ska strukturera beskrivningen av ett mönster. De härstammar från Christopher Alexanders idéer om designmönster. De är lite olika men kan se ut så här:

  • Namn
  • Det generella problemet som ska lösas
  • Den generella lösningen
  • Exempel på konkreta lösningar
  • Konsekvenser
  • Samband med andra mönster

Det som ibland har missförståtts, är att mönster inte är ett självändamål. Det var något som hände inom programvaruutveckling efter 1994 när designmönster gjorde sin entré i programmerarvärlden genom boken ”Design Patterns”. Då blev det en sport att klämma in så många som möjligt av bokens designmönster i sin kod.

Christopher Alexanders idé var att alla mönster inom ett område skulle fungera som ett språk för olika designlösningar. Han kallade det ett mönsterspråk (”Pattern Language”). Tanken är att vi tillsammans kan tradera olika lösningar samt diskutera, värdera och tillämpa dessa. Varje mönster har sina styrkor och svagheter, och passar olika bra beroende på sammanhanget. Vi ska inte bara kunna tillämpa mönster utan också välja bort ett mönster när det inte passar.

Mönster för informationsmodeller

Jag kommer i artiklar framöver att presentera ett antal mönster för informationsmodeller. En del av dessa mönster har jag lärt mig från olika böcker och sedan tillämpat i olika sammanhang. (Eller kanske glömt varifrån jag fått inspirationen. Vem kan komma ihåg var man får allt ifrån?) Jag kommer inte att vara så noga med strukturen på beskrivningen, utan min tanke är att grundligt presentera och diskutera varje mönster. I det sammanhanget kommer jag också, när det passar, ta upp andra mer grundläggande frågor runt modellering.

Syftet är att dela kunskap och erfarenheter inom informationsmodellering, samt att inspirera till en dialog runt detta. På så sätt kan vi kanske få igång en utveckling inom vårt kunskapsområde.

Källor för modellmönster

Jag har angivit några av mina källor ovan och jag kommer fortsättningsvis att försöka ange källorna för de mönster jag beskriver. Var har du hittat dina mönster? Har du något tips på en bra källa så tror jag att vi alla som läser detta blir tacksamma.

/Peter Tallungs

I och med denna artikel har vi ett sommaruppehåll. Torsdag 12 augusti kommer nästa artikel i denna serie om informationsarkitektur publiceras.

Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Saker jag stjäl från UML

UMLs klassdiagram har ett par uttrycksmedel som jag saknar i de vanliga ER-notationerna. Det finns inget som hindrar att vi ”lånar” in dessa.

Jag brukar använda den vanligaste notationen för informationsmodeller, det vill säga JMIE (James Martin Information Engineering), kanske mest känd som ”Crow foot notation” (kråkfotsnotation). Främst för att den är vanligast i de sammanhang jag jobbar. Men i den notationen saknar jag ett par saker som finns i UML. Då brukar jag helt sonika låna in dessa.

Ett försvar för att låna från olika notationer

Jag kan tänka mig att en och annan nu sätter kaffet i vrångstrupen bara av tanken på att blanda notationer. Man tycker det är viktigt att vara korrekt, följa regler och att alla gör likadant.

Mitt försvar är att det finns en tid för regler och konsekvens, och det finns en tid för experimenterande och utveckling. Informationsmodellering har som kunskapsområde stått still, i min mening stelnat redan för flera decennier sedan.

Ska vi få till en utveckling av området behöver vi experimentera. Vi behöver vara nyfikna, inspireras från andra områden, kombinera idéer och prova oss fram. Standardisera kan vi vänta med tills vi kommit fram till något som känns någorlunda stabilt. Och dit har vi en bit kvar.

I det följande redovisar jag det jag saknar i vanliga ER-notationer men som finns i UML, och som jag därför fräckt och oblygt lånar in.

Supertyp och subtyp separerade från varandra

Om en entitet är en generalisering av två eller flera andra så ritar man i de vanliga ER-notationerna den generaliserade entiteten (supertypen) som en ram runt de specialiserade entiteterna (subtyperna).

I UML ritar man i stället subtyperna separerade från supertypen, och en relationslinje emellan dessa med en ofylld triangelspets i änden mot supertypen.

(Det finns dock även en del äldre ER-notationer som också separerar super- och subtyp på samma sätt som UML. Relationen kallas då
”is-a”-relation)

Båda ritsätten har sina styrkor och svagheter menar jag.

Fördelen med ritsättet med supertypen som ram är att det intuitivt ger en bättre förståelse för vad det handlar om. Relationen mellan sub- och supertypen är inte en relation mellan två separata företeelser, utan en relation mellan två begrepp, ett mera generellt och ett mera specifikt. En sådan relation har alltså en helt annan natur än de vanliga relationerna som övriga streck representerar. Därför är det bra med ett ritsätt som kraftigt avviker från övriga relationer.

Supertypen är ett mer generellt begrepp för samma företeelser som subtypen. En förekomst av subtypen är samtidigt en förekomst av supertypen. Det finns på så sätt en likhet med de Venndiagram som vi minns från skolans mängdlära. Ritsättet gör att risken minskar att en ovan betraktare av en informationsmodell ska tro att en motorfordonsförsäkring är något annat än en försäkring.

Med UMLs ritsätt är det däremot lätt för en ovan betraktare att tro att vi, precis som med andra typer av relationer, har två olika företeelser med olika förekomster. Där har vi svagheten att relationer med så helt väsensskilda naturer har så lika grafisk gestaltning.

Men det finns också en baksida med ritsättet i JMIE. Det finns tillfällen då det blir omöjligt att rita subtyperna inuti supertypen. Det är när varje subtyp behöver veckla ut sig till ett eget ämnesområde med många egna entiteter runtomkring som är unika för just det ämnesområdet. När det behovet uppkommer ritar jag som i UML, trots att jag i övrigt använder JMIE. Det vill säga sub- och supertyper för sig, förbundna med en linje med en ofylld triangelformad pilspets.  

Komposition

Det är vanligt att två entiteter har en särskilt existentiell koppling. Det vill säga att en förekomst av en entitet inte kan existera oberoende av en förekomst av en annan entitet. Ett exempel är en faktura med en eller flera fakturarader. Relationen mellan faktura och fakturarad innebär en mycket starkare koppling än vanliga relationer. En fakturarad har nämligen ingen självständig existens, den kan aldrig existera utan att tillhöra en faktura, den kan inte byta faktura, och om fakturan raderas så försvinner också fakturaraden. I en del äldre notationer kallas den beroende entiteten för beroendeobjekt. Jag tycker att en informationsmodell blir mycket tydligare om man tydligt kan uttrycka den starka relationen.

I de vanliga ER-notationerna finns det ingen möjlighet att uttrycka detta på annat sätt än med den vanliga min 1 – max 1-symbolen, trots att det är en koppling som är väsensskild från vanliga min 1 – max 1-kopplingar.

I UML kallas den relationen komposition och uttrycks med en romb och en pilspets enligt bild. Egentligen ska romben vara fylld men den symbolen finns inte som standard i Visio så vi får nöja oss med en ofylld.
Inom parentes sagt: Den ofyllda romben uttrycker i UML ett aggregat, vilket i praktiken är samma som en min 1 – max 1-koppling, och därför är tämligen meningslös. Jim Rumbough, en av grundarna till UML, liknade det själv vid placebo och Martin Fowler ägnar en hel uppsats till att avfärda konstruktionen. 

Så fort jag har en relation i ett ER-diagram som har denna täta koppling så markerar jag det med en romb. På så sätt tycker jag att modellen blir tydligare. Man ser då vad som har en självständig existens och vad som är en integrerad del av en annan företeelse. Dessutom brukar jag placera entiteterna med den beroende entiteten placerad under och med vänsterkanten indragen från huvudentiteten, som bilden till höger visar. På så sätt vill jag tydlig signalera det nära och underställda beroendet.

Vilka innovativa idéer har du?

Jag vill med detta inspirera till experimenterande. Att vi kan lösa modellerings- och gestaltningsproblem på ett nyskapande sätt när så behövs. Vi ska inte vara rädda för att göra fel och måste inte alltid ”play by the book”. Ett område kan bara gå framåt när någon med ett tydligt syfte bryter mot ingrodda regler och ”sanningar”. Den lilla risken vi får ta är att våra modeller därmed blir lite brokigare. Men det är ett lätt pris om det kan bidra till att avancera hela vårt område.

Nu är det din tur. Vad brukar du göra annorlunda?

/Peter Tallungs

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 24 juni. Då handlar det om mönster för informationsmodeller.
Vill du prenumerera på denna artikelserie? 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” 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.