Enterprise Arkitektur og Serviceorienteret Arkitektur

Transkript

1 Enterprise Arkitektur og Serviceorienteret Arkitektur - En gennemgang i teori og praksis Af Jens Keld Trinskjær Lars Hansen IT-Universitetet EBUSS Enterprise Arkitektur F2007 Vejleder: John Gøtze Side 1 af 55

2 Indholdsfortegnelse Kapitel I - Indledning... 4 Problemformulering Afgrænsning Metode Læsevejledning Kapitel II - Begrebsafklaring Enterprise Arkitektur Hvad er en enterprise? Hvad er arkitektur? Definition af enterprise arkitektur Indholdet af en EA tilgang The Zachman Framework for Enterprise Architecture Kritik af Zachmans rammeværk Afsluttende bemærkninger Serviceorienteret arkitektur Hvad er serviceorienteret arkitektur? Definition Principperne bag SOA SOA - det tekniske perspektiv Delkonklusion: Kapitel III - Analyse Hvad er SOA modenhed? Modenhedsmodel for SOA SOA MM - en model for modenhed Enterprise arkitekturen vs. SOA Zachman og SOA SOA indflydelse på EA? Teknologiperspektivet Applikationsperspektivet Forretningsperspektivet Informationsperspektivet Hvordan påvirker SOA øvrige elementer i rammeværket? Opsummering - SOA i forhold til EA Enterprise arkitektur som ramme for SOA Delkonklusion: Kapitel IV belysning af cases Side 2 af 55

3 Den Danske Banks arkitekturindsats Løsningen Interview med Claus Torp Jensen Danmarks Radios Arkitekturindsats Interviewet En sammenstilling af Danske Banks og Danmarks Radios arkitekturindsatser...46 En udvikling nedefra? Relationen mellem EA og SOA Modenhed Delkonklusion Kapitel V belysning af hypoteser Undersøgelse af de tre hypoteser Hypotese Hypotese Hypotese Kapitel VI Konklusion Side 3 af 55

4 Kapitel I - Indledning Ordet arkitektur fortjener med rette betegnelsen Buzzword inden for IT-verdenen. Begrebet bruges nu i flæng i en masse sammenhænge. To af de mest omtalte arkitekturbegreber i øjeblikket er Enterprise Arkitektur (EA) og Serviceorienteret Arkitektur (SOA). Der er opstået en massiv "hype" omkring specielt SOA, der tilsynelandende kan anvendes til at sælge hvad som helst inden for ITbranchen. Til alt held er det lykkedes os at skabe kontakt til to af landets største virksomheder, der oveni købet begge har stor erfaring med SOA, i form af Danske Bank (DB) og Danmarks Radio (DR). Vi har derfor muligheden for at kombinere teori og empiri i undersøgelsen af relationen mellem to begreber, der om nogen er med til at forme IT-udviklingen i øjeblikket - både her i landet og på verdensplan. Derfor vil vi i denne opgave belyse hvorledes EA kan anvendes som ramme for SOA, men også hvorledes SOA kan påvirke EA. Problemformulering I denne opgave ønsker vi overordnet at undersøge sammenhængen mellem Enterprise arkitekturen og den service-orienterede arkitektur, herunder: 1. Hvordan påvirker EA og SOA hinanden konceptuelt? 2. Hvordan har casevirksomhederne i praksis anvendt EA i arbejdet med SOA - og omvendt? 3. Er der overensstemmelse mellem teori og praksis vurderet ud fra den tilgængelige empiri? Vi vil undervejs bl.a. undersøge ligheder og forskelle inden for forskellige områder blandt andre det typiske forløb, som SOA- og EA-processer gennemgår, hvilke drivers der driver udviklingen af koncepterne, og hvad begreberne indeholder. Side 4 af 55

5 Afgrænsning Det er selvfølgelig sådan, at vi har måttet udelade nogle emner for at kunne gå i dybden med andre. Da vi ønsker at belyse en udvikling af de to centrale begreber, EA og SOA, er det naturligt at inddrage modenhedsmodeller. Vi inddrager dog kun modenhedsmodeller, der beskriver SOA-modenhed. Det skyldes, at udgangspunktet for vores undersøgelse af udviklingsforløbet har baggrund i den præmis, at relationen mellem SOA og EA forandres, efterhånden som SOA modnes. Derudover kan EA fungere både som en dokumentationsmetode og et styringsværktøj. I vores analyse fokuserer vi primært på EA som en dokumentationsmetode. Den simple årsag bag dette valg er ønsket om at sikre dybden i opgaven før bredden. Metode Opgavens første del er en begrebsafklaring, der har til formål at sikre enighed om indholdet i de anvendte begreber. I forlængelse af begrebsafklaringen gennemfører vi en analyse baseret herpå, som undersøger den teoretiske relation mellem begreberne i opgaven. Denne teoretiske analyse bruger vi til at formulere en række hypoteser, der udgør grundlaget for den resterende del af opgaven. Efterfølgende gennemgår vi vores empiri. Man kunne have valgt at transskribere begge interviews i deres fulde længde og vedlægge dem som bilag. I stedet har vi valgt at skrive to referater, hvor analysen indgår som en integreret del. Dette har vi valgt, da det giver læseren en naturlig gennemgang af materialet og gerne skulle øge læsevenligheden. I sidste del undersøger vi, om vores hypoteser kan be- eller afkræftes af den fremskaffede empiri. Det bør bemærkes, at vores indsamling af empirisk materiale har karakter af en eksplorativ undersøgelse. Det har aldrig været målet at vores empiri skulle være fuldstændig repræsentativt, ligesom det heller ikke er opgavens formål at dokumentere eller gendrive eksisterende teori. Derimod er det opgavens formål at anvende empiri til at facilitere et mere rigt facetteret syn på sammenhængen mellem EA og SOA. Side 5 af 55

6 Læsevejledning I kapitel 2 gennemfører vi en begrebsafklaring og får fastlagt de definitioner, vi bruger opgaven igennem. I kapitel 3 gennemfører vi en analyse af sammenhængene mellem de begreber, som vi definerede i kapitel 2 I kapitel 4 gennemgår vi de interviews, vi har gennemført i forbindelse med indsamlingen af empirisk materiale. I kapitel 5 undersøger vi vores hypoteser I kapitel 6 vil vi afslutte opgaven med vores konklusion Side 6 af 55

7 Kapitel II - Begrebsafklaring I dette kapitel vil vi definere og beskrive opgavens centrale begreber. Mange af de begreber der anvendes i opgaven er ret nye, og defineres og anvendes ofte forskelligt afhængig af kontekst. Målet er derfor at få skabt en basis, således at vi kan anvende begreberne i resten af opgaven. Vi vil for det første se på, hvad arkitekturbegrebet overhovedet betyder, ligesom vi vil se på hvad der menes med begreberne 'Enterprise arkitektur', samt 'Service-orienteret arkitektur'. Enterprise Arkitektur Begrebet "Enterprise arkitektur" blev formodentligt anvendt første gang af Steven Spewak i sin bog Enterprise Architecture Planning 1. Efterfølgende er begrebet oftest sat i sammenhæng med John Zachman. Efterhånden er anvendelsen af begrebet vokset ganske kraftigt, og der er dukket en hel skov af forskellige definitioner op. Men enterprise arkitektur handler i bredeste forstand om at integrere IT med forretningen. Et af målene med enterprise arkitektur er at komme væk fra den systemtankegang som har præget udviklingen af IT ressourcer i de sidste par årtier 2. Istedet ønsker man at fremme en mere holistisk tilgang igennem udvikling af en overordnet arkitektur., hvor man kommer væk fra 'siloerne' og forbedrer mulighed for genbrug af IT-ressourcer. For at finde ud af hvad EA konkret indeholder, vil vi først prøve at se på hvad de to elementer af udtrykket (Enterprise og Arkitektur) indeholder hver for sig, og derefter se dem i en sammenhæng. Hvad er en enterprise? En enterprise relaterer sig på en eller anden måde som en entitet i forhold til en eller flere organisatoriske enheder. I almindelig sprogbrug anvendes ordet 'enterprise' ofte ret løst. Vi kender f.eks. begrebet 'enterprise software', uden at dette er særlig præcist defineret. Definitionen på Wikipedia hedder f.eks: "Almost any business or company can be called an enterprise" 3. En mere præcis definition finder vi hos Scott Bernard, der definerer enterprise således 4 : "An area of common activity and goals within an organization or between several organizations, where information and other resources are exchanged" 1 Bernard, p Bernard, p Wikipedia, d. 26/ Bernard, p. 31 Side 7 af 55

8 En enterprise kan altså være en del af en større organisation, være hele organisationen eller gå på tværs af flere organisationer. Det der er afgørende er, at der sker en udveksling af informationer og ressourcer. I modsat fald ville der være tale om to eller flere selvstændige enheder, fremfor en enterprise. Hvad er arkitektur? Arkitektur kan ses som en struktureret metode til at analysere, planlægge og udvikle alle former for ressourcer 5. Arkitektur er mest kendt inden for byggeriet, hvor man er vant til at designe og planlægge byggerier, hvorimod begrebet er lidt mere ukendt i forbindelse med virksomheder og IT. Men man kan opnå en intuitiv forståelse af begrebet ved at anvende husbyggeri som metafor. En arkitekt vil starte med at lave en plan for hvordan huset skal se ud, og hvordan det skal være designet for at imødekomme beboernes behov. Arkitekten har altså et udgangspunkt i form af nogle ressourcer og designer så et hus på en måde, så det imødekommer brugernes behov. Planlægning og dokumentation er altså centrale elementer. Man starter ikke med at bygge et hus nedefra, ved f.eks. at lave et soveværelse. Tanken er at arkitekturen i en enterprise også skal styres af en form for overordnet planlægning, således arkitekturen i sidste ende er drevet af virksomhedens overordnede behov. Jane Carbone giver en forklaring på, hvorfor anvendelsen af metaforen om husbyggeri er så nyttig i forbindelse med IT 6 : I have recently been reminded of how apt the comparison between IT architecture and building a house is. I learned again that what you plan is more likely to happen, that what you include in the plan is most likely to be executed, and that what you omit will likely not see the light of day. På trods af at byggemetaforen har sine styrker til at give os en forståelse af arkitektur, så har den absolut også sine begrænsninger. Den mest oplagte begrænsning ved anvendelse af begrebet om ITarkitektur er, at man i modsætning til ved byggeri sjældent starter forfra helt fra bunden. Istedet bygger man videre på noget der allerede eksisterer, og som allerede er i brug. Herzum beskriver det således 7, at en bedre analogi ville være, at skulle transformere en skyskraber om til en helt anden skyskraber - vel at mærke imens alle de der bor i skyskraberen stadig skal kunne bo der. 5 Bernard, p Carbone, p. 1 7 Herzum, p. 3 Side 8 af 55

9 Men IT-systemer er ikke statiske - de vokser istedet over tid i takt med de krav der opstår i omverdenen. Herzum påpeger derfor, at det vil være mere korrekt at anvende arkitekturen for en hel by eller en region som analogi istedet. En by er kompleks, levende og i konstant udvikling, og byplanlæggeren må nødvendigvis tage hensyn til dette. I hvidbogen 8 har man da også besluttet at anvende "byplanlægning" som en metafor for arkitekturarbejdet. Når vi snakker arkitektur i forbindelse med virksomheder og IT, kan man dele arkitekturen op i to niveauer, nemlig forretningsarkitekturen der er et udtryk for hvorledes virksomhedens strategier er omsat til forretningsprocesser og IT-arkitekturen der er et udtryk for de enkelte systemer og komponenter der indgår i det tekniske landskab i en enterprise. Definition af enterprise arkitektur Med en større forståelse af begreberne 'enterprise' og 'arkitektur' kan vi nu definere betydningen af udtrykket 'enterprise arkitektur'. Scott Bernard definerer EA således 9 : The analysis and documentation of an enterprise in its current and future states from an integrated strategy, business and technology perspective Der lægges altså vægt på at kunne dokumentere en enterprise nu (as-is) og som ønsket i fremtiden (to-be), ud fra et integreret perspektiv for strategi, forretning og teknologi. Ønsket om at dokumentere virksomheden i en fremtidig tilstand skal ses som et ønske om at kunne foretage planlægning, nøjagtigt som beskrevet i citatet af Carbone ovenfor. For at få noget til at ske, må det planlægges. Definitionen giver os dog ikke noget bud på, hvad EA reelt indeholder. For Scott Bernard 10 ligger der to forskellige ting i EA praksis, nemlig som en metode for dokumentation, men også som et styringsværktøj (management program). En dokumentationsmetode indeholer ifølge Bernard fire punkter 11 : EA tilgang - Rammeværk til modellering samt en implementeringsmetode Nuværende tilstand - Oversigt over nuværende (as-is) strategier, processer og ressourcer Fremtidig tilstand - Oversigt over fremtidig (to-be) strategier, processer og ressourcer EA styringsplan - En plan for hvordan en enterprise flytter sig fra den nuværende tilstand (asis) til den fremtidige tilstand (to-be) 8 Hvidbogen, afsnit Bernard p Bernard, p Bernard, p. 34 Side 9 af 55

10 Som styringsværktøj indeholder EA følgende fire punkter 12 : Ressourcetilpasning - Ressourceplanlægning og fastlæggelse af standarder Standardiserede politikker - Ressourcestyring og implementering Beslutningsstøtte - Finansiel kontrol og konfigurationsstyring Ressourceoverblik - 'Lifecycle' tilgang til udvikling/styring Indholdet af en EA tilgang Når en enterprise begynder at arbejde med EA, vil den anvende en EA tilgang, som en del af dokumentationsmetoden. En EA tilgang indeholder to overordnede elementer, nemlig et rammeværk (framework) til dokumentation, samt en EA metode. EA rammeværket er en struktur for de produkter (artefakter), der kommer ud af en EA-process. Scott Bernard definerer et EA rammeværk således 13 : "The EA Framework is a structure for organizing information that defines the scope of the architecture (what the program will document) and how the areas of the architecture relates to each other." Et EA rammeværk har altså til formål at definere omfanget af de artefakter der skal produceres, at klassificere de artefakter der bliver produceret i løbet af EA processen, samt vise sammenhængen mellem artefakterne. På den måde bliver EA rammeværket en struktur for både den dokumentation og analyse der kommer til at foregå undervejs, idet rammeværket også anvendes til at identificere de punkter hvor der mangler dokumentation. Rammeværket siger derimod ikke noget om hvordan arbejdet skal foregå. Her kræves en EA metode. Metoden anvendes jf. Scott Bernard 14 til at styre hvordan artefakter skal udarbejdes, arkiveres og anvendes, ligesom metoden er bestemmende for hvordan EA skal implementeres, hvilket rammeværk der skal vælges, og hvilke værktøjer der skal anvendes. Det er altså metoden der gør vores EA arbejde handlingsorienteret. 12 Bernard, p Bernard, p Bernard, p. 81 Side 10 af 55

