Enterprise Architecture.

En presentation över ämnet: "Enterprise Architecture."— Presentationens avskrift:

1 Enterprise Architecture

2 Definition av arkitektur
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 (Dynamic Enterprise Architecture, how to make it work)

3 Exempel: Systemkarta med samband

4 Exempel: Verksamhetsprinciplista

5 Exempel: Domänprocessmodell
Affärs- och produktionsplanering

6 Exempel: Blädderblocksnotering från ledningsmöte

7 Exempel: Connected process model
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

8 Exempel: Object Role Model (ORM)

9 Exempel: IT-strategiska områden

10 Exempel: Sekvensdiagram

11 Exempel: Kravkatalog

12 Exempel: Verksamhetsobjektmodell

13 Exempel: Tjänstemodell

14 New terminal Up’n running
Exempel: Vision Well defined data model for terminal business Functions/mechanisms for centralised implementation Skilled personnel Well defined and supported routines Plan Implementation Define and create new terminal in terminal system Terminal Roll-out Agreement Made New terminal Up’n running Configurate data Set-up system Central functional test Configurate data Set-up system Central functional test Install on-site Test on-site Train the users Toolkit and Workshop 1 week 1 week 1 week

15 Exempel: Integrationsprocess (orchestration)

16 Andra exempel Checklista Guideline Nätverksskiss

17 VÅR historia: Cap Gemini:s IAF-modell
BA TI GOV IS DSE DIS

18 IAF Adaptive Architecture Roadmap
The Adaptive Architecture roadmap is markedly different from previous architecture approaches, and has been designed according to a number of key principles: extensive use should be made of re-usable architecture collateral such as adaptive architecture patterns and architecture labs to accelerate the development of the architecture it is based on the Adaptive IT Point of View and associated principles; the IT Strategy and Architecture activities are undertaken concurrently it follows the Adaptive IT Think Engagement model. There are 4 phases to the Adaptive Architecture roadmap which closely follow and feed into the 4 engagement events: Discovery: Establishes the terms of reference, objectives and key inputs for the architecture related activities Visioning: Derives the TO BE conceptual architecture and associated business services based on the Adaptive IT point of view Future State: Develops the supporting logical architecture which delivers the technology services supporting the TO BE business vision Mobilisation: Produces the physical architecture comprising IS and IT products and services supporting the logical architecture and a migration plan providing the platform for the subsequent Adaptive IT Build activities.

19 Andra aktörer META Group (Gartner) Zachman TOGAF DODAF TEAF FEA ..

20 Det finns många typer av verktyg..

21 Det finns många verktyg för EA..

22 Nuläget 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 Organisationer har sedan en tid skapat rollen/befattningen Arkitekt och anställt/anlitat arkitekter 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 beskrivnings-modeller 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

23

24 DYA® är en ansats till att kunna hantera det oändligt komplexa arkitektur-ekosystemet
Företag vision/ affärsidé syften strategi Kunder IT vision syften strategi Defensiv strategi Offensiv strategi Förutseende strategi anställda Utveckling utan arkitektur Utveckling utan Arkitektur Partners Arkitektur- tjänster Utveckling med Arkitektur Ägare

25 Arkitekturens karaktär i en verksamhet
Process- dynamik Vision Behov DYNAMISK ARKITEKTUR Fokus idag Ingen förändring av Den interna verksamheten STATISK ARKITEKTUR Ingen förändring av Marknad / omvärld Marknads- dynamik

26 En ny uppfattning / 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 avvikelser från arkitekturen

27 En uppsättning av överenskommelser
Arkitektur kan ses som en samling överenskommelser som säkerställer att enskilda/åtskilda utvecklingsarbeten 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

28 Arkitekturarbete 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!

29 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 ”EPA- ingenjör” ”Ful-jobb” Verksamhets- behov IT-lösning ”Struktur- Fascist” ”Bakåt- Strävare” Ordning & Reda

30 Syftet med Dynamic Architecture
Primärt vill vi bringa elementen snabbhet och smidighet in i den strukturerade arkitekturen Vi kallar detta ”dynamic architecture”, en arkitektur speciellt avsedd för att underlätta förändring Detta har inverkan på arkitekturens två huvudaspekter: Innehåll Beskrivningar Processer Rutiner

