Beleid opstellen rondom SOA

Service-oriented architecture (soa) is in ict-land inmiddels een ingeburgerd begrip. Technologisch gezien weten bedrijven er wel invulling aan te geven, maar beleidsmatig ligt het overgaan op soa wat lastiger. Want wat voor governance moet je op soa loslaten? En kan beleid rondom soa niet in de ict-governance worden opgenomen? Lastige vragen waarop de experts van het topic SOA antwoord proberen te geven.

Gert Jan Timmerman, hoofd Kenniscentrum, Info Support

Essentieel bij het inrichten van een soa is de aansluiting bij de organisatie. In het algemeen geldt dat ict-systemen zo nauw mogelijk moeten aansluiten bij de bedrijfsprocessen. Bij de inrichting van een soa is het daarom onvermijdelijk om kritisch naar de bestaande situatie te kijken. Om een soa goed te laten functioneren, moeten in de meeste gevallen de bedrijfsprocessen omgevormd worden zodat er een nette soa opgesteld kan worden. Denk hierbij aan het beschrijven van gemeenschappelijke gegevensstructuren, het verleggen van informatiestromen en het bepalen van de eigenaars van services. Dergelijke wijzigingen kunnen in een organisatie gemakkelijk op weerstand stuiten.

Theo Stolker, informatiearchitect, Inter Access

Belangrijke vraag binnen soa-governance is welke services er nodig zijn. Er zijn verschillende manieren om dit te beantwoorden. Als de vraag start vanuit een bpm-procesimplementatie kan het procesmodel uitstekend gebruikt worden voor functionele procesdecompositie, om zo te bepalen welke services er nodig zijn. Om niet in de val te trappen services alleen te ontwerpen vanuit een specifiek proces is het verstandig dat te combineren met een business service portfolio management-proces. Daarin bepaal je welke services er in elk domein of functiecategorie nodig zijn om je bedrijfsprocessen te ondersteunen. Dit kan in generieke termen, zonder alle bedrijfsprocessen in detail te kennen.

Ferry Bijl, business solution architect, Bijlsoft

Soa-governance is niet te koop. Het team dat de eerste oplossingen op soa-basis in jouw organisatie neerzette, had nog wel het overzicht over die paar services die werden gebruikt. Ze kenden de versienummers en afhankelijkheden. Maar toen jouw soa geen hype meer was, verder groeide en teamleden vertrokken, ging hij een eigen leven leiden. In het budget van het project was weliswaar netjes een stukje budget gereserveerd voor een tool voor soa-governance, toch bleek dat niet het enige wat nodig was. Soa-governance is namelijk geen tool maar gedrag. Het hoort een onderdeel van de systems development life cycle te zijn, geïntegreerd met ict-managementsystemen. Zolang soa-governance niet volledig is ingebed in de werkwijze van de organisatie, zijn de kosten hoger dan de baten.

