Inlägg

Informationsarkitekt – Hur långt sträcker sig rollen?

Vad gör en informationsarkitekt? Hur långt sträcker sig rollen egentligen?
Den 15:e oktober 2021 bjöd vi på IRM in till diskussionsträff för att diskutera rollen Informationsarkitekt; vad som kan ingå i rollen och vad som inte ingår. Vi har röstat och vi har ett resultat!

De flesta som läser detta har nog en bild av vad en informationsarkitekt gör. Åtminstone vad kärnan i arbetet är och ungefär hur långt rollen kan sträcka sig. Och jag tror egentligen inte att vi har så olika uppfattning. Men ändå, det kan finnas aspekter där vi har en lite olika förståelse. Och det finns ju inget rätt eller fel egentligen, man kan absolut argumentera för en snävare eller vidare omfattning av rollen.

Den 15:e oktober 2021 bjöd vi på IRM in till diskussionsträff för att diskutera rollen Informationsarkitekt; vad som kan ingå i rollen och vad som inte ingår.

Vi var femton deltagare, nästan alla är verksamma informationsarkitekter och några andra med ett starkt intresse i området.

Röstningen

För att få en struktur på diskussionen hade jag förberett en röstning och listade de kompetensområden som vi såg som kandidater i sex rader. Sedan delade vi dessa i korsande kolumner för de olika sätt på vilka man kan tänkas kunna vara involverade i respektive område.  Detta resulterade i en matris, se nedan

Det är svårt att uttrycka sig riktigt entydigt så både raderna och kolumnerna kan tolkas lite olika. Man kan också argumentera för fler rader och kanske också fler kolumner. Men deltagarna denna dag var överens om att indelningen skulle fungera för en röstning. Vi skulle få ett grepp om ifall vi har ungefär lika uppfattning eller var skiljelinjerna går mellan olika uppfattningar.

Själva röstningen gick till så att deltagarna fick markera i respektive ruta om man ansåg att rollen omfattade det som påstods eller inte. Det fanns också möjlighet för ett tredje alternativ, kanske, och det hände även att någon avstod från att rösta i vissa rutor.

Resultatet

Här är röstresultatet

Jag tänker nu våga mig på en analys av resultatet. Men först några noteringar.

Vilken ”informationsarkitekt” röstade vi om?

Det finns ju två radikalt olika innebörder i termen informationsarkitekt. Se artikeln ”Informationsarkitekter – de två kulturerna”. Den betydelse vi röstade om var den roll vi på IRM är engagerade i, som är inriktad på en hel verksamhet eller del av en verksamhet. Den andra betydelsen av termen ”Informationsarkitekt” handlar om presentation av information på en specifik webbplats eller liknande.

Var gruppen representativ?

Vems uppfattning belyser röstningsresultatet? Vem var med och röstade? Jag och mina kollegor uppfattar att deltagarna på diskussionsträffen den 15 oktober 2021 kan räknas som ett representativt urval av de som är verksamma inom området. Åtminstone tillräckligt representativt för att vara intressant. Vi hade en ganska bra köns- och åldersfördelning, och deltagarna kom från både offentliga organisationer och privata företag.

Var gruppen tillräckligt stor?

En liten grupp ger ett lika bra resultat som en stor, så länge urvalet inte är skevt.

Det vi röstade om var kompetensroller, inte befattningsroller.

Jag menar att man vid diskussion om roller bör skilja på om vi pratar om kompetenser eller befattningar. Om jag säger att jag är informationsarkitekt så kan det betyda att jag har den kompetens man kan förvänta sig av en sådan. Det kan också betyda att jag har en befattning med det namnet i en viss organisation. Det är en viktig skillnad. Vi var här intresserade av själva kompetensen, inte hur man använder titeln i landets organisationer.

Rösten ”Ja” i en ruta, menar man då att en informationsarkitekt måste behärska det rutan står för?

Nej, inte riktigt, hela området är stort, och alla kan inte greppa alla delområden fullt ut. Vi menar snarare att en Ja-röst betyder att du anser att området ingår i kompetensområdet på något sätt. Att det är rimligt att anta att en utbildning eller certifiering inom området skulle omfatta området för att kunna sägas vara komplett. Det hindrar inte att jag som säger mig vara informationsarkitekt kan ha mindre kompetens inom ett eller flera av områdena. Fast jag måste nog kunna täcka de flesta i varje fall, annars blir det tunt.

Analys av resultatet

Låt mig gå igenom områdena rad för rad och försöka tolka röstresultatet.

Data- och informationsstrukturer

Syftet med data- och informationsmodellering är att få grepp om data- och informations-strukturerna i en verksamhet. Gruppen var ense om att det ingår i rollen. Så vi kan även fortsättningsvis betrakta modellering som en kärna i informationsarkitektens arbete. Närmare hälften har dock givit en liten reservation för att styra, leda och hantera med ett ”kanske”. Det beror förstås på vad vi menar med verben ifråga. ExKanske man lägger någon slags chefsroll i detta som man menar inte ingår.

Begrepp och språk

Detta område har fått lika höga röstetal som föregående. Jag tolkar det som att man vill se att vi med våra modeller, med sina benämningar och definitioner, fångar och formar ett språk för de företeelser som beskrivs av data. Jag tycker att resultatet är intressant, för jag upplever att den aspekten av modelleringen ofta inte uppmärksammas.

Försörjning, integration och användning av data/information

Analysera/utreda/dokumentera/modellera får närmast full pott i röstningen medans övriga rutor får succesivt fallande röstetal. Jag tolkar det som att man vill se det som att informationsarkitekter ser till att man har koll på hela dataförsörjningen, men att man däremot inte har ensamt ansvar för att få försörjningen att fungera. Utan det är ett ansvar för it-funktionen som helhet.

Ta hand om data som tillgång/resurs

Här återkommer mönstret från föregående rad, och min tolkning är densamma.

Ägarskap och styrning av dataresurser

Återigen samma mönster som de två föregående raderna. Samma tolkning

Styrning av dataresurser utifrån säkerhetskrav

Nu träder vi ut på lite mer främmande mark. Nästan alla röstade ”Nej”, och några är tveksamma, på om datasäkerhet verkligen är informationsarkitektens hemmaplan. Undantaget är uppgiften att analysera/utreda/dokumentera/modellera. Jag tolkar det som att informationsarkitekten kan ta en analyserande roll inom området men knappast ett större ansvar.

Jag hann själv inte med att rösta men min uppfattning stämmer väl med det samlade resultatet. Samtidigt är jag lite överraskad av samstämmigheten, jag uppfattar inte några tydliga skiljelinjer, annat än sådant som enklast kan förklaras av frågornas otydlighet.

Om jag ska våga mig på en sammanfattning så ger resultatet en vink om att det inom skrået finns en tydlig bild av vad en informationsarkitekt arbetar med. Jag vågar mig inte på en definition men vi har ringat in en bred roll runt data, information och vad det representerar i våra verksamheter. 

Du kanske läser in en annan tolkning av resultatet. Låt höra i så fall.

Tack till alla som var med och bidrog till detta och låt oss fortsätta dialogen. Vi planerar att ha fler träffar framöver. Du får gärna föreslå ämnen som du vill att vi tar upp och även former för träffar. Väl mött!

/Peter Tallungs, IRM

Nästa artikel i serien publiceras torsdag 11 november. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Modellmönster: Temporala mönster

Hur kan vi hantera tidsuppgifter i våra informationsmodeller? Det är en av de vanligaste utmaningarna, och kan samtidigt vara det stökigaste man har att göra med, som modellerare. Välkommen in i världen av temporala mönster! Det handlar om hur vi kan organisera informationen så att man kan ställa frågor på ett enkelt sätt, utan att man för den sakens skull trasslar ihop sin modell fullständigt.

Ibland räcker det helt enkelt med att bara hålla reda på vad som gäller just nu, att registrera ett snapshot av verkligheten. Det är enkelt och okomplicerat. Saker blir dock lite mer intressanta när vi inte bara vill veta tillståndet av världen just nu, utan även tillståndet för sex månader sedan. Riktigt jobbigt kan det bli om vi behöver veta vad vi för två månader sedan trodde om tillståndet för sex månader sedan. Välkommen in i världen av temporala mönster! Det handlar om hur vi kan organisera informationen så att man kan ställa frågor på ett enkelt sätt, utan att man för den sakens skull trasslar ihop sin modell fullständigt.

Mönster 1: Audit log

Det absolut enklaste sättet att registrera förändringar i data är med en så kallad audit log som finns i alla databaser. En audit log registrerar alla förändringar i en tabell.

Fördelen med en sådan logg är att den finns där färdig att använda, i varje fall om du har en databas. En annan fördel är att den inte komplicerar de vanliga frågorna mot databasen, som handlar om läget just nu och inte hur det var historiskt. Nackdelen med en audit log är att när du verkligen behöver få fram historiska data kräver det en större ansträngning. Du behöver manuellt gräva i en loggfil.

