ANDSI. Introduction à l Architecture d Entreprise Présentation du CEISAR (14 avril 2009)

Transcription

1 ANDSI Introduction à l Architecture d Entreprise Présentation du CEISAR (14 avril 2009) contact@ceisar.org

2 Agenda Pourquoi l Architecture l Entreprise? Quels enjeux permet-elle d adresser? Quoi? Qu est-ce que l Architecture d Entreprise? Comment mettre en œuvre l Architecture d Entreprise? Rôles, organisation, gouvernance, processus Projet Page 2

3 L Architecture d Entreprise décrit comment l Entreprise Opère et se Transforme pour appliquer une Stratégie Stratégie Nouveaux Produits, Processus, Partenaire, Marché Quelles Organisation et Informatique? Architecture d Entreprise Transformation Operations Acteur Action Information Organisation Acteur Humain Automate Execute Action Manuelle Action Automatisée Avec Information non structurée Information Structurée Page 3

4 Beaucoup d initiatives: comment simplifier cette nouvelle discipline? Approche BPM CMMI Cobit IL MDA MDM Praxeme SOA TOGAF UML Urbanism Zachman Gouvernance Architecture IS Project Portfolio Quality Road Map Security SOA Solutions Urbanism Architecture Business Architecture Component Architecture Data Architecture Enterprise Architecture Functional Architecture Information Architecture Infrastructure Architecture Network Architecture Organization Architecture Service Architecture SOA Architecture Technical Architecture Modèle Application Model Block Model Functional Model Organization Model Process Model Technical Model Page 4 Google: 10 millions references Action Activity Business Process Capability Domain Elementary Function End to End Process Execution Function Functional domain Macro Process Operation Organization Process Preparation Procedure Rule Service Step Sub Process Task Use case

5 LE CEISAR Page 5

6 Le CEISAR traite de l Architecture d Entreprise (organisation+si) dans de grands groupes Air France/KLM (N 1 mondial du transport aérien) Axa (N 2 mondial de l Assurance) BNP- Paribas (N 5 mondial dans la Banque) Michelin (N 2 mondial du pneumatique) Total (N 4 mondial de l industrie pétrolière) Priorités : Complexité, Agilité et Synergie Etudes de Cas Budget Centre of Excellence in EnteprISe ARchitecture Décidés par les sponsors tous les six mois Simple Cohérent En anglais Publics sur Livres Blancs Professeurs Promotion de l EA Ecole Centrale ou autres Etudiants Formation Décideurs s Informatique Entreprises Page 6

7 L équipe dirigeante du CEISAR Jean-René Lyon ECP 70 + Stanford MS 72 Manager des SI dans plusieurs grands groupes (BNP, Crédit du Nord, Axa) Entrepreneur : fondateur de Lyon Consultants ( ) puis de l éditeur de logiciel Wyde Fondateur du CEISAR en 2007 Pierre-Frédéric Rouberties ECP 92 Professionnel des SI dans plusieurs grands groupes (dont DSI d AstraZeneca France) Rejoint le CEISAR en 2007 Page 7

8 Les principaux concepts du CEISAR Page 8

9 Messages principaux AE = Organisation + (comment l Entreprise Opère et se Transforme) Une nouvelle cible d AE qui change l approche, les rôles et les outils Comprendre la Complexité implique une bonne Modélisation de l Entreprise Vision Globale :, Organisation et Un langage unique et partagé, une approche commune Accroître l Agilité Une approche adaptée : coopérative pour les Solutions compétitives La réutilisation est clé : l équipe Fondation Accroître le nombre de transformations faites directement Des compétences sont requises Structure de l Entreprise : séparer Transformation/Operation et Reuse/Specifique Vers plus de Synergie Partager les ressources ou réutiliser les modèles A plusieurs niveaux (Groupe/filiale/unité) Implique une gouvernance adaptée Page 9

10 Quels sont les 3 enjeux majeurs pour les Entreprises aujourd hui? Stratégie Productivité Complexité Marketing Agilité Synergie Gestion des RH Enjeux majeurs Communication Globalisation Page 10

