AILES : AT, Architecture Technique, principes généraux

Sphère et Point de vue
    Plus encore que d'autres sphères, il est important de distinguer l'Architecture Technique considérée comme un point de vue (et présentée ici : Architecture Technique), de la sphère.
    L'article sur les sphères architecturales rappelle la principale différence entre les 2 notions :
- un point de vue modélise une ou plusieurs structures (des éléments d'un même domaine architecturale) ;
- une sphère définit la nature de ce que ces structures vont modéliser: ici la nature des éléments modélisés représentent les composants techniques et les interfaces techniques nécessaires au développement des différents projets, mais aussi des aspects méthodologiques ou encore matériels. Si l'on est proche de l'implémentation, la vocation de cette sphère n'est pas de développer des projets. Les seuls développement concrets qui interviennent à son niveau sont ceux des frameworks (cf. plus bas). En revanche, on trouvera dans cette sphère tout ce qui supporte l'effort de développement.
    Ici, la différence entre point de vue Technique et la sphère Architecture Technique est plus subtile que dans celle exposée lors des principes généraux de la sphère d'Architecture Fonctionnelle:
- les deux peuvent et vont servir à développer des classes concrètes (via notamment le point de vue physique);
- les deux peuvent et vont servir à représenter des problématiques de déploiement (via le point de vue de déploiement et celui d'exploitation);
- mais, et là on arrive aux limites d'UML qui, rappelons-le, n'est qu'un langage de modélisation, pas un processus, seule la sphère Architecture Technique propose une méthodologie pour 'mettre en musique' tous les aspects concrets de développement, que ce soit au travers de:
    * framework;
    * procédures et activités de développement;
    * procédures et services de managements du réseau;
    * services et gestion des infrastructures;
Tout cela est illustré dans le diagramme suivant.

    [OhioState] fait clairement apparaître, dans la page 4 de son 'Architectural Framework' les 3 sous-sphères techniques que sont l'architecture de développement, l'architecture d'exécution et l'architecture d'opération.
    * L'aspect framework se retrouve dans les services fournis par l'architecture d'exécution (cf. plus bas).
    * L'aspect 'procédures et activités de développement' se retrouvent détaillées par l'architecture de développement (cf. ci-dessous);
    * L'aspect 'procédures et services de managements du réseau' est géré par l'architecture d'opération (cf. plus loin);
    * L'aspect 'services et gestion des infrastructures' est naturelle dédié à l'infrastructure (cf. paragraphe du même nom)

Architecture de développement
    C'est elle qui va devoir supporter l'effort de développement en:
- précisant les différentes activités.
Ici, le diagramme en isole 5: modélisation, codage et tests unitaires- 'Building' -, tests (d'intégrations), recettes (pour 'Acknowledgement'), la mise en production (pour Delivery).
On peut envisager un autre découpage.
- précisant le cycle de développement: en cycle en Waterfall, en V, Itératif..., ce qui implique également de déterminer qu'est-ce qui circule entre chaque étape (des modèles UML, du code, de la documentation, des librairies, ...), et comment (séparément, regroupés par paquet logique ?)
- précisant les outils techniques concrets: pour supporter la modélisation, le codage, etc., quels outils choisir, quels logiciels utiliser ?
Une fois choisi, comment les installer ? dans quel ordre ? (rq: il faut aussi s'appuyer et tenir compte des services proposés par l'infrastructure)
Une fois installé, comment les utiliser, les intégrer les uns aux autres ?
Ces outils, comme l'illustre [OhioState] page 6, concernent le développement, les aspects graphiques (comme le 'web authoring'), la gestion de configuration (qui inclue des aspect de 'version control' pour les différentes versions de fichier, mais aussi les aspects 'change management' pour gérer les requêtes de changement / évolution / corrections d'erreurs), des outils de tests et optimisation du code, etc.
- préciser les aspects méthodologiques: (Rq: cette branche peut constituer une sous-sphère à part entière). Cela va des normes de programmation en passant par les modèles de documentations jusqu'aux aspects de modélisation et de codage (avec des 'best practices').

Architecture d'Exécution
    Toutes les technologies concrètes qui sous-tendent les services techniques mises en évidence par la sphère Architecture Applicative(et détaillés dans les Principes Généraux de l'AA) trouvent un choix technologique précis dans cette sphère. Persistance: Oracle, Sybase, ? Serveur d'application: WebLogic?, WebSphere ? Tomcat ??? Broker de données: Tibco ? MQ ???
    Un aspect majeur de son activité réside dans les frameworks qu'elle fournit aux différent projet pour encapsuler des services techniques et aider les développeurs à se concentrer sur la logique applicative et les service métiers de leurs application. Typiquement, dans un environnement mixte 'nouvelles application / legacy', on peut avoir J2EE (java distribué) d'un côté, CORBA de l'autre. Ou encore, on peut avoir à mettre en oeuvre un broker de données type TIBCO ou MQSeries ou .... Plutôt que de forcer tous les développeur à se former sur toutes ces technologie, il est plus intéressant de fournir une encapsulation maison.
    Évidemment, qui dit encapsulation dit 'sur-couche', dit 'problème potentiel de performance'. Une branche potentielle de l'Architecture d'Exécution (qui peut prendre la forme d'une sous-sphère indépendante) est la branche 'prototype', chargée de construire rapidement des mini-applications sur lesquels on pourra appliquer des tests de performances.
    Cela peut amener à développer, en plus des frameworks qui encapsulent les difficultés technologiques, d'autres services techniques concret pour gérer des aspect de transaction, de cache de données, etc; aspects issus des services techniques de l'Architecture Applicative.
    Le rôle de l'Architecture d'Exécution est majeur: ces choix sont structurants et impactants. Tous les projets devront utiliser les technologies retenues, mais aussi compter sur l'Architecture d'Exécution pour masquer les évolutions, corrections et patchs de tels ou tels choix.

Architecture d'Opération
    Elle s'occupe de tous les aspects mise en production des applications développées (elle 'rend opérationel' les programmes, d'où le nom anglais 'operation architecture'). [CA] appelle cette sphère 'Operational System Organization'.
    [CA] distingue 3 sous-organisations à l'intérieur d'une sphère architecturale d'Opération:
- la transition: regroupe toutes les étapes de mise en production depuis les phases de recettes jusqu'à l'installation sur la machine de production. Il s'agit de déployer de façon coordonnée avec le cycle de développement (qui livre régulièrement de nouvelles versions), en sachant qu'une plate-forme de production ne s'arrête pas du jour au lendemain. Il faut parfois une deuxième machine de déploiement avec la nouvelle version, une première machine avec la version 'n-1' prête à prendre le relais en cas de pépin.
- le support utilisateur:
* Il assure l'installation (parfois à distance) de l'application sur les postes des utilisateurs finaux (dans le cas de logiciels déployés en internes).
* Il fournit un 'help desk' pour répondre aux question. Ce support peut se faire à plusieurs niveau: le premier est en contact direct aux utilisateur, le deuxième traite des problèmes plus compliqués, et le troisième est en contact direct avec les développeurs pour les anomalies ou demandes d'évolutions les plus importantes.
* Il assure également les sessions de formation et autres manuels ou interventions pour faciliter la mise en œuvre et l'utilisation du logiciel.
- la gestion des systèmes, qui regroupe toutes les activités garantissant le bon fonctionnement des logiciels déployés, comme ([OhioState] page 6) de l'analyse ficher de log, de l'administration à distance, de la gestion des ressources, de la mise en oeuvre des sauvegardes et restauration, du monitoring et du reporting. Cette branche travaille en très étroite collaboration avec l'infrastructure afin de gérer également tous les aspects migrations (lors de changement ou d'évolution de matériel et de réseau).

L'Infrastructure
    Quasiment tout projet développé dans une grande ou moyenne société s'appuie sur une infrastructure existante qui est là pour fournir ([Longepe]) "l'ensemble des installations de matériels et de logiciels réalisés pour permettre aux applications informatiques automatisant les processus métiers de s'exécuter dans des conditions satisfaisantes pour l'usager".
Ces installations comportent notamment :
- les réseaux locaux ou longues distances ;
- les plates-formes matérielles ;
- les logiciels de base (système d'exploitations, SGBD, middleware, etc.)
    Ces au niveau de l'infrastructure que l'on trouvera également les aspects d'installation et de déploiement de logiciels servant à supporter l'effort de développement (par exemple, l'installation d'un outils de codage), via une administration distance ou bien un 'master' répliqué sur les disques durs des postes des développeurs, etc. (l'architecture de développement s'appuie sur ces services pour déployer ses propres outils).
    On trouvera aussi les politiques d'évolutions de matériels, liés aux achats et aux formules d'amortissement.

Pourquoi ?
    [OhioState] rappelle les objectifs principaux derrière une telle Sphère Architecture Technique:
L'architecture utilisée au finale par les développeur:
* tient-elle le coup ?
   - Performance : l'attribut qualité qui mesure la capacité du système à fournir le service métier et traiter tous les événements métier à l'intérieur de son champ d'action en un temps d'exécution donné.
   - Resilience (robustesse) : le système s'écroule-t-il dès la première erreur ou peut-il fonctionner correctement dans des modes plus ou moins dégradés ?
   - Availibility (disponibilité) : l'architecture supporte-t-elle l'exécution du système pour la durée de temps spécifiée ? (par exemple : 7 jours sur 7!)
   - Security (sécurité) : les niveaux de sécurités, tant au niveau de l'application (comme évoquée au niveau applicatif qu'à celui du développement, sont-ils respectés et assurés ?
   - Operability : l'architecture permet-elle une mise en production efficace du système ?
   - Interoperability : toutes les parties du système fonctionnent-elles ensemble sans incompatibilités majeurs ?
(rq: les 2 derniers critères illustrent les concepts véhiculés par le sigle choisi pour la Sphère Architecture Technique , à savoir 'tout doit communiquer': les applications entre elles, bien sûr, mais aussi les codes, documentation, rapport d'erreur, etc., etc...).
* est-t-elle évolutive ?
    - Portability (portabilité) : cette architecture est-elle liée à l'environnement technologique actuelle ou peut-elle supporter un autre environnement ?
    - Scalability (extensibilité) : comment l'architecture supporte la montée en charge ?
    - Flexibility : à quelle rapidité cette architecture peut-elle intégrer de nouvelles spécifications métier ?
    - Maintainability : le système peut-il être modifié / corrigé facilement.

    On remarquera au travers de cette série d'objectifs un retour vers les 2 enjeux de l'Architecture ('architecture' dans son sens général) :
- le guide: maîtriser la complexité d'une architecture, avec ici l'identification claire des objectifs à atteindre pour assurer le bon fonctionnement (cf. premier ensemble d'objectifs de l'AT).
- l'évolutivité: le deuxième ensemble d'objectifs de l'AT illustre bien ce souci majeur qui se cache derrière toute architecture.