Les EAI :

1. Les EAI : Structuration de la communication dans les systèmes d’information

2. Objectifs du cours • Découvrir et comprendre les concepts et les enjeux de l'intégration d'applications via les EAI, • Connaître les différentes technologies de mise en œuvre, • Balayer les offres d'outils EAI du marché.

3. Sommaire • Point de situation de la plupart des SI • La notion d’urbanisation «naturelle», • Cas réel de cartographie applicative, • Les besoins d’évolution vers les EAI • Définitions et composition d’un EAI • Les principes généraux, • Les solutions techniques et les outils complémentaires, • La sécurité et les EAI, • Revue des différentes architectures EAI possibles, • Projet d’implantation d’un EAI • Structure de projet et points clés • Quelques cas clients • Le marché des EAI • Conclusions • Avantages et inconvénients des EAI, • Quelle(s) relation(s) future(s) entre ERP et EAI ?

4. L’urbanisation «naturelle» Ou Comment en sommes-nous arrivés là ?

5. L’urbanisation «naturelle» • Les SI se sont construits par ajouts successifs d’applications, • Les besoins de communications entre applications  développements des interfaces, • L’absence de réflexions sur l’ensemble de l’architecture du SI a conduit : AU MODELE SPAGHETTI

6. Présentation d’un cas réel • Reprenons le schéma d’architecture applicative réelle d’un équipementier automobile, déjà vu lors du cours sur les ERP.

7. Divisions / Division pneumatique Division Électronique Divers Directions : Électronique Pneu- matique Négoce de pièces Réparation Unités : Câblerie Capteurs Transmissions (cartes & ordinateurs) Lignes Pneu- matique Réparation Pignons Capteurs Électronique Câblerie autonomes : électronique Carters Montage Réparations Sites : Site 1 Site 2 Site 2 Site 2 Site 2 Site 2 Site 2 Activité : Série Série Série Série Série Rechanges Rechanges Rechanges Rechanges Rechanges Réparations Réparations Réparations Réparations Négoce Exemple d’un système d’information et ses interfaces Organisation / structure de l’entreprise

8. Cartographie applicative du site n°1 SGDT Articles Nomenclatures GPAO Macro gammes Commerce Planification Achats Stocks Atelier Articles agréés En cours Commandes Ordre Fabrication Réceptions du jour PIC / PDP Factures fournisseurs Articles Nomenclatures Expéditions OF Mouvements BR Activité Catalogue QUALITE Imputations Prix standards manuel Exped. Prix standards manuel Comptabilité Industrielle Éléments Paie PRESENCE Facture VENTES PAIE Personnel Gestion des Formations Paie CO FI TR Imputations Virements fournisseurs Virements Paie Comptabilité Générale (ERP 4) Contrôle Accès TRESORERIE Banques

9. Cartographie applicative du Site n°2 SIGA Paye Notes de frais Gestion Réparation Saisie d’activité MS Project Projets/ressources Qualité Pic /Plan dir. de prod. Saisie d’activité E déplacement GPAO Gestion de projet MRP Processus Négoce ? Stocks Achats Prod. Commerce Activité Reporting Prod Manager Gestion de config. Création / Màj Article GENEC CEC FISS E Proc. (TradeXpress) SIBA Compta (générale, analytique, auxiliaire) Facturation Contrôle facture Controlling Achats divers Module de comptabilité Interface

10. Traitement “classique” par interfaces spécifiques ou par EDI : Échange de Données Informatisées

11. Rappels sur l’EDI : l’ancêtre des EAI • EDI = Electronic Data Interchange ou Échange de Données Informatisées : • Échanges, d’ordinateur à ordinateur, de données concernant des transactions, en utilisant des réseaux et des formats normalisés, • Transit des informations de l’émetteur vers le système d’un partenaire (via des réseaux) afin d’y être intégrées automatiquement.

12. Standards EDI • Les standards d’organisations • UN/EDIFACT : United Nations / Electronic Data Interchange For Administration, Commerce and Transport • ANSI - American National Standards Institute • ASC - Accredited Standards Committee • X12 - order placement & processing, shipping & receiving information, invoicing, payment & cash application data • Certains industriels ont créé leur propres normes : • industrie automobile = norme ODETTE, • industrie aéronautique : norme AECMA.

