Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het redactionele gedachtegoed van de redactie.

Vijf richtlijnen voor bouwen aan SOA-governance

Er is net een succesvol project afgerond waarin enkele bedrijfs processen verder zijn geautomatiseerd. Het project wijst uit dat gebruikers hun taken goed kunnen uitvoeren met de informatie die ze nodig hebben en dat er kosten kunnen worden bespaard. Gebruikers blij, klant blij, leverancier blij en iedereen leefde nog lang en gelukkig. Helaas is dit vaak niet het geval. Integendeel, dit is vaak het startsein om meer processen te gaan 'ver-SOA-en-. Vooral zo’n eerste, uiterst succesvol project creëert een nieuw niveau van complexiteit in de ict-organisatie. Vraag is hoe je die SOA-projecten succesvol kan managen. Dat kan met SOA-governance.

SOA-governance is de discipline die in een ideale wereld als eerste op de agenda staat binnen een SOA-project. Toch is het nooit te laat om de beheerorganisatie (op weg) te helpen voor de uitvoering van goed beleid, goede procedures en het onderhouden van de gebruikte technologie.

Zie het creëren en vastleggen van een goede SOA-governance als het opvoeden van een klein kind dat leert van ervaringen en zichzelf steeds verbetert. Bij SOA-governance gaat het om het bereiken van de optimale situatie waarbinnen de richtlijnen en processen helder zijn en eenduidig zijn vastgesteld. Er is goed beleid vastgesteld en het het SOA-governance-model mag als volwassen beschouwd worden. In mijn beleving zijn er minimaal vijf essentiële richtlijnen die het besturen en borgen van een SOA verbeteren:

1. Start een SOA competentie center binnen de organisatie

Belangrijk binnen dit kader is dat het team dat opgericht wordt, bestaat uit professionals met verschillende competenties en uit verschillende afdelingen binnen de organisatie. Door de oprichting van een dergelijke groep bevorder je ten eerste de communicatie tussen de verschillende groepen en ten tweede zorg je voor meer draagvlak en acceptatie. Omdat iedereen vertegenwoordigd is, is met elk aspect van de SOA-architectuur voldoende rekening te houden. Een voorbeeld: bij een gemeente moest een project worden uitgevoerd waar onder andere het proces van het realiseren van een werkplek voor een nieuwe medewerker (deels) moest worden geautomatiseerd. Dit project oversteeg ten minste drie afdelingen (ICT, Facilitaire Zaken en P&O). Omdat er vanaf de start van alle afdelingen een key user actief betrokken was bij het project, ontstond er meer ruimte voor open discussie en draagvlak voor de implementatie. Dat had uiteraard een positief effect op het succesvol afronden van het project.

2. Ervaring leert..., als het goed is gedocumenteerd

Blueprints en best practises vormen een uitstekend onderwijsmechanisme. Zij vormen een tastbare manier waarbij alle betrokkenen in de SOA-implementatie kunnen profiteren van het werk dat is gedaan. Te vaak vinden ontwikkelteams het wiel opnieuw uit voor het oplossen van een bepaald probleem. Het ontwikkelen van goede documentatie met duidelijke metadatagegevens en patronen dragen bij aan het creëren van herbruikbare onderdelen. Door gebruik te maken van een beproefde (standaard)aanpak ben je in staat om risico's te verkleinen, de ontwikkeltijd te verkorten en daarmee ook een vermindering van de kosten te realiseren. Omgekeerd is het net zo belangrijk om vast te leggen welke aanpakken in het verleden hebben gefaald! Niets is zo vervelend als achteraf te moeten constateren dat de gehanteerde aanpak ook in het verleden is toegepast en faalde. Een belangrijke valkuil is documentatiebeheer. Het is essentieel om afspraken te maken over de toegankelijkheid van de documentatie. Iets dat niemand kan terugvinden levert netto niets op!

3. Gebruik een SOA-archief

De gerealiseerde services binnen een SOA-implementatie zijn per definitie herbruikbaar, maar pas op met het verkeerd toepassen van een service. Het komt zelden voor dat de exact geïmplementeerde service opnieuw te gebruiken is voor een ander doeleinde. Delen van een service zijn echter wel te hergebruiken! Als services niet goed en/of consistent opgebouwd worden, kunnen ze net zo onbruikbaar worden als bepaalde legacy-systemen. Dit geldt ook voor het managen van services.  Door gebruik te maken van een SOA-repository, aangevuld met afspraken over beheer en gebruik, is de de kwaliteit van de beschrijving van een service, de opbouw ervan en het (her)gebruik te borgen.

4. Monitor de kwaliteit en naleving van de service(s)

Breng voorspelbaarheid aan binnen je SOA door het goed (laten) uitvoeren van servicemanagement. De volledige keten van services binnen jouw infrastructuur moet goed inzichtelijk gemaakt worden. De verwachte kwaliteit en stabiliteit moeten vastgelegd worden in SLA's (service level agreements). Bespreek en leg de volgende aspecten vast binnen de organisatie:

- Beschrijving van de services
- Response levels
- Analyses van het gebruik van services
- Performance rapportages
- Etc.

Met SLA's kan je proactief reageren op mogelijke bedreigingen en falen van services. Stabiliteit is het kenmerk van een volwassen systeem. Door middel van een doeltreffend beheer van jouw services (en bijbehorende infrastructuur) kan je een hoog niveau van stabiliteit bereiken en daarmee het succes van een SOA vergroten.

5. Beheer de SOA-levenscyclus

Dikwijls merk ik dat organisaties de levenscycli van ict-gerelateerde omgevingen en/of projecten goed en gedisciplineerd documenteren en naleven. Waarom zou dat bij een SOA anders moeten zijn? Het inbrengen van tools en het vastleggen van procedures helpen bij het beheren van de services, het nieuw ontwikkelen van services maar ook bij kwaliteitscontroles, eventuele onderhoud en een hele belangrijke: testen... Als onderdeel van de SOA-levenscyclus is het raadzaam om bij het testen van (nieuwe) services deze te onderwerpen aan een aantal standaardprocedures, richtlijnen, normen en regressietesten. Deze zorgen voor een langere levensduur en vooral ook robuustheid.

Het implementeren van een SOA behelst meer dan alleen de uitvoering van een aantal diensten of het gebruik van een ESB (enterprise service bus). SOA mag dan vaak relatief eenvoudig beginnen, het introduceert onherroepelijk complexiteit in de ict-organisatie. Dit komt vooral door de aard van de problemen die we proberen op te lossen.

Wie zich hiervan bewust is en passende maatregelen neemt voor het beheer van deze complexiteit, zet een juiste stap in het succesvol ontwikkelen, implementeren en onderhouden van een SOA. Mijn advies is dan ook om SOA goed van tevoren te plannen. Neem ruim de tijd hoe je de SOA-governance gaat oppakken en inregelen met het oog op toekomstige aansluiting(en) van de overige applicatie(s).

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/3004509). © Jaarbeurs IT Media.
?

 
Expert
Jaime  Conejo Verheijden

Jaime Conejo Verheijden Bac.
(Adjunct) directeur automatisering, CIO. Expert van voor het topic .
Hele profiel

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×