11 Conséquences d une Complexité croissante Des projets en difficulté 1/3 des projets sont des succès 1/2 des projets sont en retard, hors budget ou ne délivrent pas toutes les fonctionnalités attendues 1/6 des projets échouent Délais : manque de réactivité, évolutions pas assez rapides Coûts : Faible productivité des utilisateurs : ressaisies multiples, organisation basée sur le papier Dépenses : Coûts de maintenance, d intégration, d exploitation et de formation Spécialisation des Utilisateurs: L Entreprise manque globalement de flexibilité parce que les Processus sont morcelés et l interface utilisateur n est pas homogène Problèmes de Qualité des données Difficulté à tirer partie des nouvelles technologies Citation d un DSI : Je me sens plus comme un plombier que comme un architecte. Page 11

12 Modèle d Enterprise = Modèles ( + ) Coeur- Definit le quoi : ce que sont les Entités et Processus Comment un ensemble de Matériels, Logiciels Et Données automatisent tout ou partie du Coeur- et de l Organisation Definit le qui exécute (les acteurs) et quand les Processus sont exécutés. Pour un Coeur- donné, plusieurs variantes d Organisation peuvent exister. Organisation Page 12

13 Complexité La complexité vient Du grand nombre d objets Du grand nombre de relations entre objets Si 100 acteurs ont un lien avec un objet, le modifier implique de tous les consulter et d analyser l impact d une modification pour chacun d eux De la variété des objets Pour gérer la complexité il faut Connaître les objets => modèle global (tous les objets) et détaillé (par objet) Connaître leur liens => pour tirer la ficelle dans une analyse d impact Gérer la complexité implique de décrire explicitement l Entreprise en créant un Modèle d Entreprise : Cela permet de mieux comprendre l entreprise, de l analyser et d en partager et communiquer le fonctionnement Page 13

14 Agilité Une entreprise agile minimise le temps entre l émergence d une idée et le moment où toute l entreprise en bénéficie Soit le modèle d entreprise est suffisamment souple pour mettre en œuvre l idée sans projet de transformation Soit il faut transformer le modèle et l agilité passe par l optimisation de la durée et de la complexité du projet, donc par une approche adaptée Mais vite et bien (penser à la prochaine évolution du modèle) Page 14

15 Différents Moyens d améliorer l Agilité Projet exécuté par des professionnels métier et Transformation Les Configurateurs effectuent directement les Transformations. Transformation par Construction du Modèle Transformation par Configuration Approche Outils Composants Acteur Parametres Moteur de Règles Moteur de Workflow Composants Blancs Composants Noirs Services internes Services «SOA» Page 15

16 Agilité = vite et bien SOLUTION Version 1 Version 2 Version 3 Version 4 Version n L agilité est requise pour la V1 Mais aussi pour les versions suivantes : la qualité compte Page 16

17 Complexité et Agilité La complexité est (souvent) l ennemie de l Agilité Dans un système trop complexe, les changements sont délicats, longs et coûteux : Plus d objets sont touchés Plus de liens sont touchés La mise en œuvre du changement est plus ardue, plus longue et plus coûteuse sur toutes les phases : - Analyse d impact - Conception - Réalisation - Tests - Déploiement Il faut donc travailler sur deux axes Améliorer l approche pour rendre les projets de transformation plus rapides (tout en restant propre) Améliorer le modèle Réduire la complexité du modèle, notamment par la réutilisation Introduire des possibilités de configuration (moteur de règles, moteur de workflow) Page 17

18 Synergie : quelques solutions par l AE : : Réutiliser les modèles : Aligner toutes les unités ayant une activité similaire sur le même modèle de processus Exemple : Standardiser le processus de gestion des achats entre tous les acheteurs de toutes les filiales du Groupe. Chacun Partager les ressources : Mutualiser une activité sur une unité partagée Exemple : Centraliser l exploitation des infrastructures informatiques dans un centre européen pour toutes les filiales européennes Rq : cela est fait implicitement ou explicitement quand on déploie un même progiciel sur un ensemble d unités (elles héritent du modèle de processus automatisé dans le progiciel) Limiter le nombre de technologies utilisées pour un même besoin Respecter quelques règles pour construire des solutions propres Développer la réutilisation à la construction (composants blancs) Développer la réutilisation à l exécution (composants noirs) Page 18

