Data Model Arborescent

Data Model Arborescent
La conception d’une application web nécessite la collaboration du métier et de l’informatique, deux mondes à part, qui ne parlent pas la même langue. De réunions improductives en ateliers dont il ne sort rien, il est souvent difficile de faire avancer le projet, tans ces deux mondes sont différents. Il existe cependant une méthode permettant de les faire enfin communiquer : le Data Model Arborescent, un concept OWW issu du Data Model classique, qui établit un pont entre l’humain et la machine, entre l’homme métier et l’informaticien.
Vous n’échapperez pas à la transition numérique. L’adaptation de votre entreprise à l’architecture du réseau, n’est pas négociable. Elle est inéluctable. Trop de gains de productivité sont en jeu. D’ailleurs en tant que citoyen et consommateur, vous connaissez aujourd’hui l’impact des applications web dans votre vie de tous les jours : achats, déclaration d’impôts, réservations, … tout se fait en ligne. Même le gouvernement pousse dans cette direction, grâce au projet de e-administration. Dès lors vous devez, vous aussi, proposer à vos clients, et vos employés, les moyens de communiquer avec votre entreprise de façon dématérialisée, c’est à dire au travers d’applications web. Mais ne vous y méprenez pas, c’est une tâche très spéciale, dont l’aspect informatique est seulement le détail le plus simple à traiter. Le plus complexe, et le plus coûteux reste de loin la conception.
Le problème : le passage de l’humain à la machine

Lorsqu’on se lance dans la conception d’une application web, « Il suffit de », « ya qu’à », « c’est évident », « on pourrait aussi », … sont les expressions les plus entendues en réunion. C’est bête à dire mais si l’humain comprend ces expressions, la machine en est incapable. Elle est binaire. Pour elle « c’est évident » égal 1, « il suffit de » retourne un message d’erreur, tout comme « on pourrait ». Bref, si l’humain possède l’intelligence, la machine n’en a aucune.

En fait une machine est capable de bien peu : elle manipule des chiffres et des chaînes de caractères, comme on lui indique de le faire, un point c’est tout. Et qu’il s’agisse des données nécessaires au tableau de bord de la navette spatiale, ou bien à prévenir qu’il faut penser à prendre du pain en rentrant, l’ordinateur ne fait aucune différence. Il est cognitivement agnostique, il ne donne aucune valeur spécifique aux données qu’il manipule, et ne sait pas les hiérarchiser. Il peut le faire, mais dans ce cas vous devez lui expliquer comment : quelle architecture pour cette hiérarchie, quelles règles de classement, quel format des données, … Et vous vous apercevez alors que c’est votre processus métier qu’il vous faut décrire en termes analytiques, avant même de pouvoir demander à la machine de l’intégrer sous forme d’une application.

Mais voilà, l’expérience montre que l’humain a les plus grandes difficultés à décrire son métier de façon analytique, et d’autant plus si on lui demande d’entrer dans les détails. Il y a donc blocage de communication entre l’homme et la machine. Ces deux là ne se comprennent pas naturellement.

La plus grande difficulté d’un projet de transition numérique est donc celle qui consiste à conceptualiser le passage de l’humain à la machine. Ce n’est pas la technologie qui pose problème, car on trouve aujourd’hui des matériels et logiciels informatiques très bon marché qui peuvent à peu près tout faire. C’est bien le décryptage des méthodes humaines pour les rendre réalisables par la machine qui reste l’élément bloquant. C’est là que les projets ralentissent, s’embourbent, se perdent dans les méandres de l’incompréhension et des quiproquos des différents acteurs, menant souvent à l’échec. Comment résoudre ce problème ?

Chacun son métier, mais alors où se rejoindre ?

Souvent le premier réflexe est de tout déléguer à l’informaticien, ce magicien. On lui demande d’abord d’apprendre le métier, car on subodore que connaissant le métier, il saura comment le programmer sur un ordinateur. Quelques « ya qu’à » et « il suffit  de » pour s’en convaincre, et le tour est joué.

Cela est une pure illusion. Les métiers sont complexes et il faut des années de labeur pour parvenir à en maîtriser même seulement certains aspects, avec l’aide de nombreux intervenants d’expérience.

A l’inverse il est tout aussi illusoire de croire que l’homme métier peut devenir un informaticien chevronné, cela nécessite, là encore, beaucoup trop de temps et d’expérience.

Alors que faire pour que les deux communiquent ? C’est à cette question que s’est attelé Open-World-Wide, pour finalement mettre au point une solution universelle : le Data Model Arborescent (CDA). Expliquons en quoi cela consiste.

La solution au problème : Le Data Model Arborescent

A y regarder de plus près, tous les métiers ont une chose en commun : ils manipulent des données. Même les plus éloignés de la technologie. Par exemple un menuisier utilisera pêle-mêle la longueur de ses planches, leur fournisseur, l’essence dont elles sont faites, l’angle à biseauter sur une poutre, l’adresse de sa cliente Mme Michu, toute sa comptabilité, … Aucun métier n’échappe à cette règle : sans données, pas de métier.

L’idée est alors la suivante : il suffit de cartographier ces données et on obtiendra une image fidèle du métier concerné. Mais à vrai dire on se rend très vite compte que, même pour un artisan, le nombre de données est immense. Il faut dès lors les classifier pour les rendre lisibles et compréhensibles. Oui mais comment ?

