Architecture système - Historique des versions

Justine le 22 juin 2022 à 11:38

2022-06-22T11:38:52Z

← Version précédente		Version du 22 juin 2022 à 11:38
Ligne 1 :		Ligne 1 :
			[[Category:linux]]
	https://openclassrooms.com/fr/courses/1372996-concevez-larchitecture-dun-systeme/5670251-decouvrez-le-metier-darchitecte-systeme		https://openclassrooms.com/fr/courses/1372996-concevez-larchitecture-dun-systeme/5670251-decouvrez-le-metier-darchitecte-systeme

Justine le 1 mars 2021 à 14:21

2021-03-01T14:21:58Z

← Version précédente		Version du 1 mars 2021 à 14:21
Ligne 207 :		Ligne 207 :
	=== Besoins non fonctionnels ===		=== Besoins non fonctionnels ===
	Il s'agit des contraintes techniques : performances, dispos, langages ou infras particulières, etc. L'exhaustivité et le partage de ces besoins non fonctionnels donne de la valeur à l'archi. Ces éléments doivent être présentés et discutés avec les parties prenantes.		Il s'agit des contraintes techniques : performances, dispos, langages ou infras particulières, etc. L'exhaustivité et le partage de ces besoins non fonctionnels donne de la valeur à l'archi. Ces éléments doivent être présentés et discutés avec les parties prenantes.

	[[Fichier:Besoins nonfonc.png\|sans_cadre]]		[[Fichier:Besoins nonfonc.png\|sans_cadre]]

	=== Représentation fonctionnelle ===		=== Représentation fonctionnelle ===
	Il s'agit ici de faire un schéma fonctionnel de notre système, comme décrit plus tôt. On va se demander : Quel message je veux faire passer ? Mettre l'accent sur les flux ? Les stocks ? Les blocs de traitement ? Classiquement, on va suivre le parcours de l'utilisateur dans le système.		Il s'agit ici de faire un schéma fonctionnel de notre système, comme décrit plus tôt. On va se demander : Quel message je veux faire passer ? Mettre l'accent sur les flux ? Les stocks ? Les blocs de traitement ? Classiquement, on va suivre le parcours de l'utilisateur dans le système.

	[[Fichier:Schem fonc.png\|sans_cadre]]		[[Fichier:Schem fonc.png\|sans_cadre]]

	==== Environnements et dimensionnements associés ====		==== Environnements et dimensionnements associés ====
	Une fois l'analyse fonctionnelle faite, on va décliner chacune des archis applicatives et infras en fonction des environnements, soit les briques, ayant un usage dédié durant le cycle projet (test, formation, intégration, dev, prod...). On va donc ici lister ces briques avec quelques caractéristiques : nom et localisation, liste des services utilisés (cloud, serveur, bdd...), zones réseau, espaces de stockage (taille / nature), CPUs, etc : il faut avant tout se demander quelles données seront utiles à consigner.		Une fois l'analyse fonctionnelle faite, on va décliner chacune des archis applicatives et infras en fonction des environnements, soit les briques, ayant un usage dédié durant le cycle projet (test, formation, intégration, dev, prod...). On va donc ici lister ces briques avec quelques caractéristiques : nom et localisation, liste des services utilisés (cloud, serveur, bdd...), zones réseau, espaces de stockage (taille / nature), CPUs, etc : il faut avant tout se demander quelles données seront utiles à consigner.

	[[Fichier:Listes envs.png\|sans_cadre]]		[[Fichier:Listes envs.png\|sans_cadre]]

Ligne 223 :		Ligne 226 :

	La localisation de chacun des éléments est primordiale sur ce type de schéma (côté utilisateur, côté cloud, côté virtu, etc). Il faut aussi penser à faire apparaître le nom des infras sous-jacentes (noms des serveurs) pour faire le lien avec les schémas d'infra.		La localisation de chacun des éléments est primordiale sur ce type de schéma (côté utilisateur, côté cloud, côté virtu, etc). Il faut aussi penser à faire apparaître le nom des infras sous-jacentes (noms des serveurs) pour faire le lien avec les schémas d'infra.

	[[Fichier:Schem appl.png\|sans_cadre]]		[[Fichier:Schem appl.png\|sans_cadre]]

	==== Matrice de flux ====		==== Matrice de flux ====
	Extraite de l'analyse applicative. Liste des sources, destinations, protocoles et zones réseau pour chacun des flux applicatifs. On fait en général apparaître ici les échanges nécéssitant une approbation ou une ouverture de firewall, il faut faire apparaître les points d'attention : flux volumineux ou sensibles (latence...).		Extraite de l'analyse applicative. Liste des sources, destinations, protocoles et zones réseau pour chacun des flux applicatifs. On fait en général apparaître ici les échanges nécéssitant une approbation ou une ouverture de firewall, il faut faire apparaître les points d'attention : flux volumineux ou sensibles (latence...).

	[[Fichier:Matr flux.png\|sans_cadre]]		[[Fichier:Matr flux.png\|sans_cadre]]

