PROJEKTPLAN. Enterprise architecture (EA) En verksamhetsövergripande arkitektur

Transkript

1 Sid 1 PROJEKTPLAN Enterprise architecture (EA) En verksamhetsövergripande arkitektur webbadress namn Enterprise architecture Fastställt av Dokumentansvarig Dokumentidentitet ea_pplan.pdf Version 1.0 Datum Status Fastställd

2 Sid 2 Innehållsförteckning 1 Direktivet Inledning Referenser Versionshistorik Beskrivning Omfattning Målprioritering Förväntat resultat Tidplan Kostnad Avslutskriterier Avvikelser Avgränsning Beroenden Organisation Beskrivning av ansvar Resurser Uppdragsgivare ledare Personresurser granskare Genomförande Dokumentationsform och struktur Utred lämpliga ramverk Kartläggning och dokumentation Identifiera problemområden Sätt IT Governance på plats Begreppsmodell Enterprise Architecture Inledning Verksamhetsarkitektur Applikationsarkitektur Life cycle management (LCM) Informationsarkitektur Teknisk arkitektur Leveranser Milstolpeplan Uppföljning/ rapportering Avslut av projektet Påverkan på/av projektet... 14

3 Sid 3 7 Samverkan Kommunikation Inom projektet Kommunikationsplan Kvalitetsplan Risk och sårbarhetsanalys Definitioner och förkortningar... 15

4 Sid 4 1 Direktivet 1.1 Inledning et är ett delprojekt som utförs inom ramen för huvudprojektet IT-strategiska insatser Se ref. [1]. Som stöd i arbetet ska standardiserade ramverk och metoder att användas. 1.2 Referenser [1] Huvudprojekt, [2] Aktivitetslista, [3] Begrepps definitioner, f21caa87497e/page/0693ab26-7a e-5d60b Versionshistorik Versioner Datum Författare Kommentar Första version Fortsatt arbete, viss omstrukturering Omarbetning efter kommentarer Kommenterat/ nya textförslag Uppdatering efter kommentarer Uppdateringar efter kommentarer Uppdateringar efter kommentarer 2 Beskrivning 2.1 Omfattning Vid universitetet finns idag ett antal övergripande it-system, ständigt närvarande med information, processer och integration i realtid. För att kunna bygga, styra och kontrollera dessa lösningar, och framtida, krävs att arkitekturen är väl dokumenterad och beskriven ur flera olika aspekter. Med hjälp av konceptet Enterprise Architecture (EA), som är en metod för att beskriva är och bör läge, ska vi skapa helhetssyn och styra verksamhets- och itutvecklingen. Vi behöver göra en analys och dokumentera vår nuvarande it-miljö samt skapa en bild av en framtida it-miljö för att identifiera hur it-miljön bäst kan stödjas av arkitekturen.

5 Sid 5 Visionen för Enterprise Architecture är att definiera de primära mål och syften som skall gälla i framtiden. Enterprise Architecture är processen att utforma verksamheten inte att utforma IT system. Enterprise Architecture är processen att modellera och dokumentera alla aspekter av en organisation för att säkerställa att processer, applikationer, information, data, teknologi, platser, människor, händelser och tidsplaner är anpassade till verksamhetens mål och syften. Utvecklingen av arkitekturen måste vara förankrad i verksamheten, det är en förutsättning för att EA blir framgångsrikt: Copyright 2009 The Open Group Figur 1 Konceptuell bild över utvecklingsprocessen för arkitekturen.

