Construire une architecture décentralisée

Parmi les architectures existantes, l’architecture décentralisée est une forme hybride de plusieurs autres modèles. S’il n’est pas difficile à appréhender, ce modèle requiert néanmoins une bonne organisation pour pouvoir être efficace.

Nous allons voir dans cet article ce qu’est une architecture décentralisée, comment la mettre en place, mais aussi et surtout quels sont les écueils à éviter pour que votre projet ne se transforme pas en catastrophe.

Qu’est ce que l’architecture décentralisée?

Il s’agit d’un modèle d’architecture qui s’appuie sur les concepts d’architecture centralisée (un core model partagé par toute une organisation) et d’architecture spécifique (des fonctionnalités spécifiques à un domaine sont implémentés afin de répondre à tous les besoins).

De façon basique, il s’agit de développer une application qu’on déploiera sur différents sites.

L’intérêt de ce modèle est donc de centraliser les développements et de garantir que chaque site utilise le même logiciel.

Cela peut être très utile dans le cas d’une entreprise qui grandit, surtout si c’est par croissance exogène (rachat d’entreprise). Dans ce cas les processus sont généralement très différents et l’intégration de chaque nouveau site requiert l’adaptation de son système d’information à celui de la maison mère.

Ce modèle permet de plus de développer localement des modules spécifiques à un site. Dans ce cas, les modules seront maintenus localement et le core model centralement.

Dans ce cas, pourquoi utiliser une architecture décentralisée, et pas une interface web?

Prenons l’exemple suivant : une entreprise souhaite connecter ses sites industriels à une application, typiquement son ERP. Elle pourrait développer des fonctionnalités spécifiques directement dedans, mais cela aurait 3 contraintes:

– Les performances pourraient être affectées par le nombre grandissant d’utilisateur connectés;

– La maintenance serait plus difficile car la disponibilité de l’ERP deviendrait d’autant plus critique qu’il y aurait d’utilisateurs (imaginez une entreprise ayant des sites tout autour de la terre; fonctionnant 24h/24, les arrêtes seraient difficiles à planifier);

– Enfin le développement de modules spécifiques est souvent confronté aux limites imposées par l’outil lui-même. En effet, développer en spécifique dans un ERP requiert souvent de toucher au modèle standard, complexifiant la maintenance et les montées de version.

C’est donc pour toutes ces raisons qu’il est parfois judicieux d’ajouter un logiciel externe et de le déployer, tout en le connectant au système central. On retrouve alors les avantages de flexibilités, de performance et de maintenance qu’on aurait perdu sinon. De plus, la disponibilité est améliorer par le fait :

– L’application étant déployée localement sur plusieurs sites, si l’un d’eux s’arrête, les autres ne sont pas affectés.

– Les mécanismes de mise en cache permettent de continuer à travailler même si le système central n’est plus disponible; les données étant renvoyées automatiquement plus tard.

Comment définir une architecture décentralisée ?

Il faut distinguer les aspects fonctionnels et matériels:

Fonctionnellement

Le fait d’utiliser un core model impose de concevoir des processus qui seront suivis sur tous les sites. Cela nécessite donc de travailler de concert avec les key user qui sont les plus à même de connaître les points critiques de chacun de leur processus.

Attention toutefois, définir un core model ne signifie pas que chaque site utilisera toutes les fonctionnalités de celui-ci. Il existe de nombreux cas où il faudra créer 2 processus relativement semblable dans l’application, le premier correspondant à une partie des sites, le second aux autres sites. Néanmoins si ces 2 processus impliquent plus de développement, ils ont l’avantages de partager le même modèle de données et la plupart des fonctions transverses (synchronisation avec le système par exemple). C’est par exemple le cas de 2 sites réalisant des expéditions : certains utiliseront comme unité des unités de boite là où d’autres utiliseront des tonnes de kilo. Dans les deux cas, on retrouvera un certains nombres de variables communes (entête de facture, nom de l’employé, etc), mais on aura bien affaire à 2 processus différents (mettre des boites sur une palette n’implique pas les mêmes étapes que la pesée).

On cherchera quand même toutefois à agréger au maximum les processus pour faciliter la maintenance.

Techniquement

