Détaillez les 4 couches d'une architecture
J’ai une anecdote à vous raconter : quand j’ai été exposé la première fois à une méthode d’architecture très structurée, j’ai vite pensé qu’il me serait impossible de l’appliquer à tous les projets, tant elle était lourde de prérequis et d’éléments à capturer. Quand je me suis ouvert à mon coach de l’époque, il m’a dit une chose que je retiendrai toujours : « La méthode, c’est tout le temps ».
Derrière cette position univoque, le message était que peu importe la taille de l’étude, a minima les étapes devaient être respectées afin de pouvoir considérer un système dans son ensemble.
Je vous invite donc à faire de cette phrase vôtre maxime, et de toujours prendre le temps de structurer votre réflexion selon les quatre axes décrits par la suite.
A noter, la méthode que je vous propose est le fruit de mon expérience et de mon application de nombreuses méthodes, en particulier celles utilisées lors de mes passages chez Solucom et IBM.
Merci à mes différents coachs et aux auteurs de ces méthodes sans qui ma vision de l’architecture serait bien pauvre !
Qu'est ce que la couche fonctionnelle ?
Sans une définition claire de ces points, impossible de se poser les bonnes questions par la suite ! Or, nous avons vu dans le chapitre précédent que le questionnement est tout simplement essentiel. Il faudra aussi prendre en compte les ambitions du système dans le temps (on commence avec 10 utilisateurs, mais la cible est d’en servir 10 000) et dans l’entreprise (pour l’instant on gère uniquement la paye, mais à terme on veut pouvoir supporter toutes les fonctions RH).
C’est donc de la responsabilité de l’architecte de prendre du recul, de freiner ses instincts pour faire l’effort de comprendre la Big Picture.
Quatre axes principaux permettent de détailler l’aspect métier : les utilisateurs, les données utilisées, les traitements réalisés et les interfaces avec les autres applications.
Afin de capturer ces informations, vous allez devoir identifier un représentant des métiers ou interagir directement avec eux. Parfois, un architecte fonctionnel (dont le rôle est de faire le lien entre le métier et l’IT) peut réaliser ce travail à votre place.
Identifiez les utilisateurs du système
La première étape de l’analyse fonctionnelle est d’identifier qui va utiliser le système que l’on est en train de définir : des employés de l’entreprise (gestion des habilitations) ? Des partenaires ? Des clients depuis internet (sécurisation des accès, disponibilité de l’application) ? Où sont-ils situés (gestion des fuseaux horaires) ?
La volumétrie est très importante également : combien vont-ils être au total ? En même temps ? Y a-t-il des populations « clés » devant être prise en compte en particulier ? Qui va faire de la consultation uniquement ?
Par exemple, j’ai eu l’occasion de travailler sur une application mondiale de saisie des temps de travail. La localisation précise des utilisateurs, notamment dans des pays mal desservis par internet (Australie, Chine…) nous a permis d’anticiper une architecture décentralisée au plus près de chaque plaque géographique. Sans cette analyse préliminaire, nous aurions pu décider de centraliser et de s’exposer à de fortes problématiques de performances.
Analysez les données qui sont manipulées par le système
Une fois les utilisateurs bien identifiés, on peut commencer à s'intéresser aux données qui sont manipulées : D’où viennent-elles ? Quelle est leur sensibilité (confidentialité) ? Sur quels référentiels s’appuient-elles ? Quel est leur cycle de vie : qui les produit, qui les transforme, qui les consomme ? Quel est leur format ? Quel est leur niveau de qualité ?
Selon la complexité du système considéré, la partie donnée peut revêtir un cadre plus ou moins important : en particulier, si on traite des problématiques référentielles :
Si on considère une application traitant l’inventaire magasin de boîtes de petits pois (leur nombre, leur prix, leur emplacement en rayon) qui doit s’interfacer avec l’application gérant l'entrepôt, on doit particulièrement s’assurer que la notion de « boîte de petit pois » est la même partout. Plus d’une fois, on se rendra compte que côté entrepôt, on gère seulement des palettes de boîtes et qu’un traitement est nécessaire pour passer d’un système à un autre.
Définissez les traitements à effectuer
Maintenant que nous savons qui va utiliser notre système et les données qui sont manipulées, nous pouvons nous intéresser au coeur : qu’est-ce qu’on fait de tout ça ? :)
Ici, il est question de lister les grands blocs fonctionnels par type d’usage : gestion d’inventaire, authentification des utilisateurs, production de rapports... Idéalement, c’est ici qu’on va associer des notions de performances : telle fonction doit répondre en moins de 3 secondes, tel rapport doit être produit chaque nuit, etc.
Dans la plupart des projets que je traite, personne n’est capable de fournir ces indications de manière explicite et immédiate. C’est souvent une fois le projet déployé qu’il faut revenir à cette étape et détailler, en s’appuyant sur les premiers retours utilisateurs.
En première instance, un simple gros bloc peut tout à fait faire l’affaire, permettant de représenter la cible ou la destination des échanges avec les autres applications.
Identifiez les interfaces par lesquelles transitent les données
Dernier pan à analyser, les échanges entre les systèmes doivent être caractérisés par 2 éléments : la donnée portée et surtout le sens de transfert de la donnée.
On ne parle pas ici de qui initie quoi techniquement (on l'aborde dans la couche logique) mais bien des applications sources et cibles. Encore une fois, comprendre les flux vous permet de vous interroger sur le fonctionnement global du système. Avec du bon sens, cela vous permettra d’identifier les problématiques structurelles (interconnexion, volumétries... ) et d’anticiper les problématiques techniques. Une bonne façon de bien identifier les interfaces et de vous demander qui est le producteur de la donnée et qui sont ses consommateurs.
Représentez vos besoins fonctionnels
Vous avez bien entendu déjà eu le réflexe, ayant lu le chapitre précédent, de commencer à vous représenter, même mentalement, les différents éléments capturés. Non ? :)
Je vous fournis dans le cadre de ce cours des exemples de graphiques représentant des plans fonctionnels (visibles en vidéo). Le plus important n’est pas que vous repreniez ce formalisme tel quel (sans compter que cela justifierait un cours à part ! ) mais que cela vous inspire et facilite la représentation.
L’ensemble de ces informations constitue les besoins fonctionnels, qui doivent être impérativement documentés. Ces besoins vont nécessairement évoluer dans le temps. Ce n’est pas un problème et ne rend pas caduque l’analyse. Il faudra simplement la compléter ou la refaire en temps voulu.
Des besoins qui évoluent de façon trop drastique sont en général le signe d’un projet dont le but n’est pas clair et qui risque donc fortement d’échouer. Une discussion franche avec le chef de projet ou le product owner s’impose donc pour prendre du recul et identifier les aspects structurants.
