Se verksamhetens alla perspektiv i en och samma karta

Vintergatan är en verksamhetskarta och en förmågemodell som knyter samman alla andra arkitekturmodeller. Det enkla visuella språket gör den lätt att relatera till för hela verksamheten.

Vintergatan är också en metod som förenklar den del av arkitekturarbetet som visas upp mot verksamheten. Metoden och modellen bidrar till förståelse för de konsekvenser ett förändringsarbete kan få för andra delar organisationen.

Oavsett vilken bransch ni är i så ger Vintergatan tydliga fördelar. Kontakta oss för en överflygning av Vintergatan och vad det innebär att arbeta med modellen och metoden.

I samarbete med Dataföreningen kompetens erbjuder vi kurser i Vintergatan. Vintergatan – kartan för navigering och förändring är en endagskurs där du utifrån en Vintergata över ett fiktivt företag, får grundläggande kunskap i teorin bakom Vintergatan samt hur du kan använda en Vintergata för att bedriva förändringsarbeten. Vintergatan – skapa din verksamhetskarta är en tredagarskurs där du förutom grunderna i metoden och modellen får skapa en Vintergata över din egen verksamhet under ledning av några av de bästa konsultera inom området.

Om mönster för informationsmodeller

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

Repertoarer av mönster

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

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

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

Mönster-begreppet inom informationsmodellering

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

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

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

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

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

Viktigt om mönster

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

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

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

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

Mönster för informationsmodeller

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

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

Källor för modellmönster

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

/Peter Tallungs

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

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

Saker jag stjäl från UML

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

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

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

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

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

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

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

Supertyp och subtyp separerade från varandra

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

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

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

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

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

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

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

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

Komposition

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

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

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

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

Vilka innovativa idéer har du?

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

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

/Peter Tallungs

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 24 juni. Då handlar det om mönster för informationsmodeller.
Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Modellera strukturer med instansdiagram

Ofta behöver vi reda ut och beskriva de strukturer olika objekt kan bilda med sina relationer. Det kan till exempel vara olika varianter av avtals- och kontostrukturer. Då händer det att våra vanliga diagram, det vill säga ER-diagram, inte räcker till. Ett sådant avbildar ju bara den allmänna strukturen på typnivå, inte det individuella fallet. Då är det lämplig att komplettera sin modell med en annan typ av diagram; instansdiagram (Instance Diagram). Ett sådant beskriver nämligen strukturer som förekomster av verksamhetsobjekt kan bilda.

Att beskriva exempel på förekomster i stället för klasser av förekomster

Ett ER-diagram (liksom ett klassdiagram i UML) beskriver klasser av företeelser, inte vilka enskilda förekomster företeelserna kan ha. En entitet som heter ”Kund” beskriver vad som är gemensamt för alla kunder. Den omfattar själva begreppet ”Kund”, vilka egenskaper och relationer en kund kan ha som är intressanta för vår verksamhet att hålla reda på. Entiteten står alltså för en klass av företeelser. Den är som en mall för alla kunder. Den säger inget om någon enskild förekomst av en kund.

Den struktur som ett ER-diagram ger är precis vad vi behöver som bas i en informationsmodell. Men för vissa av de områden vi behöver analysera, beskriva och skapa ett språk för räcker inte ER-diagrammet till. Jag har i en tidigare artikel berört tillståndsdiagram för att modellera det dynamiska beteendet hos verksamhetsobjekt, det vill säga hur ett objekt kan ändra tillstånd som en reaktion på olika händelser. Men nu har turen kommit till instansdiagram (Instance Diagram eller som det heter i UML: Object Diagram).

Ett instansdiagram liknar ett ER-diagram, men en ruta (eller annan symbol) i ett instansdiagram avser inte en klass av företeelser utan är exempel på en förekomst (instans) av en företeelse. Instansdiagram kan därmed användas för att reda ut och beskriva hur förekomster av objekt kan uppstå och relaterar till varandra i olika situationer.