13. Architecture EDI Récepteur Emetteur application application Fichier interne Fichier interne Si même ERP Logiciel de traduction EDI Logiciel de traduction EDI Message EDI Message EDI Logiciel de comm. Logiciel de comm. Réseau

14. Message EDIFACT Structure UNB UNH BGM I n t e r c h a n g e M e s s a g e 1 RFF NAD DTM EDI Enveloppe Détails Article(LIN) Ligne 1 Article 8712345678913 Type EN Quant. 4 ...... ...... LIN LIN LIN ...... UNT UNH Message 2 ...... UNT UNZ

15. Exemple de message EDIFACT EDI Message UNB+UNOA:2+5412345678908:140801:1201' UNH+1+ORDERS:2:901:UN:EAN005' BGM+105+112233+950730' RFF+CT+123456+910101' RFF+CR+MR. BLOCK' NAD+DP+8711886500001:14' NAD+IV+8711886599001:14' DTM+002+060120' CUX+DEM:PC' FTX+PUR+1++PLEASE DEL.BEFORE 13.00' TDT++++++EMS' TOD+++FCA' UNS+D' LIN+1++8712345678913:EN++21:4' LIN+2++8710477100104:EN++21:2' IMD+F+++HANDLE THIS ITEM WITH CARE' UNS+S' UNT+16+1' UNZ+1+12345555' Explications Boîte “Enveloppe” émettrice du message. Entête du Message; type de message Message I.D. Programme No & Date etc.. Détails Contrat Détails Acheteur Adresse de livraison Adresse de facturation Date de livraison requise Devise Texte libre Conditions de livraison Détails Article ,, Texte Article Fin d ’ordre Fin du Message

16. Les inconvénients de l’EDI • Mise au point longue entre deux partenaires, à répéter à chaque fois • Batch (la plupart du temps), • Liaison point par point  autant de liens que de partenaires qui conduit : AU MODELE SPAGHETTI

17. Application 1 Application 8 Application 2 Application 7 Application 3 Application 6 Application 4 Application 5 Le syndrome spaghetti 8 applications = 28 interfacesN(N-1)/2

18. Les raisons d’évolution vers les EAI

19. L’évolution des SI (1/3) • Facteurs de changement : • mutation incessante des marchés et des pratiques commerciales • exigence de réactivité accrue à tous les niveaux de l’organisation, • banalisation des produits - érosion de la fidélité clients • besoin de différenciation des marques, • croissances externes, fusions, partenariats • besoin de flexibilité des S.I., de consolidation des données, de cohérence stratégique.

20. L’évolution des SI (2/3) • Développement historique du parc applicatif des entreprises : • budget et conception à un niveau départemental  urbanisation «naturelle», • limites technologiques au moment de la conception, • succès des technologies Client/Serveur, • applications légères centrées sur une base de données dédiée, • confort d’exploitation d’un réseau local.

21. L’évolution des SI (3/3) • Besoins d’intégration & avènement de standards autour d’Internet : • globaliser de la chaîne de valeur de l’entreprise : ERP, SCM, CRM, BI, PLM, … • éviter les coûts d’une refonte de S.I. <-> développer rapidement le e-business, • s’appuyer sur l’existant et s’affranchir de son hétérogénéité, • disposer, de manière permanente, des ses systèmes de commerce électronique.

22. Émergence de nouveaux applicatifs«périphériques» : 3 exemples

23. En synthèse : pourquoi un EAI ? (1/2) Convergence de faits technologiques + évolutions économiques : • Spécialisation des applications, • Ouverture des ERP, • Explosion des intranets et des portails, • Applications CRM, SCM et e-business, • Refonte des processus métier : • réduction de leur durée de vie, • souplesse guidée par le besoin de modifier ses règles métiers, • recherche d’automatisation de ses processus.

24. En synthèse : pourquoi un EAI ? (2/2) • Vitesse d’évolution des entreprises (S.I. pas assez réactifs), • Recherche du meilleur logiciel répondant à un besoin donné et au coût moindre (+«clé en main»), • Contraintes d’intégration d’applications d’autres sociétés (achats, fusions ou restructurations), • … • Conclusion : nécessité d’intégrer l’ERP ou l’ensemble des composants du SI (source des données opérationnelles internes à l’entreprise)  avec les autres applications internes et/ou externes à l’entreprise via un EAI.

