04 jul De spanning tussen een projectleider en een manager beheer

Laat ik beginnen met een mening: in een organisatie met kritische applicaties ben ik een voorstander van een OTAP-straat. Ontwikkelen, Testen, Acceptatie en Productie horen wat mij betreft in dit soort omgevingen volgens een ordelijke volgorde te verlopen.

Los van de IT-spullenboel die een OTAP-straat behelst, wil ik het vooral hebben over het regelmatig in de praktijk opdoemende spanningsveld tussen een projectleider en een manager IT-Beheer. Eén van de verantwoordelijkheden, zo niet de grootste en meest belangrijke, van een IT-beheerchef is het met zijn team zorgdragen voor een storingsvrije productie-omgeving.

Het adagium luidt:

verstoringen door welke oorzaak dan ook, moeten worden voorkomen.

En daar komt ineens die projectleider binnen op de afdeling IT-beheer en vraagt of je de opgeleverde wijzigingen uit zijn team zo snel mogelijk wil implementeren. Nog niet alles is klaar, maar het laatste gedeelte wordt nu getest. De projectleider werkt wel volgens OTAP, maar hij vindt dat het daardoor wel allemaal lang duurt. Vlak voor het releasemoment nog even een kleine aanpassing op de software doen en snel testen. Moet toch kunnen.

Het komt regelmatig voor dat er een IT activiteit nog even snel in productie moet. Meestal zijn dat de wijzigingen vanuit de projecten. De opleverdatum komt in zicht voor een deliverable, en dan gaat de projectorganisatie duwen. In principe heeft het project hier een planningsprobleem, en wordt dat bij beheer neergelegd. Dat is niet vreemd, want beheer zit aan het eind van de OTAP “pipeline”.

Ingrijpen dus Change- en Release Manager

Een wijziging mag niet leiden tot een verstoring van de productie. Dat kan niet voor 100% worden gegarandeerd, maar dat moet wel het streven zijn. Hoe voorkom je dat er productie verstoringen ontstaan?

• Door het CM/RM proces consequent toe te passen.
• Goed testen (is er een testplan?).
• Zorgen voor goede rollback scenario’s
• Van tevoren duidelijke afspraken maken met de indiener(s) van de wijziging(en).
• Richt een snel traject in voor échte urgenties (zoals het dichten van een beveiligingslek).

De drang om een wijziging “snel door de OTAP straat te jassen” leidt ook tot onnauwkeurigheid, waardoor er correcties en zelfs soms reparaties moeten worden uitgevoerd. Dat werkt een langere doorlooptijd in de hand, en verhoogt de werkdruk bij beheer. Het vermeende korte termijn belang levert dan niets op.

Het doorlopen van een OTAP straat in een release cyclus kan misschien wel langer duren, maar je borgt hiermee wel de kwaliteit van het proces. Het is dus een bewuste keuze van de klant / organisatie, en daar kan niet zomaar van worden afgeweken.

Is er haast bij de implementatie van een nieuwe functionaliteit voor de klant, dan kan deze een hogere prioriteit krijgen, maar dan blijven er andere zaken liggen. Goed inzicht in de werkzaamheden van de operationele afdeling is dan ook van essentieel belang.

Nu hoor ik u vragen: “hoe zit het dan met Agile?”. Past de OTAP methode nog wel binnen de Agile werkwijzen, zoals bijvoorbeeld SCRUM? Veel gehoorde bezwaren zijn:

• Complexe administratie
• Het kost te veel tijd een wijziging door de hele OTAP straat te loodsen. Hierdoor komen vaak op het laatste moment nog issues naar voren.
• OT omgevingen zijn vaak te traag en omgevingen zijn niet gelijk geconfigureerd.
• Je kunt pas naar de volgende stap als alle voorgaande stappen zijn goedgekeurd. Een OTAP straat werkt wachtrijen (queues) in de hand.

Dat een OTAP straat een complexe administratie veroorzaakt heeft een reden. De reden is niet de OTAP straat zelf, maar veel meer wat met een OTAP straat wordt gedaan. Denk hierbij aan veel korte termijn wijzigingen en fixes, lange(re) termijn wensen van de klant, security patches van de leverancier , diverse projecten, enz. De complexiteit wordt dan veroorzaakt door het ambitie niveau van de organisatie / klant.

