Ich habe die Idee eines Inverses Conway-Gesetz in früheren Beiträgen schon einmal, aber nur am Rande. Deshalb möchte ich heute das Konzept vollständig beschreiben, weil ich glaube, dass es eine nützliche Möglichkeit ist, einige der aktuellen Herausforderungen im MarTech-Bereich zu verstehen – und warum es zu einem großen Wandel in der Marketing-Software führen kann KI-Ära.
Conways Gesetz (weite Interpretation)
Um das umgekehrte Conway-Gesetz zu verstehen, müssen Sie es zunächst verstehen Conways Gesetz. Es ist nach ihm benannt Melvin Conwayein früher Informatiker, der 1967 feststellte: „Jede Organisation, die ein System (im weitesten Sinne) entwirft, wird einen Entwurf erstellen, dessen Struktur eine Kopie der Kommunikationsstruktur der Organisation ist.“
Das klassische Beispiel für Conways Gesetz lautet: Wenn drei Teams eine Software-App entwickeln, besteht die App aus drei Teilen, die auf eine Weise miteinander in Beziehung stehen, die widerspiegelt, wie diese drei Teams interagiert haben. Die Grenzen und Übergaben zwischen den Teams werden sich in der Funktionsweise der Software widerspiegeln.
Ich glaube tatsächlich an eine breitere Interpretation von Conways Gesetz: Das Design einer Software-App spiegelt die Funktionsweise des Unternehmens wider, das sie entwickelt hat – seine Organisationsstruktur, Überzeugungen, Kultur und Philosophie. Die App ist nicht nur ein Spiegel der Kommunikationsstruktur der Organisation. Es ist die Verkörperung der Art und Weise, wie dieses Unternehmen denkt und arbeitet.
Produktmanager sprechen manchmal von „meinungsbasierter Software“, die einen Standpunkt dazu einnimmt, wie Menschen sie nutzen sollten. Aber das bedeutet nur, sich dessen bewusst zu sein. Alle Software wird von den Leuten beurteilt, die sie entwickelt haben.
Wenn 100 Unternehmen auch nur eine mäßig komplexe Softwareanwendung entwickeln, um dasselbe übergeordnete Ziel zu erreichen, erhalten Sie 100 verschiedene Implementierungen. (Dies hilft zu erklären, warum es in der Martech-Landschaft so viele Produkte gibt, die „irgendwie alle das Gleiche tun – aber nicht wirklich.“)
Das umgekehrte Conwaysche Gesetz ist das, was stromabwärts geschieht
Aber es gibt eine interessante Konsequenz für kommerziell verpackte Software. Ein Produkt spiegelt die Organisation des Anbieters wider, der es hergestellt hat. Es spiegelt jedoch nicht unbedingt die Organisation eines Unternehmens wider, das es kauft. Zumindest zunächst nicht. Sehr oft muss ein Unternehmen, das eine nicht triviale Software-App kauft, seine eigene Struktur, Prozesse und Erfahrungen anpassen, um der „Meinung“ dieser Software zu entsprechen.
Das ist es, was ich geprägt habe Inverses Conway-Gesetz: Die Einführung einer kommerziellen Software-App erfordert oft, dass ein Unternehmen die Funktionsweise an das Design dieser Software-App anpasst.
Nun, das ist nicht grundsätzlich eine schlechte Sache. Insbesondere wenn das Unternehmen eines Käufers seine Arbeitsweise ändern muss, um sich an neue Marktveränderungen anzupassen. Von einem Softwareprodukt „geprägt“ zu werden, das neue Prozesse und Erfahrungen in die Arbeitsweise des Unternehmens einbringt, ist ein Feature und kein Fehler. Sie zahlen für Software, aber was Sie in Wirklichkeit kaufen, ist eine geschäftliche Transformation.
Die Geschichte von Martech ist voller Beispiele. Berücksichtigen Sie die Rollen und Verantwortlichkeiten Ihres aktuellen Marketing-Operations-Teams, seinen Arbeitsablauf, seine Beziehungen zu anderen Teams und untereinander. Wie viel von Ihrem MarTech-Stack ist Ihrem Flow zugeordnet und wie viel ist Ihr Flow Ihrem Stack zugeordnet?
Differenzierung führt Unternehmen zurück zum Conwayschen Gesetz
Abhängig vom Reifegrad Ihres Marketingteams haben Sie die letzte Frage möglicherweise anders beantwortet. Weniger ausgereifte Teams ordnen ihre Arbeit eher dem Design der von ihnen verwendeten Software zu. Diese sofort einsatzbereite Struktur ist für sie ein echter Vorteil. Sie folgen den Noten und spielen die Cover-Songs. Und es ist tanzbar.
Reifere Teams beginnen jedoch zu improvisieren. Sie machen die Musik zu ihrer eigenen. Sie wollen Originale aufführen, keine Coverversionen.
Abgesehen von der musikalischen Metapher ist es wahrscheinlicher, dass ausgereifte Marketing-Operations-Teams ihre eigenen bevorzugten Arbeitsabläufe, Kundenreisen, Mitarbeitererlebnisse und Kundenerlebnisse entwickelt haben. Sie ordnen die Tools in ihrem Stapel ihrer Vision zu und nicht umgekehrt.
Dann wollen sie ihre Software zwangsläufig an diese Vision anpassen.
Sie geben sich nicht mehr damit zufrieden, einfach nur eine App zu konsumieren. Sie werden daran arbeiten, es zu konfigurieren, stoßen jedoch möglicherweise an den Einschränkungen dessen, was vom ursprünglichen Entwickler konfigurierbar oder nicht konfigurierbar gemacht wurde. Dies wird sie dazu veranlassen, die App nach Möglichkeit anzupassen. Sie sind jedoch auf die Erweiterungspunkte beschränkt, die der Anbieter zur Ermöglichung einer solchen Anpassung geöffnet hat.
Zu diesem Zeitpunkt beginnen Teams mit der Erstellung ihrer eigenen Apps. „Apps“ ist möglicherweise übertrieben, da es sich bei diesen Kompositionen zunächst eher um Workflows und Automatisierungen mit Tools wie Workato und Zapier handelt, die App-Grenzen überschreiten. Sie können No-Code-Tools wie Airtable und Webflow verwenden, um kleine Datenbank-Apps oder Web-Apps aus Vorlagen und Komponenten zusammenzustellen. Fortgeschrittenere Teams mit komplexeren Anforderungen nutzen möglicherweise Low-Code-Plattformen wie Microsoft Power Apps.
Hier beginnen sie, die Grenze zur Entwicklung von Software-Apps zu überschreiten, die vollständig auf ihre Bedürfnisse zugeschnitten sind. Es ist wahrscheinlicher, dass sie sich auf die offene Programmierung mit Python oder JavaScript einlassen – obwohl sie auf ein Universum von Softwarebibliotheken und Open-Source-Frameworks zurückgreifen, um ihre Entwicklung zu beschleunigen und zu vereinfachen. Auf technischer Ebene bietet diese Phase der „Erstellung einer App“ den Unternehmen größtmögliche Freiheit bei der Gestaltung ihrer digitalen Abläufe.
Aber jetzt schließt sich der Kreis. Durch die Entwicklung eigener Software unterliegen die selbst entwickelten Apps eines Unternehmens dem Conwayschen Gesetz – das Design dieser Apps spiegelt die Struktur, Überzeugungen, Kultur und Philosophie des Unternehmens wider. Das ist genau das, was sie wollen.
Wie in der Abbildung oben gezeigt, führt Sie die Bewegung entlang dieses Spektrums – konsumieren, konfigurieren, anpassen, komponieren, erstellen – von der Dynamik des umgekehrten Conway-Gesetzes zur Dynamik des Conway-Gesetzes. Sie gewinnen mehr Freiheitsgrade. Aber auch die Kosten für das erforderliche Fachwissen und den Software Development Lifecycle (SDLC)-Overhead steigen. Ist es das wert? Es hängt vom Wert ab, den Ihr eigenes Unternehmen mit einer differenzierten Software-App für einen bestimmten Zweck erschließen kann.
Die meisten Unternehmen verfügen in ihrem Tech-Stack über eine Mischung aus Apps dieses Spektrums.
Die Zukunft der Martech-Software im KI-Zeitalter
Letzte Woche habe ich eine Denkübung vorgeschlagen, um drei mögliche Szenarien für die Zukunft von Martech im Zeitalter der KI zu betrachten.
Würde KI zu einer massiven Ausweitung der kommerziellen Martech-Landschaft führen? Oder werden KI-Tools es mehr Unternehmen ermöglichen, ihre eigenen Apps zu entwickeln, was zu einer schrumpfenden kommerziellen Martech-Landschaft, aber zu einer massiven Explosion maßgeschneiderter Software führt?
Oder würde KI die gesamte Software in einer kleinen Anzahl extrem leistungsstarker Super-Apps konsolidieren – Skynet for Marketers, wenn Sie so wollen?
Auf LinkedIn gab es einige lebhafte Diskussionen zu diesen Szenarien. Aber die meisten Menschen glauben, dass es in Zukunft mehr Apps geben wird, nicht weniger. Entschuldigung, Skynet, heute nicht. Die Debatte drehte sich wirklich darum, ob wir mehr kommerzielle oder mehr benutzerdefinierte Apps sehen werden. (Oder beides, was wahrscheinlich das wahrscheinlichste Szenario ist.)
Wenn Sie über diese Alternativen nachdenken, können Sie das Szenario „mehr kommerzielle Apps“ der linken Seite des Spektrums oben und das Szenario „mehr benutzerdefinierte Apps“ der rechten Seite zuordnen.
Wird einer den anderen dominieren?
