Taggarkiv: Informationsmodellering

NY UTBILDNING – Certifierad informationsarkitekt

IRMs mest seniora konsulter inom informationsarkitektur och data management har skapat Sveriges första och enda certifierande utbildning för informationsarkitekter – CERTIFIERAD INFORMATIONSARKITEKT. Utbildningen är tolv dagar fördelade på sex tillfällen med start i november 2022. IRM levererar utbildningen i samarbete med DF Kompetens. 

Varför en Certifierande utbildning för informationsarkitekter?

Informationsarkitektur är ett kompetensområde som ligger i tiden, och i framtiden, eftersom förståelig, högkvalitativ och tillgänglig information är nyckeln till att skapa en effektiv verksamhet, och att kunna agera snabbt på nya affärsmöjligheter. Rollen informationsarkitekt finns i många verksamheter idag och efterfrågas allt mer. Men det har saknats en kvalitetssäkrad utbildning med tillräcklig bredd och djup i ämnet. Nu har IRM:s informationsarkitekter gjort något åt det. 

”Vi såg ett glapp i utbudet av utbildningar för informationsarkitekter samtidigt som våra kunder allt oftare frågar efter kvalificerad kompetens inom området.” – Mathias Lindkvist, informationsarkitekt och huvudlärare för Certifierad informationsarkitekt.

Informationshantering är ett område inom verksamhetsarkitekturen som ägnats ganska lite utrymme i befintliga certifieringar. Samtidigt är det ett område som många företag har svårast att ta tag i. Det hamnar lätt i knät på it och man hittar inte vägar för att jobba effektivt med informationen som den kritiska resurs det är. Förmågan att göra det bra förtjänar att få större fokus och en egen kvalitetssäkrad utbildning.

För vem?

IRM har tagit fram utbildningen Certifierad informationsarkitekt för den som vill fördjupa sig i ämnet informationsarkitektur och samtidigt få en kvalitetsstämpel på sin kompetens. Föreläsarna på utbildningen är några av de bästa och mest erfarna informationsarkitekterna i Sverige. De är alla till vardags aktiva som konsulter och rådgivare i sitt ämne inom ett flertal branscher.

Nyfiken? 

Boka en plats på vårt kostnadsfria webbinarium hos DF Kompetens onsdag 25 maj. Där presenterar ansvariga lärare innehållet i utbildningen samt vad rollen informationsarkitekt innebär.

Läs utbildningsbeskrivningen av Certifierad Informationsarkitekt

Det viktigaste du gör som informationsarkitekt: Arbetet med verksamhetens begrepp och språk

Informationsmodellering handlar inte bara om data och information, utan också om att analysera, beskriva och normera verksamhetens begrepp och språk. Den viktigaste uppgiften vi har som informationsarkitekter, enligt mig. Ändå är det sällan eller aldrig den uppgiften beskrivs i litteraturen om informationsmodellering eller Data management.

Vikten av begrepp och språk.

Malcolm B. Chisholm är den ende inom Data/Information Management som jag vet har intresserat sig för hur vi arbetar med definitioner. År 2010 kom han ut med boken Definitions in Information Management. I förordet citerade han ett par kollegor:

”What do you mean by ____?

After close to 30 years in the consulting business, I think that is the most important single question one can ask during an engagement.

What I´m talking about, of course, is the art and science of clarifying communication through good definitions. And it isn´t just the end result that matters – the process of building definitions is as important as the destination. Along the way, you find out what you really think a term means, what they think it means, what the term might mean sometime in the future, and any number of other details that will surface and explain miscommunication. “

Alec Sharp, Claritec Inc

“Ambiguity is a kind of friction which limits the quality of our discourse, the utility of our data, and the reach of our understanding.

All progress in information management depends on our ability to identify its source and reduce it to its absolute minimum.

In this regard, no other effort pays more dividends that that of establishing good definitions.”

Suzanne Yoakum-Stover, Ph.D. Executive Director, Institute for Modern Intelligence

Jag kan instämma, med hela min erfarenhet. Det är mer regel än undantag i våra organisationer att dataelement är otydligt eller felaktigt namngivna, definierade och beskrivna. Ofta är de inkonsistent populerade, och misstolkas då de används. Detta beror till stor del på att man inte tagit fram och använt tydliga namn och definitioner.

Hur du väljer namn och definitioner har ofta mycket större betydelse för verksamheten än hur du strukturerar information. Namn och definitioner lever ofta kvar i decennier, vanligen längre än de system vi bygger.

Termer och begrepp är mycket viktigare än vi ofta föreställer oss. Vi bygger ett språk, och språket utgör inte bara kommunikationens grundvalar utan även tänkandets. Begreppen vi använder formar och begränsar hur vi kan tänka.

Varför är detta en uppgift för oss informationsarkitekter?

Är detta verkligen en uppgift för oss informationsarkitekter? Ska vi inte bara använda de benämningar och definitioner som verksamhetens sakkunniga ger oss?

Nej, så enkelt är det inte. När jag analyserar och beskriver de data och den information som förekommer, så handlar det inte bara om informationen i sig utan det som informationen står för. Det vill säga de företeelser som informationen handlar om, inklusive dessas egenskaper, relationer, regler med mera. Då hittar jag också namn som oftast är dåligt valda och missledande. Ofta har en och samma sak fått många olika namn när det transporteras genom verksamhetens många olika system, filer, rapporter, användargränssnitt och api:er. Många namn är sammanblandande och förvirrande. Ännu värre kan det vara med definitioner, om de ens finns. Ofta är de fel och missledande.

Då måste jag bestämma ett normerande namn och hitta en korrekt definition, samt hantera alla namn som förekommer som synonymer. Det är klart att jag gör det tillsammans med sakkunniga, men det är normalt jag som får använda mitt omdöme och min erfarenhet av namngivning och begreppsanalys för att komma fram till ett namn och definition som blir bra och verkligen fungerar.

Det är svårt att tänka sig att det skulle gå att arbeta med namn och definitioner utan att samtidigt jobba med företagets data. Därmed menar jag att arbetet med verksamhetens alla namn och definitioner i praktiken är sammanvävt med informationsarkitektens arbete med data och information.

Om vi skulle ha lyxen att i organisationen ha någon som är särskilt kunnig med och ansvarig för verksamhetens nomenklatur blir det ändå så att jag som informationsarkitekt måste jobba tillsammans med denne. Det data jag hittar ger input till vad vi behöver benämna. Det går därmed inte att säga att man först måste ha ordning på alla namn och begrepp, och först därefter kan informationsmodellera. Det är ett iterativt arbete med tät samverkan mellan arbetet med informationen och arbetet med språket.

Därmed utvecklar och underhåller vi verksamhetens terminologi.

Men konstigt nog behandlas inte detta viktiga område alls när man studerar vad som skrivits inom områdena informationsmodellering, informationsarkitektur och Data Management. Jag har kanske trettio böcker om informationsmodellering hemma, men jag har inte sett detta behandlas någonstans, vad jag kan minnas. Den internationella organisationen DAMAs referensverk om Data Management: DAMA-DMBOK går på 600 sidor igenom Data Managements alla delämnen. Men inget om namngivning, begrepp och definitioner.

Chisholms bok, som jag nämnt ovan, är det enda undantaget.  

Vad behöver definieras?   

Att jobba med namn och definitioner är förmodligen det viktigaste vi gör som informationsmodellerare.

Alla element i en informationsmodell behöver ha användbara namn, definitioner och beskrivningar. Det är en viktig del av det löpande arbetet för oss informationsarkitekter.

Med element i en informationsmodell menar vi inte bara entiteter utan även attribut, relationer, förekommande värden för attribut med uppräknade värdemängder samt hela ämnesområden.

Även dataelement i våra databaser, filer, tjänster, applikationer, formulär och rapporter behöver ha användbara namn, definitioner och beskrivningar.

Vad behöver vi ha definitioner till?

Vi behöver definitionerna för att förstå de verksamhetsbegrepp som representeras i data. Vi behöver definitioner för att härledda termer ska bli korrekta, och för att mappa och spåra data genom olika käll- och målsystem. Vi behöver definitioner för att jämföra datainnehåll med definitionen.

Vi behöver definitioner för att veta att vi verkligen pratar om samma saker i alla sammanhang. Särskilt viktigt är det i analyser och rapporter.

Det finns vissa situationer då man tydligare än annars lider av brister i definitioner: Till exempel källdataanalys i BI-projekt, dataanalys när system ska ersättas samt integrationsprojekt.   

Jag tror att många som läser detta känner igen sig. Men låt oss då göra något åt detta!

Hur behöver vi jobba med definitioner?

När jag handleder elever i informationsmodellering får jag ofta hjälpa dem att skriva definitioner. De flesta tror att de skriver definitioner men skriver i själva verket beskrivningar av olika slag. Vilket ofta också behövs, fast först och främst behöver vi bra definitioner. Men med några enkla råd blir de snabbt bättre.

Namn och definition är olika saker men följs åt i arbetsgången. När du har tagit fram eller ändrat en definition för något behöver du ofta ändra namnet för att det ska avspegla innebörden. Arbetet med namn och definitioner är inget som går att separera från det övriga modelleringsarbetet, utan är själva kärnan i det vi gör när vi modellerar. Så snart vi ritar en entitet och ger den attribut och relationer så behöver vi ta fram både namn och definition.

Till en början är både namn och definition på försök, de är tentativa. Med tiden arbetar vi om dem, i takt med att vår gemensamma förståelse utvecklas.

Ibland kör vi fast. Vi kan inte komma på hur vi ska definiera något, eller kanske hur vi ska benämna det. Men då hjälper det alltid att vi sover på saken. På något sätt arbetar då hjärnan omedvetet, och nästan utan undantag kommer nya friska idéer. Det är det vi kallar aha-upplevelser.

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 19 maj. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Har du tankar om innehållet i artikeln som du vill dela? Välkommen att kommentera på vår linkedin där lägger vi ut en post vid varje publiceringstilfälle. Eller skicka ett mail till Peter Tallungs: peter.tallungs(at)irm.se

Informationsmodellering: Om hur vi kan representera mängder, sammansättningar och specialiseringar i ER-diagram

En företeelse kan ha ett nära beroende till en annan företeelse på ett eller annat sätt. Ofta vill vi se det som att den beroende företeelsen är underställd den andra. Det är viktigt att vi kan förmedla detta tydligt med grafiken i ett ER-diagram. Hur gör vi detta?

I ER-diagram uttrycker vi ju beroenden mellan entiteter med relationslinjer. Men vissa typer av relationer är annorlunda än andra. De innebär en tätare bindning. Jag tar upp dessa och diskuterar hur vi kan representera dem i ett ER-diagram.

Mängd (aggregation)

Det är ofta så att förekomsterna av en entitet ingår som en medlem i förekomsten av en annan entitet. Ett exempel kan vara böcker i en boksamling. En viss bok kan vara medlem i en viss boksamling.

I UMLs klassmodeller kallas det för en mängd (aggregation).
Medlemmen i en mängd har en egen oberoende existens. Det betyder att medlemmen (en bok) finns kvar då en förekomst av huvudentiteten (den boksamling den tillhör) upphör att existera. En medlem av en mängd kan också byta tillhörighet och bli medlem av en annan mängd, det vill säga lämna en boksamling för en annan.

