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

Back when I started off in the industry, some 20-something years ago (I do pretend I am still in my 20s, so that number has a nice ring to it), there was only one IT Department with one manager in most large organizations. Now there are multiple managers within different departments, some aligned to different parts of the organization. Some pieces are outsourced, some in-sourced, and some have contractors working on it.

When it comes to connecting most systems together, the industry is focused on “having a connector to this or that,” while the real hard part is how to connect to that particular implementation of that system.

As the technologies evolved over the years, the pillars (or silos) of teams evolved. So providing an integration solution to connect multiple systems is more of a project management (herding cats) nightmare than a connector nightmare. Let’s take a typical mid-sized company that wants to connect its cloud-based applications (CRM, HR, etc.) to its on-premises applications (SAP, Oracle Finance, Dynamics, Databases, etc.). Pretty simple task, as we have all the connector options, and in the worst case we can always fall back on a web-service-based JSON/XML connector and database connectors. The problem of “do we have a connector to each system” is solved within minutes.

The real problem and the time killer is how to connect and to whom we will give access. If we consider the layers of technology involved (taking the OSI model as a method of stepping through access):

• 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.

À propos de l'auteur

À propos de Actian Corporation

Actian permet aux entreprises de gérer et de gouverner leurs données en toute confiance, quelle que soit leur ampleur. Les organisations font confiance aux solutions gestion des données d'intelligence des données d'Actian pour rationaliser leurs environnements de données complexes et accélérer la mise à disposition de données prêtes pour l'IA. Conçues pour être flexibles, les solutions Actian s'intègrent de manière transparente et fonctionnent de manière fiable dans les environnements sur site, dans le cloud et hybrides. Pour en savoir plus sur Actian, la division données et IA de HCL Software, rendez-vous sur actian.com.