Les meilleurs articles sur l’architecture d’entreprise, ses méthodes et ses outils, découvrez quels sont les articles les plus lus de notre blog
L’année 2020 vient de s’écouler à tout jamais. Quel est le top 10 des articles les plus visités par nos amies lectrices et amis lecteurs de notre blog consacré à l’architecture d’entreprise, aux méthodes et aux outils, ainsi qu’à l’ensemble des aspects de la modélisation ?
(Etude Accenture sur les leaders, développant les systèmes futurs et les retardataires [laggards], qui investissent dans l'innovation, mais ne parviennent pas à en tirer la pleine valeur.)
Pour entretenir le suspens, commençons par la dernière position.
10
ADOIT:CE pour la gestion de l’Architecture d’Entreprise
ADOIT:CE pour la gestion de l’Architecture d’Entreprise
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.
Voir la catégorie Modélisation de système de notre blog :
9
L’Architecture Micro-Services expliquée à ma fille
L’Architecture Micro-Services expliquée à ma fille
Le nouveau style d’architecture pour concevoir des applications informatiques, voire pour urbaniser enfin le Système d’Information de l’entreprise.
Au lieu de dupliquer en entier des applications monolithiques, il s’agit désormais de distribuer, et même de dupliquer certains micro-services uniquement, sur différents serveurs. Tout en gagnant en flexibilité et en agilité, pour effectuer plus rapidement des changements, le plus souvent des améliorations.
Une application partitionnée en micro-services est plus robuste qu’une application monolithique. Un micro-service en panne ne bloque pas forcément toute l’application, qui devient alors résiliente.
C’est une évolution de la SOA (Service Oriented Architecture) : certains parlent de l’Architecture Micro-Services comme la SOA à grains fins. Elle ne remet pas en cause la SOA, mais propose des solutions techniques plus légères, souvent Open Source, comme RESTful notamment.
Voir la catégorie Architecture Micro-Services de notre blog :
8
Comment être efficace dans la modélisation de vos cas d'utilisation (UML use case diagram) ?
Comment être efficace dans la modélisation de vos cas d'utilisation (UML use case diagram) ?
Un use case UML (cas d'utilisation) est une activité métier comme, par exemple, un acte de gestion exécuté par un acteur externe à l'application.
Un use case comporte un ou plusieurs scénarios composés d’une ou plusieurs étapes.
Les scénarios peuvent être des cas nominaux où tout se passe bien, des cas alternatifs ou des cas exceptionnels conduisant à une exception métier.
Les retours d'expérience ont permis d'élaborer la méthode dite des "10 ; 10".
Un use case doit avoir en moyenne 10 scénarios, composés chacun d'environ 10 étapes. De plus, il doit être déclenché par un unique acteur (rôle), exécuté dans une limite de temps, être transactionnel, avoir un début et une fin et pour terminer on doit avoir l'unicité de lieu.
Voir la catégorie UML de notre blog :
7
Le diagramme de contextes de projets de la phase E Solutions et opportunités de TOGAF - étape 41 de l’exemple Modelio
Le diagramme de contextes de projets modélise tout ce qui est nécessaire à la réalisation d’un projet : acteurs, processus métier, règles métier, services métier, entités métier, composants applicatifs.
Ce modèle est réalisé par les architectes applicatifs et experts métier avec comme référents les experts métier à destination de la Direction Générale, DSI, responsables de domaine métier.
6
Le meilleur du meilleur des outils de modélisation de Systèmes d’Information pour 2017 : les « Modsars » de « urbanisation-si.com » récompensent les plus innovants
Les Modsars de « urbanisation-si.com » récompensent les meilleurs logiciels de modélisation de Système d’Information.
Nos critères sont sans commune mesure avec les récompenses de références comme, par exemple, celles du Gartner.
Nous privilégions l’open source, la communauté et le partage d’informations, l’innovation, la fiabilité en production, la documentation.
Les domaines concernés sont ceux des catégories du site de « urbanisation-si.com » :
- les normes de l’OMG comme UML, BPMN, SysML, DMN, BMM, OCL, MDA, QVT, XMI,
- ArchiMate
- les architecture d’entreprise comme Togaf, l'urbanisation du SI, Praxeme,
- l’Ingénierie Dirigée par les Modèles avec MDE, ATL, Ecore...
- les processus métiers et le BPM
- les règles métiers et les BRMS
- la simulation et la validation de modèles
- la génération de code à partir de modèles
- la gestion de projet avec les méthodes agiles, les méthodes d’estimation et de recettes.
Voir la catégorie Modélisation de système de notre blog :
5
BPMN l’exemple type pour tout comprendre sans prendre d’aspirine
BPMN l’exemple type pour tout comprendre sans prendre d’aspirine
Voici l'exemple de référence de modélisation BPMN présentant les concepts principaux des processus métiers.
L'objectif de cet article est de montrer concrètement comment un processus métier est modélisé avec BPMN.
L'accent est mis sur les concepts de « bassins » (pool) modélisant les échanges (associations) inter organisation et de « couloirs » (lane) représentant la communication (flux de messages) explicitant la modélisation des collaborations entre des participants.
Cet article montre comment nous pouvons composer des modèles de processus avec des sous-processus et appeler des activités.
Cet exemple ne contient pas de modèles de processus exécutables, mais représente un modèle de processus se concentrant sur les aspects organisationnels de processus métiers.
Voir la catégorie BPMN de notre blog :
4
ArchiMate pour les nuls : les fondamentaux - 1
ArchiMate pour les nuls : les fondamentaux - 1
L'adoption du standard ArchiMate par le monde de l'architecture d'entreprise a connu une croissance rapide au cours de ces dernières années.
Si d’autres notations sont couramment utilisées par les architectes d'entreprise comme BPMN, DMN et UML, ArchiMate se distingue par son périmètre de modélisation couvrant à la fois les métiers et l’IT, le rendant particulièrement bien adapté pour améliorer l'alignement stratégique, métiers et IT.
Le cœur du framework comprend les couches métiers, applicatives et technologiques, avec des couches supplémentaires pour la stratégie, les éléments physiques, l’implémentation et la migration.
En intégrant les métiers et l’IT, ArchiMate répond aux principales attentes des parties prenantes de l’entreprise : le standard fournit un ensemble commun de concepts et de vues qui décrit toutes les couches de l'entreprise.
D’autre part, de nombreux concepts et relations dans ArchiMate sont basés sur les notations UML et BPMN, offrant une passerelle vers ces langages de modélisation. Mais ArchiMate ne cherche pas à remplacer ces standards.
Une grande partie de son succès peut en effet être attribuée au fait qu'ArchiMate inclut uniquement les concepts et les relations qui sont utiles, ce qui résulte en une courbe d’apprentissage très rapide de ce standard.
ArchiMate répond également à l'exigence des cadres dirigeants qui est d’avoir une vue d'ensemble de l’entreprise.
Le framework utilise des vues centrées sur les besoins spécifiques des différentes parties prenantes de l’entreprise, avec des objets pouvant provenir de différentes couches.
Par exemple, il est possible de montrer les applications, les technologies et les processus dans un seul et unique diagramme.
Voir la catégorie ArchiMate de notre blog :
Dans l’annexe de cet article se trouvent les 37 articles de l'étude de cas :
3
La méthode top-down dans l'urbanisme du Système d'Information
La méthode top-down dans l'urbanisme du Système d'Information
La méthode top-down part de la stratégie d'entreprise, pour en déduire les objectifs métiers, les processus métiers, le Système d'Information et enfin le Système Informatique.
En haut, juste en dessous de la stratégie d'entreprise qui ne fait pas partie de l'urbanisation du SI, on trouve la cartographie métier avec les processus métiers et leurs événements déclencheurs, puis en dessous, la cartographie fonctionnelle structurant le système d'information avec des blocs fonctionnels, un niveau encore en dessous, on trouve la cartographie applicative constituée de composants applicatifs du système informatique et enfin tout en bas la cartographie technique représentant l'infrastructure technique du système informatique.
Voir la catégorie ArchiMate de notre blog :
2
SysML : le diagramme d'exigence (requirement diagram)
SysML : le diagramme d'exigence (requirement diagram)
Lors de la modélisation de leur système, un grand nombre d’entreprises ont cherché à représenter les exigences afin d'assurer la traçabilité vers les modèles de conception UML.
Malheureusement, UML ne proposant pas de diagramme d’exigences, elles ont d’abord créé leurs propres profils UML ou bien utilisé des outils propriétaires.
UML ne prévoit rien pour représenter des éléments non-logiciels, des équations mathématiques, des contraintes, des flux (énergie, fluide...), des allocations structurelles/comportementales...
Et enfin UML utilise la terminologie orientée objet (classe, attribut, méthode...) qui si elle convient bien aux méthodes et langages de programmation objet, n'est pas celle adoptée par l'ingénierie système.
En l’absence de langage de modélisation normalisé dans le domaine des systèmes industriels complexes, l’OMG a créé un profil UML (package de stéréotypes, tags/values et contraintes OCL), nommé SysML en n'oubliant pas cette fois le diagramme d’exigences.
Voir la catégorie SysML de notre blog :
Dans cet article se trouvent les articles traitant :
- le contexte d'utilisation et la syntaxe des diagrammes SysML
- un exemple complet composé de 12 articles pour illustrer l'utilisation des diagrammes
- 25 articles expliquant la méthode et les bonnes pratiques accompagnées d'un nouvel exemple complet
1
TOGAF pour les nuls
And the winner is...
Au tout début, dans les années 70 à 80, il y avait SOA, je veux parler bien sûr de “Silo Oriented Architecture”, où les architectures propriétaires régnaient en maître (IBM, Bull, DEC…).
Puis, dans les années 90s, toujours SOA, mais cette fois pour “Spaghettis Oriented Architecture” avec l’avènement des serveurs d’application.
Avant internet, en France on avait le Minitel, de même avant l’architecture d’entreprise, on avait l’urbanisation du Système d’Information (~1980 dans le domaine bancaire).
L’enjeu principal est de mettre l’IT en adéquation avec le métier.
A cette époque, l’aspect stratégie est l’apanage de la DG et est négligé dans l'urbanisation du SI.
L’alignement stratégique, la création de référentiels, la définition de scénarios de transformation et l’analyse d’impact ont commencé aux USA avec PRISM framework (1986, IBM), le framework de Zachman (1987) (Architecture d'entreprise : le framework de Zachman pour les nuls), NIST EA model (1989), puis avec DoDAF (~2000, Department of Defense Architecture Framework).
A partir de là, on commence à voir apparaître en France des méthodes.
La Délégation Générale pour l'Armement a élaboré son cadre de référence : Agate (Atelier de gestion de l'architecture des systèmes d'information et de communication, ~2000).
En 2003, la méthode Praxeme (PRAXEME, la bonne (méthode) à tout faire ?) voit le jour autour d’une nouvelle architecture appelée SOA Service Oriented Architecture.
Voir les catégories de notre blog :
- Architecture Orientée Services (SOA)
Aujourd’hui en France, l’urbanisation du S.I. et Architecture d’Entreprise sont devenues synonymes.
En 1995, la première version de TOGAF (The Open Group Architecture Framework) est publiée. La transformation de l’architecture d’entreprise a sa méthode générique avec des solutions sur étagères.
Évidemment l’objectif suprême est la réalisation d’applications opérationnelles.
Pour se faire, il faut une vision globale couvrant les aspects stratégiques, métiers, organisationnels, s’assurer de l’alignement entre le métier et la technique, rechercher constamment l’évolutivité des SI et avoir une culture de l’innovation.
Tous les métiers évoluent, le simple développeur disparaît pour devenir fullstack, DevOps voir DevSecOps, l’architecte d’entreprise se métamorphose pour préparer des scénarios d’innovation et anticiper les impacts des tsunamis que sont l’Intelligence Artificielle (Machine Learning, Deep Learning, Big Data), le Cloud [IaaS, PaaS, SaaS, FaaS], IoT, DevOps CI/CD, Microservices Architecture…
On peut continuer le parallèle entre le développeur qui n’a plus à mettre en place la chaîne de réalisation d’une application, grâce aux nouveaux outils d’automatisation DevOps CI/CD, et l’architecte d’entreprise qui n’aura plus à assurer la traçabilité métier - IT, qui se fera automatiquement avec les outils d’IA d’analyse des données.
Voir la catégorie TOGAF de notre blog :
Dans l’annexe de cet article se trouvent les 41 articles de l'étude de cas :
Rhona Maxwel
@rhona_helena
“Celui qui n'appliquera pas de nouveaux remèdes doit s'attendre à de nouveaux maux ; car le temps est le plus grand des innovateurs.”
Francis Bacon
Références des principaux articles du blog
TOGAF
- 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
ArchiMate
- ArchiMate pour les nuls : les fondamentaux - 1
- ArchiMate la synthèse : les éléments de motivation - 2
- ArchiMate en condensé : les éléments de stratégie - 3
- ArchiMate l’essentiel : les éléments de la couche métier - 4
- ArchiMate mémento : les éléments de la couche application - 5
- ArchiMate aide mémoire : les éléments de la couche technologique - 6
- ArchiMate en abrégé : les éléments physiques de modélisation - 7
- ArchiMate mémento : Alignement de la couche métier avec les couches inférieures - 8
- ArchiMate : modélisation de l’alignement des couches d'application et de technologie - 9
- ArchiMate : les éléments d'implémentation et de migration - 10
- ArchiMate : vues et points de vue - 11
- ArchiMate : guide complet des éléments de modélisation - 12
BPMN
- 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 ?
A découvrir aussi
- Urbanisation SI : est ce qu'on a vraiment besoin de modéliser le SI ?
- Urbanisation du Système d'Information : abolissez l'apartheid et vive la cohabitation entre MOA et MOE !
- L'urbanisme des SI et architecture d'entreprise : retour vers le futur
Inscrivez-vous au site
Soyez prévenu par email des prochaines mises à jour
Rejoignez les 719 autres membres