Om organisationer och personer – fyra vanliga missar

Organisationer och personer är centrala företeelser i varje verksamhet. Men vilka begrepp använder vi för dessa? I denna artikel tar jag upp några vanliga misstag, och ger råd om bra och vedertagna begrepp.

Hur det brukar se ut

I de organisationer jag verkat händer det att man delat in alla intressenter i fysiska och juridiska personer, samt haft personnummer och organisationsnummer som unikt id för respektive kategori. Jag menar att man då lyckats göra flera misstag på en och samma gång. Jag går igenom dem ett efter ett nedan.

Misstag 1: Förväxling av begreppet Organisation med begreppet Juridisk person

Det är inte alla organisationer som är juridiska personer, inte ens merparten, utan faktiskt endast cirka 40 procent av Sveriges tre miljoner registrerade organisationer. De som inte är juridiska personer utgörs främst av enskilda näringsverksamheter, de som i dagligt tal brukar kallas enskilda firmor. De är cirka 1,8 miljoner till antalet. Juridiskt och skattemässigt ingår de i den enskilda näringsidkarens person. Men de är ändå organisationer. De är ibland lite större företag, med många anställda. En och samma person kan äga flera sådana företag som till och med kan finnas på olika orter och ha olika verksamheter. Men de är inte juridiska personer.

Bland andra former av organisationer som inte är juridiska personer finns cirka 20 000 enkla bolag, 200 partrederier, 1 700 värdepappersfonder, 330 statliga enheter, 7 regionala statliga myndigheter samt cirka 6 500 verksamheter som drivs av oskiftade dödsbon. Att kategorisera alla dessa som juridiska personer blir i grunden fel.

Misstag 2: Tron att alla personer i Sverige identifieras med personnummer

Endast personer som är folkbokförda i Sverige har svenskt personnummer. Övriga som ska arbeta i landet, eller av annan anledning behöver få en registrerad identitet i Sverige, får ett så kallat samordningsnummer. Det liknar visserligen personnummer i formatet men har talet 60 tillagt till dagnumret.
(Skatteverket förklarar det så här: Samordningsnummer består liksom personnumret av tio siffror. De inledande sex siffrorna utgår från personens födelsetid med den skillnaden att man lägger till 60 till födelsedagen. För en person som är född den 23 augusti 1964 så blir de sex första siffrorna i samordningsnumret därför 640883).

Att sortera in samordningsnummer under personnummer kan synas vara en oskyldig förenkling. Men jag har varit med om att detta fått följder. Det var ett försäkringsbolag som hade företagskunder och privatkunder i samma register. De ville separera dessa genom att skapa separata register för dessa. Inte minst för att företag och privatpersoner omfattas av olika lagstiftning runt försäkring, och erbjuds olika produkter med olika skydd och olika premier. En programmerare gjorde ett sållningsfilter som baserat på om kunden hade ett giltigt personnummer blev klassad som privatperson, i annat fall som företag. Ett giltigt personnummer har, förutom en giltig checksiffra på slutet, ett giltigt datum, det vill säga de första sex siffrorna. Eftersom samordningsnummer inte klarade det testet blev alla tusentals kunder med samordningsnummer klassade som företag. Innan misstaget upptäcktes och åtgärdades blev det en hel del kostsamma och besvärliga följdfel.

Misstag 3: Tron att alla organisationer i Sverige identifieras med organisationsnummer

Eftersom en enskild näringsidkare kan driva fler än en enskild näringsverksamhet räcker det inte att använda näringsidkarens personnummer för att unikt identifiera en enskild näringsverksamhet. Enskilda näringsverksamheter identifieras därför officiellt med näringsidkarens personnummer följt av en löpsiffra, en etta för personens första näringsverksamhet, en tvåa för den andra och så vidare.

Misstag 4: Ej anpassat till kunder som inte är personer eller organisationer registrerade i Sverige

De identitetsbegrepp vi nämnt gäller endast för personer och organisationer registrerade i Sverige. Om vi har intressenter som saknar en svensk identitet behöver vi ha mer generella namn på våra id-begrepp samt kvalificera dessa med vilket land som utfärdat identiteten.

Hur ska man göra då?

Jag brukar göra så här när det handlar om verksamheter med endast svenska intressenter.

