La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Développer les capacités de l’entreprise à transformer son SI

Présentations similaires


Présentation au sujet: "Développer les capacités de l’entreprise à transformer son SI"— Transcription de la présentation:

1 Développer les capacités de l’entreprise à transformer son SI
Praxeme, la méthodologie d'entreprise 10/04/2017 Développer les capacités de l’entreprise à transformer son SI « La théorie sans la pratique est inutile ; la pratique sans la théorie est aveugle. » Immanuel Kant Intervention conjointe de : Yves CASEAU Philippe DESFRAY Dominique VAUQUIER Présentation utilisée lors de la conférence Marcus Evans : “Après 10 ans d’urbanisation : l’architecture d’entreprise”. Le 8 avril 2010. SLB-28 1.4

2 Objectif de la conférence
Praxeme, la méthodologie d'entreprise Objectif de la conférence 10/04/2017 Objectif Messages clefs Une approche holistique est nécessaire pour assurer l’alignement des SI sur la stratégie et les métiers Nous devons remettre les données au centre de notre approche de conception Nous nous rangeons dans la perspective d’un développement durable du SI Contribuer au renouveau de l’urbanisation des systèmes d’information Ce document est protégé par une licence « creative common ». Il peut être diffusé, reproduit, réutilisé, en tout ou en partie, à condition d’en citer l’origine et l’auteur. Les nouveaux matériaux produits doivent s’appliquer les mêmes conditions d’ouverture et de respect de la propriété intellectuelle. Il s’agit de 3 conférences réunies en une, avec intervention combinée des trois orateurs. Durée de la présentation : 2 h 40 SLB-28 D

3 Contenu de la conférence
Praxeme, la méthodologie d'entreprise Contenu de la conférence 10/04/2017 Une nouvelle approche des SI Comment et pourquoi réduire la complexité de son SI Comment valoriser les SI auprès des métiers Cette nouvelle approche est fournie par la méthodologie d’entreprise, Praxeme. La première partie en donne une introduction. Les suivantes montrent son impact sur : les systèmes d’information eux-mêmes, la relation avec les acteurs de l’entreprise. SLB-28 D

4 Praxeme, la méthodologie d'entreprise
Ordre du jour 10/04/2017 Partie Horaire Durée Une nouvelle approche des SI (DVAU) 9h50 45’ Comment réduire la complexité de son SI et pourquoi (YCS) 11h Comment valoriser les SI auprès des métiers (PhD) 11h45 Conclusion Fin: 12h30 Pause à 10h35 Q&R Q&R SLB-28 D

5 Une nouvelle approche des SI
Praxeme, la méthodologie d'entreprise 1 Une nouvelle approche des SI 10/04/2017 Introduction à la méthodologie Praxeme Contenu de cette partie Apprendre du passé Les limites de l'approche classique Approcher le Système Entreprise sous tous ses angles Revenir à l'essentiel Le primat du métier Transformer le système Enterprise Architecture, urbanisation et SOA Méthode publique, initiative soutenue par… Recommandation par le RGI Diffusion à l’international Caractéristique de la méthodologie (nous allons, dans cette conférence, nous intéresser surtout à la dimension « Produit », par opposition aux deux autres dimensions de la méthodologie : « Processus », « Procédés »). Filiation de la méthode. SLB-28 D

6 L’urbanisation des SI : Les leçons du passé
Praxeme, la méthodologie d'entreprise L’urbanisation des SI : Les leçons du passé 10/04/2017 Le défi permanent : Maintenir une articulation entre Vision stratégique / vision métier / vision informatique Connaissance de l’existant / vision du futur Gestion de l’urgence opérationnelle / vision architecturale long terme Les limites des pratiques usuelles Intégration des niveaux de description d’un système cible Stratégie, processus, fonctionnel, applicatif et technique Il ne sert à rien de produire de beaux plans s’ils ne sont pas réalisables d’un point de vue technique et si on n’est pas en mesure d’assurer la traçabilité entre les objectifs stratégiques et les niveaux techniques de manière à ce que toutes les décisions soient guidées par la volonté stratégique. SLB-28 P

7 L’urbanisation des SI : Conflits des paradigmes
Praxeme, la méthodologie d'entreprise L’urbanisation des SI : Conflits des paradigmes 10/04/2017 Quelles notions doivent sous-tendre l’urbanisation? Applications, Fonctions, Systèmes ? Métaphores (plan de ville) Approche fonctionnelle? Approche systémique ? Comment relier ces notions avec les autres visions ? Processus, métier, technique… Prise en compte des techniques architecturales récentes (SOA) Assure le découplage entre composants de service Supporte la notion fondamentale de service (métier) Permet une vision macro (urbanisation) et technologique SLB-28 P

8 Architecture à base d’applications : L’orientation Silo
Praxeme, la méthodologie d'entreprise Architecture à base d’applications : L’orientation Silo 10/04/2017 Une application = un silo applicatif Une entreprise taille CAC 40: de à applications Appli-nouvelle Appli1 Appli2 Appli-n SLB-28 P

9 L’approche fonctionnaliste (exemple) illustration
Praxeme, la méthodologie d'entreprise L’approche fonctionnaliste (exemple) illustration 10/04/2017 Une approche strictement statique Pas d'analyse des dépendances Référence à des choix techniques Critère de décomposition : fonctionnel Un exemple réel de carte d’urbanisation. (disons « carte » plutôt que « cartographie » qui désigne l’art de faire des cartes) Mélange de fonctions et d’applications. Surtout, la critique doit porter sur : Les conséquences de l’approche fonctionnaliste (redondance ou couplage) L’analyse amputée car limitée à la décomposition statique, sans étude des interactions et dépendances nécessaires (or, c’est justement là qu’est le problème). Le slide suivant révèle les dépendances à partir de cet exemple. Si on analyse les dépendances SLB-28 P

