Webservices zijn niet meer weg te denken uit ons ict-landschap. Vrijwel elk pakket dat nu te koop is biedt integratie-oplossingen op basis van webservices. De tools om zelf webservices te ontwikkelen zijn legio en ondertussen goed doorontwikkeld. Maar daarmee is het SOA-gedachtengoed nog lang niet geïmplementeerd. SOA koop je namelijk niet, SOA is een keuze om het ict-landschap op een bepaalde manier in te gaan richten. SOA staat voor service oriented architecture, oftewel een architectuur die gebaseerd is op (web)services. Het hebben van een set aan webservices betekent dus niet automatisch dat je een SOA hebt.
De keuze om SOA toe te passen moet gebaseerd zijn op de eisen en wensen van de business, net als alle andere inrichtingskeuzes die binnen het ict-domein worden gemaakt. De drijvende kracht achter deze keuzes zullen altijd de bedrijfsdoelstellingen moeten zijn. Beoogde voordelen die SOA biedt zijn flexibiliteit, betere besluitvorming, betere kostenbeheersing en het eenvoudiger kunnen aanpassen van het bedrijfsproces.
Maar het kopen van een pakket met webservices, of de keuze om elke integratie met behulp van webservices te doen, is niet de juiste stap om deze voordelen te realiseren. Deze voordelen kunnen pas bereikt worden als er op meerdere gebieden de juiste inrichtingskeuzes worden gemaakt; de ondersteuning door webservices is hier maar één mogelijke keuze in. En zoals met alle inrichtingskeuzes, is het bepalen van het doel en de weg om daar te komen essentieel om het optimale effect te bereiken. Dit is de rol die architectuur binnen een organisatie speelt en die ook in het geval van SOA van doorslaggevend belang is om de beoogde voordelen te kunnen bereiken.
Architectuur is verantwoordelijk om de vertaling te maken van bedrijfsbeleid naar ict-beleid. Dit beleid geeft richting aan de manier waarop de servicegeoriënteerde gedachte optimaal kan bijdragen aan de bedrijfsdoelstellingen. Daarbij spelen verschillende vraagstukken op verschillende architectuurdomeinen een rol in het kiezen van een juiste inpassing van service-oriëntatie.
In het bedrijfsarchitectuurdomein gaat het met name over de bedrijfsstrategie en -processen. Daarin moet kritisch gekeken worden welke procescomponenten in aanmerking komen om als service ingezet te worden. Hierbij zal vanuit businessperspectief nagedacht moeten worden over componenten die binnen het bedrijf op meerdere plekken gebruikt worden en die mede bepalend zijn voor bijvoorbeeld het bereiken van de doelstelling om snelle wijzigingen door te kunnen voeren.
In het domein van informatiesystemen en integratie zijn vooral de technische mogelijkheden en beperkingen van belang. Lang niet alle systemen lenen zicht voor het werken op basis van services. Niet elk systeem kan diensten aanbieden die stateless en contextloos zijn, of waarin operaties op het gewenste niveau te scheiden zijn. Op integratieniveau is een service ook lang niet altijd de meest wenselijke oplossing. Performance-eisen bij realtime toepassingen of hoog-volume transacties kunnen redenen zijn om vooral niet te kiezen voor een op standaarden gebaseerde webservice-integratie, maar om voor een voor het specifieke doel meest optimale integratie te gaan.
In het infrastructuurdomein is het vooral van belang om te kijken naar de mogelijkheden om services beschikbaar te stellen, te beveiligen, te beheren en te verzekeren dat ze voldoen aan de specifieke eisen met betrekking tot beschikbaarheid. Goede services zijn feitelijk mini-applicaties. Vanuit een beheerperspectief moeten er nu dus niet enkele tientallen applicaties beheerd worden, maar honderden tot duizenden services. Dit vraagt om een andere inrichting van beheer en het selecteren van de juiste hulpmiddelen hierbij om te zorgen dat de continuïteit van services gewaarborgd is. Want als een service die door meerdere afnemers wordt gebruikt plotseling niet beschikbaar is, dan is de impact ook direct groot.
Dit zijn allemaal redenen om vooraf goed na te denken waar een service oriented architecture toegevoegde waarde biedt aan de organisatie. Er zullen gefundeerde keuzes gemaakt moeten worden en de gevolgen van deze keuzes zullen goed overwogen moeten worden. Dit vereist een sterk architectuurbeleid, waarin beleid helder geformuleerd wordt en besluitvorming goed ingericht is. Zonder een helder architectuurbeleid is de kans op een wildgroei aan services groot, met als gevolg beheerproblematiek en uiteindelijk een verminderd vertrouwen van de business in het SOA-concept.
Een goed architectuurbeleid richt zich ook niet alleen op de ict-kant van het verhaal. Het betrekken van de business, door het beleggen van de juiste verantwoordelijkheden rondom eigenaarschap bijvoorbeeld, is hierin essentieel. In elke architectuur is stakeholdermanagement essentieel, bij SOA is dat zeker niet anders. De kracht van services is juist dat het business en ict over dezelfde services kan laten praten.
Een goed architectuurbeleid voorkomt ook dat het complete ict-landschap onnodig wordt verbouwd tot losse services, terwijl dat absoluut niet nodig is voor het bereiken van de bedrijfsdoelstellingen. Goed architectuurbeleid zorgt voor het inzetten van service-oriëntatie waar het waarde toevoegt.
Architectuur is dus de drijvende kracht achter een succesvolle SOA. Eerst goed nadenken wat de doelstelling is die wordt nagestreefd, hoe en waar dit uitgevoerd kan worden en hoe dit beheersbaar gehouden moet worden, daarna pas starten met implementatie.
