Blog | Stratégie et analyses de données | | 4 min de lecture

Savoir qui est qui dans le zoo est important dans l'industrie de l'intégration des données

points du graphique de données

À mes débuts dans ce secteur, il y a une vingtaine d’années (je fais comme si j’avais encore la vingtaine, donc ce chiffre me convient bien), la plupart des grandes entreprises ne comptaient qu’un seul service informatique dirigé par un seul responsable. Aujourd’hui, on trouve plusieurs responsables au sein de différents services, dont certains relèvent de différentes divisions de l’entreprise. Certaines tâches sont externalisé, d’autres sont prises en charge en interne, et d’autres encore sont confiées à des prestataires.

Lorsqu'il s'agit de relier la plupart des systèmes entre eux, le secteur se concentre sur le fait « d'avoir un connecteur pour ceci ou cela », alors que la véritable difficulté réside dans la manière de se connecter à cette implémentation particulière de ce système.

Au fil des années, à mesure que les technologies ont évolué, les piliers (ou « silos ») des équipes ont eux aussi évolué. Ainsi, proposer une solution d’intégration permettant de relier plusieurs systèmes relève davantage d’un cauchemar en matière de gestion de projet (un véritable « parcours du combattant ») que d’un cauchemar lié aux connecteurs. Prenons l’exemple d’une entreprise de taille moyenne typique qui souhaite connecter ses applications cloud (CRM, RH, etc.) à ses sur site (SAP, Oracle Finance, Dynamics, bases de données, etc.). tâche assez simple, puisque nous disposons de toutes les options de connecteurs et que, dans le pire des cas, nous pouvons toujours nous rabattre sur un connecteur JSON/XML basé sur des services web et sur des connecteurs de bases de données. La question de savoir « disposons-nous d’un connecteur pour chaque système ? » est résolue en quelques minutes.

Le véritable problème, et ce qui nous fait perdre du temps, c'est de savoir comment établir la connexion et à qui nous allons accorder l'accès. Si l'on examine les différentes couches technologiques impliquées (en utilisant le modèle OSI comme méthode pour analyser les étapes d'accès) :

  • Couche physique - comment le serveur est-il connecté et quelles sont les limites de vitesse (le serveur est-il connecté ?).
  • Couche liaison de données - quel est le niveau de qualité de service dont nous disposons, y a-t-il des restrictions, sur quel VLAN nous trouvons-nous et à quoi ce VLAN a-t-il accès ou non ?
  • Couche réseau - pouvons-nous effectuer un test de réseau pour chaque système que nous devons connecter ?
  • Couche transport - pouvons-nous conserver une connexion et quelles sont les performances de cette connexion ?
  • Couche session - quels sont les mécanismes d'authentification de chaque système ? Pouvons-nous nous authentifier ?
  • Couche de présentation - pouvons-nous avoir accès aux métadonnées qui se cachent derrière chaque système ? Disposons-nous de droits suffisants ?
  • Couche application - Pouvons-nous voir un échantillon des données auxquelles nous nous connectons ? Les données ressemblent-elles à ce que nous attendions ? Pouvons-nous effectuer des mises à jour, des insertions, des remontées, des suppressions et des lectures ? L'application a-t-elle été personnalisée et pouvons-nous accéder à ces personnalisations ?

Pour y parvenir, il faut travailler avec différentes équipes informatiques, tant en interne qu'en externe. Il peut également être nécessaire de travailler avec des fournisseurs ou d'autres développeurs en dehors de l'organisation. Considérez les rôles suivants (liste non exhaustive) qui nécessiteraient de gagner leur confiance et leurs connaissances/assistance :

  • Gestionnaire de serveur/matériel - Serveur virtuel, capacité, installation de serveur.
  • Spécialistes des systèmes d'exploitation - Windows / Linux / AIX / etc. Capacité à faire fonctionner votre logiciel d'intégration ? Installation, correctifs et maintenance ? Accès à distance au serveur ?
  • Gestionnaire de réseau - Dans quelle zone le serveur a-t-il été installé ? A-t-il une connectivité avec chaque système ? Accès à distance au serveur ?
  • Sécurité/pare-feu - Quels ports sont verrouillés et doivent être ouverts pour ce nouveau service ? Le logiciel antivirus pose-t-il des problèmes ? Accès à distance au serveur ? Accès au serveur par le biais d'un navigateur ?
  • Spécialiste des applications en nuage - Méthode d'accès, sécurité, possibilité d'accès ? Peut-on se connecter ?
  • Administrateurs de bases de données - Accès aux bases de données, droits, tests simples de lecture des bases de données.
  • Applications spécialisées (développeurs SAP BAPI) - Certaines BAPI personnalisées doivent-elles être utilisées ? Quelles sont les BAPI standard qui ne doivent pas être utilisées ? Pouvons-nous utiliser l'application fat client/web pour visualiser et requête système ? Pouvons-nous utiliser un système de test/développement ?
  • Développeurs d'applications - Existe-t-il une méthode standard pour la collecte des exigences, la méthodologie de développement, les évaluations par les pairs, les tests d'acceptation par les utilisateur , les tests de système, les tests de charge ?

Lorsqu'il nous est demandé de prouver que nous pouvons nous connecter à un système, nous passons 90 % de notre temps à travailler avec les personnes susmentionnées et 10 % à effectuer la connexion proprement dite. Savoir avec qui travailler et gagner leur confiance et leur adhésion est le plus difficile.