Loi de Conway contre loi inverse de Conway et l’avenir de la construction par rapport à l’achat dans le martech

J’ai lancé l’idée d’un Loi de Conway inverse dans les posts précédents, mais seulement en passant. Aujourd’hui, je souhaite décrire en détail le concept, car je pense que c’est un moyen utile de comprendre certains des défis actuels du martech – et pourquoi il peut entraîner un changement majeur dans le domaine. logiciel de marketing dans le C’était.

Loi de Conway (interprétation large)

Pour comprendre la loi de Conway inverse, vous devez d’abord comprendre La loi de Conway. Il porte le nom Melvin Conwayun des premiers informaticiens qui observait en 1967 : « Toute organisation qui conçoit un système (défini au sens large) produira une conception dont la structure est une copie de la structure de communication de l’organisation. »

L’exemple classique de la loi de Conway est que si trois équipes créent une application logicielle, l’application comportera trois parties liées les unes aux autres d’une manière qui reflète la façon dont ces trois équipes ont interagi. Les frontières et les transferts entre les équipes se refléteront dans le fonctionnement du logiciel.

Je crois en fait en une interprétation plus large de la loi de Conway : la conception d’une application logicielle reflétera la façon dont fonctionne l’entreprise qui l’a construite : sa structure organisationnelle, ses convictions, sa culture et sa philosophie. L’application n’est pas seulement un miroir de la structure de communication de l’organisation. C’est l’incarnation de la façon dont cette entreprise pense et fonctionne.

Les chefs de produit parlent parfois de « logiciels opiniâtres » qui adoptent un point de vue sur la manière dont les gens devraient l’utiliser. Mais il s’agit simplement d’en être conscient. Tous le logiciel est soumis à l’opinion de ceux qui l’ont construit.

Si 100 entreprises créent même une application logicielle modérément complexe pour atteindre le même objectif de haut niveau, vous obtiendrez 100 implémentations différentes. (Cela aide à expliquer pourquoi le paysage martech a autant de produits qui « font tous un peu la même chose – mais pas vraiment ».)

La loi de Conway inverse est ce qui se passe en aval

Mais il existe un corollaire intéressant pour les logiciels commercialisés. Un produit reflète l’organisation du fournisseur qui l’a construit. Il ne reflète cependant pas nécessairement l’organisation de l’entreprise qui l’achète. Du moins pas au début. Très souvent, une entreprise qui achète une application logicielle non triviale doit adapter sa propre structure, ses processus et ses expériences pour correspondre à « l’opinion » de ce logiciel.

C’est ce que j’ai inventé comme Loi de Conway inverse: l’adoption d’une application logicielle commerciale nécessite souvent qu’une entreprise adapte son mode de fonctionnement pour s’adapter à la conception de cette application logicielle.

Maintenant, ce n’est pas une mauvaise chose en soi. Surtout si l’entreprise d’un acheteur doit modifier sa façon de travailler pour s’adapter aux nouveaux changements du marché. Être « façonné » par un produit logiciel qui apporte de nouveaux processus et expériences au fonctionnement de l’entreprise est une fonctionnalité et non un bug. Vous payez pour un logiciel, mais ce que vous achetez en réalité, c’est une transformation commerciale.

L’histoire du martech regorge d’exemples. Tenez compte des rôles et des responsabilités de votre équipe d’opérations marketing actuelle, de son flux de travail, de ses relations avec les autres équipes et entre elles. Quelle part de votre pile martech est mappée à votre flux par rapport à quelle part votre flux est mappé à votre pile ?

La différenciation ramène les entreprises à la loi de Conway

En fonction de la maturité de votre équipe d’opérations marketing, vous avez peut-être répondu différemment à cette dernière question. Les équipes moins matures sont plus susceptibles d’adapter leur travail à la conception des logiciels qu’elles utilisent. Cette structure originale constitue pour eux un réel avantage. Ils suivent les partitions et jouent les reprises. Et c’est dansant.

Les équipes plus matures commencent cependant à improviser. Ils s’approprient la musique. Ils veulent jouer des originaux, pas des reprises.