Exemplet ovan

Den illustration som inleder denna artikel är ett utsnitt ur ett större modelldokument. De två instansdiagrammen, diagram 7 och 8, förklarar tillsammans med texten skillnaden mellan två typfall av motorfordonsförsäkring som förekommer i försäkringsbranschen: Enskild försäkring och Samlingsförsäkring.

Varje symbol i diagrammet representerar ett exempel på en förekomst av ett verksamhetsobjekt. En bilsymbol representerar ett fordon, en fabriksymbol representerar en företagskund och en dokumentsymbol representerar ett avtal. I instansdiagram använder jag ofta symboler i stället för anonyma rektanglar. Det gör diagrammet mycket tydligare. Strecken representerar relationer, samma relationer som i motsvarande ER-diagram, men eftersom det handlar om relationer mellan förekomster och inte mellan klasser blir det inga gafflar i ändarna. En relation går ju alltid mellan en förekomst av en företeelse till en annan förekomst.

Avsikten med dessa diagram och medföljande text var att tydligt förklara skillnaden mellan de två typfallen. De skiljer sig inte nämnvärt åt vad beträffar vilka verksamhetsobjekt och relationer de har. Det vill säga att ER-diagrammen skulle vara förvillande lika. Den enda skillnaden är att Samlingsförsäkring har avtalsdelar samt andra kardinaliteter (multipliciteter) för relationerna. Ändå är skillnaden avsevärd vad gäller komplexitet i hela strukturen, och därmed i hanteringen. Detta var svårt att förmedla på annat sätt än med instansdiagram. Ett ER-diagram varken förklarar eller framhäver den stora skillnaden.

Det som är speciellt med instansdiagram

Det finns många olika sammanhang där ett instansdiagram kompletterar ett ER-diagram. Det är mångsidigt användbart och har visat sig oumbärligt i många situationer. Det är några saker jag vill framhålla vad gäller instansdiagram:

  • Ett instansdiagram ersätter sällan ett ER-diagram. Vi behöver nästan alltid ett ER-diagram i botten. Instansdiagrammet kompletterar ER-diagrammet.
  • Vi bör se ett instansdiagram som en integrerad del av informationsmodellen, inte som en förklaring av informationsmodellen. Detta av två orsaker:
    1. Vi bör vänja oss vid att en informationsmodell inte är liktydigt med ett ER-diagram, utan att vi bör använda oss av alla medel vi behöver, inklusive olika typer av diagram och texter.
    2. Ofta behöver vi instansdiagram inte bara för att förklara vad vi redan vet, utan även för att verkligen analysera och förstå en eller flera samverkande strukturer. Då är det inte ”bara” en förklaring av en modell. Precis som alla andra delar av en modell är det ett verktyg för utforskning och lärande. Jag kommer i senare artiklar att visa några exempel på situationer där jag menar att det hade varit omöjligt att komma till en gemensam förståelse på ett annat sätt än med instansdiagram som verktyg för gemensamt utforskande av en domän.   
  • Instansdiagram blir ofta bättre av att ha olika symboler i form av stiliserade bilder för de olika verksamhetsobjekten.
  • Ett instansdiagram har nytta av en förklarande text, som i exemplet ovan. Det är viktigt att texten finns i anslutning till själva diagrammet och inte någon annan stans. Synergin mellan text och bild ger ett större förklaringsvärde. Det är ett av skälen till att vanliga verktyg som MS Word och MS Visio är effektivare än de specialiserade arkitekturverktygen. Det är svårt att få till de symboler och den integration av text och bild du behöver med ett specialiserat verktyg.

Har du använt instansdiagram i dina informationsmodeller? Hur har det fungerat? Vad är din erfarenhet? Kommentera gärna.

/Peter Tallungs, IRM

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 17 juni. Då handlar det om uttrycksmedel som finns UML:s klassdiagram och som kanske borde finnas i fler notationer.
Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Modellera livscykler med tillståndsdiagram