19 Le Cube du CEISAR Complexité Complexité Agilité Synergie Exécution dans le Monde Réel Un seul Modèle partagé par le, l Organisation et l Informatique, chacun choisissant des vues spécifiques. Modèle Transformations Operations Agilité Eléments Partageables ou Réutilisables Eléments Spécifiques Synergie Page 19

20 Le modèle d Entreprise permet de comprendre comment les Opérations sont executées Modèle Global Carte des Processus Carte des Activités Carte des Fonctions Carte des Solutions Carte des Entités Vue simplifiée de la réalité pour la comprendre Rôles, Configurations Instructions détaillées aux Acteurs Définir, structurer et stocker les Informations Modèle Détaillé Modèle d Acteur Modèle d Action Modèle d Information Model Modèle d Acteur Humain Rôle, Droit, Devoir, Compétence Modèle d Action Manuelle Procédure, Documentation, Guide Utilisateur Modèle d Information Humain Définition des Entités Specific Operations B Modèle d Automate Configurations logicielles et matérielles Modèle d Action Automatisée Logiciel Modèle de données informatisées Entités/Relations, Types, Attributs Page 20

21 Un seul Modèle d Entreprise pour, Organisation et avec vues adaptées Complexité G Transformations Partagées E Opérations Partagées Exécution dans le monde réel Le Modèle (Doc et Logiciel) Acteur Acteur Exécution de la Transformation Exécution des Opérations Stratégie Client Acteur Action Info. Projet Acteur Action Info. Produit Planifie Plan Planning Produit Stock Modélise But Vend Cde Teste Gère Produit H Modèle Modèle Transformation Compos Réutilisé F Modèle Venddes Opérations Stock Réutilisé ants Modèle Modèle Modèle Gère Cde Modèle d Acteur d Action d Acteur d Action Modèle de Transformation Modèle Modèle des Opérations Modèle Modèle Rôle Modèle Doc. Modèle de Modèle Rôle Modèle Doc. Modèle de d Acteur d Action d info. donnée d Acteur d Action d info. donnée Config. Logiciel Glossaire Config. Logiciel Glossaire Role Méthode Role Guide Modèle Global: Fiche les «Cartes» Fiche Outil Data Data Config Config Logiciel Transf. Model Model Agilité Synergie Transformation Modèle Global: les «Cartes» Opérations Page 21

22 Modèle d Entreprise : partager et réutiliser Complexité Partager Call center Achats Production Informatique Partager l équipe d architecture Exécution dans le monde réel Ressources Partagées par la Transformation Exécution de la Transformation Planifie Modélise Teste Modèle Plan But Compos ants Ressources Partagées par les Opérations Exécution des Opérations Produit Vend Gère Produit Vend Gère Stock Cde Stock Cde Partager les référentiels Réutiliser les mêmes définitions Réutiliser l Approche Le Modèle (Doc et Logiciel) Modèle de Transformation Role Config Méthode Outil Transf. Glossaire Fiche Data Model Modèle des Opérations Role Config Guide Logiciel Glossaire Fiche Data Model Modèles Réutilisés par les Opérations Agilité Synergie Transformation Réutiliser rôles et configuration Page 22 Modèle Global: les «Cartes» Réutiliser les Fonctions des Modèles de Solutions (SOA) Opérations Réutiliser les mêmes cartes pour les Processus, Fonctions, Entités, Blocs...

23 Le processus de Transformation : Fonctions d Ingénierie et de Gestion Page 23

