Warum viele Salesforce-Marketing-Cloud-Architekturen 2026 überarbeitet werden müssen (und nicht erweitert)

Eine Umgebung, die noch funktioniert — sich aber nicht mehr mitentwickelt

Viele Salesforce-Marketing-Cloud-Umgebungen funktionieren 2026 technisch noch problemlos. Kampagnen werden versendet, Journeys laufen weiter und Dashboards zeigen stabile Zahlen. Auf dem Papier scheint wenig problematisch zu sein. Dennoch stellen immer mehr Organisationen fest, dass jede Änderung unverhältnismäßig viel Zeit kostet, Risiken zunehmen und Marketingteams immer zurückhaltender werden, weitere Anpassungen vorzunehmen.

Dieses Spannungsfeld entsteht nur selten durch eine einzelne falsche Entscheidung oder eine fehlgeschlagene Implementierung. Es ist die Folge einer Architektur, die einst logisch war, aber nie grundlegend überarbeitet wurde. Was als pragmatisches Setup begann, um schnell Ergebnisse zu erzielen, hat sich langsam zu einem System entwickelt, das vor allem aufrechterhalten wird. Genau hier entsteht das Risiko: nicht weil die Plattform aufhört zu funktionieren, sondern weil sie immer weniger Raum für Veränderungen lässt, während die Technologie selbst weiterhin problemlos läuft.

Die Umgebung läuft, aber niemand weiß noch genau, wo die strukturellen Grenzen liegen

Von schneller Implementierung zu strukturellem Erbe

Die meisten Salesforce-Marketing-Cloud-Architekturen wurden nicht als vollwertige Architektur konzipiert. Sie entstanden aus dringenden Anforderungen: E-Mail zentralisieren, Lead Nurturing automatisieren und Customer Journeys orchestrieren. Der Fokus lag zu Recht auf Geschwindigkeit und Funktionalität. In der Anfangsphase lieferte das Ergebnisse, doch dieselben pragmatischen Entscheidungen blieben häufig bestehen, während die Umgebung, die Zahl der Märkte und die Abhängigkeiten rund um Daten und Integrationen immer weiter wuchsen.

Data Extensions wurden für spezifische Kampagnen hinzugefügt und blieben anschließend bestehen. Synchronisationen mit dem CRM wurden für einen Markt oder Use Case eingerichtet und später für andere Zwecke wiederverwendet. Consent-Lösungen wurden dort ergänzt, wo regulatorische Anforderungen dies verlangten, ohne das übergeordnete Datenmodell zu überarbeiten. Jede einzelne Entscheidung konnte rational sein, doch gemeinsam entstand eine Struktur, bei der immer schwieriger zu erklären ist, warum bestimmte Komponenten noch bestehen und welche Prozesse davon abhängig sind.

Im Jahr 2026 sind diese historischen Entscheidungen tief mit Prozessen, Reporting und Verantwortlichkeiten verwoben. Architektur ist dadurch kein theoretisches Konzept mehr, sondern tägliche operative Realität. Sie bestimmt, wie schnell eine Organisation neue Anforderungen verarbeiten kann, wie viel Risiko eine Änderung mit sich bringt und wie viel Spezialwissen erforderlich ist, um eine scheinbar einfache Anpassung sicher umzusetzen.

Warum Erweiterung so attraktiv erscheint

Wenn neue Anforderungen entstehen — neue Märkte, strengere Datenschutzregeln oder höhere Erwartungen an Personalisierung — ist Erweiterung der natürliche Reflex. Ein zusätzliches Attribut, eine ergänzende Automation oder eine neue Journey erscheint als konkrete und beherrschbare Lösung für ein konkretes Problem. Kurzfristig funktioniert das häufig auch: Die Organisation kann weitermachen, ohne die zugrunde liegende Struktur umfassender zu überarbeiten, wodurch sich Erweiterung organisatorisch leichter vertreten lässt als architektonische Veränderung.

