De l'importance du langage commun
Dans le cadre d'un projet SOA, il est primordial de s'attacher à la création d'un langage métier commun entre les métiers et l'informatique. C'est la clé de l’agilité. Au delà de l'amélioration des outils d'infrastructure ou de l’ajout de nouvelles fonctions évolués dans un PGI, c'est la définition de ce langage qui permet l'adaptation rapide des processus et donc une plus grande réactivité des entreprises aux changements. Ce langage commun doit être utilisable entre l'informatique et les métiers mais aussi entre l'entreprise et ses fournisseurs informatiques, l’entreprise et son écosystème (partenaires, clients).
Il est également intéressant de noter que les éditeurs de progiciels, les éditeurs d’infrastructure et les intégrateurs se rejoignent sur cette nécessité.
- Chez les Editeurs de Progiciels
Les éditeurs de progiciels, comme SAP ou Oracle, sont bien placé pour aborder la sémantique métier. Ils développent une stratégie double : d'un coté continuer leur investissements dans la définition de processus fonctionnels communs et du langage métier associé (dans une approche transverse (HR, Finance, ...) ou verticale (Automobile, Pétrole,...), de l'autre promouvoir une infrastructure qui permette de supporter des processus particuliers par composition facile des services. Avec cette approche, les éditeurs de PGI tentent de contrôler l'ouverture de leurs progiciels intégrés (une boite noire) vers une architecture de services ou un service est remplaçable à la volée par un service concurrent. Ils proposent une infrastructure qui permet d'intégrer des composants externes en respectant l'existant. Par exemple, un DRH pourra facilement intégrer un module de recrutement externe à l'environnement HCM de l’ERP.
Pour les entreprises qui ont lourdement investi dans la mise en place d’un ERP et qui n'envisagent qu'une évolution progressive sur la base de leurs investissements actuels, cette approche est séduisante.
- Chez les Editeurs d'Infrastructure
De l'autre coté de la barrière, les fournisseurs de solutions d'infrastructure (IBM, BEA, Tibco,...) défendent une approche inverse. Ils fournissent l'ensemble des services d'infrastructure qui permet de supporter les processus métier de l'entreprise. Les services proposés supporte une intégration à tous les niveaux- le bus d'entreprise, les meta data, l'interface utilisateur, l'orchestration des services. Capitalisant sur des expériences dans les domaines applicatifs, ces éditeurs se spécialisent dans des industries (IBM et la banque, Tibco et les utilities, BEA et les telcos,...) et proposent des services et des composants plus adaptés au domaine et répondant directement aux préoccupations spécifiques des clients industrie (réduction du churn des clients telco, vue unique du client bancaire, gestion du risque pour les clients utilities).
Ici, cette approche est séduisante pour les entreprises qui ont investie dans une solution d'infrastructure et qui envisage une évolution progressive sur cette base.
C’est peut-être les intégrateurs qui courent le plus grand risque dans cette évolution. Historiquement, les intégrateurs ont vendu des forces techniques capables de programmer et mettre en œuvre des logiciels techniques (langages, base de données, EAI,…). SOA chamboule cet équilibre. La demande des clients évolue vers un plus grand support de leur processus et une plus grande connaissance de leur métier. Les bataillons de développeurs à tout faire des sociétés de services vont devoir évoluer en des équipes commando, spécialistes de l’implémentation des règles de Bâle II dans un système d’information bancaire ou du dossier médical unique dans la branche santé. Cette évolution pose quelques problèmes car à la différence des éditeurs, les intégrateurs doivent jongler entre la connaissance des solutions des fournisseurs et le domaine du client et ses spécificités.
Libellés : SOA
permalink
Abonnement