Volgens Computable’s soa-expertpanel is het implementeren van een service oriented architecture niet altijd een goed idee. Bedrijven moeten eerst hun zakelijke en ict-processen op orde hebben. Een andere complicerende factor is de onvolwassenheid van de soa-technologie. Deze kritische geluiden waren te horen op Computable’s soa-seminar op 27 maart in Amsterdam.
Art Ligthart, partner bij Ordina was duidelijk tijdens de paneldiscussie op Computable’s soa-seminar: "Sommige organisaties moeten nog niet aan soa beginnen. Die moeten eerst hun processen en verantwoordelijkheden op orde krijgen. De belangrijkste succesfactor voor een soa is dat zowel je ict- als je businessorganisatie volwassen is." Als aan deze voorwaarde is voldaan kan een soa volgens Ligthart complexe problemen oplossen: "Een soa gebruik je juist niet voor eenvoudige kwesties. Juist als je spaghetti wilt ontrafelen, heeft het zin om dat met een soa te doen." Peter Valkenburg, CTO bij Everett voegde hier nog aan toe dat een soa vooral meerwaarde heeft als je als organisatie ‘domeinoverschrijdende diensten wilt leveren’.
Hergebruik
Hergebruik van web services, dat algemeen als het belangrijkste voordeel van soa’s wordt gezien, is volgens Valkenburg helaas niet altijd mogelijk: "In veel gevallen moet een service herschreven worden voor een volgend project. Maar er zijn ook gebieden waar hergebruik altijd werkt. Dat geldt bijvoorbeeld voor identificatie en authenticatie."
Testomgeving ontbreekt
Wout Hofman, senior consultant bij TNO ICT/E-IT benadrukte tijdens de paneldiscussie dat de soa-technologie nog niet volwassen is: "In de huidige standaarden ontbreken vaak nog afspraken op semantisch niveau. Ook de tools kunnen onderling nog niet goed communiceren."
Die onvolwassenheid komt onder andere tot uiting in het ontbreken van een goede testomgeving voor soa’s. Theo Maas, één van de hoofdarchitecten bij KLM, ging in zijn presentatie dieper op dit probleem in: "Een service onthoudt zijn context niet, terwijl je wel wilt weten waar in de keten de oorzaak van een fout ligt. Wij ontwikkelen nu zelf logging en monitoring faciliteiten. De industrie heeft daar wel standaarden voor gedefinieerd, maar levert nog niet de middelen."
Serieus probleem
Een vraag uit de zaal verduidelijkte de ernst van het testprobleem: "Als een soa succesvol is en je hebt twintig applicaties die gebruik maken van één service en je past die service aan, hoe test je dat dan? Hoe vind je de bug? Everett-CTO Valkenburg bevestigde deze analyse: "Dat is inderdaad een serieus probleem. Het is al genoeg complex om één applicatie door een OTAP-straat te krijgen. Het enige wat je kunt doen is je beheerorganisatie heropvoeden, zodat ze bijvoorbeeld kleinere brokken testen." Mark Vroom, technisch directeur bij Nedfox: "De backwards compabiliteit van services is van cruciaal belang. Als de leverancier waarmee je in zee gaat dat niet op orde heeft, kun je problemen verwachten."
Oproep aan de industrie
Ook op andere vlakken laat de industrie steken vallen. Zo verwacht KLM-architect Maas dat het gebruik van mashups ‘gaat exploderen in het komende jaar’. Standaarden en tools zijn er echter nog niet op dit gebied. Mashups zijn webpagina’s waarbinnen gegevens uit verschillende websites gecombineerd worden. Een voorbeeld is een webpagina die zowel een Googlekaart laat zien als boekingsinformatie afkomstig van een hotelwebsite. Maas: "Onze vraag aan de industrie is: kom met standaarden en tools."
Hoe krijg je toeleveranciers aan de soa?
Een andere vraag uit de zaal ging over samenwerking met toeleveranciers binnen een soa. Een ict manager binnen een technische groothandel: "Wij hebben heel verschillende leveranciers. De één heeft alles nog op papier staan, de ander heeft een full scale webapplicatie. Wat doe je als leveranciers niet aan een soa willen? Als ze er geen markt in zien?"
Het nationale knooppunt en kenniscentrum voor ict en innovatie in de zorg (Nictiz) ondersteunt om die reden leveranciers van legacy-systemen, niet alleen door het geven van cursussen, maar ook via de oprichting van een technisch platform dat concrete ondersteuning biedt tijdens de implementatiefase. Dat vertelde Albert Vlug, manager ‘ontwerp en onderhoud’ van de architectuur voor de zorg bij Nictiz in zijn presentatie. Marc Buiks, programmamanager digitalisering bij de gemeente Waalwijk heeft een heel andere benadering. Hij adviseert om knockout criteria te definiëren voor nieuwe applicaties. "Als de nieuwe applicatie daaraan niet voldoet, komt hij niet in aanmerking."
| Wat is een soa? Een Service Oriented Architectuur (soa) is een methode om onderdelen van verouderde bedrijfssystemen flexibel beschikbaar te stellen voor interne en externe medewerkers via een netwerk of het internet. De ruggengraat van een soa bestaat uit een Enterprise Service Bus (ESB) die informatie doorsluist vanuit de onderliggende systemen. Die informatie komt beschikbaar in de vorm van web services, die de bouwblokken vormen voor samengestelde applicaties. De kunst is om je web services zo te kiezen dat ze gemakkelijk herbruikbaar zijn binnen steeds nieuwe samengestelde applicaties. |
Dit artikel duidt voor mij aan dat SOA een hype is zoals vroeger reeds het geval was met met andere aanpakken. Er worden heel veel beloftes gedaan maar uiteindelijk blijken de beloften slechts wensen te zijn en worden de verwachtingen langzaam maar zeker ontgoochelingen.
Dat er toepassingen zijn waarbinnen SOA tot zijn recht zal komen, daar moet men niet aan twijfelen. Maar of SOA nu echt de zilveren kogel is die de weerwolf van de complexiteit van softwareontwikkeling zal doden?
Ik ben het ook volledig eens met de stellingname dat heterogene implementaties zeer moeilijk te testen zijn. SOA is een saus die de heterogeniteit verbergt maar, om de analogie verder te zetten, eens de spaghetti koud is wordt het 1 grote klomp en daar is geen ontwarren meer aan.
De architectuur bepaalt het kostenplaatje en SOA is een amalgaam waarmee de slechte kiezen van de architectuur moeten worden gerepareerd. Een kunstgebit om je oude gebit te vervangen is duurder, maar op lange termijn misschien toch de betere investering.
Er is ook nooit belooft dat SOA de silver bullet zou zijn.
SOA is een goed concept dat in bepaalde situaties voor een goede oplossing kan zorgen, maat het is geenszins bedoelt om overal toegepast te worden naar mijn mening. Net zoals dat voor vele anders hypes het geval is.
Ik vermoed dat SOA geen hype is en vergelijk dit met het internet in de jaren 90 (het delen van data). Voor dat je het weet gaat alles in een grote stroomversnelling. Bedrijven die in ieder geval een aanzet nemen in het denken en handelen in services (of interfaces zoals tijdens de seminar vermeld is) zullen het gemakkelijker krijgen wanneer SOA wel een rol gaat spelen. Dat de ICT en business processen “mature” moeten zijn is wel een vereiste, maar men kan dit wel doen met SOA in de gedachten. Wat het testen van SOA omgevingen betreft, er zijn wel ontwikkelingen die vruchten afwerpen in het buitenland en nog niet in Nederland bekend zijn. Dit kan dreigend zijn voor bedrijven die buiten de grenzen zaken doen omdat die niet direct kunnen participeren in SOA omgevingen met efficiente snelle services. Vooral op het gebied van Java en .Net omgevingen zijn hier groet vooruitgangen geboekt zoals o.a. dynaTrace dit doet.
Het testen van SOA omgevingen is veel meer dan alleen goede tools inzetten. De tools zijn het probleem niet hier, een keten test opzetten over 10 of 20 verschillende systemen, diverse middle ware lagen en integratie technologie?n is technisch met de juiste tools prima te doen (kijk bijvoorbeeld bij http://www.itko.com). Voor het probleem van de beschikbaarheid van testomgevingen zijn ook wel technische oplossingen te vinden (met name in de vorm van virtualisatie en simulatie). Het blijft echter zeer complexe materie, waarbij vooral de organisatorische aspecten niet onderschat moeten worden.
Het alternatief is echter niet (of niet voldoende) testen. Het blijft vreemd dat het feit dat een ketentest ingewikkeld is de reden is om er dan maar vanaf te zien…
Organisaties merken steeds vaker dat een niet geteste SOA architectuur een stuk minder betrouwbaar is dan ze gehoopt hadden.
SOA is ook een manier van denken en ordenen, structureren. Als je die hebt pas je dat toe vanaf de bedrijfsprocessen, en kun je op iedere schaal beginnen in je organisatie die je maar wilt. Dan zul je opeens zien dat je bedrijfsprocessen veel transparanter worden, zie je duidelijk de relatie tussen wel en niet met ICT te enablen processen, en bouw je de services voor de te enablen processen. TNO-ICT heeft al een onderzoek gedaan naar deze methode. Resultaten zijn beschikbaar.
Bij het testen van applicaties die ontwikkeld zijn met behulp van SOA gaat het niet zo zeer om de functionaliteit maar meer om de ondersteuning van de procesgang.
Het is de immers voor de business van belang dat zij na een update gewoon door kunnen werken zoals zij vroeger ook deden. Tooling kan daar bij helpen maar is niet van levensbelang veel meer van belang zijn de non-functionele aspecten van een service (beschikbaarheid, functionaliteit, perofmance en betrouwbaarheid). Bij het uit brengen van een nieuwe versie van een service zul je dus alle processen dienen te regressietesten die door de serivce worden ondersteund.
Als testconsultant bij Sogeti heb ik ruime ervaring met het testen in SOA-projecten.
Een SOA heeft een aantal kenmerken die een andere benadering van testen nodig maken.
Een belangrijke verandering in de testaanpak is dat je niet meer een applicatie test via een user interface maar dat je elke individuele service gaat testen. Hiervoor gebruik je een testharnas dat inmiddels door verschillende testtoolleveranciers wordt geleverd. Met een testharnas kun je functionaliteit, interface standaarden en performance van 1 service geautomatiseerd testen.
Als je weet dat de individuele services volgens specificatie gebouwd zijn wordt het makkelijker zoeken naar fouten als deze services in een ketentestomgeving geplaatst worden.
Mijn ervaring is dat ook in de ketentest niet zozeer de tooling een probleem is als wel het gebrek aan goede en volledige ketenkennis en ketenspecificaties.
De ketentestomgeving voor SOA wordt steeds complexer. Steeds meer bedrijven hebben moeite om een productie identieke keten in een ketentestomgeving te realiseren. Daarnaast stellen externe service providers hun testomgevingen beperkt beschikbaar. Het lijkt dus onvermijdelijk dat alleen deelketens getest en geaccepteerd kunnen worden. Ook zullen meerdere SOA-projecten binnen een bedrijf het moeten doen met een acceptatietestomgeving. Het is te duur en niet te organiseren om elk project een eigen acceptatietestomgeving te geven. Het aanstellen van een Test Infrastructuur Co?rdinator is een oplossing om de organisatorische complexiteit van SOA testomgevingen in goede banen te leiden.