Artikel trykt i It-håndbogen. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret.

Transkript

1 It-håndbogen Artikel trykt i It-håndbogen. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret. Børsen Ledelseshåndbøger er Danmarks største og stærkeste videns- og udviklingsklub. Uanset hvilket område eller emne du beskæftiger dig med, får du her et komplet opslagsværk på print, cd-rom og internet, der giver dig overblik og indsigt. Ledelseshåndbogen er et praktisk og overskueligt værktøj til dig, der vil være 100% opdateret inden for et bestemt område selvom du har en travl hverdag. Børsen Forum A/S, 2009 Børsen Forum A/S Møntergade 19, DK 1140 København K Telefon ,

2 Succes med SOA Succes med SOA af Jan Gravesen, IBM Global Business Services 1. Indledning To ofte stillede spørgsmål er hvordan man bedst kommer i gang med SOA og hvilke faktorer, som bidrager til at sikre at en SOA kan implementeres med succes. Gennemgribende SOA studie For at besvare disse spørgsmål gennemførte IBM s Academy of Technology i 2008 et gennemgribende studie af SOA projekter med henblik på at afdække og beskrive de faktorer, der var til stede i succesfulde SOA projekter og som adskilte dem fra projekter, der ikke kunne kaldes succesfulde, fordi de ikke havde indfriet de oprindelige forventninger til realiserede fordele og omkostninger SOA projekter Udgangspunktet for studiet var de godt SOA projekter, som IBM årligt er involveret i på verdensplan. På baggrund af denne mængde blev 200 projekter udvalgt fordi de kunne kvalificeres som værende succesfulde målt fra den aftagende organisation og IBMs side, og fordi der forelå en kritisk mænde information om projekterne, deres tilblivelse, resultater og interne konstruktioner. Disse 200 projekter blev herefter indsvævret til 100 specielt særligt egnede projekter, som derefter blev til genstand for et indgående Academy of Technology studie. I studiet, som havde en varighed af godt 4 måneder, deltog 120 af IBM s bedste it-arkitekter, Distinguished Engineers og Fellows. Formålet var i første hånd, at identificere de områder hvor udfordringerne med at implementere SOA var størst de såkaldte problemdomæner og derefter at identificere de specielle succesfaktorer ved projekterne. I anden hånd var det at gøre de fundne succesfaktorer til genstand for vurdering af om de var replikerbare, dvs. om de kunne finde an- 4/August 2009 It-håndbogen 1

3 Succes med SOA vendelse generelt i andre organisationer, og derefter at beskrive dem i generelle vendinger således at andre projekter kunne drage nytte af dem under selve projekteringen. På denne måde blev projekter som var blevet succesfulde fordi der gjaldt særlige forhold i de respektive organisationer som underbyggede successen, men som ikke kunne antages at findes andre steder, filtreret væk. 2. Hvad er anderledes med SOA? Et ofte stillet spørgsmål drejer sig om hvorvidt og i givet fald hvordan SOA adskiller sig fra andre lignende arkitekturelle stilarter. Står SOA simpelthen ikke bare for Same Old Architecture, altså noget vi alligevel altid har gjort? Fire væsentlige forskelle Svaret er, at SOA adskiller sig fra andre tilsvarende måder at gøre tingene på, og der er mindst fire væsentlige forskelle: Den første forskel ligger i den udbredte brug af standarder. Anvendelsen og den brede accept af XML og WSDL standarderne har påvirket den måde, som leverandører og industrikonsortier udvikler videre standarder på. Standarderne er uafhængige af programmeringssprog og operativsystemer og derigennem adskiller de sig fra tidligere standarder som Java og CORBA, der var knyttede til programmeringssprog eller til særlige programmeringsparadigmer. SOA vedligeholder desuden et fokus på interoperabilitet i stedet for blot på integration. Med interoperabilitet forstår vi evnen til at arbejde sammen på tværs af systemer og organisatoriske enheder. Integration. Det adskiller sig fra integration derved at integration fortrinsvis handler om at bygge transportveje mellem forskellige systemer og organisatoriske enheder men ikke nødvendigvis om hvordan de forskellige systemer og organisationsenheder samarbejder. Noget, som er et særkende for SOA, er den antagelse at enhver organisation og enhver virksomhed har et unikt virksomhedsdesign, som beskriver hvad virksomheden gør, hvilke aktiviteter og processer, som det udfører, hvilke ydelser (services) den leverer og aftager, hvilke regler den arbejder efter og hvad dens målsætninger er. Dette design er et velegnet redskab til at udvikle kommunikationen mellem virksomheden og dens egen informationsteknologi. Det leder til den videre antagelse, at en 2 It-håndbogen 4/August 2009

