AXOPEN

SOA et la nécessité de construire un SI transverse

La gestion du SI des entreprises représente un budget conséquent pour celle-ci. Les banques et assurances par exemple y consacrent 4 à 5% de leur chiffre d’affaire. La construction d’un SI transverse permet aux entreprises de réaliser des économies sur l’évolution et la maintenance de leur système en facilitant la réutilisation et en diminuant la complexité de celui-ci.

Sous-chapitre 1 – L’intérêt de la mutualisation

Le système d’information reste en soi un ensemble homogène d’applications, seulement si les applications ont été développées ou sont en tant que telles développées sur la base de standards permettant la réutilisation. Il est possible alors pour tout nouveau développement de se baser sur des composants existants exposés par les applications qui couvrent un besoin métier proche.

Le développement d’une application devient alors plus proche de l’assemblage d’appels à des composants existants ou nouveaux, plutôt qu’à l’écriture de traitements sombres et obscurs.

L’entreprise retrouve par la même occasion une meilleure vision de son système d’information. Elle retrouve des métriques utilisables en comptant le nombre de services de types règles métiers, interfaces, données de références…

La mise en place d’un SI transverse facilite grandement cette réutilisation des composants en offrant un socle technique sur lequel s’appuyer. Outre l’aspect financier qui devient une évidence pour bon nombre de décideurs, la mutualisation de composants du SI permet notamment :

  • Une rationalisation du SI : La mutualisation des fonctions redondantes sous forme de composants réutilisables entraîne in fine une réduction des coûts de développement puisque l’on développera une seule fois le composant pour qu’il soit utilisé par plusieurs applications mais surtout une réduction des coûts de maintenance évolutive et/ou corrective puisque lors d’un besoin de maintenance sur cette fonctionnalité, seul le composant mutualisé sera modifié contre ses x versions auparavant. Par ailleurs, la gestion du SI à une maille plus petite (découlant du fait de travailler au niveau composant et non application lors des études sur le système d’information) entraine une diminution de la complexité globale de gestion, puisqu’il sera possible de versionner désormais les composants sans toucher aux applications lors de tout nouveau besoin métier.
  • Une augmentation de sa souplesse : Cette gestion du changement, réalisée par composant permet de diminuer les temps de cycle projet puisque l’on s’occupera de modifier uniquement les composants dont les règles métiers évoluent et ainsi cibler notre action (contrairement à une gestion du changement par application). Cette agilité permettra alors d’obtenir un alignement plus rapide sur le métier lors d’une évolution de celui-ci (avantages concurrentiels, évolutions de la réglementation…). Lors de l’appel à un composant existant depuis une nouvelle application les bonnes pratiques impliquent l’externalisation des aspects organisationnels du système dans un fichier de configuration prévu à cet effet. Il s’agit principalement de l’adresse du composant dans le système d’information (exemple : URL). Cette bonne pratique permet alors de modifier facilement l’adresse d’un composant lors de son déplacement ou de sa duplication ou bien d’utiliser une version différente de celui-ci lorsque cela est nécessaire. La standardisation des interfaces d’échange apportée par certains standards (HTTP, SOAP, XML…) permet d’accélérer grandement la mise en place de tout nouveaux canaux de communication (interne, e-commerce…). Cette augmentation de l’interopérabilité est visible aussi lors de tout changement dans le système d’information (ajout d’un nouveau progiciel, développement d’une nouvelle application…).
  • Une pérennisation des investissements : La facilité d’exposer des fonctions existantes sous forme de composants permet aux entreprises, dont le système d’information est majoritairement constitué d’applications issues de leur patrimoine applicatif (legacy, mainframes…), de pérenniser au maximum ce patrimoine. On peut citer notamment les banques pour lesquelles on estime à l’heure actuelle que leur système d’information est constitué pour 60% d’applications antérieures aux années 1980. Dans ces sociétés, cette capacité permet de réutiliser une partie de ce patrimoine existant dans de nouveaux contextes d’utilisation (site de gestion, e-commerce…).

En conclusion, la mutualisation des composants du SI permet aux entreprises qui la mettent en pratique d’augmenter l’agilité de leur système d’information, et donc sa capacité à évoluer rapidement et à faible coût tout en réduisant les coûts de développement et de maintenance. Et ce, grâce à la rationalisation du SI, rendue possible par la réutilisation de composants développés récemment mais aussi de programmes issus du patrimoine de l’entreprise.

Périmètre de la mutualisation

Une application informatique peut être vue comme un ensemble de traitements ayant pour rôles :

  • De proposer une couche de présentation aux utilisateurs (IHM pour Interface Homme Machine).
  • De permettre l’accès à du contenu non structuré (vidéos, images, documents…).
  • De permettre l’accès à des données structurées (données transactionnelles comme par exemple les commandes et données référentielles telles que le référentiel des produits).
  • D’exécuter des règles métiers et retourner le résultat en fonction du contexte (si age_client < 21 et conduite_accompagnee == faux alors tarif = maximum).
  • De réaliser l’orchestration entre plusieurs traitements et/ou services de l’application et/ou du SI de l’entreprise (par exemple processus de commande).
  • De permettre l’interfaçage avec le reste du SI ainsi que le SI des clients, partenaires ou fournisseurs (par exemple un lien est souvent nécessaire entre l’application de gestion des clients et celle de gestion des commandes).

Forts de ces différents rôles, les traitements contenus au sein d’une application doivent être de préférence développés avec des outils et des normes permettant de faciliter la réutilisation et le couplage lâche (limitation de l’impact d’un changement grâce au contrat d’interface standardisé).

Figure : Liste des traitements mutualisables dans un SI

Le nombre de composants mutualisables augmentant de manière importante, au sein des entreprises mettant en œuvre une démarche de mutualisation, il devient alors primordial de disposer d’un système de supervision / gouvernance du SI capable d’offrir une vision exhaustive des différents composants réutilisables et de leur rôle au sein du SI.