La réponse à cette question consiste un un second point commun à tous les métiers : toutes les données peuvent être hiérarchisées dans une arborescence. Ici encore, aucun métier n’échappe à cette règle. Peut-être doit-on y voir un symptôme de la façon de fonctionner des cerveaux des êtres humains, mais en tout cas aucun de leurs projets ne déroge à cette règle.

L’entreprise de notre artisan menuisier contient un fichier client, contenant un dossier « Mme Michu », contenant un plan, contenant la mesure de l’angle à biseauter. Elle contient aussi un dossier fournisseur, contenant lui même un dossier sur le producteur de chêne, intégrant son numéro de téléphone. Et ainsi de suite. En fait l’entreprise en question doit être vue comme un objet contenant des objets, qui eux même contiennent d’autres objets, contenant eux-même des objets, etc. Et chacun de ces objet est associé à ses données propres.

Etablir une telle arborescence objet est toujours possible, pour tous les métiers. Ce n’est pas la seule façon de modéliser un métier, mais nous affirmons que cette architecture sera toujours applicable, indépendamment de toute autre méthode.

Nous avons donné le nom de Data Model Arborescent à cette hiérarchie arborescente décrivant les processus métier. Elle présente de nombreux avantages.

Les avantages du Data Model Arborescent

La simplicité : l’ancêtre du DMA est le « modèle de base de donnée relationnelle », qui est enchevêtré, complexe, et finalement illisible par l’homme métier. Même l’informaticien y retrouve difficilement ses petits. Le DMA quant à lui se présente sous une forme lisible et compréhensible pour l’homme métier, car c’est une simple arborescence.

Le référentiel commun : l’homme métier et l’informaticien peuvent chacun lire et comprendre le data model. Chacun pointe exactement sur la donnée à traiter, ainsi que ses dépendances, sans quiproquo, sans incompréhension.

Architecture réseau native : Toutes les technologies réseau sont nativement capable d’intégrer directement de telles arborescences, car elles sont elles mêmes des objets logiciels arborescents. Par exemple les bases de données, dites NoSQL, qu’utilisent Facebook, Tweeter, Google, … , sont simplement des stockages de données sous forme d’arborescence.

Un gage de pérennité : les technologies peuvent passer, l’arborescence du métier évolue à son propre rythme, elle reste toujours pertinente. Elle est un gage immense de stabilité lors des phases de migration d’une technologie à une autre. C’est l’axe autour duquel tout évolue.

La souplesse : une arborescence c’est un arbre, et un arbre est destiné à grandir et se ramifier. Il est prévu pour ça. Une nouvelle branche dotée de nouvelles feuilles peut apparaître sans aucune modification des processus existant.

Le référentiel informatique : le DMA concerne autant le back-end, c’est à dire le côté serveur, que le front-end, ou interface, ces deux domaines d’une application web utilisant pourtant des technologies totalement différentes. Dès lors le travail de fabrication des API, permettant de faire communiquer l’un avec l’autre, est grandement simplifié.

Un investissement durable : une fois votre métier décrit en DMA, ce dernier ne vous sera pas simplement utile pour une application unique, mais pour toutes celles que vous souhaiterez concevoir dans le futur.

Constituer un Data Model Arborescent

Le plus souvent il n’est pas nécessaire de passer en revue l’intégralité du métier, mais simplement la partie utile à concevoir l’application souhaitée. C’est une bonne façon de débuter la structuration d’un DMA, devant à terme décrire l’intégralité d’un métier. On commence simplement par en définir une branche.

Grâce à un système d’interviews itératives des acteurs de l’entreprise, on trace le DMA, tout en synthétisant le besoin sous forme de mockup, c’est à dire de story board. A la question « que doit faire l’application ? », la réponse sera forcément donnée sous forme de différentes pages plus ou moins dynamiques, donc de story board. Et chaque donnée affichée sera référencée dans le DMA.

Cette approche par Data Model Arborescent est la réponse d’OWW au problème du passage de l’humain à la machine. Et elle fonctionne à merveille.

Il n’y a pas longtemps, dans une grande mutuelle française, j’ai passé 4h en réunion pour spécifier une seule page web, d’une seule application, C’était le énième atelier de ce type, métier/informatique. A la fin des 4h, alors que la page semblait impossible à afficher, tant le métier et l’informatique étaient irréconciliables, j’ai proposé une approche DMA, bien que cela ne relevât pas de mes prérogatives sur cette mission. Il nous a alors fallu 5 bonnes minutes pour décrire l’arborescence des données nécessaire à cette page, et 5 autres bonnes minutes pour déterminer comment l’informatique fournirait ces données. En 10′ l’affaire était close. Aucune magie dans cela, mais une simple représentation en arborescence du problème posé, à des cerveaux humains qui eux-même pensent en arborescence. Et tout s’éclaire, le gain étant aussi drastique que 4h aboutissant à une impasse, vs 10′ et le problème est résolu.

OWW vous conseille donc de constituer votre propre Data Model Arborescent, tant il y a de bénéfices à en tirer, et reste bien sûr à votre disposition pour vous y aider, et répondre à toutes vos interrogations sur ce sujet.

 

SUIVEZ-NOUS ! facebook   twitter   linkedin

About the author: Hervé Le Cornec