Drie tekenen dat je applicatie op sterven ligt

Maar het zomaar vervangen is vaak niet aan de orde. Liever nog los je de problemen op zonder dat de boel ingrijpend verandert. Dat speelt bij applicaties meer nog een rol dan bij andere onderdelen van je ict-omgeving.

Veel ict-afdelingen schieten door in dat aanpassen, tweaken en daarmee prolongeren van het huidige applicatiegeheel, zo schrijft journalist en applicatiespecialist Paul Venezia in een recente blogpost. Het constant willen rekken van de levensduur van applicaties leidt volgens hem tot "een vicieuze cirkel van slechte ideeën en nog slechtere implementaties". Zijn pleidooi: durf een moment uit te kiezen waarop je geheel overnieuw begint.

Dat is gemakkelijker gezegd dan gedaan. Bij dit zogeheten application lifecycle management (ALM) komt immers meer kijken dan alleen de vraag 'hoe lang werken we al met deze applicatie en kunnen we hem afschrijven?'.

'Oud' en 'verouderd'

Volgens Roderick Schoon en Jasper Gilhuis, respectievelijk cto en lead architect bij Delta-N, is het bijhouden van de levensduur van een applicatie door de jaren heen veelomvattender geworden. Delta-N is gespecialiseerd in applicatie-ontwikkeling en applicatiebeheer. "Het beheren van applicaties op deze manier is niet echt nieuw", zegt Schoon. "Wel is het de afgelopen jaren beter geïntegreerd. Het is de development ontstegen."

"Er is meer tooling om het complete proces te managen", voegt Gilhuis toe. "De nadruk ligt meer op het geheel." ALM, zo zeggen de twee, begint bij de eerste ideeën voor een applicatielandschap, en eindigt op het moment dat deze wordt vervangen. "Je houdt het gehele verouderingsproces in de smiezen, niet alleen de code", zegt Schoon. "Ook je testscripts en je documentatie moet je beheren, net als de bugs en wijzigingsverzoeken."

Ook bestaat er een belangrijk verschil tussen oud en verouderd als het gaat om applicaties. Een applicatie kan al jaren zonder problemen draaien. Het is niet zo dat het prestatieniveau opeens uit zichzelf achteruit holt. De veroudering treedt pas in als het bedrijf er daadwerkelijk hinder van ondervindt.

Wat zijn de tekenen dat een applicatie verouderd is? Schoon en Gilhuis geven een paar voorbeelden.

Platform eronder

Voor ontwikkelaars is het platform waar een applicatie op draait, de onderliggende technologie dus, het meest voor de hand liggende teken dat een applicatie verouderd is. "De applicaties van bijvoorbeeld tien jaar geleden zijn al wel webapplicaties", zegt Gilhuis. "Maar je zit dan nog wel in de eerste fase van webtechnologie." Schoon: "We komen bijvoorbeeld applicaties tegen die via ASP en scripting gewoon direct html aan het genereren zijn. Code, database access en formatting, en business rules zijn door elkaar heen gegooid. Pas later zijn de frameworks en de architecturen ontstaan."

"Als het op Windows 3.11 draait, dan durf ik mijn hand in het vuur te steken dat het een verouderde applicatie is", grapt Schoon. Maar ook applicaties die op het klassieke ASP draaien, zijn meer dan slechts oud. "Als het niet meer ondersteund wordt, dan is het verouderd. Vroeger had je bijvoorbeeld C en C++, nu is het vooral C#, ASP.Net en Silverlight."

"Wij krijgen bijvoorbeeld wel eens applicaties onder beheer die gebaseerd zijn op Microsoft Content Management Server uit 2001", zegt Schoon. "Veel klanten werken met verouderde Microsoft-platformen, waarmee configuratie en instellingen gedaan zijn, een website gemaakt is, of waarmee maatwerk gemaakt is." Producten dus die niet meer bestaan. "Als je daarmee naar Microsoft zou stappen, dan krijg je denk ik te horen dat je maar naar Sharepoint moet overstappen."

Steeds moeizamere wijzigingen

De tekenen voor een bedrijf dat een applicatie misschien in zijn geheel aan vervanging toe is, kun je niet 1-2-3 zien aankomen. Een applicatie kan immers jarenlang probleemloos draaien. "Je gaat het pas herkennen als een wijziging niet zo makkelijk meer gaat als voorheen.", zegt Schoon. "Dat zijn de eerste signalen. Een applicatie kan op een verouderd platform draaien, en het nog steeds prima doen. Maar op een gegeven moment krijg je toch een economische veroudering, waarbij het meer tijd en geld kost om een verandering door te voeren."

"Stel je voor dat je ooit een workflow in een webapplicatie gebakken hebt die je niet meer kunt aanpassen. Als je deze een paar jaar later moet uitbreiden met bijvoorbeeld een bkr-controle (Bureau Krediet Registratie) voor het verstrekken van hypotheek, dan kan dat niet meer in de applicatie zelf. Je moet dan handmatige acties gaan ondernemen om het geautomatiseerde proces goed te laten verlopen", zegt Schoon.

"Je gaat dan met een losstaand proces, bijvoorbeeld batchbestandjes, twee andere processen aan elkaar knopen", voegt Gilhuis toe. "Het eigenlijke probleem omzeil je. Dat is de technische ducttape die je gebruikt."

Mode

"Maar uiteindelijk is veroudering ook een soort van mode", zegt Schoon, die daarmee aangeeft dat signalen van gebruikers ook op een veroudering kunnen duiden. "Gebruikers hebben meer wensen dan voorheen. Misschien is een bepaalde verandering niet per sé nodig, maar vinden ze toch dat de gebruikte applicatie verouderd is. Je adres niet kunnen opzoeken op Google Maps of de Microsoft-variant is voor veel gebruikers al verouderd."

En ook hier komt ALM volgens de twee om de hoek kijken. "Je ziet steeds meer wijzigingen die klein in urgentie zijn, maar groot in impact. Wensen van de gebruiker, ook als ze 'mode' zijn, horen ook bij ALM. Nu kan het triviaal zijn, maar over twee jaar is het een must."

De artikel is onderdeel van een special waarin Webwereld dieper ingaat op aspecten van applicatie infrastructuur.