Arkitektur/SOA och verksamhetsnytta i samverkan Lars Wennerholm 080617 Källor: Dynamic Enterprise Architecture DYA Per Björkegren, Sogeti CIO Sweden Computer Sweden SysTeam Använd första bilden för att bädda för övergången till Visionen genom att inleda med några Frågeställningar som väcker nyfikenhet. Vad Kentor för sorts företag? Kentor har seden 1983 levererat IT-lösningar och IT-projekt till våra kunder. Hur har vi då lyckats med detta? BILD 1

Syfte med presentationen Bidra till Kentors säljbudskap kring SOA- och arkitekturtjänster? Underlätta för beslutsfattare att investera i affärsdriven arkitekturutveckling Visa på ett verksamhetsnyttoperspektiv snarare än ett teknisk perspektiv Underlag för eventuella nya paketeringar av tjänster inom ämnesområdet? BILD 2 | KENTOR

Definition av arkitektur. Många finns, här är en Enterprise Architecture: Ett samverkande set av regler och modeller, vilka vägleder design och implementering av: Processer Organisatoriska strukturer Informationssystem Informationsflöden Tekniska infrastrukturer inom en verksamhet (Ur boken Dynamic Enterprise Architecture, how to make it work)

Hur arkitektur kan visualiseras: Systemkarta med samband

Hur arkitektur kan visualiseras: Business Principles

Hur arkitektur kan visualiseras: Domänmodeller Affärs- och produktionsplanering

Hur arkitektur kan visualiseras: Blädderblock från ledningsmöte

Hur arkitektur kan visualiseras: Processmodell Customers Identify Needs & Demands Change Contract Rules CHANGE REQUEST REQUEST FORECAST CONFIRM FORECAST COMPILATION SCA Transforest Logistics Department Logistics Department Business Development Procurement Department Tactical planning Department Request Forecast & Need Receive & Consolidate Forecast & Needs Develop Services Locate Sources & Create Contracts Plan & Optimize resources Resource Supply Demand NEED COMPILATION REQUEST CONTRACT REQUEST CONFIRM Transport Subcontractor (Haulier) Create contract Resource Planning

Hur arkitektur kan visualiseras: Objektmodell

Hur arkitektur kan visualiseras: Tjänstemodell

Andra exempel Visionsdokument IT-strategi Kravkatalog Sekvensdiagram Checklistor Guidelines Nätverksskisser EA Ramverk: Bygger antingen på en process för att bygga upp en verksamhetsarkitektur och/eller på en så kallad metamodell som beskriver och skapar spårbarhet om den information som måste samlas in. De flesta, men inte alla, ramverk innehåller dessutom en beskrivning av de vyer som bör användas. Och vissa ramverk, till exempel FEAF (Federal Enterprise Architecture Framework) innehåller även referensmodeller för att beskriva specifika verksamheter.

Arkitekturbeskrivningsmodeller finns det en del… META Group (Gartner) Zachman TOGAF DoDAF TEAF FEA eTOM … Det viktiga är inte vilken man väljer, utan hur man kompletterar dem genom att beskriva HUR man får arkitekturarbetet att fungera och leverera nytta till organisationen

Vanligt nuläge Kontinuerlig press på IT att bli mer kostnadseffektiv Fokus flyttat till koncernnivå, CIO, smartare lösningar, lägre budget, mindre projekt Snabba omvärldsförändringar ger ständiga omprioriteringar Den totala IT-kartan blir alltmer komplex Arkitektur har i olika omfattning hamnat på agendan Rollen/befattningen Arkitekt har etablerats arkitekter anställts/anlitats Arkitekturbeskrivningar skapas i allt större omfattning De flesta ansatser har fokuserat på att omfattande beskriva arkitektur Baserat på metoder och koncept som föreskriver beskrivningsmodeller och hur de ska tas fram I princip alla verksamheter har någon form av problem som kan härledas till brister avseende Arkitektur Även de som har gjort någon ansats

