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