24 Des Processus de Transformation spécifiques par Entreprise qui réutilisent des Fonctions de Transformation communes Total Étude Opportunité Faisabilité Définitions Besoins Architecture Spécification Détaillée Réalisation Recette Fonctions Processus BNP Paribas Étude Préliminaire Axa Gestion Ingénierie Avant Projet Air France Évaluation Initialisation Gestion du Projet Conception préalable Conception Générale Conception détaillée Besoins Revue de Projet Spécification Réalisation Assemblage Recette Pre Study Feasibility Architecture Spécification Design Realization Acceptance Study Définir le Problème Modéliser les Informations Évaluer le cout d Investissement Modéliser les Processus Définir les Interfaces Gérer le budget Fonctions Organisation de la Transformation (comment bien Gérer) Architecturer Modèle Global Planifier Modéliser les Fonctions Communiquer Modéliser l Organisation Réutiliser les Fonctions Affecter Ressources Configurer une Règle Fonctions Cœur- de la Transformation (comment bien Construire) Contrôler Avancement Construire Outils de Formation Construire Outils de Migration Page 24

25 Terminologie de la Transformation Comprendre le Contexte (Existant, Fondations, Approche) Décrire le Problème (But, Périmètre, Valeur, Contraintes) Transformer Modéliser (inclut le Logiciel) Construire (Interne ou Externe) Créer ou Modifier la Solution (Acheter) Adapter Configurer Vérifier la Solution Insérer (outils pour Interface, migration) Déployer (ou conduire le changement) Réorganiser Unités et locaux Affecter, Former Acteurs Humains Opérer Exécuter les Activités Offrir les Services Supporter les Acteurs Gérer les erreurs Tuner Évaluer Architecturer le Modèle Global Réaliser le Modèle Acteur Action Information Affecter, Installer, Configurer Ordinateurs Migrer les Informations à la bascule Page 25

26 Construire un Modèle de Solution 1 Comprendre le contexte 1.1 Solution en place Décrire le PROBLÈME Define Perimeter, Goal and Value Définir les Contraintes Sur les Solutions livrées sur le Projet Qualité, Interface utilisateur Délai, Budget, Ressources Ingénierie par le Ingénierie par Gérer Gérer la 0 Transformation Évaluer cout Opérationnel (Métriques) 3.1 Résoudre le Problème Architecturer Solution(s) (Interactions entre Acteurs, Actions et Informations) 3 Gérer le Risque Décider 1.2 Modèle d Acteur Fondations (Utilisateur, Ordinateur) 3.2 Modèle de Processus Modèle de Fonctions Modèle d Information Planifier Affecter les Ressources 4.1 Vérifier Contraintes sur la Solution livrée.) 4.2 Vérifier la Solution Vérifier Fonctionnalités Vérifier Contraintes sur le Projet 4.3 Page 26 4 Vérifier Structure de la Solution 4.4 Communiquer

27 Utiliser un Modèle de Solution pour une Entreprise. Construire les interfaces Construire Outils Migration Insérer la Solution 5 Gérer la 0 Transformation Vérifier 5.1 Vérifier 5.2 Déployer la Solution Affecter/ Former Affecter, Installer, Migrer les Réorganiser Acteurs configurer Informations, à la Unités et locaux Humains Ordinateurs bascule Évaluer (Métriques) Gérer le Risque Décider Planifier Opérer la Solution 7 Affecter les Ressources Utiliser les Actions offertes 7.1 Supporter les Acteurs 7.2 Gérer les anomalies 7.3 Tuner 7.4 Communiquer Évaluer et Vérifier que le But est bien atteint (Indicateurs). 7.5 Page 27

28 Processus de Conception d un Modèle de Solution MODÈLE D ORGANISATION MODÈLE MÉTIER MODÈLE 2 Processus de bout en bout 3 Processus Classe Processus >4 4 Activité >4 Classe Activité Trouver le Prochain Acteur Autoriser Fonction Organisation 5 Fonction >5 Fonction Profil d Acteur: Droits et Devoirs Entité Organisation 1 Entité Classe >1 Entité 6 Configurer le Profil Page 28

29 Modèles et Modèle ou Modèle unique? PB PB PB Informations Informations Fonctions Fonctions MODÈLE DE SOLUTION 2 4 Processus 3 2 Processus Organisation: Activités et Rôles 4 Organisation: Activités et Rôles DÉPLOIEMENT Modèle Modèle Modèle Unique Page 29