6 Sid Målprioritering Målet är att vi vid UmU använder en Enterprise Architecture och att alla enheter investerar i och nyttjar en delmängd av denna. Ett av de primära målen är att underlätta arbetet vid förändringar. Genom en kontrollerad arkitektur skall de behov som verksamheten har uppfyllas på ett effektivt sätt. Utvecklingsprojekten ska få stöd i en arkitekturplan bestående av strategiska planer, riktlinjer, referens modeller etc. Detta ska ge hög kvalitet på informationen och möjliggöra snabba verksamhetsförändringar. Ger oss ett bättre beslutsunderlag. 2.3 Förväntat resultat Vi har enhetliga och överenskomna processer och begrepp inom verksamheten. Vi har etablerat en stödstruktur en arkitektgrupp- för arkitektarbetet. Vi har skapat en förståelse för arkitekturfrågor i verksamheten. Vi har skapat ett strukturerat sätt att beskriva vad verksamheten gör Vi kan ta ansvar för att vi hanterar vår information, arkitektur och systemutveckling på ett optimalt sätt. Vi har en tydlig bild över nuläge och önskat läge när det gäller hur system och applikationer relaterar och interagerar med varandra, dess gränssnitt och kopplingar till verksamheten och dess processer. Vi har en tydlig beskrivning över nuläge och önskat läge av den tekniska systemarkitekturen. Vi har tydliga riktlinjer, regler och mallar som ska användas som stöd för att integrera/ändra eller att ta bort processer, system eller applikationer i arkitekturen. Resultatet ger oss stöd att skapa lämpliga organisatoriska strukturer och roller för att underlätta beslutsfattandet. att prioritera och hantera investeringar och resurser som avsätts till tjänster och projekt. att skapa mål, mått och kontroller för att förvalta resultatet av tjänsterna och investeringarna. i vårt arbete med it-governance ramverk med avtal, modeller, processer och verktyg. 2.4 Tidplan start: avslut:

7 Sid 7 Figur 2 Grov tidplan Detaljerade aktivitetsplaner kommer att tas fram under projektets gång. 2.5 Kostnad Kostnaden som ska finansieras inom ramen för detta projekt har ett maxtak på 955 tkr för år 2010 och 1195 tkr för år Övriga kostnader som uppstår inom ramen för detta projekt finansieras inom ramen för IT-enhetens budget och ramen för enheternas verksamhetsbudgetar för de enheter som berörs. 2.6 Avslutskriterier Intentionerna med huvudprojektet är genomförda inom ramarna för beslutad budget. 2.7 Avvikelser planen kan komma att revideras utifrån hur behov, teknik och tillgängliga resurser förändras vilket kan ge en påverkan på planerade aktiviteter inom denna plan. Uppdragsgivaren skall informeras om alla händelser som kan komma att påverka projektets möjlighet att leverera planerat resultat.

8 Sid Avgränsning Umdac driver projektet ITIL på Umdac. Direktivet från uppdragsgivaren är att implementera ITIL på Umdac med de prioriterade processerna: Incident Management, Problem Management och Request Fulfilment i första hand. Change Management och Event Management i andra hand samt övriga ITIL-processer i tredje hand. Förvaltningschefen har startat ett kvalitetsarbete kring förvaltningens tjänsteutbud och processer. Dessa projekt pågår parallellt med vårt och vi ska i vårt arbete följa utvecklingen av detta och bidra samt förhålla oss till resultaten. 2.9 Beroenden Två separat aktiviteter, projektportfölj och applikationsportfölj, genomförs och är kopplade till detta delprojekt. Målet med applikationsportföljen är att identifiera behovet av en strategi, värdet av portföljen samt vilket värde varje applikation levererar. Det långsiktiga målet med projektportfölj aktiviteten är att införa projektportföljstyrning. Vi ska säkerställa att våra resurser används till att genomföra de projekt som skapar mest mervärde. 3 Organisation 3.1 Beskrivning av ansvar Enligt projektmodell för Umeå universitet. 3.2 Resurser Uppdragsgivare. Säkerställer att det finns resurser till projektet. Fastställer projektets syfte och inriktning samt att den följs ledare, it-arkitekt ansvarar för kartläggning och dokumentation av den tekniska systemarkitekturen samt framtagande av principer och riktlinjer för önskat läge. ansvarar för att det tas fram en it-styrningsmodell (IT-Governance struktur) Personresurser Under projekttiden kommer resurser från it-enheten och anställda inom UmU komma att knytas till projektet för att medverka till att skapa projektets resultat. Även externa resurser kommer vid behov att köpas in. Specifikt berörs processägare, systemägare, it-ansvariga, verksamhets- och it-arkitekter. Följande resurser kommer att bli inblandade i projektet