Situationen: Arkitekturarbetet i praktiken Det spelar ingen roll för mig sålänge jag får mitt CRM-system! Grattis! Fortsätt med ert värdefulla arbete! Snyggt! Men det berör inte mig! Med det här gränssnittet löser vi problemet! Sida 14

En definition av EA Enterprise architecture: Ett samverkande set av regler och modeller, vilka vägleder design och implementering av: Processer Organisatoriska strukturer Informationssystem Informationsflöden Tekniska infrastrukturer inom en verksamhet (Ur boken Dynamic Enterprise Architecture, how to make it work) EA är ett ”modellbaserat angreppssätt” för att hantera IT och verksamhet ur ett helhetsperspektiv. (CIO Sweden)

Arkitekturarbetet påverkas av verksamhetens karaktär Process- dynamik Vision Behov DYNAMISK ARKITEKTUR Ingen förändring av Den interna verksamheten Fokus: idag STATISK ARKITEKTUR Ingen förändring av Marknad / omvärld Marknads- dynamik EA är VD:s verktyg, inte IT-chefens, för att Minimera risker, att samordna verksamhet och IT och att fatta bättre beslut.

Utmaningen… Att skapa en DYNAMIK mellan att upprätthålla en samman- hängande kostnadseffektiv helhet och att möta kontinuerliga behov av snabba lösningar för verksamheten Snabbhet & Smidighet Agility ”EPA- ingenjör” ”Ful-jobb” Verksamhets- behov IT-lösning ”Struktur- Fascist” ”Nej-sägare” ”Bakåt- Strävare” Ordning & Reda Coherence

Coherence- Behov av kostnadseffektiv IT, ordning & reda Effektiv delning av information Få utvecklingsmiljöer Effektiva applikationsgränssnitt Enhetligt arbetssätt Kräver enighet genom organisationen Kräver medvetenhet om arktitekturens roll och nytta i organisationen Efterlevnaden av arkitekturen ses ofta som det enda sättet att skapa enhetlighet, samtidigt som det ses som ett hinder för verksamhetens förändringsbehov

Agility-behov av flexibilitet, snabbhet Hur skapa flexibilitet/snabbhet utan att återfalla till ad-hoc och kaos? Hur överbrygga gapet mellan strategi och realisering? Hur säkra att all IT-utveckling bidrar till verksamhetsmålen? Hur kan man etablera en ”agile” arkitektur? Hur skapa balans mellan Coherence och Agility? SOA, Service Oriented Architecture En process för att dynamiskt hantera införande och vidareutveckling av EA, oavsett valt ramverk Agila utvecklingsmetoder och paketerade lösningar

Relationen mellan Affärsstrategi och IT-strategi Från Till Verksamhets- strategi Verksamhets- strategi IT- strategi IT- strategi Präglar också arbetet med enterprise-arkitekturen

Ansats kring arkitektur Arkitekturansatsen DYA® är byggt kring tre huvudprinciper: Arkitektur är inte ett mål i sig, utan ska alltid stödja verksamhetens syften Arkitekturen ska understödja förändringsprocessen Arkitektur KAN utvecklas inkrementellt « just-enough » och « just-in-time » arkitektur Initiativ oförenliga med arkitekturen kan rättfärdigas under vissa omständigheter Godkända kontrollerade avvikelser från arkitekturen (tillfälliga undantag) – ”Det är dömt att misslyckas om man drar igång sin EA-satsning utan riktning och mål och med ett för ambitiöst scope, man kommer raskt att modellera ihjäl sig” Mathias Ekstedt i CIO Sweden

Ansats kring arkitektur Primärt vill vi bygga in elementen snabbhet och smidighet in i den strukturerade arkitekturen Detta har inverkan på arkitekturens två huvudaspekter: Innehåll Beskrivningar Processer Rutiner -Eftersom modellförvaltningen innebär att man måste samla in information som är utspridd i hela företaget, inte bara på IT-avdelningen, är det också viktigt att arkitektteamet som står bakom EA-satsningen arbetar nära verksamheten Mats Geinevall

