Les débuts du développement et de l'évolution des logiciels
Dans les années 1980-1990, à l'époque du développement de logiciels, les outils et les architectures utilisés par les développeurs rendaient difficile le partage efficace du code. L'utilisation de fonctions et de procédures a évolué vers des constructions orientées objet qui ont aidé les développeurs à considérer les solutions qu'ils mettaient au point comme une série d'objets reliés entre eux. Ces objets construisent la solution et améliorent la capacité à partager le code.
Au fil du temps, ce concept a évolué pour devenir l'architecture orientée services. Ces architectures orientées services ont non seulement créé des constructions autonomes, mais elles ont également facilité l'accès à d'autres systèmes qui souhaitaient utiliser la fonctionnalité.
Les concepts ont continué à évoluer vers des architectures de microservices qui ont simplifié le déploiement et la gestion des éléments constitutifs de la solution. Ensemble, ils permettent une architecture dans laquelle les développeurs peuvent facilement et en toute sécurité intégrer de nouveaux composants dans leur solution.
Au fur et à mesure que les architectures évoluaient pour promouvoir une réutilisation du code meilleure, plus flexible et plus sûre, l'état d'esprit des développeurs concernant le partage de leur code a évolué et mûri.Les développeurs gardaient leur code secret, allant même jusqu'à l'obscurcir pour empêcher les autres d'utiliser ce qu'ils avaient créé.
Avec l'acceptation du code modulaire, les développeurs ont commencé à se pousser les uns les autres à créer du code réutilisable. Les développeurs se sont sentis à l'aise avec les autres développeurs de leur organisation qui construisaient à partir de leur code et l'amélioraient.Ce changement d'état d'esprit a donné lieu à la participation au code source ouvert, mais principalement pour des projets personnels - pas pour un véritable code de qualité de production, et pas non plus pour un code commercial.
Au fur et à mesure que les architectures permettaient des techniques de partage plus efficaces, les développeurs (et leurs organisations) ont commencé à se sentir à l'aise avec l'utilisation du code source ouvert. Aujourd'hui, certaines des plus grandes entreprises de développement de logiciels commerciaux ne se contentent pas de partager leur code ouvertement, mais apportent souvent d'importantes contributions à la communauté des logiciels libres et tirent parti des contributions de la communauté pour étendre les capacités de leurs solutions.
Maturation et évolution de l'état d'esprit du développement logiciel
La maturité des architectures est allée de pair avec la maturité de la profession de développeur.Cela a conduit à un changement fondamental dans le débat achat/construction.
Au cours des décennies précédentes, les développeurs pouvaient envisager d'utiliser un cadre pour fournir des fonctionnalités clés au sein de leur solution.Certaines équipes de développement envisageaient d'acheter une solution et de l'intégrer à cette solution pour fournir les fonctionnalités dont elles avaient besoin. Cet état d'esprit "acheter au lieu de construire" était considéré comme une bonne alternative.
Cependant, elle entraînait souvent des coûts importants lorsque la solution évoluait et changeait radicalement. L'équipe de développement passait alors beaucoup de temps à faire fonctionner sa solution avec la solution sous-jacente, au lieu de passer du temps à créer les fonctionnalités dont l'entreprise avait besoin.
L'évolution de la discipline du développement logiciel s'est accompagnée d'une évolution des approches de l'achat par rapport à la construction.Au-delà des simples cadres, les solutions actuelles englobent des offres de services, des solutions SaaS, des plateformes et des combinaisons de chacune d'entre elles (plateforme Salesforce, Microsoft Dynamics 365, etc.).
Avec la facilité d'intégration des solutions basées sur le cloud, la question de l'achat ou de la création n'est plus une décision binaire.Il s'agit plutôt d'une décision basée sur les parties de votre système que vous souhaitez acheter et sur celles pour lesquelles vous devriez dépenser du capital.
Improving aide régulièrement ses clients à répondre à ces questions. Nous avons constaté que les équipes qui adoptent des architectures de microservices sont beaucoup plus efficaces pour intégrer des capacités de solutions basées sur le cloud dans leurs solutions.
L'expérience acquise dans la décomposition d'une solution en composants clés permet à ces équipes d'identifier les parties de leur système qui peuvent être efficacement fournies par des solutions déjà construites.De cette façon, les équipes peuvent se concentrer sur les valeurs commerciales clés de leur solution et développer un code qui est vraiment un facteur de différenciation pour leur entreprise.
Solutions logicielles modernes
Chez Improving, nous avons vu certains clients se débattre avec les détails de la solution tierce qu'ils choisissent d'intégrer.Trop souvent, les équipes de développement se focalisent sur la façon dont la solution fournit ses capacités et commencent à chercher des moyens de la contourner.
Il est important que les équipes se concentrent sur ce que la solution apporte, et non sur la manière dont elle l'apporte. Si vous avez un problème spécifique concernant le "comment" de la solution (par exemple, des problèmes de sécurité particuliers), n'attendez pas du fournisseur qu'il modifie la solution pour répondre à vos besoins. Cherchez plutôt d'autres solutions qui répondent à vos exigences en matière de "comment".
Ne passez pas beaucoup de temps à essayer de contourner le "comment". Si vous ne pouvez pas accepter la façon dont il fonctionne, trouvez un autre fournisseur ou réévaluez si le "comment" est vraiment important pour votre solution. Dans certains cas, ce "comment" peut être votre sauce secrète - les aspects qui rendent votre entreprise différente des autres et la raison pour laquelle vous devriez la construire.
En résumé : construire ou acheter ? Les deux !
La technologie du cloud et les architectures de microservices ont simplifié la décision d'acheter ou de construire. Ces changements ont permis aux équipes de développement d'intégrer efficacement les solutions.
Dans le monde actuel où le cloud est roi, les développeurs sont souvent poussés à adopter une stratégie d'achat ET de construction. Les équipes de développement qui cherchent à apporter une valeur ajoutée à l'entreprise doivent être capables d'identifier où elles doivent concentrer leurs efforts pour développer du code personnalisé.
Lorsqu'il est plus judicieux d'acheter et d'intégrer une solution tierce dans leur propre solution, les équipes de développement doivent prendre de bonnes décisions concernant les solutions tierces utilisées.
Si votre équipe de développement n'exploite pas encore la technologie cloud ou les architectures microservices, Improving peut vous aider à devenir compétent, afin que vos équipes puissent utiliser la stratégie buy and build au lieu de prendre une décision binaire sur buy versus build. Contactez nous dès aujourd'hui pour démarrer votre prochaine solution logicielle moderne.
