Séance Urbanisation des SI

1. Séance Urbanisation des SI MASTER IPI-NT Le 11/12/2013 Laurent DESCAMPS

2. Urbanisation d’un SI 1 – Introduction à l’urbanisation des SI 2 - Les grands principes de l’urbanisation 3 – Un Projet « Urbanisation du SI » : l’urbanisation en pratique

3. I - Introduction • Qu’est ce que l’urbanisation d’un SI ?

4. I - Introduction • Qu’est ce que l’urbanisation d’un SI ? • Encore récemment, les concepteurs d'un projet informatique limitaient le périmètre de travail exclusivement au problème à traiter. Il s'agissait de ne pas de se préoccuper des autres systèmes déjà en œuvre, et encore moins du devenir des dits systèmes. • Cette approche historique parcellaire, hétérogène et combien néfaste est désormais révolue. • Le système d'information s'inscrit aujourd'hui dans une dimension stratégique de l'entreprise. • Il est donc primordial d'adopter une vision globale, dans l'espace et dans la durée pour tout projet d'informatisation.

5. I - Introduction • Les définitions de base : • Urbanisme : c’est comment organiser et faire évoluer dans le temps un espace composé d’ouvrages, • Architecture : comment concevoir et construire un ouvrage,

6. I - Introduction • Parallèle avec l’urbanisme d’une ville : • Une ville se compose de multiples niveaux de croissance que l'on peut qualifier de "fonctionnels" : habitations, commerces, zones industrielles. La voirie relie et dessert chaque niveau ainsi que les services communs et partagés comme l'administration, les hôpitaux, les écoles... • Une ville est en perpétuelle évolution. Pour conserver le niveau de qualité de service global, les ressources et infrastructures doivent être adaptées en continu. • Un système d'information ressemble étrangement, en tout cas sur le plan logique, au concept de la ville. Un système d'information se compose de modules fonctionnels répondant à des besoins particuliers. Les ressources globales et les réseaux de communication sont aussi partagés. Et bien sûr, le système évolue en permanence ... • Ce découpage en zones (appelé cartographie), met bien en évidence lamodularité fonctionnelle et les échanges entre modules.

7. I - Introduction Pour garantir l'adéquation entre les enjeux stratégiques, les besoins fonctionnels, la cohérence métiers, les processus et les exigences technos  les concepteurs adopteront différents niveaux d'abstraction Au sein du SI les transformations touchent aussi bien le SI et les technologies mise en place que les applications, les processus et l’organisation. C’est cet ensemble qui influence la stratégie de l’entreprise. Tous ces éléments doivent néanmoins s’articuler de manière intime tout en pouvant être modifiés sans devoir défaire les autres.

8. I - Introduction • Précisions terminologiques : • Les spécialistes des systèmes d’information ont choisi de dénommer «urbanisation» la démarche qui consiste à rendre un système d’information plus apte à servir la stratégie de l’entreprise et à anticiper les changements dans l’environnement de l’entreprise. • L’ «urbanisation du système d’information» désigne plus précisément la mise en œuvre du plan d’urbanisme du système d’information. • L’ «urbanisme du système d’information» désigne la démarche qui consiste à définir un système d’information cible qui puisse s’adapter et anticiper les différents changements (stratégiques, organisationnels, juridiques…) touchant l’entreprise. • Le «plan d’urbanisme du système d’information» désigne l’agrégation de la définition du système d’information cible et des règles d’urbanisme avec la trajectoire à suivre pour atteindre ce système d’information cible.

9. II – Les grands principes Passer d’un SI spaghetti à un SI en couche

10. II – Les grands principes • L’urbanisation du système d’information représente une évolution des visions et des démarches applicables pour aborder un problème très ancien du système d’information : l’agilité • Les entreprises ont souhaité des systèmes d’information dans un premier temps fiables, puis ouverts tout en conservant un niveau de sécurité élevé. • L’agilité vient s’ajouter à ces deux qualités historiquement exigées. Certes, elle était un avantage pour l’entreprise mais l’environnement économiquement stable dans le passé faisait que l’on pouvait s’en affranchir. • De nos jours, l’instabilité économique rend cette qualité nécessaire, voire indispensable.

