Toujours partir du besoin métier – Pas dune envie de linformatique Concevoir les services – puis concevoir leur implémentation Le vrai bénéfice est.

Présentation au sujet: "Toujours partir du besoin métier – Pas dune envie de linformatique Concevoir les services – puis concevoir leur implémentation Le vrai bénéfice est."— Transcription de la présentation:

1

2

3

4 Toujours partir du besoin métier – Pas dune envie de linformatique Concevoir les services – puis concevoir leur implémentation Le vrai bénéfice est dans la valeur économique apportée – pas la réutilisabilité de composants Démarrer petit et prioriser – ne pas faire « bouillir locéan » Sattendre à des changements – Ne pas les éviter

5 16/06/20145

6 Les premiers projets posent les briques dune architecture ambitieuse Commencer petit – ne veut pas dire quon ne voit pas grand – Mais permet de vérifier les premiers résultats rapidement La feuille de route permet de – Prioriser les éléments à mettre en place rapidement – Savoir pourquoi on ne fait pas tout tout de suite

7 Cela peut être plus ou moins complet Evaluer la maturité de lorganisation, suivant différents axes – Métier – Méthodologie – Technique Se fixer des cibles à atteindre Etablir des étapes importantes et des métriques permettant davancer dans les différentes dimensions de maturité Sattendre à des changements dans la feuille de route elle-même, lexpérience pouvant modifier la vue que lon a de la cible – Prévoir des étapes régulières de vérification de la feuille de route

8 nest pas Ce nest pas un processus une méthode Un modèle de maturité SOA est une méthode pour évaluer et mesurer la maturité de ladoption et de larchitecture SOA dune organisation capacités Un modèle de maturité SOA décrit les capacités dune SOA réelle, permettant de donner à une organisation une vue de son avancement en termes dadoption SOA et des améliorations à apporter

9 Les plans darchitecture sont centrés sur une application et réactifs Pas de réutilisation de Services Web – ou utilisation dXML simple sans approche de services Web Architecture envisagée et feuille de route autour des services et processus (mais pas au niveau entreprise) - pas d'équipe plein temps sur le sujet Existence d'une méthodologie pour certains services consommés et exposés Discipline darchitecture établie et équipe plein temps associée; utilisation de logiciels du marché standards pour l'intégration et les processus Méthodologie de dév. en place pour la SOA et les services, capacité à gérer un nb croissant de services Utilisation complètement mure de SOA et des processus Capacité à agréger des services et à étendre leur utilisation au-delà du pare- feu et des frontières de lorganisation; SLA des services (sécurité, disponibilité) respecté Applications et systèmes sont sur des îlots isolés; Le besoin d'intégration n'est pas une priorité ou est vu comme trop coûteux Principalement de l'EAI point à point. Pas d'intégration au niveau entreprise Dispose dune architecture dentreprise pour l'intégration (ESB, EAI, B2B); utilisation de solutions dintégration du marché; Les processus fondamentaux au niveau entreprise sont intégrés Processus inter-entreprises complètement intégrés; lEAI sappuie sur les services et des patterns de lindustrie; capacité à intégrer rapidement de nouveaux standards et applications Peu d'automatisation de processus/workflows à part dans des appli. isolées, recours à des contournements manuels pour des processus inter applications et inter personnels Automatisation de tâches répétitives (en remplacement du papier); quelques processus départementaux qui couvrent plusieurs applications Tous les processus métier fondamentaux sont automatisés; lactivité des processus est supervisée; Certains processus autonomes ont des règles métiers externalisées Lutilisation de processus permet une gestion de versions, de contrôle, de màj, de redéploiement dyn., une adaptation à la charge; les workflows sont automatisés et fournissent une visibilité de bout en bout B2B à base de téléphone/fax, saisie manuelle, ou contournements codés en dur Intégration B2B propriétaire (spécifique à un partenaire) ou utilisation de VAN (EDI) Solution B2B polyvalente permettant de gérer plusieurs standards (XML, X12, EDIFACT) et plusieurs partenaires commerciaux Le B2B est intégré à travers le pare-feu via des processus/workflows collaboratifs; le B2B dispose dune gestion des partenaires ciaux et des changements de règles agiles SOA et processus dentreprise Passer dun ensemble dapplications et services déconnectés à une SOA et des processus dentreprise qui sadaptent facilement

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25 Exposer Gouvernance (Exploitation, Supervision, Business activity…etc.) Gouvernance (Exploitation, Supervision, Business activity…etc.) Développement / Conception Unix Données Windows Server ERP OS390/590 Legacy Linux J2EE Consommer Partenaires Applications Mobilité Portail Office Composer