Construire un modèle de la chaîne logistique logicielle

La représentation standard d'un flux de valeur de développement logiciel commence par le codage et se termine par le code en production. Vous voyez souvent des diagrammes devops qui commencent par «l'entreprise» et se terminent par «le client». Cependant, cette représentation ne reflète pas avec précision la complexité de la fourniture de logiciels à l'échelle de l'entreprise.

En prenant du recul, vous voyez de nombreuses autres activités impliquées dans la fourniture de logiciels aux clients, mais les approches actuelles de gestion de ces activités sont enracinées dans des cadres de prestation de services et non dans des modèles de production. En tant que tels, ils ne relient pas toutes les activités impliquées en un seul système de bout en bout.

Le modèle utilisé dans d'autres industries de produits est le modèle de chaîne d'approvisionnement, et en appliquant ce modèle à la livraison de logiciels, vous pouvez élargir votre compréhension du «système» de livraison de logiciels au-delà des devops, en vous donnant de nouvelles perspectives sur la façon de l'optimiser.

Quelle est la chaîne d'approvisionnement?

La chaîne d'approvisionnement commence par l'idée que vous pouvez coordonner toutes les activités de production et de non-production en un seul système. La gestion de la chaîne d'approvisionnement est souvent interprétée à tort comme étant simplement la «gestion des fournisseurs», alors qu'en réalité ce n'est qu'un aspect de la gestion de la chaîne d'approvisionnement (bien que critique).

Toutes les entreprises de produits et de services ont une chaîne d'approvisionnement, et les activités impliquées et leur importance relative pour le système de chaîne d'approvisionnement varieront. L'idée de base, cependant, est qu'en coordonnant ces activités comme un système unique, vous obtenez une valeur supérieure à la somme des parties et une livraison efficace de cette valeur aux parties prenantes.

Les activités suivantes ne sont que quelques-uns des aspects importants de toutes les chaînes d'approvisionnement, mais pour les logiciels, elles sont exécutées de manière unique:

Planification

Dans la chaîne d'approvisionnement traditionnelle, les activités de planification impliquent la coordination des actifs et l'optimisation du flux des processus pour équilibrer l'offre de matériaux et la demande de produits. Dans la chaîne d'approvisionnement des logiciels, cette coordination implique de s'assurer que le bon code est développé pour les fonctionnalités du produit les plus nécessaires. À grande échelle, avec des centaines d'applications et des milliers de développeurs de logiciels, il s'agit d'une entreprise monumentale.

L'étendue des activités de planification est souvent minimisée par les modèles devops existants. Il est donc quelque peu ironique que les grandes entreprises qui ont le plus besoin de développement doivent faire face à des obligations légales, réglementaires, contractuelles et clients qui rendent la planification longue et complexe. Une approche de la planification de la chaîne d'approvisionnement implique l'optimisation des interfaces entre les nombreux rôles et disciplines de planification impliqués, et un facteur clé de succès est de pouvoir les intégrer efficacement.

D'une part, les méthodologies agiles qui guident le développement dans l'entreprise sont souvent formulées dans des processus en cascade. Peu d'entreprises peuvent échapper aux cycles de planification fiscale, et les processus agiles peuvent contenir des abstractions qui entrent en conflit avec ces cycles; par exemple, les sprints peuvent ne pas s'aligner sur les limites des trimestres fiscaux. Le manque de communication et de connexions entre les processus de développement utilisant des activités agiles et non productives utilisant la cascade peut entraîner du gaspillage et une inefficacité dans toute l'entreprise.

D'un autre côté, la planification des produits d'entreprise a toujours impliqué des systèmes étendus de gestion des exigences et de traçabilité, et ce n'est pas différent pour les produits logiciels. La gestion des exigences est particulièrement critique dans les secteurs hautement réglementés tels que les soins de santé, où des logiciels peuvent être développés pour des dispositifs médicaux pouvant signifier la vie ou la mort des utilisateurs. La gestion des exigences implique des outils et des méthodologies spécialisés, et la capacité de retracer la fidélité et la qualité de leur mise en œuvre tout au long du cycle de vie du développement peut être essentielle pour les produits logiciels d'entreprise.   

Approvisionnement

Dans la chaîne d'approvisionnement traditionnelle, l'approvisionnement en composants implique la gestion des relations avec les fournisseurs et le développement de stratégies d'approvisionnement pour les pièces et les matériaux. Les logiciels reposent également fortement sur des composants d'origine - selon une étude récente de Sonatype, l'open source constitue désormais la majorité des produits logiciels: jusqu'à 80 à 90% du code des applications modernes provient de composants open source. Et ces composants créent des défis de gestion uniques.