Déployer une application localement requiert nécessairement de posséder plusieurs serveurs, présents sur chacun des sites. On veillera donc à utiliser les mêmes serveurs partout, éventuellement en les dimensionnant différemment pour les sites hors normes ou dans les cas où l’élasticité prix du matériel est assez forte.

Il convient aussi de définir la granularité des besoins. En effet, déployer localement ne signifie pas forcément déployer sur chaque site physique, mais plutôt sur différents lieux représentants un tout cohérent. Par exemple, pour une application de ged, un déploiement par pays peut-être suffisant. A l’inverse, une application de gestion de production, utilisée massivement, sera plutôt déployée sur chaque site physique. Là encore évidemment, le coût est une variable importante.

Il ne faut pas non plus oublier de prendre en compte le matériel qui se connectera à l’application. Que ce soit les versions des os, les périphériques mobiles (téléphones, tablettes, rf gun), les imprimantes utilisées, lecteur d’empreintes ou autre, l’application devra être compatible avec tous. Il conviendra donc de s’adapter au matériel existant, mais aussi et surtout de spécifier les futurs matériels à acquérir, de façon à limiter les TU avant déploiement.

Comment déployer une architecture décentralisée ?

On utilisera la plupart du temps un site pilote, qui permettra de valider le logiciel. Suivront ensuite les autres sites. Le rythme de déploiement restera à la discrétion de chacun.

On veillera néanmoins à faire un master du site pilote, qu’on pourra ainsi copier sur les autres sites. En effet, même si les procédures sont bien suivis, il peut toujours arriver qu’une étape soient mal réalisée et qu’une installation échoue.

Déployer nécessite aussi de préparer les données nécessaires à l’exploitation. Veillez donc à prévoir assez de temps pour les préparer avec les métiers. On citera parmi les données critiques les login, le paramétrage propre au site (adresse de la base de données, traduction de l’application, etc) et bien évidemment les données propre à la production.

Enfin, et même si le déploiement s’est bien déroulée, tout n’est pas fini. En effet, n’oubliez pas que l’instauration d’une architecture décentralisée suppose des compromis sur les processus mis en place et que vous allez donc modifier les habitudes des personnes sur site. Il faudra donc suivre les utilisateurs pour s’assurer qu’ils ne rencontrent pas de difficultés à utiliser leur nouvelle application.

A ce titre, ne négligez pas la conduite du changement: un logiciel, même terminé, même coûteux, s’il est rejeté par ses utilisateurs, est un échec. L’entreprise n’hésitera pas à faire marche arrière si le sponsor conclut à la faillite de la solution. La réussite du projet passe donc par l’accompagnement des utilisateurs, ce qui signifie :

– Etre présent sur site lors du déploiement initial, afin de constater sur place les problèmes rencontrés et accompagnés les utilisateurs dans leur travail;

– Mettre en place un numéro de téléphone de support, affiché de façon claire et partout, pour que les utilisateurs ne sentent pas seul en cas de problème;

– Enfin, et surtout, les key user qui ont définis les processus doivent aller sur site, plusieurs fois si nécessaire, pour que les utilisateurs utilisent correctement l’application. La tentation est grande de ne pas déclarer correctement toutes les étapes d’un processus (surtout dans le monde industriel), ce qui peut entraîner des situations de blocage de l’application. On pourrait penser qu’il s’agit d’une faiblesse du logiciel, mais rappelez vous que la définition de processus commun impose des compromis. A ce titre, « blinder » l’application imposerait des coûts de développement exponentiels. L’accompagnement et la formation sont le meilleur moyen de palier à ce problème.

Comment maintenir une architecture décentralisée ?

La maintenance de l’application déployée n’est pas très compliquée lorsqu’il s’agit de simples montées de versions.

En revanche les évolutions impliquant la modification ou l’ajout de processus doivent être appréhender sérieusement. On recommandera alors, tout comme au début du projet, de réunir les key user pour appréhender les impacts des évolutions, ainsi que pour se mettre d’accord sur les nouvelles fonctionnalités à développer. Il n’est pas rare que beaucoup de sites aient des besoins différents : ce sera alors à l’entreprise de hiérarchiser ces besoins.

Enfin, le cas des montées de version du système centrale, s’il implique une modification du core model, est plus problématique. Dans ce cas encore une fois, le choix du planning d’arrêt de l’activité au niveau global sera laissé à la discrétion de l’entreprise.

=> En savoir plus sur nos offres de conseil en architecture