10 L’analyse des dépendances
Praxeme, la méthodologie d'entreprise L’analyse des dépendances 10/04/2017 Finances RH Logistique Ressources immobilières Reprend les domaines fonctionnels de la carte précédente. L’exercice a été mené lors d’un atelier. En moins d’une demi-heure. La question : quels sont les objets manipulés dans le domaine fonctionnel (ex. : personne, opération, matériel…). Plusieurs de ces objets sont nécessaires à plusieurs domaines. D’où : soit redondance (mêmes informations, règles… dans des endroits différents, soit couplage. Faits notables sur ce schéma : Beaucoup de dépendances (le coût des dépendances dans les SI…) ; Un domaine isolé : « Pilotage » (parce que nous avons pris l’habitude de traité le pilotage séparément = système décisionnel à côté du système opérationnel ; ce qui condamne à des délais insupportables pour tire de l’intelligence du système ; Praxeme propose une approche très différente de cette question). Pilotage Activités SLB-28 P

11 Un découpage fonctionnel Hiérarchique
Praxeme, la méthodologie d'entreprise Un découpage fonctionnel Hiérarchique 10/04/2017 À noter Même aproche dans les Business Capability Models Ex. : ACORD Culture Attention aux limites du découpage arborescent: Cela conduit naturellement à la séparation, la décomposition, la duplication Cela marche bien avec les choses physiques (hardware, rue, quartier, immeuble précisément) Cela marche moins bien avec des éléments conceptuels et logiques. Caractéristiques de l’approche fonctionnelle : La matière : attention portée sur la fonction, l’activité. La forme (structure) : décomposition hiérarchique descendante ; nombre de niveaux imposé. SLB-28 P

12 L’application : une notion qui s’estompe
Praxeme, la méthodologie d'entreprise L’application : une notion qui s’estompe 10/04/2017 L’approche SOA : une autre métaphore du système Le SI est une fédération de composants de services interconnectés Le SI peut être interconnecté avec d’autres SI L’ensemble n’est plus un système isolé On parle de « fédérations de systèmes » Un accès aux services Dépendant de l’utilisateur (rôle, activités en cours) Dématérialisé et de format variable (poste local, portable distant, smartphone…) Une architecture virtualisée Déploiement variable, mise à jour à chaud Cloud computing… SLB-28 P

13 Approcher le Système Entreprise sous tous ses angles
Praxeme, la méthodologie d'entreprise Approcher le Système Entreprise sous tous ses angles 10/04/2017 Notion de Système Entreprise Volonté de restaurer une certaine rationalité Cf. Enterprise Transformation Manifesto Nécessité d’un cadre de référence interdisciplinaire Approche holistique Tout dire du Système Entreprise Clarifier la chaîne de transformation Articuler les expertises Collecter et administrer les représentations de l’entreprise SLB-28 D

14 Le cadre de référence méthodologique
Praxeme, la méthodologie d'entreprise Le cadre de référence méthodologique 10/04/2017 Aspect politique (cadrage) Aspect sémantique Aspect logique Aspect logiciel Aspect pragmatique Aspect technique Aspect géographique Aspect matériel Aspect physique La Topologie du Système Entreprise SLB-28 D

15 L’entreprise et son SI en tant que système
Finalité Business Model (CEISAR) Aspect Politique Evolution Changements Structure Organisation (CEISAR) Aspect pragmatique Aspect sémantique Fonctionnelle Modèle Processus Objets Aspect logique Système décisionnel Aspect pragmatique Système d’information Praxeme meets Lemoigne  Cf. Jean-Louis Lemoigne, La Théorie du Système Général Aspect géographique Système opérant Aspect logiciel processus SI Le SI est lui-même un système Aspect physique, matériel Flux entrants environnement SLB-28 Y

16 Systèmes complexes Définition d’un système complexe
Un système est un ensemble d’éléments en interaction dynamique, organisé en fonction d’un but (objet actif, stable, évoluant dans un environnement par rapport à une finalité) Système complexe: lorsque le comportement est “émergent”, pas de liens direct entre les finalités des parties et celles de l’ensemble. Apports de la systémique générale Equilibre (homéostasie) Analyse des boucles de retour Téléolonomie (étude des finalités) Emergence Représentation et modélisation (cf. « cube CEISAR ») Conséquence de la « complexité » d’un système Simulation ou prototype, vs. analyse contrôle émergent - cf. Kelly:  By stating that the ideal IS must not be designed but grown (through emergence), I include information systems in the large family of (truly) complex systems. Management Operation Change Design SLB-28 Y

17 Le « Système Entreprise » est complexe
Caractéristiques Complexité numérique Multi-échelle Complexité temporelle Richesse des interactions avec l’environnement Exemples de symptômes: Coûts (évolution du SI) Exemple: Évolution non-linéaire du coût des projets Taux d’erreur/ panne Difficulté à « garantir » la robustesse et la tolérance aux pannes  Ross Ashby « La régulation d’un système (complexe) n’est efficace qui si elle s’appuie sur un système de contrôle aussi complexe que le système lui-même»  Time-to-market Le premier des soucis causé par la complexité Pourquoi le temps d’intégration dépend de la taille de l’hôte ? Complexité humaine (organisation) défaut de modularité (calcul d’impact et interaction) Conséquences inattendues – Feature Interaction Problem SLB-28 Y

18 Conséquence de la vision « systémique »
Emergence de propriétés De « Performance by Design » … .. à « Performance by simulation & prototype » Humilité et amélioration continue Gouvernance de la complexité (cf. 2e partie) Reconnaître le problème ! S’y attaquer de façon méthodique Cf. cube CEISAR (distingue trois dimensions) Un SI gouverné par des « politiques» explicites Contrats de service, SLA, contrats sur les données… Démarche « Architecture d’Entreprise » Aligner les « parties prenantes » Intégrer l’ «environnement du SI » dans la vision Complexité Agilité Synergie Exécution dans le Monde Réel Modèle Eléments Spécifiques Operations Transformations Eléments Partageables ou Réutilisables SLB-28 Y

19 Praxeme, la méthodologie d'entreprise
Revenir à l'essentiel 10/04/2017 Exprimer les fondamentaux La connaissance du métier Les objectifs de l’entreprise Être capable d’innover Traiter au mieux le métier Sans se soucier de l’organisation Adopter d’autres modes d’organisation Assurer l’alignement L’organisation avec le métier et les objectifs Le SI avec l’ensemble Nécessité de changer nos pratiques pour mieux innover, et assurer l’alignement SLB-28 P