I varje verksamhet finns det företeelser som transformeras till olika tillstånd. Dessa tillstånd är en central aspekt av verksamhetslogiken och är därmed något vi behöver definiera och hålla reda på. En informationsmodells ER-diagram behöver därför ofta kompletteras med tillståndsdiagram (Statecharts) för att visa vilka tillstånd ett verksamhetsobjekt kan växla mellan, vilka händelser som orsakar tillståndsförändringen och vilka orsakerna kan vara.

Verksamhetsobjekt har livscykler

De flesta verksamhetsobjekt har någon form av livscykel. Det brukar hanteras som att de har ett attribut som heter status med några fördefinierade värden. Ofta bara en kod, ibland även ett namn och om man har tur en tydlig definition. Här följer några exempel:

En kund kanske börjar sitt liv som ett prospekt (en intressent man tänker bearbeta för att bli kund). Sedan blir den en aktuell kund. Och till sist blir den en tidigare kund. Sedan kanske den någon gång kan återgå till prospekt. Eller till aktuell kund?

Ett ärende kanske börjar sitt liv som ankommet, sedan blir det under bearbetning för att till sist bli avklarat. Kan det då återgå till under bearbetning?

En produkt kanske börjar som under utveckling, sedan i produktion, sedan inte längre i produktion men fortfarande supportad, för att till sist bli avvecklad. Kan den någon gång senare gå i produktion, eller måste den då passera under utveckling?

En del verksamhetsobjekt kan ha fler än en tillståndscykel. Då brukar den ena cykeln vara den mer grundläggande, en som vi kan kalla för livscykel, som i exemplen ovan. Och de andra cyklerna handlar om andra tillstånd man vill hålla reda på. Till exempel kan ett bankkonto för tillfället vara övertrasserat eller inte övertrasserat. Det är inte samma sak som den mera grundläggande livscykeln som anger om kontot är öppet eller stängt, även om det naturligtvis finns orsakssamband mellan dessa.

Händelser och tillståndsövergångar

En händelse är något som inträffar med ett verksamhetsobjekt. Det kan till exempel vara att en kund gör ett köp eller att ett konto övertrasseras. Vanligen vill man hålla reda på olika typer av händelser. En händelse kan leda till att verksamhetsobjektet i fråga byter tillstånd, det vill säga en tillståndsövergång.Till exempel kan händelsen vara att vi avslutar en kundrelation och då blir kunden tidigare kund.

Orsaker till händelser

En och samma händelse kan ha olika orsaker. Ofta vill vi logga orsaken till en händelse. Om vi till exempel avslutar en kund kan det bero på en mängd olika orsaker. Kunden har kanske; inte uppfyllt sina skyldigheter, avvecklat sin verksamhet, avlidit, blivit dömd för olaglig verksamhet etcetera. Eller kanske har vi en gräns, så att vi automatiskt avför kunder som inte hörts av på ett par år.

Skilj på tillstånd, händelse, tillståndsövergång och händelseorsak

Vi ser ofta att man med sina statuskoder blandat ihop dessa saker. Så fort det kommit behov av att man vill följa något för mätetal och rapportering har man bara lagt till en kod till befintligt status-attribut. Vi hamnar ofta i situationer där vi behöver reda ut detta.

Vad är då ett tillstånd?

Med tillstånd menar vi ett läge som ett verksamhetsobjekt hamnat i vilket medför ett visst beteende och oberoende av hur det kom till detta läge. Ett avslutat konto beter sig på samma sätt, lyder under samma regler oberoende av orsaken till att det avslutades.

Tillståndsdiagram

För att modellera tillstånd, händelser, tillståndsövergångar och händelseorsaker räcker det inte med ER-diagram. Då behöver vi komplettera vår informationsmodell med en annan typ av diagram som heter tillståndsdiagram (Statechart eller Harel Statechart). Det är en diagramtyp som alla ingenjörer och programmerare som utvecklar inbyggda system är förtrogna med, men som är mer eller mindre okänd bland informationsmodellerare utan denna bakgrund.

