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: Mätningar

I de flesta organisationer görs mätningar av olika slag. I stort sett alla verksamheter blir mer och mer datadrivna, vilket innebär att en mängd olika typer av kvantitativa data samlas in och hanteras. Denna artikel tar upp några användbara mönster för att registrera mätningar. Exemplen är tagna från sjukvården, men mönstren är tillämpliga på alla slags verksamheter.   

/Peter Tallungs, IRM, 2021-10-14

Mönster 1: Specifika attribut per mätvärde

Det vanligaste sättet att registrera ett mätvärde i ett informationssystem är att registrera ett numeriskt värde i ett fält avsett för ett visst mätvärde.

Ett problem är att det vanligen inte anges vilken måttenhet som avses. Det har lett till fatala misstag många gånger.

Ett sätt att åtgärda detta är att alltid baka in namnet på måttenheten i attributnamnet. Det är ett enkelt och effektivt sätt att öka datakvaliteten och minska risken för missförstånd. Ändå är det sällan så görs. Kanske det ännu finns en kvardröjande uppfattning om att attributnamn måste vara korta. Men det var länge sedan vi hade den tekniska begränsningen i våra informationssystem.

Mönster 2: Entitet för mätvärde

I till exempel medicinska sammanhang vill man av säkerhetsskäl kunna registrera en mätning exakt som den gjordes, utan att behöva räkna om måttenhet. Då blir det användbart att introducera en särskild entitet för Mätvärde där vi ser måttenhet, värde och tecken som en sammanhållen enhet.

Monetära belopp kan hanteras på samma sätt. På det sättet kan man hantera flera valutor samtidigt.

Mönster 3: Omräkningsfaktor

Om vi som i föregående mönster har måttenheter som är explicit angivna i modellen så kan vi automatiskt omvandla ett mätvärde från en enhet till en annan, om vi har en Omräkningsfaktor. En sådan kan hantera de flesta omräkningar, dock inte alla. Till exempel Celsius till Fahrenheit kräver en formel. Dagar, månader och år konverterar inte heller så lätt till varandra, utan kräver lite mer avancerad omräkning.

Detta mönster är vanligt för automatisk omräkning av monetära belopp i olika valutor. Vanligen vill man hålla reda på valutakurser över tiden vilket gör att de behöver datumstämplas.

Mönster 4: Mätning

På ett sjukhus måste man kunna registrera många olika slags mätningar för samma patient. Då kan man inte ha ett attribut per möjlig mätning. Det skulle bli hundratals attribut, där de flesta förblir oanvända för en och samma patient.

En lösning är att betrakta alla saker som kan mätas (längd, vikt, blodsockernivå mm) som Typ av fenomen samt införa Mätning, en entitet för själva mätningen som görs. Vi kan då också lägga på attribut på mätningen, så som vem som gjorde den, när den gjordes och var. 

Det är värdefullt att dela in den del av modellen som är för mätningar i ett operativt plan och ett regelplan enligt ovan. Det operativa planet registrerar de mätningar som görs dagligen. Regelplanet representerar reglerna om vad som kan mätas och uppdateras endast då dessa ändras.


Man kan också ha en lista av tillämpliga måttenheter för varje fenomen, för användarna att välja från.

Kvantitativa och kvalitativa observationer

”Mätningar” är ett namn vi använder för kvantitativa observationer, det vill säga observationer vars resultat uttrycks som kvantitet eller antal av något slag. Nästa artikel breddar temat till att omfatta även kategoriobservationer, det vill säga observationer vars resultat uttrycks som tillhörande en kategori av något slag.

/Peter Tallungs, IRM

Vintergatan – en karta och en metod för att accelerera innovation och förändring

Vintergatan är en metod och en karta som gör det lätt att navigera en verksamhet från strategi till reellt genomförande i en ständigt föränderlig värld. Den knyter samman andra arkitekturmodeller så att den blir lättöverskådlig för hela verksamheten oavsett bransch. Med dess hjälp går det att synkronisera en mängd skilda resurser i en viss önskad riktning.

