urbanisation-si

urbanisation-si

ADOIT:CE pour la gestion de l’Architecture d’Entreprise

Much ado about something

adult-1822449_1920_lite.jpg

 

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.

 

Image2.png 

 

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.

 

Image3.png 

 

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.

 

 Image4.png

 

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.

 

 Image5.png

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.

 

 Image6.png

 

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

 

 Image7.png

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.

 Image8.png

 

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

 

« La rumeur est la fumée du bruit. »
Victor Hugo

10/11/2020
2 Poster un commentaire

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.

microservices-architecture-principes.jpg

 

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


18/04/2020
4 Poster un commentaire

ADOIT:CE (compléments d’information)

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


19/11/2020
0 Poster un commentaire

Inconvénients de l'Architecture Micro-Services

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

mciroservices-archictecture-inconvenients.jpg

 

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


28/04/2020
2 Poster un commentaire

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 ?

 

meilleurs-articles-architecture-entreprise-methodes-outils

 

(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 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

 

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 : 

 

1

TOGAF pour les nuls

 

And the winner is...

 

TOGAF pour les nuls

 

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

 

  1. TOGAF pour les nuls.

  2. Le processus des itérations ADM (Architecture Development Method), le moteur de la transformation d’entreprise TOGAF (The Open Group Architecture Framework)

  3. 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)

  4. 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)

  5. 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)

  6. 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)

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

  8. 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)

  9. 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)

  10. La vision dynamique des exigences de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

  11. La structure de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

  12. Les concepts du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

  13. Le diagramme de classe UML du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

  14. L’extension « Gouvernance » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

  15. L’extension « Services » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

  16. L’extension « Modélisation de processus métier » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

  17. L’extension « Modélisation des données » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

  18. L’extension « Consolidation d’infrastructure » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

  19. L’extension « Motivation » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

  20. Le référentiel TOGAF sous toutes ses coutures : le « Continuum d'Entreprise » et la réutilisation de l'architecture

  21. Le référentiel TOGAF, le patrimoine des informations et des bonnes pratiques pour toute l’entreprise

  22. Gouvernance d’entreprise, Gouvernance technologique, Gouvernance informatique et Gouvernance de l’architecture : mais où se situe la Gouvernance TOGAF ?

  23. Le cadre de gouvernance de l'architecture : identifier les processus et les structures organisationnelles efficaces

  24. Gouvernance de l'architecture en pratique : principaux facteurs de succès et éléments d'une stratégie efficace

ArchiMate

 

  1. ArchiMate pour les nuls : les fondamentaux - 1

  2. ArchiMate la synthèse : les éléments de motivation - 2

  3. ArchiMate en condensé : les éléments de stratégie - 3

  4. ArchiMate l’essentiel : les éléments de la couche métier - 4

  5. ArchiMate mémento : les éléments de la couche application - 5

  6. ArchiMate aide mémoire : les éléments de la couche technologique - 6

  7. ArchiMate en abrégé : les éléments physiques de modélisation - 7

  8. ArchiMate mémento : Alignement de la couche métier avec les couches inférieures - 8

  9. ArchiMate : modélisation de l’alignement des couches d'application et de technologie - 9

  10. ArchiMate : les éléments d'implémentation et de migration - 10

  11. ArchiMate : vues et points de vue - 11

  12. ArchiMate : guide complet des éléments de modélisation - 12

 

BPMN

 

  1. BPMN 2 : les concepts de base des processus métiers

  2. BPMN pour les nuls : les collaborations

  3. BPMN pour les nuls : les chorégraphies (Choreographies)

  4. BPMN pour les nuls : les conversations

  5. BPMN : norme OMG - synthèse des éléments graphiques

  6. BPMN : l'antisèche pour rester incollable en modélisation de processus

  7. BPMN l’exemple type pour tout comprendre sans prendre d’aspirine

  8. BPMN : la norme, toute la norme rien que la norme. L'exemple à lire en attendant une pizza

  9. BPMN : mais que dit la norme sur les sous-processus et la gestion des événements d'interruption et de remontée d'incidents ?

  10. BPMN : processus exécutables, comment s'y prendre ? (1/3)

  11. BPMN : processus exécutables, comment s'y prendre ? (2/3)

  12. BPMN : processus exécutables, comment s'y prendre ? (3/3)

  13. Comment identifier, simuler, améliorer et modéliser les processus métiers ?

  14. Comment mettre en place un jeu de rôles pour modéliser un processus métier ?

 


19/01/2021
0 Poster un commentaire

