vendredi 29 juin 2018

Etude de cas TOGAF

Le projet « Discount Travel for TOGAF » est un projet montrant comment modéliser en utilisant les normes UML et BPMN, l'architecture d'entreprise d'une agence de voyage pour gérer un système de réservation.

Cette étude de cas utilise un profil UML c’est-à-dire un ensemble d’icônes, de tagged value et de contraintes OCL personnalisant les artefacts UML pour s'appliquer aux concepts TOGAF, sans en changer la sémantique.

L’agence de voyage est à l’architecture d’entreprise ce que la bibliothèque est à UML ou le « Hello world » aux langages de programmation, c’est-à-dire l’exemple par lequel tout débutant se doit de commencer.
  
Ce projet de Modelio reprend l’exemple de la fameuse « agence de voyage », véritable étude de cas open source, maintes fois utilisée, qui est apparu pour la 1ère fois, illustrant le livre bestseller de Christophe Longépé « Le projet d'urbanisation du système d'information : Démarche pratique avec cas concret » (Dunod), qui est encore aujourd’hui considéré comme la bible de la démarche d’urbanisation du SI.

  1. Exemples d’études de cas d’architecture d’entreprise avec le framework TOGAF empruntés à l’outil français Modelio
     
  2. Exemple d’étude de cas TOGAF - Comment modéliser la phase A Vision de la méthode ADM : étape 1, les éléments de modélisation
     
  3. Exemple d’étude de cas TOGAF - Comment modéliser la phase A Vision de la méthode ADM : étape 2, matrice des parties prenantes (stakeholder)
     
  4. Tutorial, exemple d’étude de cas TOGAF - Analyser les objectifs - étape 3.1 de Comment modéliser la phase A Vision de la méthode ADM
     
  5. Etude de cas complète TOGAF, structure du projet et mode opératoire avec l’outil Modelio Business Analyst
     
  6. Comment modéliser les objectifs stratégiques et opérationnels en phase A Vision de la méthode ADM TOGAF ? (étape 3.2 de notre étude de cas)
     
  7. Cas complet de mise en œuvre TOGAF : l’artefact « catalogue d’objectifs » (étape 3.3 de notre didacticiel)
     
  8. Le catalogue des exigences de la phase A Vision de TOGAF : étape 4.1 de l’étude de cas
     
  9. Le diagramme SysML des exigences de la phase A Vision de TOGAF : étape 4.2 de l’étude de cas
     
  10. Le diagramme d’évènements de la phase A Vision de TOGAF : étape 5 de l’étude de cas Modelio
     
  11. Le diagramme des concepts de la solution de la phase A Vision de TOGAF : étape 6 de l’étude de cas Modelio
     
  12. Le diagramme de chaîne de valeur de la phase A Vision de TOGAF : étape 7 de l’étude de cas Modelio
     
  13. Comment modéliser la phase B Architecture métier de TOGAF - les éléments de modélisation - étape 8 de l’étude de cas
     
  14. Le dictionnaire métier de la phase B Architecture métier de TOGAF - étape 9 de l’étude de cas
     
  15. Le diagramme d’organisation des acteurs de la phase B Architecture métier de TOGAF - étape 10 de l’étude de cas
     
  16. Comment modéliser les flux échangés entre une entreprise et les acteurs externes en phase B architecture métier de TOGAF ? – étape 11 de l’étude de cas
     
  17. Diagramme des rôles joués par les acteurs en phase B architecture métier de TOGAF ? – étape 12 de l’étude de cas
     
  18. Diagramme d’organisation et de localisation en phase B architecture métier de TOGAF – étape 13 de l’étude de cas
     
  19. Diagramme de localisation en phase B architecture métier de TOGAF – étape 14 de l’étude de cas
     
  20. Diagramme de décomposition fonctionnelle en phase B architecture métier de TOGAF – étape 15 de l’étude de cas
     
  21. Diagramme objectifs-services métier en phase B architecture métier de TOGAF – étape 16 de l’étude de cas
     
  22. Diagramme de processus métier en phase B architecture métier de TOGAF – étape 17 de l’étude de cas
     
  23. Les règles métier en phase B architecture métier de TOGAF – étape 18 avec l’outil Enterprise Architect de Sparx Systems
     
  24. Diagramme de cas d’utilisation métier en phase B architecture métier de TOGAF – étape 19 de l’étude de cas Modelio
     
  25. Diagramme information - service métier en phase B architecture métier de TOGAF - étape 20 de l’étude de cas Modelio
     
  26. Diagramme supervision métier en phase B architecture métier de TOGAF – étape 21 de l’exemple complet emprunté à Modelio
     
  27. Diagramme des entités métier en phase B architecture métier de TOGAF - étape 22 du didacticiel
     
  28. Diagramme de cycle de vie des entités métier en phase B architecture métier de TOGAF - étape 23 de l'étude de cas
     
  29. Les éléments de modélisation avec UML de la phase C Architecture des Systèmes d'Information de TOGAF - étape 24 du tutoriel
     
  30. Le diagramme de communication des applications de la phase C Architecture des Systèmes d'Information de TOGAF - étape 25 du tutoriel
     
  31. Le diagramme de migration applicative de la phase C Architecture des Systèmes d'Information de TOGAF - étape 26 du cas complet Modelio
     
  32. Le diagramme de localisation des applications et des utilisateurs de la phase C Architecture des Systèmes d'Information de TOGAF - étape 27 de notre cas d’étude
     
  33. Le diagramme de cas d’utilisation applicatifs de la phase C Architecture des Systèmes d'Information de TOGAF - étape 28 de notre cas d’étude
     
  34. Le diagramme de réalisation des processus de la phase C Architecture des Systèmes d'Information de TOGAF - étape 29 du didacticiel
     
  35. Le diagramme de gestion d’entreprise de la phase C Architecture des Systèmes d'Information de TOGAF - étape 30 de l’exemple complet Modelio
     
  36. Le diagramme logique de données de la phase C Architecture des Systèmes d'Information de TOGAF - étape 31 de l’exemple complet Modelio
     
  37. Le diagramme de dissémination de données de la phase C Architecture des Systèmes d'Information de TOGAF - étape 32 du cas d’étude
     
  38. Le diagramme de sécurité des données de la phase C Architecture des Systèmes d'Information de TOGAF - étape 33 du cas pratique
     
  39. Le diagramme de migration des données de la phase C Architecture des Systèmes d'Information de TOGAF - étape 34 du tutorial Modelio
     
  40. Le diagramme des données de service de la phase C Architecture des Systèmes d'Information de TOGAF - étape 35 du tutorial Modelio
     
  41. Les éléments de modélisation avec UML de la phase D Architecture technique de TOGAF - étape 36 de l’exemple Modelio
     
  42. Le diagramme d’environnement et de localisation de la phase D Architecture technique de TOGAF - étape 37 de l’exemple Modelio
     
  43. Le diagramme de traitements de la phase D Architecture technique de TOGAF - étape 38 de l’exemple Modelio
     
  44. Le diagramme de matériel informatique en réseau de la phase D Architecture technique de TOGAF - étape 39 du tutorial Modelio
     
  45. Le diagramme de bénéfices de la phase E Solutions et opportunités de TOGAF - étape 40 de l’exemple Modelio
     
  46. Le diagramme de contextes de projets de la phase E Solutions et opportunités de TOGAF - étape 41 de l’exemple Modelio ) 