På mina kurser brukar jag fråga hur många av eleverna som känner till och har använt tillståndsdiagram. Det brukar vara omkring hälften, vanligen de med en ingenjörsteknisk bakgrund. Sedan frågar jag hur många av dessa som har använt tillståndsdiagram för någon typ av verksamhetsmodellering. Då åker nästan alla händer ner. De har tydligen trott att tillståndsdiagram inte har sin användning annat än i rent tekniska sammanhang. Inget kan vara mer fel.

Tillstånd, händelser och händelseorsaker är viktiga företeelser i varje verksamhet. Det är grundläggande för att hålla reda på saker och ting, och är därför en viktig del av en informationsmodell. Då är det lämpligt att vi som informationsmodellerare utökar vår verktygslåda till att omfatta även tillståndsdiagram.

Men är det inte det vi har processmodellen till?

Det finns en viss likhet mellan å ena sidan ett tillståndsdiagram och å andra sidan en processmodell eller flödesschema. Båda visar det dynamiska beteendet hos något verksamhetsobjekt. Men skillnaderna är följande:

  1. En processmodell visar en viss process, det vill säga på ett visst flöde. Ett tillståndsdiagram visar alla flöden som är möjliga.
  2. En processmodell visar sällan tillstånd och händelser, utan vad som utförs för att åstadkomma ett resultat. Ett tillståndsdiagram ger reglerna för hur ett objekt kan och inte kan uppträda, genom alla processer det deltar i.
  3. I processmodellen sker det som sker i symbolerna (processfiskarna). Händelserna och tillstånden finns på strecket mellan symbolerna. I tillståndsdiagrammet händer det däremot inget i symbolerna (tillståndssymbolerna). Det är först i strecken mellan som det sker saker som ändrar tillstånd.
  4. Processmodellen är ofta inte heltäckande. Den visar de vanligaste scenarierna, inte allt som kan hända med ett verksamhetsobjekt. Ett tillståndsdiagram ska visa alla tillåtna tillstånd och händelser. Tillståndsdiagram beskriver reglerna för transformationer medan processer beskriver olika vanliga scenarier för transformationerna.

Sambandet mellan en processmodell och ett tillståndsdiagram

En processmodell och ett tillståndsdiagram har ett samband så till vida att allt som sker i processmodellerna bör täckas av tillståndsdiagrammet för samma verksamhetsobjekt.

Här förutsätter jag att vi talar om en processmodell som inte bara visar en serie arbetssteg i största allmänhet utan som är ren i den bemärkelse att processen beskriver hur ett och samma verksamhetsobjekt förädlas eller på annat sätt ändras genom en serie transformationer.

Sambandet mellan ett ER-diagram och ett tillståndsdiagram

Ett ER-diagram och ett tillståndsdiagram har ett samband så till vida att varje möjligt tillstånd, varje händelse och varje tillståndsövergång och händelseorsak som vi behöver hålla reda på behöver representeras i ER-diagrammet, som förekomster till entiteter. Jag brukar lista dessa i själva diagrammet med både namn och definition.
Tillståndsdiagrammet hjälper oss sålunda att undersöka och illustrera det dynamiska beteendet hos ett verksamhetsobjekt. Själva definitionen av tillstånd, händelser och orsaker finns i ER-diagrammet eller i textdelarna av modellen.

Var i informationsmodellen placerar jag tillståndsdiagrammet?

Det beror på i vilket sammanhang tillståndscykeln är viktig att beskriva, vilket varierar något. Jag brukar växla mellan tre olika placeringar.

  1. I textdelen av den allmänna beskrivningen av entiteten i fråga. Det gör jag när det handlar om en livscykel som är central för att förstå entiteten ifråga.
  2. I textdelen för beskrivning av attributet som representerar tillståndet, det vill säga det som brukar heta ”status”. Det gör jag när det inte handlar om en livscykel för objektet utan någon annan mindre central cykel av tillstånd.
  3. I ER-diagrammet tillsammans med de entiteter som representerar tillstånd, händelser och orsaker. Det gör jag i så fall i kombination med någon av beskrivningarna i textdelen ovan.  

