Lennart Eriksson Enterprise Architect Grundare onroute group AB EA-arbete i praktiken Lennart Eriksson Enterprise Architect Grundare onroute group AB

Lennart Eriksson lennart.eriksson@onroute.se Marie + Jessica med Molly(barnbarn) och Johanna Utvecklare, projektledare, DBA m.m. 10 år som Chefsarkitekt för SEB gruppen Grundare onroutegroup AB www.onroute.se Intressen Familj Utförsåkning Segling Lite IT  Presentation av talare samt belysa vilken bakgrund som finns.

Affärsproblem att undvika! Vilka primära symptom skall vi vara vaksamma på? Hur kan vi diagnostisera varför? Vilka effekter uppstår p.g.a. dessa beteenden?

Symptom Bristande integration, lång tid för införande av nya funktioner, komplex driftbild ger dyrt IT-stöd Kortsiktiga beslut och/eller bristande strategisk inriktning leder till cykliskt problem 1 De 2 vanligaste symptomen/uttryck som affärsansvariga ser och även en orsak till varför de beslut som fattas ständigt leder till återkommande problem av aktuell typ.

Rats’ nest Ge anslag att även med serier av intelligenta och ekonomiskt sunda beslut kommer ett IT-stöd av bli ett råttbo om inte en stor vikt läggs vid Service orientering och arkitektur. * Adding up several least expensive, most expedient options doesn’t yield either the least expensive or most expedient overall long term solution. On the contrary , rats nests are among the most expensive, time consuming parts of IT today. Källa: Service Orient or Be Doomed . 2006, ISBN: 0-471-76858-8

Hur angripa problemen? Vilka primära symptom skall vi vara vaksamma på? Hur kan vi diagnostisera varför? Vilka effekter uppstår p.g.a. dessa beteenden?

Ett av flera stora ramverket som kan vara mycket bra som stöd för den långsiktiga processen. Glöm inte version 2.0 med operationsrad. 2017-04-03 7

Operationella modeller Coordination Unification Country 1 All Countries High Country 2 Customers Customers Country 3 Business process integration Diversification Replication Country 1 Country 1 Customers Customers Low Country 2 Country 2 Customers Customers Viktigt att innan arbetet startar säkerställa att ledning och program är överens om vilket mål vi siktar på. Coordination: Merryl Lynch Global Private Client Shared customers, products or suppliers Operational unique business units or functions Autonomous business management IT consensus Unification: Dow Chemical Customers or suppliers can be local or global Globally integrated business processes High level process owners design standardised processes IT descisions made centrally Diversification: JM family enterprise Few if any shared customers or suppliers Independent transactions Operationally unique business units. IT-.descisions made in business units. Replication: TD Bankworth Feew shared customer or suppliers Operational similar business units Autonomous business unit leaders Central control over business process design Centrally managed IT-services Country 3 Country 3 Customers Customers Low High Business process standardization Källa: MIT Sloan Center for information systems and IMD

Stages of Enterprise Architecture Maturity Business Silos Where companies look to maximize individual business unit needs or functional needs Standardized Technology Providing IT efficiency through technology standardization and, in most cases, increased centralization of technology management Optimized Core Which provides companywide data and processes standardization as appropriate for the operating model Business Modularity Where companies manage and reuse loosely coupled IT-enabled business process components to preserve global standards while enabling local differences Stadier inom arkiteturell mognad som organisationer måste gå igenom. Hoppa över steg fungerar oftast inte. Viktigt förstå “var är mitt företag” innan åtgärder startas. Källa: MIT Sloan Center for information systems and IMD

Foundation for execution Vilken “operating model” har vår verksamhet? Vilken “foundation for execution” skall vi ha? Strategic initatives Strategic initatives Strategic initatives Strategic initatives Operating model Defines Integration and Standradization requirements Enterprise architecture Establishes priorities Learning And exploitation Defines core capabilities Updates and evolves architecture Engagement model System of governance mechanisms När målen satts kan en ”operating modell” väljas och en ”foundation for execution” fastslås och ger då gott stöd för fortsatt integrations och arkitekturarbete. Observera att detta är affärsledningen som fastställer. Annars blir det oerhört svårt att genomföra förändringsarbetet. Foundation for execution Core business processes IT Infrastructure Källa: MIT Sloan Center for information systems and IMD

Hur kan detta göras praktiskt? Ett exempel från EA-arbete inom Stockholms läns landsting och inom regionssamarbete 3R (Stockholm, Västra götaland och Skåne).

