Fiches outils - Architecturer des systèmes et des services
Le diagramme d’architecture
Le diagramme d’architecture doit permettre de comprendre, à un niveau très élevé, les interactions entre les intervenants et les applications mais aussi entre les composants de ces applications ainsi que les données qui transitent. Ainsi, un tel diagramme propose les informations suivantes :
-
Qui : les intervenants impliqués (équipes ou entreprises), généralement représentés en jaune.
-
Quoi : Les processus ou sous-processus, également représentés en jaune.
-
Comment : les applications, services ou composants d’applications mais aussi les données qui transitent entre ces composants qui sont eux en bleu. Pour ce qui est des données, la représentation issue de ArchiMate est utilisée.
Bien souvent, il s’agit d’étendre ces informations de base pour y inclure, a minima, les informations d’infrastructure, c’est-à-dire les composants sur lesquels reposent les applications, services ou composants présentés ci-dessous.
D’autres informations peuvent être présentes, en fonction du niveau de maturité de l’organisation.
TOGAF décrit le modèle tandis que ArchiMate le met en œuvre. TOGAF mais aussi Archimate sont abordés au chapitre « Structurer les démarches »....
L’architecture d’une solution
Les solutions techniques doivent être décrites au travers d’un certain nombre d’informations variées. La qualité de la solution est proportionnelle à la quantité d’informations acquises, vérifiées et regroupées dans un document unique. Ce document comprend l’ensemble ou une partie des éléments suivants :
-
Contexte et portée de la solution : présentation du contexte commercial et des objectifs visés par la solution informatique proposée, délimitant clairement son champ d’application.
-
Présentation de la solution : description brève des fonctionnalités clés et des avantages offerts par la solution informatique proposée pour répondre aux besoins identifiés.
-
Hypothèses et dépendances architecturales : identification des suppositions fondamentales et des éléments extérieurs nécessaires au bon fonctionnement de l’architecture globale.
-
Décisions architecturales, risques et points ouverts : explication des choix majeurs faits dans l’architecture, des risques identifiés et des aspects non résolus nécessitant une attention supplémentaire.
-
Modèle d’architecture de haut niveau : vue d’ensemble schématique des principaux...
Le contrat de service
Le contrat de service est utilisé lorsque plusieurs systèmes interagissent entre eux, comme indiqué au chapitre « Architecturer ses développements propres ».
-
Le nom du composant de service : identifiant unique du service qui décrit la fonction qu’il remplit. Il permet aux consommateurs de services de le reconnaître et de l’appeler.
-
La description associée : rôle et fonctionnalités du service. Elle fournit des informations supplémentaires sur ce que le service fait et comment il peut être utilisé.
-
Le domaine : domaine métier ou fonctionnel auquel le service est associé, comme la finance, les ressources humaines, ou encore le support.
-
Le bloc fonctionnel : fournit une indication générale des types de fonctionnalités que le service fournit. Par exemple, la configuration et la gestion des paramètres.
-
Le fournisseur de service : entité ou organisation qui fournit le service, interne ou externe.
-
Le propriétaire du composant de service : personne ou entité responsable du développement, de la maintenance et de la gestion du service.
-
Le type : nature du service, par exemple un service utilitaire, ce qui signifie qu’il fournit des fonctionnalités générales et souvent réutilisables.
-
La version : version actuelle...
Le contenu d’un plan de sortie
Ce plan doit être préparé en amont et peut ainsi être exécuté à tout moment.
-
Objectifs et portée : définition claire des objectifs de la sortie, en identifiant les raisons de la cessation du service ou du produit, ainsi que la portée de l’opération de sortie.
-
Équipe responsable : identification des membres de l’équipe ou des parties prenantes responsables de la planification et de l’exécution du processus de sortie.
-
Calendrier et échéanciers : établissement de dates et de délais pour chaque étape clé de la sortie, y compris la date prévue de cessation du service ou du produit.
-
Communication : plan de communication détaillant les messages à transmettre aux parties prenantes internes et externes, ainsi que les canaux et la fréquence de diffusion des informations sur la sortie.
-
Étapes de sortie : description précise des étapes spécifiques à suivre pour démanteler ou retirer le service ou le produit, y compris la désactivation des fonctionnalités, la migration des données, la résiliation des contrats, etc.
-
Gestion des risques : identification et évaluation des risques associés à la sortie, ainsi que des mesures d’atténuation pour gérer...
La documentation pour approuver une solution
Les solutions reposent sur de nombreuses technologies ou services sous-jacents. Ces mêmes technologies ou services sous-jacents doivent être étudiés au préalable afin de garantir la viabilité de la solution. Par exemple, si une application repose sur un système Linux que personne ne peut supporter, alors la solution dans son ensemble n’est pas viable. Pour décrire, et donc approuver une technologie ou un service, il peut être utile de proposer les caractéristiques suivantes :
-
Présentation de la technologie ou du service : vue d’ensemble détaillée des fonctionnalités et des avantages offerts par la solution.
-
Risques liés au service : identification et évaluation des dangers ou des menaces pour l’intégrité du service ou des données et réflexions approfondies sur les aspects de sécurité spécifiques et leurs implications.
-
Authentification et autorisation : mécanismes garantissant l’identification précise des utilisateurs et leur accès approprié aux ressources.
-
Chiffrement : conversion des données en un format illisible pour assurer la confidentialité et la sécurité lors de leur transmission ou stockage.
-
Exposition publique : niveau d’accès ou de visibilité...