Hela idéen för Vintergatan uppstod genom ett starkt behov av att få verksamheter att holistiskt bli mer organiserade och effektiva. Metoden har utvecklats av kon- sultföretaget IRM i samarbete med ett trettiotal andra företag. Visionen var att verksamheter ska snabbt kunna svara på och bryta ner komplexa frågor som kan uppstå i verksamheten. Vintergatan är en karta över en verksamhet som visar vad verksamheten gör i vilken ordning. Vilka IT system man använder då man utför detta arbete, vilken information som skapas var och som behöver förmedlas till andra, samt hur man interagerar med sina kunder och partners. Allt i en och samma bild.

För fem år sedan började Cecilia Nordén, som arbetat med affärsstrategier och verksamhetsarkitektur sedan 1997, på IRM och anser att modellen är oerhört kraftfull. Även Thomas Larsson som är ny verksamhetsarkitekt på IRM har sett vad modellen kan göra för kunderna.

Visuellt starka analyser ger bättre beslutsunderlag

– Att ha en karta över verksamheten är intressant. Men riktigt spännande blir det då vi börjar använda kartan som grund för att göra analyser. På kartan kan vi visualisera frågor som: vilka projekt som pågår var, var vi har problem idag, vad vi lägger våra pengar på, önskemål från kunder eller var ny teknologi skulle ge störst nytta. Genom att visualisera dessa typer av frågeställningar på ett och samma sätt kan vi jämföra dessa på ett liknande sätt och upptäcka fler saker som behöver hanteras.

Innovation handlar mindre om idén i sig och mer om tiden det tar att omsätta den till något som når ut till kunderna så fort som möjligt, med en effektiv process på insidan. Vintergatan är ett ovärderligt verktyg för att föra rätt diskussioner om hur detta ska gå att realisera samt göra ”reality check” på vad som är möjligt eller inte, berättar Cecilia.

En gemensam bild som alla kan relatera till

–Vi skapar en gemensam bild, en verksamhetskarta som alla enkelt kan arbeta med. Vi använder liknelsen med en karta eftersom det är lätt för en organisation att relatera till på ett pedagogiskt sätt. Många verksamheter använder ibland svåra termer och då blir det oåtkomligt för många. Det var det som attraherade mig att börja jobba på IRM med Vintergatan. Jag kunde verkligen applicera och förklara metoden för mina kunder oavsett vilka utmaningar de stod inför, berättar Thomas.

Framtidvisioner

–Visionen för IRM är att växa starkt inom Vintergatan. Vi ser att det finns ett skriande behov hos verksamheter efter en gemensam bild av hur deras verksamhet fungerar idag. Många har tagit till sig vikten av gemensamma visioner och mål. Men om alla börjar den resan på helt olika platser, pga sin egen syn på hur verksamheten fungerar idag, så blir effekten att alla rusar iväg på sin egen väg och vi får svårt att tillsammans nå uppsatta mål, förklarar Cecilia. Thomas fortsätter:

–Jag har en önskan om att vi inte ska dela upp allting i så hårda block som vi gör idag. Ta exempel som IT- arkitekter, UX specialister, kundresor och så vidare. Idag känns det som att det är olika discipliner som cirkulerar omkring. Min vision är att vi slutar med det och kommer överens om åtminstone ett sätt att se på verksamheten tillsammans. Det är min ödmjuka syn.

Etablera Vintergatan i din organisation

Med utgångspunkt från Vintergatan etablerar vi tillsammans ett nytt sätt att arbeta med er verksamhetsarkitektur, för att uppnå samsyn, skapa bättre beslutsunderlag, öka förändringstakten och kundvärdet. Vi utvecklar former för att förstå och använda nya mönster kring förmågor och produkter/tjänster samt de olika tidsperspektiven.

Läs mer om Vintergatan

Har du frågor om Vintergatan? Tveka inte att kontakta oss. På mail: info@irm.se eller på telefon: 08-585 011 00

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