En mars 2021, j’ai écrit un article sur la taxe sur l’innovation : des processus maladroits et des technologies dépassées empêchent les équipes d’ingénieurs de produire d’excellentes technologies qui ravissent les clients. Dans les mois qui ont suivi, ma réflexion a encore évolué. Je n’aurais pas pu deviner combien de leaders technologiques reconnaîtraient immédiatement ces problèmes dans leur propre organisation et me feraient part de leurs plus grandes frustrations. Cet article présente l’évolution de ma réflexion ainsi que les nombreux commentaires que j’ai reçus. Il vous donnera des moyens concrets de réduire votre charge fiscale – et qui ne le voudrait pas ?

La taxe sur l’innovation, comme l’impôt sur le revenu, est réelle. Bien sûr, elle impacte le moral (avec pour conséquence l’attrition et les départs), mais elle a aussi d’autres coûts financiers et d’opportunités. Les organisations taxées voient leur rythme d’innovation diminuer, car les personnes et les ressources sont bloquées dans le maintien plutôt que dans l’innovation.

Nous avons appelé cette taxe DIRT. Pourquoi ? Eh bien, elle est ancrée dans les données (D), car elle découle souvent de la difficulté d’utiliser des bases de données anciennes pour prendre en charge des applications modernes qui nécessitent un accès aux données en temps réel pour créer des expériences utilisateur riches. Elle affecte l’innovation (I), car vos équipes n’ont guère le temps d’innover si elles sont constamment en train de chercher comment supporter une architecture complexe et bancale. Elle est récurrente (R), car ce n’est pas comme si vous payiez la taxe (T) une seule fois seulement. C’est plutôt le contraire. DIRT rend chaque nouveau projet encore plus difficile car elle introduit un grand nombre de composants, de cadres et de protocoles qui doivent être gérés par différentes équipes de personnes.

Rétrospectivement, il est clair que les leaders technologiques reconnaîtraient cet impôt et comprendraient immédiatement dans quelle mesure il est causé – ou guéri – par leur architecture de données. Les données sont collantes, stratégiques, lourdes, complexes et constituent le cœur de l’entreprise numérique moderne. Les applications modernes ont des besoins en données beaucoup plus sophistiqués que les applications que nous construisions il y a seulement 10 ans. Il y a évidemment plus de données, mais c’est plus compliqué que cela : On attend des entreprises qu’elles réagissent plus rapidement et plus intelligemment à tous les signaux contenus dans ces données. Les technologies traditionnelles, notamment les bases de données relationnelles rigides à modèle unique, inefficaces et difficiles à programmer, ne suffisent plus.

Au cours des 300 conversations que j’ai eues avec des dirigeants d’entreprise depuis que j’ai rejoint MongoDB en 2020, moins d’une poignée de dirigeants d’entreprise ont contesté cette affirmation. Lorsque votre stack IT ne peut pas répondre aux demandes de nouvelles applications, les équipes d’ingénieurs se contentent souvent de bases de données de niche à usage unique pour faire le travail (séries chronologiques, texte, graphiques, etc.). Elles construisent ensuite une série de pipelines pour déplacer les données dans les deux sens. Et tout deviendra lent et compliqué – et même politique. Il est temps de peaufiner ce profil LinkedIn.

Si cela était rare, ce ne serait pas si grave. Mais les grandes entreprises peuvent avoir des centaines ou des milliers d’applications, chacune avec ses propres sources de données et ses propres pipelines. Au fil du temps, à mesure que les magasins de données et les pipelines se multiplient, l’architecture de données d’une entreprise commence à ressembler à une assiette de spaghettis. Bientôt, vous exploitez et maintenez une couche entière d’intergiciels (ETL, ELT et streaming). La variété des technologies, chacune avec ses propres cadres, protocoles et parfois langages, complique la collaboration entre les développeurs. Il est extrêmement difficile d’évoluer, car chaque architecture est personnalisée et fragile. Les développeurs passent leurs précieuses heures de « flux » à faire du travail d’intégration au lieu de créer de nouvelles applications et fonctionnalités dont l’entreprise a besoin et que les clients vont adorer. Les architectes d’entreprise finissent souvent par consacrer leur temps aux mauvaises choses.

Il est clair pour moi que la plupart des clients sont prêts à adopter une nouvelle approche de l’architecture des données. L’une des meilleures parties de mon travail est d’écouter et d’apprendre des autres CxO. Comme la pandémie a rendu impossible toute rencontre en personne, MongoDB a déplacé ces discussions en ligne, invitant les leaders technologiques à discuter de certains de leurs plus gros problèmes en tête-à-tête et en groupe avec moi. Au cours de l’une de ces sessions, un directeur technique a déclaré : « La dette technique devrait figurer au bilan de votre directeur financier ». Même sur Zoom, la puissance de cette déclaration était claire.

