Instructions: Intégration d'applications existantes à des architectures modernes
Ces instructions présentent une vue d'ensemble des stratégies permettant de moderniser des "systèmes en vigueur" en les intégrant à de nouvelles applications.
Relations
Description principale

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 :

Restreinte

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.

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.