Comment éviter la loi de Conway et faciliter ainsi l’agilité avec l’approche Micro-Services ?

« Les organisations qui conçoivent des systèmes [...] tendent inévitablement à produire des designs qui sont des copies de la structure de communication de leur organisation. » Melvin Conway (Source Wikipédia)

 

conception-microservice-loi-de-conway-adoit-ce-visual-paradigm

 

(Mars Climate Orbiter est une sonde spatiale de la NASA lancée en 1998 pour étudier la planète. A la suite d'une confusion d'unités, la sonde se place en orbite trop basse et est détruite.

Un logiciel développé par les ingénieurs de Lockheed, concepteurs de la sonde, communiquait la poussée des micro-propulseurs en unités de mesure anglo-saxonnes (livre-force · seconde), tandis que le logiciel de l'équipe de navigation du JPL qui recevait ces données pour les calculs des corrections de trajectoire attendait des données en unités du système métrique (newton · seconde)).

 

 

Lorsqu'un système cible est décomposé en services, il existe un risque réel que sa décomposition s'aligne sur les silos ou les strates (cela dépend comment on voit les choses) existants au sein de l'organisation.

 
L’organisation des équipes a un effet direct sur le système que l’on conçoit. Les applications peuvent alors refléter les intérêts de l’organisation au détriment des réels besoins utilisateurs.
Ça signifie qu'il existe un risque pour que le système soit plus fragile, car il y a plus de modules indépendants à gérer et ne s’intégrant pas bien, même si le service résultant peut communiquer avec chacun d’entre eux.

 
De plus, si les services qui composent le système ne sont pas conçus pour le bon objectif, ils ne peuvent pas être réutilisés. Les coûts de développement et de maintenance peuvent également augmenter si les services sont conçus selon des périmètres organisationnels ou technologiques.

 
Une conception en ayant à l’esprit le métier comme unique objectif peut devenir critique. 

 
Les équipes, au-delà des frontières organisationnelles, doivent se réunir et concevoir les services conjointement, plutôt que d'utiliser des micro-services pour acheminer les appels entre les équipes.

 
Voici un extrait du contexte d’une de nos études de cas, qui nous sert comme POC pour tester des outils, illustrer des patterns ou des architectures comme les micro-services.

 
Pour avoir de la matière, nous avons choisi le monde assurantiel. Nous appellerons ClairPrev notre assureur fictif, résultant de nombreuses fusions/acquisitions et reflétant ce qui s'est passé ces derniers temps.

 

architecture-micro-services-loi-de-conway-visual-paradigm-free

 

Dans ce scénario, la conception du système a été calquée sur la structure de communication de l'organisation. Des défauts évidents apparaissent à cause de services isolés. 

 
Le système de prestation ne peut pas évoluer, car chaque domaine métier a son propre processus, chacun a sa propre vision de l’entité métier “Personne”. Chacun utilise des termes différents ou, pour une même entité métier, leur prête des sémantiques différentes.

 
Les services conçus dans ce scénario vont également être impactés par des changements qui affectent généralement une organisation, comme les aspects légaux, les fusions et acquisitions. 

 
Aujourd’hui, les exigences d’agilité dans les organisations et les systèmes sont devenues stratégiques. Tout change tout le temps, mais pas toujours au même moment. Un système n’est donc agile que s’il est possible de le faire évoluer par morceau. Il est d’autant plus agile que les morceaux sont plus petits et qu’ils sont faiblement couplés entre eux.

 
Les services ne doivent pas être évalués par chaque domaine, avec leurs propres paramètres de configuration, tests, performance, qualité, sécurité, time to market... 

 
L'architecture micro-services fonctionne bien si les architectes métier et techniques de chaque domaine communiquent entre eux pour concevoir les services conjointement, afin de servir les objectifs stratégiques de l’entreprise. 

 

architecture-micro-services-redesign-loi-de-conway-adoit-ce

 

Le diagramme ArchiMate ci-dessus montre un refactoring avec une approche architecture micro-services (AMS). A ce niveau d’échelle, on ne peut la différencier d’une architecture SOA (Service Oriented Architecture), qui de toute manière n’est que l’ancêtre de l’AMS.

 
En appliquant la loi de Conway, les équipes appartenant au domaine “Processus Transverses” se sont réunies pour concevoir un service amont de prestation. Lorsqu'une telle demande est reçue, elle est stockée, fournissant une vue unifiée de la personne (déclarant). Suivant les principes de la SOA, on ajoute un service d'orchestration (Service Orchestration de Prestation), qui reçoit la demande, puis selon les cas, appelle les services Santé, Prévoyance ou Services à la Personne. 

 
Ces appels activent ensuite chaque module de gestion de paiement.

 
Comme la conception des services ne suit plus les frontières organisationnelles, technologiques ou de communication, ils peuvent alors résister à des changements dans l'organisation, comme des fusions, des nouvelles réglementations nationales ou européennes, ainsi que le reengineering de processus. 

 
Les services sont indépendants et supportent des fonctions métier bien spécifiques.

 

Notes sur les outils utilisés

Visual Paradigm Free Edition

Pour ceux qui seraient intéressés par les outils utilisés pour des 2 diagrammes ArchiMate montrant les flux échangés entre blocs fonctionnels, le premier a été réalisé avec Visual Paradigm :

 

https://online.visual-paradigm.com/fr/diagrams/

 

Visual-Paradigm-Free-Edition

 

 

C’est la mallette “James Bond” du parfait consultant powerpointer qui doit dégainer des présentations avec des schémas sexy. Mais attention, ici point de référentiel d'artefacts d’architecture, d’outils de traçabilité, d’analyseur d’impact…, non non, juste du coloriage !

 

ADOIT:CE Community Edition

Le 2ème diagramme a été réalisé avec ADOIT:CE. Voir nos articles :

 

 

Là, par contre, c’est du lourd (bien qu’il s’agisse d'un client léger), avec, bien sûr, un référentiel d’objets, le support complet d’ArchiMate 3, des outils de traçabilité, bref la mallette du parfait cartographe.

 

ADOIT-CE

 

Conclusion

Nos systèmes, nos produits, nos outils reflètent nos rôles, nos processus et nos méthodes.

Pour enfoncer le clou, on peut citer, par exemple, Eric S. Raymond qui écrivait : "si vous avez quatre équipes travaillant sur un compilateur, vous aurez un compilateur à quatre étapes".

 

Rhona Maxwel

@rhona_helena

 

" Sauriez-vous compléter la suite de Conway, John de son prénom :

1

11

21

1211

? "

 

A découvrir aussi

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.

 

Inconvénients de l'Architecture Micro-Services

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

 

Estimation de la complexité d’une Architecture Micro-Services

pour la comparer avec la complexité d’une architecture monolithique.

 

ADOIT:CE pour la gestion de l’Architecture d’Entreprise

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)

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

 


12/01/2021
0 Poster un commentaire

Estimation de la complexité d’une Architecture Micro-Services

pour la comparer avec la complexité d’une architecture monolithique.

20200703115506_01_recadrée

Dans notre premier article sur l’Architecture Micro-Services, nous avons indiqué parmi les principes que :

 

  • une application composée de micro-services serait plus simple et donc moins complexe qu’une application monolithique équivalente (c.-à-d. ayant les mêmes fonctionnalités).

 

Il s’agit là d’une sorte d’intuition, présentée comme un postulat. Pourrions-nous le démontrer ?

Postulats et formule magique

La programmation modulaire est apparue peu après les prémices de l’informatique, dès les années 1970, et quelques connaisseurs se sont intéressés à l’impact de la modularité sur la complexité d’un système. Cette complexité est liée au nombre de fonctions dans un système. Une constatation généralement faite par tous permet de formuler un second postulat :

 

  • la complexité d’un système croît exponentiellement avec le nombre de ses fonctions.

 

Comment quantifier cette croissance exponentielle ? Selon l’étude de Scott N. Woodfield en 1979 :

 

  • accroitre de 25 % le nombre de fonctions d’une solution logicielle double sa complexité.

 

Cette constatation est connue comme la loi de Robert L. Glass, qui porte le nom de celui qui l’a exprimée en 2003. Puis Roger Sessions l’a formulée ainsi en 2011, après une simplification mathématique justifiée : Complexité(NombreFonctions) = NombreFonctions3,11.

 

Dans le cadre d’une Architecture Orientée Services (SOA), il convient d’appliquer cette formule pour estimer la complexité de chaque partition, une partition étant un module contenant une ou plusieurs fonctions. Roger Sessions a constaté que la complexité dépendait également du nombre de dépendances entre les partitions-modules. La complexité totale est donc formulée ainsi :

 

ComplexitéTotale(NombreFonctions,NombreDépendances) =
NombreFonctions3,11 + NombreDépendances3,11

 

N.B. Afin de ne pas compter les dépendances deux fois, on les comptera au niveau de chaque module qui dépend d’autres modules (les pointes de flèches sur un diagramme de dépendances).

 

Vous noterez qu’une dépendance a la même pondération d’une fonction. L’unité de mesure est la SCU (Standard Complexity Unit). Il ne s’agit pas vraiment d’une mesure absolue, mais d’une mesure relative, qui va permettre de comparer la complexité des différentes solutions d’architecture d’un système.

Vers la simplexité ?

Appliquons cette formule d’estimation de la complexité à un exemple relativement simple. Soit une application de vente de livres en ligne, avec 5 fonctions principales :

 

  • Gestion des utilisateurs (les clients, mais aussi les libraires),
  • Catalogue des livres,
  • Avis des lecteurs,
  • Gestion des achats (paniers, commandes),
  • Vitrine (interface utilisateur).

 

Les dépendances entre ces 5 fonctions principales peuvent être représentées comme cela :

 

 

Comparons la complexité d’une application monolithique, qui contient ces 5 fonctions, avec une application où chaque fonction a été partitionnée en un micro-service :

 

 

On constate que l’estimation de la complexité de l’application micro-services avec ce partitionnement maximum est presque deux fois moins élevée que celle de l’application monolithique.

 

Considérons maintenant qu’il serait logique de regrouper l’avis des lecteurs avec le catalogue des livres, soit deux fonctions dans le même module-micro-service :

 

 

Ce regroupement divise encore par deux l’estimation de la complexité ! En effet, on obtient un module-micro-service un peu plus complexe, car contenant deux fonctions au lieu d’une seule, mais on supprime une dépendance, ce qui a un impact plus fort.

Compromis, chose due

Bien sûr, nous pourrions débattre sur le postulat de départ et notamment sur la valeur 3,11 de la puissance, qui traduit l’augmentation exponentielle de la complexité selon le nombre de fonctions. Mais une chose est sûre :

 

  • la complexité du système conçu ne sera maitrisée que si l’architecte trouve un compromis entre son partitionnement en modules et la dépendance entre ces modules.

 

Thierry BIARD

 

« En mettant au premier plan l'expérience vécue et le corps en action, la simplexité est également utile pour penser un environnement mieux adapté à l'homme. »
Petit traité de cyber-psychologie de Serge Tisseron


03/07/2020
1 Poster un commentaire

ArchiMate : le diagramme de contextes de projets, comparaison du diagramme UML de TOGAF et celui avec ArchiMate - 37

L’objectif de cet article est la traduction de la modélisation utilisant le profil UML vers le langage ArchiMate concernant le diagramme de contextes de projets de la phase E Solutions et opportunités de TOGAF.

En ayant étudié la modélisation TOGAF avec le profil UML, il est facile d’apprendre ArchiMate.

C’est cette approche pédagogique que nous vous proposons.

  

Explications du diagramme de contextes de projets avec TOGAF utilisant le profil UML

Le diagramme de contextes de projets avec TOGAF utilisant le profil UML, a été expliqué et détaillé dans l’article suivant : 

 

   

Le diagramme TOGAF de contextes de projets utilisant ArchiMate

   

archimate-le-diagramme-de-contextes-de-projets.png

    

Pour rappel et à fin de comparaison, le diagramme TOGAF de contextes de projets utilisant le profil UML

     

togaf-le-diagramme-de-contextes-de-projets.png

  

Conclusion   

Le diagramme de contextes de projets modélise tout ce qui nécessaire à la réalisation d’un projet.

Ce diagramme modélise le périmètre d’un projet faisant partie de la trajectoire de transformation.

Il montre :

  • les acteurs,
  • les flux d’information avec les autres applications internes et les systèmes externes,
  • l’implémentation : des processus métier, règles métier, entités métier, cas d’utilisation, composants applicatifs et services métier.

  

Les ajouts, modifications et suppressions d’entités au sens large doivent figurer sur le modèle.

 

Le modèle sert à l’initialisation des projets et à la gestion de portefeuilles applicatifs.

  

 

Pour plus de précisions sur les “viewpoint” et les éléments de langage ArchiMate, voir l'annexe "Les mémentos d'Archimate" à la fin de l'article suivant :   

  

 

Voir en annexe à la fin de cet article, comment apprendre ArchiMate en comparant une étude de cas TOGAF modélisée avec UML et la même avec ArchiMate. 

 
Rhona Maxwel
@rhona_helena
 

"La conscience est la conséquence du renoncement aux pulsions."

Freud

      

  

Annexe : Apprendre ArchiMate en comparant une étude de cas TOGAF modélisée avec UML et la même avec ArchiMate

 


06/11/2018
0 Poster un commentaire

ArchiMate : le diagramme de bénéfices, comparaison du diagramme UML de TOGAF et celui avec ArchiMate - 36

L’objectif de cet article est la traduction de la modélisation utilisant le profil UML vers le langage ArchiMate concernant le diagramme de bénéfices de la phase E Solutions et opportunités de TOGAF.

En ayant étudié la modélisation TOGAF avec le profil UML, il est facile d’apprendre ArchiMate.

C’est cette approche pédagogique que nous vous proposons.

  

Explications du diagramme de bénéfices avec TOGAF utilisant le profil UML

Le diagramme de bénéfices avec TOGAF utilisant le profil UML, a été expliqué et détaillé dans l’article suivant : 

 

   

Le diagramme TOGAF de bénéfices utilisant ArchiMate

   

archimate-le-diagramme-de-benefices.png

    

Pour rappel et à fin de comparaison, le diagramme TOGAF de bénéfices utilisant le profil UML

     

togaf-le-diagramme-de-benefices.png

  

Conclusion   

Le diagramme de bénéfices modélise les possibilités d’amélioration avec leurs avantages et leurs inconvénients et participe à l'initialisation d'un nouveau cycle ADM (Architecture Development Method) de TOGAF.

 

Ce diagramme modélise les évolutions possibles et se positionne comme une base de travail pour étudier :

  • les apports en terme de valeur pour l’entreprise
  • le niveau de complexité
  • l’estimation de réalisation
  • les risques

Ce modèle participe à l’initialisation d’une nouvelle itération ADM.

 

Une analyse d’impacts sur la précédente itération doit être effectuée.

 

Les changements, les impacts et les objectifs seront répartis en nouveaux projets..

  

 

Pour plus de précisions sur les “viewpoint” et les éléments de langage ArchiMate, voir l'annexe "Les mémentos d'Archimate" à la fin de l'article suivant :   

  

 

Voir en annexe à la fin de cet article, comment apprendre ArchiMate en comparant une étude de cas TOGAF modélisée avec UML et la même avec ArchiMate. 

 
Rhona Maxwel
@rhona_helena
 

"L'homme devrait mettre autant d'ardeur à simplifier sa vie qu'il en met à la compliquer."
Henri Bergson

     

  

Annexe : Apprendre ArchiMate en comparant une étude de cas TOGAF modélisée avec UML et la même avec ArchiMate

 


30/10/2018
0 Poster un commentaire

ArchiMate : le diagramme de matériel informatique en réseau, comparaison du diagramme UML de TOGAF et celui avec ArchiMate - 35

L’objectif de cet article est la traduction de la modélisation utilisant le profil UML vers le langage ArchiMate concernant le diagramme de matériel informatique en réseau de la phase D Architecture technique de TOGAF.

En ayant étudié la modélisation TOGAF avec le profil UML, il est facile d’apprendre ArchiMate.

C’est cette approche pédagogique que nous vous proposons.

  

Explications du diagramme de matériel informatique en réseau avec TOGAF utilisant le profil UML

Le diagramme de matériel informatique en réseau avec TOGAF utilisant le profil UML, a été expliqué et détaillé dans l’article suivant :

 

   

Le diagramme TOGAF de matériel informatique en réseau utilisant ArchiMate

   

archimate-le-diagramme-de-materiel-informatique-en-reseau.png

    

Pour rappel et à fin de comparaison, le diagramme TOGAF de matériel informatique en réseau utilisant le profil UML

     

togaf-le-diagramme-de-materiel-informatique-en-reseau.png

   

ArchiMate Opportunities and Solutions Viewpoint

 

archimate-opportunities-and-solutions-viewpoint.png

 

Conclusion   

Le diagramme de matériel informatique en réseau modélise le déploiement des composants d’application, tous types confondus, dans une architecture technique distribuée.

Ce diagramme constitue une cartographie des infrastructures informatiques hébergeant les composants applicatifs ainsi que les acteurs accédant à ces composants.

   

 

Pour plus de précisions sur les “viewpoint” et les éléments de langage ArchiMate, voir l'annexe "Les mémentos d'Archimate" à la fin de l'article suivant :   

  

 

Voir en annexe à la fin de cet article, comment apprendre ArchiMate en comparant une étude de cas TOGAF modélisée avec UML et la même avec ArchiMate. 

 
Rhona Maxwel
@rhona_helena
 

"L'homme n'est heureux que de vouloir et d'inventer."
Alain

     

  

Annexe : Apprendre ArchiMate en comparant une étude de cas TOGAF modélisée avec UML et la même avec ArchiMate

 


24/10/2018
0 Poster un commentaire