Rhona Maxwel
urbanisation-si.com/

"Encouragez l'innovation. Le changement est notre force vitale, la stagnation notre glas."
David M. Ogilvy

mercredi 14 octobre 2015

Dans le processus d'urbanisation du SI, il y en a pour tout le monde



Le processus d’urbanisation regroupe un ensemble de processus répartis de façon classique en 3 catégories : les macros processus opérationnels « cœur de métier », les macros processus de support (soutien) et les macros processus de pilotage
Les macros processus opérationnels « cœur de métier » :
  • 2 macros-processus stratégiques portant sur l'ensemble du SI 
  • 5 macros-processus dont le but est de développer les éléments constitutifs et transverses de la démarche : processus métier, données de références, échanges, applications, infrastructure.
  • 3 macros-processus portant sur la participation de la cellule urbanisme à la gestion des portefeuilles projets, aux études, aux projets et à la maintenance.
Les 2 macros processus de pilotage :
  • Piloter et mesurer l’efficacité de la politique d’urbanisation
  • Participer aux décisions de lancement des projets
Les 3 macros processus de support :
  • Gestion des cartographies du SI
  • Veille métier et technologique
  • Gestion et le développement des compétences de l’urbanisme
Ces activités de l'urbanisation du SI ne sont pas réalisées uniquement par la cellule urbanisme de l'entreprise mais bien par l'ensemble des acteurs y compris les métiers !
"Agir en homme de pensée, penser en homme d'action."
Henri Bergson

