Bonjour Gauthier, et merci pour ton retour.
Depuis l’ équipe produit de LeanIX, il n’existe pas d’ initiative dans ce sens à ce jour.
Bien que la structure simplifiée de C4 soit précieuse pour certaines utilisations, le métamodèle LeanIX offre une fonctionnalité plus adapté pour des analyses complexes et à forte valeur ajoutée comme la gestion du risque technologique.
D‘autre part, bien que la terminologie dans le domaine puisse être flexible, l'utilisation par LeanIX du terme 'Application' pourra mieux s'aligner sur une compréhension plus large pour tous les stakeholders de l’organisation et favorisera l’adoption. Comme toujours, la personnalisation du métamodèle LeanIX est une option pour des besoins spécifiques. Si vous pensez que la notion de “System” est plus parlante pour tous vos stakeholder, et non pas seulement le Staff+ Engineer, elle peut être traduite.
Bonjour @Gauthier ,
Nous sommes également dans cette recherche d’un potentiel rapprochement entre le modèle LeanIX (utilisé en particulier par l’équipe EA) et une structuration à la C4 (utilisé par nos engineering et staff manager).
Pour donner un peu de contexte, nous avons adapté le métamodèle en créant une catégorie “Produit IT” aux capacités métiers pour documenter les périmètres applicatifs à vocation éditeur (nous avons des activités en ce sens).
La catégorie “microservice” est appelée “module/service” chez nous.
A ce stade, j’établis la correspondance suivante :
| Entité C4 | Représentation LeanIX | Commentaires |
|---|
| Software System à vocation éditeur | Capacités métiers / Produit IT | |
| Autre System | Capacités métiers | Les “Applications / Business Application” semble être la proposition standard du méta modèle V4 mais cela ne nous semblait pas satisfaisant |
| Container en gestion par notre entreprise | Application / Application en gestion | Rattaché aux capacités et/ou produits associé(e)s |
| Container associé à un système décrit | Application / Application externe | Rattaché aux capacités associées |
| Autre Container | Application / Module/Service | Pour le moment on utilise ce formalisme car nous n’avons pas la gestion ni une grande connaissance de ces containers. Avec les attributs conditionnels, nous pouvons limiter la profondeur de la documentation |
| Component “fonctionnel” | Application / Module/Service | On a encore du mal à définir ce qu’est un component “fonctionnel”. On tend à s’aligner sur le fait qu’une fonction serverless. Rattaché au container associé en tant qu’enfant. |
| Component “technique” | IT Component | Rattaché aux container et/ou component y recourant. On entend par component “technique” un SDK ou une librairie par exemple |
Preneur d’avis :)