Med andra ord är en audit log är användbar då man bara behöver komma åt historiska data ibland och att det då inte behöver gå snabbt och enkelt.

Mönster 2: Giltighet

Det vanligaste mönstret man brukar använda för att hantera tidsaspekten, utöver audit log, är att märka dataposter med Giltighet, vanligen som Från och med- och Till och med-datum. Eller datum och tid i de fall man behöver den upplösningen. Man märker posten med den tidsperiod den anses vara giltig för. När man sedan ska komma åt poster måste man alltid ange vilket datum (eller datum och tid) man är intresserad av för att komma åt rätt poster.

Fördelen är att det är en enkel mekanism, både att bygga och använda. Nackdelen är att klienten, människan eller programvaran som läser uppgiften behöver känna till, och parameterisera frågan med, vilken tidpunkt den är intresserad av. Detta behöver den göra i alla lägen även om den nästan alltid bara är intresserad av nuläget.

Idealet är att kunna gömma och glömma den temporala aspekten tills man behöver den. Det kan åstadkommas på två sätt. Man kan automatiskt och standardmässigt parameterisera varje åtkomstmetod med aktuellt datum för frågetillfället. Eller man kan ha en vy som automatiskt ger den post som gäller vid frågetillfället. De båda metoderna gör egentligen samma sak, de förutsätter att man vill ha det som gäller just nu om man inte explicit anger en annan tidpunkt.

Mönster 3: Version

Ofta vill man tänka på företeelser som att de förekommer i versioner över tid. Det kan exempelvis vara kontrakt som genomgår en serie ändringar över tid. Du vill ibland betrakta varje version av kontraktet som det verkliga kontraktet, vilket det ju faktiskt också rent formellt är.

I den mer praktiska vardagen vill du kanske se det som flera versioner av ett och samma kontrakt.

Mönstret ger på så sätt en och samma företeelse två olika roller, å ena sidan en kontinuerlig över tid, å andra sidan de enskilda versionerna som fångar tillståndet hos objektet för en viss period i tiden. Så snart någon egenskap hos objektet ändras så får man en ny version.

Det kontinuerliga objektet är det man refererar till då man tänker på objektet över tiden. Det har endast de egenskaper som inte kan förändras över tid, framförallt id-begrepp, men även andra essentiella egenskaper.

Mönstret bör användas när verksamheten ser på objektet som att det förekommer i versioner i någon form. Jag har jobbat i försäkringsvärlden i många år. Det vi kallar ”försäkring”, men rätteligen heter ”försäkringsavtal”, har just detta mönster med versioner. Varje version är rent juridiskt ett eget avtal, men för kunden är det ”min bilförsäkring”, det vill säga en och samma försäkring över tid. Och därmed är det även så för alla som arbetar mot kunden, vilket inbegriper i stort sett alla aspekter av verksamheten.

Problemet med två tidsdimensioner

Ofta har vi två olika tidpunkter för en händelse:

1.   Verklig tidpunkt, det vill säga när händelsen inträffade.

2.   Registreringtidpunkt, det vill säga när vi fick reda på att händelsen inträffade.

Därmed har vi två tidsdimensioner att ta hänsyn till, och därmed två olika historier för ett objekt eller en egenskap hos ett objekt. Låt mig visa med ett exempel.

Säg att min timlön har förändrats enligt tabellen.

Registrerat datumVerkligt datumTimlön kr
1 jan1 jan100
15 feb15 feb100
25 feb15 feb100
25 feb25 feb100
14 mar15 feb100
15 mar1 jan100
15 mar15 feb200
15 mar25 feb200
Den verkliga historiken

Låt oss först titta på den verkliga historiken. Min timlön var 100 kronor fram till den 15 februari då den ökade till 200 kronor. Det är den verkliga historiken så som den är känd (registrerad) den 15 mars.

Om vi i stället tittar på den verkliga historiken så som den var känd den 15 februari så var min lön 100 kronor i timmen och några 200 kronor var det aldrig tal om. Varje enskild dag i registreringshistoriken har således en egen verklig historik. Historiken ändras allt eftersom vi får reda på att det som var sant inte längre är sant.

Den registrerade historiken

Min lön för den 25 februari var registrerad som 100 kronor fram till den 15 mars då den blev registrerad som 200 kronor. Registreringshistoriken talar om hur vår kunskap om en viss dag förändras. Varje dag i den verkliga historiken har på så sätt en egen registrerad historik.

Det här var väl inte så krångligt, tänker du kanske. Men vänta bara…

Registrerat datum Verkligt datum Timlön kr
1 jan1 jan100
15 feb15 feb100
25 feb15 feb100
25 feb25 feb100
14 mar15 feb100
15 mar1 jan100
15 mar15 feb200
15 mar25 feb200
26 mar25 feb200
4 apr1 jan100
4 apr14 feb100
4 apr15 feb250
4 apr25 feb250

Tänk att vi den 4 april får en korrigering som säger att lönen den 15 februari i stället höjdes till 250 kronor.

Det är sånt här som får en analytiker att vilja dunka huvudet i väggen! Men låt oss se hur man kan förstå det hela.

Om vi återigen tar fasta att vi har att göra med två olika tidsdimensioner så brukar det klarna för mig.

Den verkliga historiken, som den är registrerad den 4 april, säger att min timlön var 100 kronor från den 1 januari och höjdes till 250 kronor den 15 februari. En lön på 200 kronor förekom aldrig, för den var inte sann.  

Den registrerade historiken säger att timlönen för den 25 februari var 100 kronor och att den höjdes till 200 kronor den 15 mars.

Hur kan vi hantera detta? Låt oss titta på några modellmönster för att hantera situationer med två parallella tidsdimensioner.

Mönster 4: Både verkligt och registrerat datum i audit log

Ett sätt att göra det enkelt för sig är att helt enkelt logga alla ändringar i audit log och överlåta problemet till den som vill läsa ut och analysera tidsförloppet. Det är rätt lösning i det fall att det är sällan annat än aktuell lön är intressant.

Mönster 5: Verklig tid-modellen

Vi hanterar bara verklig tid i modellen. För de fall vi bara är intresserade av hur saker och ting har ändrats över tiden i verkligheten men inte bryr oss om när vi fick kunskap om händelserna. Det är rätt val i många fall, till exempel för en kunds adress.

Mönster 6: Registrerad tid-modellen

Vi hanterar bara registrerad tid i modellen. För de fall då själva registreringen är en händelse som styr annat och därmed är viktig att hålla reda på.

Exempel: Vi skapar fakturor automatiskt baserade på tillstånd hos objekt. Det är då viktigt att kunna spåra hur en faktura beräknats. Vi behöver därför hålla reda på vad vi trodde om ett tillstånd vid den tidpunkten då fakturan producerades.

Ett alternativ är att i stället lagra alla de argument som användes när fakturan beräknades, tillsammans med fakturan.

Mönster 7: Bi-temporala-modellen

Den fulla lösningen med båda tids-dimensionerna. Den behövs sällan.

Problemet med uppdatering av temporala poster är att det är stökigt att tillåta ändring av temporala poster, exempelvis en post som säger att en anställd har en lön från ett visst datum. En ändring kan omfatta varje möjlig kombination av startdatum, slutdatum och lön. Ett gränssnitt för detta kräver många regler som styr vad som går att göra och vad det får för effekter. Vi behöver därför förenkla. Låt oss titta på två mönster för detta.

Mönster 8: Tillåt endast tillägg av poster, ej borttag eller ändringar

Alla ändringar hanteras som tillägg eller som en kombination av tillägg.

Mönster 9: Tillåt endast uppdateringar som gäller från och med idag

De enda uppdateringar som tillåts är de som gäller från och med idag. Retroaktiva uppdateringar tillåts inte. 

Som sagt, detta är ett jobbigt område. Det kan vi inte komma ifrån. Men jag hoppas att vi genom dessa mönster har fått lite bättre grepp om vilka alternativ som står till buds.

Även i denna artikel har jag inspirerats från vad jag hittat i Martin Fowlers bok ”Analysis Patterns” från 1997. Boken är, som jag nu flera gånger tjatat om, en dold skatt vad gäller modellmönster för oss informationsmodellerare.

Det här var sista artikeln om modellmönster, åtminstone för nu. Men kanske har du några modelleringsproblem som du skulle vilja belysa, eller något mönster som du brukar använda jag vi inte tagit upp. Låt höra i så fall.

Nästa artikel handlar om informationsarkitekten, vad rollen kan innehålla och inte innehålla. Vi bjöd in till en frukostträff den 15 oktober i år, där vi diskuterade ämnet. Vi röstade då på ett antal möjliga omfattningar för rollen. Jag kommer att presentera resultatet från röstningen och även försöka mig på en analys av detta.

/Peter Tallungs, IRM

