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.

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.

Digitaliseringen måste få en central roll i klimatpolitiken

IRM är medlemmar i föreningen och branschorganisationen Digitaliseringskonsulterna. Under våren har Digitaliseringskonsulterna utvärderat hur de uppmaningar som vi överlämnade till regeringen i mars 2019 har mottagits av politiken, och skrivit en debattartikel som publicerats i Computer Sweden. Digitaliseringskonsulterna ger tre konkreta förslag till regeringen.

Det finns risk för att Sverige missar möjligheter till snabba och radikala utsläppsminskningar som ökad digitalisering kan möjliggöra. De övergripande målen i Sveriges digitaliseringspolitik är att Sverige ska vara bäst i världen på att använda digitaliseringens möjligheter. Trots det saknas många av dessa möjligheter i regeringens klimatpolitiska handlingsplan. Detsamma gäller omvänt där digitaliseringspolitiken skulle kunna ha större klimatambitioner än idag.

IRM är medlem i föreningen och branschorganisationen Digitaliseringskonsulterna. Under våren har Digitaliseringskonsulterna utvärderat hur de uppmaningar som vi överlämnade till regeringen i mars 2019 har mottagits av politiken.

I samband med utvärderingsresultatet presenterades publicerade Computer Sweden en debattartikel som signerats av Digitaliseringskonsulternas styrelse. Läs den här. 

Digitaliseringskonsulternas medlemmar förenas i ambitionen att hjälpa samhället att se och använda digitaliseringens möjligheter. Vi jobbar aktivt för att stötta politiken, näringslivet och offentlig sektor i att förstå hur vårt land, genom digitalisering och innovation snabbt kan transformeras till fossilfritt välfärdssamhälle och med ökad konkurrenskraft och tillväxt som resultat. Vi vill också stötta våra kunder i strävan att bidra till ett mer hållbart samhälle med inspiration, verktyg och rekommendationer.

Gör som oss – bli medlem!

Som medlem får du möjlighet att:

  • Utveckla er roll som lösningsaktörer i omställningen till ett fossilfritt samhälle.
  • Synliggöra er kompetens genom att bidra i strategiska processer och initiativ där Digitaliseringskonsulterna är inbjudna att delta.
  • Stärka er kompetens inom digitalisering, innovation och klimat.
  • Ta del av gemensamma satsningar och initiativ arrangerade av Digitaliseringskonsulterna.
  • Ta del av kundnära dialoger med andra branscher om deras förändrade behov av digitalisering i relation till klimatomställningen.
  • Påverka Digitaliseringskonsulternas fortsatta arbete genom engagemang i en arbetsgrupp
  • Accelerera det egna hållbarhetsarbetet genom kunskapsdelning och nätverkande.
  • Utveckla ert eget värde-erbjudande kopplat till digital transformation, innovation och klimat.
  • Få insyn i och möjlighet att påverka framtida politiska beslut som påverkar vår bransch.
  • Använda gemensamt framtagna debattartiklar, pressmeddelanden etc i ert eget kommunikationsarbete.

Anslut er här

Certifierad verksamhetsarkitekt – för vem?

Certifierad verksamhetsarkitekt är en utbildning för dig som vill vara en del av det team som skapar förutsättningar för verksamheten att förändras i takt med omvärlden. I den nödvändiga, ständigt pågående, verksamhetsutvecklingen är verksamhetsarkitektens roll central för en innovativ och lättrörlig organisation.

Verksamhetsarkitekten knyter ihop olika verksamhetsutvecklingsinitiativ och IT-satsningar i den riktning som verksamheten strävar genom att synliggöra och beskriva strukturen så som den ser ut, de värdeströmmar som finns, visualisera målbilder och alternativa scenarios samt genom att ta fram en plan för hur man ska kunna nå det önskade läget.

Om du vill ha smarta strategier och effektiva verktyg för att driva ett sådant arbete så är utbildningen Certifierad verksamhetsarkitekt för dig. En av förra terminens elever uttryckte det så här:

”Jag har fått nya perspektiv, en ny verktygslåda och massa energi. 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!”