Ansats kring arkitektur Till att börja med är det frågan om innehåll, arkitekturen måste bestämmas och beskrivas Arkitekturinnehåll är en produkt, dvs ett resultat av ett projekt eller aktivitet Arkitektur måste utformas på ett sätt så att nya och oväntade lösningar kan implementeras så fort och så kostnadseffektivt som möjligt Arkitektur ska stödja snabba förändringar i verksamhets-processerna Beskrivningarna måste sedan kompletteras med processer och rutiner – dvs hur ska arkitektur hanteras och användas överallt inom organisationen Processen för utveckling och förvaltning av arkitektur bör implementeras som en dynamisk process som säkerställer en kraftfull och effektiv användning av arkitektur

Den teoretiska modellen enligt DYA© Företag vision/ mission objectives strategy Kunder IT vision syften strategi Arkitekturtjänster Defensiv strategi Offensiv strategi anställda Förutseende strategi Partners Utveckling utan arkitektur Utveckling utan Arkitektur Arkitektur- tjänster Utveckling med Arkitektur Ägare

DYA:s ® teoretiska modell -Val av utvecklingsväg Beroende på verksamhetens behov och rådande situation kan man välja en av tre utvecklingsvägar Huvudspåret man alltid ska sträva efter är en Förutseende strategi, och det är den som DYA alltid förespråkar. Strävar mot en planerad ”morgondagens arkitektur” Som alternativ finns Defensiv strategi och Offensiv strategi Båda dessa är avvikelsestrategier som kan behövas av olika skäl Båda betyder att arkitekturprocessen ”Implementering UTAN arkitektur” tillämpas Defensiv betyder att man inriktar sig på att bara hantera problematik på snabbaste och enklaste sätt Offensiv betyder att man till varje pris inriktar sig på att snabbt möta verksamhetsbehov, t ex skapa en komparativ fördel på en marknad, snabb differentiering för att generera intänkter Snabbt i båda fallen betyder att man inte hinner med arkitekturprocesserna eller att arkitekturprinciper och beskrivningar inte är fullständigt framtagna eller fastställda

Ett antal viktiga principer Arkitekturen är strategisk om IT är strategiskt Därmed ligger det yttersta ansvaret på översta ledningen Arkitekturen måste möjliggöra snabba förändringar Åstadkommes bl a med multidisciplinära team och ”projektstartsarkitektur” Kommunikation mellan verksamhet och IT-ledning är avgörande Sker bl a genom den Strategiska dialogen där beslut fattas om utveckling Verksamhetsmålen styr utvecklingen av arkitekturen Utveckling av arkitektur sker alltid som svar på ett verksamhetsbehov och baserat på Strategiska dialogen Nivån på arkitekturen kommer kontinuerligt att höjas om arkitektur- utvecklingen kopplas till viktiga verksamhetsförändringar Investeringar i arkitektur blir en naturlig del i verksamhetsinvesteringar i syfte att nå konkreta verksamhetsmål Arkitektur utvecklas ”just enough, just in time”, dvs. inkrementellt Beskrivs i modellen under Arkitekturtjänster, styr bl a bemanningen i arkitektteamet Flera utvecklingsstrategier är nödvändiga (föregående bild) Arkitekturprinciper och –processer måste vara en integrerad del av verksamhetsutvecklingen

De tre aspekterna på arkitekturtjänster Kronologi Område Omfattning Abstraktions- nivå

Grundläggande innehållsstruktur, tre typer av arkitektur Område, omfattning Grundläggande innehållsstruktur, tre typer av arkitektur Verksamhetsarkitektur Produkt-/tjänstearkitektur Processarkitektur Organisationsarkitektur Informationsarkitektur Dataarkitektur Integrationsarkitektur Applikationsarkitektur Teknisk arkitektur Middleware-arkitektur Plattformsarkitektur Nätverksarkitektur Verksamhet Processer Applikation Information Infrastruktur Teknik

Område, omfattning - Ytterligare en dimension Kategorisering utifrån olika kravgrupperingar Domänmodeller Retail Production Market & Sales Supply Chain Human Resource

