urbanisation-si.com

Much ado about something

Architecture d’Entreprise et outillage

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 (Community Edition) du groupe BOC

Le groupe autrichien BOC, spin-off de l’université de Vienne, propose des solutions pour la gestion de processus métier (ADONIS), la gestion de l’Architecture d’Entreprise (ADOIT) et la gestion des risques (GRC-Suite). Nous nous intéressons aujourd’hui à la solution de gestion de l’Architecture d’Entreprise ADOIT:CE. Il s’agit ici d’une première prise en main, en utilisant le contenu fourni comme exemple.

Depuis plusieurs années, l’édition communautaire ADOIT:CE Classic était disponible gratuitement au téléchargement pour une installation locale, mais celle-ci commençait à dater (2013) et s’appuyait sur une version encore plus ancienne du SGBD SQL Server (Microsoft). En outre, la cohabitation avec d’autres applications utilisant également ce SGBD s’avérait délicate.

Après quelques années de patience, la nouvelle édition communautaire ADOIT:CE est enfin disponible depuis le mois de septembre 2020, pour une utilisation en ligne uniquement. Seuls un accès à l’internet et un navigateur web sont nécessaires. Mais nous vous recommandons également d’utiliser un grand écran, afin de pouvoir afficher des modèles en entier et lire les noms des objets.

Le SGBD SQL Server est, cette fois-ci, chez BOC (ou son prestataire cloud). La Community Edition est une édition gratuite, mais allégée, de l’édition payante Enterprise, qui, elle, peut être utilisée en ligne ou bien installée sur un serveur local (on-premise). Ces deux éditions gratuite et payante semblent alignées sur la même version, la version 11.0.4 la date de publication de cet article. Utiliser une application en ligne (SaaS), c’est l’assurance de disposer automatiquement de la dernière version, sans aucun effort de mise à jour.

Pour information, il existe également une application mobile optionnelle nommée « Ask ADOIT », disponible sur Apple Store et Google Play, qui permet de consulter son référentiel d’architecture ou son smartphone ou mieux, sur sa tablette.

Initialisation et présentation de l’environnement

Un navigateur web et une adresse électronique valide, pour recevoir le mot de passe, suffisent pour s’inscrire sur https://www.adoit-community.com/account-registration/ avant d’utiliser ADOIT:CE. Lors de la première connexion, quelques minutes de patience sont nécessaires pendant la création de l’environnement, qui est dédié à chaque utilisateur. Car l’édition communautaire d’ADOIT est mono-utilisateur, c’est là sa principale restriction. Après leur mise en mémoire cache initiale, l’affichage des pages est rapide. Il faut indiquer que l’interface utilisateur est sobre, voire dépouillée, en noir et blanc essentiellement. Quelques touches de couleur verte viennent l’égayer légèrement.

L’utilisateur n’est pas « agressé » par une multitude de menus et de fonctions, comme il pourrait l’être par d’autres outils concurrents, aux abords beaucoup plus dissuasifs. Mais derrière cette apparente simplicité, se cachent des menus contextuels à deux niveaux, accessibles en cliquant sur le bouton droit de la souris, sur un modèle, un objet, voire un groupe d’objets sélectionnés, et permettent d’accéder à de nombreuses fonctions, qu’il conviendra d’apprivoiser.

Des objets et des modèles

Cet environnement est créé avec des objets et des modèles à des fins de démonstration. Le nombre d’objets est limité à 2.000 et 568 objets et artefacts de démonstration sont déjà fournis. Cette limite peut sembler un peu juste à long terme. Le nombre de modèles est, quant à lui, limité à 1.000 et 25 modèles de démonstration sont déjà fournis. Cette fois-ci, cette limite semble très élevée (qui, parmi nos fidèles lecteurs, ont plus de 1.000 modèles pour représenter l’architecture de leur entreprise ?).