Utbildningen upplevs ibland som tuff. Det kan vara en utmaning att börja tänka i nya banor och utveckla nya tankesätt i hyffsat högt tempo. Därför får varje elev stöd av erfarna verksamhetsarkitekter som till vardags arbetar i olika branscher, företag och organisationer. Eleverna får även personlig feedback på en övningsuppgift som löper genom utbildningen där de beskriver och arbetar med en angelägen del av sin egen verksamhet, eller i någon annan de har god insikt i. 

Vill du veta mer om vad det innebär att utbilda sig till certifierad verksamhetsarkitekt? 

Boka en plats på vårt kostnadsfria webbinarium, som vi levererar i samarbete med Dataföreningen Kompetens, 23 april där verksamhetsarkitekt och utbildningsansvarig Lars Thomasson tillsammans med en f d elev presenterar utbildningen Certifierad verksamhetsarkitekt samt ger inblick i verksamhetsarkitektens vardag.

Försvar för enkla verktyg – del 1

En serie i serien. Med denna artikel inviger vi en artikelserie på fem artiklar om informationsmodelleringsverktyg i artikelserien Informationsarkitektens tankar.

Informationsmodellering är ett hantverk. För en hantverkare är verktygen viktiga. Låt oss se över vår verktygslåda. I den här artikeln vill jag försvara de enkla modelleringsverktygen.

Det finns ett antal specialiserade modelleringsverktyg, för både informationsmodeller och andra modeller. De är egentligen hela verktygsplattformar tänkta att stödja modelleringsarbetet genom att integrera grafiska och verbala beskrivningar på ett strukturerat sätt. De ger ofta även stöd för att bygga upp ett förråd för en organisations samtliga modeller, ett repository.

En annan väg att gå är att använda sig av en kombination av vanliga generella verktyg, såsom basala rit-, -skriv, dokumenthanterings- och samarbetsverktyg där man själv får bygga upp de strukturer man behöver. Det är en ”best of breed”- strategi, de vill säga att man strävar efter att använda det bästa verktyget man kan finna för varje enskild arbetsuppgift i modelleringsarbetet.

Jag och mina kollegor har hjälpt många team och organisationer att bygga upp verksamhets- och informationsarkitektur samt Data Management. Vi har därmed erfarenheter från många olika sammanhang och förutsättningar.

Mot denna bakgrund har jag kommit till att förorda det senare alternativet då en kombination av enkla verktyg inte bara är gångbart utan det enda verkligt framgångsrika jag känner till. Enkla verktyg är inte enkla i den meningen att de är simpla. Tvärtom! De ger den flexibilitet och uttrycksfullhet vi behöver för att göra ett bra jobb som informationsarkitekter.

Jag har upplevt att denna ståndpunkt är kontroversiell bland enterprise- och it-arkitekter. Jag vill därför i denna artikel, och fyra efterföljande, tydligt och noggrant argumentera för den vägen. Kanske kan jag få någon att bli mer öppen för det alternativet. Eller också blir jag avfärdad som Luddit. (Ludditer var de engelska teknikfientliga väveriarbetarna som bjöd våldsamt motstånd till de nya effektiva vävstolarna i början av 1800-talet.)

Den enkla verktygslådan

Här är listan på de typiska verktyg jag rekommenderar. Det finns förstås likvärdiga alternativ, men då av samma enkla slag.

  • Microsoft Visio: För att rita
  • Microsoft Word: För textdokument och för att integrera text och bild
  • Katalogstruktur på server, eller liknande: Som repository för modeller
  • Ändringshistorik i dokument samt rutin för att spara versioner i katalogstrukturen: För versionshantering
  • Wiki eller det samarbetsverktyg som används i den organisation jag jobbar: För att publicera modeller samt kommunicera ut vad som händer
  • Storformatskrivare: För utskrift av modeller
  • Whiteboard och digitala samarbetsverktyg: För modelleringssessioner.

Jag kommer i följande fyra artiklar motivera och beskriva hur man kan använda respektive verktyg i verktygslådan. I denna inledande artikel ger jag generella motiveringar för kombinationen av enkla verktyg i motsats till de specialiserade.

Motivering för enkla verktyg

Här följer ett antal motiveringar till att välja enkla verktyg.

Motivering 1: Enkla verktyg ger frihetsgrader och möjliggör den rikare och mer kraftfulla gestaltning som vi behöver