Doch jede Erweiterung vergrößert auch die gegenseitigen Abhängigkeiten. Impact-Analysen werden komplexer, Fehler schwieriger zurückzuverfolgen und Teams vorsichtiger bei Änderungen, weil die Auswirkungen außerhalb des eigenen Bereichs nicht immer vorhersehbar sind. Der Wendepunkt entsteht, wenn Erweiterung technisch noch möglich ist, sich aber nicht länger beherrschbar anfühlt. Ab diesem Moment löst zusätzliche Konfiguration vor allem das Problem von heute, während sie gleichzeitig die strukturelle Überarbeitung von morgen erschwert.

Erweiterung wirkt logisch — bis sie nicht mehr funktioniert

Erweiterung wirkt attraktiv, weil sie greifbar ist. Es gibt eine konkrete Anforderung, ein erkennbares Problem und eine klare technische Handlung, um dieses Problem zu lösen. Ein zusätzliches Attribut, ein neuer Journey-Zweig oder eine ergänzende Automation scheint unmittelbar zum Ergebnis beizutragen. In der Anfangsphase einer Marketing-Cloud-Umgebung trifft das auch zu, weil die einzelnen Komponenten noch relativ wenige Abhängigkeiten besitzen und die Auswirkungen von Änderungen gut überschaubar sind.

Das Problem entsteht, wenn sich diese Erweiterungen gegenseitig zu beeinflussen beginnen. Was einmal eine isolierte Optimierung war, wird Teil eines immer dichteren Netzwerks von Abhängigkeiten. Segmentierungen beginnen mehrere Journeys zu steuern. Automations schreiben Daten, die an anderer Stelle wieder genutzt werden. Kleine Änderungen haben unbeabsichtigte Auswirkungen, die erst sichtbar werden, nachdem Kampagnen live gegangen sind. Teams lösen damit immer wieder das Problem von heute, bauen gleichzeitig jedoch eine Umgebung, in der zukünftige Veränderungen mehr Analyse, Abstimmung und Wiederherstellungsaufwand erfordern.

Im Jahr 2026 erkennen viele Organisationen, dass dieses Muster nicht länger tragfähig ist. Die Begrenzung liegt nicht primär im Tooling, sondern in einer zugrunde liegenden Struktur, die zu wenig Halt bietet, um Wachstum kontrolliert zu unterstützen. Solange diese Struktur nicht explizit überarbeitet wird, führt jede neue funktionale Anforderung zu mehr Abhängigkeiten und immer weniger Sicherheit hinsichtlich der Auswirkungen von Veränderungen.

Konfiguration ist keine Architektur

Eine fundamentale Ursache dieser Situation ist das Fehlen einer expliziten Unterscheidung zwischen Konfiguration und Architektur. Konfiguration beschreibt, wie etwas eingerichtet ist: Felder, Journeys, Synchronisationen und Automatisierungen. Architektur beschreibt, warum diese Einrichtung so gewählt wurde, welche Grundprinzipien führend sind und welche Grenzen bewusst gelten. Ohne diese Unterscheidung kann eine Umgebung technisch korrekt konfiguriert sein und gleichzeitig strukturell immer schwieriger steuerbar werden.

In vielen Salesforce-Marketing-Cloud-Umgebungen wurde die Konfiguration über Jahre weiterentwickelt, ohne dass die Architektur explizit festgelegt wurde. Entscheidungen werden vor allem funktional bewertet — funktioniert es? — und deutlich weniger strukturell — passt dies in das Systemdesign und bleibt es beherrschbar, wenn andere Teams, Märkte oder Journeys davon abhängig werden? Dadurch entsteht technische Funktionalität ohne einen gemeinsamen Rahmen für zukünftige Entscheidungen.

Die Folge ist, dass sich lokale Optimierungen ansammeln, während der globale Zusammenhang langsam verschwindet. Teams verbessern ihre eigenen Kampagnen, aber niemand überwacht das Gesamtbild. Das fühlt sich lange praktikabel an, bis niemand mehr überblicken kann, welche tatsächlichen Auswirkungen eine Änderung hat. Dann zeigt sich, dass nicht die einzelne Konfiguration das größte Problem darstellt, sondern das Fehlen expliziter Architekturprinzipien, anhand derer neue Änderungen bewertet werden können.