Medlemmen (boken) kan visserligen sägas vara underställd mängden (boksamlingen) men bindningen är inte permanent. Den är inte existentiell. De vill säga att boken kan existera utan att den tillhör en boksamling, den kan byta boksamling och den kan fortsätta att finnas efter det att boksamlingen läggs ner.

Som jag tidigare har nämnt i artikeln ”Saker jag stjäl från UML” så finns det ingen mening med att se den typen av relation som någon som utskiljer den från andra typer av relationer. Martin Fowler ägnar en hel uppsats till att avfärda att ”mängd (aggregation)” skulle vara en form av relation som behöver markeras särskilt i ett klassdiagram. Självaste Jim Rumbough, en av grundarna till UML, liknade den särskilda symbol som UML använder för mängd, en ofylld romb, vid placebo. En mängd är helt enkelt inget annan än en vanlig association med en kardinalitet min 1 – max 1 , och därför är det tämligen meningslöst att ha en särskild symbol.

Men trots att bindningen inte är permanent så finns det ändå ett beroende som säger att boken är underställd boksamlingen. Jag tycker att det är viktigt att uttrycka det på något sätt och gör det genom att placera den underställda entiteten (bok) under den andra entiteten (boksamling) i ER-diagrammet.

Sammansättning (composition)

Det finns samlingar av förekomster som skiljer sig mot mängd på så sätt att en förekomst inte kan ha en egen existens. Det vill säga att medlemmen aldrig kan existera för sig själv, oberoende av den samling den tillhör, samt att den aldrig kan byta samling. Ett typiskt exempel är hur en fakturarad hänger ihop med en faktura. I UML kallas den konstruktionen sammansättning (composition) och markeras i UMLs klassdiagram med en fylld romb. (Observera att jag använder en ofylld romb, eftersom Microsoft Visio saknar fylld romb som standard för start eller slut på linje.) 

Observera att det är en helt annan typ av relation än en vanlig association, och också annorlunda än en mängd. Jag tycker att det är en så pass annorlunda relation att den behöver markeras särskilt i en informationsmodell. Jag är inte ensam om detta. De flesta notationer för ER-diagram har sina egna sätt att markera detta.
Jag kör UMLs variant med en romb, men eftersom en fylld romb inte finns med som standardalternativ i MS Visio brukar jag ta mig frihetet att använda en ofylld romb i stället.

Vanlig layout av hierarkier

Mängder och sammansättningar bildar ofta hierarkier i flera nivåer. Här är ett exempel på hur detta kan gestaltas i ett ER-diagram. Lägg märke till att skiv- och boksamlingar är mängder, det vill säga att CD-skivor och böcker existerar oberoende av om de finns med i några samlingar eller inte. De är alltså vanliga mängder och behöver därför ingen särskild symbol. Detta till skillnad mot spår på en CD-skiva eller kapitel i en bok. De försvinner då man raderar skivan eller boken. De är således sammansättningar (compositions) och relationen är därmed av en helt annan natur och förtjänar att märkas ut särskilt. Vilket jag som sagt gör med en romb.

Det är vanligt att man gestaltar hierarkier i ER-diagram som exemplet visar, i vertikala kolumner. Men jag använder ofta en annan layout, som jag presenterar i det följande.

Alternativ layout av hierarkier

Här är exakt samma hierarki som i föregående exempel men där entiteterna placerats med indrag i förhållande till de entiteter de är underordnade. Detta sätt att rita ger fördelar menar jag, speciellt i lite mer omfattande ER-diagram.

Dels kan det ofta bli en mer kompakt layout, och dels kan det ge en tydligare ordning. Speciellt då man behöver dra många relationslinjer från entiteterna i hierarkin till andra delar av ER-diagrammet. Entitetsrutorna blir då inte lika mycket i vägen för varandras relationslinjer som då de ligger ordnade i kolumner och rader. Fördelen framgår kanske inte så tydligt i detta exempel, men jag har funnit det användbart. Att kunna ha många olika alternativ till hands för hur man kan placera entiteter i förhållande till varandra ökar vilken uttryckskraft vi kan få till för att förmedla hur sake och ting hänger ihop.

Specialisering (subtypning)

De finns en helt annan typ av relation mellan entiteter. Det är när en entitet (subtyp) är en mer specialiserad variant av en annan entitet (supertyp).

Ett exempel kan vara att faktabok och skönlitterär bok (subtyper) är två specialiseringar av bok (supertyp).

I UML markeras det med en ofylld triangelformad pilspets i änden på associationslinjen i riktning mot supertypen. Jag använder den symbolen när så är lämpligt. (När jag inte använder notationen att subtypen är inskriven i supertypen.)

Specialisering kan som exemplet visar ritas med indrag på samma sätt som jag visat ovan för mängd och sammansättning.

Exempel från verkliga informationsmodeller

Här har vi två exempel på hur hierarkier med indrag kan se ut i verkliga diagram.

Hur gör du?

Det här är ju till stor del mina egna idéer om hur man i ett ER-diagram kan representera olika vanliga strukturer hos företeelser i en verksamhet. Du har säkert andra idéer. Berätta gärna!

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 28 april. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

PS Vi har tyvärr varit tvungna att ta bort möjligheten att kommentera på artiklarna för en tid. Har du tankar om innehållet i artikeln som du vill dela? Välkommen att kommentera på vår linkedin där lägger vi ut en post vid varje publiceringstilfälle. Eller skicka ett mail till Peter Tallungs: peter.tallungs(at)irm.se

Historier från dataträsket del 2: Hur jag lärde mig vad som är viktigt i ett dataintensivt projekt

Vad är egentligen viktigt i ett projekt som involverar data i stor mängd?
Det här är en historia jag brukar dra ibland. Den handlar om banken som gick vilse och hittade rätt igen.

Det var 00-tal och jag hade ett uppdrag på en större bank. Jag fick då en förfrågan från en annan del av banken om jag kunde ta ett annat litet uppdrag vid sidan om.

Bakgrunden

På den tiden hade alla banker gjort vad de kunnat för att uppfylla kraven för regelverket Basel 2.
En anpassning till Basel 2 krävde omfattande analys- och rapporteringsmöjligheter och därmed en mycket genomgripande integration och analys av data från många olika källor. Att inte uppfylla de hårda kraven, att bli underkänd av Finansinspektionen, skulle bli mycket mycket dyrt för banken.

Banken hade genomfört ett mycket trassligt Basel 2-program och klarat kraven men endast nätt och jämnt, och med många anmärkningar. Finansinspektionen hade en dryg lista på åtgärder vilka man krävde att banken skulle åtgärda omedelbart, för att inte sänka bolaget.

Ledningen var nervös och hade skapat ett särskilt team, en ”special task force”, för att hantera problemen. Men tiden gick och de hade inte kommit någon vart. Teamet, som bestod av olika mellanchefer, förstod varken problemen eller vad man kunde göra. Av någon anledning vände man sig till mig, och bad mig att utreda saken. Jag tyckte inte att jag hade tid och tackade nej. Men de återkom efter några veckor och bad mig på nytt om jag i varje fall kunde göra en snabbutredning. Denna gång kunde jag inte tacka nej.

Mitt uppdrag

Det var bara att börja. Jag fick namn på några nyckelpersoner jag kunde intervjua. Både sådana som varit med om själva Basel 2-projektet och som hade tagit fram lösningen, och de som ingick i det förvaltningsteam för lösningen som jobbade med att försöka komma till rätta med bristerna.

Vad jag fick reda på om det genomförda Basel 2-projektet

På så sätt fick jag så småningom reda på hela historien, utifrån olika synvinklar. Projektet visade sig ha varit något av en mardröm. Det här var en bank med en stor och kompetent it-avdelning, väl rustat för ett sådant stort projekt. Man hade egenutvecklade system som fungerade bra, och utvecklade nya lösningar i god takt.

Men när det kom till Basel 2 hade något gått snett mellan verksamhet och it. Jag fick inte klarhet i precis vad som hade hänt. Det gick rykten och det hela var ett känsligt ämne. Kanske att it-sidan inte fick den budget de tyckte att de behövde för att genomföra den stora förflyttningen. Kanske att it-folket då upplevdes som krångliga att jobba med. Verksamhetsledningen vände sig i stället till en it-leverantör som sade sig ha ett standardsystem som hade en färdig lösning för Basel 2. Leverantörens säljare påståstod att de skulle genomföra projektet på tre veckor. En vecka för dataanalys, en vecka för att konfigurera systemet och en vecka för att ta fram de rapporter som krävdes. Jag tror att det kan ha varit detta som fick it-avdelningen att helt och hållet ta sin hand från allt som hade med Basel 2 att göra.

Det tog såklart lite längre tid än tre veckor. Leverantörens folk hade mycket dålig kunskap om hur man genomför ett sådant stort projekt. Och de fick nog inte mycket hjälp från it-sidan, skulle jag tro. Ryktet sa till exempel att leverantörens folk först ett år in i projektet förstod att bolaget hade verksamhet i fler länder än Sverige.

Men efter två års arbete fanns det inte mycket att göra, alla tidsfrister hade gått ut och man fick med knapp nöd godkänt av Finansinspektionen, fast med en lång restlista.

Vad jag fick reda på om Basel 2-lösningens ursprungliga förvaltningsteam

Efter driftsättningen hade man skapat ett särskilt förvaltningsteam som skulle beta av problemen. Det verkade som om it-avdelningen fortfarande inte ville ta ansvar på riktigt utan bemannade med folk från lite olika håll, bland annat från ett uppköpt bolag. När jag kom in i bilden hade detta pågått till ganska nyligen och upplevelsen var att de inte kom framåt, trots en stor bemanning. Och Finansinspektionen låg återigen på och hotade med stränga åtgärder.

Jag intervjuade några som varit inblandade. De vittnade om att arbetsprocessen för förvaltningen hade varit mycket byråkratisk. Den leddes av personer som inte hade det pragmatiska sättet att samarbeta som de var vana vid. Verksamheten, som till största delen var bankens riskanalytiker, var frustrerade. De var tvungna att komma in med en skriftlig begäran om vad man ville ha gjort innan teamledaren initierade åtgärd. Riskanalytikerna visste sällan själva vad som var felet och hade därför svårigheter att ens specificera vad de ville ha gjort. Och att föra en dialog med förvaltningsteamet var tydligen helt uteslutet. Förvaltningsledaren ville ha en tydlig och kontrollerad inkanal och en process som förhindrade vad han upplevde som smitvägar.

Den överraskande vändningen

Så här hade det varit fram tills ett par månader innan jag blev inkopplad. Bolagsledningen och den särskilda utredningsgruppen var vid det läget stressade. Kraven från Finansinspektionen tycktes vara omöjliga att uppfylla av förvaltningsteamet, trots en stor bemanning och skenande förvaltningskostnad.

Men det hade just då hänt något som ännu inte nått deras öron. Något som i ett slag förändrade bilden. Jag fick reda på det hela från riskanalytikerna.

Teamledaren från förvaltningsteamet hade gått hem på föräldraledighet. It-ledningen hade då passat på att ändra bemanningen. Man hade tillsatt en förvaltningsledare som var mycket mera smidig, samt skickat in två erfarna män i teamet för att leda arbetet rent praktiskt. Då förändrades allt i ett slag.