20 Le « métier » : Élément fondamental des entreprises
Praxeme, la méthodologie d'entreprise Le « métier » : Élément fondamental des entreprises 10/04/2017 Le métier existe indépendamment des entreprises Ex: Banque, Assurance Vie, Assurance automobile, Contrôle aérien Il dispose de ses notions propres Ses règles métier spécifiques, lois et règlements Ses besoins d’échange et coopération entre organisations participantes Il a un impact majeur sur l’organisation et le fonctionnement des entreprises SLB-28 P

21 La « vision » : La raison d’être d’une entreprise
Praxeme, la méthodologie d'entreprise La « vision » : La raison d’être d’une entreprise 10/04/2017 Ce qu’une entreprise veut être Sa finalité, ses valeurs, son business model Comment elle compte se transformer Stratégie Ex : développer une nouvelle ligne métier, adresser de nouveaux marchés, maintenir sa position dans le marché et la compétition Définition des objectifs et des moyens de les atteindre Objectif stratégique Long terme, défini qualitativement plutôt que quantitativement Il doit être focalisé de sorte qu’il puisse être découpé en objectifs à court terme Objectif tactique Court terme : une étape décomposant un objectif à long terme Il comprend une date et des critères de réalisation SLB-28 P

22 L’organisation : Ce qu’est et sera l’entreprise
Praxeme, la méthodologie d'entreprise L’organisation : Ce qu’est et sera l’entreprise 10/04/2017 Histoire et mode de fonctionnement de l’entreprise Les unités d’organisation, les rôles, la hiérarchie Les responsabilités Localisation, Géographie, contexte culturel Les processus métier Les activités de l’entreprise, sa valeur ajoutée SLB-28 P

23 Transformer le système
Praxeme, la méthodologie d'entreprise Transformer le système 10/04/2017 Les changements dans nos disciplines préparent la transformation des entreprises Une discipline pour couvrir tous les aspects de l’entreprise Enterprise Architecture Méthodologie d’entreprise Deux changements clefs dans la façon d’appréhender l’entreprise La « bonne » description du métier La « bonne » structure du système informatique SLB-28 D

24 La bonne description du métier
Praxeme, la méthodologie d'entreprise La bonne description du métier 10/04/2017 Aspect sémantique Approche par les activités Limites : Handicapée par les variations locales Génère de la redondance Modélisation sémantique Apports : Stabilité Généricité Objets Objets « métier », objets réels (Information+Transformation+Action) Se réfère à Aspect pragmatique Activités L’approche spontanée du “métier” est l’approche fonctionnaliste : elle considère essentiellement les activités, quelle que soit leur maille, des processus aux cas d’utilisation. Bien sûr, les premiers niveaux de décomposition (par exemple les domaines fonctionnels) peuvent être considérés comme génériques. Mais, à ce niveau, rien n’est réutilisable : ce ne sont que des délimitations, des territoires, pas encore des composants à partager. Quand on progresse dans la décomposition jusqu’à atteindre les actions contraintes et les outils en regard, on rencontre nécessairement les règles d’organisation, les contingences, les pratiques locales… Donc, la variation. Adieu la possibilité de réutilisation. En revanche, ce qui est partageable car indépendant des variations locales, ce sont les objets “Métier” (“business objects”). Il importe de les dégager et de les modéliser avec suffisamment de rigueur. Acteurs et entités organisationnelles Processus & cas d’utilisation SLB-28 D

25 La bonne structure du système informatique
Praxeme, la méthodologie d'entreprise La bonne structure du système informatique 10/04/2017 Aspect sémantique Determiner la structure du logiciel à partir de la description du métier Standard MDA Indépendance / choix techniques Dérivation vers différents environnements Approche compatible avec les objectifs à long terme Aspect logique Objets Services logique & agrégats (machines logiques…) Dérive Strate « Fondation » Objets « métier », objets réels (Information+Transformation+Action) Aspect pragmatique Strate « Organisation » Activités Strate « Interaction » Le meilleur système informatique est celui qui est capable, sans heurt, de prendre en charge la description du métier et de l’automatiser. L’architecture logique se réfère donc aux modèles “amont”. Elle trouve dans les modèles sémantiques et pragmatiques, la matière qu’elle doit structurer. Par dérivation des modèles “amont”, le concepteur logique trouve les “bons” services, c’est-à-dire les services à fort contenu. Dérive Acteurs et entités organisationnelles Processus & cas d’utilisation SOA SLB-28 D

26 Le changement de physionomie
Praxeme, la méthodologie d'entreprise Le changement de physionomie 10/04/2017 Caricature d’une architecture fondée sur le critère fonctionnel Schéma de principe d’une architecture logique selon Praxeme DF DF DF DF DO DO DO OM DO DO OM DF DF DF DF L’application des procédés de conceptions SOA change radicalement la physionomie des systèmes informatiques. Pour l’essentiel, le changement réside dans une décision très simple : isoler les objets “métier” dans des portions bien identifiées du système. Le cœur du système doit être structuré non plus en domaines fonctionnels mais en “domaines d’objets”. La substance ainsi isolée est largement réutilisable. Blocs logiques reprenant les domaines fonctionnels (DF) issus du modèle pragmatique Interdépendances fortes ou redondances : objets « métier » (OM) repris à plusieurs endroits Blocs logiques reprenant les domaines d’objets (DO) qui structurent le modèle sémantique Dépendances soumises aux contraintes topologiques de la strate « Organisation » vers la strate « Métier », prohibition des relations mutuelles, pas de dépendance entre les blocs DF, etc. SLB-28 D

27 Conclusion de la partie 1
Praxeme, la méthodologie d'entreprise Conclusion de la partie 1 10/04/2017 Une méthode complète, disponible Sur tous les aspects Mettre en ordre les compétences dans un cadre commun Stimuler la synergie Approche holistique Un besoin absolu pour réussir la transformation d’entreprise SLB-28 D

28 Comment réduire la complexité de son SI et pourquoi ?
Praxeme, la méthodologie d'entreprise 2 Comment réduire la complexité de son SI et pourquoi ? 10/04/2017 Contenu de cette partie Coordonner l’architecture des données avec les processus « métier » Améliorer les développements informatiques Rapidité et productivité Adopter une méthodologie précise Tout en restant agile aux changements Développer son SI de manière durable Environ 7 slides Exploiter le cours à l’X (voir blog d’YCS) SLB-28 Y