Was passiert, wenn Organisationen 2026 nicht überarbeiten?

Nicht zu überarbeiten ist keine neutrale Entscheidung. Es bedeutet, dass bestehende Annahmen unverändert bleiben, während sich der Kontext, in dem Salesforce Marketing Cloud arbeitet, fundamental verändert. Die Folgen sind nur selten sofort spektakulär. Gerade deshalb bleibt das Problem lange unter dem Radar: Technische Prozesse laufen weiter, doch Entscheidungsfindung und Veränderung erfordern immer mehr Abstimmung, Kontrollen und Spezialwissen, bevor Teams überhaupt noch Anpassungen wagen.

Marketingteams stellen fest, dass kleine Änderungen Impact-Analysen erfordern, die niemand vollständig überblicken kann. Releases werden „vorsichtshalber“ verschoben, Innovation verlagert sich von strukturell zu gelegentlich und neue Use Cases werden vermieden, weil die Risiken schwer einzuschätzen sind. KPIs können währenddessen akzeptabel bleiben, wodurch die Verschlechterung in Dashboards kaum sichtbar wird. Der tatsächliche Verlust liegt in der Agilität: Neue Märkte, Datenströme und kommerzielle Anforderungen benötigen immer mehr Zeit, um zuverlässig in die bestehende Umgebung integriert zu werden.

Wir treffen keine falschen Entscheidungen, aber wir treffen immer weniger Entscheidungen

In Enterprise-Umgebungen führt dies letztlich zu strategischer Reibung. Marketing verliert gegenüber den Businessambitionen an Geschwindigkeit, IT wird zurückhaltender und Compliance-Abteilungen prüfen Änderungen strenger, weil die gegenseitigen Abhängigkeiten weniger transparent sind. Nicht zu überarbeiten bedeutet in der Praxis somit, dass Komplexität ohne Steuerung weiterwächst. Je länger dieses Muster anhält, desto aufwendiger und risikoreicher wird eine zukünftige Überarbeitung.

Wenn Daten kein stabiles Fundament mehr bilden

Diese Spannung wird besonders sichtbar in der Art und Weise, wie Daten genutzt werden. Salesforce Marketing Cloud ist im Kern eine Datenplattform, doch in vielen Organisationen ist das Datenmodell historisch gewachsen. Datendefinitionen unterscheiden sich je Team oder Region, Felder werden für andere Zwecke wiederverwendet als ursprünglich vorgesehen und historische Data Extensions bleiben bestehen, weil niemand mit Sicherheit sagen kann, welche Prozesse, Segmentierungen oder Journeys noch von ihnen abhängig sind.

Solange Kampagnen relativ linear sind, kann eine solche Umgebung noch beherrschbar erscheinen. Im Jahr 2026 verändert sich dies fundamental, weil Personalisierung, dynamische Segmentierung, automatisierte Entscheidungsfindung und Real-Time-Datenverarbeitung immer höhere Anforderungen an Konsistenz stellen. Daten, die für eine einzelne Kampagne „gut genug“ waren, können innerhalb einer Kette automatisierter Entscheidungen plötzlich mehrere Ergebnisse beeinflussen. Dadurch werden kleine Abweichungen bei Definitionen oder Synchronisation wesentlich wichtiger als in einer traditionellen Kampagnenumgebung.

Inkonsistenz wird dann in Ergebnissen sichtbar, die auf den ersten Blick plausibel erscheinen, aber nicht reproduzierbar sind. Marketingteams erkennen Muster, können jedoch nicht zuverlässig erklären, warum bestimmte Kunden anders behandelt werden oder warum Ergebnisse je Markt voneinander abweichen. Das ist der Moment, in dem Vertrauen zu erodieren beginnt: nicht weil die Daten nachweislich falsch sind, sondern weil die Organisation nicht ausreichend begründen kann, welche Daten zu welchem Zeitpunkt führend waren und warum.

