Externe Abhängigkeiten in der IT-Strategie managen — bevor sie alles zum Brechen bringen

Das Problem, das niemand auf dem Schirm hat — bis es zu spät ist

„Nur eine kleine Änderung, die man nicht auf dem Schirm hatte oder eben, weil man der Strategie auch nicht verfolgt hat, kann auf einmal alles zum Brechen bringen.”

So formuliert es Bianca Glasner, Head of Engineering Platform Delivery bei Nosto — einer führenden E-Commerce Experience Plattform. In ihrer Rolle verantwortet sie Core Platform Engineering, AI, Infrastructure, Frontend und Platform Integrations. Sie weiß: Wer externe Abhängigkeiten passiv beobachtet, bezahlt früher oder später einen hohen Preis.

Das ist kein theoretisches Risiko. Es ist der Alltag jeder IT-Organisation, die auf externe APIs, Shop-Plattformen oder Drittanbieter-Ökosysteme aufbaut. Die Frage ist nicht, ob ein externer Partner seine Strategie ändert — sondern ob die eigene Organisation das rechtzeitig erkennt, kommuniziert und verarbeitet. In diesem Beitrag zeigt Glasner, welche Strukturen, Frameworks und Denkmodelle dabei den Unterschied machen.

Die wichtigsten Erkenntnisse

• Externe Abhängigkeiten erfordern aktives, verteiltes Monitoring — ein einziger Informations-Gatekeeper ist ein Ausfallrisiko, kein Vorteil.
• Strategie ist kein Dokument, sondern eine gelebte Praxis — sie muss von jedem Teammitglied verstanden, adaptiert und mitgetragen werden.
• Agile Methoden sind kein Universalwerkzeug — Infrastruktur-Updates mit harten Deadlines brauchen klassisches Projektmanagement mit Milestones, keine Sprints.
• 10-Jahres-Pläne sind in der IT nicht nur unrealistisch, sondern gefährlich — kürzere, quartalsweise Review-Zyklen schützen vor Orientierungsverlust bei Marktveränderungen.
• Strategie kaskadiert von einer stabilen Mission — Nostos „make every impression relevant” ist der strategische Kompass für Product, Engineering und Commercial gleichzeitig.
• Exploratives Experimentieren ersetzt Top-Down-Planung — Strategie entsteht durch validierte Hypothesen, nicht durch Boardroom-Beschlüsse.
• Informationsverlust ist ein Governance-Problem, kein persönliches Versagen — mehrkanalige Informationsverwaltung und Redundanz sind strukturelle Antworten.

Im Detail: Wie IT-Organisationen externe Abhängigkeiten strategisch managen

Externe Abhängigkeiten werden in IT-Organisationen häufig operativ behandelt – mit Newslettern und Eskalationen im Fehlerfall. Dabei handelt es sich um eine strategische Aufgabe. Führungsverantwortliche müssen API-Changes, Plattform-Ankündigungen und Partner-Updates aktiv beobachten und in die Strategieplanung integrieren, um Umsetzungsgeschwindigkeit und Koordination zu sichern.

Warum externe Abhängigkeiten eine strategische — nicht operative — Frage sind

Die meisten IT-Organisationen behandeln API-Changes, Plattform-Ankündigungen oder Partner-Updates als operative Aufgaben: Jemand abonniert den Newsletter, irgendwer liest ihn (vielleicht), und wenn etwas Kritisches passiert, eskaliert es — oft zu spät.

Glasner sieht das grundlegend anders. Für Nosto bedeutet das strategische Management externer Abhängigkeiten aktives Beobachten der Shop-Plattformen, mit denen die eigene Plattform integriert ist:

„Wir müssen natürlich die Augen auch offen halten, was machen denn die [Shopplattformen]… kann es ansonsten sehr schnell passieren, dass man natürlich den Anschluss verliert.”

Der Schlüssel liegt im Wort „wir”. Es ist keine Einzelperson-Aufgabe. Strategische Abhängigkeiten müssen als Organisationsthema geführt werden — mit klarer Verantwortungsverteilung, regelmäßigen Synchronisationspunkten und einem zentralen Wissens-Repository, das für das gesamte Team zugänglich ist.

