Houd opzet webservices in eigen hand

Weinig bedrijven maken een goed ontwerp voordat zij met service oriented architecture aan de slag gaan. Leveranciers duwen hun eigen systeem naar voren. Eindgebruikers doen er goed aan toch eigen expertise op te bouwen.

Hergebruik is het sleutelwoord bij het opzetten van een architectuur voor web services.” Dat zegt Mike Papazoglou. Hij is hoogleraar Computerwetenschappen aan de Universiteit van Tilburg en heeft het afgelopen jaar twee boeken geschreven over web services en e-business. “Daarvoor moeten organisaties hun business-domeinen, bijvoorbeeld manufacturing en HR, analyseren, op zoek naar de bedrijfsprocessen”, legt hij uit. “Vervolgens moeten ze onderzoeken hoe ze hun resources daar zo goed mogelijk bij in kunnen zetten. Er is immers al een heleboel. Je wilt zoveel mogelijk van de bestaande data en functionaliteit opnieuw gebruiken.”

Top-down

Het model dat Papazoglou gebruikt, begint als een top-down decompositie op logisch niveau. Eerst wordt de organisatie opgedeeld in business-domeinen. Denk daarbij bijvoorbeeld aan inkoop, ordermanagement en voorraadbeheer. Deze domeinen bestaan elk weer uit allerlei bedrijfsprocessen. Die gebruiken op hun beurt weer de daaronder liggende business services.

De analyse op dit niveau is volgens Papazoglou niet zo ingewikkeld. “Er zijn al referentiemodellen voor bedrijfstakken als de telecom of de fabricage van elektronica beschikbaar. Dat gaat om bekende businessmodellen en bedrijfsprocessen. Als je in de telecom zit, dan weet je de modellen voor je eigen sector wel te vinden.”

Papazoglou waarschuwt wel dat het op dit niveau absoluut nog niet om software of softwarecomponenten gaat. “De workflows worden vertaald naar business services. Denk dan aan ordermanagement, wijzigingen, planning, bulkorders, het monitoren van de voortgang en dergelijke.” Op die manier worden business services en functies via de businesslogica met elkaar verbonden tot bedrijfsprocessen.

“Op dit niveau vindt ook de integratie met andere organisaties plaats. Ze moeten elkaar kunnen verstaan. Daarvoor moeten ze op zoek naar terminologie die beide organisaties gemeenschappelijk hebben. Daarom gebruiken ze dezelfde voor hun industrie specifieke modellen.” Volgens Papazoglou is dat ook de reden dat de algemene ebXML-standaard mislukt is. “Ze hebben deze nooit compleet kunnen krijgen. De problemen bleken per industrietak heel verschillend te zijn.”

Bottom-up

Tegelijkertijd worden van onderaf, op fysiek niveau, de bestaande systemen samengepakt tot servicecomponenten. Het gaat dan bijvoorbeeld om SAP-systemen, crm-toepassingen en databases. Maar ook om legacy-servers gebaseerd op Cobol en CICS. “Die oude systemen komen veel voor. Je kunt ze er ook niet uitgooien. Ze vormen vaak de ruggengraat van de bestaande processen en moeten daarom ook weer onderdeel worden van de nieuwe omgeving.”

Op deze manier worden zakelijke processen en behoeften enerzijds, en resources en infrastructuren anderzijds, bij elkaar gebracht op het niveau van web services. Juist op dat middelste niveau, op het snijvlak van opdeling en opbouw, zit de complexiteit. Daar moet duidelijk worden welke services nodig zijn, welke beschikbaar zijn of kunnen worden samengesteld, en welke nog ontwikkeld moeten worden.

“Er moet een passing worden gemaakt van de business services op de onderliggende infrastructuur”, legt Papazoglou uit. “Waar is een bepaalde service te vinden in de bestaande resources. Kun je een ontbrekende service samenstellen? Lukt dat ook niet, dan zul je ‘m moeten maken.”

Match

“In die match van business services op de onderliggende resources zitten zowel de complexiteit als de kosten”, zegt Papazoglou. “Je hebt van tevoren immers geen garantie dat een resource die je voor een bepaalde business service nodig hebt, er ook daadwerkelijk is. Bovendien bevinden zich op dit niveau ook de transformatie-tools waarmee je bijvoorbeeld CICS aan SAP of PeopleSoft kunt knopen. Datzelfde geldt voor de message broker die zorgt voor de load balancing, de routering en de verwerking van transacties. Bovendien zul je ook alle bestaande resources van een wrapper voor web services moeten voorzien.”