Nästa artikel i serien publiceras torsdag 4 november. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Modellmönster: Observationer

Föregående artikel, ”Modellmönster: Mätningar”, handlade om att registrera mätningar av olika slag. ”Mätningar” är ett namn vi använder för kvantitativa observationer, det vill säga observationer vars resultat kan uttryckas som ett mätvärde. Denna artikel breddar temat till att omfatta alla typer av observationer. Ty kvalitativa observationer blir viktigare i samma takt som kvantitativa.

Exemplen nedan är från sjukvården där man ju gör en stor mängd observationer. Men samma mönster är tillämpliga på alla sammanhang där man registrerar observationer av olika slag.

Mönster 1: Observationer

Precis som det finns många kvantitativa utsagor vi kan göra om en patient finns det också kvalitativa utsagor. Som blodgrupp, kön och om patienten har diabetes eller inte. Vi kan se dessa som Kategoriobservationer eftersom resultatet av observationen, det Observerade värdet, alltid representerar en kategori av något slag, till exempel alla med blodgrupp A, alla kvinnor eller alla som inte har diabetes.

Vi kan utöka mönstret från föregående artikeln, ”Modellmönster: Mätningar”, till att omfatta även sådana observationer.
Kön blir ett Kategorifenomen samt Man, Kvinna, och eventuellt andra kön, blir Observerbara värden. Blodgrupp blir ett annat kategorifenomen med de observerbara värdena A, B, AB och 0. Diabetes blir en tredje typ av kategorifenomen med de observerbara värdena Positiv och Negativ.

Om diagrammets layout

Innan vi går till nästa mönster vill jag ta upp detta med layouten i diagrammet ovan. Till höger har vi regler för observationer, det vill säga vilka fenomen som kan observeras, hur de är indelade i två typer samt vilka värden och måttenheter som gäller för varje fenomen. Till vänster har vi de observationer som gjorts. När något ändras till höger, till exempel att man inför underblodgrupperna A1 och A2 i vad som går att registrera, innebär det att verksamheten konfigureras. När något ändras till vänster, det vill säga att en observation görs, opereras verksamheten.

Jag har i flera av de tidigare artiklarna om modellmönster, till exempel den föregående artikeln ”Modellmönster: Mätningar”, skrivit om hur värdefullt det är att dela in ett modelldiagram (eller mer vanligt, en del av ett diagram, ett särskilt ämnesområde) på detta sätt. Det här är ett annat bra exempel.

Men vi har en dimension till hos modellen ovan som avspeglas i diagrammet. Entiteterna bildar två horisontella rader i diagrammet, en för observationer av kategorifenomen och en för kvantitativa fenomen. Vi ser således två dimensioner i den här delen av verksamheten och avspeglar det i diagrammet.

Spegla verksamheten i diagrammens struktur

Jag tycker att det är intressant hur vi kan strukturerar våra diagram för att avspegla de mönster vi vill se i verksamheten. Vi kan hitta mönster i den mentala strukturen hos de företeelser som verksamheten hanterar som vi på så sätt kan representera och kommunicera. Det är egentligen det enda sätt vi kan få grepp om och hantera det komplicerade maskineri en verksamhet faktiskt är. Jag har inte sett den aspekten av vårt arbete som informationsmodellerare beskrivet eller diskuterat någonstans. Det har varit och är fortfarande, märkligt nog, ignorerat i hela branschen trots att det är en så central aspekt av vårt yrkeskunnande. Hitta och förmedla användbara mönster är väl allt vi gör ungefär. Desto mer angeläget att vi inom vår yrkesgrupp tar upp och diskuterar och tillsammans utvecklar hur vi kan rita och strukturera våra diagram. Jag tror att det har en stor betydelse för hur bra våra modeller blir och är därmed en viktig faktor för hur vi lyckas som individer, team och profession.

Jag kommer att komma in lite djupare på detta ämne i kommande artiklar vilka mer direkt kommer att handla om hur vi kan gestalta våra modeller.

Mönster 2: Indikationer

Vissa fenomen indikerar andra fenomen. Exempel: Viktminskning indikerar Diabetes. Vi kan utöka regelplanet i modellen med sådan kunskap.

Mönster 3: Observationsmetod

När man registrerar en observation kan det vara mer än resultatet som är viktigt. Man vill gärna veta vilken observationsmetod som användes, då det kan förklara ett märkligt resultat eller användas för att bedöma noggrannheten i observationen. Vi lägger därför till observationsmetod i diagrammet.

Mönster 4: Tid för observationen och Tid för registreringen

En observation har en tid för när den gjordes och en tid för när den registrerades. Tiden för observationen kan vara en Tidpunkt eller en Tidsperiod. Tiden för registreringen kan dock bara vara en tidpunkt.

Det gäller de flesta händelser, att de har separata tider för när de inträffade och när de registrerades.

Jag kommer att komma in på detta med temporala mönster i en kommande artikel.  

Mönster 5: Ogiltig observation

Vi kan inte komma ifrån att vissa observationer förklaras ogiltiga genom att en eller flera nya observationer motsäger den första.

Vi kanske har regler som säger att registreringen av en observation aldrig får raderas. Då får vi i stället klassa om observationen som ogiltig och länka den till den eller de nya observationer som motiverar detta.

Var kommer dessa mönster från?

Även denna artikel, precis som den föregående om mätningar, har jag inspirerats från vad jag hittat i Martin Fowlers bok ”Analysis Patterns” från 1997. Boken är, som jag tidigare nämnt, en dold skatt, lite av en apokryfisk skrift, vad gäller modellmönster. Som härmed återupptäcks hoppas jag.

/Peter Tallungs, IRM 

Nästa artikel i serien publiceras torsdag 27 oktober. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Modellmönster: Planering

De flesta organisationer behöver planera sin verksamhet samt följa upp planerna. Till detta har de diverse informationssystem. I detta sammanhang finns det lite mer att tänka på än man kanske till förstone tror.

I denna artikel tar jag avstamp i det enklaste och vanligaste mönstret, Planerad – Pågående – Genomförd, och förklarar varför det inte alltid fungerar så bra. Jag ger i de senare mönstren i artikeln ett alternativt sätt att se på planer.

nster 1: Uppgift

Beståndsdelarna i en plan är de uppgifter som vi människor planerar och genomför. En uppgift kan definieras som en avgränsad enhet av arbete som man planerat att göra, gör just nu eller har gjort. En uppgift kan ha ett antal egenskaper baserat på vem, vad, var och när.

Mönster 2: Planerad – Pågående – Genomförd

När vi gör planer och när vi övervakar planer behöver vi ta hänsyn till de tillstånd en uppgift kan ha. Det är vanligt att man har tillstånden Planerad, Pågående och Genomförd, eller motsvarande.

Det här är ett enkelt och mycket vanligt mönster, som kan verka naturligt och självklart. Men Martin Fowler argumenterar i sin bok ”Analysis Patterns” för att mönstret egentligen inte är särskilt realistisk, det vill säga att den är en teoretisk modell som rimmar dåligt med hur vi gör i verkligheten.

Låt oss titta närmare på svagheterna med detta mönster.

Planering kan sägas bestå av tidsplanering och resursplanering. Dessa kan ske i vilken ordning som helst. Men många uppgifter sätts igång utan formella beslut. De har då varken tids- eller resursplanerats. Vi kan ju förstås alltid hävda att de planeras precis i det ögonblick de startas, men det blir då mer en teoretisk styrmodell än en korrekt bild av verkligheten. Ett annat problem med detta enkla mönster är att det inte tar höjd för att många aktiviteter sätts igång innan man har alla resurser som kommer att behövas. Man planerar att anskaffa det som behövs under vägen.

Hur ska vi då göra? Jo, antingen kan vi söka ett mönster som bättre avspeglar verkligheten. Eller så kan vi använda detta enkla linjära mönster. Men då bör vi i alla fall känna till och närmare förstå dess svagheter. I annat fall får vi svårt att hantera svagheterna när de ger sig till känna.

Mönster 3: Föreslagen uppgift och Implementerad uppgift

Ett helt annat sätt att se på uppgifter, ett sätt som enligt min mening stämmer bättre med verkligheten, är att de finns som två olika företeelser, Föreslagen uppgift och Implementerad uppgift.

En föreslagen uppgift finns bara i en plan som ett förslag. Där kan den resurs- och tidsplaneras i godtycklig ordning. Uppgiften har ingen verklig existens. Först om och när den påbörjas får den en verklig existens, den är då implementerad, det vill säga att uppgiften pågår eller är redan genomförd. Vi bör då se den implementerade uppgiften som en helt egen företeelse, och inte som en föreslagen uppgift som ändrat tillstånd.

Det gör att vi kan registrera skillnader mellan plan och genomförande. Skillnad i tid sker nästan utan undantag, men egentligen kan precis alla egenskaper ändras från plan till genomförande. För att få flexibilitet bör länken mellan föreslagen och implementerad uppgift vara icke-obligatorisk.