Och så här när intressenterna är internationella.

Det här kan kanske tyckas petigt, det är lättare att bara fortsätta göra som alla andra. Vi är sociala varelser så ibland tror vi att det som alla gör är korrekt bara för att alla gör så. Men det är ett farligt gruppbeteende. Om vi inte kan klara av att fixa det som är enkelt att få ordning på, hur ska vi då kunna reda ut det som verkligen är svårt? Som modellerare är vi ansvariga för begreppen. Då behövs det att vi anstränger oss att använda de termer som korrekt representerar de företeelser vi modellerar. 

Andra intressenter än organisationer och personer

Det jag inte berört här är hur man tänker när man behöver hantera andra intressenter än organisationer eller personer. Ibland vill man se delar av en och samma organisation som olika kunder. Jag har varit med om följande situation i en verksamhet. Vi hade två bröder som kunder. De hade registrerat en firma ihop men sedan gått skilda vägar. De drev separata verksamheter, men hade ändå stannat kvar i samma firma. De hade inte talat med varandra på 20 år och ville absolut inte ses som en och samma kund. Ett annat fall är hur man i försäkringsvärlden ser hushållet som kund. För privat sakförsäkring som till exempel villa-/hemförsäkring och motorfordonsförsäkring är det i de flesta situationer ointressant just vem i familjen som faktiskt står som försäkringstagare. Jag minns knappt inte ens om bilen och villan står på mig eller min partner. Därför är det vanligt att man inom privat sakförsäkring ser hushållet som kund mer än den person som råkar vara försäkringstagare. Men detta är en annan historia.

Vad tycker du?

Jag har säkert missat någon aspekt. Du får gärna komplettera eller rätta om du har en annan synvinkel.

/Peter Tallungs, IRM

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

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

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

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

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

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

Röstningen

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

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

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

Resultatet

Här är röstresultatet

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

Vilken ”informationsarkitekt” röstade vi om?

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

Var gruppen representativ?

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

Var gruppen tillräckligt stor?

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

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

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

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

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

Analys av resultatet

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

Data- och informationsstrukturer

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

Begrepp och språk

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

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

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

Ta hand om data som tillgång/resurs

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

Ägarskap och styrning av dataresurser

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

Styrning av dataresurser utifrån säkerhetskrav

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

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

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

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

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

/Peter Tallungs, IRM

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

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

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

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

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

Visuellt starka analyser ger bättre beslutsunderlag

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

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

En gemensam bild som alla kan relatera till

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

Framtidvisioner

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

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

Etablera Vintergatan i din organisation

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

Läs mer om Vintergatan

Har du frågor om Vintergatan? Tveka inte att kontakta oss.

Cecilia Nordén, verksamhetsarkitekt och författare till boken Vintergatan – din verksamhetskarta
Thomas Larsson, verksamhetsarkitekt och författare till boken Lat men effektiv

Boken om Vintergatan – ny som e-bok

Den engelska översättningen av boken om Vintergatan – din verksamhetskarta finns nu som e-bok på Amazon!

Missa inte chansen att köpa den för endast 5 USD (ordinarie pris 22 USD). Erbjudandet gäller till och med 15 oktober 2021. 

Du hittar boken här, eller gå till amazon.com och skriv ”The Milky Way Cecilia Norden” i sökfältet.

Har du kollegor och vänner som du tror kan ha nytta av den hyllade metoden och modellen Vintergatan? Tipsa dem så att de också kan få sitt exemplar av The Milky Way – Map, Navigate and Accelerate change till detta kampanjpris. Eller ge bort en e-bok som en gåva. 🌼

Köp den fysiska boken i vår webbshop.

Det är inte fiskarna som är poängen

…det är förmågan att se hur vi kan arbeta smartare

Vill du förbättra ert arbetssätt? Ta chansen att den 25:e november lära dig kartlägga, analysera och utveckla verksamhetens processer; för att hitta smartare sätt att arbeta på med syftet att öka värdet av det ni gör för era kunder. 

IRM har hittills gett drygt 1 500 personer förmågan att kartlägga och utveckla processer agilt utifrån kundens upplevelse. Kursen Processutvedckling ger dig en effektiv metod för hur du jobbar med processutveckling samt praktisk övning i hantverket (vilket innefattar en och annan processymbol i fiskliknande form). Kursen är bara 2 dagar kort, men ger dig kunskap som du kan ha nytta av hur många dagar som h.

