Met het Computable-seminar over een service oriented architecture (SOA) heeft dit begrip een gezicht gekregen en is het los gekomen van de talloze teksten die bezoekers er al over hadden gelezen. Soa leeft, zo was de conclusie van velen na afloop.
Op 21 september stroomde ‘t Spant in Bussum vol. Jong en oud, grijs gestreept en t-shirt, allen zeer geïnteresseerd in het onderwerp van de dag: soa. Afgaand op de opkomst van het seminar is het wel duidelijk dat dit onderwerp leeft. En niet alleen bij de mensen die er in de dagelijkse praktijk handen en voeten aan moeten geven, maar ook bij diegenen die er in strategische zin een besluit over dienen te nemen, zeg maar: de it-managers.
“Toch”, zo viel uit de mond van bezoekers na afloop op te tekenen, “hadden we graag ook een business manager op het toneel gezien. Mark van der Kraan, application architect bij de Friesland Bank, mag dan wel zeggen dat de missie is geslaagd, we hadden graag gezien dat iemand van de ‘business’ ernaast stond om hetzelfde te zeggen.” Een sceptische houding die wellicht de onzekere houding van it’ers maskeert. Het valt immers niet mee om een soa gestalte te geven en het is ook niet eenvoudig te achterhalen waaraan de business behoefte heeft en daar technisch invulling aan te geven. Tot slot is het moeilijk te luisteren naar de eisen/wensen van de ‘business’ en maar al te vaak weet die zijn wensen ook niet helder te formuleren.
Verantwoordelijkheden
De ochtend begon met een lezing van Alfred den Besten van onderzoeksbureau MarketCap. De inhoud van zijn bijdrage is al uitvoerig beschreven in Computable van 15 september jongstleden (pagina 19). Slechts een uiterst beperkt aantal Nederlandse organisaties heeft soa toegepast, veel meer bedrijven zijn op bescheiden schaal bezig experimenten uit te voeren. Dit werd ook duidelijk bij de voorbereiding van dit seminar. Het viel niet mee om iemand te vinden die op het toneel met een PowerPoint-presentatie in de rug wil vertellen waarom hij een dergelijke architectuur heeft ingevoerd en hoe dat is verlopen. Die bevindingen stroken met de MarketCap-studie.
Toch zegt Van der Kraan – hoewel hij repte van een ‘ontdekkingsreis’ – een geslaagde missie achter de rug te hebben. Vooral dankzij de implementatie van een enterprise service bus waardoor applicaties ineens in staat zijn een fuga ten gehore te brengen. Aangespoord door het publiek gaf hij aan wat ‘services’ dan wel zijn. Het aanbieden van klantgegevens, en het controleproces rond een hypotheekaanvraag (kredietwaardigheid, identiteitscontrole, en dergelijke) bracht hij naar voren als voorbeelden uit zijn dagelijkse praktijk.
Bert Bastenhof, it-architect bij de Rabobank, hield zijn gehoor voor dat het een lange adem vergt om een soa-model te implementeren. Nu heeft hij wat dat betreft makkelijk praten, want de Rabo is al sinds 1999 bezig een dergelijke architectuur in te richten; ruim voordat het woord soa zijn intrede deed. Zijn grootste uitdaging: duidelijk krijgen in welke behoefte de it-afdeling dient te voorzien. “Iedereen verstaat iets anders onder een service.”
Bastenhof vindt het belangrijk dat de verantwoordelijkheden duidelijk zijn. Iemand dient zijn handtekening te zetten onder een bepaalde service. Het kan immers best zo zijn dat op technologisch gebied alle metertjes groen uitslaan en de service toch niet wordt geleverd. Wie is er dan verantwoordelijk?
Arno Teigelen, manager Ontwikkeling en Beheer van Quion, had eerder die dag uitgelegd dat het (it-)denken vanuit services het werk zoveel makkelijker maakt, terwijl tegelijkertijd de technologische uitdagingen toenemen. Je zou dit de soa-paradox kunnen noemen.
De afsluiting nam Jan Vegt van het consultancybureau 42 voor zijn rekening. Hij verwees naar de standaardencommissie Oasis om een (vrij technische) definitie van een soa te bemachtigen. En was duidelijk in zijn stelling dat een service niet gelijk is aan een webservice. “Je gaat geen Cobol-applicatie bij het huisvuil zetten.”