Planering är viktigt, men planen är bara en hypotes som snabbt kan bli överspelad. När verkligheten träffar våra planer blir ibland även de bästa planerna lagda på hyllan, och många andra saker händer utan att vara planerade.

En allmän reflektion är följande: Det som vi i förstone ser som två olika tillstånd hos en och samma företeelse, kan ibland förstås bättre som om vi ser det som separata företeelser med olika identiteter och egenskaper.

Frågorna man kritiskt bör ställa sig är följande:

  1. Följer tillstånden regelmässigt på varandra, inte bara i vår ideala föreställningsvärld utan även i verkligheten?
  2. Förblir de väsentliga egenskaperna desamma före och efter tillståndsövergången?
  3. Är det sällsynt att en företeelse i första tillståndet splittras i flera företeelser i andra tillståndet (som att en planerad uppgift implementeras som flera uppgifter), eller tvärtom, att flera företeelser i första tillståndet slås samman till en enda företeelse i andra tillståndet (som att flera planerade uppgifter genomförs som en uppgift)?

Mönster 4: Genomförd uppgift och Annullerad uppgift

Så här långt har vi undersökt hur uppgifter föreslås och hur de påbörjas, men ännu inte om de genomförs.

Ett problem är att vi i många sammanhang inte kan säga med säkerhet om en uppgift var en framgång eller ett misslyckande. Det är ofta endast en subjektiv bedömning, och kan kanske göras först långt i efterhand.

Därför tar vi i detta mönster bara med två möjliga utgångar: avslut eller nedläggning, det vill säga vi får Genomförd uppgift och Annullerad uppgift. Observera att faktat att en uppgift är genomförd inte säger något om resultatet, det vill säga om den lyckades eller misslyckades.

Besltet om att annullera en uppgift kan komma antingen före eller efter att den påbörjats. Att annullera en föreslagen uppgift är detsamma som att besluta att inte påbörja.


Mönster 5: Suspension

Vi kan pausa en uppgift med avsikt att fortsätta den senare. Tisperioden för suspensionen kan ha en öppen sluttid, vi vet inte hur länge en pågående paus kommer att vara.

Om supensionens sluttiden är passerad är den inte längre suspenderad utan aktiv. En uppgift är suspenderad om den har en för ögonblicket gällande Suspension.

Både föreslagna och implementerade uppgifter kan vara suspenderade. Att suspendera en föreslagen uppgift är samma som att senarelägga starten.


Mönster 6: Plan

En Plan är i sin enklaste form en samling uppgifter länkade i någon slags sekvens. Sekvensen uttrycker vanligen någon form av beroende, att en uppgift inte kan påbörjas förrän en annan är slutförd.


Mönster 7: Interagerar planer

I många situationer samverkar eller interagerar flera planer med varandra. En och samma uppgift ingår i flera planer. Ett beroende mellan två uppgifter gäller endast inom en viss plan.

Var kommer dess mönster ifrån?

Dessa mönster härstammar från Martin Fowlers bok ”Analysis Patterns”. Som jag tidigare har skrivit är det en orättvist bortglömd skatt, som jag gärna vill lyfta fram.

/Peter Tallungs, IRM

Modellmönster: Ekonomisk redovisning – del 2: Posteringsregler

En viktig del av informationshanteringen i en verksamhet handlar om att följa hur pengar rör sig genom verksamheten och hur pengar intjänas och spenderas. I två artiklar går jag igenom mönster för ekonomisk redovisning. De mönster som jag tar upp har egentligen en bredare tillämpning än vad artikelrubriken säger. Överallt där man behöver hålla reda på tillgångar i olika poster som till exempel lagerhantering är det användbart att tänka i ”konton”, ”posteringar” och ”transaktioner”.

I den föregående artikeln, Ekonomisk redovisning – del 1: Konto och transaktioner, gick jag igenom sex mönster för konton och posteringar. I denna artikel presenterar jag sju mönster på hur man kan automatisera posteringar med hjälp av regler.

/Peter Tallungs, IRM, 2021-09-30

Mönster 1: Posteringsregel med faktor

Låt oss ta som exempel att varje gång pengar kommer in på ditt inkomstkonto lägger du 30 procent av beloppet på ditt skattekonto (som är ett minneskonto). Du kan då ha en Posteringsregel som gör detta automatiskt.

En posteringsregel är en regel som bevakar ett visst konto. När regeln upptäcker en postering till kontot så skapar regeln en annan postering till ett förutbestämt annat konto. Det konto som bevakas kallas Triggerkonto. Den händelse som ska trigga åtgärden, det vill säga i detta fall en postering till triggerkontot kallas Triggerhändelse. Det andra kontot som ska ta emot posteringen kallas Målkonto.

Om beloppet som ska posteras till målkontot är, som i detta fall, en procentsats av beloppet i triggerhändelsen, räcker det med att regeln uttrycks som en faktor.

Mönster 2: Posteringsregel med särskild beräkningsmetod


Om vi behöver mer flexibla regler för att beräkna vad som ska hända behöver varje regel ha sin egen beräkningsmetod.

Reversering av posteringar

Om vi har gjort en felaktig postering kan vi vanligen inte bara radera den, för den kan ha lett till en utförd betalning eller en skickad faktura. Vi får i stället ta bort effekterna av den felaktiga posteringen genom att göra en ny omvänd postering, det vill säga en identisk postering fast med omvänt tecken. Därför måste varje posteringsregel kunna beordras att göra en postering som är omvänd.

Automatiserade kontosystem

I en del kontosystem är samtliga transaktioner genererade av posteringsregler. Då har man särskilda inkonton där man registrerar initiala posteringar från världen utanför. Alla andra posteringar sker automatiskt genom triggning av posteringsregler. Därmed automatiseras en stor del av kontohanteringen. Då är transaktioner inte lika nödvändiga för att spåra vad som hänt, men det kan ändå vara bra att ha registrerade transaktioner. Det förenklar hanteringen av reglerna.

När ska posteringsreglerna exekveras?

Det finns olika tänkbara modeller som man kan tillämpa i ett kontosystem för när, var och hur posteringsregler exekveras i programkod. Varje modell har sina styrkor och svagheter.

Det kan ske direkt när händelsen inträffar (vilket kallas Eager Firing inom programmerarvärlden), vid bestämda tillfällen eller först när någon efterfrågar kontoställningen (vilket kallas Backward Chained Firing). Varje modell har styrkor och svagheter. Det handlar mest om prestanda, det vill säga den tid det tar att exekvera reglerna, samt om när vi vill hantera fel. Eager Firing låter oss få felen tidigt. De andra modellerna ger oss större valfrihet när vi vill hantera felen, men till priset av större komplexitet.

Mönster 3: En posteringsregel för en grupp av konton

Det är vanligare att en posteringsregel gäller för en grupp av konton än för ett enstaka konto. Vi kan hantera det på två sätt.

  1. Genom att införa ett regelplan i modellen med kontotyper till vilka vi kan knyta posteringsreglerna.
  2. Genom att lägga posteringsregeln på ett summakonto. Då aktiveras regeln när en postering görs till ett underkonto (eller till kontot självt om det kan ta emot posteringar.) Regelns målkonto kan också vara ett summakonto, men tolkningen av regeln kommer i så fall att skapa postering till lämpligt underkonto.

Mönster 4: Posteringsregler med separata metoder

Man kan behöva ha separata metoder för att beräkna belopp, bestämma målkonto med mera. Då kan man ha fördefinierade metoder för olika ändamål. En regel blir då sammansatt av ett antal fördefinierade metoder.

Mönster 5: Konteringspraxis


Om vi har många olika konton som sitter ihop i ett nätverk av posteringsregler blir det hela oöverskådligt.

Vi behöver ett sätt att bryta ner nätverket av regler i lagom stora bitar. Till exempel kan varje typ av kund ha en särskild faktureringsprocess, och därmed ett nätverk av konton och posteringsregler som skiljer sig lite grand från en annan typ av kund.

Ett särskilt nätverk av konton och posteringsregler är en Konteringspraxis. Konceptuellt är en konteringspraxis helt enkelt en specifik uppsättning konteringsregler.

Mönster 6: Orsak till en postering

Det är ofta viktigt att kunna spåra varför en viss postering har gjorts och varför den har den form den har. Till exempel om en kund ringer och frågar om en viss post på en faktura, så behöver vi kunna se vilka posteringar som ledde fram till posten och vilken regel som skapade transaktionen.

Detta mönster låter varje transaktion minnas vilken post,,,,eringsregel som skapade den och vilka posteringar som var argument till transaktionen.

Mönster 7: Konton för lagerhantering

Kontomodellen passar bra för lagerhantering.