Det intressanta var vad de två garvade männen kunde och vad de gjorde. Och än mera intressant vad de inte kunde. De hade inte alls den kunskap man kanske skulle kunnat förvänta sig ge resultat. De hade inte kunskap om vare sig Basel 2-regelverket, Basel 2-lösningen eller Business Intelligence, som det ju i mångt och mycket handlade om.

Men i stället kunde de något annat, vilket visade sig vara det viktiga. De hade god kunskap om bolagets alla operativa system, och de källdata som fanns där och som födde Basel 2-lösningen. Och de visste vem de skulle ta en snabbfika med för att reda ut det de inte visste. Och framför allt, de hade ett helt annat arbetssätt än förvaltningsteamet hade haft fram till dess. I stället för att vänta på en beställning på exakt vad verksamheten ville ha gjort, förde de en dialog med de viktiga verksamhetsanvändarna, det vill säga riskanalytikerna. De ställde sig framför en whiteboard tillsammans med verksamhetsanalytikerna och diskuterade problem och lösningar. Riskanalytikerna jublade över skillnaden. Att det inte längre handlade om en envägskommunikation där en part ställde krav och den andra parten levererade lösning. Utan att man tillsammans diskuterade problem och möjliga lösningar och prövade dessa i små steg.

Dessa två medelålders män hade inte gått någon Agile-kurs. Jag är osäker på om de ens hade hört talas om moderna agila arbetssätt. Men de visste av erfarenhet att ett tätt och kontinuerligt tvär-funktionellt samarbete var det som krävdes.  

Så allt gick helt plötsligt åt rätt håll nu. Det fanns mycket att göra, men man betade av saker och ting i en stadig takt.

Min rekommendation till ledningen

För mig var det bara att avsluta utredningen och skriva rapport. Jag föredrog för utredningsteamet och it-ledningen vad jag kommit fram till. Det är nog det trevligaste jag någonsin rapporterat. För jag rekommenderade att man bara hade att fortsätta på samma sätt. Det fanns mycket att göra framöver, men det hände saker, och allt var på väg åt rätt håll. Fast mitt budskap att man inte fick skära ner budgeten förrän man kommit längre i att beta av problemen fick några pannor i församlingen att rynkas.

Vad jag lärde mig

Sensmoralen tycker jag är följande: Kunskap om data är avgörande, viktigare än annat, i alla satsningar som är dataintensiva. Och kanske ännu viktigare är ett nära och informellt och interaktivt arbetssätt.

Allt annat väger ganska lätt. Samt: Lita inte på standardsystem-säljare. De vet sällan vad de talar om.

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 14 april. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

PS Vi har tyvärr varit tvungna att ta bort möjligheten att kommentera på artiklarna för en tid. Har du tankar om innehållet i artikeln som du vill dela? Välkommen att kommentera på vår linkedin där lägger vi ut en post vid varje publiceringstilfälle. Eller skicka ett mail till Peter Tallungs: peter.tallungs(at)irm.se

Historier från dataträsket del 1: Hur jag lärde mig att verksamhetsexperter inte kan allt

Jag tänker att jag i några artiklar ska berätta några historier som jag varit med om, och som man kan reflektera över. Först ut är historien om hur jag på ett ganska brutalt sätt lärde mig grunden i vad det innebär att modellera en verksamhet. Eller snarare vad det inte innebär. Hur man absolut inte ska göra.

Låt mig berätta en historia jag tänker på ibland. Det var en gråkall vårvinter i Stockholm i början av 90-talet. Jag var färsk från universitetets datalinje och hade fått mitt första jobb som systemutvecklare. Ett försäkringsföretag behövde ett administrativt system som skulle fungera som en central punkt i verksamheten. Det fanns redan färdiga informations- och processmodeller som skulle fungera som specifikation. De hade tagits fram i en serie workshops ledda av ett konsultbolag. Så nu var det bara att bygga efter ritning. Det vill säga att de var så det sades.

Men alla som varit med i branschen vet ju att sådana i förväg framtagna specifikationer är tämligen intetsägande. Vanligen är de på samma gång dels alldeles för grova och dels alldeles för detaljerade. Där de går ner lite mer i detaljer blir det nästan utan undantag fel. Orsaken är nog självklar för de flesta idag. Det går inte att i förväg specificera vad som verkligen behövs. Utveckling måste alltid vara iterativ, man måste experimentera sig fram, ställa upp hypoteser, prova vad som fungerar och modifiera alltefter man lär sig.

Men på den tiden, och även långt senare, fanns det en naiv tro på att man kunde specificera saker i förväg. Det var en hel industri, konsultbolag som tog fram hela pärmar av modeller och specifikationer. Det finns det nog fortfarande de som gör, men det är ovanligt.

Det var uppenbart för mig redan efter första dagarna att jag måste ta fram allt från grunden, inte minst en datamodell att basera databasen på. Pärmen jag hade fått i handen var inte till mycket hjälp, annat än att den i varje fall ringade in vilka områden man hade tänkt sig att man behövde it-stöd för.

Nåväl, jag satte igång med ungdomlig energi. Mest handlade det om att se vilka data som hanterades idag och vad man tyckte sig ha behov för framöver. Det gick ganska lätt. Men några begrepp hade jag svårt för. Ett av dessa var det mest centrala begreppet ”Försäkring”. Som alla vet som har sitt boende eller bil försäkrad så får man ju en ny version av försäkringen varje år. Är det då en ny försäkring eller är det samma?

Mitt första möte med en verksamhetsexpert  

När jag besvärade kontorsfolket med denna och andra frågor blev jag hänvisad till Arne, bolagets mest seniora expert. ”Arne kan allt. Han är en legendar i branschen”. Vad bra tänkte jag, nu kan jag få riktigt bra svar på mina frågor. Så här gick min intervju:

Jag: Det som löper över flera år, är det en försäkring?

Arne: Ja.

Jag: Det som jag får nytt varje år, vad är det?

Arne: En försäkring.

Jag: Men du sa ju att det som löper över flera år är det som är en försäkring?

Arne: Jo.

Jag: Men det är ju olika saker?

Arne (nu lite irriterad): Ja, men det är en försäkring.

Och så vidare. Så höll vi på ett tag. Och Arne började nu bli röd i ansiktet.

Då fick jag infallet att passa på att reda ut något annat. Nämligen vad den korrekta termen är för själva det papper man får hem som det står ”Försäkring” på. Det var ingen bra idé. Arne kallade också detta för ”försäkring”.

Nu var jag förvirrad och mina upprepande frågor och påpekanden att vi behövde skilja på de olika men närliggande företeelserna. Det fick till resultat att Arne stod och dunkade försäkringsbrev i skrivbordet, så att askkoppar och aska flög. (Jo, man rökte på kontor på början av 90-talet. Svårt att tro idag.) och upprepande högljutt: ”Det här är en försäkring. Och det här. Och det här.”

Jag lämnade Arnes flotta hörnrum med tanken att det blir nog inte så lätt i den här branschen. När inte verksamhetsexperter kan svara på de mest enkla frågor.

Varför berättar jag denna historia? Jo, jag tycker att i den finns en sensmoral. Men först måste jag bara säga vad jag så småningom lärt mig i själva sakfrågan, vad de korrekta termerna är för de företeelser som jag undrade över. För det första: Inget av det jag nämnde heter formellt sett ”försäkring” även om det används som en vardaglig term. Det man tecknar med ett försäkringsbolag är ett avtal om försäkring, ett ”försäkringsavtal”, även om ingen använder det ordet till vardags. När avtalet förnyas årligen blir det rent juridiskt sett ett nytt avtal. Men i praktiken, ur alla vanliga aspekter, ser man det som en ny version av samma avtal. Man kallar då varje version för ”försäkringsavtalsversion”, om man ska vara korrekt, men oftast bara ”försäkringsversion”. Det dokument som manifesterar avtalet kallas, som alla nog vet, ”försäkringsbrev”.

Vad jag lärde mig

Men hur var det med sensmoralen i historien? Jo, jag tänker att det jag lärde mig den hårda vägen var att när man vill analysera, förstå och beskriva en verksamhet räcker det inte med att fråga verksamhetsexperter. Man kan inte förvänta sig att experter så där enkelt och rakt ska berätta för en hur deras verksamhet fungerar. Att vara bra på en verksamhet betyder inte att man nödvändigtvis kan beskriva den på ett tydligt sätt. Jag har absolut inga tvivel på att Arne var bland de bästa på området och klart och tydligt kunde skilja på de företeelser jag frågade honom om. Men det betyder inte att han därmed kunde benämna och definiera dessa saker på ett sätt som var användbart för mitt syfte.

Det är mitt jobb, som informationsarkitekt att analysera, beskriva och benämna de begrepp som verksamheten behöver. Inte någon verksamhetsexperts. Jag måste förstås fråga och föra en dialog med olika verksamhetsexperter. Men inte bara det, jag måste forska och tänka själv också. Jag kan aldrig förvänta mig att verksamhetsexperter ska vara bra på att analysera och beskriva de begrepp de använder.

Mitt andra möte med verksamhetexperter

En tid senare, när jag tyckte att jag fått ihop en någorlunda klar databasdesign, så var det en sak som återstod innan jag kunde påbörja konstruktionen. Vi behövde bestämma detaljer som fältlängder, värdeförråd, vad som skulle vara obligatoriska termer etcetera. Jag och datachefen fick då den strålande idén att göra detta i ett stormöte. Det vill säga, vi själva var väldigt nöjda med idén. Representanter från verksamhetens alla hörn skulle få vara med och bidra med sin kunskap. Intresset visade sig emellertid vara lågt, det grymtades att man minsann hade viktigare saker att göra, viktiga kundmöten och nya avtal som man behövde få fram. Men vi trumfade igenom ett stormöte till slut, med många deltagare, allt från chefer och stjärnsäljare till sekreterare och assistenter. Vi började ställa våra frågor. Hur långt kan ett kundnamn vara? Hur stort belopp kan en försäkringspremie vara på? Måste en försäkring alltid ha provisionsprocenten angiven?

Irritationen växte i salen. Varför ska jag var med här tyckte vissa, det här är inte mitt område? Andra: ”Det här är en teknisk fråga, jag har bättre saker att göra”. Varje fråga möttes av vilda gissningar, ointresse, och ifrågasättande av om detta var deras sak. Folk började droppa av. Det gick så långt att vi fick avbryta.

Vad jag lärde mig denna gång

Vad var sensmoralen denna gång? Jo, densamma. Verksamhetsfolk kan inte allt, kan inte i detalj veta vad de behöver, har inte alltid rätt. Och bryr sig ofta inte ens. Verksamhetsexperter är inte kunniga på alla aspekter på sin verksamhet. Det är jag som verksamhetanalytiker som måste använda olika metoder och källor och rätt avväga och räkna ut hur saker hänger ihop.

Då det gäller så enkla saker som, fältlängder och existensregler för olika fält är det enklast att tröska igenom befintligt data efter extremvärden.

Jag tänker ibland på dessa händelser. Jag var oerfaren och naiv. Fast hur skull jag kunna veta att experter inte kan ge vettiga svar på frågor inom sitt område? Just dessa aspekter var ju inte deras område förstås. Borde jag ha förstått det i förväg? Kanske inte, men jag borde i varje fall ha varit mer uppmärksam när jag fick tecken på att så inte var fallet. Inte vara lika envis och mer eller mindre kräva att de skulle kunna svara. Idag hoppas jag att jag är mer ödmjuk när det gäller förväntningar på vad andra ska kunna, även sådana som är experter. Det hela kokar ner till att verksamheter är komplicerade ekosystem och ingen kan vara expert på alla aspekter av något så mångfacetterat.