4 Succes med SOA virksomheds aktiviteter kan modeleres og udtrykkes som services, at services kan samordnes i tværgående processer, og at disse services og processer kan implementeres i en SOA. SOA arbejder endelig med et andet perspektiv på genbrug, som er orienteret mod at forbedre organisatorisk produktivitet gennem deling af ressourcer og serviceaktiviteter, og ikke kun sigter mod at forbedre produktiviteten for programmører og systemudviklere. 3. Hvad er så egentlig problemet med SOA? SOA er en arkitekturel stil til udvikling af automatiserede aktiviteter, som har været under udvikling i snart 40 år og som rummer det bedste fra objekt-orienteret programmering og lagdelt arkitektur. SOA arbejder med services, ikke systemer Når vi siger at SOA er velgnet til at programmere automatiserede aktiviteter, er det fordi SOA adskiller sig fra systemparadigmet ved at man kan programmere funktionalitet, som ikke er indholdt i et it-system. I realiteten er det muligt at implementere alle automatiserbare aktiviteter i en organisation som services, der afvikles af en fælles SOA platform. Det er altså services, ikke systemer, som er den fundamentale byggesten i denne arkitektur. Det traditionelle systemparadigme for udvikling og afvikling af forretningsaktiviteter, kommer ud af et behov for at have funktioner som kan kalde hinanden effektivt. Tidligere var den effektivitet med hvilken funktioner kunne kalde hinanden betinget af, at de delte samme system og havde adgang til de samme data. En oversætter kunne oversætte de beskrevne definitioner af funktionerne og skabe en fysisk addressebaseret version af dem, som var optimeret ifht. computerens adresserum. Omkring midten af 1980erne kunne funktioner kalde hinanden v.hj.a. remote procedure calls (RPC) over fysisk adskilte adresserum..dvs. at en funktion som blev afviklet på en computer kunne nu kalde en funktion, som blev afviklet på en anden computer v.hj.a. et procedurekald. På et tidspunkt omkring midten af 1990erne var netværk og netværksprotokoller efterhånden ved at være så effektive, at disse funktionskald næsten kunne foretages lige så effektivt som hvis funktionerne delte samme lagerområde. 4/August 2009 It-håndbogen 3