Deux toutes petites jauges, de couleur verte également, rappellent les ratios d’utilisation des objets et des modèles, par rapport à leurs limites. Sans doute passeront-elles au rouge à l’approche des limites ? Un accès direct et rapide aux objets et modèles récemment ouverts est possible par un menu dédié.

Pour créer un nouvel objet, il faut sélectionner son type (61 types différents) et son groupe d’appartenance, c.-à-d. avoir déjà une idée précise de son utilisation ultérieure. L’outil de recherche permet de retrouver facilement un objet ou un modèle. Il est possible d’indiquer un type d’objets uniquement, afin d’obtenir la liste de tous les composants, par exemple, et générer ensuite un diagramme de dépendances.

La sauvegarde des objets et des modèles, sur le cloud donc, est automatique, toutes les 20 modifications par défaut. Si vos données d’architecture sont hautement confidentielles ou si vous devez respecter la souveraineté numérique, il faudra donc préférer l’édition Enterprise payante, que vous pourrez alors installer on-premise.

Traduction partielle en français

Il est possible de choisir le français comme langue d’utilisation. La traduction est de qualité. Certaines listes sont toutefois restées en anglais (propriétés des objets et des modèles). La documentation, un manuel utilisateur de 213 pages au format Acrobat PDF, à télécharger à la première consultation ainsi que les vidéos, disponibles au centre de connaissances en ligne, sont, elles, en anglais uniquement. Ce n’est pas très grave, car il s’agit d’une documentation de référence, à ne consulter qu’en cas de besoin, et de vidéos peu instructives. En effet, ces vidéos trop courtes, réparties en deux catégories Débutant et Expert, répondent essentiellement aux questions Comment, mais pas aux questions Pourquoi.

La documentation, en anglais donc, concerne l’édition complète Enterprise et décrit quelques fonctionnalités qui ne sont pas disponibles dans l’édition communautaire allégée. En effet, l’édition CE d’ADOIT permet essentiellement de Cartographier et Documenter (ce qui constitue la base du travail de l’architecte d’entreprise, bien sûr), tandis que l’édition Enterprise propose en plus de :

- Contrôler et Publier, ce qui a du sens avec cette édition multi-utilisateurs,
pour passer en revue les objets créés par ses collègues, avant de les publier,

- Gouverner et gérer, pour obtenir la big picture de l’entreprise (statistiques,
évaluation des capacités, roadmap).

Forte orientation ArchiMate

Parmi les modèles fournis, figure le métamodèle d’ArchiMate, reproduit ci-dessous. D’autres standards internationaux sont simplement cités dans la documentation : ITIL, COBIT, TOGAF et RiskIT. N.B. ArchiMate est le langage de modélisation recommandé par le cadre d’architecture TOGAF.

Restitutions

35 vues différentes sont proposées par ADOIT:CE. Par défaut, ces vues sont listées par type et dans l’ordre alphabétique :

- Diagrammes de composition et de dépendances,

- Graphiques à barres et à bulles,

- Listes et matrices,

- Rapports bureautiques.

A l’usage, il faudra préférer la liste de ces vues regroupées par couche (Reports by Layer), dans l’ordre top-down. Un type de vue peut être utilisé dans plusieurs couches, ce qui permet à ADOIT:CE de proposer une soixantaine de restitutions :

- Motivation,

- Stratégie,

- Métier*,

- Application*,

- Technologie*,

- Physique

- Implémentation & Migration.

*On retrouve donc, parmi ces 7 couches, 3 couches du POS (Plan d’Occupation des Sols) pour l’Urbanisation du Système d’Information (CIGREF) : seule la couche fonctionnelle entre la couche Métier et la couche Application n’y figure pas.

Cycle de vie des objets