Ligne 232 :		Ligne 237 :
	Dans la lignée de nos schémas précédents, on va visualiser d'un coup d'oeil les ressources utilisées. On recommande d'afficher les configurations matérielles (OS, CPU, RAM, stockage) et les caractéristiques de dispo et résilience (réplication, clustering...). On doit faire le lien avec la partie applicative, à travers des identifiants communs (nom du serveur, rappel de sa fonction).		Dans la lignée de nos schémas précédents, on va visualiser d'un coup d'oeil les ressources utilisées. On recommande d'afficher les configurations matérielles (OS, CPU, RAM, stockage) et les caractéristiques de dispo et résilience (réplication, clustering...). On doit faire le lien avec la partie applicative, à travers des identifiants communs (nom du serveur, rappel de sa fonction).
	Inutile de se perdre en parlant des services communs comme le réseau ou le stockage : autant renvoyer vers les DATs de ces éléments. On va seulement parler des détails particuliers comme un double attachement réseau, par exemple.		Inutile de se perdre en parlant des services communs comme le réseau ou le stockage : autant renvoyer vers les DATs de ces éléments. On va seulement parler des détails particuliers comme un double attachement réseau, par exemple.

	[[Fichier:Schem tech.png\|sans_cadre]]		[[Fichier:Schem tech.png\|sans_cadre]]

	=== Représentation opérationnelle ===		=== Représentation opérationnelle ===
	On va montrer comment le système utilise les services d'exploitation. Comme pour l'infra, la plupart sont mutualisés. On va mettre en avant comment ils sont utilisés pour répondre aux contraintes. Par exemple, on mettra en avant une sauvegarde externalisée pour répondre aux besoins de reprise d'activité.		On va montrer comment le système utilise les services d'exploitation. Comme pour l'infra, la plupart sont mutualisés. On va mettre en avant comment ils sont utilisés pour répondre aux contraintes. Par exemple, on mettra en avant une sauvegarde externalisée pour répondre aux besoins de reprise d'activité.

	[[Fichier:Schem ope.png\|sans_cadre]]		[[Fichier:Schem ope.png\|sans_cadre]]

Ligne 250 :		Ligne 257 :
	* Alternatives considérées		* Alternatives considérées
	* Justification pour expliquer la décision et le choix		* Justification pour expliquer la décision et le choix

	[[Fichier:Decision arch.png\|sans_cadre]]		[[Fichier:Decision arch.png\|sans_cadre]]

	=== Plan projet ===		=== Plan projet ===
	On va pouvoir faire un plan projet, étant bien placé quant à la mise en oeuvre du projet en question. On va lister les tâches et les personnes, en utilisant la méthode RACI.		On va pouvoir faire un plan projet, étant bien placé quant à la mise en oeuvre du projet en question. On va lister les tâches et les personnes, en utilisant la méthode RACI.

	[[Fichier:Plan prj.png\|sans_cadre]]		[[Fichier:Plan prj.png\|sans_cadre]]

	=== Calendrier de réalisation ===		=== Calendrier de réalisation ===
	À partir du plan projet, on peut faire un bon vieux GANTT !		À partir du plan projet, on peut faire un bon vieux GANTT !

	[[Fichier:Gantt.png\|sans_cadre]]		[[Fichier:Gantt.png\|sans_cadre]]

	=== Risques ===		=== Risques ===
	On peut faire un peu d'analyse de risques à travers les étapes d'analyse, comme par ex. une sensibilité des performances en fonction du nombre d'utilisateurs. On doit pour chaque risque identifier l'impact et la probabilité, ainsi qu'un éventuel moyen de mitigation.		On peut faire un peu d'analyse de risques à travers les étapes d'analyse, comme par ex. une sensibilité des performances en fonction du nombre d'utilisateurs. On doit pour chaque risque identifier l'impact et la probabilité, ainsi qu'un éventuel moyen de mitigation.

	[[Fichier:Risques.png\|sans_cadre]]		[[Fichier:Risques.png\|sans_cadre]]

	=== RACI opérations ===		=== RACI opérations ===
			Comme pour le projet, on doit faire une matrice RACI des opérations, pour savoir qui va exploiter les différents composants, applis et infras. Selon les contextes, on mettra l’accent sur l’organisation qui traitera, la distinction entre ressources internes et externes ou encore les périmètres infogérés.

			==== Coûts ====
			Comme le calendrier, les coûts sont essentiels pour faire émerger un système. Ici, on doit comprendre l'aspect technique des offres de service, des unités d'oeuvre ou des devis. On va s'intéresser à ce que coûtera la mep et le récurrent.

			== Revue par les pairs ==
			Le DAT permet de structurer une vision, une réflexion, et d'expliciter des choix. Il doit être un outil de communication et d'échanges. La revue par les pairs est essentielle pour ne pas se perdre dans l'analyse. Pour couvrir tous les angles, il est nécessaire que tout travail soit revu et challengé. On a trois grands types de revues :
			* Les comités d'architecture techniques et leurs variantes
			* La revue en groupes d'architectes
			* Les binômes.

			=== Comité ===
			Le comité d’architecture technique (CAT par la suite) a pour but principal de valider les systèmes ou applications en cours de conception. Le principe est de présenter son dossier à un groupe de représentants de la DSI : archis, séc, exploit, directeur technique, etc. C’est avant tout l’exhaustivité de l’analyse qui est regardée, en général au détriment de sa profondeur. Pour ce genre d’exercice, une communication optimale est nécessaire, que ce soit à l’oral ou à l’écrit.

			Le but est d'avoir une appétence technique, tout en ayant des facilité à expliquer des concepts complexes. Il faut s'attendre à être questionnées sur des angles non identifiés au préalable, et on peut se retrouver à ajourner si notre design est remis en question. Autant perdre du temps au début que de tout reconstruire un an après.

			=== Revue en groupe d'architectes ===
			On expose moins les jeunes architectes et on prépare les dossiers de façon collégiale. On va surtout chercher la somme des expériences communes pour identifier les points faibles et les compléter au mieux. On assure aussi une qualité commune à une équipe de niveaux variés.

			Elle permet le partage et le transfert de compétences sans sanctionner les imperfections, mais en les accompagnant.

			=== Revue en binôme ===
			Utile quand l'organisation de ne se prête pas à des comités. Le mieux est alors d'identifier un collègue qui sera le binôme et à qui présenter les travaux. En dev, on appelle ça la méthode du canard en plastique : on explique sa démarche à un canard en plastique (ou un collègue, ça évite de passer pour une débile). S'exprimer à voix haute permet de prendre du recul et d'améliorer sa qualité de réflexion. Les meilleurs canards sont ceux qui remettent les choix en question pour les optimiser.

