En forretningsorienteret SOA modenhedsmodel med forsvaret som case.

Størrelse: px
Starte visningen fra side:

Download "En forretningsorienteret SOA modenhedsmodel med forsvaret som case."

Transkript

1 En forretningsorienteret SOA modenhedsmodel med forsvaret som case. Jess Alster Larsen Peter Krüger Cand.IT Speciale, EBUSS Vejleder: John Götze 3. januar 2008 IT - Universitet i København Rued Langaardsvej 6 DK-2300 København S

2 ii

3 Abstract This master thesis has been written as the final part of our studies for Master of Science in Information Technology in the E-business programme. Keywords: Business IT / enterprise architecture (EA) / service oriented architecture (SOA) / ecosystem / IT-strategy / Net-centric Warfare (NCW) / International Operations. We found it interesting that there are a number of models for measuring SOA maturity from a technical point of origin on the market from vendors as well as from organisations. We set out to identify the difficulties and differences in the existing models in order to create a more business oriented approach to measuring SOA maturity. We discussed the relation between EA and SOA and how they are intertwined. We introduced the term ecosystems in order to make this the focal point for our analysis. From the ecosystem line of thought we developed a SOA maturity model with six levels. The ecosystem approach provides us with a method to keep the core tasks up front during an initial SOA process. By focusing on the different ecosystems a company resides within, we are able to define tasks, process and data sources and use these to provide service needs and probable service models. Pilot testing and implementation follows the defined needs for service models. In order to validate our model we analysed the SOA maturity in a military unit from the Danish Defence. We analysed a single process within a small ecosystem. This demanded an exposition of the Danish Defence establishment and the missions and strategies herein. Our model levels 1 through 3 (strategic levels) has shown to be alright for focusing on the business purpose in the incipient SOA process. Levels 4 through 6 (tactical levels) have not been validated, as they are not fundamentally different from the existing models. iii

4 iv

5 Indhold Abstract ii Indhold iv Figurer viii 1 Indledning Læsere og forudsætninger Motivation og relevans Problemstilling Problemformulering Afgrænsning Valg af metode og struktur for specialet Praktisk læsevejledning Metode Bidrag Tak til v

6 vi Indhold 2 Eksisterende modeller og begreber Hvad er SOA? Definitioner af SOA Principperne bag SOA EA og SOA Hvad er Enterprise Arkitektur? EA i en SOA sammenhæng SOA og Økosystemer Motiver for et Økosystem Forudsætninger for SOA Økosystemer Modenhedsmodeller og SOA Udvalgte modenhedsmodeller Leverandør modenhedsmodeller Uafhængige modenhedsmodeller Delkonklusion Redegørelse for virksomheden forsvaret Forsvarets organisation Forsvarets overordnede organisation En enhed i internationale operationer Forsvarets IT-organisation Forsvarets mission, vision og strategi Forsvarskommandoens mission, vision og strategi IT-Strategier for Forsvaret EA i forsvaret

7 Indhold vii IT Governance i forsvaret SOA i forsvaret Delkonklusion Modelopbygning Betragtninger om SOA modenhedmodeller Udgangspunkt for vores SOA modenhedsmodel Definition af et SOA økosystem Overlappende Økosystemer Tværgående økosystemer Begreber i kontekst af økosystemer Metrikker for SOA Modenhed Udvikling af egen SOA modenhedsmodel Niveau 1 Definere Økosystemer Input og output Niveau 2 Processer Input og output Niveau 3 Servicemodeller Koordination af servicemodeller Definition af økosystemernes servicemodeller Input og output til servicemodeller Niveau 4 Initial arkitekturimplementering Input og Output Niveau 5 Arkitekturimplementering Niveau 6 Optimeret Økosystem med SOA

8 viii Indhold 4.10 Anvendelse af modenhedsmodellen Delkonklusion vores Modenhedsmodel Forsvaret modenhedsmodellen i anvendelse Niveau 1 økosystemet defineres Niveau 1 Input/Output til modenhedsvurdering Niveau 2 Proces beskrives Niveau 2 Input/Output til modenhedsvurdering Niveau 3 servicemodeller Niveau 3 Input/output til modenhedsvurdering Niveau 4 Initialfase Delkonklusion SOA modenhedsmodellen i forsvaret Konklusion Perspektivering Betydning for forsvarets fremtid i krigsførelsens kredsløb Bibliografi 163 Index 168 Liste over forkortelser 170

9 Figurer 1.1 Krigsførelsens kredsløb (egen produktion) Specialets opbygning Servicemodel for Økosystem Service Integration Maturity Model IBM scope of adoption Sonic Software Maturity Model BPtrends SOA Maturity Model BPtrends SOA Maturity Model and Process CBDI Maturity Model Streams FEA Segmentet Arkitekture FEA Reference Model FEA Segment Identification Ministerområdets organisation IKT ansvar i forsvaret Teknologisk begrebsapparat Aktitketurlandskabet Netværks Baserede Operationer i en SOA tankegang ix

10 x Figurer 4.1 Økosystemer XYZ (egen produktion) SOA Modenhedsmodel (egen produktion) Indlejrede økosystemer (egen produktion) Konfliktende økosystemer (egen produktion) Overlappende økosystemer (egen produktion) Eksempelvise spørgsmål til Niveau Eksempel på BPMN diagram (egen produktion) Økosystemer, datakilder og processer (egen produktion) Datakilder og processer sammenhæng (egen produktion) Eksempelvise spørgsmål til Niveau Økosystemet og dets servicemodeller (egen produktion) Definition af servicemodeller (egen produktion) Ensrettede servicemodeller (egen produktion) Eksempelvise spørgsmål til Niveau Eksempelvise spørgsmål til Niveau Eksempelvise spørgsmål til Niveau Fra modenhed til roadmap (egen produktion) Forsvaret i dets økosystemer (egen produktion) Opgavenedbrydning for INTOPS (egen produktion) Infanteridelingen i kamp under anvendelse af ildstøtte (egen produktion) BPMN diagram for proces Skudordre for ildstøtte under infanteridelingens kamp (AS-IS). Nummerering jf. eksemplet p. 138 (egen produktion) Sammenhæng mellem økosystemer, processer og datakilder for processen Skudordre (egen produktion)

11 Figurer xi 5.6 Hvordan virker et GPS system? (egen produktion) Arkitektur ved en service bus (TO-BE) (egen produktion).. 147

12 xii Figurer

13 1 Kapitel 1 Indledning Formålet med dette kapitel er at få defineret rammerne for dette speciale. Vi vil fremlægge motivation og problemstilling som ligger til grund for den efterfølgende analyse. Vi afgrænser opgaven og viser struktur og metode, samt specialets bidrag. 1.1 Læsere og forudsætninger Dette speciale er skrevet som afsluttende speciale på cand.it studiet, hvor begge skribenter er indskrevet på EBUSS linien. Læserne er primært vejleder og censor og subsidiært relevante personer i forsvarets IT-struktur, som arbejder med udvikling af Serviceorienteret Arkitektur (SOA). Det forventes at læseren har kendskab til forretnings-it, enterprise arkitektur, SOA, og IT-strategi. 1.2 Motivation og relevans I forbindelse med uddannelsen til cand.it er vi flere gange stødt på begrebet SOA uden dog til fulde at forstå de dybere implikationer ved begrebet. SOA bruges i flæng og ofte af sælgere, som vidunder løsningen for IT i fremtiden uden at specificere, hvordan det skal lykkes i praksis for den enkelte organisation at implementere det. I 2007 blev begrebet SOA kåret som Most confusing Acronym [1]. Der er altså nogen usikkerhed om, hvad

14 2 Kapitel 1. Indledning begrebet egentligt betyder. Det har givet en stor lyst til at komme i dybden med området og forsøge at afklare, hvad SOA kan gøre for en organisation. Begrebet service orienteret arkitektur bliver brugt til at dække alt fra anvendelse af enkelte webservices til forretningsmodellering. Det vil sige, at der kan være både high-level og low-level indgangsvinkler til SOA, hvor det generelle løfte er større fleksibilitet og omstillingsparathed(agilitet), se kapitel 2. For at kunne belyse SOA, uanset definition, stiller dette nogle krav til kompleksitet i den organisation, der undersøges. Da den ene af forfatterne har en mangeårig erfaring i forsvaret bag sig, vurderede vi, at forsvaret kunne være en interessant og kompleks virksomhed at undersøge SOA i. Dette understøttedes endvidere af, at man i staten og dermed også i forsvaret er i gang med at undersøge og implementere SOA. Forsvaret har mange opgaver, herunder krigsførelse i internationale operationer. Siden 11. september 2001 har forsvarets deltagelse i internationale operationer i bl.a. Irak og Afghanistan haft karakter af en stadigt stigende intensitet i den måde operationerne gennemføres på. Kampene er blevet stadigt hårdere så fokus har flyttet sig fra fredsbevarende til fredsskabende missioner, med regulære kamphandlinger til følge. Dette har medført et krav om stadig udvikling af den måde forsvaret deltager i operationerne på. I det historiske perspektiv er krigsførelse lige så gammelt som mennesket. Siden tidernes morgen har mennesket udkæmpet slag mellem hinanden helt tilbage fra stenaldermanden, der sloges med nabostammen om jagtrettigheder eller andet, op til massekrigene i det 20. århundrede og frem til nutidens fragmenterede kampplads med krig mod terrorisme. Krigshistorien kan man lære meget af, selv om det ofte anføres at Generals always prepare for the last war, dvs. man forbereder sig på den næste krig, ved at lære af den forrige 1. I krigshistorisk videnskab hvor man netop forsøger at uddrage en lære af fortidens krigshandlinger fremhæves ofte den sammenhæng, der er mellem teknologi, organisation og doktrin. Forklaringen på, hvad de første to er, giver sig selv, mens den sidste angiver den måde militære styrker fastlægger deres procedurer for, hvordan de indgår i en kamphandling. På lavere niveauer kaldes dette taktik, på højere niveauer kaldes det operationer eller strategi. De tre elementer indgår i Krigsførelsens kredsløb 2 (som kan ses i figur 1.1 (p. 3)), hvor udvikling i en af spidserne vil medføre at 1 Ordsprog, ukendt oprindelse, måske kinesisk. 2 Efter Oberstløjtnant K.V. Nielsen ved Hærens Officersskole[2]. Den opmærksomme læser af kilden vil bemærke, at K.V. s model indeholder en ydre cirkel, som omfatter samfundet, i form af ideologi, økonomiske udviklingsniveau og politiske strukturer. Disse indvirker selvfølgeligt på udviklingen i forsvaret, og i vore dage nok endnu mere. Men for simplicitetens skyld er det udeladt i indeværende motivation.

15 1.2. Motivation og relevans 3 Figur 1.1: Krigsførelsens kredsløb (egen produktion) de andre to spidser trækkes i den ene eller anden retning; de påvirker altså hinanden. I midten er uddannelse helt central for at kunne påvirke aktørerne til at ændre adfærd i takt med udvikling på alle tre områder. Som eksempler på udvikling, hvor et af de tre områder fik indflydelse på de andre, kan anføres: Det teknologiske område blev udviklet med opfindelsen og ibrugtagning af stigbøjlen i middelalderen. Dette medførte, at ridderen nu kunne kæmpe opsiddet til hest, idet han blev mere stabil i sadlen. Dette ændrede markant på organisation, hvor den relative kampkraft mellem fodfolk og ryttere ændrede sig. Doktrinen ændrede sig også, idet man med de hurtige og mobile flankeangreb, fik mulighed for hurtige tyngdeskift med pansrede og meget slagkraftige enheder. På det organisatoriske område så man Napoleons (gen-)indførelse af værnepligten, som lagde grunden for massehærene og de store verdenskrige. På doktrin området ses Hannibals nedkæmpelse af den overlegne romerske styrke i slaget ved Cannae (år 216 f.v.t.) ved at anvende en ny doktrin. Hannibal lod midten af sin formation (som set fra den

16 4 Kapitel 1. Indledning romerske side så ud til at være ens i hele bredden) være svagere og lod denne falde tilbage. Romerne troede de havde sejren sikkert i hus, indtil Hannibal lod sine flanker omslutte romerne fra begge sider og vandt slaget overlegent. Endnu et klassisk eksempel er Frankrigs opførelse af Maginot linien ved grænsen til Tyskland i mellemkrigstiden (mellem 1. og 2. Verdenskrig), som havde til formål at hindre en gentagelse af de altødelæggende og udmarvende skyttegravskrige under 1. Verdenskrig. Den teknologiske udvikling og ikke mindst den doktrinære og organisatoriske udvikling i den tyske hær i denne periode, gjorde dog Maginot-linien ganske overflødig. Tyskland var efter 1. Verdenskrig blevet tvunget til at afmoblisere og måtte maksimalt have et forsvar på mand. For at omgå denne beslutning uddannede man relativt set store mængder officerer og befalingsmænd, som kunne forestå uddannelse af de værnepligtsstyrker, som blev indkaldt senere. Af samme grund blev man organisatorisk nødt til at tænke nyt. Dette skete ved at opstille enhederne på en ny måde, hvilket medførte nye krav og muligheder for doktrinudviklingen. Teknologisk var mellemkrigstiden også nådig for tyskernes udvikling af deres forsvar. Nye motorer, metaller og meget andet underbyggede udviklingen på doktrin og organisation. Så da tyskerne angreb Frankrig den 10. maj 1940 anvendtes hurtige og meget mobile pansrede enheder, der kunne køre dybt og hurtigt udenom de franske styrker (gennem Belgien uden om Maginot-linien) og derved underminere og overflødiggøre det store franske projekt, hvilket jo som bekendt medførte den hastige franske kapitulation 3. Her var det altså en kombination af udvikling på alle tre områder, som førte til den overlegenhed tyskerne kunne mønstre. Når det ene element udvikler sig, bliver de andre nødt til at følge med. På den moderne kampplads, hvor kampen foregår mod fragmenterede styrker i et ikke nærmere defineret rum (modsat tidligere tiders frontlinier) som eksempelvis kampen mod terror bliver doktrinudviklingen nødt til at være langt fremme. De politisk-økonomiske indvirkninger på forsvaret og dets rolle i samfundet bliver selvfølgeligt også mere dominerende på udviklingen af alle elementer i krigsførelsens kredsløb. Under alle omstændigheder er kredsløbet godt til at beskrive forsvarets udvikling. Det er muligt at slå fast om der er en balance mellem de tre (fire inklusiv uddannelse) elementer og som 3 Og jf. ovenstående, er det jo interessant at notere sig, at de franske generaler åbenbart alligevel ikke havde lært noget af 1. Verdenskrig for der gjorde tyskerne jo det samme; de forsøgte at omgå de franske styrker ved til stadighed at bevæge sig mod Atlanterhavet gennem Belgien (von Schlieffen planen).

17 1.3. Problemstilling 5 krigshistorien har vist, har denne ubalance ved mange lejligheder været den afgørende faktor. Når man begynder at arbejde med begrebet SOA i forsvaret, bliver krigsførelsens kredsløb pludseligt interessant. Med SOA flyder grænserne mellem teknologi og organisation potentielt sammen. Takket være større fleksibilitet, kan man forestille sig situationer, hvor den eksisterende organisation bliver mere flydende og enheder sammensættes ad hoc til opgaven. Med SOA vil IT-systemer eventuelt give nye muligheder for løsningen af disse opgaver. Spørgsmålet er således om SOA i virkeligheden kan være med til at smelte teknologi og organisation sammen og derved påvirke doktrinen? I hvert fald er det en motiverende tanke at gå ind til opgaven med. Vil dette nye element i den teknologiske værkstøjskasse være med til endnu en gang at rykke på balancen i krigsførelsens kredsløb? Med baggrund i denne kobling mellem SOA og forsvaret, er det på tide at undersøge hvordan en sådan opgave kan løses. 1.3 Problemstilling For at få større indblik i SOA, hav vi i opstarten til dette speciale, gennemført adskillige eksplorative interviews 4 med nøglepersoner rundt omkring i det danske SOA miljø, med hovedvægten på folk fra det danske forsvar. Ud af dette kom en forståelse af, at udrulningen af SOA i Danmark ikke går så hurtigt, som man havde forventet. Dette er der flere forskellige grunde til, men en enkelt speciel grund blev fremhævet af stort set alle respondenter: Forretningen er ikke moden nok. 5 En forklaring på dette kan være, at man ikke altid har den samme opfattelse af, hvad SOA egentligt er. Der er potentiel stor forskel på hvad konsulenter og leverandører siger er muligt og nødvendigt, i forhold til hvad virksomheder forventer og reelt har brug for. Igen er forventningerne ikke de samme blandt IT-folk og folk fra forretningssiden i virksomheden. Problemet er nok ikke SOA begrebet i sig selv, men mere at man beskæftiger sig med SOA på forskellige abstraktionsniveauer. Hvis forretningen ser på SOA som andet en et teknologisk projekt, så ses SOA i nogle meget overordende komponenter, hvor man som teknikker ser på SOA i nogle meget mere specifikke komponenter. Hvis ikke forretningen, leverandører og teknikkere er bevidste om denne forskel i deres abstraktion af 4 Alle interviews er tilgængelige i MP3 format, på petkrug 5 Udledt af interviews med [3], [4] og [5]

18 6 Kapitel 1. Indledning SOA så er de tvunget til at tale forbi hinanden. Den tilgængelige litteratur har tendens til at fokusere mere på den tekniske indgangsvinkel og derefter tilpasse dette til et forretningsyn uagtet at fordelen ved SOA primært er baseret på et forretningsmæssigt potentiale, det vil vi behandle nærmere i afsnit 2.1. Derfor vurderer vi, at det er langt mere interessant at se på SOA fra en forretningsmæssig synsvinkel. Vi vil derfor se nærmere de forberedelser forretningen kan gøre, for at komme rigtigt i gang med SOA processen. Modenhedsmodeller bliver ofte anvendt til at pejle en virksomheds udgangspunkt for at påbegynde arbejdet med blandt andet SOA. Der er udviklet adskillige modenhedsmodeller, der er mere eller mindre gode, men fælles for mange af dem er, at de har taget et teknologisk afsæt i forhold til SOA. De forretningsmæssige aspekter i modenhedsmodellerne er, efter vores viden, ganske overfladisk behandlet. Som tidligere nævnt, kommer en af forfatterne til dette speciale fra forsvaret. Sammenholdt med, at der foregår et stort SOA arbejde i hhv. det danske forsvar og i North Atlantic Treaty Organisation (NATO) regi, har vi valgt at tage udgangspunkt i koncernen forsvaret. Forsvaret vil blive anvendt som case virksomhed, hvor vi vil tage udgangspunkt i en specifik forretningsproces som analyseres for at fremkomme med betragtninger, der eventuelt ville kunne anvendes til vurdering af forsvarets SOA modenhed Problemformulering Med udgangspunkt i ovenstående problemstilling, vil vi ved anvendelse af relevante modeller og begreber fremkomme med en forretningsorienteret SOA modenhedsmodel, primært til anvendelse i forsvaret. Vi vil vurdere en eller flere processer med henblik på at afklare graden af modenhed. Vi vil opnå dette ved at analysere følgende spørgsmål: 1. Er det muligt at opstille en mere forretningsorienteret SOA modenhedsmodel? 2. På hvilket niveau er forsvaret i SOA modenhed? 3. Hvordan kan den forretningsmæssige SOA modenhed forbedres?

19 1.4. Afgrænsning Afgrænsning Forsvaret er et en stor og kompleks virksomhed. Når man skal analysere en stor virksomhed, bør man inddrage alle aspekter af denne. Det kan dog blive en meget stor opgave at uddrage alle fakta om SOA i forsvaret og fremkomme med en komplet modenhedsanalyse. Vi vil derfor bruge analysen til at fokusere på kerneopgaver og kerneprocesser, hvilket vi vender tilbage til i afsnit 4.5, ved enkelte enheder. Dette er for at gøre opgaven mindre kompleks og mere håndterbar. Konklusionerne skulle dog gerne kunne overføres til det brede eksempel. Når man taler om forsvarets IT-installationer, vil tanken ofte automatisk falde på IT-sikkerhed. Særligt i relation til kampenheders brug af IT-systemer, kan CIA (Confidentiality, Integrity and Availability) 6 være kampafgørende. Dette vil dog være et komplet speciale i sig selv, og da forsvaret har sin egen myndighed til at vurdere IT-sikkerhed, nemlig Forsvarets Efterretningstjeneste, vil vi derfor kun berøre IT-sikkerhed, hvor det kan give input til en specifik pointe. Man har dog stadigt fokus på sikkerhedsaspekter ved materieltjenesten i forbindelse med indkøb af nye systemer) Ligeledes kan man anføre, at en beskrivelse af IT Governance for en virksomhed, kan være en stor mundfuld. IT Governance er en væsentlig del af at håndtere og udvikle sine IT-systemer, men da forsvaret har vist sig at have godt styr på IT governance (ved hjælp af bl.a. PRINCE2) [6] [7] så vil vi kun berøre dette område perifært. NATO er i fuld gang med deres arkitekturproces. I løbet af har man arbejdet på at færdiggøre NATO Architecture Framework ver. 3.0 (NAF) denne er udgivet i ULTIMO NOV Dette var så sent, at man fortsat ikke har fået færdiggjort NATO Maturity Levels (NML) - NATOs modenhedsmodel. Vi har derfor valgt ikke at inddrage NML i sammenligningen af modenhedsmodeller i kapitel 2, da det er et ufærdigt produkt.

20 8 Kapitel 1. Indledning Figur 1.2: Specialets opbygning 1.5 Valg af metode og struktur for specialet Specialets opbygning er illustreret i figur 1.2 (p. 8). I første kapitel opstiller vi en problemformulering og ud fra denne beskrives modeller og begreber indenfor SOA og SOA modenhed i kapitel 2. Herunder fremkommer vi med fordele og ulemper ved de eksisterende modeller. I kaptitel 3 redegøres for forsvarets organisation, herunder de enheder der anvendes senere, og forsvarets IT-strategier gennemgås med henblik på, at skabe et fundament for at 6 Confidentiality: fortrolighed hvem har ret til at læse og skrive data; Integrity: integritet af data at man har styr på om data bliver ændret eller slettet under en transaktion eller kommunikation; Availability: tilgængelighed at man har adgang til data, når man har behov for det.

21 1.5. Valg af metode og struktur for specialet 9 vurdere forsvarets indsats på SOA området. I kapitel 4 opstiller vi på basis af resultaterne fra kapitel 2 en ny model til at måle SOA modenhed. For at teste denne model, afprøver vi den på en enhed i forsvaret i kapitel 5 og søger at udlede noget generelt om SOA modenhed i forsvaret. I kapitel 6 samler vi konklusionerne og vurderer, hvor godt modellen har beskrevet SOA modenheden og om der er muligheder for at anvende modellen i andre sammenhænge Praktisk læsevejledning Vi har anvendt følgende notation i specialet: Kapitler og afsnit er benævnt med arabertal i op til to underniveauer. Henvisninger er til afsnit, f.eks. afsnit 1.5. Figurer er benævnt med to arabertal, hvor første tal angiver kapitelnummer, og andet tal er figurens nummer i pågældende kapitel. Der anvendes alene fodnoter. Nummerering starter forfra i hvert kapitel. Bagest i specialet er en bibliografi. Denne er usorteret, men afspejler rækkefølgen kilderne optræder i specialet. Henvisninger til en kilde sker med denne notation: [6]. Såfremt der henvises til en bestemt side i kilden vil det fremgå således: [6, p. 5]. Er der tale om et interview, vil disse være tilgængelige som Mp3 filer på følgende adresse: og henvisningen vil indeholde det tidspunkt i lydfilen vi referer til, således: [6, min. 20:23]. Ikke publiserede kilder i bibliografien vil være at finde på Ligeledes er der bagest i specialet en liste med forkortelser. Vi er klar over at forsvaret bruger mange forkortelser og de er derfor medtaget disse. Bemærk at man i forsvaret ikke anvender bøjning på militære forkortelser (eksempelvis kan BTN både stå for bataljon, bataljoner, bataljonens, etc.), hvilket vi også efterlever. Citater på engelsk vil ikke blive oversat til dansk, men betydningen vil blive diskuteret i brødteksten. Termer og begreber fra IT-verdenen som anses for at være kendte, vil ikke blive oversat.

22 10 Kapitel 1. Indledning Metode For at være i stand til at beskrive forsvaret på en sådan måde, at det er anvendeligt som case, vil vi kort redegøre for metodikken til case study research fra Robert Yin [8]. Det er dels for at afklare en metodik til at formulere undersøgelsen af forsvaret som case. Videnskabelige undersøgelser kan gennemføres på mange forskellige måder. På det samfundsmæssige område kan det omfatte eksperimenter, spørgeundersøgelser, analyse af historie eller arkiveret information (statistik). Alle disse har fordele og ulemper, og er afhængige af tre betingelser: (a) typen af det stillede videnskabelige spørgsmål, (b) den kontrol undersøgeren har over de aktuelle adfærdsmæssige aktiviteter og (c) om der er fokus på nutidige eller historiske fænomener[8, p. 1, 5]. Det afgørende er, at vi i dette speciale ikke har adgang til at ændre på adfærden i den undersøgte virksomhed (hvorfor eksperimenter ikke er en mulighed jf. (b)), og vi fokuserer på kontemporære emner (hvorfor historieanalyse ikke er en mulighed jf. (c)), står alene tilbage af vælge mellem spørgeundersøgelse eller case studie. Dette afgøres af valget af spørgsmål der stilles i specialet. Vælger man at spørge hvordan og hvorfor er det et case studie, mens man ved de yderligere spørgsmål som hvor, hvad, hvor mange og hvor meget skal give sig i kast med en spørgeundersøgelse. I og med, at vi vil fokusere på analyse og vurdering, er det oplagt at der skal være nogle bagvedliggende hvor og hvad, men det centrale i vores undersøgelser er hvorfor eller hvordan, hvilket leder os til at betragte det som et case studie. Case studier egner sig til undersøgelse af emner indenfor det samfundsvidenskabelige område. Informationsteknologi (IT) hidrører som regel til det naturvidenskabelige område qua sin tekniske indgang til tingene, men når man ser på emnet for dette speciale (der jo tager sit udgangspunkt i EBUSS linien på cand.it studiet), bliver det langt mere i retning af det økonomiske/forretningsmæssige område, og dermed i retning af det samfundsvidenskabelige. Case studier handler i bund og grund om at indsamle, analysere og præsentere data på en fornuftig, valid og redelig måde. [8] angiver metodik til at gøre dette på en systematisk måde. Man skal vælge mellem at gennemføre et studie af undersøgende, beskrivende eller forklarende karakter. I et speciale må man naturligvis komme ind på alle tre forskellige dele for at opnå den fornødne viden som basis for sin analyse. Case studier kan bruges til enten at præsente en individuel case eller at ge-

23 1.5. Valg af metode og struktur for specialet 11 neralisere ud fra undersøgelsen af denne. Det er vores håb, at indeværende speciale kan give en afklaring af problemstillingen i forsvaret, og at dette kan anvendes til at sige noget generelt om de resultater, der fremkommer, så det vil kunne bruges generisk også i andre sammenhænge, dvs. til modenhedsanalyse af andre virksomheder end forsvaret. Man kan vælge mellem at undersøge en eller flere cases og så sammenligne disse. Dette ses dog som nævnt i indledningen ikke optimalt, da vi derved ikke kan komme nok i dybden med analysen (fordi der skal bruges for meget plads på at beskrive den anden eller flere virksomheder). Man vil kunne opbygge en case på følgende måde: 1. Studiets spørgsmål, hvor de primære hvordan og hvorfor defineres. 2. Forslag / Hypotese, hvor spørgsmålet defineres i en hypotse om den virksomhed vi vil undersøge. Her fremkommer de underspørgsmål, som skal undersøges, og hvordan det skal gøres. Dette kommer til udtryk i problemformuleringen. 3. Analysens elementer, hvor fremgangsmåden for undersøgelsen opstilles med spørgsmål og metodik. Det er samtidigt her man skal afgrænse sig for at undgå at blive fanget af at ville undersøge alt. Underspørgsmålene klarificeres her og man skal afklare hvordan man sikrer sig at få valide data gennem spørgsmålene. Desuden afklares, hvem eller hvilke afdelinger det er relevant at undersøge, for at dels afgrænse opgaven og dels rette analysen mod de interessante og relevante data. Det er også her man fastlægger hvilken litteratur man vil anvende for at sikre sig, at man har de relevante a priori antagelser med. Dette vil vi skrive om i kapitel 2 og Det logiske link mellem data og hypotese, hvor man finder sammenhænge mellem data og virksomhed, hvor man sammenligner data med tidligere kendt viden og opstiller nye fundne sammenhænge. Det gør vi i kapitel 4 hvor vi opstiller modellen, og i kapitel 5, hvor vi anvender modellen på casen. 5. Kriterier for at tolke analysens resultater dvs. hvor man opstiller de krav der skal være opfyldt for at man kan svare positivt på de stillede spørgsmål i studiet. Det gør vi i kapitel 6. Det vi har valgt at gøre er således følgende: Efter problemstillingen (1) er blevet defineret er gennemført nogle eksplorative (opklarende) interviews for