Vi kan skapa ett ”tillgångskonto” för varje lagersaldo (Ett Lagersaldo är att ett visst antal av en viss vara finns på ett visst lager). När vi flyttar en vara från ett lager till ett annat skapar vi en Lagertransaktion. Vi kan också hantera kundordar som ”posteringar till utgiftskonton” och leverantörsordrar som ”posteringar till inkomstkonton”. Vi kan också ha ”summakonton” för alla varor av samma varugrupp i ett lager och för en viss lagervara totalt i alla lager, eller för orderstocken. 

Varifrån kommer dessa mönster?

Många mönster i denna artikel och den förra utgår från vad jag hittat i Martin Fowlers bok Analysis Patterns från 1997. Boken är en dold skatt vad gäller modellmönster för informationsmodellering. Martin Fowler skrev boken för programmerare, vilket jag tror är orsaken till att den är så gott som okänd bland informationsmodellerare. Fast den är inte särskilt känd bland programmerare heller. Hans modellmönster förtjänar att lyftas fram och komma till nytta. Jag vill på detta sätt bidra till detta.

Vilka är dina erfarenheter? Har du arbetat med något av dessa mönster eller liknande? Kanske har du andra mönster att dela med dig av?

/Peter Tallungs, IRM

Nästa artikel i serien publiceras torsdag 30 september. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Modellmönster: Ekonomisk redovisning – del 1: Konto och transaktioner

En viktig del av informationshanteringen i en verksamhet handlar om att följa hur pengar rör sig genom verksamheten och hur pengar intjänas och spenderas. I två artiklar går jag igenom mönster för ekonomisk redovisning. De mönster som jag tar upp har egentligen en bredare tillämpning än vad artikelrubriken säger. Överallt där man behöver hålla reda på tillgångar i olika poster som till exempel lagerhantering är det användbart att tänka i ”konton”, ”posteringar” och ”transaktioner”.

Mönster 1: Konto och Postering

Den grundläggande idén bakom ekonomisk redovisning är att man har olika högar med pengar för olika syften, och att vi registrerar hur pengar flyttas mellan högarna. Vi kallar en sådan hög för Konto.

Det behöver inte handla om pengar. Vilka resurser som helst kan hanteras, och hanteras i olika verksamheter, på samma sätt, som till exempel lagervaror eller poäng av olika slag.

I de flesta sammanhang vill vi inte bara hålla reda på hur mycket det finns på kontot utan även varje förändring som påverkat innehållet.

Ett konto håller saker av värde – pengar eller gods.

Pengar, eller gods, kan endast läggas till eller tas bort genom att göra en Postering. Posteringarna utgör tillsammans en historik av alla förändringar på kontot. Beloppets tecken (plus eller minus) anger om posteringen är en debitering eller kreditering (insättning eller uttag).

Saldo, hur mycket det finns på kontot vid ett givet tillfälle, är en nettoeffekt av samtliga posteringar på kontot fram till den valda tidpunkten. Regeln innebär att saldot beräknas varje gång den efterfrågas. Det hindrar inte att föregående saldo lagras internt från gång till gång för att snabba upp beräkningen.

Med detta mönster kan man också se hur saldot har ändrats under en tidsperiod. Ett Kontoutdrag är en lista på samtliga posteringar som gjorts under en tidsperiod.

Lägg märke till att man vanligen håller reda på två tidpunkter för en postering. Den tidpunkten då posteringen gäller, samt tidpunkten då posteringen registrerades.

Det är ofta så att vi behöver veta både tidpunkten för en händelse i verkligheten och tidpunkten för vår kunskap om denna händelse.

Mönster 2: Transaktion

En kontoändring innebär vanligen att ett belopp flyttas från ett konto till ett annat. Det räcker oftast inte med att registrera att beloppet har kommit eller gått utan vi måste också hålla reda på varifrån och varthän.

En Transaktion länkar explicit ihop ett uttag från ett konto med en insättning på ett annat. Att två posteringar hör samman på detta sätt visar på en viktig bokföringsprincip. Pengar, eller gods, uppstår aldrig ur intet och de försvinner aldrig, de bara flyttas runt mellan olika konton.

I bokföringssystem strävar vi efter att få kontona balanserade, det vill säga att få saldo lika med noll vid en viss tidpunkt i affärscykeln (bokslutet).

Med hjälp av explicita transaktioner bygger vi in denna kontroll i själva strukturen. Det gör det lättare att hitta läckor i systemet.

Märk att jag satt en tvåa vid relationen från Transaktion till Postering, detta för att markera att en transaktion måste omfatta precis två posteringar, varken mer eller mindre. Fast man kan egentligen mycket väl tänka sig transaktioner som omfattar ett godtyckligt antal uttag och insättningar, fast alltid minst två, bara summan blir noll. I själva verket är den tvåvärda transaktionen endast ett specialfall av den flervärda.

Mönster 3: Transaktion utan explicita posteringar

I kontosystem med endast tvåvärda transaktioner behöver man egentligen inte en särskild entitet för posteringar, utan kan förenkla modellen enligt följande.


Mönster 4: Summakonto och detaljkonton

I kontosystem är det ofta användbart att gruppera konton till summakonton. Om jag till exempel har separata konton för olika utgifter så vill jag kanske gruppera vissa som personliga utgifter och andra som affärsutgifter.

Posteringar kan då endast göras mot detaljkonton. Ett summakonto har ändå transaktioner genom sina underkonton. Summakonton kan i sin tur grupperas i mer övergripande summakonton.

Mönster 5: Gruppering av konton utan
explicita summakonton

Det är vanligt att dela upp konton i två typer; summakonton och detaljkonton, men egentligen är det inte nödvändigt. I detta mönster kan alla konton ha underkonton.

Mönster 6: Minneskonto

Ibland behöver man reservera pengar för ett visst ändamål, till exempel skatt. Då kan man ha ett konto där man löpande registrerar hur mycket man reserverar, ett så kallat Minneskonto. Då vet jag hur mycket av de pengar jag har som jag verkligen kan disponera.

Observera att när jag reserverar pengar på ett minneskonto så flyttas inte pengar. Det är bara en notering om hur mycket jag är skyldig. På så sätt innehåller ett minneskonto pengar fast inte ”riktiga” pengar. Det innebär att dubbel bokföring inte är nödvändig, det vill säga att en postering till minneskontot inte behöver speglas av en postering från ett annat konto. Det går att öka skulden i skattekontot utan att minska tillgångarna någon annanstans.

Det finns två sätt att hantera detta:

  1. Skapa ett motkonto. På detta sätt blir principen om dubbel bokföring genomgående för alla konton.
  2. Undanta minneskonto från regeln om att en transaktion alltid ska balansera. Tvärtom måste det då finnas en regel som säger att transaktioner mot minneskonton inte får balansera. I annat fall läcker verkliga pengar till minneskontot!

Fortsättning i nästa artikel

I nästa artikel tar jag upp hur man kan styra posteringar med hjälp av posteringsregler. 

/Peter Tallungs, IRM

Nästa artikel i serien publiceras torsdag 30 september. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Modellmönster: Produkt – del 1: Produktstrukturer

De flesta verksamheter erbjuder sina kunder produkter eller tjänster av något slag. Runt produkter och tjänster finns det många företeelser som behöver modelleras, definieras och benämnas. Ämnesområdet Produkt är i en del verksamheter så centralt att det finns informationsmodellerare som kallar sig för produktmodellerare. Jag går i denna, och följande, artikel igenom några centrala begrepp och mönster inom produktområdet.

Produkt eller tjänst?

Termen ”produkt” kan stå för olika saker. Det gemensamma är att det är något som en verksamhet kan tillhandahålla till sina kunder. I den ursprungliga betydelsen är det något materiellt, till skillnad från tjänst som är den immateriella motsvarigheten. Men det har blivit vanligt att man benämner även tjänster som produkter. Och eftersom de mönster jag kommer presenterar här fungerar lika bra för materiella som immateriella produkter så gör jag här ingen skillnad.

Verksamheter har ofta problem med sin produktflora

Jag upplever att man i många verksamheter har problem med en oöverskådlig produktflora och svårt att ens komma igång med att bringa ordning. Man har ofta stupat redan på tröskeln, redan när man försökt bestämma vad en ”produkt” är. Kanske har man ett par tusen saker registrerade som man säljer, men frågan blir då: Är det verkligen produkter? En del varor man erbjuder är kanske paketeringar av flera olika produkter. Och andra företeelser man hanterar är kanske bara komponenter som man sätter ihop produkter av. Många produkter är så lika varandra så man kanske borde se dem som varianter av en och samma produkt. Och några är små förbättringar av tidigare produkter, så man kanske borde se dem som versioner av en och samma produkt. Hur kan man bestämma vad som är vad, och hur ska man hålla reda på det?

Det brukar bli många åsikter, och jag har upplevt att många verksamheter inte har kunnat reda ut detta. Man har helt enkelt gett upp alla försök att bringa ordning i produktfloran, med resultatet att det blivit svårt att analysera och följa produkters beteenden över tid.