29 Enjeux : Pourquoi réduire la complexité ?
Réduire les coûts De fonctionnement D’évolution (projets) Améliorer la qualité de service Cf. première leçon d’ingénierie des systèmes: KISS Éviter des « interactions non désirées » Réduire le time-to-market Agilité (3e partie) Durabilité (éviter le mur) La complexité est un enjeu de long terme, lorsqu’on s’aperçoit qu’on est devenu immobile, il est trop tard Favoriser l’alignement stratégique Il est difficile d’aligner ce qu’on ne maîtrise pas  SLB-28 Y

30 Comment maîtriser la complexité d’un SI ?
Approche simple Cartographie (utilité de UML2) Approche systématique Architecture d’entreprise, une démarche transverse d’alignement sur une cible et une transformation Approche technologique Infrastructure (middleware) Introduction de découplage, de mutualisation et d’intermédiation Approche de bon sens Standardisation énergique Réduire l’hétérogénéité réduit la complexité (Printz) Approche architecturale (structurelle, le plus difficile) Modularité (découplage) Approche stratégique SOA (architecture orientée-service) en tant que méthode de gouvernance, pour favoriser la réutilisation et la mutualisation SLB-28 Y

31 Réponse technologique : Infrastructure
Les middleware ont pour vocation de réduire la complexité technique (même s’ils ne font pas tout) Bus : réduire la complexité structurelle des interactions BPM: réduire la complexité temporelle MDM/EII/ ETL/ Annuaires: réduire la complexité structurelle de la gestion des données Attention: plus la complexité technique est réduite, plus la complexité fonctionnelle est dimensionnante Rôle fondamental de l’architecture d’entreprise Besoin de plus de maturité L’outillage réflexif (le SI du SI) joue également un rôle clé pour maîtriser la complexité Automatisation  meilleur contrôle Professionnalisation et Systémisation des interventions humaines (ex: CMDB & ITIL) SLB-28 Y

32 Réponse de bon sens: Standardisation énergique
Standardiser les objets … et les processus Avantages de la standardisation Réduction du périmètre à gérer Tire l’entreprise vers l’avant (le plus souvent) Support à l’automatisation Permet de s’appuyer sur les bonnes pratiques (des autres) Difficultés de la démarche Résistance au changement Surtout dans le contexte distribué d’une grande entreprise Compromis vs. « bénéfice de la diversité » Best fit / expérimentation Coût de mise en œuvre Ce ne sont pas les mêmes qui touchent les bénéfices et qui subissent les inconvénients (à rétablir) SLB-28 Y

33 Réponse complexe : Découplage et modularité
C’est une sous-partie de la démarche d’urbanisation Construire une architecture modulaire Diviser pour régner, minimiser les interactions Problématique multidimensionnelle Interaction = échange (le plus évident et le plus classique) Interaction = partage de ressource (cf. Architecture de données) Interaction = couplage/coévolution politique SI (ex: IHM) métier (ex: politique multi-canal) Difficile à mesurer  difficile à maîtriser Des méthodes et des outils … Matrices d’interaction (DSM) / partitionnement de graphe Architectures en couches (propagation logarithmique des impacts) Mais surtout un art qui s’apprend par expérience Ex: faire des scénarios (cf. « règle » des systèmes complexes) SLB-28 Y

34 Réponse stratégique: SOA
Pourquoi ? Méthode de transformation perpétuelle et effort continu de l’ensemble des acteurs SOA favorise la modularité Favorise mutualisation/ réutilisation -> réduction possible de complexité Gouvernance SOA « affirme en premier lieu l’existence d’un certain nombre d’artefacts (cartographie, catalogue de service, roadmap) et les rôles (droits et devoirs) de chacun ». SOA local  global SOA « Départemental » = architecture à base de services  SOA « Global » = Construire un catalogue de service structuré sous forme d’architecture Ce qui fait de SOA une méthode adaptée à l’amélioration continue du système d’information est la capacité à distribuer l’effort, à servir de support à la diversité (tolérance implicite vis-à-vis de la variété des solutions), et à construire une architecture modulaire. En effet, la décomposition en services produit de façon implicite les gènes de la modularité : abstraction, encapsulation, découplage par interface, élimination des redondances, etc. L’approche SOA est implicitement modulable, ce qui signifie que l’effort peut être adapté dans le temps en fonction des autres enjeux et autres priorités. SLB-28 Y

35 Développement Durable du SI
« développer les services informatiques d’aujourd’hui sans compromettre les capacités à développer ceux de demain, à travers un épuisement des ressources ou une complexité non maîtrisée » Cf.le rapport de la Commission Brundtland  SOA (global) est la méthode de développement durable Ce n’est pas la seule façon d’urbaniser (au sens organiser pour réduire la complexité) un SI La méthode pour le faire de façon continue, en tant que pratique d’entreprise (avec tous les acteurs), sur la durée, avec un effort limité car progressif et qui génère sa propre récompense Nettoyage : savoir éliminer = gérer un patrimoine Cf. Extreme programming (Agile Manifesto) : lisser ses efforts, intégration continue, conception simple Décomplexifier en continu, et non pas en mode héroïque s’exprime comme « le développement qui répond aux besoins du présent sans compromettre la capacité des générations futures à répondre aux leurs". SLB-28 Y

36 Complexité et SOA Gestion du catalogue Gestion des versions
Partage, hiérarchisation, exposition Gestion complexe … mais une complexité qui existe (explicitation) Gestion des versions La complexité de la gestion des versions et des déploiements est le « bon cholestérol » de la mutualisation : plus on mutualise, plus ces problèmes de conflits de ressources partagées apparaissent. Il ne faut pas s’en plaindre, c’est un bon symptôme. En revanche, cela requiert une véritable discipline. Richesse Fonctionnelle interfaces Early Adopters (N+2) Rupture Rupture Tous les ST utilisent (N+2) Version N Version N+1 Version N+2 Temps Roadmap Versions SLB-28 Y

