Dette technique à échelle : éviter la faillite

Le carrefour est la même chose inévitable que toutes les entreprises de logiciels prospères doivent traverser. Ce n'est pas un mauvais MVP qui a passé le test d'adéquation produit-marché, mais un système multiforme qui sert des milliers ou des millions d'utilisateurs a été développé. Mais il y a quelque chose sous la surface. Les nouvelles versions arrivent lentement. Des semaines sont consacrées au développement de simples modifications. Le taux de correction des bugs est plus élevé que celui des anciens problèmes. Le code source oblige les ingénieurs à passer plus de temps à se battre qu'à créer de nouvelles fonctionnalités. Ce scénario se produit super souvent dans le monde de la technologie. Des entreprises qui semblaient promises à un brillant avenir sont étouffées par leur propre succès initial et doivent soit se contenter d'une stagnation complaisante, soit relancer leur développement à grands frais. Les coupables ne sont pas les développeurs incompétents ou le manque de ressources. Les origines résident plutôt dans les choix architecturaux fondamentaux qui ont été faits au cours des premiers mois décisifs, lorsque la rapidité de mise sur le marché était plus importante que la maintenabilité à long terme. Apprendre comment les décisions techniques tiennent la route au fil du temps, c'est un des trucs les plus importants à savoir pour tout leader qui dirige une boîte technologique en pleine croissance. Les choix qu'on fait aujourd'hui peuvent soit accélérer la croissance future, soit créer des obstacles invisibles qui freinent toutes les autres initiatives. La différence entre les entreprises qui réussissent et celles qui échouent, c'est souvent la sagesse architecturale utilisée au bon moment.

Il y a des raccourcis entre le prototype et le logiciel prêt à être produit qui sont censés être rapides mais qui ont des retours sur investissement super longs. Au début, le développement se concentre surtout sur le prototypage rapide et les fonctionnalités directes plutôt que sur des trucs abstraits comme la modularité ou l'extensibilité. Cette méthode est super logique quand le but principal est de valider les hypothèses et de saisir les opportunités du marché avant que les concurrents n'arrivent. Mais ces victoires tactiques peuvent créer des faiblesses stratégiques. Les architectures monolithiques qui semblaient géniales pour les petits groupes deviennent des goulots d'étranglement quand les organisations grandissent. Les schémas de base de données qui étaient parfaits au début sont difficiles à changer pour prendre en charge de nouvelles fonctionnalités. Des centaines de systèmes d'authentification d'utilisateurs s'effondrent sous le poids de milliers d'utilisateurs. Les modèles d'intégration qui marchaient bien avec quelques services tiers deviennent incontrôlables à cause de la taille de l'écosystème.

Une API pas super efficace peut gérer la charge de trafic actuelle sans problème, mais va complètement planter si l'utilisation double. Un code bien ficelé peut permettre de développer rapidement des fonctionnalités au début, mais le développement en parallèle peut devenir encore plus compliqué si l'équipe s'agrandit. Les entreprises ont souvent tendance à mal interpréter ces symptômes comme des difficultés passagères, qui ne sont pas systémiques et qui nécessitent une correction architecturale. Les dirigeants peuvent penser que plus d'ingénieurs accéléreront le processus de développement, pour finalement se rendre compte que les frais généraux de coordination et les conflits de code ralentissent en fait le développement. Les problèmes de performance sont traités en augmentant la puissance des serveurs au lieu d'améliorer l'efficacité de base. Les problèmes de sécurité sont résolus avec une solution ponctuelle plutôt qu'une visite du site du système. Les conséquences économiques et la portée vont bien au-delà de la productivité dans le domaine de l'ingénierie. L'expérience des clients est affectée car les systèmes sont moins stables et moins réactifs. Lorsque la plateforme n'est pas en mesure de répondre aux besoins des entreprises clientes potentielles, les opportunités commerciales sont perdues. Les avantages concurrentiels sont réduits car les fonctionnalités se développent lentement. Cela rend le processus de recrutement plus difficile, car les ingénieurs ne veulent pas travailler dans des organisations qui présentent des dysfonctionnements techniques.

Construire une architecture modulaire

Pour développer efficacement une architecture, il faut connaître les principes qui aident à créer un bon design ainsi que les limites pratiques à prendre en compte quand on décide de mettre en œuvre ou non quelque chose. La base commence par la modularité et la séparation des préoccupations. Les systèmes développés structurent les fonctionnalités en éléments distincts, avec des interfaces et des responsabilités bien définies. Une telle stratégie permet aux équipes de créer, de modifier ou de remplacer des parties individuelles sans perturber l'ensemble du système. Les architectures orientées services illustrent bien ce concept dans son ensemble. Plutôt que de développer des applications monolithiques avec toutes les fonctionnalités utilisant la même base de code et déployées de manière similaire, les organisations peuvent décomposer les systèmes en services dédiés qui interagissent via des API cohérentes. Les services sont indépendants et peuvent être développés, testés et déployés simultanément par différentes équipes sans se marcher dessus.

Le truc, c'est de définir des contrats distincts entre les différentes sections du système et d'éviter les couplages serrés qui font que les changements se propagent dans tous les sens à travers le code.

Considérations relatives à l'architecture des données