Omfattning – skall stödja Lego-principen Självständiga byggbitar som kan utvecklas, förvaltas och ändras oberoende av varandra Exempel på principer för en anpassningsbar arkitektur: Data skall registreras och underhållas på ett ställe Applikationer får endast erhålla data från en auktoriserad källa Tydligt definierade kopplingspunkter måste finnas mellan alla huvudprocesser och informationsförsörjande tjänster IT-system skall ha separat implementerade styrande resp. exekverande mekanismer Presentation av information, verksamhetslogik och registrering av data skall implementeras separat Styrning/övervakning inriktas på gränssnitt mellan system i st f internt i systemen (”svart låda-princip”) Standardgränssnitt och –tekniker för integration skall användas

Abstraktionsnivå Hur ska principerna uttryckas? Vilka måste förstå? ”med kund menar vi.. ” Hur ska principerna uttryckas? Vilka måste förstå? Vilken nivå krävs? kund order avtal Det är viktigt att varje verksamhet sätter en nivå på arkitektur- beskrivningarna så att de är balanserade med den nytta de kan ge Mer konkret kan man tänka sig en ”vd-vy” som visar hur IT-systemen stödjer verksamheten eller en ”kodar-vy” som visar utvecklarna hur IT-infrastrukturen är uppbyggd. Tanken är att de olika intressenterna ska kunna välja abstraktionsnivå, alltså detaljnivå, så att de får precis så mycket information om en process som de behöver vid varje givet tillfälle -Philip Allega, Gartner

Kronologi Det finns alltid tre Kronologiska ”versioner” av arkitekturinnehåll: - Nuläge - Nästaläge - Målbild Framtidens arkitektur Målbild Källa: Gartner Nästa- läge Morgondagens arkitektur Nuläge Det är ”morgondagens arkitektur” som blir fundamentet för de ändringar som görs i principer och arkitekturmodeller Dagens arkitektur

DYA:s ramverk för Arkitekturbeskrivningar Verksamhetsmål Verksamhets- arkitektur Informations- arkitektur Teknisk arkitektur Prod/ service Orga- nisation Data Appli- kation Middle- ware Platt- form Nät- verk Process Allmänna Principer Alla rutor måste inte fyllas i till varje pris! Policys Direktiv Detaljeringsgrad Modeller

Implementation av arbetssättet, processen ”Plantera in” in rutiner, stora som små, i alla verksamhetsprocesser där arkitekturtjänster behövs eller krävs för att uppnå de övergripande målen med en arkitektur; - Kostnadseffektivitet Snabbhet / Smidighet ”De flesta företag kommer att misslyckas med införande av SOA om man inte inför rätt form av styrning. SOA handlar om rätt form av beteende, inte om att bygga eller köpa” ”Det största misstaget ett företag kan göra är att missa behovet av kommunikation och samarbete” -Burton Group Behov: En arbetsmodell

Förvaltning & Styrning Arbetsmodell Förvaltning & Styrning Realisering utom Arkitektur Verksamhetslösningar Verksamhets- behov Realisering inom Arkitektur Strategisk Dialog Verksamhets- lösningar Arkitektur- tjänster DYA® Dynamisk Arkitektur Verksamhet Processer Applikation Information Infrastruktur Teknik

-Några grundförutsättningar för arbetsmodellens synsätt Arkitekturstyrningen innebär en samling överenskommelser som säkerställer att enskilda utvecklingsinitiativ och upphandlingar samverkar med varandra för ett gemensamt övergripande verksamhetsintresse Genom att tydligt beskriva omfattningen av ett projekt och dess ansvar, blir både verksamhetsdomän och projektets frihetsgrad tydliggjort Ett resultat av ett projekt som är kompatibelt med arkitekturen kommer alltid att passa i ett större verksamhetsperspektiv