11. II – Les grands principes • Les facteurs qui poussent à l’urbanisation : • L’environnement concurrentiel des entreprises : le changement est devenu la règle. Les entreprises doivent réagir de plus en plus rapidement aux mouvements des marchés et à la versatilité des besoins des clients. • Un rôle nouveau pour la DSI : le passage d’une ère productive à une ère des services à l’utilisateur. Un SI omniprésent à tous les niveaux pour tous les métiers de l’entreprise. • L’état de l’art technologique évolue : des nouveaux outils et méthodes de conception des SI qui favorisent l’agilité, la réutilisabilité, • La présence en entreprise de référentiels : le plan d’urbanisme qui comprend les 3 composants principalement décrits dans les référentiels (données, processus et règles) devient un référentiel en soi

12. II – Les grands principes

13. II – Les grands principes • Les problèmes liés à un SI non urbanisé : • Un système d’information « non agile » pose des problèmes à la fois pour les utilisateurs (impacts métiers) et pour la direction des systèmes d’information (impacts technologiques). • Un système d’information est naturellement soumis à l’obsolescence. L’urbanisation change la capacité de la direction des systèmes d’information à affronter ce constat, notamment en la rendant capable de gérer toute la variabilité entre le nouveau et l’ancien, le standard et le sur-mesure. • Le choix des bonnes solutions et l’identification des bons compromis sont handicapés avec un système d’information non urbanisé.

14. II – Les grands principes • Les symptômes d’un SI non urbanisé pour les directions métiers : • Difficulté à développer et distribuer de nouveaux produits et nouveaux segments de marchés. • Difficulté à assurer de nouveaux services aux directions opérationnelles, notamment dans une logique internationale et transversale. • Augmentation de tâches à « non-valeur ajoutée » (ce qui a un impact indirect sur les processus). • Difficulté de maintenir un niveau de service en cohérence avec l’accélération technologique. • Surcoût d’exploitation et de maintenance : lourdeur reconnue, il faut de plus en plus de personnes, de ressources et de savoir-faire pour assurer un service constant. • Persistance et accroissement de la non-qualité.

15. II – Les grands principes • Les symptômes d’un SI non urbanisé pour la direction informatique : • Diminution voire absence de la maîtrise sur le système d’information. • Accroissement des vulnérabilités et des risques de dysfonctionnement générés par l’augmentation de la complexité du système d’information. • L’obsolescence technique et une architecture qui n’est plus adaptée augmentent les risques de dysfonctionnements, qu’ils soient mineurs (ralentissement, procédures complexes…) ou majeurs (perte d’information, arrêt d’exploitation…). • Difficultés à intégrer des technologies nouvelles. L’intégration de nouvelles technologies dans un système d’information non urbanisé est délicate, voire impossible. • La non-maîtrise des évolutions logicielles (rustines, versions…) par manque de cible identifiée (gestion de parc). L’urbanisation permet de mettre de l’ordre en gérant la diversité des technologies et des processus. • Parmi les autres difficultés, on peut citer aussi la dégradation de l’image de la DSI vis-à-vis des directions opérationnelles et plus généralement de l’entreprise vis-à-vis de ses clients.

16. III - L’Urbanisation en pratique • Le but de ce chapitre est d ’expliquer de manière concrète : • Le cheminement d’un tel projet en réalité • Les différentes étapes par lesquelles l’entreprise est passée pour mener sa réflexion

17. L’urbanisation à Cofidis  Pourquoi urbaniser ? • Phase 1 : le cadrage • Phase 2 : l ’étude préalable • Phase 3 : l ’étude détaillée • Phase 4 : la réalisation • Le bilan • Et au final ...

18. Pourquoi urbaniser ? • Le SI s ’est construit au fur et à mesure des projets sans schéma d ’ensemble. • Les Constats internes étaient : • Un fort enchevêtrement des applications. • Un découpage fonctionnel pas correctement délimité. • Un modèle logique de données peu adapté au découpage applicatif où toutes les applications peuvent accéder à tout. • Une absence de vision globale du parc applicatif. • Une cartographie de l ’existant incomplète.