Våra modeller kan bli mycket bättre gestaltade än vad som är vanligt idag. Det gäller alla slags modeller. Om vi ska lyckas få en organisation att samlas kring modellerna och låta dem representera en gemensam förståelse måste de bli mycket mer överskådliga, tydliga och tillgängliga. Samtidigt behöver de ges ett rikare uttryck genom att kombinera olika slags kunskap. Det handlar om hur vi ritar. Det vill säga struktur, disposition, färger, gråskalor, linjetyper, typsnitt, symboler, samt hur vi integrerar text och bild. Vi behöver kombinera och integrera olika slags diagram med varandra samt med textuella beskrivningar.

Det sätt vi i branschen idag arbetar med våra modeller har en stor potential till förbättring. Det handlar också om hur vi hanterar våra modeller, och hur vi tillgängliggör dem. För att kunna göra allt detta på ett bra sätt behöver vi verktyg som ger frihetsgrader, som inte begränsar oss, låser in oss och hindrar oss i det vi behöver göra.

Motivering 2: Enkla verktyg främjar experimenterande och därmed utveckling av alla våra områden där modellering är en viktig del.

Som yrkesgrupp behöver vi utveckla informationsmodelleringsområdet. För det behöver vi verktyg som ger oss den friheten.

Jag vill jämföra med vad som hände inom systemutveckling kring millennieskiftet. Vid slutet av 90-talet var tron på specialiserade modelleringsverktyg stor. Rational Unified Process var den förhärskande utvecklingsmetoden och Rational Rose var det modelleringsverktyg som skulle stödja hela utvecklingsprocessen. De organisationer som var ambitiösa och anammade detta arbetssätt fick det svårt. Metoden framställdes och tolkades på ett sätt som gjorde den överlastad och rigid. Själva metoden och verktyget styrde tänkandet och arbetssättet i stället för att vara en verktygslåda. Det blev att man fokuserade på att betjäna verktyget och utvecklingsmetoden i stället för att koncentrera sig på vad användare och verksamhet behövde. Man blev på så sätt en operatör av ett verktyg utan egen agens och ansvar.  

I det sena 90-talet växte missnöjet hos utvecklare och utifrån några individer växte det fram en motrörelse. Några utvecklare, på lite olika ställen, började tänka på vad de själva verkligen behövde och vad som fungerade. De tog fram mer basala och hantverksmässiga arbetssätt som parprogrammering, test-first design, scrum-tavlor med mera. Det nya tänkesättet grodde och spred sig i utvecklarsamhället. Ett par år efter millenniumskiftet fick det etiketten agila rörelsen. Utvecklare byggde själva enkla verktyg för att stödja sitt arbete. Mest kända blev testverktyg för att automatisera tester samt så kallade refactoring-verktyg för att snabbt och enkelt göra ändringar i kod.

Jag menar att vi behöver en liknande rörelse bland oss informationsarkitekter. Det vi behöver är en ny vår för arkitektarbetet som ett hantverk, precis det som agila rörelsen var för systemutvecklare för två årtionden sedan. Vad gäller arbetssätt så har vi redan lärt av agila rörelsen och alla förstår nog nu att vi behöver smidiga och mer kommunikativa arbetssätt. Men då det gäller verktyg återstår att överge de stora tunga modelleringsverktygen och i likhet med systemutvecklarna gå till oss själva, och ställa oss frågan vad vi egentligen behöver. Tillbaka till hantverket, och vad som verkligen stödjer det.

Jag har sett organisationer där arkitekterna varit som slavar under avancerade verktyg. De har varit upptagna med att mata verktygsmonstret. Resten av organisationen har inte haft nytta av arkitekterna, som befunnit sig i en parallell värld utan kontakt med verksamhetsutvecklingen.

Och denna nya vår jag hoppas på har faktiskt redan grytt på en del ställen. Jag har sett organisationer där verksamhets- och informationsarkitekter till sist givit upp sina tunga arbetssätt och verktyg. De har lämnat sina slutna rum, klivit ner från elfenbenstornet och gått ut där verksamhetsutvecklingen sker, bland utvecklarna och i verksamheten. De har sett hur de kan stödja utvecklingsarbetet. De har då, för första gången, känt sig välkomnade av utvecklare och domänexperter. De modellerar fortfarande, men nu med enkla tekniker som tjänat syftet på ett helt annat sätt.

