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