Vorige week beweerde ik dat er een belangrijk verschil bestaat tussen een prototype en een productiesysteem. Vanwege dit verschil is het onmogelijk om softwaretools te maken die ideaal zijn voor zowel het prototype als het uiteindelijke systeem; er moet een compromis gezocht worden.
Ontwikkelaars kunnen twee extreme uitgangsposities innemen Er kan gekozen worden voor een ontwikkelomgeving die geacht wordt aan beide eisen te voldoen, of er kunnen twee aparte ontwikkelsystemen gebruikt worden, de een ideaal voor prototyping, de ander voor productie. Beide hebben hun voor- en nadelen.
Het eerste concept, dat gebruikelijk is voor client/servertoepassingen, is gemakkelijker te gebruiken, maar levert oplossingen die problemen leveren op het gebeid van stabiliteit, prestaties en onderhoud. Het naïeve gebruik van ontwikkelomgevingen voor gui-pc-applicaties leidde tot de vele problemen die we nu tegenkomen bij dikke-clients-ontwerpen. Gebruiksgemak, met name van het ‘front-end’ van de gui, leidde ertoe dat ontwerpers geen oog hadden voor de noden van productiesystemen, zoals netwerkprestaties en herstel. Niet zozeer de tools op zich waren fout, maar het gebruik ervan. Zulke tools kunnen ideaal zijn voor het ontwikkelen van het client-gedeelte van een dunne-client-applicaties, terwijl andere meer geschikte tools gebruikt zouden kunnen worden voor het ontwikkelen van de code voor de server-kant.
Het tweede alternatief lijkt het beste, maar vergt twee ontwikkelteams. Bovendien vergt het begrip en samenwerking van de verschillende ontwikkelaars; de prototypeontwerper richt zich op de behoeften van de gebruiker terwijl de ontwikkelaars van productiesystemen zich op de technische kant richten. De prototypeontwikkelaars kunnen veel alleen doen, maar applicatieontwikkelaars moeten in teams werken.
Er is momenteel geen ideale oplossing. Het betekent dat we nog steeds een praktische implementatie van het case-levenscyclusmodel nodig hebben. Als het ontwerp kan worden vertaald naar een prototype, kan het goedgekeurde ontwerp automatisch worden gegenereerd als productiesysteem. Met deze mate van automatisering hoeven er geen compromissen gesloten te worden en zullen de beste prototyping- én ontwikkeltools automatisch worden gebruikt. Ook zijn zo verschillende architecturen te gebruiken. Met deze benadering is het concept van herbruikbare componenten het best te introduceren. Dezelfde technieken zijn al de norm voor hardware-ontwikkeling; waarom zijn we zo traag in het opnemen van softwarecomponenten voor gui-interfaces?
Als we naar de huidige situatie kijken, wordt het duidelijk dat het probleem eerder in de mensen schuilt dan in de technologie. Met iedere uitgebreide business-applicatie zijn veel mensen gemoeid: van gebruikers tot onderhoudspersoneel.
De programmeurs van oude mainframes waren vaardig in het omgaan met tp-monitoren en complexe file-structuren. Als gui-interfaces in beeld kwamen, wisten ze van niets, en de meesten vonden dat ze al genoeg te doen hadden. En zo verscheen er een nieuwe generatie programmeurs die experts werden op het gebied van gui-interfaces maar niets over buisness-transacties wisten. In plaats van samen te werken, ontwikkelden zich twee antagonistische scholen. Het kostte IBM inderdaad vijf jaar om de geschikte software te lanceren voor het implementeren van een dunne-clientmodel waarin een gui-pc-client toegang kon krijgen tot cics-transacties op de host. Wat een ramp! Gebruikers moesten het dientengevolge stellen met karakter-interfaces of nieuwe pc-netwerkapplicaties laten ontwikkelen. De pc-programmeurs wisten niet beter en probeerden systemen op basis van ‘file-sharing’ te ontwikkelen, merendeels Novell Netware.
Een dergelijke blunder lijkt tegenwoordig onvoorstelbaar, maar het toont eens te meer hoe stom het is om niet samen te werken, en om niet op een gecoördineerde wijze gebruik te maken van de beste vaardigheden. Tien jaar later maken we nog steeds veel dezelfde fouten, hoewel minder ernstig.
Er is een groot verschil tussen gebruik maken van een leverancier van applicatiepakketten of een inpandig ontwikkelteam. Er is absoluut geen excuus voor een ontwikkelaar van pakketten om niet gebruik te maken van de best beschikbare tools. Het moet een mengeling van ontwerp-, prototyping- en productietools zijn. Dezelfde overweging geldt bij grootschalige ontwikkeling binnen het bedrijf, maar de meeste inpandige ontwikkeling is gericht op kleinere applicaties. Het is moeilijk om de voordelen van het gebruik van een pc-gebaseerd rad-systeem (rapid application development) te ontkennen, maar wanneer moet die worden vervangen?
Martin Healey, pionier ontwikkeling van op Intel gebaseerde computers en c/s-architectuur. Directeur van een aantal it-bedrijven en professor aan de Universiteit van Wales.
