In de afgelopen maanden heb ik een grote provincie geholpen te bepalen hoe soa-governance zou moeten worden inrichten. Hierbij een verslag van de bevindingen.
Wat als eerste opviel bij de provincie is dat de betreffende organisatie al een duidelijke en goed werkende organisatie rond het beheer van applicaties heeft. Tot dan toe werd elk van deze applicaties echter gezien als losstaand. Dit leidde tot allerlei vragen en onzekerheid toen de eerste services beschikbaar werden gesteld voor het dms en de opmaak van brieven. Door een aantal sessies met architecten, projectleiders, functioneel ontwerpers en applicatiebeheerders kwamen we tot de volgende definities en afspraken:
1. Nu is de verantwoordelijkheid van functioneel- en technisch applicatiebeheerders gedefinieerd in termen van fysieke applicaties. Het is verstandig om dit om te vormen naar verantwoordelijkheid per functioneel domein, met uiteraard binnen dat domein nog steeds één of meerdere applicaties. Dit kan geleidelijk ingevoerd worden.
2. Het gebruik van een service is niet fundamenteel anders dan het gebruik van deze applicatie via al bestaande gebruikersschermen. In die zin valt toegang tot de applicatie via een service ook onder de verantwoordelijkheid van de functioneel applicatiebeheerder (fab). Wijzigingsbeheer voor services zou dus ook via deze fab moeten lopen, waarbij zoveel mogelijk gebruik gemaakt wordt van al bestaande werkwijzen. Bij de provincie is dat bijvoorbeeld dat wijzigingsverzoeken worden ingevoerd via het meldingsformulier van de Servicedesk. Daarnaast vallen ook informatiebeveiliging en functionele acceptatie van services onder verantwoordelijkheid van deze beheerder.
3. Ook uit technische oogpunt valt een service onder de verantwoordelijkheid van de applicatie die ze aanbied. De technisch applicatie beheerder zal dus ook kennis moeten hebben van de impact van het gebruik van de applicatie via deze services.
4. Het is belangrijk om inzicht te geven in de al beschikbare en de geplande services en hun interfaces. Binnen de provincie werd hiervoor al de term service catalogus gebruikt. In feite zou in deze service catalogus een compleet overzicht moeten geven van de levenscyclus van een service, oftewel, welke versie ontwikkeld wordt, welke versie in productie is, en welke versie uitgefaseerd zal worden of al uitgefaseerd is. Afspraak hier is dat de technisch applicatie beheerder de inhoud van deze catalogus up-to-date zal houden.
5. Over en weer hebben aanbieder en afnemer van een service verplichtingen, die ergens vastgelegd moeten worden in een service level agreement (sla), steeds vaker ook een dino genoemd (diensten niveau overeenkomst). Dat zou je per service kunnen doen,maar de provincie geeft er de voorkeur aan om de bestaande, generieke basis sla applicatiebeheer uit te breiden met specifieke aspecten van ondersteuning van webservices. Daarnaast wordt er per webservice een 'webservice levering overeenkomst' (wlo) opgesteld, analoog aan de bestaande 'gegevens levering overeenkomst" (glo) zoals die opgesteld wordt voor gegevensstromen aan bijvoorbeeld het datawarehouse.
We gaan in de komende maanden evalueren hoe de betreffende afspraken voldoen.
