Les architectures de référence ont pour but de définir les choix technologiques par type d’applications et par couches (si l’on veut bien admettre qu’à l’heure d’aujourd’hui les architectures sont nécessairement multitiers) : quelles technologies pour les clients légers et quelles technologies pour les clients lourds par exemple, ou bien quelle (idéalement au singulier) technologie pour l’accès aux bases de données relationnelles. Ou encore quelles technologies pour le mode batch ou quelles technologies pour le mode événementiel.

Mais les architectures de référence ne devraient pas s’arrêter là. Trop souvent les choix s’opérent sur une base essentiellement technique, en négligeant les critères économiques. Il est ainsi fréquent qu’au nom de la stabilité en production par exemple, la productivité des développeurs, avec son impact sur les temps et coûts de réalisation, soient fortement négligés. Ceux-ci sont alors obligés de faire avec des moyens trop rudimentaires en regard des impératifs de budget et de délai. Au risque, soit, dans le pire des cas, de devoir remettre une offre qui fait perdre un marché, soit de ne pas pouvoir respecter ces deux contraintes.

Les architectures de référence gagneraient donc à intégrer cette dimension économique. Et, par exemple, faire la différence entre d’une part, les contraintes liées à un portail public qui hébergent des dizaines ou des centaines d’applications stables du point de vue fonctionnel (24 X 24, 7 X 7, avec des milliers d’utilisateurs), dont le taux de disponibilité est une contrainte majeure, et d’autre part quelques applications métiers départementales (8 X 24, 5 X 7, avec quelques dizaines ou centaines d’utilisateurs), urgentes souvent, dont les efforts de maintenance seront importants.

Des intersections subsisteront, certes, mais certains aspects mériteront des différences.

En jouant sur les extrêmes, faites donc la différence entre une approche sur la seule base JSPs et sur une approche en vous appuyant sur un outil tel que WaveMaker par exemple.