I de fall de trots allt behövt lite mer verktygsstöd har de, precis som utvecklarna, själva experimenterar och byggt de verktyg de behövt. Jag ska försöka ge exempel på sådana verktyg framöver.

Dessa egenbyggda verktyg kan sedan i likhet med vad som hänt inom utvecklarvärlden så småningom kommersialiseras och bli standard. Det är egentligen alltid så det sker då ett yrkesområde utvecklas på riktigt. Alltid utifrån professionen och hantverket. Aldrig från verktygsleverantörerna.

Motivering 3: Enkla verktyg sätter fokus på uppgiften

Att ta ansvar för något stort, till exempel en informationsarkitektur, kan vara skrämmande. Det är många saker man måste ta ställning till och kanske behöva försvara. Då är det lockande att gömma sig bakom ett ramverk, en industrimodell, en metod eller ett verktyg som synes ge objektiva svar. Det är att fly undan det ansvar vi har. Då blir jag en operatör av ett verktyg i stället för informations- eller verksamhetsarkitekt.

Vi behöver i stället fokusera på vad som behöver lösas i verksamheten och använda de verktyg som gör jobbet. Inte först välja verktyg för att sedan bara mata detta.

Motivering 4: Enkla verktyg minskar beroendet

Om man i en organisation har tagit in ett avancerat modelleringsverktyg så medföljer det ett antal metamodeller, vilka styr hur de modeller man tar fram måste se ut och relatera till varandra. Om man senare vill ändra detta kan det bli mycket dyrt och svårt. Verktygen är i själva verket ofta en hel plattform av verktyg som hänger samman. Man blir på flera sätt, på gott och ont, beroende av leverantören och dennes utveckling av plattformen.  

Vanliga argument för specialiserade verktyg

När man argumenterar för en enkel verktygslåda får man ofta mothugg. Här följer ett antal argument som man stöter på och hur jag vill bemöta dem. 

Argument 1: Specialiserade verktyg ger konsistens

Specialiserade verktyg har en metamodell som styr hur vi kan modellera. Det gör att vi alla ritar och beskriver på samma sätt vilket är viktigt. Om vi inte gör på samma sätt blir resultatet spretigt, återanvändningen svår och kvaliteten lidande. Det följer vanligen med metamodeller vi kan välja mellan och i de mer avancerade verktygen kan vi själva, eller med hjälp från konsulter, ta fram en egen metamodell som passar oss.

Mitt motargument: Sättet vi modellerar behöver utvecklas för att på allvar bli relevant för våra verksamheter. Vi behöver alltså se det som ett hantverk i utveckling. Då är experimenterandet viktigt, att vi söker oss fram och lär oss. Vi ska då inte standardisera arbetssätt, notationer, metamodeller med mera. Det skulle frysa all utveckling och fortsätta hålla oss fast på det stadium vi är idag. Däremot ska vi dela erfarenheter och inspireras av varandra. Men det är något helt annat.

Det finns alltid, inom alla områden en motsats mellan utveckling och standardisering. Vi ska standardisera det vi tycker att vi nått en mognad inom. Men bara där. Där vi behöver utveckling ska vi tvärtom befrämja att vi gör olika, inte bekämpa. Vi behöver tåla och bejaka spretigheten. Utveckling innebär experimenterande.

När vi har lärt oss vad som verkligen fungerar kommer saker och ting att mogna och vi kommer naturligt att gravitera mot något av en de facto-standard. Men att gå utvecklingen i förväg och bestämma en standard innan vi har nått den mognaden är fel. Det är att frysa all utveckling. Därför behöver vi frihetsgrader. Det betyder inte kaos, utan bara att vi i får vara beredda på varianter och förbättringar i små steg. Och även något vilt försök ibland! Det är så utveckling går till. Överallt och alltid.

Argument 2: Specialiserade verktyg ger struktur och ordning

Specialiserade verktyg styr hur och var vi spar, versionshanterar och publicerar modeller. De ger oss ett strukturerat repository. Det gör att resultatet inte bara blir högar av osorterade modeller på olika ställen med oklara syften och sammanhang.

Mitt motargument: Vi behöver alltid ett strukturerat repository. Vi vill inte ha oordning. Men det är mycket lätt att ordna det på ett enkelt sätt och på vilken lagringsyta som helst där man kan ha filkataloger av något slag, och något slag av enkel åtkomstkontroll och versionshantering.