Justine le 1 mars 2021 à 14:07

2021-03-01T14:07:36Z

@@ Ligne 168 : / Ligne 168 : @@
 L'analyse opérationnelle est aussi le moment de voir les contraintes posées par l'exploit : mécanismes de déploiement CI/CD, gestion des majs, rechargement des bases de données, gestion des logs, du NTP... L'idée est de creuser un peu pour se demander quels services opérationnels auront un impact sur notre système.
-= POUR CONTINUER =
+= Document d'Architecture Technique =
-https://openclassrooms.com/fr/courses/1372996-concevez-larchitecture-dun-systeme/6737986-entrainez-vous-a-representer-votre-premiere-architecture
+Le document d’architecture technique—DAT dans la suite de cours, ou TAD en anglais—est la pierre angulaire du travail de l’architecte. C’est à cet endroit que nous allons pouvoir capitaliser tout le travail de conception et documenter les hypothèses majeures retenues.

Justine le 28 février 2021 à 22:36

2021-02-28T22:36:13Z

← Version précédente		Version du 28 février 2021 à 22:36
Ligne 167 :		Ligne 167 :
	=== Déploiement, patches, et autres évolutions ===		=== Déploiement, patches, et autres évolutions ===
	L'analyse opérationnelle est aussi le moment de voir les contraintes posées par l'exploit : mécanismes de déploiement CI/CD, gestion des majs, rechargement des bases de données, gestion des logs, du NTP... L'idée est de creuser un peu pour se demander quels services opérationnels auront un impact sur notre système.		L'analyse opérationnelle est aussi le moment de voir les contraintes posées par l'exploit : mécanismes de déploiement CI/CD, gestion des majs, rechargement des bases de données, gestion des logs, du NTP... L'idée est de creuser un peu pour se demander quels services opérationnels auront un impact sur notre système.

			= POUR CONTINUER =
			https://openclassrooms.com/fr/courses/1372996-concevez-larchitecture-dun-systeme/6737986-entrainez-vous-a-representer-votre-premiere-architecture

Justine le 28 février 2021 à 22:35

2021-02-28T22:35:37Z

Voir les modifications

Justine : Page créée avec « https://openclassrooms.com/fr/courses/1372996-concevez-larchitecture-dun-systeme/5670251-decouvrez-le-metier-darchitecte-systeme = Inititation = == Principe généraliste... »

2021-02-28T21:27:37Z

Page créée avec « https://openclassrooms.com/fr/courses/1372996-concevez-larchitecture-dun-systeme/5670251-decouvrez-le-metier-darchitecte-systeme = Inititation = == Principe généraliste... »

Nouvelle page

https://openclassrooms.com/fr/courses/1372996-concevez-larchitecture-dun-systeme/5670251-decouvrez-le-metier-darchitecte-systeme

= 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.
<nowiki>
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.
</nowiki>

=== 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.