25. Les EAI :Ou …La mort annoncée du concept «Spaghettis» …

26. Application 1 Application 8 Application 2 Application 7 Application 3 Application 6 Application 4 Application 5 Rappel du syndrome «spaghettis» 8 applications = 28 interfacesN(N-1)/2

27. EAI Ce que propose l’EAI ? Application 1 Application 8 Application 2 Application 7 Application 3 Application 6 Application 4 Application 5

28. Le déport de l’interfaçage vers l’EAI Application Reste dans Application Logique Applicative Ordonnancement Extraction EAI L’interface est déporté dans Transformation Émission Routage Suivi des flux

29. EAI : définition • L'objet de l'EAIEnterprise Application Integration = intégration des applications de l'entreprise : • c’est l'intéropérabilité et l'organisation de la circulation de l'information entre des applications hétérogènes, • c'est faire communiquer les différentes applications de l'entreprise, voire même celles des partenaires (clients, fournisseurs, sous-traitants, co-traitants, …) • Un projet d'EAI consiste : • à mettre en place une architecture de communication entre les différentes applications, • à développer des connecteurs (middleware) permettant d'interfacer des applications utilisant des protocoles de communications différents, • Au-delà de l'intéropérabilité entre applications, l'EAI peut, aussi, permettre de définir un Workflow entre applications.

30. Finalité d’un EAI : «fluidifier, simplifier et structurer» les échanges entre applications

31. Les objectifs d’un EAI • Un outil d’EAI n’intervient pas dans le fonctionnement interne des applications maîtrisant les fonctions et règles métier • Il permet : • de transmettre des données d'une application source vers une application destination (avec transformation éventuelle), • de fédérer progressivement les échanges et les flux entre applications, • de connecter de nouvelles applications à un «bus» d’échange unique en fonction des besoins d’interfaçage, • d'orchestrer le déroulement des processus métier via: • l'organisation de l'exécution des composants du SI impliqués dans le processus, • la prise en charge des interactions entre ces composants, • de mettre en œuvre des règles d’urbanisation d’un SI.

32. Principes générauxd’un EAI

33. Principe général d’un EAI • Applications existantes et futures pouvant communiquer entre elles et partager des informations de façon simple efficace, • Utilisation d'un bus de communication en lieu et place de communications directes d'application à application.

34. Les périmètres fonctionnels impactés Place de marché Privée - publique Commerce électronique Comparateurs Moteurs de recherche Datawarehouse décisionnel BI Clients CRM - ERP Connaissance KM, archivage Fournisseur SCM - EDI EAI Téléphonie Nomades, PDA Vendeurs SAV Siège ERP Back - office Point de vente Front - office Dépôts - Usines logistique

35. Les périmètres techniques impactés

36. Les trois types d'intégration Orchestration d’un ensemble de tâches à effectuer par différentes applications avec ou sans intervention humaine Intégration au niveau des processus métier Orientation métier Basée sur des logiciels de messagerie orientés réseau (solution EAI + complète), avec produits de middleware orientés messages (MOM) Intégration au niveau des applications Échange et partage des données applicatives via base de données commune, XML (Extensible Markup Language) particulièrement utile pour l'intégration applicative inter-entreprise, Intégration au niveau des données Complexité technique

37. Exemple d'intégration au niveau des données EAI propose un point d'intégration unique au travers de son bus de communication

38. Les outils EAI d’intégration au niveau des données • Les outils EAI d’intégration de données proposent : • des services de transformation de données, • la sécurisation et la fiabilisation des échanges, • l’utilisation de connecteurs standard d'accès aux sources de données, • Mais ils court-circuitent la couche métier et les règles de gestion ne sont pas vérifiées dans les transferts, • Exemple : base de données avec données stockées incluant des règles de gestion (appartenance à un gpe). L’intégration niveau données ne tient pas compte de cette couche et se connecte directement à la base de donnée  atteinte d’intégrité des données (vue métier).