37 Praxeme, la méthodologie d'entreprise
Données et processus 10/04/2017 Coordonner l’architecture de données avec les processus « métier » Modélisation sémantique En amont des processus Conception des processus Changer de point de départ pour innover Concevoir les processus à partir du cycle de vie des objets Architecture des données Les décisions sur l’aspect sémantique Domaines d’objets Possibilité de décomposition génériques La délimitation des bases de données Dans l’aspect logique On cherche à la rendre compatible avec la structuration logique 4-5 slides SLB-28 D

38 Bases et blocs dans l’aspect logique
Praxeme, la méthodologie d'entreprise Bases et blocs dans l’aspect logique 10/04/2017 Plan des Services … blocs logiques Quel niveau d’agrégat ? Plan des Données En SOA pur  principe d’encapsulation = les données ne sont accessibles de l’extérieur du blocs que par appel à des services. + recherche de blocs autonomes (qui deviendront, dans l’aspect physique, des unités de déploiement) Conséquence : à quel niveau d’agrégats logiques les bases de données doivent-elles correspondre ? Machine logique : exclu (trop petit ; correspond grossièrement à la table) Atelier logique : idéal puisque ce sont les services d’interface de ces ateliers qui sont visibles de l’extérieur ; mais si on choisit ce niveau pour dimensionner les bases, cela conduit à sous-exploiter les possibilités des SGBD. Ce serait pourtant le meilleur choix du point de vue du déploiement. Fabrique logique : c’est le choix « réaliste » (en renonçant à certaines propriétés attendues d’une vraie SOA). Le plan des services masque le plan des données SLB-28 D

39 Une « bonne » architecture de données (résumé)
Un modèle Global, partagé, compris, entretenu Un cycle de vie et des propriétaires Qui crée, qui lit, qui modifie, qui supprime ? Un plan de distribution Où sont les copies et pourquoi ? Qui est la référence (SPT) Des mécanismes (audit / synchro / etc.) S’il y a distribution (copies), il y aura des problèmes  Purge ! Des outils La gestion des données distribuées est difficile (surtout du point de vue des performances) – éviter de réinventer la roue ! Il vaut mieux simplifier l’architecture de données (diviser pour régner) et utiliser des solutions « du commerce » SLB-28 Y

40 Architecture de données: les questions
composant A Réferentiel Technique broker cache Bus Référentiel : Modèle commun message Données locales Données partagées B C Réplication pour contraintes de performance ou pragmatiques (ex: progiciel) À traiter: Synchronisation de copies Gérer le flux de synchronisation (cf. slide suivant) Garantir la cohérence des accès concurrents La cohérence => signalisation / exclusion / sérialisation Impossible dans le cas général (problème des « snapshots ») OK si on se limite à une cohérence modulo les observations des processus Interactions Les activités interagissent via (1) messages/services (2) ressources partagées (objets) Axiome: toute activité qui modifie un objet métier partagé est encapsulée dans un processus (= éviter les IHM de saisie sauvage ) La replication viole la modularité SLB-28 Y

41 Synchronisation et Processus
(1) Changement sur OM1 (?) Mise à jour replicat OM1 Données locales composant A composant B Données partagées (3) Nouvelle activité (2) Fin d’activité Référence OM (?) Mise à jour référence OM1 Moteur de Processus Deux flux d’information circulent : Signalisation du processus Mise à jour des objets distribués Il est important qu’ils soient synchronisés (pour la bonne exécution du processus) Exemple Pernod (« propagation trop rapide des processus ») Exemple Bouygues Telecom : messages « contextuels » qui combinent les deux flux Plus gros Plus complexe SLB-28 Y

42 Processus et Transactions Longues
La distribution des données exige une approche transactionnelle (reprise sur erreur) L’approche service (SOA) encapsule les données avec des transactions courtes Les processus servent à implémenter les transactions longues Début du processus Fin du processus Etat S1 initial cohérent : Une référence unique + Toutes les copies sont synchronisées Participants : l’état des objets est contenu dans les messages qui circulent Etat final cohérent (modification de la référence) succès Non-participants : l’état des objets est défini par la référence avec un « lock » sur l’écriture échec Retour à S1 par re-synchronisation des systèmes impliqués dans la Transaction depuis la référence Etat temporaire : deux parties= les systèmes qui participent à la transactions et les autres SLB-28 Y

43 Améliorer les développements informatiques
Praxeme, la méthodologie d'entreprise Améliorer les développements informatiques 10/04/2017 Assister et contrôler les développements en répondant aux question Quoi faire ? Préciser et Implémenter les modèles fournis dans les aspects amont (dérivation des modèles) Répondre aux exigences formulées et gérées Comment le faire ? Suivre une méthodologie indiquant les procédés, le contenu Définir et suivre un cadre architectural défini Comment vérifier ce qui a été fait ? Traçabilité par rapport aux modèles amont, aux éléments de cadrage (exigences) Complétude, pertinence, validation Environ 3 slides SLB-28 P

44 MDA : Approche centrée sur les modèles
Modèle des exigences : Définit le système dans son environnement Dérivation Modèle d’analyse et conception. Dérivation Modèle de Réalisation: Détermine comment le système est construit Génération Code du système. Artéfacts de configuration. La méthodologie (Praxeme) fournit la nature des différents modèles SLB-28 P

45 L’approche centrée sur les modèles (MDA): apports
Praxeme, la méthodologie d'entreprise L’approche centrée sur les modèles (MDA): apports 10/04/2017 Détermine « comment » représenter les facettes de l’entreprise et de son SI Support de la méthodologie : formalisme, règles de représentation, de cohérence, de production documentaire Supporte l’articulation des représentations (quoi faire) Transformation automatique des modèles entre chaque plan (exemple: passable de l’architecture logique au logiciel) Outille les règles d’architecture technique (quoi faire) Automatise la projection du modèle logique sur une architecture technique, selon des règles dédiées Assure la traçabilité (Comment vérifier) Automatique dans les dérivations Manuelle et outillées Productivité Automatisation des règles de dérivation Praxeme fournit les règles de dérivation Synchronisation modèle/code Environ 3 slides SLB-28 P