5 Succes med SOA Problemet på dette tidspunkt var, at funktioner for at kunne kalde hinanden skulle anvende samme dataformat og protokol til at foretage kaldet og få et resultat tilbage, og disse formater og protokoller skulle så bindes til det eller de operativsystemer (nedadtil) og programmeringssprog (opadtil) som funktionerne var udviklet i. Java er et eksempel på en udviklings- og afviklingsstandard, som kombinerer klassebegrebet i objekt-orienteret programmering med en lokationsuafhængighed baseret på RPC mekanismer, som så kaldes JMI, AJAX o.l. Imidlertid skal man for at kunne anvende disse mekanismer også anvende Java som programmeringssprog og platform. Med SOA anvendes i stedet en standard for formatet af meddelelser (XML), formatet for navngivning og beskrivelse af services (WSDL) og en protokol (SOAP) til servicekald, som ikke kun knytter sig til et enkelt programmeringssprog, men til mange forskellige. SOA arbejder heller ikke med et klassebegreb som i objekt-orienteret programmering og placerer sig derfor neutralt ifht. objekt- eller proceduralt-orienterede programmeringssprog. En SOA kan desuden bestå af mange forskellige, fysisk og geografisk adskilte udviklings- og afviklingsplatforme, som hver for sig anvender forskellige programmeringssprog, f.eks. C#, C og Java, og som afvikles på forskellige operativsystemer, men som ikke desto mindre eksponerer services på samme måde, anvender samme standarder, og som derfor kan kalde hinandens services. Med SOA får vi altså en adskillelse mellem den måde aktiviteter (læs: services) er defineret på, og den måde de er implementeret på. Denne adskillelse opstår ved at det egentlig er ligegyldigt hvilke programmeringssprog og platforme, der er anvendt til at implementere aktiviteterne. Det afgørende er hvordan aktiviteterne er definerede og hvordan de fungerer. SOA og BPM skaber grundlaget for genbrug af services Tilsvarende skaber BPM en adskillelse mellem processers definition og deres implementering. Her kan vi definere en proces som en relateret mængde aktiviteter, der tilsammen producerer et resultat, som har værdi for en kunde. Processerne skal koordinere udførelsen af aktiviteterne så resultatet afpasses ifht. hvad der forventes af eller er aftalt med kunden. I BPM defineres processerne og aktiviteterne hver for sig, og der anvendes BPM software til at udføre processerne og koordinere aktiviteterne. 4 It-håndbogen 4/August 2009

6 Succes med SOA På trods af disse potentielt strålende egenskaber ved SOA og BPM er der flere besværligheder, som fordrer at der arbejdes med tingene på den rigtige måde, før resultaterne, som vi diskuterede ovenover, kan realiseres. De væsentligste af disse besværligheder blev afdækket i IBM s studie og viste sig at være: SOA erstatter et system-orienteret arkitekturparadigme for systemudvikling, som er meget gammelt og velforstået og som de fleste projektorganisationer har valgt at organisere sig efter uden en organisering som opfordrer til genbrug vil det være vanskeligt at levere en SOA SOA sigter i bund og grund efter at skabe et bedre grundlag for genbrug når en service er defineret af et projekt eller en organisatorisk enhed et sted i organisationen, skal den ideelt set kunne anvendes (genbruges) af et andet projekt eller af en anden organisatorisk enhed det er dette løfte om genbrug, som oftest er grundlaget for en business case om at introducere SOA i organisationen. Men genbrug har vist sig langt vanskeligere at forstå og realisere end de fleste havde forventet, og der knytter sig forskellige spilleregler til genbrug, som skal respekteres før værdien viser sig. Når vi langsomt opbygger en SOA, projekt for projekt, ender vi med mange services, mange flere end vi havde systemer. Vi ved i dag at mange systemer er svære at administrere og at administrationen i sig selv er en omkostning, der ikke kan negligeres. Med SOA vokser mængden af ting, som vi nu skal administrere dramatisk, og vi skal derfor finde og implementere en effektiv måde at levere denne administration på, for at undgå at omkostningerne løber løbsk. I en SOA arbejder vi med et nyt niveau af finkornethed vi har mange services, mange flere end vi havde systemer, og disse services kalder hinanden og indgår i komplicerede service- og proces-netværk over et eller flere netværk. Alle disse netværkskald skaber risiko for dårlige svartider og for at vores infrastruktur overvældes. At sikre acceptabel ydelse og skalerbarhed er et must. Et andet og interessant problem med SOA, som betyder, at mange har vanskeligt ved at komme i gang med det, er at det faktisk er svært at finde ud af hvilke services man skal have. SOA projekter starter ofte i it-organisationen, og der vil være tendenser til at it-medarbejdere forsøger at definere tekniske infrastruktur-orienterede services, som skal erstatte funktioner, der afvikles inde i systemer, 4/August 2009 It-håndbogen 5