Målen med kursen är att du som deltar ska kunna:

  • självständigt kartlägga din verksamhets processer både på övergripande och detaljerad nivå.
  • analysera processerna för att hitta förbättringsmöjligheter.
  • sätta processmål och mäta dem.
  • åstadkomma kundfokusering med hjälp av kundresor.

Lärarna som dagligen arbetar med verksamhets- och processutveckling, inom både privat och offentlig sektor, delar generöst med sig av sina erfarenheter under utbildningsdagarna.

Läs mer om kursen Processutveckling Vi levererar den i samarbete med Dfkompetens

Läs tidigare kursdeltagares omdömen

Modellmönster: Ansvarsförhållanden mellan parter

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

Mönster 1: Organisationshierarki med explicita nivåer

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

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

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

Mönster 2: Organisationshierarki med generaliserade organisationsenheter

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

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

Mönster 3: Flera organisationshierarkier

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

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

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

Mönster 4: Organisationshierarki med relationsobjekt

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

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

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

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

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

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

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

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

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

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

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

Mönster 6: Relationer styrda av ett regelplan

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

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

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

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

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

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

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

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

Om regelplan i modeller 

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

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

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

Var kommer dessa mönster från

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

/Peter Tallungs, IRM 

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

Spela en avgörande roll – utbilda dig till verksamhetsarkitekt

Vill du spela en avgörande roll? Utbildningen Certifierad verksamhetsarkitekt ger dig förmågan och självförtroendet att driva arkitekturarbetet i din organisation med komplett verktygslåda. Du får strategier för hur du gör verksamhetsarkitekturen relevant för hela organisationen samt verktyg för att bygga vägen mot framgångsrik förändring.

Verksamhetsarkitekten – en möjliggörare

Målet med verksamhetsarkitektur är att möjliggöra en snabb och enkel verksamhetsutveckling, åstadkomma hög informationskvalitet samt att se till att rätt system stödjer verksamheten. När det målet är uppnått når vi också ett tillstånd där verksamheten snabbt kan svara mot nya omvärldskrav. Verksamhetsarkitektens roll är därmed central för en innovativ och lättrörlig organisation. 

Välj Sveriges största utbildning av verksamhetsarkitekter

Tillsammans med Dataföreningen Kompetens har vi genom åren certifierat en bra bit över 1000 verksamhetsarkitekter. En framgångsfaktor för utbildningen Certifierad verksamhetsarkitekt är föreläsarnas erfarenheter inom olika branscher. De är alla aktiva i sina respektive roller i olika bolag och organisationer. Det ger dem insikt i, och stor förståelse för aktuella utmaningar och olika förutsättningar, både inom privat och offentlig sektor.

 Under utbildningens 12 dagar, fördelade på 6 utbildningstillfällen, får du se verksamhetsarkitektur utifrån flera olika perspektiv. Du får strategier för hur du gör verksamhetsarkitekturen relevant för hela organisationen samt verktyg för att bygga vägen mot framgångsrik förändring. Du lär dig skapa samsyn och kollektiv intelligens samt visualisera och kommunicera komplexitet utan att tappa relevant information i trubbiga förenklingar. Utbildningen Certifierad verksamhetsarkitekt ger dig förmågan att driva arkitekturarbete med självförtroende och kompetens i din verksamhet med komplett verktygslåda.

”Denna kurs är av yttersta kvalitet och är en otroligt viktig pusselbit för företag som vill skapa en effektiv organisation och bedriva intelligent digitalisering i en tid av snabba förändringar. Ett måste för seriösa bolag och myndigheter. Verksamhetsutveckling som område behöver dessa verktyg för att vara effektiv och bestående. Styrkan i utbildningen är att man får en helhet och ser en tydlig röd tråd hur allt hänger ihop.” 

Samuel Forsberg, CGI Certifierad verksamhetsarkitekt hösten 2020 

För vem?

Certifierad verksamhetsarkitekt riktar sig till dig som i din yrkesroll upplever att din verksamhet har svårt att hantera förändringar, har trögrörliga systemstöd, okoordinerade utvecklingsinitiativ och systemsatsningar (exempelvis flera kundregister, flera leverantörsregister etc.) eller allmänt dålig kvalitet på lagrad information.

