urbanisation-si

urbanisation-si

Les fondamentaux de la modélisation d'un Système d'Information : le bon usage des modèles

Un modèle est faux par nature !

Il n’est pas conçu pour être vrai et représenter parfaitement la réalité mais pour répondre à un usage. Un modèle n’est ni bon ni mauvais, un modèle est juste adapté ou pas à un usage.

 

fondamentaux-de-la-modelisation-systeme-d-information-bon-usage-des-modeles.gif

  

Un modèle est comparable aux cartes géographiques, il peuvent être déclinés à différentes échelles qui permettront de zoomer sur une partie du domaine traité pour en connaître les détails les plus subtils.

 

Combien de fois ai-je entendu au cours de mes missions, les DBA me dire : « mais il manque des choses dans ton modèle » et combien leur ai-je répondu « mais regarde, tu n’es pas dans la liste des destinataires. C’est un modèle à forte granularité, spécialement conçu pour le comité d’architecture d’entreprise, ne t’inquiète pas ce modèle subira différentes dérivations qui ajouterons les détails qui te permettons de concevoir la base de données. »

 

Un modèle est une représentation d’une réalité matérielle ou immatérielle, un modèle n’est pas cette réalité.

On pourra affiner les modèles en créant de nouveaux modèles de plus en plus détaillés jusqu'à peut être atteindre de manière asymptotique le monde réel sans jamais l'atteindre.

Modéliser est donc l’acte de représenter nos concepts et les objets de notre réalité.

 

Cette réalité pouvant être immatériel et exister uniquement comme construction mentale, par exemple un remboursement de soins d’une mutuelle n’a pas d’existence physique mais est une réalité pour beaucoup de gens, le relevé papier rend concrète et matérielle la réalité du remboursement.

Un modèle est forcément une description limitée et orientée de la réalité.

 

Il est impossible de décrire de manière absolue la réalité à des fins descriptives ou prédictives, sans même parler de l’intérêt d’une telle démarche.

 

Un modèle va décrire la réalité avec un certain filtre, en utilisant certains concepts permettant de classifier la réalité observée.

Par exemple, un processus de liquidation d’une garantie décès d’un contrat de prévoyance sera décrit avec les notions d’événements (dossier client déposé), d’activités (vérifier les pièces, remplir le dossier), de transitions (les conditions sont respectées alors le dossier est transmis au contrôleur).

De manière très simplifié, un modèle décrit toujours une réalité observable ou, encore mieux, mesurable et donc numérique.

La réalité observable peut être décrite en répondant aux questions : « Quoi ? Qui ? Quand ? Où ? Comment ? » ainsi qu’en décrivant les contraintes qui définissent les limites du modèle.

 

La léthargie d’une entreprise dû à la complexité peut être éviter grâce à la modélisation

Les modèles offrent des mécanismes d'abstraction, permettant de raisonner à des niveaux plus macroscopiques, en agrégeant des éléments détaillés, en ne révélant que les parties significatives, ou en généralisant des notions et mécanismes.

 

L'abstraction permet de gérer la complexité, qui est un frein important dans les entreprises.

La complexité cause en effet la léthargie et l’inertie qui empêchent beaucoup d’entreprises d'être réactives.

 

L'abstraction est rendue nécessaire pour des besoins primaires de gestion, de classification, et des besoins plus sophistiqués de mutualisation, de rapprochement, de rationalisation.

Pour des raisons de pédagogie, l'abstraction est également utilisée pour adapter les niveaux de détails présentés selon les interlocuteurs correspondant à points de vue différents, dédiés à des parties prenantes spécifiques.

Le niveau d'abstraction doit être défini en détail selon les objectifs et les parties prenantes ciblés par le modèle.

 

Les modèles comme principal support de communication au sein de l’entreprise

« Nous ne raisonnons que sur des modèles » Paul Valéry

 

En formalisant les connaissances, ils permettent de comprendre et d'éclaircir un problème.

Avec les modèles, les différents constituants d'un domaine d'étude sont représentés, différents types de liaisons permettent de les positionner, et ces constituants sont valorisés en leur affectant des propriétés.

 

Les modèles constituent alors un support à la réflexion, et sont enrichis par les résultats de celle-ci.

En matérialisant la compréhension d'un problème, un modèle décrira à la fois le contexte, le domaine ciblé, et reflétera l'intention, le projet de construction qui est imaginé.

La communication est une nécessité première au sein des entreprises, pour laquelle les modèles offrent un support important.

 

Les entreprises utilisent les modèles pour représenter leur organisation.