7 Succes med SOA f.eks. til fejlrapportering, inddatering, uddatering mv. Vi ved nu, at det sjældent er på denne måde at SOA får forretningsmæssig relevans i stedet skal SOA anvendes til at definere og implementere forretningsmæssige services, som repræsenterer forretningsaktiviteter og som kan anvendes til at bygge forretningsprocesser. Dette fordrer imidlertid et bedre samspil mellem IT og Forretning og en ny måde at udvikle krav på. SOA er altså på mange måder mere besværligt end den indarbejdede system-orienterede arkitektur, hovedsagelig fordi det repræsenterer en ny måde at arbejde med it på, og det fordrer ligeledes en vis form for reorganisering, nye incitamenter, opbygning af nye kompetencer, og en kultur som promoverer genbrug og standardisering. SOA modenhed kan måles Når nu der er mange strålende egenskaber ved SOA men samtidigt besværligheder forbundet med at komme i gang, er det kun rimeligt at spørge om der overhovedet er nogen der er kommet i gang med SOA. Til det formål kan vi se på et studie som IBM gennemfører hvert andet år af SOA modenheden i forskellige organisationer. De seneste datasæt har vi fra 2007 og For at opgøre hvordan og hvor langt virksomheder og organisationer er kommet med SOA anvender IBM sin SOA modenhedsmodel SIMM (SOA Integration Maturity Model), som er adopteret som industristandard af The Open Group, i form af The Open Group Service Integration Maturity Model (OSIMM). Ved at have en standard industrimodel for SOA modenhed, bliver det muligt for virksomheder og organisationer, at benchmarke sin SOA modenhed og samtidigt udvikle en roadmap for transformation fra et system-orienteret til service-orienteret paradigme som kan være nyttig i planlægningsøjemed. Modellen inddeler SOA modenhed i 7 niveauer: 1. Silo (data integration): Organisationen starter med en basis i proprietær og ad-hoc integration og arkitekturen er sårbar overfor ændringer 2. Integrated (applikationsintegration): Organisationen arbejder her med en form for EAI (Enterprise Application Integration), men anvender proprietære grænsesnit og integrationspunkter. Arkitekturen er domineret af egenudviklede og legacy systemer. 3. Komponentiseret (funktionel integration): På dette stadie komponentiserer og modulariserer organisationen 6 It-håndbogen 4/August 2009

8 Succes med SOA kritiske dele af sin applikationsportefølje, og eksponerer disse komponenter så de kan kaldes af andre komponenter 4. Simple services (procesintegration): Organisationen har udviklet simple services på et relativt finkornet niveau, som anvendes til at sammensætte nye forretningsprocesser på tværs af organisatoriske enheder. 5. Sammensatte (eng. composite ) services: Her er organisationen begyndt at arbejde med services, som er sammensat af andre services på et lavere abstraktionsniveau. Sammensatte services antager konturerne af funktionelle og komplekse applikationer, og begynder at erstatte anvendelsen af systemer som de basale byggeklodser. 6. Virtualiserede services (virtuel infrastruktur): På dette niveau har organisationen skabt en virtualiseret infrastruktur til afviklingen af simple og komplekse services. Applikationer, services og informationsflow er modulært adskilte. Principper om grid-computing og Cloud computing tager form, og services leveres af en allestedsværende infrastruktur, er tilgængelige overalt og SOA begynder at fungere som en utility. 7. Dynamisk rekonfigurerbare services (eco-system integration): På dette sidste niveau kan services sammensættes dynamisk, erstattes dynamisk, knyttes til hinanden på tværs af virksomhedsskel dynamisk osv. Den basale enhed i al udvikling af ny funktionalitet er dynamiske services, og nye sammensatte services kan dannes på basis af simplere services som sources fra forskellige organisationer eller konsortier. En helhedsanalyse af organisationers SOA modenhed ifht. SIMM blev gennemført i 2007 og viste følgende resultat: 4/August 2009 It-håndbogen 7