46 Adopter une méthodologie précise
Praxeme, la méthodologie d'entreprise Adopter une méthodologie précise 10/04/2017 Faire valoir l’apport de l’architecture d’entreprise Combattre les préjugés et le court-termisme Exemple 1 : agilité – celle du développement ou celle du système? Exemple 2 : les progiciels et l’intégration Défendre les activités de conception et de consolidation En s’appuyant sur des références partagées Assurer la continuité de la stratégie au déploiement Importance de l’architecture logique Guider les pratiques par des méthodes détaillées Rétablir la rigueur tout en augmentant la productivité Les procédés… SLB-28 D

47 Les règles de dérivation
Praxeme, la méthodologie d'entreprise Les règles de dérivation 10/04/2017 Du sémantique au logique Un pari sur l’universel Pour construire un noyau stable et largement partagé Du pragmatique au logique Un édifice formel Pour correspondre aux fédérations d’entreprises SLB-28 D

48 Conclusion de la partie 2
Praxeme, la méthodologie d'entreprise Conclusion de la partie 2 10/04/2017 La maîtrise de la complexité est une condition nécessaire de la compétitivité des entreprises Réduire les coûts et les délais Augmenter la qualité de service Innover (cf. 3e partie)  plus que jamais, l’urbanisation SI (EA) est indispensable au développement de l’entreprise À condition de renouveler l’approche Rôle fondateur de l’architecture de données Transformer à partir des processus SLB-28 Y

49 Comment valoriser les SI auprès des métiers ?
Praxeme, la méthodologie d'entreprise 3 Comment valoriser les SI auprès des métiers ? 10/04/2017 Contenu de cette partie Définir la vision Axes stratégiques et moyens Prendre en charge la connaissance du métier Formuler les exigences Nouvelles avancées Transformer l'entreprise Innovation et agilité Négocier les budgets SLB-28 P

50 “Business Architecture”
Praxeme, the enterprise methodology “Business Architecture” 4/10/2017 Partie de l’architecture d’entreprise dédiée au métier Liens avec la Topologie Praxeme Contribution Exclusive responsibility, ownership Possible negotiation SLB-28 P

51 Le Cadrage des travaux MOA/MOE: Objectifs
Fixer les objectifs de l’Entreprise Rassembler les connaissances métier Définir le domaine d’application et ses limites Cadrer les investissements dans l’entreprise Guider les choix et les priorités d’investissement Garantir que les nouveaux développement SI : Servent les objectifs de l’organisation et de ses managers Représentent correctement le métier Correspondent aux attentes MOA/Utilisateurs Améliorer la compréhension entre tous les intervenants Guider la modélisation Pertinence, complétude Les techniques de cadrage comprennent : L’analyse des objectifs La définition du dictionnaire La définition des règles métier L’analyse des besoins La gestion de la traçabilité Ce document est protégé par une licence « creative common ». Il peut être diffusé, reproduit, réutilisé, en tout ou en partie, à condition d’en citer l’origine et l’auteur. Les nouveaux matériaux produits doivent s’appliquer les mêmes conditions d’ouverture et de respect de la propriété intellectuelle. SLB-28 P

52 Le Cadrage – Positionnement
Praxeme, la méthodologie d'entreprise Le Cadrage – Positionnement 10/04/2017 Comment l’entreprise se définit, Ce qu’elle veut être Business Architecture Visions (Objectifs) Ce que l’on veut obtenir Modèles d’organisation Exigences Règles Métier Connaissance du domaine Vocabulaire Modèles du métier Modèles du SI SLB-28 P

53 Définir la vision d’une entreprise : Ses objectifs
Praxeme, la méthodologie d'entreprise Définir la vision d’une entreprise : Ses objectifs 10/04/2017 Définition Une Entreprise fonctionne sur un (ou plusieurs) métier(s) pour satisfaire certains Objectifs Business Model Des objectifs sont établis en cascade pour diriger l’action dans l’entreprise Des objectifs stratégiques… …jusqu’aux objectifs personnels En permanence, les parties prenantes se réfèrent aux objectifs établis pour répondre à la question « Pourquoi ? » Raison d’être, finalité Nécessité d’évolutions SLB-28 P

54 Définition des Objectifs
Praxeme, la méthodologie d'entreprise Définition des Objectifs 10/04/2017 Ce qu’une entreprise veut être Sa finalité, ses valeurs, son business model Comment elle compte se transformer Stratégie Ex : développer une nouvelle ligne métier, adresser de nouveaux marchés, maintenir sa position dans le marché et la compétition L’objectif n’exprime pas comment le résultat sera atteint Mais un objectif opérationnel participe au comment pour un objectif de plus haut niveau Objectif stratégique Long terme, défini qualitativement plutôt que quantitativement. Il doit être focalisé de sorte qu’il puisse être découpé en objectifs court termes Objectif tactique Court terme : est une étape décomposant un objectif long terme. Il comprend une date, et des critères de réalisation SLB-28 P

55 Propriété d’un Objectif
Praxeme, la méthodologie d'entreprise Propriété d’un Objectif 10/04/2017 Structuration Décomposition des objectifs stratégiques Comment peut il être réalisé? Les objectifs s’ordonnent dans l’arbre des objectifs Principe de rationalité de l’action Regroupement d’objectifs en objectifs plus larges Pourquoi l’objectif courant est-il nécessaire? Assignation des Objectifs Qui est responsable d’un Objectif : Rôle, Unité d’Organisation, Processus, Composant du SI Objectif « Corporate » Caractérisation Objectif quantifié (par opposition à qualitatif) Degré de satisfaction Problèmes Source Compatibilité (influence) entre objectifs SLB-28 P

56 Modèle d’Objectifs - Exemple
Praxeme, la méthodologie d'entreprise Modèle d’Objectifs - Exemple 10/04/2017 (modèle Modelio – SLB-28 P

57 Le Cadrage explicite et enrichit les modèles (1)
Praxeme, la méthodologie d'entreprise Le Cadrage explicite et enrichit les modèles (1) 10/04/2017 (modèle Modelio – SLB-28 P