11 The Zachman Framework for Enterprise Architecture Det formodentlig mest kendte EA rammeværk er udarbejdet af John Zachman. Baggrunden for Zachmans arbejde med EA er, at han som konsulent for IBM blev opmærksom på, at der opstod en stigende kompleksitet i kundernes krav til anvendelse af IT. Han fandt det derfor nødvendigt, at kunne skabe bedre dokumentation, der igen dels kunne bidrage til at skabe et bedre overblik over ITsystemerne, og dels kunne give virksomhederne bedre mulighed for at designe, planlægge og konfigurere IT-systermerne. Han udviklede og publiserede derfor sin ISA model 15 (Information System Architecture) model i I 1992 blev rammeværket udvidet 16 i samarbejde med John Sowa, og kendes indimellem som "Sowa-Zachman" rammeværket (herefter dog blot kaldet Zachman's rammeværk). Rammeværket vises i figur 1.1. (Figur 1.1 Zachman Framework for Enterprise Architecture) Rammeværket er et strukturelt værktøj, idet rammeværket udelukkende anvendes til at klassificere arkitekturartefakterne. Der er ikke nogen metode tilknyttet rammeværket. Der er heller ikke nogen fastlagt process eller flow i forhold til modellen, herunder ikke noget fast start- eller slutpunkt. 15 Zachman, Zachman, 1992 Side 11 af 55

12 Selve rammeværket er en matrix struktur med to dimensioner. På Y-aksen er modellen inddelt i fem forskellige lag, der viser virksomheden på forskellige abstraktionsniveauer 17. Disse lag kaldes oftest for perspektiver. Perspektiverne indeholder bl.a. forretningsmodel, logisk model og fysisk model. Formålet med at anskue en enterprise fra forskellige perspektiver er, at forskellige interessenter ser forskelligt på tingene, og at deres synsvinkel alle er valide, men kun en del af virksomheden. Kun ved at se på alle perspektiverne opnår man en holistisk betragtning. Hvert af perspektiverne er tilknyttet en rolle, såsom 'planner', 'owner', 'designer', 'builder' og 'sub-contractor'. Igen kan vi genkende metaforen fra husbyggeriet. Rammeværket beskrives på baggrund af figur 1.1. De fem perspektiver ser derfor således ud: Scope (Planner s view) Eksterne krav og afgrænsning af organisationen. Modellering af forretningsfunktioner Business Model (Owner s view) Definition af forretningsprocesser og allokering af funktioner System Model (Designer s view) Logiske modeller og definition af krav Technology Model (Builder s view) Fysiske modeller. Definition af løsninger og udvikling Detailed Representation (Subcontractor s view) De detaljerede elementer som systemerne er opbygget af Functioning Enterprise Det faktiske system/element 17 Der er ganske vidst tale om forskellige abstraktionsniveauer, men ikke forskellige detaljeringsniveauer Side 12 af 55

13 På X-aksen finder man en række engelske w-spørgsmål, i form af det såkaldte who-what-wherewhen-why-how 18 fokus. Her stilles en række spørgsmål til hvert lag i modellen. De seks aspekter i rammeværket er: Data (What) Hvilke forretningsentiteter, dataobjekter, komponenter mm. findes i organisationen og hvordan hænger de sammen. Funktion (How) Hvordan virker forretningsprocesser, applikationsfunktioner og computerfunktioner i enterprisen Network (Where) Hvor er forretning, computerfunktioner, IT-systemer mv. placeret rent geografisk People (Who) Hvem består organisationen af? (forretningsenheder, personer, brugere mv.) Time (When) Hvornår udføres aktiviteterne og hvornår opstår der hændelser? (forretningshændelser, systemhændelser mv.) Motivation (Why) Hvorfor eksisterer organisationen (hvad er vores strategier, forretningsmål osv.) Hver kombination af perspektiv og aspekt danner en celle. Tilsammen danner de to dimensioner en matrix med 30 celler. Slutteligt skal det nævnes, at der er opstillet en række regler for rammeværket. De syv regler er 19 : Regel 1 - Der er ingen rækkefølge på kolonnerne Regel 2 - Hver kolonne er en simpel, basal model (en abstraktion) Regel 3 - Den basale model (abstraktionen) er unik for hver kolonne Regel 4 - Hver række danner et unikt perspektiv Regel 5 - Hver celle er unik Regel 6 - Ved at udfylde alle cellerne i en række, dannes et komplet billede af det pågældende perspektiv Regel 7 Modellen er rekursiv, og kan anvendes som metamodel 18 Selvfølgelig med undtagelse af How 19 Zachman, 1992, p Side 13 af 55

14 Kritik af Zachmans rammeværk På trods af udbredelsen af Zachmans rammeværk, så har det dog ikke manglet kritik. Herunder gennemgåes de to vigtigste kritikpunkter: manglende metode for omfangsrigt Manglende metode tilknyttet Som tidligere nævnt, så er der ikke nogen metode tilknyttet rammeværket, og der er udelukkende tale om et værktøj til at identificere og klassificere artefakter. Det gør selvfølgelig på den ene side at rammeværket er generisk, og kan anvendes med den metode som en enterprise nu finder passende. Omvendt så kan det også være en ulempe, at en enterprise selv skal finde vej igennem dette ganske omfattende rammeværk. Rammeværket er for omfattende Mængden af artefakter der skal produceres og detaljeringsgraden der skal til for at udfylde alle cellerne i rammeværket er ganske enorm. Bloomberg et al, argumenterer 20 for at kun få - om nogle - enterprises er i stand til at mestre indholdet i alle 30 celler. De mener at rammeværket skal ses som et 'best case'. Dvs. at udfyldelsen af cellerne skal dikteres af forretningens behov, og hver enterprise må finde sin vej gennem rammeværket. Zachman ser det heller ikke som et krav, men derimod som ønskeligt, at alle celler i rammeværket udfyldes. Han siger det på denne måde 21 : I am confident that at some point in time, the Enterprise is going to wish it had all of those design artifacts (models, cells of the Zachman Framework, the Framework for Enterprise Architecture) made explicit, Enterprise-wide, horizontally and vertically integrated at excruciating levels of detail..." Det er Zachmans klare holdning, at for at kunne håndtere kompleksitet og hyppige forandringer, så vil man på et tidspunkt få brug for at have alle celler i rammeværket udfyldt ned på "excruciating levels of detail". Det er altså op til den enkelte enterprise selv at finde ud af hvordan og hvor meget af rammeværket der skal udfyldes. Men umiddelbart synes der at være et spænd mellem Zachmans tilgang til EA, og de mere agile udviklingsformer som der ofte advokeres for i disse år. 20 Bloomberg, p Zachman, 2000, p. 1 Side 14 af 55

15 Afsluttende bemærkninger På trods af at vi har fremført væsentlige kritikpunkter i forhold til Zachman rammeværket, så synes vi dog stadig at rammeværket har sin værdi. Selvfølgelig i form at at rammeværket nærmest er 'defacto' standarden, og at mange andre rammeværker læner sig op af dette. Rammeværket synes at have sin styrke ved den enkelhed hvormed den beskriver en enterprise. Generelt taget synes rammeværket ikke at være særligt målrettet mod EA processen. Hvis vi i denne opgave havde haft en mere processorienteret vinkel på EA, ville vi formodentlig have taget udgangspunkt i et mere moderne rammeværk. Men som udgangspunkt for en akademisk analyse finder vi rammeværket særdeles velegnet. Serviceorienteret arkitektur I dette afsnit vil vi afdække den service-orienterede arkitektur, både ud fra et forretningsmæssigt, og et teknisk synspunkt. Hvad er serviceorienteret arkitektur? SOA har uomtvisteligt fået meget omtale i IT-verdenen igennem de sidste par år. Når man snakker om SOA, så nævnes der da ofte også en hel række af fordele og mål. Af de mest almindelige nævnes typisk fordele som hurtigere udvikling, bedre mulighed for genbrug af ressourcer, bedre integration mellem IT-systemer, samt mere forandringsparate IT-systemer. Forventningerne til SOA har mildest talt været enorme. På trods af at SOA er særdeles omtalt, så er det ikke særlig veldefineret. Begrebet anvendes ofte forskelligt, afhængig af hvem og i hvilken interesse begrebet anvendes. F.eks. bidrager mange konsulenthuse og analysehuse med hver deres syn på SOA, ligesom mange IT-leverandører markedsfører såkaldte SOA-produkter, der igen er med til at gøre begrebet mere diffust. Men der synes at være to overordnede synsvinkler på SOA, nemlig en forretningsmæssig og en teknisk. Vi vil i det følgende søge at definere SOA, ligesom vi vil give en beskrivelse af både den forretningsmæssige og den tekniske side af SOA. Definition Med baggrund i de mange forskellige definitioner på SOA, har standard-organisationen OASIS defineret en såkaldt SOA reference model (SOA-RM). Modellen er et abstrakt rammeværk, der dels søger at skabe en fælles forståelse af SOA, ligesom den søger at beskrive forholdet mellem de elementer der indgår i SOA. Det er tanken at der ud fra denne abstrakte referencemodel, kan skabes Side 15 af 55

16 konkrete arkitekturmodeller. Der er altså tale om en model på et så tilpas højt abstraktionsniveau, at den ikke bundet til nogen konkret arkitektur, ligesom den er teknologi- og leverandørneutral. På trods at tvivl om hvorvidt OASIS qua reference modellen vil lykkes med at skabe konsensus om SOA, så er modellens abstraktionsniveau dens absolute styrke, hvorfor vi vil anvende den i det følgende. I referencemodellen defineres SOA således 22 : Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains Denne definition giver anledning til flere overvejelser. Det første man kan bemærke er, at SOA er et paradigme og ikke en teknik eller en konkret arkitekturform. Vi kan se SOA som en tankemåde for hvordan man man organiserer og udnytter funktionalitet spredt på tværs af den fysiske systemarkitektur, og hvor de udbudte funktioner kan være under forskelligt ejerskab. Det andet vigtige element i definitionen er 'capabilities'. På dansk kan man sige, at capabilities er muligheden eller evnen til at udføre en funktion eller opgave. En capability vil ofte være skabt på baggrund af et 'need' (eller behov) hos en anden part. Services er altså det centrale bindeled mellem capabilities og needs. Som det beskrives i SOA-RM 23 : "...in SOA, services are the mechanism by which needs and capabilities are brought together..." Der er altså tre centrale koncepter jf. referencemodellen der kendetegner services 24 : The capability to perform work for another The specification of the work offered for another The offer to perform work for another En service skal altså kunne udføre en funktion for en anden, der skal være en specifiktation for den funktion der udbydes, ligesom funktionen rent faktisk skal udbydes til brug for andre parter. Det fortæller os, at der også må være flere parter involveret i en service. 22 OASIS, p. 8, l OASIS, p. 9, l OASIS, p. 8, l Side 16 af 55

17 Principperne bag SOA Det blev tidligere nævnt at der er en række fordele der tilskrives SOA. Spørgsmålet er imidlertid, hvad det er for principper der gør at man kan opnå disse fordele. Overordnet set kan man sige, at ud fra et historisk synspunkt er SOA en videreudvikling i forhold til tidligere paradigmer indenfor IT, hvor trenden generelt går mod stadigt højere grad af abstraktion, og stadig større fokus på indkapsling af funktionalitet i diskrete funktioner. Vi har tidligere set både det objekt-orienterede paradigme, samt det komponent-orienterede paradigme. Med SOA smider man ikke de gamle paradigmer på porten, men bygger istedet videre på dem. Det har indimellem ført til påstanden om at SOA bare er 'gammel vin på nye flasker'. Man kan dog ikke komme uden om, at der med SOA sker abstraktion på at nyt niveau, nemlig på serviceniveau, istedet for på objekt- eller komponent-niveau. Tankegangen er, at når man splitter systemerne op i mindre funktioner, og i jo højere grad man abstraherer disse funktioner fra hinanden, desto nemmere er det at genbruge disse dele og anvende dem i nye sammenhænge. Ved at holde funktionerne adskilte, gør man det også nemmere at foretage ændringer ét sted, uden at der opstår komplikationer i et andet sted. Dette princip kendes bl.a. fra objekt orienteret programmering i form a 'common closure' princippet, hvor man pakker funktionalitet der ændres på samme tidspunkt i samme pakke, mens funktionalitet der ikke vil være påvirket af en ændring, indkapsles i en anden pakke. En grafisk brugerflade på en hjemmeside vil f.eks. typisk blive ændret oftere end den funktionalitet der ligger bag ved. Ved at adskille de volatile elementer (i dette tilfælde brugerfladen) fra de non-volatile elementer (de bagvedliggende funktioner) opnår man en større fleksibilitet til at foretage ændringer. Et af midlerne til at opnå disse fordele er 'løs kobling'. Kobling beskriver den grad af afhængighed der er mellem komponenterne, det vil sige hvilket niveau af fælles viden der skal til, for at to entiteter kan kommunikere sammen 25. Kobling går gradvist fra tæt kobling, hvor de to enheder skal have en høj grad af fælles viden for at kunne kommunikere, videre til løs kobling hvor de skal have mindre viden, eller de kan til sidst være helt afkoblede, således at de ikke har nogen fælles viden. Tidligere har tæt kobling været det altdominerende paradigme indenfor IT, idet man her kan foretage en optimering mod en bestemt anvendelsesform, med forbedret performance som resultat. Performanceproblemer har fået en gradvis mindre rolle med udviklingen indenfor computer- og netværks-teknologi. Med løs kobling opnår man den fordel, at de forskellige funktioner i princippet kan anvendes uafhængigt af hinanden. 25 Hvid Jensen, p. 90 Side 17 af 55

18 Når talen falder på SOA og løs kobling, så hentydes der oftest til, at de web-services man anvender til at kommunikere med er løst koblede. Det er dog vigtigt at pointere, at løs kobling ikke kun har en betydning i forhold til de enkelte delelementer af IT-arkitekturen. Man kan også opnå en løsere kobling i forhold til forretningsarkitekturen og mellem applikationsarkitekturen og teknologiarkitekturen. På den måde kan man i princippet ændre på sine forretningsprocesser uafhængigt af sin IT-arkitektur, og på den måde opnå forbedret fleksibilitet i sin forretning. I praksis er målet dog nok at skabe en løsere kobling mellem forretningsprocesserne og IT-systemerne, end at opnå fuldstændig afkobling mellem forretningsprocesser og systemer. Men pointen er, at effekten af løs kobling ikke blot er teknisk men absolut også forretningsmæssig. SOA - det tekniske perspektiv En gængs opfattelse af SOA er, at det handler om at sætte web services på sine legacy systemer. En web service består af et interface samt en bagvedliggende funktionalitet. I bred forstand er en web service blot et stykke software med et interface, der kan anvendes til maskine-til-maskine kommunikation over et eller flere netværk. Webservices kan udføres med flere forskellige teknologier, men man vil typisk vil tænke på de såkaldte W3C web-service standarder (WS.*). I sin mest basale form er der tale om XML beskeder pakket ind i en SOAP konvolut. Andre teknologier kan dog også anvendes til at skabe webservices. F.eks. kan man anvende REST, dvs. HTTP GET/PUT/POST/DELETE kommandoerne til at foretage kommunikationen mellem systemerne. Der kan anvendes XML til udvekslingen af data, men det er ikke noget krav. REST er ikke i sig selv en formaliseret standard, men snarere et arkitekturprincip, der anvender andre standarder. Ydermere kan proprietære og binære kommunikationsformer også anvendes til web services. Hvid Jensen beskriver fire søjler som den tekniske del af det service-orienterede paradigme hviler på 26 : Distribuerede - Services kan være placeret på tværs af netværk og den fysiske systemarkiektur Løst koblede - Der kræves et lavt niveau af fælles viden for at to parter kan kommunikere sammen Baseret på åbne standarder - Ved at anvende åbne og leverandørneutrale standarder, sikres det at data ikke bliver låst fast i informationssiloer Processorienterede - Services er målrettet mod at understøtte processer. Det betyder at i SOA må der nødvendigvis skulle være standardmetoder til at beskrive processer, håndtere sikkerhed, udveksle data mv. 26 Hvid Jensen, p. 82 Side 18 af 55

19 Til sidst skal det dog nævnes, at teknisk SOA ikke blot handler om services, men også om infrastruktur (ellers ville det også være svært at tale om arkitektur). Et af de centrale elementer i den service-orienterede arkitektur er en såkaldt Enterprise Service Bus (ESB). Definitionen af hvad en ESB er varierer meget alt efter hvilken leverandør man spørger. Men overordnet set, så kan en servicebus bl.a. kendetegnes ved at den er distribueret (der er tale om en bus struktur og ikke en hub), kan transformere mellem forskellige protokoller, understøtter asynkron levering og routing, ligesom den kan indeholde funktionalitet til overvågning, logning mv. Delkonklusion: I dette kapitel har vi foretaget en afklaring af de centrale begreber i opgaven. Vi behandlede først EA og dernæst SOA. Indledningsvis definerede vi EA som analyse og dokumentation af en enterprise på nuværende tidspunkt og i fremtiden, ud fra et integreret syn på strategi, forretning og teknik. Målet er at skabe overblik, samt give bedre muligheder for planlægning. Vi anvendte byplanlægningsarbejdet som metafor for dette arbejde. Lidt mere detaljeret kan man sige, at EA består af to hovedkomponenter, nemlig en dokumentationsmetode, samt et styringsprogram. Dokumentationsmetoden indeholder typisk en dokumentation af den pågældende enterprise 'as-is', altså som den er idag, samt i en ønsket fremtidig tilstand ('to-be'). Derudover indeholder dokumentationsmetoden en EA tilgang, som dels består af et EA rammeværk, og dels består af en implementeringsmetode. Rammeværket anvendes til at sætte rammerne for hvilke artefakter der skal produceres i EA processen, og rammeværket bliver på den måde også en struktur for analysen. EA rammeværket demonstrerer desuden sammenhængen mellem artefakterne. EA metoden anvendes til at styre hvordan artefakter skal udarbejdes, arkiveres og anvendes, ligesom metoden er bestemmende for hvordan EA skal implementeres, hvilket rammeværk der skal vælges, og hvilke værktøjer der skal anvendes Side 19 af 55

20 Derefter blev Zachman s rammeværk gennemgået. Modellen viser et holistisk billede af virksomheden, set fra forskellige vinkler. Rammeværket består derfor dels af 5 perspektiver der viser virksomheden på forskellige abstraktionsniveauer, og dels af 6 aspekter, der viser forskellige elementer af virksomheden. Tilsammen danner rammeværket en matrix med 30 celler. Vi afsluttede gennemgangen af Zachman s rammeværk med en diskussion om nogle af de væsentlige kritikpunkter der kan rejses, idet modellen mangler en tilknyttet metode, og er særdeles omfangsrigt. Vi konkluderede dog, at rammeværket trods kritikpunkterne var egnet til vores formål i opgaven. Dernæst gik vi over til at definere og beskrive SOA. Vi anvendte OASIS referencemodellen som udgangspunkt. SOA blev defineret som et paradigme og anvendelse af 'capabilities' spredt på tværs af den fysiske system-arkitektur, og hvor de udbudte funktioner kan være under forskelligt ejerskab. Det blev understreget at SOA er et princip og ikke en bestemt teknik eller arkitekturform. 'Capabilities' er evnen eller muligheden for at gøre noget for en anden. Services blev set som det der binder 'capabilities' og 'needs' (behov) sammen. Derefter blev de centrale principper der skaber mulighed for at opnå fordele med SOA diskuteret. Indkapsling og abstraktion af funktionalitet blev set som bærende elementer i SOA. I den sammenhæng var begrebet 'løs kobling' af afgørende betydning. Kobling betegner det niveau af fælles viden som to parter skal have for at kommunikere. Ved lavere grad af kobling, gøres det nemmere at genbruge funktionalitet i nye sammenhænge, og foretage ændringer i delelementer af systemerne. Begrebet løs kobling skulle dog ikke kun ses i forhold til web services, men i bredere forstand, i form af løs kobling til applikationsarkitekturen og forretningsarkitekturen. I den sidste del af kapitlet blev den tekniske del af SOA gennemgået. Web services blev defineret som eksekverbar software med et interface, der kan kaldes på tværs af netværk. Der vil ofte være tale om de såkaldte W3C WS.* standarder, dvs. XML beskeder pakket i en SOAP konvolut. Men web services kan også etableres med andre standarder og teknikker, såsom REST, eller med binære og proprietære standarder. En Enterprise Service Bus blev beskrevet som et værktøj til at opnå mere løs kobling i arkitekturen, samt tilbyde central funktionalitet, som f.eks. logning, routing af meddelser og transformation af protokoller. Side 20 af 55

21 Kapitel III - Analyse I dette kapitel vil vi behandle den konceptuelle sammenhæng mellem EA og SOA. Der er to hovedformål med dette kapitel, idet vi dels ønsker at vise, hvordan de to begreber relaterer sig til hinanden, ligesom vi ønsker at skabe et teoretisk fundament, for vores senere empiri i form af interviews med vores case virksomheder. Vi ønsker at kunne besvare de to spørgsmål: hvad tilfører EA til SOA? hvad tilfører SOA til EA? På den baggrund vil vi i slutningen af kapitlet opstille nogle hypoteser, som vi vil belyse empirisk med vores interviews. Hvad er SOA modenhed? I løbet af denne opgave anvendes begrebet 'SOA modenhed' ganske ofte. Det er derfor på sin plads at beskrive begrebet, så det kan anvendes så præcist som muligt. I den forbindelse kan det være nyttigt, at se på hvad målet med SOA egentlig er. For organisationer der befinder sig i en konkurrencesituation på et marked, da må målet med SOA være at opnå konkurrencefordele. I sin artikel "What is Strategy" beskæftiger Michael E. Porter sig indgående med emnet konkurrencefordele, og i den forbindelse med forskellen på begrebet strategi, og det som han kalder 'operationel effektivitet'. Han beskriver de to begreber således: Strategi: virksomheden søger at indtage en unik position idet den foretager en række langsigtede valg og fravalg Operationel effektivitet: En virksomhed er i stand til at gøre det samme som andre, men mere effektivt Side 21 af 55

22 Ifølge Porter, så er anvendelse af strategi vejen frem i forhold til at opnå vedvarende konkurrencefordele hvor operationel effektivitet er givet. Vi vil derfor anse modellen som værende kumulativ, idet tidligere niveauer vil være inkluderet på højere niveuer, således at ønkset om operationel effektivitet også er et naturligt element på højere niveauer. Hvis målet med SOA er at opnå vedvarende konkurrencefordele, så ser vi moden SOA som en naturlig forlængelse af forretningen, og ikke som et teknisk projekt fokuseret på at opnå operationel effektivitet. Moden SOA må altså være kendetegnet ved, at være drevet af forretningens strategier og mål. Denne måde at anskue moden SOA på, kan udtrykkes i 2 principper: at de konkrete løsninger udmøntet af SOA paradigmet er drevet at forretningsstrategien og ikke af hensyn på lavere niveauer at de konkrete løsninger udmøntet af SOA paradigmet reelt har en påvirkning på forretningen Kort sagt er moden SOA altså kendetegnet ved en vekselvirkning i forhold til forretningen. På den ene side er SOA indsatsen drevet af forretningens mål og strategier, mens SOA også har en positiv effekt på disse. Ydermere, så kan man se SOA modenhed som en kontinuær fordeling med ønsket om at opnå operationel effektivitet på laveste niveau, og den totale sammensmeltning mellem SOA og forretning på højeste niveau. Modenhedsmodel for SOA I det foregående afsnit blev SOA defineret. Det er dog nødvendigt at kunne operationalisere modenhedsbegrebet, i form af anvendelsen af en SOA modenhedsmodel. Ikke overraskende, findes der også her et væld af valgmuligheder, rækkende fra de mere abstrakte til de mere salgsorienterede modeller. Vi har følgende to krav til en modenhedsmodel: den skal understrege vores pointe om, at der er en udvikling i modenhed fra fokus på operationel effektivitet og videre til strategi den skal være så tilpas simpel, at vi kan indplacere case-virksomhederne i modellen inden for den korte tidsramme vi har i interviewene Side 22 af 55

23 På den baggrund anvendes en model kaldet SOA MM. Der nævnes tre overvejende inspirationskilder til modellen 27 : input fra mere end 2000 arkitekter og udviklere input fra industri-analytikere med vægt på successfulde måder at implementere SOA på success med rammeværker såsom Capability Maturity Model (CMM) og CMM Integration (CMMIsm) til at definere og måle processforbedringer inden for ingeniørdiscipliner Det hedder yderligere om modellen 28 : The model is designed to show the increasingly positive impact of SOA adoption from a business perspective. It provides IT decision makers with a framework for benchmarking the strategic value of their SOA implementation, and a model for visualizing future success. Modellen synes altså også at understrege den progression der er i forhold til SOAs indflydelse på forretningen. Så på trods af at der her er tale om en leverandørskabt model 29, så er den særdeles velegnet til at demonstrere vores pointer. SOA MM - en model for modenhed Selve modellen som ses i figur 3.1 er inddelt i fem lag, hvor 1 repræsenterer det laveste niveau af modenhed og hvor niveau fem repræsenterer det højeste niveau af modenhed. For hvert niveau er der angivet hvilket fordele (benefits), der potentielt kan opnås ved det givne niveau. 27 Movin' SOA On Up d. 26/ Movin' SOA On Up d. 26/ Af Sonic Software, samt partnerne AmberPoint, BearingPoint og Systinet Side 23 af 55

24 (Figur 3.1 SOA MM By Sonic Software, samt partnerne AmberPoint, BearingPoint og Systinet) Herunder er de fem niveauer beskrevet kort: Niveau 1 - Initial Services Her er tale om absolut indledende øvelser i forbindelse med SOA. Det kan være i forbindelse med et specifikt og konkret udviklingsprojekt der typisk kræver integration mellem ét eller flere systemer. Der kan dog også være tale om deciderede forsøg med SOA i et 'laboratorie-miljø'. Projektet er typisk drevet af ønske om funktionalitet. Niveau 2 - Architected Services I niveau 2, er der i forhold til niveau 1 inkluderet en form for teknisk 'governance', ofte i form af en arkitektur med henblik på at opnå besparelser i organisationen. På dette niveau er indsatsen styret af ønsket om lavere omkostninger til udvikling og udrulning, igennem anvendelse af standardiseret infrastruktur og standardkomponenter. Her sker et skifte, hvor man ikke længere anser udviklingsprojekter som værende enkeltstående. Side 24 af 55

25 Niveau 3 - Business & Collaborative Services I niveau 3 ser vi for første gang, at der sker en sammensmeltning mellem forretning og IT. På dette niveau handler det om at skabe sammenhæng mellem forretningsprocesserne og de tekniske processer. Herigennem skabes der omstillingsparathed i forretningen. Denne omstillingsparathed kan opnås, enten ved at fokusere på at optimere de interne forretningsprocesser (3a), eller ved at fokusere på at optimere forretningsprocesserne i forhold til eksterne partnere. Niveau 4 - Measured Business Services Hvor det på niveau 3 drejer sig om at implementere interne og/eller eksterne forretningsprocesser, så drejer det på niveau 4 sig om, at måle og præsentere disse for organisationen, således at de giver feedback til organisationen, der så kan reagere på de hændelser der opstår. På dette niveau begynder man at kunne tale om transformation af virksomheden. Niveau 5 - Optimized Business Services I niveau 5 giver SOA os ikke bare muligheden for at reagere på forretningshændelser, men giver os også muligheden for at systemerne selv reagerer på forretningshændelser ud fra givne regler. Det beskrives som at SOA informationssystemerne danner et "enterprise nervous system". På dette niveau kan man sige, at SOA ikke længere blot er en del af virksomheden, men i et vist omfang er selve virksomheden. Enterprise arkitekturen vs. SOA Et af denne opgaves mål er at se på hvordan EA og SOA begreberne forholder sig til hinanden. I dette afsnit vil vi se på de konceptuelle sammenhænge mellem de to begreber. Målet er dels at demonstrere hvilken indflydelse EA og SOA har på hinanden, ligesom vi vil opstille en række hypoteser som vi kan belyse senere ved hjælp af vores cases. Zachman og SOA En metode til at analysere sammenhængen mellem EA og SOA på, er at se hvorledes SOA passer ind i et rammeværk. På denne måde vil vi kunne se hvilke grænseflader der er mellem de to begreber, idet SOA på den ene side får betydning for indholdet af enterprise arkitekturen, mens EA på den anden side sætter rammerne for EA indsatsen. Vi har tidligere beskrevet Zachman rammeværket, og på trods af rammeværkets svagheder iøvrigt, har vi fundet at rammeværket er et udmærket værktøj til demonstration af overordnede principper. Der er to måder man kan mappe SOA ind i Zachman rammeværket på, nemlig på et konceptuelt niveau, eller på et mere konkret niveau hvor man Side 25 af 55

26 indplacerer SOA artefakter i rammeværket. Den mapning vi vil foretage vil være mere overordnet og konceptuel. Vores mål med mapningen er da heller ikke at foretage en komplet mapning, men snarere at demonstrere overordnede sammenhænge. En mere konkret tilgang til mapningen ses i kapitel 9 i Ramus Knippels 'SOEA' speciale 30, hvor han foretager en detaljeret mapning af SOA artefakterne i forhold til rammeværket. SOA indflydelse på EA? Lublinksy og Tyomkin beskæftiger sig med sammenhængen mellem EA og SOA i deres artikel Dissecting service-oriented architectures, dog primært med SOAs indflydelse på EA. Vi vil i det følgende tage udgangspunkt i deres artikel. De argumenterer for at der er fire centrale EA perspektiver 31 i form af forretning, applikation, teknologisk og informationsperspektivet som vil blive påvirket af SOA (se figur 3.2). I forhold til vores problemstilling er det værd at bemærke, at figuren kan mappes direkte til Zachman (og formodentlig er figuren afledt af Zachman). Hvis vi ser på forretnings-, applikations- og teknologiperspektiverne, så passer de nøjagtigt med det konceptuelle, logiske og det fysiske perspektiv i funktionsaspektet i Zachman. På samme måde passer informationsperspektivet ind i data-apektet i Zachman rammeværket. Vi kan dog se at informationsperspektivet ikke er normaliseret i forhold til Zachman, men går som en tråd langs funktionsperspektivet. I Zachman rammeværket ville vi tale om den fysiske, den logiske og den semantiske datamodel, fremfor at tale om et samlet informationsperspektiv. Det er iøvrigt værd at bemærke, at denne inddeling også går igen i andre rammeværk såsom TOGAF Knippel, Kapitel 9 31 Lublinsky, p Jf. Lublinsky, p. 53 Side 26 af 55

27 (Figur Lublinsky & Tyomkin) Teknologiperspektivet I teknologiperspektivet definerer vi vores teknologiske platform. Denne platform vil i høj grad blive påvirket, når vi begynder at arbejde hen imod service-orientering. I begyndelsen kan kravene være moderate, men efterhånden som vi bevæger os væk fra nogle få eksperimentelle services i periferien af vores kerneforrretning, og videre til at skulle drive hundredevis eller tusindvis af services der har en stigende betydning for vores forretning, så vil kravene blive skærpet kraftigt. For at kunne opnå både genbrug og en effektiv drift af vores services, er det nødvendigt at implementere en fælles infrastruktur til at udvikle og drive vores services. Figur 3.3 viser en generisk oversigt over de elementer der typisk vil indgå i en teknologisk platform. Jf. Lublinsky 33 kan elementerne overordnet set deles op i værktøjer, infrastruktur, samt run-time support. Værktøjer: Development and test tools: Værktøjer, processer, metoder og 'patterns' 34 til at designe, udvikle, samle og teste services 33 Lublinsky, p Vi opfatter i denne sammenhæng patterns, som en art best practice Side 27 af 55

28 Infrastruktur: Service deployment: processer og teknologi vedrørende udrulning af services, incl. hosting platform Infrastruktur: middleware, operativsystemer, hardware, lagring, netværk, samt tillid og management support for hele systemet Service run-time support: processer, logik, funktioner og 'styring af status som krævet af en service baseret applikation og det fulde enterprise applikationsmiljø, med specific support for services af services Service binding and invocation: Run-time komponent: Quality of Service (QoS): Garanti af kvalitet i form af prioritering Service versioning support: Styring af versioner af services (Figur 3.3 Lublinsky & Tyomkin) Samlet set må vi konstatere, at efterhånden som man bevæger sig væk fra det laveste niveau i vores SOA modenhedsmodel (initiale services), så vil den teknologiske platform begynde at få en større betydning. Side 28 af 55

29 Applikationsperspektivet I Lublinskys & Tyomkins applikations-perspektiv (Zachman's Application Architecture ), beskæftiger vi os med applikationsporteføljen. Et af hovedformålene med at introducere en applikationsarkitektur er at indføre løs kobling også på applikationsniveau. Af Lublinsky og Tyomkins figur 3.4 ser vi igen de generelle elementer i en applikationsarkitektur. (Figur Lublinsky og Tyomkin) Det interessante her er, at der ikke blot er tale om enkeltstående services der kan kommunikere sammen, men at de kommunkerer sammen via en service bus. Et vigtigt formål ved at indsætte et ekstra lag i arkitekturen er, at gøre strukturen mere løst koblet. De opnåes dels igennem at de enkelte services ikke skal integreres punkt-til-punkt med andre services, dels fordi at service-bussen også kan anvendes til transformation mellem forskellige protokoller, og slutteligt fordi service-bussen understøtter asynkron levering af meddelser. En service bus vil derfor blive et vigtigt element i en SOA implementering allerede i en tidlig fase. For at være en del af en EA indsats, skal service-bussen ihvertfald på sigt være enterprise-wide. Business process engine: ved at introducere en separat Business Process Engine*, kan forretningsprocesserne holdes adskilt fra de underliggende services Business services: de indkapslede forretningsfunktioner Utility services: forretningsservices der ikke tilhører kerneforretningen, men som stadig kan tilgåes fra alle typer af klienter Common (infrastructure) services: leverer system og infrastruktur støtte til forretningsservices Side 29 af 55

30 Forretningsperspektivet I forretningsperspektivet har vi bevæget os væk fra IT-arkitekturen og ind i forretningsarkitekturen. Målet er her igen, at få delt funktionaliteten op i mindre dele, der er mere håndterbare og som lettere kan genbruges. Det vil sige at common closure princippet anvendes også her, idet de mere volatile elementer (forretningsprocesserne) adskilles fra de mindre volatile elementer (forretningsservices). På den måde isoleres ændringer i forretningsprocesserne i større eller mindre grad fra IT-arkitekturen, med forbedret fleksibilitet og omstillingsparathed som resultat. Derfor inddeles enterprise-funktionaliteten på dette niveau i forretningsprocesser og forretningsservices. Det man kan se er, at i takt med at vi har bevæget os op i SOA modenhed, er det nu forretningen (eller rettere: forretningsprocesserne) der bliver bliver styrende for hvilke services der skal implementeres. For det første fordi at for at kunne udvælge og prioritere de rette services som skal implementeres, da er det nøvendigt at være istand til at identificere og beskrive de relevante forretningsprocesser. Ydermere, så får forholdet mellem processerne og services også en betydning for granulariteten 35 af de services som skal udvikles og implementeres. På den ene side må vores services ikke være så findelte som objekterne i vores bagvedliggende kode, men omvendt må de hellere ikke være mere grovkornede end at de har en størrelse hvor de stadig er kandidater til genbrug i andre eller ændrede sammenhænge. Informationsperspektivet Lublinsky og Tyomkin har valgt at danne et generelt informationsperspektiv (figur 3.2) der går som en tråd på langs af teknologi-, applikations- og forretningsperspektivet, fremfor at normalisere begrebet til det semantiske, det logiske og det fysiske niveau i data-aspektet i Zachman rammeværket. Derudover så anvender Lublinsky og Tyomkin begrebet information, mens Zachman anvender begrebet data. Vi ser dog information som data sat i kontekst. Vi ser dog ingen problemer i at anvende deres fremgangsmåde på dette punkt, idet vi udelukkende er interesserede i at demonstrere de overordnede sammenhænge mellem EA og SOA. Lublinsky og Tyomkin angiver to overordnede elementer i informationsperspektivet 36 : Underliggende data modeller for service implementeringen Data dictionary for servicebeskeder som definerer den semantiske del af kommunikationen i SOA 35 Med granularitet menes hvor specifikke services skal være, dvs. hvor meget funktionalitet den enkelte service skal indeholde 36 Lublinsky, p. 56 Side 30 af 55

31 Når der gemmes data i forskellige systemer i en virksomhed, gemmes de oftest i forskellige fysiske datamodeller, på trods af at data indeholder information om samme forretningsobjekt 37. Det er f.eks. ikke særlig sandsynligt at en kunde er lagret på samme måde i et ERP system, som i et CRM system. Men såfremt en SOA indsats skal give virksomheden den ønskede værdi, er det helt essentielt at have en fælles begrebsmodel af de forretningsobjekter der indgår i services. Uden at have en fælles forståelse af f.eks. hvad en kunde er på tværs af enterprisen, vil det være svært for ikke at sige umuligt at opnå forbedret integration og forbedrede muligheder for genbrug vha. SOA. For på trods af at vi eksponerer vores funktioner som services, vil data reelt set stadig være placeret i 'siloer. Så der findes altså en stærk motivation for at opnå en fælles model for vores forretningsobjekter. Men det vil normalt være urealistisk at forsøge at etablere en fælles fysisk datamodel for data i en enterprise. Dels fordi at det vil være et særdeles omfattende arbejde, og dels fordi at mange af virksomhedens data ligger gemt i leverandørudviklede standardapplikationer, der kan være svære eller umulige at ændre. Samtidig er en fysisk datamodel ikke nødvendigvis særlig velegnet til at skabe en fælles referenceramme mellem det forretningsmæssige og det tekniske. En bedre måde at angribe problemstillingen på, er at skabe en fælles semantisk forståelse af indholdet i forretningsobjekterne. Så længe de forskellige interfaces på tværs af arkitekturen overholder de fælles semantiske definitioner, gør det ikke noget, at der ligger forskellige fysiske datamodeller bagved. Såfremt en enterprise skal bevæge sig videre fra det laveste modenhedsstadie af SOA, hvor der blot etableres få eksperimentielle services af periferær tilknytning til kerneforretningen, da er det afgørende, at forretningsobjekterne defineres og dokumenteres på systematisk vis, i form at et data dictionary. Hvordan påvirker SOA øvrige elementer i rammeværket? Lublinsky og Tyomkin går ikke videre end at se på det som vi i Zachman terminologi ville kalde dataog funktionsaspekterne, og det er da tydeligvis også centrale aspekter i relation til SOA. Men det betyder ikke at der ikke er andre sammenhænge mellem EA og SOA end dem. I dette afsnit vil vi fortsætte med at give en ganske kort og overordnet introduktion til hvordan SOA også kan brede sig i rammeværket i takt med stigende modenhed. Network: Netværksaspektet i Zachman omhandler forretningens netværk, lige fra forretningslokationerne og ned til de fysiske datanetværk der anvendes. I begrebsafklaringen beskrev vi hvorledes SOA kunne ses som et paradigme for organisering og anvendelse af capabilities på tværs af den fysiske system- 37 Vi definerer et forretningsobjekt, som en entitet i virksomheden som vi ønsker at opbevare og behandle data om Side 31 af 55

32 arkitektur og på tværs af domæneejerskab. Igen ser vi, at SOA i allerhøjeste grad skaber muligheder for at ændre på konfigurationen af de forskellige typer af netværk. Det gælder ikke mindst den fysiske placeringen af de enkelte services, herunder enterprisens egentlige datanetværk. Anvendelse af SOA kan altså have indflydelse på vores lokalisering af virksomhedens funktioner i form af: distribueret anvendelse af services internt i virksomheden, jf. modenhedsmodellens niveau 3a (Business Services) distribueret anvendelse af services med samarbejdspartnere i værdikæden, jf. modenhedsmodellens niveau 3b (Collaborative services) Time: Tidsaspektet i Zachman rammeværket omhandler de hændelser der sker i en enterprise. I de øverste to lag (kontekst og koncept) handler det om hændelser der sker i forretningen, mens det på lavere niveauer handler om hændelser der sker i IT-systermerne. Af SOA modenhedsmodellen som blev beskrevet tidligere i opgaven fremgik det, at på de to øverste lag (henholdsvis Measured og Optimized Business Services) handler det om at kunne reagere på de hændelser der opstår, så tæt på real-time som muligt. Med Measured Business Services kan vi ved at måle på vores forretningsprocesser få feedback, som vi kan reagere på. I Optimized Business Services kan systemerne selv reagere på hændelser ved at foretage handlinger ud fra et sæt af forretningsregler. Det er altså tydeligt, at ved SOA modenhedsniveau 4 og 5, så vil der også her opstå et øget sammenfald mellem SOA indsatsen og Zachman rammeværket. Opsummering - SOA i forhold til EA I det ovenstående har vi set på hvilke grænseflader der findes mellem EA og SOA. Målet har ikke blot været at vise hvordan SOA påvirker EA, men også at lægge op til en diskussion i det næste afsnit, om hvad det egentlig er som EA kan tilføre SOA. Gennemgangen viser to overordnede ting. For det første, så ses det at der er et overordentligt stort sammenfald mellem moden SOA og områderne dokumentation og analyse som Zachman rammeværket beskæftiger sig med, og at dette sammenfald vokser i takt med stigende SOA modenhed. Jo højere modenhed af SOA, desto flere celler i Zachman rammeværket får vi brug for til at dokumentere og analysere enterprisen ud fra. Vi har set hvordan bl.a. data-, funktions-, tids- og netværks-aspekterne har sammenhæng med SOA. På den baggrund vil vi opstille vores første hypotese: Side 32 af 55

33 Hypotese 1: Sammenfaldet mellem EA og SOA vil blive større ved højere SOA modenhedsniveauer Vores gennemgang giver også et indtryk af hvor omfattende en indsats det egentlig er at opnå en strategisk anvendelse af SOA. Valg af det service orienterede paradigme vil i sig selv påvirke kravet om hvad vi skal dokumentere og analysere, ligesom SOA vil påvirke standarder og udviklingsmodeller i virksomheden. Derfor vil valget af en service-orienteret tankegang i virksomheden betyde, at SOA i sig selv vil påvirke enterprise arkitekturen nedefra. Vi kan på den baggrund opstille vores næste hypotese. Hypotese 2: SOA paradigmet er så omfattende, at det vil påvirke enterprise arkitekturen nedefra Samlet set må vi konstatere, at jo højere modenhed af SOA, desto flere celler i Zachman rammeværket får vi brug for til at dokumentere og analysere enterprisen. Enterprise arkitektur som ramme for SOA Overordnet set, så har EA til formål at skabe overensstemmelse mellem strategi, forretning og teknik. Men når vi nu har demonstreret hvor stort et overlap der er mellem EA og SOA, så kan det måske forlede nogen til at mene, at SOA i virkeligheden er en slags mini-ea. Bloomberg argumenterer i bogen Service orient or be doomed netop for at SOA i virkeligheden er EA 38. Vi er ikke enige i den holdning, idet vi anser EA og SOA som værende to vidt forskellige ting. EA er en tilgang til dokumentation og planlægning i en enterprise, mens SOA er et paradigme for udvikling og anvendelse af IT-ressourcer. Men det er i rollen som værktøj for dokumentation og styring at EA har sin styrke i forhold til SOA. Vi mener at EA overordnet vil tilføre SOA tre forskellige ting: 1. ved at fungere som bro mellem det strategiske, forretningsmæssige og det tekniske domæne 2. ved at fungere som ramme for dokumentation 3. ved at tilføre SOA styringsprogrammer 38 Bloomberg, p. 126 Side 33 af 55

34 Ad. 1 Af definitionen på EA fremgik det, at EA handler som at skabe overensstemmelse mellem det strategiske, det forretningsmæssige og det tekniske niveau i en enterprise. Samtidig opstillede vi i vores diskussion af SOA modenhed den præmis, at i takt med stigende SOA modenhed vil SOA få en større og større strategisk betydning for virksomheden. Med Porters udtryk, så bevæger vi os gradvist fra udelukkende at fokusere på operationel effektivitet, til at fokusere mere på den strategiske positionering af organisationen. Vi kan med andre ord ikke opnå SOA modenhed uden at skabe overenstemmelse mellem strategi, forretning og teknik. Det er efter vores overbevisning netop det som EA kan tilføre SOA. I de næste to punkter vil vi se på hvordan EA konkret kan bidrage med at opnå denne holistiske tilgang. Ad. 2 Et af de primære elementer i enterprise arkitekturen er rammeværket, der fungerer som struktur for dokumentation og analyse. Formålet med at dokumentere og analysere er at blive bedre til at planlægge og og tænke i overordnede sammenhænge. Vi har i de foregående afsnit set, hvor stort et overlap der er mellem Zachman rammeværket og de aspekter af en enterprise der vil blive påvirket af en moden SOA. Det viser at der er en høj grad af overenstemmelse mellem de rammer for dokumentation og analyse som rammeværket opstiller, og så de krav til dokumentation og analyse som vil være krævet, såfremt vi ønsker at anvende SOA til at realisere virksomhedens strategiske mål, og ikke bare som en teknisk platform til systemintegration. Ad. 3 Det sidste element som EA kan tilføre SOA er styringsprogrammer til at opnå den service orienterede enterprise. Styringsprogrammer er afgørende for en successfuld SOA indsats af to grunde. Den første grund er at hvis SOA skal skabe strategiske fordele, så er det ikke nok at der fokuseres på de tekniske elementer. Der skal som tidligere beskrevet en overordnet planlægning til. Den anden grund er, at SOA er et særdeles omfattende paradigme med en voldsom grad af kompleksitet. Jeff Schneider der er grundlægger af konsulentvirksomheden MomentumSI forudsiger på sin blog 39 : More CIO's will lose their job over SOA implementations than lost their job over ERP implementations. 39 Schneider d. 26/ : Side 34 af 55

35 De fleste opfatter nok ERP implementeringerne som overordentligt komplicerede IT-projekter, og citatet giver os en form for billede af kompleksiteten i SOA. Et så ambitiøst projekt kan ikke gennemføres uden at at der ligger velovervejede principper til grund for styringen. Enterprise arkitektur er det der kan give styring til SOA indsatsen. Som det allerede fremgår, så er det service-orienterede paradigme særdeles omfattende, og kræver megen omtanke ogstyring. Fra SOA modenhedsmodellens niveau 3 (Business Services og Collaborative Services) er SOA ikke længere et teknisk projekt, der kan ledes og udføres udelukkende af ITfunktionen. Hvor dokumentation er de værktøjer der skaber platformen til at opnå overenstemmelse mellem strategi, forretning og teknik, så er det styringsprogrammerne der gør denne overensstemmelse realiserbar. Enterprise arkitekturen har altså samlet set en masse at tilføre SOA. Man kan ligefrem spørge sig selv om det overhovedet er muligt at opnå en moden anvendelse af SOA uden elementer af enterprise arkitektur involveret. Efter vores opfattelse tilføjer enterprise arkitekturen de elementer der gør at SOA overhovedet kan blive realiseret som et strategisk værktøj, og ikke bare som et værktøj til at implementere en teknisk integrationsplatform. Uden enterprise arkitektur, ville man være tvunget til at skabe et SOA rammeværk fra bunden. På den baggrund vil vi opstille vores sidste hypotese. Hypotese 3: Enterprise arkitekturen vil levere de rammer og metoder der gør, at man kan opnå en strategiorienteret anvendelse af SOA Delkonklusion: I dette kapitel har vi beskæftiget os med den konceptuelle sammenhæng mellem EA og SOA. Vi lagde ud med at beskrive begrebet SOA modenhed. Vi beskrev formålet med en moden SOA tilgang som ønsket om at skabe konkurrencefordele. Jf. Michael Porters teorier, så skabes konkurrencefordele med strategi, dvs. ved at gøre virksomheden unik igennem det at foretage en række langsigtede valg og fravalg. Moden SOA ville derfor være drevet af forretningens strategi, ligesom moden SOA også ville have en påvirkning på virksomhedens opfyldelse af sine strategiske mål. Modsætningen til strategiorienteret SOA vil være operationel effektivitet, der handler om at gøre det samme som andre, men bare mere effektivt. Side 35 af 55

36 Vi valgte derfor en modenhedsmodel ud fra kriterierne om at den skulle kunne beskrive vores præmis om stigende strategisk fokus, ligesom at den skulle være tilpas simpel til at den kunne operationaliseres indenfor den begrænsede tid, vi havde til rådighed med case-virksomhederne. Valget faldt på den såkaldte SOA-MM model, der beskriver modenheden i fem niveauer, fra initielle services, til muligheden for at virksomheden kan reagere automatisk på forretningshændelser. Dernæst gik vi over til at analysere sammenhængen mellem EA og SOA på det konceptuelle niveau, ved at se hvor SOA kunne indplaceres i Zachman rammeværket. Vi tog indledningsvist udgangspunkt i Lublinskys og Tyomkins artikel, og viste hvorledes EA og SOA overlapper med hinanden, i forretnings-, applikations-, teknologi- og informationsperspektiverne. Ydermere fandt vi også gensidighed i forhold til Zachmans tidsaspekt. Det tog vi som indikation af, at sammenfalde mellem SOA og EA ville være stigende, ved højere SOA modenhedsniveauer, ligesom vi så det godtgjort, at SOA paradigmet var så omfattende, at det måtte påvirke EA. På den baggrund opstillede vi vores første to hypoteser, som vi vil belyse med vores empiri, nemlig: Hypotese 1 - Sammenfaldet mellem EA og SOA vil blive større ved højere SOA modenhedsniveauer Hypotese 2 - SOA paradigmet er så omfattende, at det vil påvirke enterprise arkitekturen nedefra Til sidst analyserede vi hvorledes EA kunne påvirke SOA. Vi fandt i den sammenhæng tre påvirkningsmuligheder: 1. ved at fungere som bro mellem det strategiske, forretningsmæssige og det tekniske domæne 2. ved at fungere som ramme for dokumentation 3. ved at tilføre SOA styringsprogrammer På den baggrund opstillede vi vores sidste hypotese: Hypotese 3: Enterprise arkitekturen vil levere de rammer og metoder der gør, at man kan opnå en strategiorienteret anvendelse af SOA Samlet set kan vi altså konkludere, at selv om EA og SOA er to vidt forskellige ting, så passer de ualmindeligt godt sammen, og kan nærmest ses som to sider af samme sag. Side 36 af 55

37 Kapitel IV belysning af cases Den Danske Banks arkitekturindsats 40 DB lagde allerede i 1990 grunden til sin nuværende arkitekturindsats med strategien "Én bank, ét system, én proces". Banken var fusioneret med Handelsbanken og Provinsbanken og skulle håndtere samkøringen af de tre bankers IT-systemer. Allerede i 1999 besluttede man at anvende services. Med i denne beslutningsproces var Claus Torp Jensen(CTJ), som stadig er ansat i DB i dag. DB har i forlængelse af sin strategi udviklet en omfattende IT-arkitektur, der mest af alt kan kaldes serviceorienteret - selv om banken i følge CTJ aldrig har haft et SOA-projekt. Det vender vi tilbage til. Løsningen I 1999, da de første serviceorienterede skridt blev taget, skyldtes det et behov for at kunne kommunikere mellem bankens forskellige systemer. Og da grundholdningen var, at dette først og fremmest var et teknologisk problem, udviklede man en ESB for at løse problemet. Banken fik dog efterhånden øjnene op for, at der kunne være andet og mere end teknologi i ideen om at integrere de forskellige systemer. Derfor tog man ved årsskiftet initiativ til "det hele projekt", der skulle samkøre IT og forretning via et SOA-paradigme. Partnerskabet mellem IT- og forretningsorganisationen blev nu et andet: Hvor det tidligere havde været aftalebaseret, fik ITafdelingen nu ansvar for både forretnings- og IT-løsningen, mens forretningsorganisationen fungerede som kravsstiller med udgangspunkt i sine behov. I dag opererer DB med et SODA (Service-Oriented Development of Applications) paradigme. Udgangspunktet for dette er en assembly first tankegang, hvis hovedidé ifølge CTJ er, at det første skridt i et IT-projekt er at skille forretningsbehovet ad og finde ud af, hvad man har brug for. Andre elementer i DB's SODA-paradigme er, at forretning og IT skal kombineres, og at dette bedst kan gøres ved at kombinere serviceorientering og BPM (Business Process Management). Det er derfor, man ifølge CTJ ikke kan tale om et decideret arkitekturprojekt i DB. Han siger, at der ikke er tale om en bevægelse fra et punkt til et andet, men snarere en løbende indsats: Det er derfor, jeg ikke tror, man kan gøre det som et projekt, det er et organisatorisk tiltag en kulturel forandring. Det er interessant at bemærke den helt åbenlyse kombination af et stykke teknologi i form af serviceorientering og et klassisk forretningsmæssigt værktøj som BPM. Det vidner om, at DB har nået et punkt, hvor IT og forretning flyder sammen og ikke længere er forskellige størrelser, der kun vanskeligt lader sig forene. Det ses også i de 5 elementer, der ifølge CTJ bedst beskriver sammenhængen i DB's arkitekturindsats: 40 Kilden til dette afsnit er et interview, som vi gennemførte den 13/ Side 37 af 55

38 Forretning Funktionalitet GUI Proces Data (Figur 4.1 egen tilvirkning) Pointen er her, at der er en kombination af tekniske og forretningsmæssige krav, der skal integreres for at opnå det resultat, der er bedst for DB som helhed. Centralt står brugergrænsefladen, der skal forene de forskellige elementer, der på hver deres måde er vigtige for, at DB får IT-værktøjer, der løser deres formål. Interview med Claus Torp Jensen Som bekendt har DB en ganske stor indsats bag sig på det serviceorienterede område. Som det første ville vi gerne vide lidt om optakten til denne proces. Ifølge CTJ har DB's proces et langt stykke hen af vejen været drevet af et fokus på den samlede organisation. Allerede i 2002 med "det hele projekt" blev dette fokus formaliseret. Det betyder også, at indsatsen har været drevet af ønsker på et strategisk niveau: Har vi haft en diskussion fra toppen af koncernen, om det er den rigtige måde at udvikle på? Nej. Har vi løbende diskuteret på ledelsesplan, om det var det, vi ville? Ja. Man kan ikke tale om governance og sponsorship i traditionel forstand, når det her er en kulturel forandring drevet af strategi. Strategierne har helt klart top-management sponsorship, men udmøntningen af strategierne i, hvad der så skal til, har et langt stykke hen af vejen været drevet af mellemlederne, lyder CTJ's måde at beskrive forløbet på. Men selv om DB relativt hurtigt udarbejdede en strategi til at samle forretning og teknologi, kom teknologien først. I 2002, da man lancerede "det hele projekt", havde man arbejdet serviceorienteret i flere år. Men efterhånden opstod erkendelsen om, at man var nødt til at involvere forretningen for at kunne realisere servicetanken. EA er koblingen af IT og forretning, men CTJ har en opfattelse af EA, der afviger fra vores definition i denne opgave. Hvor mange opfatter EA som et værktøj til at komme fra et udgangspunkt til et mål, ser CTJ først og fremmest EA som et værktøj til viden og analyse. Derfor har DB udviklet et rammeværk til dokumentation af virksomhedens sammenhænge - der i øvrigt er inspireret af det rammeværk, som Zachman er forfatter til. DB's EA er "samtlige assets i udviklingsprocessen og porteføljen og evnen til at dokumentere og genanvende dem". Da vi spurgte CTJ, om DB havde en EA, svarede han derfor: "Hvis formålet med at have en Enterprise Arkitektur er at være i stand til at standardisere og genanvende - så er det det, vi gør." Side 38 af 55

39 Drivers Det viser sig i løbet af interviewet, at baggrunden for arkitekturindsatsen i DB har ændret sig siden begyndelsen. Da var målet at opnå efficiency (operationel effektivitet) i måden, man kommunikerede mellem systemer på. Ifølge CTJ blev man dog hurtigt klogere. I dag er de grundlæggende drivers bag processen ønsket om at opnå agilitet og effectiveness hvor effectiveness i modsætning til efficiency sigter mod at maksimere værdien af en investering. Det illustrerer, hvordan man i DB har bevæget sig fra et rent teknologisk fokus til et mere forretningsorienteret. I dag skal arkitekturen medvirke til at sikre, at DB er i stand til at reagere på muligheder og trusler, og hvad der ellers måtte forekomme i markedet. DB er i dag nået dertil, hvor: "Den største udfordring er rent faktisk kultur", hvis man spørger CTJ. Det betyder, at forretningsledelsen træder i forgrunden frem for teknologien. Alle medarbejdere skal overbevises om det fornuftige i forandringer, da det koster mange penge og ressourcer at flytte en stor organisation som DB. Modenhed Når man tilsyneladende har nået et punkt, hvor de forretningsmæssige udfordringer er de største for arkitekturindsatsen, er det interessant at undersøge, hvordan man måler udbyttet af arkitekturen. I DB anvender man CMMI til at måle hvad organisationen er i stand til. Man har haft et CMMI-projekt kørende i tre år. På den måde måler man ikke udbyttet af arkitekturindsatsen direkte, men kan kun måle på organisationen som helhed. CTJ ser DB's indsats som tredelt: Først implementerede man serviceorienteret teknologi, så valgte man et mere bredt favnende udviklingsparadigme, og nu er man nået til erkendelsen af, at man skal arbejde med den organisatoriske modenhed - i DB's tilfælde bl.a. vha. CMMI. Man har endnu ikke nået et punkt, hvor teknologien kan understøtte virksomhedens beslutningstagning. Ifølge CTJ er det noget, man har intentionen om; og man har med den nuværende arkitektur bygget platformen til det. Men man mangler endnu at få indsamlet tilpas meget information til, at det vil give mening. Skal man indplacere DB's SOA-indsats i SOA MM, er der flere åbenlyse kendetegn, der kan medvirke til at placere DB. Vi ved, at DB har overstået niveau 1, initial services: Man har ud fra et ønske om funktionalitet forsøgt at integrere flere systemer vha. services. Ligeledes har vi set eksempler på, at man i DB har gjort sig arkitektoniske overvejelser om den serviceorienterede indsats. Man er gået væk fra en snæver efficiency-tilgang til en mere costorienteret effectiveness-strategi, der netop kendetegner niveau 2. Integration mellem forretning og IT som beskrevet i niveau 3 er præcis, hvad CTJ beskriver som ét af resultaterne af DB's SOA-indsats. Umiddelbart vurderet har DB's fokus primært været på en optimering af de interne Side 39 af 55

40 forretningsprocesser vha. arkitektur. Der kan dog ikke være nogen tvivl om, at DB også har nået niveau 3. DB har det i tanken, at bevæge sig videre til et niveau, hvor man dels er i stand til at måle på forretningsprocesserne med henblik på at opnå kontinuerligt feedback og respons på forretningsbegivenheder, og dels efterfølgende bliver i stand til at reagere automatisk på disse hændelser. Man har altså intentionen om at nå videre til niveau 4 og niveau 5, men erkender at man endnu ikke har forudsætningerne på plads. Påvirkningen mellem EA og SOA CTJ skelner meget kraftigt mellem paradigmer og teknologi: På den ene side står SOA, der for CTJ betegner den serviceorienterede teknologi, mens SODA på den anden side betegner et paradigme, der er uafhængigt af en teknologisk platform. I stedet angiver SODA en bestemt måde at tilgå arkitekturbegrebet på. Dette står i umiddelbar modsætning til det begrebsapparat, vi har skitseret for opgaven. Derfor vil vi lægge vægt på begrebernes forskellige betydninger i det følgende. CTJ anvender SOA-begrebet til at differentiere teknologi og arkitektur. For ham er relationen mellem teknologi og arkitektur dybest set uinteressant. Derimod er det for ham interessant at se på relationen mellem et paradigme som SODA og implementationen af en EA: "SODA er det paradigme, som din EA skal operere indenfor, så SODA sætter nogle af rammerne for, hvilke artefakter du har brug for, så der er nogle valg, der er truffet á priori, hvis man siger, at man ønsker et bestemt paradigme". Derimod siger CTJ om løs kobling mellem EA og teknologien, der for ham ikke nødvendigvis behøver at være SOA: "SODA kan i sit fysiske udtryk benytte sig af SOA-teknologi, OOteknologi, klassisk teknologi, you name it". Dette sætter en tyk streg under den tendens i DB, der peger i retning af, at teknologien er blevet noget sekundært, mens forretningsmulighederne derimod er i centrum. CTJ runder af: "Den modne organisation har forstået, at det at administrere viden er mindst lige så vigtigt som at administrere kode. At man ikke kan tænke forretning og IT hver for sig, men at man må gøre det sammen". Et praktisk eksempel på det er anvendelsen af forskellige standarder i DB. Hvor normale web services anvender XML i deres kommunikation, anvender DB den standard, der er anvendelig i den specifikke sammenhæng - ud fra en cost-betragtning: Eksempelvis anvender man kun XML ved kommunikation med eksterne partnere, mens man ikke går af vejen for at bruge en gammel mainframekommunikationsprotokol, hvis det er mest hensigtsmæssigt i en given situation. Det illustrerer, at DB ikke lader sig styre af teknologiske principper, men i stedet lader de teknologiske principper blive styret af mere pragmatiske betragtninger. Side 40 af 55

41 CTJ opsummerer DB's filosofi på følgende måde: "Det er én af grundene til, at jeg tror, at de virksomheder, der kører et SOA[vores fremhævning, her menes tydeligvis ren teknologi]-projekt, de fuldstændig har misforstået, hvad det handler om. Mange af dem har meget meget travlt med at komme over på en serviceorienteret teknologi - OG - hvad fik du ud af det? Ud over at have brugt en masse penge [...] med mindre man forstår, at der, hvor værdien bliver skabt, er i omsætningen af forretningsbehovet til de stumper, der skal til, og vælger sit paradigme og sin måde at gøre det på, og sin EA til at styre det med - så bliver man out-sourcet"! Med alt tydelighed har DB altså bevæget sig fra en situation, hvor konkrete tekniske valg var på dagsordenen til en situation, hvor det er forretningsmæssige krav, der styrer IT-indsatsen og ikke blot mere eller mindre tilfældige teknologiske valg. Danmarks Radios Arkitekturindsats 41 DR vedtog i 1999 en strategiplan, der bl.a. fastlagde retningslinjerne for virksomhedens fremtidige teknologiske udvikling. I dag har DR implementeret serviceorienteret teknologi og arbejder ud fra en veludbygget enterprise arkitektur. Bag denne indsats stod Michael S. Hansen(MSH), som på det tidspunkt var IT-direktør i DR. Han er i dag ansat i en lignende stilling i Region Sjælland. Michael er den primære kilde til vores informationer om arbejdet med arkitektur i DR. Interviewet I strategiplanen fra 1999 var det et centralt element, at man skulle arbejde for anvendelsen af modulær software med henblik på at sikre øget genanvendelighed. På det tidspunkt havde man ikke gjort sig klart, hvilke konsekvenser denne beslutning skulle få, og man kunne heller ikke sætte navn på konceptet. Selv om det var en strategiplan, der blev udarbejdet på ledelsesniveau, som gav startskuddet til DR's arkitekturindsats, så vil det ikke være forkert at sige, at den primære driver for indsatsen i begyndelsen var teknologien. Godt nok fastlagde planen nogle retningslinjer, men som MSH siger: "Men på det tidspunkt aner man jo ikke, hvad det er. Man har ikke rent defineret, at det skal være sådan en slags enterprise architecture. Men det er de første principper, der bliver lagt klar der". Derfor fulgte man strategiplanen op med en beslutning om at tilstræbe en stjerneopbygning 42, der gjorde brug af serviceorienteret dataflytning. Først senere førte denne implementering af teknologi til en erkendelse af, at der var behov for en overordnet plan for anvendelsen af samme: En Enterprise Arkitektur(EA). Denne situation beskrives meget klart af MSH: "Så skal man også have beskrevet hele arkitekturen og sammenhængen, og... og ønsket om at have det inde som en, en beslutningsparameter i prioriteringer betyder så, enterprise architecture begrebet bliver taget til det her, og så begynder 41 Kilden til dette afsnit er et interview, som vi gennemførte den 18/ En central hub er samlingspunkt for et antal klienter Side 41 af 55

42 man så at definere de forskellige områder". Med andre ord var det teknologien i form af SOA, der førte til behovet for og ønsket om en decideret EA. Det var tilfældet, fordi alt, hvad man lavede på applikationssiden, kørte mod SOA med fuld fart. Denne udvikling affødte behovet for en EA-paraply, der kunne indgå i styringsmodeller, strategier o.s.v. I forbindelse med det praktiske arbejde med udformningen af en EA for DR anvendte man Zachman's rammeværk. Rent metodologisk lavede man dog også sin egen udviklingsmodel, der var tilpasset de konkrete behov i DR. Dette indebar blandt anvendelsen af de to forskellige teknologier.net og J2EE side om side. Endvidere anvendte man Rational Unified Process (RUP) i udviklingsarbejdet. Drivers Driveren bag arkitekturindsatsen var først og fremmest en række forretningsmæssige udfordringer, der var resultatet af den teknologiske udvikling. Der var opstået et krav om, at man konstant var i stand til at gøre tingene hurtigere, bedre og billigere, fordi konkurrenterne var i stand til det. Det var udgangspunktet for ideen om at anvende services. Man fandt ligeledes ud af, at man for at sikre kvaliteten af disse services var nødsaget til at overvåge og styre anvendelsen af de forskellige services. Dermed opstod behovet for en ESB. Det udtrykkes klart af MSH: "Det var drevet af, at vi simpelthen ikke kunne følge med, med det budget, der lå. [...] Og så kunne vi se, at teknologien ændrede sig superhurtigt". Ligesom for DB drejede det sig altså på én gang om både efficiency i form af ønsket om mere IT for det samme budget og effectiveness i form af de mere forretningsmæssige krav, som DR stod over for. MSH opsummerer DR's krav i fire punkter: Kravet om hurtigere time-to-market Ønsket om øget genanvendelighed af de forskellige programmer/produkter Ønsket om hurtigere produktafprøvninger Kravet om sikker leverance af nye tjenester Modenhed Skal man indplacere DR's SOA-indsats i SOA MM, er der flere åbenlyse kendetegn, der kan medvirke til at placere DR. For det første kan det umiddelbart konstateres, at DR har opbygget de første services og dermed minimum har nået niveau et. På niveau to er indsatsen kendetegnet ved de første arkitektoniske øvelser, hvor argumentet bag indsatsen er ønsket om at nedbringe omkostningerne (~operationel effektivitet). Vi kan også umiddelbart konstatere, at DR har nået dette niveau. Side 42 af 55

43 Mere kompliceret bliver det, når det skal undersøges, om DR kan indplaceres på niveau tre. Her drejer det sig om at få forretningsprocesser og teknologi til at spille sammen. Ifølge MHS har DR anvendt services til forretningsmæssig integration både internt og eksternt. På det rent forretningsmæssige område har man gjort brug af elektronisk fakturering, men da DR først og fremmest er et mediehus, er forretningsudvikling for DR ofte lig med produktudvikling: DR har da også internt brugt services til at lave playlister på nettet og til at styre netradio, ligesom man har integreret sig med eksterne partnere. Et eksempel på det er muligheden for at blive videreført fra netradioen til en udbyder af onlinemusik, der sælger det stykke musik, der aktuelt bliver spillet i radioen. Også niveau tre i modenhedsmodellen synes DR dermed at have nået. Derimod kan det diskuteres, om DR er nået et modenhedsniveau videre. På niveau fire begynder organisationer at opstille metrikker og anvende diverse måleinstrumenter til at måle på sine forretningsprocesser. I mediebranchen har man traditionelt anvendt metrikker som seer- og lyttertal til at vurdere populariteten af et produkt. Med Internettets komme er så fulgt muligheden for at måle antallet af besøgende. Disse måleenheder er indtil videre de eneste, DR anvender. Dette kan dog til dels hænge sammen med den branche, som DR opererer i. Man vil ofte foretage kvalitative vurderinger af produktet - en type vurderinger, der qua deres natur er vanskelige at måle på: "Der er ikke nogen metrik, der siger: Er det nu en god eller en dårlig idé det her", siger MSH. På den anden side er det sandsynligvis altid muligt at opstille metrikker inspireret af eksempelvis CMMI, som Danske Bank har gjort det, for at måle organisationers evne til hurtigt at omstille sig osv. Det er ikke en strategi, man indtil videre har fulgt i DR, så umiddelbart er det svært at argumentere for, at DR har nået niveau 4. Man kunne endvidere stille spørgsmålet, om det skyldes DR's funktion som offentligt finansieret servicevirksomhed, hvilket begrænser kravene til at tilpasse sig skiftende leverandørforhold, til- og afgang af kunder med videre. Det er udfordringer, som en virksomhed som Danske Bank er nødt til at tackle. En anden forklaring kunne være, at DR måske stadig mangler at udbrede anvendelsen af services til andet end bare produktsiden og dermed udnytte teknologien til styring og pleje af kunder, til lagerstyring og til andre opgaver uden direkte forbindelse til kernekompetencen (hvilket ville være en opgave, der var en del af niveau 3). Det er dog et spørgsmål, der vil være uden for denne opgaves fokus og i øvrigt ikke vil kunne besvares med den nuværende empiri. Påvirkningen mellem EA & SOA Som vi allerede har været inde på, opstod ideen om en EA først i DR, da man var begyndt at implementere serviceorienteret teknologi. Derfor spurgte vi MSH, om man kunne forestille sig, at det kunne været gået den anden vej. Svaret var kontant: "Det var aldrig sket. [...] Man kunne godt lave et dokumentationsarbejde - men det havde man ikke set som et afgørende twist. Det var først noget, der opstod, da man begyndte at forstå, hvad det er for nogen mekanismer, der kører." Side 43 af 55

44 Generelt er det MSH's opfattelse, at der først og fremmest har fundet en påvirkning sted fra SOA til EA. Udviklingen er kommet nedefra, hvor brugen af teknologien har skabt et behov for en ensartet dokumentations- og registreringsmetode. Det udtrykker MSH på følgende vis: "Det gav jo heller ikke mening at etablere et paradigme, som ikke hang sammen med den virkelighed, der var etableret". Dermed understreger han en væsentlig pointe: Nemlig at principperne i form af en EA er afhængige af den virkelighed, der allerede er etableret i form af SOA. Omvendt betyder tilstedeværelsen af en EA i DR, at hvert skridt i udviklergruppen bliver vendt i arkitekturgruppen. Dermed er der alligevel tale om en art symbiose mellem EA og SOA, hvor der, med MSH's ord: "har været en påvirkning indholdsmæssigt til EA, og rammemæssigt til SOA-delen". Derfor finder MSH det vigtigt at understrege, at det er nødvendigt at forstå samspillet mellem principperne som formuleret i en EA og virkeligheden i form af den teknologiske mulighed. Ellers får man en kamp mellem principper og virkelighed, "og mærk jer mine ord - den taber principperne altid", siger MSH. Frihed som usikker nødvendighed Hos DR har man forsøgt at håndtere ovennævnte skisma: Når det sker, at folk ikke overholder retningslinjerne som givet i EA'en, har man en politik for håndteringen. F.eks. arbejder man med såkaldte "sandkasser", hvor BETA-lanceringer kan holdes for sig selv uden at påvirke den resterende arkitektur. Problemet er, at DR lever af kreativiteten og er tvunget til at skabe rum til den på trods af de ganske nødvendige principper, der er formuleret i EA'en. Det er en problematik, som MSH får sat fint ord på:"men det er hele tiden en overvejelse af: Hvornår skal du begrænse innovationen, ikk'...? For at få sikkerhed... Og hvornår bliver du fri på sikkerhedens bekostning?" DR har altså valgt at indgå enkelte kompromisser i forhold til de formulerede standarder og krav. I stedet har man formuleret en politik til netop at håndtere disse undtagelser. Det er et eksempel på, at EA ikke kun er et stramt styringsværktøj. Alligevel er det tre klassiske termer, MSH hæfter på begrebet, når han skal forklare, hvad EA er i DR: Det giver overblik og fungerer som et styringsredskab og et strategisk redskab. Derfor arbejder man i dag på en teknologistrategi i DR, som EA'en afstikker rammerne for. Side 44 af 55

45 EA som total styring Ligesom i Danske Bank har man overvejet tanken om at bruge EA som en transitionsplan, der beskriver et ønsket endemål med arkitekturindsatsen. I DR har man dog - ligesom i Danske Bank - været nødt til at stille sig selv spørgsmålet, om det kan lade sig gøre at registrere tingene, før virkeligheden har ændret sig? Om denne udvikling siger MSH: "Jeg tror, man har haft den ideelle tilgang, da man startede op, og så har man nok måttet erkende, at hvis nu bare, vi kunne mappe principperne og så have en strategisk principtilgang, en standardtilgang, og så har man dykket ned i enkeltområder [...] der har simpelthen ikke være manpower til det, det er jo en gigantisk opgave, hvis du skal til at mappe alt det der". Én af grundene til, at man nåede denne konklusion var, at man ikke ville få noget for pengene, hvis man forsøgte at gøre alt på én gang. Det ville i stedet komme til at blive en stor omkostning selv på længere sigt. For MSH er det et spørgsmål om bundlinietankegang: "De virksomheder, der kører det i bund, ikk'... Det er mit bud, det er enten en virksomhed, der er ejet af en fond, som ikke skal lave overskud, fordi de mentalt tænker... De har overskud til at tænke idealistisk. Og det er jo rigtigt at gøre. Altså det, der står i lærebøgerne, er jo rigtigt. Det er bare for dyrt!" Derfor er EA i DR først og fremmest et spørgsmål om at etablere en ramme for styring og analyse: "Der hvor EA bliver godt, det er, hvis man dokumenterede sine principper, sine standarder og sådan nogen ting og sager - når du skal lave strategi. Der bliver det godt. EA er jo strategi. [...] Man skal sørge for, man bliver positioneret i de andre styringsmodeller f.eks. projektledelsesmodeller, beslutningsmodeller, at arkitekturdelen kommer ind, får lov til at sige: Okay venner, kunne vi holde os inden for den her ramme?" Indsatsens karakter I forlængelse af denne diskussion om EA'ens rolle i DR afslutter MSH interviewet i samme stil som hos Danske Bank, da vi spørger ham, hvornår EA/SOA-projektet slutter i DR: "Jeg er måske nok belært af erfaring mere af den opfattelse, at det her det ikke er et projekt. Det er simpelthen en filosofi." På vej ud af døren sammenligner han projektet med den evige opdatering af styresystemer på pc'erne; Det er en evig proces, som fortsætter kontinuerligt: "Det er jo en.. en udvikling af forretningens tankegang, af strategisæt, af styringsmetoder, af udviklingsmetoder. Der kommer bare noget nyt på hele tiden". Side 45 af 55

46 En sammenstilling af Danske Banks og Danmarks Radios arkitekturindsatser I gennemgangen af vores undersøgelse af arkitekturindsatserne i DB og DR har vi forsøgt at fokusere på enkelte elementer, der er centrale i forståelsen af dette arbejde. I dette afsnit forsøger vi at sammenstille resultaterne, således at læseren kan danne sig et samlet billede af de to virksomheder. En udvikling nedefra? Hos DB blev den første udvikling imod en arkitektur som anset som et teknologisk projekt: Nemlig at kunne kommunikere mellem bankens systemer, for at udmønte strategien om én bank, ét system, én proces. Først senere blev man opmærksom på, at en teknologisk indsats af denne karakter, ville kræve en kobling til forretningen, og dermed en overordnet plan i form af en EA. Hos DR lå der en strategisk plan bagved beslutningen om at anvende modulær software. Her var der dog primært tale om et teknologivalg. Først senere tog man initiativ til en decideret EA. Der er ikke fuldkommen overensstemmelse mellem forløbene i DR og DB. Ikke desto mindre er det ikke helt forkert at sige, at udviklingen mod EA og en topkoordineret IT-indsats, der sidestiller ITaspekter med forretningsmæssige aspekter, i begge virksomheders tilfælde har haft teknologien som det primære udgangspunkt. Ud fra vores samtaler med IT-lederne fra de to virksomheder ser det ud til, at behovet for integration først er blevet erkendt i takt med, at teknologien er blevet mere moden og har fået indflydelse på stadigt flere aspekter af den daglige drift af virksomheden. Relationen mellem EA og SOA Denne diskussion leder naturligt videre til en overvejelse af, hvordan serviceorienteret teknologi i form af SOA påvirker en EA og omvendt. Som indledning til denne overvejelse vil det være rimeligt at genbruge MSH ord om denne relation i DR de er nemlig meget beskrivende for begge organisationer: "[Der] har været en påvirkning indholdsmæssigt til EA, og rammemæssigt til SOAdelen". I DB er det anvendelsen af SODA, der eksemplificerer, hvorledes anvendelsen af teknologi på forhånd er med til at træffe nogle valg om, hvilke artefakter osv. der skal inkluderes i en EA. Omvendt er EA den ramme for viden og analyse, der anvendes til at styre teknologiindsatsen. Side 46 af 55

47 Hos DR er det udviklingen i teknologianvendelsen, der skaber behovet for en ensartet dokumentations- og registreringsmetode. Så selv om arkitekturindsatsen betyder, at alle væsentlige valg i udviklergruppen vendes i arkitekturgruppen, er arkitekturgruppen i lige så høj grad nødt til at tage hensyn til udviklergruppens behov; det illustreres bl.a. af den nødvendige hensyntagen til skæve indfald og ukonventionelle ideer i form af en relativt nem adgang til at udarbejde BETA-versioner og til at bruge de såkaldte sandkasser. Det er dermed en gennemgående og på sin vis kontradiktorisk opfattelse i både DB og DR, at EA, der egentlig opfattes som et styringsværktøj, i lige så høj grad påvirkes af teknologiudviklingen, som det er tilfældet den anden vej. Den konstatering kommer i umiddelbar forlængelse af vores tidligere konklusion af, at tanken om en EA først er modnet og udviklet i både DR og DB i takt med, at teknologien har nået et vist niveau af kompleksitet. En anden årsag til dette er en idé, som hovedsageligt stammer fra interviewet med MSH, nemlig ideen om, at de principper, der nedfældes i en EA, nødvendigvis må forholde sig til den virkelighed, der allerede er etableret i form af teknologi, hvis de skal give mening. Selv om det i princippet er en EA's fornemste opgave at styre og føre, er der altså i realiteternes verden i lige så høj grad tale om, at der finder styring sted i den anden retning. Modenhed I relation til organisatorisk modenhed tager vores undersøgelse udgangspunkt i modellen SOA MM. Det viser sig ret hurtigt, at DR og DB i henhold til denne model begge befinder sig på samme niveau af modenhed. DB er nået vidt i anvendelsen af metrikker i form af CMMI som et målingsværktøj for organisationen som helhed og har også ambitioner om at føre anvendelsen af SOA-teknologien videre til modellens niveau 4 og 5, hvor informationssystemerne er så udviklede, at de bliver i stand til på egen hånd at reagere på forretningshændelser ud fra givne regler. I modsætning hertil har DR ikke indført andre metrikker til måling af organisationens performance end de traditionelle mediemetrikker som seer- og lyttertal. Dette forhold understreger, at virksomhederne står på samme niveauer i i modellen, men at de ikke er nået lige langt i niveau 3. Det kan dog også være med til at illustrere, at anvendelsen af teknologi i virksomheder afhænger af den enkelte virksomheds kontekst. Der er milevid forskel på bank- og mediebrancherne, hvilket betyder, at behovet for måling med henblik på styring og i sidste ende tilpasningsevne er forskelligt i de to brancher. Som afslutning på dette afsnit har vi valgt at sætte DR og DB over for hinanden i en tabel, hvor de to virksomheder sammenlignes på forskellige punkter. Tabellen ses nedenfor og skulle gerne opsummere tingene, før vi efterprøver vores hypoteser i det næste afsnit. Side 47 af 55

48 Danske Bank Danmarks Radio Initielle drivers bag Ønsket om kommunikation på Strategisk valg af teknologi udviklingen tværs af systemer (efficiency) Udvikling i drivers Agilitet og omstillingsparathed Udvikling i teknologianvendelse (SOA) (effectiveness) fører til et behov for dokumentation/styring Strategi Først "Én bank, ét system, én Strategiplan fra 1999 vælger modulær proces", som havde til formål at software. integrere systemerne. I dag har man EA, der indgår i DR's Senere "Det hele projekt", der strategiske overvejelser. havde til formål at samkøre IT og Man arbejder på teknologistrategi med forretning udgangspunkt i EA'en. Governance Strategien har top-level EA anvendes som ramme til at styre sponsorship, men udmøntningen er projekter i en passende retning. Der drevet af mellemlederne. DB har gives mulighed for at bryde med bevaret ders hidtige governance- retningslinierne i EA'en for at sikre struktur retten til og muligheden for at innovere. Definition af EA Viden, Analyse, Governance, Overblik, styringsredskab og et Standarder (ikke transitionsplan) strategisk redskab (ikke transitionsplan) SOA modenhed Niveau 3, på vej videre Niveau 3 (Tabel 4.1 egen tilvirkning) Delkonklusion I dette kapitel har vi belyst vores problemstilling ud fra et empirisk synspunkt. Vores fremgangsmåde har været først at beskrive og kommentere de interviews vi har foretaget med vores casevirksomheder, hvorefter vi har foretaget en sammenstilling for at se på ligheder og forskelle. Vi fandt for det første mange ligheder mellem de to case virksomheder. For det første, så var de initielle drivers for SOA spørgsmålet om bedre at kunne integrere systemerne. For begge virksomheder gælder det også, at SOA efterhånden har fået et langt mere strategisk (og dermed forretningsmæssigt) sigte. Begge virksomheder udmønter SOA indsatsen som led i en overordnet strategi for virksomheden. Udviklingen af nye services sker i høj grad med udgangspunkt i forretningens behov. Drivers i den fortsatte udvikling af SOA, handler idag mere om agilitet og omstillingsparathed, end bare om operationel effektivitet. Side 48 af 55

49 I begge virksomheder kan man sige, at SOA har påvirket EA på indholdssiden. Her er dog forskelle på de to virksomheder. I DB har valget af SODA udviklingsparadigmet påvirket den indholdsmæssige side. I DR sker påvirkningen mere løbende bl.a. i form af en formaliseret hensyntagen til skæve indfald og ukonventionelle ideer af hensyn til muligheden for at innovere. Omvendt, så er der også nogle forskelle. I DR foregår der en langt større påvirkning nedefra, end der gør i DB, i og med at arkitekturgruppen løbende modtager input fra udviklergruppen. Der er altså en mere kontinuær og gensidig påvirkning mellem EA og SOA i DR, end man ser i DB. I ingen af virksomhederne har man lavet en komplet dokumentation af virksomheden as-is. I DB handler det om, at man mener at virksomheden er for stor, og ændrer sig så meget, at en dokumentation vil være uaktuel, før den er afsluttet. I DR ser man en komplet dokumentation som en principielt god ting, men man vurderer, at udbyttet af en sådan komplet as-is dokumentation ikke står mål med indsatsen, der skal til, for at opbygge den. Virksomhederne anlægger heller ikke helt samme syn på hvad EA er. I DB handler EA mest om viden, analyse, governance og standarder. I DR er en EA til for at give et overblik og for at fungere som et styringsredskab og som et strategisk redskab. Ingen af virksomhederne har formuleret en to-be tilstand. Vi har konkluderet, at begge virksomheder befinder sig på niveau tre i SOA MM, men at DB i modsætning til DR har intentionen om at bevæge sig videre. Side 49 af 55

50 Kapitel V belysning af hypoteser Undersøgelse af de tre hypoteser Vi har i opgavens kapitel 3 opstillet tre hypoteser, som det nu er på tide at efterprøve med baggrund i den empiri, vi netop har gennemgået. Vi vil her liste de tre hypoteser og belyse hver af dem via vores empiriske materiale. Hypotese 1 Sammenfaldet mellem EA og SOA vil blive større ved højere SOA modenhedsniveauer Pointen i ovenstående hypotese er, at man i takt med udviklingen af SOA vil bevæge sig fra at anvende teknologien på et grundlæggende operationelt (og teknisk) niveau mod en situation, hvor SOA anskues fra en strategisk synsvinkel. Vi finder, at vores casemateriale fuldt ud understøtter denne hypotese. I både DR og DB ser vi, at man i takt med SOA indsatsen gør sig flere og mere omfattende arkitektoniske overvejelser. I starten blev indsatsen for begge virksomheder hovedsageligt drevet af et ønske om bedre integration mellem systemerne. Efterhånden viser det sig for begge virksomheder, at en sådan indsats har det som en logisk konsekvens, at der opstår et behov for at samordne strategi, forretning og teknologi, hvilket vi i praksis sætter lig med en EA indsats. I sidste ende når begge virksomheder frem til den konklusion, at SOA ikke blot er en teknologi, men i højere grad er en filosofi - en måde at organisere sig på. Det står i skærende kontrast til de indledende SOA-øvelser, der i begge tilfælde først og fremmest bar præg af at være rene teknologiprojekter. Hypotese 2 SOA paradigmet er så omfattende, at det vil påvirke enterprise arkitekturen nedefra Hos begge virksomheder ser vi flere eksempler, der kan underbygge denne hypotese. Hos DR er det for det første interessant, at det er implementeringen af SOA, der er med til at gøre opmærksom på behovet for mere styring og dokumentation af indsatsen og dermed også fungerer som en driver for udarbejdelsen af en EA. Endvidere ser vi i DR, at arkitekturgruppen er nødt til at tage hensyn til udviklergruppens behov i den konkrete udformning af EA'en. Arkitekturgruppen styrer altså, men påvirkes samtidig nedefra af udviklergruppen. Side 50 af 55

51 I DB sætter man fokus på dette forhold på anden vis: Her siger man kort og godt, at der er nogle valg angående EA, der er truffet 'a priori, når man vælger et bestemt paradigme - i dette tilfælde SOA og SODA. Det står umiddelbart klart for os, at denne hypotese holder. De tre nævnte eksempler er forskellige, men siger på hver deres måde noget om, hvordan SOA-paradigmet kan påvirke en EA "nedefra". I forlængelse af den første hypotese giver det sig selv, at denne påvirkning vil blive større, efterhånden som en SOA-implementering modnes. Større strategisk fokus betyder større påvirkning. Vi ser altså, at SOA påvirker EA indholdsmæssigt. Hypotese 3 Enterprise arkitekturen vil levere de rammer og metoder der gør, at man kan opnå en strategiorienteret anvendelse af SOA Denne tredie hypotese er mere vanskelig at forholde sig til end de to foregående. Naturligvis kan vi umiddelbart bekræfte hypotesens gyldighed. Begge virksomheder har anvendt elementer af EA som en ramme i deres arbejde med SOA. Alligevel er der flere forbehold. I vores begrebsafklaring identificerede vi de to hovedelementer i EA som dels en dokumentationsmetode og dels som et styringsredskab. Begge virksomheder har generelt set anvendt EA som et værktøj til dokumentation og som struktur for deres analysearbejde. Der er dog to vigtige bemærkninger. For det første har ingen af virksomhederne satset på at lave en fuld dokumentation af virksomhedens as-is tilstand. Derudover har virksomhederne heller ikke formuleret en to-be tilstand. Det tætteste, man kommer en egentlig formulering af en transition, er implementeringen af deres respektive Enterprise Service Bus. I stedet har man anlagt en mere pragmatisk synsvinkel, hvor man har vurderet indsatsen løbende på en caseby-case basis. For at forstå, hvorfor dette er tilfældet, er det nødvendigt at se på de to virksomheders grunde til at gribe tingene an på denne måde. I DB vurderer man ganske enkelt, at et dokumentationsarbejde, der vedrører hele virksomheden, er om ikke umuligt så i hvert fald utrolig omfattende pga. virksomhedens størrelse. Endvidere vil et sådant arbejde tage så lang tid, at det er uaktuelt, før det er afsluttet. Slutteligt, så ser man ikke behovet eller muligheden for at foretage en transformation af hele virksomheden fra ét stadie til et andet. Man opfatter sig selv som værende i konstant forandring, hvilket gør ideen om et mål og en plan for, hvordan man når det, meningsløs. I stedet fokuserer man på at bruge EA som et redskab til at dokumentere og genanvende, så man hele tiden kan blive bedre til at gribe de muligheder, der opstår i markedet. Side 51 af 55

52 I DR har man lignende grunde. Man vurderer, at et sådant arbejde ville være alt for omkostningsfyldt set i forhold til det potentielle udbytte. Iderudover stiller man sig selv spørgsmålet, om det overhovedet er muligt at foretage en sådan registrering, inden situationen har ændret sig. Man ser i teorien metoden som fornuftig, men i praksis giver den ikke den nødvendige gevinst. Der er altså ikke overensstemmelse mellem den anvendelse af EA, vi havde forventet at se ud fra vores kendskab til teorien og den, vi rent faktisk har oplevet i de to virksomheder. Spørgsmålet er så om virksomhederne har valgt 'path of least resistance', eller om de har været tvunget til at foretage de valg som de har truffet. De to virksomheder har efter vores overbevisning implicit eller eksplicit foretaget en form for cost-benefit vurdering af omfanget af EA dokumentations- og planlægningsmængden. Udbyttet må nødvendigvis vurderes til at være større end indsatsen hvis man skal foretage en given handling. Vi har derfor lavet en konceptuel fremstilling af denne cost-benefit analyse. Omfanget af indsatsen i et EA projekt er afhængig af følgende tre elementer: Forandring - den hastighed hvormed virksomheden ændres og udsættes for forandringer i det omgivende miljø Størrelse - her tænkes ikke på virksomhedens størrelse, men snarere størrelsen på genstanden for indsatsen: Hvor mange forskellige IT-systemer, hvor meget hardware, hvor mange processer, hvor komplekse sammenhænge osv. skal inkluderes? Organisatoriske evner - virksomhedens 'capabilities' Den krævede indsats for en virksomhed vil være en funktion af følgende: (Forandring x Størrelse) / Organisatoriske evner Cost-benefit analysen vil bestå af en sammenligning af den nødvendige indsats med det potentielle udbytte. For at sætte arbejdet med en EA i gang må en virksomhed altså vurdere udbyttet af den færdige EA til at være større end den nødvendige indsats. Det, der kan diskuteres i forbindelse med DB og DR, er, om de har gennemført cost-benefit analysen korrekt. Det vil kræve et omfattende empirisk arbejde at lave en sådan vurdering, ligesom der uanset fremgangsmåden altid vil være et større antal ubekendte i en sådan analyse. Det betyder, at de to virksomheders valg om at anlægge en mere pragmatisk holdning til EA, end teorien foreskriver, ikke kan valideres eller afvises i denne opgave. Det eneste, vi kan konkludere, er altså, at der er stor forskel på, hvordan man beskriver EA i litteraturen, og hvordan man udfører EA i praksis. Det er dog tankevækkende, at begge virksomheder har valgt samme fremgangsmåde. Side 52 af 55

53 Kapitel VI Konklusion Vi har igennem denne opgave beskæftiget os med sammenhængen mellem EA og SOA. Vi foretog indledningsvist en begrebsafklaring, hvor vi definerede EA som ønsket om at kunne dokumentere og analysere en enterprise nu (as-is) og som ønsket i fremtiden (to-be), ud fra et integreret perspektiv for strategi, forretning og teknologi. Vi definerede derefter SOA som et paradigme for anvendelse og organisering af funktionalitet på tværs af den fysiske systemarkitektur og på tværs af domænejerskab. Hvordan påvirker EA og SOA hinanden konceptuelt? I kapitel 3 opstillede vi vores teoretiske fundament for opgaven. Vi beskrev SOA modenhed som en progression fra fokus på operationel effektivitet, og til et gradvist stigende strategisk fokus. På den baggrund valgte vi at anvende SOA MM modellen til at måle SOA modenhed. Efterfølgende analyserede vi sammenhængen mellem EA og SOA vha. Zachman rammeværket. Vi fandt at der var et stort overlap, og at denne steg i takt med modenheden. Vi fandt at SOA primært påvirkede EA indholdsmæssigt, mens EA påvirkede SOA rammemæssigt. På den baggrund opstillede vi tre hypoteser, som vi anvendte som analysegrundlag i vores behandling af empirien. Hvordan har casevirksomhederne i praksis anvendt EA i arbejdet med SOA - og omvendt? I begge virksomheder startede man med at anlægge en teknisk synsvinkel på SOA. Man har efterfølgende fundet behov for at skabe en mere forretningsmæssig tilgang til det serviceorienterede paradigme, hvorfor man har anvendt elementer af EA i sin indsats. Begge virksomheder lagt relativt mest vægt på at anvende EA som et værktøj til dokumentation og analyse. Side 53 af 55

54 Er der overensstemmelse mellem teori og praksis vurderet ud fra den tilgængelige empiri? I vores teoridel opstillede vi tre hypoteser: Hypotese 1 - Sammenfaldet mellem EA og SOA vil blive større ved højere SOA modenhedsniveauer Hypotese 2 - SOA paradigmet er så omfattende, at det vil påvirke enterprise arkitekturen nedefra Hypotese 3: Enterprise arkitekturen vil levere de rammer og metoder der gør, at man kan opnå en strategiorienteret anvendelse af SOA Vi fandt at alle tre hypoteser blev understøttet. Begge virksomheder anvendte EA elementer ved højere grader af SOA modenhed. Ydermere, så påvirkede SOA EA nedefra, i form af indholdsmæssige krav. Slutteligt så fandt vi, at EA leverede rammerne til at opnå en mere strategifokuseret anvendelse af SOA. Men vi fandt også, at ingen af virksomhederne havde lavet en tilnærmelsesvis komplet dokumentationaf virksomheden as-is, med henblik på at formulere en to-be tilstand for virksomheden som helhed. Derimod havde man anlagt en mere pragmatisk case-by-case synsvinkel. Vi opstillede en forventning om, at virksomhederne implicit eller eksplicit havde anlagt en costbenefit analyse. En sådan cost-benefit analyse så vanskelig at foretage, at det ligger uden for vores empiri at foretage et estimat om, hvorvidt virksomhederne har valgt den optimale tilgang til EA. Afslutning Afslutningsvis vil vi konstatere, at begge virksomheder indledningsvist har anlagt en serviceorienteret synsvinkel, og at EA først er kommet ind i billedet senere. Det antyder for os, at SOA vil være en vigtigt driver for adoption af EA elementer i fremtiden. Derudover ser det ud til, at EA og SOA i både DB og DR efterhånden er kommet til at hænge uløseligt sammen. Vi ser absolut en logisk sammenhæng mellem de to begreber, så selv om de beskriver to forskellige områder, så supplerer de hinanden på en måde, der gør det nærliggende at konkludere, at moden SOA og EA i virkeligheden er to sider af samme sag. Side 54 af 55

55 Appendix A - Litteraturliste: Bøger "An introduction to Enterprise Architechture", Scott Bernard, 2nd Edition, AuthorHouse, 2005 "Service orienteret arkitektur - integration som konkurrenceparameter", Henrik Hvid Jensen, Litera, 2. Udgave, 2006 "IT Architecture Toolkit", Jane A. Carbone, Prentice Hall, 1st Edition, 2004 "Service Orient or Be Doomed!: How Service Orientation Will Change Your Business", Jason Bloomberg & Ronald Schmelzer, Wiley, 2006 Artikler, whitepapers mv. "What is Strategy", Michael E. Porter, Harvard Business Review, November-September, 1996 "Dissecting Service-Oriented Architectures", Boris Lublinsky & Dmitry Tyomkin, Business Integration Journal, October 2003 "Architecture Artifacts Vs Application Development Artifacts", John A. Zachman, Zachman International, 2000 "Extending and Formalizing the Framework for Information Systems Architecture", John A. Zachman & John F. Sowa, IBM Systems Journal, Vol 31, No 3, 1992 "A framework for information systems architecture", John A. Zachman, IBM Systems Journal, Vol. 26, No. 3, 1987 Standarder "Reference Model for Service Oriented Architecture 1.0" (SOA-RM), OASIS, 2006 Specialer "SOEA", Rasmus Knippel, IT-Universitetet, 2005 Websites SOA MM - Side 55 af 55