Det Digitale Danmark Indlægsholder: Jes Rude Dragsted, ATP Kristian Vengsgaard, SKAT Michael Strand, Deloitte Dato: 2. April 2009
Agenda Introduktion EA erfaringer fra ATP EA erfaringer fra SKAT Diskussion Opsummering og konklusion 2
Mange kloge mennesker har defineret EA for os Enterprise Architecture is the set of descriptive representations (i.e. models) that are relevant for describing an Enterprise such that it can be produced to management s requirements (quality) and maintained over the period of its useful life (change) John Zachman Gartner: Predicts 2009 Enterprise Architecture programs at Risk - Through year-end 2009, 55% of EA programs will be stopped due to economic pressures and the lack of perceived value - By 2012, 80% of organizations will have abandoned the use of standard EA frameworks 3
I dag skal vi høre hvad EA er for ATP og SKAT SKAT og ATP har arbejdet i flere år med EA og i dag vil de dele ud af deres erfaringer om hvad EA er i praksis; deres opture og nedture Jes Rude Dragsted, Chef for IT Design & Arkitektur, ATP Kristian Vengsgaard, Projektchef, Systemmodernisering, SKAT 4
Næsten alle danskere er kunder i ATP Koncernen 4,5 millioner danskere kommer i berøring med ATP Koncernens produkter. De samlede produkter sikrer vores kunder en grundlæggende økonomisk tryghed under og efter deres arbejdsliv. 5
ATP Koncernens opgaver Lovregulerede opgaver Markedsbaserede opgaver pension uddannelse Pension ATP Sikring AER Pension og sikring PensionDanmark sygdom barsel SP AES JØP (Unit Link) SUPP FerieKonto DA-Barsel ferie indkomst LD LG Kompetencefonde Barsel.dk Sundhedsordning 6
Forretningsmæssig særkende Lave enhedsomkostninger Stordriftsfordele gennem standardiserede processer og datamængder Enkelthed og effektivitet i processer Tung batch organisation Burde have været tænkt bedre ind i arkitekturen fra starten 7
Enterprise Arkitektur i ATP Enterprise Arkitektur defineres i ATP som det tværgående og kontinuerlige Enterprise Arkitekturen er besluttet i ledelsen. Strategiske statements (vision og pejlemærker). Arkitekturprincipper. Enterprise Arkitektur rammeværk. Arkitekturstyregruppe på tværs af forretning og IT 8
Enterprise Arkitektur i en kontekst Justeres 2009 Justeres 2009 Strategi fokus Forretningsstrategi IT-strategi Enterprise fokus Enterprise Arkitektur (EA) Etablering af nyt forretningsfundament og teknisk infrastruktur Afsluttes 2010 Forretningsmuligheder og -trends Definition af overordnede principper, modeller og retningslinjer, der skal sikre, at funktionelle og tekniske løsninger understøtter ATPs Forretnings- og IT- Strategi. Transition plan Teknologiske muligheder og trends Projekt- og løsnings fokus Lø sningsportefølje Justeres vha. en releasestruktur Tværgående teknisk fokus Teknisk Infrastruktur Justering og konsolidering 9
ATP s EA framework Strategi Proces Løsning Information Interessent Teknologi Konceptuelt niveau Enterprise Arkitektur principper Forretningsprocesser Projektstyringsmodel Udviklingsmodel Driftsprocesser Funktionelle domæner Ydelseskatalog Begrebsmodel Interessentmodel Infrastruktur domæner Logisk niveau Løsnings arkitekturdrivere Forretnings workflows Use Cases Løsnings- portefølje Servicekatalog Informationsmodel Logiske datamodeller ATP s organisations model Teknologi modeller Operationelt niveau Forretningsregler IT- Workflows Komponentmodeller Portlet specifikation Output specifikation Fysiske datamodeller Kunder Medarbejdere Leverandører Sikkerhedsmodel Teknisk Infrastruktur modeller Implementeringsniveau? Jobafvikling Programmer Database tabeller Sikkerhedsprofiler Tekniske Implementerings modeller 10
ATP s Dokumentationsframework Strategi Proces Funktiona- Information Løsning litet Teknologi Konceptuelt niveau Forretningsstrategi IT-strategi EA EA arkitektur Interessentmodel Ordningsmønstre Proceskatalog Niveau 1 og 2 Forretningsdomæner Niveau 1 og og 2 Begrebsmodel Ordningsoverblik Ordningens processer Ordningsløsning Logisk niveau EA EA principper Non-funktionelle krav Forretningsflow Løsningsflow IT IT systemlandskab Løsningsdesign Brevspecifikationer Informationsmodeller Ordningens forretningsflow og og løsningsflow Årets gang Brevoversigt Operationelt niveau Designprincipper Instrukser Funktionalitetsspecifikationer Logiske datamodeller Ordningens breve Portal layout Implementeringsniveau Rød skrift = Forretningsartefakter Sort skrift = IT-artefakter 11
ATP s 10 EA principper - status 1. Én koncern funktionalitet udvikles én gang ATP vil udvikle funktionalitet én gang og bruge den mange gange. Funktionalitet skal således anvendes på tværs af ydelser, ordninger og støttefunktioner i form af løsninger. 2. Optimering af processer ATP vil forenkle, IT-understøtte og automatisere processer - ikke bare kerneprocesser, men også støtte-, udviklings- og ITdriftsprocesser. 3. Portefølje fokus Løsninger, systemer og infrastruktur betragtes som enhver anden investeringsportefølje, der skal vurderes og plejes. 4. Processernes strategiske betydning betinger implementering Processer opdeles i tre kategorier: stor, medium og lille strategisk betydning. For alle kategorier gælder arkitektur-retningslinjer og -anbefalinger for implementeringen og jo større strategisk betydning, des strengere er disse. 5. Formalisering af information Oprettelse og vedligeholdelse af forretningsmæssige begreber og deres relationer til hinanden sker kun ét sted Informationsmodellen. nemlig i 6. Sikkerhed Eksekvere sikkerheds procedurer i henhold til identificerede risici balanceret mod forretnings risici og omkostninger. 7. Løs kobling ATP ønsker IT-løsninger bygget efter princippet om løs kobling. Det betyder, at afhængigheder mellem ellers integrerede dele af en IT-løsning, skal fjernes mest muligt. 8. Robusthed IT-løsninger - og dermed bagvedliggende systemer og infrastruktur - skal være robuste og stabile. 9. Skalerbarhed De enkelte elementer, som indgår i ATP s løsninger og infrastruktur, skal være skalerbare, således at kapaciteten kan op- og nedjusteres i takt med forandrede forretningsmæssige som tekniske behov. 12 10. Arkitektur- og Metodefokus Der skal i ATP arbejdes metodisk efter de retningslinjer, der udstikkes bl.a. i Enterprise Arkitekturen, Kvalitetssikring, Governance, Udviklingsmodellen og Design principperne. Dette gælder både internt og i samarbejde med eksterne leverandører.
ATP s forretningsdomæne Kommunikation Ekstern kommunikation Call Center Portaler Dok. håndtering & Journal Kerneforretning Kerne 1 UnitLink Ind-/Udbetaling Kerne 2 Fonds Interessent Masterdata & Analyse Data Warehouse Økonomistyring Roadmap for hvert domæne skal udarbejdes som en del af forretningsstrategien i 2009-3-5 års sigte Workflow Infrastruktur Sikkerhed 13
Domæne landskab ved opstart 80-90 % af sagsbehandling foregår via portal området Ekstern kommunikation Portaler Call Center Workflow workflow styrer alle end to end processer Ind-/Udbetaling Dok. håndtering & Journal Kerne 1 Al kommunikation mellem domæner 100 % synkront SOA enablet. UnitLink Kerne 2 Rene domæner uden redundans i de respektive områder. Fonds Interessent Økonomistyring Infrastruktur Data Warehouse 14
Domæne landskab i dag 20-30 % af sagsbehandling foregår via portal området Ekstern kommunikation Portaler Workflow Call Center Workflow workflow ad hoc implementeret som place holder for notifikationer Workflow Ind-/Udbetaling Interessent Workflow Dok. håndtering & Journal Kerne 1 Al kommunikation mellem domæner SOA lignende asynkront enablet enten med ny eller gammel teknologi UnitLink Interessent Kerne 2 Interessent Lidt redundans etableret i diverse domæner for at tilsikre leverancesikkerhed samt skalérbarhed. Fonds Interessent Økonomistyring Infrastruktur Data Warehouse 15
Learning Points Enterprise arkitektur er et fælles anliggende mellem IT og forretningen. Fokuser på standardisering og genbrug. Forstå forretningen og implementer arkitekturen herefter. Enkelthed i arkitekturen hvor muligt. Gør dine egne erfaringer med SOA. Enterprise Arkitektur er ikke statisk. Arkitekterne skal deltage i projektarbejdet. Udarbejd operationelle principper der kan anvendes af projekterne og følg op! Start implementeringen småt. 16
EA i SKAT Retrospektiv Hvorfor EA? Kompleks systemportefølje Stor leverandørafhængighed Nye opgaver Krav om øget effektivitet 17
EA i SKAT Retrospektiv Hvad forstod vi med EA? EA og SOA Alle fire vinkler: Modellering Planlægning hånd i hånd Standard og regler Organisering 18
EA i SKAT Retrospektiv Modellering ydelseskatalog 19
EA i SKAT Retrospektiv Modellering - Specifikationsmetode Modelleringen skal beskrive de optimale forretningsgange på forretnings-niveau, dvs. modellerne skal være ideelle uden begrænsninger afledt af it-systemer, aktuel organisationsstruktur eller økonomi. (SKATs forretningsmodelleringsvejledning) 20
EA i SKAT Retrospektiv Modellering, Planlægning & Standarder og regler Servicebeskrivelse (WDSL) Procesmodel (BPMN) Use Case (UML) 21 Vejledning skal følges System architect Giver en rækker klare fordele: Begrebsmodel (UML) Leverandøren kan se i hvilken proces deres løsning skal indgå Forretningen kan forklare sig selv Forretningen udfordres
EA i SKAT Retrospektiv Organisering Professionel projektorganisation SAS kontor LAS kontor SIP Projektorganisering Organiser projektet med innovation for øje = modsætninger mødes Konflikt er basis for forandring Medarbejdere skal være villige IT-arkitekter til at lære forretning og forretningsfolk til at lære præmisser for IT 22
EA i SKAT Retrospektiv Hvordan planlagde vi opgaven med at indføre EA? 3 faser: 1. IP, Portal & TSE Under udvikling 2.1 DMR &EKKO Under udvikling 2.2 EFI Under udvikling 3. Fase 3 I modning Sideløbende procesudvikling 23
EA i SKAT Retrospektiv Hvad har vi opnået? Og mere vigtigt (og irriterende). Hvad har vi ikke opnået? - Fase 1 næsten i mål - Fase 2.1 forfra - Fase 2.2 entusiastisk leverandør - E-indkomst - Metodekendskab - Afstand til forretningen - Detaljer er ikke detaljer 24
EA i SKAT Retrospektiv Hvad har vores største udfordringer og overraskelser på rejsen? Lad os bygge et hus Hvilket maksime fortolker vi med? Det skal være muligt Infrastruktur & forretningsapplikation Samspillet mellem flere leverandører 25
EA i SKAT Retrospektiv Hvad har vores største udfordringer og overraskelser på rejsen? Test af infrastruktur Forretningens forståelse Hvem ejer hvad? Portal Læring: Implementering tidligt Elefanten i små bidder Den ingen vil have Revurder strategien - men hold fast EA = Samarbejde! Platforms komponent Applikation 26
Så hvad kan vi uddrage fra ATP s og SKAT s erfaringer 27 2009 Deloitte Touche Tohmatsu
Fælles læringspunkter ATP Enterprise arkitektur er et fælles anliggende mellem IT og forretningen Fokuser på standardisering og genbrug Forstå forretningen og implementer arkitekturen herefter Enkelthed i arkitekturen hvor muligt SKAT Implementering tidligt! Elefanten i små bidder Revurder strategien - men hold fast EA = Samarbejde! Gør dine egne erfaringer med SOA Enterprise Arkitektur er ikke statisk Arkitekterne skal deltage i projektarbejdet Udarbejd operationelle principper der kan anvendes af projekterne og følg op! Start implementeringen småt 28
Vores diskussion under forberedelse til dette indlæg 1. Hvorfor lave EA når det er så svært? 2. Hvorfor ikke bare starte i et hjørne og så arbejde sig derudaf, for verdenen ændrer sig jo alligevel hele tiden? 3. Hvornår bliver man færdig med EA? Og hvornår er EA en succes (kan det måles)? 4. Er EA et højkonjunktur fænomen, eller har det også sin berettigelse i lav-konjunktur? 5. Når det nu hedder EA hvorfor ender det så altid at blive forankret i It-afdelingen? 6. Hvad er prisen for en service i en EA- og SOA verden? 29
Plenum: Diskussion 30 2009 Deloitte Touche Tohmatsu
Hvad har vi lært. EA er i virkeligheden mange ting Modellering Konceptuelle, logiske og fysiske modeller Værktøjsorienteret Forskellige arkitektur synsvinkler (Zachman) (applikationer, processer, data, infrastruktur etc.) Når vi har fået modelleret kan vi bygge den rigtige arkitektur til vores virksomhed Store mængder af information der kan give overblik skabes Risiko for elfenbenstårn (architecture anti-pattern) hvor informationen kun reflekterer virkeligheden et øjeblik Planlægning As-Is modeller To-Be modeller Gap-analyser Transitionsplaner Når vi ved hvor vi er og hvor vi skal hen så kan vi planlægge rejsen til den gode arkitektur Retning og tilgang til forandringsproces opnås Hvis der ikke er styring, økonomi, og forretningens involvering kan det gå galt Standarder og Regler Arkitekturprincipper Arkitektur politikker Standarder Specifikationer Architecture patterns Vi definerer et præcist sæt principper, politiker m.m. og styrer på at alle følger dem og på den måde får vi en god arkitektur Regler og politiker der sikrer at vi alle arbejder mod det samme ensrettede mål Meget kæp og meget lidt gulerod Organisation Arkitekturkontor Organisationsstruktur Kompetenceopbygning Tæt på interessenterne Vi investerer i vores ressourcer for at sikre at de har de nødvendige kompetencer til at bygge en god arkitektur Samme forståelse af målene og få implementeringsfejl Hvis der ikke er tæt koordinering til forretningen bliver det let en stræben efter den perfekte arkitektur 31