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.

12 Kommentarer
  1. Peter Kråik
    Peter Kråik says:

    Tack Peter!

    Jag uppskattar verkligen din artikelserie. Det är ett starkt bidrag till att ensa vår egen bristfälliga nomenklatur i branschen. De grundläggande problemen, anser jag, beror på just detta att vi inte har en stringent nomenklatur.
    Det börjar redan med att vi blandar ihop olika grundläggande termer och begrepp som du tidigare varit inne på och även tar upp i denna artikel. Det är många kloka tankar och konkreta referenser som delas. Än en gång tack för att jag och vi får ta del av ”Tallungs värld”
    Med vänliga hälsningar
    Peter

  2. Peter Tallungs
    Peter Tallungs says:

    Tack Peter!
    Jo, vad vi kallar saker för är ett problem.
    Fast jag tror att vi först och främst behöver utveckla vårt område, till en djupare förståelse vad vi håller på med och hur vi behöver arbeta rent praktiskt. Och då måste vi kanske först röra till det ännu mer genom att ifrågasätta invanda föreställningar och gamla stelnade sanningar.

    Och jag tror inte att de är bättre med begreppen inom andra områden. Jag läser just nu systemteori, som ju har ett stort intresse för alla oss som håller på med verksamhetsarkitektur. Man vill ju tro att akademiker är bättre på att tänka klart. Där finns det olika skolor med olika syn på saker och ting, ofta har man blandat ihop saker och har mer än lovligt lösa definitioner. Fast det ger ändå stor inspiration till mig.

  3. Lars Taxén
    Lars Taxén says:

    Peter, den väg framåt du beskriver tycker jag är helt rätt. Framförallt handlar det om vikten av att få till ett samordnat synsätt på verksamheten. Problemet att hantera kognitiv och kommunikativ friktion är gravt underskattat enligt min mening, och det saknas systematiska metoder och verktyg för att arbeta med detta. Anledningen är förstås att det delvis handlar om ”osynliga” saker – det vi har innanför pannbenet. Och då är det inte så enkelt att göra ett business case som man kan räkna hem arbetet på. Men alla som har suttit i ett möte för att ta fram en modell, vet att det kostar enorma mantimmar för att komma fram till en kompromiss. Ofta så räcker det inte med bara modellen – den måste också implementeras i ett informationssystem för att diskussionerna ska konvergera.

    Vi verkar helt överens om problemet med att få ett samordnat synsätt (gemensam världsbild) är det allt överskuggande. Frågan är bara hur man angriper problemet. Min uppfattning är att man måste börja med att ifrågasätta vårt traditionella sätt att tänka och uttrycka oss. Här är några saker vi borde fundera på:

    • Eftersom vi alla har unika hjärnor, vars inre vi inte kan veta något om, så blir alla uttryck som ”identiska mentala modeller”, ”designa mentala modeller”, ”gemensam karta i huvudet”, osv. problematiska. Den här typen av uttryck måste förpassas till historiens sophög om vi ska komma vidare. Det enda gemensamma är det som finns utanför huvudet – modellen.
    • Uttryck som att en modell avbildar ”verkligheten” är också problematiska. Inte minst visar det sig genom att man ofta sätter citationstecken runt ’verkligheten’. En modell avbildar inte ’verkligheten’ utan är en del av den; precis lika verklig som pennor, datorer, kartor eller vad det nu kan vara. Då kommer man ifrån avbildningssynsättet till att se modellen som ett instrument för att få fram en gemensam syn. Och då blir alla dom saker Tufte beskriver förstås väldigt viktiga.
    • Domänbegreppet är fundamentalt för modelleringen. Frågan är vad vi egentligen menar med ”domän”. Men här finns det förstås en drös av tankar – arbetspraktik, verksamhet, organisationsenhet, osv. Ofta kopplas detta till begrepp som ”siloer”, ”stuprör” för att indikera att de i någon mening är självständiga enheter. Själv har jag forskat många år om detta under begreppet ”Activity Domain”, bl.a. för att lyfta fram de kognitiva aspekterna på modellering. Men här behövs mer diskussion.
    • Synen på modeller, grafer, osv. att de ”förmedlar” kunskap, information, mening, m.m. måste ifrågasättas. En modell innehåller ingen substans som kan förflyttas från modellen in i våra hjärnor; den är bara något som existerar som streck på ett papper eller pixlar på en skärm. Information blir det bara när någon person tolkar modellen. Samma modell uppfattas oundvikligen olika av olika personer, helt enkelt för att vi har olika hjärnor. Genom en sådan synvända blir just tolkningen av modellen det viktiga – hur den bidrar till att skapa samsyn om verksamheten

    Det finns flera trådar att dra i men det kan vänta. Som vi diskuterat tidigare så kan man i praktiken nog bortse från de här subtiliteterna om man nöjer sig med att fortsätta som vanligt. Men om vi verkligen vill tänka om när det gäller modellering, måste vi gå till själva grunden för hur vi tänker.

    Så tänker jag. Ska bli intressant att följa dina tankar framöver!
    Lars

  4. Peter Tallungs
    Peter Tallungs says:

    Svar till Lars Taxén.
    Tack för din uppmuntran och din noggranna kritik. Jag tänker också att vi behöver ifrågasätta gängse föreställningar inom vårt område. Både teori och praktik. Subtiliteter kan vi förstås lämna därhän. Det är det vi kallar sådant som inte har någon praktisk betydelse.

    * Om vi kan ha gemensamma föreställningar
    Du hävdar att vi inte kan ha några gemensamma föreställningar. Du har naturligtvis rätt i att vi inte kan ha någon absolut kunskap om vad andra har i huvudet. (Jag är inte helt säkert riktigt på vad jag har i huvudet? Det är i varje fall inte helt konsistent och konsekvent.) Men jag menar att vi ofta har skäl att tro att vi har tillräckligt gemensam förståelse för att kunna resonera om något. Det upplever jag dagligen. Det är förstås en abstraktion, men jag menar att den är användbar för detta sammanhang.

    Kanske du och jag egentligen har samma syn i denna fråga, bara det att jag utryckt mig lite slarvigt. Jag påstår inte att vi har fullständiga och kompletta modeller i huvudet, hela tiden. Jag måste ofta titta efter i vår ritade och i text beskrivna modell för vad det egentligen var vi kom fram till. På så sätt behöver vi kontinuerligt synka vad vi har i huvudet, och då behövs en riktigt bra gestaltad modell.

    * Om vad en modell avbildar
    En modell (mental och/eller gestaltad) avbildar aldrig verkligheten. Vi är i själva verket inte intresserade av verkligheten. Det vi har är en modell av verkligheten (mental och/eller gestaltad) som avbildar vissa aspekter av en verklighet som är av intresse för oss. Det som cybernetikern Ross Ashby kallade för ”system”. Han menade att inget som finns i verkligheten är ett ”system”. En verksamhet är inget system, utan varje person som betraktar en verksamhet kan forma hur många ”system” som helst, dvs abstraktioner av verksamheten.

    * Om vad en domän är
    Jag och många andra använder begreppet ”domän” för det som modellen försöker representera olika aspekter av. Det kan vara precis vad som helst och måste så vara, eftersom vi modellerar så olika saker. För mig är det ofta allt det som hanteras av en hel verksamhet, eller en del av en viss verksamhet, eller ibland bara en viss tjänst eller grupp av tjänster. Men det kan vara vilken avgränsning som helst som man behöver skapa modell för. Det är ingen svaghet hos begreppet menar jag.

    * Om en modell kan förmedla kunskap
    Jag tycker att vi inte förlorar något på att uttrycka oss på det sättet även om vi vet att det egentligen går att se djupare på det hela. Vi kan säga att en bok, eller en video, eller en person kan förmedla kunskap. Även om vi vet att det egentligen är en komplicerad process som inbegriper kodning i olika nivåer, från fysiska och kemiska händelser i min hjärna, via kodning i nervimpulser och skapande av rörelser i mina stämband till vågor i luften som på något sätt är kodade morfem på ett språk som är känt av oss båda och hela vägen genom hela protokollstacken igen till det blir kemi i din hjärna. Kan du inte tycka att det blir jobbigt att hela tiden bryta ner det till sina minsta reduktionistiska bitar? Kan vi inte bara säga att jag ”jag meddelade dig och allt tyder på att du förstod”.

    Ser fram mot fortsatt dialog!

  5. Tobias Nilsson
    Tobias Nilsson says:

    Det låter så självklart när man hör det från dig Peter. Kul att se sån utåtriktad energi från dig igen.

    Fråga: Planerar du att prata mer ingående om homonymer längre fram i serien? Alltså termer som låter identiska men som används till helt olika saker på olika ställen i verksamheten. Jag skulle jättegärna se lite exempel på hur du har visualiserat den typen av begreppskonflikter i modeller där det går att zooma ut och täcka in flera domäner och system.

  6. Peter Tallungs
    Peter Tallungs says:

    Svar till Tobias:
    Tack Tobias.
    Det jag alltid har med är synonymer, att en och samma företeelse eller egenskap (eller egenskapsvärde) kallas för olika saker i olika sammanhang. Det har jag alltid med i textdelen av modellen och också i själva ER-diagrammet. Ofta är det tekniska namn i det omedelbara sammanhanget. De skriver jag i grått direkt efter det namn som jag menar är det kanoniska som vi bör använda som det ”riktiga” gemensamma namnet. När det är flera andra synonymer listar jag dessa i textdelen och skriver jag både vad det heter och i vilket sammanhang det heter så.

    Homonymer brukar jag påstå att man ska ha med men i praktiken har det inte blivit så ofta. Men visst bör man ha med det så snart då det är risk för förväxling. Då skriver jag att det är en homonym, i vilket sammanhang den förekommer och vilken betydelse termen har i det sammanhanget.

    Vanliga synonymer är vad företeelsen heter i ett visst it-system. För de namnen som är satta där är ofta inte speciellt bra valda från början och har ofta blivit ännu mer missvisande. Ett specialfall är när man behöver skriva allt på både svenska och engelska. Då dubblerar jag allt, både namn, definitioner och beskrivningar och använder blå färg för allt som är engelska, för att skilja ut så att läsaren kan koncentrera sig på ett språk åt gången samtidigt som allt hålls samman.

  7. Peter Tallungs
    Peter Tallungs says:

    Tobias, jag insåg att jag inte riktigt svarade på din fråga. Jag har inte riktigt tänkt på det du efterfrågar, men kanske det handlar om det som Eric Evans i Domain Driven Design kallar för ”shared domains”, det vill säga när två domäner möts och överlappar varandra. Jag kommer att komma in på det så småningom, men det blir längre fram i serien.

  8. Marcus
    Marcus says:

    Intressant.

    Några tips på hur man tar sig an informationsmodelkeringen när en hel del av verksamheten består av excelexercis, personliga informationsmängder, tämligen odokumenterade arbetssätt, beslut fattade på känsla/upplevd data snarare än sådan som finns i databaser? Där beräknade uppgifter inte går att följa i databasen utan skapas med kod eller manuella insatser och ’brukas’ utan att lagras… Alltså när en ganska betydande del av informationen (källdata eller bearbetad information inte går att läsa ur databaser). Så klart något man vill komma till rätta med, men det är ju lite svårt att först fixa och sedan rita ☺️. Man får en ungefärlig bild av vad det är för information som är inblandad men den är svår att bekräfta och väldigt tidsödande att gå till botten med. Rita mer övergripande och ungefärligt?

  9. Peter Tallungs
    Peter Tallungs says:

    Svar till Marcus.

    En rapport från verkligheten! En uppfriskande reality-check! Så ser det ut på många ställen. Ja egentligen mer eller mindre i alla organisationer jag har jobbat i. Att fixa bristerna först utan att kartlägga situationen, går förstås inte.

    Jag brukar alltid börja med att kartlägga både vilka verksamhetsfunktioner och system som finns och hur de är integrerade. När jag pratar om system så är inte minst de odokumenterade viktiga att få grepp om.

    Om Kalle har ett excelark som är en regelmässig del av informationsförsörjningen i verksamheten så är det en viktig applikation att dokumentera, både vad den innehåller, vad den gör och hur den är integrerad med resten av verksamheten. Om Kalle mejlar resultatet av sin snurra vid till någon inför varje månadsskifte så är det en integrationspunkt och en tjänst som bör dokumenteras och hanteras. Man får inte glömma att kartlägga, intervjua och förstå vem som använder informationen, till vad och hur de uppfattar att det fungerar.
    Ofta sker saker i programkod som man behöver dra fram i ljuset och få grepp om. Standardsystem är ett kapitel för sig. Där har man vanligen krånglat ihop saker så de är tufft att reda ut.

    Arbetet har två sidor, ungefär som inom historievetenskapen: Etnologi (intervjua infödingarna, det vill säga verksamhets- och it-experter) och arkeologi (gräva i ruinerna, det vill säga databaser och filer).

    Att sedan åtgärda brister är ett långsiktigt och tålmodigt arbete, ett litet steg i taget, med agilt arbetssätt. Det finns ingen snabbfix, men det fungerar inte heller med ett stort grepp som ska fixa allting på en gång. Men det kan ändå gå ganska fort, fortare än man kanske tror, när man fått igång ett litet team och ett arbetssätt där man betar av grej efter grej.

    (De värsta haverierna jag sett är när en it-ledning i samarbete med en leverantör ser det hela som ett teknisk problem som kan lösas med en ny plattform.)

    Jag har försökt beskriva det arbetssätt jag använder, som en roadmap i stora drag, i förra veckans artikeln med titeln Data Management.

    Kanske någon annan läsare vill kommentera?

  10. Lars Taxén
    Lars Taxén says:

    Peter, inte helt lätt detta! Hela tanken med mina inlägg är att vi måste ta itu med svårigheterna att få till en samsyn om något, t.ex. en modell. Alla har vi upplevt hur mödosamt detta är, hur man kan bli oense, och hur man fastnar i oändliga diskussioner om vad en viss del av en modell egentligen ’betyder’.

    Är det här ett viktigt problem? Jag menar nog att det är det. Och om man ska ge sig på att lösa det, måste vi gå till grunden och tänka nytt. Det är då som subtiliteterna blir viktiga.

    Ett exempel: Vi kan se en modell som en avbildning av något som finns (en ’del av verkligheten’). Då blir konsekvensen att vi försöker hitta den ’bästa’ avbildningen, och diskussionen tenderar att handla om det som är ’sant’ och ’mest rätt’. Alternativt kan vi se modellen som visar på mot något som ännu inte finns – en tänkt framtid som vi ska konstruera tillsammans. Då blir fokus på hur modellen ska utformas för att underlätta samsynen.

    Detsamma gäller dom andra punkterna jag tog upp. Det här är raka motsatsen till ett reduktionistiskt synsätt – det handlar om samspelet mellan det individuella och det sociala. Jag skulle snarare säga att det sätt vi praktiserar modellering på idag är reduktionistiskt – ett alltför ensidigt fokus på modeller utan att ta hänsyn till våra biologiska förutsättningar att förstå dom (tänk TOGAF).

    Egentligen är vi nog i grunden helt eniga om att det är ett stort problem att åstadkomma en gemensamma samsyn. Men det behövs en grundligare diskussion om hur man ska lösa det.

  11. Peter Tallungs
    Peter Tallungs says:

    Svar till Lars Taxén.
    Tack för att du vill borra i detta, som vi båda tycker är viktigt. Jag tycker också att vi behöver tänka nytt inom området, både teoretiskt och praktiskt. Det som intresserat mig de senaste decennierna är att utveckla är främst följande två områden:

    1) Att våra modeller behöver bli vad jag kallar ”rikare”, det vill säga bära mer kunskap i en och samma modell.

    2) Att våra modeller måste bli bättre gestaltade i både grafik och text.

    Båda strävandena hänger ihop. Punkt 1 är beroende av punkt 2. De innebär båda att vi måste släppa en hel del invanda föreställningar och frigöra oss från dagens ramverk, metoder och verktyg som begränsar oss. Samt att vi behöver lära oss från andra områden som gestaltar komplicerade saker med grafik och strukturerad text.

    Du har säkert andra käpphästar, men det är bara roligt och nyttigt. Jag ser fram mot den dialogen.

Lämna en kommentar

Want to join the discussion?
Dela med dig av dina synpunkter!

Lämna ett svar

Din e-postadress kommer inte publiceras. Obligatoriska fält är märkta *