9 Succes med SOA Figur 1. De syv modenhedsniveauer for SOA ifht. modenhed (2007) Det går fremad, men langsomt Analysen viser at der finder en bevægelse sted i retnings af en service-orienteret it-arkitektur og at godt 12 % af alle organisationer i 2007 havde nået et sådant niveau i sin udvikling, mens godt 30 % havde modulariseret og formået at eksponere nogen forretningsfunktionalitet i komponentform, hvor komponenter har veldefinerede grænsesnit og regulerer deres opførsel gennem kontrakter. Den gennemsnitlige SIMM score var 2.31 i 2007, hvilket indikerede at de fleste organisationer befandt sig i et bevægelsesfelt mellem niveau 2 (integration) og niveau 3 (komponentisering). I 2009 blev samme studie gennemført og her viste der sig en gennemsnitlig SIMM score på Scoren indikerere at hovedparten af alle analyserede organisationer fortsat er i samme bevægelsesfelt som i 2007, men at flere har nået til et lettere forhøjet modenhedsniveau. De fleste organisationer er i 2009 fortsat på integrationsniveauet som det også var tilfældet i Dette kan tolkes som en indikation af, at SOA fortsat skal betragtes som leading edge for de fleste organisationer. Resultaterne for udviklingen i modenhed fra viser følgende billede: 8 It-håndbogen 4/August 2009

10 Succes med SOA Figur 2. Udviklingen i SOA modenhed Grafen viser, at der finder en langsom udvikling sted fra silo-opdeling, integration og komponentisering til fordel for service-orientering og sammensatte services. Når vi analyserer udviklingen i modenhed fra på de forskellige dimensioner i SIMM, ser vi ikke overraskende, at der har fundet en positiv udvikling sted, på næsten alle dimensioner af modellen, med en enkelt undtagelse. Den forretningsmæssige dimension, hvor organisationens modenhed på samspillet mellem IT og Forretning måles, har set en svagt negativ udvikling det vidner om, at SOA fortsat er et anliggende for it-organisationen, og at forretningsdelen af organisationen fortsat ikke har købt ind på SOA, som en samordnende metafor for samarbejde med it. Analysen viser desuden at de fleste organisationer befinder sig på niveau 1-3 i modenhedsmodellen mens SOA ofte sælges og promoveres på sine niveau 5-7 egenskaber. Dette indikerer en tydelig forskel på forventninger og realiteter ifht. hvad SOA kan levere på kortere sigt, som ikke er gunstig for den videre udbredelse af SOA, og kun tjener til at så skepsis omkring SOA s potentiale. 4/August 2009 It-håndbogen 9