mardi 13 octobre 2015

Architecture d'entreprise : le framework de Zachman pour les nuls


Architecture d'entreprise : le framework de Zachman pour les nuls


Le système d’information d’une organisation peut s’organiser suivant une matrice (Framework de Zachman) ou les colonnes sont les traditionnels : Quoi (inventaires des données), Comment (processus métier), Ou (localisation, distribution), Qui (Acteurs, responsabilités), Quand (temporalité, fréquence), Pourquoi (motivations, objectif stratégiques) et les lignes représentent les niveaux du plus au moins abstrait : Contexte (identification du périmètre métier, planification), Conceptuel (concepts et modèles métiers), Logique (architecture, modèles de conception), Ingénierie (réalisation des entités métiers, spécifications techniques), Perspective physique (implémentations des composants métiers, outils) , Perspective entreprise (la réalisation des différentes activités dans l’entreprise) et les cellules représentent les artefacts à réaliser.


La métaphore de la cité : le POS (Plan d’Occupation des Sols) d’un SI a pour but :
• De définir les services et les responsabilités attachées à chaque sous-ensemble
• D’organiser le SI
• L’objet et la mission des applicatifs le composant
• Les regroupements d’applicatifs en ensemble cohérents
• Les périmètres réservés pour de futurs applicatifs à construire, notamment pour les applicatifs transversaux
Le POS d’un SI doit être compatible et s’aligné sur la stratégie de l’entreprise. Le dossier doit comporter :
• Synthèse sur les orientations et options retenues
• Un ensemble de cartographies (graphiques et commentaires associés) montrant avec précision les différentes subdivisions du SI et permettant de savoir à quels sous-ensembles du SI s’applique ou non une règle d’urbanisme donnée
• Les règles d’urbanisme ainsi que la définition de la mission et des services de chaque zone, quartier et îlot
• Annexes, CR d’entretiens, liste des personnes concernées, …
Le découpage en zones suit la typologie suivante :
• zone échange est responsable de l’acquisition/restitution du SI vis à vis de son environnement extérieur
• zone gisement de données : ensemble de toutes les informations dynamiques et pérennes ainsi que les services d’accès à ces données et assure la conservation et la valorisation du patrimoine d’informations, garantit sa cohérence et permet son enrichissement dans le temps
• zone référentielle des données de l’entreprise : regroupe l’ensemble de toutes les informations communes aux différents éléments du SI dont le cycle de vie est relativement stable
• zones opérations : on en trouve par métier principal
• zone ressource : regroupe les systèmes dédiés à la gestion des ressources internes (RH, comptabilité, …)
• zone pilotage
Les quartiers dans le SI sont des composants homogènes quant à la nature de l’information traitée. Ils correspondent à un sous-système. On a un couplage faible et une forte cohérence entre les quartiers. Ils regroupent les îlots qui sont les plus petits niveaux de décomposition du SI.
Un îlot :
• représente des entités (développées ou achetées) remplaçables du SI
• correspond à un but fonctionnel et avoir des accès à des bases de données
• reçoit ou émet des données vers d’autres îlots
• équivalent à une application ou une grande fonction applicative
• progiciel ou module d’un progiciel.
Mais à quoi peuvent bien ressembler les règles d’urbanisme ? Exemple :
• Interdictions comme d’accéder à un bloc sans passer par son port (prise)
• Limitations, par ex. une donnée doit être sous la responsabilité d’un et d’un seul bloc
• Prescription, par ex. tout bloc doit avoir un port (prise)
Parmi retours d’expérience les plus fréquemment cités :
• Les cartographies des applications existantes sont exhaustives et constituent un référentiel partagé, complet et administré de façon centralisé
• Les cartographies d’états futurs du SI sont moins fréquentes et leur niveau de détail est d’autant moins fin que l’on se projette dans un futur lointain
• La mise à jour des cartographies est réalisée dans la plupart des cas par des cellules dédiées mais la tendance est d’inscrire la mise à jour de la cartographie dans la méthodologie de conduite de projet
• La restitution des cartographies se fait par l’intermédiaire d’un intranet en général largement ouvert aux utilisateurs concernés
Néanmoins malgré sa très large généralisation, la cartographie applicative rencontre des difficultés :
• La coexistence de la cartographie de l’existant, de cartographie futures à différents horizons et d’une cartographie cible est difficile à obtenir
• La maîtrise de la cohérence du référentiel de cartographie, notamment en ce qui concerne les flux inter-applicatifs, nécessite un processus formalisé de mise à jour, qui n’est pas toujours en place ce qui nécessite d’effectuer des contrôles à posteriori
• La production de sous-ensembles cartographiques spécifiques n’est pas automatisée
• Le maintien à jour de la cartographie est difficile et nécessite organisation, suivi et support du management
Mais, la question qui intéresse tout le monde, c’est en quoi un environnement urbanisé peut-il réduire les coûts projet. Les réponses sont multiples :
• Mise à disposition d’informations sur le contexte fonctionnel et les applications
• Anticipation des impacts des autres projets
• Réduction des études amont et des études préalables
• Réduction du risque de fausse route
• Maîtrise du périmètre des projets
• Réduction des risques liés à la taille des projets
• Réduction des études, des développements et de la recette
• Existence de briques directement utilisables (composants, référentiels, EAI, ESB, données…)
• Existence de règles de construction qui permettent aux projets de se centrer sur les problèmes métier.
Pour les spécifications, on a un surcoût de l’ordre de 20% au départ pour passer à une orientation processus et une économie par la suite de 30% du à la simplification des études d’impact d’où un gain net de 10%.
Sur le développement on a un gain net de 20% car les objets métiers sont mutualisés et externalisés des processus.
L’intégration gagne en net un facteur de 40%. Il faut en effet au départ un surcoût de 30% pour acquérir le technique des bus logiciel et des adaptateurs mais une économie par la suite de l’ordre de 70% grâce à la réutilisation et au fait qu’il faille un seul adaptateur à réaliser pour se connecter au bus.
Ce que gagne l’exploitation, environ de l’ordre de 20% du aux découplages des systèmes et la flexibilité des hébergements, est perdu à cause des logiciels à mettre en œuvre (bus, logiciel d’administration, de surveillance, …).
Bien souvent, des applications obsolètes continuent de tourner par peur de couper le « mauvais fil » tellement les liens qui la relie au SI constitue un véritable plat de spaghetti. Si le SI est bien urbanisé, un seul lien à désactiver suffit d’où un gain net estimé à 80%.
Bien sur ces contributions continuent leurs effets dans les phases d’évolution ou de maintenance.
La gouvernance du SI optimise l’ensemble « fonctionnalités, coûts, délais » en misant sur l’urbanisation du SI. Chaque projet, lui aussi, optimise le même ensemble, mais à son échelle.
Pourquoi les projets sont-ils réticents à appliquer les règles d’urbanisme, parce qu’ils y voient une source de coûts additionnels.
La raison est que chaque projet voit les efforts de maintien ou d’amélioration de l’urbanisation comme générateurs de coûts. La raison d’être même des projets explique ce point de vue. En effet, un projet est constitué pour fournir, partant d’une situation donnée, une situation cible dans des coûts et délais déterminés. Les facilités que lui offrent son environnement, fruit des projets précédents, et les surcoûts éventuels qu’il génère aux projets suivants ne sont pas prises en compte par le projet. Un projet ne tient pas compte des efforts passés : il ne valorise pas dans son budget ce qui lui apporte un contexte urbanisé. Le projet n’a aucune nécessité de simuler quel aurait été son coût si la cartographie n’était pas à jour, s’il n’y avait pas de référentiels, si aucun mécanisme d’échange inter-applications n’était disponible, ... ce contexte à haute valeur ajoutée est considéré comme gratuit, alors qu’en fait, il s’agit d’une réduction de coût financée par les projets antérieurs. Un projet ne tient pas compte de la situation qu’il laisse: le projet ne valorise pas non plus le surcroît de travail qui sera demandé aux projets suivants et à la maintenance du produit si le projet dégrade l’urbanisation. Par contre, chaque jour de travail à maintenir ou améliorer l’urbanisation apparaît dans ses charges: tout naturellement, le projet va privilégier les ressources vers des tâches qui participent à l’atteinte de ses objectifs. Les tâches « pour la suite » apparaissent inévitablement comme des surcoûts.
Il faut se lancer dans l’urbanisation dès le départ du projet, les méthodes, les retours d’expérience et les outils existent et font qu’aujourd’hui urbaniser son SI n’est plus une aventure mais de la vulgaire routine.   