La date de début de validité (facile) et la date de fin de validité (beaucoup plus difficile à estimer) du cycle de vie de chaque objet peuvent être renseignées. Par défaut, tous les objets s’affichent, mais il est possible d’indiquer une date dans le filtre temporel optionnel. Ainsi, en indiquant la date du jour, c’est l’architecture As-Is qui s’affichera, tandis qu’en indiquant une date dans le futur, ce sera l’architecture To-Be. Cette approche, qui ne nécessite qu’un seul référentiel pour stocker les objets du passé, du présent et du futur, est habile. On peut également comparer le modèle To-Be avec le modèle As-Is, mais pour que cette fonctionnalité soit pratique, il faudrait disposer d’un écran encore plus grand.

Contenu de démonstration

Le contenu de démonstration fourni en exemple concerne l’architecture d’une banque fictive « ADOmoney Bank ». 24 modèles répartis dans 4 catégories (Gouvernance, Architecture d’Entreprise, Service Management et Gestion des Risques) sont fournis. Les modèles de la catégorie Architecture d’Entreprise sont répartis en 4 sous-catégories d’architecture : Transformation, Métier, Système d’information et Technologie.

La complexité de cet exemple est similaire à celle d’une architecture réelle. Voici un extrait de l’architecture des composants constituant une application et notamment leurs interfaces. Une vue miniature, mais panoramique (en bas à droite), permet d’ajuster automatiquement l’affichage d’un modèle à la taille de la fenêtre ou de zoomer en avant et en arrière. L’écran de 13 pouces d’un notebook est clairement trop petit pour avoir une vue globale du diagramme.

Vous noterez qu’ADOIT:CE dessine automatiquement des petits ponts sur les connecteurs, lorsque ceux-ci se croisent : cela peut sembler être un détail, mais cette simple fonctionnalité contribue grandement à la clarté des diagrammes.

Evaluation du portefeuille d’applications

Il est possible d’évaluer chaque application du portefeuille, selon trois critères, dans l’exemple ci-dessous, de satisfaction du métier du métier (axe horizontal), de coût (axe vertical) et d’importance stratégique (taille des points).

Gestion des données de référence

Il est possible de faire du Master Data Management : une matrice entre les composants et des objets métiers peut ainsi révéler que plusieurs composants écrivent dans un même objet métier, ce qui peut révéler des conflits, surlignés en orange dans l’exemple ci-dessous.

Importation et exportation

Les objets uniquement peuvent être importés au format Excel, ce qui est, en théorie, utile pour récupérer l’existant. Un classeur « ADOIT 11 ArchiMate Excel Import Template (FR).xlsx » est téléchargeable avec 61 feuilles différentes, une pour chaque type d’objet. Rien n’indique si chaque champ est obligatoire ou facultatif… Plusieurs types d’objets possèdent plus de 500 champs ! En pratique, cela ne sera pas très facile à utiliser.

Chaque modèle est exportable dans un document autonome, au format Acrobat PDF, ou comme un graphique, au format bitmap PNG ou au format vectoriel SVG, pour être inséré dans un document bureautique, au format Word ou PowerPoint par exemple.

La portabilité des données d’un outil vers un autre est un point important également. Il est possible d’importer et d’exporter modèles et objets via des fichiers au format (The Open Group). L’application Archi (www.archimatetool.com) au moins supporte également ce format.

Avantages                                     

ü Rien à installer, toujours la dernière version en ligne

ü Interface utilisateur relativement simple

ü Support complet d’ArchiMate

ü Gratuit pour toujours

ü Nombreuses fonctionnalités, pour une version gratuite

Inconvénients

û Différences entre modèles, rapports, vues et restitutions peu claires

û Rien pour supporter les diagrammes UML

û Pas d’aide méthodologique, lorsque l’on part de rien

û Les connaissances (ressources) ne sont pas en français

N.B. Les diagrammes BPMN sont supportés par l’autre outil ADONIS.

Conclusion

En guise de conclusion, si vous utilisez déjà le langage de modélisation ArchiMate ou si vous envisagez de l’utiliser, n’hésitez pas à essayer cet outil lors d’un vrai projet d’Architecture d’Entreprise, puis à partager vos impressions sous la forme de commentaires à la fin de cet article.

Thierry BIARD