Nous avons également commencé à regarder les diaporamas sur l’architecture des données de certaines des sociétés de capital-risque les plus connues. Il est certain que les sociétés de capital-risque doivent positionner chacune des entreprises de leur portefeuille comme un acteur essentiel de l’architecture de données du futur. Mais la vision globale n’était pas convaincante. Un leader technologique a déclaré : « Lorsque je regarde les 20 nouvelles technologies nettes que je dois apprendre, c’est terrifiant. » D’autres ont fait remarquer que le simple fait de regarder ces diagrammes d’architecture était un peu décourageant, car ils savaient que l’architecture de données de leur propre organisation était déjà au moins aussi compliquée. Ils savaient qu’ils devaient simplifier leur architecture de données, mais plus d’un a admis avoir reporté ce travail – indéfiniment – parce qu’il était tout simplement trop décourageant. J’ai récemment rencontré une grande entreprise de soins de santé dont les dirigeants pensent que c’est tout juste possible, mais ils plongent courageusement dans l’aventure, sachant qu’ils doivent le faire et qu’ils apprendront en cours de route en démolissant leurs monolithes.

Dans de nombreux cas, la taxe sur l’innovation se manifeste par l’incapacité d’envisager une nouvelle technologie parce que l’architecture sous-jacente est trop complexe et difficile à maintenir, et encore moins à comprendre et à transformer. C’est la raison pour laquelle de nombreux dirigeants d’entreprises ont les doigts dans la digue de la transformation, en attendant la retraite – ils pensent qu’ils ne peuvent pas se moderniser.

Vous ne serez pas surpris d’apprendre que nous avons également vu comment MongoDB, en tant que base de données à usage général capable de traiter tous les types de données à la vitesse et à l’échelle, pouvait contribuer à résoudre ce problème. Permettez-moi d’être clair. J’ai travaillé sur ou avec des bases de données pendant toute ma carrière de 35 ans, et j’ai rejoint MongoDB pour une raison : je crois que nous pouvons construire la base de données et l’environnement de création d’applications que j’ai voulu créer et utiliser pendant au moins 30 de ces années. Notre vision de MongoDB va au-delà de notre base de données éponyme pour devenir une plateforme de données applicatives plus large et plus polyvalente qui vous permet d’accélérer et de simplifier la création de tout type d’application. Elle représente un progrès significatif vers notre objectif plus large, qui reste le même : rendre les données étonnamment faciles à utiliser. Nous voulons que les données deviennent un facteur d’innovation, et non un obstacle. Et nous voulons enfin permettre aux équipes technologiques de commencer à démêler leur étalement et à se débarrasser de leur DIRT.

Par où commencer ? Il est bon d’avoir une meilleure compréhension de la façon dont la DIRT peut freiner vos équipes. Vos développeurs ont-ils des difficultés à collaborer en raison de la fragmentation de l’environnement de développement ? Les modifications de schémas sont-elles plus longues à mettre en œuvre que les modifications d’applications qu’elles sont censées prendre en charge ? Avez-vous des difficultés à construire des vues 360 de vos clients ? Et si oui, pourquoi ? Ce sont tous de bons endroits pour commencer à creuser dans la DIRT.

Vous pourriez également examiner de près vos applications et vos sources de données, ainsi que les mesures à prendre pour transférer vos données sur une plate-forme de données applicatives. Cela pourrait signifier identifier les objets de vos applications et toutes les applications qui interagissent avec eux. Vous pourriez ensuite attribuer un score de complexité à chacun d’entre eux en fonction d’attributs tels que les propriétés, les méthodes, les collections et les attributs. Maintenant, prenez du recul et identifiez chaque application qui se connecte à chacun de ces objets et classez-la en fonction de son degré de criticité, du nombre de personnes qui en dépendent, du nombre de tâches qu’elle doit accomplir et de la complexité de ces tâches. Une fois que vous aurez une meilleure idée de toute cette complexité, vous serez mieux placé pour créer un plan d’élimination de vos anciens systèmes, en commençant peut-être par les sources de données les moins complexes et les moins intégrées. Bien sûr, vos mesures et votre kilométrage varieront, mais l’essentiel est de commencer.

Je ne prétends pas que tout cela soit facile. Comme beaucoup d’entre vous, j’ai passé la majeure partie de ma carrière à travailler sur des problèmes comme ceux-ci. Mais cela signifie également que je sais reconnaître le progrès quand je le vois, et le début d’un moyen pour les organisations de commencer à nettoyer leur DIRT.
___________________

Par Mark Porter, CTO chez MongoDB

A lire également :

La distinction, importante, entre recherche et développement…

Un conseil pour les nouveaux développeurs cloud

5 innovations qui vont bouleverser la décennie 2020-2030…