Certifierad verksamhetsarkitekt riktar sig exempelvis till dig som är verksam som:

  • CIO
  • IT-arkitekt
  • Processutvecklare
  • Projektledare
  • Strategiansvarig
  • Verksamhetsutvecklare

”Känner att jag redan innan kursen var slut börjat göra saker på ett annat sätt, tänka på annat sätt, se saker på nytt sätt – en personlig utvecklingsresa!”

Elevcitat från utvärderingen av Certifierad verksamhetsarkitekt hösten 2020.

Denna utbildning är inte bara ett knippe verktyg som du lär dig hantera. Den är också, för många av deltagarna, en personlig utvecklingsresa. Vi levererar våra utbildningar i samarbete med Dataföreningen KompetensLäs mer och boka din plats här.

Läs mer

Funderar du på vad rollen verksamhetsarkitekt innebär? Läs också vår artikel Vad gör en verksamhetsarkitekt.

Missade du webbinariet?

Lars Thomasson är verksamhetsarkitekt och ansvarig för utbildning Certifierad verksamhetsarkitekt presenterade utbildningen på ett webbinarium hos Dataföreningen kompetens.

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.

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.

Vilken notation är bäst?

För informationsmodeller finns det många olika notationer. Nu ger jag min syn på det alla har en åsikt om: Vilken är bäst?

Jag talar här om det sätt att modellera som nästan är synonymt med begreppet informationsmodellering: Entity Relationship Diagrams, som förkortas ERD eller ER Diagrams. Det vill säga boxar som står för entiteter (klasser av företeelser) med streck för de relationer som kan finnas mellan dessa. För detta finns det en uppsjö av notationer att välja mellan, det vill säja sätt att rita sina boxar och relationer.

Först behöver jag gå igenom vilka vanliga ERD-notationer det finns. Jag berör vilka traditioner de är sprungna ur och därmed vilka grundläggande synsätt de bygger på. 

ER-modelleringens historia

Den första ERD-notationen togs fram av Peter Chen 1976. Ändamålet var att designa databaser. Relationsdatabaser var då något nytt. Edgar ”Ted”, F Codd hade föreslagit relationsmodellen 1970 då han var anställd på IBM. Codds idé om hur design av en relationsdatabas skulle gå till var att man skulle strukturera en från början ostrukturerad datamängd genom att steg för steg mekaniskt applicera ett antal så kallade normaliseringsregler. Peter Chens idé var att i stället modellera fram en struktur för sina data.

Under de följande decennierna utvecklades det ett antal varianter på Chens ursprungliga notation. Det är dessa varianter jag nu diskuterar.

Viktigt i sammanhanget är att vi sedan många decennier tillbaka använder ER-diagram till många andra syften än att designa relationsdatabaser. Det har blivit ett oerhört kraftfullt och effektivt verktyg för att analysera beskriva vilken data- eller informationsmängd som helst samt även företeelser och begrepp inom ett område.

ERD-notationer

Vi kan inte diskutera alla exotiska varianter av notationer utan får göra ett urval av de vanligaste. De man kan stöta på idag är främst följande:

  • IDEF1X som har sitt ursprung i amerikanska flygvapnet
  • Bachman
  • Barker, vanlig bland Oracle-folk
  • James Martin Information Engineering (JMIE), också kallad Information Engineering eller Crow’s Foot Notation, framtagen av den brittiske IBM-konsulten James Martin
  • Express, för produktdata
  • UML klassdiagram som vanligen inte räknas som en ERD-notation trots att den har samma ursprung och kan användas för samma ändamål. Modelleringsspråket UML (Unified Modeling Language) som innehåller notationer även för andra modelltyper än data- och informationsmodeller har en egen historia och tradition från metoder för design av objektorienterad programkod i mitten av 90-talet.

Aspekter att jämföra

