RAD avontuur

MS Access en VB zijn niet voor niets zo razend populair geworden: ze stelden de ontwikkelaar in staat om relatief zeer snel een applicatie te bouwen die er qua UI (User Interface) zeer gelikt uit zag.
In sommige gevallen begon een applicatie als goedbedoelde hobby van mensen in de business afdeling, in andere gevallen was het vanaf het begin een product van de IT afdeling.
Snel en dus goedkoop werd er iets praktisch in elkaar gezet. De problemen begonnen pas later toen er onderhoud aan gedaan moest worden. In veel gevallen bleek dat extreem tijdrovend en dus duur te zijn. Regelmatig zelfs zo tijdrovend dat het geheel vervangen werd door een nieuwe applicatie, waarbij hetzelfde probleem ontstond als er onderhoud en uitbreiding nodig was.

De kans bestaat dat u er nooit goed achter bent gekomen wat nu eigenlijk deze problemen met het onderhoud veroorzaakten. Misschien heeft u gedacht aan de volgende oorzaken:
  • Geen documentatie?
  • Geen helder analyse en ontwerp op voorhand?
  • Zijn mijn ontwikkelaars toch niet hoog genoeg opgeleid?
  • Geen duidelijke project management methode?

Veel van deze applicaties zijn gebouwd met een RAD (Rapid Application Development) aanpak, gebruikmakend van een technisch platform dat RAD goed ondersteunt (zoals MS Access of Visual Basic).
Bovenstaande pijnpunten kunnen zeker een rol gespeeld hebben in uw nachtmerrie, maar boosdoener nummer één is de structuur, of beter gezegd het gebrek aan een heldere structuur.
Hoewel Microsoft al jaren theoretische propaganda maakt voor de multi-tier structuur (gescheiden lagen voor database-access, business- en applicatie logica en UI logica), laat ze in haar populaire demo’s met destijds VB 6 en recentelijk met het .NET platform, telkens de verkeerde voorbeelden zien. Ook in de meeste populaire demo’s met VisualStudio.NET (waarmee C# client-server en ASP.NET web applicaties gebouwd worden) worden ontwikkelaars telkens weer verleid om vanuit de UI laag rechtstreeks contact te maken met de database. De nieuwste versie van ASP.NET heeft hier nog meer faciliteiten voor gekregen. Deze aanpak lijkt eigen te zijn aan RAD. Het gevolg is dat er helemaal niets in huis komt van een multi-tier structuur. Er ontstaat spaghetti code in de schermen waarin data-acces-, business- en UI code als een onontwarbare kluwen door elkaar lopen. Trots zal de ontwikkelaar u tonen hoe razendsnel hij een nieuw schermpje kan bouwen. Maar als het geheel wat complexer wordt, bijvoorbeeld doordat static security ingebouwd moet worden (beschikbare functionaliteit afhankelijk van de identiteit van de gebruiker) of nog erger, doordat dynamische security plotseling nodig blijkt te zijn (beveiliging ook afhankelijk van de data inhoud), dan ontstaat met veel moeite een instabiel product dat zeer slecht te onderhouden is. Wat begon als snel en dus goedkoop, eindigt dan gemakkelijk als een gedrocht dat extreem duur is in onderhoud.
Dit soort frequent voorkomende problemen in het verleden zijn mede de oorzaak van de huidige populariteit van grote standaard pakketten zoals SAP en Oracle aanbieden. Dit ondanks hun vaak bijzonder ongelukkige UI, slechte performance en starheid, terwijl we juist flexibel wilden zijn vanwege de voortdurend veranderende wereld....