Uit dit verhaal wordt ook duidelijk waarom een monolithische aanpak, zoals die bijvoorbeeld door Oracle en SAP wordt gepropageerd, niet werkt. “Je moet de onderliggende techniek aanpassen op de zakelijke behoeften, en daarbij zoveel mogelijk van de bestaande resources opnieuw gebruiken. Je zult dus in ieder geval moeten programmeren.” Daarmee kom je als vanzelf op een best-of-breed-aanpak uit.

Complexiteit

Volgens Papazoglou zijn er al standaardmethoden beschikbaar om die passing tussen business services en resources voor elkaar te krijgen. “Er zijn daarbij drie belangrijke principes waar je naar moet kijken. De eerste twee zijn koppeling en cohesie. De eerste moet laag zijn, de tweede hoog. Dat betekent dat je bij de compositie de services die conceptueel bij elkaar horen ook in hetzelfde businessproces bij elkaar moet zetten.

“Door op deze manier sterk cohesieve processen te bouwen, houd je je ontwerp simpel en krijg je goed van elkaar losgekoppelde functies. Bovendien minimaliseer je zo ook de onderlinge afhankelijkheden. Als je iets moet veranderen, doe je dat immers het liefst op één plek. Je wilt niet dat veranderingen zich verspreiden over het hele systeem; die wil je lokaal houden.”

“Het derde principe is dat van de fijnmazigheid,” vervolgt Papazoglou. “Binnen elke laag wil je services van ongeveer dezelfde grootte hebben. Op die manier kun je het aantal functieaanroepen beperkt houden en heb je niet te veel boodschappen om rond te sturen.” Dat is immers de belangrijkste reden om deze complete hiërarchie met al die lagen op te zetten. Je probeert de businessdomeinen op het hoogste niveau en de technologie op het laagste niveau bij elkaar te brengen op een stapsgewijze manier die de complexiteit binnen de perken houdt.

Geen snelle oplossingen

“Hoewel veel leveranciers zeggen die wel te kunnen leveren, zijn er geen snelle oplossingen voor deze problematiek”, aldus Papazoglou. Sterker nog, volgens hem zijn zij juist schuldig aan de gebrekkige manier waarop gebruikers nu tewerkgaan. “Er zijn in Europa maar heel weinig bedrijven die een goed ontwerp maken voordat zij met service oriented architectures (soa’s) aan de slag gaan. Dat komt door de leveranciers. Zo’n bedrijf roept dat je gewoon hun erp-systeem moet aanschaffen en dat alle problemen zich dan vanzelf zullen oplossen. Dat zie je vaker nu leveranciers steeds meer consultancy willen verkopen. Daarom moet je vooral zelf expertise opbouwen. Leveranciers willen een partnership met hun klanten. Dat maakt je echter kwetsbaar. Als hij je laat zitten, dan ben jij je markt kwijt. Houd daarom altijd zelf de controle. Als je toch gaat outsourcen, zorg dan zelf voor een goede governance, om hun governance te kunnen controleren.”

“Bedrijven moeten zich goed voorbereiden op deze enorme klus,” waarschuwt Papazoglou. “Ad hoc integratie is straks een basisbehoefte van de business. In de toekomst moet dat daarom veel gemakkelijker zijn. Change management is daarmee niet langer een proces, maar een uitgangspunt bij het opzetten van zaken. Verandering moet een onderdeel van de architectuur zijn, een manier van werken.”

Governance

It governance wordt daarmee nog belangrijker dan het nu al was. “Wie is de eigenaar van deze problemen? Koppelingen tussen verschillende organisaties bijvoorbeeld vinden op businessniveau plaats. Daar wordt besloten welke diensten worden aangeboden en afgenomen en wat de kwaliteit daarvan moet zijn. Tegelijkertijd heeft dat gevolgen voor de niveaus daaronder. Een bepaalde service level agreement (sla) stelt immers eisen aan de quality of service (qos) van de onderliggende infrastructuur. En dat heeft weer gevolgen voor de load balancing op it-niveau. De business analist en de it’er moeten dat samen oplossen.”

Papazoglou vindt dat organisaties daarvoor een balans zullen moeten vinden tussen centrale en decentrale aansturing. Hij pleit voor een ‘federated’ benadering. “Een sterk hiërarchische aanpak werkt niet. Je kunt dat beter per divisie inrichten en zorgen dat over die divisies heen expertise wordt uitgewisseld. Tegelijkertijd moet je wel iemand op centraal niveau hebben om de boel aan te sturen.” Volgens hem is er juist over dit onderwerp nu veel discussie. “Er wordt op dit moment heel veel gepubliceerd; de academici zijn er nog niet uit.”