Exempel på användning av tillståndsdiagram

Vi på IRM byggde för en tid sedan ett Data Warehouse hos en bank som köpt upp flera andra bankföretag. Bankföretagen hade liknande betalningsprodukter men det hade utvecklats olika avtalsstrukturer. Alla hade någon form av avtal för sina kunder. Alla system hade någon form av status för sina avtal, men man hade över åren bara lagt till nya statuskoder för allt möjligt som man ville hålla reda på.

Systemen behövde nu kunna rapportera in sina data i samma format så att vi i Data Warehouse kunde skapa översikter oberoende av hur de olika systemen såg ut internt. Vi var alltså tvungna att skapa ett ”lingua franca”, ett gemensamt språk för tillstånd, händelser och händelseorsaker. Vi samlade de som visste mest om detta och var mest beroende av att tolka dessa koder, det vill säga marknads- och riskanalytikerna. Sedan ritade vi upp en första version av ett tillståndsdiagram med de tillstånd och händelser vi trodde på.

Därefter fick analytikerna gå igenom en mängd olika händelsekedjor och se hur de passade in i livscykeln. Vi ändrade många gånger tills alla var nöjda. Vi jobbade mycket med namn och definitioner. Sedan fick de som var ansvariga för respektive system bygga översättningar från sina lokala språk till vårt nu gemensamma språk. Det hade varit svårt att åstadkomma detta på ett annat sätt än med tillståndsdiagram.

När behöver man ett tillståndsdiagram?

Man behöver kanske inte tillståndsdiagram för linjära cykler då ett objekt bara kan gå en rak väg längs en serie av tillstånd. Men man behöver i vilket fall lista tillstånden, se till att de har bra namn och definitioner, samt definiera händelser och orsaker till tillståndsförändringarna. Och för att vara alldeles säker på att ett objekt inte kan gå tillbaka till tidigare tillstånd bör man gå igenom alla tänkbara scenarion. Ett effektivt sätt är att undersöka befintligt data. Har det hänt att en avslutad kund har återöppnats? Eller blir denne definitionsmässigt en ny kund då?

Vad är en informationsmodell egentligen?

Jag menar att en informationsmodell inte måste vara samma sak som ett ER-diagram. Det behöver alltid finnas ett eller flera ER-diagram som bas i informationsmodellen, men vi behöver fler diagramtyper för att komplettera, då ER-diagram inte lämpar sig för att gestalta det vi behöver gestalta. Tillståndsdiagram är ett exempel på ett sådant komplement.  

Vi behöver helt enkelt utveckla vår verktygslåda, bruka de verktyg som gör jobbet. Inte bara bli operatörer av de oss givna verktygen. Många som informationsmodellerar känner bara till ER-diagram. Du är säkert bekant med liknelsen att om man bara har en hammare så ser man bara spikar, och bankar ner både spikar och skruvar.

Hur lär jag mig mer om tillståndsdiagram?  

Det finns gott om material om tillståndsdiagram, både i böcker och på webben. Googla ”Statecharts”. Har du använt tillståndsdiagram till informationsmodellering?

/Peter Tallungs, IRM

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 10 juni. Då handlar det fortsatt om notationer för informationsmodellering, men vi går närmare in på notationer för tillståndsdiagram.
Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Vad skulle hända om alla i teamet var lika engagerade?