Förvaltningen för IT-ramverket och dess uppdrag Råttbo av lösningar skapat av upphandlingsresultat Initierades hösten 2005 och etablerades under 2006 Införa en tydlig processbaserad hantering av strukturfrågor som finns och kommer att uppstå för vårdsystem inom SLL Tillhandahålla regelverk ( RRR = Regler, Riktlinjer och Rekommendationer) både för verksamhet och teknik som grund för normering och styrning av IT-stöd inom vården Bedriva aktiviteter för att stödja och skapa följsamhet till IT-ramverkets RRR Beskriva vilket uppdrag som fanns bakom praktikfallet. Beskriva vilka delar som inte fanns och vad som behövde skapas inom SLL. LOU upphandlingar stort problemområde som kan ge många arkitekturer och leverantörer.

EA-arbete inom SLL mappat till Zachman som stödjande ramverk Omfattning (kontextuell) Planerare Verksamhetsmodell (konceptuell) Ägare Tekniskmodell (fysisk) Konstruktör Implementation (realiserad) Bygg/Köp DATA Vad FUNKTION Hur NÄTVERK Var MÄNNISKOR Vilka TIDPUNKT När MOTIVATION Varför Systemmodell (logisk) Designer Vy Område Verksamhets- arkitektur Lösnings- arkitektur Använde Zachman som ramverk och den egna tolkningen om ansvarsgränser för att anpassa till aktuell organisation. Svårt både nationellt och regionalt att få “rätt” representation i verksamhetsdelar. Källa: http://www.zifa.com/

Förvaltarroller inom IT-ramverket EA-ledning Ramverksförvaltare Verksamhetsarkitekt Informatiker Teknik Teknisk arkitekt Ansvarig för plattformsfunktioner Integrations specialist Ansvarig utvecklingsmodeller IT-säkerhet Genomgång av de olika roller som finns inom arbetet med EA-ramverket.

IT-ramverket Den organisation som sattes upp för att förvalta IT-delen av ramverket. Motsvarande behövs för affärsdelen. Kritiskt att hantera både ”befintliga saker” = röda till höger om strecket i bilden Och ”skapandet av nya förmågor” Viktigt förklara vem bestä’ller vad och vem är leverantör av plattform m.m.

RRR Regel – Hårt skallkrav. Går ej att åsidosätta. Riktlinje – Mjukt skallkrav. Krävs dokumenterat beslut inom IT-ramverketsförvaltning för avvikelse. Rekommendation – Börkrav. Avvikelse dokumenteras och meddelas IT-ramverketsförvaltning RRR:er och dess styrande och normerande roll inom EA-ramverket. Avvikelser beslutas på olika nivå och kopplas till en åtgärdsplan och ett slutdatum då följsamhet skall vara uppnådd.

RRR:ernas roller Sammanfattar på översiktligt sätt vad som finns inom ett ramverk Sätter grunden för revisioner Kopplar sig till detaljer i anvisningar Ger möjlighet att långsiktigt målstyra Exempel (www.it-ramverket.sll.se ) RRR 3 All data valideras i mottagande delsystem. Syfte: Säkerställa att informationsutbyte sker på ett korrekt sätt. Inkonsistent data kan medföra feltolkning vid användning. Anvisning Validering av data i GVD-systemet RRR 5 All data lagras i fastställda lagringstjänster Syfte: Syftet med denna regel är att säkerställa skalfördelar med avseende på ekonomi, tillgänglighet och säkerhetskopiering. Anvisning Anvisning Lagring i GVD Plattforsmfunktionsbeskrivning GDBH Plattformsfunktionsbeskrivning GLY Exempel på RRR:er inom IT-ramverket. Förklara att ”one linern” får sitt exakta innehåll genom preciserande anvisningar

Arbetsformer Regelmöten 4 gånger per år Arkitekturgrupp möten 6 ggr/år Krav på aktivt deltagande ifrån projekt och förvaltningar Utskick av dokument i förväg för att få en bra dialog och återkoppling på mötet Vårdrelaterade projekt/förvaltningar ska hålla sig informerade om IT-ramverkets dokumentation Arkitekturgrupp möten 6 ggr/år Grupp med deltagande av alla parter som bedriver vårdrelaterade IT-aktiviteter Utbildning och informationsspridning Hur går arbetet till med att förankra och få genomlysning av EA-ramverkets regler m.m. till innan styrgruppen fastställer.

Granskningar – tillvägagångssätt för att uppnå följsamhet Strukturerade möten med hjälp av en upprättad checklista, mellan projekt/förvaltningar och representanter från EA-ramverkets förvaltargrupp I projekt bör detta ske inför beslutspunkter (BP) I systemförvaltningar bör det ske minst en gång per år, lämpligen före beslut av förvaltningsplan Hur kan följsamhet kontrolleras och förbättras över tiden. Protokoll och avvikelser samt planer för avveckling av avvikelser.