30 Comment s armer pour faire face à l afflux de Solutions Évolutives? On a informatisé ce qui était facile. Approche Contractuelle inadaptée Solutions de Commodité (Besoins Prévisibles) Paye Solutions Évolutives (Besoins non Prévisibles) Processus de Recrutement Catalogue des Offres/Tarifs Processus de création des Offres Saisie du Contrat Processus de Vente Tableau de bord des ventes Ventes prévisionnelles et impact sur la production (flux tendus) Page 30

31 Pour Construire une Solution de Commodité, l Approche Contractuelle est la plus répandue.. et sont séparés On peut soustraiter tout l Effet Tunnel Une livraison définitive Définir tous les Besoins. Contrat Concevoir Modèle Programmer, Intégrer Modèle Vérifier Livrable Le doit tout définir! Le Chef du Projet est gestionnaire du Contrat Les Ajouts vont couter cher! Page 31

32 Pour Construire une Solution «Évolutive», Il faut développer l Approche Coopérative. Le Chef de Projet est Constructeur et sont Associés: responsabilités et sont Associés partagées Mais comment Garantir que l Architecture de la Solution permet d accepter les Besoins futurs??? Contrat V1 Version 1 Contrat V2 Contrat V3 Version 2 Version 3 Construire Architecture Spécifier, Vérifier Spécifier, Vérifier Spécifier, Vérifier Construire Architecture Concevoir, Programmer Concevoir, Programmer Concevoir, Programmer On peut soustraiter l par Versions Livrable V1 Outil de Modélisation commun / Livrable V2 Livrable V3 Résultat Rapide Construit pour évoluer Page 32

33 Approche Contractuelle ou Coopérative Approche Contractuelle Pourquoi? Conséquences? Besoin bien cerné (back office, production, réglementaire) Conditions du succès 1. L importance du Contrat 2. Chef de Projet plutôt Gestionnaire 3. MOA qui s engagent sur une description exhaustive des Besoins 4. Outils de Modélisation indépendants des Outils. 5. Réutilisation de Progiciels 1. Relation contractuelle: «, faites le» 2. Terminé quand tous les besoins sont satisfaits 3. sous-traitable Globalement 4. Effet tunnel 5. Les adjonctions ultérieures peuvent couter cher 6. Peu d espoir pour les Fondations Pourquoi? Conséquences? Besoin évolutif (Front Office, CRM, Business Intelligence, Conception de Produit, Entreprise Étendue) Approche Coopérative Conditions du succès 1. L importance de la Qualité de la Construction qui accueille les compléments ultérieurs. 2. Chef de Projet plutôt Constructeur 3. Équipe mixte / 4. Outils de Modélisation partagés et «Round Trip» 5. Réutilisation de Composants 1. Responsabilité Partagée: «Trouvez une bonne Solution ensemble». Compromis possible entre souhaits s / possibilités 2. Terminé quand échéance de la Version atteinte 3. sous-traitable par lots 4. Résultat rapide 5. Droit à l erreur pour les MOA 6. Fondations possibles Page 33

34 RÉUTILISATION: UNE ALTERNATIVE AUX PROGICIELS ON PEUT CONSTRUIRE UNE APPLICATION SPÉCIFIQUE AVEC 90% DE COMPOSANTS PRÉFABRIQUÉS Page 34

35 La Tendance à la Réutilisation Nb de Solutions De plus en plus de Solutions Compétitives sont fabriquées à partir de Composants De plus en plus de Solutions de Commodité sont fournies par des fournisseurs de Progiciels La plupart des Solutions sont des Développements spécifiques. Mais Trop cher Trop long Trop risqué Demande un effort au pour Modéliser Développement indépendant Réutilisation par Progiciel Monolithique Mais Avantage concurrentiel? Agilité? Sur-ensemble Pour Solutions de Commodité: Production, Back Office, gestion de Ressources... Pour Solutions Compétitives: Front Office, CRM, Business Intelligence, Processus de bout en bout, conception de Produits... Réutilisation par Composant Long Terme Page 35