Le nouveau style d’architecture pour concevoir des applications informatiques, voire pour urbaniser enfin le Système d’Information de l’entreprise.

C’est le premier article d’une nouvelle série qui vise à expliquer l’Architecture Micro-Services.

Evolution de l’architecture logicielle

Tentons de résumer l’évolution de l’architecture logicielle en trois grandes étapes, forcément réductrices, qui ont mené à l’Architecture Micro-Services :

1-      Architecture monolithique

A la fin du 20e siècle, les applications informatiques développées étaient monolithiques, c.-à-d. constituées d’un seul bloc, parfois très gros. Ce qui n’empêchait pas la programmation modulaire. Seul le stockage des données, centralisé, était confié à un Système de Gestion de Base de Données (SGBD).

De nombreuses applications monolithiques sont encore en production aujourd’hui (souvent une application monolithique par domaine métier), tellement cloisonnées entre elles que l’on parle alors d’architecture en silos.

2-      Architecture Orientée Services

Au début du 21e siècle, disons vers 2005, un premier effort de partitionnement a été effectué avec l’Architecture Orientée Services (SOA), pour supporter l’avènement des processus métier et leur orchestration. Les données étaient toujours centralisées dans un SGBD.

Les solutions techniques mises en œuvre, peut-être trop lourdes (protocole SOAP et autres Web Services sur un ESB - Enterprise Service Bus), n’ont pas permis à la SOA de rencontrer le succès escompté : son usage s’est souvent limité aux gros projets dans les grandes entreprises.

3-      Architecture Micro-Services

Le terme micro-service fut utilisé pour la première fois en 2011, lors d’une conférence pour les architectes. Un des objectifs était de proposer un mécanisme de mise à l’échelle (scaling) plus performant et surtout plus flexible pour faire face à l’accroissement du nombre de visites des sites web les plus populaires (Amazon, eBay, Google, Netflix).

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.

Principes de l’Architecture Micro-Services

C’est un style d’architecture dont l’approche est de :

- concevoir une application en une suite de petits services, appelés micro-services,
  découplés le plus possible les uns des autres,

- chaque micro-service :

• répond à une fonctionnalité métier unique,
• est simple ou moins complexe,
• est indépendant, voire autonome,
• s’exécute dans son propre processus,
• dispose de sa propre base de données,
• peut être développé dans un langage de programmation quelconque,
• communique avec un protocole léger,
• est déployable indépendamment des autres,
• est déployable de façon continue et automatisée,

- la gestion centralisée des micro-services doit être réduite au strict minimum
(service discovery, par exemple ; il s’agit d’un dispositif pour découvrir les services).

Le fait que chaque micro-service doit disposer de sa propre base de données est sans aucun doute la différence principale avec l’Architecture SOA et provoque un fort impact sur la conception.

Partitionnement et granularité

L’Architecture Micro-Service se doit de répondre à une question primordiale : Comment partitionner une application volumineuse ou le Système d’Information de l’entreprise en micro-services ? Et ce partitionnement a son pendant : quelle granularité pour ces micro-services ?

Si vous comptez sur The Open Group (l’auteur de TOGAF) pour connaitre la bonne granularité d’un micro-service, vous serez fort déçu : « les bons micro-services sont situés entre les monolithes et les nanoservices ». Nous n’osons pas reproduire ici le diagramme lapalicien associé à cette affirmation, visible à cette adresse https://www.opengroup.org/soa/source-book/msawp/p6.htm.

Le partitionnement en tant que tel ne doit pas être un objectif, mais la conséquence de l’application des principes de l’Architecture Micro-Services. La démarche à suivre sera sans doute différente selon qu’il s’agisse de refondre une application monolithique existante (et même tout le Système d’Information de l’entreprise) ou de concevoir une nouvelle application en partant d’une feuille blanche.

L’approche de type top-down, orientée décomposition, est la plus courante, mais une approche alternative de type bottom-up, orientée agrégation, n’est pas exclue. Nous reviendrons sur ce sujet crucial du partitionnement d’une application et de la granularité des micro-services.

