Bij applicatiebeheer is een goede gebruiksondersteuning (incidentbeheer) belangrijk. Even zo belangrijk is het onderhouds- en vernieuwingsproces van applicaties. Het is een utopie dat een maatwerkapplicatie gedurende haar levensduur niet wijzigt. Veranderende behoeften zijn vaak aanleiding om applicaties te wijzigen. Maar ook externe factoren zoals aanpassingen in wetgeving kunnen een aanleiding zijn. Een recent voorbeeld is de cookie-wetgeving.
Na het bouwen en opleveren van een applicatie worden altijd nog aanpassingen gedaan. Logisch, omdat gebruikers er na oplevering mee gaan werken en tegen een aantal zaken aanlopen. Wijzigingen die worden doorgevoerd nadat de applicatie is opgeleverd en in beheer is genomen, volgen in grote lijnen dezelfde processen als wijzigingen tijdens het bouwtraject. Er is echter een aantal zaken waarmee tijdens het beheer rekening moet worden gehouden. De applicatie is immers al in gebruik en daardoor zijn de eisen rondom kwaliteit, onderhoud, afhankelijkheden en testen groter. Het inrichten van change en release management voorkomt verstoringen.
Onderhoud en vernieuwing
Binnen het Application Services Library-framework (ASL 2) is een aantal procesclusters opgezet om applicatiebeheer goed in te richten. Eén daarvan is het cluster ‘onderhoud en vernieuwing’ dat we in dit artikel toelichten. Naast dit cluster zijn de verbindende processen ‘wijzigingenbeheer’ en ‘programmabeheer en distributie’ cruciaal voor een correcte afhandeling van wijzigingen. Met het proces ‘onderhoud en vernieuwing’ worden verantwoordelijkheden tussen functioneel, technisch en applicatiebeheer afgebakend. Verder zorgt dit proces voor kennisborging, wat tot minder afhankelijkheid van bepaalde medewerkers zorgt. Ook kunnen wijzigingsplannen worden gebundeld tot volledige releases, langslepende wijzigingen worden voorkomen en worden afhankelijkheden tussen verschillende wijzigingen tijdig onderkend. Het proces ‘onderhoud en vernieuwing’ leidt tot een standaardisatie van de dienstverlening, kostenbesparing en een hoger niveau van service en kwaliteit.
Wijzigingenbeheer
De verbindende processen regelen de overdracht van dagelijks beheer naar onderhoud en vernieuwing en vice versa. Het wijzigingenbeheerproces heeft als doel het werken op een gestandaardiseerde wijze. Wijzigingen worden ingepland en op basis van de juiste prioriteiten uitgevoerd. Dit gebeurt in overleg met de klant, omdat zoals gezegd wijzigingen vaak ontstaan vanuit gebruikersbehoeften. Uiteraard moet rekening worden gehouden met afspraken om wijzigingen als een release uit te brengen. Ook is het noodzakelijk gebruikers tijdig te laten weten wanneer zij een nieuwe release kunnen verwachten. Wijzigingenbeheer gaat in samenspraak met de impactanalyse van het proces onderhoud en vernieuwing. Vanuit deze analyse zal er regelmatig met wijzigingenbeheer contact zijn over eventuele aannames die moeten worden gedaan of gevolgen van de wijziging voor het dagelijkse beheer. Het is van belang vooraf vast te stellen of er voor het dagelijkse beheer is te werken met een doorgevoerde wijziging.
Naast de gangbare wijzigingen die bij een oplevering worden doorgevoerd, kennen we wijzigingen die voortkomen uit een programmeerfout (bug). Wijzigingen van dit type kunnen meestal niet wachten op de normale opleveringsplanning en worden in een zogenaamde hotfix release naar productie gebracht.
Grootschalige wijzigingen die buiten het normale onderhoudsproces vallen, worden meestal projectmatig opgepakt. Het is dus mogelijk dat verschillende opleveringen parallel naast elkaar lopen. Dit vergt een goede planning en technische invulling van het gelijk laten lopen van verschillende broncodeversies (branches): de branching en merging strategie. In nevenstaand figuur zien we dit schematisch weergegeven binnen het ASL2-framework.
De processen
Zoals gezegd volgen de onderhouds- en vernieuwingsprocessen in grote lijnen dezelfde werkwijze als in applicatieontwikkeling. De processen van onderhoud en vernieuwing zijn:
– Impactanalyse; hier wordt in kaart gebracht wat de consequenties zijn van een wijzigingsvoorstel. Denk hierbij in termen van inspanning (de begroting), toekomst (onderhoudbaarheid), gevolgen voor gebruik en de risico’s.
– Ontwerpfase; hierin wordt dieper ingegaan op de vraagstelling uit het wijzigingsverzoek en wordt er een oplossingsrichting bepaald en uitgewerkt.
– Realisatiefase; hierin wordt het ontwerp van de wijziging concreet uitgewerkt en ook de documentatie over de wijziging wordt opgeleverd en/of aangepast.
– Testfase; hierin worden de wijzigingen getest.
– Implementatiefase; in deze slotfase volgt na de acceptatie, eventuele opleiding en/of instructies van dechargeverlening door de opdrachtgever.
Ondanks dat ASL2 in het procescluster onderhoud en vernieuwing bovengenoemde fases doorloopt volgens de watervalmethode, is er geen enkele belemmering om bijvoorbeeld iteratieve methoden te gebruiken zoals Agile of Rational Unified Process (RUP). Het meest ideaal is om tijdens de applicatieontwikkeling al rekening te houden met de eisen van het onderhoud- en beheerteam. Fundamentele keuzes die tijdens de ontwikkeling worden gemaakt, kunnen later tijdens onderhoud en beheer een obstakel vormen voor verdere ontwikkeling. Om van de fase van acceptatie naar de fase van beheer te komen, zijn dan ook vaak aanvullende investeringen nodig.
Meer dan tijdens de applicatieontwikkeling, moet tijdens de fase van het onderhoud en beheer meer rekening worden gehouden met enkele zaken. Zo worden aan een bestaande applicatie hogere eisen gesteld. De verwachtingen van de gebruikers zijn vaak dusdanig dat zij geen (nieuwe) problemen willen ondervinden met het uitbrengen van een nieuwe versie van de software. Ook zijn deadlines strikt, denk maar aan het voorbeeld van de cookie-wetgeving. Verder kunnen gebruikte technologieën verouderd zijn. Dan is de vraag hoe je voor voldoende kennisniveau van het onderhoud-en-beheer-team zorgt. En software moet beheersbaar blijven. Doordat verschillende beheerders werken aan de software gedurende de lifecycle, kan de broncode complex worden. Snel opgeloste problemen in de software blijven vaak als een suboptimale oplossing in de applicatie voortbestaan. Tenslotte wordt bij applicatieontwikkeling vooraf een budget beschikbaar gesteld. Organisaties vergeten vaak dat tijdens de onderhoud- en beheer-fase ook een budget moet worden gereserveerd voor wijzigingen. Het is niet ongebruikelijk om jaarlijks gemiddeld twintig procent van de initiële ontwikkelkosten te reserveren als budget voor onderhoud en beheer.
Programmabeheer en distributie
Het laatste proces is het verbindend proces programmabeheer en distributie. Binnen dit onderdeel wordt de vastlegging, verspreiding (uitrollen) en het beheren van de (ver)nieuw(d)e applicatieonderdelen vastgelegd. De taken die we dan vooral zien, is het beschikbaar stellen van releasenotes en handleidingen aan gebruikers en het veilig stellen van uitrolsets en –instructies en test-sets.
Tot slot
Een doordacht onderhouds- en vernieuwingsproces is niet zomaar geregeld. Een onderhouds- en vernieuwingsproces waarbij meerdere partijen zijn betrokken, dwingen medewerkers ertoe duidelijke afspraken over verantwoordelijkheden te maken binnen alle processen.
Eric Kwerreveld, manager application maintenance & support bij Macaw Application Services
Dit artikel schetst het beeld van softwareontwikkeling, -beheer en change/releasemanagement zoals we dat al jaren kennen. ASL, ITIL, RUP en Scrum vormen daarin de hoofdmoot. De problemen die in het artikel genoemd worden zoals plannen en het halen van deadlines, budget reserveren, en (gebrek aan) kennisuitwisseling zijn er zeker maar zijn allemaal het gevolg van het opwerpen van muren tussen ontwikkeling en beheer en het strict volgen van bovengenoemde methoden. Ik vind het daarom jammer dat deze ‘ouderwetse’ en arbeidsintensieve processen uitgebreid beschreven worden en dat er niet wordt ingegaan op nieuwe ontwikkelingen. De DevOps methode zorgt er bijvoorbeeld voor dat de ontwikkel- en beheerteams beter gaan samenwerken en gedeelde verantwoordelijkheid nemen voor het eindproduct. Continuous integration en continous delivery maken snelle, automatische en frequente releases naar productie mogelijk. Met dit soort methoden en technieken kunnen teams efficiënter werken waardoor eindgebruikers/klanten als winnaar uit de bus komen.
Dit artikel blinkt uit in wollig taalgebruik en wazige vakterminologie. Maar echt inhoudelijk is dit niet meer dan een opsomming van steekwoorden voor checklijstjes. Wat dat betreft zou een persoonlijk perspectief het geheel wat minder droog maken. En een eigenlijk antwoordt op de implicitiete vraagstelling in de titel wordt niet gegeven.
Ik volg de beredenering uit de boekjes ook niet zo heel erg maar dat zal ongetwijfeld aan mij liggen. Ik zal maar even niet beginnen over het gemis aan materie kennis van de IT, ze zouden me er eens voor verguizen hier in Computable.
Het is een open deur. Natuurlijk wijzigen applicaties wanneer omstandigheden veranderen! Alleen al, als voorbeeld, dat BTW tarieven wijzigen in een applicatie, dan dient er een upgrade te komen die die tarieven doorvoert. Immers, dat is namelijk de taak van automatiseren. Het dusdanig inregelen dat iedereen er met een druk op de knop mee uit de voeten kan.
Wat ik zeer uitgebreid en wollig lees, zijn standaard processen waarbij zeer veel zaken bij elkaar op een hoop worden geveegd ten einde …… tja … daar ga ik mank.
FO/TO RFC
Het maakt mij niet uit met welke u wil beginnen. De intentie is dezelfde. Tot een change te komen.
Development – Test
Vervolgens heeft u een Beta die wordt getest en met een beetje geluk een functionalteits test.
Eerste communicatie
De eerste communicatie wordt door Change Management gedaan zodat iedereen begrijpt dat er wat aan zit te komen.
Pilot
Vervolgens een pilot met een selecte groep gebruikers waar een aantal zaken worden getest. Roll out/back, functioneel testen, impact assessment.
Go/No Go
Vervolgens word er een besluit genomen. Is er aan alle voorwaarden voldaan? Mooi, dan gaan we een keer ‘Live’.
Tweede communicatie
Change management scheduled een release en communiceert dit naar de goegemeente en wanneer niemand kijkt, of thuis is, kan de change worden doorgevoerd. Uiteraard hoort in de communicatie ook dat IT support daarin is geïnstrueerd en dat men weet wat er gebeurd en wat er van ze wordt verwacht. Uiteraard!
Documentatie
Natuurlijk is er ook gedacht aan de gebruikersdocumentatie en natuurlijk de technische onderhouds documentatie, de FAQ en Known Problems.
Budget
Vanuit de praktijk weet ik dat meer dan 80% van de budgetten in boven geschilderd voorbeeld totaal ontoereikend zal zijn. Dat heeft te maken met het immer bestaande gapende gat tussen IT en non IT en niet te vergeten de (IT) commercie. Wanneer we zoiets plaatsen in het licht van de overheid, neem bijvoorbeeld het EPD van Ab Klink, dan heb je na 600 miljoen natuurlijk ook nog niets.
Rest mij na het lezen van de publicatie toch een kleine pregnante vraag.
Hoe komt het toch dat men nog steeds niet begrijpt dat wanneer je te maken krijgt met lineaire processen, men dan nog steeds cirkels of ovalen gebruikt????
Even over het ‘Tot Slot…..’
Over een IT proces kun je niet onderhandelen. het is een O of een I (value) Het is domweg het beleggen van een voorgenomen taak (top Down) waarin je verwachtingen uit in procesvorm en dat als ‘assignment’ in SLA of hand over vervat.
Documentatie, ook de proces documentatie, maakt gewoon deel uit van het standaard E2E proces voor ontwikkeling, testen en oplevering. Tenminste, dat is stellig mijn bescheiden menig.