Het komt geregeld voor dat de ontwikkeling van een product ver gevorderd is, of zelfs al opgeleverd is, maar dan toch niet aan de wensen van de klant voldoet. Recent voorbeeld: het Fyra-debacle. De treinstellen zijn opgeleverd, voldoen functioneel naar wensen van de klant, zijn mooi afgewerkt maar vertonen talloze mankementen.
De bouwer van de trein, in dit geval AnsaldoBreda, vindt dat de NSonvoldoende onderhoud heeft gedaan en dat de mankementen te verhelpen zijn. De gevolgen hiervan zijn niet te overzien, een verliesgevend jaar voor NS, rechtszaken die ophanden zijn en de politieke verhoudingen tussen enerzijds België en Nederland en anderzijds Italië die onder druk komen te staan. Er zijn opmerkelijke parallellen te trekken met het opleveren van software releases en mijn ervaringen op het gebied van technisch applicatiebeheer.
Technisch applicatiebeheer
Wat versta ik onder technisch applicatiebeheer? Het installeren van nieuwe versies van de applicatie, fixes en van patches, het tunen van de database en de monitoring van processen en log files, opstellen van cleaning scripts en ongetwijfeld nog een aantal activiteiten die met het technisch applicatiebeheer te maken hebben. Dit technisch applicatiebeheer laat zich prima uitbesteden. De klant kan zich dan helemaal richten op de strategische rol van zijn applicatie-landschap en het lifecycle management van de applicaties. Althans, zo zou het in theorie moeten zijn.
In de praktijk pakt het nogal eens anders uit. Waar gaat het dan mis? Bijvoorbeeld wanneer er geen sprake is van een volwassen release management proces. Het draait dan om het spanningsveld tussen de wensen van de business en het op tijd opleveren van kwalitatief goede oplossingen. Deze software moet ook nog eens goed te installeren zijn, een goede performance hebben, veilig zijn en van de juiste documentatie voorzien. Als daar iets aan hapert komt dat onvermijdelijk binnen het domein van het technisch applicatiebeheer tot uiting.
Softwareontwikkeling en onderhoud (patches en fixes) gebeuren vaak onder grote tijdsdruk. Het gaat hierbij in de meeste gevallen om het zo snel mogelijk ontwikkelen van de gevraagde functionaliteit. Over hoe dat het beste kan gebeuren wordt dan ook erg veel geschreven, denk maar aan talloze artikelen over de waterval methode, Scrum, Agile, et cetera.. Al deze methodieken gaan vooral over de manier waarop de functionaliteit tot stand wordt gebracht, in relatie tot de wensen van de opdrachtgever.
Maar de kwaliteit van de ontwikkelde software in termen van performance en beveiliging, de benodigde infrastructurele configuratie en de noodzakelijke documentatie, komen nauwelijks aan bod. Juist binnen het technisch applicatiebeheer komen missers op dit gebied direct aan het licht, met alle gevolgen van dien. De applicatieontwikkelaar meent klaar te zijn zodra de gevraagde functionaliteit geboden wordt. De business zit hierop met spanning te wachten en gaat ervan uit met het opleveren van het product de software eigenlijk al klaar is.
Gevolgen?
En dan gebeurt het… voor het technisch applicatiebeheer wordt een service provider ingeschakeld, die de applicatiesoftware rechtstreeks van de ontwikkelaar krijgt. Maar al te vaak komt het dan voor dat de software niet zonder tussenkomst van de ontwikkelaar te installeren is op de acceptatieomgeving, de integratie met de bestaande it-architectuur van de klant niet op orde is en de installatie- en beheer-documentatie onvolledig zijn.
Wat vindt de klant daarvan? Die zal weinig begrip opbrengen voor de kwalitatieve argumenten van de serviceprovider die het technisch applicatiebeheer uitvoert. Immers, de business heeft de functionaliteit nú nodig en dat mag natuurlijk niet worden gefrustreerd door het ontbreken van documentatie of een achterblijvende performance. Kortom, spanning tussen de klant en de service provider.
Dit verschijnsel kan worden voorkomen door tijdens het ontwikkelproces de provider die het technisch applicatiebeheer gaat uitvoeren al mee te laten kijken. Dit moet ervoor zorgen dat de softwareontwikkelaar niet alleen functionaliteit oplevert, maar ook de benodigde kwalitatieve en beheeraspecten gelijktijdig met het eindproduct oplevert. Hierna zal de service provider de software formeel moeten accepteren op deze technische aspecten. Kortom het uitbesteden van technisch applicatiebeheer vergt een volwassen softwareleverancier, service provider en een klant die zowel de business als zijn ict-partners weet te managen.
Jan Willem,
Technisch applicatiebeheer laat zich vaak heel wat moeilijker uitbesteden dan je doet veronderstellen omdat deze beheerders vaak een brugfunctie hebben. En je legt ook nogal makkelijk de problemen bij een ander door te stellen dat als het niet werkt dit ligt aan onvolwassen processen.
Maar je ging dan ook al bij je intro de mist in door een vergelijk met de Fyra te maken omdat ik sterk de indruk krijg dat ook hier behoorlijk geblunderd is op bestuurlijk niveau. Ik vraag me dus af hoe het ook al weer ging bij RBS, die hadden technisch applicatiebeheer geloof ik ook uitbesteed en daar gingen de updates niet geheel lekker.
Bij de NEN wordt een praktijkrichtlijn voor het overdragen van software systemen ontwikkeld (NPR 5325). Daarin worden best practices beschreven om bovenstaande problematiek te vermijden.
Maar inderdaad, het is zoals Ewout zegt, niet gemakkelijk dat uitbesteden.
“applicatiesoftware rechtstreeks van de ontwikkelaar”
Dan gaat het waarschijnlijk niet om een grote mainstream leverancier. Heb je dan al niet zelf gekozen voor een Fyra ?
@JanWillemvandenBos Het is een bekend probleem dat bij overzetten van ontwikkelde software naar beheer problemen optreden. Niet voor niets is DevOps een term die in is. Betrek beheer bij het ontwikkelingsproces.
Dat is een mijn grote twijfels die ik heb het outsourcen van ontwikkeltrajecten en ook nog het beheer. Zeker als dat meerdere partijen zijn, het is een garantie voor de problemen die je omschrijft. Ik denk dat voor een goed lopende project de lijnen tussen gebruikers, ontwikkelteam en beheer zo kort mogelijk zijn. Alles wat er tussenzit werkt verstorend en zeker als de verhouding tussen die drie geformaliseerd is dan kan je je lol op. Ik zie het al helemaal weer voor me, over ieder issue, wijziging moet er eerste door heel veel hele dure mannen in een hok vergaderd worden: want wat is het nu, een bug, een change een request en de allebelangrijkste vraag: wie gaat het betalen?
De problemen die jij beschrijft is denk ik ook geen probleem van applicatiebeheer maar van hoe een project georganiseerd is.
Wie alleen kijkt naar functionaliteit, maar niet naar de voorwaarden om die functionaliteit optimaal te kunnen laten functioneren, is niet slim bezig. Ik kan niet beoordelen of de NS haar huiswerk goed heeft gedaan, noch of de AnsaldoBreda de juiste vragen heeft gesteld of adviezen heeft gegeven. Ik zie wel dat er wederzijds een verschil van mening is als het gaat om oorzaak en gevolg van het onderpresteren van de Fyra in de praktijk van het Nederlandse spoor.
Op het Italiaanse spoor schijnen ze al jaren zonder noemenswaardige problemen te rijden. Misschien dat men eens goed had moeten bekijken welke factoren daar aan bijdragen en welke zaken er in Nederland dan anders geregeld hadden moeten worden om dezelfde performance te krijgen.
Het grote verschil met de vergelijking met technisch applicatiebeheer is dat men hier een product heeft gekocht dat al bestond. Juist daarom was de NS in staat geweest alle ins en outs te bekijken en te beoordelen of dit product in de Nederlandse setting aan de verwachtingen zou kunnen voldoen.
Als je dat nalaat vraag je om problemen.
Wat betreft de Fyra ben ik het eens met de stelling dat er geblunderd is op bestuurlijk niveau. Het Fyra debacle heeft diverse oorzaken. Wat ik heb willen belichten zijn de paralellen met technisch applicatiebeheer. Mijn ervaringen leren mij dat zaken die tijdens softwareontwikkeling (releases, patches, fixes) te weinig aandacht hebben gekregen, binnen de discipline van technisch applicatiebeheer, naar boven komen. Een juiste procesgang en het vroegtijdig betrekken van het technisch applicatiebeheer bij ontwikkeling (zoals Louis ook aangeeft) kan deze problemen voorkomen.
Dat betekent ook dat uitbesteden prima kan, maar dan wel als hiervoor de juiste processen worden ingericht. Juist bij uitbesteden wordt kristalhelder welke processen aanwezig zijn en welke ontbreken. Immers, de ontwikkelaar kan geen wijzigingen meer kan doorvoeren tijdens installatie en oplevering. De technisch applicatie beheerder moet zich beroepen op de aangeleverde code, documentatie en configuratie. Juist de scheiding tussen ontwikkelaar en beheer kunnen voor een verbetering van de kwaliteit van het ontwikkelproces zorgen.
Overigens gaat het bij technisch applicatiebeheer juist over beheer van bestaande applicaties, waarmee de paralell met de Fyra valt te trekken. Als de NS zich meer had verdiept in de technische aspecten van de Fyra inclusief te beoordelen of dit product in de Nederlandse setting aan de verwachtingen zou kunnen voldoen, was een deel van het probleem al in een eerder stadium aan bod gekomen. Punt is dat al je je alleen richt op de functionele vraag en aspecten zoals de fixes, patches en releases niet meeneemt in de bouw, risico loopt op vervelende issues. Ik bepleit dan ook juist de activiteit die hk in het tweede deel van zijn reactie aangeeft, namelijk éérst alle ins en outs bekijken en de impact hiervan te beoordelen vóórdat er ontwikkeld wordt.
Zie ook: http://www.nu.nl/binnenland/3592095/ook-softwaregebreken-nekten-fyra.html#
Wat is technisch applicatiebeheer is mijn eerste vraag. Systemen up and running houden zou ik zeggen. Zolang dat puur hardware/systeem software matig is, kan dat volgens mij voor iedereen gedaan worden. Kijk maar naar de cloud.
Wat ik me al jaren afvraag is, wie het gat tussen zeg functioneel Beheer en technisch Beheer gaat dekken. Een gemiddelde functioneel beheerder kent de applicatie als een black box. En de technisch applicatiebeheerder ziet de applicatie als een instance op zijn machine.
Wie zou de kennis van batches, installatie, eigenaardigheden van de applicatie alemaal moeten hebben? Simpel gezegd, wie weet hoe een applicatie werkt.
DEVOPS? Alleen als we dat letterlijk gaan nemen. Beheer en ontwikkeling gaan echt samen werken.
Hoe je het ook regelt of noemt (ik heb trouwens een hekel aan de nieuwe kreten die de IT steeds weer verzint) zorg dat mensen samen gaan werken.