Jag tycker att det illustrerar något grundläggande om kunskap och hur vi finner den. Vi ska fråga, fast inte förvänta oss att alltid få de svar vi behöver ha. Kanske du tycker att denna historia visade något du redan vet. Och det hoppas jag. Men i så fall kan den kanske tjäna som en påminnelse om vilken naiv bild andra kan ha av vad vi gör, vi som jobbar med modellering, att vi bara frågar och tecknar ner vad experter säger.  

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 7 april. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

PS Vi har tyvärr varit tvungna att ta bort möjligheten att kommentera på artiklarna för en tid. Har du tankar om innehållet i artikeln som du vill dela? Välkommen att kommentera på vår linkedin där lägger vi ut en post vid varje publiceringstilfälle. Eller skicka ett mail till Peter Tallungs: peter.tallungs(at)irm.se

Informationsmodellering: Hur vi kan namnge relationer

Jag vill ge ett alternativ till den vanliga principen för att namnge relationer mellan entiteter i informationsmodeller. Syftet är att namnen ska överensstämma med namnen för de verksamhetsbegrepp som relationerna representerar. Vi får därmed en spårbarhet från relationerna i våra informationsmodeller till termer i verksamheten och i informationssystemen.

Den vanliga principen för namngivning

Det vanliga är att namnge relationer så att relationsnamnet tillsammans med entitetsnamnen blir mer eller mindre en verbal mening som går att uttala.
I exemplet till höger blir det ”Beställning läggs av Kund”. Det är tänkt att hela ER-diagrammet då blir läsbart som ett antal verbala uttryck. Det är en fördel, speciellt då det gäller ovana läsare av ER-diagram, och i varje fall då det gäller enklare diagram, det vill säga där man bara har ett antal entiteter och relationer och inga attribut.

Men jag menar att den principen för namngivning också har ett antal nackdelar, och att dessa tillsammans vida överskuggar fördelen. Jag beskriver problemen i det följande.

Problem 1: Namnen blir ofta intetsägande verb

Det blir ofta nästan omöjligt att undvika att relationsnamnen blir intetsägande verb som ”har”, ”tillhör”, ”är”. När vi talar så har dessa allmänna verb en funktion, men de kan aldrig fungera som verksamhetbegrepp. De beskriver inte vad relationen står för, i detta exempel vilken roll en kund har i en beställning. En relation har alltid en mening. De namn vi ger saker och ting bör uttrycka den meningen så klart och tydligt som möjligt.

Problem 2: Namnen uttrycker ofta handling

Om man vill undvika de mest allmänna verben, se ovan, så blir relationsnamnen ofta i stället verbsatser som uttrycker någon form av handling i tiden, som ”läggs av” i exemplet ovan. Problemet med sådana namn är just det att de uttrycker handling, det vill säga en process. Det fungerar inte så bra i en informationsmodell, som ju ska vara processneutral. Modellen ska bara uttrycka vilken information som kan finnas, inte hur den skapas.

Alla beställningar har en beställare, men så snart beställningarna finns så är beställningarna redan lagda. ”Läggs av” är historia, det var något som skedde någon gång, i det ögonblick beställningen gjordes. Det gör att informationsmodellen får drag av process, vilket är falskt. ”Lagd av” vore mer korrekt i så fall, men är ändå inte bra, eftersom det mer talar om hur relationen skapades än vad den innebär.

Problem 3: Namnen blir inte verksamhetstermer som kan användas i andra sammanhang.

Den kund som lagt en beställning är ”Beställare” på beställningen. Det är en egenskap hos en beställning. En relation är således alltid en egenskap hos en entitet samt också ett verksamhetsbegrepp som bör definieras, beskrivas och normeras. Det är det vi har informationsmodellens textdel till. Och där kan egenskapen inte heta ”Läggs av” eller ”Har”. Knappast heller ”Kund” eftersom det namnet bara uttrycker vilken klass av objekt som utgör värdeförråd för egenskapen, och inte vad relationen har för mening.

Sedan ska relationen realiseras i olika sammanhang. Den kanske blir en; databaskolumn, variabel i programkod, fält i en fildeklaration, ruta i användargränssnitt eller term i en rapport? Då, om inte tidigare, behöver vi ett tydligt namngivet, definierat och normerat verksamhetsbegrepp. Detta är enligt min mening informationsmodellens jobb. Precis som vi gör med entiteter och attribut. Då fungerar termen ”beställare”, men knappast de intetsägande namnen man ofta ser i informationsmodeller.

Vad vi vill med namngivning

Vi kan tänka efter vad vi egentligen vill med namnen, vad som är ett bra namn. Ett namn ska förstås vara så korrekt och tydligt som möjligt men också så användbart som möjligt. Det innebär att det ska fungera i så många olika sammanhang som möjligt, det vill säga alla de sammanhang som informationsmodellen kan komma att användas i. Man brukar ibland uttrycka det som att informationsmodellen ska vara process-agnostisk, det vill säga inte ha något spår av hur företeelserna kommer till eller hanteras, bara att de finns och vad de har för mening.

Jag tycker att det är viktigt att våra modeller, blir användbara som underlag för implementationer av informationssystem av olika slag. Det kan vara databaser, programkod, filer, meddelandescheman, användargränssnitt, api:er, rapporter med mera. Vi normerar ett språk för allt det som hanteras och presenteras. Då gäller det att de namn vi väljer blir så användbara som möjligt. Men då måste vi ha en namngivning som är så pass användbar att den verkligen fungerar i skilda sammanhang.

Men jag vet att det finns en mer traditionell uppfattning som säger att det inte är något värde att försöka tillämpa samma namngivning i informationsmodeller som i fysiska sammanhang. Man ser det som olika världar som ska hållas isär. Vi gör konceptuella modeller och bryr oss inte alls om det ”tekniska”, säger man. Man är alltså inte bekymrad för om informationsmodellen säger något om den fysiska verkligheten, eller ens om den är användbar i praktiska sammanhang.

Jag är av motsatt åsikt. Jag menar att vi så lång det går bör jobba ihop, tvärs över alla roller i organisationen och så långt det går ha gemensamma modeller. Det är ju det modeller är till för, att ge oss en gemensam bild, en gemensam förståelse att jobba med och att utveckla tillsammans.

Nyckeln är ”så långt det går”. Det kommer alltid att finnas skillnader mellan modeller och det modellerna används till, men låt oss sträva efter att hålla dessa så små som möjligt. Detta är en princip som kommer från den filosofi som heter ”domändriven design”, och som jag tycker är helt avgörande för vilken nytta våra modeller ska kunna ge. Jag har skrivit om detta synsätt i många tidigare artiklar.

Mitt förslag till namngivningsprincip

Mitt förslag är en namngivning som jag tillämpat i ett par decennier och som jag tycker fungerar bra.

En relation är egentligen inget annat än en egenskap hos en entitet. Närmare bestämt en egenskap som innebär att entiteten har en relation till en annan entitet. Man kan också uttrycka det som att egenskapen har ett värdeförråd (en värdedomän) som definieras av den andra entiteten, det vill säga den klass av företeelser som den andra entiteten representerar. I exemplet, som är genomgående i denna artikel, är det Beställning som har egenskapen ”Beställare”, som enligt ER-diagrammet är en obligatorisk egenskap och som har ett värdeförråd (möjliga värden) som är mängden av alla kunder.

Allt det vi behöver definiera och beskriva för övriga attribut behöver vi också beskriva för de attribut som manifesterar relationer, såsom namn, synonymer, beskrivningar, värdeförråd, format och regler. Varför ska vi då behandla relationer på andra sätt än andra attribut?

Låt oss se hur det blir när vi beskriver detta med hjälp av attribut.
Namnet på attributet skulle jag skriva ”Beställare – Kundnummer”. Ofta blir namnet lite mer specifikt än vad relationen heter. Vi vill ju kunna säga att i detta fall är det beställarens kundnummer som är egenskapen.
En del kanske tycker att man kan utelämna suffixet ”Kundnummer”. En främmande nyckel ska ju ändå alltid peka på primärnyckeln i den entitet den pekar på. Men jag föredrar att ha med det ändå. Man kan inte vara nog tydlig. Det kan ju också finnas till exempel ”Beställare – Namn”.

Nu har vi fått en tydlig spårbarhet mellan diagram och de attribut man beskriver i textdelen av modellen.

Det finns de som reagerar på det osköna i redundansen i detta sätt att göra, det vill säga att samma sak beskrivs två gånger, en gång som relation och en gång som attribut. Att en beställning har en kund som beställare beskrivs både med relationslinjen och med attributet. Man kan då undra om det är samma sak eller inte. Jag förstår invändningen, men menar att den väger lätt. Jag tycker att det är ett pris värt att betala, bara man är tydlig med namngivning och beskrivning.

Namngivning enligt databasstandard

Det finns en annan princip för namngivning av attribut som manifesterar relationer som man ofta stöter på och därför är värd att nämna. Det är det namnskicket som är vanligt i databassammanhang. I en traditionell databas är ju en relation manifesterad som en databaskolumn, vilken är en främmande nyckel, det vill säga den innehåller värden som återfinns som primärnyckel i en annan tabell. Då brukar man ge den kolumnen samma namn som den tabell och kolumn den pekar på. I exemplet ovan skulle då attributet heta Kund.Kundnummer. Fördelen för databasdesigners är att detta namnskick underlättar så att man automatiskt kan hantera relationer. Fast jag tycker att det namnskicket inte passar för en bredare användning. Man säger visserligen att kolumnen innehåller ett kundnummer men det viktigaste tycker jag ändå är att uttrycka relationens mening.

Relationers riktning

Inom traditionell data- och informationsmodellering har relationer inte någon riktning. Det beror på att informationsmodellering har ett ursprung i relationsdatabasdesign. I en relationsdatabas kan en relation traverseras i vilken riktning som helst, till exempel med frågespråket SQL. Däremot så har relationsnamnet alltid en viss läsriktning, det vill säga namnet är tänkt att läsas från en bestämd entitet till den andra. Man kan dock lika gärna behöva sätta ett namn med motsatt läsriktning. Eller ha två namn, ett åt vartdera hållet. Det finns de som förespråkar det.

Men så fungerar inte alla modelleringsspråk. I klassmodeller i UML är det annorlunda, därför att UML ursprungligen är framtaget för att strukturera objektorienterad programkod. Där har relationer alltid en bestämd riktning. Om man i programkod vill kunna traversera i båda riktningarna behöver vi skapa två relationer, en för vardera riktningen.

I programkod, liksom i olika språk för datascheman, är det dessutom vanligt att relationer går åt hållet från en till många. I programkod skulle förmodligen en kund ha en kollektion av pekare till de beställningar kunden är beställare på.

Allt detta gör att det är viktigt att vi pekar ut riktningen för våra relationer, vare sig det rör sig om att relationen verkligen har en bestämd riktning eller det handlar om läsriktning för det namn vi väljer att ge den. Jag gör det med en liten fylld pilspets som i exemplet.

