Médiathèque
Les records pour le secteur de l'édition, confirment l'engouement des Français pour la lecture. Cette rubrique, sorte de reader's digest des best sellers sur nos sujets préférés et auxquels vous êtes fidèle, pourrait vous servir à compléter votre bibliothèque personnelle ou celle de votre entreprise.
Les articles et les vidéos sont choisis pour leurs qualités pédagogiques et inspirantes ainsi que leurs apports sur des retours d'expérience, permettant d'aiguiser votre sens critique et votre curiosité.
“Oldies but goodies”, même si certains sont quelque peu datés, ils n'ont pris aucune ride. Leurs auteurs sont pédagogues, ils manient les effets de styles et la rhétorique et leurs contenus sur les fondamentaux sont intemporels.
TOGAF et SAFe pour renforcer la résilience opérationnelle numérique : 1ère partie
Les organisations victimes d’attaques par malware, ransomware ou autres sont de plus nombreuses, et cela dans tous les domaines.
Laurent Jordi, architecte d’entreprise pour de grands groupes, vous explique dans une série de vidéos courtes, comment, en combinant TOGAF et SAFe, vous pourrez rendre votre SI résilient face à ces cyberattaques.
Les 2 thèmes introduits dans cette première capsule sont la Résilience opérationnelle numérique
et la Gestion des risques liés aux TIC par des tiers.
Laurent Jordi
EZ Logic Monaco
“J’ai toujours eu la conviction que les virus informatiques ou biologiques finiraient par détruire la quasi-totalité de l’espèce humaine.”
Franck Thilliez
Articles conseillés
Vidéo de Laurent Jordi
Articles consacrés à TOGAF
- TOGAF 10, quelle méthodologie d’architecture de sécurité et de gestion des risques ?
- 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
Le condensé de l'ouvrage Urbanisme des SI et Gouvernance du Club Urba-EA, le recueil des retours d’expérience de grandes entreprises
Bien que l’on trouve les thèmes classiques du processus d’urbanisation et les composantes de l’Architecture d’Entreprise dans les frameworks de Zachman et TOGAF, on est ici avant tout dans un recueil de retours d’expériences empruntées à de grandes entreprises, ce qui est assez rare et qui mérite d’être souligné.
Les auteurs
Le Club Urba-EA réunit les professionnels des grandes entreprises, en charge de piloter les transformations du Système d’Information (SI) et de l’Architecture d’Entreprise (AE). Au travers de conférences et de groupes de travail, les membres du Club échangent sur des problématiques variées : exigences métier, processus, entreprise numérique, transformation du SI, maîtrise des données (data centric, big data, référentiels…), opportunités technologiques, solutions Cloud, API, intelligence artificielle…
L'essentiel
La première partie intitulée “L’essentiel” rappelle le défi des entreprises qui est de se mouvoir dans l’ordre ou risquer le chaos face aux évolutions perpétuelles des règles et des dynamiques de l’économie mondialisée, le changement devient un état permanent.
L'urbanisation : un processus permanent
Les différentes dimensions de l'urbanisme de SI
Dans la deuxième partie, les auteurs posent les postulats du processus d’urbanisation du SI. Tout d’abord, la dimension statique constituée d’un modèle en couches verticales ou le niveau inférieur est la réalisation du niveau immédiatement supérieur.
Les niveaux sémantiques du modèle en couches de l'urbanisation du SI
- La vision métier est axée sur la stratégie, les processus métier et les activités de l’entreprise.
- La vision fonctionnelle structure en blocs les informations et services nécessaires aux processus métier.
- La vision applicative informatise les services et les données métier regroupés en applications.
- Enfin, la vision technique implémente ces logiciels sur l’infrastructure technique répondant au contrat et SLA (Service Level Agreement, règles de gouvernance) de service.
La dimension dynamique s’occupe de la prospective visant à définir une cible d’évolution pour le SI (voir notre article : Le rôle de la prospective pour une entreprise innovante et résiliente).
La modélisation des différentes couches permet de cartographier l’état actuel du SI, ainsi que la cible souhaitée. Cette dimension inclut le caractère opérationnel indispensable pour concrétiser les options d’évolutions en applications.
Le néophyte découvrira les macro-processus de l’urbanisation des SI à savoir :
- les processus opérationnels : planifier les développements des applications en définissant les trajectoires pour l’atteinte des cibles définies, promouvoir les architectures orientées services (SOA), ainsi que les référentiels et le BPM (Business Process Management), contribuer aux phases amont des projets et assurer la gouvernance des règles d’urbanisme,
- les processus de pilotage : mesurer le degré de maturité de l’urbanisation du SI,
- les processus de support : les méthodes de cartographies et la formation à la démarche d’urbanisation du SI.
L’Architecture d’Entreprise dans le monde anglo-saxon est un “mindset” reposant sur une modélisation globale rassemblant acteurs, motivations, stratégies, organisations, processus métier, données métier, écosystèmes technologiques, infrastructures techniques…
Le champ couvert est plus étendu que l'urbanisation du SI, comme nous l’avons détaillé dans notre article : Urbanisation du Système d'Information vs Architecture d'Entreprise
Périmètre de l'urbanisation du SI par rapport à l'architecture d'entreprise
en considérant le framework de Zachman
Société Générale
Plusieurs retours d’expérience concernant l’indice d’urbanisation sont détaillés, notamment celui de la Société Générale. Les principaux critères retenus sont :
- Connaître le système existant
- Gérer les référentiels
- Disposer de cibles d’évolution du SI
- Maîtriser une construction du SI optimale
- Maîtriser la complexité des flux
- Piloter l’urbanisation du SI et communiquer
Les résultats ont servi à dresser un état des lieux, à établir un diagnostic et à définir deux cibles, une à court terme et une théorique et enfin à élaborer un plan d’action pour tendre vers cette dernière.
Renault
Parmi les exemples d’urbanisation des échanges en entreprise étendue, on trouve celui de Renault. Il s’agit de l’urbanisation des échanges en B2B (Business to Business). Une voiture est faite à plus de 60 % de pièces détachées achetées par les constructeurs. Tous les métiers comme l’ingénierie, les achats, la logistique… sont en relation avec des partenaires ou des fournisseurs. Les auteurs détaillent le contexte, les acteurs, la situation initiale et la problématique, les enjeux et les objectifs, la démarche mise en œuvre, les préconisations de l’étude, le déploiement de l’infrastructure d’échange, l’évangélisation des MOA et MOE.
La démarche d’urbanisation a eu pour effet d’apporter aux directions métier (MOA) une méthode pour réaliser des processus ouverts et aux maîtrises d'œuvre (MOE) des recommandations pour faciliter la réutilisabilité, l’évolutivité et la généricité des applications. Tout échange avec les partenaires se fait à travers le portail fournisseur. La propriété de généricité d’entreprise étendue est remplie avec un seul et même portail pour les employés et fournisseurs qu’il suffit de paramétrer selon des règles appropriées. Les modèles des maquettes conçus par ingénierie assistée par ordinateur sont échangés par un processus formalisé, unique et outillé. Le protocole d’échange “Odette” du monde automobile a été adopté par tous les acteurs.
Le lecteur trouvera dans cet exemple une démarche et des préconisations générales qui ne sont pas propres à Renault. Il pourra les appliquées aux échanges transverses internes ou aux échanges en B2B d’autres entreprises.
Un deuxième cas d’usage de la réalisation d’un processus d’urbanisation d’un SI transverse est traité au travers de la filière Risque de la Société Générale. Les apports se traduisent par : une meilleure connaissance et une vue d’ensemble de l’existant, la modélisation des objectifs et processus métier, les architectures fonctionnelles et applicatives comme cadre de référence, une meilleure connaissance des projets de la filière risque dans les branches.
L'urbanisme : composante majeure de la gouvernance
du Système d'Information
Les apports de l'urbanisme de SI à la gouvernance
“On ne peut gouverner que ce que l’on connaît”, tel pourrait être le titre de cette troisième partie consacrée au rôle prépondérant de l’urbanisme dans la gouvernance du SI.
Les objectifs de la gouvernance du SI (voir nos articles : L'urbanisme et la gouvernance du Système d'Information) sont :
- l’alignement du SI sur la stratégie de l’entreprise
- l’optimisation de la contribution du SI pour le métier et pour les clients
- la maîtrise des coûts du SI
- la réduction des risques liés au SI
- la fourniture quotidienne aux clients du SI, des niveaux de service qu’ils attendent.
L’urbanisme va permettre le pilotage de l’évolution du SI, la gestion des risques, la maîtrise des coûts et la création de valeur.
AXA
Ces apports de l’urbanisme dans la gouvernance du SI sont explorés au travers du retour d’expérience d’AXA France. Après avoir construit une cible fonctionnelle par une approche top-down, l’urbanisme chez AXA s’est concentré sur l’intégration des activités MOA dans le cycle des projets et notamment dans la phase amont. Le processus de gouvernance a permis d’inscrire l’urbanisme le plus en amont possible, permettant aux architectes d’intervenir le plus tôt possible dans les projets.
Un référentiel des processus est, alimenté par leurs concepteurs, articulé avec le référentiel applicatif et les fonctions de la cible d’urbanisme, permettant une continuité entre les modèles de processus, fonctionnels et applicatifs.
Une meilleure intégration MOA et MOE a permis entre autres l’automatisation des processus.
Air France et KLM
L’exemple typique de projet d’urbanisation lors d’une fusion de 2 entreprises est abordé avec le rapprochement d’Air France et de KLM. La démarche a été menée avec pragmatisme en partant de qui est disponible en utilisant une méthode bottom-up. L’urbanisme a permis de structurer le processus de rapprochement des SI des deux compagnies. Une décomposition en domaines métier a été effectuée, la communication entre les équipes a été améliorée grâce aux cartographies fonctionnelles. Une stratégie commune a été définie avec la mise en œuvre de référentiels communs permettant une politique commerciale plus efficace, l’interopérabilité entre applications, la construction de règles et de trajectoires vers des cibles choisies.
Le SI résultant et urbanisé a apporté une amélioration de la lisibilité par le métier, une diminution de la taille des projets grâce à la modularité.
L'urbanisme au cœur des projets
La partie 4, répond aux questions :
- Quelles sont les interactions entre urbanisme et projets ?
- Comment intégrer l’urbanisme dans les projets ?
- Comment l’urbanisme peut-il réduire le coût des projets métier ?
La contribution des SI au métier de l’entreprise n’est plus à démontrer, il faut maintenant la développer.
L’ouvrage énonce les principales règles d’urbanisme, ce qui devrait intéresser le néophyte. Nous en donnons ici quelques exemples :
- Pour chaque domaine métier, une cartographie des applications existe et est mise à jour par les projets.
- Un référentiel de données d’entreprise ne doit pas être géré dans une application spécifique opérationnelle.
- Pour chaque domaine métier, une cible fonctionnelle existe et est validée par le métier.
- La construction de tout nouveau système applicatif respecte un modèle en n couches.
- Deux applications relatives à deux activités différentes ne peuvent pas gérer une même donnée en accès CRUD (Create, Read, Update, Delete).
- Une application métier utilise des services (architecture SOA Service Oriented Architecture de type par exemple microservices, voir nos articles : Architecture Micro-Services et Micro-Services études de cas) pour réaliser les fonctions suivantes : échanges, données référentielles, sécurité, décisionnel, gestion des ressources nécessaires au processus métier.
- A l’intérieur d’un SI, les échanges de données entre blocs fonctionnels n’appartenant pas au même domaine ne se font pas en point à point, mais passent par des outils d’échange comme l’EAI (Enterprise Application Integration), un bus logiciel ESB (Enterprise Service Bus), l’Event Streaming (voir nos articles : Event Driven Architecture EDA.
Les futurs urbanistes de SI apprécieront le chapitre consacré aux fonctions qu'ils auront à remplir et trouveront plusieurs cartographies fonctionnelles comme par exemple celles de la RATP et RTE (filiale d’EDF), entièrement commentées.
L'urbanisme créateur de valeur
La cinquième partie explique comment l’urbanisme est un moyen d’accroissement de valeur.
Bien des exemples d’urbanismes réussis sont liés à la prospective.
Le retour sur investissement (ROI) de l’urbanisme est celui d’une infrastructure caractérisée par un investissement à la création puis par un coût d’entretien.
Au départ des surcoûts apparaissent viennent ensuite les économies que procurent la réduction des études amont, l’anticipation des impacts des autres projets, la réduction du périmètre des projets, la réduction des études, des développements et de la recette, la réutilisabilité de blocs applicatifs et pour finir l’existence de règles permettant aux projets de se concentrer sur les aspects métier. Dès que l’apport de valeur dépasse le cumul des surcoûts, le ROI est atteint.
Conclusion
L’ouvrage se termine sur des perspectives à court terme. Les grandes entreprises, dotées de SI de plus en plus complexes, seront confrontées à un environnement réglementaire protéiforme et des contraintes mondialisées, les obligeant à lutter contre l’entropie et à rechercher toujours plus d’agilité.
Les urbanistes deviendront les catalyseurs de cohérence, de transversalité et de flexibilité.
Une révolution technique donnera-t-elle enfin l’agilité instantanée tant désirée ?
Urbanisme des SI et gouvernance
Bonnes pratiques de l’architecture d’entreprise
Club URBA-EA
Parution : avril 2010 - 2ème édition
Collection : InfoPro
Editeur : Dunod
|
Rhona Maxwel @rhona_helena |
“Le drame de notre temps, c'est que la bêtise se soit mise à penser.”
Jean Cocteau
Compléments de lecture
La médiathèque
Le condensé de l’ouvrage Architecture et transformation de l'entreprise et du SI de Romain Hennion Rhona Maxwel |
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. |
|
Urbanisation, SOA et BPM d’Yves Caseau Rhona Maxwel |
Les retours d’expérience d’un Directeur des Systèmes d'Information de grands comptes sont précieux et ne sont pas légion. Le parcours original de l’auteur lui permet d’exposer de manière pédagogique des points de vue de chercheur en architecture distribuée, d’ingénieur d’étude, de consultant en architecture de SI et enfin de DSI pour les aspects opérationnels. Fait assez rare pour ne pas être souligné, on trouve dans cet ouvrage de nombreux exemples concrets tirés de l’expérience à Bouygues Telecom. |
|
Le projet d'urbanisation du SI de Christophe Longépé Rhona Maxwel |
Comment un ouvrage informatique, vieux de plus de 20 ans (la première édition date de 2001, la 4e et dernière édition de 2009), peut-il être toujours d’actualité et considéré comme un livre culte ?
|
|
|
Cas concret d’un Système d’Information urbanisé : Mango
|
Dans cette vidéo sous forme de présentation silencieuse de slides, vous découvrirez un exemple pédagogique illustrant les fondamentaux de l’urbanisation du Système d’Information allant même parfois jusqu’à montrer des rapports et des structures de données. Cette vidéo très détaillée convient bien à ceux qui recherchent des exemples de la vraie vie. |
|
Laurent Jordi |
Parmi les critiques de TOGAF, une qui revient souvent concerne le manque d'exemples détaillés et de cas d'usage démontrant la praticité de ses recommandations. Cette vidéo devrait adoucir ce reproche. |
Notre série "est-il un bon outil de modélisation"
|
Rhona Maxwel |
Cet outil gratuit, en français, en mode SaaS dans le cloud, accessible à partir de nombreux appareils mobiles (iOS, Android…), offre un panorama hétéroclite de modèles de visuels, dont voici une liste à la Prévert : cartes cadeaux, anniversaire, menus, albums photos, tableaux de bord, graphiques statistiques, bande dessinée… et ce qui nous intéresse tout particulièrement les diagrammes ArchiMate, BPMN, et UML.
|
|
Essai et évaluation de Modelio : est-il un bon outil de modélisation ? Rhona Maxwel |
Ce test concerne Modelio, le seul outil open source fonctionnant sur Windows, Linux, Mac OS, supportant ArchiMate, TOGAF, BPMN, UML, SysML, MDA et offrant, pour tous ces artefacts de modélisation, un référentiel commun assurant la traçabilité depuis la stratégie jusqu’à la couche technologique. Mais est-il fiable en usage intensif dans les entreprises ou doit-il être plutôt réservé à l’apprentissage de la modélisation ?
|
|
ADOIT:CE pour la gestion de l’Architecture d’Entreprise Thierry BIARD |
Comme le suggère le titre de notre blog, la mise en œuvre de l’Urbanisation du Système d’Information et de l’Architecture d’Entreprise doit se faire avec méthode. Mais sans outil adéquat, l’application d’une méthode s’avère vite laborieuse. Rappelons qu’il s’agit de mettre en place un référentiel d’architecture (généralement stocké dans une base de données) contenant des objets, qui seront ensuite utilisés pour créer des modèles (diagrammes, matrices, listes et rapports). Les articles de notre blog concernant les outils rencontrant généralement un grand succès, en voici un concernant un outil intéressant, et pas seulement parce qu’il est gratuit.
|
|
ADOIT:CE (compléments d’information) Thierry BIARD |
Voici quelques compléments d’information intéressants qui ont été donnés par l’éditeur BOC Group. |
PILI, Agilité logicielle, Event Driven Architecture, Architecture Hexagonale et Domain Driven Design
|
Le PILI était-il un bon modèle ? Thierry BIARD |
En fin d’année 2021, la RATP a mis en vente aux enchères du mobilier réformé, au profit d’une œuvre caritative (belle initiative). Parmi les 215 lots mis en vente figuraient quatre PILI (Panneaux Indicateurs Lumineux d’Itinéraires).
|
|
Rhona Maxwel |
Des plus petites aux plus grandes entreprises, le concept de bounded context est aujourd’hui au cœur de la conception d’architecture logicielle, mais se pose l’éternelle question de quelle méthode pour parvenir à un découpage produisant le couplage le plus faible, augmentant ainsi l’évolutivité, l'autonomie et l'agilité.
|
|
Rhona Maxwel
|
Comment gérer l’idempotence de l’envoi d’un même message ?
|
|
Architecture Hexagonale, un exemple de mise en pratique de la méthode DDD Domain Driven Design Rhona Maxwel |
L'architecture hexagonale (ou encore Ports & Adapters Architecture, ce qui est moins sexy) créée par Alistair Cockburn garantit la réutilisabilité de la logique métier en la rendant agnostique techniquement. |
Les couches de l'Architecture Microservices et la méthode de conception DDD (Domain Driven Design) Rhona Maxwel
|
Cet article présente le rôle des différentes couches de l'Architecture Microservices et le lien avec la méthode de conception DDD. |
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
Urbanisation, SOA et BPM d’Yves Caseau
Les retours d’expérience d’un Directeur des Systèmes d'Information de grands comptes sont précieux et ne sont pas légions. Le parcours original de l’auteur lui permet d’exposer de manière pédagogique des point de vue de chercheur en architecture distribuée, d’ingénieur d’étude, de consultant en architecture de SI et enfin de DSI pour les aspects opérationnels. Fait assez rare pour ne pas être souligné, on trouve dans cet ouvrage de nombreux exemples concrets tirés de l’expérience à Bouygues Telecom.
Parution : août 2011 - 4ème édition
L'auteur
Yves Caseau possède un CV hors norme, Docteur en informatique (Université Paris-Sud, 1987), Docteur en Philosophie (Ecole normale supérieure, 1987).
Il débute dans la recherche chez Alcatel-Alsthom (1984-1988) puis chez Bellcore (1988-1994).
Il rejoint le groupe Bouygues en 1994 comme directeur du e-Lab.
En 2001, il est nommé CIO (Chief Information Officer) de Bouygues Telecom où il évolue comme vice-président exécutif en 2007.
Auteur et contributeur de nombreux ouvrages, il est, depuis 2012, académicien et président du Collège TIC de l'Académie des Technologies.
En 2014, il est recruté par le groupe Axa pour prendre la responsabilité du pôle digital.
Il entre en 2017 chez Michelin comme CIO du groupe.
Début 2021, toujours CIO de Michelin, il récupère la fonction du digital avec la fonction de CDIO (Chief Digital Officer).
Présentation
Ne vous fiez donc pas à la date de parution qui peut sembler ancienne pour un ouvrage traitant de tels sujets. D’abord parce qu’aucune solution technologique d’intégration n’est évoquée et ensuite parce que l’auteur à eu l’intelligence de prendre de la hauteur sur les questions et les éléments de réponses qui resteront encore pertinents pour longtemps.
A nouveau un livre qui a pour vocation de former à la démarche d’urbanisation. La progression se fait sous forme d'un triptyque : I - Les principes de l’urbanisation ; II - Les défis de l’urbanisation ; III - Perspectives.
I - Les principes de l’urbanisation
La première partie s’adresse aux néophytes, on y trouve les fondements de l’urbanisation du SI. La démarche est présentée comme une transformation progressive du SI intégrant l’existant, s'appuyant sur les processus métier et leur adéquation avec le SI afin d’atteindre flexibilité et évolutivité. Le moyen pour y parvenir est la mise en œuvre d’une architecture distribuée. Le SI urbanisé est basé sur les processus métier de l’entreprise, une structure hiérarchique en sous-systèmes ou les échanges sont standardisés suivant le modèle métier encore appelé langage pivot et enfin sur une architecture ouverte pour l’évolutivité.
L’auteur insiste sur la manière de concevoir la cartographie fonctionnelle où il faut éviter le dogmatisme et la théorisation. L’intermédiation encore appelé proxy permet de découpler les composants grâce aux adapteurs et contribue à la mise en œuvre d’une architecture agile.
Le théoricien s’exprime sur les techniques de modélisation comme sur la réification d’un lien consistant à le représenter par une classe avec des méta attributs comme le degré de fiabilité, la durée de validité, des éléments de preuves, … L’avantage est de pouvoir utiliser l’héritage pour faire évoluer la sémantique du lien au cours des évolutions du modèle.
Le modèle de processus est un espace à 2 dimensions. La dimension horizontale représente les processus transverses et aux domaines fonctionnels de l’entreprise. La dimension verticale identifie des sous-processus masquant par abstraction des niveaux de détails qui ne sont pas nécessaires lorsqu’on étudie les processus dans leur globalité.
Par acquis d’expérience, le postulat principal de l’urbanisation est que l’analyse des processus métier fournit les bonnes interfaces de services. Les processus métier sont des enchaînements de services métiers qui évoluent par recomposition ou re-paramétrage des services mais sans modification des interfaces.
Un des fondamentaux de l’architecture est la diminution du couplage, qui passe, nous rappelle l’auteur par une communication asynchrone entre émetteur et récepteur et par la gestion d’un évènement qui n’est que la réification de l’échange.
II - Les défis de l’urbanisation
La deuxième partie montre l’importance de la conception dans la réalisation d’un SI agile et modulaire. Une modélisation du cycle de vie du SI, met en perspective les avantages et les inconvénients d’un projet d’urbanisation afin d’obtenir le retour sur investissement.
L’auteur nous livre les résultats du ROI d’une étude de Bouygues Telecom ainsi que d'entreprises similaires. A cause de la simplification du calcul des impacts, la phase de spécification/conception peut atteindre un gain de 30 %. Le fait que la logique d’enchaînement ne fasse plus partie du composant logiciel, permet une réduction du développement de 20 %. L’intégration ne dépendant que d’un adaptateur, on économise toutes les connexions du composant avec les autres et ainsi on arrive à diviser le travail par un facteur 3. En ce qui concerne les tests, et plus particulièrement les tests fonctionnels transverses et de non-régression, on peut compter sur un gain de l’ordre de 30 %. Quant à la réutilisation des services, il faut atteindre un niveau maturité correspondant à la réalisation d’un catalogue opérationnel pour avoir un gain substantiel pouvant aller jusqu’à 25 %.
Si cette analyse théorique reste pertinente, elle doit être modulée. En effet la phase de spécification/conception est impactée par le changement de paradigme qu’il faut assimiler, le développement des adaptateurs dépasse les estimations, l’infrastructure d’intégration est un investissement coûteux surtout lors de l'acquisition, du déploiement et de la mise au point.
L’auteur rassure en montrant que la situation est nettement plus positive sur le moyen ou le long terme.
Un des concepts clé de l’ouvrage est l’urbanisation fractale ou comment appliquer les mêmes principes à différentes échelles du SI.
La formalisation de cette récursivité peut s’exprimer de la manière suivante :
- SIU (Système Informatique Urbanisé) = un bus + un moteur de processus + des SIU branchés sur le bus qui rendent des services implémentant les activités des processus
- deux SIU + une passerelle qui joue le rôle de double proxy.
Dans une DSI moderne, l’exploitation est conçue comme un ensemble de services et la DSI signe avec ses clients des contrats de services avec les SLA (Service Level Agreement) servant de base à l'établissement de la tarification.
L’auteur va détailler les solutions de BAM (Business Activity Monitoring), l’exploitation des processus, la gestion des erreurs et donne des solutions aux transactions longues avec le modèle LRA (Long Running Action model).
Enfin différentes approches sont proposées pour la synchronisation de copies d’objets métier distribués.
III - Perspectives
La troisième partie est celle que je préfère. L’auteur donne sa vision de la gouvernance de la SOA, définie par des artefacts de partage d’information, des processus de validation et de mise à jour ainsi que des règles à respecter avec comme artefact principal, le catalogue de services.
Le BPM peut-il tenir ses promesses ? L’échelle de maturité du BPM est discutée en faisant référence à TOGAF et au Club Urba-EA.
Des solutions pour un modèle métier agile comme intégrer l’orienté objet, la méta-modélisation et la généricité.
Avec l’orienté objet on se concentre sur le “quoi” avant le “comment” en décrivant une ontologie des entités métier avant de penser à leur description et sur la réification des rôles dans le SI. Un méta-modèle décrit les entités utilisées pour construire les différents modèles de données, facilitant ainsi la compréhension de la terminologie métier, la comparaison de modèles différents et le transfert comme la migration d’un modèle vers un autre.
La généricité consiste ici à s’abstraire du positionnement de l’entreprise au sein de son industrie et s’imaginer que le modèle de données peut être partagé par d’autres membres de ce même domaine métier.
Les concepts de l’approche SOA sont exposés sans jamais spécifier de technologies comme les Web Services ou plus récemment les Microservices. L’auteur insiste surtout sur les dangers en soulignant que si l’urbanisation contribue à supprimer l’architecture spaghetti, il est par contre très facile de se retrouver avec un réseau de dépendances comme une infrastructure d’intégration mutualisée rendant le système plus rigide.
Toujours sur l’agilité, l’auteur insiste sur le paramétrage permettant des modifications rapides reposant sur des objets métiers et non plus sur des tables et effectuées directement par les domaines métiers. Lors de la refonte du back-office de Bouygues Telecom, l’augmentation du périmètre fonctionnel a augmenté la quantité de paramétrage. Pour éviter cela, il a fallu travailler sur les modèles de données pour augmenter le pouvoir d’abstraction des objets métiers de telle sorte qu’on puisse exprimer plus de choses avec moins de paramètres, ce qui revient presque à urbaniser le paramétrage.
La meilleure agilité consiste à rendre ses utilisateurs autonomes. L’expérience montre que la gestion des données est le plus grand obstacle à l’agilité. En effet lorsque les données n’existent pas, il est impossible de combler un besoin fonctionnel par un développement agile.
L’auteur cite le cas d’un projet qui a coûté 500 K€ pour simplement changer la logique de présentation d’une liste d’options. à cause d’un modèle de données trop pauvre, ce qui est classique et normal, et difficile à enrichir, ce qui est regrettable et évitable.
A l’éternelle question comment augmenter la productivité et diminuer les coûts, l’auteur répond en explorant des évolutions possibles de l’urbanisation.
La première c’est l’automatic computing autrement dit la capacité pour le SI à s’auto-administrer, s’auto-optimiser et à s’auto-gérer.
Ensuite le MDA (Model Driven Architecture) est discuté et si l’auteur le considère comme une source inspirante, il le déconseille car les processus métier sont de plus en plus complexes à réaliser et nécessite une analyse, une conception et des algorithmes tellement spécifiques que leurs générations à partir de modèles de haut niveau ne seraient absolument pas rentables.
Et pour finir, l’OAI (Optimization of Application Integration) consiste à agir en termes de débit, de temps de latence et de disponibilité sur les composants et l’infrastructure. L’objectif est de satisfaire les SLA exprimés sur des processus qui parcourent les composants, en utilisant les mêmes notions de débit, de latence et de disponibilité. A chaque processus est associé une priorité métier propre ainsi qu’une valeur métier puisque le processus est un fil de la chaîne de valeur. Deux problèmes doivent être résolus, le problème statique de satisfaire tous les SLA et le problème dynamique de minimiser la dégradation d’un point de vue métier lorsqu’une situation exceptionnelle se produit. L’OAI repose sur le middleware adaptatif et l’autonomic computing permettant d’obtenir des propriétés de self-configuration, self-optimizing et de self-healing pour la gestion des incidents.
Conclusion
Si comme on l’a dit au début, ce livre reste toujours d’actualité, on arrive à la limite de fraîcheur en ce sens que le Cloud Computing élément incontournable de l’agilité du SI est peu évoqué.
S’il est irréaliste d’imposer un modèle d’urbanisation unique, il n’en demeure pas moins primordial de partager un modèle métier commun, un ensemble de processus transverses, une stratégie d’assemblage, un catalogue de services et une urbanisation fractale.
L'auteur porte un regard global sur l’architecture d’entreprise qui va de la théorie (le pourquoi) à la pratique (le comment) tout en distillant quelques pensées philosophiques au milieu de concepts techniques, on ne s'en plaindra pas.
Le point de vue du DSI
Yves Caseau
Parution : août 2011 - 4ème édition
Collection : InfoPro
Editeur : Dunod
|
Rhona Maxwel @rhona_helena |
“On devrait inventer l'alcootest politique, on devrait faire souffler les hommes politiques dans un ballon pour savoir s'ils ont le droit de conduire le pays au désastre”
Coluche
Compléments de lecture
- Le projet d'urbanisation du SI de Christophe Longépé
- Les étapes d'un schéma directeur
- Positionnement des processus et règles métiers dans la norme BMM Business Motivation Model de l’OMG et autres artefacts génériques
- Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : Exemple d'exécution du modèle de décisions
- BPMN : processus exécutables, comment s'y prendre ? (3/3)
- CMMN (Case Management Model and Notation) : vie et mort d’une norme de l’OMG (Object Management Group)
- Les fondamentaux de la modélisation d'un Système d'Information : le bon usage des modèles
- SysML pour les nuls : de la modélisation des exigences à la réalisation du système
- Quels sont les meilleurs langages et notations de modélisation pour TOGAF ?
- Les concepts du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
- Le processus des itérations ADM (Architecture Development Method), le moteur de la transformation d’entreprise TOGAF (The Open Group Architecture Framework)
Le projet d'urbanisation du SI de Christophe Longépé
Comment un ouvrage informatique, vieux de plus de 20 ans (la première édition date de 2001, la 4e et dernière édition de 2009), peut-il être toujours d’actualité et considéré comme un livre culte ?
Le projet d'urbanisation du SI - Cas concret d'architecture d'entreprise de Christophe Longépé - 4e édition - Dunod
Christophe Longépé, aujourd’hui Chief Data Officer à BNP Paribas et auparavant Group Chief Enterprise Architect à la Société Générale, fait partie des experts français reconnus et incontestés de l’Architecture d’Entreprise.
Christophe Longépé
Partie I : les fondations
De manière très classique, la première partie revient sur les fondamentaux, les enjeux des entreprises, et identifie les changements nécessaires à la mise en œuvre de la stratégie. Le principe est de sauvegarder la cohérence et l’efficacité du système en établissant une combinaison subtile et complexe entre réutilisation d’un acquis et mise en œuvre d’architectures techniques, de plates-formes et d’outils d’amélioration de l’efficacité.
La démonstration est faite sur les similitudes entre l’urbanisme de la cité et celui des Systèmes d’Information, comme la définition avec le Plan d’Occupation des Sols (POS), le regroupement des applicatifs, le périmètre réservé pour les projets à venir, le découpage du SI en zones, quartiers et îlots, les règles d’urbanisme, l’infrastructure avec les artères de communication et enfin les cartographies.
Même si le métamodèle décrit est propre à l’auteur et est de nos jours remplacé par celui de standards comme TOGAF et ArchiMate, il a le mérite d’expliquer simplement ce qu’est un métamodèle et sert de socle à la description aux règles d’urbanisme. Leur classification suit les niveaux du cadre de référence : stratégie, métier, fonctionnel, applicatif et technique.
Pour les novices, ce chapitre est particulièrement inspirant et ouvre la voie à des réflexions plus approfondies et à des pistes de recherches sur des sujets clés de l’architecture.
Partie II : l’étude de cas culte
Cartographie cible des processus métier de l'agence de voyage, reproduit avec l'outil Enterprise Architect de Sparx Systems
La deuxième partie est très certainement la plus passionnante ; elle occupe du reste les deux tiers de l’ouvrage, fait rarissime que l'on peut souligner. On y trouve la célèbre étude de cas du tour-opérateur, reprise maintes et maintes fois comme démonstrateur pour des outils de modélisation.
L’exemple de l’agence de voyages est à l’architecture d’entreprise ce que l’exemple de la bibliothèque est aux bases de données ou encore le “Hello world” est à l’apprentissage de la programmation.
L’entreprise considérée a perdu sa place de leader sur le marché. La stratégie de la Direction Générale est des plus classiques : augmenter le nombre de contacts, puis les transformer en réservation, permettre aux vendeurs de se focaliser sur leur métier, diminuer les coûts de gestion, développer des canaux alternatifs et améliorer la trésorerie.
Comment transformer ces objectifs métier hautement stratégiques en objectifs opérationnels, qui seront ensuite réalisés grâce à une transformation digitale ?
Longépé va alors faire la preuve de la nécessité d’une démarche d’urbanisation du SI en explicitant les étapes successives qui vont s'enchaîner logiquement révélant les cartographies métier, fonctionnelle, applicative actuelles et cibles et enfin l’infrastructure. Avec, à chaque fois, la vérification que les règles et les bonnes pratiques de l’urbanisme sont bien respectées et que l’on a bien établi les liens entre l’étape n-1 et l’étape n, assurant la traçabilité et l’adéquation de la stratégie avec le Système d’Information.
On ne peut pas reprocher que certains détails des processus métier de cet exemple soient désuets. Cet exemple est en effet un cas d’école générique qui s’applique à tout type de transformation numérique et qui sert brillamment l’illustration de la méthode.
Le point faible concerne la modélisation. C’est seulement à partir de la 4e édition que BPMN (Business Process Model and Notation) est enfin cité comme concurrent du diagramme d’activité UML (Unified Modeling Language, voir dans Articles la catégorie UML), pour modéliser les processus métier de l’étude de cas. On aurait espéré qu’ils fussent entièrement refaits en BPMN (voir dans Articles la catégorie BPMN) en y ajoutant DMN (Decision Model and Notation, voir dans Articles la catégorie DMN) pour les règles métier.
La couche application est structurée en un ensemble de packages UML contenant les classes métier.
La cartographie technique existante peut être modélisée par des diagrammes de déploiement et/ou des diagrammes de composants UML.
L’outil idéal, selon Longépé, doit couvrir la modélisation et la simulation de processus, la modélisation d'architecture et supporter UML. Les diagrammes de séquence et de collaboration utilisés n’ont pas été repensés avec la version 2.5.1 d’UML.
Longépé en a bien conscience, et pose la question “Doit-on utiliser UML ?”. La réponse est que, d’une part, la méthode énoncée se doit d’être agnostique en ce qui concerne les techniques de modélisation et, d’autre part, on retrouve les critiques usuelles sur UML qui est trop générique et qui, appliqué à l’urbanisation du SI, nécessiterait un profil spécifique avec des stéréotypes, des tagged values et des contraintes OCL (Object Constraint Language, voir notre article Modélisation de système : UML n'est rien sans OCL !), bref un véritable métamodèle ou carrément un langage dédié comme ArchiMate (voir dans Articles la catégorie ArchiMate) pour le cadre TOGAF (The Open Group Achitecture Framework, voir dans Articles la catégorie TOGAF).
Parties III et IV : formalisation de la méthode et rôles des acteurs
Dans la Troisième partie, Longépé conceptualise la démarche d’urbanisation du SI. Sa vision intéressera les novices et sera une excellente introduction aux frameworks standards comme TOGAF.
Évidemment, il est logique de terminer par la description des acteurs et leurs rôles dans le processus d’urbanisme. C’est l’objectif de la quatrième et dernière partie qui encore une fois intéressera quiconque désirant avoir une bonne compréhension sur la constitution et le fonctionnement du pôle urbanisme au sein d’une entreprise.
Conclusion
Très certainement un des ouvrages les plus concrets ayant servi de base à bon nombre d’étudiants ou apprentis urbanistes de SI.
Bien qu’aujourd’hui les cadres d’architecture d’entreprise comme TOGAF avec ArchiMate aient pris le pas sur la démarche d'urbanisation des SI, ce livre reste une référence pour qui veut comprendre les fondamentaux sur la gestion des processus métier, les changements nécessaires à la mise en œuvre de la stratégie, la cohérence, l’efficience et les bonnes pratiques d’un SI agile.
L’idée phare est l’étude de cas hyper concrète servant de fil conducteur pour le déroulement de la démarche proposée par Longépé.
La démonstration est apportée qu'urbaniser les SI sert de levier pour mettre en œuvre la stratégie, permettre l'atteinte des objectifs, pouvoir assurer la pérennité des investissements, accroître la réactivité de l’entreprise, accentuer l’indépendance des différents blocs, augmenter la réutilisabilité des composants, améliorer l’interopérabilité des systèmes et renforcer la cohérence du SI.
Ce livre constitue une référence indémodable comme ouvrage pédagogique sur le sujet de l’urbanisation du Système d’Information, qui très certainement continuera longtemps à être actualisé lors de prochaines éditions.
Christophe Longépé n’a aucun souci à se faire concernant l’obsolescence des écrivains.
Le projet d'urbanisation du SI
Cas concret d'architecture d'entreprise
Christophe Longépé
Parution : 2009 - 4e édition
Collection : InfoPro
Editeur : Dunod
A noter qu’il existe une version anglaise, non mise à jour : “The Enterprise Architecture IT Project - 1st Edition (2003) - The Urbanisation Paradigm”.
|
Rhona Maxwel @rhona_helena |
"Vous pouvez être bon en technologie et aimer la mode, être bon en technologie et aimer l'art, être bon en technologie et être une bonne maman"
Marissa Mayer
Compléments de lecture
- Urbanisation SI : la carte au trésor se dissimule t-elle dans le POS ?
- En urbanisation SI, comment met on en oeuvre la traçabilité entre la vue applicative et les vues fonctionnelle et infrastructure ?
- Urbanisme SI : la nécessité d'un "espéranto"
- Les règles d'urbanisme du SI : maîtriser les échanges inter-applications
- Dans le futur, il faudra réaliser la symbiose des méthodes et veiller à la cohérence des gouvernances SI et processus
- TOGAF
- ARCHIMATE
- BPMN
- DMN
- CMMN
- BMM
- UML
- SYSML
- INGÉNIERIE DIRIGÉE PAR LES MODÈLES (IDM)
Cas concret d’un Système d’Information urbanisé : Mango
Dans cette vidéo sous forme de présentation silencieuse de slides, vous découvrirez un exemple pédagogique illustrant les fondamentaux de l’urbanisation du Système d’Information allant même parfois jusqu’à montrer des rapports et des structures de données.
Cette vidéo très détaillée convient bien à ceux qui recherchent des exemples de la vraie vie.
(extrait de la vidéo de Fatima-Zahra Yamani)
Les systèmes d'information dans l'entreprise - Cas Mango par Fatima-Zahra Yamani :
|
Rhona Maxwel @rhona_helena
|
“Maintenant que nous avons abouti à un paradoxe, nous avons des chances de progresser.”
Niels Bohr
La sélection d’urbanisation-si.com d’articles du web - 09 septembre 2021
Architecture et agilité : deux concepts incompatibles ?
Les architectes d’entreprise sont-ils en droit de se demander si un projet d'architecture peut se réaliser en mode agile avec des sprints soutenus ?
Après avoir rappelé les fondamentaux de l’architecture d’entreprise et de l’agilité, cet article répond par l’affirmative en montrant, avec des exemples à l’appui, que les deux se fortifient mutuellement.
Architecture et agilité : deux concepts incompatibles ?
5 conseils pour ré-architecturer vos applications pour le cloud
La migration d’une application vers le cloud peut comporter des pièges et le retour sur investissement ne sera pas garanti.
L’auteur de l’article décrit les bonnes pratiques pour faire un reengineering d’une application afin de profiter au maximum des avantages du cloud.
5 conseils pour ré-architecturer vos applications pour le cloud
RGPD : Un guide pratique pour les développeurs
La réglementation européenne RGPD (Réglementation Générale sur la Protection des Données - General Data Protection Regulation - GDPR en anglais) s'applique à tout le monde. Dans le cadre d’une entreprise importante, il est fort probable qu'un processus de mise en conformité soit en cours.
Cet article montre comment concevoir les modèles de données, leurs stockages, les flux associés, et les appels d'API tout en gardant à l'esprit la protection des données.
RGPD : Un guide pratique pour les développeurs
Quel framework d’architecture d’entreprise choisir ?
Quel est l'état de popularité des différents frameworks ?
Les architectes d’entreprise sont souvent interrogés sur le choix d'un framework d'Architecture d'Entreprise.
Le framework est à l’Architecture d’Entreprise ce que la boussole est au marin, il constitue une trame, un espace de langage commun, de coordination et de collaboration pour les acteurs, à partir duquel chaque entreprise bâtit sa démarche de façon itérative afin d’atteindre sa cible, c’est-à-dire une entreprise agile et résiliente.
Quel framework d’architecture d’entreprise choisir ?
Architecture d’Entreprise : vision métier ou technologique ?
Un des des objectifs de l’Architecture d’Entreprise est d’aligner la stratégie IT sur la stratégie Métier, de faire en sorte que la couche technologique supporte l’architecture métier.
Cet article montre que l’Architecture Business n’est qu’un domaine de l’architecture d’entreprise qui, si l’on prend le framework TOGAF, en comporte quatre (Business, Data, Application, Technology).
L’architecture d’entreprise : vision métier ou technologique ?
Comment promouvoir une démarche d’architecture d’entreprise ?
Cet article, daté de 2015, de Dominique Vauquier, créateur et auteur principal de Praxeme, méthodologie de transformation d’entreprise, très en vogue en France, dans les années 2000, notamment avec les débuts de SOA (Service Oriented Architecture), n’a pas pris une ride. On se délecte du style adopté pour présenter d’une manière très pédagogique la théorie et la pratique de sa vision, parfois même philosophico-technique, de l’architecture d’entreprise.
L’article se conclut sur la définition, due à Thierry Biard (auteur de nombreux articles que vous pouvez découvrir sur ce site urbanisation-si.com : https://www.urbanisation-si.com/ )
« L’Architecture d’Entreprise permet de concevoir, du métier à la technique, l’Entreprise dans tous ses aspects. »
Comment promouvoir une démarche d’architecture d’entreprise ?
Bonne lecture.
|
Rhona Maxwel @rhona_helena |
"Si vous voulez tuer une idée à coup sûr, créez un Comité pour l'évaluer."
Charles Kettering
TOGAF : Retour d'expérience sur les phases Migration Planning F, Implementation Governance G et Architecture Change Management H
Parmi les critiques de TOGAF, une qui revient souvent concerne le manque d'exemples détaillés et de cas d'usage démontrant la praticité de ses recommandations. Cette vidéo devrait adoucir ce reproche.
(extrait de la vidéo de Laurent Jordi)
De nombreux retours d'expérience sur les premières phases (A à E) de TOGAF sont présents sur internet, ceux concernant les 3 dernières : Migration Planning F, Implementation Governance G et Architecture Change Management H, sont nettement plus rares.
Vous trouverez donc dans cette vidéo, une mise en œuvre des phases "Migration Planning", une intéressante personnalisation de la phase "Implementation Governance" en intégrant le processus "DevSecOps" et pour finir la phase "Architecture Change Management".
Voici la vidéo de Laurent Jordi :
Cas d'usage : Modernisation d'une partie du SI d'un leader de la sécurité
La généricité de TOGAF ressort bien à travers cette vidéo.
TOGAF n'impose rien, ce n'est qu'une boîte à outils de bonnes pratiques, et la méthode ADM (Architecture Development Method) doit être adaptée sans plus de précision.
Si vous recherchez un retour d'expérience de mise en œuvre, vous le trouverez dans cette vidéo.
Bien évidemment, les métiers et la DSI doivent conjointement définir l'architecture, puis c'est la vision de l'architecte d'entreprise qui permettra à chacun, grâce aux modèles et cartographies, d'avoir des vues correspondant à leurs enjeux
Rhona Maxwel
@rhona_helena
"Notre taux de réussite est actuellement trop élevé, nous devons prendre plus de risques, ..., essayer plus de choses folles, ..., et nous devrions déprogrammer plus de séries, globalement."
Reed Hastings (PDG de Netflix)
Articles conseillés :
- 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)