|
| |
| Infrastructure/Chantiers |
| Les
progiciels peuvent-ils vraiment s'adapter à une architecture
orientée services ? |
| L'émergence des services Web et de la vision orientée processus des systèmes d'information conduit les éditeurs de progiciels (CRM, ERP...) à non plus seulement proposer une alternative à l'hétérogénéïté, mais bien à s'adapter à elle. Quel chemin leur reste t-il à parcourir ? (Mardi 15 avril 2003) |
 |
Opposer progiciels et modules
applicatifs spécialisés n'est semble t-il
plus de mise: à l'ère des Web Services,
se dégage un modèle d'architecture où
les premiers agissent non plus comme un tout cloisonné,
se suffisant à lui-même, mais bien comme
une plate-forme applicative intégrant des composants
(objets métiers) "maisons", mais aussi
capable de s'ouvrir sur des composants extérieurs.
Faire
avec l'augmentation de "l'entropie des SI"
Mais employer le terme "plate-forme applicative"
peut induire en erreur. Sur le modèle "traditionnel"
trois-niveaux, centré sur le serveur d'application
- lequel a pour fonction stricto sensu de distribuer
des composants sur un réseau - tend à se
greffer l'approche basée sur le service applicatif.
Très schématiquement, il s'agit d'invoquer
telle fonctionnalité d'une application A, telle
autre d'une application B, etc., et d'orchester ensuite
(en les faisant communiquer, en les enchaînant suivant
une logique appropriée...) ses "services".
Ainsi,
l'accent est mis résolument sur l'intégration,
ce qui revient à reconnaître que, naturellement,
les systèmes d'information évoluent vers
plus d'hétérogénéité,
exactement comme un système physique voit son entropie
croître, mesurant l'augmentation de son degré
de désordre.
Par "plate-forme applicative", on entend donc
avant tout "plate-forme d'intégration",
à savoir la capacité à bâtir
non seulement un portail cohérent de services (Web),
mais également à gérer les interactions
de ces derniers. Ainsi, on observe chez les grands éditeurs
de progiciels une tendance à se libérer
du "tout intégré" pour adopter
une architecture plus proche de ce qui vient d'être
décrit.
Changement de stratégie
Stratégiquement, les éditeurs de serveurs
d'applications vont d'ailleurs dans le même sens,
en mettant en avant d'une part leurs ateliers de développement
(et donc, in fine, leur capacités d'ouverture
et d'intégration), d'autre part leurs liens avec
des outils de construction de portails, qu'ils soient
de la même gamme (IBM Websphere, BEA Weblogic...)
ou tiers.
Mais revenons aux progiciels: les éditeurs proposant
ce type d'outils ne se placent pas sur le terrain de l'infrastructure
serveur, mais sur celui de l'applicatif métier.
A ce titre, ils apparaissent en position de faiblesse
par rapport notamment aux spécialistes de l'EAI,
du BPM, de la modélisation/conception logicielle,
mais bénéficient à l'inverse d'une
légitimité liée à leur connaissance
de la réalité fonctionnelle de secteurs
spécifiques. Ils sont ainsi mieux à même
de parler "processus" (circulation de l'information,
chaîne de validation...) que les acteurs de l'intégration
applicative, lesquels sont plutôt attendus sur le
traitement des "flux".
Pourtant, s'il semble naturel que les éditeurs
de solutions d'EAI (voir notre
dossier) communiquent autour de la gestion des processus,
il est moins facile pour un éditeur de progiciels
de parler de flux d'intégration. En effet, s'ouvrir
vers l'extérieur (par exemple en publiant ses fonctionnalités
sous forme de services Web, mais aussi et surtout en garantissant
l'interopérabilité de ceux-ci avec ce que
propose d'autres fournisseurs) impose une remise en question
radicale des choix qui présidaient historiquement
à la constitution des progiciels: en d'autres termes,
là où on offrait un ensemble "tout
en un" paramétrable, dans le but de simplifier
la vie de l'utilisateur, mais aussi de dissuader les clients
d'aller voir ailleurs, il s'agit maintenant de proposer
une machinerie laissant le choix à l'utilisateur
de s'affranchir de certains modules fournis par l'éditeur
du progiciel, pour en choisir d'autres.
Les exemples de SAP et de Siebel
Et de fait, la nature même des progiciels a longtemps
empêché ceux-ci d'être véritablement
"orientés processus": configurables,
verticalisés, modulaires, voire même modélisables
en services orchestrables, certes, mais proposant de véritables
outils de gestion souple des processus, notamment lorsque
ceux-ci doivent être relayés par des flux
interapplicatifs, non.
Récemment, néanmoins, des acteurs comme
SAP sur le terrain des ERP ou Siebel sur celui du CRM
(mais ce ne sont pas les seuls) assument la "contradiction
de l'ouverture" propre aux éditeurs de progiciels.
Le premier, avec NetWeaver (regroupant... un serveur d'applications
et des outils d'intégration basés sur un
référentiel d'objets métiers) et
plus largement l'architecture ESA (Entreprise Services
Architecture) personnifie ce mouvement de fond qui pourrait
toucher l'ensemble du monde des progiciels. Le second,
avec d'une part la fourniture dans Siebel 7.5 de processus
prémodélisés (baptisés "meilleures
pratiques") et d'autre part la stratégie UAN
(Universal Application Network) de partenariats avec des
fournisseurs de solutions d'EAI, entend également
permettre de capitaliser sur l'existant en introduisant
de la cohérence autour, là aussi, d'un référentiel
d'objets métiers.
Méritoires, ces premiers efforts restent encore
incomplets, pas tant du fait des éditeurs eux-mêmes,
d'ailleurs, que du degré de maturité des
technologies qui vont permettrent de réaliser informatiquement
la vision d'une orientation service. Pour ne rappeller
qu'un seul des problèmes qui se posent sur ce terrain,
citons l'absence de standard établi pour orchestrer
les services Web (malgré certaines initiatives).
Par ailleurs, un processus (vu ou non comme l'enchaînement
de services applicatifs) se doit de pouvoir être
optimisé, ce qui passe (voir à ce sujet
la
chronique de Jean-François Pirus) par la modélisation,
la simulation et le contrôle de la performance,
toutes opérations non réalisées en
propre (ou de manière limitée) par le progiciel,
fut-il de la nouvelle génération décrite
ici.
La voie de l'architecture
orientée service sera t-elle prise par l'ensemble
des acteurs du monde du progiciel (ce qui n'est pas le
cas aujourd'hui) ? Sans doute, si d'une part l'industrie
peut s'accorder sur des socles standards, et si d'autre
part, la stratégie des pionners s'avère
payante. De ce dernier point de vue, l'approche qui consiste
à tirer profit de l'existant autant que possible,
plutôt que se hasarder dans l'implantation d'un
bloc monolithique, devrait de fait séduire les
clients dans un contexte de contrôle des coûts
et de méfiance vis à vis des projets "big
bang".
|
|
|
 |
[