Warum Überarbeitung etwas anderes ist als Bereinigung

Überarbeitung wird häufig mit Bereinigung verwechselt, als ginge es hauptsächlich darum, alte Data Extensions zu entfernen, Journeys zu vereinfachen oder technische Schuld abzubauen. Bereinigung kann notwendig sein, löst jedoch das zugrunde liegende Architekturproblem nicht. Überarbeitung beginnt vielmehr damit, Annahmen explizit zu machen, die jahrelang implizit geblieben sind, und Prinzipien festzulegen, denen sowohl bestehende als auch neue Konfigurationen entsprechen müssen.

Eine inhaltliche Überarbeitung erfordert daher mindestens vier explizite Entscheidungen, die gemeinsam bestimmen, ob die bestehende Konfiguration noch in ein beherrschbares Design passt. Es geht nicht um technische Details, die je Kampagne neu definiert werden können, sondern um feste Grundprinzipien, anhand derer Teams zukünftige Erweiterungen, Ausnahmen und Änderungen konsequent bewerten können:

• Führende Daten: festlegen, welche Quelle für welchen Datentyp und welche Entscheidung maßgeblich ist.
• Entscheidungsgrenzen: bestimmen, welche Entscheidungen innerhalb von Marketing Cloud getroffen werden und welche bewusst außerhalb der Plattform bleiben.
• Bewusste Komplexität: zwischen Komplexität unterscheiden, die kommerziellen Wert schafft, und Komplexität, die lediglich historisch gewachsen ist.
• Bewertung von Erweiterungen: neue Konfiguration nicht nur nach Funktionalität beurteilen, sondern auch nach Zusammenhang, Beherrschbarkeit und zukünftigen Abhängigkeiten.

Indem diese Grundprinzipien explizit festgelegt werden, erhält Konfiguration innerhalb eines größeren Designs wieder Bedeutung. Nicht jede bestehende Lösung muss verschwinden und nicht jede Erweiterung wird automatisch abgelehnt. Der Unterschied besteht darin, dass neue Entscheidungen künftig anhand eines gemeinsamen Architekturrahmens bewertet werden. Damit wird Überarbeitung von einer Bereinigungsaktion zu einer strukturellen Methode, zukünftiges Wachstum beherrschbar zu halten.

KI legt Architekturfehler schonungslos offen

Der Aufstieg von KI-Funktionalität innerhalb von Salesforce Marketing Cloud verändert die Art der Architekturdiskussionen fundamental. Während traditionelle Kampagnen noch auf Grundlage impliziter Annahmen funktionieren konnten, erfordert KI einen deutlich höheren Grad an Konsistenz und Transparenz. Modelle, die Verhalten vorhersagen oder Entscheidungen automatisieren, sind auf stabile Inputs angewiesen. Wenn Definitionen je Markt, Kanal oder Zeitpunkt voneinander abweichen, kann dieselbe Logik Ergebnisse produzieren, die statistisch plausibel, organisatorisch jedoch schwer zu erklären sind.

Viele Organisationen erleben dies nicht als direkten Fehler, sondern als schleichendes Problem. Ergebnisse erscheinen logisch, sind jedoch nicht reproduzierbar. Optimierungen funktionieren manchmal und manchmal nicht, ohne erkennbare Ursache. Dadurch sinkt das Vertrauen in KI und Funktionen werden vorsichtiger eingesetzt, obwohl gerade dort der erwartete strategische Wert liegt. KI wird damit zu einem Stresstest für bestehende Architekturen: nicht weil die Technologie selbst versagt, sondern weil sie Inkonsistenzen sichtbar macht, die in manuell gesteuerten Kampagnen jahrelang verborgen bleiben konnten.

Warum KI ohne Architektur unerklärbar wird