36 A full implemented Insurance Model P/C Life (Savings) Business Lines Cash Value/ Annuities Life (Disability: Indiv/Group) LoanProtection One Business line = 5% work Health Care Reinsurance 179 Classes 164 Screens 544 Services 113Classes 49Screens 396Services 150 Classes 170 Screens 670 Services 130 Classes 250 Screens 600 Services 34 Classes 33 Screens 137 Services 190 Classes 145 Screens 712 Services 160 Classes 227 Screens 1084 Services Prod/Contract 150 Classes 230 Screens 1145 Services Prod/Contract 265 Classes 515 Screens 2684 Services Types 80 Classes 64 Screens 620 Services UI 180 Classes Screens Services Individual 160 Classes 200 Screens 1000 Services Rule/Engine 40 Classes 80 Screens 360 Services Group 140 Classes 175 Screens 880 Services Application Framework Contextsecurity 65 Classes 75 Screens 355 Services Persistency 110 Classes Screens Services Accounting 180 Classes 190 Screens 870 Services Desktop 135 Classes 210 Screens 1560 Services Parser/Interpret 520 Classes Screens Services Global Insurance Compensation 36 Classes 18 Screens 70 Services Claim 298 Classes 342 Screens 1661 Services Cross Business Compensation 70 Classes 55 Screens 235 Services 450 Classes 540 Screens 3643 Services Kernel Others (types...) 750 Classes Screens Services Reports 121 Classes 64 Screens 331 Services Forms/Reports 160 Classes 140 Screens 800 Services AGL 764 Cl Sc Sv Application 35 Classes 14 Screens 300 Services Others Classes Screens Services LightClt 274 Cl. 0Sc. 1684Sv Robot 176 Cl. 288 c. 1450Sv Replication 361 Classes 148 Screens 2088Services Interface 242 Cl. 158Sc Sv 1301Classes 1191Screens 7475Services 1117 Classes 1495 Screens 7150 Services Migrate 108 Cl. 15 Sc. 812 Sv 1586 Classes Screens Services Classes (1400 are persistent, 320 tables),, 4677 Screens, Services Page 36

37 La Fondation Cartes (Modèles Globaux) Méthodes et outils Sur les couches basses, non spécifiques à un Infrastructures : Serveurs, réseaux, postes de travail Gestion de la sécurité : Authentification, gestion des droits, sauvegarde, logs Interface Utilisateur GED, Impression, Interfaces, Composants logiciels réutilisables Architecture Sur les spécificités Glossaire Modèle d Acteur Modèle de Processus Composants logiciels réutilisables Page 37 Architecture Technique La Fondation nécessite une équipe dédiée pour la construire, la promouvoir et la supporter auprès des équipes projet Chaque projet doit se poser deux questions : Que prendre de la Fondation? Que donner à la Fondation?

38 L Architecture d Entreprise est une réponse aux principaux enjeux de l Entreprise Enjeux Complexité Agilité Synergie Entreprise 1 Entreprise 2 Des Solutions de Commodité Entreprise 3 Aux Solutions Aux Solutions Aux Solutions Competitives Competitives Competitives Gestion De l approche Contractuelle à l approche Cooperative : Itérative, Implication du Qualité de la Construction Gestion des Fondations: gouvernance, organisation, Fondations Architecture d Entreprise Ingénierie Modèle Global pour toutes les Solutions Modèle Unique pour le et l Réutilisation : référentiels, composants Priorité au Modèle d Information Les Processus doivent supporter différentes Organisations Page 38

39 GOUVERNANCE DE L AE UNIR MÉTIER ET SÉPARER SOLUTIONS ET FONDATIONS SÉPARER PRESENT ET FUTUR Page 39

40 8 Rôles Construit Fondations 1 Le Sponsor définit But et Contraintes Transforme Modélise Construit Solutions Opère Opérations Constructeur pour les Fondations Constructeur pour les Fondations Support Fondations Constructeur pour les Solutions Constructeur pour les Solutions Configure Modèle de Solution Déploie les Ressources Supporte les Operations Operations Evalue Page 40

