Skip to main content

Bonjour la communauté !!

En discutant avec nos Staff+ Engineers et en lisant plusieurs articles dans la presse, je vois arriver un alignement de vocabulaire autour de Systems, containers, composants.

C’est par exemple illustré dans cet article :

https://nikolaschou.medium.com/a-new-software-architecture-metamodel-inspired-by-c4-agile-and-togaf-b3f21ab9848

Et également décrit dans le C4 Model : 

https://c4model.com/abstractions

 

Avez-vous aligné votre metamodel vers ces notions, si oui comment, et sinon pourquoi ? 

@LeanIX Team :  cette nomenclature étant de plus en plus utilisée par les staff+, notamment dans un contexte d’organisation produit et d’agilité, comment prenez-vous en compte cela ? Allez-vous vers une modification du metamodel. ?

merci d’avance pour vos retours !!

 

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


Reply