KI in Salesforce Marketing Cloud wird häufig als Optimierungsebene betrachtet. Modelle sagen Verhalten voraus, optimieren Timing oder wählen Content aus. Das funktioniert, solange KI hauptsächlich statistisch eingesetzt und die endgültige Entscheidung an anderer Stelle getroffen wird. Im Jahr 2026 verschiebt sich der Einsatz jedoch zunehmend in Richtung Entscheidungsarchitektur: KI beeinflusst nicht nur, wie gut ein Prozess ausgeführt wird, sondern immer häufiger auch, was geschieht und welcher Kunde oder welche Aktion Priorität erhält.

Ohne explizite Architektur entsteht hier ein fundamentales Problem. Entscheidungen können technisch konsistent berechnet werden, organisatorisch jedoch nicht konsistent erklärt werden. Unterschiedliche Datendefinitionen, abweichende Synchronisationswege und implizite Annahmen führen zu Ergebnissen, die plausibel erscheinen, ohne reproduzierbar zu sein. Das betrifft Governance unmittelbar, weil eine Organisation nicht nur wissen muss, dass ein Modell ein bestimmtes Ergebnis erzeugt hat, sondern auch, auf welchen Daten, Entscheidungsregeln und Verantwortlichkeiten dieses Ergebnis beruhte.

Überarbeitung schafft daher keine Einschränkung für KI, sondern das Fundament, auf dem weitergehende Automatisierung verantwortungsvoll aufgebaut werden kann. Erst wenn Datenströme, Ownership und Entscheidungsgrenzen explizit festgelegt sind, kann KI nachhaltig eingesetzt werden, ohne dass jede abweichende Ausgabe erneut eine Suche nach Ursachen auslöst. Architektur ermöglicht es, Geschwindigkeit und Autonomie zu erhöhen und gleichzeitig Erklärbarkeit und Kontrolle zu erhalten.

Governance ist keine Compliance-Schicht

Im Jahr 2026 ist Governance kein Kontrollmechanismus, der erst nachträglich auf Marketing Cloud angewendet wird. Für multinationale Unternehmen ist Governance eine Designanforderung, weil Umgebungen innerhalb unterschiedlicher Datenschutzregeln, Datenstandorte und Verantwortungsstrukturen arbeiten. Wenn diese Bedingungen nicht explizit in der Architektur verankert sind, wird jede Erweiterung zum Risikomultiplikator: Technisch kann ein neuer Flow funktionieren, während Ownership, Consent-Logik oder Auditability unzureichend geregelt sind.

Viele Organisationen lösen Governance-Fragen mit Ausnahmen und Workarounds. Das funktioniert, solange die Umgebung begrenzt bleibt, doch mit zunehmender Komplexität wird Compliance immer stärker von manuellen Checks und individuellem Wissen abhängig. Überarbeitung bedeutet daher, Governance zum Bestandteil des Systemdesigns selbst zu machen. Regeln zu Data Ownership, Consent, Reproduzierbarkeit und Risikomanagement dürfen nicht neben der Architektur existieren, sondern müssen in der technischen Gestaltung von Prozessen und Verantwortlichkeiten sichtbar werden.

Governance vor und nach der Überarbeitung

Diese Verschiebung macht Governance nicht schwerfälliger, sondern vorhersehbarer. Teams müssen nicht mehr bei jeder Änderung erneut bestimmen, welche Kontrollen notwendig sind, weil die wichtigsten Entscheidungs- und Verantwortungsstrukturen bereits Bestandteil des Designs sind. Dadurch kann eine Organisation schneller verändern, ohne für jede Erweiterung neue Ausnahmen zu schaffen oder Governance-Sicherheit von einzelnen Mitarbeitern abhängig zu machen.

Integrationen als verborgene Quelle von Komplexität

Ein dritter struktureller Engpass liegt in Integrationen. Viele Salesforce-Marketing-Cloud-Architekturen wurden historisch rund um CRM als primäre Wahrheit aufgebaut, während die Datenlandschaft 2026 erheblich breiter ist. Customer Data stammen aus Web- und App-Umgebungen, Consent-Plattformen, externen Datenprovidern und teilweise CDP-ähnlichen Strukturen. Ohne explizite Rollenverteilung wird jede neue Quelle zu einer Landschaft hinzugefügt, in der nicht immer klar ist, welches System für welchen Zweck führend sein soll.