11 Succes med SOA 4. Hvordan kommer man i gang med SOA? SOA kan startes op flere måder Start med et enkelt forretningsområde Det er naturligvis muligt at komme i gang med SOA på flere måder: lettest er det hvis SOA anvendes som den arkitekturelle stilart for udvikling af et nyt it-system. Her kan man simpelthen arbejde med SOA men stadig bibeholde den traditionelle projekt/system model, hvor man organiserer et projekt omkring leverancen af et system, og der anvender SOA som et af de toneangivende principper for design og konstruktion af et system. Alternativt kan SOA anvendes som en standard indenfor rammerne af et forretningsområde og der angive en retning for hvordan nye systemer udvikles. Ofte vil det være muligt at anlægge en sådan fælles standard indenfor et enkelt forretningsområde og der igennem sikre, at de systemer og/eller services som udvikles indenfor samme forretningsområde i det mindste kan tale med hinanden. En tredje mulighed er at anvende SOA som standard indenfor en samlet organisation, f.eks. bestående af flere mere eller mindre uafhængige forretningsområder. De forskellige forretningsområder kan have længersigtede fordele ved at anvende samme standard fordi det ruster organisationen ifht. fremtidige re-organiseringer og til f.eks. at levere integrerede produkter og services baseret på forretningsprocesser, som virker på tværs af forretningsområderne. Specielt denne procesorientering kan blive vanskelig hvis forretningsområderne anvender forskellige standarder for SOA, som betyder, at services og processer ikke kan kalde hinanden, eller kun vanskeligt kan gøre det. Som vi kan se bliver governance mere og mere betydningsfuldt i takt med, at virkefeltet for SOA udvides fra det enkelte projekt til det enkelte forretningsområde og endelig til den samlede organisation. De fleste organisationer starter med SOA ifht. et enkelt projekt eller et enkelt forretningsområde, mange i det håb, at det vil på sigt vil være muligt at nå til det tredje niveau hvor SOA er en helhedsdækkende standard som faciliterer organisatorisk ændring, produkt og serviceintegration og sammenhængende, tværgående processer. Det er imidlertid de færreste der træffer designvalg som er møntet på denne fremtidige situation. Her kan SIMM modellen være os behjælpelig modellen beskriver en niveaudeling af de stadier, som så godt som alle virksomheder og organisationer vil gennemgå på vejen mod 10 It-håndbogen 4/August 2009

12 Succes med SOA en dynamisk service-orienteret arkitektur. På denne måde definerer modellen en række pejlemærker for en naturlig udvikling, hvor hvert udviklingstrin er baseret på det foregående. 5. Hvordan får man succes med SOA? Fem gennemgående karakteristika IBM s Academy of Technology studie fra 2008 viste at succesfulde SOA implementeringer havde fem gennemgående karakteristika, som adskilte dem fra mindre succesfulde eller helt fejlslagne implementeringer: De var baseret på en arkitektur med en tydeliggjort vision for fremtiden, som muliggjorde at virkefeltet for SOA gradvist kunne udstrækkes fra det enkelte pilotprojekt til et eller flere forretningsområder, til den samlede organisation, eller ovenikøbet til et helt økosystem bestående af samarbejdende organisationer Der var et produktivt samarbejde mellem it-organisationen og forskellige afdelinger og organisationsområder ifht. definitionen af nye forretningsprocesser og services Der havde været et forudgående arbejde med at ændre både organisatoriske kompetencer, mentaliteter og kultur for at omstille organisationen fra en system-orienteret måde at udvikle sig på, til en service-orienteret måde at udvikle og genbruge services på Projekterne var baseret på en skalerbar infrastruktur, som ryddede evt. tekniske problemstillinger omkring svartider og skalerbarhed af vejen Der var en veludviklet operationel visibilitet, som gjorde det muligt at administrere services (finansiere dem, udvikle dem, anvende dem, afvikle dem mv.) på en omkostningseffektiv måde, og som sikrede deres vitalitet og derved deres konstante relevans for forretningen og dens processer De fem karakteristika var sammenhængende på den måde, at de alle influerede hinanden og var gensidigt understøttende: en fremtidsorienteret arkitekturvision er kun relevant og bidragende til succes når der eksisterer et produktivt samspil mellem IT og Forretning. Den kan kun leveres når den tekniske infrastruktur skalerer og leverer en acceptabel ydelse, når servicemængden kan administreres med acceptable omkostninger, og når udviklings- og projektkulturen er orienteret mod genbrug og standardisering. 4/August 2009 It-håndbogen 11