Det är fel att tro att ett specialiserat repository krävs för ordning och reda. Ett specialiserat repository ger heller inte ordning och reda av sig självt. Vi behöver även då tänka igenom och komma överens om saker och ting. Den största faran med verktyg som styr oss är kanske just den tankefällan, att vi tror att vi inte behöver tänka själva. Vi har sett modellbibliotek som varit total kaos i verktygsbaserade repositories och jag tror faktiskt att vi sett fler välordnade bibliotek bland de som byggs mera manuellt. Jag är övertygad om att när jag behöver bygga något själv leds jag in på att tänka igenom och ta ansvar för vad som behövs.   

Argument 3: Specialiserade verktyg ökar produktiviteten

Verktyget hjälper mig. Jag kan återanvända delar av andra modeller när jag gör en ny, eller referera till befintliga. När jag vill göra en ändring av något som manifesterar sig på många ställen behöver jag bara ändra på ett ställe. När jag vill publicera en modell gör jag det automatiskt. Versionshanteringen är inbyggd vilket gör att den går lätt och smidigt. Jag behöver inte fundera så mycket på hur jag ska göra rent praktiskt med dessa hushållsbestyr så jag kan koncentrera mig på själva modellerandet.

Mitt motargument: Jo, verktyget hjälper dig förvisso med några enkla uppgifter. Men inte alls så mycket som man kan tro, och inte alls med det som är det väsentliga; hur du gör riktigt bra modeller och hur du når ut med dem. Tvärt om hindrar det dig. Så triviala uppgifter går kanske något snabbare – men till ett mycket högt pris.

Om vi definierar produktivitet som hur mycket nytta vi gör, hur bra vi når ut och hur vi hjälper människor och team att hantera sin komplexitet så vinner de enkla verktygen överlägset. 

Det finns ett talesätt som säger ”A fool with a tool is still a fool”. Det brukar motvilligt citeras av verktygssäljare när man pekar på misslyckade införanden av deras produkter. De vill betona att deras fina verktyg trots allt inte garanterar ett bra resultat, utan att det kan finnas dumma människor som inte begriper hur de ska användas. Det finns ett tillägg till talesättet som säger ”A fool with a tool makes a faster fool”. Det vill säga att om ett verktyg ökar produktiviteten utan att verktygsanvändaren gör ett bra jobb hamnar man snabbt i ett dåligt läge.

Argument 4: Specialiserade verktyg stödjer samarbete

Verktyget stödjer att flera kan jobba samtidigt med samma modell, kanske även från olika geografiska platser.

Mitt motargument: Jo, verktyget har funktioner för detta. Men det fungerar bättre med de generella samarbetsverktygen vi använder i övrigt i våra distansarbeten.

Konflikten mellan viss automatisk hantering och stöd för rik gestaltning

Jag menar att om vi använder de specialiserade verktyg som finns så får vi visserligen stöd för vissa enkla uppgifter.

Men vi väljer samtidigt bort möjligheten till att göra riktigt bra modeller.

Vi kan inte få både och. Åtminstone inte idag. Och inte förrän vi själva inom professionen bidrar till den utveckling som kanske kan ge oss sådana verktyg.

Och vi tenderar till att både övervärdera nyttan av den lilla automatisering vi kan få samt att undervärdera vikten av att göra riktigt bra modeller som når fram.

I själva verket är det så krasst att om vi inte når fram har vi inget som motiverar vår existens.

De ivrigaste proponenter för specialiserade verktyg jag mött har nästan i samma mening beklagat att de inte har gehör hos it- och verksamhetspersoner för vad de gör, utan blir ständigt kringrända av utvecklingsprojekten. Det kanske skvallrar om något?

Fortsättning följer

Jag är medveten om att den här posten väcker många frågor. ”Peter pratar mycket om att vi ska göra bättre modeller men inte hur det går till.” Det är ett stort område, men jag vill steg för steg i den här artikelserien ge mitt bidrag till det.

Vad är din erfarenhet? Vilka verktyg använder du? Handen på hjärtat, vad fungerar på riktigt?

/Peter Tallungs, IRM

Nästa del i miniserien om informationsmodellerarens verktyg publicerar vi torsdag 22 april. Vill du prenumerera på artikelserien Informationsarkitektens tankar? Registrera din mailadress här.