Architectures des GDSS distribués

De nombreux auteurs définissent l’architecture d’un DSS en termes de divers composants [Bonczek 81] [Sprague 82]. [Turban 01] note que les divers composants d’un DSS traditionnel et/ou ses utilisateurs peuvent être dispersés à la fois géographiquement et organisationnellement au travers d’une organisation et de son environnement. Les décideurs et assistants doivent être capables de travailler avec le système n’importe où. Ils doivent avoir un accès direct au DSS afin d’adapter dynamiquement les ressources à la situation. L’architecture qu’il propose possède cinq caractéristiques principales :

Les ordinateurs sont dispersés au travers d’une ou plusieurs organisations ;

Les ordinateurs sont connectés à l’aide d’un système de communication de données ;

Une BDD commune est partagée par toutes les BDD corporatives, mais des BDD additionnelles peuvent exister ;

Tous les ordinateurs sont coordonnés centralement à l’aide d’un plan de gestion de ressources d’information ;

Les opérations d’entrées/sorties sont effectuées au sein des postes utilisateurs.

Les trois principales topologies utilisées pour la communication sont la topologie centralisée, la topologie décentralisée et la topologie hybride. La topologie hybride représente une étape intermédiaire entre les deux autres topologies.

2.5.1.1 Architecture centralisée

Dans les structures hiérarchisées les différents centres sont coordonnés par une entité hiérarchiquement supérieure (Figure 3.4). Les prises de décision pour un niveau sont ici centralisées dans un centre coordinateur qui possède l’ensemble des informations nécessaires transmises par les centres qu’il supervise.

L’architecture distribuée de Turban est typiquement une topologie de réseau centralisé. Le principal avantage des systèmes centralisés est leur simplicité, qui est un facteur important pour le développement de DSS (temps de développement court et meilleure maniabilité). En outre, la topologie centralisée permet un contrôle aisé sur les données et les utilisateurs du

DSS. Cette centralisation de la décision permet aussi d’avoir l’assurance d’une cohérence des

choix. En revanche, une telle approche ne permet pas d’illustrer le caractère distribué des décisions que l’on rencontre dans une architecture industrielle quelconque. Par conséquent, il n’y a aucune tolérance aux fautes, aucune indépendance du lieu et faible extensibilité. Aussi, l’architecture repose sur une source centrale de synchronisation (figure 3.4). Bien souvent, le

central susceptible de rendre le système particulièrement fragile et de mettre tout le système hors-service face à une défaillance du composant central que cela soit local (comme une panne matérielle) ou externe (comme une panne réseau). En outre, l’évolutivité d’un tel système est limitée : l’augmentation de la capacité ne peut se faire que par un remplacement du composant central par un composant plus puissant. Dans le cas de certaines filières où l’intégration verticale est fortement présente, le réseau avec coordinateur peut s’avérer représentatif. COORDINATEUR CENTRAL DECIDEURS CARACTERISTIQUES Décideur 1 Décideur 2 ……….. Décideur N ……… ……… ……… ………

Décideur 1 Décideur 2 Décideur N

Figure 3.4 : Architecture centralisée

Parmi d’autres possibilités, deux topologies de réseau peuvent améliorer cette situation : une topologie décentralisée et une topologie hybride combinant des topologies centralisées et en anneau [Minar 02].

3.5.1.2 Architecture décentralisée

Dans l’approche distribuée, nous sommes en présence d’un réseau de centres de décision autonomes [Huguet 94]. Cette approche permet d’illustrer les contraintes à respecter dans un centre de décision qui découlent des centres amont et influent sur les centres aval. Si les contraintes appliquées à un centre sont trop restrictives, la décision est alors impossible. On parle alors de défaut d’autonomie. Dans ce cas de figure les centres amont ne pourront pas valider leurs décisions. La négociation pour la recherche d’une décision commune est alors initiée.

Contrairement à l’approche par coordinateur, cette approche permet par définition d’illustrer le caractère distribué des décisions. Les systèmes décentralisés (figure 3.5) ont presque exactement les caractéristiques opposées des systèmes centralisés. Ils sont tolérants aux fautes (dans une certaine mesure), indépendants du lieu et extensibles. En effet, l’extension du système peut être réalisée par l’ajout de nouveaux composants sans devoir suspendre le fonctionnement de l’ensemble. De même, la réplication des composants

fautes. En revanche elle demande la mise en point de méthodes spécifiques de gestion pour assurer une cohérence globale des différents choix. Le principal désavantage de cette topologie réside dans la difficulté à connaître et à maîtriser l’état du système : il est ainsi relativement difficile de gérer les autorisations d’accès et par conséquent difficile à implémenter.

3.5.1.3 Architecture hybride

Les topologies hybrides sont parfois utilisées pour traiter des cas relatifs à la synchronisation de données, la réplication de données ou équilibrage de la charge, mais celles-ci restent fortement basées sur des architectures centralisées traditionnelles. De plus, de telles topologies hybrides montrent qu’elles sont peu utiles dans des situations extrêmes.

Afin de résoudre ces problèmes, la topologie hybride isole quelques composants jugés « centraux » à l’architecture dans un anneau (figure 3.6). De cette manière ces composants sont clairement identifiés et donc plus faciles à administrer. Afin de ne pas mettre en danger l’ensemble du système en cas de panne de l’un de ces composants centraux, une certaine redondance des fonctionnalités et des connections est prévue.

Décideur 1 Décideur 2 Décideur 3 Décideur 3 Décideur 2 Décideur 1 Décideur 3 Décideur 1 Décideur 2

COORDINATEUR CENTRAL DECIDEURS CARACTERISTIQUES Décideur 1 Décideur 2 ……….. Décideur N ……… ……… ……… ……… Décideur 1 Décideur 2 Décideur 2 Décideur 1 Décideur 3 Décideur 3 Décideur 3 Décideur 1 Décideur 2

Figure 3.6: Architecture hybride

2.5.2 Les GDSS basé sur le Web

Les équipes virtuelles sont des groupes géographiquement dispersés de gens partageant un but commun pour réaliser des tâches interdépendantes en travaillant à des endroits différents. Elles utilisent l'ordinateur et les technologies de communication pour communiquer des idées et des informations, pour coordonner des activités et prendre des décisions. Pour travailler efficacement, les équipes virtuelles doivent utiliser des technologies du web pour surmonter les barrières spatio-temporelles qui affectent les sessions de prise de décision distribuées, augmenter la gamme et la profondeur d’accès à l'information et améliorer l'efficacité et la performance du groupe. Les technologies du web peuvent supporter le travail de groupe de quatre manières : la structuration des processus de groupe, support à la communication, l'amélioration du traitement de l'information et des capacités de modélisation.

Les systèmes d'aide à la décision de groupe basé sur le web sont des systèmes fondés sur les technologies du web où les utilisateurs accèdent avec des navigateurs du web via la

décision et la communication entre des équipes distribuées. Cependant, peu de GDSS à base du web sont disponibles en raison de la difficulté de construire des applications à base de web faciles à utiliser. En effet, le support à la communication interpersonnelle dans les technologies de collaboration à base du web existantes est limité aux forums de discussion, l'e-mail, la messagerie instantanée et les outils de conférence audiovisuels à base du web. Les outils d’aide aux équipes distribuées qui ont été empiriquement testés sont principalement des systèmes de conférences asynchrones (c'est-à-dire les logiciels de forum de discussion) ; ces systèmes ne supportent pas explicitement les processus de prise de décision et ne fournissent pas souvent d'outils pour l'évaluation des options alternatives.