Maar als bedrijf kan je wellicht toch beter eerst uitvissen wat soa wel is en waarom een bedrijf zich daar zo nodig moet aan wagen? En nog belangrijker, wie nu eigenlijk aan de soa-kar moet trekken in een bedrijf.

Soa is allang geen vieze term meer…. Het staat voor Service Oriented Architecture en dat zou eigenlijk al een voldoende verklaring moeten zijn. Bedrijven doen immers voor de taken en processen aan de zakelijke kant van het bedrijf een beroep op diensten die door de ict-afdeling aan de eindgebruikers wordt geleverd. En een soa beschrijft dan ook een mogelijke aanpak hoe ict die diensten concreet kan aanbieden. Eenvoudig, niet?

SOA is geen product

Wellicht is het duidelijker eerst te stellen wat soa niet is. “Soa is geen product dat je kant en klaar uit een doos haalt,” aldus Peter Vermeulen, consulting director bij IDC Benelux, “maar is in wezen een evolutieve wijze van software implementeren en aanwenden.” Het is dus een aanpak, die per definitie van bedrijf tot bedrijf anders zal worden ingevuld conform de noden van het bedrijf. En het is een evolutief gebeuren, en dus zeker niet van de ene op de andere dag in kannen en kruiken.

Een van de redenen waarom soa vandaag zoveel belangstelling geniet is onder meer de groeiende druk op cio’s vanuit de zakelijke kant van het bedrijf om sneller en beter op de (veranderende) bedrijfsnoden in te spelen. En dat is inclusief het snel, gericht en veilig toegankelijk maken van geïntegreerde bedrijfsinformatie. Bedrijven hebben immers “te maken met een groeiende concurrentie wereldwijd én lokaal, terwijl ook het gedrag van de klanten steeds grilliger wordt.” Bovendien worden ook de eisen vanwege de overheid, sectoriële reglementen en/of grote klanten en partners inzake het naleven van wetten en regels steeds strenger, wat alles samen niet zelden snelle aanpas-singen van processen en software vereist.

Kortom, soa moet worden gezien als een evolutieve en flexibele aanpak om in een haast continu proces door het samenvoegen van bestaande en nieuwe toepassingselementen de vereiste nieuwe diensten aan te bieden.

Opletten geblazen

Een valstrik is hierbij de verleiding om soa in eerste instantie te zien als een middel om kosten te besparen. De ict-afdeling heeft immers al een goede kijk op soa en verwerkt zo’n aanpak in de budgetten. Maar Vermeulen waarschuwt uitdrukkelijk tegen het overlaten van soa aan de ict-afdeling. “Soa wordt nog te vaak vanuit ict-standpunt bekeken, in plaats van hoe je er de bedrijfsprocessen mee kan veranderen!” klinkt het.

Meteen is dat ook de crux van een echt succesvolle soa-aanpak binnen bedrijven: het continu en vlot kunnen afstellen van ict-diensten op de bedrijfsnoden en vice versa. Want ook een aanpassing van de bedrijfsprocessen moet kunnen in het kader van een soa-aanpak. Helaas komt hier meteen ook een eeuwige ‘heilige graal’ om de hoek krijgen. Een betere alignering van ict op de bedrijfsnoden vergt immers een goed onderling begrip tussen ict’ers enerzijds en personen van de zakelijke kant van het bedrijf anderzijds… Een bedrijf start het best vanuit een bedrijfsstrategie om tot een eventueel (ver)nieuw(d)e business architecture te komen, en die vervolgens in een flexibele (soa-gerichte) ict-infrastructuur te vertalen. Immers, “een goede businessgerichte soa omsluit ook de bijhorende ict soa.” Omdat het een evolutieve architectuur betreft en niet een eenmalig specifiek productpakket, “kan je die beter zelf uitwerken en dat proces niet uitbesteden,” adviseert Vermeulen. Belangrijk is het voor dit alles voldoende ‘business sponsoring’ in het bedrijf te vinden.” Zeg maar personen uit de zakelijke kant van het bedrijf die echt bereid zijn aan de soa-kar te trekken vanuit het bedrijfsproces-standpunt!

Als beide partijen elkaar kunnen vinden in een lange termijn soa-aanpak, kunnen ze er ook allebei bij winnen. Voor de ict zit er een kwaliteitsverbetering van de geleverde diensten in, naast lagere ict-kosten en mogelijkheden voor een snellere ontwikkeling van bedrijfs-toepassingen. De ‘business’-kant van het bedrijf kan zich nog meer focussen op klanten, innovatie en een verhoogde operationele efficiëntie, zonder de vrees al te lang op de nodige toepassingen te moeten wachten. Overigens plukken bedrijven vandaag al niet zelden de vruchten van soa zonder het te weten. Bijvoorbeeld door verbeterde contacten met derden die wel al gebruik maken van soa of al een vorm van soa toepassen, zonder het ook zo te noemen. De wortels van soa gaan immers terug op technologieën voor Enterprise Application Integration en/of Enterprise Service Bus.