24 12 Kapitel 1. Indledning at sikre et fornødent domænekendskab. Og ud fra dette er hypotesen om at man kan opstille en modenhedsmodel for forsvarets SOA modenhed iscenesat (2). Herefter har vi arbejdet med dels litteratur og teoriapparat for at kunne opstille en modenhedsmodel, som kan danne grundlag for en yderligere undersøgelse i (3). Først nu gennemføres dataindsamling i form af interviews med personer i forsvaret for at sikre, at det er de korrekte spørgsmål der bliver stillet og at data bliver af valid karakter, som kan give input til undersøgelsen i (4). Slutteligt mangler vi så at afklare resultatet af analysen i forhold til kriterierne i (5), for at sikre at vi er nået hele vejen rundt. Planlægning af dataindsamling Dataindsamling sker hernæst i relation til udviklingen af vores model og de spørgsmål, der kan udledes heraf (jf. afsnit 4.3. Der gennemføres interviews og læses diverse publikationer og direktiver fra forsvaret mhp. at besvare spørgsmålene. Disse resultater rededøres der for i kapitel 3 og anvendes i kapitel 5. Forsvaret er en stor case, men jf. afgræsningen ser vi på mere håndterbare enheder og opgaver. Undersøgelsesgruppen består kun at to personer (forfatterne), hvorfor vi har vuderet, at det ikke ville være nødvendigt med en undersøgelsesprotokol. Data registeres løbende og analyseres i det pågældende kapitel, som det falder naturligt. Der bør kunne etableres en chain of evidence som kan føre frem til at kunne konkludere på analysen. Interviews gennemføres med åbne spørgsmål for at give respondenter mulighed for at elaborere over emnet, samt for at give intervieweren mulighed for at improvisere undervejs, såfremt der måtte opstå ikke forudsete muligheder for enten at gøre data mere dybdegående eller mere omfattende. Interviews optages i MP3 format for at sikre til stadighed at kunne gå tilbage og validere data. 1.6 Bidrag Vores speciale fremkommer med en ny metode til at måle SOA modenhed. Udgangspunktet for modellen er, at den skal være mere forretningsorienteret, hvilket vi ser opnået ved hjælp af opgavecentrerede økosystemer. Modellen opfordrer til, at man beskriver ens kerneopgaver og processer med henblik på at assistere i prioriteringen af disse. Dette medvirker til at en virksomhed kan fokusere sin indsats på de opgaver og processer, der giver størst forretningsmæssig værdi.

25 1.7. Tak til 13 Derudover har vi beskrevet en SOA proces, som kan bruges som roadmap til at planlægge en virksomheds videre rejse mod SOA. Modellen er valideret på et mindre eksempel i forsvaret. 1.7 Tak til Vi vil gerne takke vores velvillige interviewofre for at have taget sig tid til at give deres bud på, hvad SOA og SOA modenhed er for nogle størrelser. Vi vil gerne takke Rasmus Knippel fra Cap Gemini for at have bidraget til opbygningen af en interessant problemstilling omkring SOA modenhed ovenikøbet efter vi var gået. Vi vil gerne takke Gert Hvedstrup Jensen for at have mødtes med os flere gange og bidraget til at give FMT syn på NBO og SOA og ikke mindst for gode og saglige kommentarer til vores arbejdsproces. Søren-Peter Nielsen tog sig tid i en meget travl hverdag til at mødes med os og give os IT- og Telestyrelsens visioner for Danmarks fremtidige tilgang til SOA og den rolle det offentlige spiller i denne proces. Torbjörn Åhberg gav os indblik i SOA fra en leverandørs perspektiv, og fik forklaret i lægmands termer hvad SOA er. Glenn Jeilsø fra FKO, Bent Brundtø og Kim Holm fra FKIT gav os mange gode pointer om SOA i forsvaret og lysten til at arbejde videre med SOA i en stor virksomhed. Tak til John for at give os adgang til dit store netværk og for at lade os deltage i SOA konferencer og workshops. Det gav et ekstra twist til opgaven. Vi vil gerne takke Kim og Peter for at have læst korrektur på specialet vi ved godt at det er et hestearbejde, så vi sætter meget stor pris på, at I tog jer tid. Sidst, men ikke mindst, tak til Maja og Malene for jeres store tålmodighed og opbakning. Uden den, var vi næppe kommet så langt.

26 14 Kapitel 1. Indledning

27 15 Kapitel 2 Eksisterende modeller og begreber Indholdet af dette kapitel vil primært være fokuseret på at beskrive de teorier og modeller, som vi anser for at være meget interessante i forbindelse med besvarelsen af problemformuleringen. Vi vil kort gennemgå de udvalgte begreber og modeller, for at forklare, hvad essensen af dem er. Derudover vil vi fremhæve og diskutere, hvad vi finder mest anvendeligt ved de respektive modeller og begreber. Der vil i de efterfølgende kapitler blive refereret til dette kapitels beskrivelser samt blive uddybbet, hvorfor vi finder en model eller et begreb interessant. Da begrebet Service Orienteret Arkitektur er et meget grundliggende begreb for dette speciale, forekommer det, som et naturligt sted at starte med beskrivelserne. 2.1 Hvad er SOA? Før vi går i gang med at definere vores forståelse af begrebet SOA, finder vi det essentielt at undersøge, hvorfor SOA er interessant. Som vi vil diskutere i afsnit er der ikke en entydig definition af hvad SOA er, hvilket har givet plads til en hel del hype. Størstedelen af hypen drejer sig natuligvis om hvilke fantastiske fordele, der kan opnås med SOA. Dem er der rigtigt mange af og vi har bragt et lille udvalg af dem her 1 Agile 2 systemer: SOA vil gøre det nemt og hurtigt at lave ændringer 1 Vi har lånt opstillingen af SOA hype, fra Rasmus Knippels speciale[3, p. 7], da denne er yderst passende til vores brug. 2 Agil: smidig, fleksibel eller omstillingsberedt.

28 16 Kapitel 2. Eksisterende modeller og begreber til virksomhedens IT systemer, ikke kun i funktionalitet, men også p- latform, leverandør og geografisk lokation. Integration: SOA gør det muligt og nemt, at integrere systemer på tværs af siloer og platforme. Lavere udviklingsomkostninger: SOA muliggør genbrug af kode og funktionalitet, samt data efter mantraet data fødes en gang og er tilgængeligt overalt. Forbedret ROI 3 Ses blandt andet opnået ved at: Undgå dyr middleware og undgå proprietære standarder, ved at anvende åbne standarder og webservices. Konsolidering af en virksomheds forretningsgange til fælles services, der kan anvendes af flere forretningsenheder. Forretningsprocesser kobles til IT: Alle forretningsprocesser skal tænkes som services. Støtter produkter med kort livscyklus: I den meget konkurrenceprægede verden er tid penge, og SOA lover at kunne understøtte nye produkter hurtigt, således at Time-to-Market (TTM )bliver kortere 4. Dette er blot et lille udsnit af de fordele SOA kan levere, hvilket forklarer at SOA er et begreb som mange taler om. Mange af fordelene er indbyrdes afhængige. Hvis vi skal pege på en overordnet forretningsmæssig fordel ved SOA, så må det blive et citat af ZapThinks Ronald Schmelzer: After all, the greatest benefit of Service-Oriented Architecture (SOA) is the business value it offers via increased business agility[9] Begrebet SOA virker umiddelbart til at dække over løsningen på et hvert tænkeligt problem i relation til koblingen mellem IT og forretning og integration mellem adskillige IT systemer. Det er umiddelbart noget af en opgave, som man ser løst af SOA, hvorfor man kan undre sig over, hvad dette begreb helt præcist indebærer og hvordan det skal kunne realisere forventningerne. Denne undren bringer os til at undersøge, hvordan SOA defineres nærmere. 3 Return on Investment 4 TTM - tiden der går fra at en virksomhed får en ide til et nyt produkt til det er på markedet.

29 2.1. Hvad er SOA? Definitioner af SOA I den tilgængelige litteratur har adskillige forfattere opremset forskellige definitioner på, hvad der efter deres mening, er definitionen på SOA. Fælles for alle definitionerne er, at der ikke umiddelbart er nogen, der er forkerte, idet forståelsen kommer an på hvilket perspektiv læseren har på at læse den givne tekst. Efter vores mening, er den meget snævre tekniske definition af SOA fuldt ud lige så valid, som en mere high level forretningsmæssig beskrivelse det kommer nemlig helt an på, hvordan man har behov for at forstå begrebet. I forbindelse med fokus for dette speciale har vi primært læst i forretningsrettede bøger, hvilket vil sige, at de specifikke tekniske forklaringer med vilje ikke er inddraget i den efterfølgende definition af SOA. IBM s definition Når man vil definere SOA forekommer det naturligt at beskrive, hvad en af de store og mere erfarne aktører på området forstår ved begrebet. Et par af IBM s medarbejdere har i [10] nævnt flere definitioner af SOA, som bliver diskuteret. Man når frem til en fælles forståelse for, hvad SOA skal forstås som i bogen, nemlig: A service-oriented architecture is a framework for integrating business processes and supporting IT infrastructure as secure, standardized components services that can be reused and combined to address changing business priorities. [10, p. 4-5] Det er jo en meget god og let forstålig definition, som forholdsvis nemt kan sælges henover direktionsbordet, hvilket heldigvis også stemmer overens med målgruppen for bogen. Vi vil dog påpege, at første halvdel af IBM s definition umiddelbart minder mere om, hvad vi forstår ved EA (Enterprise Arkitektur bliver defineret nærmere i afsnit 2.2) der jo netop har til formål at forsøge at forene forretningsprocesser og IT. Den anden halvdel af definitionen koncentrerer sig så mere om, hvad vi reelt vil betegne som essensen af serviceorienteret arkitektur, nemlig at opbygge standardiserede og genbrugelige komponenter, som kan kombineres og re-kombineres, således de dækker forretningens skiftene behov. Genbrug af services, stiller nogle krav til definitionen af de enkelte services, idet man skal definere services til at udbyde lige præcis de informationer og funktionaliteter, der er nødvendige

30 18 Kapitel 2. Eksisterende modeller og begreber for at kunne løse en specifik opgave, enten alene eller i sammenhæng med andre services. Det er nok ikke helt tilfældigt, at IBM anvender en EA-lignende definition af SOA, idet det er to begreber, der er forholdsvis svære at skille ad. Det forekommer os i hvert fald svært at tale om SOA uden at tænke i EA baner, da man efter vores mening bør have gjort sig et minimum af overvejelser omkring sin EA, inden man begynder at drømme for meget om SOA. Set i den sammenhæng er det meget naturligt, at IBM definerer SOA, som de gør. OASIS definition En anden definition som er mere rettet mod distribuerede egenskaber ved SOA bliver tilbudt af OASIS 5 : Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. [12] Denne definition af SOA lægger mere vægt på de distribuerede egenskaber ved SOA og de deraf afledte kompleksiteter. Hvis vi sammenligner denne definition med IBM s definition, stiller OASIS s definition nogle yderligere krav til, hvordan services skal opbygges. Da enkelte komponenter i en SOA kan ligge uden for dens kontrolområde, stilles der nogle implicite krav til definitionen af dens komponenter. Man kan man af gode grunde ikke forvente, at alle andre anvender den samme teknologi platform som en selv. For at SOA skal kunne fungere, kræver det at komponenter eller services skal defineres på en sådan måde, at de kan forstås af alle, der har behov for at kunne anvende en service. Det vil i korte træk sige, at man såvidt muligt og efter behov skal definere services efter standarder 6, som til en vis grænse gør, at services bliver anvendt og fortolket på samme måde, hvad enten man koder dem i Java eller.net. 5 OASIS er et non-profit konsortium som arbejder med at udvikle af standarder [11] 6 Som eksempelvis webservice standarden

31 2.1. Hvad er SOA? 19 TOGAF s definition En tredje definition bliver tilbudt af TOGAF 7, som er en organisation, der traditionelt har arbejdet meget med Enterprise Arkitektur. Definition of SOA Service-Oriented Architecture (SOA) is an architectural style that supports service orientation. It is a way of thinking in terms of services, service-based development, and the outcomes of services. [13] Hvor en service defineres på følgende måde: A service is a logical representation of a repeatable business activity that has a specified outcome, such as check customer credit, provide weather data, or consolidate drilling reports. It is self-contained, may be composed of other services, and is a black box to its consumers. [13] Som man måske kunne forvente, så er TOGAF mere klare omkring A et i SOA. De definerer, at det er en arkitekturstil, som understøtter service o- rientering. Derudover definerer TOGAF SOA, som en måde at tænke på, hvilket er en mere passende beskrivelse af SOA end IBM s framework beskrivelse. SOA er, efter vores mening, mere en filosofi eller paradigme, end det er en specifik metodik til at opnå agilitet, jf. SOA fordele på side 16 i en virksomhed 8. Vores egen Definition Baseret på de ovenstående definitioner af SOA, vil vi nu sammensætte vores egen definition af SOA, så den indeholder de elementer, som vi mener, er de mest interessante ved SOA. Dette bliver derved sådan begrebet skal forstås gennem dette speciale. 7 The Open Group Architecture Forum 8 Her tænkes på agilitet i sin bredeste forstand, spændende over blandt andet IT systemer, forretningsmodeller, markeder og produkter.

32 20 Kapitel 2. Eksisterende modeller og begreber Service Orienteret Arkitektur, er en arkitekturstil der understøtter serviceorientering, ved at fokusere på at udvikle selvstændige standardiserede services 9 der kan genbruges og kombineres med andre services, der kan ligge indenfor eller udenfor eget domæne og kontrol. Det unikke ved vores definition af SOA, er at vi har inkluderet følgende interessante og problematiske elementer: Arkitekturstil Selvstændige standardiserede services Genbrugelige services Kombinerbare services Services kan være under forskellige domæner af ejerskab Den ovenstående liste illustrerer, hvad vi ser som kernen i SOA. Vi ser SOA, som en samling af tanker og principper arkitekturstile for hvordan man skal designe IT systemer og forretning, så de går gå op i en højere enhed, og derved opnå business agility, jf. afsnit 2.1. Indeholdt i denne arkitekturstil, er så tankerne om at standardisere, genbruge og kombinere services, som derudover også tager hensyn til, at services kan anvendes og udbydes af kilder uden for en virksomhed. Denne arkitekturstil, SOA, er guiden for at virksomheder kan nå deres mål business agility. Det efterfølgende afsnit vil beskæftige sig med at beskrive de understøttende principper for at muliggøre SOA Principperne bag SOA Konkurrencen er øget i hele verden grundet flere forskellige faktorer, hvilket stiller krav til at virksomheder skal levere mest muligt til mindst mulig pris. Introduktionen af IT systemer bevirkede, at den samme medarbejderstab kunne formå at producere mere og bedre, hvilket øgede konkurrencedygtigheden. Eftersom flere og flere IT systemer er blevet tilføjet for at understøtte flere og flere opgaver og stort set alle konkurenterne har de samme eller 9 jævnfør TOGAF SOA Definition

33 2.1. Hvad er SOA? 21 tilsvarende systemer, har IT systemerne efterhånden mistet deres konkurrencemæssige betydning, idet de nærmere er blevet en forudsætning for at kunne deltage i kapløbet. Konkurrencefordelen er efterhånden blevet flyttet fra IT-understøttelse til integration og agilitet, hvilket er den grundliggende tanke i SOA. Selvom der er mange forskellige definitioner af, hvad SOA er, er der dog ikke ændret ved at målet i sidste ende er agilitet. Dette bevirker, at uanset hvordan man definerer SOA, er der nogle sammenfaldene principper, som gør sig gældende for at kunne indfri målet om agilitet. Principperne bliver benævnt lidt forskelligt, alt efter hvilken litteratur man studerer, dog er der sammenfald i meningen af de forskellige principper. Disse principper [14] vil i det efterfølgende blive listet med en forklarende tekst. Forretningsrelaterede services Genbruglige services Kontraktbaserede services Løst koblede services Platformsuafhængig anvendelse af services Lokationsuafhængig anvendelse af services Sammensætning af services Services er en abstraktion over forretningsfunktionalitet og information Services versioneres Services registreres og er synlige SOA er baseret på standarder Fælles for disse principper er, at enkelte overlapper hinanden og andre hænger sammen, hvorfor principperne skal ses som en sammenhængende masse og ikke enkeltvis anvendes som implementeringsmilepæle eller til vurdering af SOA modenhed [14, p. 38]. Dette vil dog ikke afholde os fra at anvende enkelte af disse principper, ved en efterfølgende udvikling af vores SOA modenhedsmodel. Forretningsrelaterede services: Dette princip dikterer at services skal understøtte forretningsprocesser, så der er fælles fodslag mellem IT og forretningen. De centrale aktiviteter for at

34 22 Kapitel 2. Eksisterende modeller og begreber sikre dette fælles fodslag, er modellering og forståelse af forretningsprocesser. Denne forståelse og modelering vil så kunne anvendes som udgangspunkt for specifikationen af services. Genbruglige services Services skal som udgangspunkt designes med henblik på genbrug, hvilket vil sige at services skal opbygges på baggrund af bredt accepterede arkitektur principper og standarder. Overholdelse af sådanne standarder og principper vil kunne sikre at services vil kunne kommunikere med andre og således bliver mere anvendelige og genbrugbare. Kontraktbaserede services En servicekontrakt er en specifikation af, hvad en service kan tilbyde, hvad den forventer til gengæld og hvordan der kommunikeres. En kontrakt er i bund og grund, en præcis beskrivelse af hvad serviceyder og servicemodtager kan forvente af hinanden, samt en beskrivelse af hvor servicen kan findes, typisk en URL. Overholdelsen af dette princip vil være medvirkende til at koble services løst til hinanden. Løst koblede services Dette princip er meget vigtigt i relation til at opnå fleksibilitet i sine ITløsninger. Løst koblet, betyder at der er et minimum af afhængigheder mellem serviceyder og servicemodtager. Den eneste fælles reference som servicemodtager og serviceudbyder har til hinanden er servicekontrakten, som dikterer med hvilket indhold og hvordan kommunikationen skal foregå. Den store fordel ved at have løstkoblede services er, at man kan ændre i den bagved liggende kode/implementering af services uden at servicemodtagere opdager det 10. Platformsuafhængige anvendelse af services Dette princip dikterer at man skal beskrive sin servicekontrakt i et platformsuafhængigt format, samt at anvende platformsuafhængige kommunikationsprotokoller, eksempelvis hhv. WDSL og SOAP. Ved anvendelse af disse vil man eksempelvis kunne få en service kodet i Java til at tale med en.net webservice. Princippet om løst koblede services kommer også til sin ret her, da dette netop frigør servicen fra sin implementering, og dermed det sprog den er kodet i. Lokationsuafhængig anvendelse af services Dette princip går ud på, at en servicebruger skal kunne anvende en service uden at vide præcist hvor denne service afvikles fysisk. 10 Så længe servicekontrakten overholdes, vel og mærke

35 2.1. Hvad er SOA? 23 Sammensætning af services Man kan sammensætte services af andre services. Man kan betragte services som en slags byggeklodser som man kan opbygge services og forretningsprocesser med. Dette kaldes orkestrering. Der stillles naturligvis nogle driftsmæssige krav til services, der anvendes af mange andre services, idet den service potentielt ville kunne blive en flaskehals. Services er en abstraktion over forretningsfunktionalitet og information Dette princip dikterer, at en service skal være en abstraktion over den underliggende implementering. Det vil sige at en service kan være langt mere kompleks end den ser ud til at være for servicebrugeren, idet servicebrugeren kun kan se det af servicen, som er specificeret i servicekontrakten. Derudover kan en service også være meget kompleks i sin implementering, hvor det for en servicebruger ikke er relevant at se kompleksiteten, men kan nøjes med et meget simplere interface. Fordelene er som ved løskobling at man kan ændre frit i den underliggende implementering, uden at påvirke servicebrugere, så længe man vel og mærke overholder servicekontrakten. Services versioneres Dette princip skal sørge for at man på sigt kan udvikle sine services, så man kan have flere versioner af samme service kørende samtidigt, samt have mulighed for at varsle brugere om, at der snart ændres i servicekontrakten, eller at denne skal opdateres. Dette er vigtigt for at kunne opretholde fleksibiliteten i sine løsninger. Services registreres og er synlige For at gøre det nemt at finde services kan man med fordel registrere dem i et katalog, hvor servicebrugere kan slå dem op, og efterfølgende forbinde til den rigtige service, som at anvende en telefonbog. Det er vigtigt at definere, hvilke oplysninger der skal publiceres i kataloget samt i hvilket format. SOA er baseret på standarder Dette gælder naturligvis tekniske standarder, som skal sikre at servicemodtager og -yder skal kunne kommunikere. Derudover er det også nødvendigt, og sikkert langt sværere, at definere standarder for bla. forretningsmæssige begreber, således at servicemodtager og -yder har samme forretningsmæssige forståelse af, hvad en service tilbyder. Dette kan gøres ved standardiserede domænemodeller og referencemodeller, som vil skulle udarbejdes i samarbejde mellem deltagere i disse domæner.

36 24 Kapitel 2. Eksisterende modeller og begreber De ovenstående principper er blevet opstillet af IT- og Telestyrelsen (ITST) og fungerer som et fingerpeg om, hvad man skal have in mente, når man påbegynder arbejdet med SOA. Listen er dog ikke udtømmende, og andre principper vil formodentligt være at finde i specifikke projekter. 2.2 EA og SOA Vi har nu par gange nævnt Enterprise Arkitektur og Serviceorienteret Arkitektur i sammenhæng. Dette er gjort helt overlagt, da der, for os er en klar kobling mellem disse to selvstændige begreber. I første omgang vil vi kort præsentere, hvad vi forstår ved Enterprise Arkitektur. SOA blev præsenteret i afsnit 2.1.1, og vi vil i det efterfølgende, afsnit 2.2.2, argumentere for sammenhængen mellem EA og SOA. For senere at kunne anvende elementer fra EA i opbygningen af en modenhedsmodel, vil vi fremstille den sammenhæng vi ser mellem EA og SOA Hvad er Enterprise Arkitektur? Enterprise arkitektur er en akademisk velbeskrevet disciplin, idet der findes adskillige frameworks på markedet. Disse giver et bud på hvordan en EA skal se ud og hvordan man skal gribe EA processen an. Nogle af disse er Zachmans framework [15], TOGAF [16], DODAF [17], MoDAF [18], FEAF [19] og Hvidbog i IT-arkitektur [20], hvor de fleste har skævet til Zachmans framework i udgangspunktet. Zachman bliver ofte refereret til som EA ens fader, primært fordi han var en af de første til at formulere tankerne om behovet for et holistisk billede af en virksomhed (enterprise), hvor strategier, IT-systemer og forretningen er rettet mod et fælles mål. Behovet for et helhedssyn på en enterprise skyldtes ikke kun, at IT-systemerne blev større og mere komplekse, men også at de begyndte at blive distribueret ud til flere afdelinger af en enterprise. Formålet med EA er, at virksomheder, på baggrund af en veldokumenteret EA, er i stand til at træffe bedre strategiske beslutninger og få disse implementeret i virkeligheden. Fælles for de fleste frameworks er, at de er gode til at illustrere, hvad der skal dokumenteres, men knap så gode til at forklare, hvordan man får begyndt på EA arbejdet. En undtagelse fra dette er Scott A. Bernard, som udover et framework også har beskrevet en metodik til, hvordan det kan udfyldes [21]. Bernard har defineret EA på følgende måde:

37 2.2. EA og SOA 25 EA = Strategi + Forretning + Teknologi [21, s. 32]. Formålet med EA arbejdet er at aligne alle de forretningsrelaterede tiltag i en virksomhed, så alle tiltag er rettet mod det samme mål. Arbejdet med EA resulterer i en række produkter, som ofte kaldes artefakter 11. Et artefakt er en beskrivelse af eksempelvis en forretningsproces, en infrastrukturkomponent, en applikation eller noget helt fjerde. I denne forbindelse er det vigtigt at påpege, at EA ikke er et fysisk produkt i sig selv, men resulterer i en række produkter, som beskriver en enterprises komponenter i en fælles referenceramme. Bernard har lavet en god opstilling over, hvad man kan forvente at få ud af EA. EA består af to dele, en managementdel og en dokumentationsdel, der til sammen giver et koordineret overblik over en virksomheds strategi, forretning, ressourcer og flow af informationer. Managementdelen består af fire områder [21, p. 33]: Resource alignment: Resource planning and standards determination Standardized policy: Resource governance and implementation Decision support: Financial control and configuration management Resource oversight: Lifecycle approach to development/management Og dokumentationdelen [21, p. 34] består af følgende fire områder: EA Approach: A modeling framework and implementation methodology Current views: Views of AS-IS strategies, processes and resources Future views: Views of TO-BE strategies, processes and resources EA management plan: A plan to move from AS-IS to TO-BE Managementdelen er de overordnede principper og regler for, hvordan man ønsker sin EA etableret og styret. Man kan sige, at managementdelen står for styring og strategi, og dokumentationsdelen for implementeringen af disse. 11 Når vi efterfølgende anvender artefakter, referer vi til produkter som er indeholdt i EA.

38 26 Kapitel 2. Eksisterende modeller og begreber EA i en SOA sammenhæng EA resulterer i en række artefakter, der beskriver en enterprise i et helhedsperspektiv, inkluderende både strategier, forretning og ressourcer. Dette dokumenterede overblik over en virksomhed, vil alt andet lige gøre det en hel del nemmere at realisere en SOA. Efter vores mening er EA og SOA ikke 2 modstridende eller konfliktende begreber, men nærmere to begreber som støtter hinanden vældig godt. EA er som sagt summen af strategi, forretning og teknologi, som i skøn forening, gerne skulle gøre at en virksomhed anvender sine ressourcer mest effektivt og træffer de rigtige beslutninger (også på lang sigt) ud fra de muligheder og begrænsninger, der ligger i virksomhedens EA. SOA bliver først rigtigt interessant i forbindelse med definitionen af TO- BE arkitekturen, som gerne skulle defineres ud fra de fremtidige visioner for virksomheden. Et eksempel på dette kunne være et problem i en virksomhed, der anvender en lang række forskellige specialiserede silo systemer, hvor det er besværligt (og dyrt) at udvikle systemerne samt at integrere til andre systemer. Virksomheden vil gennem længere tid have ærgret sig over de besværlige monolitter og forventer over tid, at der vil blive et større og større behov for at sammenholde de data, der findes i de forskellige siloer. Hvis dette er AS-IS situationen, så vil en arkitekt lægge meget vægt på, at TO-BE arkitekturen tager hensyn til problemstillingen omkring integration af data. Funktionaliteten af silo systemerne fungerer dog upåklageligt, men funktionaliteten lever ikke op til de krav som fremtidens markedsplads sætter til forretningen. En mulig TO-BE strategi for virksomheden, kan være, at man fremover skal prioritere at få silo systemerne lukket op, så data kan anvendes frit på tværs af systemer. En sådan strategi vil blive inkluderet i virksomhedens EA og dermed i TO-BE arkitekturen. En mulig TO-BE arkitektur, som lever op til strategien om tværgående dataanvendelse, vil potentielt være en SOA. Det ovenstående eksempel illustrerer, hvordan vi ser koblingen mellem EA og SOA. EA er den overordnede ramme for koblingen mellem forretning, teknologi og strategi, som kan realiseres i flere andre arkitekturer, der iblandt SOA. SOA, er derved ikke en forudsætning for EA, men det kan diskuteres om EA er en forudsætning for SOA. Som det måske kan udeledes af det tidligere nævnte eksempel, så mener vi og andre [22], at man ikke realistisk kan implementere og realisere en SOA, hvis ikke man har fundamentet(læs: EA) i orden. Behovet for at få alignet en virksomheds strategier, teknologier og forretningsmæssige mål, er som sådan ikke indholdt i SOA paradigmet (jf. vores definition af SOA på side 19), hvorfor vi ikke ser det realistisk at tale

39 2.3. SOA og Økosystemer 27 SOA uden EA. Teknisk kan det lade sig gøre at påbegynde rejsen mod SOA, uden at have en EA, og (måske) opnå succes med dette. Man bør være forberedt på at støde på problemer, hvis man udelukkende udvikler sin SOA på baggrund af enkeltstående pilotprojekter, som på sigt skal kombineres. Hvis ikke der udvikles en overordnet strategi for, hvordan projekterne skal fungere sammen, så er dette en åbenlys faldgrube, hvor mange gode intentioner går tabt og man (igen) vil stå med infleksible IT løsninger. Udover, at en EA vil hjælpe med styringen af arkitekturer, vil mange af de dokumenterede artefakter også være yderst anvendelige til realisering af eksempelvis SOA. EA er ofte begrænset til, af naturlige årsager, at beskæftige sig med de elementer, der er under en virksomheds umiddelbare kontrol. Da virksomheder befinder sig en verden, hvor der er et hav af leverandører, kunder, institutioner o.l. med hvilke der løbende skal kommunikeres, kan EA styrkes med nogle af de fordele, der ligger i en SOA. Kompleksiteten af virksomhedens EA og SOA kan dog øges, hvis man forsøger at inddrage virksomhedens nærmeste samarbejdspartnere i et tværorganisatorisk samarbejde. Denne kompleksitet kan beskrives og tildels afhjælpes ved anvendelse af SOA økosystemer, som beskrives i det efterfølgende afsnit. 2.3 SOA og Økosystemer Indholdet af dette afsnit baserer sig på økosystemstilgangen fra CBDI [23]. Vi vil overordnet beskrive, hvordan de ser begrebet anvendt. I afsnit vil vi udbygge begrebet til brug for opbygning af vores model. Begrebet økosystem er lånt fra den biologiske verden, hvor ordet beskriver:... et komplet miljø i naturen med alle levende organismer. Det første grundprincip i økologi er, at hver levende organisme har et løbende og vedvarende forhold til ethvert andet element, der indgår i dens miljø. [24] Det vil sige et komplet system, hvor deltagerne er forbundet til hinanden og derved påvirker hinanden både positivt og negativt. Den potentielle fordel ved et økosystem er naturligvis at summen hele økosystemet er mere end summen af dets deltagere, altså tanken om at 2+2 = 5, hvilket ses opnået gennem et positivt symbiotisk forhold mellem deltagerne. Såfremt en af deltagerne fejler, kan det gå ud over alle deltagere i økosystemet. Deltagerne i

40 28 Kapitel 2. Eksisterende modeller og begreber økosystemerne støtter og hjælper hinanden til at opnå mål, som ville være svært eller umuligt at opnå alene. I økosystemer kan man ofte se netværkseffekter, når en kritisk masse er opnået, hvilket kan gøre det svært enten at skifte til et andet økosystem eller at efterligne det. I afsnit på side 84, vil vi beskrive nærmere, hvordan vi ser økosystemer anvendt i dette speciale, nemlig som et fundament for at få beskrevet det virvar af relaterede opgaver og processer, der udgør en virksomhed, på en håndterbar måde. Fælles for virksomheder og mennesker er, at de alle agerer i en eller anden form for økosystem, da de er en del af den verden de befinder sig i. Økosystemer i og mellem virksomhederer kan opstå omkring flere forskellige ting, såsom en ERP applikation 12, et netværk, et programmeringssprog eller en stor kunde. En virksomhed vil således være medlem af adskillige økosystemer alt afhængigt af, hvilket fokus man tager. Uanset hvilken slags økosystem en virksomhed er medlem af, er det nødvendigt, at der er et fælles sprog 13, altså en standardiseret forståelse af begreber på tværs af virksomheder, så deltagere i et økosystem kan kommunikere gnidningsfrit. Adskillige af de forretningsmæssige problematikker, som bør afklares for at opnå en g- nidningsfri integration på tværs af en virksomhed, vil relativt simpelt kunne afklares indenfor den enkelte virksomhed. Hvis man ser SOA i en større sammenhæng end den enkelte virksomhed, så stiger kompleksiteten for afklaring af kommunikationsbehov, hvilket gør, at virksomheden bør udvælge, hvilke økosystemer de aktivt vil deltage i. En ulempe ved økosystemer kan være, at deltagere også bliver påvirkede af hinanden i negative situationer. For at minimere de negative indvirkninger på økosystemets deltagere, kan man med fordel se på SOA, idet der netop her, er mulighed for at koble sig løst til platforme o.l. Et stort potentiale ved dette ville være, at en virksomhed ville kunne høste fordelene ved at være med i et økosystem og takket være den løse kobling ville kunne forlade økosystemet forholdsvist smertefrit, hvis en suboptimal situation skulle opstå. Alt andet lige, skal en virksomhed være opmærksom på, at dominerende aktører i et økosystem, ikke ubetinget går ind for løs kobling til økosystemer, hvilket vi kort vil diskutere i det efterfølgende. Hvordan den løse kobling i økosystemer vil kunne opnås, diskuteres nærmere i afsnit Enterprise Ressource Planing system 13 Electronic Data Interchange (EDI ) er et eksempel på et sådant sprog

41 2.3. SOA og Økosystemer Motiver for et Økosystem Alt efter hvem og hvad, der er den dominerende aktør i et økosystem, findes der forskellige motiver for, hvad formålet med et økosystem er. Overordnet set findes der 5 typer af SOA økosystemer, som er normale på IT-markedet [23, p. 2]: Platformer (Microsoft Windows, Linux o.l.) Udviklere (sprog og/eller værktøj)(java, MS Visual studio) Applikationer (MS Office, SAP) Solution Frameworks Industri- eller forretnings-domæner (det offentlige, Walmart o.l.) De fleste virksomheder vil på en eller anden måde deltage i økosystemer, der er en blanding af de ovenstående typer, og motiverne for de enkelte deltagere vil variere. De fleste motiver vil dog kunne skrives ind under begreberne Lock-In [25, kap. 5 og 6], og Standard wars [25, Kap. 9], hvor eksempelvis en ERP leverandør forsøger at øge lock-in ved at gøre det svært for økosystemets deltagere at skifte til et andet økosystem (en anden ERP applikation). Standard-wars motivet vil kunne indfries af eksempelvis Microsoft, som vil øge størrelsen af et økosystem centreret omkring deres platform, så platformen kan aspirere til at blive en de-facto standardplatform. En understøttende strategi til et sådant motiv, ville være at sørge for, at Microsoft applikationer enten vil være kompatibelt eller inkompatibelt med konkurerende produkter. Som menigt medlem i sådanne økosystemer, skal man gøre sig klart, om man er villig til at acceptere et højere niveau af lock-in, samtidigt med at man skal vurdere, om eksempelvis en microsoft platform understøtter ens behov. Derudover bør det også vurderes, om platformen potentielt ville kunne udvikle sig til at være en de-facto standard eller om man risikerer at være inkompatibel med alle andre. Denne vurdering bør naturligvis foretages inden man vælger at indgå i et økosystem. Når virksomheden har identificeret de økosystemer, den deltager i, er det interessant at undersøge, hvordan koblingen til de andre deltagere i økosystemet defineres og etableres, se mere om dette i afsnit Som tidligere nævnt, er alle virksomheder involveret i en eller anden form for økosystem, uanset om virksomheden er klar over det eller udnytter dette. Interaktion i adskillige økosystemer vurderes at rumme både fordele og

42 30 Kapitel 2. Eksisterende modeller og begreber ulemper, men man kan formode, at det vil være muligt at høste nogle synergi effekter i arbejdet med økosystemer. Disse synergi effekter kan realiseres, hvis en virksomhed er i stand til at sikre, at der er fællesnævnere i de krav, der skal leves op til i de forskellige økosystemer. Dette vil vi vende tilbage til i afsnit om overlappende økosystemer og i afsnit 5.1, hvor vi ser på forsvarets rolle i dets økosystemer Forudsætninger for SOA Økosystemer Arbejdet med SOA økosystemer ligger i høj grad i, at definere hvordan og hvad man skal kommunikere med hinanden. Når man som virksomhed deltager i adskillige økosystemer, opstår der en kompleksitet i forbindelse med definition af begreber og standarder, der skal etableres, for at deltagere kan kommunikere frit og gnidningsfrit med hinanden. Ved deltagelse i adskillige økosystemer, kan der opstå problemer, hvis man skal etablere og efterleve eksempelvis ti forskellige økosystemsstandarder. Som deltager i sådanne systemer, bør man derfor aktivt gå ind i definitionen og afklaringen af disse standarder og begreber. Virksomhedens aktive deltagelse i disse økosystemer og fastlæggelsen af standarder for kommunikation i disse, vil på sigt kunne forbedre muligheden for at indfri de fordele SOA lover, jf. afsnit 2.1. For at man kan kommunikere i et økosystem, bestående af leverandører, kunder og producenter, kræver det, at der defineres et fælles sprog. En metode at beskrive dette sprog på, er at definere en servicemodel for økosystemet. Servicemodellen indeholder en beskrivelse af de informationer, der skal udveksles mellem deltagere, samt hvordan denne kommunikation skal foregå. Servicemodeller kan i princippet sammenlignes med en servicekontrakt, jf. afsnit 2.1.2, men på et højere abstraktionsniveau. Relevante input til udarbejdelsen, af servicemodeller, vil være artefakter fra en EA, hvorfra man vil kunne udlede, hvilke typer af data, der forefindes i virksomheden og hvilke der ville være interessante at dele med andre. Derudover vil EA give et overblik over hvordan kommunikationen ville kunne foregå, i kraft af applikationer, infrastruktur, standarder o.l. Hvis ikke der eksisterer en EA, så skal denne dokumentation udarbejdes, inden man kan udarbejde en servicemodel. En servicemodel består af to elementer, hvor det ene er rettet mod forretningsmæssige services Business Service Model (BSM ) og det andet er rettet mod infrastrukturservices Infrastructure Service Model (ISM ) [23, p. 3]. Disse to elementer kan både anvendes internt i en virksomhed og eksternt af andre virksomheder, uafhængigt af hinanden. Det vil sige, at en

43 2.3. SOA og Økosystemer 31 virksomhed kan definere en BSM, som eksterne partnere kan anvende, mens ISM kun anvendes internt. En servicemodel, skal i stil med servicekontrakten, specificeres uafhængigt af sin implementering, så brugere af de udbudte services ikke behøver at kende de bagvedliggende systemer 14. I figur 2.1 (p. 31) [23] er der illustreret en servicemodel. Figur 2.1: Servicemodel for Økosystem Figur 2.1 er en eksempelvis illustration af de forskellige lag, der skal til for at 14 Der vil i det resterende af denne opgave ikke blive skelnet mellem ISM og BSM, da vi ikke anvender begrebet i en sådan detaljeringsgrad, at en skelnen er relevant.

44 32 Kapitel 2. Eksisterende modeller og begreber tilbyde en service til en servicebruger. De stiplede linier indikerer, sammenhængen mellem den information eller funktionalitet, som en service udbyder til brugeren, samt hvorfra disse informationer og funktionaliteter udbydes. Målet for servicemodeller er, som sagt, at de skal være uafhængige af deres implementering, men i kraft af at de ressourcer en service trækker på, er sammensat af en lang række forskellige systemer, bliver denne løse kobling kompleks. Hvert enkelt lag i servicemodellen kan potentielt bevirke, at der opstår afhængigheder til de efterfølgende lag. Eksempelvis kan applikation X, udbyde en funktionalitet, som kræver at servicebrugeren også gør brug af applikation X. Der er et hav af potentielle afhængigheder mellem de forskellige lag, og det vil være yderst besværligt at undgå alle disse. Løs kobling i servicemodeller betyder, at man har fundet et acceptabelt forhold mellem afhængighed og fleksibilitet. Dette forhold vil være en forudsætning for at tale om løs kobling i afsnit 4.6. Udover at illustrere afhængigheder mellem komponenterne i en servicemodel, illustrer figur 2.1 også muligheden for indlejrede servicemodeller. Dette vil sige at man kan skalere scope for en servicemodel, så en servicemodel kan trække på andre underliggende servicemodeller. I figuren eksemplificeret ved tilstedeværelsen af to ISM, hvor den øverste kan indholde en eller flere andre ISM. Dette er også et forudsætning for begrebets anvendelse i afsnit Modenhedsmodeller og SOA I dette afsnit vil vi kort præsentere en række forskellige modenhedsmodeller, som vi finder interessante i forhold til at evaluere SOA modenhed. Vi vil ikke beskrive de enkelte modeller i detaljer, men fremhæve de fælles træk, som gør sig gældende for de fleste modehenhedsmodeller, samt fremhæve de steder hvor de adskiller sig mærkbart fra hinanden. Vi har i dette speciale beskæftiget os med bred vifte af modenhedsmodeller, som kan ses herunder i vilkårlig rækkefølge: IBM - SOA Self-assesment Survey 15 [26] SAP- SOA Self-assesment Survey 16 [27] Sonic Software [28] 15 Udskrift af testen er tilgængelig på 16 Udskrift af testen er tilgængelig på

45 2.4. Modenhedsmodeller og SOA 33 BPtrends [29] IBM Service Integration Maturity Model (SIMM) [30] CBDI forum SOA Adoption in the Danish Public Sector 17 Enterprise Arhitecture Assessment Framework (EAAF) [31] Grunden til at vi netop har valgt at kigge på disse modenhedsmodeller er at: a) der refereres til dem i litteraturen; b) de tilbydes af software producenter med erfaring på området; c) de tilbydes af konsulenthuse med erfaring på området; d) eller tilbydes af en uafhængig organisation. Hovedvægten er lagt på SOA modenhedsmodeller, mens en enkelt EA modenhedsmodel er blevet undersøgt, således at vi får et bredt indblik i modenhedsvurderinger Udvalgte modenhedsmodeller Vi har udvalgt en række modenhedsmodeller for at undersøge hvilke tilgange der findes til vurdering af modenhed. Modenhedsvurdering er en forholdsvis ny disciplin, og der er endnu ikke defineret en entydig måde at opbygge en model på. Vi vil derfor undersøge, hvad eksisterende modenhedsmodeller anser for at være den rigtige tilgang til vurdering af modenhed. Vi vil for hver enkelt model diskutere de gode og dårlige ting ved modellen. Disse diskussioner vil, i sammenhæng med de foregående afsnit i dette kapitel, være det primære input til modeludviklingen i kapitel Leverandør modenhedsmodeller Adskillige af de modenhedsmodeller vi har studeret bliver tilbudt af leverandører af software, hvilket gør, at man som læser bør tage et par forbehold til kvalitet af indholdet i disse modeller. Det meste fremstår i whitepapers, som ikke nødvendigvis har været under akademisk review. Man bør i denne sammenhæng, være specielt opmærksom på risikoen for, at modenhedsmodellen er rettet mod at munde ud i et specifikt produkt og dermed et potentielt salg. Vi går derfor ud fra, at det ikke absolutte sandheder, der står i sådanne modeller og white papers. Med det forbehold in mente, har leverandører ofte mange gode pointer og praktiske erfaringer, som man med fordel kan lære 17 Udleveret af Søren Peter Nielsen, ITST [4]