Arbetsmodellen Följande skall gälla Multidisciplinär samverkan – arkitektur är ett gemensamt ämne för verksamhet och IT “Just enough, just in time” – utlösaren för att utveckla/förändra arkitektur är ett tydligt verksamhetsbehov Verksamhetsbehovet avgör både fokus och prioritet för arkitekturaktiviteterna Arkitektteamet hålls litet, och när det behövs så utökas det med anställda från andra avdelningar eller konsulter Projektstartsarkitektur – projekt vägleds och stöds i sin användning av arkitektur genom att de innan start tillhandahålls en arkitektur eller ett arkitekturramverk specifikt för projektet. Innehåller ev frihetsgrader och hänvisning till utvecklingsstrategin (inom/utom arkitektur) Standarder och mallar – både design av arkitektur och utveckling av IT blir effektivare genom användninga av standarder och mallar Strategier – som komplement till den normala standardiserade arkitekturtillämpningen kan en defensiv och en offensiv arkitekturstrategi anammas för ett initiativ. Denna betyder att man av olika skäl strukturerat och under kontroll får avvika från standarden.

Förvaltning & styrning Strategisk Dialog DYA® Strategisk Dialog Verksamhets- behov Realisering inom Arkitektur Verksamhets- lösningar Realisering utom Verksamhetslösningar Arkitektur- tjänster Förvaltning & styrning Dynamisk Arkitektur Verksamhet Processer Applikation Information Infrastruktur Teknik Förvaltning IT-Governance Project-Portfolio management Information management Strategisk Dialog Information Managament policy Business – ICT alignment Business case development Arkitekturtjänster Enterprise architecture, business architecture, information architecture ICT architecture Working with architecture (architectural process) Architectural awareness workshops Architectural training and coaching Architectural assessments Realisering inom Arkitektur Business analysis Information analysis Project start architecture Göra rätt saker Sida 38

Strategisk Dialog, Göra rätt saker Definiera business case, dvs. vilka utvecklingsinitiativ skall startas IT och verksamhet tillsammans Utgå från verksamhetens mål och behov Startar med högsta ledningens prioriteringar Enterprise-arkitekten är rådgivare utifrån IT:s möjligheter Konkretiseras på mellannivå Arbetsgång Identifiera möjliga utvecklingsinitiativ Identifiera IT-möjliggörare för verksamheten Välj de initiativ som skall utvecklas till business cases Upprätta Projektförslag

Strategisk Dialog, använd hjälpmedel! 6 3 1 Smart cards 10 2 4 WAP CTI 12 EDI Totalt TTC TTM I-net Faktura Kund-service Teknologier Verksamhetsmål Snabb vinst Business case Ingen prioritet Ingen lösning Omfattning/kostnad Resultat 1 2 3 4 Låg Hög

Strategisk Dialog, Arkitekternas input Stöd till konsekvensanalyser Modeller Tillhandahålla arkitekturprinciper Arkitektur- tjänster

Strategisk Dialog, Resultatet Business Case Mål Förutsättningar Finansiell analys Grov plan Lösningsval etc Strategiskt dokument Verksamhetsmål IT möjliggörare Möjliga Business Case Projektförslag Uppdragsbeskrivning Organisation Genomförande Överlämning Resurser Styrning etc Offensivt -utom arkitektur Defensivt -utom arkitektur Inom arkitektur

Arkitekturtjänster-Göra saker Rätt DYA® Strategisk Dialog Verksamhets- behov Realisering inom Arkitektur Verksamhets- lösningar Realisering utom Verksamhetslösningar Arkitektur- tjänster Förvaltning & styrning Dynamisk Arkitektur Verksamhet Processer Applikation Information Infrastruktur Teknik Förvaltning IT-Governance Project-Portfolio management Information management Strategisk Dialog Information Managament policy Business – ICT alignment Business case development Arkitekturtjänster Enterprise architecture, business architecture, information architecture ICT architecture Working with architecture (architectural process) Architectural awareness workshops Architectural training and coaching Architectural assessments Realisering inom Arkitektur Business analysis Information analysis Project start architecture Göra saker rätt Sida 43

Arkitekturtjänster Arkitekturramverk Verksamhetsmål Verksamhets- Teknisk Informations- Allmänna Principer Policys Direktiv Modeller Prod/ service Process Orga- nisation Data Appli- kation Middle- ware Platt- form Nät- verk Projektstartsarkitektur Miljöer Avgränsning för lösning Designval Standarder & direktiv