Métaphore musicale mise à part, les équipes d’opérations marketing matures sont plus susceptibles d’avoir développé leurs propres flux de travail, parcours clients, expériences employés et expériences clients. Ils mappent les outils de leur pile à leur vision, plutôt que l’inverse.

Inévitablement, ils veulent adapter leur logiciel à cette vision.

Ils ne se contentent plus de simplement consommer une application. Ils travailleront pour le configurer, mais peuvent s’irriter contre les contraintes de ce qui a été rendu configurable ou non par le développeur d’origine. Cela les amènera à personnaliser l’application, lorsque cela est possible. Mais ils sont limités aux points d’extension ouverts par le fournisseur pour permettre une telle personnalisation.

C’est à ce moment-là que les équipes commencent composer leurs propres applications. Le terme « applications » est peut-être exagéré, car au départ, ces compositions sont davantage des flux de travail et des automatisations utilisant des outils tels que Workato et Zapier qui dépassent les frontières des applications. Ils peuvent utiliser des outils sans code tels que Airtable et Webflow pour assembler de petites applications de base de données ou des applications Web à partir de modèles et de composants. Les équipes plus avancées ayant des exigences plus complexes peuvent utiliser des plateformes low-code telles que Microsoft Power Apps.

Ici, ils commencent à franchir la frontière et à créer des applications logicielles entièrement adaptées à leurs besoins. Ils sont plus susceptibles de s’engager dans une programmation ouverte avec Python ou JavaScript, tout en s’appuyant sur un univers de bibliothèques de logiciels et de frameworks open source pour accélérer et simplifier leur développement. Au niveau technique, cette étape de « création d’une application » donne aux entreprises un maximum de liberté dans l’élaboration de leurs opérations numériques.

Mais maintenant, nous avons bouclé la boucle. En créant leur propre logiciel, les applications développées en interne par une entreprise seront soumises à la loi de Conway : la conception de ces applications reflétera la structure, les convictions, la culture et la philosophie de l’entreprise. C’est exactement ce qu’ils veulent.

Comme le montre l’illustration ci-dessus, parcourir ce spectre – consommer, configurer, personnaliser, composer, créer – vous fait passer de la dynamique de la loi de Conway inverse à la dynamique de la loi de Conway. Vous gagnez plus de degrés de liberté. Mais le coût de l’expertise requise et les frais généraux du cycle de vie du développement logiciel (SDLC) augmentent également. Est-ce que ça vaut le coup? Cela dépend de la valeur que votre propre entreprise peut débloquer avec une application logicielle différenciée dans un but particulier.

La plupart des entreprises auront un mélange d’applications de ce spectre dans leur pile technologique.

L’avenir des logiciels martech à l’ère de l’IA

La semaine dernière, j’ai proposé un exercice de réflexion pour réfléchir 3 scénarios possibles pour l’avenir du martech à l’ère de l’IA.

L’IA entraînerait-elle une expansion massive du commerce paysage martech? Ou les outils d’IA permettront-ils à davantage d’entreprises de créer leurs propres applications, ce qui entraînera un rétrécissement du paysage martech commercial mais une explosion massive de logiciels sur mesure ?

Ou l’IA regrouperait-elle tous les logiciels en un petit nombre de super applications ultra puissantes – Skynet for Marketers, si vous voulez ?

Il y a eu des discussions saines sur LinkedIn autour de ces scénarios. Mais la plupart des gens pensent que l’avenir proposera davantage d’applications, et non moins. Désolé, Skynet, pas aujourd’hui. Le débat tournait vraiment autour de la question de savoir si nous verrions davantage d’applications commerciales ou davantage d’applications personnalisées. (Ou les deux, ce qui est probablement le scénario le plus probable.)

Pendant que vous envisagez ces alternatives, vous pouvez mapper le scénario « applications plus commerciales » sur le côté gauche du spectre ci-dessus et le scénario « applications plus personnalisées » sur le côté droit.

L’un dominera-t-il l’autre ?