AILES : Architecture, définitions

Propriétés de base d'une architecture
On trouvera dans la figure suivante les 5 propriétés de base d'une architecture, que l'on retrouve mentionnée dans la plupart des définitions de [SEI] (qui n'en comporte pas moins de... 80! Deux "livresques", 8 classiques, 18 bibliographiques et 52 proposées par des visiteurs de [SEI])

    (ce diagramme est détaillé dans la modélisation de l'Architecture)
    Toutes ces définitions parlent au minimum d'une "organisation" de :
- point de vue (le point de vue d'un acteur constitue une vue architecturale, comme des spécifications fonctionnelles, des spécifications logicielles, point de vue structurel et organisationnel, matériel, déploiement, exploitation) ; cette notion est illustrée par l'article sur les caractéristiques de bases avec l'exemple d'une architecture en 4+1 vues.
- composants (ensemble indépendant et concret d'éléments d'architecture, par exemple logiciels, comme un ORB - CORBA) ; cette notion est détaillée dans l'article sur les caractéristiques de bases,
Cf. aussi - dans le Questionnaire Langage - les réponses concernant la notion de Composant.
- connexions entre ces composants, donc une topologie aussi bien logicielle (connexion via marshalling d'objet - transformation d'un donnée structurée en tableau de bytes - comme c'est le cas dans un ORB ou connexion via un streaming comme pour MQSeries...) que matérielle (connexion locale ou distribuée),
- contraintes sur le comportements dynamique (en terme, par exemple, de temps de réponses, de synchronisation, ...).

    Concernant ces caractéristiques de base (composant, connexions, contraintes...), Benjamin LEE (Software Programmer, IHS Solutions Sdn Bhd) résumait le tout en disant :
« L'architecture, c'est comme une équipe de foot. On y retrouve des composants (une équipe, avec des éléments, les joueurs), des connections (4-4-2 ou 4-3-3, l'ailier passe à l'attaquant), des contraintes de comportement dynamique (jeu à une touche de passe, ou en contre-attaque) ».
    Toutefois, il ne s'agit pas de jouer au foot, mais bien de répondre aux exigences ("requirements") du maître d'ouvrage (donc du client et de ceux qui "ont des intérêts" ("Stakeholder") dans la réalisation du système).

D'où une première définition :
« Description, au besoin selon plusieurs points de vue, de l'organisation des composants, de leur connexions et de leur dynamiques, afin de répondre à toutes les exigences du client. »
Si cette définition mentionne les éléments de base (qui sont détaillés dans Caractéristiques de bases), elle n'intègre pas encore les raisons même qui justifient l'Architecture. La suite de l'article étudie ces raisons et les enjeux qu'elles impliquent, avant de proposer une définition plus complète.

Au fait, pourquoi l'Architecture ?
    C'est vrai qu'en tant que jeune ingénieur, vous aller d'abord vous trouver confronté à des architectures "simples" :
- environnement mono-machine (allez, au hasard, que des PC sous NT),
- accès à l'information unique et bien défini (par exemple, via un ORB comme Orbix, une implémentation de CORBA),
- éventuellement, une base de données tout aussi unique et définie (par exemple, Oracle ou Sybase, ou ...).
    Et hop, avec ces éléments techniques, vous pouvez commencer à analyser, voir à concevoir votre application.
Vous pourrez après faire un joli dessin "d'architecture", décrivant la distribution de votre application. Par exemple :

...
Cela s'appelle de l'architecture descriptive.
Il s'agit de décrire, pendant ou après la conception du logiciel, une architecture qui "rend compte" des choix effectués.
Et avec cela, vous passez à côté de (au moins) 2 détails d'importance.

1/ Les exigences ("Requirements"). Il faut bien se rendre compte qu'elles sont de 2 types :
- exigences fonctionnelles (celles directement issues des "fonctionnalités" décrites dans le cahier des charges, comme accéder à un compte client),
- exigences non-fonctionnelles, comme la disponibilité du système, la montée en charge, l'administration, ... ce sont celles-là que l'on risque de négliger le plus facilement, si on ne les a pas soigneusement étudiées avant d'analyser et concevoir le système.
(cf. aussi les caractéristiques de bases : Enjeux)
2/ Les vues (cf. article caractéristiques de bases : Vues) : le dessin ci-dessus ne rend compte que d'une vue architecturale, ou encore "point de vue" (ici, la vue "déploiement" représenté par son diagramme UML correspondant). Mais il en existe bien d'autres.
Classiquement, on distinguera au minimum l'architecture fonctionnelle qui s'occupe de l'organisation des différents composants logiciels entre eux, et l'architecture technique qui rend compte de la topologie des machines (composant matériel) et de leur moyens de communication. Mais il existe des points de vue bien plus détaillés (cf. caractéristiques de bases : Vues).
    Il est toutefois intéressant de noter que la plupart des 80 définitions de [SEI] ne parlent que de "System Software Architecture", soit "Architecture du système logiciel". Le terme anglais "System" est ici à interpréter comme un système complet (logiciel + matériel). Toutefois, ces deux notions - logiciel et matériel - sont à la base des deux points de vues majeurs exposés dans l'article sur la les points de vue des architectures.

    Donc, l'architecture est là, comme la première définition le mentionne, pour répondre aux exigences client en adoptant les points de vues (vues architecturales) qui permettent de décrire de telles solutions. Mais son origine illustre une autre raison d'être de cette activité.
    Le paragraphe suivant détaille cette origine, centrée sur la production de services logiciels, mais d'autres aspects comme l'agrégation ou l'hétérogénéité technique sont abordés dans l'article Pourquoi l'Architecture ?.

Et ça vient d'où, l'Architecture ?
    [SAPF2000] situe l'apparition d'un intérêt pour cette activité dans les années 1970, à partir du moment où la réalisation des logiciels a franchi un certain seuil de complexité.
A ce moment, on se rendait bien compte que les ingénieurs en charge de cette réalisation... perdaient le contrôle, et ce notamment car :
- les spécifications étaient imprécises (ce qui est souvent le cas pour de "petits" projets, comme cela est rappelé dans l'article sur les spécifications)
- le code grossissait de façon monolithique, et ce même si les ajouts n'avaient rien à voir avec les fonctionnalités initialement codées (on a peur de toucher à ce qui existe, alors on empile...), du coup, plus personne n'était sûr des fonctionnalités précises de telle ou telle partie,
- l'intégration devenait impossible. Rajouter, par exemple, un nouveau type de base de donnée entraînait des problèmes dont la correction n'aboutissait toujours que... sur d'autres problèmes. Les effets de bords étaient trop nombreux, puisque toutes les parties du systèmes étaient bien trop couplées entre elles (chacune à besoin des autres... et la moindre correction est très dangereuse : les dangers du couplage ont déjà été dénoncés notamment dans l'article sur le codage).
- la mise en parallèle des tâches étaient risquées, puisque tout se tenait, il était difficile à une équipe d'avancer alors qu'elle dépendait des résultats d'une deuxième... elle-même attendant la première! (encore le couplage!...)
- la diversification des produits logiciels étaient compliquée. Qu'est-ce que la diversification ? Cela prend la forme soit :
    * d'une famille de produit (comme la suite bureautique Office de Microsoft, dont une bonne partie du code est aujourd'hui commune entre ses différents produits). Certes, ce n'est pas tous les jours que vous seriez amené à développer pareille "suite",
    * d'une gestion de configuration d'un logiciel (je livre une version 4.1 à telle date, une 4.2 à telle autre et je dois corriger des problèmes sur la 3.5). Et cela peut parfaitement être votre lot quotidien. Si le code à gérer en terme de configuration n'est pas suffisamment modulaire et découplé... c'est le cauchemar.

Enjeux
    le paragraphe précédent met clairement en évidence un premier enjeux :
l'architecture est avant tout un guide pour aider les concepteurs d'un logiciel a en maîtriser sa complexité.
    L'article sur les caractéristiques de bases : Structures indique où se situe cette complexité et précise le rôle du guide.
    Mais l'article sur l'intranet (à venir) démontre que de nouvelles architectures viennent se greffer sur d'ancienne, que de nouvelles sources d'informations peuvent venir compléter d'ancienne... (Rq : ce phénomène d'empilement monolithique existe toujours, mais cette fois, on n'a plus peur de remplacer des pans entiers d'architecture par d'autres, notamment lors de "l'intranisation" de certaines "vieilles" bases d'information).
    Regardez le schéma ci-dessus (celui du paragraphe précédent illustrant une architecture client-serveur) et posez-vous la question : que se passe-t-il si vous complétez votre ORB (qui permet la communication via des objets) par une communication HTML de type "Internet" pour que votre client accède à d'autres types de données distribuées ?
Ce client sera-t-il impacté par cette nouvelle source de données ? Ou bien cet ajout sera-t-il complètement transparent ?
    Le deuxième enjeu concerne donc l'évolutivité et il faut bien prendre conscience que, derrière ce terme, il ne s'agit pas de "tout prévoir" lorsque l'on conçoit une architecture. Il s'agit "simplement" de vérifier si la solution retenue n'est pas fermée. Pour cela, chaque composant d'une architecture (comme, par exemple, les composants "client", "serveur d'application" et "base de données" d'une application intranet) doivent pouvoir être remplacées par un composant similaire mais de technologie différente tout en gardant un impact mineur (par exemple, toujours dans le cadre d'une application intranet, la base de données doit pouvoir changer sans que le poste client s'en aperçoive).
    Comme le dit, dans [SEI], Matthew GREAM, ingénieur australien, l'architecture doit couvrir :
- le passé, en se servant de formalismes généraux existant qui aident à mieux comprendre les problèmes architecturaux du projet actuel (encore cette notion de guide),
- le présent, en décrivant l'architecture retenue pour ce projet au travers de diagrammes, textes, etc,
- le futur, en fournissant suffisamment d'informations sur la maintenance de l'intégrité architecturale lors de la vie d'un logiciel une fois livrée. Ces informations constituent un véritable référant qui n'est pas figé mais au contraire en constante évolution.

    Ces deux enjeux (guide et évolutivité) sont les justifications majeures de l'architecture. Celle-ci doit alors être prescriptive, donc être une étude préalable qui englobe tous les aspects du "système" à analyser.
    Seul ce type d'architecture (qui nécessite un véritable architecte et non quelques croquis avec des boites et des lignes) apporte l'assurance de répondre à tous les problèmes initiaux et de prendre en compte l'évolution du système.
    L'article sur l'intranet (à venir) en est une bonne illustration.
    Toutes ces caractéristiques de base sont repris et détaillés dans l'article suivant : Caractéristiques de bases.

Pour résumer
    Nous avons vu que :
- l'architecture peut être descriptive, mais elle doit surtout être prescriptive et intervenir avant la conception proprement-dite du système,
- elle est là pour maîtriser la complexité d'un système, dans le but de répondre à toutes les exigences du client, qu'elles soient fonctionnelles ou non.
    La définition évolue et prend en compte les enjeux de l'Architecture.
« Description, au besoin selon plusieurs points de vue, de l'organisation des composants, de leur connexions et de leur dynamiques, et guide permettant la mise en place des réponses aux exigences du client concernant un système et son évolution dans le temps. »
    Notre diagramme initial évolue également pour faire apparaître ces nouvelles notions :

(ce diagramme est rappelé dans la modélisation de l'Architecture)
Si l'architecture (bleue sur fond rouge) est détaillée, ainsi qu'une des caractéristiques de base (les exigences, en jaune sur fond rouge), on retrouve aussi les deux enjeux en vert sur fond rouge (guide et évolution).

Définition standard ?
    La définition donnée ci-dessus ne s'est donc pas basée, au moment de sa rédaction (mi-2001) sur une "définition standard"... et pour cause, en ce domaine, il n'y en avait pas vraiment.
    Microsoft nous rappelle, dans son MAO (Microsoft Architecture Overview, cf. [MSDN]) que la définition de "Enterprise Architecture" existe, et est définie par l'ANSI/IEEE Std 1471-2000 (créée mi-2001) :
"the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution."
    Mmmm... j'crois qu'c'estclair, y compris au niveau de la définition : au travers des termes "oraganization", "components", "relationships", "design" et "evolution", on retrouve bien les notions d'organisation, de composants, de connexions, d'exigences du client (auxquelles le"design" doit répondre"), et d'évolution dans le temps de la définition de cet article !
    Donc, y z'ont copié !!! (je blague, oeuf corse).
    Ce qui suit est issu du MAO (Microsoft Architecture Overview, cf. [MSDN] de Microsoft). Mes remarque sont en [italique rouge entre ]
    Microsoft précise qu'une architecture d'entreprise est un outil conceptuel qui permet de comprendre leurs propres structures et leur fonctionnement.
[Très vrai et cela ne date pas d'hier : il s'agit de la Loi de Conway, rappelée dans [XPLB], et qui observe - dès 1968 - que la structure d'un programme ou système informatique reflète nécessairement celle de l'entreprise ou de l'organisation qui l'a créée.]
    Elle leur fournit une cartographie de l'entreprise et un guide pour planifier les changements de métier et de technologie.
Elle comprend un ensemble cohérent de modèles qui décrivent la structure et les fonctions de l'entreprise.
Un modèle, toujours selon Microsoft, est arrangé selon un niveau de détail croissant et incluant :
- ses objectifs et buts;
- ces process et organisations;
- ses systèmes et données;
- ses technologies employés.
    [Remarque : on retrouve les 4 sphères architecturales (métier, fonctionnelle, applicative et technique).]