Elke applicatie moet om te beginnen volledig gespecificeerd zijn. De business rules moeten vervolgens formeel vertaald worden in een format dat toegesneden is op een implementatie middels computers.
Dat leidt tot gegevens ontwerpen en tot specificaties voor de applicatieprogramma’s die nodig zijn om de applicatie te implementeren. Zo lang mijn herinnering strekt wordt er in de it-bedrijfstak al gedroomd van software tools die dat proces kunnen automatiseren. Natuurlijk is er best wat vooruitgang geboekt, maar de ideale, geïntegreerde Case tools blijven een illusie. Om de ontwikkelaars van dit soort gereedschappen recht te doen: er bestaat bij de applicatieontwikkelaars weerzin om dat concept ingang te doen vinden. Al was het maar omdat bij de ontwikkeling van een omvangrijke applicatie nogal wat mensen betrokken zijn, waarvan er geen bij machte is een methodologie op te leggen. Het gevolg is dat al te weinig ontwikkelaars het geringe aantal hulpmiddelen gebruikt en dus blijven ze duur. Maar al ter vaak lijkt het budget nodig voor de aanschaf van geavanceerde ontwikkel-tools ontzettend hoog, en is het lastig om dat bedrag af te wegen tegen het aantrekken van meer programmeurs.
Prototyping is een van de meest gebruikelijke technieken die aangewend worden om het ontwikkelproces van applicaties te verbeteren. Maar helaas creëert dat evenveel problemen als het oplost, waarvan velen zelfs ernstig te noemen zijn. Er is een groot verschil tussen een onderhoudbare zakelijke applicatie en een prototype, iets dat helaas niet vanzelf spreekt voor een eindgebruiker. Erger nog: het is zelfs niet duidelijk voor de enthousiaste nieuwe programmeur, die de ervaring mist om te weten dat een probleem oplossen meer resources kost dan het gelijk goed doen.
Het feit dat we kennelijk niet in staat zijn te accepteren, is dat gereedschappen om onderhoudbare code te ontwikkelen fundamenteel verschillen van tools voor rapid prototyping. Gereedschap voor prototyping en vergelijkbare gereedschap voor proof of concept exercities moet makkelijk in het gebruik zijn, interactief en zwaar overleunen naar het beeld dat de eindgebruiker te zien gaat krijgen. Maar de uiteindelijke applicatie zal een lang leven beschoren zijn en zal voortdurend in onderhoud blijven bij een team van mensen, in de loop van de jaren waarschijnlijk verschillende mensen. De uiteindelijke applicatie moet een goede performance bieden en schaalbaar zijn tot aan een groot aantal gebruikers, waar twee waarschijnlijk voldoende is voor een prototype. Om een applicatie te ontwikkelen die schaalbaar is is een andere architectuur vereist dan bij een prototype. De problemen waarmee client/server applicaties te kampen hebben zijn gemeengoed geworden. Een thin client applicatie, met alle applicatielogica en de grafische presentatie daarvan in het gebruikersinterface (gui) op één pc is betrekkelijk makkelijk als een prototype te ontwikkelen met behulp van Visual Basic, Delphi of vergelijkbare hulpmiddelen. De beschikbaarheid van componenten om te helpen bij het bouwen van gebruikers-interfaces overbelicht de echte waarde van het concept. Het ziet er erg goed uit voor de gebruiker en de inventieve ontwikkelaar zonder ervaring. Maar zo’n architectuur betekent dat alle multi-user aspecten als het vergrendelen van records extreem moeilijk zijn op te lossen. Bovendien zal er nogal wat netwerkverkeer ontstaan, omdat immers elk pc-werkstation een kopie van de gehele applicatie moet hebben. Als dezelfde applicatie behoorlijk ontworpen zou zijn, dan gaat een groot deel van de inspanning op aan performance tuning bij een zware belasting. Eén aspect daarvan is het reduceren van de netwerkbelasting, en een ander het delen van gemeenschappelijke programmacode op de server. Aandacht verdient ook het hoofdstuk recovery en het afhandelen van fouten. Foutcorrectie bij het invoeren van data is essentieel in een productie-applicatie, maar niet nodig in een prototype. Samenvattend heeft een finaal productontwerp te maken met beveiliging, netwerk performance, recovery en andere onderwerpen die eenvoudigweg buiten beschouwing blijven bij een prototype.
Als we ooit een situatie bereiken waar Case-tools usance worden, zijn we meteen van het probleem af. Zulke tools zijn namelijk in staat een eenvoudige versie af te scheiden voor prototyping en dan een volledige versie als het ontwerp aanvaard is. Maar dat duurt nog wel even. Dus moet de oplossing tot die tijd maar zijn dat voor prototyping en voor ontwikkeling verschillende gereedschappen worden ingezet; en dat wordt niet in de gehele bedrijfstak geaccepteerd. Het betekent het bouwen van een prototype om de goedkeuring te verkrijgen van de zakelijke ontwerpers, om vervolgens op basis daarvan het uiteindelijke product te bouwen. Dat lijkt vrij recht-toe-recht-aan, maar dat is het toch niet. Het probleem blijft toch dat geen enkele ontwikkelaar of programmeur toegerust kan worden met alle tools en met alle aspecten van een applicatie. De dominante technieken zijn nog immer gebaseerd op ‘dikke’ clients, wat betekent dat de ontwikkelaar een specialist moet zijn in gui’s, business logica, databankontwerp en netwerken. De beschikbare tools zijn de laatste tijd beter geworden, maar ondersteunen nog immer niet de teamaanpak die gebruikelijk is in de gevestigde bedrijven voor gegevensverwerking.
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.
