Architecture soa (architecture orientée services)

n(n-1)

2

où n représente le nombre d'applications, soit dans ce cas (7 applications) : 21 liens.

Ce syndrome dit « spaghetti » est d'autant plus fort qu'il est constitué de technologies bien différentes (Transfert de fichiers, Echange de messages, Alimentation de Datawarehouse, Réplication de données etc ...). Il illustre diverses problématiques : codage de la transcodification des données et de la transformation de leur structure, redondance des données dans plusieurs référentiels, vue d'ensemble difficile à obtenir, sécurisation inexistante des flux, difficulté à passer en temps réel ...

1.4.2 ETL

Illustration 5 : ETL : le plat de spaghettis semble plus organisé

Une fois le « business Model » en place, les DSI sont amenées à justifier davantage le retour sur investissement des nouvelles solutions à déployer. Les impacts sur les développements, la maintenance et le déploiement sont alors regardés à la loupe. Les années se succédant, il faut aussi se soucier de l'intégration du « Legacy system »^2(*) dans une architecture en pleine mutation. La cartographie macroscopique des applications permet au Directeur Informatique d'optimiser et de construire sa stratégie tout en l'expliquant à la Direction Générale. Les applications de gestion ne sont plus suffisantes pour répondre au besoin des utilisateurs et il faut y ajouter de la valeur, c'est à dire des outils de pilotage car la vue verticale de l'entreprise ne permet pas d'analyser transversalement les différentes activités ou métiers. C'est pour répondre à ce dernier besoin, qu'ont été conçus les datawarehouses^3(*). En conséquence, les échanges de données deviennent plus importants et nécessitent des outils capables de gérer le référentiel des données hétérogène de l'entreprise. C'est dans ce contexte que s'installent dans notre quotidien les ETL^4(*) (en 1997, date du premier brevet déposé) mais dans la première moitié des années 90 pour d'autres solutions non brevetées. Leur vocation est de traiter de gros volumes d'échanges en mode différé, souvent la nuit ou tout au moins, pendant les heures creuses, en mode batch. La problématique des données hétérogènes est prise en charge par les nouvelles fonctionnalités graphiques de mapping de données et par des modules de connaissance internes permettant tout aussi bien d'interagir sur des bases de données différentes (Oracle, Sybase, SQL Server ...) que sur des fichiers à plat (CSV) ou propriétaires (EBCDIC, RMS...). Chaque application est connectée à l'ETL et forme un tout, sans avoir à connaître la topologie globale du système. La responsabilité est laissée à la couche broker qui gère la connexion de chaque application. Le développeur d'interfaces commence à disposer d'une vue unique, toute modification dans un des modèles de données pouvant faire l'objet d'une mesure d'impact sur l'ensemble du système. Les premiers scénarios d'intégration^5(*) sont mis en oeuvre, permettant d'encapsuler des modules de traitement

de façon « intelligente » (notion d'interfaces packagées, avec boucles et conditions).

Illustration 6 : Constitution d'un ETL

* ² Legacy System : vieux Mainframe plébiscités par les utilisateurs, difficile à remplacer.

* ³ Datawarahouse : entrepôt de données qui se caractérise par des données orientées « métiers » non volatiles présentées selon différents axes d'analyse ou « dimensions ».

* ⁴ ETL (Extract, Transform and Load) : technologie informatique permettant d'effectuer des synchronisations («alimentation », « extraction », « transformation », « constitution » ou « conversion », souvent combinés) massives d'information d'une base de données vers une autre.

* ⁵ Exemple des package d'interface Sunopsis (depuis la version 2 en 1999).