13 Succes med SOA På grund af denne sammenhæng kan vi illustrere de fem sammenhængende karakteristika som en stjernemodel for SOA succes: Figur 3. De fem karakteristika ved succesfulde SOA projekter 5.1. Fremtidsorienteret arkitekturvision Det at opfatte arkitektur som mere end bare en måde at sikre integration på er et gennemgribende behov på tværs af de ti områder. En kernearkitekturgruppe kan etableres for at sikre konsistens i de forskellige projekter og for at guide arkitekturens udvikling. Der er specielt fire områder som er specifikke ifht. arkitekturens udvikling: genbrug, data administration, sikkerhed og behovet for at kunne validere, at man går rigtigt frem. En af målsætningerne med SOA er at blive i stand til at kapitalisere på genbrug af arkitekturkomponenter og services. For at nå til en effektiv grad af genbrug, skal projekterne altså vurdere behovet for ny funktionalitet udfra et genbrugsperspektiv. Ideelt set skal genbrug af komponenter og services være prioriteret højere end individuelle og specifikke projektkrav. Dette fordrer ofte nye incitamenter for projekterne, som ligger udover at bare nå milepæle til den lavest mulige omkostning. Desuden kan det ikke antages, at eksisterende web services overholder standarder eller at det er nemt at sammensætte eller integrere dem. Implementering af sammensatte ser- 12 It-håndbogen 4/August 2009

14 Succes med SOA vices kan være en kompliceret affære, som kan involvere udvikling af transaktioner, fejlhåndtering, sikkerhedshåndtering og sammenstilling af forretningslogik. Hvis denne erkendelse ikke er på plads indledningsvis og deles af de involverede parter, vil genbrug sjældent føre til de forventede resultater. Genbrug er altså muligt, men ofte sværere end man forventer Organisation og kompetencer Mange af de lessons learned, som studiet hæftede sig ved, var organisatoriske af natur. Genbrug fordrer f.eks. at der er incitamenter som sikrer at projekterne vil prioritere genbrug både i deres produktion af nye services og i deres konsumption af eksisterende services. Hvis disse incitamenter ikke er på plads, vil genbrug blive underprioriteret til fordel for andre traditionelle performance indikatorer som tid og projektøkonomi med det resultat, at den kritiske masse af genbrugelige services og komponenter aldrig rigtig nås. Desuden åbner SOA muligheder for at integrere og genbruge services på tværs af både projekter og organisatoriske enheder, men kun hvis der er en form for enighed på tværs af organisatoriske enheder om at arbejde hen mod denne form for tværgående sammenhæng. I modsat fald vil det godt nok være muligt at kalde services, som er udviklet i et andet organisatorisk område, men services vil formentlig ikke anvende samme definitioner af data og derfor vil de ikke kunne integreres omkring en fælles opfattelse af verden. I et konkret eksempel havde et forsikringsselskab anvendt 3 måneder på diskutere hvad man skulle kalde en airbag, på tværs af sine skades- og bilforsikringsområder. Serviceintegration på tværs af forretningsområder og organisatoriske enheder bliver vigtigt, når der skal implementeres tværgående forretningsprocesser f.eks. i forhold til kundeservice, salg, ordremodtagelse, som sætter kunden i centrum for serviceleverancen. Når processerne er tværgående er det det samme som at forskellige forretningsområder deles om processerne, samtidigt med at de leverer forskellige aktiviteter til processernes udførelse. En simpel aktivitet som et kreditcheck kan deles af alle forretningsområder og aktiviteten kan anvendes i en forretningsproces som modtager kundeordrer (Order to Cash). Kreditchecket skal leveres til processen fra et sted i organisationen, for eksempel 4/August 2009 It-håndbogen 13