39. Les trois types d'intégration Orchestration d’un ensemble de tâches à effectuer par différentes applications avec ou sans intervention humaine Intégration au niveau des processus métier Orientation métier Basée sur des logiciels de messagerie orientés réseau (solution EAI + complète), avec produits de middleware orientés messages (MOM) Intégration au niveau des applications Échange et partage des données applicatives via base de données commune, XML (Extensible Markup Language) particulièrement utile pour l'intégration applicative inter-entreprise, Intégration au niveau des données Complexité technique

40. Intégration au niveau des applications L’intégration au niveau des applications consiste à utiliser les API métier pour faire communiquer les systèmes.

41. Exemple d'intégration au niveau applicatif Manipulation des données sécurisée puisque règles métier interposées lors des traitements.

42. Remarques sur l’intégration au niveau applications (1/2) • L’intégration au niveau des applications est un bon départ en vue d’une exposition des API métier  Web Services • Mais l’intégration de la couche métier n'est pas toujours aisée : • toutes les applications ne fournissent pas des API métier, • les applications anciennes des environnements centralisés sont souvent des blocs monolithiques sans notion de couche, • notamment, leurs seules interfaces sont constituées de grilles d'écran, • un important travail de restructuration est souvent nécessaire en préalable à toute intégration d’applications, • La couche de présentation gère l’interface utilisateur avec les systèmes, cette couche peut constituer un point d'intégration potentiel (intégration au niveau «écran») = revamping applicatif pour EAI.

43. Remarques sur l’intégration au niveau applications (2/2) • Même un API métier disponible n’est pas toujours directement exploitable tel quel : • protocoles de communication propriétaires  création d'une sur-couche d'adaptation, • Stabilité des API applicatifs dans le temps car : • c’est le point d'entrée de l'intégration, • une modification interne dans une application ne doit, théoriquement pas, entraîner une modification de l’API métier, • si tel est le cas  lourdeur de la gestion de l’intégration au niveau applicatif, • Mode synchrone en request/reply, non recommandé plutôt un mode asynchrone court dans lequel l’EAI se charge d’appeler l’API.

44. Intégration au niveau des processus métier • Intégrations au niveau données et applications focalisées sur aspects techniques de l'intégration, • Intégration au niveau des processus métier = une approche fonctionnelle de l’intégration d’applications, • Ce sont les processus métier qui pilotent l’intégration.

45. Les trois types d'intégration Orchestration d’un ensemble de tâches à effectuer par différentes applications avec ou sans intervention humaine Intégration au niveau des processus métier Orientation métier Basée sur des logiciels de messagerie orientés réseau (solution EAI + complète), avec produits de middleware orientés messages (MOM) Intégration au niveau des applications Échange et partage des données applicatives via base de données commune, XML (Extensible Markup Language) particulièrement utile pour l'intégration applicative inter-entreprise, Intégration au niveau des données Complexité technique

46. Exemple d'intégration au niveau des processus métier

47. Intégration au niveau desprocessus métierBPI (Business Process Integration) • BPI = concevoir des processus métier et de les relier aisément aux applications sous-jacentes, • Les produits de BPI utilise un moteur d'orchestration connaissant les étapes & données du processus et chargé : • de l'aiguillage des flux de données dans le cadre des processus métier, • du suivi de l'état d'avancement de chaque processus, • d’activer des alertes en cas de déviation du fonctionnement.

48. Les outils EAI d’intégrationau niveau des processus métier • Les produits de BPI proposent : • un support natif de certains processus classiques (briques élémentaires prédéfinies et configurables), • la combinaison de plusieurs briques = un processus métier, • un outil de modélisation graphique les agrége, • sur cette base, le logiciel de BPI se charge : • de générer automatiquement le code nécessaire aux interactions entre les actions élémentaires, • et de donner les instructions au moteur pour exécuter les processus définis.

49. En résumé • En complexité croissante, les différents types d’intégration sont : • l’intégration au niveau des données (transmission de données avec des transformations éventuelles d’une source à une destination), • l’intégration au niveau des applications (utilisation d’API métier pour transférer ou intégrer des flux de données), • l’intégration au niveau des processus métier (orchestration d’un ensemble de tâches à effectuer par différentes applications avec ou sans intervention humaine).