Développement orienté-service, le meilleur des deux mondes

Voir la version AMP

Devriez-vous commencer, à titre de Directeur TI, à penser en termes de Développement orienté-service plutôt que de Développement d’application ou encore d’achat d’un logiciel commercial ?

La question mérite d’être posée car, étonnamment, bien que nous ne cessions de vanter les mérites du Développement Agile depuis plus d’une décennie, le fait est que, la majorité des grandes et moyennes entreprises se lancent encore de nos jours à grands frais dans des projets TI lourds, à longue échéance, en s’appuyant sur des plateformes reconnues telles SAP ou Oracle ou en s’appuyant sur des logiciels commerciaux.

Nous comprenons très bien le dilemme auquel sont confrontés les Directeurs TI (CIO / CTO) qui les amène à penser, parfois à tort, que la notoriété d’un logiciel reconnu constitue nécessairement une garantie de performance et de sécurité (pérennité).

Ayant réalisé au cours des 30 dernières années à la fois du Développement d’applications sur mesure et du Développement sur des plateformes Microsoft déjà en place, nous comprenons très bien le risque que représente un Développement logiciel sur mesure quand une entreprise a déjà investi des sommes importantes sur une plateforme donnée ou dans une solution maison critique.

Cependant, quand le projet TI n’est pas la refonte d’un système existant mais bien un projet pour répondre à de nouveaux besoins d’affaires, nous avons pris une autre tangente depuis quelques années parce qu’elle nous est apparue plus avantageuse à la fois pour le client et le développeur, une troisième voie entre le Développement logiciel sur mesure et le Développement Microsoft pur; le Développement orienté-service.

Les principes du Développement orienté-service

Alors que le Développement d’application sur mesure permet une très forte adéquation (développement des fonctionnalités) aux besoins et objectifs visés, celui-ci constitue un risque appréciable en termes de pérennité de services et de coûts de développement.

D’un autre côté, le logiciel commercial entraîne souvent des coûts d’adaptation pré-installation faramineux et un coût récurrent de licence.  De plus, toute personnalisation de fonctionnalités entraînera elle aussi des coûts supplémentaires parfois importants et la fin de l’évolution du logiciel dont la version devient alors figée dans le temps.

La 3e voie que nous préconisons, le Développement orienté-service, offre à notre avis le meilleur des deux mondes.

Notre Développement orienté-service s’appuie sur trois principes :

  1. développement par itération, en parallèle
  2. architecture orientée-service
  3. architecture « platformless »

Développement par itération, en parallèle

D’une part, l’exécution de ce que nous appelons le Développement orienté-service se fait en réalité en parallèle des systèmes et applications en place avec lesquels ils devront communiquer.  Elle peut même se faire en marge des infrastructures TI en place, par l’utilisation du Cloud.

D’autre part, le développement est orienté « fonction »; le développement se fait en étapes, par itération de fonctionnalités répondant à des besoins spécifiques, au fur et à mesure qu’elles sont requises dans le temps.

Architecture orientée-services

Notre approche vise à travailler en services et à favoriser la réutilisation des services existants (fonctionnalités déjà en place). Nous avons designé une architecture « multi-couches » qui communique avec les services déjà en place (via des API) et met en scène notre catalogue de services.

Architecture platformless

Les services développés ne sont plus dépendants d’un environnement spécifique, Windows, Cloud ou Linux. Pour ce faire, nous faisons appel au protocole « low-level » REST et au nouvel environnement de développement « .Net core 2 ».

Ainsi, les services développés seront hébergés dans le Cloud mais ils pourraient tout aussi bien être hébergés soit chez le client, soit chez un hébergeur.

Bénéfices du Développement orienté-service

L’architecture orientée-services permet au directeur TI de répondre à des besoins d’affaires auxquels les systèmes en place ne répondent pas et qui seraient trop longs ou même trop risqué (gestion des versions futures) de développer à même ses propres systèmes.

Cette architecture responsabilise l’injection de nouveaux fonds dans les TI car elle permet le développement de nouvelles fonctionnalités en utilisant les toutes dernières technologies et elle lève les barrières imposées par les systèmes en place qui oblige non seulement l’utilisation d’une technologie donnée mais généralement une version spécifique de cette technologie, qui soit dit en passant, n’est souvent pas récente.

Le développement en parallèle et par étapes préserve l’intégrité des systèmes en place et donc, leur évolution future, tout en minimisant les risques de dépassement des coûts et de non adéquation des livrables.

Le développement en parallèle et par étapes se veut sans conteste la meilleure solution pour offrir et profiter rapidement de nouvelles fonctionnalités tout en minimisant les risques et les coûts associés au développement.

L’architecture orientée-services préserve l’intégrité des systèmes et applications en place et garantit ainsi leur évolution future (mises à jour et mises à niveau).

L’architecture « platformless » ne contraint plus le directeur TI à faire le choix d’une plateforme ou encore d’un type d’hébergement.

Conclusion

Soyons honnêtes, à l’heure de la compétitivité globale, de la performance, de l’agilité et de la qualité sur tous les plans; quelle entreprise peut encore se payer le luxe d’infrastructures TI lourdes, à frais récurrents, et n’offrant pas toutes les fonctionnalités dont elle a besoin pour compétitionner et performer, là, maintenant ?

 

Denis Paul & Michel

Laisser un commentaire

Votre adresse de courriel ne sera pas publiée. Les champs obligatoires sont indiqués avec *