D - PowerPoint PPT Presentation

About This Presentation
Title:

D

Description:

Mod le de pr sentation pour la communication Praxeme. NB : il existe un mod le plus sp cialis pour les supports de formation. – PowerPoint PPT presentation

Number of Views:114
Avg rating:3.0/5.0
Slides: 72
Provided by: Domini104
Learn more at: https://www.praxeme.org
Category:

less

Transcript and Presenter's Notes

Title: D


1
Développer les capacités de lentreprise à
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

2
Objectif de la conférence
  • Objectif
  • Messages clefs
  • Une approche holistique est nécessaire pour
    assurer lalignement 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 dun
    développement durable du SI

Contribuer au renouveau de lurbanisation
des systèmes dinformation
Durée de la présentation 2 h 40
D
3
Contenu de la conférence
D
4
Ordre du jour
Partie Horaire Durée
Une nouvelle approche des SI (DVAU) 9h50 45
Comment réduire la complexité de son SI et pourquoi (YCS) 11h 45
Comment valoriser les SI auprès des métiers (PhD) 11h45 45
Conclusion Fin 12h30
Pause à 10h35
QR
QR
D
5
Une nouvelle approche des SI
1
  • 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

D
6
Lurbanisation des SI Les leçons du passé
  • Le défi permanent Maintenir une articulation
    entre
  • Vision stratégique / vision métier / vision
    informatique
  • Connaissance de lexistant / vision du futur
  • Gestion de lurgence opérationnelle /vision
    architecturale long terme
  • Les limites des pratiques usuelles
  • Intégration des niveaux de description dun
    système cible
  • Stratégie, processus, fonctionnel, applicatif et
    technique
  • Il ne sert à rien de produire de beaux plans
    sils ne sont pas réalisables dun point de vue
    technique et si on nest pas en mesure dassurer
    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.

P
7
Lurbanisation des SI Conflits des paradigmes
  • Quelles notions doivent sous-tendre
    lurbanisation?
  • 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

P
8
Architecture à base dapplications
Lorientation Silo
  • Une application un silo applicatif
  • Une entreprise taille CAC 40 de 10 000 à 50 000
    applications

Appli-nouvelle
Appli1
Appli2
Appli-n
P
9
Lapproche fonctionnaliste (exemple) illustration
Une approche strictement statique Pas d'analyse
des dépendances
Référence à des choix techniques
Critère de décomposition fonctionnel
Si on analyse les dépendances
P
10
Lanalyse des dépendances
P
11
Un découpage fonctionnel Hiérarchique
  • À noter
  • Même aproche dans les Business Capability Models
  • Ex. ACORD
  • Culture

