Ce billet a pour objectif de proposer un modèle de choix pour répondre aux problématiques de « Make or Buy » rencontrées lors des phases de conception d’une plateforme d’intégration, en entreprise, à savoir choisir une solution outillée du marché – qu’elle soit dans le « cloud » , open source ou non – ou bien choisir de bâtir une solution spécifique, et sur-mesure.
Cette notion de plateforme d’intégration est à rapprocher de la notion d’iPaaS[1] très en vogue actuellement, mais pour un usage interne à l’entreprise. Nous parlerons davantage de retours d’expériences que des aspects académiques, néanmoins nous donnerons une définition de plateforme d’intégration qui correspond au métier d’architecte d’enioka.
I) Plateforme d’intégration : kesako ?
Qu’est-ce qu’une plateforme d’intégration ?
Une plateforme d’intégration est un middleware, c’est à dire un logiciel d’infrastructure fournissant des fonctions d’intégration aux applications du SI, et dont la valeur ajoutée pour le SI est d’abstraire et de réduire la complexité liée aux chaînes de liaison techniques des échanges inter-applicatifs, en proposant des solutions « clés en main » pour les principaux cas d’intégration.
Le schéma ci-après illustre la position du middleware d’intégration dans l’architecture :
Quels sont les principales caractéristiques d’une plateforme d’intégration ?
Parmi les critères fondamentaux caractérisant un service middleware on retrouve toujours:
- l’interopérabilité inter-applicative, notamment sur la connectivité proposée aux applications, avec notamment des connecteurs pour l’intégration (annuaires, bases de données, outils MFT[2]/MOM[3]…) et une API[4] de développement pour l’intégration des applications,
- l’abstraction de l’hétérogénéité des infrastructures techniques sous-jacentes,
- le passage à l’échelle par administration et paramétrage plus que par développement logiciel.
Quels sont les enjeux de maîtrise de la complexité du SI ?
Un service middleware d’intégration répond à plusieurs enjeux de maîtrise de la complexité des SI :
- réduire les coûts et délais liés à l’intégration d’applications et formaliser des abaques,
- proposer une architecture d’intégration homogène,
- industrialiser la supervision et l’exploitation techniques de l’intégration,
- fonder des modèles d’architecture et de service d’intégration « clés en main ».
II) Identification des critères pour un choix « Make or Buy »
Nous nous proposons de sélectionner les critères déterminants pour décider de l’implémentation d’une plateforme d’intégration par un produit du marché ou par un développement spécifique.
La maturité technique du SI client
La maturité technique du SI client est un critère majeur de décision.
Si la maturité est faible, faire le choix d’un développement spécifique serait risqué, l’accent est donc généralement mis sur le choix d’un produit du marché, et une intégration faible de celui-ci au SI pour limiter les impacts. Et si les besoins en évolution des fonctions d’intégration sont méconnus, il est préférable de mettre en œuvre un développement spécifique léger en forme de prototype permettant aux équipes IT d’identifier les premiers éléments de complexité, et de faire évoluer la solution d’intégration avec les besoins des applications au fur et à mesure de la croissance du SI.
A l’opposé, pour un SI dont la maturité est forte, le choix portera davantage sur un outil du marché avec une forte industrialisation de son intégration au SI, ou bien sur un développement spécifique avancé pour une intégration «sur mesure».
La vitesse d’évolution du SI est également un paramètre à prendre en considération au regard du cycle de vie d’un produit du marché (nouvelles versions, support fin de vie). Par exemple, dans le cas d’un SI à évolution rapide – cas courant – un développement spécifique peut jouer un rôle de « joint de dilatation » entre les interfaces et les produits qui implémentent le service middleware et limiter les impacts de montée de version sur les applications du SI.
Le modèle technique de répartition
Le modèle technique de répartition est également l’une des clés de décision pour le choix. Une faible répartition correspond à un modèle client-serveur classique, avec une centralisation des fonctions d’intégration sur le serveur, et l’appel de ces fonctions par les clients. Une forte répartition correspond davantage à un modèle peer-to-peer qui permet à chaque client de disposer localement des fonctions d’intégration sans faire appel à un tiers sur le réseau.
Le modèle de répartition peut engendrer selon les produits du marché des coûts conséquents de licence (produits payants) et des coûts d’administration importants en cas de croissance rapide du SI.
La plupart des produits du marché proposent un modèle à faible répartition.
La complexité des chaînes d’intégration
Plus les chaînes d’intégration sont complexes (nombre d’étapes, nombre d’applications, topologie de la chaîne d’intégration, règles de gestion, hétérogénéité technologique, interactivité homme-machine, …) plus les contraintes sont fortes sur le service middleware. Rares sont les produits du marché capables de maîtriser de facto cette forte complexité tout en respectant les exigences de la Production. Il est souvent utile dans ce cas de fournir un développement spécifique qui implante du liant entre Intégration et Production.
Le choix d’un outil du marché – seul – ne permettra pas la flexibilité requise de bout en bout, et souvent l’intégration du « dernier kilomètre » est le maillon faible qui masque toute la valeur du middleware d’intégration. Par exemple, ce sujet est particulièrement visible lorsqu’il s’agit d’interfacer la chaîne d’intégration avec les outils de la Production (ordonnancement, supervision, …) et les différents outils métier, de bout en bout et de manière homogène!
Les compétences
Les compétences internes (ou externes) sont celles qui à moyen et long terme sont garantes, au quotidien, du maintien en condition opérationnelle du socle, et de l’accompagnement des projets jusqu’en production.
Dans ce contexte, le choix d’un développement spécifique est à proscrire si les équipes ne sont pas suffisamment formées pour le développement de services middleware complexes.
Par son positionnement dans l’architecture et dans les processus IT, un socle d’intégration est par nature à mi-chemin entre le monde des Etudes, et le monde de la Production. Afin de sécuriser l’avenir d’un développement spécifique, il est presque indispensable de recruter des compétences qui puissent comprendre ces deux mondes. Par exemple, une DSI qui ne dispose pas de ces compétences fera davantage le choix de l’achat d’un produit du marché.
A l’inverse, le choix d’un produit du marché peut nécessiter des compétences d’administration spécifiques, et donc des formations à prendre en compte lors de la contractualisation.
Les normes et standards des développements projets et de la Production
Les normes et standards des développements et d’infrastructure peuvent conditionner la décision. Il est nécessaire de contrôler que les normes en vigueur ne sont pas incompatibles avec la portabilité des développements sur le produit du marché et/ou sur son exploitation. En effet, il est fréquent dans un SI de voir tout un périmètre implémenté par un outil du marché qui ne respecte par les normes et standards définis en interne. Dans tous les cas, des exemples (ou templates) de développement respectant les normes et standards sont souvent les bienvenus pour montrer l’exemple aux équipes études.
La prise en charge de protocoles spécialisés
La prise en charge de protocoles spécialisés comme Odette FTP ou EDIFACT/EANCOM pour l’industrie, ou NOEMIE pour le secteur de la Santé, peut nécessiter le choix d’une solution du marché disposant du support intégré de ces protocoles. D’autant que l’implémentation de ces protocoles peut faire l’objet d’une certification par leur autorité de gestion ou tout simplement s’avérer coûteuse. A l’opposé, des protocoles standards et simples d’accès pour le développement logiciel comme FTP et HTTP/SOAP seront plus pertinent dans le cadre d’un développement « maison ».
Le modèle de coûts
Enfin, le critère coût restera déterminant pour le choix, avec un équilibre à trouver entre CAPEX et OPEX en fonction du budget. Il faut prendre en compte le cycle de vie « classique » d’un middleware d’intégration et projeter une vision d’architecture à 3-5 ans. Dans les deux cas, il y aura des postes de coûts en CAPEX et en OPEX.
Dans le choix « make », le CAPEX sera moindre la plupart du temps, parce que les coûts de licence des produits du marché sont encore importants pour ce type de service middleware, mais l’OPEX peut être en retour élevé (coût de maintenance logicielle). Néanmoins, dans le choix « buy », la problématique est la visibilité sur l’OPEX (coûts de maintenance et renouvellement de licences) dans une vision à 3-5 ans, ce qui n’est pas toujours simple en fonction du modèle de licence plus ou moins flou proposé par les éditeurs. Les solutions iPaaS dans le « cloud » peuvent à ce titre proposer une alternative avec un bon compromis, mais les offres restent encore un peu jeunes et ce choix pose de nouvelles questions en termes technique, fonctionnel, et financier.
III) Conclusion
En conclusion, bien que la notion de middleware ne soit pas nouvelle et que l’implantation de produits middleware dans les SI contemporains soit une pratique répandue de facto, le besoin d’adaptation et mise à niveau est toujours présent. Il n’y a pas de réponses à la complexité à travers un modèle unique de middleware. Les produits du marché ne satisfont pas toujours les contraintes et les exigences des entreprises et des organisations, qui doivent répondre à des problématiques techniques et humaines toujours plus ambitieuses. Et les solutions « cloud » qui se développent amènent de nouvelles solutions avec leurs contraintes spécifiques… Le choix est guidé en fonction d’échéances dans l’évolution du SI, de contraintes d’architecture, et de possibilité budgétaire de la DSI et de compétences.
[1] Integration Platform as a Service
[2] Monitored File Transfer
[3] Message Oriented Middleware
[4] Application Programming Interface