46 34 Kapitel 2. Eksisterende modeller og begreber af, således man kan minimere sine egne fejltrin. En yderligere udfordring er, at det er begrænset, hvad der er af akademisk litteratur på SOA modenhedsområdet, og endog også EA modenhedsområdet, da de fleste modeller og framework er blevet til ud fra praktiske erfaringer. Man kan formode, at i takt med, at der akkumuleres mere og mere SOA-erfaring rundt i verden, vil det akademiske niveau efterfølgende stige. Dette er en ikke uvæsentlig grund til at se nærmere på leverandørernes bud på modeller, idet de, alt andet lige, er dem med mest praktisk erfaring. Denne erfaring kan, over tid, danne grundlaget for en større akademisering af SOA modenhedsmodeller og SOA generelt. Dette vil vi selv forsøge at opnå, hvilket man kan læse mere om i kapitel 4. SOA Self-assessment Disse self-assessment tests er ikke, hvad vi umiddelbart forstår ved en modenhedsmodel. De er nærmere en form for temperaturmåling af, hvilke kompetencer der er i den forespørgende virksomhed, så udbyderen af self-assessment testen kan målrette sit marketingsfremstød. Fælles for de to test vi har fundet er, at man ikke kan tage testen uden at logge ind og tilkendegive sine kontakt og firma oplysninger 18. Testene er udformet som et web-spørgeskema, hvor respondenten for hvert spørgsmål har fire udsagn, hvor denne skal vælge det, der passer bedst til dennes virksomhed. Den endelige score bliver så beregnet udfra hvilke af de fire udsagn man vælger. SAP self-assessment test SAPs spørgeskema indeholder 19 spørgsmål, hvor der er fire muligheder, for at vælge det bedst passende udsagn til spørgsmålet samt en ved ikke mulighed. Essensen af spørgsmålene er at pejle, hvor vigtigt fleksibilitet er og hvor god virksomheden er til det. Derefter drejer spørgsmålene hen imod at få afklaret, om der er en governance struktur, om der dokumenterede forretningsprocesser, om man følger best practices, om IT har ledelsens bevågenhed, om er der er etableret faste forretningsgange for hvordan IT strategi hænger sammen med forretningsstrategi, og om der er et Program Management Office (PMO) etableret etc. Ud af de 19 spørgsmål, tolker vi, at 15 spørgsmål er rettet mod at få fastlagt, hvor langt man er kommet med EA i virksomheden. 18 Vi har naturligvis oprettet en dummy bruger og printet begge self-assesment testene ud, så man ikke behøver logge ind, men bare kigge på

47 2.4. Modenhedsmodeller og SOA 35 Af de fire resterende spørgsmål, er der tre, der er direkte rettet mod SOA, og et enkelt rettet mod at vurdere virksomhedens SAP installation i forhold til SOA. Afhængigt af hvilke statements man har valgt ved de respektive spørgsmål, gives der en samlet SOA modenhedsværdi, samt muligheden for at blive kontaktet af en SAP medarbejder. Det kan forekomme en smule underligt, at et spørgeskema omkring SOA indeholder så mange elementer af, det der ofte forbindes med EA. Af dette udleder vi, at SAP ser det som essentielt for SOA, eller Enterprise Service Architechture (ESA) som de kalder det, at en virksomhed har den grundlæggende EA tankegang og struktur på plads før man går i gang med SOA. Dette er vi iøvrigt helt enige i, jf. afsnit IBM self-assessment test IBMs spørgeskema er opbygget på nogenlunde samme måde som SAP s, men spørgsmålene er mere målrettede mod SOA. Denne test er efter IBMs eget udsagn, en light version af deres SIMM modenhedsmodel, se afsnittet om IBM SIMM. IBM har valgt at dele deres spørgsmål op i proces, arkitektur, applikation og infrastruktur. Der er fire spørgsmål til hver underopdeling med hver fire svarmuligheder. Spørgsmålene under process går på at få afklaret, hvor godt integreret SOA er i virksomheden, samt om der er beskrevne processer for udvikling i en SOA. Arkitektur spørgsmålene forsøger at afklare, hvor god en integration der er mellem applikationer, samt i hvor høj grad man er i stand til at genbruge services. Applikations spørgsmålene går primært på at få klarlagt, hvor god en kobling der er mellem IT systemer og forretningsgange, samt at klarlægge hvor veludviklet en governance struktur, der er i virksomheden. Derudover spørges der også ind til, om der findes et servicelag, hvor man kan finde og kombinere services, samt hvilken erfaring man har med integration af applikationer. Infrastruktur spørgsmålene drejer sig om, hvordan man udvikler sin infrastruktur og i hvor høj grad den indfrier krav fra forretningen. Derudover spørges der også, om der er en fælles sikkerhedsinfrastruktur og om det er muligt at måle på performance for anvendelsen af forretningsprocesser. De 16 spørgsmål munder så ud i en score, i stil med den for SAP, som giver en placering i en af fire modenhedsniveauer. Afhængigt af hvilket modenhedsniveau man lander i, anbefales der nogle entry points. Disse er de steder, som IBM mener er gode at starte med, hvis man vil forbedre sin SOA modenhed. IBMs spørgeskema giver klart udtryk for, at det er mere SOA orienteret end

48 36 Kapitel 2. Eksisterende modeller og begreber det fra SAP. Spørgsmålene er dog lige så svære at svare entydigt på, så nogen reel modenhedsvurdering mener vi ikke det giver. Vores betragtninger i forhold til Self-assessment Alt i alt fungerer IBMs self-assessment test udmærket til at pointere, hvilke områder IBM synes, der er mest vigtige i forhold til SOA implementering. SAP ser ud til at hevende sig til virksomheder, hvor EA ikke er veletableret, idet de fleste af deres spørgsmål virker som om, de søger at afdække EA modenhed. Generelt set synes vi ikke denne form for test er specielt anvendelige, da spørgsmålene er meget overordnede. Derudover anvendes der ikke entydige begreber, hvilket gør at spørgsmål kan tolkes forskelligt. Vi mener derfor, at man ikke kan tale om en modenhedsvurdering af en virksomhed. At netop dette er tilfældet, overrasker dog heller ikke, da det ville være utroligt at kunne afdække en virksomheds modenhed ud fra spørgsmål. Derfor er det mere interessant at kigge på de lidt mere detaljerede modenhedsmodeller. IBM SIMM IBM har udviklet denne modenhedsmodel på baggrund af mange års erfaringer med SOA projekter rundt om i verden. Baseret ud fra disse erfaringer har IBM kunnet identificere en række fælles punkter, der giver problemer i implementering af SOA og har derfor forsøgt at sammensætte nogle mønstre for, hvordan man bedst kontrollerer en SOA implementering [30]. IBM sammenligner disse mønstre med de retningslinier, piloter modtager fra flyveledere under indflyvning til en lufthavn. IBM har defineret syv niveauer af modenhed, som er bestemt ud fra graden af fleksibilitet og løs kobling, der kan opnås på hvert niveau. Der skal efter sigende findes en dybdegående gennemgang af alle modenhedsniveauerne i IBMs model, men den er umiddelbart ikke frit tilgængelig, da det sikkert er en konkurrenceparameter for IBM. Derimod har vi kunnet finde en kort præsentation af, hvad der forstås ved de enkelte niveauer, samt en illustration af modenhedsmodellen, se figur 2.2 (p. 37) [32]. Level 1 Her har virksomheden propritære applikationer, hvor disse intergreres adhoc. Dette gør at arkitetkturen bliver skrøbelig ved ændringer. Level 2 Virksomheden bevæger sig, på dette modenhedsniveau, mod en form for

49 2.4. Modenhedsmodeller og SOA 37 Figur 2.2: Service Integration Maturity Model EAI 19. Denne integration er skræddersyet til de enkelte applikationer og opnås ved hjælp af propritære connectors og integrationspunkter. Level 3 På dette niveau er virksomheden begyndt at renovere deres applikationsportefølje i moduler og komponenter, med klart definerede afgrænsninger. Integrationen mellem komponenterne opnås gennem deres interfaces og deres indbyrdes kontrakter. Level 4 Her påbegynder virksomheden de tidlige skridt mod SOA, hvor de påbegynder arbejdet med at definere services og udbyder dem internt eller eksternt i virksomheden. Level 5 Her øger virksomheden sin indflydelse i værdikæden og i økosystemet, hvor services er genstand for en kontrakt mellem service consumer, service provider og broker, som frit kan danne deres eget økosystem. Level 6 Virksomheden afvikler deres applikationer på en virtualiseret infrastruktur. Man når dette niveau, når man har af-koblet applikationen, dens services, komponenter og flows. Level 7 19 Enterprise Application Integration forkortet EAI er brugen af software og valg af softwarearkitektur for at få flere softwarebaserede systemer til at udveksle data med hinanden.

50 38 Kapitel 2. Eksisterende modeller og begreber Virksomheden har nu en dynamisk og re-konfigurerbar software arkitektur. Den kan sammensætte services ved runtime ved hjælp af policy beskrivelser, management og monitorering. Måden en virksomhed kan opnå disse forskellige niveauer af modenhed er illustreret i figur 2.3 (p. 38) [30]. Som ses på figuren forventer IBM at SOA adoptionen starter på et ad hoc niveau, hvor tiltag kan være små pilotprojekter o.l. IBM forventer at SOA lige så stille vil dryppe videre ud i virksomheden, for til sidst at være dryppet helt ud i det omkringliggende økosystem. Figur 2.3: IBM scope of adoption Vores betragtninger i forhold til modellen En pudsighed ved SIMM er, at det først er fra Level, 4, at der er tale om en SOA modenhedsmodel. Dog er der ingen tvivl om at de tre forgående levels er nødvendige for at kunne få succes med SOA. For at være en SOA modenhedsmodel burde de tre første niveauer nok nærmere være benævnt som forudsætninger for at tale om SOA og ikke som en del selve SOA modenhedsvurderingen. Derudover har IBM valgt at betragte SOA modenheden ud fra 7 views, som ses langs y-aksen på figur 2.2 (p. 37). Ved skæringen mellem niveau og view, skulle der være en detaljeret beskrivelse af, hvad der

51 2.4. Modenhedsmodeller og SOA 39 er indeholdt i kvadranten, men de beskrivelser er, som tidligere nævnt, ikke umiddelbart til at få fat på. Det ser dog ud til, at IBM har løsnet grebet lidt om deres SIMM, da de har indgivet den til The Open Group, sandsynligvis med henblik på at få den accepteret som en standard model. The Open Group har valgt at kalde deres model Open Group Service Integration Maturity Model (OSIMM ) [32]. Der er nedsat en arbejdsgruppe, som arbejder med OSIMM, men der er endnu ikke blevet publiceret noget nyt fra dem. Der er i et referat [32] blevet diskuteret, om der skal tilføjes et ekstra view omhandlende management, hvilket kan indikere, at det er ret begrænsedede ændringer, der er tale om. Vejen til SOA adoption, som IBM foreskriver, forekommer en smule usikker. Hvis man skal følge denne laissez-faire tilgang til SOA, risikerer man, enten at der intet sker eller at det bliver det rene anarki. Det kan godt være, at SOA ved denne adoptionsstil vil vinde stort indpas hos udviklere og fremsynede ledere, da de har stort set frie hænder. Vi tror ikke på, at man vil finde en optimal SOA ved en sådan tilgang, da en klar risiko er, at pilotprojekter, over tid, bliver udvidet til at være den gældende SOA for hele virksomheden. Sonic Software SOA Maturity Model Denne modenhedsmodel er sammenstillet af Sonic Software og er baseret på Software Engineering Institute (SEI) CMMI framework 20, diverse SOA relaterede artikler fra Forrester Research samt erfaringer fra deres kunder. Sonic [28] har skævet en hel del til måden CMMI frameworket er opbygget på, og de har endda mappet CMMI s niveauer til deres egne. Dette har IBM også gjort med deres SIMM model, hvilket dog ikke har den store betydning, da CMMI s framework, ifølge IBM [30] er så overordnet beskrevet, at det er forholdvis simpelt at mappe SIMM til CMMI. Hvorom alting er, så har Sonic også mappet deres model til CMMI og denne mapning kan ses på figur 2.4 (p. 40) [28, p. 9]. I det efterfølgende, vil der kort blive forklaret, hvad Sonic Software ser indeholdt i de forskellige niveauer. Vi har dog udeladt at kigge nærmere på de produkter, som Sonic Software mener ville kunne være indeholdt i de respektive niveauer. 20 Capability Maturity Model Integration (CMMI) CMMI er en tilgang til procesforbedring der hjælper en virksomhed med at få effektive og sammenhængende processer. I deres CMMI model er der 5 niveauer af modenhed, som vurderes ud fra niveauet af processtyring [33].

52 40 Kapitel 2. Eksisterende modeller og begreber Figur 2.4: Sonic Software Maturity Model 1. Initial Services Fokus for dette niveau ligger på, at virksomheden danner sig de første erfaringer med SOA gennem mindre projekter. Disse projekter er som regel baseret på et behov for ny funktionalitet, som man så forsøger at dække ved at anvende ny teknologi. Herved optjenes der i virksomheden erfaring med at udvikle SOA applikationer, samtidigt med at et forretningsbehov bliver dækket. 2. Architechted Services Baseret på erfaringerne fra det foregående niveau, bliver der her specificeret hvilke standarder, infrastruktur o.l. der skal anvendes i fremtidig udvikling. Dette arbejde ledes typisk af en arkitektur afdeling Business and Collaborative Services Fokus for denne fase er på koblingen mellem IT og forretning, der skal sikre, at der er sammenspil mellem de to dele af organisationen. Værdien i denne fase er, at sikre at der er en klar kobling mellem forretningsprocesser og de understøttende services. Der er i følge Sonic to retninger man kan væl- 21 krav til denne organisation er ikke nærmere specificeret.

53 2.4. Modenhedsmodeller og SOA 41 ge, som begge opfylder kravene til niveau 3. Ved fokus på business services, ligger fokus på forbedringen af forretningsgange internt i virksomheden. Collaborative services medfører at fokus ligger på at forbedring af de eksternt rettede processer der berører den omkring værende værdikæde. 4. Measured Business Services Som titlen måske giver en ide om, så er fokus for dette niveau at virksomheden skal måle og skabe overblik over de services og processer der blev implementeret på det foregående niveau. Disse målinger skal anvendes som feedback på performance og indvirkning på forretningen - altså hvor meget de bliver anvendt og hvor godt de performer. 5. Optimized Business Services Baseret på målingerne i niveau 4 kan den Service Orienterede Arkitektur optimere sig selv, baseret på regler og policies, således at forretningen altid anvender optimerede og opdaterede services 22. Vores betragtninger i forhold til modellen Umiddelbart forekommer Sonic Modenhedsmodel at have en fornuftig opbygning. Vi undrer os dog over måden de har valgt at konstruere niveau 3 på. Selve ideen i, at man kan holde de eksterne og interne processer adskilt, forekommer ufornuftig, da man jo gerne skulle se alle processer i et stort hele, for at have den maksimale og fleksible anvendelse af både interne og eksterne services. Hvis ikke man holder sig dette for øje kan man riskere at ende op med redundante services og derved ikke optimere genbruget af services, som er en af kernepunkterne i SOA, jf. punktopstilling på side 21. Man kan antage, at denne ulogiske opdeling måske skyldes, at Sonic har to produkter, der matcher netop den opdeling. Uanset hvad bevæggrunden er, så synes vi ikke man kan tale om enten interne og eksterne processer, idet de gerne skulle hænge sammen. Sonic tager også udgangspunkt i, at virksomheder skal starte med små projekter og derfra udvikle en større plan for arkitekturen. Sonic har i modsætning til IBM udspecificeret behovet for en fælles arkitektur allerede på niveau 2. Vi mener dog stadig, at der er en risiko for en sub-optimal arkitektur, som nævnt p Sonic giver et eksempel på dette ved at tage udgangspunkt i Dell. Hvis der på Dells lager er ved at være få standard harddiske tilbage, så ville man kunne foretille sig, at et slagtilbud på en anden type harddisk vil blive præsenteret på hjemmesiden.

54 42 Kapitel 2. Eksisterende modeller og begreber BPTrends BPTrends er et analysefirma, der leverer nyheder og informationer relateret til Business proces change [34]. I den forbindelse har de også fået udarbejdet en SOA modenhedsmodel. Forfatterne bag modenhedsmodellen er begge ansat hos WiPro Technologies [35], som er leverandør af forretningssoftware. De er i øvrigt, efter eget udsagn, de første til at opnå CMMI level 5 certificering. BPTrends model er udarbejdet efter forfatterne har studeret en række af andre modeller på markedet, blandt andet IBM s SIMM, se p. 36. BPTrends har fremstillet en temmelig forvirrende figur [29], for at illustrere deres SOA modenhedsmodel, se figur 2.5 (p. 42). Figur 2.5: BPtrends SOA Maturity Model I figur 2.5 (p. 42) er implementeringen af SOA set ud fra 5 forskellige aspekter, hvilket gør selve figuren lidt uoverskuelig. Man starter sin SOA rejse i nederste venstre hjørne og bevæger sig over tid mod øverste højre hjørne.

55 2.4. Modenhedsmodeller og SOA X-aksen repræsenterer scopet for virksomhedens SOA, som øges over tid. 2. Y-aksen repræsenterer modenhedsniveau og kan sammenlignes med de tilsvarende niveauer i Sonics model p Derudover har forfatterne tilføjet en vurdering af, hvorvidt SOA anstrengelserne er cost effective og feasible (de skraverede trekanter langs hhv. x- og y- aksen). Hvordan de helt præcist vurderer, om det enten er cost effective eller ej, er dog lidt tyndt beskrevet i dette whitepaper, så man skal nok ikke lægge meget mere i de termer end en smule sund fornuft (niveau af genbrug kontra udbredelse af SOA). Nogle reelle økonomiske betragtninger bliver i hvertfald ikke tilbudt. Som en forlængelse af disse antagelser, kommer man også med 4. en overordnet antagelse om at ROI, sådan nogenlunde vil følge den 45 graders linie der ligger midt i figuren. Heller ikke her bliver der tilbudt nogen økonomisk beregning. 5. Den sidste dimension er SOA expansion stages, som indikerer at jo længere man når i sin SOA adoption i virksomheden, så får man brug for forskellige softwareløsninger til at styre processen (hvilket er det WiPro Technologies leverer). Det interessante ved denne model er dog, at BPTrends modsat IBM, har vedlagt en beskrivelse af de aktiviteter og artefakter, som de forventer man skal udarbejde for at bevæge sig mod et højere niveau af SOA modenhed. Dette har de også mappet ind i deres modenhedsmodel, se figur 2.6 (p. 44) [29, p.11], hvilket giver en god forståelse af, hvad de mener kan bringe virksomheden videre til næste niveau af modenhed. Hver enkelt af disse aktiviteter, der er mappet ind på førnævnt figur, er også kort beskrevet i [29, p ]. Vores betragtninger i forhold til modellen BPTrends modenhedsmodel kan anvendes til at give øjebliks billede af AS- IS situationen samt anvendes til ligge en plan for hvordan virksomheden kommer fra AS-IS til TO-BE [29, p. 1]. BPTrends kommer frem til et begreb, de betegner som en hybrid modenhedsmodel. Vi mener, at man lige så godt kan betragte modenhedsmodellen og processen som to separate begreber, da det, efter vores overbevisning, ikke giver nogen værdi at blande begreberne sammen. Modenhedsmodellen mener vi ikke bringer noget nyt til bordet,

56 44 Kapitel 2. Eksisterende modeller og begreber Figur 2.6: BPtrends SOA Maturity Model and Process udover nogle lidt udefinerede økonomiske betragtninger, som vi mener, de enten burde have underbygget noget bedre eller helt have udeladt. Det vi mener, BPTrends kan bidrage med er, måden de har opbygget deres hybrid model på. Hele ideen med at beskrive hvilken proces de lægger til grund for at tale om SOA modenhed, virker meget fornuftig, specielt når man tænker på, hvor mange forskellige definitioner der findes på SOA, jf. afsnit Vi havde helst set, at de havde holdt processen og modenhedsmodellen adskilt, da det ikke giver umiddelbar mening at blande et dynamisk og et statisk begreb sammen Uafhængige modenhedsmodeller Efter en lille præsentation af det lille udvalg af kommercielle modenhedsmodeller, vil vi nu kigge lidt på et par modeller, som vi har valgt at betegne som uafhængige modenhedsmodeller. Grunden til dette er at vi ser disse som værende uafhængige af leverandører og som sådan ikke afhængige af, at de skal passe ind i en leverandørs portefølje af produkter.

57 2.4. Modenhedsmodeller og SOA 45 CBDI Forum CBDI Forum er en research afdeling i EVERWARE-CBDI, som er et uafhængigt konsulenthus specialiseret i EA og SOA. CBDI Forum udarbejder undersøgelser og rapporter omkring SOA best practises, blandt andet for Ministeriet for Videnskab, Teknologi og Udvikling (MVTU). MVTU har bestilt en række undersøgelser hos CBDI-Forum og en af dem er en modenhedsmodel rettet mod at vurdere SOA adoption i den danske offentlige sektor[36]. CBDI berører, som den eneste af de modeller der er repræsenteret i dette kapitel, definitionspløret omkring hvad der hvad, med hensyn til roadmap og modenhedsmodel. CBDI definerer forholdet mellem de to begreber således: Part of the problem is a failure to understand the difference between a maturity model and a roadmap. While a roadmap is (or at least should be) a practical template plan, based on a consolidation of experience from many organizations, a maturity model is a more theoretically grounded framework, based on a logical analysis of capabilities and their dependencies. [37] Ikke overraskkende er det også dette, deres modenhedsmodel giver udtryk for, idet den definerer fire faser, samt præsenterer en række kapabiliteter eller færdigheder, som en virksomhed skal bestride. Som en af de få, er CBDIs modenhedsmodel ikke blevet illustreret med en meget avanceret og sigende figur. De har nærmere holdt sig til KIS(S) princippet 23 og har i stedet blot opstillet fire punkter som repræsenterer deres modenhedsniveauer[38]. 1. Early Learning 2. Integration 3. Reengineering 4. Maturity CBDI har ikke gjort det helt store nummer ud af at forklare, hvad de mener med de respektive niveauer, men har i stedet brugt energien på at få opstillet en liste over de kapabiliteter, som en virksomhed skal være i besiddelse af for at befinde sig på det ene eller andet niveau. Denne liste kan sammenlignes 23 Keep It Simple (S...)

58 46 Kapitel 2. Eksisterende modeller og begreber lidt med den liste som BPtrends (afsnit p. 43) tilbyder. I stil med IBM s model (figur 2.2 (p. 37)), har CBDI valgt at opdele deres model i noget de kalder strømme, hvilket tildels kan sammenlignes med de vandrette rækker i figur 2.2 (p. 37). CBDI illustrerer det i figur 2.7 (p. 46) [36, p. 11]. Figur 2.7: CBDI Maturity Model Streams Til hver af strømmene er der lavet en liste af kapabiliteter, der bliver mappet til de førnævnte 4 modenhedsniveauer. CBDI har, efter eget udsagn [38, p. 17], en mere proces rettet tilgang til modenhed end mange af de andre modeller, der er tilgængelige. Processen og den rækkefølge en virksomhed skal udvikle sine SOA kapabiliteter er yderst vigtige, idet kapabiliteterne kan have indbyrdesafhængigheder. Hvilke afhængigheder der er imellem den lange liste af kapabiliteter, de selv har listet op, er de dog ikke gået i dybden med. Dette skyldes sandsynligvis, at afhængighederne varierer fra virksomhed til virksomhed og deres model på nuværende tidspunkt ikke er blevet anvendt og kommenteret nok til, at sådanne kan fastsættes med sikkerhed. Det bliver spændende at se om der kommer en afklaring på dette inden for den nærmeste fremtid. Som et led i at indarbejde erfaring i modellen, bliver den blandt andet overvejet som brugbar model for ITST [4].

59 2.4. Modenhedsmodeller og SOA 47 Vores betragtninger i forhold til modellen Vi synes godt om CBDI s tilgang til modenhedsmodeller, specielt fordi man ikke har oplevelsen af, at modellen er blevet designet med henblik på at ramme et specifikt produkt. Derudover virker fokusset på at definere de kapabiliteter eller færdigheder en virksomhed skal opbygge og deres indbyrdes afhængighed meget fornuftigt, da det helt sikkert vil give en mere håndgribelig ide om, hvad der skal til for at opnå en bedre SOA modenhed. Så kan man altid diskutere om det er de rigtige færdigheder de har peget ud. Dette vil sikkert blive afklaret, når der bliver indarbejdet noget mere praktisk erfaring i modellen. Vi kan specielt godt lide deres definition af forholdet mellem modenhedsmodel og roadmap, hvilket er den definition der vil blive anvendt i dette speciale. EAAF Enterprise Architechture Assessment Framework (EAAF ) er et EA modenhedsværktøj, der er udviklet specifikt til at måle graden af modendhed af det amerikanske Federal Enterprise Architechture program (FEA). For at kunne anvende EAAF, finder vi det nødvendigt kort at ridse op, hvad FEA egenlig drejer sig om. FEA: Bag FEA står en række amerikanske offentlige institutioner, der med The Office of Management and Budgets (OMB) i spidsen, har udviklet en segmenteret EA for hele den amerikanske stat. Arbejdet med FEA begyndte i 2002 [39] og havde til formål at forbedre blandt andet tværinstitutionelle forretningsgange, informationsdeling og bedre udnyttelse af budgetter. Endemålet for FEA hvis man kan tale om det i en sammenhæng, hvor man aldrig bliver færdig er at opnå en kunde/borger centreret offentlig sektor, der understøtter opgaverne bedre ved at maksimere udbyttet af teknologi investeringerne. Nøgleordene eller principperne 24 bag FEA tilgangen er: Business Driven FEA skal være ensrettet med forretningens strategi og mission. Proactive and Collaborative across federal government Indarbejdelse af FEA sker ved aktiv deltagelse i udviklingen af og anvendelsen af EA ansvarlige. 24 Disse kan sammelignes med de principper der er nævnt i Hvidbogen [20]

60 48 Kapitel 2. Eksisterende modeller og begreber Architecture improves the effectiveness and efficiency of government information resources Ingen investeringer kan foretages uden at det kan begrundes i forretningsarkitekturen. FEA benytter sig af en arkitektur, som OMB kalder segmenteret arkitektur, illustreret i figur 2.8 (p. 48) [40, p.3]. Som det kan ses på figuren, ses EA som Figur 2.8: FEA Segmentet Arkitekture den overordnede arkitektur og segmentet som en specifik arkitektur for en LOB 25. Sammenhængen mellem den overordnede EA og de respektive segmenter styres ved hjælp af en række reference arkitekturer, se figur 2.9 (p. 49) [40, p. 4]. De enkelte reference arkitekturers indbyrdes sammenhænge kan ses i figur 2.9. Sammenlagt fungerer referencemodellerne, som et framework op imod hvilket, man kan vurdere en enterprise [41, p. 5]. Det vil sige, at samlingen af referencemodeller fungerer som et regelsæt for, hvordan de enkelte segmenter må se ud. Hvordan arkitekturen helt specifikt kommer til at se ud, afhænger af de enkelte segmenter, men de skal alle overholde og begrundes ud fra de respektive referencemodeller. Identifikationen af de enkelte segmenter bliver foretaget ud fra den enkelte enterprises aktiver, som bliver holdt op mod de respektive reference modeller. Forløbet for identifikation af LOB ses i figur 2.10 (p. 49) [40, p.7]. OMB har identificeret 3 kategorier af segmenter, som de mener er beskrivende for de fleste enterpriser. Core mission Areas er det serviceområde som gør 25 Line Of Business - forretningsenhed

61 2.4. Modenhedsmodeller og SOA 49 Figur 2.9: FEA Reference Model Figur 2.10: FEA Segment Identification

62 50 Kapitel 2. Eksisterende modeller og begreber LOB unik og reelt set er dennes grundlag for eksistens. Derudover er der også Common Business service, der definerer de støtte funktioner, som er nødvendige for at LOB en kan udføre sit formål. Slutteligt er der Enterprise services, som går på tværs af hele enterprisen. EAAF: EAAF modenhedsmodellen består af et regneark, hvori der er en lang række spørgsmål. Disse spørgsmål er delt op i tre kategorier, hhv. Completion, Use og Results, hvor der angives fem udsagn til hvert spørgsmål. Afhængigt af de enkelte statslige institutioners modenhed, kan man vælge udsagn 1-5, hvor 5 er den mest modne 26. Derudover, opfordres der til, at man vedlægger links eller henvisninger til, hvor OMB kan finde dokumentation der underbygger den valgte modenhed. Ved evalueringen understreges det, at man kun er på modehenhedsniveau 3, hvis man også opfylder alle krav for modenhedsniveau 1 og 2. Afhængigt af hvilke selektioner der foretages ved udfyldningen af regnearket, beregnes der en overall score for FEA modenhed. Vores betragtninger i forhold til modellen Generelt set synes vi at FEA modellen er en meget interessant måde at anskue EA på, da der helt sikkert vil komme et stort fokus på koblingen imellem forretning og IT. Denne kobling er nærmere defineret i en række referencemodeller, som kan/skal inddrages på forskellige niveauer i EA beskrivelsen. Hvis ellers man har formået at få beskrevet de respektive referencemodeller på et passende niveau, er det i vores øjne, et fremragende værktøj til at kommunikere og styre EA ud i store komplekse organisationer. Modenhedsmodellen er også fornuftigt bygget op, men er ikke noget spektakulært, da det blot er en række kriterier baseret ud fra referencemodellerne. Vi synes dog at koblingen af EAAF og FEA giver et meget godt grundlag for at vurdere modenhed, uanset om man taler EA eller SOA. Spørgsmålene i EAAF er dog en anelse overordnede, og man ville med fordel kunne opdele dem i mindre og mere specifikke spørgsmål. Dette behøver dog ikke nødvendigvis at blive gjort, da det helt specifikt afhænger af, hvor detaljerede og de enkelte referencemodeller er. Problemet med FEA og EAAF er, at alt er baseret på referencemodellerne, hvilket mere eller mindre sætter EAAF ud af spil som en generel EA modenhedsmodel. 26 I samme stil som ved self-assessment testene p. 34, men her rettet specifikt mod FEA framework (og dermed mere grundige og entydigt anvendelige).

63 2.5. Delkonklusion Delkonklusion Grundet de mange forskellige definitioner af SOA, var vi nødsaget til at definere klart, hvad vi mener med SOA. Vi har derfor, i starten af dette kapitel, diskuteret hvad der kan forstås ved begrebet SOA, og ud fra en række definitioner sammensat vores egen definition af SOA. Denne definition er gældende for resten af dette speciale. For at få definitionen brudt op i nogle mere operationelle begreber, har vi kigget på hvilke arkitektur principper, der kan indfri de løfter som SOA sætter i udsigt. Med en eksplicit definition af SOA og SOA principperne i bagagen, har vi og læsere en fælles forståelse for hvad der fremover menes, når står SOA i dette speciale. Vi har derudover diskuteret SOA i sammenhæng med to andre begreber, nemlig EA og SOA økosystemer. Som vi ser det, er SOA tæt knyttet til EA, da EA er et godt fundament at bygge SOA på. SOA derimod, er kun en af mange arkitekturer som kan være indeholdt i en EA. Begrebet økosystemer er lånt fra biologiens verden, hvor det beskriver et organisk system med organismer, der alle er forbundet og afhængige af hinanden. Dette forhold giver nogle fordele, når det går godt for økosystemet, men giver ulemper, når det ikke går så godt. Problemet med organiske økosystemer er, at det er svært at træde ud af dem. Virksomheder deltager alle i en række forskellige økosystemer, som deler en række fælles kendetegn med de organiske. Fordelen er dog, at virksomheder kan bryde den tætte kobling til deres økosystemer, hvis de anvender SOA principperne i deres økosystemer. Kernen i de økosystemer en virksomhed indgår i, er gnidningsfri kommunikation. For at denne kommunikation kan lykkes, defineres der nogle servicemodeller for økosystemerne. Disse servicemodeller skal kobles løst til hinanden, for ikke at havne i samme situation, som de organiske. Herefter undersøgte vi en række modenhedsmodeller, hvor de stærke og svage sider blev diskuteret for hver enkelt. Fælles for modellerne er, de alle forsøger at opstille et antal metoder, til at måle i hvor høj grad en virksomhed er klar til SOA. Metoderne er på nogle områder forskellige og på andre områder meget ens. Et gennemgående træk for alle modenhedsmodellerne, er at de alle tager afsæt i teknikken, og at virksomheder skal starte med at få erfaringer igennem pilotprojekter. Efter man har opnået en række færdigheder, kan man så begynde at planlægge sin arkitektur. I SOA modenhedsmodellerne tager man ikke højde for, at man ved den manglende planlægning af arkitekturen risikerer at få implementeret en række sub-optimale arkitekturer. Det vil sige at pilotprojekterne vokser op og bliver gældende arkitektur, hvorved man risikerer at stå i samme infleksible situation som man forsøger at komme