Das ist nicht nur Best Practice — es ist Risikominimierung. Wer kritisches Wissen über externe Plattform-Changes bei einer einzelnen Person konzentriert, schafft einen Single Point of Failure in der eigenen Strategie.

Das Verteilte Informations-Modell: Redundanz als strategische Stärke

Glasner beschreibt ein konkretes Szenario, das vielen Tech-Führungskräften vertraut sein dürfte: Eine externe Plattform kündigt eine Änderung an. Der zuständige Entwickler oder Architekt übersieht die Ankündigung — nicht aus Nachlässigkeit, sondern weil das Informationsvolumen schlicht zu groß ist.

„Wir waren uns natürlich auch sehr sicher… weil es eben auch ein bisschen ein Überangebot an Neuigkeiten gab und eben auch dann nicht mehr klar nachverfolgbar war.”

Das Ergebnis: Kritische Changes landen erst im System, wenn sie bereits Probleme verursachen. Die Lösung ist strukturell, nicht individuell.

Das Knowledge Distribution Model funktioniert in fünf Schritten:

1. Kritische Informationsquellen identifizieren — Changelogs, offizielle Newsletter, Community-Channels, Slack-Gruppen der Plattformanbieter
2. Monitoring-Aufgaben auf mehrere Personen verteilen — keine Einzelverantwortung für strategisch relevante Informationen
3. Regelmäßige Synchronisations-Meetings — dedizierte Dependency-Calls, nicht als Unterpunkt in anderen Meetings
4. Zentrales Wissens-Repository — Wiki oder Docs, das alle erkannten Changes dokumentiert und auffindbar macht
5. Eskalations-Mechanismus — klares Protokoll für kritische Änderungen mit definierten Reaktionszeiten

„Das Beobachten von Ankündigungen sollte nicht nur bei einer Person liegen, sondern wirklich auch integriert verteilt sein.”

Diese Strukturierung ist kein bürokratischer Overhead — sie ist die Grundlage dafür, dass Informationsverlust als Risikofaktor systematisch eliminiert wird. Gerade in großen IT-Organisationen und Projektportfolios, wo Teams parallel an mehreren Plattform-Integrationen arbeiten, ist diese Redundanz nicht optional.

Wann Wasserfall das richtigere Werkzeug ist als Agile

Einer der provokativsten Punkte im Gespräch mit Glasner: Sie plädiert explizit dafür, klassisches Projektmanagement nicht zu verteufeln.

„Ich möchte da bitte niemanden auf die Füße treten und sagen, macht bloß keine Wasserfall. Nee, die haben durchaus ihren Platz und Sinn.”

Die Entscheidungslogik ist pragmatisch. Nicht alle Projekte haben dieselbe Charakteristik — und das Werkzeug muss zur Aufgabe passen, nicht umgekehrt:

Projekt-Typ-basierte Methodenwahl:

Besonders relevant ist dieser Ansatz für Infrastruktur-Roadmap-Planungen und API-Change-Management-Prozesse: Wenn eine externe Plattform eine Deprecation ankündigt und ein Migrationsfenster definiert, ist ein agiles “wir schauen mal” keine akzeptable Antwort. Meilensteine, Task-Breakdown und Fortschritts-Tracking sind dann die richtigen Werkzeuge.

Mission-getriebene Strategie-Kaskadierung: Der Kompass für alle Bereiche

Wie hält eine Organisation strategische Kohärenz aufrecht, während sich externe Abhängigkeiten, Marktbedingungen und Technologie-Landschaften permanent verändern? Nostos Antwort ist eine stabile übergeordnete Mission, die als strategischer Anker fungiert.

„Wir haben als übergeordnetes Ziel… ‘make every impression relevant’. Und basierend auf dem setzen wir natürlich unsere Strategie in den verschiedenen Bereichen.”

