Verksamhetsarkitektur (EA) Löser alla problem, eller hur..!? Per Lecktorp Seniorkonsult på Front End Per.lecktorp@frontend.se 070 – 930 82 07 Lars Rydell Verksamhetsarkitekt på Bolagsverket Lars.rydell@bolagsverket.se 076 – 1166389  Front End AB, 2013

Vad vi ska prata om Kort om vad är Enterprise Architecture? Under vilka förutsättningar kan EA vara till hjälp? Vad kan vi få hjälp med? Exempel på vad Bolagsverket gör med hjälp verksamhetsarkitektur  Front End AB, 2013

Varför EA? Jo...  Front End AB, 2013

Vad är EA – nåt nytt? Lite historia Vad står EA för Forskarrapport som definierar EA som begrepp kom 1985 (Zachman) Department of Defense startade på allvar efter Gulfkriget Federala myndigheter i USA startade 2001 Idag: Norge: Motsvarighet till svenska landstinget har central satsning på EA. Svenska myndigheter: FMV (sedan 2000), Skatteverket, Trafikverket, CSN, Bolagsverket, SJV med flera arbetar med EA Övriga: Volvo, Sandvik, Vattenfall, Swedbank, Scania, BT, SEB försäkringar med flera arbetar med EA. Vad står EA för Man brukar säga att E står för Enterprise Wide dvs hela verksamheten. A står för Arkitektur här ungefär, övergripande beskrivning av strukturen hos ett system och dess ingående delar. Blir något i stil med: Övergripande beskrivning av strukturen för hela verksamheten och dess ingående delar. Många olika tolkningar för vad Enterprise Architecture står för finns och debatteras!  Front End AB, 2013

Buzzwords! Verksamhetsarkitektur Enterprise Architecture Informationslogistik TOGAF Zachmam MODAF TOGAF - The Open Group Architecture Framework Zachman Framework – Klassificeringsdiagram för EA MODAF - Ministry of Defense Architecture Framework  Front End AB, 2013

Släpp det!  Front End AB, 2013

Det handlar om att: Hur ska vi göra nu? Arbeta för att förstå sin verksamhet: Vad den gör Varför den gör det Hur och vad den är uppbyggd av Hur den fungerar För att kunna svara på frågan: Hur ska vi göra nu? Tro inte på: Löften om en silverkula Att fler Buzzwords ger bättre resultat Att ett krångligt språk ger mer insikt  Front End AB, 2013

Att lösa verksamhetsproblem Om man inte är överens om problemet Om man inte tänker investera i eller arbeta med att lösa problemet Om man inte är beredd att ändra sitt sätta att göra saker Finns ingen lösning! Inget verktyg eller metod kommer att hjälpa! Blir problemet inte löst! Inget verktyg eller metod kommer att göra jobbet! Blir arbetet bortkastat Resulterar i hyllvärmare med eller utan verktyg Det handlar alltid om att lösa verksamhetsproblem och inte ett tekniskta, informations eller arkitektur-problem. När man kan beskriva verksamhetsproblemet kan man börja nysta i om problemet kommer av eller har lösning i teknik, information, eller arkitektur. Exempel: Om man inte lyckas leverera utlovade underlag till medborgarna inom specificerad tid så är det ett problem som ägs av den levererande organisationen (verksamheten). Detta problem kan då bero på fel av kund, underbemanning, brist i kompetens, krångliga processer, dåligt anpassade IT system eller tekniska fel. För att förstå vad som är roten till problemet bör man ha kunskap om all dessa delar och hur de samverkar. Det är inte ovanligt att man löser problemet på kort sikt utan att ha löst problemets underliggande orsaker. Ibland kan problemet bero på flera samverkande brister som var för sig inte är ”viktiga” nog för att åtgärdas.  Front End AB, 2013