P
12
Lapplication une notion qui sestompe
  • Lapproche 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 dautres SI
  • Lensemble nest plus un système isolé
  • On parle de  fédérations de systèmes 
  • Un accès aux services
  • Dépendant de lutilisateur (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

P
13
Approcher le Système Entreprise sous tous ses
angles
  • Notion de Système Entreprise
  • Volonté de restaurer une certaine rationalité
  • Cf. Enterprise Transformation Manifesto
  • www.enterprisetransformationmanifesto.org
  • Nécessité dun 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
    lentreprise

D
14
Le cadre de référence méthodologique
Aspect politique (cadrage)
La Topologie du Système Entreprise
D
15
Lentreprise et son SI en tant que système
Finalité
Aspect Politique
Business Model (CEISAR)
Evolution
Changements
Structure
Organisation (CEISAR)
Aspect pragmatique
Aspect sémantique
Modèle Processus
Objets
Fonctionnelle
Aspect logique
Système décisionnel
Aspect pragmatique
Système dinformation
Aspect géographique
Système opérant
Aspect logiciel
processus
SI
Le SI est lui-même un système
Aspect physique, matériel
environnement
Flux entrants
Y
16
Systèmes complexes
  • Définition dun système complexe
  • Un système est un ensemble déléments en
    interaction dynamique, organisé en fonction dun
    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 lensemble.
  • 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é  dun 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
Y
17
Le  Système Entreprise  est complexe
  • Caractéristiques
  • Complexité numérique
  • Multi-échelle
  • Complexité temporelle
  • Richesse des interactions avec lenvironnement
  • Exemples de symptômes
  • Coûts (évolution du SI)
  • Exemple Évolution non-linéaire du coût des
    projets
  • Taux derreur/ panne
  • Difficulté à  garantir  la robustesse et la
    tolérance aux pannes
  •  Ross Ashby  La régulation dun système
    (complexe) nest efficace qui si elle sappuie
    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 dintégration dépend de la
    taille de lhôte ?
  • Complexité humaine (organisation)
  • défaut de modularité (calcul dimpact et
    interaction)
  • Conséquences inattendues Feature Interaction
    Problem

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 !
  • Sy 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 dEntreprise 
  • Aligner les  parties prenantes 
  • Intégrer l environnement du SI  dans la vision

Y
19
Revenir à l'essentiel
  • Exprimer les fondamentaux
  • La connaissance du métier
  • Les objectifs de lentreprise
  • Être capable dinnover
  • Traiter au mieux le métier
  • Sans se soucier de lorganisation
  • Adopter dautres modes dorganisation
  • Assurer lalignement
  • Lorganisation avec le métier et les objectifs
  • Le SI avec lensemble
  • Nécessité de changer nos pratiques pour mieux
    innover, et assurer lalignement

P
20
Le  métier  Élément fondamental des
entreprises
  • 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 lorganisation et le
    fonctionnement des entreprises

P
21
La  vision  La raison dêtre dune entreprise
  • Ce quune 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 quil 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

P
22
Lorganisation Ce quest et sera lentreprise
  • Histoire et mode de fonctionnement de
    lentreprise
  • Les unités dorganisation, les rôles, la
    hiérarchie
  • Les responsabilités
  • Localisation, Géographie, contexte culturel
  • Les processus métier
  • Les activités de lentreprise, sa valeur ajoutée

P
23
Transformer le système
  • Les changements dans nos disciplines préparent la
    transformation des entreprises
  • Une discipline pour couvrir tous les aspects de
    lentreprise
  • Enterprise Architecture
  • Méthodologie dentreprise
  • Deux changements clefs dans la façon
    dappréhender lentreprise
  • La  bonne  description du métier
  • La  bonne  structure du système informatique

D
24
La bonne description du métier
  • 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é

Aspect sémantique
Objets
Objets  métier , objets réels (InformationTrans
formationAction)
Se réfère à
Aspect pragmatique
Activités
Acteurs et entités organisationnellesProcessus
cas dutilisation
D
25
La bonne structure du système informatique
  • 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 sémantique
Aspect logique
Objets
Services logique agrégats (machines logiques)
Dérive
Objets  métier , objets réels (InformationTrans
formationAction)
Aspect pragmatique
Activités
Dérive
Acteurs et entités organisationnellesProcessus
cas dutilisation
SOA
D
26
Le changement de physionomie
Caricature dune architecturefondée sur le
critère fonctionnel
Schéma de principedune architecture
logiqueselon Praxeme
DF
DF
DF
DF
DO
DO
DO
OM
DO
DO
OM
DF
DF
DF
DF
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 dobjets
    (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.

D
27
Conclusion de la partie 1
  • 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
    dentreprise

D
28
Comment réduire la complexité de son SI et
pourquoi ?
2
  • Contenu de cette partie
  • Coordonner larchitecture 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

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 dingé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,
    lorsquon saperçoit quon est devenu immobile,
    il est trop tard
  • Favoriser lalignement stratégique
  • Il est difficile daligner ce quon ne maîtrise
    pas ?

Y
30
Comment maîtriser la complexité dun SI ?
  • Approche simple
  • Cartographie (utilité de UML2)
  • Approche systématique
  • Architecture dentreprise, une démarche
    transverse dalignement sur une cible et une
    transformation
  • Approche technologique
  • Infrastructure (middleware)
  • Introduction de découplage, de mutualisation et
    dintermédiation
  • Approche de bon sens
  • Standardisation énergique
  • Réduire lhé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

Y
31
Réponse technologique Infrastructure
  • Les middleware ont pour vocation de réduire la
    complexité technique (même sils 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 larchitecture dentreprise
  • Besoin de plus de maturité
  • Loutillage 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)

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 lentreprise vers lavant (le plus souvent)
  • Support à lautomatisation
  • Permet de sappuyer sur les bonnes pratiques (des
    autres)
  • Difficultés de la démarche
  • Résistance au changement
  • Surtout dans le contexte distribué dune 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)

Y
33
Réponse complexe Découplage et modularité
  • Cest une sous-partie de la démarche
    durbanisation
  • 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 dinteraction (DSM) / partitionnement de
    graphe
  • Architectures en couches (propagation
    logarithmique des impacts)
  • Mais surtout un art qui sapprend par expérience
  • Ex faire des scénarios (cf.  règle  des
    systèmes complexes)

Y
34
Réponse stratégique SOA
  • Pourquoi ?
  • Méthode de transformation perpétuelle et effort
    continu de lensemble des acteurs
  • SOA favorise la modularité
  • Favorise mutualisation/ réutilisation -gt
    réduction possible de complexité
  • Gouvernance SOA
  •  affirme en premier lieu lexistence dun
    certain nombre dartefacts (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 darchitecture

Y
35
Développement Durable du SI
  •  développer les services informatiques
    daujourdhui 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 nest pas la seule façon durbaniser (au sens
    organiser pour réduire la complexité) un SI
  • La méthode pour le faire de façon continue, en
    tant que pratique dentreprise (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

Y
36
Complexité et SOA
  • Gestion du catalogue
  • 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 sen plaindre, cest un bon
    symptôme.?
  • En revanche, cela requiert une véritable
    discipline.

Richesse Fonctionnelle interfaces
Early Adopters (N2)
Rupture
Rupture
Tous les ST utilisent (N2)
Temps Roadmap Versions
Version N Version N1 Version N2
Y
37
Données et processus
  • Coordonner larchitecture 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 laspect sémantique
  • Domaines dobjets
  • Possibilité de décomposition génériques
  • La délimitation des bases de données
  • Dans laspect logique
  • On cherche à la rendre compatible avec la
    structuration logique

D
38
Bases et blocs dans laspect logique
Plan des Services
blocs logiques
Quel niveau dagrégat ?
Plan des Données
Le plan des services masque le plan des données
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.)
  • Sil 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 larchitecture de
    données (diviser pour régner) et utiliser des
    solutions  du commerce 

Y
40
Architecture de données les questions
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 gt 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é
Y
41
Synchronisation et Processus
(1) Changement sur OM1
(?) Mise à jour replicat OM1
Données locales
composant A
composant B
Donnéespartagées
(3) Nouvelle activité
(2) Fin dactivité
Référence OM
(?) Mise à jour référence OM1
Moteur de Processus
  • Deux flux dinformation circulent
  • Signalisation du processus
  • Mise à jour des objets distribués
  • Il est important quils 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

Y
42
Processus et Transactions Longues
  • La distribution des données exige une approche
    transactionnelle (reprise sur erreur)
  • Lapproche 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
Etat final cohérent (modification de la référence)
Participants  létat des objets est contenu
dans les messages qui circulent
succès
Retour à S1 par re-synchronisation des
systèmes impliqués dans la Transaction depuis
la référence
échec
Non-participants  létat des objets est défini
par la référence avec un  lock  sur lécriture
Etat temporaire  deux parties les systèmes qui
participent à la transactions et les autres
Y
43
Améliorer les développements informatiques
  • 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

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 danalyse 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
P
45
Lapproche centrée sur les modèles (MDA) apports
  • Détermine  comment  représenter les facettes de
    lentreprise et de son SI
  • Support de la méthodologie formalisme, règles
    de représentation, de cohérence, de production
    documentaire
  • Supporte larticulation des représentations (quoi
    faire)
  • Transformation automatique des modèles entre
    chaque plan (exemple passable de larchitecture
    logique au logiciel)
  • Outille les règles darchitecture 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

P
46
Adopter une méthodologie précise
  • Faire valoir lapport de larchitecture
    dentreprise
  • 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 lintégration
  • Défendre les activités de conception et de
    consolidation
  • En sappuyant sur des références partagées
  • Assurer la continuité de la stratégie au
    déploiement
  • Importance de larchitecture logique
  • Guider les pratiques par des méthodes détaillées
  • Rétablir la rigueur tout en augmentant la
    productivité
  • Les procédés

D
47
Les règles de dérivation
  • Du sémantique au logique
  • Un pari sur luniversel
  • Pour construire un noyau stable et largement
    partagé
  • Du pragmatique au logique
  • Un édifice formel
  • Pour correspondre aux fédérations dentreprises

D
48
Conclusion de la partie 2
  • 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, lurbanisation SI (EA) est
    indispensable au développement de lentreprise
  • À condition de renouveler lapproche
  • Rôle fondateur de larchitecture de données
  • Transformer à partir des processus

Y
49
Comment valoriser les SI auprès des métiers ?
3
  • 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

P
50
Business Architecture
  • Partie de larchitecture dentreprise dédiée au
    métier
  • Liens avec la Topologie Praxeme

Exclusiveresponsibility, ownership
Contribution
Possible negotiation
P
51
Le Cadrage des travaux MOA/MOE Objectifs
  • Fixer les objectifs de lEntreprise
  • Rassembler les connaissances métier
  • Définir le domaine dapplication et ses limites
  • Cadrer les investissements dans lentreprise
  • Guider les choix et les priorités
    dinvestissement
  • Garantir que les nouveaux développement SI
  • Servent les objectifs de lorganisation 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
  • Lanalyse des objectifs
  • La définition du dictionnaire
  • La définition des règles métier
  • Lanalyse des besoins
  • La gestion de la traçabilité

P
52
Le Cadrage Positionnement
Business Architecture
Comment lentreprise se définit, Ce quelle veut
être
Visions (Objectifs)
Ce que lon veut obtenir
Modèles dorganisation
Exigences
Règles Métier
Connaissance du domaine
Vocabulaire
Modèles du métier
Modèles du SI
P
53
Définir la vision dune entreprise Ses objectifs
  • 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 laction dans lentreprise
  • Des objectifs stratégiques
  • jusquaux 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

P
54
Définition des Objectifs
  • Ce quune 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
  • Lobjectif nexprime 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
    quil 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

P
55
Propriété dun Objectif
  • Structuration
  • Décomposition des objectifs stratégiques
  • Comment peut il être réalisé?
  • Les objectifs sordonnent dans larbre des
    objectifs
  • Principe de rationalité de laction
  • Regroupement dobjectifs en objectifs plus larges
  • Pourquoi lobjectif courant est-il nécessaire?
  • Assignation des Objectifs
  • Qui est responsable dun Objectif Rôle, Unité
    dOrganisation, Processus, Composant du SI
  • Objectif  Corporate 
  • Caractérisation
  • Objectif quantifié (par opposition à qualitatif)
  • Degré de satisfaction
  • Problèmes
  • Source
  • Compatibilité (influence) entre objectifs

P
56
Modèle dObjectifs - Exemple
(modèle Modelio www.modelio.fr)
P
57
Le Cadrage explicite et enrichit les modèles (1)
(modèle Modelio www.modelio.fr)
P
58
Le Cadrage explicite et enrichit les modèles (2)
(modèle Modelio www.modelio.fr)
  •  Optimiser taux de transformation Client ,
     Optimiser délai traitement dossier  ? KPI
    durée de traitement, taux de transformation

P
59
Prendre en charge la connaissance du métier La
terminologie
  • Effort pour capturer les vocabulaires
    dans lentreprise ? construire la référence
    terminologique de lentreprise
  • 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

P
60
Le Dictionnaire Source du modèle sémantique
(modèle Modelio www.modelio.fr)
P
61
Formaliser les principes régissant le métier
Les règles  métier 
  • 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 lentreprise (règles
    dorganisation)
  • Exemples
  • Règles daccè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 dorganisation relèvent de
    lorganisation métier

P
62
Règles Métier - guides
  • 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

P
63
Projection des Règles métier sur le modèle
(modèle Modelio www.modelio.fr)
P
64
Formuler les Exigences Quand et Pourquoi
  • 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 lobjet dune négociation MOA/MOE
  • Modèle métier Exigences ? Solution technique

P
65
Analyse des besoins Propriétés
  • 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 daccès au compte doivent
    être disponibles 24h/24

P
66
Analyse des Besoins - Exemples
Propriétés des exigences
(modèle Modelio www.modelio.fr)
  • Besoin fonctionnel Chaque client possède un
    compte auquel le commercial a accès
  • Besoin non fonctionnel Les services daccès au
    compte doivent être disponibles 24h/24

RM
P
67
Formalisation des besoins Exemple (Standard
SysML)
(modèle Modelio www.modelio.fr)
P
68
Exigences quelques règles
  • 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 dun outil, au détail
    dun 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

P
69
Transformation Rapide et Permanente
  • Lexigence dagilité est partout, avec un  temps
    métier qui saccélère 
  • Cycles produits, offres, datamining  temps
    quasi-réel , etc.
  • Une grande partie de linnovation métier se
    projette sur le SI
  • De en ,  entreprise innovante   SI
    agile 
  • Trois formes dagilité
  • 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)

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

Y
71
Comment être agile ? (suite)
  • Agilité modifier par paramétrage ? (cf. MDA)
  • Paramétrage  live  et  déclaratif 
  • Live pas darrêt pour changer
  •  déclaratif  accessible pour lutilisateur et
    prouvable (partiellement) - réduction de leffort
    de test
  •  Urbanisation du paramétrage  
  • Mutualisation/  centralisation  - par
    processus - du paramétrage
  • Paramétrage métier qui sappuie sur le modèle de
    donnée pivot
  • Optimiser les processus (de transformation)
  • Cf. CMMI plus de maturité plus dagilité à
    terme
  • Lean Management supprimer ce qui est inutile
    et accélérer le temps de parcours

Y
72
Comment être agile ? (fin) Architecture
  • Pattern  Publish Suscribe 
  • Définir les bons événements
  • Différentes techniques dimplémentation
  • EDA Event Driven Architecture
  • Exemple (Architecture Android)
  • Extension dynamique des capacités dupload 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 lintermédiation dynamique sans
    UDDI ?
  • Traduire la généricité et labstraction du modèle
    de données dans le logiciel
  • Exemple paramétrisation des processus (vs.
    catalogue)

Y
73
Innovation, Transformation et Potentiel de
situation
  •  In Search of Excellence  - Peters Waterman
  • Les compagnies innovantes sont particulièrement
    efficaces dans ladaptation continues aux
    changements de leur environnement
  • Les compagnie excellentes maîtrisent leur
    complexité interne  La complexité cause la
    léthargie et linertie qui empêchent beaucoup
    dentreprises dêtre réactive 
  • Linnovation requiert de la  marge de manœuvre 
    (loosely coupled systems)
  • Cf. métaphore de lempire et des barbares dOcto
  •  Conférence sur lefficacité  - François
    Jullien
  • Stratégie chinoise vs. Stratégie grecque ?
  • Potentiel de situation ce quil faut développer
    à travers le système dinformation
  • Maximiser la capacité à profiter dopportunité en
    développant le  potentiel  (sans être guidé par
    une prévision infaillible)

Y
74
Négocier les budgets
  • Le ROI de linfrastructure dintégration nest
    pas simple
  • Linfrastructure coûte cher
  • La conception semble difficile au début !
    alourdit les spécifications essais/erreurs
  • Tests complexes (courbe dapprentissage)
  • Exploitation et mise au point difficiles
  • Facteurs clés
  • Age moyen (taux de refonte) -gt nettoyage
  • Taux de renouvellement -gt évolutions
  • Le ROI se juge avec du recul
  • Cycle complet de vie
  • Quelle est la valeur de lagilité ?
  • Analyse de scénarios (avec et sans)

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) -30 -70 - apprendre la technique adaptateurs un seul adaptateur à réaliser, réutilisation
Intégration UAT-VABE 10 -30 conduite du changement - capacité à automatiser les tests modularité (test isolé dun composant)
Exploitation 20 -20 orientation processus - découplage des systèmes, flexibilité de lhébergement
Nettoyage 0 -80 un seul fil à débrancher
Il faut plusieurs cycles pour que les effets
vertueux dominent les coûts dinstallation
Y
76
Mesurer la valeur de la flexibilité
  • La valeur associée à la flexibilité du système
    dinformation, cest-à-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é nexiste 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
    dun 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)

Y
77
Conclusion de la matinée
  • Développer les capacités de lentreprise à
    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 lentreprise à se transformer
    elle-même
  • Le pouvoir créatif de ces nouvelles approches
  • Larchitecte comme agent de transformation

D
78
Conclusion
  • Pour en savoir plus
  • Le site de lassociation Praxeme Institute
  • www.praxeme.org
  • 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
  • http//groups.google.com/group/Praxeme-Annonces
  • Adhésion individuelle gratuite
  • http//friends.praxeme.org/adhesion

Aidez-nous à vous aider rejoignez-nous !
P
Write a Comment
User Comments (0)
About PowerShow.com