Das ist keine Unternehmens-PR — es ist eine operative Notwendigkeit. Mission-getriebene Strategie-Kaskadierung bedeutet: Product, Engineering, Commercial und Infrastructure entwickeln jeweils eigene Strategien, die aber alle auf denselben Nordstern einzahlen. Wenn sich der Markt verändert, können Bereichsstrategien angepasst werden, ohne dass die Mission selbst in Frage gestellt wird.

„Es zieht sich halt bei uns speziell anhand dieser Mission natürlich durch — Strategie in jedem Bereich.”

Das hat einen praktischen Vorteil für Product-Engineering Alignment: Beide Bereiche können unabhängig priorisieren und entscheiden, solange ihre Entscheidungen auf die übergeordnete Mission einzahlen. Das reduziert Abstimmungsaufwand, ohne strategische Kohärenz zu opfern.

Exploratives Experimentieren: Wie Strategie wirklich entsteht

Glasner beschreibt einen Strategieentstehungsprozess, der konträr zu klassischer Top-Down-Planung verläuft. Am Beispiel von E-Commerce-Betreibern, die Nostos Plattform nutzen:

Kunden beginnen mit einer Vision — Absatz steigern, neue Märkte erschließen — und testen dann parallel verschiedene Hypothesen: Personalisierung, Cross-Selling-Potenzial, intelligente Suche. Die Daten entscheiden über die strategische Ausrichtung, nicht das Bauchgefühl des Managements.

„Das ist eigentlich so der erste Punkt, wo Strategie für uns als Unternehmen eben auch sehr wichtig wird… wenn Zahlen dann für Leute sprechen, sieht man dann, wie sich die Strategie vom Shopbetreiber dann dahingehend verändert.”

Die Skalierung dieses Ansatzes ist beeindruckend: Glasner berichtet, dass ein großer E-Commerce-Anbieter 20.000 verschiedene Experiment-Versionen gleichzeitig laufen lässt — parallele A/B-Tests, die die leistungsstärksten Varianten in den Hauptbranch überführen. Das ist Strategie-Entwicklung durch systematische Validierung, nicht durch Planungs-Sessions.

Das Explorative Strategie-Entwicklungs-Framework in fünf Schritten:

1. Vision definieren (Absatz erhöhen, neue Märkte erschließen)
2. Hypothesen identifizieren (Cross-Selling-Potenzial, Personalisierungs-Hebel)
3. Parallele Experimente starten (A/B-Testing, Feature-Flags)
4. Daten sammeln und auswerten
5. Strategie basierend auf Validierung anpassen oder pivoten

Strategy Review: Warum 10-Jahres-Pläne in der IT kontraproduktiv sind

„Es macht wenig Sinn, speziell in der IT, dass man eine Strategie für die nächsten 10 Jahre hat… in der heutigen Zeit, wo wirklich alles so dynamisch ist, wo morgen einfach die ganze Welt ganz anders aussehen kann.”

Dieser Punkt trifft besonders auf Organisationen zu, die mit externen Technologie-Ökosystemen arbeiten: API-Versionen werden deprecated, Shop-Plattformen ändern ihre Architektur, KI-Modelle verschieben innerhalb von Monaten die technologischen Möglichkeiten. Ein Drei-Jahres-Plan, der im Jahr eins mit einer API-Deprecation konfrontiert wird, die nicht antizipiert wurde, ist bereits im ersten Quartal obsolet.

Der Adaptive Strategy Review Cycle ersetzt die klassische Jahresplanung durch kontinuierliche Überprüfung:

• Laufendes Monitoring von Kundenfeedback und Marktsignalen — nicht nur in Review-Meetings
• Quartalsweise statt jährliche Überprüfung der strategischen Ausrichtung
• Cross-funktionale Abstimmung zwischen Product, Engineering und Commercial bei jeder strategischen Anpassung
• Aktive Kommunikation von Strategieänderungen an alle Stakeholder — keine stille Kurskorrektur

Entscheidend ist dabei: Strategie darf nicht als Dokument behandelt werden, das ein