Introduction
Les systèmes vitaux, souvent appelés "systèmes en vigueur", de nombreuses grandes entreprises sont souvent enfouis dans
de volumineuses applications monolithiques sans interface standard et développées dans de vieux langages informatiques,
comme le COBOL. La plupart de ces entreprises veulent tirer profit d'Internet, de l'intranet, du commerce électronique
et d'autres nouvelles technologies pour rester compétitives. Cependant, récrire ces systèmes en vigueur clés n'est pas
toujours une option viable du point de vue financier (trop onéreux) ou technique (les programmeurs d'origine ne sont
plus dans la société) ou pour des raisons de délai (impossible d'attendre). L'alternative choisie par de nombreuses
entreprises est de moderniser leurs "systèmes en vigueur" en les intégrant à de nouvelles applications.
La méthode d'intégration de ce type la plus courante est souvent appelée Intégration d'applications d'entreprise et consiste à implémenter une infrastructure
de communication entre les différentes applications de l'entreprise, anciennes et nouvelles.
Stratégies d'intégration de systèmes en
vigueur
L'intégration de systèmes en vigueur peut-être divisée en deux catégories principales :
Les stratégies restreintes sont celles qui ne modifient pas l'application en vigueur et n'effectuent que des
modifications mineures. Cette stratégie est la moins onéreuse, mais également la moins flexible. Cette approche est
généralement utilisée lorsque l'intégration d'applications d'entreprise est effectuée au niveau interface utilisateur, au niveau données ou parfois au niveau interface d'application.
Lorsque l'intégration est effectuée au niveau interface utilisateur, les écrans basés sur du texte existants sont
remplacés par des écrans de type navigateur intégrés à un portail d'entreprise. Si ce type d'intégration est souvent
considéré comme instable et archaïque, il est parfois le plus pratique pour intégrer des systèmes en vigueur ne
fournissant pas d'accès au niveau processus métier ou au niveau base de données.
L'intégration au niveau données peut être effectuée soit en réutilisant la base de données existante soit en extrayant
les données de la base de données existante pour mettre à jour une nouvelle base de données en utilisant une solution
d'extraction/transformation/chargement. Si cette approche peut sembler attractive, elle est parfois difficile à
implémenter car la transformation des données, les contraintes et les contrôles sont souvent implémentés dans la
logique métier des applications existantes.
L'intégration restreinte au niveau interface d'application, également appelée encapsulage d'éléments existants, peut
offrir davantage de flexibilité. Dans le cadre de cette approche, vous générez des interfaces de programme
d'application pouvant être appelées autour des transactions existantes. Dans la mesure où cette approche tire parti des
transactions existantes, elle n'est pas très onéreuse et évite les désavantages de l'intégration au niveau données. En
transformant les transactions en interfaces de programme d'application, cette approche permet une meilleure flexibilité
que l'intégration au niveau utilisateur. Cependant, pour rester restreinte, cette approche ne peut pas être utilisée
pour modifier ou améliorer des fonctions métier car ces actions nécessitent une approche non restreinte.
Une stratégie non restreinte implique que vous avez besoins de modifier le code fonctionnel existant. Bien sûr, ce type
d'approche présente davantage de risques et est plus coûteux car le code existant est généralement ancien et mal
documenté et les programmeurs l'ayant écrit sont rarement disponibles. Il est cependant celui qui offre le plus de
flexibilité et qui vous permet de modifier et d'améliorer les processus et fonctions métier. Cette approche est souvent
utilisée avec l'intégration d'applications entreprise au niveau interface d'application lorsque vous avez besoin d'interfaces de programme
d'application qui ne correspondent pas aux transactions existantes. Cette approche peut également être utilisée avec
une intégration d'applications d'entreprise au niveau méthode, mais la restructuration du code existant pour fournir des méthodes
partagées est souvent trop coûteuse.
Une des approches non restreintes d'intégration au niveau interface d'application est appelée "e-composants existants".
Cette approche consister à diviser l'application existante en un ensemble de composants métier autonomes. Chaque
composant publie un ensemble clairement défini d'interfaces de programme d'application qui facilite le passage d'une
connectivité programme à programme rigide à une approche basée sur les messages plus souple pouvant être déployée sur
plusieurs plateformes et intégrée à l'architecture globale avec des modèles de composants appropriés. Cette approche
peut être affinée pour définir chaque e-composant existant en tant qu'un ou plusieurs services d'une architecture SOA,
en utilisant les services Web. Voir Concept : Introduction à l'architecture SOA.
Dans la mesure où les approches non retreintes sont généralement plus coûteuses et plus risquées au niveau de
l'architecture que les approches restreintes, envisagez d'adopter une approche itérative pour réduire les risques et
démontrer la faisabilité de l'architecture lors des premières itérations.
|