Vi kan jämföra dessa notationer ur olika aspekter som vi bedömer som viktiga. Jag har valt följande aspekter:

  • Förekomst
    Hur vanlig är notationen? I Sverige? I världen? I olika specifika sammanhang?
  • Uttryckskraft
    Hur bra går det att uttrycka det vi behöver med hjälp av notationen?
  • Tydlighet
    Hur tydligt blir det att läsa och förstå notationen, (för en relativt ovan respektive van person).
  • Ändamålsenlighet
    Hur bra passar notationen för informationsmodellering?
  • Verktygsstöd
    I vilken mån har de vanliga rit- och modelleringsverktygen inbyggt stöd för notationen?
  • Kunskap
    Hur vanlig är notationen i facklitteratur, utbildningar och annat material?
  • Kultur
    I vilket sammanhang har notationen sitt ursprung. Det påverkar vilka underliggande synsätt notationen baseras på, vilket kan göra den mer eller mindre lämplig för olika ändamål.

Jag kommer nu att gå igenom aspekt för aspekt, i sju ronder.

Jämförelse 1: Förekomst

Det är förstås viktigt hur vanlig den notation man väljer är, både allmänt i världen och i Sverige samt inom det speciella område man är verksam.

Bland de traditionella ERD-notationerna, det vill säga alla utom UML klassdiagram, sägs JMIE (Kråkfotsnotation) vara överlägset vanligast, både i världen och i Sverige. Och det stämmer nog. Jag har många böcker om informationsmodellering, både nyare och äldre, och kan nästan inte påminna mig om att jag sett någon annan notation. Alla de övriga verkar vara på utdöende eller återfinns endast i speciella sammanhang. Som Barker bland Oracle-folk och Express för produktmodellering. Dock kan även JMIE i sig själv förekomma i lite olika varianter med mindre avvikelser från varandra.

UML är en familj av notationer för modellering av programkod. UML kom 1996 och användes först endast för programvarudesign inom den objektorienterade paradigmen. Senare har några börjat använda UMLs olika notationer även för verksamhetsmodellering, och bland dessa klassdiagram, både för verksamhets- och databasmodellering.

Så idag finns det i stort sett bara två olika läger vad beträffar notation.

  • JMIE som har sitt starka fäste i databasdesign, liksom i de yrkesgrupper som historiskt kommer därifrån, som enterprise-, verksamhets- och informationsarkitekter, Business Intelligence-folk med flera.
  • UML klassdiagram som fortfarande har sin spridning främst bland programmerare och då främst för modellering av programkod.

För informationsmodellering är alltså JMIE vanligast, även om UML klassdiagram också förekommer.

Resultat: JMIE vinner i den här kategorin, fast med UML klassdiagram som god tvåa.

Eftersom aspekten ”Förekomst” är så viktig så kan vi redan här räkna bort alla andra notationer än JMIE och UML klassdiagram. Det är ingen idé att beakta en notation som inte används i praktiken, så till vida den inte har alldeles extraordinära kvaliteter i övrigt som motiverar att den blir kvar. Vilket jag bedömer att de inte har. Av startfältets sex tävlande återstår alltså redan nu bara två.

Jämförelse 2: Uttryckskraft

Det är viktigt att den notation jag väljer kan uttrycka det jag behöver uttrycka.

Jag anser att JMIE och UML klassdiagram har mer eller mindre samma uttryckskraft. Liksom de flesta andra notationer som vi redan har räknat bort. Skillnaderna är små, så det ska egentligen inte påverka valet. Men jag tycker att UML klassdiagram har två uttrycksmedel som jag tycker är värdefulla och som vanligen saknas i de traditionella ER-notationerna.

1.  ”Composition”, en fylld romb i änden på relationslinjen som markerar att en entitet är en integrerad del av en annan och inte kan existera självständigt. Som att en fakturarad hör till en faktura och att fakturaraden inte kan existera självständigt, oberoende av fakturan.

2.  Möjligheten att rita en specialiserad entitet (en subtyp) skild från den generella (supertypen), alltså det som man kan kalla en ”is-a”-relation eller ”arv” inom programmering, med en linje mellan entiteterna markerad med en ofylld triangelformad pilspets i änden. Det är värdefullt då man behöver utveckla flera olika specialiserade entiteter i olika ämnesområden. Det vanligaste i ERD-notationer är annars att en eller flera specialiserade entiteter ritas inuti den generella entiteten.