9 Sid 9 Maria Valtersson Mattias Wallmark Konsultstöd Utförarenheten granskare Per Björkegren, SWEAN 4 Genomförande Arbetet kommer att bestå av en mängd aktiviteter som delvis kommer göras parallellt t.ex. dokumentationsarbete kring nuläget tas fram parallellt med framtagande av referensmodeller etc. Arbetet kommer även att vara av iterativ karaktär så att en helhet snabbt kan byggas upp och därefter kan detaljer mer och mer utvecklas. Det är viktigt att hela tiden ha ett helhetsperspektiv och fokusera på resultatet och inte fastna i modeller och detaljer. Det är också viktigt att tänka igenom varför dokument tas fram, en behovsanalysgörs för varje artefakt som beskriver vem som har behovet, för vilket ändamål, hur ökas effektiviteten, säkerheten etc. En genomgripande och viktig del i projektet är också kommunikationen med verksamheten, se vidare Dokumentationsform och struktur Initialt så skall det fastställas i vilken form dokumentationen skall tas fram och i vilken struktur. Vilka verktyg och vilka format skall användas? En grundtanke är att så långt som det går använda sig att generella verktyg som t.ex. Visio och endast nyttja specialverktyg, t.ex. IBM Rational Architect, när behov uppstår. 4.2 Utred lämpliga ramverk Utred om det finns ramverk eller delar av ramverk som kan vara lämpliga när en Enterprise Architecture skall byggas upp. Ett exempel kan vara Zachman Framework, TOGAF. Ett ramverk kan ge oss: En enhetlig metod för hur en arkitektur skall beskrivas Verktyg och gemensamma termer. Rekommenderade standarder Dock skall inte alltför stor kraft läggas på detta utan det skall ge oss en inblick och idéer för det framtida arbetet.

10 Sid 10 Copyright 2009 The Open Group Figur 3 Utvecklingsprocessen för arkitekturen 4.3 Kartläggning och dokumentation Initialt skall nuläget beskrivas och dokumenteras. 1. Ta del av övergripande processkarta över de processer som verksamheten använder idag. 2. Tag fram en objektkarta över de identifierade objekten (i detta fallet dom olika itsystemen) som finns i arkitekturen. 3. Dokumentera objektmodellen ur ett verksamhetsperspektiv. Objekten i detta fall är de system eller applikationer som används av verksamheten. Inbördes beroenden och samverkan ur ett verksamhetsperspektiv skall beskrivas. Informationsutbytet mellan olika verksamhetsområden ska beskrivas. 4. Dokumentera objektmodellen ur ett tekniskt perspektiv. Objekten i detta fall är de system eller applikationer som används direkt eller indirekt av verksamheten. Här skall beroenden och samband beskrivs ur ett tekniskt perspektiv. Informationsutbytet

11 Sid 11 mellan dessa system och applikationer ska beskrivas. Beskrivningen skall underlätta i det fallet då objekt eller system skall bytas ut. 5. Tag fram modell som bl.a. knyter ihop verksamhet och tekniskarkitektur. 4.4 Identifiera problemområden Särskilda problemområden identifieras och plan utarbetas för att hantera dessa. I dagsläget är följande problemområden prioriterade: Infrastruktur och identitetshantering Koncernkatalogen Brist på dokumentation 4.5 Sätt IT Governance på plats Ta fram en Governance struktur, ansvar, roller och forum. Bestäm modell för it.verksamheten. Fastslå principer för it-styrningen. Arbeta igenom processer, mätetal och ta kontroll över projekten. Figur 4 Övergripande bild över en arbetshypotes för IT-Governance struktur

12 Sid Begreppsmodell Ta fram en gemensam begreppskatalog att använda. Definiera data och information så att vi kan vara säkra på att namnen är konsekventa. Vilka begrepp finns? Hur beskrivs de? Hur hänger de ihop? 4.6 Enterprise Architecture Inledning Följande aspekter skall adresseras. Verksamhetsarkitektur o Processer och verksamhetsnära begrepp Applikationsarkitektur o Applikationsstruktur och kopplingar Informationsarkitektur o Informationsmodeller etc. Teknisk arkitektur Logisk/fysisk system arkitektur Verksamhetsarkitektur et kommen att använda befintlig dokumentation och ta del av resultatet från pågående projekt inom förvaltningen Applikationsarkitektur Beskrivning av den önskade applikationsstrukturen dess interaktion med varandra och dess användare. Fokusera på data som konsumeras och produceras mellan applikationerna. Mindre fokus på intern struktur. Här kan mycket återanvändas från Life cycle management (LCM) Identifiera vilka mål vi kan sätta med de resurser vi har och hur vi med tiden ska öka ambitionen. Titta på Application lifecycle management (ALM) och Infrastructure lifecycle management (ILM) och gör ett urval. Identifiera applikationsområden Identifiera nyckelprocesser per område Identifiera input och output En del av detta arbete kommer att tas fram i aktiviteten applikationsportfölj, Se vidare 2.9.