Il faut faire super gaffe à l'architecture des données, car ce genre de choix peut coûter super cher à changer dans le cas des bases de données. Le plan d'optimisation des cas d'utilisation peut être un gros frein quand les exigences changent. Les entreprises qui cartonnent investissent dans des modèles de données assez flexibles pour soutenir leur croissance sans avoir à faire des migrations à grande échelle. Ça pourrait ressembler à ça :

• Choisis des bases de données documentaires plutôt que des bases de données relationnelles en fonction de tes besoins.
• Utiliser une stratégie de gestion des versions des données
• Créer des API qui cachent les implémentations de stockage sous-jacentes.

Équilibrer les besoins actuels et futurs

Les exigences en matière d'évolutivité doivent trouver un équilibre entre les besoins actuels et les opportunités futures. Quand on met en place des solutions trop sophistiquées pour des problèmes qui pourraient ne jamais se poser, on gaspille des ressources et on complique les choses inutilement. Les solutions trop peu sophistiquées pour s'adapter à une croissance prévisible entraînent une dette technique qui augmente de façon exponentielle. La meilleure solution consiste à repérer les goulots d'étranglement en matière d'évolutivité dès les premières étapes et à mettre en place une architecture capable de s'adapter en douceur à la charge.

Observabilité et sécurité

L'observabilité est un autre facteur architectural super important qui n'est généralement pas pris en compte dans les premières étapes du développement. Tout système qui manque de fonctionnalités complètes de journalisation, de surveillance et de débogage devient plus difficile à maintenir à mesure qu'il se complexifie. Il est beaucoup moins cher d'intégrer l'observabilité dans l'architecture dès le début que de le faire après coup, mais les expériences acquises sont super précieuses pour l'optimisation et le dépannage. C'est pareil pour l'architecture de sécurité, qui est aussi un investissement précoce. Adopter les composants de base pour l'authentification, l'autorisation et la protection des données permet de développer rapidement des fonctionnalités sans créer de dette de sécurité. Par contre, si on s'occupe de la sécurité après coup, ça peut coûter cher de tout refaire quand les besoins de conformité ou les modèles de menace changent.

Prise de décision technique

Les entreprises qui veulent éviter les pièges architecturaux devraient mettre en place des modèles de prise de décision technique qui équilibrent le rythme à court terme et l'endurance à long terme. Ça inclut :

• Mettre en place des procédures de révision architecturale pour les choix techniques importants.
• Documenter les compromis
• Vérifiez souvent la dette technique par rapport aux priorités de l'entreprise.

Test et intégration

Investir dans les tests automatisés et l'intégration continue, ça vaut le coup aussi parce que ça permet de refactoriser en toute confiance et de faire des investissements architecturaux. Quand les équipes peuvent rapidement confirmer les changements, elles sont plus à même de mettre en place des ajustements proactifs plutôt que de repousser indéfiniment le processus de maintenance. Le développement parallèle est aussi possible grâce à des suites de tests complètes qui repèrent les problèmes d'intégration dès le début.

Révision du code et partage des connaissances

La révision des codes doit vérifier à la fois les implications architecturales et l'exactitude du fonctionnement. Seules les révisions qui se concentrent sur la fonctionnalité immédiate ne permettent pas de détecter et de corriger les problèmes structurels avant qu'ils ne s'enracinent. On peut améliorer la qualité des décisions dans toute l'organisation en formant les ingénieurs à identifier et à communiquer les compromis architecturaux.

Les présentations techniques et les réunions d'architecture fréquentes permettent de garder une compréhension commune dans le contexte de l'expansion des équipes d'ingénieurs.

Révisions régulières de l'architecture

Les évaluations architecturales régulières permettent de prendre un peu de recul par rapport au développement quotidien et d'analyser la santé des systèmes à plus grande échelle. Ces examens doivent déterminer où en est la dette technique, si les architectures actuelles répondent aux besoins de l'entreprise et ce qui peut être fait pour les améliorer afin d'offrir le meilleur retour sur investissement possible en matière d'ingénierie.

Le processus de mise à l'échelle après le démarrage est forcément une évolution architecturale, mais ça ne veut pas dire qu'il faut faire des réécritures coûteuses ou même stagner dans le développement. Les entreprises qui prennent des décisions architecturales prudentes dès le début sont mieux placées pour assurer leur pérennité, tandis que celles qui négligent les aspects structurels finissent souvent par être dépassées par leurs propres réalisations. La plupart des entreprises technologiques qui ont des modèles qui marchent ne voient pas l'architecture comme une décision, mais plutôt comme une discipline continue. Elles développent des systèmes qui peuvent évoluer facilement, investissent dans les outils et les processus nécessaires pour pouvoir faire des changements en toute confiance et ont les connaissances architecturales pour faire les bons compromis quand ça compte vraiment. Le coût de la discipline architecturale n'est rien comparé au coût d'une faillite technique. En prenant conscience que les décisions prises à un stade précoce se multiplient avec le temps et en appliquant de manière cohérente des principes architecturaux éprouvés, les organisations seront en mesure de développer des logiciels qui ne feront qu'accroître leur succès à long terme. La question n'est pas de savoir si des problèmes architecturaux vont se poser, mais s'ils seront détectés et traités avant qu'ils ne deviennent des problèmes apparemment insurmontables.