19. Constats internes : exemples • Enchevêtrement des applications : • Une journalière de 3 000 jobs. • Incompatible avec le temps réel (arrêt du temps réel de 22h00 à 04h00)  problématique pour les services en ligne (SVI, Internet). • Un fil rouge de 50 traitements : • Enchevêtrés • Des points d ’attente • Echanges de fichiers de données • Déchargement de table en début, puis rechargement en fin  Base instable

20. Constats internes : exemples • Périmètre fonctionnel enchevêtré : • Application « Comptes » (débit/crédit) qui effectue « des demandes d’adresse client ». • Application « Contrats » (octroi de crédit) qui effectue des créations de client. Alors qu’il existe une application « Clients » dont le but est de créer et gérer les données du client.

21. Constats internes : exemples • Découpage du modèle logique de données : • Des tables de plus de 200 colonnes. • Des tables de plus de 10 000 000 occurrences. partagées entre plusieurs applications. • Toutes les applications peuvent accéder à tout (en lecture ou en mise à jour).  toutes les applications sont impactées en cas d ’évolution du modèle de données car besoin de faire évoluer les structures d’échange de données.

22. Constats internes : les conséquences • Une réelle difficulté à faire évoluer le SI • des projets gelés pour la création de nouveaux produits, • des développements sur des systèmes parallèles au SI, • Un manque de réactivité dans la prise en compte des évolutions (3 à 4 Mise En Production globale / an). • Des dérives QCD. • Des difficultés dans la maîtrise du parc applicatif (besoin de connaître tout). • Les choix ont toujours été accès sur la performance, le besoin utilisateur, la rapidité du développement au détriment de l’évolutivité du SI.

23. Constats internes : les conséquences • Problématique dans la résolution d’incident : • X origines de mise à jour  risques multipliés par X, c ’est le cas des rattrapages manuels sur la perte d’intégrité de la base.  Identification et recherche de l’anomalie longue dans le cas présent

24. Constats internes : les conséquences • Problématique dans l’évolution : • La Normalisation d’adresses (5 x 32 passage à 6 x 38)  lourdeur et coût élevé pour la mise en œuvre • Le jour de paiement : passage d’un champ de X(2) à 9(2)  80 jours de charge, multi-applications. • Evolution du format d’échange avec les partenaires contentieux : plusieurs centaines de jours de charge pour aucun gain fonctionnel  un format d’échange totalement déstructuré au fil des années

25. Constats internes : Le remède • Urbaniser c ’est : • Se redonner un cadre et des principes d ’organisation. • Définir les différents composants du système et les modalités d’assemblage. • Rendre indépendant tous les composants. • Relier les composants par un échangeur. • Assurer la cohérence et la souplesse de l’ensemble.

26. Les Forces existantes • Système d ’information « récent » (~ 25 ans). • 2 grandes refontes (technique et fonctionnelle). • Architecture « presque » homogène : • Batch : cobol. • Temps réel, trois architectures : • J2EE / Weblogic • VB / Tuxédo (3 tiers) • Acms / Decforms • 1 base de données commune. Quelques bases annexes.

27. L’urbanisation à Cofidis • Pourquoi urbaniser ? Phase 1 : le cadrage • Phase 2 : l ’étude préalable • Phase 3 : l ’étude détaillée • Phase 4 : la réalisation • Le bilan • Et au final ...

28. Phase 1 : le cadrage • Recherche d ’informations / séminaires / lecture des ouvrages de référence. • Appropriation : • Des concepts (zone / quartier / bloc). • Des 7 règles (unicité, autonomie, asynchronisme …). • De la démarche d ’urbanisation. • Du gestionnaire de flux (l ’échangeur). • Proposition aux instances de décisions.

29. Flux Prise Fonctionnalités Prise MCD Flux Urbanisation - Les concepts Zone décisionnelle et pilotage Zone d ’échanges • Zone : Le SI est découpé en Zone opérationnelle Zone de gestion interne • Quartier : • - Regroupe des composants homogènes • quant à la nature des informations traitées. • Bloc : • - Unité interchangeable et réutilisable. • - Correspond à une fonction du SI. • - Regroupe les données et les traitements • (fonctionnalités). • - Devient 1 à n applications.