De bezwaren dat OT omgevingen traag zijn, en niet identiek zijn geconfigureerd, kom ik vaker tegen. Dit heeft te maken met een (niet) goed omgevingen beheer. Voorheen was dat minder een probleem, maar door Agile werken liggen de eisen die worden gesteld aan de omgevingen hoger. Dit is vaak een kostentechnisch probleem, en dat ligt bij de eigenaar van de OTAP straat. Kijkt men alleen naar de kosten, of ook naar de kwaliteit?

Dat een OTAP straat lang duurt en wachtrijen veroorzaakt is een kwestie van organisatie

Vaak krijgen projecten een eigen OT(A) straat die uiteindelijk aanhaakt bij de AP straat van Change Management (CM). Vanaf dat moment val je onder regie van CM, en kan het langer duren, omdat men op een gepland moment gaat testen op de A omgeving (GAT-test). De acceptatie omgeving is tenslotte een functionele confrontatie tussen allé wijzigingen van dat moment. Daarna pas gaat het naar productie.

Vanuit Agile wordt als oplossing aangedragen:

• Reduceer het aantal omgevingen naar een O en P omgeving (P is de beste test omgeving). Voor kritische systemen is dit niet zonder gevaar. Op korte termijn lijkt er misschien geen probleem te zijn, op langere termijn kan er een probleem ontstaan, bijvoorbeeld een performance probleem, door groei van de database. Maar ook de “technische confrontatie” (normaal in de T omgeving uitgevoerd als Systeem Integratie Test -SIT-) wordt overgeslagen. Binnen de sprint, of zelfs binnen het project kan dit goed uitpakken, totdat een ander project zijn technische wijzigingen (die in de SIT wél waren getest) in productie brengt. De technische confrontatie vindt dan voor het eerst plaats in Productie en dat kan verkeerd uitpakken.
• Breng nieuwe features in productie, maar maakt ze pas zichtbaar voor de gebruiker als ze goed zijn getest. Dit is een andere deployment methode, en lijkt me geen probleem als dat in het CM/RM proces is in te passen.
• Automatiseer de deployments en het testen. Dit is volgens mij een oplossing die hout snijdt. Voorwaarde is wel dat dit proces eigenlijk feilloos verloopt. Men kan dan na verloop van tijd voldoende controle op en vertrouwen in het proces hebben, dat men een omgeving overslaat. Je zit dan wel op een hoog volwassenheidsniveau van de inrichting. Ik kom dat echter weinig tegen. Geautomatiseerd deployen en testen is een complexe zaak, waar veel operationele beheer organisaties (nog) niet aan toe zijn. Daarnaast zullen bijvoorbeeld Scrum sprints worden uitgevoerd door steeds in samenstelling wisselende teams. Ik zie hier een probleem met betrekking tot consistentie en borging, vooral voor de lange termijn. In theorie is dit in Agile wel afgedekt, ik zie er in de praktijk weinig van terug,

Bij kort cyclisch werken is de organisatie het knelpunt, niet de OTAP straat

Leg je als organisatie de lat hoog, dan zal je moeten investeren in:

• Een goede OTAP inrichting
• Een professioneel omgevingenbeheer
• Een professioneel Release- en Change management

Aangezien hier vaak de schoen knelt, uit zich dat in problemen in en met een OTAP straat. Dit zijn echter de symptomen, niet de oorzaak.

Niet in alle gevallen is een OTAP straat noodzakelijk. Niet kritische applicaties kunnen wel een afwijkende route volgen. Down time is dan geen probleem, en er is tijd om het probleem te fixen. Voor kritische bedrijfsvoering systemen is een OTAP in mijn ervaring een must.

Wilt u Agile werken, be my guest, maar kijk dan wel naar het volwassenheidsniveau van de operationele beheerorganisatie en het CM/CR proces. De projectleider stapt hier makkelijk overheen, de manager Ops wordt wel degelijk met de gevolgen geconfronteerd.