Conclusions élargies sur un objet métier

Ce texte ci dessous est extrait du blog de ea-is.blogspot.com article concernant l'Anatomie d’un Objet métier.

Conclusions élargies sur un objet métier.

1- Les objets métiers (OM) sont une abstraction de la réalité. La photographie métaphorique doit laisser la place à la modélisation. La modélisation sémantique doit tenir compte de la posture des métiers à leur égard, leurs intérêts et leurs objectifs.
2- Les objets métier sont résumés à l’aide d’une abstraction, nommée « classe d’objet ». Cette classe d’objet doit être typée plus finement. Dans le cas de nos objets métiers, on pourrait par exemple choisir les termes de « Concept », « Entité », ou encore « OM ». C’est une excellente idée d’utiliser un formalisme d’abstraction simple, évolutif, standard et ouvert, comme UML.
3- Le terme « modèle d’objet métier » (MOM) n’est pas un terme très propice, car il peut prêter à confusion, entre un modèle de classe et un modèle d’instance. Les anciens parlaient de « Modèle Conceptuel de Donnée », qui cette fois opposait, le terme de concept et de donnée. Dans notre affaire, « Modèle des Concepts Métier » met tout le monde d’accord.
4- 90% des soi-disant experts en modélisation confondent « Modèle » et représentations graphiques du modèle. Pour ne plus jamais subir ce genre d’amalgame, rappelons gentiment que si un modèle est assimilable à un hyper cube, les vues ou « Diagrammes » en sont les faces de projection. Ainsi, retenons qu’un modèle se conjugue plutôt au singulier alors que les diagrammes sont les vues plurielles du modèle. La confusion a été entretenue pour la raison suivante : Cette sacro-sainte mauvaise habitude de vouloir absolument représenter tous les concepts d’un modèle sur une seule vue. Du coup le modèle était le diagramme. Cette mauvaise habitude persiste encore dans certains outils d’urbanisation qui affirme : « les vues sont le modèle ». Ce type de pratique est néfaste à 2 titres :
-Manque d’agilité de l’outil dans la gouvernance de la donnée: Dans le processus d’acquisition de l’information, des architectes, tout concept n’est pas forcement représentable intelligiblement sur une vue, immédiatement.
-Les éléments du modèle peuvent et doivent le plus souvent être exploité par transformations, générations successives, et ne pas sans tenir à refaire la tapisserie du mur de son bureau.
5- Un modèle n’est jamais complet ou exacte du premier coup. Il est donc important d’itérer sur sa mise à jour et d’automatiser les conséquences de cette itération, que cela occasionne sur le reste du système (c’est un premier principe d’agilité des données en EA)
6- Les objets métiers doivent avoir une définition métier précise, permettant d’être identifié naturellement par leurs bénéficiaires. L’architecte « sémantique » gère la synonymie, et l’homonymie des noms des OM.
7- L’architecte sémantique est l’une des casquettes de l’architecte d’entreprise.
8- Dès la conception, L’architecte « sémantique » doit toujours garder à l’esprit qu’un objet métier deviendra très probablement (du moins on l’espère) une donnée informatique.