En annan fördel med en sådan pilspets vid relationsnamnet ges exempel på här till höger. Ibland har man många relationslinjer som går ut vertikalt från en entitet. Då kan en sådan pilspets tydligt markera vilket namn som hör till viken relationslinje. Se de relationer som går vertikalt uppåt från entiteten ”Card Activity”.

Låt oss diskutera och utveckla vårt område!

Allt detta är förstås bara mina egna erfarenheter och åsikter, inte en slutgiltig ”sanning”. Men det är något vi borde diskutera och utveckla. Jag har saknat en sådan dialog. Det är därför jag skriver dessa artiklar.

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 31 mars. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

PS Vi har tyvärr varit tvungna att ta bort möjligheten att kommentera på artiklarna för en tid. Har du tankar om innehållet i artikeln som du vill dela? Välkommen att kommentera på vår linkedin där lägger vi ut en post vid varje publiceringstilfälle. Eller skicka ett mail till Peter Tallungs: peter.tallungs(at)irm.se

Informationsmodellering: Om struktur i flera nivåer

I en informationsmodell med många ämnesområden har vi ett behov av att gruppera dessa i större områden. Det vill säga att etablera en övergripande struktur för modellen. Sedan finns det också ofta ett behov av att dela in ett enskilt ämnesområde i mindre avsnitt. På så sätt kan vi strukturera en informationsmodell i flera nivåer. Denna artikel visar hur vi kan gestalta denna struktur grafiskt i ett ER-diagram.

Gruppering av ämnesområden

Låt mig visa ett exempel, se bild I. Detta är ett utsnitt av ett ER-diagram som är en översikt av en större informationsmodell, vilken omfattar en hel verksamhet. Modellen som helhet har ett femtiotal ämnesområden. Förutom det översiktliga ER-diagrammet finns det ett detaljerat ER-diagram och detaljerade textuella beskrivningar för varje ämnesområde.
Du kan läsa mer om ämnesområden i artikeln Informationsmodellering: Om ämnesområden

För att få till en övergripande struktur räcker det inte med ämnesområdena. Det finns ett behov av en mer övergripande struktur. För detta skapade vi femton övergripande områden med upp till kanske sex-sju ämnesområden i varje.

Lägg märke till hur vi har gestaltat denna indelning grafiskt. Varje sådan grupp av ämnesområden bildar en egen avgränsad rektangel i ER-diagrammet, med extra luft runt och en rubrik över. För att tydligt ringa in varje grupp har vi gjort en bred grå linje över gruppen, på vilken grupprubriken är skriven. Linjen spänner över hela bredden på gruppen för att tydligt markera vilka ämnesområden som ingår i gruppen. Även grupprubriken är grå, för att den inte ska framhävas lika mycket som entiteterna.

Det är viktigt att både rubrik, definition och rubriklinje är gjord i en mörkgrå färg, i likhet med ämnesområdets rubrik. Det gör att hela den underliggande strukturen hamnar på ett mentalt plan som är mindre framträdande, för att inte förvirra vårt mönstersökande synsinne. Det gör att entiteterna och deras relationslinjer framhävs i förhållande till strukturen. Allt detta gör modellen tydligare. 

Det vanligaste sättet att gruppera saker i flera nivåer i en graf brukar annars vara att rita rutor i rutor. Men det bör vi undvika. Det blir svårare att överblicka. Förmodligen för att hjärnan hela tiden söker mönster, och om rutor ibland kan vara entiteter och ibland ämnesområden och ibland grupper av ämnesområden så går en del mental kapacitet åt till att hela tiden försöka skilja mellan dessa. Synsinnet belastas ju mycket av att leta mönster bland myllret av synimpulser och försöka ge dessa mening. Vad hör ihop med vad? Vad är parallella företeelser? Vad är viktigast? Låt oss då hjälpa till, genom att göra de mönster vi vill förmedla visuellt tydliga, och låt oss avstå från sådant som förvirrar.

Bild I Exempel på gruppering av ämnesområde

Vi har lagt till en definition under, eller efter, grupprubriken när vi tyckt att det behövts, skrivet med ett mindre typsnitt. Detta har vi gjort med ämnesområdenas rubriker också, liksom med entiteterna.

Vi älskar definitioner! Inget skapar så mycket förvirring och tveksamhet helt i onödan, som en modell utan definitioner. Ett namn kan stå för lite av varje, och ofta är man osäker på vad den som gjort modellen har tänkt sig. Definitioner i ER-diagrammet ger läsaren en betydligt bättre chans att förstå.

Att skriva definitioner tvingar mig som modellerare att tänka igenom vad jag egentligen menar, och hur det kan uttryckas tydligt. Vilket ofta leder till att jag för mig själv reder ut inkonsekvenser och oklara tänkesätt. Esaias Tegnér sa det väl: ”Det dunkelt sagda är det dunkelt tänkta”. När vi tvingas att uttrycka våra uppfattningar tydligt, till exempel genom att tydligt definiera våra modellelement så som entiteter, ämnesområden, attribut och relationer, blir vi nödgade att tänka klarare och tydligare. Jag kommer i en senare artikel att berätta om vad en bra definition är och vad den inte är.

Gruppering i två dimensioner

Ibland finner man att man att det vore bra att strukturera sin modell i två dimensioner. Då kan man ordna ämnesområdena i rader och kolumner med rad- och kolumnrubriker. Se exempel bild II.

Bild II Exempel på gruppering av ämnesområde i två dimensioner

Gruppering inom ämnesområden

Vanligen finns det även ett behov av att gruppera entiteter inom ett ämnesområde. Det underlättar ofta läsningen och förståelsen av modellen.

Då använder jag ett liknande sätt att rita som för grupper av ämnesområden. Det vill säga att jag skapar en rubrik på en bred horisontell linje där linjen dras ut så den tydligt markerar vad gruppen omfattar. Det som omfattas är alltid en eller flera entiteter men kan även inkludera andra modellelement. Se bild III.

Bild III Exempel på gruppering av entiteter inom ett ämnesområde

Viktigt att vi identifierar och gestaltar meningsfulla strukturer

Jag menar att det är viktigt att vi identifierar meningsfulla strukturer i vår verksamhetsdomän, samt att vi gestaltar dessa i vår modell. På så sätt kan vi skapa en mer tydlig gemensam karta över vår data-/informationsresurs, de företeelser som hanteras och vår verksamhetslogik. Detta har ett stort värde för vår gemensamma förståelse och lärande, och därmed för verksamhetens hela hantering och utveckling.

Varning för övertro på industrimodeller.

Men se upp för att använda en generell struktur för alla verksamheter du stöter på. Det har många gånger gjorts försök i olika branscher att skapa generella strukturer som fungerar för en hel bransch. Men det är omöjligt att bedöma om en sådan struktur skulle fungera för ens egen verksamhet innan vi ens har förstått och kommit överens om vår egen struktur. Ty varje typ av verksamhet har sin egen struktur. Till och med verksamheter i samma bransch har ofta ganska olika sätt att hantera saker. Det kan bero på att de har lite annorlunda gränsdragning mot partners eller leverantörer. Eller att deras produkt- eller tjänstestruktur är annorlunda uppbyggd.

Tyvärr ser man ofta en övertro på så kallade industrimodeller. Man har grovt generaliserade strukturer för en hel bransch, och försöker tvinga alla i samma mall. Det skulle kanske fungera någorlunda om man såg till att förstå sin egen verksamhet på djupet, och i detalj, där det trixiga gömmer sig. Det vill säga om man modellerade först. Men det var ju det man hoppades slippa genom att köpa in en industrimodell.

Dock finns det mönster som återkommer både inom branscher och också tvärs över olika branscher. Men det är något annat. Det är sådant vi ska hålla utkik efter. Det är ett spännande och outforskat område som det skulle vara intressant att gräva mer i. Men det är inte alls samma sak som att tro att man bara kan applicera en industrimodell för sin egen verksamhet.
För att läsa mer om problemet med industrimodeller se artikeln: ”Varför en industrimodell är en dålig idé”

Hur gör du?

Nu har jag berättat hur jag gör för att strukturera modeller. Berätta gärna hur du gör. Kanske kan vi lära oss mer tillsammans? Hör av dig via LinkedIn eller mejl, peter.tallungs@irm.se.

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 24 mars. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

PS Vi har tyvärr varit tvungna att ta bort möjligheten att kommentera på artiklarna för en tid. Har du tankar om innehållet i artikeln som du vill dela? Välkommen att kommentera på vår linkedin där lägger vi ut en post vid varje publiceringstilfälle. Eller skicka ett mail till Peter Tallungs: peter.tallungs(at)irm.se

Tio tips för bättre gestaltning av en informationsmodell

Jag ger här några enkla tips om hur du kan göra dina informationsmodeller tydligare. Tipsen förändrar inte modellen i sig, det vill säga vad modellen säger, utan endast hur den säger det den säger.

I min föregående artikel ”Vi kan göra bättre modeller – Om gestaltning med grafik och text” påstod jag att vi kan göra modeller som bättre förmedlar allt det vi vill förmedla. Jag planerar en rad artiklar om detta. Som en rivstart kommer här en liten guide med tio praktiska tips på hur du på ett enkelt sätt kan få dina modeller att bli tydligare.

Startläget

Bild I. Före alla ändringar

Tänk dig att du har följande ER-diagram, se bild I. Tänk dig också att du är nöjd med vad diagrammet visar. Det är precis så du vill uppfatta de företeelser som hanteras i den domän du beskriver. Det vill säga följande:

  • Man har kunder som kan lägga beställningar av färdiga paket av produkter.
  • En beställning kan avse ett eller flera produktpaket, där man också väljer hur man vill ha respektive paket förpackat.

Jag tycker egentligen inte att detta ER-diagram är uppseendeväckande dåligt. Jag har sett värre. Men ändå, jag menar att det finns utrymme för förbättring.

Jag ska visa hur vi med enkla medel kan förbättra diagrammet, steg för steg. Vi ändrar inte själva modellen, det vill säga det som modellen uttrycker, vilka företeelser som hanteras och hur de är relaterade till varandra. Resultatet blir i varje steg samma modell fast med en ny gestaltning.

Steg 1: Identifiera och rita ut ämnesområden för att ge modellen en geografi

En modell blir mer begriplig om man delar in den i olika ämnesområden. Ett ämnesområde är en del av en modell med företeelser som hör samman på något sätt, och gärna beskrivs tillsammans.

När jag får ett ER-diagram i min hand så är alltid det första jag gör att försöka ringa in olika delar av diagrammet så att varje del bildar en sammanhängande helhet av saker som hör ihop. I denna modell tycker jag att Beställning och Beställningsrad hör tätt ihop eftersom beställningsrader är delar av en beställning. Sedan tycker jag att Produkt, Produktpaket och Förpackningsalternativ hör samman eftersom de tillsammans utgör det som kunder kan beställa. Till sist får Kund bli ett eget område. (Bild nedan)

Bild II. Ämnesområden inringade

Det här sättet att dela in en modell är inte någon exakt vetenskap. Det finns ofta flera alternativ. Men det finns ändå vissa principer som avgör vad som bör hamna i samma ämnesområde. I senare artiklar återkommer jag till det ämnet.

Rita nu grå rektangulära ytor, en för varje ämnesområde. Flytta entiteterna så att de hamnar på rätt plats. (Bild III)

