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. Prøv Ledelseshåndbogen i 10 dage for kun kr. 250,- Klik ind på: 6 It-håndbogen 4/August 2009