28 octobre 2006

Processus métier : de la modélisation au design

Mode traditionnel
Dans un mode client-fournisseur, ou MOA-MOE, le travail de l'architecte SI en terme de modélisation des processus revient à dessiner les processus existant ou à mettre en oeuvre avec un formalisme BPMN ou UML2 (par exemple, selon les usages dans l'entreprise).

Dans un projet en mode MOA-MOE, l'architecte porte donc le stylo-BPMN et réalise les diagrammes des processus métier et leur accostage (impacts sur les applications, sur les flux, sur les bases de données) sur le SI.

Mode collaboratif : de la modélisation au (co-)design
Mais la proposition de l'architecte SI se situe en réalité plus en avance de phase. La modélisation a posteriori (systèmes existant) ou en aval des spécifications de besoins dans un cycle en V (projet en cours) doit laisser la place à une collaboration lors du design des processus futurs, en cours de développement ou de refonte.

La réflexion conjointe et transverse de l'architecte SI, des utilisateurs et des personnes en charge du projet conduira naturellement à la réconciliation entre les besoins initiaux, le plus souvent exprimés par les acteurs métier, et les apports supplémentaires (goodies ?) apportés par la technologie employée (ou proposée) qui pourront être traduits en besoin complémentaires.
L'innovation métier s'allie donc à l'innovation technique.

Si de plus le business plan de l'entreprise est basé sur l'économie numérique, vous gagnerez en parts de marché, incontestablement.

Illustration
Lors de la reprise d'un processus l'architecte signale que le client online pourrait voir s'afficher dynamiquement le contenu de son panier et des suggestions complémentaires d'achat en utilisant AJAX sur la SOA mise en place lors des précédents travaux de refonte. Ensemble ils redéfinissent le processus d'achat en diminuant le nombre de clics pour valider le panier ou pour obtenir des articles simplement depuis d'autres zones du catlogue.
Cette illustration n'est pas vraiment innovante, mais elle permet de comprendre le lien entre apports métier et apports technologiques. L'architecte SI met en regard ces deux univers (j'ai même souvent employé l'expression "réduction du fossé métier-SI"), rend plus transverses les processus, aussi bien au niveau métier qu'au niveau SI.

23 octobre 2006

J2EE ? avec discernement

Vous avez déployé une infrastructure J2EE et vous souffrez pour vos performances ?
Vous avez lu les tests de performance de J2EE et vous êtes refroidi ?

Normal.

J2EE n'est pas lent, il en fait juste beaucoup... parfois même un peu trop.

J2EE repose avant tout sur une promesse de fiabilité et de sécurité. Et cela a un coût, payé par les performances. Les serveurs devront être "musclés", et les applications taillées avec attention. Et ce que vos intégrateurs ou éditeurs de serveur d'application font le plus souvent, sans discernement, c'est vous servir du J2EE sous prétexte que la "Standard Edition" n'est pas pour l'entreprise, à l'inverse de l' "Enterprise Edition". Songez que pour eux c'est surtout la promesse d'une réutilisation maximale.

Etudiez votre besoin

Si vous n'exploitez pas les possibilités offertes par J2EE, alors restez sur des solutions ad-hoc en J2SE, au risque d'assister à une dégradation des performances et une augmentation de vos coûts de possession.
L'architecture J2EE n'est pas une mauvaise architecture, loin s'en faut (voir mon précédent article "Java LA plateforme"), mais elle ne s'adresse pas à tous.

Quelques illustrations :
- La plupart des développements J2EE se font en écrivant le minimum de code grace à la richesse de la plateforme. Conséquence évidente, la généricité (du code déjà écrit) en fait un système moins performant (mais plus évolutif) qu'un système au design spécifique.
- Les EJB sont entièrement pris à la charge de la plateforme, ce qui induit un risque sur la charge et les performances, surtout si on utilise les API de persistance. De plus il existe des spécificités d'implémentation qu'il faudra prendre en compte en cas de passage d'un server applicatif J2EE à un autre.
- JSF (et Struts pour ceux qui y sont encore) induisent des indirections et l'usage de beaucoup d'objets pour gérer les contextes de la session et des invocations de services, en échange d'une excellente évolutivité de la plateforme. Ce que vous ne payez pas dans vos développements et tests, vous le payez en performance.

- Plus lointain de J2EE mais à considérer tout de même, les Web Services. L'usage de XML sur HTTP est un frein à la performance mais réduit les temps d'intégration et les risques de dysfonctionnement aux interfaces de vos systèmes. La SOA est bonne pour la fiabilité, mais à étudier de près pour les performances.

Bilan

J2EE semblera peu performant à qui ne fait pas usage d'une majorité des fonctionnalités proposée. Pour celui qui utilise sa puissance, alors c'est une très bonne plateforme, même si un réglage fin des performances reste obligatoire.
Mais surtout, regardez de près : parfois, un simple développement J2SE suffit, même en environnement distribué.

Dernier point : quoi que vous fassiez, privilégiez la sécurité avant tout, avant les performances, et jamais "dans un deuxième temps", comme on entend souvent.