Ge ämnesområdena beskrivande namn. Försök placera ämnesområdena så att ordningen får någon slags mening. Här tänker jag mig att vi å ena sidan har kunder (de vi erbjuder saker) och å andra sidan har erbjudanden (det vi erbjuder våra kunder). Mitt emellan har vi det som knyter ihop dessa två kategorier av företeelser nämligen de beställningar som är lagda av kunderna.

Lägg märke till ritsättet:

  1. Ämnesområdena ritas som ljusa grå ytor, med mellanrum emellan.
  2. Ämnesområden bildar tillsammans en rektangel.
  3. Namnen på ämnesområdena skrivs med fetstil och med en mörkt grå färg.

Tillsammans gör detta att ämnesområdena bildar en neutral bakgrund för diagrammet. Indelningen tillför inte komplexitet utan reducerar komplexitet. Detta är en grundprincip för en bra gestaltning. Hur vi fångar och tillför så mycket kunskap och mening till modellen som möjligt, utan att i onödan tillföra komplexitet.

När jag handleder elever i informationsmodellering och visar dem detta steg blir de alltid överraskade av hur mycket tydligare modellen blir redan av detta första enkla steg. Till och med en så enkel modell som denna blir mycket tydligare. Tänk då hur det blir med modeller som är mycket mer komplexa. Och det handlar inte bara om hur jag kan kommunicera modellen till andra. Även jag själv ser och förstår modellen tydligare. Modeller är som sagt inte bara ett kommunikationsverktyg utan också – egentligen först och främst när man tänker efter – ett tanke- och analysverktyg.

Bild III. Efter steg 1: Ämnesområden inritade

Steg 2: Byt versaler mot gemener

Det är välkänt att versaler ger sämre läsbarhet än gemener. De gäller inte bara löptext utan även rubriker och dylikt. Därför är det bättre att skriva allt med gemener, förutom inledande versal på namn. (Bild IV)

Steg 3: Rita relationslinjer med vinkelräta linjer

När man har många relationer och de behöver dras lång väg blir det tydligare om linjerna dras vinkelräta än om de går kors och tvärs. (Bild IV)

Steg 4: Böjda hörn på relationslinjerna

Böjda hörn är att föredra. En fördel är följande: Hjärnan letar hela tiden efter mönster i synimpulserna. Hjärnan behöver då skilja mellan olika typer av hörn. Om hörnen på relationslinjerna skiljer ut sig tydligt från hörnen på entitetsrutorna så kan vi avlasta den kognitiva funktionen.
(Bild IV)

Bild IV. Efter steg 2, 3 och 4: Namn skrivna med gemener, relationslinjer med vinkelräta linjer och böjda hörn
Bild V. Reltationslinjen från Payment Batch ansluter en annan relationslinje. Den runda böjen gör att man ser vilket håll den tar vägen.

Detta kan tyckas som en liten sak, och är kanske det. Men det är enkelt att åstadkomma och det ger en effekt.

En annan fördel med böjda hörn på relationslinjerna är följande: När man drar flera relationslinjer till samma mål kan man dra dem tillsammans. Om man då ansluter linjen med en böj så visar man vilket håll en anslutande linjen tar vägen. Se exempel, bild V

Steg 5: Byt princip för namngivning av relationer

Relationer mellan entiteter är egentligen också attribut hos entiteter, och bör benämnas med en verksamhetsterm. Om vi som exempel tar relationen mellan Beställning och Kund som i diagrammet heter läggs av, se bild 5. Det är ingen verksamhetsterm. Verksamhetstermen för relationen är lämpligen Beställare, och är inte bara en relation utan manifesteras som en egenskap hos enbeställning med samma namn.Det attributet kommer behöva beskrivas med namn, egenskaper och regler, i modellens textdel precis som andra attribut. Det kommer också att behöva representeras av något dataelement, kanske en kolumn i en tabell eller liknande.  

Därför anser jag att principen för att namnge en relation i ett ER-diagram bör vara en princip som fungerar inte bara i diagrammet utan också i övriga delar av modellen, samt i alla övriga sammanhang där relationen förekommer i verksamheten. En informationsmodell som kommer till användning i en verksamhet normerar ju ett verksamhetsspråk. Och Beställare är då en verksamhetsterm som vi bör definiera och beskriva i vår modell. Läggs av är inte på samma sätt en verksamhetsterm, den har ingen mening utanför detta diagram, och inte ens någon mening utanför den linje den är placerad på.

Jag vet att detta går emot det som brukar läras ut. Men om vi ska utveckla vårt kunskapsområde behöver vi vara beredda att ompröva ingrodda ”sanningar”.

Lägg också märke till att en relation, inte bara en entitet, alltid hör till ett visst ämnesområde. Beställare är en relation/egenskap hos en beställning och hör därmed till ämnesområdet Beställningar, och inte till Kunder. Därför bör relationslinjens etikett, namnet på relationen, alltid placeras hel och hållen inom ämnesområdet i diagrammet. (Bild 5)

Steg 6: Markera läsriktning för relationsnamn

Namnet på relationer är alltid avsedd att läsas i en viss riktning. Gör det tydligt med en lite pilspets som det visas i exemplet nedan, bild VI

Bild VI. Efter steg 5 och 6: Relationer namngivna med verksamhetsbegrepp och som egenskaper, och med läsriktning markerad

Steg 7: Lös upp många-till-många-relationer

Modeller blir tydligare om man uttrycker många-till-många-relationer som entiteter i sin egen rätt. Se entiteten Produkt i produktpaket i bild VII nedan.Lägg märke till namnet. Precis som övriga entiteter så bör man vara noga med att ge den ett namn som uttrycker vad en enskild förekomst av entiteten står för. En förekomst av den entiteten uttrycker ju fakta att en viss produkt förekommer i ett visst produktpaket.

Steg 8: Placera en entitet som är underställd en annan entitet under denna och med indrag

I exemplet nedan, bild VII, så är Beställningsrad underställd Beställning i den meningen att den förra är en del av den senare. Samma gäller för Produkt i produktpaket i förhållande till Produktpaket. Det framgår tydligt att de hör samman i en hierarki på det sättet om man placerar Beställningsrad och Produkt i produktpaket i diagrammet som jag har gjort, under och med ett indrag. Ofta har man flera underställda entiteter och ibland i flera nivåer. Då blir det ännu viktigare att vi tydligt visar hierarkin.

Lägg också märke till att jag fann det tydligare att bryta ut Produkt till ett eget ämnesområde. Detta eftersom man i detta fall inte erbjuder produkter till kunder annat än som ingående i paket. (Bild VII)

Bild VII. Efter steg 7 och 8: Många-till-många-relation upplöst. Underställda entiteter placerade för att uttrycka beroendet.

Steg 9: Skriv entiteternas definitioner i entitetsrutorna

Om man tar med definitionen i entitetsrutan så får läsaren en extra möjlighet att förstå vad entiteten står för. Definitioner är mycket centrala delar av en informationsmodell. Egentligen mer centrala än namnen. Namnen är viktiga som mentala ”etiketter”. Men det är definitionerna som uttrycker vad företeelserna i fråga är för något. (Bild VIII)

Bild VIII. Efter steg 9 och 10: Relationer som innebär komposition (beroendeobjekt) särskilt markerade. Definitioner i entitetsrutor.

Steg 10: Markera beroendeobjekt

Vissa relationer där en entitet är underställd en annan entitet innebär en starkare bindning än andra. Den underställda entitetens livscykel är då sammankopplad med den andra entiteten. Till exempel kan en beställningsrad inte existera utan att den hör till sin specifika beställning. Den kan alltså varken existera självständigt eller byta vilken beställning den är en del av. Det är en permanent relation. Det är en viktig egenskap hos relationen men den uttrycks inte av den vanliga 1–1-relationen. En vanlig min 1- max 1-koppling säger ju bara att beställningsraden alltid måste var knuten till precis en beställning, men inte att det alltid måste vara samma beställning. I en del notationer kallas det för beroendeobjekt.

Jag tycker att mina modeller blir tydligare om jag markerar vilka entiteter som hör samman på det här starka sättet. En beställning och dess beställningsrader är inte olika informationsobjekt, utan beställningsraderna är integrerade delar av en beställning med ett existentiellt beroende. Det vill säga att en beställningsrad inte kan existera oberoende av sin beställning.

Bild IX. Composition (beroendeobjekt) i UML

I UMLs klassmodeller kallas den relationen sammansättning (composition) och uttrycks med en romb. Egentligen ska romben vara fylld men den symbolen finns inte som standard i Visio så jag brukar nöja mig med en ofylld. (Bild IX)

Inom parentes sagt: Den ofyllda romben uttrycker i UML en mängd (aggregation), vilket i praktiken är samma som en vanlig association med en min 1 – max 1-koppling. Därför är symbolen tämligen meningslös i UML. Jim Rumbough, en av grundarna till UML, liknade den vid placebo och Martin Fowler ägnar en hel uppsats till att avfärda konstruktionen.

Jag har skrivit om detta tidigare, i artikeln ”Saker jag stjäl från UML”.

Vad har vi gjort egentligen

Lägg märke till att vi inte på minsta sätt har förändrat modellen, endast dess gestaltning. Diagrammet som det blev till slut uttrycker exakt samma modell som diagrammet gjorde från början, det vill säga vi har inte ändrat något i vår bild av vår förståelse av det som avbildats. Det vi har ändrat är endast gestaltningen, det vill säga sättet modellen säger det den säger.

Bild X. Från före alla ändringar till efter steg 9 och 10: Relationer som innebär komposition (beroendeobjekt) särskilt markerade. Definitioner i entitetsrutor.

Men jag menar att skillnaden är avsevärd. Jag vill på detta sätt visa hur vi med mycket enkla medel kan få till mycket bättre informationsmodeller. Det är därför jag tycker att det är så viktigt att vi börjar diskutera gestaltning av modeller och utveckla sättet vi gestaltar på. Målet för mig är inte att alla skall göra som jag. Pröva själv, på dina egna diagram. Se om du tycker att det blir någon skillnad. Min vilja är att vi kommer loss från den dogmatik och förstening som rått i några decennier nu, och att vi kan börja utveckla vårt område. Låt oss pröva olika sätt, låt oss diskutera och låt oss dela med oss.

De finns de som är rädda för en sådan öppenhet och frihet. De tycker att vi då visar oss som amatörer, att vi visar upp en tvekan, att vi inte alltid vet vad som är bäst, och att vi öppnar upp för anarki och oordning. Till dessa vill jag säga: Utveckling innebär alltid en viss oordning. Leve denna oordning! 

Fortsättningen

Du kanske har andra tankar om hur vi kan göra bättre modeller. Det är bra, låt oss få höra. Det är så ett område kan utvecklas.

Det kommer fler artiklar om gestaltning av modeller. Detta var bara en liten början, varje steg ovan går det att säga mer om och det finns andra områden av ämnet att diskutera, inte minst de delar av våra modeller som består av text.

Hoppas du vill hänga med på detta.

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 10 mars. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

PS Vi har tyvärr varit tvungna att ta bort möjligheten att kommentera på artiklarna för en tid. Har du tankar om innehållet i artikeln som du vill dela? Välkommen att kommentera på vår linkedin där lägger vi ut en post vid varje publiceringstilfälle. Eller skicka ett mail till Peter Tallungs: peter.tallungs(at)irm.se

Vi kan göra bättre modeller – om gestaltning med grafik och text