58 Le Cadrage explicite et enrichit les modèles (2)
Praxeme, la méthodologie d'entreprise Le Cadrage explicite et enrichit les modèles (2) 10/04/2017 (modèle Modelio – « Optimiser taux de transformation Client », « Optimiser délai traitement dossier »  KPI = durée de traitement, taux de transformation SLB-28 P

59 Prendre en charge la connaissance du métier : La terminologie
Praxeme, la méthodologie d'entreprise Prendre en charge la connaissance du métier : La terminologie 10/04/2017 Effort pour capturer les vocabulaires dans l’entreprise  construire la référence terminologique de l’entreprise Savoir de quoi on parle (un besoin normatif) Élaborer un savoir commun (un besoin descriptif) Partager ce savoir (un besoin pédagogique) Les moyens Dictionnaire Thesaurus La référence fondamentale d'un domaine Réutilisable quelle que soit la technologie sous-jacente Facilite considérablement le nommage cohérent du modèle SLB-28 P

60 Le Dictionnaire Source du modèle sémantique
Praxeme, la méthodologie d'entreprise Le Dictionnaire Source du modèle sémantique 10/04/2017 (modèle Modelio – SLB-28 P

61 Formaliser les principes régissant le métier : Les règles « métier »
Praxeme, la méthodologie d'entreprise Formaliser les principes régissant le métier : Les règles « métier » 10/04/2017 Elles déterminent ce qui doit ou ne doit pas être fait Contraintes portant sur certains aspects du métier (règles de gestion) ou certains modes opératoires de l’entreprise (règles d’organisation) Exemples : Règles d’accès Règles de conversion Exploitation des règles Les règles de gestion relèvent de la sémantique métier Les règles d’organisation relèvent de l’organisation métier SLB-28 P

62 Praxeme, la méthodologie d'entreprise
Règles Métier - guides 10/04/2017 Les règles métier sont « atomiques » Elles ne se re-décomposent pas Les règles métier distinguent : Les activités métier acceptables Les activités à rejeter Elles requièrent très souvent des activités dédiées de traitement des violations Ces activités doivent être séparées de celles de traitement des activités normales Les règles métier ont un coût de gestion Ce coût doit être mis en balance avec celui des risques métier liés à leur violation Il y a un équilibre à trouver entre le nombre de règles et leur coût NB : Les règles de gestion sont incontournables SLB-28 P

63 Projection des Règles métier sur le modèle
Praxeme, la méthodologie d'entreprise Projection des Règles métier sur le modèle 10/04/2017 (modèle Modelio – SLB-28 P

64 Formuler les Exigences : Quand et Pourquoi
Praxeme, la méthodologie d'entreprise Formuler les Exigences : Quand et Pourquoi 10/04/2017 Un besoin est : Exprimé par une partie prenante Une capacité ou une condition qui doit être satisfaite pour résoudre un problème ou atteindre un objectif Une capacité qui doit être satisfaite pour satisfaire un contrat, standard, ou autre document imposé Source : BABoK – Business Analysis Book of Knowledge Il contractualise la relation MOA/MOE Il fait l’objet d’une négociation MOA/MOE Modèle métier + Exigences  Solution technique SLB-28 P

65 Analyse des besoins – Propriétés
Praxeme, la méthodologie d'entreprise Analyse des besoins – Propriétés 10/04/2017 Un Besoin… …doit être géré, en lui affectant des propriétés Origine, Bénéfice attendus, Coût, Risque, Stabilité, objectif de version …peut être classifié en types de besoins (exemple: fonctionnels, non fonctionnels, ergonomiques, etc.) Besoin fonctionnel: Exemple - Chaque client possède un compte auquel le commercial a accès Besoin non fonctionnel: Exemple - Les services d’accès au compte doivent être disponibles 24h/24 SLB-28 P

66 Analyse des Besoins - Exemples
Praxeme, la méthodologie d'entreprise Analyse des Besoins - Exemples 10/04/2017 Propriétés des exigences (modèle Modelio – Besoin fonctionnel : Chaque client possède un compte auquel le commercial a accès Besoin non fonctionnel : Les services d’accès au compte doivent être disponibles 24h/24 RM SLB-28 P

67 Formalisation des besoins : Exemple (Standard SysML)
Praxeme, la méthodologie d'entreprise Formalisation des besoins : Exemple (Standard SysML) 10/04/2017 (modèle Modelio – SLB-28 P

68 Exigences : quelques règles
Praxeme, la méthodologie d'entreprise Exigences : quelques règles 10/04/2017 Un besoin doit être : Compréhensible Atteignable Mesurable Dans les SI, les exigences initiales sont souvent démesurées Il faudra savoir ne retenir parmi elles que les 20% vraiment indispensables, leur sélection devant être dûment justifiée Bien souvent, on ne peut pas assigner de limite rationnelle à la richesse d’un outil, au détail d’un référentiel etc. Dans ce cas, il sera raisonnable de borner les exigences en se fixant une limite arbitraire en budget et en délai SLB-28 P

69 Transformation Rapide et Permanente
L’exigence d’agilité est partout, avec un « temps métier qui s’accélère » Cycles produits, offres, datamining « temps quasi-réel », etc. Une grande partie de l’innovation métier se projette sur le SI De + en +, « entreprise innovante » ≈ « SI agile » Trois formes d’agilité: Agilité tactique = faire vite et bien ce qu'on sait faire Agilité stratégique = arriver à faire le mieux possible ce qu'on ne sait pas faire (au premier abord) Réutiliser et recomposer Agilité structurelle = réduction de la complexité pour réduire les risques d’échec La complexité/la taille sont des facteurs principaux de risques (projets qui dérapent ou échouent) Maîtriser la croissance (nettoyer) et la complexité (architecture) It is now clear for me that the true difference in the outcome is not the set of expected benefits of a "disciplined/architected" approach, but rather the unexpected benefits (what one could call the strategic agility) and even more the avoidance of major problems in the future life of the IT system that is being built, mostly with respect to data integration. SLB-28 Y

70 Comment être agile ? Contourner la complexité
Contrecarrer ses effets par d’autres approches vertueuses Anticiper  Scénariser Découpler (donc installer des infrastructures) Urbaniser les modèles de données Recherche permanente de l’agrégation, de la mutualisation, de la simplification, de l’abstraction Automatiser - agilité technique Minimiser ce qui est manuel Technologies de la flexibilité : MDA, Moteurs de règles cf. ACMS (Agility Chain Management System) SLB-28 Y