Men det är egentligen inte så svårt. Vi bör bara vässa våra analysverktyg en smula och gå metodiskt tillväga, begrepp för begrepp. Där har vi informationsarkitekter en viktig uppgift att fylla.

Om begreppet ”produkt”

Ett fruktbart sätt att se på begreppet produkt är att det är någonting man kan erbjuda kunder som en enhet.

”Kan erbjuda” är viktigt för det är en produkt, även om det är något man ännu inte har erbjudit någon kund. Eller av olika omständigheter aldrig kommer att erbjuda en kund.

Jag vill inte skriva ”sälja” för jag tycker inte att det är någon egentlig skillnad i avseendet om eller hur vi får ersättning för det vi erbjuder. En produkt kan vara helt gratis, det är likafullt en produkt.

”Som en enhet” är viktigt, ty mycket av det vi kan erbjuda kan vi inte erbjuda i sig självt utan bara som en komponent av något annat. Om jag säljer bilar så erbjuder jag kanske röd lack. Men inte som en självständig enhet. Du kan inte köpa röd lack av mig utan att den sitter på en bil. Du kan bara få röd lack som en komponent till bilen du köper. Men jag vill ju kanske ändå kunna följa upp hur röd lack säljer.

Det betyder inte att jag alltid måste sälja en produkt som en egen enhet. Jag kan paketera flera produkter så att de tillsammans blir en paketering. Du kanske kan köpa ett paket av mig med en isskrapa plus rattmuff. Det avgörande för om det är en produkt är att jag kan erbjuda den för sig själv.

Men ”produkt” är långt ifrån det enda begreppet vi behöver definiera. Låt oss gå vidare. Det har för övrigt ingen betydelse om man benämner produkt för ”artikel” eller ”vara”. Frågeställningarna och lösningarna blir precis desamma.

Mönster 1: Produktindivid

Vi behöver begreppsmässigt skilja de individuella exemplaren av en produkt från det som vi i förra stycket kallade för produkt. Ett namn som förekommer är ”produktindivid”, ”produktförekomst”, ”produktinstans” eller ”produktexemplar”.

Det kan finnas noll, en eller flera produktindivider av en och samma produkt. En produktindivid är alltid en individ av en viss produkt och har ett existentiellt beroende till denna, som jag uttrycker med en romb i änden på relationslinjen. Det uttrycker att produktindividen inte kan existera oberoende av sin produkt och att den heller aldrig kan ändras så den blir en individ av en annan produkt.

Produkt ligger i ett regelplan i förhållande till produktindivid, vilket betyder att när vi lägger upp en ny produkt kan det i detta sammanhang ses som en konfigurering av verksamheten. Vi bestämmer vad vi kan erbjuda. Det har inte hänt något operativt bara för att vi lägger upp en ny produkt, vi har inte producerat något, det betyder bara att vi bestämt att det finns ett visst erbjudande. Det är inte förrän det skapas ett exemplar av den produkten, en produktindivid, som det händer något operativt, som någon form av produktion har skett.

Resonemanget är precis lika för tjänster, det vill säga immateriella produkter. Ett försäkringsbolag erbjuder dig en hemförsäkring (produkt). Du tecknar en sådan, och avtalet får ett försäkringsnummer (en produktindivid). Den enda skillnaden är att en immateriell produkt (tjänst) uppstår genom någon form av performativ (utförande) akt.

Mönster 2: Produkttyp

Man delar vanligen in produkter efter olika kriterier i produkttyper, produktgrupper etcetera. Jag har inte tagit med det i diagrammet. Om vi fokuserar på själva produktadministrationen som en verksamhetsförmåga kommer man kanske vilja se entiteten produkt som tillhörande ett operativt plan. När man definierar en ny produkt innebär det just i detta sammanhang en operativ handling. Hur man delar in sin produktkatalog i produkttyper och produktgrupper innebär med det perspektivet att man konfigurerar verksamheten i fråga.

Med detta vill jag bara visa att vad man ser som operativt är inget absolut utan beror på sammanhanget. Att något sådant kan hända vid ett perspektivskifte kan kännas flyktigt och osäkert för en del. Men jag anser att det är viktigt att veta att olika kontext ger olika perspektiv och att vilken kontext man har kan därmed vara avgörande för modellen.   

Observera att jag här har valt att Produkt inte har ett existentiellt beroende till Produkttyp (det vill säga ingen romb i änden). Jag ser produkttyp som något som vanligen är en ganska flyktig indelning av produkter. Man kan ju ofta ändra typningen av produkter, det vill säga hur man delar in produkter i olika produkttyper, utan att det därför blir nya produkter. Man kan förstås hävda motsatsen för sin specifika verksamhet, men jag tror det är ovanligt. Det här är en bedömning jag gör, och det kan variera från verksamhet till verksamhet. Den kritiska frågan är: Kan en produkt ändra produkttyp och ändå ses som samma produkt. Om svaret är ja: ingen romb, om svaret är nej: romb.

Mönster 3: Produktvariant

En produkt kan finnas i flera varianter. Det kan vara olika färger eller andra smärre skillnader, men att man ändå vill se det som en och samma produkt. Vad som är olika produkter och vad som är flera varianter av samma produkt är ett val man gör i verksamheten.

Jag har varit med om att någon i en verksamhet har sagt att de egentligen har bara en produkt, men vi levererar den i många varianter, medan någon annan vill se det som att man har väldigt många produkter. Man behöver komma fram till hur man vill se det och vilka egenskaper som ska skilja för att man ska betrakta två artiklar som varianter av samma produkt. Det har mycket med marknadsföring och försäljning att göra, det vill säga hur man vill presentera varorna för kunderna.

Det finns alltid minst en variant av varje produkt. En produktindivid blir alltid en förekomst av en specifik produktvariant.

Mönster 4: Produktvarianttyp

Det finns ofta ett behov av att kategorisera även produktvarianterna. Om man säljer till exempel hushållsapparater kan det vara färger eller elanslutning. Det finns 14 olika standarder för elkontakter världen över. I vissa verksamheter har varje produkttyp sina egna varianttyper, i andra kan de vara gemensamma tvärs över hela produktkatalogen.

Mönster 5: Produktversion

Produkter förändras över tid. Man behöver hålla reda på vilken version en produktindivid är av. Inte bara produkter har versioner utan även produktvarianter. På så sätt får vi två parallella stråk i vår produktstruktur. En som är mer beständig över tid, och en annan som fångar hur en och samma produkt utvecklas över tiden.

Men hur bestämmer man när en viss vara ska ses som en ny produkt eller en ny version av en befintlig produkt? frågar sig den skarpsinnige. En riktlinje brukar vara att om ändringen är så pass framträdande att kunden uppfattar det som en ny produkt ska det vara en ny produkt annars är det en endast en ny version av den befintliga. Ett klädföretag jag jobbade för sa så här: ”Om en söm inte visar sig hålla i längden åtgärdar vi det. Då blir det en ny version. Kunden märker inte detta vid köpet, men vi vill veta vilken version en viss produktindivid är av när vi får klagomål. Om det visar sig att en ficka sitter fel placerad på en skjorta, och vi åtgärdar det, då blir det en ny produkt för kunden ser skillnaden.”

Mönster 6: Produktkomponent

Ofta utvecklar man komponenter som man kan använda för att bygga ihop olika produkter. En komponent kan definitionsmässigt inte säljas separat som en egen enhet, i så fall skulle den vara en produkt i sin egen rätt. Komponenter används inte bara i materiella produkter. Försäkringsbolag och finansiella verksamheter har ofta ett antal produktkomponenter vilka används till olika produkter.

Observera hur jag namnger och definierar den entitet som utgör många-till-många-relationen ”Produktkomponent i produktvariant”. Jag tycker att det är viktigt att vara strikt med att namnet, och definitionen avser en förekomst av entiteten. Det gör det lättare att förstå vad entiteten representerar. Man ser annars ofta att entiteten kallas Produktkonfiguration, men jag tycker att man bör vara konsekvent med att namnet på en entitet alltid ska vara namnet på en förekomst av entiteten. En förekomst av den entiteten är inte en fullständig konfiguration av en produkt utan endast en detalj av konfigurationen, nämligen just faktumet att en viss komponent används i en viss produktvariant.

Produktkomponenter har i likhet med produkter och produktvarianter sina typer, varianter och individer. Kanske behöver man också hålla reda på vilken version av en produktkomponent som ingår i en viss version av en produktvariant, och även vilken komponentindivid som ingår i vilken produktindivid.

Jag har i diagrammet tagit med följande:

  • Produktkonfigureringar på typnivå, det vill säga vilka typer av produktkomponenter som kan förekomma i vilka typer av produktvarianter.
  • Produktkonfigureringar på variantnivå, det vill säga vilka produktkomponenter som kan förekommer i vilka produkter.
  • Produktkonfigureringar på versionsnivå, det vill säga vilka versioner av komponenter som används i vilka versioner av produkter.
  • Produktkonfigureringar på individnivå, det vill säga vilket specifikt exemplar av en komponent som förekommer i vilket specifikt produktexemplar.