Ceux-ci servent d'une part à cartographier les éléments de l'entreprise, comme les rôles dans l'entreprise, les sites, les processus métier, les ressources matérielles, les applications, et d'autre part à détailler ses constituants et son fonctionnement comme le déroulement d'un processus métier. Cartographier consiste à répertorier, classifier et positionner l'existant, pour partager sa connaissance et permettre à chacun de situer les constituants d'une carte.

 

Les modèles facilitent également le dialogue entre des expertises différentes dans l'entreprise, comme typiquement entre MOA et MOE, ou encore entre utilisateurs et analystes métier.

 

Ainsi, les modèles peuvent servir à représenter les besoins métier des utilisateurs, puis ils sont ensuite codifiés de manière précise pour préparer le travail des architectes et concepteurs.

 

Les modèles servent ainsi à partager une connaissance, et à collaborer à sa construction.

Un travail collaboratif peut en effet s'appliquer sur les modèles qui sont enrichis par la contribution de chacun tout en étant partagés.

La modélisation des connaissances sur le métier, sur l'organisation, sur les processus et sur le SI permet de constituer un patrimoine pour l'entreprise pouvant être réutilisé et exploité de multiples façons.

 

Simuler et vérifier qu’un système fonctionne

Voir la série d’articles que j’avais consacrée aux techniques de vérification et simulation des modèles :

 

 

Très utilisés dans toutes sortes de projets d'ingénierie, les modèles sont également exploités pour prévoir et simuler le comportement du système à réaliser, mais aussi les travaux de construction du système.

 

Le modèle, en fournissant une vision d'ensemble, permet plus facilement d'appliquer des changements selon une stratégie particulière.

 

On peut aussi tester des hypothèses, imaginer des variantes : ces activités ne peuvent, en effet, pas être envisageables lors de la réalisation effective du projet, du fait de leur lourde charge en coûts et délais.

 

Par ailleurs, les modèles sont fréquemment utilisés pour identifier des lots de travail au sein d'un projet, afin de déléguer et suivre ces travaux.

 

Dériver les modèles pour générer des productions informatique

L'informatique utilise les modèles aussi pour générer automatiquement des productions informatiques plus détaillées : par exemple du code, des schémas de base de données ou des documents.

 

Lors de leur évolution au cours du temps, depuis la vision vers la réalisation, les modèles deviennent de plus en plus précis, formels, pour guider voire automatiser le travail des architectes, concepteurs puis développeurs.

 

L'inconvénient de cette approche est que dès lors qu'un modèle est suffisamment précis pour être exécutable, il devient beaucoup moins utile pour comprendre et raisonner sur les systèmes complexes.

 

L'architecture d'entreprise est davantage centrée sur la spécification et la conception que sur la construction.

Elle requiert des modèles moins précis et formels.

 

Utiliser les normes UML, BPMN, SysML, BMM, DMN, SOAML, …

L'intérêt des modèles est décuplé par leur standardisation : celle-ci assure une notation unique, connue de tous, partagée entre tous les pays et pour tous les domaines connexes de l'architecture d'entreprise (organisation, processus métier, données, applications) et de l'informatique ; elle fournit une sémantique — c'est-à-dire une définition de l'ensemble de ses termes, mécanismes et constructions — formellement élaborée, limitant ainsi les interprétations que l'on peut avoir d'un modèle ; elle garantit un marché à un grand nombre d'outils associés (modélisation, génération...) ; elle permet une interopérabilité entre ateliers de modélisation évitant ainsi d'être prisonnier d'un atelier particulier.

 

Les modèles réalisés pour l'entreprise ont alors une valeur patrimoniale augmentée par le fait qu'ils sont exploitables par un très grand nombre de personnes et d'outils.

 

Mais attention ces normes formalisent des représentations mais ne précisent pas de méthode d’utilisation.

Je me souviens lors de recrutement, des personnes interrogées sur leur CV, qui me disaient bien connaître la « méthode UML »

 

Cependant, les modèles tels que UML et BPMN sont une boîte à outils très vaste.

Il revient alors à chaque organisation de définir ses conventions, quelles parties de ces modèles sont utilisées et à quelles fins, quelles extensions sont apportées.

 

On peut utiliser dans quelques cas des modèles informels qui n'obéissent pas à un formalisme rigoureux.

Ce sont souvent des graphiques libres, des supports aux idées, des moyens de communication spontanés.

Ils sont naturellement utilisés lors de réunions de travail et sont des facilitateurs de communication spontanée.

Dans les phases initiales d'analyse, lorsque les données du problème ne sont pas clairement établies et qu'il faut bâtir un consensus pour cadrer le domaine d'intervention et les travaux à effectuer, ou lorsqu'il faut communiquer avec des interlocuteurs non avertis des modèles utilisés, les modèles informels peuvent être utilisés.

 

L’outil mindmap en est un bon exemple.

