Considérations clés pour évaluer un logiciel et garantir une meilleure expérience à long terme.

La quête de la transformation numérique s'étend sur des décennies, mais sa réalisation demeure un rêve en partie inachevé. D'un côté, les solutions logicielles d'entreprise sont de plus en plus puissantes, avec des interfaces qui impressionnent et des performances bien supérieures à celles de leurs prédécesseurs. L'adoption généralisée des logiciels de gestion de la relation client (CRM) a, dans une certaine mesure, transformé les fonctions en contact avec la clientèle grâce à l'amélioration des fonctionnalités et de la connectivité avec les plateformes de messagerie, de communication et de facturation. Ce n'est qu'un exemple d'une technologie métier essentielle qui est devenue une source unique de vérité au sein des organisations. D'un autre côté, toute application logicielle bien conçue aura un périmètre fonctionnel limité, ce qui signifie qu'inévitablement, les organisations possèdent généralement un écosystème complet de solutions répondant à divers besoins.

La quête d'un écosystème logiciel intégré : défis entre les silos logiciels et l'intégration transparente

Compte tenu de la prévisibilité de ce phénomène d'écosystème et du temps que le concept de « transformation numérique » occupe l'esprit des professionnels de l'IT et du business, il est assez surprenant de constater à quel point cet univers est souvent fragmenté. Les silos d'information nécessitant une synchronisation manuelle avec les systèmes sources de référence sont plus la norme que l'exception.

Bien que certains éditeurs vantent des stratégies de connecteurs « plug-and-play » avec d'autres logiciels, celles-ci s'accompagnent souvent de mises en garde qui mènent à une réalité décevante. La réalité attendue est que les organisations utilisent une pléthore de solutions au sein d'une même entreprise. Au sein d'une catégorie de solutions logicielles, il existe généralement une abondance d'applications détenant des parts de marché significatives. Combiné au fait que les logiciels évoluent fréquemment, nécessitant des mises à jour des connecteurs, les limites de l'approche par connecteurs prêts à l'emploi deviennent évidentes.

La tendance prédominante du secteur évite les gadgets (*widgets*) et privilégie le développement de logiciels disposant à la fois d'interfaces pour l'utilisateur final et d'interfaces basées sur du code. L'approche privilégiée pour ces dernières est l'interface de programmation d'application (API). Moyen de communiquer avec un système en langage informatique, les API permettent à deux systèmes d'échanger via une application personnalisée. Une telle application orchestre le flux et la transformation des informations, et ce, dans des conditions métier précises adaptées aux besoins de l'organisation. Acquérir un logiciel critique dépourvu d'API et impossible à « intégrer » est probablement une mauvaise décision d'entreprise, risquant de condamner les équipes à une maintenance manuelle des données dans différents systèmes — un effort humain à faible valeur ajoutée et à haut risque d'erreur.

Naviguer dans la complexité des API

Naturellement, toutes les API ne se valent pas. Historiquement, les projets logiciels internes échouent ou n'aboutissent pas plus souvent qu'ils ne sont adoptés, en partie à cause des difficultés liées à l'utilisation d'API inadaptées à la tâche qui leur est assignée. Voici quelques considérations pour évaluer un logiciel afin d'obtenir une meilleure expérience d'intégration :

1. Les API doivent être faciles à comprendre, rédigées dans le langage métier que l'application supporte, et permettre les actions que les utilisateurs finaux réalisent avec l'application. Cette caractéristique réduit les frictions liées à la traduction des besoins métier en code — et permet aux développeurs de « parler » le langage métier dans leur application personnalisée.
2. Les API doivent être bien documentées. Des portails de documentation interactifs qui décrivent entièrement les entrées, sorties, paramètres et critères de réponse — comme ceux compatibles Swagger — sont indispensables. La documentation doit révéler les meilleures pratiques, et pas seulement les pratiques nécessaires, pour utiliser les méthodes pertinentes dans un projet. Le portail API doit permettre aux développeurs de tester les API sans écrire de code, et ainsi d'évaluer leur utilité avant d'investir du temps et des efforts dans une tentative d'intégration.
3. Les API doivent être bien supportées par l'éditeur. Tant pour répondre aux erreurs inattendues pouvant indiquer un problème système, que pour fournir des conseils sur leur utilisation optimale et la plus efficace, les éditeurs de logiciels doivent aider leurs clients à tirer le meilleur parti de leurs API, dès la conception et après le déploiement.

Faciliter une intégration transparente

Les API InvestorVision™ s'inscrivent dans la longue tradition de support aux interactions automatisées avec les solutions SS&C Intralinks. Conçues pour supporter le reporting investisseur, les API InvestorVision reflètent les processus métier que l'interface web supporte et ajoutent des couches d'abstraction puissantes pour optimiser l'efficacité du code.

Soutenues par une équipe d'assistance primée et guidées par les conseils d'un groupe de services professionnels disposant d'une expérience approfondie des API Intralinks, nos clients peuvent mettre efficacement sur le marché des solutions basées sur les API rapidement, en faisant les choses correctement dès la première fois.