Informationsspridning IT-ramverkets web 2007-10-25 Informationsspridning IT-ramverkets web Information måste spridas till ALLA intressenter och vara aktuell. Källa: www.it-ramverket.sll.se 20

Fortsättning följer… Vad händer vidare inom vården? VIT-boken och dess delar.

Arkitektur från verksamhet till IT Vården i Sverige i ett EA-perspektiv Alla delar skall samverka för att få en lösning som Verksamheten accepteras, sitter ihop Informatik och innehållsmässigt samt har en Teknisk struktur som är skalbar och tillräckligt flexibel.

Möte med vård och omsorg Från V och I till T Flera vård och omsorgsgivare kan vara inblandade! Hälsoärende ”brukarens process” Möte med vård och omsorg Realiseras av vård- och omsorgsprocesser hos vård- och omsorgsgivare Scenario 1 Mammografi 10-14 bra scenarier för vård och omsorg medborgare – olika ingångar / behov personal – vårdsituationer vård – inom och mellan vårdgivare omsorg – inom och mellan omsorgsgivare gränsöverskridande vård och omsorg (fallet Esther?) samverkan Försäkringskassan EU vård mfl Operativ modell Process styrd uppbyggnad av hur IT-stöd skall realiseras.

Helhetsbild Kund- och personalingångar Socialstyrelsen Försäkringskassan Skatteverket Arbetsförmedlingen Apotek NEF VIF Helhetsbild Kund- och personalingångar Växel Riks lokalt & personligt VIK Vårdgivare A Internet tjänster Administration & vårdsystem ”Riksingångar” Telefon Fråga.se Internet tjänster Medborgare VpW NPÖ HSA NPÖ Besök & uppsökande TIS SITHS SVR.se NARRR TIS NARRR RIV HSA RIV NOD NPÖ SITHS Vårdgivare B TIS Telefon Internet tjänster HSA Administration & vårdsystem Telefon 1177 HSA NPÖ SITHS Besök & uppsökande Handbok Internet tjänster Personal TIS NOD NARRR HSA VpW - P RIV Mycket stort antal standarder (endast svenska preciseringar) måste finnas och samverka för att olika lösning och leverantörer skall kunna samarbete och tillsammans utgöra ett fungerade IT-stöd för vården i Sverige. TIS NPÖ SITHS HSA Kommun C RGS webb TIS NARRR Internet tjänster SITHS Administration & omsorgssytem Telefon Rådgivnings- stöd Kunskapsbas HSA SITHS Besök & uppsökande TIS Handbok HSA RGS SITHS Kan använda samma verktyg

När verkligheten är svårare än vad böckerna säger! Vilka lärdomar skall vi lyfta fram för att ge stöd för kommande aktriveiter?

Erfarenheter Stöd från ledning absolut kritiskt EA-arbete tar lång tid och kräver ledningens övertygelse och stöd Kommunikation och skriftlig dokumentation central för efterlevnad uppföljning och kontroll Intern kompetens måste hanteras omedelbart Integration är centralt för att lyckas Både leverantörer och Landstinget är ovan att upphandla tjänstebaserat Viktigt skilja på hantering av avtal och informatik/teknik Summering av de olika erfarenheter som kommit fram under de första åren av EA arbete inom vårdsektorn.

Erfarenheter Generiska och standardiserade lösningar viktiga för TCO Standarder löser INTE hela kakan Stora system innehåller ofantliga mängder detaljer vid teknisk implementation/integration Moderna metoder och prototyping viktig hjälpmedel för att få användardeltagande och feedback Anpassning köpta produkter kan vara mycket svår och kostsam Summering av de olika erfarenheter som kommit fram under de första åren av EA arbete inom vårdsektorn.

Läsvärt inom EA och SOA Service Orient or Be Doomed, ISBN 0-471-76858-8 Enterprise Architecture as Strategy, ISBN 978-1-59139-839-4 Enterprise Integration Patterns, ISBN 0-321-20068-3 Service-Oriented Modeling ISBN 978-0-470-14111-3 Intressant bok med diskussion om hur en affär kan bete sig för att tillgodogöra sig SOA m.fl. nya idéer. Viktig grund för resonemang om hur en organisation kan sättas upp och skapa strategisk målbilder som kan kommuniceras och vara stöd till strategiskt förändringsarbete. Mönster (miljöoberoende) för integration och uppbyggnad av heterogen IT-miljöer. Process beskrivning för hur arbete med affärsprovesser kan bedrivas för att ge bra underlag för SOA implementationer av IT-stöd.

Frågor? Frågestund….