Prochains articles

Après les principes-avantages de l’Architecture Micro-Services, que nous venons de présenter dans ce premier article, nous nous intéresserons dans le deuxième article aux :

- Considérations techniques, inconvénients et impact sur l’organisation de l’Architecture Micro-Services,

Puis nous développerons le sujet de l’Architecture Micro-Services, souvent associé à d’autres sujets plus conceptuels, déjà abordés sur ce blog (liste non exhaustive) :

- Le partitionnement d’une application et la granularité des micro-services,

- L’Architecture Micro-Services dans les cadres d’Architecture d’Enterprise (Praxeme, TOGAF),

- Les méthodes de conception de l’Architecture Micro-Services,

- La modélisation de l’Architecture Micro-Services avec UML, ArchiMate ou autres,

- L’Architecture Micro-Services et les bases de données,

- L’Architecture Micro-Services et les processus métier,

- L’Architecture Micro-Services et les règles métier,

- La gestion des API et la gouvernance des micro-services.

N’hésitez pas à poster un commentaire en cliquant sur le lien ci-dessous.

Thierry BIARD

Architecte d’Entreprise, Spécialiste EDI, BPMN et DMN, je propose mes compétences aux leaders du Transport et de la Logistique, pour mettre en place des échanges B2B efficients. J’ai fait mienne cette citation de Nelson Mandela : « Je ne perds jamais. Soit je gagne, soit j’apprends ». En fait, j’apprends plus souvent que je gagne !

« La vie ce n’est pas d’attendre que l’orage passe, c’est d’apprendre à danser sous la pluie ».

Voici quelques compléments d’information intéressants qui ont été donnés par l’éditeur BOC Group.

La version payante de l’application ADOIT peut être complétée par des modules optionnels UML et BPMN. Le module UML propose les 4 diagrammes les plus courants : cas d’utilisation, classes, paquetages et activités, tandis que la module BPMN propose l’emblématique diagramme de collaboration (une alternative plus qu’intéressante au diagramme d’activités UML). Ces deux modules partagent le même référentiel d’objets, unique par définition.

L’article principal ci-dessus concernait la prise en main de la version 11 d’ADOIT:CE. La prochaine version 12, disponible en décembre 2020, promet encore plus de ressources en français, notamment le métamodèle d’ArchiMate. Cette traduction s’appuiera sur le glossaire officiel anglais-français de The Open Group, qui publie ce langage de notation standard.

Enfin, légèrement effrayé par le nombre conséquent de champs importables pour chaque objet (souvent plus de 500), il convient de signaler que ces champs ne concernent pas uniquement les propriétés des objets, mais permettent également de décrire les relations entre eux.

Thierry BIARD

Intéressons-nous à quelques considérations techniques importantes, puis aux inconvénients de l’Architecture Micro-Services et enfin à son impact sur l’organisation.

Dans notre premier article L’Architecture Micro-Services expliquée à ma fille, nous avons résumé l’évolution de l’architecture logicielle, présenté les principes de ce style d’architecture et posé les questions du partitionnement d’une application monolithique et de la granularité des micro-services.

Considérations techniques

L’architecture idéale est sans doute celle qui dépend le moins de toutes considérations techniques, mais au moment où il faut la réaliser, il est nécessaire de disposer des outils adéquats. La panoplie des outils dont on dispose pour mettre en place les micro-services, selon l’architecture préalablement établie, est très large.

Pour être précis, il vaudrait mieux parler de composants logiciels qui proposent des micro-services. Les composants favorisent la réutilisation du code déjà développé et limitent automatiquement la redondance (du code, mais aussi des données), que l’on trouve bien souvent dans une architecture en silos. Attention toutefois à ce que cette lutte contre la redondance n’augmente pas le couplage entre les micro-services.