Arkitekterna är aktiva tillsammans med verksamheten Strategisk dialog Business case team Arkitektur- tjänster Arkitektteam Utveckling inom ark Projektteam Utveckling utom ark

Ariktekturtjänster, arkitektteamet Chefsarkitekt Verksamhets- arkitekt Informations- arkitekt Teknik- arkitekt

Förvaltning & styrning Realisering DYA® Strategisk Dialog Verksamhets- behov Realisering inom Arkitektur Verksamhets- lösningar Realisering utom Verksamhetslösningar Arkitektur- tjänster Förvaltning & styrning Dynamisk Arkitektur Verksamhet Processer Applikation Information Infrastruktur Teknik Förvaltning IT-Governance Project-Portfolio management Information management Strategisk Dialog Information Managament policy Business – ICT alignment Business case development Arkitekturtjänster Enterprise architecture, business architecture, information architecture ICT architecture Working with architecture (architectural process) Architectural awareness workshops Architectural training and coaching Architectural assessments Realisering inom Arkitektur Business analysis Information analysis Project start architecture Sida 47

Realisering, Tre möjliga utvecklingsstrategier Defensivt Förutseende Offensivt Organisationen väljer lösning inom struktur Organisationen Ser tillfällig konkurrensfördel Organisationen måste reagera Verksamhet IT Kortsiktig lösning Kortsiktig lösning Utvecklings -process Kontinuerlig process- förbättring IT-lösningar: Hög Ad-Hoc & problemlösning IT-lösningar: Hög Ad-Hoc & problemlösning IT-lösningar: Hög förutsägbarhet I syfte att snabbt nå verksamhetsmål

Arkitekturtjänster – Utveckling inom arkitekturen Projektförslag Uppdragsbeskrivning Organisation Genomförande Överlämning Resurser Styrning etc Verksamhets- & IT-lösning ”Bygg-lov” Projektstartarkitektur Övervaka implementation Arkitektur- tjänster

Förutseende strategin, den planerade vägen Styrande arkitekturprinciper Verksamhets- arkitektur Informations- arkitektur Teknisk arkitektur Permanent rörelse Arkitekturtjänster Process IT-lösning I IT-lösning II IT-lösning III Utveckling inom arkitektur Periodisk rörelse Projekt Projektstart- arkitektur Utvecklings- process Urvecklings process IT-lösning IV Förutsägbart innehåll

Arkitekturtjänster – Utveckling utom arkitekturen Projektförslag Uppdragsbeskrivning Organisation Genomförande Överlämning Resurser Styrning etc Verksamhets- & IT-lösning Ledningsbrev Syfte, deklaration Avvikelser från ark. Projektdata Avgränsningar Överenskommelse om offensiv/defensiv implementation Överenskommelse om utveckling utom ark. Driftöverens- kommelse Övervaka implementation ”Bygg-lov” Ledningsbrev Arkitektur- tjänster

Överblick, sammanfattning av aktiviteter Business Case Förvaltning & Styrning Lednings- direktiv Realisering utom Arkitektur Projekt- startdirektiv Verksamhetslösningar Verksamhets- behov Realisering inom Arkitektur Projekt- starts- arkitektur Strategisk Dialog Verksamhets- lösningar Arkitektur- tjänster Arkitektur- ramverk DYA® Bygglov Dynamisk Arkitektur Verksamhet Processer Applikation Information Infrastruktur Teknik

What’s in it for Kentor? Diskussion… Stärka säljbudskapet kring SOA- och arkitekturtjänster generellt? Underlätta för beslutsfattare att investera i affärsdriven arkitekturutveckling Visa på ett verksamhetsnyttoperspektiv snarare än ett teknisk perspektiv Underlag för eventuella nya paketeringar av tjänster inom ämnesområdet? SOA/EA governance maturity assessment? Hur bra är företaget på att styra sin arkitekturutveckling, och stämmer riktningen och besluten med verksamhetens mål? ….

TACK!