Exemples de dettes techniques dans la mise en œuvre de systèmes BI

Le développement et le déploiement de systèmes de BI est un processus assez rapide et bon marché, mais leur maintenance dans le temps est coûteuse. Cela peut être imaginé à travers la métaphore de la dette technique.

Dette technique - fait référence aux problèmes accumulés dans le code ou l'architecture du programme liés à la négligence de la qualité dans le développement de logiciels et entraînant des coûts de main-d'œuvre supplémentaires à l'avenir.

Il existe souvent des raisons stratégiques bien fondées pour contracter une dette technique. Toute dette n'est pas mauvaise, mais toute dette doit être remboursée. La dette technique peut être payée en refactorisant le code, en améliorant les tests, en supprimant le code mort, en réduisant les dépendances, en resserrant l'API et en améliorant la documentation. Le but n'est pas d'ajouter de nouvelles fonctionnalités, mais de permettre des améliorations futures, de réduire les erreurs et d'améliorer la maintenabilité. Le report de ces paiements entraîne des coûts complexes. La dette cachée est dangereuse car elle augmente silencieusement.

Exemples de dettes techniques en BI:

• Il existe un entrepôt de données dans le projet BI, mais en fait il s'agit d'une copie de la base de données de travail. Par conséquent, les avantages de stockage, tels que le taux de rafraîchissement des données, sont perdus et les données peuvent être perdues ou endommagées.
• Lors du chargement et de la mise à jour des données (ETL), les données ne sont pas vérifiées / corrigées. Les erreurs sont transférées vers l'application.
• Les noms de champs et de variables non optimaux rendent l'édition et l'utilisation de l'application difficiles à l'avenir.
• Un modèle / une structure de données initialement mal sélectionnés de l'application entraîne des problèmes lors du fonctionnement et de la modification de l'application.
• BI , , ( ). , .
• BI — . BI. , - .
• , , ().
• BI, , - , .

Seule la connaissance de cela, malheureusement, ne fournit aucune mesure de gestion. Comment mesurer la dette technique dans un système ou estimer la valeur totale de cette dette? Le fait que l'équipe travaille toujours n'est pas la preuve d'un faible niveau d'endettement, car la valeur totale de la dette n'apparaît qu'avec le temps.

Quelques questions utiles à considérer:

1. Est-il facile de tester complètement un algorithme entièrement nouveau pour calculer les métriques?
2. Dans quelle mesure l'effet d'un nouveau changement dans un système peut-il être mesuré avec précision?
3. À quelle vitesse les nouveaux membres de l'équipe peuvent-ils se mettre à jour?

Nous espérons que cet article pourra servir d'incitation à de nouveaux développements dans le domaine de la BI, y compris l'amélioration des méthodes de test, des modèles de conception, etc. Mais le point le plus important est que la dette technique est un problème dont les programmeurs et les gestionnaires doivent être conscients.