157
© Groupe Eyrolles
Chapitre 4
L’architecture ERP-centrique 1
L’objet essentiel de ce chapitre est de construire une architecture applicative, à
partir de la modélisation réalisée au chapitre précédent. Le responsable de la spécification système doit aller au-delà des modèles et proposer une architecture physique, tant au point de vue des matériels que celui des logiciels.
L’intérêt d’une architecture est de définir des couches qui peuvent être physiquement substituées par de nouvelles couches en fonction des évolutions des normes
et standards. De telles substitutions entraînent forcément des évolutions dans les
couches supérieures, essentiellement des mises à jour, sans remettre en cause le
fondement applicatif.
Certes, la communauté des éditeurs de progiciels a mis en place une structure normative pour une standardisation des applications. Il s’agit de l’Open Application
Group (OAG) créée en 1995, dont font partie de nombreux éditeurs du marché.
L’intérêt de l’utilisateur est, certes, de suivre les résultats des travaux de ce groupe
et leur mise en application par les acteurs du marché, cependant, il demeure indispensable que l’entreprise utilisatrice maîtrise, de son côté, l’architecture de son système applicatif, car une grande partie s’appuie sur des fondements normatifs de
l’informatique générale. Par ailleurs, il est indispensable de recentrer l’architecture
1. L’ERP, en tant qu’outil de production de l’entreprise, au même titre que les couches de base, dont
celles du réseau local, conditionne le modèle d’architecture. L’auteur se permet ce néologisme
anglais, ERP-centric tout comme certains spécialistes du marketing ont introduit LAN-centric conduisant, dans notre jargon informatique, aux barbarismes LAN-centré ou Réseau-centré. Alors
pourquoi ne pas utiliser ERP-centrique ?
© Groupe Eyrolles
Chapitre 4
L’architecture ERP-centrique 1
L’objet essentiel de ce chapitre est de construire une architecture applicative, à
partir de la modélisation réalisée au chapitre précédent. Le responsable de la spécification système doit aller au-delà des modèles et proposer une architecture physique, tant au point de vue des matériels que celui des logiciels.
L’intérêt d’une architecture est de définir des couches qui peuvent être physiquement substituées par de nouvelles couches en fonction des évolutions des normes
et standards. De telles substitutions entraînent forcément des évolutions dans les
couches supérieures, essentiellement des mises à jour, sans remettre en cause le
fondement applicatif.
Certes, la communauté des éditeurs de progiciels a mis en place une structure normative pour une standardisation des applications. Il s’agit de l’Open Application
Group (OAG) créée en 1995, dont font partie de nombreux éditeurs du marché.
L’intérêt de l’utilisateur est, certes, de suivre les résultats des travaux de ce groupe
et leur mise en application par les acteurs du marché, cependant, il demeure indispensable que l’entreprise utilisatrice maîtrise, de son côté, l’architecture de son système applicatif, car une grande partie s’appuie sur des fondements normatifs de
l’informatique générale. Par ailleurs, il est indispensable de recentrer l’architecture
1. L’ERP, en tant qu’outil de production de l’entreprise, au même titre que les couches de base, dont
celles du réseau local, conditionne le modèle d’architecture. L’auteur se permet ce néologisme
anglais, ERP-centric tout comme certains spécialistes du marketing ont introduit LAN-centric conduisant, dans notre jargon informatique, aux barbarismes LAN-centré ou Réseau-centré. Alors
pourquoi ne pas utiliser ERP-centrique ?