Observera att jämförelsen här endast handlar om uttryckskraften hos notationen vad gäller just informationsmodellering. UML klassdiagram är ju i grunden avsett för design av programkod och har därför möjlighet att uttrycka beteende hos klasser i form av metoder vilket det inte finns behov av hos en informationsmodell.

Resultat: Ett plus till UML klassdiagram.

Jämförelse 3: Tydlighet

En notation behöver vara så tydlig som det bara går för att vi ska kunna göra modelldiagram som kommunicerar effektivt.

Här finns det ofta starka åsikter som dra åt olika håll. Traditionella informationsmodellerare tycker att UML är obegripligt och UML-konnässörer tycker att traditionella ERD-notationer är passé. Men min uppfattning är att det handlar mer om det som kallas ”confirmation bias” än verklig skillnad, att man gärna vill tro att det man är van med är lättast att begripa. Jag tycker att det är hugget som stucket mellan JMIE och UML klassdiagram.

Det som skiljer är främst hur man betecknar kardinalitet (multiplicitet) i relationerna. Det vill säga vilka symboler man har i ändarna av relationsstrecken. UMLs min- och maxvärden i form av siffror är möjligen enklare att direkt förstå för den oinvigde. Fast JMIEs tvärstreck och gafflar är grafiskt tydligare så snart man fått dem förklarade för sig.

För övrigt har tydlighet hos våra modeller mer att göra med hur vi använder disposition, struktur, namngivning, texter, gråskalor, färger och så vidare, vilket har mer att göra med vår kunskap om grafisk gestaltning än om vilken notation vi använder.

Resultat: Jämnt skägg alltså.  

Jämförelse 4: Ändamålsenlighet

Jag tror att många skulle anta att UML är bäst för programvarudesign och de traditionella ER-notationerna bäst för informationsmodellering. Man kan anta att eftersom olika notationer ursprungligen är framtagna för olika ändamål så kan de vara bättre eller sämre lämpade för det jag behöver gestalta. Men skillnaden i hur väl lämpade JMIE och UML klassdiagram är för informationsmodellering är, om den ens finns, så liten så att jag bedömer den som betydelselös.

Det är dock sant att ERD-diagram inte täcker det som behövs för programvarudesign. Det som saknas är framförallt möjligheten till att beskriva vilka metoder en viss klass har. Men däremot passar UML klassdiagram alldeles utmärkt för informationsmodellering. Men eftersom det är för ändamålet informationsmodellering jag gör denna jämförelse så blir det inge tydligt utfall åt ettdera hållet.

Resultat: Därmed är det oavgjort även här.

Jämförelse 5: Verktygsstöd

Det är så klart viktigt att mitt verktyg kan användas för den notation jag har valt.

Både JMIE och UML klassdiagram tillhör de vanliga notationerna och har därmed lika bra stöd i alla vanliga verktyg.

Resultat: Återigen oavgjort.

Jämförelse 6: Kunskap

Jag behöver kunna hitta utbildningsmaterial för den notation jag väljer. Jag tror att det är ungefär lika lätt att hitta utbildningsmaterial och läroböcker om JMIE som inom UML.

Resultat: Oavgjort.

Jämförelse 7: Kultur

En viss notation lever inte i ett vakuum utan är inbäddad i en kultur inom ett visst område. Kulturen för med sig vissa föreställningar, som man visserligen kan förhålla sig till men som ändå påverkar kunskapsområdet på många sätt.

Det är här vi har den enda större och riktigt intressanta skillnaden mellan de traditionella ERD-notationerna och UML. Fast den slår åt båda håll! ERD-notationer har en äldre historia och har därmed använts i ett halvsekel för modellering tvärs över hela verksamheter. Det var vitrockarnas värld bland stordatorerna i datorhallen. Därför finns det gott om erfarenhet och modelleringsmönster att ta del av. Dock är det en kultur som i mina ögon stelnade någon gång på 90-talet.

UML uppstod först under andra halvan av 90-talet, i den objektorienterade programmerarkulturen. Det vill säga mikrodatorvärlden. Länge tog man fram endast enstaka specialiserade applikationer som var relativt fristående. Man hade inget samröre med stordatorfolket. Därför finns det inte alls samma erfarenhet i den kulturen av verksamhetsövergripande information. Däremot finns det en hel del friskt nytänkande som saknas i den gamla världen. Framförallt vill jag framhålla idén om domändriven design (Domain Driven Design) av Eric Evans som är något av det bästa som tänkts och skrivits på vårt område.