41 Quelles Conséquences sur la Gouvernance? (voir livre blanc) Sortir l Informatique de son isolement: ne pas opposer Business et Protéger le Futur du Présent: isoler la Transformation des Opérations Promouvoir l innovation. Architecture ou Fondations Grouper les décisions Road Map globale Portefeuille de Projets «Solutions» Portefeuille de Projets «Architecture/Fondations» Solution 1 Solution 2 Solution 3 Composants, Templates, Sécurité, Architecture technique Méthodologie Préciser les Rôles: en particulier «Maitrise d ouvrage» et «Architectes» Pour réussir Partage et Réutilisation associer Architectes et Architectes Informatiques au sein des mêmes équipes d architecture. Page 41

42 IMPACT SUR LA STRUCTURE DE L ENTREPRISE Page 42

43 Les Différentes Unités d Organisation Les Fondations sont les Modèles communs à tous les s: Modèle d Acteurs: Roles et Configurations Modèles d Action: Solutions et Composants réutilisés Modèles d Information: référentiels partagés et Modèles d info réutilisés Souvent appelé MOA Ligne 1 Transformation 1 Les Opérations représentent l essentiel des effectifs. Opération 1 Existe rarement. Fondations Fondations Fondations Transformation 1 Ligne 2 Souvent appelé MOE Transformation 2 Opération 1 Production Informatique Opération 2 Transformation 2 Opération 2 Page 43

44 Scénario d organisation 1: Lignes Indépendantes, aucune synergie. Ligne 1 Ligne 2 Ligne 1 Transformation 1 Opération 1 Transformation 1 Ligne 2 Transformation 2 Chaque Ligne possède sa propre DSI Opération 1 Opération 2 Transformation 2 Opération 2 Page 44

45 Scénario d organisation 2: DSI centralisée Ligne 1 Ligne 2 DSI Chaque Ligne possède sa propre équipe de MOA. Ligne 1 Transformation 1 Opération 1 La DSI gère les Fondations communes à toutes les lignes, y compris pour la partie qui n est pris en charge par personne. Fondations Fondations Fondations Transformation 1 Ligne 2 Transformation 2 Opération 1 Opération 2 Les Opérations sont centralisées dans la DSI. La MOE de chaque ligne est dans la DSI. Transformation 2 Opération 2 Page 45

46 Scénario d organisation 3: Transformation et Opérations sont séparées Opérations Ligne 1 Transformation Opérations Ligne 2 Il existe une équipe de Transformation unique qui est séparée des Opérations Ligne 1 Transformation 1 Opération 1 Les Lignes se concentrent sur les Opérations. Fondations Fondations Fondations Transformation 1 Ligne 2 Transformation 2 Opération 1 Opération 2 Les Opérations peuvent être centralisées dans une Unité spécialisée Transformation 2 Opération 2 Page 46

47 Scénario d organisation 4: Fondations et Lignes sont séparées Ligne 1 Ligne 2 Fondations Ligne 1 Transformation 1 Opération 1 Fondations Fondations Fondations Transformation 1 Ligne 2 Transformation 2 Opération 1 Opération 2 Les Opérations peuvent être centralisées dans une Unité spécialisée Transformation 2 Opération 2 Page 47

48 Conclusion Une nouvelle discipline émerge: l Architecture d Entreprise Un effort de simplification des concepts est nécessaire: elle a besoin d un Modèle unique dont chacun exploite les vues qui lui conviennent Le CEISAR apporte sa contribution: utilisez ses produits téléchargeables sur et faites les progresser Ils sont gratuits Ils sont la conséquence d études de cas concrètes de grands utilisateurs Ils sont prolongés par des formations Nous pouvons vous accompagner sur une démarche d amélioration de votre Architecture d Entreprise par des actions de sensibilisation ou de formation Devenez Sponsor si vous souhaitez bénéficier des expériences des autres et aider à créer un Centre d Excellence Français en Architecture d Entreprise Page 48

49 Possibilité d accompagnement du CEISAR Page 49