Layouten har stor betydelse

Lägg märke till den layout jag givit diagrammet, med entiteter i kolumner och rader. Själva strukturen och hur entiteterna är placerade i förhållande till varandra har stor betydelse då det skapar ordning och reda i begreppen och tankegången. Skillnaden mot om man placerar rutorna utan någon speciell tanke är helt avgörande för begripligheten.

Jag planerar att i senare artiklar ta upp sådant som gestaltning av modeller, hur man kan rita (och skriva) sina modeller på ett tydligare sätt så att de blir mer användbara.

/Peter Tallungs, IRM 

Nästa artikel i serien publiceras torsdag 9 september. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Modellmönster: Kundlivscykel – del 2: Livscykelhändelser

Detta är andra delen av två om en kundlivscykel, där vi tittar närmare på hur vi kan hantera de händelser som innebär att kunden byter status.

Mönster 1: Livscykelhändelser för kund

För att analysera och förstå rörelser i kundstocken behöver vi tydligt definiera och namnge vilka händelser som kan inträffa i en kunds livscykel och som innebär att en kund byter status, till exempel övergår från prospekt till aktuell kund. Man kan mena olika saker med händelser. Här har jag valt att bara se själva övergången, från ett tillstånd till ett annat, som en händelse. Det vill säga att jag här inte inkluderar den bakomliggande orsaken som orsakade tillståndsförändringen. Det gör modellen renare och tydligare och därmed mer användbar för analyser. Den bakomliggande händelsen som är orsaken till tillståndsövergången hanteras i nästa mönster i artikeln.

Jag har försökt att rita in varje möjlig tillståndsövergång, och därmed livscykelhändelse, som en pil i diagrammet här till höger och ge händelsen ett tydligt namn. Jag tror att det finns många andra förslag.

Pilen längst ner i diagrammet innebär att vi någon gång rensar ut minnet av den avslutade kunden. Det är ju också en händelse, men inte en händelse som har med kundrelationen i sig att göra utan bara med informationshanteringen som avbildar händelsen i verkligheten. Därför har den händelsen inte något namn och finns då inte heller registrerad någonstans, eftersom informationen om kunden då är borttagen.  

Nu kan vi skapa en entitet, kallad Livscykelhändelse, som har de sju möjliga händelserna i diagrammet ovan som förekomster.

Därefter kan vi skapa en entitet, kallad Kunds inträffade livscykelhändelse, för att registrera de kundhändelser som inträffar för kunden.

Observera att de två högra entiteterna i diagrammet tillhör ett regelplan. De definierar reglerna som finns, det vill säga vilka kundstatusar och livscykelhändelser som kan förekomma. När något händer i regelplanet, till exempel att en ny kundstatus läggs till, konfigureras verksamheten, det vill säga att vi förändrar reglerna för vad som kan inträffa. När något händer i det operativa planet, till exempel att ett prospekt blir ny kund, så opererar verksamheten.  

Om rubriker i diagrammet: Jag brukar gruppera entiteter och sätta rubriker i diagram enligt ovan. Modellen blir tydligare om man på detta sätt separerar regelplanet från det operativa planet. Det blir då tydligt var man sätter regler och var saker och ting händer operativt.

Men märk att vad som är konfigurering och vad som är en operativ händelse beror på sammanhanget. I modellen i stort kan man mycket väl hävda att detta att ett prospekt blir till aktuell kund är en konfigurering. De verkliga operativa händelserna är med detta större perspektiv först när en kund köper något. Skillnaden mellan det lilla sammanhanget och det stora visar bara att världen är fraktal. Den distinktion som gjorts mellan de två planen är endast för just detta sammanhang. Om man zoomar ut till ett större sammanhang kan mycket väl en operativ händelse (en ny kund) skifta till att ses som en konfigurering.

Mönster 2: Händelseorsaker

Vi har hittills definierat en händelse som det faktum att en viss tillståndsövergång har skett, oberoende av orsaken. Särskilt då det gäller avveckling av en kund brukar det vara värdefullt att registrera orsaken. Orsaken kan till exempel vara något av följande:

  • Kunden har varit inaktiv under en lång period (som man bör bestämma längden på).
  • Kunden har upphört att existera (avliden, utflyttad från landet, avvecklat företag).
  • Kunden har sagt upp sig.
  • Kunden har misskött sig, till exempel inte reglerat sina skulder till oss.
  • Kunden är misstänkt för brottslig verksamhet, eller på andra sätt blivit ej önskvärd.

Men även orsakerna till att man vinner prospekt eller att en kund skapas utan att tidigare varit prospekt är intressant att studera, för att förstå hur vi vinner kunder över huvud taget. Man kan förstås se och hantera allt detta som olika händelser, men jag anser att modellen blir renare och lättare att förstå, hantera, förändra och använda i analyser om man separerar livscykelhändelsen, det vill säga själva tillståndsövergången från den bakomliggande händelsen, det vill säga orsaken till tillståndsövergången. Om vi lägger till livscykelhändelser och händelseorsaker till modellen får vi modellen nedan. Vi ser nu att övre delen av diagrammet handlar om nuläget, kunders aktuella status, och nedre delen om kundernas historik, det vill säga vilka händelser som inträffat och varför. Och som tidigare visar högra delen av modellen själva regelverket, vad som kan inträffa, och vänstra delen det som verkligen inträffat.     

Enkel uppföljning

Om vi kan registrera kundhändelser på detta vis, blir mycket av uppföljningen enkel.
Vi kan till exempel göra följande:

  • Veta exakt hur många (aktuella) kunder vi har just nu och vi varje givet tillfälle i historien.
  • Veta och analysera churn rate (kundomsättning), det vill säga hur många kunder som tillkommer och försvinner under varje tidsperiod, och orsakerna till detta (så långt vi har kunskapen).
  • Analysera hur länge vi behåller kunder.

Om vi som brukligt har delat in kunder efter geografi, segment och kategorier av olika slag kan vi analysera beteendet för olika grupper av kunder enligt ovan utefter olika grupptillhörighet. Det finns då ingen ände på de analyser som vi direkt kan göra.

Inte bara kunder har en livscykel

Dessa modellmönster är användbara inte bara för kunder utan för alla företeelser vars livscykel man vill kunna analysera. Särskilt vanligt är det för produkter. Men även produktindivider, avtal och konton har ofta livscykler man vill hålla reda på.

Inte bara livscykler utan även andra cykler

Jag brukar kalla de övergripande tillstånden och händelserna i en företeelses liv för livscykel, men det finns ofta andra parallella förlopp som är värda att följa. För kunder kan det ofta vara att vi vill veta om de är i skuld eller inte, och händelsen att de hamnar i skuld och händelsen att vi aviserar skulden och när de reglerar skulden. På så sätt kan vi mäta hur lång tid det går, i allmänhet, innan betalning sker och vilka kategorier av kunder som är särskilt sena med mera.

Möjligheterna är stora. Vi kan med enkla grepp få kontroll på det dynamiska flödet i våra verksamheter. Det enda som behövs är en tydlig och genomtänkt struktur för tillstånd, händelser och händelseorsaker.

Kommentera gärna. Berätta hur du använder livscykler, händelser och händelseorsaker för att få koll på flödet i din verksamhet.  

Vad vi nu kan göra

Om man skapar en gemensam modell på detta sätt, i till exempel ett gemensamt Data Warehouse, och låter de olika kundsystemen rapportera enligt detta så får man på ett ganska enkelt sätt helt nya möjligheter. Den stora fördelen med detta är att vi inte behöver bygga om alla källsystem innan vi kan få gemensamma begrepp. Översättningen från de lokala begreppen görs där det finns bäst förutsättningar, det vill säga i de team som hanterar respektive källsystem. Alltså en pushmodell där den gemensamma modellen blir det semantiska formatet i kontraktet de måste rapportera enligt.

Det är en stor skillnad mot hur det vanligtvis är, det vill säga att man har flera olika system med olika, och vanligen oklara definitioner, och ingen gemensam modell. Analytiker får sitta och försöka tolka och pussla ihop data från olika system. Beroende på vem som tar fram rapporten blir resultaten olika. Jag får ofta höra från ledningar: ”Om jag ber om en viss rapport blir resultatet olika beroende på vem som tar fram den, och alla svar är sanna, fast på olika sätt och oklart hur.” Osäkerheten och bristande jämförbarhet är således ett problem. Ett annat problem är tidsåtgången och arbetsbelastningen. I en bank tog det analytikerna hela månaden att ta fram månadsrapporten. De hade därmed inte någon tid alls att göra det de ville göra och var bra på, att analysera resultatet och dra lärdom. Efter att vi implementerade en gemensam modell enligt ovan kunde de ta fram månadsrapporten på några sekunder. Det är svårt att tänka sig något annat vi som informationsarkitekter kan göra som ger större förändring på lika enkelt sätt.

