Quelques réflexions supplémentaires qui font suite au long article où j’avais expliqué l’intérêt qu’il y avait à modéliser vos architectes. Il y aura quelques répétitions, mais je voudrais ici aller un cran plus loin, en présentant l’intérêt à baser toute la documentation architecture sur un modèle. J’appelle cela le “Model-Based Architecture Documentation” MBAD donc, en partie pour faire écho à MBSE (Model-Based Systems Engineering) et en partie pour faire des jeux de mots autour de Michaël Jackson.

Je le redis, le modèle est une base de données. Le schéma (ou la vue, les 2 termes sont ici équivalents) est une requête sur cette base de données. Le fait de modéliser votre documentation architecture (DA dans la suite de l’article) va structurer l’information tout comme une base de données est une structure de stockage beaucoup plus formalisée qu’un tableur.

L’effort de modélisation (car il y a un effort à fournir ne nous le cachons pas) va permettre ensuite de :

• requêter cette documentation
• valider les données
• garantir la cohérence des informations et de leurs mises-à-jour.
• éviter de laisser les marges d’interprétation et de flou induites par une documentation purement rédigée. Une prestation qui produit un livrables sous forme de modèle est bien plus facile à valider que s’il s’agit de documents de plusieurs dizaines de pages.

Je suis convaincu que pour la DA, il faut vraiment abandonner le paradigme “papier” bêtement traduit en multiples fichiers Word (ou, si les schémas sont modélisés, ils sont conservés sous leur forme la moins riche, une copie d’écran dans le document). Le recul de quelques décennies est maintenant suffisant pour voir que cela ne fonctionne quand même pas très bien non ?

La difficulté est qu’il n’y a pas de standard de ce qu’il faut modéliser (et qu’il ne faudrait pas se retrouver à TOUT modéliser) mais je ne suis même pas convaincu qu’un tel standard soit souhaitable. Je préconise qu’au sein de chaque entreprise/organisation, de prendre pour base l’existant de la DA et, par itération, de modéliser progressivement ce contenu. Cette démarche progressive doit se faire en se demandant à chaque étape, si chaque information a réellement sa place dans la DA et si ce n’est pas le cas de l’externaliser en gardant sa forme non structurée.

Je ne peux pas lister tout ce qui serait à modéliser, cela dépend du contexte de chaque organisation, je voudrais juste illustrer par un exemple concret, très orienté SI qui doit se rencontrer dans à peu près toutes les entreprises.

Ensuite, prenez comme base les sollicitations qui vous parviennent, celles qui sont les plus fréquentes ou les plus ardues à traiter, et interrogez-vous si un effort raisonnable de modélisation permettrait de mieux y répondre (ou d’y répondre tout court).

Dans mon cas, on me demandait régulièrement si le cadre technique du SI servait à quelque chose et s’il était respecté. Je n’ai jamais pu y répondre autrement qu’au feeling mais voilà comment je procéderais dans une approche MBAD

D’abord je modéliserais les grands principes (principles) et règles (requirements) de ce cadre technique du SI :

Puis pour chaque solution technique, je dois indiquer si ces règles sont ou non respectées :

L’inconvénient de cette approche est qu’elle créé une ambiguité : l’absence de relation entre A et R03 est-elle un oubli ou volontaire ? Essayons de faire plus explicite. Archimate n’a pas de relation “négative”, j’utilise ici une convention en indiquant [!] pour montrer que la relation signifie “n’est pas réalisée”

C’est mieux mais si on a 150 prérequis, le schéma risque d’être un peu long et chargé. On peut ainsi proposer de factoriser le fait que “tous les prérequis sont satisfaits sauf R03” en indiquant la relation entre A et le principe ‘Respecter le référentiel technique’

C’est une illustration, inutile de dire que cet effort de modélisation doit être mené sur le long-terme pour documenter ainsi tout un SI.

On peut aussi imaginer d’autres questions auxquelles un modèle peut répondre, voici quelques exemples issus de mon expérience personnelle :

• Est-ce que tous mes flux inter-applicatifs utilisent un protocole sécurisé ?
• Quelles solutions de mon SI embarquent une mécanique d’audit-trail ?
• Quelles chaines applicatives ont mis en place leur propre gestion de logs ?
• Chez quel fournisseur SaaS ai-je des données de niveau restreint ?
• Quelles applications prévues par les architectes d’entreprise n’ont pas été encore implémentées ?

---