Organisaties die zich op het soa pad begeven zouden zich dus niet alleen moeten concentreren op het selecteren van een esb-leverancier of de juiste bpm-tooling, maar ook op het realiseren van een goede basis voor soa-governance. Door een board voor soa-governance in te stellen, kan het beleid voor soa-governance worden vastgelegd en kunnen de te volgen processen worden ingericht. Pas wanneer deze basis is gelegd, heeft het nut om tools voor soa-governance (registries, repositories, CMDB's) te selecteren ter ondersteuning van het beleid. Hoe beter de organisatie is in ict-governance (bijvoorbeeld itil), des te makkelijker zal volgens de principes van soa-governance geleefd worden. Soa-governance is niet voor niets een subset van ict-governance.

Ad Gerrits, informatiearchitect, Gemeente Nijmegen

Soa is een denkmodel waarbij leveranciers volgens servicecontracten diensten leveren aan afnemers. Een organisatie kon kiezen of, en in welke mate, soa-principes werden toegepast. ‘Zonder governance maar beter niet beginnen met soa' is een bekend advies. Een nieuwe generatie cloudservices vormt het breekijzer dat dit gaat veranderen. Cloudservices worden, of zijn al, beter en goedkoper dan ict-voorzieningen in eigen huis. Werken met soa-principes wordt daardoor noodzakelijk en soa-governance belangrijker dan ooit. Want de voordelen van soa, voor zowel bedrijfsprocessen als ict, worden pas echt benut als er binnen de hele organisatie servicegericht wordt gedacht.

Friso Schutte, it-architect, Cerios

In mijn ervaring komt een zogenaamde ‘center of excellence', die regels voor de definiëring, afbakening en registratie van services opstelt en daarmee voor soa-governance zorgt, meestal niet goed van de grond vanwege gebrek een multidisciplinaire kennis. Er is sprake van een structurele onderschatting van de technische complexiteit. In het ergste geval denkt de architect bijvoorbeeld dat het hebben van een webservice registry garandeert dat je automatisch loosely coupled en herbruikbare services krijgt, terwijl de ontwikkelafdeling het als een overbodige tool ziet die misschien leuk is voor de beheerafdeling en de beheerafdeling vraagt zich af wie de tool eigenlijk gebruikt.

Mendel Koerts, principal consultant, Capgemini

Soa-governance. Met deze samenstelling van twee woorden worden begrippen bij elkaar gevoegd die allebei hoog scoren op de verwarringsindex… Stel dat de lokale EDP-auditor van dienst vragen gesteld heeft over de beheersing van een servicegeoriënteerde applicatiearchitectuur waarop de teamleider Software Ontwikkeling geantwoord heeft met ‘Ja, daar hebben we tools voor'. Uit de audit-resultaten blijkt dat er ruimte voor verbetering is. Waarom?

Soa heeft voor veel mensen te maken met systeemintegratie op basis van webstandaarden en webtechnologie. Voor anderen gaat soa veel verder en beslaat het tevens de niet-ict-kant van een enterprise architectuur. Het e-book ‘ArchitectedERP' beschrijft bijvoorbeeld het ‘Denken in Diensten'-concept. Governance op zijn beurt heeft te maken met structuren en processen die een organisatie in staat stellen op een gecontroleerde manier besluiten te nemen. En wat is dan soa-governance?

Het Common Architecture Reference Model (CORA) verdeelt soa-governance onder in drie technische deelgebieden: de service policy, de service repository en de service registry. Een product als de SAP ‘Enterprise Services Repository' dekt dat netjes af. Aan de andere kant beveelt SAP via een wiki aan een soa-governanceproces op te zetten ‘to drive clear decisions about the use of soa in software products…'. Soa-governance gaat zo bekeken dus over structuren en processen voor de beheersing van een soa en ook over de tools die deze ondersteunen.

Massimo Capoccia, director product management, Infor

Governance is meer en meer een noodzaak aan het worden als het gaat om het beheren van de life-cycle van een soa-architectuur in een organisatie. Helaas wordt governance door bedrijven vaak slecht geïmplementeerd, waardoor het meer als een obstakel wordt ervaren dan een voordeel. Governance krijgt meestal binnen bedrijven een bredere charter dan waar het voor bedoeld is, namelijk het beheren van service-interfaces, portfoliomanagement, stimuleren van hergebruik en het beheren van bedrijfsprocessen.

Organisaties introduceren veelal zware bureaucratische processen waarbij iedereen elke dag beslissingen moet goedkeuren. Top down-gedachten die vaker een belasting zijn voor de operatie dan een vereenvoudiging. Het ontbreekt dan vaak aan een evenwichtige balans door tevens een bottum up-benadering te integreren. Als voorbeeld uit mijn praktijk merk ik dat veel teams te veel tijd besteden aan eindeloze discussies over hoe interfaces eruit moeten zien of welke formaten de berichten moeten hebben. Dit alles ten faveure van de politieke belangen en niet vanwege de bedrijfsbelangen. Eigenlijk spreek je meer van het definiëren van een ‘politieke interface' dan governance. Bedrijven met zo'n opzet zullen dan vaker ook geen voordeel ervaren.

Danny Greefhorst, directeur, ArchiXL

Soa-governance is te veel opgeblazen door leveranciers. Soa heeft wel impact op een organisatie en de wijze waarop systemen worden ontwikkeld en beheerd, maar is niet zodanig specifiek dat je hier iets heel bijzonders voor moet inrichten. Als de architectuur-, ontwikkel- en beheerprocessen op orde zijn, dan is ook soa onder controle. Soa-governance is dan niet meer dan ‘normale' ict-governance en architectuur-governance.

Gijsbert in ’t Veld, cto en principal consultant, motion10

Om een services oriented architecture (soa) te omarmen – mijns inziens een nobrainer – wordt vaak al snel gekozen om een enterprise service bus (esb) te implementeren. De esb maakt het mogelijk om sneller de eerste soa-implementatie(s) tot stand te brengen en is bij uitstek geschikt om structuur aan te brengen in de aanpak en het uiteindelijke beheer. Het biedt de voordelen van flexibiliteit (stukken functionaliteit kunnen makkelijk bijgeplaatst en vervangen worden doordat er ook binnen de esb gebruik gemaakt wordt van een service gerichte aanpak), aanpasbaarheid (vele protocollen en standaarden worden ondersteund (lang niet alles wordt al ontsloten via standaard web services)) en robuustheid (d meeste esb's maken gebruik van een (combinatie van) standaard producten om de esb-functionaliteiten mogelijk te maken en hebben ingebouwde voorzieningen voor schaalbaarheid, herstartbaarheid en monitoring).

Met name dit laatste punt wordt in de praktijk nog al eens genegeerd en is men vaak al blij als er een werkende, ‘productierijpe' versie van een oplossing is opgeleverd, om er na een tijdje achter te komen dat er voornamelijk uit is gegaan van ‘happy flows' en er eigenlijk geen zaken worden gemeten. En zoals bekend: meten is weten!

Door nu voor alle services die geconsumeerd en gepubliceerd worden door de esb, alsook de services die de esb zelf gebruikt (transformatie, routering, etc.) uit te rusten met de juiste, vaak standaard aanwezige instrumentatiefunctionaliteit, kunnen de eerste basisstappen worden genomen om runtime soa-governance mogelijk te maken. Door het ontwikkelen (of hergebruiken) van standaard frameworks voor het gekozen esb-platform is dit vaak een maar kleine extra stap tijdens het ontwikkelproces die later zijn vruchten afwerpt.

Gershon Janssen, it-architect, Qroot Consulting

Governance is voor iedereen moeilijk. Soa belooft voordelen en is breed omarmd. Na flink oefenen beginnen we de complexe realisatie in de vingers te krijgen en kunnen we ons opmaken om de beloftes die soa ons doet te incasseren. Toch? Wel als je jouw soa-goverance op orde hebt.

Zomaar wat items waarvan je vast enkele herkend: Heb je er regels of afspraken voor? Strong typing? Naamconventies? Technische standaarden? Foutafhandeling? Operationele validatie? Beveiligingsstandaard? Centraal handhavingmodel? Security bij orkestraties? Hoeveel versies van één service live? Wie betaalt dat? Utiliteitsservices? Wie is daar eigenaar van? Registreren van services? Toestemming voor gebruik en mate van gebruik? Werkt de service nog? Problemen en nu? Tooling?

Feit is dat over vele aspecten, van ontwerp tot beheer, afspraken moeten worden gemaakt; het liefst van meet af aan. Doe je dat niet, dan verzand je vrij vlot in implementatieverschillen met als resultaat een instabiele productiesituatie met op termijn een flinke set van legacy-soa-services. Een nachtmerrie! Governance kan je hiervoor behoeden, echter is een uitdaging op zich die we tot nu toe te laat aangaan.

Nu is het lastige van governance dat je er pas wat aan kunt doen wanneer je ook weet wat de problemen kunnen zijn. Je weet dan immers waarover je wat moet gaan afspreken. Early adopters hebben dit aan de lijve ondervonden, wat maakt dat er inmiddels best practices zijn. Helaas zijn deze slechts richtinggevend en blijft het toespitsen op de organisatie alleszins uitdagend.

Ferrie Roelfzema, partnermanager, Software AG

Wanneer mensen de term ‘governance' horen, associëren zij dit veelal met een verstikkende bureaucratie van regels en procedures, waarbij elke vorm van creativiteit en flexibiliteit ontnomen wordt. In de context van een servicegerichte architectuur (soa) is governance echter een essentieel ingrediënt om het potentieel van soa te ontsluiten en flexibele en betrouwbare oplossingen te ontwikkelen.

Soa-governance vertoont grote overeenkomst met andere aspecten van ict-governance en zouden samen moeten evolueren. Soa-governance kan echter een grotere impact binnen een organisatie hebben en zou niet beperkt moeten worden door het labeltje ‘techniek' of ‘ict-projecten'. Het dient beschouwd te worden als een fundamentele organisatiebrede beweging, met evenveel waarde voor de business als voor ict. Om dit te bereiken dient de soa registry/repository enerzijds opgezet te worden als het referentiepunt voor business services en anderzijds als de bron voor operationele informatie voor het optimaliseren van deze services.

Om soa-governance succesvol te implementeren, is juiste planning noodzakelijk. Allereerst dient bepaald te worden wat beheerd moet worden, vervolgens hoe het beheerd en gemonitored moet worden. Bij de implementatie van soa-governance dient een organisatie ten minste de volgende zes punten te adresseren:

1. Het niveau van soa-volwassenheid vaststellen.
2. De doelstellingen van soa definiëren en publiceren.
3. Vaststellen van de soa-organisatiestructuur.
4. Creëren van de noodzakelijke processen ten behoeve van soa-governance.
5. Soa-processen iteratief en incrementeel implementeren, waardoor de architecturale evolutie van de gehele soa continu geborgd is.
6. Continu meten, evalueren en bijsturen.