”Igår hade vi veckomöte med teamet. Det var som vanligt. Per pratade sjuttio procent av tiden. Av oss sju var det bara Anna som verkligen sa något av värde, men jag tror de flesta missade hennes poäng. Vi kör på i inkört spår trots att minst fyra av oss kan se bättre lösningar, om vi hade fått göra rätt från början. Tror inte det blir så mycket bättre när detta är sjösatt, men det blir förhoppningsvis inte värre i alla fall. Känner liksom att det inte är mitt problem. Det får PL dra i. Jag försökte tidigt i projektet lyfta vissa problem, men det slutade bara med att jag fick ett gäng tunga bollar i mitt knä så nu duckar jag hellre. Vill inte sitta där ensam med ansvaret och sen få skit när resultatet inte lever upp till förväntningarna.

Ibland funderar jag på hur vår slutprodukt skulle kunna se ut om alla i teamet var lika engagerade. Tänk om folk lyssnade på varandra och verkligen vågade ”testa varandras tankar”, om du förstår vad jag menar. Jag tror för det första att varje möte hade varit sju gånger roligare, mer produktivt och vår slutprodukt mycket mer ändamålsenlig än den jag ser växa fram nu.

Min tro på att det finns bättre arbetssätt än vårt stärktes för någon vecka sedan, när jag ramlade över ett case där man beskrev olika positiva följder av att införa ett agilt arbetssätt.”

– Vad innebär egentligen ett agilt arbetssätt? Vad gör det med ett team? Kan det vara något för Kim som frustrerat beskrev sin situation ovan?

Ledarskapets betydelse

Högpresterande team är summan av medlemmarnas agerande med varandra. Det agila ledarskapet jobbar med både kultur och struktur. På en övergripande nivå handlar det om att ge förutsättningar för teammedlemmarna att känna ägandeskap och ansvar för innehållet samt resultatet av deras arbete. Genom det skapas förutsättning för självorganisering och autonomi.

Kollektiv intelligens

Den bästa poängen med ett agilt arbetssätt får vi när agerandet bidrar till att kollektiv intelligens uppstår. Agila ceremonier är designade för att driva upp kunskap och produktivt agerande, men ett agilt arbetssätt i sig är ingen garanti för att kollektiv intelligens ska uppstå. Det kräver bl a:

  1. Trygghet
    För att utvecklas och komma fram till nya smarta lösningar krävs det att vi vågar ta risker. I en gruppdynamik som upplevs säker vågar vi göra misstag och lita på att dessa inte vänds mot mig. Det ökar individernas mod att ta upp problem, utmanande perspektiv samt dela med sig av idéer, kunskap och erfarenheter, vilket är vitalt i ett arbetssätt som är hypotes- och lärandedrivet.
  2. En gemensam tillräckligt komplex problemformulering
    En problemformulering som innehåller flera perspektiv och en djup förståelse har större förutsättningar att kunna leda till en intelligent lösning. I ett samtal där partnerna i högre grad lyssnar på varandra istället för att mest fokusera på att rättfärdiga sina egna perspektiv skapas en mer sann problemformulering och följaktligen en problemlösning som är mer ändamålsenlig.
  3. Fokus på kundvärde
    Genom ett samlat fokus på kundvärde minskar konkurrensen i teamen. Det skapar lyftkraft mellan lagmedlemmarna. Teammedlemmarna tendrar att i större utsträckning att hjälpa varandra. De värderar och nyttjar unika färdigheter, kunskaper och talanger på ett sätt som bidrar till det gemensamma värdeskapandet.

Detta är hela idén med tvärfunktionella och självorganiserande team och är också det som kategoriserar högpresterande grupper. Genom den kollektiva intelligensen kan vi bättre utforska, förstå och skapa en gemensam representation av våra kunders ”jobs to be done”, deras behov, och på ett bättre och snabbare sätt uppfylla dem.

Ja, så vad händer om alla i teamet är lika engagerade och motiverade? Det korta svaret är: ökad kundnöjdhet, ökad lönsamhet och god kollegial stämning.

Ta reda på vad Business Agility skulle kunna innebära för ert team.

Volkswagen Finans Sverige har infört ett agilt arbetssätt. Läs om deras erfarenheter här.