64 52 Kapitel 2. Eksisterende modeller og begreber ud af. I enkelte af modellerne bliver økosystemer inddraget på de højeste modenhedsniveauer. Ydermere forundres vi over, at der angives en lang række forventede forretningsmæssige fordele ved SOA, men alligevel tager alle SOA modenhedmodellerne udgangspunkt i teknikken. Og dette uden egentlig at planlægge, hvordan de forretningsmæssige gevinster egentlig skal komme i hus. Det ser ud til at de fleste SOA modenhedsmodeller er konstrueret ud fra devisen Når bare teknikken virker, så kommer alt det andet af sig selv. Dette mener vi IKKE er tilfældet. Vi mener, at der er mulighed for at konstruere en bedre SOA modenhedsmodel, der ikke tager udgangspunkt i de tekniske detaljer, men fokuserer mere på, hvad det er forretningen kan få ud af SOA, samt give en metode til at bearbejde kompleksiteten i at opnå dette. Vi vil i det efterfølgende kapitel 4 argumentere for og beskrive en sådan model, som tager udgangspunkt i de begreber og modeller, der er beskrevet i dette kapitel.

65 53 Kapitel 3 Redegørelse for virksomheden forsvaret Som beskrevet i kapitel 1 vil vi anvende forsvaret som case. Dette kræver en redegørelse for, hvordan forsvaret er opbygget og hvilke opgaver man har. Det sker endvidere for at kunne gennemføre og vise den dataindsamling, vi har foretaget gennem de interviews, vi har gennemført, samt de kilder vi har fået adgang til. I dette kapitel vil vi derfor beskrive forsvaret som institution i det offentlige statsapparat, dels for at få beskrevet forsvarets kerneopgaver og dels for at beskrive den omverden man opererer i. Dette opnås gennem en beskrivelse af forsvarets organisation og dernæst de visioner og strategier man har for forsvarets virke. Dernæst fremlægges forsvarets direktiver for IT-området og hvordan og hvorfor man arbejder imod at anvende en serviceorienteret arkitektur tilgang. Sidst i dette kapitel vil vi fremlægge nogle af de tiltag forsvaret har gjort med henblik på implementering af EA og SOA. Resultaterne vil blive anvendt sammen med resultaterne fra kapitel 4 til at undersøge forsvarets SOA modenhed, samt trykprøve modellen i kapitel Forsvarets organisation Opgaverne til forsvaret 1 er som beskrevet i [44] at skabe fred og sikkerhed for Danmark. Dette er blandt politikkere (og dermed i befolkningen) blevet 1 Informationerne i afsnit stammer hovedsageligt fra [42] og [43] om Forsvaret.

66 54 Kapitel 3. Redegørelse for virksomheden forsvaret tolket i stadigt bredere forstand til at omfatte ikke blot suverænitetshåndhævelse af dansk territorium, men også indsættelse af styrker i international ramme for at forebygge krig og konflikter. Dette med det formål at fremme en fredelig udvikling i verden. Danmarks medlemsskab af North Atlantic Treaty Organisation (NATO), siden oprettelsen i 1949, har været med til at definere den danske udenrigs- og sikkerhedspolitik. Det danske forsvars rolle i NATO er til stadighed blevet prioriteret (når man ser bort fra fodnote-politikken i 1980 erne) ikke mindst efter de danske forbehold til Maastricht-traktaten, som gør at Danmark ikke deltager i det fælles udenrigs- og sikkerhedspolitiske samarbejde i EU (FUSP). Dette har medført en tilnærmelse til USA og Storbritannien med indsættelse af fælles styrker rundt om i verdens brændpunkter. Danmark indsætter og prioriterer endvidere styrkebidrag i rammen af FN og OSCE med henblik på, at deltage i fredsbevarende, fredsskabende og humanitære operationer. Det internationale engagement er vokset kraftigt siden afslutningen af den kolde krig. Her havde man en mere fastlåst situation og der var langt mere fokus på øst-vest konflikten, så det danske forsvar var i overvejende grad fokuseret mod territorialforsvaret af Danmark. Musketér eden fra NATO s charter, artikel 5 [45] foreskriver at medlemslandende vil komme hinanden til undsætning, hvis et land bliver angrebet. Article 5 The Parties agree that an armed attack against one or more of them in Europe or North America shall be considered an attack against them all and consequently they agree that, if such an armed attack occurs, each of them, in exercise of the right of individual or collective selfdefence recognised by Article 51 of the Charter of the United Nations, will assist the Party or Parties so attacked by taking forthwith, individually and in concert with the other Parties, such action as it deems necessary, including the use of armed force, to restore and maintain the security of the North Atlantic area. Udviklingen i sikkerhedspolitikken har gennem 1990 erne og særligt efter 11. september 2001 rettet sig mod bekæmpelse af diktaturstater og anslag mod demokratiet i form af terrorisme m.v. Forsvarets rolle i internationale styrker har medført et stigende behov for kommunikation og udveksling af informationer, hvilket den teknologiske udvikling har givet mulighed for. Dette vil vi vende tilbage til i afsnit 3.4. I næste afsnit gennemgås de forskellige myndigheder, som indgår i forsvaret

67 3.1. Forsvarets organisation 55 og hvad deres primære opgaver er. Dette gøres for at identificere, hvilke dele af organisationen, det kan være relevant og interessant at arbejde videre med i relation til IT systemer og SOA Forsvarets overordnede organisation Forsvarsministerens resortområde er illustreret i figur 3.1 (p. 55) [46]. Forsvarets Figur 3.1: Ministerområdets organisation organisation er opbygget med Forsvarsministeren som ansvarlig for hele resort området. Ministeriets opgaver er af politisk karakter og omfatter planlægning,

68 56 Kapitel 3. Redegørelse for virksomheden forsvaret udvikling, styring og kontrol af hele resortområdet. Når det kommer til at styre det militære forsvar vil en lang række af de mere lav-praktiske opgaver løses af Forsvarskommandoen (FKO) med reference til ministeriet. På ITudviklingsområdet f.eks. har ministeriet ikke sin egne IT-udviklingsafdeling, men må bero på at lade FKO komme med oplæg, som ministeriet dernæst kan godkende/tage i anvendelse [47]. Under ministeriet ligger FKO og et antal sideordnede myndigheder. Disse omfatter Hjemmeværnskommandoen, Forsvarets Efterretningstjeneste, Auditørkorpset, Farvandsvæsenet, Forsvarets interne revision, Beredskabsstyrelsen og Militærnægteradministrationen. I dette speciale beskrives disse myndigheder dog kun i det omfang, de er relevante for opgaven. Forsvarsministeren er den politiske og administrative leder af disse myndigheder og er den højeste ansvarlige for alle opgaver. Men i praksis vil disse opgaver være delegeret til de underlagte myndigheder og i noget omfang også ansvaret 2. FKO er den praktisk udførende myndighed og foresat for hovedparten af forsvaret (idet ovennævnte sideordnede myndigheder i budget og antal udgør en marginal del 3 af det samlede budget for resortområdet). Under FKO hører de operative myndigheder og de funktionelle tjenester. Deres opgaver og struktur beskrives i det følgende: de operative myndigheder: Hæren med opgaverne at tage sig af det landbaserede forsvar af Danmark, at bidrage til at løse internationale opgaver i FN, OSCE og NATO ramme, samt evt. katastrofehjælp. Den overordnede myndighed i hæren er Hærens Operative Kommando (HOK) der står for uddannelse og indsættelse af hærens enheder. De operative enheder udgøres af dels de to brigader (1. og 2. brigade) som er dem, der uddanner soldater og løser de praktiske opgaver i ind- og udland og dels regimenter, som har til opgave at være støttestruktur for de operative enheder. Hæren har i de forløbne 15 år deltaget i internationale operationer på Balkan, i Eritrea, i Irak og senest i Afghanistan. 2 Idet dog det understreges, at ansvar selvfølgeligt ikke kan delegeres; det ligger alene hos ministeren, men i praksis kan denne godt uddele næser. 3 Ca. 3% af de godt 20 mia. DKr der årligt tildeles forsvarsministerens resortområde (2006- tal) jf. finansloven.

69 3.1. Forsvarets organisation 57 Søværnet har to primære opgaver; Den ene er håndhævelse af suverænitet i de danske farvande (incl. Færøerne og Grønland) med inspektionsskibe og kuttere og dertil eftersøgninger, miljøovervågning, forureningsbekæmpelse, isbrydning m.v. Den anden er, at Søværnet indgår i løsningen af de internationale opgaver med inspektionsskibe, til overvågningsopgaver, håndhævelse af FN-embargoer, patruljetjeneste, humanitære støtteopgaver samt støtte til egentlige kamphandlinger med transport af hærens materiel eller deltagelse i bekæmpelse af terrorisme. Søværnet er styret af Søværnets Operative Kommando (SOK) og under denne er fire eskadrer med de operative opgaver samt et antal myndigheder i støttestrukturen (flådestationer, marinedistrikter m.v.). Internationalt har Søværnet deltaget i den første golfkrig (i 1990), i Middelhavet i forbindelse med konflikterne på Balkan og i Mellemøsten og i den Persiske Golf i forbindelse med kampen mod terrorisme (den seneste Irak krig). Flyvevåbenet håndhæver Danmarks suverænitet i luften og overvåger dansk luftrum. Der løses en række civile opgaver såsom eftersøgnings- og redningstjeneste og transport at patienter. Hertil kommer de internationale opgaver som omfatter deltagelse i NATO/FN missioner. Flyvevåbenet består under Flyvertaktisk Kommando (FTK) af o- perative enheder i form af eskadriller med kamp- og transportfly samt redningshelikoptere og støttestruktur med flyvestationer og luftrumskontrol. Internationalt har flyvevåbnet været indsat på Balkan, i Irak og i Afghanistan. samt de lidt specielle Operative kommandoer for Grønland og Færøerne, der primært har med suverænitetshåndhævelse og inspektion at gøre. de funktionelle tjenester omfatter myndigheder, der løser de opgaver, man har defineret som værende fællesværns dvs. på tværs af de tre operative værn. De funktionelle tjenester har således til opgave at formidle støttefunktionerne til forsvarets øvrige myndigheder (inklusive hinanden): Forsvarets Personeltjeneste Forsvaret Personeltjeneste (FPT) blev som konsekvens af at man havde identificeret værnsfælles opgaver oprettet i 2005, hvor

70 58 Kapitel 3. Redegørelse for virksomheden forsvaret man sammenlagde de decentrale personelforvaltninger over hele landet til én central tjeneste med sæde på Holmen. FPT er underlagt Forsvarschefen og tager sig af personelmæssige forhold for alle medarbejdere i Forsvaret fra ansættelse (indkaldelse) til afsked (hjemsendelse). Opgaverne omfatter alt fra strategisk ledelse og policy over personel- og lønforvaltning og kompetenceudvikling til almindelige administrative opgaver. FPT løser disse opgaver for alle Forsvarets fastansatte civile og militære, værnepligtige, personel af reserven og Hjemmeværnets frivillige. Herudover løser FPT tilsvarende opgaver for Hjemmeværnskommandoen. Endelig har FPT ansvaret for centrale lønforhandlinger og lønaftaler samt løn- og pensionsadministration for alle Forsvarsministeriets øvrige styrelser [48]. En lang række af de opgaver FPT løser er IT-understøttet og underbygger dermed den centraliserede tankegang. FPT har ca. 620 medarbejdere. Forsvarets Materieltjeneste Forsvarets MaterielTjeneste (FMT ) er Forsvarets materielfaglige videnscenter og logistiske myndighed, der anskaffer, vedligeholder og videreudvikler materielkapaciteter samt sikrer forsyninger til rettidig støtte for Forsvarets operationer [49]. FMT er opstået som en sammenlægning af de tre værns materielkommandoer 4 samt dele af Forsvarets Forskningstjeneste (FOFT). FMT varetager alle opgaver i forbindelse med indkøb, produktion, modtagelse, opbevaring, udlevering, reparation og drift af materiel til Forsvaret. I samarbejde med FKO og de operative kommandoer vurderer FMT, hvad de udsendte styrker og det danske forsvar har brug for af materiel. Der gennemføres således også forskningsrelateret arbejde med henblik på at sikre, at fremtidens forsvar bliver materielmæssigt klædt godt på. I praksis sørger FMT for, at forsvaret materielmæssigt bliver drevet på en sikker og fornuftig måde. Dette betyder, at FMT har en stor rolle i IT-projekter, hvori der indgår operativ anvendelse. Samlet set vil FMT nå op på ca medarbejdere, når alle sammenlægninger er på plads den 1. januar Bygnings- og etablissementstjenesten Forsvarets Bygnings- og Etablissementstjeneste (FBE) er i praksis forsvarets vicevært. De står for vedligeholdelse og drift af alle forsvarets bygninger, kantiner, rengøring, arealpleje, affaldshåndtering m.m. og leverer således støtte til de operative myndigheders 4 Hærens (HMAK), Søværnets (SMK) og Flyvevåbnets (FMK) materielkommando.

71 3.1. Forsvarets organisation 59 (og de andre i støttestrukturens) fysiske rammer. Af IT-mæssige opgaver kan deres rolle i IT-infrastrukturen bemærkes. FBE er ansvarlig for at trække alle kabler, såvel strøm som net. FBE har ca medarbejdere fordelt over hele landet. Forsvarets Koncernfælles Informatiktjeneste Forsvarets Koncernfælles Informatiktjeneste (FKIT) blev etableret januar 2006 mhp. at implementere en IT driftsstruktur, der omfatter hele ministerområdet (koncernen). Dvs. ikke kun indenfor FKO område, men også ved FKO sidestillede myndigheder (jf. side 56). FKIT overordnede serviceydelser omfatter brugerstøtte, brugeradministration, arbejdsstationsservice, filprint og messaging service, datacenterservice, netværksservice, overvågning, service til koncernfælles tillægsprodukter og service til funktionsbestemte tillægsprodukter (dvs. hvis en eller få myndigheder har et IT-system, som godt nok ikke er værnsfælles, så kan opgaver mht. drift og opgraderinger alligevel ligge ved FKIT, såfremt dette aftales). Til støtte for FKIT kerneydelser varetages desuden en række funktioner såsom økonomistyring, personaleforvaltning (i tæt samarbejde med FPT) og leverandørstyring. FKIT er centralt placeret med ca. 250 medarbejdere i Avedøre. Hertil kommer ca. 15 virtuelle medarbejdere som er placeret ude ved myndighederne mhp. at kunne yde fysisk støtte ved problemkilden. Mere om FKIT i afsnit Ud over de her nævnte (FPT, FMT, FKIT og FBE, der er de fire største) er der endvidere Forsvarets Regnskabstjenste (der styrer al likviditet og regnskab i forsvaret), Forsvarets Mediecenter (der håndterer presse- og informationsopgaverne), Forsvarets Sundhedstjeneste (som håndterer alt om idræt og sundhedspleje (læger og tandlæger)), Forsvarsakademiet (der står for planlægning og gennemførelse af al værnsfælles videreuddannelse og forskning på lederniveau) og Forsvarets Rekruttering (der gennemfører rekrutteringsopgaver og står for sessionsbehandling m.v.) En enhed i internationale operationer Efter vi har beskrevet forsvarets overordnede myndigheder, vil vi beskrive en eksempelvis kampenhed, fra de operative myndigheder. Det er som oftest en type enhed, der forbindes med forsvaret, og det taler derfor for, at det

72 60 Kapitel 3. Redegørelse for virksomheden forsvaret er sådan en enhed vi kan bruge til den følgene analyse. De enheder, der er mest fokus på er de enheder, som er udsendt i internationale operationer (INTOPS) 5, som opererer i et multinationalt miljø, særligt sammen med NATO partnere (jf. afsnit 3.1 p. 53). Vi vil derfor beskrive en typisk enhed (hvis en sådan findes), der er udsendt. Valget falder naturligt på den danske bataljon (BTN) i det sydlige Afghanistan, da det er den største enhed Danmark for tiden har udsendt. Det er samtidigt en enhed, der har været meget fokus på i løbet af efteråret 2007 på grund af dens deltagelse i hårde kamphandlinger i den hærgede Helmand provins. Det vurderes at være de hårdeste kampe, danske enheder har deltaget i siden Den danske bataljon er en del af 6 ISAF (International Security Assistance Force) styrkens Regional Command South (RC(S)), der ledes af en britisk general med hovedkvarter i Kandahar. RC(S) består af flere kampgrupper, der modsvarer en dansk brigadestørrelse. ISAF opererer under et fredsskabende mandat i henhold til FN-Pagtens kapitel VII. ISAF er imidlertid ikke en FN-styrke, men en NATO-ledet koalition, der har soldater fra i alt 37 lande herunder 26 NATO-lande. Den samlede styrke er på ca soldater. Det er NATOs første Out-of-area operation, hvilket betyder, at det er første gang NATO opererer udenfor det umiddelbare ansvarsområde i Nordatlanten. Den overordnede opgave for ISAF er at hjælpe den afghanske regering med at udbrede og udøve kontrol over landet, så der skabes betingelser for stabilisering og genopbygning. Opgaverne udføres i tæt samarbejde med de afghanske sikkerhedsstyrker, og der ydes støtte og rådgivning til opbygning af den afghanske hær. Indsatsen gennemføres i samvirke med nationale, regionale og lokale politiske, militære og religiøse ledere samt ved samarbejde og koordination med andre internationale organisationer. Der er således mange samarbejdspartnere, der skal kommunikeres med og udveksles oplysninger med. Det danske styrkebidrag i de sydlige provinser er grundlæggende bygget op om den danske bataljon, der danner Battle Group Center, der indgår under den britisk ledede Task Force Helmand sammen med en Battle Group North og en Battle Group South. Task Force Helmand har soldater fra Storbritannien, Canada, Holland, Danmark, Estland og Tjekkiet. I den dansk ledede Battle Group Center indgår en række britiske enheder, så den samlede kamp- 5 International Operations. 6 Dette afsnit hidrører for hovedpartens vedkommende fra [50].

73 3.1. Forsvarets organisation 61 gruppe er oppe på omkring 800 soldater. Heraf er det danske bidrag ca. 550 soldater.. Den danske bataljon består af: En chef (oberst) og en stab Et stabs- og logistikkompagni, der indeholder enheder til forsyning, vedligeholdelse og reparationer samt sanitetspersonel, der både varetager ambulance- og redningstjeneste samt den almindelige lægetjeneste. En artilleripejleradarenhed, der blandt andet indsættes til sikring af lejrene, idet den kan lokalisere, hvorfra fjendtlige tunge våben skyder. Observatører der er i stand til at kommunikere med og dirigere ildstøtten fra kampfly og artilleri. En ingeniørenhed, der bl.a. vil kunne støtte lejrområderne og foretage minerydning. En elektronisk opklaringsenhed. En telegrafenhed, der skal sikre kommunikation mellem enhederne og hjem til Danmark. Et mekaniseret infanterikompagni, der kører i PMV M113 G3. En spejdereskadron, der kører i Eagle I. Et kampvognsdetachement med en kampvognsdeling på tre Leopard 2 A5. En militærpolitienhed, der skal støtte øvrige danske enheder og opretholde (selv-) justits i lejren. En Civil-militær samarbejdsenhed til identifikation og koordination af udvalgte genopbygningsprojekter. De primære opgaver for den danske bataljon er, at de skal gennemføre sikkerhedsog stabiliseringsoperationer. Opgaverne vil variere fra varetagelse af sikringsopgaver til egentlige kamphandlinger i form af enten selvstændig indsættelse eller som led i mere omfattende og bredspektrede sikkerhedsoperationer. De

74 62 Kapitel 3. Redegørelse for virksomheden forsvaret danske soldater bidrager også til at skabe og opretholde sikkerheden i indsættelsesområdet ved bl.a. at patruljere i lokalområdet og skabe et tillidsfuldt forhold til befolkningen. De primære kampenheder er det mekaniserede infanterikompagni (INFKMP) og spejdereskadronen, samt kampvognsdelingen (KVGDEL). Hertil kommer de britisk enheder under den danske kommando. Det er med disse styrker BTN primært løser ovennævnte opgaver. Resten af BTN (artilleri, ingeniører, telegrafenehd, m.v.) støtter løsningen af primæropgaverne. BTN opererer i et rum med allierede partnere og har derfor stort behov for kommunikation med disse. BTN har nogle IT-systemer til at understøtte dette, hvorfor vi vil vende os mod forsvarets IT-organisation og undersøge, hvordan styrkeindsættelsen understøttes af IT Forsvarets IT-organisation Opgaverne på informatik området blev tidligere opdelt i en operativ og en administrativ del. Disse var som regel ikke indbyrdes afhængige og omfattede groft sagt de systemer, der anvendtes i det operative miljø, dvs. ved enheder som kunne indsættes i kampopgaver (bredt formuleret), og de opgaver som anvendtes i støttestrukturen til at styre forretningen forsvaret, dvs. håndtering af løn, personale, bygninger, økonomi etc. Denne opdeling er ikke længere brugbar, idet IT (som i resten af samfundet) er blevet så integreret i den måde man løser sine opgaver på, at man nu har valgt en anden indgangsvinkel at gå væk fra silotankegangen. Ved at opdele opgaveløsning i kritiske og ikke-kritiske opgaver (jf. [6, min. 2:18]), har man samtidigt fået prioriteret sine opgaver. Der er dog stadigt en opdeling af systemer, som understøtter de to forskellige opgavetyper, men fokus er på om det er kritisk eller ej. Når en enhed sendes til f.eks. Afghanistan, er det ikke længere nok at se på, om deres systemer kan anvendes på den moderne kampplads (som eksempelvis våbensystemer eller kommunikationssystemer), men i lige så høj grad at se på om hele den administrative del, der omfatter en udsendelse, kan bringes frem til missionen i udlandet. Det er således kritisk for enheden, at man er i stand til at generere pakkelister, organisation, løn/ydelser m.v. som foregår i det administrative system, for overhovedet at komme af sted. Denne opdeling i kritiske/ikke-kritiske systemer har medført en fokusering på, hvem i forsvaret, der løser hvilke opgaver. Der er dog stadigt en opdeling af ansvaret for de forskellige typer af opgaver, idet FMT har ansvaret for IT-systemer, der

75 3.1. Forsvarets organisation 63 udelukkende anvendes til styrkeindsættelse eller uddannelse hertil, herunder i eller i tilknytning til våbensystemer. FKIT har så ansvaret for resten (se figur 3.2 (p. 64)). Som beskrevet i er det FKIT der er omdrejningspunktet i forsvarets administrative IT-organisation. Styringen foregår stadigt centralt fra dels F- KO via Udviklingsstaben (UV) og fra FMN (der jo i høj grad læner sig op ad UV på IT-området). Men, med den nye centraliserede tilgang til drift og udvikling, har man formået at samle ekspertise og knowhow i den nye tjeneste. Der er identificeret et antal opgaver, som stadigt løses decentralt, men hertil er allokeret enkelte funktioner, som løses ved de lokale myndigheder. Langt hovedparten af IT-opgaverne løses fra hovedkvarteret i Hvidovre. Opgaverne til FKIT har således været med til at definere organisationen. Som udbygning af informationerne om FKIT opgaver i afsnit kan anføres, at de definerede ansvarsområder til FKIT ifølge [51] er, at være ansvarlig for (for alle forsvarets myndigheder også de udsendte enheder): gennemførelse af IKT-virksomheden 7, herunder for fastlæggelse af de teknologiske og kommercielle rammer for anskaffelse af IKT-produkter og IKT-serviceydelser, standardisering og konfigurationsstyring, kontakt til leverandører, indgåelse af kontrakter, forvaltning samt IKT-faglig rådgivning af koncernens myndigheder. Ifølge [7] er FKIT er ansvarlig for følgende driftsmæssige opgaver: Forsvarets Interne Intranet (FIIN ) og øvrige infrastrukturydelser på netværket i from af data med klassifikation Til Tjenestebrug (TTJ) og op. 7 Informations- og kommunikationsteknologi. Bemærk at forsvaret konsekvent anvender betegnelsen IKT, idet man ser IT i rammen af både traditionel IT og i rammen af den nødvendige kommunikation, fordi denne ofte sker ad alternative kanaler (dvs. ikke via traditionel TCP/IP, men eksempelvis via satellit eller HF).

76 64 Kapitel 3. Redegørelse for virksomheden forsvaret Koncernfælles applikationer herunder mail, intranet, Office pakken, De- Mars 8, KESDH, XPOST og REGNEM 9 Web hoteller, filservere, og hoster myndighedsspecifikke applikationer på FIIN Myndighederne er selv ansvarlig for Myndighedsspecifikke applikationer Applikationer på Internettet. Figur 3.2: IKT ansvar i forsvaret Fordelingen af ansvar på IKT-området i forsvaret er illustreret i figur 3.2 (p. 64) [47]. FMT er ansvarlig for de operative applikationer, C3I 10 systemer samt applikationer der er en del af våben og materielsystemer. De operative 8 Forsvarets store ERP system fra SAP 9 KESDH: Koncernfælles dokumenthåndteringssystem; XPOST: terminalprogram til krypteret kommunikation; REGNEM: Regeringens krisestyringsnetværk til klassificeret kommunikation (Hemmeligt). 10 Command, Control, Communication and Information systems de systemer, der kan håndtere information og kommunikation på kamppladsen, samt at være med til at visualisere disse.

77 3.1. Forsvarets organisation 65 kommandoer er ansvarlige for at fastlægge og formidle brugende myndigheders behov for og krav til ydelser fra IKT-systemerne. Blandt C3I systemerne kan nævnes DACCIS 11, der er det system hæren bruger til at føre enheder fra BTN og op. DACCIS giver føreren mulighed i realtid for at overskue kamppladsen med egne og fjendens styrker (så meget man nu ved) ved hjælp af ikoner. DACCIS kan uddrage, gemme og kommunikere/replikere informationer, samtidig med at man har mulighed for at udvikle planer og udsende disse som ordrer via datalink over radio. Det primære formål er at have flere og hurtigere informationer end fjenden, og dermed komme denne i forkøbet. Ved at bryde ind i fjendens overvejelsescyklus og gøre det hurtigere, vil man tvinge fjenden til at være reaktiv på ens egen aktioner og det kan i sidste ende være det, som afgør kampen. Før indeværende forsvarsforlig havde man organisationen Forsvarets Forskningstjeneste (FOFT) underlagt Forsvarsakademiet denne er nu nedlagt, og hovedparten af ressourcerne er overført til FMT. Dette er i god overensstemmelse med FMT fokus på anvendt forskning til våbensystemer (jf. afsnit 3.1.1). FMT har således nu blandt andet ansvaret for introduktionen og forskningen i f.m. Netværks Baserede Operationer (NBO) 12. Dette er forankret i den sektion under FMT der hedder Anvendt forskning, hvor hovedopgaven er at se fremad. Sektionschefen er Gert Hvedstrup Jensen, der blev interviewet [53]. I denne sektion er fokus på udvikling af NBO og den mulige implementering i den operative struktur. Se figur 3.2 for en beskrivelse af de forskellige dele af forsvaret, der spiller en rolle i IKT-arkitekturen. Det er værd at bemærke at FMT har ansvaret for C3I og våbensystemer dvs. de elementer af IT, der bruges ved kampenhederne. Visionen for brugen af IT på fremtidens kampplads betegnes ofte som NBO. Det vil derfor være relevant at se på nogle af de forskellige definitioner af NBO. En af disse er f.eks. den amerikanske definition af Network Centric Warfare: Network-centric warfare (NCW), now commonly called network-centric operations (NCO), is a new military doctrine or theory of war pioneered by the United States Department of Defense. NCW/NCO seeks to translate an information advantage, enabled in part by information 11 Danish Army Command and Control Information System oprindeligt udviklet af Maersk Data Defence, nu overtaget af SAAB Defence. Se mere på [52] 12 Den amerikanske terminologi for NBO er Network Centric Warfare. NATO kalder det for NATO Network Enabling Capability (NNEC) - kært barn har mange navne. I dette speciale anvendes primært betegnelsen NBO, fordi det er den term det danske forsvar anvender.

78 66 Kapitel 3. Redegørelse for virksomheden forsvaret technology, into a competitive warfighting advantage through the robust networking of well informed geographically dispersed forces. This networking combined with changes in technology, organization, processes, and people may allow new forms of organizational behavior. Specifically, the theory contains the following four tenets in its hypothesis: A robustly networked force improves information sharing; Information sharing enhances the quality of information and s- hared situational awareness; Shared situational awareness enables collaboration and self-synchronization, and enhances sustainability and speed of command; and These, in turn, dramatically increase mission effectiveness. [54] Dette er jo en lang definition, der omhandler mange områder, heriblandt fokuseringen på informationsoverlegenhed. NBO handler altså om deling af information, kvalitet af informationerne og dermed bedre situationsbevidsthed. De delte informationer muliggør samarbejde og selvsynkronisering og giver hurtigere beslutningsprocesser under operationerne. NATO s indsats på NBO området kalder de selv for NATO Network Enabling Capability (NNEC). De definerer det således: NNEC is the Alliance s ability to integrate the various components of the operational environment, from the strategic level (including NATO HQ) down to the tactical levels, through a network of networks.[55] Dermed vurderer vi, at en dansk definition af NBO kunne være: Netværks baserede operationer omhandler en integration af sensorer, våbensystemer og beslutningsstøttesystemer, så de i størst mulig udstrækning kan optræde som et netværk af netværk. En central del af NBO er at alle systemerne optræder som en verden bestående af service udbydere og service brugere. [55, p. 13] hvilket minder om SOA principperne i afsnit og underbygger tanken om at SOA og NBO er nært beslægtede. Dette vender vi tilbage til i afsnit 3.4.

79 3.2. Forsvarets mission, vision og strategi Forsvarets mission, vision og strategi I dette afsnit vil vi først redegøre for den overordnede strategi og mission for forsvaret og dernæst for de mere specifikke strategier og missioner for ITstrukturen. Dette er for at undersøge om de overordnede opgaver i forsvaret afspejles i IT-strategien. Forsvaret er en gammel organisation med rødder langt tilbage i tiden. Ligesom i det øvrige samfund har man løbende måttet indrette sig på udviklingen på såvel det teknologiske, organisatoriske og samfundsmæssige område (jf. krigsførelsens kredsløb i afsnit 1.2). Forsvaret får i bund og grund sine opgaver fra den danske stat, udtrykt gennem folketinget og regeringen. Ser man helt overordnet på forsvaret, er det historisk set staten Danmarks middel til at kunne håndhæve sin nationale suverænitet og håndhæve sin udenrigspolitik. Som offentlig institution er forsvaret opgaver reguleret ved lov her Lov om Forsvaret [56]. I denne er beskrevet dels forsvarets formål 1: Det militære forsvar skal bidrage til at fremme fred og sikkerhed og som noget nyt efter afslutningen af den kolde krig i Europa i starten af 1990 erne at medvirke som et ( 2) væsentligt sikkerhedspolitisk middel med det formål at medvirke til at forebygge konflikter og krig, hævde Danmarks suverænitet og fremme fredelig udvikling i verden med respekt for menneskerettighederne. I lovens 3 er beskrevet, hvordan forsvaret skal være en integreret og forankret del af NATO. Med dette in mente udarbejder Forsvarsministeriet deres fortolkning og opgavenedbrydning så de kan formulere Danmarks forsvarsog sikkerhedspolitik og gøre denne tilgængelig for FKO, der så skal operationalisere politikken. Både forsvarsministeriet og FKO har udarbejdet både vision, mission og strategi. Forsvarsministeriets overordnede mision er: Arbejde for fred og sikkerhed og at skabe resultater, der bidrager til fred og sikkerhed og som anderkendes i ind- og udland.

80 68 Kapitel 3. Redegørelse for virksomheden forsvaret Der er hermed fokus på den militære gren af udenrigspolitikken, idet man skal anvende det danske forsvar aktivt til at positionere Danmark i internationalt regi og til at understøtte den valgte politik Forsvarskommandoens mission, vision og strategi Som alle andre store koncerner er forsvaret 13 nødt til at relatere sit virke til den virkelighed, det befinder sig i. Dette inkluderer naturligvis at arbejde med planlægning af fremtidige strategier for alle forsvarets opgaver. På alle niveauer vil der foregå et strategi arbejde for at kunne fremlægge de arbejdsopgaver, man forudser vil komme i fremtiden og ikke mindst for at gøre disse lettere 14 at håndtere. Ud fra direktiv fra FMN og Lov om forsvaret, kan opstiler FKO deres mission [44, p. 2]: Ved at kunne kæmpe og vinde fremmer Forsvarets soldater en fredelig og demokratisk udvikling i verden og et sikkert samfund i Danmark. 15 Missionen bliver det styringsværktøj, som forsvarets ansatte til stadighed skal rette sig mod. Og den giver så anledning til at formulere Forsvarets vision (NOV 2007), som er den målsætning man vil styre forsvaret mod i fremtiden. Denne er opdelt i tre hovedområder: Forsvarets operative virke, der omfatter, at forsvaret skal være et fleksibelt og relevant redskab i den danske udenrigspolitiske værktøjskasse, og være en samarbejdspartner, som allierede ønsker at arbejde med, samt at være synlig som del af det danske samlede beredskab. Forsvarets virksomhed, der omfatter fornuftig og rimelig anvendelse af ressourcerne, innovation og førende i udviklingen af den offentlige sektor. 13 Forsvarets nye mission og vision folder indeholder et strategi afsnit, men dette arbejde er endnu i sin vorden, og er derfor ikke medtaget i dette afsnit. 14 Med strategi forstås: den langsigtede planlægning som foretages for at opnå et bestemt mål. Ved at formulere, implementere og evaluere beslutninger vil man blive i stand til at nå målet. 15 Missionen er fornyet og publiceret den

