'We zijn met service-oriented architecture (soa) in een fase gekomen dat er weinig geheimen meer zijn over het toepassen ervan bij het ontwikkelen van applicaties en oplossingen. Het is echter een valkuil om niet verder te denken dan dit ontwikkelproces', waarschuwt een van de experts van het Computable-topic SOA. Computable vroeg de experts om hun belangrijkste advies.
In de ICT Services Guide 2009 staat per topic een selectie van de belangrijkste expertadviezen. Ook worden per topic rapportcijfers gegeven voor dienstverleners die actief zijn in dat ict-deelgebied. Hiervoor liet Computable onderzoek verrichten onder bijna tweeduizend ict-managers en ambitieuze ict-professionals. Ook werden de respondenten algemene vragen en stellingen voorgelegd. Het onderzoek werd verricht door TNS Nipo.
Ga service-georiënteerd denken
De A van soa is van Architectuur en soa is daarom eerst en vooral een manier om tegen de dingen aan te kijken. Ik zie nog te vaak dat vanuit de vertrouwde oplossingsrichtingen met soa wordt gestart. Het resultaat is er vrijwel altijd een van teleurstelling. Aan de, vaak hooggespannen, verwachtingen van de business wordt niet voldaan. Een enterprise service bus, web services of een servicelaag alleen maken nog geen soa. Dat zijn technieken, die je wel heel goed op een soa-manier kunt gebruiken. Zorg dat de essentie van soa wordt begrepen. Pas daarna komen de voordelen, waarbij ik business agility en time-to-market met stip bovenaan plaats.
Bauke Teerenstra, IT architect, Atos Origin
Het draait om services, niet om middleware
Denk goed na over het doel dat je wilt bereiken: soa is alleen een middel. Een losse business case maken voor soa zelf is dan ook niet echt nuttig. Je moet op zoek gaan naar projecten waar een duidelijke behoefte is aan ontkoppeling tussen verschillende functionaliteiten, bijvoorbeeld omdat de functionaliteit hergebruikt kan worden in een ander proces of in een portaal. Dezelfde doelmatigheid geldt ook bij de inzet van soa middleware (ESB). Kijk daarbij ook goed naar de toegevoegde waarde die deze kan leveren. Dit kan erg verschillen per organisatie. Zo speelt een gemeente bijvoorbeeld met geheel andere problematiek als een bank. Uiteindelijk draait het in de service-architectuur vooral om de services en niet om de middleware.
Danny Greefhorst, directeur, ArchiXL
Denk verder dan alleen het ontwikkelproces
Denk aan de hele softwarelevenscyclus en aan elk deel van de organisatie dat betrokken is! We zijn met soa in een fase gekomen dat er weinig geheimen meer zijn over het toepassen van soa bij het ontwikkelen van applicaties en oplossingen. Het is echter een valkuil om niet verder te denken dan dit ontwikkelproces. Het komt nog steeds voor dat te laat vragen gesteld worden als: Wie gaat dit beheren? Hoe worden SLA's gedefinieerd en bewaakt? Wat zijn de consequenties voor de verschillende partijen bij wijzigingen en uitbreidingen in de toekomst? Betrek vanaf het prille begin ook de toekomstige beheerders en bekijk de impact op change management processen. En onderschat het belang van Service Level Agreements niet.
Theo Stolker, informatiearchitect, Inter Access
ICT faciliteert, maar de bedrijfsmogelijkheden zijn de echte waarde
Voor selecteren van soa-oplossingen moet men niet alleen focussen op het uitvoeren van technische integratiestandaardisering, maar juist meer in het verkrijgen van nieuwe bedrijfsoplossingen en mogelijkheden. De ict faciliteert, maar de bedrijfsmogelijkheden zijn de echte waarde. Hier gaat het om enerzijds 'composite applications' die door de integratiestandaardisatie van bedrijfsfunctionaliteiten resulteren in verkorte ontwikkeling van innovatieve bedrijfsprocessen. Dit ging voorheen alleen met veel manuele en technische aanpassingen. Maar de integratiestandaardisatie brengt een hele nieuwe generatie van mogelijkheden en dat is dat deel of zelfs delen van bedrijfsprocessen buiten het bedrijf geïntegreerd kunnen worden met mashups, SaaS en cloud computing oplossingen zoals Google maps, PayPal, Salesforce.com. Als men hierop focust dan brengt het selecteren van soa als oplossing een geheel andere dimensie aan een bedrijf.
Michael Widjaja, partner, Accenture
Aanschaf van een SOA-product leidt niet automatisch tot SOA
Realiseer dat het aanschaffen en uitrollen van een soa-product niet automatisch leidt tot een service-oriented architecture. Het soa-product is een ondersteunend product, namelijk een platform, welke het mogelijk maakt om met minder inspanning een soa te bereiken. Het is juist het ontwikkelprocess waarbij soa belangrijk is. Vanaf de eerste ontwerpfase speelt soa denken een rol en niet pas als het technisch ontwerp ter tafel komt. Een soa-platform levert slechts de ondersteunende tooling om sneller soa-projecten te kunnen uitvoeren. Denk aan: beheer, monitoring, grafische ontwikkelomgevingen. Als het ontwikkelprocess gericht is op soa, dan zal het platform succesvol zijn.
Marcel Grauwen, lead consultant, Global Middleware Consultancy
SOA is springlevend
Het belangrijkste advies voor soa is niet opgeven. Soa is door sommige al weer dood verklaard, maar niets is minder waar: soa is springlevend. Alleen net als alle andere hypes komt er een punt waarop de twijfel toeslaat. Is dit wel de juiste benadering, brengt het wel alle voordelen die de leveranciers verteld hebben ? Voor soa geldt niet als voor vele andere complexe technologische ontwikkelingen, het kost tijd om alle voordelen ervan te gaan ervaren, maar als het die tijd krijgt is SOA beslist zeer levensvatbaar. Mits op de juiste manier toegepast, gebruikmakend van voldoende governance, maar waak voor het te strak regelen van de procedures en afspraken. Het moet wel een vloeibaar geheel blijven, gericht op veranderlijkheid. Dus het belangrijkste advies voor SOA is: geef SOA de tijd om zichzelf te bewijzen, bezuinig niet op de expertise die nodig is om SOA verstandig toe te passen, en zorg goed voor je soa-initiatief door het precies voldoende governance aandacht te geven.
Edwin van Asch, solution architect, Systemation AES
SOA maakt versimpelen mogelijk
Met soa als hulpmiddel moeten we werken aan het versimpelen van ict en organisatie. Dus niet zomaar services ontwerpen en implementeren maar eerst de behoefte ter discussie stellen: ‘wie heeft dit eigenlijk nodig? Kunnen we een bedrijfsproces niet toevallig vereenvoudigen zodat de behoefte vermindert? Kunnen we de wet- en regelgeving niet vereenvoudigen zodat het systeem minder complex wordt? Of kunnen we de professional zelf niet een besluit laten nemen over zijn werk in plaats van de computer?' Pak het probleem op, draai het om, bekijk het van alle kanten, maak het simpel en los het op aan alle kanten! Niet zomaar direct in de ict-oplossing duiken. Soa is niet meer dan een hulpmiddel dat dit faciliteert. We hebben immens nog veel meer architectuurstijlen ter beschikking. Maar laten we in vredesnaam voorkomen dat we daar nog complexere oplossingen mee bouwen! Soa is een belangrijk hulpmiddel: services en standaardisatie maakt vereenvoudiging mogelijk.
Art Ligthart, partner, Ordina
Zorg voor aansluiting tussen SOA en business
De grootste uitdaging die ik in dit kader nog steeds regelmatig tegenkom, in verschillende marktsegmenten, is de aansluiting van op soa gebaseerde oplossingen op de belevingswereld aan de businesszijde. Het kost tev eel, duurt te lang en is te complex, oplossingen en producten worden ter discussie gesteld. Terwijl een bedrijf als Intel bijna 200 miljoen dollar per jaar bespaart op ict door hergebruik en architectuurdenken. Een goede stap in mijn beleving is om aan te haken bij de mensen die met bedrijfsprocesverbeteringen bezig zijn. En die zijn er binnen iedere organisatie wel ergens. Dat vergt wel dat je soa ziet als veel meer dan plat gezegd een opvolger van EAI. Dat vergt dat je gaat denken in diensten, zoals beschreven wordt in bijvoorbeeld ArchitectedSAP.
Mendel Koerts, SAP service line, Capgemini
Verzeker je van een gelijk begrip tussen vrager en aanbieder
Een service-oriented architecture is een gecontroleerde vorm van ict-dienstverlening. De gebruiker vraagt, de ict-dienstverlener levert. Samen hebben ze afgesproken waaraan de dienst moet voldoen en het is aan de leverancier om zijn middelen zodanig in te richten dat de gewenste kwaliteit en kwantiteit op een efficiënte wijze wordt aangeboden. De leverancier van de diensten is gebaat bij een zo breed mogelijk gebruik van de diensten. Het komt neer op het besturen van het aanbod op basis van de actuele vraag en de trend in de vraag op langere termijn; het publiceren van de mogelijkheden op een voor iedereen toegankelijke manier en het verzekeren van een gelijk begrip tussen vrager en aanbieder voor wat betreft de karakteristieken van de te leveren diensten. In ict-termen zijn dus nodig: een SOA Catalogue/Repository, een Service Management faciliteit en een Service Provisioning engine.
Frank Kroon,
De SOA gedachte is vanuit ontwikkeling en de (bedrijfs)proces gedachte natuurlijk een goede stap.
Maar gezien vanuit beheer, audit en beveiliging blijkt uit de praktijk dat het een complete green-field is.
Hier zal meer nadruk om moet komen te liggen.
Als je niet alle facetten goed implementeerd een beheert wordt SOA een Service Overdraagbare Aandoening.