Daraus entsteht leicht ein Netzwerk von Point-to-Point-Integrationen. Synchronisationen werden angepasst, um akute Probleme zu lösen, erhöhen jedoch unbeabsichtigt die Abhängigkeiten zwischen Systemen. Datendefinitionen verschieben sich unbemerkt und Reports korrigieren, was upstream nicht eindeutig festgelegt wurde. Eine Überarbeitung verlangt deshalb explizite Systemrollen: Nicht jedes System muss alles wissen, doch für jede relevante Entscheidung muss klar sein, woher die entscheidenden Daten stammen und welche anderen Systeme dieser Definition folgen.

Überarbeitung als strategische Entscheidung

Was KI, Governance und Integrationen gemeinsam haben, ist, dass sie nicht nachhaltig allein durch zusätzliche Konfiguration gelöst werden können. Sie erfordern architektonische Entscheidungen darüber, was strukturell ist und was temporär bleibt, was zentral verwaltet wird und was bewusst lokal abweichen darf. Ohne solche Grenzen wird jede neue technische Möglichkeit erneut zu einer separaten Diskussion, wodurch die Komplexität wächst, ohne dass die Organisation über ein konsistentes Kriterium verfügt, anhand dessen Entscheidungen bewertet werden können.

Im Jahr 2026 werden diese Entscheidungen zudem immer weniger technischer Natur. Sie bestimmen, wie erklärbar Entscheidungen sind, wie skalierbar die Umgebung bleibt und wie viel operatives und Governance-Risiko eine Organisation bereit ist zu akzeptieren. Überarbeitung ist damit kein Wartungsprojekt, sondern ein strategischer Eingriff, der bestimmt, unter welchen Bedingungen Marketing Cloud weiter wachsen darf und welche Formen von Komplexität die Organisation bewusst nicht länger akzeptiert.

Architektur ist auch eine Organisationsfrage

Wenn Architektur implizit bleibt, konzentriert sich Wissen nahezu immer bei einer kleinen Zahl von Spezialisten. Sie wissen, wie das System historisch gewachsen ist, wo Ausnahmen liegen und welche Annahmen einst getroffen wurden. Das wirkt effizient, solange diese Personen verfügbar sind, stellt jedoch ein strukturelles Risiko dar. Änderungen werden verschoben, weil ihre Auswirkungen schwer zu überblicken sind, neue Teammitglieder benötigen lange Einarbeitungszeiten und die Entscheidungsfindung verlangsamt sich, sobald mehrere Bereiche oder Märkte von derselben Konfiguration abhängig sind.

Überarbeitung macht Architektur explizit und dadurch übertragbar. Wissen verlagert sich von Personen hin zu Strukturen, Dokumentation und gemeinsamen Designprinzipien. Das macht Organisationen weniger anfällig und erhöht die Agilität in komplexen internationalen Umgebungen. Ein reifes System ist daher nicht nur technisch stabil; es muss auch verständlich genug sein, um von mehreren Teams verantwortungsvoll verwaltet zu werden, ohne dass entscheidendes Wissen ausschließlich in den Köpfen weniger Spezialisten verbleibt.

Überarbeitung ist keine Reimplementierung

Ein hartnäckiges Missverständnis besteht darin, dass Überarbeitung bedeutet, alles neu aufzubauen. In der Praxis geht es bei einer wirksamen Überarbeitung gerade darum, Dinge explizit zu machen, bevor sie ersetzt werden. Organisationen müssen sichtbar machen, welche Annahmen noch gültig sind, welche temporären Lösungen inzwischen strukturell geworden sind und welche Komponenten tatsächlich Probleme verursachen. Erst danach kann entschieden werden, wo Anpassungen erforderlich sind und wo bestehende Konfiguration innerhalb des neuen Rahmens weiterhin problemlos funktionieren kann.