Ces composants sont encapsulés et accessibles uniquement via leurs API (Application Programming Interface), soit selon le style RESTful (REpresentational State Transfer), qui s’appuie sur le protocole synchrone HTTP, soit via un système de messagerie au protocole asynchrone (de type message broker). Ce principe de composants encapsulés et échangeant entre eux via leurs interfaces n’est pas sans rappeler le paradigme de la Programmation Orientée Objet (OOP).

Tandis que les micro-services peuvent échanger entre eux directement via leurs API, les Clients externes peuvent éventuellement accéder à toutes les API de façon unifiée, grâce à une passerelle (API Gateway). Le couplage entre les micro-services peut être réduit en utilisant le mécanisme d’Inversion des Dépendances : les micro-services doivent dépendre de leurs abstractions (couches de haut niveau), mais pas de leurs implémentations (couches de bas niveau).

Autre considération, les micro-services sont exécutés par des serveurs qui n’ont pas besoin de connaitre leurs contextes d’utilisation (stateless servers), ce qui permet de les distribuer et de les dupliquer plus facilement.

La dernière considération technique importante est la conteneurisation (containerization), qui facile grandement le déploiement des micro-services, avec une règle simple à appliquer : un seul micro-service, ou plutôt un seul composant logiciel donc, par conteneur.

Ces considérations techniques seront approfondies dans nos prochains articles.

Inconvénients de l’Architecture Micro-Services

Tandis que les principes de l’Architecture Micro-Services sont généralement partagés par tous, car ils constituent autant d’avantages, les inconvénients sont plus rarement évoqués. Ces inconvénients sont bien souvent les conséquences de ces principes et constituent parfois des contradictions. Il est toutefois possible d’atténuer ces inconvénients : c’est en fait là que réside le talent de l’architecte.

1- Terme « micro » très relatif : la difficulté est de bien définir la granularité des micro-services. Cette granularité est variable d’un micro-service à l’autre. Ce n’est pas une bonne idée d’essayer d’obtenir une granularité uniforme pour tous les micro-services.

2- Problème de mise à jour des bases de données cloisonnées (chaque micro-service ayant sa propre base et pouvant être instancié plusieurs fois par le mécanisme de mise à l’échelle). Le mécanisme usuel de transaction de type « commit » n’est plus suffisant ; un mécanisme plus complexe appelé « saga » est nécessaire.

3- Défi en matière de débogage, test, déploiement des applications constituées de micro-services. Chaque micro-service aura été testé individuellement au préalable, mais ensuite, il faudra bien les tester tous ensemble, de façon automatisée de préférence.

4- Changements compliqués à cause des éventuelles dépendances entre les micro-services. Les micro-services supportent toutefois le versioning et plusieurs versions d’un même micro-service peuvent coexister, permettant une migration progressive vers la dernière version.

5- Application globale moins performante (latence), car dépendante du réseau (éventuellement moins fiable). Un protocole de communication asynchrone sera souvent préféré à un protocole synchrone, afin d’éviter d’attendre trop longtemps une réponse « immédiate » à chaque requête. De plus, l’usage d’un mécanisme de lecture via une mémoire cache est recommandé, afin d’optimiser la performance.

6- Besoin d’authentification, voire de chiffrage, pour diminuer les failles de sécurité du réseau.

(Liste non exhaustive, sans doute)

Impact sur l’organisation

Ce serait très réducteur de résumer l’Architecture Micro-Services à son aspect purement technique, car elle a également un impact fort sur l’organisation de la direction informatique de l’entreprise et l’exploitation d’une infrastructure distribuée et automatisée va induire de nouvelles pratiques, et même un changement de culture.

Ainsi, la frontière entre le build et le run (selon ITIL) disparaît. Cette approche est alignée avec la tendance DevOps (Development & Operations) avec Intégration et Livraison Continues (CI/CD). A noter que l’imbrication de la conception avec le déploiement en production des micro-services nécessite un champ très large de compétences.

