L'articulation entre métiers et TIC est un des enjeux de l'informatique, récurrent depuis les origines. C'est là que peut se jouer l'efficacité d'un SI. Le dialogue entre les métiers de l'entreprise et son informatique doit pouvoir s'appuyer sur un outil de modélisation type BPEL (cf VendrEDI n°82), mais d'abord sur une définition des règles de business auxquelles il sera fait référence dans un modèle. Ces règles de métier sont du type IF-THEN-ELSE, et ressemblent donc aux règles des langages de programmation. Sauf qu'elles sont exprimées en langage courant (anglais) et peuvent donc être facilement utilisées par les businessmen pour codifier la logique de leurs opérations et permettre ensuite aux dévelop-peurs de prendre la suite avec la logique de leurs langages de programmation. Qui peuvent alors respecter la logique des "fonctionnels" des métiers.

C'est l'objectif des outils de BRMS (Business Rules Management System) qui se répandent : à côté de sociétés spécialisées, Microsoft devrait inclure un "Business Rules Framework" dans la version 2004 de BizTalk. Les avantages d'un BRM se situent aussi bien au stade de la conception que de la maintenance. Plutôt que d'être pendu au téléphone, le côté business, une fois sa modélisation "réglée", peut passer commande au côté TIC qui peut passer aux tests et à la production du code. Et en cas de modification de ces régles des métiers, les fonctionnels compétents peuvent les traduire logiquement eux-mêmes, sans attendre la disponibi-lité des développeurs (mais avec peut-être, quand même, une certaine aide de leur part ;-). Si ça marche, le coût de conception et de maintenance sera réellement moindre et on peut espérer que les régles métiers seront bien implantées correctement. Mais, en fait, un BRMS a un domaine d'application utile à considérer avec précaution : d'une part les PME "mono-métier" n'en ont guère la justification, et d'autre part les ERP ou les CRM des grandes entreprises contiennent déjà, en principe, un outil de gestion des règles. En revanche, toute nouvelle application développée en entreprise justifie un BRMS, surtout si la nouvelle application doit rester autonome. Et mettre à plat les règles des métiers de l'entreprise peut, en soi, être parfois très utile !

L'orientation de tous les grands offreurs vers un apaisement bienvenu de leurs conflits sur les standards des Services Web (SW) vise à répondre à l'attentisme des utilisateurs qui, en attendant ce cessez-le-feu, en sont restés à ce qui marche, et notamment à l'EDI traditionnel. Et à propos de ce qui marche, en plus de standards réconciliés, les utilisateurs ont aussi besoin de comprendre comment les SW pourront se raccorder à leurs applications existantes, traitées par leurs gros ordinateurs, ou à des fonctions gérées directement par ces  mainframes. D'où l'intérêt commun aux offreurs d'outils de SW et aux offreurs de mainframes à expliquer ensemble comment relier ces  deux types d'outils. Selon eux, SW et main-frames doivent être considérés comme complé-mentaires dans le cadre de l'architecture SOA qui va gouverner les SI orientés services (cf. les VendrEDI n°75 et n°80).

Non seulement les SW sont l'outil d'avenir de l'EAI (Enterprise Application Integration), mais ils présentent aussi un grand avantage pour une intégration directe Web-to-mainframe : les SW permettent non seulement un accès aux données, mais aussi aux application processing or func-tionality. Ce que l'EDI traditionnel fait moins bien, faute en particulier de SOAP et d'un langage de description des services comme  WSDL dont Edifact n'a pas les fonctionnalités.

Mais architecture "orientée services" ne signifie pas que toutes les applications doivent être ouvertes : ce n'est pas utile pour toutes. De plus la qualité des services offerts par les "grosses bécanes" doit être protégée et ne doit pas être compromise par une "ouverture". Avant de brancher directement des SW sur le mainframe, des ESB seront utilisés (cf VendrEDI n°82). Et l'intégration progressive, avec XML, avec les SW, avec la publication sur un portail etc. est une marche raisonnée vers la SOA, et non un "grand soir". Avec une "feuille de route" claire : choisir les applications éligibles, définir le sous-ensemble de leurs données à transporter vers une autre application, vers un portail ou sur le Web, en déduire le schéma XML, correspondant et implémenter les outils WSDL et SOAP nécessaires.

En fait, les vraies difficultés ne seront pas techniques mais humaines : la culture des services informatiques quelquefois barricadés autour de leur gros ordinateur n'est pas celle des Services Web, dont la culture devrait mieux se partager entre TIC et responsables métiers et aussi mieux relier l'ancien et le nouveau dans les TIC elles-mêmes.