30. Urbanisation Les 7 règles de fonctionnement • Unicité : 1 bloc  1 quartier  1 zone. • Autonomie : un bloc assure seul ses traitements. • Asynchronisme : pas de dépendance temporelle entre blocs. • Appartenance : une donnée est sous la responsabilité d ’un bloc. • Échange : les échanges entre blocs sont normalisés. • Ancrage : un bloc a une seule entrée et une seule sortie. • Communication entre blocs transite par le gestionnaire de flux.

31. UrbanisationLe gestionnaire de flux Le flux (ou message) • Un flux est produit en sortie du bloc • Il est événement déclencheur d’autre(s) bloc(s) • Le flux est normalisé (format pivot) Le gestionnaire de flux • Le gestionnaire de flux prend en charge les flux • Il transporte le flux de l émetteur vers les destinataires • Il assure une garantie de délivrance App 1 App 2 App 1 App 2 App 4 App 3 App 3

32. La démarche d ’urbanisation • La démarche se base sur un cadre de référence distinguant 4 visions du SI : • Métier / Fonctionnelle / Applicative / Technique • Une approche « top down » : • On cartographie le système d ’information en partant de la vision métier alignée sur la stratégie de l ’entreprise pour aboutir à la vision technique.

33. La démarche d ’urbanisation Architecture existante Architecture cible Métiers Architecture cible Fonctionnelle Architecture existante Architecture cible Applicative Technique Architecture existante Architecture cible

34. Les décisions prises • Concepts (zone/quartier/bloc) :  Réponse des instances de décisions : • Ok pour la mise en place de ces concepts. • Règles :  Réponse des instances de décisions : • On part à priori sur la mise en place des 7 règles. • Avec des réserves fortes sur les règles : Autonomie/ Asynchronisme/Appartenance des données (en lecture).

35. Les décisions prises • La démarche d ’urbanisation :  Réponse des instances de décisions : • La réalisation des différentes cartographies du système d ’information : démarche coûteuse. • Il n ’y a pas de réelle volonté de repartir des métiers. • On souhaite se servir des concepts de l ’urbanisme pour découper et classer le parc applicatif. • Accord sur la réalisation d ’une cartographie fonctionnelle cible à court terme  cadre de référence pour les projets.

36. Les décisions prises • Le gestionnaire de flux  Réponse des instances de décisions : • Lancer l ’étude sur les solutions d ’échange entre blocs (EAI – Enterprise Application Intégration : architecture intergicielle permettant à des applications hétérogènes de gérer leurs échanges ). • Plan de route pour la phase 2 : • Ecriture d ’une charte d ’urbanisme (concepts et règles). • Réalisation d ’une cartographie fonctionnelle cible. • Etude sur les solutions d ’échange entre blocs.

37. Sommaire • Pourquoi urbaniser ? • Phase 1 : le cadrage • Phase 2 : l’étude préalable • Phase 3 : l ’étude détaillée • Phase 4 : la réalisation • Le bilan. • Et au final ...

38. Phase 2 : l ’étude préalable • Ecrire une première charte d ’urbanisme à partir des concepts et règles validés. • Sensibiliser les équipes à l ’urbanisme.  Changer dès à présent, dans les projets, les façons de concevoir. • Réaliser la cartographie fonctionnelle cible validée par les instances de décisions.  Cadre de référence : se rapprocher au travers des projets du périmètre fonctionnel attribué.

39. Cartographie fonctionnelle cible Echanges Décisionnel et pilotage ODS Datawarehouse Contrôle de gestion Marketing sélections Pilotage opérationnel Services en ligne Marketing reporting Etudes Internet Minitel Opérationnelle Serveur vocal Interactif Référentiel Incidents Eléments de structure Contrôle adresses Catalogue Habilitations Institutions Editique Sinistres Centre de contacts Gestion des affaires Client Produit crédit Services Risque Contentieux Courrier Fax Déclaration FICP Revolving Carte bancaire Interrogation risque Gestion clientèle Client Suivi impayés Amortissable Téléphonie E-mail Routage Contrat Règles d ’octroi Accords Archivage Flux financiers Tarification Imputation Règles de recouvrement Plans Echanges financiers Agendas et suppléances Affaires spécifiques Echanges inter bancaires Echanges monétique Gestion interne Ressources humaines Outils et services Finances Comptabilité