Exemple concret de l’impact sur l’organisation : La taille de l’équipe responsable d’un micro-service est plus ou moins proportionnelle à la taille de ce micro-service. Chaque équipe, malgré sa taille réduite, doit pouvoir travailler de manière autonome. Amazon conseille de limiter la taille de l’équipe à une douzaine de personnes (two-pizza team !).

Les responsabilités nouvelles sont distribuées par micro-service, et sont étendues d’un bout à l’autre du cycle de vie du micro-service, c.-à-d. depuis la conception jusqu’à la production et même le support. Aussi faut-il raisonner en termes de Produit (alors qu’il s’agit d’un Service…), comme dans une méthode Agile, et non en termes de Projet, avec une fin planifiée.

Thierry BIARD

“In theory, there is no difference between theory and practice, while in practice, there is.”
Benjamin Brewster

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”.

"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)

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 :

“Maintenant que nous avons abouti à un paradoxe, nous avons des chances de progresser.”

Niels Bohr

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.

"Si vous voulez tuer une idée à coup sûr, créez un Comité pour l'évaluer."

Charles Kettering

La spécification date de fin 2016 et est, ou devrais-je plutôt dire “était”, destinée à venir en complément au BPMN (Business Process Model Notation). 

Seulement voilà, les compléments, demandant des efforts d’assimilation supplémentaires, les utilisateurs ont souvent tendance à s’en passer en les contournant, et au fil du temps, ils tombent dans les oubliettes.

Comme nombreux avant nous, nous allons donc démontrer que l’on peut se passer de CMMN en utilisant BPMN et les “sub-process ad hoc”.

