De weg naar succesvolle SOA-projecten

Vandaag heeft iedereen in de IT-sector de mond vol over service georiënteerde architecturen (SOA). Hoewel iedereen het eens is over de theoretische meerwaarde ervan, staan heel wat IT-managers nog sceptisch tegenover de service georiënteerde benadering. En niet zonder reden, want achter SOA-projecten schuilen tal van valkuilen. Wij zetten even op een rijtje hoe u de weg effent naar een succesvol SOA-project.

Meer dan ooit beseft iedereen dat de strenge eisen die gesteld worden aan ICT-oplossingen een aangepaste benadering vragen. De waarde van een organisatie wordt in grote mate bepaald door de snelheid waarmee ze accurate en up-to-date informatie ter beschikking kan stellen. Een ver doorgedreven automatisering van de businessprocessen, zelfs over de muren van de organisatie heen, is een dagelijkse realiteit. Een moderne softwaretoepassing is geen ‘eiland van automatisering’, maar vormt een tussenstation in een groot netwerk van toepassingen. Deze trend heeft specifieke uitdagingen geïntroduceerd in software engineering en een grote impact gehad op de manier waarop bedrijfstoepassingen gebouwd worden.

SOA
We kunnen dus stellen dat SOA onafwendbaar de nieuwste stap voorwaarts is. Zoals steeds het geval met innovatieve technologieën, is er ook wat SOA betreft een zekere terughoudendheid merkbaar bij IT managers. Het aantal effectieve SOA-realisaties in België ligt vandaag zeer laag. Bedrijven overtuigen te kiezen voor een SOA-project blijkt dus nog een grote uitdaging.

VANWAAR HET SCEPTICISME?
De oorzaak is te vinden in de complexiteit van SOA-projecten. Een SOA steunt op technologische innovaties. Zo is webservicetechnologie van meet af aan een van de belangrijkste peilers geweest van service georiënteerde architecturen. Open standaarden en ondersteunende technologieën (Soap, Rest, SCA, WS-*) maken het mogelijk om op een veilige, betrouwbare manier informatie uit te wisselen via onveilige netwerken zoals het internet.

Achter al deze technologische innovaties gaat echter een grotere, meer organisatorische complexiteit schuil. Het mislukken van een SOA-project is zelden te wijten aan een gebrek aan technologische mogelijkheden, maar eerder aan de nieuwe onvoorziene uitdagingen waarmee project managers plots geconfronteerd worden.

IT’S A WAY OF LIFE…
Een eerste valkuil voor SOA-projecten is een onderschatting van de impact die dergelijke projecten hebben op een organisatie. SOA is een visie op de manier waarop systemen gebouwd moeten worden om enkele specifieke kwaliteiten mogelijk te maken: interoperabiliteit tussen technologieën, losgekoppelde services, betrouwbaarheid, beheersbaarheid enzovoort. Beschouw SOA dus gerust als het volgende software-engineeringparadigma. Net zoals objectoriëntatie begin jaren ’90, zal ook SOA een grote impact hebben op de manier waarop toepassingen in de toekomst ontworpen en ontwikkeld zullen worden.

Alvorens een SOA-project op te starten, moet de organisatie in kwestie eerst werk maken van de noodzakelijke paradigm shift. De organisatie moet SOA leven en ademen, zodat er sprake is van een Service Georiënteerde Organisatie (SOO). De rol van het management is hierin cruciaal. Zij moeten een klimaat creëren, zowel politiek als cultureel, voor een geleidelijke overgang naar de SOO. Het gebrek aan een dergelijke overkoepelende visie van SOA heeft spijtig genoeg al te vaak geresulteerd in dure mislukkingen. Volgende oorzaken liggen meestal aan de basis van mislukte SOA-projecten:

– Wantrouwen of een gebrekkige samenwerking tussen de Teams
– Onvoldoende opleiding en begeleiding van de teams
– Tegengestelde belangen, politiek
– Slechte design skills voor de ontwikkeling van services
– Gebrek aan metrieken om een goede opvolging te garanderen
– Gebrek aan een SOA governance-infrastructuur

De realisatie van een service georiënteerde architectuur moet kaderen in een bewuste strategie van de organisatie. Change management met het oog op de realisatie van een SOO is cruciaal en moet de klemtoon leggen op de diverse culturele en educatieve uitdagingen.

DE VENDORVALKUIL
Een andere belangrijke misvatting is het feit dat SOA iets is wat je kan kopen of installeren. SOA is iets wat je doet, niet iets wat je koopt! Hoewel ze dit soms laten uitschijnen, is er vandaag geen enkele constructeur die alle facetten van service georiënteerde architectuur met één tool afdekt. Wat niet wil zeggen dat tools overbodig zijn, integendeel. Een belangrijk criterium voor geslaagde SOA-projecten is de flexibiliteit om de juiste tool op de juiste plaats te selecteren, zodat maatwerk afgeleverd wordt.