"Rien ne vous emprisonne excepté vos pensées. Rien ne vous limite excepté vos peurs. Et rien ne vous contrôle excepté vos croyances."
Marianne Williamson


Voir aussi :  

mardi 11 novembre 2014

Le Saint Graal de la gouvernance des investissements ?

Le Saint Graal de la gouvernance des investissements ?

Le niveau 1 de la gouvernance des investissements est la gestion de projet qui incombe à la MOE et dont les objectifs est la maîtrise des coûts, des délais et des risques.
Le niveau 2 est la gestion de programme, le nouveau paradigme de la MOA, qui s'intéresse essentiellement à la maîtrise des résultats.
Et enfin le niveau 3, la gestion de portefeuille comme référeniel de décision et qui a trait à la maîtrise de la valeur et qui relève de l'investisseur. Son organisation et son animation sont de la responsabilité du DSI.
Pour des investissements d'infrastructure comme la mise en place d'un ESB (Enterprise Service Bus) qui est la solution d'interopérabilité entre toutes les applications, les anciennes comme les nouvelles permettant de réaliser les concepts de communication par message de l'urbanisme du SI, bien souvent le rôle de la MOA est joué par la DSI. Malgré les avantages indéniables, les directions vous rétorquent que se ne sont que des slogans commerciaux des grands éditeurs logiciels cherchant à créer le buzz. Car les intérêts ne sont souvent pas compris par les métiers et les informaticiens voient d'un mauvais oeil l'arrivée d'une nouvelle architecture qu'ils ne connaissent pas et craignent de perdre leurs pouvoirs et leurs prérogatives. Il faudra alors concevoir et réaliser une conduite du changement réellement efficiente. 
D'autant plus que les résultats de ce type de projet d'infrastructure transverse ne sont pas visibles immédiatement. Ils le deviendront quand d'autres projets exploiteront les possibilités offertes. Voilà un brillant exemple où il est tout à fait judicieux d'adopter une gestion de programme.

