Rapid Application Development (rad) stelt de IT-industrie in staat beter te voldoen aan de eisen en verwachtingen van gebruikers. Helaas heeft de hype het weer eens gewonnen van de feiten. Er is op dit moment op grote schaal rad-gereedschap te koop, maar dat is niet zozeer geschikt voor applicatie- als wel voor programmaontwikkeling. Tussen het ontwikkelen van applicaties en programma’s bestaat namelijk een groot verschil!
Serieuze ontwikkelaars proberen al jaren de levenscyclus van applicaties te definiëren en te implementeren, maar zijn daarbij niet altijd even succesvol. Toen de PC massaal aansloeg is er veel veranderd, in sommige opzichten ten goede, maar in andere opzichten ten kwade.
De PC maakte grafische editors mogelijk, zodat veel ontwerpfuncties geautomatiseerd konden worden. Denk aan logische analyse, het modelleren van relaties tussen entiteiten enzovoort. De eerste op terminals gebaseerde systemen waren goed voor eenvoudig programmeerwerk en tekstverwerking, maar niet voor de grafische kwaliteiten van front-end case-tools. De PC bracht ons het concept van de ‘programmer’s workbench’. Programma’s werden op individuele PC’s ontwikkeld en daarna op het doelsysteem geladen, gecompileerd en getest. Door simulatoren te gebruiken, volstond één workbench voor het ontwikkelen van versies voor verschillende doelsystemen, al is dit concept nooit maximaal benut.
De PC werd in toenemende mate gebruikt in client/server-architecturen en was als zodanig ook nodig om de applicatiecode op te kunnen draaien. In tegenstelling tot het workbench-principe moest de ontwikkelde client-code gebruik maken van het grafische user interface (gui). De meeste applicaties die met workbenches op PC’s werden ontwikkeld, gebruikten de grafische mogelijkheden alleen voor de ontwikkeltools, terwijl de uiteindelijke applicatie vaak karaktergeoriënteerd was. In de begindagen was dit erg ingewikkeld en was er een hoop lager programmeerwerk in C nodig, maar al snel ontstonden er betere tools. Met deze tools kon men het gui interactief ontwerpen en kon een eenvoudige tekstverwerker in de context van de gui worden opgestart, dit alles in één product.
Met C++ en Ole maakten deze tools het gebruik van bibliotheken met componenten mogelijk, die waren gericht op het creëren van fraaie en (helaas) te complexe gui applicatie-interfaces. De marketing van deze tools was zo succesvol dat ze al snel bekend stonden als rad-tools.
Helaas waren de gui rad-tools programmeertools in plaats van applicatieontwikkeltools. Het case-concept stelde de applicatie centraal; ontwerp, logische consistentie, systeemanalyse, coderen, testen, geïntegreerd testen, documenteren en onderhouden. Het is er nooit helemaal van gekomen, en dat kwam vooral door het gebrek aan standaarden voor repositories, waarmee de verschillende tools onderling hadden kunnen samenwerken. De gui rad-tools zijn in feite Rapid Program Development tools.
Bij de gui rad-tools is alle aandacht gericht op de applicatie die op de client PC draait. Hierdoor moet het hele programma door één persoon worden ontwikkeld. Voor teamwerk is modularisatie van code echter noodzakelijk. Terugkijkend moeten we concluderen dat het dikke client rad-concept wel tot grote problemen moest leiden. (En ik moet zeggen dat ik dat altijd al gevonden heb.) Het is een goed concept voor eenvoudige applicaties; in de handen van een goede projectleider misschien ook nog voor kleine tot middelgrote applicaties; maar voor complexe applicaties is het een ramp. Vooral applicaties die door de hele onderneming worden gebruikt, hebben als gevolg van hun complexiteit een lange levensduur. Zulke applicaties worden voortdurend geactualiseerd en gecorrigeerd, in de meeste gevallen door iemand die de code in eerste instantie niet geschreven heeft.
De geschiedenis leert ons dat ongeveer 50 procent van het IT-budget wordt besteed aan het onderhouden van bestaande applicaties. Slechts 20 procent wordt uitgegeven aan het ontwikkelen van nieuwe systemen. Elk concept dat het programmeren goedkoper maakt maar wel leidt tot hogere onderhoudskosten, leidt uiteindelijk tot hogere applicatiekosten. Dit wordt nog verergerd door het hoge aantal storingen dat optreedt als goede demo’s, die ontwikkeld zijn met behulp van gui rad-tools (perfect voor prototyping), niet uitgroeien tot volwassen productiesystemen.
De oplossing is een combinatie van gebruiksvriendelijke gui-tools en het levenscyclus-concept van case-tools. Er zijn enkele volledig geïntegreerde case-tools op de markt, zoals Forte en Dynasty, maar van het dunne client-model verwacht ik nog de meeste heil.
Eenvoudige gui rad-tools zijn prima in staat een gui ‘look-and-feel’ en eenvoudige lokale verwerking te creëren. Deze tools verwijzen naar de echte business-code, maar integreren deze code niet in het PC-programma. Om de applicatiecode op de server te ontwikkelen – met inbegrip van testen, performance, beveiliging, transactiediensten en dergelijke – kunnen krachtige multi-user case-tools worden gebruikt. De client-code kan worden ontwikkeld met Visual Basic of Java, en er zijn inmiddels ‘professionele’ versies van Microsofts Visual Basic en IBM’s Visual Age die het werken in teams en het hergebruik van code ondersteunen.
