Architecture système
Inititation
Principe généraliste
Un architecte, c’est avant tout le dépositaire d’une méthode et d’une vision.
- La méthode permet d’analyser un système selon tous ses axes et surtout de poser les bonnes questions.
- La vision est le fruit d’une réflexion en commun entre les experts des différents composants et l’architecte. Elle constitue la façon optimale d’organiser les composants entre eux afin d’en obtenir la meilleure efficacité globale : c’est l’architecture cible.
On part toujours d'un besoin, on pose des questions et on mène une étude.
Caractéristiques d'une bonne architecture
Elle répond à plusieurs caractéristiques:
- La sécurité : Elle s'appuie sur la disponibilité, l'intégrité, la confidentialité, la traçabilité (DICT) ; ainsi qu'une perte de données maximale admissible.
- L'élasticité (scalabilité) : le système doit pouvoir répondre à des contraintes changeantes. On parle d'élasticité verticale quand on rajoute des ressources (RAM, CPU, etc) et horizontale quand on rajoute des nouveaux éléments (serveurs web, etc).
- Le couplage faible : le couplage est la nature de l'adhérence qu'ont deux systèmes entre eux. Une architecture moderne et bien pensée a une adhérence faible avec ses interfaces externes et internes. L'idée est que si deux services ont un couplage faible : un changement de l'un n'entraînera pas tellement de changements sur l'autre. C'est l'un des buts de l'approche micro-services, par ex. Autre exemple : mettre le nom du PDG devant sa place de parking est un couplage fort, mettre sa fonction (PDG) est un couplage faible qui permet de changer le PDG sans changer la plaque...
- La simplicité : un système simple est compréhensible, et donc plus stable dans la durée.
Représentation de l'architecture
[On nous explique qu'il faut faire des schémas d'architecture, waouh] Que représenter ? Un Si vu sous l'angle de l'architecture technique peut se décomposer en 4 plans :
- Fonctionnel : représente l'aspect métier, que fait l'application et la nature des données qu'elle échange avec le reste du monde
- Le plan applicatif : les flux (protocole, fréquence, sens), les stocks (partage de donnée...), les middlewares (base de données, serveur java…) et les frameworks utilisés (.NET, Java...)
- Le plan infrastructure permet de décrire les choix techniques (serveurs choisis, connexions réseau, etc)
- La couche opérationnelle décrit la gestion du système : mécanismes de sauvegarde, de supervision, de métrologie, etc
Description des 4 couches
Couche fonctionnelle
Quel que soit le projet, la méthode devrait toujours être appliquée.
Donc, la couche fonctionnelle ? Elle traite de tout ce que fait l'application : les données manipulées, et comment elle s'inscrit dans son écosystème applicatif. On part toujours d'un besoin et on mène une étude : le questionnement des besoins est essentiel. Il faut aussi voir les ambitions du système dans le temps (combien d'utilisateurs au final ?) et dans l'organisation (on peut commencer par ne gérer que la paye, et finir avec un soft pour toute la RH). Il faut éviter de se jeter sur la résolution de problème sans faire d'étude fonctionnelle : plus on évite l’analyse fonctionnelle, plus le système défini risque d’être inadapté au besoins réels des utilisateurs. Il faut réussir à prendre du recul pour voir le tableau global. L'analyse fonctionnelle étudie quatre aspects :
- Les utilisateurs
- Les données
- Les traitements
- Les interfaces applicatives
Identifier les utilisateurs
On commence par identifier simplement les utilisateurs. As-t'on une gestion des habilitations ? Est-ce que des partenaires vont intervenir ? Aura-t'on des clients depuis le net ? Dans quels fuseaux horaires ? La volumétrie est très importante à évaluer aussi. Combien au total, en même temps ? Y'a-t'il des populations clefs à prendre en compte ? Des gens en lecture seule ? En gros, on s'intéresse à l'usage.
Analyser les données
Il s'agit d'analyser les données qui seront traité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é ? Ces informations sont importantes en terme de sécurité, mais aussi en terme de référentiel de données.
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.
Les traitements
On sait qui utilise le système et quelles sont les données, alors maintenant, on en fait quoi ? 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, 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.
Identifier les interfaces
Qui produit la donnée, qui sont les consommateurs ? Les échanges entre les systèmes doivent être caractérisés par 2 éléments :
- La donnée portée
- Le sens de transfert
On ne se demande pas qui initie quoi (ça c'est la couche logique), mais quelles sont applications source et cible. Comprendre les flux permet de s'interroger sur le fonctionnement global. Cela permet aussi d'identifier les problématiques structurelles (connexions, volumétries...) et d'anticiper des problèmes techniques.