Sphères architecturales :
les "4 grandes" architectures

[Architecture],
[UMLAction], [Longepe]

	Pourquoi structurer ? (= "pourquoi faire ? quels métiers ?), avec, entre autre : - digramme d'Ishikawa (objectifs stratégiques métier) ; - cartographie des processus.
	Quoi structurer ? on raisonne en terme de fonctionnalité (liée aux métier). On y trouve les principaux diagrammes associés au points de vue fonctionnel.
	Avec quoi structurer ? On voit apparaître : - le composant technique UML qui fait le lien avec la fonctionnalité ; - des regroupement d'ordre applicatif.
	Comment structurer ? On y voit des problématiques de : - déploiement ; - choix techniques d'outils et d'implémentation.

L'architecture métier (cf. diagramme ci-dessus)
    Elle permet de décrire la structuration d'un système par rapport à ses activités métiers. Celles- ci se décriront : 
- par un diagramme des objectif (de type diagramme d'Ishikawa par exemple, afin de représenter les causes et leurs effets) ; 
- par une cartographie des processus ("opérationnel" et "de support").
Il faudra alors vérifier que chaque objectif est bien rempli par au moins un processus.
    On retrouve essentiellement ce type d'architecture dans des démarches de haut niveau, très en amont. Concrètement, cette architecture intervient dans des projets d'urbanisation de système d'information.
L'architecture fonctionnelle (cf. diagramme ci-dessus)
    Elle associe aux activités métiers des composants fonctionnels métier, tels que décrit dans l'article sur Architecture Fonctionnelle.
    Elle ne fait encore aucun choix d'implémentation, ni même de conception détaillée (comme l'application de design pattern). Elle se concentre sur l'identification des composants fonctionnels à même de fournir l'activité métier identifiée ci-dessus.

L'architecture applicative (cf. diagramme ci-dessus)
    Elle fait le lien entre les fonctionnalités identifié dans le niveau précédent et les composants techniques qui vont les réaliser : un composant technique peut très bien réaliser plusieurs fonctionnalités (cela s'appelle une librairie!).
    Il faut également déterminer les services techniques qui vont vus permettre de construire votre plate-forme technique d'exécution des composant, ainsi que cela est détaillée dans l'Architecture Technique.
    A ce niveau, vous ne savez pas la nature exacte de vos composants techniques (comme ceux au niveau "métier" ou "ressource"). Par exemple, dans un contexte d'objets persistant, aurez-vous besoin de :
- un accesseur COBOL appelant une base DB2 sur MVS ?
- un composant DCOM appelant une base Access ?
Vous savez juste que vos objets métier ne feront pas parti de la même application que vos objets persistant.
    Généralement, une architecture applicative peut être :
- centralisée : (thin client, serveur applicatif unique) ;
- client/serveur : (fat client, serveurs applicatifs multiples) ;
- n tiers (thin client, serveurs applicatifs multiples; applicatif downloadés partiellement sur le client) ;
- distribué (ORB ditribué).
cf. ci-dessous architecture multi-tiers.

L'architecture technique (cf. diagramme ci-dessus)
    Vous faites le lien entre vos composants techniques du niveau précédent et des choix techniques concrets, ainsi que des choix de déploiement.
    Par exemple, ce n'est qu'à ce niveau que vous savez si votre application "ressource" est un système persistant à base de fichier, de base de données relationnelles, objets, etc...
    C'est également là que vous structurer le déploiement de votre architecture et de ses composants techniques et définissez les protocoles de communications qui les relieront (HTTP, RMI/IIOP, SQL, ...).

Lien entre 4 architectures majeures et ces 4 sphères architecturales

    architecture client/serveur, dite "multi-tiers" (pour rappel, "tier" signifie niveau). 
    Elle met en ouvre un client qui communique à un serveur données ou de service :
- soit directement (auquel cas le client est "fat-client" ou "client lourd", car il contient toute la logique applicative) ;
- ou indirectement, via un ou plusieurs serveurs d'application (d'où "thin-client" ou "client léger", le client ne s'occupe plus que de la présentation des données). 
    Il s'agit de la solution trouvée face à l'expansion des entreprises, d'où :
- une sphère architecturale bien précise : la distribution des services (distribution locale, sur tout un département, tout une entreprise ou carrément via Internet), comme rappelé dans l'article sur caractéristiques de bases : Sphères ;
- une exigence cliente (cf. définition de l'architecture) précise : la montée en charge, d'où l'importance des serveurs intermédiaires et du ou des middlewares utilisés pour distribuer les services entre clients et serveurs.
    Comme l'indique l'article sur les points de vue, elle est liée aux points de vue techniques.
    Le tableau ci-dessous montre son lien avec les 4 grandes sphères architecturales présentées précédemment.
=> c'est une architecture applicative.
=> c'est avant tout une architecture technique.

    architecture multi-niveaux va de pair avec la précédente. Elle décrit où se situent les différents services fonctionnel, et ce pour :
- une sphère architecturale : le déploiement des services logiciels (déploiement au niveau local, au niveau du département, au niveau central). Ces services sont accédés à ces différents niveaux via un "poste de travail", point d'entré dans le système pour un utilisateur.
Par exemple, la génération de l'état d'un compte bancaire est une fonctionnalité faite en central, sur les serveurs de la banque. La consultation pour l'établissement d'un crédit se fait au niveau du département "prêts financiers". Sa visualisation se  fait au niveau de tout poste client, après identification de l'utilisateur. Ces deux derniers services (consultation pour prêt financier et visualisation) nécessitent des "postes de travail" au niveau département et local
(on trouvera un autre exemple de niveau - front office et back office - dans l'article sur le passage entre l'AT et  l'AF)  ;
- une exigence cliente : maintenance (et évolutivité) fonctionnelle. Il faut pouvoir changer la visualisation d'un état bancaire sans pour autant impacter et modifier les fonctionnalités de génération d'un état ou d'établissement de crédit.
    Comme l'indique l'article sur les points de vue, elle est liée aux points de vue techniques.
    Le tableau ci-dessous montre son lien avec les 4 grandes sphères architecturales présentées précédemment.
=> c'est avant tout une architecture technique.

    architecture en couches établi la correspondance entre les services techniques (comme, par exemple, l'accès à une base de données) et les composants d'architectures concernés (comme un middleware, plus un driver), via des cas d'utilisation technique, le tout au sein :
- d'une sphère architecturale : la répartition de services techniques (la plus connue est "présentation - application - métier - accès aux données - stockage des données)
Par exemple, la génération de l'état d'un compte bancaire est une fonctionnalité faite en central, sur les serveurs de la banque. La consultation pour l'établissement d'un crédit se fait au niveau du département "prêts financiers". Sa visualisation se  fait au niveau de tout poste client, après identification de l'utilisateur.
- d'une exigence cliente : maintenance (et évolutivité) technique. Il faut pouvoir changer la base de données sans remettre en cause la présentation. Si l'architecture suit un modèle en couches bien découplées les unes des autres, chacune peut évoluer à son rythme.
    Comme l'indique l'article sur les points de vue, elle est liée aux points de vue fonctionnels et 
techniques.
    Le tableau ci-dessous montre son lien avec les 4 grandes sphères architecturales présentées précédemment.
=> c'est avant tout une architecture applicative.

    architecture à base de composant identifie des composants architecturaux réutilisables. Un composant, dans ce contexte, est plus spécifique que le composant introduit par les propriétés de l'architecture et détaillé dans les caractéristiques de bases. Il se caractérise par :
- une interface bien définie
- une implémentation.
Il existe différent type de composants (métier, technique, ...)
- une sphère architecturale :  la distribution des services (distribution locale, sur tout un département, tout une entreprise ou carrément via Internet), donc la même que pour l'architecture multi-tiers.
- une exigence cliente : réutilisation, puisqu'un composant est soit développé (et utilisé à différents endroits d'un système logiciel) ou acheté tout fait (et utilisé tel quel, ou encore encapsulé).
    Comme l'indique l'article sur les points de vue, elle est liée aux points de vue techniques.
    Le tableau ci-dessous montre son lien avec les 4 grandes sphères architecturales présentées précédemment.
=> c'est une architecture fonctionnelle et applicative.

Dans ce tableau, on peut visualiser les activités principales de structuration (en gras), ce qui permet d'associer à ces architecture une sphère principale d'activité.

Architectures transversales
    Il s'agit d'architecture qui auront des activités de structuration au sein des 4 grandes sphères présentées en début d'article. On peut les qualifier d'architecture de "support" (au même titre qu'il existe des "processus supports" par opposition aux processus opérationnels, ou encore des composants techniques support constituant la plate-forme technique qui supporte l'exécution des composants fonctionnels techniques.

    L'exemple le plus connu d'architecture concernant toutes les sphères architecturale est l'architecture de sécurité. 
    Au niveau métier, on va identifier :
- le périmètre général de sécurité suivant le public visé (grand public, sociétés du groupe, société) et le média utilisé (internet, extranet, intranet).
- les risques sécurité (en terme juridique, commercial, organisationnel, ...), en général identifié par la MOA (maîtrise d'ouvrage).
    Au niveau fonctionnel, on va identifier les services et les flux de données qui auront besoin d'être sécurisé.
    Au niveau applicatifs, on identifiera le type de service technique à apporter pour sécuriser les données (typiquement : Disponibilité - Intégrité - Confidentialité - Contrôles).
    Au niveau technique, on mettra en place les firewalls et l'on identifiera les DMZ qui en découlent, ainsi que les protocoles (et les ruptures de protocoles entre DMZ). Il s'agit de sécuriser les serveurs, les échanges et les accès. 

    D'autres types de structuration (donc d'architecture) sont également transversales, comme : 
- l'architecture transactionnelle ;
- l'architecture organisationnelle (qui relie les fonctions à une ressource humaine) ;
- l'architecture administrative (avec un help desk chapotant des administration de réseaux, système, application, ...).