50 Possibilités d intervention Sur la sensibilisation : auprès des décideurs, des utilisateurs, des projets Sur les pratiques d ingénierie (quick wins et bottom up) Modélisation des Objets du Modélisation des Processus Coaching sur un projet pilote Sur le modèle de transformation : mise en place de la démarche AE et de la gouvernance associée (top down) Page 50

51 FIN Page 51

52 La Forêt ou la Molécule de Chlorophyle? Time to Market Gains de Productivité Partenariat Nécessité d Evoluer Qualité de Service Client Usage d Internet Globalisation Contradiction croissante entre: Nécessité d Evoluer Capacité d Evoluer Air France Processus majeurs décomposables en dizaines de milliers de Fonctions. Progiciel d Assurance Services Logiciels Mais Complexité BNP Paribas objets en Production en France informaticiens Page 52

53 Différence entre l AE et l urbanisme Quelques similitudes Vision globale Modèle d Entreprise Décrire l Existant et la cible et gérer la transition Et des différences Importance de l Architecture : le périmètre de l AE ne se réduit pas aux seuls Processus automatisés (contrairement à l urbanisme qui se concentre sur les SI) L urbanisme n est pas intrusif dans les projets : propose l agencement du territoire, pas comment concevoir les solutions / l AE inclut les modèles globaux mais aussi les modèles détaillés Page 53

54 La vision globale du Modèle d Entreprise Coeur * Domaine Bloc * Cartographie applicative * Processus Coeur * Business Entity Acteur * Classe * Fonction Fonction Fonction d Organisation * * Software Service * Processus Organisé Organization Entity Acteur de l Organisation Organisation Page 54

55 Quelle complexité? La complexité s exprime à deux niveaux Cœur de - Trop d entités du : par exemple le nombre de produits - Trop de Fonctions, parce que par de mutualisation Organisation - Trop de variantes de processus organisés Se traduit sur les modèles globaux d Information et de Processus - Trop de Fonctions d Organisation, par rapport au nombre de Fonctions Système Informatique Se traduit sur la cartographie des blocs applicatifs - Pas de réutilisation - Beaucoup de technologies différentes pour le développement - Beaucoup de technologies différentes pour l exécution Page 55

56 Mesurer la complexité du système Enterprise Mesurer la complexité Mesurer la complexité Du Coeur- Nombre et complexité de : Mesurer la complexité De l Organisation Mesurer la complexité De l Nombre de : Nombre de : Entités Processus Fonctions Interfaces Utilisateur Volumes Données Instances de Processus Proc. Org/Proc. Activités/Processus Types d Acteurs Fonct. Org/Fonct. Volumes Acteurs Matériels et Blocs (et taille) Interfaces Tables et attributes Technologies d Opération Technologies de développement Qualité de : Code Données Productivité Obsolescence Page 56

57 Synergie : Groupe et filiales Un Groupe peut Partager Des Unités de Solutions (comme un service Achats central ou un centre d exploitation informatique) Des données de référence (par exemple sur les clients) Un Groupe peut Réutiliser Un Modèle d Acteurs Groupe (role, configurations) Un Modèle de Solution Groupe (même Modèle RH opéré par chaque filiale) Un Modèle de Processus Groupe Un Modèle Fonctionnel Groupe Un Modèle de Données Groupe Une Méthodologie Groupe Elements partagés ou réutilisés au niveau du Groupe Elements partagés ou réutilisés au niveau de la filiale Eléments Spécifiques à chaque Unité Synergie Page 57

58 Mesurer le niveau d architecture qui réduit la complexité inutile et apporte de la synergie Mesurer le niveau d architecture Mesurer l architecture Cœur- Entités communes Modèles de Processus communs Fonctions Communes Mesurer l architecture De l Organisation Description commune de l Organisation Fonctions d Organisations communes Interface Utilisateur uniformisée Mesurer l architecture Software Services communs Blocs communs Classes communes Données communes Environnement de développement standardisé Environnement d opération Standardisé Personnalisation par paramétrage et moteur de règles Page 58