Peter Vermeulen waarschuwt overigens wel voor ‘vendor hype’. Soa is een etiket dat lijkt aan te zetten tot kopen en dan loopt een bedrijf het risico toch een ‘wondermiddel’ te worden aangesmeerd. Anderzijds stoelt soa toch op een stevige technologische leest, waarvoor al een hele rits standaarden werd geformuleerd (onder meer inzake webservices), weliswaar meer op puur infrastructuurniveau dan op ‘business’ niveau. Deze laatsten zijn nodig om ook toepassingen vlotter met elkaar te laten werken, door bijvoorbeeld gemeenschappelijke begrippen (als bijvoorbeeld, wat is een ‘klant’) of mechanismen inzake ‘workflow’, ‘orchestration’, ‘provisioning’ en dies meer. Het heeft er gelukkig alle schijn van dat als leveranciers op dit punt hun eigen standaarden gaan creëren, de onderliggende standaarden (zoals XML) toch nog latere mogelijkheden inzake ‘vertaling’ bieden.

Hoe aanpakken?

Een soa pak je bij voorkeur behoedzaam en doordacht aan zonder daarom ‘quick wins’ uit het oog te verliezen. Begin met een klein project dat gegarandeerd haalbaar is (of geen problemen creëert als het toch zou mislukken) en waarvan de baten onmiskenbaar zijn voor de zakelijke gebruikers. Vandaar ook de noodzaak om ict’ers en businessmensen samen te laten werken!

Probeer een soa-aanpak ook steeds zo goed mogelijk te structureren, om te voorkomen dat op langere termijn een services-‘spaghetti’, met navenante versiecontrole en afhankelijkheidsproblemen, ontstaat.

Aangezien het een architectuur betreft, zal een soa-aanpak in verschillende bedrijven ook verschillend worden ingevuld én moet die steeds open staan voor wijzigingen en aanpassingen. Dat vereist ook een lange-termijnvisie. “Ik ken wel bedrijven die een dergelijke roadmap voor de komende 10 jaar hebben,” weet Vermeulen. Een soa-aanpak zal daarbij ook ruimte voor aanpassingen voorzien, want na een tijd kan er een einde komen aan efficiëntieverhogingen uit het gebruik van een erp-omgeving en moet allicht meer aandacht worden besteed aan anders en beter werken (met andere bedrijfsprocessen).

Voor grotere bedrijven is het daarbij allicht interessanter een losstaande soa te formuleren en te implementeren, terwijl het voor kleinere bedrijven aangewezen is een soa op basis van een erp-omgeving uit te dokteren.. Een en ander zal daarbij ook afhangen van de partner(s) waarop een beroep gedaan wordt voor de implementatie, en dat kunnen zowel leveranciers van toepassingen zijn, als infrastructuurleveranciers, systeemintegratoren of off shore vendors. Voorts kan soa zich ook op verschillende wijzen concretiseren, met componenten die ‘loosely’ tot ‘tightly cou-pled’ (grove tot fijne granulariteit) zijn. Dat kan gaan van geoutsourcete businessprocessen (zoals vaak door bijvoorbeeld Indische outsourcers wordt aangeboden) of complete legaattoepas-singen (zonder aanpassingen) in een ‘losse koppeling’ met andere elementen tot het nauw koppelen van kleinere (wellicht nieuw geschreven) componenten die makkelijk tot nieuwe toepassingen kunnen worden samengevoegd. In de praktijk zal een soa-aanpak een beroep doen op die verschillende mogelijkheden, naargelang kostenbesparingen, snelheid, toekomstgerichtheid en dies meer primeren. Vandaag werken bedrijven wel overwegend aan soa op basis van eigen interne middelen, of middelen waarop men toch kan vertrouwen inzake beschikbaarheid, en niet zozeer op basis van services aangeboden door derden. Er moet in ieder geval altijd aandacht worden besteed aan de onderlinge afhankelijkheden van de samenstellende componenten.

Het heeft ook geen zin helemaal geen aandacht te besteden aan soa, want vaak duikt zo’n aanpak toch op een of andere wijze op in een bedrijf. In dat opzicht is het opmerkelijk dat nog weinig aandacht wordt besteed aan de mogelijk verstorende of complementaire werking van mash-ups. Dit zijn ad hoc samenvoegingen van gegevens uit verschillende bedrijfsbronnen en hoewel duidelijk verschillend in ‘scope’ ten opzichte van soa-gerichte ontwikkelingen, vormen ze toch een voorbeeld hoe eindgebruikers het heft in eigen hand kunnen nemen als het aankomt op het creëren van eigen toepassingen.

Voorts moet ook in een soa-aanpak uitdrukkelijk aandacht worden besteed aan ‘security’. Dat slaat niet alleen op de toegang voor de gebruikers maar ook op de onderlinge samenwerking van systemen en toepassingen en op het afnemen van diensten van buiten het bedrijf. Ook in dit laatste geval moet de betrouwbaarheid kunnen worden gecontroleerd.

Een soa doorbraak?

Ja, ‘ma non troppo’. Blijkbaar is de belangstelling voor soa toch nog vrij beperkt, wat onder meer bleek uit de recente Data News enquête (gepubliceerd in de ICT Guide 2008). Slechts 22 procent van de respondenten werkten al rond soa in hun bedrijf, en van de overigen hadden er 93 procent geen plannen in die richting. Volgens Vermeulen is er vandaag duidelijk meer belangstelling voor soa in landen als de VS, Groot-Brittannië en ook Nederland, en dat vooral in de grote(re) bedrijven. Cruciaal is en blijft evenwel dat soa een betere samenwerking tussen ict’ers en businessmensen vereist en zo een oplossing kan bieden voor het probleem dat vandaag “ict meer een struikelblok is voor flexibele aanpassing van business,” aldus Vermeulen, “het gevolg van een onvermogen om te veranderen en zelfs onwil.”

Guy Kindermans