81 3.2. Forsvarets mission, vision og strategi 69 Forsvarets medarbejdere, der omfatter udviklingen af disse, samt forventninger omkring at skulle udvise initiativ, tage ansvar og handle til fordel for helheden. Forsvaret skal være en udfordrende og attraktiv arbejdsplads, der kan tiltrække dygtige medarbejdere. Dette viser at forsvaret selvfølgeligt prioriterer sine operative opgaver de opgaver, der for tiden primært løses for den danske stat i udlandet. Tredelingen er ikke udtryk for prioritering mellem opgaverne, snarere en måde at fremhæve de forskellige fokusområder. Del 1 (operativ virksomhed) viser tydeligt at kommunikation og samarbejde med allierede primært i NATO, og med særligt fokus på USA og Storbritannien er højt prioriteret, og hermed bliver der automatisk fokus på NBO (se p. 66). Fra forklaringen til visionen kan man se: At kunne måle os med vores primære samarbejdspartnere stiller også store krav til interoperabilitet. På materielsiden skal vi kunne koble vores systemer til vores samarbejdspartneres systemer [44, p. 13]. Interoperabiliteten er altså i højsædet og taler for at man til stadighed skal holde fokus på at kunne kommunikere med allierede ved hjælp af sine systemer. Materielanskaffelser skal også have dette fokus, og det ligger til grund for den forskning/udvikling, der udføres for hvordan fremtidens forsvar skal se ud. Del 2 taler for innovation og udvikling som del af den offentlige sektor, hvilket igen taler for, at forsvaret skal være førende på IT-området. I forklaringerne kan bl.a. ses følgende sentens: Vi skal være blandt de førende inden for ledelse, personale, pædagogik, Informations- og Kommunikationsteknologi (IKT) og økonomi. At vi skal være blandt de førende, betyder ikke, at vi nødvendigvis skal være de bedste inden for udviklingen af den offentlige sektor, men det udtrykker, at vi skal være med fremme i feltet [44, p. 14]. Man bør notere sig at forskellen mellem del 1 og 2 her går på forskellige partnere. Del 1 er primært samarbejde med allierede partnere (dvs. multinationalt, mens del 2 primært retter sig mod samarbejdet indenlands typisk med fokus på de administrative systemer.

82 70 Kapitel 3. Redegørelse for virksomheden forsvaret Del 3 viser, at man har fokus på udviklingen af medarbejderne og med den personaleafgang, der opleves i 2007, er der ingen tvivl om, at man har fokus på fastholdelse af bl.a. specialister på IT-området. Man vil være attaktiv i forhold til at arbejde andre steder end forsvaret, og her kan udvikling af den enkelte medarbejder være en mulighed. Hvad betyder det så for informatik systemerne i forsvaret? Det er det, vi vil forsøge at afklare i næste afsnit IT-Strategier for Forsvaret Den nuværende strategi for IKT dækker perioden (og opdateres som minumum hvert 2. år). Strategien følger Statens IT-Råds vejledende skabelon for de statslige IT-strategier 16. Strategivirksomheden på ITK-området styres, som beskrevet ovenstående, af forsvarsministeriet, som fastlægger de strategiske mål og godkender og iværksætter væsentlige IKT-initiativer, men udarbejdes i praksis af UVT-afdelingen 17 FKO [47] (og jf. afsnit 3.1.3). Her udarbejdes handlingsplaner, varetages projektledelse og implementering af projekter, samt rådgiving af FMN. FKIT ledelse er forankret i UV-staben, hvilket betyder at UVT kan sikre sammenhæng mellem IKT og forsvarets ledelsesprocesser, operative virksomhed og støttevirksomhed. Samtidigt holdes til stadighed fokus på, at den måde FKIT leverer sine serviceydelser, er i henhold til de direktiver, der kommer fra UVT (og ikke mindst undgår man at der kommer overlap i løsningen af opgaverne). FMT har ansvaret for de IKT-systemer, der udelukkende anvendes til styrkeindsættelse, hvilket set fra UVT side giver en noget længere kommandovej, fordi man skal over chefen for FMT (general) når noget skal koordineres og ikke kan befale direkte som til FKIT. FMN mission for IKT er 18 : Understøtte Forsvarsministeriets overordnede mission gennem tilvejebringelse af effektive og sikre redskaber til håndtering og udnyttelse af informationer. [58, p. 3] Dette er til fulde i overensstemmelse med forsvarets mission jf Det fører frem til FMN vision for IKT : 16 Se mere i [57] 17 UVT er den tekniske afdeling under UV-staben i FKO. 18 Dette afsnit beror i hovedsagen på [58]

83 3.2. Forsvarets mission, vision og strategi 71 Der rådes over et fælles netværk af netværk, hvor der kan udveksles operative og forvaltningsmæssige informationer, internationalt såvel som nationalt. Informationerne kan præsenteres på en platform, hvor information er tilgængelig sikkerhedsmæssigt forsvarligt, på rette sted, i den rette form og på rette tid. [58, p. 3] Her ses en tydelig fokusering på det internationale element og dermed også på interoperabiliteten med andres landes IT-systemer, herunder netværk. FMN skal, som en del af centraladministrationen i staten, selvfølgeligt leve op til de visioner, regeringen har om digitalisering, hvorfor man allerede i begyndelsen af afsnittet om strategi (p. 69) fremhæver dette, gennem målet: Forsvarsministeriet vil arbejde og kommunikere digitalt og vil fra 2009 overgå til fuld elektronisk sags- og dokumenthåndtering. [58, p. 3] Opgaverne er dermed defineret fra centralt hold, og omfatter dermed de o- perative og de forvaltningsmæssige opgaver. Dette ses som de overordnede forretningsmæssige opgaver. Det grundlæggende princip bliver, at forsvarets IKT skal understøtte de forretningsmæssige opgaver. Det fremgår af indeværende IKT-strategi, der løber fra , at IKT kan støtte enten det ene eller det andet område men ikke samtidigt men at man kan forvente af den teknologiske udvikling, at man på på sigt kan understøtte begge sider af opgaveporteføljen med samme IKT system(er). FKO tolker FMN IKT-strategi til deres overordende mål for IKT-virksomhed, som er... at sikre en hurtig, sikker og rationel behandling og udveksling af informationer for derved at bidrage til effektiv løsning af koncernens opgaver. [58, p. 3] Man kan endvidere se, at man vil råde over fælles netværk af netværk, hvor informationer kan udveksles mellem operative og forvaltningsmæssige systemer, såvel indenfor landets grænser som til enhederne i udlandet. Visionen er, at det kan ske på en fælles platform... på rette sted, i den rette form og på rette tid [58, p. 3]

84 72 Kapitel 3. Redegørelse for virksomheden forsvaret Kravet til IKT anvendelse i relation til internationale opertioner er fortsat interoperabiliteten med NATO samarbejdspartnere. Dvs. at informationer skal kunne udveksles mellem systemer, på tværs af systemer, klassifikationsniveauer, værn, kommandoniveauer samt til og fra koalitionspartnere. Et første konkret skridt mod NBO er etablering af 1-NET 19, fordi man med dette vil kunne anvende internettet som transportkanal for sin kommunikation mellem Demars og udsendte enheder og på sigt også våbensystemer. Heraf ses, at koncernen forsvaret har fokus på IKT. Gennem opbygning af netværk af netværk, interoperabilitetskapacitet og tværgående systemer vil man sikre at fremtidens forsvar kan operere på lige vilkår med partnere i såvel ind- som udland og på såvel operative som administrative systemer. 3.3 EA i forsvaret Når forsvaret dermed har defineret sin strategi på IKT-området, kan man begynde at se på de forskellige delområder. Et af disse er fundament for meget af det andet arbejde, nemlig forsvarets Enterprise Arkitektur. Derfor vil vi undersøge, hvad forsvaret har gjort for at definere sin EA. Man har identificeret et antal områder, hvor forsvaret er nødt til at skabe forbedringer for at kunne håndtere den fremtidige IKT-struktur. Der har tidligere været en silotankegang (som de fleste andre steder), som har medført, at informationer ikke er blevet delt optimalt. Dette, sammen med den manglende båndbredde ved de udsendte enheder, har medført et lavere informationsniveau ved soldaten i missionsområdet end hos sagsbehandleren i FKO og dermed skabt en sub-optimal situation [47]. Den overordnede arkitekturopbygning er lavet med henblik på at skabe sammenhæng og sikre interoperabilitet med andre myndigheder i staten og i NATO [58, p. 10]. I de tidligere afsnit er beskrevet, hvorledes det er vigtigt for forsvaret at have denne interoperabilitet med sine samarbejdspartnere. Der eksisterer et skisma mellem at indordne sig under de statslige arkitekturdirektiver og de direktiver, der kommer fra NATO på arkitektursiden. I 19 1-NET er det projekt forsvaret er i gang med, som har til formål at koncernens medarbejdere kan kommunikere på internettet fra koncernens standardarbejdsplads. Herved forventes opnået en mere effektiv sagsbehandling, bedre muligheder for automatisk dataudveksling og kommunikation med leverandører, borgere, myndigheder m.v. uden for ministerområdet.

85 3.3. EA i forsvaret 73 den administrative del har Forsvaret valgt at følge de retningslinier, der er udgivet fra IT- og Telestyrelsen, strengt. Det er de nødt til som en statslig virksomhed [6, min. 19:00]. Som beskrevet i på side 71 samt i afsnit 3.2 på side 67 er dette en nødvendighed for forsvaret at efterleve. På NBO siden har FOFT (senere SEK for anvendt forskning ved FMT) i samarbejde med FKO, FKIT og de operative kommandoer og materieltjenester, i 2006 opstillet rammerne for forsvarets målarkitektur [59]. Det overordnede formål har været at opnå den situation, at forsvaret kan have en fælles arkitektur på alle systemer. I målarkitekturen anbefales det at følge NATO s terminologi og rammestruktur. Ud fra sammenligninger med de amerikanske, engelske og NATO arkitekturrammeværktøjer opstilles et fælles værktøj til brug i det danske forsvar benævnt Forsvarets Målarkitektur 20. Denne indeholder en beskrivelse af NBO-tankegangen og den systemmæssige, holistiske måde at betragte operationer og kapabiliteter på. Dette er ikke nyt, fordi alle systemer er systemer af systemer, men det holistiske er en ny måde at anskue operationer og kapabiliteter på. Den holistiske tilgangsvinkel sikrer, at man arbejder med arkitektur på håndterbart detaljeringsniveau. Ellers risikerer man, at systemer af systemer bliver endog yderst komplekse, når man begynder at beskrive dem i detaljen. Målarkitekturen fastsætter rammerne for udvikling af NBO, så forsvaret har en fælles vedtaget vej for at nå NBO-visionen. Målarkitekturen er ment som samlende for både den administrative og den operative struktur og dækker således alle IKT-systemer. Det er dog vigtigt at slå fast, at forsvaret endnu er i planlægningsfasen, hvad angår EA de hernævnte tiltag er alle fremkommet i teoretisk form, men er endnu ikke implementeret. Det vil vi vende tilbage til. Målarkitekturen består af tre elementer: En operativ synsvinkel, der baserer sig på tre NATO scenarier. Disse bruges til at uddrage generiske missioner og til at tænke NBO ind i strukturen. En system synsvinkel, hvor kravene til information afklares. Hvilke krav er der til kommunikationssystemerne, informationssystemerne og til interoperabilitet? En teknisk synsvinkel, hvor man anvender en 3-lags referencemodel om 20 Kursiverede sentenser nedenstående er fra [59].

86 74 Kapitel 3. Redegørelse for virksomheden forsvaret Figur 3.3: Teknologisk begrebsapparat IP konvergens, netværkscentrering og serviceorientering. Dette er den reele arkitekturtilgang. De tre lag i den sidste pind er vist i figur 3.3 (p. 74) [59]. Det første lag er det fysiske lag. Det består af netværk, kredsløb, radioforbindelser, SATCOM etc. (point-to-point eller netværk). Det andet lag er det logiske lag. Dette består af forbindelsesprotokoller som transporterer informationer rundt i det enkelte netværk eller mellem netværk. Anvendelse af IP muliggør principielt, at enhver type information kan transporteres frit mellem alle typer netværk. Det tredie lag er servicelaget (applikationslaget). Her møder brugeren IKT i form af en PC, en laptop, en PDA, en IP-telefon, mobiltelefon, radio, våbensystem, C3I system m.v. En række services (fri tekst, formaterede messages, billeder, grafik, video, lyd etc.) stilles til rådighed for brugeren (fx. i portaler hvor information fra en lang række uafhængige leverandører præsenteres efter brugerens behov og ønsker). Samlet muliggør dette, at enhver bruger principielt kan tilgå enhver type data. Dette kræver dog Network Management (styring af disse netværk af netværk) således, at der er sikkerhed for, at data når frem i rette form, til rette brugere og med rette indhold (Confidentiality Integrity Availability (CIA)). Tillige kræver det vilje til at dele informationer. For så vidt angår de taktiske datalinks er disse illustreret separat, idet de er indeholdt i alle tre lag. Dog kan data fra datalinks pakkes ind i IP og dermed transmitteres til en anden bruger på netværket. Målarkitekturen kommer frem med et antal fokusområder for at kunne leve op til kravene om interoperabilitet mellem forsvarets forskellige systemer, på såvel den operative (med eller uden alliancepartnere) som den forvaltnings-

87 3.3. EA i forsvaret 75 mæssige. Disse omfatter IP enabling af alle forsvarets systemer (og her er 1-NET et væsentligt område, hvor man er i fuld gang), udarbejdelse af en handlingsplan og en roadmap for implementering af SOA, og til at måle net readiness i overensstemmelse med NATO Maturity Levels (NML) 21. Slutteligt kan hele den samlede arkitektur tankegang ses i figur 3.4 (p. 75) [59]. Den overordnede målarkitektur omfatter hele koncernens IKT på lang sigt (15 år), men med lav detaljeringsgrad. Dette er for at have noget at sigte mod på såvel det strategisk som det tekniske niveau. Ud fra dette er så udarbejdet forsvarets overordnede systemarkitektur (DEFOSA) 22, som er til noget kortere sigt (5-10 år) og med større detaljeringsgrad med henblik på at være limen mellem målarkitektur og systemarkitektur på enkeltsystemerne. I DEFOSA er anført de standarder, som forsvaret som minimum skal følge på IKT området. Systemarkitekturen er så den arkitektur, der skal danne baggrund for anskaffelser dvs. de krav der skal opstilles i forbindelse med større anskaffelser eller opgraderinger af eksisterende systemer. Her er detaljeringsgraden naturligvis høj. Figur 3.4: Aktitketurlandskabet Sammenfattende på forsvarets status på EA området kan det fastslås, at forsvaret er i gang med at se på EA. De er lidt klemt mellem krav fra statens digitaliseringsstrategi og NATO, men har udarbejdet en målarkitektur, som skal være i stand til at honorere begge strategier. Målarkitekturen er beskrevet i teorien, men man er ikke i gang med at implementere endnu. 21 Jf. afgrænsning behandles dette ikke yderligere. 22 Defence Overarching System Architecture

88 76 Kapitel 3. Redegørelse for virksomheden forsvaret IT Governance i forsvaret For en god ordens skyld vil vi kort redegøre for de værktøjer forsvaret anvender til at styre arkitektur og infrastruktur. Ifølge afgrænsning behandledes dette dog ikke videre i analysen. Der anvendes forskellige værktøjer til IT governance og her ses stadigt en opdeling mellem de administrative systemer 23 og operative systemer. Administrativt er det altoverskyggende system SAP R/3 (DeMars), hvor man på driftssiden anvender ITIL 24 til at håndtere infrastrukturen, udvikling og operationer. Forsvaret er ved at indføre værktøjerne fra COBIT 25, der er en samling af Best Practises dvs. en samling af generelt accepterede målepunkter, -metoder, indikatorer og processer, der kan være med til at støtte maksimering af de fordele, der er ved brug af informationsteknologi og til udvikling af styring og kontrol af denne i virksomheden. Til understøttelse for ministeriets forretningsmæssige mål samles IKT-projekter og styres gennem programstyringsmetoden Managing Successful Programmes (MSP) 26. Projekter kræver en godkendt business case og gennemføres som udgangspunkt med brug af PRINCE2 modellen. 3.4 SOA i forsvaret Som beskrevet i afsnit 2.2 er EA en forudsætning for at kunne implementere en fornuftig og gennemtænkt SOA. Uden en EA vil arbejdet med at opbygge en SOA blive meget kompleks og vil inkludere mange elementer af en EA alligevel, hvorfor det vurderes at være en forudsætningsskabende faktor, at der er en EA til stede før man iværksætter SOA initiativer. I forvaltningsapplikationerne er man så småt begyndt at implementere SOA. Det er jo beskrevet i direktiverne [58] og [51] at man skal rette fokus mod SOA. DeMars er udviklet af SAP og er som sådan forberedt på SOA men man afventer et udspil fra SAP s side [6]. Man er i gang med nogle pilotprojekter, der bl.a. omfatter en Enterprise Service Bus 27 (ESB), som er tænkt til 23 Der er dog stadigt fokus på, hvilke systemer der er kritiske eller ej. 24 Information Technology Infrastructure Library [60] 25 Control Objectives for Information and related Technology [61] 26 MSP [62] 27 Software, som kan muliggøre integration mellem mange applikationer.

89 3.4. SOA i forsvaret 77 at skulle håndterer kommunikation mellem de forskellige systemer ind og ud af DeMars. Man er for nærværende kun i gang med at få ESB til at virke og kun enkelte systemer er koblet sammen via ESB en. Det er intentionen, at de forvaltningsmæssige systemer, på sigt, skal kobles sammen med de operative via ESB for at sikre, at kritiske systemer kan tale sammen 28. I afsnit på side 66 defineres NBO. Forsvaret har i [59] fastslået at NBO baserer sig på en SOA tankegang. Hvis man ser på figur 3.5 (p. 77) kan dette tydeligt ses. Al kommunikation og udveksling af informationer og ydelser foregår via services. Figur 3.5 [47] kræver dog en uddybning. Det scenarier, Figur 3.5: Netværks Baserede Operationer i en SOA tankegang man skal forestille sig her, kan være følgende. En observatør (i figuren End User ) sætter sit kampstade op, mhp. at deltage i kamp mod en fjendtlig enhed. I det øjeblik hans instrumenter er kalibreret vil hans system automatisk logge på det netværk der er til stede. Det er lige meget om det er kommunikationsnetværket fra en naboenhed fra USA eller om det er hans egen enhed. Kommunikationen foregår via en service som overholder de standarder, der er givet i NNEC. 28 DeMars kan jo godt være et kritisk system i nogle sammenhænge, selvom det er et rent administrativt system.

90 78 Kapitel 3. Redegørelse for virksomheden forsvaret I det øjeblik han er logget på vil de andre tilgængelige systemer poppe op på hans terminal. Det være sig våbensystemer eller sensorer. Disse vil ikke nødvendigvis vise sig som systemer (eksempelvis som et kanonbatteri eller et kampfly), men snarere som en kapabilitet i form af f.eks. ildområder, der kan nedkæmpes med en vis sandsynlighed eller et område som kan overvåges v.h.a. et sensorsystem (radar, IR, termisk, satellit eller lign.). Det er ikke nødvendigt at kende de andre systemer, fordi de logger på systemet på samme vis som vores bruger, ved hjælp af en service. Når han har behov for en service påkalder han den på sin terminal og kan i grunden være ligeglad med, hvilken enhed der leverer støtten til ham. Som beskrevet i det ovenstående, er dette stadigt på det teoretiske plan - velbeskrevet i skrivelser og udgivelser, men det teknologiske halter endnu efter. NATO har meget fokus på NNEC/NBO også og vil inkludere nationale netværk i deres infrastruktur. NATO s muligheder for informationsudveksling, associerede processer og personel til indsamling af information herunder databehandling, lagring og management af information, skal kunne støtte en NATO-ledet mission. Tilslutning af lokale missionsnetværk til NATO Information Infrastructure sker gennem NATO Information Exchange Gateways. 3.5 Delkonklusion Redegørelsen i dette kapitel har vist følgende resultater: Vi har redegjort for forsvarets organisation både i det store perspektiv og for et eksempel på en enhed udsendt i INTOPS. Dette viser, at forsvaret er en kompleks organisation med mange forskellige parter, der har behov for at kommunikere via mange forskellige systemer. Forsvarets organsisation og strategier lægger op til, at man har fokus på IT som et middel til at understøtte de primære operative opgaver med IT (jf. afsnit 3.2). FMT har fastslået, at der er en tæt sammenhæng mellem NBO og SOA. FMT har identificeret, at SOA vil være en mulig arkitektur, som kan indfri forventningerne til NBO, jf. p. 66. Ud fra de statslige direktiver og NATO s NNEC har FMT udviklet et forslag til en målarkitektur, der kan leve op til de forskellige krav, både de militære interoperabilitetskrav og de civile digitaliseringskrav.

91 3.5. Delkonklusion 79 Målarkitekturen indeholder et forslag til at gøre arkitekturen i forsvaret serviceorienteret, så dette kan opfyldes. Disse resultater vil dermed kunne anvendes i den model, vi vil udvikle i næste kapitel. Modellen udvikles på basis af resultaterne i kapitel 2 og trykprøves med resultaterne i dette kapitel, i kapitel 5. Dermed skulle det blive muligt at komme med en vurdering af forsvarets SOA modenhed eller anvise en metode til at måle det, samt at fremkomme med nogle retningslinier for den videre proces.

92 80 Kapitel 3. Redegørelse for virksomheden forsvaret

93 81 Kapitel 4 Modelopbygning Formålet med dette kapitel er, at opbygge en SOA modenhedsmodel, der undgår de uhensigtsmæssigheder, som vi har identificeret i kapitel 2. Først vil vi argumenter, hvorfor økosystemer er interessante i en SOA sammenhæng og derefter sammenstille en model, der kan måle på SOA modenhed, med inddragelse af relevante elementer fra modellerne i kapitel 2. I det efterfølgende kapitel vil vi kombinere vores model med erfaringerne fra kapitel 3 til at vurdere modellens brugbarhed. Der er i løbet af de sidste år skudt et hav af forskellige modenhedsmodeller og self-assesment tools op 1, som lover at give en indikation af, hvor parat en virksomhed er til at bevæge sig i retning af SOA. Ikke overraskende er det specielt leverandører, der er meget aktive på denne front. Dette skyldes naturligvis, at de har en kommerciel interesse i at få kommunikeret ud, at interesserede købere helt sikkert er parate til SOA. For at komme godt i gang med SOA, skal virksomheden bare lige købe lidt udstyr for at få lidt erfaring med SOA teknologierne, blandt andet igennem pilotprojekter. En anden problematik omkring modenhedsmodeller er, at flere af disse bliver tilbudt af virksomheder, der er baseret i USA 2, hvor der er lidt andre forudsætninger for at tale SOA end i Danmark. Dette skyldes formodentligt, at EA er lovpligtigt i USA 3, hvilket gør, at den offentlige sektor og sandsynligvis mange private virksomheder har fokus på EA og derfor alt andet lige har et bedre udgangspunkt for at diskutere SOA. 1 Vi har kigget på et lille udsnit af dem i 2.4 fra side 32 2 For eksempel i afsnit om Sonic Software figur 2.4 (p. 40) og IBM figur 2.2 (p. 37) 3 Jf.Clinger-Cohen act [63]

94 82 Kapitel 4. Modelopbygning Vi har identificeret, jf. afsnit 2.5, at man ofte foreslår at gå i gang med at lave pilotprojekter 4 o.l. for at få en teknisk indsigt i og erfaring med, hvad man kan med de forskellige teknologier. Erfaringer med teknologi er aldrig spildt, da det giver en god forståelse, for hvad der er teknisk muligt. Man kan så diskutere, om man skal starte med teknikken eller om man burde starte med nogle mere strategiske overvejelser. Som tidligere nævnt i afsnit 2.2.2, ser vi SOA som en del af EA, hvilket giver muligheder for at drage nogle paralleller mellem de to begreber. En af disse paralleller kan drages til, hvordan man starter op med EA arbejdet i forhold til hvordan man foreslår at påbegynde med SOA. I EA bør man netop tidligt i forløbet fastlægge en vision og strategi for virksomhedens EA, før man går i gang med at lave pilotprojekter 5. Med dette in mente, kan man forundres over, at så mange SOA modenhedsmodeller har sat sig udover strategi/planlægningsaspektet. Dette manglende fokus på planlægning af SOA skyldes måske det tidligere nævnte forhold at det er lovpligtig at have en EA i det offentlige system i USA. Derved forudsættes det muligvis, at virksomheden allerede, ved hjælp et EA arbejde, har ensrettet sine IT tiltag med virksomhedens strategier. Da dette antages ikke at være repræsentativt for danske virksomheder, mener vi som udgangspunkt, at mange af de eksisterende modenhedsmodeller tager et forkert afsæt i rejsen mod SOA. Dermed ikke sagt at pilotprojekter og deslige er unødvendige, de er blot ikke det rigtige sted at starte. På sigt, tror vi det bliver problematisk, at flere modenhedsmodeller ikke tager en strategisk tilgang til SOA. Dette er en pointe som også CBDIs David Sprott [38, p. 7] fremhæver som et potentielt problem. Ved at starte, som de fleste modeller foreslår, med at lave pilotprojekter og udsætte planlægningen til de senere faser, risikerer man, at pilotprojekterne vokser op til at blive enterprisens SOA. Dette er i bedste fald er suboptimalt. For at sikre en strategisk og forretningsorienteret tilgang til SOA og minimerer risikoen for at suboptimere, mener vi, at der er behov for at udvikle en ny SOA modenhedsmodel. For at undgå at lave endnu en model baseret på teknik, bør en ny model være fokuseret mod de forretningsmæssige opgaver en virksomhed skal løse. Det er sådan en model, vi i resten af dette kapitel vil opstille og argumentere for. 4 F.eks. Sonic, beskrevet i afsnit eller IBM i deres SIMM model beskrevet i afsnit Jf. Scott A. Bernards metodik foregår den reelle dokumentation af EA først i fase 3, hvor fase 1-2 primært omhandler rammerne for EA [21, pp ].

95 4.1. Betragtninger om SOA modenhedmodeller Betragtninger om SOA modenhedmodeller Før vi kan diskutere modenhedsmodeller og opbygningen af en sådan, er vi nødt til at skabe lidt klarhed over, hvad en SOA modenhedsmodel egentlig er. Som tidligere nævnt i afsnit 2.4.3, er der en gængs begrebsforvirring omkring, hvad der er en modenhedsmodel og hvad der er et roadmap. Vi har valgt at anvende CBDIs definition (jf. p. 45) af forholdet mellem modenhedsmodeller og roadmaps, som vi tolker på følgende måde: Modenhedsmodellen er et teoretisk og logisk funderet rammeværk, hvori færdigheder og afhængigheder analyseres. Et roadmap er en vejledende plan for implementering, baseret på praktiske erfaringer fra adskillige organisationer. Mere specifikt ser vi en modenhedmodel som et øjebliks billede af en virksomheds nuværende situation, en form for AS-IS situation. Roadmappet er i den forbindelse den vejledende plan for, hvordan man bevæger sig fra sin AS-IS til sin fremtidige TO-BE situation 6. I begrebet modenhedsmodel ligger der, udover en AS-IS betragtning, også en forventning om, at man skal kunne måle et niveau af modenhed. Forudsætningen for at kunne måle et niveau er, at man har en fælles kontekst for denne måling. Eksempelvis er der ikke stor mening i angive noget i meter, hvis ikke der er andre der er klar over, hvad 1 meter er. For at undgå tvivl om, hvad 1 meter betyder, så er man nødt til at definere hvad 1 meter er. Denne problematik ser vi som et udtalt problem i forhold til SOA modenhed, da det er svært at definere hvad SOA modenhed er, når man ikke engang er enige om, hvad SOA er. Denne problematik har medført, at der hurtigt kan opstå tvivl om, hvad der er roadmap/proces og hvad der er SOA modenhed. Situationen er ikke optimal, men er sikkert et nødvendigt onde, indtil der, over tid, nås til en global fælles definition af SOA og SOA modenhed. Indtil en sådan definition er blevet etableret, er vi nødt til at forklare, hvad vi mener, når vi siger SOA modenhed. For at have kontekst at vurdere modenhed i, jf. eksemplet om 1 meter, er vi nødt til at definere, hvad man bør måle på og i hvilken kontekst vi gør det. For at forklare konteksten omkring vores SOA modenhed, har vi beskrevet en teoretisk og logisk proces for, hvordan vi ser SOA implementeret. Resultatet af vores SOA proces er nogle outputs, som vi anser for værende nødvendige for at kunne avancere til et højere modenhedsniveau. Dermed er 6 I EA regi vil en sådan plan ofte være betegnet management plan [21].

96 84 Kapitel 4. Modelopbygning SOA processen, i den efterfølgende beskrivelse af vores model, ikke en del af SOA modenhedsmodellen, men den bagvedliggende argumentation for outputtene. Disse output er derved kernen for SOA modenhedsmodellen og det er disse, vi i en modenhedvurdering vil måle på. Den beskrevne SOA proces vil dog også kunne anvendes til andet end argumentation for output, hvilket vil blive demonstreret i kapitel 5 med forsvaret som case. 4.2 Udgangspunkt for vores SOA modenhedsmodel Det centrale omdrejningspunkt for udviklingen af denne SOA modenhedsmodel er den tankegang, der ligger bag anvendelsen af økosystemer, jf. afsnit 2.3. Baggrunden for dette er, at man ved hjælp af økosystemer kan beskrive en virksomhed i sin helhed samt de relationer en virksomhed har til den omkringliggende verden. At se en virksomhed i en helhed, ser vi som en rigtig god mulighed for at få koblet strategier (både for forretningen og IT) med den omkringliggende virkelighed. I relation til SOA er helhedsbetragtningen meget interessant, da en virksomhed ikke kun kommunikerer internt med sig selv, men også eksternt med leverandører og kunder, som igen kommunikerer med andre virksomheder. På trods af at de fleste virksomheder er unikke, er der antageligvis en del sammenfald i mellem virksomheder og den information de udveksler med deres nærmeste omgivelser. Det er denne antagelse, at der er sammenfald i behov for kommunikation af informationer, der gør, at det er interessant at betragte en virksomhed ud fra et økosystemsperspektiv Definition af et SOA økosystem Vores anvendelse af økosystemer tager udgangspunkt i CBDI s anvendelse af begrebet [23]. Vi mener dog, at i denne sammenhæng er det nødvendigt at argumentere bedre for koblingen mellem SOA og økosystemer. Derfor vil vi fremhæve, hvilke egenskaber økosystemstankegangen har og hvordan den hænger sammen med SOA og SOA modenhed. Økosystemer er et begreb der oprindeligt stammer fra biologiens verden, men er siden blevet anvendt i rigtigt mange andre sammenhænge. Dette medfører naturligvis at der er en lang række forskellige definitioner af økosystemer, afhængigt af hvilken kontekst begrebet bliver anvendt i. Grunden til at vi finder økosystemerne anvendelige beror ikke på mangfoldigheden af begrebets anvendelse, men nærmere de karakteristika som kendetegner begrebet.

97 4.2. Udgangspunkt for vores SOA modenhedsmodel 85 Med baggrund i definitioner fra forskellige kilder, har vi fremhævet de karakteristika, der er essentielle for vores anvendelse af begrebet. Definitionerne vil blive præsenteret efterfølgende, hvor de vigtigste passager og nøgleord vil være fremhævet.... Central to the ecosystem concept is the idea that living organisms are continually engaged in a set of relationships with every other element constituting the environment in which they e- xist Ecosystems can be bounded and discussed with tremendous variety of scope, and describe any situation where there is relationship between organisms and their environment. A system as small as a household or university, or as large as a nation state, may then be suitably discussed as a human ecosystem. While they may be bounded and individually discussed, (human) ecosystems do not exist independently, but interact in a complex web of human and ecological relationships connecting all (human) ecosystems to make up the biosphere. [64] Ecosystem: The interacting synergism of all living organisms in a particular environment; every plant, insect, aquatic animal, bird, or land species that forms a complex web of interdependency. An action taken at any level in the food chain, use of a pesticide for example, has a potential domino effect on every other occupant of that system. [65] Hvis man ser bort fra det biologiske islæt i de ovenstående definitioner, kan vi identificere nogle kerne egeskaber ved økosystemer. De mest interessante egenskaber har vi oversat og listet herunder. Interagerer med det omkring værende miljø. Stor variation i scope af økosystemer. Økosystemer kan ikke eksistere uafhængigt af andre økosystemer. Der er et komplekst net af afhængigheder mellem økosystemer. Handlinger i et økosystem kan have en domino effekt i et andet økosystem.

98 86 Kapitel 4. Modelopbygning En af de vigtigste antagelser omkring økosystemer er, at alle deltagere i økosystemet interagerer med hinanden, hvorved alle deltagere også potentielt påvirker hinanden. Dette net af interaktioner mellem deltagere i økosystemet gør at det bliver meget komplekst at deltage i et økosystem og måske endnu mere komplekst at beskrive et sådant i detalje. Derfor er endnu en vigtigt egenskab ved økosystemer, at disse kan defineres i scope afhængigt af, hvad man vil undersøge. Denne frie definition af scope, kan kun lade sige gøre i kraft af en anden egenskab ved økosystemer, nemlig at økosystemer ikke kan eksistere alene. Det vil sige, at de hænger altid sammen med andre økosystemer. Man kan godt undersøge et økosystem isoleret, men det vil altid kunne påvirkes ude fra af andre økosystemer. Udover at denne kobling til andre økosystemer er en stor styrke ved begrebet, så er det samtidigt dets største svaghed. I relation til punktopstillingen på p. 86, er de to sidste egenskaber, to sider af samme sag. Det, at økosystemer altid hænger sammen med andre økosystemer, gør at der er en lang række afhængigheder imellem økosystemer. Denne afhængighed mellem økosystemer gør, at hvis man ændrer en faktor i et økosystem, er der stor risiko for at det påvirker tilknyttede økosystemer. Fra biologiens verden, er der utallige eksempler på, at ændringer i et økosystem kan have utilsigtede og grelle konsekvenser i andre. Som eksempel sås en situation i landbruget, hvor opdagede at mange insekter åd landmændenes afgrøder, hvilket betød, at landmændende begyndte at sprøjte med gift. Dette havde en positiv effekt for økosystemet marken, men havde den utilsigtede konsekvens at økosystemet naturen tog kraftigt skade, idet bestanden af småfugle gik meget tilbage. Disse affødte effekter ser vi som et udtryk for tæt kobling. Denne tætte kobling til de omkringliggende økosystemer er svære at ændre på i den biologiske verden, da der er nogle helt grundliggende spilleregler, der skal overholdes for at levende organismer kan overleve. I den digitale verden er reglerne endnu ikke så fasttømrede og dette åbner op for en lang række muligheder. Problemet med biologiske økosystemer er den tætte kobling til andre økosystemer, på baggrund af regler for eksistens. Hvis man, i stedet for en biologisk enhed, sætter en virksomhed i centrum af et økosystem, vil der være mulighed for at undgå en lignende tæt kobling til andre virksomheder. I kraft af at IT og integration til andre virksomheder er en forholdsvis umoden disciplin (i forhold til jordens udvikling), så er der ikke på samme måde defineret spilleregler for overlevelse. Potentialet ligger helt klart i at definere disse spilleregler. Men, hvor biologien dikterer tæt kobling, bør virksomheder sigte mod løs kobling og derved øget fleksibilitet. Præcis dette er nogle af

99 4.2. Udgangspunkt for vores SOA modenhedsmodel 87 hjørnestenene i SOA, da det muliggør virksomheders hurtige omstilling til skiftende markedsvilkår. Økosystemer i relation til arkitekturbegreber I forbindelse med SOA og EA er det interessante ved økosystemer, hvordan interaktionen mellem økosystemets deltagere foregår og hvordan den kan defineres. Potentialet ved økosystemstankegangen ligger i høj i grad i mulighederne for standardisering, hvilket er en forudsætning for genbrug. Kommunikationen kan eksempelvis være de informationer, der udveksles mellem en kunde og en leverandør. Hvis denne kommunikation bliver standardiseret, vil både kunde og leverandør potentielt kunne genbruge standarden til kommunikation med andre kunder og leverandører. Et af kendetegne ved et økosystem, jf. punktopstilling på p. 86, er at man kan scope et økosystem frit, hvilket minder lidt om den tilgang FEA tager, jf. afsnit p. 47 (en segmenteret arkitektur baseret på LOB). Forskellen er umiddelbart, at FEA tager udgangspunkt i de organisatoriske rammer for en enterprise, hvor vi med vores økosystemstilgang, favner bredere og inkluderer de omkringliggende enterpriser. Hvis man kigger på en tilfældig virksomhed med FEA briller på, vil man se virksomheden, som en enterprise bestående af en række segmenter og LOB, defineret udfra virksomhedens organisatoriske opbygning. Hvis man inkluderer de nærmeste kunder og leverandører, med hvilke man måske har EDI forbindelser, så taler man ofte om extended EA, hvilket heller ikke vurderes at være bredt scope nok for en virksomheds økosystem. Når vi, i dette speciale, betragter en virksomheds økosystem, så ser vi et økosystem bestående af adskillige extended EA, hvor der er et potentiale i at samarbejde. De deltagende virksomheder er bevidste om at der findes andre virksomheder, der er meget lig dem selv, hvorved der er potentiale i at drage nytte af hinanden ved at definere fælles standarder for interaktion mellem økosystemets deltagere Overlappende Økosystemer Som tidligere nævnt, er en af forcerne ved økosystemerne, at scope for disse kan defineres meget frit. Dette åbner for muligheden for at opdele en

100 88 Kapitel 4. Modelopbygning virksomheds økosystem i mindre indeholdte økosystemer og derved mindske kompleksiteten. En problemstilling, der i den sammenhæng presser sig på er, at en virksomhed således kan indgå i flere forskellige økosystemer, der ikke umiddelbart kan defineres uafhængigt af andre økosystemer. Dette har vi forsøgt at illustrere i figur 4.1 (p. 88). X,Y og Z illustrerer tre forskellige økosystemer, hvor der er et område, der er fælles for de tre økosystemer. Økosystemerne X, Y og Z kan enten være deløkosystemer af en virksomheds økosystem eller det kan være tre virksomheders økosystemer, jf. definition p. 87. Figur 4.1: Økosystemer XYZ (egen produktion) Det område, der er af størst interesse på figuren, er naturligvis det område, der er markeret med en blå sky. Her er der både store strategiske muligheder og/eller risici. Fordelene består primært i, at en virksomhed, der er klar over hvilke økosystemer denne agerer i, er i stand til at identificere de områder, der i figuren er markeret med den blå sky. Her ligger et potentiale i at have en strategisk tilgang til en virksomheds engagement i økosystemer. Hvis en virksomhed har en proaktiv tilgang til et samarbejde med de andre deltagere i virksomhedens økosystemer 7 kan man håbe på, at virksomheden kan påvirke andre virksomheder til at anvende nogle af de standarder og definitioner som 7 Hvis man har en dominerende position, som eksempelvis en meget stor virksomhed over en række mindre leverandører og kunder, kan man alternativt diktere hvordan deltagere skal kommunikere med hinanden.

101 4.2. Udgangspunkt for vores SOA modenhedsmodel 89 den proaktive virksomhed allerede har overvejet. Dette kan på sigt medføre, at virksomheden opportunt kan definere en de-facto standard for kommunikation i et eller flere økosystemer, hvori denne indgår. Risikoen kan på den anden side bestå i, at man som virksomhed bliver locked-in 8 til et bestemt økosystem og kan have store omkostninger ved at skifte, samt at man kan risikere at skulle leve op til flere forskellige overlappende økosystemers krav. Derudover er der også en risiko for at man ikke kan få lov til at være med i et økosystem, hvis ikke man overholder visse standarder for kommunikation eller lignende. Et oplagt eksempel til illustration af dette er det offentliges strategi om kun at modtage fakturaer i et bestemt digitalt format. Hvis ikke en leverandør lever op til disse kommunikations standarder, kan han ikke handle med det offentlige. Det offentlige kan diktere dette, fordi man har en dominerende position i forhold til sine leverandører. Hvor mange danske virksomheder, der er i position til at diktere noget tilsvarende, er uklart, men formodentligt er det oplagt for de fleste virksomheder at indtage en mere forhandlende position i dannelsen af lignende kommunikationsstandarder Tværgående økosystemer Udover de overlappende økosystemer, er der også mulighed for at økosystemer kan indholde en række fælles karakteristika, som med fordel kan defineres som et selvstændigt økosystem. Et eksempel på et sådant økosystem i en virksomhed kan være et infrastruktur økosystem, hvor opgaven er at understøtte de andre økosystemer i virksomhedens økosystem. Hvis man forestiller sig at virksomheder i et økosystem vil udbyde webservices eller lignende til hinanden, er de nødt til at definere en form for fælles infrastruktur for at muliggøre dette. En tilsvarende situation vil også gøre sig gældende internt i en virksomhed, hvis man vil dele services med andre afdelinger o.l. Et sådant økosystem, er grundlæggende for at andre økosystemer kan fungere, hvorfor man bør prioritere et infrastruktursøkosystem. Det må dog ikke være det drivende element, da et sådant system ofte ikke tilfører noget værdi i sig selv, men kun i kraft af de andre økosystemer, det understøtter. Tilsvarende kan man også forestille sig, at der vil kunne defineres et økosystem centreret omkring organisationen og de styringsprocesser, der er nødvendige for at styre udvikling 8 Jf. afsnit Lock-in opstår når en virksomhed har svært ved at skifte til en anden udbyder/platform. Man kan være locked-in på grund af en kontrakt, teknologi, brugerflade, netværk af kunder o.m.a. 9 Det er intet til hinder for at virksomheder, der ikke handler med det offentlige også anvender det offentliges kommunikations standarder, hvilket vil forenkle standardiseringsarbejdet mellem virksomheder betydeligt.

102 90 Kapitel 4. Modelopbygning og administrere en virksomhed. En af de vigtige opgaver et sådant økosystem er bygget op omkring, ville kunne være kontakt til andre deltagerere i økosystemet, hvor man skal koordinere ved hjælp af styregrupper 10. Dette er blot to økosystemer, som vi forventer, at man vil kunne genfinde i de fleste virksomheder. Der er antageligvis flere, men vi har foreløbig kun identificeret de to. I forhold til hvad andre SOA modenhedsmodeller anvender af begreber, så er vores tværgående økosystemer sammenlignenlige med termer som, Streams og Views (p. 36). Hvor mange tværgående økosystemer der findes eller hvor mange det er relevant at definere, afhænger af økosystemet, der analyseres. Vi forventer dog, at der vil blive identificeret flere, jo flere virksomheder der anvender modellen og får erfaringer med tilgangen. Fælles for de tværgående økosystemer, er at de principielt er grundliggende for de resterende økosystemer, og som sådan således skal prioriteres tidligt i SOA overvejelserne. Hvorom alting er, er det dog stadig vigtigst at fokusere på de økosystemer, der har størst forretningsmæssigt potentiale. En forretningsmæssig gevinst kan formodentlig allerede indfries tidligt, hvis man formår at få gennemtrumfet en fælles infrastruktur og processtyring tidligt, alene i kraft af færre fejl investeringer i infrastruktur 11. En stor del af de tværgående økosystemer vil være dækket af en EA, i fald en sådan er på plads i virksomheden Begreber i kontekst af økosystemer For at alle har den samme forståelse af de begreber, der bliver anvendt i udviklingen af vores model, vil vi kort præsentere de væsentligste begreber og deres indbyrdes sammenhæng. En grundlæggende forudsætning for, at et økosystem kan fungere er, at dets medlemmer kan kommunikere og udveksle data med hinanden. Dette behov for at kunne kommunikere frit, kan man også kalde et behov for interoperabilitet. En nødvendig forudsætning for at man kan interoperere er, at man dels har en fælles forståelse af, hvordan verden ser ud, at man skal tale samme sprog eller i det mindste kunne forstå hvad andre siger. Denne fællesforståelse er hvad 10 Her tænker vi på styregrupper i stil med hvad Prince2 metoden foreskriver, hvor der er repræsentanter for de vigtigste interessenter. 11 En yderligere gevinst er, at jo flere der anvender en fælles infrastruktur, desto lavere bliver omkostning dem der anvender den.

103 4.2. Udgangspunkt for vores SOA modenhedsmodel 91 vi i økosystems kontekst kalder en servicemodel, idet det er en beskrivelse af den semantik, der anvendes i et givent økosystem, jf. figur 2.1 (p. 31). Ifølge CBDI [23] er servicemodeller det centrale element i definitionen af økosystemer. Det vil sige, at f.eks. virksomheder, der anvender SAP, vil være medlemmer af et økosystem, der er defineret omkring SAPs servicemodel, hvilket giver fin mening i kontekst af økosystemet. I forhold til virksomheders anvendelse af begrebet, mener vi dog ikke det giver den store værdi at dele økosystemer op efter servicemodeller defineret af andre eller virksomheden selv. Hvis økosystemer skal give god mening i forhold til virksomheder, så mener vi, at økosystemer bør defineres ud fra virksomhedens formål og de opgaver denne skal løse. I disse opgavebaserede økosystemer kan der så indgå en eller flere servicemodeller. Virksomhedens største opgave er i denne sammenhæng at få orkestreret alle disse forskellige servicemodeller og økosystemer, så alle økosystemer og deres opgaver og servicemodeller er ensrettede. Økosystem vil i det efterfølgende være at betragte som opgavecentrerede økosystemer. Et andet begreb, som er yderst relevant i denne kontekst, er et af kerneprincipperne i SOA, nemlig løs kobling. På samme måde som services kan kobles løst til hinanden via en service kontrakt, så kan også økosystemer kobles løst til hinanden via deres servicemodeller. For at services kan kobles løst, kræves det, at den service de tilbyder, tilbydes uafhængigt af den enkelte services implementering, hvorved en given service nemt kan skiftes ud med en anden service. Det eneste krav, der er til den nye service er, at den skal leve op til den samme service kontrakt. Dette kan til et vist niveau, opnås ved at anvende platformsuafhængige kommunikationsstandarder. Således bør det være irrelevant om en service er kodet i java eller.net. Et tilsvarende potentiale ser vi i at koble økosystemernes servicemodeller løst. Dette kan opnås ved at have fokus på de begrænsninger det enkelte servicemodeller bevirker og minimere deres indvirkning på økosystemet. Vi antager dog, at det ikke er realistisk at løst koble alle sine økosystemer, da det er alt for komplekst og omkostningsfuldt at undgå nogen form for afhængigheder til IT systemer i en virksomhed. Derfor bliver den løse kobling mere et spørgsmål om at afveje fordele og ulemper, ved enten at definere egne servicemodeller eller at acceptere de begrænsninger i fleksibilitet, der ligger i at anvende proprietære producent servicemodeller.

104 92 Kapitel 4. Modelopbygning Metrikker for SOA Modenhed Da det vil afhænge af den enkelte virksomhed at få præciseret, hvad man skal måle på og til hvilken kvalitet (hvor godt), er det ikke muligt at opstille en udtømmende liste af output. Dette afholder os dog ikke fra at angive en metode til at måle på sådanne målepunkter. Vi vurderer, at den måde som EAAF (jf. p. 47) er opbygget på synes fornuftig, og vi har derfor tænkt os at anvende en lignende tilgang. Efter hvert modenhedsniveau defineres nogle output, som vi mener er relevante for at komme fra et niveau til det næste. Med udgangspunkt i EAAF modellen, vil vi så opstille fem statements, hvor graden af opfyldelse af disse statements bestemmer hvilket modenhedsniveau det specifikke økosystem er på. Som bekendt er scope for økosystemer meget varierende, hvorfor man må definere et fælles scope for økosystemer, der skal sammenlignes. Et passende niveau kan være LOB 12, hvor vi forventer at der ville kunne identificeres en passende mængde fælles karakteristika, så man kan sammeligne modenhed på tværs af virksomheder og økosystemer. Hvis ikke sådanne karakteristika kan identificeres vil en sammenligning potentielt svare til at sammenligne pærer med bananer. De output, vi præsenterer i denne model, er bud på sådanne fælles karakteristika. Med afsæt i de respektive niveauers output, vil man kunne opstille statements fra 1-5, som i EAAF, hvor de undersøgte økosystemer skal score mindst 4, før man kan begynde at kigge på det næste modenhedsniveau. Passende dokumentation, der understøtter påstanden om modenhed bør også stilles til rådighed ved en sådan undersøgelse. Før en virksomhed kan påstå at være på modenheds niveau 3, skal alle underliggende LOB også være på niveau 3. Der er dog intet til hinder for, udover relationer mellem økosystemer, at man kan fortsætte med enkelte økosystemer til højere niveauer af modenhed. Dette vil dog ikke ændre på virksomhedens totale score. Vi har efter hvert niveau givet et eksempel på graduering af et spørgsmål rettet mod at afklare graden af opfyldelse af et ønsket output. Efter denne skitsering af de vigtigste begreber i vores modenhedsmodel, er vi nu parate til at præsentere vores egen SOA Modenhedmodel. 12 Line of Business

105 4.3. Udvikling af egen SOA modenhedsmodel Udvikling af egen SOA modenhedsmodel Dette afsnit indeholder en hurtig oversigt over vores SOA modenhedsmodel, hvor argumentation og diskussioner vil være at finde i det efterfølgende. Hvert niveau er her kort beskrevet med fokus på at præsentere formål og opgaver i de enkelte niveauer, jf. figur 4.2 (p. 94). I afsnit 2.5 har vi sammenlignet de forskellige modeller og fundet nogle af de stærke og svage sider ved disse. Dette bringes i anvendelse i vores udvikling af en model til vurdering SOA Modenhed. Niveau 1 : Definere økosystemer (fra p. 96) Her defineres hvilke økosystemer en virksomhed indgår i. Økosystemerne er centreret omkring en virksomheds formål, som derefter kan splittes op i mindre indlejrede opgavecentrerede økosystemer. Der defineres også målsætninger for hvilke mål en virksomhed kan have med hensyn til SOA. Disse bør defineres i business cases, der centreres omkring økosystemer. Økosystemerne og deres opgaver skal alle koordineres, hvilket ses styret af en EA/SOA/Projektkontor afdeling. Der er blevet identificeret to økosystemer infrastruktur og organisation som forventes at være fælles for en lang række andre økosystemer. Disse ses defineret som separate økosystemer og bør prioriteres højt, da disse er potentielt grundlæggende for succesen af andre økosystemer. Når en virksomheds ledelse har defineret økosystemer i detaljen, prioriteres disse efter strategisk betydning og vigtighed i forhold til virksomhedens formål. Outputtet af niveau 1 er, blandt andet en prioriteret liste af økosystemer. Niveau 2 : Definere vigtige processer (fra p. 105) Med udgangspunkt i de økosystemer, som bliver defineret i niveau 1, beskrives opgaverne i økosystemerne og de processer, der iværksættes for at løse disse opgaver. Processerne defineres med udgangspunk i det enkelte økosystem, men der skal også tages højde for de steder, hvor økosystemer interagerer med hinanden. En proces består af en sekvens af aktiviteter, hvortil de underliggende datakilder skal mappes. Dette gøres for at identificere de steder, hvor der er sammenfald mellem proces, økosystem og datakilder, da det er relevant her at overveje service orientering. Herefter prioriteres processerne i økosystemet, så de bliver klart, om man ser på en kritisk eller ikke-kritisk proces. Outputtet af niveau 2 er, blandt andet, en procesbeskrivelse og en liste over ønskede services, baseret på de identificerede informationsbehov, ved sammenfald mellem proces, økosystem og datakilde. Niveau 3 : Servicemodeller (fra p. 111)

106 94 Kapitel 4. Modelopbygning Figur 4.2: SOA Modenhedsmodel (egen produktion)

107 4.3. Udvikling af egen SOA modenhedsmodel 95 Baseret på servicebehovene fra niveau 2, bliver det her undersøgt i detaljen, hvilke muligheder og begrænsninger, der ligger i de datakilder, der er blevet identificeret. Hver datakilde har en servicemodel 13, som specificerer hvordan man kommunikerer med denne datakilde. Servicemodellen specificerer hvilke færdigheder en service kan tilbyde samt hvilke protokoller o.l. der skal anvendes. Da vores økosystemer er opgavecentrerede, er der ofte mere end en servicemodel i spil, hvorfor man skal orkestrere de aktive servicemodeller, så man finder en overordnet servicemodel. Den overordnede servicemodel skal dermed tage hensyn til de underliggende servicemodeller samt sikre at orkestreringen er i stand til at løse opgaverne i økosystemet. Når servicemodellerne er på plads, fungerer disse som en reference arkitektur, som danner rammerne for at man kan påbegynde implementering. Denne reference arkitektur er det primære output fra dette niveau. De efterfølgende tre niveauer er baseret på et afkog af de gængse modenhedsmodeller fra 2.4. Niveau 4 : Initial arkitekturimplementering (fra p. 118) Baseret på reference arkitekturen fra niveau 3, er formålet med dette niveau at påvise, at reference arkitekturen kan implementeres og at denne er i stand til at understøtte en af de, i økosystemet, specificerede opgaver. Denne validering ses udført ved hjælp af pilotprojekter, hvor servicemodellerne kan godkendes efter et succesfuldt pilotprojekt. Outputtet er hermed en række økosystemer med godkendte servicemodeller, som er klar til implementering. Niveau 5 : Arkitekturimplementering (fra p. 119) Formålet med dette niveau er at implementere den arkitektur, som vi har anvendt niveau 1-4 til at fastlægge. Udover implementeringen af arkitekturen er formålet også at følge op på, om SOA målsætningerne fra niveau 1 er blevet opfyldt samt identificere eventuelle mangler. Da SOA er en rejse, forventes det, at SOA målsætningerne ændres over tid, hvilket stiller ny krav til arkitekturen som løbende skal implementeres. Niveau 6 : Optimeret økosystem med SOA (fra p. 121) Det højeste niveau afspejler en organisation, som har implementeret en SOA på baggrund af de økosystemer, virksomheden indgår i. En organisation, som har uddannet sit personale og optimeret sig selv til at få det fulde udbytte af de forretningsmæssige gevinster, der er forbundet med SOA implementeringen. Et scenarie på dette niveau kan være, at arkitekturen er dynamisk og er selvstyrende/selvsynkroniserende i kraft af forud definerede politikker eller 13 Enten som standard ellers skal virksomheden selv specificere en.

108 96 Kapitel 4. Modelopbygning regelsæt, der specificerer, hvad der skal gøres i tilfælde af en given hændelse forekommer på markedspladsen. Modellen er tegnet med pile i højre side, der viser vejen til de forskellige niveauer. Efter denne korte opsummering og introduktion af modellen, vil vi i det efterfølgende argumentere mere detaljeret for udviklingen af modellen. 4.4 Niveau 1 Definere Økosystemer Metodikken vi ser anvendt til definition af økosystemer og underopdeling af disse, kan tildels sammenlignes med metoden der anvendes i FEA (se afsnit og herunder figur 2.10 (p. 49)). Før man overhovedet kan begynde at overveje at kaste sig ud i økosystemer, er det essentielt, at man har et formål med at kigge på SOA og derved økosystemer. Et af formålene kan være, at en virksomhed ønsker at være med til at forme de økosystemer, denne deltager i, hvilket kræver en strategisk tilgang til at samarbejde med andre aktører i virksomhedens økosystem. Formålene med en sådan strategi kan være at definere nogle fælles standarder for kommunikation, hvorved kommunikation mellem deltagere i økosystemet forenkles. En sådan standard kan promoveres af den enkle virksomhed eller dannes af en samling af virksomheder. Hvilken indgangsvinkel, man anvender, afhænger af hvilken virksomhed, det drejer sig om. Motivationerne kan variere mellem at ville simplificere interaktionen mellem deltagere eller at ville udelukke udefrakommende i at deltage samt gøre det svært for deltagere at skifte til et andet økosystem. Uanset motivationen, mener vi, at virksomheder bør definere en strategi for, hvordan de aktivt har tænkt sig at manipulere eller styre de økosystemer, de deltager i. Da det nok ikke er realistisk, at en virksomhed kan opnå kontrol over alle de økosystemer denne deltager i, er det nødvendigt at fokusere på de økosystemer, der har størst strategisk værdi for virksomheden. En strategisk værdi kan for en virksomhed, f.eks. bestå i at knytte tættere bånd til kunderne, ved at tilbyde kunder muligheder som konkurrenterne ikke kan tilbyde. Dette kan eksempelvis opnås ved at opstille rammer og standarder for services, der gør at en kunde kan hente en service direkte fra virksomheden, og enten anven-

109 4.4. Niveau 1 Definere Økosystemer 97 de denne i kundens processer eller vise den på deres hjemmeside 14. Jo flere services man kan tilbyde og få kunderne til at efterspørge, jo mere er kunderne locked-in til virksomheden, hvilket gør at kunder potentielt forbliver kunder. Risikoen består primært i, at den passive virksomhed på sigt vil få dikteret en række krav og kommunikationsmetoder af andre medlemmer i de forskellige økosystemer, hvori denne deltager. Problemet er her, at virksomheden ikke rigtigt får mulighed for at opnå de store effekter af genbrug, idet at denne risikerer, at de services virksomheden tilbyder udadtil og anvender fra eksterne kilder, skal tilrettes specifikt til medlemmerne af 5-6 forskellige økosystemer. Dette ville virksomheden formodentlig kunne have undgået (eller i det mindste minimeret risikoen herfor), ved at indtage en mere proaktiv holdning og deltage aktivt i definitionen af standarder for kommunikation i økosystemerne. Hvordan defineres et økosystem? Selve begrebet Økosystem er sikkert let forståeligt for de fleste mennesker, og der er som sådan ikke noget odiøst i at beskrive et sådant i overordnede termer (se også 2.3). Kompleksiteten af begrebet øges dog i det øjeblik, hvor man forsøger at trække nogle klare grænser for hvad der tilhører Økosystem X og Økosystem Y, idet der kan forekomme overlap mellem de respektive systemer, jf. figur 4.1 (p. 88). At lave sådanne klare grænser mellem økosystemer, giver efter vores mening heller ikke den store mening, idet vi reelt blot vil have delt en kompleks verden op i nogle mere håndterbare bidder. For at illustrere økosystemet, vil vi bruge en elefant som metafor for et økosystem. Hvis man vil spise elefanten 15, er man nødt til at dele den op i håndterbare bidder og spise den et stykke ad gangen. Man behøver ikke at få defineret helt præcist, hvor hovedet bliver til krop, men bare at elefanten består af flere legemesdele, så kan man på et senere tidspunkt overveje, hvor det er mest hensigtsmæssigt at lægge snittet. På samme måde kan man også definere et stort økosystem, som f.eks. den 14 Et eksempel på dette er igoogle, hvor man kan tilpasse sin egen side ved at anvende små applikationer, der henter data fra services eksponeret af Google, som eksempelvis Gmail eller Google Calendar. Applikationerne er både udviklet af Google selv og andre udviklere. Dette er kun muligt fordi Google har lykkedes med at definere og standardisere den måde, hvorpå man skal kommunikere med Google services, og derefter offentliggjort det til alle interesserede, således der ikke eksisterer tvivl om hvordan man kommunikerer med Google, se mere på 15 Hvis man er meget sulten...

110 98 Kapitel 4. Modelopbygning danske stat og så opdele det i mindre bidder ministerier, kommuner, selvstændige offentlige virksomheder osv. Disse kan så igen underopdeles i mindre bidder, såsom linieenheder, som så igen kan opdeles. Det vigtige er ikke, hvor grænsen går, men nærmere at få fremhævet de steder, hvor økosystemer er i kontakt med hinanden og derfra definere, hvordan man bør kommunikere i og mellem økosystemer jf. den blå sky på figur 4.1 (p. 88). En anden vigtig egenskab ved økosystemer er, at de helst skal defineres så præcist, (for nu at blive i ovenstående eksempel med elefanten), at elefanten kan beskrives, skilles ad (ikke spises) og sættes sammen igen, uden at man nødvendigvis er klar over, hvor snitfladen er, men så man stadig har styr på at hovedet skal sidde på halsen. Denne samhørighed mellem økosystemets og dets indeholdte økosystemer har vi forsøgt at illustrere i figur 4.3 (p. 98). De blå cirkler illustrerer de opgaver, der ligger til grund for økosystemet og tanken er, at disse skal referere opad, så de opgaver, der ligger til grund for et økosystem altid kan mappes op mod en opgave på et overliggende niveau. Figur 4.3: Indlejrede økosystemer (egen produktion) Hvis man antager, at det store alt-favnende økosystem i figur 4.3 er en virk-

111 4.4. Niveau 1 Definere Økosystemer 99 somhed, hvor økosystemet er defineret ud fra virksomhedens formål, er det de overordnede opgaver, som det er virksomhedens formål at løse. I det store økosystem er opgaverne overordnede og strategisk beskrevne og er ikke umiddelbart operationelle, hvorfor man med fordel kan opdele det store økosystem i mindre indlejrede økosystemer. I kernen af disse indlejrede økosystemer ligger der mere udpenslede beskrivelser af virksomhedens formål, som alle kan mappes op imod det overordnede formål med virksomheden/det store økosystem. Tanken er, at man skal kunne tage formålet med virksomheden og få det bragt fra strategisk niveau til et mere taktisk niveau, hvor man kan definere nogle reelle og håndgribelige opgaver. Dette har vi forsøgt at illustrere i figur figur 4.4 (p. 99), hvor man ser virksomhedens formål blive specificeret i mere detaljerede opgaver. Figur 4.4: Konfliktende økosystemer (egen produktion) Som det også fremgår af figuren, kan der opstå overlap, idet enkelte opgaver kan løses på forskellige måder i forskellige økosystemer. Dette er i og for sig ikke noget problem, så længe der ikke er overlap i opgavens formål. I det tilfælde, hvor der er overlap mellem opgaverne og økosystemer, skal der koordineres mellem disse, en opgave der ville kunne varetages af en EA afdeling eller et programkontor. Ved en koordinerende indsats mellem økosystemer bør man kunne nå til en fælles definition af en servicemodel for det overlap-

112 100 Kapitel 4. Modelopbygning pende område, så økosystemerne bliver ensrettede med hensyn til de opgaver der forventes udført i de enkelte økosystemer 16, jf. figur 4.5 (p. 100). Figur 4.5: Overlappende økosystemer (egen produktion) Formålet med hele øvelsen er, at man får opdelt sine økosystemer i nogle meningsfulde, mindre økosystemer, som man så kan undersøge om det ville give mere mening at opdele yderligere, for at opnå mere håndterbare økosystemer. Antallet af underopdelinger i en virksomhed, bestemmes ud fra kompleksiteten i dennes opbygning 17. Fælles for alle de underliggende økosystemer er, at de skal hænge sammen, da de skal kunne mappes op til de opgaver, der er bestemt på det overliggende niveau. I fald der er overlap mellem disse økosystemer, skal disse koordineres indbyrdes, så man ikke stiller modstridende krav til de underliggende økosystemer, som eksemplificeret i figur 4.4 (p. 99). Man er færdig med opdelingsprocessen, når man mener, at det ikke længere er relevant at opdele sine økosystemer i mindre enheder. 16 I definitionen af servicemodellerne, vil der sandsynligvis opstå et behov for en koordinering mellem disse, hvorved man kan undgå unødigt overlap mellem services og processer, se niveau Vi antager, at man i kommuner, ministerier, koncerner har brug for adskillige niveauer af økosystemer.

113 4.4. Niveau 1 Definere Økosystemer 101 Da det formodentligt ikke er muligt at arbejde fokuseret på alle økosystemer samtidigt, er det nødvendigt at prioritere indsatsen, således man ikke prøver at Boil the ocean 18. Dette beskrives i det følgende. Prioritering af økosystemer Man kommer ikke langt med at angribe hele verden på en gang, så derfor bør man prioritere sin indsats for at kunne opnå nogle resultater. Det store spørgsmål er så, hvordan man gør dette i relation til økosystemer. Dette kan man ikke umiddelbart give et generisk bud på. I og med at økosystemer kan defineres ud fra så forskellige grundlag, som f.eks. HR Rekruttering 19 eller Windows Server , er det ikke relevant at diskutere en generisk metode til at udvælge, hvilke økosystemer man bør fokusere på. I stedet bør en virksomhed definere de overordnede målsætninger (strategi og vision) for, hvad man vil med SOA, og derefter vurdere, hvor vigtige de respektive økosystemer er med hensyn til at indfri disse målsætninger, jf. punktopstillingen på side 16. Disse kunne eksempelvis være nedenstående, og ville normalt være beskrevet i en business case: Økonomisk rentabilitet Billigere udvikling af IT 21 Time-to-Market 22 Strategisk vigtighed Lock in af kunder Undgå lock in Time-to-Market Teknologisk vigtighed 18 Med andre ord, man skal opdele problemer i mindre problemer og så løse et lille problem ad gangen. 19 Her tænker vi på en afdeling i en virksomhed hvor økosystemet kan bestå af ansatte i afdelingen, firmaer de samarbejder med, andre lignende afdelinger i andre virksomheder 20 Her tænker vi på økosystemet mellem firmaer der anvender systemet, Microsoft selv, konsulenter etc. 21 I kraft af øget genbrug og fleksibilitet 22 Med efterfølgende mulighed for mersalg og erobring af markedsandele

114 102 Kapitel 4. Modelopbygning Burning Platform 23 Time-to-Market Essensen er, at de overordnede målsætninger skal støtte op omkring virksomhedens overliggende strategi, samt understøtte virksomhedens formål. Da de enkelte økosystemer, virksomheder deltager i, kan være meget forskellige, er det tvingende nødvendigt, at man får defineret nogle overordnede målsætninger og til hvert økosystem specificerer metrikker, der kan medvirke til, at man kan prioritere et eller flere økosystemer frem for andre. I sidste ende bør man vælge det økosystem, hvor virksomhedens aktiviteter giver bedst forretningsmæssig mening. Der kan dog være andre hensyn, som kan tages i forbindelse med udvælgelse af det økosystem, man vil prioritere. Det kan være afhængigt af om man vil prioritere økosystemer med løsning af kritiske opgaver fra starten af, for hurtigst muligt at opnå de forretningsmæssige gevinster, eller om man antager et forsigtighedsprincip og starte ud med et mindre vigtigt økosystem, for at få prøvet tingene af, inden man går i gang med de kritiske systemer. Under alle omstændigheder er det vigtigt at få afklaret præcist hvilken prioritering, der ligger til grund for udvælgelsen Input og output Input Input til niveau 1 er primært virksomheden og dennes nærmeste omgivelser og interaktionspartnere. For at gøre inputtet lidt mere håndgribeligt har vi opstillet en række eksempelvise spørgsmål, hvor svarene på disse, vil kunne hjælpe med til at få defineret de overordnede økosystemer en virksomhed indgår i. Svarene på disse er dermed de primære input til niveau 1. Hvilke organisationer kommer direktiver fra? (Er man kontraktligt bundet af noget?) Hvilke organisationer har man behov for at kommunikere med? Hvilke økosystemer indgår virksomheden i? 23 Gammel og utidssvarende platform i forhold til nutidige og fremtidige krav

115 4.4. Niveau 1 Definere Økosystemer 103 Er der kendskab i organisationen til EA? Er der udpeget enterprise arkitekter/afdelinger? Er der Evangelister (evt. selvbestaltede) til at drive udvikling mod SOA? Er der SOA tiltag hos de organisationer, man kommunikerer med? Dette er kun et kort uddrag af de spørgsmål der kan stilles, og de vil sikkert lede til en række affødte spørgsmål. Ideen er, at virksomheden skal have klarlagt, hvordan og med hvem denne interagerer i dens omverden. Output Formålet med niveau 1 af modenhedmodellen er at få klarlagt hvilke økosystemer en virksomhed indgår i. Disse skal defineres til et sådant niveau, at de er til at arbejde videre med, fokuseret mod at løse virksomhedens primære opgaver, jf. figur 4.5 (p. 100). Det er naturligvis en forudsætning, at ledelsen har forståelse af SOA og økosystemer, da definitionen af økosystemer bevæger sig fra strategisk til taktisk niveau. Deraf kan man udlede, at definition af økosystemer er en opgave, som kræver ledelsens bevågenhed og engagement. En virksomhed kommer ikke langt, hvis de folk der skal udføre arbejdet ikke har de kompetencer og evner der skal til. Derfor er det vigtigt, at man på et tidligt tidspunkt planlægger, hvordan og hvorledes, man vil øge forankringen af SOA i en virksomhed. Dette er en opgave vi ser, ligger i forbindelse med det tværgående økosystem Organisation jf. afsnit Vi har derfor identificeret nogle output 24, som vi mener er essentielle for at få rammerne for det videre arbejde på plads. Ledelsen har ved f.eks. workshops vist forståelse for økosystems tankegangen Der er defineret en SOA økosystems strategi, som er i overensstemmelse med virksomhedens formål 24 Disse er, på dette niveau og de efterfølgende niveauer, stærkt inspireret af de beskrevne modeller i afsnit 2.4.

116 104 Kapitel 4. Modelopbygning Der er defineret overordnede økosystemer, der kan mappes til SOA økosystems strategien Kompetenceplan og strategi for medarbejder udvikling Der er udarbejdet business cases for SOA økosystemerne SOA økosystemerne er klart definerede med deres opgaver og dette er dokumenteret Der er klarhed over hvordan de enkelte økosystemer relaterer til hinanden og dette er dokumenteret. Etablering af en projektorganisation eller et projektkontor til drift af SOA arbejdet. Prioriteret liste over økosystemer baseret på overordnede målsætninger, se side 4.4 Liste over potentielle samarbejdspartnere til definition af økosystems standarder I stil med EAAF har vi opstillet en række spørgsmål, som er tiltænkt at afdække graden af opfyldelse af for et af de ovennævnte output. Vi har præsenteret dem i vilkårlig rækkefølge og vil efterfølgende give et eksempel på hvordan man kan gradbøje et af spørgsmålene til 5 statements figur 4.6 (p. 104). Figur 4.6: Eksempelvise spørgsmål til Niveau 1 Er der klart definerede økosystemer og er disses opgaver beskrevet? Er økosystemerne blevet prioriteret efter vigtighed og forretningsmæssig rentabilitet?

117 4.5. Niveau 2 Processer 105 Hvordan er kendskabet til SOA i IT-afdelingen og i resten af organisationen? Er der generel forståelse i ledelsen af betydningen af at være deltager i forskellige økosystemer? 4.5 Niveau 2 Processer Når definition og prioritering af økosystemer er tilendebragt, er det tid til at kigge på de processer, der er i økosystemerne. Disse skal vurderes på baggrund af, hvor vigtige de er i forhold til udførelsen af de opgaver, der er defineret i økosystemerne. Men for at blive i stand til at vurdere dem, er det nødvendigt at få nogle definitioner på plads: Proces: en naturligt forekommende eller designet sekvens af aktiviteter til transformation af et objekt eller et system. Kerneopgave: en opgave, som er den vigtigste opgave for opgaveløseren. Den opgave, som er en forudsætning for løsingen af ikke-kerne opgaver dvs. opgaver, der er kontekstafhængige. Kerneopgaverne er en helt central del for forståelsen af, hvordan processerne skal prioriteres. Ved at analysere de bestående processer kan man forstå de sammenhænge, der er i løsningen af opgaverne, såvel internt i eget økosystem som imellem andre økosystemer, man interagerer med. Der kan defineres en AS-IS situation, som bruges til at bestemme ens (ønskede) TO-BE situation og dermed give input til, hvordan man skal udarbejde sine planer for at flytte sig fra det ene til det næste niveau. Beskrivelsen af processerne kan ske gennem brug af notationen BPMN 25. De økosystemer og deres opgaver, som blev identificeret på niveau 1, skal nu vurderes. Dette gøres ved at splitte hver enkelt opgave op i atomer, for at kunne finde de sammenhænge, der er. For at bruge elefanteksemplet fra p. 97, så skal man nu ikke blot se elefanten som et hele af økosystemer, der hver især tager sig af f.eks. bevægeapparat, fordøjelsessystem etc., men må nu se på hver enkelt delopgave og dennes rolle i den samlede opgaveløsning. Derved 25 Business Process Management Notation [66].

118 106 Kapitel 4. Modelopbygning Figur 4.7: Eksempel på BPMN diagram (egen produktion) bliver fordøjelsessystemet til et økosystem i en pool 26, hvor der sker indtagelse af føde, tygning, synkning af maden, passage af spiserør, nedbrydning af indholdet af mavesækken, videre til tarmsystemet, etc. Kontakten til andre økosystemer i form af overførsel af energi til muskler, udskillelse af affald til nyrer og lever, passage over i blodet til transport rundt i organismen m.m. kan ses som interaktion med de andre økosystemer. I centrum af hvert økosystem er et antal opgaver, jf. afsnit 4.2.4, hvis løsning er økosystemets formål. Løsningen af disse opgaver foregår ved at gennemløbe en sekvens af aktiviteter. Disse kaldes en proces. I figur 4.7 (p. 106) ses processerne for hvert økosystem i en pool (vandrette områder). Er der indenfor et økosystem mindre indlejrede økosystemer 27, kan disse opdeles i swim-lanes. Processerne begynder i en startnode og hver enkelt lille ændring fremgår af en pil, der viser sammenhæng og afhængighed mellem aktiviteter, så man kan bevæge sig videre til den næste delaktivitet. Aktiviteter kan være i sekvens med aktiviteter der ligger i andre økosystemer, hvilket er eksemplificeret i figur 4.7 (p. 106) med pile på tværs af swim-lanes (dette er illustereret med 26 I BPMN notationen. 27 Afhængigt af hvordan man har defineret scope for økosystemet.

119 4.5. Niveau 2 Processer 107 gule trekanter på figuren). Her kan der være muligheder for at anvende services, så integrationen mellem enheder lettes og gøres mere fleksibel overfor at andre endnu ukendte enheder kan anvende de tilgængelige informationer. Endvidere kan der være behov for interaktion mellem pools dvs. mellem forskellige økosystemer (illustereret med røde trekanter på figuren). Her er der i høj grad mulighed for at anvende principperne i SOA, da man ofte med fordel vil kunne løst koble systemerne. Dette giver endvidere den fordel, at de definerede services potentielt vil kunne genanvendes til interaktion med andre økosystemer. Før denne kobling til andre økosystemer kan opnås, kræver det, at deltagende parter definerer, hvordan komminikationen skal foregå. Det vil vi komme tilbage til på niveau 3, hvor vi taler om servicemodeller. Det vigtigste på niveau 2 bliver at få defineret, hvilke processer der gennemføres i det enkelte økosystem og hvordan økosystemerne er afhængige af hinanden. Det vil sige, hvilke processer der afvikles på tværs af opgaverne samt hvilke informationer, der anvendes og hvilke kilder de kommer fra. Fra niveau 1 er der defineret og prioriteret nogle økosystemer, hvorfor der også nødvendigvis må være en række processer, der gør, at sådanne økosystemer eksisterer. Prioriteringen af processerne bør foregå efter de samme principper, som økosystemerne blev defineret ud fra. For at få et overblik over sammenhængen mellem de fundne output fra niveau 1 og 2, kan disse med fordel sættes ind i en tabel, som kan vise dels hvordan processerne fordeler sig på økosystemer og relateret til datakilder, og dels hvordan datakilder og processer virker sammen inden for det enkelte økosystem. Det er illustreret i figur 4.8 (p. 108). Her ses alle økosystemer listet lodret (benævnt V-Z), og alle de identificerede datakilder (benævnt 1-3) listet vandret. Med datakilder forstår vi de IT-systemer, der tilbyder eller lagrer information til brug for løsningen af en delopgave eller proces. Datakilderne er opdelt på processer(benævnt A-D), og markeringerne herunder viser da sammenhængen for, hvor en proces indgår i et økosystem og hvilke datakilder den trækker på. Ved at opstille en figur på denne facon, vil det blive tydeliggjort, hvor der er interaktion mellem økosystemer. Før denne interaktion kan spænde af på en fornuftig måde, skal man have defineret nogle klare snitflader mellem økosystemerne. På dette niveau 2, påpeges snitfladerne og på det efterfølgende niveau 3, påbegyndes arkitekturarbejdet med at få taget højde for kommunikationsbehovene og få defineret snitfladerne i detaljer. På figuren fremhæves de processer, som spænder på tværs af mange økosystemer, hvilket indikerer, at her er der mange krav til, hvordan denne kommunikation kan forløbe. Derfor vil det være et oplagt sted at gennemføre en analyse af, om man

120 108 Kapitel 4. Modelopbygning skal påbegynde en udvikling af fælles services eller anden kobling 28. Vandrette sammenhænge viser de processer, der indgår i det enkelte økosystem samt hvilke datakilder disse trækker informationer fra. Af figur 4.8 (p. 108) fremgår det, at adskillige økosystemer anvender proces B og D, samt at disse processer henter informationer fra datakilde 1 og 3. Dette sammenfald gør, at man bør undersøge om man kan standardisere de informationer der bliver tilbudt fra datakilde 1 og 3, og måske tilbyde disse i services. Om services er den rigtige metode afhænger af behovet for forholdet mellem performance og fleksibilitet. Figur 4.8: Økosystemer, datakilder og processer (egen produktion) Den næste figur 4.9 (p. 109) er en mere detaljeret visning af sammenhængen indenfor det enkelte økosystem (her eksemplet benævnt W i figur 4.8 (p. 108)) mellem processer og datakilder. Her ses da, hvilke datakilder en enkelt proces skriver og læser i. Er der her lodrette sammenhænge, vil det give en indikation af, hvor det vil være formålstjenligt at service enable kilden. Forhåbningen er, at man gennem en detaljeret undersøgelse af de sammenhænge, der er imellem processer, økosystemer og datakilder, bliver i stand til at identificere de informationer/data, som er formålstjenelige at udbyde som services. Ved at undersøge de processer og opgaver der er indeholdt i økosystemer, kan man få et overblik over de servicebehov, der måtte være i virksomheden. Ydermere kan man identificeret, hvilke datakilder der anvendes og kan derved forholde sig til de begrænsninger/fordele som disse kan 28 Kriterier til vurdering af koblingsmetode, kan være hyppighed af service anvendelse og data mængde.

121 4.5. Niveau 2 Processer 109 Figur 4.9: Datakilder og processer sammenhæng (egen produktion) tilbyde. Dette kan der tages stilling til på niveau 3. For at kunne udføre en sådan analyse på niveau 3, har vi identificeret input og output for dette niveau Input og output Input Inputtet til niveau 2 er primært definitionen af økosystemerne i niveau 1 samt definitionen af deres indeholdte opgaver. Disse opgaver skal løses ved hjælp af processer, som understøttes af mennesker og IT-systemer, der kan tilhøre flere økosystemer. Afhængigt af de prioriteter og målsætninger, der bliver defineret på niveau 1, vil man være i stand til at prioritere sin indsats i forhold til, hvilke økosystemer man vil analysere først samt hvilke aktører, der er relevante at bringe i spil. Output Ligesom på niveau 1, vil man her skulle levere nogle produkter, for at kunne komme til at måle på modenheden. Det er i den forbindelse vigtigt at definere sine processer i en så tilstrækkelig detaljeringsgrad, at man er i stand til at anvende det til opbygning af SOA. Dvs. at det skal være beskrevet på en sådan måde, at man f.eks. kan anvende dem som behovsinput til en service

122 110 Kapitel 4. Modelopbygning kravspecifikation, der muliggør kommunikationen mellem aktiviteter og datakilder. Endvidere skal man have defineret en prioritering af sine processer hvilke er de vigtigste, dvs. kritiske for virksomhedens løsing af sine kerneopgaver og evt. også kritiske for at de andre processer kan forløbe korrekt. Dette bør vurderes ud fra de i niveau 1 definerede strategier og målsætninger. Procesbeskrivelser, evt. inklusiv diagrammer udvisende sammenhænge med andre økosystemer. Interaktionsbeskrivelser, der beskriver behovet for data, samt hvilke kilder og aktiviteter disse indgår i, evt. opstillet som i figur 4.8 (p. 108). Liste over kritiske og ikke kritiske processer. Liste over ønskede services (behov). Afhængigt af, hvor velbeskrevet en EA en virksomhed har, så vil der på dette niveau være en stor del dokumentation af eksisterende processer. Har virksomheden på forhånd en veldokumenteret EA, vil meget dokumentation og beskrivelse af processer og datakilder allerede være produceret og derved nemt tilgængeligt. Som på niveau 1, har vi også forsøgt at opstille nogle spørgsmål der retter sig mod afklaring af opfyldelsen af niveau 2 output, eksemplificeret i figur 4.10 (p. 110). Figur 4.10: Eksempelvise spørgsmål til Niveau 2 I hvor høj grad er økosystemets opgaver opløst i delopgaver og understøttet i processer?

123 4.6. Niveau 3 Servicemodeller 111 Hvor godt er processerne opsplittet i aktiviteter og understøttende datakilder? Er processerne beskrevet så detaljeret, at de kan bruges til at lave kravspecifikationer ud fra? Er der etableret en prioritering af processer, således der er klarhed over, hvilke der er kritiske og ikke-kritiske processer? I hvor høj grad kan man spore ønskede services tilbage til aktiviteter? 4.6 Niveau 3 Servicemodeller Formålet med dette niveau 3, er grundliggende set at få dokumenteret måden kommunikationen skal foregå på i og imellem de respektive økosystemer en virksomhed indgår i. Dvs. at få specificeret de respektive servicemodeller 29. Vi har på de to foregåendeniveauer fået opdelt virksomheden i nogle håndterbare økosystemer 30 samt fået defineret hvilke forretningsprocesser og understøttende IT systemer, der bidrager til løsningen af disse opgaver. Processerne er bygget op omkring løsningen af økosystemets opgaver og kan som sådan godt have kontakt til andre økosystemer 31 og spænde over en vifte af interne servicemodeller. Da økosystemer kan bestå af flere mindre økosystemer, som kan anvende adskillige servicemodeller, er udfordringen på dette niveau at få koordineret og klarlagt, hvilke økosystemer anvender hvilke servicemodeller samt om der er sammenfald mellem de forskellige økosystemer. Eksempelvis kan man godt forestille sig, at HR og Logistik begge anvender SAP som understøttende IT system, hvilket gør, at der kan være et sammenfald mellem servicemodeller, i dette tilfælde SAPs servicemodel. Sammenhængen mellem servicemodeller i økosystemet 32, har vi forsøgt at illustrere i figur 4.11 (p. 112) Koordination af servicemodeller For at sikre sammenhængen mellem servicemodellerne ser vi det nødvendigt, at man på det højeste niveau af økosystemer, hvori en virksomhed har ind- 29 Se afsnit Opbygget omkring nogle opgaver, der kan spores tilbage til virksomhedens formål. 31 Som nævnt i niveau 1 økosystemer kan godt lappe ind over hinanden. 32 Input til dette vil i høj grad kunne findes i tabellerne, der er output fra niveau 2.

124 112 Kapitel 4. Modelopbygning Figur 4.11: Økosystemet og dets servicemodeller (egen produktion) flydelse, definerer nogle principper for, hvordan man skal koordinere servicemodellerne. Da vi beskæftiger os med SOA, kan nogle af disse principper være: Servicemodellerne skal være løst koblede Servicemodellerne skal være platformsuafhængige Fleksibilitet er vigtigere end pris Vi accepterer Lock-In til den rette pris Det påpeges, at de ovenstående principper ikke må være i modstrid med de overordnede målsætninger, defineret på niveau 1. De 2 første punkter er lånt fra SOA principperne, jf. afsnit 2.1.2, hvilket ikke er helt tilfældigt. Som tidligere nævnt i afsnit 4.2.4, ser vi ingen problemer i at anvende de samme principper for økosystemer som for services, idet man kan anskue økosystemer som meget komplekse services i sig selv, der har til formål at løse en specifik opgave. Dette er netop en af grundene til, at vi finder det meget anvendeligt at centrere vores økosystemer omkring opgaver i stedet for om servicemodeller. Fordelen er, at økosystemerne bliver forretningsrettede, da opgaverne defineres ud fra virksomhedens formål,

125 4.6. Niveau 3 Servicemodeller 113 hvilket skulle sikre at SOA bliver rettet mod forretningens behov. Ulempen ved denne indgangsvinkel til økosystemer, er at man skal håndtere flere servicemodeller. Da servicemodeller kan være modstridende, er en virksomhed nødt til at prioritere anvendelsen af servicemodeller ud fra, hvad der er strategisk og økonomisk fornuftigt. Hvis man ser nærmere på de ovennævnte eksempelvise principper, kan man se, at enkelte af principperne er potentielt modstridende, da det kan være svært at koble systemer løst, hvis man på samme tid accepterer at blive locked-in til en servicemodel. Dette er overlagt for eksemplets skyld, men denne modstrid skal naturligvis ikke være til stede når en virksomhed definerer principperne for anvendelse af servicemodeller. Den altovervejende beslutning, principperne skal være med til at understøtte, er i sidste ende, hvilke servicemodeller man kan acceptere og hvilke man ikke kan. Problematikkerne kan eksempelvis være, at man ønsker at have løst koblede systemer for enhver pris, hvilket vil kræve at virksomheden er nødt til at definere sine servicemodeller selv og derudover definere services i de underliggende applikationer selv. Hvorvidt det i det hele taget er muligt at koble alle sine servicemodeller løst er på nuværende tidspunkt en utopi, hvorfor man i stedet bør fokusere på at få en forretningsmæssig fornuftig tilgang til Lock-In og proprietære servicemodeller Definition af økosystemernes servicemodeller Metodikken til at definere økosystemernes servicemodeller, minder på mange måder om definitionen af selve økosystemerne, jf. afsnit 4.4 p. 97, hvor nøglen er at sikre sammenhæng mellem de overordnede økosystemer helt ned til det laveste niveau af de indlejrede økosystemer. Denne sammenhæng er også nøglen til definition af servicemodellerne. Da vi allerede har defineret økosystemerne omkring deres opgaver og har defineret de processer og systemer, der indgår i løsningen af disse opgaver, finder vi det mest relevant at begynde definitionen af servicemodellerne fra det laveste niveau, som illustreret i figur 4.12 (p. 114). Dette gøres for at klarlægge, hvilke afhængigheder de enkelte servicemodeller indgyder på de enkelte økosystemer. Når man har dannet sig et overblik over de servicemodeller virksomheden bevidst og ubevidst anvender, er det for forretningen tid til at definere de principper, der skal lægge fundamentet for, hvilke servicemodeller og afhængigheder virksomheden kan acceptere fremover. Tanken er, at forretningen bør have et kendskab til de anvendte servicemodeller for at kunne definere realistiske principper for, hvordan virksomheden skal prioritere anvendelse af servicemodellerne. Alternativt kunne et princip være at vi accepterer ikke

126 114 Kapitel 4. Modelopbygning Figur 4.12: Definition af servicemodeller (egen produktion) proprietære servicemodeller, hvilket i realiteten ville resultere i en enorm omkostning til definition af egne servicemodeller og services. Det er nok mere realistisk, at en virksomhed accepterer at være bundet til en servicemodel fra SAP end at acceptere omkostningerne til at definere egen servicemodel og services. Efter endt definition af de styrende principper for sine servicemodeller, er virksomheden parat til at tage en top-down tur ned gennem hierarkiet af servicemodeller og økosystemer, for at ensrette de uoverensstemmelser, der måtte være mellem servicemodellerne og de styrende principper. Som ved økosystemerne, er det her vigtigt, at der er en koordinerende enhed, såsom et EA/SOA kontor, der er i stand til at identificere overlap mellem servicemodeller samt orkestrere et væld af forskellige servicemodeller. Når virksomheden har orkestreret sine servicemodeller og har fået ryddet ud i uhensigtsmæssighederne, illustreret i figur 4.13 (p. 115) er virksomheden klar til niveau 4.

127 4.6. Niveau 3 Servicemodeller 115 Figur 4.13: Ensrettede servicemodeller (egen produktion) Input og output til servicemodeller Input De primære input kilder til definition af servicemodeller er naturligvis de 2 foregående niveauer, specielt tabellerne fra niveau 2. Der er formodentligt nogle tværgående økosystemer, som tidligere diskuteret i afsnit 4.2.3, som er fælles for en række af de økosystemer virksomheden indgår i. Disse økosystemer og deres servicemodeller er derfor også vigtige inputs til det videre arbejde med de resterende økosystemer. Infrastrukturmæssige overvejelser, som besluttes i løbet af servicemodelorkestreringen, kan blandt andet være valg af service bus, sikkerhedskomponenter til styring af single sign-on og flere andre, hvilket naturligvis vil være en del infrastruktur økosystemet, jf. afsnit De komponenter, der eksisterer eller indkøbes, skal kunne mappes op mod de opgaver, som det er økosystemets formål at løse. Derudover er det også nødvendigt, at der er et krav til infrastrukturen, om at denne skal kunne udvides med flere komponenter fremover. Konsekvensen vil ellers kunne være, at man bevæger sig fra én brændende platform til en anden, hvilket tildels

128 116 Kapitel 4. Modelopbygning kan undgå ved at koble sine systemer løst, både i kraft af servicemodeller og service kontrakter. Hele arbejdet med økosystemer og servicemodeller vil, alt andet lige, blive en hel del lettere hvis en virksomhed har en veletableret EA funktion og en veldokumenteret EA, da der er stort behov for en koordinerende enhed samt at EA artefakterne vil være yderst anvendelige i orkestrereringen af servicemodellerne. Hvis man i en virksomhed ikke har EA lignende tiltag, så forestår der en lang række forudsættende aktiviteter, før man reelt kan begynde at orkestrere sine servicemodeller. Specifikke artefakter til definition og orkestrering af servicemodeller er umiddelbart definitioner af data (informations- eller dataarkitektur), anvendte standarder, fælles definitioner af fælles begreber samt andre problematikker, afhængigt af de involverede servicemodeller. Tanken bag orkestreringen af servicemodeller kan sammenlignes med sammensatte services, og de servicekontrakter der forbinder de deltagende services. Det er ikke specielt interessant, hvordan de respektive services er implementeret, så længe de overholder deres service kontrakter. På samme måde er det ikke specielt interessant hvordan de enkelte servicemodeller er specificeret, de skal bare kunne leve op til deres forpligtelser internt og eksternt i økosystemer. Output Outputtet fra niveau 3 vil være en velbeskrevet arkitektur, der tager udgangspunkt i orkestreringen af servicemodeller, som tager højde for de mange forskellige relationer mellem økosystemer og deres indeholdte processer og IT systemer. P niveau 2 blev der koblet processer og IT systemer på de opgaver, der er centrum for økosystemerne, ud fra hvilke man kunne specificere et behov for, hvilke services der ville være nødvendige i forhold til de opgaver, der skal løses i økosystemerne. Outputtet af niveau 3 er, baseret på inputtet fra niveau 2, en kravspecifikation på hvilke services der skal udbydes og hvordan de skal tale sammen ved hjælp af deres servicemodeller. Jævnfør afsnit er der enkelte økosystemer, hvor det ikke er specielt relevant at udbyde services, som eksempelvis et organisatorisk økosystem dannet omkring opgaver relateret til organisation, proces og styring. Fra sådanne økosystemer er kravspecifikation af services ikke det vigtigste output, men nærmere et governance værktøj til at styre og guide selve implementeringen og udviklingen af den service orienterede arkitektur. Under orkestreringen af servicemodellerne, og udarbejdelsen af de respektive service kravspecifikationer, vil det også være nødvendigt at foretage en case-to-case

129 4.6. Niveau 3 Servicemodeller 117 vurdering af service granularitet 33 og andre tekniske design time overvejelser. Som i de foregående niveauer vil vi også her tilbyde en ikke-udtømmende liste af forventede output fra niveau 3: En reference arkitektur baseret på servicemodelorkestrering Service kravspecifikationer En projektplan baseret på strategier og prioritering af økosystemer Governance struktur, der understøtter ændringer af servicemodeller 34 En række spørgsmål til modenhedsvurdering af niveau 3, kunne være følgende, med et enkelt spørgsmål eksemplificeret i figur 4.14 (p. 117): Er der defineret en fælles servicemodel for alle økosystemer? Er der klar sammenhæng i økosystemernes servicemodeller? Er der defineret en prioriteret plan for pilotprojekter? Er der defineret og dokumenteret en proces for ændringer til servicemodeller? Er der ud arbejdet kravspecifikationer til ønskede service jf. niveau 2? Figur 4.14: Eksempelvise spørgsmål til Niveau 3 33 Granularitet referer til den laveste dimension af en service. Det vil sige, at det er problematikken omkring hvor bredt eller snævert, man skal definere en service, for at den skal kunne genbruges mest eller bedst muligt. 34 Såsom Life cycle management, versionering, change request o.l.

130 118 Kapitel 4. Modelopbygning 4.7 Niveau 4 Initial arkitekturimplementering På dette niveau er det første gang man reelt påbegynder at implementere SOA. De foregående 3 niveauer indholder de strategiske og forretningsmæssige overvejelser, som vi indledningvis efterlyste i dette kapitel. Der er allerede adskillige modeller, der beskæftiger sig med implementeringen af SOA, og indholdet i de efterfølgende niveauer er reelt et afkog af, hvad andre allerede har overvejet. Som udgangspunkt anvender vi Sonics modenhedsmodel, jf. afsnit 2.4.2, og vil indrage andre modenhedmodeller beskrevet tidligere i afsnit 2.4.1, hvor det findes relevant. Vores niveau 4, kan på mange måder sammenlignes med andre modellers niveau 1 til 3. Vi er efter omfattende planlægning parat til at lave de pilotprojekter og erfaringsdannelser, som anbefales langt tidligere af de fleste andre modeller. I faserne 1 til 3 i Sonics modenhedsmodelmodel, jf. afsnit 2.4.2, er indholdet af disse faser primært fokuseret på at få specificeret, hvilke services og standarder man skal udvikle og anvende. Disse overvejelser har vi allerede på plads, med baggrund i definitionerne af vores økosystemer og deres orkestrerede servicemodeller. Formålet med vores modenhedsniveau 4 er at få verificeret vores arkitektur, som er udfaldet af det foregående niveau 3. Denne godkendelse af arkitekturen udføres, da vi ikke forestiller os at det er realistisk muligt at orkestere en bred vifte af servicemodeller uden at lave fejl. Vi vil derfor påbegynde pilotprojekter for at få verificeret arkitekturen og for at afklare, om man skal tilbage og ændre i outputtet fra niveau 3. Disse iterationer er dog ikke del af modenhedsmodellen, men er en del af roadmap processen Input og Output Input Input til dette modenhedsniveau er de orkestrerede servicemodeller, kravespecifikationer på services og de andre outputs fra niveau 3. Dette er den indledende implementering af arkitekturen, hvorfor der vil kunne gøres god brug af de styringsprocesser, der vil være defineret i et tværgående økosystem, idet der sikkert vil være nødvendigt at lave tilbageløb mellem niveau 3 og 4.

131 4.8. Niveau 5 Arkitekturimplementering 119 Output Baseret på prioritering af økosystemer, opgaver og processer, udføres der er en række pilotprojekter. Formålet med disse pilotprojekter er at få testet orkestreringen af servicemodellerne fra niveau 3 igennem, så man kan nå at rette eventuelle uhensigtsmæssigheder. Efter pilotprojekterne er vel gennemførte, kan arkitekturen godkendes, og derved er det muligt at implementere i stor stil. Udfaldet af dette niveau er derfor en række økosystemer med godkendte servicemodeller, der er klar til implementering i fuld skala. I stil med de tidligere niveauer, tilbydes også her en ikke-udtømmende liste af spørgsmål til evaluering af niveau 4 modenhed, samt et eksempelvis spørgsmål (figur 4.15 (p. 119)): Figur 4.15: Eksempelvise spørgsmål til Niveau 4 Hvor mange økosystemer har godkendte servicemodeller? Er der velbeskrevne change requests til servicemodeller fra niveau 3? 35 Er der en prioriteret plan over implementering af økosystemer og deres afhængigheder? Niveau 5 Arkitekturimplementering På dette niveau forestiller vi os en fuld udrulning af SOA baseret på de godkendte økosystemer og deres servicemodeller fra niveau 4. Økosystemernes implementering bør ske efter den prioriterede liste af økosystemer fra niveau 4, efter hvilken også økosystemerne er blevet godkendt. Dette gør, at en virksomhed reelt kan begynde at implementere eksempelvis infrastruktur før alle 35 Defineres i de tværgående økosystemer. 36 Denne projektplan kommer fra niveau 2, men der er antageligvis behov for løbende opdateringer.

132 120 Kapitel 4. Modelopbygning økosystemer er blevet godkendt. Dette kan frembringe nogle problematikker, idet økosystemer, der endnu ikke er godkendte, kan have indvirkning på infrastrukturen, hvilket må håndteres via de processer, der er defineret i organisationsøkosystemet, se afsnit Dette er blandt andet en af grundene til, at vi mener, at de to tværgående økosystemer bør prioriteres højt (men ikke højest) i niveau 1, da de er forudsættende for at den efterfølgende implementering kommer til at forløbe fornuftigt. Udover at implementere sin arkitektur på dette niveau, så er det også nødvendigt at have et overblik over, hvor langt man er fra at nå sine forretningsmæssige og strategiske mål (se punktopstilling med eksempelvise målsætninger p. 102), fastlagt i niveau 1. Ved at udføre en gap analyse 37, mellem SOA strategien og realiteterne, kan man identificere, hvor der er mangler og i- værksætte initiativer til forbedring. Det antages der via disse gap-analyser vil kunne komme nogle yderligere krav til eksempelvis infrastrukturen, hvorfor dennes servicemodel naturligvis skal opdateres tilsvarende. Vi forestiller os at forbedringstiltag i slutningen af dette niveau ville kunne være behov for virtualisering af services og load-balancing af populære services, hvilket kræver, at man kan måle på performance på services og processer. Alt afhængigt af hvilke opgaver infrastrukturen har skullet løse i niveau 3, så er disse komponenter måske allerede inkluderet i et infrastrukturs økosystem. Input Inputtet til dette niveau kommer primært fra de foregående niveauer, primært niveau 3 og 4, da vi i realiteten implementerer arkitekturen, der er blevet planlagt og verificeret på de underliggende niveauer. Output Outputtet er, hvis alt går vel, en velfungerende økosystems-baseret SOA, hvor SOA strategien og de affødte business cases er blevet indfriet. Mere specifikt vil et reelt output løbende være en gap analyse, som over tid vil blive implementeret i de foregående niveauer. I stil med de forgående niveauer vil vi også her givet nogle bud på nogle modenhedsspørgsmål. samt et eksempel på et spørgsmål (figur 4.16 (p. 121)). 37 Hvor virksomheden sammenligner sin nuværende målopfyldelse med sin potentielle målopfyldelse.

133 4.9. Niveau 6 Optimeret Økosystem med SOA 121 Hvor mange af de prioriterede økosystemer er implementeret? I hvilken grad er SOA strategien blevet indfriet? Er der foretaget gap analyse og er der en prioriteret liste over ønskede forbedringer? Hvor mange deltagere i økosystemet udveksles der data med via services? Figur 4.16: Eksempelvise spørgsmål til Niveau Niveau 6 Optimeret Økosystem med SOA Dette niveau kan man referere til som Nirvana, og det er tvivlsomt om det i det hele taget er realistisk at nå til dette niveau. Dette niveau kan sammenlignes med IBMs SIMM niveau 7 (jf. figur 2.2 (p. 37)), hvor man kan automatisk kan rekonfigurere arkitekturen og få denne til at tilbyde services på baggrund af policies. Ikke overraskende er dette niveau ikke specielt veldefineret i de modeller vi har undersøgt, hvilket sandsynligvis skyldes, at der er et godt stykke vej før man kan opnå disse drømme. Forhåbningen på dette niveau er, at forretningen kan definere en række policies, som automatisk bliver implementeret i arkitekturen og måske udbudt som services, hvis en eller anden forretningsmæssig situation opstår. Over tid, som SOA implementeringer og succeser bliver mere generelle vil der helt sikkert kunne tilføjes en mere nøjagtig beskrivelse af indholdet af dette niveau. Hvorom alting er, forventer vi at indholdet af en modenhedsmodels sidste niveau altid vil være uopnåeligt, da der altid skal være et højere niveau at stræbe i mod. Vi formoder, at som erfaringerne udvikles, vil de komponenter, der er en del af dette niveau, på sigt vil blive flyttet ned på niveau 5 i takt med, at de bliver mere almindelige.

Projektledelse i praksis

Projektledelse i praksis Projektledelse i praksis - Hvordan skaber man (grundlaget) for gode beslutninger? Martin Malis Business Consulting, NNIT mtmi@nnit.com 20. maj, 2010 Agenda Project Governance Portfolio Management Project

Læs mere

Byg din informationsarkitektur ud fra en velafprøvet forståelsesramme The Open Group Architecture Framework (TOGAF)

Byg din informationsarkitektur ud fra en velafprøvet forståelsesramme The Open Group Architecture Framework (TOGAF) Byg din informationsarkitektur ud fra en velafprøvet forståelsesramme The Open Group Framework (TOGAF) Otto Madsen Director of Enterprise Agenda TOGAF og informationsarkitektur på 30 min 1. Introduktion

Læs mere

Bilag 12 - Fælles arkitekturramme for GD1-GD2-GD7. OIO Serviceprincipper

Bilag 12 - Fælles arkitekturramme for GD1-GD2-GD7. OIO Serviceprincipper Bilag 12 - Fælles arkitekturramme for GD1-GD2-GD7 OIO Serviceprincipper Version: 1.1 Status: i høring i PF for GD1 og GD2 Oprettet: 4. juni 2014 Dato: 4. juni 2014 Dokument historie Version Dato Beskrivelse

Læs mere

Fra ERP strategi til succesfuld ERP implementering. Torben Storgaard HerbertNathan & Co

Fra ERP strategi til succesfuld ERP implementering. Torben Storgaard HerbertNathan & Co Fra ERP strategi til succesfuld ERP implementering Torben Storgaard HerbertNathan & Co ERP - realisér morgendagens gevinster + Leveringstid Omkostninger Kundeservice + + Hvem er brugere af ERP i dag? @

Læs mere

Forberedelse. Forberedelse. Forberedelse

Forberedelse. Forberedelse. Forberedelse Formidlingsopgave AT er i høj grad en formidlingsopgave. I mange tilfælde vil du vide mere om emnet end din lærer og din censor. Dæng dem til med fakta! Det betyder at du skal formidle den viden som du

Læs mere

Oplæg ved AEA - EA netværk EA i Gentofte Kommune. På ITU den 6 marts 2013

Oplæg ved AEA - EA netværk EA i Gentofte Kommune. På ITU den 6 marts 2013 Oplæg ved AEA - EA netværk EA i Gentofte Kommune På ITU den 6 marts 2013 CV Sarah Ebler - Enterprise Arkitekt Gentofte Kommune Erhvervserfaring: Enterprise Architect - Gentofte Kommune - 01.10.2011 - nuværende

Læs mere

KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB

KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB Det er Web Services, der rejser sig fra støvet efter Dot Com boblens brag. INTRODUKTION Dette dokument beskriver forslag til fire moduler, hvis formål

Læs mere

FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø

FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø Høringssvar vedr. FESD GIS-integrationsmodel version 2.0 Geodata Danmark har

Læs mere

make connections share ideas be inspired

make connections share ideas be inspired make connections share ideas be inspired Integration af prædiktive analyser og operationelle forretningsregler med SAS Decision Manager Kristina Birch, chefkonsulent Professional Services, Banking & Mortgage

Læs mere

Kendskabet til converged systems er endnu lavt, da næsten halvdelen af IT beslutningstagerene ikke kender til konceptet.

Kendskabet til converged systems er endnu lavt, da næsten halvdelen af IT beslutningstagerene ikke kender til konceptet. Survey Resumé IDC Nordic, Bredgade 23A 3. 1260 Copenhagen K, Denmark & Upplandsgatan 7, 111 23 Stockholm, Sweden Converged Systems i Danmark Kendskab og præferencer Anders Elbak June 2013 Dette dokument

Læs mere

Konference om Cloud Computing 18. maj 2011. Proof of Concept for transition til Cloud Lars Ravndrup Thomsen, Solutions Architect, KMD

Konference om Cloud Computing 18. maj 2011. Proof of Concept for transition til Cloud Lars Ravndrup Thomsen, Solutions Architect, KMD Konference om Cloud Computing 18. maj 2011 Proof of Concept for transition til Cloud Lars Ravndrup Thomsen, Solutions Architect, KMD POC, hvad er det? En søgning på internettet viser, at de fleste sites

Læs mere

SOA i Lægemiddelstyrelsen - fra spaghetti til lasagne. Mikael Bay Skilbreid, leder af facility management og it IBM Softwaredag 2006

SOA i Lægemiddelstyrelsen - fra spaghetti til lasagne. Mikael Bay Skilbreid, leder af facility management og it IBM Softwaredag 2006 SOA i Lægemiddelstyrelsen - fra spaghetti til lasagne Mikael Bay Skilbreid, leder af facility management og it IBM Softwaredag 2006 19. september 2006 Agenda Udfordringer overvejelser om SOA Visionen driver

Læs mere

Agil test tilgang - erfaringer fra projekter

Agil test tilgang - erfaringer fra projekter Agil test tilgang - erfaringer fra projekter af Michael Roar Borlund November 2011 Image Area Agenda Introduktion Agil test Fremtidsvision Agil test tilgang Agil opbygning i QC Resumé og Spørgsmål 2 Introduktion

Læs mere

NNIT PLAYMAKER. PLAYMAKER Et redskab til aktiv refleksion over din holdsætning, din placering på banen og dine målchancer.

NNIT PLAYMAKER. PLAYMAKER Et redskab til aktiv refleksion over din holdsætning, din placering på banen og dine målchancer. NNIT PLAYMAKER PLAYMAKER Et redskab til aktiv refleksion over din holdsætning, din placering på banen og dine målchancer. FORMÅL NYE PERSPEKTIVER OG MULIGHEDER It-rollen er under stærk forandring, påvirket

Læs mere

- Få mest muligt ud af opgaveskrivningen!

- Få mest muligt ud af opgaveskrivningen! - Få mest muligt ud af opgaveskrivningen! En eksamensopgave Forarbejdet Opgaveformuleringen Disposition og layout Dokumentation Selvstændighed Abstract Vurderingskriterier Alle regler står i pjecen om

Læs mere

Forberedelse. Forberedelse. Forberedelse

Forberedelse. Forberedelse. Forberedelse Formidlingsopgave AT er i høj grad en formidlingsopgave. I mange tilfælde vil du vide mere om emnet end din lærer og din censor. Dæng dem til med fakta. Det betyder at du skal formidle den viden som du

Læs mere

Balancen mellem de interne nødvendigheder og de eksterne påvirkninger reguleres i kommunens it-strategi som præsenteres herunder.

Balancen mellem de interne nødvendigheder og de eksterne påvirkninger reguleres i kommunens it-strategi som præsenteres herunder. It-strategi 1.0 Indledning Flere og flere forretningsprocesser i kommunerne stiller krav til it-understøttelse, og der er store forventninger til at den offentlige sektor hænger sammen inden for it-området.

Læs mere

Service Orienteret Arkitektur en succes, der i stigende grad kræver IT Governance fokus

Service Orienteret Arkitektur en succes, der i stigende grad kræver IT Governance fokus Service Orienteret Arkitektur en succes, der i stigende grad kræver IT Governance fokus 4. oktober 2006 C O N N E C T I N G B U S I N E S S & T E C H N O L O G Y DEVOTEAM i Danmark og i Europa 2 Devoteam

Læs mere

Bilag. Resume. Side 1 af 12

Bilag. Resume. Side 1 af 12 Bilag Resume I denne opgave, lægges der fokus på unge og ensomhed gennem sociale medier. Vi har i denne opgave valgt at benytte Facebook som det sociale medie vi ligger fokus på, da det er det største

Læs mere

Solutions Day. IT Service Management. Globeteam ITSM

Solutions Day. IT Service Management. Globeteam ITSM Solutions Day IT Service Globeteam ITSM Indhold IT Service Introduktion til ITSM og ITIL Angrebsvinkel til ITIL Case - Kriminalforsorgen ITSM værktøjer Afrunding Hans Christian Holst ITSM konsulent hch@globeteam.com

Læs mere

Uddannelse: Født: 1973

Uddannelse: Født: 1973 Uddannelse: Bopæl: HD Smørum Født: 1973 Civilstand: Sprog: Gift, 2 børn Dansk, engelsk, svensk og norsk Introduktion: NJ er certificeret projektleder med fokus på infrastruktur-, implementerings-, migrerings-,

Læs mere

Uge 5.3: (Search,) Select & implement and development methods

Uge 5.3: (Search,) Select & implement and development methods Innovationsprocesser Uge 5.3: (Search,) Select & implement and development methods A A R H U S U N I V E R S I T E T Department of Computer Science 1 Innovation & ICT development *** Innovation *** * ***

Læs mere

Tips og vejledning vedrørende den tredelte prøve i AT, Nakskov Gymnasium og HF

Tips og vejledning vedrørende den tredelte prøve i AT, Nakskov Gymnasium og HF Tips og vejledning vedrørende den tredelte prøve i AT, Nakskov Gymnasium og HF Den afsluttende prøve i AT består af tre dele, synopsen, det mundtlige elevoplæg og dialogen med eksaminator og censor. De

Læs mere

Delaflevering FUA.4 Betina Korsbro, Mi Louise Hansen, Jesper Led Lauridsen og Knud Back

Delaflevering FUA.4 Betina Korsbro, Mi Louise Hansen, Jesper Led Lauridsen og Knud Back Delaflevering FUA.4 Betina Korsbro, Mi Louise Hansen, Jesper Led Lauridsen og Knud Back 1 Indhold 1.1 Generelt i forhold til projektet 1.1.1 Problemformulering Kalundborg kommune har gennem de senere år

Læs mere

Analyse af capabiliteter

Analyse af capabiliteter Analyse af capabiliteter Ressourceanalysen deles op indenfor fire områder [s245]: Kapitel 6: Analysing resources basics Kapitel 7: Analysing human resources Kapitel 8: Analysing financial resources Kapitel

Læs mere

Udfordringer og problemstillinger. En liste over de udfordringer og problemstillinger, der er ved Java og JEE udvikling

Udfordringer og problemstillinger. En liste over de udfordringer og problemstillinger, der er ved Java og JEE udvikling Java og JEE 1 2 Udfordringer og problemstillinger En liste over de udfordringer og problemstillinger, der er ved Java og JEE udvikling 3 Generelt om Java og JEE 4 Generelt, I Man undervurderer hvor mange

Læs mere

IT-strategi og ROI baseret på IT

IT-strategi og ROI baseret på IT IT-strategi og ROI baseret på IT Indhold Udarbejdelse af en IT-strategi Udarbejdelse af en ROI-case til ledelsen (business case) Praktisk eksempel på Case forløb 10-05-2012 EG Copyright 2 Faser i udarbejdelse

Læs mere

Hvordan flytter Økonomi ud af baglokalet og hen til beslutningsbordet?

Hvordan flytter Økonomi ud af baglokalet og hen til beslutningsbordet? Hvordan flytter Økonomi ud af baglokalet og hen til beslutningsbordet? Hvad er business partnering? Den rolle Økonomi påtager sig for at understøtte forretningen, øge kvaliteten af beslutningsprocessen

Læs mere

Hvordan sikres investeringen i eksisterende systemer, når skyen tages i brug. Carsten Rasmussen, CTO, Capgemini Danmark A/S IDC Cloud Computing 2011

Hvordan sikres investeringen i eksisterende systemer, når skyen tages i brug. Carsten Rasmussen, CTO, Capgemini Danmark A/S IDC Cloud Computing 2011 Hvordan sikres investeringen i eksisterende systemer, når skyen tages i brug Carsten Rasmussen, CTO, Capgemini Danmark A/S IDC Cloud Computing 2011 Formål og agenda Formål Vi vil på denne workshop diskutere:

Læs mere

Serviceorienteret arkitektur - Hvad og hvorfor

Serviceorienteret arkitektur - Hvad og hvorfor > Serviceorienteret arkitektur - Hvad og hvorfor IT- & Telestyrelsen November 2006 Indhold > Forord 6 1. Indledning 7 1.1 Formål og baggrund 7 1.2 Målgruppe 8 1.3 Pjecens struktur 8 Del 1 - SOA i den offentlige

Læs mere

Pains. Gains. We offer SAP advisory services helping Your company to eliminate Your painpoints and gaining the most out of Your SAP investments

Pains. Gains. We offer SAP advisory services helping Your company to eliminate Your painpoints and gaining the most out of Your SAP investments + We offer SAP advisory services helping Your company to eliminate Your painpoints and gaining the most out of Your SAP investments Pains Pain Relievers Gains Gain Creators We help businesses gaining benefits

Læs mere

Ydelseskatalog. Tak fordi du downloadede dette dokument vores ydelseskatalog. Vi hjælper dig helt i mål! Ydelseskatalog. Indhold

Ydelseskatalog. Tak fordi du downloadede dette dokument vores ydelseskatalog. Vi hjælper dig helt i mål! Ydelseskatalog. Indhold Indhold 2 Business intelligence workshops 3 Customer Intelligence workshops 4 at få flere kunder 5 at kunne vækste sine kunder 6 at kunne fastholde sine kunder 7 Generelt om segmentering 8 Behovsbasere

Læs mere

Uddrag af artikel trykt i Offentlig Ledelse. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret.

Uddrag af artikel trykt i Offentlig Ledelse. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret. Offentlig Ledelse Uddrag af artikel trykt i Offentlig Ledelse. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret. Børsen Ledelseshåndbøger er Danmarks største og

Læs mere

Service Orienteret Arkitektur

Service Orienteret Arkitektur Service Orienteret Arkitektur Datalogisk Institut 22. november 2004 v/ Vidensleverandør Henrik Hvid Jensen, SOA Network henrikhvid@soanetwork.dk (c) SOA Network, 2004 1 Indførelse af et servicelag (c)

Læs mere

Security as a Service hvorfor, hvornår og hvordan. Gorm Mandsberg, gma@dubex.dk Aarhus, 13.06.2013

Security as a Service hvorfor, hvornår og hvordan. Gorm Mandsberg, gma@dubex.dk Aarhus, 13.06.2013 Security as a Service hvorfor, hvornår og hvordan Gorm Mandsberg, gma@dubex.dk Aarhus, 13.06.2013 SecaaS hvorfor, hvornår og hvordan hvad Hvorfor.. Hvornår.. Hvordan.. Disclamer: Dubex er MSSP og leverer

Læs mere

Velkommen. Program: Oplæg om emnet baseret på Best Practice (ITIL) Refleksion

Velkommen. Program: Oplæg om emnet baseret på Best Practice (ITIL) Refleksion Driftskontrakter Hvordan sikrer man sig, at man får en ordentlig driftskontrakt? Hvad skal man være opmærksom på, og hvornår begynder man egentlig at tænke den ind? Velkommen Program: Oplæg om emnet baseret

Læs mere

It-delstrategi for administrativ it-anvendelse

It-delstrategi for administrativ it-anvendelse Administrativ DELSTRATEGI 2011-2015 NOTAT It-delstrategi for administrativ it-anvendelse 9. september 2011 Indholdsfortegnelse 1. Formål...2 2. Baggrund...2 3. Vision...3 4. Strategisk retning...3 4.1.

Læs mere

Introduktion til NNIT

Introduktion til NNIT Introduktion til NNIT IT-kontraktsnetværk 18. august 2014 PUBLIC Kort fortalt En af Danmarks fire største leverandører af itservices Vi leverer udvikling, implementering og drift til life sciences, finanssektoren,

Læs mere

Det danske ERP marked

Det danske ERP marked Det danske ERP marked ComputerCamp seminar 25. marts 2009 Herbert Nathan Indhold Introduktion til HerbertNathan & Co Nogle indledende system begreber ERP-markedet leverandører og trends Hvorfor anskaffe

Læs mere

Værdibaseret styring og optimering af projektporteføljen

Værdibaseret styring og optimering af projektporteføljen 17. April 2007 Værdibaseret styring og optimering af projektporteføljen Programchef Thomas Steinmetz, G4S Teamleder Charlotte Blou Sand, Creuna Copyright Creuna Danmark A/S Om Creuna Skandinavisk IT-konsulenthus

Læs mere

Fremtidsmodel (Blueprint) - Vejledning

Fremtidsmodel (Blueprint) - Vejledning Fremtidsmodel (Blueprint) - Vejledning Januar 2014 Indhold 1. FORKLARING PÅ CENTRALE BEGREBER... 3 2. HVAD ER FREMTIDSMODELLEN (BLUEPRINT)... 4 3. FORMÅLET MED FREMTIDSMODELLEN... 4 4. HVEM MODTAGER FREMTIDSMODELLEN...

Læs mere

Orientering om det engelske abstract i studieretningsprojektet og den større skriftlige opgave

Orientering om det engelske abstract i studieretningsprojektet og den større skriftlige opgave Fra: http://www.emu.dk/gym/fag/en/uvm/sideomsrp.html (18/11 2009) November 2007, opdateret oktober 2009, lettere bearbejdet af JBR i november 2009 samt tilpasset til SSG s hjemmeside af MMI 2010 Orientering

Læs mere

DA EN MAND FRA IT MØDTE EN MAND FRA MARKETING

DA EN MAND FRA IT MØDTE EN MAND FRA MARKETING DA EN MAND FRA IT MØDTE EN MAND FRA MARKETING EN LILLE KONKURRENCE Hvem stiller det bedste spørgsmål på Twitter? #ThorupMajlund AGENDA 1. Quiz med en suveræn præmie 2. Om os 3. Digital Transformation på

Læs mere

FORRETNINGSSTRATEGI SUNDHED.DK

FORRETNINGSSTRATEGI SUNDHED.DK FORRETNINGSSTRATEGI SUNDHED.DK INDHOLD 01 Om dokumentet 3 02 Sundhed.dk s forretning 4 02.1 Mission og vision 4 02.2 Sundhed.dk s position og marked 4 02.3 Sundhed.dk s fundament og leverancer 5 02.4 Målgrupper

Læs mere

Roadshow: ITIL V3. hvordan træder man ud af børneskoene?

Roadshow: ITIL V3. hvordan træder man ud af børneskoene? Roadshow: ITIL V3 hvordan træder man ud af børneskoene? Westergaard Management A/S Stifter Ole Westegaard Adm. Direktør Steen Sverker Nilsson Direktør Johnny Jensen Westergaard Management stiftedes den

Læs mere

Standardiseret tilgang til Software Asset Management. ISACA Medlemsmøde 2013 Jan Øberg ØBERG Partners

Standardiseret tilgang til Software Asset Management. ISACA Medlemsmøde 2013 Jan Øberg ØBERG Partners Standardiseret tilgang til Software Asset Management ISO19770 ISACA Medlemsmøde 2013 Jan Øberg ØBERG Partners 1 WG21 historien ISO19770 arbejder i WG21 under ISO Etableret i 2001 Første standard 19770-1

Læs mere

IMPLEMENTERINGSMODELLEN KORT OG GODT. Implementering af monopolbruddet

IMPLEMENTERINGSMODELLEN KORT OG GODT. Implementering af monopolbruddet IMPLEMENTERINGSMODELLEN KORT OG GODT Implementering af monopolbruddet Version 0.8, marts 2015 Indledning KOMBIT har udviklet en implementeringsmodel for at understøtte kommunernes succesfulde implementering

Læs mere

Vejledningen til proces for design af fremtidsmodellen

Vejledningen til proces for design af fremtidsmodellen Vejledningen til proces for design af fremtidsmodellen Januar 2014 Indhold 1. FORMÅL... 3 FORMÅLET MED DENNE PROCESVEJLEDNING... 3 2. FREMTIDSMODELLENS OMRÅDER... 3 2.1. AKTIVITETER... 4 DEFINER OVERORDNEDE

Læs mere

Aktstykke nr. 28 Folketinget 2009-10. Afgjort den 19. november 2009. Økonomi- og Erhvervsministeriet. København, den 9. november 2009.

Aktstykke nr. 28 Folketinget 2009-10. Afgjort den 19. november 2009. Økonomi- og Erhvervsministeriet. København, den 9. november 2009. Aktstykke nr. 28 Folketinget 2009-10 Afgjort den 19. november 2009 28 Økonomi- og Erhvervsministeriet. København, den 9. november 2009. a. Økonomi- og Erhvervsministeriet anmoder om Finansudvalgets tilslutning

Læs mere

WINDCHILL THE NEXT STEPS

WINDCHILL THE NEXT STEPS WINDCHILL THE NEXT STEPS PTC/user, 4. marts 2015 Jens Christian Jensen, Econocap Agenda Windchill the next steps Bliv opdateret og inspireret til at se hvor Windchill kan hjælpe dig med andet end blot

Læs mere

Flyvevåbnets kampfly. - nu og i fremtiden

Flyvevåbnets kampfly. - nu og i fremtiden Flyvevåbnets kampfly - nu og i fremtiden Danmark skal have nyt kampfly for: fortsat at kunne udfylde rollen som luftens politi over Danmark og imødegå evt. terrortrusler. fortsat at råde over et højteknologisk

Læs mere

ANALYSE AF SIKKERHEDSSTANDARDER OG -LØSNINGER

ANALYSE AF SIKKERHEDSSTANDARDER OG -LØSNINGER ANALYSE AF SIKKERHEDSSTANDARDER OG -LØSNINGER Kommunernes it-arkitekturråd 8. maj 2014 AGENDA Væsentligste observationer og konklusioner Relevans for kommuner STRATEGI OG ARKITEKTUR Analysen giver et bud

Læs mere

Hvordan udarbejdes en strategi

Hvordan udarbejdes en strategi LENNART SVENSTRUP Hvordan udarbejdes en strategi LENNART@KYOEVAENGET.DK 2011 Strategi Alle kan udarbejde en strategi! MEN: For at en strategi er noget værd i praksis, skal den tage udgangspunkt i virkeligheden,

Læs mere

Ud af krisen. Software på tværs, 15. juni 2009

Ud af krisen. Software på tværs, 15. juni 2009 Ud af krisen Software på tværs, 15. juni 2009 Om Ative Agile udvikling og rådgivning Klassisk udviklingsmodel Krav Design Ændrer sig Implementering Tager for lang tid Springes over Mareridt Test Deployment

Læs mere

Strategisk Overensstemmelse - en kort introduktion

Strategisk Overensstemmelse - en kort introduktion Strategisk Overensstemmelse, en kort introduktion 2008 Strategisk Overensstemmelse - en kort introduktion Omgivelser (marked) Segment Segment Segment Kunde interface Strategi Enhed Enhed Enhed Værdiskabelse

Læs mere

CSC Innovation Consulting. - Inspiration til innovative løsninger

CSC Innovation Consulting. - Inspiration til innovative løsninger : CSC Innovation Consulting - Inspiration til innovative løsninger INNOVATION Praktisk innovation skal være er et centralt element i vores samarbejde med kunder. Vores metode Vi baserer vores metode på

Læs mere

IT-Universitetet, Projekt- og Programledelse November 2013 AGIL PROGRAMLEDELSE 13-11-2013 1

IT-Universitetet, Projekt- og Programledelse November 2013 AGIL PROGRAMLEDELSE 13-11-2013 1 IT-Universitetet, Projekt- og Programledelse November 2013 AGIL PROGRAMLEDELSE 1 AGENDA Hvem snakker? De betydende faktorer Agil forretningsudvikling D60 leverancemodel - Bedrock Opsamling og? 2 Hvem snakker?

Læs mere

Udfordringer for cyber security globalt

Udfordringer for cyber security globalt Forsvarsudvalget 2013-14 FOU Alm.del Bilag 105 Offentligt Udfordringer for cyber security globalt Binbing Xiao, Landechef, Huawei Technologies Danmark Knud Kokborg, Cyber Security Officer, Huawei Technologies

Læs mere

Den røde tråd fra testdækning til releasemetrikker

Den røde tråd fra testdækning til releasemetrikker Den røde tråd fra testdækning til releasemetrikker The art of developing software cheaper, in good quality and at schedule Software-Pro Agenda Den røde tråd fra testdækning til releasemetrikker Mange har

Læs mere

IT-UNIVERSITETET I KØBENHAVN

IT-UNIVERSITETET I KØBENHAVN IT-UNIVERSITETET I KØBENHAVN KANDIDAT I IT & BUSINESS (E-Business) ITU.dk/uddannelser IT & BUSINESS (CAND.IT I E-BUSINESS) Kunne du tænke dig at arbejde i krydsfeltet mellem it og forretningsudvikling?

Læs mere

Morten Juul Nielsen Produktchef Microsoft Danmark

Morten Juul Nielsen Produktchef Microsoft Danmark Morten Juul Nielsen Produktchef Microsoft Danmark Er du, din organisation og dit datacenter klar til Skyen? Dynamisk Datacenter & Cloud Computing System Center Suiten med fokus på Service Manager Next

Læs mere

Det fleksible fællesskab

Det fleksible fællesskab Kultur Det fleksible fællesskab Kirsten Hastrup unı vers Kultur Det fleksible fællesskab Kultur Det fleksible fællesskab Af Kirsten Hastrup unıvers Kultur Det fleksible fællesskab er sat med Adobe Garamond

Læs mere

Kulturministeriets it-arkitekturpolitik

Kulturministeriets it-arkitekturpolitik Kulturministeriets Kulturministeriets Januar 2012 Udgivet af Kulturministeriet Udarbejdet af Kulturstyrelsen H.C. Andersens Boulevard 2 1553 København V www.kulturstyrelsen.dk post@kulturstyrelsen.dk Kulturministeriets

Læs mere

Nyhedsbrev om teknologi B og A på htx. Tema: Studieretningsprojektet

Nyhedsbrev om teknologi B og A på htx. Tema: Studieretningsprojektet Nyhedsbrev om teknologi B og A på htx Tema: Studieretningsprojektet Ministeriet for Børn og Undervisning Departementet Kontor for Gymnasiale Uddannelser September 2012 Hvorfor dette nyhedsbrev? I august

Læs mere

Manuskriptvejledning pr. 2015 Bachelorprisen

Manuskriptvejledning pr. 2015 Bachelorprisen Manuskriptvejledning pr. 2015 Bachelorprisen Fremsendelse af artikel Artikler skrevet på baggrund af bachelorprojekter, der er afleveret og bestået på det annoncerede tidspunkt, kan deltage i konkurrencen

Læs mere

Totally Integrated Automation. Totally Integrated Automation sætter standarden for produktivitet.

Totally Integrated Automation. Totally Integrated Automation sætter standarden for produktivitet. Totally Integrated Automation Totally Integrated Automation sætter standarden for produktivitet. Bæredygtighed sikrer konkurrenceevnen på markedet og udnytter potentialerne optimalt. Totally Integrated

Læs mere

4 sekunder. 20 sekunder. 1-3 timer. 14% hurtigere. 5-6% bagud. 30/70 split. Vejen til succes med Hybrid Cloud v/cso, Poul Bærentsen, Atea

4 sekunder. 20 sekunder. 1-3 timer. 14% hurtigere. 5-6% bagud. 30/70 split. Vejen til succes med Hybrid Cloud v/cso, Poul Bærentsen, Atea 4 sekunder 1-3 timer 20 sekunder 14% hurtigere 5-6% bagud 30/70 split Vejen til succes med Hybrid Cloud v/cso, Poul Bærentsen, Atea Emnerne jeg vil tale om Brændende platforme versus brændende ambitioner

Læs mere

Artikel trykt i ERP. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret.

Artikel trykt i ERP. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret. ERP Artikel trykt i ERP. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret. Børsen Ledelseshåndbøger er Danmarks største og stærkeste videns- og udviklingsklub.

Læs mere

Projektledelse. Uddrag af artikel trykt i Projektledelse. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret.

Projektledelse. Uddrag af artikel trykt i Projektledelse. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret. Projektledelse Uddrag af artikel trykt i Projektledelse. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret. Børsen Ledelseshåndbøger er Danmarks største og stærkeste

Læs mere

Rating af organisatoriske udfordringer i forbindelse med implementering af it-systemer

Rating af organisatoriske udfordringer i forbindelse med implementering af it-systemer Rating af organisatoriske udfordringer i forbindelse med implementering af it-systemer delmængde af implementeringskonceptet fra Region Hovedstaden/ v Therese Lundsgaard Formålet med at rate og beskrive

Læs mere

SUPPLY CHAIN INNOVATION

SUPPLY CHAIN INNOVATION KONKURRENCEKRAFT GENNEM SUPPLY CHAIN INNOVATION VÆRKTØJER Med afsæt i hovedrapporten har dette arbejdshæfte til formål, at belyse, hvordan danske virksomheder kan arbejde med supply chain innovation, gennem

Læs mere

Poster design. Meningen med en poster

Poster design. Meningen med en poster Poster design At præsentere et naturvidenskabelig emne er ikke altid lige nemt. Derfor bruges ofte plakater, såkaldte posters, til at fremvise forskning på fx messer eller konferencer. Her kan du finde

Læs mere

VidenForum Fokus på viden Viden i fokus

VidenForum Fokus på viden Viden i fokus VidenForum inviterer til seminarrække - Learn how to improve your intelligence and market analysis capabilities VidenForum har fornøjelsen at præsentere en række spændende seminarer i samarbejde med Novintel

Læs mere

Om forretningsmæssige kompetencer

Om forretningsmæssige kompetencer Om forretningsmæssige kompetencer Uddanner universiteterne kun i det de forsker i? DI, Industriens Hus - 22. september 2009 Jørn Johansen JoJ@delta.dk www.deltaaxiom.com www.delta.dk Tlf.: 72194421 1 Delta

Læs mere

Uddannelsesmodul for undervisere at vurdere læsefærdigheder. MODEVAL2 LdV TOI 2008 FR 117044

Uddannelsesmodul for undervisere at vurdere læsefærdigheder. MODEVAL2 LdV TOI 2008 FR 117044 Uddannelsesmodul for undervisere at vurdere læsefærdigheder MODEVAL2 LdV TOI 2008 FR 117044 Modeval2 er et Leonardo da Vinci innovation overførsel projekt, der henvises til i koden n LLP-LDV-toi-2008-FR-117.044.

Læs mere

Hos Lasse Ahm Consult vurderer vi at følgende supplerende krav i de enkelte kravelementer er væsentlige at bemærke:

Hos Lasse Ahm Consult vurderer vi at følgende supplerende krav i de enkelte kravelementer er væsentlige at bemærke: ISO 9001:2015 (Draft) Side 1 af 9 Så ligger udkastet klar til den kommende version af ISO 9001. Der er sket en række strukturelle ændringer i form af standardens opbygning ligesom kravene er blevet yderligere

Læs mere

3.g elevernes tidsplan for eksamensforløbet i AT 2015

3.g elevernes tidsplan for eksamensforløbet i AT 2015 Mandag d. 26.1.15 i 4. modul Mandag d. 2.2.15 i 1. og 2. modul 3.g elevernes tidsplan for eksamensforløbet i AT 2015 AT emnet offentliggøres kl.13.30. Klasserne er fordelt 4 steder se fordeling i Lectio:

Læs mere

Aspector v/morten Kamp Andersen. Hvorfor Talent Management? - argumenter og business case

Aspector v/morten Kamp Andersen. Hvorfor Talent Management? - argumenter og business case Aspector v/morten Kamp Andersen Hvorfor Talent Management? - argumenter og business case PROGRAM 1. Hvorfor er der (igen) fokus på Talent Management? 2. Hvad er Talent Management? 3. Hvad er business casen?

Læs mere

Strategic Management of Professional Service Firms

Strategic Management of Professional Service Firms Strategic Management of Professional Service Firms Bente R. Løwendahl Strategi AALBORG UNIVERSITET Det samfundsvidenskablige fakultet HD i Organisation og Ledelse 8. semester HDO Indhold 1 Professionelle

Læs mere

Principper for organisering af it-området i Koncernservice

Principper for organisering af it-området i Koncernservice Bilag 5 til rapport om Koncernservice Principper for organisering af it-området i Koncernservice Projektet har i sit arbejde diskuteret en række principielle forhold vedr. organiseringen af it-området

Læs mere

Fra konsensus- til performancekultur

Fra konsensus- til performancekultur Fra konsensus- til performancekultur Erfaringer med at udvikle en organisation November 2012 Forretningsområder Parallelimport af medicin i EU Salg af generiske lægemidler i EU Orifarm - en international

Læs mere

Vejledning - Udarbejdelse af gevinstdiagram

Vejledning - Udarbejdelse af gevinstdiagram Vejledning - Udarbejdelse af gevinstdiagram Maj 2015 INDHOLD 1. INDLEDNING... 1 1.1 FORMÅL... 1 1.2 VEJLEDNINGENS SAMMENHÆNG MED DEN FÆLLESSTATSLIGE IT-PROJEKTMODEL... 1 1.3 GEVINSTDIAGRAMMET... 2 1.4

Læs mere

LICENSMODELLER ÆNDRINGER OG RETLIGE UDFORDRINGER ÆNDREDE LICENSMODELLER - RETLIGE UDFORDRINGER 29. FEBRUAR 2015

LICENSMODELLER ÆNDRINGER OG RETLIGE UDFORDRINGER ÆNDREDE LICENSMODELLER - RETLIGE UDFORDRINGER 29. FEBRUAR 2015 LICENSMODELLER ÆNDRINGER OG RETLIGE UDFORDRINGER DAGSORDEN 1. Markedsudviklingen 2. Licensmodellernes udvikling i hovedtræk 3. SaaS det økonomiske fundament 4. SaaS - udvalgte eksempler på udfordringer

Læs mere

Idekatalog. Så vidt jeg husker fremgik det ret tydeligt hvad der skulle være i ansøgningen. Der var bare virkelig mange informationer der skulle med.

Idekatalog. Så vidt jeg husker fremgik det ret tydeligt hvad der skulle være i ansøgningen. Der var bare virkelig mange informationer der skulle med. Ansøgning Yderligere bemærkninger til ansøgningen Det var fedt at rammerne var så åbne, som jeg så det var der kun to krav til projektet: Det skulle være open source og det skulle have det offentliges

Læs mere

Application Management Service

Application Management Service Application Management Service I dette Whitepaper vil vi beskrive nogle af vores erfaringer med Application Management. De fleste virksomheder har på et tidspunkt lavet, eller fået lavet, en mindre applikation,

Læs mere

HYBRID TAKEOFF REDEFINED JOURNEY TO THE CLOUD BY EMC Søren Holm, Proact

HYBRID TAKEOFF REDEFINED JOURNEY TO THE CLOUD BY EMC Søren Holm, Proact HYBRID TAKEOFF REDEFINED JOURNEY TO THE CLOUD BY EMC Søren Holm, Proact More than 3500 projects In control of 55 petabyte data 450 certified consultants More than 1.5M euro in training per year 55 PB,

Læs mere

Samrådsspørgsmål. Akt 186

Samrådsspørgsmål. Akt 186 Samrådsspørgsmål Akt 186 Der ønskes en uddybende redegørelse for og en drøftelse af årsagerne til og konsekvenserne af den forventede meget betydelige fordyrelse og forsinkelse af projektet. Svar: Indledning

Læs mere

Fremtidens forskning og forskningsbiblioteket Resumé

Fremtidens forskning og forskningsbiblioteket Resumé Fremtidens forskning og forskningsbiblioteket Resumé Danmarks Elektroniske Fag- og Forskningsbibliotek Fremtidens forskning og forskningsbiblioteket Resumé Massive teknologiske forandringer inden for forskning,

Læs mere

Vejledning i projektledelse

Vejledning i projektledelse Dansk standard DS/ISO 21500 2. udgave 2013-09-27 Vejledning i projektledelse Guidance on project management DS/ISO 21500 København DS projekt: M268368 ICS: 03.100.40 Første del af denne publikations betegnelse

Læs mere

Guide til kravspecifikation

Guide til kravspecifikation Side 1 af 10 10. november 2008 Guide til kravspecifikation Version 1.0. Denne guide indeholder en række råd til brug i kravspecifikationer for IT systemer, der skal anvende NemLog-in løsningen. Hensigten

Læs mere

Sådan er fremtidens virtuelle arbejdsplads idag! Copyright 2011 Microsoft Corporation

Sådan er fremtidens virtuelle arbejdsplads idag! Copyright 2011 Microsoft Corporation Sådan er fremtidens virtuelle arbejdsplads idag! 5 tendenser der ændrer arbejdspladsen i fremtiden med IT. Giv dine medarbejdere Consumerization adgang til de applikationer af medarbejdere de har brug

Læs mere

Artikel trykt i ERP. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret.

Artikel trykt i ERP. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret. ERP Artikel trykt i ERP. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret. Børsen Ledelseshåndbøger er Danmarks største og stærkeste videns- og udviklingsklub.

Læs mere

En midlertidig organisation der etableres for at levere en eller flere leverancer til opnåelse af forandringsevne

En midlertidig organisation der etableres for at levere en eller flere leverancer til opnåelse af forandringsevne Sammenfattende definitioner Definition og beskrivelse Vision En portefølje er en samling af projekter/mer, som vurderes samlet med henblik på at optimere sammensætning og prioritering af strategiske indsatser

Læs mere

Dagens program. Digital formidling - med udgangspunkt i Ting. Proces og output. Projektbeskrivelserne. Walk the Talk - Formål

Dagens program. Digital formidling - med udgangspunkt i Ting. Proces og output. Projektbeskrivelserne. Walk the Talk - Formål Digital formidling - med udgangspunkt i Ting Den 22. april 2010 2. møde i det faglige udviklingsforum Dagens program Kl. 9 Velkomst og morgensang Kl. 9.15 Projekterne Kl. 10 Definition af Digital strategi

Læs mere

Slides fra studietur til Manchester Jacqueline Albers Thomasen, MacMann Berg jat@macmannberg.dk/ 51927879

Slides fra studietur til Manchester Jacqueline Albers Thomasen, MacMann Berg jat@macmannberg.dk/ 51927879 Slides fra studietur til Manchester Jacqueline Albers Thomasen, MacMann Berg jat@macmannberg.dk/ 51927879 Et par systemisk opmærksomheder Handlinger er relationelt forbundet med andre handlinger Alle er

Læs mere

Aalborg Universitet. Banker i Danmark pr. 22/3-2012 Krull, Lars. Publication date: 2012. Document Version Pre-print (ofte en tidlig version)

Aalborg Universitet. Banker i Danmark pr. 22/3-2012 Krull, Lars. Publication date: 2012. Document Version Pre-print (ofte en tidlig version) Aalborg Universitet Banker i Danmark pr. 22/3-2012 Krull, Lars Publication date: 2012 Document Version Pre-print (ofte en tidlig version) Link to publication from Aalborg University Citation for published

Læs mere

Den gode projektopgave

Den gode projektopgave Den gode projektopgave Rapporten er ikke projektet, men formidlingen af projektet Multimediedesigneruddannelsen Erhvervsakademi Aarhus Indhold Opgavens dele placeres således:... 3 Titelblad/ forside...

Læs mere

Vejledning - Udarbejdelse af gevinstdiagram

Vejledning - Udarbejdelse af gevinstdiagram Vejledning - Udarbejdelse af gevinstdiagram Januar 2014 INDHOLD 1. INDLEDNING... 1 1.1 FORMÅL... 1 1.2 VEJLEDNINGENS SAMMENHÆNG MED DEN FÆLLESSTATSLIGE IT-PROJEKTMODEL... 1 1.3 GEVINSTDIAGRAMMET... 2 1.4

Læs mere

Én IT løsning, mange fordele AX TRAVEL. - fremtidens rejsebureauløsning

Én IT løsning, mange fordele AX TRAVEL. - fremtidens rejsebureauløsning Én IT løsning, mange fordele - fremtidens rejsebureauløsning Privatejet virksomhed Etableret i 1987 100 % danskejet Hovedkontor i Allerød og kontor i Århus +80 medarbejdere Solid og positiv økonomi gennem

Læs mere