SOA-governance besteedt nog niet voldoende aandacht aan de praktijk en de business.

SOA-governance moet een project beter helpen op poten zetten, bewaken en optimaliseren. Governance maakt bijvoorbeeld de definitie mogelijk van regels voor de creatie en het ‘gebruik’ van diensten, de controle van hun (technische en functionele) geschiktheid vóór hun ingebruikname, of nog de controle van prestaties, QoS, SLA’s, toegangsrechten, de organisatie van diensten in een samenhangend centraal register, enz. Ondernemingen besteden hier echter vaak veel te laat aandacht aan, namelijk op het moment dat de problemen opduiken, als er te veel slecht geïdentificeerde diensten zijn of als er onvoldoende hergebruik is. “Governance zou van in het begin een bekommernis moeten zijn, met een definitie van eenvoudige zaken die worden verrijkt naarmate de complexiteit toeneemt”, meent Eric Bernard (GFI). “Van bij het begin moet er een Excellence Committee worden opgericht dat de prioriteiten, rollen en verantwoordelijkheden bepaalt, de diensten geleidelijk aan in kaart brengt, bepaalt wie voor hun ontwikkeling en hun gebruik betaalt, en welk proces welke dienst vergt. Daarvoor moet een goed panel worden samengesteld, met mensen voorzien van de juiste ingesteldheid, de steun van de directie, respect van de medewerkers en een horizontale visie. Prioriteiten bepalen betekent overigens niet dat men moet afstappen van een globaal beeld van de architectuur die men wil vorm geven.” Een cruciaal punt is het definiëren van een systematiek die op coherente wijze de modules, functionaliteiten, verantwoordelijkheden van personen en sectoren beschrijft, zodanig dat de applicatiecomponenten echt met elkaar kunnen samenwerken, ook tussen verschillende departementen of met modules van andere bedrijven. Hoe meer een dienst blootgesteld en gedeeld wordt, hoe belangrijker deze problematiek.”

“Wat SOA betreft, was de enige toegepaste governance aanvankelijk financieel”, zegt Tim Hall van HP Software. “Daarna volgde de IT-governance, in de hoop de slaagkansen te verhogen. Maar het volstaat niet om enkel projecten en portefeuilles te beheren. Ook de – al dan niet functionele – behoeften moeten strenger gedefinieerd worden, en ze moeten traceerbaar zijn zodat we zeker weten dat de resultaten voldoening geven. Er is ook meer nauwgezetheid nodig voor de kwaliteit van de applicaties, of het nu gaat om beveiliging of prestaties. Er gebeuren nog te veel manuele tests. Een geautomatiseerd systeem zou moeten kunnen bevestigen en certificeren dat de ontwikkelde applicatie ook echt voldoet aan de eisen. Tools moeten in detail de evolutie naar het gewenste doel controleren en op het vlak van de veiligheid nagaan of de blootstelling van een dienst geen exploiteerbaar risico vormt voor een hacker.”

Efficiëntere tools

SOA-governance doet ondertussen een beroep op meer geavanceerde tools. We zien bijvoorbeeld oplossingen verschijnen op basis van regels die ze koppelen aan de verschillende stappen van de levenscyclus om automatisch te controleren dat men naar de volgende etappe kan gaan, die rollen en regels vergelijken, en verzoeken automatisch weigeren, nog voordat ze de server bereiken, als de auteur niet de toestemming had om ze te formuleren. Tools controleren automatisch de goede uitvoering van de transacties en verbeteren de boodschappen die voor problemen zorgen. Via automatisch opgestelde rapporten en dashboards (identificatie van gegevensbronnen, betrokken departementen, soorten boodschappen, verkeersvolume, prestaties, …) kunnen niet-technici de stromen bekijken zonder de boodschappen te hoeven ontcijferen. De catalogussen of referentiesystemen met diensten passen zich beter aan het profiel van de geadresseerde aan.

“Ontwikkelaars, technische architecten en businessanalisten hebben totaal verschillende behoeften inzake informatie en zichtbaarheid van de beschikbare diensten”, aldus Tim Hall. Vandaar dat er tools bestaan die de toegestane zichtbaarheidsgraad automatisch filteren, of sommige details verbergen (zoals code) als de dienst ter beschikking wordt gesteld van een externe partner of een klant. Ook diensten die worden beschouwd als mashable worden strenger gecontroleerd, zowel wat prestaties als beveiliging betreft. “Men moet kunnen identificeren op welke manier dit soort diensten gebruikt zal worden, ze niet zomaar blootstellen, maar beslissen wie ze zal gebruiken en hoe.”

Er zijn nog meer vorderingen op het vlak van het beheer van metadata (vooral voor de follow-up van veranderingen), inspecties en geautomatiseerde tests van code, integratie met producten en kwaliteitscontrolemechanismen.

Eric Bernard is echter van oordeel dat “tools vaak gericht zijn op het technische beheer van de diensten en niet echt nuttig zijn voor mensen van de business. Er zou een betere traceerbaarheid moeten zijn van de business naar de it toe, men zou beslissingen moeten nemen die op de beide dimensies slaan, en de ingebruikname van een nieuwe versie van bedrijfsprocessen pas mogen toestaan na een kosten-batenanalyse. De levenscyclus van de wijzigingen aan het dienstenaanbod moet beter ontwikkeld worden, zodat je bij elke stap weet wie zijn toestemming gaf voor de overgang van de ene status naar de andere, en wanneer.”

Brigitte Doucet