31 Enligt DYA.. .. är Arkitekturprocesserna viktigare än arkitektur-produkterna .. är Arkitektur en möjliggörare till förändring .. skapas dynamik genom “Just enough, just in time architecture” .. är arkitektur en kontinuerlig process .. är avvikelser tillåtna, men bara under kontroll

32 Hur skapar man snabbhet och smidighet?
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 snabbt stödja förändringar i verksamhetsprocesserna Beskrivningarna måste sedan kompletteras med processer och rutiner – dvs hur ska arkitektur hanteras ö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 fenomenet arkitektur

33 Tre saker att vara överens om avseende innehåll
Kronologi Omfattning Avgränsning Abstraktions- nivå

34 Omfattning / Innehåll Grundläggande innehållsstruktur!
Verksamhetsarkitektur Produkt-/tjänstearkitektur Processarkitektur Organisationsarkitektur Informationsarkitektur Dataarkitektur Integrationsarkitektur Applikationsarkitektur Teknisk arkitektur Middleware-arkitektur Plattformsarkitektur Nätverksarkitektur Verksamhet Processer Applikation Information Infrastruktur Teknik

35 Omfattning/Innehåll - Ytterligare en dimension
Kategorisering utifrån olika kravgrupperingar Domänmodeller per verksamhetsområde Retail Production Market & Sales Supply Chain Human Resource

36 Abstraktionsnivå ”en helpdesk för alla frågor”
”med kund menar vi.. ” ”välutbildade anställda” ”lagra kunddata centralt” ”en helpdesk för alla frågor” kund order avtal Hur ska principerna uttryckas? Vilka måste förstå? Vilken nivå krävs? Det är viktigt att varje verksamhet sätter en nivå på arkitektur- beskrivningarna så att de är balanserade med den nytta de kan ge

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

38 DYA:s ramverk för Arkitekturbeskrivningar
Verksamhetssyften Verksamhets- arkitektur Informations- arkitektur Teknisk arkitektur Prod/ service Orga- nisation Data Appli- kation Middle- ware Platt- form Nät- verk Process Allmänna Principer Policys Direktiv Detaljeringsgrad Modeller

39 OK, nu har vi beskrivningsnivån klar, då återstår praktiken

40 DYA-aspekter på förändringsprocessen
Följande aspekter är solklara.. 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 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.

41 Verksamhetsutveckling / Förändringsprocess
DYA:s huvudprocesser Verksamhetsutveckling / Förändringsprocess Realisering utom Arkitektur Realisering inom Arkitektur Strategisk Dialog Arkitektur- tjänster DYA Det är dessa processer som sammantaget skapar dynamiken mellan snabbhet/rörlighet och enhetlighet/välstruktur

42 IT-ledning/styrning/organisation
DYA:s tjänstemodell IT-ledning/styrning/organisation 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

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

44 DYA handlar helt enkelt om att plantera 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

45 DYA:s exempel på arkitekturtjänster
Investerings- kalkyl IT-ledning/styrning/organisation Brev till ledningen Projekt- direktiv Realisering utom Arkitektur Verksamhetslösningar Verksamhets- behov Projekt- starts- arkitektur Realisering inom Arkitektur Strategisk Dialog Verksamhets- lösningar Arkitektur- tjänster Arkitektur- ramverk DYA Bygglov Dynamisk Arkitektur Verksamhet Processer Applikation Information Infrastruktur Teknik

46 Man kan välja olika strategi för att jobba med arkitektur
Denna strategi gäller primärt vilket ansats man ska ha för ”Morgondagens arkitektur” Huvudspåret man alltid ska sträva efter är en Föregripande strategi, och det är den som DYA alltid förespråkar 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 Snabbt i båda fallen betyder att man inte hinner med arkitekturprocesserna eller att arkitekturprinciper och beskrivningar inte är framtagna eller fastställda

47 OK, då har vi innehållet och processerna. Hur går man då tillväga?

48 Hur går man vidare Jag refererar här till Martin nya material som jag ännu inte översatt, men grunden bör det se ut enligt följande Man kan göra det enkla arkitekturtestet för att förstå vart man står Oftast behöver ett arkitekturarbete ”säljas in” Väl insålt är “DYA®-scan” med den stora mognadsmatrisen som resultat en mycket bra början I nästa steg planerar man arbetet och tar hänsyn till de olika områdena Vision, Personal, Processer och Artefakter och gör en plan..