15 Succes med SOA fra det forretningsområde som først implementerede den med genbrug for øje. Det skaber en ny udfordring i og med at servicen skal vedligeholdes og videreudvikles og der skal betales for dens drift. Disse omkostninger kan afholdes ud af it-budgettet for det forretningsområde, som oprindeligt udviklede servicen, derfor ejer servicen og som leverer den til de forretningsprocesser, som konsumerer den. Men hvem ejer forretningsprocesserne, når de er defineret og implementeret på tværs af organisatoriske enheder, og hvem skal følgelig betale for at konsumere services? I svaret på dette spørgsmål gemmer sig en uddybning af forskellen mellem den traditionelle funktionelt opdelte eller produkt-orienterede organisation og den proces-orienterede organisation. I den funktionelt opdelte organisation tilstræbes en specialisering i produktionen af specielle ydelser og/ eller produkter. Indenfor hver af de funktionelle eller produkt-orienterede enheder, f.eks. skadesforsikring, helbredsforsikring og rejseforsikring, udføres forretningsaktiviteter for at producere og levere ydelser og produkter til markedet. I nogle tilfælde er de enkelte funktionelle eller produktenheder proces-orienterede internt og vælger derved at organisere sine forretningsaktiviteter i egne lokale processer. Når den samlede organisation vælger at implementere tværgående forretningsprocesser for at kunne levere sammenhængende ydelser og produkter til sine kunde,r kan en anden opdeling implementeres. Endelig er de teknologier, som anvendes f.eks. til procesmodellering, procesudførelse mv. nye, og der skal investeres i at forretningsanalytikere og it-folk forstår at modellere både services og processer på en måde som begge parter forstår og kan forholde sig til Produktivt samspil mellem it og forretning SOA og BPM giver mulighed for at modelere forretningsaktiviteter (som services) og forretningsprocesser, f.eks. ved anvendelse af et struktureret modelleringsværktøj og en struktureret metode som f.eks. SOMA. I princippet kan processer modeleres grafisk i et værktøj, og modellerne kan af værktøjet omsættes til BPMN (Business Process Modeling Notation). BPMN kan videre omsættes til BPEL (Business 14 It-håndbogen 4/August 2009

16 Succes med SOA Process Execution Language), som kan afvikles i en BPMserver. Flere og flere organisationer anvender en struktureret programmeringsmodel, f.eks. IBM WebSphere Business Modeler, til at modellere processer. Mange procesmodeller er imidlertid fejlbehæftede, og når de oversættes til eksekverbar kode, f.eks. i IBM WebSphere Process Server, opleves fejlsituationer, som udspringer af modellen Operationel visibilitet Den operationelle visibilitet er overordentlig væsentlig fordi mængden af ting, som vi nu skal til at finansiere, deles om, vedligeholde, videreudvikle, erstatte, eller nedlægge øges væsentligt i takt med at modenheden omkring SOA øges. Uden klart vedtagne spilleregler for denne form for SOA governance øges omkostningerne og den interne organisatoriske friktion i et sådant omfang, at SOA vil bære en omkostning som overstiger dens økonomiske og organisatoriske fordele. Organisationer, som havde demonstrerbar succes med SOA, udviste rettidig omhu og vedtog spilleregler for SOA governance på tværs af organisationen på et relativt tidligt tidspunkt, istedet for at konfrontere problemet når det havde vokset sig for uoverskueligt. I lighed med de karakteristika som knytter sig til arkitektur, hviler en del af SOA successen på evnen til at se fremad, træffe tidlige beslutninger og implementere principper og spilleregler, som muliggør snarere end bremser fortsat fremdrift Skalerbar infrastruktur Når der arbejdes med SOA er resultatet en højere grad af lagdeling og opdeling end hvad der almindeligvis er tilfældet. Denne lagdeling, f.eks. mellem processer og aktiviteter, og opdeling, f.eks. mellem services, som skal kunne tilgå hinanden, er netop fordelen ved SOA og BPM fordi den resulterer i muligheden for ændre processer og aktiviteter, uden at dette er særligt vanskeligt eller kompliceret eller medfører store ændringer i andre dele af arkitekturen end itlandskabet. Processer og aktiviteter er altså isolerede fra hinanden af arkitekturen. Imidlertid medfører denne isole- 4/August 2009 It-håndbogen 15