Som vanligt skulle jag uppskatta om du ville kommentera detta. Kanske du har idéer om hur man kan tänka annorlunda, eller synpunkter på modellerna jag visar.

/Peter Tallungs, IRM 

Nästa artikel i serien publiceras torsdag 9 september. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Modellmönster: Ansvarsförhållanden mellan parter

I en verksamhet behöver man hantera olika typer av ansvarsförhållanden mellan parter. De man kanske först tänker på är de som uttrycks i organisationshierarkier, men det är bara ett av en mängd olika slag av ansvarsförhållanden. I denna artikel beskriver jag några användbara mönster för att hantera förhållanden där en part har ett ansvar gentemot en annan. Jag passar också på att ta upp hur man kan införa ett regelplan i sin modell. Det är ett effektivt sätt att göra sin informationsmodell tydligare.

Mönster 1: Organisationshierarki med explicita nivåer

Det här är ett vanligt och naturligt sätt att modellera organisationshierarkier, liksom hierarkier i övrigt. Varje typ av organisationsenhet har sin egen entitet. Det har sin stora fördel i att det känns naturligt, det vill säga överensstämmer med den bild vi har naturligt i huvudet. Men det har en begränsning. Om organisationsstrukturen ändras – om till exempel nivån med avdelningar tas bort för att platta till strukturen – måste vi bygga om modellen helt och hållet.

Mönstret ger alltså en tydlig och naturlig men inte speciellt flexibel modell.
Det räcker till i de fall vi inte behöver hantera historik, det vill säga hur organisationen förändras över tid.

Mönstret passar inte heller då vi behöver en mer generisk modell som ska användas för flera olika organisationer.

Mönster 2: Organisationshierarki med generaliserade organisationsenheter

Vi kan skapa en mer generell entitet som gäller för alla organisationsenheter oavsett typ. Vi kan sedan ha mer dynamiska regler för vilka subtyper som finns samt begränsningsregler för hur de kan relatera till varandra.

Detta mönster har möjligen en något större flexibilitet än föregående, det vill säga att det blir lite lättare att förändra organisationsstrukturen. Men vad vi nu vunnit i flexibilitet har vi förlorat i tydlighet.

Mönster 3: Flera organisationshierarkier

Ofta har man två eller flera parallella organisationshierarkier, det vill säga multipla rapportvägar. Det avbildar man på enklaste sätt genom att ha fler än en moder-dotter-relation.

(Subtyper och begränsningsregler har inte tagits med i diagrammet här).

Men om vi vill hantera egenskaper hos själva relationen, till exempel historik som vilken tidsperiod relationen gällde för, behöver vi lyfta själva relationen till att representeras av en egen entitet. Vilket tar oss till nästa mönster.

Mönster 4: Organisationshierarki med relationsobjekt

Vi kan göra själva relationen till en egen entitet. Då öppnas flera möjligheter:

  1. Nya typer av ansvarsrelationer kan lätt läggas till.
    Vi kan typa relationerna så att en organisationsenhet kan ingå i flera hierarkier samtidigt. Man kan till exempel ha en organisationshierarki baserad på produkt och en annan baserad på säljorganisation.

    Om vi endast har två hierarkier är detta knappt värt besväret, men för fler hierarkier än så är det användbart.
  2. Vi kan ge varje relation en tidsperiod då den gäller.
    På så sätt kan vi hantera förändringar över tid, till exempel att en enhet byter plats i strukturen.

    När man på detta sätt gör entitetstrukturen mera generell blir det viktigt att i text uttrycka de regler som begränsar vilka relationer som är möjliga. Observera att reglerna i detta fall läggs på själva relationen.

Vi kan använda detta som en metamodell vilken kan härbärgera alla möjliga ansvarsstrukturer mellan organisationsenheter.  

Mönster 5: Relationsobjekt för ansvarsförhållanden för olika typer av intressenter

Det förra mönstret (mönster 4) handlar om organisationsenheter där en organisationsenhet kan ha en relation till en annan organisationsenhet, enligt en viss regel för en viss tidsperiod.

Alltid när något gäller för organisationer eller organisationsenheter kan man fråga sig om detsamma inte kan gälla för andra typer av intressenter, som till exempel personer. I just detta fall kan man ställ sig frågan: ”Kan en person ha en relation till en organisationsenhet eller till en annan person, enligt viss regel, för en viss tidsperiod?”. Eller motsvarande fråga för organisationer som helhet.

Om vi byter supertypen Organisationsenhet mot Intressent kan vi täcka en vid uppsättning relationer mellan parter, till exempel ledningsrelationer, anställningar och kontrakt.

Vi har emellertid introducerat komplexitet genom att vi nu täcker en mycket större variation i relationer mellan parter än bara mor-dotter-förhållanden. Det krävs regler för att styra vilka parter som kan ingå i vilka relationer.

Det kan vi hantera genom att introducera något i modellen som kan kallas regelplan.

Mönster 6: Relationer styrda av ett regelplan

Vi kan dela upp vår modell i två delar.

  • Operativa planet registrerar de dagliga förhållandena (eller händelserna) i domänen. I detta fall vilka konkreta ansvarsförhållanden som finns i verksamheten
  • Regelplanet håller de regler som styr strukturen i det operativa planet. I detta fall vilka typer av parter det kan finnas och vilka typer av ansvarsförhållanden som kan finnas för varje kombination av två typer av parter.

På så sätt definierar varje förekomst i regelplanet en tillåten konfiguration av förekomster i operativa planet.

Exempel: Ett specifikt ansvarsförhållande (en länk mellan två specifika parter) kan endast skapas mellan parter enligt vad som är angivet i Typ av ansvarsförhållande.

Det är intressant att notera hur det operativa planet speglas i regelplanet. De två planen har liknande men inte identiska relationer. Det operativa planet registrerar de specifika parterna i ett visst ansvarsförhållande medan regelplanet definierar vilka typer av parter som är tillåtna för en viss typ av ansvarsförhållande. Detta är ett typiskt mönster: Flervärd mappning i regelplanet för att visa tillåtna typer för en envärd mappning i operativa planet.

Metadata utrycks nu inte längre bara av entitetsstrukturen utan även av förekomsterna i regelplanet. För att systemet (det vill säga informationssystemet i bred bemärkelse) ska fungera räcker det inte med att implementera modellens struktur (till exempel skapa de tabeller som behövs). Vi måste också instansiera objektförekomsterna i regelplanet. Det vill säga till exempel att populera de tabeller som beskriver vilka parter som kan finnas och vilka relationer varje kombination av dessa kan ingå i. Att instansiera regelplanet innebär att konfigurera systemet, det vill säga verksamheten.

Notera att mappningen från Part till Typ av part ersätter subtypning av Part. Att en mappning definierar en subtyp kallas ibland ”power type”.

När ska detta mönster användas? Vi kan inte undvika att hantera den inbyggda komplexitet som finns inom en domän. Vi kan bara fråga oss vilket mönster som enklast representerar den komplexitet vi behöver hantera. Se upp bara så att detta mönster inte blir ett catch-all för alla typer av relationer mellan två parter.

Om regelplan i modeller 

Det är fruktbart att tänka i begreppen regelplan och operativt plan när man modellerar och att hålla isär dessa grafiskt inom ett ämnesområde. Fast jag skriver aldrig ut termen ”regelplan” utan något i stil med ”Regler för kund” eller ”Produktregler” som rubrik för den delen av ämnesområdet.

Regelplan kan ibland också kallas typplan eftersom de oftast innehåller entiteter vars instanser definierar typer. Det är också ett metaplan rent definitionsmässigt, men jag tycker vi ska undvika namnet ”metaplan”, för begreppet ”meta” är ett alldeles för vitt begrepp, det vill säga att det kan betyda lite vad som helst och kan därmed förvirra mer än det tydliggör. Metadata är ju data om data och det rymmer allt möjligt.

Att skikta en modell – eller vanligare ett ämnesområde inom en modell – på detta sätt är ett mycket kraftfullt sätt att ordna sin domän. Det är inte speciellt känt, men jag hoppas att det härmed sprider sig.  

Var kommer dessa mönster från

Jag har hämtat dessa mönster från Martin Fowlers bok ”Analysis Patterns”, från 1997. Det är bok som inte många känner till, i det närmaste en apokryfisk skrift, som jag menar har ett stort värde. Speciellt vill jag nämna detta med regelplan, vilket jag en gång lärt mig från denna bok, och använt i tjugo år i mina modeller. Det är mer eller mindre nödvändigt för att hantera lite mer komplicerade verksamhetsdelar.

/Peter Tallungs, IRM 

Nästa artikel i serien publiceras torsdag 26 augusti. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

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.