(exemple pédagogique d'un dossier de suspicion de fraude à la mutuelle modélisé avec CMMN)

Objectifs de CMMN 

BPMN a été adoptée comme norme de modélisation des processus métier, qui sont décrits comme des séquences prédéfinies d'activités avec décisions (passerelles) pour diriger la séquence le long de chemins alternatifs ou pour des itérations. 

Ces modèles sont efficaces pour des processus métier prédéfinis, entièrement spécifiés et reproductibles. (Voir nos articles dans la catégorie BPMN)

Qu’en est-il de la modélisation d’activités qui ne sont pas prédéfinies et reproductibles, mais qui dépendent plutôt de l'évolution des circonstances et des décisions ad hoc des experts métier concernant une situation particulière ?

C’est en partant de ce manque dans les normes de modélisations que l’OMG a créé CMMN.

Les applications sont nombreuses, on peut citer par exemple : les traitements antifraude, la gestion des réclamations dans les assurances, les diagnostics médicaux…

Le kit de survie CMMN

Il fut un temps où nous aurions pu utiliser l’outil open source bpmn.io, qui proposait le tiercé gagnant de la modélisation : BPMN pour les processus métier, DMN (Decision Model Notation) (voir nos articles dans la catégorie DMN) pour les règles métier et CMMN pour les processus ad hoc et non reproductibles, mais aujourd’hui CMMN est absent de la plateforme.

Heureusement pour notre démonstration, l’outil Enterprise Architect de Sparx Systems supporte toujours CMMN, en plus de BPMN, DMN et bien d’autres choses encore pour notre plus grand bonheur. 

Comme cet article n’a pas pour vocation d’être exhaustif concernant la norme, voici donc les principaux artefacts de modélisation avec leur description :

Exemples de patterns CMMN

Enterprise Architect propose même un “Model Wizard” avec 3 patterns.

“Three Choice Tasks”

Ce pattern crée des éléments et un diagramme qui modélisent un choix simple où une tâche particulière doit être effectuée avant que d'autres tâches puissent être sélectionnées. La tâche sélectionnée dépend généralement de ce qui est déterminé dans la tâche précédente.

(pattern CMMN “Three Choice Tasks”)

“Two Phase Expanded Case Plan”

Ce pattern crée des éléments et un diagramme qui contient un modèle de plan de cas composé de deux étapes dont chacune contient cinq tâches dont deux sont discrétionnaires. Les deux étapes sont déclenchées par deux événements différents et pourraient potentiellement s'exécuter simultanément.

(pattern CMMN “Two Phase Expanded Case Plan”)

“Basic Five Task Plan”

Ce pattern crée des éléments et un diagramme où un événement utilisateur déclenche une tâche humaine qui est terminée, puis un certain nombre d'autres tâches peuvent être terminées. Pour atteindre un jalon, une tâche humaine doit être terminée. À tout moment, un événement de minuterie pourrait être déclenché mettant fin à l'exécution du cas.

(pattern CMMN “Basic Five Task Plan”)

Modélisation CMMN d’un cas de suspicion de fraude à la mutuelle

L’exemple pour notre démonstration sera volontairement simplifié, pour être avant tout pédagogique et se concentrer sur les sous-processus ad hoc.

La nature des fraudes reste assez classique : ordonnances fausses ou trafiquées, déclarations mensongères, fausses identités...

A l'origine du soupçon, souvent un signalement par les gestionnaires, qui émane de leur intuition face à un dossier, car les algorithmes d'IA n’éprouvent pas (encore) de sentiments.

D’autres niveaux reposent sur des moteurs de machine learning.

La tâche humaine bloquante “Analyser les arguments et les pièces justificatives fournis” est une tâche ad hoc. En effet, le gestionnaire doit adapter les vérifications en fonction de la spécificité des affirmations et des pièces fournies par l’assuré.

A noter aussi la tâche humaine non bloquante “Lancer le moteur d'IA”, qui est facultative, en fonction par exemple du type de fraude.

(exemple pédagogique d'un dossier de suspicion de fraude à la mutuelle modélisé avec CMMN)

Modélisation BPMN du même cas de suspicion de fraude à la mutuelle

Pour arriver à la même sémantique, nous avons utilisé l’artefact BPMN “sub-process ad hoc” nommé “Sous-processus ad hoc pour analyser les dires de l'assuré” avec le sigle ~ (tilde) en bas de l'activité et l'événement intermédiaire interruptible (en pointillé) typé message : “L'entretien entraîne des vérifications spécifiques”.

(le même exemple que précédemment, mais en utilisant BPMN en remplacement de CMMN)

Conclusion

La réticence aux changements, aux nouveautés, est présente partout.

Convaincre des experts métier de faire l’effort d’apprentissage d’une nouvelle notation comme CMMN, alors qu’on vient de leur infliger BPMN et qu’ensuite on leur a rajouté une couche avec DMN, en leur vendant que c’était complémentaire, est totalement une mission impossible. 

Les utilisateurs chercheront à s’en passer par tous les moyens.

Les solutions de contournement existent, comme nous l’avons démontré en utilisant les subprocess ad hoc de BPMN. 

D'autres défauts viennent s'ajouter, comme sa valeur limitée, la connaissance métier enfouie dans des règles invisibles, les artefacts de modélisation mal interprétés et rien n'est prévu pour montrer l'alignement de l'informatique avec le métier. 

CMMN rejoint donc le club des normes (CWM, KDM, VDML, MDMI, SBVR, SPEM...) qui n’ont pratiquement jamais été utilisées, car souvent trop complexes à mettre en œuvre et, en tous les cas, toujours boudées par les utilisateurs. 

“On mesure l’intelligence d’un individu à la quantité d’incertitudes qu’il est capable de supporter”

Emmanuel Kant

Compléments de lecture

• 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 ?
  
  
• DMN - L'antisèche de la notation complète des composants d'un DRD (Decision Requirement Diagram) : notation de la décision
   
• DMN - L'antisèche de la notation complète des composants d'un DRD (Decision Requirement Diagram) : notation des règles de connexions
   
• Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN (Decision Model Notation) : le processus métier BPMN
  
  
• Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN (Decision Model Notation) : La vue des exigences des décisions
   
• Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN (Decision Model Notation) : Le niveau logique de décision
  
  
• 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
   

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)