"Celui qui va doucement va loin."
Proverbe laotien

Les outils d'APM (Application Portfolio Management)

Les outils d'APM (Application Portfolio Management)


L'APM (Application Portfolio Management) ou Gestion de Portefeuille de Projets est une méthode de gouvernance de SI dont le but est de capitaliser les ressources constituées par plusieurs évolutions du SI grâce aux recettes de retour sur investissement, de coût de maintenance, de développement ou de rachats.
Il existe de très nombreux éditeurs d'APM, citons parmi les principaux : CA Clarity Project Portfolio Management, Microsoft Project Server 2010, Oracle Primavera, HP Project et Portfolio Center, Compuware Changepoint, SAP CProjects et RPM, Serena Mariner, Planview Enterprise, Planisware, ...
Attention ces outils demandent une réelle compétence et doit s'accompagner d'un processus de réingénierie contribuant à la gouvernance :
  • réingénierie du processus de planification stratégique (élaboration du plan pluriannuel)
  • réingénierie du processus budgétaire (élaboration du plan opérationnel annuel)
  • réingénierie du processus de suivi et de contrôle des projets (évaluation continue des investissements en cours)
L'installation d'un tel logiciel entraîne de définir de manière formelle et codifiée le référentiel de valeurs. L'outil oblige aussi à rationaliser et codifier la description des projets, à codifier et industrialiser le reporting projet.
Il s'agit bien de la mise en place d'un référeniel complet poue décrire, manipuler et gérer le portefeuille des projets de la DSI mais pas pour gérer ces projets individuellement.
Si on y ajoute des activités hors projet comme la gestion des budgets de maintenance, d'infrastructures, le contrôle de gestion, tous les acteurs de la gouvernance (investisseus, contrôleur de gestion, MOA opérationnelle, MOE, ...) auront à leur disposition toutes les activités de la DSI et un référentiel commun partagé.