Jag påstår att vi arkitekter kan bli bättre på hur vi utformar våra modeller. Mycket bättre! Detta är introduktionen till en serie artiklar där jag kommer att ge mina råd om hur vi med hjälp av bättre grafik och strukturerad text kan få våra modeller att bära mer kunskap och bli mer effektiva tanke- och kommunikationsverktyg.

Modeller är våra viktigaste verktyg

Modeller är arkitektens viktigaste verktyg. Vi arkitekter – vare sig vi är informations-, verksamhets- eller it-arkitekter – är i grunden modellerare. En nestor i branschen sa en gång: ”Jag modellerar vad som helst, var som helst, i vilket sammanhang som helst”. Jag brukar tänka på det.

Modeller är på samma gång ett tanke-, analys och kommunikationsverktyg. De blir mycket kraftfulla verktyg om vi förstår att utforma och använda dem rätt. En modell kan, rätt utformad, bli till en samarbetsplattform för lärandet i en organisation. 

Modellering är ett hantverk

Det är ett hantverk att göra bra modeller. Det kräver kunskap, vana och handlag. Och för en hantverkare är verktygen allt, de är som en förlängning av kroppen, sinnena och hjärnan. En hantverkare behöver därmed hålla sina verktyg i gott skick, så att de är skarpa och precisa.

Låt oss göra det.

Gestaltning är viktigt

En modell står och faller med hur den är utformad, i grafik och text. Om den tydligt förmedlar det som modelleraren vill förmedla, om den är krispigt klar, då gör den sitt jobb. Oavsett om den är en sann och användbar representation av det som modelleras, egentligen. Ty om modellen är tydlig går innehållet alltid att kritisera och förbättra. Den är lika mycket en fråga som ett påstående: ”Kan vi se det så här?”. Och frågor är minst lika viktiga som påståenden.

Om modellen inte är tydlig går idéinnehållet egentligen inte ens att kritisera. Ty det som man inte kan förstå kan man inte heller kritisera. Därför är det oerhört viktigt hur vi ritar våra modeller. Hela vårt yrke och yrkesområde, både som individer och som yrkesgrupp, står och faller med detta. Fast inte bara hur vi ritar. Modeller bör ha text också, och vi bör integrera grafik och text så att det bildar en helhet. Därför vill jag hellre säga gestalta och inte rita trots att grafiken har en framträdande roll.  

Hur står det egentligen till där ute?

Om man googlar på ”informationsmodell”, ”datamodell” eller liknande får man upp många olika exempel på diagram. Bilden som inleder denna artikel visar några slumpvisa träffar. Jag har inte valt ut vare sig bra eller dåliga exempel, utan bara det jag tycker kan vara representativt för hur det ser ut i våra verksamheter.

Jag tycker inte att man i något av dessa exempel, eller andra man kan hitta när man letar, har lyckats få modellerna att kommunicera på ett effektivt sätt. Vi kan göra mycket bättre, och det med enkla medel.

Hur ska man då göra?

Det finns inte mycket skrivet om hur man gestaltar modeller, och det lilla som är skrivet brukar vara upp åt väggarna enligt mig. Det är en stark åsikt och jag kommer att motivera den. Och inte bara motivera utan även visa på bättre sätt i de artiklar jag planerar att skriva framöver.

Det gäller inte bara informationsmodeller utan även andra modeller inom it- och verksamhetsarkitektur, så som förmågekartor, systemkartor, processmodeller med flera.

Låt oss bli bättre – tillsammans! 

Jag har i ett par decennier arbetat med att försöka utveckla hur man kan rita och skriva, för att göra bättre modeller. Jag har varit nyfiken på hur man gör inom andra yrkesområden där man gör modeller, ritningar, kartor och grafik i största allmänhet. Det jag lärt mig har jag sedan prövat att tillämpa på vårt område, i första hand informationsmodeller samt förmåge- och systemkartor. Och jag vill påstå att jag funnit sätt att rita och skriva, samt kombinera grafik och text, som jag menar har potential att lyfta hela vårt område. För om vi kan göra tydligare, skarpare och mer informativa modeller så kan vi bli mycket mer relevanta för våra organisationer.

Det betyder inte att jag vet och kan allt. Du kanske också har något att bidra med. Du har kanske andra insikter. Det är värdefullt om du då delar med dig. Så att vi tillsammans kan utveckla hela vårt område.

Exempel från ett helt annat område

Som en liten inledning vill jag visa ett mycket enkelt och vardagligt exempel från en helt annan bransch. Det är det elektriska kopplingsschemat till elsystemet på en bil, en Nash Ambassador från 1957. Det kanske inte är något märkvärdigt, det är så kopplingsscheman brukar ritas. Men ändå. Jag tycker att det finns så mycket klokskap och skicklighet i den grafiska gestaltningen som man kan begrunda och bara måste beundra. 

Lägg till exempel märke till följande:

  • Begränsningar: Tänk först på de begränsningar man hade: inget färgtryck samt begränsat utrymme.
  • Geografin i schemat: Titta sedan på hur man ordnat geografin i schemat. Längst upp har vi framlyktorna, sedan motorutrymmet med tändspole, fördelardosa och batteri. instrumentpanelen hittar vi långt ner på ritningen med alla strömbrytare och instrument. Baklyktorna ser vi längst ner. Hela ritningen är alltså utlagd schematiskt efter var i bilen respektive komponent sitter. Komponenterna är ordnade i grupper som är tydligt avgränsade från varandra. Man kan naturligt och utan ansträngning orientera sig i ritningen i förhållande till bilen i verkligheten.
  • Symboler: De olika komponenterna har symboler som är lätta att känna igen eftersom de avbildar komponenten ifråga symboliskt. Så länge man vet något om bil-el kan man mer eller mindre automatiskt känna igen komponenterna och behöver ingen symbolförklaring. Eller i varje fall, när man har stött på dem en gång är det lätt att erinra sig vad de står för nästa gång.
  • Linjer: Alla ledningar ritas som linjer, men de som går mellan batteri, laddningsrelä och generator är kraftigare. De representerar kraftigare kabel som ska klara starkare ström. Kabeln till startmotorn är på liknande sätt lite mittemellan i grovlek. Grovleken på linjen symboliserar hur grov kabeln är.  Linjerna är dragna med räta vinklar och ”hopp” där de korsar varandra. Linjer som ska till samma ställen är dragna tillsammans som grupp.
  • Ordning: Symboler, linjer och texter är placerade med raka marginaler. Hela diagrammet bildar en rektangel med raka marginaler.

Jag har försökt tänka hur man ska kunna förbättra kopplingsschemat ovan, men har inte hittat något sätt. Det är helt enkelt perfekt. Idag har vi förstås färgtryck, vilket skulle vara en fördel. Men i övrigt?

När jag ser vad man gjort inom detta och andra områden med grafik och gestaltning blir jag lycksalig, imponerad och ödmjuk. Det finns så mycket kunskap om hur man gestaltar ritningar och modeller inom olika yrkesområden. Det finns så mycket att lära sig av.

Varför har vi inte lärt oss?

Men varför är det så bristfälligt inom vårt område? Det vill säga allt som har med it- och verksamhet att göra. Varför har vi inte lärt oss?
Du som läser detta, tror du inte att vi inom vårt område skulle kunna bli lika bra på att gestalta med grafik och text som i andra branscher? Eller är det så att just vårt område är så omöjligt, att vi har en omöjlig uppgift? Vi kan i varje fall inte skylla på att vi är i en ung bransch. Verksamhets- och it-arkitekter har funnits i någon form i minst ett halvsekel. För mig är det en gåta. Hur har vi kunnat undgå att inte lära oss med tiden? Vad har hållit oss tillbaka? Jag vet inte, men jag tycker att vi nu har ett ansvar att bli bättre.

Hur blir vi bättre?

Vad kan vi då göra för att bli bättre? Jag vill i varje fall dra mitt strå till stacken. Jag kommer i en rad av artiklar framöver stegvis gå igenom det jag kommit fram till, med exempel och motiveringar. Några saker är kanske självklara för läsaren, några är kanske nya. Några är kanske kontroversiella i det att de motsäger sådant som annars brukar läras ut. Men jag tror verkligen att du, om du läser, begrundar och provar det som sägs kommer att utvecklas som modellerare och arkitekt.

Du behöver inte ens hålla med om allt, och det är ok. Men du kommer att bli tvungen att reflektera över hur du gör och varför.

Jag hoppas också att du vågar och vill kritisera mina råd. Det kan ju inte vara så att det bara är jag som har kunskap inom området. Eller att det jag säger är den slutgiltiga visdomen inom området. Min önskan är att fler vill bidra.

Det mesta jag kommer att skriva om framöver är mer eller mindre tillämpligt på alla slags modeller, och ibland till och med på alla slags grafiska representationer. Men en del konkreta råd gäller specifikt för informationsmodeller.

Mitt hopp är att det finns läsare som blir nyfikna på att utvecklas, som blir inspirerade till att experimentera och förbättra sina modeller i detta avseende. Det är det jag vill, så ett frö till en renässans inom området.

Vad jag kommer att beröra

Följande är en preliminär och grov plan över vilka ämnen jag kommer att ta upp i artikelserien.

  • Disposition:
    Hur vi placerar elementen i förhållande till varandra på diagrammet så att vi förmedlar vilken relation företeelserna har till varandra.
  • Struktur:
    Hur vi ger diagramytan en struktur som förmedlar hur vi ser på relationen mellan företeelserna.
  • Övergripande struktur:
    Hur vi kan ge hela modellen en meningsfull övergripande struktur.
  • Fokus:
    Hur vi lyfter fram centrala element.
  • Linjer:
    Hur vi drar relationslinjer så de blir tydliga och inte stör.
  • Namn:
    Hur vi benämner företeelserna och placerar namn.
  • Definitioner:
    Hur vi skriver definitioner och använder definitioner i diagrammet.
  • Verksamhetsregler:
    Hur verksamhetsregler har sin naturliga plats i informationsmodellen.
  • Färg:
    Hur vi använder färg.
  • Gråskalor:
    Hur vi använder gråskalor.
  • Samverkan tex och grafik:
    Hur vi får grafik och text att samverka.
  • Informationstäthet:
    Hur vi får våra modeller att förmedla allt vi behöver förmedla.
  • Diagramtyper:
    Hur vi kan utöka vår verktygslåda med fler diagramtyper.
  • Rika informationsmodeller:
    Hur vi kan få informationsmodeller att bära mycket mer kunskap och spela en mer central roll i en verksamhet.

Nästa artikel blir en rivstart.
Hoppas du vill hänga med! Om du har tankar kring detta – mejla mig: peter.tallungs@irm.se

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 3 mars. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

PS Vi har tyvärr varit tvungna att ta bort möjligheten att kommentera på artiklarna för en tid. Har du tankar om innehållet i artikeln som du vill dela? Välkommen att kommentera på vår linkedin där lägger vi ut en post vid varje publiceringstilfälle. Eller skicka ett mail till Peter Tallungs: peter.tallungs(at)irm.se

Hur kan informationsmodellering gå till? Del 2

Förra artikeln ”Hur kan informationsmodellering gå till? Del 1” beskrev vilka arbetsformer som kan finnas för informationsmodellering. Det gav en bild av själva verktygslådan som står oss till buds. Denna artikel ger exempel på hur man kan kombinera arbetsformerna i ett uppdrag. Jag tror att det är värdefullt att reflektera över och diskutera hur vi jobbar. Gör du likadant, eller på annat sätt?