40. Gestionnaire de flux • Recherche d ’informations / séminaires / lecture des ouvrages de référence. • Appropriation des concepts.

41. Gestionnaire de fluxles découvertes • Les différents composants de ce type d ’outil (EAI – Intégration d’Application d’Enterprise ) : Supervision Process métier Moteur d ’intégration (règles) Large périmètre Transporteur Connecteurs Connecteurs applicatifs Connecteurs techniques Connecteurs progiciels

42. Gestionnaire de fluxles découvertes • Définir correctement son besoin avant de choisir : Supervision Process métier Refonte du SI. Urbanisation. Solution « d ’infrastructure ». Moteur d ’intégration (règles) Echanges entre applications. Solution « tactique ». Transporteur Connecteurs

43. Gestionnaire de fluxles découvertes • Plusieurs modes de communication entre applications : • Le mode conversationnel : Une communication s ’instaure entre deux applications puis supporte un dialogue sous forme de questions /réponses. • Le mode requête /réponse : Ce mode est similaire au précédent mais limité à un seul aller-retour. • Le mode file de message : L ’application émet un flux dans une file d ’attente d ’une autre application. • Le mode publication/abonnement : L ’application émettrice publie un flux. Les applications réceptrices s ’y abonnent. Synchrone Asynchrone

44. Gestionnaire de fluxles découvertes • De nombreux acteurs sur le marché (plus de 13 acteurs). • Les outils ne couvrent, pas tous, toutes les couches. • Les prix sont variants et le ticket d ’entrée est élevé ( de 29 à 500 K Euros). • Des outils dont l ’implémentation nécessite de connaître les nouvelles technologies (J2EE ... Peu connu à l’époque de ce projet dans l’entreprise).

45. Gestionnaire de flux • Etude sur les capacités de notre système d’information à évoluer vers une architecture de de ce type (par un consultant extérieur). • Les recommandations : • Approche « tactique » : problématique d’échange entre applications. • Ne pas entrer dans le monde des nouvelles technologies (J2EE) par ce type d ’outil (Tuyauterie)  ce qui a été fait en pratique avec un projet fonctionnel de refonte de la gestion, • Evaluer les produits déjà en place qui couvrent certains composants d ’un gestionnaire de flux

46. Les décisions prises • Nouvelle donnée importante : en cours de projet il a été décidé que l’architecture cible tournerait autour de J2EE. • Initialisation du chantier « Architecture », avec un axe « Urbanisation ». • Volonté de donner les moyens techniques aux équipes pour dés-imbriquer les applications sur l ’architecture existante pour faciliter : • La migration, éventuelle, vers J2EE. • La mise en place des projets de refonte.

47. Les décisions prises • Pour dés-imbriquer les applications, deux axes d ’étude : • Comment accéder aux données d’une autre application sans accéder directement à son modèle de données (mode de communication synchrone) ? • Comment échanger des flux entre applications selon le mode publication/abonnement (mode de communication asynchrone) ?  Lot1

48. Sommaire • Pourquoi urbaniser ? • Phase 1 : le cadrage • Phase 2 : l ’étude préalable Phase 3 : l’étude détaillée • Phase 4 : la réalisation • Bilan. • Et au final ...

49. Phase 3 : l ’étude • Axe 1 : Comment échanger des flux entre applications selon le mode publication/abonnement (Gestionnaire de flux) ? • L ’idée générale : • Une application, après avoir réalisé une action, en informe les autres applications par l’émission d’un flux (ex : création, modification d’une adresse d ’un client). • Les applications qui souhaitent recevoir ce type de flux s ’y abonnent.  Mode de communication asynchrone publication /abonnement. Intégration des applications par les traitements.

50. Phase 3 : l ’étude Exemple : • Avant : • L ’application « Plan », après avoir créé un plan : • met à jour le bloc-notes de l ’appli « Recouvrement » • met à jour les données assurance de l’appli « Assurance » • Elle met donc à jour des données dont elle n ’est pas propriétaire. • Après : • L ’application « Plan », après avoir créé son plan, en informe les autres blocs par l’émission d ’un flux. • Les applications « Recouvrement » et « Assurance » s ’abonnent à ce type de flux et mettent à jour, elles même, ses données (le bloc-notes, les données assurance).