Architecture

L'architecture se divise en deux parties principales :

l'architecture "physique" qui concerne la définition du matériel à utiliser pour héberger des applications et à laquelle on peut aussi rattacher l'architecture du réseau, bien que certaines architectures logicielles "imposent" presque une certaine architecture matérielle.
l'architecture "logicielle" qui concerne la mise en place des logiciels permettant la mise à disposition des applications désirées.

Les deux domaines se rejoignent parfois ou interfèrent fortement car certains choix d'architecture logicielle nécessitent la mise à disposition du matériel approprié :

Pour utiliser une architecture logicielle "n tiers" il vaut mieux disposer de plusieurs machines ... bien que l'utilisation de "containers" et de "micro-services" puisse rendre ce paramètre un peu obsolète.
Pour donner du souffle à certains logiciels, par exemple les bases de données et dans une certaine mesure les serveurs d'application, il faut que le matériel hébergeant le logiciel dispose de :

1. suffisamment de mémoire.
2. un/des processeur(s) d'une puissance adéquate.
3. un système disques adapté à la demande d'entrées/sorties.
4. un ou plutôt des accès réseau aux performances adéquates.

Les termes utilisés sont en général "imprécis" (suffisamment, adéquate, adapté, performant) pour justifier une connaissance nécessaire de la réalité des matériels et logiciels qui seule permet de réaliser un ensemble où tous les éléments fonctionnent en harmonie ... et donnent la qualité de résultat escomptée.

L'architecture ne doit pas être l'apanage des grandes sociétés (les "grands comptes"), mais peut parfaitement être abordée au sein des PME et PMI pour lesquelles elle peut être une garantie d'un bon rapport coût / satisfaction.

Si l'architecte "informatique" n'est pas un "artiste" il doit être au moins un bon "artisan" à l'aise avec tous ses outils.

NB : on parle aussi quelquefois d'architecture de sécurité, mais la sécurité fait partie des éléments à prendre en compte obligatiorement dans l'architecture matérielle comme dans l'architecture logicielle. Pour bien faire, la sécurité doit être prise en compte dés la conception des logiciels jusqu'aux matériels et même à l'usage des logiciels (politique de mots de passe et politique de sauvegarde par exemple).
Si les données ont un niveau de confidentialité particulier il faudra consacrer une partie de l'étude à la gestion adéquate de cette confidentialité.

Architecture : éléments de mission

Un exemple de la contribution des architectes.
Lorsqu'une société décide d'installer un nouveau logiciel elle devra réaliser un certain nombre d'opérations :

Définir les contraintes, budget, puissance nécessaire (mémoire, disques, processeur)
Criticité de l'application
Besoins de sécurité des données
Définir l'environnement de sécurité de l'application
Peut-on utiliser un matériel existant ?
Si non :

Choisir et configurer le nouveau matériel (mémoire, disques, processeurs)
Commander le matériel
Installer le matériel dans ses locaux (ou le réceptionner si un serveur extérieur est utilisé)
Initialiser le système et installer l'Operating System
Configurer et sécuriser l'OS
Installer le logiciel choisi
Paramétrer le logiciel choisi
Effectuer les tests techniques

Si oui :

Le serveur choisi est-il suffisant ou est-il nécessaire de le renforcer (mémoire, disques, processeurs)
Le serveur est-il à la bonne version de système
Comment effectuer l'installation sans perturber les applications existantes ?
Quel est l'influence de ce choix sur la sécurité des applications déjà hébergées sur cette machine....
Quelles actions doivent elles être effectuées pour atteindre la cible de sécurité fixée
...

Effectuer les tests fonctionnels
Valider le système de sauvegarde
Mettre en place les règles de sécurité
....

La contribution essentielle de l'architecte est de participer et de valider chacune des phases afin d'assurer que le système présentera les fonctionnalités prévues avec un environnement stable, performant et sécurisé.
L'architecte joue ici un rôle de chef d'orchestre pour assurer que la partition sera jouée sans "couacs".

Gestion de la vie des données