Min erfarenhet är att informationsarkitekter gör ganska olika. Det är inte alla som omfamnar alla arbetsformerna. Man har kanske inte tagit möjligheten att utöka verktygslådan.

Jag har funderat på hur jag gör egentligen. Det vanliga är att jag löpande kombinerar och växlar mellan arbetsformer efter behov och läge. Jag kan skönja ett någorlunda återkommande mönster i vilken ordning och på vilket sätt jag växlar de olika arbetssätten. Jag ska nu försöka beskriva detta. Föreställ dig att uppgiften är en av de vanliga, att modellera de centrala delarna av en verksamhet. Alternativt kan det vara en avgränsad del av en verksamhet, som till exempel en större verksamhetsfunktion.

Steg 1: Skapar en karta

Det första jag gör är alltid detsamma. Jag börjar inte med att informationsmodellera, utan först behöver jag skapa något som kan ge överblick och fungera som en kontextkarta. Det vill säga en karta där jag sedan kan ge förankring, det vill säga sammanhang och avgränsning för de olika informationsmodeller jag tar fram. Det blir en karta över vilka verksamhetsfunktioner (eller om man vill kalla det för verksamhetsförmågor) det finns, och hur de relaterar till varandra. Där ritar jag in alla it-applikationer liksom hur de är integrerade med varandra och omvärlden.

Hur man tar fram en sådan förmågekarta har jag ännu inte beskrivit i denna artikelserie, men det är lätt och snabbt att göra, och blir en mångsidigt användbar karta, som visar vilka delar den består av och hur dessa samverkar. Det bli ofta första gången verksamhet och it får en gemensam karta där båda sidorna kan känna sig hemma.

Det intressanta är att det mest effektiva sättet att få fram en sådan karta är att re-engineera applikationsportföljen. Ty informationssystemen är idag en så integrerad del av en verksamhet att it-landskapet, om man tolkar det rätt, faktiskt ger den mest tydliga och sanna bilden av hur verksamhetens olika funktioner samverkar operativt.

Det går till så här: Jag workshoppar med it-arkitekterna och tar hjälp av deras kartor över vilka applikationer som finns. Ty finns det en applikation så finns det en verksamhetsfunktion som applikationen stödjer. Eller som jag vill se det: En applikation är alltid, per definition, en integrerad del av en viss verksamhetsfunktion. Hur dessa sedan är integrerade och används ger nycklar till beroendet mellan verksamhetsfunktionerna.

Att det fungerar går tillbaka på Conways law: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

Fast då behöver man först göra klart för sig vad som egentligen utgör en it-applikation och vad som inte utgör en it-applikation. En it-applikation är, per definition, ett informationssystem som stödjer en viss verksamhetsförmåga. Det kan således vara ”Pelles månadsrapport”, ett Excel-ark, så länge det har en återkommande och operativ roll i verksamheten. Ett affärssystem däremot är sällan en applikation, utan en plattform för flera separata applikationer. Huvudboken är en applikation, leverantörsreskontra en annan, och så vidare. En integrationsplattform är heller aldrig en applikation, utan en kommunikationsinfrastruktur. Finns det någon verksamhetslogik som körs på en sådan plattform så är denna verksamhetslogik en egen applikation. En applikation som ägs av en verksamhetsfunktion och bara driftas på integrationsplattformen. För en verksamhetslogik måste per definition alltid ägas av en verksamhetsfunktion, och utgör då en applikation som ingår som en integrerad del i den verksamhetsfunktionen.  

Andra sätt att nysta ut hur verksamheten hänger ihop utgår ofta från saker som organisationsschemat eller processerna. Men det ger inte fakta på samma sätt som om man utgår från hur verksamheten verkligen fungerar och hänger ihop operativt, enligt ovan. Den bild man får fram när man gör en förmågekarta på det sätt jag beskrivit visar hur verksamheten fungerar på riktigt. Det blir sedan mycket intressant att lägga organisationsschema och processmodeller ovanpå detta.

Ännu mer intressant blir det att lägga på tjänsteperspektivet. Men då är vi kommit långt från informationsmodellering.

Vad beträffar informationsmodelleringen så blir en sådan förmågekarta användbar för att ge kontext åt de olika informationsmodellerna. Allt annat man kan göra med en sådan karta får det bli andra artiklar om.

Steg 2: Identifiera och få tillgång till scheman för de mest centrala databaserna, eller datakällorna

Jag behöver nu snabbt få ett första grepp om de centrala informationsstrukturerna. Det enkla och effektiva sättet är att ”reverse-engineera” databasschema för de mest centrala databaserna. Jag intervjuar it-arkitekter och förvaltningsansvariga för att få reda på vilka de centrala databaserna är. De förser mig med scheman, samt med upplysning om vem som är mest kunnig om respektive databas och som jag kan få störa med frågor allteftersom.

Steg 3: Tolka scheman

Jag går sedan igenom olika scheman, ofta databasscheman, tabell för tabell, kolumn för kolumn, och försöker tolka och rita början till en informationsmodell. Ofta får jag fråga den som vet vad som döljer sig i databasen och jag försöker med dennes hjälp ge bra konceptuella namn och definitioner till entiteter, attribut och relationer. Fast jag noterar också de fysiska namnen för att hela tiden behålla kopplingen till det fysiska.

Snabbt har jag nu ett första utkast till en informationsmodell som jag visar för kunniga it-personer. De ger mig feedback, korrigerar mina missförstånd och snabbt har vi en modell som representerar vår gemensamma förståelse så här långt.

Det här är ett lätt och roligt arbete i verksamheter som har egenutvecklade system. Även om det är gamla system är de nästan alltid relativt välstrukturerade vad gäller informationsstruktur och begriplighet. Det är min erfarenhet. Jag håller inte med om det som ofta sägs, att de gamla systemen är den stora bromsklossen.

Men med standardsystem är det en helt annan sak. Dels har de ofta tusentals tabeller varav nästan alla är så generella att de kan innehålla lite av varje. Ofta är också strukturerna misshandlade, både av företagen som utvecklar systemen och av den senare anpassningen när man har försökt få systemen att åtminstone hjälpligt stödja det som verksamheten behöver. Och vad värre är; ingen i organisationen har någon vidare kunskap om vilka data som faktiskt finns i systemen eller hur den är strukturerad. Om jag då vänder mig till leverantören så är det också där svårt att få vägledning. Dels har de inte så mycket grepp om vilka anpassningar som gjorts och hur olika strukturer har använts hos just denna verksamhet. Dels är de sällan så värst pigga på att hjälpa till om det inte handlar om merförsäljning. Ofta skäms de för att visa sina trassliga datastrukturer.

Arbetet att bringa ordning blir då betydligt knepigare, och långsammare. Men det finns ändå inget annat sätt än det jag beskrivit. Organisationen behöver ta tillbaka kontrollen över sina data och hur det hanteras.

Steg 4: Tolka data

Därigenom går jag igenom data i databaser och filer. Vanligen börjar jag med de mest centrala databaserna. Jag går igenom datainnehållet kolumn för kolumn. För varje kolumn kollar jag saker som följande:

  • För alla kolumner: Finns det tomma förekomster (vilket inkluderar innehåll som på något sätt kan tolkas som tomt)?
  • För textkolumner (utom de med ett litet och bestämt antal möjliga värden): Vad är de längsta textsträngarna? Är de klippta? Finns det konstiga värden?
  • För numeriska kolumner (utom de med ett litet och bestämt antal möjliga värden): Vad är minimi- och maxvärde? Finns det negativa värden? Finns det orimliga värden?
  • För kolumner med ett litet och bestämt antal möjliga värden: Vilka är värdena, och vilka antal har varje förekomst?

Tillsammans med någon kunnig går jag igenom hur man ska tolka innehållet, och bokför alla resultat. Jag listar särskilt de anomalier jag upptäcker, det vill säga de misstänkta bristerna i datakvalitet, så här långt.

Sedan går jag vidare på liknande sätt. Fast med den lite djupare förståelse jag nu har kan jag göra analyser med databasfrågor där jag kombinerar värden i olika kolumner, detta för att hitta mönster i data som kan förklara saker och ting.

Vid det här laget har jag fått en djupare kunskap om befintliga data och vad de betyder. Ofta får vi justera definitioner och ibland även namn på entiteter och attribut. Vi kan till exempel upptäcka att bland det vi trodde var kunder finns även leverantörer eller partners.

Så syftet är dels att få en djupare och mera rättvisande förståelse för vilka företeelser som hanteras av verksamheten och hur, det vill säga en mer korrekt informationsmodell och mera korrekta definitioner och beskrivningar än vad vi annars skulle ha. Dels får vi också en lista på brister till exempel saknad, motsägelsefull eller på annat sätt uppenbart felaktiga data. Detta kan bli input till data management-åtgärder, vilka kan vara att korrigera bristerna men också att utforma åtgärder för att den typen av fel inte ska uppstå igen.

Ibland får jag till och med tillsammans med en programmerare tolka någon algoritm i programkod som bestämmer värde på någon output, baserat på olika kombinationer av input-parametrar.  

Också detta är vanligen ett rättfram, roligt och enkelt arbete. Men även här blir det oerhört mycket knepigare när det är frågan om standardsystem.

Steg 5: Fördjupat arbete

I detta läge har vi kommit så långt man kan komma med dessa enkla och rättframma arbetsformer. Det har mest handlat om ett rakt och enkelt arbete. I en del fall räcker detta och vi kan mer gå över i en mer lugn takt, att fortsätta stödja utvecklingsarbetet i organisationen.

Men i många verksamheter finns det områden som har trasslat ihop sig ordentligt. Det kan vara en produktstruktur där man tappat greppet fullständigt. Eller att man har olika strukturer och begrepp i olika system och där ingen egentligen vet hur det hänger ihop. Då är det tidigare kartläggandet bara själva initierandet. Nu börjar det riktigt roliga! Ett detektivarbete med att lägga pussel och hitta mönster i oredan. De mest framträdande metoderna i detta arbete blir att varva dataanalys (för att hitta mönster och mening i oredan) med riktade eller spontana workshoppar med de tyngsta kunniga inom området, ofta analytiker av olika slag. Vi tar oss an ett område efter ett annat. Min erfarenhet är att det kan ta lite tid, men det går alltid att bringa ordning. Bara man har envishet. Man jobbar på, men forcerar ändå inte, saker och ting måste få mogna fram.

Detta är en förenkling

Denna beskrivning är naturligtvis förenklad. I verkligheten blir det mer att man växlar och blandar arbetsformer ännu mer. Men det ger ändå en bild av det typiska, hur tyngdpunkten stegvis flyttas från vissa arbetsformer till andra.

Hur jobbar du som informationsarkitekt? Liknar det mitt sätt eller är det helt annorlunda?

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 24 februari. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

PS Vi har tyvärr varit tvungna att ta bort möjligheten att kommentera på artiklarna för en tid. Har du tankar om innehållet i artikeln som du vill dela? Välkommen att kommentera på vår linkedin där lägger vi ut en post vid varje publiceringstilfälle. Eller skicka ett mail till Peter Tallungs: peter.tallungs(at)irm.se