71 Comment être agile ? (suite)
Agilité = modifier par paramétrage  (cf. MDA) Paramétrage « live » et « déclaratif » Live : pas d’arrêt pour changer « déclaratif » = accessible pour l’utilisateur et prouvable (partiellement) - réduction de l’effort de test « Urbanisation du paramétrage  » Mutualisation/ « centralisation » - par processus - du paramétrage Paramétrage métier qui s’appuie sur le modèle de donnée pivot Optimiser les processus (de transformation) Cf. CMMI : plus de maturité = plus d’agilité à terme Lean Management : supprimer ce qui est inutile et accélérer le temps de parcours SLB-28 Y

72 Comment être agile ? (fin) Architecture
Pattern « Publish & Suscribe » Définir les bons événements Différentes techniques d’implémentation EDA : Event Driven Architecture Exemple (Architecture Android) Extension dynamique des capacités d’upload de photo Intermédiation dynamique Principe : laisser un intermédiaire décider qui rend un service donné Standard SOA = UDDI (annuaire de services) Universal Description Discovery and Integration On peut faire de l’intermédiation dynamique sans UDDI  Traduire la généricité et l’abstraction du modèle de données dans le logiciel Exemple: paramétrisation des processus (vs. catalogue) Le projet UDDI a commencé en octobre 2000 par une collaboration entre Microsoft, Ariba, et IBM. D'autres entreprises s'y sont jointes comme Sun Microsystems, Oracle, HP ou encore SAP. Une version 2 a été mise au point en 2002. La version 3 a été mise au point en 2003, et a été adoptée par quelques entreprises en 2005 (pour information seulement). SLB-28 Y

73 Innovation, Transformation et Potentiel de situation
« In Search of Excellence » - Peters & Waterman Les compagnies innovantes sont particulièrement efficaces dans l’adaptation continues aux changements de leur environnement Les compagnie excellentes maîtrisent leur complexité interne : « La complexité cause la léthargie et l’inertie qui empêchent beaucoup d’entreprises d’être réactive » L’innovation requiert de la « marge de manœuvre » (loosely coupled systems) Cf. métaphore de l’empire et des barbares d’Octo « Conférence sur l’efficacité » - François Jullien Stratégie chinoise vs. Stratégie grecque  Potentiel de situation : ce qu’il faut développer à travers le système d’information Maximiser la capacité à profiter d’opportunité en développant le « potentiel » (sans être guidé par une prévision infaillible) From this analogy we can pick three key principles: One cannot do the architecture without knowing what "the future holds" from a business perspective : Service Architecture is about business Going from the shape to the folds is tricky : Architecture is not for "dummies", it requires thinking and abstraction One can overdo it and spend more time solving the puzzle than solving the business problem. It is easier to wrap a complex form than find the optimal set of folds that would help wrapping the most. SLB-28 Y

74 Négocier les budgets Le ROI de l’infrastructure d’intégration n’est pas simple L’infrastructure coûte cher La conception semble difficile au début ! alourdit les spécifications + essais/erreurs Tests complexes (courbe d’apprentissage) Exploitation et mise au point difficiles Facteurs clés Age moyen (taux de refonte) -> nettoyage Taux de renouvellement -> évolutions Le ROI se juge avec du recul Cycle complet de vie Quelle est la valeur de l’agilité ? Analyse de scénarios (avec et sans) SLB-28 Y

75 Analyse par phase Etude Impact-Spécification +20% -30% -: changement orientation processus +: simplification des impacts Développement 0% -20% +: Objet Métiers Mutualisés & Externalisation de la logique (processus) Développement (Intégration) -70% -: apprendre la technique « adaptateurs » +: un seul adaptateur à réaliser, réutilisation Intégration – UAT-VABE 10% +: conduite du changement - : capacité à automatiser les tests + modularité (test isolé d’un composant) Exploitation 20% +: orientation processus -: découplage des systèmes, flexibilité de l’hébergement Nettoyage -80% +: un seul fil à débrancher Il faut plusieurs cycles pour que les effets vertueux dominent les coûts d’installation SLB-28 Y

76 Mesurer la valeur de la flexibilité
La valeur associée à la flexibilité du système d’information, c’est-à-dire sa capacité à exploiter des opportunités futures, peut être mise en évidence par une analyse de scénarios La flexibilité est (presque toujours) un investissement « La valeur de la flexibilité n’existe que si le futur est incertain »  Exemples : Urbanisation et programme de refonte Exemple Bouygues Telecom: Lancements i-mode & Néo vs. Refonte du back-office La vision stratégique dépasse la vision tactique d’un ordre de grandeur Architecture SOA Coût de la mutualisation des services : on commence par un investissement pour un bénéfice qui se développe dans le futur Un service réutilisable coûte plus cher (classique) SLB-28 Y

77 Conclusion de la matinée
Praxeme, la méthodologie d'entreprise Conclusion de la matinée 10/04/2017 Développer les capacités de l’entreprise à transformer son SI Un cadre de référence commun pour une approche holistique La Topologie du Système Entreprise Une approche qui remet la connaissance au centre Fondamentaux du métier, sémantique, « données » Par opposition aux processus comme seuls points de départ Des procédés précis pour assurer le « développement durable » du Système Entreprise Et aussi, aider l’entreprise à se transformer elle-même Le pouvoir créatif de ces nouvelles approches L’architecte comme agent de transformation Reprendre les 3 messages : Approche holistique Données au centre Développement durable SLB-28 D

78 Praxeme, la méthodologie d'entreprise
Conclusion 10/04/2017 Pour en savoir plus Le site de l’association Praxeme Institute Les prochains événements Formation condensée « Praxeme en 2 jours » 20-21 mai 2010 Atelier « Praxeme et… les langues » Pour rester informé Liste de diffusion Adhésion individuelle gratuite Aidez-nous à vous aider : rejoignez-nous ! SLB-28 P


Télécharger ppt "Développer les capacités de l’entreprise à transformer son SI"

Présentations similaires


Annonces Google