Vendor lock-ins (waarbij de IT-infrastructuur van een bedrijf grotendeels geënt is op de producten van één leverancier, zodat aankopen van een concurrent uitgesloten worden) vormen om twee aantoonbare redenen een bedreiging voor SOA-projecten. Ten eerste omdat een service georiënteerde architectuur van nature uit verschillende technologieën van meerdere leveranciers gebruikt. U kan zich dan terecht de vraag stellen of een service georiënteerde architectuur in een omgeving van een enkele producent niet haaks staat op één van de belangrijkste fundamenten van SOA en bijgevolg schadelijk is voor resultaten van de SOA-inspanningen op lange termijn. Binnen de grenzen van de eigen organisatie blijft dit over het algemeen nog onder controle. Vaak worden de beperkingen van het single-vendor platform pas echt merkbaar wanneer integratie met externe partners nodig is.

Daarnaast ondersteunen de tools vaak de visie van de constructeur op SOA. Die visie is soms moeilijk te verzoenen met de specifi eke context van de organisatie waarbinnen de tool gebruikt zal worden. Wetende dat SOA maatwerk is, is het noodzakelijk de fl exibiliteit te behouden om buiten het kader te denken dat aangereikt wordt door de vendor.

SOA MET MATE
Services vormen de kern van een service georiënteerde architectuur. Zij automatiseren één of meerdere stappen in een businessproces en bieden deze functionaliteit aan via een duidelijk omschreven interface. Services ontstaan niet in het ijle, maar worden expliciet ontworpen om zo breed mogelijk herbruikbaar te zijn en zodoende de schaalvoordelen ervan te maximaliseren. Niet alleen de toegenomen complexiteit bij de bouw van services moet in rekening worden gebracht, maar ook het beheer van services in productie: life cycle management, version management, SLA monitoring enzovoort.

De uitbouw van een SOA vergt meer investeringen dan u op het eerste zicht zou vermoeden. Om deze meerkost te beheersen, moet de creatie van elke nieuwe service kritisch worden afgewogen tegen de doelstellingen van de architectuur. SOA is geen doel op zich. Niet alles moet een service zijn, enkel herbruikbare functionaliteit.

NOOD AAN GOVERNANCE-INFRASTRUCTUUR
Een huishouden waar geen afspraken bestaan of waar gemaakte afspraken niet worden nagekomen, zal na verloop van tijd resulteren in chaos. Zo zal ook een SOA-infrastructuur die niet beheerd wordt, op termijn veranderen in een niet te onderhouden kluwen van interagerende services. Om te vermijden dat u in dergelijke situatie terecht komt, heeft u nood aan beheerprocessen. Een SOA governance-infrastructuur verzamelt alle tools die nodig zijn om services op een correcte manier te ontwikkelen, publiceren en consumeren.

Dergelijke infrastructuur stuurt mensen, processen en beleid met één doel voor ogen: de nodige mechanismen inbouwen om op lange termijn te evolueren naar een echte service georiënteerde organisatie.

De adoptie van SOA in een organisatie betekent de introductie van een nieuwe cultuur. Die nieuwe cultuur zal pas worden aanvaard als ze gedragen wordt door de mensen die in de organisatie actief zijn. Dit is het doel van governance. SOA governance wil mensen ondersteunen zodat ze ‘de juiste dingen doen’. Een goed beheer van een SOA-infrastructuur omvat minimaal volgende componenten:

– Beheer van service m
eta-informatie: hergebruik van services stimuleren door ze te publiceren in een centrale repository Beheer van policies: een goed beleid bakent de grenzen af van de service georiënteerde architectuur. Policies bevatten regels voor ontwikkeling van services (codeerconventies, standaarden), alsook runtime-specificaties voor services (SLA’s)
– Beheer van processen: aan het gebruik van services gaat een onderhandeling tussen dienstverlener en gebruiker van de service vooraf over de gebruiksvoorwaarden van de service. De gebruiksvoorwaarden worden fi naal vastgelegd in een contract.
– Testing en Diagnostics: het testen en opvolgen van services moet garanderen dat ze zich op een betrouwbare manier gedragen in een productieomgeving.

Nog al te vaak wordt governance in SOA-projecten stiefmoederlijk behandeld. De afwezigheid ervan vormt echter een reële bedreiging voor de beheersbaarheid van de architectuur op langere termijn.

Project managers moeten beseffen dat het welslagen van een SOA-project in mindere mate bepaald wordt door de keuze van de technologie of de keuze van een product. Laat u zeker het hoofd niet op hol brengen door de technische staf of door gladde constructeurs. Leg echter de nadruk op het verwerven van de steun van het strategisch management. Hun steun is cruciaal om een cultuur te creëren die nodig is om finaal de stap naar de service georiënteerde organisatie te zetten.

Bob Van Rompuy is Group Manager van het Java Competence Center bij Dolmen / JCS. Zijn specialisatie domein is architectuur in de brede zin, met een belangrijke focus op SOA.