9 questions à vous poser avant d’entreprendre un développement spécifique sur votre futur projet d’intégration de données

article in English

En tant que directeur marketing d’une entreprise proposant des solutions d’intégration de données, j’ai investi beaucoup de temps à convaincre les responsables des services informatiques de l’opportunité de passer du développement spécifique, à une approche basée sur des solutions. Voilà pourquoi j’ai découvert avec grand plaisir les conseils pratiques du rapport “Does Custom-Coded Data Integration Stack Up to Tools?”[1], publié récemment par Gartner.

Si vous vous apprêtez à travailler avec des nouvelles technologies Big Data et Cloud, ce rapport de Gartner présente de nombreux points importants à prendre en considération, mais il y a également d’autres questions sur lesquels vous devriez vous pencher avant de vous lancer dans tout projet de développement spécifique. Dans ce blog, je vous propose un résumé des principales leçons que j’ai tirées de cette étude, ainsi qu’une check list des questions que tout responsable IT devrait se poser au moment d’évaluer une approche basée sur du développement spécifique versus une solution d’intégration de données.

Mes principaux points à retenir du rapport  “Does Custom-Coded Data Integration Stack Up to Tools?”

. Assurez-vous d’avoir en vue tous les coûts, tant à court qu’à long terme : si une approche par développement spécifique permet de réduire globalement les coûts de 20%, les coûts de maintenance s’en trouveront augmentés de 200%.

. Il y a un temps et lieu pour le développement spécifique, mais seulement à certaines conditions : le codage manuel peut être un bon choix pour des projets simples et très ciblés qui ne nécessitent pas beaucoup de maintenance. Il pourrait aussi s’avérer nécessaire lors de situations où il n’existe pas de solutions capables de réaliser la tâche demandée. A noter, seulement 11% des entreprises interrogées par Gartner poursuivent le développement spécifique.

. Les projets d’intégration de données qui exigent plusieurs développeurs tireront parti des environnements de design visuel fournis par les solutions. Réutiliser des éléments issus de développements précédents sera donc plus facile, ce qui pourra déboucher sur des flux d’intégration de données plus efficaces. Cela est dû au fait qu’un seul job peut alimenter plusieurs cibles, au lieu d’avoir une série de flux d’intégration de données exécutant tous plus ou moins le même chose de manière répétitive.

. Il est important de comprendre les coûts de maintenance et de support associés à chaque projet.  Si plusieurs utilisateurs maintiennent et supportent le code une fois qu’il est en production, leur courbe d’apprentissage avec l’approche manuelle sera importante, et si le code est destiné à être utilisé pendant des années, le turnover du personnel entraînera à long terme une augmentation de ces coûts.

Compte tenu des considérations ci-dessus, j’ai conçu une check list de questions afin d’aider les responsables des services informatiques à prendre des décisions plus éclairées concernant l’approche à adopter.

La check list du développement spécifique :

1.  Est-ce que mon équipe de développeurs dispose des compétences nécessaires pour faire du développement spécifique ?

Si vous utilisez une nouvelle technologie comme par exemple Hadoop ou une plateforme Cloud, qui sera en charge du travail, et combien de temps de formation sera nécessaire ?

2.  Est-ce que je veux vraiment que mes experts du développement consacrent du temps à cette tâche ?

Les spécialistes du codage manuel constituant en général un quart de l’équipe de développement, ils sont donc une ressource rare. Si un développeur -non spécialiste- pouvait effectuer la même tâche en utilisant une solution, et en économisant ainsi des heures de travail, ne préféreriez-vous pas plutôt assigner aux spécialistes des missions nécessitant leurs expertises ?

3.  Est-ce que je peux effectuer le même travail avec une solution, de manière plus rapide et économique par rapport au développement spécifique ?

On demande sans cesse à la plupart des services IT de faire plus avec moins. Une approche basée sur des solutions permet souvent de réduire les coûts par développeur assigné à la tâche, et cela de manière plus rapide.

4.  S’agit-il d’un projet ponctuel, indépendant ou bien d’un domaine où je prévois du développement de plus en plus intensif dans le temps ?

Si vous vous lancez dans une initiative qui utilise une plateforme Big Data ou Cloud, il est probable qu’au fil du temps vous voudrez toujours en faire plus avec cette solution. Si tel est le cas, s’appuyer sur des experts du développement spécifique est une approche qu’il sera difficile de faire évoluer au vu de la pénurie de ces ressources.

5.  Quelle est la portabilité de ce code si je veux le ré exploiter sur une nouvelle plateforme comme Spark ou Flink ?

La portabilité est un sujet que l’on néglige facilement. L’écosystème Apache Hadoop évolue à une vitesse incroyable. Par exemple, en 2014 et en 2015, MapReduce était la norme. A la fin de 2016, la norme, c’est Spark. Si vous avez opté pour un développement spécifique, vous aurez constaté qu’il est impossible de migrer le code de MapReduce vers Spark. En revanche, les principales solutions d’intégration de données vous permettent de le faire, éliminant ainsi les problèmes liés aux codes préexistants.

6.  Est-ce que plusieurs développeurs collaboreront à ce projet ?

Comme déjà indiqué plus haut, dans le cas où plusieurs personnes sont dédiées à un projet, les avantages d’une approche basée sur des solutions sont nombreux, et incluent une réutilisation et un partage du code simplifiés, des environnements de design visuel, et même un support et des experts pouvant fournir des conseils aux développeurs.

7.  Pendant combien de temps ce code restera-t-il en production ?

Quand on s’engage dans un nouveau projet, il est tentant de se concentrer sur le temps nécessaire à sa mise en œuvre et de perdre de vue sa durée de vie. Souvent, un élément qui demande six mois de développement sera utilisé pendant cinq ans, voire plus. Si tel est le cas, les coûts de maintenance et de support du code continueront donc dix fois plus longtemps par rapport au temps de développement initial. C’est à cause de cet aspect qu’il est essentiel d’avoir une compréhension globale des coûts de maintenance et de support associés.

8.  Qui sera en charge de la maintenance de ce code ?

Si vous disposez seulement de quelques développeurs Spark, c’est à eux qu’il appartiendra de maintenir et supporter le code qu’ils ont créé. Au fil du temps, ces deux tâches absorberont toute leur capacité de travail, ce qui les empêchera de démarrer de nouveaux projets. A savoir, des missions susceptibles d’aider votre entreprise à obtenir un avantage compétitif.

9.  A quel rythme le code devra-t-il être mis à jour pour pouvoir répondre aux nouveaux besoins de l’entreprise ou s’adapter aux changements au niveau des cibles et sources de données ?

Les sources de données, les cibles et les besoins de l’entreprise sont en constante évolution. S’il est raisonnable de penser que ces éléments vont évoluer, alors il faut prendre conscience du fait que les coûts de maintenance et de support seront significativement plus élevés.


[1] “Does Custom Coding Stack Up to Data Integration Tools,” Mark A. Beyer, Ehtisham Zaidi, Eric Thoo, Gartner Research, Septembre 2016. 

 

Share

Leave a comment

Ajouter un commentaire

More information?