Une Mind Map, encore appelée topogramme, schéma heuristique ou carte mentale, est un diagramme utilisé pour voir, classifier et organiser des concepts, ainsi que pour générer de nouvelles idées.

Elle est utilisée pour connecter des mots, des idées et des concepts à une idée ou un concept central.

Voir les articles consacrés à ce sujet :

 

 

 

 

Ou bien encore le diagramme d’Ishikawa (plus connu sous le nom de diagramme d’arrêtes de poisson ou encore diagramme d’objectifs/sous-objectifs) qui consiste à identifier l’objectif final d’un processus métier puis les sous-objectifs permettant de l’atteindre et ainsi de suite de manière récursive.

 

 

En phase A (vision), ces modèles informels peuvent par exemple être utilisés pour produire des diagrammes de solution conceptuelle ou des diagrammes de chaîne de valeur.

Ils serviront alors de base à la construction de modèles « formels » plus précis et gérés par des ateliers de modélisation.


Par contre, lorsque l'on progresse vers la solution technique, les modèles doivent être plus précis, et fournir un grand niveau de détail sur le fonctionnement de la solution.

On aboutit ainsi à des modèles plus formels, décrivant en détail la structure des données, ou la logique d'enchaînement des activités dans un processus.

On s'adresse ici à des interlocuteurs plus avertis, ce qui autorise l'usage de modèles plus techniques.

Les phases d'élaboration de l'ADM exploiteront ainsi davantage les modèles formels.

 

La gouvernance des modèles

Le modèle n'est qu'un constituant au sein de TOGAF, le point majeur étant le cycle ADM.

L'ADM fournit les processus et activités qui produisent et consomment les modèles, et qui motivent leurs évolutions dans le temps pour des objectifs déterminés.

Le modèle est un outil qui doit être ciblé sur les usages pertinents dans le contexte de l'entreprise.

Les limitations des modèles (incomplétude, difficulté de mise à jour ) nécessitent un calibrage et une gouvernance adaptée.

 

Par ailleurs, les modèles ne fournissent pas les informations de contexte nécessaires à leur bonne compréhension :

 

  • Pourquoi ce modèle est-il élaboré ?
  • Quel problème veut-on traiter ?
  • Comment sera-t-il exploité ?

 

La gouvernance doit intégrer des politiques et des règles concernant la modélisation comme la gestion du cycle de vie d’un modèle,  mettre en place des conventions sur les méta informations d’un modèle (son propriétaire, les droits d’un utilisateur, le but recherché, les destinataires, le versionning, …).

 

Leurs spécialisations à travers les différents artefacts TOGAF de nature « diagramme », et leur structuration en point de vue permettront de résoudre ce dernier point : pour chaque utilisation de modèle dans un artefact, TOGAF et le point de vue affecté nous indiquent quelles grandes préoccupations sont ciblées, et à quels participants s'adressent les modèles.

 

TOGAF et la modélisation

Selon TOGAF, un modèle est une représentation d'un sujet particulier.

Le modèle fournit cette représentation sur une échelle réduite, d'une manière simplifiée ou plus abstraite, relative au sujet concerné.

Dans le contexte de l'architecture d'entreprise, le sujet est l'entreprise ou certaines de ses parties.

La finalité du modèle est l'élaboration de vues qui adressent les préoccupations des parties prenantes : leurs points de vue sur l'entreprise.

 

Conclusion

Les normes UML, BPMN, SysML, BMM, DMN, SOAML, … sont des boites à outils, des notations, mais pas des méthodes.

TOGAF recommande l'usage de UML et BPMN.

Cependant, TOGAF a son propre métamodèle.

L’architecte qui doit modéliser doit au préalable définir la manière d'utiliser ces normes pour TOGAF, et comment mettre en correspondance les concepts de ces normes et les concepts TOGAF.

 

L'abstraction permet de gérer la complexité, qui est un frein important dans les entreprises.

La complexité cause en effet la léthargie et l’inertie qui empêchent beaucoup d’entreprises d'être réactives.

Pour mettre en œuvre la réutilisabilité, l’évolutivité, la flexibilité, la maintenabilité, la capacité d’innovation, une entreprise est obligée de pratiquer la modélisation de son fonctionnement.

  

Rhona Maxwel

@rhona_helena

 

"Tous les modèles sont faux, certains sont utiles."

G. Box

 

 

Articles conseillés :

 

UML

 

SysML

 

BPMN

 

DMN

 

 

BMM

 

Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 2ème partie - Processus métiers - Profil UML Eriksson Penker



27/02/2018
0 Poster un commentaire

A découvrir aussi


Inscrivez-vous au blog

Soyez prévenu par email des prochaines mises à jour

Rejoignez les 203 autres membres