2.2.1 Système et Architecture
Commençons notre investigation en confrontant différentes définitions d’un système avec différentes définitions d’une architecture.
Système
Joël de Rosnay « Un ensemble d’éléments, en interaction dynamique, organisés en fonction d’un but. » [dR77]
Jean-Louis Le Moigne
« Quelque chose qui fait quelque chose (activité = fonction) et qui est doté d’une structure, qui évolue dans le temps, dans quelque chose (environnement) pour quelque chose (finalité). » [LM90]
MIL-STD-499 “An integrated composite of people, products, and processes that provide a capability to satisfy a stated need or objective.” [DoD74]
ISO 15288 “A combination of interacting elements organized to achieve one or more stated purposes” [ISO08]
EIA 632 “The aggregation of end products and enabling products that achieves a given pur- pose.” [EIA03]
Architecture ISO/IEC/IEEE 42010
“The fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution.” [ISO11] TOGAF “The structure of components, their inter-relationships, and the principles and guide- lines governing their design and evolution over time.” [For18] Nota : TOGAF 9.2 adopte deux définitions de l’architecture. Celle précitée de l’ISO/IEC/IEEE 42010 et celle-ci.
Frey “The structure, arrangements or configuration of system elements and their internal relationships necessary to satisfy constraints and requirements.” [Cra07]
John W. Evans “An architecture is the conceptualization, description, and design of a system, its components, their interfaces and relationships with internal and external entities, as they evolve over time.” [Mag10]
Crawley “The embodiment of concept, and the allocation of physical/informational function to elements of form, and definition of interfaces among the elements and with the surrounding context.” [Cra07]
Crawley,Cameron and Selva
“The simplest notion of architecture [..] is that architecture is an abstract description of entities of a system and the relationship between those entities. In systems built by human, this architecture can be represented as a set of decisions ” [CCS15] Reekie and
McAdam
“The whole consists of parts; the parts have relationships to each other; when put together, the whole has a designed purpose and fills a need. ” [RMM06]
Joel Moses “An architecture is a plan for change .” [Mag10]
Nous pouvons noter une assez grande diversité dans la définition d’une architecture, et également une proximité avec la notion de système. Les quatre premières en font une caractéristique consubstantielle d’un système. Les quatre suivantes se focalisent sur les aspects fonctionnels d’un côté et physiques de l’autre, augmenté de la projection ou du passage des uns aux les autres. Seule la dernière définition, celle de Joel Moses, sort du lot en proposant une vision temporelle de l’architecture, vision que nous reprendrons fortement lorsque nous bâtirons notre proposition de paradigme.
En revanche, ces différentes définitions nous éclairent assez peu sur comment distinguer et particulariser l’architecture dans un contexte d’ingénierie des systèmes. Il va nous falloir creuser plus avant.
2.2.2 Faire de l’ingénierie et architecturer
Il est nécessaire de faire la distinction entre une démarche d’architecture (système) et une démarche d’ingénierie (système). À la fois les postures à adopter et à la fois les techniques et méthodes à mettre en œuvre diffèrent.
Tout d’abord, sans sombrer dans des querelles byzantines ou disputes sémantiques, faisons quelques remarques sur le vocabulaire. Sa mise en regard avec la langue anglaise permet de saisir le désarroi auquel nous pourrions être confronté.
Architecturer est un verbe en français, non en anglais (néologisme en anglais américain – entrée inexis- tante dans le Merriam Webster – et connoté génie logiciel en anglais britannique – “Design and configure (a program or system)” dans l’Oxford).
Concevoir n’a pas de traduction fidèle en anglais, “to design” en est la traduction la plus rapprochée, mais approximative (ne parlons pas de “to conceive” en anglais, qui veut dire avant tout faire un enfant, conception ici dans son sens premier). Du coup, le terme de Architectural Design a disparu des normes et standards liés à l’ingénierie et l’architecture des systèmes au profit de :
• Une partition entre Architecture Definition et Design Definition dans l’ISO 15288 [ISO15].
• Un triplé de processus cœur (Architecture conceptualization, Architecture evaluation, Architecture elaboration) dans l’ISO/IEC/IEEE 42020 [ISO17].
Plutôt que de les opposer, nous serions plus avisé de promouvoir la dualité et la complémentarité, entre architecture et ingénierie. Cette distinction existe depuis longtemps dans d’autres domaines comme le bâtiment (architecture et génie civil), le naval (architecte naval et chantiers navals).
Brad Mercer de la MITRE Corporation [Mer08] pointe la différence entre les deux en notant la com- plémentarité entre analyse des fonctions et synthèse de la forme, reprenant en cela le terme donné par Christopher Alexander [Ale64], un des pionniers dans la formalisation de la conception architecturale :
Engineering “Engineering employs analysis of function to iteratively decompose and separate a primarily functional representation of a whole into representations of economically producible components that can be assembled to construct the functional whole.” Architecting “Architecting employs synthesis of form to iteratively compose separate elements to
form a coherent whole, or a representation of a coherent whole, that can serve as an initial point for system development.”
Le tableau ci-après, extrait de [Mer08] (traduit par l’auteur) liste ces complémentarités.
Table 2.2: Complémentarité entre architecture et ingénierie
Architecture Ingénierie
Synthèse de la forme Analyse des fonctions
Holistique Réductionniste
Affronte la complexité Simplifie la complexité
Valeur qualitative Coût quantitatif
Abductif Déductif
Heuristique Algorithmique
Le quoi Le comment
Accent sur le sens (sémantique) Accent sur l’arrangement (syntaxe) Interfaces externes, ouverture Interfaces internes, limitation
Abstrait, théorique Précis, exact
Produit des spécifications d’architecture Produit des spécifications de réalisation Conception architecturale Conception centrée ingénierie
Détaillons certaines de ces complémentarités.
Holistique versus réductionniste
L’approche holistique (du grec ancien ὄλος / hólos signifiant entier), d’un point de vue ontologique (vision du monde), considère qu’un système complexe n’est pas réductible (approche réductionniste) à l’ensemble ou l’agrégation de ses parties, mais que le tout est plus grand que la somme des parties. De fait, les propriétés de tels systèmes ne peuvent se déduire de la seule connaissance de leurs parties (principe d’émergence). En architecture, la synthèse de la forme ne saurait se réduire à une vision extensionnelle des parties la constituant.
Affronter la
complexité versus la simplifier
Saisir la complexité d’un système se fait selon Edgar Morin [Mor05] suivant trois perspectives paradoxales :
• Le tout est plus grand que la somme des parties. Il s’agit du principe d’émergence vu précédemment.
• Le tout est plus petit que la somme des parties. Composer des éléments entre eux limite leur autonomie respective, leurs degrés de liberté. Ils perdent une partie de leur individualité en se fondant dans le tout.
• La prise de conscience de cette contradiction inhérente.
Affronter la complexité n’est pas refuser la simplicité, c’est assumer la contradiction, l’incertain, accepter qu’une part échappe à certaines formes de rationalités par ailleurs souvent limitées. Adopter une pensée complexe ne rejette pas une pensée simplifica- trice, mais si elle s’appuie dessus, elle ne s’en contente nullement et la complète. La simplification tente de mettre de l’ordre en rationalisant suivant des principes de disjonction et réduction, en laissant de côté l’incertain, le désordre apparent. La pen- sée complexe en prend le contre-pied en se basant sur les principes de distinction et conjonction, et d’implication. Il s’agit selon Edgar Morin d’effectuer en une même opération apparemment paradoxale de séparer et de joindre : « vous allez joindre l’Un et le Multiple, vous allez les unir, mais l’Un ne se dissoudra pas dans le multiple et
le multiple fera quand même partie de l’Un » ([Mor05]). Affronter la complexité se fait en raisonnant sur des modèles au bon niveau d’abstraction ou suivant la bonne perspective, leur nécessaire caractère parcimonieux n’imposant pas la simplification. Abductif versus
déductif
C’est certainement là une des discordances majeures sur les modes de raisonnement entre une démarche d’ingénierie et une démarche architecturale. Si le couple induc- tion/déduction est souvent mis en avant dans les démarches de type résolution de problèmes, l’inférence abductive, à notre sens l’inférence primordiale dans une dé- marche de conception architecturale, est trop souvent ignorée. Nous lui consacrerons un passage complet (cf. section 2.3.2 page 64), sous la dénomination que lui donna Umberto Eco : la méthode du détective [Eco92].
Ajoutons à ces complémentarités de [Mer08] quelques compléments de notre cru.
Multi-tout versus
multi-ingénierie
Là où une conception système met en œuvre différentes ingénieries (à la fois disci- plinaires – mécanique, électrique, thermique, logicielle. . . – et transverses – facteur humain, sûreté, sécurité. . . –), la démarche architecturale requiert souvent d’élargir son champ d’implication au-delà de ces ingénieries en incorporant des aspects tels : la politique, la stratégie, le marketing, l’environnement, le juridique, le social ou le sociétal, la culture. . . Décisions structurantes et entremêlées versus décisions locales et concourantes
Les deux démarches sont rythmées par des prises de décision. C’est la façon cadencée d’avancer dans l’inconnu. Pour autant, les natures des décisions ne sont pas équi- valentes. Les décisions architecturales façonnent la solution dans son ensemble et l’orientent dans une direction générale, un axe distinctif. Leur remise en cause effon- drerait la cohérence et l’intégrité de la proposition. Ces décisions tiennent la solution. D’autres décisions sont plus locales, et complètent la définition précise de la solution. Ces choix ne remettent pas en cause l’intégralité de la solution et peuvent donc être retardés au maximum (et surtout intervenir causalement une fois les choix architec- turaux verrouillés). Ils sont suffisamment non corrélés entre eux pour être traités de manière concourante (posture analytique) au contraire des choix architecturaux qui nécessitent une posture holistique. Nous indiquerons ultérieurement des indications pratiques permettant de distinguer entre décisions architecturales et décision d’ingé- nierie. Mentionnons ici quelques contrastes :
Rationalité des alternatives De manière simplifiée, supposons qu’une décision nous
confronte à deux alternatives a et b. Le choix dans un contexte d’ingénierie se formaliserait en logique propositionnelle par une simple disjonction (exclusive ou inclusive) : (a ∨ b) ou (a ⊕ b), alors que le choix dans un contexte archi- tectural pourrait être confronté à des contradictions, des dilemmes. . . comme : (a → b) ∧ (b → ¬a).
Résolution de l’information Souvent l’information dont nous disposons dans un
contexte de conception architecturale est incertaine, floue, incomplète. Cette ré- solution s’améliore au fur et à mesure de l’avancement et donc de la profondeur de l’analyse, passant souvent d’une vision qualitative à une vision quantitative. Conjonction
complexe vs disjonction compliquée
Une des conséquences de l’adoption d’une pensée complexe aboutit à privilégier la définition d’une architecture sous forme de principes (règles d’organisation, principes de composition des éléments entre eux. . . ). L’ingénierie de ces systèmes complexes repose plutôt sur une découpe idoine en constituants élémentaires, éventuellement sur
plusieurs niveaux de hiérarchie, et des propositions d’agrégat de ces constituants. Pour utiliser une analogie, nous retrouvons là une différence dans la théorie des ensembles entre définir un ensemble en compréhension et le définir en extension ; nous pourrions même pousser cette comparaison, et posant qu’un ensemble qui serait uniquement défini en extension et pour lequel nous ne parviendrions pas à l’exprimer en compré- hension, ne posséderait pas d’architecture intelligible. Dans un cas, l’abstraction sous forme de principes permettrait de saisir la complexité, ou tout au moins de rendre intelligible le tissage des éléments entre eux, quand dans l’autre cas nous ne rendrions compte que d’un pliage compliqué.
Informatif et intentionnel plutôt que complet et cohérent
Une définition architecturale se doit d’orienter et de donner un cadre aux divers travaux (d’ingénierie et autres) accompagnant le cycle de vie du système considéré qui en émanent. En ce sens, elle ne saurait être trop précise ou trop contraignante, donnant trop de détails, mais au contraire suffisamment floue et incertaine de manière à laisser libre cours aux diverses ingénieries. Elle ne doit pas résoudre tous les problèmes (c’est le rôle des travaux des ingénieries), mais plutôt permettre de comprendre dans quel contexte ils se posent et vers quelles finalités la solution doit tendre.