Problèmes d’historisation/archivage ou suppression de données.
Lors du développement d’une nouvelle application les concepteurs pensent rarement dans la durée et il est très exceptionnel de trouver dans les éléments d’architecture la notion de « durée de vie » ou de « cycle de vie » des données.
Cet état de choses est en train de changer car on stocke de plus en plus de données et que stocker toutes les données accessibles « en live » coûte très cher.
Les problèmes ne commencent qu’avec le temps … car les données s’accumulent. Les sauvegardes deviennent plus longues, les temps de réponse se dégradent insensiblement et finissent par devenir un vrai problème pour les utilisateurs dont l’activité principale ne doit pas être d’attendre un résultat devant un écran figé. Cela peut être encore plus préjudiciable si celui qui "attend" est un client éventuel qui sera tenté d'aller "voir ailleurs" si les systèmes répondent.
J’ai rencontré des applications de suivi de livraison dont les temps de réponse étaient devenus « catastrophiques », et qui, après analyse montrent que les tables interrogées comportent 10 ans d’historique alors que le suivi demandé ne concerne en général que les quelques derniers jours.
Si, en plus, l’indexation n’est pas parfaite on atteint des temps de réponse très variables entre gros et petits clients pouvant varier de 2 à 30 secondes, le plus long pour les plus gros clients … ceux avec qui on travaille le plus et dont on consulte/traite le plus souvent souvent les données. Et pour un utilisateur normal 10/20 secondes correspondent à une durée prohibitive qui perturbe largement son travail.

Par ailleurs la plupart des données ont plusieurs vies …
L’accès rapide à une facture est indispensable tant qu’elle est « en cours » puis « payée », mais plus tard elle reste intéressante pour assurer un suivi du client, pour calculer des statistiques commerciales, pour répondre à des règlements administratifs (archivage).
Mais ces derniers usages ne nécessitent plus un accès fréquent et rapide aux données, il est donc intéressant de « sortir » ces données de l’endroit où elles sont nées pour les entreposer dans un endroit moins prestigieux .. et moins coûteux.
Il est donc très important de définir le cycle de vie des données pour ne pas se retrouver avec les factures et bons de livraison des dix dernières années dans le système de suivi « technique » et financier des livraisons. Pour le suivi des livraisons, dès la livraison effectuée la donnée ne présente plus d’intérêt direct et peut être « sortie » du système opérationnel pour être transférée dans un système où elle restera disponible pour tous les besoins statistiques.
Une conservation trop longue présente plusieurs inconvénients :

Les volumes stockés augmentent et nécessitent des ajouts au systèmes de stockage.
Les sauvegardes durent de plus en plus longtemps.
Les temps de réponse s’allongent.
Les opérations de maintenance deviennent de plus en plus consommatrices de temps, une simple modification de colonne peut immobiliser le système pour de longues périodes.
En cas d'incident sur les données les temps de restauration deviennent prohibitifs.

Mais même les besoins statistiques diminuent avec le temps et la dernière période de la vie d’une donnée se passe dans des archives gelées ( communément appelées glacier ? ).

Il faut donc répartir les données sur des systèmes différents en fonction de leur usage instantané.
Ceci présente en plus l’avantage de ne pas surcharger un système « temps réel » utilisé par de nombreuses personne avec des traitements statistiques de longue durée qui pénalisent les utilisateurs et qui surtout donnent des temps de réponse très variables selon le lancement de ces gros traitements.
Une « bonne » répartition est en général :

Un système « temps réel » interactif ne doit pas contenir de données inutilisées et ne doit pas avoir à « supporter » des traitements lourds en concurrence avec le travail des utilisateurs interactifs.
La nuit ou le week-end permettent de « sortir » les données devenues obsolètes pour les envoyer dans un système « statistique » de second iveau qui traitera de grosses quantités de données pour fournir des analyses et autres résultats statistiques utiles.
Le système « statistiques » devra lui même être « purgé » des données devenues trop anciennes qui pourront être stockées dans des machines (ou sites) d’archivage avant d’être éliminées ... mais quand ?

La répartition des données au cours de leur vie sur des machines de caractéristiques différentes présente beaucoup d'avantages notamment au niveau coût par l'optimisation du stockage et du couple processeurs/mémoire, sans compter une meilleure expérience utilisateur pour la partie interactive ... de plus en plus importante.

En résumé :

Processeurs et disques rapides, beaucoup de mémoire pour les applications interactives.
Disques de grosse capacité pour les machines "statistiques".
"glacier" pour les données plus anciennes, par exemple celles à conserver légalement.
Et surtout un plan de vie des données prévu dès la conception !