Premièrement, il peut être difficile de décider comment déterminer la qualité des composants, de nombreux facteurs influençant les décisions telles que la consommabilité, les tests, la documentation, la communauté, le support et les tendances technologiques. Il est impératif d'avoir une stratégie et une approche claires pour sélectionner les composants.

Deuxièmement, comme le nombre de composants open source gonfle, même savoir ce qu'ils sont tous autorisés à gérer tous efficacement est un défi. Les chefs de produit et les ingénieurs doivent être très attentifs aux problèmes de licence et de sécurité. L'état de vos composants open source peut changer quotidiennement à mesure que de nouvelles vulnérabilités sont découvertes et que les responsables de la maintenance modifient leurs stratégies de propriété intellectuelle. Et les clients veulent savoir exactement ce qu'ils reçoivent - de nombreuses grandes entreprises n'achèteront pas de logiciel sans une nomenclature décrivant ce qu'il y a dans la boîte. La gestion de tous ces problèmes open source est un aspect central du développement de produits logiciels.

Distribution

Mettre le logiciel entre les mains des clients peut impliquer un réseau complexe de partenaires de toutes sortes: déploiement, distribution, intégration, revendeur; accords de toute nature: OEM, licences, NDA, RFP; réunions de toutes sortes: démos, PoC, présentations; et bien plus.

Ces relations servent d'entrées, de sorties et même d'étapes dans le processus de livraison du logiciel. L'état de l'une de ces relations peut avoir un impact direct sur les activités de développement. Sans les gérer de près et les relier au travail effectué, des déchets très tangibles se produisent.

Imaginez livrer une épopée pour un prospect qui est tranquillement devenu une opportunité perdue, ou déployer une fonctionnalité pour un partenaire qui a annulé son accord il y a un mois. Cela se produit régulièrement lorsque le logiciel est livré indépendamment du flux de valeur de l'entreprise, lorsque la fonction de livraison de logiciel n'est pas liée à la chaîne d'approvisionnement.

Le pipeline de devops doit être étroitement lié aux partenariats, accords et objectifs pour lesquels le travail est effectué. Le code peut être traçable et lié de l'histoire à l'exigence en passant par l'enregistrement client dans votre CRM, le tout en traitant votre livraison de logiciel comme une chaîne d'approvisionnement et en poursuivant une stratégie d'intégration.

Imaginez, à la place, pouvoir faire apparaître toutes les activités en cours exécutées pour un contrat spécifique, ou toutes les fonctionnalités prévues pour un nouveau client - c'est le résultat de la gestion de la chaîne logistique logicielle - visibilité et traçabilité tout au long du cycle de vie.

Outils

Bien que votre outillage de fabrication classique puisse consister en des machines de découpe et des fours de traitement thermique, la chaîne d'approvisionnement logicielle implique une classe d'outils (diversement appelés outils ALM, outils de cycle de vie ou outils devops) qui sont utilisés pour gérer les différentes étapes de la livraison du logiciel. .

La stratégie de gestion de ces outils est très différente de l'approche classique car l'investissement technique et intellectuel dans les outils de développement logiciel est énorme et très impactant. Ce type d'outil évolue également rapidement et est très fragmenté - les Jenkins d'aujourd'hui seront les Hudson d'antan. Une organisation doit être positionnée pour disposer d'une pile d'outils résiliente mais modulaire, qui fournit aux équipes ce dont elles ont besoin, tout en conservant la flexibilité nécessaire pour s'adapter.

De plus, la chaîne d'outils ne peut pas être déconnectée - elle doit faire remonter les informations en amont et en aval tout au long de la chaîne de valeur pour obtenir les connaissances là où elles sont nécessaires. Il est essentiel d'examiner également ce domaine du point de vue de l'intégration - comment pouvez-vous relier les activités d'une couche donnée aux activités de gestion de la chaîne d'approvisionnement environnantes et de soutien?

Conclusion

Les entreprises ont historiquement séparé la gestion de la technologie des secteurs d'activité générateurs de revenus, la traitant comme un ensemble d'activités de soutien motivées par des valeurs et des objectifs alignés sur la prestation de services. Dans un monde défini par logiciel, cependant, ce modèle d'entreprise ne convient plus.

La capacité de livraison de logiciels a quitté l'espace de support défini de manière classique et en est venue à définir toutes les activités principales génératrices de revenus.

Vous devez donc repenser votre modèle en tant que système de production et évoluer vers un modèle qui capture les relations de complexité entre les activités de chaîne de valeur. La chaîne d'approvisionnement incarne cette réflexion, et à mesure que la production de produits logiciels évoluera, nous verrons sûrement ce modèle mûrir.