Dieser Ansatz verhindert, dass ein Architekturprojekt zu einem kostspieligen technischen Reset ohne klaren Mehrwert wird. Vieles kann bestehen bleiben, erhält aber neue Bedeutung, weil bekannt ist, warum es existiert, welche Abhängigkeiten akzeptabel sind und welche Grenzen künftig gelten. Eine Überarbeitung reduziert dadurch Komplexität, ohne Funktionalität unnötig zu verwerfen, und verhindert gleichzeitig, dass dieselben Ad-hoc-Muster nach einer Reimplementierung einfach erneut aufgebaut werden.

Warum 2026 der Wendepunkt ist

Die Kombination aus KI-getriebener Entscheidungsfindung, strengeren regulatorischen Anforderungen und höheren Erwartungen an Personalisierung macht 2026 zu einem Wendepunkt. Architekturen, die vor dieser Phase entwickelt wurden, sind nur selten für eine Umgebung konzipiert, in der mehr Entscheidungen automatisiert werden, Daten aus mehr Quellen zusammenkommen und Erklärbarkeit wichtiger wird. Sie können technisch noch funktionieren, verfügen jedoch häufig nicht über die expliziten Designprinzipien, die notwendig sind, um weiteres Wachstum beherrschbar zu halten.

Organisationen, die ohne Überarbeitung weiter expandieren, vergrößern ihre Abhängigkeiten und operativen Risiken. Organisationen, die zunächst explizit machen, welche Architektur sie benötigen, schaffen Raum für kontrolliertes Wachstum, erklärbare Entscheidungen und nachhaltige Skalierbarkeit. Der Unterschied liegt nicht in mehr Tooling, sondern in Disziplin: Nicht alles, was technisch möglich ist, ist auch architektonisch sinnvoll, insbesondere dann nicht, wenn jede neue Möglichkeit zusätzliche Abhängigkeiten erzeugt.

Überarbeitung als Voraussetzung für nachhaltige Skalierbarkeit

Viele Salesforce-Marketing-Cloud-Umgebungen funktionieren technisch noch einwandfrei und können dennoch strategisch erschöpft sein. Das geschieht, wenn jede Erweiterung mehr Abstimmung erfordert, wenn Daten und Integrationen nur noch von Spezialisten vollständig verstanden werden und wenn neue Möglichkeiten hauptsächlich zusätzliche Abhängigkeiten schaffen. Die relevante Frage für 2026 lautet daher nicht, wie viel Funktionalität noch hinzugefügt werden kann, sondern wie viel strukturelle Klarheit erforderlich ist, um neue Funktionalität weiterhin verantwortungsvoll nutzen zu können.

Überarbeitung bedeutet dabei nicht, zu einer einfacheren Vergangenheit zurückzukehren oder bestehende Investitionen abzuschreiben. Sie bedeutet, explizit zu machen, welche Bestandteile der aktuellen Architektur noch zu der Organisation passen, zu der Marketing Cloud inzwischen geworden ist. Das erfordert klare Entscheidungen über Daten, Integrationen, Governance, KI, Ownership und Entscheidungsgrenzen. Gerade weil diese Entscheidungen im Voraus getroffen werden, entsteht erneut Raum für gezielte Erweiterung, ohne dass jede Veränderung die Verwundbarkeit des Gesamtsystems erhöht.

Für Enterprise-Organisationen ist dies letztlich der Maßstab für Skalierbarkeit: nicht ob die Plattform noch eine weitere Journey, Integration oder KI-Funktion bewältigen kann, sondern ob die Organisation diese Erweiterung verstehen, kontrollieren und reproduzieren kann. Ein überarbeiteter Architekturrahmen macht Marketing Cloud damit weder kleiner noch weniger ambitioniert. Er verhindert, dass Wachstum zu technischer und Governance-Schuld wird, und hält die Plattform als strategische Umgebung einsetzbar, die sich mit neuen Märkten, regulatorischen Anforderungen und kommerzieller Entscheidungsfindung weiterentwickeln kann.