13 Sid Informationsarkitektur Beskriv och kartlägg var och hur informationen lagras och återanvänds av verksamheten och dess system/applikationer. Ta fram sambanden mellan process/system och informationsgrupper. Informationen skall beskrivas: Konceptuellt - alla verksamhetsbegrepp. Logiskt Logik och hur entiteterna relaterar till varandra. Fysiskt Hur datalagringen är realiserad för en viss funktion. I samband med detta så definieras en informationsstrategi: Data Governance, organisera och skapa rutiner, struktur, roller och ansvar för att få en effektiv hantering av informationstillgångarna. Mät värdet och klassificera informationen, inkluderar sekretess, integritet, tillgänglighet, överensstämmelse, pålitlighet och effektivitet. Val av arkitekturer för lagring av information där även informationssäkerhet är med som parameter Teknisk arkitektur Den tekniska arkitekturen skall innehålla mjukvara och hårdvara som behövs för att stödja utveckling av verksamheten, data och applikationer. Detta inkluderar IT infrastruktur, middleware, nätverk, kommunikation, processer och standarder Nuläge Enligt dokumentation i Målbild Styrs av EA Vision Målbilden skall innehålla: Referensmodell bestående av konceptuell arkitektur och logisk arkitektur Fysiskt arkitektur Säkerhet o Informationssäkerhet o Datasäkerhet o Identitetshantering o Autentisering, auktorisering Utarbeta direktiv till projekt och tjänsteleverantörer. Principer, riktlinjer (t.ex. för integration av nya applikationer) checklistor, mallar, exempel

14 Sid Leveranser Kommer att definieras i detalj under projektets gång, Följande levereras från projektet: Dokumentation över nuläge. Arkitekturplan inklusive referensmodell för önskat läge. Informationsmodell Nödvändiga riktlinjer, regler och mallar som kan användas som stöd för att integrera/ändra eller att ta bort processer, system eller applikationer i arkitekturen. 5 Milstolpeplan BP Beskrivning Datum MS1 Dokumentationsform och struktur, utredning ramverk samt begreppsmodell MS2 Identifikation problemområden MS3 Kartläggning och dokumentation MS4 Utkast EA version MS5 Färdigställande EA version Uppföljning/ rapportering Rapportering sker till uppdragsgivaren kontinuerligt. Slutlig rapportering och uppföljning sker efter projektets slut. 5.2 Avslut av projektet et avslutas när uppdragsgivaren anser att målen i uppdraget är uppnådda inom ramen för beslutad budget. 6 Påverkan på/av projektet Enligt beskrivning i huvudplanen. 7 Samverkan Enligt beskrivning i huvudplanen. 8 Kommunikation 8.1 Inom projektet Enligt beskrivning i huvudplanen. Även utanför projektet till övrig UmU organisation. 8.2 Kommunikationsplan Enligt beskrivning i huvudplanen.

15 Sid 15 9 Kvalitetsplan Enligt beskrivning i huvudplanen. 10 Risk och sårbarhetsanalys Följande risker är identifierade inom ramarna för projektet: Effekt Risk Beskrivning av risken Sannolikhet Riskfaktor prioritet Möjliga konsekvenser Föreslagna / genomförda åtgärder 1 Svårt att avgränsa uppgiften, lätta att falla in i detaljer eller omfatta för mycket. Ramverk etc. tas överhanden och målet missas Helheten missas och bara delmängd av den önskade arkitekturen tas fram 2 För lite resurser et kan inte genomföra sina mål. 3 För stort documentations arbete 4 Brist på enhetlig standardisering av EA 5 Arkitekturen blir inte kommunicerad i verksamheten i tillräcklig omfattning et kan inte genomföra sina mål Tappar fokus på målen Den skapade arkitekturen får ej genomslag I verksamheten. Framtagandet av arkitekturen tas fram genom korta iterationer och fokus är alltjämt på helheten. Nödvändiga resurser engageras. Prioriteringar måste göras löpande. Återigen är helhetsbilden det viktigaste. Diskutera fram de artefakter som ger mervärde och nytta för verksamteten. Mindre fokus på formen. Fokus på kommunikation i projektet. 11 Definitioner och förkortningar Se ref. [3]