"La musique donne une âme à nos coeurs et des ailes à la pensée."
Platon 

Attention à votre portefeuille !

Attention à votre portefeuille !


La valeur des projets d'un portefeuille évolue dans le temps car le contexte peut changer et comme pour un coup de vent qui se prépare, il faudra réduire la voilure. Ceci se traduira en diminuant les investissements de tel ou tel projet et en revoyant les ambitions à la baisse. Tel budget pourra alors être alloué à un autre projet devenu plus prioritaire. Si les risques d'un projet deviennent trop importants parce que la MOA ne s'implique pas ou pour toute autre raison alors il est urgent de réaffecter les efforts sur d'autres projets. 
Plus facile à dire qu'à faire ! Comment procéder sans créer de désastre ?
La gestion de portefeuille donne les moyens d'évaluer de manière continue les projets et donc de prévoir les reconfigurations de projets. La valorisation et la structuration des projets s'obtiennent à partir du référentiel de valeurs qui doit être mis à jour en permanence. La mise en place d'un comité ad hoc pour la gestion effective du portefeuille  permet d'avoir une vision rationnelle sur les projets en cours et prendre les décisions qui s'imposent. Ce comité peut être le même que le comité informatique, d'architecture, stratégique de SI, de pilotage de SI, ..., mis en place par la DSI.
Ce comité est conseillé par la cellule urbanisme.

"Le moment donné par le hasard vaut mieux que le moment choisi."

lundi 10 novembre 2014

Qui nous dit qu'on a fait le bon choix ?

Qui nous dit qu'on a fait le bon choix ?


Un investissement doit déboucher sur les résultats prévus et toujours pertinents au moment de la livraison. Ceci implique forcément d'inclure la mesure de ces résultats dans la gestion de projet c'est à dire avant qu'il ne commence.
La gestion de programme, qui par définition consiste à livrer des résultats et non pas un investissement, va boulverser les habitudes de la MOA qui doit réussir à livrer le résultat attendu. Toute ses actions ne doivent concerner que cet objectif, que ce soit ses expression de besoin, ses demandes de changement, ses recettes, la conduite du changement, ...
Attention au projets qualifiés, par des directeurs ambitieux, de stratégiques et pharaoniques, mais n'appartenant à aucun programme. De nombreux projets ont été stoppés à cause de conflits d'intérêts, de l'ambition de certains directeurs, de la non-implication des métiers et des utilisateurs, de l'insuffisance de la conduite du changement, des conflits avec la MOE externe, des techniques mais surtout du fait qu'ils n'aient rien d'autre à livrer que l'investissement qu'ils contruisaient.
Pour faciliter la mise en oeuvre d'une gestion de programme, il faut une gestion des engagements consistant à jalonner le projet de différentes étapes au cours desquelles la MOA s'engage un peu plus sur le chemin de la concrétisation des résultats. Ces jalons sont autant d'opportunités de reconfiguration de l'investissement. La MOA doit faire un point sur la valeur de l'investissement par rapport aux résultats escomptés permettant éventuellment de reconfigurer le programme. On doit faire apparaître les étapes de livraison des résultats. Les résultats livrés sont des résultats mesurés. A chaque jalon il faut pouvoir réévaluer le programme et remettre en cause son intérêt.
De trop nombreux projets se sont retrouvés dans un état ou les décideurs étaient dans l'incapacité de remettre en cause les décisions initiales et se sont transformés en catastrophes ! Il faut savoir geler, reconfigurer, réaligner ou accélérer un projet, bref être en capacité de tout remettre en cause.

"Le bonheur ne vient pas à ceux qui l'attendent assis."

L'article sélectionné :

Etude de cas TOGAF

Le projet « Discount Travel for TOGAF » est un projet montrant  comment modéliser  en utilisant les normes UML et BPMN,  l'architecture...

Les articles les plus consultés :