Le condensé de l’ouvrage Architecture et transformation de l'entreprise et du SI de Romain Hennion
Cet ouvrage décrit la méthode d’architecture d’entreprise BATP (Business Architecture Transformation Program) de la société Global Knowledge, qui est une adaptation pratique de TOGAF (The Open Group Architecture Framework) en fonction de leurs nombreux retours d’expérience internationaux.
Parution : 2014
L'auteur : Romain Hennion
- Directeur de Projets en CyberSécurité - FORMIND (2021),
- Directeur Programme Cyber Security Consulting - Oteria Cyber School (2021),
- Responsable Pédagogique Cybersécurité - Ecole Centrale Paris (2013 - 2021),
- Directeur Cyber Security & Risk - Deloitte (2018 - 2021),
- Auditeur ISO - PECB Europe (2011 - 2020),
- Directeur Gouvernance, CyberSécurité et Audit - Global Knowledge France (2008 - 2018).
- Et pas moins d’une vingtaine de certifications (Iso 27701 Lead Manager, ISO 27032 CyberSecurity Lead Manager, ISO 27005 Risk Manager - Approved Trainer, Cobit, Itil, Lean Six Sigma, Prince2, Togaf…)
Etat de l’art et avenir de l’architecture d’entreprise
Les premiers chapitres sont évidemment consacrés à la définition de l’architecture d’entreprise, en insistant sur l’agilité comme impératif, la gouvernance, la conformité aux règles et la performance. Les missions stratégique, métier et Système d’Information de l’entreprise sont rappelées. L’auteur expose un historique qui va jusqu’aux situations actuelles comme le recentrage sur le cœur de métier et l’externalisation de fonctions comme la paye et pour l’informatique avec des solutions de cloud computing.
D’après lui, l’avenir de l’architecture d’entreprise pourrait se trouver dans les patterns organisationnels modélisant les structures communes de plusieurs entreprises.
L'analyse systémique est présentée avec beaucoup de pédagogie. Les aficionados du savoir encyclopédique, trouveront leur bonheur au chapitre panorama des méthodes avec le modèle du MIT CISR (Center for Information System Research), le modèle du FEA (Federal Enterprise Architecture), le framework de Zachman, TOGAF (The Open Group Architecture Framework), le modèle de McKinsey.
Les outils de modélisation sont répertoriés comme BPMN, à cette occasion l’auteur en profite pour parler de la méthode Lean Six Sigma, méthode d’identification des critères de qualité, de mesure de la performance et d’optimisation des processus.
Les limites du BPM comme les processus métier dynamiques et ad hoc sont trop souvent mis sous silence et ont le mérite d’être citées ici.
L’architecture d’entreprise au quotidien
En ce qui concerne la modélisation du SI, une large part est consacrée à UML, avec le diagramme de cas d’utilisation et le diagramme d’activité pour les scénarios.
SOA et une de ses implémentations avec les Services Web sont largement détaillés en introduisant des technologies comme Java.
A notre avis, cette partie n’a rien à faire dans un tel ouvrage. En effet, de nos jours, les Services Web sont remplacés par l’architecture microservices. L’auteur aurait dû, comme Yves Caseau dans son livre “Urbanisation, SOA et BPM", prendre de la hauteur en restant au niveau des concepts sans introduire de technologies d’implémentation.
La méthode BATP
(Business Architecture Transformation Program)
Présentation
C’est seulement dans la deuxième moitié du livre que l’on voit enfin en détail TOGAF qui est quand même le sous-titre du livre. Et là, on est un peu déçu, car l’auteur Romain Hennion, qui a été Directeur “Architecture et Gouvernance” chez Global Knowledge (Formation et conseil) détaille dans le reste de l’ouvrage la méthode BATP (Business Architecture Transformation Program).
Certes, BATP s’appuie à la base sur les phases du cycle de vie de l’ADM (Architecture Development Method), le cœur de TOGAF, mais comme toute méthode, elle possède sa propre terminologie et concept qui déroute au premier abord tout connaisseur de TOGAF. Leur méthode BATP, nous dit-on, n’est que le fruit de l’évolution de TOGAF, Global Knowledge, l’a déployée des centaines de fois à travers le monde.
Leur méthode comprend 5 étapes composées de tâches, que nous allons détailler.
S’engager
L'événement correspondant à l’identification d’une opportunité client déclenche la 1ère étape dite d’engagement. L’objectif est d’améliorer le métier grâce à un processus de transformation de l’organisation. Les architectes d’entreprise, souvent d’anciens architectes logiciel, doivent de nos jours, se focaliser sur l’évolution et la transformation au niveau du métier, et non plus au niveau des technologies ou du SI.
Si l’architecte est interne à l’organisation, il établit sa propre crédibilité personnelle avec le métier et les parties prenantes, il doit montrer la valeur de la démarche d’architecture accompagnée de sa méthode. S’il est consultant externe, il doit démontrer sa crédibilité ainsi que celle de la société qu’il représente.
La première étape de la phase d’engagement est d’établir la vue des besoins métier, formuler les perspectives explicites ou implicites de l’organisation en utilisant l’outil “business model canvas” qui présente la manière dont une organisation crée de la valeur et se l’approprie.
Exemple de Business Model Canvas : Gérer un stand de limonade, template emprunté à Visual Paradigm
L’architecte doit ensuite affiner la vue des besoins des entreprises en interviewant les dirigeants.
Pour préparer ces entretiens, on utilise le “stakeholder matrix”.
Stakeholder Matrix, template emprunté à Visual Paradigm
L’outil est le cadre classique pour les questions stratégiques, qu’est ce qui ne fonctionne pas ou qui freine le développement de la société, en distinguant les faits des opinions, l’objectif est d’inciter la DG à prendre des mesures.
La dernière tâche de cette 1ère étape consiste à préparer la proposition de vision et de périmètre de l’architecture. L’architecte décrit les avantages quantitatifs et qualitatifs d’une démarche d’architecture d’entreprise.
Collecter et Analyser
L’objectif de la 2ème étape “Collecter et Analyser” est de développer une analyse complète du métier.
Une des tâches est de définir les concepts d’architecture. Il s’agit de modéliser l’état actuel du métier puis l’état souhaité, ce qui va servir de base à la conception du plan de transformation de l’organisation. On utilise les vues représentant un système en fonction des intérêts de la personne qui le regarde et les points de vue définissant la perspective à partir de laquelle le système est regardé c’est à dire :
- Comment construire et utiliser une vue (schéma et modèle)
- L’information qu’elle devrait contenir
- Les techniques de modélisation
- Les raisons de ce choix en décrivant les intérêts des parties prenantes.
L’architecte doit identifier les parties prenantes et recueillir les exigences avec les méthodes standards d’analyse de documents, d’interview, de groupe de travail, de brainstorming et d’observation.
L’auteur définit un modèle comme une représentation et une simplification de la réalité, afin de fournir de l’information à une audience particulière, dans le but d'analyser, de communiquer et de comprendre.
Selon lui, un modèle comprend 3 caractéristiques :
- Représentation : la manière dont le modèle décrit les choses comme par exemple un diagramme, une matrice ou une simulation.
- Simplification : réduire la complexité d’une situation qui empêche une vision globale.
- Transfert d’informations : quoi envoyer, des données, des processus, des interactions, une séquence, des événements… et à qui, les dirigeants s'intéressent à des situations de haut niveau alors que les techniciens ont besoin de précisions.
Les modèles constituent une documentation formelle réduisant le risque d'ambiguïté tout en apportant une compréhension commune du contexte.
Extrait de l'ouvrage de Romain Hennion : la pyramide Business Model Definition.
A noter que l'activité Business Scenario se trouve anormalement placée avant Business Use Case !
Business Model
Le business model présente les parties significatives de l’organisation et les flux d’information de haut niveau. Les modèles de contexte métier décrivent le périmètre à analyser.
Value Chain
La modélisation de la chaîne de valeur fournit une vue globale de l’entreprise. Elle comprend l’ensemble de ses capacités qui créent de la valeur. Le diagramme d’Ishikawa est utilisé pour identifier et organiser les différentes causes possibles d’un problème.
(voir notre article Modélisation métier : méthode des processus métier orientés objectifs).
Requirement Analysis
L’auteur aborde de manière pédagogique la gestion des exigences avec les définitions de la typologie associée (métier, parties prenantes, solutions, transition, politiques, règles métier, fonctionnelles et non fonctionnelles).
Voir nos articles :
- SysML : le diagramme d'exigence (requirement diagram)
- SysML : exemples de diagramme d'exigence tout droit sortie de la norme de l'OMG
- SysML : Décomposition des exigences avec le diagramme de requirement SysML - Les spécifications du HSUV (tutorial SysML partie 8)
- SysML : Méthode d'utilisation - 1ère étape Modélisation des exigences et des besoins - 1.1 Le package de spécifications - cahier des charges
- Le catalogue des exigences de la phase A Vision de TOGAF : étape 4.1 de l’étude de cas
- La vision dynamique des exigences de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
- Expression des besoins : modélisation des exigences avec le "mega extra super" AGL MEGA
- ArchiMate étude de cas : diagramme des exigences, comparaison du diagramme SysML de TOGAF et celui avec ArchiMate - 4
La méthode suivie par l’auteur intègre la méthode SMART (Spécifique, Mesurable, Atteignable, Réaliste, Temporellement borné), voir notre article :
Business Use Case
Un manque de rigueur est à noter dans la pyramide du Business Model Definition. En effet, jusqu’à présent, l’activité de “business scenario” était placée dans plusieurs figures avant celle du Business Use Case, mais dans les 2 paragraphes qui leur sont consacrés, leurs positions sont inversées !
Les use cases UML ont toujours une certaine granularité et se composent de scénarios, nominaux alternatifs ou exceptionnels, permettant d’avoir la séquence des interactions des acteurs.
L’activité de description de ces scénarios vient donc logiquement après celle d’identification et de modélisation des use cases.
Extrait de l'ouvrage de Romain Hennion : la pyramide Business Model Definition.
A noter que l'activité Business Use Case est cette fois-ci correctement placée avant Business Scenario.
Toujours très pédagogue, l’auteur détaille donc les cas d’utilisation métier à la fois processus et cas d’utilisation UML (ou SysML).
Voir nos articles :
- Comment être efficace dans la modélisation de vos cas d'utilisation (UML use case diagram) ?
- SysML : Méthode d'utilisation - 1ère étape Modélisation des exigences et des besoins - 1.2 Le package des cas d'utilisation (use case)
- SysML : les use case "top level" et opérationnels (tutorial SysML partie 4)
- SysML : le diagramme de cas d'utilisation (use case diagram)
- 5/11 Projet informatique, passer du moyen âge à l'ère industrielle. Mettez le paquet sur les Use Case.
- Estimation – Méthode des points de cas d’utilisation
- ArchiMate, méthode de modélisation : le diagramme de cas d’utilisation métier, comparaison du diagramme UML de TOGAF et celui avec ArchiMate - 18
Business Scenario
Pour aller plus en profondeur dans les niveaux de détails, l’auteur reprend le concept de Business Scenario déjà présent dans bien d’autres méthodes.
Les objectifs sont :
- Décrire un problème en s'appuyant sur la terminologie de l’architecture d’entreprise
- Modéliser la séquence étape après étape d’un événement métier en l’accompagnant d’une description textuelle
- Détailler les ressources humaines et les technologies mises en œuvre pour atteindre le résultat voulu.
Le processus itératif et incrémental de réalisation de ces scénarios est entièrement passé en revue.
Business Process Modeling
Le Business Process Modeling termine la démarche de la définition du Business Model. L’auteur rappelle la définition et les fondamentaux de la modélisation des processus avec BPMN.
Voir nos articles :
- BPMN 2 : les concepts de base des processus métiers
- BPMN pour les nuls : les collaborations
- BPMN pour les nuls : les chorégraphies (Choreographies)
- BPMN pour les nuls : les conversations
- BPMN : norme OMG - synthèse des éléments graphiques
- BPMN : l'antisèche pour rester incollable en modélisation de processus
- BPMN l’exemple type pour tout comprendre sans prendre d’aspirine
- BPMN : la norme, toute la norme rien que la norme. L'exemple à lire en attendant une pizza
- BPMN : mais que dit la norme sur les sous-processus et la gestion des événements d'interruption et de remontée d'incidents ?
- BPMN : processus exécutables, comment s'y prendre ? (1/3)
- BPMN : processus exécutables, comment s'y prendre ? (2/3)
- BPMN : processus exécutables, comment s'y prendre ? (3/3)
- Comment identifier, simuler, améliorer et modéliser les processus métiers ?
- Comment mettre en place un jeu de rôles pour modéliser un processus métier ?
Construire et Valider
Cette étape est déclenchée par l’input “Vision de l’entreprise cliente axée sur l’activité” correspondant à l’output de l’étape précédente “Collecter et Analyser”.
La première tâche vient de la démarche d’urbanisation du SI consistant à aligner l’architecture technique sur l’architecture métier en suivant les domaines traditionnels d'architecture :
- L’architecture conceptuelle ou métier
- L’architecture logique ou fonctionnelle
- L’architecture physique ou technique
L’auteur fait le rapprochement avec les types d’architecture défini dans TOGAF.
Voir notre article : TOGAF pour les nuls.
La tâche suivante consiste à identifier les solutions possibles. La panacée passe par un brainstorming, une évaluation des dépendances, une estimation des coûts et une analyse des contraintes.
Présenter la solution et Obtenir l’accord
L’objectif est de proposer plusieurs solutions issues de l’étape précédente, puis à concevoir la solution choisie et la mettre en œuvre.
Voir notre article sur le schéma directeur élaboré par le DSI : Les étapes d'un schéma directeur
Pour faciliter l’adhésion des parties prenantes, il faudra détecter les soutiens et les résistances au changement.
Pour ce qui est de la communication avec les dirigeants, Romain Hennion propose le modèle de compréhension IOCBAA (Issue, Opportunity, Credentials, Benefits, Action, Agenda) de Kenn Leithwood ( https://www.oise.utoronto.ca/lhae/Faculty/1650/Kenneth_Leithwood.html ).
Ce modèle montre comment délivrer un premier message qui attire l’attention et prépare les destinataires à recevoir la suite.
Dernière étape : Mettre en œuvre et Évoluer
Le but est de déployer la solution acceptée à l’étape précédente. La mise en œuvre pouvant s’effectuer sur une période significative, un processus de gestion des changements devra être élaboré.
Dans une perspective de résolution consensuelle des conflits, l’auteur cite le psychologue Kurt Lewin qui a développé les concepts de “dynamique de groupe” et de “résistances au changement” (http://www.sietmanagement.fr/les-phases-du-changement-la-conduite-des-etapes-des-trajectoires-k-lewin-r-zmud/)
A la fin de l’ouvrage, l’auteur aborde la gouvernance de la mise en œuvre et les moyens pour s’assurer des bénéfices et de la satisfaction du client.
Conclusion
On regrette que l’auteur ait laissé la quasi-totalité des illustrations en anglais, ce qui complique la compréhension pour le profane, bien que l'on retrouve les traductions en français dans les explications textuelles.
Comme le livre traite majoritairement de la méthode BATP de Global Knowledge, le sous-titre “La méthode TOGAF en pratique” est exagéré si l’on recherche un ouvrage traitant rigoureusement de ce sujet.
Bien souvent, les méthodes consistent en un assemblage de bonnes pratiques, de certaines parties d’autres méthodes ou de modèles, la méthode BATP en est la preuve flagrante.
Toutefois, cet ouvrage conviendra parfaitement pour le lecteur néophyte désirant avoir une connaissance concrète des activités d’un consultant dans le domaine de l’architecture d’entreprise.
Quant au lecteur aguerri, il trouvera sûrement de nouvelles pistes passionnantes à explorer.
Architecture et transformation de l'entreprise et du SI
La méthode TOGAF en pratique.
Romain Hennion
Parution : 2014
Editeur : Eyrolles
|
Rhona Maxwel @rhona_helena |
“Celui qui accepte le mal sans lutter contre lui coopère avec lui.”
Martin Luther King
Compléments de lecture
- TOGAF pour les nuls.
- Le processus des itérations ADM (Architecture Development Method), le moteur de la transformation d’entreprise TOGAF (The Open Group Architecture Framework)
- La phase A Vision du cycle de la méthode ADM (Architecture Development Method) de la transformation d’entreprise TOGAF (The Open Group Architecture Framework)
- Comment mettre en œuvre la phase B Métier de la méthode ADM (Architecture Development Method) du framework d’Architecture d’Entreprise TOGAF (The Open Group Architecture Framework)
- Comment mettre en œuvre la phase C Système d’Information et la phase D Technique de la méthode ADM (Architecture Development Method) du framework d’Architecture d’Entreprise TOGAF (The Open Group Architecture Framework)
- Comment mettre en œuvre la phase E Opportunités et Solutions de la méthode ADM (Architecture Development Method) de la transformation d’entreprise TOGAF (The Open Group Architecture Framework)
- Comment mettre en œuvre la phase F Planning de migration de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
- Comment mettre en œuvre la phase G Gouvernance de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
- Les objectifs de la phase H « Gestion de la maintenance et des évolutions » de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
- La vision dynamique des exigences de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
- La structure de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
- Les concepts du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
- Le diagramme de classe UML du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
- L’extension « Gouvernance » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
- L’extension « Services » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
- L’extension « Modélisation de processus métier » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
- L’extension « Modélisation des données » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
- L’extension « Consolidation d’infrastructure » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
- L’extension « Motivation » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
- Le référentiel TOGAF sous toutes ses coutures : le « Continuum d'Entreprise » et la réutilisation de l'architecture
- Le référentiel TOGAF, le patrimoine des informations et des bonnes pratiques pour toute l’entreprise
- Gouvernance d’entreprise, Gouvernance technologique, Gouvernance informatique et Gouvernance de l’architecture : mais où se situe la Gouvernance TOGAF ?
- Le cadre de gouvernance de l'architecture : identifier les processus et les structures organisationnelles efficaces
- Gouvernance de l'architecture en pratique : principaux facteurs de succès et éléments d'une stratégie efficace
A découvrir aussi
- La sélection d’urbanisation-si.com d’articles du web - 09 septembre 2021
- Le projet d'urbanisation du SI de Christophe Longépé
- Urbanisation, SOA et BPM d’Yves Caseau
Inscrivez-vous au site
Soyez prévenu par email des prochaines mises à jour
Rejoignez les 757 autres membres