Men du behöver inte begränsa dig till böcker och erfarenheter från ERD-samhället bara för att du använder ERD-notation. Om man vill utveckla sitt kunnande är det viktigt att söka kunskap och inspiration bredare. Och är du UML-anhängare bör du ta del av den rika erfarenhet som generationer av kollegor har gjort. De problem du stöter på har sannolikt många hanterat före dig.

Resultat: Oavgjort. Fast vi bör förstå att både den traditionella ERD-kulturen och UML-kulturen har både styrkor och svagheter av betydelse. Det betyder att du som informationsarkitekt inte kan välja. Du behöver ta del av båda kulturerna.

Konklusion

Om du håller med om ovanstående så finns det bara två alternativ, och det är JMIEsamt UML klassdiagram. Och det är inte så tydligt vem av dessa som är vinnaren.

Jag har växlat fram och tillbaka genom åren. Vanligen, när jag kan välja, använder jag JMIE, av skälet att det är vanligast bland informationsarkitekter. Fast när jag behöver något element från UML klassdiagram, som jag nämnt ovan att jag saknar, så lånar jag helt sonika in dem. Så om jag skulle känna behov av att vara lite mer konsekvent skulle jag kanske gå över till UML klassdiagram. Fast jag är inte så stor anhängare av konsekvens. Det är viktigare att vi söker fritt och lånar friskt för att utveckla vårt område.

Vi som arbetar med detta måste förstås vara väl förtrogna med både ERD-notation och UML klassdiagram. Framförallt behöver vi kunna ta del av den kunskap som finns inom båda områdena. Sorgligt nog finns det en kulturell gräns som verkar svår att överstiga. Få informationsarkitekter tar del av saker från programmerarvärlden. Och tvärtom. Få programmerare från UML-världen känner ens till det som har tänkts och gjorts innan de kom in på banan. Det är så synd.

Mitt råd till dig som kollega är att vara mer öppen för ”den andra sidan”.

Exotiska svenskar

Om du varit med ett tag i branschen i Sverige vet du att det finns ett par rent svenska varianter på notationer. Jag vill bara kort nämna dem här. Stanli var ett standardiseringsorgan för geografisk information som drevs av Svenska Standardiseringsinstitutet. De tog fram en standard för begreppsmodellering – Stanli-notation – som i praktiken var en ERD-notation, fast relationer var begreppsmässiga i stället för informationsmässiga.

På åttiotalet fanns det ett samarbete mellan svenska myndigheter som tog fram en standard för systemutveckling. Jag tror att det bland andra var Kommundata som var drivande. Det resulterade bland annat i en variant av ERD-notation som i grunden liknar JMIE men har fyrkantiga gafflar och några andra egenheter. Den har levt vidare ända till idag som ett rent svenskt unikum. Den är idag känd som IRM-notation.   

Avgränsning

Jag har i den här artikeln avgränsat mig till de vanligaste och mest generella notationerna. Det vill säga de som hör till familjen Entity-Relational Diagram samt klassdiagram i UML Vi har därmed inte tagit upp följande notationer:

  • Object-role modelling (ORM) som är ett alternativ till ER-notation där man endast uttrycker elementära fakta, utan att strukturera dessa i entiteter, attribut och relationer.
    (Bör inte förväxlas med Object Relational Mapping). Det kanske jag återkommer till i någon senare artikel.
  • Diagramtyper som är värdefulla komplement till ett ER-diagram. Jag tänker särskilt på förekomstdiagram (Instance Diagram) och tillståndsdiagram (State charts), vilka jag planerar att beskriva i senare artiklar.

Vad tycker du?

Notationer är det ett område med personliga preferenser. Jag har nu redogjort för mina, fast försökt vara någorlunda objektiv ändå, om det nu alls är möjligt. Det är möjligt att du gör en annan bedömning. Det skulle vara intressant att höra både vad du håller med om och vilka andra bedömningar du gör.

/Peter Tallungs, IRM

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 3 juni. Då handlar det fortsatt om informationsmodellering, men med fokus på tillståndsdiagram.
Vill du prenumerera på denna artikelserie? Registrera din mailadress här.