Att lösa verksamhetsproblem Då löser man problemet! Och då är EA (verktyg och metoder) en god investering Om man: är överens om problemet arbetar med lösningen därmed ändrar sitt sätta att göra saker Det handlar alltid om att lösa verksamhetsproblem och inte ett tekniskta, informations eller arkitektur-problem. När man kan beskriva verksamhetsproblemet kan man börja nysta i om problemet kommer av eller har lösning i teknik, information, eller arkitektur. Exempel: Om man inte lyckas leverera utlovade underlag till medborgarna inom specificerad tid så är det ett problem som ägs av den levererande organisationen (verksamheten). Detta problem kan då bero på fel av kund, underbemanning, brist i kompetens, krångliga processer, dåligt anpassade IT system eller tekniska fel. För att förstå vad som är roten till problemet bör man ha kunskap om all dessa delar och hur de samverkar. Det är inte ovanligt att man löser problemet på kort sikt utan att ha löst problemets underliggande orsaker. Ibland kan problemet bero på flera samverkande brister som var för sig inte är ”viktiga” nog för att åtgärdas.  Front End AB, 2013

EA:s bidrag till lösningen Erbjuder verktygen en gemensam beskrivning (av verksamheten) att diskutera kring Erbjuder verktygen ett sätt att sammanställa, dela och återanvända information Erbjuder verktyget hjälp med att informera om nya arbetsätt och uppföljning När man arbetar med att bli överens om problemet Under arbetet med att hitta lösningen Vid förändring av arbetsätt Det handlar alltid om att lösa verksamhetsproblem och inte ett tekniskta, informations eller arkitektur-problem. När man kan beskriva verksamhetsproblemet kan man börja nysta i om problemet kommer av eller har lösning i teknik, information, eller arkitektur. Exempel: Om man inte lyckas leverera utlovade underlag till medborgarna inom specificerad tid så är det ett problem som ägs av den levererande organisationen (verksamheten). Detta problem kan då bero på fel av kund, underbemanning, brist i kompetens, krångliga processer, dåligt anpassade IT system eller tekniska fel. För att förstå vad som är roten till problemet bör man ha kunskap om all dessa delar och hur de samverkar. Det är inte ovanligt att man löser problemet på kort sikt utan att ha löst problemets underliggande orsaker. Ibland kan problemet bero på flera samverkande brister som var för sig inte är ”viktiga” nog för att åtgärdas.  Front End AB, 2013

Hur kan man göra detta bättre? Förstå problemet Sätt frågorna i fokus Skapa en gemensam bas av grundinformation (modell i databas / repository) Sortera all fakta efter grundinformationen Gör därefter analyserna  Front End AB, 2013

EA verktyg och TOGAF ? Verktygen Är hjälpmedel Tex Mood, Troux, Qualiware, Systems Architect mfl.. Är hjälpmedel Tankesättet och metoden kring verksamhetsarkitektur fungerar bra utan verktyg Verktyget förenklar arbetet och är nödvändigt när man vill hålla ordning på stora mängder information och relationer  Front End AB, 2013

Goda råd! Fokusera på det verksamheten vill åstadkomma/utveckla Vilka frågeställningar ska EA besvara för att bidra till detta Etablera styrning och förvaltning av EA tidigt! Försök inte göra allt eller ens klart… Utgå från frågeställningar/problem som ni vill lösa Samla in information som redan finns Analysera problemet, utvärdera informationen Förbättra och komplettera till dess ni har svar på frågorna  Front End AB, 2013

Goda råd! Se EA (verksamhetsarkitektur) som en tjänst Lägg inte energi eller tid på hur arkitektur ska bedrivas – ställ krav på att arkitekten hanterar dessa frågor! Fokusera på verksamhetsfrågorna och vilka underlag ni behöver skapa Gör som arkitekten säger. Börja…det är en resa Mål och användningsområden kommer att utvecklas allt eftersom resultaten ger nya insikter Håll fast vid metoderna och sköt förvaltningen av EA  Front End AB, 2013

Metamodellen, är den inte viktig? En metamodell är ett ”standardsätt” att sortera och bygga information i verktyget Bygger på ”Best Practice” Framtaget för specifika syften och användningsområden och ingår olika ramverk tex MODAF militärt ramverk, TOGAF civilt med IT fokus osv.. Inget som verksamheten behöver arbeta med Är främst ett hjälpmedel för EA arkitekten En metamodell är ingen lag och inte heller ett mål. Man kan använda valda delar, göra avsteg Man kan skapa en egen Kom ihåg att avsteg och förändringar i metamodellen kräver erfarenhet och kunskap för att bli bra  Front End AB, 2013